Jan 24, 2021


Leavers and joiners

This week one of the devs who has been on the team from the beginning left (though not far away, only to another team on GOV.UK), and a replacement will be joining on Monday.

That’s sad, but it does give us another opportunity to test and iterate our on-boarding documentation. One of the other devs on the team has really taken charge of this process, helping to onboard a bunch of frontend devs, and has recently been working with our tech writer to get it all written up, which is great.

Secret management

I wrote up some documentation on secrets, and was kind of surprised by how many we have already. It would be nice to remove some of these, for example maybe we could replace the special shared OAuth tokens—they’re essentially just shared passwords—with a mechanism to automatically negotiate a temporary credential, which would also have the advantage that leaking it becomes less of a concern. But then we need the secret which gives access to the secret generator. Hmm.

Another problem with our secrets is that they’re set in environment variables, which of course don’t have any sort of auditability: the process can just read them willy-nilly. The GOV.UK PaaS doesn’t have any sort of secrets management built in yet, but it’s on their roadmap. Maybe we can live with the current situation until then.

On another note, I removed detect-secrets from our repositories, as it was just a pain. We gave it a good go, but I think we’re now all firmly of the opinion that it’s better to just not have the need to touch production secrets when doing local development.


Our apps still have “prototype” in the name. But are they? We’ve learned a lot about the domain since starting. There are some implementation choices we made which are starting to bite us. Is it time to throw our current code away and start again, producing the first version of some non-prototype apps?

Well, maybe. It depends on who is building the real authentication solution for the cross-government account system.

If it’s us, then we’ll need non-prototypes at some point. If it’s the Digital Identity programme, they’ll build the thing and we’ll just be implementing a frontend on top.

On the assumption that it will be us, I’ve been looking into using ORY Hydra as our OAuth/OIDC tool1. Currently we use doorkeeper and doorkeeper-openid_connect, which work, but doorkeeper-openid_connect is looking for maintainers, and we’d ideally not end up implementing bits of the prototols—why use libraries if we still need to do it ourselves?

Better tests

I learned a couple of handy things about testing this week:


This week I read:


Another good session in my Pulp Cthulhu game this weekend. In which the characters saw a terrible vision of the future, and then promptly repressed the memory, keeping only a faint impression that “somewhere in China” is relevant to their current predicament.

Unfortunately for them, China is pretty big.

Having one of the players handle writing up the session recap is a game-changer, I wish I’d started doing this years ago. My GM notes for this campaign are so brief compared to the previous one.

Time Tracking

I’m still keeping up with my time tracking, tweaking it as I go.

I decided to add a chores:self category, which so far covers my morning routine: showering, getting dressed, and making a pot of tea. I decided that if I’m aiming to have under 2 hours of untracked time a day, losing a 45-minute chunk every morning wasn’t a good start. I should probably also track meal times in that, though I eat pretty quickly.

I’m also considering adding a leisure:misc for slacking-off mindless-browing-the-internet time and the like. I originally planned to not track that, but maybe it would be nice to be able to distinguish time lost due to measurement errors or gaps, and time spent doing nothing useful.

  1. Though we’ll also need to look at more options, and possibly do some spikes, to ensure we make the “best” choice.↩︎