BBS（Bulletin Board System、電子掲示板）を導入
Debimate（本ブログ）に、BBS を導入した。技術的には、giscus/giscus を利用している。GitHub Discussions にコメントが記録されるため、投稿には GitHub アカウントがいる。アカウントを要求する仕様は、荒らし防止に役立つと考えている。なお、コメント投稿で再デプロイが走るため、リアルタイム性はない。
Weeknotes と BBS の構成は、私が10代の頃の個人サイトから強い影響を受けている。当時は、雑多な近況を公開して、BBS で好き勝手に交流していた。SNS が流行る前のインターネット文化だ。X（旧 Twitter）に比べれば、牧歌的な交流スタイルだった。
今回は、狙って Weeknotes と BBS を導入したわけではない。点が線になる感じだ。WordPress から GitHub Pages への移行、ブログを自己ブランディングの道具として再活用、X への拒否反応、LLM によるサイト構成変更の容易化……色んなものが重なって、段階的に BBS へ辿り着いた。果てして書き込みが増えるのだろうか。
ブロックチェーンの応用先としてのタイムカプセル
私の悪い癖だが、新しい技術概念を勉強している最中に、他のことに夢中になってしまう。試験勉強中に部屋の掃除を始めるのに近い。この悪い癖から生まれた成果物がブロックチェーン環境構築コマンドの block だ。先週の Weeknotes に詳細を書いてある。
ブロックチェーンの特徴が掴めてくると、私は「分散ノード」「改ざんが検知できる」という特徴から、「そこそこ大事なデータを皆で管理するシステム（インフラコストを自分だけで賄わないシステム）」を構築できないかと考えた。
最初の閃きは、Wikipedia だ。Wikipedia は寄付を何度も募っている。分散ノードでテキスト管理すれば、インフラコストを自分だけで賄わないシステムとなり、寄付への依存を減らせるのではないかという発想だ。私の理解が甘かったのだが、Wikipedia はインフラコストよりも人件費の負担が重いらしく、しかも本案は既に前例があった。
次に考えたのは、政治的な公文書の管理だ。発想は悪くない。問題は端的に2つあり、公文書の管理に関わる立場ではないこと、最初から誤った内容が登録されていると無力になるということだ。最後に発想したのは、タイムカプセルだ。需要は少ないが、悪くはない。時限式の暗号化として Timelock Encryption があり、10年後に復号できる何かを分散ノードで管理することが可能だ。特定のサービスが10年後も生き残っているかどうかを心配する必要がなくなる。その一方で、分散ノードを維持できるか、という問題が生まれる。なお、ここまで考えると「ブロックチェーンである必要はあるのか」という別の問題が出てくる。
タイムカプセルを作って何が嬉しいのか、という意見は認める。この案を自由に実装してもらっても構わない。
gup が topgrade のバックエンドに
gup は go installしたバイナリを更新するツールであり、私が開発した OSS の中で一番成功している。そんな gup が、topgrade で利用されていた。topgrade はあらゆるツールを更新するコマンド。go 製バイナリの更新に gup が利用されているようだった。ありがとうございます。なお、ChatGPT にエゴサさせて発覚した。
ネットの海でジャンクを漁る
ネットで色々漁っている。
例えば、Internet Archive のようなサイトを閲覧している。Internet Archive には、あらゆるデジタルデータが保存されている。ソフトウェア、映画、本、ライブ録音、ネット黎明期のテキストデータなどがある。このようなアーカイブサイトは、基本的に海外運営なので日本の情報が薄めだ。しかし、電化製品（日本製）の説明書が異様に揃っていたり、日本の PC ゲームが残っていたりする。なお、文化保存の観点でお目こぼしを貰っているだけで、このようなサイトは複数の権利を侵害しているケースが大半だろう。コンテンツのダウンロードは違法となる可能性があるので、推奨しない。
私は、古いモノをチラ見して楽しむ癖がある。プログラミングの勉強をし始めた時、UNIX v6 のコードを読んだりした。音楽も、70’s ぐらいまで遡った。予め断っておくと、体系的に歴史を紐解いている訳ではない。断片的にチラ見して、当時の状況を把握したつもりになって薄い知識欲を満たすのだ。その過程で、特定シリーズのモノを収集する傾向があったが、最近は物理的な制約に直面して収集癖が鳴りを潜めた。家が狭いのだ。
この手のサイトは情報が整理されておらず、当時の状況を説明する文章もない。「アーカイブサイトに、コンテンツ単位で熱量の高い文章が書かれていればいいのに」と思いながら、データを漁っている。この行為に生産性はない。YouTube Shorts を見るのと同等。最近急に始めた。
VOW WOW の再評価
80’s に登場・活躍した邦楽バンドの中では、ヴィジュアル系バンドが好きだ。私の中では、X JAPAN、DEAD END、Gargoyle、AION、BUCK TICK が殿堂入りポジション。他には、ボーカルから DIO の影響が感じられる ANTHEM を愛聴していた。聖飢魔II、SHOW-YA なども聞くが、キリがないので割愛する。そのようなバンドと比較して、VOW WOW に対する私の評価（2010年頃の評価）は、さほど高くはなかった。ブルージーであり、スラッシュメタルのように激しくはなく、歌唱と演奏は上手いがハマりどころがなかった。しかし、最近ふと気づいた。「VOW WOW は、Rainbow（Ritchie Blackmore）の影響を受けていないか？」と。
私は二つの虹（もう一つは L’Arc～en～Ciel だ）を聴き込んでおり、VOW WOW 初期の三作はキーボードとギターから Rainbow や Deep Purple の影響を感じ取れる。“MASK OF FLESH (Masquerade)“にいたっては、「Rainbow のカーボンコピー」と評されるレビューがあるぐらいだった。この事実に気づいてから、VOW WOW をリピートし続けている。不思議なことに、日本人がギターとキーボードの掛け合いを行うと、演奏に遊びがあるはずなのにタイトさを感じる。日本人らしさを感じるプレイといれば、Who do They think We are ? -A Tribute to Deep Purple From Japan に収録されている Burn であり、色んな元ネタを踏まえた完コピ演奏である。
今回は、音の捉え方を変えただけで、VOW WOW への評価が大きく変わった。評価軸、大事だね！
truss の利用者から機能要望が来た
truss は、端的に説明すれば、画像変換 CLI・サーバー・WASM である（紹介記事はこちら）。いつの間にか Drupal（WordPress のような CMS）モジュールのバックエンド候補として検討されているようで、機能追加要望があった。不思議な話でもあり、PHP の GD や ImageMagick を差し置いて、何故 truss が選ばれているのか。ネットで検索したら、答えが出てきた。
機能追加の依頼者は Drupal GovCon（2026年）で発表しており、「Drupal モジュールが高速な Rust 製 CLI を 管理して直接起動し、結果を静的成果物として保存すればよい」旨の考えを示していた。truss も Rust 製 CLI であるため、この方の戦略とマッチしていたのだろう。ImageMagick は機能的に圧倒的に優れているが、配布が少し面倒だ。単一バイナリではなく、かつランタイム環境によって考慮すべき事柄があるため、ユーザーが戸惑う場面が増える。Rust 製 CLI であれば、バイナリﾎﾟﾝｯが簡単にできる。
…..というゲスパーをする必要も実はなく、具体的な説明が truss を利用しているライブラリの説明に書かれていた。
和訳：マネージドホスティングでは、GDのWebP/AVIFサポートやImageMagickが全く含まれていない状態で出荷されることが多く、どちらかをインストールするにはサポートチケットを発行するか、そもそもインストールするオプションがないのが一般的です。Better Image Optimizerはこのギャップを回避します。trussモジュール独自のコード内でバージョンとSHA-256によって固定された単一の静的リンクバイナリを取得し、それをプライベートファイルシステムに保存し、Symfony Processを介してシェルから実行します。