Quels sont les avantages de Ruby on Rails ? Après deux décennies de programmation, j'utilise Rails

Parfois, j'entends des gens se plaindre de leurs clients, dire qu'ils insistent pour utiliser Rails, qu'ils ont trop bu de Kool Aid. S'il s'agit de recruteurs, ils ont presque mal au ventre à l'idée de devoir trouver un autre développeur Ruby on Rails 'primadona'. Ensuite, 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, en tant que programmeurs, il semble parfois que nos clients n'en aient aucune 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 tout simplement pas". En fait, je pense que la plupart des clients connaissent très bien leurs options et pourtant ils décident toujours d'opter pour Rails.

Je vais essayer d'expliquer ce qui, à mon avis, rend Rails suffisamment avantageux pour être sérieusement envisagé pour une pléthore de projets et de besoins.

Avantages du rubis

Il est possible que personne ne connaisse les avantages de Ruby s'il n'y avait pas Rails lui-même. Certaines personnes aiment rabaisser Ruby en disant que c'est "si facile pour Ruby" avec son "chevalier en armure brillante appelé Rails" et que sans Rails, "Ruby ne serait pas pertinent". Je ne peux pas dire avec certitude si c'est vrai ou non, mais je sais que ce serait vraiment dommage si le monde manquait une langue aussi superbe. Le fait est que l'auteur de Rails a délibérément choisi Ruby, et son pari "sauvage" a payé avec un énorme intérêt. Ce qu'il a vu à l'époque, beaucoup d'autres peuvent le voir aujourd'hui. Ruby permet en quelque sorte aux programmeurs d'une manière particulière qui est si difficile à expliquer aux « masses non lavées ». Alors, pourquoi utiliser Ruby on Rails ? Ruby rend les programmeurs heureux, comme annoncé.

Alors que la plupart des développeurs conviennent que Ruby est pratique, certains le voient trop . Ils s'inquiètent de ce qui pourrait arriver avec toutes les libertés que Ruby permet, tout le potentiel d'abus. Permettez-moi d'illustrer avec quelques correctifs de singe:

 "1".to_i #=> 1 class String def to_i raise 'foobar' end end "1".to_i #=> RuntimeError: foobar

C'est aussi simple que cela : avec seulement cinq lignes de code, nous avons pris une classe existante et remplacé 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 end end "2".to_i #=> 0.8700000000000001

Juste comme ça, nous avons introduit une erreur dans la classe String qui pourrait être enveloppée et masquée par couche après couche de complexité.

Alors, vous pensez peut-être : tout le monde et leur mère peuvent-ils gâcher ma précieuse candidature ? Bien que ce comportement semble en effet effrayant, ce n'est vraiment pas le cas. En cinq ans d'utilisation de Ruby, je n'ai eu exactement aucun problème avec ce comportement. Cela peut sembler contre-intuitif, mais encore une fois, il en va de même pour la conduite de voitures à 60 MPH dans des directions opposées séparées uniquement 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 en forme de couteau. J'aime à penser que les adultes peuvent très bien manier les couteaux - la sécurité des enfants est pour, eh bien, les enfants (Tweet). Et être traité comme un enfant dans l'informatique vous laisse victime du paradoxe 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 que vous étiez trop dangereux. Bien sûr, aujourd'hui nous nous demandons « pourquoi utiliser Ruby on Rails » ; c'est donc un débat pour une autre fois. Certes, Ruby passe à côté de certaines fonctionnalités que possèdent d'autres langages (Lisp hmm, hmm). Dans l'ensemble, Ruby est proche du sommet du « continuum du pouvoir du langage ».

Mes premières années avec Ruby ont été une leçon d'humilité. J'ai tellement appris rien qu'en lisant le code des autres. Parfois, j'étais étonné; parfois, j'étais fou; mais finalement, cette connaissance m'a permis de communiquer avec mon ordinateur beaucoup plus efficacement qu'auparavant. Je me sens presque désolé pour d'autres langages « bureaucratiques » qui vous font sauter à travers des cerceaux juste pour le plaisir de sauter à travers eux, 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 tissé dans l'ADN de Rails au niveau le plus bas 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 annoncé comme une tente de Rails, donc cette affirmation n'est pas nouvelle, mais on m'a rappelé sa véracité tout récemment alors qu'un de mes amis a essayé de me montrer à quel point Hibernate était vraiment "cool". Il luttait. Je pouvais ressentir sa douleur car 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 dans Clipper Summer '87), j'ai une tolérance proche de zéro pour les complications inutiles. Et Rails obtient des scores très élevés dans ce département. C'est plus qu'une simple « convention plutôt que configuration » ; Je parle de tout l'état d'esprit pragmatique qui est très apprécié et imprègne la communauté Rails.

Expressivité

Rails est aussi proche de l'anglais que possible (sauf si vous utilisez COBOL). Il utilise ce qu'on appelle un DSL interne, étendant Ruby avec sa propre sémantique. Construire un DSL est toujours dangereux car vous développez effectivement un nouveau langage. Parce qu'il est interne, vous n'avez pas besoin d'utiliser un analyseur externe, mais dans un sens, cela ressemble à un nouveau langage. L'équipe Rails a trouvé un bon équilibre avec son DSL, l'utilisant là où cela a du sens et n'en exagérant que rarement, démontrant une excellente maîtrise de soi. Je pense que tout programmeur, quelle que soit son expérience Rails (et même certains non-programmeurs) pourrait comprendre ceci :

 class User < ActiveRecord::Base devise :database_authenticatable, :registerable validates_numericality_of :years_of_experience, :allow_blank => true acts_as_taggable acts_as_taggable_on :certificates, :expertise_kinds validates_presence_of :first_name, :last_name, :email has_many :translations has_attached_file :avatar, :styles => {:small => "240x240>"} has_attached_file :cv ...

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 réalisez qu'il ne s'agit que d'appels de méthode sans parenthèses, vous êtes prêt à partir. Pourtant, le Rails DSL donne l'impression d'être ce langage spécial pour décrire les exigences alors qu'en fait il ne s'agit que d'un nommage intelligent et de l'utilisation inhérente de l'excellente syntaxe de Ruby.

Communauté

Rails a une armée de committers qui s'assurent qu'il reste en parfait état. De nombreux projets mijotent avec l'âge, mais avec Rails, des étincelles jaillissent encore lorsque des décisions doivent être prises. On a l'impression que les mainteneurs se soucient (encore) 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 packages, RubyGems, comparable à CPAN en termes de nombre de packages - et compte tenu de l'âge de CPAN, cette affirmation est (pour le moins) très impressionnante. Rails a eu un bref dérapage lorsqu'il a essayé de créer ses propres "plugins Rails". Heureusement, cela n'a pas collé, donc RubyGems reste la source unifiée et superbe pour le 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é

Les rails ont fait le tour du pâté de maisons. D'une manière hipster, ce n'est même plus aussi cool. C'est une bonne chose lorsqu'il s'agit de choisir une pile technologique : vous voulez quelque chose qui a fait ses preuves. Et Rails n'est que cela. Nous avons récemment écrit un article sur la grande variété d'interpréteurs et d'environnements d'exécution Ruby qui sont désormais disponibles.

Commercialisation

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 avouons-le :

1. Comparé à la concurrence, le site Rails fait bonne figure.
2. Le premier casting d'écran de Rails, à l'époque, était tout simplement à couper le souffle. Cela n'a peut-être pas l'air si impressionnant aujourd'hui, mais rappelez-vous que la seule raison pour laquelle nous connaissons tous Java est que tout le monde était tellement excité par la possibilité d'exécuter une applet Java dans le navigateur. Cela s'est avéré ne pas être si important après tout, mais cela a quand même mis Java sur le radar. 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.

Ce n'est même pas une question de vanité; il s'agit d'engager autant de personnes intelligentes que possible pour mettre de l'eau dans le moulin. Lorsque les cadres sont pris en compte, le meilleur endroit où être est dans la foule. Choisir un cadre 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 point suivant.

(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é, voire parfois écrasant.

Le dilemme ici : combien de fois voulez-vous écrire la même chose encore et encore ? Certaines d'entre elles peuvent être mieux réécrites, j'en suis sûr, mais cela prend du temps - beaucoup de temps. Plus vous permettez à Rails de faire pour vous, moins vous aurez à vous soucier de réécrire ou de réimplémenter vos fonctionnalités.

Rails est (comme on dit) "piles incluses". Ce n'est pas une bonne chose si vous aimez la parcimonie ou si vous ressentez le besoin d'avoir une connaissance approfondie de la façon dont tout fonctionne. En pratique, si vous abandonnez vos peurs, cela semble fonctionner. Les rails ont des valeurs par défaut raisonnables pour presque tout ce dont vous avez besoin et sont suffisamment modulaires pour éviter de vous coincer dans une situation difficile.

Conclusion

Demandez-vous à nouveau pourquoi utiliser Ruby on Rails ? Rails convient à la fois aux sites Web publics à la pointe de la technologie qui concurrencent les applications JavaScript à page unique et aux applications de système de base d'entreprise complexes qui ont généralement l'air un peu plus "laide" (avec une interface utilisateur plus générique et moins fidèle), mais qui compensent cela tache avec une tonne de règles commerciales et de logique compliquées. Son avantage est qu'il est polyvalent et capable de rivaliser avec les élégants et les puissants.

Pour la plupart des problèmes courants, Rails a un composant à votre disposition presque prêt à l'emploi avec une documentation qui est constamment au-dessus de la moyenne (d'une manière ou d'une autre, l'équipe principale de Rails a persuadé les contributeurs qu'écrire de la documentation est cool (même si nous savons tous que c'est pas), conduisant à des documents bien écrits, concis et rapides).

Lorsque vous mettez de côté les licornes et les câlins du vendredi, vous vous retrouvez avec un cadre puissant que vous pouvez utiliser à la fois pour votre futur changeur de jeu et votre prochain site commercial intermédiaire. Et avec votre pool de joyaux haut de gamme, vous avez à portée de main un arsenal qui met en œuvre certaines des idées les plus brillantes de la programmation informatique. Sans chichi.