A Java geek

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!

Kotlin added the idea of Context Receivers in version 1.6.20. In this post, I’d like to toy with them to understand how useful they can be. If you want to play along, you’ll need to compile with the -Xcontext-receivers flag. The main idea behind context receivers is to pass additional parameters to a function without having to do it explicitly. A simplified model sample Let’s start with a simple example to show how it works.

Regular readers of this blog know that I’m using Jekyll to generate the static site. I’m using GitLab: when I push on the master branch, it triggers the generation job. However, Jekyll is Ruby-based and requires a couple of Gem dependencies. I’ve also added a few plugins. For this reason, I’ve created a Docker image with all required dependencies. Regularly, I update the versions in the Gemfile.lock via Bundler. Afterward, I need to rebuild the Docker image.

Recently, I designed a simple metrics-tracking system. A Python script queries different providers' APIs for metrics, e.g., Twitter, GitHub, etc. The idea is to run this script each day, store them in Google BigQuery and provide an excellent data visualization in Google Data Studio. I’m a big fan of automation, so I’m using GitHub Actions. Accessing Google Cloud with a Service Account I query the different APIs with different Python libraries.

If you attend conferences or read technical articles, you could think that microservices are the correct and only way to build a system at the moment. Despite some pushback from cooler heads, the default architecture is microservices. In this post, I’d like to argue why it’s wrong. I’ll first get back to the origin of microservices and the fundamental reason to use them. Then, I’ll describe why microservices don’t fit most organizations' structures.