I recently spent some time learning Nix after watching this talk by Xe. Nix is a package manager/build system for Linux and macOS. It does a number of things I really like:

• Transparent handling of source and binary packages.
• Includes a rich central package registry, but you can host your package descriptions or binaries anywhere.
• Does not require root and runs alongside any Linux distribution.
• Easy to pin or customize versions of individual packages.
• Straightforward support for project-specific dependencies.

Nix is a cool piece of tech, but in my opinion, it’s pretty hard to learn (at least at time of writing). I think this is accidental complexity: I was able to be productive with Nix in my personal projects in a few days, but it took a fair amount of research from many different sources. I took a lot of notes, then realized I wanted to publish them to share this knowledge.

So here’s my guide! “Nix From the Ground Up” aims to help explain the concepts behind Nix with a hands-on approach.

It’s been three years since my initial post about Getting Things Done. The last couple years have been weird, to say the least. I’ve still stuck to the Getting Things Done methodology, but the last year in particular has made me acutely aware of weaknesses in my practice. This year, almost all the projects I took on had high number of unknowns: becoming a manager, buying a house, and improving the house. The slight discomfort I identified in my previous retrospective has grown to an unavoidable problem. When the next steps for most of my projects aren’t obvious, my “external brain” frequently gets out of date and stops helping me. In turn, the staleness of my “external brain” erodes my trust in it. This feedback loop got me back into a pattern of reacting without much planning, and the stress of internalized time management came back. In the last six months, I’ve been improving my tooling to address this problem.

I was hacking on a personal project over the weekend that I’m deploying using Google’s Container-Optimized OS. Container-Optimized OS is quite convenient for hosting small services that don’t quite fit a web request/response workload: it is (mostly) stateless, it auto-updates, it has systemd, and (as the name implies) it runs Docker containers. It is a nice fit for one-process programming.

For debugging, I want to SSH directly into the VM instance. Especially after recently learning from a coworker how easy it is for blackhats to search the public internet for known vulnerabilities, I don’t want to leave an SSH port open continuously. Even with regular security updates, I’d rather avoid the attack surface. In the past, I would modify my Google Cloud project’s firewall temporarily to allow SSH traffic while debugging and then (hopefully) remove the SSH traffic rule after I finished. This has been cumbersome, but there hasn’t been another solution that’s quite as simple.

Enter Tailscale! Tailscale creates a peer-to-peer Virtual Private Network (VPN) with very little fuss. While Container-Optimized OS is mostly designed for running containers, I found I can run the Tailscale static binary with a little kludging.

In the two months since I published gg 1.0, a project to reduce the friction in working with Git, I’ve been working to make it more accessible and easier to install. To this end, I’ve made three big improvements:

• A standalone Go library, gg-scm.io/pkg/git, allows any Go program to interact with Git repositories. (I may end up writing another blog post just about this — stay tuned!)
• Windows support, complete with MSI installer.
• An APT repository for Debian and Ubuntu users.

If you’re interested in trying out gg, it’s never been easier: see the instructions at gg-scm.io. Read on if you’re interested in how to package a Go program for Windows and Linux.

Today, I released a small library called postgrestest. It spins up an ephemeral PostgreSQL database in Go. I’ve found it quite useful for writing tests that use PostgreSQL while keeping the test hermetic and reasonably fast. In my benchmarks, starting a server takes roughly 650 milliseconds and creating a database takes roughly 20 milliseconds — a 70% improvement and 90% improvement, respectively, over a postgres Docker container in the default configuration.

You can install it with:

go get zombiezen.com/go/postgrestest