Git のコミットメッセージってどれくらいの情報量を載せられるんだろう
というのをちょっとだけ調べて、 湘なんか #5 - connpass という集まりで話してきた。
要約すると：
- Git はファイルサイズや文字数の制限を設けていない
- だいたい 64KB くらいにおさめると安全
- 日本語文字なら20,000文字くらい
- GitHub のコミット詳細に全文表示される
- JetBrains の Git クライアントでも全文表示される
- lazygit でも1秒かからなず表示される（当然これはスペック依存ではある）
それはそうと、湘なんかという集まりに参加するのは2回目なのだけど、非常に良い空気を纏っていてとても楽しめた。
その地域に対して好意的な人たちが集まっていることもあるし、トークや LT の内容も多種多様でどれも面白い。
（実は参加した2回とも、前にスケジュールが詰まっていて、最初から参加できてはいないのだけど……）
こういうコミュニティが参加できる距離にあるということに幸運を感じている。
今後も参加できるときは参加したいし、こういう場で話せるようなネタも仕入れておきたい。
`git history *` で作られるコミットには署名がつかない
Git 2.54 で git history reword , git history split コマンドが、 Git 2.55 で git history fixup コマンドが追加された。それぞれ以下の作業を置き換えられる。
git history rewordgit rebase -iでrewordを指定
git history splitgit rebase -iでeditを指定git reset HEAD~して分割したいコミットの差分を uncommitted にする- “
git add -pしてgit commit” を分割後のコミットの単位で実行 git rebase --continue
git history fixupgit commit --fixupしてgit rebase --autosquash
いずれも、対象のコミットハッシュさえ取れればかゆいところに手が届く便利なコマンドである。
ただし、Git 2.55 時点では3つとも experimental である。
そして、これらのコマンドによって作られたコミットはどうも署名されないようだ。
手元（Git 2.55.0）で試したところ、コミットを再生成する際に commit.gpgsign が反映されず、対象コミット以降がすべて未署名になった。
実装を見ると、コミット時の署名有無の指定をする箇所で NULL が渡されており、署名付きコミットの処理に入ることはなさそうに見える。
https://github.com/git/git/blob/e9019fcafe0040228b8631c30f97ae1adb61bcdc/builtin/history.c#L145-L147
今後のアップデートでこの問題が改善する可能性は十分にあるが、少なくとも現時点ではコミットにちゃんと署名をつけたい場合、 git history の利用を控える、もしくは git history の実行後に以下のコマンドを実行する必要がある。
git rebase --force-rebase {署名を付け直したい最も古いコミットの親コミットのハッシュ}
--force-rebase をつけておかないと no-op になって署名が外れたコミットのままになるので注意。
モバイルバッテリーを使う際のライフサイクル
先日、使用していたモバイルバッテリーを地域の処分場に持っていった。
要するに廃棄したわけだが、理由は膨張していたから。
使っていたのは Baseus の 6000mAh のモバイルバッテリー。
2年弱前に購入したもので保証期間内であったが、2年持たずに膨張するものを再び使いたいとは思わなかったので、そのまま廃棄することに。
実はこの製品、購入直後に1つ前の世代のものが発火の危険性ありということでリコールされていた。
その時点で気づいてはいたものの、世代が違うということでリコール対象外だったこともあり、100％の安心はできないな、という警戒心を持ちつつ使っていた。
膨張していることに気づいたのは2週間くらい前、だったかな。
MagSafe で iPhone を充電するのに使っていたが、ある時 iPhone とモバイルバッテリーの間に妙な隙間があることに気づいた。
本来であればぴったりくっついてほしいところが、そうなっていない。
それに気づいた瞬間、「これはバッテリーの膨張だ」と気付き即座に利用を停止。
このタイミングで膨張したバッテリーの処分方法についてもチェックしていた。
処分には普段足を運ばない場所に行く必要があり、なかなか機会を作れずに放置していたのだが、ある夜急にパチッという弾ける音が耳に入った。
音源を探るとそこには利用を停止したモバイルバッテリーがあった。
急速に膨張している。
これは危険だ、ということで空き缶に封印して発火した場合でも対処しやすい位置に置いて一晩を過ごした。
そして翌日、処分を請け負ってくれる場所に持っていった。
話としてはそれだけで、2年持たないのはちょっとコスパ悪いなあ、とか思うところは色々あるけれど。
大事なのは、モバイルバッテリーには発火の危険性があるということ。
当然だけど、わざわざそのようなリスクのあるものを家においておく理由はない。
少しでも膨張しているのであればなるべく早く処分すべきだし、そもそも膨張する前に処分するくらいの気持ちで使うくらいでちょうど良いだろう。
自分が使っている iPhone は 12 mini で、流石にもうバッテリーがかなり劣化している。
1日持たないどころか、日によっては2回充電しないといけないこともある。
スマートフォン自体の使用頻度が比較的高くないので普段はなんとかなっているが、長時間の外出時に困る、という状況だ。
だがまだ、新しくモバイルバッテリーを注文していない。
捨てるときのことを考えると腰が重くなってしまっているというのが実情だ。
つまり、購入を検討する時点で捨てるときのことを考えている。
この手の製品は、使わなくなったら家に放置するのではなく、なるべく早く然るべき手順で処分するに越したことはない。
そう考えると捨てるコストが理由で購入をためらう気持ちが出てくる。元より自分はそういうタイプだ。
モバイルバッテリーの必要性は正直まだある。
一方で、モバイルバッテリーの購入をためらう理由もある。
安全とはそれだけ価値の高いものなので、次を購入するかどうか、慎重に考えたい。
「わかる」と「操る」から学ぶ AI との向き合い方
最近 AI というものの進化が様々なシーンで日常を変化させていっている。
ソフトウェアエンジニアリングに関わっていると、一年前、いや半年前と比較しても非連続的といっていい変化がもたらされているのを感じる。
当然、当事者たちは日々 AI との向き合い方、活用の仕方について侃々諤々である。
自分自身その渦中に身を置きながらも、いつものようにポジションを表明せず、お得意の「様子を見る」をしていたのだが、最近読んでいた本の中の一節がふと目に留まった。
この本自体は少し前に執筆されたものだが、最近になって改めて文庫として刊行され、おそらくはその際に追加された解説に書かれていた文章だ。
数学においては「直観」と「規則」が、いつも背中合わせの関係にある。直観的に何かを「わかる」ことと、規則に従って記号を正しく「操る」こととは、常にたがいを支え合う関係にある。計算の意味を「わかる」ことができて初めて、筆算の規則を編み出すことができる。だが、ひとたび筆算の手続きを身につけてしまえば、極端な話、たとえ意味を忘れてしまったとしても、正しく数を「操る」ことはできる。かくして、「わかる」と「操る」は互いを支えながら、原理的には切り離すことができるのである。
この洞察が、たとえば計算機の成立を支える。実際、計算機に「わかる」ための意識や心はないが、それでも様々なデータを規則に従い、正確に「操る」ことができる。直観を孕む人間の知能に、どこまで規則の側から迫っていけるかは「人工知能」研究にとって重要な問題である。
── 森田真生「解説」、矢野健太郎『暮しの数学』中公文庫、2020、pp.241-242
数学を「わかる」ことと「操る」ことは相互に関係するものでありながら、切り離すことができる。これは示唆に富んだ一節ではなかろうか。
また、計算機と同じように AI も「わかる」ための意識や心を持っているわけではない。だが、最新のモデルが「操る」コードの品質はかなりよくなってきている。
ここ数年で設計、開発、テストといったソフトウェアエンジニアリングにおける「操る」業務の一部が急激に AI に委譲されていっている。
しかし「操る」ことを AI に委譲したからといって、実現しようとしているビジネスや、構築しようとしているシステム、採用しているアーキテクチャを「わかる」ことを手放せるわけではない。
自分が「わかっている」ことが AI に作業を上手に委譲するために必要なのだ。
わかっていなければ AI に適切に指示することも AI のアウトプットを正確に評価することもできない。
今やこれらの業務の多くを AI に任せているソフトウェアエンジニアもかなりの数になっているだろうし、その一方で自らが手を動かして開発を行わないことに違和感や不安を抱いている人もいるだろう。
しかし、それを委譲することはけっして己の不要性を示すことにはならない。少なくとも現時点では、それによって直ちにソフトウェアエンジニアの仕事が失われるわけではない。
ただし、考えること、ビジネスやシステム、アーキテクチャを理解することまで委譲してしまってはいけない。
そうなったら、その先にはソフトウェアエンジニアとしての衰退しか残っていない。
yashiki で表示するウィンドウを自在に切り替える
タイル型ウィンドウマネージャ yashiki の導入
macOS を利用する際は、かなり前からタイル型ウィンドウマネージャを導入している。
最初に導入したのは Amethyst で、もうだいぶ昔のことなので詳細は覚えていないが、何かしらのアプリケーションとの相性の問題があって、あまり長くは使わなかったと記憶している。
その後は macOS でのタイル型ウィンドウマネージャを諦めていた時期もあったが、併用していた Linux ではタイル型ウィンドウマネージャを使っていたこともあり、良いものがあれば、という気持ちは常に持っていた。
ある時、新しい MacBook のセットアップをしたタイミングで yabai というタイル型ウィンドウマネージャを導入して、それ以降は概ねずっと何かしらのタイル型ウィンドウマネージャを使っている。
期間的には yabai を最も長く使っていたが、他のものも試したいという気持ちで AeroSpace に切り替えて使っていた時期もある。
そしてまた今年、新年を迎えたタイミングで新しいタイル型ウィンドウマネージャを試そうという機運になった。
候補は OmniWM と yashiki の2つ。
typester/yashiki: macOS tiling window manager
一口にタイル型ウィンドウマネージャといってもいろいろな種類があり、この2つはウィンドウマネージャとしての基本的な考え方が大きく異なっている。
ここではタイル型ウィンドウマネージャの歴史や系譜については触れないが、今回は両方を実際にインストールして試した。
少しの時間ではあるが実際に触ってみて、現在の自分の使い方に合っているのは yashiki だと判断し、今は yashiki を常用している。
自分の基本的な使い方
yashiki がどのようなものかはリポジトリを見に行ってもらうのが速いと思うが、自分の使い方を一部紹介する。
前提として、デフォルトのレイアウトは tatami を採用している。
まずは README に書かれている設定にもあるが macOS の Spaces を再現したいので、 ctrl-1 〜 ctrl-9 でそれぞれ tag N を表示するようにしているが、 tag N はそれぞれ bitmask 2N-1 を表す。
それぞれの tag にアプリケーションを割り当てており、上記のホットキーでスムーズに切り替えられるようにしている。
yashiki （や yashiki が参考にしている river）が面白いのは tag を bitmask として表現しているところだ。
先にも書いたが、例えば ctrl-3 は tag 3 に切り替えるが、これは bitmask 4(binary: 100)に相当する。
逆に bitmask 3(binary: 011)は tag 1 と tag 2 の和集合であり、これを表示すると tag 1 に割り当てられたウィンドウと tag 2 に割り当てられたウィンドウの両方が表示される。
これを活かすため、自分はさらに ctrl-shift-1 〜 ctrl-shift-9 に 2N-1 を tag-toggle する設定を追加している。
yashiki tag-toggle コマンドは、指定した bitmask と現在表示している bitmask の XOR をとる。
これによって、たとえば ctrl-2 を押して tag 2 (= bitmask 2) を表示している状態で、 ctrl-shift-5 を押すと bitmask 18 を表示している状態になる。
これはつまり tag 2 (= bitmask 2) と tag 5 (= bitmask 16) を同時に表示している。
tag-toggle コマンドは XOR をとった結果が 0 になる場合は何もしないので、表示する tag がない状態にはならない。
最初に tag N にそれぞれ1つ（ないしは2つくらいまでの）ウィンドウを割り当てて置くことで、1つのウィンドウを画面全体に表示したい場合も、2つのウィンドウを左右に分割したい場合も簡単に切り替えることができる。
また tatami は master-stack 式のレイアウトだが、 master 側（画面の左側）に置くウィンドウの数を増減できるので、 4K ディスプレイなどでウィンドウを 2x2 に配置することも容易にできる。
yashiki を紹介するトークをしてきた
先日、「なんか」を話す会に参加してきた。
何を話そうか、というところで最近自分の中でホットな yashiki の話をしてきたという次第。
自分はそれなりにタイル型ウィンドウマネージャを使ってきているけど、がっつり使いこなしているというよりは、浅瀬で基本的な機能だけを使っているという感じなので、他の人がどう使っているかを知りたい。
そのためにもまず、使ってくれる人が増えたらいいなあ、という思いがあったのでちょうどよい場が得られてよかった。