The post list and archive page weren’t quite enough

This blog runs on Hugo + PaperMod. At first the header just had two menu items: “Posts” and “Archive.” As the post count grows, being able to browse by date or tag helps. PaperMod is a single-column theme though - there’s no concept of a sidebar built in. The content column is fixed at a max width (--nav-width: 1024px) and centered, so on a wide screen there’s blank space on either side. I figured something could go there.

First pass: just two buttons

PaperMod ships an empty hook partial called extend_footer.html - override it and you can inject arbitrary HTML at the end of every page. There’s also a convention where any CSS file dropped in assets/css/extended/*.css gets auto-concatenated into the theme’s stylesheet. Using both, I added two fixed pill buttons in the right margin: “📅 By date” linking to /archives/, and “🏷️ By tag” linking to /tags/. Just shortcuts, nothing more.

Looking at Hatena Blog, I decided to rebuild it

Plain buttons felt thin. Hatena Blog’s sidebar has an actual month-grid calendar with post days highlighted, and a tag cloud with names and counts sitting right there. I wanted that instead.

The tag cloud was easy - PaperMod’s own /tags/ page (taxonomy.html) already does exactly this, so I borrowed its logic directly:

{{ range $tagsPage.Data.Terms.Alphabetical }}
  {{ with site.GetPage (printf "/tags/%s" .Name) }}
    <a href="{{ .Permalink }}">{{ .LinkTitle }} ({{ $count }})</a>
  {{ end }}
{{ end }}

The calendar took more thought since this is a static site generator. At build time, I embed each language’s post dates, titles, and URLs as JSON inside the page ({{ $calItems | jsonify }}), then render the month grid with plain vanilla JS. No external library.

The calendar rendered nothing

I shipped it, and the tag cloud showed up fine - but the calendar area was just blank. The prev/next (‹ ›) buttons appeared; no day grid, no month title.

Checking the actual rendered HTML in devtools, I found this:

<script type="application/json" id="quick-cal-data">"[{\"date\":\"2026-08-21\",\"...\"}]"</script>

The whole array had been escaped and wrapped in quotes as a string. Feed that into JSON.parse() and you get back a single string, not an array. The .forEach() right after it obviously doesn’t exist on a string, so it threw and halted the rest of the script.

The cause was Hugo’s template engine (html/template). When you interpolate a value inside a <script> tag, Hugo automatically treats it as untrusted and escapes it as a JS string literal. jsonify returns a plain string, so Hugo wrapped the whole thing in quotes rather than trusting it as raw JS.

The fix was one line - pipe it through safeJS to tell Hugo explicitly that this JS is safe to pass through as-is:

{{ $calItems | jsonify | safeJS }}

With that, the JSON landed as a real array again, and the calendar started working.

Adding monthly jump buttons

Once the calendar worked, I wanted a way to jump straight to a given month instead of stepping through prev/next one month at a time - which gets tedious as posts accumulate. I added a list of every year-month with at least one post, newest first; clicking one jumps the calendar there in place, no page reload, reusing the same state the prev/next buttons already manage.

Where things stand

This post ends up being a record of the blog fixing itself while I was building it. Calendar, monthly buttons, and tag cloud are all in the sidebar now - next up is actually writing more posts.

To be continued.

Deliberately a different stack

The blog runs on Hugo, but this one is plain HTML/CSS/JS with no build step at all. If I’m going to put projects out as a portfolio, showing range in approach felt better than reaching for the same stack every time. Data lives in a terms.json file, with search and category filtering built on top of it. At launch: 33 terms across 5 categories (stock phrases, reactions/emotions, food & daily life, relationships/how people address each other, and things picked up at work).

Content is a mix of generally well-known Singlish terms plus a few I’ve actually heard myself. The plan going forward is to keep appending to terms.json as new ones come up.

The subdomain pattern became a real pattern

The domain-and-repo shape settled into an actual template at this point: one dedicated GitHub repo per project, one <project>.taikiito.com subdomain via a Cloudflare CNAME. One thing I learned here: the CNAME has to stay DNS-only (not proxied), or GitHub Pages’ automatic HTTPS certificate issuance gets delayed or fails outright.

Back and forth on the footer line

I rewrote the footer copy twice. The first version said something like “hope this is useful to someone” - writing it out, it felt a bit presumptuous, so I changed it to a more self-aware “way too niche for anyone, but I made it for myself so here it is.” Looking at that again, I decided neither was actually necessary and removed the line entirely. Stating what the thing is felt like enough; why it exists is something a reader can decide for themselves.

Two more things shipped, same day

The blog and this glossary, both shipped the same day, both riding the same subdomain pattern. Whatever comes next, that pattern makes it fast to stand up.

To be continued.

Why

The same newsletter that had introduced me to MulmoClaude in the first place also carried some advice from its author: if you want to move toward being an engineer, publish real work on GitHub. The domain setup, self-hosting, and email troubleshooting I’d been doing seemed like the kind of thing that could be genuinely useful to someone hitting the same problem via search, so I decided to write it up.

Choosing a diary format

I first considered topic-organized how-to posts, then switched partway through to a chronological diary - writing things in the order they actually happened, mistakes and detours included. It’s closer to how it actually went.

Picking the stack

I went with Hugo as the static site generator, mainly because multi-language support (i18n) is built in. Theme: PaperMod. Deploy is GitHub Actions building the site and pushing it to GitHub Pages, with a custom domain (blog.taikiito.com) pointed at it via a Cloudflare CNAME.

I split it into two repos: the actual Hugo source I edit (blog-source) stays private, and a single Actions job builds it and force-pushes only the built static output to a separate public repo (blog). Editing history and drafts never leave the private repo - only the finished output is public, which I like.

Renamed my username while I was at it

I also renamed my GitHub username at this point. The old one had a string based on my birthdate in it, added without much thought when I first signed up, and I’d wanted to change it for a while. My first choice was already taken, so I landed on a -dev suffix instead. With zero public repos at the time, the switching cost was basically nothing.

I also set up a GitHub profile README - creating a repo with the exact same name as your username makes it auto-display on your profile page. Kept it to two lines:

Tinkering with computers on the side. Hoping it helps someone.

Where things stand

The blog itself and a public GitHub account are both in place now. The actual posts are what comes next, written up after the fact as things happen.

To be continued.

Why Miniflux

A few options were on the table, but I picked Miniflux for being lightweight and easy to self-host. The setup was one Docker Compose file - a Miniflux container plus a PostgreSQL container. Access followed the same pattern as MulmoClaude: a Cloudflare Access authentication gate in front.

The plan was to pull in the Straits Times, the NYT, and a handful of blogs, sorted by category. Twitter/X was out from the start - it dropped free RSS access back in 2023.

What subscribing to feeds actually revealed

Once I actually wired up the feeds, a few things weren’t what I expected.

• The NHK feed had been silently blocked as of August 8th. No explanation given, and it’s likely targeting cloud-provider IP ranges as a class, not anything specific to my setup.
• The Straits Times and NYT feeds were both alive, but both stop at headline and summary before the paywall.

Technically, I got it fully working.

And decided to stop anyway

Once it was working, I paused and thought about it. The idea of aggregating news by category wasn’t bad on its own, but running it for real seemed like it would just become an ever-growing pile of unread items - an information-overload sink. The point had been to control how much I read, not to read more.

Same day, I removed the whole thing - the Docker containers, the nginx config, the DNS record, the Cloudflare Access application. Less than 24 hours between building it and tearing it down.

Getting something working and actually keeping it are different things

This one taught me that getting something technically working is a different question from whether it actually earns a permanent place in my routine. Deciding to build something and then walk away from it isn’t necessarily a bad outcome.

To be continued.

One subdomain, one static page

I created a new subdomain, card.taikiito.com, and added a second nginx server block on the same Lightsail box. The important part: it’s completely separate from the main Node.js app. No proxy_pass - just a single static HTML file being served - so traffic to the card page has zero effect on the main app’s load.

The content is lifted straight from the business card I actually use day to day. I kept it down to two buttons:

• “Save Contact” - generates a .vcf file on the spot via a JS Blob and opens the phone’s add-to-contacts sheet
• “WhatsApp” - a wa.me click-to-chat deep link

I originally had a third button for sending an email too, but later cut it down to just an info row with a mailto: link. Fewer buttons turned out to be more usable.

A small color detour

I’d built it in navy from the start, but made a black-and-white version too, just to compare side by side. Navy won, and the black-and-white draft got deleted.

A small gotcha

Right after launch, previewing the card inside this app’s own embedded iframe, the email address showed up as a garbled placeholder string instead of the real thing. My first thought was I’d broken something. Turned out to be Cloudflare’s “Email Address Obfuscation” (Scrape Shield) - it automatically encodes email addresses on the page to deter spam scrapers, and a small decoding script is supposed to restore the real address in a normal browser. That decoder just doesn’t run inside this app’s preview iframe. It’s a zone-wide setting, so I left it on and confirmed the real address renders fine in an actual browser tab.

What a name-domain unlocks

The moment my own name became a domain, spinning up small subdomains like this got trivial. A few more of the same pattern would follow.

To be continued.