• filmpick — a local movie recommendation engine, renamed

    I’ve been running a project called movies-organizer for a while. Bad name. It sounds like a tool for renaming files. Today I renamed it to filmpick — because what it actually does is help you pick your next film.

  • Overhauling a Jekyll blog — dark mode, code blocks, and all the small things

    This blog has been running on Jekyll since 2015. The content changed, the stack around it changed, but the blog itself? Same minima theme, same default code blocks, same flat archive page. It was time to fix that.

  • qubitcoin — a post-quantum Bitcoin rewrite, and why silent RPC failures matter

    There’s a particular class of bug I hate more than crashes: the API that quietly returns nothing when you give it garbage input. No error, no 400, just an empty result that looks exactly like a valid-but-empty result. This surfaced while working on qubitcoin, a post-quantum Bitcoin rewrite I’ve been building — so let me introduce that first, then get to the bug.

  • x402 - HTTP payments that actually work

    HTTP 402 Payment Required. It’s been sitting in the spec since 1991 — literally the first version of HTTP that had status codes. “Reserved for future use.” For decades, every web developer has scrolled past it and thought “huh, wonder when that’ll be a thing.”

    Well, it’s a thing now. x402 is an open protocol that revives that dusty status code into actual payment infrastructure. Coinbase’s Developer Platform team built the initial implementation, but this isn’t just a Coinbase product — Cloudflare, Polygon, and Solana are backing it as part of a broader push for “agentic payments.” The idea is that any HTTP endpoint can become a digital vending machine: request a resource, get a price, pay on-chain, receive the goods. No accounts, no API keys, no invoicing.

    I wired it into one of my projects. The integration is absurdly simple.

  • mcp-http-tools - any HTTP API as an MCP tool, zero code

    I’ve been using Grafana since around 2014 and added Prometheus and Loki to the stack not long after. Dashboards and alerts are great for knowing what happened — but when I want to actually poke at the data, it’s still curl commands in a terminal. I wanted Claude to be able to query my monitoring stack directly — but writing a custom MCP server for every API felt like too much work. So I built mcp-http-tools: a generic MCP server where you define tools in YAML and it proxies requests to any HTTP API.

  • macosx-audit - know what's running on your Mac

    In the last post I teased this one — so here it is! macosx-audit is a single-file bash script that audits your Mac’s security posture. No agents, no daemons, no root required for most checks. Just run it and see what’s there.

  • bioenv - Touch ID for your environment variables

    I haven’t been around here for quite some time. 6 years to be exact! Life got busy, work got busy, everything got busy. But I’m back and I have something cool to share. Let’s get to the point.

  • Self-hosted GitHub Actions runners — setup, gotchas, and when it's worth it

    GitHub-hosted runners are convenient until you look at the bill, or until you need something they don’t offer — a specific OS version, access to internal services, a macOS runner for iOS builds. Self-hosted runners solve all of that at the cost of running your own infrastructure. I’ve got both Linux (on a VPS) and macOS runners running now, and the setup is simpler than I expected. The gotchas, less so.

  • Self-hosting Supabase on a VPS — what you actually need

    Supabase Cloud is genuinely good. Managed Postgres, row-level security, Auth with social providers, Realtime subscriptions, Storage — all wired up, all maintained by someone else. The free tier is generous. So why would anyone self-host it? Cost, mostly. And control. And the fact that your data isn’t sitting on someone else’s hardware if that matters to you. Here’s what actually running Supabase on a VPS looks like, past the “just run docker-compose” step.

  • SQLite as the production database — when it's actually fine

    Every time someone mentions using SQLite in production, the response is predictable: “it doesn’t scale,” “no concurrent writes,” “use Postgres.” And they’re right — if you’re building the next Twitter. But most of us aren’t. Most of us are running apps that serve hundreds of requests per minute, not thousands per second. And for that, SQLite is not just fine — it’s better.