de PHP / symfony à Ruby / Rails : un an après


J’ai toujours très peu de temps dispo, d’où la fréquence de publication proche du néant depuis pas mal de mois. La faute à un bureau toujours trop sommaire à la maison, les travaux s’éternisant, et le peu de temps libre qui me reste est consacré à quelques projets pour l’instant un peu “top secret” ;)

On pourra remercier Vince au passage qui lui trouve du temps à consacrer à ce modeste blog !

Mais je viens de réaliser que cela allait faire quasi un an que j’avais attaqué Ruby / Rails de manière plutôt intensive et qu’un petit bilan s’imposait donc ! Alors je me lance !

Contexte

Un petit coup de contexte, notre startup Autrement édite 2 sites web, Chambres à part et HotelHotel. Le premier est en symfony1.4 et le 2e est en Rails3 suite à une décision prise fin 2009. Pour ceux que ça intéresse, Jérémy avait écrit un billet à l’époque sur ce choix.

A l’époque je m’étais retrouvé un peu seul à tenter vainement de défendre symfony mais j’avais du me résoudre à me lancer dans le grand bain pour la conception d’HotelHotel à laquelle il fallait bien que je participe (bah oué on est un peu que 3 côté techos :p), c’était il y a quasi 1 an !

Je vous préviens, ceux qui me côtoient un peu s’y attendent surement ;), je n’ai pas vraiment changé d’avis : Ruby / Rails j’accroche pas, et de depuis quasi les premières lignes écrites. Et je vais essayer de retranscrire un peu mon ressenti et retour d’expérience.

No révolution

Déjà, aucune révolution, il faut le savoir. Les différences fondamentales sont assez “mineures” dans le sens où ca n’a pas changé grand chose dans ma manière de bosser. En fait, si vous avez fait du PHP et du symfony, vous saurez faire du Ruby et du Rails, mais vous (re)passerez par la case documentation les 6 premiers mois pour trouver les équivalents à vos connaissances PHP/symfony.

Et ça commence du coup mal. Apprendre un langage et un outil en essayant de tenir des “cadences” de production honorables pour son égo, c’est pas simple. C’est même assez compliqué et ça frustre !

Côté bilan, le langage il n’y a pas grand chose à redire si ce n’est ce côté implicite avec lequel j’ai encore maintenant beaucoup de mal, question de goût j’imagine. J’ai croisé un jour un gist avec 2 “versions” d’un même code, l’un en version totalement implicite, l’autre en version totalement explicite (je remets pas la main sur le lien) : pas photo pour moi, le 2e était clairement plus compréhensible sans même connaître Ruby !
Mais les Rubyistes ont choisi le premier… ;)

Après, il est plutôt bien construit, l’api est clairement plus aboutie que PHP, et permet de faire tout autant de chose, et plutôt vite et bien une fois qu’on s’est habitué à sa syntaxe. Il faut être honnête Ruby n’a rien a envier à PHP en tant que langage pur. Mais la réciproque est pas loin d’être vrai. PHP se traine beaucoup de boulet, mais personne nous oblige à les utiliser.

Pas de switch en vue

Du coup pas vraiment de changement suffisant pour me dire que cela vaut le coup de “switcher”. Au contraire même, le problème (oui c’est un problème pour moi) de l’implicite rend toute lecture de code un vrai cauchemar ce qui m’a certainement ralenti et un peu découragé de me plonger à 110% dans le code comme j’aime tant faire. Parcourir des lignes de code que j’ai encore du mal à déchiffrer me décourage un peu. (Et oui désolé, mais moi, j’aime voir mes fins de lignes avec des points virgules !!!)

Pour le framework c’est une autre histoire. A vrai dire, je ne lui trouve pas grand chose pour lui. Attention, il vaut bien symfony 1 qui était ma référence lors de mon lancement dans Rails. Il permet de faire (quasi) tout autant de chose.
Je précise quasi, parce que moi j’ai toujours la vague impression que je suis bridé, certainement parce que je suis encore loin de maitriser les rouages que j’avais pris le temps de décortiquer sur symfony.
Et pourtant c’est déjà sa version3 (qui va avoir un an aussi d’ailleurs). Quand on voit le gap franchi avec symfony1 et Symfony2, la comparaison avec le second ne serait certainement pas à son avantage :p (:troll:)

Et c’est sans doute là que le bas blesse, je me suis retrouvé à repartir de zéro, en me disant que ça je saurais le faire de suite sur symfony, que Rails doit le faire aussi, mais qu’il fallait repasser par la case google. Et au final il le fait mais il ne fait guère plus. Donc peu de vrai “découvertes” et forcément, une petite déception…
Je me retrouve avec 2 couteaux, pas la même forme/couleur, mais le rendu est bien le même, j’arrive à couper mon saucisson sans problème (j’étais à l’apéro au moment d’écrire ces lignes…).
J’aurais préféré me retrouver avec un nouvel outil un peu différent, genre des ciseaux.

Bien sûr, je peux sans doute m’en prendre en grande partie à moi même, je n’ai jamais remis la même énergie que pendant mes 3 années passées sur symfony. Peut-être que je passe à côté de quelque chose ! Jémémy me dirait (et me dira ;)) certainement que oui…

Et puis la communauté me manque ! Je suivais (suit encore en fait ;)) l’actualité, blog, twitter qui tournent autour de symfony. Celle de Rails et même de Ruby est beaucoup plus petite en France et j’ai finalement très vite lâché l’affaire une fois de plus, un peu découragé.

Rajouter à cela, les gems, qui sont très sexy sur le papier mais qui compliquent un peu le côté, je vais mater dans le code comment c’est foutu de ce petit plugin qui rox, bien sûr le fameux RVM qui ne m’aime définitivement pas. On ne parlera pas de Passenger qui a lui aussi ses petits caprices de temps en temps, ou bien le fait qu’il faille redémarrer l’appli pour qu’un changement dans une lib soit pris en compte (mais apparemment que sur ma machine :( )

Des détails me direz vous ! Oui c’est clair, des broutilles auquel on est confronté tous les jours dans notre métier de développeur. Et le changement forcé de mes petites habitudes de bidouilleur PHP n’a pas du arranger les choses.

Je ne rentre volontairement pas dans le côté technique à comparer deux outils qui font leur job. Parce que pour le coup, la différence ne se fait pas là pour moi à mon avis.

Bilan

Au final on peut dire que c’est plus un mauvais feeling et le fait que je sois ravi de symfony et PHP qui font que j’accroche pas. J’ai passé et donné beaucoup de mon temps sur symfony et PHP et je n’ai pas été déçu, finalement je me dis que quelque part, je les trompe un peu … ;)

Et puis Symfony2 est arrivé… J’ai décortiqué les bétas, testé et retesté, lu le code. Et l’excitation de m’en servir grandit chaque jour ! Définitivement, une question de feeling donc. Et aussi parce que j’ai eu l’impression de progresser dans mon métier avec symfony1, et cette même sensation m’envahit quand je vois Symfony2. Ruby / Rails ne m’ont permis que de me diversifier…

Attention, je reste quand même ravi d’avoir pu goûter à ce changement. Ça aura au moins eu le mérite me confronter à autre chose justement, un environnement quasi entier qui diffère ! Je rajoute aussi une corde à mon arc, sait-on jamais hein…

Et ça m’aura permis aussi de me conforter, malgré toute la mauvaise presse qu’il se traine, dans l’idée que moi je l’aime bien mon PHP :p

Tags: , , , ,

A propos de l'auteur

Développeur web spécialisé Symfony, il est avant tout passionné de web tout simplement. Il aime les défis et farfouiller dans le code de Symfony ou Doctrine. Fondateur du blog, il exerce chez Autrement.

Vous avez aimé ce billet? Faites le savoir!

  • Delicious
  • Twitter
  • Technorati Favorites
  • FriendFeed
  • Google Bookmarks
  • Share

10 Réponses

  1. Jlecour 28 June 2011 à 12 h 21 min #

    Yes, je vais pouvoir réagir en preums ;-)

    On a beau travailler côte à côte depuis un bout de temps, j’avoue que je suis un petit peu étonné de cette amertume. Je savais bien que certains point te restaient un peu en travers, mais pas à ce point là.

    En même temps, ce que tu décris de ton plaisir à découvrir, décortiquer, … dans PHP/Symfony, je le vis de la même manière avec Ruby/Rails. Ça doit donc être une question de goût, de sensibilité. C’est tout à fait subjective mais carrément respectable.

    Le fait que la greffe n’ait pas prise sur toi est probablement lié au fait que ça n’est pas un choix que tu as fait. Tu l’as accepté de manière très pro et sérieuse (ce que je reconnait en tant que collègue), mais il t’as peut-être manqué la petite graine de passion ; celle qui fait qu’on lit plus, teste plus, participe plus dans la communauté, …

    Je pourrais évidemment argumenter (avec ou sans troll) sur les questions d’implicite/explicite, sur l’intérêt des gems, sur les outils de l’environnement, la communauté, l’écosystème, … mais c’est dur à faire à l’écrit dans une section de commentaires.

    Pour résumer, (et défendre ce que j’aime) je pense que le contexte n’a pas forcément joué en ta faveur, plus que les outils eux-mêmes. Je me fouetterai un peu en pensant que j’ai peut-être pas aussi bien accompagné cette diversification que j’aurais du le faire. Mea culpa.

  2. colinux 28 June 2011 à 17 h 25 min #

    Eh bien en tant que compagnon de bureau, je trouve aussi que tu as un mérite énorme à accepter de galérer autant comme ça semble être parfois le cas.

    Comme tu l’as dit le plus positif dans tout ça, c’est de t’y frotter par toi-même et te faire ton propre avis. Ça aura l’immense avantage de conforter tes choix futurs dans symfony2 pour de nouveaux projets pros ou persos.

    À propos de l’implicite, j’ai jamais manipulé de code fonctionnant comme ça, mais bien que je comprenne certains avantages que ça puisse procurer, intuitivement j’aurais tendance à largement préférer l’écriture plus complète de code. J’ai toujours pensé que c’était de la foutaise de devoir écrire le moins de lignes de codes pour le principe et pour réduire les chances de bugs: on peut en faire tout en autant si c’est pas plus si on n’a pas en tête ou en vue toutes les implications que quelques lignes peuvent avoir. J’ai aussi l’intuition que c’est plus long de trouver l’origine d’un bug fonctionnel, même s’il ya 10x moins de ligne de code, surtout si on maîtrise pas parfaitement les outils utilisés. M’enfin c’est peut-être mon amertume grandissante envers le web de mon côté obscur qui me fait dire ça…

  3. Jlecour 28 June 2011 à 17 h 37 min #

    Sur cette question d’implicite vs. explicite, j’ai moi aussi un regard partagé, voici un méli-mélo de ce que j’aime ou pas (attention avis perso) :

    * séparateur de fin de ligne : NON, c’est inutile
    * parenthèses pour les conditions de blocs (if, while, …) : NON
    * parenthèses pour les arguments de méthodes : NON si c’est pour écrire un DSL, oui si il y a des précédences ou à l’intérieur d’une ligne
    * self pour expliciter le récepteur du message : NON si c’est évident, OUI pour les cas un peu particuliers, mais là des fois je me fais avoir, donc j’avoue que c’est un peu glissant
    * “return” de fin de méthode : NON, on s’en sort très bien avec des conventions d’écriture du code (je parle pas de syntaxe)

    Je n’en vois pas d’autres pour le moment mais je suis sûr que vous allez en rajouter ;-)
    Et puis au besoin, on peut trouver des exemples concrets pour alimenter le débat.

    Ce que j’aime dans l’implicite c’est quand ça facilite la lecture en enlevant ce qui n’est pas nécessaire à la compréhension. En gros ; quand ça enlève du bruit, mais ça veut pas dire (pour moi) que c’est une course au moins possible de caractères écrits (je trouve aussi que c’est débile).

    Ça me fait penser au DRY. Le but n’est pas d’éviter les répétitions de caractères, mais d’éviter la présence d’une unité logique à plusieurs endroits dans le code.

    Il y aussi la tendance à compacter du code le plus possible : OUI si ça aide à le lire ou le rendre plus efficace, mais NON si ça devient illisible juste pour impressionner les collègues.

    On pourrait aussi parler des questions de méta-programmation. Certains adorent, d’autres détestent ; ce qui compte c’est d’utiliser ces “possibilités” à bon escient et pas juste pour la beauté du geste. C’est notamment là qu’on voit la véritable expérience d’un développeur.

  4. Florian Klein 29 June 2011 à 10 h 21 min #

    je suis tellement d’accord avec ton post et les commentaires!

    J’ai souvent entendu dire que “less code = less bugs”….
    D’où ca sort ce principe ?

    C’est clair que c’est pas le nombre de lignes qui fait la qualité du code, ni d’ailleurs le fait d’utiliser des parenthèses ou des point-virgules…

    C’est clairement l’architecture du code qui fait la lisibilité et la maintenabilité!

    Alors compacter du code parce que le langauge le permet, c’est clairement une erreur pour moi…

    Si rails, c’est ca, merci d’avertir :)

  5. Jlecour 29 June 2011 à 12 h 41 min #

    Florian, je me permet d’affirmer que Rails ça n’est pas ce que tu décris.

    En aucun cas un langage ou un framework ne peut forcer le développeur à écrire ceci ou cela. Par contre il est vrai que certains sont un peu aveuglés par des principes de concision. Ils trouvent ça magique au début et en font des tonnes pour se donner l’impression qu’ils sont forts.

    Comme je disais, il ne faut pas confondre la réduction du rapport entre les parties signifiantes et non signifiantes du code avec le fait d’en écrire le moins possible.

    D’ailleurs, plus le code est compact, plus il faut être balèze pour bien l’écrire en premier lieu et le débugguer ensuite.

    Un dicton dit “Si tu es à 100% de ton **intelligence** quand tu écris une ligne de code, tu n’arriveras jamais à la debugguer en cas de soucis”.

    Par contre “less code = less bug” est une vérité, mais à qualité de code égale. Le problème est souvent qu’on veut écrire moins de code, mais il est moins bon, donc plus buggé ou moins maintenable ;-)

  6. Damien 29 June 2011 à 16 h 08 min #

    Je serai intéressé de savoir de quel type de code “implicite” tu parle …

    Quant à “no revolution”, ce n’est pas rails qui a “piqué” les idées de symfony, mais bien le contraire.

  7. Jlecour 29 June 2011 à 16 h 27 min #

    Damien, ça n’est pas si simple que ça.

    En réalité, il y un certain nombre de framework dans la nature et chacun avance plus loin que les autres sur certains aspects. Au bout d’un moment, certains “concurrents” récupèrent les bonnes idées pour faire s’améliorer.

    Rails n’est pas celui qui a tout inventé non plus et qui s’est tout fait piquer. Il y a des design patterns qui ne viennent pas d’un framework en particulier, même si Rails en a mis en pratique plusieurs plutôt en avance.

    Il n’y a qu’à voir Rack par exemple. Ça fait partie maintenant des fondements de beacoup de framework en Ruby mais l’idée de départ et sa première implémentation viennent de Python avec WSGI.

    Moi je trouve ça vachement bien qu’une idée ou un concept qui a fait ses preuves puisse être repris ailleurs, ça fait avancer l’ensemble.

    Je ne crois pas qu’il faille attendre de vraie grande révolution en passant d’un de ces outils à l’autre.
    Par contre, chez l’un plus que les autres, on peut y trouver des manières de faire, de penser, des priorités données à certains axes, … qui nous parlent plus. Moi j’ai trouvé ça dans Rails, Tim plus dans Symfony et je connais plusieurs dev Django dans le même cas.

    Vive la diversité et le cannibalisme chez les frameworks !

  8. shouze 6 July 2011 à 21 h 18 min #

    Je vais faire court… je ne vois pas d’énormes révolutions dans les versions récentes de rails.
    Rails a été plutôt révolutionnaire à sa sortie, j’ai voulu en faire, puis quand j’ai pris le train en route j’ai vite été déçu par le fait que ça n’avançait pas si vite.
    Une chose qui me chagrine en particulier c’est l’ORM où à mon avis le principe d’Active Record n’est pas génial. Je préfère largement la façon dont les Frameworks Java Doctrine2 gèrent ça.

    Ensuite au niveau du langage : Ruby, comme Python, sont bien supérieurs en terme de conception car tout est objet.
    Cela dit on a beau avoir un bon langage, ce qui compte c’est ce qu’on en fait, et quelle communauté active de développeurs est disponible sur le marché du travail.
    Malheureusement en France on est super lights côté communauté de devs sur d’autres langages que PhP.
    Alors oui PhP n’est pas tout brillant loin de là, sauf qu’il est la référence open source sur le web pour l’instant.

    Côté serveur, python comme ruby ont fait d’énormes progrès pour devenir performants et ça c’est un bon point ! Il y a quelques temps j’aurais bien dit que PhP coûtait moins cher en hébergement à trafic identique. Aujourd’hui ça doit se valoir.

    Pour finir, attention aux devs PhP de ne pas s’endormir sur leurs lauriers car rien n’est acquis d’une part et d’autre part se diversifier et connaître un minimum sur un framework en java/ruby/python est plus que recommandé, ne serait-ce que pour s’ouvrir l’esprit.

  9. tomsoft 2 February 2012 à 15 h 22 min #

    @shouze : d’accord sur la diversification! le premier apport de rails a surtout etait de permettre l’emergence du model MVC dans les applis Web, ou avant c’etait soit du php bas niveau, ou du java/ejb imbitables!

    D’un autre coté, une chose que j’apprecie sur rails c’est que l’evolution est plutot bien maitrisé, et qu’il n’y a pas des nouvelles features toutes les semaines.

    Par contre, pas sur de comprendre ce que tu reproche a ActiveRecord. Sinon Rails3 introduit la separation et permet d’utiliser des choses comme DataMapper

    Et je ne suis pas sur de suivre le debat sur “implicite”. ne pas mettre des “;” c’est condiéré comme de l’ecriture implicite?

    Ca me semble un detail, mais ce que je trouve, ruby permet en tant que language d’exprimer des choses en très peut de ligne, et donc de se concentrer sur l’essentiel et pas la tuyauterie

    Content que les frameworks php sautent dans le train, car ce n’etait pas gagné pour eux d’avance!

    Autre avantage de rails, c’est qu’il y a aussi d’autres très bonne choses en ruby, notamment eventmachine, dans l’esprit de node.js mais apparu avant et qui permet de faire des tas de choses sympa ….

  10. aeiouy 11 July 2013 à 21 h 13 min #

    c’est définitivement une question de feeling effectivement. je tombe sur ce post par hasard (google, en fait je m’aperçois que j’ai tapé « rails je l’aime » dans google. je dois être complètement fou).

    je peste chaque jour me disant pourquoi je n’ai pas découvert rails plus tôt tellement j’adore ce framework. ce framework est une absolue bombe atomique. en fait, toute la bonne came bibliographique est en anglais, et je pense que c’est le principal frein au truc en France.

    j’ai perso commencé avec un bouquin en accès gratuit « Ruby on Rails Tutorial: Learn Web Development with Rails » de Michael Hartl. Ca t’apprend tout le basique, avec les best practices, c’est super concret (tu développes en fait au fil des chapitres un twitter like), c’est très actuel, tu peux clairement commencer à développer des trucs après ça. Ca m’a mis une dizaine de jours et ensuite j’ai complètement switché. Il y’a aussi énormément de vidéos, l’excellent site « railscasts » permet de découvrir tout plein de choses via des vidéos courtes.

    mon principal coup de coeur, c’est le gain de temps énorme. tout est implicite (ce qui visiblement te dérangeais), donc tu n’as pas à t’emmerder à tout redéclarer, tout spécifier. t’es comme dans une rolls royce en fait, t’as rien à faire :-)

    j’avais essayé symfony et j’avais pas accroché. donc surement question de feeling. dommâge que tu n’ai pas rencontré la lumière avec rails, sincèrement il a changé ma vie. yaaaaaaah!