The following blog post by Karl Tryggvason shows a simple script to get data from a JSON Web Token (JWT) using jq. It is basically splitting the token on the . and then convert each part from base64 encoding. As extra functionality the timestamp fields exp and iat are converted to human readable dates.

Maven uses the Surefire plugin to run unit tests and the Failsafe plugin to run integration tests. The default behaviour of Maven is to run all tests and show a summary at the end. The summary shows how many tests have run and how many failures, errors and skipped tests happened. So every time when you run mvn test or mvn verify all tests will be executed, even when tests are failing. You can speed up your build by stop running tests once a test fails. You must use the Java system properties surefire.skipAfterFailureCount and failsafe.skipAfterFailureCount to make sure Maven will skip running any tests after a test failure has occurred. You can specify a number with the parameter to set how many tests should fail before other tests are skipped. It is possible use these parameters in the plugin configuration in your pom.xml as well.

In my previous post, The Azure Scale Controller is Wilding: Build Your Own Java Fan-Out Orchestrator, we explored how Azure’s default queue autoscaling can easily overwhelm downstream services during large fan-out operations.

While managing concurrency solves rate-limiting issues, another silent budget-killer remains: unresponsive, frozen code.

A while ago I was stuck on a problem. I had been turning it over on my own for the better part of a morning, and I was not getting anywhere.

Then I walked to the coffee machine. A colleague asked what I was working on, I explained it in two sentences, and before my cup was even full he said something that pointed me straight at the answer. No meeting, no ticket, no scheduled call. Just two people standing next to a machine that makes mediocre coffee, tea for me.

That is the kind of moment I have been missing, and I think a lot of teams are missing it too.

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.

While working on a Spring Boot 4 service using Java 25, I wanted to protect my external API calls as these can go down every now and then. For this I used Resilience4j @CircuitBreaker and @Retry annotations, and put a @Cacheable on top. Three annotations stacked on a single method, what could possibly go wrong?

It turns out that the order in which they are applied by default is probably not the one you want. This makes your circuit breaker count every retry attempt as a separate failure. And once the circuit opens it even blocks data that is sitting right there in your cache. Here is what happens by default, and how I changed it.

As a consultant I am part of a lot of different Java projects. Some of these project use Lombok. When you use a Lombok annotation code gets generated when the code is compiled. This code is not visible in the IntelliJ IDEA editor which could be a problem when you want to debug your application and need to add a breakpoint for the generated code. Suppose you have a Java class with a simple constructor without using Lombok annotations. You can place a breakpoint in the constructor and when you debug the application in IntelliJ IDEA the execution stops at the breakpoint. Now you can check for example the values of parameters that are passed into the constructor call. But when you use a Lombok annotation like @RequiredArgsConstructor the code for the constructor is generated and not visible in your editor. If you want to check the values of parameters passed into the constructor you need to set a breakpoint at the line that has the @RequiredArgsConstructor statement. When you debug your application IntelliJ IDEA will stop execution when the constructor is invoked and you can check values of parameters.

If you work with Azure Durable Functions, you likely use the Fan-Out / Fan-In pattern to process data in parallel. In practice, trusting default queue scaling in production often triggers HTTP 429 (Too Many Requests) storms, connection pool exhaustion, and downstream outages.

It’s finally mature: a framework to define nullability in Java. There have been so many attempts, but JSpecify is here to stay. Now that this has been addressed, another challenge comes to mind: How can we eliminate the boilerplate of handling incoming null arguments?

Our colleague Jacob shed a light on working with AI in a post he wrote back in June, Contemplations. One of his points was that, with AI being more and more ubiquitous in our work as software developers, sophisticated programming concepts are starting to become irrelevant. The AI doesn’t care how elegant the code is, it spits out something that works. In the end that’s what matters to the business; it just works.

I learned about Rich Sutton’s "Bitter Lesson" recently, and I can’t help but draw parallels between the work on the cutting edge he describes and our daily work using AI as software engineers.