Hébergeur

[gillesfabio]

@DelphineM Quel serait ton budget maximum ? Si tu recherches du mutualisé de qualité, Alwaysdata est vraiment top. Tu peux démarrer avec le compte gratuit, si le projet respecte les conditions (pas à fins lucratives, ni héberger des proxies). Puis éventuellement passer au pack 10 Go, si besoin.

Je ne pense pas que Node.js soit supporté out-of-the-box (du moins, il serait possible de le compiler mais je doute qu'on puisse respecter le quota de 10 Mo pour le compte gratuit). Mais Alwaysdata supporte bien Python/Ruby (oui, PHP aussi). Tu peux même bénéficier d'une interface administration auto-générée si le backend est réalisé avec Python/Django.

Si tu veux un hébergement qui te laisse plus de liberté (et donc, pouvoir utiliser les technologies que tu souhaites), tu as droit à 1 an de micro instance gratuite chez Amazon Web Service. Mais tu dois gérer toi-même l'admin. Après, je ne peux pas t'en dire plus puisque je ne connais que très peu ce service. Dans le même style (tu dois gérer l'admin), tu as aussi les entrées de gamme chez Online ou Kimsufi.

[DelphineM]

Dans la mesure où je suis sur un projet qui ne me rapportera jamais rien et pour lequel je suis dépendante de la communauté (il pourrait ne jamais exister sans que je puisse y faire quelque chose), je me vois mal mettre plus de quelques euros par mois. Et par quelques euros, j'entends 5 €. C'est d'ailleurs suffisant pour un hébergement mutualisé chez OVH. (J'ai peur d'être rapidement coincée avec les hébergements gratuits)

Suite à la conversation que nous avions commencée avant que Spoiled People soit une organisation, nous pourrions donc partir sur du PHP. @gillesfabio va être un peu déçu car il s'est vaillamment battu pour Node.js mais je pense que je n'ai pas le choix.

@Pivwan, tu t'étais proposé pour le serveur et je crois que PHP était ton option préférée ; tu es toujours avec nous ? Tu as d'ailleurs ton mot à dire si tu penses que je fais un mauvais choix.

[pygillier]

Amha, si on veut pouvoir proposer l'outil au maximum de personnes, il faut proposer au moins une version du web service en PHP. Simplement parce que c'est le langage le plus présent dans les hébergeurs gratuits ou bon marché. Après, en définissant proprement les API et en gérant les histoires de version, l'implémentation de ces API dans d'autres langages n'en sera que plus simple.

Pour résumer ma pensée, soyons agnostiques sur la technologie, au moins au début. Définissons déjà ce que chaque élément du projet doit fournir et comment il doit être architecturé

Pierre-Yves Gillier mailto:pierre-yves@gillier.name

Delphine Malassingne notifications@github.com a écrit :

Dans la mesure où je suis sur un projet qui ne me rapportera jamais rien et pour lequel je suis dépendante de la communauté (il pourrait ne jamais exister sans que je puisse y faire quelque chose), je me vois mal mettre plus de quelques euros par mois. Et par quelques euros, j'entends 5 €. C'est d'ailleurs suffisant pour un hébergement mutualisé chez OVH. (J'ai peur d'être rapidement coincée avec les hébergements gratuits)

Suite à la conversation que nous avions commencée avant que Spoiled People soit une organisation, nous pourrions donc partir sur du PHP. @gillesfabio va être un peu déçu car il s'est vaillamment battu pour Node.js mais je pense que je n'ai pas le choix.

@Pivwan, tu t'étais proposé pour le serveur et je crois que PHP était ton option préférée ; tu es toujours avec nous ? Tu as d'ailleurs ton mot à dire si tu penses que je fais un mauvais choix.

— Reply to this email directly or view it on GitHub.

[gillesfabio]

Je propose un truc. Comme c'est un projet communautaire, il serait injuste que tu sois la seule à le financer. Le plus simple serait de développer, dans un premier temps, une version fonctionnelle en local que quiconque pourrait également installer sur son serveur. Puis, pour celles et ceux qui ne souhaitent pas investir dans un serveur, proposer un financement participatif sur Ulule pour payer les frais d'hébergement du service (parce que tu seras très vite coincée avec du mutualisé, OVH ou pas, gratuit ou pas — montée en charge, perfs, libs, etc). Et là, tu ne te poses plus la question de PHP. Tu choisies la technologie la plus sympathique, la plus adéquate.

Je trouve vraiment dommage qu'au jour d'aujourd'hui, nous soyons encore contraints et forcés d'utiliser un langage immonde (certes, c'est très subjectif mais je connais très peu de développeurs heureux de l'utiliser) pour espérer toucher le plus grand nombre (d'autant que le plus grand nombre sera davantage intéressé d'utiliser la version centralisée plutôt que se prendre la tête avec hébergeur, installation et maintenance). Aujourd'hui, on a Python, on a Ruby, on a Node, on a des tonnes de frameworks géniaux développés par des gens blindés de talent et on en revient à... PHP. Il y a dix ans, OK. Le choix était limité et les alternatives fiables et éprouvées peu nombreuses. Mais aujourd'hui, AMHA, ce serait une erreur de partir sur une telle base. Puisque tôt ou tard, si le service connaît son petit succès, le code sera remanié et on finira par tout ré-implémenter en Python, Ruby ou Node, pour moins souffrir, pour donner envie aux développeurs de participer à son développement.

L'idée d'avoir plusieurs implémentations différentes (une spécification et plusieurs implémentations dans différents langages) n'est, AMHA encore une fois, pas la bonne solution. La dispersion des forces peut conduire à la mort, pure et simple, du projet. Quid de la maintenance de ces implémentations ? Les développeurs seront actifs les premières semaines puis finiront peut-être par ne plus les maintenir. Or, le temps passé au développement de chaque implémentation aurait pu être investi sur le projet.

Enfin bon, peu importe. Si PHP est retenu, je ne me pendrai pas non plus :) Mais envisageons peut-être d'autres pistes comme le financement participatif. Beaucoup plus juste. Et qui laisserait le choix de la technologie.

That was my two cents.

[DelphineM]

Suivons le conseil de @Pivwan :

Définissons déjà ce que chaque élément du projet doit fournir et comment il doit être architecturé et évitons trolls et provocations.

Nous avons une discussion qui attend notre énergie : Specification de l'API

[arnaudlimbourg]

Ne pas s'embêter et mettre ça sur heroku pour commencer :)

[spartDev]

Je suis de l'avis de @gillesfabio, avoir plusieurs implémentations dans différents languages est, pour moi, une erreur. Il faut que toutes les forces en présence se concentre sur un seul language afin d'éviter que le projet ne se disperse trop.

Concernant le choix du language, il est vrai que Php est le language le plus utilisé actuellement et connu du plus grand nombre mais justement ne serait il pas intéressant de regarder du coté des alternatives comme Node, Ruby ou Python et permettre à certain de monter en compétence dessus ? Ce qui m'intéresse dans ce projet (outre que je trouve l'idée de @DelphineM super intéressante) est de pouvoir échanger avec d'autres (développeur back, front ou autre) afin de continuer à apprendre tout en m'amusant sur un projet ! Je dois avouer avoir un certain penchant pour Node mais ca c'est le développeur front qui parle :)

L'idée d'un financement participatif me parait vraiment intéressante, comme la très bien dit @gillesfabio, il s'agit avant tout d'un projet communautaire et il serait donc injuste que seul @DelphineM sorte la main à la poche.

[kloh-fr]

Je sors du technique pour revenir sur la question initiale du choix d'hébergement, de son coût en particulier. Comme je le disais à @DelphineM sur son blog, j'avais en tête un projet similaire et j'étais prêt à investir un peu dedans, donc je donnerai volontiers quelques euros aussi s'il faut. Étant sans-boulot-fixe, je pourrai pas mettre grand chose, mais même 5 €/mois permet déjà d'avoir quelque chose, surtout si on est quelques uns à participer. :-)

[pygillier]

Je peux fournir une VM chez Gandi (j'ai du stock de crédits) avec le support qui va bien pour quelques mois.

Cela revient à 7.46€HT/mois pour une VM de base.