Everyone is addicted to something: be it success, sex or just coffee. Some time ago I noticed that drinking a coffee too early after the previous one makes me hot-tempered to the point of being irritated. So, I tried to go one week completely caffeine-free. After two days of terrible headaches and being overall tired as hell my abstinence lasted for two weeks before giving up. This gave me an idea: how about, instead of the silly New Year’s resolutions, I try to abstain from my addictions, one month at a time?

This is just basic theory of probability, and it’s overly simplified, but it goes like this:

Suppose an event has probability of occurring, say, 1%. So, on average, let’s say it happens on 1 out of a hundred attempts. What’s the probability it happens at least once in 10 attempts? Well, it’s (1 – probability it never happens), that is 1 – 0.99 ^ 10 ~ 10%. In 20 attempts, the probability goes up to 1 – 0.99 ^ 20 ~ 18%.

Over the past few days I finally got to evaluating the New Relic APM. It feels like it’s the go-to solution for monitoring application performance, and we’ve been having some issues with it in the past, so it felt natural to give it a try. Continue…

My boss asked me to document the various sources of information I get my daily dose from. Well, I never understood sharing articles on Twitter and such, I follow only friends on Facebook, so no social sources for me.

I am an old guy, that means one thing only: RSS! Here goes my list:

IT News

Gizmodo (once I subscribed to Engadget as well, but it seemed duplicate, and Gizmodo didn’t fill my screen with huge images directly in the feed)

Commit content

Any code deployed to production (be it a web application, mobile application, …) must have been committed into the repository earlier. Commits should deal with one thing (~1 issue) and one thing only. Commit early, polish later.

Commit message

Write an English sentence describing the commit. If a commit deals with an issue from the issue tracker, start the sentence with the issue key.

Intro

Application will know which database to connect to, which resources to use, etc from a configuration file, or better, environment variables (http://12factor.net/config).

Application code always lives in Git. It is deployed to the various environments either as a Git checkout, or using a specialized tool (Jenkins + rsync or such).

Development

Typically, this is the localhost of each of the developers. This is the only environment where code changes are allowed. It’s possible for the database structure or resources configuration to get temporarily out of sync with the code base.

Testing & Production

Testing serves to allow testers (internal or external with customer) to try out changes in the application before it hits the production. The purpose of production is probably clear

One important rule: application changes should (must) be deployed atomically. This means that if I change some code that needs an updated database schema, I must upgrade the schema at the same time (atomically) as I deploy the updated code – otherwise the application could crash or even corrupt data.

Of course, never deploy to production anything that was not previously verified on testing.

Upgrade procedure

Take the application down – redirect to static server, other instance, …

Upgrading your operating system could be a harrowing experience. However, with some forward thinking, you can survive it quite unharmed.

Allocate around 1 man-day for the upgrade, the same as for migrating to another computer or such. You might think it will be less, but just in case – make sure you won’t need to be productive on the day of the upgrade. Pick Saturday if you can.