時のオカリナリメイク（Nintendo Direct）
時のオカリナのリメイクが待ち遠しい。リンクの服は手編みっぽかったが、一体コキリ族の誰が作ったのだろうか。ここまで現代化されたグラフィックの中でコッコいじめをすると、果たしてどんな恐ろしい形相でコッコが飛び交うのだろうか。
子供の頃に NINTENDO 64 を持っていないのに、時のオカリナだけを買ってもらった。N64時代の黒を基調としたパッケージは、小学生が見ても格好良さを感じたものだ。オープニングで沈む月をバックにエポナと突き進むのも、印象的だった。当時プレイしたゲームの中では難易度が高く、ジャブジャブ様、水の神殿で詰まった記憶がある。死亡回数は18回だ。ムジュラの仮面が個人的な本命なので、そこに繋げるために売り上げへ貢献しなければならない。
20～30年もあればゼルダがリメイクされると考えれば、私が70歳になる前にはもう一度リメイクされる可能性がある。老後の楽しみができた。
gup が Meta Package Manager に組み込まれた
Topgrade に続き、gup が meta-package-manager に組み込まれた。
mpm は、以下の機能を実現するために gup の幅広い機能を使っていた。
- 個別更新：
gup update <name>を実行 - 全更新：
gup updateを実行 - インストール済み一覧表示：
gup list --jsonを解析 - 最新ではないコマンド表示：
gup check --jsonを解析 - 削除：
gup remove --force <name>を実行
json 出力機能が有効に使われる日が来るとは、思いもしなかった。json といえば、最近 jsonize コマンドを作った理由は「コマンド同士で連携するには、パイプか json が必要。しかし、json 出力がないコマンドもある」と考えたからだ。grep や awk、sed を駆使すれば jsonize は不要なんだが、そのワンライナーを書くのが厳しい人に向けて作った。とは言え、ワンライナー作成自体、最近は LLM 任せにしがちだ。
Wasm は便利な中間表現
ncruces/wasm2go を眺めていて、Wasm を中間表現として C/C++などの既存資産を CGO なしの Go パッケージに組み込む案は、実用的だと感じた。特段新しい案でもない。「GoにおけるFFIのこれまでとこれから（Go Conference 2026、goccy 氏）」 でも似た内容が触れられていた。例えば、SQLite は利用しているシステムコールが少ないため、Wasm to Go しやすい。
オリジナルコードを参照させながら LLM に他言語版を実装させる案もあるが、機械的に置換した方が安心。トークンを浪費しないし、誤解釈によるバグを埋め込まない。個人的に試してみたいのは、NKF（Network Kanji Filter） の Go 化である。NKF は、文字コードや改行コードを変換するツールで、昔の印象だと精度が良かった。作業としては NKF を Wasm to Go して、型やら良い感じの API を独自設計して提供する必要がある。
文字コードの領域は、Go において決定版ライブラリが恐らく存在せず（ないよね？）、メンテ状況が怪しいライブラリが多い。文字コードは沼なので、ライブラリ開発自体が難しい。その結果として、「Excel を CSV として保存すると Shift-JIS になるから、UTF-8 に変換しようか」みたいなエッジケースだけ個別対応する羽目になる。2022年頃から文字コード自動判別ライブラリが欲しかったので、今度文字コードで苦しんだらライブラリを開発するかも。
5年ぶりに Neovim 環境を整えた
スッとコードを読むときのために Neovim 環境を作った。私は、組み込み時代は画面全部をターミナルで覆って開発するスタイルだった。バックエンドエンジニアになってから、Visual Studio Code を使うようになり、Neovim を使う機会がなかった。コードリーディングには Neovim が便利なので、環境を準備しておいた。書くなら VS Code、読むなら Neovim の使い分け。VS Code は最近やや重く、機能が増えすぎた。
昔はターミナル背景を透過させたり、色んなプラグインを試したりしていたが、必要な機能だけを設定した。設定いじりに熱中すると、肝心の開発が進まない。
比較表を書くと、改善する羽目になる
nao1215/jsonize がある程度完成したので、 記事を書いたり、類似ツールとの比較表を書いたりしていた。
比較表は厄介だ。サボりがバレる。脳内でイマジナリー上司に詰められる。
詰められる例
- 私 「A、B、C の項目に関して、A と C は競合より優れています」
- 上司（非実在）「何故 B で負けているんだ？勝つ方法は？」
- 私 「一応、こうすれば勝てますが…」
- 上司（非実在）「方法があるなら、なぜ勝つまでやらないんだ？」
- 私 「改善してから、再提出します」
上記の会話例は創作だが、似た会話をした経験は何度かある。先輩からは「比較表を書いたら、全部 ◯ にしないと駄目だよ。☓ があると何か言われちゃうからね」と教えてもらったものだ。性能改善に繋がるなら問題ないのだが、どうしようもない場合は言葉遊びや隠蔽工作みたいな方向に倒れる可能性もある。
jsonize は比較表を導入したせいで、性能改善する羽目になっている。例えば、Python 製ツールに Go 製の jsonize が速度で負けている部分があった。原因は、膨大なパーサーデータを起動時に読み込んでいたこと。読み込みタイミングを変更によって条件次第では7倍以上高速になった。
最初は「ありのままの姿（比較表）を見せればいいか」と考えていたのに、表をレビューしたらお化粧したくなってしまった。負けず嫌いとは違うのだ。なぜベストを尽くさないのか、と指摘された感じがする。巧遅拙速が良いと教えられて育ってきたが、結局拙いものは許されない。
パフォーマンス測定（ベンチマーク）で使う himorime を作った
jsonize の比較表を作っている時に、ベンチマークスクリプトが必要になった。実行時間やメモリ使用量などのパフォーマンス測定は、様々な OSS で必要になる頻度が高く、かつ劣化にはすぐ気づきたい。OSS 間で品質基準を統一したかったので、ツール化することにした。名前は、himorime（火防女）だ。
himorime は、E2E ツールの atago の姉妹ツールとして設計している。E2E は atago、パフォーマンス計測は himorime と責務を分けた。どちらもコマンドをテスト対象としている。atago に himorime の機能を統合すると、atago 自体の設計が壊れ始めるリスクが合ったので、素直に別ツールとした。現在はバグ潰しの最中で、それが完了すると私の OSS に himorime が組み込まれていく。最後に、紹介記事を作成する予定。
火防女は、Demon’s Souls から借用した。atago（愛宕）が火伏せ（防火）に関係するので、火から連想ゲームした。Demon’s Souls の篝火は拠点（ベンチマーク）っぽいし、ベンチマークを見ると性能改善したくなる点が火防女によるレベルアップに似ているなと考えた。himorime の最高な点は、GitHub に同名リポジトリが存在しなかったこと。
ちなみに、開発初期は「弥彦（yahiko）」という名前だった。彌彦神社は、荒廃した土地を再生させる力を持つとして崇められているらしい。ソフトウェアを健全に保つには、ピッタリの名前だと考えていた。その一方で、弥彦はるろうに剣心のキャラ名でも利用されているし、彌彦神社は恋人を別れさせるイメージしかない。夕飯の準備中に、ふと「かぼたん（火防女の愛称）でいいのでは？」と急に思い浮かんだので、改名した。