The end of the year has come again. For one, it’s a moment of celebration last year’s achievements, for the other it’s a relief a new year will dawn. The old will soon be replaced by something new. There is both beauty and sadness in the circle of life.

Content Security Policy response headers provide us control over the content allowed on our sites. In this post I’ll show you how to implement the report functionality of CSP violations using AWS' CloudFront configured in terraform. Furthermore I’ll share some thoughts on how to process these violations.

Finally, the well deserved break. As this pandemic forces me to work from home for too many days now, I treasure every moment I can walk in the open. So I grab a lunch out of my kitchen and step outside. Breathing in the fresh outdoor air, I try to let go of all tension. Tomorrow I’ll have to give a presentation to my fellow programmer buddies. And to be honest, I am quite stressed about this. How should I convey my message? Yeah, I made some slides. But still, will they really understand it? How can I even get them to stay focussed all the time? Especially now I have to do present remotely.

The Gradle Build Cache is particularly well suited to speed up your CI/CD build times. But to set it up properly in GitLab you need to get a few things exactly right. This blogpost will guide you through the steps, as well as provide you with some background.

Setting: We serve a GraphQl API using Sangria and Akka HTTP.

We’ll go through the steps necessary to parse value classes.

Testing classes that work with date calculations based on the current date and time (now) can be difficult. First of all we must make sure our class under test accepts a java.time.Clock instance. This allows us to provide a specific Clock instance in our tests where we can define for example a fixed value, so our tests don’t break when the actual date and time changes. But this can still not be enough for classes that will behave different based on the value returned for now. The Clock instances in Java are immutable, so it is not possible to change the date or time for a Clock instance.

In Spock 2.0 we can use the new MutableClock class in our specifications to have a Clock that can be used to go forward or backward in time on the same Clock instance. We can create a MutableClock and pass it to the class under test. We can test the class with the initial date and time of the Clock object, then change the date and time for the clock and test the class again without having to create a new instance of the class under test. This is handy in situations like a queue implementation, where a message delivery date could be used to see if messages need to be delivered or not. By changing the date and time of the clock that is passed to the queue implementation we can write specifications that can check the functionality of the queue instance.

We’ll update a config file with sed

This short story is all about the absolute joy you can experience as a Developer. I wrote it to share what it is that I miss sometimes, now that I’ve taken on a different path these last years. I wanted to write it down to share a combination of feelings that I miss that other developers might recognise as well and can cherish even more because it is written down. Hopefully this blog brings a smile to your face if you’re a developer, and can even be something that you can rely on in darker times. When those blasted builds just won’t go green, tests won’t pass, or production is not the happy place that it should be.

After completing the Kotlin for Java Developers Course on Coursera I was looking for an excuse to put my freshly gained Kotlin knowledge into action. I decided to address my frustration about the large amount of falsely detected movements by one of my security camera’s.

One of the core components of that solution is a REST API that receives an image and returns a list of detected objects. I decided to develop that using Kotlin, KotlinDL and KTor.

This blog posts describes the core components of the solution. The source code of the example is available at GitHub.

This post will show how to create a list with how many products there are in a category and their sub categories with Elasticsearch aggregations covered with tests.

On our site there are products with a category and they have a sub category, for example product category is shoes and sneakers is a sub category.

Many JSON REST APIs today offer a Swagger page as documentation as a way to explore the API (see also this recent post by Jorrit). This Swagger page (aka Swagger UI) is often used by testers to interact with the API to manually construct and verify the API calls that are then implemented as an automated test.

What you may not realize, is that the Swagger UI is generated from an openapi.json or openapi.yaml file hosted by the API server. To ensure "Swagger compatibility", this must follow the OpenAPI Specification.

But if a webpage that can interact with the API is generated from this document, shouldn’t it be possible to generate test cases for this API from it also?

Let’s find out!

For one of our clients we use the Quarkus framework. Quarkus is a full-stack, Kubernetes-native Java framework, designed to work with popular Java standards, frameworks and libraries. It is possible to get into details about Quarkus, but that’s not what this post is about! This blog will tell you how to set up a simple database driven application with a full end-to-end test, using Quarkus and testcontainers.