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.
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
This song isn’t a true history, but it is rooted in a true place and the kind of hunger that only bites when you’re young, reckless, and willing to work.
My brother and I spent our summers hauling watermelons and cantaloupes off our Granddaddy’s farm, stacking them into a trailer hitched to an old Massey that had seen better decades. We’d sit for hours on the shoulder of the road under a hand-painted sign, watching the heat shimmer off the asphalt and dreaming the day away once the heavy lifting was done.
There was a jagged kind of freedom in those afternoons. It was the independence of cash in a pocket and the quiet pride of having something the world actually wanted during in the middle of a long, hot day.
This song takes that truth and stretches it until it’s a little more dangerous, landing somewhere in the haze between a memory and a myth. It’s a nod to a specific kind of freedom that you have to earn with your hands and a tribute to South Georgia in July, where the humidity makes the world feel like it’s liquefying around you and you’re just trying to white-knuckle the things that keep you moving.
Lyrics
OUT ON HIGHWAY 84
Asphalt’s bleeding tar, summer of ‘94 Crossed the dry county line on highway 84 Air’s thick as molasses, smell of diesel and pine I’m perched on this tailgate, just killing off time
Got a hand-painted sign saying "Sweetest in the State" Two bucks a sugar-baby, 'fore it’s too late Cicadas are screaming like a choir in the heat While that South Georgia sun bakes the soles of my feet
It’s the Fourth of July and the blacktop’s steaming Heat off the hood has the whole highway dreaming Got a bed full of melons, green gold and deep red And a jar of lightning to keep my soul fed Let the law keep rolling, let the flags fly high Trading in sugar ‘neath the South Georgia sky
A man in a Caddy rolled through the grit Kicking up the gravel like it owes him rent I spat a black seed, looked him dead in the eye Said, "The dirt gave me fruit; the Lord gave me sky" He bought a thirty-pounder and left in a swirl Of red clay and gravel at the edge of the world
Repeat Chorus
Radio static or a preacher with the news Talking ‘bout the Lord, get your asses in the pews Deputy rolling, eyeballing the scene Tip my tattered hat, Lord my record ain’t clean
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.
Most terminal emulators ask you to make peace with an awkward tradeoff. You can have something fast but austere, polished but slow, powerful but painfully non-native. Ghostty, created by Mitchell Hashimoto, is interesting because it doesn't merely try to improve one side of that triangle. It tries to make the tradeoff smaller. The result is a terminal that is GPU-accelerated, deeply configurable, standards-aware, and designed to feel like a first-class citizen on the platform it runs on.
At the highest level, Ghostty is a modern terminal emulator for macOS and Linux. That sounds ordinary right up until you look at how it positions itself. The project is explicitly built around three goals:
Fast
Feature-rich
Native
The third goal is where the project gets interesting.
There are plenty of fast terminals. There are plenty of featureful terminals. There are also terminals that feel at home on a specific operating system. Very few try to be genuinely strong in all three categories at once, because that is much harder than slapping a fast renderer on a cross-platform UI toolkit and calling it a day.
Ghostty takes the harder path. On macOS, it uses real Apple frameworks. On Linux, it integrates with GTK4 and the surrounding desktop environment. Underneath those platform-specific shells is a shared Zig core that handles terminal emulation, rendering, and the heavy lifting that makes Ghostty feel so absurdly responsive.
If you spend a good chunk of your day in a shell, an editor, a multiplexer, or a remote session, that combination matters more than it may seem on paper.
Issues and pull requests accumulate quickly on any active project. Without structure, a repository becomes a flat list of work with no clear sense of what belongs together, what's blocking a release, or how close you're to shipping. Milestones give that structure: lightweight containers that define the payload of a release, track progress automatically, and surface what remains without requiring a separate project board or external tool.
This post covers how milestones work, how to name and manage them, how to operate them through the UI, the GitHub CLI, and the REST API, and how to automate the tedious parts with GitHub Actions. It's opinionated: these are the practices that work in production open source repositories, not a neutral survey of every option.
A milestone is a named container attached to a repository. It holds issues and pull requests, carries an optional description and due date, and displays a live progress bar computed from the ratio of closed to total items. Nothing more. That simplicity is the point.
Most developers first encounter JetBrains code inspections as red underlines and yellow warnings inside the editor. That live feedback is the same inspection engine behind Problems, batch runs, and shared profiles, even when the UI says "problem" in places. It's useful, but it isn't the real power move. Instead, learn how to run a deliberate inspection pass across a file, package, module, or whole project before you commit your changes and open a pull request.
That workflow lives in Problems, Project Errors, Code | Inspect Code, scope selection, and inspection profiles. Once you start using this, PyCharm and GoLand stop being fancy editors and become a code quality gate.
Applies Across JetBrains IDEs
My focus here is on PyCharm and GoLand because they're the tools I use most. The same inspection model also shows up across other JetBrains IDEs, though the exact inspection groups, plugins, and file-type support will vary by product and project setup.
By the time a problem reaches CI/CD, you've already paid the context-switch tax:
You wrote the code.
You staged it.
You pushed it.
You waited for the pipeline.
You reopened the work.
By contrast, when PyCharm or GoLand finds the issue locally, you can usually fix it while the code is still fresh in your head.
That's the value of leaning on inspections end to end. The IDE isn't only marking mistakes in the current file as you type. It can also run structured inspection passes against broader scopes of code and show you the results in one place, grouped, triaged, and ready to fix.
For a lot of Python and Go developers, that second part is the missing piece.
It also does something more subtle over time: It teaches you patterns.
If you keep paying attention to the same warnings, quick fixes, and inspection results, you start to internalize better habits before the IDE has to remind you.
If you already use GitHub security features for Go, it is tempting to assume CodeQL and Dependabot cover everything you need. They do not fully replace govulncheck.
For Go projects, govulncheck adds a very useful layer: it understands the Go vulnerability database and uses package and call graph information to reduce noise. That means it can help answer a more practical question than "is this module version mentioned in an advisory?" It can help answer "does this vulnerability affect code my project actually uses?"
That is enough of a difference that I think govulncheck is worth surfacing directly in GitHub code scanning, not just running as an isolated terminal command or a one-off CI step.
Namiko Akoi Miller April 01, 1932–September 01, 1993
Reflection
Few things are as still as a South Georgia library in the dead of summer. The air inside is thick with the scent of old paper and the hum of a laboring compressor, while the dust drifts through shafts of light.
Namiko Akoi Miller was the steward of that stillness. As the librarian of Seminole County Public Library, she was a quiet mercy in a landscape that didn’t always know how to hold a gentle thing. To a child fleeing the white-hot sun or a restless home, she offered up worlds bound in glue and buckram. She would press her stamp to the page; a small ritual of safe passage.
The quiet didn't just end; it tore. I was a junior in high school when the town’s fragile veneer of safety was once again peeled back, exposing the old shadows underneath. We learned then what we’ve known ever since: you don't ever truly outrun the way violence hollows out a small place.
This song isn't about her murder. It's about the grace of a woman in a house of stories, and the way that grace continues to haunt the pine curtains and the red clay, long after the sanctuary was breached.
Lyrics
NAMIKO
A freight train’s echo, water tower in the air Dust on the hardbacks, sunlight on the stairs She knew every title and she knew every face Keeping the peace in a small-town place
Faded ink on the due dates, a pocket full of prayers A quiet kind of calling, an empty wooden chair
And it ain’t the books that haunt that room at night It’s the lamp still burning in the borrowed light Where the stories always ended the way you hoped they would A chapter closed in Seminole like no one thought it could
Kids came in laughing, sun-drenched, summer-sweet A note in the margins, a squeak in the seat She’d say “Take your time,” ‘cause time was on our side Now the doors lock early and the town stays inside
Repeat Pre-chorus
Repeat Chorus
There were ghosts in the aisles long before she was gone Seeking shade from the heat of a red Georgia dawn. She’d stamp the cards gently, she’d ask how you’ve been A shelter from the weather and the trouble you're in
I won’t sing of shadow, I won’t sing of blood I’ll sing her name like a hymn in the flood I’ll sing the way she handed hope across a desk The simple, honest kindness that we easily attest
No, it ain’t the books that haunt that room at night It’s the love she left there in the borrowed light Let the pages hold her, let the pine wind tell Somebody keep the quiet, somebody keep it well
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.
