Skip to content

Posts

Tech learnings and musings from the.dusktreader.

the.dusktreader blog © 2025 by Tucker Beck is licensed under CC BY-SA 4.0

Betwixt: a data transformation layer design spec

TLDR

Your DB type and your API type are not the same shape. Stop trying to squish them together with awkward hooks, aliases, and non-local mapping functions. Betwixt your models lives a new, delcarative mapping layer.

Pick any non-trivial Python backend. There is a database type (an ORM row, a @dataclass, an attrs class) and there is an API type (a Pydantic model, an msgspec struct, whatever the framework demands). They are not the same shape. They cannot be the same shape: one is constrained by the storage schema, the other by the wire contract. Mapping between them is real work.

Introducing chill-out: ice out supply-chain attacks

chill-hero

TLDR

Every new dependency release is an attack window. chill-out audits your lockfile, blocks anything too fresh to trust, and fixes violations automatically. It works for Python and npm, and takes thirty seconds to wire into CI.

Your lockfile has a freshness problem you might not be thinking about. A new release of any package you depend on, direct or transitive, is a window of time when a supply chain attack could reach your production environment before anyone notices. chill-out closes that window by refusing any locked version that hasn't cleared a configurable cooldown period.

Charm your Pydantic models with Wizdantic

TLDR

Conjure populated Pydantic models from thin air with an interactive terminal wizard.

CLI tools that need structured configuration often end up with a maze of input() calls, hand-rolled validation, and forgotten edge cases. If you already have a Pydantic model describing that configuration, wizdantic turns it into an interactive wizard with a single function call. You define the shape of the data once, and the wizard handles the rest.

Introducing mkdocs-editor-notes: Keep Your Documentation Clean While Tracking TODOs

TLDR

Track TODOs right in your docs without cluttering them. Use footnote syntax, get an auto-generated tracker page.

Writing documentation is hard. Keeping it up-to-date is even harder. When I'm writing, I inevitably encounter sections that need more work:

  • I should add an example here
  • Need to verify this with the team
  • TODO: Update this after the API changes
  • Does this make sense to beginners?

These thoughts are valuable—they represent improvements, questions, and reminders that will make documentation better. But where do you put them?

  • in dev
  • 4 min read

UEFI Arch (Throwback 2012)

Throwback

In 2012, I documented the process of setting up a laptop with UEFI. I read it every now and then, and I thought it might be interesting to others as well. Here is the unedited document copied from my google drive.

Installing ArchLinux on a Notebook with UEFI

Makefile magic

TLDR

I have a cool structure, nice convenience functions, and flashy magic that "makes" my projects pretty awesome!

For a fairly long time, now, I've been including a Makefile in all of my projects. It's a nice way to provide access to actions that need to be done over-and-over in a software project. It's familiar (to most folks), works on almost any reasonable dev environment out-of-the box, and makes getting started on the project really straightforward.

Over the years, I've developed a lot of cool stuff that I like to include in my Makefiles. This ranges from some basic patterns and structures that I've found helpful to some fancy "magic" that makes it nice to work with.

make help example

Example of make help with my custom Makefile

Today, I decided to create a GitHub repo to showcase these patterns in a few example Makefile entries. I thought it might be nice to talk through what's offered there and explain some of the deeper magic.

  • in dev
  • 29 min read

Introducing Typerdrive: Develop API-Connected Typer Apps at Lightspeed

TLDR

I created a package to extend Typer with some great features for building CLIs that communicate with APIs.

During my time as an engineer working primarily with Python, I've written a a fair number of CLIs powered by Typer. One type of project that has been popping up for me a lot lately involves writing CLI programs that interface with RESTful APIs. These are pretty common these days with so many service companies offering fully operational battlestations...I mean, platforms that can be accessed via API.

I've established some pretty useful and re-usable patterns in building these kinds of apps, and I keep finding new ways to improve both the developer experience and the user experience. Every time I go about porting some feature across to a new or old CLI, I wish there was a library that wrapped them all up in a nice package. Now, there is:

typerdrive-logo typerdrive-logo

  • in dev
  • 29 min read

Bootstrapping Python projects with copier

TLDR

I used copier to create a python project template that includes logic to deploy the project to GitHub.

I tend to create a lot of Python projects of various sizes. In the past few weeks, this has been even more frequent. Just a few days ago, I started a new project called drivel. It is a CLI and Python package that generates fun metasyntactic names (think foo, bar, baz) to use in my code. You can read more about it in the drivel docs if you want to learn more.

When I went to start this project, I did what I usually do. I copied one of my other projects to a new directory and started ripping stuff out, renaming things, and just generally futzing around until I had the scaffolding for my new project. This isn't hard work, but it always ends up taking a lot longer than I expect.

There are a lot of conventions that I've gotten attached to in my projects over the years. And, while it's not that hard to just borrow things from past projects, it's boring work that cries out to be automated.

So, I decided to create a project template that would allow me to do all this in just a matter of seconds.

  • in dev
  • 4 min read

Self-contained Python scripts with uv

TLDR

You can add uv into the shebang line for a Python script to make it a self-contained executable.

I am working on a Go project to better learn the language. It's a simple API backed by a postgres database.

When I need to test out an endpoint, I prefer to use the httpx python package inside an ipython REPL over making curl requests. It's nice to be able to introspect responses and easily package payloads with dicts instead of writing out JSON.

Anyway, I decided to write a script to upsert some user data so that I can beat on my /users endpoint.