Introduction à Ruby et Ruby on Rails

Introduction

Dans cette seconde partie, je ne vais traiter que de Ruby et Ruby on Rails. J'ai présenté déjà les outils et les protocoles derrière le web. Je vais maintenant tenter de présenter un nouvel outil qui est, à mon goût, une grande évolution pour le développement web. Je n'engage personne à me suivre s'il n'est pas d'accord ; je vais vous montrer ce que Rails sait faire et vous pourrez juger vous-même. Je vais essayer de ne pas être outre mesure partisan dans cet article, pour vous laisser l'espace d'un jugement personnel et fondé.

Je suis désolé pour les non-initiés, cet article va certainement être difficile d'accès voire tout à fait inintéressant pour vous. J'ai tenté d'être le plus clair et exhaustif pour comprendre les notions abordées. J'essaierai, à l'avenir, de faire des articles moins spécialisés !

Ruby

Tout d'abord Ruby ! pour vous mettre un peu dans le bain.

OO

Ruby est un langage résolument Orienté Objet et ce dès le début. Il a été conçu par Yukihiro Matsumoto, dit Matz, un développeur japonais. Il a commencé à écrire ce langage en 1993 car aucun ne lui convenait tout à fait. D'autre langages auparavant ont été créés dans une orientation objet forte, voire très forte (ex. SmallTalk). Et nombre d'autres ont reçu des patchs de programmation orientés objet (ex. C++).

Dans Ruby tout est un objet.

Une classe est un objet. Un type est un objet. Une instance de classe est un objet. Une methode est un objet.

Exemple :

Langage élégant, concis et lisible

Un des principaux intérêts de Ruby est sa lisibilité et sa relisibilité (si ce mot existe). Revenir sur un script (eh oui c'est un langage interprété) après quelques mois voire quelques années ne pose pas de problèmes. Et même lire le code d'un autre est vraiment aisé. Et ce n'est pas rien !

Ruby est, comme tous les langages, basé sur nombre d'obligations d'écriture, mais c'est pour autant un langage très souple. Il y a beaucoup de manières d'écrire la même chose (ce n'est pas un langage qui a pour objectif le “one-way” de Python) mais il y a aussi beaucoup de conventions, non obligatoires, instaurées par la communauté pour que la lisibilité et la concision du code reste optimale.

Enfin il n'est pas rare que le code de ruby soit très concis et que les méthodes soient constituées de 1, 2 ou 3 lignes. On peut enchaîner élégamment les méthodes ensembles.

Exemple :

Communauté active et agréable

Ce qui est bien avec Ruby, et c'est aussi le cas avec Rails, c'est qu'il y a une communauté heureuse autour de lui. Quand je suis arrivé dans la communauté, j'ai eu la même impression que quand je suis arrivé sur la plate-forme Mac. On se sent bien. On est soutenu, aidé, les problèmes sont résolus, des articles aident à tous les niveaux.

Les programmeurs Ruby sont des passionnés.

Ruby évolue relativement vite et de manière très intelligente. Les ajouts au langage sont minutieusement pesés. Comme le cœur du langage et la bibliothèque standard sont déjà vastes et que la communauté (qui n'est pas aussi ample que sur Java ou Python par exemple) est très active, on trouve de nombreuses bibliothèques libres de grande qualité.

Entre RDoc, pour la documentation du langage, ruby-forge pour le développement de code libre et Ruby Gems qui permet de télécharger ces bibliothèques et les maintenir à jour, la communauté est désormais solidement installée et prête à se développer encore.

Hashs et Blocks

Parmi les bonnes choses de Ruby, il y en a 2 qui sont vraiment sympathiques : les hashs et les blocks.

Les hashs sont des tables, mais qui au lieu d'être indexées numériquement (de 0 à x) sont indexées par une chaîne de caractères.

Exemple :

Les blocks sont des bouts de code qui vont être, littéralement, envoyés à la méthode qui les précède.

Exemple :

Nous avons déjà vu des blocks en action : entre do et end

Mais nous pouvions l'écrire ainsi :

Ou ainsi :

Ou enfin :

Vous montrer ces 4 manières différentes n'est pas particulièrement utile pour décrire les blocks. Je tenais à vous montrer ici un des plaisirs que j'ai avec ruby : écrire do…end est plus élégant, plus lisible, plus sensé, à mon goût, que {}. Un code avec moins de signes barbares ($//] et moins de MAJUSCULES partout, c'est tout simplement plus reposant pour l'œil. Je pense que c'est extrêmement important d'écrire un code agréable à lire, concis et clair. Nous reviendrons un peu plus tard sur la notion de “beauté” du code avancée par le créateur de Rails et vous remarquerez que je suis assez d'accord avec lui.

Pour en revenir aux blocks :

La méthode each() va prendre le block qui le suit et l'exécuter tant qu'il trouve des entrées dans la valeur (en l'occurrence une variable locale) qui le précède. each() va successivement prendre “Suisse”, “France” et “Belgique” et les faire glisser dans le block qui le suit.

Cet aperçu des blocks et des hashs est extrêmement mauvais. Mon explication fut succincte et certainement peu claire pour beaucoup mais je souhaitais faire sentir aux programmeurs qui me lisent un petit morceau de l'étendue des possibilités des blocks. Pour comprend un peu mieux, Programming Ruby de Dave Thomas, Chad Fowler et Andy Hunt aux éditions Pragmatic Programmer.

Nommage

Un dernier point de Ruby semble relativement important pour comprendre la suite, le nommage en Ruby (et donc en Ruby on Rails).

Variables locales et méthodes :

Variables globales :

Variables d'instance :

Variables de classe :

Constantes ou noms de classes :

Ruby on Rails

Ruby on Rails est un framework web open source qui reprend soigneusement les principes de concision et de lisibilité de Ruby. Ruby est à tous les niveaux du code, de la configuration (le peu qu'il en est) au code dynamique dans le HTML. Ruby est un langage très clair et Rails exploite ses nombreuses possibilités de clarification du code.

Histoire

Ruby on Rails est un framework web libre issu d'une “petite” entreprise de développement web très célèbre : 37signals, basée à Chicago. J'ai déjà un peu expliqué la genèse de Ruby on Rails dans la première partie de cet article, je ne vais pas y revenir.

Communauté et développement

La communauté Rails est comme celle de Ruby ou celle du Mac, très agréable. Et ça c'est toujours un plus. Il faut dire, que ce soit pour Ruby ou pour Rails, une partie importante des développeurs utilise des Macs. Ça paraît assez logique : Ruby et Rails sont un langage et un framework qui cherchent toujours à atteindre la meilleure solution possible. Arriver à l'essentiel, comme le dirait Jonathan Ive… Je ne sais combien de posts j'ai lu, où le blogueur parlait d'une ligne de code, qui marchait, sur laquelle il s'était arraché les cheveux une partie de la nuit parce qu'il ne la trouvait pas assez jolie.

Sur ce, je reviens sur l'idée de David Heinemeier Hansson (DHH pour les intimes), le créateur de Rails : le code doit être beau. Selon lui, la production d'un beau code rend un développeur heureux. Ça paraît vraiment idiot, mais c'est assez vrai… Quand on a fini une partie de code et qu'on la regarde en se disant que c'est ça, que là on a fait au mieux, que c'est très clair, on est content. C'est la première fois que ça m'arrive aussi clairement, avec Ruby et avec Rails.

Les deux communautés revendiquent d'ailleurs que développer avec leurs outils remet du plaisir dans la programmation. Et je dois avouer que je m'amuse pas mal. Beaucoup plus qu'avec PHP ou du CSS…

Enfin Rails a actuellement une communauté très active. Le cœur du développement de Rails est composé d'une douzaine de développeurs et plusieurs centaines d'amateurs qui participent à l'enrichissement du framework. On pourra remarquer dans la communauté, comme dans la communauté Mac, un certain nombre de passionnés relativement désagréables, qui traînent à droite, à gauche, avec des airs de je-sais-tout condescendant. C'est un fatalité à laquelle il est prévenant de toujours rester insensible.

Esprit

Ce framework est, selon le souhait de son créateur, un framework qui a une “opinion”. Je comprends bien que ça ne semble pas vouloir dire grand chose… Cela veut simplement dire que Rails a une façon particulière de penser et, s'il permet de faire les choses de nombreuses manières différentes comme ruby, il y a en général une bonne manière de faire qui est vivement conseillée. Il est fait certains choix au niveau du framework qui poussent à vraiment respecter les conventions.

Aussi ce framework évoluera selon le bon plaisir de DHH, qui est un peu comme Steve. Il a l'air assez difficile à vivre, d'avoir une opinion forte et de se conduire en dictateur salvateur. C'est tout son charme. En tout cas, rails n'évoluera pas sur certains aspects que DHH considère comme étant trop “business-logic”, c'est-à-dire qui répondent à des problèmes de développement à un trop haut niveau. Par exemple Rails n'intégrera pas de multilinguisme pour un moment. Attention, il est évidemment possible de faire du multilinguisme dans Rails mais ça se fait avec des plug-ins et c'est relativement facile. Pour DHH il n'existe pas à ce niveau un solution suffisamment satisfaisante pour qu'il l'adopte et l'internationalisation est une question au niveau “business” selon lui.

“Convention over Configuration”

C'est l'un des leitmotiv de Rails. On préfèrera, à des pages et des pages de configuration en XML (cf. J2EE), des conventions. Il y aura donc des règles assez strictes qui imposent au programmeur une certaine rigueur. Mais c'est pour son bonheur…

Il sera toujours possible de contourner les limitations, d'où le “over”, et faire du Ruby. C'est les conventions et quand celles-ci sont insuffisantes pour un problème particulier on pourra les contourner. Cela n'arrive pas tant que ça si l'on s'applique et que l'on ne fait pas des choses très très particulières.

Il est bon de savoir que parmi les petits plus de Ruby, on peut modifier les classes et les méthodes qui ont déjà étés déclarées. Et donc on peut redéfinir tout le comportement du langage selon ses besoins.

Supprimer le choix quand il n'est pas nécessaire

Un dernier point important de Rails est que c'est un framework qui veut supprimer un maximum de choix possibles pour le développeur. Par exemple : la structure des répertoires d'une application Rails est toujours la même et tous les fichiers et les dossiers de l'application sont générés, souvent vides, pour que le programmeur n'ait qu'à les remplir, sans pouvoir se tromper de répertoire.

Je vais rapidement décrire les dossiers de base d'une application rails.

app : c'est ici que se trouve votre application.

Vous voyez les Contrôleurs (controller), les Modèles (model) et les Vues (views) qui sont les gardiens principaux du code de votre application. Nous reviendrons plus en détail sur ces composants.

components/ : on peut mettre ici le code d'actions qui pourront être appelées pour alléger le code des actions répétitives.

config/ : c'est ici que se trouve toute la configuration de Rails

En gros, trois fichiers importants :

database.yml où vous allez dire à Rails comment se connecter à la base de données,

environment.rb et le dossier environment où l'on va pouvoir préciser les caractéristiques de son environnement (on peut créer différents environnements ; à la base on a development, test et production ; Rails intègre, comme vous pouvez le voir, un environnement de test) si nécessaire (le peu de configuration se fait de manière très lisible, pas question de XML)

et routes.rb vers lequel nous reviendrons plus loin.

db/ : ici vous mettrez les définitions sql de votre base de donnée.

doc/ : ici vous mettrez la documentation de votre code, qui sera générée automatiquement au format HTML (RDoc) d'après vos fonctions et les commentaires que vous aurez placés dans le code.

lib/ : ici vous mettrez de larges morceaux de code que vous réutilisez entre vos différents projets. Comme des plug-ins mais plus pour un code non issu d'un tiers.

log/ : vous trouverez ici tous les logs de l'exécution de vos applications. Selon l'environnement, la taille et la teneur du programme, le log sera différent.

public/ : ce répertoire est votre répertoire web de base. Vous mettrez ici des pages statiques, vos images, vos fichiers, votre CSS et votre JavaScript.

script/ : est un répertoire de scripts utiles au développement de l'application.

test/ : Rails a donc un environnement de test intégré. Les tests sont très vivement conseillés sous Rails. On vous donne tous les outils et l'espace pour réaliser des test. On peut faire sous Rails des tests fonctionnels, unitaires et depuis la version 1.1 des tests d'intégration.

tmp/ : ici se logent des fichiers temporaires tel le cache.

vendor/ : enfin ici on trouve le code tiers, notamment le code des plug-ins

MVC – Model View Controller (Modèle Vue Contrôleur)

Rails a été développé dans une architecture MVC. Cette notion n'est pas très complexe mais assez difficile à cerner. L'idée est que l'on va diviser le travail de notre application web en plusieurs morceaux pour clarifier le développement et permettre une réutilisation efficace de code récurrent.

Dans la partie modèle on va mettre tout ce qui est "données". Concrètement, c'est en général une définition de la base de donnée. Dans rails on ne définit pas vraiment la base de données mais on va créer des classes qui auront transformé les tables de la base en objets ruby. Le modèle est géré par le module Active Record de Rails.

La vue va gérer le rendu des pages. On y trouvera donc le HTML avec des balises Ruby imbriquées, qui donneront le dynamisme aux pages. La Vue est générée par Action View.

Enfin le contrôleur est la base de notre application, là où se trouve toute la logique de l'application, là où l'on trouvera aussi le plus de code ruby.

L'intérêt d'une telle architecture vient du fait que l'on va pouvoir réutiliser aisément telle action d'un contrôlleur dans plusieurs vues, ou que l'on pourra utiliser telles infos de la base de données à différents endroits, de différentes manières, sans écrire beaucoup de code. Le deuxième intérêt évident est que c'est plus logique, plus lisible, les choses sont mieux rangées.

Quand une application Rails reçoit une requête, par exemple http://www.votresite.com/admin/page/1/, c'est le contrôleur, directement, qui va recevoir la demande. Rails va chercher dans notre code le contrôleur « admin » (dans le fichier app/controllers/admin_controller.rd), l'action « page » (qui se trouvera dans ce fichier) en envoyant comme argument l'id 1.

Rails va aller chercher dans la base de donnée les données dont il a besoin pour cette action (imaginons qu'on a demandé de modifier la page ayant pour id 1) et va renvoyer à l'internaute une page avec le html contenu dans le fichier app/views/admin/page.rhtml.

Le fonctionnement décrit ainsi n'est pas très clair, mais j'écris la fin de cet article en vacances (enfin !) avec un PC. Je vous aurais fait un magnifique schéma avec Omnigraffle. Désolé !

Active Record

Active Record est un module particulier dans Rails. C'est un module de mise en relation objet-relationnel (ORM) à part entière. On peut l'utiliser sans Rails. Il existe de nombreux ORM et celui de Rails suit à peu près le modèle standard. Les tables de la base de données correspondent à des classes Ruby et les colonnes et les lignes des tables correspondent à des objets Ruby.

Donc pour dire à Rails qu'il existe telle table dans la base de données, il suffit de créer une classe. Par exemple la classe Page (dans le fichier app/models/page.rb ; remarquez la majuscule car il s'agit d'une classe, voir ci-dessus l'intro sur ruby). Puis Rails, malin qu'il est, va de lui-même regarder la base de données pour trouver toutes les colonnes qu'il contient. Pas besoin de définir les colonnes, ni leur type. La convention (Convention over configuration) veut que les tables d'une application Rails soient au pluriel et les modèles qui les dirigent soient au singulier. La table correspondant à la classe Page s'appellera donc « pages ». Cette convention a sa logique mais si ce n'est pas la vôtre, vous pouvez dire à Rails que telle classe appelle telle table très facilement.

Active Record a beaucoup de qualités et de fonctions très utiles et très simples à utiliser. Je vais juste revenir sur 2 d'entre elles.

Les tables jointes sont un classique des bases de données. Si l'on veut par exemple relier les articles d'un blog à des catégories, c'est très simple. On aura donc une classe Article reliée à une table articles et une classe Category reliée à une table categories (attention ! Rails gère les pluriels irréguliers en Anglais uniquement : Person => people…)

On définira dans la classe Article la relation qu'il a avec les categories ainsi (aucun code supplémentaire n'est requis) :

et on définira la classe Category ainsi :

Dans la table articles il faudra rajouter une colonne category_id (N.B. : toutes les tables doivent avoir une colonne clef primaire ayant pour nom « id »)

Puis on appellera dans notre contrôleur tous les articles de la catégorie « Humeurs » (ayant pour id 3 par exemple)

Toutes les requêtes SQL sont gérées par Rails. C'est quand même très simple (pour ceux qui ont des notions de programmation…), non ? Puisqu'on a affaire à du Ruby on peut ainsi enchaîner les commandes pour qu'elles soient plus concises et tout de même claires.

Le deuxième point que je souhaitais développer ici, afin de vous montrer une petite partie de la puissance de Active Record, c'est la validation. Car Active Record peut vérifier si les données qui vont être transmises à la base sont celles attendues. Il est assez logique que ce soit au moment de l'enregistrement des données que l'on vérifie les donnée fournies par l'utilisateur.

Pour vérifier si un utilisateur saisit bien un titre et un texte pour chaque article, il suffira de rajouter à notre classe Article une ligne de code :

Si l'utilisateur ne saisit pas un des deux, un message d'erreur lui sera retourné. Rails gère ce système tout seul mais il est possible de paramétrer entièrement la validation et son affichage pour l'utilisateur si l'on souhaite quelque chose de plus évolué.

Action Pack : Action Controller

Action Controller fait partie du module Action Pack, comme Action View. Tous deux ne peuvent pas vraiment être utilisés en dehors de Rails, contrairement à Active Record. Cela ne veut aucunement dire qu'ils ne sont pas puissants, mais qu'ils sont faits pour travailler ensemble et de préférence avec Active Record.

Comme je vous l'ai déjà dit, c'est dans le contrôleur et donc dans Action Controller que se trouve toute la logique de l'application web. Je ne pourrai pas tout dire de ce module non plus, puisque la limite du développement possible ici est celle de Ruby. Mais je vais quand même essayer de présenter très rapidement le fonctionnement général du contrôleur et quelques-unes des aides que Rails propose avec ce module.

Nous avons vu précédemment le fonctionnement basique du module contrôleur. On a donc autant de Controllers (qui sont des classes Ruby) que l'on a besoin, dans lesquelles on a des actions (qui sont des méthodes Ruby). Voici comment s'écrit le contrôleur de notre premier exemple (http://www.votresite.com/admin/page/1/) :

Rails va utiliser l'id « 1 » qu'il a trouvé dans l'adresse qu'on lui a transmise, pour chercher dans le modèle « Page » la bonne page.

Si l'on définit une action index ainsi :

On y accèdera ainsi : http://www.votresite.com/admin/ (en réalité http://www.votresite.com/admin/index.html). La logique des adresses et leur rapport avec les contrôleurs et les actions est donc très logique et simple.

Si l'on veut personnaliser ces adresses, Rails nous donne un outils très puissant, les Routes. Les Routes sont paramétrées dans le fichier config/routes.rb. On peut envoyer n'importe quelle adresse vers n'importe quel couple contrôleur-action. Ainsi on n'a pas à fouiner dans le routage de notre serveur, ce qui n'est pas toujours une partie de plaisir, et l'on peut créer des routes plus complexes. Voici la route de base que nous avons décrite précédemment :

Action Controller est vaste et je ne pourrai pas tout décrire de manière satisfaisante. Mais Rails gère entre autres dans ce module les sessions, les cookies et le cache sur plusieurs niveaux, des filtres de vérifications post- et pré-action (par exemple avant d'accéder au contrôleur Admin, il faudra être identifié), etc.

Action Pack : Action View

Action View est encore un outil puissant pour la simplicité et la non répétition de code (incroyablement important pour le HTML !). Action view est capable de générer, à la base, des pages html (rhtml) et le xml (rxml) pour le flux Rss notamment. On peut rajouter d'autres formats tel le pdf par un plugin trouvable sur internet.

Le code inséré dans le html ici n'est autre que du Ruby. Un, le Ruby c'est un langage très lisible ; et deux, Rails fournit beaucoup d'aides à l'écriture, donc le fait d'utiliser un langage de programmation ne pose pas de problème aux graphistes qui auraient à écrire les pages rhtml. Faire une boucle sur tous les titres des articles renvoyés par le contrôleur (@articles) s'écrit ainsi :

Remarquez les deux conteneurs Rails <% … %> et <%= … %>. Le premier est là pour la logique et le deuxième retourne ce qu'il y entre les balises. Il y a toujours de la logique dans les vues et la manière dont le fait Rails est malgré tout relativement agréable.

Si l'on veut que le titre ne fasse que 15 caractères et prenne une majuscule, il suffit de l'écrire ainsi :

Parmi les petits plaisirs de Action View on trouve des générateurs de formulaires très évolués qui permettent de récupérer facilement des entrées utilisateur, un assistant de pagination simple à utiliser, des « templates », des « helpers » personnalisés (tels les capitalize et truncate ci-dessus, qui sont eux intégrés à Rails) et des appels à des morceaux de code répétitifs. Pour appeler un morceau de code récurrent, il suffit d'appeler un fichier précédé d'un blanc (en l'occurrence _form.rhtml) souligné ainsi :

On peut passer des arguments à ces morceaux de code. On peut également appeler des composants qui sont des morceaux de code plus évolués.

On pourrait encore passer des heures à décrire ce module mais je tente de rester à une présentation simple de ce qu'est rails.

Action Mailer, Action Web Service et Active Support, Ajax

Rails comporte encore 3 modules et des petits plus sur lesquels je vais passer très rapidement ci-dessous.

Action Mailer : envoyez et recevez des emails (html et texte) sans effort. Action Mailer mériterait encore une description de 3 pages. Le fait de pouvoir recevoir aisément des emails et les traiter est très sympathique.

Action Web Service : créez des Web Services sans efforts.

Active Support : un composant que Rails utilise beaucoup mais qui n'est pas directement utilisé par le développeur. Il offre au développeur quelques méthodes de gestion du temps et autres aides utiles.

Ajax : même si ce point est essentiel dans le développement d'applications web et de sites web modernes, son implémentation mérite de maîtriser un minimum Rails et je ne pourrai pas vous faire d'exemple clair. En tout cas sachez qu'il n'est pas nécessaire d'écrire une ligne de JavaScript pour faire des appels Ajax et une série importante d'effets. Il existe depuis la version 1.1 de rails un nouveau composant Ajax, les RJS, qui autorise plusieurs modifications d'une page, à différents endroits, en une seule requête. Rails utilise parmi les meilleures bibliothèques Ajax actuelles, c'est-à-dire Prototype et Script.alici.us (voir script.aculo.us pour voir tous les effets possibles). Les développeurs de ces deux bibliothèques font partie du Core development Team de Ruby on Rails.

Conclusion

Nous avons donc maintenant fait un vrai petit tour de Ruby on Rails. Je n'ai peut-être pas suffisamment développé certains points mais en faire plus eût été trop, c'est maintenant à vous de découvrir la beauté de RoR si vous êtes intéressé par le développement d'applications web. Vous trouverez au bas de cet article une série de références pour approfondir le sujet.

Enfin, je suis désolé pour ceux qui n'ont pas bien tout suivi. Je tenais à présenter à des passionnés d'informatique ce nouvel outil de développement, qui fait du bruit en ce moment mais qui est assez mal connu. Comme dans la communauté Mac, certains crient sur les toîts avoir le meilleur outil entre les mains en narguant les autres qui du coup, vexés, ne daignent pas regarder plus avant le produit.

Ruby on Rails ne deviendra peut-être pas le prochain « PHP » (veuillez excuser la comparaison entre un framework et un langage) mais le voulons-nous ? Voulons-nous que tout le monde passe au Mac ? Pourquoi pas mais pas à n'importe quel prix. Rails devrait rester à un niveau gérable, comme le Mac, et c'est plus une force qu'une faiblesse. L'amélioration du framework en sera certainement meilleure et plus réfléchie.

Cuk est en endroit où l'on parle de tout et il s'agissait d'une des meilleures tribunes qui soit pour ce genre d'article. Merci encore à toi François de m'avoir permis de publier cet article.

Je vais essayer de continuer à vous donner des nouvelles du web. Je reviendrai sur les nouveautés, passerai en revue les nouvelles applications et de temps à autre ferai un état des lieux de l'internet.