Nicolas Fränkel

Today, I’d like to provide some help on how to choose a cache solution. I will organize it into two parts: In this post, we will list what features a cache must have and which ones it can optionally provide. Most criteria are general and can be used regardless of the tech stack, while a couple is specific to the JVM.In the second part, I’ll list providers and verify their respective capabilities Why cache? First, let’s bust a common myth.

Some time ago, I read a post describing how to run a serverless Kotlin function on OpenFaaS. While the content is technically correct, I believe the concept itself is very wrong. Such posts can lead people to make ill-advised decisions: 'because we can' is hardly a winning strategy. in this post, I’d like to first explain why the JVM platform is a bad idea for FaaS. Then, I’ll proceed to propose alternatives to use Kotlin nonetheless.

Last week, I described different techniques to fasten your Maven builds. Today, I’d like to widen the scope and do the same for Maven builds inside Docker. Between each run, we change the source code by adding a single blank line; between each section, we remove all built images, including the intermediate ones that are the results of the multi-stage build. The idea is to avoid reusing a previously built image. Baseline To compute a helpful baseline, we need a sample project.

Builds require a few properties, chief among them reproducibility. I would consider speed to be low on the order of priorities. However, it’s also one of the most limiting factors to your release cycle: if your build takes T, you cannot release faster than each T. Hence, you’ll probably want to speed up your builds after you’ve reached a certain maturity level to enable more frequent releases.

Two weeks ago, I wrote how you could write a Spring application with no annotations. Many alternatives are available to configure your Spring app. I’d like to list them in this post, leaving Spring Boot out of the picture on purpose. Core concepts Property file XML Groovy DSL Self-annotated classes Configuration classes Kotlin DSL Bean definitions Beans Conclusion Core concepts A couple of concepts are central in Spring.

In my latest blog post, I advised reassessing one’s opinion now and then as the IT world changes fast. What was true a couple of years ago could be dead wrong nowadays, and you probably don’t want to base your decisions on outdated data. This week, I’d like to follow my advice. One of my first posts was advocating for TestNG vs. JUnit.

Some, if not most, of our judgments regarding technology stacks come either from third-party opinions or previous experiences. Yet, we seem to be adamant about them. For a long time (and sometimes even now), I’ve seen posts that detailed how Spring is bad because it uses XML for its configuration. Unfortunately, they blissfully ignore the fact that annotation-based configuration has been available for ages.

There’s still an ongoing debate whether development in particular and IT, in general, are engineering practices. In all cases, there’s no denying that our industry is based on scientific foundations. Most of the organizations I’ve worked for implement the Deming wheel in one form or another: From a bird’s eye view, it makes a lot of sense. And given the success of the method in the Japanese car industry, there’s no denying that it’s effective.

On March 14th, 2020, I landed home. I had planned the week before to be productive: one talk in Pasadena, two talks in San Francisco, one in Bucharest, and one in Istanbul. Then, on the 16th, I was supposed to fly again to other events. Then, Covid happened. Governments started to close borders; in turn, organizers began to cancel events. I managed to do the talk in Pasadena with about ten people in the room. The organizer of one of the San Francisco talks managed to move my talk online.