Of course there are replacement apps that handle a lot of this out of the box, but from iTerm to Ghostty and others, they always fall short for me in one way or another. So I stick with Terminal, and honestly, it works really well, minus the pane support. tmux fixes that, but it also overrides so much native Terminal functionality that other basic behavior can break, like clicking a URL.

With a little bit of configuration in ~/.tmux.conf though, you can restore the ability to open links with a right-click. Below is the config to do just that.

setw -g mouse on
set -g word-separators " \t\n"
bind -n MouseDown3Pane select-pane -t= \; copy-mode -M \; send-keys -X select-word \; send-keys -X copy-pipe-and-cancel "sh -c 'read -r url; case \"\$url\" in http://*|https://*) open \"\$url\";; esac'"
bind -T copy-mode-vi    MouseDown3Pane send-keys -X select-word \; send-keys -X copy-pipe-and-cancel "sh -c 'read -r url; case \"\$url\" in http://*|https://*) open \"\$url\";; esac'"
bind -T copy-mode-emacs MouseDown3Pane send-keys -X select-word \; send-keys -X copy-pipe-and-cancel "sh -c 'read -r url; case \"\$url\" in http://*|https://*) open \"\$url\";; esac'"

With this snippet you can simply right-click on a link in Terminal and it will open in your default browser, just like it should.

Looking to do more with your tmux config? Take a look at my full .tmux.conf. It adds a few other quality-of-life tweaks like pane splitting, vi-style copy mode, and more, all without altering Terminal.app’s native look.

These past few weeks have found me looking again at moving off of Apple. I’ve been eyeing a new Pixel phone (I still say my Pixel 3XL was probably my all-time favorite phone) as well as Linux laptops. It’s tempting, but I’m going to stick with Apple.

Apple device integration is still the best

Primarily my main reason for sticking with Apple is the device integration. I can start something on one device and pick it up on another and that pretty much works for everything at this point.

Every other tech I’ve tried finds some way to limit this and the result is always that for pretty much any real task I have to keep my phone and my laptop with me to get it done. That might seem normal for most, but that’s my problem with it. Every one of these devices is a general purpose computer and I want them to behave like it. Apple, these days, does a great job with it.

My family is still on Apple

The second reason I stick with Apple, and what brought me back to it in the first place, is that my entire family is “all in” on Apple. That has come in surprisingly handy these past few years in sharing data, offering tech support and more. Sure, I can (and did) work with them when I was on Android and Linux but the friction was much higher, particularly for my parents and my brother. These days I don’t have to guess. I know what they have and we make it work.

Everything I need is actually available for Mac

Next, unlike Linux where I spent a large portion of my time fighting to make various services or apps work, everything I need works well on my Apple hardware.

This means I don’t have to find weird third-party clients for things like Sonos or deal with alternative apps for many of the things I use on a regular basis. It also means that I can get by on Apple’s default apps for almost everything I need. That was simply impossible on Linux.

As a perfect example of this, I wiped my Mac this morning. It took me less than 2 hours to completely restore it, configuration and all. That’s not from a backup either. I simply ran my dotfiles’ setup script and it was all back to working order very quickly. I never could get my Linux machines anywhere near that efficient and it’s come in handy on more than one occasion.

iCloud’s services just work

Finally there’s iCloud. I have a lot of data in it these days and, unlike with Google or the dozens of other services I’ve used, I’m OK with that. Once I log into iCloud my messages, mail, phone and so much else is just there and works. That has been a very handy thing for me.

Apple really is the best, for me

So all this, device integration, family, app availability and iCloud put together mean that Apple’s ecosystem, while not perfect, is still, in 2026, the right fit for me. Not only do I not see that changing any time soon, but anymore I don’t know if I even want it to.

Since then I’ve given plenty of conference talks, Meetup presentations and other more informal teaching, but it’s not the same as being in a classroom.

There’s something to be said about helping folks move forward in their lives, whether it’s a classroom, where I taught computer science, or an airplane cockpit, where I taught folks how to fly. For all the experiences I’ve had before or since, it is the teaching that was the most rewarding.

People often ask me why I quit flying for a living. The truth is that the fun part of flying was the teaching. The rest was honestly incredibly boring. Sure, I loved the travel, but that gets old after a while. Considering my first day as a professional pilot, as a flight instructor for SIU, was on September 11, 2001, I can’t say being around an airport was ever a fun part of the job. And let’s face it, no one really enjoys dealing with air travel today on any level.

What I miss about flying was teaching someone how to fly. More often than not the student is someone who dreamed of flying an airplane most of their lives. They, as the student, sit in the left seat, which is normally the captain’s seat on a passenger jet, and I, as the instructor, am in the right, co-pilot seat. Most importantly, from the moment we walk out to the plane to the moment we sign a logbook we both want to be there and we both take something away from it.

If we want to sight see from the plane we can do that. If we want to do more touch-and-gos, we can do that too and each and every turn, landing, takeoff and communication is geared towards making sure that student is that much more ready to meet their goal. When the time comes for their first solo or their checkride I might not be physically with my student, but my heart sure is. Their success is the point, and for every one, my nerves are as bad as theirs, as I can’t wait to hear (or see) the results.

In the classroom, it isn’t much different. From the first day through the final exam I love working with each and every student, especially at the moment when a complex topic “clicks” for them.

Whether in the classroom or in the cockpit, though, there’s nothing like seeing someone succeed at their own goals and knowing you had a part of that.

When I left flying, being a flight instructor wasn’t much of a career. To most of aviation, it is considered “time building” as the instructors are just there to log hours of their own for their big airline job. That wasn’t me. I always thought I would go back to it part-time, but life has never worked out that way.

I’m fortunate. I’ve been able to teach at the college level in two very different disciplines, aviation and computer science. Today, though, every time “back to school” is talked about on TV I remember those days and think maybe this will be the year I find myself teaching again. A guy can dream, right?

Why I Wiped It

I wasn’t unhappy with my library because it was messy. I was unhappy because I was bored with it. I’d re-listened to the same collection for years, adding albums, but never really pruning anything, and at some point I stopped listening to anything new. I kept reaching for the same few hundred songs out of thousands, not because I wanted to hear them, but because they were familiar.

By the time I reset it in March, the library had grown to more than 2,000 albums. That’s not a small thing to walk away from, but the size was part of the problem. Somewhere in there was music I actually loved, buried under years of half-remembered additions, one-off recommendations I never revisited and albums I only kept out of habit.

Starting Fresh: Again

So I erased it. All of it. No “just in case” folder set aside for later.

Then, since March, I’ve added back more than 1,000 albums, and I’ve realized I’m just rebuilding the old library from memory.

So I’ve deleted it again and this time I’m building a new one around what I actually want to listen to, which turns out to be narrower and more specific than “everything I’ve ever liked.”

What I’m Actually Looking For

The goal this time isn’t volume. It’s peace. I want music that calms me rather than music that’s simply familiar. That means spending more time with a smaller set of artists and genres instead of skimming across everything and being a lot more willing to leave an album out if it doesn’t do anything for me.

It also means listening more intentionally. Instead of putting the library on shuffle and letting habit take over I’m choosing what goes in and, just as often, choosing what stays out.

Where This Goes

I don’t know if this library will end up at 2,000+ albums again, or even if it ever should. That’s sort of the point. The old one grew by accumulation. This one is growing by choice, and so far that’s made all the difference.

None of this was one big redesign. It’s been a lot of small releases, sometimes a few in a single day. Each one nudged things forward, but looking back at the changelog, a few themes stand out.

A New Coat of Paint

The most visible change was a full color refresh back in the spring. It was intentionally a breaking change: I wanted an excuse to actually sit down and rethink the palette instead of tweaking it forever. It’s more “earthy” than my previous palette and just feels more like me. Everything since then has been built on top of that, and I love it so much that I’ve turned it into a VS Code theme, an Xcode theme, and more.

I’ve Added a Library

The library has probably gotten more attention than any other part of the theme this year. It started with the goal of backing up my Goodreads history and has since grown to include filtering by year, author, and rating, along with summary cards for years and authors. Along the way I fixed a few bugs and tweaked the design here and there and now I’m pretty darn happy with it.

Under the hood I also added ISBN, ASIN and cover image support to book front matter, which finally made the covers reliable instead of a guess (even though I don’t display them yet).

When I launched it, I displayed all the books at once, which didn’t make much sense. I later added manual pagination, but as of this week, the list loads progressively as you scroll, which feels a lot more natural on a page like this.

Alongside that change, I refactored the underlying script to make it simpler and faster.

Faster, Leaner Pages

A lot of the less visible work went into performance. Content images now get a proper WebP srcset through a render hook, load lazily when they’re offscreen, and let the browser select an appropriately sized image instead of always downloading the largest one. Header images received the same treatment, and the search index is now truncated so its payload doesn’t balloon on larger sites.

I also cleaned up some things that were quietly working against performance and correctness, like a fetchpriority=high hint that had leaked onto content images instead of staying reserved for actual LCP elements.

Cleaner Feeds and Metadata

RSS took a few passes. Feeds broke and got fixed for newer Hugo releases, notes finally got their own working RSS feed, and the main feed’s dc:creator field is now configurable through site parameters instead of being hardcoded. I also replaced the old schema.json approach with a proper JSON-LD header, and standardized how page and feed titles are formatted so they’re consistent everywhere instead of ad hoc.

Small Stuff That Adds Up

The rest was a lot of polish: a skip-to-content link, a noscript fallback for search, datetime attributes on post timestamps so the semantics are actually correct, the monospace font was finally removed from blockquotes so quotes stop looking like code, and a handful of favicon fixes (Safari really did not like the old one).

A Better Development Workflow

None of this would have been as easy to keep shipping without the boring maintenance work alongside it. I added ESLint and switched to Hugo’s own gotmplfmt formatter for templates, migrated the dev site config from hugo.json to hugo.toml, and kept dependencies current with pretty much every release. There were also a couple of straight-up refactors just to cut cruft out of the codebase, with no user-facing change at all.

I’m Loving This Work

What strikes me looking back over all of this is just how steady the pace has been. No big rewrites, mostly a lot of small, deliberate improvements. That’s exactly the kind of work I want to be doing with this site right now, and I’m looking forward to seeing what the next few months of changes look like.

As a bonus, I’ve made this all available for your site at kana.sh

After a lot of trial and error I settled on Unread as my feed reader. It works well, though I still prefer Reeder back in its prime. Unread does have one feature I haven’t seen in years, though: a free syncing service that not only works, but works well. It works so well, in fact, that I decided it was time to drop Feedbin, which had been syncing Reeder for me for the last few years. It’s been a great combination.

When I switched I also decided it was time to start my feed subscriptions over, since it had been a while and I was subscribing to literally hundreds of feeds, most of which I no longer found relevant.

Today I’ve got a few dozen feeds in Unread, and it has reminded me of just how much I appreciate RSS feeds, and why I bothered with all this switching in the first place.

Sure, I could get my news through social media, wading through AI slop and rage bait to find it, but why?

The truth is I don’t need 1,000 sources, and I definitely don’t need to find out what’s trending for everyone else (or even anyone at all). What I don’t want is to get sucked into rabbit holes of topics I don’t care about.

What I need is to keep up with the few sites that are important to me and RSS is still the best tech to do that.

Thankfully, most content management systems, including WordPress and Hugo, publish their content in RSS format, and it’s easy for readers to find the feed (at least in most cases). All that’s left is to find the reader that works for you and paste in the URL of the site you want to subscribe to.

So if you’re stuck in algorithmic hell, tired of the endless scrolling, the AI slop and the rage bait, dust off an RSS client and add the sites you care about. If you’re like me it might just restore your faith in the web.

For a number of years I used Dr. Link Check to give me a report of broken links, which I’d then fix by hand. It’s been effective but this site has grown to a point where I need an ever-more-expensive plan to keep up with it all. That’s OK, but not ideal.

Since moving back to Hugo, whose links are much easier to parse programmatically, I thought there had to be a better way.

There is, and it’s called Lychee.

Lychee is a Rust CLI utility that checks links programmatically and generates a report I can use to fix them. With Dr. Link Check I ran link checks once a year when I paid for a month of the service. With Lychee I run link checks automatically once a month or on demand, either as a GitHub Action or on my laptop. This means I can stay ahead of the inevitable link rot over time and make sure this site continues to function as I intended.

The Lychee Configuration

Regardless of where I run Lychee, locally or in the GitHub Action, it uses the same configuration file:

# Shared config for `make check-links` and .github/workflows/link-check.yml.
# lychee loads this automatically from the working directory.

cache = true
max_cache_age = "25d"
no_progress = false

# Accept 403s: many sites block bots outright, which isn't a real broken link.
accept = ["200..=299", "403"]

exclude = [
    '^(?:/|#|\.)',
    '^file:',
    '^mailto:',
    'https?://(www\.)?chriswiegman\.com',
]
exclude_path = ["public/library/"]

# Identify ourselves so hosts don't silently throttle/block an anonymous bot UA.
user_agent = "Mozilla/5.0 (compatible; chriswiegman.com link checker; +https://chriswiegman.com)"

# Give slower sites more time before giving up, and retry transient/rate-limit
# failures with a real gap instead of hammering them again immediately.
timeout = 30
max_retries = 4
retry_wait_time = 3

# Keep overall load low enough that we don't trip rate limits or saturate
# our own connection pool (defaults are 128 total / 10 per host / 50ms gap).
max_concurrency = 32
host_concurrency = 4
host_request_interval = "500ms"

Running Lychee Locally

To run Lychee locally I use a Make target. This generates a fresh report each time I run it:

.PHONY: check-links
check-links:
	rm -f lychee-report.md
	@command -v lychee >/dev/null 2>&1 || { echo "lychee not found. Install it with: brew install lychee"; exit 1; }
	hugo --gc --minify
	@lychee -vv --root-dir '$(CURDIR)/public' --format markdown --output lychee-report.md './public/**/*.html';

With this I only run make check-links from my terminal and it generates a Markdown report I can use to clean up any bad links.

Running as a GitHub Action

I also use the following GitHub Action to check the links on my site monthly and create an issue with any bad links found:

name: Check for Broken Links

on:
  schedule:
    # Run monthly at 7 AM UTC on the 1st of every month
    - cron: '0 7 1 * *'

permissions:
  contents: read
  issues: write

concurrency:
  group: ${{ github.workflow }}
  cancel-in-progress: true

jobs:
  check-links:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v7
        with:
          submodules: true
          fetch-depth: 2

      - name: Setup Hugo
        uses: peaceiris/actions-hugo@v3
        with:
          hugo-version: "latest"
          extended: true

      # Hugo's resources/ (processed images, bundles) and its module/build
      # cache (.hugo_cache) are cheap to share across runs but expensive to
      # rebuild from scratch, so both are restored from one cache entry
      # keyed on everything that can change the build output.
      - name: Cache Hugo build artifacts
        uses: actions/cache@v6
        with:
          path: |
            resources
            .hugo_cache
          key: ${{ runner.os }}-hugo-${{ hashFiles('**/go.mod', '**/go.sum', '**/package-lock.json', '**/pnpm-lock.yaml', '**/yarn.lock', 'hugo.toml', 'hugo.yaml', 'hugo.json', 'config/**', 'assets/**') }}
          restore-keys: |
            ${{ runner.os }}-hugo-

      - name: Build site
        shell: bash
        run: hugo --gc --minify --cacheDir "${{ github.workspace }}/.hugo_cache"

      - name: Cache Lychee output
        uses: actions/cache@v6
        with:
          path: .lycheecache
          key: cache-lychee-${{ hashFiles('.lycheecache') }}
          restore-keys: cache-lychee-

      - name: Check for broken links
        id: lychee
        uses: lycheeverse/lychee-action@v2
        with:
          args: --root-dir '${{ github.workspace }}/public' './public/**/*.html'
          fail: false
          format: markdown
          jobSummary: true
        env:
          GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}

      - name: Upload lychee report
        if: always()
        uses: actions/upload-artifact@v7
        with:
          name: lychee-report
          path: ./lychee/out.md
          if-no-files-found: warn

      - name: Create or update issue with broken links report
        if: steps.lychee.outputs.exit_code == '1'
        uses: actions/github-script@v9
        with:
          script: |
            const fs = require('fs');
            const maxBodyBytes = 60000;
            const runUrl = `${context.serverUrl}/${context.repo.owner}/${context.repo.repo}/actions/runs/${context.runId}`;

            let report = '';
            try {
              const lycheeOutput = fs.readFileSync('./lychee/out.md', 'utf8');
              const outputBytes = Buffer.byteLength(lycheeOutput, 'utf8');
              if (outputBytes > maxBodyBytes) {
                const trimmed = lycheeOutput.slice(0, Math.floor(maxBodyBytes * 0.9));
                report = `${trimmed}\n\n...output truncated. [See full report in workflow logs](${runUrl}).`;
              } else {
                report = lycheeOutput;
              }
            } catch (error) {
              report = `Could not read lychee output. [See workflow logs](${runUrl}) for details.`;
            }

            const body = `## Broken Links Report\n\n_Generated by weekly link check — [workflow run](${runUrl})_\n\n${report}`;

            const issues = await github.rest.issues.listForRepo({
              owner: context.repo.owner,
              repo: context.repo.repo,
              state: 'open',
              labels: ['broken-links']
            });

            if (issues.data.length === 0) {
              await github.rest.issues.create({
                owner: context.repo.owner,
                repo: context.repo.repo,
                title: 'Broken Links Detected',
                body: body,
                labels: ['broken-links', 'bug']
              });
            } else {
              await github.rest.issues.createComment({
                owner: context.repo.owner,
                repo: context.repo.repo,
                issue_number: issues.data[0].number,
                body: body
              });
            }

Upload this to your .github/workflows folder in your repo and it will handle everything except actually fixing the links.

Taken together, the config and these run methods are helping me clean up this site and keep it running well going forward. If you run a Hugo site of your own, both the config and the workflow above should drop in with only a little modification.

To address this I’ve created a simple Backup GitHub app that does one thing and one thing well: it fully backs up all my GitHub repos, public and private.

This script, with few options, has you log into your GitHub account without playing games with access tokens and stores that login in your Mac keychain. It then simply backs up every repo in your account to the current directory (though you can specify another directory with a flag, if you want) and it does it all super fast.

That’s it. No fancy bells or whistles… just a simple backup of what matters most: all your GitHub code.

You can install it from Homebrew or directly from GitHub and then just run it from the folder you want to backup your repos to. If you run it a second time it will simply update the repos it finds making it perfect for keeping your backups current over time.

As a bonus, this was a fun little project for me. I have been experimenting with how to use AI, but not for this. The app itself was done by hand over the last few days for fun and, fun it was. I don’t have many opportunities for that lately.

So if you need a quick and easy way to backup your GitHub code, give it a shot.

One note… it’s Mac only, for now, as I don’t have any other machines to test it on. It might work on Linux, but I wasn’t going to promise that. Feel free to open a PR if you want to help me distribute it there.

With a little bit of work I now have a solution that works for me well in VS Code by letting me autocomplete the tags and categories I’m already using throughout this site. I just start typing and it lets me know if a tag has been used before or not.

Here’s how it works:

Extract the Tags and Categories and save Them to JSON

The first piece is a Node.js script that extracts all the tags and categories and saves them to .vscode/tags-categories.json and .vscode/markdown.code-snippets.

The former file I use for reporting. The latter is what actually does the magic in VS Code.

Save this to scripts/extract-tags.js

#!/usr/bin/env node

/**
 * Extracts all unique categories and tags from published Hugo posts.
 * Outputs a JSON file that can be used for autocomplete/reference.
 */

const fs = require("fs");
const path = require("path");

const CONTENT_DIR = path.join(__dirname, "..", "content", "posts");
const OUTPUT_FILE = path.join(
  __dirname,
  "..",
  ".vscode",
  "tags-categories.json",
);
const SNIPPETS_FILE = path.join(
  __dirname,
  "..",
  ".vscode",
  "markdown.code-snippets",
);

/**
 * Extracts frontmatter from a markdown file
 */
function extractFrontmatter(content) {
  const match = content.match(/^---\n([\s\S]*?)\n---/);
  return match ? match[1] : null;
}

/**
 * Parses YAML-style list items from frontmatter
 */
function parseListItems(frontmatter, key) {
  const items = [];
  const blockRegex = new RegExp(`^${key}:\\s*\\n((\\s*-\\s*.+\\n)+)`, "m");
  const match = frontmatter.match(blockRegex);

  if (match) {
    const lines = match[1].split("\n");
    for (const line of lines) {
      const itemMatch = line.match(/^\s*-\s*(.+)\s*$/);
      if (itemMatch) {
        const value = itemMatch[1].trim().replace(/^["']|["']$/g, "");
        if (value) {
          items.push(value);
        }
      }
    }
  }

  return items;
}

/**
 * Recursively finds all markdown files
 */
function findMarkdownFiles(dir) {
  const files = [];
  const entries = fs.readdirSync(dir, { withFileTypes: true });

  for (const entry of entries) {
    const fullPath = path.join(dir, entry.name);
    if (entry.isDirectory()) {
      files.push(...findMarkdownFiles(fullPath));
    } else if (entry.isFile() && entry.name.endsWith(".md")) {
      files.push(fullPath);
    }
  }

  return files;
}

/**
 * Main extraction logic
 */
function extractTagsAndCategories() {
  const categories = new Set();
  const tags = new Set();
  const categoryCount = {};
  const tagCount = {};

  const files = findMarkdownFiles(CONTENT_DIR);
  console.log(`Found ${files.length} markdown files`);

  for (const file of files) {
    const content = fs.readFileSync(file, "utf8");
    const frontmatter = extractFrontmatter(content);

    if (!frontmatter) continue;

    // Extract categories
    const fileCategories = parseListItems(frontmatter, "categories");
    for (const cat of fileCategories) {
      categories.add(cat);
      categoryCount[cat] = (categoryCount[cat] || 0) + 1;
    }

    // Extract tags
    const fileTags = parseListItems(frontmatter, "tags");
    for (const tag of fileTags) {
      tags.add(tag);
      tagCount[tag] = (tagCount[tag] || 0) + 1;
    }
  }

  // Sort by usage count (most used first)
  const sortedCategories = Array.from(categories).sort((a, b) => {
    return (categoryCount[b] || 0) - (categoryCount[a] || 0);
  });

  const sortedTags = Array.from(tags).sort((a, b) => {
    return (tagCount[b] || 0) - (tagCount[a] || 0);
  });

  return {
    categories: sortedCategories,
    tags: sortedTags,
    stats: {
      categoryCount,
      tagCount,
      totalCategories: categories.size,
      totalTags: tags.size,
      totalFiles: files.length,
      generatedAt: new Date().toISOString(),
    },
  };
}

/**
 * Generate snippet prefixes for a tag/category
 */
function generatePrefixes(name) {
  const lower = name.toLowerCase();
  const prefixes = [lower];

  // Add concatenated version for multi-word items (e.g., "Digital Life" -> "digitallife")
  if (name.includes(" ")) {
    const concat = lower.replace(/\s+/g, "");
    if (concat !== lower) {
      prefixes.push(concat);
    }
  }

  // Add common abbreviations
  const abbrevMap = {
    Technology: ["tech"],
    Personal: ["pers"],
    WordPress: ["wp"],
    Infrastructure: ["infra"],
    "Open Source": ["oss"],
    Reflection: ["reflect"],
    "Web Development": ["webdev", "web"],
    Development: ["dev"],
    "Digital Life": ["digital"],
    "Social Media": ["social"],
    Education: ["edu"],
    "Self-hosting": ["selfhost"],
    "Content Management Systems": ["cms", "contentmanagement"],
  };

  if (abbrevMap[name]) {
    prefixes.push(...abbrevMap[name]);
  }

  // Return single string if only one prefix, otherwise return array
  return prefixes.length === 1 ? prefixes[0] : prefixes;
}

/**
 * Generate VS Code snippets from tags and categories
 */
function generateSnippets(data) {
  const snippets = {};

  // Generate category snippets
  for (const category of data.categories) {
    snippets[`Category: ${category}`] = {
      prefix: generatePrefixes(category),
      body: category,
      description: `Category: ${category}`,
    };
  }

  // Generate tag snippets
  for (const tag of data.tags) {
    snippets[`Tag: ${tag}`] = {
      prefix: generatePrefixes(tag),
      body: tag,
      description: `Tag: ${tag}`,
    };
  }

  return snippets;
}

/**
 * Main execution
 */
function main() {
  console.log("Extracting tags and categories from published posts...");

  const data = extractTagsAndCategories();

  // Ensure .vscode directory exists
  const vscodePath = path.dirname(OUTPUT_FILE);
  if (!fs.existsSync(vscodePath)) {
    fs.mkdirSync(vscodePath, { recursive: true });
  }

  // Write JSON data file
  fs.writeFileSync(OUTPUT_FILE, JSON.stringify(data, null, 2));

  // Generate and write snippets file
  const snippets = generateSnippets(data);
  fs.writeFileSync(SNIPPETS_FILE, JSON.stringify(snippets, null, 2));

  console.log("\nResults:");
  console.log(`  Categories: ${data.stats.totalCategories}`);
  console.log(`  Tags: ${data.stats.totalTags}`);
  console.log(`  Files processed: ${data.stats.totalFiles}`);
  console.log(`\nOutput written to:`);
  console.log(`  - ${OUTPUT_FILE}`);
  console.log(`  - ${SNIPPETS_FILE}`);
  console.log("\nMost used categories:");
  data.categories.slice(0, 5).forEach((cat) => {
    console.log(`  - ${cat} (${data.stats.categoryCount[cat]} posts)`);
  });
  console.log("\nMost used tags:");
  data.tags.slice(0, 10).forEach((tag) => {
    console.log(`  - ${tag} (${data.stats.tagCount[tag]} posts)`);
  });
}

main();

Running the Script

I have three ways to run the script above to update the code snippets. I use a VS Code Task, the terminal via a Make target, or automatically every week via GitHub action. Frankly, the GitHub action is enough but the other options just make it easier for me if I know I’ve changed the list.

Makefile

Add the following to Makefile in your project’s root:

.PHONY: extract-tags
extract-tags:
	node scripts/extract-tags.js

VS Code Task

This one you’ll save to .vscode/tasks.json. You can then run it by selecting “Run Task” from the command palette.

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "Extract Tags",
            "type": "shell",
            "command": "make extract-tags",
            "problemMatcher": []
        }
    ]
}

GitHub Action

Finally, this GitHub Action will run every Saturday, or you can trigger it manually by visiting your repo’s Actions page on the GitHub website:

Save this as .github/workflows/update-taxonomies.yml.

name: Update Taxonomy Database

on:
  schedule:
    # Run every Saturday at 00:00 UTC
    - cron: "0 0 * * 6"
  workflow_dispatch: # Allow manual triggering

permissions:
  contents: write

jobs:
  update-tags:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v6

      - name: Set up Node.js
        uses: actions/setup-node@v6
        with:
          node-version: "lts/*"

      - name: Run extract-tags script
        run: node scripts/extract-tags.js

      - name: Commit changes
        uses: EndBug/add-and-commit@v9
        with:
          add: ".vscode/tags-categories.json .vscode/markdown.code-snippets"
          default_author: github_actions
          message: "Update tags and categories database"
          committer_name: GitHub Actions
          committer_email: actions@github.com

Updating Your Project Settings

Once you can run the script you need to update your project’s settings in VS Code to actually trigger the snippets.

Save the following to .vscode/settings.json.

{
  "[markdown]": {
    "editor.quickSuggestions": {
      "other": false,
      "comments": false,
      "strings": true
    },
    "editor.snippetSuggestions": "top",
    "editor.suggest.showSnippets": true,
    "editor.wordBasedSuggestions": "off"
  }
}

Wrapping Up

That’s it. Now VS Code will automatically complete your tags and categories based on those already in use around the site. This approach has helped me maintain a much cleaner site structure, preventing the tag sprawl I experienced in the past. The autocomplete makes it easy to reuse existing tags rather than accidentally creating duplicates with slight variations.

This is actually the third time I’ve moved this site to Hugo. Historically, I get about a month in and start thinking about going back to WordPress due to workflow issues. This time is different.

Working on this Site Has Been Fun Again

First and foremost, working on this site has been fun again with Hugo. I’ve made over 300 commits since I started porting my old site to it. A few weeks ago I had even started learning Swift and playing with apps for Apple. I’ve enjoyed that, but I haven’t gotten far simply because I’ve had too much fun working on this site.

I’ve built the library and notes pages. I’ve optimized and re-optimized the site templates and I’ve built numerous scripts to make writing easier.

I’ve rethought the content, moving short, personal posts to the “notes” page in order to make my RSS feed and blog easier for folks to read. I’ve also consolidated the tags on this site, going from almost 300 to about 35.

So far I’ve largely kept the design, but that will be updated too. For now I’ve just been optimizing the heck out of what I have with more semantic markup and leaner CSS.

Through all of it, I’ve had fun with the tech. That’s something I hadn’t really had with this site in a very long time.

Workflow Matters

I wrote about my new Hugo workflow a few weeks ago. I’ve automated draft creation and publishing so that I don’t have to worry about the little details that used to drive me crazy.

Since that post I’ve taken it further by implementing the notes page. This page takes all the content that really didn’t deserve to be called a blog post and adds it to a dedicated notes section, separate from the normal blog (though still available via RSS). This corrects a long-standing problem: me publishing what was essentially garbage just to say I published something on a given day.

Going forward I’ve even built the notes feature into my publishing script. Any “Personal” post that is less than 80 words will automatically become a “note” upon publishing. In the end, this means the main feed will contain better content and I can easily publish the shorter, personal notes on the site.

In the end I’ve invested more in my workflow with this iteration of the site than I have with the site itself, and so far I’m really liking the results.

Performance and Privacy Matter

Finally, this site is far more performant and private than something built on WordPress and hosted on WordPress.com could ever be.

What started me on this path back away from WordPress was realizing just how bad WordPress had become for tracking. WordPress.com forces Jetpack onto sites and it was filled with scripts for user tracking, AI, and other garbage that I just didn’t need or want. While I had been able to remove some of that via code, it wasn’t enough. On top of that, no matter how much I tweaked the site the WordPress Dashboard was pathetically slow, especially on my iPad, and writing became a more frustrating chore than something I enjoyed.

Then there was the WordPress theme. I actually did like the base theme I was using, OllieWP (if I was ever forced to use WordPress again, this is the theme I would choose). In the end, though, it couldn’t overcome the shortcomings of working with WordPress’ full site editor’. For example, between the Dashboard performance problems and the ridiculous way editing actually works, it could take an hour or more for even the smallest changes. What’s worse is that there was no good way to roll anything back.

My final straw was trying to adjust the spacing between posts on the homepage. It took multiple screens, each requiring an independent save. In the end, I spent over 2 hours on it, hated the results, and then found that the only way I could roll it all back was to do a full database restore at the host level.

That’s just unacceptable.

Of course, then there were the front-end performance issues as well. Even though the page required no interactivity, I could never get it to load fewer than nearly a dozen JavaScript resources. Add in the CSS and other assets and the best I could get the page weight on the homepage was right around 500kb. That’s insane! Believe it or not, that was also an improvement from the 900kb it was before I started removing all the tracking scripts and other cruft.

Today the homepage of this site, with all resources loaded, is about 14kb. The content is the same as it was with WordPress but the bloat is just gone. This is good for everyone, especially those of y’all who don’t want to be tracked (there is nothing left for tracking other than logs my host, Cloudflare, might keep).

This Site Is Finally Something I’m Proud Of

In the end, after a month back on Hugo this site is finally something I’m proud of and can have fun with. It’s been a lot of years since I’ve been able to say that.

Building my own site is what originally attracted me to tech as a career. Compared to aviation, I was actually building something and it was amazing. The problem was that feeling of pride and wonder seemed to have died long ago.

Thankfully, neither was really dead. I just needed to think differently and spend some time focusing on what matters most to me: how I use my tools.

When I last had this site on Cloudflare I used Cloudflare Pages. That worked well at the time but Cloudflare Pages isn’t getting the attention it used to. Instead Cloudflare is focusing on its Workers product which is generally more robust, but does pose a few challenges for deploying a static site such as this one which is made with Hugo.

It took a little trial and error, but now I’m pretty happy with the this site on Workers. The catch is the default configuration recommended by Cloudflare, where Workers connects directly to my repository just didn’t work for me.

What I needed was a few things:

1. The ability to reliably deploy when new content is pushed (this is where Workers’ recommended connection to GitHub was fine)
2. The ability to easily deploy on demand for any reason I needed to
3. The ability to deploy the site on a schedule to handle scheduled content such as this post
4. Faster deploys than their default mechanism

Thankfully, this wasn’t too hard to get. My configuration involves an updated wrangler.toml configuration as well as a GitHub Action that does all the actual work. Here’s the relevant files:

The Wrangler Config

Wrangler serves as the controller, if you will, for Cloudflare Workers. It’s what starts the server and actually gets your code working. This is the big difference from Cloudflare Pages which just served any files it had automatically.

To run a Hugo site on Cloudflare workers add a file to the root of your site called wrangler.toml with the following configuration:

1
2
3
4
5
6
7
8

name = "chriswiegman-com"
compatibility_date = "2025-07-31"
preview_urls = true

[assets]
directory = "./public"
not_found_handling = "404-page"
html_handling = "auto-trailing-slash"

The only thing you’re going to need to change for certain is the name field on line 1 to reflect the name of your worker. The rest should work fine with most Hugo builds.

The GitHub Action

Next up, the GitHub Action. For this you’ll want to save the following code to .github/workflows/deploy.yml in your GitHub repo:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91

name: Deploy to Cloudflare Workers

env:
  SITE_TITLE: "Chris Wiegman"
  SITE_URL: "https://chriswiegman.com/"
  RSS_URL: "https://chriswiegman.com/index.xml"


on:
    push:
        branches: [main]
        paths-ignore:
            - "content/drafts/**"
            - ".vscode/**"
            - "scripts/**"
            - ".github/**"
            - "Makefile"
            - "package.json"
            - "package-lock.json"
            - "README.md"
            - ".gitignore"
            - "/gitmodules"
    workflow_dispatch: {}
    workflow_call:
        inputs:
            ref:
                required: true
                type: string
    schedule:
        - cron: "0 15 * * *"

permissions:
    contents: read

concurrency:
    group: ${{ github.workflow }}
    cancel-in-progress: true

jobs:
    deploy:
        runs-on: ubuntu-latest

        steps:
            - name: Checkout
              uses: actions/checkout@v6
              with:
                  ref: ${{ inputs.ref }}
                  submodules: true
                  fetch-depth: 2

            - name: Setup Hugo
              uses: peaceiris/actions-hugo@v3
              with:
                  hugo-version: "latest"
                  extended: true

            - name: Cache Hugo resources
              uses: actions/cache@v5
              with:
                  path: |
                      resources
                  key: ${{ runner.os }}-hugo-resources-${{ hashFiles('**/go.mod', '**/go.sum', '**/package-lock.json', '**/pnpm-lock.yaml', '**/yarn.lock', 'hugo.toml', 'hugo.yaml', 'hugo.json', 'config/**', 'assets/**') }}
                  restore-keys: |
                      ${{ runner.os }}-hugo-resources-

            - name: Cache Hugo cacheDir
              uses: actions/cache@v5
              with:
                  path: |
                      .hugo_cache
                  key: ${{ runner.os }}-hugo-cachedir-${{ hashFiles('**/go.mod', '**/go.sum', 'hugo.toml', 'hugo.yaml', 'hugo.json', 'config/**') }}
                  restore-keys: |
                      ${{ runner.os }}-hugo-cachedir-

            - name: Build site
              run: hugo --gc --minify --cacheDir "${{ github.workspace }}/.hugo_cache"

            - name: Set up Node (with npm cache)
              uses: actions/setup-node@v6
              with:
                  node-version: "lts/*"
                  cache: "npm"

            - name: Install Wrangler (cached)
              run: npm ci

            - name: Deploy to Cloudflare Workers
              run: npx wrangler deploy
              env:
                  CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
                  CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}

Of course you’ll want to change your site info on the first 3 lines. You’ll also need to set two secrets in GitHub: CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID.

The latter is available on the right-hand column of the Overview page for your Cloudflare domain.

The API key can be created under your Cloudflare profile by going to API Tokens. You’ll need to add the following permissions:

• <your user> Scripts:Edit
• All users - User Details:Read

The Action itself does two things:

1. It runs daily at 09:00 CST as well as running on push and running “on demand” in that you can manually trigger it from the “Actions” page of your GitHub repository.
2. It builds your site, but it also caches the build which can make it much faster. On my little site it knocks the build time from ~5 minutes to around 40 seconds, mostly due to all the image processing I do.
3. It installs Cloudflare’s Wrangler and deploys it per our Wrangler script above.

To use Wrangler in this fashion, you’ll need to install it in your Hugo site;s repo with npm. Use the following in your repo’s directory to install it:

npm i -D wrangler@latest

Note that Wrangler is only needed for deployment. Wrangler is saved as dev script so it shouldn’t affect anything else on your site.

That’s it. With those two files deployed to your site and Wrangler in your package.json file your Hugo site should be fast and available on Cloudflare Workers.

While I wasn’t technically a pilot for the last 5 years I worked in aviation, I did support the aviation department at Southern Illinois University Carbondale with tasks such as maintaining flight simulators and even flying planes for maintenance checks when needed. In many ways I miss that job but I was there to get a degree and move into a developer role so, as soon as I graduated, that’s exactly what I did.

I left SIU to work for St. Edward’s University in Austin, TX where I also received my first official title as “developer.” Since then I’ve had a number of tech jobs and moved into management. Life looks as different from 2012 to today as it did from when I first started in aviation in 1998 until I left it in 2012.

It’s hard to believe it’s been that long. I still feel like I’m just getting started in tech and I’m not even half way through it. I have 20 years to go before I can consider retirement.

I don’t know how the rest of my career in tech will look but I’m looking forward to see what I can bring to the table for the next 14 years and beyond.

A high-level overview

I had a few major friction points the last time I used Hugo. The first was trying to manage content. I had all the posts in a single directory and it just wasn’t usable. Second was properly handling drafts. I accidentally published a draft on more than one occasion and I don’t want to do that again. Finally was handling post dates, particularly with drafts.

Today I solve the first issue by using a different post structure. Instead of storing all 800 plus files in a single folder, I put all my posts in /content/posts/<year>/ folders. Adding the year folders makes it so much easier for me to sort through the old post list and find what I’m looking for when I’m trying to link back to it.

I’ve also improved how I name the draft files themselves. In the year folder files are named in the following format: MM-DD-<post title>.md. The date is based on the publish date they appear on the site and makes it even easier for me to find the content I was looking for. Previously I would sometimes use a date, but it was usually when I started a post draft. This could get very confusing when I was trying to find an old post.

Of course, a good naming convention actually has to be followed. To do this today I use two scripts that can be run in any number of ways: “Create Draft” and “Promote Draft.”

Working with drafts

Create Draft does what it says. It creates a new post draft under /content/drafts/ and labels the file with a timestamp. This lets me work on the draft for as long as I want without risking publishing it. The file name doesn’t matter either, I can change it to anything I want to help make sorting multiple drafts easier.

As for the draft itself, it uses most of the normal front matter but with a few twists. First, it adds the base of an image for the featured image. Next it also adds empty taxonomy terms for both category and tags. Finally, it doesn’t add a date at all as I don’t necessarily know when I’ll publish the post.

To launch the Create Draft script I can either run it from a VS Code task or run it as a GitHub Action. The former works great when I’m on my laptop. The latter I use when I’m working from my iPad.

Publishing new content

When a draft is ready I run the “Promote Draft” script either from VS Code’s task runner or GitHub Actions. It asks me for a few fields: “now” or “later”, the post file name and a date.

If I only have one post the post file name field doesn’t matter as it will select the only post. If there are multiple posts and I forget to specify the filename it will fail with a robust error messages that even lists all the drafts in the folder. I rarely have more than a couple of drafts I’m working on at a given time so this make publishing a given post very easy.

If I want the post to appear on my site immediately, I select “now” and run the script. It will move the post to the appropriate post folder, rename it to conform to my post naming structure, add a timestamp to the date front matter and set the draft flag to false. If I run it through GitHub Actions it will even handle the post commit and if I run it via VS Code I just commit the changes when the script is done.

If I don’t want to publish the post right that moment I can specify “Later” when running the script and enter the date I want it to publish on in YYYY-MM-DD format. It will do all the same as above only it will set the date and time in the file name and in the date front matter to 8:00 am in my home timezone on the date I specified.

When “now” is selected via GitHub Action it will automatically trigger my deployment action to send it to CloudFlare. If I’ve elected to publish it later the 8:00 am is key as I’ve set my deployment script to also run on a daily schedule at 9:00 am in my home timezone. This will catch the future post date appropriately and publish it to my site, all while accounting for the fact that scheduled GitHub actions aren’t perfectly timed.

As a bonus, when new content is published an additional GitHub Action is kicked off to notify various services of the new content, kinda like Ping-o-matic does in WordPress.

Issues I still need to work on

For the most part, this works great. I can write from IA Writer, my app of choice on my iPad, or VS Code on my Mac and no my post will be available on my site when I want it to be. This is already a lot better than my workflow the last time I tried to use Hugo.

Where I still have some friction is with the iPad. I cannot preview a post so if I get anything wrong, like an image path, I’ll be in trouble. Second, I have to manually kick off the actions on GitHub’s website, update the repo in Working Copy and then remember to sync it all later. It’s not bad but I think I can do better and I’m still experimenting with ways to make that happen.

Finally, editing pages still isn’t great with this workflow (nor was it good with WordPress either). I’m also working on a way to draft edits to pages and have them automatically publish themselves when I want them to.

In the end, though, this is a sustainable workflow I can live with. Content is easier to find and organize, drafting posts is less error-prone and posts are published when I want them to be without me having to worry about publishing anything by accident or missing a post entirely. That’s a huge win and I’m excited for what it will enable for me going forward.

So how do these scripts work?

I’ll follow-up in the coming weeks with posts on each of the scripts, create draft and publish, as well as the VS Code tasks, GitHub Actions and other automation I’m using to make this all work.

…okay, I won’t try any more jokes.

As I wrote the other day, last year was defined by my work. This year I have no intention of repeating that.

That’s not to say that I don’t enjoy my work or that I don’t wish to move my career forward. I very much would like to do those things. What I am saying is that I want to do a lot more than just my day job and I’m excited that this year it all looks possible.

A Running theme on these posts

There is a running theme for every new year that I will continue to carry over into 2026:

I want to work on my health. 2025 was not a good year for my fitness or diet. This year I want to get back on track to at least the level I was at when we arrived in Chicago. This means losing 15 pounds, reducing how much we dine out and drink, and getting my activity level back up to something I’m not embarrassed about.

Honestly, these should be doable. The biggest obstacle to my health was my last job and I’ve already started to get better since leaving in August. The only parts that haven’t started to recover are my fitness level and my weight, both of which are tied together and both of which have continued to falter mostly because I managed to get sick more than once this past fall.

I’ve got this.

I’m excited for new projects

For years I’ve struggled to find tech to work on that is fun for me. I think I failed at this mostly because I kept trying to do things in WordPress. I’m not going to make that mistake anymore.

I’m slowly starting to learn Swift and SwiftUI and have a few project ideas in mind. I’ve also got a lot of things I want to do with this site, from new post ideas to a new theme. Add that to some general utilities I’m working on for myself and I think 2026 will be the first year in many where I’m genuinely excited about doing something in tech again.

I’m comfortable with the tech I have

Part of the excitement of new tech to learn is I’ve stopped agonizing on my tools and have embraced the tech I have, currently all Apple devices. I still have a Framework laptop that can run Linux, but’s it’s mostly been put away in a drawer. I’m done trying to force Linux into my workflow.

Since I shelved the Linux laptop, sometime around August, I’ve found new ways to work with my iPad and my MacBook Pro. It’s amazing what a machine can do when you stop spending all your time trying to make something else work even though something “good enough” is already on your desk.

That’s not to say I’ll never work with a Linux machine again. I did enjoy it. It’s simply an acknowledgement of the fact that Linux doesn’t work for me right now and that’s OK.

All tech is flawed. Instead of trying to fix that I’m going to embrace what I have that works for me today and, honestly, doing so has been fun. I even find myself browsing sites like MacRumors more often and looking forward to new features and hardware. I hadn’t let myself do that in many years.

We’re going to get out more

Outside of projects to work on, I’m also excited for the prospect of traveling again this year.

The last real trip I took was a work trip to Limerick in February 2024. From that time until we spent a weekend in Carbondale this past October the only “travel” Joy and I did was to either my Dad’s or her sister’s house. This year we’re going to fix that.

Next month I’ll go to Athens for the first time for a work trip. At the end of that, Joy and I will meet in Rome for a week to explore and unwind. I can’t wait.

Later in the year we’re talking about a trip to Germany as well as road trips to finally visit friends we haven’t seen in far too long. I’ll take vacation for some of it (especially the trips to Europe) but I’m going to try to take advantage of my remote status and work wherever we land.

So much of our travel in the past was for a reason. Either work, a wedding or family would give us the reason to visit a place and we’ve been horrible at traveling for anything else. This year we’re going to change that and I can’t wait.

I need to stop doomscrolling

Finally, if there’s a real resolution for this year it will be to stop doomscrolling.

Almost every night I find myself sitting down with my iPad after work and, rather than doing anything productive, doomscrolling until it’s time to go to bed. That has to stop.

From reading, to writing, to side projects I’ve tended to replace them all with mindless scrolling. I get why, it was easier when I didn’t know what I wanted to work on, but that’s no longer the case.

Today I have a lot of things I’m actually excited to learn and work on. I don’t need to scroll on here to mask that anymore. That prospect alone is exciting to me.

2026 is here. I’m going to embrace it

All this is to say that I’m excited for 2026, both the good and the bad that will come of it.

For the first time in a very long time I’m in a place that feels like home with family and friends nearby. I’m in a job I love. We have a chance to travel again and I’m genuinely excited for a chance to work with new and exciting tech.

I’m hopeful this will all come together for a 2026 worth embracing, even when things don’t work out as planned.