気がつけば夏が終わり秋の最中。
最近、様々なことが慌ただしく、ようやく振り返る時間を見つけてみれば、流れた時の速さの何たることか。

というわけで、最近のことをざっと記録しておこうと思う。

カンファレンスとか勉強会とか

今年はちょっと意識的に外に出ていこうと考えていたので、オフラインでのイベント参加を前年までより少し増やしている。

大きめのところだと 大吉祥寺.pm とか Go Conference とか Kaigi on Rails とか。
他にも Go 関連の勉強会に行ったり、地域コミュニティ的なものに参加してみたり。
コミュニティの維持に貢献できるわけではないけれど、今後も自分にできる範囲でこういったものに関わっていきたいとは思っている。

次は YAPC::Tokyo 2026 でこれは非常に楽しみにしている。10月の初めにキックオフイベントがあり、こちらも非常に良かった。

家の近くでやってた謎解きイベントに参加したり

オフラインで開催されるこの手のイベント、昔は時々やってたけどここ数年は全然触れてこなかったので、こちらもリハビリ的に近場で参加してみたりしている。
具体的にどれに参加したとか、詳細なネタバレはしないけれど、どれもカジュアルに楽しめて良かった。

ロン・ミュエク展にも行った

少し前まで森美術館で開催されていた ロン・ミュエク展 にも行ってきた。
普段からこの手の常設でない展示に関心高く接しているわけではないのだけど、これは友人におすすめされたので時間を確保した。

この手の展示は見ると楽しいし、非日常感もあって良いのだけど、自分に美術・芸術という分野の基礎知識が欠けていることで楽しめないものも一定存在するように感じている。
それもあって、普段からアンテナを高く張って、という感じにはなっていない。何かきっかけがあって、タイミングが合えば、という感じ。

わりと終盤で止めていた FFTIC をクリアした

何をもってクリアというのかという話はあるけど、エンディングを見てディープダンジョンを最下層までクリアしたあたりで満足、 あとはやり込みだけど、昔オリジナルの FFT を結構プレイしていたので、追加要素以外は無理に味わわなくても、という感じ。

新しく作りたいツールの設計をゆっくり進めている

1ヶ月くらい前から頭の中で温めていたアイデアのひとつを、実際に自分用のツールとして実装しようと思って、まずは設計を進めている。
自分が求めるものや形を紙に書いて、それを元に設計を少しずつ形作っているところ。設計は概ねできてきており、プライベートで時間を確保できるようになったら実装に着手したい。

記録を見て振り返った（この記事）

日記、というほどのものではないけど、日々の記録を残せるときには残すようにしており、この記事の内容は直近3ヶ月分くらいを見返しながらいくつかをピックアップしたもの。
記録は基本的に手書きで書いている。キーボードをタイプすることは昔から好きなのだけど、文字を書くという行為もわりと昔から好き。
なのだけど、手で文字を書く機会というのは年々（というか自分が大人になる頃にはもう壊滅的に）減っており、自分で機会を作らないとお気に入りの文房具の出番がない、という理由が大きい。

というのをちょっとだけ調べて、　湘なんか #5 - connpass という集まりで話してきた。

要約すると：

• Git はファイルサイズや文字数の制限を設けていない
• だいたい 64KB くらいにおさめると安全
  • 日本語文字なら20,000文字くらい
  • GitHub のコミット詳細に全文表示される
  • JetBrains の Git クライアントでも全文表示される
  • lazygit でも1秒かからなず表示される（当然これはスペック依存ではある）

それはそうと、湘なんかという集まりに参加するのは2回目なのだけど、非常に良い空気を纏っていてとても楽しめた。
その地域に対して好意的な人たちが集まっていることもあるし、トークや LT の内容も多種多様でどれも面白い。
（実は参加した2回とも、前にスケジュールが詰まっていて、最初から参加できてはいないのだけど……）
こういうコミュニティが参加できる距離にあるということに幸運を感じている。
今後も参加できるときは参加したいし、こういう場で話せるようなネタも仕入れておきたい。

Git 2.54 で git history reword , git history split コマンドが、 Git 2.55 で git history fixup コマンドが追加された。それぞれ以下の作業を置き換えられる。

• git history reword
  • git rebase -i で reword を指定
• git history split
  • git rebase -i で edit を指定
  • git reset HEAD~ して分割したいコミットの差分を uncommitted にする
  • “git add -p して git commit” を分割後のコミットの単位で実行
  • git rebase --continue
• git history fixup
  • git 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 との向き合い方、活用の仕方について侃々諤々である。
自分自身その渦中に身を置きながらも、いつものようにポジションを表明せず、お得意の「様子を見る」をしていたのだが、最近読んでいた本の中の一節がふと目に留まった。

この本自体は少し前に執筆されたものだが、最近になって改めて文庫として刊行され、おそらくはその際に追加された解説に書かれていた文章だ。

数学においては「直観」と「規則」が、いつも背中合わせの関係にある。直観的に何かを「わかる」ことと、規則に従って記号を正しく「操る」こととは、常にたがいを支え合う関係にある。計算の意味を「わかる」ことができて初めて、筆算の規則を編み出すことができる。だが、ひとたび筆算の手続きを身につけてしまえば、極端な話、たとえ意味を忘れてしまったとしても、正しく数を「操る」ことはできる。かくして、「わかる」と「操る」は互いを支えながら、原理的には切り離すことができるのである。

この洞察が、たとえば計算機の成立を支える。実際、計算機に「わかる」ための意識や心はないが、それでも様々なデータを規則に従い、正確に「操る」ことができる。直観を孕む人間の知能に、どこまで規則の側から迫っていけるかは「人工知能」研究にとって重要な問題である。

── 森田真生「解説」、矢野健太郎『暮しの数学』中公文庫、2020、pp.241-242

数学を「わかる」ことと「操る」ことは相互に関係するものでありながら、切り離すことができる。これは示唆に富んだ一節ではなかろうか。

また、計算機と同じように AI も「わかる」ための意識や心を持っているわけではない。だが、最新のモデルが「操る」コードの品質はかなりよくなってきている。

ここ数年で設計、開発、テストといったソフトウェアエンジニアリングにおける「操る」業務の一部が急激に AI に委譲されていっている。
しかし「操る」ことを AI に委譲したからといって、実現しようとしているビジネスや、構築しようとしているシステム、採用しているアーキテクチャを「わかる」ことを手放せるわけではない。
自分が「わかっている」ことが AI に作業を上手に委譲するために必要なのだ。
わかっていなければ AI に適切に指示することも AI のアウトプットを正確に評価することもできない。

今やこれらの業務の多くを AI に任せているソフトウェアエンジニアもかなりの数になっているだろうし、その一方で自らが手を動かして開発を行わないことに違和感や不安を抱いている人もいるだろう。
しかし、それを委譲することはけっして己の不要性を示すことにはならない。少なくとも現時点では、それによって直ちにソフトウェアエンジニアの仕事が失われるわけではない。
ただし、考えること、ビジネスやシステム、アーキテクチャを理解することまで委譲してしまってはいけない。
そうなったら、その先にはソフトウェアエンジニアとしての衰退しか残っていない。