A Java geek

If you’ve more than a couple of years of experience in IT, you probably have stumbled upon the following quote: There are only two hard things in computer science: cache invalidation and naming things. — Phil Karlton Then, because it’s such a great quote, it evolved: There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.

As part of my new job on Apache APISIX, I write less Java and Kotlin code. And when I do, the code is really simple. My coding hours (unfortunately not days) involve: A lot of containerization, including Dockerfile, docker-compose.

Java has been my bread and butter for almost two decades. Several years ago, I started to learn Kotlin; I never regretted it. Though Kotlin compiles to JVM bytecode, I sometimes have to write Java again. Every time I do, I cannot stop pondering why my code doesn’t look as nice as in Kotlin. I miss some features that would improve my code’s readability, expressiveness, and maintainability. This post is not meant to bash Java but to list some features I’d like to find in Java.

At the beginning of the year, I had two new Macs in a row in one month. I changed my company and had to return my previous laptop. Thus, I ordered a replacement one, but due to the current hardware shortage, the shipping took weeks: I had to rent one in the meanwhile. It means I had to install my Jekyll stack twice in a row. The first time took quite some time; the second one was much faster.

Writing summaries of conference talks is the best way to focus on the talk and listen actively. Before conference speaking became part of my job, I did it. However, I don’t attend that many talks now, and I don’t take notes when I do. jPrime is a conference in Bulgaria, and after two cancellations due to Covid, they had their edition this week. Probably, for this reason, the atmosphere is quite emulating: I attended a couple of talks; here are my notes.

In my previous blog post Chopping the monolith, I explained my stance on microservices and why it shouldn’t be your golden standard. However, I admitted that some parts of the codebase were less stable than others and had to change more frequently. I proposed 'chopping' these few parts to cope with this requirement while keeping the monolith intact. As Linus Torvalds once wrote: Talk is cheap, show me the code!