Social media has been blamed for locking people in a bubble, only showing them news that is in line with their beliefs. This divides society into different groups that have almost nothing in common. People read what they think they want to read, never seeing a different opinion. At the same time governments and influencers have started to call for filtering. Facebook would have to filter out lies and fake news, so we all see the truth only. The problem with the filter approach is that it will cause opinions to drift toward some bottom line truisms we can all agree on. If we start fining social media for violations, the companies will get more and more conservative, and we’ll end up in a boring world. Like having a perpetually overcast sky and an eternal drizzle. Grey goo everywhere.

This is not what we need. What we need is to be confronted with opinions that differ from what we think is right. So we (i.e. Albert Brand, Arjan Molenaar and myself) started a one-day research project at Xebia, inspired by a feature of my favorite Dutch newspaper, NRC. The feature is called Twistgesprek. The format is that two people discuss a statement during the week. Their conversation is summarized and published in the Saturday paper as a back-and-forth of messages. Quite often I start with a strong opinion about the subject being discussed, but end up with a more thorough understanding of its nuances because of the discussion. Having your convictions challenged and modified is a wonderful gift.
So, the idea was to show people ideas that directly contradict each other.
more

Mutation testing promises to help ensure quality tests. It does this by making changes to a code base and running all tests. If all is well, some changes in code should result in failing tests. So making a bunch of changes like inverting the condition in an if-statement, should cause the tests to fail. If not, the test isn’t good enough.

I’ve tried this technique a couple of years ago, and wanted to find out what had changed.

While trying to upgrade my programming skills, I ran into a new-fangled way to do ifs.

The example below is taken from code that gets a value for a property of a class. A value may or may not be set and if it isn’t the code should use a default.

You can find the code here [on Github].

So my classic go-to solution was to use an if statement like this:

[more…]

My first [Uncle Bob] event was the 2017 [GoTo conference] in Amsterdam, where Robert Martin delivered a talk like he must have done a thousand times. And many of you will probably have seen some version of it way back when. For me it was all new, having managed to somehow avoid the experience for years. He said many things that made sense to me at the time, but what got stuck in my head was the idea of a programming Kata. The advice I distilled from his words was to take a small programming problem and try to implement a solution over and over again. The actual solution would be less important than the act of solving the problem. Allowing you to experiment in a safe and well known environment. Small techniques for problem solving would gradually become part of muscle memory, much like happens, or so I’m led to believe, in martial arts.

I liked the idea and found myself a small problem: read more…

In my [previous blog] I used local images wired together with a docker-compose.yml file. This was an improvement over stand alone containers. Networking is now more robust because code in images uses names instead of IP addresses to access services. This time my goal is to introduce Swarm so I can distribute components over multiple hosts and run more instances if necessary. Next, I’ll describe step one: migrate the docker-compose-single-host setup to a Docker Swarm multi-host version. [More].

In the previous version of the shop landscape (see tag ‘document_v2’ in this [repository]) services were started with a shell script. Each depended on Rabbit MQ to run, so there was a URL with an IP address that depended on whatever address the host it runs on got from its DHCP server. This was brittle, so I decided to introduce docker-compose. Actually, I should say ‘re-introduce’ because my colleague Pavel Goultiaev built a previous version using compose. In this version, I copied and finished his code.

read more

This blog is part of my Trying-to-understand-Microservices-Quest, you can find the previous [installment here].

In a previous installment of our Microservice refactoring effort, I’ve introduced a ShopManager and a Clerk to implement the shopping process (see this blog). I ended up with a JSON document transferred between services. To make life easy for myself I just parsed all of the document using Spring magic. This time I will discuss the downside of this strategy and show an alternative.

read more

A while ago at Xebia we tried to streamline our microservices effort. In a kick-off session, we got quite badly side tracked (as is often the case) by a meta discussion about what would be the appropriate context and process to develop microservices. After an hour of back-and-forth, we reached consensus that might be helpful to place a topic like microservices in a larger perspective. Below I’ll summarize my views on how to design robust microservices: start with the bigger picture, take time designing a solution, then code your services.

read more

A while ago I described the first part of our journey to refactor a monolith to microservices (see here). While this was a useful first step, a lot can be improved. I was inspired by Greg Young’s course at Skills Matter, see CQRS/DDD course. Because I think it’s useful to reflect on the steps you take when changing software architecture, I’ve set a couple of milestones and will report on each when I get there. The first goal is to introduce process in our domain and see what happens.
Read more →

For a training on Microservices that is currently under development at Xebia, we’ve created implementations of a web shop in both a monolithic and Microservices architecture. We then used these examples in a couple of workshops to explain a number of Microservices concepts (see here and here). In this post we will describe the process we followed to move from a monolith to services, and what we learned along the way.
Read more →