In the previous post, we’ve introduced the Elm Architecture (TEA) and then wrote a PReact component to implement this pattern. Today it’s time to use it! If you haven’t, I recommend that you read the first post before continuing on this one.
If you have been searching for resources about the Elm Architecture on the internet, you must have encountered the “counter” example. This is literally the Elm Architecture’s “Hello world”.
A few months ago in my post Reaching a limit of Reactive Programming, I’ve mentioned the MVU (Model-View-Update) pattern could be a solution to the problems I was encountering at that time. I’m now using MVU since a few months on other projects and I want to write my own article where I present this pattern in more details.
This post is the first of a four-post series. We’ll be working on webpages, but this pattern can be used in other contexts like desktop applications.
If you’re working in IT, you’ve probably already encountered the “No deployments on Friday” mantra/dogma. It’s so ubiquitous that they’re many memes about it on the internet.
Recently, one of my LinkedIn relations commented a post that way saying something like “If you had to deploy today (Friday) and it went wrong, I’m sorry for you.” In his comment, he argued that he had shipped more than 10 versions that day and it was no big deal for him, starting a discussion with the author of the post. As I was reading them, I realized they were both right, and above all, by their positioning about “no deployments on Friday” I could make a lot of guessing about their respective business and organizational contexts as well as their technical practices.
I’ve recently finished reading Real-World Event Sourcing. It was a fun reading, but I found the book unclear on a very specific point and I want to express my thoughts on it in this blog post. I may have misinterpreted the author’s explanations but this doesn’t invalidate the following reflection.
As the book is about Event Sourcing and CQRS (Command Query Responsibility Segregation), events are naturally the central building block: they’re used to store states and trigger effects in the system.
In my career, I had (and still have) many opportunities to develop UIs on desktop and web applications using various technologies. With these experiences I’ve been using two main patterns: MVVM (Model-View-ViewModel) and a Reactive approach.
In this post, I want to talk about the Reactive approach and especially about two features where it has become a burden to me.
I am not talking about a specific framework here. By Reactive I think of a specific way to code and organize behaviors for a UI.
In a previous post, I’ve mentioned I’ve read the book Programming Elixir 1.6.
As I was planning to read Real-World Event Sourcing, I chose to conduct a second reading because my limited knowledge and skills with Elixir were eroded over time. I took time to take many notes which are available on a dedicated repository.
In this post, I want to present to you the Elixir language, the Erlang VM and give you a taste of why you should learn it even if you will not use it in production.
A few weeks ago, I’ve published a post where I described improvements for various architectures, following a logical path from a CRUD architecture to a CQRS/ES implementation.
Since then, I participated in Lyon Craft 2025, a local conference focusing on the software craftsmanship mindset and practices. For this edition, we had the pleasure to invite Jérémie Chassaing for an event-sourcing workshop. I had the opportunity to discuss with him and attend his workshop.
When writing software, we’re using types to represent the information we’re manipulating. Values are express through primitive types like bool, int or string. We’re building complex data representation by composing these types. This composition is done by defining our own types, usually with classes or tuples.
Even if there are several ways to store and represent the same information, these ways are not all equivalent. Some are too permissive and allows states that should be considered as illegal regarding our business rules. Others are well defined and only represent legal states, meaning we don’t have to write code to defend ourselves against malformed data.
To develop software, as developers we have to choose between several architectures. Our choice must be based on various constraints like the type of problem we’re trying to solve, but also the load or the level of reliability and resiliency targeted. We also have to consider the available skills in the team.
In this blog post, I want to iterate through several back-end architectures I’ve encountered and used during my career. For each of them, I’ll be highlighting their limitations and then introducing an improvement. To do so, I’ll start from the (in)famous “CRUD app”, the assumed simplest architecture, the one that will not give you one of your worst headache (until it does), and I’ll finish with some advanced solutions.
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”.