記事一覧とアーカイブだけでは物足りなかった

Hugo + PaperMod で組んだこのブログは、最初はヘッダーに「記事一覧」「アーカイブ」の2つのメニューがあるだけだった。記事数が増えてくると、日付やタグから辿れた方が使いやすい。PaperModはシングルカラムのテーマで、サイドバーという概念自体がない。ただ、コンテンツ幅(--nav-width: 1024px)は画面中央に固定されているので、広い画面では左右に何もない余白ができる。ここに何か置けるはずだと考えた。

まずはボタンだけ置いてみた

PaperModには extend_footer.html という空のフック(パーシャル)が用意されていて、上書きするだけでフッター末尾に任意のHTMLを差し込める。CSSも assets/css/extended/*.css に置いたファイルが自動で本体CSSに連結される仕組みがあるので、これを使って、画面右端に固定表示する丸ボタンを2つ置いてみた。「📅 日付別」は /archives/ へ、「🏷️ タグ別」は /tags/ へのリンクだけの、ただのショートカットだ。

はてなブログを見て、作り直すことにした

ボタンだけでは芸がない。はてなブログのサイドバーにあるような、実際にカレンダーの月表示が出て投稿日がハイライトされるもの、タグも名前と件数がその場に並ぶものにしたいと思った。

タグクラウドの方は簡単だった。PaperMod自身の /tags/ ページ(taxonomy.html)が既に同じことをしていたので、そのロジックをそのまま借りた。

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

カレンダーは静的サイトジェネレータなので少し工夫が要る。ビルド時に、その言語の全記事の日付・タイトル・URLをJSONとしてページに埋め込み({{ $calItems | jsonify }})、バニラJSで月表示のグリッドを描画する方式にした。外部ライブラリは使っていない。

カレンダーが、何も表示されなかった

書き終えてデプロイしたら、タグクラウドは正しく出るのに、カレンダー部分だけが空白だった。前後の月ボタン(‹ ›)だけが表示されて、日付のマス目もタイトルも出ない。

ブラウザの開発者ツールで実際のHTMLを見て気づいた。埋め込んだはずのJSONが、こうなっていた。

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

配列全体が、エスケープされた文字列として二重にクオートで包まれている。JSON.parse() にこれを渡すと、配列ではなく1本の文字列が返ってくる。直後の .forEach() はもちろん文字列には存在しないので、その場でエラーが起きてスクリプト全体が止まっていた。

原因はHugoのテンプレートエンジン(html/template)の仕様だった。<script> タグの中に値を差し込むと、Hugoは自動的にそれをJSの文字列リテラルとして安全にエスケープしようとする。jsonify が返すのはただの string 型なので、信頼できない値として扱われ、丸ごとクオートで包まれてしまっていた。

直したのは1箇所、safeJS を挟んで「このJSは安全だから素通ししてくれ」と明示するだけだった。

{{ $calItems | jsonify | safeJS }}

これでJSONがそのまま配列として埋め込まれるようになり、カレンダーが動くようになった。

月別ボタンも追加した

カレンダーが動くようになったところで、月ごとにジャンプできるボタンも欲しくなった。前後の月を1つずつ辿るだけでは、記事が増えてきたときに不便になる。投稿のある年月を新しい順にリストアップし、クリックするとページ遷移なしでカレンダーがその月に切り替わる仕組みを、既存のカレンダーの状態管理に乗せる形で追加した。

今の状態

このブログ自体が、動かしながら直したものの記録になった。カレンダー・月別ボタン・タグクラウドがサイドバーに揃った状態で、次は中身の記事を増やしていく番だ。

つづく。

あえて違うスタックにした

ブログはHugoだが、こちらはビルドツールなしの素のHTML/CSS/JSにした。ポートフォリオとして公開するなら、同じスタックばかりより手数の幅を見せた方がいい、という考えからだ。データは terms.json に切り出し、検索とカテゴリ絞り込みのUIをその上に乗せた。公開時点で33語、5カテゴリ(定番表現、感情・リアクション、食・生活、人間関係・呼び方、仕事・現場で聞いた表現)。

内容は一般的によく知られたシングリッシュ表現に加えて、実際に自分が生活の中で聞いた表現もいくつか混ぜてある。今後も会話の中で拾ったものを terms.json に足していく運用にするつもりだ。

サブドメインのパターンが確立した

ドメインとリポジトリの組み方も、このタイミングで型として固まった。プロジェクトごとに専用のGitHubリポジトリを作り、<プロジェクト名>.taikiito.com のサブドメインをCloudflareのCNAMEで紐付ける。GitHub Pages側の自動HTTPS証明書発行を妨げないよう、CNAMEは必ずProxyなし(DNSのみ)にする、というのも今回学んだ点だった。Proxyを有効にしたままだと証明書の発行が遅れる、あるいは失敗する。

一言添えるかどうかで迷った

フッターの文言は2回書き直した。最初は「誰かの役に立てばいいなと思って作っています」という一文を入れていたが、書いてみて少し押しつけがましく感じ、「ニッチすぎて誰得だけど、自分用に作ったのでついでに公開してます」という自虐寄りの言い回しに変えた。それも見返して、結局どちらも要らないという結論になり、最終的には何も足さずに削除した。何を作ったかだけを書けば十分で、なぜ作ったかは読む人が決めることだ、と考え直した形だ。

同じ日に、器が2つ増えた

ブログとこの用語集サイト、同じ日に公開した2つが、どちらも同じサブドメインのパターンに乗っている。次に何を作るにしても、この型に乗せれば早い。

つづく。

きっかけ

中島聡さんのニュースレター経由で以前MulmoClaudeを知ったのと同じように、彼のニュースレターで「エンジニアを目指すなら、まず実物をGitHubに公開するといい」という趣旨のアドバイスを目にしていた。ドメイン運用やセルフホスティング、メールまわりで試行錯誤してきたことが、同じ問題にぶつかった誰かの検索結果に引っかかれば十分だと思い、公開することにした。

形式は「時系列の日記」にした

最初はテーマ別のハウツー記事にしようかと考えたが、途中で「実際に起きた順番のまま書く日記形式」に変更した。うまくいかなかったこと、迷ったこと、あとから直したことも含めて、そのまま時系列で残す方が実態に近い。

スタックを決める

静的サイトジェネレータはHugoにした。決め手は多言語対応(i18n)が標準で入っていること。テーマはPaperMod。GitHub Actionsでビルドし、GitHub Pagesにデプロイ、独自ドメイン blog.taikiito.com をCloudflareのCNAMEで割り当てた。

リポジトリは2つに分けた。実際に編集するHugoのソース一式(blog-source)は非公開、ビルド後の静的ファイルだけを別リポジトリ(blog)にforce pushで公開する構成にしている。GitHub Actionsの1ジョブの中で、ビルド→出力先リポジトリへのpushまで完結させた。ソース側の編集履歴や下書きを外に出さずに、成果物だけを公開できるのが気に入っている。

ついでにユーザー名も変えた

GitHubのユーザー名も、このタイミングで変えた。もともと登録したときに深く考えず入れた生年月日由来の文字列が入っていて、前から気に入っていなかった。理想の名前は既に他の人に使われていたので、末尾に-devを足した形に落ち着いた。公開リポジトリがまだ0個の状態だったので、切り替えのコストは低かった。

合わせて、ユーザー名と同じ名前のリポジトリを作ると自動でプロフィールページに表示される、GitHubのプロフィールREADME機能も使った。中身は最小限、2行だけ。

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

ここから

ブログの器と、公開用のGitHubアカウントが整った。中身の記事は、実際に起きたことをこうして後から書き足していく形になる。

つづく。

Minifluxを選んだ理由

候補はいくつかあったが、軽量でセルフホストしやすいという理由でMinifluxに決めた。構成はDocker Compose1本で、Miniflux本体とPostgreSQLのコンテナを立てるだけ。アクセスはMulmoClaudeと同じパターンで、手前にCloudflare Accessの認証ゲートを置いた。

対象はSingapore Straits Times、NYT、その他いくつかのブログをジャンル別に分類する構想だった。TwitterやXは2023年以降無料のRSSフィードを廃止しているので、これは最初から対象外にした。

フィードを繋いでみて分かったこと

実際にフィードを購読してみると、いくつか想定外のことが分かった。

• NHKのフィードは8月8日付でサイレントにブロックされていた。理由の開示はなく、クラウド事業者のIPレンジ自体が対象になっている可能性が高い。
• Straits TimesとNYTのフィード自体は生きていたが、どちらも本文はペイウォールの手前、見出しと要約までしか取得できない。

技術的には一通り動く状態まで持っていけた。

それでも、やめることにした

一通り動くようになったところで、少し立ち止まって考えた。ジャンルを分けて集約する、という構想自体は悪くないが、実際に運用したら未読が積み上がっていく「情報過多」の受け皿になるだけではないか、という懸念の方が強くなった。読む量を増やすためではなく、読む量をコントロールするために始めた話のはずだった。

結局、同じ日のうちにDockerコンテナ、nginxの設定、DNSレコード、Cloudflare Accessのアプリ設定まで、一式をすべて削除した。作ってから壊すまで、24時間もかかっていない。

動くものを作ることと、使い続けることは別

技術的に動くところまで持っていくのと、それを実際に自分の生活に組み込んで使い続けるのとは、別の話だと分かった一件だった。作って終わりにする判断も、悪い結果ではないと思っている。

つづく。

サブドメインを1つ切って、静的ページだけを置く

card.taikiito.com というサブドメインを新しく作り、Lightsailの同じサーバー上にnginxのserver blockをもう1つ追加する形で対応した。ポイントは、MulmoClaude本体のNode.jsアプリとは完全に切り離したこと。proxy_pass は使わず、ただの静的HTMLファイル1枚を配信するだけの設定にしたので、名刺ページのアクセスがMulmoClaude本体の負荷に影響することはない。

中身は実際に普段使っている名刺の情報をそのまま移した。ボタンは2つだけに絞った。

• 「連絡先に保存」— クリックするとJSのBlobで .vcf ファイルをその場で生成し、スマホの連絡先追加シートを開く
• 「WhatsApp」— wa.me のクリック・トゥ・チャットのディープリンクを踏むだけ

最初はメール送信ボタンも用意していたが、後で削って情報行(mailto:リンク)だけに縮小した。ボタンは絞れるだけ絞った方が結局使いやすい。

色で少し迷った

配色は最初からネイビーで作っていたが、比較のために白黒版も一度作ってみた。並べて見て、結局ネイビーの方が良いという結論に落ち着き、白黒版は削除した。

地味なハマりどころ

公開直後、このアプリ自体に埋め込んだプレビュー用のiframe内でカードを確認したところ、メールアドレスの表示が記号だけの謎の文字列になっていた。最初は自分のミスかと疑ったが、正体はCloudflareの「メールアドレス難読化」機能(Scrape Shield)だった。ページ内のメールアドレスをスパム避けのため自動でエンコードして表示する仕組みで、通常のブラウザではJSが実際のアドレスに戻して表示するが、このアプリのプレビュー用iframe内ではそのデコード用スクリプトが動かなかった、というだけの話だった。ゾーン全体の設定なので個別にOFFにはせず、実際のブラウザでは問題なく表示されることを確認して終わりにした。

名前のドメインは、こう転がっていく

自分の名前をドメインにした瞬間から、こういう小さいサブドメインを次々に切れるようになった。この後もいくつか同じパターンで増やしていくことになる。

つづく。