The version catalog in Gradle is very useful to define a list of dependencies in one single place. In our build script we references dependencies from the version catalog using type safe accessors when we define a dependency for a configuration. Sometimes multiple dependencies belong to each other and are used in combination with each other. In the version catalog we can define bundles of such dependency groups. Instead of referencing each dependency individually we can reference a bundle from the version catalog in our build script. This keeps our build script cleaner and updating a bundle only needs a change in the version catalog.

A version catalog in Gradle is a central place in our project where we can define dependency references with their version or version rules. A dependency reference is defined using an identifier with a corresponding dependency definition containing the coordinates of the dependency. Now we can reference the dependency using the identifier in for example a dependency configuration, e.g. implementation(libs.spring.core). If there is a version change we want to apply we only have to make the change in our version catalog. An added bonus is that Gradle generates type safe accessors for the identifier we use in our version catalog, so we can get code completion in our IntelliJ IDEA when we want to reference a dependency from the version catalog.

Besides dependencies we need to build and test our software we can also include definitions for Gradle plugins including their version.

In a previous post we learned how to read text file contents with the slurp function. To write text file content we use the spit function. We content is defined in the second argument of the function. The first argument allows several types that will turn into a Writer object used for writing the content to. For example a string argument is used as URI and if that is not valid as a file name of the file to read. A File instance can be used directly as argument as well. But also Writer, BufferedWriter, OutputStream, URI, URL and Socket. As an option we can specify the encoding used to write the file content using the :encoding keyword. The default encoding is UTF-8 if we don’t specify the encoding option. With the option :append we can define if content needs to be appended to an existing file or the content should overwrite existing content in the file.

About a month ago I was co-host of the online conference Inclusive Design 24. This free 24 hour online conference focuses on inclusive design and shares knowledge and ideas from analogue to digital.

As a software engineer with a focus on architecture, my view on software inclusivity was very much focused on usability by people with different disabilities. These are very important considerations of course, but this is by no means the entire spectrum of inclusivity.

In this blog I will share my insights and thoughts on how we can take small steps in our day to day work that can make a huge impact on the inclusivity of our software.

GitLab Container Registry is a convenient choice to store Docker images when using GitLab CI. When every pipeline produces a new Docker image tag, you might want to clean up these image tags periodically. By default GitLab only offers a simplified Cleanup policy, which relies on regular expressions to clean up old image tags. But this approach does not take into account which image tags were recently deployed to your environments.

In this blogpost we outline an alternative image tag cleanup mechanism. We query the GitLab API to see which image tags were recently deployed to our environments, and retain these image tags in case we want to rollback.

Context with receivers is a new experimental Kotlin feature. So let’s explore this feature a bit and see what it is all about.

Don’t you just hate it when you’re getting that weird git error that prevents you from pulling to your local branch. For example:

Well, you could delete your local folder and do a re-checkout. There are however other ways git can help you, even without falling back to the git reset --hard origin/master method.

Writing JPQL queries can be annoying, because you cannot test them in a database tool or in your IDE. But with IntelliJ Ultimate, you can!

With Springdoc you can create a Swagger UI and generate the OpenAPI spec file. In a project it is a good practice to support version n - 1 of the API for backwards compatibility. The problem is that some objects have the same name and then the last parsed object is used for all versions in the OpenAPI spec. In this post the solution with definitions is shown.

Do you like stories? Tales that move you out of the ordinary into the extraordinary. Do you take satisfaction in programming? Where every bit, every keystroke means exactly one very thing. Do you esteem transparent functionality above all else? Then read on, to get introduced to a land of farmers, magick and wizards. But its wizards are programmers and its sorcery is called F#…​