Archives de
Étiquette : 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.
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.

5 bonnes raisons de participer à la Code Week 2015

5 bonnes raisons de participer à la Code Week 2015

L’heure de la Code Week 2015 a sonné ! Ce samedi 10 Octobre marque le début d’une  semaine dédiée au code et à la programmation numérique dans toute l’Europe. Toxicode s’est mobilisé pour vous proposer tout au long de la semaine des événements en Région Parisienne et à Rennes et vous donne 5 raisons imparables de ne pas rater ce rendez-vous à échelle européenne.

Parce que c’est hyper tendance

La Code Week, c’est avant tout des opportunités de rencontres et d’échanges dans toute l’Europe. Et d’année en année, les événements organisés se font plus nombreux, et visent un public plus large. Il faut dire que la question de l’apprentissage du code est désormais devenue centrale et mobilise de plus en plus le gouvernement comme les acteurs sociaux. En 2014, on a compté environ 300 événements organisés rien que dans la France ! Cette année, Toxicode a mis les petits plats dans les grands et s’est associés à différents partenaires pour vous proposer des ateliers ludiques et innovants autour de l’apprentissage de la programmation (voir programme ci-dessous).

Parce qu’il y aura de l’action

La Code Week, c’est des ateliers ludiques pour les enfants (ateliers Scratch), des activités manuelles pour mettre les mains dans le cambouis (Makey Makey), de la création de jeux vidéo y compris la programmation de comportements d’un héros et de monstres (ateliers Toxicode – Code N Slash )…  Tout est fait pour que les participants de tous âges puissent vraiment avoir une expérience concrète de la programmation et de ses nombreuses applications au quotidien.

Parce qu’il y aura des robots et des IA (Intelligences Artificielles)

La Code Week, c’est des rencontres du 3ème type garanties ! Et oui, fini les heures assis devant un écran à écrire des lignes de code incompréhensibles. Désormais, la programmation permet de coder des intelligences artificielles (atelier Toxicode – Coder une intelligence artificielle à Rennes), le comportement d’un robot constructeur (ateliers Toxicode – Codecraft) ou de robots en chair et en os, enfin vous voyez ce que je veux dire… (ateliers robotiques avec de vrais robots pour devenir l’ami de Wall-e)         

Parce qu’il y aura de la compèt

La Code Week, c’est aussi l’occasion de participer à des challenges quel que soit votre niveau, passionné de programmation ou débutant. De nombreuses game jams sont prévues, permettant de se mesurer aux autres participants pour créer un niveau de jeu vidéo (ateliers Toxicode – Code N Slash ) ce qui obligera à sortir de votre zone de confort et à repousser vos propres limites !   

Parce qu’il y aura des filles (et des garçons)

Désormais, le code n’est plus seulement réservé à la gent masculine ! Les filles ont investi la place et ne comptent pas en partir. Les assoc de promotion de la programmation et des nouvelles technologies destinées aux filles type Girls in Tech ou Rails Girls fleurissent un peu partout et on ne va pas s’en plaindre… Lors des ateliers Toxicode organisés cet été, on comptait certes encore une majorité de mâles, mais les filles sont de plus en plus nombreuses ! Donc n’hésitez plus et venez apprendre à coder ou vous perfectionner au code, partout en France et en Europe !

Programme des ateliers Toxicode pour la Codeweek 2015 (10 au 18 octobre 2015) :

  • 10 octobre 2015 de 15h00 à 16h30 – “Atelier Codecraft” à la Médiathèque Hélène BERR, Paris 12ème, le cadre de NUMOK, festival numérique des Bibliothèques de la Ville de Paris.
  • 10 octobre 2015 de 14h30 à 17h30 – “Atelier Code N’ Slash” à la Médiathèque Françoise SAGAN, Paris 10ème.
  • 13 octobre 2015 de 19h à 23h – “Atelier Code N’ Slash” à l’ISART DIGITAL, Paris 11ème.
  • 17 octobre 2015 de 10h00 à 13h00 – “Atelier Bot Arena pour coder une Intelligence Artificielle” dans le cadre du Festival MAINTENANT à Rennes.
  • 17 octobre 2015 de 11h00 à 12h30 – “Atelier Codecraft” au Cube à Issy-les-Moulineaux.
  • 17 octobre 2015 de 14h30 à 17h30 – “Atelier Code N’ Slash” au Cube à Issy-lesMoulineaux.

Nos interventions :

  • Le 17 octobre 2015 de 15h15 à 16h30 – Échanges autour de l’apprentissage du code et des jeux vidéo : outils numériques de réappropriation du monde dans le cadre du Festival MAINTENANT à Rennes.
  • Le 23 octobre 2015 – Participation à la soirée de clôture de la Codeweek, organisée dans les locaux de Mozilla à Paris autour du thème : « Code, Créativité et Pédagogie ».

Exemple d’outils : http://silentteacher.toxicode.fr/

Démonstration de Bot Arena : https://www.youtube.com/watch?v=faS7zrRijAg

Démonstration de Code N’ Slash : https://www.youtube.com/watch?v=ZYv90pAvGe8

Nos formations en ligne : http://www.toxicode.fr/events

Pour plus d’informations sur ces événements  Code Week 2015, vous pouvez consultez la page www.codeweek.eu/

 

 

Histoire pour apprendre à coder – Le boulier

Histoire pour apprendre à coder – Le boulier

Lorsque l’on souhaite apprendre à coder, on pense que l’on va apprendre un métier qui est très récent. C’est vrai, si vous apprenez un langage de programmation votre objectif sera certainement de vouloir réaliser des sites web ou des logiciels via un ordinateur. Cela fait partie des nouveaux métiers qui ont vu le jour avec l’essor des nouvelles technologies.

Si je vous demandais à quand remontent les origines des langages de programmation, je pense que la majorité des lecteurs de ce billet de blog estimerait que cela remonte à moins d’un siècle. C’est là qu’il peut sembler y avoir un paradoxe. Même si le métier de développeur web ou de développeur de logiciel est très récent dans notre Histoire, l’origine de l’informatique et des langages de programmation est bien plus lointaine que l’on ne pourrait le penser.

En réalité, l’informatique que l’on connaît aujourd’hui est le résultat final de trois innovations humaines (que je traiterai à travers trois billets de blog) :

  • La mécanisation des opérations de calcul
  • La programmation
  • La notion d’algorithme

Dans ce premier billet de blog, je vais revenir sur la mécanisation des opérations de calcul.

Qu’est-ce la mécanisation des opérations de calcul ?

L’homme a cherché depuis plusieurs siècles des solutions pour calculer plus rapidement. Les méthodes pour compter et calculer peuvent être radicalement différentes d’un endroit du globe à l’autre.

Ainsi, le boulier, essentiellement en Asie, est un outil mécanique utilisé pour calculer, et ce depuis des siècles.

Dans un article du journal Le Monde du 26 novembre 1987 (réservé aux abonnés), un journaliste avait suivi des expériences faites dans des classes pour utiliser le boulier. Il est expliqué que lors de concours de calcul au Japon, le choix du boulier était supérieur à la calculatrice électronique. Le boulier permet même de calculer plus rapidement qu’une calculatrice !

« Avec le boulier, un enfant est capable de raisonner sur un nombre qu’il ne sait pas désigner », observe Mme Josette Huso, institutrice en CP à Grigny.

Le boulier offre la possibilité d’acquérir une réflexion visuelle où l’on va déconnecter le nombre de son aspect abstrait. On ne visualise que des boules. De plus, cela permet de voir les opérations dans leur ensemble. Une addition ou une soustraction sont des opérations pratiquement identiques dans cette méthode de calcul alors que dans les pays occidentaux, on va les traiter comme deux éléments d’apprentissage distincts. Les élèves qui ont appris à calculer avec un boulier sont souvent meilleurs en calcul mental. Ils ont une méthode de calcul différente.

En développement, c’est la même chose. En fonction de la façon dont sera écrit le code, on va avoir une réflexion différente pour arriver à un résultat. C’est pour cette raison qu’il est important de maîtriser les bonnes pratiques de la programmation car cela permet d’avoir un code plus efficace et lisible.

Le boulier illustre le paradoxe que l’on retrouve au Japon mais également dans le développement et l’informatique. Nous avons des outils ultra modernes tout en utilisant des logiques, des méthodes, qui sont ancestrales (même si l’usage du boulier n’est pas nécessaire pour apprendre à coder). Cette méthode est ancienne et les bouliers sont des objets rustiques dont la puissance pédagogique a traversé les siècles.

A l’heure du débat sur la nécessité d’apprendre le code à l’école, cela pourrait commencer par l’apprentissage de certains socles. L’usage d’un boulier dans une classe pourrait, paradoxalement, être un élément de l’apprentissage du code à l’école.

C’est donc assez amusant de constater que nos élèves (ceux qui ont eu des leçons avec un bouliers) « apprennent » depuis des décennies des logiques courantes en programmation à l’école…

Pour aller plus loin, je vous invite à comprendre le mécanisme du boulier à travers cette vidéo et pourquoi pas vous amusez avec un boulier … numérique !