Technology¶

Maintain Formatting of Embedded Terraform Provider Examples with terrafmt

When a Terraform provider repository ships Markdown documentation full of example configuration, those snippets are part of the product. If they drift out of style, or worse, stop parsing as valid HCL, users feel it immediately. terrafmt is a small tool that helps keep embedded Terraform examples formatted and syntactically correct in both local workflows and CI.

terrafmt scans files for embedded Terraform configuration, extracts the matching blocks, parses the HCL, formats it, and then either shows the diff or rewrites the file in place. It recognizes embedded configuration in a few very practical forms:

• Markdown documentation files with fenced hcl, terraform, or tf blocks
• Go source files that return raw strings
• Go source files that build examples with fmt.Sprintf(...)

In other words, terrafmt is a bridge between "this is documentation" and "this is still code."

Linux Commands Reference: Essential CLI Categories for Daily Work

The Linux command line is one of those skills that keeps compounding. Once you can inspect a system, trace a process, move data safely, and answer your own questions from a shell prompt, you stop waiting on GUIs and start working at the speed of the machine. This reference gathers 15 essential command categories into one practical page you can keep nearby, whether you are building confidence or sharpening the habits that make day-to-day operations smoother.

This is not meant to be a memorize-everything-in-one-sitting tutorial. It is a working reference positioned between beginner comfort and intermediate fluency, with a handful of deeper operational workflows where extra context matters most.

Inside My VS Code Setup: Theme, Extensions, and Settings

If you spend hours a day in your editor, your setup stops being a cosmetic preference and starts becoming part of how you think. Mine has evolved into a very opinionated VS Code environment tuned for the work I do most often: Go, Python, PowerShell, Ansible, Terraform, Markdown, YAML, JSON, and a steady stream of GitHub-driven automation.

Earlier this month, I wrote about why I use JetBrains GoLand and PyCharm over VS Code for some language-specific work. That's still true. But VS Code remains one of the most useful tools on my machine because it is fast, flexible, and easy to shape around the task in front of me.

This post is a tour of the setup I keep coming back to, the one that feels like home every time I open VS Code.

How to Write Effective GitHub Issue Templates

A pull request template improves the quality of proposed changes, but it only helps after someone has already made it to the solution stage. GitHub issue forms solve the earlier problem: they shape the information you collect when someone reports a bug, asks for an enhancement, or suggests a documentation fix. In that sense, they're the natural companion to a pull request template, and for many repositories they do even more to reduce maintainer back-and-forth.

While my previous post, How to Write an Effective GitHub Pull Request Template, was about improving review, this post is about improving intake.

• Pull request templates help contributors explain a proposed change.
• Issue template help contributors explain a problem, an idea, or a gap before any code has been written.

That distinction matters, because most maintainer time is lost much earlier in the process: missing reproduction steps, missing environment details, vague enhancement requests, and documentation issues with no concrete suggestion.

How to Write an Effective Security Policy for GitHub Repositories

A repository security policy is one of those documents that people often add because GitHub expects it, not because they have thought through what it needs to do. That is how you end up with policies that say little more than "email us if you find a problem" or, worse, tell researchers to open a public issue for a vulnerability report. An effective security policy is not a box-checking exercise. It is an operational document: it tells security researchers how to contact you safely, tells users which versions you still support, and tells everyone what kind of response process they can reasonably expect.

This post walks through how to write a security policy that is actually useful on GitHub: what sections it needs, how specific to be, which mistakes to avoid, and a practical SECURITY.md template you can adapt for your own repositories. The goal is not just to help you publish the file, but to help you publish one that will still read as clear, credible, and operational when someone actually needs it.