さてちょっと時間あるから WP に金払ってドメインの設定でもするか・・・。

「法蓮草の森」は完全に思いつきの名前すぎ、あとから変えたい気もするので、ドメインはもうちょっと agnostic なかんじにしたい。しかし notes.dodgson.org は使ってしまっている。records.dodgson.org とか? notes と何が違うのかという話はあるが、違いはなくて名前の衝突を避けたいだけです。logs とかでもいいけど、log ってかんじでもないからなー。

"Domain Connection" という機能が $13 だけど paid plan ならフリーだよー、とか書いてるので、むしろ domain connection だけ売ってくれと思って調べたが、それを買うことはできないらしい・・・なんだそりゃ別に personal plan でいいんだけどさ・・・。

とか試行錯誤していたら間違えてこのブログをアップグレードするかわりに新しいブログを買ってしまった！ギャー！しかしあっさり refund できたのでよかった。この refund のしやすさは評価する。

そして Personal Plan を refund してわかったことだが、もし Personal Plan で custom domain を使っていた場合、Personal Plan をやめて Free Plan に戻っても custom domain は使いつけられるらしい。それが $13/year の Domain Connection 機能。つまりこの "plan" にアクセスするには有償プランを購入のうえ refund すればよい。Audible の退会フローでだけアクセスできる格安プランみたいなもんだな。まあこのブログをちゃんとやってるうちはふつうに金払いますよ潰れてほしくないからね・・・。Misreading Chat を完全終了する日が来たら Domain Connection に切り替えていい気はする。

はー無事金払い終了。Domain の upsell が激しすぎてかなり UX を損ねているのが残念。でも consumer 向け有料サービスというのはこうなってしまうよなあ。世の中うまい話はないのである。まあトータルのお買い得度を考えるとこのくらいの annoyance はいいです。

朝起きて顔洗ってコーヒー淹れて着替えて 4:37.

Chapter 2: Thirteen Common Mistakes In Dashboard Design

• Exceeding the Boundaries of a Single Screen.
  まあこれはわかりやすいね。なお画面を分けるのも、drill down は別にしてやめとけという主張。
• Supplying Inadequate Context for the Data
  比較すべき数字が含まれていない（平均、目標など）。良い悪いだけでなく、どのくらい良い・悪いのかがわからないとだめ。
• Displaying Excessive Detail o Precision
  逆に細かすぎる、みたいなの。ビジュアルが伴わない場合はなおさらそうだよな。というか table はイマイチな気がするな。自分の dashboard もちょっと table を混ぜちゃってるけど、あれは細部として切り離したほうがよさげ。
• Expressing Measures Indirectly
  伝えたいことが伝わらない指標を使っている。例では予実の時系列チャートを挙げており、予実の額自体をプロットするのをダメとしている。かわりに予算を定数とし、予算に対する実際の出費の % をプロットしたほうが良いとしている。予算超過しているかどうかがわかりやすいから。なるほど。なお仕事ではもっとあからさまにダメな indirect measure が問題になったことがある。それは直したけど、他にもこういうのありそう。"Indirect" という語彙があると指標を殺したいときの説得には役立つげ。
• Choosing Inappropriate Display Media
  Bar chart はやめておけ、まして 3D は最悪だ。あと二種類くらいダメなチャートが乗っており、かつ後の章でも詳しくやるらしい。仕事、社内ベータユーザの OS ビルドの分布を pie chart で出しちゃってるけど、だめかな・・・。エントリが多いと bar chart はかさばるのだよなあ・・・。後の章に期待。
• Introducing Meaningless Variety
  無意味に使う chart の種類を増やすのはやめなさい、boring とか気にしないで consistency 大事にしなさい、という話。
• Using Poorly Designed Display Media
  単一のチャートのダメさについて、いくつか例を示しながら議論している。詳しくは Show Me thee Numbers という別の本を読んでねとのこと。はい
• Encoding Quantitative Data Inaccurately
  グラフはゼロベースにしろよなとか。はい。
• Arranging Information Poorly
  重要な数字は prominent に、注意すべき数字は stand out させ、比較すべきものは隣に置く。
• Highlighting Important Information Ineffectively or Not at All
  後の章で詳しくやるよ。
• Cluttering the Display with Visual Effects
  謎の装飾はやめろ、みたいなの。これは自分にはさすがに関係ないが, vendor がつくる昔ながらの dashboard ではたしかによくあったかもしれない。例示される screenshot が厳しい。
• Misusing or Overusing Color
  無駄に関心を引く色を使っちゃうとか。こういうの dashboarding tool がデフォルトの palette をまともにしてくれればいいんだけど、なんか無駄に赤とか入れてくるよな・・・。その点モダンなチャーティングライブラリはえらい。
• Designing an Unattractive Visual Display
  過剰な装飾はダメとはいえ ugly すぎるののも困るから aesthetics も気にしような、あとの章で教えてやるかんな、という話。はい。

今や自明なものもあるし、なるほどというものもあるし、よくわからんから後の章に期待というものもある。コンテクストの不足、情報の過剰、Arrangement の工夫、一画面に収める、とかはできてないときもあるので次からはちゃんとやりましょう自分。

Chapter 3: Assessing What's Needed

• 要件定義ちゃんとしような、という章。
• Begin With a Definition
  "It is an information display that will keep them aware of what's going on in their specific realm of concerns". EDA とかのツールじゃないからね、という話。
• Focus on the Goals, Not on the Means
  エンドユーザからの fancy にして欲しいという要望は無視し、彼らの必要とするものを作ってあげなさいね、という話。はいはい。
• Get into People's Heads
  Dashboard を読む人のメンタルモデルに沿って画面をデザインしてあげようね、読み手のメンタルモデルをインタビューするときはホワイトボードに図を描いてもらって、いろいろ質問しながら図に矢印とかを書き足してもらおうね、初心者はそもそもメンタルモデルがないときもあるから育ててあげようね。という話。
• 最後は余計なお世話というか出過ぎた主張だと思うが、Dashboard はさておきメンタルモデルや問題意識の共有というのは必要で、しかし自分はしばしばさぼりがちである。PM とかこういうの話し合うの好きで、話が長くなって仕事が進まないのでイヤだなーといつも思っているが、数字を中心とした design doc 的なものを書いてそれを dashboard という形で実装する、というフローは必要なのだろうなあ。business objective の定義みたいな。まあ business ってほどじゃない性能上の指標なんだけど。
• Ask the Right Questions
  • Dashboard の更新頻度は?
  • 誰が読むの?
  • 何をモニタするの? なんの目的で?
  • どういう疑問にこたえたいの?
  • Dashboard をみてどんなアクションをとりたいの?
  • 具体的に表示したい項目は? それぞれ何がわかるの? 詳細が必要なのサマリが必要なの?
  • 目的のために一番重要なのはそのうちどの数字なの?
  • どういう logical grouping があるの? 各数字はどの group なの?
  • どの数字とどの数字を比べたいの? 互いにコンテクストを提供できる数字たちはどれ?
• このリストは comprehensive ではないといってるが、良いリストだね。耳が痛い。Dashboard design doc があるとしたらこういう質問には答えてしかるべきだな。作ってみないとわからないものもありそうだけど。
• Identify Information that Really Matters
  上の質問リストに出てきた数字のうち、実際に性能に影響を与えるものだけを dashboard に含めなさい。人々は実際には使わない数字を念のためと入れたがるけど、空間や関心を無駄遣いするのでやめなさい。入れたがり屋さんには「あんたその数字をみてどう行動するわけ？」と聞きなさい。そうですねー。EDA してた名残でなんとなく入れちゃうチャートとか、割とあるよね。
• Identify Useful context for Measures
  それぞれの数字を読むにあたって役立つ context が何か identify しなさい。たとえば "targets, standards, measures of the norm, or the past data." - "Compared to What?" - これ全くその通りだけど一方で内製の dashboarding tool はチャートにこういう情報を埋め込む支援が全くない、というか不可能。Altair も支援といえるものはないけど、コードを書けば任意の線を埋め込めるのでなんとかなる。むしろ dashboarding tool 側ではなくそいつの参照する SQL の側にこういう指標を埋め込んで、可視化用のデータを生成を生成すべきなのだろうな。

短いがなかなか有用な章だった。読書はここまで。

The Food Lab: Better Home Cooking Through Science

夜は眠くてやる気なくても読める本を寝る前にちょっとだけ読むことが多い。その記録もつけてみる試み。

Chapter 2: Soups, Stews, and the Science of Stock

• Collagen/Gelatin は connective tissue である。legs, wing, back and skin に豊富。
• Meat only stock -> flavor. Bone only stock -> body. Carcasses -> Both
• carcasses は food processor で砕いたのちに simmer する。Flavor が短時間 (45min) でよく出る。Gelatin は摘出されないがそれは市販の gelatin を足せばよい。

Stolte: Polaris: A system for query, analysis, and… - Google Scholar

久々に出社し、タダで使えるプリンタがあるのを思い出したので星空日記で積み残していた Tableau の元となった論文を読む。

• RDB に入っているデータを引っこ抜いてチャートを描く GUI を作りましたよ。Grammar of Graphics にインスパイヤされた可視化を GUI でチョイチョイと作れますよ。指定された可視化仕様に基づき SQL をつくって RDB から引っこ抜いてきますよ。
• という内容で、完成されている。Tableau... はさわったことないけど社内のダッシュボードツール(Data Studio を武骨にしたようなもの)はこれをしょぼくしたものという風情。2002 年でこの完成度。そりゃ Tableau 流行るわけだわ。
• データや代数のモデルを RDB/SQL に寄せてあるのが GoG との違いだと書いてあるが、20 年後に振り返ると成功している。もちろん ggplot2 路線にはそっちなりの良さもあるんだけど、GUI で画面を作るに際して UI の操作を通じて結果の可視化を軸に SQL を組み立てるアイデアがエレガントかつ正しいバランスをヒットしていて見事。
• このあと WU とかから出てきた研究でここまで「やるな！」感がある論文は星空日記では発見できなかった。つまり一族の親分たる Patrick Hanrahan はすごかったね。

しかしその後の Tableau の発展はアカデミアに還元されることはなかったのだった・・・と書こうと思ったら Tableau Research というのがあり、論文わりと面白そうじゃないですか。タイトルで選んで記録:

• Towards a Theory of Bullshit Visualization
• What Do We Talk About When We Talk About Dashboards?
• Looks Good To Me: Visualizations As Sanity Checks
• In Pursuit of Error: A Survey of Uncertainty Visualization Evaluation
• Reflecting on the Design Criteria for Explanatory Visualizations
• Whisper, Don't Scream: Grids and Transparency
• Technical perspective Finding and telling stories with data.
• Voyager: Exploratory Analysis via Faceted Browsing of Visualization Recommendations

可視化は自分の関心が高まってるせいもあってどの論文も面白そうでよい。

あと Polaris の被引用リストを見ていたら The Grammar Of Graphics の論文バージョン 2012 を発見したので、書籍 Grammar Of Graphics じゃなくてこっちを読もうかな。

夢。仕事帰り、広尾の築四十年家賃七万円のアパート、屋外の小汚い共用洗濯機で隣人と雑談しつつ服を洗いながら、そろそろ親も年だし実家の近くに引っ越して、家賃ももうちょっと金かけて小ぎれいなところに住むかなどと考える。その汚い洗濯機を使うなコインランドリーにしておけ！と動揺して目が覚める。隣人との雑談がなぜか英語である。そしてあのアパート、洗濯機は自分で持ち込んだ気がするな。

さてブログを公開しないと。

一目にさらすのが憚られるエントリをドラフトに戻し、ドラフトのうち今みると別に公開してもいいかと思えるものを公開に切り替え、気づいた範囲でタイポを直し、git commit -u && git push. Netflity の設定が死んでいなければ公開されることでしょう。Netlify にしてあるよね？なんかいろいろ mess なのだよな・・・と Netflity の dashboard を見たところ、ファイル名不正とかで失敗していた。修正。

はい、無事公開されました。よかったね: steps to phantasien

というわけで code-server を動かしていた VM も停止。

はーこれで "steps to phantasien" というブログも終了。この名前はもはや四半世紀くらい使っているはずだな・・・と Web Archive を確認すると・・・。あった！中二病が痛すぎてリンクをするのに躊躇するが、この URL を思い出すのに一分くらいかかったので記憶から消え去る前に記録しておく。それにしても 20 世紀からブログ（という名前ではなかったが）書いてるとかすごくね？お前が東村山で書いてるそのウェブサイトは 23 年後に Mountain View で終わるぞ。黒歴史になりそうなとこは消しとけ、と教えてあげたい。

さて活動記録をつけるにあたりやりたいことや読みたい本を整理するとか Notion を再セットアップするとかをやりたい気もするが、そういうメタ活動に時間を使いすぎるのもアンチパターン感があるので、適当に積読から一冊選んで読み始めます。

Information Dashboard Design: The Effective Visual Communication of Data - 仕事で dashboard を作る機会が増えたものの、それらの dashboard が良いとは思えない（良し悪しの判断すらできない）という足元の覚束なさから買ったまま積んでいた本。

Chapter 1: Clarifying The Vision

• 世の中の dashboard のダメさ。物理的な "dashboard" の skeuomorphism はゴミという話。へー昔はそういう dashboards がいろいろあったのだねー・・・。
• Vendor が製品を fancy にみせるためにつけた pre-defined な dashboard のダメさ。へー(同上)。
• 歴史。90 年代に OLAP や BI がもてはやされ始め、ゼロ年代初頭に Enron のスキャンダルがあってビジネスにおける監視の重要性が見直され花開いたという話。それとは別に工場とかの機器が電子化・ネットワーク化されて画面がつき、その監視のためにエンジニアが考えたゴミのような監視 UI がつくようになった。はあ。
• Dashboard とは何か:

A dashboard is a visual display of the most important information needed to achieve one or more objectives, consolidated and arranged on a single screen so the information can be monitored at a glance.

P.26

• スクロールが必要なものはもはや "a dashboard" ではない。一目みてわからないから。
• Dashboard は用途に応じてカスタマイズするのが大前提である。つまりインフラチームとかが作ってくれているお決まりの可視化ツールは、カスタマイズの支援の程度によってはゴミ化する可能性がある。
• Dashboard は以下のものではない:

- A display that is used for data exploration and analysis
- A portal
- A scorecard
- A report that people use to look up specific facts

p.30

• なるほど...
  • EDA を混ぜがち、というは自分の感じていたすわりの悪さを説明している。
  • Portal を混ぜがち（なせいでちゃんとした Portal がない) という問題も同じ。
  • Scorecard は一緒なのでは、と思ったが、そっちには決まったやり方というのがあるらしい。

• Dashboard は "Situation Awareness" を高める。つまり alert が発生する前からなんとなく全体の状況を把握するのを助ける。のでいざ alert が発生しても慌てなくて済む。
• Situation Awareness を update する -> 注意の必要なものがあるか判断する -> あれば詳しく見て、対処の必要性を判断する -> 対処するならする。
• Dashboard は "need to leverage people's visual capabilities" ということで次章につづく。

今日はここまで。読書は椅子に座ってやるよりタンスとかの上に本を置いてストレッチとかしながら読むほうが眠くらななくてよいね。

今日は weekly review という名の雑用の日です。Weekly Review のテンプレを Notion に移行しなければ・・・とおもったがそういうことをしてると作業が進まないので何はともあれ家計簿でもやりますわ。はい。

ところで WP.com は xxx.wordpress.com の XXX が選べなくなって、いよいよ実質上有料といった風情。別にいいけど、時代だねえ変えられた。日本のブログサービスは滅茶滅茶いろいろあって、よく続いてるよなあ。ブログ大国といってよいのではないか。一方日本語で「ブログ」で検索して出てきたサービス紹介のブログ記事は Medium は載ってないし(まあそれはいい) WP の紹介は間違ってるしで、ブログというものの現状をよく表している気がする。

Disnesy+, 1-2 本みればだいたい元が取れるが、最近ほんとにスクリーンを見な過ぎてこれですら元が取れていない・・・。

Todoist に「日本語のサイエンスっぽい本を探す」（子向け）というタスク。自然科学ね。図鑑だとモノは列挙されているがいまいち説明がないのでは…というような話をしていたのだった。しかし図鑑いまいち説が事実なのかをまず確かめようではないか。図鑑に迷ったら！図鑑最新情報＆おすすめ100選！ | 絵本ナビスタイル とか見る限りでは事実な気がする。

「植物」というカテゴリに絞った時点で図鑑になってしまう？もっと生物の読みものとかで探すほうがいいのではないか。それとは別に図鑑もあっていいと思うけど、日本語だと日本の植物の図鑑になってしまうのがなあ。それ生えてねーっつーの（言いがかり）。植物図鑑は英語でよくないですかね・・・。

といったところで 1-2 冊リストに追加のち時間切れ。書店にアクセスできない厳しさ。

というわけで Blog を Hugo から WP に移行中。移行といっても仕切り直しなので特にコンテンツの移動とかはなし。かわりにドラフトという名目で公開をさぼり続けている Hugo のブログを公開する作業をします。

今はドラフトの repo を公開用からフォークして書いている。理論上これをマージすればよい。ということでやってくぞ。しかし Ubuntu から Windows に来て以来なにも開発的な設定をしていないので、それも並行してやらねばならず、だるい。

作業予定 (TODO: Notion に移動する)

• anemone.dodgson.org にドラフトをマージして中身を確認
• anemone.dodgson.org を公開 (push)
• ドラフトを書くのに使っていた code-server の VM を停止。(削除はいずれやる。)

WSL に Hugo が入ってない（入ってるわけない。）いれます。

マージは no conflict で成功。最後の終了のアナウンスを書き、眠いのは今日はここまで。明日は push をします。

リンク記録

• credentials - How can I save username and password in Git? - Stack Overflow

長いことブログというものを表立って書いていなかった。なにもインターネットに存在感がないのは寂しいのでまた書いてみる。

人々に言いたいことは今のところ特にないので、かわりにしばらくは自分が余暇の時間にやっている読んだり書いたりの活動を記録していこうと思う。森田が報告・連絡・相談するので法蓮草の森。連絡と相談はたぶんしないけど、語呂優先です。

Hugo を使ったこのブログ、2015 から更新しているようなしていないような状態のまま使っているけれど、 そろそろ引退させようとおもい作業をしている。

ブログとかを書いていると虚栄心などで気が散り精神衛生を損ねたりするという理由でブログの公開を年一回にしたのが 2016 年。 その後、子ができて忙しくなったりで段々と公開するのがめんどくさくなり、そもそも書くのもめんどくさくなり、書くこともなくなり、読む人もいなくなり、と荒廃が進んで今日に至っている。

友人向けに管をまく雑談はぼちぼち書いており、そういうのはパスワードで保護されたドラフトサイトでだけ公開し、ドラフトのままにしている。 そのほか自分にだけ読める braindump や走り書きなども少しあり、そういうのは draft サイトにすら表示されない特殊な状態で、localhost のプレビューでのみ読めるようになっている。

公開にあたってドラフトのうち衆目にさらしてもよさそうなものを cherrypick しようとしたが、ほとんどない。 愚痴とか気の迷いの謎の活動とかが多くてあまりにしょうもない。このブログ最後の更新は、ほんとに何も読むべきものはない。 まあ家事子守疫病とかで忙しいかったのだよね。他人のためになんか文章を書くとか、そんな余裕はゼロ。

なおこのブログを閉じるのは別にブログというものをやめたいというわけではなく、 むしろ今後はふつうにリアルタイムでどうでもいい日記的なのをどこかのブログに書こうかなと思っている。 この anemone.dodgson.org を終了するのは、単に区切り目というだけ。

時が流れ、加齢とライフステージの変化にともない虚栄心とかがなくなったのでリアルタイムにブログを書くくらいは問題ない、 というのはうそで、最近はガチで他人に自慢できる要素が自分の人生から消え去ったので虚栄しようがなくなった。 自分がぼんくらおっさんであることを隠す意欲すらないので、逆に息抜き・社交として日記とかを書く気が起きたかんじ。

行先の URL はまだ決まってないので、きまったらまたここに書きます。

WSL2 のビデオを見る。

• Hyper-V based な VM らしい。ただしかなり para よりで、Microsoft が改造したカーネルが必要。
• ということは、WSL2 用の Ubuntu とかは Microsoft と Canonical が協力してこの専用カーネルを同梱した特製 Ubuntu を作ってくれているということである。Vanilla Ubuntu ではない。Cloud 向けの distro images と似たような感じか。
• カーネルが upstream じゃないのがどのくらい不安か考える。主要な不安: WSL は新しい Ubuntu のバージョンとかにきちんと追従できるのか。
  • Ubuntu にしたって vanilla kernel じゃなくて多少はパッチが当たっているわけだが backport が基本で、vanilla kernel を入れても動く。だから Ubuntu は別に MS patch に更なる変更をする必要はない。
  • Android とかは、最近は upstream を重視しているとはいえかなり激しくパッチが当たっている。Vanilla kernel は動かない。一方で Android は Ubuntu とかの distro を動かす必要はないので、kernel のバージョンが遅れ気味なのはそれほど致命的ではない。
  • つまり Ubuntu あるバージョンが新しめの kernel を必要としているとき, Microsoft が彼らの fork をきちんと rebase する、かつ Canonical と協力してそれを WSL2 向けにパッケージしてくれると、はじめて WSL2 で新しい Ubuntu が使える。どのくらい delay があるだろうね。半年くらいかな。22.04 を見ればわかることでしょう。
• そのほかの不安: GUI 対応
  • Video subsystem は仮想化していないので、画面がない。
  • かわりに X/Wayland server を実装する的な方向らしい。これはいばらの道っぽい感じもするが、一方で GUI で使いたいものなんてそんなにないような気もする。Android Studio とかの IDE くらいか。なので、GUI が無いなら無いで諦めはつくかな。
• Crostini と比べてみる。
  • WSL2 の体験は Crostini よりはだいぶ良いが、それは terminal がよくできてるとかブラウザ外での UX が Windows の方がこなれている(当然)からだと思う。
  • Crostini は WSL より para 度が低い、より普通の VM である。 Crostini は LXC という業界標準技術で VM の中にコンテナを作っている。LXC が何なのかよくわからないが、これで動く OS のイメージは canonical が host しているものが使えるらしい。official image ではないとはいえ、Microsoft 改造 distro ほど乖離してはいなそうだし、そもそも VM ベンダに依存していないのがよい。
  • 一方で性能は WSL2 の方が出そうな雰囲気。これは para の力とみることもできるし、VM 基盤 (Hyper-V vs Crostini) のやる気の違いともいえる. Crostini とかね、趣味 プロジェクトにしか見えないじゃん…
• つまり WSL2 は vanilla VM と比べると para の力で性能や体験をチューンしつつ para の弱点はカネの力でなんとかしようとしている。

ただ ps とか top とかしてみると普通の Ubuntu と全然違うよね。プロセスが 10 個くらいしかない。daemon 類が完全に不在。このおかげで “shell を抜けた瞬間に VM を終了する” という “lightweight vm” が実現できているわけだが、一方でこんなにプロセスなくていいの? という疑問はある。たとえば SSH とかできないよね。自動化との相性は悪い。あと普通の Ubuntu (Cllient/Server) からの乖離はカーネルだけでなく、割とでかそうだな。

WSL2 でできないことはなにか:

• 新しい/マイナーな distro を入れて遊ぶ. まあ、過去の実績からして杞憂だね. Ubuntu の LTS しか使ってない.
• カーネルいじってあそぶ. これも杞憂系だが、やるにしても WSL の外でやる方がよいだろうね…
• daemon 的に headless でなにかを動かす (ex. code-server, jupyter notebook). これができないのは微妙ではあるが…ただ Jupyter 動かないとかは考えづらいので、試してみた方がよさそうだな。

将来 WSL2 / Windows を使いたくなくなるシナリオはどんなものか:

• Microsoft が再び世界征服を果たし, WSL のやる気を失う. これはなさそうだな. 別に現状でも desktop/laptop のシェア的には世界征服済なわけで.
• Chrome へのいやがらせが加速して使い物にならなくなる. これはかすかに不安を感じるが, Edge を使いましょうということで. 仕事の Chromebook とアカウントが乖離するのは便だが.
• 上にあげたような何らかの limitation に遭遇する. これはなんだかんだで一番心配, ただこれを解決しようとおもったらおそらく Mac でもだめで, Linux laptop 一択になってしまうねえ.
• そういえば Rebuild.fm に出るときは Mac が必要だが… まあもう呼ばれることもないでしょう.

といった点を踏まえ、自分は WSL2 にどこまで魂をゆだねていいのだろうか。つまり次に買う laptop は Linux が動くものにすべきなのか Macbook がいいのか Windows-only か。

• Linux laptop は…もういやだな、という気持ちがある。
  • 選択肢が少なすぎる.
  • 周辺機器が基本的には動かない。Podcast 撮るとか不安。
  • バッテリーが持たない.
  • GPU もへぼい.
  • GUI は大体もっさりである.
  • アプリも全然ないし, あっても出来が悪い.
  • とはいえコードを書くには最強.
• Macbook もなあ…
  • M1 以降, 気軽に使える VM (VirtualBox) がなくなってしまった. Parallels みたいに有償でゴツイのしかない.
  • コマンドライン環境は, あるにはあるが Linux ではない微妙さがある. Docker とかめんどくさそう. ARM 故のめんどくささが重なる.
    • しかもバージョンを重ねるごとに締め付けが厳しくなっているように見える.
    • 一方でファイルシステムは GUI の世界とネイティブにつながってるので便利ではある.
  • バッテリーの持ちと性能は圧倒的に良さそう.
  • デバイスの選択肢はそんなにないが、その選択肢は世界で一番売れてるラインナップなので問題なし.
• Windows は…
  • WSL2 は Linux でよい. 手軽な VM のない Mac に比べるとだいぶマシな雰囲気.
  • デバイスの選択肢がいろいろある.
  • 動作は, ビルドとかは Mac より遅いかもしれないが体感できる UI の速さは問題を感じない. (vs. Linux のなんでももっさりな GUI)
  • WSL2 の外でのコマンドラインは自分のリテラシ的に論外. PowerShell とか覚える気にならないし, ネイティブに Unix 系ツールがない.
    • これは日常のプログラミングを不自由にしそうだが、どうかな? そういうのは WSL2 の中でやればよい気もする.

結局のところ、自分はそんなに家でコード書かないし、Linux べったりに暮らしていないのだよね。 課外活動でコードを書く friction を最小化するために Linux laptop を使っているが、それを生かせていない。 一方で Linux laptop の不自由さは毎日被害を被っている。

などを踏まえ Linux laptop はやめて、かつ自分の中二病を発揮するなら Mac もナシで、次は Windows だな、という気分。 まあ laptop を買うというような大きな決断をする前に手持ちの laptop に Windows をインストールの上いろいろやってみて大丈夫さを確認するのがよいのだろうな.

ついでに WSL2 / Hyper-V の論文とかどっかにないかなと思い軽く探したけど見当たらず。残念。

来月から出勤が確定した。一方で月曜と金曜は家から働けるらしい。 出社はしなくていいならしたくないので月金は自宅勤務にしたいが、家と会社の両方に環境を作るのが億劫。

いま自宅では Cloud の Linux と Chromebox の組み合わせがメインで、たまに Chromebook でキッチンとかからテキストを書いたりしている。 これまでの出勤ではその Chromebook を持参の上モニタを繋いで Cloud の Linux workstation と併用していたが、これは毎日だとイマイチ。 デバイスをぶら下げるのに hub が必要だし、ミーティングとかでモニタを外すとウィンドウのレイアウトが崩壊してしまうから。

会社には COVID 前から使っていた Linux のでかい workstation がある。仕事中はこいつをメインにして、 家からはこの workstation にリモートで入るというオプションもある。 ただ謎のセキュリティの制限によりリモートとローカルの両方から使うのは色々とバーが設けられており、だいぶやりづらい。

といった様々な組み合わせを列挙して pros/cons を検討しようではないか。

• Chromebox+CloudLinux(+Chromebok) at Home, CloudLinux+Chromebook at Office
  • Pros: 会社でもブラウザ環境を Chrome OS にできる (vs. Linux のかったるさ)
  • Cons: Chromebook のポートの少なさ, モニタを着脱した際のウィンドウレイアウト崩壊のかったるさ, 外部モニタにつないだ際のぎこちなさ
• Chromebox+CloudLinux(+Chromebok) at Home, Linux Workstation (+Chromebook) at Office
  • Pros: 勝手知ったる親しみやすさ
  • Cons: Home/Office 環境の乖離. shell の履歴や手元の WIP commits (Android) を持ち越せない.
• Chromebox+Remote Linux Workstation(+Chromebook) at Home, Linux Workstation (+Chromebook) at Office
  • Pros: Office/Home ともに比較的親しみ深い構成
  • Cons: セキュリティによる Remote/Local 同時利用制限が不便 (IDE Windows などは殺されてしまう)

金の力で会社用 Chromebox を購入すると

• Chromebox1+CloudLinux(or Linux Workstation)(+Chromebook) at Home, Chromebox2+CloudLinux(or Linux Workstation)(+Chromebook) a Office

という構成になり最強なのだが, 自腹は遠慮願いたいなあ。それなりに速い Chromebox が欲しいけど、高いからね。$900 くらいする…

Linux Workstation を手放して Chromebox と交換するという手もあるらしいが

• 手元で動く Linux がなくなってしまうのはデバイスのデバッグなどで若干不安
• そもそもハードウェアサポート部門は Return-To-Office の対応に追われておりこの手の手続は停止中らしい

といった理由で今はできない。といった点を鑑みるに:

• Chromebox+Remote Linux Workstation(+Chromebook) at Home, Linux Workstation (+Chromebook) at Office

が無難なのだろうな。会社でも手元を ChromeOS にするほうが Linux より色々と面倒が少ないんだけど、まあ贅沢は言うまいよ。 そもそも自宅の Chromebox だって COVID のドサクサで買ってもらったものだしなあ。

しかし ChromeOS と Linux を行ったり来たりするのはかったるいなー…

• Chromebox+CloudLinux(+Chromebok) at Home, CluodLinux+Chromebook at Office

あるいは

• Chromebox+Remote Linux Workstation(+Chromebok) at Home, Remote Linux Workstation+Chromebook at Office

にしつつ, 会社で　Chromebook を使うときは laptop ではなく external keyboard を使うのはどうか。 それにあわせてキーボードとマウスを挿す USB hub を買い、会社においておく。Hub とケーブルは持ち歩かない。

ついでに、家には laptop を持ち帰らず会社においておく…と思ったが podcast とかこれがないと撮れないね。 そういう趣味的活動に使える Linux じゃない私物 laptop が必要だな・・・まあしばらくは持ち歩きます。はい。

そしてミーティングには laptop を持っていかない！これだ！いやだめだなさすがに・・・。 でもミーティングは自席から出るのはどうか。1:1 はさておき、 参加者が remote なミーティングは自分は会議室行くひつようないじゃん？ 臨席の人々には迷惑だが、オフィス復帰後は極度の会議室不足が予測されるので 自席からのミーティング参加は cultural norm になるんじゃないかな・・・だめ？ リモートの人と会議室から話すのマジ意味ないよね。 とにかく laptop の持ち運びは最小限にしたい所存。

あとはゴミのようなどうでもいい Chromebook を一台なんとかして入手する、という路線もありうるが・・・ しかるべき場所にいけば転がってるんだろうけど、思い当たる節はないのであった。

というわけで USB Hub を購入。

そのほか security key が mess だったのを整理し、 通勤随伴電話機の台数も限定し、よしよし。 というか電話機は家じゃなくて会社においておくほうが邪魔じゃなくていいな。 次回持っていこう。

などといいつつ段ボールを物色していたら XPS 13 が出てきた! こいつに Windows を入れれば 家の podcast 問題等は解決し laptop 持ち歩きの必要はなくなるんじゃないか？ あとで Windows のライセンスでも買おうかな。 $200 もするけど laptop 買うよりは安い。

などとばたばたしつつ、次回出社は明後日木曜日です。はあ。

今の仕事はやることがいくらでもあり、むしろ自分のスループットが全然足りておらず、総体としてそれはいいことだと思っている。やることと言っても必ずしもバグ直すみたいのばかりでもなく(バグも無限にあるが)、たとえば Kotlin 移行とかね。そういう感じ。まあ Kotlin 移行はリストの4番目くらいなのでできる気はしないけど。(さすがに他の誰かが先にやると思う。)

仕事がたくさんあると感じられるのは、それがデスマでない限り良い兆候である。仕事、特定の製品とか、の課題と、ある程度の解決への道筋を、自分が理解できているシグナルだから。

これは必ずしも自明でない。たとえば自分が下っ端すぎたり上司が micromanage だったりすると、自分の問題意識とは無関係に仕事が降ってきて、それは「やること」というより「やらされること」がいっぱいある状態といえる。そういうのは、自分の勤務先ではあんましない気がする(あるが、だいたいみんな逃げ出してしまう)。

勤務先で伝統的によくあるのは、製品が成熟しすぎていてほんとに何もすることがないケース。細かいバグ直しくらいしかない、みたいな。今は知らないが、自分がいたころのブラウザとかは、割とそんな感じだった。すると人々は頑張ってやることを考える。純朴だった頃の自分はその過剰さがイノベーションの鍵だと思っていたし、今でも一定程度そうだと思うが、実際には要らない機能や複雑なデザインを生み出す悪影響もあったと思う。

まあ組織としての良し悪しはさておき、自分にはそういう成熟・資源過剰状態は向いてなかったね。イノベーティブなプロジェクトを生み出せる力がなかったから。下手にイノベろうとして負債を生み出したり、人のイノベに乗っかろうとして痛い目を見たりした。

今の仕事は特にがんばってイノベる必要がなく、それどうみてもダメですよね直さないと、みたいのが色々ある、のみならず次々出てくる。これは(しばらくするとボスも気づいてなんとかしろと言ってきたりするので)ウンザリな面もあるが、無理してイノベらず明らかな課題を解くだけで成果になるのは良い。優先度だけ気を付ければ良い。

明らかにやるべきこと、すなわち明らかなダメさが沢山ある製品大丈夫なの、という不安はある。ただすくなくとも product-market fit みたいのは心配しなくていいわけで(そりゃスマホのカメラいるでしょ、みたいな)、あとは競合をなんとかすればよい。

競合は心配だしそんなに楽観もしていないけれど少しは希望が持てるのは、結局はリサーチ部門の神成果のおかげなのだろうな。彼らが無茶で過剰なイノベをして、それをなんとかエンドユーザの手に届けるのを手伝うのがアプリチーム。そういう役割分担。自分が誰かのイノベに乗っかっていることに変わりはない。ただそれが自分個人の小細工でなく組織のデザインである点が異なる。

あとはイノベの質だな。実際だめなイノベも沢山やってきて、そういう連中の相手はウンザリ。が、今のところはなんとかイノベ黒字に見える。エラそうだな自分。

自らイノベを生み出す厳しさに向き合わなくていいのか？向き合えたほうがいいんだろうけど、成熟製品の中で歪んだイノベに関わるのは嫌だし、すると会社を辞めた方が良いのではという話になり、それは諦めている。

この諦めを受け入れるなら、今の「他人のイノベの組織的なお手伝い」という立場はそんなに悪くないのだろう。そして将来チームを選ぶ際はイノベが黒字っぽいチーム、製品が良いといえる。これは「上手く行ってる製品」とほぼ同義な気もするが…。

同じ諦めの眼差しで、成熟製品部門にいた昔の自分のぱっとしなさを振り返る。あれは自分でイノベろうとしてうまく行かなかった挑戦と失敗の帰結であって、責めるようなものじゃ無いかもしれない。事後的に見れば無茶だったとわかるが、当時はそういうのもアリという空気があったのよ、てね。