For Ousterhout the opposite of tactical programming is Strategic Programming which requires more long-term thinking and a different mindset. A strategic developer doesn't sacrifice well-designed code for quicker delivery time. Ousterhout encourages us to come up with different solutions for a specific task and continue with the best design. Of course this approach costs more time but Ousterhout argues that it pays of in the long run and I think most of us would agree.
Working in a well-designed codebase with fewer complexities enables us to not only develop new features faster but will also lead to fewer bugs in our software systems.

Personally, I think it is very important to think about those two approaches when we are developing software. I believe that none of us adds complexity to a system on purpose but due to deadlines and external pressure we might tell ourselves that the little shortcuts we take are not too bad. Unfortunately, only time will reveal the amount of complexity caused by our shortcuts.
Let’s fight off complexity and avoid taking too many shortcuts for faster delivery times.
I'm convinced that I will pay off in the long run!

My favorite quote from the keynote was: Make Monoliths Modern Again by Cora Iberkleid. We should definitely work hard to avoid building big balls of (distributed) mud 🙂

In This Ain’t Your Parents’ Java Venkat Subramiam discussed how Java is evolving continuously and coming up with neat language features allowing us and future generations of developer to write better and more maintainable code.
Favorite quotes:

• They call this casting, I call it punishment

• Don’t work for the compiler, let the compiler work for you

Daniel Garnier-Moiroux did a great job in explaining core concepts of Spring Security like filters and the Authentication interface.
Key takeaways:

• You can become a Spring Security ninja by enabling TRACE logging for org.springframework.security and digging through the logs

• Writing some extra code for proper emoji support is always worth it 🙂

After the lunch break Philip Riecks kicked of this Spring Boot testing workshop.
He gave an excellent overview about the out-of-the box features provided by the Spring Boot Starter Test and presented useful testing libraries like WireMock and Testcontainers.

Key takeaways:

• Pay attention to the number of Spring contexts created during the execution of your test suite. Keep the number low to ensure fast feedback cycles.

• With some creativity you can even use Java testing libraries for excelling at your favorite browser game 😉

Аlina Yurenko talked about the past, the present and the future of GraalVM in her session and demonstrated the power of going native with the help of benchmarking demos.

Key takeaway:

• Always use GraalVM ! 😉 (Since it provides a high-performance JIT compiler as well)

• Adopt a pet!

In the final session of the day, Joris Kuipers emphasized that production-grade applications require more than just architecture and business logic to succeed.
He provided useful and applicable tips for logging, caching and error handling.

Key takeaways:

• Start building your own Autoconfigurations to share functionality between projects/modules

• Save time and money by using proper caching

I thoroughly enjoyed today’s sessions, and I'm already looking forward to day 2 of Spring IO 2024.

A big shout-out to all the speakers and the exceptional organization team for making this conference both possible and fantastic.

This issue is solved by Container Engines!
They provide convenient APIs for interacting with Container Runtimes without having to know all the low-level details.
Furthermore, this abstraction allows using different Container Runtimes if necessary.

If you started a container on your local machine once, you already interacted with a Container Engine since Docker is one of the most popular engines out there.

The docker Command Line Interface (CLI) allows us to interact with the heart of the Container engine.
In Docker terms called the Docker Daemon.
This CLI provides a high level of abstraction for the end-user since it focuses on the most important parts of a container's life cycle.
The CLI allows us to:

• start a new container
• stop a container
• restart a stopped container
• fetch a new image
• ... and much more

Based on that brief overview of functionality we can extract the main responsibilities of a Container Engine:

• Management of the container life cycle (forwarding proper commands to the underlying runtime)
• Pulling and pushing container images to image repositories
• Configuring storage for containers

Since we are now more familiar with the functionalities provided by a Container Engine, let’s have a closer look at two very popular engines:

Docker

The Docker Engine consists of the following parts:

• dockerd a long-running daemon process which acts as server. Also called Docker daemon
• the docker CLI which acts as a client and communicates with dockerd via the Docker Engine API

The Docker daemon comes with it's one CLI called dockerd.
It can be configured either by passing flags to dockerd or a JSON configuration file.

Once a request from the Docker Engine API is received, the Docker daemon takes care of processing the request and reporting the status back to the docker CLI.
Under the hood containerd is used for interacting with the underlying Container runtime (in this case runc).
So the Docker daemon does not interact with the Container runtime directly but makes use of another abstraction layer on top of runc, called containerd.
If you haven't heard about Container Runtimes, check out the first article of this series: Container Runtimes.

If you want to tinker with the Docker Engine API you can use the API directly via HTTP or integrate a provided SDK into your code.
See API docs for more information.

The client-server architecture of Docker allows the docker CLI to easily interact with remote Docker daemons as well. The Docker daemon process can listen to requests from the Docker Engine API via three different socket types:

• unix
• fd
• tcp

TCP sockets enable the possibility for remote connections. The other two socket types are bound to the host and cannot be access from a remote machine.

Docker is a prominent example of a Container Engine. It gained a lot of popularity since the initial release in 2013.
However, with the rise of Kubernetes another popular engine was born.
Let's have a look at CRIO-O.

CRI-O

The CRI-O container engine provides a stable, more secure, and performant platform for running Open Container Initiative (OCI) compatible runtimes.
CRI-O’s purpose is to be the container engine that implements the Kubernetes Container Runtime Interface (CRI) for OpenShift Container Platform and Kubernetes, replacing the Docker service.
Source

The CRI-O container engine can launch a container by using an OCI-compliant Container Runtime like runc.

It uses containers/image library to pull images from a registry. Therefore, it supports Docker schema2/version 1 and schema2/version2.

Although it is not really necessary to interact with CRI-O directly, CRI-O comes with a bunch of CLIs and tools:

• crictl: allows debugging issue with the underlying runtime without having to set up other Kubernetes components
• runc: CLI for interacting directly with the runtime
• podman: offers the same command-line features as the docker CLI and additional features on top of it
• buildah: allows building of OCI images with and without a Dockerfile
• skopeo: helps with the management of container images

For more information regarding the bundled tools see: CRI tools.

Why was CRI-O created?
CRI-O was started by Red Hat, with the goal of decoupling Kubernetes from Docker.
It is now a project of the Cloud Native Computing Foundation.
With it, it is possible to use any OCI compliant Container Runtime in Kubernetes.
Since both containerd and CRI-O implement the Kubernetes Container Runtime Interface both can be used easily in Kubernetes.

Wrap up

Let's summarize what was covered in this article:

First, we had a look at the responsibilities of a Container Engine.
Then we had a closer look at how the Docker Container Engine works under the hood.
Last but not least, CRI-O was introduced as an alternative to Docker.

Container Runtime

A Container Runtime provides an execution environment for processes in an isolated manner (a container).
The most common Container Runtimes follow the Open Container Initiative (OCI) Runtime Specification.

• What is the purpose of this specification?
• What does it include?

Open Container Initiative Runtime Specification aims to specify the configuration, execution environment, and lifecycle of a container.
Source

A detailed specification exists for different platforms (Linux, Windows etc.).
The Linux specification for example includes:

• available Namespaces
• available File systems
• available Devices

Let’s have a look at three prominent Container Runtimes:

• runc
• crun
• gVisor (runsc)

runc

Is a low level CLI capable of spawning and managing containers compliant with the OCI Runtime Specification.
It is written in Go and a project of the OCI.

Since it takes care of low level interactions it is not recommended to use runc directly.

…unless there is some specific use case that prevents the use of tools like Docker or Podman, it is not recommended to use runc directly.
Source

So if you want to build the next Docker, feel free to use it directly :)

runc is currently used by Docker as a default Container Runtime and can be used with Podman & Kubernetes as well.

crun

crun basically solves the same problem as runc: creation and management of the actual container instances.
Of course it also fully implements the OCI Runtime Specification.
crun is written in C and promises a lower memory footprint and better performance. crun is used by default by Podman and can be used with Docker & Kubernetes as well.

gVisor (runsc)

gVisor is all about security. It includes a container runtime matching the OCI Runtime specification called runsc.
For improved security, containers created by gVisor are sandboxed which leads to better isolation between your containers and the host system.
Only a limited surface of the host kernel is available for the container and calls to it are intercepted and monitored for suspicious activities.
gVisor is written in Go and maintained by Google.
runsc can be used with Docker & Kubernetes.

Summary

In this article we had a look at the most basic building block of any modern Containerization tool. We briefly touched the Container Runtime Specification from the Open Container Initiative and compared three different implementations of the specification.

In the next article we will explore Container Engines!

Find usage of tables

One of my most used shortcuts is “Find usage” but it took me quite some time to figure out that this also works with database objects like tables:

This makes refactoring your database easier since you can analyze the dependencies between your database objects and your source code quite effortless with the help of “Find usage”

Multiple consoles

In IntelliJ, it is possible to have multiple database consoles for a single data source.
All open consoles can be found under Scratches and Consoles in the side navigation:

Furthermore, those console can be renamed like all the other files in your project!
For me this is especially helpful when I have to switch between different issues or tasks. With the help of multiple consoles I can keep all the queries needed for analyzing an issue together in one console and even give the console a telling name, so I can find those queries faster later on.

Safety features

Preview delete

Like in the “normal” source code editor ALT + ENTER is your best friend in the database console as well. With it, you can safely preview a delete query!

Gives a preview of the affected row:

In my opinion this makes removing data from your production database far more comfortable 🙂

Warnings

Tired of dropping all your data due to a missing where condition in your delete statement? IntelliJ issues a warning for unsafe statement and requires extra confirmation before executing such statements.

Quite helpful in my opinion! This also works for update statements:

Auto-expand column names

Last but not least, auto expansion!
Let’s say you want to select nearly all of your columns but do not want to type all column names manually.
In my opinion the easiest way to achieve this is by using the expand column list feature. Simply write: SELECT * FROM <your_table> highlight the asterisk character and press ALT + ENTER. This will give you all the column names, afterwards you can delete any unwanted column!

Wrap up

That's all from my side for now.
What do you think about the mentioned features?
Did I miss a feature you love?
Let me know in the comments!

flutter build linux

Unfortunately this gave me the following error message:

CMake Error at /usr/share/cmake/Modules/FindPkgConfig.cmake:605 (message):
A required package was not found
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindPkgConfig.cmake:827 (_pkg_check_modules_internal)
flutter/CMakeLists.txt:25 (pkg_check_modules)

I doubled checked the official documentation and verified that the following packages were installed:

• clang
• cmake
• ninja-build
• pkg-config
• gtk3

Afterwards I reran the build command but with the verbose flag enabled:

flutter build linux -v

Which resulted in:

[        ] -- Checking for module 'gtk+-3.0'
[   +1 ms] --   No package 'gtk+-3.0' found

Flutter was not able to locate my gtk installation.
You can check if pkg-config can locate the package by running:

pkg-config --libs gtk+-3.0

This command returned the following error on my system:

Package gtk+-3.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gtk+-3.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gtk+-3.0' found

I fixed this by figuring out where gtk3 is installed and adding the directory to the PKG_CONFIG_PATH variable.
Check where the package is located:

pacman -Ql gtk3

gtk3 /usr/lib/pkgconfig/gtk+-3.0.pc

Let's add this directory to PKG_CONFIG_PATH environment variable:

export PKG_CONFIG_PATH=/usr/lib/pkgconfig

You might want to add this to your .bashrc or .zshrc config file.
Don't forget to reload your environment, e.g. with the source ~/.zshrc!

After modifying the PKG_CONFIG_PATH the Flutter build returned:

Package 'shared-mime-info', required by 'gdk-pixbuf-2.0', not found
Configuring incomplete, errors occurred!

Okay, another familiar error, let's check if shared-mime-info is available:

pkg-config --libs shared-mime-info

If the package was not found on your system, you can install it via yay or pacman
E.g.: yay -Sy shared-mime-info
Afterwards check the installation path: yay -Ql shared-mime-info
Search for the directory including the shared-mime-info.pc file, in my case it was: /usr/share/pkgconfig/

Therefore, I added this directory to the PKG_CONFIG_PATH as well:
export PKG_CONFIG_PATH=/usr/lib/pkgconfig/:/usr/share/pkgconfig/

Afterwards I was able to build and run the Flutter application on Manjaro!

Wakapi

Wakapi is a Wakatime compatible open-source backend for collecting and visualizing coding statistics. It can be self-hosted fairly easily be running the provided Docker image.
The compatibility with Wakatime is a big bonus since Wakatime provides many plugins for data collection from your favorite IDE or text editor. I'm pretty sure you can find an integration for your most loved tool here.
Let's see how one can run Wakapi with Docker.

Running with Docker

First we will create a Docker volume to make sure our data is not lost when the container is stopped/removed:
docker volume create wakapi-data

To make sure user passwords are hashed properly we generate a salt:
SALT="$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w ${1:-32} | head -n 1)"

Then we run the Docker image:
docker run -d \ -p 3000:3000 \ -e "WAKAPI_PASSWORD_SALT=$SALT" \ -v wakapi-data:/data \ --name wakapi \ ghcr.io/muety/wakapi:latest
Source

Create account

After the Docker container is up and running, we need to create an admin account.
Navigate to your Wakapi frontend e.g. if run locally http://localhost:3000/login and sign up there.
The first registered account will become the admin account for this Wakapi instance. After you are logged in you can obtain your personal API key in the top right corner: (Don't worry the API key in the screenshot is from a local instance ;))
If you do not want any other users to create an account on your instance, you can set WAKAPI_ALLOW_SIGNUP environment variable to false.

Configure the plugin

After the account creation is done, you need to install the Wakatime plugin for your desired IDE. Once the installation is done you need to configure it to use your own Wakapi instance by creating a config file under ~/.wakatime.cfg with the following content:

[settings]

# Your Wakapi server URL
api_url = http://localhost:3000/api/heartbeat

# Wakapi API key, obtained from the web interface in the previous step
api_key = 406fe41f-6d69-4183-a4cc-121e0c524c2b

Analyze your activity

After the Wakatime plugin is configured properly, it should send data from your IDE/editor to your Wakapi backend where your statistics are waiting for you to be analyzed.

Wakapi provides filters for different time-windows and statistics for editor usage, time spent on projects, time spent coding in a certain language.

Wrap up

I think it is quite useful to visualize your coding activity. It provides insights into how you spend your days and might help optimizing your daily schedule.

Shout-out to Ferdinand Mütsch for creating this amazing open-source tool and thanks to Wakatime for open-sourcing their plugins.