via Neural Architecture Search with Reinforcement Learning

話題になっている論文を読んで全然わからず撃墜されようシリーズ。

これはまあ表題にあるような話で、具体的には LSTM で CNN や RNN のアーキテクチャを生成し、その性能を実際に train して求めては reinforcement leraning で探索する、というものらしい。よりまともな説明は Research Blog: Using Machine Learning to Explore Neural Network Architecture などを見ると良い。

NN で RNN/CNN のアーキテクチャを探索(生成)するというのが面白いところなのだと思う。うまい具合に解空間を絞っておいてあげないと探索しきれないので、そのへんのさじ加減が妙。

それはさておき自分はそもそも reinforcement learning が全然わかってない。gradient が計算できなくても "policy gradient" というのが計算できればよい、らしいが、なんだそりゃ。総当りや greedy とも違うのだろうし、なんだかまったく謎。Reinforcement learning なんてロボットとかやってる人だけのニッチかと思っていたら、こうして汎用的な目的でも使えるのだなあ。きっとそのうち勉強しないといけないものなのでしょう。そんなもののリストはひたすら伸びていくばかり・・・。

あとぎょっとしたのはトレーニングに 600 GPU も使っているというところ。NN 関係、分散できそうで案外できないように見えていたけれど、そんなにスケールできるとなるといよいよでかい企業の独擅場になってしまいそう。ちょっと前に FAIR に CNN をガっと 200 GPU くらい使って並列化する話があったのを思い出す。まあ独占的にでかいデータセットを使う話ではなくあくまでアルゴリズムの範疇なので、外野でも再現性はあるといえばある。AWS でやるとか。しかし金のかかる世界であることには違いない。

続編にあたる [1707.07012v1] Learning Transferable Architectures for Scalable Image Recognition では、前の論文で発見したアーキテクチャ（を改良したもの）を積み重ねて使ったら探索に使った以外の、より大きなのデータセットでもいい結果がでたよ、という話。Neural Search でみつけた architecture が transferable なのだとしたら（そして transferable ってのは割と信憑性あるよね。結局実践の場ではどこかの researchers が手動で発見し論文に書いた architecture を再利用しているわけだから。) もう国家予算で 10000GPU くらいかき集めて最強の architecture でも探せばいいのでは、という気になってくる。天文学者が望遠鏡つくるみたいな・・・。

と、わからないなりに SF ぽさを楽しめる部分もあるね、NN 論文。楽しいという以上の効能はさておき。

一旦解約し、その shady なやり口に腹を立ててもう契約しまいと思っていた NYTimes, ニュースに飢えるあまり再購読した。悔しいが、一方で満足度は高い。読みたいものがある安心感。

解約後も少しはニュースを読まねばと思い、 まず Google  New をみたがしょうじき玉石混合すぎてというかレイアウトに読ませる意思を感じなくて無理だった。Router, BBC, Bloomberg あたりをみたけどなんかちがう。たぶん自分はニュースだけでなくちょっと長めの文章も欲しており、NYTimes はその面で質が高いのかもしれない。あるいは自分が思想的に青いリベラルなせいでそうでないサイトと相性があわないのか。ただ右左かかわらず新聞社のコンテンツはだいたい paywalled で、どのみち金は払わないと読めない。それなら慣れ親しんだ NYTimes でいいです、となった。むしろ解約後ずっと週一で紙バージョンを買っていたおかげか紙面構成に適応が進み、前より楽しめるようになっている。

ニュースへの飢餓感、東京にいたときは全然なかったけど異国に住むと感じる。住んでる国の現状がぜんぜんわからないのは怖い。それは理論上日本でも同じはずだけど、母国のことはなんとなくわかっていると錯覚できた。異国だと記事を読んだ時に感じる面白さもだいぶ違う。割と素直になるほどアメリカこういうかんじかー。と感心できる。批評性のかけらもない態度だけど、批判的に読んだところで事実関係を追跡する時間も能力もないからね。アメリカ素人だから。それはいいです。

まあそういう理屈はさておき一日の中のやる気がない時間にニュースジャンキーとしてヘッドラインを眺め読みたいものが見当たらずイライラする日々が終わったのがめでたい。自分にとって興味深い story を読むのは欠かせない楽しみだったと痛感。しかし新聞読んでうむうむ言ってるあたり、完全におっさん。

紙バージョンといえば新聞とは別に長めの文書を読みたいと思い New Yorker はじめ数冊買ってみた。どれもそこそこ面白いけれど、決定打はないという印象で購読には至らず。

via Google has dropped Google Instant Search

HN をみると結構嫌いな人がいたのだとわかる。うっとおしいという評価らしい。自分はデスクトップだとほとんど Omnibox からしか検索しないので使い勝手への意見はないが、きっとそういう面はあるのだろう。

以下もひきつづき外野としての感想。

タイプしおわった瞬間にはもう答えがわかってる、というアイデア自体は良いと思うのだよな。タイプしているそばから結果を取得して表示するのが Instant なわけだけれど、結果を fetch だけして表示は変えず Enter された瞬間に prefetch しておいた結果を表示する、とかにすればうっとおしさを犠牲にせず速さだけ手に入ったのではなかろうか。たとえばいま「カツ丼」と検索すると 0.81 秒かかった。これがなくなるとだいぶうれしくね？

まあ、そのくらいのことは中の人は考えてるだろうから、外野がどうこういうものでもない。投機的実行というのは何かと難しいものでありますな。

本の写経をちまちまと進めている。意外とはかどらない。TF, 書いてみると事実上新しいプログラミング言語を覚えるのに近い。しかも言語の出来はあんましよくない (Python の DSL だから。) そして Mathy. なので写経といえどもけっこうもたつく。

そしてトレーニングが遅い！CNN で CIFAR10 してみよう、みたいなやつが手元の XPS13 だと普通に 15 分くらいかかる。15 分、たぶん界隈的には一瞬なんだろうけど、一日一時間しかない人にとっては割とつらい。トレーニング中はほっといて先の方の写経を進めるなど並列化しているけれども、限度があるなあ。この本で一番重そうな model はこの CNN なので写経をしている間は我慢すればいいが、もうちょっと込み入ったものを扱いだしたらラップトップで作業は辛い気がする。ラップトップ、遅いだけでなく画面を閉じると止まってしまうからバックグランドで動かしておくのも難しいし。クラウド利用を再開しないとなあ・・・。

少し前に Benchmarking TensorFlow on Cloud CPUs という記事があって、この人によると価格性能比がいいのは GPU ではなく CPU らしい。まあそうでしょう。それより興味深いのは、TensorFlow を PIP レポジトリ経由でインストールするかわりにコンパイラの最適化オプションを指定し自分でビルドすると CPU なら倍近く速くなるという。なんだそりゃ・・・金をケチるためにはビルドしたほうがいいが、環境構築にビルドを混ぜたくない。なやまし。

GCE の pricing を調べる。n1-highcpu-8 で考えてみる。月 $200. Preemptive Instance が使えると安いけれど、それだと boot disk が消えてしまうとかでややめんどくさい。一方で月に $200 ドルも払いたくないから、この高いインスタンスを必要なときだけ起動するみたいな使い方が良かろう。

必要な準備はなにか。最低限の provisioning script は前に買いたやつがあるから、あとはトレーニングが終わったら shutdown するスクリプトを書けばそれでいいかな。コード書くのはしばらくは Jupyter Lab で我慢しとけばいいでしょう。

ま、実際にやるのは写経活動がおわったあとなので細かいこともあとで考えます。

完全な脱線として手元のラップトップを速く出来ないか物色してみる。今の XPS 13 は i5 2.3-2.8GHz. 2 core (+HT). Macbook Pro にすると i7 2.8-3.8 GHz 2 core とか 3.1-4.1 GHz 4 core とかがある。そしてこの速くて高いやつは $3000 くらいする。 XPS13 の倍以上の値段だけど、性能も倍か。ちなみに XPS15 は同じ性能で $2100 くらい。しかも NVIDIA の GPU がついてくる。しかし Linux を動かすのは大変そうなのだった・・・。

Dell のコンシューマ向けのやる気の無さからして XPS15 Developer Edition が出る日は来ないだろうし、やっぱりクラウド生活に体を慣らす方が時代に即してる、気がする。

via Yes you should understand backprop – Andrej Karpathy – Medium

いい話だなーと思って読んでいたが、最後に紹介されているバグの実例が自分にはとても chase down できそうになくてつらい。Huber loss とか知らないよ・・・。

そもそも TF には微分不能というか微分が変な op は入れないでほしいなあ。Clip とかいかにもだめそうじゃん。まあそれいったら ReLU だっていかにもだめそうだが・・・。

via Achievement is not normal, it's lognormal

または、100x プログラマはどのようにうまれるか。それは each achievement の multicative accumulation である。なるほど。これは自分がこの間書いた利息で暮らすプログラマの話にちょっと通じるものがあるなあ。いずれにせよ与太話だけれど。

via Death By A Thousand Cuts - 1 year later series - Uchujin -The Blog

日本に10年住んでから英国に帰った人が文句を書くシリーズ、らしい。 HN. なんとなくコレクションしておく。

感想としては: 言いたいことはわかるが、それはさておきなんとも entitled な人だなあ。

Jupyter notebook でのコーディングにおける best practice みたいのが知りたいな、と軽く検索したりしてみたが、めぼしい記述はみあたらなかった。ふと Notebook の出処である工学部とかの Notebook はどうやってるのかと思って調べてみたら、割と違う世界が広がっていた。(これ や これ など)

Laboratory Notebook とよばれる実験とかの記録を残すノートは、発明や発見を示す重要な証拠である。要するに論文とか特許を書くときのもとねたであり、裁判になったときに提出する資料だ。だから客観性、網羅性、integrity、などが重要。かなり rigorous にやっている。

省みて Jupyter Notebook はどうか。Data Science な人たちの一部は reproducibility を強調している。Reproducibility は Laboratory Notebook の精神に通じるところがある。Jupyter notebook は何も考えないと reproducible にならないけれど、ふつうのプログラマならそれを reproducible にするのはむずかしくない。バージョン管理も、まあするでしょ。なので Laboratory Notebook に必要なものの多くは簡単に実現できる。

そして自分の関心は、証拠づくりよりは自動化や整理整頓を通じたワークフローの効率化にある。あとはツールとしての ergonomics を気にしている。これはいかにもプログラマ的な関心事で、Laboratory Notebook ユーザとは話が合わなそう。そして ML の文脈だと、プログラマとしての関心を追求するのもいいけれどその前に Laboratory 的な rigorous で scientific な物事の進め方を気にする方が良いのかもしれない。試行錯誤というのは自動化の反対側にあるからね。

具体性のないところで考えすぎている気がする。保留。

Learning Tensorflow の写経を始めた。色々あそんでみるにあたり TF スキルが bottleneck に思えてきたため。頭が元気な朝の時間を写経のような低負荷な行いに使ってしまっていいのか不安だったけれどやってみると TF コード書きはまあまあ mind melding で悪くなかった。後半の分散化とか high-level API  とかは写経に値するか微妙というかたぶんいらないので、途中までやって切り上げる予定。

以下 TF コード素人感想。というか不満点。こうした不満が大局的に的を射ているとは思っていないけれど、まあ入門時の気分を書き留めておくとあとから見て面白いかもな、ということで。

よいところ:

• Computation graph をつくって評価するというアプローチ自体はまともだなと思う。というか他のデザインがすぐには思いつかない。 Torch とかは違うというけれど。
• グラフ構築の API にきちんと operator overload をつかい、かつ numpy 互換ぽくしたのは偉かった気がする。

不満:

• 計算グラフの変数 (tf.Tensor) と評価後の値の変数 (numpy array) がまざりがちで辛い。この2つはある種の鏡像なのだから、その対称性や、逆に生きている世界が別である事実はデザインの上で強調されるべきだったと思う。
• Python の with が過剰。 Device とか引数にわたせばよくね？同じことは Graph にも言える。特に辛いのが Session の closer に with をつかっているところ。Session を使ったコードブロックは膨らみがちなため、インデントされたコードの範囲がどんどんでかくなっていく。これが Jupyter だと辛い。まあ Jupyter では InteractiveSession を使えということなのかもしれないが。あと with に頼らざるをえないのは Python に無名関数やブロック記法がないせいなので TF のせいじゃなくて Python のせい、とも言える。ここでブロックが使えたら Tensor と Numpy がまざる問題もだいぶ軽減されたのにね...
• Session.run() の feed_dict が global() でひっこぬく前提の作りになっている。変数名と Tensor の 名前が混じり合って辛い。これも Python 側での名前と Tensor name を一致させる努力をしてほしかった。Graph の __setattr__/__getattr__ を使うとかさ。やりようはあるじゃん？

TF は割と lower-layer な抽象のはずなのに中途半端に API usability をがんばっているのが違和感なのかもしれない。最終的には何らかの higher-level API を使いましょう、という話なのだろうけれど、たとえば Keras みたいにガッチリ下のレイヤを隠してしまうのが常に良いのかはわからない。むしろ best practice を encourage するような薄い層をかぶせるくらいでいい気もする。

あとどこまで Jupyter Lab(Notebook) で書いてどこから  .py を書くべきなのかもわからない。training を Jupyter Lab から実行するのはなんとなく脆弱でイマイチにおもえる。が、一方でモデルをつくったりデータを除いたりするのは対話的環境の方が嬉しい気もする。データ整形と可視化だけで機械学習のない Data science ならまあまあ全部 Notebook でも良いと思うんだけど。このへん世間の人がどうしているのか知りたい。

Information Theory: A Tutorial Introduction: James V Stone: 9780956372857: Amazon.com: Books

というわけで読み終わった。

エントロピー入門。難しい証明はせず、ちょっとした式変形ですむ証明はしつつ、解釈や直感的な理解に重みをおいている。真面目なやつを読みたい人は真面目なのを読むのが良いと思うけれど、自分はこのくらいでよかった。200 ページくらい。

最後の二章は物理学、脳生理学におけるエントロピーみたいな話。あまり真面目には追わず流し読み。Maxwell's Demon とか、そういえばなんか聞いたことあるねそれ・・・みたいなかんじ。

Entropy というものを完全に腑に落とせたかというと no だけれども、式をみてもビビらないようにはなった。ただ entropy とか logit をつかってなんかやる系の計算にはしばらく近づかない気がするので無駄といえば無駄。気を済ますため、納得税としての読書だったとは思う。まあ納得税率高めな性格のため仕方なし。

via Manning | Deep Learning with Python

Keras の作者が本を書いていた！ひととおり TF に適応した頃に読みたい。どれだけ先になることやら・・・。

via We no longer have Basecamp Personal. – DHH – Medium

自分たち夫婦は TODO 管理の一つとして Basecamp Personal を使っている。なぜかというと Basecamp はまあまあまともなグループウェアであり、かつこの Personal 版が発表された当時は $25 一回買い切りというおとく pricing だったから。でも Personal という値付けはもうないらしい。そして Basecamp 自体むかしは無料枠があった気がするけれど、今は一律月額 $100 限定のビジネス専用グループウェアになっていた。

製品がなくなったといってもまだちゃんと使えているし、Basecamp 2 から Basecamp 3 への移行もできた。でもある日これからは毎月金払え、といわれたらちょっと困る。結婚、引っ越し、第一子誕生といった大掛かりな出来事がおわった平時の今はさほど依存していないので他のツールに乗り換えてもいいのだけれど、昔の記録が消えてしまうとしたら悲しいね。

いまのところ 37 Signals が金に困ってる様子はないのでさほど心配はしていないものの、自分がメインの顧客でない心細さはある。一方で家族むけのグループウェアとかすげえ儲からなそうなので、自分たちがメインの顧客になるまともなグループウェアというのはどこにもなさそう。まあ困る日が来たら考えます。

via 米国大学院に合格するためにやったこと

すごいなこのひと。これがエリートの根性というものか。

アメリカで職業プログラマをやるの、日本の米国資本企業から転勤する自分のようなのが一番ラクで、つぎがビザだしてくれる会社に直接応募する路線、いちばんのハードコアがこの留学だとおもう。特に社会人からの留学はいかにも大変そう。

転勤というある種のショートカットで来る人と留学正面突破の人のスタート地点は必ずしも同じでない。かたや入試というバーをこえ学校で散々鍛えられてから仕事を始める。他方はぶーたら仕事をしてなんとなく来てしまった人。実力に差があるのは当たり前。まあ実際は転勤でやってくる人の中にも優秀な人はたくさんいて、それはそれでエリートだなと思うけれども、転勤は不足をごまかせてしまうのは事実。

インターネットによって可視化された別世界の生態が目に入った時、たまたま米国でプログラマをやるという共通点があるからといってリンク先の人のような根性のあるエリートとボンクラな自分を同じ土俵で比べても詮ない。それでも、こういう人たちが目にするであろうアメリカの情報産業は、自分がみている世界とは違うものなのだろうなあとおもうと少しだけ寂しい。

自分もがんばればそうなれたのだろうか。と問いたい誘惑はあるが、それは自分はがんばればエリートになれたのだろうかと問うようなもので、若干トートロジーっぽい。エリートというのは異常ながんばりを永続的に続けている種族なわけだからね。

自分はがんばれたか。問いへの答えは実績をみればわかる。自分はこのさきどれだけ頑張れるかを問うなら少しは意味があるかもしれない。エリートのようにはいかないけれど、ボンクラのなかではマシな方でありたい。

via Research Blog: Using Deep Learning to Create Professional-Level Photographs

これも GAN らしい。Street View の画像を crop している。そして discriminator の training data は 500px.com からもってきたとしている。なるほど・・・

Kullback–Leibler divergence. これがさっぱりわからず喉につかえていたため、 Amazon でみつくろった易しい情報理論の本を読んでいた: Information Theory: A Tutorial Introduction. 200 ページの薄い本。150 ページあたりでようやく K-L Divergence 登場。

K-L Divergence はこんなかたち...といってもこのブログは数式をつかえないため latex-like にかくと...

D_{KL}(P(X), Q(X)) = \int_{x} p(x) log \frac{p(x)}{q(x)} dx

これ以前みたときはさっぱりわからんかったけど、entropy を復習してからみるとなんとなく親しみのある形をしている。(そしてむかしむかし卒業論文とか書いてた頃はこの表記を脳内でレンダリングできたはずだが、今みるとぜんぜん読めませぬ。これは quicklatex.com で確認しつつ書いてます。)

これをちょっと変形すると腑に落ちやすくなる。

D_{KL}(P(X), Q(X)) =
   \int_{x} p(x) log \frac{1}{q(x)} dx
 - \int_{x} p(x) log \frac{1}{p(x)} dx

ひとつ目の項が P と Q の cross entropy, ２つめの項が P の entropy になる。 つまり cross entropy が単一の entropy よりどれだけ大きいかの指標が K-L Divergence.

D_{KL}(P(X), Q(X)) = H(P, Q) - H(P)

なぜ cross entropy がこの形なのか(とくになぜ非対称なのか)は釈然としていないけれど、一方で Q = P のとき最小になる点を鑑みると有用性はわかる。そして NN とかの loss function だと P は training data で固定だから K-L Divergence を最小化するには cross entropy を最小化すればいい、というのもわかる。

というかんじで、完全に腑に落ちていないとはいえもともとは cross entropy の式の根拠がさっぱりわかっていなかったのに比べると表面的にせよ理解は進んだ。そして大した話ではないこともわかった。一方で entropy はけっこう機械学習っぽいこともわかった。150 ページを費やして得られる知識としては満足。せっかくなので残り 50 ページくらいもいちおう読む予定。

これを読んでいて思った事。とくに賛成とか反対とかではなく、関係あるようなないような話。

上の記事では、英語の難しさを「読む < 書く < 聞く」と分類している。というとだいぶ乱暴だけれど、まあ読み書く話す書くの難しさに序列をつける議論は良く見る。けれども、たとえば聞くのが読むより難しいのは本当だろうか・・・はさておき、読むより聞くのを重点的に訓練したほうが良いのだろうか。いまいち確信がない。同じ文章なら聞くより読むほうが簡単なのは確かだとおもう。でも文章の中身ってそのぶん難しいでしょう。そしてたとえば読むのが10倍遅いのと話を 1/10 しか聞き取れないのとどっちが不利益かというのも、そんなに自明じゃないと思うんだよね。

リーディングとリスニングの難しさの比較は本題じゃない。この序列はどこから来るのかを考えたい。それは、できない瞬間に感じる辛さ、ペインの強さに関係があるのではないか。リスニングできないと辛い。とっさに口から言葉がでないと辛い。読む速度が遅いのは、辛いというほどではない。うまく書けないのも、辛い時はあるけれど普段は割と大丈夫。

でもだからといって、読み書きの速度が遅かったり語彙がなかったり稚拙だったりすることで損をしていないとは限らない。たとえば、大量に飛び交うバグトラッカーの議論やメールを全部追いきれない、読むべき資料を放置してしまう、白熱したスレッドに口を挟めない、説得できない。ブログを書いてもまず HN や Reddit に載らない。気を引けない。こういう機会損失の大きさはランチの会話についていけない事実より軽いのか？わからない。でも刺すような痛みはない。オンラインの議論で折れる辛さは多少あるけれど・・・

ペインの強さと問題の重要度が同じとは限らない。これはバグトラッカーの「重要度(Priority)」と「緊急度(Severity)」の関係に似ている。昔のバグトラッカーは重要度と緊急度を区別していた。たとえばごく少数のユーザにだけおこるクラッシュは重要度は低いけど緊急度は高い、みたいに使う。この分類は紛らわしいので、最近は重要度一本のみのシステムのほうが多いと思う。

ペインで重要度を判断するのは, severity を priority とみなすのに似ている。実際のところ、これはそれほど悪いヒューリスティクスでもない。深刻なバグは、たとえ稀にしか起きなくてもさっさと直して悪いことはない。それにペインは自分を動機づけてくれる。英語ができなくて感じる憤りがやる気につながる。

近似としてもまあまあで、やる気がおこるボーナスつき。ペインドリブンは悪くない。

一方で欠点もある。ペインは対症療法に走りがち。バグでいうと、深刻なクラッシュを適当な NULL チェックを入れて直す感じ。本当は根深いデザインの粗かもしれないのに、急いで穴をふさいでしまう。同じように、英語のペインを感じる場面から逃げることで、仕事の質を下げたりキャリアの機会を逃してしまう。そうやって目先の痛みを塞ぐ所作が板についてしまう。これはたぶん、あまりよくない。自分がそうなりつつあるからわかる。

ペインドリブン以外に選択肢はあるのか？そもそもペイン以外に重要度を判断する術はあるのか？たとえば語彙数なんかは、世間で知られる指標と自分の現状からギャップがわかる。スピーキングなら、宮川さんくらい喋れればなあ、といった憧れは原動力になるかもしれない。こうした前向きな希望/目標ドリブンの勉強はありうる。でも希望だけだと心もとない。ペインドリブンの力も捨て難い。再現するクラッシュバグが直しやすいように。

自分の目標にペインを引き寄せることはできないか。たとえばリスニングを鍛えたいなら、本来聞き取れてほしい会話を聞く。読めてほしい本を読む。英語が苦手といいつつ英語圏のカンファレンスで発表している日本人プログラマがたまにいるけれど、それも引き寄せたペインに数えることができるかもしれない。

自分は英語のポッドキャストを聞いたり、日本語の本はきほん読まず英語でだけ読むようにしている。筋トレたる勉強に対し、これはジョギングみたいなもの。今まではそんなメタファで捉えてきたけれど、引き寄せたペインと考えることもできるな。

ペインドリブンから効果を引き出すには、自分の目標にあわせてペインを配置したい。ペインをデザインするとよい。セキュアなソフトウェアを作るために自腹でクラッキングコンテストを開くようなもの。あるいは遅いスマホでアプリを動かし性能の粗を探すようなものか。似たような議論を聞いたことはあるけれど、改めて考るとできることはまだありそう。

読むと聴くは引き続きやるとして、書くと話すのペインをどうデザインするか。話す・・・はアイデアなし。うーむ。まあジョギングじゃなくてペインなら、今までの自分のやり方とは違うアプローチがありそう。おいおい考えていきます。ストリート英語とかはこの路線なんだろうけど、さすがにガッツが足りない。

書くのは・・・やっぱりブログを日本語で書くのはダメだな。英語のブログ書き、練習にしてはフィードバックがないし、ジョギングにしてはきつすぎるからとやる気を起こせなかったけれど、ペインには違いない。ついったも同じ。

ペインをデザインする上で気をつけることはあるか。

まず、いつかペインが小さくなるという実感はほしい。だから訓練ナシでペインだけ、はよくない気がする。これは英語のブログ書きが抱えている問題の一つ。辛いだけでうまくなる感じがしない。たぶん書く訓練をセットにしないと盛り上がらない。

あとペインが辛すぎる、実害が大きいのも困る。仕事中の自分用メモを英語だけにすると進捗が落ちて諦めた。これは実害が大きすぎた。でもたとえば水曜日はノーIMEデー、くらいの緩さならいけるかもしんないね。

今年に入ってからは主に訓練サイドのことを考えてきた。このところやや煮詰まっていたので、ペインデザインに工夫の余地があるとわかったのはよかった。

最近 GitHub したさから RxAndroid にパッチ書いてる。なかなか満足度高い。ほとんどゴミ拾いしかしてないけどコミットは多いおかげで表面的には #3 contributor に成り上がった。 ゴミ拾い以外にもプロジェクトが本質的にコールバックインターフェイスを Observable に置き換えてく労働集約的なものなので素人にもまあまあやることがあってよい。

コードが小さいからブランチの移動やテストが速い。IntelliJ はよくできててリファクタリングがラク。そして 1.0 前なので割とガンガン変えてよい。ちょっとさわっただけですぐ何か壊れたりしない。快適。ちいさいことは素晴らしい。

レビューは割と細かいことを言ってくるのだが、仕事と違って Rx も Android も素人なので今のところ勉強になってよい。JavaDoc の書式とか忘れてるからね。そしてなぜか妙にレビューが速い。こいつら仕事(本業)してんのか感ある。特に Android オープンソース界隈で有名な Jake Wharton という人は他のプロジェクトも色々やってるはずなのだがすごい勢いでレビューしたり細かい雑用パッチ書いたりしててエラいね。そしてみな夜も普通に活動している。若者め・・・。

勉強になるとかはさておき、この色々な会社の知らない人が集まってガチャガチャやる感じが久しぶりで楽しい。WebKit も仕事で始めた頃はそんなんだったんだけど、今はそういうの全然なくて単に仕事だからね。RxAndroid は別に Jake Wharton はメインではなく、RxJava の Netflix もメインではなく、主に SoundCloud の人が書いたライブラリらしい。そのほか Trello だの Venmo など東海岸系の会社がおおいので、たぶんこいつらは知り合いなのだろうな。

Trello の Android 求人をみると確かに俺たち RxJava 使ってるぜとある。この求人は他の Android 求人とちがいちゃんとあんどろ好きに訴える感じになっててよい。その気になれば ListView 相当を自分で書けること、とか言われても書けないですが。

子供の離乳食が始まった。

今のところ朝だけ。離乳食の feeding を手伝うため、出勤が 20-30 分くらい遅くなる。結果として朝の職業訓練というか読書の時間が同じだけ削られる。

かわりに昼飯の時間をなんとかできないかと考え、昼飯の後ではなく前に時間をとってみることにした。30分くらい。昼飯の後だと眠くなるため。

数日やってみた感触としては: ないよりはいいけれど、そんなによくない。まず朝ほど頭が元気でない。数時間働いたあとだから。あと食事のあとの眠さやだるさが割と仕事に差し支える。食後の休みにはそれなりに意味があった。あとチームメイトや腐れ縁仲間（東京出身者）など他人とのランチがあるとだめ。

このいまいちさを受け入れるという選択肢がある。あとは昼飯の時間を削り、朝の時間を延ばすという選択肢もある。後者は、だるさで仕事が進まない問題は残るが読書時間の質の問題は解決する。

むかし、昼飯を一回たべるかわりにシリアルなどの軽食数回にわけてみたことがあった。食後の眠さがなくなるというライフハック。これは、虚しさと栄養の偏りという問題がある、が、栄養の偏りは実は自分の現状のランチと大差ない気もする。なので食事の虚しさを受け入れれば眠気の問題を解決できる。

というわけで、朝の時間を延ばし、昼食をやめてシリアルなどで空腹を凌ぐことにすると離乳食にともない失われた時間を取り戻すことができる。

朝五時から五時半に起き、家事や離乳食補助などをしたあと７時前に家を出て会社に走っていく。７時半前についたらシャワーを浴び、シリアルを食べ、８時前から８時半くらいまで読書などをする。そこから１０時くらいまで仕事をしてシリアルを食べ、また仕事をして１４時くらいにシリアルをたべ、１６時半まで働いて退社。１７時帰宅、シャワー、子供の風呂補助、掃除、炊事、で１９時半から２０時くらいに夕食。隙間にちょっと英語の練習。食後はぐったりしつつちょっとなんか読んで２１時から２１時半に寝る。というかんじか。

帰宅後、夕食の前後は少し時間がある（こともある）んだけれど、この時にはもう疲れていて入り組んだ活動は出来ない。そして availability も不安定。なので英語の教材消化１５分くらいをあてこむのがせいぜい。

更に extreme な方向として就寝を20時にして４時におきるのはどうか、と思ったものの、夫婦の就寝時間をあわせようとするなら２０時はむり。ゆこっぷ（奥さん）に２０時に寝ろとは言えない。夫婦の就寝時間をあわせないという選択肢もあるかもしれないけれど、関係の stability に影響がありそうでまだ踏み切れない。

まあ共働き、子持ち、睡眠時間削れない、体力ない中年、となるとこのへんが限界な気がする。残業もないし通勤も短いなど恵まれてる部分もあるので文句はいえない。

一年くらいして子供が授乳でない食事をとるようになると、朝は家族で食事をとることになるだろう。すると今のように朝早く家を出て会社でシリアルをたべる手は使えなくなる。そして食後に会社まで走るのは辛い。となると色々考えなおさねばならない。もうだめ、という気分になってくるけれど、とりあえず今は考えずにおく。

Learning TensorFlow - O'Reilly Media

O'Reilly が subscription に移行する直前くらいにゲットしたベータ版を読み終えた。

薄いのがよい。200 ページくらい。そして基本的に TensorFlow の話しかしない。機械学習のベストプラクティスとかはナシ。そういう話を他で散々読んだ身としては良い塩梅だった。

カバーしている範囲はだいたいオンラインの TensorFlow のチュートリアルやガイドと同じくらい、か、ちょっと少ない。本という体裁で読めるのは良い。説明も若干丁寧。コアにあるオブジェクトモデルとかを説明してくれる。かわりに入り組んだ新しいモデルの解説などむずかしい話はない。ところでひさしぶりに公式資料を眺めたんだけど、とょっと増えてる気がするね。

オンラインのチュートリアルとかぶらない部分もある。たとえば high level API として Keras や TF-Learn の章がある。ただまあ、こういう high level API は high level なだけあってオンラインの資料で足りる印象。すぐ変わるし。

オンラインの資料を順番に読んでくのがかったるい人には良い本だと思う。一通りオンラインの資料を読んで理解した人、もう hello world より先まで触っているひとは読まなくてよさげ。

ベータ版なのでコードは若干あやしげ。まあ出版される頃には直っていることでしょう。

職場での会話。

同僚「O の次は P か。何のデザートかねえ」自分「まだ O が何かすらわかんないじゃないですか」 同僚「Wikipedia にリストがあるな」自分「パフェとかどうすかね」 同僚「パフェ？」 自分「あれ、フランス語じゃない？(あたしの発音わるすぎ？)」 同僚「パーフェクトのパフェ？」 別の同僚「P-A-R-F-A-I-T」

同僚はフランス人なのだが、パフェといってもピンとこなかったぽい。「日本ではなぜか有名なんですよ」「ほんとだ。Wikipedia の写真も Osaka Japan だって」「(エビチリみたいなもんか・・・)」

パフェたべたいなあ。Sandaeといえば通じたのだろうか。松と竹くらいの違いだよね？

すごいプログラマのすごさの何割かは、そのプログラマが過去に書いたコードから来ている。割合には個人差がある。

たとえば Google の legendary programmer たる Jeff Dean. Jeff Dean は色々すごいことをしてきた。今でも相変わらずすごい。でも Jeff Dean がすごいことをできる理由の何割かは、Jeff Dean のコードを動かしているインフラ自身も Jeff Dean が作ったからではないか。ライブラリから実行環境まで、インフラに精通しているからこそ問題を速く正確に突き止めて解決できる。莫大な社内のコード資産を使いこなすのも朝飯前。自分の成果を leverage しているとも言える。精通しているだけでなく、そうした基盤のデザイン自体も何らかな形で Jeff Dean の仕事 ...すなわち Google の最新コアテクノロジ... に fit している。ありものを使わず色々作ってきたのは、まさにそのためなわけだから。

もし Jeff Dean がある日どこかのソーシャルメディアなスタートアップに転職し、AWS の上に作られた Scala バックエンド群の刷新みたいなプロジェクトを任せられたらどうなるだろう。たぶんちゃんとやってのけるだろうけれど、伝説的といえる活躍ができるかどうは不透明だと思う。積み上げた成果の利息は馬鹿にならない。

Jeff Dean に限らず、多くのエース級プログラマは自分の仕事自体を足場に次の歩みを進める。その仕事がだめにならないかぎり、利息が利息を産んで成果を加速する。すごく大きな成果を上げる唯一の手段が、足場を組み立ててながら上に登るこの方法だと言ってもいい。

一方で、エース級をめざしたりめざさなかったりする下々の者が目標としてすごいプログラマに尊敬の眼差しを向けるときは、相手のすごさの内訳にも思いを巡らせると良い。その人は資産の利息で暮らしているのか・・・つまりそれまでの成果をスケールさせる仕事がうまいのか。それとも今現在の稼ぎ・・・すなわち新しいことを学んで形にするスループット・・・が多いのか。両方か。二つの成果はどう関係しているか。

利息で暮らすのがダサいという話ではない。それはそれでいい。というかちょっと羨ましい。ただ自分の目指す姿、ロールモデルとしてエースプログラマを眺めるときは、そのすごさの出処を気にしないと空回りしがち。手持ちの資産がないのに利息生活者の真似をしてもうまくいかない。あるいは蓄えがあるのにそれを活かさず日銭ばかりを気にしても勿体無い。

名誉と保身と念のため補足しておくと、Jeff Dean が利息だけで暮らしてるという主張じゃないですよ。言うまでもないけれど。

via The View from Aristeia: O'Reilly's Decision and its DRM Implication on HN.

オライリーがオンラインで本および e-book の直販をやめて Safari Subscription のみに移行するという話。

HN のコメント欄は PDF が買えなくなる！と困る人々にあふれている。誰かが Play Books では PDF がダウンロードできるぞ！と言い、しかしその PDF は期待したものではないぞ！と不満の声があがる。たまに HN で Play Books の名前を見たと思ったらこれかよ・・・。

どうもその PDF は EPUB をレンダリングしたもので、製本の PDF ではないっぽい。しかしそれは製本用 PDF を納品してくれていない O’Reilly のせいであって Play Book のせいではないのでは・・・。たとえば Packt Publishing の本 (Python Machine Learning とか)はちゃんと製本用の PDF も取れるよ！濡れ衣だよ！！

理由はどうであれ製本 PDF がないのは不便といえば不便かもね・・・・と思いつつ O'Reilly 社長によるアナウンス を読んでいたら「PDF ないのは不便でごめんねなんとかできないか検討してるよ」というコメントをしていた。なんとかしてほしいもんです。O'Reilly の本をほとんど EPUB を読んでいる自分にとってはどうでもいいといえばいい話だけれど、一般論としては数式があると PDF が欲しくなる。

そして Play Books ユーザとしては別に O’Reilly の直販がなくてもいいかと思ったが、よく考えたら Learning TensorFlow は beta version で買っている。そして beta version は Play Books などの reseller には卸してくれない気がする。ちょっと不便になるなあ・・・。

Safari は月会費 $40. まあ入らないよなあ。

カンファレンスの録画が見れるのはよさそうではある。Pragpub や Manning もネットワーク内にいるから、月に二冊くらい読めてかつカンファレンス動画も週に数本見るくらいのガッツがあれば感覚的には元が取れる感はある。が、そんな時間も気力もないのだった。そしてネットワークの出版社は全ての本があるわけではないっぽい。たとえば Manning の Kotlin In Action は見当たらない。いまいち。

この判断が気に入らず他所の ebook friendly な出版社に鞍替えする著者が増え、O’Reilly が反省して直販に帰ってくる、という展開に期待しておきます。

via 第3回　常にそこにいろ：継続は力なり―大器晩成エンジニアを目指して｜gihyo.jp … 技術評論社

ひげぽん氏の連載がオンラインで読めるようになっていたのを知る。

この「常にそこににろ」は連載の中でもいい話だと思った。リーダシップをかんじる。リーダーシップを追求していない自分は、常にはそこにいない。線引きとしては、自分の仕事に直接関係あるものはやるけれど、そうでもないものはやらない。たとえばメールやコードレビューの返事はするしチケットも更新するけれど、長引いている技術的な議論、みたいなやつからは早めに撤収しスルーしている。たとえば Dagger をコードにいれるか否か、みたいなやつ。

Dagger の例のようにコードベース全体に影響がある話や、チームのポリシーに手を入れるような議論は長引く。そういう議論から撤収するということは、影響範囲の大きい判断には影響を与えないということでもある。影響力の大きさがすなわちリーダーシップだから、自分にリーダーシップはない。

影響力を諦めた見返りとして、人々が長々としたメールを書いたり追加のミーティングに時間を使っている間にコードを書いたり調べものや考え事ができる。ただ影響力を行使しなかったせいで物事が悪くなってしまっても文句は言えない。そういう時は諦めて逃げ出そうと自分は考えているけれど、あまり生産的な態度ではないとも思う。

Pick Your Battles という言葉がある。書籍 Fearless Change も pick your battles と念を押す。HBR には How to Pick Your Battles at Work なんて記事があった。何でもかんでも口を挟むのではなく重要なものに絞って参戦しなさい - 意見が強い人に向けたメッセージ。自分にもそういう時期があったかもしれないけれど、あちこちで不毛な戦いを目にするうちにアホくさくなり今のような態度が板についてしまった。でもたまには battle を pick した方が良いのだろうな。戦う気の無さは fear 故じゃないのといわれたら、まあそうかもしれないね。英語できないからでしょ、といわれるとだいたいそうです。