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.

Whether you like it or not, GitHub has become the primary provider to host one’s code. You or your company is probably using GitHub. I want to highlight some files to beautify your GitHub repository in this post. README I hope that by now, everybody is familiar with READMES. If one places a README file at the root of one’s repo, GitHub will display its content on the repo’s homepage. However, here are a couple of tips you may not know.

I’m pretty much a learning-by-doing kind of guy. However, I tend to get back to documentation after a certain level. Last year, I started to learn the Rust programming language on my own. Then, I felt the need to read some theories. I have known the 'In Action' Manning series for a long time. When I saw Rust in Action, I thought it would be a step in this direction. Facts 12 chapters, $33.59The book’s subtitle is 'Systems programming concepts and techniques'.

Java has long been infamous for its NullPointerException. The reason for the NPE is calling a method or accessing an attribute of an object that has not been initialized. var value = foo.getBar().getBaz().toLowerCase(); Running this snippet may result in something like the following: Exception in thread 'main' java.lang.NullPointerException at ch.frankel.blog.NpeSample.main(NpeSample.

During the pioneer area of the World Wide Web, the content was static. To serve it, a group of developers created a web server, which is now known as the Apache Web Server. The Apache Web Server is built around a module architecture. Developers created a module to run CGI scripts to add dynamic content to the lot. Users wrote early CGI scripts in Perl.

I’ve tried Go in the past, and the least I could say is that I was not enthusiastic about it. Chief among my griefs was how the language handled errors, or more precisely, what mechanism it provided developers with to manage them. In this post, I’d like to describe how a couple of popular languages cope with errors. A time before our time I could probably go back a long time, but I needed to choose a baseline at some point. In this post, the baseline is C.