FB のろくでもないニュースがあり、さすが同じ広告業者でもあいつらは格が違うな・・・とびびっていたら勤務先も似たようなことをやっているという報道がつづいてまた一つがっかりした。
セクハラ幹部に一生遊んで暮らせる手切れ金を払ったのもひどかったが、ユーザとは関係ない話だった。これはエンドユーザ相手。がっかりもひとしお。
しかしそうした判断とは裏腹に自分の gut feeling は思ったより動じなかった。予想の範囲内だったというわけでもなく、もうどうでもいいという気分が近い。勤務先からの自我切り離しが着々と進んでいるのを感じる。売り上げて給料を払ってくれればそれでいい（法は守るとして）。誇りを持って働くことへの憧れもまだゼロではないが、今はファンタジーにしか感じられなくなった。目先の仕事がそれほどつまらなくないのがせめてもの救い。
降り注ぐ失望をいつか無視し切れなくなる気もする。一方で仕事に対する感性の劣化速度もなかなかのもの。光の速さで心を麻痺して、そのまま苦しまずに倫理的な死を遂げられたらと思わないでもない。家族がいると物理的な死はちょっと抵抗あるね。
定期的な愚痴なのでそっとしといてください。
05:08. 機能は睡眠確保のためにスキップして目覚ましをとめた、はいいが昨晩戻し忘れた...
- PDFium, shared_library は動いたので次はツリーの中で Java をビルドしてみるべし。
- 手強い・・・ third_party 依存が多いがこれぜんぶコピーするの？的になってる・・・。
- 時間切れ。
Stepping back, ほんとに Chromium ビルドシステムの中で Java をビルドすべきなのかなあ。
- 調べたところ、どのみち AAR までは一撃ではたどり着けなそう。Cronet は zip と jar を生成したのち何らかのスクリプトで AAR を作っている模様。
- GN は複数 CPUarch の同時ビルドに対応しておらず、これが JNI つき AAR ビルドの大きなブロッカーになっている。
- 主要な動機は一撃でビルドしたいのと jni_generator を使いたいだが、これは android_library() に加えて更にたくさんの依存関係を pull する疑惑がある。そして既に依存の一部は DEPS で pull できずコピーを強いられている。厳しい。
- Chromium の Java ビルドはビルドの成果物にやたら前処理や後処理をするので、Stub でごまかすのが難しい。
という点を踏まえるとフル GN は諦め、
- SO のビルドまでは GN/Ninja でやり、Java は Gradle なり Bazel なりでビルドする。
- GN で SO をビルド、しかるべき場所にコピーするスクリプトを書き、Gradle/Bazel からビルドの一部として呼び出す。
- jni_generator は諦め、手で RegisterNative する。
という路線に切り替えるのが良さげ。明日やる。まずは JNI と NDK つきでコードをビルドしましょう。
今の仕事が辛くなったら Chrome for Android に逃げ込むのもアリかなとおもってたけど、これはこれで厳しそうだなあ。我に安住の地なし。
同僚からいじめを受ける夢を見た。
その同僚は隣のチームに比較的最近入ってきたほとんど接点のない相手で、したがって嫌な思いをしたこともない。正直いうと名前すら思い出せない。白人である。
白人である、というのは本来は完全に無意味な情報なはずで差別的ですらあるが、ここでは関係がある気がする。つまり、自分は心のどこかで白人ちょっと怖いのかもな、と思ったから。自分はたとえばインド人の同僚からいじめられるところはまったく想像できないが、先の夢に出てきた同僚からいじめられる様は、想像・・・というか空想・・・の範囲内なんだよね。端的にいうと風貌が（日本の）マンガとかにでてくるいじめっ子ぽい。もちろん現実にそういうことは起きない。
夢にでてくるとかまさに unconscious bias. Unconscious bias って majority が minority に対して抱くものだと考えがちだけど、実際は逆向きも少しはあるよね。だからこそ人種間の対立というのは一層ややこしくなるんだろうし。しかし自分は別に普段から迫害されてる minority というわけではないので、この unconscious bias というか discriminatory な気持ちは単に情けないというかみっともないというかひどい。夢だからどうしょうもないとはいえ反省した。
たとえば同じ白色人種でも自分はチームの TL が夢の悪役に出てきたことはない。見も蓋もないことをいうならこの TL の方がよりいじめっ子ぽい風貌をしているしコードレビューとかで迫害されている、というのは冗談だけどそれなりに blunt な扱いをうけてムっとすることもたまにある。しかし自分が相手の性格をよくわかっているので unconscious bias を生み出す未知への恐怖はない。差別は相手を知らないとおこる。
まあ仕事のストレスが歪んだ形で現れた面もあろう。仕事忙しいの良くない。締め切りよくない。（やつあたり。）こういう話はそっと胸に秘めておくのがマナーだけれども、公開時点では時効ということでひっそり confess しておく。
via [1.3] arter97 kernel for OnePlus 6 - Post #56
No, I'm actually not going to refine this as I'm quite certain this is due to the bulls**t OnePlus is doing with schedulers to boost certain whitelisted apps such as Snapchat.
Those crap OnePlus code, which is just hard to look at, may improve user experience, but I'm just refusing to put cancer in to my kernel. These are just bandaids on top of another multiple layers of bandaids that are prone to cause more problems down the road.
Oneplus はカーネルレベルで Snapchat を優遇しているのか・・・。自分もカーネルレベルで優遇してほしいもんだわ。無理だが。なんとかして一般的なフレームワークでこういうのできないのかなあ。
05:07. 子が若干風邪っぽく、結果として自分も若干鼻水が。とりあえず鼻うがいをしておく。
Tax return も podcast editing も放り出して PDFium. おまえらは夜に相手してやる...
- 今日は shared library としてリンクしたい。
- またひとつ build yak 潰し・・・
- JNI_OnLoad のみ export するオプション vs. しないオプションで 12MB vs 4MB. シンボル隠す tweak を削るとビルドの yak は減るがいちおう真面目にやっとく。
- 時間切れ。
Ask HN: Go-to web stack today? | Hacker News
簡単なウェブアプリをささっと作れた方がよいよなあという年来の懸念と、簡単につくりたい社内ウェブアプリ（ちょっとした dashboard 的なもの) があるのとで、何で作ろうかと考える。自分の現状としては flask いちおう使えますが・・・くらい。
上のスレを眺めていると flask 派はいるにはいるが少数で、Django か Rails あたりでいいんじゃね、的な雰囲気。Rails もうちょっと人気あるかとおもったけど Django/Rails とくくられる程度の扱いか。US だとそうなのかね。Java 勢どうなのかとおもったけれど Spring Boot は flask 以上に人気なかった。まあ HN という媒体のバイアスはあろうが、自分はそのバイアスされた世界に生きているので無視はできない。
Elixir や Clojure はよりマイナーで、まあそうだよなと思う。Go もバックエンド方面向けらしくフルスタック用途ではあまり見かけない。自分はこの辺の温度感が知りたかったので、なんとなくわかってよかった。Go 流行っているけれど、それは既存のウェブアプリからサービスを切り出す用途ではやっているのであって、ブラウザに HTML や JSON をお渡しする仕事は昨今あまり変わり映えしていない。代わり映えしないから話題にならないだけで、すごく衰退したわけではない。
自分の関心は世の中みんな JS でやるようになった結果ウェブのサーバ側は簡素でよくなり、結果として従来のでかいフレームワークは衰退して小さくて気の利いた奴らが台頭したりしてないよな・・・特に Go とか普及してないだろうな・・・というあたりだったが、少なくともいわゆる「フルスタック」の人の間ではそういうことは起きてなさそう。Micro なんとかだと事情はまた違うのかもだが、自分はそんなサーバがいくつも必要なものを作りたいわけではないからね。
といった現状はあるが・・・。自分の仕事を考えると App Engine で動かさねばならず、そうすると Django とか別に嬉しくないので Flask か Spring Boot, しかし会社の中で Spring Boot 使ってる人とかいなそうなので結局 flask かな。Flask はやっつけモニタリング UI やしょぼいデータ編集ツールなどで割と使われている模様。
いい機会だから GAE でなく内製側のクラスタに push できる何かとして作ってみようかと一瞬思ったが、勝手に使えるデータベースがなかった。終了。どのみち内製のクラスタで動かしたところで社内の謎フレームワークが使えるようになるくらいで、良い選択肢は増えない。
自分や自分の周りの人が使うレベルを一歩越えようとするとやはり flask はつらそうで、Django なり Rails なり Spring Boot なりを使いたい。しかしこれは社内では使えないスキルなのでいまいち盛り上がらない。社内でしか使えない謎スタックはそれ以上にやる気が起きない。うむ。やはり Flask だな。今の自分にちゃんとしたウェブを作るのは out of scope ということなのでしょう。やむなし。
JS はというと社内はおおむね Angular ぽいので、全然興味ないけどまあ Angular でいいです。React 勢とかいるのだろうか。気になるけれど深入りしても仕方なし。
より現実的な問題としてそんなことしてる暇あんのか、というのはあるが、まあ隙間を見つつジリジリ進められたらいいな、みたいなレベルの話ですので。
Home - Dynalist
自分は Workflowy が好きだったのだが、実装がへぼい上に良くなりそうな気配がなかったため半年くらいで捨てた過去がある。この Dynalist は自分と同じような Workflowy への不満をちゃんと作るという形で解決したと主張している。
たしかにちょっとさわったかんじ若干マシに見える。自分はかきものを Wordpress に統一しようとしており、公開したいものもとりあえず Wordpress につっこむ運用をしている。しかし若干敷居が高いので細かい書捨てをやりにくい欠点があった。あと何かをインクリメンタルに書くのが難しいことにも不満を感じていた。Dynalist いいのでは・・・いつものように単なる迷走な可能性も高いが・・・。
まあ軸足は Wordpress に置きつつ Dynalist もチマチマ試してみるとしよう。Wordpress も Dynalist も仕事に使えないのが一番つらいが、それは勤務先のせいなのでやむなし。
このあいだ久しぶりに社内ソーシャルメディアを眺めたらあまりに空気が悪くてびっくりしてしまった。（普段はブロックしている。）
自分が勤務先に持つ悪印象への貢献度は: 社内ソーシャルメディア > 世間の報道 > 普段の仕事。普段の仕事で不満を抱くことはないでもないとはいえ、社内ソーシャルメディアに渦巻く negativity と比べたら足元にも及ばない。遠い昔は仕事が退屈な時期に社内ソーシャルメディアから euphoria を補っていた淡い記憶があるが、どうやってそんなことが可能だったのか今となっては思い出せない。
今の勤務先は総体としては downturn に入っており、テック産業の歴史を鑑みるとそのまま朽ちていくと考えるのが一番妥当。楽観的にいってもどっかで下げ止まるくらいがせいぜいで、大復活みたいのは考えにくい。そうした世代交代は産業全体からみると健全なことであろう。自分が収入の stability を欲している時期にそれが起きてるのは個人的にはすごく困ったことだし大復活してほしいけれども。
5 年くらい前はそういう空気を読み取った人がザザザーっとスタートアップや近隣の景気良さそうな会社 (FB とか) に流れていたように見えたが、最近は謎の給与格差および巨大スタートアップ群の停滞感、競合他社がおなじくらいぱっとしない問題などから行く先を失って滞り、社内メディアでガス抜きをしているのかもしれない。 社員が高齢化した面もあろう。自分がまさにそうだし。
成長の鈍った企業で社員の不満が渦巻きがちなのは仕方ないのかもしれないが、社内ソーシャルメディアは空気の悪さを増幅している気がする。会社の先行きの不透明さ以前に、この空気の悪さが嫌でやめる人も結構いるんじゃないか。それは（「言論の自由」みたいなものが後押しするはずだった）組織の resillience を損ねている気がする。
まあ Twitter がそうであるようにソーシャルメディアはコミュニティのろくでもなさの投影にすぎず、まともな社員は社内ソーシャルメディアで管巻いたりせず淡々と仕事をしていると信じつつ自分もそう行動して生きたい所存。
一歩さがって、なぜ言論であるはずの社内ソーシャルメディアが組織の resillience に寄与していないと感じるのかを考えてみる。たぶん必要とされている言論はソーシャルメディアではなくジャーナリズムなのだろうな。しかし残念ながら社内ジャーナリズムというものは存在せず、NYTimes や Bloomberg のような世間のジャーナリズムに依存している。この非対称性(?) が社内の言論をろくでもなく感じる理由だろう。
社内ジャーナリズムというのは存在しうるのだろうか。たとえば Microsoft の景気減速がひと目を引いていた 2000 年代, Mini-Microsoft という匿名 MS 社員のブログが一部で注目を集めていた。これはまあまあいい線行ってたんじゃないかな。空気の悪さはかなりのものだが、当時は筋が通っているように感じた。（今読み直したらただのゴミに感じるかもしれないが。）
ただこういう本気の批評は存在しにくいよね。書き手の動機がなぞすぎる。
社内のソーシャルメディアにも単体ではよく書けた言説はぼちぼちある。ただ編集の役割を果たすものがないせいで、ストリームに消化されて終わるのだろうなあ。だれか愛社精神あふれる暇人がそうした声をきちんとまとめてアーカイブしていけば、それは社内ジャーナリズムの萌芽となろう。芽が出る前にクビになりそうだけど。
追記
この日はどこかの新聞に空気を悪くする報道があり特別荒れていたとあとから知った。
04:59
Podcast 話す内容復習。間が空いたのですっかり忘れている。
子が起きてこないのでここぞとばかりに PDFium のビルド直し。というわけで Paperium プロジェクトの中で PDFium がビルドできたぞ！これで PDFium をパッチしたりブランチしたりせずコードをたせる。今のところ別プロジェクトにするという切り口は良かったように見える。
しかしエンジニアリング的に見ると PDFium が別レポジトリに住んでるのは完全にムダだね。Chromium ツリーの一部としても PDFium 単体でもビルドできるようにする、しかし PDFium 単体でビルドするには Chromium のツールチェインが必要、とかわけわからん。v8 に Node がいるように PDFium に大きなサードパーティのクライアントがいるなら多少は理解できるけれども、Foxit は PDfium を使っているのかなあ。コミットログみるかぎりなんかしてる様子はなさそうだが。いろいろなぞ。単にレポジトリをマージする体力がないだけなのかもな。
仕事をしつつ PDFium をいじりつつ論文読む、とかやってるとなにかに集中するのが難しい。きちんと時間をとって作業してるとき以外も頭のすみでなんとなく考えているわけで、そういう時に考えるものが散漫になる。そして考える対象を変えるとコンテクストが失われてしまう。
きちんと時間をとって何かする時はそれまで頭の片隅で考えていたぼんやりした何かに形を与えるわけだが、別の考え事によってもともと考えていた何かが失われていると捗らない。
まあ仕事はある程度まとまった時間があるのでなんとかなるけど、他は割と厳しい。仕事にしても、たとえば通勤中に仕事のことを考えているか他のことを考えているかで滑り出しの順調さが大きく変わり、それは一日の生産性に響く。
Podcast やってると Podcast 準備のない日にコードを書くのがはかどらない問題の解決として、Podcast 準備とコードいじりの両方をちょっとずつやる、というのを考えていたが、この集中を失われる問題は悪化してしまう気がする。
そして課外活動を忙しくしてしまうと最低限必要な仕事および家庭への集中が失われ、それはそれで困る。
Podcast の優先度を下げるのが一番いいのだろうけれど、ちゃんと準備せず話すのはすごく気分が悪いという問題がある。まあ頻度を下げろということなのだろうなあ・・・。
これは自分が仕事でぱっとしない理由を説明してもいる：自分は業務時間の外でほとんど仕事のことを考えていない。
TL とかみてると、彼は職場にいる時間はふつうに 9-17 だが、通勤バス（推定片道一時間）の中では明らかに仕事をしているし他に趣味プロジェクトを持っている様子もない。かわりに仕事を趣味化することには大きく成功している。趣味を全面に出しすぎてコードベースにオーバーヘッドを持ち込んでいる面もあり、それはチームメイトとしては迷惑だが個人としては上手いことやったなと評価している。他のファクターをさておくと仕事はこのくらい熱心にできたほうがいいよね。
自分は他のファクターをさておけないので仕事に全部をつっこむ気にはなれず、その consequence は残念なものだが、仕方ない。なお PDFium の仕事は探せばあるかもしらんけど別に PDFium の仕事をしたいわけではないです。Podcast で食っていきたいわけでもないです。
Ten minutes a day – Alex Allain – Medium
この人は一日十分を三年続けて本を書いたと言っている。すごいね。気が散るとかいうのは甘えなのかもしれないとも思うが、どちらかというと仕事の外でできる活動は一つくらいで、そいつがこの一日十分の枠ということなのだろうねえ。
やはり podcast がんばりすぎを何とかするのが正しいよなあ・・・。
servo/webrender: A GPU-based renderer for the web
今日は向井さんが Servo の話らしいので雑談がてらちょっと眺める。Servo のレンダラ。最近は Firefox でも使おうとしているらしい。
ブラウザのレンダラを再利用可能にするというアイデアは皆が考えるけれどまず失敗するものの典型だが、これはすくなくとも Servo と Firefox で動いているわけである種の夢を叶えている。どうなってんのかと見てみると・・・。いわゆる CSS Rendering Model を扱っているのではなく、どちらかというと Skia に近いレイヤだった。ただ Skia よりはもうちょっとブラウザに寄せてある感じはする。API が retained-mode first というか only なので, immediate ぽい API の Skia より色々できるだろうと想像はつく。
思ったより普通だったが、それはきっと正しいことなのだろうな。
04:42
引き続き。どこで諦めるかの引き際も考えないとなあ・・・。
方針を考えようではないか
- Chromium のビルドシステムを使って PDFium の API を Java に公開する AAR を作る。大枠では Cronet と同じアプローチ。これが一番「ただしそう」だから。そして巨大プロジェクトをいじるときは corner-cutting しない「正しさ」は割と需要、という自説。ただ複数 CPU アーキテクチャ対応などはいまは考えない。
- Git repo は PDFium とは別に持つ。PDFium の DEPS をコピーして gclient する。これは概ね Electron がやっている方法。Electron は Chrome まるごとなのに対し自分は PDFium が対象。
- AAR のビルドに必要な Chrome の依存関係は選択的に clone する。
作業としては
- PDFium のビルドを再現できるプロジェクトをつくる。
- PDFium の shared_library をビルドする BUILD.gn を書く
- AAR をビルドする stub を作る（大変）
- 何らかの JNI のコードを stub に加える（大変）
- ビルドした AAR をテストする Android アプリを作る。
- PDFium をリンクして JNI から呼ぶ。
くらいまで行けば最低限の見通しは立つを言えよう。
やる気を出すために名前も考える: Paperium とする。なぜならフル機能の PDF には興味がなくて論文が読めるくらいでいいからである。
via Profilo · An Android performance library
コードを眺めているが・・・。すごいなこれ。
すごいところを列挙するのはあとでやるとして、Android の C++ レイヤの練度で見ると Facebook は自分の勤務先を含む多くの会社を圧倒している気がする。
たとえば Chrome なんかは単純に C++ のコードベースとして見れば割と比類ない練度だと思うけれども、基本的にはデスクトップアプリだから Android らしさというのはない。Facebook から出てくるライブラリの C++ は Android らしさを感じる。しかも Android が好きで良さを引き出そうというよりは、Android の弱点にくまなく付け込んで攻略するという方向性。これは自分の好みに近い。
自分の勤務先は根本的にはウェブの会社で、モバイル対応はなんとなく場当たり的に行われた。上の方は mobile first と旗を振ったけれど、なにをすべきなのかは誰もよくわかっていなかった。各チームがそれぞれ勝手に色々やっていたため、全社共通の基盤みたいのの整備が遅れた。さすがに今はちゃんとしてきたけれども、インフラから整然と作っていったサーバ側とはだいぶ趣が違う。そしてアプリインフラ的なレイヤを主導しているのが Java の人なせいか C++ レイヤは未だに荒野感がある。まあ Android の低レベルの仕事をしたいプログラマの多くはアプリじゃなくて OS やると思うんだよね。アプリとして C++ 書きたい人、そんなにいない気がする。
この話とはちょっと矛盾するけれども、初期にモバイル対応 (Android アプリ開発) を主導した現場の人の多くは Android OS 出身者で、自分のアプリのために Android のギリギリを攻めて行こうというよりは Android ecosystem の良き市民であろうという意識が強かった。だから platform の .so を dlopen() してシンボルをぶっこぬく、とか多分やらない。Java レイヤの hidden API を reflection でよぶくらいがせいぜい。自分たちのチームにしても、OS やデバイスがやるべきことは自分で妙なハックをしたりせず OS やデバイスの人に頼む。(自分はそれがあまり好きでないが、妥当だとは思っている。)
ふりかえって Facebook を見るに、彼らの mobile first はなにをすべきかはっきりしていた。Facebook アプリに全部の機能を詰め込んでちゃんと動くようにすればよい。そう決断したタイミングがすごく早かったとは思わないけれども、とにかくチームが、そしてコードベースが一つのアプリを中心に編成された。だからライブラリなどのインフラも大規模コードベースらしく整備されているし、よく書けてる。
しかも低レベルでいろいろやりたいプログラマに OS をやるという選択肢がない。彼らはそのかわりにアプリの中で色々無茶なハックをしてウサを晴らしたのだろう。OS のコードをコピーし、アプリ固有の事情にあわせツールチェインを魔改造し・・・といった具合に。
まあこれらは完全な想像だけれども、Profilo および依存先 C++ のコードには大量につっこまれたエンジニアリング資源の匂いがあるね。Android がアプリレイヤでどこまで無茶できるかを体験するには面白いところなのだろうな Facebook. まあコード読んで勉強させていただきますわ。
何人かやってる人がいる。
でもぜんぶ Chromium way にするのが正しそうだなあ。同時に一番茨ではあるが・・・。
05:05 段々起きる時間が遅くなってる. 昨日は寝る前にちょっとコードをいじったら案の定寝付きが悪くなってこの有様. 寝る前に読める無難な紙の本を探そうかな...
今日は PDFium ビルドつづき
- 自分で書いた Makefile と Ubuntu の Clang を使ってビルドしようとしているが, C++ stdlib のシンボルらしきものがみつからずリンクエラー... と思っていたがよくみると instantiate された std::vector がないのか。なんで？結局 libpdfium.a だけでではだめなのかな？ basic_ostream とかもまじってるので結局はライブラリな気もするが...
- __next_prime() とかはやはりランタイムの一部でヘッダで定義はされてないぽいのでライブラリが必要。これは Chrome が持っている Clang 系列の C++ ライブラリ。一方手元の clang は /usr/lib/x86_64-linux-gnu/libstdc++.so.6 を参照しており、これは GNU 由来っぽい。問題は２つあって
- Clang 由来ではなく GNU 由来の C++ を使っている
- そもそも Chromium はライブラリ含め自分でビルドした C++ ツールチェインをつかっている。
- というわけでシステムのツールチェインではなく Chromium のもってるツールチェインを使わないとダメなのではなかろうか...まじで？ それライブラリとして使えないじゃん・・・。しかし Ubuntu の Clang とはじっさいだいぶバージョンが乖離してるのでダメそうだな。
というわけで一定程度 Chromium の流儀でコードを書く必要があるのは受け入れねばならなげ。あるいは自分で Makefile や Bazel のビルド設定を書く、だけどそっちはより茨度高いからねえ。そもそも Android の Chrome は PDF 見れないので、いま Android+aarch64 向けにビルドできてるのも歴史的残滓の可能性がある。(AArch64 自体は Chromebook もあるからサポートするだろうけれど。) うーむ・・・。まあそれはいま気にしても仕方ない。
Cronet の BUILD.gn を見てみる。まあこういう感じでやるのだろうなあ。そしていよいよ Chromium のツリーがいるのでは・・・。あんなでかいもんチェックアウトしたくない・・・・。一方で Chromium のツールチェインにくっついている以上 v8 と違ってもはや単体での利用は非現実的なのだから Chromium のツリーに入れてしまえばいいのにと思ってしまう。Blink ですらマージしてるってのに。世の中にはこれをなんとかビルドして使ってる人がいるのかなあ。
あらためて DEPS を睨んでいて気づいたが、googlesource.com の git は何らかの頑張りにより git レポジトリのサブディレクトリを独立した git repo として clone できるっぽい・・・。なかなか狂ってるなあ・・・。こういうのを駆使すれば Chromium の必要なサブセットだけを持ってきて使うことができ、実際 PDFium はちょっとだけそういうことをしているわけだが・・・茨の道としか思えないのだった。しばらく見ない間にまただいぶ独自世界化が進んでいる Chrome の世界よ。
そして v8 を見ていて気づくこととしては別にこいつも out of box では単独ビルドできず Chromium のツールチェインを使うね。Node.js は、単に開発者ががんばって追従してるのだろうなあ・・・。
時間切れ。
Android 用にビルドできないかなんとなく試してみる。
PDFium から AAR を作るにあたり Chromium のビルドシステムに乗ればラクなのでは、とか思ったが気の迷いだった。Chrome のネットワークスタックをライブラリ化した Cronet の BUILD.gn を見るとが何らかの方法はあるように見えるが、これたぶん Chromium のツリーまるごとないとダメだよね。それは嫌です。
Halide がやっているように PDFium を C++ のライブラリとしてパッケージ化して Bazel の BUILD ファイルをつくってやり、それを使う、くらいでいいかなあ。
少し前に JIRA is an antipattern という記事があり、盛り上がっていた。どうも ticket を assign するという形で micromanage されることがあり、それが嫌という話らしい。
これはツールの濫用/誤用であるというのが主要な反論で、そうだろうとは思う。一方でツールやプロセスが暗に促す方向というものもあり、JIRA は micromanagement を遠ざけるような力を持っていない。それはそれできっと事実なのだろう。
自分は勤務先内製の bug tracker に長いこと不満を持っているわけだが、ひとつだけ良いこともあると気づいた。このツールは管理職が下々を micromanage するには出来が悪すぎるのである。一方、むかし Pivotal Tracker を使っているチームの TL/M によるものすごい micromanage を目撃したことがあり、あのチームでだけは働きたくないと思ったのを覚えている・・・というのは嘘で、当時は Pivotal いいなー使ってみたいなーと思った。しかし今振り返るとアレはないわ。無理。
そんなことを考えたきっかけは、やはり少し前にあった Why 95 Percent of Software Engineers Lose Nothing By Unionizing という記事。これを書いた mchurch というのは HN から ban された過去を持つ筋金入りのクソブロガーだが、それでも Scrum とか micromanage だよね、という話は自分の心に刺さるものがある。
なぜか。自分が昔々 Scrum ごっこをしていた頃のことを思い出すと、あれは micromanage だったと思うからだ。当時の自分はどちらかというと manage する側だったので「うむ、チームワーク」とか思っていたわけだけれど、他の人はどう思ってたのかねえ。管理されてる感あったんじゃないかな。
Scrum や Agile は teamwork の皮をかぶった相互監視 micromanagement methodology である・・・と主張するつもりはない。Agile が people を empower することはできると思う。一方で JIRA と同じくこうしたプロセスというのはどうしても管理者、あるいは管理性向のある個人に濫用されがちで、それを防ぐ仕組みも特にないのではないか。
Agile に関する語りはだいたいそうした管理者や管理性向パーソン ("scrum master") によって行われており、これは管理職やリーダシップに関する語りと同じ問題をはらんでいる。つまり、あなたの周りのひとはほんとにハッピーになったんですかね、という問いには答えてくれない。
出来損ないの agile が招く潜在的な micromanagement から身を守るには自分とその周辺の仕事を自分で manage しておいた方がよくて、そのためには逆説的だけど軽く agile のような計画の話とかを勉強するのはいいんじゃないかなあ。GTD とかの生産性ライフハックだけだとちょっと心もとないよね。
自分も何か読み直そうか。10 年前からなんか進歩したかな agile 方面。Lean がでてきたくらいだろうか。調べないとわからないね。
チームの人が増えた影響などで、コードレビューをする機会が多くなってきた。自分は前のチームではあまりレビューをせず、その前もそんなにせず、つまりあまりレビューをして来なかった。しかしいよいよレビューする側になってしまったかんじ。まあ税金なので仕方ない。
で、どうも言葉遣いが乱暴というか blunt になりがちでよくないなと気づいた。昔々オープンソース仕事で他の会社のひとが書いたものをレビューしていたころはかなり気を使って丁寧な言い回しをしていたものだけれど、そういった気遣いが完全に失われている。
オフィスが近所で立ち話したりランチたべたりする機会があるならまだいいんだけれど、remote の人が相手だったりするとほんとに気をつけないと関係を損ねてしまう。しかも自分が微妙に authority を持っているせいで、相手が不満を口にせずただ黙って hate をためてしまうこともありうる。それは困る。
というわけでコードレビューの言葉遣いは気をつけないといけないし、特に remote の人が相手の時は人格を切り替えていかねばなあ。
そういう意味で自分の今いるチームはあまり参考にならない。Remote の歴史が浅いせいか人々はオフラインで話をつけがちだし、いちばん権力のある TL はだいぶエラそうというか blunt だから。そのへんは remote 歴の長いチームの方が勉強になることが多い。あの頃レビューをしてくれた人たちはだいぶ気を使ってたのだろうと今になると思うが、昔のことすぎてどんな感じだったかすっかり忘れてしまった。
性能仕事には色々イヤなところもある。
なにかと組織やコードのダメなところにでくわしがちなのも、イヤさの一つ。どんな仕事も多かれ少なかれダメさと戦う必要はあるが、性能仕事はその程度がひどい。コードにしろ組織にしろ抽象化なりプロセスなりでダメさを隠そうとするわけだが、性能は隠せないので。
わかりやすい例として、レガシーコードの奥の方が遅いみたいなやつ。速くするにはそのレガシーコードを触らねばならず、ウっとなる。性能改善に Anti-Corruption Layer はない。
組織のダメさでいうと、マネジメントの意向でインテグレートすることになったよそのチームのコードが遅い、みたいなやつ。そのコードは特段ひどいわけではないが、しかしよくわからん・・・みたいになる。
別の組織のダメさ。なんで性能関係の CI 無いの？と思って追求していくと SWET/QA 部門と開発チームのつなぎ目にある crack に落ちてた・・・みたいなケース。
こういうのが次々と出てくる。
自分はなるべくダメさに怖気づかずズカズカ入っていって直したいと思っているのでそのように振る舞っているが、ダメさに向き合っているとどんどん仕事やコードや組織が嫌いになっていくという問題があり悩ましい。Burn-out しないよう程々にしないとなあ。まあ九時五時で働いているとなかなか burn-out するほど消耗しないけれど。
05:27 於 Starbucks. 雨なせいか他に客がいない。一番乗り。
今週は家の設備トラブル対応で金曜に podcast を録音できなかったため・・・ちょっと心に余裕があるね。
- この "MN" 記事が邪魔くさいので他のブログに移そうかと思ったが・・・めんどくさいので保留。
via I interviewed at six top companies in Silicon Valley in six days | Hacker News
また HN が大企業コーディングクイズ問題で荒れていた。自分の見解は前に書いたが、この話はコーディングクイズを肯定する前提で書いた。HN のトップコメントはしかしアンチコーディングクイズで、しかもなんとなくわかってないなあ・・・と感じてしまった。
なお以下の話は自分の意見であって別に勤務先などの見解を反映していない。
コーディングクイズがアルゴリズムを書かせがちなのは、別に CS の知識的なものを問いたいわけではなく、プログラミングの筋肉みたいなものを知りたいからだ。プログラミングには筋力/体力みたいなものが存在する。それは綺麗な抽象化を考える力とかアルゴリズムの知識とかではなく、目の前の積み上がったミクロな複雑さの山を押しのけてズカズカと前に進んで結果を出す速度みたいなもの。
アルゴリズム類のコーディングには抽象化でごまかせないむき出しの難しさがあるので、体力を試すのには割と向いてる。
体力が導く「成果」はかならずしも最終的な成果ではなく、試行錯誤のマイルストンに近い。目の前に自明でない問題がある。ここでいう問題は原因不明のバグかもしれないし、API デザインみたいなものかもしれない。そこでガガガっと色々試して解空間を探索して良い答えを出す力が筋力。知識があるほどよい初期解を選べる。体力があるほど広い空間を探索できる。
そういう筋力を使わずにできる仕事、良い初期解の近傍で乗り切れる仕事はたくさんある。そういう仕事の多くでは、規模から生まれる複雑さがプログラミングの主要な、しばしば唯一の、敵である。一方で世の中には筋力がないと解決できない仕事もある。そして実際に筋力がある人の働きを目にしないと、世の中にそういうものがあることには気づけない。
筋肉質な仕事ぶりを目にすると、ああアーキテクトとか別にどうでもいいな、という気持ちになる。規模に頼らなくても意味のある成果を出せることがわかるから。
体力だけあって抽象化とかの技能がないとそれはそれでやがて破綻する。けれどテック大企業、というと一般化しすぎだけれど自分の勤務先とかはそういう筋力で解く姿勢を重く見ている気がする。表立ってそれが語られることはなく、表面的には規模の複雑さを扱うほうが偉くなれることになっているが、空気を流れる ethos は筋肉を志向している、気がする。それを端的にあらわしているのがたとえば Jeff Dean Facts のような subculture である。
そういう価値観は必ずしもいいことばかりではなく、わかりやすい欠点としては manliness や heroium に傾倒しがちで teamwork や inclusiveness とは相性が悪いなど副作用もある。良くも悪くもそういうものというだけで。昨今の diversity awareness の高まりから生まれた古い subculuture に対するカウンターにはその綱引きを見ることができる（例 1, 2）。大企業はでかいだけあって価値観も一枚岩でない。ただ採用の仕組みとかは早い段階に固まってしまいがちで、結果として proto culture が染み出すのだろう。
そして自分は後ろめたさを感じつつこうした古い価値観を一定程度 preach しており、だから冒頭のようなコメントを読むとため息ついちゃうんだろうな。Manliness が大事って話じゃなくて、ばばばっとコード書きたいなということね。
筋力がないのに筋力がある人のように働こうとすると、初期解近傍で妥協するかわりに時間をかけて広い解空間を探そうとして仕事が遅い人になってしまうのだった。困る。しかしちょろい仕事をぱぱっとやるとかマジもう興味ない。価値観の呪い。
しかし冒頭のコメントの人は抽象化が大事とかいいつつコーディング練習するヒマがあったら乗っかるフレームワーク考えるのに時間使いたいわとか言っていて、現代における抽象化というものを考えてしまうよなあ。
このごろ、やってることというか問題領域が周りの人とかぶることが多くて若干めんどくさい。しかもかぶってる相手が TL-like な人々だったりするので余計に。
TL-like な人々と仕事が被るのは自分の扱っている問題意識が正しい可能性を示唆しているので悪いことではないのだが、解決へのアプローチが違うとそれを調整する必要があり、それはつまり基本的には相手のやっていることに合わせつつ必要に応じて手直ししてもらう、みたいなかんじになる。めんどくさい。
傾向としては TL-like な人々は何らかの best practice を探してきてコードベースをそれに近づけようとする。自分は目の前の問題を pinpoint で解決しようとする。一般的にどちらかいいということはできない。best practice の適用範囲に自分たちの製品がいるとは限らない一方、自分の pinpoint な解決が code health を損ねるだけの local optima である可能性もある。
ただ best practice 路線はいまのところ目の前の問題をずばっと解決してくれないことが多く、目の前の問題をずばっと解決したい自分としては困りがちで、調整が必要になる。
TL-like people は使える report がいたり近隣チームの人をよくしっていたりするので、仲良くしておくに越したことはない、しかしかったるいという話。根本的には言語能力の不足な気もして、なかなかしんどい。
会社での勤務時間中は step back して問題について考え直す、という頭の使い方がなかなかできない。
なぜかと考えるに、仕事中はどうしても英語で物事を考えがちで、それが自分の思考能力を律速している面がある。ただそれだけでもなく、最近は問題について考えるときに、その解決方法をどうやって他人に説明するかと joint で考えがちなのが良くないなと思う。
今の仕事は他人、特に近隣チームの人を説得、合意形成したりその人たちにお願いしたりする場面が多く、結果として「提案の仕方」を軸に物事を考えてしまう。もっというと脳内でそうした人々と会話したり、実際に相手のデスクに出向いて軽く温度を調べたりする。他人と話して inspiration を得ることもあるわけだが、言語能力が高くなかったり相手が押しの強い人物だったりすると問題を矮小化してしまったり、変に（最終的には正しくないとわかる）意見を押し付けられてかえって自分の解空間を狭めてしまうことがある。
なので他人と話す必要性のプレッシャーをなんとかして保留し、問題の解決方法に集中して考えるのが良いのだろうな。しかしオフィスは他人に溢れているからそれが難しいのだった。
考える必要性がある程度溜まったら WFH というか Work From 通勤途中のスタバ、みたいにしてなんとか自分をデタッチしたほうが良いのだろう。というかスタバまで行かずなんとか近隣のオフィスで考え事のできる場所を探しが方が良い。自分のいるオフィス周辺は建物の建造が人の増えっぷりに追いついておらず、かつてないほど詰め込まれているのだった。東京オフィスより狭いのでは、みたいなかんじで厳しい。
05:17.
仕事のストレス高まりにともない課外活動のやる気が侵食されている。しかしで家では疲れ切っており仕事日記をかくなど仕事について考える余力がない。結果として仕事がはかどらず、というデッドロックが発生しているので今日は週末だというのに仕方なく朝から仕事について考えたい。
Facebook が公開した Spectrum というモバイル画像ライブラリのコードを眺めていたら FBJNI というライブラリが含まれていた。Spectrum のみならず FB の JNI 依存プロジェクトには軒並み含まれているので、社内ライブラリのスナップショットをコピーしてるのだろうな。
コンパイル時プログラミングで JNI の method signature string を生成してくれるのが素晴らしい。独立したライブラリに切り出してくれないかなあ。
05:56. 昨夜は夫婦会談をしていたら遅くなってしまった。しかし夫婦は話をしないと崩壊しがちなので会話重要。
- コードでも書くか、と思ったがいまいちやる気が起きない。Halide チュートリアルも、なんか詰まってた気がするが記憶が失われた・・・。
- やることリストを見直す。これらの細かい hello work をやるのは、まあいいかもな。ということでやる。
- Podcast の予習を調整することでコード書きをしたいと思っていたが、単純にたとえば週に 1,2 日コード書く日を作る、みたいな方針は間があいてコンテクストが失われるので厳しいな。Write Every Day とまではいかなくても何らかの continuty というか momentum を保つ仕組みが必要・・・。
というわけで Bazel + Android + Java.
- bazel を blaze とタイプしてしまう程度には忘れている・・・・
- Android Studio を 3.3 にあげた... らどうも Bazel plugin は 3.3 未対応らしい (Bug). Sigh. しかし自分でビルドできると書いてるのでいちおう試してみる。
- おお大した準備なく普通にビルドできる。すごい。期待低いというかもしらんけどこれ IDE のプラグインだからね。ビルドシステムつくってるやつらのプロジェクトがちゃんとビルドできるのは live up with the expectation であることよ。GitHub の issue に zip の在り処をコメントしておく。
- なお この IntelliJ plugin はいちおうオープンソースだが、実際は copybara というツールで社内の monorepo から sync しているだけの downstream っぽい。まあいいんだけど。
- Bazel を Anroid Studio で使う記事が docs.bazel.build のみならず developer.google.com にあるのだが・・・。こんなもんを endorse するとか正気なのだろうか。1.0 ですらないのに・・・。まあ公式サポートにさしたる意味がないのは昔からだけど、やれやれというかんじだな。
- Bazel のバージョンも上がっていたのでいちおう追従しておく。
- ANDROID_HOME は .bashrc のみならず .profile でもセットする必要あり・・・
- 仕事は色々制約があるが動くはずのものはなんもしなくても正しく動くのでこういう雑務は spoil されがちだなー・・・。
04:50. 雨が続いて運動不足なせいか気分がどんよりしがち・・・。
- 関連論文ざざっとながめてノートに追記する日。
- 次なに読むかなー・・・
04:57.
ノート準備。しかし書き込みした論文を会社においてきてしまった・・・。そろそろ電子化したい気もするが、あんまし良いデバイス候補がないね。まあ iPad がいいのはわかってるんだけど、iOS の世界に住んでないので気乗りしないのだった。
4:40. 家族の行事に押され間が三日空いてしまった。コードでも書こうと Podcast 準備のペース調整をしていたぶんは失われた。Sigh. まあそういうものです。
論文つづき。
High memory pressure 環境下でのアプリの挙動を調べたりしている。Android は、すくなくとも userdebug build なら top や vmstat が入っているのでその結果を眺めているのだが、vmstat の結果はチャートでみたいなあ。要件としては:
- vmstat のみならず /proc/meminfo もチャートにできるとなお良い。特定プロセスの /proc/pid/status も。
- 事後的に生成でなく、1 秒間隔の疑似リアルタイム表示はしてほしい。
- グラフを、できれば HTML で欲しい。画像ファイルでも良い。とにかくファイルに保存して URL addressable な場所に置いてバグトラッカーなどから参照したい。
非機能要件/非要件としては
- どっかのサーバで動かすのは NG. 手元の ADB にアクセスする必要があるから。あとサーバは保守するのがめんどいので。手元で agent だけ動かしてサーバはリモート、とか理論上は可能だけど overkill.
- インストールが面倒なのはナシ。npm とか同僚に頼めないので不可。single binary か、社内のツリーにコードをホストしてビルド方法共有くらいが限度。
- 手元のマシンは超はやい。localhost で動かすならネットワークも（あたりまえだが）超速い。
- デバイスへの負担は少なくしたい。一方でデバイスにバイナリを置くのも面倒なのでできれば避けたい。adb shell でやれる範囲から始めたい。
条件反射で考えたのは Electron で直にコマンドを実行しつ結果を描くか何らかのローカルサーバから websocket だったが、一秒に一回なら iframe なりに SVG を毎回再読込でよくね？と気づく。20 世紀方式とも言える。そんな昔じゃないか。Pre-Ajax とも言える。これは static HTML を S3 的な場所に置いてシェアするのとも相性が良い、かもしれない。
というわけで
- サーバはメトリクスごとに json で timeline を返す endpoint を持つ。
- ページの JS はその endpoint を叩いて SVG なり canvas なりに書く。
- HTML のダンプは、指示があったタイミングで最新の snapshot の json を埋め込んだファイルをどこかに書き出す。
というかんじでいけるかな。これだけシンプルなら plain JS を HTML に埋め込む形で開発してもなんとかなるでしょう。
なあローカルサーバを何で書くか。反射的に考えると Python だが、社内は python 事情がよくないうえに若干性能が心配であることを考えると Go かなあ。Go よくわかんないので勉強しないとね・・・。
05:05. デイケアで昼寝しすぎてるせいか子供の寝付きが悪く、結果として家全体の就寝が遅れ、朝が遅くなる。もうちょっと昼間遊ばしといてくれないもんかなあ。一年後 preschooler になった日にはそんな心配ないのだろうけれど。
- ノートは昨日でだいたい書けたがちょっと直しがあるのと、来週分の論文読み。
- 資料みながらノートを直したりしてたら時間ぎれ。
05:24. トラブルで出遅れ。寝坊じゃないんだけど。
ノート続き。開始が送れると時間が減り、結果として進捗が下がる、ということが目に見えてわかるのでこうして記録をとるのには一定程度意味があるな。
05:15. 夜にダラダラして寝るのが遅れた。就寝前のリズムが乱れててよくない。とにかくさっさと風呂に入り、そのあといつ寝てもいい状態でダラダラするようにしないといかん。スマホとかみてるとだめ。
で、ノート書き。
04:56. 旅行などで３日空いた。そしてまた目覚ましつけ忘れ。
論文続き。
- 今日で一旦最後までたどり着きたい・・・。
- たどり着いた。とりあえずノートにダンプ・・・。
via amakanサービス終了の経緯 | r7kamura on Patreon
シリーズ情報は誰かが提供してくれるものではないため、書籍の名前、カテゴリ（漫画、ライトノベル、雑誌など）や作者を amakan 側で解析し、良い感じに分類するということをやっていました。
前のチームにいたとき、漫画のタイトル（など）からシリーズを検出してまとめるコードの日本語対応をしてちょと頼まれ、適当に正規表現を書いた記憶がある。リンク先にも書いてある通り、書誌情報にはシリーズ番号が入っていることもあるが、入ってないこともあるのだった。
元のコードに正規表現やその他の細かいコードを足せば大体動いたが、それなりに奇妙なケースもあって (1上、1下... 3上、3下 みたいなのとか)、そういうのをちゃんと動くようにしたかは覚えていない。最後に計算量を変えるような微妙なコードを書いたがレビューされなかった、やんわりとした悲しみが残っている。
そのバッチは Cloud Dataflow の前身 FlumeJava で書かれており、自分が書いた唯一の production big data コードとなった。まあ正規表現なんだけど。
Flume みたいな並列のコードからガバっと叩いてバッチでデータ処理してもびくともしない Megastore だか Spanner だかはすごいな、という感想を持った。