ふと GitBook を見てみたら、PDF と EPUB のエクスポート機能がなくなっていた。ええー・・・どうも電子書籍執筆ツールからテクニカルドキュメンテーションのホストに衣替えしたらしい。それ Read the Docs なのでは。一方で Read the Docs にマーケットがあったのは明らかなので、その市場に乗り込むのは正しいのかもしれない。
個人的にはオンラインで Markdown から EPUB を作れるサービスとして老後(?)の楽しみにしてたので残念。
ところで Read the Docs の Github アカウントは rdfd らしい。F を落としたのはえらかったね。落とさないという選択はあり得ない気もするけど。
GitHub のコードブラウザはディレクトリのページでまず README を表示してくれる。これは小さいながらすごく良い発明だったと思う。今では GitHub に限らずソースコードをホストするサイトは概ねこの仕様に従っている。
あるディレクトリやパッケージになにがあるかを説明したいことは多い。Javadoc にもそういう機能があった。でも言語を問わず README を書ける方が堅牢でいい。言語固有の拡張はあっていいと思うけれど。
会社の中にあるコードブラウザも数年前から README 表示がついた。Monorepo を採用していると README はプロジェクトのホームページみたいになる 。GitHub でいうとルートディレクトリの README が重要なのと同じ。これがない時代はいったいどうしてたのかと不思議になるくらいの必須機能。
ディレクトリ単位で README をつけられる機能、ソースコードの文脈以外でも欲しいことがよくある。ちょっと前から Google Apps に Team Drive という機能がようやく追加され、チームのドキュメントはここに集約しましょうという話になる。けれどディレクトリにファイルが並んでるだけだと、そこに本来なにがあるべきといった情報が足らず膨大なドキュメント群を navigate できない。
ここでディレクトリ単位の REDME があったらどれだけ便利だろう。とりあえず新入りはこのドキュメントを読め、新しい design doc はここにおけ、ミーティングの議事録はここ。そんなガイドを書いておける。今はそういう情報は Google Sites （まだあるよ！）に書くことが多いのだけれど, コードに近いドキュメントは markdown でレポジトリに入れそうでない文書は Docs で書く結果 Sites に残された情報って README 代替以外でそんなにないのだよね。しかも Sites と Docs は認知的に遠い上に主戦場が Docs なせいで README ページは保守されそこねがち。Docs に README があればもうチーム内情報の整理に Sites いらないじゃん。
ドキュメントはぜんぶ Markdown で書けば Docs だっていらないじゃん、という主張はありうるし、実際そういうチームもある。ただレビューしたり図を書いたりするのは Docs の方がだいぶラク。Docs がコードのレポジトリにチェックインできたらなあ・・・と思う瞬間がないではない。それは MS Word という。別に Word を使いたいわけじゃないんだよ。
Docs に README のインライン表示がついたら、自分の中にかすかに残る Wiki への郷愁を完全に殺すことができるのになー。
最近ようやく（自分以外の）子供がかわいいという感覚がわかってきた。けれど自分の場合、よその子の中にも結局我が子の影を見ているからだなと思う。
3-4 歳くらいの子供が公園で遊んでいる。自分の子ももうすぐあんな風になるのかな、と思う。新生児が stroller の上で眠っている。自分の子も少し前まであんな風だったのに、大きくなったな、と思う。泣き叫んでいる子供を見ても、ああ可哀想に眠いのかな思い通りにいかないことがあったのかな、と思いはすれど特に不愉快に思うことはない。結局、自分の子供もそういう時があるからだと思う。共感といえば聞こえはいいけれど、天気みたいなものだよな。雨が降ってるのに怒っても仕方ないというか。
自分の子供が、たとえば１０歳くらいになったとき、newborn や toddler を目にした自分は我が子の小さい頃を思い出すのだろうか。思い出せる方が子育ては実りあるものになると思うけど、物忘れは激しいし、どうかな。
説明するってのは難しいなあと Podcast をしていて思う。今回の Graal/Truffle は周辺論文も読んでほぼ理解したつもりだったが、話してみるとわけわからんかんじになってしまった。
なぜかと考える。ひとつは Truffle/Graal というものがどう振る舞うかはわかったが、それが他のものと比べてどう新しいのかについての理解が足りていなかったこと。たとえば普通の最適化コンパイラ/JIT にはなぜそれができなくて、なぜ Truffle ではできるのかという部分の説明ができなかった。それは
とかだよな。
でもこれは、実際に説明しようとして失敗しないと思い至れない。いちおうなにを話すかはノートに箇条書きしてあるのだけれど、それが不十分なのだろうなあ。結局、自分がアイデアのコアを理解できてないということのような気もする・・・が、こうして事後的にはわかるのだから、理解してないというのとも違う。説明できないだけで。
公開前に読みなおしてわからなさを判断できるブログだとこういう問題はおきない。でもブログを書くのがと大変だから Podcast をやってるわけで、たとえばブログを書いた上で Podcast に臨むとかは時間がかかりすぎて本末転倒。
もうひとつのオプションは、前の日のランチとかでリハーサル？をしておくことだろうか。ただそれだと聞き手がねたばれしてしまい、本編の会話がいまいちになってしまう気もする。向井さんじゃない誰かに説明してみるのがよいのだろうけど、日本語の通じる知り合いがまわりにあんましいないのだよなー Y 氏くらいで・・・もうちょっと日本人同僚たちと親しくしておくんだった・・・。英語でやれ？すみません・・・。
箇条書きのノートだけだとうまく話せないのは、スライドだけつくってもうまく講演ができないのと似ている。事前の練習が必須。一人で、あまり手間をかけずに、それができないもんかなー。まあ講演の練習なんかは一人でやることもあったから、やればいいだけかもしれないが・・・。夜中にやるの？ひとりで？まあ一回くらいは練習してみていいかもしれないな。あとはやはり Y 氏に犠牲になってもらうか・・・あのひと木曜の昼はあいてるのだろうか・・・。
あとはノートをもうちょっと会話に近づけていくというのはあるかもしれないね。しかしそれほぼ Blog なのでは、という気はする。時間と手間をかければよくなるのはわかるが、本業および家庭に差し支えると困るのでラクさは重要なのだった。持続可能性。
持続可能性という意味では週に一本、担当は隔週にするのはよい。自分への論文読み圧が減ってしまうのはやや残念でもあるけれど。
前回の RISC-V の話がなぜ比較的大丈夫だったかというと、立ち入った話が少なかったからだろうね。ああいう与太話寄りのはラクだけれど、やっぱり立ち入った話ができないと面白くないよなあ。自分が。世の中の説明がうまい人たちの頭の中ってどうなってるのだろうね。
追記
うー
こう説明すればだいぶ腑に落ちるはずだが、この理解には到達できていなかった。限られた時間でこういう理解に辿りつけなかったのは、自分が言語処理系に通じておらずメンタルモデルが弱かったせいだよなあ。
練習するとかもあるけど、ちゃんと腑に落ちるまで考えるのも大事。練習をすると自分の理解の不備に気付きやすくはなるが、けっきょく理解には時間をかけないといけない。
仕事のうだつがあがらない問題に対処すべく、会社員技能について基本に立ち戻って見直そう、本でも読んで考えを整理したい、などと考える。
けれどプログラミングとかソフトウェア開発の本を読もうという気になれない。残念。なぜかと考える。たぶんコーディング能力をちょっとあげたらくらいでは仕事の難関を超えられる気がしないからだろうな。世の中にはコーディング能力がボトルネックになる仕事は割とあるし、圧倒的にコードがかければ多くの問題をその力で片付けることもできる。ただ自分の目の前の仕事はそうではない・・・つまり漸近的なプログラミング技能の改善が仕事の生産性に直結していない気がする。ドカーンと書けるようになれば別だけど、そういうことはおきないから。
それじゃジコケーハツでもしますか、というと・・・悪くはないだろうけど、自分は既にライフハック的なのはやってしまっているので、大きな期待ができない。復習がてら軽く古典的なやつを読み直してもいいかもは思う。達人プログラマ的なソフトウェア開発者向け読み物にせよ、GTD 的な一般ライフハック読み物にせよ。
自分が弱いなと思うのは「何をやるか決める」あるいは「なにをやり続けるかを決める」みたいな部分。最近 Sam Altman が書いていた Productivity という記事でもそれが一番大事と言う。自分は別に起業家でも経営者でもない会社員だけれども、そんな下っ端にも何をやるか/やらないかのオプションは結構あり、選択は成果に大きく影響する。
これは最初になにをやるか決める時だけでなく、プロジェクトを続けていくなかで予期しないことが起きた時に舵取りの判断をする話でもある。進みが遅いとき、大きな問題が起きた時、壁を押し続けるべきなのか、方向転換すべきなのか、諦めるべきか。それを誰に相談してどう決めるか。こういう判断は日々フラクタル的に発生してるけれど自分は良い舵取りの指針を持っていない。
あとは他の人と協力して何かやるのもあまり得意でないなあ。頼んだことをきちんとやってもらうとか、利害関係を調整してなんかやるとか。今のプロジェクトはそういう場面が多く、手こずっている。それだけじゃないけれど。
やることを決めるとか関係者との協力とかっていわゆる leadership の文脈で語られることが多いけれど、自分は別に lead ではない。世の中の leadership 愛好家は肩書とは関係なく leadership はあるというけれど、やはりチームとか組織の責任をもってる人と individual contributor では権力や戦力の量(立場があると強い)や身軽さ(立場がない方が高い)が違うので、個人として人々と協力しつつ価値のあることをやる手口は leadership とは別に議論してほしい。しかし世はなぜか個人の生産性の話を lifehack ぽい方向に向かわせがちで、そうじゃなくて・・・と思う。
「問題解決」みたいのは近いといえば近いけれど、なんちゅうか、製品開発は必ずしも問題解決ってわけでもないのだよな。そして問題解決とかいいだすとだいたいプロセスとかに手を出しがちで、しかしプログラマとしての自分はそういうので成果をだしたいわけではない。そうことやってると Engineering Manager とか TPM とかになってしまうよ・・・。
起業家や management ではない。Leadership でもない。問題解決コンサル/TPMでもない。スーパーハカーでもない。が、言われたことをやるだけの純粋末端というわけでもない。世間のよくある肩書の隙間にいるのがソフトウェア製品開発の IC なのだ・・・というのはいまいち納得がいかない。そんな特別なものじゃなくてみんなやってるはずだし何らかの方法論はできてるはずなのだが。みんな leadership 目指して頑張ってるの？そんなことないでしょ日銭稼ぐのだって多少は頭使うでしょ...
きっとそういう議論をしてる人はどこかにはいるのでしょう。自分が仕事のインパクトみたいな会社員的な語りから興味を失ったまま何年も過ごしてしまったから見えていないだけで。真面目にやります。はい。
つまり: 古典を読み直しつつ、弱点を補う話題の読むものを探す。考えを整理する。
なんか同じようなことを数年おきに考えてるなーとおもったら初出は 13 年まえだった。やばい。進歩してない。ていうか 13 年前のほうがちゃんと会社員だった気もする。
人事考課の評定が下がってしまった・・・。
しょうじき仕事がはかどってない体感はあり、予期はしていた。しかし実際に受け取るとへこむのだった。上司はチーム移ってまだ短いし仕方ないからここからアゲてこうなと励ましてくれたけれど、上司に励まされるのはヤバいよなあ。上司がでなく、自分が。よくやってるのでその調子で頼む、以外の評価はよくない。次の半年で同じ評定だとクビ・・・まではいかないけれどだいぶよろしくない。たとえば給料は下がる。困る。
今のチームはクライアントサイドの中では少し特殊なエリアで、自分も馴染みがない。だからこそ良い挑戦になろうと選んだのだけれど、挑むにあたり必要な頑張りが足りなかった。立場を追い込めば自然とがんばるという自分への期待を満たすことができなかった。堕落したな。
今は、去年よりマシとはいえやはり家事育児もあり仕事に使える時間や体力の資源は限られている。にもかかわらず唐突に Podcast をはじめてしまったり ML をやらなければみたいなプレッシャーを感じたりで気が散り、仕事への注力が足りていなかった。
これは優先順位だけの問題ではなく、「気が散る」ことからくる慢性的な生産性低下の問題でもある。仕事中なのに仕事に集中しきれない。これはほんとに堕落したとしかいいようがないので、立て直さないといけない。
集中力に限って言えば、過去に気が散る時期は何度もあった。今までの仕事は気が散っていても経験値で乗り切れたけれど、新しい慣れない仕事は経験値がないので気が散るとだめ。一方で、昔のようにガッツリのめり込んで駆け上がる体力も時間もない。
かわりに: 限られた時間の中で集中して働くこと。成果のでる仕事を優先すること。成果を出すやりかたを優先すること、が求められる。逆にいうと、たとえば新しいテクノロジをさわれる、みたいな自分の興味を優先すべきではないし、同じく深掘りして詳しくなりたい、みたいになんでも自分でやろうとはせず、できる人に頼むことを優先した方がよいということ。
もっというと、好奇心や学び優先ではなく成果を優先するよう自分の価値判断を調整しないといけない。すくなくともチームの中である程度の地位を獲得するまでは。
自分は個人的に成果自体より好奇心や目新しさやハンズオンの充足に重きをおいているのでこれは残念な話だけれど、いまは価値観を優先する余裕が自分にない。それが今回の評定であろう。 wake-up call というやつだ。がんばって成果をだして立場を固め余裕ができたらまた好奇心を優先できるようになる。そう信じて頑張らないといけない。
ただしょうじき、馴染みの薄いジャンルの新しいチームで成果を上げるにはどうべきか、いまいちよくわかんないのだよな。いまのところあまり立て直せる見通しがない。これは時間をかけて真面目に考えないとなあ・・・。自分がそんなちゃんと働けるプログラマなのか不安。しかしこれは向き合わなければいけない不安なのだよ・・・と自分に言い聞かせる。
成果と好奇心が一致していないのは悲しいことか。悲しいことではある。これは自分の実力と期待値と責務が釣り合っていない、端的にいうと実力不足ゆえの話なので、がんばって少しずつギャップをうめていくしかない。
追記: 人事考課の季節
結構あるのでどれを読んだものか・・・。特徴的な最適化手法の話と、上のレイヤからのインターフェイスすなわち IR の話を読むのが良いかなあ。
Product and tool manuals | Docker Documentation
Docker, 色々手を広げたせいでみなが使いたいであろう docker であるところの docker engine のドキュメントがわかりにくくなってしまってるなあ。仕方ないので適当に評判の良さそうな本を買った。
企業とユーザの利害が乖離しており気の毒ではあるけれど、これだと他のコンテナ技術の台頭を許しちゃうんじゃね、と心配になる。自分は Docker に深入りする気はまったくないので、何が台頭してこようと表面的に理解しなおすだけなので問題ないといえばない。それでも詳しくなる気は削がれる。良くないね。
ついでに Audible の subscription も停止。停止ひきとめの案内をみてわかったこと:
一時停止でもいいかとおもったけれど、後腐れないために一旦やめた。たまっていた credit は wishlist に入れておいた本から適当にピックアップして消化。
以前ドライブのあいだずっと podcast を聞きまくっていると話していた友達に、自分のやってる podcast を聞いてよと言ってみた。すると「今年は大きな仕事ができそうな気がしているので podcast は聞かないでぼんやり考え事してる」という返事。
仕事のことを考えるかどうかはさておき、通勤や移動の時間を考え事にあてたいのはわかる。自分も一時期 podcast や audiobook などを聞きすぎて考え事ができていないと通勤中のオーディオ摂取をやめたことがあった。ただそのときは同じことを何度もぐるぐる考えてしまうだけで実りがなかったから、またオーディオ生活に復帰したのだった。
でもそろそろ考え事に時間を割いていい時期かもしれない。Podcast は楽しいけれど、ソーシャルメディアやニュースサイトを眺めるのと似て大きな実りはないよね。
Podcast を聴いている時間のうち、すべてが考え事に適しているわけでもない。たとえば料理中なんてのは考え事には向かない。作業への注意がそれなりに必要だから。でも通勤や運動のように、体は使うけれど頭を使わない時間は考え事に向いている。自分は今年から料理を含む家事の多くをゆこっぷ（奥さん）に移譲してしまったので、オーディオ可処分時間は減ったのだった。そのぶん他の時間が増えているはずなんだけど。
というわけで今月と来月は通勤中の podcast および audiobook はやめます。
Altair という Python の可視化 API がある。このあいだ社内で紹介テックトークがあったので手持ちの SQL/Notebook 仕事で使ってみた。結構良い。Pandas の plot() はしょぼすぎるから辛くても Matplotlib を・・・みたいな機会は, 自分の SQL 仕事の範囲ならもう起こらなそう。簡潔かつ強力。
バックエンドとフロントエンドを切り離し、そのあいだは Vega という JSON ベースのフォーマットで通信する、だからクロス言語にもできるんだよ！とかいう話を昔きいたときはうげー overengineering で完成しなそうだし遅そう・・・と思って無視してたけど普通に使えました。ごめん。
ところで Altair と Vega (と Deneb) は Summer Triangle からきた命名なのだね。
日曜日。リズムを維持するため定例のコーヒー外出をしている。家にいるとダラダラしてしまうし。家事は立て直せたが、そこから先に何をするかは未だ定まらず。家事をしていると思ったほど無限に時間があるわけでもない。会社員だから当たり前だけれど、時間がるとダラダラしてしまうという事実は、自分のぱっとしなさを象徴している感じはする。
朝に早起きするのがけっこう難しい。さすがに午後まで寝てしまうとかはなく 7時半くらいには起きているけれど、睡眠時間的には 6 時に起きてもバチはあたらない。今までは人の気配で起きていたのだなと思う。
思ったことを書くのについ Twitter をしてしまう。よくない。Blog に書きます。はい。
仕事中に電話が来て、ER のときに撮った X-Ray の料金を払えという。なんかそれ先週あたりに請求書が来ていてオンラインで払ったような…。そう伝えるも、払ってないという。では bill を再送してくれというと、少額なのでだめだとか。ウェブサイトで払えるというが、仕事中で立て込んでいたのと払ったはずなのとで、その場では払わずかけ直すと伝えて切る。
さて。Bill を確認したいが捨ててしまったのただよなあ。Receipt はとってあるのだが、そこにはなんの支払いだったかが書いていない。同じ請求だと思うが…
と思いつつかかってきた電話番号をぐぐると…若干怪しい。Scam 番号判定サイトの一つが疑わしいと言っているものの、あまり決定的でもない。一方で持ち主のビジネスも見つからない。Scam かなーしかし本物で払いそびれもやだなー…。
Scam だとしたらどこから情報が漏れたのか。それこそ捨てた bill だろうか。わからん…
まあこっちからは何もせずかけ直してきたら留守電に録音してビジネスの名前を確認し、怪しくなえれば払う、くらいかなあ。
ERにかかると支払いが面倒になると学ぶ。そして bill は捨てず、せめて写真くらいはとっておく、とも。
追記。
Voice mail のキャッチに成功した。単にかかった病院が評判の悪い業者を使っていただけのようだ・・・。あとで兼ねなおして払おう。Sigh. ER かかるといいことないね。
追記。
Procrastination の果てで支払いを済ませた。前回の電話よりはマシな感じの人だった。やれやれ。反省のため confirmation number のみならず自分の account number も聞き出しておく。やれやれ。
Haircut の reservation はともかく、Bill の支払いのような本質的に必要悪だが相手も自分が嫌われ者だとわかっているものは Google Duplex みたいので自動化しても角が立たないと思うのだよなー。お店の予約とかはその後サービスをうけるのだから相手の人間性を尊重しておく動機があるが Bill の支払いなんてのは一刻も早く縁を切りたいわけだから機械ウェルカムじゃん。
留守番日記、二日目。（毎日はつけないよ。）
これは独身生活ではないよな。家が広すぎるしモノは多いし。そしてホテルでもない。自分の家族のために organize されているので。これは・・・留守番だな。若干寂しく、思ったほど心躍る感じでもない。しかし時間は時間なので活用していこうではないか。
昨日は気が散漫になってインターネットをしているうちに夜が更けてしまったので、反省して立て直しを図る。家事、一人だからやらなくていいわけではないと気づいたため朝晩週末とやることを紙に書き出して壁に貼る。家事そのものではなくやるべき家事を考えるのがストレスなので、紙に書いてあることを順番にやればよい。
食事。会社の夕食を食べようかと思ったが、夕食の提供開始が自分の定時よりだいぶ後だと気づく。そしてけっこう混んでて列が長い。暗くなってから帰るのは嫌なので帰って自炊することにする。ここ数年の訓練の結果とくに炊事に苦痛はなくなっていたのだった。自分で調味すると味覚が疲れないのもよい。会社飯、きらいじゃないけど味噌や醤油への craving を detach できていない自分。
といっても毎日自分のためだけに炊事するのは若干かったるいので来週はドカっとカレーでも作って食べ続ける所存。晩飯だけならまあ、いいでしょ。適当に野菜も食べたりして。今週は冷蔵庫の在庫処分を優先する。問題なければ来週以降も似たような感じで。
インターネットやりすぎ問題は残るため、久々に procrastination device であるところの Mono G をとりだしてセットアップした。この遅いデバイスでのみソーシャルメディアを見るものとする。
というかんじで昨日よりは留守番の姿勢が整ってきた気がする。
週末のつくりおき料理については色々具体的なアイデアが頭に浮かぶのに（カレー、ポトフ、ボロネーゼ、ゆで豚、浅漬け・・・）留守番コーディングプロジェクトについてはなんの具体性も浮かび上がらない。この 1-2 年の自分の暮らしぶりの現れなので仕方ないとはいえ、やれやれ・・・。
妻子が骨休めにと一ヶ月ほど実家に帰っていった。自由だ！と思っていたけれど、家に帰ってくると誰もいなくて奇妙な気分。もう結婚して四年以上なので家に誰もいない感覚を忘れている。家が自分のためではなく家族のためにセットアップされているにも関わらず自分しかいない、という点が特に奇妙だ。猫はいるのだが。
とか思いながらソーシャルメディアを眺めていたらあっという間に一時間たってしまった。ちゃんと計画なり思惑を持ってやることやらないとダメだな、ということでこれから考えます。ほんとは事前に考えておきたかったんだけど、ちょっと体調を崩したせいで出遅れたのだった。
さすがにずっと一人活動していると飽きそうなので、週末はともだちを捕まえて料理でもしたい。しかしこういうときに気軽に呼べる相手が案外少ないというのが今の自分なのだった。一人だけいて、よかったな、というとこです。
Podcast の編集手順を記録しておく。
前提: 二人が会議室に集まって録音している。各自マイク持参のうえミキサにつなぎ、それぞれのマイクをステレオの左右に割り振る。そのステレオ出力をUSBに変換して電話機につなぎ、録音アプリで録音。セグメントごとに別々に高音質 MP3 で保存して Google Drive にアップロードし、それを Linux laptop からダウンロードして Audible で編集し、96bps モノラルの MP3 でエクスポートして Cloud Storage にアップロードしておしまい。
編集でやること:
作業フロー:
一番時間がかかり疲れるのが通して聞きながらの編集なのだけれど、その前後も手順を決めておかないと何度も正規化したりノイズ除去したりして音質を落としたりしがち。細かい編集はあまりやりたくないのでちょっとした空白とか言いよどみはスルーしている。バースト消すのだけはサボれなくて厳しい。アルゴリズムでなんとかなりそうなものだが・・・。
Rui-san の勧めに従い Auphonic を使い始めた。ローカル版を買ったほうがいいらしいけど動かせる環境がないのでオンライン版。音量の調整とノイズ除去はコレ任せになった。空白除去などの削る作業だけ自分でやってる。
Jupyter Notebook をホストしてくれるサービス、いくつかあるので眺めている。
GPU クラウドの会社 Paperscape のサービス。
Collaborative に同時編集とかができる、というのが売り、だが、ベーシックなデザインがしょぼくて深入りする気にならず。Github アカウントの OAuth でログインし、無料枠で UI や機能を試せるのは良い。
この中だと自分には Colab が一番マシかなあ。ただ商業製品ではないので課金してそのぶん柔軟にするみたいなオプションがないのが惜しい。Gradient もいい線いってるのだがなぜか一時停止ができない。Managed Jupyter, いまのところ決定版はナシということだな。
自分でクラウドに VM を持つオプションは二年前から何か進歩があっただろうか。SOCKS 使うとかいやなんだけどやむなしなのかなー未だに・・・ Sigh.
会社だと Colab でも悪くない感じがするのはなぜだろうと考えるに、理由はふたつくらいありそう。
Cloud Storage の仲間にファイルを置くようにすれば前者は解決する、のだろうか。使っているフレームワークが対応してないとだめだな。
今のチーム, dashboard を誰が保守しているのかと思ったらつくった人はもう他所のチームに移ってしまっており、自分の隣の席の人が壊れたのをほそぼそと直していたのだった。そこで dashboard 開発を take over してみようかとコードを読んでみるとよく出来おり感心。社内のdashboard インフラを使いこなし、しかし大げさなことはせず、データパイプラインのほぼ全てが SQL で完結している。バッチの使い方とかも手堅い。Possibly privacy sensitive な raw log から aggregated なデータをつくるとか、こういうのは Java で書くものだと信じていたが SQL で足りるんだな。
LinkedIn を眺めると、その dashboard をつくった人は前の会社で何らかの analytics 業務をしていたらしい。道理で Android 開発者なのにばりばり SQL を書けるわけだ。そういえば隣の席の人も前の会社では Hadoop 的な世界でなんかやってたと言っていた。なぜこの人たちが Android のアプリを書いているのかは謎だが、それはさておき自分も若くて融通が効くうちにキャリアのどこかでデータに近づいておくんだったなあといつもの後悔が浮かび上がる。まあ 10 年前とかデータの仕事そんなになかった気がするけど。でもサーバ側をやっていれば SQL は得意になったかもね。
キャリアが若いうちは採用する側も色々甘く見てくれるため、わりと専門でない仕事をすることができる。だからたとえば自分のようにクライアントサイドばっかりの人も 2-3 年サーバサイドの修行でもするかな、と転職するのは割にあう気がする。
しかし実際にはそういう見通しで転職することを考えたこはなかった。なぜだろうね。まあ今の勤務先で長々とは働く前は小さい会社でそれなりに色々やっていたので、スキルセットの構築という点で特にまずい判断があった気はしない。大企業で長々と同じことをやるのが良くなかった、といういつもの結論にたどり着くだけだった。
を、はじめて仕事で使えた・・・。
ログを集計するなかログの種別をあらわす type の列とそのイベントの発生回数をあらわす count の列があり、そのほかに日付の列があり、イベントの種別ごとに 日付/回数 を plot したい。そこで pivot. 絵に描いたような例なので特筆すべきことは何もないのだけれど、まあ、うれしいじゃん。Java 初心者が初めて Java の generics のクラスを自分で書いた、みたいな種類の喜び。わかりますかね。わかんなくていいですが。
もともとこの作業はダッシュボード (Redash 的なやつ) の上でやっており、しかしそのツールは pivot をサポートしてないので Spreadsheet を export してそっちで続きを処理した。
が、なんかおかしいな・・・と考えるに去年は BigQuery 業務を Pandas でやっていたのを思い出した。Dashboard って定期的にモニタリングするにはいいけど探索的な作業には向かないじゃん。そういえば。データ解析ごっこ一年ぶりくらいなのですっかり忘れてたよ。
今のチームはデータのありかが BigQuery でなく内製の Dremel なため（ほぼ同じだけど） Pandas は標準でサポートしてない。 さて・・・と思ったが社内の Datalab 的なやつ（ほぼ同じ）を触ってみると Dremel Pandas がサポートされていた。よしよし。去年は手元で Jupyter を動かしていたけれど、今や Datalab 的なやつで作業できる。手元になにもいらない。めでたい。
追記: Datalab ではなくて Colab だった。
via The rationalization of publishing – Ev Williams – Medium
Medium はいよいよ subscription に本腰のようである。まあ subscription いいと思うけれど自分の blog を置くにはもはや不適。自分が書きたいのはまさに "free cheaply produced content" なわけだから。なにをもって cheap と呼ぶかはともかく、課金したいようなものではない。たぶん non-member の無料枠は残すと思うけれど、あのうっとおしい pardon dialog のことを思うとあんまし使いたくないなあ。
端的にいうと自分は誰かに話を聞いてほしいというのが主なので、その願いを叶えるために書き手として金を「払う」のはまあまあ妥当に思える。なので WordPress とかの blogging platform のほうが自分には合っているのだろうな。
読者として Medium にカネを払う価値はあるか? $5/m わからんなあ。自分が medium で読んでいるのは主に engineering blog の類で、それらは paywall されていない。そして彼らの "quality content" は読んでない。自分は NYT だけでおなかいっぱいだわ。The Atlantic と New Yorker が Medium 配下になるくらいの大変動があったら金払いそうだけどね。
View を最適化する仕事は結局よくしらべてみるとうっかりさわっている API が binder call をしているのが原因ということがわかり、それを適当にキャッシュしたりなんだりすれば大体解決したのだった。
最初は binder_driver というタグを有効にすると Systrace で binder call をトレースできることに気付かずだいぶ時間を無駄にした。しかも Systrace をみてもどの API が Systrace してるのかわからないし・・・。文字列渡して注釈してくれや・・・。まあそこは profiler を併用すればいいので致命傷ではないのだけれど、こいつらトレースを rich にしておく重要性をわかってないな、と思う。まあ八つ当たりだけれど。
３月は病気がなおって気が緩みつい Twitter をしてしまったが、大いに気が散って生産性を破壊してしまった。今月からはまあ、おとなしくています。すなわち Podcast のアナウンスだけするとしよう。思いついたバカなことを衝動的に書き捨てるのは気分がいいけれど、失われる時間には代えがたい。
Podcast へのフィードバックなどをエゴサーチするのには Warble Alerts を使っている。検索キーワードを登録すると、新しい検索結果を一日一回メールで送ってくれる。