Hypertext Dispatches

I'm Just a River

Ryan Johnson — Sun, 19 Apr 2026 00:00:00 +0000

I'm Just a River

!!! heart "In Loving Memory" Written to process the death of my nephew.
Rest in Peace, Phin.

Phineas Harvey Alexander Tillman June 4, 2001–January 11, 2026

--8<-- "./snippets/ai-recording-disclaimer.md"

A Deep Dive into golangci-lint

Ryan Johnson — Sat, 18 Apr 2026 00:00:00 +0000

golangci-lint is one of the highest-leverage tools in the Go ecosystem because it turns a loose collection of static analysis tools into a single, fast, repeatable code-quality gate. Used well, it catches real bugs, reduces review noise, and helps maintainers keep a project consistent without turning style preferences into endless pull request commentary.

For many Go teams, the mistake is not adopting golangci-lint. The mistake is adopting it without a strategy. Enabling too many linters at once, tolerating unexplained //nolint comments, or treating the default output as a substitute for judgment quickly turns a useful signal into background noise.

This post walks through how golangci-lint works, how I think about configuring it for a real project, and how to run it in ways that are practical for both day-to-day development and long-term open source maintenance.

Much of what I know about golangci-lint was learned the unglamorous way: maintaining Go-based open source projects where lint output has to hold up in front of contributors, CI systems, release processes, and real users. That includes work across HashiCorp Terraform providers, HashiCorp Packer plugins, and Go SDKs.

If you want the broader project list behind that perspective, see the Open Source Projects section of my resume.

That context matters because this is not an abstract "here are the docs" walkthrough. It is an opinionated maintainer's view of what actually keeps linting useful in a long-lived Go codebase.

What the Record Shows

Ryan Johnson — Fri, 17 Apr 2026 00:00:01 +0000

{ style="display: block; margin: 0 auto;" .skip-lightbox }

!!! note "" Image Source: InnerSloth

There is a kind of performance that no longer feels like performance because you have been doing it so long that it has settled into your bones.

Each morning arrives with its own familiar ritual: the steady voice, the practiced calm, the expression that says, "I belong here." After enough years, it becomes automatic. People hear you speak, ask for your judgment, trust what you have to say. Your name appears on work that matters.

From the outside, it can look like certainty.

But beneath all of that, there can still be a quieter voice saying something else entirely:

!!! quote "" "Today will be the day they figure out I don't belong here after all."

It has a name, of course: Imposter Syndrome. That old habit of treating your own record like disputed evidence.

That voice is stubborn. It doesn't yield easily to experience, praise, or proof. It survives accomplishment with an almost insulting ease. It can sit in the same room with a long career, meaningful work, and the respect of other people, and remain completely unimpressed.

I've spent most of my professional life inside the orbit of very large institutions, places whose names carry their own kind of weather.

On paper, my record isn't especially mysterious. I've held serious roles. I've contributed to products and open source projects people actually use. I've written extensive designs and documentation that helped people do their jobs. I've even written a book. I've earned certifications and accreditations, sometimes less out of ambition than out of a private need to quiet the voice that keeps insisting I've not done enough. I've stood in rooms where others came to listen, and I've spoken at more technology conferences than I could name without stopping to count, somehow managing not to waste their time.

Automating Releases with GoReleaser

Ryan Johnson — Fri, 17 Apr 2026 00:00:00 +0000

{ align=right width=225 .skip-lightbox }

Shipping a polished release for a software project by hand gets old fast: building for multiple platforms, packaging archives, generating checksums, publishing GitHub releases, cutting container images, and updating a Homebrew tap is exactly the kind of repetitive work that should not depend on memory or heroics.

GoReleaser turns that whole workflow into a repeatable release pipeline that scales from your first CLI to a heavily used open source project.

!!! tip "Not Just for Go-based Project Releases" Despite the name, GoReleaser supports releasing for Go, Python, Rust, Zig, and TypeScript based projects.

Manual releases often seem manageable at first, then turn into a mess the moment users ask for macOS support, ARM builds, checksums, containers, or a one-line brew install experience. Maintainers end up writing ad hoc shell scripts, copying files into GitHub Releases by hand, and hoping the version embedded in the binary matches the git tag they just pushed.

GoReleaser solves that by treating release engineering as configuration. You describe what to build, package, sign, and publish, then let one command, or one CI job, do the same thing every time. It handles the boring parts well enough that you get to focus on your project instead of your release checklist.

How to Create Terminal Demos as Code with VHS by Charm

Ryan Johnson — Thu, 16 Apr 2026 00:00:01 +0000

{ align=right width=225 .skip-lightbox }

Manual terminal recordings tend to age badly. The timing is inconsistent, the cursor jumps, the window size changes between takes, and the one command you needed to correct means starting over. If you have ever tried to capture a polished CLI walkthrough for a README, release note, or docs site, you have probably spent more time re-recording than documenting.

VHS from Charm (a.k.a., Charmbracelet) fixes that by turning terminal demos into source code. Instead of screen recording your desktop, you write a small .tape file that describes the terminal session: window size, theme, typing speed, commands, pauses, screenshots, and output format. Then VHS renders the result into a GIF, MP4, WebM, or even a directory of raw frames.

There are two hard parts in terminal documentation:

Capturing a terminal session that looks clean and readable.
Keeping that session reproducible as the tool, docs, and CLI output evolve.

Traditional recording tools help with the first part, but not the second. A hand-recorded GIF is an artifact, not a build input. Once it drifts from reality, you either live with stale docs or record it all over again.

VHS treats terminal demos the same way we treat infrastructure, tests, and CI workflows: as code.

Git Submodules Deep Dive for Platform Engineering

Ryan Johnson — Thu, 16 Apr 2026 00:00:00 +0000

Platform engineering teams face a recurring challenge: shared code. You have a library of Terraform modules that ten product teams consume, a set of Ansible roles that every configuration management pipeline needs, or a collection of CI/CD workflow templates that must stay consistent across dozens of repositories. The naive solution is to copy files between repositories, but then every fix requires propagating changes to every consumer by hand. Git submodules offer a structured alternative: embed one Git repository inside another as a tracked dependency with an explicit, auditable version reference.

This post covers how submodules work at the Git level, how to add and consume them, the day-to-day operations that platform engineers and DevOps practitioners need to know, CI/CD automation with GitHub Actions, and the common pitfalls that cause teams to abandon submodules prematurely.

{ align=center .skip-lightbox } { align=center .skip-lightbox }

Lost in Shades of I'm Okay

Ryan Johnson — Wed, 15 Apr 2026 00:00:00 +0000

Lost in Shades of "I'm Okay"

{ align=center .skip-lightbox }

!!! note ""

This piece contains discussion of depression and hopelessness. Please read with care.

There is a particular meanness to depression.

It doesn't always arrive like a storm. More often it comes like summer heat: slow, saturating, difficult to argue with. It settles into the walls, into the body, into the space between one thought and the next, until everything feels heavy with it. The house seems to take it in. Even the light looks tired by the time it reaches the room.

I have known days when the floor felt like the safest place to keep my eyes. Old wood, scarred and splitting, honest in its damage. Floorboards don't ask anything of you. They don't expect performance. They don't require you to explain why lifting your head feels like lifting stone. Looking down became a kind of prayer then, if prayer can be made out of exhaustion. I studied every crooked crack as if it might tell me how to stay in one piece. Lost in shades of "I'm okay."

Shadow of the Cloud

Ryan Johnson — Tue, 14 Apr 2026 00:00:02 +0000

Shadow of the Cloud

39 North · Shadow of the Cloud

--8<-- "./snippets/ai-recording-disclaimer.md"

Oh My Zsh on macOS: A Reference for a Clean, Maintainable Shell

Ryan Johnson — Tue, 14 Apr 2026 00:00:01 +0000

!!! example ""

```shell % omz version __ __ ____ / /_ ____ ___ __ __ ____ _____/ /_ / __ \/ __ \ / __ `__ \/ / / / /_ / / ___/ __ \ / /_/ / / / / / / / / / / /_/ / / /_(__ ) / / / \____/_/ /_/ /_/ /_/ /_/\__, / /___/____/_/ /_/ /____/ master (061f773) ```

If you spend a large part of your day in a terminal, your shell stops being just a shell and starts becoming part of your development environment. On my Mac, that environment is built around Zsh, Oh My Zsh, the Spaceship prompt, and a small set of plugins that improve the things I do constantly: Git, GitHub, containers, Kubernetes, Terraform, Python, Go, and Ansible. The result is not flashy for the sake of being flashy. It is a shell that surfaces useful context quickly, stays out of the way when I am focused, and is still simple enough to maintain without turning ~/.zshrc into a junk drawer.

Automate Locking Closed Issues and Pull Requests on GitHub

Ryan Johnson — Tue, 14 Apr 2026 00:00:00 +0000

Automate Locking Closed Issues and Pull Requests on GitHub

Locking a closed thread prevents new comments from being added. It keeps old threads quiet and lets maintainers direct their attention toward work that is still active. This post covers two approaches: a shell script using the GitHub CLI for one-time or ad hoc locking across one or more repositories, and a GitHub Actions workflow using dessant/lock-threads for ongoing automation.

Managing Stale Issues and Pull Requests with GitHub Actions

Ryan Johnson — Mon, 13 Apr 2026 00:00:00 +0000

Managing Stale Issues and Pull Requests with GitHub Actions

Every open-source project eventually faces the same problem: issues and pull requests that were once active go quiet. A bug report with no updates in a year. A pull request that was never finished. A feature request that the contributor lost interest in. These threads accumulate over time, and before long a repository's issue tracker becomes a graveyard of items that no one knows are still relevant.

The actions/stale GitHub Action gives maintainers a way to address this automatically. It scans issues and pull requests on a schedule, labels anything that has gone too long without activity, warns contributors that it will be closed soon, and closes it if no activity follows. The whole process is configurable and runs without manual intervention.

This post covers what the action does, how to configure it, a real-world example from one of my own projects, and an honest look at the tradeoffs so you can decide whether it makes sense for yours.

Ignoring Files in Git with `.gitignore`

Ryan Johnson — Sun, 12 Apr 2026 00:00:00 +0000

Ignoring Files in Git with `.gitignore`

Every Git repository accumulates files that should never be committed: compiled binaries, dependency directories, editor configuration, operating system metadata, and local environment files that contain secrets. Without a mechanism to exclude them, every git status output and git add . command becomes a manual filtering exercise. The .gitignore file is Git's built-in solution to that problem, and understanding how it works end to end, including its pattern syntax, scope model, and debugging tools, eliminates a class of frustration that affects developers at every experience level.

Tracking Empty Directories in Git with `.gitkeep`

Ryan Johnson — Sun, 12 Apr 2026 00:00:00 +0000

Tracking Empty Directories in Git with `.gitkeep`

Git tracks files, not directories. That distinction is easy to overlook until you run into the consequence: an empty directory you create locally simply does not exist after a fresh clone. No staging, no commit, no push will capture it, because Git has nothing to work with. The .gitkeep convention is the widely adopted workaround for this behavior, and it requires nothing more than a single empty file placed inside the directory you need to preserve.

Controlling Git Repository Behavior with `.gitattributes`

Ryan Johnson — Sat, 11 Apr 2026 00:00:00 +0000

Controlling Git Repository Behavior with `.gitattributes`

A .gitattributes file lets you assign attributes to file paths in a Git repository, giving you explicit control over how Git handles those files during checkouts, merges, diffs, and archives. Line ending inconsistencies, corrupted binary diffs, merge conflicts in generated files, and bloated archive packages are all problems that a well-constructed .gitattributes file prevents before they reach your team.

Managing GitHub Repository Settings with Probot Settings

Ryan Johnson — Fri, 10 Apr 2026 00:00:00 +0000

Managing GitHub Repository Settings with Probot Settings

GitHub repository settings can be managed through the web UI, the REST API, or the gh CLI. Default branch, merge strategies, issue tracking, vulnerability alerts, labels, branch protection rules: regardless of how you change them, the result is the same: no audit trail tied to your repository, no peer review process, and no straightforward way to reproduce the configuration in another repository without repeating the same steps manually.

The Probot Settings app solves that problem by treating repository configuration as code. You commit a .github/settings.yml file to your repository, and the app syncs its contents to GitHub's API every time the file changes. The settings are versioned, reviewable, and repeatable.

This post covers how the app works, how to install it, what it can configure, and how to structure a settings.yml file that covers the settings I apply to every project.

Fare Thee Well

Ryan Johnson — Thu, 09 Apr 2026 00:00:00 +0000

Fare Thee Well

39 North · Fare Thee Well

!!! note "Rendition Notes" This rendition features original lyrics inspired by the traditional folk song "Dink's Song", also known as "Fare Thee Well".

--8<-- "./snippets/ai-recording-disclaimer.md"

Please Format Your Code Blocks: GitHub Issue Etiquette

Ryan Johnson — Thu, 09 Apr 2026 00:00:00 +0000

Please Format Your Code Blocks: GitHub Issue Etiquette

You are a maintainer. You have carved out thirty minutes between meetings to work through the open issues on your project. You open the first one. The title is promising. The reporter clearly hit a real bug. And then you see it: a wall of unformatted YAML, raw Terraform, and shell output, all smooshed together into a single paragraph, every newline stripped, every indentation gone, triple-quoted strings collapsed into nothing, angle brackets eaten by the Markdown renderer. You cannot tell where the config ends and the error begins.

You close the tab.

If you are a maintainer, you have lived that moment.

If you are a contributor, please keep reading, because this post is for you, and it will help your issues get more attention.

DCO vs CLA: Managing Contribution Agreements in Open Source

Ryan Johnson — Wed, 08 Apr 2026 00:00:00 +0000

DCO vs CLA: Managing Contribution Agreements in Open Source

When you accept code contributions to an open-source project, you are entering a legal relationship with every contributor. Who owns the code? Do you have the right to relicense it? What happens if a contributor later claims you do not have permission to use their work? Two mechanisms exist to answer those questions before they become problems: the Contributor License Agreement (CLA) and the Developer Certificate of Origin (DCO).

This post takes a thorough look at both: what they are, how they work, the tradeoffs involved, and the tooling available to automate enforcement on GitHub.

A Better Inbox for Pull Requests on GitHub

Ryan Johnson — Tue, 07 Apr 2026 00:00:00 +0000

A Better Inbox for Pull Requests on GitHub

GitHub released a new Pull Requests dashboard in public preview at the end of March 2026. It replaces the existing pull request list at github.com/pulls with something that functions more like an inbox: a view that surfaces the PRs that actually need your attention rather than presenting every open PR you are associated with.

Why I Use JetBrains GoLand and PyCharm Over VS Code

Ryan Johnson — Mon, 06 Apr 2026 00:00:00 +0000

Why I Use JetBrains GoLand and PyCharm Over VS Code

VS Code is a remarkable editor. It is fast, extensible, and free, and it has become the default tool for an enormous portion of the developer community. I use it myself for PowerShell, general Markdown, and lightweight editing. But when I sit down to write Go or Python, GoLand and PyCharm are where I do my best work.

This is not a condemnation of VS Code. It is an explanation of why, for language-specific work, purpose-built IDEs make me a more productive and deliberate developer.

Hypertext Dispatches

I'm Just a River

I'm Just a River

A Deep Dive into golangci-lint

What the Record Shows

Automating Releases with GoReleaser

How to Create Terminal Demos as Code with VHS by Charm

Git Submodules Deep Dive for Platform Engineering

Lost in Shades of I'm Okay

Lost in Shades of "I'm Okay"

Shadow of the Cloud

Shadow of the Cloud

Oh My Zsh on macOS: A Reference for a Clean, Maintainable Shell

Automate Locking Closed Issues and Pull Requests on GitHub

Automate Locking Closed Issues and Pull Requests on GitHub

Managing Stale Issues and Pull Requests with GitHub Actions

Managing Stale Issues and Pull Requests with GitHub Actions

Ignoring Files in Git with `.gitignore`

Ignoring Files in Git with .gitignore

Tracking Empty Directories in Git with `.gitkeep`

Tracking Empty Directories in Git with .gitkeep

Controlling Git Repository Behavior with `.gitattributes`

Controlling Git Repository Behavior with .gitattributes

Managing GitHub Repository Settings with Probot Settings

Managing GitHub Repository Settings with Probot Settings

Fare Thee Well

Fare Thee Well

Please Format Your Code Blocks: GitHub Issue Etiquette

Please Format Your Code Blocks: GitHub Issue Etiquette

DCO vs CLA: Managing Contribution Agreements in Open Source

DCO vs CLA: Managing Contribution Agreements in Open Source

A Better Inbox for Pull Requests on GitHub

A Better Inbox for Pull Requests on GitHub

Why I Use JetBrains GoLand and PyCharm Over VS Code

Why I Use JetBrains GoLand and PyCharm Over VS Code

Ignoring Files in Git with `.gitignore`

Tracking Empty Directories in Git with `.gitkeep`

Controlling Git Repository Behavior with `.gitattributes`