References

Here you can find a small collection of my public projects. Feel free to click through the links and give me feedback or suggestions. For more information, you can also contact me.

OakHost

Putting Macs that are designed for consumers in a data center environment is a challenging task, but it offers a lot of creative freedom. We set out to build the perfect infrastructure to accommodate these challenges while benefitting from the excellent power to performance ratio of Apple silicon.

Podkast (DE)

In the Podkast by Deniz and me, we talk bi-weekly sometimes about the latest news in the tech sector, personal experiences, and things that annoy us. Feel free to check out our podcast and leave us some listens or nice comments :)

Previous Projects

Bootstrapper - Explaining Programming (DE)

Programming is hard. But if you still want to start, you can stalk my YouTube channel. There, I try to introduce complete beginners to some terms, situations, and circumstances, explained as simply as possible so that even someone without prior knowledge can understand.

Simple Regex Language

Regular expressions are incredibly powerful. And confusing. It’s too easy to make mistakes. You forget to escape a dot or confuse ^ with $. Simple Regex Language - or SRL for short - provides a solution. And in many programming languages. Bonus: Every SRL query can be converted into a conventional Regular Expression.

Nothing for Android

This app proves that you can achieve success with nothing and get over 20,000 downloads. Furthermore, it was mentioned several times on AndroidPIT and in a video by iBlali.

Miscellaneous (GitHub)

On GitHub, I have a few public projects that mainly arose out of boredom.

Mistakes I’ve Made

Failure is a friend dressed up like an enemy. – Jeff Goins

No one is perfect, and everyone makes mistakes. However, it’s often hard for us to admit that. I believe that mistakes aren’t bad and help us recognize our strengths and improve our weaknesses. That’s why I want to stand by all my results. This includes the positive results listed above, but also the following, in which I want to explain what I did wrong and what I learned from it.

2017: Permission groups are overrated

A sync job between the database and Active Directory was tasked with synchronizing all permission groups of all employees. If a group is removed from the database, the job also removes it from the AD. The problem arises when the used AD library has a bug after an update, which always returns an empty string as the group name. As a result, after the update, all groups of all company employees were removed from the AD, denying access to all services.

What I learned:

  • Unit tests are not a panacea and do not ensure that errors cannot occur. Therefore, it’s essential to ensure that the development environment matches the live version as closely as possible. Automatic library updates should also be approached with caution.
  • For jobs with sensitive tasks on many objects, it’s wise to implement a check for unusual actions (Sanity Checks). For example, the job could abort if more than 20% of users are removed from groups, preventing total damage.
  • Good documentation is crucial. I already blogged about this in 2016 (DE), and it shows that I still have a long way to go. While many parts of the application were well documented, the management and debugging of jobs were not, resulting in a delay of about half an hour because I was unreachable at the time of the incident.

What I had already learned:

  • Rollbacks should be quick and possible on the go. Therefore, the original problem was fixed within half an hour of detection, and the synchronization could be restarted.
  • Unit tests help prevent such errors, which is why a similar error could be prevented in the past. Unfortunately, I did too much mocking in this scenario.
  • Identifying the exact cause is essential. If you can only speculate about the error but cannot reproduce it, you risk repeating such an error. Fortunately, I was able to trace the bug to the exact commit in the library, ensuring that the behavior is back to normal.

2014: DELETE FROM ….

Every IT professional has a day when they radically clean up a production database. In my case, it was the time recording database, which records the working hours of employees. Instead of a SELECT, I accidentally executed a DELETE. Fortunately, with the appropriate WHERE statement, so only a few employees were affected. However, the result was that some had to re-enter their times because the backup did not work reliably.

What I learned:

  • Backups are incredibly important and must be tested for functionality. A broken backup is no backup.
  • Handle permissions with care. While it’s nice to have many options, with great power comes great responsibility. Each user should only be assigned the rights they really need. These should be restricted accordingly in a live environment. Read-only access by default is also a good idea.
  • Development environments should always be used for tests, and they should not have access to production systems.

What I had already learned:

  • Backups are essential, which is why a backup was available. Unfortunately, as mentioned, it was incomplete and therefore unusable.
  • Communication is crucial. The error was communicated, the affected employees were informed and could re-enter their times, limiting the damage to a minimum, and the working hours were correctly accounted for at the end of the day.