ロックなクロック crock コマンドをつくったぜ
こう…！
もともと Rust の勉強としてつくり始めたのだけど、一通り書いてみてから「ついでに Go も触ってみよう！」ということで最終的には Go 製になりました。
リポジトリ：
お使いのマシンですぐにご利用いただけます！
Mac:
brew tap mirumirumi/crock
brew install crock
Linux:
wget https://raw.githubusercontent.com/mirumirumi/crock/main/crock.sh -P /tmp/
sh /tmp/crock.sh
Windows:
Invoke-WebRequest https://github.com/mirumirumi/crock/releases/latest/download/crock.exe -OutFile $env:temp\crock.exe # it would be `C:\Users\[user]\AppData\Local\Temp`
# Move it anywhere you want!
最後に crock コマンド。
crock
今回の目論見のひとつに「apt や yum で簡単にインストールできるようにするのをやってみる」というのがあったのですが、結果としては諦めた形です。こんなに奮闘したのは久しぶりだったのですがあえなく敗退しました。後ろでちょっと書いています。
Windows のインストールもなんやかんやかっこつけようとしてますが、これも実は choco と winget に挑んで負けた結果です :(
できたこと(😸)、できなかったこと(😿)
😸：Rust と Go の練習
サーバーを書くとき用の言語として新しい手札を加えたくて、ここ最近ほそぼそと Rust の The Book を読んだり写経したりしていました。自分は新しい技術要素に触れるときは「必ずそれをメインで使って実リリースするものとして最後までつくりきる」という信条でやっているので、今回もその一環でつくり始めました。
ある程度書き終わったところで、
- 自分の素養レベルに対して難易度が高い
- 少なくともいま以降数年間の自分には必要ない言語に思えた
などがありました。
現実的に仕事で使えるレベルで習得を目指していたため、「学習に長い時間がかかってもいいから最高のパフォーマンスを叩き出せる言語を選ぶ」というよりは「言語自体はシンプルだけどチーム開発のしやすさなどで色々な課題解決が見込めそうなものを選びたい」という感じでした。
これは（少なくとも初学者が感じる感想としては）まさに Rust と Go のことに思えます。
どちらもスクリプト言語に比べたらかなりの実行速度やメモリ効率のよさがあり、静的型付けによる堅牢な実装も期待できます。
Go を実際に書き始めてみると、チュートリアルやらなんやらを読み始めた初日にはとりあえず手は動かせる状態にはなります。文法含めとにかくシンプルであることを柱にしているらしく、なるほどこれはこの書きやすさが多くの人を惹きつけているのだなと思いました。
いまはもっとたくさん Go を書きたい欲にあふれていて、とりあえず次は Python で書いていた Lambda を Go に書き換えてみようと思っています。AWS SDK の雰囲気にも慣れたいし、コールドスタート周辺のパフォーマンスがどれくらい変わるのかもすごく気になっています。
HTTP サーバーもかなりシンプルに書けそうなので、サーバーレスは使わずに Go Only + App Runner とかもかなり楽しそうです。
Rust は… またいつか触ってみます :)
😸：CLI ツールをつくってみる
なにかしら CLI アプリケーションを作ってみたいと昔から思っていたのですが、結果的にはこれも達成できたことになります。
Rust や Go で書く以上なにもしなくてもこれは自動的に満たされる項目ではあるものの、「ちゃんとバイナリとして使ってもらえるようにする」というところまでできたので個人的には満足しています。
標準出力というものに今まであまり縁がなかったので、「こういうことしたいときはこういうことをやってるのね～」という学びがたくさんあって楽しかったです。実は色の指定とかもできます。
OS ごとのパッケージマネージャーで手軽にインストールできるようにするのもこの延長線上にあったわけですが、その結果は次の次以降の項です。
😿：アナログ時計の描画
もともとはアナログ時計を描画する作戦だったのですが、各 "針" ごとのアスキーアートをつくりはじめて開始 5 分ぐらいで心が折れました。
短針・長針・秒針の各 60 パターンをそれぞれ用意すればいいだけ（60^3 ではなく 60*3）ならなんとかなりそうかなと思っていたのだけど、「よく考えたらそれぞれの針はアナログ的にちょっとずつ動くじゃん」となり、「それができないならただのデジタル時計じゃね？」からの「じゃあ表記ももうデジタルでよくない？」というオチです。実にアホです。
天才のひとはひょっとしたら針の位置を示す 0 ~ 59 の値を与えられるだけでその針のアスキーアートを自動生成できてしまうのかもしれません。僕には一生かかっても無理そうですが。
😸：brew でインストールできるようにする
brew は各パッケージマネージャーの中で最も簡単にオリジナル公開できるもののひとつだと思われます。
いわゆる「本家」のリポジトリに登録するのは色々な意味で難しいですが、個人リポジトリとしての公開（Tap という）はわりとすぐにできました。
パッケージ管理としての Ruby スクリプトとそれを格納する GitHub リポジトリが必要で、これはプログラム本体のリリース時に自動的に更新される仕組みにしています。
記事の冒頭で紹介したインストールコマンドが
brew tap mirumirumi/crock
brew install crock
のようになっていましたが、この 1 行目は「本家じゃない非公式リポジトリをパッケージ検索候補に追加するよ」みたいなことです。
削除もいつも通りで簡単なので（brew uninstall crock）、Mac の方はぜひお試しください！
😿：apt や yum 用のパッケージング
今回いちばん悔しかったのがこれでした。
まず関係しそうな文献を探すのがとても難しく、関係ありそうなものが見つかってもそれぞれの断片的な情報を繋とめるこちらの知識が明らかに欠如しているために一向に作業が進みませんでした。
丸一日ググるだけでなにも手を動かせないという状況が久しぶりで苦い思いをしましたが、まあこういうのっていつか役に立つときが来たりするじゃないですか。 …来てね？
苦戦度の体感的比較は次のようなものでした：
- Go による本体の実装：1
- brew のパッケージング：2
- rpm (
yum install用)のパッケージング：5 - choco/winget のパッケージング：10
- debian (
apt install用)のパッケージング：500
Debian、難しすぎる。もうやりたくない。
rpm 用のは完成まであと一歩のところまでいけたのですが、ビルドしたバイナリをどうやっても実行できず一旦中断しました。こっちはリフレッシュして再挑戦すればいけそうな予感はあります。
まあ結局 Linux 系はシェルスクリプトでお茶を濁すことにして、Windows は「ただでさえこんなツール使う人おらんだろうにわざわざ Windows に入れるなどという奇怪な人種がいるわけない」として実行ファイルをそのまま使ってもらう形にしました。PowerShell 魔界すぎる。
たぶん Zenn の読者層的に本記事をお読みの方のほとんどが Mac だと思われるので、brew だけはちゃんとできたのはせめてもの救いでした。
おわりに
最近どうにも負けが込んでいる気がします。
自分は「泥沼にハマるくらいならある程度の形にしてとりあえず動くものを出そうよ」派なのですが、これは徹底しすぎると「諦めグセ」ともいえる状態になってしまいます。反省点を書き出すところまでは十分できていると思うけど、これをほったらかしにせずいつかちゃんと回収しないといけないですよね。
さて、次はなにをつくろうかな！（回収しない）
Discussion