I’m happy to share with you the first chapter of my new book, Microservices for everyone. I’m still in the process of writing it and intend to release parts of it during the next weeks. If you’re interested, sign up on the book’s landing page and receive a 25% discount when the first chapter gets released.

If you’re curious about the table of contents so far: you’ll find it in the PDF version of the introduction.

As I promised in my previous “Bash practices” post, I would discuss a query function in this article. Here you have it:

function create_temporary_directory() {
    directory=$(mktemp -d "$1/XXXXX")
}

create_temporary_directory

echo "$directory"

That’s a bad query function!

This function is supposed to return the path of a temporary directory. It accepts one argument: an existing directory we want to create the temporary directory in. It uses the mktemp utility to do the “heavy” lifting. It accepts as an argument a kind of a template for directory names (XXXXX will be replaced by 5 random characters). After creating the directory, mktemp echos the full path of the directory to stdout, meaning we can copy it into a variable by using the $(...) syntax.

Forgive me for my bad pun. As I mentioned in my previous Bash post I’m going to show you some ways in which you can improve the design of Bash scripts. Again, it’s a weird language, and a lot of what’s below probably won’t feel natural to you. Anyway, there we go.

I started out with a piece of code that looked like this:

BUILD_DIR="build"

function clean_up() {
    rm -r "$BUILD_DIR"
}

clean_up

Function arguments

Inside a function you can use all global and environment variables, which easily leads to smelly code like this: clean_up will behave differently based on what’s in the global variable BUILD_DIR. This makes the function itself quite unpredictable, but also error-prone, as the value of BUILD_DIR may at one point not contain the name of a directory, or even be an empty string. Usually we would fix this by providing the path to the directory we’d like to remove as an argument of the function call, like this:

A bit of reminiscing

When I was a kid, MS Windows was still a program called WIN.COM which you needed to start from the MS-DOS command prompt. You could also add it to AUTOEXEC.BAT which was a so-called batch file. You could write these .BAT files yourself. They were basically just command-line scripts. You could make them execute commands, print things, collect input, and make simple decisions. It wasn’t much, and I remember that you often needed some helper .COM or .EXE programs to accomplish anything useful. The most advanced thing I ever wrote was a nice little ASCII-art menu program, spread across multiple .BAT files (with GOTOs and all), which allowed me to easily start my favorite games, like Super Tetris, known to me as SUPERTET.EXE, or Prince of Persia.

For quite some time now the PHP community has becoming more and more professional. “More professional” in part means that we use more types in our PHP code. Though it took years to introduce more or less decent types in the programming language itself, it took some more time to really appreciate the fact that by adding parameter and return types to our code, we can verify its correctness in better ways than we could before. And although all the type checks still happen at runtime, it feels as if those type checks already happen at compile time, because our editor validates most of our code before actually running it.

Unbalanced test suites

Having spoken to many developers and development teams so far, I’ve recognized several patterns when it comes to software testing. For example:

1. When the developers use a framework that encourages or sometimes even forces them to marry their code to the framework code, they only write functional tests - with a real database, making (pseudo) HTTP requests, etc. using the test tools bundled with the framework (if you’re lucky, anyway). For these teams it’s often too hard to write proper unit tests. It takes too much time, or is too difficult to set up.
2. When the developers use a framework that enables or encourages them to write code that is decoupled from the framework, they have all these nice, often pretty abstract, units of code. Those units are easy to test. What often happens is that these teams end up writing only unit tests, and don’t supply any tests or “executable specifications” proving the correctness of the behavior of the application at large.
3. Almost nobody writes proper acceptance tests. That is, most tests that use a BDD framework, are still solely focusing on the technical aspects (verifying URLs, HTML elements, rows in a database, etc.), while to be truly beneficial they should be concerned about application behavior, defined in a ubiquitous language that is used by both the technical staff and the project’s stakeholders.

Please note that these are just some very rough conclusions, there’s nothing scientific about them. It would be interesting to do some actual research though. And probably someone has already done this.

In previous articles I’ve already spent a few words on some of the talks I watched at DDD Europe that made quite an impact on my thoughts about software development and design. The design part is often the most philosophical one. Design talks are often less practical. Speakers use metaphors to bring their message across and take note of other disciplines than software engineering to discover useful design principles and heuristics.

Rebecca Wirfs-Brock: Design Matters

The opening keynote of the second day was particularly philosophical. To be honest, I didn’t know Rebecca. She is co-author of several important books on object design: “Designing Object-Oriented Software” and “Object Design: Roles, Responsibilities, and Collaborations”. It should be interesting to take a look at these some time.

In a previous post I discussed some of the talks I attended at the DDD Europe conference in Amsterdam. This conference has offered a lot more amazing content and I’d like to continue to tell you about it.

Lately I’ve been thinking about why Domain-Driven Design (DDD) has such a great attractive force on me. In particular when at the same time I’m strongly attracted by technology like Docker and its surrounding ecosystem of tools that are finally helping us to fulfill the ideal of continuous delivery, with relative ease. Configuring servers, deploying them, connecting them, etc. is what we previously would have called “operations” work. Now that developers themselves get to do more and more operations work, a movement was called to life: devops, where two previously separated responsibilities are merged into one: writing software and running it in production is part of the same, single task: shipping working software.

I’m currently attending the DDD Europe conference in Amsterdam and thought it might be interesting for people at home to read up on some of the topics that this interesting (and well-organized) conference covers.

Mel Conway: Consider the development feedback loop

On Twitter there were outbursts of “The legend on stage” and “This is the Conway of ‘Conway’s Law’” when Mel Conway entered the stage. I knew about the law, which amounts to the observation that software systems tend to be shaped by the way the teams working on it communicate.

As was the case with the SymfonyConsoleForm library, I realized I had not taken the time to properly introduce another library I created some time ago: ConvenientImmutability. This one is a lot simpler, but from a technical standpoint I think it might be interesting to at least talk a bit about the considerations that went into it.

For starters, it’s important to keep in mind that I don’t think you’ll actually need to use this library. Of course, I’ll explain why. But first: what is ConvenientImmutability about?