前回の記事で書き忘れてたこと。

本には主要登場人物というべき何度も登場する人がいく人かいるのだけど、その中の一人がBob（”Crazy Bob”というあだ名がつけられている）という人だ。本書では9章の「コアライブラリ」の章で初登場する。BobはDanger/Be/WebTV人脈ではなく、もともとGoogleでAdsの一員として働いていたところからAndroidに移籍した人だが、コアライブラリとしてApache Harmonyを移植したりしてランタイムの基盤を整えたりといった大きな貢献をしている。それだけではなく本書の結構いろんな箇所で登場していろんなコメントを残している。インタビューに応じてくれて多くのコメントを残してくれたのだろうと想像される人物である。

それ自体はふーんでおしまいなんだけど、その初登場の節からちょっと後で、BobはやがてGoogle自体をやめてSquareのCTOになったのだった、という後日談が簡単に述べられる。自分はちょっと気づくのが遅くて、そこで遅まきながら気づいた次第なのだった。このBobという人は、先般サンフランシスコの路上で刺されて亡くなったBob Leeその人だ。

https://en.wikipedia.org/wiki/Bob_Lee_(businessman)

2023年4月某日、男性が深夜にサンフランシスコの路上に刺され、そのまま亡くなるという事件があった。その男性は実は元SquareのCTOでCash Appの創業者であるBob Leeなる人物だと判明してサンフランシスコテック業界に大きな衝撃を与えた。当初こそいかにサンフランシスコの治安が悪化したかという話として受容された本事件だが、その後奇妙な展開を迎える。Bob Lee刺殺犯の容疑者は通りがかりの見知らぬ強盗ではなく、Bob Leeと知己であるNima Moneriなる人物だった。実はBob LeeはThe Lifestyleなる名前のセックス＆ドラッグコミュニティの一員であり、Nimaの妹もそのコミュニティの一員としてBobと関係を持っていたのだという。Nimaは既婚者である妹がBobと関係を持っていたり一緒にドラッグをやっていたりするのではないかという疑念を抱き、その日に問いただして最終的にBobを刺殺したのだという。この事件の背景まで報道されると、サンフランシスコテック業界内ではどちらかというと困惑といった感じで受け止められたと記憶している。

“Androids” はこの事件が起きるより前に書かれた本なので、もちろんこういう事情は本書では一切触れられていない。Bobは他の開発者たちと同様にAndroidの初期の話を彼自身の視点から語ってくれているだけだ。だが彼の発言を読んでいくことで、彼の人となりのようなものがわずかなりとも垣間見える。私自身はこの事件の報道があった時にはBob Leeという人と関わりはなかったし、詳しくもなかったので、事件の報道内容についてもなんというかフラットに受け止めていたと思う。でも本書を読んでBob Leeという人の輪郭のようなものが見えてくると、この事件の不思議さというか、事件の報道を読んだ時の困惑のようなものがわかるように思うのだ。

本書のBob Leeは気さくで、技術の細かいところもよく抑えた好人物で、報道のようなセックス＆ドラッグコミュニティに出入りするテック系のお金持ち、といったイメージとは全く異なる。いったいどちらが本当の姿なのか……などと思うのだ。だが、どちらかだけが本当ということではなく、そのどちらでもあるというのが人間というものなのだろう。

ともあれ、この事件の人物と本書の登場人物が繋がったのは結構びっくりしたし、それで事件の受け止め方も変わってきたな、ということは、本の感想とは違うレベルの話だけど書いておきたかったので、こうして補足記事として書いておく。

Chet Haase氏の書いた”Androids“を積んでたのを思い出したので読んだ。面白かった！

Chet氏は2010年にGoogleに入り、Androidの、特にUIフレームワーク周りの開発を主導してきたエンジニアだ。同時にAndroid開発コミュニティではさまざまな講演などでもお馴染みの人でもあり、Android Developers Backstageというポッドキャストのホストも長いことこなしてきた。

そんなChet氏が、Androidの初期の事柄を記録しようということでさまざまな人にインタビューを行い、それをまとめたのが本書だ。創業からGoogleの買収を経てSDKの公開、1.0、そして最初のデバイス（G1）の発売である2009年ぐらいまでのことについて、関係者の声や思い出話をまとめ、紹介している。これが面白いのだ。

面白さの一つには、出てくる個別のエピソードがそれぞれいちいち面白いという面がまずある。創業まもなくほとんど何もできてなかったスタートアップのAndroidみたいなところでGoogleによる買収が決まったか。Larry PageがDanger（AndyがAndroid創業以前にやってた携帯電話の会社）の携帯を使っていてファンだったところが大きいらしい。Google買収前にAndroidの面々がサムスンに交渉に行って「で、OS作るチームはあるの」と言われてBrian Swetland一人で作りますと言われて一笑に付される話。Hiroshi Lockheimerは大学の学位がなかったので当時めちゃくちゃ学歴主義だったGoogleでの採用が難航し「なぜ大学を中退したか」みたいな小論文を書かされるようになったというくだり。当時別のチームにいたがAndroidの中の人に頼まれてAndroid SDKを紹介してデモアプリを動かすような講演をやったら、そのことを知らないAndyに「こいつは一体誰なんだ、なんで勝手にこんな紹介してるんだ」と烈火の如く怒られ、そのことを振り返って「Andyとの仲は最悪のところから始まった。ここからは良くなることしかないと思うことにしたよ」などと嘯くDave Burke……。

自分にとっての面白さは、身近さと同世代性という面もある。自分はAndroidと全くの無関係ではない仕事生活をしていたことがあるので、本書の中で言及されている人たちの中には、直接の知り合いとまではいかないがこちらからはどういう人なのかはわかっているような人たちが結構いっぱいいる。そういう人たちの物語が描かれるということの面白さというものがある。そしてAndroid登場時にはすでにGoogleで働いていたので、そういう面でも身近さと同世代性みたいなものがある。まあ実際には自分よりはやや年上な人たちが多いんだけど、小学生の時とかにBASICでプログラミングに初めて触れた、みたいな人たちが多いのも同世代性を感じるところがあるかもしれない。

ある意味では『闘うプログラマ』みたいな面白さもある。それまでのキャリアで培われていたOS人材がAndroidの名の下に（再）結集し、スマートフォンOSという新しい分野を切り開いていく（そして成功する）というストーリーの面白さ。それと同世代性からすると「俺たちの世代の『闘うプログラマ』」という側面があるような気がする。

ただ、『闘うプログラマ』と比較してみると大きな違いがあって、それは本がどこに焦点を置いているかというところ。『闘うプログラマ』はデイブ・カトラーという人へのフォーカスが大きく、それ以外のOS開発チームはややもすると背景に落ち込んでいるような気がする。それと比べてみると “Androids” ではむしろAndy Rubinの影の薄さが際立つ。

Andyの影がうすいというのは別に何もしていないということではないし、言及回数が少ないということでもない。ただ本書は（多分）Andyに話を聞きに行って（いけて）いないし、彼自身の話というのは意外とあんまり出てこない。本としてのフォーカスはむしろAndroidというプラットフォームを作り上げていった開発者たちにあり、読者に印象を残すのはBrian SwetlandでありMike CleronでありDianne HackbornでありRomain Guyであり……といった人たちになる。開発対象のレイヤ（カーネル、コアライブラリ、フレームワークなど）ごとの章立てと、各節ごとに特定の個人にフォーカスを当てて語られるような構造からしても、編年的ではなく列伝的な構成になっている。この構成がこの本のいいところだと思う。各人のそれぞれの思惑とかあるべき姿、そういうものの対立が描かれているところも面白さに寄与している。

少し残念なところ。自分はAndroidには複雑な気持ちを持っているので、本書の著者や登場する開発チームの人たちの語られることは少し違うな、と思うことは結構あった。もちろん事実として正しくないということではない。ただ自分とは違うものの見方であり、そういうふうにみるとこういう表現になるんだな、納得はするけど自分とは違うな、というようなものでしかない。でもまあ、そういうものは多々あった。具体例はあげづらいのだけど。

もう一つ、東京チームの存在感のなさは残念に思った。実際には東京に開発チームができたのは本書のスコープからすると少し後のことだと思うのでそこにほぼ言及がないのは仕方ないようにも思うのだが、もう少し稿を割いても良かったんじゃないかなあと思う（ただの身贔屓かもしれない）。東京の人たちで言及されているのはたぶん、門間さんのことがインタビュイーの発言の中に一度言及されているだけじゃないかな。まあこれは自分が日本人だからで、他のロケーションの人には同様に色々思うこともあるだろう。

まあそれはさておき総合的には非常に面白い本だった。日本語で出してもそれなりに面白く読まれるのではないかなあ。誰か訳さないのかな。

“Prince of Persia: the Lost Crown” をちまちま遊んでてやっとクリアした。コンプリートは全然だが、そこまではやらなくていいかな。でも面白かった。

プリンス・オブ・ペルシャといえば初代をスーパーファミコン版でやったことがあるぐらいで、シリーズのファンということではない。でもまあ初代はかなり好きだったな。今回はこれまでのシリーズとはストーリーラインや趣きがだいぶ違うようなので、思い入れのあるファンからの評判がちょっと芳しくないところもあるらしいが、そういうしがらみがないのがよかったのかもしれない。

ゲームジャンルが大きく変わっていて、いわゆるメトロイドヴァニアの2Dアクションゲームになっている。でもパズルっぽい要素というか……手持ちの動きの組み合わせをどうするとこの先のアイテムが取れるのか……みたいな曲面が多く、その難易度もそこそこで、そういうのを考えながら遊ぶのは結構楽しい。アクションの難易度というか複雑度はまあまあ難しいところもあり、何度も挑戦しがいのある箇所もそれなりにある。操作は割と快適で、何度も挑戦するのはうんざりだけど我慢できなくもないぐらいのバランスがとられているし、脇道を通らずに最後まで行くならそこまで複雑なアクロバティックな動きはしなくてもよかったりするというのもあり、プレイしやすい。

ボス戦もそれなりに歯応えがあり、初見で倒すのは結構無理で何度かプレイしながら攻撃パターンから的確に避けたりするのを学習したりしつつ倒すが、全然勝てそうにないということもない、ぐらいのちょうどいい難易度。それでも後半になると「そもそもどうやって避けたらいいか一見よくわからん」みたいな攻撃パターンが出てきて、それを手持ちの動きで避けれたりすると気持ちいい。

というわけでアクション性は高いんだけど、全般的にパズルっぽさがあるように感じられ、そこがよかったと思う。やりごたえもそれなりにある。でもまあ難しすぎて投げ出したくなるということもない。あと操作性が快適で困ることが少なかった。まあ自分がメトロイドヴァニアは割と好きというのはあるが、良いゲームだったと思う。

ストーリー自体はなんかすごい凝ったものではなくて普通だなと思ったけど、まあこのシリーズはそういうものなのでは、みたいな気もする。ストーリーの細かい点で疑問というか解決されない部分が残ったなと思ったが、ググってみたらファン考察みたいなのが出てきていてなるほどなと思ったり、そういう楽しみもあった。

というわけで、とにかくよくできていて楽しめた。

日本語版のレビューを読んでたらバグが多すぎるというのがあったが、自分はそんなふうには感じなかったな。途中で一度アップデートがあったのでそれで修正されたところもあったのかもしれない。一個だけ、とあるサブクエストを受注するとゲーム自体が固まるというバグに遭遇して困ったけど、それぐらい。ちなみにPS5版でプレイした。

https://amzn.to/3OF3veo

ここ3年くらい、fitbitのinspire HRという安いモデルをずっと使ってたのだが、それを紛失した。何を言ってるのかわかんないだろうけど、気がついたら腕についてなかった。

そもそも安いモデルの安っぽいデフォルトのバンドでやってたんだけど、それがどうにもヘタってきてて、ちょっとした衝撃で外れかけるということがここ最近よくあった。寝てる間に外れて起きたら腕時計してなかった、という事もあった（その時はベッドを探したら出てきた）。

で、こないだの週末、朝から出かけてお昼ご飯を外食し、うちに帰ってきて、子供を昼寝で寝かせて少し休憩し、子供が起きたので抱き抱えて居間に来て、さて、と思ったら腕時計をしていないことに気づいたという次第。昼食時には腕時計をしていたと思う。帰宅して休憩していた時はどうだったかな、あったような気もするが記憶はなんだか曖昧。そんな感じ。fitbitアプリの同期時刻を見ると、だいたい昼食後から帰宅時ぐらいが最後の同期だったようだ。帰る時に駐車場などで落としたか、車の中で落としたか、家の中か、そこのところが判然としないがそんなところだと思う。

まあ安いモデルで十分すぎるぐらい使ったし、個人情報とかも特に入っていないと思うし、このまま出てこなくてもまあそれは別にいいか、というような程度のものだ。しかし紛失するとは思わなかった。しかも紛失するとなかなか探しづらい。携帯電話とかは音を鳴らすみたいな機能があったりするが、スマートウォッチは何もできない。がんばって見つけるしかない。いやそれは大概の物がそうか。

何年もずっとつけてたから、腕にスマートウォッチがないとなんとなく寂しいような気もする。一方、腕がスッキリしているようにも感じる。子供を寝かしつけるときに不用意に点灯してしまう問題がないのは良い。時間の確認がちょっと手間になった。でもまぁなくてもいいな。新しいのを買い直してもいいのだけど、さてどうしたものかなぁ。大した機能は別になくてよく、フィットネストラッカーの機能があると嬉しい程度なので、pixel watchはどうにも食指が動かない（AndroidユーザなのでApple Watchはなおさら要らない）。fitbitがGoogle傘下になった今後、シンプルなフィットネストラッカーのプロダクトラインの今後はどうなるんだろうな。いっそスマートでない腕時計でもいいかもしれないが。

こんな記事を見かけた。

こういうことはレポジトリ構成・ワークフローと密接に紐づいているので、そういう前提を抜きにはどれがいいとかはいうことはできない。が、自分はいわゆるsquash and mergeのみの環境しかほとんど経験がないし、それで困ったことが一度もない、という話をしておきたいので書いておきたい、ので書いておく。

squash and mergeのメリットは書いてある通りで、基本的にPR内の細かい修正というのはゴミみたいなコミットが多く、メッセージも雑なことが多いので、それをコミットログに残しておくのは嫌だということがある。それよりは意味のある単位のコミットを残しておきたいし、それの単位はPRで行うのが良い、ということだ。

“Google-style” workflow

デメリットの方は、いわゆるfeature branchというワークフローで顕在化する問題であると思う。で解決策はあり、それはワークフローを変えてfeature branchは作らない、ということになる。全ての作業は主にmain branchに対して行う。もちろんPRのためにはブランチを作るが、それは個々のPR単位で作り非常に短命になる。その昔、Googleが「全てmain branchで作業している」開発スタイルだという話を公表して当時は結構話題になったので私は”Google-style”のワークフローと呼んでるけど、ぶっちゃけ今となっては常識化してきたと思う。もっと一般的な名前があるのかどうかはよくわからない。（追記：trunk-based developmentという名前がちゃんとあったというのを指摘された。専用のドメインまであるのか。thanks for the info!）

このワークフロースタイルでは、機能を開発するのにブランチを作ることはしない。個々の開発者は個別にPRごとのブランチを作る（topic branchということが多いと思う）。このブランチでそれなりに意味のある変更が積み上がったら、それをPRする。PRでコードレビューされ、レビュー内容に応じてちょこちょこ変更したりするが、ともあれそれが終わってPRがマージされたらおしまい。そのブランチも消す。ブランチは短命で、平均寿命は1日以下とかみたいになる。そういうふうに短いサイクルでブランチを作っては消していく。なのでリンク先のような問題は起こりえない。

もちろん開発する機能というのは大規模なものもあり、そういうものは一つのPRで終わることもないし時間もかかる。でも全てのコミットはmainに積み上げていく。完成していない機能はフラグなどを使って実際には使われないようにしたりする。この方が全員が全てのことを把握できるし、意図せず他の機能のものを壊すこともないのでいいのだ、というのがjustificationであると思う。

cascading PRs

一つの作業をしていく中で、その作業がちょっと規模が大きくなってきたのでPRを分けた方がいいな、ということはある。そういう場合にはPR1のブランチがあって、それに依存したPR2のブランチがあり、さらにPR3のブランチもあって……みたいな構造をとる事もある。そうしてPR1がマージされた後でPR2/PR3はどうすればいいのか？という話はあると思う。

ただこれはfeature branchとは本質的に違う点があり、PR2/PR3というのは基本的には自分一人しか触らない。feature branchとして開発している場合にはチームみんながそれをいじっているわけなので、どうやってマージするか、整合性を取るかというのは大きな問題になるけど、自分の手元のローカルブランチなので好きなようにいじってしまえばいい。具体的には、普通PR1をマージしたら、PR1ブランチを削除し、mainをgit pullした後で、PR2はgit rebase mainすればそれで済む。PR1に由来するコンフリクトは自分にとっては自明だし、ほとんどの場合にはgit rebase –skipするだけだ。もしくはgit rebase -iして自分でPR1由来のコミットを消してもいいだろう。

release branches

場合によってはリリースごとにブランチを作るということはある（昨今のモダンなウェブ開発ではあんまりないかもしれないけど）。例えばChromeブラウザでは新しいバージョンごとにブランチが作られている。このブランチはリリーススケジュールにもよるがそこそこ長命であることが多い。Chromeは4週間ごとに新しいブランチが作られるが、stableチャンネルの他にbeta、devというチャンネルがあるため、8週間くらい生き延びる。

ただ、基本線は同じと思う。

まず、リリースブランチはリリースごとに新しいものを作る。例えばChromeの場合、一つの「stable channel用のブランチ」があるわけではない。Chromeは今バージョン119でbetaが120だが（あってるかな）、この場合には「バージョン120のブランチ」と「バージョン119のブランチ」が作られている。stableが120に移るというのは、stableは「バージョン120のブランチ」を使うように変更することを意味する。その時betaは新しく作られた「バージョン121のブランチ」を使うようにスイッチしている。「バージョン119のブランチ」はそのまま消されることはないが放置され、忘れ去られる。

そしてリリースブランチでは開発をしない。メインの開発とは別にセキュリティの修正など重要なパッチをリリースに含めたいことはとてもよくある。だがその時もリリースブランチに直接変更を加えることはしない。あくまでも修正はmainのブランチに対して作り、そちらにマージする。マージした後でその修正をリリースブランチにcherrypickする。

もちろんワークフローとか開発スタイルというのは大きく優劣があるようなものではない。例えばこういう開発スタイルは大規模分散的なオープンソースソフトウェア開発（例えばLinuxカーネルとか）には向いてないだろうと思う。文化的な面もある。

ただ、この「squash and merge」というのは基本的にはここで私のいう「Google-style workflow」と相性がよく、というかこのワークフローでないなら難しい面もあるということなのだと思う。どのマージスタイルを選ぶのかというのはちょっとした選択のようでいて、ワークフローも含んだ選択でもあるのだろう。

Android-style workflow

ところで、この記事の元ネタのような呟きを bluesky に書いていたところ「Androidは……」というツッコミというかなんというかをいただいた（笑）。AndroidはGoogleの一部でありながらこういう「Google-style」ワークフローでは全くなく、完全なるカオス。自分はちょっとだけ体験したけどマジでやばい。どうしてこうなってしまったのか、こうなる前にもっと別なところを改善すべきだったのでは、と個人的にいつも思っている。

あんまり詳しくは公表されていないのではっきり書かない方がいい気もするけど、例えばAndroidは社内にmainブランチ的なものがある一方でAOSP (Android OpenSource Project)として公開されているブランチもあり、どちらも活発に開発されている（新しいコミットがどんどんマージされている）。しかもwearとかはまた別の自前ブランチを持っていたりする。そういう中で、誰かの入れたコミットがそれぞれのブランチに適切にマージされていくような仕組みがある。だが（上記だけでも結構複雑そうに思えるが）実際にはさらに数段複雑な構造になっているため、「適切なマージ」の仕組みは複雑怪奇な仕組みになっている。

こういうことはやめましょうね、という反面教師としてしか存在価値はないような構成・ワークフローになってしまっていると思う。もっとシンプルでstraightforwardなもので充分です。AndroidやLinuxカーネルを開発するんじゃないんだからね、と、私としては思う次第。

PS5のSpider-Man 2をクリアした。かなり面白かった。今回も良作。ただ総合的な満足感は前作の方が上という気がした。

PS4にあったゲームの続編で、ニューヨークを舞台にしたオープンワールドゲーム。今回の主なヴィランはKraven the hunterとヴェノム。Kraven the hunterっていうヴィラン初めて見たんだけど、ゲーム内でのデザインはよくできててかっこ良くはあるものの、「君ちょっと世界観違くない？」という気がする見た目だったのがすごく気になった。オープニングシーンとかちょっと笑っちゃった。

ゲームとしてはそんなに難しすぎないしやっていて楽しい。スパイダーマン的な動きが色々できたりアクションも派手。ゲームメカニズムとしては基本的には前作そのままでやることもそのままだが、色々追加要素（糸を渡したりとか）もあり、そこそこ複雑化していて楽しくはなっている。空飛ぶアクションは苦手だったのでそこはちょっとイマイチだったが。

ストーリーも複雑化していたが、でもきちんと繋がったストーリーになっていて感心した。特にLiのストーリーラインがなかなか良かった。ただ、ピーターとマイルズのダブル主人公制はそんなにすごく機能しているという感じではなかったかなと思う。あとMJ強すぎでは。というかMJの持ってる武器が強い。スパイダーマンたちもそれ装備しなよ！と少し思った。

総合的な満足度という点では、サブクエストがかなり少なかったように思う。前作ではスパイダーマンのマスクを被った猫を探すみたいな些細なサブクエストがたくさんあって楽しかったように記憶しているのだが（スパイダーキャットは本作でもちらっと再登場していて良かったけど）、そういうサブクエストが多くなかったかなと思った。序盤のサブクエストの一つはかなり良いものだったが、ああいうのがもう少し色々あると楽しかったかなぁ。一方で収集要素は増えていたけど、そっちはそこまで面白さを感じられず……。

サブクエストというかサブストーリーでいうとThe Flameのストーリーライン、あれで終了なの？　最後の一つをやり逃したのかと思ってしまった。続編を作る気満々だから、続編へのヒキも考えての展開だったのかな。

続編といえばエンディングからは続編作る気がビンビン伝わってきたが、アメコミ知識がなさすぎて最後に名前だけ出てくるキャラクターに「えっ誰？」となった。速攻で検索して把握しました。

というわけで、色々言いたいことはあったが総合的にはすごく楽しかった。続編も楽しみです。

数週間前くらいに会社で導入してもらって、github copilotを使ってみている。

今のところ、すごくいいっていう感じではない。copilotの動作、おおむね

• 関数などの名前だけ書いて空白にしておくと、関数全体の中身を勝手に埋めてくれる
• 細かい修正をしているときなどの補完入力的な挙動
• コメントなどの入力支援

と言ったところであるように思う。が、

• 最初のパターンはあんまり使ってない。出てきたものも微妙なものが多い気がする
• 細かい修正は便利なことは多い。特にGo言語はエラー処理などでboilerplateが多いので、そういうところでやってくれるのは本当に助かる
• ただ挙動として、プログラミング言語の意味的な情報（型とか）を利用しているわけではなく、周囲のコンテキストなどをプロンプトとして生成しているだけなので、結果として「雰囲気で補完している」ようなことがままある。ないフィールドを補完してしまったりとか。
• コメントの入力支援はなかなか便利。特に英語が母語ではない身としては割と助かる。ただそういうことではない、みたいなコメントも多い気がする。

というわけで、便利は便利なんだがなけりゃないで構わないな……という気持ちもある。個人的には、コメントの文章とかのこなれてない表現をいい感じに編集してくれたりしてくれた方が助かるのだが、copilotはそういう機能ではないなあ、という話ではある。

ただ、もっと最初のパターンを使いこなすようになってくるともっと生産性が上がるのかもしれない。まだ「上手い使い方」がわかっていない感じがある。関数の名前に加えてコメントを適切に書いたりと言った、一種のプロンプトエンジニアリングでもっといい感じにできるのかも。その辺を追求するべきなのかどうかは悩みどころ。

---

さて、そんなことを思っていたらcopilot workspaceの話題を見かけた。

すごい。すごいけど、このcopilotの現状からしてどこまでできるようになるものなんだろうか。

これまでの自分の体験としては、確かにすごいけどそこまでのことができるようには思えないようにも思える。ただ、それなりにきちんとした実装方針を提示すると実際のコードや修正をそれなりの形に持っていける、というのは全く不可能ではないような気はする。この実装方針のブレークダウンが肝で、そこをうまく作るためにはそれなりにプロンプトエンジニアリングが必要な気がするし、現在の実装に基づいて具体的にissueを設定しないといけないんじゃないか、という気がする。まあただの想像ですけど。

ただ、そのようにしてなされた実装はどちらかというと設計が汚くなったり重複したりとなってしまいがちなんじゃないか、という気もする。同じようなコードを何度も書くことはAIにとってはそれほど苦ではないような気がするので。そしてこれを継続していくとコードは複雑化し、読めなくなっていき、メンテナンスができなくなっていったりするんじゃないだろうか。そこで適切なリファクタリングを導入する必要がある。もちろんそれにもcopilotを使って……となっていったりするのかな。

ところで、複雑なソフトウェアにおいては、問題をどのレイヤでどのように解決するかが自明でないことがよくある。copilot workspaceはそういう問題を解決するものではないだろう、と思う。例えば、ChromeOSのウィンドウマネージャを作っていたとき、「なぜかこのタイミングでフォーカスがあるはずなのにない」「フォーカスがないはずなのにある」みたいなことがある。その問題を解決するのに一番単純な方法は、問題が報告された場所にif文を一個足すことだったりする。しかしそうやっていくと管理するべき状態はどんどん複雑化し、また別な予測不能な問題を引き起こすこともある。でもそこでイベントの流れをよく追ってみると、正しい修正は別なコードの分岐のところに適切な処理を入れることだった、みたいなこともあったりする（そしてそこまでわかってみると修正は非常に単純であり、1行で済んでしまったりする）。

ソフトウェア開発ではそういうことがよくあるわけだけど、この種はAIは（まだ？）そこまではやってくれるようにはならないだろう。issueでもdiscussionの流れを見て……とか言ってたし、そういう分析や発見をissueにどんどん足していってもらうのが前提で、そういう全てを見て実装方針を決定したりするのだろうが、そのためには人間がそういうことをコメントに足していく必要がある。これまあ、悲観的に言えば「AIがソフトウェアを書くようになり、残された人間の仕事はデバッグだけ」ってことな気もするが、別な言い方をすると人間の仕事っていうのは「何が正しい動作なのかを考えて決める」「問題に対してどのような修正を行うべきなのかを決める」といったところとも言えるかもしれない。

子が3歳になった。誕生日会をやったり、プレゼントをあげたり、まあまあいろんなイベントをこなした。

それと別に保育園でもお祝いをしてもらったようで、アプリ経由で写真が送られてきた。Happy Birthdayと書かれた壁紙の前に撮って記念写真を撮ってもらったもののようだ。Vサインのような手を作っているが、よくみると手の指は3本立てている。

それで思い出したが数ヶ月前のこと。どこかに買い物をしに行った時だったかと思うが、適当に子供の写真を撮ったりしていると、子もポーズを取って撮影されてくれたりする。その中でVサインをしていることがあった。そして、自分はtwo歳なのでこうしているが（子は日本語と英語が混ぜこぜになっている）three歳になったらこうするのだ、といった趣旨のことを述べて指を3本立てて親に見せたのだった。

そのことを覚えていて初志貫徹して、3歳になったから指を3本だろと思ってそうしたのだろうか。それともそれと無関係に保育園の先生から何か言われたので3本指にしたのだろうか。

正直なところその辺のことはよくわからないし、そもそも「2歳だから」と言う理由でVサインをするという発想自体も、保育園の先生か同級生から仕入れた発想だったのか、自分で考えたものだったか、その辺も不明ではある。

それはさておき、こういうことは書いておくことで覚えておきたいなと思っていたので書いておくことにする。

---

ものすごくどうでもいい余談であるが、この文章を書くにあたって一応Vサインの情報をwikipediaで読んでいたところ、日本における事例が妙に詳しく書かれていて興味深かった。そんなわざわざ特記するほどのことなのかはよくわからないけど。

なんか最近になって、VS codeを起動しているとファンが回るようになってしまった。topで調べると関連するプロセスがCPUを100%利用しているので、これが原因だろうとは思う。ただプロセス名が全部codeなので、どんな処理をしている奴がどんな理由でCPUを使っているのか、いまいちよくわからない。仕方ないのでVS codeを再起動するとまあ直ったりするのでそういうふうに使っていた。

今日もそういうことがあったが……いい加減うんざりしたので、調べてみることにした。

VS codeにはprocess explorerが同梱するようになっていたようだ。Ctrl-Shift-Pでコマンドパレットを起動して process explorer を調べて起動すると別ウィンドウが開いて教えてくれる。この機能は正直なところ完成度があまりにも低く、例えばCPUやメモリ使用量でソートしたりできないし、私の使っているLinux版ではCPU利用率が全く取れていないようで全部0%になっていたりするが、必要最低限の機能はある。自分の場合、そこまでプロセス数が多くないのでひとまずこれで乗り切れた。

さて、VS codeのウィンドウからはCPU利用率がわからないのでtopで問題のプロセスのPIDを特定し、それとVS codeのウィンドウにあるPIDの表示を突き合わせたところ、どうもgoplsを起動・管理するユーティリティプロセスが暴走していたということがわかった（ところでChromeでは、メインのブラウザプロセスやblinkを動かすレンダラプロセスの他に、外部コマンドやプラグインを別プロセスで安全に動作させるユーティリティプロセスというものもある。こういうjargonがelectron経由でこういうところにも見られるんだなーとちょっとした感慨がある）。しかも管理対象のはずのgoplsはdefunctしている。何らかの理由でgoplsがクラッシュするか動作を終了したけど、それを管理するユーティリティプロセスの側がその状態をうまく扱えておらずおかしくなっているという問題のようだ。なんかビジーループしているんじゃないだろうか。他のgoplsプロセスは普通に動いているのでVS code全体としての動作には問題が起きていない。要するにCPUの無駄遣いであった。

VS codeのprocess explorerから右クリックで個別プロセスをkillできるので、問題のあるユーティリティプロセスをkillして問題解決。問題の把握方法と単純な解決策を理解できたのは良かった。

まあしかし今後また起きると面倒なので、goplsの問題というべきかVS code側の問題かわからないけど、直ってくれるといいな。あとタスクマネージャ、流石にCPU利用率ぐらい取れるようにしてください……。

最近ふと気づいたネタです。

Googleのmanaged Kubernetes環境であるGKEで、新しく作るkubernetesクラスタには名前をつけます。まあGKEでなくても大抵はそうですが。利用者の識別のために何らかの名前をつけるわけです。識別のための名前なので、名前は重複しないように選ばないといけません。ではどのレベルでの重複が問題なんでしょうか？

例えばs3のbucketの名前とかは世界全体で重複しちゃダメですね。GCPのプロジェクトIDも同様です。一方、GKEのようなリソースの名前では、当然ながらプロジェクトIDが異なれば同じ名前のものを使えます。利用者側としても自分が指定したものがわかればいいので（ユニークなIDは内部的には付番されているはずですがこれを使うことはありません）。つまり自分用に気軽にmyclusterみたいな名前のクラスタを作ってもよい。当たり前のことですね。複数のプロジェクトが同じ組織に属している場合などで考えると当たり前とは言い難いかもしれませんが、まあそれでも大丈夫ということになっています。単にややこしくなるだけのことです。

さらにいうとGKEのクラスタの名前はもっと細かい範囲でも識別可能なら同じ名前でも大丈夫なようになっています。例えばリージョンが異なれば大丈夫。例えばus-central1にmyclusterを作ったら、もうus-central1にはmyclusterという名前の別なクラスタは作れないけれど、違うリージョンであるus-west2には作っても問題ありません。

さらにややこしいことに、GKEのクラスタはリージョン全体にまたがるregionalなクラスタと、単独のゾーン（availability zone）だけに存在できるzonalなクラスタがあります。そしてzonalなクラスタであれば、同じリージョン内でも違うゾーンなら同じ名前でも良いようです。つまり同じus-central1内でもus-central1-aのmyclusterと、us-central1-bのmyclusterが別個に存在しても良いのですね。

さらにさらに。regionalなクラスタとzonalなクラスタも共存できます。というか疑問に思ったのでやってみたらできました。つまり、us-central1-aのmyclusterとus-central1-bのmyclusterがあり、同時にus-central1に存在するmyclusterが存在しても良いわけです。この時、regionalなクラスタのノードはzonalなクラスタのノードと同じゾーン内に共存しています。していてもまぁ問題ないわけです。

まぁだからどうかというと、現実的にはこんなややこしいことをする利点は一切ないのであんまりやられていないと思いますが、やろうと思えばできるんだなあということでした。