Honing the craft.

You are here: My most recent posts

The dup-composer dry run tryout

Last week, I have managed to add some missing bits, chiefly docstrings, to the prototype of dup-composer, but I didn't finish and share the post with you then, as we were moving from our weekend house that took two days of work. I am sharing it today however. Now you can do dry runs, that print the Duplicity commands to be executed with the given configuration. In this blog post I demonstrate how the tool can be configured, what features are covered, the caveats, and finally the next features I will be rolling out.

dup-composer Duplicity frontend development status

My mini project called dup-composer that is aimed to develop a simple configuration based CLI frontend for Duplicity is in progress. I have kicked off actual development last week and want to share with you a progress update. TL;DR I will publish the initial prototype or alpha version in the next 1-2 days. You can find details about my progress, findings and decisions in this post.

Building a Duplicity configuration profile manager

As mentioned in my earlier post on migrating Owncloud to Docker, I am in the progress of moving all my services and development projects into Docker. In order to have a resilient setup, this also means, that I have to reconfigure my automated backup system. So far, I have been using a custom Bash script to do the backups on a few - *nix - systems. Now however, I am considering wrapping a Python program around Duplicity - which is my primary backup tool - to make the maintenance of my configuration easier.

Migrating ownCloud CE to Docker

As part of my effort to move all my production services and development projects deployed on my home microserver into Docker containers, I have started to migrate the ownCloud Community Edition I am running for my personal data into a new container based installation. I have encountered some problems and the migration required some trial and error, hence, to facilitate the iteration, I have written a shell script to handle most of the standard migration steps. This post explains, what the script does and how the migration process looks like using it, while also giving a bit of a background.

My personal case for making a change now, before it happens to me.

The general rule of thumb on how often it is recommended to change jobs used to be every five years not too long ago. Nowadays it is closer to the one to three years range, as I just learned after skimming a few sites offering general career advice. I have been working at my employer Avaya for almost 12 years, and from this 12 years, the last 9 years - although, I have grown responsibility-wise - were spent in essentially the same position. Of course, this, in itself isn't the reason, or justification for moving on to the next stage of my career by leaving Avaya. In this post, I summarize my thoughts and feelings about making this decision for myself.

Why and how I have shifted my GTD organization backbone in Evernote towards notebooks.

I have been using Evernote to manage my GTD tasks and projects from the very beginning. In case you haven't heard of the Getting Things Done (GTD) methodology - the chance of this is pretty slim as it is very popular and gets much love on the Internet for well over a decade now - it is a conceptually very simple yet extremely powerful project management and self-organization system. Finding the right technical implementation of GTD for myself took some time and also involved some trial and error, but as soon as I have found The Secret Weapon (TSW), I have decided to go with it. It worked like a charm in general, it also has proven to provide great coverage of the GTD workflow. However, The Secret Weapon's approach is highly tag oriented and this technical detail has exposed some drawbacks with time. After living with these for a while, it was time to look into how I could hedge the elements of friction in the system while retaining the granularity and flexibility that the tag system of TSW has provided.