@kyanny's blog

My thoughts, my life. Views/opinions are my own.

ふと GitHub の通知を IRC クライアントで読んだら便利かもしれないと思い、ゴニョゴニョやり始めたら相当な時間を溶かしてしまった。けどだいたいできた。

最終的に、

  • ngircd
  • limechat
  • octokit + net-irc

という感じの構成になった。

ngircd は Listen 127.0.0.1 にしてるので IRC 部分はローカルホストで完結している。

ngircd が brew services で起動できないとか通知を取ってきて irc に投稿するスクリプトの cron を仕込んでないとか多少足りないところはあるが、本格的に使い始める前に「本当に IRC クライアントで通知なんて読むか?」という問いに答えなければならない。

そもそものモチベーションは、「通知溜まりすぎ。大半は見逃しても構わないようなやつなのでどんどん既読になって欲しい、けど念のためどこかにログは残ってて欲しいしざっと眺めて目についたやつは見たい」という感じ。

ログを残したい、というのとざっと眺めたい、が重要な気がしている。通知は一度既読(done)にしてしまうと更新があるまでどれだかわらかなくなる。操作ミスが非常に痛い。GitHub の Web UI は一覧性は高くない。ページングは遅すぎる(そういえば昔は AutoPagerize なんてものもあったな)。延々とスクロールバックできるチャットルームに垂れ流しておきたい。

なぜ Slack ではないのかというと、単純に会社の Slack ワークスペースへの API アクセス権限が無いため。Incoming Webhook が一個あれば済むのに……と思いつつ 2021 年にもなって IRC クライアントプログラムの書き方に四苦八苦するのは徒労もいいところだが、IRC bot の類をろくに書いてこなかったので良い経験にはなった。

せっかく自分が完全に自由に使える IRC サーバがあるのだからと、通知アイテムが属するリポジトリごとにチャンネルを作ってリポジトリごとに通知がまとまるようにしてみたり、大事な通知は Web UI に残っててしっかり注意を払って確認できるように IRC に流して既読にする通知をタイプ(reason)でフィルタしたりしてみた(とりあえず team_mention のみ垂れ流し既読)。

本当は deno で書き始めたが、IRC チャンネルから QUIT すると例外が発生してプログラムがクラッシュする問題の解決方法がわからず(結果的に接続は切れるのだが)、いろいろ、本当にいろいろ試行錯誤した結果、全部 Ruby で書いた。最初は gh api を組み合わせたりしていた。