vt100

Principles.

Every tool here exists because something I care about was being broken, and it bothered me enough to fix it.

In Inventing on Principle, Bret Victor describes a way of working: find something you believe so strongly that seeing it violated feels wrong, not just inefficient, and let that guide what you make. You don't build a thing because it's a good idea. You build it because the world breaks your principle and you can do something about it.

I didn't plan this collection that way, but looking back, that's how it grew. Each tool answers one principle. Together they're what I mean by calm architecture: systems small enough to understand, that tell the truth about themselves, and that don't need tending.

  1. A build should be a command I can run myself.

    What I saw. CI as a remote machine running its own YAML dialect, starting cold on every build. When it fails, the only way to debug it is to push another commit and wait.

    What I made. punchcard The pipeline is mise run ci: the same command on my laptop and on the server, in a workspace that remembers between builds.

  2. A program should run on the machine with nothing in between.

    What I saw. A single static binary shipped inside an image, through a registry, under a container daemon: three new things to run so that one thing can run. Meanwhile systemd sits on every Linux server, already able to isolate, limit and restart it.

    What I made. unit It writes hardened systemd units from a short description and deploys over SSH. Nothing new runs on the server.

  3. Look before you change, and look at the real thing.

    What I saw. Tools that change machines without showing what they're about to do, and tools that show a plan, but against a state file that drifted from the machines long ago.

    What I made. smed It reads each machine, shows a diff against what's actually there, then applies it. There's no state file; the machines are the truth.

  4. Nobody should read half a truth.

    What I saw. Data pipelines that rebuild tables one at a time, so a reader can catch the database halfway through, and tests that fail after the bad data is already published.

    What I made. molt A folder of SQL builds into DuckDB in one transaction, tests included. Either everything is new and tested, or nothing changed.

Not resolved yet

Two principles I keep seeing broken, with nothing here to answer them yet.

  1. I should know how my machines are without logging in to them.

    What I see. Updates waiting, a reboot pending, a service that failed overnight, and I only find out by logging in and looking. The usual answer is a monitoring platform bigger than the machines it watches.

  2. Logs are text, and I should be able to grep them wherever they are.

    What I see. Logs either stranded on each server, or shipped to a search cluster that needs its own care and its own query language. journald already stores them well.

A principle isn't a rule I apply. It's a way of noticing. If one of these tools doesn't live up to its principle, that's a bug, and I'd like to hear about it on GitHub.