Matthieu Segret

Une chose qui a changé ma vie de développeur lorsque je suis entré dans le monde Ruby c’est la possibilité de déléguer l’administration de son application sur le cloud avec Heroku, Engin Yard ou Cloud Foundry.

L’administration système n’a jamais été une passion pour moi. Donc pouvoir déployer mes applications en un «git push» sur Heroku est un gain de temps considérables.

Si on ajoute à cela les services proposés sur le cloud (backup journalier de la base de données, mise en place de cron, monitoring des instances de production avec New Relic, gestion des erreurs avec Airbrake, mise en place de cache : Redis ou MemCache, création de certificats SSL ..) Tous ces services ne sont pas une exclusivité Ruby on Rails, mais avec Rails c’est souvent plug & play !

Je vous invite à lire les autres avantages de la série : les avantages de Ruby on Rails

Pour avoir pas mal utilisé Ant lorsque je faisais du Java, je me souviens du temps perdu pour débogguer mes scripts. Je me disais alors, pourquoi coder des scripts en XML ?

Avec Rake, je peux écrire mes tâches en Ruby. Comme Ant, je peux gérer une dépendance de tâche si nécessaire.

Il est très simple de charger tout le contexte d’un projet Rails dans une tâche Rake afin par exemple de manipuler la partie métier d’une application.

On peut aussi très facilement utiliser un système de Cron avec des tâches Rake pour les lancer périodiquement.

Je vous invite à lire les autres avantages de la série : les avantages de Ruby on Rails

Rack est une couche d’abstraction entre le serveur web et votre code Ruby. Pour les pythonistes, Rack est l’équivalant de WSGI.

Les autres me diront : « A quoi ça sert ? ».

Le premier intérêt de Rack, c’est de servir « d’adapteur universel » entre la plupart des serveurs web et du code Ruby. L’interface est très simple : une méthode qui prend la requête en entrée et retourne la réponse en sortie. Vous trouverez un exemple d’utilisation sur le blog de Damien Mathieu : créer un Rack middleware.

Il n’y a pas besoin de rentrer dans la technique pour voir d’autres avantages. Les « tranches » Rack peuvent se superposer, la réponse en sortie d’un Rack peut être branchée à l’entrée d’un autre Rack. Ces Racks que l’ont appellent middlewares ont différentes utilités : mise en place de cache avec Rack::Cache, Rack::Throttle pour limiter le nombre et la fréquence des requêtes HTTP provenant d’un client, Rack::Honeypot pour filtrer les spams, etc. Vous trouverez d’autres exemples ici.

Enfin dernier grand avantage : Rack peut rendre vos applications web modulaire ! En effet vous pouvez créer des applications Ruby on Rails entières avec modèles, vues et contrôleurs et les réutiliser comme un module d’une autre application Rails. C’est comme cela que fonctionne par exemple ActiveAdmin et Devise. A noter que Ruby on Rails n’est qu’un ensemble modulaire de « tranches » Rack.

Je vous invite à lire les autres avantages de la série : les avantages de Ruby on Rails

En 2 ans de Java, je n’ai jamais rien compris à Maven, pourtant avec Nexus, la gestion des bibliothèques durant le déploiement devait être plus simple… J’ai fini par me dire que l’installation automatisée des bibliothèques et la résolution de leurs dépendances devait être un métier à part !
Ici c’est Rubygems et Bundler qui m’ont fait changer d’avis (tous deux sont inclus par défaut dans Rails).

Rubygems permet de facilement publier, installer et mettre à jour des bibliothèques Ruby (que l’on appelle « gems »).

Grâce à Bundler, vous pouvez dans un seul fichier déclarer la liste des gems utilisés par votre projet. Si vous ajoutez ou enlevez la déclaration d’une gem, Bundler le détecte et installe ou supprime automatiquement la gem en question. Bundler résout les dépendances, les doublons, les différences entre les environnements (développement, tests, staging, production.. ). Cela redevient humain de gérer les bibliothèques dont dépend votre projet !

Je vous invite à lire les autres avantages de la série : les avantages de Ruby on Rails

Certains me diront : « SASS et CoffeeScript, ce ne sont pas des exclusivités de Ruby on Rails ? ». Et ils auront raison ! Seulement je n’aurais pas utilisé ces langages s’ils n’étaient pas par défaut dans Rails.

CoffeeScript est une manière alternative d’écrire du Javascript. Il s’agit d’un langage destiné à être compilé en javascript. Mon code est plus lisible, plus facile à maintenir, il m’évite les pièges basiques. CoffeeScript a été pour moi un grand changement dans ma façon de faire du JavaScript, du même ordre que la découverte de mon premier framework Javascript (Prototype). De plus la combinaison CoffeeScript / JQuery est un réel plaisir !

Si vous voulez en savoir un peu plus sur CoffeeScript, je vous conseille les slides de Jean-Hadrien Chabran.

Il y aussi son homologue pour CSS : SASS. SASS est compilé en CSS et ajoute ces fonctionnalités que j’attendais désespérément : les variables, les fonctions, l’imbrication des sélecteurs..

Et si l’on ajoute Compass, un framework CSS codé en SASS, faire du CSS devient enfin supportable !

Je vous invite à lire les autres avantages de la série : les avantages de Ruby on Rails

- Besoin d’une interface d’administration ? Je mets en place ActiveAdmin en moins d’une journée !

- Besoin d’un système d’authentification complet (validation de l’email, gestion de la perte du mot de passe, chiffrement du mots de passe etc..) ? En moins d’une heure j’ai tout cela avec Devise. Et une heure plus tard j’ai aussi la connexion Facebook, Twitter, LinkedIn avec OmniAuth.

- Besoin de mettre en place un moteur d’indexation de documents avec le célèbre Solr (basé sur Lucene)? Il me suffit d’une demi-journée pour écrire mes règles d’indexation avec Sunspot et moins d’une heure pour mettre en place Solr avec WebSolr.

Je n’ai jamais autant aimé écrire des formulaires depuis que j’ai découvert SimpleForm. J’écris mes formulaires en Ruby, et SimpleForm génère à partir d’un objet de mon modèle un formulaire avec label, annotations, affichage des erreurs, validation html5 pour chaque attribut spécifié.

Ruby on Rails foisonne de gems (bibliothèques) me permettant de mettre en place des fonctionnalités complexes avec une grande simplicité.

Vous semblez sceptiques ? Je vous invite à aller voir le site de Ryan Bates : RailsCasts qui vous donnera quelques échantillons.

Je vous invite à lire les autres avantages de la série : les avantages de Ruby on Rails

Voici ce que je lis et j’entends quotidiennement :

« Je suis développeur PHP, je dois me former à Ruby on Rails pour un projet, je suis curieux de pouvoir comparer avec Symfony. »

« J’ai beaucoup entendu parler de Ruby on Rails, que fait-il de plus que les autres frameworks ? »

« Je suis venu à cet apéro Ruby car je voudrais en savoir plus sur Ruby on Rails.. »

Manifestement, il y a un grand besoin de comprendre pourquoi ce framework web fait autant parler de lui.

En retour j’entends :

« Ce que j’aime le plus dans Ruby c’est sa syntaxe élégante ! »

Question de goût donc ?

« Pour moi la force d’un programme écrit en Ruby, c’est sa capacité de s’écrire lui même »

Ça me fait une belle jambe !

« Ruby on Rails est très bien conçu : MVC, Migrations, Tests etc.. »

Les autres frameworks ne font pas la même chose ?

Depuis 5 ans les frameworks web se sont nourris les uns les autres. Lorsque l’un d’entre eux met en avant une bonne idée, celle-ci est souvent reprise et digérée par les autres.

C’est ainsi que beaucoup d’entre eux possèdent maintenant un environnement dit « full-stack », une architecture MVC (ou proche), un ORM, un language de templating, un gestionnaire de librairies, un système de tests, des migrations, etc. C’est le cas par exemple pour CodeIgniter, Symfony, Zend Framework, CakePHP, Django, Play!.

De plus les principes Don’t repeat yourself et Convention Over Configuration ont commencé à faire leurs bout de chemin chez tous ces frameworks.

Pourtant Ruby on Rails garde pour moi des atouts qui expliquent sa popularité croissante. J’ai donc décidé d’écrire une série d’articles sur ces avantages qui me servent au quotidien :

• Les avantages de Ruby on Rails (1/10) : les bibliothèques
• Les avantages de Ruby on Rails (2/10) : SASS et CoffeeScript
• Les avantages de Ruby on Rails (3/10) : la gestion des bibliothèques
• Les avantages de Ruby on Rails (4/10) : Rack
• Les avantages de Ruby on Rails (5/10) : Rake, le lanceur de tâches
• Les avantages de Ruby on Rails (6/10) : le déploiement sur le cloud

Une fois freelance, j’ai rapidement eu de la demande pour des formations. Comme j’aime beaucoup faire partager mes connaissances, j’ai passé une bonne partie de l’été à préparer une formation de trois jours.

J’ai rédigé une présentation et des exercices pratiques en m’inspirant de nombreux livres (Agile Web Development with Rails), présentations, cours (Code School)… qui correspondent à la façon dont j’ai envie d’enseigner.

Une fois prêt, j’ai donné mes premières formations. Les retours ont été très bons. J’ai fait évoluer la formation pour supprimer les défauts de jeunesse. Maintenant que ma formation a été rodée, j’ai décidé de la packager dans une offre claire.

Vous pouvez voir l’offre sur ma page Formation. N’hésitez pas à me laisser votre email ou à me contacter pour que je vous donne plus d’information.

Voilà maintenant 1 mois que je travaille avec Camille Roux sur un moyen de partager l’actualité Ruby dans le monde francophone.

En effet, le langage Ruby est en plein boom en France depuis quelques mois. Les offres d’emplois se multiplient, les initiatives individuelles et collectives ne manquent pas : Apéro Ruby partout en France, évènements (Railscamp, RULU, Rendez-vous freelances, conférences..), futur site RailsFrance, screencasts, nouveaux blogs..

Cependant, ces différents contenus restent difficiles à trouver, souvent peu mis en avant. Il manquait un outil pour tous les rassembler et les rendre visibles à la communauté. RubyLive voit le jour pour pour combler ce manque.

RubyLive est un flux d’actualités collaboratif. Chacun, une fois inscrit, peut soumettre un article. Une fois modéré, l’article devient visible à tous, il apparaît sur le flux RSS du site et est publié sur Facebook et Twitter.

Je suis heureux de vous annoncer que RubyLive est maintenant en ligne !

Vous pouvez dès maintenant lire l’actualité Ruby et proposer vos dernières news sur RubyLive.fr.
Je tiens à remercier nos partenaires pour leur soutient : Entropic Synergies, Novelys, Belighted, RemixJobs et OVH.

Un ami m’a conseillé il y a quelques mois le livre : Metaprogramming Ruby de Paolo Perrotta.

Un livre très intéressant donnant quelques bonnes pratiques pour faire de la métaprogrammation avec Ruby.

Qu’est-ce que la métaprogrammation ?

Il y a plusieurs définitions, mais celle qui nous intéresse est la suivante :

« Metaprogramming is writing code that writes code »

Vous pouvez trouvez ici une définition plus complète : http://en.wikipedia.org/wiki/Metaprogramming.

A quoi cela sert-il ?

Redéfinir, ajouter des méthodes et des classes, exécuter du code à la volée, cela permet de créer des frameworks comme Rails et Sinatra, mais aussi des bibliothèques comme devise ou haml.

Tous utilisent la métaprogrammation. Les raisons sont diverses : rendre une bibliothèque plus intuitive à utiliser, éviter la duplication de code, s’interfacer avec un code existant, implémenter un domain specific language…

Voici un exemple concret dans Rails : la génération des accesseurs d’un modèle à partir de l’introspection des champs de la base de données. Le développeur qui crée un nouveau modèle n’a ainsi pas besoin de maintenir ces accesseurs dans le monde objet.

Un autre exemple toujours dans Rails : les méthodes find_by de ActiveRecord.

Pourquoi donc se priver de faire de la métaprogrammation ?

La métaprogrammation permet de faire des choses fantastiques. Cependant elle requiert de la discipline. Si on ne suit pas certaines bonnes pratiques, on peut aboutir à un code confus et difficile à débogguer.

Si vous souhaitez vous investir de manière plus approfondi dans la métaprogrammation avec Ruby, n’hésitez pas à lire le livre de Paolo Perrotta Metaprogramming Ruby.