abbr --add jjc --set-cursor -- 'jj commit -m "%"'

This adds an abbreviation, which is a like an auto-expanding bash alias, that puts your cursor at the % character. So when I type jjc in my terminal and hit space, that expands to:

jj commit -m "<cursor>"

Handy!

My image in video calls looks so much better here compared to my home office, which is in our underground basement and has only one tiny little window to let light in. It’s amazing what natural light can do.

On that note, we’re starting a project soon to renovate our garage to do a number of things, including giving me an above-ground office with some nice windows. I’m looking forward to that. At least the part where the project is done. It’s going to be a slog to get there from here.

On the flip side, working here makes me appreciate my walking pad back home. My body, while bathed in wondrous sunlight, is feeling stiff and stagnant.

Here’s a pic of that mountain.

And one from the night before when the sun was going down.

No filters or processing because, as you can probably tell, I don’t know what I’m doing.

I had my ears checked this week by an audiologist, and my hearing is “borderline” normal except for a particular band of frequencies in which I have achieved “mild” hearing loss. And it just so happens that the typical adult female voice falls within those same range of frequencies.

My wife has some new leverage in our little debate.

The audiologist said it’s my choice whether to try hearing aids now, since my hearing loss is only mild, but that I’m probably going to need them in 5–7 years. Ever the curious cat, I decided to try a demo pair.

The effect was subtle at first. I even asked her, “Are they on?” I couldn’t tell. But I’m now three days in, and I’m appreciating them more and more.

We did family movie night this weekend, and it was literally the only time in our family’s history that my wife wanted to turn the volume up while I was completely fine with it. Usually I’m aspiring toward theater-esque volumes. I’ve been telling myself it’s because I want the IMAX experience at home, but perhaps I’m also trying to fill some gaps in the spectrum.

We went to a food cart for lunch yesterday and sat outside in a somewhat crowded area, with many people chatting nearby. My wife whispered at me, without leaning in, to turn around and look at a guy’s earring. (It was shaped like a huge tooth.) Instead of my typical response, “Huh?” I just turned around and looked. Her eyes lit up. “Ooh, this is fun!” She was referring to the fact that I can actually hear her whisper now. She whispers all the time as a means of covert communication around our kids. But it doesn’t work so well when I ask her to repeat her secret messages at volume.

I also suspect I’m feeling more alert, especially later in the day. Apparently this is common, as the aids reduce listening fatigue. It’s tiring when your brain has to put in extra work to make sense of sounds all day long.¹

So, the hearing aids may be here to stay. I have slight qualms about that, since I’m only 46. But they’re not too glaring a change in my visage. My wife, who sees everything, didn’t even notice that I had them in on that first day until I mentioned it several hours later. Maybe we can incorporate them into foreplay.

With that, I promise I’ll stop blogging about this blog for the rest of the month because I’ve been doing way too much of that lately. With one caveat: I’ll try to keep up with the Blaugust weekly themes, so I might bend that rule I just made if called for by the topic at hand.

On the x-axis, and just spiritually, I’m somewhere around the “Moved from Jekyll to Hugo people.” But I’m pretty high on the y-axis as well, which probably means I need to chill out.

Comic credit to Rakhim.

I found it last night after reading Brennan’s post, Free Speech and the IndieWeb, which discusses the reasons he doesn’t use Cloudflare. See also his longer post on this topic.

I have been feeling a little dirty about using Cloudflare for hosting this little indie blog. Plus, Cloudflare frustrated me this week when it wouldn’t update my broken site (my fault for breaking it; Cloudflare’s for not letting me fix it). So Brennan’s post provoked me to look for alternatives. I searched for options that allow deployment of static sites via rsync, and I soon beheld pico.sh.

I’d signed up and had my site deployed to pico pages in a matter of minutes. Truly, less than ten minutes, including the time to sign up and pay for a year of pico plus, which is only two bucks a month.

This is my deployment command:

rsync --delete -rv ./public/ pgs.sh:/blog

Et voila: https://sal-blog.pgs.sh/

What I’m liking so far

Other than reading docs, it seems I interact with pico.sh entirely over ssh and rsync. Auth is handled via ssh key. If I want to chat with the community, I use IRC with pico’s provided bouncer. Account notifications are provided via a unique RSS feed. This is all so geeky and awesome.

Deploys use actual rsync, so I can see which specific files are being updated, how much data is being transferred, etc. I was wishing for that kind of transparency when Cloudflare’s wrangler tool was refusing to update my site this week. This also gives me control over the deployment: I can upload only specific files or glob patterns, use --dry-run to preview the operation, etc.

Speaking to some of Brennan’s points, pico.sh has a Code of Content, which currently reads:

• Don’t upload content if someone else might own the copyright to it
• Don’t upload gore
• Don’t upload “hate speech” (i.e. demeaning race, gender, age, religious or sexual orientation, etc.)
• Don’t upload material that is threatening, harassing, defamatory, or that encourages violence or crime
• Don’t upload illegal content, nudity, or adult sexual content
• Don’t upload content to spam users
• Don’t upload content to employ social engineering tactics in an effort to trick users
• Don’t impersonate someone else

In short, don’t be an asshole. I like supporting a service that is willing to take a stand on that.

The founders are active on HN, and I like their vibe.

Their blog is filled with transparency about the evolution of the product, and they use RFCs with their community to help guide the direction.

There’s a lot to like so far, and I’m only an hour into this!

What’s next

I’ll keep poking around to learn more, run some tests, etc.

I need to get redirects working. It looks like they use the same format as Cloudflare. Wonderful.

If I’m still feeling this good about it in a day or so, I might just point my domain at it!

PT Mono was in the list of fixed-width fonts that made his cut. For some reason it stuck in my brain. Maybe because I hadn’t heard of it.

Later, I found myself perusing macOS’s Font Book app. There, in the relatively small Fixed Width collection of fonts, was none other than PT Mono. Turns out it’s a default font on macOS.

Coincidence, or obvious message from Zeus?

I set it as my VSCode font and have been quite liking it. It’s fun but not trying too hard.

And just writing this has sent me back down the font rabbit hole. This last paragraph is written using Ubuntu Mono. Why do I do this.

What happened

I can’t know for sure, but here’s what I suspect happened.

Sloppiness on my part

When Hugo builds my production site, it puts the files in the public/ subdirectory. I then upload that subdir to Cloudflare Pages with wrangler.

When Hugo runs its local dev server, which renders all my draft posts, it puts the files in the public/ subdirectory.

See where I’m going with this?

I have to assume that, when I ran my production deploy, the public/ folder was dirty with the dev server’s version of the site. Talk about a rookie mistake.

I’d been keeping the server running on purpose because I ran a pre-deploy check that scraped the site for broken links. I think I’d been passively assuming that the dev server stuck its build somewhere else, and I was too buried in all the Hugo learnings to think too hard on it. Plus, everything had been working fine for the first couple days, so it slipped off my list of concerns.

Rollbacks are nice

I was struggling to get my fix deployed (see The plot thickens section below), but fortunately the Cloudflare dashboard came to my rescue. It has a history of my deployments, and with a click I can instantly roll the site back to any of the recent ones. I found the latest one that didn’t have my drafts, and rolled back to it.

Adding guardrails

I then spent a lot of time adding scripts and automation to prevent this sort of thing from happening again.

• Server:
  • Build the local dev server into a different folder using the --destination flag.
• Build:
  • Added --cleanDestinationDir to the hugo build call (probably redundant with the wipe above, but belt and suspenders).
• Pre-deploy:
  • Error if (DRAFT) appears in my homepage or RSS feed files (I append that to the draft titles in my Hugo templates);
  • Error if localhost links appear in my homepage or RSS feed files (to guard against this problem);
  • Error if the Hugo server is running locally.
• Pre-prod:
  • Wired up a proper staging deploy to a Cloudflare Pages preview site, including its own working RSS feed, of which I am now a proud subscriber.
• Post-deploy:
  • Scrape the deployed site to double check that none of the problems above appear there either.

This is all part of my Makefile now, so make deploy_staging and make deploy_prod automatically do the cleaning, building, double checking, and deploying.

The plot thickens: Cloudflare Pages not updating

At this point I’m thoroughly gunshy about deploying to prod given my recent misadventures, so I used my staging deployment to test all these checks out. And I found a stubborn problem: broken files in staging weren’t getting updated when I’d redeploy.

For example, the <link rel="alternate"... element in my topmost index.html file — the element that tells RSS readers where to find my RSS feed — had localhost as its URL domain. And no matter how many times I re-deployed the corrected site, it wouldn’t change. I tried wrangler’s --skip-caching flag. I tried purging the cache in the Cloudflare Dash. I checked my local public/index.html probably over thirty times to confirm it was correct. I tried downgrading wrangler to an older version, since it’s had several updates recently. I had a dozen conversations with Gemini about it.

No matter what, each time I’d deploy, my staging site’s homepage content wouldn’t budge.

Eventually I tried deploying the site to a net-new Cloudflare Pages preview site. The new site did not have the problem. Okay, good, I’m not crazy.

Then I shoved some changes into my homepage and re-deployed to staging. Aha! That fixed the problem in staging.

So, I suspect I’ve hit some bug in how Cloudflare manages updates. I assume the deploy logic thinks it already has the latest version of the file despite the fact that the local one has different content. But if I make additional changes to the local file, it seems I can unstick it.

To address this, I added one more script to my deployment pipeline. This script adds a comment with a timestamp to the bottom of my public/index.html and public/index.xml files after they are built by hugo. The comments look like this:

<!-- build 1786050421 -->

They should be invisible to the reader, but in theory, they will nudge the Cloudflare logic to update those two pages on every deploy.

This seems like a reasonable time to cite the old classic:

There are only two hard things in Computer Science: cache invalidation and naming things. — Phil Karlton (via Martin Fowler)

Back to GitHub-triggered deploys?

In the midst of all this, I said screw it, this is too wonky and time consuming, I’ll just go back to having Cloudflare build the site from pushes to GitHub.

I set all that up, but the build was failing because Cloudflare Workers uses an older hugo binary. I set the HUGO_VERSION env var as guided by the Cloudflare docs, but it still used an old version. Then I remembered I’d also have to get dart-sass installed in the worker for it to be able to compile my CSS. Gah.

So I gave up on this and went back to solving the problem above.

Maybe things work now

My Makefile is now labyrinthian. It might work. Who knows.

And to you bloggers who use Bear, Micro.blog, Write.as, Pure Blog, etc. … you may now nod and smile in smug satisfaction with your choices.

(Although, this sort of firefighting is kinda fun. Once I the fixing-it part, anyway.)

If you happened to see the actual words of those posts (they might be cached in your feed reader), I realize you now can’t unsee them. My sincerest condolences.

I’ll do a followup post once I figure out what happened and how exactly I fixed it.

Mike recommends self-hosting media. I’ve been back and forth about doing that vs. using something like Cloudinary or Cloudflare. I think Mike makes a good point, and I’ll keep the images in my blog repo.

Mike also puts permalinks in his posts proactively (excuse the accidental alliteration) so they stay consistent across platforms. Smart.

More good thoughts in the post. Check it out!

Well ripgrep is the antidote to that feeling. It’s just mind-bogglingly fast. I flippin’ love ripgrep. I use it for so much stuff.

Anyway, today I found a nice snippet that lists all my blog posts that are still in draft status:

rg '^draft( = |: )true' --glob "*.md" --files-with-matches content

The handy bit there is '^draft( = |: )true', which will find both draft = true (TOML syntax) and draft: true (YAML syntax). Since moving to Hugo, my new posts generated with the hugo new content command have TOML frontmatter, but my old stuff has YAML. (I could easily change the default to use YAML instead, but TOML feels fun and whimsical at the moment.)

Other bits:

• --glob "*.md" filters to markdown files.
• --files-with-matches tells ripgrep to print only the filenames (normally it will also print the file’s contents around the match).
• content is the path to search (my content/ subdirectory).

I stuck it in a shell script in scripts/drafts. Here’s the output at this moment:

> ./scripts/drafts
content/notes/remote-dev-ssh-config.md
content/blog/adding-backlinks.md
content/blog/personal-reference-system.md
content/blog/find-your-drafts-with-ripgrep.md
content/blog/stupid-pizza-humor.md
content/blog/blog-post-resiliency.md
content/blog/supernote-manta-thoughts.md
content/blog/success-at-blogging.md

Don’t judge me. They’re still drafts for a reason. 😉

Here’s what it looks like outside (image from Oregonlive.com):

It’s a drag. My kids both have camps this week that have either been canceled or compromised. Exercising outside is a bad idea. I’m monitoring our indoor AQI with a couple sensors and redistributing air filters around the house.

It’s all relative

That said, this is nothing compared to our bout with smoke in 2020. Our AQI, currently at a casual 160 per the screenshot above, shot past 500. That’s literally off most of the scales. A Department of Environmental Quality rep explained:

It doesn’t mean the monitors can’t display higher than that, it just means the health categories haven’t been set up to go beyond that.¹

Cool.

The AQI hung out at roughly those levels for an entire week. Not to mention, this was September of 2026 when the pandemic was in full swing. I was struggling as a parent. It was deep low point.

So hey, this ain’t so bad. 😉

Heat waves and smoke

Normally, air gets cooler as you go up into the atmosphere, so warm air from the surface climbs up and away from the surface. This air movement is known as convection,² and it carries pollutants like wildfire smoke up into the atmosphere where they disperse.

Heat waves in the Pacific Northwest are driven by high-pressure systems up in the atmosphere. These can be called heat domes (though I’m not yet sure if our current heat wave is technically a heat dome or not). The high pressure forces air to sink toward the surface. The sinking air compresses and warms, preventing cloud formation and air movement. The warming effect also causes a layer of hotter air to form over cooler air below — the reverse of the normal situation described above. This is called an inversion layer.

In this scenario, instead of smoke rising up and dispersing, it’s held down at the surface by the high pressure and sinking air. Meanwhile, the inversion layer acts like a lid over the top, suppressing air movement and causing it to stagnate.² And it’s not just the smoke that stagnates, but also dust, car exhaust, industrial pollution, etc. This can last for days or even weeks.

Better yet, the intense sunlight speeds up chemical reactions of nitrogen oxides and volatile organic compounds in the air, creating ground-level ozone and smog.^{3 2}

I think I get it now. In technical terms, our air has turned to dogshit. But it should get better on Friday!

The issue was that the Hugo baseURL setting wasn’t being applied properly, so all the post links were pointing at localhost. The scrappy, I’m-in-the-middle-of-dinner fix was to set it manually:

hugo --baseURL "https://sals.place" build

But today I hope to figure out why the baseURL setting in hugo.toml setting wasn’t taking effect.

My apologies to any reader who had to deal with the trouble!

Thank you to Pablo and Daniel

After deploying the migrated site last night, I hustled off to dinner with the family, none the wiser that I’d busted my feed. Luckily, Pablo from the excellent powRSS noticed the problem, emailed me to let me know, and told me he’d clean up the broken links on powRSS once it’s fixed. Amazing.

Another reader, Daniel, emailed me as well and even included a link to page on what might explain the issue.

If not for these fine folks helping me out, I might not have noticed the problem for another day or two.

Pablo and Daniel, once again, thank you. 🙏

What should you do when you’re busy and have been spending too much time on your blog lately? Why, dive head first into a completely unnecessary SSG migration, of course!

I had Hugo on the brain last night for somewhat valid, somewhat flimsy reasons:

• I used Hugo in the past and liked it.
• 11ty’s fast, but Hugo’s wicked fast.
• I’ve been writing more Golang code lately.
• While I’m fine with JavaScript and enjoy TypeScript, relying on npm feels dirty these days with all the supply-chain attacks. Hugo is a single, batteries-included binary that does not rely on third-party packages.

With these thoughts in mind, I dipped a toe back into the Hugo pond this morning, liked the feel of it, and before long was wild-eyed and neck-deep in migration. It’s now about 3:50 pm, and I think most of the core stuff is working in Hugo.

Here are my very hasty thoughts on what I like better:

• The local dev server has a flag that controls whether drafts are included or not. I don’t think 11ty has this. I had to write some custom code to be able to run the dev server but exclude drafts locally.
• The dev server seems to reliably start and stop in an instant. The 11ty server gets stuck sometimes, taking a long time to exit.
• I love that Hugo boilerplate leans hard into partials. You can accomplish the same thing with 11ty, but it felt less clear which way is most idiomatic.
• I like that Hugo’s shortcodes are stored in html files instead of JS functions.
• Hugo has native blocks! 11ty says you can use the Nunjucks template-inheritance feature, but it doesn’t work with 11ty’s native layout flow. In my experience, anyway.
• Dates make more sense to me. 11ty forces dates for everything, and it’s really hard to tell whether a page has an explicit date or just the auto-computed date that 11ty imposes on it. I burned a bunch of time wrestling this because I wanted my notes to be undated.
  • Edit: To be fair, 11ty forcing me into dates made me realize that maybe I do want them after all.
• Nitpicking, but defining the nav menu in the hugo.toml config file is clearer to me than how 11ty does menus.
• See above re: single binary.
• See above re: wicked fast.

11ty’s great, of course. Hugo’s just more my vibe so far.

I’m out of time and gonna hit the deploy button. Fingers crossed.

If you’re new to blogging, it’s a great opportunity to meet many cool people, get help with starting up your own website, and participate in a cool community project. If you’re a blogging veteran, it’s just the push to dust off the old site and get back into the ring again. Overall, it’s just a nice event that reinvigorates the community and helps folks not just build up a habit of writing but also form connections with other people in the sphere.

Hard to argue with any of that.

I myself don’t care about the awards, but I do care about conduct (don’t overuse AI, don’t be a dick). Also, the themes are fun:

• August 1st – 6th: Welcome to Blaugust
• August 7th – 13th: Introduce Yourself/Getting to Know You
• August 14th – 20th: Creator Appreciation
• August 21st – 27th: Staying Motivated
• August 28th – 31st: Lessons Learned

See the Themes and Prompts section of the site above for more detail on those. I’ve added these to Todoist, so I’ve got a fighting chance at actually doing some of them.

It’s not too late to hop on board. Take a gander at the page linked above and sign up! And regardless of Blaugust, if you’re participating in the indie blogosphere in any reasonably positive way, even if just as a reader, you’re helping to keep the cool web alive. Thank you!