キャリア近況 - 滞舎路日記 を見ていて、本題とは関係ないが昔から抱いていたほのかな疑問を思い出したので書いてみる: 日本の景気のいい IT の会社で働くの、どんなものなのだろう/だったのだろうね。

今この瞬間に景気のいい Mercari なり PFN なりがそこらへんの外資系より(少なくともいくつかの指標においては)良い、というのは、まあそうなのだろうと思うしいい話だ。実際そこらへんの外資系から流れていく人も多い。

それはさておいて、たとえば 5-10 年前の景気の良い IT 企業、たとえば Mixi であったり楽天であったり DeNA であったり、で働くのは、それこそいわゆる外資系と比べてどのくらいダメだったのだろうなあ。まあ給料は安かったろうけれども、それもさておくと。中の人達はまあまあ楽しそうにやってたじゃん？

というのは、外資系および米国で働きつつ日本の会社の悪口を言ってる人たち、だいたい凋落を続けるメーカー系大企業出身だったり、景気の悪いアカデミアだったり、そのほか運が悪くてランダムにひどい待遇の立場にいた人だったりするのだよね。自分も過去に働いた会社は景気のわるいところばかりで、すべて大規模リストラしたり解散したりしている。それらと比べたらそりゃ景気のいいアメリカの会社は色々良いに決まってるが、これは日米比較という意味でフェアな比較ではなかろう。Comparing Apples To Oranges すぎる。

本当のところはどうなのか・・・というマクロな比較には実のところそんなに興味がなくて、自分も若いうちに一回くらい何らかの景気のいい日本の会社で働いてみたかったなという話です。自分の過去の記録をみても転職に際しあまり景気を気にしている様子がない。気にしろ。

就業年数が少ないときの経験は自分の中の定規になる。景気のわるい受託の会社で失敗プロジェクトばかりという自分の経験はだいぶ自分の prospect を損ねたと感じている。プロジェクトの失敗は自分に責任があるケースも多いのでかつての勤務先を責める気は毛頭ないけれども、「プロジェクトは{成功する/儲かる}こともある」という暗黙の前提でいる人と「プロジェクトは{失敗する/金の無駄}」と心のどこかで思っているひととでは、成功への引力みたいのがだいぶ違う気がする。

ところで辛い経歴を持つ人の呪いの深さというのは本当にかわいそうなところがある。

東京にいたころ、昔の（景気の悪い元勤務先/運の悪かった仕事)と景気の良い今の勤務先を比べ、日本の将来を憂いる風の口ぶりでなにかと過去の職場の悪口を言う人が一定数いた。いやその化石のような電機メーカー公社みたいなやつ基準で日本に危機感もってないで FB なり Netflix なり Amazn なりと比べて勤務先に危機感もってくれよという気持ちになったのを思い出す。同じように、そうした凋落していく会社はほっといて景気の良い日本の会社に目を向ければそれほど悲観的になることもない（から黙って仕事してればよい）とも思ったが、実態を知らないため確信もなかった。

いずれにせよ彼らの憂国活動は精神衛生にもよくなさそうだし生産的でもない上に本人の reputation も損ねると悪いことづくめなのだけれど、何らかの obsession に囚われ口走ってしまう様子で気の毒。

自分も過去の職場と現職を比べため息の出る場面はよくあったけれど、単に自分の経験がへぼいだけなのが明らかだったため異種混合の呪いにかからず move on できたのはよかった。

なんてのは、いまとなっては心の底から昔の話。

Android には Performance Team というのがあって、「なんか遅い」みたいなバグに対してアプリ開発者が音を上げると登場して triage して責任者を突き止め、場合によっては自分で OS を直して帰っていく。最初は懐疑的だった自分もなかなかの仕事ぶりに評価を改め、いまは頼りになる人たちだと思っている。サーバ側でいうところの SRE みたいなもの、というとわかりやすい。

なんでクライアントサイドに SRE (的な仕事)がいるのかというと、結局システムとしての Android には分散システム的な側面があるからだと思う。Binder は RPC みたいなもんでたまに congestion を起こすし、ハードウェアの故障はともかくプロセスは LMK で死ぬ。CPU もメモリもいつも足りておらずプロセスは資源を奪い合っている。本物の分散システムとの大きな違いの一つは network partition がないところだけど、OS 本体はともかくアプリから見ると offline 状態というのは network partition みたいなもので、それなりに graceful に扱わないといけない。

そしてなんか電話機/アプリが遅いというとき、それはしばしばシステムとしての問題である。すなわち overload や contention のような system-wide で inter-component な問題が遅さを引き起こしている。もちろんアプリの出来が悪いだけということも多いけれども。

というわけでクライアントサイド OS の開発組織に SRE じゃなかった Performance Team があり、そうした system-wide の性能について日々考えているというのは、まあまあ理にかなっている。

クライアントサイドの性能問題は、いくつかの点でサーバサイドより簡単である。

まずなんだかんだで本当の分散システムではない: 多くの問題は単一デバイスに閉じている。だから理論上 OS は system-global view を持っている。もちろん production には millions of devices があってそいつらには long tail の問題があるわけだが、少なくともデバイス同士が干渉しあうことは、そんなにない。(クライアントであるデバイスが送るリクエストがサーバ側のレイテンシを生み出すことはよくあるが、ちょっと脇においておく。)

あと、突然の高負荷でシステム全体がダウン、みたいなことも起こりにくい。なのでふつう pager で呼ばれたりはしない。まあサーバサイドで flag flip をしたら突然アプリがバタバタと死にはじめることはあり、そういうときはアプリの人も呼び出されるわけだけれども、flag flip は昼間やってちょうだいね、ということで。

一方、サーバサイドにない難しさもある。

まずなんといってもモニタリングがヘボい。これは半分は本質的な問題で、半分は特定の実装のできの悪さだと思う。

本質的な問題。モバイルデバイス、とにかく計算資源がない。CPU 遅い、メモリ少ない、ストレージ少ない、ネットワーク帯域細い。なんでとりあえず Prometheus の agent をインストールしましょう、というわけにはいかない。モニタリングをするにあたってもかなりケチくさくやらざるをえない。

実装のへぼさ。 つまり、そうはいってももうちょっとなんかないの？というね・・・。Performance Team もなんらかの clue がないとできることは限られてしまうし、ましてアプリ開発者(自分)はもうわけわかんないログ睨むの疲れたよ・・・。ただ最近は Perfetto というプロジェクトでそのへんをなんとかしようとしているらしいので、首を長くして待っている。

クライアントサイド固有の難しさそのに。Production の制限の多さ。要するに我々は SRE と違って世の中の電話機に adb したりできないのである。いや、できたら困るんですよ。わかってますよ。でも出来なくて困ることもあるんだよ！Systrace できないじゃん！みたいな話です。

まあ Lambda や App Engine とかも開発者はコンテナにアクセスできないので似たような面はある。すると app-level の instrumentation がいよいよ重要になってくるため、結局は計算資源がボトルネックといえる。

クライアントサイド固有の難しさそのさん、といえるかどうかはわからないが違うところとして、ロードが burst 的というのがある。だから広い sliding window で time series の log をとる、とかやると重要な情報すなわち burst/spike を見逃してしまう。これは実際に時系列のデータを見て意見してるわけではないので間違いかもしれないが・・・。

スマホ、大半の時間は寝て過ごしている。画面をつついている時間も大多数は平和なものだ。アプリを起動する瞬間、データをロードする瞬間、カメラのシャッターを切る瞬間、なんらかのデータを submit する瞬間、モードを切り替える瞬間など、ほんのゼロコンマ数秒から数秒の間に起こる色々な細部が重要で、その数秒に問題があるとアプリが固まったり描画が乱れたりする。これはたくさんのクライアントから並列でリクエストが飛んできて結果として全体のマクロな負荷は平滑化されて見えるサーバの皆さんの典型的なロード特性とは異なる。

Burst 的、別の言い方をするとロードが時系列方向に heterogeneous である、と言えるかもしれない。なんでサーバサイドと同じようなモニタリングしてもダメだと思うのだよな。ではどうするか、は、アプリ次第だけれども、system-wide でいうと AcitivityManager や LMK の活動は重要な指標になりうる。Historian はそのへんよくできており、こいつやるな、と思う（エラそう）。

他の切り口でいうと、homogeneous な負荷の世界ではスタックトレースのサンプルをソートした framegraph が重要で, 負荷の heterogeneous な世界では普通の時系列 trace が重要。クライアントサイドでも、たとえば IPC のスループットをなんとかしたい、みたいな話になると tracing より framegraph が役に立つ。むかし Chrome の IPC 載せ替えを手伝っていたときは tracing より perf と framegraph が友達だった。

とにかく Android アプリは app-level および system-wide 双方が structured  で resource efficient な continuous かつ in-production の instrumentation をがんばらないといけない、ということです。もっとかっこいいツールとかダッシュボードとかみながらタタターンってかんじで性能改善したいじゃん。させろ！

聞いてる Podcast の入れ替わりを記録。

おわってしまったもの:

• Exponent | A podcast about tech and society, hosted by Ben Thompson and James Allworth 残念だが、この人達はある意味で似たような話を繰り返しているので仕切り直す必要は理解できる。
• Revisionist History Podcast Season 3 がおわって、Malcolm Gladwell の次の podcast はあんまし自分の興味のないものらしい。残念だけど、ネタ切れというのはあるだろうな。

ききはじめたもの

• Modern Love これはすばらしいね。人生からマンガを絶って以来失われていたものが帰ってきたかんじがする。谷川史子的ものからヤマシタトモコ的なものまで幅広い。時々弘兼憲史が混じっている点についてはめをつぶってやる。毎回聞くものではなく、すごい意識レベルが下がっているときにばっと聞くかんじ。
• The InfoQ Podcast, ThoughtWorks Podcasts | ThoughtWorks こっちの路線は必ずしも興味があるわけではないが、たまに聞いてる。SE Radio みたいなもんだな。

しばらく audiobook を減らしていたけれど、また Audible subscription を復帰しようかなあ。Podcast ばかりだとどうしても飽きるね。

土曜の朝に早起きして考え事の時間をとる実験、第一回。6:10 くらいにスタバ到着。

• スタバが空いているのは良い。
• 朝起きるのは大変。特に前夜に早寝できないと無理。そして金曜の夜は何かと滞りがちである。ただ相対的にはコントロールしやすいね。

果たして続くでしょうか。

TickTick という TODO アプリを使い始めてみる。Android 圏でちゃんと cross-platform できる数少ない TODO アプリのひとつ。

TODO アプリ、複数使うのはアホらしいと昔は思っていたが、気が散らないという意味で用途によって使い分けるのはいい気がしている。自分は、夫婦 grocery list には Wunderlist を使い、夫婦それ以外リストには Basecamp を使っている。TickTick は自分雑用トラック用。

Wunderlist どうすっかなー。Microsoft TODO への移行を促されて以来いよいよ本気でメンテされてないが、Micorosft TODO の圧倒的余計なお世話感は移行する気を削ぐ。アプリが壊れるまではほっときます。なんとなく iPhone X 移行とか ugly になってそうなもんだけど、どうなのだろうな。

Shingles / 帯状疱 が出てしまった。痛痒い。虫刺されと腰痛が同時に来ているような感じ。

ウェブを読んだ情報からおっさんの病気だなーと思っていたが、チームのメーリングリストに "shingles になっちゃったので悪いけど感染気をつけようねー" 的なメールを書いたところ、俺もなった、辛かったわーという返事が２つ。どちらも年下。必ずしもおっさん専門の病気というわけでもないらしい。だからなんだっつー話ではある。

ストレスなどで免疫が弱るとなりやすいという。このところかなりストレスレベルが高まっていたので、そうですね、という。家も仕事もストレス源自体は減らせないので、ストレス感度みたいのを下げてかないといけない。自分はストレス溜めやすい方だと思うので。

Podcast もどうすっかなー。しばらくお休みすべきか・・・。仕事もおやすみしたいが、それは叶わぬというか色々都合が悪いのでぼちぼち働きます。一週間くらいで治るなら休んでもいいけれど、回復まで一ヶ月くらいはかかるものらしい。

去年の終わりから今年にかけて、椎間板ヘルニア、chest wall pain (肋軟骨炎), overactive thyroid (甲状腺機能亢進症), そして shingles と病気ばかり。こう病気が続くと、あと何年生きられるのだろうかみたいな気分になる。が、気を取り直していかないとなあ。この先何年も似たような状態が続くようなら、まじで半引退して負担の少ない暮らしに舵を切る必要があるかもしれないが、まあその時がきたら考えます。あとから振り返って今年は特別ひどかったね、と思えることを期待。

時間をつくったとしてどんなコードを書きたいかぼんやり考える。時間をつくれる目処は立っていないがそれはさておく。

まず Android のアプリ、一人で一定程度規模のあるものを書きたい気持ちがある。いままではゴミのような小物しか書いていないので。ゴミのような小物しかないのはやる気ではなく実力の問題なのだが、やらないといつまでも実力つかないからね。

できれば Android からは足を洗いたいとういう儚い願望はあるが、ここ数年の選択の結果すっかり Android しかできない人になってしまったので、せめて Android  開発者としては一人前になっておいた方がいいのでは、という気がしている。たとえば転職したい、とか思ったとして Android 開発者枠以外では雇われようがない。いまのところ転職したい気はないが、世間の動向からして勤務先で働くのに耐えられなくなる可能性はなくはない。そして最悪転職できる、と思えることは精神衛生に寄与する。

それとは別に ML やらないと、という焦りもある。しかしこれは仕事との相関が一ミリもない上に謎の理由で stuck して結局コード書けないみたいな可能性が高いので、コードを書くという目的には向いてないようにも思う。謎の理由で stuck するのはおそらく ML 修行には必要なフェーズなのだろうが。

この中間くらいの路線として, CV  なり Computational Photography なりのアルゴリズムを実装してみたい気持ちもある。いまの立場で Android 以外のなにか面白いことをやろうかな、とおもったらきっとこのへんが一番近いので。・・・と思っていたが、実際にこういう仕事をしている本職の研究者、および今でこそアプリレイヤで働いてるけど昔はピクセルさわってました、みたいな人の仕事ぶりをみると現状の自分と距離がありすぎてはじめる前から諦め、みたいな気分。

転職という話だと leetcode なり Euler なり HackerRank なりで coding quiz の練習でもするか、という選択肢もありうる。しかし正直自分はこの手のがまったく好きではないので、ほんとの職探しが目前にない限りやる気にならないなあ。短い時間でインクリメンタルに結果(正解)がでる良さもあるのだが。

実利という意味では何らかの Android 関係のオープンソースのプロジェクトにパッチを書く、というのもアリといえばアリ。でもまあ、あまりに仕事的すぎるというかたくさんコードを書くには向かないね。自分はコードの書き方がその手のパッチ修行に最適化されすぎているので、その路線を練習しても仕方ない。転職的な意味ではこれもそこそこ効果的ではあるのだろうけれど・・・。

こういう実利を完全にぶっちぎって無意味に言語処理系とかレイトレとか書きたい。という願望はないではないけれど、ファンタジーにしか感じない。

もうちょっと実利的にクラウドつかってなんかする、みたいのはアリかもしれない。しかし自分はクラウドつかってなんかするの実利を得られる身分ではないな。Android 枠でしか転職できない上に、会社の中はクラウドじゃないからねえ。

まあとりあえあえず Android アプリをなんか作る、としよう。

WordPress で日記を書くアプリ。WordPress for Android は遅すぎるというか UI がゴテゴテなので、もうちょっとテキストを書き捨てられる何か。欲しい。しかし自分がどうでもいいとおもっている「インターネットから JSON を持ってきてリストを表示するアプリ」なので、イマイチ盛り上がらない。でもまあ、こういう定番の作り方を知っておくのが "Android 開発者" であることだろうな、とも思う。

何らかのカメラアプリ。自分の持ち札的にはこっちをやった方がいいことに思えるが、特に作りたいものがないという問題がある。エンドユーザとしての自分がテキスト中心すぎて、画像でやりたいこととか全然ないのだよね。もうちょっと画像とか写真のリテラシーがあればよかったのだけれど。写真は Camera と Photos で完全に足りてます、という・・・。

今は規模は諦めて Hello Work をやる方が良いのかも知れない。やってるうちに何か書く気が湧いてくるかもしれないし。でもなー。なんかちゃんと頭つかって規模なりアルゴリズムなりの難しさがあるものを書く、ということがしたいのだよなー。

この何もかける気がしない感じ、ちょっと鬱病のひとみたいでよくないなあ・・・。

ここ数ヶ月くらいデバッグのためにログを睨んだりちまちました高速化のために Systrace を睨んだりしてばっかりだったせいか、なんか全然コードが書けなくなってる感じがする。そしてこの先もあんまりでかいコードを書く展開にならない予感。リハビリというか筋トレとしてある程度まとまったコードを書きたいが・・・。

どうしたもんかな。仕事を休むか仕事をサボるか。この２つは実は本質的には大差がないのだよな、仕事は結局進めないとならず、サボろうが休もうが仕事が進まないことに差はないわけだから。仕事を休むのは制度なので休んでもクビにはならないわけだが、自分は今はクビになるよりもうちょっと色々やらないといけない身分になってしまったので、こう、心の余裕がないね。

仕事でまとまったコードを書けばいいのでは、という話はあるのだけれど、書くものないのだよね。いやリファクタリングとかすれば表面的な行数としてはいっぱい書くわけだけど、そしてそういうリファクタリングの TODO は若干あるからやる予定ではあるけれど、リファクタリングって本質的にはコードの品質以外何も生み出さない（そしてそれが良いところである）わけなので、ここでいう「まとまった量のコードを書く」には該当しない。ズバっと書き換えて高速化する、とかはリファクタリングとは違うが、速くできるならもうしてるっつー話です。

仕事のコードはリアルに価値を生み出さなければならず、それはめちゃめちゃコードを書ける人にとってはともかくボンクラ勢にとっては難しい。なのでどうしてもリファクタリングとかバグ直しとか細かい高速化とか、小さいインクリメントで小さい成果がでるものに逃げがち。

逃げずにリスクを取るとどうなるのか。というと、そもそも今の自分の仕事でどうリスクを取ればいいのかすらわからん。というのは、ガバっとコードを書いて実現したい新機能とかすごいかっこいいアーキテクチャとか別にないからね。

まあ「無い」というと語弊があって少しはあるんだけど、自分の立場を踏まえた優先度としては他に色々やることがあり、それらの「やること」はコードをガバっと書く以外の細々したものばかりなのである。困ったね。

この仕事でガバっとコードを書く自分が想像できない事実と、コード書きリハビリの必要性はたぶん表裏一体で、仕事でガバっとコードを書ける身分になるためにリハビリが必要だと自分は感じている。

これはもとをたどると去年チームに入ったときによくないリスクの取り方をして失敗し、その後の病欠などとをあわせコードを書く立場を作るためのリスク予算がなくなってしまった、という現実の帰結なのだろうなあ。

この話を総合すると下手に余剰の時間でランダムなコードを書くのはいまいちで、限られた余剰の時間はコードをがばっとかける身分への歩みにあてるべき、ということになるが・・・。

しかし経験的にこの何も見えない状況でそういう投機的な行動をとるのは良くない気がするな。リファクタリングでもバグ修正でも、個々の規模の大きさは気にせず数をこなすことでチームのコードをさわることにもっと体をならす方が良い気がする。

というのは今のチームに入って一年経つにも関わらずすごい限定的な働き方をしてしまったせいでコードベースに体が馴染んでおらず、それもズバっとコードをかけない感覚に寄与している気がするから。

つまり今の自分には２つ問題がある。1. 目の前にあるコードベースへの慣れの不足、そして 2. 絶対的なコーディング量の不足。これらに実績不足が組み合わって、仕事でガバっとコードをかけない状態を生み出している。小さい変更を積み重ねると 1. を改善できるし、2. についても少しは足しになる。だからこれがいま仕事の時間を使ってやるべきことに思える。

コーディング量の不足は・・・。やっぱり Podcast やめるしか無いかな、という気がする。しかし始めてしまったものには色々 inertia があって踏み切れないでいるのだった。

今年もふたたび @Scale に行ってきた。(去年)

おもしろかったが、一方でこういうかっこいい何かの一部になることは自分にはもうないだろうと思い知らされる面も強く、気落ちした。

知り合いが podcast で "自分で作ろう！" という話をしていた。この episode の主張は、プログラマは年をとると自分で何か作っても大変な割に良い物ができないからと既製品ですませようとするが、それは面白くないし作らない側のバイアスが強すぎるので作る側に倒してみると良い、という話。

自分は、すくなくとも余暇では何も作ることはできないし、仕事も目先の成果を優先して色々妥協しているのでここでいう「作る」に相当するなにかをすることはない。別の言い方をすると自分は作るか作らないかという選択肢から作らない選択をしているわけではなく、作るという選択肢がない。作る必要がある問題は、単に諦めている。

これは悲しいことだが自分の選択の結果なのでどうこういう気もない。自分の現状を正当化しようと作る選択肢の価値を低く見るようになってはいけない。一方で、現実にはそれは難しいとも思う。自分が「正しい」選択を諦め続けているという事実を見つめながら日々を過ごすのは、控えめに言って憂鬱だ。だから自分の言動の端々からは「作らなさ」のようなものが滲み出ることだろう。自分の知人にもそういう人はいる。

支持したい価値観と自分の行動が一致しないことが増えてきた。こういう場面で人々の振る舞いは色々だ。

行動にあわせて価値観を調整する人もいる。上の例で言うなら何かを作らずありもので済ますのを良しとするようになる。行動と言動の不一致を受け入れる人もいる。「自分で作るといいよ」といいながら自分では作らない。何も言わなくなる人もいる。ただ姿を消す。

多くの場合は、これらが少しずつ同時におこる。言葉の角が丸く曖昧になり、時々かっこいいことをいっても行動は伴わず、存在感が薄れていく。

また時間のなさについて考えている。というのは週末の leave alone 枠を数週続けて撮り損ねた上、今週(いま)も半分くらいになってしまってかなり frustration の水準が高まっているため。

時間がない、という事実はあるわけだが、可処分時間が単調減少しているのかというと、ゆるやかには単調減少であるにせよこのゼロになってるんじゃね、という体感が正しいとも思えない。何が起きているのか。日常の fluctuation が以前より大きいのだろう。つまり波が合って不規則である。

たとえば週末の leave alone 枠にしても日曜の 10 時から、とか決めてあるわけだが外出の予定のとかに上書きされ予定通りにことが進むことは少ない。食事の時間とかも子供の昼寝などに合わせて微調整されるので、この 10 時という予定を決めた前提もすぐに崩れてしまう。気がつくと時間は失われている。週末は特にその傾向が強い。というのは外出のタイミングは必ずしも自分たちだけでコントロールできるものではないから。

この不規則さとどう折り合いをつけるか。一つは少し無理をしてでも不規則さの影響が比較的少ないタイミングに予定をつっこむ。たとえば早朝とか。たとえばこのスタバは  5:30 から開いているらしいので、眠気をこらえて 5 時に起きて駆けつけ、5:30 時から 8 時くらいまで確保する、というのはどうか。なんとなく自分の規則正しさの限界を超えてしまっている気もするけれども・・・。あと週末に限っては深夜帯を利用する路線もありうる。田舎なのでコーヒー屋とか一切空いてないという問題はあるが・・・。そして年寄りなので深夜は早朝より辛いね。だめか。

直行する論点として、不規則に生まれた時間をどう取りこぼさないかを考える必要もある。不規則であるということは（長期的には）失われた時間がどこかで帰ってきているはずなので、それを逃さず捉える必要がある。

たとえば、最近は朝の時間は完全に失われた一方でゆこっぷ（おくさん）が子と co-sleep するようになったため夜の時間が増えた。夜は朝より疲れているので朝やっていたように気合をいれて難しい教科書を読み続けるのは難しいが、それでも podcast 準備の論文を読むくらいはできる。

ただこの夜の時間は自分のリズムに完全に組み込まれておらず、いまいち活かしきれてない。なんとなくだらだらネットをみて夜が更けてしまって後悔することが多い。

こういう不規則な時間をキャッチしてなんかやるのは、子供ができてからずっと考えているけれど今のところ機能してない。MSR のひとが Microproductivity という研究をしていてこれは問題意識としてちょっと違いきもするのだが、なにしろ research なのでなにか使えるものがあるわけでないのだった。ただこう iterative かつ incremental になんか書く、というのは以前からできてらいいと思っているので、もうちょっと追求しても良い話題なのかもしれない。ゼロ秒思考とか、切り口は悪くないと思うんだけど蒸留するフェーズが弱いよね・・・って前も書いたな。

自分は文章を書く時は基本的に一撃でズバっと書く傾向があり、逆に書きかけで止まると書き上がることはないのだけれど、もうちょっと iterative に書き、アイデアを整理していく方法を考えた方が良いのだろうなあ。むー・・・。保留。

まあまずは早起きですかね。きびしい・・・

手元では再現しないが厄介なバグを割り振られ、ここ一週間くらいじっとログやコードを睨んでみたり再現を試みたりしていたがあまり打ち手がなく、仕方ないので問題が起きた時にそれを検知してこっそりアプリを殺す、という回避策コードをコードレビューにだしたところ「これほんとに治るの？それとも speculative fix なの？」というので「speculative だし fix ですらない partial mitigation ですよたぶん dead lock かなんかっぽいんだけど・・・」と返事。すると「Dead lock なら再現したときに bugreport とると thread dump が入るからわかるよ」と指摘される。なんだって！Bugreport なら最初にもらったやつが一個だけあるよ！さっそくログをにらみ直すとたしかに最後の方に thread dump が。そしてたしかに dead lock (じゃないんだけど似たような事態) がおきている！

普段はそのへんのノイズをフィルタし表示してくれるビューアを使っていたのでまったく気づいてなかった。この一週間はなんだったのか・・・といっても dead lock ぽいなと気づいたのは数日前。この数日はなんだったのか・・・。

適当な修正を書き、問題の箇所の持ち主にレビューを出す。そしてあちこちたらい回された結果、どうもその問題はちょっと前に依存関係の奥の方で修正されていたとわかる。そりゃ再現しないわけだわ・・・。

というわけで自分の書いたコードたちはチェックインされることなくバグがなくなり、めでたく締め切り前のノルマ完了。まあそれらのコードは会話のきっかけみたいなもんだったのでどうでもいいんだけど、ストレスがしんどい一週間だった・・・。

Bugreport に thread dump が入っているのを知らなかったのは残念だったが、それ以前に自分はほんとにログを読むのが下手だなあと思う。あとからみると、たしかに根本にあった問題を匂わせる出力はログに含まれていた。しかしノイズをかき分けてそれに気づくだけの才覚がなかった。

しょうじきこの「Bugreport のログから色々読み取る」というスキルはレガシーかつドメイン固有な上に持つと色々嫌なものを引き寄せてしまう気がするのであまり上達したいとも思わないのだが、一方で性能改善の仕事をしているとログを相手にトラブルシュートしなければいけないことは多い。生き延びるためにある程度は鍛えないといけないのだろうなあ。やだやだ・・・。

この「手元では再現しないがおかしい」という類のバグは、特に性能がらみでよくおこる（「なんか遅かった」的なやつ。) On-device tracing があるとだいぶ違うが大抵 trace なんてとってくれないので bugreport の限られた情報から憶測するしかない。多くの場合はしばらく睨んだ末に「わからん。降参」となって終わり。この triage 作業は今の仕事で一番イヤな部分と言えよう。やりたくないけど、性能仕事をしている限りは逃げられない。厳しい。色々対策は考えてるけど、どうなるかね。

今週は旅行のため Podcast を録音しておらずしたがって編集もないので、その暇にどうやったら購読者を増やせるかを考えてみる。増やす必要があるのかは今は脇においておく。

Buzz

まず完全に自分の直感で頭に浮かぶアイデアを書き出してみる。

話題を buzz りやすいものにする路線がありえる。buzz りやすいすなわち social media でリンクされやすということね。これには２つの切り口があると思う。

一つ目は題材/headline に流行り物や人々の好きそうなものを選ぶ。流行り物はさておき、好きそうなものとは何か。聞き手がその話題について知っており（あるいは知っていると信じており）、どれどれこいつらどれだけわかってるか聴いてみっか、みたいな態度で聞ける話。たとえば bikeshed であったり古典であったり。自分の意見を (support であれ confrontation であれ) 表明しやすい話題と言えるかもしれない。昨今は意見を表明する = social media になんか書く、なので buzz に向いている。

流行り物は自分も知りたい時があるのでそういう時だけやればいいとして、「人々の好きなもの」はねえ・・・購読者を増やすことが他のなにより優先するひとだけがやることであって、自分はそれに該当しない。Empirical software engineering  の話、読むと面白いけどあまりやりたくないのはこの「人々の好きなもの」成分が強すぎるから。

話術

つぎ。話術を軽妙にする。なんつうかこれは「話を面白くする」みたいなトートロジーぽい主張に見えなくもないけれど、情報としての価値ではない filling の部分をよくする、ということで、ようするにテレビのトークショーとかのホストやレギュラーのようであれ、ということだよな。まったくできる気もやる気も沸かない話だが・・・。

ただ軽妙さはともかく滑舌はもうちょっとなんとかしたい気がしている。編集してて自分のいってることがしばしば聞き取れことがあり、聴いてる人に申し訳ない。

Referral

すこしデータをみてみる。上で buzz ればよいと書いたけれども、じっさい social media  上でのリンクの流通はどのくらい購読者増に寄与するものだろうか。Misreading Chat, stats を見ていると social media より検索エンジンからの流入の方がだいぶ多い。これは自分がむかし blog を書いて stats  を眺めていた時には見られなかった現象な気がする。確認のため前に書いてた Medium の stats を見たら Twitter だのブックマークサイドだのばかり。検索エンジン全然 refer してくれてない。

検索でサイトにたどり着いてくれていることを考えると・・・。どうしたらよいのだろうね。たとえば show notes をもうちょっと親切にするとか? でも show notes で気が済んだら聴いてくれないからダメだな。Rebuild とか Turing Complete FM とかは chapter をつけていて、あれはエライし聴いてもらう敷居はさげていると思うが、面倒すぎるし Wordpress の hosting ではどのみちうまくリンクできないからダメ。

iTunes

多くの podcast は番組内で iTunes に review を残してくれるよう頼んでいる。Review の流量が iTunes 内でのランキングに寄与するためらしいのだが・・・ Apple デバイスというか iTunes の動くデバイスを持ってない身としてはランキングってなに？ってかんじなのだよなー。てか Chrome OS 開発者と Android アプリ開発者がやってる podcast をみなさん iTunes で聴いているの? ほんとに?

iTunes の Podcast Analytics はいちおう見えるようにしてあり、それによると各エピソード最終的に 500 devices くらいでは聴かれているらしい。これは多いと思うけれども、一方で 7-8 割くらいといわれる iTunes の podcast market share を自分たちの購読者が反映しているというアイデアも直感的には信じがたい。まあ自分が Android にバイアスされすぎてるんだろうね。ただ自分で見えないランキングのために何かをお願いするのはアホらしいなあ。 自分がこのアホらしさを克服できたらお願いすることにしよう・・・。

The YouTube stars heading for burnout

とかぼんやり考えていたら職業 Youtuber の苦労について書かれた記事を見かけた。記事の中では彼らが購読者獲得のため何をがんばっているかについても触れられている。YouTube は podcast よりは Web 寄りだけれども、同じ非活字メディア同士参考になる部分はある気がする。

記事の中では social media やコメントでの engagement, 更新頻度, 他の Youtuber からの推薦(を得るための Youtuber 同士の社交) に苦労しているとある.

自分は social media があまり好きでないので Twitter で反応するとかはあまりやってない. 購読者を増やす意味ではやった方がいいんだろうけれども, Twitter にログインしたくないので. Social media の外に dedicated な forum をつくる、というのも理論上はできるけれども、なんとなく嫌な予感しかないので多分やらないでしょう。

更新頻度は, 結果的に週二回になっていてこれは良い方向に機能してるのだろうけれども, 個人的には編集とかが大変なので半分くらいでもいいかなと思っている. ただ論文を読む量も減ってしまうので, 今のところ週二回になっている.

他の Youtuber がどうこういう点だと、じっさい Misreading Chat の購読者は Rebuild や Turing Complete FM 経由でやってきた人が多いっぽいので、きっと効果はあるのだろうな。ただ、たとえば Rebuild に出してもらって自分の podcast の宣伝をするというのも図々しく感じてしまう。一回やらせてもらったからもう十分でしょう。自分が他の podcast を宣伝するのは別にいいのだが。

むしろこの記事を読んで思うに、自分は職業 podcaster ではないのだから生活がかかってる人々と同じ指標すなわち購読者数を気にするのは筋が悪いのではないか。そもそも日本語のプログラマ向け Podcast を職業でやってる人はいないと思うけれども・・・。

様々な時代の力によって本職ではない個人までもが stats と attention の虜になってしまった blog の不幸を繰り返さないためにも、購読者数のような他人の数字ではなく自分にとっての価値を重視する方がよい。とおもう。と、結局いつもの結論になってしまうのだった・・・。

ただ滑舌は、もうちょっとなんとかしたいです。はい。

Snippets, 始めたのが 2015 年の初頭くらい. 去年の途中であまりに何もできない時期が続いたため一旦リタイアし, 今年の 3 月くらいからまた復帰していた. しかし結局なにもできていない.他の人々ががんばってるのをみると, 励みになるより自分の powerlessness が際立って depress されてきてしまう.

この Snippets はもともと互いの活動に触れることで自分を procrastination とか complacency から立て直す目的で始め、それは機能していた。でも今の自分の問題は時間のなさであってサボりであるとは感じていない。だから今週も何もできませんでした、しかしどうしょうもないかんじです、みたいな snippets を書き続けているとどんどん現実が reinforce されていくように感じる。

一方で snippets をやめても特にどうにもならないこともわかっている。なんというか、どうにもならない現実を受け入れるか、リマインドされ続けるかの違いみたいなかんじか。

これは benchmark の rebaselining に似ている、だろうか。ある benchmark で何らかの数字が悪化し dashboard が赤くなる。しかし諸事情からその数字が改善しないことはわかっている。このときやるべきことはベンチマークの baseline を現状の数字で書き換え、今後の regression に備えることである。その dashboard を赤いまま放置することでも、continous benchmarking を止めてしまうことでもない。ゼロ成果な Snippets を書き続けるのは前者、Snippets から脱退するのは後者に相当するように思える。

では baseline の update に相当するのは何なのだろうか。それ以前に、自分は現状を受け入れるべきなのだろうか。それとも何かもうちょっと悪あがきすべきなのだろうか。というと悪あがきすべきなのは明らかなのだが、特にアイデアないのだよね。そしてこのメタファでいくと順番としてはまず rebaselininig で regression に備えた上で try-n-error するのが望ましい。なので今の自分を monitoring するのに相応しい baseline について考える必要がある。それはできれば snippets のフレームーワークに則っているのが望ましいが、必ずしもそうでなくてよい。

どうしたもんかねえ。といったところで今日は時間切れ。