Monter dans le train de Ruby et Rails

Première publication : 2009-11-13
Tags : railsruby

Lorsque j’ai plongé dans la communauté Rails il y a 3 ans, elle n’était pas aussi riche qu’aujourd’hui : moins de monde, de livres, de blogs, de documentation… Ça rendait les choses plus faciles car on trouvait assez rapidement les sources valables, mais en même temps il y avait beaucoup moins d’information disponible qu’aujourd’hui.

Je me suis dit que rassembler un peu mes sources et donner quelques conseils pouvait probablement aider des nouveaux venus.

Alors par où commencer ?

Contrairement à ce que j’ai fait, je pense qu’il faut commencer par aborder Ruby, en tant que langage.
Dans mon précédent article sur la comparaison de PHP/Symfony et Ruby/Rails, je disais qu’à mon avis, la principale force de Rails, c’est Ruby.

Ruby est un langage qui emprunte des concepts et tout un tas de mécanismes à d’autres langages, mais c’est aussi un langage qui étonne et surprend au début, par sa syntaxe et ses idiomes particuliers.
Pour éviter d’écrire du PHP ou du Java en Ruby, il est important de bien comprendre et intégrer le style Ruby ; la manière d’itérer dans un tableau, l’enchaînement des appels de méthodes, les blocks, l’absence de primitives, l’arborescence des types d’objets…

Mise à jour : En tout premier lieu, jetez vous sur l’excellent Try Ruby! (in your browser) qui vous permettra en une quinzaine de minutes de voir différents aspects du langage. Merci à NiKo qui m’a rappelé cet oubli impardonnable, ou plutôt cette disparition entre mon brouillon et la version finale de l’article.

Pour cela, je conseille de parcourir la documentation de Ruby. N’ayez pas peur, c’est beaucoup plus concis que celle de PHP ou Java.
Ruby est composé d’une partie “Core” et d’un ensemble de “Standard Libraries”.
Chaque type d’objet dispose de méthodes, documentées de manière très lisible, avec des exemples d’utilisation.
On peut donc “lire” ces fichiers de doc et comprendre par exemple tout ce dont est capable la classe Array, le fait qu’elle partage des comportements avec Hash, via le module Enumerable…
Les notions de manipulation/création d’objets personnalisés et d’instance de ces objets, l’héritage et la modularisation, la méta-programmation, l’introspection… sont des concepts majeurs, qui seront mieux expliqués dans des livres et/ou articles de blog.

Le livre The Well-Grounded Rubyist (par David A. Black aux éditions Manning) est probablement le meilleur pour accompagner le novice en Ruby, y compris sur les terres de Ruby 1.9

Être capable d’écrire des bouts de programmes ou algorithmes simples, du genre de ceux qu’on apprend en cours à la fac est l’histoire de quelques jours où ont doit s’efforcer de rester un peu à l’écart de Rails.
Un bon petit exercice peut être de prendre un script shell et de le re-coder en Ruby, comme par exemple lister des fichiers dans des répertoires, renommer/déplacer certains qui seraient passés dans des filtres…

Au mieux on aura assimilé Ruby, le plus vite on comprendra Rails.

Aborder Ruby on Rails, le framework de développement web

Pour commencer, je conseille la lecture de quelques articles :

En parallèle, plonger dans 1 ou 2 livres est une très bonne chose car on y est accompagné par des experts particulièrement pédagogues :

  • The Rails Way par Obie Fernandez, aux éditions Addison-Wesley, disponible en anglais seulement
  • et aussi le très officiel Agile Web Development with Rails (3ème édition) par Sam Ruby, Dave Thomas et David Heinemeier Hansson, aux éditions The Pragmatic Bookshelf. Il est disponible en français et en anglais

On ne peut pas passer à côté des screencasts de Ryan Bates (Railscasts.com) et ceux de Geoffrey Grosenbach / Topfunky (Peepcode.com).

  • les Railscasts sont gratuits. Un nouveau sort quasiment chaque semaine , il y a déjà plus de 180 épisodes, entre 5 et 20 minutes environ.
  • les Peepcode sont payants et plus rares, mais la qualité du fond et de la forme en fond une ressource fondamentale. Je conseille l’abonnement illimité pendant 1 an, ça vaut vraiment le coup.

L’idéal est probablement de les regarder en diagonale une 1ère fois, en partant des plus anciens, sans trop s’attarder sur les détails car Rails évolue très vite et certains épisodes sont totalement obsolètes au niveau de l’implémentation. Par contre les passer en revue permet de se rendre compte des tendances et des techniques clés. Personnellement, je les ai tous en permanence sur mon disque dur et j’y reviens souvent.

Pour suivre les publications de tous les producteurs de screencasts, il y a Learnivore (par Thibaut Barrère - @tbarrere) qui les recense tous.

Le bon dosage théorie/pratique

Le risque à partir bille en tête dans un projet concret après avoir lu quelques articles et synthèses de livres, c’est qu’on va se limiter à la surface des choses, on va mal utiliser les outils à disposition ou utiliser le mauvais outil pour le boulot.

Je ne préconise pas non plus de passer 6 mois à lire tous les livres, sans toucher au clavier, car on apprend énormément en faisant soi-même, en confrontant ses idées à la réalité des fonctionnalités qu’on veut mettre en œuvre.

C’est pourquoi je pense qu’il faut conserver une bonne part de son temps à l’apprentissage pur. Revenir à la doc du langage et tester des méthodes qu’on connaît mal ou dont on avait oublié l’existence, lire et essayer de mettre en œuvre les bonnes pratiques décortiquées par les experts…

Personnellement, je passe beaucoup de temps personnel à mon métier, mais c’est rare que je continue à la maison mon boulot de la journée. Je préfère utiliser ce temps pour mes lectures, mes recherches et tests… Ça me permet de prendre du recul et avoir une perspective plus large. Au final, c’est ma compétence et ma productivité qui croissent, même si je ne passe pas plus de temps à pisser des lignes de code.

Sur ces points, je conseille vivement la lecture de la série d’article de Jamis Buck intitulée There is no magic, there is only awesome où il livre ses clés de la compétence : connaître ses outils, son langage, ses librairies et sa communauté. (NB : le début de la 1ère partie est assez particulière, ne bloquez pas dessus, le reste est passionant).

Intégrer les tests dans son apprentissage

Je ne vais pas faire l’article du Test-Driven Development (ni du Behavior Driven Development), mais j’insiste énormément sur le fait qu’il ne faut absolument pas négliger cet aspect là. Il ne faut surtout pas sauter les chapitres où les auteur parlent des tests, en se disant qu’on y reviendra plus tard, quand on on maîtrisera mieux le langage et le framework, et ce pour 3 raisons.

  1. c’est très dur de revenir là dessus plus tard. On est vite pris dans la “production” et on a l’impression que c’est du temps perdu, ce qui est archi-indéniablement-faux.
  2. ça aide énormément pour apprendre car on est en permanence à décrire ce dont on a besoin et implémenter ce qui satisfait ces besoins. On décortique systématiquement ce qu’on écrit lors des phases de refactorisation…
  3. c’est un pan entier de la culture Ruby et des avantages qui sont à porté de main. Le négliger serait comme ne jamais utiliser les tableaux ; on peut s’en sortir sans, mais quelle difficulté et quel dommage.

Sur la question des tests, je conseille le superbe livre The RSpec Book” (toujours en version bêta, en cours d’écriture), par un collectif d’auteurs (dont David Chemlinski) aux éditions The Pragmatic Bookshelf.

Lire du code, encore et encore

Une fois qu’on a compris le langage qu’on va manipuler, il n’y a rien de mieux que de lire du code
NB : regardez la vidéo de la conférence de JEG2 sur ce sujet

On préfèrera lire du code brillant, mais il faut aussi lire du code commun, voir sale, ça permet de mettre en perspective ce qu’est un code beau, efficace, lisible. Et d’ailleurs, plus on en lit, plus on sait faire soi-même la différence. Ruby encourage tellement l’écriture de code lisible et concis que lorsque ça ne l’est pas, c’est mauvais signe.

Les librairies standard sont un bon point de départ. Le code est principalement de très bonne qualité (à quelques exceptions près) mais n’est pas non plus sur-compressé et sur-intelligent (ça n’est pas son but).
Le code interne de Rails (ou plutôt ses librairies principales, comme ActiveRecord, ActiveSupport…) est également une très bonne matière, mais comme tout bon framework, son code doit être le plus optimisé possible, le plus malléable et générique possible, au détriment de la clarté et de la transparence. On aura donc des fois du mal à démêler le fonctionnement de portion de code ou la méta-programmation et l’abstraction sont utilisés à plein régime.
Enfin, les librairies tierces les plus connues et utilisées sont de bonnes choses à lire. Leur succès au sein de la communauté est souvent signe de qualité du code.

Jamis Buck conseille de toujours lire le code d’une gem ou d’un plugin avant de l’installer et l’utiliser. Au mieux on aura parfaitement compris ce qu’il fait et comment l’utiliser à fond. Au pire on sera dégoûté de son fonctionnement et on le jettera aussitôt. Et souvent on se dira que ça vaut pas le coup de l’installer car on n’a besoin que de 10% de son code et qu’on ferai mieux de le recoder soi-même de manière plus adaptée à ses besoins.

Se tenir au courant de la vie de l’écosystème

Une fois qu’on a mise les pieds dedans et qu’on se dit qu’on n’a pas envie d’en sortir en courant, il faut bien se tenir à jour et continuer d’apprendre.

Pour ça je n’ai rien trouvé de mieux que de m’abonner à tout un tas de blogs et suivre pas mal de gens sur Twitter.

Avec un peu d’habitude on sait rapidement faire le tri entre ceux sur qui il faut se jeter sans attendre à chaque post et ceux qu’il faut garder dans un coin du radar car ils sortent de temps en temps un truc fort valable.

Je vous glisse ma liste de recommandations, à toutes fins utiles.

Les podcasts Rails Envy et Ruby5 permettent de suivre l’activité de la communauté Rails depuis de nombreux mois. À chaque épisode il y a les “show notes” pour retrouver ce qui a été évoqué.

Avec l’arrivée des listes sur Twitter, le mieux est de farfouiller dans les listes suivantes (dont la mienne).
En faisant des recoupements entre les personnes suivies, on se retrouve rapidement avec la crème de la communauté.

Voici ma liste de blogs et sites suivis via RSS. Ils ne sont pas tous très actifs (heureusement) mais contiennent tous des articles très intéressants.

Quelques mentions particulières :

  • Ryan’s Scraps ; Il décortique à l’avance les nouvelles fonctionnalités
  • A Fresh Cup ; Les trouvailles quotidiennes d’un développeur Ruby/Rails fameux
  • Giant Robots ; De très bons conseils et tutoriaux de la part d’une team qui produit beaucoup de très bons plugins/gems. Ils sont l’éditeur de Hoptoad (notifications d’exceptions)
  • Ruby Best Practices ; Les meilleurs pratiques en Ruby, très avancé.
  • Le blog de James Edward Gray 2nd ; Un développeur de très haut niveau qui poste des article très poussés sur les meilleures pratiques et des analyses de “produits”
  • The Rails Way ; Les bonnes pratiques Ruby et Rails par KOZ (Mickael Koziarski)
  • the { buckblogs :here} ; Le blog de développeur de Jamis Buck (état d’esprit, bonnes pratiques, analyses…)
  • The Journeyman Software Craftsman ; Le blog de Corey Haines sur son expérience de développeur itinérant. Beaucoup de réflexions et analyses sur l’attitude du développeur et les bonnes pratiques

Autres blogs et sites :

J’espère vraiment que cet article sera utile. Il ne reflète que mon avis et mon expérience.

Si vous avez des avis et des suggestions, n’hésitez pas à utiliser les commentaires pour ça.

Alain Régnier 2010-08-29 14:25:41

Bonjour, Merci pour ces infos claires et généreuses! Je suis débutant en programmation (et autodidacte), mais assez débrouillard. Par quoi faut-il commencer pour apprendre à programmer en Ruby? Je suis tombé sur votre blog parce que je cherchais la différence entre PHP et Ruby, c’est très clair. Est-il préférable d’utiliser MySQL ou PostgreSQL? Un ami m’a dit qu’il avait beaucoup de problèmes pour passer de Ruby 1.x à Ruby 2.x. Du coup, 1) faut-il directement apprendre en ruby 2.x? (Mon Mac avec Leopard a Ruby 1.8.6); 2) si on cherche à reprendre un projet écrit en Ruby 1.x, faut-il envisager de tout réécrire en Ruby 2.x? (et a fortiori Ruby 3.x)? Un GROS MERCI si vous pouvez répondre à ces interrogations (même si elles peuvent paraître naïves…

Jérémy Lecour 2010-08-29 17:30:27

Alain, pour commencer à apprendre Ruby, je conseille quelques ressources telles que Ruby Koans, Why’s (Poignant) Guide to Ruby ou The Well Grounded Rubyist.

Pour MySQL vs PostgreSQL, c’est surtout une question de besoins. MySQL ets plus répandu et plus connu, mais PostgreSQL a quelques fonctionnalités en plus.

Pour la question de version de Ruby, il n’existe à ce jour que Ruby 1.x (1.8.7 et 1.9.2 sont les versions les plus couramment utilisées). Ruby 2 n’est qu’à l’état de projets.

Si c’est de rails (le framework web écrit en Ruby) dont vous parlez, je conseille de commencer directement en version 3, qui devrait être en version stable d’ici quelques jours maxi. Vous trouverez quantité de ressources en ligne, synthétisées (liste non exhaustive) ici : http://weblog.rubyonrails.org/2010/8/28/rails-has-great-documentation

Bienvenu dans la communauté Ruby et Rails. N’hésitez pas à me questionner à nouveau, notamment via mon compte Twitter

Jordi Dosne 2011-07-29 16:24:03

Bonjour, Connaissez-vous un bon livre pour novice en Ruby, dans le genre de The Well-Grounded Rubyist mais en français ? Merci par avance!

Jérémy Lecour 2011-08-16 09:07:49

Malheureusement je ne connais pas de bon livre en français. Je préfère les lire en anglais quand ils sortent plutôt que d’attendre des mois/années sans certitude d’une traduction.

Aina Anjary Fenomamy 2011-02-04 15:20:41

salut,

Merci pour les conseils et références :) j’utilise Ruby on Rails depuis quelques temps maintenant et j’avoue que j’ai encore pas mal de chose à apprendre pour mieux utiliser l’outil. Ruby Toolbox est aussi une bonne documentation concernant les gems.