むかし、スマホアプリのオフラインデータモデルは Cache based (サーバが source of truth でクライアントはそれを部分的に cache すると考える) がよいのか Sync based (データはそれぞれがもっていてオンラインの時に同期する) がよいのかとぼんやり考えていた時期があった。

が、いまおもうと空想上の問題だったね。このとき考えていた素朴な答えのひとつは「アプリによる」だったけれど、どちらかというと「どちらも使う」という方が正しいと思う。

オフライン対応のための sync というのは強力なアイデアだけれども、データモデルによっては正しく実装するのが割と難しい。ファイルシステムみたいにネストしたデータ構造 (tree) もけっこう難しいし、一部の TODO アプリみたいな ordered list には別の難しさがある。"最強の sync framework" みたいのを開発し、その上にアプリを作ろうとして失敗するのを遠目に見たことがある。最強のフレームワークが想定するデータモデルの複雑さは大抵のアプリにとって過剰すぎたのだろう。Chrome の profile data sync も、最初はすごい汎用的なフレームワークから始まったものの機能開発者が誰も使いこなせず簡単なモデルに回帰していった。というのは 5 年くらい前の話で、今はどうなってるのかわからんけれど。

その点 cache は比較的簡単。サーバが source of truth だとオフラインでデータを書き換える操作はできないけれど、それでいいものは沢山ある。たとえば shopping アプリなら top selling item list とかは cache でいい。Twitter の timeline みたいのも一見すると自分が参加できるから sync と考えたくなるけれど、投稿された timeline の cache + 投稿前 draft の sync (あるいはクライアントに閉じたコピー)  ともみなせる。Immutable objects + Pending operations として表現すればよい、とも言える。

Twitter みたいな social media は本質的にオンラインなので sync の出番がないのは自然。もうちょっとクライアント中心のアプリだと sync したいものが色々でてくる。けれど、その色々 sync したいものをひとつのデータモデルとして sync しようとするとふたたびデータモデルの複雑さあらわれる。個々の機能がそれぞれ勝手に自分のデータを sync する方が、データ種別毎の単純さをあてにできてよい気がする。ぱっと見ると同じようなコードがあちこちに現れて無駄っぽいし、サーバとの API も工夫しないと round trip が増えてしまうけれど。そこは小細工でがんばる。

なので immutable とみなせるものは cache で済ませ、それ以外はぼちぼち sync する, くらいが現実的には安全。

Sync はなんとなくかっこいい。Offline でも online でも同じように操作ができ、データが透過的にクラウドに保存される。理想的じゃん？でもユーザが offline/online の透過性を求めていないこともよくある。同期の有無やタイミングをコントロールしたいユーザは多い。そしてこの flexibility を許すと透過的な sync という夢は終わる。一方で product design として automagical な sync を実現したい、という意見はあるだろうし、それが望ましいアプリも多いだろう。だから Sync か Cache かは engineering だけでなく product の design でもある。そして答えはアプリ単位でなく機能単位で変わる。だからどちらも必要。

というのは今になってみると当たり前だけれど、何年か前の自分はわかってなかった気がする。そして数年後にはまた気が変わり「やはり最強の sync framework があればいい」とか言ってるかもしれない。

Stop Calling Women Nags という記事が一部で話題になっていた。家事における "Emotional Labor" の存在を appreciate しろよ男ども、という話。男どもに文句があるのはわかるが記事にあるような仕事...言われなくても片付けをするとか...は Emotional Labor にあたるのだろうか。

同じ話題を扱ったウェブ漫画があると HN のスレで知り、眺めてみる。これは同じ問題を "Mental Overhead" と呼んでいる。この方が適切な名前に思える。

自分が Emotional Labor ... というか「感情労働」について知ったのは、むかし「管理される心」を読んだときのことだった。原書の紹介をみると、この時点では Emotional work と呼ばれていた模様。まあ Labor の方がやらされている感があってよい。ここでいう emotional work/labor は、仕事のために感情をコントロールする、装う必要のある仕事を指している。客室乗務員とか看護の仕事とか。日本のサービス業全般そうじゃね、という話もあるがそれはさておくとして、部屋の片付けは別に emotional labor ではないよな。

なぜこんな言葉の overload が起こったのか。冒頭の記事からリンクされている資料を読んで謎がとけた。この資料は、2015 年に書かれた Emotional Labor に関するエッセイ をめぐる MetaFilter (暇つぶしサイト) 上の議論をまとめたものだった。このエッセイ自体は emotional labor を語義通りに扱っているのだが、なぜか MetaFilter の議論は仕事をしない男たちを糾弾するスレへと発展し、その内容を "Emotional Labor" の名前の下でまとめたりした人がいたものだから emotional labor = 男たちがやらない家事, という overload が生まれたのだな。まあ男たちがやらない家事の中に emotional labor が含まれるのは事実かもしれないが、この誤ったラベルづけは gender bias をめぐる feminist の態度を stereotypify して dichotomy を深めるだけではなかろうか... 一部の男たちが家事をしないのはそれが emotional labor だからではなく、単にしないだけだとおもうよ...

その点これを mental overhead だと指摘した Emma の漫画は正しい。この漫画では家事を project management に例えている。Project かどうかはともかく management としての側面を無視して家事を単純な routine labor だとみなすのが家事にたいする無理解の核の一つだと自分も 思う。

そしてインターネッツを眺める限り、残念ながら家事をしない男たちへに苦情を申し立てている女性たちの多くは特別よい management practitioner すなわち manager ではないように読める。世の中の管理職もたいがいゴミであることを考えるとこれは別に責められることではない。一方で、家事をしない男たちの問題をボトムアップで解決するには女性たちはマネージメントとかリーダーシップとかメンタリングとかを勉強するのが早道なのではないかとも思う。ようするに使えない部下や後輩(=夫など)をもってしまった上司や先輩はどうやってその部下なり後輩なりを育てていけばよいのか。まあ使えない部下の例は不適切かもしれないけれど、たとえば TL としてどうやってチームに仕事を分担していけばいいのか。

たとえば夫を micromanage したくないという女性たちは夫に役割の big picture を説明した上で delegate しているのか。あまりそういう様子はない。家事の分担が機能不全になっている人たちの問題は使えない部下たる夫だけでなく口うるさい上司たる妻にも改善できる点はあるのではないか。夫婦間での上司/部下という関係の fairness についてはさておくとして。たまにみかける夫を「褒めて伸ばす」みたいな言説はこの方向性のひとつと見なせなくもない。まあでも leadership とか coaching とかの本を何冊か読むともっと先に行けると思うのだよな。

That being said, 家事の一部に emotional labor が含まれているのは事実で、自分はそれをサボっているなあ。個人的にはそれが冒頭の記事の takeaway なのだった。人付き合い、近所づきあい、親戚づきあいみたいのを自分は完全にゆこっぷ(奥さん)に任せてしまっている。少しはやらないといけない・・・とおもいつつ腰が重い・・・。

ところでそういう emotional labor としての diplomacy は伝統的に女性が得意というのはほんとだろうか? また仕事の話にもどると, 外交や折衷は管理職の仕事の重要な部分を占めているはずだが、管理職はだいたい男である。これは 1. 男たちは別に diplomacy が苦手じゃない。 2. 女性が管理職になった方が世の中色々うまくいく, のどちらだろうね。白黒はっきりした話でもないだろうけれど。

まあ男たちがみな管理職になるわけではない点を踏まえると、したっぱの男たち(自分とか)は diplomacy が苦手かもしれず、家でも人付き合いの役に立たず、まったく使えない気がしてきた。つらい。新たにそんな悩みが生まれた昨今。

最近いまいち勉強する意欲がわかないのと、手元の「そのうち書くこと」リストが100行くらい溜まってしまったので、飽きるまでしばらくばさばさとブログでも書こうかという気がしてきた。現実逃避かもしれないが・・・。

世の中には binge watching というものがあるらしい。なら binge writing もあるのかなと検索してみる。あるね。そして binge writing の対にあるのは write every day らしい。物書きとしてどちらのアプローチが望ましいのかを人々は議論している。そういえば以前 Write Code Every Day なんて話があったけれど、これは物書きの write every day に触発されたものなのかもね。Binge writing はさしずめ hackathon というところだろうか。

なお Deep Work おじさんこと Cal Newport は “Write Every Day” is Bad Advice と書いている。物書きが本業の場合は別として、細切れの時間だけでは deep work できないから、ということだろう。

John Resig による Write Code Every Day を読みなおすと、所定の coding 時間の外側でも色々と考え事をする前提がある。そんな勢いで side project やってたら他のことは何も出来なそう。たとえば通勤中に podcast や Audible を聞くとかしないほうがいいよね。たぶん。その隙に考え事をしたほうが良い。そこまで入れ込める side project があればよかろうなとは思う。

ところで binge writing と言い張る予定だったこの blog まとめ書きシリーズ(予定)はどちらかというといえば write every day だと気づいた。Binge writing できるほどまとまった時間はない。

最近聞いた話。

勤務先のアプリは社内向け dogfood (beta) や、より狭い範囲の fishfood (alpha) を weekly でリリースしているチームが多い。これは continuous delivery の仲間と見ることもできるし、XP とかにあるイテレーションのデモの亜種と見ることもできる。

そんな weekly release を採用したチームのプログラマが、目先のリリースごとに新機能を入れないといけないせいで突貫工事をする羽目になって辛いと文句を言っていた。PM などから「次の weekly release にこれ入れてね」とか言われるらしい。興味深い現象。これはプログラマと PM のどちらが悪いのか。

プログラマからみると、 weekly のような time-boxed release の利点は締め切り優先で無理にコードを突っ込まなくていいことのはずなのに進捗を示したいがために無理を強いられるのは理不尽に感じる。リリースが頻繁だから少し送れてもダメージが少ない。それが CD の狙いではなかったか。

PM からすると、毎週少しずつ進んでいくインクリメンタルな開発を可能にするのが weekly release の利点であり、少し進んだらその成果を示すべきではないかと言いたい。かもしれない。

外野から見ると、潜在的な問題は 3 つ思いつく。ひとつ目は weekly な dogfood/fishfood の新機能という粒度は weekly の成果には大きすぎる場合もあるだろうなということ。テストプログラムのデモくらいの粒度で checkpoint させてほしい機能もあるよね。ふたつ目は、PM とプログラマの話し合いが不十分なせいでインクリメンタルにできない順番での実装を強いられている（PMが悪い）、あるいは単にそのプログラマがインクリメンタルに進めるのが苦手（プログラマが悪い）。

でも上の dichotomy は自分の想像で、このケースは PM もプログラマも agile とか興味ないのだろうなあ。Weekly release ってのはまあ agile の文脈から生まれてきた習慣なわけだけれど、インフラなどの進化で敷居が下がり普及した結果とくに agile 信者でないチームもなんとなく weekly release を採用できてしまい、背景を理解してないせいで苦労する。Travis CI のバッジがいつも赤い open source プロジェクトみたいな...

この一周回った感じ、当事者には悪いけどちょっと面白いね。教科書的な答えとしては weekly release を導入するなら開発プロセス全体もちゃんと見直しましょうね、というかんじか。えらそう。みんながんばれ。

定期的にあらわれる類の記事。ではあるけれどつい記録せずにはおれない。ともったらそもそも最近の記事じゃなかった (2015)。なんか似たような話を読んだ気がすると思ったよ・・・。

via Stressful lives of older tech workers - Business Insider / HN

Kent Beck の talk があるらしい！が、この日から旅行なのだった残念・・・・最近 Facebook でなにやってんのかなー.

via ThoughtWorks

MS のしゃっちょーさんが本を書いたらしい。次の Audible はこれ聴くかなあ。

勤務先のしゃっちょーさんにも一冊書いてほしいもんです。Chairman とかじゃなく、現役の社長に書いてほしいよね。まあ勤務先関係の本というのはえてして素直に読めないものだが・・・。

via Hit Refresh: The Quest to Rediscover Microsoft's Soul and Imagine a Better Future for Everyone: Satya Nadella, Greg Shaw, Jill Tracie Nichols, Bill Gates: 9780062652508: Amazon.com: Books

結局 Wok Pan への不安は払拭できず揚げ鍋を買った。

揚げ鍋買ったんだよねーという話を同僚にしたがイマイチ話が噛み合わない。なぜかとおもったら自分が pot for fries と言っていたからであった。 Fries = potato fries なのをつい忘れてしまう。Fried stuff と言ったら通じた。そして揚げ鍋は fryer pot か。そういえば揚げる道具は fryer だもんな。自分が買ったやつの商品名は tempura pot になっているが。

それにしても fries が自動的に芋の揚げ物ってどうなの。アメリカの揚げ文化はいまいち信用できん。おまえら鶏と芋しか揚げないんでしょみたいな。揚げ道具に関するオンラインの記事を読む限り日本料理の方が揚げ力は高い気がする。たとえば fryer pot には漏れなく basket が付いてくるが、それ菜箸でよくね？Basket が有効な局面は理解できるけれど、所要油量が増える、かさばるなど home use には overkill なきがする。まあやつらは箸が使えないから仕方ないか。

via New – Per-Second Billing for EC2 Instances and EBS Volumes | AWS Blog

おや。GCP を使う一番の動機がなくなってしまったなあ。

むかし FB や G+ などに書捨てたテキストを掘り出した。social media に書いたテキストは発掘が大変なので、バックアップとして。salvation というタグがついており、タイトルの頭に日付がついているやつら。ほんとは post の日付をオリジナルの日付に揃えたかったのだけれど、面倒なため挫折。なお時事ネタであって現在の見解を反映するものではありません。

Rui-san が Gauche のコードがを上から下まで読んだのは勉強になったという話をしており、遅ればせながら自分も本腰を入れて読むコードが欲しくなった。そこで読んでみたいプロジェクトを書き出してみたものの収まりが悪い。なぜそれを読みたいのか、まずは自分の中にある基準を書き出してみることにする。重要度順。

Code Quality: まず良いデザイン、良いコードであること。要するに一般的な意味でのコード品質が高いこと。汚いコードを読むのは辛い。大半の C++ コードはダメ。MySQL, MongoDB あたりは脱落。Mesos, WebKit とかもうーむ...

Problem Maturity: よく考え抜かれ、よく研究された問題を解いていること。教科書的な問題には多くの人が時間をかけた研究の成果が詰まっている。難しい問題を、洗練された方法をたくさん使って解いている。大げさに言えば人類の英知がある。OS や言語処理系、信号処理、データ圧縮、人工知能などなど。

Suppleness: コードがデザインを、デザインが問題への理解や意見を直接に反映していること。問題への理解がコードに反映されておらず、オラーっと勢いで書いてしまってるコードというのは結構ある。理想的にはコードを読めば問題と答えを理解できると良い。Code quality みたいなものかもしれないけど、アーキテクチャのまともさに近い。抽象度高め。古い問題の焼き直し系はそれなりにあてはまる。たとえば LLVM とかディティールはひどいけど大まかなデザインは教科書的。

Relevance: 知りたいと思っている分野の問題であること。ジャンルとして興味のあるものを読みたい。たとえば自分は人工知能とかあんまし興味ない。何が好きかは人によってまちまちだから意味ない指標かもしれないけれど、他人の勧めと自分の興味のバランスは要るよね。

Foreign-ness: よく知らない問題であること。どうせなら新鮮な発見がほしい。自分だと今更別のブラウザを読む気にはならない。VM も何度か読んだことあるので気が乗らない。

Self contained-ness: 自己完結する度合いが高いこと。いろいろなライブラリを繋ぎ合わせて作ったものは、本題が依存先ライブラリの中にあったりして拍子抜けする。あちこち読むのも大変でまとまりがないから、できれば読み物として閉じていてほしい。Gauche や Go は多分この点でよくできてる。そうでなくても古いものは自己完結する率が高い気がする。

Size: 大きすぎないこと。でかいと読むのが大変。そしてでかいコードはその大半が、動作には必要だけれど読むに値しないものだったりする。コードの中で問題にとって本質的な部分の割合が高いほど望ましい。Linux のコードなんて大半はドライバなわけだし、「ドライバ」みたいに綺麗にわかれてないだけで世の中の巨大なコードは大半がそういう枝葉末節からできている。ブラウザだと HTML の個々の要素の実装とか読む題材としてはどうでもいいけど量は多い。そういうコードがダメという話ではない。読むものはノイズが少ないほどいいというだけで。

Age: 古すぎないこと。今更 C 言語とかよみたくない。あとおっさんが読んだものをあとから読むのは癪だし上から目線でなんか言われたりして不愉快。Emacs とか絶対読みたくない。K&R ですらない。

Theoretical Complexity: 背景にある理論が難しすぎないこと。すごい難しい数学が背後にあり、その数式をコードにおとしたような問題は結構ある。背後の理論がわかってないと何もわからない。それを勉強するのも含めてコードリーティングという面はあるけれど、自分には機械学習とかわかる気がしない。数学が苦手という個人的な事情ゆえか・・・。

Familiarity: 自分が使っているものであること。触ったことがあり、動作を知ってるものの方が理解しやすい。自分の場合この理由でサーバサイドが辛い。もっとウェブアプリとか書いてるならいいんだろうけど。

Standalone-ness: ライブラリやフレームワークよりはシステムやアプリケーションであること。強い主張というよりは個人的な好み。依存するものが多いのがいまいちなのの裏返しで、 依存されてはじめて意味があるというのも読み物として自己完結度が低い気がする。

これらを完全に満たすものはないだろうけれど、ただぼんやり列挙して gut feeling に従うよりは納得のいく形で読む題材を選べる気もする。具体的なプロジェクトについてはこれから考える。

カルマはためすぎないほうが良いと思う。

仕事での貸し、面倒でイヤな仕事を片付けた実績。わかりやすい業績じゃなくて、プロジェクトや製品を支える雑用の見返りがカルマ。ビルド壊れ治し、バグのトリアージ、レビューの球拾い、ツールの改善、トロル対応。そういう仕事をすると貯まる目に見えないポイント。組織のインセンティブデザインなんて完璧でない。道徳心や責任感のある人がその不完全を埋める。そしてカルマを貯める。

カルマは貯めるだけでなく使うこともできる。日頃の行いがよければ、たまに無理したり変なことをしても大目に見てもらえる。そういう形でためたカルマを消化できる。自分は一時期クラッシュバグを直しまくってカルマをためていたため HTML Imports の出荷でやや無理にブランチに変更をねじこんでも見逃してもらえた（気がする）。

そんなカルマだけれど、あまりためすぎない方がいい。

まずカルマは曖昧なものなので、どのくらいたまっているかわからない。貯めこんでガバっと使おうとすると手持ちのカルマ分を超えて使い込んでしまうことがある。やりすぎてしまう。様子をみながらちょいちょい使うほうが無難。

カルマは風化しやすい。利息がついたりせず、むしろ成果が地味なだけに忘れられがち。カルマ獲得直後なら「あの面倒な仕事をしてくれた人」と思ってもらえたのが、時間がたつと、そして人の入れ替わりが進むと「なにしてるのかわからない人」へと格下げされてしまう。カルマは新鮮さが命。

カルマは積もった鬱積の影かもしれない。溜め込むのは体に良くない。そしてたまらず一度に吐き出したカルマを組織が受け取れるとは限らない。組織のカルマ受け入れバッファには上限がある。他にカルマ消費中の人がいるとき、二人目には待ってほしいかもしれない。カルマは産休やサバティカルのように制度化されたものじゃないから使い手の立場は弱め。

こうした理由から、カルマは溜め込まず隙を見つけてチマチマ使っておくといい。けれど責任感がある人はえてしてカルマを溜め込みがちに見える。貧乏クジばかり引かされた末に嫌気が差し燃え尽き、よくわからないプロジェクトをはじめたまま帰ってこなかったり、辞めてしまったりする。早めにカルマを取り崩して息抜きすればよかったのにと悲しくなる。

カルマを使えると思い至らない人がいる。一方でカルマ使いがうまい人もいる。基本的に面倒見がいいんだけど、たまに姿を消して変なツールやら謎のプロジェクトやらで遊んでいる。そして気が付くと本業に戻っている。頼りにされているとわかっており、カルマ消化中もカルマ獲得活動を完全には絶やさない。

カルマのため方がうまい人もいる。雑用に名前をつけ、成果を数値化したりイニシアティブを立てたりして目立たせる。本業に格上げし、成果にカウントされるよう工夫する。アピールには意味がある。人々は地味な仕事には気づきにくいし、気づいてもすぐ忘れてしまうから。管理職がそれをうまく計らってくれればいいけれど、できるなら自分でやっちゃった方が確実。そもそもカルマは組織の弱みから染み出すもの。うまく捉えられれば苦労しない。

雑用のプロジェクト化、昔はなんとなくセコいとおもっていた気もする。でも名乗りを上げ説得力のある動機を示して人々を巻き込むなんてむしろ献身的じゃんね。

Google はチームやプロダクトを助ける働きをした人を表彰する仕組みがあり、たまにノミネートして表彰している。これはカルマを買い取る制度とみなすことができるかもしれない（賞金があるのかは知らないけれど。）20% 制度もカルマ消化の口実に使える。そうやって組織の助けを借りられれるなら、それはそれでいい。

誰もがカルマを溜め込むわけではない。カルマをまったく稼がない選択もありうる。でもそれを勧めるのはどこか悲しい。稼いだら貯めずに使う、くらいのバランスが健康的だと思う。ある種のアサーティブネスかもしんない。

数年前に二泊三日のリーダーシップ研修みたいのを受けた。上司の指令により送り込まれた。そのトレーニングは一部の社内ボランティアが始めたもので、評判がよかったのと運営してる人の熱意などにより全社的なエンジニア向けプログラムに格上げされていた。教えるのは普段はエンジニアしてる人たち。各種アクティビティを通じリーダーシップを学びましょう、みたいな内容。講義:グループワーク が 2:8 くらい。

US, ヨーロッパ, アジアで開催があり、僕は東京で開かれたアジア枠に参加した。参加者は中国、韓国、インド、オーストラリアから。転勤で海外勤めしているアメリカ人やヨーロピアンも結構まじってる。

主たるメッセージは、自分の主張ばっかりしてないで一歩下がって話を聞き議論をまとめ合意を引き出す工夫をしましょうね、というもの。最初のグループワークは参加者数十人が全員でやる大人数作業。参加者が意思統一し足並みを揃えて動かないと達成できないようデザインされている。

この最初の作業が、おもしろいくらい上手くいかなくて衝撃だった。どいつもこいつも見事に自分の意見を貫こうを声を荒げ、話を仲裁しようとする人も複数あらわれてやはり声を荒げ、ワーワーいってるうちに時間切れ。すげえ。ちなみに研修の最後にも同じ作業をやる。今度は学んだことを生かしてうまくやる、というわけだ。

研修はそのあと 5-6 人のチームにわかれ、チーム単位で色々なグループワークをやる。合意を見出す以外にも役割分担をするだとか、他のチームとうまくコミュニケーションするだとか、正確にメッセージを伝えるだとか、チームワークが機能しないと失敗するアクティビティをこなしてはああチームワーク大事だねと納得する。そんな構成。けっこうよくデザインされてる。

でも同時に、これ日本人だけの集団でやったら最初の作業から上手くできちゃうなあ。とも思った。多数派が自己主張しないじゃん。少数の声の大きい人が適当に仕切って進んで終わりな気がする。そういう引っ込み思案は韓国も似た感じらしい。中国人とインド人は個人差があった。研修の主催者もそれを鑑み、アジア開催の時は文化的差異や言語バリアをそれなりに考慮して教えているのだそうな。（そういう様子はあった。）

僕はチーム作業でシドニーから来たシニアなエンジニアと一緒になり、この人が見事に人の話を聞かず自分のアイデアで突き進む人だった。同じチームには他に中国人と韓国人とインド人。インド人は若干食い下がっていたけど概ね説き伏せられていた。自分はもう面倒なのでハイハイと話をあわせるのみ。なにしろそのシドニー人、ぜんぜん話を引き出す気ナシ。当人は研修の最後に妙に感銘を受け良いトレーニングだったナアとかいってた。ほんまかいな。

リアルな仕事の US 側 TL がこのシドニー人みたいだったら、きっと一方的にこき使われていた。そう思って背筋が寒くなった。自分は運が良かった。この恐怖から、研修のあと1年くらい真面目に英語を勉強したのだった。実は転勤したくて勉強したんじゃないんだぜ・・・。

僕は pre-Google の経験から、リーダーシップというのはなんだかんだで決断したり引っ張って前に進めたりするものだと思っていた。謙虚なリーダーシップについての議論は知っていたけど信じていなかった。でもこうして船頭多く破綻する研修のアクティビティを見たとき、ああ、なるほどこれが一歩下がったリーダーシップの必要性かとすごく腑に落ちたのだった。

実際 Web Components プロジェクトの初期も意見のある JavaScript マニアやオレオレアーキテクト達が自分の考えた最強のデザインみたいのを主張するばかりで話の進まない期間が長かった。非公式なプロジェクトだったため正式な TL もいなかった。まあ形式的な TL の機能する会社じゃないのでいても大差なかったろうが。

結局プロジェクトファウンダの一人であり責任感の強いシニアなエンジニアが適当に話をまとめ、仕様を書き、W3C での議論みたいな面倒を引き取り、しかしデザインの意向はマニアから汲み取り、少しずつ前に進んだのだった。あのマニアどもの一人でも面倒を汲み取る責任感があればそういう役割の分断がなくてもっと色々スムーズに進んだろうに・・・。

そのシニアなエンジニアは特段優れたウェブ標準書きではなかった。でも謙虚なリーダーシップを持っていた。ぎこちないリーダーシップだった。もっとうまくやってほしい、自分はずっとそう思っていたけれど、一方でそれがうまく機能する様も想像できなかった。そのリーダーは、英語力不足で脱落しがちな自分からも意見を汲み取ろうと常に気遣ってくれた。プロジェクトの意思決定が messy すぎてもうやめたいという場面は二回くらいあったけど、彼のおかげで踏みとどまれた。

僕はもともとそのリードがさっさと決断しないのをもどかしく思っていた。でも強い主張をもって荒れ狂う人々をそれとなく収めるのがこの会社のリーダーシップだと理解して以来見直した。そして例の Weinberg の本 が似たようなことを言ってたとぼんやり思い出したのだった。これを読んだのは ACCESS にいた頃。今読んだらまた違う理解がありそう。自分にとってリーダーシップは遠い世界の話になってしまったからさほど関心はないけれど、ぱらぱら眺めてみたい気もする。

一方、トップダウンのバシっとしたリーダーシップがない自分の勤務先は組織としてどんどんグダグダ化が進んでいるようにも見える。実務レベルの謙虚なリーダーシップについては納得しつつ、そのスケーラビリティはまだ信じられていない。

YC のボス Sam Altman 主催 “Startup School” のビデオが面白いと教わる。ビデオのほかに参考読み物のリストもある。Sam Altoman はよく HN にブログ記事がランクインしており、それを読むことはあった。 YC の偉いひとだったのか。

自分はスタートアップで働ける気はしないけれど、スタートアップの方法論はソフトウェア開発者の要履修項目になりつつあるのかもしれないと思う。昔のアジャイルみたいな位置付け。アジャイルからリーン一族が派生して、それが Paul Graham らの教義と合流したものがスタートアップ理論・・・くらいの根拠のないイメージ。出自はさておきスタートアップがらみの書籍は増えたし、それはソフトウェア開発方法論のコミュニティとそこそこ重なっているように見える。バブルを差し引いてもなにかは生まれてるんでないのかな。

ここになにかがあって、自分はそれをわかってないと感じた出来事: higepon は去年の多くを growth の仕事に費やしたという。その growth というのは startup school の一項目になっている。で、僕はそれが何なのかまったくわからない。想像もつかない。ほんとに。全然。Hive か何かで SQL たたいてグラフ睨んでるのかなーとイメージしているけれど、それが何のグラフなのかどうやって集めたデータなのか、微塵も思い浮かべられない。

そういうものは多分ほかにもあるのだろう。そしてスタートアップ以外の組織もその方法論を取り込んでいくのだろう。そもそも Twitter からして上場企業だし。とすると、スタートアップ理論というのは、新しい世代のソフトウェア開発手法に付けられたラベルなんじゃないか。だとしたら知らないとまずくない？そんな恐怖。

スタートアップの存在感も不安を後押ししている。勤務先、辞めた人の行く先は半分くらいがスタートアップに見える。まあ競合他社に行く人はわざわざ farewell メールにそんなこと書かないだろうけど。この感じは日本ではなかった。

大企業の会社員がスタートアップ理論をかじる必要はあるのか？それはウォーターフォールの開発者がアジャイルをかじる必要があるのか、という問いに似たところがある・・・もしスタートアップ理論が次世代のソフトウェア開発方法論なら。

アジャイルも半分は意味があり残り半分はゴミだった。割合はさておき、スタートアップ理論も同じだろう。当てずっぽうなメタファでいうとアジャイルのオンサイト顧客がスタートアップ理論におけるハカソン、グロースがリファクタリングなんだよ、とかそういうかんじ。対応はてきとうです。

僕は最近のオフィス引越しで Chrome じゃないチームが多いビルに移ったんだけれど、細々したチームがいくつもあるらしく会議室とかオフィスがめいめいに装飾されたりちらかったりしている。スクラムのカンバンみたいのもあるんだけど、見慣れない流儀のダッシュボードも多い。社内でも、聞きなれない、でも社内生まれでもなさそうな製品開発方面の用語を目にするようになった。なんとなくスタートアップ方面由来なんじゃないかという予感がある。エンジニアはさておき PM にはその手の話が好きな人が多いから、彼らが流行りを持ち込んでる気がする。

開発方法論に興味を失ってしばらく経つ、でも以前は興味があったことだし、その知識が役にたつこともあった。少なくとも自分に視座を与えてはくれた。スタートアップ理論も勉強したら案外面白いかもなあ、とおもったわけです。どうですかね。大企業勤めにゃかんけーねーですかね。

アジャイルに増して玉石混合度が高く、Amazon を見ても単なる WIRED 的読み物と教科書っぽいのが混ざって並んでいる。かじるにしても筋道を付けるのはちょっと面倒そう。とりあえずは飽きるまで startup school の参考記事を読むところからスタートかしら。

Chrome はマルチスレッドなのだけれど、色々辛い。マルチスレッドがらみのバグはよくコードレビューで指摘されるし（気づくのは大したもんだおともうが）、TSAN (Thread Sanitizer: レースコンディション動的検出ツール) ボットが見つけてくれることもある。でも正直 reason-able なコードが書ける気がしない。皆なんで平気なのか謎。まあ平気じゃないから TSAN みたいなものが必要になるわけだけれど。

スレッド同士で間接的直接的に同じ変数を触ってレースが発生する。根本的にはそういうデザインを強いられるアーキテクチャがまずい。なぜオブジェクトをスレッドに縛り付けてメッセージパッシンする作りにしなかったのか。プロセス同士はそうなってるんだから同じことをすれば良いはずなのに・・・。

何がこのまずいデザインを招いたのか。なぜ人々は頑張れなかったのか。社会的な要素が大きいとわかりつつ、どんなデザインになっていれば平和だったかを想像してみる。

• ある概念(たとえば HTML の Frame、ウィンドウ、クッキーのストア)などが、それぞれのスレッドで独立したアイデンティティを持つ、スレッド単位のミラーリングを行う、ためのパターンを決めておけばよかった : たとえば FrameIO, FrameUI みたいなかんじで担当スレッドと概念の対応付けがわかる名前にするとかね。そして対応づけられたスレッドでインスタンスを作り、別スレッドの相棒とチャンネルを接続して作業完了、となるまでが簡単に書ければよかった。スレッドに紐付けるオブジェクトのコードは部分的に見られるけれど、それを支援するインフラがない。結果として主にオブジェクトの寿命管理でバグがおこる。たとえばデストラクタが望ましくないスレッドで呼ばれたりする。これを避ける仕組みはあるっちゃあるんだけど使い難いし忘れがち。
• スレッド間でクライアント・サーバ的なメッセージングをやる基盤が欲しかった。IPC/RPC みたいの。Chrome の IPC はすごく原始的なので、どうしても使わざるを得ない場面(つまりプロセス間通信)でしか使う気が起きない。もうちょっと汎用的なメッセージング機構として整理されていてほしかった。Go の Channel みたいなのは昔からあったし使われてたよ・・・。
• そうしたメッセージングの仕組みが存在し、かつスレッドに対する PostTask() より簡単であるべきだった。別スレッドでコードを実行する PostTask() はすごく便利で、another_thread_->PostTask(Bind(&MyObject::DoSomething, this)) みたいな, 同じオブジェクトを別スレッドで動かすコードが大量に書かれる。そしてある日バグる。同じ手軽さでスレッド間通信を書ければ「ある日バグる」がおきずに済んだ。

などなど・・・。将来マルチスレッドなコードを書く日が来たら教訓にしたい。

・・・といいたいとこだけど自分じゃこんなコードにならないね・・・。自分はスレッドは人類には早すぎた道具なので近づかずにすむよう(デザインで)全力を尽くす派。日常的にロックをつかって排他制御する Chrome のコードには共感できない。もしかしたらボンクラばかりのチームの方が少数のエリートが決まりを作って守らせたかもしれない。でもそれなりにコード書ける人がその自負でもって各々勝手にコードを書いていくと、さっさと仕事を片付ける最短パス = PostTask() と lock, に収束してしまうのだろうなあ。Chrome は大掛かりなアーキテクチャ的制約みたいのが少ない。それは良いところもあるけど、辛い事もあるね。

それにしてもウェブの世界は非同期かつメッセージングなコードを強制されているのに、その実装がこんな shared state だとは皮肉なものであることよ。たぶん Servo とかはもっとずっとマシなのだろう。ちゃんと UI がついたころに見てみたい。

Ben Evans が「イノベーションはしょぼくて安いものが使い物になる、という風に下から上に上がってくるものだとされているけれど、モバイルでは上から下、高いものが安くなることでモバイルで使えるようになる形で起こる」と主張している。

これは僕個人の印象とは違っていた。ソフトウェアについて言えば昔のモバイルは上から下の流れがあった、つまり遅いコードがモバイルでも使えるように CPU が速くなっていった。たとえば WebKit が動くようになった。でももうモバイルはモバイルの道を勝手に進んでいて、あまり上から降りていける感じがしない。センサーとか GPU とかタッチパネルとか PC についてないし、カメラもスマホのほうがよっぽど高品質。上から降りていけるものがあるなら便乗したいけれど、なんかあるかねえ・・・。

グラフィクスの技法なんかは未だに上から下の流れがあるのかもね。PC で書いてたシェーダを GLES にもってって使う、みたいに。グラフィクスに限らず難しいアルゴリズムをデバイスに持っていくのはありかもしれない。そういえば AOSP のツリーにはちょっとだけ機械学習のアルゴリズムが入っていた気がする。何に使ってるのかは不明。

個人的には Docker みたいなコンテナ技術が降りてきてセキュリティや互換性の問題をなんとかすることを期待しているけれど、いまのところそういう様子はない。iOS のサンドボクシングなんて、実は事実上のコンテナなのではないかという気もするけれど。

WebKit contributors meeting の Wiki を見ていたら "CSS Houdini" という単語が出てきて、なんだそりゃと思ってちょっと調べてみる。

と CSS とレイアウトやレンダリングに imperative な API をつけようというウェブ標準話らしい。こんなのやってんだな。WebKit で話がでるくらいだから Google だけでなく MS, Mozilla, Apple も巻き込めており、出だしは順調げ。まあ問題が超絶手強いので先は長そうだけど、がんばってほしいもんです。

• http://dev.w3.org/houdini/
• https://wiki.css-houdini.org/
• http://trac.webkit.org/wiki/March%202015%20Meeting
• http://dev.w3.org/houdini/box-tree-api/

こうやって話が進むのを見ると、Extensible Web Manifest は結構良い宣言だったのではと思う。Alex Russel の一味はいい仕事をした。Web Components の仕事は色々辛かったけれど、こういう発展の萌芽となったと思えばまあ、報われないでもない。

Alex Russel が Web Components (当時はコードネームで呼ばれており、この名前がついたのはちょっとあと)とか言い出したのは 2011 年。ある朝ミーティングに呼び出されて VC 越しで話を聞き、入社して日が浅かった自分は「次はこれをやれってことなんだな」と理解して何となく Shadow DOM まわりの実装を手伝い始めた。今思えばあれは単なる売り込みであって、別に手伝わなくても良かったのだが。(基本的にそういうトップダウンの任命はない。実際、同席した同僚はスルーしていた。）

Web Components は当初それほど extensibility を強調してはおらず、むしろ「俺はこうやって JS ライブラリを書きたいのにかけないのはおかしい」というやや中二っぽいフラストレーションに導かれていた（ように見えた）。クールに書きたいその気持ちを突き詰めた結果、APIのレイヤリングが狂ってるのがおかしいからそれをなんとかすべきという主張に辿り着き、Extensible Web のアイデアが生まれたのだろう。そして、高レベルな APIから作ると失敗した場合にダメージがでかい（ウェブ標準は引き返せない）ことだし低レベルなAPIから揃えていきましょうという合意が生まれ、Service Workers が生まれ、Web Animations のドラフトからは当初含まれていた SMIL みたいなマークアップ定義が消えた。CSS Houdini も「実装を晒しすぎない程度に低レベルな API を定義しよう」というメガネでみると自然に見えると思う。

こうした学びの代償として Web Components には「クールに書きたい」の残滓があり、それらはチームを苦しめた/苦しめている。Shadow DOM の特別なセレクタ、宣言的な “Distribution” のコンセプト、あとは HTML Imports まるごと。こいつらは強力な機能なのだが、特にブラウザの低レベルな API を公開してはいない。だから仕様の議論も終わらない(好みが入り込みやすいから)し、実装も複雑になったりする。最初から Extensible Web のアイデアがはっきりしていたのなら、また違ったものができたに違いない。とはいえ the sail has shipped なのだった。

Extensible Web の視点に経つと Polymer の役割にも功罪ある。API の実用性をドッグフードして弱点を暴き出すのを手伝った一方、API の使い勝手に重心を動かしもした。先送るはずだった「クールさ」を再びプロジェクトに持ち込んだ。結果としてチームは API からクールさを殺すことが出来なかった。

もっともこれは Polymer が悪いというより、ユーザの要求をプラットホームの視点で解釈しなおすことができなかった開発者（自分とか）の責任という方が筋が通っている。そこはごめんなさいというしかない。ごめんなさいね。ほんとに。僕は疲れ果てて撤退しちゃったけど、まだやってる人たちは後始末のために色々考えてると思います。

2014 年 2 月に引っ越してきたので1年以上たった。1年経ったまとめとかは特にしてないのだが、なんとなく今の暮らしや仕事の良いところを書いてみる。愚痴ばっかり書いてんじゃねーという指摘を受けたのと、自分を励ますため。個人の体感であってベイエリア生活や Google 社員を一般化するものでありません。めんどっちいので blog には書かず、知り合いにシェアして気を済ませておく。以下順不同。

生活編:

天気/気候。気候の良さの帰結を想像するのはけっこう難しいかもしれない。それはたとえば、お昼ご飯を外で食べられるということ。Google オフィスの社食、半分以上には屋外のパラソル席がある。そこでご飯をたべる。気分いい。考え事ついでの散歩とかも天気がいいと気分いい。それは例えば、自分の傘を持っていないということ。ここ数年は干ばつのため例年以上に降ってないらしい。でもそろそろ欲しいな、傘。

自然。開発しすぎだの水不足だの言うけれど、なんだかんだで東京都心よりもずっと植物がある。散歩とか自転車通勤とかが気分いい。アパートの庭にリスだの小鳥だのが来たりもする。ちょっと面白い。あと Yukop(おくさん)主導で毎月ハイキングしてる。ハイキングできるエリアまでは車で３０分くらい。自分では運転してません。すみません。

家が広い。アホみたいな家賃を払ってる帰結なのだけれども、まあ広い。東京では夫婦で六畳1Kに住んでたから雲泥の差。広いとなくなるストレスというのはある。たとえば台所が広いので自炊がはかどる、一人がテレビを見てても他方に干渉しない、猫が走り回れる、など。あと敷地内にジムが付いてたりする。ジムとプールは家賃高いアパートにはだいたいついてる。

建物やお店が少ない。建物、特に高いビルがすくないぶん圧迫感がない。少し気が楽。お店がすくないと、なんとなくの買い食いなどがなくなり、細々した出費が減る。外食は月に数度。でかけるより家で作って食べたほうが楽だから。お店がすくないのは欠点でもあるが、その話はスコープ外。

変わった食材を手に入れやすい。移民居住区のため、中国人向けスーパー、韓国人向けスーパー、インド人向けスーパー、メキシコ系スーパー、よくわからん地中海系っぽいスーパーなどが(自動車で)まあまあ近所。インド料理は適当に作ったら辛すぎたので自粛中。中華調味料系はなんでもあって重宝する。韓国スーパーは日本に近いものが日本スーパーより安く売っているのと、冷凍食品が妙に充実している。あと豚肉ね。カットのバリエーションが豊富でさすが焼肉の国。

あまり人混みがない。なくなってわかる、実は人混みはけっこうストレスだったという事実。モールなどではそこそこ人混みしているけれど、新宿渋谷と比べたら荒野みたいなもん。自動車渋滞はあるけれど、僕は自転車通勤なので影響少なめなのだった。

テック会社がいろいろある。Google はおいておくとして、30 分のチャリ通経路に LinkedIn と Microsoft と Mozilla と Coursera とあとなんかもう一個くらいある。駅前に Apple と Nokia がある。Yahoo や Apple の通勤バスが走ってるのを見かける。ハイウェイを走ってると Intel, Adobe, Oracle, Salesforce, Evernote, etc. が見える。週末などで Palo Alto までいくともっと今時なやつらがいろいろある。アメリカテック企業憧れ世代なので、こういうのを見るとわけもなく気分が盛り上がる。そういうところで勉強会があったり、遊びに来いよと誘われたりもする。勉強会の類はもうちょっと行きたいなあ。

同業者が近所。Apple ... は最近は縁がないけれども、たとえば Web Components 売り込みにちょっと Mozilla 行ってくるわ、みたいのが普通にある。Microsoft 本社もいちおう国内。PM とかはたまにミーティングしに行ってる。ブラウザ固有といえば固有。W3C の会合も近所が多い。もう行かないですが。同業者だけでなく Web API を使ってくれている会社に行ったりもしてるらしい。僕は行ったことなし。

US オンリーネットサービスが使える。Spotify, Netflix, Google Express など。Kickstarter も送料が安い。

日本のネットコンテンツを見なくてもピアプレッシャーがない。はてなブックマークだのまとめサイトだのをぜんぜん見なくなった。ネット中毒者である自分には有意義。英語圏コンテンツはまあ、見てます。いいんだよそれは。

飽きない。なんだかんだで新天地だから色々物珍しいし、挑戦してるという緊張感は生活の張りになってる。人生退屈だわーという感じはない。

仕事編:

オフィス。広い。まあ広いのも良し悪しだけれども、今回は良い話だけ。自席が広いのは割とどうでもいい(というか席は特段広くない)けど、たとえば駐輪場が広いと停めるのがラク。六本木は大変だった・・・。あと天気と自然が相まって敷地内の散歩がはかどる。

オフィス、ゆとりがあるだけでなく、単純に規模がでかい。なので自分のことを知ってる人が誰もいない場所、というのが別の建物に行けば簡単にみつかる。そういうところで昼飯をたべたり仕事および趣味コードを書いたりすると職場なのに一人の時間を味わえる。けっこうよい。

偉い人が近くにいる。新しいプロジェクトの情報とかが入って来やすい。世の中で広く使われている製品(Chrome)に関する意思決定がどのような空気によって起こるのか、などがわかる。わかったからどうということもないけれど、でかくて広く使われているソフトウェアをどんな人がどんな風に作っているのかは年来の謎だったので答えに近づける excitement はある。個人的にはこれが一番大きい。

仕事の選択肢がいっぱいある。本社だし。東京でやってるプロジェクトがつまらないものだとは思わないけれど、選択肢の量はたぶん二桁くらい多い。人数が全然ちがうからね。Chrome の中でも Google 全体でもそう。

レビューの返事が速い。時差がないため。まあ実際は相手次第だけれども、速い時はすごい速い。

いわゆる待遇がよい。タダ飯、給料など。このへんは東京 Google も良かったけれど、違いは近隣の競合も待遇を競い合っているので全体的にソフトウェアエンジニアの待遇は良い。転職しようとして実際にそれら良い会社に入れるのかはまったく自明でないが、それについて考えるのはまた今度にしておく。少なくとも選択肢はある。

W/L バランス。異常によい。これはベイエリアで一般化はできないし Google でもいろいろあるとおもうが、今のプロジェクトはおっさんが多いなどの理由によりみな大変帰りが早い。帰るのが早いだけでなく来るのが早い人も多いね。僕は遅めだけど、周りが早く来て早く帰るので残業圧がまったくない。早く帰るのは家庭の平和に大きく寄与するので重要。ちなみに早く帰った分の時間は概ね炊事に消えている。趣味は炊事。

書き出してみると、仕事より生活の positivity が多いことに気づく。Google は完璧ではないにせよグローバル企業たろうと頑張っているから、東京と US の差は意外と大きくない。違いは主に規模から来ている。そういう意味では Google で働くことの良いところ、という話も書き出してみると面白いかもしれない。そのうちね。

生活の違いは大きい。でも家賃含め金がかかると車必須なところ以外はけっこう気に入ってるね。払いのいい仕事さえあれば楽しく暮らせる気がする。その前提が成り立ち続けるようがんばりたいもんです。

以上、1年分のポジティブな話でした。

クラッシュするだの遅いだのとコミットしてはしばらくのちにリバートされる、を繰り返してきた担当機能のフラグフリップ、もう一ヶ月くらい経つしいいかげん定着したかと思った矢先、またリバートされた。先週の金曜。Chromebook でクラッシュするという。しらねーよ・・・と思いつつ BTS を眺めたら人々が頑張って原因解明に努めるスレが目に入り一転ごめんなさいという気分に。同類のレポートが次々とマージされてくる。ChromeOS の新しいリリースが多くの人に届き始めたのだろう。再現条件はさまざまで、いまいちよくわからない。つらい一週間の始まり。

クラッシュするといってもクラッシュダンプはない。IPC がエラーを返し、それをクラッシュと判断したブラウザが sadface を出すというもの。なぜ IPC がエラーを返すのかを調べないといけない。というのはその IPC のインフラを書き換えたのが自分だから・・・。

「ChromeOS 設定でビルドした Chrome でも再現しますかね？」と尋ねるも、それではダメという。しかし手元に実機がない。家に Pixel が一台あるだけ。仕方ないのでこの日は準備のみ。 ChromeOS のビルド方法を向井さんに教わり、USB メモリを借りるなどして準備を進める。

月曜。 自宅に置いてあった Chromebook Pixel を会社に運び、ビルドしたバイナリを動かしてみる。ChromeOS 、さすがに丸ごと自分でビルドする必要はない。ベースとなる Linux のイメージをダウンロードして USB 経由でマシンに入れ、そこにビルドした Chrome 追加する。Chrome といっても UI が全部はいったもの。色々細かい勝手がわからず向井さんに泣きつきつつトラブルシュートを進めるうち、自分のバイナリが動いたのを確認したころには日が暮れていた。正確には日は暮れてないけど疲れたので帰宅。

火曜。 ビルドはできたのでバグの再現を試みる。全然再現しない。そもそも再現条件がよくわからん。はー。Pixel で試してるんだけど再現しますよね？と BTS のスレッドで質問すると、俺の手元では Peppy という安めの端末で再現してるよという。うーどっちも Intel だから似たようなもんだろうし Pixel で再現するという報告も見た気がするんだけどなあ・・・とぐずぐずしていたら、手元で再現できているというエンジニアが丁寧にもマシンのゲット方法を教えてくれた。

ありがたく指示に従い指定された Lab に出向いてマシン(Peppy)を確保。ついでにそのバグを bisect してフラグフリップが原因と突き止めたエンジニア、 S さんにご挨拶にうかがう。すみませんね僕のバグが手間かけてしまって・・・などと挨拶。大変良い人だった。そして向井さんの斜め向かいあたりに座っていた・・・。

そのあと自席に戻るも電源ケーブルを間違えたのに気づき Lab との間をもう一往復し、気がつくと Google Fit の運動時間ゴールが達成されていた。結局 Peppy 向けのビルドを作ってその日はおしまい。仕事の進みが遅いのは手際の悪さに加えてやる気が底辺だからです。

水曜。 Peppy で再現を試みるも、やはり再現しない。はー・・・S さんが BTS に書いてくれた通りにやってるんだがなー。もしかして手元の Chrome が微妙にオフィシャルビルドと違うせいでダメなのだろうか。それとも僕のアカウントでは再現しなくて S さんのアカウントだと再現するのだろうか・・・。仕方なく Peppy 片手に再び S さんを訪問。

たびたびすみません再現しないんです・・・と相談。嫌な顔一つせずどれどれ・・・と彼のアカウントで実験してくれた。そして再現した！おお、ビルドは合っていた！ということは違いはエクステンションか？すみませんがそのエクステンション一覧をコピペしていただけませんかね・・・とお願いし、自席に戻る。ちなみに向井さんのゾーンから僕の席まで自転車アリで１０分くらい。遠い。

もらったリストをもとに大量のエクステンションおよびアプリをインストール。しかもテストアカウントじゃなくて自分のアカウントに。なぜなら社員アカウントにインストールされる謎のエクステンションとかが原因だと困るから。すると・・・再現した！ついに！差分に怪しいエクステンションはなかったから、量が問題だったようだ。ランダムにエクステンションがクラッシュする。（クラッシュしたとポップアップがでる。）タブの中身もたまに変。

ちなみにこの再現手順がまためんどい。アカウント作成後、初回ログインの直後でだけ起こるという。ログイン直後に発生するアカウントようデータのダウンロードが負荷をかけて問題を起こすらしい。だからアカウントを作ってはログインし、再現を見届け、ログをにらみ、ログを入れ直してビルド、バイナリ転送、アカウントを消し、作り直し、ログインし・・・というターンアラウンド。そして相変わらず原因がわからない。

Chrome のコードには任意の場所でスタックトレースをダンプする機能がある。これを使ってログを取ろうとするも、リリースビルドだとシンボルがない。関数名がわからない。そこでデバッグビルドをつくり転送・・・するとディスク容量不足といわれる。まじかーーー。Chrome は autoupdate にパーティションのトリックを使っており、システム(Chrome 含む)の入ったパーティションはすごく小さく切ってある。なのでバイナリが 100MBでかくなっただけでもう溢れる。うええ・・・。そしてパーティションを大きくするには自分で Linux のイメージを作り直さないといけないらしい。それはしんどそうだ・・・。リモートデバッグをする方法もあるというが、デバッガを使いたいんじゃなくてバーっとログを出して眺めたいのだよ・・・そしてリモートデバッグの設定もそれはそれで大変げ。つらい・・・力尽き帰宅。

木曜。 デバッガなしシンボルなしは辛いが環境つくるのも辛そう・・・。ぼんやりとプリント文を足して眺めてたり、改めて手元のUbuntu 上で動かしなおしたりするうち、辛さが眠気に変わってきた。昨晩ちょっと夜更かししたせいもあり、すっかりフォームが乱れている。もうやだぜんぜんわからん・・・と一時間くらい昼寝。

少し回復したのち、原因の仮説を書き出して一つ一つ検証していこうと気を取り直す。プリント文も雑に入れたのは消し、条件を絞ってプリントできるようグローバル変数を足すなどの小細工に時間を使う。(こういうのをさぼってしまうのがフォームの乱れなわけです。)

ライブラリのコードをにらみつつ、うーむエラーになるパスに入るにはこのフラグがオフのはずで、たしかにオフなのだがそもそもこれ何だろう・・・と引数に渡すフラグの値を変えてみたら・・・

直った！！なんだそりゃーーー！ まぐれだと困るので周辺の調べを進めるも、たしかにこのフラグで良さそう。

しかし見覚えのない定数だなあ・・・と git blame すると、去年の終わりに足されていた。僕がその API を使った部分を書いたのはもっと前。そりゃ見覚えないわ。というかこのフラグを足すときに挙動が変わっているんだから、呼び出し場所を直しておいてくれよ・・・と言いたいところだけれど、そのライブラリは不幸にもレポジトリが別なためそうした気の利いた変更は(確実にクラッシュするような場合をのぞき)されないのであった。

自分がやっている IPC 載せ替えプロジェクトはプラットホーム固有の問題が多く、Windows で動かない、Mac でだけテストが失敗する、Nexus 9 でクラッシュときて今回ついに Chrome OS。普段 Linux で仕事をしてるので無事全プラットホームを踏破した。辛い。

とはいえ今回の一週間はさすがに時間がかかりすぎ。Lesson Learned としては再現方法や再現環境が曖昧なバグに出会ったら再現できている人に直接あって話をしましょう、ですかね・・・近所にいないと困るけど。

先週社内の Android アプリ開発者があつまるカンファレンスがあって人々の発表を見たりなんだりした。いい意味でも悪い意味でも刺激的な回だった。色々途中をはしょって自分の takeaway を書くと、開発者からみた Android の問題は「いつかよいコードを書いて暮らせる日が来る」という希望をプログラマにもたせていないところで、それは問題だということ。

Android プラットホームはいまいち生産性を高めたりクールなコードを書いたりできる方向に進歩していない(しているが、進みが遅い)。しかもフラグメンテーションやら途上国向け廉価版端末の拡大などで、昔のムーアの法則みたいに性能問題も片付かない。結果としてコードが辛くても性能を優先し、なんとか使えるアプリを作りましょう、という結論になりやすい。

現状がそれなのは仕方ないのだが、どうもプラットホームを作ってる人たちは組み込み出身なせいもあってそういうクソコードに慣れすぎており、普通の開発者のペインを正しく感じられていない気がする。平気な顔で、クソコードを書きましょう、それがユーザのためです、みたいな話をする。検索社員にそれを強いるのはいいとして(いやですが)、その価値観は端々から染み出し、アプリ開発者からみたプラットホームとしての素敵さを損ねている。

これは他のプラットホームと比べた時大きな弱点になると思う。途上国向けにクソコードで頑張ろう、というメッセージは若くてキラキラした開発者には届かないよ。クールさの重要性を過小評価してる。

検索社員でもプラットホームの外でアプリを書いている人たちはそこまでクソコード信仰に染まっておらず、賢い人々が制約のなかでなんとかクールなかんじにできないかと試行錯誤しており (外から見えるやつだと Dagger とか Espresso とか) 若干の希望がある。でもそれが Android 本体に全然入ってこないのが悲しい。検索会社の中のコードだけ良くなっても根が腐ってたらしょうがないじゃん。

Android 本体の開発者は、プラットホームとしての中立性を気にして自分たち以外の検索社員からコードを守ってきた。文化的にも他の部署とは距離がある。おかげで何かと物事をカオスにしがちな検索会社文化のダメな面から Android は守られてここまで来たけれど、その一方で暇を持て余した頭のいい奴らがクールなことをする、という検索会社の良さが持ち込まれることもあまりなかったと思う。

独立を守る判断が悪かったとは言わないけれど、その結果が「クソコードで頑張ろう」だとしたら、あんまし嬉しくないなあ。もうちょっとクールなところを見せて、Android 開発にもクールなところはあるんだぜ、という気分にさせてほしい。それがないと辛い。キラキラした若者どうこう以前に自分が辛い。

そんななか Android アプリ開発者として自分はどんな方向を目指すか。今回一つはっきりしたのは、Android にどっぷり浸かるのは良くないということ。自分が大切にしたい倫理観や美的感覚が腐ってしまう。もともと Android を好きになってプラットホームと一緒に頑張ろう、と自分を説得しようと思っていたが、やめた方が良かろう。

それよりは、意識的に世の中の Android 以外の部分で楽しくてクールなものたちを摂取し希望の腹を満たし、その勢いで Android のダメなところをぶちのめす、みたいな態度の方がよい気がする。共に戦う仲間ではなく、あらゆるハックを駆使し攻略すべきオープンソースクソゲーとしての Android. プラットホームを作ってる人たちには悪いけど、こう考えた方が精神衛生を保ちつつ Android 業を続けられる気がする。Android の制約や特性を深く理解する必要はあるけれど、なかの人のお願いを聞いてやる必要はない。そういうパズルだと思えばまあ悪くない、かもしれない。

これはどこか Web platform に対する React.js の態度と似ている。Web platform guy だった頃は React あんまし好きじゃなかったけど同じ結論になろうとは・・・。なら React Native は正しいのか？わからんけど、そういうもんでもなかろう。あれは特に Android の問題を理解した上で作られてものではないからね。Android をハックしてクールな何かを作る方法はたぶん他にあるでしょう。

あまり深く考えたことがないが、何かは暗に期待している気がする。５年も同じ会社にいるわりにこれをよく考えてないというのは会社員的にはダメっぽい話ではある。

今までマネージャは４人。最初は日本人の A さん。つぎは隣の英語圏同僚 B があるとき「マネジメントやってみっかな」とかいってマネージャになった。(向いてなかったらしく、一年半くらいでエンジニアに戻ってきた。）つぎは転勤後、 Blink 全体をみている C さん。これは A さんの上司。そのつぎが Books で今の上司の D さん。

自分がひとつはっきりマネージャに期待していることといえば、上の方で起きた変化(隣接プロジェクトの開始、終了、方向転換など)を教えてもらうことだな。これは特に日本にいたときには思っていたし、今もまあまあ思っている。自分の身に降りかかってくる変化を予期したいからね。これは期待しているし、 1:1 で尋ねる。相手の情報通度によって結果はマチマチながら、何かは得られる。

上の方ではなく、チームの仕事の仕方や文化や歴史を教えてほしい。これは主に現在。いまいち色々な流儀がわからないので、よく 1:1 などで聞いている。同僚に聞いた方が早い場合もあるけど。

問題が起きたときに何とかして欲しい。たぶんしてもらうべきだが、自分はそれがうまくないとおもう。 会社員になったときの最初のマネージャが期待に応える力が無さそうだったから、という影響もあるかもだが、助けを求めるのはうまくなりたいかもしれない。特に前のプロジェクトは色々辛かったので助けを求めようがあった気がするが、求めなかった。これは反省すべきなのだろう。しかし上司が辛さの根本的な原因を持ち込むこともよくある。だから自分の中で上司に助けを求めたい気持ちは薄め。

面白い仕事を持ってきて欲しい。これは最初の頃はあったかもだけれど、最近はどっちかというと変な仕事を押し付けてこないでやりたいことをやらせてほしい、普段はほっといてほしい、に変化している気がする。

ほっといてもらうのには概ね成功しているが、それは自分が何かしたからではなく上司の性格な気もする。ほっておく以上のレベルでやりたことをやれたか？そもそもプロジェクトを自分から始める方法というのはさっぱりわからないので始めたことがない。上司の協力を求めるべきところなのかもしれない。やりたいことは勝手にやるべき、みたいな謎の価値観が自分の中に暗にある。

人事評価のときに味方になってほしい。まあ、あるよね。ただ自分で出世の希望をもてない期間が長すぎてこの話題から興味を失っている。ほんとは考えた方がいいのかもしれない。しかしなんというか、成果を上げるのが先なのでいまいち興味が持てないなあ、今は。

フィードバックがほしい。うーむ・・・。たぶんもらうべきなのだろうけれど、気にしたことがない。前にひげぽんがこの話を書いてるのを読んで反省した。でもフィードバックしてほしい程度は上司も同僚もあんまり差がない気もする。

キャリア支援。あまり期待してない気がする。上司になんとかできると思っていないからか、自分のキャリアに対する認識が甘いからなのか。でも仕事選び、人事評価、フィードバックってのはキャリア支援みたいなものとも言える。単に意識してないだけで、ほんとは求める余地はあるのだろう。

組織のいざこざから守ってほしい。わからん。組織のダイナミクスに鈍感だったりあまり摩擦の多いところで仕事をしなかったりしてきたからかもだけれど、あまり困ったと感じたことがない。構造的にダメなものはあるが、そういうのは直属の上司にはどうにもならない気がしてしまう。ほんとは伝えておけば良くなるものもあったのかもしれない。

期待に答えてもらうために意識的に何かしているか？してない。自分の対人技能の低さを痛感するね・・・。人として失礼がないようにはしてるし、いうことはだいたい聞いてるが、そういうのは意識的とは言わない。

それ以外に、自分は思想的にマネージャになんかしてもらうよりはチームとしてなんかする、たとえば週報もマネージャに送るよりチームに送る方が正しい、というような価値観が根深くあり、それがマネージャを特別扱いしたくない気持ちにつながっている気がする。でもそれは現実とは離れているし、直行する部分も多そうなので、マネージャの仕事を助けて見返りを得るという姿勢を身につけるべきなのだろう。このへんは価値観やメンタルモデルの校正が求められる。

これに限らず自分は機能しない暗黙の素朴な価値観によって行動が麻痺してしまうことが結構ある。なんとかすべきだけれど、それは価値観を無視していいわけではなく、それについてよく考える必要があるということなので難しいね。すぐにできることではないけれど、徐々に考えたい。

なぜ外資で働くのか。

特にkzysになんか言いたいわけではなく、ふと考えを整理したくなったのでしてみる。なおMacbook 水没故障につき途中から Moto X で書いてるので、なんか変かもしれない。モバイル力低し。

kzys はなぜ外資で働くのかと聞かれた時…と書いてるけれど、プログラマの身からすると、なぜ外資で働くのかと疑問に思う気持ちがよくわからん。商業ソフトウェアというのはアメリカの独壇場であって、US based company で働くかどうかは、多くの場合するかしないかというよりはできるかできないかの問題ではないか。オープンソースもまあ、だいたいアメリカでしょ。

仕事にする上で不安があるのはわかる。でもそれはたとえば日本支社で実際に開発してんのとか、英語できないとムリじゃないのとか、十分に高い専門性がないと雇われないんじゃないのとか、そういう点ではないか。そこでコード書けるもんなら書きたいに決まってるじゃん。自分はそこに疑問を感じたことはなかった気がする。

自分の記憶は改竄されていないか？どうだろう。たとえば最初の勤務先は経営者が "Post-PC 時代で打倒 MS" みたいなことを言っていた。日本市場を制覇して海外進出してと、当時その言葉が一定程度の信憑性を持つ瞬間はあったかもしれない。自分はそれを信じていたか？わからない。少なくとも勝つ姿を想像できてはいなかった。想像できなかったのは想像力不足かもしれないし、手元にあるコードがしょぼすぎたせいかもしれない。

会社員になって1年目の終わりくらいに、自分の書いている SVG の実装と Mobile 向け Flash がコンペにかかる、という事案があった。そのコンペは負けて、まあ考えると当たり前の結論ではあったが、自分は結局モバイルも上の世界(PC)からやってくるコードに負けるのだな、と結論した記憶がある。今のスマホ市場を見るとこの結論は必ずしも正しくないけれど(Flash は死んでしまったし)、グラフィクスの専門家が書いたコードに私大新卒のしょぼいコードが勝てない、という見方をすれば圧倒的に正しいとは思う。そしてそんな専門家は周りにいなかった。

1-2 年後に会社の雲行きも怪しくなったりして、その頃には日本のソフトウェアが US のものより良くなりうるという言説は信じていなかった。そして自分の経験から、勝敗の理由は謎のアンフェアさではなく実力どおりだと思っていた。市場の動向を見ても、ウェブサービスで US の流行りを輸入して成功した会社がその後ぱっとしなかったり、Twitter みたいに国内クローンを寄せ付けないものが現れたりして、確信は深まった。まあこれは追認バイアスかもしんないけどね。

なので US based 企業で働くという選択肢があるのならやりたいというのは、その選択をした時の自分にとってはすごく自然だったし、その感覚は今でも変わらない。すごい当たり前に思ってるけど、案外一般論じゃないのかね。

もちろん "選択肢がある" というところはそんなに自明でもなくて、選択肢がないと感じるのは理解できる。自分も選択肢があるとは思ってなかったし、東京に Chrome/WebKit のチームが来る偶然がなければ選択肢はないと信じ続けて特に挑戦はしなかったと思う。もともとそんなにガッツある方じゃない。機会があっても家庭の事情や生活の幸福度などで日本をとることもあろう。それも理解できる。

でもなんでって聞くようなもんじゃなくね？親戚のおっさんとかならともかく…電機メーカーみたいに世界で戦えてた過去があると、また違った世界観が見えるのかねえ。わからん。

まあそれはいいとして。

日本の会社で働いていたら、振る舞いの選択として "日本に閉じる" のは現実的な気はする。

たぶん kzys はこの記事を参照しているのだと思うけれど, 自分が日本の会社で働いているとして, 業務時間外の半職業的活動(学習, 腕試し, コミュニティ参加, 自己宣伝)をどう割り振るか.それを国内/英語圏というコンテクストで捉えた時どう見えるか.

単純に挑戦や学びという点で見るなら、半職業的活動も英語圏になるのは自然に思える。言語とか特に関係ないことも多そう。

コミュニティ参加は悩ましい。英語圏のコミュニティの方が大きいし「本家」であることも多いだろうけれど、入っていくのは大変だしミートアップも海外でやられて参加できなかったりする。日本のコミュニティは周縁的だけれど、敷居は低いし実際に会って話すのもラクだろう。コミュニティに参加して「仲間感」みたいのを楽しみたいなら、そういう敷居の低さは意味がある。

自己宣伝。日本にいて日本の会社で働くつもりなら、英語で書いてもあんまし意味ないよね。

リンク先の人がやってるような活動は、ここではコミュニティ参加と自己宣伝に割り振って良いとおもう。自己宣伝というと聞こえが悪いけれど、読者の求めがあることを書くなり話すなりするわけで、意味、価値はある。挑戦としての面白さはどうかわからんけれど。

逆に英語圏で、日本人プログラマがコードを書く以外の価値のあることをするのは大変だと思う。コードを書いて意味のあるとこまで行くのも、言語バリアはさておき競争は激しい。なのでめちゃコードをかける場合以外、生み出す価値の期待値は低くなりがちな気がする。ただ挑戦としての張り合いはあるように見える。

なので英語圏でがんばるかどうかは、価値、成果の出しやすさを重視するか挑戦を重視するかのトレードオフと、その人の技量、競争力に依存して決まるものではないかしらね。

英語圏でやったほうが成果になる。そう口にするの人がいるのは、実力者ゆえの遠慮のなさか、強がりか、どっちかだとおもう。

自分は職業経験のおかげで、コードならジャンルを選べば（ブラウザ周りとか）英語圏でも成果を出せると思う。でもコード以外はかすりもしない。でもブラウザまわりでなんかやったり日本語でなんか書いたりするのはいまいち退屈でやる気にならない。そのせいで業務外活動では長いこと何も成果を出せていない。「価値」を生んでない。これは自分の成果への期待値と実力に齟齬があって、期待値に近づく方を優先してる結果なので仕方ないと思っている。

仕事で Closureという内製 JS ライブラリ+ 型注釈コンパイラを使っている。これはまあまあよくできている。型とライブラリのおかげでGoogleは複雑なコードが書けたのだとわかる。2008 年くらいにこれで仕事をするのはクールだったに違いない。でもいまとなっては TypeScript, React, Node エコシステムの方がいいし、そもそもJSが最前線でない。

その 2008 年前後、自分が一瞬 SGI にいた頃、そこには内製の C++ シーングラフライブラリや複数マシンを同期してでかい画面に絵を出すツールキットとかがあった。2000 年くらいにこれで仕事をするのはまあまあクールだったろうな、と思った。でもその時点ではPCゲームのほうがだいぶ先を行っていた。

かつて最前線だった場所にあとからやってきてその残り香(あるいは腐臭)を嗅ぐこの感覚は、寂しさもあるが感慨もある。歴史的遺産の見学。遺産すなわちレガシーだから現実的には単にろくでもない。でも世界のどこかでは今もきっとクールなことをしてる人がいて、それはエキサイティングだろうと思いをはせずにおれない。

via Facebook and Microsoft introduce new open ecosystem for interchangeable AI frameworks – Facebook Research

NN のモデル交換用フォーマットを FB と MS が共同で策定した(する)という話。お互いにモデルのパース合戦をするのに疲れたのか。こういうのが出て来るまでにはもう 1-2 年かかるとおもってたけど、案外早かった。MS はともかく FB がついてるのは期待できる。彼らも PyTorch と Caffe の相互運用をラクにしたいだろうからね。

コードを覗くとほとんどからっぽで、いまのところ実態と言えるのは onyx.proto ファイルのみ。かなり見切り発車な感じ。まあ早い段階から他のベンダー (TF, MXNet, etc.) を巻き込んでいきたいということなのでしょう。どうなるかねえ。自分の勤務先も無駄な arrogance を発揮せずちゃんとのっていってほしい。

しかしきみたち proto なのか。いいのかそれで。しかも proto2 かよ。微妙なバージョンの Proto に依存しているベンダーが多いから保守的に倒しとくわ、というようなコメントが書いてある。おそらく Hadoop のやつらのせいであろう。どうせならあまり手垢のついてないフォーマット使えばいいのになあ・・・。