自分の勤務先はいまいちこう、小規模でカジュアルな情報共有がやりづらい。Google Apps を使っているので、まあメーリングリストはある。いちおうチャットもある。Docs もある。Sites もある。社内ソーシャルメディアもある。ソースツリーに Markdown をチェックインする文書化インフラもある。Bugtracker もある。しかし。あれがないんだよあれが。Wiki と Blog がつくっついたみたいな、日本の会社は多かれ少なかれ使ってるアレ。Qiita Team, Esa, Kibela とかそういうやつ。なんでないの？
勤務先は融通の聞かない大企業だから仕方ない面はある。しかし英語圏、似たようなツール全然なくね？ グループウェアとか Slack クローンとか Google Docs の亜種は腐るほどあるくせになぜアレっぽいやつはないの？おかしくね。Confluence は違うんだよ！Wiki は違うの！Wiki でも代用できるけどそうじゃないの！もっと時系列とカテゴリーとソーシャルメディアと日報と日記と意見と説明をいいかんじに雑に混ぜたようなそういうやつなの！なんでわかんないのきみたち！！？
と思っていたのだけれど、まあこれはもしかしたら日本語プログラマ圏固有の文化なのかな、と思うようになった。というのも結局こいつらはみな secondlife こと Yuichi Tateno 氏がはてな社やら Cookpad 社やらで内製および製品化したウェブアプリから多かれ少なかれ、そして直接的間接的な形で影響を受けて生まれた親戚みたいなもの。言ってみれば Tateno Culture なのだ・・・と自分は自分は雑に理解している。でも 7 割くらいあってるよね多分。
結局アメリカ製の気の利いた、ものに限らずパクリでもそうだけれど、様々な生産性ツールだって、作り手がキャリアを通じて得た体験や知見から生まれている。そして彼らは誰一人として Yuichi Tateno と一緒に働いていないのである。（たぶん。）残念すぎるが、まあ仕方ないね。日本とアメリカ遠いからね・・・。
自分も 10 年くらい前に日本の会社で働いていたとき、Wiki で似たようなことをしていた。そしてそれは特別なことではなかったと思う。それはなんていうか日本語圏プログラマなウェブピープルの時代の空気で、それも当時はあんまし気にしてなかったけど多分もとをたどれば Yuichi Tateno 周辺カルチャーにたどり着いたのではないだろうか。そして自分が悪態をつきながら渋々 Google Apps を使っている間に、そうした文化は上に挙げたような製品たちに結実していったのだった。やーよかったね。羨ましい。
最近なんとか Google Apps 上で擬似的にそういうことができないかと試行錯誤してるんだけど、いまのところ全然むりなかんじ。自分は thought leader でもないし。
現状のアレらのツールは自分の勤務先のような社員数万人の企業までスケールするようには見えない。でも同じようなものがもし英語圏で流行り、あわよく Unicorn 化したりした暁にはなんらかの形で Google Apps や Office 365 に受け入れたかもしれないし (Slack を見よ)、そうでなくても内製のしょぼいクローンくらいは作られたであろう。
そういうことが起こらなかったのは残念だけれど、どちらかというと固有名詞の正確さはさておき先の Tateno Culture 的な時代精神が花開いていくつものユニークな製品をうみだした素敵な事実を appreciate したいいうはなしです。
上の製品たちが英語圏に展開すればいいのでは、と期待する人がいるかもしれないけれど、それはなさそうだと自分が考えているのはわかってもらえると思う。人々が共有する時代の空気から生まれたものが、空気の繋がっていない違う世界に広がっていくのは難しいよね。
あと勤務先の名誉のためにいっておくとそういうアレがない以外はまあまあうまく回っているのではないでしょうか。
2019/8/26 追記
本家? のはてなグループはおわってしまったと教わった: はてなグループ終了に寄せて - #生存戦略 、それは - subtech
ARM の Big.Little いまいちじゃね？と思うのだが世間の人々はどう評価しているのだろうな。
Pixel2 とかは Big x4, Little x4 の CPU が載っている。仕事でやっている CPU intensive なアプリだと、なにかと処理を並列化していくのでけっこう CPU は使い切る、のはピークの瞬間だけだけれどもたとえばアプリ起動時で 4 コアくらいは使い切る。
そういう高負荷時の Systrace をみると, Big コアのロードが真っ先に埋まっている。そこから更に負荷が上がると残りの Little コアも埋まっていく。この挙動が妥当かどうかはさておき、アプリは自分のスレッドがどのコアに割り振られるかはわからないので性能を予想しづらい。スレッドの特定のコアを指定する API も少なくとも Java レイヤにはない。ベンチマークのスコアもいまいち安定しない。（なので言語処理系とかで本気の厳密なベンチマークをしたい人たちは遅いコアを全部殺したうえで計測したりする。ついでに thermal governor も殺してクロックも固定する。電話機が熱で溶けないのか心配。）
たとえば Halide みたいな data parallel なコードが「よし 8 コアあるぞ!」とスレッドを 8 個起動したとする。しかしそれらの並列処理は速度が揃わない。他プロセスの影響だの cache coherency だの言い出すまでもなく CPU が違うから。そりゃタスク粒度をあげて細かく worker に振り分けていけば unevenness は隠せるし、そうでなくても速い CPU が空き次第スケジューラが遅い CPU からスレッドを migrate してくれればいいっちゃいいのだが・・・それよか 8 個の並列処理がだいたい同じ速さで終わると思ってfork-join をかける方が簡単じゃね？
そしてアプリのスレッドを速いコアから順に割り振るのはいいのか？省電力とかいう話はどこいった？画面が消えているときはモードが変わって速いコアを止めているのだろうか。
など色々自明でないことが多すぎて、アプリプログラマには手に負えない。それよか速いコアだけ 6 個、とかにした方がよかったんじゃないのかなあ。遅いコア２つ速いコアを１つ買えるという計算があってるのかはわからないが・・・。 LWN の記事を読んでも辛いという気持ちしにかならない。
最初の記事では Big と Little の CPU を排他的に使う (Big だけで動くモードと Little だけで動くモードをスイッチする) ということが書いてあり、マジかと思う。まあこれは 2012 年に書かれた記事で自分の Systrace などの観察とは一致していないので、少なくともいまは違うのだろう。
Apple はどうしてるのかと Wikipedia を眺めていたら、どうも彼らの CPU も Big.Little 類似のアーキテクチャを採用しており、しかも A10 くらいまでは LWN にあるような Big/Little 排他動作のアプローチだったらしい。まじか。でもたしかに iPhone のコア数って 2-3 くらいと伝え聞いていたので、整合性はある。そして A11 からはでかいのと小さいのを同時に使えるようになったと書いてある。そりゃ iPhone X 速くなるわけだわ。
むー。Big.Little は失敗におわった実験かと思ってたけど、全部自前でやりたい放題かつ実際にベンチマークでは Snapdragon 勢に圧勝している Apple の CPU が同じことをしているとなると、自分の脊髄反射とは裏腹にそれなりに成功したアーキテクチャーなのかなあ。ぜんぜん納得行かないが・・・。
探すと関連論文ちょこちょこあるね。ちらっと読んでみようかなあ。
5 月くらいに出ていた。CoreML / NNAPI の Windows 版みたいなもんらしい。こういうものが普通の OS Update で降ってくるあたり Desktop OS の maturity を感じる。
Battery Historian (GitHub) というツールがある。Android の bugreport dump を時系列に可視化してくれる。名前からもわかるようにバッテリーの浪費をチェックするためのツールだが、結果としてシステムの挙動を longitudinal かつ holistic に眺める役に立つ。Systrace のように細かいことはわからないが、そのぶん広い時間の幅をカバーしてくれる良さがある。なんだかわからない性能バグがやってきたら、とりあえず軽く Historian をチェックする。
このツール何がすごいかというと、必要な情報はぜんぶ bugreport dump から集めているところだよな。
Android の bugreport dump はすごいアドホックな非構造テキストデータの塊で、基本的には logcat バッファの中身と dumpsys にはじまるいくつかの inspection 系コマンドの実行結果が詰まっている。ないよりはマシだが、しょうじき大したデータではない。Historian はそのしょぼいデータをまあまあいい感じに可視化し、なんらかの知見を引き出している。もちろん中の人が作っているので Historian 自体の必要に応じ OS が収集しているデータもあるだろうが (batterystats とか), それにしてもこのしょぼい中がんばったなと感心する。
常識的に考えたら Android がやるべきことはシステムの活発度に応じ粒度を変えながら iostats やら vmstats 的なデータを構造化した状態で time series 用 ring buffer のストレージにダンプし続け, かつそのストレージを様々な subsystem から書き込めるよう公開し、システム全体の時系列のロードを常時収集のうえ bugreport に含めることである。ぜんぶ proto なサーバ側を見よ。
しかし Android にそうした大局的なまともさは期待できない。(いいかげんやってもバチはあたらないとおもうが。) かわりに正しい問題を見定めたビジョンと実力のある現場のエンジニアが手持ちの時間の中でギリギリできることをやる。その結果が Historian なのだろう。（きっと。）これは Android 的だなと思う。Systrace も似たような雰囲気あるでしょ。
こうしたツールやシステムに対する自分の気分は複雑。ギリギリじゃなくてちゃんとまともにやれと思う一方、まともにやろうと人を集めて作ると大げさで使えないゴミの負債を生んでしまうのではという恐怖心もある。オープンソースな世界だと市場原理でいいやつが残る期待があるけれど、企業のコードベースというのは計画経済で、かつオープンなプラットフォームだと一度入れてしまったものはゴミでもなかなか切り捨てられない (例: renderscript)。あんまりムリに背伸びはしないでくれよな、などと思ってしまう。我ながら上から目線な上に余計なお世話にもほどがありますが・・・。
Android に限らず、しょぼいが便利な内製、製品固有のツールやライブラリが本腰を入れたプロジェクトとして書き直されゴミ化する様を何度も見てきた。そのせいで警戒心がある。しょぼいツールに資源が投入された結果よくなった例もきっとあるのだろうけれど。
個人的な意見としては、問題意識のあるプログラマがヒマを見つけて気の利いたツールの萌芽を作り、それに気づいた周りのプログラマが手を貸し育てていく、というパターンが内製ツール成功の定石。Android のひとたちにはきっとヒマが足りてない。これも余計なお世話だが。
プログラマは適度にヒマにしておくのがよい。ヒマの大半は無駄に使われるだろうけれど、時々生まれる成果はトップダウンには置き換えられないものだから、それに免じて見逃してちょいだい。と思う。そういう意味で優秀なプログラマほどヒマなほうが良い。
勤務先のソフトウェア開発インフラやプロセスには良いところも悪いところもある。中でも一番良いものはたぶんコードサーチだと思う。コードサーチのできの良さが、他の様々なイマイチさを一定程度救っている。
コードサーチといっても検索だけでなく、シンボルをクリックしてジャンプできるとか履歴やら blame やらができるウェブブラウザ越しのコード閲覧環境一式や monorepo である事実を含めて良い。
まずコードサーチがあるとドキュメンテーションの重要性が下がる。この API なんだろ、という時にまずコードサーチをするようになるから。実装を見て、呼び出し箇所を見て、だいたい用が足りる。それでもダメならコードの冒頭なりディレクトリの README にドキュメントないかなーと探して、それでもダメなら仕方なくコードじゃないサーチを試す（だいたい何もでてこない）。エラーがおきたら、まずエラーメッセージをコードサーチする。
ライブラリを提供する側もユーザがコードサーチすることをわかっているので、サンプルコードとかは一通りチェックインされている。そして codelab とよばれるハンズオン方式のチュートリアルがドキュメンテーションの方法として幅を効かせている。
逆に Javadoc のビューアは知る限りどこにもない。Java 自体は広く使われているし、そのコメントも Javadoc フォーマットで書くのだが・・・。コードサーチ上ではコメント内の @link とかがちゃんとハイパーリンクになっててウケる。
設定ファイルの類がぜんぶチェックインされている事実もコードサーチの有用性を高めている。ダッシュボードや Web UI の類でよくわらからい項目があったら、とりあえずコードサーチする。
あるとき性能リグレッションのバグを割り振られたプログラマが、ベンチマークの CI を管理する QA チームの一人に質問していた。
「この指標の名前、コードサーチしても全然出てこないんだけどどうやってサーチすればいいの？このハイフンの前を削ればいい？」その場の誰にも答えがわからず聞いて回ってたどり着いた人いわく「その項目の横にある鉛筆のアイコンをクリックすると（コード上の名前とダッシュボード上の名前の）マッピングを編集できるよ」つまり答えは（サーチでたどり着けない）データベースの中にあったのだった。
データベースじゃ見つからないわと一同爆笑。そしてブーイング。サーチできるようにしとけよ！と叫んだそのプログラマは、すかさずラベルにコード内のシンボルを追記した。よしよしこれでサーチできるぞと・・・。
このエピソードはコードサーチのメンタルシェアを物語っていると思う。実際じぶんたちのチームが使っているダッシュボードは社内でもできの悪い部類に属しており、ちゃんとした部門の使っているできが良いやつは設定をチェックインする設計のものも多い。まあ設定ファイルをチェックインするのは infrastructure as code 的な意味でコードサーチ以外の利点も多いなのでサーチのためだけにそうなっているわけではないけれど。
コメントだけがドキュメントでない、独立したドキュメントにはそれはそれで価値がある。その主張は事実かもしれないけれど、コードサーチはドキュメントとしてのコードや設定ファイルの守備範囲を大きく広げる。おかげでプログラマの仕事がよりコード中心になる。副作用がないではないけれど、個人的にはけっこう好き。
あるとき社内インフラのサーベイがメールで送られてきた。諸事情でフラストレーションを溜めていた自分は脊髄反射で「中途半端な内製ツールを強要しないでオープンソースを使わせろばーかばーか」的なコメントを書いて投稿してしまい、あとで大人気なかったと反省した。
そうはいってもいいとこだってあるよな、と考え直して最初に思い至ったのがコードサーチ。罪滅ぼしにいい話でも書こうと思った次第。いずれ GitHub に完敗する日まではエンジョイしておきたい。
Podcast, 自分のターンは基本的には論文の構成にしたがって話を進めているのだけれど、これはイマイチだな。概要をつたえるという趣旨に合わないし、門外漢相手に話をするメディアの性質にもあってない。そして書いて有ることを全部伝えようとする結果長くなりがち。もっとこう、内容を把握した上で話す順番とかとりあげる話題は自分で考え、細部はざっくざくと削ってしまう方が良さそう。
それはつまり Linear Digressions みたいにするということで、幾つかの理由からもともとはあまり乗り気でなかった。まず若干パクリっぽい気分になるので自分なりの方法を考えたかった、というエゴのようなもの。あと Linear Digressions はあっさりしすぎて食い足りないところが自分は不満なので、詳しい話をしたかった。あとは理解がいいかげんな状態で中身を再構成するとかできなそう、という気がしていた。
が、その結果として締りがなく時間ばかり長い現状になってしまっているので、何か違うことを試して良い頃合いでしょう。難しかったらまた考え直すということで。
たとえば向井さんとかは、割とあっさり済ませているよね。そしてそれは機能している気がする。自分はせっかく読んだので読んだよーと言いたい誘惑に負けてるのだろうな。
というわけで次回からは構成を無視してあっさり目に話してみたい。
Google insiders: meeting leaks backfired, gave execs moral high ground - Business Insider
James Damore の事件以降つぎつぎに色々な資料がリークし続けている勤務先、ついに会社の all hands の中継動画がリークされて発言が live tweet されるとか、もうどうにもならいなと思う。
自分はもともと勤務先のことを経営陣によるすごい判断が支えているとはあまり考えておらず、ボトムアップと運の力でなんとなくうまくいってる説をファンタジーとわかりつつも支持している。ある種の sensitivity もなるべく低くして、いまいちな経営判断があったくらいでがっかりすることはなくなった。でもボトムアップのファンタジーを信じていると、こうした下々による心ないリークやその帰結は hurt なのだった。今日は会社やめたい衝動がにわかに沸いた。稼がないといかんのでやめないけど。
ファンタジーとか社畜精神とかはおいておくとして、社内のメーリングリストやソーシャルメディアなどでの発言が次々と新聞やらニュースサイトやら右翼過激派やらに転載されるような会社で働きたいか。自分は（主に仕事の生産性向上のため）数年前から社内のフォーラム類は見ない書かないの方針でぜんぶブロックしているので直接の被害はまずないけれども、なんていうかすごく嫌なものだよ。新製品のリークの方がよっぽどマシ。
なにかが壊れてしまって、バラバラと崩れ落ちていくものがある。崩落の地鳴りが事件のたび心をよぎり、そのつど一層音量を絞り込んで、日々を生きていく。聞こえなくなってしまったものはきっと色々あるのだろうけれど、すぐに忘れてしまう。それを悲しいとすら思わなくなる。耳を澄ます privilege を自分は持っていない。
衝動的な愚痴なんでそっとしといてください。
Android では UI thread に高いプライオリティが割り振られているという。それは Systrace を睨めばわかるが、ふと思い立って実際にどのくらいなのか調べてみた。この SO の記事を真似してよく知っているアプリすなわち仕事アプリのスレッドを眺めてみる。
- UI Thread と Render Thread は同じくらい高い pri がある: 29
- HwBinder のスレッドは更に高い: 31
- ランダムなワーカーの皆様は 19
- Thread#setPriority で釣り上げを試みたと思しき奴らは 21. つまり Java の API をいじっている範囲では UI Thread には勝てない。setpriority() とか使うと変えられるのだろうか。常識的に考えるとダメそうだが。
- ART の GC 用スレッドは低め: 15
最終的に UI thread をブロックする処理は下手に worker に逃がすより UI thread でやってしまったほうが良い場合があるとわかる。まあ CPU は１個だけじゃないし他プロセスとの兼ね合いもあるので一概には言えないけれど。
ps の出力には PRI の他に NICE もあるが、上下関係は PRI に準じている。違いが気になるけど調べるのはまた今度。
via Profiling: Measurement and Analysis | Riot Games Engineering
Riot Games という会社は自分の C++ のゲームを trace する際に Chrome Tracing のフォーマットでダンプしているらしい。そうそう、こういうのいるよねーと思うのだった。
ただ続編の記事 Profiling: Real World Performance in League を読むとこの人はもっと色々使っており、たとえば GPU analyzer みたいのを使っている。そういえば Snapdragon Profiler もなんかこの手の機能があるようなないような感じだった。自分の今の仕事だと GPU がボトルネックになるのを見たことがないのであまり出番はなさそうだが、それはさておき tracing 以外のツールも色々使えるようになりたいもんだなあ。特にクライアントサイドだと画面の visual components と cost budget を対応づけるような何かは欲しい。Android にも overdraw とかあるにはある。ただもうちょっと自分のアプリに近いレイヤで工夫したいね。
あと PC games みたいのは画面もでかいしメモリもいっぱいある(開発機には)ので in-app で色々書けるけれども、スマホは画面が狭いので on device は限界があるよなあ。自分は debug 情報表示用 activity を入れとく派だけれども、その activity を表示すると本体の activity が stop してしまう欠点があり、これはアプリによっては嬉しくない。悩ましい。
仕事のアプリは諸事情により一部にカスタムなレイアウトのロジックを持っている。面倒そうなコードなのでなるべく近づかないようにしていたが、ちょっと手直しをする仕事が回ってきたので仕方なくじっと睨む。
これは書いた人がレイアウトというものをわかってないなあ・・・というコード。
べつにすごい深い知識を求めているのではなく、レイアウトというのはまず子の大きさを求めて次に位置を決めてあげる、という二段階構成が基本なんだよとか、ただし位置を決めるプロセスで制約を満たすために大きさを直したりすることもあるんだよ、だとか、縦に積むとか行を詰めてくとか代表的なパターンがいくつかあるんだよ、みたいな。Android の View にしても measure() と layout() の二段構成になっている。
そのカスタムレイアウトは諸事情により View のライフサイクルとは独立したコードになっていて、それはいいのだがレイアウトが二段構成だとか基本的なパターンがあるみたいな事実がコードにまったく反映されていない。厳しい。
しかも興味深いことに、コードの挙動をよく睨むと現状の仕様はそれほど厳しいものではなく、上に書いた conventional な感じに書き直すことができることに気づく。つまりコードが変なだけでカスタムとはいえすごく変な振る舞いをしているわけではない。
これ書いた人たちはどのくらいわかっているのだろうか・・・。たぶんすごく最初の素朴なバージョンはわかってる人がデザインして雑に書いたのを、他の人がいじるうちにわけわからなくなってしまった、とかなのだろうなあ。というわけで肝心の変更をするまえにクリーンな状態に書き直し。これでバグらず直せるぜ。
レイアウトの振る舞い自体にも奇妙なところがあるにはあるのだが、これは書き直しているとよく考えられた巧妙な仕組みであることに気づく。ダメなコードは振る舞い自体もダメなことが多いが、クリーンに書き直すことでコアのアイデアが浮かび上がってくることもたまにある。今回はそういうケース。歴代の UX のひとがよく考えた結果なのだろうな。
自分は UI のデザインをモック画像だけでコミュニケーションするのはよくないと感じている。その理由の一つがわかった。モック画像はコンパイルしたバイナリみたいなもので、UX person の考えた rationale が失われてしまう。Design Language みたいなテンプレ、モジュール化はそうした lost in translation を防ぐ試みとも解釈できる。けれどテンプレや再利用ではない、自分がいま直したコードのようにアプリケーションのユニークな振る舞いを捉えることはできない。
どうすべきか。ひとつには UX person との対話を通じて相手の意図をコードに落としてあげる、つまりモックの一方通行ではなく相手と話をする、DDD みたいなやり方が良いのだろう。自分のチームは対話するところは割とできてる感じがあるけれど、今回直した部分についてはプログラマが意図をエンコードするのに失敗していた。しかもそのために必要なのは readable code 的な hygine skill ではなく UI レイアウトというドメインの知識だった。
という上から目線の話を書きたかったわけではなく、コードはともかくレイアウトの振る舞いがすごくよく考えられていて UX 氏やるな、とおもったという話を書きたかったのだった。でも実例なしに書くのが難しく話がそれてしまったね。
人様の podcast に出ないかと誘っていただいたのをはじめて断ってしまった。がっくし・・・。しかし最近は自分の podcast すらスレスレでやってるので人様のに出してもらう準備をする時間はないのだった・・・。軽妙に時事ネタを雑談するスキルとかがあればいいけど、時事ネタもわかんないしなあ。Android の話なら少しはできるかもだけど、専門家というほどでもないし。
というか冷静に考えると録音のための時間をブックするのも厳しくね？子供の相手を奥さんに押し付けるのも週に一回くらいが限度だよなあ。週末なら大丈夫だろうか。とにかく決まった時間になんかするというのがすごく困難。就業後に会社で録るってのはそういうのをなんとかするハックなわけで、我ながらよく思いついた。そして向井さんが近所でよかった・・・。
雑誌連載を断ったり podcast を断ったり講演を断ったり（これは仕方ない）、不義理を重ねていくと人間関係が疎になってしまって孤立が深まるなあと残念。子育て中の人間が孤立するというのは現代では割とよくある話に思えるが、昔はどうしてたのだろうか・・・というと、地理的な近接性というか近所付き合いみたいのが中心だと子育てしてても孤立しないのかもしれない。それは付き合う相手を選ぶ自由がないことでもあるのだが。義理を果たすというのは本質的に資源を使うことなので割とどうにもならない。
それでもテクノロジのちからで昔よりはトレードオフのない自由が増えているはずなのだけれど、その余剰は育児がぜんぶ吸い取ってしまうのだろうな。Parkinson's Law.
$ adb shell monkey -p your.package.name -v 500
via UI/Application Exerciser Monkey | Android Developers
あなたのコード、特定の条件下 (デバイス、OS など）で起動するとすぐ落ちますよ、ということを伝えるためのコマンド。再現手順を簡潔に伝えられて良い。
そんなクラッシュコードがチェックインされるとかどうなの・・・と思うかもしれないけれど依存関係の奥の方で変更があったりするとそういうこともあるのだよ。翌朝来たら誰かががんばって bisect して直していた。おつかれさまでした・・・。
追記
とりあえず何十回か回す one-liner を書いて動かすとなかなか楽しい。まあ monkey test ってのはもともとそういうものなわけだが。monkey 実行前の条件づくりをもうちょっとがんば良いテストになりそうだな。というかテストの人たちはそうやってるのであろうな。
Phase correlation - Wikipedia
HDR+ の論文で template matching に Fourier transformation を使う話が出てきた。(Fast Template Matching) 全然わからん。まあ Fourier transformation からしてわかってないのでわかるわけないのだが、表面的に雰囲気だけでも理解したいなーとおもってうろうろしていたら phase correlation の話がみつかった。
つまり 1 pixel ずつ位置をずらしながら毎回エラーを計算するのではなく、frequency domain にもっていって convolution すると一撃でエラーを最小化できる場所がわかる、ということらしい。frequency domain なら位相のずれが捉えられる、ということなのかなあ。まあ雰囲気はわかった・・・ような気分にはなった・・・。
Evicted: Poverty and Profit in the American City を Audible で聞き始めた矢先、アパートのドアに管理事務所からのお手紙が。「三日以内に家賃払うか出てけ」「法的な措置をとるからよろね」という。マジかよ！慌てて管理サービスのページを開くと auto-pay の設定が切れていた。すかさず支払う。しかしこんな脅迫状送りつけてくる前に一声かけてくれや・・・。三日前に通知とか、うっかり旅行中だったら詰んでしまう。Auto-pay を設定しなおすと同時に、設定の見直しを促すカレンダーイベントを作って予防線を貼った。明日 leasing office にいって支払いが認識されていることを確かめねば、と思ったら off-site で不在とか張り紙がはってある。脅迫状送りつけといてだんだよーーーもーーー。
前に住んでいたアパートはもうちょっと穏当なメッセージで通知された気がする。このアパート、立地はいいけど運用は色々と好きになれん・・・。なお先の書籍によると、いちど法的な措置が発動してしまうと、裁判で勝とうが負けようが訴訟された記録がデータベースに残り、就職やらローンの審査やらに影響がでうるという。疑わしきは無罪の原則は資本主義の圧力により崩壊していたのだった。読んでる本がよくないのかもしらんが、アメリカのろくでもなさに対する確度が高まっていく日々。
Mountain View は今年から rent control の法案が施行された。最初はめでたいと思っていたけれど、これって大家に住人を追い出す incentive を与え、長期テナントはなにかと迫害されうるよなあ。自分たちは本来は大企業勤務でわりかし stable income 、かつたいして文句もいわない優良住民のはずなのに、rent control のせいで追い出し候補になってしまう。ダメじゃん。はー Sunnyvale に帰りたい・・・という気分。
十年前に住んでた桜新町のアパートでうっかり半年ほど家賃を払い忘れたら大家さんが遠慮がちにやってきたのを思い出す。あの頃は平和だったなあ（そして馬鹿だったなあ・・・）。なおその次に住んだ広尾のアパートは２日くらい払いが遅れたら親に電話が行き、かつ大家がドアをドンドン叩いて催促に来た。それでも法的措置を取られるのよりはマシな気がするよ・・・。
ATP 285 の雑談で、Mac OS はいつ Intel を捨てて ARM になるのかの与太話をしていた。
一足先に ARM になった laptop のひとつたる Chrome OS のユーザとしては、Apple にはがんばって速いやつを出してほしいなあと思う。いま自分は Chromebook Plus という Samsung の Chromebook でこの文書を書いているわけだが、前も書いたけどこいつは遅い。しかしそれは ARM (as an architecture) のせいなのかというと、わからない。というかそんなことはないだろうと思う。ARM を載せた Chromebook はみな low-end の廉価版で、安いが遅い CPU を使っている。Snapdragon 835 を載せた Chromebook なんてのは存在しない。ハイエンドはみんな Intel. 一瞬登場した ARM の Windows (RT) も似たようなものだろう。
だから今のところ誰も本気の ARM laptop がどのくらい速いのか知らない。そこに Apple がバーンと ARM 版 Macbook なり iOS laptop を出してそれがすごく速かったら、そして Apple が出すならたぶん速いと思うのだが、競合の皆さんもやる気出して速いの作ると思うのだよなー。そしたら Intel (as a company) 以外みなハッピーじゃん。
まあ競合の皆さんは Apple を待ってないでさっさと速い CPU を積んだ high-end ARM Laptop を出してほしいもんです。特に Samsung, Exynos な Chromebook を出して！(個人の見解です。)
Link: Manu Sridharan - Challenges in Large-Scale Mobile App Performance - YouTube
Uber がモバイルの性能頑張ってるよ、という話。Android と iOS でひとつづつトピックを紹介している。
Android 側では nanoscope というプロファイリングを強化した ART のフォークを紹介し、iOS では Swift のコンパイラの最適化を upstream する話をしている。
なんちゅうか、皮肉な話だよなあ。
Android はだいたい全部オープンソースだが、コミュニティドリブンでない。年に一回変更がダンプされてくるだけなので、何かを upstream するのはすごく大変で一部のメーカーくらいしかやってない。iOS は Darwin くらいかオープンソースじゃなかったわけだが、あとから登場した Swift はびっくりするほどオープンにオープンソースしている。
結果として Uber は Android では成果をフォークをして iOS では upstream している。まあ Swift はコンパイラなので OS からは unbundle されている影響もあるかもだが・・・。実際 ART は AOSP をトランクとして作業してるらしいので年に一回ダンプするモデルではないが、まあ最新の Android でだけ修正されてしかも成果は来年までおあづけ、とかだと盛り上がらない。
最近 AndroidX が AOSP ベースになったとアナウンスしていたけれど、どうなるかねえ・・・。
ところで Nanoscape を紹介する記事 Introducing Nanoscope: An Extremely Accurate Method Tracing Tool for Android で彼らが発見したとしている性能上の問題、ぜんぶ userdebug の Systrace みればわかるのだよね。おまえらカーネルいじる前にやることあんぞ。同時に我ながら Systrace おじさんすぎて苦笑。
ART はロックの競合を Systrace に記録してくれため、どのスレッドがどのスレッドを待っているのかがひと目でわかる。これは素晴らしい機能で、マルチスレッドコードのクリティカルパス解読を助けてくれる。
自分が仕事でみているアプリは大量にネイティブコードがあるのだが、こいつらが pthread でロックを待つと Systrace 上にはただ "pthread の lock を待ってます" とだけ表示される。嬉しくない。もうちょっと詳しく教えてくれ・・・。
まあアプリのレイヤで使う pthread が不透明なのは自業自得といえなくもないが、platform のコードも同じ問題も持っているのでやはりお前らなんとかしろ！と思う。なんとかしていただきたいものです。
時間がない、という定期的な愚痴です。
子の寝かしつけが難しくなってきたのと、子の朝飯の助けをするようになった結果、朝の時間も夜の時間もなくなってしまった。前は Podcast だけで一週間が終わってしまうと思っていたけれど、今や podcast の準備すら怪しい。ここ一ヶ月くらいエクストラな読書はまずムリなかんじ。そこに週末の外出などが重なると、週末の考え事時間さえ失われる。フラストレーションというか絶望というかそういう気持ちになる。
とはいえコントロールできることではない以上精神衛生を損ねても仕方ない。10 のうち 10 失われるところをなんとか 1,2 は手元に残せるよう頑張ってみて、うまく行ったら喜ぶくらいに期待値を調整しないとな。たとえば今は妻子昼寝の隙をついて給油ついでにコーヒー屋で管を巻いている。こういう小細工を、夫婦関係を損ねない範囲で色々やってくセコさが求められている。
共働きを片働きにして余裕ができるかと思ったが、そこに発生した余剰資源は大半が子供などの為に使われ自分には大して回ってこない。これも優先順位からして完全に妥当なことで文句はないけれど、自分が間違った期待値を持っていたせいでがっかりしてしまう。
妻子あり生活、適応したと思ったけれどまだまだ先は長かったという話。