Remember the good old days, when IT got a new server. It was a special event - and naturally the naming game. Finding that special name for the server, which neatly fitted into the naming scheme adopted (be it Indian cities, Nordic mythology or cartoon characters).

This ought to be then, but the ceremony still happens regularly in many IT departments, where servers are treated with the same affection as with pets - and with all the bad side effects it may bring along.

At its simplest  feature toggle is a small if-statement, which may be toggled without deploying code, and used to enable features (new or changed functionality) in your software.

In an agile setup most developers love  having feature toggles available, as they often allow for a continuous delivery setup  with very little friction and obstacles. While this is true, it often seems developers forget to think of feature toggles as ephemeral, and doesn’t realize what a terrible mess, this can cause - given they don’t remove the toggles once the feature is launched and part of the product.

Building audiobooks on (Debian) Linux in the m4b format is actually possible and doesn’t have to be a pain. I’ve found numerous recipes with shell instructions, but having a nice simple app to handle the building of the books seems much easier.

Most of the apps available for Linux seemed to be in a pre-alpha state, but after a few experiments I’ve settled on m4baker, which - while a bit rough - actually seems to do the job just fine.

I’m digging through a backlog of podcasts and the gem of the day goes to SE-Radio podcast. In episode #247 they talk about DevOps and while I’ve preached and practiced DevOps for years, as mainly as common sense, the podcast did present a more reasonable argument why it works.

Developers are praised and appreciated for short time to market; the number of new features they introduce and changes they make to the running system.

Get your company implementing DMARC now…

During the past 5-6 years email industry efforts have been pushing the DMARC standard along. It provides the best widely supported and seemingly efficient way to - as a domain-owner - protect the domain from misuse and abuse in terms of spam and phishing attacks.

As sending email has often been a wild-west, and knowing who is a valid sender of email may prove a challenge for many companies - and as most IT developers does seem to care too much about the finer details of email (and production just as bad email headers as HTML markup :-) ), implementing DMARC protection on your domain may actually be a challenge.