Discover how to build your own, offline "LocalStack" for Google APIs using WireMock and TestContainers. In this post, I will show you how to set up a two-purpose mocking strategy. By writing your JSON mock responses just once, you can reuse them to power automated integration tests and spin up a standalone mock server for local (UI) development. No more production data and sharing of google keys between developers, no more 403 User Rate Limit Exceeded.

Over the past few weeks, I’ve been on a rewarding journey. As a Managing Director who is no longer a full-time software developer, finding the time to code and keep up with the relentless pace of new technologies is a real challenge. While my colleagues are experimenting with the latest frameworks and tools daily, I know I’m not alone in feeling that the tech landscape evolves faster than the hours in a day allow — or faster than what client projects typically permit you to explore.

That’s why I cherish internal projects. Earlier this year I posted about Posting our blog feed to social networks using Slack. And recently I set out to build a couple of internal tools for our Google Workspace environments, but I decided to try something different than what maybe most developers would do.

Instead of relying solely on traditional documentation or enabling an autopilot AI assistant directly inside my IDE or terminal (like a Claude Code subscription), I used the standard Google Gemini web client. It comes included with our company’s Google Workspace account — proving that you don’t need expensive premium subscriptions or complex local LLMs to get value.

Sometimes when you upgrade your application the new version does not work correctly, and you need to downgrade. When you are unlucky you did some changes in your database that cannot be undone. In that case you need to restore the database from a backup, which is usually quite cumbersome and time-consuming. How nice would it be if you could just run an undo script which is much more light weight. This blog describes how you can do that using Flyway.

AsciiDoc and UML are two well known technologies for software design. A very nice way of creating beautiful PDF documents is to combine both by embedding PlantUML in your AsciiDoc. Generating the PDF can be a bit cumbersome, but with the following Maven setup it is quick and easy.

Some people think GUIs have replaced the command-line. But they have not, they are complementary. Some things can still be done better and easier in the command-line, for example scripting, and to servers one usually has access via an SSH terminal only. But there is more! This blog will describe a few very convenient commands for software developers. All of it works in the Bash shell (common on Linux), but most of it works in the Z shell (zsh) as well (common on Mac).

The ultimate way to get rid of versioning administration is to use CI/CD (Continuous Integration/Continuous Deployment). However, in many cases CD is not possible. For example when creating libraries, or software requiring versions for compliance reasons. Versioning is then still needed. This should be easy, but it turns out that without a proper procedure it can become very messy very fast. This blog will describe a simple set up of such a procedure based on trunk-based development and Semantic Versioning.

Flyway is convenient tool to manage your database changes. You can use it to create and populate your database from scratch, or to manage changes on a pre-existing database. You can add it to your application so that when it starts up it invokes Flyway, or you can use the command-line version. This blog describes a convenient way of using the Flyway command-line version.

In production the log level should be INFO. However, in many cases it is set to DEBUG because otherwise critical message are missed. This is unfortunate, because it usually leads to a lot of log file pollution. And it should not have been needed, had the developers followed the following rules.

Hibernate is a great Object Relational Mapping (ORM) library for accessing data in a relational database. It is one of the leading implementations of Java Persistence (formerly known as JPA). Using JPQL (based on HQL, which is still a nice syntax guide) one can access and update the data in the database through your ORM objects in a simplified SQL way. However, when implemented incorrectly one can run into serious performance problems. They can all be avoided though. Here are some important things to consider to make your queries performant.

When developing software I find it very useful to stick to a number of rules. They are all commonly known, but it can be very convenient to have list of them. Sticking to these rules will enhance the quality of your code drastically.

We all know mocking libraries like Mockito or Mockk to mock classes in our unit tests. They can be convenient to mock I/O with external systems by replacing the boundary classes (aka. DAO = Data Access Objects) with mock objects. That way we do not require a full-blown simulator of that external system. However, mocking using these libraries also has some drawbacks. One way to avoid these drawbacks is to write your own mocks.

Suppose you are testing a set of Quarkus based microservices. They run as Docker images inside a Kubernetes cluster on your local machine, e.g. using MiniKube or Rancher Desktop. At some point you find a bug in one of the services, or you find that you need an extra logging in code. Now you would like to quickly modify the code and redeploy it in your Kubernetes cluster. Typically your Docker image is build using a build pipeline on a build server, which may take several minutes. Can this be done any faster and easier? With Skaffold you can!