The Clojure namespace clojure.java.io contains useful functions to work with files. One of those functions is make-parents. We can pass a java.io.File instance as arguments or use the same arguments that can be passed to the file function that is also in this namespace. The function will create all parent directories for the file. The return result is true if the directories are created (they didn’t exist before) and false when the directories didn’t have to be created (already exist).

In the following example we see an example of usage of the make-parents function:

We’ll continue the plan to rate movies with Markov chains.
This time we’ll tokenize the input.

Spring REST docs and Swagger are great ways to document your API, but both have their strong and weak points. I prefer the test-driven way of documenting an API of Spring REST docs over the "Magic and Annotations" approach of Swagger, but on the other hand the output of Spring REST docs just doesn’t look as nice as the interactive UI of Swagger. Wouldn’t it be nice if we could combine both frameworks to create the most awesome API docs ever?

Testing is an important part of writing an application. There are many decisions to make about what, how and when to test. It often helps me to think of the costs and values of (potential) tests to reason or talk about them.

This text will explain what these costs and values are and some of the guidelines I derived from this.

Kafka Connect is a great tool for streaming data between your Apache Kafka cluster and other data systems. Getting started with with Kafka Connect is fairly easy; there’s hunderds of connectors avalable to intregrate with data stores, cloud platfoms, other messaging systems and monitoring tools. Setting up a production grade installation is slightly more involved however, with documentation at times scattered across the web.

In this post we’ll set up a complete production grade Kafka Connect installation, highlighting some of the choices and configuration quirks along the way.

For illustrative purposes we will set up a JDBC source connector that publishes any new table rows onto a Kafka Topic, but you can substitute any other source or sink connector. All configuration is available on GitHub.

When we convert our PlantUML diagrams we get a default look-and-feel for our diagrams that is mostly red and yellow based. We can alter the style and color of individual elements using the skinparam command. But we can also apply so-called themes to our diagram that will alter the look-and-feel of our diagram with a simple theme reference.

We can define the name of the theme in our diagram markup using the !theme directive. Or we can use the command-line option -theme when we generate a diagram from our markup. We can even combine both methods where the end result is also a combination of both themes.

Recently I gave a talk that included a slide where I briefly discussed single return vs multiple returns. The purpose of this slide was only to give an example of a dogma and basically had nothing to do with the rest of the talk. Therefore it was kinda funny to see that this particular slide caused a lot of discussion afterwards, so it seems natural to write a blog about this topic.

So…​ should a function only have a single return statement or is it better to allow multiple returns?

Will Quantum Technology change the world of Software Engineering completely?

Let’s start by saying that I am no expert in the field of Quantum technology. I am just very interested in what the possible impact of this shift in technology will be in our field of Software Engineering.

If you would like to know more about the basics of Quantum technology, I highly recommend checking out the website of the QuTech Academy for further reading.

In this blog I am sharing my thoughts on how Quantum Technology can impact the world of Software engineering and hopefully inspire you to think about the possibilities that lie ahead.

Zero Trust; you’ve probably, at the very least, heard of the term. Some may have worked on a project where a Zero Trust policy was in effect, and others may well be working for a company with a company wide Zero Trust policy in effect. But do you know what Zero Trust actually entails? And if you know, do you know how best to develop software that has to comply to a Zero Trust policy?

Depending on your level of exposure to Zero Trust, you may well have had a bad experience with it, may not want to have anything to do with it, or may not want to develop in such an environment at all. If you had a bad experience, it is most likely due to the company or project not understanding the Zero Trust methodology and implementing it incorrectly; but that is a subject for different blog post. Regardless of your experience with (or opinion of) Zero Trust, this post will give you some helpful hints on how to best develop for a Zero Trust environment.

Spring Security provides a lot of convenience to develop secure web applications. However, it relies strongly on a SecurityContext stored in a thread-local (inside the SecurityContextHolder class). If not mitigated, this causes issues in multi-threaded contexts. When using Kotlin Coroutines, there is an additional abstraction layer where you don’t really know (and don’t want to know) on which thread(s) your code will be running. Luckily, there is a relatively easy solution!