I’m a developer and I like Scrum. Not every developer does. A complaint I sometimes hear is the following:

If you have - or are confronted with - such a complaint, I have some tips for you to take into consideration

Groovy 3 adds support for Java’s lambda syntax expressions. This way we can write code in Groovy using lambda expressions just like in Java. But Groovy adds an additional feature and that is default parameter values for lambda expressions.

In the following example we use a default parameter value for a lambda expression.

Groovy contains lots of little gems that just make live easier and our code more expressive. Groovy 3 doesn’t disappoint by adding some nice syntax additions. For example we can now use !in to check if an item is not in a collection, opposed to in that checks if an item is in a collection.

In the following example we use !in:

In Java we can use Collections.shuffle method to randomly reorder items in a list. Groovy 3.0.0 adds the shuffle and shuffled methods to a List or array directly. The implementation delegates to Collections.shuffle. The shuffle method will reorder the original list, so there is a side effect using this method. Or we can use the shuffled method that will return a copy of the original list where the items are randomly ordered.

In the next example we use both methods to randomly order lists:

In Groovy we have useful classes to parse JSON and XML: JsonSlurper and XmlSlurper. Groovy 3 adds the YamlSlurper class to read in YAML formatted strings. The result of parsing the YAML content is a Map object.

In the next example we have a sample YAML as string that we parse using the parseText method of YamlSlurper:

Groovy 3 adds the YamlBuilder class to create YAML output using a Groovy syntax. The YamlBuilder is closely related to JsonBuilder that is described in a previous post. We define a hierarchy using a builder syntax where we can use primitive types, strings, collections and objects. Once we have build our structure we can use the toString() method to get a string representation in YAML format.

In the following example we use YamlBuilder to create YAML:

Groovy 3 adds the average method to collections to calculate the average of the items in the collections. When the items are numbers simply the average is calculated. But we can also use a closure as argument to transform an item into a number value and then the average on that number value is calculated.

In the following example code we use the average method on a list of numbers and strings. And we use a closure to first transform an element before calculating the average:

Spring Boot Admin describes several ways of connecting clients to the admin server. If your Spring Boot applications are running on kubernetes or openshift then Spring Boot Admin can use the Spring Cloud Kubernetes discovery client. In this blogpost i’ll show you how.

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: