Déjà mon deuxième meetup Craftsmanship ! La formule reste inchangée mais le contenu se renouvelle : 3 lightning talk et une partie atelier ! C’est Cyrille qui ouvre le bal.

La progressivité dans le code, par Cyrille Martraire

Cyrille nous invite à prendre conscience de la notion de « progressivité » lors de nos refactorings. Certains remaniements se font en douceur… jusqu’à se heurter à des remaniements qui s’avèrent plus brutaux !

Ainsi passer d’un if au for se fait en douceur. Dans un SGBDR, une entités qui était comprise dans la même table que l’entité maître va pouvoir migrer dans une table séparée lorsque sa cardinalité augmente. Cette déformabilité est facilitée par les outils, des IDE proposant des fonctions de refactoring, ou bien entendu la présence de tests unitaires.

Hélas cette déformabilité rencontre des limites, dont les frameworks sont régulièrement responsables : ceux-ci proposent des conforts d’usage selon un cadre nominal, mais la sortie de ce cadre engendre alors une forte augmentation de la complexité.

Enfin, déformabilité ne signifie pas flexibilité anticipée !

Docker pour le développement logiciel, par Mario Loriedo

Peut-on de manière simple gérer ses environnements de développement indépendamment de la machine ? C’est ce que Mario nous propose via un plugin Sublime Text qui nous permet la compilation directe dans un conteneur Docker !

Ce petit projet open-source a vu le jour lors du Docker Hackathon, il est hébergé sur Github. si vous souhaitez y contribuer, vous êtes le bienvenu !

Qu’est-ce que l’isomorphisme ?

Bien sûr, ici on parle de l’isomorphisme en programmation. De l’usage d’anciens mots pour de nouveaux usages, en quelque sorte…Ici, on parle avant tout d’utiliser le même langage et les mêmes API côté client et côté serveur. Cela réduit terriblement les technologies que l’on peut considérer. C’et donc essentiellement Javascript à la base, même si on a de petites choses en Ruby.

La plateforme la plus avancée en l’état est Meteor, qui propose ses API Java côté serveur, client Web et mobile ! Bien entendu, les API se comportent différemment en fonction de la localisation, un concept que l’on n’a pas trop de mal à imaginer si l’on pense au stockage…

Teasing des sessions

Nous arrivons à la seconde partie de la soirée, celle ou des ateliers ou des sujets d’open-space vont être proposés.

Java 8

Une première session pour évoquer Java 8 et les bonnes pratiques de programmation à mettre en oeuvre avec cette nouvelle mouture de Java. On pense aux lambdas, bien sûr.

Docker pour l’intégration

C’est aussi un open-space qui nous est proposé ensuite : peut-on utiliser Docker pour les tests d’intégration et comment ? Pour quels apports ?

Cycle de vie et versionning des applications

Un autre open-space proposé ici avec une nette coloration devops…

TDD en mission : oui, non, comment ?

Ca fait toujours classe de dire que l’on fait du TDD. Mais dans le contexte réel du client, ce n’est pas toujours si évident : pression des deadlines, fort legacy, etc. Est possible et comment faire ?

Cette session sera retenue lors des votes.

Atelier BDD

Stéphane Bagnier avait prévu son coup. Il propose un atelier des capture des besoins en ATDD, sur papier via l’interview d’un client.

Cet atelier sera également retenu.

Randori de code

Au dernier moment, cette proposition de session de « live coding » en mode Randori, autour de la résolution d’un jeu ! En l’occurence le tic-tac-toe, que j’appelle personnellement « Morpion ».

Ce sera la 3ème session retenue.

Il est maintenant temps de voter.

Grand amateur d’ATDD, je me jette bien entendu sur l’atelier de Stéphane !

Atelier BDD

L’animation proposée par Stéphane est très différente de l’atelier ATDD que je propose. Elle est aussi plus ludique. Le « sujet métier » est un jeu. Il s’agit d’un jeu des plus bizarre : le cul de chouette, issu de la série Kaamelott ! Nos 2 animateurs (car ils sont deux) répondent de manière imprécises et évasives aux questions que nous leur posons destinées à éclairer les spécifications du jeu ! Quand aux tentatives d’abstractions, ils s’y montrent carrément hermétiques !

L’idée est bien sûr de nous mettre face à des comportements réels ou exagérés d’utilisateurs et de les aborder par le biais d’exemples à l’aide de l’approche BDD.

En phase 1, le réflexe « écriture de tests » de prends pas, les participants rebondissent de questions en questions, sans les approfondir et en cherchant prématurément des généralisations. Bref, quelques concepts sont dégagés, mais cela reste très superficiel

Le second round est dédié à l’écriture de tests en binômes, en se concentrant sur des sous-parties du problème. Le résultat est beaucoup plus encourageant, d’ailleurs on découvre des pièges de l’énoncé. Le travers le plus souvent constaté est l’écriture de tests pas suffisamment univoques, parfois même abstraits ! Ce fut d’ailleurs l’objet d’une petite discussion assez intense dans mon propre binôme.

En conclusion : un bel atelier pour faire découvrir le BDD comme technique de spécification agile.

Et pendant ce temps…

Deux autres ateliers se déroulaient durant cette période. Tout d’abord la discussion autour du TDD en entreprise.

Je n’avais jamais vu le Randori pratiqué. Il m’a fallu un petit moment pour en comprendre le fonctionnement. Pour tout dire, il m’a aussi fallu un petit moment pour saisir que tests et code fonctionnels étaient mélangés au sein du même fichier source. Un peu de refactoring, que diantre !

On termine la soirée (au moins pour moi, car je ne suis pas resté pour la 3ème mi-temps) par un débrief des différentes sessions. Voici celle du TDD, justement.