Parfois, j’entends des gens se plaindre de leurs clients, dire qu’ils insistent pour utiliser Rails, qu’ils ont bu trop de Kool Aid. S’il s’agit de recruteurs, ils ont presque mal au cœur à l’idée de devoir trouver un énième développeur Ruby on Rails » primadona « . Puis ils sortent quelque chose de similaire à cette comparaison incroyablement ignorante entre Git et PHP pour prouver leur point de vue. » Ils ne savent même pas ce qu’ils demandent « , disent-ils.
Pour nous, programmeurs, il semble parfois effectivement que nos clients n’ont pas la moindre idée. Nous aimons exagérer des cas comme celui-ci. Quand on y réfléchit un peu, il ne semble pas juste de penser qu’une personne qui me donne de l’argent pour construire des choses est en quelque sorte limitée et » ne comprend pas « . En fait, je crois que la plupart des clients connaissent très bien leurs options et pourtant ils décident quand même d’opter pour Rails.
Je vais essayer d’expliquer ce qui, à mon avis, rend Rails suffisamment bénéfique pour être sérieusement considéré pour une pléthore de projets et de besoins.
Bénéfices de Ruby
Il est possible que personne ne connaisse même les avantages de Ruby si ce n’était pas pour Rails lui-même. Certaines personnes aiment déprécier Ruby en disant que c’est » si facile pour Ruby » avec son » chevalier servant appelé Rails » et que sans Rails, » Ruby serait sans intérêt « . Je ne peux pas dire avec certitude si c’est vrai ou non, mais je sais qu’il serait extrêmement dommage que le monde passe à côté d’un langage aussi superbe. Le fait est que l’auteur de Rails a choisi Ruby délibérément et que son pari « sauvage » a été payant. Ce qu’il a vu à l’époque, beaucoup d’autres peuvent le voir aujourd’hui. Ruby permet en quelque sorte aux programmeurs de s’épanouir d’une manière particulière qu’il est difficile d’expliquer aux « masses non averties ». Alors, pourquoi utiliser Ruby on Rails ? Ruby rend les programmeurs heureux, comme annoncé.
Si la plupart des développeurs s’accordent à dire que Ruby est pratique, certains le voient comme trop. Ils s’inquiètent de ce qui pourrait arriver avec toutes les libertés que Ruby permet, tout le potentiel de mauvaise utilisation. Permettez-moi d’illustrer mon propos par un patch singulier :
"1".to_i #=> 1class String def to_i raise 'foobar' endend"1".to_i #=> RuntimeError: foobarC’est aussi simple que cela : avec seulement cinq lignes de code, nous avons pris une classe existante et modifié son comportement. Rien n’est sacré, pas même une chaîne. Cette erreur particulière serait facile à repérer, mais les choses peuvent devenir beaucoup plus sinistres :
class String def to_i self.to_f - 1.13 endend"2".to_i #=> 0.8700000000000001Juste comme ça, nous avons introduit une erreur dans la classe String qui pourrait être enveloppée dans et obscurcie par des couches successives de complexité.
Alors, vous vous dites peut-être : Est-ce que tout le monde et sa mère peuvent mettre en péril ma précieuse application ? Bien que ce comportement semble effectivement effrayant – il ne l’est vraiment pas. En cinq ans d’utilisation de Ruby, j’ai eu exactement zéro problème avec ce comportement. Cela peut sembler contre-intuitif, mais il en va de même pour les voitures qui roulent à 60 km/h dans des directions opposées, séparées seulement par une fine ligne blanche au milieu de la route. En pratique, les deux fonctionnent remarquablement bien.
Un autre avantage est que Ruby est un outil polyvalent. En tant que tel, il a des bords tranchants, comme des couteaux. J’aime à penser que les adultes peuvent manipuler des couteaux très bien – la protection des enfants est pour, eh bien, les enfants (Tweet). Et le fait d’être traité comme un enfant dans l’informatique fait de vous une victime du paradoxe de Blub de Paul Graham : vous pensez que vous êtes mieux sans certaines fonctionnalités que vous ne comprenez pas ou que quelqu’un vous a dit être trop dangereuses. Bien sûr, aujourd’hui, nous nous demandons « pourquoi utiliser Ruby on Rails » ; il s’agit donc d’un débat pour une autre fois. Il est vrai que Ruby ne dispose pas de certaines fonctionnalités que d’autres langages possèdent (Lisp hmm, hmm). Dans l’ensemble, Ruby est proche du sommet du » continuum de puissance du langage « .
Mes premières années avec Ruby ont été une leçon d’humilité. J’ai appris tellement de choses rien qu’en lisant le code des autres. Parfois, j’étais émerveillé ; parfois, j’étais fou ; mais finalement, ces connaissances m’ont permis de communiquer avec mon ordinateur beaucoup plus efficacement qu’auparavant. Je me sens presque désolé pour certains autres langages » bureaucratiques » qui vous font sauter à travers des cerceaux juste pour le plaisir de les sauter, tout en vous disant » je fais juste ce qu’il y a de mieux pour vous, c’est pour votre bien ! «
Pragmatisme
Il y a un profond respect pour le pragmatisme tricoté dans l’ADN de Rails au plus bas niveau possible. En combinaison avec les avantages de Ruby, ce pragmatisme produit des solutions élégantes et encourage/inspire la communauté de développement Ruby on Rails à faire de même. Le pragmatisme est souvent présenté comme une tente de Rails, cette affirmation n’est donc pas nouvelle, mais elle m’a été rappelée à l’ordre très récemment lorsqu’un de mes amis a essayé de me montrer à quel point Hibernate est vraiment « cool ». Il avait du mal. Je pouvais sentir sa douleur alors qu’il était incapable de définir une myriade d’options et de paramètres de configuration qui auraient dû être des valeurs par défaut du framework en premier lieu.
Avec l’âge, mes normes de complexité artificielle sont devenues de plus en plus élevées. Considérant que j’ai commencé à écrire du code de production en 1989 à l’âge de 11 ans (en commençant par un projet pour mon voisin de palier dans Clipper Summer ’87), j’ai une tolérance proche de zéro pour les complications inutiles. Et Rails a un score très élevé dans ce domaine. C’est plus qu’un simple » convention over configuration » ; je parle de tout l’état d’esprit pragmatique qui est très apprécié au sein de la communauté Rails et qui s’y infiltre.
Expressivité
Rails est aussi proche de l’anglais qu’il peut l’être (sauf si vous utilisez COBOL). Il utilise ce que l’on appelle un DSL interne, étendant Ruby avec sa propre sémantique. La construction d’un DSL est toujours dangereuse car vous développez effectivement un nouveau langage. Comme il s’agit d’un DSL interne, vous n’avez pas besoin d’utiliser un analyseur syntaxique externe, mais dans un sens, cela ressemble à un nouveau langage. L’équipe de Rails a trouvé un bon équilibre avec son DSL, en l’utilisant là où il est utile et en n’en abusant que rarement, faisant ainsi preuve d’une excellente maîtrise de soi. Je pense que n’importe quel programmeur, quelle que soit son expérience de Rails, (et même certains non-programmeurs) pourrait comprendre cela :
En fait, si vous n’êtes pas familier avec Ruby, cela peut sembler étrange – c’est presque comme si ce n’était pas un langage de programmation. Une fois que vous avez compris qu’il s’agit simplement d’appels de méthodes sans parenthèses, vous êtes bon pour la suite. Malgré tout, le DSL de Rails donne l’impression d’être ce langage spécial pour décrire les exigences, alors qu’en fait, il s’agit simplement d’un nommage intelligent et d’une utilisation inhérente de l’excellente syntaxe de Ruby.
Communauté
Rails dispose d’une armée de committers qui s’assurent qu’il reste en parfait état. De nombreux projets mijotent avec l’âge, pourtant avec Rails, les étincelles volent encore lorsque des décisions doivent être prises. On a l’impression que les mainteneurs (encore) se soucient vraiment et veulent que les gens utilisent Ruby on Rails et comprennent ses avantages.
Sous Rails lui-même, comme une cerise sur le gâteau, se trouve Ruby avec son formidable gestionnaire de paquets, RubyGems, comparable à CPAN en termes de nombre de paquets – et compte tenu de l’âge de CPAN, cette affirmation est (pour le moins) très impressionnante. Rails a connu un bref déraillement lorsqu’il a essayé de créer ses propres « plugins Rails ». Heureusement, cela n’a pas collé, et RubyGems reste donc la source unifiée et superbe de code programmé par des individus très brillants.
La synergie entre un langage cool, un framework web pragmatique et une superbe communauté donne à Rails un résultat bien meilleur que la somme de ses parties.
Maturité
Rails a fait le tour du pâté de maisons. D’une manière un peu hipster, il n’est même plus si cool que ça. C’est une bonne chose lorsqu’il s’agit de choisir une pile technologique : vous voulez quelque chose d’éprouvé. Et Rails est exactement cela. Nous avons récemment écrit un article parlant de la grande variété d’interprètes et de runtimes Ruby qui sont maintenant disponibles.
Marketing
Je sais, je sais. En tant que professionnel de l’informatique, je devrais vraiment valoriser les choses » sérieuses » et ignorer les » paillettes « . Cela peut sembler superficiel, mais regardons les choses en face :
- Par rapport à la concurrence, le site Rails a l’air bien.
- Le premier screen cast de Rails, à l’époque, était tout simplement époustouflant. Elle n’a peut-être pas l’air aussi impressionnante aujourd’hui, mais rappelez-vous que la seule raison pour laquelle nous connaissons tous Java est que tout le monde était tellement enflammé par la possibilité d’exécuter une applet Java dans le navigateur. Il s’est avéré que ce n’était pas si important après tout, mais cela a tout de même permis de faire connaître Java. De même, ce screencast de 15 minutes sur le moteur de blog a été un énorme succès qui a enthousiasmé beaucoup de gens.
Il ne s’agit même pas de vanité, mais d’engager autant de personnes intelligentes que possible pour apporter de l’eau au moulin. Lorsque l’on envisage des frameworks, le meilleur endroit pour se trouver est dans la foule. Choisir un framework sur lequel ces personnes intelligentes se concentrent signifie simplement que beaucoup plus de terrain est déjà couvert pour vous. Et cela m’amène à mon prochain point.
(Ne pas) réinventer la roue
J’ai un faible pour les petits frameworks. J’aime quand je peux comprendre ce que fait un framework particulier et pourquoi. En ce sens, Rails est quelque peu gonflé, et même écrasant par moments.
Le dilemme ici : combien de fois voulez-vous écrire les mêmes choses encore et encore ? Une partie peut être réécrite mieux, j’en suis sûr, mais cela prend du temps – beaucoup de temps. Plus vous permettez à Rails de faire pour vous, moins vous avez à vous soucier de réécrire ou de réimplémenter vos fonctionnalités.
Rails est (comme on dit) » batteries incluses « . Ce n’est pas une bonne chose si vous êtes adepte de la sparsité ou si vous ressentez le besoin d’avoir une connaissance approfondie de la façon dont tout fonctionne. En pratique, si vous laissez tomber vos craintes, cela semble fonctionner. Rails dispose de valeurs par défaut raisonnables pour presque tout ce dont vous avez besoin et est suffisamment modulaire pour éviter de vous coincer.
Conclusion
Demandez-vous à nouveau pourquoi utiliser Ruby on Rails ? Rails convient à la fois aux sites Web publics de pointe qui rivalisent avec les applications JavaScript à page unique, et aux applications complexes de systèmes centraux d’entreprise qui ont généralement l’air un peu plus » moches » (avec une interface utilisateur plus générique et de moindre fidélité), mais qui compensent cette imperfection par une tonne de règles et de logiques métier compliquées. Son avantage est qu’il est polyvalent et capable de rivaliser à la fois avec les plus élégants et les plus puissants.
Pour la plupart des problèmes courants, Rails dispose d’un outil à votre disposition presque dès la sortie de la boîte, avec une documentation qui est systématiquement supérieure à la moyenne (d’une manière ou d’une autre, l’équipe centrale de Rails a persuadé les contributeurs qu’écrire de la documentation est cool (même si nous savons tous que ce n’est pas le cas), ce qui a conduit à des docs bien écrits, concis et permettant de gagner du temps).
Quand vous mettez de côté les licornes et les câlins du vendredi, vous vous retrouvez avec un framework puissant que vous pouvez utiliser à la fois pour votre futur game changer et votre prochain site d’entreprise moyen. Et avec votre pool de joyaux haut de gamme, vous avez au bout des doigts un arsenal qui met en œuvre certaines des idées les plus brillantes de la programmation informatique. Sans chichi.