This week at work a colleague showed a nice feature of the Pattern class in Java: we can easily turn a Pattern into a Predicate with the asPredicate and asMatchPredicate methods. The asPredicate method return a predicate for testing if the pattern can be found given string. And the asMatchPredicate return a predicate for testing if the pattern matches a given string.

In the following example code we use both methods to create predicates:

The book The Fifth Discipline by Peter M. Senge landed on my doormat recently. I ordered it after hearing Andrew Harmel-Law of ThoughtWorks mention it at the JFokus 2020 conference (article in Dutch). His takeaway was as follows:

"Placed in the same system, people tend to produce the same results".

Once I received the book however, a line at the top of the cover caught my eye:

"In the long run, the only sustainable source of competitive edge is your organization’s ability to learn faster than its competitors"

This statement rings so many bells I’d like to dwell on just that without even going into the book itself. There are two obvious yet often missed clues here that I’d like to share.

The times I’ve worked on a project where the scope is "rebuild the existing implementation, but with new tool / techonology X", I’ve encountered various pitfalls that make these projects much harder than they need to be.

Let me offer some tips on how to deal with them.

This post gives an example how to read values and secrets from an alternative store instead of storing them in config files, which is never a good idea. The example uses the AWS parameter store, but can be easily adapted to the newer AWS Secrets Manager or any other store!

The goal is to avoid configuration files like these:

If you write lots of Kotlin code you might have noticed that it is annoying to write the named parameters when calling functions or when creating a new instance of class.

I found an IntelliJ IDEA plugin named 'Kotlin Fill Class' that does this for you. https://plugins.jetbrains.com/plugin/10942-kotlin-fill-class

Last week, on Thursday 6th and Friday 7th of February, I attended DDD Europe 2020 in Amsterdam. In this post I will give a short overview of the talks and workshops I followed and some of my personal takeaways.

I had a great time on the conference. One of the things I like most is the mixture of talks and workshops. In the 2 hour workshops you are expected to actively participate in whatever is happening. Be it discussions or really doing some coding or testing.

I’d like to thank all the speakers and attendees for their input, talks, workshops and discussions during the breaks.

SQL allows you to do calculations on columns over multiple rows using aggregate functions like COUNT, SUM, AVG etc. This post explains how to use them in Kotlin Exposed. We will also cover arithmetic operations on one or more columns. If you haven’t used Kotlin Exposed before, you can go here for an introduction.

Consider an application containing two tables in an SQL database: Comment and User. A comment is written by a user, and can receive likes/dislikes. The snippet below shows the table definitions:

This is a blog post that tries to give a pragmatic explanation about what a monad is, and what problem it tries to solve. This post is written by Ties van de Ven and Justus Brugman.

When I tried to learn about functional programming, I found myself lost in new words and jargon, I did not know about. Suddenly my vocabulary needed to be extended with terms like Monads, Monoids, Composable, Functors and so on. When trying to understand these terms, it became clear that I found it hard to understand what a monad is.

This post explains how to use table aliases using Kotlin Exposed. Aliases are necessary when you want to join the same table multiple times. If you haven’t used Kotlin Exposed before, you can go here for an introduction: Kotlin Exposed - A lightweight SQL library.

In this example we have an application containing two tables: Message and User. The Message table has two references to the User table, one to model the 'fromUser' relationship and one for the 'toUser' relationship. The table definitions look as follows:

We can use the flatten method in Groovy to flatten a collection that contains other collections into a single collection with all elements. We can pass a closure as extra argument to the flatten method to transform each element that is flattened. The argument of the closure is the element from the original collection.

In the following example we first use the flatten method without a closure argument. Then we pass a closure argument and transform the element:

I’ve recently had the situation where I deployed a Spring Boot application on OpenShift where a certain dependency needed a properties file that couldn’t be found. The problem was that this dependency didn’t scan the classpath for the file, but just opened a FileInputStream relative to the current path.

In this blogpost I will guide you through the process of deploying a text file next to a jar in an OpenShift container. I’ve reproduced an example scenario, but you can skip these steps and go right to the solution if you want to.