Closed j15e closed 11 years ago
Personnellement, j'irais pour le PHP. Les ressources sont plus facile à trouver avec ce language. Mon deuxième choix serait le Python
Aucune intégration de système à prévoir avec Centraide ni les employeurs a qui vont l'utiliser. La seule extraction à prévoir est un CSV des dons pour que l'employeur fixe les retenues à la source pour l'année qui suivra.
L'équipe de Centraide n'a pas d'équipe interne donc il n'y a pas de contraintes technologiques. L'application sera maintenue ici comme elle sera créée initialement.
Les technos proposées sont intéressantes. Bernard Chhun qui a rejoint le projet s'y connait dans plusieurs d'entre elles. Il aussi proposé CodeIgnitor et CakePHP.
L'important c'est le résultat et les différentes avenues proposées se rendent toutes à la même destination.
On attendra les prochains jours pour avoir un nombre suffisants d'équipiers pour trancher.
Ça débute bien! Le 11 août 2013 14:19, "Sylvain Mallet" notifications@github.com a écrit :
Personnellement, j'irais pour le PHP. Les ressources sont plus facile à trouver avec ce language. Mon deuxième choix serait le Python
— Reply to this email directly or view it on GitHubhttps://github.com/centraide-quebec/campagne-en-ligne/issues/3#issuecomment-22462313 .
@sylvainmallet Tout dépends des compétences de l'équipe de bénévoles. Python, c'est bien, mais il faut que les bénévoles qui travailleront dans le backend soient à l'aise avec ce dernier.
@j15e Plone est un peu too much pour ce projet selon moi. C'est un CMS qui penche beaucoup vers les fonctionnalités de portail web. De plus, la création de thème avec ce dernier est infiniment plus chiant qu'avec Django et/ou Flask.
@sylvainmallet Tout dépends des compétences de l'équipe de bénévoles. Python, c'est bien, mais il faut que les bénévoles qui travailleront dans le backend soient à l'aise avec ce dernier.
Entièrement d'accord avec @bchhun. Les compétences de l'équipe sont un des points déterminants lorsqu'on choisit la techno pour un projet. Moi aussi j'ai une préférence pour du Python ou du Ruby, mais si l'équipe est constitué entièrement de développeurs PHP, le choix n'est pas difficile à faire.
Un autre facteur à considérer, (mais qui n'est peut-être pas important dans le cadre de ce projet) c'est les librairies qui sont disponibles selon le langage/framework. Peut-être Python offre des librairies avec des fonctionalités mieux adaptés au projet qui ne sont pas disponibles dans PHP, par exemple.
@j15e Plone est un peu too much pour ce projet selon moi. C'est un CMS qui penche beaucoup vers les fonctionnalités de portail web. De plus, la création de thème avec ce dernier est infiniment plus chiant qu'avec Django et/ou Flask.
Encore une fois, je suis d'accord avec @bchhun (heureuse coincidence ! Qui sait, peut-être on serait toujours d'accord sur tout si on se rencontrait dans la vrai vie ;) ). Si le projet tend vers le python, je choisirais quelque chose de plus léger comme Django ou Flask.
Je connais vraiment peu les framework Python (flash semble être un cousin de Sinatra), mais vous avez mon vote pour Python vs PHP pour la qualité générale des librairies et surtout de l'environnement de développement.
Pour ce que je connais du projet, j'opterais personnellement pour le PHP. Mais c'est biaisé car c'est mon langage préféré ;) Et pour le framework je recommanderais CodeIgniter pour sa simplicité et sa capacité au HMVC si le projet le rend nécessaire (http://net.tutsplus.com/tutorials/php/hvmc-an-introduction-and-application/).
Je serais personnellement prêt à donner de mon temps en tant que développeur ruby. On pourrait utiliser Sinatra ou encore Rails. Je maitrise de mieux en mieux RoR, et je crois que ce serait un framework très pertinent pour ce projet puisque la communauté autour de Ruby on Rails est vraiment en effervescence et produit des gems opensource (plugin/library) d'une grande qualité. Ces gems accélère grandement la réalisation d'une application, et la mentalité opensource semble profondément ancré au sein de cette communauté. Je crois que ce serait le choix à faire.
@Madumo Ces arguments sont également valides pour Python et même PHP depuis la sortie de Fuel et Laravel. On se tire dans le pied à court et à long terme si on choisit une techno qu'une seule personne maîtrise sur 4. Le problème n'est pas tant l'apprentissage du langage/framework, mais bien la connaissance des pièges propres à chaque techno.
Oui, c'est vrai. Je suis tout de même ouvert à l'idée de le faire en python s'il y a des gens ici qui s'y connaisse bien avec un framework et qui ont suffisamment de temps à consacrer au projet pour offrir un certain mentorat aux développeurs avec moins d'expérience avec le langage/framework.
Mais suis-je le seul avec une base avec ruby/RoR ?
Je suis d'accord avec @bchhun. Il faut voir combien de dévelopeurs sont prèts à travailler avec les technologies choisies.
Il faut p-e aussi penser à ceux qui vont héberger le site. S'ils l'hébergent chez eux, c'est p-e une bonne idée d'y aller avec une technologie qu'ils maitrisent.
Si une communauté parvient vraiment à réaliser ce projet à terme, je doute que la "facilité" de mise en production soit un réel problème auquel il faut s'attarder ;-) Rendu là n'importe qui peut s'en charger via ssh.
@Madumo nous n'avons pas encore eu de rencontre de démarrage, mais j'ai cru comprendre que @sylvainmallet et @dfstorm maîtrise bien PHP. Pour ma part, je suis un généraliste qui a bossé avec .NET, Python et PHP.
@Madumo pour ce qui est de la mise en production; j'en doute fort, mais que faire si le serveur de production est sous Windows ? ça devient un problème tannant si on le sait pas d'avance. Évidemment, il y a des solutions pour ça, mais bon. Autant s'éviter certains problèmes d'avance.
@bchhun Je crois que les questions de mise en production sont réellement un problème moindre. Le site n'attirera sans doute pas un trafic monstre et je suis plutôt certain qu'avec une initiative de ce genre il ne sera réellement pas difficile de trouver de l'hébergement sponsorisé qui satisfasse les besoins de l'application.
La mise en prod n'est pas un réel problème, et s'il en est un il est bien minime en comparaison au problème qu'est la réalisation même du projet. Il faut considérer les disponibilités humaines (en heure/semaine mais aussi en niveau d'expertise) pour chaque technologies proposées.
Évidemment, si je suis le seul à me débrouiller avec RoR, ce ne sera définitivement pas un bon choix. D'autant plus que je ne suis pas un expert.
Ce n'est pas seulement une question de mise en production, mais plutôt une question de maintenance. Il semble que ce sera hébergé chez Evoilla. Si leurs applications utilisent toutes le même language, en ajouter un nouveau comporte des coûts pour eux qui devront s'assurer de tout garder à jour. Et surtout de tout configurer de façon sécuritaire. Pour la mise en prod elle-même, un script s'en charge.
J'ai relu le commentaire de @nicolasroberge, et il semble prêt à maintenir ce qui sera choisi. Mais ça vaut quand même la peine d'y penser, Même si je suis d'accord que ce n'est pas aussi problématique que de trouver des gens qui vont s'impliquer.
Dans le pire des cas ça sera hébergé chez Evollia. Toutefois Microsoft a offert de l'héberger sur Azure. Je sais que ça supporte pas mal n'importe quoi maintenant. Il faudrait s'assurer que ça fonctionne là. Sinon, si c'est chez Evollia on héberge que le stack LAMP et .NET/MSSQL chez Rackspace.
Pour le choix techno, je veux juste que ça vous passionne et que vous ayez du plaisir à travailler là-dessus. En tant qu'employeur je sais qu'il y a plus de ressources humaines en PHP suivi de Ruby suivi de Python. Mais ce sont tous d'excellentes technos assez nez à nez en terme de fonctionnalités. Le 12 août 2013 21:15, "Eric Hogue" notifications@github.com a écrit :
Ce n'est pas seulement une question de mise en production, mais plutôt une question de maintenance. Il semble que ce sera hébergé chez Evoilla. Si leurs applications utilisent toutes le même language, en ajouter un nouveau comporte des coûts pour eux qui devront s'assurer de tout garder à jour. Et surtout de tout configurer de façon sécuritaire. Pour la mise en prod elle-même, un script s'en charge.
J'ai relu le commentaire de @nicolasrobergehttps://github.com/nicolasroberge, et il semble prêt à maintenir ce qui sera choisi. Mais ça vaut quand même la peine d'y penser, Même si je suis d'accord que ce n'est pas aussi problématique que de trouver des gens qui vont s'impliquer.
— Reply to this email directly or view it on GitHubhttps://github.com/centraide-quebec/campagne-en-ligne/issues/3#issuecomment-22537476 .
Pour ceux qui sont intéressé par Python je vous propose Pyramid qui offre un flexibilité hors-pair et qui permet de choisir l'architecture et les composantes appropriées au projet. On peut partir simple, comme Flask, et finir élaboré comme bon vous semble. Je suis un membre fondateur de Pylons Project et un «core» développeur du projet, je peux donc participer à toutes les étapes et aussi fournir le support nécessaire aux collaborateurs intéressés.
Pour le déploiement, Rackspace est un excellent choix. Combiné à un outil d'orchestration comme Ansible il serait simple de maintenir un serveur Cloud bien organisé et d'assurer à l'application un déploiement fiable.
Je ne sais pas si Azure offre un bon support pour les technologies proposées (qui sont *nix), mais une plateforme Linux serait appropriée pour ce type de development/déploiement à mon avis.
Je tiens d'abord à remercier @Madumo et @blaflamme pour vos opinions et vos suggestions. Je sais que le choix de la techno est un sujet chaud pour la plupart des développeurs et je suis heureux de savoir que ça vous importe assez pour que vous interveniez.
Cela étant dit, je préfère attendre à notre rencontre de démarrage en équipe avant de faire un choix définitif de la techno.
Notre équipe ne connait pas encore toutes les contraintes du projet et je veux en savoir plus avant de sauter sur une techno que nous maîtrisons moins bien.
Vous le savez probablement déjà, mais les courbes d'apprentissages des éléments suivants ont le potentiel de ralentir grandement notre vélocité de développement:
Or, ce qui m'inquiète le plus en ce moment est la date de livraison du projet (que je ne connais pas encore).
D'après la page d'à propos de Centraide, la campagne 2013 se tient de la mi-septembre au début décembre. Dans mon livre à moi, cela se traduit par un prototype fonctionnel d'ici 1 mois (mode pessimiste).
Si c'est le cas, il est certain que nous choisirons une techno connue de nous 3.
Merci à tous de votre intérêt !
Personnellement, je suis beaucoup plus "fluent" en php qu'avec les autres languages. Pour l'hébergement, je ne crois pas que ce soit vraiment un gros problème. n'importe quel serveur Unix/Linux ferait la job. Au pire du pire, un serveur windows, mais ça je ne le suggère pas vraiment.
Un serveur Linux représenterait mieux, à mon avis, l'esprit de centraide ;) Tout dépendra de l'affluence prévu...
@bchhun j'ai vu qu'il y avait une ouverture pour l'utilisation de python et le projet semble être un bon «fit». Je voulais tout simplement vous signaler mon intérêt si vous pencher vers cette possibilité, c'est ma spécialité.
@blaflamme Je suis également plus productif sous Python que tout autre stack de développement. Mais je ne veux pas l'imposer à notre équipe de bénévoles si cela implique que nous ne livrons pas le projet dans un délai raisonnable.
@bchhun exact, et ce n'est pas mon intention d'influencer le choix. Par contre si Python est choisi je pourrai participer à un niveau plus important.
Je serais partant de donner un coup de main en python, je suis loin d'être un pro sauf que je serais prêt à mettre du temps !
A.
@blaflamme @akimc merci a vous 2. On vous en redonnes des nouvelles apres notre reunion de demain soir
Bon matin messieurs,
Nous avons donc choisi le langage PHP avec un choix de framework de dernière génération:
Personnellement, Laravel a mon vote.
Gabriel et Sylvain devront consulter leurs docs respectives et me revenir avec leur choix.
Merci à tous pour vos suggestions !
Je présume que c'est une discussion qui aura lieu surtout avec les développeurs souhaitant s'engager à donner de leur temps, mais ce serait intéressant d'avoir une idée des technologies auxquelles l'équipe de développement interne est ouverte et savoir s'il faut intégrer le système à un ou d'autres systèmes existants posant des contraintes.
Personnellement je n'ai pas le temps nécessaire outre pour quelques petites contributions au README :smile:, mais j'aimerais voir le projet se développer avec Rails sous Ruby, Django ou Plone sous Python ou Symfony2 sous PHP.