Dispatches¶

Decoding the Major and Minor Pentatonic Scales

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.

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.

Hay for the Heifers

Nginx: A Practical Deep Dive

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:

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

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 fully 64-bit architecture on Windows. Operating systems and hardware moved on from 32-bit limitations a long time ago, but parts of Workstation's underlying components were still dragging legacy dependencies forward.

The 26H1 release finally drops them. Installers, services, libraries, and application binaries now operate entirely in a 64-bit environment. It's a cleanup that eliminates years of technical debt and gets out of the way of heavy edge-case workloads on the Windows side.

In 26H1, you can finally see when a virtual machine was created and when it was last powered on.

If you manage a handful of virtual machines, you probably won't care. If you manage dozens, or maintain a sprawling cybersecurity lab, this is a massive quality-of-life fix. It's significantly easier to find dormant lab machines without having to boot them or guess based on filesystem modification dates.

The most impactful part of 26H1 isn't technical. Since Workstation Pro and Fusion Pro are now free for personal, educational, and commercial use, the economics of local virtualization are completely different. You don't have to justify a license request or fall back to an open-source alternative with fewer features. You can just download the premier desktop hypervisor and run your lab.

The 26H1 release includes a typical collection of bug fixes and security updates to improve platform stability. When you rely on virtual machines as part of your daily workflow, predictable execution matters more than new knobs to turn.

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

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

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:

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

PowerShell Command Naming: Approved Verbs, Clear Nouns, and Better APIs

The difference between a PowerShell command that feels native and one that feels bolted on is often not the implementation. It's the name. In PowerShell, names are part of the interface contract: they drive discoverability, shape user expectations, and determine whether your module behaves like a first-class citizen or like a private script someone published by accident.

If you maintain PowerShell modules long enough, you start to see the same mistakes over and over:

• Functions named with verbs PowerShell doesn't recognize
• Plural nouns where PowerShell expects singular object names
• Verb choices that imply one behavior while the function performs another
• "Do everything" verbs like Invoke used as a substitute for design
• State-changing commands that don't support -WhatIf and -Confirm

This post is about avoiding those mistakes and building command names that feel idiomatic, predictable, and maintainable.

A bad command name spreads farther than you might expect. It shows up in documentation, examples, tab completion, issue reports, code review comments, CI logs, and muscle memory. Once users learn the wrong name, you either carry it forward forever or you break them later when you fix it.

PowerShell isn't just a shell. It's a command discovery environment. Users don't need to remember your entire module if your names fit the ecosystem. They can find commands through patterns:

Get-Command -Verb Get
Get-Command -Module My.Module
Get-Command -Noun VcfCluster
Get-Help Get-VcfCluster -Full
Get-Verb

That only works well when command names follow the conventions the engine, the help system, and the user all expect.

The best PowerShell command names are easy to guess. If I know your module has a cluster object, I should be able to guess that retrieval is probably Get-Thing, creation is probably New-Thing, mutation is probably Set-Thing, deletion is probably Remove-Thing, and validation is probably Test-Thing. If your module breaks that expectation, you increase the amount of documentation the user must read before they can do anything useful.

Seminole Clay

Maintainer Burnout in Open Source

Most of the internet runs on digital duct tape: small libraries, CLI tools, and frameworks held together by maintainers who never billed you for the install. Your CI pipeline, your container base image, and your app's transitive dependencies all assume someone will answer the issue, cut the release, and patch the CVE on a timeline that looks suspiciously like "when they have a free evening."

Maintainer burnout is what you get when that assumption keeps landing. It's not a bad week or a need for better time management. You still care about the project. You still know what a good fix looks like. You just can't get there anymore without paying a cost you didn't use to pay. The code might take twenty minutes. The replies take the rest of your life.

Why Maintainer Burnout Happens

The public story of open source is commits and stars. The private story is triage, judgment calls, release notes, duplicate issues, security advisories, and the careful tone you need when you close a thread in public. Reply-shaped debt piles up in that gap. That's where maintainers break.

Volume Without Staff

Growth rarely brings reviewers, security rotation, or funded operations. It brings more issues, more pull requests, more "quick questions," and more combinations you'll never reproduce on your laptop. A star is a bookmark for a user. For a maintainer, it's a rough guess at how many strangers will show up in your inbox next quarter.

Entitlement as Urgency

Many users interact with free software as if it were a paid product: instant fixes, roadmap influence, enterprise response times, and frustration when you say "not yet." You inherit on-call dread without an on-call team. Every open thread reads like it's due now. Only you know which ones can wait until Saturday and which ones turn into someone else's emergency if you don't move tonight.

Guides like Please Format Your Code Blocks and Writing Practical Contribution Guidelines exist because unclear intake isn't rudeness. It's unpaid labor you pay before the real work starts.

Value Created, Compensation Delayed (or Never)

Industry products ship on volunteer maintenance. Sponsorship logos are easier to obtain than guaranteed hours. Maintainers run a second shift after paid work, doing release engineering and community moderation for strangers while their own sleep debt compounds.

The industry takes a lot upstream and sends back gratitude, sometimes money, almost never enough hands on the work.

Isolation and Identity

Solo maintainers carry product, support, security, and governance in one GitHub avatar. When a co-maintainer changes jobs and stops reviewing, the bus factor becomes you. For many people, the project is also résumé, community, and the thing they're known for. Stepping back can feel like disappearing. Staying in can feel like you're drowning. Burnout sometimes looks like silence while you still watch the notification count, unable to reply and unable to walk away.

Audiences for Touring Broadway Shows are Exhausting

I have reached the point where I started to dread going to see touring Broadway productions, and it has absolutely nothing to do with the performers on stage.

The productions themselves are often excellent. The casts are talented. The orchestras are strong. The staging and technical production is impressive given the realities of moving a major show from city to city.

The problem is increasingly the audiences.

Over the last few years, I have noticed a steady decline in theater etiquette at touring productions. Not occasional distractions. Not the inevitable cough or dropped Playbill. No, I mean a constant stream of behavior that would have been considered unacceptable not very long ago.

For example, yesterday was Beauty and the Beast at the Fox Theatre in Atlanta. The Fox! People were still up and down all night, phones out the whole time. The woman in front of me had hers up maybe ninety-five percent of the show. Scrolling. Texting. I swear to God she was on the Applebee's website.

Earlier this year I saw Les Misérables in Fort Lauderdale. I traveled nine hours each way. Hadn't seen it in thirty years. I watched more people going back and forth to the bathroom than I watched the show.

That's not two bad nights, either. Phones stay out through half the show even after the announcements. Not a quick glance. More like someone at home half-watching Netflix while they scroll Instagram and wait on DoorDash. People talk at normal volume during scenes that matter. Whole rows get up two or three times in one act. Screens pop on because somebody needs to check a text or confirm what time it is. People rush out before the end like their team is losing and they're trying to beat traffic.

The part that gets me is most of them don't seem to notice they're ruining it for everyone around them.