ブロッキングかノンブロッキングかという議論、10-20 年前と比べるとだいぶどうでもよくなった。これは全ての二項対立に言えることだが、理論的な良さ・悪さは個別の実装のがんばりによっていくらでもひっくり返る。

ブロッキング API と大量のスレッドが嫌われた理由の一つは OS スレッドのオーバーヘッドだった。スタックとかのためにアロケートされるメモリや、スケジューラへの負担。

スケジューリングを自分で持つような言語処理系だと、たいがいスレッドはずっと軽量になる。その筆頭は Go や Erlang だろう。Java Project Loom の Fiber も似たようなものになりそうな雰囲気がある。OS に fiber 的な仕組みを突っ込むこともできることはできて、先の Project Loom の資料は Google が C++ fiber のため Linux kernel を改変している事例に触れている。根本的なレベルで言語(C++)の可搬性を損なうそういう変更はちょっと勘弁してほしいもんだけれども。

ランタイムによる軽量スレッドの反対にいるのがコンパイラによる非同期の隠蔽で、Haskell の do syntax にはじまり C# を経て async/await 構文は多くのメインストリーム言語が備えるに至った。Async/await はたしかにシステムの負担は少ないが、yield 時にコンテクストを heap に避難する必要があるためコンパイラの optimizer から見えるコードは分断されるし停止再開もキューへの出入りがあるし、真にまっすぐなコードのように速くはならない。システムへの負担がコンパイラとライブラリに皺寄せられている。

Fiber によってランタイムの負担を減らすアプローチと、非同期構文でコンパイラがランタイムの負担を引き取るアプローチ、どちらが良いかは結局実装次第。

そしてアプリケーションプログラマからすると、どちらを使うかは性能を意識して選ぶというよりエコシステムとの親和性で半自動的に決まるものになった。この話題で喧嘩できるのはレガシー言語のユーザーと真にヒマな troll だけではなかろうか。（そしてこれらは大部分が重複している。）どちらでもない人は完全にほっといてよい。

レガシー言語のユーザである自分はもともとノンブロッキング寄りの派閥だったけれど、Android の仕事をはじめてからはブロッキングでスレッド作りまくるのにも一定の理はあると考えるようになった。

OS スレッド、オーバーヘッドがでかいだけあって OS やランタイムの支援が手厚い。たとえば OS スレッドは止めてダンプできる。Thread dump はデッドロックのデバッグになくてはならない。ノンブロッキングの世界は一見 deadlock が無いように見えるけれど、結局依存関係が循環したり待つべきものを待ちそびれると dead lock 相当の問題は起こり、しかも多くのノンブロックシステムはそのデバッグ手段を提供していない。

同様に OS スレッドは Systrace やプロファイラのようなツールで実行フローを可視化することができる。ついでにロックの競合もランタイムが教えてくれる。これがコンパイラベースの非同期になると OS からは実行フローも依存関係も見えなくなり、性能解析が辛くなる。

などデバッグや性能分析のしさすさという点で OS スレッドとブロッキングには非同期構文にない良さがあり、自分の仕事にとってそれはすごく重要。もちろん Android で非同期を捨てタスク毎にスレッドを作りまくるのはそれはそれで非現実的だけれども、一方で GCD のある世界ほど非同期を強く推す必要もない気がする。Android にも GCD 的なものがあれば事情も違うかもだが。がんばれ（TODO: あとで観る)！ Java の Executor とか 10 年以上進歩してないじゃんか・・・やる気出せよ・・・。

話がそれた。ノンブロッキングな世界にある性能解析やデバッグのやりづらさも、言語処理系のコード生成やランタイムががんばって色々実装すれば解決する問題かもしれない。OS には皆が使う故に大量のエンジニアリング支援をつっこめる強みがある一方、言語処理系がコードを annotation すると簡単に解決できるはずのことはたくさんあるし、ツールも誰かがやる気をだして作り込めばよいといえばよい。たとえば Chrome には一時期 Promise Debugger というのがあったらしい。

非同期構文を持つ言語はどのくらい性能分析やデバッグを助けてくれるのか。自分からは今の所あまり助けてくれていないように見えるけれども、不勉強なせいで自分が知らないだけかもしれないし、今はなくても言語の成熟にあわせて整ってくるかもしれない。

なのでどうしても二項対立で口論したいならせめて具体的な実装２つを戦わせてほしいし、そもそも喧嘩するヒマがあったら自分の使っている言語や OS が良いものになるよう足りてないものを議論したり作ったりで応援してほしいもんです。

つまり JVM や ART は Executor や VM や ftrace と実行フローをコミュニケートするための API を足して Systrace やプロファイラの可視化をなんとかしろ！

増えすぎた体重を減らそうと減量を初めたのが 2 月。三ヶ月で 73.4kg から 62.6kg まで減らし、無事目標の 63kg を突破した。めでたさを記録しておく。手元の記録によると引っ越し直後の 5 年前には 65kg くらいだったらしい。胃潰瘍でやせ細っていた時代の名残。5 年間で +/-10kg を往復してしまった・・・。

最初は軽く食事を減らしてみたものの体重が変わらず、もうちょっと攻めた方法にと intermittent fasting / IF すなわちプチ断食を試した。自分は The Obesity Code というダイエット本を参考にしたが、Reddit の Wiki や WeFa.st という IF 愛好団体のサイトでだいたい必要なことはわかると思う。WeFa.st は Jack Dorsey も IF してるという新聞の記事で存在を知り、こんなシリコンバレー系無駄に意識高いアホなやつらと同じことをしていたとは・・・と残念な気持ちになってしまった。同じバカっぽさなら Reddit の肩を持ちたい。どうでもいいけど。

IF はその名の通り断続的に食事を抜くことで体重を減らす。食事を抜く頻度はキツさと体重を減らしたい度合いによって色々。自分は「週 2 回食事を食べない日を設ける、ただしその断食日も 400kcal は摂取して良い」というルール (ジャーゴンでは 5:2 と呼ぶ) からはじめ、次に 400kcal の部分をやめて完全食事レスに切り替え、最終的には「週二日食事レス＋週一日晩飯のみ」に落ち着いた。月曜金曜は食事をとらず、水曜は晩飯だけ食べる。

細かいコツとかは上のリンク先を参照のこと。IF 信者は色々効能を説いており、インターネットでも検索すると体験談がでてくる（この文章もそうした体験談の一つである）が、信者以外の共通見解は：減量効果は他の減量メソッドと同程度、ただし挫折しやすいのが欠点、というくらいらしい。

個人的には「一切食べない」というわかりやすさが良いと思った。もうちょっとだけ・・・みたいな誘惑と戦う余地がなく諦めがつきやすいし、制限しない日は普通に食べられるから気がラク。なお普通に食べると言っても snack と sugar はやめている。

体脂肪がある限り食事を抜いても腹減り感があるだけで倒れたり意識が遠くなったりすることはまったくなく、従って体重が増えたらしばらく食事を抜けば良いと身を持って学べたのは良かった。肥満への恐怖が薄らいだ。

目標を達成したこのあとはどうしたものかなあ。

信者になったことだし IF 自体は何らかの形で継続したい気がしている。リバウンドの懸念があるだけでなく、休肝日ならぬ休胃腸日があるの、体を休めてる感じでよい。あと食事がないと腹は減るけど食事の時間は浮くし、食後の胃の重さや眠さもなくなりその点では快適。

体重がどこまで下がるか見届けたい好奇心がある一方、週三日は若干きついのも事実。キツいのを続けてなんとなく破綻させ失敗した気持ちになり次に体重が増えた時に IF する気がおきない、というのは避けたい。

まず週二日にして、しばらく様子見としよう。体重は測り続けて経緯をみたい所存。やめたくなったらやめます。

Pragprog 20 周年版(Beta)読み始め のフォローアップ。

時代が内容に即してない、という印象は間違っていた。コードの部分はそれなりに書き換わっており, Ruby のみならず JS, Clojure, Elixir, Python までサンプルコードがいろんな言語をいったいきたりしていた。特に Elixir はさすがに本をだしているだけあって強く推されており、actor-based concurrency を含め Elixir の推し機能を他言語の類似機能と比較しながら軽く紹介していた。動的型言語界隈の流行りを全然追いかけていなかった身には目新しく、Elixir の本は読んで見る気になった。一年に一つ新しい言語をやろうと勧めてきただけのことはある（なお序盤にあるその自己投資に関するセクションはまるまる残っている。）

そんなかんじでテクノロジ回りはまあまあ書き換わっており、日本語の改訂版を読んだ時に感じたこりゃねーわ感はだいぶ薄れていた。たとえば MVC や Wizard の話などは姿を消し、かわりに ReactiveX のセクションが増えている。プレインテキストどうこうの話はまだあるが、コード生成の話は消えてかわりに ebook もビルドしようぜ、みたいな話に姿を変えていた。あんたら出版社だもんな。

テストの話も「20年前はテストしやすいコードだとか単体テストしろと説得する必要があったけど、もうそういう時代じゃないよね」とはじまり、TDD いいよ、でも原理主義になりがちだから気をつけてなどと話し時代を回顧する。そのあと Python の Hypothesis というツールをつかった property based testing を紹介し、セキュリティの話に進む流れ。Hypoethesis いいじゃん。今度ためそう。

説教セクションは小さな改定として日々の仕事記録 (engineering daybooks) の話が追加されており、やはりみんなやってるね、などと思う。

要素技術のでてこないセクションは旧版と同じ内容も多く、それらに新味は感じない。ただ当たり前の話をしているように感じるのは、たぶんいいことなんだろうね。

合意できない話もそこそこある。それは古臭さより立場の違いから来ているように感じる。

Dave Thomas と Andy Hunt はもともとが自営業コンサルで、その後電子書籍出版で起業し small business で食ってきた人たち。仕事では好きな動的言語をテキストエディタで書いてる。自分は各種零細で C++ を書いたあと感じの悪い大企業の末端として Java のスマホアプリを IDE で書いてる。プログラマのキャリアとしてある意味で反対側に振れている。彼らの価値観に自分が共感できないのは、まあ仕方ない。

自分は彼らの定義する pragmatism に同意できない。流行りには乗らず人の入れ替わりが少ない安定した小さいチームで顧客やエンドユーザと話しながらフィードバックループで物事を良くしてこうな、みたいのは、Basecamp 勢の自己啓発書に感じるどうでもよさに通じるものがある。そういうライフスタイルはきっと素敵だろうけれど、我々そういうんじゃないんで・・・という他人事感。

自分は流行りものに乗れるものなら乗りたいし、チームは適当に人が出入りして規模も大きくなっていく方が景気がよくて好きだし、フィードバックとかいわれてもエンドユーザ多すぎだし (チームとして UX study とかはしてるわけだが、それは「顧客との対話」みたいのとは違うでしょう)、物事はしばしばインクリメンタルに進まずバーンと変わって阿鼻叫喚になるものだし。まあ最後のやつは特段好きではないけれど世の倣いと受け入れている。

結局自分の関心は問題解決とかよりソフトウェアテクノロジの進歩を見届ける方に寄っているので, The Pragmatic Programmer の想定する地味に人々の役に立とうとする craftmanship な皆さんとはいまいち反りが合わない。ただそれに文句をいう筋合いはなかろう。

逆にいうと自分の価値観の偏りによって分かり合えなくなってしまった相手というのが世の中には結構いるということで、それはプログラマについて何か書くとき気をつけたほうが良いのだろう。

過去に読んだり挫けたりした技術書を思い出せる範囲でリストしてみた (草稿注: 本のリストは面倒が多くなりがちなので公開時はリンクしないかもしれない。)

数えると、読んだと言えるのは 170 冊くらい。すごく少なくはないが、学生バイト時代もいれて 20 年プログラマしていることを考えると年間十冊以下で、多くもない。技術書好きは名乗れないことに気づいてしまった。特に 2010 年からの数年、つまり今の会社に入って東京で働いていた頃は全然読んでない。この時期は読書に限らず色々さぼっていて、自分のキャリアの足を引っ張っている。

技術書を読むのはいいことなのだろうか。もちろん時間が無限にあるなら読んで損はないし、時間が無限になくても読書ならではの良さはある。けれど他の career progression activities との兼ね合いは昔信じていたほど自明でない。一方で技術書とはいえ読書には楽しみの面もあり、それを享受しきってこなかった後悔も少しはある。そして同じ本を読むにも上手い下手はある。

総体として、自分はまあまあ読んでいるけれどもうちょっと読めばよかったし、せっかく読むならもっと良い読み方もあったね。

リストづくりを通じて技術書読みへの意見が少しは整理されたので、稿をわけていくつか書きたい。自分は本を読む本やその recommendation list にある本の著者らのようなハードコア読者ではないけれど、カジュアル読者の意見にも何らかの意味はあるでしょう。書いたらここでリンクします。

Digital Minimalism の話のつづき。

歩きながら考え事するのは意味があると Cal Newport は主張する。自分も合意するが、一方で歩きながらの考え事には難しさもある。

自分にとって一番の困難は、考えを積み重ねるのが難しいこと。考えを積み重ねるには、考えが脳の容量を超える前にスナップショットを書き出し形を与える必要がある。自分はこの容量があまり大きくないのでこまめな snapshoting を必要としているが、歩きながらはそれが難しい。結果として同じ事をぐるぐると考えてしまう問題がある。

同じ考えをぐるぐるする問題に自分は苦しめられがち。世間ではこれを自動思考と呼ぶ。自動思考も書き出すことで対処できる。従って考え事をするにあたっては何か書くものがあったほうが良い。

書き出しメディアとしてためしに持ち歩き用の紙のノートを買ってみた。徒歩通勤で持ち歩き、podcast や audiobook を聴く時間を減らして考え事をする。そして snapshot を書き出す。割と良い。以下雑感:

• ハードカバーのノートがよい。膝の上などで書きやすい。カバンには入れず手に持っておくと friction が下がってよい。
• しかしさすがにどこでもノートをとれるわけではない。基本的には公園などいくつかのチェックポイントで書いている。たまにほんとに立ち止まって書くこともある（田舎なので可）。
• 仕事後の帰路が特に捗る。積み残した仕事を振り返り、明日なにしようなどと考える。仕事日記のかわりになる。
• 歩き出し 10 分で考えがまとまり、書き出すと気が済むこともしばしばある。気が済んだら考え事は切り上げて podcast や audiobook を聴く。
• スマホではダメなのだろうか？自分はスマホを the source of distraction  だと考える Cal Newport 派なので紙だけど、スマホで良い人もいるとは思う。あと音声でメモできたらかっこいいかもなとも思う。

夏のあいだはいいけれど、冬はどうかな。

最近はプログラマ向けの技術書を読んでもムカついたりがっかりしたりばかりで、読みたい技術書を探すにも良い技術書評家はいないし、もうプログラマ向け技術書というジャンルは終わってしまったのだろうか。それはなぜか。

・・・というような不満をもっていたが、考えているうちにこれは概ね濡れ衣に思えてきた。端的にいうと、一線を退いた元おたくが「最近のアニメ（などの得意だったおたく分野）はつまらん」というのと同じ現象が自分に起きているだけな気がする。

キャリアの停滞

まずマンネリ化。自分はキャリア初期のたくさん学ぶことのある時期は終わってしまった。これは雇用という点では良いことだが、学びのある本に出会う確率を下げてはいる。多くの人が「これは必要」と思う話題ほどたくさんの本が書かれる。中身はどれも似通ってくる。新しい読者が必要なものに出会う確率はあがるが、必要なものを読み終えた読者は同じものの繰り返し、すなわちマンネリ化にがっかりしがち。マンネリ化を打破したいならキャリアを大きく舵切りする必要があるが、それは雇用と収入を危険に晒すので困る。

キャリアの方向転換をしなくても順当な出世路線を進んでいれば新しく学ぶことはありつづけるように見える。この話を書くにあたり InfoQ の Book Review セクションを見ていたらリーダーシップや経営の話の多いこと。こうした upper management への aspiration があれば世の中の（広義の）技術書で読み物に困ることは少なそう。いわゆる「ビジネス書」は技術書に限らず人気ジャンルである。自分もビジネス書は嫌いではないけれど、根本的には他人事なので純粋な技術書ほどの熱意はない。

コンテンツ消化のサボり

自分は 10 年前くらいに技術書は英語でしか読まないと決めてから大きく読書量が減った。外資系会社員になるにあたり立てた意識高い系の目標だったが、完全に裏目に出た。純粋に読速を落としただけでなく、その副作用で意欲が削がれてしまった。この問題は数年前からようやく解決しはじめたけれど、今度は子どもができて時間の絶対量が減ってしまった。

自分のコンテンツ消化不良には２つの症状がある。1 つめはコンテンツ選びの偏食化。プログラミングというものへの自分の意見の先鋭化もあり、意見の合わない主張の本は腹が立って読めなくなる。自分の意見は（すくなくとも自分にとっては）正しいと思っているので反りが合わないこと自体に問題は感じていないが、コンテンツ消費者としては反りの合わないものも幅広く摂取して視座を広く保つ方が良いのではないか。A grumpy old reader は望ましい姿ではない。時間のなさ自体、偏食に輪をかける。本を読まない理由をがんばって探すようになる。この態度も良い読者とはいえない。

もう一つの症状は新刊感度の低下。読むべき本を探すのに時間をかけなくなった。自分の行動範囲から書店が消えたせいもあって、向こうから面白い本がやってくることがなくなった。読む本を必要に応じて探すようになった。効率という点でこれは必ずしも悪いことではない。けれど無駄の生む serendipity がないと読書という行為全体の楽しさは薄れる。

要するに「本を探す、本を読む」という行為にかける時間の絶対量が減ってケチ臭くなった。その結果見返りが少なくなり、楽しみが削がれた。

ジャンルとメディアの変遷

「綺麗なコードを書くこと」が関心の中心にある時代があった・・・と思う。「オブジェクト指向」がホットな話題だった。アジャイルの一環である TDD もリファクタリングも DI も、広義ではコードの綺麗さすなわち変更に強く保守しやすいこと、をめぐる話題だ。今は、少なくとも昔ほど「コードの書き方」それ自体が注目を集めていない気がする。

自分はコードの綺麗さを長いこと追求していた。ある時期から行き過ぎを反省し意図的に気にするのをやめて、今は割とどうでもよくなった。一方で、「オブジェクト指向」（関数型でもいいよ）や「リファクタリング」のようなコードの書き方に関する大きなブレークスルーがやってくるんじゃないかと心のどこかではいつも期待していて、それはきっと書籍という形で届くという期待もあって、でもその期待は裏切られ続けているように感じていて、失望がある。

最近までそこそこ盛り上がっていたアジャイルの思想的後継に Microservices や Devops がある。これらの話題は広く語られ、本も割と売れているようだ。けれど Microservices にしろ Devops にしろ「オブジェクト指向/関数型」のような狭義の「コードの書き方」つまりソースコードの textual representation に関する話題ではない。ソフトウェアのフレームワークやアーキテクチャやリリースプロセスの側に重点がある。

コードの世界のイノベーションは、ふつうに続いている。わかりやすいところだと Flux とかは DI に匹敵するインパクトがあると思うし、Event Sourcing や Service Mesh みたいのもデザインパターンの後継と言える。Rx から async/await の流れを数えてもいい。メインストリーム言語も格好良いのがふえた。ただこいつらは本ではなく (Redux, Kafka/Samza, Istio, Rx, Kotlin のような) 実装として世に登場している。書籍は二次情報にすぎない。そして書籍に存在感のある Microservices にしたって主要な情報源はオンラインにある。

そしてどのみちサーバサイドをやってない自分にこれらの大半は縁遠く感じる。モバイルもホットな話題は年一回の開発者会議なりオープンソースプロジェクトなりが中心で、書籍はおいてきぼり。ついでに「コードの綺麗さ」においてモバイルは出遅れがちである。（反論はご自由に。）

結果として、自分が身近に感じられるソフトウェア開発の新しくてかっこいい話題を学ぶ感動や興奮は書籍から得るのが難しくなったように感じる。

いちおう確認しておくとこれは完全に言いがかりであって出版社や著者を責めていない。ただ昔の体験が自分の期待値を決めているので勝手に失望してしまう。

キャリアの停滞も時間のなさも時代性からの乖離も自覚していたが、それが技術書体験の不満に繋がっているとは気づいていなかった。考えてみてよかった。

そこまで技術書にこだわらなくてもいいのではと思うかもしれない。でも自分はもともと本を読むのが好きで、技術書は活字というホビーとソフトウェア開発というキャリアの両方まとめて面倒をみてくれる人生のキラーコンテンツだったので、それを楽しめない失望は大きいのだよ。

自分は技術書とどう向かい合うべきなのだろうか。もっというと、キャリアが停滞し時間もなく時代遅れの自分はどうやって様々なプログラマ向けコンテンツと向かい合うべきなのか・・・は、稿をわけて考えたい。

GCP Cloud Build は AWS CodePipeline にくらべるとだいぶしょぼいが、意外な良さもある。

Cloud Build は stateless である。動かしたい Docker Image の URL と引数のリストを API に投げると、どこかでコンテナが実行されてログがどこかに保存される。必要な情報はぜんぶ API に渡す。コマンドラインだと YAML に書く。なので、割と汎用的になんでも動かせる。ビルドである必要はないし、レポジトリに紐付ける必要もない。（逆にいうと git clone もユーザが明示的にやらねばならず。CI としては面倒。)

これ、自分が前からほしかった「任意のコードを一回だけ実行できる serverless のサービス」そのものじゃん。たとえば Jupyter Notebook を評価して、結果をどこかに置くとかもできる。これを Cloud Function 経由で定期実行すれば Jupyter のダッシュボードが作れる。など夢が広がる。

ただ現状単なるビルド環境なので計算機資源の量とかは選べない。それも指定できるようになると非分散ジョブ実行系として使えるものになりそう。

The Pragmatic Programmer, 20th Anniversary Edition: your journey to mastery by David Thomas, Andrew Hunt | The Pragmatic Bookshelf

正式版を読み終えてから感想を書くのが筋だが読み終えられるか自信がないのでベータ版たるいまの目次と冒頭一割くらいを眺めた感想を書いておく。

むかし Rebuild.fm に出してもらった時に自分の pragprog への感想を話した。その印象は改版によっても大して変わっていない。つまり、内容が時代に即していないように思える。ただ振り返るに当時の意見はフェアでもなかったなと思う。

まずこの本は自分のような一定程度キャリアを積んだおっさん向けには書かれていない。キャリアの序盤に読む本である。そのタイミングで読む本として適切なのかに疑問はあるが、自分は junior な人々の教育について考えることに時間を使っていないので特に意見がない。

ついでにいうと、DT/AH の想定していると思われる職業プログラマのジャンルは伝統的エンタープライズだが、自分はインターネット会社でコンシューマ製品の仕事をしている。この違いも大きいと思う。たとえば仕様の話とか全然噛み合わない。新版では旧版の "Great Expectation" という節がなくなり "Delight Your Users" に置き換わっている。コンシューマ製品だとこれがほぼ全て。

なおこの節は冒頭で "Our goal as developers is to delight users. That’s why we’re here. Not to mine them for their data, or count their eyeballs or empty their wallets." と勤務先含む一部テック企業に喧嘩を売っており、ほんと読む気なくすわ。

つまり自分は対象読者ではないし、対象読者について想像もできない。

二点目。一度書かれた書籍の構成を大きく変えるのは難しい。章や節を足したり引いたりすることはできるし細かい書き直しもできるが、アーキテクチャは変わらない。Refactoring や Reservability を語る本がそうなのは皮肉といえば皮肉だが、現実というのはそういうもんであろう。もとの本とぜんぜん違う内容になったら改版するより別の本として売ったほうが良かろうし。

三点目。著者はどちらも 60 前後で人生後半をエンジョイしており、前線で戦ってる感じじゃない。これに文句を言う筋合いはない。自分も 60 になったら前線にいたくない。 Dave Thomas は三年前に出版から足を洗って Elixir を書いている。Andy Hunt は逆に本気の作家として SF を書いている。Elixir が前線じゃないというと怒られそうだし新版に concurrency の章が追加されているあたりにフィードバックを感じるが、いずれにせよガツガツ働いてガツガツ稼ぐぞ！というフェーズの人たちではない。ガツガツ本を書いてくれと頼む相手でもなかろう。

やはりいま現役でガツガツ働いてる人がちょっとイキった勢いで書いた新しい一冊が求められている気がする。The Passionate Programmer はその点いい仕事をしたが、これにしたって 10-15 年前。

四点目。ソフトウェア産業の成熟。新版は新しく追加された冒頭の "It's Your Life" という節で「プログラマは引く手あまたの稼げる仕事なんだから、それを活かして人生をコントロールしような」と話す。プログラマは稼げる仕事になった。20年前はそんなでもなかった[要出典]。職能の成熟にともない期待されるレベルもあがったと思う。一冊読んですごく色々わかった気になれる時代は終わったんじゃないか。

いちおう義理でもう少し読みます。

追記: The Pragmatic Programmer 一通り眺めた

Cloud Build は随分と Docker 中心の製品である。 まずデフォルトのビルド成果物は Docker イメージという前提がある。そしてビルドに使うツールも Docker イメージとして提供されており、ユーザも自分のイメージを使ってビルドステップを足すことができる。

Cloud Functions は特に Docker は出てこないが Cloud Run や App Engine Flex は Docker である。そして言うまでもなく K8S/GKE は Docker イメージを動かす環境である。

など、GCP はなにかと Docker を要求してくる。GCP はコンテナ推しクラウドなのでややバイアスはあるが、とはいえ自分がボンヤリしている間に世の中の Docker 必須な雰囲気はずいぶん広まっていた。

4-5 年前, Docker の浸透度はここまでではなかった気がする。細々と競合っぽいやつが現れたり現れなかったり、どうなるのかと思っていた記憶がある。しかし気がつけば世の中のコンテナは Docker 一色。企業としての Docker のもうだめっぽい雰囲気との対照がすごい。

雑に調べた自分の理解によれば・・・

• あるとき Docker が OCI という標準化団体をつくって container image のフォーマットを標準化するといいだし、そこに競合および同業者を巻き込むことに成功した。結果としてコンテナ業界にあった Docker ロックインへの不安が和らぎ adoption が進んだ。これは K8S が CNCF を作ったのと似たようなものである。
• ついでに主要な競合であった CoreOS は RedHat に買収され, RedHat は IBM に買収され、現在の IBM はデファクトスタンダードに楯突いたりしない会社なので、結果として Docker やっつけるぞみたいなギラギラした人々がいなくなった。
• クラスタ管理分野での K8S の勝利も Docker 普及の助けとなった。

というかんじで現代に至ったらしい。あってる？

しかし K8S が Docker に依存するとか俄には信じがたい・・・と思って調べると、彼らは Docker と自分の間に cri-o / CRI というレイヤを挟んでコンテナのバリエーションを吸収している。そして GKE は実際に Docker でないランタイムを使うオプションがある。しかし開発者はふつうに Docker でイメージを作って push できる。なぜなら GKE のランタイムは Docker がつくったイメージ、おそらくだいたい OCI 準拠、を実行できるから、ということらしい。あってる？

自分はそんなに Docker 好きじゃないし特に使いみちもなかったのでいつもコピペと SO だのみでだましだまし使ってきた。でもイメージフォーマットは定着したようだし開発者が手元で使うツールとしての docker コマンドも特に良い代替品が出て来る見込みは薄い。もうちょっと流暢に使えるよう労を割いてよさそう。

Docker 社が Microsoft か IBM あたりに買収されればもっと心穏やかになれるのだが。

追記

などと書いた矢先に社長が変わった: Steve Singh stepping down as Docker CEO | TechCrunch

Python の async/await について調べもの。

主な興味として generator を async / await ベースで書けるか知りたい。本文に yield のある関数が自動的に generator になる辛い仕様のない世界は（書き手が気をつければ）実現できるのか。

PEP 492 -- Coroutines with async and await syntax と PEP 525 -- Asynchronous Generators を眺めた結論としては、できなそう。むしろ "async generator" というものが登場してより複雑になった感がある。PEP 492 は冒頭で自分の不満を async/await の動機のひとつとして上げているにもかかわらずそれを解決していない。ひどくね？

翻って Kotlin を見るに, async/await と yield はどちらも suspending function である、というかどちらも coroutine 言語機能の上に書かれたライブラリ関数である。型チェックの助けもあり、Python にあった複雑さは存在しない。Python ももうちょっとレイヤリングをがんばって async/await を generator の延長に実装し、その上で yield の紛らわしさを解消する構文を足してほしかった・・・

以前 Flask の一味 Armin Ronacher が Python の coroutine わからんという記事を書いていた。彼の不満はランタイム API の話が中心だったけど、その複雑さは文法にも染み出している。つらい。

Python の async/await が自分に必要となる場面はそれほど想像できないので、なかったものとしておくのが良いかもしれない。

Marco Arment のつくっている Podcast アプリ Overcast に clip sharing 機能が追加された。（ATP のエピソードも参照。) Podcast のエピソードから一分以内の音声を切り出し、Podcast のロゴがついたビデオとしてソーシャルメディアなどにシェアできるという。これまでソーシャルメディアとの距離があった podcast が、ついにバズる機会を得たのかもしれない。なかなかうまいものを考えたと感心する。アプリの宣伝にもなるので Overcast 以外の podcast アプリが追従する可能性も高い。

一方で podcast をやっている身としては嫌なものが開発されたと胃が痛む。Podcast はソーシャルメディアで buzz らないからこそ気楽にできるのであって、文脈から切り離された言葉尻を clip sharing されたりするとその気楽さは失われる。ソーシャルメディアで buzz らせる断片を探しながら podcast を聴く attention-addicted listener やソーシャルメディアでの buzz を狙ったコンテンツも現れるかもしれない。イヤすぎ。

若干 podcast への意欲が削がれた。Marco Arment はファンだけど、こればかりは流行らないでほしいなあ。

一つ前の作業で Executor をフックすると既存のコードへの変更を小さく大局的な挙動をいじれるとわかったので、当初考えていた高速化を Executor 中心で実装してみる。Handler のようなゴミを直接使わずほぼすべての場所に Executor を配備仕切った序盤のプログラマは偉かった。しかし platform の API が Handler を要求してきて殺意。

いちおう design doc を書いて流し、大きな push back が無いことを確認。実際にコードを書いて試してみると・・・まあまあ速くなった。めでたい。コードを整理してレビューに出す。

レビューを待ちつつ次の手を考える。色々やりたいことはあるが、当面は UI Thread の高速化に注力しよう。複数の device / build flavor の組み合わせで Systrace のダンプを集める・・・のをいいかげん少しは自動化したいので Colab で適当なコードを書く。Systrace 開始、アプリ起動、Systrace 終了待ち、アプリ終了。ファイルを HTTP reachable な場所にコピーしてリンクを返す。これでブラウザから一撃で Systrace を取って表示されたリンクをクリックして結果が見られる。これよくね？100 年前から colab 化しておくべきだった・・・。

ダンプを眺めていると、当初の予定に反し UI Thread の外側にひどいコードをみつけてしまう。これなぜ自分のベンチマークは検出してくれなかったのだろうか・・・というと、レビュー中の自分の変更が入る前はスレッドの隙間に隠れていたのが暴かれてしまったのだろう。逆にいうと自分の高速化の効果はこの最近の変更のせいで目減りしてしる可能性がある。許すまじ。

一方、問題の変更はまだ Release flavor では有効になっていないので、自分の変更 (フラグなし) をさっさとコミットしたうえで あれらが Release flavor に来るのを待ち、flag flip のタイミングでベンチマークが検出するまで知らん顔しておくのも手かもしれない。どうしたものか。まあ自分の変更が入ってから考えよう。

Dev flavor と Release flavor の結果もやや違う。ベンチマークの結果も違うので当たり前ではあるが、Dev ばかり見てるのはよくない。

そしてデバイス間の差も大きい。やはり場当たり的なチューニングはもう限界で、なんらかのヒントに基づきコード自身がスケジューリングを最適化してくれないと厳しい。しかし今年の締め切り内にそれは無理げ。ほんとに？真の優先度はどうあるべきか・・・。

それはさておきどうも UI Thread に注力はまだ若干早そうな雰囲気。

といった見通しを得るにあたり colab は必須だったので、やはり 100 年前から使うべき。