Hacker News いまいちという話題は定期的にでてくる。自分も最近そう思うことが増えた。なおこれは単純に HN のダメさだけでなく例のごとく自分のソーシャルメディアリテラシの低さでもある点は先に断っておく。

だめさの一つはテックゴシップ比率の多さ。ゴシップ、目に入るとつい読んでしまうけれど人生における有用性の低さは Yahoo Topics と大差ない。というか業界内輪ネタなのであるいみで一層役に立たない。(なお自分は Yahoo Topics は読んでないので濡れ衣かもしれない。むかしだったらワイドーショー的というかんじかな。適当な比喩が思い当たらない。) 自分の勤務先はよくゴシップの対象になる。そこで心ない根拠もない誹謗中傷コメントを読むのも精神衛生によくない。

総花的たる裏返しで、自分の興味あるニッチがいまいちカバーされない。仕方ないとわかってはいるけれど。

ダメさその 2 はコメント欄。たまに当事者が出てきたりして面白いのだけれど、オフトピックだったり脊髄反射だったりするものが大半。自分はまずコメントを眺めて記事本文を読むかどうか決めることが多かったのだけれど、どうも機能していない。脊髄反射もオフトピックも純粋な暇つぶしとしては機能してしまうためつい読んでしまうが、時間の無駄感を禁じえない。そして稀にすごく面白いコメントがあるため、スロットマシン効果が依存性をつくりだしている。自分はもともとコメントは一切読まなかったため困らなかったのだけれど、いつの間にかずぶずぶと時間を潰している。やばい。

コンテンツの総花化もコメントの脊髄反射化も、ソーシャルメディアがたどる一般的なライフサイクルではある。かつて Paul Graham 信者が集う掲示板に過ぎなかった頃はよくも悪くもはっきりしたバイアスがあり、個性につながっていた。それが今や新聞記事からちょくちょく参照される有様。

しかもメディアが本業ではないせいでスケールする気がなく、本来ならもうちょっと頑張れるところで頑張っていない。長大なスレッドの奥服描くに眠る面白コメントやトップページにでてこない面白記事、ぜったい見逃してると思うんだよなあ。

なのである時期から Hacker Newsletter や The Macro のようなプロキシを使うようになった。そして The Macro はいつの間にか終了していた・・・。

あとは Reddit や Datatau とかのニッチも冷やかしている。Reddit はジャンル別のおかげでゴシップ比率が低いのと、コメントが完全にゴミなおかげで全く読む気がおきないところがよい。

しかし書きながらほんとネット依存がひどいな我ながら、と思いました・・・読まなくていいのはわかってるんだよ・・・。

Neural Networks の実装はなぜか軒並み CUDA を使っている。自分も数日前から CUDA の入門書を読みはじめた。以前 OpenCL の入門書を読んだことがあるのだけれど、GPGPU へのアプローチにどんな違いがあるのか興味が湧いたため。

そんな矢先、AMD が GPGPU 用のカード Radeon Instinct をリリースしたというニュースがあった。彼らが提供するプログラマ向けのプラットホームは Radeon Open Compute Platform (ROCm) と銘打たれ GitHub に置かれている。色々なツールがあるけれど、主要なコンポーネントは HCC というコンパイラらしい。このコンパイラから使える API は数年前に Microsoft が発表した C++ AMP と互換だそうな。

C++AMP や HPP のサンプルコードを眺めてみると、ホストのコードと GPU でうごくカーネルのコードがわかれていない。これは CUDA も同じ。OpenCL ではカーネルを別のファイルに定義し、そのカーネルからコンパイルしたバイナリを OpenCL のホスト API でロードし GPU に送る、みたいな荒々しい API だった。C++ AMP だと C++ の lambda を専用のアルゴリズム関数(並列 for みたいなやつら)に渡すだけ。あとはツールチェインがよろしくやってくれる。こりゃいいわ。

CUDA は C++ ではなく C なので若干切り口は違うけれども、やはりホストとカーネルが混在できる。このアプローチだと GPU 業者はコンパイラをまるごと提供する必要がある。ROCm は Clang を使っている。ROCm にしろ CUDA の NVCC にしろ、基本的には ホスト/カーネル混在のコードをCPU 用のコンパイラに渡す前で前処理し、カーネル部分だけ自分でコンパイルするかんじらしい。これは OpenCL よりだいぶいい。特に C++AMP の lambda を使えるところ。未来っぽい。

CUDA は今の所 lambda は使えないけれど、対応は時間の問題に見える。CUDA 自体は C API ながら NVCC は C++ も扱え、NVIDIA 自身 Thrust という CUDA 向け C++ ライブラリを提供している。

なお NN まわりでの CUDA の普及は CUDA それ自体の良さだけでなく、NVIDIA 謹製の cuDNN なるライブラリが職人的チューニングですごい速く、みなこれを使っているからという面もあるそうな。NVIDIA がんばった。積み重ねを感じる。OpenCL を勉強している場合じゃなかった。

自分はそこそこ自律的に仕事をしやすい職場にいるとおもう。とはいえ完全に好き勝手できるわけではなく、所属しているチームや製品の方向性や自分の身の丈にあった仕事を考えないといけない。チーム内での地位やカルマの溜まり具合も関係がある。何事にも不確実性はある。不確実性に伴うリスクがどれだけとれるかはその人の実績で決まる。このフェアさは妥当だと思う。そのほか上司のマイクロマネッジ指数やチームの性格、部門の景気なども仕事の自律性に影響を与える。これらはフェアネスよりも運の部類。

自分はまあまあ運が良い気がする。今のところ割と勝手なことを勝手なペースでやっている。一方で自分のプロジェクトを誰かに手伝ってもらえる実績や ambition もない。結果として一人で自分のプロジェクトを進めることになりがち。アーキテクチャを刷新してぜんぶ倍速くしますみたいなアイデアと実力があればチームをリードすることもあるだろうけれど、残念ながら特にアイデアはない。実行可能なアイデアの不在は自分の実力のほどを表しているとおもう。

だから自分にとって、やることを決めて仕事をするのは一人プロジェクトと対になっている。一人プロジェクトにはチームをリードしてなんかやる的なかっこよさはない。一方でよいところもある。人々と協調しなくていいぶん締切や設計を柔軟に変えられる。他人の仕事を止めるわけにはいかないから間に合わせなければ...といった気苦労がない。前もって慎重に決めた API にコミットする必要もない。

End-to-End でぜんぶコードを書く満足感もある。システムの全体像を見通し、その理解をもとに物事を判断できるのはいい。正しい感じがする。サーバとクライアントでチームや担当者を分けるのが前時代的だという指摘がされてから随分たつけれど、ようやく身を持ってそれを理解できた。

待たされる

一人プロジェクトに特有の欠点や苦労もある。

一人プロジェクトとはいえ、チームや関係各位にはそこそこ世話になる。典型的にはコードレビューを頼まないといけない。それらの人々にとって、自分の一人プロジェクトは割とどうでもいい。同じプロジェクトのメンバー同士なら互いに依存があるから協力しあう動機がある。一人プロジェクトは依存が一方的だから、レビュアには善意と責任感以上の動機がない。だから彼らの本業が忙しいと一人プロジェクトは後回しにされがち。道理にかなった判断とはいえ、あまり放置されても仕事が進まず困る。

誰かの仕事をブロックする心配がない一方で他の人には始終ブロックされるのが一人プロジェクトのつらいところ。催促は嫌われない程度にしつこくするとして、他になにができるだろう。

ブロックされる一般の仕事の進め方は大きく二つある。一つは並列度をあげること。並列にできる作業をいくつか持っておき、一つがブロックしたら別の作業を進める。もうひとつは投機すること。レビューを待たず作業を進める。レビューの結果コードが変わったら、先に進めておいたコードもあわせて直す。ただ並列に進められることにも限度があるし、投機的なコードを書くにも根性がいる。レビューの結果次第でまるごと無駄になることもあるから。自分はどちらもさほどうまくない。

並列してやる作業の候補としてチーム全体の仕事を手伝うのは手だと思う。担当が決まってない地味で退屈なバグをなおすとか、コードを書く手前でバグのトリアージを手伝うとか。コードレビューをするのもいい。一人で仕事をしているとチームとの結束が薄れがちなので、待ち時間は利他的に使うと割りきり雑用を引き取るとなんとなく絆が深まる。待たされているレビュアが TL などの忙しい人なら、その人の仕事のうち一部を引きとってみてもいい。

こういうボランティア精神をいつも発揮できるといいんだけれど、実際にはなんとかブロックを回避して本業を進められないかとあがいて時間を無駄にしがち。モラルが足りてない。

ふらつく

一人プロジェクトは方向性が揺らぎがちでもある。これは自分の性格や未熟さかもしれない。決めたゴールの正しさへの確信がふと消えてなくなる。正しく定義したつもりのゴールが曖昧だったと気付く。あるいは期待するほど成果がなさそうとわかる。ゴールを決めるための探索的な作業にずるずると時間を使い、ミイラとりのミイラになることもある。

大きな不確定要素から片付けていく。手応えを確かめながらインクリメンタルに進む。不確かさを相手取る仕事の進め方はよく議論された話題なので特に新しく言いたいことはない。ただ実際にやってみると不確かさからくる不安や動揺は思ったより大きい。他人の仕事を手伝ってばかりだった自分の肝の座らなさにがっかりする。これまで他人に押し付けてきた不確かさが自分のものになる戸惑い。

ブロックしがちな作業と見失いがちなゴール。その圧力を前によく手が止まる。もやもやしたまま何日も無駄にしてしまう。締め切り不在の油断が事態を悪くする。こんなに好き勝手できるのにこんなに仕事がはかどらないなんて、かつては思いもしなかった。仕事中、何をするかを考える時間が増えた。一人プロジェクトのおかげでミーティングはほとんどない。けれど計画や提案をスケッチしたり直近の進捗を眺めて予定を見直すなど、結構な時間をコードを書く手前で使っている。

傍目からはさぼっているみたいに見えまいかと不安になる。コードのコミットの数だけを数えたら誰かに待たされながらバグを直している間のほうがよっぽど順調。ふらついている時間を待たされている時間にかぶせられるよう、試行錯誤のアイデアを備忘録へ蓄えるようになった。

自分でやることを決めて、自分で仕事を進めて、製品がよくなって、上司もチームも自分もハッピー。そんな理想までの距離は遠い。ただ追いかけるには悪くない理想だと思って今のところ続けている。少し肩身が狭い。何しましょうかとボスに尋ねればいくらでも仕事があることはわかっている。でもその日はまだ先延ばしにしておく。かすかな雇用への不安も、先延ばしにしておく。

仕事の内容を自分で決めるのが、今のチームに引っ越してからの個人的な目標の一つだった。現状を記録しておきたい。

チームに入った当初、同僚からは二つの入門プロジェクトを提案された。ひとつはある種のキャッシュを実装するというもので、もうひとつは・・・わすれた。この段階では右も左もわからずやりたいこともない。とりあえずキャッシュ実装のプロジェクトをやってみることにした。

引き受けたは良いけれど仕事の全体像がわからない。そのキャッシュとやらをいれると何がどれくらい速くなるのか。そこでコードを読んだり、プロファイラを眺めたり、性能測定用の instrumentation を足したりした。調査によって段々と様子がわかってきた。まず、件のキャッシュがもたらす性能への影響は、あるにはあるが大したことはない。他にも色々遅いところがある。なのでキャッシュの仕事は適当にすませ、その他の遅いところを順々に直していくことにした。遅いところは細々たくさんあったので、修正にはけっこう時間がかかった。まだ完全に直し切れてもいない。ただ結果として「どこを速くするか」すなわち「やること」を自分で決めることにはなった。

性能周辺のインフラ、というと大げさだけど調査の仕組みも揃えていくことにした。まず Systrace ベースのユーティリティを書き、最初に足した logcat 依存の雑な instrumentation を置き換えた。そして自分が速くしたいシナリオで通るコードパスにトレースを足し、レイテンシの内訳をぱっと目で見られるようにした。

Systrace の結果を見せるとコードからは自明でない高速化の成果が一目でわかるようになるため、調査のみならずコードレビューが楽になった。そのほかベンチマークの自動化や性能測定向けデバッグオプションの追加など、細々と仕事のやりやすさを積み増した。

ユーザの手元で実際に速くなっているのかを確認するため、分析用のシステムにデータを送るコードも足した・・・というか既にそういうコードはあったので、自分に必要なイベントを追加した。

歴史的経緯から、自分のチームはこの目的にもっぱら Google Analytics を使っている。ところが Google Analytics のダッシュボードで見える性能の指標のうち説明のつかない値を示しているものがある。自分の高速化の成果もいまいちわからない。困った。

あるとき Google Analytics のデータを BigQuery にダンプできることを知り、試しにダンプしてヒストグラムを書いてみた。するとごく少数の outlier がダッシュボードに表示されている指標・・・すなわち平均値・・・を台無しにしていることがわかった。50 percentile をみると自分の期待した値になっている。

BigQuery を通じて GA の値が正しく読めるようになり、仕事の成果をアピールしやすくなった。SQL と Pandas の練習も兼ね、そのあとしばらくは BigQuery をつかった性能指標の分析に時間を割いた。おかげでいくつか新しいプロジェクトのアイデアも思いついたけれど、まだ実施には至っていない。ミーティングでグラフを見せるなどもした。

当初はある単一シナリオの性能改善に注力してきたものの、low hanging fruits の収穫がおわってしまった。残りを搾り取るために大きな変更をしてもいいけれど、むしろ他のシナリオを速くした方がよくないかと思い立つ。そこで目につく遅さから候補リストを書き出してチームにシェアしたところ、いくつか反応があった。なかでもボスの提案が的を射ていた: それまで見てきたオフラインでの性能ではなくネットワークの絡むところを速くするのはどうかという。仕事でさわっているアプリは世間の平均よりもだいぶオフライン寄りなのだけれど、それでもネットワークの絡むところはある。そして測ってみるとたしかに遅い。頻度はすくないもののユーザ体験の良し悪しに響く部分でもある。

といった経緯から、そのネットワークありシナリオの高速化を次の大きなゴールとすることにした。まずは適当にプリフェッチでもするか...とデザインの資料を書いて回覧したら、TL から思わぬ反応があった: ボトルネックにある遅い API コールがなぜそんなに遅いのか、サーバのチームに聞いてみてはどうか。そこで同じ資料をもとにサーバの人々と話をしたところ、プリフェッチもいいけどまずは API を速くした方がよくね？という。

速くしろっていうけどそれあなたたちのコードですよね…と思ったものの、サーバサイドのコードをさわるいい機会にも思えた。そこで教えを請いつついろいろ調べると、アプリとサーバの双方で少しずつ工夫すればレイテンシを減らせそうだとわかった。なのでそのまま教えを請う日々を続け、サーバのコードに変更を入れた。コードベースへの不慣れとなかなかのレガシーぶりに気圧され、作業にはおもったよりずっと時間がかかった。けれどなんとかリリースできた。

サーバサイドで使われている社内の奇妙なインフラに触れる機会ができたのはよかった。フロントエンドとバックエンド二つのサーバをさわる羽目になったおかげでシステム全体の見通しもよくなった。

そうしたプロジェクトとは別に、ある時期から性能関係のバグがぼちぼち回されてくるようになった。性能系ツールの使い方の相談もうけるようになった。チーム内での存在感に不安がある身なので、何らかの役回りが認知されつつあるとわかって安心する。最近は速度だけでなく、そのほかの性能上の指標も良くしたいと試行錯誤している。

1年半たった割には大した仕事をしてない。残念ではあるけれど、「自分のやることを自分できめる」という目標自体はまあまあ達成されていると思う。持ち回りの義務的なやつを除けば、いまのところ上司からあれをやれと指示されたことはない。

節目ごとに意見を聞き、チームやボスの意向を織り込んではいる。だから純粋に自分の意思とはいえない。ただ最終的になにをやるかは自分で決めている。プロジェクトの価値を完全に内面化できる。おかげで仕事への納得度が高い。ボスに乗せられているだけという可能性は否定しないけれど、そういうファンタジーは気分の良さに繋がるので気にせず踊ればいいと思う。

他の人のやりたいことを手伝う仕事は、プロジェクトの価値を必ずしも腑に落としきれない。ビジョンや方針に異論があるわけではない。ただ価値判断の根元が自分の中にないのでいつも方針に迷いがあり、自信を持てない。どこか責任も持ちきれない。自分で決めるとそんな歯がゆさがない。たとえそれがファンタジーでもね。

「速くする」というゴールはかなり単純でわかりやすい部類だと思う。ユーザに見える機能を自分で考えて作るとしたら、ただ速くするよりだいぶ解空間が広く難しそうに見える。製品開発のキャリアが長い人ならそれもうまくできるのだろう。そうした経験を持つ人と自分のギャップを埋められるとは思わない。ユーザの欲する機能を考えて作るのは、それはそれで長い道のりだとおもうから。

エンジニアリング専業に近い仕事をしてきた自分が考える仕事がユーザ視点の専門家と違ったものになるのは自然だと思うし、そこに何らかの価値があるならそれでいいと思っている。

かつてひげぽんは「妥協して Evernote を受け入れよ」と言った。慧眼。

自分はその教えに従っていたが、諸事情によって受け入れられなくなってしまった。ただ同じ精神があてはまるものは他にもある気がする。たとえば Google Docs. 自分の中で Google Docs は MS Word を Web に持っていっただけの何一つ面白みのないソフトウェアに位置付けられている。Wiki のような Web らしいソフトウェアを大量のエンジニアリング資源で脇に追いやった悪役でもある。

ただ仕事で渋々使っているうちに、実はいいところもあるという事実を受け入れられるようになってきた。まず sync がほぼ完璧に動く。Evernote と違ってそうそう壊れない。Android アプリも当たり前のようにちゃんと動く。オフラインでも使える。デスクトップで使う分にはけっこう速い。ウェブアプリの割にキーボードショートカットが充実している。人々が Google アカウントを持っているおかげで選択的共有が簡単。思想的には気に入らないけれど、手がかかっている分で色々補えてしまう。いっぽう思想的には好みの Workflowy は、こうした基本的な品質で Docs に及んでいない。

試しに今まで Workflowy を使っていた日々の作業記録を Docs に移してみる。一つの文書に追記していくスタイル。Workflowy の柔軟性はないけれど、まあまあ使える。メニューを Compact control 表示に切り替える。Outline を表示する。ページサイズを大きいものに変更し、余白を減らし、等幅フォントを使うようスタイルを調整する。キーボードショートカットを調べ、いくつかの頻出操作を覚える。するとあら不思議、思ったほど悪くない。機密度の高いものも書けるし・・・。

これでよかったのか。なんとなく気まずい。なんとなく納得がいかない。でもきっと慣れる。

仕事の作業記録以外に Docs に移せるものはあるか。たとえば個人的な定期レビューの記録なんかは Docs でいいかもしれない。定型的なもの、頻繁に更新はしないものは Docs で足りそう。段々と移していこう。きっと慣れる。

追記

やはり納得できず、今は Dropbox Paper を同じ目的で使っている。

去年果たした Linux laptop への移行に伴い Evernote と Dayone を失って以来、数カ月に一度くらいなんか使えるノートとりアプリはないかとウェブをぶらぶらして時間を無駄にしてしまう。今日も二時間くらい浪費してしまった。

Note taking 難民になるのは昔からの持病。一度はサブカル心をおさえて Evernote を受け入れ、完治やったーとおもっていたものの Linux というサブカル心に後ろから刺されてしまった。ぜんぶむなしい一人芝居だけれども。いい年してなにやってんだとおもう。

従来のデスクトップ作業のうち音楽や写真などを Android に追い出せたので昔よりは Linux デスクトップの可能性は増えているはず。なのにまさか note taking がボトルネックになるとは。Emacs 中心の生活だった10年前の自分は想像しなかっただろう。

Evernote に挫けたのは Web 版が貧弱すぎたから。今は Simplenote と Workflowy がメインで、勤務先の機密が絡むものは Google Docs に置いている。Simplenote も Workflowy もウェブ版がちゃんと動くので Linux に優しい。Linux で note taking といえば Emacs を想像するかもしれないけれど、そんなによくない。Sync とモバイルの不在が辛すぎる。Emacs の org mode および org-journal もすぐに挫けた。同様の理由で昔つかっていた howm などに戻る気もしない。

Simplenote は日記や各種草稿、あとは braindump に使っている。Workflowy はリスト書き。TODOリストとか、作業ログとか。一時期は Workflowy に全部集約しようとしたこともあったのだけれど、あまりにモバイルがダメすぎて挫けた。Simplenote もあまり好きではないのだけれど, Sync がありかつ Android 版がきちんと動くので使っている。たぶん小さいメモを書くだけなら Google Keep の方が良いと思う。でも自分のような長文用途に Keep はまったく向かない。つらい。Simplenote にも不満は多い。日付のようなメタデータが見えるところに表示されない。公開していないノートに URL がない（そのため別のノートから参照できない。) そして export したデータからごっそりメタデータが落ちており、事実上エクスポートが機能しない。

自分の難民ぶり(愚かさ加減)を白状するためにここ一年で試したり評価したりしたツールを列挙してみる。

定番の Evernote 代替品 OneNote. Evernote よりマシだけど Web が遅い。Keep: 長文がぜんぜんダメ。Web もいまいちやる気がない。Google Docs, Dropbox Paper: 細かいテキストを書くのが断片だめ。新しい Docs を作るのが遅い/大げさ。文書が沢山あると破綻しそう。Zoho Notebook: Evernote クローンぶりが徹底してるのはいいんだけど、今のところウェブがない。日本製の Inkdrop というのもよさそうなので気になっているがこれはモバイルがない。

DayOne 代替品: Journey. あまりに露骨な DayOne クローンなのでつかう気になれなかった。しかしパクリである点を見逃せば手堅く開発を続けているっぽいから見なおしてもいいのかもしれないね・・・。Wordpress. 実は普通に非公開で blog を持てばいいのではないかという気がしている。まだ試してない。いちおうモバイルのアプリはある。出来はいまいち。ただ我慢はできそうだった。ちなみに競合の Tumblr はアプリが buggy で全然だめだった。

最近少し見なおしているのが Google Docs. メモごとにドキュメントをつくるとキリがないけれど、一つのドキュメントに延々と追記していくスタイルなら案外いけるのではないかと思い始めている。というのは勤務先チームの議事録がそんなかんじで、けっこう機能しているため。ドキュメント内なら簡単に検索もできるしね。なにか使いみちないかな。

ただこうやって矢鱈に新しいツールを試してがっかりするを繰り返すのは不毛すぎる。Linux という宗教を受け入れている以上ある程度の不自由は仕方ない。自分の note taking の現状を整理し、それにあわせて妥協できる範囲を探したい。

これは言い過ぎだが、Data Science 的な文脈で DataFrame が JSON に近い位置にいるのはたしか。JSON と同じく特に難しいものではない。一方で知ってないと色々損をする。

JSON と同じく、DataFrame はなにかが「ちょうどいい」抽象でもある。

データ交換フォーマットや PRC の wire protocol として XML が大げさすぎたように、データ分析をするのにORM や ResultSet みたいな行指向の抽象はいまいちだし、一方で完全に型が uniform な matrix や tensor みたいのはプリミティブすぎる。DataFrame は複雑さのバランスでうまいところを突いた。

そしていちど DataFrame という抽象が定まると、その上に色々なエコシステムができる。分析、可視化、I/O などなど・・・。Pandnas の上で動くライブラリは色々あるし、R に至っては言語自体が DataFrame のためのプラットホームみたいなもんじゃん。

DataFrame と顔見知りになれただけでも R や Pandas をさわってみた甲斐があったなと思う。

Learning Spark

知り合いが Hadoop をやっているのをみて羨ましくなり向こうが Hadoop ならこっちは Spark だ！と入門してみた。実際には大したことはせず, DataProc で遊んでみたくらい。まあ面白くはあった。DataProc は History Server にアクセスするのが面倒でいまいちという感想。真面目に使うとそのへんの workaround は確立できるんだろうけれど。

そのあと仕事で少しだけ Flume (Cloud DataFlow の前身) を触る機会があり、Spark 入門とあわせてちょっと big data な気分を味わえたのは良かった。

Programming in Scala (3ed)

Spark をやった勢いで Scala を復習。むかし初版を読んだときの印象よりは難しくない気がした。まわりの言語が難しくなってきたからかもしれない。Scala の型システムのうち Java にないもの (abstract type とか)が どうやって Java にマップされるのか調べなればと思ったのを今思い出した。そのあとちょっと趣味で小さいコードを書いたりしたが, Scala native で mature な HTTP クライアントがろくにない、という事実にやや呆れる。探し方が悪いのかもしれないが・・・。Spark で使うくらいが無難なのかなあ。

Hadoop Application Architectures

これも Spark の勢いで読んだ。憧れの Hadoop エコシステム、けっこういまいちな部分も多いね。自分でクラスタを運用するよりはなるべくクラウドに置いて EMR なり DataProc なりで必要なときだけ Spark などを動かす、という方が少なくとも余暇プログラマの範囲ではよさげ。(後日 AWS の発表会をみてその印象を強めた。)

どのみち自分が Hadoop システムのアーキテクチャについて真面目に考える日はこないだろうという事実は寂しい。

Building Microservices

教養に読んだ。まあいい話なのではないかなと思う。ただ Rails みたいに気の利いたフレームワークが出揃わないと個人ではやる機会がなさそうでもある。CNCF とかにがんばってほしいところだけれど、Foundation とかいってる時点でいまいち期待できない感もある。

Fluent Python

機会学習とかデータサイエンスをやるなら Big data 以前に手元で動く Python だと心を改め読んだ。良い本だった。(感想)

High Performance Python

Numpy 周辺の vectorized な世界に詳しくなろうかなと読んだ。まあまあだった。(感想)

Natural Language Processing with Python

機会学習とかやるなら隣接分野もわかった方がいいかと思い読んだけれど、 確率的アプローチになる前の古臭い自然言語処理の話が大半でがっかり。 ただそのあと読んだ From Frequency to Meaning: Vector Space Models of Semantics というサーベイを理解する役にはたった。このサーベイはよかった。

Learned Optimism

以下自己啓発っぽいやつら。 これは息抜きに読んだ。古い本だけれど予想外に面白かった。 感想はそのうち別に書きたい。

Deep Work

大雑把にいうと、ソーシャルメディアをやったりメールに返事してる暇があったら仕事しろ、という本。議論は雑だけれど、著者は書いている主張を実践した上で書いているのでまあまあ説得力はあった。自分のような脱ソーシャルメディアしたい勢といては励まされた。

最近にたような主張をする記事を NYTimes でみかけた・・・ら、この著者が書いていた。

The Life-Changing Magic of Tidying Up

Audible にて。これも息抜き。コンマリメソッドというやつね。なぜか流行ってるという話をNYTimes で読み興味を持って周辺事情をを色々調べたらあまりに面白かったため、敬意を払い原点も読もうと思った次第。Konmari method に全米が熱狂するこの現象ほんとに面白いのでなんとか伝えたい気もするけれど、一方で総体としてはかなりどうでもいい話なので割愛。どうでもいい副作用として洗濯物は Konmari Method でたたむようになりました。

Grit

Audible にて。これと下の Mindset とあわせて、自分は勉強とか根性というものに対する態度を改めた。詳しい感想はそのうち別枠で。

Mindset

Audible にて。ビルゲイツ推薦図書として流行っていたので読んだ。若干強引なところはあるが、核にある主張には説得された。

Predictive Analytics

Audible にて。機会学習サイコーっすよーという本。色々を事例を紹介していく。アルゴリズムの話もあるけれど、おまけ程度。ややクドくて食傷。むしろ The Signal and the Noise を読むべきだったかも。

The Master Switch

インターネット歴史読み物。昔読みかけて挫けていたのを思い出し Audible で出直し。 面白かった。一度は力を失った AT&T がジリジリと復活してくる様が不気味で読ませる。

Creativity Inc.

Audible にて。Pixar 社長の自伝。面白かった。Jobs の話はしないと前置きつつ前半 1/3 くらいは Jobs ストーリー番外編として普通に面白い。後半の Pixar の会社の話もよい。

個人的にはむかし論文を読んだ CG 研究者が経営者としてぶいぶい言わせてるという事実がなにより感慨深かった。Catmull-Clark subdivision surface の Catmull? まじで? 的な.

ゼロ秒思考

ここから日本語の本。知り合いが読んでいたのにつられて読んだ。色々つっこみどころも多いけれど正しい指摘もしていると思う。自分も少しメモの書き方が変わった。詳しい感想はそのうち別枠で書きたい。

速さは全てを解決する　『ゼロ秒思考』の仕事術

上の続編。前作でカバーされていない話題を扱っているかとおもいきや、著者のランダムライフハックを披露するしょうもない本となっていた。一冊目には可能性を感じただけにだいぶがっかりした。

成功する子 失敗する子――何が「その後の人生」を決めるのか

Mindset, Grit とかの並びにある話。子育ての話というより貧富の差など社会問題の本。面白かった。日本の貧困関係の読み物と照らしあわせて考えると示唆深い。

以上 18 冊。今年はジョギング中のタブレット読書と通勤や家事労働中の Audible を通年で使ったはじめての年。軽めの本を読む量を増やせたのは嬉しい。

一方で、ジョギングと Audible の枠では読めない歯ごたえのある本を一冊も通読していない事実は無視できない。手強い本を読めるようになりたいと 2-3 冊挑んだけれど、どれも読みきれなかった。悲しい。再挑戦したいけれど、手を打たないと同じ結果になりそう。

あとやはり英語の本はまだスループットが出ない。Audible も等倍か 1.1 倍くらいでしか聞けないし、ジョギング中の読書もオライリー本を一ヶ月一冊がせいぜい。たまにちょろい日本語の本を読むとすごい速度で進み驚く。英語圧のために 5-6 年やっているこの縛りプレイ、明らかに自分の読書量を削っている。一方で昔よりは速く読めてもいる。いつまで続けるべきかは悩ましいけれど、まあしばらくやります。技術書以外は日本語で良い気もするけれど、技術書以外はほとんど Audible なのだった。

そういえば本以外に読んだオンライン長文や論文なども読んだ記録を残したいと数年来思っているのだけれど、うまくいっていない。