Retour sur le ncrafts.io – jour 1

Pour paraphraser Laurent Bossavit : soyez toujours curieux. Ce mantra s’applique particulièrement à la conférence dont nous allons résumer certaines des sessions. En tant que software craftsman, c’est toujours enrichissant de se mêler et d’échanger sur d’autres technologies/langages/communautés. En cela NCrafts 2015 nous permet réellement d’ouvrir le spectre de notre métier vers des sessions rafraichissantes où le fun prend une part importante.

Les maîtres mots de cette année : programmation fonctionnelle (les types plutôt que les tests) et Event* (Storming, Sourcing, Driven Development).

The Joy of Debugging Ourselves

Par Laurent Bossavit

Cette keynote commence par un mantra assez amusant : La vie serait plus simple si on pouvait lire le code source.
Pour lui la programmation ouvre aux développeurs des possibilités infinies. Mais elle est également source de frustration (je ne peux pas tout savoir) et de danger (je me crée mes propres problèmes, je m’investit trop, je suis en burnout). De cette dualité nait l’interrogation légitime : pourquoi le code peut-il être douloureux ?

La vision simpliste de l’écriture d’un logiciel pourrait se résumer à ces trois étapes :

1. écrire le code
2. supprimer les bugs
3. profit

En réalité, c’est beaucoup plus complexe que cela. Déjà le terme bug est très mal choisi : c’est comme si on pouvait lister tous les bugs de manière exhaustive pour les supprimer. Laurent nous fait part d’une de ses réflexions qu’il aimerait que l’Histoire puisse retenir sous le terme de loi Bossavit : les bugs dans le code sont en fait des bugs dans notre cerveau. Petite note en passant : en réalité, il faudrait plutôt parler de l’esprit. Cependant dans cette keynote il n’est pas utile de distinguer l’esprit – le software – du cerveau – le hardware. Le parallèle est intéressant.

Si on essaie de continuer notre explication de pourquoi le code peut-être douloureux, Laurent revient sur une fonctionnalité assez désagréable de notre cerveau : le biais de confirmation. Nous ne recherchons que les preuves de ce que nous pensons déjà vrai.

Pour aller plus loin, on pourra lire l’ouvrage de Daniel Kahneman : Thinking, fast and slow. L’évolution nous a conduit à penser rapidement pour réagir à un environnement hostile. Aujourd’hui, ces dangers immédiats ne sont plus prépondérants et il faudrait favoriser un autre type de réaction : la réflexion et le raisonnement. Pourtant instinctivement dans le code, nous continuons à penser rapidement. Pour aller plus loin, on peut affirmer que le raisonnement est plus souvent un bug qu’une fonctionnalité. Contrairement à l’état dépressif qui est une fonctionnalité plutôt qu’un bug. Cet état émotionnel nous empêche de vivre la vie que nous avons vécu jusque là : il nous immobilise dans un état qui nous permet d’analyser des problèmes complexes et reconsidérer vos décisions malheureuses.

Un autre parallèle sur les bugs de l’être humain peut être fait à propos de l’humour. En fait l’humour c’est un debugage de notre raisonnement.

Vous faites une hypothèse depuis le début de la blague jusqu’à ce qu’elle soit invalidée, et ça vous fait sourire.

Laurent conclue en nous incitant à être toujours curieux et à faire le chemin par nous même. Il cite par exemple le TDD. Selon lui c’est une excellente pratique mais qui ne doit pas être imposée. Il faut que vous fassiez vous même l’expérience et y trouviez vous même les intérêts.

Le mot de la fin : debuggez tout ce que vous pouvez.

Write Your Own Compiler in 24H

Par Phil Trelford

Phil travaille à Londres dans une société en finance et est l’heureux papa de deux enfants à qui il essaie d’enseigner l’informatique. Il a tenté l’expérience avec du logo et ses tortues. Cependant pour un aficionado du fonctionnel, il fut très déçu de constater que ce langage n’offre pas la possibilité d’écrire de fonctions. C’est pourquoi il a cherché à développer un compilateur pour rajouter cette construction.

L’intérêt de cette session est qu’elle est très pragmatique. Phil nous prévient dès le début : il n’y aura pas de théorie des langages, pas de mathématique ni de preuve de programme.
En revanche, il nous présentera certaines notions comme les DSL, les AST, le parsing, les interpréteurs et la génération de code le tout sous la forme d’une démo interactive dans Visual Studio.

Après un troll en règle sur les différents langages (PHP, Scala, Java, C#), il fini par nous donner son penchant pour F#. Pour commencer, on n’a pas besoin d’implémenter le parseur. L’AST suffit. Il exécute un exemple d’AST de logo et ça affiche la forme géométrique attendue. Il nous présente ensuite l’utilisation d’une librairie pour le parseur : FParsec. C’est assez élégant de voir comment la grammaire se déclare de manière fonctionnelle dans F# avec cette libraire.

Il introduit ensuite la nouvelle fonctionnalité de son langage : la fonction. Au lieu d’écrire public static void main(), il préfère nommer la déclaration d’une fonction to : plus concis en effet. Il nous montre brièvement qu’il a eu besoin d’un peu d’aléatoire avec le mot clé SetRandomPosition. Cela lui permet d’introduire un peu d’art dans ses programmes.

Malgré son aversion peu dissimulée pour JavaScript, il concède ensuite à nous montrer un compilateur de son AST vers JavaScript et un peu de canvas. Dans son code, le compilateur n’est qu’un pattern matching de son AST. Le plus beau, c’est que ça fonctionne. La seule chose qui choque, c’est le navigateur utilisé : IE !

Dernière démo avant de passer au basic : Phil nous montre son compilateur d’AST logo vers MSIL (le bytecode de .Net). On obtient un binaire (oui, un .exe) qui affiche la même figure que dans la page web. Magique.

Pour bien nous montrer que ce processus de construction d’un langage est itératif et scale en complexité, il nous montre exactement les mêmes étapes qu’en logo mais pour un langage un peu plus évolué : le basic. Il y apporte de nouvelles fonctionnalités : la fonction et le pattern matching ! Le plus beau, c’est qu’il a mis à disposition son compilateur sur le windows store et nous montre l’exécution de jeux écrits en small basic (rétro compatible avec son basic). Vraiment impressionnant.

Vous pensez que Phil a atteint sa limite dans l’implémentation de compilateur ? Et bien non car il s’est ensuite amusé à nous montrer son compilateur C# ! Certaines fonctionnalités avancées du langage n’y sont pas mais on peut quand même exécuter tout un tas de programmes compilés grâce à son travail.

À la fin de sa démo, Phil nous préconise la lecture de Programming Language Concepts.

Note de la fin : écrire un compilateur est vraiment amusant et gratifiant.

Functional Programming in C#

Par Tomasz Jaskula

Voici ce qu’il faut retenir de la session de Tomasz :

La programmation orientée objet essaie de modéliser le vrai monde : est-ce une bonne chose ?
Les frameworks d’injection de dépendances nous facilitent trop la vie pour écrire du code couplé. Il faut trouver un moyen pour que ça soit douloureux à nouveau : l’application partielle.
Comment contrôler la complexité d’un programme ? En composant les fonctions. Comment composer les fonctions sans les coupler fortement les unes aux autres ? Grâce à l’usage des monades : des types encapsulant un résultat correct et un résultat en erreur. Pour composer deux monades en C#, il faut écrire un peu de code pour dé-wrapper le succès à l’appel de la prochaine fonction.

Conclusion de la présentation : focalisez-vous sur la simplicité et écrivez seulement le code qui est important pour votre business.

Continuous delivery, the missing parts

Par Paul Stack

Paul est un ancien développeur qui a migré du côté opérationnel il y a quelques temps et se défini comme un DevOps extremiste. C’est pourquoi, sa présentation a pour objectif de rappeler les bases du Continuous Delivery (CD) et l’émancipation du DevOps.

Pour celà, il commence par donner sa définition du CD : c’est une ensemble de principes et pratiques ayant pour but de construire, tester et releaser un logiciel plus rapidement et donc plus fréquemment.

De là, il commence par définir ces 8 principes :

• The process for releasing/deploying software MUST be repeatable and reliable : ceci en vue de les automatiser et de ne pas y mettre les mains dedans à chaque fois qu’on les utilise,
• Automate everything! : les tâches répétitives ne font pas parties de nos jobs, dev ou ops. D’autant plus que nous savons automatiser, c’est ce que nous faisons pour nos clients. Nous automatisons des traitements métiers. Alors pourquoi ne le faisons-nous pas pour nos opérations techniques ?
• if something is difficult or painful, do it more often : pour maitriser un art, il faut le pratiquer. Comme tout sportif de haut niveau, comme tout expert dans son domaine, comme tout professionnel, nous nous devons de faire face aux difficultés qui nous ralentissent,
• keep everything in a source control : « Peux-tu me copier tes commits sur ma clé USB que je les récupère, stp ? »,
• done means released : terminé s’applique à quoi ? à qui ? à une fonctionnalité ?! Oui mais pas seulement. Une fonctionnalité apporte de la valeur ajoutée à un produit. Produit qui est utilisé par des utilisateurs. Donc tant que ces utilisateurs ne peuvent profiter de la fonctionnalité, elle n’apporte aucune valeur. Donc terminé s’applique à une fonctionnalité en production, dont les utilisateurs profitent,
• build quality in! : je vous renvoie vers le manifeste craft et notamment son premier principe : « Pas seulement des logiciels opérationnels, mais aussi des logiciels bien conçus ». La malfaçon a des conséquences financières, toujours, que ce soit en consommation de ressources (quantité de CPU, RAM, disque, etc. utilisée) ou bien en maintenance (difficulté à maintenir et faire évoluer l’application),
• everybody has responsability for the release process : si une fonctionnalité est terminée lorsqu’elle est en production, tout le monde est alors responsable de son cycle de vie, du PO à l’OPS en passant par les devs, jusqu’à la prod et sa maintenance.

Ensuite, Paul nous a parlé des 4 pratiques qu’il juge nécessaire pour mettre en place un bon CD :

• build binairies only once : évidemment, si entre deux builds d’intégration continue de votre pipeline les sources ont changé, vous ne déploierez pas la fonctionnalité souhaitée. C’est pour cela que très souvent, le premier job d’intégration continue déploie l’artefact généré sur un repository de binaires comme Nexus, que les builds suivant utiliseront pour s’assurer de tester les mêmes sources,
• use the same mechanism to deploy on each environment : pourquoi faire compliqué quand on peut faire simple ?
• smoke test your deployment : s’assurer qu’un déploiement s’est bien passé vous assurera de ne pas faire perdre de temps aux utilisateurs de cet environnement. Ne serait-ce que valider que la page d’accueil de votre application s’affiche est un bon début,
• if anything fails, stop the line : en effet, pourquoi le déploiement fonctionnerait en production s’il n’a pas fonctionné en pré-production ?

Une fois les bases posées, Paul a enchainé sur les malentendus/trolls qu’il a pu entendre ou lire :

• CD is only for startups : il est vrai que l’approche ne sera pas la même entre une grosse IT et une startup, mais rien n’empêche de démarrer sur un projet, puis d’itérer sur d’autres au fur et à mesure,
• CD works only for NodeJS/Scala/Ruby : a obtenu la palme d’or au Trolls Awards 2014,
• we can hire a consultant to help us making CD : par consultant, Paul parle d’un genre de MOA, une personne qui donne des specs, des guidelines, etc. mais qui ne met pas les mains dans le code. Si on se remémore les principes cités plus haut, c’est un sujet qui doit être pris par les développeurs et opérationnels car ce sont eux qui connaissent leur produit, qui savent comment le déployer,
• a good tool will help us implement CD : chaque contexte est différent, des outils existent pour faciliter des étapes du CD mais pas pour le mettre en place,
• CD is simple has hooking github to Azure : pas si simple que ça malheureusement, les besoins sont un peu plus complexes : comment gérer différents environnements ? différentes configurations ? etc.

Ensuite, Paul a naturellement enchainé sur le concept qu’on appelle DevOps. Pour lui, ce n’est ni un rôle, ni une personne, c’est juste un mot sur le concept de collaboration entre les développeurs et les opérationnels.

Pour la petite histoire, Flickr a annoncé en 2009 réalisé 10 déploiements en production par jour (oui, il y a 6 ans…). À la suite de ça a eu lieu la première conférence nommée DevOps Days en octobre 2009, à Ghent en Belgique. C’est là que le mot est né.

Le concept se repose donc sur :

• une culture : les hommes et leur interactions en premier,
• l’automatisation : là, vous pouvez utiliser tous les outils que vous voulez,
• measurement : « if you can’t measure, you can’t prove. So measure everything! »,
• sharing : entre toutes les équipes, partager vos connaissances et vos expériences.

Le sujet des métriques est revenu plusieurs fois lors de la discussion. C’est la base d’un produit pragmatique car les indicateurs nous permettent d’avancer dans la bonne direction. Vous ne pouvez plus perdre du temps et réclamer des fonctionnalités ou des machines si vous n’êtes pas capables d’expliquer ce que ça va apporter au produit !

Crafted design

Par Sandro Mancuso

C’est une présentation que Sandro Mancuso joue depuis quelques temps mais qu’il améliore au fil du temps. Il l’avait d’ailleurs jouée au craft day de l’an dernier.

On en retiendra surtout que la séparation des responsabilités est importante et qu’utiliser CQRS couplé à l’event sourcing permet de créer des composants simples et correctement découpés.

Je rajouterai une petite note sur l’organisation de packages : le découpage des sources en couches applicatives (rest, services, dao, dto, etc.) n’apporte aucun sens au produit. Un découpage par domaine a d’avantage de puissance et permet d’un premier coup d’oeil de se diriger vers là où l’on souhaite.

Event storming

Par Alberto Brandolini

L’event storming, présenté par son inventeur, est une méthode permettant de définir les processus fonctionnels de votre produit. Un peu à la manière d’un story mapping, nous modélisons les flow fonctionnels d’une application en mettant en évidence les évènements et leurs déclencheurs, et non pas les user stories, découpés en domaines fonctionnels.

Lors de cette présentation, Alberto nous a expliqué pourquoi l’event storming était une solution adaptée au développement logiciel et plus appropriée qu’UML par exemple.

Le principe est de réunir developpeurs et stakeholders dans une pièce, les munir de posts-it et de markers. Chacun va ajouter des évènements et ses déclencheurs (des actions, des commandes) et, à travers les conversations, le produit va naitre.

L’intérêt de cette méthode est que le résultat est directement convertible en code puisqu’en utilisant CQRS, Event sourcing et Domain Driven Design, vous n’aurez qu’à reproduire les commandes et évènements que vous aurez définis auparavant. De plus, il permet d’avoir une vision globale et partagée de l’application. Alors que si vous utilisiez UML et les diagrammes d’activité, il serait impossible de ne créer qu’un seul diagramme pour toute l’application.

Au final, cette méthode apporte de la communication, de la reflexion et de l’apprentissage. Si vous souhaitez en savoir plus, voici le blog d’Alberto Brandolini.

My adventure with ELM

Par Yan Cui

ELM est un langage assez jeune qui se compile en JavaScript et s’intègre dans le navigateur. Sa particularité est d’apporter le paradigme fonctionnel et réactif directement dans le language. Yan parle d’un ensemble de valeurs qui évoluent au cours du temps. Elles émettent des évènements qu’on appelle signal dans ELM. Selon Yan, ELM permet d’écrire vos programmes de manière fluide et linéaire ; contrairement à un langage impératif où il est souvent peu naturel de naviguer dans les différents endroits de vos fichiers sources. La complexité est encore plus grande à l’exécution où on ajoute l’état et les boucles.

En ELM, tout est immuable par nature. Les transformations simplifient la décomposition du problème.

Pour nous mettre l’eau à la bouche, nous assistons ensuite à la diffusion d’une vidéo d’une démo d’un jeu dans lequel on peut changer les valeurs physiques des éléments et rejouer le futur. On obtient un debuggeur visuel et interactif tout cela rendu possible par le modèle évènementiel et immuable.

Nous passons ensuite très rapidement sur la syntaxe du langage. En un mot, c’est très déclaratif.

Ensuite la magie du langage ainsi que le talent de Yan opèrent : il nous code tout simplement en une quinzaine de minutes un snake. Juste éblouissant.

Tout n’est cependant pas si rose :

1. Les stack traces sont illisibles
2. La rétro compatibilité n’est pas assurée pour l’instant car le langage est jeune et évolue énormément
3. Lorsque vous debuggez, il faut rapidement mettre en pause sinon dès que vous rejouez l’histoire ça prend énormément de temps

En conclusion : malgré sa jeunesse ELM est un langage prometteur. Pour l’instant il est surtout dédié au développement de jeux dans le navigateur. Il dispose d’un plugin pour Sublime Text et elm-reactor vous permet de développer en local avec un feedback très rapide.

TDD is Dead?? Let’s Do an Autopsy

Par Bruno Boucard

Par Thomas Pierrain

Bruno et Thomas reviennent sur le TDD dans cette conférence avec un bilan sévère : peu de gens pratiquent vraiment le TDD de manière régulière et pour le travail régulier. La question légitime qu’ils posent est donc : pourquoi ?

Certains avantages du TDD ne sont pas réellement justifiés : cela vous apporte par exemple soi disant un bon design, mais peut-on aboutir à un bon design si on ne sait même pas ce que c’est ? Il nous promet de nous poser le moins de questions possible lors de l’implémentation mais est-ce vraiment souhaitable ?

Voici les arguments :

• le design émergeant n’est pas magique : vous devez vous poser
• le TDD ralentit le développement : en quelque sorte, mais ça vous apporte tout de même des tests
• les tests finissent par paralléliser une base de code grandissante : il faut pour cela refactorer les tests et ne pas tester les implémentations (tests unitaires strictes sur les classes, mocking) mais bien les fonctionnalités

Bruno et Thomas nous rappellent que le TDD est vraiment efficace lorsqu’il est correctement effectué : il vous encourage au minimalisme, vous offre une boucle de feedback courte, favorise le pair programming dynamique : lisez Growing Object-Oriented Software Guided by Tests.

Red – Green – Refactor n’est pas suffisant.

The Silver Bullet Syndrome

Par Hadi Hariri

Pendant sa présentation Hadi nous parle avec beaucoup d’humour du syndrome de la balle d’argent dans notre métier : l’informatique. Ce syndrome, selon lui, consiste à inventer des nouvelles technologies à une vitesse vertigineuse dans l’espoir d’apporter une « meilleure solution » à un problème quelconque. Hadi plaisante avec cela : « nous les informaticiens avons réussi à créer une industrie qui s’auto-alimente: nous créons une nouvelle technologie > nous écrivons des livres ou des billets de blogs > nous faisons du conseil ou donnons des formations > nous mettons en prod > ça marche pas trop > nous créons une nouvelle techno > etc. ».

Hadi nous rappelle que c’est très difficile voir impossible pour une personne d’être à la pointe tout le temps, au courant des dernières nouvelles technologies du moment. Cela ne sert pas à grand chose si, à côté, nous ne sommes pas capables d’aider nos entreprises à créer de la valeur et par conséquent, faire de l’argent. Pour reprendre son exemple, c’est comme engager un ouvrier et exiger qu’il travaille avec un type spécifique de marteau ou une marque précise de scie sauteuse. Il vaut mieux lui demander de régler un problème et laisser qu’il s’en occupe avec ses outils et le laisser choisir solution selon le problème.

Je vous recommande fortement de regarder la vidéo de ce talk dès que ce sera publié par les organisateurs de NCrafts.

The Kata In The Hat

Par Jonathan Perret

Par Emmanuel Gaillot

Pour terminer cette première journée en apothéose Jonathan et Emmanuel nous offrent 45 minutes de live coding un peu fou sur un thème assez simple et pourtant fondamental : écrire un générateur de manifesto en Haskell – le tout sous les contraintes soumises par le public dans un chapeau. On a donc pu admirer le talent des développeurs mis à l’épreuve par :

1. coder en chantant
2. coder sans les ‘e’ : brillamment remplacé par des ‘ε’
3. coder sans les mains et avec le nez
4. killer le processus 1 sur un système unix : heureusement pas le laptop utilisé pour le live coding mais celui d’Emmanuel. Il a lancé la commande mais l’épreuve ne précisait pas qu’il fallait être sudo.
5. coder en dansant

La fin du kata approchant, Emmanuel et Jonathan ont accéléré sérieusement pour parvenir à finir leur générateur, mettant malicieusement « comme dans la vraie vie » les tests de côté et faisant du copié collé.