Explore

After my tokens ran out I realized how valuable hand-coding is

Built LLM-backed editorial tooling that turns repo history, notes, and existing markdown into concrete portfolio-writing workflows instead of generic text generation.

I built `local-llm` because I wanted Pi to feel local, usable, and not annoyingly fragile. More specifically, I wanted a coding-agent setup that could run against a local `llama.cpp` server on my 3090, come up inside a Nix shell, reuse one shared model server across terminals, and still keep the nicer Pi ergonomics I actually wanted: wrappers, model config, wiki support, context-mode, subagents, and a few task-specific local helpers. That sounds tidy when I say it like that now. It was not tidy while I was putting it together. The repo is small, but the job it is doing is pretty specific: take a general agent stack and turn it into a repeatable local workstation setup with predictable runtime behavior.

The second version of the project looks narrower and smarter. After the first market-facing phase stalled out, the evidence does not suggest I gave up on the whole idea. It suggests I came back to it with a different product shape, a different notebook runtime, and a stronger bias toward operational coherence.

I built Obsidian Remotion because I wanted a Markdown note to behave like a Remotion sketchbook. The practical goal was pretty simple: write prose, drop in `ts` or `tsx` blocks, and get live, type-checked Remotion previews in a side pane without cramming React and Remotion into the plugin bundle itself. That separation ended up being the whole project. I wanted the plugin to stay relatively small and handle editor integration, diagnostics, preview lifecycle, and UI. I wanted the vault to own `node_modules`, so the actual React and Remotion runtime stayed under the user's control. In practice that felt much less cursed than trying to smuggle a whole frontend runtime into an Obsidian plugin and then hoping version skew would somehow be fine.

The most recent era of this repo is where a bunch of half-formed ideas finally snapped together. Expanded the repo into an editorial workbench with blob-backed media logistics, Obsidian-friendly authoring, and LLM-driven tooling for prioritizing and drafting portfolio content.

A technically interesting object is not automatically a market-ready object. That sounds obvious. It was still a lesson I had to pay for in the real world. By the time the project reached this phase, there was already a lot of serious work behind it: terrain-derived geometry, custom tooling, mold iterations, pour logs, text refinements, process math, and actual candles that looked pretty good. The next step seemed straightforward enough: make the brand legible, get the booth and collateral together, and see what happens when the project leaves the workshop.

At some point a prototype stops being interesting just because it exists. That was the phase I hit in late spring 2025. I had enough geometry, enough molds, and enough poured objects to know the idea was real. What I did not have yet was a workflow that could survive iteration cleanly, or a product shape that felt settled enough to build around.

I thought the hard part was going to be the geometry. It was hard, sure. But once the mountain shapes started becoming workable, the project revealed its real personality: molds, wax, curing, shrinkage, leakage, demolding, lettering, and all the little physical details that do not care how elegant the code looked five minutes ago.

The geometry pipeline was stanky for a while. What I needed sounded simple enough: select a real mountain, extract usable terrain, shape it into something I could fabricate, and iterate quickly enough to compare ideas instead of getting lost in tooling churn. In practice this meant GIS inputs, notebook environments, CAD viewers, mesh processing, and a lot of dependency weirdness all trying to occupy the same room.

The first question is: what is the project? That sounds obvious, but it was the problem underneath a whole pile of other problems. I was trying to make mountain-shaped candles. More specifically, I was trying to use digital fabrication to create wax sculptures derived from real terrain. That part was clear enough. What was much less clear, especially early on, was whether this was fundamentally a candle business, a fabrication experiment, a software project, an art object, or some scrappy mutant combination of all four.

Northwest Waxworks started as a pretty simple idea: use digital fabrication to turn mountain terrain into candles people would actually want. It got complicated quickly. What looked at first like a geometry problem turned out to be a stack of interlocked problems: terrain data, CAD, notebook tooling, mold design, wax behavior, text legibility, process repeatability, branding, market fit, and then, once all that was already plenty, a whole notebook-runtime migration from Jupyter to marimo.

I acquired a 20-year-old Staübli RX90 industrial robot and retrofitted it with a custom-built control system, transforming it into a precise and ergonomic tool for cinematic motion control.

I built this repo to make backups less ad hoc. It started with a Borg script and host-specific pattern files, then grew into tooling for migrating old Arq backups into Borg, and later picked up an offsite replication step to Backblaze B2.

Built a welding positioner capable of supporting several hundred pounds with infinitely variable rotation speed and 90+ degree tilt

The least glamorous part of this repo is probably the most representative part. Recovered the site from toolchain drift by pinning dependencies, vendoring unstable pieces, and treating maintenance work as part of the product instead of background cleanup.

In this quick and dirty project we assemble the official Prusa mk3s enclosure

A rusty heart beats away inside this thinking rock

Stepper drivers are used as a simpler interface to control stepper motors, here we use the esp-idf RMT peripheral to send step pulses

In the interest of repeatable builds we must create a nix derivation for a rust-esp32 toolchain

My nixos partition has filled up, here are some steps to recover

Using an arduino uno as a logic analyzer

Diagnosing stepper timing issues with another esp32

After a BIOS update my computer booted straight to Windows. Using diskpart, bcdedit, and bootice the issue was resolved.

Communicating between a Flutter app on Android and an ESP32 under ESP-IDF

Here we go, time for PAIN

Setting up an esp32 development environment in nixos using vscode and ESP-IDF

Let's spin a stepper motor using ESP-IDF (FreeRTOS) on an ESP32!

3d printing allows quickly iterating on taking assembly issues and applying them to the design

The design process has to start with validating the basis for decisions

In this quick post we demonstrate using `strace` to diagnose why docker is starting so danged slowly

Developing a report of upcoming tasks from WeKan using Jupyter Lab

In order to experiment with new video software this early machining project was finally published!

At some point I realized that plain markdown was not visually or structurally distinct enough for the kind of work I wanted to publish. Expanded the site into a denser technical publishing tool with notebook embedding, richer article framing, and better support for project artifacts that did not fit clean blog-post shapes.

Sometimes the best solution is less solution.

An insane plan to allow posts on this site to perform computations and display output

Once I moved to Gatsby, the problem stopped being “how do I have a site?” and became “how do I structure a site that can actually hold the work I want to publish?” Built a content-driven portfolio model with tags, series, clusters, page-generation rules, and stronger TypeScript-checked structure.

By moving GatsbyJS configuration to a typed language the implementation can be checked by the computer

[Worse is Better](https://en.wikipedia.org/wiki/Worse_is_better) is a development philosophy that prioritizes practicality over functionality.

In this follow up post the calculations made earler are taken into practice and some sawdust is made.

With a quick set of measurements and a 3d printer many household items can be fixed

In this post we explore the steps and calculations needed to create a custom frame

Continuing to cross stuff off the Shop Improvement list. We build a shop wide air system on the cheap!

With experience across the entire stack we are well poised to build a team to solve small to medium projects

I started this repo because I wanted a place to publish projects, then kept rebuilding it until it could actually support the kind of technical writing and project history I wanted to put on it.

I started this repo because I wanted a place to publish projects. That was the whole brief. Built the first version of the portfolio, pushed past the starter-template stage, and turned an initial Zola site into the beginning of a custom publishing system.

This is a long-shelved generator project connecting a light garden engine to a small permanent magnet motor.

I am attempting to set up video conferencing on mattermost and the experience is stanky

Repairing a broken handwheel on an old lathe with some TIG welding and machining.