Archives de
Catégorie : programmation

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.
Mark Zuckerberg pense que l’on peut apprendre à coder grâce aux jeux vidéo

Mark Zuckerberg pense que l’on peut apprendre à coder grâce aux jeux vidéo

On ne présente plus Mark Zuckerberg, le célèbre fondateur de Facebook. Le 15 mai dernier, lors d’une séance de questions/réponses publiée sur Facebook, il a incité les parents à laisser leurs enfants jouer aux jeux vidéos pour favoriser leur développement intellectuel. Pour Mark Zuckerberg, on peut apprendre à coder grâce aux jeux vidéo et il se base sur son expérience personnelle pour en parler.

« Je ne serais assurément jamais devenu programmeur si je n’avais pas joué aux jeux vidéo étant enfant. » – Mark Zuckerberg

Il y a souvent un débat sur les effets des jeux vidéo sur les enfants. Par exemple, dès qu’il y a une tuerie aux Etats-Unis ou un acte de violence dans la société, on voit se développer des arguments autour du « c’est la faute aux jeux vidéo« .

Cette fois, Mark Zuckerberg explique que c’est grâce aux jeux vidéo que l’on peut devenir développeur. Dans son enfance, son goût des jeux vidéo lui a donné envie de faire des choses pour lui. Il a donc commencé par faire ses propres jeux vidéo seulement pour lui et « ils étaient horribles« . Ce n’était pas grave. Le jeu vidéo a donc été sa porte d’entrée pour apprendre à coder.

Néanmoins, il admet que certaines craintes des parents sont légitimes sur les jeux vidéos mais cela reste la solution la plus simple pour faire aimer les nouvelles technologies aux enfants.

Chez Toxicode, nous apprenons justement à des enfants à découvrir la programmation tout en développant leur propre niveau d’un jeu vidéo. Nos ateliers sont accessibles et on remarque qu’ils sont passionnés par l’exercice. Lors de nos différents ateliers pour apprendre à coder, je suis toujours assez étonné par le silence qui règne dans la salle. Les enfants sont vraiment concentrés.

Je partage donc cette approche pédagogique avec Mark Zuckerberg et je vous invite, si vous avez des enfants, à développer leur curiosité de la programmation que ce soit via des jeux vidéo ou tout autre support.

Entre programmation et créativité : Bret Victor, le visionnaire décalé

Entre programmation et créativité : Bret Victor, le visionnaire décalé

A première vue, Bret Victor semble être un type plutôt banal. Il n’a ni la gouaille ou l’assurance d’un Mark Zuckerberg, ni le côté businessman génial d’un Steve Jobs. Il passerait presque inaperçu. Lorsqu’on commence à regarder une de ses présentations d’une heure sur Youtube, on se dit qu’on risque de s’ennuyer un peu, même si on est intéressé par la programmation.

Et en une minute, tout est retourné… On se prend une claque conceptuelle en pleine figure, on est sonné et surtout on n’a pas envie d’en perdre une miette. Car Bret Victor est avant tout un visionnaire… et un visionnaire de la meilleure trempe… un visionnaire décalé.

Bret Victor, ancien interface designer chez Apple, considère tout ce qui l’entoure et l’intéresse, notamment ses domaines d’expertise – programmation et créativité – et les triture, les retourne dans tous les sens pour mieux s’interroger et ouvrir de nouvelles portes… et c’est totalement prenant de le voir entreprendre ce questionnement philosophique des choses.

J’en veux pour preuve deux vidéos fort inspirantes que je vous conseille de regarder au plus vite.

« Les créateurs ont besoin d’une connexion immédiate avec ce qu’ils sont en train de créer. »

Dans “Inventing on Pinciples” (Inventer selon des Principes), Bret Victor traite du sujet de la créativité en s’appuyant sur des exemples liés à la programmation mais pas que. Et sur un précepte essentiel : quel que soit votre domaine d’expertise, technicien, ingénieur, vous pouvez (même vous devez) avoir le sentiment de travailler pour une cause qui vous semble juste, de défendre un principe éthique auquel vous croyez. En gros, il y a de la morale dans tout ce que l’on fait, même quand on met les mains dans le cambouis.

Bret Victor illustre ce principe en citant son exemple personnel. Le principe auquel il croit fermement ? Lorsqu’on crée quelque chose, on devrait pouvoir voir immédiatement, sans délai, le résultat ou l’impact de ce que l’on a crée. Il prend d’abord pour exemple une page de code classique d’une image. Si l’on souhaite modifier un détail de l’image, il faut aller dans le code, modifier, sauvegarder, relancer avant de confirmer que le résultat est bien celui qu’on espérait. Et Bret Victor de demander : pourquoi ne pas pouvoir voir immédiatement le résultat de toute modification dans notre code? Je vous laisse regarder la vidéo pour découvrir ses idées qui permettraient de coder efficacement, en ayant un lien direct avec ce que l’on veut créer.

Il n’utilise pas que des exemples issus de la programmation, également des algorithmes mathématiques, des circuits électriques… Mais le principe fondateur reste le même, et franchement, plus il parle et plus on en est convaincu. Bret Victor se place constamment en porte-à-faux par rapport à ceux qui croient déjà “savoir ce qu’ils font” et qui à force de ne rien questionner, finissent par simplement stagner plutôt que créer.

“La pensée la plus dangereuse pour un créatif, c’est d’avoir la certitude qu’il sait ce qu’il fait. »

Dans “The Future of Programming” (L’Avenir de la Programmation), Bret Victor est également dans le décalage, mais cette fois temporel. Il utilise une pirouette élégante : arrivant sur la scène avec un vieux rétroprojecteur, il fera mine pendant toute sa présentation d’être en 1973 et de présenter les idées révolutionnaires des années 60 et 70 qui à coup sûr, seront totalement acquises d’ici 40 ans, c’est à dire … en 2013.

Pourquoi ? Pour mettre la « nouvelle génération » qui constitue son public devant ce qu’il nomme une « tragédie » : que de toutes les idées visionnaires nées dans les années 60, à l’époque ou la programmation n’était pas encore clairement définie, nombreuses ont été totalement oubliées. Et le futur qu’on imaginait serait le nôtre en 2014 n’a pas pris en compte les idées géniales du passé. Du coup, on code encore comme il y a 40 ans… on a stagné. Et pire encore : la nouvelle génération tient pour acquis que tout a été déjà réfléchi, que la programmation ça doit être comme ça. Ils ne sont pas bridés, ils sont juste aveugles…

Pour remédier à cela une bonne solution : écoutez ce que dit Bret Victor, essayez d’être inspirés par ce que vous faites et ne prenez jamais pour acquis les systèmes dans lesquels vous évoluez.

Si vous faites partie de la nouvelle génération de développeurs, concepteurs de jeux vidéos, ou autres experts IT, si vous manquez d’inspiration lorsque vous vous levez le matin, regardez ces deux vidéos… elles changeront peut être votre façon de travailler ou même votre vie !