The behavioural economics of bugs in robots

All contending teams, without exception, experience a moment at which all members are standing around the table, looking at the robot; this is not what’s supposed to happen. Shouldn’t be a surprise, we told them in advance there would be bugs. Unfamiliar with the codebase and the hardware, it is now their job to find the bugs and fix them. They do know what the robot should do: ‘it should follow the black line, once you press the start button’.

We have been doing these robot challenge workshops for a while now. They’re great fun, for creating a shared understanding between business and IT, or experiencing an acceptance test-driven approach to software development. The mBot robots bring a highly visible aspect to the software’s behaviour.

Read more →

This one crazy DevOps language you should learn (during Advent Of Code)

Random bits I learned about an underappreciated language by having fun during Advent Of Code.

This Friday the 2017 edition of Advent Of Code started, a daily treat of small programming puzzles for the holidays. Kudos to Eric Wastl for creating such a fun competition!

Last year I wanted to add a DevOps theme to my participation, so I choose to write solutions in the most important DevOps language. No, not Go. No, also not Python. Definitely not Java. Number one of course is… Bash: present in all Linux systems, almost all Docker containers, heck, even in Windows now. Gluing together systems for almost 30 years. [More...]

Refactoring to Microservices – Introducing Docker Swarm

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].

An Ubiquitous Domain language throughout testing

One of the biggest challenges as engineers is to write working software and also keep an extensive documentation. Most engineers hate writing documentation, and after they published documentation on a wiki it will die a lonely death. We want to strive for writing a Living Documentation in an Ubiquitous Language. Practices like Domain Driven Design (DDD) and Behaviour Driven Development (BDD) can help you achieve this. Especially when we start writing code, it is really important for the quality of our software to start with tests describing what your application does. We want to write software with empathy in mind, software that is understandable for peers. While software developers are beginning to use the language of the domain (business language) more in their application code, most tests still contain a lot of technical language.

Read more →

Refactoring to Microservices – Using Docker Compose

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].

Avoiding deeply nested component trees

By passing child components down instead of data you can avoid passing data down through many levels of components. It also makes your components more reusable. Even multibrand components become much easier to build. Overall it is a pattern which improves your frontend code a lot!

The Problem

When building frontends you will pass data from a parent component to a child component. Often the child component renders this data, but not the component passing it along. The child components have different data requirements than your current component.

Then you add a new component, somewhere down your component tree. It has new data requirements, so you have to pass its data through all its parent components. On top of data, it might also need callbacks to provide interactivity. You also pass these through all parent components. You change a lot of files to add new functionality. With all the data passing the readability of your code also decreases. Overall the maintainability of codebase decreases.

Code samples and more at

Property-based testing in Java with JUnit-Quickcheck - Part 1: The basics

To be able to show you what Property-based testing (PBT) is, let's start by grasping the concept of a property in programming languages. Since this is a Java tutorial, I will start with Oracle and their definition of a property in their glossary:

Characteristics of an object that users can set, such as the color of a window.

Property is neither a variable/field or a method; it is something in between which is always true in your context. An example is weight in a postal parcel: this always is greater than zero.  In Java the following example implementation would follow:

Read more →