Hypertext Dispatches

Announcing the Packer Plugin for Artifactory

ryan@tenthirtyam.org (Ryan Johnson) — Tue, 04 Aug 2026 00:00:01 +0000

Today marks the v0.1.0 release of the Packer Plugin for Artifactory, my first standalone Packer plugin. This one's been on the list for a while.

The plugin adds an artifactory post-processor. After a Packer build produces an OVA or OVF, the post-processor uploads it straight to JFrog Artifactory. Build, export, upload, done. No handoff step, no separate script, no copy-pasting artifact paths into another job.

Primary targets are the vmware/vsphere and vmware/vmware Packer plugins, covering vSphere, Fusion, and Workstation. Any other builder that emits OVA or OVF should work too. Authentication supports username and password, API key, and access token. Custom properties let teams attach version, OS, and build metadata right from the post-processor block.

Announcing the Packer Plugin for VMware vSphere v2.3.0

ryan@tenthirtyam.org (Ryan Johnson) — Tue, 04 Aug 2026 00:00:00 +0000

Packer Plugin for VMware vSphere v2.3.0 was released on 03 August 2026!

This release expands how vsphere-clone starts a build. Inventory templates still work. So do content library items, and local or remote OVF/OVA packages. Remote sources support HTTP, HTTPS, and HTTPS with basic authentication. Pick the source that matches where the image already lives, then customize, provision, and publish as usual.

v2.3.0 also expands vSphere data sources for inventory lookups in HCL, ships project documentation at vmware.github.io/packer-plugin-vsphere, and includes reliability improvements, clearer validation, broader test coverage, and dependency updates.

Oh, Adeline

ryan@tenthirtyam.org (Ryan Johnson) — Sun, 02 Aug 2026 00:00:00 +0000

An original murder ballad, inspired by the traditional folk songs “Poor Ellen Smith” and “Two Sisters”

!!! warning "Trigger Warning" This piece incl...

For It All

ryan@tenthirtyam.org (Ryan Johnson) — Sat, 01 Aug 2026 00:00:00 +0000

!!! lyrics "Lyrics"

**For It All** The radiator’s humming The lights are turned down low I’m leaning on the counter Watching head...

How to Structure an Ansible Collection

ryan@tenthirtyam.org (Ryan Johnson) — Tue, 21 Jul 2026 00:00:00 +0000

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

I recently wrapped up work on an Ansible collection I developed for a customer through my role at Broadcom. With the project complete, I wanted to write down the structure it followed and the reasons behind it. This guide is for developers building their first collection and maintainers checking an existing one against Ansible's recommended practices.

Those decisions matter once an Ansible repository has been in use for a while. Roles sit beside playbooks that depend on custom filters. Lookup plugins get copied from one repository to another. The same automation has to run locally and in Ansible Automation Platform (AAP), where repository-specific plugin paths become difficult to maintain.

A collection gives that content a package name and a standard layout. Roles, plugins, playbooks, documentation, and tests can ship together as a versioned package under a namespace such as example.platform. Once you understand where each part belongs, the structure is straightforward.

Farmer's Daughter

ryan@tenthirtyam.org (Ryan Johnson) — Thu, 02 Jul 2026 00:00:01 +0000

!!! note "Reflection" Published alongside Field After Field, Song After Song, a reflection on the ...

Field After Field, Song After Song

ryan@tenthirtyam.org (Ryan Johnson) — Thu, 02 Jul 2026 00:00:00 +0000

90s country music takes me back to Saturday mornings in Southwest Georgia, when my dad, my brother, and I would climb into an old two-toned orange and white ...

Development Containers: Consistent Environments for Every Contributor

ryan@tenthirtyam.org (Ryan Johnson) — Wed, 01 Jul 2026 00:00:00 +0000

{ align=right width="200" .skip-lightbox }

Some engineering teams hit the same friction eventually: A new developer clones the repository, follows the setup instructions, and spends the next two hours debugging why the toolchain that works on everyone else's machine doesn't work on theirs. The versions are slightly different. A system dependency is missing. The environment variable was never set. By the time they make their first commit, they've already burned half a day on tasks that had nothing to do with the code they were hired to write.

Development containers help solve this by codifying the development environment as a container image. Every contributor uses the same tools at the same versions on every machine. Onboarding becomes more a matter of opening the repository rather than following a tedious setup guide.

A development container, commonly called a "devcontainer", is a Docker container configured as a development environment. It holds the runtime, tools, extensions, and settings required to work on the project, and that configuration lives in the repository right next to the codebase.

The Development Containers specification defines the format that editor and platform integrations follow. VS Code, GitHub Codespaces, JetBrains Gateway, and the Dev Containers CLI all consume the same .devcontainer/ definition. A valid configuration should work across those entry points without forked setup docs.

Instead of a README.md that says "install x v1.24, y 1.11, and z v7.1.2," the repository includes a container image specification.

MCP Servers: A Practical Guide to Context on Demand

ryan@tenthirtyam.org (Ryan Johnson) — Fri, 26 Jun 2026 00:00:00 +0000

Model Context Protocol, or MCP, is how an AI client asks for context instead of waiting for you to shuttle it in. Clients can already expose open files, workspace context, and sometimes terminal output. Remote services, databases, CI runs, output from another shell, you still feed that in by hand. MCP gives the client a shared protocol to discover tools, read resources, and reach those systems directly. If the LLM is doing the reasoning, an MCP server is the part that lets it look around and, when you allow it, act on current state.

The model doesn't have to rely only on whatever you remembered to supply it. It can ask for current state, call a tool you exposed, and come back with something closer to evidence.

Less autocomplete. Less guessing. More "I checked x and y, and here is what I found."

MCP is an open protocol for connecting AI applications to the systems around them.

An MCP server can expose a few kinds of things:

Tools: actions the model can ask to run, such as read_logs, run_tests, or a query you wrapped instead of exposing raw shell.
Resources: readable context, such as repository metadata, service health, runbooks, or log files.
Prompts: reusable prompt templates that package common workflows.

An MCP client, such as VS Code or Cursor, connects to one or more servers and surfaces those capabilities to the model.

| Old Workflow | MCP Workflow | |-------------------------------|---------------------------------------------------| | Paste a log into a chat | The model calls a read_logs tool | | Explain your repository | The client provides workspace context | | Paste command output | The server returns structured tool output | | Ask the model to guess state | The model asks the system for current state | | Manually perform every action | The model proposes or invokes approved tool calls |

MCP doesn't make a model omniscient. It gives the model a way to ask for context and use the actions you chose to expose. That matters more once you've lived through the manual context loop a few dozen times.

I'll Be Damned

ryan@tenthirtyam.org (Ryan Johnson) — Mon, 22 Jun 2026 00:00:00 +0000

!!! note "Reflection"

Some roads don't take you anywhere new; the ones that drag you back to what you can't forget. For me, that’s the haunted str...

Generating a Python SDK from an OpenAPI Specification

ryan@tenthirtyam.org (Ryan Johnson) — Sun, 21 Jun 2026 00:00:00 +0000

If your API ships an OpenAPI spec, OpenAPI Generator can build the Python client from it. You don't have to hand-write mode...

Making Sense of the Circle of Fifths

ryan@tenthirtyam.org (Ryan Johnson) — Sat, 20 Jun 2026 00:00:00 +0000

If the Circle of Fifths has always looked like one of those theory diagrams everyone swears is important but no one actually explains, you're not alone. The good news is that it's not really a chart about memorizing symbols. It's a map of how keys, chords, and musical motion relate to each other, and once you hear that on guitar, it starts feeling useful fast.

For a lot of players, the Circle of Fifths feels abstract because it gets introduced on paper instead of on the fretboard.

If my Decoding the Major and Minor Pentatonic Scales post was about understanding what's happening inside the pentatonic scale shapes, this one is about understanding why chords and keys pull the way they do around those scale shapes.

My goal here is to help you:

understand what the circle is actually showing you,
learn why moving by fifths sounds so strong in music,
connect nearby keys to nearby chord families, and
use the circle for progressions, songwriting, and practice.

!!! tip The Circle of Fifths isn't mainly about memorizing key signatures. It's about seeing which keys are closely related, which chords want to lead to each other, and why certain progressions feel so natural.

What Is the Circle of Fifths?

At its core, the Circle of Fifths is just an ordered list of notes.

Start on C. Move up a perfect fifth and you get G. Move up another fifth and you get D.

Keep going and you get:

C
G
D
A
E
B
F#
Db
Ab
Eb
Bb
F
back to C

That's the circle.

If you move the other direction, you're moving by fourths, which lands on the same set of keys in reverse order.

"Why does that matter?"

Because music built from neighboring keys tends to share a lot of notes and chords. The closer two keys are on the circle, the more naturally they tend to connect.

{ width="720" .skip-lightbox } { width="720" .skip-lightbox }

!!! note "Guitar Translation" Think of the circle as a map of musical neighborhoods. Keys that sit next to each other are closely related. Keys across the circle feel more distant.

Why Fifths Sound So Strong

The interval of a fifth is one of the most stable and powerful sounds in music.

Guitar players already know this sound, even if they don't call it by name:

A basic power chord is built around the Root Note and the 5.
Power chords put the sound of the fifth under your fingers all over the neck.
A lot of strong chord movement in rock, blues, country, and pop follows fifth relationships!

The motion around the circle lines up with one of the most fundamental relationships in the instrument and in tonal music itself.

!!! tip When you hear progressions like D - G - C or Em - Am - D - G, you're hearing the motion that lines up with the circle. And your ear recognizes that pull immediately.

Clockwise and Counterclockwise

One reason the circle matters is that it helps organize keys.

Moving clockwise:

goes up by fifths,
adds sharps, and
often feels like increasing harmonic brightness or tension

Moving counterclockwise:

goes up by fourths,
adds flats, and
often feels like a move toward warmer, flatter key areas

Here's a practical shorthand:

C has no sharps and no flats
one step clockwise, G, has 1 sharp
one more step, D, has 2 sharps
one step counterclockwise, F, has 1 flat
one more step, Bb, has 2 flats

!!! note "Stop! You Don't Need to Memorize All of This at Once!" Start with just C, G, D, A on the sharp side and C, F, Bb on the flat side. That small map already explains a huge amount of real guitar music.

Relative Minor

The Circle of Fifths isn't only about major keys. Each major key has a Relative Minor that uses the same notes.

Examples:

C major and A minor
G major and E minor
D major and B minor

If that sounds familiar, it should. It's the same relationship we used in Decoding the Major and Minor Pentatonic Scales.

The circle helps you see those pairs as families:

major key on the outside
relative minor connected to the same note pool

That's useful when:

understanding songs that shift between major and minor moods,
finding related scales quickly, and
writing chord progressions that feel connected without feeling repetitive

vmcli: A Practical Guide for the VMware Fusion and Workstation Command Line

ryan@tenthirtyam.org (Ryan Johnson) — Fri, 19 Jun 2026 00:00:00 +0000

The command line is still the fastest way to script power state, disks, snapshots, and guest operations on with VMware Fusion (macOS) and **VMware Workst...

Requests vs. HTTPX: Choosing a Python HTTP Client

ryan@tenthirtyam.org (Ryan Johnson) — Thu, 18 Jun 2026 00:00:00 +0000

requests earned its reputation honestly. For a long time, if you needed to call an API, download a file, or glue two services together in Python, requests was usually the obvious answer.

Async web frameworks, high-concurrency services, and I/O-heavy workloads changed what many teams need from an HTTP client. That's where httpx starts to matter.

This post compares requests and httpx from the point of view of a Python developer who already knows requests, wants a clear explanation of what httpx adds, and doesn't want hand-wavy "modernization" advice.

The Champion: `requests`

requests became the standard because it removed friction. Small API. Sensible defaults. Session when you need reuse.

The API is small and easy to learn.
The defaults are simple enough for scripts and internal tools.
Session gives you connection reuse and shared configuration without much ceremony.
The ecosystem around it is huge: tutorials, examples, blog posts, Stack Overflow answers, and third-party integrations all assume you know requests.

For synchronous Python code, it's still a good library. A lot of production code doesn't need async support, doesn't need HTTP/2, and doesn't need a broader transport model. In those cases, requests remains a sensible choice.

That's why this comparison is not really about replacing a bad tool. It's about recognizing where the older tool stops fitting as cleanly.

The Challenger: `httpx`

httpx looks familiar on purpose. The synchronous API feels close enough to requests that most Python developers can read it immediately. That compatibility is one of its best features, because it lowers the cost of trying it.

Its two biggest advantages are:

Native async and await support through httpx.AsyncClient
Optional HTTP/2 support on both sync and async clients

Those aren't cosmetic differences.

Async support means httpx fits naturally into frameworks like FastAPI, Starlette, and any other async application that should not block the event loop on outbound network calls. HTTP/2 support means one client connection can handle multiplexed requests when the remote server supports it, which can matter for high-concurrency workloads.

You opt in with httpx.Client(http2=True) or httpx.AsyncClient(http2=True), and the server still has to support HTTP/2 for you to get it.

httpx also pushes users toward safer networking defaults. The biggest example is timeouts: requests doesn't time out unless you ask it to, while httpx enforces timeouts by default.

Decoding the Major and Minor Pentatonic Scales

ryan@tenthirtyam.org (Ryan Johnson) — Sun, 14 Jun 2026 00:00:00 +0000

If you've ever felt trapped inside the classic minor pentatonic box, you're not alone. The good news is that the box isn't the problem. The real breakthrough comes when you understand what the notes inside that shape are doing, and that's the moment the fretboard starts making sense.

Most intermediate players start in the same place: Minor Pentatonic Position 1, fingers parked at the 5th fret, trying to find fresh ideas out of the same old lick. While that scale shape is useful, but it can start to feel a bit clostrophobic.

My goal with this post is to help you:

Stop seeing pentatonic scales as random patterns.
Start seeing them as intervals, Root Notes, and musical colors.
Learn why major and minor pentatonic scales are deeply connected.
Use that connection to make better phrases anywhere on the neck of the guitar.

!!! tip You don't need to memorize five more disconnected shapes to improve. You need to understand what your current shape is already showing you.

The word pentatonic just means five notes.

That's the whole idea:

A major scale has 7 notes.
A natural minor scale has 7 notes.
A pentatonic scale trims that down to 5.

Why remove two notes?

Because the notes that are left out are the ones that create the strongest half-step tension. Whilst half-steps aren't bad, they're the notes most likely to sound tense, crunchy, or like they want immediate resolution. When you remove them, the scale becomes smoother and more forgiving.

That's why pentatonic scales are awesome:

They're easy to hear.
They're easy to phrase.
They sit well over a range of chords.
They quickly sound musical, even before your theory knowledge is deep.

On the guitar, the pentatonic scales work so well because they remove some of the strongest tension notes from the full scale. You can still create emotion and movement, but you're less likely to land on a note that feels harsh or unresolved by accident.

!!! note "Why Pentatonics Feel So Friendly" By removing some of the most tension-heavy notes from the full 7-note scale, pentatonics give you a leaner set of notes that is easier to phrase with confidence. That's why they're often the first scale family guitar players truly learn to hear.

Hay for the Heifers

ryan@tenthirtyam.org (Ryan Johnson) — Thu, 11 Jun 2026 00:00:01 +0000

!!! note "Reflection"

Farm work looks noble from a distance, viewed through the softening lens of years gone by. But it was just sweat, salt, and t...

Nginx: A Practical Deep Dive

ryan@tenthirtyam.org (Ryan Johnson) — Thu, 11 Jun 2026 00:00:00 +0000

Nginx ends up in front of a surprising amount of web traffic. You might not think much about it until you have to troubleshoot a redirect loop, a broken certificate renewal, or an application that only fails once it sits behind a proxy.

Static sites, application servers, APIs, internal tools, container platforms, and CDN origins often have Nginx somewhere out front. People keep using it because it's fast, it's predictable, and it makes you declare what the server should do.

This guide walks through the part that matters in practice: what Nginx is good at, how its config model works, how to install it, how to serve a site, how to terminate TLS, how to replace .htaccess style behavior the Nginx way, and how to use it as a reverse proxy and a basic load balancer.

Nginx is a web server, reverse proxy, and load balancer. In a modern stack it usually does one or more of these jobs:

Serves static files directly.
Terminates HTTPS connections.
Redirects HTTP to HTTPS.
Proxies requests to application servers.
Balances traffic across multiple backend services.
Adds request and response headers.
Buffers slow clients away from backend applications.
Enforces simple access control rules.
Caches upstream responses when configured to do so.

It's especially good at static assets, reverse proxying, and a lot of concurrent connections. It also works well as the boring edge layer in front of applications written in Node.js, Python, Go, Ruby, PHP, Java, or anything else that can listen on a port.

The simplest mental model:

mermaid graph TD A[Client Browser] -->|HTTPS Request| B[Nginx] B -->|HTTP Request to Local App| C[Backend Application]

Nginx does not need to understand your application. It just needs to accept the request, apply the rules you gave it, and either serve the response or pass the request upstream.

Nginx became popular because it handles several common infrastructure problems without much drama:

It handles many concurrent connections efficiently.
It serves static files quickly.
It's excellent as a reverse proxy.
It's good at shielding backend apps from awkward client behavior.
It centralizes TLS, redirects, headers, and access control.
It can load balance traffic without a separate appliance.
Its configuration is explicit and reviewable.

Nginx expects configuration in known files, not hidden per-directory overrides inside the document root. That makes behavior easier to inspect, version, test, and deploy.

VMware Workstation and Fusion 26H1 Release

ryan@tenthirtyam.org (Ryan Johnson) — Sun, 07 Jun 2026 00:00:00 +0000

VMware Workstation Pro and Fusion Pro 26H1 shipped recently and was a fairly quiet release.

The biggest change in Workstation Pro 26H1 is the move to a ful...

How I'm Preparing for GH-600, GitHub's Agentic AI Developer Certification

ryan@tenthirtyam.org (Ryan Johnson) — Sat, 06 Jun 2026 00:00:00 +0000

{ align=right width=175 }

When I published Branching Out: GitHub Certification Path, GitHub had five certifications. That list is already out of date, and so is my own exam roadmap.

GitHub has now added a sixth exam: GH-600, GitHub Certified: Agentic AI Developer (beta). As of June 6, 2026, this one is still in beta, and it fills a different role than the existing Copilot certification. The Copilot exam is about using GitHub's AI tooling well. GH-600 is about building, operating, constraining, and evaluating agents inside real software delivery workflows.

I'm treating this post as my preparation plan for GH-600. These are the official materials, docs, and hands-on exercises I'm using to get ready for it.

GitHub is treating agentic AI as an engineering discipline: tool access, MCP configuration, execution boundaries, memory, observability, evaluation, and guardrails. That's the right frame for the technology, and it's the reason this exam is worth taking seriously.

Versioning Documentation with ProperDocs and mike

ryan@tenthirtyam.org (Ryan Johnson) — Fri, 05 Jun 2026 00:00:00 +0000

If you're using ProperDocs, versioned publishing should be straightforward. Build the docs for a release, publish them under a stable version label, and leave older versions alone. Until mike v2.2.0, that simple workflow still carried a nagging question: did the rest of the tooling really understand ProperDocs, or was it still assuming MkDocs under the hood?

mike publishes each supported release as its own directory tree on a deployment branch, usually gh-pages. Old versions stay put even when today's main branch moves on. In the mike v2.2.0 release, that process got simpler for ProperDocs users: when the properdocs package is installed, mike runs properdocs instead of mkdocs. No separate workflow branch. No wrapper script. No extra switch to remember.

The release notes include:

Add support for ProperDocs.

In practice, that means mike now checks for the properdocs package first. When it's present, mike uses the properdocs command and includes properdocs.yml and properdocs.yaml in its default configuration file search order.

That is exactly the kind of compatibility work you want in a documentation pipeline. Install the generator you actually use, install mike, and let tool detection do the boring part correctly.

ProperDocs exists because some teams need the MkDocs 1.x operating model to keep working. They have plugins, theme overrides, snippets, macros, and workflow assumptions built around that ecosystem. Versioned publishing shouldn't force those teams into a second set of build logic.

Before this change, the friction wasn't that versioned docs were impossible. The friction was that ProperDocs users had to think too much about whether the surrounding tooling still assumed MkDocs. That extra uncertainty is how CI jobs grow unnecessary conditionals and side paths.

With mike v2.2.0, the command flow is really simple:

bash python -m pip install "properdocs" "mike>=2.2.0" mike deploy 1.0 latest --push