Nicolas Fränkel

In the latest years, there has been some push-back against frameworks, and more specifically annotations: some call it magic, and claim it’s hard to understand the flow of the application. It’s IMHO part of a developer’s job to know about some main frameworks. But it’s hard to argue in favor of annotations when there are more annotations than actual code.

It seems pretty popular right now to bash widespread software design practices, e.g. dependency injection, frameworks, annotations, etc. While there are some downsides of adopting those practices, I believe there are more benefits. In that post, I’d like to address those points, and come up with arguments in favor.

I’m not a regular StackOverflow user, neither as a contributor, nor to ask questions. However, I recently stumbled upon a question, tried to help…​ and failed. I was pointed out my answer was wrong - thanks for everyone who did. I think failures are great occasions to learn something new! In this post, I’d like to detail what I learned after digging further: there are several ways to combine elements from an existing collection in Kotlin stdlib.

Distributing Java webapps via Docker is pretty widespread. However, regarding replacing desktop applications, it suffers from a not-so-great integration with the user’s desktop. On OSX, a quite popular distribution channel is Homebrew. Let’s dedicate this post to check how to distribute our desktop webapp via Homebrew.

Two weeks ago, we studied how to replace desktop Java apps with Java webapps. Now is the time to think about distributing such desktop webapps. The current trend now is to use Docker. I assume readers are at least familiar with the technology. The most straightforward way is to create a WAR and deliver it inside a Tomcat image. Another option is to create a fat JAR with Tomcat embedded as per the previous post, and run it inside a image with the JRE only. One of the deciding factors is the si

One of my first talk at an international conference was about cargo cult in the Java world. The story behind cargo cult is quite interesting: indigenous peoples were living their life on some islands in the Pacific Ocean. During World War II, both Japanese and American forces happened to come to those islands which were important to their respective military supply chain. Both sides did what every armed force in the world does to achieve their goal: they brought soldiers, constructed airplane r

Though I fancy myself a backend developer, I love the frontend. It’s always magic to visualize what you coded. Believe it or not, 15 years ago, I wrote JavaScript to dynamically add rows to an HTML table for Internet Explorer 5.5. That was called Dynamic HTML. But I was still a Java developer at heart.

I admit the title is a bit provocative. Of course, you need to push your changes. I should probably have renamed it Don’t just git push, or Don’t simply git push. But I’m sucker for clickbait titles. My point is, you should never ever type: git push This begets the question, why? Answering this question is the subjet of this post.

Last week, I wrote about how one could migrate metrics from Spring Boot 1.5 to Spring Boot 2.0. This week, it’s time to check the different metrics available in Spring Boot 2.0 and how to create them. Meter There are 4 main types of metrics available: CounterGaugeTimerDistribution summary To keep the post readable in one piece, it will be limited to Counter and Gauge All metrics inherit from the base Meter class. A Meter provides basic measurement storage capabilities. As

I’ve already written about the excellent monitoring features available in Spring Boot. In Spring Boot 2.0, there has been a major rewrite regarding how the /metrics endpoint is designed. This is the subject of this post.