SOLID -> CUPID -> Cute DDD en

Un regard et présentation de "bonnes pratiques" de conception orient-objet et architecturale. Avec du code et une problématique très complexe.

Code is the new Res Publica en fr

"A Battle for Power"

To you, code might just be a sequence of instructions executed by a machine or running in the cloud.
But in reality, it is much more than that.
Can we even begin to grasp what’s truly at stake?

Code is the vehicle that reveals how companies are structured — from their darkest corners to their brightest ideals.
It’s not just a technique; it’s a mirror.
What if, just once, we dared to look through it?

Because of the diversity in how code is produced in companies, the many possible forms of organization,
and the different credos and “chapels” created by code makers themselves,
I’ve witnessed countless conflicts and outcomes — some fortunate, others not — some polished, others left unfinished.
Code is a story written by humans — leads, engineers, testers, POs, SMs, EMs, CTOs…
And in the end, if things go well, something gets delivered: a product… or more.

I’ll reframe all of this in the broader context of human societies and the evolution of Work.
And I’ll try to answer these six questions:

What is code?

What stands behind the power to write code?

Is there a secret society inside your company?

What’s at stake in the struggle for power?

What forms does power take?

What are the techniques of power?

https://docs.google.com/presentation/d/1iqDs9J_DszTC1ytdnoa96W-GBaCErcKvK4-yG46oCsg/edit?usp=sharing

Le code est une Res Publica en fr

"Une bataille pour le pouvoir"

Pour vous, le code n'est surement qu'une suite d'instructions exécutées par une machine ou dans un cloud.
Mais il est en réalité tellement plus que cela.
Pouvons-nous même, nous faire une idée réelle de tout ce dont il est l'enjeu ?

Le code est le vecteur de l'organisation des entreprises, jusqu'à ses idéaux.
Ce n'est pas une technique, c'est un miroir.
Et si nous osions regarder au travers, pour une fois ?

À cause de la diversité à produire du code en entreprise, à cause de la multiplicité formes d'organisations possibles,
mais aussi des différents credo ou chapelles qu'ont créées les "faiseurs" de code; j'ai pu voir nombre de conflits, de résultats plus ou moins heureux, plus ou moins achevés.
Une histoire avec des humains, des chef-fes, des technicien-nes, des testeur-euses, des PO, des SM,EM. CTO...
et au final, si tout se passe bien, un ou des produits…

Je remets tout cela en perspective avec les grandes Sociétés Humaines et l'organisation du Travail.
Et je répondrai à ces 6 questions :
Qu’est-ce que le code ?
Qu’est-ce que le pouvoir de faire du code ?
Y a-t-il une société secrète dans votre compagnie ?
Quels sont les enjeux du pouvoir ?
Quels sont les formes du pouvoir ?
Quelles sont les techniques du pouvoir ?

https://docs.google.com/presentation/d/1iqDs9J_DszTC1ytdnoa96W-GBaCErcKvK4-yG46oCsg/edit?usp=sharing

Tout ce que vous avez voulu savoir sur les Doublures de Tests sans jamais avoir osé le demander en 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.

Tout ce que vous avez voulu savoir sur les Doublures de Tests sans jamais avoir osé le demander en 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.

Atelier Mob TDD et DDD, tester une architecture Hexagonale fr en

En 3 ou 4h, nous allons apprendre à mettre en oeuvre le TDD de manière concrète, avec une approche DDD pour un cas métier, et des adapters vers des services externes. Un cas simple qui fait se poser beaucoup de question. Préparez vous à être surpris.

Comprendre les tests unitaires et le besoin de doublures dans un début d’architecture hexagonale; clarifier ce que l’on appele doublure de tests.

workshop TDDD : Hexagonal testing with Doubles fr en

You're asking yourself: how to practically isolate my domain code from moving parts like databases or external systems, APIs... in the simplest way either. How can I do that without integration testing. Are Unit Test sufficient? Can I apply TDD literally?
I've heard about mock as a perfect solution to test my dependencies.
Well, we need to talk. Better than that: we need to code!
Let's work on a very concrete and representative example. And let's mob it!

Format: 3/4h ( live coding/workshop) ; fish bowl MOB programing
Isolate domain rules and invariants
Add external system and test then
Learn about test doubles : stubs, spy, fake, mocks
When and how to use it? How to avoid mocks.

We will work on Concrete examples:
- ask time / generate random values (like UUIDs)
- send a mail / print an invoice
- access to an external resource (like a file)
- invoke a read/write repository
- summon an API
Showing what’s legitimate and what’s beyond reason

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.

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

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

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: 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 think about 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 Kotlin, and presenting a concrete example of testing the Hexagonal Architecture with and without Test Containers
Code is here:
https://github.com/Guillaume-Music-Action/Tester_Hexagone_Parcmetre
https://github.com/music-action/how-to-test-the-hexagon-kotlin-2024

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
https://github.com/Guillaume-Music-Action/Tester_Hexagone_Parcmetre

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.

What is a testable architecture? en fr

Software architecture has so many facets, so many variations.
A true matter of style, a patchwork of proposals, influenced by fashion trends sometimes.
But how testable is yours?
And what is a good test, in your humble opinion?
What are the genuine characteristics of effective tests?
What are your expectations when it comes to bring your systems under tests?
Let's analyze those crucial, almost philosophical questions (I doubt, therefore I test? Or the opposite ?).
Integration(s), connascence and testability are crucial to question when time comes for architectural choices.

Qu'est ce qui rend une architecture logicielle testable ? en fr

On parle beaucoup de TDD, avec toujours, hélas, beaucoup de polémiques.
La qualité d'une solution logicielle, d'un produit fiable ne peut pas se résumer à une couverture de tests.
L'architecture logicielle a tant de style différents, tant de variations, de chapelles même.
Dans ce maelstrom de propositions, souvent trop influencées par des tendances de mode, laquelle choisir sous l'angle de la testabilité ?
Et d'abord, qu'est-ce qu'un bon test, selon votre humble avis ? Quelles sont les véritables caractéristiques de tests efficaces ?
Quelles sont vos attentes lorsqu'il s'agit de soumettre vos systèmes à des tests ? (couverture de code, expressivité, stabilité, vitesse de feedback, qualité des reports, lisibilité, maintenabilité).
Les tests sont aussi importants que votre code ? Sans aucun doute, ils subissent lourdement les conséquences de vos choix d'architecture logicielle.

Analysons ces questions cruciales, presque philosophiques, que dise je ! Je doute, donc je teste ? Ou l'inverse ?
L'intégration, la connascence et la testabilité sont des aspects cruciaux à questionner lorsque vient le temps des choix architecturaux.

.Net Core Testing: pushing the limits en

Let's discover and unleash the power of automated testing using xUnit with related technologies such as Containers and Benchmark Testing.
I invite you to a journey through several testing techniques, from simple to advanced.
We will cover solitary tests, then social tests, and going deeper into test containers and testing a rest API, but staying in the Unit test layer, not E2E. That's where we introduce UniTegration.
Live coding, real world enterprise oriented C# examples. Testing is believing.

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

History of .Net, how Microsft got rid of Windows en

In a short 30mn talk, I will visit the history of .Net SDK and show you how Microsoft, to embrace Docker and Cloud Based applications, definitively abandoned Windows, enabling DevOps teams to seamlessly build Open Source-based software architecture for the Web.

Des Erreurs sans se tromper fr

“errare humanum est, perseverare diabolicum”

L'erreur est humaine, persévérer [dans son erreur] est diabolique.
C’est dit.
Dans le code, persévérer à gérer des erreurs à l’infini est diabolique.

Il est temps d’envisager la gestion des erreurs d’une manière différente, plus rationnelle, et plus simple surtout.
Et d’abord, de quelles erreurs parlons-nous?
Il serait bon de les cartographier pour mieux les comprendre.
Pour ensuite envisager une gestion souple et cohérente.

Dans cet atelier, prenons le temps de nous mettre en situation et appliquons quelques stratégies connues, et d’autres, moins usitées, sur des exemples typiques du code que l’on voit en production.
Comparons et évaluons les avantages et inconvénients.
Il n’y a pas de solution unique, ni d’approche magique.

Pas de besoin d’environnement de développement pour participer à cet atelier, vos propositions seront traduites en code par notre driver.
Le code sera élaboré en Mob Programming, les échanges avec tou-te-s les participant-e-s permettront de considérer les différentes options. Vous sortirez de cet atelier alors moins démunis pour vous attaquer à cette problématique dans votre base de code de tous les jours.

Java, Kotlin, C# ou typeScript

Dev <3 Ops : a deep experience at ITER en

Like many developers, production sometimes felt like a galaxy far, far away from my daily coding routine.
And anyway, my code works on my machine. Let the infrastructure specialists just to do their job! (sic)

… That was me, before.

But for almost two years now, everything has changed.
Sure, I got into it a bit lately. But I really ran into it.
That being said, I haven’t become a DevOps engineer. And let’s be honest—that title doesn’t even have sense. Just another HR invention, as if they weren’t already busy enough hunting for five-legged FullStack unicorns… but I digress.

I’m considering myself “just” as a Dev who loves Ops.
Someone who knows how to work with them, who understands them.
Who enjoys sharing knowledge and learning from them in return.
Who embraces their challenges too—for better or sometimes for worse. Everything can happen.

Let me tell you how this all came to be, and why I’d be truly unhappy if I ever had to go back to a "simple" developer role.