まえの話の続き。

アプリにデバッグ用の UI を入れる狙いを広く捉えると、これは observability の改善だと言える。Observability, ソフトウェアの状態を外から見えるようにすること。場合によっては状態をいじれること。

Monitoring なんかは observability の一部と言える。ただしここでは主に対話的な observability, つまりデバッグ UI みたいなものを念頭に置いている。対話的な observability の実装に限っても色々な形がありうる。デバッグ用の dashboard かもしれないし、HUD 風の overlay かもしれないし、気の利いたCLI かもしれないし、何らかの shell かもしれない。

Observability の高さはそのチームやインフラの maturity を示す良い指標の一つだと思う。Maturity の高いインフラは低レイヤでプラットホーム寄りの observability が高い。Maturity が高いチームのソフトウェアはドメイン寄りの observability が高い。両方の水準が高いとインフラがアプリレベルの observability を高める仕組みを用意しつつアプリがきちんとそれを使いこなし、プラットホームレベルの指標とドメインがむすびついて見える。たとえば各 HTTP リクエストにタグをつけられるインフラがあり、アプリは機能を表すタグをつける。すると dashboard で機能毎の aggregation が見える、など。

今はオープンソース経由でインフラがどんどん進化しているから、インフラレベルの observability はちゃんとツールを持ってきて 使おうというだけの話かもしれない。たとえば API のクリーンさで新しいライブラリを選んだら observability がいまいち、みたいなパターンもある。逆にいうとライブラリやツールは observability で差別化することができるとも言える。React Debugger や Spark の History Server が良い例。

そしてアプリケーションレベルでの observability は未だに各プログラマやチームに委ねられている。結果として出来の良さにはばらつきがある。

Observability をがんばる価値は、一見するとそれほど自明でない。余計な仕事に感じるし、ソフトウェアのサイズが大きくなったり、ちょっと遅くなったりする。なにより observability のためのコードは多くが instrusive で見苦しい。何を observable にすべきかもアプリ次第ではっきりしない。これはかつての testability に似たところがある。テストは余計な仕事に思えるし、コードが複雑に、場合によっては少し遅くなる。けれど各種宣伝活動が実って人々は説得され、今は testability のコストに文句を言う人は少なくなった。

たぶん observability についても誰かが頑張ってアイデアを整理し、啓蒙する必要があるのだろう。どんな風に整理されるべきなのだろうね。自分はまだ考えが足りない。無念。

アプリで予期せぬ通信が発生し、不本意な帯域を使っている。そんなバグを直そうとまずは network traffic を記録する instrumentation を足してみる。今までも Log に URL をダンプするフラグみたいのはあったけれど、もうちょっとマシなものが欲しい。

最初は HTTP の API 前後をフックして記録してみたが、それだけでは不十分と気付き TrafficStats も併用することにした。コードの中で適当な処理の開始と終了のタイミングをマークし、その間の traffic を求める。ついでにテストオプションで起動時から現在までの traffic も記録できるようにする。

HTTP の API をフックするだけだと不安だった理由はいくつかある。一つは response のヘッダに Content-Length が入ってないことがあり、そのとき圧縮展開前の body の長さを知るのは難しそうだったこと。あとは依存しているライブラリの奥の方で自分の知らない HTTP ライブラリなどを使われるとフックしきれない心配があったこと。そして WebView みたいなネイティブコード内の出来事も記録したかったこと。TrafficStats は OS から値を読むので漏れなくデータがとれる。誰かが QUIC で UDP を話しはじめると詰んでしまうけれど・・・。

最初は記録したデータを analytics のインフラに送り集計しようとぼんやり思っていたけれど気が乗らず、かわりにテスト用の Activity をひとつ足してしょぼい Dashboard にしてみた。けっこう良い。もともと analytics 側で何らかのクエリを書き anomaly を探す気でいた。けれど現状の理解が足りていないせいで前提となる normal な挙動をわかっていなかったと気づく。

アプリの状態を観察する仕組みは、一番素朴なプレインテキストのログをさておくと Stetho みたいになんとかワークステーションで表示しようとしたり analytics にデータを飛ばして集計したりしたくなる。でもアプリに UI をつけるのが良い場合も多い。何かを試して結果を見る iteration も速いし、Dogfood build に同じ UI を入れておけばバグ報告をしてくれた人に情報収集を頼んだりできる。USB ケーブルを刺し adb bugreport してくれ、とはなかなか言えない。そして bugreport のダンプに必要な情報が含まれているとも限らない。とはいえ Activity#dump()  は、それはそれで実装しておきたい。

などと思いつつ Jake Wharton のサンプルアプリ u2020 を眺めていたらすごいがんばったかんじの dashboard が実装されたいた。さすがだ。自分のチームは弱小のためこのへんがいまいち整備されてない。社内のでかい/新しいアプリは色々工夫してるのだろう。誰かに知見を集めて欲しいもんです。と、ここに書いても仕方なし。

CLion のバージョンがあがったというメールが来たので眺めていると、Unreal Engine サポートだって。へえ。誰が使っているのか疑問に思っていた Clion, そういえばゲーム業界は C++ だったね。

自分も結局 subscribe した。ところが購入したあと一週間くらいで C++ 仕事が片付いてしまい寂しい結果となったのだった。せっかくだから C++ 書きた・・・くない。

NN の授業で bprob の挙動を理解しようとするたびいつも混乱してきたが、今日ふと Deep Learning Book の section 6.5 を読んだところだいぶ混乱が収まった。

この節では TensorFlow のような NN 処理系が bprob をモデル化する方法を大まかに説明している。基本的には欲しい gradient から output の方向に向かって再帰的に gradient を求めては chain rule を適用していく。少なくともプログラマにとって、これはすごくわかりやすい気がする。そして自分が混乱した理由もわかった。

授業で習う bprob がわかりにくい理由は大きく分けて二つあると思う。一つは data flow graph の概念がないこと。上の section 6.5 を見るとわかるように, data flow graph の DAG は NN のネットワークと一見似ているけれど少し違う。Data flow graph は AST みたいなものである。そして言語処理系が AST をたどって式を評価するように NN 処理系は DAG を辿って bprob を評価する。数式だけ眺めてこのフローを理解するのは、けっこう math 力がないと難しい気がする。自分はわかっていなかった。

理由その二は、"Backpropagation" という名前に output から input の「下方向」にむけてデータを押し出す (propagate する) イメージがあること。これは間違っていないし実際そういう由来なのだろうけれど、gradient を求めるという観点では 下流にある weight のノードから上流の output のノードに向け「上方向に」必要な値(gradient)を取りに行くと考えた方が馴染みがある。言語処理系が AST をたどるのと同じ順番だから。

汎用フレームワークのモデルである「取りに行く」スタイルが backpropagation の名前が示唆する「押し下げる」スタイルよりわかりやすい別の理由は、前者だと計算したい値が比較的はっきりしているからでもある気がする。「押し下げる」スタイルで考えていた時は、自分がどの値を propagate すべきなのかわからず混乱した。DAG の概念の不在が混乱に拍車をかけた。DAG の下流に propagate すると考えれば、まあ無駄はあれど間違ってはいないからね。

Data flow の DAG 上を再帰的に pull するスタイルで素朴に考えると gradient の部分式を何度も計算する羽目になり、実装に無駄が多い。だから効率的な push/propagate のモデルで説明したくなる気持ちはわからなくもない。でもプログラマにしてみれば部分式をテーブルにキャッシュするなり DP に書き直すなりしてこの手の問題を高速化できるのは当たり前なわけで、それなら「欲しい値を再帰的に求める」というシンプルなモデルとして理解し、ただし遅いから DP しましょうねと言われるほうがだいぶわかりやすいよなあ。まあでも腑に落ちてよかった。達成感大。

「プログラマのための XX 入門」みたいのは胡散臭いので読まないようにしてるけれど、場合によっては CS の基礎知識が役に立つ事もある例。まあ NN も CS なので当たり前か・・・

大統領選が終わった。感想などを書いてみる。

ベイエリアに住んでいる日本人はけっこう動揺しているのではないかと思う。自分たちの多くはビザや永住権で滞在しており、市民ではない。だから移民政策の影響を受ける。Trump 次期大統領の発言を真に受けるなら最悪国外退去や口座凍結もありうる。実際にそういうことが起こる確率は低いと思うけれども、万一起こると人生大打撃なので心配したくなる気持ちはわかる。今までそういう心配は皆無だった。ビザの期限切れはあるけれど、それは deportation とは違うからね。

政策上の不安のほかに、外国人差別の感情がおもったより根強いと思い知らされた薄寒さもある。ベイエリアなんてインド人と中国人が最大勢力みたいな地域。自分が差別される様をいまいち想像できない。でも Trump に投票したのはアメリカ人の約半数。そのすべてが差別主義者ではないにせよ、一方で敗れた Hillary 派の全てがリベラルというわけでもない。あわせて何割かは潜在的な差別主義者かもしれない。実際に racist として振る舞うのはそのまた数割なのだろうけれど。ただ差別される側としては人口の１割でも差別主義者がまじってたら十分イヤじゃん？

別の不安。自分のような大手テック企業社員は平均的アメリカ人の何倍も給料をもらっている。Sillicon Valley は Wall Street と違い、経済危機の際に公的資金に助けられたなどのわかりやすい粗がない。だからあからさまなバッシングは少ない。でも inequality があるのも事実。職に困っているアメリカ人が仕事を奪った外国人めと恨みたくなる気持ちも少しはわかる。人種差別だけでなく、こういう class division も感じずにはおれない。

といった事情から、自分やまわりの日本人は標準的アメリカ人および日本在住日本人よりも神経質になっているように見える。外国人という身分固有の面倒くささと言える。

新聞などでは Trump 躍進の理由として "less-educated/non-educated/working class white" の支持を挙げている。自分にはこれが一番のナゾ。Less-educated white, 高卒白人というのがどういう人たちなのか、まったくわからない。転勤で引っ越してきた身だと面識のあるアメリカ人はみな仕事の同僚。そして職場であるテック企業の製品開発部門に less-educated な人はいない。仮に正式な学位がなくても独習や業界経験で educated と区別がつかない人柄になっていると思う。

アメリカ生まれアメリカ育ちなら、その高卒白人とも何らかの形で接点があるのだろう。親戚がいるだとか、かつて less educated 地域に住んでたとか、メディアやサブカルチャーを通じて目にするとか。自分は一貫して大卒ばかりの会社でしか働いていない都市生活者だったけれど、日本の less educated な人々の姿なら少しは想像できる。人生を通じて何かしらは接点があったから。アメリカの less educated white はまったくわからん。たまに新聞記事を読むくらいじゃ足しにならない。

ベイエリアも二時間ほど車を走らせて郊外に向かえば Trump 支持の地域に入る。旅行なんかでそういう町に立ち寄ると、学位の有無はさておきたしかに白人が多い。というか Asian がいない。Latino もちょっと少ない。中華料理屋の客に一人も中国人がいなかったりする。そして油淋鶏だと思って頼んだメニューがチキンカツの甘いソースかけだったりする。この町の生活を自分はまったく想像できない。California は農業国だし、あたりには畑や牧草地も多い。たぶん農業か畜産業をやってるんだろうと推測はできる。でもそれ以上の想像ができない。ステレオタイプすらない。

自分の勤務先では、diversity への配慮から差別問題の理解を深めなさいねと推薦図書などを紹介したりする。その推薦図書は、たとえば黒人の思想家がマイノリティーとしての苦悩や怒りを綴った本だ。そういう本を読んでもいまいちピンとこなかった。そもそも差別をしている側、すなわち less-educated white について何もわかってなかったのがピンとこない理由の一つだなと今更ながら思い至る。理解しようとする順番が間違っていた。

どうにか身の危険を冒さずに less-educated white について知る方法はないかとおもっていたら、さっそく NYTimes が推薦図書リストを公開していた。一冊くらい読まねばなるまい。

国外脱出など。自分は今のところ特にそういう気はない。Muslim や undocumented immigrants のように激しく攻撃されている身の上だったり物事が思ったより悪くなったら考えた方がいいのかもしれないけれど。まだそんな気にはなれない。まあ本気で考えてる人はそんなにいないでしょう。さすがに。

わざわざ日本から引っ越してきた理由というのは人それぞれだろうけれど、大きく現実的な損得勘定と思想的なものの二つに分類してみたい。損得勘定は、たとえば給料がいいとか天気がいいとか。選挙の結果をうけ、アメリカで外人プログラマをやる利得の期待値は少し下がったように感じる(リスクが大きくなったから)。結果として損得勘定の見通しが黒から赤になる人は少しはいるかもしれない。

思想的なものというのは、シリコンバレーで働くぜ！的な理想や憧れみたいなもの。自分は昔からアメリカテック企業に憧れがあったし、その延長でシリコンバレー的な価値観を重んじている。そしてシリコンバレー的、というかアメリカのテック企業の価値観は、様々な形でアメリカリベラルの価値観や理想を体現したものだ。でかい会社だと多国籍でグローバリゼーションだからもうアメリカ関係ないでしょと思う人もいるかもしれない。でもグローバリゼーション自体がリベラルな価値の一部だし、多国籍に展開して何をしてるかといったらアメリカ的価値を売り込んでるわけじゃん。それで嫌われたりもしてるじゃん。

だから自分はシリコンバレーや巨大テック企業が国家を超えていくという一部の論調を信じていない。一部アメリカ人には自覚がないっぽいが、そこにある理想はどう見てもアメリカ的(アメリカのリベラル的)なものだ。アメリカ的過ぎてむかついたり疎外感を感じることもある。それでも全体としては、自分は同じ理想を信じている。国外脱出は、象徴的な意味で反進歩的な勢力に自分の理想を挫かれるように感じる。気に入らない。

などと自分の価値観を見直すきっかけになったのはよかった。

まあ理想だなんだとカッコつけてられないほど事態が悪くなったらさっさと日本に逃げ帰ってどこかの会社に泣きつき雇ってもらう所存だけれども、遠くの心配事はさっさと忘れて前に進む方が厚顔能天気でシリコンバレーっぽいし、良い意味でアメリカっぽいと思う。郷に入りては郷に従え。

家から南に三時間, San Luis Obispo の郊外にある Sycamore 温泉までおでかけ。

といっても yukop (妻) 企画による旅行のためどういう場所かはよくわかっていなかった。ホテルの各部屋に風呂桶と蛇口がついており、その蛇口から温泉の湯を張って入るという趣向。風呂桶のない暮らしをしていると湯が身に沁みる。そのほか露天が楽しめる屋外風呂おけとかもあったけれど、そういう non-private な湯は衛生管理のためか塩素がきつすぎて温泉感はない。

温泉はさておき個人的には南に下るためカルフォルニアロードトリップの定番 California State Route 1 を少し走れたのが良かった。海岸沿いで眺めが良い一車線の highway。ところどころに vista point がありゾウアザラシなどをながめたりする。帰り道は逆方向に遠回りして、なにもなさそうな山道 Route 25 を走ってみる。交通量が少なく無人の荒野を行く感じが楽しい。道なりの山肌には牛が放牧されており、これが grass fed ってやつかとおもったりする。

今回からようやく Cruise control の使い方を覚えたおかげで highway を走るのがラクになった。Bay area の運転は特段楽しくないけれど、そこから 1 時間くらいがんばって離れるとまあまあ荒野ドライブが楽しめる。もうちょっと遠くに行ける体力が欲しいもんです。

Courseraで Neural Networks for Machine Learning というクラスをとっており、ようやく半分まで進んだ。CNN, RNN, LTSM という三大知りたかった単語の正体がわかってよかった。後半はなんの話をするんだろう。個人的には応用編として TensorFlow でコードを書こうとなってほしいところだけれど、普通に理論的な話が続くっぽい。

授業の内容。むずかしい、というか超絶不親切。自分のような初学者はビデオをみただけだとまず間違いなく理解できない。だから周辺資料をがんばって読む。クラスのページにアップロードされている論文以外だと、最初は Stanford の 231n および 245d からリンクされている論文のうち関係ありそうなものなどをつまみ食いしていたが、結局 www.deeplearningbook.org の草稿から関係のある章を刷って読むのが一番役に立っている。

授業の話題の選択自体は正しそうな印象。あと教科書を読んだ上で話を聞くとそれなりに面白い。講師が NN における歴史上の人物の一人なので細かい発言がぶっとんでいる。たとえば "なんで hidden layer をそうやって呼ぶか知ってますか。私が気に入った名前だからです。hidden markov model という名前がかっこ良かったので hidden という部分をパクったのです" とかいう逸話をサラッとはさんでくる。わかりやすさよりはそういう雑談を楽しむクラスなのか。

クイズ。自力で必要なスコアを取るのはまず無理だと思うが、多くは答え合わせのフェーズで正答が読める。なので何度かやればだいたい大丈夫。クイズは単純な復習でなく、事実上授業のコンテンツの一部になっている。このスタイルは好きではない。ただゴミではなく理解の足しにはる。

コーディング。相変わらず Octave は好きになれない。あと training が手元だと普通に 20 分くらいかかる場合があり、複数のパラメタでトレーニングしなおしたりする必要があるため時間を節約する工夫が必要。自分は GCE で 8 core のインスタンスを借り、カネの力で解決した。Octave の vectorization はぜんぶのコアをきちんと活用しており感心。

といったかんじで良い所も悪いところもあるコース。

授業と教科書の組み合わせでもなお理解できず仕舞いなトピックも残る。後続の講義でその不理解がボトルネックになったことは今のところないけれど、いつか理解不足で挫折するかもという危険は感じる。完遂できる自信はない。ま、できるところまでがんばります。

遅い API にキャッシュをいれて速くしたい。サーバ側の話。

Tracing 結果をながめながら Bigtable の速度に感心する。Read が速い。Write もまあまあ速い。遅いのは Spanner. Spanner が遅いのは仕方ないから、こいつをストレージに使っているバックエンド API の結果は適当にキャッシュして速くしたい。Bigtable を HBase, Spanner を MySQL かなにかに読み替えてもらえばだいたい気分はわかるはず。

自分はサーバサイド要素技術の知識が 10 年前くらいで止まっているけれど、当時の LAMP スタックだとデータはぜんぶ MySQL などの RDB に入れ、遅い部分は memcached や Redis にキャッシュしておくのが定石だったと思う。キャッシュの validity を保つのが面倒だった。

Bigtable/HBase はだいたい十分に速いから、その上にキャッシュがほしくなることは少ない気がする。キャッシュを持ち込む複雑さを受け入れてまで 10ms を 5ms にしたいほど速度に厳しいシステムや API はそれほど多くないだろう。でも 100ms が 10ms になるなら頑張りたい人はいるに違いない。（数字はてきとうです。）

Bigtable/HBase のような速いストレージに RDB ほどの柔軟性はない。けれど一応 the source of the truth ではあるからキャッシュにともなう面倒もない。Caveat: replication の遅延とかで完全な consistency はない。Eventual のみ。

"RDB + Cache" モデルに対するこの "速い KVS(?) + 遅い RDB" モデルは、非正規化したスキーマを考える面倒なんかはあるにせよトータルな面倒量の差分は昔思ってたよりも少ない気がしてくる。特に速いものを作りたいと思っているのなら速いストレージを使うのはありだよな。たぶん。HBase はさておき Redis を HA 構成で動かしつつキャッシュ以外も色々保存している人々はそういう判断なのかもしれない。

でかいシステムのデザインを自分でイチから考える日は来なかろうとシステム構成の話題は無視しながら暮らしてきたけれど、少しはわかった方がいいよなあ。どうしたらわかるようになるのかわからないけれど、Netflix あたりのモダンなシステムの話を読むくらいはすべきなのかね。

なお自分がさわっているシステムのコードはだいぶ古めなので、以上の記述は勤務先の標準的な構成を示唆するものではない。とおもう。