Documentaire sur Ruby on Rails [vidéo]
(youtube.com)- Le point de départ de Rails naît pendant le développement de Basecamp chez 37signals, lorsque David Heinemeier Hansson crée lui-même en Ruby les outils dont il a besoin
- La collaboration entre Jason Fried et David commence en 2001 par une question sur PHP publiée sur le blog de 37signals, puis mène au développement du backend de Basecamp et à l’extraction de Rails
- Rails a cherché à combiner, dans Ruby, la rapidité de développement web de PHP et la rigueur de la conception orientée objet à la Java ; sa forme essentielle se construit entre l’été 2003 et le lancement de Basecamp en février 2004
- Sa diffusion initiale s’appuie sur un produit réel, Basecamp, une démo de 15 minutes, des comparaisons avec Java et la réputation de 37signals ; les premiers contributeurs, dont Jamis Buck, Jeremy Kemper et Tobias Lütke, ainsi que la Rails core team, se constituent alors
- Après sa publication en open source sous licence MIT, Rails garde le cap consistant à permettre à de petites équipes de construire de grandes applications web, grâce à des cas d’usage à grande échelle comme Shopify et GitHub et à une communauté active depuis 20 ans
La rencontre entre 37signals et David Heinemeier Hansson
- En 1999 ou 2000, Jason Fried dirige une agence de web design appelée 37signals et développe en PHP, en side project, une base de données de livres en ligne nommée Single File
- Il apprend PHP avec des livres et avance assez bien, mais finit par bloquer sur certains points ; à une époque où il n’existe pas d’espace de réponses comme StackOverflow, il demande de l’aide en ligne
- David Heinemeier Hansson, qui travaille dans le web à Copenhague, au Danemark, lit régulièrement le blog de 37signals, Signal vs. Noise, et répond en 2001 à une question de programmation de Jason
- La réponse de David est très détaillée, et Jason y voit non pas un simple commentaire, mais une réelle volonté d’aider
- Par la suite, David examine l’ensemble du code de Jason et lui dit en substance : « ce n’est pas terrible, recommençons » ; c’est à ce moment-là que leur collaboration démarre
- Les deux travaillent à distance pendant un certain temps, puis se rencontrent pour la première fois en personne près du Hancock building, à Chicago ; Jason se souvient que la tenue blanche de David était particulièrement voyante
Rails naît pendant la création de Basecamp
- 37signals gère alors les projets clients par e-mail et constate qu’il est difficile de suivre les versions des fichiers, les tâches restantes et l’état de préparation des lancements ; en 2003, l’entreprise décide donc de créer un outil de gestion de projet interne
- À l’époque, David est étudiant en école de commerce à Copenhague et ne peut travailler qu’environ 10 heures par semaine ; pour le développement du backend de Basecamp, il préfère recevoir un ordinateur portable Apple et du matériel plutôt que de l’argent
- David découvre Ruby grâce aux écrits de Martin Fowler et Dave Thomas, et se laisse séduire par ce langage venu du Japon dont le code se lit presque comme du pseudo-code
- Avant Basecamp, les travaux de 37signals utilisaient PHP, mais David décide de construire le backend de Basecamp en Ruby, un choix auquel Jason fait confiance
- David cherche dans Rails une combinaison de deux éléments
- une immédiateté permettant de mettre rapidement sur le web, comme avec PHP
- la rigueur intellectuelle de la conception orientée objet et des patterns qu’il voyait dans Java
- À l’époque, Ruby dispose de peu de bibliothèques ou de frameworks pour aider au développement web et à l’accès aux bases de données ; David crée donc lui-même les outils nécessaires pour construire Basecamp
- Entre l’été 2003 et le lancement de Basecamp en février 2004, le cœur de Rails prend forme ; après la sortie de Basecamp, David passe environ six mois à peaufiner le code et la documentation avant de publier Rails en 2004
Première publication, marketing polémique et formation de la core team
- En préparant la publication de Rails, David accorde de l’importance non seulement au code, mais aussi à la qualité de la documentation, et estime que la première version doit être suffisamment bonne
- Lorsque Rails commence à attirer l’attention, David cherche à défendre fermement l’orientation du framework et dit « non » aux demandes qu’il ne souhaite pas accepter
- Lors d’une des premières conférences Rails, en réaction à des exigences injustifiées et à des menaces d’échec, David utilise une diapositive « F()c% You » et affirme que l’open source n’est pas une relation commerciale et que les utilisateurs ne peuvent pas en dicter la direction
- Dans le même temps, Rails grandit en acceptant du bon travail envoyé par des milliers de contributeurs ; cela ne signifie pas que David rejetait les retours ou les contributions en tant que tels
- À l’International Ruby Conference de 2004, David présente Rails en se concentrant moins sur une démonstration de code que sur les raisons qui l’ont poussé à créer Rails et sur son objectif d’offrir une meilleure expérience aux programmeurs
- Pendant environ la première année, David est le seul à committer directement du code, tandis que les patches sont reçus par e-mail, via un Wiki, etc.
- Ensuite, les personnes ayant beaucoup contribué reçoivent un accès au codebase, ce qui donne naissance à la Rails core team ; Jamis Buck, Jeremy Kemper, Marcel Molina, Scott Barron, Sam Stephenson et Michael Koziarski font partie des premiers committers
- 37signals recrute certains membres de la Rails core team ou contributeurs Rails, et Jamis Buck devient le premier programmeur embauché par 37signals à l’époque où Basecamp commence à croître
La diffusion portée par un vrai produit et son écosystème
- La réputation de 37signals et le succès concret de Basecamp jouent un rôle majeur dans l’attention initiale portée à Rails
- David estime que, pour faire connaître un outil fondé sur un langage peu connu comme Ruby, il faut un cri fort plutôt qu’une présentation discrète ; il produit donc des contenus polémiques comparant une implémentation Java et une implémentation Rails
- La diffusion de Rails repose à la fois sur la démo de 15 minutes, sur les clients payants et la croissance de Basecamp, et sur du code réellement en production
- Tobias Lütke utilise Rails très tôt, au Canada, lorsqu’il crée une boutique en ligne de snowboards au moment où il cherche à lancer une entreprise ; ce projet, Snowdevol, débouchera ensuite sur Shopify
- Tobias se souvient que Rails lui a permis de construire seul le système et qu’il était alors plus productif que d’autres équipes qui développaient des boutiques en ligne
- Shopify est une entreprise influencée par Rails ; elle utilise encore aujourd’hui les dernières versions de Rails, la majeure partie de son codebase est en Ruby, et sa structure de dossiers de base est identique à celle d’une application Rails classique
- Les critiques selon lesquelles Rails « ne scale pas » existent depuis le début, mais Basecamp servait de vrais utilisateurs, et même avant l’apparition de cas comme Shopify ou GitHub, des réponses affirmaient que Rails était scalable dès l’origine
- Shopify est présenté comme un service à très grande échelle représentant environ 10 % du e-commerce mondial, et certains témoignages disent ne pas savoir quelle échelle Rails serait incapable d’assumer
Releases, fusion avec Merb et cap maintenu pendant 20 ans
- Dès le départ, publier Rails en open source s’impose comme un choix naturel ; David considère que, puisque les outils open source ont rendu possible son travail web, il doit lui aussi partager sa boîte à outils
- Des discussions ont bien lieu sur la possibilité de rendre Rails payant ou d’en faire un avantage concurrentiel exclusif, mais David décide que l’open source sous licence MIT est important et qu’il veut faire de Rails un immense succès
- L’outil créé par Jamis Buck pour déployer Basecamp prend ensuite le nom de Capistrano
- Les principales releases de Rails suivent le fil suivant
- Rails 1.0 constitue un point de départ important
- Rails 1.2 est considérée comme une release initiale stable et comme le moment où Rails montre les traits d’un framework web mature
- En décembre 2007, Rails 2.0 apporte notamment les sessions basées sur les cookies et les named scopes
- En mars 2009, Rails 2.3 est présentée comme une release dotée des outils nécessaires aux développeurs web modernes, des petites applications aux grandes
- À l’époque de Rails 2.3, jQuery est en train d’émerger, et Rails cherche à créer un espace capable d’absorber l’énergie du monde JavaScript
- Par la suite, le framework web Ruby Merb apparaît comme un concurrent plus rapide, plus léger et faisant moins de choses, et les développeurs Rails y voient des axes d’apprentissage
- Rails 3.0 résulte de la fusion avec Merb, ce qui nécessite un important travail de refonte des internes de Rails pour les rendre configurables, recombinables et modulaires
- La communauté Rails se concentre sur la possibilité, pour des personnes sans formation académique en informatique ou en programmation, de créer des applications web et de bâtir une carrière
- Rails cherche à abaisser la barrière d’entrée et à offrir ensuite un chemin pour devenir un programmeur de haut niveau dans une entreprise ou une industrie
- Comme le dit aujourd’hui le site web de Rails, Rails est un framework qui permet à de petites équipes d’aller de « Hello World à l’IPO », et la communauté comme la qualité du codebase sont jugées meilleures que jamais
1 commentaires
Commentaires sur Hacker News
J’ai vraiment beaucoup aimé ce documentaire, et le point de vue du framework porté par une seule personne ressortait bien à travers l’histoire personnelle de Toby chez Shopify
« From Hello World to IPO » était aussi excellent, et j’ai été particulièrement marqué par l’idée que, quel que soit le projet Rails qu’on ouvre, qu’il s’agisse du plus gros ou d’une nouvelle application, la structure est presque toujours la même
Dans l’environnement actuel, où les API et les stacks frontend s’entremêlent, ce type de cohérence n’est pas toujours garanti
Les évolutions récentes de Rails renforcent encore une base déjà solide, et le travail en cours ne concerne pas seulement Kamal, mais aussi des outils comme Solid Cache et Solid Queue pour simplifier l’infrastructure
Côté frontend, Turbo Morphing est actif, et pour les applications mobiles il y a aussi Turbo Native et Strada
J’ai déjà migré vers 7.1 et j’exploite une application mobile construite avec Turbo Native, et j’attends avec impatience de remplacer le cache Redis par Solid Cache pour simplifier davantage et garder les données en cache plus longtemps
C’est agréable de voir que la communauté Rails est toujours aussi vivante, et que les anciens comme les actuels membres de l’équipe core restent profondément liés au framework
Je n’ai jamais utilisé Rails, mais ce que je déteste vraiment dans l’écosystème Node.js, c’est l’absence de conventions claires
Même avec le même framework, la structure change tout le temps et c’est le bazar ; à la rigueur, la seule exception serait Next.js, encore que ce soit davantage côté frontend
Il y a aussi beaucoup d’outils de développement autour de Ruby et Rails qui apparaissent, donc j’espère encore de bonnes évolutions avec Rails 8.0 et Ruby 3.4
Découvrir qu’il est en fait le fondateur de Shopify et qu’il a une fortune de 5,5 milliards de dollars, ça m’a fait rire
Les développeurs ont vraiment tendance à sous-estimer cet aspect de RoR
Non seulement cela facilite l’onboarding, mais ça réduit aussi énormément le bikeshedding
Le MVC n’est peut-être pas ce qu’il y a de mieux pour tout, mais dans la plupart des cas c’est largement suffisant
Il faut vraiment que je regarde ça plus tard aujourd’hui
J’ai touché à plusieurs frameworks comme Laravel, ExpressJS, MeteorJS, Django et Flask, chacun avec ses avantages et ses inconvénients, mais j’ai toujours fini par abandonner, soit en suivant les tutoriels, soit en essayant à ma manière
J’ai commencé Rails il y a trois jours, et j’ai pu construire rapidement un MVP à montrer à un collègue pendant le week-end
Rails m’a permis de me concentrer sur ce que l’application doit faire plutôt que sur la manière de l’implémenter, et je comprends enfin pourquoi les gens l’aiment autant
Avec Rails, on est vraiment très productif
Mon plus gros reproche depuis longtemps, c’est que dès qu’on sort des conventions, la documentation manque ou les informations se contredisent souvent
Il peut être très difficile de trouver et de comprendre la « voie bénie », mais heureusement ChatGPT s’en sort plutôt bien pour donner un point de départ sur ce genre de sujet
C’était vraiment un excellent documentaire
J’utilise Rails depuis quelques années, et pour une petite équipe qui construit un produit et implémente de la logique métier en suivant des schémas bien établis, c’est extrêmement productif
Si vous êtes curieux de voir à quoi ressemble une vraie structure d’application Rails, je recommande de regarder la base de code de Jumpstart. C’est une très bonne ressource pour apprendre à structurer les choses
https://jumpstartrails.com/
En alternative, Bullet Train est aussi plutôt bien, mais ajoute beaucoup de bibliothèques sur mesure qu’il est difficile de considérer comme la « manière Rails »
https://bullettrain.co/
Je trouve que ce documentaire sur Rails, comme celui sur Elixir, n’a pas réussi à couvrir grand-chose
C’est trop court, ça effleure à peine l’histoire des origines avant de se terminer, et ça s’arrête avant d’atteindre les passages vraiment enthousiasmants
Au lieu de montrer à la communauté et aux non-initiés à quel point ces technologies sont formidables, cela semblait plus proche d’un exercice de valorisation de l’ego des intervenants
J’aimerais voir un documentaire de 1 h 30 sur Elixir et un autre sur Rails, qui aillent au-delà des compliments mutuels pour montrer les années de galère, les différentes façons dont plusieurs entreprises les ont utilisés, etc.
En gros, reprendre le format de Indie Game: The Movie serait bien plus captivant, et j’aimerais voir davantage de bons documentaires sur le logiciel
Il y avait beaucoup de petits fragments d’histoire difficiles à trouver ailleurs : à quel point l’approche de David était singulière, comment l’équipe Rails s’est formée autour de Toby et d’autres personnes, comment cela s’est combiné avec d’autres frameworks, etc.
J’aurais aimé que ce soit plus long, mais c’est déjà remarquable qu’ils aient réussi à faire ça
Je l’ai vu, mais je trouve qu’il ne montre pas suffisamment ce que Rails a accompli
Ruby on Rails a changé le paradigme de construction des applications web en faisant passer le développement d’une approche centrée sur les fichiers, comme avec PHP, JSP ou WebForms, à une approche fondée sur les routes et le modèle MVC, et aujourd’hui presque tous les vrais frameworks web adoptent cette méthode
Le documentaire ne parlait pas de cet aspect, mais ça restait malgré tout agréable à regarder
Cela dit, j’ai presque l’impression de devoir m’excuser de mettre Struts et Rails dans la même phrase, tant Rails a accompli bien plus
Les figures légendaires des débuts de Rails ont ouvert la voie à la manière moderne de développer des applications web
On peut presque dire qu’il y a eu un avant et un après Rails dans le développement web
À lire les commentaires, on dirait que Rails recommence à gagner un peu en popularité au-delà de son image de framework simplement ennuyeux mais solide
Rails, c’est une autre époque qui correspondait à mon parcours de l’époque, et ça me rappelle quand je faisais des choses plus amusantes et plus brutes
Ce que j’apprécie énormément dans Rails, c’est sa vision forte, et le fait qu’il ne soit pas devenu un énième framework obèse pour créer des applications « enterprise-grade »
C’est un framework vieux de 20 ans, mais qui n’a pas peur de changer radicalement avec son temps, et qui a encore quelque chose de punk comparé aux autres
Ça m’a réchauffé le cœur de repenser à mon propre parcours, quand j’ai commencé à utiliser Rails il y a 20 ans
https://twitter.com/buger/status/1723040883325460818
J’ai travaillé de 2015 à 2019 sur une très grosse application Rails en production, et le résultat, c’est que j’ai fini par aimer Rails mais par détester Ruby
S’il existait un Rails en TypeScript ou en Go, je ne vois quasiment aucune raison d’utiliser autre chose pour le backend d’applications web
La console Rails est l’un des meilleurs outils de productivité que j’aie jamais utilisés
Avec TypeScript, ce serait peut-être faisable en s’appuyant sur le REPL Node existant, mais si la console Rails est aussi utile, c’est au fond beaucoup grâce à Ruby lui-même
Les documentaires de Honeypot sont vraiment excellents, je les recommande vivement