DEV Community: Tobias Haindl

Working Code Isn’t Enough

Tobias Haindl — Tue, 11 Jun 2024 17:33:00 +0000

In A Philosophy of Software Design, John Ousterhout argues that striving only for working code is not enough. The mindset of getting a feature done as fast as possible is not ideal, he calls this approach Tactical Programming.
Tactical programming results in addition of too much unnecessary complexity since not enough time is spent on coming up with a well-designed solution for your problem. This approach seems reasonable since some developers have to perform in high-pressure environments. With the next deadline lurking around the corner aiming for working code as quickly as possible seems like a good idea. Unfortunately, achieving working code in a short period of time often involves taking shortcuts. Each little shortcut increases the complexity of our code which harms the quality of our software systems in the long run.

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!

Cover photo by GR Stockss on Unsplash

Bending Time in Spring Applications

Tobias Haindl — Mon, 08 May 2023 15:37:38 +0000

Did you ever feel the need to unleash your inner Doctor Strange and manipulate time concisely when testing your Spring application?

Let's check out the newest addition to the Spring ecosystem!

Spring Modulith

Spring Modulith supports developers implementing logical modules in Spring Boot applications. It allows them to apply structural validation, document the module arrangement, run integration tests for individual modules, observe the modules' interaction at runtime and generally implement module interaction in a loosely-coupled way.
Documentation

In this article we will focus on one specific area of Modulith, the Moments API.

Moments

The Moments API enables developers to easily react to the passage of time-based events in your application.

This allows you to easily write code which should be executed once a day, once a week etc.

Example application

I created a small sample application demonstrating features of the Moments API.

The code can be found on Github.

Let's walk through the application code together.

Setup

First we need to add the Modulith dependencies to our Spring application.
I'm using Maven to manage the dependencies in the sample application:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.experimental</groupId>
            <artifactId>spring-modulith-bom</artifactId>
            <version>0.6.0</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

and the actual dependency:

<dependency>
    <groupId>org.springframework.experimental</groupId>
    <artifactId>spring-modulith-moments</artifactId>
</dependency>

Of course, we also want to test our application code, so we will add the test dependency as well:

<dependency>
    <groupId>org.springframework.experimental</groupId>
    <artifactId>spring-modulith-starter-test</artifactId>
    <scope>test</scope>
</dependency>

Daily notifications

In the example application we want to send out notifications daily to our customers.
At the end of each day, we want to fetch all our customers and check if they opted in for receiving a notification on this day.

Let's create a simple Spring service called CustomerNotificationService.

To listen to events emitted by Moments, we annotate a public method with @EventListener and add the event we want to listen to as a method parameter:

@EventListener
public void on(final DayHasPassed dayHasPassed) {}

Now we can easily implement our business logic and let Moments take care of the rest:

@EventListener
public void on(final DayHasPassed dayHasPassed) {
  var passedDate = dayHasPassed.getDate();
  log.info("{} has passed. Checking notifications for customers.", passedDate);
  for (var customer : customerService.getCustomers()) {
    if (customer.allowedNotificationDays().contains(passedDate.getDayOfWeek())) {
      eventPublisher.publishEvent(new CustomerNotificationEvent(this, customer.id(), passedDate.getDayOfWeek()));
    }
  }
}

For simplicity and brevity reasons the CustomerService returns two hard-coded customers:

@Service
public class CustomerService {

  public Collection<Customer> getCustomers() {
    return List.of(new Customer(1, Set.of(DayOfWeek.MONDAY, DayOfWeek.FRIDAY)),
        new Customer(2, Set.of(DayOfWeek.SATURDAY, DayOfWeek.SUNDAY)));
  }
}

If the customer opted in for receiving notifications on this day, we simply emit a new CustomerNotificationEvent which could then be picked up by some other service and actual send out the notification.

Since we care about our code, we want to ensure that it is working properly. Thankfully Modulith comes with great test support.
Time for some time bending :)

Testing time

The Moments API exposes a class called TimeMachine.
With it, we can easily manipulate time in our tests.
In the following test we will enable the TimeMachine by setting spring.modulith.moments.enable-time-machine=true.

Additionally, we will annotate the test class with @ApplicationModuleTest. This is another cool feature provided by Modulith.
With it only beans defined in the given module (in our case customer) will be created upon test execution.

@ApplicationModuleTest
@Import(CustomerNotificationServiceTestConfig.class)
@TestPropertySource(properties = "spring.modulith.moments.enable-time-machine=true")
class CustomerNotificationServiceTest {

    private final TimeMachine timeMachine;

    CustomerNotificationServiceTest(final TimeMachine timeMachine) {
        this.timeMachine = timeMachine;
    }

    @Test
    void sendNotificationToCustomer(final PublishedEvents publishedEvents) {
        for (var i = 0; i < 7; i++) {
            timeMachine.shiftBy(Duration.ofDays(1));
        }

        assertThat(publishedEvents.ofType(CustomerNotificationEvent.class)
                .matching(e -> e.getCustomerId() == 1))
                .hasSize(2)
                .extracting(CustomerNotificationEvent::getDayOfWeek)
                .containsOnly(DayOfWeek.MONDAY, DayOfWeek.FRIDAY);

        assertThat(publishedEvents.ofType(CustomerNotificationEvent.class)
                .matching(e -> e.getCustomerId() == 2))
                .hasSize(2)
                .extracting(CustomerNotificationEvent::getDayOfWeek)
                .containsOnly(DayOfWeek.SATURDAY, DayOfWeek.SUNDAY)
        ;
    }
}

Bootstrapping with ApplicationModuleTest

If we run the test and check the logs we can see what @ApplicationModuleTest does under the hood:

Bootstrapping @org.springframework.modulith.test.ApplicationModuleTest for Customer in mode STANDALONE (class dev.tobhai.modulithevents.ModulithEventsApplication)…

# Customer
> Logical name: customer
> Base package: dev.tobhai.modulithevents.customer
> Direct module dependencies: none
> Spring beans:
  + ….CustomerNotificationService
  + ….CustomerService

With the help of @ApplicationModuleTest we can easily test the interaction between multiple beans defined in a module without the need for a full-blown Spring Context.

Shifting time in the test

Now to the time-bending part of the test:
First we define a fixed Clock instance in the CustomerNotificationServiceTestConfig.
Then we enable the TimeMachine by setting: spring.modulith.moments.enable-time-machine to true.

Now we can simply inject the TimeMachine instance into our test class and use it to shift time around in a very readable and concise way:
timeMachine.shiftBy(Duration.ofDays(1));

Assertions on emitted events

How can we actually verify that the CustomerNotificationEvent was emitted properly?

Modulith helps us out in this scenario as well:
By adding PublishedEvents publishedEvents to the signature of our test method, we can access all emitted events and perform assertions on them.

publishedEvents.ofType(CustomerNotificationEvent.class) .matching(e -> e.getCustomerId() == 1) helps us to access all CustomerNotificationEvents for customer with ID.
The time in our test starts on a Monday, and we shift "time" by seven days.
Therefore, we expect that two events (for Monday and Friday) are emitted for customer 1.

Wrap up

In this article we explored the Moments API of the Spring Modulith projects.
Additionally, we had a look at testing support provided Modulith.

Did you play around with Modulith yet?
If so, what is your favorite feature?

Feel free to follow for more Java related content :)

Cover photo by Aron Visuals on Unsplash

Container Deep Dive 2: Container Engines

Tobias Haindl — Thu, 01 Dec 2022 17:35:14 +0000

In the last post of this series we had a closer look at Container Runtimes.

However, for us developers interacting with Container Runtimes is tedious and not straightforward since they have not been designed to be consumed directly by the end-user.

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-Os 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.

Cover photo by Garett Mizunaka on Unsplash

Container Deep Dive 1: Container Runtime

Tobias Haindl — Thu, 01 Dec 2022 17:33:43 +0000

Containerization technologies stand upon the shoulders of giants.

Several building blocks are needed to make Docker, Kubernetes and co as powerful as they currently are.

In this series I want to explore each layer of those tools individually.

We will start at the bottom with Container Runtimes and move upwards to higher abstraction layers.

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!

Cover photo by Lucas Hoang on Unsplash

Container Deep Dive 1: Container Runtime

Tobias Haindl — Sun, 06 Nov 2022 15:23:11 +0000

Container Runtime

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

Lets 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)

Summary

In the next article we will explore Container Engines!

Why I love IntelliJ's database window

Tobias Haindl — Fri, 28 Oct 2022 16:36:24 +0000

In this article I want to share some of my favorite features of IntelliJ's database window/console.

Let's jump right in!

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 easily 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!

Lets 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!

Building Flutter Linux on Manjaro

Tobias Haindl — Sat, 06 Aug 2022 08:56:29 +0000

Last week I was eager to check out a little Flutter application built by Lucas Schuster.

I was especially interested in trying the Flutter Desktop support for Linux.

After installing Flutter via fvm, I checked out his Git repository and issued the following command for building the Flutter app on Linux:

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!

Photo by Danist Soh on Unsplash

Analyze your coding activity in a privacy-friendly way

Tobias Haindl — Thu, 23 Jun 2022 07:02:35 +0000

These days data is ubiquitous, we generate loads of data each day, consciously and unconsciously.

I'm not the biggest fan of giving away my personal data, but I still like to analyze my spent time by tracking some stats. This also applies for my coding activity.

That's why I was looking for an open source tools which helps with tracking and analyzing my coding time.

I found a great open-source, privacy-friendly tool called Wakapi which can help with those tasks.

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 Mtsch for creating this amazing open-source tool and thanks to Wakatime for open-sourcing their plugins.

Header image by Isaac Smith

What do we say to typos? Not today!

Tobias Haindl — Wed, 20 Apr 2022 17:55:14 +0000

As we all know, typing frantically can lead to typos quite easily.

Since I'm not really proud of all the typos I produce during a normal work day, I decided to do something against it a few
weeks ago.

LanguageTool to the rescue

I was already used to wiggly lines in my favorite IDE IntelliJ and really missed the spell and grammar check capabilities in other editors especially when writing something in the browser.
A colleague told me that IntelliJ is using LanguageTool.

Therefore, I looked around on GitHub for a way of hosting my own LanguageTool server.
I came across this repository and decided to give it a go and run it on my Linux server.

Running your own instance with Docker

Setup n-gram support

For better analysis results we will download the n-gram dataset provided by LanguageTool.
N-grams can be used to distinguish between words which are easily confused like there and their or bite and byte. Depending on the context LanguageTool can make assumptions about the correct word with the help of the n-gram files.

To download all English n-grams in your current directory, execute:

wget https://languagetool.org/download/ngram-data/ngrams-en-20150817.zip

To unpack the downloaded zip file into the directory ngrams:

unzip ngrams-en-20150817.zip -d ngrams

If you want to add n-grams for an additional language, make sure to adhere to the directory structure.

E.g. for English and German:

ngrams/en/1grams
ngrams/en/2grams
ngrams/en/3grams
ngrams/de/1grams
ngrams/de/2grams
ngrams/de/3grams

Pull and run the image

docker pull erikvl87/languagetool

To pull the latest version from DockerHub.

docker run --rm -e langtool_languageModel=/ngrams -v /home/<insert-your-path-here>/ngrams:/ngrams -p 8010:8010 erikvl87/languagetool

To run the LanguageTool server with n-gram analysis enabled.
Make sure to change <insert-your-path-here>/ngrams to your local ngrams directory which we previously created.

Install the Chrome plugin

To enable spell and grammar checking in Chrome install the corresponding plugin.
Head to the setting and set to URL to your LanguageTool Server:

It is important to add /v2 to the base path, otherwise the Chrome plugin won't work!

E.g. if your LanguageTool server is reachable under https://my-domain.dev the configured URL should be https:/my-domain.dev/v2.

After that the LanguageTool should be available to you.
In the dev.to editor it looks like this:

Additional plugins can be found here.

That's all from me!
Thanks for reading!
Happy spell and grammar checking everyone!

Tobias HaindlFollow

Jack of all trades (Full-stack engineer). Navigating my way through the world of tech. Writing about my journey here. Focusing on Java, Databases and Python.

Header image by Patrick Fore

Effective Remote Work

Tobias Haindl — Sun, 10 Apr 2022 18:09:14 +0000

In the last years remote work became necessary for many of us.
I do not think I need to tell you about the reason behind that.

Since the first lockdown in Austria about two years ago, I was working remotely most of the time.

Therefore, I spend some time thinking and reading about remote work.
One of my favorite books about it is Effective Remote Work by James Stanier.
In this post I want to share my personal key takeaways from it with you.

Checkpoints

During a “normal” work schedule which includes a commute to the office, the work day has naturally checkpoints built into it.

You leave the house at a certain time, you might take the train to another city or into the city center. After your commute is finished, and you arrived at the office your brain switches into work mode automatically.

At midday, you promised Alice to grab some lunch at 12.
Another checkpoint helping your brain switch into a more relaxed state, and it is way easier to unglue your eyes from the screen if you made an arrangement already.

At the end of the day you physically leave the office.
Work related thoughts can be left behind as well and your brain can switch into leisure mode easily.

Those checkpoints are essential for your mental health and your energy levels.
They help your brain transition between different states and help with unplugging from a potential stressful day.

Working remotely means that you are inviting all of the negative parts of work into your home.

P.28 Effective Remote Work, James Stanier

Sometimes work causes frustration and like James Stanier put it in the quote you are inviting all of the negative parts of work into your home.

Therefore, it might help to install a shutdown routine as the last checkpoint of your work day.

This routine can be manifold.
You might want to go for a short walk around your neighborhood after closing your laptop.
Or you can try Cal Newport’s shutdown ritual which even includes a cool-sounding shutdown phrase.

Whatever action you prefer, I think it is essential to show our mind that work is over now and leisure mode can be activated by performing a similar routine at the end of each work day.

Artifacts - the backbone of remote working

Artifacts are the backbone of remote working. Creating effective ones is an art, just like programming.

P.101 Effective Remote Work, James Stanier

James Stanier points out that written word is the optimal medium when it comes to information consumption.
Several types of Written Artifacts are helpful in a remote work setting:

Design documents
Meeting minutes
Newsletters
Wikis

I really like the idea of using an internal newsletter (e.g. team or product related) to provide information to interested people.
It is an easy way of sharing the work your team has already finished or is planning to do soon.

Another category of artifacts we encounter in our daily jobs are Codebase Artifacts like Commit messages, Pull Requests and Architecture Design Records.

Architecture Design Records (ADR) are documents describing a design choice. These documents should help with capture the reasoning behind a design decision. They should be checked in into your version control system, so they are easily accessible for any developer.

To me ADRs look very helpful - unfortunately I have not encountered any in my work projects yet.

Measure twice, cut once

We can apply this old proverb originating from carpentry and similar traditional crafts to our daily communication.
When working with an expensive piece of wood, you want to make sure all your measurements are correct before cutting through it.
Therefore, you should measure twice, cut once.

Especially in asynchronous communication time is *not * critical.
We can invest a few extra minutes to check if the chat message is easily comprehensible or not.
Before sending, take another look.

Read over it.

Check if the written words are well-structured and convey the intended message properly.

The sender should optimize and make sure that the receiver can easily understand the message!

Wrap up

Built **checkpoints **into your remote work day, to help your brain transition from leisure mode into work mode and vice versa.
Master the production of different kind of artifacts.
Do not forget to measure twice, cut once when communicating with your peers! Review your written messages like you review code from others :)

That's all from me for now, thanks for reading!
For more content on software development feel free to follow me.

Tobias HaindlFollow

Jack of all trades (Full-stack engineer). Navigating my way through the world of tech. Writing about my journey here. Focusing on Java, Databases and Python.

Photo by Avi Richards on Unsplash

Forget the 10.000 hour rule! Strive for range!

Tobias Haindl — Sun, 27 Mar 2022 17:19:14 +0000

In his book Outliers Malcom Gladwell argues that the perfection of a certain skill takes a lot of time.
He brings up successful people from different domains and analyzes their lives.
It all boils down to one thing:

practice
more practice
even more practice

Range

David Epstein in his book Range provides a fresh perspective on this debate.
Who has the upper hand in long and daunting journey striving for perfection in a certain skill:
the one who focuses early and gets in a lot of practice ?
Or the one trying out things across different fields and deciding later on what to master in life.
He brings up famous people like Vincent van Gogh and explains how a late start and a huge range of different experiences can be essential for mastering a skill.

During reading his book, I thought about how this discussion influences tech careers.
I think a late start into a tech career does not prevent one from becoming a great developer.
Earlier experiences in other domains can help with understanding the customer/user better.
Previously earned domain knowledge can be applied during requirements engineering. It can help explain the customers’ needs to colleagues etc.

Of course there are a lot of hard skills to master in tech like getting familiar with the syntax of a new programming language.
However, I think a broad range of skills can be helpful, especially when working in a team.
Having people with different skills on your team brings fresh and new perspective to your hive mind.

Let's discuss

Did you specialize early in your career on a certain niche?
Did you switch careers late?
If so, do you regret it or are your previously earned experiences beneficial?

Sources
Outliers
Range
Header picture

Intro to Postgres enums

Tobias Haindl — Mon, 07 Mar 2022 16:31:44 +0000

In most programming languages the use of enums is pretty common and heavily relied upon by developers. It took me quite some time to learn that this feature exists in the database realm as well.
Therefore, I will provide a short introductory summary of enumerated types in Postgres.

Enums are used for representing a limited number of possible values.
Status fields are a good example.
Let’s say we want to store account information inside a database table:

In our example an account can have one of the following status:

ACTIVE
DELETED
BANNED

We can create a database enum by executing:

CREATE TYPE ACCOUNT_STATUS AS ENUM ( 'ACTIVE', 'DELETED', 'BANNED');

We can then use the generated enum in our table definition:

CREATE TABLE ACCOUNT (STATUS ACCOUNT_STATUS, USERNAME TEXT, EMAIL TEXT);

Now we insert a new account:

INSERT INTO ACCOUNT VALUES ('ACTIVE', 'testuser','user@test.com');

Since we set the datatype of the STATUS table to ACCOUNT_STATUS the database now takes care of validation.

If we try to insert an account with status INACTIVE

INSERT INTO ACCOUNT VALUES ('INACTIVE', 'testuser', 'user@test.com');

The database returns the following error:

ERROR: invalid input value for enum account_status: "INACTIVE"

Since "INACTIVE" is not valid for our defined enum.

Having a data validation mechanism like this on database level helps to enforce data integrity at all times.

Querying enums

Unfortunately the values of enum types can not be retrieved by the following query:

SELECT * FROM ACCOUNT_STATUS

But one can make use of the built-in functions UNNEST and ENUM_RANGE

SELECT UNNEST(ENUM_RANGE(NULL::ACCOUNT_STATUS))

This query returns one row for each enum value.
In our example:

ACTIVE
INACTIVE
BANNED

Alternatives to enums: check constraints

We can add a similar data validation mechanism to our database tables by adding a check constraint.
In our example the constraint would look like this:

CREATE TABLE ACCOUNT (STATUS TEXT CHECK (STATUS IN ('ACTIVE', 'INACTIVE', 'BANNED')), USERNAME TEXT, EMAIL TEXT);

After defining the column name and type we add the constraint by using the CHECK keyword.
In the parenthesis following CHECK we define a boolean expression which must be true for every row of the table.
For better maintainability we can also give the check constraint a name:

CREATE TABLE ACCOUNT (STATUS TEXT CONSTRAINT ACCOUNT_STATUS_CONSTRAINT CHECK (STATUS IN ('ACTIVE', 'INACTIVE', 'BANNED')), USERNAME TEXT, EMAIL TEXT);

Enum vs Check constraint

Advantages of enums

Once defined enums can be reused in different columns or tables.
Additionally, the usage of enums helps with understanding the database schema.
Because creation of a specific type conveys more purpose: e.g. column of type ACCOUNT_STATUS is more specific than a column of type TEXT.

Disadvantages of enums

With enums we defined a new data type for our column (note the CREATE TYPE syntax above).
Therefore, the built-in string operators and functions do not work on enums.
With a check constraint do not have to define our own data type, so any built-in operator and function for the used column data type can be used.

Like in other parts of software development, designing a database schema involves tradeoffs.
So it is quite handy to have different tools in your tool belt!

If you like this summary, feel free to follow me on Twitter or here for more content.

Sources:
Postgres docs