同じことを考えている方がいて嬉しかった
先日、Feedlyで登録フィードを斜め読みしていたところ、「ターミナルを自作したら、1日のコミット数が500を超えて、生産性がバグった話」という記事を読みました。
ちょうど同じ頃、私も似たような壁を感じていました。向いているベクトルは少し違いますが、以下の動画のように、「自分から探しにいかなくてもよい」仕組みを作っていたところです。
「同じようなことを考えている方がいたんだ」と嬉しくなり、この記事を書いています。
並列化すると、探す時間が増えていった
私の場合、複数のリモートサーバーにSSH接続し、それぞれの環境でtmux、git worktree、Codexを使って並行作業することが増えてきました。
当初は、SSHのRemoteForwardでローカルポートをリモート側へ転送し、Codexのnotify payloadをそのポートへ送る構成にしていました。ローカルPCが payload を受信し、OSのデスクトップ通知を表示する仕組みです。
この方法は、並列で動かすCodexが少ないうちはうまく機能していました。
しかし、並列数が増えるにつれて、
「これは、どのSSH接続先だろう...」
「どのターミナルだろう...」
「どのタブ(tmuxでいうところのwindow)だろう...」
と、通知元を探す時間が増えていきました。
作業自体を並列化してみたら、そのぶん対象を探したり切り替えたりするコストが大きくなっている。これが段々とストレスになってきました。
通知から対象のpaneを直接開く
そこで、OS通知の代わりに自作のポップアップを表示し、そこへ「開く」ボタンを追加しました。
目標は、「開く」を押したら、対象のターミナルに切り替わり、該当するtmux paneが表示されることです。
ターミナルを、私が普段使用しているKittyに限定することで、なんとか意図したとおりに動かせるようになりました。
最初は「これで解決だ〜」と素朴に喜んでいました。
今度は通知が積み上がった
ところが、今度は別の問題が出てきました。
通知が増えると、ポップアップが次々に積み重なってしまうのです。
順番に処理していけばよいのですが、未読の資料がデスクの上に積み上がっているようで、どうにも落ち着きません。
さらに、一覧性もないため、
「いま、どれが待ち状態なのか」
「あの作業は、いまどういう状況なのか」
が分かりません。
その結果、結局はターミナルを巡回し、それぞれの状況を確認することになってしまいました。
Codexの稼働状況を一覧にする
この時点で、通知を受け取ったときに、該当するpaneを開くところまではすでに実現できています。
それならば、現在開いているターミナルとSSH接続先を調べ、各リモート環境で動作しているtmux上のCodex paneを一覧表示し、それぞれの進行状況を表示すればよい。そう考えました。
実現には、リモート側で動かすヘルパースクリプトもいくつか必要になりました。
そこで、必要なスクリプトがインストールされているかを確認し、存在しなければ「リモートにインストール」できるようにするなど、補助機能も整理しました。
さらに、Codexが動いているカレントディレクトリからGitブランチを取得したり、ghコマンドが利用できる場合には、関連するIssueやPull RequestのURLをブラウザで開くボタンを追加したりしました。
もちろん、これらの実装はAIに任せています。
名前について相談したところ、「これはサーバー横断のプロセスモニターのようなものだから、codex-monitorがよいのでは？」と言われたので、そのままcodex-monitorという名前にしました。
探すストレスがなくなった
いまのところ、かなりうまく動いています。
以前感じていた「ずっと何かを探している」というストレスがなくなりました。また、対象のブランチやIssue、Pull Requestをすぐ確認できるため、「これは何の作業だったっけ」と文脈を思い出す時間も短くなりました。
結果として、並行作業時の切り替えコストを大きく抑えられています。
使っていて少しでも気になる点があれば、その場で改善しています。そうして、少しずつ自分の手に馴染む道具になってきました。
ただし、公開する予定はありません
ところで、私は冒頭の記事を書かれた方ほど志が高くないため、このcodex-monitorを公開する予定はありません。
というのも、このツールは、
- OSはLinux、さらにいえばUbuntuとX11を前提としている
- ターミナルはKittyを前提としている
- KittyやSSHの起動時に、ターミナルを識別するための特殊な処理が必要になる
- 接続先を
~/.ssh/configで管理し、RemoteForwardを設定している
といった、私個人の環境に強く依存しているためです。
それでも当初は公開を考え Go で実装して可搬性を高めにしようと思っていた時期もありました。
しかし、ここに挙げたもの以外にも、私が忘れているだけでさまざまな前提条件があるはずです。一般的な環境へ導入するには、すこし敷居が高いツールになっているな、と思った時点で公開は諦めました。
つまり、同じことを考えている方がいて嬉しかった
というわけで...
本当にただ、「同じようなことを考えている方がいて嬉しかった」というだけの記事です。
そして、自作の仕組みをきちんと一般化し、公開されている元記事の方を尊敬します。