ncrafts.io jour 2

NCrafts 2015, ce sont deux jours de conférences mémorables. Après avoir fait un retour sur le premier jour, voici un article qui résume certaines des conférences auxquelles nous avons assisté lors du deuxième jour.

Puisque l’édition 2015 est déjà passée, nous ne pouvons que vous encourager à ne pas manquer la prochaine édition. En attendant, si le sujet vous tient particulièrement à cœur, sachez que Sandro Mancuso propose une formation en France en partenariat avec Xebia Training.

Dichotomy between things and processes

Par Mathias Verraes

En keynote, Mathias Verraes nous a parlé de l’importance de réflechir à notre modélisation avant d’implémenter une solution. Il part d’un exemple simple de deux stories qui ont le même objectif mais écrites d’un point de vue différent :

De ces deux user stories, la modélisation peut changer car elle est inconsciemment induite par la description de la story et le fait que nous souhaitions coller le modèle de données au plus proche de la réalité.

Au lieu de ça, nous devrions prendre le temps de réflechir au modèle et notamment aux évènements qui en découlent en s’appuyant sur des questions du type :

• qu’est-ce qui change ?
• pourquoi ces changements ?
• dans quelles circonstances ces changements apparaissent ?
• qu’est-ce qui les déclenchent ?

De plus, l’event storming offre un ensemble de pratiques permettant de répondre à ces questions. Cela nous permet de mettre en avant les notions de temps (dépendances chronologiques du parcours utilisateur), les contraintes, les intentions, etc.

Full-Time Pair-programming

Par Houssam Fakih

Tout le monde clame haut et fort que le pair-programming est une solution pour bon nombre de problèmes lorsqu’on souhaite travailler efficacement en équipe. Houssam nous offre dans ce talk un retour d’expérience de trois années de pair-programming non-stop.

Le parallèle qu’il effectue avec le sport et notamment l’haltérophilie est déroutant : nous sommes invités à regarder ensemble des vidéos YouTube de sportifs en train de soulever de la fonte. Pourtant c’est complètement approprié avec son discours sur les qualités qu’il faut posséder pour pratiquer le pair-programming à plein temps. Tout est une question de coordination : pour que la magie opère il faut dès le départ discuter sur l’objectif de la session de coding afin que les deux développeurs soient bien alignés. Il est primordial de rester focalisé sur la tâche pour limiter le temps de switch lorsqu’on s’échange le clavier. La vitesse de développement doit également être adaptée au moins rapide pour progressivement l’amener vers une vélocité plus élevée lors de sa montée en compétence sur le projet. Ne vous privez jamais du feedback que vous procure un nouvel arrivant dans l’équipe.

Houssam nous prévient : pair-programmer est fatiguant et il faut savoir se ménager. Faire des pauses régulières pour s’aérer le corps et l’esprit.

D’autres points très intéressants sont évoqués : la flexibilité, la balance, la propriété du code, le partage de connaissances, l’unicité de la configuration et des outils pour toute l’équipe. Ce n’est pas parce qu’on pair-programme qu’on ne peut pas chercher l’amélioration continue : il est toujours utile de faire intervenir un coach dans l’équipe qui analysera d’un point de vue extérieur comment les pairs travaillent, se relaient et réalisent la performance de délivrer le bon logiciel. Notez au passage que ce vocabulaire emprunté au sport prend tout son sens dans ce contexte. À la fin de la session, on peut proposer une petite rétrospective, savoir sortir de sa zone de confort, mesurer le temps de l’échange des rôles driver/navigator ainsi que sa fréquence ou maîtriser les outils afin de ne pas frustrer son pair.

Pour résumer le pair programming est une pratique très enrichissante. Houssam nous invite évidemment à la pratiquer et même à expérimenter d’autres voies : le cross programming (pairer avec un expert du domaine), le mob programming (pairer avec toute l’équipe en même temps).

L’une des questions en fin de talk a particulièrement retenu l’attention : qu’en est-il des problèmes humains qui sont engendrés par cette pratique riche en interactions sociales ? La réponse de Houssam est assez catégorique : si le développeur ne parvient pas à s’intégrer à l’équipe dont les membres sont nécessairement tous déjà « compatibles », il va très vite émettre le souhait de quitter le projet. Cette intégration échoue en majorité à cause du mode de travail collaboratif constant (dont on a finalement pas tant l’habitude que cela – notre système éducatif est basé quasi exclusivement sur le travail personnel) plutôt que pour des problèmes humains.

Building the future of User Experience

Par Vincent Guigui

Au début de la présentation, Vincent a attiré notre attention avec la question suivante : avez-vous remarqué comment peut-on être limité par les IHMs (Interfaces Homme-Machine) de nos jours ? Imaginez vous devant votre PC, vous vous retrouvez souvent limité par la taille de l’écran, obligé de scroller de haut en bas ou de gauche à droite selon l’action réalisée. Nous sommes aussi limités car dans la plupart des IHMs, lorsqu’on interagit avec un outil, un site ou autre, nous devons taper sur des touches, cocher des cases, scroller, etc. Ne serait-il pas plus simple de juste demander quelque chose avec sa voix, ou de faire des signes, par exemple ? Nous avons besoin de davantage interagir avec les systèmes qui nous entourent et ce le plus naturellement possible.

• le son en utilisant des hauts parleurs directionnels qui sauraient interagir avec la bonne personne,
• le touché grâce au retour haptic par exemple,
• l’odeur pour manipuler l’humeur (et reproduire l’envie qui nait en nous lorsqu’on passe devant une boulangerie).

• utiliser sa bague pour gérer le volume,
• nos chaussettes pourraient nous alerter quand on marche trop vite,
• même chose pour les fourchettes et le fait de manger trop rapidement,
• ou encore les ceintures et les quantités mangées,
• les brosses à dents pourraient nous indiquer la qualité de notre brossage en plus de la durée minimum,
• etc.

Ce futur n’est pas si lointain, les choses sont en train de changer. Vincent nous donne beaucoup d’exemples d’applications ou dispositifs qui sont en cours de construction ou sont déjà arrivés pour nous aider à améliorer nos interactions avec les machines. Voici quelques uns :

• La Kinect de Microsoft aujourd’hui nous permet d’interagir avec une application tout simplement en bougeant son corps,
• L’Oculus Rift et HoloLens nous offrent des belles perspectives pour le futur avec la réalité augmentée.

L’expérience utilisateur est en train d’évoluer pour justement se rapprocher plus de l’utilisateur, pour rentre nos interactions avec nos appareils et services plus intuitives, plus naturelles.

Enterprise Tic-Tac-Toe

Par Scott Wlaschin

Rien que le titre de ce talk est inspirant : que viennent faire accolés l’un à l’autre le qualificatif souvent associé dans notre industrie à l’artillerie lourde et le nom d’un jeu simpliste ? C’est tout l’intérêt du sujet proposé par Scott : nous montrer que la programmation fonctionnelle peut apporter des réponses simples à des problèmes qualifiés de compliqués ou de transverses dans nos projets.

Tout d’abord, que regroupe ce terme entreprise (attention du second degré a été malicieusement inséré dans cette énumération) ?

1. séparation des responsabilités (NdT: separation of concerns) : parce que bien souvent les équipes ne s’aiment pas et ne veulent pas savoir ce que les autres font, il est bon de bien découper les responsabilités
2. sécurisation : parce que les développeurs du backend ne font pas confiance aux développeurs du frontend
3. documentation : parce que l’équipe de maintenance n’a pas le niveau pour lire le code
4. scalabilité : parce que le directeur technique veut se construire un CV à base de mot-clés à la mode

En programmation fonctionnelle, une partie de la sécurité nécessaire dans un projet peut être implémentée par un système de type consistant : en effet, puisqu’on ne fait pas confiance à l’interface utilisateur qui va mal gérer les états du système, les conversions de types primitifs ou l’état interne du système alors le passage systématique par des types explicites limite les cas d’erreurs.

Pour garantir une certaine séparation des responsabilités, Scott nous expose alors un concept que nous connaissons sous le terme de Generics et qui se nomme Parametric Polymorphism en programmation fonctionnelle. Cela permet par exemple au tic-tac-toe de masquer l’état interne du jeu à l’interface tout en conservant ce paramètre au fur et à mesure des appels.

Comment fournir un log systématique des appels en programmation fonctionnelle ? En utilisant de l’AOP, des annotations java ou des attributs .net, de l’instrumentation de bytecode ? Rien de tout cela : il suffit de composer les fonctions (l’opérateur >>) afin d’entourer sa fonction principale par des logs sur les paramètres ou les valeurs de retour.

Une fois que notre programme fonctionne, le frontend web aura besoin de nous invoquer avec un format proche de ses technologies et de son formalisme habituel : HTTP et JSON. Cependant le type de retour du tic tac toe pour l’instant n’est pas JSON friendly : il comporte de nombreux détails d’implémentations inutiles voire dangereux d’exposer aux clients. C’est pourquoi un nouveau type de retour est introduit pour ce besoin : ApiResult.

Même avec ce type spécifique un problème persiste : le JSON ne respecte pas le système de type que l’on manipule avec un langage fonctionnel. Le client peut toujours nous envoyer une payload qui ne pourra pas être transformée en type. Par exemple si on doit écrire un programme qui gère le stockage d’un fichier de configuration :

1. type File : c’est bien trop dangereux,
2. type TextWriter : le client peut écrire n’importe quoi dans le fichier de configuration,
3. interface clé/valeur : ce n’est pas encore type safe,
4. interface avec toutes les fonctions possibles : l’état n’est pas bien géré,
5. interface avec seulement une seule fonction : dans ce cas le client n’a d’autre choix que d’utiliser la fonction de création/mise à jour de la configuration.

C’est l’application du Principle Of Least Priority ou capability based security. Le bon effet de bord d’implémenter la sécurité est que cela induit souvent un bon design. Dans le tic tac toe, cela se traduit par le changement du type GameState en NextMoveInfo avec une seule fonction disponible : MoveCapability. Scott nous montre ensuite sa mise en application avec l’instanciation d’un vrai jeu qu’il fait tourner devant nous. Nous constatons que ça peut paraître compliqué de parser les réponses et de les renvoyer au prochain tour. C’est à ce moment que HATEOAS est mentionné. Pour l’implémenter en F#, il encode ses NextMoveInfo en guid. Le bénéfice principal est que c’est bien le serveur qui a la maîtrise du schéma et que c’est au client d’interpréter les liens plutôt que de devoir connaître les URI à l’avance. Cela permet un découplage clair entre client et serveur.

En résumé, cette conférence est un excellent exemple de ce qu’il est possible de faire avec un langage fonctionnel de nos jours. De plus le ton résolument second degré du sujet entretien l’intérêt durant toute la présentation. Le côté démonstration avec le code F# qui s’exécute devant nos yeux dans Visual Studio fini de captiver les développeurs que nous sommes.

When DDD meets documentation

Par Cyrille Martraire

Pour chauffer la salle, Cyrille commence par nous faire un petite démo d’un synthétiseur analogique avec lequel il peut générer du pitch, de l’echo et toute sorte d’effets. Rien à voir avec la conférence mais ça permet de détendre l’atmosphère.

Puis il enchaine avec ses slides à un rythme ultra rapide, à base de gif animés et de mots en plein écran pour maintenir l’attention. Sur la forme : c’est une très bonne surprise.

Le pitch du talk de Cyrille est accrocheur : la documentation peut-être au moins aussi cool que le code ! D’habitude, la rédaction d’une documentation est une souffrance, souvent peu à jour : bref on a l’impression que ça ne sert à rien et que c’est inutile. En fait, il faut complètement revoir notre rapport à la documentation et inverser les responsabilités : ce n’est pas au développeur de documenter son code, c’est le code qui doit s’auto-documenter pour le développeur.

Mais quel est le lien entre la documentation et le DDD ? Les deux notions sont centrées autour de la connaissance du domaine. Où doit-on mettre la connaissance ? Comment transférer cette connaissance vers des vraies documentations ? Votre objectif aujourd’hui avec la documentation est de ne pas la rédiger vous même mais bien de la générer à partir des méta-données déjà disponibles : l’exemple du BDD est particulièrement parlant. C’est une documentation exécutable qui sera toujours à jour car elle est la pré-condition à la livraison du logiciel.

En DDD, on peut ajouter des annotations autour des notions comme le bounded context ou des core concepts qui permettent de dégager un glossaire toujours à jour.

Si vous respectez l’architecture hexagonale, vous pouvez tirer parti de vos packages ou de vos annotations pour générer un diagramme avec les types internes au domaine versus les ports et adapters en interface du domaine. Vous pouvez même débogguer votre design en détectant des anomalies comme une dépendance externe à votre bounded context. Si vous avez du mal à générer un diagramme qui vous parait pourtant simple ? Vous venez de débogguer votre design : refactorez pour que la génération soit plus simple et vous constaterez également une simplification dans la conception.

La clé, c’est de générer les graphiques les plus simples possibles : prenez votre base de code et retirez tout le superflux. Le maître mot, c’est un diagramme pour un usage, une histoire.

Vous pouvez utiliser certains outils de génération de diagrammes à partir de simples fichiers textes. Ces fichiers pourront être placés au plus près du code, mis en gestion de configuration et mis à jour en même temps que le code en lui même lorsque vous faites évoluer votre logiciel.

D’autres examples de génération de documentation sont mentionnés par Cyrille : générez un nuage de tags de vos types, vos noms de variables et vos fonctions pour connaitre la qualité de votre ubiquitous langage ; demandez à votre logiciel de vous expliquer les résultats qu’il vous rend.

Voici d’autres phrases choc qui peuvent vraiment vous faire changer la vision que vous vous faites de la documentation :

1. si vous connaissez votre design et que vous savez ce que vous faîtes, votre documentation est déjà à moitié générée,
2. si vous écrivez des tests et du code de qualité, la documentation sera quasiment gratuite,
3. le talent requis pour écrire une bonne documentation est similaire au talent requis pour introduire un bon design.

Le mot de la fin de cet excellent et rafraichissant talk de Cyrille est le suivant : la documentation est seulement emprisonnée dans votre code. Vous n’avez qu’à la libérer !

Hands’ on: you are a seasoned TDD practitioner? Join us in the battle agains the kata diamond!

Par Jean-Laurent de Morlhon

Par Bruno Boucard

Que serait une conférence sur le craft sans un vrai coding dojo ? Les experts du domaine Jean-Laurent et Bruno nous ont proposé un kata dont la simplicité de l’énoncé n’avait d’égal que le challenge pour l’implémenter. Malgré une salle relativement petite et bien chauffée par la matière grise en fonctionnement, la plupart des pairs sont venus à bout de l’exercice. Mais comme bien souvent dans ces évènements, le plus important n’est pas le résultat mais bien le chemin pris pour y arriver.

C’est pourquoi nous avons passé environ une demie heure à débriefer sur notre session de code. Cet exercice est intéressant pour savoir si le TDD peut vraiment nous aider. En effet, dès le second ou le troisième test, on arrive vite à bloquer sur l’implémentation KISS et il faut se retrousser les manches pour imaginer l’algorithme final. Or, le TDD permet tout de même d’avancer en baby step si on se donne le temps de tester des parties plus petites du résultat attendu.

Je vous encourage à pratiquer ce kata pour vous faire une idée de ce que nous avons expérimenté durant ces deux heures.