La réécriture de LinuxFr.org en Rails pose deux grandes questions : pourquoi réécrire et pourquoi Rails ? Pour les deux questions, j'ai pu répondre à travers différents commentaires, mais je souhaite expliquer ça de manière plus structurée.
Pour la première question, j'ai publié un journal hier : http://linuxfr.org/~NoNo/30481.html . Et la seconde fait l'objet de ce journal ;-)
Avant d'expliquer le choix de Ruby on Rails, je vais expliquer le contexte. J'ai commencé le développement de la nouvelle version début janvier 2009 (on peut encore lire sur github la description initiale du projet : The new version of LinuxFr.org will be in Ruby on Rails. It's my resolution for 2009.). Mais l'idée de réécrire LinuxFr.org est bien plus vieille que ça. Je me souviens que l'on en avait discuté lors de l'AG de l'association LinuxFr fin 2007. Il faut donc garder en tête que la décision de choisir Rails a été prise en 2008 en fonction de ce qui se faisait à ce moment-là.
Les critères pour choisir étaient assez simples :
1. Que ça tienne la charge sur le serveur LinuxFr ;
2. Que l'on puisse retrouver une grande partie des fonctionnalités existantes (pas simple, il n'y a pas de liste exhaustive des fonctionnalités, on sait juste qu'elles sont nombreuses, vraiment très nombreuses) ;
3. Que le CMS/Framework/langage soit suffisamment populaire pour attirer des contributeurs et être maintenu pendant au moins 5 ans ;
4. Et pour départager, ce serait ce qui me ferait le plus plaisir à faire. Après tout, c'est moi qui allait être le principal développeur, valait mieux que je sois motivé pour faire ça.
Mon premier réflexe a été de regarder ce qui se faisait du coté des CMS. La quantité de fonctionnalités me paraissait impressionnante (pourtant, avec le recul, je l'avais très largement sous-estimée à ce moment-là) et utiliser un CMS devait permettre d'avoir très rapidement une nouvelle version.
Mon langage de prédilection est le Ruby, j'ai donc commencé par regarder s'il y avait des CMS en Ruby qui pouvaient convenir. À l'époque, il n'y avait rien de vraiment probant (et encore aujourd'hui, les CMS en Rails, ce n'est pas vraiment ça). Puis, je suis aller voir ailleurs si l'herbe était plus verte. Dans beaucoup de cas, ça ne faisait pas grand chose des fonctionnalités demandés pour LinuxFr.org : la tribune, les commentaires sous forme d'arbre de discussions, différencier les nouveaux commentaires des commentaires déjà lus, etc. Du coup, quitte à devoir tout recoder, je préférais partir sur du Ruby on Rails plutôt qu'un CMS existant dans notre langage que je ne maitrise pas forcément aussi bien.
Après, il y a deux ou trois CMS qui auraient pu convenir. Je me rappelle surtout du cas de Drupal. J'avais commencé à regarder la chose et avais eu l'occasion de participer à un apéro Drupal (IIRC, c'était une des rencontres qui a permis la création d'une communauté Drupal française, réunie maintenant sur drupalfr.org). J'ai donc pu avoir des retours de gens qui utilisaient Drupal couramment, voir qui contribuaient au développement. Et ces retours m'avaient fortement refroidis. Je ne me souviens plus précisément des propos, mais c'étaient du genre : tiendra pas la charge ; moi, j'attendrais la prochaine version de Drupal ; faudra sûrement sacrifier quelques fonctionnalités ; etc.
Je me suis alors tourné vers les frameworks. J'avais le choix entre Rails, Django et les frameworks PHP (je n'avais pas vu de framework Perl intéressant). J'ai rapidement éliminés les frameworks PHP, ils étaient trop en retard sur Rails et Django. [troll] C'était il y a 2 ans, mais il semblerait que ce soit encore le cas aujourd'hui (je n'ai pas re-testé récemment mais ce sont les échos que j'en ai eu lors du dernier forum PHP) [/troll].
Restaient donc Django et Rails. Honnêtement, les deux se valent. L'un et l'autre sont deux très bons frameworks. Je pourrais trouver des points sur lesquels Rails est meilleur que Django, mais je suis sûr que des pythonistes n'auraient pas de mal à faire l'exercice inverse.
Pour départager les deux, j'ai fait appel au 4ème critère : le plaisir. Je connaissais mieux Rails que Django donc je pouvais attaquer plus vite la réécriture et [troll] Ruby est un langage bien plus fun que Python : je pense que la communauté Python est trop sérieuse pour accueillir un génie comme Why the lucky stiff, et Zed Shaw n'a pas encore dit de mal de Python, ça doit forcément cacher quelque chose [/troll].
Mon choix final a été Ruby on Rails et je pense qu'il a tout ce qu'il faut pour réussir ça : je ne m'inquiète pas trop pour les performances et la communauté est active (pas encore assez en France, mais ça va changer). D'ailleurs, si je devais refaire le choix aujourd'hui, je pense que je repartirais pour Rails.
Journal Pourquoi Ruby on Rails pour la réécriture de LinuxFr.org ?
26
nov.
2010
# premier journal du vendredi
Posté par ZeroHeure . Évalué à 5.
Et à part ça j'en profite pour féliciter l'auteur qui parvient à occuper tout l'espace rédactionnel du vieux linuxfr.org pour parler du nouv hum hum je m'égarais. Bravo m'sieur nono pour tout ce travail solitaire. Je sais ce que c'est et j'admire, plus d'un aurait déjà craqué.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# Comparatif ?
Posté par windu.2b . Évalué à 4.
(question sérieuse)
Sur quel(s) point(s) les frameworks PHP sont-ils encore en retard, par rapport aux frameworks Rails/Django ?
Car j'entends souvent parler de Symfony, Zend Framework, ... et plutôt en bien !
[^] # Re: Comparatif ?
Posté par CrEv (site web personnel) . Évalué à 3.
heu ... sur PHP par exemple
Bon, ça fait bien troll comme ça, mais l'une des forces de rails est justement ruby, qui permet d'étendre facilement le langage. Ainsi on a presque l'impression que certains aspects du framework sont le langage. Il en résulte un très bon ressentiment lorsqu'on code, c'est agréable.
A côté de ça, PHP et agréable ça pique...
[^] # Re: Comparatif ?
Posté par Ludo . Évalué à 2.
De plus, pour avoir fait pas mal de Zend Framework, il y a de bonnes idées, mais il y a souvent pas mal d'abstractions dans les classes qui complexifient le code sans pourtant avoir des avantages probants.
Alors qu'en RoR, le framework me semble plus pragmatique par rapport au besoins quotidiens d'un développeur Web.
[^] # Re: Comparatif ?
Posté par Bruno Michel (site web personnel) . Évalué à 4.
Est-ce que ces personnes ont déjà essayé des frameworks dans d'autres langages comme Rails ou Django ?
[^] # Re: Comparatif ?
Posté par Bruno Michel (site web personnel) . Évalué à 2.
Je ne suis pas les avancées des frameworks PHP, donc je vais probablement dire des bêtises, mais je me lance. Les personnes qui connaissent mieux les frameworks PHP que moi pourront me corriger ;-)
Tout d'abord, j'ai l'impression que les frameworks PHP sont très en retard sur tout ce qui concerne les tests. Je ne connais pas d'équivalent à rspec en PHP par exemple. Une anecdote me confirme dans cette opinion : lors d'une des présentations au dernier Forum PHP, le conférencier a demandé qui connaissait les mocks ou stubs à l'audience, et j'étais l'une des deux personnes à avoir levé la main.
Ensuite, il y a la gestion des assets. Il existe pas mal de plugins Rails pour compresser/minifier/bundler des fichiers javascripts. Sass et Less sont une grande avancée pour gérer les feuilles de styles. Il y a des outils pour créer des sprites CSS facilement.
Un troisième exemple est le possibilité de profiter des technologies NoSQL. Damien Tournoud, qui a fait l'introduction au monde NoSQL lors du forum PHP, considère que les frameworks PHP sont très en retard sur ce point. Les bibliothèques pour se connecter à redis sont des gros bricolages. Les ORM ne savent que très mal utiliser des bases NoSQL comme MongoDB.
[^] # Re: Comparatif ?
Posté par Sufflope (site web personnel) . Évalué à 4.
Oui enfin... forcément...
[^] # Re: Comparatif ?
Posté par Bruno Michel (site web personnel) . Évalué à 2.
[^] # Re: Comparatif ?
Posté par Dinofly (site web personnel) . Évalué à 1.
http://www.doctrine-project.org/blog/tags/odm
[^] # Re: Comparatif ?
Posté par Dinofly (site web personnel) . Évalué à 3.
Je n'ai peut-être pas compris ce qui fait la spécificité de rspec mais il me semble que ce n'est qu'une bibliothèque de tests unitaires ?
Ça existe bien évidemment en PHP avec PhpUnit ou Simpletest. Le code de Symfony2 est couvert à plus de 95% par des tests unitaires.
Il est tout à fait possible de faire du TDD en PHP, j'en fais moi-même !
Le fait qu'au forum PHP il n'y ait pas grand monde qui connaisse ça est "normal": ça vient du public de PHP. PHP est très accessible aux débutants, donc beaucoup de développeurs PHP sont (et resteront, bien souvent) super-novices. Ça ne représente pas les possibilités du langage en lui-même, mais son usage général.
Quelqu'un qui connaît Ruby ou Python, c'est déjà quelqu'un qui cherche un peu plus loin que les langages que tout le monde connaît. C'est à mon avis pour ça que les développeurs concernés sont en moyenne meilleurs que les développeurs PHP, et non par les qualités intrinsèques de ces langages.
[^] # Re: Comparatif ?
Posté par daimrod . Évalué à 4.
C'est à dire que lorsque tu fais du PHP sans framework tu pleures très rapidement.
Donc dès que tu découvres un framework genre Symfony c'est l'extase.
# Rails 2.3 ou Rails 3
Posté par bghflt (site web personnel) . Évalué à 4.
La seule réserver pourrait avoir été que tu ne maîtrise pas l'architecture sur laquelle poser ton bébé, mais comme tu as là toute latitude..
Tu comptes partir pied au plancher sur la Version 3 ?
[^] # Re: Rails 2.3 ou Rails 3
Posté par Oni . Évalué à 3.
# Perl et Ruby
Posté par jbbourgoin (site web personnel) . Évalué à 1.
Sinon Ruby est un excellent choix, et puis c'est un langage fun !
[^] # Re: Perl et Ruby
Posté par Frank-N-Furter . Évalué à 2.
Depending on the time of day, the French go either way.
[^] # Re: Perl et Ruby
Posté par Bruno Michel (site web personnel) . Évalué à 2.
[^] # Re: Perl et Ruby
Posté par ZeroHeure . Évalué à 4.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Perl et Ruby
Posté par jbbourgoin (site web personnel) . Évalué à 1.
[^] # Re: Perl et Ruby
Posté par Jean B . Évalué à 5.
Je n'ai pas essayé Catalyst_(logiciel). Dancer [http://perldancer.org/] est pas mal du tout, mais comme je préfère le Ruby, je reste accroché à en:Sinatra_(software).
De rien ;)
# Fun
Posté par wilk . Évalué à 4.
En tant que développeur en Python pour le boulot, je confirme tout à fait ton point de vue. J'ai justement choisi Python pour aller droit au but sans me laisser distraire. Pour les loisirs ou r&d ça m'ennuierait sûrement.
# Critéres de choix d'un environnement
Posté par rogo . Évalué à 1.
J'ai plutôt l'impression que les critères furent :
1. Se faire plaisir avec une techo que j'aime bien.
2. Pas partir dans du folklo complet (choisir des outils qui tiennent au moins 5 ans).
C'est tout à fait honorable quand on est seul à développer.
Sinon, pour les critères annoncés, les 1, 2 et 3 ne me semblaient pas déterminants :
1. La charge.
Si j'en crois mon expérience, un système de cache (soit interne à l'appli, soit au niveau du serveur web) nivellera les performances. RoR a plutôt la réputation d'être lourd, en particulier avec son ORM/ODM, et Ruby 1.8 est franchement lent (Ror/1.9 est instable, non ?), mais ça ne devrait pas être bien important par rapport au cache.
2. Les fonctionnalités
Il faut de toutes façons les coder. Avec un CMS, certaines peuvent être fournies d'entrée, mais il faut forcément compléter.
3. La popularité et la longévité.
Django, Drupal, Symfony, ZendFramework, Ror. Tout ça garantissait 5 ans de suivi. Pour attirer des développeurs, AMHA, un framework/CMS PHP attirait 10x plus de développeurs qu'un produit Python, lui même attirant 2x plus de monde que du Ruby.
4. Le plaisir perso.
Le goût pour Ruby est respectable. D'où le choix de RoR et Ruby.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.