TensorFlow に固定小数点演算を実装していた人による What I’ve learned about neural network quantization という記事を読んでいたら、Snapdragon 向けにもそういう最適化をしたと書いてある。Snapdragon に載っている Hexagon なる DSP を使うらしい。調べるとなかなか歴史のある DSP で、TensorFlow 対応は Qualcomm が今年はじめに発表をしていた。速そう。

TF のコードを覗くも肝心なところは Hexagon SDK の中に隠れているらしく、つなぎのコードだけがコミットされている。そして TF 力がないのでどういうアーキテクチャなのかわからない・・・。

Hexagon 自体の概要は Qualcomm のスライドがよくまとまっている。省電力でアプリケーション固有命令をおおく備えた SIMD で VLIW の CPU ということらしい。と、これだけ読むと DSP ってそういうものでは・・・と思ってしまうけれど、汎用 CPU としても使えるくらいにはリッチでもある。メモリ保護とかもあって一応 Linux を動かした実績があるという。ということは何らかのコンパイラがあるということで、実際 LLVM のターゲットがあった。

VLIW ということで 4 命令までは pack して同時実行できる。SIMD として 64bit までの並列演算ができる。(8-bit 8 要素とか) そして 500MHz 動作かつ 4 thread までうごかせる。というかんじらしい。命令も fuse した命令が色々入っており、スループットは高いと主張している。リファレンスをダウンロードしてみると、その他に H.264 用の命令とかもあることがわかる。専用命令は Instrinsics を使うとしても VLIW とかどうすればコンパイラに指示できるのだろうか・・・。（そして リンク先の instrinsics の定義では H.264 用とされる decbin 命令がコメントアウトされているが大丈夫なのだろうか・・・）

それにしても自分はすごく初歩的なことがわかってない。実際の Android デバイスの DSP ではどんな OS が動いており、どのくらいのメモリが DSP に割り当てられ（そのメモリはホスト OS と共有するのか？)、どんなタイミングでコードが DSP のメモリにロードされ、実行され、ホスト側の CPU と DSP はどうやって通信するのか？だいたい GPU みたいなもだと考えればいいのかなあ。そういえば GPU と違って ISA が公開されているのは好感が持てるね。

GPGPU

GPU といえば Snapdragon の GPU は GPGPU できるのだろうかとふと調べてみたら OpenCL に対応していた。実際に使っている話を聞いたことがないが。

そして Snapdragon のライバル Exynos は DSP とかどうなってんのかなーと資料を探すも全然見当たらない。動画や音声のために色々 DSP は入ってるはずだが、Snapdragon と違ってサードパーティに公開はしていないのだろう。つまんね。ただし GPGPU は ARM のサイトに Mali SDKs というのがあって、それが使えるっぽい。めんどくさいから誰か Samsung と Qualcomm の両方に対応した Java の OpenCL ラッパー作ってくれないかなあ。そのくらい敷居が下がればやる気も起きるというものです。というか NDK に入れといて欲しい・・・

追記

その後もう少しだけ調べた。このスライドが色々謎に答えてくれたのと、SDK をダウンロードしてみたりもした。自分の疑問への答えを記録しておく。まず OS は QuRT という RTOS. 公開資料は見当たらない、つまり大したものではない。SDK が提供するプログラミングスタイルは、その QuRT に ELF の SO をロードさせ、ホスト側から SO 内の関数を RPC で呼び出すというもの。Hexagon  SDK に IDL コンパイラがついてくる。RPC の実態は ION と呼ばれる Android/Linux 提供の共有メモリというか DMA 機構らしい。

より重要な事実: Hexagon で実行するバイナリは OEM による署名が必要。つまりサードパーティのコードは動かせない！まじかよ！いみねーーー！そんなら GPU の方がいいわ・・・。TensorFlow が Hexagon 対応したといってもそこらへんのアプリが恩恵を受けられるわけではないのだなあ。がっかり。もちろん将来のバージョンの Android が Hexagon TensorFlow を同梱してくれればいいと言えなくもないけれど、そんなことが起こるのかわからないしどのみちバグがあっても直らない謎のバイナリに依存するのは OS の API だけでたくさん。はーがっかり。

追記

Android 8.1 に NN API が入ったので、こいつが裏で Hexagon を使ってくれれば良いのであろう。使ってるのか知らんけど。

Deep Learning 本, 最後の 3 章は挫折。理由を考えるに、自分は Structure Probabilistic Modeling がわかってないのでその知識を前提に話をされてもわからん、ということだと思う。16 章でちらっと説明があるわけだけれど、こんな駆け足でわかるなら苦労しないです・・・

20 章 Deep Generating Models をわからないなりに冷やかして把握したこととして、generative models には undirected graph に基づくものすなわち RBM/DBM などと、directed graph にもとづくものすなわち GAN とか VAE とかがある。そして RBM 勢は世間のニュースを観ている限りいまいち盛り上がってない。ので undirected graph ベースの structured modeling はがんばって勉強しなくても当面はいいのではなかろうか。

一方で今をときめく GAN とかは directed graph ベースのモデルだとされており、つまり Bayes net とか標準的な PGM の延長にあるっぽい。したがって graphical model 自体は勉強しないとダメそう。GAN や VAE が実際に graphical model と言えるのかはよくわからないけれど、結局 generative models は確率変数になんかする話であり、確率ベースの方法論である PGM にはそのための道具立てが揃っている、ということなのだろうなあ。きっと。Edward みたいのもあることだし、NN と PGM は最終的には両方やんないとダメなのでしょう・・・。

本全体の感想。なかなかよかった。特に Part 2 の実践編がよかった。NN の基礎的かつ理論的な部分ではだいぶ理解が進んだと思う。Part 3 は自分にはまだ難しすぎたけれど、それでも representation learning の章は面白かった。目次を除くと 700  ページくらいのわりかし薄い本な点も助けになった気がする。これ以上厚いと辛いだろうね。

一方で薄いせいではしょられている部分も多いから、二版が出るなら間違いなく厚まりそう。だからこういう本は薄い版のうちから読むのがお得と RTR (from 500 pages at 1st ed. to 1000 pages at 3rd ed.) から学んだ。まあ改版しなそうな予感もあるけれど。このゴールドラッシュの最中によく書いたよねこの本。エライ。

このあとどうしましょう。

まずはいくつか復習したいことなどが溜まってきたので、そのために必要なものを読む予定。これはすぐおわる（希望的観測）。

あといいかげんコードを書きたい。TensorFlow, 公式ドキュメントがやや不親切で再挑戦は気が重いなあ・・・とおもいつつウェブを物色していたら O'Reilly から Learning TensorFlow という本がベータ版として出版されかかっており、ちらっと中身をみたかんじ自分には割と良さそう。機械学習とは・・・とかいう話をすっとばして TF の説明だけしている。おかげで薄い。これを読もうかな。Hands-On Machine Learning with Scikit-Learn and TensorFlow も Amazon のレビューを見る限り良さそうだけれど、自分は Scikit-Learn 成分は摂取済みなのだった。

そのあとは cs231n なり cs224n なりで画像処理なり自然言語処理との組み合わせを勉強したい気もするけれど、そんな気力が湧くかは不明。ひげぽん氏みたいに自分でデータを集めてなんかやるのも楽しそうだし。ぬるく TF 入門を済ませてから考えることにする。

Generative Models の勉強もそのうち再挑戦したいけれど、しばらくは放置かな。確率や PGM など generative models の前に勉強しないといけないことが多く、数式をかき分け厚い教科書たちを読み進める気力が湧くまでは無理。しかもそれらを読んでる間はほとんど手を動かせない。まあ generative models がわからなくてもできることは色々あるでしょう、きっと。

ところで generative models はどうやって勉強すればいいのかとウェブを冷やかしていたらみつけた U. Tronto の授業、シラバスに「最後のプロジェクトは NIPS に論文書きます(誇張)」とか書いてあってフいた。さすが AI のメッカはちがうな。

今週は夏休み、というか子供のデイケアが二週間休みになってしまうので、そのあいだは昼間子供の世話をする必要がある。夫婦交代で仕事を休み子守。今週は自分のターン。

そうはいっても仕事がないならちょっとくらい何かできるんじゃね？・・・と思ったけど全く甘かった。手が空くのは子供が昼寝をしている 2 時間くらい。この間に昼飯を食べ、掃除などの家事をして・・・とかやってると仕事の忙しさと大差なくね？というか仕事の方がラクじゃね？

ラクというと語弊があるけれども、自分は子守には何の専門性もなく得意でもないので、だいぶぎこちない。あと気を使うので疲れる。専業主婦、これに加えて家事も全部やるとなるとなかなか大変というかちょっと無理な趣がある。主夫にはなれないな・・・。

運動不足を避けるため、朝ゆこっぷ（奥さん）が仕事に行く前に隙を見てジムで走っている。通勤ランと違いジムはいちおう本が読める。朝に読書。ここだけ夏休みっぽい。

ちょっと前に散々けなした Dagger, 仕事で使ってるのだけれども、まあまあいいね。細かい不満はあるしチームでの使い方にイマイチなところもある。が、ないよりだいぶマシになった体感がある。余暇コードみたいな小さいプロジェクトだと必要性を感じないけれど、仕事のでかいコードベースではあったほうがいい類のものなのだろう。

Activity や View のレイヤではあまり使われておらず、つまり field injection はやってない。まあ Field injection するくらいなら DI なんてなくていいと個人的には思っているので、つまり Activity や View にベタベタくっつけるようなコードは止めろというようなことです。誰となく。

Monte Carlo Methods.

だいたいが、むかし途中まで読んで挫けた Doing Bayesian Data Analysis で勉強した範囲の話だった。Figure 17.2 の説明がおかしいな、とおもったら誤植だったらしくウェブ版では直っている。

Gibbs Sampling は追加でもうちょっとなんか読んでもいい気がする。Wikipedia とか。ただ究極的には stochastic process のようなものを理解しないと internalize できないだろうな。

via The Human Fabric of the Facebook Pyramid – SHARE LAB

LinkedIn からデータひっこぬいてみたら Facebook 社員のその前の勤務先は Google がぶっちぎりで多かったよ、という話。そりゃそうだ。超近いし。給料も似たレンジだし。都会 (SF) に通いたくないけれど Google に飽きた社員にとって Facebook は福音に違いない。雇ってもらえる場合に限るけど。

むしろ Microsoft と Amazon のシアトル勢が二番手三番手なのがちょっと意外。ベイエリアにもオフィスあるけれど、そんなに大きくないよね。(As well as Facebook Seattle office もそんな大きくないよね。) となるとシアトルから来ているのでしょう。やはり転職する時は引っ越す覚悟がいるのだなあ。ベイエリアにくるにせよ、シアトルに行くにせよ・・・。

家買っちゃってる人ととかどうするんだろう。貸すのかな。引っ越した先でまた買うの？まじで？ガッツあるよな。

ところで文中のストリームの可視化はかっこいいけどミスリーディングだね。比率を伝えるにあたり、書くエントリーの間に余白があるせいでマイノリティーが実際より大きく見えてマジョリティーの比率が小さく見える。たとえば社員の勤務国、ぱっとみると US が 6 割くらいだけど余白を詰めたら実際は 8 割くらいじゃなかろうか。

Structured Probabilistic Models for Deep Learning.

いよいよサーベイみたいなかんじでささっと済ましてくるなあ。抽象的かつ概要的な話が多く雲をつかむような気分・・・。

Variational inference, D-separation, structure learning などなど新しくて難しい概念をバンバンつっこんでくるが全然 connecting dots されない。この先の章で使うらしいけれど、使われると死ぬ気がする。

最後にでてきた RBM は NN4ML でやったおかげでなんとなくわかった。

そろそろわからなくなりそうという不安を抱え続け、しかし概要的な話ばかりで決定的にわからない瞬間に出会わないまま 16 章も終了。いまいち張り合いがない。

RBM, 世の中ではほんとにつかってんのかなとライブラリを探したら sklearn に入っていた。がしかし、こういう切り口では使わないではなかろうか。もうちょっと stack とかしたいんじゃないの？全然 modularity ないよねこれ。

ちょっとぐぐると TF で RBM したよ、みたいなサンプルがちょこちょこある。そっちが正しいアプローチなきがする。自分で書いて、Optimization だけ TF に任せる的な。

Amazon’s New Customer | Hacker News

HN を見ていたら Ben Thompson のダメさについて合意が形成されつつあり頷く。なんでも Platform とか Operatin Systems とか言えばいいってもんじゃねえんだぞ！ Michael A. Cusumano と似たダメさ。検索会社についての話もまったく的外れだし、新しい記事が出てくるたびに読んではムカついていた（のでやがて読まなくなった）が、世の人々も同じことを思っていたようで良かった。コメント欄では「的外れなことを書いて意見を集めるという strategy なんだよ! なんだってー！」 みたいなコメントがあってウケた。そういうことにしとこう。

岡目八目もあるので単にインサイダーの意見が正しいとは思わないけれど、Giant tech companies にすごい緻密で遠大な roadmap がありそのゴールに向け着実に駒を進めているという陰謀論史観の滑稽さには複雑な思いがある。まあロマンとして信じたい気持ちはわかる。自分もそうした陰謀論的ファンタジーを信じたい願望が、特に Bezos と Jobs について湧き上がるのをしばしば抑えられない。でも世の中もっと iterative だし悪巧みを隠せるほど法制度もジャーナリズムも無能じゃないでしょ。とすぐ我に帰る。

なお陰謀論がどうであれ Amazon が最終的に世界征服するという bottom line それ自体には異論ないです。はい。

via Error Prone

Java の Lint ぽいやつ。割と簡単に plugin が書ける、らしい。

こういうので色々アプリ固有のチェックを書いていく世界に昔は憧れていたが、今の仕事をその段階まで持ってくのはちょっと頑張りが必要そうだなあ。

ランダムなマネージメントの話。マネージャはコードを書くべきか。

なおここでいうマネージャは Engineering Manager で、TL は他にいるものとする。この前提だと、conventional wisdom は「マネージャも重要なものはともかく少しはコードを書いた方がいい」くらいな気がする。

自分は個人的にはマネージャにはコードを書いてほしくない。全然。なぜならマネージャの書いたコードは扱いがめんどくさいから。そしてどうせならコード書き以外の面倒に時間を使ってほしいから。

例。あるとき上司の上司が crash bug の修正コードを書いてきた。普段はコードを書かないがプログラマ出身の人物。そのバグは当人が現役だった頃に使っていたのと同じライブラリのよくある問題に起因していた。その知識を活かして問題を特定し、修正を試みたのだった。

問題の特定まではよかった。でもコードをみると直し方がいまいち。コードベースの抽象やパターンに従わず、力技で片付けている。全体のデザインを正して似たような問題が起こらないようにするといった配慮がない。しかし通りすがりの上司の上司に正しいデザインのあり方を説明しコードを書きなおしてもらうなんてやりたくない。気を使うし、コードベースに対する理解の程もわからない。忙しい相手だけに素早いイテレーションも期待できない。ただバグを登録してくれるだけでよかったのに・・・。

うげーめんどくせーと顔をしかめる同僚たち。結局心臓の強い同僚の一人が容赦なくダメだししてパッチはお蔵入りとなり、その強心プログラマが自らマシな修正をした。チームメイトに同じことをしたら喧嘩になるところだけれど、この時に限っては正しい対応だったと思う。

上司のコードをレビューするのはそれなりに気を使う。相手がまともな人間でコードレビューに手こずったくらいでは気分を害さないくらいは期待していい。それでも自分にそう言い聞かせ権力構造から心を切り離さないといえないのは疲れる。

しかもマネージャには他に本業があり、結果としてコード書きの対応は遅れがち。一方でレビューは間隔があくほど認知の負担が上がるので、イテレーションの遅いレビューはそのぶん疲れる。普段コードを書いておらず共有するコンテクストが少ないのもコミュニケーションの敷居を上げる。

更に言うと、管理職は必ずしも良いプログラマではない。才能の優劣ではなく、下々のプログラマに比べて読み書きしている仕事コードの量が違う。頼れるチームメイトである度合いと言ったほうが良いかもしれない。片手間でコードをみているマネージャよりより、プロジェクトのコードベースに馴染んでいる現場のプログラマの方がよくコードをかけるのは当たり前。それが役割分担じゃん。

要するに: 権力を無視して正しく振る舞うのは疲れる。通りすがりの相手も疲れる。ぱっとしないコードを読むのも疲れる。だからコードはプログラマにまかせマネージャは本業に専念しておくれ、と思う。

Good First Bug

コードを書いては欲しくない。でもコードは書けて欲しい。少し理不尽な言い分だとは思う。でも現場に近いマネージャであるほど、下々が上司に巻き取って欲しい仕事にはコードを書けないと現実的でないものが多い。

例。とある夕方、翌日の UX レビュー会議で動くデモが必要とわかる。一応コードはあるものの、まだコードレビューがおわっておらずマージされてない。担当者はもう帰ってしまった。しかも明日の会議で必要なパッチは二つ。こいつらを手元でマージし、アプリをビルドしないといけない。

このとき職場に残っているプログラマにビルドの雑用を頼むのでなく、自分でささっとビルドできる・・・くらいはマネージャに期待したい。似たような場面はいくらでもある。

そしてちょっとした雑用にプロダクション以外の書捨てコードで自動化や分析ができると便利な場面は多い。そんな仕事に上司が手作業で時間を無駄にしてたら、ちょっと興醒めでしょ。

コードを書かないとコードを書けるようにはらなない。プログラマからマネージャに転身した身であっても、時がたてばコードやインフラは変化し、昔の知識は使えなくなってしまう。

そんなマネージャがプロジェクトのコードを学ぶためにコードを書く。これは必要なことだと思うし、現場のプログラマとしても協力してあげたい。コードそれ自体がプロジェクトの役に立たなくていい。たとえば優先度の低いしょぼいバグをなおすとか、あってもなくても大差ないちょっとした API を生やすとか、入門のためにかけるコードは色々ある。Open source でよくある good first bug というやつ。

マネージャが書くコードの面倒くささは、有用なコードをキメたつもりになっている本人と現実のギャップに起因することが多い。学びのためのコードにそうした勘違いはない。むしろちょっと応援したくなったりもする。

それに、マネージャが通りすがりで雑用をさばけないのはコードのデザインやインフラが腐っている兆候かもしれない。そうした歪みや技術的負債の痛みを体験したマネージャなら、負債返却や自動化強化を求めるチームからの声にも意味のある形で応えることができるだろう。

コードをめぐるプログラマとマネージャの関係は、そのくらいが円滑じゃないかな。

この文章はマネージャに向けたものではなく、自分とおなじそこらへんのプログラマを読み手として念頭においている。上司の書くいまいちなコードを見て複雑な気持ちな人に自分の感覚を信じて欲しい。下々のプログラマも声を出そう。これを読んだマネージャは一定の割合でムカついているとおもうけれども、そういう人は世に溢れるキリッとしたマネジメント語りを読んで元気だしてね。

via Stop Pretending You’re Not Rich - The New York Times

アメリカ、超格差社会な割に当人たちはいまいちその自覚がない、という話はよくみかける。この記事の人はイギリスから来て、おいおい実力主義とかお前らなに言ってんだよどう見ても階級社会だろ、イギリスの方が自覚的なだけマシだな、と書いている。

そういえば今年のはじめごろに white working class 研究として Audible した White Trash: The 400-Year Untold History of Class in America もある意味この系列の本だった。アメリカの poor white ってやつは奴隷と一緒で建国の瞬間から存在して脈々と生き続けているんだよ、という話。まあ upper middle class とpoor white の間には広い spectrum があるとは思うけれども、class の存在に無自覚なアメリカというテーマは共通している。

ふと見返すと、表題は misleading だね。金を持っていることが問題ではなく、それが class の力でありかつそれに無自覚なのが問題だ、といっているわけだから。まあ金の分布が偏ってる事自体も問題だと思うけれど。

Representation Learning

すっかり論文紹介といった風ではあるが、この章は面白かった。Deep Learning ぽい。Unsupervised Pretraining, Transfer Learning, Zero-shot learning, Distributed Representation, etc. ここでの議論にでてくるから事前に Autoencoder の章があったのか。あとは望ましい representation を learn させるための手法としてついにちらっと GAN が出てきて盛り上がるなど。

ただほんとに論文紹介なので、少しぐらいは読まないとなあという気がしてくる。特に zero-shot learning は話として面白いから少しはなんか読んでも良さそう。Google Translate の zero-shot training の話 はその仲間に数えていいのかなあ。ちらっと読むと、sequence の先頭にlanguage tag をつけたらあとはよろしく動いてくれたよ、とか書いてあるけどそんな単純な話じゃないよねたぶん。一方でざっとウェブを眺めるとだいぶ色々あってたじろく。

章の最後には「望ましい特徴量の性質」のようなものがリストされている。これはなんとなく「良いコードの性質」みたいな議論と似た雰囲気がある。素人としてはなるほどそうですか・・・とあまりピンとこないけど、経験を積んだ ML エンジニアは頷く感じなのだろうなー。頷く感じになれる日はいつか来るのだろうか。

ランダムなマネージメントの話 (Randomly On Management, ROM) つづき。カテゴリを振り分けることにしました。

自分の勤務先では、むかしマネージメントに関する調査プロジェクトをやっていた。Project Oxygen という名前。そのことをふとおもいだした。上の記事にある「調査でわかった良いマネージャの振る舞い」に、自分の上司は半分くらいは該当している。この記事によれば管理職向けトレーニングとかも社内でやってるというし、上司のまともさは人事な人たちの成果なのだろうか。

と思って、このあいだその上司に「そういえば Project Oxygen って知ってます？」と聞いてみたら「知らないなにそれ」という反応だった。ははは。まあそんなものだよな。トレーニングとかなしでも結構良いマネージャだという事実は別に悪い話でもないし。みくびってごめんなさい我が上司よ。

なお上の記事にでてくるマネージャフィードバック用のアンケートは今でも実施されており、結果をチームに共有のうえ議論するみたいなことも、少なくとも自分の上司はちゃんとやっている。ので Project Oxygen の名前は知らないにせよ間接的な恩恵はうけてるといえるかもしれない。

Autoencoders.

Denoising と Sparse はわかったが Stochastic というのがわからん。そして参考文献もない・・・。Contractive もいまいちわからん。そして難しい割に盛り上がらないなあ Autoencoder. 使いみちも今や可視化くらいしかないというし。まあ NN4ML にもでてきた Semantic Hashing は面白い気もする。実用的にどうこういうよりは、non-linear な dimensionality  reduction のわかりやすい例として教養として知っておきなさいね、ということなのかもしれない。

Keras のサイトにある autoencoder を作ろうという記事も、「最近は特に使いみちないけど授業によくでてくるせいで皆作りたがるからサンプル載せとくよ」みたいなことが書いてあって見も蓋もないのだった。

Part3 は詳しい中身には立ち入らず論文を紹介してくかんじになってきた。うーむ・・・。しかしぜんぶ理解しようと論文を読んでいるといつまでたっても読み終えられない。わからん、とかいいながら前に進みます。

via The Konami exodus - Nikkei Asian Review

Konami なかなかのブラックぶりだな。普通に不買運動とか起きそうな内容に思えるが・・・。はさておき、Nikkei.com 英語セクションは paywall ないのね。便利。

via ICML 2016 Tutorial on Deep Residual Networks

別のところで出て来たための調べ物。

[1512.03385] Deep Residual Learning for Image Recognition が論文本体。上のスライドがよくかけていた。ConvNet も深くしていくと段々辛くなってくるけれど、residual cconnection というある種の skip connection をつけてやると 100 layer 以上いけるようになるよ、という話らしい。深いレイヤでおこりがちな gradient の vanish/explode を線形の成分をまぜてやることで緩和するという点で LSTM に似ているという話がどこかに書いてあった、が、リンク失念。こういうわかりやすいアーキテクチャは心休まるな・・・。

https://pragprog.com/titles/category/audio_books

最近は audiobook もやってるらしい。今のところとくに聞きたいものはなく、しかも Audible じゃない audiobook ってどうやって聴けばいいのかわからないけれども、引き続きがんばってほしいものです。

via guru - GoDoc

Go で IDE-like な静的解析をやるツール。エディタの中から使う前提らしい。Refactoring はできないけど、それ以外はけっこうできるっぽい雰囲気。IDE と違って毎回クエリするけれど、Go のパースは速いのでいける、のだろうか。伝統的な意味での「モダンな」開発環境に対するアンチテーゼが徹底しててえらい。このペースだとそのうちリファクタリングもできるようになりそうだね。

ランダムなマネージメントのはなし。

今の勤務先以前の会社にいたマネージャというのは、いま自分や自分の勤務先がマネージャに期待している機能はほとんど果たしていなかった。テクニカルな度合いも低かった。一方で多くはステレオタイプな昼行灯みたいにヒマそうでもなかった。

自分の以前の勤務先は多かれ少なかれみな受託開発をしており、受託開発をするソフトウェア会社の管理職の主要な仕事は接客や渉外だった。そういた仕事はある種の専門性がいるし、時間もかかる。なのでこうした管理職はコードを全く書かないにも関わらずプレイングマネージャだったと言える。そして接客渉外に向いた人とソフトウェア開発のマネージャに向いた人は、必ずしも同じでない気がする。あれは色々不幸な仕事だったろうなと今更思う。

そういうプレイング管理職と働いた結果自分はマネージメントに期待をしなくなり、あまり manage されない働き方をするようになった気がする。なので結果としてはよかった。ただマネージメント軽視で arrogant な TL 的存在たる自分と一緒に仕事をしていた、自分のまわりの、場合によっては気の弱い人々は、もしかしたら本来的な意味でのマネージメントの介入があったらよかったかもしれない。なんつうか、ごめんね。

どうすればよかったのか。よくわからない。受託開発は大変、ということかもしれない。なお接客の影響からマネージメントへの期待値が低い会社で接客をしていないマネージャは、単にぱっとしなかった。

Kzys が管理職についてなんか書いていたので、自分も便乗して何か書こうかと思ったものの、その前に最近たまに考えていることを書いてみる: 下っ端でもマネージメントやリーダーシップについて思うことがあるなら書いたほうが良い。マネジメントの都合でなく、自分の都合でそれを語って良い。

自分と同世代の同業者は、マネージメントなりリーダーシップなりの仕事をやっている人が多い。そうでなければフリーランスやコンサルタント。特にインターネットの世界で名だたる有名人ほどこの傾向が強い。そうした人々はしばしば当事者としてマネージメント（以下字数節約のためにマネージメントとリーダーシップをひっくるめてマネージメントと呼ぶ）について色々かっこいい話をする。長年の経験や成果に裏付けらているだけあって説得力もある。

マネージメントをめぐる議論は、あるべき下っ端の姿を様々な形でほのめかす。なにしろ下っ端をマネッジしたりリードしたりするわけだから。つまりマネージメント語りはマネージメント当人(マネージャ、リーダー)についてだけでなく下っ端についても語っている。

下っ端も自分について語ることがある。けれど下っ端の語りにマネジメントへの意見がはっきりと現れることは少ない。多くは個人的な「生存戦略」みたいなものとして消化される。

結果として、マネージメントの意見は組織と個人双方に影響を与える一方で下っ端の意見は個人に影響することはあれ組織を動かす力がない。あっても弱い。

発言に影響力のある人がマネージメントに偏っているのもつらい。そういう人々の語りの中で定義される（組織にとって都合の良い）下っ端のあり方に影響をうける人は多いと思う。影響力がある人のかっこいい話を流されずに消化するのは正直けっこう難しい。かっこいいんだもの。

マネージメントと下っ端の都合が常に相反するわけではない。足並みを揃えられることは沢山ある。とはいえ下っ端も当事者として自分の望みを語らないと、他の都合が優先されてしまう。

政治と比べてみる。マネージメントだけが組織のあり方を議論している現状は、政治家や官僚だけが政治を議論しているのに似ている。政治家も官僚も国民すなわち下っ端（※言葉の綾です）のために働くことになっている。が、この前提は色々な圧力や思惑や誤解によって崩れがちだと多くの下っ端は信じている。だから activist や journalism が存在するし、政治に意見のある下っ端・・・というかふつうの市民・・・も多い。

下っ端会社員は必ずしも投票権を持っていないから、市民とはすこし違うかもしれない。一方で組織の execution に直接参加しているぶん、ふつうの市民が政治にもつより大きな影響力を持っている面もある。公務員みたいなかんじと言えなくもない。

国家公務員は内部告発の権利を保証されている。内部告発は政治の床屋談義はおろかふつうの journalism よりだいぶ覚悟がいる activism の極地だけれど、この法律は組織の姿勢を正す下っ端の存在意義をよく表しているとも思う。

下っ端プログラマがマネージメントについてなにか言うのは床屋談義に毛が生えたようなもので、極端な場合を別にすると国家公務員の内部告発みたいな覚悟は必要ない。マネージメントを悪者とみなす必要もない。ただ、それでも声をだした方が良い。音量のバランスがよくなるし、なにか悪いことが起きて本当に声を上げる必要があるときによく声が通る。たとえば Susan Fowler の記事は当人が勇敢かつ優れた書き手であっただけでなく、tech industry の sexism に関する年来の議論があったからこそ可能だった。

と、そんなに肩肘はらなくていい。幸い多くのプログラマは特段酷い目にあっているわけではない。概ね楽しくやってる。そういう平和な時分、仕事をより良いものにする上でどうしてほしいかを語ればいいだけの話。一定以上まっとうなマネージメントなら下っ端の声は聞きたいと思ってるよ。たぶんね。

Daniel Pink が Free Agent Nation を書いて 15 年。プログラマの中にはやっていき宣言みたいにロックなことを言う人もいて、ソフトウェア開発者をはじめとする知的ブルーカラーのあるべき生き方はこっちなのかな、と思うこともある。一方で会社に雇われて働くのはまだまだメインストリームだし、いいところも多い。

特にソフトウェア開発の世界では Agile manifest を発端に組織のなかでもボトムアップに個人を empower する流れが生まれた。その agile 世代にキャリアを踏み出し、個人として empower され成果をだした人々がいまマネージメントに舵を切っている。でも彼らはみな偉くなってしまったので、いま下っ端な個を応援する声はちょっと弱くなった気がする。カウンターがほしい。Erik Meijer の One Hacker Way はその extreme な例だとおもうけれども、もうちょっと穏当かつ持続的な切り口として下っ端のマネージメント語りがあってよいと思う。

追記

間を置きつつ断片的に書いているので ROM(Randomly On Management) というカテゴリに振り分けておくことにした。

Goodfellow Chapter 12 の復習。

まず [1] を読む。けっこうよくかけていたけれど、Encoder-Decoder の理解が怪しい気がしたため続けて [2] を読んだ。すると理解が怪しかったのは Neural Machine Translation や Statistical Machine Translation それ自体だったことに気づく。Phrase based SMT framework とかいわれてもわからん。しかし深入りするとキリがなさそうなので今は撤退。Encoder-Decoder に attention の context をつかうモデルについてはわかったのでよしとする。

ついでに Encoder-Decoder の同義語ぽくつかわれる Sequence-to-Sequence もチラ見しておこうと [3] を読んだ・・・が不親切すぎ！Deep LSTM ですかそうですか・・・というかんじだった。その点 [1] は Appendix にモデルが書き下してあってすばらしい。やはり企業の研究者よりアカデミアの方が論文さぼらなくてよいな。Bengio 先生はテックカンパニーとかに浮気せず世界のために丁寧な論文を書き続けて欲しいもんです。教科書も。

関連のある冷やかしでながめた Distill の [4] は attention の可視化がよかった。あと画像にも attention を使う話があると知った。

• [1] [1409.0473] Neural Machine Translation by Jointly Learning to Align and Translate
• [2] [1406.1078] Learning Phrase Representations using RNN Encoder-Decoder for Statistical Machine Translation
• [3] [1409.3215] Sequence to Sequence Learning with Neural Networks
• [4] Attention and Augmented Recurrent Neural Networks

Attention という仕組みの素人感想。

Encoder-Decoder の自然な拡張に見える。というかもともと Encoder-Decoder が variable length の text を fixed dimension の vector に畳み込むという無茶をしていたわけで、無茶すぎたのをちょっと反省したらこうなったみたいなかんじ。ただ attention の割り振りを学習できるという発見はよい。この「パラメタは何でも学習しちゃおうぜ」という態度をネイティブに理解したいもんです。

Google Wifi – Made by Google

買った。二台。

今までは living room に設置したモデム付属の Wifi を使っていた。本来はそれで間に合う敷地面積のアパートなのだが、壁の位置などがわるいらしく電波を拾えない部屋があった。一度は extender を買ってみたもののいまいち。来月数日ゆこっぷ（おくさん）の WFH が予定されているため、環境整理として買うことにした。

電波の入らなかった bedroom に二台目を設置し、電波の問題は解決。その他としては:

• 設定をアプリでできるのは、便利。Bluetooth 越しに色々やるおかげでブラウザで奇妙なURL につなぐみたいな苦労がない。認証にはデバイスに貼り付けられた QR コードを使う。
• 時間を決めてオフラインにできる機能がある。便利！と一瞬おもったけれど cellular data を切断できるわけじゃないから断線効果は低いな。
• Guest Wifi の機能がある。追加で ephemeral な access point  を定義できるようなもの？まあ便利かもしれない。

まあしかし、高いね。三台買うと割引があるのだけれど、二台は一番割高に感じる。Google Home とか Nest とかのおまけ機能として入ってればお得感あるんだけどなー。

Linear Factor Models.

突然難しくなった...

PCA みたいに feature extraction をするモデルのうち linear なものたちとして Independent Component Analysis, Slow Feature Analysis, Sparse Coding を紹介する。わからん。ICA は [1404.2986] A Tutorial on Independent Component Analysis でそもそもどういう話なのかを学び、ML 的文脈での解釈は Ng 師匠の notes で理解(師事してません)。 Sparse Coding は全然わからんけれど、あまり流行ってないといことなのでサボって無視。

こういう unsupervised な feature extraction はある種の generative model と解釈することができる。なぜなら extract した feature を model が想定する probability distribution から draw した sample で重み付けして足し合わせれば data を generate できるから。

こうした素朴(=Linear)な generative モデルから話を始めつつ、だんだんと洗練された手法へと話を進め、最終的には GAN にたどり着ける！はずだ！と信じて、わからないなりに読み進めてる。しかし先行きだいぶ不安。

なお ICA は sk-learn に実装が入っており、普通に便利げ。

きのう WWDC の中継をみながら野次馬 Twitter をするなか、最速を名乗る Safari の参照ベンチマークがぜんぶ自家製であるという野次 tweet としたら翌朝おもったより retweet されてしまい、居心地が悪くなって削除した。

自分は unlearning のためブラウザのニュースはなるべく読まないことにしており、件のベンチマークの中身がどんなものかまったく知らない。調べる気もない。そんな無関心なものについて知ったような顔で何かいうのはよくない。それ以前に同業他社の仕事についてとやかくいうのは品がない。こういう発言をすることに慣れてしまうと自分の sincerity を損なう気がする。HomePod くらい自分の素人ぶりが自明なものに雑な発言をするのには、大して心も傷まないのだけれど。

ベンチマークを作るのは報われない仕事だ。安定して意味のあるベンチマークを書くのは難しい。にもかかわらずそれ自体で何かが速くなるわけでもないし、速くできる確証があるわけでもない。的外れだったり出来がわるかったりすると誰からも相手にされず技術的負債にすらなる。出来がよかったらよかったで、競合がガンガンチューンしてきて負けてしまうリスクもある。

それでもベンチマークを書くのは、遅いものを知っていて、速くしたい意思があるからだ。なので特にブラウザのベンチマークというのは誠実なものが多い。

だからベンチマークを書いた事実を揶揄してしまうとプログラマとしての精神性が損なわれてしまうな・・・・と反省した。

Chapter 11 は Practical Methodology. Hyperparameter のチューニングからデバッグまで、短いし math もないけど良い章だった。ここに載ってるデバッグ手法を使いこなせるようになりたいもんです。

ただデバッグして hyperparameter tuning してそれでも結果が出なかったら practitioner にできることはありませんそこからは researcher の仕事です、みたいな言い分にやや萎える。わかってんだけどさー。

Chapter 12 は Applications. GPU, 分散処理,  画像処理, 自然言語処理, Recommendation....って盛り込み過ぎ. 書くトピックごとにどんな成果がでているかを紹介しつつ論文のリンクだけあるかんじ. 特に自然言語処理の章は全然わからんかった. 著者が他と違うんじゃね, という気がする. 知りたかったの attention mechanism についても結局よくわからなかったので要復習.

これで Part 2. Deep Networks: Modern Practices が終わった。もともとはここで切り上げる予定だったけれど、Part 3 も読みたくなってきたなあ。NN4ML のときにつまみ読みした感じだと math が難しすぎて挫折しそうだけれども、自分のわかってない限界を知るために読んでおきたい. くじけたら終了ということで.

引き続き読書に時間を割くということは、TensorFlow とかで実際にコードを書くのはまたしばらく（数カ月）お預けということでもある. ここで両方できない現状にはまったくがっかりする. でもそれが現実なのだった. Sigh. でもなんとなく続きを読んだほうがいい気がしているのです.

... The world is depending on you - WWDC 2017 キーノート冒頭のビデオより。

これ、いいよな。開発者はこう言って欲しいと思う。Apple は言って欲しいことを言ってくれたし、プラットホームのアップデートも発言と足並みを揃えている。一方の Google I/O は Mobile First から AI First を謳っていたけれども、それは開発者の聞きたいことだったのだろうか。AI はオレらがやっとくからみんな安心してアプリ作ってくれよな、という今回の WWDC のメッセージの方にプラットホームとしての確からしさを感じてしまう。

一方で正味なはなしアプリとか作ってる場合なのか、という疑問はある。というか、アプリとかつくってる場合じゃないというのが世間の空気だと思うのだよな。そんなとき「次は AI だからみんな AI やろうぜ」と「世間は色々いってるけど心配いらないよ」では、どちらが適切な宣言か。

株主に対するメッセージとしては前者が望ましい。だから今日 APPL の株価は下がった。けれど WWDC 参加者に伝えるべきメッセージは後者だと思う。世間の風向きがどうであれ、彼らはもう Keep Creating Apps と決断して WWDC に来てるわけだから。メディア相手に取り繕うことをせず開発者に語りかけた今日の Apple は、ちょっとかっこよかったね。

I/O で発表された Android の Architecture Components. サポートライブラリの一味。ベストプラクティスを支援するためのライブラリらしい。

サブモジュールは四つ。Lifecycle, Live Data, ViewModel, Room ORM. ドキュメントなどを読んでみた今のところの自分の結論は: Lifecycle 以外いらない。

Lifecycle

今まで Android は Activity の lifecycle を外部から listen する良い方法がなく、開発者はみなそれぞれ Activity を継承してアドホックに(あるいはオレオレライブラリとして) lifecycle をフックしていた。ActivityLifecycleCallbacks というのがあるにはあるのだけれどこれはグローバルなフックなので大げさすぎた。初期の RxAndroid も、このせいで Activity の lifecycle のための Observable を提供する方法に合意がとれずに終わった。

Lifecycle モジュールはそのフックを提供する。そして Lifecycle をコールバックする Activity および Fragment の base class も用意している。API が安定したら support library の base class に直接同じ機能を入れる予定という。

このレイヤはしょうじき出来の良し悪しは割とどうでもよく、誰かが方法を決めて皆がそれに従うのが重要。なので support library がそれをやってくれるのは良いと思う。

Activity を継承しないと lifecycle がフックできないとかほんとにクソだなと誰もが思っていたのに今まで何もしてこなかったのはひどい話だと思うけど、Better late than never ではある。OSS の世界に複数の方法が乱立して辛くなる前だったのはよかった。

LiveData

RxJava 的なもののしょぼい再実装。既存の実装と比べて唯一の利点は Lifecycle aware なことだけれど、Lifecycle API が定義された今なら既存のライブラリたちを Lifecycle aware にするのは簡単なので、別に再実装しなくてよくね、と思う。

Support Library のような "official" なサードパーティライブラリしか使えない辛い立場の人にとっては better than nothing かもしれないけれど、どうせなら既存の出来の良いライブラリを endorse してほしかった。

ViewModel

使う必要なし、というかこれが best practice という点にまったく同意できないので積極的に避けていきたいかんじ。なお世間が MVVM の文脈で ViewModel と呼ぶものとは若干違うと思う。

Room Persistence Library

世の中もう ORM は足りてると思うのだがなぜまた作ったのだろうな・・・。

Lifecycle を別にすると既存のオープンソースのライブラリたちと比べて特に出来が良い様子もなく、そもそもコードが公開されておらず(support library の流儀を考えるとそのうち AOSP の一部として公開されるだろうけれど)、なんなのだろうな・・・。あなたたちに今更でてきてアーキテクチャどうこういわれる筋合いないですよ、と思う人が多いのではなかろうか。

コミュニティベースの Android 系カンファレンスではここ数年アーキテクチャや保守性に関する話題が延々と議論され、それなりに合意が生まれライブラリとかも揃ってきた。一方 Google I/O の Android 関連の talk はこれまで新機能や性能の話ばかりで開発者の生産性やコードの保守性に関する議論はなかった。Android は本体のコードもあんなだし参考実装を名乗る例年の I/O アプリも割とべったりした実装。少なくともアプリレベルのアーキテクチャやコードの品質についてはコミュニティからの credibility がないと思う。それを突然でてきてエラそうな顔されてもね・・・。

やっぱり Lifecycle だけ作ってあとはコミュニティを endorse したり support する方が良いのではないかなあ。

先週は結局風邪で2日休んだ。喉がやられた結果、今週も全快はしていない。

自分の一日の timetable は、こうした体調不全や突発的な用事に弱い気がする。逆に、予定外にできた時間を使うのもうまくない。時間がないときは低空飛行を続け、体調などの回復にあわせ高度を上げ、隙あらば加速して距離を稼ぐという柔軟性はどうすれば手に入るのだろう。

まずはなにをどの順番で drop するのかを考える必要がありそう。逆にすきあらばやることを整理しておくのも良いかもしれない。思わず生まれた時間をうっかりインターネッツに捨ててしまい、いつも悲しい思いをしている。

via Fringe Groups Revel as Protests Turn Violent - The New York Times

この記事を読むなどで知ったけれど、4 月に Berkeley で Ann Coulter という conservative activist の speech が cancelled になった事件は Antifa (Anti-fascists) という左翼の過激派団体の仕業だったのだな。Alt-right のろくでもなさは広く知られているけれども、こういう alt-left (?) がいなくならない限り燃料には事欠かなそう。

同じく Berkeley で 3 月にあった Pro-Trump の集会にもこの Antifa は殴り込んで問題を起こしており、その喧嘩に乗り込んでいった conservative おっさんの有志が social media で盛り上がり Based stickman (Know-Your-Meme, Image search) という翼賛的 meme が生まれたという。そしてこの stickman 氏はその後 alt-right 過激派若者ギャング団体で自分の subgroup を持つことになったそうな。

California もあんまし平和じゃないなあ...

母親から Google アカウントのパスワードが誰かに破られた（が、Google が謎の方法で阻止した）というメールがきた。パスワードを変えてねと伝える。

パスワードが破られるのはどこかで漏れたパスワードが共通だったかありがちな単語を使っていたか。いずれにせよパスワードマネージャを使ったほうがいいのだが、何を薦めたものかなあ。母親は iPhone + Windows ユーザなのでとりあえず 1Password を勧めておいたが、わかりやすいオフィシャルな日本語解説が見当たらない。不安。こういうとき、ちょっと行って見てあげられないのは心苦しい。

Google にもいつの間にか passwords.google.com という Chrome の autofill をサービス化したものができており、国際化などを考えるとこれが iPhone で使えればいいのに、だめっぽい。Keychain インテグレーションとかなくていいから、とりあえず簡単なアプリくらい作ってくれよ・・・。

まあいずれにせよ人間が覚えるパスワードを Google のものにするのもやや不安。メールアドレスと紐付いているし、でかいせいで狙われやすいから。破られても謎の方法で阻止してくれるのはいい話だけれども。

via Node.js 8: util.promisify()

こういうのは JS のような動的型づけ言語の便利なところだよな。Internal symbol でカスタマイズできるのもよい。

TypeScript でもサポートして欲しいというけれど、なかなかむずかしそう。Promisify を実装できるくらい強力な型システムを持った言語はどれだけあるだろうか。マクロとかがあればいけそうだが・・・すなわち Rust とか Kotlin はいけるのかな？気になるところ。

Press This 機能を使う実験中。なんとなく細々しすぎる気もする。まああとで考えます。

via The young Japanese working themselves to death - BBC News

BBC, 日本のつらい話が妙に好きだよねいつもながら・・・。特にあたらしい話はなし。

労働時間比較@OECD. これを引き合いに出すと日本のひとはよく「正しい数字が申告されるわけない」というが、他の国の人が日本と比べて正しいとなぜ思うのか。どんな国でも弱者はわりかし搾取されてんじゃね? 資本家のがめつさを侮るなかれ。そしてこの表をみるたびいつも韓国やばいなと思う。

BBC の記者がこれを cultural matter にしたがるのが、アメリカ脳に染まった身には面白い。単に class inequality と capitalism による abuse とみなすと色々わかりやすいとおもうんだけど。もちろん人気のある大企業で Karoshi がおきてるのは興味ふかい現象ではあれどそれは意外性ゆえニュースになるのであって、学歴などをもたない未熟練労働者はふつうに酷使されてバタバタ死んでいるのではなかろうか・・・。

むしろ本来は資本階級に近いエリートですら Karoshi から逃れられないリスクがあるのだとしたらそれは案外フェアかもしれず、社会が人生の well-being を真面目に考えるのを促すいい話なのかもしれない。だからこそ cultural phenomenon とかいわず class warefare に持ってく方が戦う気がおきるとおもうんだけど。Cultural な問題ってなかなか直せないじゃん。とか Edger H. Shein 読者としては思ってしまうのだった。まあイギリス人的には他人事なのだろうな。

Instapaper, Android 版で記事によっては全く何も表示しないエラーがけっこうな頻度で起こるのに嫌気が差し Pocket に乗り換えてみる。

Pocket よいところ:

• Google アカウントでログインできる。Android では特に便利。
• 今のところ表示壊れがおきていない。

Pocket いまいちなところ:

• Pagination ができない。一方で Instapaper for Android の不安定さもpagination 起因な気がしているのでまあこれは仕方ないともいえる。
• Font の選択肢がすくない。そもそも aesthetic が理由で使うアプリなんだからもうちょっとがんばってくれや。
• Android 版でリンクをクリックした時の挙動がなぞ。ふつうにブラウザ開いてください。
• Chrome extension が New Tab Page にゴミを突っ込んでくる。死ね。(死ね、と遠回しに書いたフィードバックを送り済み)

などといいつつしばらく使います。

Pinboard に売られた！！！

Pinterest じゃないよ Pinboard だよ? Indie Web ですよ? 企業というよりほとんど個人だよ? 一体いくらだったんだ。 $1000 くらいじゃないのか? は冗談ですが、一桁多いくらいじゃね? $1M だったら絶対買わないよね。(追記: $35,000 だったらしい。まあまああってた。)

Del.icio.us は青春の一部なので、何かの弾みで可愛いサイトに生まれ変わってないかと年に一回くらい見てたけれど、どんどん転売されゴミ化をつづけていた。が、最後になんとなく救われた気分。成仏しておくれ。

最後の一文 "Do not attempt to compete with Pinboard." がウケる。なお自分はとっくの昔に Pinboard に乗り換え済みで慎ましい日々を過ごしております。

自分は「はてなブックマーク」は色々なレイヤで嫌いだけれど、彼らがビジネスとして一定程度成功したのは偉いとおもう。Reddit みたいに Internet のサブカル top page でありつつ、引き続き個人にブックマーク機能を提供しつづけているのはえらい。

オフィスができて求人してる。

このあいだ買い物で近所をとおったときに駅前のビルが看板をだしており、あれこんなところにあるの？と思ったところ最近できたらしい。特にできそうな仕事ないので関係ないんだけど、なんでまた Mountain View なんだろうね。既に San Francisco オフィスあるじゃん？家賃が若干マシという判断なのだろうか。なぞ。

よくみると Android の求人あるね。1, 2, 3. サーバ側の求人と比べた qualification のザルさが Atlassian の強み弱みをよく表してるとおもう。

オフィス新設とかでガバっと求人するタイミングは入りやすいものなのだが、そこで勢い余ってうっかり動けないのが妻子持ちボンクラ大企業会社員なのだった。