🗣️ 背景 # 色々な CLI アプリケーションを作っている。十数個ある。そのリリース作業で、ずっと以下の3つに困っていた。
1. 1回のリリースで触る場所が多い。 昨今の CLI アプリケーションは、バイナリを置いて終わりではない。macOS と Linux、arm64 と amd64 の組み合わせでバイナリを用意し、コンテナイメージを公開し、crates.io などのレジストリに登録し、Homebrew🍺 のレシピを更新し、プロダクトのホームページも作る。1回のリリースに対して、公開先がいくつもある。
2. 同じ情報を何箇所にも手で書き写していた。 バージョン、リリース日、説明、ライセンス。同じ内容を、プロダクトのリポジトリ、Homebrew のレシピ、自分のホームページに、それぞれ別々に書いていた。二重、三重の管理である。当然、情報の齟齬が様々なところで生じるし、更新忘れも結構あった。
3. プロダクトの一覧が、機械可読な形でどこにもない。 どんなプロダクトがあるのか、それぞれいつリリースしたのか。ホームページに載せたくても、プログラムから読める形で集約された場所がないので、結局また手で書くことになる。2の原因でもある。
このうち 1 は、後述するように既存のツールでもそれなりに何とかなる。厄介なのは 2 と 3 で、これは第1次情報がどこにあるのかを決めていないことが原因である。裏を返せば、正となる情報を1箇所に決めて、他はすべてそこから取ってくるようにすればよい。
このようなことを自動化したいなと、これまでずっと思っていたのだが、この度、ようやく目処が立ったので、内容をまとめておく。
🌊 Workflow # 最初に行うべきは、マシンリーダブルなものを第１次情報とすることである。これを tamada/api として作成した。そして、プロダクトの情報は基本的に GitHub で管理し、GitHub 上で管理できない情報のみを tamada/api に置くことにした。加えて、GitHub Pagesで、擬似REST APIとして、さまざまな情報を公開することにした。基本的に情報を取得させるだけであるため、GET メソッドのみ対応として、JSON を様々な場所においておくことで対応した。具体的な内容は、https://tamada.github.io/api/ を参照されたい。ホームページの更新や Homebrew なども、すべてこのリポジトリの GitHub Pages から情報を取得することにする。
背景 # ホームページ上にさまざまな情報を載せるようになると、掲載すべき情報がさまざまな場所に点在するようになる。 それを一つの場所で管理するためには、REST APIやGraphQLなどのCMSとは異なるサービスが必要になる。 REST APIやGraphQLサーバを構築するには、費用がかかる。
費用をゼロに近づけるためには、自分でサービスを運営するか、格安のサービスを探すしかない。 自分で運営するには、運営コストが無視できないし、格安のサービスも昨今の事情からいつ値上がりするかがわからない。
一方で、主に行いたいことは情報の取得のみである。 RESTの GET、GraphQL であれば query のみであり、POSTや mutations は行わなくても問題はない。
GET のみであれば、HTTP サーバにファイルを置いておくだけで REST API として扱えるようになる。 データを JSON で用意しておき、必要な JSON の内容を適切な場所に index.json として配置する。 そのディレクトリをエンドポイントとして公開しておけば、擬似 REST API の完成である。
FauxREST # 擬似REST APIを作成するツールである FauxREST を作成した。 このツールは、与えられたディレクトリ内の JSON ファイルを特定のルールに従って分割し、 所定の場所に置くことで、擬似REST APIのファイルを出力する。 このツールを使って、API を構成し、そのAPIから情報を取得して必要な情報を取得するよう変更すれば、 データと表示を分割できる。
ホームページのデザインを更新した． # 以前使っていた cayman-hugo-theme はそれなりに気に入っていたものの、 2023-01-03 にアーカイブされた。 それ以降、新しいデザインにするために色々と試行錯誤したものの、なかなかしっくりくるデザインが見つからなかった。 Astro を試したり、Zola も試したりもしたものの、最終的には Hugo に戻ってきた。 で、Hugo のテーマの中で、Blowfish を採用することにした。 とあるサイトで使っているテーマであり、色々な設定項目もあるので、まあ良いかなと思って使ってみると、それなりに良いかなと言う感じ。 カード状にブログ記事やプロダクトを表示できるのも良い。
次にやりたいこと # Hugo mod を使って、このサイトをモジュール化したい。 これで、各プロダクトからも同じテーマを使えるようになる。 partial の一部を書き換えたりもしているし、、テーマのアップデートがあったときに、各プロダクトのサイトに反映させやすくなる。 プロダクトのリリースにより、自動的にプロダクトの日付を更新するようにしたい。 GitHub Actions でこのサイトを更新しているなら、プロダクトのリリース時に、そのプロダクトのページの日付を更新するようにしたい。
Getting ways of the version defined in pom.xml Constant Property Package Module What the case in the use of native-image? Result of Measurements Summary References Getting ways of the version defined in pom.xml # Java 17が出たことだし，いい加減に Java のモジュールシステムを本格的に使いだそうとしている． 最近のJavaの自作ツールは一応モジュール対応にしたつもり（pochi，vhcなど）．
で，ビルドツールは Maven を使うことが多いのだけど，pom.xml で設定したバージョン情報をアプリケーションからどんな情報で取得できるかを確認してみた．
次の4つの方法に分類できる．
Constant: 自分でバージョンの文字列をString型リテラルとしてソースコードに書き込む． Property: src/main/resourcesにプロパティファイルとしてバージョン情報を置いておく． Package: MANIFEST.MFに書かれている Implementation-VersionやSpecification-Versionのいずれかを利用する． Module: ModuleDescriptorのversionメソッドから利用する． それぞれの分類を独断と偏見で４段階で評価してみた（1が良くて，４が悪い）．
とあるユーティリティプログラムを作成しようと思ったものの，どのような言語で作成しようかと悩み中． 希望としては，ワンバイナリが生成可能，ジェネリクスあり，ストリーム処理，あたりが扱えると嬉しい． また，クロスコンパイルしたいし，書きやすい（EtoW; Easy to Write）言語であると嬉しい．
で，まとめてみた．
Language One Binary Generics Stream Cross Compile EtoW Java GraalVM OK OK Hard OK Go OK 1.17- No OK OK Rust OK? OK ??? OK? No Node.js ??? ??? OK N/A OK Python ??? OK? ??? ??? OK Kotlin OK? OK OK OK ??? Java は GraalVM を使うとバイナリを作成できるけど，面倒． GraalVM を使ってもクロスコンパイルは難しいんじゃないかな． GitHub Actions などを使えばクロスコンパイルはできそうだけど，面倒だなぁ．
Go は概ね良いのだけど，ストリーム処理が行えないのが悩みどころ． ジェネリクスも出たばかりであまり書き慣れていない． 例外処理はなくてもいいや．
Rust も良いのだけど，コンパイルを通すのに一苦労な点で，簡単なユーティリティを書くのにはそぐわない気がする．
Node.js，Python はよく知らない．
ちょっと調べてみると Kotlin がネイティブコードを生成できるらしい Kotlin も結局は Java バイトコードに変換するはずだから， GraalVM と何が違うのかはよく分からないし，これまでに書いたことないけど，書いてみようかな．
ホームページのデザインを更新した． # ふと思い立って，ホームページのデザインを更新してみた． 作成したプロダクトのデザインは cayman-hugo-theme に統一していたので，個人ページも同じテーマを採用してみた．
雑感 # 以前使っていたHugo Swiftに対して思っていた要望が解消されたかな？
トップのサイン波のアニメーションを変えたい． -> なくなった． ハンバーガーメニューが気に入らない． -> なくなった．
