Comment embarquer PO, Devs, Testers, SM dans le même bateaux en 4 ateliers en

DDD ou Domain Driven Design rassemble une foisonnante palette d'outils qui s'adressent à tous les membres qu'un équipe ou entreprise Agile.
"Ce qui part en prod, c'est ce que le dev a compris", cette phrase n’est pas anodine.
Avec Rachel Dubois, nous avons entrepris de présenter un certain nombre d'ateliers phares pour faire toucher du doigt la réalité de DDD et de ses bénéfices.

Nous vous proposons de revenir sur les temps forts de ces ateliers : Domain Story Telling, Event Storming, Context Mapping, Wardley Mapping, et même Mob Programming.

Nous y avons embarqués avec joie autant de SM, PO, testeurs/euses et devs.
Les Grenoblois résisteront-ils à la tentation de nous rejoindre ?

Profession Développeur: prisme de la société ou singularité? en

Assurément, mon titre aurait dû être "Profession développeur-euse"... et ce sera là mon premier constat :
Qu'avons-nous de si particulier pour que les femmes soient à ce point sous-représentées ?
Et, si c'était là le seul biais... il y en a tant d'autres.

Après 30 d'évolution dans ce métier, je propose une véritable introspection.
Que dis-je ? Une catharsis !!
J'aborderai des sujets sociétaux, mais également des aspects socio-économico-professionnels.
Mais, aussi un peu de technique. Car nous, Développeurs/euses, nous adorons nous compliquer la vie pour paraitre toujours plus des incontournables. Hors, personne n'est irremplaçable, et le mythe du Cowboy coder macho n'a pas encore disparu :(

L'idée est de faire réfléchir tout le monde à la place des uns et des autres dans cet univers particulier qu'est la création de logiciels.

Ecologie du logiciel, en route vers la simplicité en fr

Dès le début du projet, les équipes se perdent dans la complexité
technique, organisationnelle et par manque de clarté dans la vision PM/PO...
La complexité est la soeur jumelle de l'entropie, elles augmentent exponentiellement au cours de la vie du produit.
Nous nous pencherons sur une adaption des principes d'entropie et néguentropie sur l'axe du Product Management et sur l'axe technique.
La complexité est même souvent accidentelle. Une fois installée, elle est difficilement réversible.
“Faire simple c’est difficile”.

Nous vous proposons de voir des stratégies simples, mais exigeantes, pour une simplicité retrouvée et un développement logiciel soutenable.

Ecologie du logiciel, en route vers la simplicité en fr

Dès le début du projet, les équipes se perdent dans la complexité
technique, organisationnelle et par manque de clarté dans la vision PM/PO...
La complexité est la soeur jumelle de l'entropie, elles augmentent exponentiellement au cours de la vie du produit.
Nous nous pencherons sur une adaption des principes d'entropie et néguentropie sur l'axe du Product Management et sur l'axe technique.
La complexité est même souvent accidentelle. Une fois installée, elle est difficilement réversible.
“Faire simple c’est difficile”.

Nous vous proposons de voir des stratégies simples, mais exigeantes, pour une simplicité retrouvée et un développement logiciel soutenable.

Développeurs·euses : facilitez-vous la vie en (re)apprenant à lire. en

Dans nos écoles, nous avons appris à lire avant de savoir écrire. D'après les méthodes usuelles d'enseignement, Comprendre un texte, c’est se faire une représentation mentale cohérente qui intègre toutes les informations du texte. Ces principes s'appliquent tout aussi bien à la compréhension de n'importe quel code logiciel. Car nous avons tous fait l'expérience de lire du code qui ne nous appartenais pas ou même nos propres productions.

Nos constats sont les suivants:

Il est souvent difficile et compliqué de lire ou de relire un code source.
C'est une activité pénible et démotivante pour grand nombre des développeurs.
Et si la raison ne tenait qu'a notre méconnaissance des mécanismes de fonctionnement de notre cerveau ?

Venez explorer, expérimenter et apprendre comment fonctionne notre cerveau lors d'un atelier de lecture d'un code source Et tirez profit de ces nouvelles connaissances pour améliorer vos capacités de lecture ainsi que la lisibilité de votre code source.

L'atelier se base sur les exercices proposés par Felienne Hermans dans son ouvrage "The Programmer's Brain".

TestContainers: turning the Pyramid of Tests upside down en fr

Docker has changed the world of IT (and is still changing it). It's not just about infra or ops. It really is devOps. And in devOps, there's dev.
Developers have everything to gain from using Docker, but sometimes it can seem complicated or cumbersome. That's where TestContainers come in. A technology available for a large number of development frameworks (Java/Kotlin, Python, NodeJs, .Net, Ruby...) . It will change the way you design unit and integration tests.
As I will show you working code and tests, this will be a good opportunity to return to the true meaning of some magic terms and to talk about the famous test pyramid, once again.

slides are here https://docs.google.com/presentation/d/1TMiNdJxUmbzkcGPHCEuW9_qKHI4uglVcMzFR0Ic8pTc/edit?usp=drive_link

This session comes with a hands on lab , using C# or Kotlin, and presenting a concrete example of testing the Hexagonal Architecture with and without Test Containers
Code is here:
https://github.com/music-action/how-to-test-the-hexagon-kotlin-2024

JAVA: 2 weddings and a funeral en

Java is old. But Java is moving.
Let's dive into history,what are the major changes other the years.
Discover the good, the bad and the ugly.
Let's look to the future !
New way of programming is reaching the Java community (too).
But is not always clearly understood. And even less apply.
Let's demystify the progress. New times are now!

You will learn how Java evolved quickly recently and try to understand why people are slower to make the move.
Also, we will cover the true game changer in Java programming styles and foresee how to move to more modern patterns: the functional way !

Hexagonal Architecture, let's test! en

The hands-on workshop for Hexagonal Architecture, Clean archi, Onion layers, etc... you name it.
One of the most discussed software architectural pattern.
And subject to a wide range of various interpretations.
You may already know a bit or a lot about it.
But what's its advantage, whenever you implement it?
Tests !!!!
You want to experience them for real ?
So let's dive into practical and real life examples and tactics.
Mob coding coming from excerpts from the trenches.
TDD all the way. C# Net Core or Kotlin. CI/CD in mind.
Unit tests, mocks, fake, ArchUnit, Mutation testing in one day.

A practical workshop to show you how to decide between unit test, integrations and so on. Mock it or fake it? Fake it until you make it? Let's go deeper into a concrete, full working example.

Worskhop sources:
https://github.com/music-action/how-to-test-the-hexagon-kotlin-2024

How to test the Hexagon? en

You've probably heard or even practice Hexagonal Architecture, Clean architecture, Onion layers... you name it.
Perhaps one of the most discussed software architectural pattern.
Strangely, its implementations are subject to a wide range of interpretations.
But, undoubtedly, its major advantage, whenever you implement, is ... Testability !!!!
Somehow, it has been forgotten.

So let's dive into practical, real life examples and tactics.

Quick Live coding and samples from the trenches included.
TDD all the way. C# Net Core or Kotlin.

This conference comes with a workshop where you will mob on a concrete example.
https://github.com/music-action/how-to-test-the-hexagon-kotlin-2024

Slides are here:
https://docs.google.com/presentation/d/1SSBVGOQQK-vMRIJfDtYu-01PGvweMvcTnQx9a4wkHHE/edit?usp=drive_link

Monads without Maths, but with Cats (live coding) en fr

You heard about Monads, but the maths behind it seems unreachable? Let's demystify it with an
hands on lab based on TDD and C#/Java/Kotlin (your choice) to simply have fun with Monads and never be afraid of them.
We will auto-learn about simplicity, clarity, Unix style, and fun(ctors).

PLan:
Common Issues in Code
Basic Principles of a Monad
A Simple Case: Option
Where to Find Monads?
Hands-on: TDD Mob Programming
What to Do with a Monad?
Further with Either... or Maybe
Let's Chain, Let's Bind...
Practical Case: Monads in a Web API
Further: Validation
Attention: Treat Your Monad with Respect
Comparison of Styles (What Is Complexity?)

https://docs.google.com/presentation/d/1VPWqxxqrudsR001B0mXeSCY3bdjvT_xdqbsCxj3Kqck/edit?usp=sharing

What is simplicity, really ? en

Define simplicity is no simple.
Everyone has its own definition
Simplicity is cultural
Simplicity is hard
Simplicity is not a bestseller
Simplicity is not speed
Do we (really) learn simplicity?

after those fundamental questions, we will dive into some real life experiences (of mine):
Strategic Simplicity
- In Product Vision
- In design

Tactical Simplicity
- In architecture
- In code
- In testing strategy

Unfortunately, we'll cover a lot of fallacies. Because, once again, simplicity is not obvious, for humans at least.

A basis for a general discussion on the necessity of KISS that remains hard to achieve.

Workshop: Practical guide to Monads for those who don't like maths en

You heard about Monads, but the maths behind it seems unreachable? Let's demystify it with an
hands on lab based on TDD and C#/Java/Kotlin (your choice) to simply have fun with Monads and never be afraid of them.
We will auto-learn about simplicity, clarity, Unix style, and fun(ctors).

PLan:
Common Issues in Code
Basic Principles of a Monad
A Simple Case: Option
Where to Find Monads?
Hands-on: TDD Mob Programming
What to Do with a Monad?
Further with Either... or Maybe
Let's Chain, Let's Bind...
Practical Case: Monads in a Web API
Further: Validation
Attention: Treat Your Monad with Respect
Comparison of Styles (What Is Complexity?)

the code:
https://github.com/guillaumeagile/MonadsFromTheTrenches_workshop
the slides:
https://docs.google.com/presentation/d/1VPWqxxqrudsR001B0mXeSCY3bdjvT_xdqbsCxj3Kqck/edit?usp=sharing

Petits biais et grands travers du développement logiciel en

Faire partie de la grande famille des développeurs... quoi de plus rassurant? Nous aurons du travail à l'infini.
Oh, vraiment?

Nous savons coder, nous savons faire ce que les autres ignorent. Nous sachons. Nous dirigeons le monde. Car le logiciel dirige le monde.
Ils exigent de nous de la rapidité, pas de problème, nous livrerons à temps.
Puissants et obéissants, quel joli paradoxe.

Et pourtant, nous ne sommes pas au dessus de la mêlée.
Cette belle profession a besoin d'un bon coup de ménage, et surtout de balayer ses propres certitudes.
Let's do it!

Mental load for developers, how to reduce it ? en

As a developer, you may have asked yourself that question: why is it so difficult? why is my brain twisting when I see that code? Is it too complex? too simple?
Those questions are simply about the cognitive efforts required when doing or entering a project.
Is there way to tackle it? at least lower it?
But what if, complexity (and its counterpart, simplicity) might not have the same definition for everybody?
Well, we will show up how and why mental load applied to software development is a trap.
And, as Franck Herbert said: “Knowing where the trap is—that's the first step in evading it.”

Le monde n'est pas CRU(D), il est vivant! en

"Tu veux un logiciel? bah tu n'as qu'à prendre une base de données, un ORM, rajoute une API REST" (parce que c'est la mode) :
"et voila!"

Ajouter, modifier, supprimer... et se planter!
Tout ce qui vient avec le monde CRUD est une simplification de la réalité qui fait froid dans le dos. En étant aussi simpliste, les applications en deviennent horriblement complexe: transactions, verrous, exceptions, mutations... que des sources d'ennuis.

Venez voir comment on peut se débarrasser du mal à la base. Oui le monde évolue en permanence, et votre façon de programmer aussi.
Trop compliqué? En 1h30 de live coding, donnez naissance à du code fermé à la modification mais ouvert à l'infini.

Ensemble programing: revue de code et refactoring par petits pas en

Cet atelier vous permettra de travailler vos revues de code, et de refactorer en toute sécurité grâce à une bonne couverture de test.

Pas à pas, nous travaillerons sur une base de code très améliorable (à dessein), et nous appliquerons un à un des contraintes de qualité, dont nous discuterons ensemble dans une phase préalable de revue de code.
Ensuite, tous ensemble (mob programming), au boulot ! Il nous faudra améliorer, c'est-à-dire refactorer, sans casser le comportement attendu. Pas de panique, nous fournissons les tests automatisés.

Cela nous permettra d’apprendre différentes techniques de factoring , utiles à la maintenance et lisibilité de votre code.

Cet atelier se base sur le kata de Pedro Santos.

Développeurs, réduisez votre charge mentale! en

Haaaaa, la charge mentale. Encore un truc de coach agile :D
Et si nous appliquions le concept aux développeurs et aux testeurs?
Imaginons nous réellement tout ce qui ce passe dans la tête de ceux ci? et surtout comment faire pour alléger la pression!
Des moyens, il y en a tellement.
Et pourtant, les développeurs eux même rechignent à simplifier leur code.
Allons voir ensemble pourquoi...

L'invasion des mutants dans votre code (oui mais pour votre bien) fr

Tester c'est être agile, car c'est être confiant dans le produit qu'on livre. Vous faites probablement du TDD, ou au moins vous essayez d'écrire des tests. Vous vous vantez même d'avoir une bonne couverture. Mais résisterez vous à l'invasion des mutants?
Cette pratique de test peut faire peur, et pourtant... Quelle puissance! Quelle exigence!
Ce n'est pas (que) un outil de test, c'est (aussi) le gardien de la qualité de votre code. Et il ne tergiversera pas!
Etes vous prêts?

Tout ce que vous avez voulu savoir sur les Doublures de Tests sans jamais avoir osé le demander fr

Vous vous posez des questions sur les doublures de tests ou ce qui est généralement et abusivement dénommé “mocks”.
Venez apprendre et comprendre ce que sont les bouchons, dummy, stubs, fake, spy et mock. Quand et pourquoi les utiliser en situation réaliste, et l’usage d’un fake versus un spy.

DDD: des outils pour le PO (mais pas que) fr

"Ce qui part en prod, c'est ce que le dev a compris", cette phrase n’est pas anodine et Guillaume l’utilise même souvent.

La relation entre le PO et les devs devrait être fusionnelle, au moins intense, animée, vivante et surtout permanente. Le PO doit parler le langage de son client et de son univers (le fameux "domaine"). Le dev doit parler le langage du PO.
Transitivité : Le dev doit parler le langage des utilisateurs, même et particulièrement dans son code. C'est un des piliers de DDD (Domain Driven Design). Mais sans le PO, le dev ne peut pas y arriver.
DDD vient avec une foule de sages conseils et d'outils extrêmement pratiques. Bien connus des développeurs, ils sont encore trop confidentiels dans le monde des POs/PMs.
Je vous invite à une rencontre...

Les monades sans les maths (live coding) en fr

Les monades ne sont pas qu'un OVNI mathématique, mais un vrai paradigme de programmation qui peut s'utiliser à peu près partout dans votre code.
Quel que soit le langage. Peu importe les situations.
Je vous propose une brève intro orientée "pratique" et surtout du live coding avec du TDD pour démystifier la librairie LanguageExt que nous avons en C# / .Net

Vous allez voir, ça ne mord pas, ça ne griffe pas.

Etes vous prêt à arrêter de coder avec des null, des if, des loops, des exceptions et tout autre cochonnerie ?

slides:
https://docs.google.com/presentation/d/1VPWqxxqrudsR001B0mXeSCY3bdjvT_xdqbsCxj3Kqck/edit?usp=sharing

TestContainers: la révolution pour vos tests unitaires en fr

Docker a bouleversé le monde de l'informatique (et est encore en train de le faire). Ce n'est pas qu'une affaire d'infra ou d'ops. C'est vraiment du devOps. Et dans devOps, il y a dev.
Les développeurs ont tout à gagner à utiliser Docker, mais parfois cela peut paraitre compliqué ou lourd. C'est là qu'entrent en scène les TestContainers. Une technologie disponible pour un grand nombre de frameworks de développement (Java/Kotlin, Python, NodeJs, .Net, Ruby...) que je vous propose d'utiliser pour vos tests unitaires et d'intégration ; une bonne occasion de revenir sur le vrai sens de ces 2 termes et de parler de pyramide de tests, une fois de plus.

slides are here https://docs.google.com/presentation/d/1TMiNdJxUmbzkcGPHCEuW9_qKHI4uglVcMzFR0Ic8pTc/edit?usp=drive_link

This session comes with a hands on lab , using C# or Kotlin, and presenting a concrete example of testing the Hexagonal Architecture with and without Test Containers
Code is here:
https://github.com/music-action/how-to-test-the-hexagon-kotlin-2024