Posts

I think I found my new favourite thing about Claude Code: using it to upgrade Hugo. Switching to a static blog generator was supposed to make things easier, but given how infrequently I actually write anything here, every time I sat down I’d fight with the latest version of Hugo for a while and sometimes just give up. (Of course I probably didn’t really need to upgrade Hugo, especially since I Dockerized it… but I have some sort of weird obsession to keep my systems and tools always up to date). ...

I acquired a copy of Learn to Program with Minecraft from No Starch Press a while ago but only recently decided to crack it open. Multiple versions of Minecraft, Spigot, and Python have been release since, but the provided zip file on the publisher’s website hasn’t been kept up to date. I took some time to figure out how to replicate the setup and figured I’d write it down for posterity. These instructions are for Windows 11. ...

Last year I wrote a post for the Shopify engineering blog on the subject of Modelling Developer Infrastructure Teams. I figured I should link to it here as well. I’ve had several industry peers reach out to me to exchange notes on building dev-infra teams, so it seems the topic resonated with some people!

The last Raspberry Pi that I bought (the one that powers my ledweb setup) came with a remote control intended for media servers, one of the official OSMC remotes. I thought it would be fun to use it to do something involving my LED panel, like switching between different modes or something. I couldn’t find any information on using this remote outside of OSMC, however. I’ve never done any programming that interfaced directly with a USB device either. But it turned out to be surprisingly straightforward. ...

Something I regularly tell my daughter, who can tend towards perfectionism, is that we all fail. Over the last few years, I’ve seen more and more talks and articles about embracing failure. The key is, of course, to learn from the failure. I’ve written a bit before about what I learned from leading the MozReview project, Mozilla’s experiment with a new approach to code review that lasted from about 2014 to 2018. I’m still teasing lessons out of the experience. Here are a few that I’ve been thinking a lot about lately. ...

I’ve discussed and linked to articles about the advantages of splitting patches into small pieces to the point that I don’t feel the need to reiterate it here. This is a common approach at Mozilla, especially (but not just) in Firefox engineering, something the Engineering Workflow group is always keeping in mind when planning changes and improvements to tools and processes. Many Mozilla engineers have a particular approach to working with small diffs, something, I’ve realized over time, that seems to be pretty uncommon in the industry: the stacking of commits together in a logical series that solves a particular problem or implements a specific feature. These commits are generally authored, reviewed, updated, and even landed as a set. They tell a complete story; indeed, you could view this process as similar to writing a novel: the book is written, edited, and published as a complete unit. ...

This is the last post in a three-part series on A Vision for Engineering Workflow at Mozilla. The first post in this series provided some background, while the second introduced the first four points of our nine-point vision. The Engineering Workflow Vision (continued) 5. Reviews are straightforward and streamlined The Engineering Workflow team has spent a lot of time over the last few years on review tools, starting with Splinter, moving into MozReview, and now onto Phabricator. In particular, MozReview was a grand experiment; its time may be over, but we learned a lot from the project and are incorporating these lessons not just into our new tools but also into how we work. ...

In my last post I touched on the history and mission of the Engineering Workflow team, and I went into some of the challenges the team faces, which informed the creation of the team’s vision. In this post I’ll go into the vision itself. First, a bit of a preamble to set context and expectations. About the Vision Members of the Engineering Workflow team have had many conversations with Firefox engineers, managers, and leaders across many years. The results of these conversations have led to various product decisions, but generally without a well-defined overarching direction. Over the last year we took a step back to get a more comprehensive understanding of the needs and inefficiencies in Firefox engineering. This enables us to lay out a map of where Engineering Workflow could go over the course of years, rather than our previous short-term approaches. ...

The OED’s second definition of “vision” is “the ability to think about or plan the future with imagination or wisdom.” Thus I felt more than a little trepidation when I was tasked with creating a vision for my team. What should this look like? How do I scope it? What should it cover? The Internet was of surprisingly little help; it seems that either no one thinks about tooling and engineering processes at this level, or (perhaps more likely) they keep it a secret when they do. The best article I found was from Microsoft Research in which they studied how tools are adopted at Microsoft, and their conclusion was essentially that they had no overarching strategy. ...

Having taken advantage of a Black Friday sale at BuyaPi.ca and picked up a Raspberry Pi 3 Model B, I then needed something to do with it. I’m not sure how it popped into my head, but at some point I realized my bar absolutely needed a Times Square zipper-type LED display. I mean, it seems so obvious in retrospect. At first I thought about making one but then I thought “hahah yeah right no”. Luckily Adafruit caters to people of a similar mindset, so I got myself a superfancy 64x32 RGB LED matrix. The assembly tested my very rusty soldering skills (and also made me realize how my near vision has degraded in the past ten years…), but it powered up just fine! ...