課外活動ではじめたはいいが脱落してしまった Snippet Train, 課外活動はともかく仕事ではこれに類する何かは欲しいなあ、と思っていたところ似たような要望を聴いたのでちょっと紹介文書を書いた上ではじめてみた。一ヶ月くらいたったけれどそこそこ続いている。参加者はチームの半数は超えており、安定した感じはあるので自分がサボらなければ続くであろう。そして自分は「スレッドを始める」という責務を持っているので続ける気がする。
投稿を nudge するメールは、自動化できなくもないけどなんとなく人間から届く方がいい気がしている。人々は機械からのメールを無視するのに慣れすぎているので。
Snippet train, チームに欲しいとは思っていたが言い出すほどでもないと感じていた。ただ timezone の違う国にチームができて分散が進み、チームの中でも inter-site のコミュニケーションをなんとかした方がいいという機運が高まったため、それに便乗できた。
一週目のスレッドも実は難産で、「メールのスレッドに返信する形で投稿する」というコンセプトが理解されず自分の投げた一通目からあとが続かなかった。しかしある同僚が「俺も snippet 投稿したいんだけどうすればいいの？」と訪ねてきたおかげで、デスクまでいって「そのメールに返信すんだよ！」と横で背中を押すことができ、仕組みを demonstrate できた。そのあとはわりかしスムーズに続いた。新しいプロセスを始めるに当たってはサクラが必要という話。この TED Talk そのまんまですが・・・。
西海岸タイムゾーンではいまだに weekly standup meeting をやっている。個人的にはいらないと思っているが、週に 30 分くらいのためにケンカしても仕方ないので参加している。じっさいこのミーティングはそれをきっかけに人々が（ミーティング後に）議論をはじめることに成功している。Snippet Train はそれができてない点で相対的に動機が弱い。
たぶん今は snippets が箇条書きだけで dry すぎるのが問題で、もうちょっと軽く nuance/tone を添えられると議論の種になるなど status updates としての価値も増すと思うのだが、意義を高めるにはまだ iteration が必要そう。自分がチーム内でザコすぎるためいまいち cultural change を drive できないのが若干残念。
Apple のサイトで自分たちの podcast の analytics をみていると、昔の録音を聴いている人が一定数いて興味深いなと思う。過去 60 日の統計、新しいエピソードはだいたい 500-700 listeners のあたりを推移している一方で昔のやつも 30 くらい聴いている人がいる。
自分たちの podcast は時事ネタでもないので昔のやつを聞いても特に問題はないが、一方で世の中他に聴くものいっぱいあるべ・・・という気もする。
が、ここ数日 Exponent の backnumber を聞いている自分を発見して、ああこれかという気分になる。つまり意外と聴きたいものがなくてバックナンバーを聴いてしまうことがある。Exponent なんてもう 5 年くらいやってるのでバックナンバーも豊富。バックナンバーの豊富さだと ATP は更に上なわけだが、今は ATP 聴きたい気分でもないのであった。
理論上は Audible で本をみつけてきて聴く方が有意義だと思うが、本を探す気力も長いものを聴く気力もないときってあるじゃん。あと直前に聞いた audio book にがっかりした記憶が新しいと、本に近づく意欲が下がる面はある。
というわけでサイトのサイドバーにバックナンバーを出すようにした。まあバックアンバー聴くような人はだいたいアプリ使ってるだろうけれど。
2014 年あたりの Exponent を聴くとテックへの風当たりみたいのが全然違って興味深い。このころは暗雲の気配こそあれまだ楽観的だったね。だから引っ越してくる気にもなったわけだけれども。自分が転職した 2010 頃はどんな空気だったのか、2014 年より更に utopian だったはずだが今となってはマジで思い出せない。
あと Exponent, James が co-author した How Will You Measure Your Life の話をしているのも良い。まあメインの著者は Clayton Christensen で James はちょっと手伝っただけだと思うけど、割と好きな本の話を当事者が話すのを聴くとちょっと楽しいね。
via Antitrust 3: Big Tech : Planet Money : NPR
Planet Money が三回シリーズで Antitrust を扱っていた。その中で紹介されていた論文 Yale Law Journal - Amazon’s Antitrust Paradox, NYTimes で紹介されたのをきっかけにブレイクしたという。自分も antitrust まわりに気をつけるようになったのはこの記事がきっかけだった。論文は 1/3 くらい読んで放置してあるが・・・（長いのだよ。）
別のきっかけは Exponent の Episode 153 — Black Holes. 上の論文は Amazon の分割を提案しているらしいけれど、このエピソードでは Facebook による競合の買収を問題視している。NPR のエピソードでも同じことを主張する人が登場した。
Tech 大企業はいっぱいあるので、一社が（たとえば倫理的な判断から）買収を遠慮したりすると、別の会社に攫われてしまう。競争がある故にいろいろえげつなくなりがちな面はある気がする、ので法が頑張るのはそんなに悪くなさそう。ちゃんと機能するのかは疑わしいが、やってみて機能したりしなかったりするなかゆらゆらと調整するのが民主主義、法治国家の歴史だとも思う。
そういう法律は大企業だけでなくスタートアップにも影響ありそうだよね。主要な exist path だった買収に暗雲が漂うわけだから。
いずれにせよ Antitrust はもうちょっと色々読むなりして心の準備をしたいかんじ。
06:10 @Starbucks. 家事してたら出遅れた...
最近は weekly review といいつつ blog 書いて終わってる日曜朝であることよ.
via Block ads in apps on Android (including video ads) - unlike kinds
フーンどうやるのかな、とおもってコードを覗こうとしたが GPL3 だったので諦め。周辺情報を総合すると VPN として振る舞うらしい。
これを使えば /etc/hosts の代替品となるのではなかろうか。でも VPN ってことはアプリをぜんぶのパケットが通ってくのかな。それは雑に作ると性能でなそうだが・・・。
そしてなぜか app store でなく f-droid で配布してるけれど、Ad-blocker は Playstore の規約に触れるのかな。まあ触れてもおかしくないな。自分用なら adb install すればよさそうではある。
サンプルの ToyVPN を見ると・・・ IP packet がストリームとしてやってくるのか。厳しい。一方で VpnService.Builder をみると DNS を指定できる。
なんとなくインプロセスの DNS を実装してそいつが /etc/hosts 的に twitter.com などをブロックし、IP パケットは素通しする、というような実装ができると一番簡単に思えるがどうなのだろうな。素通しは必要なシステムコールを特定すればなんとかなるとして、インプロセスの DNS は手強い・・・。なお ToyVPN は linux の tunneling の仕組みに丸投げする実装になっている。
DNS はインプロセスじゃなくてどっかに自分で立てる、という方向性もありうるか。どのみちそこまでがんばって実装する気にはならないなあ・・・。
ここまで。Android の VPN の API を眺めることができたのでよしとする。
更にスレを読み進めると、Android P はユーザが DNS サーバを上書きできるのか。(Cloudflare の説明) これでやるのが一番簡単そうだなあ。しかし DNS サーバを運用するのみならず DNS-over-TLS をサポートしたやつを使うとか大変そうすぎる・・・。誰かそういうサーバ立ててくれないかなー・・・。
via You probably don't need a single-page app | Hacker News
自分も手元に SPA の悪口を書いた draft があるのだが、世間での hate が高まっているところに加えて言うこともないかなと思う。
なお自分は不満は開発者としてではなくユーザとしてのものである。すなわち世のウェブ製品や内製のツールが SPA になったとたん URL が壊れるなど激しくゴミ化する現象が観測され、気に入らないという話。出来の悪いコードというのはいつの世にもあるのだけれど、内製ツールという観点だとダメージの現れ方が厳しいと思う。
この話は長々書いても悪口にしかならないのでやめとこう。
それよりは、出来の悪い SPA はなぜ生まれるのかを考えて見る方がいい気がする。個人的には Web というプラットホームが十分な基盤を提供してないせいだと思う。JS フレームワークの未熟さみたいのはそのうち解決するだろうから。
SPA は、伝統的なウェブにあった URL 単位の "画面" という単位が希薄になりがちである。その昔, URL はユーザにとっては文脈を特定するコンパクトな表現であり、同時にウェブアプリにとっては serving というわかりやすい抽象化の単位であった。つまり URL のわかりやすさはユーザにとっても開発者にとってもある程度有り難みがあった。
ところが SPA になると開発者にとっての URL は単なる負担になる。画面という抽象化の単位に自動的に URL がつかなくなるから。なのでサボって腐ることが増える。ウェブやブラウザという patform は、ウェブプログラマに良い URL をデザインする incentive を用意しないといけない。そうしないとサボられてしまう。
素人の意見としては TurboLinks みたいのをもうちょっと洗練させて標準にすればよいのではないかと思う。つまり、JS のコードやある種のサイトグローバルなデータはインメモリに残しつつ、ページ単位のデータを新しい URL のもとに取得しなおす。ある意味では JS フレームワークの router みたいなもんだが、それを何らかの形でブラウザが提供し、それは JS だけだと実現できない何らかの有り難みがあるとよい。
完全に口から出まかせを続けると、そのためには API から serve される JSON が一級市民にならないといけない。もっというと "JSON のレンダリング" みたいな概念が一級市民として必要に思える。20 年くらい前は XSLT がそれだったわけで、XSLT は概ね失敗したのでたぶん普通にやると失敗するからもっとうまくやらねばならず、自明でないデザイン上の難さがある。Service Worker からもう三歩くらい進めばなんとかならない？だめ？
URL がぶっこわれていてリンクも scrape もできない dashboard や CRUD UI は心底うんざり。そういうのを作ったやつが悪いのは確かだが、ウェブがしゃきっとしないから治安が悪くなったのも事実だと思うのだよね。
Android だと Activity がプラットホーム提供の画面単位の抽象化単位として機能している。Activity をすっとばした SPA 的アプローチも一瞬流行りかけたが、今のところ主流にはなっていない。React Native にやられてしまうかもしれないけれど。
ウェブも Android も React にやられかけているというのは興味深い現象であることよ。
臨席の同僚が "なんとか deep dive" というような文章をチームにシェアしており, それは要するにアプリの特定の困った挙動についてコードをよく読んで調べたよ、という話だった。
なにか違和感を感じたのは、deep dive と銘打ってやっていることが自分の普段の仕事みたいなものだったから。それ別に deep dive 呼ばわりするようなものではないのでは、という。
その人はチーム歴が比較的浅いいわゆる TL/M で、割とばりばり仕事ができるタイプ。こういう getting things done な人は普段から無駄にコードを読んだりせず、もっとゴール駆動で作業するのだろうなあ。
一方で自分は getting things done への passion が不十分で、それよりはコードを読んだり色々調べたりして目の前の事象に詳しくなることを優先している。これは成果を求められている会社員的にはあまり望ましくない。個人的には getting things done のために "deep dive" を犠牲にしたいとは思わないけれど、そのコストは自覚して deep dive の "成果" を意識的に仕事に還元することは考えが方が良いかもなとはおもった。たとえば notes を書いて流すといった形で。コード以外の成果の割合を増やすのもそれはそれでいまいちだけれども、無駄に調べものしたりしている間はコード書いてないので仕方ない。
仕事は完全に gtd に倒し、知的関心の探求は課外活動に回すという選択肢はある。ただ、いまの自分の仕事はそれなりに面白い questions を提供してくれるので、それを表面的に片付けてしまうのは勿体無い気がしている。望ましい振る舞いは仕事次第な面はある。
Android の昔からある高速化 tips というか性能アンチパターンとして onDraw() でのメモリアロケーションが挙げられているがホンマかいなと思う・・・
・・・と書こうとして証言を探したが、公式ドキュメントは割とまともだった (1, 2). 特に後者は "Object allocation and garbage collection (GC) have become significantly less of an issue since ART was introduced ... Note that significant amounts of allocation can mean more CPU resources spent on GC" とページを締めくくっており、これがまさに自分の言いたかったことなのだよね。ついでにいうと onDraw() は別に毎フレーム呼ばれねーよ、というのがある。
なぜこの話を書こうとおもったのか忘れたけれど、古い知識で性能しったかぶりするのはよくないから実際に測ってからなんか言おうね、といういつもの話でした。まあ GC の影響は測るのが難しいから公式ドキュメントが cargo cult busting してくれてるのは良いことである。Android の公式資料, たまにちゃんと書かれてるね。
早朝活動、仕事には支障がでてないフリをしているけれど若干でている事実を認めざるを得ない。つまり、ちょっと眠い。そして退社前に疲れて集中できなくなる。
さいきん週に一回くらい家族三人で cosleep する実験をしている。Co-sleep は良いところもある。この NYTimes のエッセイの気持ちもちょっとわかる・・・というのはさておき、子供とねると 20-21 時から 6 時まで 10 時間の睡眠となる。翌日は会社での調子がすこぶる良い。眠くならないし疲れない。
今は 4:15 に目覚ましをならし、うだうだスマホを眺めて顔を洗って・・・と五時前に課外活動を初めている。しかも夜もなんだかんだで 21:30-22:00 までダラダラ起きてしまう。睡眠時間は 6-7 時間。やはり最低 8 時間は寝ないとダメだなあと思う。
就寝前のダラダラを減らせばいいとわかっているのだけれど、夜は疲れ果てて意識レベルが下がっているので「風呂に入って寝る」というルーチンすら億劫でもたもたしてしまうのだよなあ・・・。
via google/mobly: E2E test framework for tests with complex environment requirements.
最近性能テストの自動化にこれを使っている。まあまあ良い。良さの一部は lab の実機で CI するインフラを誰かが用意してくれているから、というツール自体とは無関係なものだけれど、テストコードが host 側で動き、しかもそれが Python だというのも良い。
原則としてこうした E2E のテストは保守性の点で望ましくないことが多く最小限にすべきなのだが、性能のベンチマークばかりは実機でやりたいし、環境をいじる必要もあるのでホスト側の adb で色々やりたい。そして自分の関心は特定のコードの挙動でなくシステムとしての遅さなのだった。
Mobly をランダムな他人に進めるかというと・・・どうだろうね。ちょっと大げさすぎる気はする。しばらくは plain python でがんばってみて、辛くなったら調べてみるくらいでいいのではないかな。ホスト側でテストを動かすというコアのアイデアが重要だと思う。
それはさておき仕事で python を書くのは新しく学ぶことが多くて楽しい。文法とかは今更特に学ぶところはないが、社内インフラをはじめ色々なライブラリを使い、他人のコードレビューを通せる程度にはゴミでないコードを書くと、余暇プロジェクトや書き捨てのスクリプトとは違う仕事の手触りがある。
他人になおしてほしいが困るのは自分、というバグがある。バグトラッカーには owner の概念があり、これはふつう直す人を意味するが、直す人とそのバグがなおる事実を気にする人は別なことが多く、（例: API を実装する人/使う人）なおる事実を気にする人が誰かをコミュニケートする良い方法がない。
これは自分の周りではどう解決されているかというと、基本的には TPM や EM が「直る事実を気にする人」を代表し、hotlist で気にするバグを管理しつつ定期的につついて回っている。ただこの方法は機能しないことも多い。なぜなら TPM/EM のつつかなければいけないバグが多すぎるし、当事者ではないから伝言ゲームになりがち。やはりできるだけ直してほしい本人がつつくべきで、システムにもそれを支援してほしい。
したがってバグには「直ることを気にする人」すなわち owner と、それを直す「assignee」が別に存在すべきなのではないか。
とかおもったけど、これは管理社会へ続く道への一歩であって、やはり直す人が決定権を持っている方が健全だな。こういう願望が頭をもたげるのは「直してほしいのに治らない」という organizational malfunction への反応であって、その正しい解決策は上のアイデアのような脊髄反射ではない気がする。
健全なのは、直したいとおもっている当人や関係者が踏み込んでいって直せる状態にすることかもしれないし、場合に寄っては問題解決がおこるスループットの上限を受け入れることかもしれない。他人になにかを強要しようとするのは傲慢だし、自分がやられたらイヤだよね。
しかし締め切りのプレッシャーに晒されながら直してくれよオオとかイライラしているとなかなか一歩下がった価値判断をするのは難しいのであった。
去年体重が増えてしまったのを減らそうと思っている。風邪の季節の間は体力をおとす減量は遠慮してたけれど、そろそろいいでしょう。
どのくらい増えたかというと、だいたい 65kg だったのがいまは 73.5kg. 増えすぎでズボンが履けなくなるレベル (夏の間はジャージとハーフパンツで暮らしていたので気づかなかった.) 去年の長い病欠のあいだ体力を落とすまいと食べまくり、その勢いのまま締め切りプレッシャーや減俸手前のストレスに晒され食べすぎた。
一年で 8 キロ増えたのは人生初な気がする。年内に 65kg まで減らす...のはストレッチゴールだけれど、最低でも 70kg は切りたい。
やること
- 毎日体重を図る（はじめた）
- 食事制限
- 時間の都合で今より運動量を増やす予定はなし。
食事の記録、せめて写真、をとることを考えているが、よい方法が思いつてない。こういうのはアプリがよいのではないかと調べ中。
Daybook - Diary, Journal, Note - Apps on Google Play
とりあえずなんらかの日記アプリに写真を添付する、という方向でやってみる。なんか個人アカウントなのに写真アップロード対応とか小遣い足りてるかい・・・と不安になる面はあるが、DayOne モロパクリの Journey に比べベーシックなかんじに好感。
05:01 @Startbucks. 三連休なので月曜に来ている. 日曜とはちょっと客層が違う.
週末、家族で早起きしてささっとでかける方が渋滞事情などがラクなのだけれど、そうするとこの朝のそっとしといてもらう時間の確保が難しくなるため難しい。
こんな便利関数があったのか JNI! しかしこれ MappedByteBuffer には使えるのだろうか。名前だけみるとダメそうだが・・・。
From jni_internal.cc
static void* GetDirectBufferAddress(JNIEnv* env, jobject java_buffer) {
return reinterpret_cast<void*>(env->GetLongField(java_buffer, WellKnownClasses::java_nio_DirectByteBuffer_effectiveDirectAddress));
}はいダメでした。解散。
近所の席の同僚が内製の dashboarding tool をつかい複数のタブからを SQL を叩きつつにらめっこしていたので、そういうのは Colab の方がいいよ、と勧めたところ(この同僚は他の用途に Colab を使っていたため敷居はさほど高くない) 「いやーでも histogram どう描くのかわからないんだよねー」という。「ちょっと Python 足せばいいじゃん」「めんどくさい」などの会話がつづき、そうかそうか・・・とおもって帰宅したら、翌朝チームに送られてきたメールは colab をリンクしており、matplotlib でヒストグラムを書いていた。やるな。
自分は以前 SQL で histogram を計算したのち Pandas で plot をしてめんどくせーとかいっていたが、彼のコードをみると SQL は結果をひっぱってくるのみで histogram は Python 側で計算していた。データサイズをみるとたしかに全然大丈夫そう。SQL でヒストグラムはすごいめんどっちいので、この手の作業は Python でできるならその方がいいね。心を改めた。というかデータがでかいならサンプリングすればいいだけだから、基本的に histogram は Python の方が良さそう。
04:50
そろそろノートを書かねば。一日サボるとだいぶ厳しいこの日々が帰ってまいりました。
The Age of Surveillance Capitalism: The Fight for a Human Future at the New Frontier of Power: Shoshana Zuboff
Tim Wu の The Curse of Bigness を聴いて、テック企業のあり方について考えてみようかな・・・と聞き始めた。あちこちで話題になっている一冊。
なのだが・・・これ厳しくね？メタファとレトリックでひたすら FUD しまくってて聴くに耐えない。お前は何言ってんだ・・・と頭痛がしてきて数時間で挫折した。たぶん多少は意味のある指摘もしているはずで理解したいのだが、罵詈雑言の割合が高すぎてちょっと無理。空想上の巨悪を叩かれても、いやそんなことしてないんで・・・的な気分にしかなれない。耳が痛いのでなく頭が痛い話でつらい。
自分はテックカンパニーのプライバシーの扱いはもうちょっと何かが何とかなってもよいのではとは思っている。でもこういう乱暴なバッシングから有意義な議論が起こる様は想像できない。
自分の勤務先の現実なんて、世間の若いインターネット企業が growth hack とかいいはじめて何年もたったあとにようやくそういう話をしはじめたくらい prediction based でなんかするのに出遅れており、自分はこんなやる気なくて大丈夫なのかと思っていた（し、そのへん頑張らなすぎて消えていったとしか思えないサービスも多い。）Surveilance して predict できるならもっと色々うまくやってるはずじゃね？株価とか又聞きで判断せず製品さわった方がいいよ・・・まあ technical なあら捜しをしても詮無い書き手なのだろうけれども。
しかしこうやってセンセーショナルにバーっと叩いて、それがバズってなにかが起こるのかもしれず、そうしたら著者としては満足なのだろうなあ。レビューも絶賛してるのばかりだけれども、こういう話を聞きたい人が聞きたい話をしてくれて喜んでいる様子。炎上商法みたいのに振り回されるのだとしたら悲しいが、人々がこれを求めているところが時代なのだろうな。
繰り返すけど、評判から判断するになにか意味のある議論してるんだと思うのだよね。でもほんとにノイズがキツすぎて読めないよ。
The Curse of Bigness: Antitrust in the New Gilded Age: Tim Wu
でかい企業の独占はよくない、という話の発端である Shaman Acts や、それをうけた 20 世紀序盤から中盤にかけての anti-trust 活動、70 年代のシカゴ学派によるカウンターから現在までの歩みを紹介しながら、いまの anti-trust は元々の精神を失っている、取り戻そうと語る。
Tim Wu にしては薄い本だけれども、The Master Switch で anti-trust のハイライトである AT&T を研究し The Attention Merchant でインターネット企業を研究した流れでみると自然なかんじはする。自分は昨今のテック企業をめぐる言論には mixed feeling だけれども、でかすぎてダメというのはそうだろうなと思う。
Forbes には否定的なレビューが載っているが、全部読んで振り返ると自分は Tim Wu に分があると思った。自分が左よりで Tim Wu ファンであるバイアスは差し引く必要があるが。
テック企業は anti-trust の例外と見られることがある。つまり、たとえば Microsoft を分割しなかったけれどその後に新興企業が出てきて世代交代したし、それまでも The Innovator's Dilemma で語られているように世代交代の disruption は続いてきた。競争が機能してるんだから anti-trust みたいな規制いらなくね？という主張。
でも、たとえば Microsoft が勃興できたのは IBM が anti-trust を巡って政府と戦った名残で IBM PC がやたらオープンになっていたおかげだし、同様にそのあとのインターネット企業がウェブでやんちゃできたのも Microsoft が anti-trust のリスクに備えて無茶しなかったからという面はある。
もうひとつは、やはりインターネットおよびウェブというのは電話以来百年ぶりの超特大イノベーションで、PC market を独占していた Micorosoft が氷山の一角にあるパイを食べたくらいではまだまだ余裕で巨大な市場が残っていただけという気が個人的にはしている。その超巨大市場がようやく飽和して現代があるのではないか。
そして企業に悪意というか強欲さがあろうがなかろうが anti-trust のない市場には monopolize の tendency みたいなものがあり、それはある意味で自然の摂理というかエントロピーみたいなものなので、人類の平和のためになんらかの秩序が必要で、 anti-trust はそのための発明なのだ・・・という説明を Tim Wu はしていないけれど、自分はそう納得した。
それにしても Anti-Trust というアイデアは全然自明じゃないよね。こんなものが 19 世紀に提案されていた事実にはアメリカの民主主義の力を感じざるを得ない。最近のアメリカには失望つづきだったけれど、そうした歴史や Tim Wu のような書き手の存在はさすがと思う。
自分が Design Docs というものがいまいち好きでない。Design Docs という抽象的な概念が嫌というよりは、提供されるテンプレートが嫌（という話は前に書いた気もするけれども発見できなかった・・・。）
典型的な Design Docs は BDUF によりがちである。バシっとしたデザインを宣言し、これでいくぞ！という。しかしそれは多くの場合嘘である、というと語弊があるが結果できあがるものとは違う。違うものを作るの自体は良いが、そんなら最初からバシっとデザインできてるみたいな顔すんなよ、と思う。
これは半分はテンプレートや慣習の問題である。多くの design docs は confidence level を communicate しない。「ここのデザインはまだ決められないので適当です。ちょっと作ってみてから考えます」「これはあとで変えられない重要な決定です」みたいな情報は一級市民であるべきだが、抜け落ちがちである。
そうしたプロジェクトの confidence level を上げていくというか uncertainty を絞り込んでいくの作業は planning と呼ばれる。つまり planning と design は表裏一体である。しかしなぜか２つは独立に扱われがちである。書いてる人が違ったりすることすらある。アホか。まあ planning というとプログラマ以外の stakeholder も色々関係してくるのでプログラマだけがどうこうすることはできないけれども、自分のぶんの計画くらいは design に織り込んでいいのではないか。そうしないと PM の書いた PRD みたいないまいち iterative 精神を理解してない計画に縛られて色々厳しくなりがち。不透明なものを段階的にすすめるならそうはっきり伝えなておかないと。
Agile は planning についてはいろいろと手法を開発したが、design 側は手薄になりがち。もともと BDUF に対するアンチテーゼの面があるから documented design を意図的にがんばってない部分はあるのだろうけれど、そうはいってもコード書く前に多少はなんか考えて書き出しといた方がよくね？実験的に開発をすすめるにしろ、多少は当初の目論見をはっきりしないと slip しがちじゃん? いやドキュメントも必要に応じて書くよとかいうけど、たとえば Scrum のプロセスの回し方みたいのを議論する細かさに比べたら design の話は皆無といってよい。そういうことやってると BDUF の亡霊に襲われるぞ。というかその亡霊が Design Docs だと思うのだよね。
自分はある時期までは iterative に進めるなら事前の documented design はなくてもいいと思っていた。実際なくてもできることは多い。ただ相手にするコードベースが大きかったり達成したいゴールが自明じゃなかったりすると iteartoin の turnaround time が長くなりがち。だから事前にあるていど調査をして見通しを立てるのには意味がある。しかしその調査の結果や見通した設計を資料化する部分でいつもモタモタしてしまい、もたついた末にサボってひどい目にあったりする。
特に誰かに助けを求めたいときはやりたいこと、やっていることを文書化しておくと be on the same page する上で都合が良い、というか割と必須。ひどい目にあうのは意思疎通の失敗が多い気がする。
もう一つ多いのは自分がやるべきことをはっきり決められていないのに気づいていない場合で、症状として procrastination が現れる。これは文書を書くとはっきりしたり、少なくとも何がはっきりしてないか自覚できたりする。考える道具としての文書化。
自分はこういう uncertainty から始まる evoluving design を記録するメディアとしての半時系列的なアプローチに興味あがり、だから blog 的なものに期待があるのだろうということに気づいた。もしかして一部では solved problem なのかもしんない。勤務先、なんとかならんかなー・・・。
まあ勤務先はおいといて、自分でなんかモダンなものをさわってみないとなあ。
社会人になって blog 的なものを書くにあたり、一つ決めていたことがあった。それは批評や批判を書かないということ。仕事をしているとネガティブなことはたくさんあるわけだが、それを blog などに書いているとネガティブな話が好きなネガティブな人が集まってくる。学生の自分はいわゆる批評の類が好きでよく読んでいたが、一方でその不毛さは当時のウェブの楽観的な空気と噛み合わず、自分は楽観的に何かを生み出す側でいたいと思っていた。今日のウェブはネガティブな言葉に埋め尽くされてしまったが、一方で自分の勤務先を含めるインターネット企業は良くも悪くも当時の楽観の帰結である。自分がそっち側で仕事をしていられる理由の一つは、楽観側に身を置くと決めたおかげもある。９割は運だとしても。
自分の性格もあってこの決めごとは必ずしも守られておらず、しばしばなにかにケチを付けてしまうことはあった。そしてそういうものほどよく流行った。けれどそういう流行りをある程度押し返すことができたのは、いちおう「決めていた」からだと思っている。
ある時期からは自分の感じている苦難（というと大げさだけど struggle ということね）と、ものを書く際に課している delightedness の gap が大きくなって、けれど struggle や frustration を表立って口にするのは昔以上に problematic で、何かを書くのが億劫になった。今のように 人目につくまで時間を置く方針はその溝を橋渡しする処方となっている。
いまの自分が書かないようにしていることはいくつかある:
- アメリカ・ベイエリアの暮らしの話。たまにはいいとおもうけれど、こういうのばっかり書いていると「アメリカ・ベイエリアの人」になってしまうよね。特にベイエリアはいちおうコンピュータ産業の中心地ということになっているので、この話題は同業者からの関心を集めやすい。一方で職業人としての足しにはならないし、この手の話に寄ってくる同業者は地理的なコンプレクスを持っている人が多く、話して楽しい相手ではない。だいたい日本の悪口とセットになりがちで、それも negativity を呼び寄せる。
- 外資系企業の話。まあ外資系じゃないんだけど、日本にいた頃は外資系だった。これも上と同じで、話しているうちに「外資系企業の人」になってしまいがち。これは「ベイエリアの人」よりは仕事に役立てやすいケースもあるようだけれども、プログラマ向きではないよね。ある種のコンサルタントになりたいなら別だけれども。
- あとは前に書いたけど記事の孫引きみたいなやつね。
なにを書くかの選択は、自分が外からどう見えるか以上に自分が何を考えることに時間を使うかを決める面がある。これも前にちょっと書いたけれども、ベイエリア在住技術者の人にも東京の外資系企業で働く人にも伝統的日本企業を腐すことに自分のプレゼンスの大部分を費やしてる人が一定数いる。そういうひとたちはそうした自分の勤務先が晒されている競争や、面している課題を考えることにどれくらい時間を使っているのか。そっちのほうがずっと興味深いし、仕事にも関係あるし、重要な話題だと思うのだけれど。まあ業界動向はともかく他人より自分の話をしたほうが良いよね。
こうした人々はもしかしたら意識の切り替えがすごく上手で、日本の悪口は単なる関心の通貨や息抜きに過ぎないのかもしれない。でもそういう語りが自分の精神性に影響を与えないってこと、ほんとにあるのかな。自分には無理。Whenever they go low we go high.... とかいうとまったく縁起が悪いが...
外資系というか bigco という話だと、もちろん大企業づとめにはいいこともあるのだが、一方で自分のプログラマとしてのキャリアを危険に曝している面も大きい。仕事をするにしても大企業なりの難しさは色々ある。大企業勤めの害をなるべく押し返しつつ、大企業の難しさを押しのけながら仕事をする、というのは自分の大きな関心であり、そういう話はぼちぼちしていくと思う。自分の立場が持つ問題とどう戦うかという話はステレオタイプの助けもあってか日本の中小企業勤務者の語りの方がよく目につく。ただ自分にとっては全体的に他人事すぎる。だからテック大企業の人も角が立たない範囲でそいう話をしてほしいもんです。
06:08 - 無駄についったして消耗してしまった・・・。
via Androidにおけるパフォーマンスチューニング実践 - Speaker Deck
世間の期待値的には性能の話がこれでいいのか・・・別にリンク先のひとを腐したいわけではなく、2019 年にこんな話なのか・・・と割と心の底からびっくりしてしまったのでひっそり記録したかったという話。なお別にこういう話をしているからその人たちのアプリが遅いといいたいわけではない。地味にコツコツやればそこそこ速くなるジャンルはたくさんあるから。それでいいならそれでよいのです。
つい Twitter に余計なことを書いてしまったが完全に言いがかりだったと反省。
講演きいてないのでわからないけれど、リンク先の資料に問題があるとすれば計測して、詳しく見て問題を特定して、それを速くする、というサイクルが感じられないところかな。高速化、そのサイクルが一番下にないとカーゴカルト黒魔術みたいのになりがち。
追記
スライドの人が dex.fm に出ていたことに気づいたので聴いてみた。ちゃんと仕事してる人だった。我ながら言いがかりよくないわ。
dex.fm — 064: Performance Tuning
こういう人の話を聴いてみると、自分のやってる仕事は単に職場のインフラを exploit しているだけだなあと思う。たとえばベンチマークの自動化にしても lab なり dashboarding なり scheduled execution なりの仕組みはもうあるので、それを寄せ集めれば良い。
というか自分はそれすらできず、半年くらい前にやってきた別の人が別の目的で寄せ集めた自分のチーム向けのセットアップに相乗りしている。一番大変な connecting pieces 作業はそのひとが済ませてくれたので、自分はその上でちょっとコードを書けば良い。
自分の作業はアプリ側からメトリクスを expose する側に寄っているのでちょっと守備範囲が違うとも言えるが、そのアプリ側の仕事にしても昔だれかがやったまま放置していたコードを整理復旧して使い物にしただけで、特にすごく何かをがんばったわけではない。まあこれは前のチームで割とがんばった部分なのでやればできるとは思うが・・・。
こうした仕事に価値がないとは思わない。実際自動化によってカバレッジがあがり、早い段階で性能バグを発見できるようになったわけだから。ただまあ、リンク先の人のような全方位的活躍とは程遠い。
他人の仕事を寄せ集めるだけで成果がでるのも、他人の仕事を寄せ集めるのが大変なのも、大企業であることよ。最近やってきたできるエンジニアは「俺はコードは書かない。他人のコードをコピペするだけだ」と冗談交じりに言っていて、そういう面なあるなと思う。コピペ元コードの出処が社内コードサーチか SO かの違いで世間のプログラマも割とそんなもんなのではという気もする。はさておき。
部品を寄せ集める大変さを考えると大企業で社内インフラに乗るのだろうがスタートアップでオープンソースに乗るのだろうが大差なくね、というのは常々感じているオープンソースもっと使わせろという不満につながるわけだが、自動化のインフラはコードだけでなくサービスの operation も必要な類なのでまあ仕方ないかなと思う。過剰な大変さはなんとかしてほしい気もする一方、サーバ側と比べた時の社内のモバイル回りの筋の悪さには諦めもある。
こういう感じの方針で作ってくべしという指標
- API はなるべく PDFium をベタに map していく。Intelligent なことはアプリがやる。
- 自分が使わなそうな API は入れない。当たり前だけど。メタデータとか際限なく色々ありそうなので。そこはがんばらない。
- Finalizer は実装しない。自分でちゃんと close() してねということにする。finalizer がらみの複雑な色々とかと付き合う気になれん。
- Checked exception はナシ。例外階層は一定程度真面目にやる。といっても PDFium のレイヤで起こりうるのは IO とそれ以外、くらいな気がするが・・・。
- 主要な native backed オブジェクトはインターフェイスにしておく。ネイティブが絡むとさすがにテストとかが辛かろう。
- Java の IO は使わず mmap でバリっと読むの限定とする。ダウンロードしながら表示とかやらない。どう考えても圧倒的にメモリ効率が違う。
実装
- システムコール類は単一のクラスに押し込める。Android 方式。任意のオブジェクトのメソッドを ad-hoc に native にしていくのは色々つらそうなため。
- 悩ましいのは PDFium の API だが・・・。これも native との境界はぜんぶ static にしておく方が見通しはいいかもしれないなあ。もとの API が C なわけだし。その方がネイティブの切り口に悩まなくて済みそう。
- JNI 境界のオブジェクト受け渡しはあんまりがんばらない。配列とか文字列でがんばり type-safety は追求しない。
- 自分が使いそうな API は、即座に必要なくても一応足していく。開発しながらライブラリとアプリを往復するの大変そうなので。
実装すべき(API を生やすべき)機能
ヘッダを眺めると・・・
それなりに C++ のヘルパとか書かないと厳しそうだな・・・。
04:59.
そんじゃ aar をリンクするアプリでも書きましょう。
- ところで Bazel を眺めていたら いまだに Kotlin 1.3 をサポートしてない! やる気あんのか? 残念であることよ。アプリ本体は Gradle にすっか・・・・と一瞬思ったが、それはそれで厳しいな。遅くいし依存関係はすぐグチャグチャするし・・・。
- ところで (2), なんとなく Paperium ライブラリはアプリ側の Bazel Workspace に直接ぶら下げる気でいたが難しい気がしてきた。Bazel というか仮想 monorepo は色々ディレクトリ構成の縛りがあるが、Paperium は Chrome ツリーにも制約をうけている。両方満たすの無理、みたいに積む瞬間が来そう。まああとで考える。
- それはさておき Hello アプリ動いて SO もロードできたぞ！苦節半月、ようやくスタートラインまできた！というとやや嘘で、またスタートライン（アプリ）にはたどり着いていないが、少なくとも Paperium の API を足していく段階にはたどり着いた。
- 基本的には PDFium の API のサブセットをマップするだけのつもりだけれど、ちょっと書き出して作業しないとダメだな、さすがに。
05:06. 間があいてしまったがやってきます。
今日は Bazel から GN (を呼ぶスクリプト) を呼ぶ。
- genrule と aar_import を組み合わせる方針は良さそうだが bazel がスクリプトを謎の sandbox 下で呼ぶため gn が見えない・・・。めんどくせー。PATH をハードコードして乗り切る。こういう設定の類を渡せない bazel もつらいし、gn や ninja がツリーに含まれていない chrome もつらい。コンパイラもツリーにはいってるのになんて gn は環境変数前提なんだよ・・・。
- こうした性質があるため、gn を呼ぶスクリプトにはなるべく path 類をハードコードせず Bazel 側から渡すようにするとトラブルが少なげ。理想的には custom rule を定義するのがよいんだろうけれどガッツがないので genrule で乗り切りたい所存。
- custom rule はともかく人として macro にはしておくか・・・。
- こうしてできた so を aar にマージするわけだが・・・。zip コマンドよくわからないので Python だのみ。
- そういえばこの .so みんなデバッグビルドだな。そのうちリリース版も必要。しかし今はスルー。
- できた。次はこの so がほんとに動くのかを確認いたしましょう、だけど今日は時間切れ。
- Java 一行も書いてないけどビルド的には一番正しい PDFium for Android を作っている予感。
平和な朝、ストレッチをして家を出て、走って会社について朝食して、バグのリストや機能の記録からやるべきことを見直してノートに書き出して仕事を始める。これが全部スムーズにいくと朝から調子よく仕事ができる。一日の生産性はおおむね朝の調子の定数倍なのでこういう日は仕事がはかどる。
しかし実際には雨が降って走れなかったり、子供の相手や医者その他の雑用で朝のルーチンをこなせないままばたばたと職場につき、遅刻にともなう焦りと締切圧からなんとなく前日にやっていた作業を再開する・・・というような日は集中を欠き、一日の生産性はその集中のない状態の定数倍なのでつまりまったく捗らないまま終わる。
といった点を考えると、たとえ朝に雑用が立て込むなので遅れてついたり運動できなかったりした日も、会社についてから慌てず騒がずストレッチや作業計画に時間を使ってから仕事を初めた方がトータルの生産性は高まるのではないか。
問題があるとすれば、オフィスというのは朝から時がながれるほど混み合い慌ただしい空気にあふれてくるので、それを振り切るのは割と大変ということ。もうちょっと余裕のあるオフィスで働きたいもんだわ・・・。
それとは別にぶらっと見たインターネットで disturbing/digsuting な話（勤務先のやらかしなど）を読んでしまうと気が散ってしまう問題もある。精神衛生のためにインターネットは見ない方がいい。わかってる。
Colab には Local Runtime という機能があり、自分のワークステーションで動いている Jupyter に Colab でアクセスできる。これを使うとアプリなどのベンチマークの実行、集計を一箇所に集約できてよい。
アプリのベンチマークは、ある程度自動化可能になっている前提。たとえ自分の場合だと Android 相手なので ADB で適当にインテントを送りつけアプリを起動したりベンチマークのスコアをどこかにダンプしたりできるようになっている。
次のステップは Python から ADB などを呼び出してベンチマークを実行し、結果をダンプしてパースしてスコアを読み出す。あとはそれを適当に複数回実行したのち Pandas とかで整形すればよい。
環境のセットアップなど Python 側でデータの解釈が必要ないコマンドの実行は shell command 記法 で書いておくと簡潔だし出力も記録できる。
またベンチマークの意図やコード上にあらわれない情報（アプリを改変してビルドしなおしたなど）はテキストとして書いておく。Diff を gist 的な場所に貼り付けて URL を記録してもいいかもしれない。
ある程度結果がでたら整形して説明を書き加え、バグトラッカーなどで関係者にシェアする。Jupyter と比べた時の Colab の利点は、Notebook が最初から URL を持っているおかげでシェアする作業が自明なところ。ipynb をバグに添付しても間違いなく読んでもらえないからね。
開発中にとるベンチマークは探索的な性格を持っており、同時に手順が繊細で自動化しないと間違いやすい。なので Jupyter と相性がよい。自分は今まで適当にシェルスクリプトとかで半自動化し、結果を Jupyter にコピペして計算と整形だけやっていた。これは間違ってたね。なんのベンチマークをしたか自動で記録がのこり、再実行はセルと叩き直すだけ。同じ場所でメモもとれる。コピペの手間もなし。全然よい。
よく考えると本質的にベンチマークの試行錯誤というのは実験という Notebook の使いみちの王道なんだから相性が良いのは当たり前。性能の仕事を主にして数年、今までこれをやってなかったのは shame と言って良い。反省。でも明日からちゃんとやる。むしろシェルスクリプトの出力をコピペするとかかったるいのによく耐えてきた。
次は Systrace を統計的に処理するとかやりたいなあ。どっかにパーサないものか。Chrome は trace 結果が JSON だったので簡単に Pandas から読めたのだが。
04:43. 昨日は眠気がきつかったので脱落。今日は大丈夫。
- ビルドできたはいいが nm するとシンボルがないといわれるな・・・とおもったら nm -D とするものらしい。そうですか。
- というわけでビルドはできた。こいつをしかるべき場所にコピーする・・・のは Bazel 側の仕事としよう。まずは複数 arch でビルドするスクリプトを書くべし。
- なんかこんな時間に子供が叫んでいる？とおもったら猫が窓際で近所の外飼い猫と喧嘩していた。おまえら友達いたのか。
- x64/x86 では libjpeg-turbo が yasm を要求してくるが ARM はしてこない。ARM は速くしてくれてないのだろうか・・・。いやあるな。しかし Chrome のコピーはなんか古い気がする・・・。
- とかいってる間にビルド終了。次は Bazel の Java ディレクトリを作ろうではないか。このプロジェクトは BUILD.gn と BUILD が混在するカオスビルドシステムになるが、それがよい。
- うげー Bazel の AAR にも native lib 入らないのかいな・・・。しかし冷静に考えるとそうだよな、とは思うが・・・（依存関係は Bazel がひっぱってくるものだから。)
- しかしサンプルアプリは全部入り aar ではなくライブラリ単位の jar とプレビルドのバイナリターゲット（というものはあるのだろうか・・・）に依存させて試す必要がありそうだなあ。Sigh.
- 時間切れ
なんとなく考えると、先の workaround を genrule にして全部入り aar を生成し、その出力を aar_import すれば良い・・・ような気がするが、そういう芸当が可能なのかはわからん・・・。次はそれで。