Spinach Forest

August, 2023

/ Amplification At Tails   / TIL: Ubuntu Desktop Core   / Feel-Good Membership   / TIL: Twyman's law   / Caffeinated   / Unhedged   / TIL: Dagger Instantiation Recursion   / “If we have data, let’s look at data. If all we have are opinions, let’s go with mine.”   / TIL: Chrome Side Panel API   / TIL: Struct and Row Types   / なくならなかった仕事   / ... 

Amplification At Tails

Trustworthy Online Controlled Experiments という本を読んでいたら(いい本です。読み終わったら紹介予定)、ページロードのレイテンシを 100ms 遅くしたら売上が 1% 下がった 2006 年の Amazon の事例が引用されていた。引用先のブログ記事では、レイテンシが 500ms 遅くなる変更をしたら売上が 20% 下がった Marrisa (昔の Google の偉い人)の講演も引用されている。なお先の書籍では Bing の同様の事例も載っている。

Amazon の実験では人工的に遅延を挿入したようなので一概には言えないが、しばらくレイテンシの仕事をしていたら 100ms なり 500ms なり遅くなったらそりゃダメに決まってんだろと思う。

ここでいう 100ms などの数字は、おそらく 50 percentile (median) である。こうした遅延は、tail にいくとめちゃ増幅される傾向がある。DynamoDB の paper は p99 を 2x くらいに抑えたと自慢しているが、これはすごいがんばった事例の話で、しかもデータベースのようなデータセンタの中にある単一のコンポーネントについて議論している。E2E だと古くて遅い電話機もあるし、データがインターネットをまたぐし、バックエンドが沢山あると一番遅いやつが足を引っ張ったりするし、p99 が 10x くらいになるのは珍しくない。 p95 も 2x-3x とかである。こうなると p50 で 100ms だった遅延は p95 で 200ms, p99 で 1,000ms まで増幅される。ユーザは、そんなに長くは待ってくれない。200ms, 1,000ms というのは差分で、絶対値は(たとえば)2,000ms, 10,000ms とかだからね。

15 年前に件のストーリーを聞いた自分はこの事実をわかってなかった。速さが重要なんだというテック企業からの啓示をありがたく拝聴してただ真に受けていた。今は、それが当たり前になった。いちおう成長してんな自分。単に世の中が進歩しただけな気もするけど。

TIL: Ubuntu Desktop Core

|

Ubuntu を Chrome OS みたいにするという話らしい。開発者環境はコンテナベースにしたいとある。Crostini を例にあげているけれど VM が間に挟まるのは嫌だなあ。コンテナだけにしておいてほしいアプリは Snap-based. VSCode も Android Studio もあるのでなんとかなりそう。ただし Chrome OS と違って Chrome はない。Firefox でも使えばいいのかな。

今のところは実験的ぽい様子なのであまり気にしなくて良さそうではある。

Feel-Good Membership

自分の favorite podcast であるところの ATP はこのごろ広告収入源で困っているという。毎度 membership への加入を募っている。しかし $8 なー。根が Freemium 乞食なので NYT の $17, Disney+ が $8 と比べると腰が引けてしまう。そして別に特典とかいらないのだよね。$3/m くらいなら特典なしでも払うんだけど・・・。などと思っていたところサーベイがあったのでその旨を書いておいた。

なおふと Rebuild.fm membership(supporter) の pricing を見たら $10 で ATP より高価であった。さすが日本を代表する tech podcast である。なお自分が少し前まで sub していた Stratechery Plus は $12/m. また購読しようかなあ。


この手の membership の値付けって難しいよね。NYT や Display+ のようなマスメディアと personality based の podcast を比べるのは本来はナンセンスだけど、可処分時間的にはマスにこそ時間を使ってるわけじゃん。いや Disney+ は全然観ていないか・・・。いずれにせよ personality based の membership は時間単位ではなく他の何かの基準によって人々は金を払っている。

なおあるとき YouTube アプリのバグを眺めていて YouTube にもクリエイターにカネを払う memberships というのがあると知った。「こんなのあるの知ってた?」と友達に話したら「応援と思っていくつか sub してますよ」とのこと。へえ。

同じことを妻に話したら実は育児 podcast (?) の membership を sub しているという。みんな思ったより sub してんのね。心情的には Disney+ より ATP にカネ払ってあげたいよなあ。

TIL: Twyman's law

|

Twyman's law states that "Any figure that looks interesting or different is usually wrong", following the principle that "the more unusual or interesting the data, the more likely they are to have been the result of an error of one kind or another".

Twyman's law - Wikipedia

データ分析をしていて面白いことに気づいたときにまずすることはデバッグであり、A/B テストのインフラは "guardrail metric" を用意しような、という文脈で出てきた格言。

Caffeinated

このところ子に対する当たりがきつい、と妻に指摘される。思い当たる節はある。カフェイン。この 1-2 週間くらい、仕事中の眠気払いにコーヒーを少し飲んでいる。その影響に違いない。

やめた方がいいなと思う一方、久しぶりに飲んでみると早朝の起きやすさは段違いである(眠りが浅いので)。課外活動しやすい。仕事も、なんとなく捗っている気がする。

ただこの「人への当たりがきつくなる」問題は困る。今回は妻に指摘されたから気づけたけれど、たとえば仕事で同僚への当たりがきつくなっている可能性もある。そういえば昨日 PM の質問にチャットで答えたらしばらくして「ごめんね同時にやってるプロジェクトが多すぎて細部を覚えておけないのよ・・・」という返事がきたな。やっぱりきついこといっちゃったのでは・・・?(と思ってログを見直したが、これは返事をしなかったのが問題だった気がするな。:thumbsup: を忘れずに。)

はーどうしようかなあ。とりあえず一旦カフェインを抜いたほうが良さそうだが、一週間以上続けてから抜くとそれなりに解脱症状あるのだよね・・・。


カフェインを本格的にやめるきっかけになったのは四年前に Why We Sleep を読んだときから。このときは昼に一杯にしておくと書いているが、その後は週に一杯くらいに減らしたり、ちょっと増やしてみたり、基本的にはあまり飲んでいなかった。今回は油断した。

振り返ると、自分の off-caffeine 期間はパンデミックとほぼ重なっている。これはトータルでは良い判断だったと思う一方、パンデミック中に何もした記憶がないのは、もしかしたら caffeine の欠落により睡眠が伸びて活動が減った影響もあるのではないか。一日が短くなってしまうインパクトは大きい。

言動への影響を抑えつつ眠気を抑える方法はないものかねえ。

Unhedged

Unhedged: a new markets podcast from the FT - Financial Times

FT が Pushkin production ではじめたニュースの podcast. 一回 15 分くらいで短い時間を潰せるのと、FT らしく moral judgement をせずカネの話しかしないのである種の安心感がある。そのへんは色々庶民の見方的な仕草をしがちな Planet Money とは対照的。どちらが良いというのはなくて、その時の気分で聞き分ける感じ。

日本の景気が良い話などは、よく知らなかったのでふつうに理解の助けになった。

TIL: Dagger Instantiation Recursion

|

TIL というか久しぶりにやったので記録。

@XxScoped
class A {
  @Inject A(Lazy<B> b) {
    b.get();
  }
}

@XxScoped class B { @Inject B(Lazy<A> a) { a.get(); } }

とかやるとあーら不思議、A の constructor が何度も呼ばれてしまいます。ふつうはこんなわかりやすい例じゃなくてもうちょっと入り組んでいるが、スタックトレースをダンプすれば多少入り組んでいても一目瞭然である。

コンストラクタでなんかするのを止めろ、が一般的な良い解決。ただし今日は俺のコードじゃねー的な場面なので適当に直します。

理論上は静的にチェックできるはずとはいえ Lazy がそういうチェックを回避する手段なのでチェックで弾くのは本末転倒。動的にチェックするのはどうかというと、それも可能だけれど、どのみちクラッシュするので労には見合わなそう。

“If we have data, let’s look at data. If all we have are opinions, let’s go with mine.”

|

とある本の冒頭で引用されていた、元 Netscape CEO のセリフ。いまいち出処がわからないが、あちこちで引用されている。データサイエンス方面では有名な格言らしい。 この T シャツとかほしくないですか?

・・・しょうじき自分で着たいかと言われると微妙だが、偉いボスが着てたらときめいちゃいそう。

TIL: Chrome Side Panel API

|

Chrome の side panel には extension の API があった。標準の side panel 機能はいらないものばかりだが、拡張にはなにかいいものがあるかもしれない。

ちょっと探した範囲ではこれといって良い利用例は見当たらなかった。

TIL: Struct and Row Types

|

これに触発されて TIL をつけてみる試み。基本的にはぐぐったリンクを書いておくだけなので読む人にとってはノイズですが、他に良い置き場所が思いつかないので。


DuckDB や BigQuery には Struct という type がある。

これは表面的には JSON type と似ているが、型が決まっている。したがって columnar storage だと個々の primitive values が column になるのが便利。BigQuery とかはそもそも出自が Protobuf の columnar database で, struct は proto と似たようなものである。ZetaSQL を見ても proto と struct は似たような扱いを受けている。

この便利な機能は Postgres にもあるのかなと調べてみると、composite type というらしい。Postgres は columnar ではないので別に JSON でも大差ない気もするけど、型がある嬉しさはある、のではなかろうか。たとえば index を作れるとか。

ふと JSON type には index 作れないのかなと調べてみると, GIN (全文検索) としてインデクスできるようである。

なくならなかった仕事

自分は Android プログラマで、我ながら将来性のない仕事をしているなとぼんやり思っている。将来性がないというのは、つまりあと 5-10 年くらいしたらこの仕事はなくなりそうだな、ということ。

これは妥当な見通しだろうか。

20 年前には Windows プログラマという仕事が普通にあって、VB とかを書いていた。Windows のネイティブアプリを書くそんな仕事は、今はなくなった。すくなくとも近似的には。たぶん 10-15 年前くらいにはもうなかった気がする。Windows の仕事は Web (および Electron) に取って代わられた。


一方で、無くなりそうでなくならなかった仕事もある。モバイルファーストが騒がれていた 十数年前、もうウェブプログラマの仕事はなくなりそうな気配があった。広い合意ではなく、まだいけるというウェブプログラマもたくさんいた。とはいえモバイルのネイティブアプリにやられると思っている人も多かった。

けれど、それは起こらなかった。今やウェブの求人はモバイル求人より多いくらいである。何が起きたのか。あるいは起こらなかったのか。

まず、Web の主戦場たるデスクトップにモバイル OS はやってこなかった。そして人々は Windows や Mac といったデスクトップ(ラップトップ)を使い続けている。特にエンタープライズの世界ではいまだにデスクトップが中心である。

なぜモバイルプラットフォーム (iOS, Android) へのシフトが起きなかったのだろうかというと、プラットフォーム業者のやる気がなかったからだろうね。Apple は Mac を急いで殺す必要がなかったし、Android は Windows を倒せる器ではなかった。

やる気がなかったというと語弊があって、どちらのプラットフォームもWindows が築きあげたデスクトップ環境のロングテール的複雑さを取り込むよりは自分の得意な市場を広げる方を選んだ。なぜならモバイルの市場はデスクトップの市場よりずっとデカいからである。

モバイルのウェブがネイティブにやられることもなかった。ソーシャルメディア、チャットや動画など、人類が時間の多くを溶かす少数のアプリはネイティブが担っている。けれどコンテンツを冷やかしてそのリンクを回覧する行為は、動画やソーシャルメディアを除きだいたいウェブのままである。そうしたロングテールのコンテンツにとって、アプリは補助的な存在にとどまった。アプリとウェブのどちらが補助的なのかは議論の余地があるが、どちらも必要なのはたしかでしょう。

URLでリンクできてインストールも不要というウェブの性質をネイティブアプリは克服できなかった。ウェブの方が相対的に安く作れるのも助けになっている。


昔は「新しいプラットフォーム(たとえばウェブ)が古いプラットフォーム(たとえば Windows)を駆逐する」という歴史観があった。が、モバイルの時代にウェブは生き残った。新しきが古きを殺すパターンは繰り返されなかった。

新旧交代史観とは別に「オープンなプラットフォーム(たとえばウェブ)がクローズなプラットフォーム(たとえば Windows)を駆逐する」という歴史観もある。

ではクローズなプラットフォームである Android や iOS が何かオープンなプラットフォームにやられそうかというと、今のところ決定打は見えていない。Web (PWA) はそれなりにがんばっているがメインストリームには来ていないし、React Native も流行りそうで流行り切っておらず、最近はむしろ下火ですらある。Flutter, Xamarin はほっておく。

そんなかんじで、Android や iOS はウェブという古いプラットフォームを駆逐はしなかったし、一方でオープンな何かに駆逐されることもなく今日に至っている。

次世代のプラットフォームも、今のところ登場の兆しはない。Apple Vision Pro みたいなのは兆しなのかもしれないけど、フォームファクターからしてデスクトップはともかくモバイルを駆逐するとは思えない。

プラットフォームとしてのネイティブモバイルがもつ将来性は、当初の印象ほど悲観的でない。


とはいえ技術としてのコモディティ化は進んでいる。モバイルアプリをつくるのは、今やそれほど難しくない。ハードウェアも速くなって、開発環境も整備されて、変化も昔ほどは速くない。資料も豊富で、その気になれば誰でも始められる。誰もが日々使っているものなので、アプリの仕様もわりかし無理なく理解できる。

作るものはだいたいがクラウド(ポップカルチャー的用法)にあるデータのフロントエンドなので、仕事に高い専門性を要求されることは少ない。だからオフショアとかに発注されがち。かつて WordPress などの CMS が「ウェブ制作」の敷居を下げ専門家が居場所を失ったように、モバイルの専門家も今は若干肩身が狭い。

求人を眺めていても、リーダーシップ的でないモバイル開発者に景気よく給料を払ってくれそうなのは Meta と TikTok くらいである。人類の時間を溶かしたいソーシャルメディアがモバイルの専門家を必要としているのはわかるけど、そういう職種は限られてるよね。人類の可処分時間は飽和しているので。エンタープライズの世界でクラウド技術者が DX だのなんだのと湯水のように採用されているのとは対照的である。


こう書いてみると、モバイル開発者の景気の悪さは人類の可処分時間、電話の画面を見つめている時間の飽和が理由の一つだと言えるだろう。

ウェブのフロントエンドには同じ閉塞感を感じないのだが、なぜだろうね。というと、一つにはエンタープライズのフロントエンドは別に可処分時間を奪い合ってはいないからだろう。長い時間使ってほしいわけではない。さっと用が済むならその方が良い。本質的に色々なことを自動化したいわけだから。

あとウェブ開発者の需要は随分前、それこそ 10 年以上前から飽和しているので、今更悲壮感はないのかもしえない。均衡しているというか。モバイル開発需要の飽和は、ここ 5 年くらいの話だよねたぶん。だから傾きを感じやすいのだろう。(なお、ここでいう飽和は相対的なものである。モバイルもウェブも何らかの求人はあるからね。)


そんな煮え切らない立場の Android プログラマはどう将来を思い描いているのだろうか。

まず仕事を頑張って専門家として出世していく路線がある。Growing as a Mobile Engineer という本はそんな話で、モバイルプログラマの出世を議論している。出世できるならそれに越したことはないことでしょう。

モバイルには見切りをつけて他のことをやる人も多い。2010-2015 頃にモバイルをやっていたけれど今は全然違うことをやってる人は沢山いる。今日もモバイルから出ていく人は多いだろう。ただそういう舵切りは、ある程度若くないと難しいよね。(なおここでいう若さは可処分時間の多さや金銭的責任の小ささの代替指標である。)

若くもなく出世もできない人、というのは自分のことですが、はどうするのか。というと・・・そういうプログラマの先行きの難しさはモバイルに限った話ではないので、ここで議論しても仕方ないな。


まとめると:

  • モバイルの仕事は特にすぐなくなりそうではない。ただし需要は飽和し、技術も徐々にコモディティ化している。
  • つまり年寄り Android プログラマの抱える不安はプラットフォームの消滅ではなく安い労働力との競争である。
  • したがってモバイルプログラマがキャリアを重ねるには、がんばって偉くなるか若いうちに他の好景気分野に避難するのが良い。
  • ただし居残ってもすぐに失業するほどの危機は今のところ迫っていない。

補遺: Apple Ecosystem

自分が Android 開発者なので iOS については議論していないが、大まかな位置づけは同じかなとぼんやりおもっている。

ただ、たとえば iPad のような大画面端末がよく売れていたり、Catalyst のようなモバイルによるデスクトップ殺しが一応は機能していたり、モバイルほどのインパクトはないとはいえ Watch や Vision Pro のような新しいフォームファクターを開拓していたり、エコシステムが開発者としての守備範囲を広げてくれているのはいいなと思う。

Android も Auto や TV などで割と普及しているので、総体としては似たようなものなのかもしれないが、これらはアプリ開発者より AOSP 開発者の土俵なのだよね。