NCrafts France est une conférence indépendante, pour la communauté .NET, qui avait lieu le 16 mai dernier à Paris. La conférence a été initiée par Rui Carvalho, qui s’occupe du groupe Alt.NET sur Paris. Tout une équipe de bénévoles animait aussi chacune des sessions. Au programme, et bien je dirai plutôt du DDD (Domain Driven Design), du F#, de l’Agilité, et finalement un contenu pas si .NET que ça, loin de là. La conférence avait lieu dans les locaux de Valtech à Paris.
En arrivant, après avoir discuté avec quelques figures connues (Cyrille Martaire, Jérémie Chassaing, Alexandre Victoor…) je ne me sentais pas d’attaque pour aller voir F#’s Type Providers: The future of meta-programming in .NET par Robert Pickering. J’ai préféré faire un atelier de 2 heures passionnant : Event Storming 101.
EventStorming
Ce workshop était organisé par 2 personnes du DDD User Group Belge : Jef Claes et Tom Janssen. Dans une salle, avec 25 personnes, nous avons découvert une technique intéressante de modélisation, appelée « EventStorming » (en un seul mot).
Cet atelier a été créé par Alberto Brandolini (@ziobrando) en 2013. Il s’agit d’une approche, à tester en petit groupe, visant à faire émerger un domaine métier, sur n’importe quel cas. Pour notre exercice, nous avons modélisé et analysé le principe d’un site marchand. Pour cela, nous avons effectué plusieurs ateliers, afin de nous faire comprendre petit à petit le principe.
Je vous raconterai dans un article plus détaillé, les principes de l’atelier
-
- Présentation de l’atelier
-
- On commence par tous écrire nos idées
-
- Chaque petit groupe de 5 personnes présente son modele
-
- Ensuite on refait l’exercice en ne décrivant que des événements
-
- Chacun doit avoir un feutre et un bloc jaune
-
- Clément explique une idée
-
- Enfin on revoit sur un des modèles, on synthétise
-
- On essaye de les classer chronologiquement
-
- Le Product Owner (en bleu de dos) passe à la casserole
-
- Synthèse
Monoids, Monoids Everywhere in your domains!
Cyrille Martaire est directeur technique et co-fondateur de la société Arolla. Basé à Paris, avec une cinquantaine de salariés, Arolla fait autant de Java, que de .NET. Sa présentation portait sur les Monoïdes. Lorsque l’Algèbre vient percuter la théorie des langages, les patterns, et finalement des concept que l’on connait tous…
Qu’est-ce qu’un monoide ? A quoi cela sert-il ? Et si en fait… j’en avais déjà vu ?
L’approche est très intéressante, pour peu que vous ayez déjà fait du DDD. Il cite à raison quelques patterns du monde DDD, qui sont parfait dans le monde de la programmation fonctionnelle : l’immutabilité (les Value Object), l’associativité, les éléments neutres, tout ce qui est fold, bref j’ai adoré cette présentation. Sur la forme tout d’abord, Cyrille est un très bon speaker. Sur le fond, rien à redire. L’explication et les exemples permettent de comprendre les caractéristiques des monoides. Et cerise sur le gâteau : le sujet vous intéressera et gagne à être connu si vous commencez vraiment à faire de la programmation fonctionnelle. Mais pas que…
Un monoïde en mathématique, est une structure algébrique consistant en un ensemble muni d’une loi de composition interne associative, et d’un élément neutre. Un exemple peut-être ? Nous pourrions décrire la séquence des actions dans un match de Rugby. Il n’y a que 3 façons de marquer des points au rugby :
- 3 points pour une pénalité
- 5 points pour un essai
- 7 points pour un essai transformé
Partant de là, l’élément neutre de notre monoïde sera 0, le score de départ. L’addition est un exemple de loi de composition interne. Plutôt que de mettre à jour un compteur de score, voyons si nous ne pouvons pas garder un ensemble, un groupe, qui serai la séquence des scores (action de marquer). De cette façon, il est possible de calculer le score final, et de garder la séquence des actions du jeu. Calculer la séquence finale, c’est simple. Il suffit de faire le total des Score… Et bien en fait il est aussi possible de réduire, de faire un fold, en utilisant une des propriétés du monoïde. Pour que cela fonctionne et soit possible, il faut donc décrire un objet à même d’effectuer ces opérations, c’est un monoïde. Donc un monoïde est un ensemble, avec une loi de composition interne associative, et d’un élément neutre de départ.
A quoi cela peut-il bien servir ? Nous sommes habitués à programmer dans un univers impératif, où nous mettons à jour des compteurs. L’approche impérative représenterait le match de Rugby, et le score, comme étant un compteur, incrémenté à chaque but. Nous aurions alors un objet mutable (le score total). L’approche fonctionnelle encourage l’immutabilité entre autre. Nous pourrions obtenir le même résultat, à savoir connaître le score final, tout en prenant une approche où aucun élément n’est modifié. Pour cela, nous représenterons la suite des actions de notre match de Rugby, pour finalement retrouver le score final.
Je vais vous le dire : vous utilisez déjà des monoïdes sans le savoir. Une liste chaînée ? C’est un monoïde. La concaténation de 2 chaines de caractères ? C’est un monoïde ! Dans le cas d’une liste chaînée, chaque élément possède un pointeur vers l’élément suivant. Je pense que vous connaissez les avantages d’une liste chaînée, dès lors qu’il s’agit de manipuler d’énormes structures rapidement, et efficacement. Pour ce qui est de la concaténation de chaîne de caractères, cet exemple vous fait comprendre que nous ne modifions pas l’un des deux termes (« hello » et « world ») mais que nous créons un troisième terme en partant de « hello », tout en conservant en fait, un lien sur l’élément suivant. Pour la liste chaînée, l’élément neutre est une liste vide. Pour la concaténation, c’est une chaîne vide.
Tout ceci doit donc vous donner une idée et l’avantage des monoïdes : simple à composer, rapide, capable de conserver un historique lorsque l’on parle d’événements…
Quid de la mémoire ? Que des objets immuables ? Mais mon GC va exploser…
Une question intéressante en fin de présentation a suscité le débat : « si je n’utilise que des objets immuables, et que j’en ai un grand nombre, alors mon GC va passer son temps à collecter des petits objets ».
Dans le cadre d’un langage sur une VM, comme C#, Java ou Scala, n’oublions pas tout d’abord que le JIT (compilation à la volée) va introduire un certain nombre d’optimisations, particulièrement pour ce qui concerne la mémoire. Pour réellement porter un jugement (« je crois que le GC va faire beaucoup de garbe-collecting ») encore faut-il maîtriser le fonctionnement du JIT.
Ensuite, dans le cadre de certains langages fonctionnels comme Clojure et Scala, c’est un point qui est justement adressé intelligemment par les concepteurs des langages. Rien que ce point vaudrait un article pour comprendre le fonctionnement de la JVM.
Posez-vous les questions suivantes : pourquoi les Strings en Java sont immuables ? Pourquoi la concaténation d’un million d’élément ne produit pas d’OutOfMemory ? Pourquoi puis-je associer 2 chaînes de caractères et faire une phrase ? N’y aurait-il pas un monoïde derrière tout cela ?
En conclusion sur ce sujet : à découvrir
Event Sourcing, DDD and F# a match in heaven par Jérémy Chassaing
Jérémy est un excellent orateur, passé déjà par Devoxx France, afin d’y présenter CQRS (Command/Query/Responsability Segregation). Il a effectué un exercice de live-coding en F#, sur les règles du jeu de UNO.
D’un point de vue modélisation tout d’abord, c’est un exercice intéressant. Jérémy modélise le jeu comme un ensemble de commandes, et entre autre un enchaînement d’événements, le tout en F#. Pour n’avoir jamais fait de F#, j’ai compris. Mais clairement, c’est grâce à mon expérience Scala. On retrouve des principes, que j’ai même trouvé plus simple en F#.
Côté domaine, on retrouve une Card, décliné en Color et ActionCard. Pour les commandes : StartGame, FirstCard et PlayCard. Les événements : GameStarted, CardPlayed. Tout est suivi avec une machine à état simple, qui permet de connaître le joueur courant, la carte du dessus du paquet, etc.
L’exercice permet surtout de comprendre l’importance de la distinction entre ce qui est commande, et ce qui est état. A juste titre, Jérémy explique que l’approche de Martin Fowler, pour ce qui est CQRDS, est incomplète.
J’ai trouvé aussi que l’exemple utilisé était tout à fait pertinent pour démontrer l’importance de l’approche fonctionnelle, pour résoudre ce type de problème. DDD apporte ici encore une fois quelques principes qui marchent très bien avec la programmation fonctionnelle.
Conclusion et petit bilan perso
Cela fait du bien, de sortir un peu de la sphère Java. Et d’aller voir d’autres sujets, sans forcément tout comprendre. En tous les cas, je vous encourage l’an prochain à venir participer. Tous les développeurs .NET (mais pas que…) et surtout, les personnes intéressées par ce qui est DDD ou fonctionnel.
A suivre donc.
Références:
- Site de la conférence NCrafts France
- Introducing EventStorming by Ziobrando
- Présentation CQRS de Jérémy Chassaing, Devoxx France 2012
- Le jeu de UNO
0 no like
Si tu apprécie de sortir de la sphère Java, il y a des conférences qui ont la mixité dans le sang – le BreizhCamp par exemple 😛 – c’est en effet très enrichissant et rafraichissant.