Earlier, I wrote an article about how to create a connection to a database service in Cloudfoundry. The reason for this was to backup and restore a Mongo database, which is the topic of this article.

1. SSH-tunnel

First, built up an SSH-tunnel (details see here):

There are several tools to solve the "Let's schedule an event" and "Let's find a common result via a poll" - problems. The most famous is doodle.com. However, most of these tools gather data. How this data is used can not be influenced by or even known to the user. Remember: If you're not paying for it, you become the product.

Recently, I joined a new project. As always when this happens, I got a ton of new credentials for websites, platforms and so on. This flood can easily be managed using password managers like KeePass. However, one of my new colleagues showed me some cool features I didn't know before. This article is a short review of those features.

Some values of an application have to be provided from "the outside" of the application, for example the secret of a JSON Web Token (JWT). This secret must remain private and must not be shared. Hence, it cannot be written in a properties file, especially not in an open-sourced project.

In a local environment and also in a deployed state, this can be done by providing an environment variable:

Since recently, my employer msg DAVID is using the Clifton StrengthsFinder 2.0 to improve the personal development of each employee and also promote better cooperation in teams. In this article, I publish my personal test results and comment on them. This post serves as a retrospective for myself and as a reference for my colleagues so that they can learn how and why I do things the way I do.

For the last two weeks, I’ve been testing a new tweak for my self-management: Timeboxing. This article explains the principle and summarizes my insights.

In the great book "Tools of Titans" by Tim Ferris, I read about manager’s schedule and creator's schedule. In this article, I explain the difference between both and how I use them.

Until recently, I told my team to squash all of their commits on a given feature branch to just one commit. Every feature branch consisted of just this one commit and could be integrated into develop so that develop read just like a sequence of features. After further consideration, I changed that. Here are reasons for both approaches:

Pro-Squash:

I keep forgetting how to get the overall test coverage of multiple modules in IntelliJ IDEA. There are several ways, here's my favorite:

You can test this by cloning my tiny test repository.

Yesterday, I was working at the office. This is an unusual thing for me to do because since a couple of months, I'm working from home. My 6-headed team consists of three developers in Romania, one business consultant working from home in Hannover, one part-time project lead working from different places and me. It really makes no sense for the whole team or even the three of us living in Germany to share an office. So we are working from wherever we like.