Delègue Alexandre

L'architecture hexagonale est probablement mon défaut quand je setup un projet. Quand on suit certaines précos, cette architecture peut sembler intimidante, voir compliquée, à tel point que peut se dire : tanpis, je vais commencer simplement / autrement, et on verra après.

Moi, je pense qu'au contraire, on peut commencer en archi hexa de façon simple et monter en puissance ensuite. Et même si on fait quelques entorses, ça sera toujours mieux que de ne pas le faire.

J'aime bien écrire du sql et donc par conséquent, je ne suis pas trop fan d'ORMs, voir un peu plus.

Comme seulement râler n'est pas très constructif, dans cet article, je vous propose une solution pour exécuter des queries graphql sans ORM, en écrivant du sql avec postgresql.

Cette fois, on va aller encore un peu plus loins : on va écrire notre propre monade ! N'ayez pas peur tout est sous contrôle !

Si vous faites du webflux, avec du code métier, allez y les yeux fermés !

Dans l'article précédent, on a parlé d'immutabilité qui limite une partie des effets de bord, en empêchant la modification de variable en dehors du scope de fonctions. Cette fois-ci, on va aller plus loins, en traitant : les exceptions, les IO, les dates ou les traitements aléatoires.

Dans le post précédent, on a vu les fondations de la programmation fonctionnelle. Ici, on va s'intéresser un peu plus en détail à l'immutabilité en java.

La version 8 du jdk a amené la programmation fonctionnelle en java, notamment, avec les fameuses lambda et les streams pour les collections.

Mais peut-on réellement faire de la prog fonctionnelle en java ? Dans ce post, on fera un tour de quelques notions de prog fonctionnelle et on verra ce qu'on peut faire en java.

Le sharding est un algo très utilisé dans le monde des systèmes distribués. C'est un algo assez simple, qui pourrait aussi vous aider dans vos développements de tous les jours.

À la MAIF, je travaille sur les données de connaissances de la personne. Ces données étaient gérées par un CRM du marché, un peu vieillissant. Sur le cœur de métier, la MAIF a choisi le "build" à la place du "buy" et donc sur ce périmètre, on remplace le CRM par un applicatif fait main, réalisé par une équipe d'artisans.

Une des taches, qui nous occupe pas mal, c'est, de synchroniser les données entre le CRM et notre applicatif, que ce soit dans un sens ou dans l'autre. Pour ce faire, nous avons mis en place une architecture logicielle que je vais présenter ici.

Le "property based testing" est un type de tests souvent utilisé en programmation fonctionnelle pour valider des lois. Il y a quelques années, j'avais testé jqwik, une librairie de property based testing en java, pour valider des lois sur une lib d'optics en java (ouais je sais, ça à l'air de ne rien vouloir dire cette phrase). Je n'étais pas allé plus loins que ça.

Cette année à Devoxx France 2025, j'ai assisté à un talk de Pierre Zemb "Et si on faisait du simulation-driven development ?" dans lequel il évoquait le property based testing pour tester du code métier.

Voyons ce que ça peut donner en java pour tester une application spring.

À la MAIF, le flow de dév le plus communément appliqué, c'est du gitflow et du scrum. Personnellement, j'ai du mal à comprendre le gitflow et je ne comprends pas à quoi sert la branche develop du moins pour le développement d'application. Les branches support ne sont pas utiles car, on ne maintient qu'une version de notre application à un moment donné. J'ai également l'impression que la branche master et develop finissent obligatoirement par avoir un historique divergent, à moins de rebase develop à partir de master de faire un force push.

En ce qui concerne le scrum, je trouve que ça génère une pression continue, on est toujours en train de se prendre la tête sur les stories pour savoir si ça va rentrer ou non dans le sprint. Ça n'est pas très chill comme méthode.

Depuis quelques années sur notre projet, nous avons mis en place un flow un peu atypique à base de trunk base. C'est ce que je vais vous présenter ici.