In this post I want to have a look at the code structure of Watson, a simple Python program for time tracking. It is the first of hopefully a long series of articles in which I analyse the architecture of open source projects. Watson is quite simple and is programmed in my primary language (Python), so it is a good starting point.

I’m currently switching from ledger-cli to hledger and I am using the chance to clean up my old accounting data a bit at the same time. Up to now I have used the standard English accounting structure that is recommended by these tools with root accounts named Assets, Equity, Liabilities, Income and Expenses and tried to keep the names of all sub accounts in English.

I recently was responsible for two service outages of a web API in a single day. This made me think about the way to test said API before deploying updates to production. Obviously, the existing unit tests, code reviews as well as manual tests were not enough in some cases.

On AWS there are two different lifecycle types for servers: On-demand and spot. On-demand servers are normal servers, as long as you pay for them they will run (unless hardware breaks). Spot instances on the other hand are cheaper, but can be taken away at any point in time. Usually you receive a notification a few minutes in advance. With Amazon Auto Scaling Groups (ASG) you can create a fleet of servers consisting of on-demand and spot instances to have a fixed baseline size and scale up when there are cheaper spot instances available. However, there is one use-case ASGs currently cannot handle: You cannot run on spot instances when spot instances are available and use on-demand instances when no spot instances are available.

Recently, I wanted to delete some of my configuration groups from the AWS Parameter Store. I use the hierarchical concept of the Parameter Store and thus wanted to recursively delete all options under a specific prefix.