Hello, project log
First entry — what this section is for and how I'm going to use it.
This is the first post in /projects/. I started this space to document the
things I’m building — both at work (RuralTrace, FSData, consulting) and on my
own time (papers, experiments, side projects).
Why a project log
A few reasons converged:
- External memory. I find a bug, solve it, forget the solution, hit the same bug six months later. Writing it down once costs less than rediscovering it three times.
- Sharper thinking. I notice gaps in my reasoning faster when I have to explain something to a hypothetical reader than when I just keep it in my head.
- Public surface. It’s nice to have a single URL to point people at when someone asks “what are you working on?”
What goes here
Roughly three categories:
- Project write-ups — technical decisions, architecture, what worked, what didn’t. Honest post-mortems.
- Field notes — short observations that aren’t worth a full post but shouldn’t be lost. Things like “wrong way to set up a Polars pipeline” or “interesting paper I read on time series clustering.”
- Tools & dotfiles — when I configure something the right way after getting it wrong six times, I write down the right way.
Markdown features this template supports
Inline code works as expected. So do code blocks:
# How I currently bootstrap a new Python project
uv init my-project
cd my-project
uv add polars duckdb pyarrow
Bold and italic. Links open in a new tab when external.
Block quotes for callouts and citations.
Lists, both ordered and unordered, render with brutalist accents. Headings (H2, H3) use the same Instrument Serif as the rest of the site.
Next up
The first real post is going to be on how I structure data pipelines at RuralTrace — specifically the decision to use DuckDB as the analytical layer even when the source data lives in Postgres.