自分はなにかというとウェブやブラウザを使おうとしたがる。うっかり Chromebook を買ってしまったりする。よくない性癖だなと思う。
でもこれはブラウザの仕事を何年もやった結果でもある。ウェブはレガシーでコンテンツもほとんど時間の無駄・・・とは切り捨てられない心情がある。Deep Work を読んだひげぽんが、自分は無意識に Twitter を使う理由を探していた、というようなことをどこかに書いていた。これも似たようなものではなかろうか。ソーシャルメディアを時間の無駄と切り捨てられない心情。
こうしたある種の attachment や obsession は時に自分たちを苦しめる。職業病とばっさり言うのは容易い。けれどそのこだわりは切り捨ててしまって良いものなのか。Web なりソーシャルメディアなりを仕事にしていた人がその良さを大切にする。それを咎めることはできるのか。
自分はソーシャルメディアは時間の無駄で自分な単なる中毒だと思っているし、明日 Twitter がなくなってもちょっと寂しいくらいだと思う。一方 Web テクノロジは何らかの形で息を吹き返すとも心のどこかで信じている。でもそれは「自分にとって」そうだというだけで、この価値観を一般化したいとは思わない。
自分が深くコミットしたものを通じて何らかの価値観を形成する。その価値観の残滓が自分の現実の邪魔をする。そういう価値観は、たとえ邪魔であっても抱えて生きていく方がまっとうに感じる。それをすっかり忘れてしまうというのは、自分が人生を費やした何かを忘れてしまうのと同じだから。
自分の脳に刻み込まれた反応を自覚し、眉をしかめ、あるいは歯ぎしりし、または苦笑いして、不都合を迂回する。そんな所作に馴染んでいきたい。現実の邪魔が増えていく過程を老化というなら、それは仕方ない。
当初の目論見に反し portrait mode での PDF リーダーとして使い物にならなかった Chromebook Plus, なんとか使ってあげようとしていたものの、結果として無駄に Web を見る時間が増えたり workaround の調査に時間がかかったりと frustration が溜まる一方。Sunk cost の罠にハマっているように思えてきたため使うのを諦めることにした。
ブラウザ上の開発環境でカジュアルコーディングをする試みに続き、昨日は GCE 上の Jupyter notebook をさわれるようにしようと四苦八苦していた。
Ubuntu では SSH の port forwarding で SOCKS proxy を通し、Firefox のプロキシをその SOCKS にしてクラウド内の VM にアクセスしていた。Chrome OS も一応 port forwarding はできるらしいけれど、ブラウザが Chrome しかない(当たり前)なので通常のコネクションと SOCKS を同時に使えない。不便すぎる。ホストの port forwarding に頼らず oauth2_proxy などを使ってアクセスする方法も考えてみたものの、SSL の証明書をとるだの reverse proxy と使い捨て VM の間の HTTP の forwarding を設定するだの面倒が多く, Ubuntu から SSH する方が圧倒的にラクそう。
時間が無限にあれば趣味として Web-based coding の可能性を追求していいかもしれないけれど、自分はそんなことに時間を使いたくない。だから Jupyter 端末としても使えない。結果として自分にとっての Chromebook の使いみちは blog を書いてウェブを眺めるくらいしかなくなってしまった。自分はウェブを見る時間を減らしたいと思っているので、ウェブしか使えない端末が手元にあるのは望ましくない。実際ここ一週間くらい Chromebook をメインに色々やろうとしてみたけれど、結果としては procrastination が進んだだけだった。
$400 の買い物が無駄になったことも、PDF を快適に読める環境がないことも、Chrome OS が自分にとって使い物にならないことも、当分 crappy な XPS13+Ubuntu を使い続けるしかないことも、どれも悲しい。がこのままニッチ環境にこだわってズルズルとサブカル税を払い続けるよりは、うかつ税とみなして終わりにする方が良かろう。
Chrome OS 上の Android 実行環境は今度よくなる可能性もあるので、一年後くらいにまたさわってみたい。でもしばらくはそっと押入れの奥のほうにしまっておきます。
Google Cloud には AWS にない Projects という概念がある。これがいまいちよくわからない。
課金などはこの project 単位で計算される。だから予算管理とかに使えるのはわかる。Project をまるごと消すこともできるので、いわゆるプロジェクトに紐付けることもできる。けれど個人だとどういう単位で作るのが良いのか、best practice がわからない。
ドキュメントは "Use Project as a boundary for policies" と言っているが、個人用途だとこれといった policy はない。Firebase で project をつくると GCP にも同じ名前の project ができる。むかしは App Engine のアプリをつくっても project ができた。なにかアプリやサービスをつくる、みたいなときには新しい Project を作るのが自然そう。
ではたとえば TensorFlow 用に一時的に上げたり下げたりする速い VM が欲しいとか、Chromebook からログインして使う常時上げとく端末が欲しいとか、GCP の機能を実験したいとか、そういうアドホックな用途にはどういうプロジェクトを持つのが良いのか。
今は sandbox という名前の project があり、これを使いまわそうとしている。実験と生活に使うVMのprojectを混ぜるのはやや気持ちがわるい。一方で実害はない気もするし、細かく分けると gcloud コマンドが不便になる。やはり当面は sandbox 一本で行こうかな。
AWS にない概念があると迷うのは AWS がよくできているからなのか自分が GCP native でないからなのか。特に GCP native になりたいわけではないけれど、どうせ使うなら正しい使い方が知りたいもんです。
Chromebook がサボり端末化しつつあるので、生産的たるべくコードも書けるようにしたいとブラウザベースのオンライン開発環境を試したが満足いくものはなかった。参考にしたリンク。
ゴールとしては、ちょっとしたコードを書きたい。たとえば今じぶんは Programming in Haskell を読んでいる。これを写経したり章末問題を解いたりしたい。あとはその他の新参言語で Euler を解いたり、Repl で知らない機能を試したりしたい。そういうカジュアル小規模コーディングが目的。
Koding. Vagrant みたいな provisioning をやってくれる。そして provision した VM に対するファイルブラウザ、ターミナル、エディタを提供する。エディタは Ace をつかっている。
全体に設定が柔軟なのはよい。プロビジョンのスクリプトを自分で書ける。VM も好きなクラウド業者に置ける。たとえば自分なら GCP を使いたいとして、GCP が普通にサポートされているしインスタンスタイプなども選べる。ユーザが GCP project の service account を Koding 用につくってあげて、Koding はそれで API を叩く。ファイルブラウザも便利。欠点としては、遅い。Ace はいまいち。Haskell の syntax highlighting もない。
Codenvy. Koding と似てるけど、融通が効かない。エディタは Eclipse Che. たぶん以前 Orion と呼ばれていたもの。HTML 断片を除くと Orion の文字がちらちらと見える。Haskell サポートはナシ。Koding と比べ利点を見いだせず。
Codeanywhere. コードを編集するのだけに特化している。いちおうコンテナの中でテストを動かしたりはできるっぽい。Code Mirror ベースのエディタ。Haskell の syntax highlighting あり。コードの置き場は様々なバックエンドが使えて、VM から SFTP でひっぱってきたりもできる。
理論的には良いかんじだが、バックエンドとつなぐ Connector がまったく動作しない。ためしに使ってみた Github バックエンドと Google Drive バックエンドどちらも動かず。バグにしてもひどすぎじゃね？
Ideone. もう IDE はいらないからこのくらいでいい...んだけど広告があまりに邪魔。金払って消せないかなあ。あと書いたものが手元に残らないのはやや寂しい。Ideone.com で見えるんだけど。
理想的には VS Code がブラウザで動けば良い。そういえば VS Code の Monaco エディタを生み出した VS Online はどうなったのか。調べたところ今は VS Team ServicesVS Team Services と名前を変え、IDE としての機能はなくなったらしい。
なお Cloud 9 は以前試し済み。だいたい Koding や Codenvy みたいなもんだったと記憶。
Web IDE は総じて遅いのがまず辛い。ARM Chromebook の遅さに輪がかかってしまう。そして自分のようなマイナー言語のおためしや小さいスニペットを書きたいだけの人に IDE は overkill すぎる。どのみち IDE 支援の弱い言語ばかり。ただまともなエディタとターミナルがあればいいんだよ。ターミナルで Vi だの Emacs だのを使いたくないだけなんだよ...
よい代替案を模索中。Chromebook を諦めろという結論なのかもしれないけど。
Dropbox Paper のドキュメントは、デフォルトの設定だと URL がわかれば誰にでも中身が見えてしまう。これ referrer その他でうっかり URL が漏れたのに気づかなかったら大惨事なのでは。自分は Paper で個人の journal をつけているのだが、これがダダ漏れだったかもしれないと思うとぞっとする。そのデフォルトはないだろう・・・。そしてデフォルト設定は変更できない。文書毎に設定が必要。
むかし社内の Google Docs はデフォルトの可視性が全社公開だった。これはなかなか透明性が高くてよかったのだけれど、本来透明であるべきでないものがうっかり可視になっているトラブルが続出し、世間と同じ設定になった。設定変更に反対し opt-out する人々もいたと記憶しているが、記憶間違いかもしれない。
それ以来、逆に回覧されてくる design doc などのパーミッションを自分が持っていなくて読めないことが増えた。自分はもともとの透明性は好きだったので、今でもチームに共有する文書は全社公開の設定にしている。誰も見ないと思うけど、そういうことじゃないのだよ。
そんな話を思い出した。
とにかく Paper のデフォルトパーミッションはやばい。
しばらく前から Nuzzel というサイト/アプリを使っている。適当な Twitter アカウントを登録すると、フォローしている人のシェアしたニュース記事をまとめて表示してくれる。この手のアプリは他にも色々あると思う。Nuzzel にはウェブの他に (たいして出来の良くない) Android アプリと毎日のメール配信がある。自分は主にメールを見ている。
使い始めたきっかけは「ニュースはソーシャル経由で集める時代だよねーブックマークサイトのトップページを見る時代じゃないよねー」的なことを誰かが言っていたこと。ML 関係のニュースを読みたかったのときにその発言を思い出して Nuzzel を試した。たしかにトップページ的なやつで ML 関係のニュースを集めるのはやや分が悪い。HN にはあまり上がってこないし、 r/machinelearning もいまいち玉石で質がわからない。そこでどこかから ML 有名人の Twitter アカウントリストみたいのをみつけてきて、それを follow する新しい Twitter アカウントを作って Nuzzel に登録した。ついでに ML 以外のプログラミング系アカウントも適当に足した。
結果。まあまあ良い。自分はどのみち ML 素人なので、論文を読めないことがボトルネック。だからニュース取りこぼしで困ることはなくなったと思う。なお自分のフォローしているような news junkie の researcher たちの一部は arxiv-sanity のようなサイトを使っている模様。
残念だったこと。T 大統領のニュース多すぎ。特に "friends of friends" という 2-hop のアカウントから流れてくるニュースを集約したページはほとんど T 関係のニュースしかない。少し前に NYTimes の記者が 「大統領ニュースを無視しようとしたけど無理だったわ」みたいな記事を書いていた。これか・・・。お前らがシェアするからつけあがるんじゃねーか！と思ってしまう。気持ちはわかりますけどね。アメリカのソーシャルメディアの汚染されっぷりが今更ながらわかった。
ところで自分が Nuzzel を使うきっかけになった発言をしたのはたぶん Naoya Ito 氏だったと思うのだけれど、いま Twitter アカウントをみたら protected になっていた。Twitter のような broadcasting social media の時代も終わろうとしてるのかなと、うっすらおもう。
ベイズ統計の本を読むとだいたい最初の方に Monty Hall Problem というのが出て来る。自分も最初これを直感的に納得することができなかったが、そのあと扉 3 つでなく 100 個くらいで考えると割と納得できるようになった。
テレビ特番の屋外セット。目の前に 100 個の扉がある。そのうち一つにはあたりの景品 (Tesla) が, 残りの 99 の扉の後ろにはハズレの動物(Alpaca)が隠れている。鳴き声が煩い。
参加者である自分は 100 個の扉の中から一つを選ぶ。司会者が指を鳴らすと、自分の選んだ扉とあと一つ以外の 98 の扉が一気に開く。98 匹の alpaca が一斉に走り出し、自分のそばを駆け抜けていく。上空からはテレビ局のヘリがその様子を録画している。司会者は言う。いまならもう一つの扉を選んでもいいですよ。
扉の後ろの部屋には屋根がない。ヘリのカメラからは部屋の中が丸見えだ。Tesla の部屋と自分の選んだ部屋以外の扉が開き、参加者と自分の背後にいる alpaca 飼いのかざす餌にむかって alpaca たちが駆けていく様を広角のレンズが捉える。この上空の視点からみると、自分が司会の誘いに乗らないのはすごく馬鹿げたことに思える。1/100 の確率が一気に Tesla の扉に収束していくのが手に取るようにわかる。だって Tesla の扉(と自分が適当に選んだ扉)だけが閉じてるんだもの。もちろん自分の選んだ扉の後ろに Tesla がある確率もゼロじゃないけれど 1/100 だからねえ。どう見てももう一つの扉の後ろにあるでしょ。Tesla.
ソフトウェアだと数の少ないケースで考えると納得できるものが多いけれど、確率とかは極端な数で考えるとわかりやすいこともある、のかもしれない。ちなみに Tesla は特にほしくない。
野菜不足を感じたため、少し前から食事の野菜を増やそうとしている。
今までの野菜摂取は週末に作り置きしたおかずからが大半だった。けれど作り置ける料理は限りがある。種類も、調理の時間も。なので食べるその日に作るか、作った日と翌日の二回くらいにわけてたべる野菜が欲しい。そして平日にささっとつくれる調理の簡素なものがよい。
と考えた末、今は大きく３つのジャンルに手を広げてみている。
一つ目は浅漬け。きゅうり、大根、人参、白菜、セロリなど。適当に塩を降って ziplock にいれる。作って 2-3 日で食べきる感じ。塩だけだと物足りないので「ほんだし」や顆粒の鶏がらスープなどを混ぜてスナックっぽい味にする。あとは生姜を刻んで混ぜたり、ガーリックパウダーを振ったり、醤油やごま油を垂らしたり。割と良い。白ごはん.com のレシピをもとに改変して食べてる。
二つ目は茹で野菜の和物。チンゲンサイやサヤエンドウを茹で、かつおぶしと醤油を和えてたべるだけ。あとは秘蔵の出汁殻ふりかけがあるのでそれをかけたりとか。当日と翌日の２日で消化するかんじ。これも一瞬で作れて良い。味付けはもう一捻りしたい気もする。
３つめは炒めもの。チンゲンサイ、サヤエンドウ、パプリカ、ブロッコリなどを単品で炒める。油にニンニクや花椒をいれて香りを出し、炒めたら塩コショウ。気が向いたらオイスターソース。あとは鶏がらスープと片栗粉を水に溶いてからめたりとか。これは上の二つより一手間ふえるけれど、まあ中華鍋で炒めるは好きなので許容範囲。炒め物についてはウー・ウェンの教科書から学ぶことが多かった。最近はガーリックオイルを作り置いている。
あと生姜焼きなど marinated pork/beef を焼くときは上の炒め物野菜とあわせて炒めたり、麻婆豆腐にどさくさで人参を入れたりと、肉を食べるときは強引に野菜を足す。
といったかんじにして野菜摂取量が増えた。気がする。少なくとも週末の買い物の量は増え、バッグを買い足した。
現実逃避のアプリ開発も一段落し、育児休暇ももうすぐ終わる。そろそろ NN のお勉強トラックに復帰したい。が、間が二ヶ月以上ブランクがあったせいか、もう全然覚えてない。のみならず、難しい問題や数式に挑んでいく勢いがどこかに行ってしまった。休みボケ。
この失速は鬱病の初期症状みたいなもので、えいっと作業を始めれば治るのかもしれない。そう期待してぼちぼち作業をはじめたい。といっても休み前の時点からはじめるのはムリそう。何歩か巻き戻し、気分転換にひねりを加えて着手でき・・・ればいいなあ。
NN や機械学習は自分の苦手なものの集合体なので、いまいち腰が重い。でも苦手を克服していかないと前に進めないのだった。しんどいのも仕方なし。
Attachment Parenting という子育ての流派があるらしい。名前から想像すると「子供はちゃんと可愛がりましょうね」みたいな曖昧な主張を想像するけれど実際はもっと具体的。ざっくりいうと 1. 子供は一日中だっこひもでだっこしましょう (Babywearing) 2. 子供がぐずったらすかさず乳をやりましょう, 子供が自分で決めるまで卒乳はやめましょう. 3. 子供と一緒に寝ましょう (co-sleeping). 割と強い主張で、共働きだと全然無理. Attachment Parenting を提唱したのは Dr. Sears という人が 1992 に出した本. ウェブで育児情報を検索するとよく askdrsears.com というサイトがひっかかるのだけれど, Attachment Parenting のひとだったのか… Dr. Sears そのひとについては 2012 年の TIME の記事が詳しい。
Attachment Parenting に対しては非科学的だとか母親が理不尽に大変といった批判がある. ざっと読んだ範囲だと Attachment parenting: the best way to raise a child – or maternal masochism? という The Guardian の記事が自分の感覚に一番近かった. 一方で How the Attachment-Parenting Debate Ignores Women of Color という The Daily Beast の記事は, 欧米以外だと attachment parenting 風子育てが普通な国はいっぱいあるのに今更ラベルをつけて良いだの悪いだの人の子育てのやりかたに口を挟まれるとむかつく、やりたいようにやらせろ、と African American の著者が主張している。まあ日本も co-sleeping が普通だよな。住宅事情のせいな気もするけど。
Attachment Parenting は「非直感的な」近代 US 子育てに対する反発だという見方もある。たとえば Sleep Training は広く知られたプラクティスだけれど、その流派の中には Extinction/Cry-it-out といって一旦子供を crib におろしたら泣いても朝までほっとけと主張する人もいる。(自分は sleep training に興味があったので代表的な本を一冊読んだ.) NYT Upshot のある記事は sleep training はどの方法もそれなりに効果があり今のところ害はみられないとしている。一方で Attachment parenting の信奉者は Extinction 系 sleep training を強く攻撃している。Upshot の記事のコメント欄にもそういう人たちがいっぱい。子育てにありがちなもめる話題の一つだとわかる。
自分は sleep training はまあまあ信じているけれども、一方で Attachment Parenting は Formula feeding への反発でもあるというから厄介。アメリカ、一世代前までは母乳より粉ミルクのほうが良いと信じられていて、母乳が主流になったのは割と最近(といっても 10-20 年とか)のことらしいからね。そういう意味で Attachment parenting は無闇にクラシックなわけではない。更に厄介なのは Attachment Parenting を包含する Natural Parenting という派閥があり、この人たちは vaccination にも反対しているらしい。たびたび目にする最近ワクチン接種率が下がっててやばいという話、まさかこんなところで繋がるとは。他人の子育ての方針にとやかくいいたくはないけれど、これはちょっとなあ。なお件の Dr. Sears はちゃんと vaccination していた...が遅らせろともいってるらしい…
あまりこの辺の議論に engage して消耗したくないと思いつつ、怖いもの見たさでつい色々読んでしまうのだった。
WebView のダメさというのは広く語られて久しいが、自分も仕事でさわった WebView を通じて理解が深まった。周回遅れは承知で記録しておく。なお自分の仕事アプリは電子書籍リーダであり電子書籍の標準フォーマットは HTML なので WebView を使うのは仕方ない。以下は仕事に文句を言ってるわけではない。
モバイル向けのサービスを作りにあたり、数年前まではアプリを WebView で実装しようとする人々がいた。そして滅びた。彼らは Web テクノロジのダメさを非難したけれど、Web のダメさは理由の半分くらいだと思う。残りの半分は WebView のダメさではないか。少なくとも Android では。
Android の WebView は Web と Android のダメなところを集めた代物といえる。
まず WebView は View のサブクラスなので Activity のライフサイクルに引きずられて作られたり破棄されたりする。しかし WebView の中からライフサイクルイベントを知ることはできないし状態も直列化されない。結果としてライフサイクルが切り替わるたびにページが再構築される。状態がふっとんでしまうし、遅い。様々なものが View の寿命にひきずられるのはほんとにキツイ。ライフサイクルの遷移による WebView の再構築はウェブページのリロード相当ではない。どちらかというとブラウザの再起動みたいなもの。レンダリングエンジンの使う OS の資源は一旦破棄したあと確保しなおされる。キャッシュも全部消える。超遅い。
同じモバイルでも WebView でなくブラウザのウェブならこうした問題はおきない。ブラウザはページを Service にホストするため Activity ライフサイクルの影響を受けない。仮にブラウザが背後のタブにいるページを一旦 purge したとしてもブラウザ本体は生き続けている。だからタブの開き直しは WebView つくりなおしより速い。
画面の描画もきびしい。最近の WebView は別スレッドの GL でページを書いて結果を SurfaceView としてアプリ本体の View ツリーに composite するけれど、メインスレッドを自分でもっていないせいでブラウザがやっている小細工がまったくできない。遅い。
スレッドといえば、アプリのスレッドと WebView のスレッドがわかれておりイベントループが二つあるのもつらい。普通の WebView のユースケースでウェブのイベントループとアプリのイベントループを混ぜたくないのはわかる。ランダムなウェブサイトの遅さがアプリを止めてしまうから。でもその理不尽な環境下にある WebView を主体としてアプリをつくるとか、無理でしょ。
このスレッドモデルのせいで WebView と Java のブリッジコールは超遅い。ブリッジは WebView のスレッドでもなくメインループでもない謎のスレッドで呼ばれる。スレッドホップが挟まるせいで JS が 1ms 近く止まってしまう。しかもブロッキングせずに ブリッジを呼ぶ方法がない。最近は postMessage() できるようになったけど。いずれにせよ JS の世界と Java の世界は大きく隔たっている。これは Node を自由に使える Electron とはだいぶ違うし、ActiveX の使えた Windows の IE component よりもしょぼい。
こういう技術的な問題のせいで WebView ベースのアプリは Android の力をまったく引き出せない。そのくせウェブのよさも全部捨ててしまっている。ブラウザの資源を使えない。URL もない。Hyperlink もない。柔軟なデプロイもできない。検索エンジンからもソーシャルメディアからも traffic を呼び込めない。そりゃダメだろ・・・
今となってはブラウザもマシになったし JS で書きたいだけなら React Native もある。WebView で頑張ろうとする人はいない。だからこの話は歴史的な回顧でしかない。Lesson Learned があるとすれば何か。Web やその他のテクノロジをプレットホーム抽象化レイヤとして使ってはいけないということだろう。Web の良さはプラットフォーム中立であること（だけ）ではない。Web は Web というプラットホームであり、独立したプラットホームとしての良さがある。その力を引き出さないと良いものは作れない。WebView はそれを反例として示した。
電気圧力鍋の Instant Pot を買った。前から圧力鍋が欲しいと思いつつ買いそびれていたところ、NYTimes と HN で立て続けに記事を見かけ背中を押された。
調理時間の節約を謳っているが、けっこうトリッキー。レシピに載っている実際の加圧時間の他に加圧前の preheat が 10-15 分, 加圧後の減圧が 10-30 分かかる。だからオーバーヘッドが 20-45 分ある。加圧本体も 10-60 分くらいあるから、合計で一時間以上はかかる。短い時間で調理する道具ではない。
一方、この 1 時間のあいだ見張りは必要ない。放っておけばいい。だから他の調理があるときは Instant Pot の待ちをオーバーラップさせ時間を償却できる。週末のバッチ調理にあわせて使うにはもってこいの道具といえる。
オーバーヘッドがでかい一方鍋のサイズも大きいため大量に作るのに向いている。ただ保存がきく料理でないと大量に作っても嬉しくない。カレーやシチュー、角煮やゆで豚なんかはよい。食べきり前提の one-pot dish みたいなレシピを見かけるものの、上記の特性をいかせないので自分としてはいまいち。
圧力鍋だと他で得られない料理が作れる。しかも電動で失敗しづらい。その感動がカルト感につながっているのだろう。待ち時間は長いけど手はかからないでかい鍋という特性を活かしつつ使っていきたいもんです。とかいってレシピの調査に延々と時間をつかっている。そろそろ切り上げねば・・・
Kotlin で Android アプリを書くのは結構たのしい。
Kotlin は Scala ほどではないにせよ十分にモダンなので書く楽しさがあるし、自分の欲しいアプリが自分で作れるのも良い。Web の時代、自分はまともな職業 Web プログラマだったことがなかったせいでウェブアプリを作るのは一苦労だった。Android は一応仕事でやってるのでまあまあラクというか、作業していてそれなりに confidence がある。こういう状態で余暇のコードが書けるのはたのしい。
でも余暇で Android をやることはもうしばらくないだろう。他にやることがある。決めていたことだけれど、今となってはちょっと残念。
仕事での立場が下っ端すぎるせいもあり、今の自分は Android プログラマを名乗るにはだいぶ未熟。でもあと 1-2 年仕事と業務外で Android をみっちりやればまあまあまともな Android プログラマになれると思う。けれども 1-2 年後に良い Android プログラマでいるために他のことを犠牲にできない。時間や体力が十分にあって他と Android の両方を追えればよいのだけれど、それは現実的でない。
だから自分は生半可な能力のまま Android プログラマとしてのキャリアを終えるだろう。仕事でやっている技術に習熟できないのは悲しい。けれど時節柄その技術に深入りできない。自分のスキルセットを周回遅れにした代償。StackOverflow によれば 2016 年の Android 技術者の需要は Cloud と iOS についで三番目の需要過多。モバイル開発者の需要ギャップは今がピーク。この瞬間に良い Android プログラマでいることができたら、色々楽しいこともあったのかもしれない。数年遅かった。ふと higepon が iOS アプリ開発に精を出していた時期を調べてみると 2013 あたり。これがタイムリーってものだな。
もともと自分はモバイルが好きでなかった。今も強い情熱はない。そのせいで出遅れた面もある。それにさほど流行り廃りを気にする方でもなかった。メインストリーム全般に対する漠然とした不信感は今もある。でも周回遅れの年寄り外国人になってしまった今、そんなより好みをする贅沢が許されるようには感じられない。やるべきことにやりたいことが追い出されるのはちょっと悲しい。でも仕方ないね。
二年前に Android の勉強がてらつくったまま存在を忘れていた自分のデビュー作アプリ Hiccup, いまふと developer console をみると総インストール数 400, アクティブデバイスへのインストールが 15 となっていた。そしてレビューが２件ついていた...
アプリがゴミであることを考えると結構多い。サーチしてもこのアプリにたどり着くのはかなり困難なはずだが、一体どうやって発見したんだろうな。これが二年という年月の力なのか。
一方で自分がむかし作ったウェブサイト, たとえば gisted.in とか、一切 analytics とってないけど誰も使ってないと思うんだよね。(とおもったら GA が入っていた。そしてやはりユーザはいなかった。）2015 というのは趣味の Android アプリを出すにはまだ遅すぎない時期だったのかもしれない。今はもう Apple の App Store みたいな勢いで血の海のような気がする。
その数少ないユーザたちはヨーロッパ、中東、東南アジアにいるらしい。無駄に Next Billion にリーチしていた。ははは・・・。
なおこの Hiccup というオーディオプレイヤ、巻き戻しをラクにするアイデアはわるくなかったと思うけど使う API の選定を間違えたせいでやたら buggy, かつオーディオデータを自分の在庫 (Play Music) から取り出すのが大変なためあまり実用にならなかったのだった。残念。アルバムとかプレイリストみたいのを真面目に作らないと使い物にならないと思うので、作り直すこともないでしょう。
なんとなく landing page というか Play Store からリンクするサイトがあった方がいいかな、と思い Wordpress で作ってみた。
最初は Hugo あたりでやろうかとおもったけれど、テンプレートの種類と質、あと単純に運用のラクさを考えて Wordpress にしておく。無料枠だと自分のドメインをあてられないのが玉に瑕だけど、アプリドメインつきのサイトをつくるほどの力作じゃないのでいいでしょ・・・。
これソーシャルメディアなどに流すときは Play Store の URL とおの landing page の URL, どっちを流すのがいいのかね。エゴは landing page を流せと言ってくるが、インストールしてくれる可能性を考えたら Play Store を流す方が親切ってもんだよな。というわけで Play Store のリンクを流すことにする。ただしエゴ目的で stats をとれる bit.ly を挟んでおく。
結果として landing page は Play Store からリンクされているだけ。意味ねえー。最初は日本語の landing page も作ろうかと思ったけどめんどくさいのでやめ、アプリ自体と Play Store の listing だけ日本語も用意しておく。
Landing page というのは Echo Fairy よりもうちょっと手間のかかった力作を作った人がやることだと学ぶ。
Crash reporting と簡単な analytics のために入れてみる。いれるだけならすごい簡単で感心。
特に API key の扱いがよくできている。コンソールから google-services.json というファイルをダウンロードしてきて、それをアプリコードのディレクトリに置く。そして build.gradle で Firebase の plugin を有効にする。するとあら不思議、自分のコードには API キーだのなんだのを入れなくてもなんとなくgoogle-services.json の値が使われる。なのでこの JSON ファイルを .gitignore しておけばうっかりキーを git の履歴などにいれてしまう心配がない。
プラグインはどうやってこのなんとなくを実現しているのか。build/ 以下の生成物を覗くと app/build/generated/res/google-services/debug/values/values.xml というファイルがあり、API キーが埋め込まれていた。つまりリソースを生成していた。妥当。
Firebase 概ねいいやつなんだけど、データベースの値段が高いよなあ。リアルタイムじゃなくていいから Datastore くらいの価格付けにしてほしい・・・と pricing のページをみていて気づいた: 無料枠では Analytics データへの BigQuery は使えない！それがキラー機能なのに。残念・・・まあ query が必要なほど使われる気はしないけれど。
色々直した結果けっこう使えるようになってきた Echo Fairy, せっかくなのでアイコンを作ってあげることにした。
当然こんな絵を自分でかけるわけがない。元ネタは絵文字。具体的には Twemoji の Angel とMaterial Icons の Mic を SVG でダウンロードし、Inkscape で適当に掛けあわせた。
絵文字からアイコンをつくるのは、余暇の自分用アプリ向けなら割と手頃な気がする。CSS でとりあえず Bootstrap を使うのと同じノリで。編集しやすい SVG で素材が手に入る、良い時代であることよ。
なお、まだ様々な設定項目がハードコードされているため Play Store に載せられる品質からは程遠い。そろそろ設定画面を作らないとなあ・・・。
休暇に入る少し前、自分のチームの TL が「アプリの MTTF 取りたいなー」とバグをファイルした。すでに集めているメトリクスから適当に計算できるのでは、という期待があったようだけれど、ちょっと考えてみるとまあ無理。というか Android アプリの MTTF はどう計算すればいいのだろうか。
Android の文脈を離れると、MTTF はクラッシュ間隔の平均値を取れば良い。そして Play Services のようなシステムに近いサービスやメッセージングやチャットみたいなほぼ常駐する性質のアプリならこの計算方法で意味がある。けれどたとえば一日一回くらい起動してコンテンツを眺めるようなのアプリだと、単純にクラッシュ間隔を求めても仕方ない。
そこでまずアプリが前面にいるときの時間を記録しておくことにした。そして前回のクラッシュから次のクラッシュまでどれだけ前面にいたかを TTF, time-to-failure とみなす。この指標は悪くない。ユーザからみてどれだけ頻繁にクラッシュするかを表した指標だから。
けれど細かいところに疑問はのこる。具体的には sync など何らかのバックグランド処理中、画面を見せていないときにおきたクラッシュはどう扱うべきか。ユーザの体感クラッシュ頻度という観点だけを考えると、これら background crash は無視してよい。けれどアプリの安定性を気にするならこの crash も指標に加えてあげたい。
そこで厳しい側に倒すべく、バックグラウンドだろうがなんだろうがクラッシュのタイミングで TTF を計上することにしてみる。もし background crash がおきたら、前回の crash からその時点までの foreground 時間の合計を計上する。この方法の問題は、画面を表示することなく二回つづけて background crash がおきると二回目の crash の TTF がゼロになってしまうこと。厳しすぎじゃね？
とはいえ厳しい側に倒す方針なのでまずはこれでよい。厳し目に計算した MTTF をモニタリングしておき、値が下がったら詳しくデータを調べればいいから。そうした breakdown につかうべく TTF event の付加情報として crash した時点でアプリが前面にいたかどうかの状態も送っておく。
というかんじで MTTF が計算できるようになった。のだけれど、休暇に入ってしまったので出荷されたコードがほんとに正しく動いてるかどうかはまだ調べてない。
ELK Developer 募集中だよーという求人スパムが来た。
検索してみると ELK とは Elasticsearch + Kibana のことらしい。Elasticsearch 流行ってるなあ。今や Mongo より目にすることが多い気がする。まあ MongoDB 簡単なので世の中には Mongo の専門家って殆どいなそうだけど。それは良いことでもある。
詳しくなる日は間違いなく来ないが、それでもなんとなく一回くらいは触ってみたい気もする Elasticsearch。余暇で触ってみるならなにをするのがいいのかねえ。というのを考えるより、まず EC2/GCE あたりで Hello world してみるべきか。登録しとこう。
なにすればいいのかね。検索エンジンでもつくるの？
第一子生誕後一ヶ月は完全に iKnow をさぼっており負債というか要復習語が 500 以上たまっていた、のを、ようやく返済。復習モードだけだと新単語を混ぜた場合の倍くらいの速度で消化できるので案外といえばラクだった。ただし失われたリズムを取り返す苦労は多少ある。
最近は Chromebook Plus で iKnow している。タイプできるのでスマホよりこっちの方が速い。一時期からモバイル慣れの一環としてスマホに移行してたけど、文字入力とかキーボードある方がいいわ、と諦めた。
育児休暇中の息抜きにボイスレコーダーのアプリを書いている。
最初のコミットから一ヶ月くらい経ったこの頃、ようやく dogfood できるようになってきた。たぶん本気の Android プログラマだったら三日くらいでできる仕事なのだけれど、まあ実力がないので時間がかかるのだった。x1/10 プログラマってかんじか・・・。
目的としては、英語の音読や音声教材の repeating などで自分の発声を聞きたい。しかもすぐに聞きたい。そして繰り返し同じフレーズを練習したりしたい。
そこでアプリの起動中ずっとマイクから音を拾い、なにか喋ったぽい塊を検出して喋り終わったら（静音区間があったら）その喋ったぽい塊の音声を即座に再生するコードを書いた。つまり声が始まったら録音を初めて、声が終わったら録音を終えて、その場ですぐ再生する。
UI をどうしたものかと考えてた結果、かっこいい画面を作れる技能もないし操作の必要も少ないから画面はナシで notification にだけ常駐すればいいかな、という気がしてきた。オーディオ系のアプリってだいたい notification としてミニコントロールが出てくるけど、そこだけあるかんじ。草葉の影でコダマをささやくので Echo Fairy と命名。
試してみると静音区間の判定や UI の工夫がまだまだ必要とわかった。でも常駐してエコーしてくれる挙動自体は悪くない気がする。しばらく手直ししつつ使ってみたい。
なお自分の発音がどうだったかというと、やばい。予期していたこととはいえ、こりゃ聞き取れんわ。同僚たちすまぬ。
もう一つの発見としては、自分の声を聞いてダメとわかっても正しい発音に近づける方法がわからないということ。まずは発音の教材を Echo Fairy と共にやり直そうかな。
買い物の帰り、police に pull over され焦る。なにかと思ったら left brake light が切れていた。直せという旨の切符を切られる。切符初体験。世の中どうみても半損して色々動かなそうな車が走っているのをよくみかける。あいつらはいいのか？それともそうしたボロ車はずっとボロいわけではなく修理前なだけなのだろうか。なぞ。単に切符を切られ続けているのかもしれないが。
近所の車用品屋で bulb と wrench を買って交換、市の police departments に切符を持ち込み、修理したところをみせ署名をしてもらう。そのうち court から手紙が来るのでそれに切符をつけ返信するように、とのこと。あれ、切符を着られたときはその場で封筒を貰えると言われたのに・・・。ガイドを読むと別に手紙を待つ必要はなさそうだが、一方で宛先もわからん・・・。
なにしろこの面倒の発生が休暇中でよかった。
そして wrench のサイズを買い間違え、世の中の socket には SAE と Metrics 二種類の系統があると知る。SAE はインチ、Metrics は...名前の通り。自分たちは日本車所持につき Metric の wrench が必要。インチなんてアメリカしか使わねーんだよ！とひさびさの American moment.
追記
その後チケットやオンラインの指示にを読み解き police signature のはいった ticket を court に送ったのだが、それは完全に無視されて二ヶ月後の本日 (May, 5th) に金払えという手紙がきた。直した証拠があれば $25, なければ $197. 証拠の書類は送ってしまったのでもう手元にない。理不尽すぎる…が、他の選択肢はないのでおとなしく $197 支払い。
これはうかつ税なのか、学習料なのか・・・。Ticket を切った police のいうことは間違いで signature をくれた police の言うことが正しかったということだよなあ。なんとなく「待つ」という選択肢は問題を先送りしている気がしてなんとかアクションしたのが裏目に出た。次にチケット切られたらおとなしく court letter を待ちます。はー $197...
せっかく渡米三年たったしなんか書こうと思ったがいまいち書けない。それがなぜかを考える。いい歳なのにまだ自意識過剰なのだろう。
自分はベイエリアなどに住む一部プログラマたちの底抜けな楽観や強気さが苦手だ。この地はプログラマをやるにはたしかに結構いいとこだけど、心配事もある。国をまたぐのは大変な人には大変だから無闇に勧める気になれない。エリートのみなさまにはわからないでしょうけどね・・・などと卑屈な気分が頭をもたげる。
一方でシリコンバレー家賃高くて大変なんでしょ給料も額面だけのハッタリなんでしょ、みたいな斜に構えた声も勤務先を馬鹿にされているようで腹がたつ。おまえら企業が儲かってるってことがどういうことかわかってんのか、と高圧的に言い返したくなる。とはいえたかが平社員が給料で声を荒げるのもみっともない。いつまで景気がいいかもわからないし、それに格差の国で給料の話なんて一般化できないじゃん。
こういう bipolar な framing は他にも色々ある。乗るにせよ反るにせよ、それらにひっかかってつまらないステレオタイプに巻き込まれたくない。語られていないことも色々あるから、ほんとはそういう話ができたらいいのにと思う。たとえば外国で暮らす寂しさや不安、気楽さや高まりというのは、金銭的な話以上に日々の気分に影響していると思うのだけれど、あまり語られていないように見える。まあ逆に古典的でベタ過ぎるのかもしれないけれども。
自分は bay area advocate にも critic にもなりたくない。日々の暮らしをどう感じているかみたいな個人的な話がしたいだけだ。でも謎の自意識に邪魔されてうまく言えない。ベイエリア日本人なんて別に珍しいものでもないんだし、気にしなければいいんだけれど。
あるいは、自分はただ雑さに負けているのだろうか。人生楽しいこともあるし大変なこともある。それを三年分まとめて書こうとするから平滑化されてつまらなくなる。日々を少しずつ、小さな主語で書いていく丁寧さが必要なのかもしれない。
来た。ので手元の書きかけ Kotlin コードをちょっと書き換えてみる。ただ async/await はまだちゃんと調べてないので後回し。type alias と bound callable references はすぐ使えて良い。
Bound callable reference, 便利だけどいよいよ currying 的なことがしたくなる。このへんの高階関数の扱いは Scala の方がいいなあ。JS ですら bind があるというのに...他はそんなに不満ないのだが。
結局 async/await というか Coroutine の資料も読んだ。この入門的な記事を読み、次に適当にコードを参照しつつ詳しいバージョンを読み、最後に高位の API の説明を冷やかせばだいたいわかると思う。Kotlin は最近の言語に漏れず API リファレンスから GitHub のコードに飛べるのが便利だね。
Python の generator/coroutine をなんとなくわかってるという自分の理解からみた要点:
- 一番下にあるプリミティブは suspend キーワード, Continuation インターフェイスと suspendCoroutine() 関数。suspend キーワードのついた関数は、匿名クラスの Coroutine と、それを呼び出すスタブのメソッドを生成する。Coroutine の匿名クラスは Continuation インターフェイスを実装している。suspendCoroutine() を使うと、suspend 関数の中から自分自身の coroutine オブジェクトに (Continuation インターフェイスを介して) アクセスできる。このオブジェクトを非同期な API のコールバックから呼び出して継続する。
- Python の generator は suspend するたびに値を返せるが、Kotlin の Coroutine は最後に一つだけ値を返す。途中の suspend では値を返さない。buildSequence() などは generator みたいなもんだけど、これは coroutine のプリミティブの上でライブラリとして実装されている。
- Python の generator 関数は generator を返すが, Kotlin の suspend 関数は何も返さない。かわりに暗黙の引数として Continuation オブジェクトを渡す。CPS スタイルってそういえばこういうかんじだったかもしらん。
第一印象。Python と比べると、後出しだけあって Kotlin の方がだいぶいいと感じる。整然としており、ドキュメントを 2,3 種類読んだだけで概要を把握できる。 Python の generator/coroutine はいくつ資料をよんでもなんとなくしかわからない。そしてそれは自分だけではないっぽい。
整然としているのは、まず JVM が変化せずコンパイラの力だけでがんばっているぶんレイヤリングがうまくできているおかげ。これは C# や JS もそうかな。コンパイラが生成するコードをなんとなく理解できれば一番下のレイヤがわかる。Python はインタプリタを拡張して色々やっているせいでシステムとして理解するのが辛い。
レイヤリングという点で、コンパイラの仕事や言語本体の拡張が割と小さいのも良い。Continuation インターフェイス、suspend キーワード、suspendContinuation() instrisics 関数。プリミティブはほぼこれだけで、あとはライブラリ。わかりやすい。他の言語はもうちょっといろいろ言語本体に入ってしまってるよね。たとえば JS の async/await は Promise とくっついている。
型が静的なのも良い。Python はある関数が generator かどうかを混同しがちで辛かった。動的型というのはそういうものだけれど、実行時にしかわからないバグの原因が増えると動的型でがんばるの段々辛くなっていく。Kotlin は suspend 関数を間違ったコンテクストで呼ぶことはできないので安心。
Java 資産との乖離が心配だったけれど, ライブラリの API が RxJava など限られた非同期フレームワークに集約されている限りは RxJava と coroutine の interop を使えるので割と大丈夫なかんじ。ハードコア Kotlin プログラマは coroutine をばりばりつかったライブラリとかを作りたいだろうけれど、ライブラリは Java と Rx にしておきアプリのレイヤでだけ coroutine をつかうくらいが無難な気がする。
Kotlin 1.1 ではまた experimental というから様子見。そのうち思い出したにはいいかんじに普及していることでしょう。
数年に一度おこる発作の一つとして Haskell でも入門すっか・・・と VS Code の haskell mode である Haskelly の説明を読んでいたら、Haskell の distribution として Haskell Stack なるものに依存していた。読んでいる入門書には Haskell Platform を使えと書いてあるのだが。
Haskell Stack は 2015 年に登場した新顔で、だいたい Haskell 版 Anaconda みたいなものらしい。開発元は FP Complete という Haskell 愛好家のあつまったコンサル会社。Haskell で devops とかおまえなにいってんだという感じはあれど、それでも自分の愛するテクノロジで食ってる人々には憧れるね。
当然のようにすぱっとは動かず SO の対処法をコピペ。したら動いた。エディタの中で GHCI のシェルが起動できるのはいいかも。
Haskell 入門はいつも道半ばで飽きる。今回は一冊読みきれると良いなあ。
子供がうまれてばたばたしていた先月、家財保険の更新請求が届いて引っ越しから三年経ったと知る。昨日しごとのメールをみていたら入社 7 周年のお知らせが届いていた。そして今朝自宅のメールボックスにグリーンカードが届いていた。晩飯はグリーンカレーの予定。
三年でグリーンカード。さっさと取らせてくれた勤務先の景気には感謝するほかない。引っ越し当初はグリーンカードとったらスタートアップに転職するぜーとか思ってたけれど、今やそんな気分はどこかに行ってしまった。子供がいると金を稼がなねばならず、ボンクラの身で金を稼ぐには大企業で働くくらいしかない。そして今更よその景気のいい大企業に入れてもらえる気がしない。今の仕事が嫌でないのは幸い。
せっかくなので知った顔で何か書いてみたい。とおもって書き出したけれどまとまらない。まあ、概ね元気にやってます。
確定申告の季節。
FedEx には print and go というサービスがあり、メールで送った PDF などを店舗で印刷できる。のだが、サーバにつながらないとかでもう半月くらい機能不全。アホか。
Google Drive からファイルをダウンロードできる機能もある。店舗のプリンタ内蔵ブラウザに Google パスワードを入れるとか超絶セキュアじゃないのでやりたくないのだが背に腹はかえられず使おうとするも、その内蔵ブラウザがリロードを繰り返し auth できない。死ね。
はー・・・とおもいメニューを見ると Dropbox にも対応しているという。仕方なく PDF を Drive から Dropbox にコピーして再びログインを試みる・・・も二段階認証に対応してない。爆発しろ。(追記: 専用の one time password をメールのリンク経由で取得する必要があったらしい。)
はー。この書類、どう印刷したものか。一番合理的なのは USB メモリにコピーして FedEx に出直す、なのはわかっているのだが、このクソシステムの提供者にはもう 1¢ たりとも払いたくないという怒りがある。とりあえず会社のプリンタを拝借するかなあ。
長期的にはプリンタを買いたい気もするが、それはそれで敗北感がある。あんなでかいものを自宅に置きたくない。ペーパーワークのお供につかうモノクロだけの小型プリンタ, cloud print 対応、みたいなのが欲しい・・・。写真とか絶対自宅で印刷しないからねえ。
などと眺めていたら UPS でも印刷できるというので試している。ウェブサイトから PDF をアップロードして会計を済ませ、店頭で受け取るらしい。人間が介入するのがちょっとやだなあ・・・。
もとを辿れば確定申告に紙が介入するのがそもそもむかつくという話もあるのだが、これは色々事情があって仕方ないのだった。
Antirez, the author of Redis, wrote a piece called ”The mythical 10x programmer".
I don't disagree with the list of the characteristics of good programmers, but I've been thinking that the "10x" framing is misleading.
The 10x productivity is often attributed to the speed of the software development. Speed is important, but what really makes one competitive or unique is that he or she, the superior programmer, has done things that are impossible to others. The lightning speed is just one of such impossibilities.
I think that focusing on the extended capability, making impossible possible, is better strategy than just focusing on being faster. Because you can be replaced by cheaper labor if you are just a "speed" programmer and the development speed isn't critical (or isn't considered critical) for that project. Also, you consequently attract projects with tight deadlines. You won't be replaceable if you can do things that cannot be done by other 10 mediocre programmers.
The problem is that, there aren't always such hard problems which can be solved by a few smart people. As a "possibility" programmer, You need hard problems. Some companies know that and lure smarts by advocating hard problems. More often though, you'll have to find such problems by your own.
Another caveat is that, even though I emphasize possibility over speed, many smart programmers prove that the speed is one of the critical foundation of their impossible-looking achievements. In other words, faster programmers tend to solve harder problem. You cannot simply ignore the speed.
Note that Antirez is one of such people who has done an impossible job: Building Redis. From the list it is clear that he knows what 10x really means. He just didn't state it in that way.
I didn't write English sentences at all while I'm off from work, and I feel I'd better exercising some. So here you go. Forgive my slippery text, my Japanese-reading friends.
