Apr 4, 2021


This was a short week.

I was on support for Monday and Tuesday—nothing exciting happened—then back on team work on Wednesday and Thursday, before the bank holiday Friday.

Speaking of which, we launched a small experiment on the bank holidays page: if you’ve consented to cookies, then there’s a button to remember your location, so that when you next visit the page the right tab is pre-selected. We’re thinking about where else on the platform we can use that information (eg, highlighting nation-specific parts of content).

What else did I do? Not much.

I finished off writing some documentation, and reviewed a PR, and made a presentation about the accounts / personalisation architecture to give at next week’s GOV.UK Tech Fortnightly. I also made a list of problems with our “Set up a new Rails application” docs, as it misses a lot of steps (and gives the steps it does have in the wrong order), and set up continuous deployment for our release app.

Finally, I’ve decided to make a work to-do list, to capture non-team-related work, or team-related-work which is either something for me to do specifically (as tech lead) or which is too small to be worth writing a proper card for and taking to planning:

Work to-do list.

I’ve also been working through the DDaT framework, making a list of evidence for each skill I’m supposed to have, so that I can talk about how great I am (and ask for more money) when the skills survey next comes around. But that’s a bit slow going.


This week I read:

RPG Blog

It’s a new month, so there’s a new post: I Roll in the Open.

A lot of GMs advise rolling behind a screen, so you can fudge rolls when you get a result which would be bad for the story. I think that at best fudging is unnecessary, and can be remedied by being more thoughtful about what rolls you ask for (and I go in to how I think about rolls), and at worst cheating, where you’re explicitly ignoring the rules of the game.


I hit a bit of a snag with this VPS on Sunday morning, I did some routine maintenance, pruning old docker volumes. This warns you that you can lose data, but reassures you that only volumes not attached to a running container will go away:

$ docker volume prune
WARNING! This will remove all local volumes not used by at least one container.
Are you sure you want to continue? [y/N]

I had a quick check: bookdb, running; bookmarks, running; RPG blog, running; pleroma, running. All good.

I hit “y”.

And saw all of those services immediately crash as docker deleted their volumes from underneath them. That’s not supposed to happen.

Half an hour later I was back up and running, having switched all those containers to use bind-mounts rather than named volumes, with data restored from backups. I’ve lost a few days of analytics for the RPG blog, but nothing else is gone.

While docker volume prune deleting in-use volumes was very annoying, and confusing (the error message says it’ll do the exact opposite!), it’s good that my backup process is actually working. This is the first time I’ve needed to restore a database backup, so they were totally untested.

I also took the opportunity to improve how I manage dockerised services, so now: