Archives de
Étiquette : Ruby on Rails

Pilier Rails 5 – La beauté du code tu célèbreras

Pilier Rails 5 – La beauté du code tu célèbreras

On écrit du code non seulement pour être compris de l’ordinateur ou d’autres programmeurs, mais aussi avec une intention esthétique. Un code qui plaît à l’œil a de la valeur en tant que tel et doit être encouragé au maximum. Cela ne veut pas dire que l’aspect esthétique est l’unique priorité, mais il a sa place aussi bien que les autres dans les critères de choix du programmeur

Mais qu’est-ce exactement qu’un beau code ? Quand on parle de Ruby, un beau code se situe souvent au croisement entre un assemblage d’idiomes Ruby et d’un langage customisé et spécifique à un domaine.

Voyons un exemple simple issu d’Active Record :

  class Project < ApplicationRecord

     belongs_to :account

     has_many :participants, class_name: ‘Person’

     validates_presence_of :name

   end

Cela ressemble à du DSL mais c’est une définition de classe avec trois appels de méthodes de classe qui prennent en paramètre des symboles et options. Il n’y a rien de sophistiqué, mais ces quelques lignes, aussi simples que jolies, offrent autant de pouvoir en plus que de flexibilité.

Une partie de la beauté de ces lignes de code vient de ce qu’elles honorent les principes mentionnés ci-avant, dont celui de Convention plutôt que Configuration.

Lorsqu’on crée une association avec un belongs_to :account, par convention on référence un modèle « Account » stocké dans la table nommée « accounts » via la clé « account_id ».

Un autre exemple du système de migrations de base de données :
   class CreateAccounts < ActiveRecord::Migration
     def change
       create_table :accounts do |t|
         t.integer :queenbee_id
         t.timestamps
       end
     end
   end

Le programmeur déclare une classe de façon conventionnelle, comme la sous classe ActiveRecord::Migration qui implémente #change, et le framework peut faire toute la plomberie autour, et sait que c’est cette méthode qu’il doit appeler. Dans le cas de ces migrations, cela va non seulement permettre d’appeler rails db:migrate pour mettre à jour la base de données avec cette nouvelle table mais aussi de la supprimer avec un autre appel.

Mais parfois, un beau code peut être plus subtil, et plutôt que de le rendre aussi bref que puissant, le challenge pourra être d’avoir une écriture fluide et bien rythmée.

Prenons ces deux lignes :

if people.include? person

if person.in? people

Même si le résultat est le même, le style et le focus sont légèrement différents. La première ligne se focalise sur la collection, tandis que la seconde se concentre sur la personne. Même si les deux lignes ont quasiment la même longueur, la deuxième semble beaucoup plus belle et peut susciter un réel plaisir esthétique pour le programmeur lorsqu’elle est utilisée dans un cas où la condition concerne la personne. 

Pilier Rails 4 – Un paradigme unique tu refuseras

Pilier Rails 4 – Un paradigme unique tu refuseras

Il est toujours tentant de choisir une seule idée centrale pour sous-tendre votre architecture et de la suivre jusqu’à sa conclusion logique. Cette méthode séduit plus d’un programmeur. Rails est à l’opposé de ce principe.

Rails n’est pas un tissu uni et lisse, mais plutôt un patchwork, composé d’une variété d’idées et de paradigmes, dont certains qui pourraient sembler incompatibles s’ils étaient combinés deux à deux. Mais Rails n’est pas un championnat de la meilleure idée où un seul vainqueur serait choisi.

Prenez les templates qu’on utilise pour construire le view dans notre graphe Rails MVC.  Par défaut, tous les assistants qui nous permettent d’extraire du code de ces templates sont juste une bouillabaisse de fonctions, très semblable à une soupe PHP. Mais cette bouillabaisse fonctionne parfaitement lorsqu’on doit présenter des fonctions individuelles qui n’ont que rarement besoin d’interagir.

Cela ne veut pas dire qu’on n’a pas besoin de temps en temps d’avoir recours à quelque chose d’orienté objet lorsqu’on construit des views. Le concept de Presenters, dans lequel on emballe de nombreuses méthodes interdépendantes les unes des autres et les données en-dessous, s’avère parfois un antidote parfait à la bouillabaisse de fonctions. Mais cela arrive rarement.

La flexibilité idéologique de Rails lui permet de résoudre une large gamme de problèmes. La plupart des paradigmes individuels conviennent parfaitement pour résoudre un certain type de problèmes mais sont inadaptés et trop rigides dès qu’ils sont sortis de leur zone de confort. Appliquer des paradigmes en couches superposées permet de couvrir toutes les zones à problème et rendent le framework final plus puissant et bien plus flexible que tout autre paradigme individuel.

Mais cette flexibilité a un coût : elle requiert de maîtriser non seulement la programmation orientée objet mais également d’avoir pas mal d’expérience en programmation procédurale et fonctionnelle.  Cette contrainte concerne également les sous-langages de Rails : il est ainsi fort utile de maîtriser Javascript pour les views ou SQL pour résoudre quelques queries un peu plus complexes, du moins pour pouvoir profiter au mieux de toutes possibilités qui s’offrent à vous.

La seule façon de gérer cette contrainte est d’adopter la technique de la tortue plutôt que celle du lièvre pour apprendre en chemin, patiemment. Ce qui veut dire qu’au départ vous ne comprendrez pas forcément chaque aspect du framework mais cela ne vous empêchera pas de faire quelque chose de simple qui aura une réelle valeur.

Pilier Rails 3 – Un menu omakase tu utiliseras

Pilier Rails 3 – Un menu omakase tu utiliseras

Comment savoir quel plat commander dans un restaurant quand on ne sait pas ce qui est bon ? Si vous laissez le chef choisir pour vous, vous avez de fortes chances de déguster un bon repas. Tel est le principe de l’omakase.

En matière de programmation, ce principe consistant à laisser des experts choisir pour vous est proche du principe de Convention plutôt que Configuration mais à un niveau plus macro. Alors que le premier se concentre sur la meilleure façon d’utiliser des frameworks individuels, omakase se focalise sur le choix des frameworks et comment les assembler les uns avec les autres. Ce principe contraste donc avec la tradition forte en programmation de présenter les différents outils disponibles comme des choix individuels et de laisser au programmeur le privilège (et le fardeau) de décider le(s)quels il va utiliser.

Vous avez probablement entendu souvent ce conseil : « Utilisez le meilleur outil pour accomplir la tâche », mais la question de quel est le « meilleur outil » est souvent plus difficile à trancher qu’il n’y paraît au premier abord. Ruby a fait le choix de réduire le privilège du programmeur individuel, celui de choisir chacun de ses outils, au profit d’un plus grand bien : une boîte à outil plus performante pour tous.

Les bénéfices sont légion !

  • La force du nombre : l’expérience partagée par le nombre d’utilisateurs de Rails offre une base saine pour partager, débattre, et apprendre les uns des autres,
  • Les utilisateurs travaillent tous à améliorer la même boîte à outil : en tant que framework complet (Full Stack Framework), Rails inclut une variété de parties mobiles qu’il est important de savoir assembler. La plupart des difficultés rencontrées dans les logiciels provient non pas des composants individuels mais des interactions. Le travail commun de l’ensemble de la communauté Rails permet  de mieux comprendre et maîtriser ces interactions,
  • Des substitutions possibles mais pas obligatoires : si Rails est une pile de composants fonctionnant selon le principe omakase, il est toutefois possible de remplacer certains de ses frameworks et librairies par d’autres composants, mais ce n’est pas une obligation. Ce qui signifie que vous pouvez prendre le temps de développer une palette que vous maîtrisez bien avant de penser à remplacer certains de ses composants.
Les 8 Piliers de la Doctrine Rails : Pilier 1 – Le bonheur des programmeurs tu assureras

Les 8 Piliers de la Doctrine Rails : Pilier 1 – Le bonheur des programmeurs tu assureras

Ruby on Rails ou ROR pour les intimes, framework web libre écrit en Ruby, connaît un succès grandissant et rassemble une communauté de plus en plus importante et passionnée.

Selon David Heinemeier Hansson (DHH), créateur de Ruby on Rails (2004) et de l’outil de gestion de projet Basecamp dont RoR est issu, une des réalisations majeures de Rails a été d’unifier et de cultiver une tribu fortement soudée autour d’une pensée variée et peu conventionnelle sur la programmation.

DHH a rédigé en janvier dernier un article très intéressant listant et explicitant les 8 piliers de Ruby on Rails qui plus qu’un framework, constitue une véritable philosophie de la programmation et du métier de programmeur selon lui:

Nous lançons donc aujourd’hui une série de billets hebdomadaires pour vous présenter les 8 piliers de la Doctrine Rails. Notre série de billets constitue une synthèse du point de vue de DHH sous-tendant la création de chaque pilier, dans une perspective de découverte d’un aspect « culturel » de la programmation, à savoir la création d’un langage informatique et l’importance des valeurs qui peuvent sous-tendre cette création. Toutefois, si nous tenons à restituer les idées clés avancées par DHH, nous ne partageons pas forcément l’ensemble de ces idées et tenons à rester neutre par rapport à ses arguments. Nous espérons que vous lirez ces billets avec le même regard critique que nous avons eu pour les écrire, et qu’ils vous permettront d’avoir une lecture objective sur la création de Ruby on Rails.

Pilier 1. Le bonheur des programmeurs tu assureras

Ce premier pilier est issu tout droit du principe à l’origine de la création de Ruby : placer le programmeur sur un piédestal. En se mettant au service du bonheur des programmeurs, Ruby s’est placé dès le départ en porte-à-faux avec les environnements de programmation les plus populaires :

  • Là où Python soutient qu’il n’y a qu’une seule façon de faire quelque chose, Ruby se délecte des subtilités et des nuances d’expression de la programmation.
  • Là où Java s’efforce de protéger les programmeurs de leurs propres faiblesses, Ruby les encourage à prendre des risques, quitte à les pousser à l’autodestruction.
  • Là où Smalltalk milite pour la clarté du message, Ruby accumule les mots-clés et structures avec un appétit gargantuesque.

Et c’est bien ce qui a rendu Ruby si attractif aux yeux de DHH  comme de nombreux autres programmeurs après lui. Pour DHH, la découverte de Ruby a été une véritable révélation, un passage  de« faire de la programmation parce qu’il avait besoin de programmer » à « faire de la programmation parce qu’il en est tombé amoureux comme mode d’expression et exercice intellectuel ».

Plus qu’un langage, Ruby est une vision, une contre-culture, un lieu où les marginaux de la programmation peuvent se rassembler et ressentir un vrai sentiment d’appartenance.

Pour donner un exemple concret, prenons un principe souvent associé à Ruby dans un premier temps : le principe de moindre surprise (Principle of Least Surprise), selon lequel Ruby devrait se comporter de manière prévisible (par contraste avec Python). Mais ce principe présentait un problème, il était intrinsèquement subjectif : en effet, prévisible pour qui ? Plus la communauté Ruby s’élargit, plus ce principe devint une source de débats sans fin et finit par s’effacer du devant de la scène. Rails a été conçu selon un principe similaire mais quelque peu différent, le Principe du Plus Large Sourire, qui doit permettre à l’utilisateur de profiter au mieux de sa vie.

Il peut sembler difficile de mesurer le degré de bonheur que Rails permet d’atteindre. Mais à un niveau macro, ce bonheur est palpable dans la communauté, qui se targue de meilleures conditions de travail et de vie.