Archives de
Mois : août 2016

Pilier Rails 2 – Les conventions tu adopteras

Pilier Rails 2 – Les conventions tu adopteras

Cette semaine, nous poursuivons notre série de billets blog sur la Doctrine Rails avec le Pilier 2, qui préconise les conventions plutôt que les configurations.

L’un des premiers slogans de Rails a été :

« Chacun d’entre vous N’EST PAS un magnifique et unique flocon de neige. »

Le postulat était qu’en renonçant à un individualisme aussi tentateur que vain, il serait plus facile d’échapper aux complications liées à la prise de décisions quotidiennes et d’avancer plus rapidement sur les questions réellement importantes.

Une des missions de Rails est ainsi de dégraisser le mammouth né de l’accumulation de décisions auxquelles doivent faire face chaque jour les développeurs. Des centaines de ces décisions ont juste besoin d’être tranchées une seule fois et si quelqu’un d’autre que vous peut le faire, tant mieux ! En effet, que vous importe le format dans lequel vos identifiants de base de données sont décrits ? Est-ce une décision digne de délibérations récurrentes ?

Le passage de la configuration à la convention permet non seulement de se libérer des affres de la délibération récurrente, mais aussi d’approfondir le niveau d’abstraction. La force des bonnes conventions est qu’elle permettent des gains de temps et de productivité sur un vaste ensemble de fonctions.

De plus, les conventions facilitent la maîtrise de Rails par les débutants qui peuvent ainsi créer d’excellentes applications sans forcément savoir que telles ou telles conventions existent ou pourquoi elles existent. Il leur suffit souvent de comprendre comment les pièces du puzzle s’assemblent, ou plus concrètement de regarder les autres applications créées pour comprendre comment s’imbriquent les pièces. En fin de compte, l’imposition d’une contrainte confère même aux esprits les plus rebelles davantage de liberté.

Cependant, le pouvoir de la convention n’est pas sans danger. Il est aisé de croire que chaque aspect d’une application peut être conçu à partir de templates prédécoupés, alors qu’en réalité, la plupart des applications valables contiennent quelque chose d’unique, même un élément mineur. Le plus difficile reste donc de savoir quand s’écarter des sentiers battus de la convention et d’être capable de se montrer créatif.

Histoire pour apprendre à coder – La programmation

Histoire pour apprendre à coder – La programmation

Ce billet de blog est la suite de celui sur le boulier qui évoquait la mécanisation des opérations de calcul. Comme indiqué dans l’article sur le boulier, je souhaite reprendre trois innovations importantes (qui ont des conséquences lorsque l’on veut apprendre à coder) à travers une série de trois billets de blog qui sont :

Qu’est-ce la programmation ?

Les débuts de la programmation remontent au Moyen-Âge avec les  premiers automates. A l’époque, c’était des objets mécaniques qui avaient des mouvements automatiques (d’où leur nom) sans intervention humaine pour effectuer les mouvements. Les humains se contentaient de les … programmer !

Ces automates avaient donc une mémoire limitée à l’aspect mécanique qui pouvait se concrétiser par l’utilisation de poulies, d’engrenages, de courroies, etc.

A la fin du XVIIIème siècle, la programmation a connu une étape importante avec l’industrialisation. On avait besoin de machines capables de répéter des gestes programmés à l’avance par l’homme. Les machines industrielles ont permis dépasser les limites physiques du corps humain.

De nombreuses initiatives sont alors réalisées pour développer la programmation. On peut, notamment, évoquer les recherches du britannique Charles Babbage (1792-1871) sur les « calculateurs ».

BabbageDifferenceEngine

Charles Babbage est considéré comme un des précurseurs de l’informatique. Il est le premier à avoir réalisé une machine qui combine une mémoire et un calculateur programmable. 

« You will be able to appreciate the influence of such an Engine on the future progress of science. I live in a country which is incapable of estimating it. »
— Charles Babbage

Il a commencé à réfléchir à la programmation lorsqu’il était chargé de contrôler des calculs. Comme son travail était légèrement ennuyant, il a réfléchi à des méthodes pour automatiser ces calculs et éviter les erreurs.  Après différents essais, il a commencé à réaliser une machine intitulée le Analytical Engine qui était programmable à l’aide de cartes perforées qui permettaient d’obtenir les résultats (sur une feuille de cuivre) lorsqu’elles étaient insérées dans la machine.

Malheureusement, Charles Babbage n’a jamais réussi à construire une machine complète faute de financement. Cependant, le Science Museum de Londres à construit une de ses machines en 1990 en suivant ses plans et la machine fonctionnait bien comme il l’avait prévu.

La programmation est importante lorsque l’on veut apprendre à coder et son histoire n’est pas aussi récente que l’on pourrait le penser. Aujourd’hui, la programmation est essentiellement numérique mais elle puise ses origines dans ses recherches.

 

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.