Platform changes and Bazel rebuilds

Bazel is a build system from Google which uses a strong change detection model to solve a number of build correctness problems make-like systems struggle with. While it handles most cases of rebuilds correctly out of the box, one recurrent gap is that if glibc changes bazel doesn’t notice and may produce broken results. I’d like to talk about how we hacked around this problem at work, since there aren’t a lot of well documented solutions out there.


About a year ago, I decided to get into 3d printing. I had a specific project in mind (which of course I still haven’t done) for building a fairly large interior structure for a pelican case, and so at the advice of a friend I decided to pick up a Creality CR-10v3 for its large build volume. Fast forward many months of building custom firmware, cursing furiously at slicer settings and hand-tuning the printer to get acceptable precision and I finally started making practical prints. But … printing is kinda slow. A single part can routinely take 3-4h to bake. Printing multiple parts at a time is possible, but printing time is mostly a factor of tool-head movement time. More movement for multiple parts means more time than printing the parts serially, and more time means more risk of bed ahesion or something else failing. So better to make printing multiple objects sequentially efficient, or even to print in parallel. Enter print farming, and my second CR-10v3.

Farewell StrangeLoop

In 2009 when Alex ran the first StrangeLoop, I was a sophomore in High School. When I started hanging out in Clojure circles around 2013, StrangeLoop was the place to be. Rich had spoken there, Zach had spoken there, as would Joe, SPJ and many many more industry leaders.

This post serves as cross-proof that I’m in the fediverse.

A eulogy

Originally on cohost

Cram; a new dotfile manager

Ah dotfiles. Love ‘em or hate ‘em we’ve got to live with ‘em. While Rob Pike has words about Unix hidden files, we (almost all) work on computers and with software whose behavior is determined in large part by hidden files in our home directories. There’s probably a .bashrc or .zshrc and a whole .ssh/ and .config/ directories kicking around on your workstation full of stuff that matters a fair bit to your day-to-day and standing up a new work machine is probably a wasted day of trying to remember homebrew incantations and source software.

Superficial Simplicity

For the last decade I’ve chased and wrestled with the ideal of “simple” software, but I’ve come to see it as a false summit and want to spend some ink on why in the hope that it can lead to a better understanding of simplicity and more intelligent conversations about complexity.

Software working conditions

If you’ve spent any time around a traditional workshop or machine shop, you’ve probably seen signs about how safety is everyone’s responsibility and about keeping the shared space clean. In an environment with sparks, unrated flammables left around are a risk. In an environment with rotating tools like lathes loose clothing that can wrap or snag and pull can lead to injury. Less extreme examples like sweeping up the shop and keeping the fridge clean all fill different parts of the same shared obligation to the other users of a space.

Techdebt Tornado

Techdebt tornado, adj.; pejorative

One who successfully delivers changes with limited or counterproductive regard for architecture.

One who produces work, especially feature work, at the cost of existing architecture and without developing a successor architecture.

The Thirty Million Line Problem

This blog post is a review and musing on a talk of the same title “The Thirty Million Line Problem” (2015) (~1h lecture + 40m q&a).