Constructive Laziness

As the title of my blog “Constructive Laziness” indicates, I’m a great believer in maximising the amount of work you don’t do. In fact, if you’re reading this before 8th July 2017, I’d like you to be constructively lazy now.  Please scroll to the bottom of this post - the bit marked “ Actions ” - there’s a couple of things I’d like you to do before you read the rest of it. I don't practice or advocate pure laziness you understand.  I don’t think I’d have survived over 20 years in IT, including a couple of startups, by being purely lazy. In fact, I enjoy working hard and I like a challenge. What I mean by “Constructive Laziness” is avoiding unnecessary work, so I can focus on the things that will deliver most value.  Not in terms of money (if I was looking for the greatest financial reward for the hours worked, I’d have moved into sales a long time ago), but in terms of solving the problem. I first got paid to write code in 1989.  I was working in a research lab, us

Over the last three months, I have been delivering Docker "Hands on Labs" (HOLs) as part of the series of Oracle Code events in EMEA. These labs have been fantastically well received.  We've been over - subscribed on each occasion.  We’ve tried to accommodate as many as we can, but still had to turn people away. In Berlin, the session was so popular we even had some of the extra people sitting on the floor! But running a HOL is never stress free – the audience will always manage to throw curve balls at you, no matter how many times you rehearse the lab beforehand. And the things that cause the most grief are usually not the ones you expect to be difficult.  So it was here.  On each occasion, the most frequent issue we had was the humble SSH client. To maximise the value of the lab time, as a pre – requisite, we had asked the attendees to install a Docker environment either natively on their laptops or in a VM. Now we weren’t that surprised to find some of our

In  my last post, I described  Syncing from GitLab to Docker Host Volume  to ensure that the correct set of configuration files were read on startup. What I didn't explain was that I don't actually recommend this approach. Did it work? Yes, it did. Yes, we were able to control and distribute the configuration in such a way that we could track changes and say what configuration had been used to start each container. So what was wrong? In a word, complexity - we made life unnecessarily complicated for ourselves.  It would have been far simpler to have built a new image for each change to the set of configuration files, and then published the image in a repository (public or private). What we were saving ourselves with the syncing approach was the effort of building a new image with each change.  But building a new image isn't that much effort, and can be automated in any case. Fewer images doesn't give any significant saving in terms of storage either.  With mul