Since Mapstruct version 1.3.0.Final is out, we are able to better integrate with Lombok Builder pattern. Mapstruct is a library that takes away a lot of boilerplate code for mapping between POJO’s. With Mapstruct there is no need for implementing the real mapping itself.

With Lombok we can use a Builder pattern and mark an object as a Value(Object). It will result in an immutable object. This blog post shows how we can use Mapstruct to use the Builder pattern of Lombok.

A big part of the fun of starting a new project is making a design and choosing an appropriate technology stack. If you are a Java developer and need to access a SQL database, a common choice is to use JPA with an ORM framework such as Hibernate. This adds a lot of complexity to your project for multiple reasons. In my experience, writing performing queries requires careful analysis. Writing custom queries is possible but more complex. For starters, JPQL/HQL queries are parsed at runtime and the criteria API is far from user friendly. Moreover, the extensive use of annotations makes it harder to quickly see how the database is structured.

Kotlin Exposed is a lightweight SQL library on top of JDBC that could serve as a good alternative. When using Kotlin Exposed you start by describing your database structure using plain Kotlin code. The code resembles SQL DDL statements very closely and does not require any annotations or reflection! You can use these descriptions to write type safe queries. These queries can be written in two flavors: DSL and/or DAO. This post focuses on the DSL flavor.

After my last post, it would be a good time to do a bit more of a technical story. The goal will be to set up a Hello World application using the Play framework, a front-end based on Angular running on a Docker image, deployed in your local running Kubernetes!
So let’s play!

Nowadays you can’t walk into an IT department without hearing discussions about containerization. Should we move to OpenStack or OpenShift? Do we want to use Pivotal Cloud Foundry? What about Docker Swarm or Kubernetes? How to integrate our new kubernetes cluster into our CI/CD pipelines?

Keep in mind that DevOps using unmanaged infra adds an extra layer of complexity to the development teams. In the end, you might save money on an Ops team, but the tasks still need to be executed, leaving the work for the development team. As an example, when you create some new code, make a pull-request, the CI/CD pipeline kicks in to automatically build your code, perform (unit) tests, deploy to the next environment, etc. When an error occurs, the pull request would be rejected, leaving the developer to fix any possible issues, even infra.

Separating concerns is something we as developers are used to thinking about in terms of code. But the same also applies to identity management. If you’ve dabbled in AWS, you can get started right away with a root account. However, when it goes beyond dabbling, it might be a good idea to start splitting up responsibilities.

While I’m working with Terraform, I’d thought I’d share the way I set up my DNS for my Virtual Private Cloud (VPC).

ScalaDays 2019 is alweer een week voorbij, maar langzaam, maar zeker krijgt de enorme hoeveelheid hoge-kwaliteit input hun gevolgen in mijn kennis over Scala.

Naar aanleiding van een rode draad die ik vond tijdens deze ScalaDays, heb ik enige gedachten over het gebruik van Types in Scala geblogd.

Today I’ve been working exactly minus 23 days at JDriven. So as you might expect, officially I’ll be starting there at the first of July. For my new employer, this is no reason at all not to invite you on the seminars they provide for their people, so yes this proved as well there is a reason to make this next step into choosing for JDriven. So last Thursday there I headed to headquarters at Nieuwegein for a full day workshop about Microservices, given by nobody else than Sam Newman!

Sam Newman
Okay, for the ones who don’t know, he is the author of the books ’Building Microservices’, ’Lightweight Systems for Realtime Monitoring’, and the forthcoming book ’Monolith to Microservices’, all published by O’Reilly. He’s also known being the co-creator of the Lego XP Game.

In a previous post we learned about setting the value of options attribute to nowrap on listing and literal blocks, so the lines in the block are not wrapped. In the comments a user suggested another option to disable line wrapping for all listing and literal blocks in the document by using the document attribute prewrap. We must negate the document attribute, :prewrap!:, to disable all wrapping. If we place this document attribute at the top of our Asciidoctor document it is applied for the whole document. We can also place it at other places in the document to change the setting for all listing and literal blocks following the prewrap document attribute. To enable wrapping again we set :prewrap: (leaving out the exclamation mark).

In the following example we have markup with a listing, literal and example block and we use the document attribute :prewrap!: to disable the wrapping for the listing and literal blocks:

Since Gradle 5 we can easily use a bill of materials (BOM) in our build file to get recommended dependency versions. The dependency versions defined in the BOM are dependency constraints in Gradle. This means the dependencies we define in our build that are part of the BOM don’t need a version, because the version is resolved via the dependency constraint that is defined in the BOM. Also transitive dependency versions are resolved using the BOM if applicable. We use the dependency handler method platform to define the BOM we want to import. The versions in the BOM are recommendations. We can override the recommendation by specifying the version for a dependency found in the BOM with an explicit version.

From Maven builds we know the dependencyManagement section in our POM file. In the section we can describe dependencies with their version and later in the dependencies section we can refer to the dependency without the version. We can use dependency constraints in Gradle to do the same thing. A dependency constraint can be used to define the version or version range for a dependency defined in our scripts or a transitive dependency. Just like a dependency the dependency constraint is defined for a configuration, so we can fine tune the constraints to the correct configuration.

Using dependency constraints in a multi-project build allows us to define the dependency versions in the root build file and define project dependencies per project without a version. The version will then be used from the dependency constraint we defined in the root build file.

I like to create immutable classes. When using lombok we can easily create immutable classes.

This class Person with the @Value annotation will create an immutable class with an all args constructor. The @Builder will add a Builder pattern to the Person class, so I can use it like this: