Notes from the Week #10

I’m a bit pleased that I’ve managed to keep up weeknoting for 10 weeks now - I’m usually rubbish at building and maintaining habits.

Hubble, Hubble, Toil, and Trouble

Whilst I lead the Shift team, my “first team” in the Lencioni-sense is the Team of Team Leads. As a result of our highly-collaborative structure, we’re great at building rapport within our own teams as a result of working closely together day-in-day-out.

The Team of Team Leads (or TTL) however don’t spend that much time together, as we’ve got our own teams to be concerned with, but we’re trying to become a better team in the truest sense of the word - one way we’re doing that is to just spend time with each-other and bond, to understand eachothers’ motivations, contexts, and problems.

On Tuesday the TTL took a day-trip to the Science Museum. There was no plan (not even for when we’d take lunch!), forcing us to self-organise.

We ended up having a good ol’ wander around the exhibits

I learned some cool facts about foghorns

We took advantage of the Science Museum’s IMAX cinema to catch a short film about a Hubble repair mission in 3D - absolutely gorgeous and fascinating. (Even in space, there’s no escape from “Just hit it with a hammer until it does the thing”)

We shared trivia about ourselves during lunch, including things like “What’s the strangest dream you’ve had recently?”

We did end up coalescing into separate conversations but they were rich, deep, and left me with lots to think about.

All in all, a rewarding and fun day out!

Smokin’ on the Dock(er) of the bay

Last week I mentioned that we were going to try using containers to speed up the feedback loop of our developed-in-the-open Puppet code. In traditional Shift-style we kept a detailed log of the experiment and its objectives and I’m pleased with how it’s turned out.

We’ve tried dedicated testing solutions like Beaker and Kitchen before, but in the end all we needed was a very simple smoke test evaluation loop:

Build test image containing SystemD and Puppet

Copy module code into container

Run puppet apply against a test manifest using the module

Verify that the exit code is 2

The reason we test for exit code 2 rather than 0 is that puppet apply has non-standard exit codes - 2 means changes were applied and there were no errors, whereas 0 means no changes applied.

Our aims, which we fulfilled, are below:

Feedback loop for testing and implementing code is less than 5min.

Spin up/down of new container takes less than 1min.

Puppet can apply manifests cleanly.

We can develop in the open.

Provide a potential smoke-test environment for further developing production systems.

Timeboxed. If the working cost of setting up a Docker container for smoke tests was prohibitive we would abandon the experiment.

The spin-up/spin-down of the container is actually fast enough that the run-time of the smoke tests are dominated by the application of the manifest (installing packages, etc).

We chose to develop this in the open because we’re being strict about separating configuration from data, and in this case there’s no reason not to - check it out on our public GitHub!

Papers, Please

I’m honoured to be one of the program committee for the Software Engineering in Practice track and while I can’t talk about the papers that are coming through the system, I will say that there are some absolute bangers this year and I’m looking forward to spending a week in Montréal next year at the conference.

P.S. if anyone has any good food recommendations for Montréal, please let me know!