Technology¶

How to Inspect Code in PyCharm and GoLand

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.

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.

Upload govulncheck Results to GitHub Code Scanning for Go

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.

Task: A Practical Guide to Cross-Platform Build Automation

make is still one of the most useful tools in a developer's toolbox, but a lot of modern repositories need something more portable, more readable, and easier to share between local development and CI. Task is a fast, cross-platform task runner that keeps the good part of a Makefile, one command for common project workflows, while replacing the rough edges with a YAML-based Taskfile.yml, built-in dependency orchestration, variables, templating, caching, and first-class behavior on Windows, macOS, and Linux.

Field Dispatch: The First ESX Host Drifts from Custom Certificates After VMware Cloud Foundation 9 Instance Bring-Up

If you're using securitySpec to deploy VMware Cloud Foundation 9.x with external CA-signed ESX certificates, the bring-up can look successful while still leaving you with one surprise:

I ran into this while testing external CA-signed certificates through both the API and Ansible. The JSON payload was accepted, the instance bring-up completed, the ESX hosts retained their external CA-signed certificates except for first ESX host, the one used during the bootstrap for the vCenter appliance.

Tip: Using the GitHub CLI to Copy Labels Between Repositories

If gh is not installed yet, install it first:

brew install gh

sudo apt update && sudo apt install -y gh

# RHEL
sudo dnf install -y dnf-plugins-core
sudo dnf config-manager --add-repo https://cli.github.com/packages/rpm/gh-cli.repo
sudo dnf install -y gh

# Fedora
sudo dnf install -y gh

winget install GitHub.cli

Then authenticate:

gh auth login
gh auth status

That second command is worth running. It confirms that your session is active before you try to modify repository settings.

Clone Labels into the Current Repository

If you are already in the destination repository directory, the command is simple:

gh label clone OWNER/SOURCE-REPO

Example:

gh label clone tenthirtyam/example

That copies every label from tenthirtyam/example into the current repository.

Target a Different Destination Repository

If you are not inside the destination repository, use --repo:

gh label clone OWNER/SOURCE-REPO --repo OWNER/DESTINATION-REPO

Example:

gh label clone tenthirtyam/source-example --repo tenthirtyam/destination-example

Ubuntu 26.04: How to Upgrade from 24.04 LTS

Ubuntu 26.04 LTS, Resolute Raccoon, was officially released on April 23, 2026.

If you're like me and want to upgrade now, here's a clean step-by-step process to do it on both Ubuntu Desktop and Ubuntu Server.

Before the Upgrade

Before you begin the upgrade, review the following checklist.

1. Back up anything you care about.
2. If the system is a VM, take a snapshot.
3. Make sure the current 24.04 LTS install is fully patched.
4. Make sure you have enough free disk space.
5. Be prepared to answer interactive prompts during the upgrade.

On Ubuntu Server, I would also review any third-party repositories or PPAs before you start. They are a common source of upgrade friction, and Ubuntu may disable them during the release upgrade anyway.

Update the current system first:

sudo apt update
sudo apt dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true
sudo reboot

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.