仕事日記、もともとの着想はワインバーグの「スーパーエンジニアへの道」という古い本から得た。
この本は会社員になってすぐの頃に読んで以来、仕事を真面目にする気になるたびに読み返している。別段新しい本でもないし、別にリーダーになりたいわけでもない（原題は Becoming a Technical Leader。）プログラマ向け自己啓発、今なら他にも色々あると思うので特に誰かに勧めたいとは思わないのだが、自分はなんとなく読み返してしまう。今もってるやつなんてこっちに引っ越してきたあとわざわざ Amazon.co.jp で買い直してる。
大した本でもないのになぜそんなに読み返してしまうのかと考える。たぶん、過去に自分が仕事を真面目にやろうとした頃の気分がかすかに蘇るからだろうな。それで背筋が伸びる。
20代の、自分がそのうちリーダーシップ的なものを持つと疑わなかった自分はきっと、この本を読んでやがて自分のテクニカルな技能を捨ててリーダーシップに舵を切るのだろうか・・・（しかし自分なら大丈夫に違いない・・・）とか思っていた気がする。しかし自分はリーダーシップのようなものを得ることは全くなく、というと言い過ぎだけれどそういうのは今の会社に入る前に卒業して、下っ端プログラマとして今日に至っている。なので本書も後半にいくほど段々と縁遠い話になっていく。
・・・とそれはさておき、ページをめくりながら自分が真面目に働いていた事実を思い出すと、ちょっとやる気がでる。そういう本ってきっとみんな別々に持っているんだろうなと思う。
仕事を真面目にやる活動の一貫として、一ヶ月くらい前から一日の終わりに１０分くらいで仕事の日記を書く、ということをはじめた。割と続いている。
一日の終わりというのは退社前ではなく子供が寝たあとから自分が寝る前くらい。就業時間外に仕事のことを考えるのもどうかと思うけれど、一方できっかり nine-to-five で働いていると仕事中はいまいち心の余裕がなく内省的な気分になれない。少し距離のあるところで考えものをする良さもある。
まあ実際は Podcast の編集に追われたりで、翌朝会社で書いたりすることもしばしばだが。朝はもともと早めに行って本読んだりしてるため、職場の匂いからはデタッチできている。
10 分は短い。何をやったか思い出して書き出してだいたいおしまい。立ち入った考え事はあまりできない。それでも何かおかしいことに気がついたり、やり忘れていたことに気づいたりはけっこうある。10 分から得られる効能としては十分だと思う。No pun intended.
意識高い系の工夫として、以下の４つの項を含めることにしている: 気分、発見、感謝、債務
気分は、いいとか悪いとか疲れてるとか達成感あるとか、そういう話。悪い気分が続いていたら早めに気づけるように、というモニタリング目的。
発見は、新たに知ったことなど。コマンドラインの引数から同僚の性格まで。いちおう毎日何らかの歩みは進めていると自分に言い聞かせるための道具。
感謝は、これは完全にスピリチュアルな人みたいでアレだけれども、今日は誰に世話になったかという話。同僚とのインタラクションを思い出し、かつネガティブなことは含めない結果、一人で黙々と働いているという気分を和らげる効果がある。
債務は、やらなければなーと思いつつやっていないこと。調べ物、優先度見直し、バグ直し、など。
こういう必須項目についてのみ書いているわけではなく、むしろ最後に思い出してささっと書いて終わりくらいのもの。中身はなんでもいいけど何かしら書くことを決めておくとリズムができて良いと思った。
追記
その後、最後に「明日やる」のリストを書くことにした。これまでは本文に埋没してたけれど、リストにしておくと翌朝さっと見返せるので。
Cold start 時のベンチマークが大きく下がっていることが発覚したので調べろと言われ、調査をする。しかし warm start 時と比べてこれといった違いがあるようには見えない。さて・・・。
改めて Systrace を睨むと、どうも自分たちのアプリではなく他のアプリが活発に動いている。なぜか。 Cold start を実現するためその測定はデバイスの再起動直後に行われていた。そしてデバイス起動の broadcast intent に反応し多くの pre-installed アプリがなんらかの準備運動を始めていたのだった。CPU が混雑するそんな起動直後でのベンチマーク。そりゃ遅くもなるわ・・・。
実際のところベンチマークは以前から起動直後に測定されているため、これだけが性能低下の原因だと言い切るのは勇み足の可能性がないではない。けどどうせ startup 時に色々やるアプリが増えたんでしょ... と shrug したい面はある。それに起動直後といういかにも non deterministic な環境で安定した測定ができるとも思えない。起動後はしばらくほっといてから測ってちょ、と伝える。測定のターンアラウンドが伸びてしまい気の毒だけれど・・・。
Cold start, 普通のアプリだったらプロセスを殺して page cache をクリアするくらいでだいたいいいと思うんだけど、センサーとかを使い始めるとまったく自明でないのだよなー・・・。一方でセンサーの cold start が遅くなったところでアプリにできることなんて大してない気もするのだが。しかし我々には platform に bug を file する、という責務があるのだった。
通勤中の Podcast をやめてみると書いたけれど、結局再開している。これをやらないと勤務前に頭が英語モードにならず、ややおたおたした気分になってしまうことがわかったため。そういえば podcast を聞くのは単なるコンテンツ消化というだけではなく英語圧という面もあったのだった・・・。
そう考えると、聞き流すよりは集中して聞いて脳内シャドーイングするくらいの勢いが良い気がする。となるとあまりバカっぽいコンテンツよりはそれなりに身のあるものを聞きたい。あるいは一方的な broadcast より conversational なのを聞きたい。商業的なやつはどうしても broadcast ぽくなりがちで、一方 indie のやつはおおむねバカっぽい。トレードオフが悩ましい。
週末の Left Alone 時間が午後にずれこんだため、コーヒー屋を諦めて会社に来ている。なぜコーヒー屋を諦めるかというと、午後は Wifi の混雑が厳しくなりがちだから。最近は書き物環境をほぼ WordPress に統一してしまったため、Wifi が欲しくなるのだった。On the go でちょっと書くならモバイルでいいんだけれど、時間をとって何かするときはラップトップとネットワークが欲しい。彼らの Electron アプリがオフライン対応してくれればいいのだが・・・。
週末に会社にいくなんてのは絶対にやりたくないことのひとつだったし、そういうことをする人々を内心見下していたものだけれど、すっかり見下される側になってしまった。Wifi の有無のようなロジスティクスの都合はさておき、心境の変化について考えてみる。
一番大きいのは、この Left Alone 時間は気分転換というより家の雑事から自分を切り離すための手段である、というところだろうな。自宅でもそこそこ集中して作業ができるなら気分転換先というだけで会社にいくのはいまいちだけれど、今は家から離れたいだけ。なお別に家が嫌という話ではなく、子供がいると本当に気が散るのだよね。たとえゆこっぷ（おくさん）が面倒を見てくれていても、声が聞こえるだけできびしい。なのでもう家以外だったら割とどこでも良いのだよな。
あと今は５時になったら容赦なく退社する暮らしをしているので、仕事や会社にうんざりするほど働いていないせいもあるかもしれない。家の都合があるから仕事のキリがいいところまで働くなんてことはできないから、むしろちょっと働き足りないみたいな。これは言い過ぎだけど、ある種の煮えきらなさはある。
ロジスティクス。家と会社が近くなったので、コーヒー屋も会社も体感距離が大差ない。そしてコーヒー屋は午後になると Wifi のみならず席も空いてないところが多いのだった。
まあ、それでも午前中にコーヒー屋に行くのが一番いいね。早い時間のコーヒー屋の雰囲気がよい。ただいつも午前中に時間をとれるわけではないから、そういうときは会社で妥協します。
Misreading Chat 表面的なところだけ追ってる、という感想を見かける。実際そうなのだが、悲しいことでもある。しかし時間や気力といった予算の都合によりそんなに立ち入った話はできないのだった。話ができない以前に、立ち入ったレベルまでは理解できない。
深い理解に基づいて詳しい話をする podcast は可能か。比較的じぶんがよく知っているものについて話すなら、ある程度は詳しい話ができるだろう。ただそれだと本人には得るものがないし、自分だとすぐ話すことがなくなってしまうね。なんでも詳しい人と言うのは存在するから、そういう人にはいいのかもしれない。
毎回よく調べてきて話すことも、頑張ればできるのかもしれない。それだと毎週やるのは難しいだろうけれども、それはそれで需要はあろう。このスタイルをやるならひとり語りにする方が良い、あるいは一人が話役、一人が聞き役みたいな。
Linear Digressions なんかはこの中間くらいで、host の Katie が専門であるデータサイエンスや機械学習について流行りの話題や気になる技術を調べてきて co-host の Ben に話すスタイル。これは Katie が優れたデータサイエンティストであるがゆえに成立している。自分には専門で追いかけている分野がないので、真似できない。
自分が先端にいる専門分野がない悲しさはある。受け入れているし日々はやり過ごしているが、ときどきその悲しさと向かい合わざるをえない。ひと目につくところで何かを語る以上、自分の vulnerable な部分に踏み込まれることに、あるいはそこ壁を立てることに、慣れないといけない。Blog では慣れたが、Podcast はまだ慣れないね。
よく知らないことをがんばって調べて話す。Revisionist History など商業的な podcast はそうなわけだが。程度を下げたとしても自分が余暇にできる感じじゃないな。
しばらく表面的な話をやっていきます。はい。
via The Untold Story of Japan’s Secret Spy Agency
最初の感想としては、日本の諜報機関も案外ちゃんと仕事してんな、というものだった。諜報機関、基本的にグレーゾーンな生き物なのでいろいろ後ろ暗いところはあるだろうけれど、それ以前にちゃんと人材確保できてなさそうという偏見を持っていた。だから何かやってる、というのは国防的な意味でよいことではなかろうか。ちゃんと監視機構がないというのはまあそうなのだが。
しかし NSA 30000 人はさておき UK の 6000 人に対して 1700 人。数が多ければいいってもんでもないけれど、心もとない数字ではある。記事中でもデータを集め始めたら収集がつかなくなりアメリカに助けを求めている話がでてくる。がんばれ・・・。
自分はそんな 30000 人の電脳諜報部を擁する国で外国人をしている手前プライバシーなどないも同然に感じているからなんとなく感想が雑になってしまうけれど、この日本の諜報部のみなさんを国民はもっと警戒した方がいいんですかね。どうなの。
GANのep聞いたけど具体的にどのproposition, theoremがわからなかったか言ってくださるとよかったかな / 学部レベルの確率統計の知識でprop1とthm1はわかるはず. Thm2も用語調べつつ読めばわかるんじゃないかな
というフィードバック。聞いてる人が論文を手元にもってない前提で話しているし自分も向井さんの読んでる論文は手元においていないのでこのレベルの細かさで話すことはないけれども、一方で何がわかってないかちゃんと理解するのはいいことにも思える。
というわけで論文をちらっと眺めてみると・・・以前よんだとき、自分はそもそも式 (1) がよくわかってなかった気がする。今みるとわからなくもない。記憶をたどるに、まえは式中の P_{data} が何なのかわからなかったせいで行き詰まったのだと思う。文中にも出てこないし。これが要するに training data のことだよ、というのがわからなかった。今回は向井さんの話もあってそういうものだという前提で読めたのでわかった気になれたのだろう。
というところで満足して証明は読まず。ひどい。
妻子帰宅。
一ヶ月を振り返ると:
- 期待していたより生産的でなかった。インターネットで時間を無駄にしてしまうなど。
- とはいえ時間はあった。結果として Misreading Chat 調べ物は過剰に捗った気がする。
- 考え事ができたのはよかった。ゆこっぷ（おくさん）退職後、ようやく自分の体調が復帰して片働き会社員として仕事への取り組みを見直す必要があったなか、いいタイミングだった。
あとは妻子あり状態と独身状態の差を眺めるいい機会となった。そして自分の価値観は完全に妻子持ちに適応済であることを確認した。自分の時間があるのはいいことだけど、かといって独身に戻りたいかというと、そうでもないね。なぜかを説明するのは難しいけれど。妻子ありは（主に金銭的プレッシャーからくる）ストレスはあるけれど、ある種の精神的充足もある。
まったく説明になっていない。これは適応の結果なので別に独身者に結婚や子持ちを勧める類の話でもない。結婚生活とかムリとおもってても案外大丈夫だよというだけで、どちらかというと就職に似ている。学生時代、毎日朝から会社いくとか絶対ムリだわ・・・と思っていたけれど、案外適応できた。まあ働く必要がない身分なら別に仕事しなくていいと思うけど、仕事して金稼ぐってそれほどムリでもないよ、みたいな、そういうかんじ。
ただ家族持ち状態であっても、趣味のコードとかはさておき考え事をする時間についてはどうにかして確保した方がよいなともおもった。それなりにとっていたつもりだったけれども、こうして時間ができてみると足りてなかったことに気づく。特に自分は仕事についてほんとに何も考えてなかった事実にけっこうショックをうけた。その話は別に書く。
いまは自分の作業記録を箇条書きでつけていて、箇条書きのトップベルは time box である。例:
- #1
- #2
- Attack (link to a bug...)
このフォーマットはよくない気がしてきた。なぜなら time box ごとに作業の記録が分断されてしまうから。単純にトップレベルの箇条書きを落とすのはどうか。
- Bug reading
- Attack (link to a bug...)
いい気もする。ただ理想的には timebox を何らかの形で記録したいような気もする。Mac とかだとテキスト入力をフックして timestamp を入れたりできるのだけれど、ChromeOS (+Google Docs) だとそういうツールはないっぽい。いまいち。時の流れをうまくキャプチャしたいのだが・・・。
が、そういって現状維持してもよくならないので、しばらくトップレベルの箇条書きをやめてみよう。
Ask HN: Amazon software engineers, how is the work culture now? | Hacker News
予想はしていたが参考にならんなー・・・。ただチーム間でのバラツキは大きそう。同じようなスレが検索会社についてたったなら・・・と思うが検索会社への悪口はもともと定期的に提供されているので新味はないか。でかい会社というのは部門によって景気も雰囲気もまちまちなので、こういう愚痴スレの biased sample から何かを判断するのは難しいね。
自分からは kzys や dagezi といった知り合いが割と楽しそうにやってるので割と良さそうに見える。ただ日本ドメ企業で鍛えたプログラマはちょっとやそっとのデスマだとびくともしない可能性もあるため、自分のように完全に spoiled なひとが適応できるかは、やや不安。もし日本に帰ったら働けるんだろうか自分・・・。
前にも書いたのだが・・・
Jupyter は色々なものが混じっているのであるべき姿について考えるのが難しい。
- Computational Essay や Interactive/Reproducible Paper, ストーリー
- Lab Notebook
- 作業記録をつけるためのもの。Rigorous である必要。
- たぶん Reproducibility が特に重要。
- アカデミアにとって研究の成果の証拠だから。一方でそれは Producible Paper でもいいといえばいい。（発見のタイミングとかそんなに重要じゃない。）
- しかし Jupyter が Lab Notebook に向いているのかは怪しい。
- Sloppy になりやすいし。ふつうに Evernote/OnoNotes とかでよくね？
- 一方でデータの可視化やキャプチャとかには便利。
- 証拠と自分のための記録は一緒でいいのか？失敗の記録は別でよくね？そして再現性いらなくね？
- REPL
- ブラウザなので履歴にアクセスしやすい。
- インラインで画像を表示できる。
- 探索的な作業ができる。
考察
- 「実験そのもの」と「実験の記録」混ぜる必要は必ずしもないのでは？
- 実験の記録は別に管理する必要がある。
- Jupyter である必要はないが、数値やチャートの生成を考えると活用する余地はあるかも。トータルで(たとえば) OneNote の良さに勝てるのか？それを勝つ方向に進歩しているか（そうは見えないが）？
- 同様に「実験の記録」と「ストーリー」も別。
- ストーリーを Jupyter にするのがすごく流行らないのは、結局は実験記録を整形する手間がかかるからかも。
- こいつらがぜんぶ一撃で済む、ということを暗に期待すると辛くなる。
- Reproducibility もどこまで期待するかで手間がかわる。
- 最終的な成果を reproduce するのには手間をかけて良い。
- 全ての行程が reproduce にする、というのは現状の技術では大変なのでは。
- Jupyter は notebook の実行可能性を担保しない。
- バージョン管理がスムーズでも盤石でもない。
(colab は git がない, ipynb-json-blob 問題, データどこに置くかなど)
- ここは探索の身軽さを優先し少し手を抜いて良いのでは。つまり、がんばれば再現できる程度に記録をとる、ただしツールによる保証(CI, presubmit check)はない。
- たとえばいまいちだった試行の reproducibility にコストを割くのは無駄ではないか。
- 何らかのチェックポイントを reproduce にしておく、くらい？
- これらは現状のテクノロジーの制限なので将来よくなることはありうる。
- 現状の Jupyter は Storytelling ツールとしての進化に重点があるように見える。
- LN や REPL としての改善はあんましがんばってなくね？特に LN としてのがんばりは感じない。
- REPL としては既にまあまあ良いし、可視化まわりの強化は REPL でも恩恵がある。
- LN には無理に使わず、別できちんと記録をとる方が良い。
- Notebook という名前にまやかされない。騙されてたの自分だけかもしらんが。でも reproducibility とかいうのはこの流れだよね。
- Wordpress でやるとかのほうがマシ。
- Reproducibility のツールとして Jupyter はかならずしも良くない。
- Literate Programming や Visualization があるのはよい。
- CI 的な検証を自動化することを支援してない点ではいまいち。
- データサイエンスのしての主張な platform として Jupyter が使われており、データサイエンスの重要な practice として reproducibility があるから Jupyter を reproducible にしたくなるが、現実としてそんなに向いてない。
The Essential Drucker: The Best of Sixty Years of Peter Drucker's Essential Writings on Management (Play Books)
仕事のやる気を立て直すにあたり何か背筋が伸びる感じの本で読もう・・・ではなく聴こうと思い、そういえば Drucker って人気あるけど読んだことなかったなということで一冊。
古臭いし、前半のマネジメントの話は下々的にはどうでもよかったが、Knowledge Worker という概念を売り込む後半はそれなりによかった。なにかとリーダーシップの話になってしまう世の中の本と比べ、Knowledge Worker というのは専門職としてあるのだよ、という話をするので。この Knowledge Worker という概念、今ではあまり聞かなくなってしまった気がする。当たり前になってしまったのかもしれないし、他の名詞に置き代えられたのかもしれない。
もう少し細部を理解しようと paperback を買い直し、昨日届いたところ。読んだらまた感想でも書きます。
ところで Drucker, 日本では妙に人気がある気がする。アメリカでもそこそこ読まれているっぽいけれど, Amazon のレビューの星の数はそこらへんの作家と大差ない。
Drucker の文章にはよく日本がでてくる。Zaibatsu だとか Toyota だとか。昔の日本の影響力が垣間見えて感慨深い。このへんの日本贔屓がかの国での人気の秘密なのだろうか。
・・・とか思いながら paperback の冒頭を読んでいたら驚くべき事実が明らかになった: The Essential Drucker の元になったのは、なんと日本の Drucker 読み物なのだという。Drucker ファンである Mr. Ueda が、過去に当人の書き散らかしたの何冊もの本を通読して抜粋、編集しなおし、三冊にまとめたのだという。それを気に入った Drucker が Mr. Ueda バージョンを逆輸入した際、三冊だと多いねということで出版社が更に絞り込んで一冊にした。それがこの The Essential Drucker らしい。まじかー。Management の話はいらないから Individuals の部分だけ読みたいなーとおもいつつ聴いていたのだが、日本語ではそういう本がある。しかし英語にはない。なんだそりゃ・・・。
Amazon.co.jp の著者ページ をみると、Mr. Ueda はその後も様々なまとめバージョンの Drucker 本を出して啓蒙に勤しんでいる様子が伺える。つまり日本語圏での Drucker 人気は必ずしも Drucker の昔の文章に日本がよく出てくるからではなく、熱狂的 Drucker ファンであるところの Mr. Ueda ががんばったからなのだった! Drucker は本の冒頭で Mr. Ueda を指し "He is thus thoroughly familiar with my work - in fact, he knows it better than I do." とか言っている。そんなこと言われると原著厨の自分ですら Drucker は日本語で読んだ方が良いんじゃね、という気がしてきてしまう。Paperback 買ってしまったじゃないか...まあ絞られた分薄くなってるのでよしとしよう...。
訳者のがんばりでオリジナルの出版国より翻訳先で人気が出てしまう作家は確かにおり、たとえば柴田元幸が訳している作家とかはそういう面がある。Paul Auster にしろ Stuart Dybek にしろ、全然人気なくてびびる。柴田元幸の訳本が翻訳文学ファン以外でどれだけ人気なのかといわれるとわからないけれど・・・。
しかし超有名人だと思っていた Drucker が Paul Auster 枠だったとは、Mr. Ueda がんばったなあ。
REAL ID Act
カルフォルニアの免許は連邦ID互換ではなかったためもうすぐヒコーキ（国内線）に乗る時に免許の他にパスポートが必要だよ、という警告があった。そして免許更新の再に少し手間を書ければ連邦互換の "REAL ID" というやつを作れるよ、という。この REAL ID を諦めればオンラインで免許が作れる。REAL ID のためには予約の上 DMV に行って手続きをしないといけない。別に Non-REAL ID でよいよねえ、とゆこっぷ（おくさん）に言ったら、いやふつうに考えて REAL ID でしょ、という。めんどくささへの耐性が一桁くらい違う感じがする。おかげでたすかっているのだが・・・。
で、仕方なくひと手間かけて取得した REAL ID が届いた。有効期限も 5 年くらいある。めでたい。予約していったおかげか、手続き自体はまあまあ速やかだった。ペーパーワークは電子化され、据え置きのPCから入力するシステムが導入されていた。
平日夜や週末を生産的に過ごせる！と思っていたがダラダラすごしている。
平日夜。インターネットをダラダラやってしまい、結果として就寝が遅くなる。しかし夜は疲れていて時間があったところで頑張れない・・・・という二三年前にたどり着いた結論を思い出した。遅い就寝が貴重な朝の時間を奪っている。もったいない。あと一週間くらいは早寝早起きしよう。
週末も、もっと色々できるかと思ったが家事をして昼寝をして・・・とやはりダラダラしてしまった。週末って、そういえば前の日のうちにやることを決めておかないとぼんやり終わってしまうのだったな。やはり二三年前にはやってたけどこの一年ですっかり失われてしまっていたよ。
もっともそうやってキビキビした余暇をすごす努力自体、結婚したあとにはじめたことなので、独身時代の自分は時間はあったが生産的ではなかったね。早いうちからもてる時間を最大限使って前に進んでいる人たちが、いま同世代のスターになっているのだろうな。
家事育児などで時間がないとぐちぐち言えるほどもともとの自分は生産的でなかった。この事実はがっかりだけれど、一方で普段感じている不満の根拠がファンタジーだとわかったのは家庭平和の観点からよかったかもしれない。どうせ時間あってもダラダラインターネットするだけなんだから、それより限られた時間をうまくつかいなよと。
Computer Architecture, Sixth Edition: A Quantitative Approach
7 章が Domain-Specific Architecture. ここだけつまみ読み.
TPU と Pixel Visual Core, PVC の方が複雑でいまいち読んでいても理解できた気がしない。
ダイサイズという点だと TPU の方が断然でかく PVC はしょせんスマホの co-processor なのだが、一方で PVC を複雑に感じる、というのが不思議なところではある。TPU の方がより機能的な複雑さを削り落として ALU とかに割り振ってるということなのだろうなあ。
そのほかとある CPU エンジニアが最近のスマホのチップには 10 種類以上の instruction set が詰め込まれているのが普通、と証言していたくだりが面白かった。iPhone のチップも 2015 年の時点で CPU と GPU あわせてダイサイズの 1/3 くらいしか使ってないとも書いてあり、この謎チップ というか DSP というか DSA の時代は来てるなあと説得させられる。スマホはその傾向が顕著ではあるのかもしれない。
ともだちがマインドフル·リーダーシップという本を読んでいた。リーダーシップにある人は mindfulness があったほうがいいよ、という話らしい。たしかに。上の人がイライラしたり気が散ってたりするとやだよな。そしてそういう人は一定数いそうではある。
既にどこかで書いた気もするけれど、自分が mindfulness というか meditation というものに興味を持ったのは１０年くらい前に何かの雑誌で記事を読んだ時だった。外資系企業でブーム、みたいな内容だった記憶。最近は mindfulness を名を変えはやり続けている。息が長い。まあ仏教と同じくらいのロングセラーなわけだが・・・。
自分はそのときに半年くらいやってみて効能を感じ、その後も人生の辛い時期になるたび断続的に mediate していた。ただランニングをするようになって憂鬱な気持になることが減り、meditation もしなくなった。運動の方がはっきりと精神衛生に寄与するから。
ただ憂鬱な気持はともかく気が散る現象は続いていて、未だに苦しめられている。抗鬱ではなく集中のための道具としてふたたび取り組みなおしてもいいかもしれない。やりかた、だいぶ忘れちゃったな。
最近どこかのテック資本家が meditation は gdb みたいなものだと言っていた。自分はどちらかというとモニタリングみたいなものだと思う。top みたいな。言いたいことは同じだろう。何かおかしなプロセス（おかしな考え事）をみつけて、kill する。Meditation というのはおかしかろうがなんだろうがプロセス（考え事）が頭にうかんだら kill するプロセスを繰り返す練習。その訓練を重ねると日常生活の中でもバックグランドで top を起動しておき異変にきづき kill できるようになる。結果として集中力が増す。
これを教えに組み込んだ仏教は偉かった。キラーコンテンツ。でもそろそろ独占を手放す頃合いなのだろうね。
仕事のアプリ、長いこと測定されそこねていたが重要な速度上の指標が下がっているから直せという。速かった頃のバイナリを持ってきてトレースを比べるが・・・わからん。これはリグレッションした箇所を見つけて直すより真面目に速くするほうが良さそう。
このアプリは色々マルチスレッドにして速度を稼いでいる。そしてアプリ内で CPU インテンシブな部分(View の構築など)とシステムのサービスを待つのが遅い部分がある。当然後者は非同期に待つ。結果としてぱっとトレースをみただけだと critical path がわからない。
仕方ないのでコードを睨んでいるのだが、むー。
自分は critical path を依存関係のグラフとして理解しようとしている。最終的なオブジェクト A を得るには オブジェクト B と C が必要で、C を作るには D が必要、だからクリティカルパスは B->A か D->C->A ... みたいな。グラフの arc に所要時間を割り振っていく。
このモデリングをコードにマップする方法がいまいちはっきりしない。
まず依存関係のノードがコードの上のオブジェクトとして現れるとは限らない。たとえば最後の測定地点が、とあるシステムからのコールバックが呼ばれたところであるとする。コールバックに引数はない。だから目に見えるオブジェクトがあるわけではない。仕方ないので概念上の Readiness object みたいのを考える。
その一方、コード上存在感がある割に依存関係のノードにならないクラスが多い。具体的には Creator やら Initializer やらの Verb-er class. Java のイディオム的にオブジェクトなだけで、こいつらは事実上の関数である。しか本物の関数ではないせいで、依存関係の in と out をわかりにくくしている。
非同期のわかりにくさという意味では、関数やコンストラクタの引数に Future 的なオブジェクトを渡されるのも辛い。戻り値だけにしてくれ…。
わかりにくさの理由は２つ。一つは Future (ListenableFuture) が入力なのか出力なのかわからないこと。まあ ListenableFuture なら入力だし SettableFuture なら出力なのだが, ownership の行方がすぐわからなくなる。
もう一つは、要するに pure function と IO function みたいのが混ざってしまう、ということだろうなあ。Future にアクセスする関数やオブジェクトというのは非同期のフロー (IO) に参加している。一方で binder の遅いブロッキングコールを読んだりもする (pure). もうわけがわからない。やはりロジックはなるべく pure な感じに書いて、一番外側で IO 的なものを組み合わせる作りにしてほしいなあ。しかし Java というのは文化的にそういう区別をがんばっていないのでどうにもならないのだった。Rx 世代のコードベースで働きたいものであることよ・・・。
ただ Rx 的なコードの性能分析がどうあるべきなのか、と聞かれてもぱっと答えることはできないな。IO の中の時間と自分の pure な部分の時間を、どうにかして可視化するのだろうけれど・・・。
コード中心の分析がそもそも筋悪な気もする。手元にはいちおう Systrace のダンプがあり、これは時間とスレッドの関係についての雛形になりうる。こいつを画像にキャプチャし、その上に依存関係のフローを注釈として書き込んでいけばいいかもしれない。それなら可視化のベースラインを捏造しなくてよくなるよね。こうしてみるかな。
本来なら Systrace の API が非同期のフローをサポートして、手書きで注釈を後付する必要なんてのはない方がよいんだけど。そこは多くを期待するべからずということで。
Boundaries を書いて思い出したこと。
勤務先、自分が入社してから社員数がおよそ 3 倍くらいになっている。いま入ってくる人は自分が感じた以上に大企業の圧力を感じているだろう。たとえば自由度の低さとか。
自分は、この会社は割と自分でやると決めたことをやることができる、というか自分でやることを決めた方がよいと思っている。自分で決めないとマネージャとかが適当に仕事を持ってきてくれるのですごく困りはしないけれど、自分の好みや価値観はマネージャより自分の方がよく知っているはず。
ただ一方でやることに制限がないわけではない。適度に空気を読まないといけない。一方で、空気を読みすぎると自分を縛ってしまう。組織の巨大化にあわせ、空気はどうしても硬いものになっていくから。
比較的自由だった時代、あるいは比較的自由度の高いチームの空気を覚えていると、少しくらいまわりが堅苦しくなっても昔のように振る舞うことができる。多くの場合それで特に問題ない。でもいま入ってくる人たちは空気の味を知らないから、必要以上に自分を縛ってしまうように見える。ちょっともったいない。近隣大企業を渡り歩いてきた人なんかは勝手にやる空気のバリエーションを他所で身につけてくることもあるけれど、新卒とかはどうかな。
一方、自分より前からいる人はより一層自由の濃い空気を体験しており、より一層自律的に振る舞っているようにみえる。個人差はあるけれど。
自分は仕事を選べない受託開発の世界からやってきたため、やることを自分できめる空気に馴染むことがなかなかできなかった。そのせいで自由な時代、自由なチームの文化を無駄にしてしまった後悔がある。その反動で今はなるべく自分で仕事を決めるようにしており、それはうまくいくこともあれば行かないこともある。今のチームではまだ自分の知識が足りなすぎてうまくいかないことの方が多い。けれど仕事は自分で考える方が良い。自分はそう価値観を形成した。コードはどこまでもズカズカ踏み込んで行く方が良いという価値観と同じように。
こうした価値観の正しさを身をもって示すのがプログラマとしての自分の使命なのだろうとぼんやり思う。いまのとこぜんぜん示せてない。
今の仕事はアプリ開発な割にけっこう platform と密着しており、エッジケースのバグなどを踏むことが多い。というか自分がやっているプロジェクトが踏んでしまい困っている。
本来なら platform のコードを持ってきて直したいところなのだけれど、ビルドするのも動かすのもデバッグするのも大変。やりかたもよくわからない。そしてコードが雑然としている割に繊細な部分なので下手に触ると壊しそう。現実問題あまり直せる気がしない。いちおうビルドはしてみたが・・・。
アプリの開発をしていてサーバのコードを触るより、アプリの開発をしていて platform のコードをさわるほうが大変。実行環境の距離を考えると納得いかないけれど、スケールを考えると仕方ない気もしてくる。特定アプリの都合だけでどうにかできるものではない。
Platform とアプリの間の壁は受け入れるとして、連携している別アプリとの壁もけっこう厚そうに見える。そして platform 内部でもモジュール間の壁を感じる。
自分たちのアプリは monorepo に住んでいて、platform は monorepo 外の git repo 群にある。platform の中の壁は、たぶん git repo の間にあるのだろうと思う。連携しているアプリは同じく monorepo に住んでいるけれど、リリースサイクルの違いなどが壁になっている、気がする。
壁があるといっても、別に反目しあっているわけじゃない。相手のコードベースに踏み込んで直すのがやりにくいという話。かわりに相手に直してくれと頼む。頼むのが悪いとは思わないけれど、自分はよそのコードに踏み込んでいくのは得意だと思っていたのでやや物足りない。誰かに依存すると相手の都合に引きずられてしまうし。でも郷に入りてはで、頼み力を上げないといけないのだろうな。組織の壁というのも少しはあるし。
あるときコード解析ツールのグローバルな設定更新にあわせ自分たちのコードベースが間接的に依存しているどこかのプロジェクトのコードが壊れた。そのプロジェクトは解析ツールの設定を変えている問題に気づいていない。
壊れて困ってますとバグをファイルしたあと、ふと自分で直してしまう方が早いのではと思い立つ。たかだか数行の修正。ためしにレビューをもとめアップロードしたらあっさり受け入れられた。修正完了。二時間くらいでビルド回復終了。
壊れたコードのチームが何をやっているのかも、コードをレビューしてくれたのが誰かも、自分は知らない。にもかかわらず 1-2 時間で他人のコードに踏み込んでいって直せる。この壁の低さは monorepo と unified build system の力だと思う。じぶんは monorepo そんなに好きじゃないけど、いいところもあるね。レポジトリやビルド方法が違うと、なかなかこうはいかない。
思えばこのずかずか入っていって直すスタイルは Chrome 時代に身につけたものだ。Chrome もどちらかというと monorepo よりで、一つのツリーになるべく多くのコードを突っ込んである。だからチームやモジュールの垣根を超えてコードをいじりやすい。そして V8 や Skia を直すのには壁がある。この壁は明らかにレポジトリに起因している。意味的に似た関係である WebKit と JavaScriptCore のあいだの壁は低い。同居しているから。
Monorepo にはコードのでかさという代償がつきまとう。ソフトウェアを小さく分割し、壁の向こうは触らないと決めれば小さなコードの身軽さを楽しめるのかもしれない。けれど可能性があるなら踏み込みたいと自分は思ってしまう。価値観とチームのやり方にズレがあるのは悲しいけれど、異文化体験ということにしておく。
車が自由に使えるの、ちょっと便利だね。たとえば東京に帰る日本人同僚の送別会がダウンタウンである、なんてとき身軽に行ける。通勤バスに乗りそびれた向井さんを家に送っていける。
自分の車を持っていたらまた違った生活ができたかなあ。しかしこの便利さはヒマとセットなので、ヒマがない今はあまり活用できそうにない。子供が生まれる前はどうだったか。少しは使ったかもしれない。
どちらかというと、もっと積極的に Uber や Lyft を使っておけばよかったという話か。週に一回乗るくらいなら車を買うよりも安上がりなのだから、「車を買うよりは安い」とおもってこれらのタクシーを使えばもっと積極的にイベントの類に顔を出せたことだろう。車がないのを言い訳に出不精してしまったのは、過去三年間の反省。
自分の、つまり家で二台目の車を持つのは、度々考えるけれど今のところ踏みとどまっている。周りを見ると子供が二人いる家では二台目に踏み切る人が多い。アメリカ人的には持っていて当然のようだけれど、その価値観はまだ受け入れていない。