Dispatches¶

Using VS Code Remote Tunnels for Headless Remote Development

The best development machine isn't always the one under your hands. Laptops are wonderful daily drivers, but they're also thermally constrained, battery-bound, and constantly moving between networks. For serious build and test work, especially on Go projects that need real Linux, Windows, and macOS coverage, I keep the compute somewhere stable and let my laptop act as the control plane.

With VS Code Remote Tunnels, you run the VS Code CLI on a remote machine, authenticate it with your GitHub account, and connect to that machine from VS Code or vscode.dev without opening inbound firewall ports, maintaining a VPN profile, or teaching dynamic DNS yet another way to disappoint you.

Remote development used to mean one of two things: SSH into a server and live in a terminal, or carry around a fragile stack of VPNs, jump boxes, port forwards, editor extensions, and local configuration. That worked, but it made the developer's laptop the place where every concern collided.

Modern remote development is a cleaner architectural split:

• The laptop is the interface. It provides the screen, keyboard, editor chrome, GitHub sign-in, and whatever local ergonomics make you productive.
• The remote node is the execution environment. It owns the CPU, memory, disk, operating system, SDKs, build cache, test dependencies, and long-running processes.
• The identity provider brokers access. With Remote Tunnels, GitHub authentication gives you a familiar access path without requiring a public SSH endpoint.

It lets you treat development environments more like durable infrastructure and less like whatever happened to be installed on the laptop.

For my open source work, the benefits are immediate. The builds are fast, but fast is relative when you're compiling repeatedly, running integration tests, linting large module graphs, or validating cross-platform behavior against platform-specific dependencies. A headless machine with more cores, more memory, a warm module cache, and a stable network turns the edit-build-test loop into something predictable. The laptop stays cool. The battery lasts longer. The build cache stays where the builds happen.

Hard Days

A Long-Awaited Exhale

For most of my life, I thought everybody's brain was about like mine. Loud, busy, and hard to steer.

I figured other people were just better at keeping theirs in the lane. That was the story I had.

They could sit still. They could start the thing they didn't want to start. They could schedule the appointment, make the call, answer the email, finish a small task, then move on with their day like it hadn't cost them anything.

I thought I was lazy. Or weak in some way nobody had named out loud yet.

School taught me how to fake my way around it.

I could read a chapter three times and come away with almost nothing. Then a teacher would tell some sideways story in class, not even part of the lesson, and I'd remember the whole thing years later in detail. I could put off a paper until the night before, write it half-crazed at the kitchen table, and get a better grade than I did on the one I had tried to do the right way.

Nobody called that a pattern, not then.

Teachers said I was bright but scattered. Smart but unfocused. Capable of more, if only I would apply myself.

I heard that enough times that it stopped sounding like an opinion. It sounded like a verdict.

And I believed it.

A Mindful Habit for Maintaining Online Accounts

Free trials pile up. Side projects die. Shopping sites you used once still have your card on file. After a few years, you end up with a lot of accounts you don't remember creating and even less confidence in how they're secured.

Most online accounts don't disappear just because you stop using them. They can still hold your data, old passwords or recovery factors, and sometimes your payment details. Every forgotten login is another door you left unlocked.

• Breach Exposure: forgotten accounts often still have weak or reused passwords, and many either don't support MFA or have it available but not enabled.
• Privacy Leakage: abandoned accounts can keep personal data, billing details, and usage history long after you stop using the service.
• Recovery Pain: if one gets hijacked, recovery can fail fast when the old email address, phone number, or other method is no longer yours.

Before deleting any account, confirm you no longer need access to purchased content, invoices, or exported data from that service.

Regular audits aren't exactly fun, but they keep your account footprint smaller and easier to defend.

I used to clean this up in occasional panic sessions. It never stuck. But what finally worked was a simple lifecycle: inventory, classify, decommission, and monitor.

Transitioning GitHub Pages to Deploy from Artifacts Instead of a Branch

For a long time, publishing this site was simple in the best possible way. ProperDocs built the HTML, Materialx handled the presentation, and a GitHub Actions workflow ran properdocs gh-deploy through task deploy. That command force-pushed the rendered site to a gh-pages branch, then GitHub's Pages backend quietly noticed the branch update and published it.

That model still worked, but the warning lights started blinking in the generated pages build and deployment job. GitHub was warning about Node.js 20 deprecation inside the Pages deployment path.

The noisy warning was only the symptom. The deeper problem was architectural: the deployment was still using a Git branch as an artifact transport.

The fix was to stop publishing a branch at all. The GitHub Action now builds the content, uploads the contents as GitHub Pages artifacts, and then actions/deploy-pages publishes it through GitHub's modern Pages deployment path.

Ansible Vault: A Practical Deep Dive

Ansible runs need secrets at runtime: passwords, API tokens, private keys, TLS material, and cloud credentials. You don't have to keep those in Git. External stores, CI variables, and untracked local files are all valid patterns. Ansible Vault is for the case where you want encrypted variables and files versioned next to the playbooks, roles, and inventory that use them, with the vault password kept out of the repository.

This post walks through ansible-vault and the runtime flags that unlock encrypted content during a run: create and edit vaulted files, wire passwords from files or prompts, use vault IDs, and avoid the mistakes that still leak secrets after decryption.

Vault is built into Ansible. It's not a centralized secrets manager, and it doesn't replace runtime discipline around logs, registers, and task output.

Out of Time

Using a GitHub Discussions-First Approach Intake for Maintainers

I still spend time re-routing #1234: a question filed as a bug, a feature pitch that should've been an Ideas thread, an install problem with no version in the body. Discussion category forms fix what shows up in the forum once someone lands there. This post is about policy and wiring: where contributors go first, and what happens when they open New issue anyway.

Some maintainers want questions, ideas, and suspected bugs in GitHub Discussions, triaged in public, with Issues opened only after the work is real. That takes five pieces: chooser routing, a reserved issue template, discussion forms (see How to Write Effective GitHub Discussion Templates for YAML and the Ideas and Community Help examples), CONTRIBUTING.md, and a pinned rules thread.

How to Write Effective GitHub Discussion Templates

I'm wiring up community intake for an upcoming open source project. Issue forms and a pull request template were the easy parts. Community discussions were what I hadn't nailed yet.

I wanted a public place for questions and early ideas without Issues turning into a pile of one-liners. I've set up GitHub Discussions on other repos before; this time I wanted the same structured intake issue forms already give you.

So I used discussion category forms: YAML on the same schema as issue templates, with required fields, defaults, and labels on create, tied to a category instead of an issue chooser. Questions stay in the forum. Work that needs a tracker still opens an issue.

If you've shipped issue templates before, the field types won't surprise you. What's different is the plumbing: .github/DISCUSSION_TEMPLATE/, one YAML file per category, and a filename that must match the category slug—not bug.yml copied from Issues.

Publishing Docker Images to GitHub Container Registry

GitHub Container Registry ("GHCR") is GitHub's OCI-compatible container registry at ghcr.io. If your source code, releases, issues, permissions, and automation already live in GitHub, publishing container images to GHCR keeps the distribution path close to the repository that produced the image.

In this post, we'll publish a Docker image two ways: first manually from a local terminal, then automatically from GitHub Actions whenever a GitHub Release is published. Along the way, we'll cover image naming, authentication, permissions, release-driven tags, OCI labels, and the small details that make GHCR feel predictable instead of mysterious.

GHCR differs from a generic public registry when your project is already GitHub-centered:

• Images can be associated with a repository.
• Repository permissions can be used for package access.
• GitHub Actions can publish with the built-in GITHUB_TOKEN.
• Images can be public or private.
• Tags, labels, and package metadata sit near the release and source history.
• The registry supports standard Docker and OCI tooling.