普段の Git の操作は、なるべく使っているエディタや IDE の機能に任せよう、と思いつつ、なんだかんだと込み入ったことをしようとするとターミナルを開いて git コマンドを直接打つことになってしまっている。

最近は同時に扱うリポジトリが増え、さらに複数のブランチを並行して開発を進める、というケースがにわかに増えてきている。これによって最近感じていた課題が、「あの作業はどのブランチでやっていたか」である。特にちょっと小さなコミットを積んですぐ別のブランチに移る、ということをやっていると、それぞれのブランチの名前を部分的に覚えておくことすら煩わしく感じるようになってしまった。

ブランチを切り替えるとき、普段遣いしていたのは以下のようなコマンドである。

git branch | grep -v HEAD | sed -e \'s/* /  /g\' | string trim | fzf-tmux | read -l result; and commandline "git switch $result"; and commandline -f execute

fzf でローカルブランチをリストアップしてその中から選ぶ、というものでシンプルで使い勝手が良い。ただ、普通に git branch しているので、リストがブランチ名の昇順になってしまう。ソート指定で最新コミット順にするという手もあるが、直感的に並ぶかというとそういうわけではない、というかゆいところに手が届かない感じに悩んでいた。

で、ブランチを頻繁に切り替えるときに代用するようになったのが git switch - である。これは直前のブランチに戻るコマンドで、最近の自分のユースケースにかなりマッチしている。時々2つ前のブランチに戻りたいときもあり、そういうときは git switch @{-2} と打ったりしていた。

これを繰り返していると、最近利用した順に並んでいるブランチ名から選択して切り替えたい、と思うようになったので、そういう function を作ってみた。

https://github.com/risou/config/blob/aee46efc0237b961236c727af868126cc8723973/config.fish#L114-L153

最初は git switch @{-n} を 数十回繰り返す、みたいなことをしていたが、当然これだと遅いので、一気に対象を取得しようと git reflog の結果からブランチ切り替えのログを抽出して、ブランチ名のリストを得るという方向に切り替えた。

これによって、「いくつ前のブランチに戻りたいか」がわかっているときはもちろん、少し曖昧なときもリストを見て名前から判別できるようになった。

使い勝手に問題がないかや速度面に問題がないかなどは、これから使っていく中でチューニングしていく予定だが、最近気になっていたことを解消するものを作れたことに満足している。

ここ数年、ウィンドウマネージャとして yabai というツールを使っている。
yabai が本領を発揮するためには System Integrity Protection を無効にする必要があるけれど、プライベートの環境も仕事の環境もなるべく同じに揃えておきたい気持ちがあり、会社から貸与されている Macbook の SIP を無効化しようとは全く思わないため、 SIP を無効化せずに使っている。
ところが MacOS Sequoia にアップデートして以降、少なくとも SIP が有効な環境ではウィンドウを別のスペースに移動させることができなくなった。

これまではスペースを大量に使って、スペースごとに最大でもウィンドウは2つ、といった運用をしてきたけれど、先の問題と作業環境のディスプレイの配置を変えたことが重なって、ウィンドウの管理方法が変わってきた。

最近は同時に使うスペースの数を少し減らして、代わりに1つのスペースに3つ以上のウィンドウがある状態で yabai の zoom-fullscreen を多用している。
また 4K 以上の解像度があると、3つ以上あるウィンドウの中から任意の2つを左右に分割したり、 2x2 の4分割にしたりという運用をすることもある。

zoom-fullscreen は yabai 上で managed (= not floating) なままで使うことができるが、2分割や4分割で使うためには floating にする必要がある。すなわち yabai において managed=off にする必要がある。
（本来的には、そのスペースにウィンドウが2つしかない状態にすることで yabai が勝手に左右に分割してくれる、という状態が望ましいし、4分割においても概ね同様のことが言える）

で floating の ON/OFF を頻繁に切り替えると、ウィンドウのフォーカスを切り替えるときなど、ふとしたときに期待する操作が行えない、ということが発生する。これは floating なウィンドウは yabai に manage されていないことに起因しており、アクティブウィンドウが floating なときに yabai -m window --focus east などが使えないため、他のウィンドウの選択が少々面倒になる。

ということでアクティブウィンドウが floating かどうかをいつでもわかるようにしたい、という動機で yabai, skhd, JankyBorders の設定を色々いじってみた。

具体的には、アクティブウィンドウがどれかをわかりやすくする JankyBorders の色情報を切り替えている。 yabai managed なウィンドウであれば緑に、そうでなければ黄色になるように設定した。

そのウィンドウが floating であるかどうかを判定したいタイミングは、大きくわけて以下の2種類になる。

• アクティブウィンドウの floating ON/OFF を切り替えたとき
• ウィンドウのフォーカスを切り替えたとき

前者については、該当するショートカットを実行したときに borders コマンドを叩くようにしている。
floating の切り替えを行う際はいつも、 toggle floating のショートカットを入力するか、上記の2分割、4分割の状態にするショートカットを入力するため、それらのコマンドに borders コマンドを組み合わせているだけだ。
一例を示すと、以下のような感じ。

alt + shift - f : yabai -m window --toggle float; [ "$(yabai -m query --windows --window | jq -r '.["is-floating"]')" = "false" ] && { borders active_color=0xc000ff80; :; } || borders active_color=0xc0ffff00

https://github.com/risou/config/blob/8b2f46f7dc3b93118e95690e3e1382ced7d9ba3e/.skhdrc#L61

もう1つのケースがフォーカスを切り替えたときで、この場合は yabai の signal で borders コマンドを発火している。

yabai -m signal --add event=window_focused action='[ "$(yabai -m query --windows --window | jq -r ".[\"is-floating\"]")" = "false" ] && { borders active_color=0xc000ff80; :; } || borders active_color=0xc0ffff00'

https://github.com/risou/config/blob/8b2f46f7dc3b93118e95690e3e1382ced7d9ba3e/.yabairc#L95

これで、常に現在アクティブなウィンドウが floating かどうかが目に見えるようになった。

とはいえ、せっかくタイル型のウィンドウマネージャを用いているのに floating を多用するのはもったいないように感じている。

現代においては AeroSpace という非常に魅力的な選択肢もあり、時間に余裕ができたら試してみようか、という気持ちは少しある。
思想としては AeroSpace よりも yabai の方が好みなので、可能であればこのまま yabai を使い続けたいが、さて。

以前は Übersicht で simple-bar というウィジェットツールを使っていた。

このウィジェットを使っていた主な目的としては、 yabai というウィンドウマネージャを使っている中で、どのデスクトップにどのアプリケーションを置いているかなどが可視化されていると嬉しいというのが最も大きい。
このウィジェットツールは Mac の標準のメニューバーを代替することを想定しているものなので、日時に表示はもちろん、個人的には Spotify のステータス表示および再生・停止を行うウィジェットを便利に使ったり、自分でカスタマイズして MeetingBar の表示および次のミーティングへの参加ができるウィジェットを用意して、普段は OS が用意しているメニューバーを必要としない状態にしていた。

が、いくつか問題があって代替を探していた。

主な問題は何かというと、

• 時折、負荷がかかっていそうな気配を感じさせる
  • CPU 使用率が跳ねたり、ファンが全力で稼働している音がしていた
• ローディング状態が続く
  • 各ウィジェットが shell を定期実行してその結果を表示、という挙動をしているのだが、細かく大量にコマンドを実行しているためか、おそらく待ち行列が発生してローディング状態になって何も情報が得られない、という状態に結構なっていた

あたりで、特に後者はメニューバーの代替としての価値をほとんど失ってしまっているので時間を見つけて解消したいと思っていた。

simple-bar の代わりになりそうなものを探して、以下の２つのどちらかをためそうと考えた。

• simple-bar-lite
• SketchyBar

前者は simple-bar の軽量版ということで、導入コストが低そうなのが魅力だった。
が、問題の根本がもし Übersicht なのであれば、 simple-bar-lite を導入しても問題が解消しない可能性があった。

ということで、 SketchyBar を試すことにした。

実は SketchyBar の導入は Übersicht を導入したときにも検討をしていた。のだけど、調べてみたところ結構導入が大変そうだったので、一度見送ったという背景があった。

とはいえ、今回はもう腹をくくってこれを導入しよう、ということで、 Share your setups · FelixKratz/SketchyBar · Discussion #47 · GitHub から様々なセットアップを探して、ひとまずこれにしよう、というものを決めてそれを元に自分用にカスタマイズをした。

まずは、各デスクトップで開いているアプリケーションの表示部分をカスタマイズ。 4K などのモニタを使っているときは良いが、 FullHD のモニタではデスクトップ数が多いと横幅を広く取りすぎるので、アプリケーションがないデスクトップの表示をコンパクトにして、代わりに今アクティブなデスクトップのアプリケーションアイコンを省略しないようにした。

Spotify の表示についても参考にしたものでかなり整っていたが、再生・停止等の操作はポップアップメニュー経由で行う前提になっていたのと、再生していないときには表示領域に何もでなくなってしまうので、アイコンを常時表示にして、アイコンをクリックするだけで再生と停止を行えるようにした。

MeetingBar については自分で実装してワンクリックで次のミーティングのページを開けるようにした。これについては simple-bar 用に自分で用意したスクリプトをそのまま流用できたのでそんなに大変じゃなかった。

SketchyBar を導入して Übersicht を使っていたときの問題は解消したかというと、今のところ解消していそうな気配を感じている。
ファンが唸ることはなくなったし、ローディング状態にもならない。
さらに、 Übersicht から SketchyBar に置き換えたことが直接的な要因かは定かではないが、バッテリーの持ちが大幅に改善した。最近、長時間のオフラインミーティングなどで、途中でバッテリーが尽きてしまう問題を抱えていたが、かなり持つようになったことでこの問題が解決したことは副次的効果としては非常に嬉しかった。

これは Übersicht も同様だが、導入に際してどういう仕組みであるかを理解するまでのコストが高い。一方で、仕組みを理解してしまえばカスタマイズは容易といえる。
ということで、自分のやりたいことができるようになってきたところなので、時間に余裕ができたらもう少しカスタマイズしたいな、と思っている。
とはいえ、どんなカスタマイズをすると便利かの鮮明なイメージはまだ持っていないので、使いながら色々と考えてみようと思う。

参加するまで

僕の中では YAPC は Perl のカンファレンスではあるので、「最近 Perl 書いてないしな」というのと「勤め先では Perl を使ってないからスポンサーにはならないだろうし、そうすると宿泊費も交通費も自腹だろうから、まとまったお金を捻出できるかわからないしな」などと考えて迷ってはいた。
まあ結局、「行かないで後悔するよりは、行って後悔した方がいいな」と判断してお金をかき集めて行くことにしたのだけど。

宿は早めに取っておこうと1ヶ月前に確保。
移動は新幹線で、いい席へのこだわりとかあったわけでもないので1週間ちょっと前に予約。
ただ今回は普段と比較して新幹線に乗っている時間が思った以上に長かったので、快適な席をとった方が良かったな、と思う。とはいえ行きは快適だったし、帰りに快適でなかったのは隣の席の人のいびきが酷いことに起因しているので、いい席を確保するとかそういう話ではないが……。

準備

流行り病の影響でこの手のイベントが開催されなくなっていた時期、仕事も在宅が中心になったりと環境の変化が大きかったため、手元にいろんなものがない状況だった。

このイベントのためというわけではないけど、実は天候に左右されずに履ける靴がなかった。
持っていたのは全く防水性のないウォーキングシューズと、完全にフォーマル向けの革靴のみ。
ここ数年、梅雨の時期なども引きこもることによってしのいできたが、出社の頻度も徐々に増えてきており、このままではまずいということで昨年末頃に雨や雪の日も履ける靴を一足調達した。
当日の天候がどうなるかわからなかったので念のためこの靴を使用し、広島にいる間は雨に見舞われることもなく順調だったが、帰りに駅から自宅までの移動のタイミングで雨が降っていたので結果的にこの靴を用意しておいてよかったと言える。

鞄も別件で昨年末頃に新調しており、今回の2泊3日もこれに助けられた。
以前使っていた鞄は PC と着替え両方を詰め込むにはスペースが足りず、1つにまとめられずにいたが、新調した鞄は2泊3日分くらいであれば余裕を持って受け入れられる大きさだったため、宿泊を伴う旅行としてはとても久しぶりとなる鞄1つでの参加ができた。

在宅勤務が中心となったタイミングで携帯電話周りを見直しており、現在は iPhone 12 mini を使っている。
もう3年以上使っているということもあるが、やはり小さい端末はバッテリーも小さく、今回は特にバッテリーが全く持たなくて困った。
イベント当日は PC も iPhone も夕方頃には完全にバッテリーが尽きてしまっており、これは準備不足だったと言わざるを得ない。
会場での給電は基本的に NG だと考えている（運営が OK 出した場合を除く）ので、これについては自分で解決策を用意しておくべきだった。
普段あまりにも出かけないのでモバイルバッテリーを用意することを完全に失念していた。

また、回線契約も同じタイミングで見直しており、普段は Wi-Fi で事足りるため提供されるデータ通信量の少ないプランに乗り換えていた。
この手のプランは非常に安く助かっているが、用意されているデータ量を超えるとただちにそれなりの金額が加算されてしまうため、外出が多い月などはデータの残量を気にする必要がある。
これに対しては、少し前に別件でモバイルでのデータ通信が必要な機会があり、その際に加入した povo に助けられた。
povo は「テザリング可能」で「24時間使い放題」が330円という、普段全く使わないがある1日だけめちゃくちゃ使うというユースケースに対して非常に刺さるプランを用意しており、今回もこれに助けられた。
このプランは驚くべきことに、現在は まだ 24時間といいつつ、 翌日の23:59まで 使い放題であるため、今回はイベント当日の朝にプランを購入して、翌日のアフターイベントから帰宅までを24時間（をオーバーしているが）の範囲でカバーすることができる。
（注：公式でもこの私用については 当面の間は と表現しており、これが正規の仕様ではない。参考： https://povo.jp/spec/topping/24/ ）

ちなみにカメラを忘れたので、ほぼ写真を取らず、ここにも画像は一切掲載されません。

イベント当日

前夜祭、当日とまあ魅力的なトークが多かった印象だった。
最初に書いたように自分は YAPC に対して Perl のカンファレンスというイメージを未だに持ってはいるものの、実際にはもっと広い範囲のテーマを許容していることは理解しており、そういう意味でも1日開催なのがもったいないくらいに様々なトークが用意されていたと思う。
（とはいえ、スケジュール調整の問題も体力の問題もあるので1日開催の方が個人的にはありがたいわけだが）

最初のトークセッションの一つである『コミュニティと共に生きる』は共感できる部分もあれば、それは生存バイアスというか幸運によって成り立っている部分もあるよな、と思ったりもしたけれど、今回の YAPC の参加者の半数以上は YAPC 初参加らしく、若い人たちには良い影響のある話かもなあ、と思ったりしました。
実際のところ、継続して同じコミュニティに居続けることに正解不正解なんてないと思うけれど、少なくともコミュニティって属しているだけじゃなくて、その中で自分が何かをやっていかないと意外と簡単に消滅してしまうので、そういった意味でも何かしらのコミュニティに積極的に関わっていく経験というのはしておいて損はないものだと思う。

個人的に最も印象に残っているのはパスキー認証の話で、今の自分の関心領域に近いこともあり、非常に興味深く楽しむことができた。また、ライブコーディングをしてくれたのも個人的には嬉しかった。
ただまあ、前提となる知識がそれなりに必要なジャンルではあるし、40分では物足りなかったかもしれない。

杜甫々さんのキーノートは、個人的には結構刺さったし、あれは刺さる人多かったと思う。
インターネットが普及していく中で、かなり初期の頃から変わらずコンテンツを育て続けている様子というのは、その裏側を意識すると圧倒的なものを感じてしまうけれど、こういったものも人の情熱や好み、そしてなにより継続する力によって支えられているんだなあ、というのをひしひしと感じました。
もちろん僕も WWW 入門にはお世話になりました。

LT は全体的に勢いがあって、「やっぱり LT はこうでなくちゃ」みたいな気持ちになった（けど実際のところそんなに LT はこうあるべき、みたいなのはないと思っている）。

他にも面白そうなトークいっぱいあって、枠被りで見れなかったものが多いので動画公開を楽しみにしています。

スポンサーブースは一通り回ろうと思ったが、1箇所での話が長くなってしまうことによって、結局全てのブースで話をするだけの時間がなくなってしまった。
コミュ力が皆無なので、話始めるのも難しいし、話を終えるのはもっと難しい。

懇親会では以前一緒に働いていた人の近況について色々聞けてとても懐かしい気持ちになった。
「◯◯さんも入社してもう8年目だけど〜」みたいなことを言われて「えっ」となったり。
（そんな昔でしたっけ……？　となって計算してみたらそんな昔でした）

イベント会場でのランチ等もそうだし懇親会もだけど、提供される食事の量が結構多そうで、非常に美味しいけどそんなにたくさんは食べられない……という気持ちにもなったり。
（そうはいっても食べようと思えば全然食べられたのだけど、美味しい食事はメインの目的ではなかったので、色んな人と話したりしていたら食事を摂る時間があまりとれなかった。それはそれでもったいないことをしたな、とも思う）

会場の椅子で宣伝されていた Perlbatross は非常に面白かったが、それに時間を割いてしまってはイベントに来た意味が薄れてしまうという感じだったので、現地ではほどほどにしてホテルに戻ってから楽しませてもらった。

周辺イベント

スポンサー企業が開催する懇親会的なイベントには参加しなかった。
これは体力的な問題に起因するもので、なるべくしっかり睡眠を取って、良い状態で YAPC に参加したかったからだ。
昔と比べて体力が衰えたというわけではなく、昔と比べて自分の体力への理解が深まったからとれた選択だと思う。 ただ、開催翌日の「オフラインだからできる話」はしっかり聴講してきた。こういう場所でしか話されないオフレコトークは総じて価値が高いと思っている。
残念ながら「オフラインだからできる話」なのでここにうっかり感想を書くこともはばかられるため、これ以上の言及は控える。

他の非公式なイベントには参加しなかったが、せっかく遠方まで来たのだからもう少し参加しても良かったかもしれない。

振り返り

前職の方と話す機会を得たり、過去の YAPC で親しくしていただいた方々と話せたりしたこともあり、同窓会的な意味でも十二分に楽しめたと思う。
遠方の（宿の確保が必要な距離での）カンファレンス参加自体は珍しいことではないが、業務外で自腹で、というのはとても久しぶりで、事前に懸念していたとおり、それなりの金額を使った。
今後も参加するためには、普段からこういうイベントのために予算を押さえておく必要がありそう。

しばらくオフラインのイベントから離れていたのだけど、今年に入ったあたりからまたそういうイベントに参加していこうという気持ちになっていたので、ちょうど良いタイミングで慣れ親しんだ（？） YAPC に参加できたのは非常にありがたかったです。

次回もあればなるべく（予算が許せば）参加したいと思っているので、今回の反省を活かせるようしっかり準備しておきたい。

Web で開発していると、様々なサービスのアカウントでログインする機能を作ったりとかその他諸々、 OAuth2 や OIDC のお世話になることがある。
で、そういったものを利用するソフトウェアの開発に関わっていると、試しにリクエストを行うことも多々あるわけで、その度にアクセストークンを手動で取りに行くのって面倒だな、と思っていた。

実際に開発が終わってしまえば、使う分にはアクセストークンを意識することはないが、底に至るまでの間にアクセストークンがほしいなというシーンがあり、そういうときに簡単にアクセストークンを取得したいな、ということでコマンド一発でアクセストークンを取れるツールを作ってみた。

give-me-accesstoken

とはいっても、これはあまり汎用的に使えるものではないと思うし、とりあえず自分や自分の周囲の同じようなことをしている人が使えればいいかな、ということでサポートしている範囲は最小限です。

クライアント認証方式としては client_secret_post と private_key_jwt をサポートし、 authorization code grant と client credentials grant の2種類に対応している。

authorization code grant の場合は普通、途中でブラウザに飛んでブラウザ上でログインをしてからツールに戻ってくるという手順になるので、そういった挙動には対応している。
ひとまず Google と GitHub では動作の確認をしている。
ただ、自分が使いたい対象の一つが、この手法では上手く動かないことがわかっており、どうも Cookie にセッション情報がないと認可リクエストを通せないようだったので、そのケースに対応している。
これはあまり正攻法ではないし、複数の問題を内包してしまう（パスワードを設定ファイルに直書きする必要があったり、 MFA に対応できなかったり）ため、これが使われることはあまり望んでいない。
（しかし自分が必要としているから対応しているので、当然自分は使う）

しばらくは自分で使ってみて、問題なさそうであれば自分の周囲の人たちに紹介してみようと思う。