Links: Feb 16

Change of plan! Will now try to write shorter posts but more often. With bigger posts, if I miss a date, they start to scare me off writing them as I know that would require substantial time investment.

Recently I have discovered how once never-failing task prioritisation strategy can backfire. You most certainly know the strategy: an interesting, engaging, and enjoyable task should be stashed and used as a treat after one sorts out boring or urgent assignments.

You’d wonder how this could possibly go wrong? Here’s what happened with me: one of the tasks, which I long wanted to implement myself, was finally approved and assigned to me with low priority. I revelled and carefully set it aside so I could come back to it with enough time to do it neat and proper. Alas! For the next three (!) weeks, due to routine, urgent, and other business, I haven’t got enough time to tackle it.

Eventually, the task received medium priority and I had to implement it within certain time constraints. This obviously meant it wasn’t as neat as I wanted it to be; this also meant it wasn’t a treat anymore! Broken hopes and bad mood instead of delight and satisfaction! Horrible experience, beware. Now I’m trying to get back to it and rework the way I would at least be content with.

Okay, let’s shove in some of the interesting links I came across last month:


Tom Limoncelli referred an interesting article that defines five stages of how management, owners, and investors treat IT in their businesses:

  1. Cost center
  2. Service Provider
  3. IT Partner
  4. Business Peer
  5. Business Game Changer

Implication is the further stage you’re in, the better it is. It struck me though that some firms actually may advance in a backward direction! I would not want to stay with the firm that made more than one step backwards (one step might be a coincidence, two — a pattern).

Why would someone writing in Python and Ruby want to learn Java? Here’s an explanation: Why I’m Learning Java.


    • Valuable bookmark: how to count and quantify the number of syscalls a program makes? Here’s an example using SystemTap.
    • Very good explanation why systemd raises so many questions and fires heated debate — systemd: broken by design.
    • Vector — an interesting tool for predictive scaling and flexible downscaling of your AWS environments.
    • Blockade — a utility for testing network failures and partitions in distributed applications.
    • Provocatively titled post ‘10 things we forgot to monitor‘ lists some of the things you shouldn’t be missing in your monitoring. Included mostly for scripts examples.
    • Flapjack — monitoring notification routing + event processing system. More details on how and why and a live demo.
    • Very expressive presentation on how to build a modern monitoring subsystem:




Seems I’ve failed to make this post short. Have so many interesting things in my drafts that it’s challenging to stop once started. Will improve next time. That’ll be all for today, folks.