Skip to content

Dispatches

How to Use GitHub Projects Effectively

Most engineering teams still plan work in one tool and ship it in another. Issues live in Jira or Trello, pull requests live in GitHub, and every status change requires a human to copy context across tabs. GitHub Projects removes much of that friction by keeping planning, issue tracking, and delivery close to the code.

Current GitHub Projects is the planning layer on top of issues and pull requests: custom fields, saved views, built-in automations, roadmaps, charts, and API access. It replaces Projects (classic), not the same product with a new coat of paint.

For teams that already live in GitHub, the value is straightforward:

  • Less context switching between a tracker and the code host
  • Fewer stale status updates because issue and pull request state can drive project state
  • One place to plan cross-repository work without losing repository-level detail
  • A workflow that works for a two-person open source project, an inner source program, or a larger engineering org

Not Projects (classic)

This guide covers the current GitHub Projects experience. If you're starting fresh, use the new Projects workflow, not classic boards.

Keeping GitHub Repository Mirrors in Sync with GitHub Actions

Mirroring a Git repository sounds simple until you need it to stay current without thinking about it. A one-time copy is easy. The useful version is a mirror that keeps following upstream branches, tags, and rewritten history without becoming another chore on your list.

I use this pattern for repositories I want to preserve, test against, or keep available under my own GitHub namespace. A recent r/github threasd asked about mirroring a public repository into a private one; this is the workflow I use for that and similar cases.

The twist is that I don't put the sync workflow in each destination repository. I keep the automation in a standalone private repository that acts as a mirror controller.

Before getting to GitHub Actions, it helps to understand the manual Git operation the workflow is automating.

Why Mirror a Repository?

A mirror is useful when you want a repository to follow another repository as closely as possible. That is different from a normal fork, where you expect to create your own branches, open pull requests, and maintain local work.

I usually think about mirrors as infrastructure, not collaboration space. They are useful for:

  • Keeping a personal copy of an upstream project
  • Preserving access to a dependency you rely on
  • Testing automation against a repository under your own namespace
  • Keeping several upstream repositories available from one GitHub account or organization
  • Avoiding a manual Sync fork habit for repositories that should simply track upstream

That last point is the practical one. If the destination is supposed to reflect upstream, humans should not be the scheduler.

Treat Mirrors as Destructive Targets

A mirror destination should not contain independent work. Mirroring usually involves forced updates to branches and tags, which means local-only changes in the destination can be overwritten. Use dedicated mirror repositories, not repositories where people are actively developing.

Papa was a Pepper

Reflection

My Grandaddy was a tough, stubborn, but gentle man who didn't touch beer or liquor, but he worked that South Georgia clay with a furious, sugar-fueled sweat.

He left empty Dr Pepper bottles everywhere. Stacked high under the pole barns, rattling in the bed of his truck, and wedged into the rusty frame of a Massey tractor from the last mow of the pasture.

Whenever the barns got totally full, my brother and I would help him load up the trailer and haul that glass down to the back forty. It was a place we rarely dared to go alone, but there we'd dump them into a hidden ravine where the sun couldn't reach, watching those old styrofoam sleeves peel away from the glass like sunburned skin. They just added to a jagged mountain of thousands of empties resting deep in the damp pine needles.

When the wind came up through those trees, it would blow right across the open bottle necks, making the back woods groan with a heavy, whistling breath.

Lyrics

PAPA WAS A PEPPER

I grew up on a patch of that South Georgia red
Following the dust and the things Grandaddy said
Checking the rows in his ole fedora hat
Turning that clay, yeah, he had it down flat
He had cattle in the field, peanuts knee-high
A cane pole waiting when the sun fell in the sky
Working six days, but he never touched a beer
He had a different kind of cooler in the truck all year

He was stubborn as a mule, hard-headed and tough
But he had a sweet tooth for the fizzy stuff
Didn’t need the whiskey, didn't need the wine
He just needed 23 flavors at a time

     Papa was a Pepper
     Lord, he drank ‘em by the case
     Little glass bottles all over the place
     In the barn, in the truck, by the back forty trees
     Stacking up mountains of memories
     If hard work has a flavor, man, you better believe
     It tastes like the doctor to me
     Yeah, Papa was a Pepper

We’d load up the trailer with the empty glass
Styrofoam sleeves blowing in the grass
He hit 93 and he never slowed down
The toughest old man in this whole damn town
Granny said, “Drink Water,” Papa just laughed
Said, “That’s for the catfish, mama don't be daft!”
He’d crack a cold one and he’d give me a wink
Yeah “Life’s too short for a boring old drink!”

     Repeat Chorus

Now the house sits quiet and the garden’s overgrown
But I still feel him when I’m driving back home
He didn’t leave a fortune, didn't leave gold
Just a mountain of stories that’ll never get old

Papa was a Pepper
And I still raise one now and then
To the farmer, the fisherman, my best friend
Yeah, life goes down a little smoother, you see
When you got a little sugar and a family tree
Every time I crack one, man, you better believe
Papa’s right here with me
Yeah, Papa was a Pepper

Writer: J. Ryan Johnson (BMI)
Copyright: © 2026 J. Ryan Johnson. All rights reserved.
Phone: +1 (407) 902-5419
Email: hello [at] tenthirtyam [dot] org

Audio Disclaimer

Lyrics: Original | Audio: AI-Generated

I am a songwriter and a musician, but I am not the voice meant to inhabit these verses.

I've used AI to bridge the gap for the concept demos, crafted to serve as blueprints that capture the genre, tone, and weary soul I hear for each song.

They exist as an invitation, offered in the hope that these lyrics will eventually reach the hands of an artist and storyteller who can bring them fully into the light.

Until then, they remain as they were born: quiet reflections on the grit and grace found just north of the county line.

Beautiful, Structured Logs for Go CLIs with charmbracelet/log

VHS

If most of the logs from your Go CLI still look like a wall of monochrome timestamps and free-form strings, you're leaving a lot of developer experience on the table. Charm's log package gives you colorful, readable, structured terminal output without forcing you into a heavyweight API or a machine-first JSON mindset from the start.

There's nothing wrong with simple logging. The problem is that simple logging tends to stay simple long after your application stops being simple.

At first, a few log.Println calls feel harmless. Then the output gets noisy. Errors look almost the same as info messages. Request context gets squeezed into ad hoc strings. The one line you need is somewhere in the middle of a hundred identical timestamps, and your terminal gives you very little help separating signal from noise.

That's the gap charmbracelet/log tries to fill. It's a leveled, structured, human-readable logger built for terminals. It looks good out of the box, keeps the API small, and still gives you the structured fields and formatting controls you want for real projects.

The Fine Art of a Minimal Reproducible Example

Two hours in, what you're actually shipping is a GitHub issue, a JIRA ticket, or a Slack thread: symptoms, hunches, pasted logs, then one more file because someone asked nicely. Each round trip tugs another detail out of your repo while the runnable version still lives mostly on your machine. Then a follow-up makes you spell out the repro steps you sort of skipped the first time, and halfway through your reply the bug stops looking fuzzy. Nobody merged a fix for you. You just finally described it clearly enough to see it yourself.

That loop is about as expensive as debugging gets, and almost none of it is mandatory. The antidote is the minimal reproducible example (MRE): the smallest, most self-contained piece of code that reliably triggers the problem you're trying to explain. Being kind to whoever reads your ticket is a nice side effect. The main payoff is that your own picture of the break gets sharper. Most of the time you'll see the answer yourself before you hit send.

Bulk Delete GitHub Deployments

Repositories that ship often, especially to GitHub Pages or similar environments, can rack up a long list of deployments. The UI is fine for spot checks, but it doesn't give you a fast way to clear old rows when you only care about what is current. The REST API deletes one deployment per request, so the practical approach is the same as workflow run cleanup: loop with the GitHub CLI (gh).

This post starts with a loop that deletes deployments whose latest status is inactive, then adds a variant that also removes error and failure without touching rows that still end in success.

T.J.

Reflection

The post T.J. Came Running is a reflection on that afternoon on my Grandaddy's land and the silence that followed. This song took shape in late 2025, decades after that day, when the grief I still hold had to move through rhyme and meter.

Lyrics

T.J.

The bus brakes hissed on the county tar
Granny sat waiting in that idling car
A '78 Olds, painted midnight blue
Smelling like dust and dried morning dew
We tossed our bags on the back seat
And left downtown for the red-dirt heat
Just an afternoon ride, back to the farm
Before we knew that Granny could do so much harm

     You can pound on the glass till your knuckles go numb
     But the rubber don't care where the power comes from
     He was running on trust, just beating the air
     While she stared at the road like there was nobody there
     It’s a hell of a thing in the rearview pane
     To see heavy blue steel leave a red dirt stain

Crossed the cattle gap, and the suspension groaned
Entering the land that my grandaddy owned
T.J. came running down the long dirt track
With his ears flopped forward and then flying back
Just a happy fat beagle, brown and white
The softest thing running in the afternoon light
He thought he was greeting a friend at the gate
Not a two-ton machine marking his fate

     Repeat Chorus

The thump wasn’t loud, but it shook the frame
And the silence that followed didn't have a name
I looked out the back as the dust settled down
At a patch of red and brown on the clay ground
He was wide open on the homestead road
As I fell next to him

The thump wasn’t loud, but it shook the frame
And the silence that followed didn't have a name
I looked out the back as the dust settled down
At a patch of red and brown on the clay ground
He was wide open on the homestead road
As I fell next to him, under the load
The boy I was died right there in the grit
When the tires kept turning and my world just split

Grandaddy came out with a spade in his hand
Moving like a ghost across the bottomland
He didn't ask questions, he saw what she’d done
Just wiped his forehead in the sinking sun
We buried him deep where the tree line starts
With the sound of that Olds still revving in our hearts
I learned right then what I couldn't unlearn
That the people you love don’t always turn

I stood by the hole
Granddad handled the spade
The dog was broken
Two lives unmade
She went in the kitchen
And the red dirt dried
And a part of me stayed
Where a little soul died

Writer: J. Ryan Johnson (BMI)
Copyright: © 2026 J. Ryan Johnson. All rights reserved.
Phone: +1 (407) 902-5419
Email: hello [at] tenthirtyam [dot] org

Audio Disclaimer

Lyrics: Original | Audio: AI-Generated

I am a songwriter and a musician, but I am not the voice meant to inhabit these verses.

I've used AI to bridge the gap for the concept demos, crafted to serve as blueprints that capture the genre, tone, and weary soul I hear for each song.

They exist as an invitation, offered in the hope that these lyrics will eventually reach the hands of an artist and storyteller who can bring them fully into the light.

Until then, they remain as they were born: quiet reflections on the grit and grace found just north of the county line.

Setting up RDP on Ubuntu 26.04 LTS

I still use RDP when I want a remote desktop on another machine. On Ubuntu 26.04 LTS Desktop (Resolute Raccoon, April 2026) the built-in path is Settings → System → Remote Desktop, matching what Canonical has documented since 24.04.

The steps below walk through the toggles, ufw, and how to connect with a client.

Procedure

Open Remote Desktop in Settings

  1. Open Settings.
  2. Navigate to System.

  3. Open Remote Desktop.

    Tip

    If you don't see it, click the search control at the top of Settings, type remote, and open the match under System.

    Settings System List with Remote Desktop

Select and Enable a Connection Method

You'll see two tabs that aren't interchangeable.

  • Desktop Sharing: View or control the desktop while you're logged in. Someone joins your live session. Resolution follows your local session, so the client can look a little soft.

  • Remote Login: Connect when the account isn't in use, closer to a headless workstation login. Resolution follows the client window, so it tends to look sharp. If you're already logged in locally, a remote user may get offered the nuclear option to end your session.

    Tip

    Generally, I use the Remote Login method.

  • Select the tab for the path you want.

  • Turn on the main toggle at the top of that tab.

    Tip

    You may need to click Unlock and enter your password before the toggle will stick.

Fast Local Checks, Trusted CI: Pre-commit and GitHub Actions for Go

For small Go projects, it's easy to tell yourself that gofmt, go mod tidy, and golangci-lint are habits, not policy. That usually works right up until a pull request fails because generated files changed, go.sum drifted, or a formatter was only run on one laptop.

The pattern I keep coming back to is simple: define the validation contract once, usually in a Makefile or Taskfile.yml, then let pre-commit provide fast local feedback and GitHub Actions enforce the same expectations for everyone else. Local hooks keep the loop short. CI keeps the rules shared, visible, and hard to accidentally bypass.

This isn't the only way to validate a Go repository, and it isn't always necessary. But for Go projects with generated code, multiple contributors, or public pull requests, it's a very practical baseline.

Dependabot vs. Renovate: Dependency Management on GitHub

Dependabot vs. Renovate Dependabot vs. Renovate

Dependency updates are easy to picture one repo at a time. They get political fast when the count is hundreds or thousands: security response, CI minutes, reviewer attention, repo standards, and how much supply-chain theater your org is willing to run.

Most organizations and users will start with Dependabot on GitHub. It's an obvious choice: first-party, no extra service to stand up. Plenty of teams still reach for Renovate when policy, monorepos, or odd manifests stop fitting Dependabot's mold.

Blunt matrix:

Capability Dependabot Renovate
GitHub integration First-party, tight dependency graph and advisory wiring Strong GitHub support, but you run it as an app, Action, or your own worker
Configuration model Simple repository-local YAML Layered policy model with presets and package rules
Custom dependency extraction Limited to supported ecosystems Strong, especially with custom regex managers
Monorepo handling Good for straightforward layouts Better for large, mixed, policy-heavy monorepos
Pull request grouping Useful but bounded Very granular by manager, package, path, dependency type, and update type
Automerge policy Usually implemented with GitHub Actions and branch protection First-class Renovate policy, still gated by GitHub rules
Security updates Best native GitHub Advisory Database integration More programmable, but integration depends on deployment model
Fleet-scale operations Low operational burden, fewer controls More operational burden, much more control