It started as a dependency update — just running bundle outdated to see what was stale — and turned into a full day of fixes. Here’s what happened.
The site was technically live at markhazleton.github.io but that’s just the GitHub Pages default. Part of the Make Bold Spark portfolio work involved migrating Spark projects to dedicated domains, so this one is now properly at simpleblog.makeboldspark.com.
That meant adding a CNAME file, fixing the url in _config.yml (which was pointing to the wrong domain and therefore generating wrong canonical URLs in every single page — good catch), and updating robots.txt to point the sitemap at the right address.
Wired up Google Analytics 4 using the Make Bold Spark property (G-RY77Z11S9E). The old google-analytics.html include was still using the Universal Analytics script — which was deprecated in 2023 — so that got replaced entirely. Now the GA4 gtag loads in <head> on every page.
No data before today. Fresh start.
The site had no personality. The home page was literally empty — just a layout declaration. The header showed “Mark Hazleton” with no context. The about page read like a LinkedIn summary.
Fixed all of that:
This was the most time-consuming part. A few of the older posts had problems:
github.io identity. Retitled them to match the current site.The chaos mode post from last July survived intact. Some things shouldn’t be edited.
The SEO plan has a few more items — Google Search Console verification, tag archive pages, related posts at the bottom of each post. Those are the next things on the list.
For now the site is in better shape than it was this morning, which is enough for one day.
]]>The Jekyll project continues its dual-track release strategy, maintaining both the 3.x and 4.x lines:
csv, base64, and json as explicit runtime dependencies, and fixed the --livereload-ignore option.The gap between Jekyll 4.x (latest) and what GitHub Pages supports (3.10.0) continues to be the biggest friction point for Jekyll users on GitHub Pages. Jekyll 4.x brings real improvements — faster builds, better Sass converter support, and modern Ruby compatibility — but GitHub Pages hasn’t adopted it.
As of the last GitHub Pages gem update (v232, August 2025):
| Key Dependency | Version |
|---|---|
| Jekyll | 3.10.0 |
| Ruby | 3.3.4 |
| Liquid | 4.0.4 |
| Kramdown | 2.4.0 |
| Rouge | 3.30.0 |
| Minima | 2.5.1 |
| jekyll-seo-tag | 2.8.0 |
| jekyll-feed | 0.17.0 |
Ruby 3.3.4 on the GitHub Pages runner is a welcome upgrade. The jekyll-sass-converter remains at 1.5.2 (the older Sass engine), which is worth noting if you’re doing anything advanced with Sass.
Jekyll remains one of the most-used static site generators thanks to its deep GitHub Pages integration. While newer tools like Astro, Hugo, and Eleventy have gained significant traction, Jekyll’s simplicity and zero-config GitHub Pages deployment keeps it relevant, especially for blogs and documentation sites.
One trend I’ve been leaning into on this site is pairing Jekyll with Bootstrap 5 via CDN. Rather than fighting with Jekyll’s Sass pipeline for complex layouts, loading Bootstrap 5.3.8 from a CDN gives you a full responsive framework with dark mode support (data-bs-theme), Bootstrap Icons, and modern utility classes — all without adding build complexity. This site now runs on this exact setup.
The intersection of AI tooling and static site development continues to evolve rapidly. Tools like GitHub Copilot make it easy to generate post content, refactor layouts, modernize CSS, and audit configurations. Most of the recent modernization work on this site was done collaboratively with Copilot.
Just wrapped up a round of modernization:
data-bs-theme attributeA few things I’m watching:
That’s it for now. More to come as the year progresses. You can always find my latest work at markhazleton.com.
]]>Starting the year right with some housekeeping and infrastructure updates. I just ran a full bundle update on the site to bring all dependencies current while maintaining GitHub Pages compatibility.
Here’s what got updated in today’s maintenance cycle:
While many gems have newer versions available (Jekyll 4.4.1, Kramdown 2.5.1, etc.), this site intentionally uses the github-pages gem bundle, which locks dependencies to match GitHub’s deployment environment. This ensures:
sources branchRunning bundle exec jekyll doctor confirms everything is healthy: ✅
The site continues to evolve with:
This blog serves as both a personal platform and a testing ground for modern Jekyll patterns. Looking forward to more experiments in 2026!
Site built with Jekyll 3.10.0, deployed via GitHub Pages from the sources branch to simpleblog.makeboldspark.com
Friends, colleagues, fellow travelers of the information superhighway… gather ‘round and let me tell you a tale of digital mayhem that would make even the most seasoned GeoCities veteran weep tears of pure nostalgia.
It started innocently enough. I was looking at my perfectly respectable Jekyll blog - you know, the kind with Bootstrap 5, clean typography, sensible color schemes, and all those boring “best practices” that make websites actually usable.
BORING.
So I did what any rational software architect would do: I asked GitHub Copilot to “go full chaos and crazy” and show me what it could do.
Narrator: He was not prepared for what happened next.
TL;DR: Asked AI for web design chaos, got a 90s nostalgia explosion with Matrix rain effects, rainbow animations, and a Konami code easter egg. The internet may never recover.
What I Expected: Maybe some fun CSS animations, perhaps a disco ball cursor, possibly some Comic Sans if we’re feeling really wild.
What I Actually Got:
Pro Tip: This is what happens when you combine artificial intelligence, web development, and a complete disregard for user experience best practices.
Let me walk you through some of the “highlights” of this digital fever dream:
/* This is an actual line from the chaos stylesheet */
@keyframes rainbow {
0% { color: #ff0000; }
16% { color: #ff8000; }
33% { color: #ffff00; }
50% { color: #00ff00; }
66% { color: #0080ff; }
83% { color: #8000ff; }
100% { color: #ff0000; }
}
Yes, that’s right. Every single heading on my site now cycles through the colors of the rainbow like it’s auditioning for a Pride parade. The site title doesn’t just display text anymore - it PERFORMS it.
The AI decided that my sophisticated blog needed a Matrix rain effect running continuously in the background. Because nothing says “professional software architect” quite like green text falling down your screen while you’re trying to read about cloud architecture patterns.
Remember visitor counters? Those beautiful, spinning number displays that told you exactly how popular your Angelfire site was? Well, they’re BACK, baby! Complete with localStorage persistence and smooth number animations that would make a slot machine jealous.
Here’s where things get truly unhinged. The AI implemented a KONAMI CODE easter egg. That’s right - if you type ⬆️⬆️⬇️⬇️⬅️➡️⬅️➡️BA on my professional blog, it activates “ULTRA CHAOS MODE” which makes literally everything on the page rainbow-colored and bouncy.
I’m putting that on my resume.
But here’s the thing - as I watched my clean, professional blog transform into what can only be described as “a rave having a panic attack in a time machine,” I realized something profound:
Sometimes you need chaos to appreciate order.
In our world of Material Design guidelines, accessibility standards, and user experience best practices (all of which are genuinely important!), we sometimes forget that the web can be fun. Remember when websites had personality? When every site looked completely different? When someone’s personal homepage could assault your senses in seventeen different ways and you’d bookmark it anyway because it was memorable?
Am I going to keep this design? Probably not for my main professional site (my clients might stage an intervention). But you know what? This exercise reminded me why I fell in love with web development in the first place.
The web doesn’t have to be boring. Code doesn’t have to be serious all the time. Sometimes the best way to push boundaries is to completely ignore them and see what happens.
Want to experience the chaos firsthand? The Konami Code is waiting. Just remember: ⬆️⬆️⬇️⬇️⬅️➡️⬅️➡️BA
Warning: May cause spontaneous nostalgia, uncontrollable giggling, or the sudden urge to create your own GeoCities page.
A: Define “good.” If by “good” you mean “accessible, usable, and follows modern design principles,” then absolutely not. If by “good” you mean “memorable, entertaining, and likely to make people share screenshots,” then it’s a masterpiece.
A: I asked it to go “full chaos mode” and it delivered a complete CSS and JavaScript framework featuring Matrix rain effects, rainbow animations, visitor counters, and even a Konami code easter egg. The AI has no chill.
A: Technically yes. Practically your clients might stage an intervention. But hey, if you want to be memorable…
A: Jekyll static site generator, Bootstrap 5, custom CSS animations, Canvas API for Matrix effects, localStorage for visitor counting, and enough JavaScript to power a small carnival.
A: Surprisingly well! Unique content, engaging user experience (even if it’s chaotic), and plenty of social sharing potential. Search engines love memorable content.
A: 100% functional! Try it: ⬆️⬆️⬇️⬇️⬅️➡️⬅️➡️BA. It activates “Ultra Chaos Mode” that makes everything rainbow and bouncy. I’m genuinely proud of this feature.
A: Probably not for the main site (my professional reputation is hanging by a thread), but this experiment taught me valuable lessons about creativity, fun, and pushing boundaries in web development.
P.S. - If you’re a potential client reading this and wondering about my sanity: I promise I can still build sensible, accessible, performant websites. This was just my brain having a digital vacation.
But if you want your site to have Matrix rain effects and rainbow text… I know a guy. 😉
This post was written while listening to dial-up modem sounds and staring at a lava lamp. The author is not responsible for any retinal damage caused by the site’s current visual state.
]]>The out-of-the-box Jekyll/Minima setup uses a Sass pipeline to compile styles locally. It works, but it’s friction — every tweak to the theme means fighting the Sass compiler, understanding which variables Minima exposes, and hoping the github-pages gem version matches your local one.
For a simple personal blog, that’s more complexity than the job requires.
Bootstrap 5.3 via CDN, loaded directly in the <head>. No local compilation. No Sass imports. Just:
<link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.8/dist/css/bootstrap.min.css" rel="stylesheet">
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/bootstrap-icons@1.11.3/font/bootstrap-icons.min.css">
Plus a small style.css for the handful of site-specific things Bootstrap doesn’t cover.
Bootstrap 5.3 handles this natively with data-bs-theme="dark" on the <html> element. I added a toggle button to the header that reads from localStorage and respects the system preference on first visit:
const savedTheme = localStorage.getItem('theme');
const prefersDark = window.matchMedia('(prefers-color-scheme: dark)').matches;
const theme = savedTheme || (prefersDark ? 'dark' : 'light');
document.documentElement.setAttribute('data-bs-theme', theme);
Works without any custom CSS. That’s the whole point.
Replaced the emoji-based icons in the footer and nav with Bootstrap Icons. SVGs, consistent sizing, no font-loading surprises. The social links went from a mix of text and emoji to clean icon links that look the same in every browser.
CDN dependency means the icons and styles don’t load if the CDN is down. For a personal blog that’s an acceptable risk. If this were a production app with uptime requirements I’d bundle them — but it’s not, so I didn’t.
The github-pages gem still pins Jekyll to 3.10.0 and Sass to an old compiler. Bypassing the Sass pipeline entirely sidesteps that constraint cleanly.
]]>When I pushed updates to my GitHub repository, the public site did not reflect the changes. Despite the GitHub Actions workflow running without errors, the site remained outdated. After some investigation, I identified two main issues:
Gemfile.lock file did not include the x86_64-linux platform required by the GitHub Actions runner.activesupport-8.0.2 gem required Ruby version >= 3.2.0, but the workflow was using Ruby 3.1.6.Here are the steps I followed to fix the issues and get the site updates working again:
The first step was to add the x86_64-linux platform to the Gemfile.lock file. I ran the following command locally:
bundle lock --add-platform x86_64-linux
This ensured that the lockfile included the necessary platform for the GitHub Actions runner.
Next, I updated the Ruby version in the GitHub Actions workflow to 3.2.0 to meet the requirements of the activesupport-8.0.2 gem. Here’s the updated section of the workflow file:
- name: Setup Ruby
uses: ruby/setup-ruby@v1
with:
ruby-version: '3.2'
bundler-cache: true
To ensure compatibility across different environments, I normalized the platforms in the Gemfile.lock file by running:
bundle lock --normalize-platforms
This step removed any discrepancies and ensured the lockfile was consistent.
After making these changes, I committed the updated Gemfile.lock and workflow file to the repository:
git add Gemfile.lock .github/workflows/jekyll.yml
git commit -m "Fix platform and Ruby version issues"
git push
Finally, I triggered the GitHub Actions workflow again. This time, the build and deployment completed successfully, and the site updates were reflected on the public site.
By following these steps, I was able to resolve the issues and get my site updates working again. If you’re facing similar problems, I hope this guide helps you troubleshoot and fix them efficiently.
]]>The brief was simple: add a theme switcher that respects the system preference, lets the user override it, and persists the choice across page loads. It needed to touch the header template, the CSS, and write the JavaScript.
Normally that’s 20 minutes of work I’d do myself. I wanted to see how much of it Copilot would handle correctly without me steering.
It proposed three changes in one go:
[data-theme="dark"] and [data-theme="light"] selectorslocalStorage, fall back to prefers-color-scheme, and set the attribute on <html>The CSS variable approach was the right call — no class toggling, no duplicated rules. The JavaScript was clean. I made one change: it was setting the attribute on <body> and Bootstrap 5 wants it on <html> for data-bs-theme to work, so I moved that.
The theme switcher icon started as 🌙 hardcoded in the HTML. Copilot didn’t account for the initial state — if you loaded the page in light mode, you’d see a moon icon suggesting it was already dark. I had to point that out and it fixed the initialization logic.
It also initially used document.body instead of document.documentElement. Small thing, but the kind of thing you catch immediately if you know Bootstrap’s dark mode implementation.
For a well-scoped task with a clear outcome, agent mode saves real time. It’s best when you know exactly what the answer should look like — then you’re just reviewing instead of writing. Where it struggles is anything that requires understanding your specific setup (in this case, which element Bootstrap 5 watches for theme attributes).
Useful tool. Doesn’t replace knowing what you’re doing.
]]>gem install bundler after Ruby is installedOn Windows you want the wdm gem — it lets Jekyll watch for file changes natively instead of polling. Without it --livereload is sluggish. The Gemfile already has it:
platforms :mingw, :x64_mingw, :mswin do
gem "wdm", "~> 0.1.1"
end
It only installs on Windows platforms, so it doesn’t affect GitHub Actions or anyone running on Mac/Linux.
bundle exec jekyll serve --livereload
That’s it. The site builds to _site/ and reloads in the browser whenever you save a file. Default port is 4000.
A few flags worth knowing:
# Preview draft posts from _drafts/
bundle exec jekyll serve --livereload --drafts
# If something's broken and you want a clean build
bundle exec jekyll clean && bundle exec jekyll serve --livereload
If you develop on Windows and deploy via GitHub Actions (Linux), you’ll eventually hit this: the lockfile only has Windows platforms listed, and the Actions runner can’t resolve gems.
Fix it once and forget it:
bundle lock --add-platform x86_64-linux
Commit the updated Gemfile.lock. Done. GitHub Actions will be happy.
Two things worth configuring:
terminal.integrated.defaultProfile.windows) so bundle exec works without switching shells_site/ and .jekyll-cache/ to .gitignore if they aren’t already — no reason to commit build outputNot much to report beyond that — this is one of those “I just wanted to make sure I still know how this works” posts. If you’re here, hello. More actual content eventually.
]]>Learned to update my config.yml to exclude my published (doc) folder, that way Jekyll is not trying to build a site recursivly .
exclude:
- Gemfile
- Gemfile.lock
- /docs/
- /README.md
Also updated the config to include links to the published site
# Site settings
title: Mark Hazleton
email: "" # Removed email
description: >- # this means to ignore newlines until "baseurl:"
Mark Hazleton on GitHub
baseurl: "/" # the subpath of your site, e.g. /blog
url: "https://markhazleton.github.io/" # the base hostname & protocol for your site, e.g. http://example.com
author:
name: Mark Hazleton
email: "" # Removed email
Still need to pick how to automate the copy from my _sites folder to my docs folder that GitHub uses to publish updates to my site.
]]>