Few months ago, I’ve read this article: How We Built a Self-Healing System to Survive a Terrifying Concurrency Bug At Netflix.

What I loved is how unconventional the solution was. However, unconventional doesn’t mean irrelevant, their solution kept the software running during the weekend, and this without any human intervention. The solution wasn’t perfect, but it was “good enough” and even more, respectful of people’s time.

By the end, it concludes with a concept that somehow inspired me: “technological adulthood”.

Recently, Antoine Caron published a blog post about his AI usage. Thanks to him, I’ve discovered the /ai ‘manifesto’ and I want to do the same here. Maybe you’ve reached this post by typing /ai in the URL.

My posts

All the posts in this blog are written by myself, I don’t use any generative AI to produce content.

Creating a blog post is an interesting activity, it requires me to challenge and organize my thoughts before trying to write on a topic. Today, I use this blog as a place to put thoughts that I think are worth writing about and sharing.

In early 2020, I’ve read the book Programming Elixir 1.6. At that time I had one goal: to have an introduction to the actor model with a language that supports it by design, in this case Elixir. I think it was a good read and I achieved my goal, even though I didn’t feel able to design a complete system using this pattern.

However, I realized I’m using some actor model concepts for a few years now. In my previous post, I’ve mentioned types of effects produced in a CQRS/ES system, one of them is triggering new processes.

If you’ve already developed a software using the event sourcing pattern, you’ve probably faced difficulty: How-to design good events? What is a good event granularity?

Indeed it’s difficult to produce good events that will not harm our design. As a seasoned developer with event sourcing, I’m still struggling with this, even if I’ve developed several heuristics over time.

In this blog post, I will share with you these heuristics. But keep in mind this is not some kind of best practices. Best practices are useful for contexts where we can apply a method without any (major) form of adaptation, there’s nothing that simple when developing a custom software for business. The following heuristics are rather a way to ask ourselves good questions and drive our thinking.

Nowadays, most of the services we’re using are online and available 24/7. If, like me, you’re working on a company that provide this kind of service, you’re probably aiming for such availability. As I’ve already highlighted it, it has a huge influence on how you should code and deploy your software. Indeed, to maximize availability, you’re probably aiming for a zero downtime deployment.

Zero downtime deployment includes several topics. Today I want to focus on how to achieve a database migration without service interruption.

Nouvelle présentation, nouveau co-spreaker ! Cette fois-ci, c’est Aurélien BOUDOUX qui m’accompagne pour vous proposer un retour d’expérience sur nos années de développement avec le pattern CQRS/ES.

Fun fact : nous avons eu l’idée de ce talk parce que nos pratiques semblaient converger malgré des expériences très différentes. En construisant ce talk, nous avons découvert qu’en réalité nous avons des pratiques très différentes, et que celles-ci sont en grande partie issues de nos contextes respectifs.

I’ve recently gave a talk with my friend Aurélien about the heuristics we’ve developed after using CQRS/ES for several years.

After our talk, we had a chat with some developers. We concluded that choosing a state-based oriented approach (like CRUD) seems to be the default solution, such choice seems to remain unchallenged. On the opposite side, choosing an event-based systems (event sourced or event driven) will very often be heavily challenged.

Thinking in events

In a previous post, I’ve expressed some kind of thought experiment to highlight how natural events can be:

Clap de fin pour cette présentation, nous avons donné notre dernière session le vendredi 26 avril à MixIT. J’ai eu grand plaisir à présenter ce sujet si particulier avec mon co-speaker Olivier PONCET.

Abstract

Lundi 21 juillet 1969, l’humanité posait pour la première fois le pied sur la Lune. Cet exploit est le fruit de nombreuses avancées techniques et technologiques, notamment en électronique et dans le domaine de l’informatique alors naissant. Pour mener à bien leurs missions, les astronautes s’appuyaient sur l’AGC, l’ordinateur de bord du programme Apollo qui permettra de réaliser ces exploits.

I had the chance to work few months in Agicap, an enterprise producing a cashflow management SAAS for businesses.
It was a great mission, my team worked a way that I consider to be, so far, the most efficient and pleasant in my career. We managed to produce value at a constant speed while keeping a full control of our code, not allowing any kind of quality depreciation over time.

This blog post is just a recap of all practices we had in place and why I believe it was beneficial for us. Please, keep in mind we chose these regarding our context, this is not some sort of silver bullets list.

Tout part d’un talk donné par Emilien PECOUL (aka Ouarzy). Durant ce talk, celui-ci a tenté de démontrer à son audience qu’elle connaissait déjà la plupart des concepts formulés dans la théorie des catégories. À mon sens, il y est parvenu même si ce sujet est bien trop vaste pour être abordé en seulement 45 minutes.

C’est pourquoi quelques années plus tard, il m’a proposé de le réadapter avec lui sur un format université (3 heures).