Goodfellow 本 読書記録。

Chapter 6 は feed forward network. 前読んだ時は backpropagation の節ばかり読んでいたけれど、その手前にある activation function や loss funciton の話も結構丁寧にかいてあった。 自分はなんで sigmoid がダメで ReLU なのかわかってなかったけれど、saturation があるでしょ、といわれるとそのとおりだなと思う。

最後にある Historical Notes の節もよかった。現代の NN は昔と何が違うのか、データサイズや計算機の性能はもちろんだけれど、Maximum Log Likelihood / Cross-entropy の普及と ReLU の登場もでかかったという。授業をぼんやり見てるだけだと気づけないところなので読んだ甲斐があった。

Backpropagation は、わかってから読むと大変明快に書いてあるけれどわからない人にわかりやすくは書いてない。去年がんばった甲斐あって理解はできたが、新しい発見もなし。でもこれが理解できるようになったのはよかったなあ。プログラミングでいうと再帰とかポインタとかクロージャとかシステムコールとか、そういうやつらが理解できた時の喜びに似ている。

ゆこっぷ (奥さん) の仕事がはじまった。Day care の送り迎えともに担当で、さすがに疲れている様子。日中にやってもらっていた細かい雑用が夜に回ってくるようになった。仕方なし。

時間割を変え、朝早く会社に行くことにした。5 時に起き、6 時すぎに家を出て、６時半到着くらいのかんじ。会社で朝食を食べ、読書などをして、7 時半ちょっとすぎくらいに始業。16時半退社、21時就寝。

自分の業務外ワークを夜から朝に持っていくのが目的。朝はまだ元気なので少しは手強い本が読める。これはよい。30-60 分程度の短い枠だから進みは遅々としたものだけれど。

結果として就寝が早まり21時になった。帰ってきて、子供の風呂入れを手伝い、炊事、掃除、食事、風呂、などの家事が一通り終わると、順調なら20時くらい。残りの一時間でなにをするか。といっても疲れている上にごたごたして時間の残らない日も多いから、なにか生産的なことをしようとムリするよりは休憩と割り切るのが良いのかもしれない。未定。

弁当担当。ゆこっぷの弁当づくりをひきとってみる試み、まあ大丈夫そう。結局のところ作りおきや晩飯の残りを詰めるだけで、何かを作りわけではない。台所の片付けをふくめ 20 分くらいで済む。朝 5 時に起きて弁当を作って猫の世話をして身支度してストレッチして、となると微妙に時間が足りず、6 時ぴったりに家を出ることは出来ない。やむなし。

週末。子供がずっと家にいる上に平日から持ち越した家事が溜まっているぶん、平日より自分のために時間を確保するのがむずかしい感じがする。週末をどう過ごすのかは全く見通しがない。むー。

ここ半月くらいは本を読む以外に何も業務外ワークをしていない。平日一日 45 分 = 月に 15 時間で、これは以前の試算よりだいぶ短い。自分の生活にこれ以上なにかする余地がある感じも今のところない。ただ今は生活に慣れるのが優先かなと思う。無理に色々詰め込もうとしても体調を崩したり人間関係を損ねたりしそうなので。

一方で標準的な子持ちの大人は業務外ワークとかしないと思うので、したいならなんらかの非標準的な取り組みが必要だろうとも思う。ここから先の時間確保は時間割に組み込んで確実にやるより、隙をみてとりくむ不定期な枠なのかもしれない。 EC2 の spot instance や GCE の interruptible VM みたいな。そういう時間の見つけ方や使い方は今まで考えたことがないけれど、要研究かもなあ。

情報 offloading 活動つづき。オンラインサービスのうち使ってないものを解約: Netflix, Youtube Red, NYTimes.

Netflix, 引っ越してきた当初はゆこっぷ（奥さん）がぼちぼち見てたけど、仕事をはじめてからはすっかり見なくなった。映画は Google Play や Amazon で買うなり借りるなりして観ている。頻度は低い。月一回くらいかな。

YouTube Red/Google Play Music, 日本の雑なポップスを聞きたいと思っていたけれど、US からだと聴けないものばかりなのだった。あと Google Play Music の無償版適当ストリーミングは Spotify とおなじくCM  が入るだけなので、聞きたくなったらそれでいい。Digital music は国境をまたいで買いにくい。Amazon.co.jp で MP3 を買うのが今のところの結論。どのみちそんな頻繁に買わない。自分にとって音楽はノイズ避けでしかないことだし、US の音楽を聴けということかもしれない。

NYTimes. 今年に入ってからはほとんど読めてないので諦めることにした。この新聞、記事はいいけど subscription の仕組みは全体的にクソ仕様。まず自分は  $35/month 払っていたのだが、今はこれに相当する plan がない。"Full Access" という plan が $25/month. どこかのタイミングで価格改定があったようだが、既存のユーザは高いままという次第。おまえはケータイ回線業者か！そして解約には電話が必要。おまえは Comcast か! 特別に安くしときますよ、みたいなオファーをしてひきとめようとするあたりも同じ。ろくでもない。

ウェブ企業の契約形態に慣れていると外の世界のクソさを忘れがちだけれど、そういえば世の中こういうものだった。もう NYTimes とは契約しない気がする。めんどくさいから。かわりに買い物ついでの supermarket で紙バージョンを買ってみたらけっこういい。やっぱ新聞は紙がいちばんということで。週に一回だけ買おう。

メールで受け取っていた newsletter の類も一旦ぜんぶ unsubscribe. 自分の Inbox で脇道コンテンツと要対応メッセージが混じるのはよくないとおもったので。思ったよりたくさん subscribe していたことがわかり我ながらアホめと思う。

Day care が始まったので、予定どおり走って迎えに行ってみる。

が、こりゃだめだわ。まず日差しが強い。自宅まで徒歩15分、4 月でこれだと夏には子が熱中症になってしまう心配がある。日陰は涼しいんだけど、木陰のある気の利いた道ではないのだった。そして自分の身体が熱い。走ってきたからね・・・。抱っこひもでかかえているのだけれど、互いに身体がくっついているため子が暑そう。あと雨がふると厳しそうなのを肌を持って感じた。荷物が多いので、傘をさしてもあちこち濡れそう。

説明が難しいけれど、なんとなく危ない橋を渡っている感じがある。物事が自動車前提にデザインされている。自分ひとりだと特に困らないけれど、子を抱えていると身体の自由が効かないので不安。ガラわるいやつらに絡まれたりすると辛そう。

相談の結果、追加費用を払って預ける時間を延ばしたうえでゆこっぷ（奥さん）が drop off だけでなく pick up も担当することにしてみた。まわりの共働きにクルマ一台でやりくりしている人々を他に見たことがない。自分たちもいつかはもう一台持つことになりそうだけれど、今はまだ、という判断。

またゆこっぷの負担が増えてしまうのでだいぶ心苦しい。Good news は Pick up 作業自体はクルマがあるなら特段大変ではないこと。といっても退社時刻が hard deadline になるは厳しいこともあろう。せめてもの offloading ということとでゆこっぷの弁当は自分がひきとる予定。自分が食べない弁当を作るのは principal agent にならないか心配な一方、弁当も含めた献立計画全体を自分がコントロールするのは一貫性があるようにも思える。

これだけでなく、ゆこっぷには復帰後の時短勤務をお願いしている。これはすごい負けた気がしている。

自分を時短勤務にしないのは経済的な理由。時短に伴う減俸の絶対額および潜在的な解雇リスクのコストが違いすぎる。Tech 大企業勤務の自分と non-tech 小企業勤務のゆこっぷで給与格差があるのは当たり前で、だから時短の判断もそこそこ合理的だとは思っている。

一方で男女間の給与格差は広く知られた社会現象であり、それでも家事や育児を奥さんに押し付けないのがひとつのリベラルな態度。目先の経済的合理性やブートストラップのジレンマに負けず社会のあるべき姿を目指せという話なわけじゃん。だから経済的な合理性をとった自分は負けている。それに家事育児に職業的達成の邪魔をされたくないという個人的な願望が表面的な合理性の影に隠れているのも事実で、それも後ろめたさに繋がっている。

理想に対して資源が足りない以上、こうした葛藤が終わることはないだろう。極端、単純、乱暴な理想を受け入れれば解決する部分もあるのだろうけれど、今のところ受け入れる気はないので後ろめたさとともに生きていきます。

情報過多なのをなんとかする定期的な活動。

まずソーシャルメディアのアプリは別のスマホに移し、自分のメインの電話からはアンインストールした。貸出用に買ってあった Moto G Play をそのソーシャルメディア端末に転用。持ち歩かず、自宅のガジェット充電棚に置いておく。

ソーシャルメディアのアプリを完全に消してしまうとついブラウザで開いたりしてしまうけれど、みたいときは別のスマホを手に取る、というくらいの距離にしておくとブラウザ経由の誘惑に負けにくくなる。

Android, 安い端末があるのがよい。Mogo G Play なんて良い出来なのに Amazon Prime で $100 だからね。会社用隔離端末としてもう一台欲しいくらい。次やるなら $50 くらいのをためしたい。

このバリエーションとして、Chrome (ブラウザ) にも隔離プロファイルを作った。メインで使っている Google アカウントなどへのアクセスを遠ざけるのが目的。隔離プロファイルは独立した Google アカウントをつくる。パスワードマネージャは入れず、GitHub やブログなど作業に使う最低限のパスワードはブラウザに覚えさせる。自分は普段からソーシャルメディアはブロックしているけれど、隔離プロファイルではそれに加えてニュースサイトなどもブロックする。そして普段はその隔離プロファイルを使い、用事があるときだけメインのプロファイルでウィンドウを開く。

メールやニュースはもっぱら電話で眺める昨今、PC を開いている時はなにか作業をしたいときが多い。なので Gmail などを隔離してもさほど不便でない。/etc/hosts ほどの抑止力はないけど、地味に割込みを遠ざけておける。AWS や GCP のアカウントがさわれないので少し困るけれど、それらはなるべくコマンドラインでがんばる。なお /etc/hosts は引き続き使ってます。

仕事では Chrome/Google のアカウントが必須なのでこの手は使えない。ただ仕事中のうっかりさぼり指数はそんなに高くないから良いでしょう。仕事中のコードを書くワークステーションではメールやチャットを見ないようにはしている。そういう連絡系は Macbook でやる。GMail 上では Hangouts からサインアウトをしておくのも良い。Hangouts は hangouts.google.com で使うようにする。たまにチャットで呼ばれて気づかないことがあるのが玉に瑕ではあるものの、本当に急ぎの用事ならチームの人がフィジカルに話しかけてくるのでセーフ。

我ながら迷走してるなと思うけれども、インターネットに脳をやられた人の price だと思って受け入れている。

Part 1, 5.5 あたり。

誤差を最小化するのではなく、モデル(確率モデル)上でのデータの likelihood を最大化する、という形で学習を定義すると色々捗るという話。

Mean squared error も実際はガウス分布の likelihood と等価であるとか、よくわかってなかったので読み直す。ついでに cross-entropy も等価だとかいいだすし。何度か読み直し、Python でグラフを書いてみたりもして、ようやくメンタルモデルができてきた。

Bayesian 方面から来るとこの方が馴染みやすいのかもしれないけど、何かと確率変数で物事を定式化していくスタイルはなかなか馴染めなずしんどい。ガチガチに高階関数なコードに馴染めないのと似ている。なんか「おまえらが Rx だなんだと有難がっているものは全部モナドだ！バーン！」みたいな気分。もうちょっと適応したいもんです。Monad も Bayes も。

ML diary.

Deep learning, どういう話かすっかり忘れてしまったので Goodfellow を読み直す。今回は頭から順番に読む。ようやく Part 1 読了。Part 1 は Deep Learning の前段階である線形代数だのなんだのを復習する内容。

まあ読まなくてもいいと思う。知っている内容は知っているし、知らない話は短く書かれてもわからない。

あとあと必要とされる知識のうち自分が知らないものを把握する役にはたった。自分は確率、情報理論が怪しい。数値計算は怪しいけれど、まあこれはなくても大丈夫かな。なんとなく。線形代数はたぶん大丈夫。機械学習基礎、きっと大丈夫。

確率と情報理論は主に Part 3 で必要とされた記憶がある。つまり Part 2 までは読み進められるけれど Part 3 を読む前にはこれらの前提知識を勉強する必要があるということ。それがわかったのはよかった。

明日から本編である Part 2 に入れるのはうれしい。読み切るのにどれくらいかかるかねえ。

関係ないけど Ian Goodfellow 氏、いつのまにか OpenAI から Google に移籍していた。時代に欲されている人は自由だなあ。

一週間終了。疲れた。社内の復職 tips サイトに「月曜から復帰するのはやめておけ」と書いてあったのを思い出す。無視して悪かった。この疲れが今の狂ったタイムテーブルのせいなのか、仕事の慣れが足りないせいなのか。後者の割合が高いといいんだけれど。

走って通勤。衣類は工夫の余地がありそう。荷物を減らすべく、帰路の衣類=日中の衣類にしたい。手持ちの綿の服は諦めて Polyester を受け入れ、中学校の体育教師みたいな格好をして過ごすかんじ。また一段狂気が増す気がして決断できないが、とりあえずジャージを一着 Amazon で注文。

雨。走れないので勤務先が近所を走らせている通勤バスに乗る。しかし 6:30 みたいな時間にはまだ便がない。7:30 くらいのやつがあったので、それに乗る。雨の日は家で朝食をとることになる、はいいとして、運動ができないのは困るなあ。雨が降った日は夜にでもジムで走るべきか。あるいは朝走るか。朝走る方が全体としての整合性はとれている気もする。

夜。帰宅して掃除して子供を風呂に入れて晩飯を作って食べて。これが終わるともう疲れている。本を読みたいが、しんどい。時間よりは体力がボトルネックになっている。時間がボトルネックになるよう時間割をいじったほうがよさそう。

色々計算してみると、自分が自由に使える時間は一日 2.5 時間くらい。これは仕事の昼休みとかも含む理論値で、雑用やイレギュラーな出来事などを間引くと職業訓練に使えるのは一日平均 1-1.5 時間くらいが現実的な数字。週末も時間があるわけではなく、まだ真面目に数えてないけど平日と同じくらいがせいぜいな気がする。となると一ヶ月あたりの職業訓練は {1, 1.5}*30 = {30, 45} 時間。フルタイムの一週間くらい。一年で {9, 12} 週間。フルタイム二、三ヶ月分。

こう数えてみるとけっこうある。そんな時間があるようには思えないが、それはこれらの時間が断片化されているのと、フルタイムの定時というのは大して長くない（フルタイムで成果を出すには調査などで暗に課外の時間を使っている）、この時間すべてを職業訓練につっこむわけではない、などの事情からくる感覚のギャップか。たとえばこのブログを書く時間もその枠から捻出されている。ブログとか書いている場合なのか？一方でどのみち何らかの reflection はするのだからそれがブログの形をとるだけとも思える。

自分の職業的 prospect の暗さは考えだすとキリがない。暗い気持ちになるとますます生産性が下がるので、運動で脳内麻薬を摂取しつつできる範囲でやれることをやります。

この blog の投稿が 100 を超えたと少し前に知らされた。

育休のヒマさに助けられたとはいえ、2015 年は 20 個くらいしか書いてないことを考えるとよく書いてるのではないか。まあ大したことは書いてないけれど、どうでもいいことを気兼ねなく書きたいという思惑がかなっているとも言える。

一方で、もうたいしたことなくないまとまった何かが書ける気がしない。それに、今となって考えると長い文章はブログではないところでやるのが良い気がする。たとえば薄い同人誌として epub をつくるとか。Gitbook あたりに置くとか。ウェブにはウェブに向いた長さがあって、自分が過去にブログに書いたものはその上限を超えてるケースが多かったと思う。

もっとも根本的にはまとまって説明できるようなものを特に持っていないという事実の方が悲しむべきことなのだろう。詳しいものをなにも持っていないのは悲しい。他人に語る価値のある何かに、他人に語れるほど詳しくなる日は、はたしてまた来るのだろうか。今は辛抱の時期、と自分に言い聞かせる。

仕事のコードベースに Dagger が入っていた。休暇前には入れたい派と入れたくない派が口論していたけれど、入れたい派たる TL が説得しきったぽい。がんばった。

自分は DI に mixed feeling で、ないよりはいいけど今更騒ぐようなものでもないと感じる。たぶんそれは自分が DI 世代の洗礼をうけており, framework があろうがなかろうが DI 的なコードを書くからかもしれない。依存はコンストラクタの引数で渡すし単体テストがいるなら重いクラスはインターフェイスで隠すでしょ? あたりまえじゃん? という。

少し前に The myth of using Scala as a better Java という記事があった。この記事では Scala では Java と違って DI framework もクールなんだよ！みたいな話をしている。Cake pattern で framework を使わないのが Scala の DI に対する態度だと思っていたけれど、今は違うんだな。まあ手書きだと interceptor とかできないよね。たしかに。

などと話題を目にすることが続いたこともあり、少し DI について思いを馳せていた。

DI はもともと testability の文脈から生まれたけれど、DI framework は必ずしも testability のためだけにあるわけでもない。テストを書こうが書くまいが DI framework に有用性はある。とはいえテストのことを忘れて Dagger のような framework をみると中途半端に見えるのも事実。Android 上だと特に煮え切らない。

何が煮え切らないのか。自分は DI framework に何を期待しているのか。少し考えて見る。

DI framwork はオブジェクトグラフ(DAG)構築を支援するツールと言える。更に一歩さがると、Make をはじめとするビルドシステムにならぶ依存関係解決システムであり、つまり Spark や TensorFlow みたいなデータフローの実行系でもある。有向グラフを評価して末端の結果を計算する。その評価プロセスに伴う複雑さを利用者から隠してくれる。

Java の DI framework...というと一般化しすぎで Dagger の話だけれども、その第一のいまいちさは依存関係記述の冗長さだろう。初期 Spring の残念な XML は論外として、Dagger の annotation と Component/Module クラスを使う依存の記述も特段ぱっとしない。Java のクラスや annotation をたよっているせいで冗長。もうちょっとコンパクトにできないのかとおもってしまう。ただこれは DI の限界というよりまともな言語内 DSL を定義する力のない Java の限界かもしれない。Scala の MacWire なんかはちょっとだけマシに見える。

Dagger のいまいちさその 2 は、非同期性をまったく扱ってくれないところ。たとえば Android の Service はインスタンスを非同期にしか bind できない。だから Service を依存関係にもつグラフは Dagger では作れない。一方でこういう非同期性は Android のコードを辛くする原因の大きな部分を占めている。

こういう非同期性の問題を今は Rx が解決してくれているわけだけど、そのせいで依存の解決が Dagger と Rx にまたがってしまう。となると全部 Rx でよくね、という気分になる。でも本来なら Dagger の builder は必要に応じて build() の戻り値を Promise 的なオブジェクトで返してほしいし、値を provide する module 達も同様に依存関係を非同期で解決させてほしかった。あと 3 年くらいしたら開発者もやることなくなってそういう機能をつけはじめそうだけど、今欲しいんだよ！今くれ！せめてどこかのガッツある子が勢いでハックできるように Dagger にはプラグインを機構つけてほしいです。

Dagger のいまいちさその 3 は, 実行時の引数を依存関係に組み込めないこと。たとえばデータベースにクエリを投げるとかってデータベースのクライアントと SQL を引数にとって依存関係を解決するプロセスというか、ある意味で pure function なわけじゃん。それを扱えないとデータフローエンジンとしてはいまいち。

オブジェクトを inject するという DI 本来の原則によるとアプリケーション側からフレームワークに何かを渡せないのは自然だけれど、物事を宣言的にしていきたいデータフロー処理系の立場からみると DI のコンセプトに固執されてもつまらない。もう副作用のないところは全部ひきとってくれよ。要するにモナドだろ(いってみただけです)。

Dagger のいまいちさその 4 は、寿命の始まりの面倒は見てくれるのに寿命の終わりは放置していること。Android では Activity などライフサイクルの終わりに必要な後始末の処理を忘れて error prone にしがち。そこは lifecycle を manage するツールすなわち DI framework が面倒をみるのが筋じゃね?

最近の Dagger には Android 向けの機能が入るという話を聞いたので喜んで見に行くと、メモリプレッシャーが高くなったときに解放する参照を選べるとか書いてあってがっかり。そうじゃなくて！ Component を捨てるタイミングで！ destroy() を呼んで欲しいんだよ！そういうコードを生成しろ！ @Destroy みたいなアノテーションが必要か・・・

Android ライフサイクルの辛さ, マルチコア化に伴う非同期性の蔓延やデータフロー・プログラミングの隆盛など昨今の身辺事情を鑑みつつ改めて DI を見直すと、かつてはすごくキラキラして見えたものが解いていて欲しい問題の 2 割くらいしか片付けてくれない現状にがっかりする。だから盛り上がれないのだろうな。ないよりはあったほうがいいんだけど。DI よりはもっと今時の何かに期待すべきなのかもしれない。

追記

その後 Dagger には Producer というのがあることを学ぶ。これはまさに非同期にオブジェクトを解決する仕組み！だが・・・ ListenenableFuture なんてつかってんじゃえーーー！RxJava に対応しろ！今すぐだ！

いやいいんですよ Guava. でも Guava だけ特別扱いとかおかしくね？今時みんな Andorid で Guava つかってないんでしょ...  Netflix の若者とかが PR 送りつけたりして欲しいもんです。はい。

Amazon, Play Books

なかなかよかった。なにより薄い。はじめて Haskell の本を読みきれた気がする。章末問題がよくできていて、途中まではちょこちょこ解いた。仕事がはじまってからは諦めた。もう少し解いた方がいい気がするが・・・。

Haskell, 相変わらず実用性を感じないけれど。一方で昔ほどは理不尽にも感じない。そして Rx など Haskell 発祥の技術が流行ってきたせいで、なるほどアレがコレなのかという発見がある。たとえば Erik Meijer が Rx だけでなく async/await を推した理由も、要するに do/return が欲しかったのか、みたいな。

例題にでてくる Monadic Parser みたいのを見るに、もしかしたら Kotlin の suspend method もうまくつかえば単純な非同期だけでなく monadic parser みたいのを作れるのかもしれない。パーサのコードはまっすぐに書き、しかし pull based でうごく XML parser みたいな。10年前に欲しかった・・・。

一冊流し読んだだけだとウンチクは溜まれどコードを書けるレベルは程遠い。せっかくなので もうちょっと周辺を読んでみたいけれど、あとがつかえてるのですぐには無理。でも気が向いたらなんかもう一二冊読みたいもんです。

復職初日および二日目。

諸事情により走って通勤することにした。朝は 6:30 に家を出て、帰りは 16:30 に会社を出る。片道 20 分ちょい。このように狂ったタイムテーブルなのは 、来週から帰路にあるデイケアで 17:00 に子供を引き取る必要があるため。

朝飯は会社で食べている。家で朝食をとらないのは夫婦円満的視点からやなかんじだが背に腹は変えられない。そして 7:00 だとまだ食堂があいていないので、休憩コーナーにあるシリアルなどを適当につまむ。大企業の福利厚生恐るべし。

朝早く家を出るのが最大の難関だと思っていたが、自分はもともと朝にジムで走っていたのでそれが通勤になるだけだった。むしろ帰りがしんどい。仕事がおわったあとって、実はけっこう疲れているね。頭だでけなく身体も。仕事どうこう以前に夕方だからかもしれないけど。その疲れにもかかわらず所定の時間に目的地（デイケア）にたどりつかないといけない。プレッシャーが重い。仕事にはまり迎えをすっぽかすとこまるから, 16:25 にアラームを設定。

退社の 16:30, 外はまだかなり明るい。こんな時間に帰っていいのか不安になるが、朝 7:00 から会社にいる事実を思い出して自分を納得させる。

仕事。休暇突入まえに放置していたパッチがそのままになっている。一人プロジェクトの寂しさ。こいつらを片付けあとにやることを考えないとな。とりあえずは Android O 向けになんかやる的な細かいバグを引き取るのがいいかもしれない。人々は新しいプロジェクトで忙しそう。手伝いたい気もするが、近づきたくない気もする。だらだらとしてしまい仕事をやる気が起きない初日の反省から、二日目は久しぶりにポモドロした。

昼飯。自分で調理しなくても食い物にありつけるタダ飯の有り難みを改めて appreciate する。しかしどうやっても食べ過ぎる。スナックや飲み物も食べ過ぎがちだったが、帰り道を走るとき腹痛になるとわかった。午後の間食はひかえよう。

今週はまだゆこっぷ（奥さん）が育休中で、子供は家にいる。デイケアの始まる来週からが本番。

なお日記といっても毎日書く予定はない。

The ChangeLog の feedbin 回を聞き、割と共感したのでつかってみようかな Feedbin・・・と読みたい Blog のリストを作ろうとしてみたものの、あまり列挙できずにああブログは自分の中では死んでいるのだな、と思い直す。Feedbin を使って Blog を読むというのは、最初から Blog 読者をやりなおすということな気がする。それは楽しいことだろうけれども、今は余力がなくてできないわ。残念。ちゃんとフィードのリストを保守し、ブログを読み続けている人が羨ましい。

Feedbin 作者は自身を Indie Web 開発者と位置づけている。自分はこういう indie なのはちょっと好きで、pinboard.in とかも使っている。自分には叶えられない夢を叶えている人たち。

そして RSS はそういう indie 精神と合致していると思う。ソーシャルメディアと clickbait によって廃墟と化したメインストリームの Web を横目に、儲からない趣味として文章を書く。そうそう、blog  ってそういうもんじゃん。Audience building とかばかじゃん。みたいな。いやいいんだけど。

自分は個人 blog がメインストリームに返り咲く日は来ないと思うし、個人 blog  の閲覧に余暇時間予算の多くを割きたいとも思えない。でももうちょっと読んであげたいもんだなあ。心の中のそのうち気が向いたらやりたい事リストに追加しておく。

Danah Boyd が Medium に書いているのに気づいた。

Danah Boyd は Social Media に対して Ethnography をやる、という自分の好きな分野どまんなかの社会学者なので以前は書いたものをちらちら読んでいた。存在を忘れていたけれど再会できて嬉しい。

Blog をインポートしたのか過去の書きものもけっこう Medium 読めるようになっている。一方でソーシャルメディアやオンライン sexism をめぐる社会状況は激変しているので、今みると古臭さを感じなくもない。ソーシャルメディアについて語ることも、インターネットのコミュニケーションについて語ることも、今やなにも珍しくないからね。

Depmind による on top of TF のライブラリらしい。(GitHub)

Keras など既存のライブラリと比べ parameter sharing がやりやすいのが利点、としている。Keras との比較だと TF native なのもいいのかもしれない。

まあ当分はスルーでいいかな。自分のような素人は当分 Keras で事足りることでしょう。インストールの冒頭にまず Bazel を入れて・・・とかやんねーよ！などと思うのだった。

三ヶ月の育児休暇も今日でおわり。ざっと採点してみる。

育児。おもったよりできなかった。一方でゆこっぷ(奥さん)が思ったより enthusiastic だった。そして父親は授乳をしないとなると育児の負担を揃えるのは難しい気もする。そのぶん家事をひきとるべきだったけれど、引き取る量が十分ではなかった。

炊事。全体ではやってない家事のなかでもこれだけはよくやった。自分はもともと半分以上の炊事をしていたけれど、有給中は 9 割くらいは引き取っていたとおもう。炊事以外の家事をもうちょっとやるべきだったね。掃除洗濯。

職業訓練。アプリを作れたのは良かったような気もするけれど、ML をまったく忘れてしまったのは代償として望ましかったのか。アプリづくりをはじめた頃は子供の世話がすごい大変で、数式を睨んで追いかける気力がなかった。余裕ができたあとに復帰すればよかった気もするけれど、そのために書きかけのアプリを abandon するのも良くない。そもそも職業訓練とかしてないでもうちょっと子供と engage すべきだったとも思う。

運動。走るのだけは続けていた。ただほぼ在宅で子供の散歩くらいしか歩かなかったので総運動量は普段より少なかった。最低限は守ったくらい。

全体としては 70 点くらいかな。育児休暇というのをどう過ごすべきなのか事前にはまったくわかっていなかったので、こんなもんだと思う。

育児休暇を三ヶ月とること自体に価値はあったか。それはあったと思う。十分に engage しなかったとはいえ子供に対する理解は進んだし、ゆこっぷとの役割分担を調整する余裕もあった。じぶんは根がさぼり体質なので、たとえば育休を一ヶ月で切りあげゆこっぷより先に職場復帰していたら、仕事を理由に育児は今より更にやらなかった気がする。

ML 入門 Diary 略して MLD. 実際は ML というか NN だけど。

ここ数日で GCE で Jupyter とかをする用のインスタンスの provisioning 自動化をした。

• 前回 AWS でやっていた時は Vagrant をつかっていたけれど、今回は GCE の Startup Script と若干の手動作業に移行した。Vagrant は大げさ過ぎることに気がついたため。サーバの deploy と違って Jupyter 環境にはどのみち SSH でログインして色々作業するので、完全に自動化しなくてもまあいいかな、と思うに至った。
• Python は pyenv のみで virtualenv はナシ。環境を作り直したい時は VM ごと作りなおせば良いと割り切る。virtualenv って activate とかが面倒だし。
• GPU の有無は、いちおう GPU を使えることは確認しつつ最初は CPU だけにしておく。お金をけちるため。
• GCE はインスタンス構築後に device type (CPU 数とか) を変えられることに気づいた。各種準備などをしている時はCPU数を減らし、トレーニングを回す段になったら CPU を増やす、とかができる。残念ながら GPU の付け外しはできない。そのうちできるようになると期待。データは独立した permanent disk に置きインスタンスを作りなおすでも理論上はいいんだけど、コマンド一行で変更できるならその方がラク。
• Jupyter notebook でなく Jupyter Lab を試している。荒削りながら Koding をしょぼく軽くしたような感じで、けっこう良い。Notebook 機能だけでなくテキストエディタとターミナルがブラウザからさわれるようになる。上で SSH すると書いたけれど、実は Jupyter Lab の起動までを全部自動化した方がいいかもしれない。オープンソース JS プログラマは Atom とかほっといて Jupyter Lab の開発を手伝って欲しいもんです。

作った環境の使用を兼ねて Keras をさわってみる。といってもサンプルをコピペして動かしただけ。TF を直に触るよりはだいぶラク。自分で shape を計算する手間がだいぶ減るし、単純にコード量も少ない。自分がクールな ML アルゴリズムを発明する日は来ないだろうという現実を踏まえると、このレイヤからプログラミングを始めても良い気がする。アルゴリズムへの理解は深まらないかもしれないけれど、実際に動かすまでの距離は短い方がやる気を出しやすいからね。

一方で、自分は Keras が面倒を見てくれないレイヤにも苦手なものが多いと気付く。ML な基本的な作業、たとえばデータの前処理、精度の評価、hyperparameter の探索など。前ちらっと Kaggle 入門を試した時の理解によるとそのへんは sklearn が面倒を見てくれるっぽい。そのうち入門しないといけなそう。

似たような味だったけど、調理時間は結構違う。Butternut Squash は 20 分蒸し茹でしてやや茹で過ぎくらいなのに対し、Kabocha Squash は 4 分で煮崩れた。レシピには 2 分と書いてあったのでそのとおりにやればよかった・・・。

Butternut Squash, 調理時間の長さ以外だと種も少ないし皮もむきやすいし味もあっさりしているので Kabocha より好きかもしれない。