Did something I’ve been intending to do for a while, and added glightbox  to this site so you can click any photos I post to see them at the highest resolution. Especially helpful if you visit on a mobile. I also put in per-post galleries, so if you’re already viewing a photo at max res, you can click arrows (or swipe) to see other photos in the same post, but it won’t mix in other photos that aren’t in the same post even if they’re on the same page. (I also worked out how to generate names for the data-gallery attribute automatically from the post slug, so I didn’t have to go back and edit every single existing photo post – that was the most challenging part of this whole pro­cess 😛) If you have Javascript disabled, it should degrade gracefully to just link to the photo. Not all my pictures look totally crisp at full size, but hopefully this still makes it easier to admire all my gorgeous cat and dog photos 😉

Published a bunch of new pages to my personal wiki today, most of them not truly new (they’d been in my Obsidian wiki ages), but a couple were. Some of the new uploads include language revival, Kazakhstan and the browser game Kingdom of Loathing. Check it out if you like 😛

It’s been bugging me for a while that Vercel is generating incorrect “last modified” datetimes for my wiki pages on this site. What it seems to be doing is getting the last modified date only if it’s within the ten most recent commits. If the last modification was further back than that, it prints the last modified datetime of the tenth-most recent commit. From the docs  it looks like Vercel is not even fetching git commit author dates (but commit SHAs and commit author logins, those it fetches…), so instead I guess it stores some cache that only goes back ten commits? I have no real clue, but because I don’t know how to fix this, I’ve commented out the part of my template that generated “last modified” text for my wiki pages. Better to display nothing than to have it display something that’s wrong for the vast majority of pages…

I mean… one way to fix this would be to build my site using GitLab’s CI/CD and just upload the built files to Vercel, instead of GitLab merely passing the source files along for Vercel to build. But ugh, what a hassle to change that all around 😩 Another strategy would be to manually set a “last modified” date in the front matter of pages I want to have one, and display that in preference to whatever git says. (Or even disable enableGitInfo entirely, if it’s just resulting in junk data.) That’d also be annoying, though. So, for the moment, I think just not displaying “last modified” dates’ll have to be the go.

Uhh, well here’s a little Vercel quirk to be aware of: its default build command for Hugo repositories builds all your drafts as if they were ready-to-go finished posts 🤯 It’s not like I had a burn book stashed away in my Hugo drafts or anything but it’s definitely something I wish I’d noticed yesterday! TBH it’s so random it hadn’t even occurred to me they could possibly be doing that – the “build drafts” flag -D is something you have to explicitly add to the basic hugo build command, after all. Fixed now, anyway.

On the off-chance you noticed a couple of hours’ downtime earlier today, that’ll be because I moved this site’s hosting over to Vercel . I made the move for a couple of reasons:

1. As I mentioned, I decided to move my writing repository over to GitLab, and if I was doing that I thought I might as well move my other personal projects at the same time. (GitLab also allows you to host larger repositories on their servers – useful if I keep this site going for years and upload lots of photos – and there are of course political reasons  why lots of people hate Github.) However, the idea of having to rewrite my Github Workflows file for GitLab’s CI/CD system made me sad.
2. I wanted a hosting solution that had a CDN integrated into it, so ordinary HTML pages can actually be cached (so they’ll load fast, from cache, on most pageloads) but the cache invalidates automatically when I update my site (so new posts can be seen on my home page/in feeds/etc. straight away, not hidden behind a stale cache). I never worked out how to achieve this when my hosting and CDN were separate, even though I figured it was possible by processing the output of rsync and sending the output as a list of URLs to purge through the CDN’s API.

At any rate: full credit to Vercel, they made deploying my site from my GitLab repository unbelievably easy. Updating the DNS records for my domain was just as easy, but DNS caching meant it took a couple of hours for the change to go live. As for “why Vercel and not Netlify” or any other similar platform, well… the usage limits on Vercel’s free platform were just a bit more generous. Not that I think I’d have gone over Netlify’s limits anyway, but it’s nice to have some peace of mind 🤷🏻‍♀️

I think the DNS has all updated now, so that’s that: I’m now serving my site through BunnyCDN , which should mean pages, images etc. will load from a server geographically close-ish to each visitor, rather than always from my shared host’s server in the US. The real load time savings will come as more of the site actually gets cached on the CDN servers, of course, so Bunny doesn’t have to fetch so much from the slow shared hosting server.

It might seem like a bit much for a personal homepage, but Bunny is very cheap (the minimum cost of US$1 per month covers up to 100GB of bandwidth, depending on where your visitors live), and the slowness with which my own site loaded here in Australia was really annoying me. So here’s to fast loading speeds!