In DataWeave we can use expressions in strings that will be evaluated and inserted into the string value. This is called string interpolation. The expression must be enclosed in parentheses where the first parenthesis is prefixed with a dollar sign: $(<expression>). The expression must return a string value or can be automatically coerced into a string value in order for it to work. The expression can also be a variable.

In DataWeave we can calculate the average for an array of numbers with the avg function. If we want to calculate the average for other types in an array or object if we first transform the source object to an array of numbers.

To get a v4 UUID in DataWeave we must use the function uuid from the dw::Core module. The function simply returns a value that is created using random numbers. So each time we invoke the function we will get a different value.

DataWeave has a standard function to join array elements into a string value: joinBy in the dw::Core module. The joinBy function takes an array as first argument and a string value that is used as separator. The array should have string values or values that can be coerced into string values.

In Akka Typed we need an ActorContext to create new actors.

This poses some problems if we want to create an actor inside a class that’s not an actor. We can pass around an ActorContext from a (higher level) actor. But if this is a longer-lived class, we have to keep in mind that this ActorContext is only valid during construction. So it’s generally frowned upon to pass around the ActorContext.

Azure DevOps seems to be getting quite popular. All .NET projects I have worked on last couple of years use it, which is quite understandable since it is made and maintained by Microsoft. But also in the world of Java/Kotlin, Azure DevOps is becoming an excellent choice. Maybe Microsoft loves Java after all! A DevOps service isn’t a DevOps service without some solid CI/CD tooling. Azure DevOps’s CI/CD tooling is called Azure Pipelines. So how do you set up an Azure Pipeline for your Kotlin project? Fortunately, its quite simple.

Making illegal states unrepresentable is a good engineering practice. To do this we want to add checks before object creation to make sure it is created in a correct state. Throwing exceptions in the constructor would work for this but it would mean introducing runtime exceptions in your software. If you want to safely create objects without runtime exceptions then smart constructors might be a good solution for you.

Immutability is a good practice with a lot of advantages. One of the disadvantages however is that it is hard to make changes in deeply nested immutable data structures. To circumvent this, Optics were invented and the Arrow library brings these to Kotlin.

We’re going to explore how we can use a default value for a value class in Sangria.

This builds on the previous blog post about Sangria.

To demonstrate OpenRewrite, this blogpost will walk through upgrading a Spring Boot 1.5 application to 2.5+. Along the way we will pick up JUnit 5, and migrate from Java 8 to 17, with minimal manual intervention.

We’ll start with the Spring PetClinic Sample Application, back as it was almost five years ago in 2017!