Technology¶

EditorConfig Deep Dive: Syntax, Properties, and Best Practices

Every shared repository eventually rediscovers the same avoidable argument: tabs or spaces, LF or CRLF, trim trailing whitespace or leave it alone, final newline or not. None of these questions are hard. They are just repetitive, noisy, and surprisingly good at wasting review time.

EditorConfig exists to move those decisions out of personal editor settings and into the repository itself. It is a simple, cross-editor standard for defining basic text file formatting rules so contributors using different editors and IDEs still save files in a consistent way.

This matters more than style bikeshedding. Inconsistent indentation creates ugly diffs. Inconsistent line endings break shell scripts and CI jobs. Trailing whitespace produces review noise that hides the change you actually care about. EditorConfig is not glamorous, but it solves a class of problems that should stay boring.

This guide covers how EditorConfig works, the syntax of .editorconfig files, the standard properties you can rely on, where editor support stands, and how to build a practical starter template for a modern repository.

Linux Kernel Sets Rules for AI-Generated Code

AI coding assistants were always going to force this conversation eventually. Tools like Copilot, ChatGPT, and Claude can draft code quickly, explain unfamiliar sections, and help contributors move through a patch faster than they could on their own. That is useful. It is also exactly the kind of shift that was bound to run into the Linux kernel's standards around trust, review, authorship, and licensing.

The kernel is not a project where code gets merged because it looks plausible. It is a project where contributors are expected to understand what they send, defend it under review, and stand behind it legally and technically. That is what makes the new guidance on AI-generated and tool-generated contributions worth paying attention to.

Use 1Password SSH Agent for SSH Keys and Git

If you already trust 1Password with API keys, database passwords, and tokens, your SSH keys are the next obvious secret to get out of ~/.ssh/. The 1Password SSH agent lets OpenSSH and Git use keys stored in your vault instead of private key files on disk, which makes day-to-day Git authentication cleaner without turning your home directory into a small museum of long-lived keys.

The important nuance is this: the op CLI is part of the workflow, but the actual SSH agent is provided by the 1Password desktop app. That matters because it keeps the model honest:

• 1Password stores the private key item
• The desktop app brokers SSH authentication
• OpenSSH talks to the 1Password agent
• Git keeps using SSH exactly the way it always has

If you are already using 1Password for local development secrets, this is the same idea applied to Git access. The application code stays boring, the SSH client stays boring, and the secret moves into the vault where it belongs. If your main goal is application secrets rather than Git access, the companion post is Use 1Password CLI for Local Development.

Use 1Password CLI for Local Development

If your local development workflow still depends on .env files full of live credentials, you are not doing configuration management, you are just normalizing secret sprawl. The 1Password CLI, op, gives you a better model: keep secrets in a vault, inject them into a child process only when needed, and let your terminal stay fast without turning your laptop into a plaintext key dump.

This post is intentionally about local development only. No CI runners, no GitHub Actions, no Kubernetes side quests. Just a developer workstation, a terminal, and a sane way to run Python, Go, PowerShell, Zsh, and Bash without leaving credentials all over the filesystem.

After MkDocs 1.x: Fragmentation, Risk, and What Comes Next

For more than a decade, MkDocs, especially when paired with Material for MkDocs, became the default answer for engineering documentation. It was simple enough for technical writers, familiar to Python-centric platform teams, and polished enough that most organizations never needed to build a documentation frontend of their own. That consensus has now fractured. As of 2026, teams still running MkDocs 1.x are no longer just choosing a mature stack, they're accepting a growing maintenance, compatibility, and software supply chain risk.

MkDocs earned its position because it solved the right problem at the right level of complexity. It gave teams a straightforward content model, a single configuration file, a Python packaging story that fit naturally into existing developer environments, and a clean separation between content, theme, and deployment. Material for MkDocs then raised the ceiling dramatically. Search, dark mode, responsive navigation, blog support, admonitions, tabs, code annotations, and a broad plugin ecosystem turned what began as a documentation generator into a complete publishing stack.

For engineering organizations, that combination was unusually efficient:

• Technical writers could stay in Markdown.
• Engineers could treat docs like any other Git-based project.
• Platform teams could build and deploy sites with the same CI pipelines used elsewhere.
• Open-source programs could publish polished public documentation without standing up a custom app.

In practice, MkDocs plus Material became the reference architecture for documentation in many Python-centric and infrastructure-heavy teams. It wasn't the only option, but it was often the least controversial one.

A Quick HAProxy Load Balancer for VMware Cloud Foundation Operations

When I need to stand up a quick load balancer for VMware Cloud Foundation Operations in the lab, I don't want to rebuild the same HAProxy configuration by hand every time. I just want a small Debian or Ubuntu VM, a VIP on the right VLAN, a backend pool of appliance nodes, and a fast path to getting the service online.

This helper script is what I use for that job. It prompts for the virtual IP, netmask, redirect FQDN, and backend node IPs, then wires up the network interface, installs HAProxy, generates a fresh configuration, and restarts the required services. It is intentionally opinionated, which is exactly why it's useful in a home lab.

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."

Field Dispatch: Increase the ESX Certificate Key Size in VMware Cloud Foundation 9.0

In VMware Cloud Foundation 9, the certificate workflow in VMware Cloud Foundation Operations ("VCF Operations") can make ESX certificate replacement look more constrained than it is.

When generating a CSR for an ESX host, the interface may show 2048 as the only RSA key size available. In an environment where server certificates must use 3072 or 4096 bit keys, that can look like a mismatch between the platform and the security baseline.

The important detail is where the CSR gets its key size. For ESX hosts, CSR generation can use the host's advanced certificate key size setting, even when VCF Operations only displays 2048.

So the question is not only what the dialog shows. It is what the ESX host is configured to use when the CSR is created.

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.