Altair のコードなどを読む日記。

Vega Research Reading List

• A Tour through the Visualization Zoo 2010
• How Vega Works / Vega / Observable
• Prefuse: A Toolkit for Interactive Information Visualization 2005
• Protovis: A Graphical Toolkit for Visualization 2009
• Declarative Language Design for Interactive Visualization 2010
• D3: Data-Driven Documents 2011
• Declarative Interaction Design for Data Visualization 2014
• Reactive Vega 2016
• Vega-Lite 2017
• Communicating with Interactive Articles 2020
• ] Critical Reflections on Visualization Authoring Systems

Stretch

• Stolte: Polaris: A system for query, analysis, and… - Google Scholar
• A layered grammar of graphics
• Blackwell: Cognitive dimensions of notations: Design… - Google Scholar

Authorization Tools

• Charticulator: Interactive Construction of Bespoke Chart Layouts - Microsoft Research cs.umd.edu/papers/DataIllustratorCHI18.pdf)
• Lyra 2: Designing Interactive Visualizations by Demonstration | MIT Visualization Group
• [Data Illustrator: Augmenting Vector Design Tools withLazy Data Binding for Expressive Visualization Authoring](http://data-illustrator.

2021/12/01 #1

• とりあえずチェックアウトしたら 論文 が入っていたのでそれを眺める。
• わかったこと: Altair のコードは Vega-Lite の JSON Schema から生成されている。そして Vega-Lite の JSON は Vega の JSON に変換され、例週的には D3.js でレンダリングされる・・・らしい。ほんとに？ Vega-Lite はいいとして D3.js はデフォルト(非対話モード)では使われない気がするけどな。Canvas に書いているような。Altair のコードは早めに切り上げて Vega-Lite のコードをよむのが正しげ。

ではコードを眺めましょう・・・

• コード生成をしているのは altair/generate_schema_wrapper.py at master · altair-viz/altair. Vega と Vega-Lite と両方の schema を使っている。つまり Vega-Lite は独立した schema ではなくて、Vega の拡張というかんじなのかね。それは schema を読めば明らかに成ることだが・・・。
• 生成されるのは このへんのファイル
• 実質的に面白いのは utils/ とかで、ここには Vega-Lite の JSON をラップして JS でレンダリングする HTML を吐くコードがある。興味深いのは Colab 対応のコードが入っていること。(display.py)。しかしこれを enable する様子がない。Colab 側で対処されているのだろうか。Colab を検出するコードがあるなら見たかったんだけど。
• 必要な NPM のライブラリは vega, vega-lib, vega-lite, vega-embed. これらはみな https://github.com/vega で開発されている。
• というわけで Altair は Vega-Lite なりなんなりの JSON を作ってくれるのだよ！以上。Altair は JSON-Schema の generation だったのだねえ。JSON つくるところは見てないけど、まあ大したことないと思うのでいいです。

というわけで Vega および Vega-Lite を眺める。まずは Schema から。

• Specification | Vega
• Vega-Lite View Specification | Vega-Lite

巨大だなー・・・・。といったところで今日はここまで。

2021/12/02 #2

• Vega 関係の論文を眺めるが・・・Research Publications | Vega
  • Vega そのものはないのだね。あってもバチはあたらないと思うが、新規性はないのかもしれない。Vega-Lite は昔読んだので割愛。
• ではドキュメンテーションを見ましょうか。 手始めのチュートリアルは・・・めっちゃ対話的だな。SVG か。 これはほんとに D3 based なのだろうなあ。
• この documentation によると vega-cli というツールでブラウザなしに PNG を作れるらしい。Altair も　Selenium 依存とかやめてこっち使えばいいのに・・・はさておき、canvas に書くらしい。D3 わかってないけど canvas に描けるんだっけ？これはコードを見るべきだな。
• Repo の説明をよむと・・・なんかめちゃ reactive っぽい雰囲気だなー。しかも JSON の input の他に “data flow description” なる中間状態があり、それが最後は scenegraph になるらしい。
• コードよりは Schema をよむほうが自分の役には立ちそうなので、ドキュメントをよむ。
• それすらでかすぎるのでおとなしく チュートリアル からはじめます・・・。ようやく Altair で見覚えのある雰囲気になってきた。
• そしてもういいかな、という気分になってきた・・・。自分は interactive visualization をそんなに信じてない、というのはいいすぎだけど、宣言的である限り大したことはできないと思ってるんだろうな。JS でバリっと作るくらいがんばるならいいけど、Python から JSON を生成していると限りなく静的だからねえ。
• リサーチという点ではこういうインフラを作った上に色々リッチなものを積み上げ、interactive + declarative の地平を切り拓いていくことには意味はあるんだろうな。
• このひとたちが Observable, Inc. になっていたのか。アカデミアでがんばってほしかった・・・。

さて・・・

• 個人的には reactivity にコストを払ってデータサイズの制限をつけるくらいなら静的に振り切ってデータサイズにスケールするようにしてくれ、という気分がある。そういう意味で、一旦自分で Vega のレンダラを Skia あたりで書いてみるのは楽しそうではある。実用を目指すのは難しいにしても、娯楽として。
• 一方で、自分は interactive visualization というものをきちんと appreciate できているのかという疑問もある。なのでこの UW IDL から出ている論文のうち関連のありそうなものを読んでみるのは良い気もしている。

つまり書くかよむかという話なわけだが・・・。まあ、読むかな。読むだけならすぐ終わるからね。

• Vega Related Papers
• UW IDL Papers
• Vega Blog @ Observable

Reading List をつくってページトップに置くべし。

2021/12/03 #3

• まず How Vega Works / Vega / Observable から。
• Dataflow != Scenegraph なのか。そして dataflow 複雑だな。
• 参照されていた A Guide to Guides: Axes & Legends in Vega / Vega / Observable も。
• カスタマイズのパラメタが多くてめんどくさいものだ、ということはわかった。こういうのを地味に実装してるのは偉いね。

Reactive Vega: A Streaming Dataflow Architecture for Declarative Interactive Visualization

• Vega, もともと (2015) は Reactive じゃなかったのか! それを FRP のブームにのってこんなことにしてしまったんだな・・・。
• Stolte: Polaris: A system for query, analysis, and… - Google Scholar という Tableau のもとねた paper が grammar of graphics に並んで参照されている。GoG は古すぎる上に本一冊なので読む気にならないが、この論文は読んでも良いかもな。
• 論文の常として Relate Work のセクションは素晴らしいな。この論文の位置づけを理解できる上に、streaming database とか FRP のリサーチまで参照されている。可視化については言うまでもない。
• ただ Vega の挙動を理解するという意味では How Vega Works の方が簡潔＋具体的でよかったね。

2021/12/04 #4

というわけで Reactive Vega 了.

• 感想としては、JSON なので損してるね。 “Grammar” という意味で簡潔さがなさすぎ。機械生成を前提としており、たとえば Altair はその簡潔さ部分を助けてくれている。が、JS にそれがないと Obsevable Inc. が目指すような JS 中心対話的可視化 notebook はつくれない気がするな。
• あと UI イベントとデータを統合的に扱っていて、Reactive という観点でそれがいいのはわかるけど、結果としてデータ側の扱いが軽くなってる印象。リアルタイムにデータを流し込めれば dashboard とかで守備範囲が広がるはずだけど、そういうのの支援が特にない。Frozen なデータを対話的に drill-down する暗黙の前提を捨てきれていない。

というわけで Vega を Reactive にする判断は、個人的にはあまり convince されていないのだった。やりたいことはわかるんだけど。

• つぎ。Prefuse: A Toolkit for Interactive Information Visualization. 2005 の古い論文なので軽く行くべし。
• うげ。データソースが graph (Node+Edge) かいな。可視化もそれ系。マジどうでもいい・・・。というわけで次にいくべし。なお Java で実装されており時代を感じました。 この頃の可視化ってこういうやつだったかもね。ggplot2 (2007) は先進的だったな。
• 一方でこう、データ構造をパイプラインにつっこんでレンダリングするところはどこか Reactive Vega というか現在の Vega の実装に通じるものがあるねえ。

つぎ Protovis: A Graphical Toolkit for Visualization 2009.

• ここでついに GoG が言及されている！つまり (graph-based でなく) charting みたいな応用に視界を向けるに至った。ggplot2 は言及されないが Tableau が言及されており、これは Stanford つながりなのだろうな。ていうか Pat Hanrahan の研究室からスピンアウトしたのか。何らかのドラマの予感があるが、論文とは関係ないので先行くべし。とにかく Vega と Tableau は親戚なのだね。
• よくみると脚注で “Grammar of Graphics の実装である ggplot2 はこんな風に書きます” とか書いてんな。ちゃんと本文から引用しろ！
• なお実装は JS である。サンプルコードを見ると・・・。あれ、これまさに自分が Vega にほしいと思っていた JS (!=JSON) の DSL じゃん。
• 可視化で Tufte の再現をやってるあたりがシアトル勢だねえ。
• 比較対象が Processing だが、そりゃ plotting に特化すりゃプリミティブしかない Pocessing よりは簡素になんだろ。

了。

• オブジェクトモデルに違いはあれど、ハイレベルには JS で ggplot2 的な GoG をしました、という話だった。
• この時点では対話制はデータとは分離されていた。そんくらいでいいんじゃね、という気がするが reactive になってしまったんだね・・・。
• データの扱いに型が全然登場せず、そのへんが JS だなと思う。そしてデータを可視化するのにその data source がここまで opaque だと見通しが悪くて厳しい。そこは DataFrame がベースにある R の世界に対する弱点だね。
• これをがんばって refine していえばそれなりに良いものが出来た気がするが、なぜか Vega で JSON にしてしまったのだねえ。

つぎ Declarative Language Design for Interactive Visualization 2010

• JS だった Protovis を Java に移植して、Protovis DSL の宣言的言語としての可搬性、表現力を demonstrate するぞ、という話らしい。
• ただ DSL といっても internal DSL すなわち単なる API なので、テキストレベルで一致するわけではない。本当に単なる移植。
• ただ宣言的な言語だから色々最適化できるんだよ！と色々最適化を頑張って見せている。この話 Reactive Vega でもあったな。
• なぜ Java なのか？ Java の方が速いしアプリに embed したいかもしれないでしょ、と言っているが、10 年後の今から見ると完全にハズレな方向性だねえ。
• Protovis の論文には全然登場しなかった実装の話が少し載っている。そしてだいたい Reactive Vega と同じだな（というか、そこで引用されていたのでこれを読んでいるのだが。） アニメーションの都合でシーングラフを作ってますよという話。そうかい。
• それをシーングラフと呼ぶか AST と呼ぶかはともかく、DSL が作るデータ構造はレンダリング可能なデータ構造とは一致できないので、何らかの IR が必要なのは確かなのだろうね。それだと internal DSL にする旨味(実装のラクさ)が失われてしまう気もするけれど、まあ仕方ない。なおこの変換の過程でバイトコード生成とかして高速化してますよ、とある。
• Java だから Android でも動かしたよ、というスクショがある。頑張ってるな。しかし性能評価では一切言及なし。そういう遅い環境でこそ高速化の意義があると思うが、推して知るべし。並列化とかはそれなりにがんばってる。「Java に持ってきたから速い」という論文なので、そのへんは Protovis より真面目。
• discussion を軽く冷やかして読了。そして時間切れ。ここから Vega に向かうのは、まあわからなくもない。なんで Vega の論文はないんだろうね。

2021/12/07 #5

今日読むのは D3: Data-Driven Documents - 2011. D3 って本もあるくらいヒット作だけど完全にスルーしてたので良い機会であることよ。

• D3 は基本的には SVG のために jQuery を作ってやったぞ、という話である。 GoG の仲間たちはそれぞれ語彙を再発明しているが、ウェブなら SVG という標準があるんだからこれに乗るのが筋だろ、という主張。
• ただ素朴に jQuery 的 fluent API を実装するだけでなく、アニメーション、レイアウト、データを bind する仕組みなどもきちんと作り込んでおり、このへんの労によって使えるライブラリになっている。
• ただサンプルコードを見ると・・・・なんというか、クリエイティビティを問われるね。SVG がむき出しすぎる。論文の中のサンプルもそうだけど、たとえば d3js のサイトからリンクされている Observable の gallery から Stacked bar chart を眺める。しかしなぜこれが stacked になるのかまったくわからない！適切なデフォルトとかも特に無いので、width に “-1” とか書いてマージンを調整している。厳しい。比較として Altair のサンプルを見よ。あるいは faceted scatter plot を比較せよ: D3, Altair.
• 一方で、ミタメを完全にコントロールして novel な可視化をしたいガチ勢に良いツールだというのも理解できる。たとえばこの stacked bar から grouped bar への遷移アニメーション, なんの意味があるのかまったくわからないがとにかくかっこいい。こういうのは Altair / Vega では単純に不可能。
• D3 は宣言的な GoG に対するアンチテーゼとして API を手続き的な側に寄せた。一方で SVG や DOM という Web のプリミティブを活かすことで、ある程度宣言的な要素を残した。その結果として可視化ガチ勢の必須ツールとなった。偉業。
• ただ自分は可視化ガチ勢ではないのでお手上げ。個人的には D3 の上に同じ方向性で charting のためのライブラリを積み上げてくれればよかったのにと思うが、そういう事は起こらなかったのだねえ。Michael Bostock が興味なかたのだろうな。残念。かっこいい可視化をしたい人生のターンが来たら真面目に勉強します。

つぎ Declarative Interaction Design for Data Visualization, 2014. ちょっと前に読んだ論文とほぼ名前が一緒で紛らわしい…

• とおもったが Reactive Vega の話だった。
• Interactivity ってどうしても手続き的というかコードを書きたい場面があるのに、それを JSON で表現しなくてはいけないところに罰ゲーム感がある。Vega の Internal DSL を捨て JSON を選んだ結果プログラミング言語の支援が失われた痛みが強く出てる。
• さっと眺めるくらいで終了。お疲れ様ですね。

明日は Vega-Lite の論文を読み直すわけだが、こうしてみると Protovis から D3 と進んだものの D3 が takeover 仕切らず Vega で宣言的な方向性を強める方に振り戻してしまったのは、なんかちょっと残念だよな。おかげで Altair みたいなものが可能になったので文句は言えないんだけど、JS の可視化世界征服のためには Altair の JS 版が必要なんじゃないの？ JSON とか書かせないでくれよ。なんで無いのだろうね、というかほんとに無いのかな？

… と調べると vega-lite-api というのがあった。(サンプルコード). オフィシャルサイトのドキュメンテーションで全然推されてないのはなんなのだろうね。

まあいいです。今日はここまで。

2021/12/08 #6

今日は Vega-Lite 2017 を再読。(前回の記録)

• Vega-Lite のモデルをそこそこ丁寧に解説しており、良い導入になっている。
• Vega ではなく Vega-Lite が GoG/ggplot2 のライバルだと理解。Vega は思ったよりシンプルで、たとえば様々なデフォルトを解決してくれたりしない。言われたとおりに書くだけ。一方の Vega-Lite はそういう類推および簡単な集約などをやってくれる。おかげで記述がシンプルになる。
• 論文としての novelity がどこにあるかというと interactivity を GoG に持ち込んだこと。これは他には誰もやっていない。が、個人的には興味ないなあ・・・。D3 とかをやってから戻ってくると有り難みを感じるのかも知れないが、普段の plotting 作業で対話制野必要性を感じることないからね。

Vega-Lite でようやく ggplot2 に（だいたい）追いつき、ある面では追い越すことが出来た。が、やはり JSON が足枷に感じるよなあ。簡潔といいつつ JSON というものの本質的な記述力の低さが足を引っ張っている。これは vega-lite-api や Altair で解決されているわけだが。

対話性にしても、exploratory visualization に使えると言っているが EDA には弱いのだよね。JS というか JSON だとでかいデータを処理できないから。自分が EDA しようとおもったらまず SQL を書く部分で色々パラメタを変えて試行錯誤するから、それが「対話・探索」に相当する。Vega-Lite はそういうデータソースの tweak には向いてない。SQL なり Pandas なりの filtering/reshaping 能力に比べると Vega-Lite の transform とかしょぼくて使い物にならない。覚える気も起きない。

別の見方をすると、Vega-Lite のいう exploation は可視化つき資料を書く人が可視化つき資料を読む人のために用意するものである。たとえば NYT の記者がインタラクティブな可視化つき記事に埋め込む可視化とかには使える。これまでは D3 でガッツリ書かなければいけなかったよそ行きの対話的可視化を、分野を限ればサクっと作れるようになる。

そこに価値があるのはわかるが、自分がほしいものではない。自分は自分自身のために探索をしたいわけだから。こうして Vega-Lite の可視化の位置づけと自分がそれに不満な理由を理解できたのはよかった。

Vega に対して Vega-Lite が追加した対話性以外の部分、つまり既存の GoG に対する feature parity は、novelity はないかもしれないが実用という意味では重要で、いい仕事をした。おかげで Altair ができるわけだからね。

さてこれで Altair に至る道筋が理解できた。読み残しているのは UW の人たちの最近の論文と、Vega への影響の強い昔の論文たち。どっちから読もうか。まあ先に UW シリーズを終わらせておくかな。

というわけで Communicating with Interactive Articles, 2020

• これは(少し前に休刊になてしまった) Distill です。Distill の休刊には G Research の凋落を感じてしまう。まあそれはいい。
• サーベイ記事なのでちょっと長いね。
• 了。感想はあとで。

2021/12/09 #7

Communicating with Interactive Articles:

• まずオンラインの様々なインタラクティブ可視化記事を参照しながら、インタラクティブ記事の利点を説明していく。このパートは単純にリンク集として素晴らしい。あとで読む。
• 次にインタラクティブ記事を作る上での壁を議論する。まずインセンティブの壁（たとえば研究者には時間をインタラクティブ論文を書く動機がない、それより静的な論文を量産する方が良いから、など。）これはまあ、どうでもいい。
• そしてもう一つの壁、すなわち技術的な困難を説く。新聞社の可視化記事とかチームで作る前提、Distill の記事も Git clone して HTML を編集するコラボレーションスタイル、そんなのプログラミングリテラシーがないとムリじゃんと。
• 著者らは解決策の一つとして Markdown の可視化拡張 + static site generator の Idyll というのを作っている。要するに Vega chart を埋め込めるわけだが・・・これは Jupyter と比べてそんなに嬉しいのか？研究としてはいいが、実用したいとは特に思えない。
• ただし著者らはこれを dogfood して Parametric Press という online mag を issue 2 まで出しており、そこは評価できる。
• これだけでなく、いくつかのインタラクティブ可視化がんばろうなムーブメントを紹介し、同時に NYT の中の人が “インタラクティブなの作ってもみんな触ってくれないからやめるわ” と 言ったスライド などを参照しつつ、可能性はあるからがんばってこうな、と締めくくる。

UW IDL のみならず周辺の可視化研究者の立場がよくわかる論文だった。やはり自分でデータを突きながら open-ended の探索をするよりは、何らかの insights がある前提でそれを communicate する手段としての対話的可視化なのだよな。

そしてプログラマというのは、対話的可視化ができるコンテンツおよびツールを生み出す上でかなり良い立場にいる。なぜならコードが書けるから。もちろん書くべきコンテンツがあるとは限らないが、もしデータに基づいて何かを発言するなら対話的可視化をつけてなんか言う方がいいんじゃないか、と思うに至った。なぜならプログラマにはそれが可能だから、面倒ではあるかもしれないが・・・。

ただ面倒くさいのは事実。著者らも “reating a successful interactive article is closer to building a website than writing a blog post” と書いている。そういう意味で単一のデータ/データセットに対する対話的コンテンツを作るのはプログラマであってもなかなか割にあいにくい。

一方、データを扱うツールみたいのを作るなら、もうちょっと対話性をがんばってもいいんじゃないか。自分はいま仕事のサイドで Perfetto Trace をクエリして興味のある指標をダンプするコマンドラインツールを作っており、そのツールに静的なチャートを埋め込めないかというのが Altair のコードを読みはじめたきっかけだった。が、コマンドラインツールではなく JS のウェブアプリにして、trace のファイルをアップロードすると色々チャートを出してつつける、という方が人々も触る気になるんじゃないか？（今はツールが指標を書いた markdown をバグトラッカーにアップロードする作りになっている。)

隣のチームではデータを可視化する Python のライブラリを書いてそれを呼び出す Colab noetbook のテンプレを配布している。それでも悪くはないし敷居は低いが、ウェブベースのツールにしたほうがより敷居は下がるよね。

ここには手間と見返りのトレードオフがあるが、すくなくとも単一の対話的可視化記事を作るのに比べるとツールをがんばる方がだいぶ割が合うように思える。自分もともとは他人のための可視化には興味がなかったが、なにか頑張る余地があるのかもしれないと考えを改めた。EDA には大げさ過ぎると思っていた D3 も、何ができるか触っておくとツール業の足しになるかもしれない。

など、それなりに対話的可視化の価値を見直すきっかけとなった。

つぎ Critical Reflections on Visualization Authoring Systems, 2020

• なんらかの振り返り論文。
• 筆頭著者 は MIT の人らしい。このひとの研究室をみると・・・・似たような研究をしているね: MIT Visualization Group
• 可視化を GUI で作るツールを過去に色々作ってきたから振り返るよ、という話だった。興味ねー。著者は “A shared assumption underlying our systems is an author’s desire to visualize data without programming while still exhibiting a level of comfort with computational thinking” と書いており、一方自分は pogramming する方にバイアスがあって GUI でポチポチ dashboard を作るのにはウンザリしているので、やむなし。
• そしてダッシュボードという観点で見ると、ツールは SVG や Vega をエクスポートできるらしいが、そんなもん貰ってもなあという残念感。最終的な成果がブラウザで消化され、かつデータソースはダイナミックに降ってくるわけだから、そのツールも dashboard に住んでるのが自然じゃね？(Web-based ではあるらしい。)
• ただ Vega (JSON) をエクスポートして、データの部分はテンプレにすれば他のツールにも持っていけるよと言っており、そういう用途が念頭にあったからこそ Vega は JSON なのだとわかる。
• なにかと Power BI が参照されていてなんでやねんと思ったら、著者の一人は MSR で可視化ツールの研究をしているらしい。へえ。

この論文は話題になっている可視化ツール (Lyra, Data Illustator, Charticulator) がわかってないと意味不明だな。終了。あとで一つくらい読んでやるとしよう・・・。

というわけで Lyra 読む？とおもったけど著者の一人は最近 Lyra2 というのを出しているので、これを読んでみるかな。MSR のも気になるけどね。

Lyra 2: Designing Interactive Visualizations by Demonstration | MIT Visualization Group, 2020

• Lyra (1) に interactivity を足したよ、Vega-lite を出力できるよ、というものらしい。興味わかん・・・。
• Lyra は GitHub にあり(vega/lyra), Lyra 1 は 実際にさわれるものがオンラインにある. Lyra 2 はまだリリースされていないらしい。なんやねん・・・。
• で Lyra 1 をさわってみると・・・なんちゅうか、会社の dashboarding tool の方が普通に良く出来てるな。Lyra 2 の論文を見るとその手の dashboarding tool (Tableau とか) はテンプレートベースで表現力がないので、Vega / Vega-Lite のようにもっと表現力の高い可視化を提供すると言っている。がしかし、そのために使い勝手の敷居が上がりすぎじゃね？
• Textural representation より敷居が低いとかいうけど、コードはコピペすればだいたい動くからサンプルのコピペを起点にいじっていけるのに対し、Lyra は一からデータを作っていかないといけない。もちろん理論上テンプレートは提供できるわけだが、SO とかからコピペできる textural representation の versatality には全く及ばないのではないか。
• 論文中では使い勝手の工夫とかユーザビリティの評価とかしてるけど、まあどうでもいいかな。わたくしはテンプレベースの GUI か textural representation があればそれでいいです。

がっかりしつつ、いちおう MSR のやつも読んでおく:

Charticulator: Interactive Construction of Bespoke Chart Layouts - Microsoft Research, 2018

• が Abstract よんでパラパラ眺めてだけでもう興味の無さが限界に達してしまった・・・。
• オンラインで試せる: https://charticulator.com/ が、やはりわけわかんない。
• Power BI とインテグレートしてるのは偉いなと思いました。

以上。Tableau 路線 Authoring tools の必要性には説得されなかった。今日はここまで。 明日はその Tableau の論文でも読むべし。

• Home - code-server v3.12.0 docs

VM をつくる:

$ gcloud compute instances create codevm --image-project=ubuntu-os-cloud --image-family=ubuntu-2004-lts \
  --machine-type=e2-custom-micro-2048 --zone=us-west3-a \
  --boot-disk-size=16GB --boot-disk-type=pd-balanced
$ gcloud compute instances add-metadata codevm --metadata enable-oslogin=TRUE

SSH with port forwarding:

• 8080: code-server
• 1313: Hugo serving

$ gcloud compute ssh codevm -- -L 8080:127.0.0.1:8080 -L 1313:127.0.0.1:1313

必要なものを をインストールする:

vm$ sudo sh -c 'curl -fsSL https://code-server.dev/install.sh | sh'
vm$ sudo systemctl enable --now code-server@$USER
vm$ sudo snap install hugo

TODO:

• 自動 shutdown をつける
• Terraform にする

ツール類の導入

$ nvm use stable
$ npm install -g yo generator-code
$ npm install -g vsce

##　パッケージ

$ vsce package

VSIX をサイドロードする

• How to install VS code extension manually? - Stack Overflow

Links

• Extension API | Visual Studio Code Extension API
• Your First Extension | Visual Studio Code Extension API

2016 はブログを書かないと決めたものの、何か書かないと精神衛生に悪いからと結局9月ころから個人的に書き溜めていた。 年も開けたのでまとめて公開しておく。

考えごとを記録するとき、第三者の視線があるのは自分にとって助けになる。 みっともなさゆえ不必要にネガティブだったり自棄鉢にならないから。 一方で他人の視線があると無駄に気を引こうと謎のサービス精神を発揮してしまい害をなすこともある。 誰でがそうとは思わないけれど、自分の場合ね。

書き溜めておいて年に一回くらい公開するのは、 その二つのバランスをとる良い方法かもしれないと思ってこんなことをやっているけれど、 それが果たして意味があることなのか。今のところわからない。 ただ 2016 年中はそれなりに書きたいことだけを書けた気がした。

List Threads Based On Their Priorities

$ adb shell ps -T -l `adb shell pidof $PROCESS_NAME` |  sort -r -k 8 -n

Pull Out The Latest Trace

$ adb pull /data/local/traces/`adb ls /data/local/traces | tail -n 1 | awk '{ print $4 }'`

Buid, Flush. Sync

Build:

$ source build/envsetup.sh
$ lunch <product>-<variant>      
$ m

Flash:

$ vendor/google/tools/flashall

Incremental Flash:

$ adb remount && adb shell stop && adb sync && adb shell start

$ git config --global credential.helper store
$ git config --global core.editor vi
$ git config --global user.email "omo@dodgson.org"
$ git config --global user.name "Hajime Morrita"

Code Server を使ったブログおよびメモ環境を整備するプロジェクト。

Tasks:

• Chromebook からの SSH port forwarding を設定する
  • SecureShell は壊れたら browsing data を clear したのち about://restart すべし :-(
  • PWA で動かすと Ctrl+Space が取られてしまうので Ctrl+Shift+Space で日本語入力に切り替える。
• Blog post のドラフトを新しく作る vscode の拡張(?) を書く
• WP の今年分をインポートする
• oauth2-proxy の裏に隠してコンテンツを公開する
• 友達の皆様向けに oauth2-proxy を設定する
• 手順の文書化
• Code blog のスタイル調整
• ドラフトトップページの整理
• 非公開メモおきばをつくる
• single.html に日付を入れる
• pages の目次を作る
• Wrap-up を書く
• 変更のお知らせ
• title に日付を入れる

Stretch:

• vscode の拡張を強化
  • Fragments のファイルを開く
  • Wiki page のファイルを作る
• Wikilink 相当の Hugo shortcode を作る
• Confluence のコンテンツをコピーする (手動?)
• VM の夜間自動 shutdown を設定する
• VM の起動用ウェブ UI をたてる

2021/11/19 #11

• 目覚ましつけ忘れて寝坊。
• まとめ
• そしてお手紙送付。これにて横書き日記はおしまい。めでたしめでたし。
• さて縦書日記に戻りたいが、微妙に家の細事が滞っている。そっちが先。

2021/11/18 #10

• さて、友人向け公開だけでなく、メモ目的で自分にだけ見えるページというのが欲しい。 しかし Hugo ではそういう複数の可視性をサポートしていないので、何らかの工夫が必要。
• 「自分にだけ」の部分は「localhost 用にレンダリングした場合」という形で表現できる。 code-server の VM で ‘hugo serve’ した port を forward しているので。
• しかし「表示しない」をどうしたものかなあ・・・
• disableKinds を使えるかと思ったが、自分で kind を定義できないのでダメ。
• publishDate を未来にすれば ‘-F’ オプションを使うことで自分だけに見えるページは作れる、まあアリだけど、もうちょっとなんとかならないか。
• buildExpired / expiryDate についても同様だが・・・こっちの方がちょっとだけ扱いやすい気もするな。“0000-01-01” とかにすればいいわけで。これでいいかなあ。
• というわけで WP から移行してきた個人的な記録に expiryDate をつける。
• あとは vscode 拡張のテンプレにも最初から expiryDate をつけておこう。消すのは簡単だからね。
• できた。
• 今週一杯使うと書いたけど、もうやることないね。まとめを書いてお知らせして、おしまいだな。年末になったらマージして public にも公開しましょう。誰も読まないだろうけど。

2021/11/17 #9

• さて一応 CI も動いたし一通りのことはできたが、せっかくなので今週は細かいブログの調整とかをするかな。
• まずは 文書化.
• Code snippets のスタイルが崩壊しているのをなんとかせねば・・・。
• げ。インポートスクリプトのバグで前に公開したものたちまで非公開になっているな・・・。 直すべし・・・。
• といったところで終了。

2021/11/16 #8

• 家の用事を片付けていたらもう 5 時。
• 基本的には動いているのだが、どうせなら Dockerfile の multi-stage build というのを試してみようかなあ。
• できた。どっちがいいかと言われると正直どうでもいいが、Dockerfile に閉じるのはいいのかもしれない。まあ一度やってみたかったので満足です。

2021/11/15 #7

• さてなぜイメージに正しくファイルが入ってないのか調べましょう。
• 単に hugo -D -F してなかっただけの模様…
• イメージが巨大化した (+50MB)。 昔のドラフト日記に png がいっぱい貼り付けてあるため・・・。
• さて認証。自分だけにしか公開していないはずが、なんかデバッグユーザで 普通に見えてしまうな。結局 oauth2-proxy 側できちんと弾かないとダメっぽい・・・。
• それでもダメ。 ログを見てもファイルを読むのに失敗した様子はない。 oauth2-proxy のコードで --authenticated-emails-file の振る舞いを調べると --email-domain が一致しているのでも通過できるらしい. --maill-domain を削除。でめでたく 403 が帰るようになった。
• というわけでマニュアルのデプロイはできるようになりました。 次はこいつを CI したい。 GitHub Actions でいくか Cloud Builds でいくか。 Cloud Run との相性では Cloud Builds なのだが、 なんか GitHub からコードを持ってくるのがすごいめんどくさかった気がするのだよなー昔。今はマシになったのだろうか。
• ドキュメントを読むとさすがにできるっぽいのでやってみたいところだが、ビルドを Dockerfile に押し込めるか外でやるかが悩ましいな・・・。とりあえず Hugo は毎回ダウンロードしないで third_party あたりにコミットしとこう。
• 手元の gcloud builds submit は動いたので、今度はこれを GitHub に紐付ける必要があります。
• ビルド(デプロイ)に二分半。遅いのをなんとかしたい気もするが大半の時間が docker push/pull なので特にできることもないかなあ。
• Multi-stage Dockerfile にすうと cloudbuild.yaml を簡素化できそうだが・・・。 イメージサイズの再現には役に立たないな。やめ。

2021/11/14 #6

• 前日が遅かったため寝坊。
• さて、前日は Cloud Builds に突撃しようとしていたが、まずは手動で作ったイメージを gcr.io に push して Cloud Run を動かしてみようではないか。
• GCP, Container Registory は終了で Artifact Registory になったらしい。名前変える意味あんのか・・・。
• gcr.io じゃなくて us-west3-docker.pkg.dev らしい…
• Cloud Run の domain-mapping は Pre-GA だったのか。そして us-west3 は未対応らしい :-( おもむろに us-west1 に追加。Artifact はもう west3 のままでいいです…
• 唯一の AWS 依存であるところの Route 53 でドメインを設定. Cloud Domain に移そうかと一瞬思わなくもないが、めんどくさいな。Roue 53 で何一つ困らないし。dodgson.org じゃないドメインをとる暁には試してあげよう。むしろ kzys のやってる App Runner でも使って見る方が正しい課外活動にも思えるけれど。
• Domain mapping の設定がが帰ってこないので App Runner のドキュメントを冷やかすものなり。Heroku みたいに Git (というか GitHub) にコードを push すると deploy されるタイプと、Docker イメージを push すると deploy されるタイプの二種類があるらしい。docker push すると勝手にデプロイされるのはひと手間少なくて便利だね。Cloud Run は docker push と cloud run deploy はわかれているので。
• 20 分後にようやく設定完了。そしてイメージに HTML が入ってないっぽい雰囲気。時間切れ。

2021/11/13 #5

• 引き続きインポート作業。昔書いた Python のコードがひどい・・。 前向きにいうと Python の fluency は数年前よりは上がっている。
• というわけでインポート終了。ドラフトやメモも含めてインポートしたためゴミだらけだが、 まあいいです。
• さて次のステップは Netflify に push か。しかし改めて考えるにこれ Netlify にすべきなのだろうか・・・企業秘密ではないにせよあまり不特定多数に見られたいわけでもないもの（愚痴とか）も含まれている。oauth2-proxy の後ろに隠すとは言え、裏にある Netlify の URL をさわると見えてしまう。むしろ oauth-proxy の Docker image に HTML とかをつっこんで push する方がよくね？
• ただ oauth2 proxy はデバッグがだいぶ面倒なのでちょっと気が引けるなあ・・・。とかいってると進まないのでとりあえず突撃すべし。
• とりあえず Message Passing で使っているこの Dockerfile を起点になんとかしたいわけだが・・・どうすればいいのかな。というと Hugo の public を ADD すればいいのか。
• 今回は gmail.com で auth したいんだけど、Google 側はどうやって設定するのだろうね・・・。これ か。
• Google OAuth の設定は触るたびに面倒になっていて、今はテストユーザに限った テストモードでない限りレビューが必要らしい・・・・が、 このテストユーザ機能はそのままブログの認証に使えるじゃん。 oauth2-proxy でユーザを絞らなくて良いのは偶然便利。
• うげ gcloud builds submit するには Dockefile の中で hugo からの generation をしないといけないのか。さて・・・。
  • Option 1: docker push で手元で作ったイメージを gcr.io に push する
  • Option 2: gcloud builds submit できるようになんとかする
• なんとなく gcloud builds でちゃんと動くようにしておくのが筋な気がするが、 そもそも Cloud Builds のことを完全に忘れてしまったのでその復習からやらないといかん。
• といったところで今日は時間切れ。先は長いなあ・・・。

2021/11/12 #4

• 昨日は夜が遅かったので寝坊。まあいいです。
• WP インポートするぞ！インポートのスクリプトはあるが、 今までと違って公開してないものも (draft として) import してみるべし。
• しかしその前に今年分の公開/非公開フラグをつけ直さないといけない・・・。愚痴の皆さんには非公開になっていただく。

2021/11/11 #3

• Extension 続き。
• スタブ作成できた。20 行じゃないけど 50 行くらい。async/await のおかげでめちゃ手続き的にまっすぐ書けるし “VS” Code だけあって TS よくわからん素人でも生産性高いし、世の中に腐るほど手本はあるし、ブログやメモ書くの支援するくらいなら拡張は自分で揃えられそうな予感。
• つぎ、いまいるファイルを rename する拡張。
• できた。もう Emacs Lisp を懐かしむ日も来るまい（もともと全然詳しくないだけに。）
• さてパッケージファイルを作って code-server に持っていきます。
• Hello From YokogakiX.
• コードはこんなかんじね.
• さて、では WP のコンテンツ今年分をこのブログにインポートしましょう。
• といったところで時間切れ・・・。

2021/11/10 #2

• さてブログのドラフト書き支援 VSCode 拡張を考えます。
• が、ドキュメントを読んでいて気付いたがテンプレ挿入は Snippets というのが使えるのかな？
• つかえた！いいじゃん。しかも blog のレポジトリにチェックインしておけるじゃん。
• つぎはファイルをいい感じの日付ディレクトリに作りたい。なんかコマンドを実行すると /content/post/2021/11/10/untiled.md のようなファイルができるとかにしたい。
• この untiled.md を rename するのは手動でやるか・・・と思ったがそういうコマンドはなく、拡張を入れる必要があるらしい。
  • sleistner/vscode-fileutils: Visual Studio Code Extension
• そして code-server は Marketplace が使えない！といっても大半の拡張は GitHub にあるので sideload すればいい気がする。
• この vscoe-fileutils のコードを真似して書けばいいかな・・・とおもったがなんか妙に大げさだね。20 行くらいで書けてほしいんだけど・・・。勉強がてらこれを参考に自分の拡張として実装しなおすのがいいかな。
• というわけで拡張の stub を作りましょう・・・。
  • Extension API | Visual Studio Code Extension API
• Packaging / publishing のセクションを読むに、雑に extension のディレクトリを sideload しておくことはできず、vsix というパッケージにする必要があるらしい。まあいい。ただ拡張の開発は code-server ではやりずらそうなので、おとなしく手元でやりましょう。
• F5 でエディタの別インスタンスを起動して開発するの、Visual Studio ですねえ。
• 気がつくと extension id を tategakix にしてしまった。縦じゃない…

2021/11/09 #1

• とりあえず VM をたてて laptop から書き始めるところまではきたぞ。
• Chromebook でも動いた。SSH のキーを登録するのに戸惑ったが 公式資料 などを見てなんとかなった。public key と private key 両方が必要というのが罠。
• これで仕事中もちょっとメモを読み書きできるようになったので、最低限のラインにはたどり着いたといえる。

Windows を試す日記。

• Goal 1: Chromebook と同程度に非コード作業をできるようにする。要するに不自由なく Chrome が動くようにする。
• Goal 2: Linux でのベーシックな開発作業をできるようにする。
• Non Goal: ファンシーな Windows 専用アプリを使う
• Non Goal: Windows native の開発をする

試すこと:

• DuckDB をビルドしてみる
• Android Studio を使ってみる
• Jupyter を使ってみる
• 起動時の SSH port forwarding を自動化
• XPS 15 にインストールしてみる

2022-03-10

ここまでにやったこと:

• Windows 10 の ISO image から Bootable USB を作成, インストール.
  • イメージは Microsoft からダウンロードできる。
  • Disk utility を使う。一部ファイルがでかすぎるため NTFS でフォーマットする必要あり。まあまあ時間かかる。
• XPS 13 に刺してインストール.
• Amazon で Windows 10 のライセンスを購入, activate.
• Windows Updates を全部適用… したら Windows 11 になっていた.
• Install Chrome
• Dell のサイトを探してドライバを入れる。
  • セキュアじゃないかんじの謎のプログラムをインストールするとウェブサイトがデバイスを検出してドライバを列挙してくれるようになる。どうみても attack vector です。
  • 必須といわれるものを入れてもいろいろ動かない。追加でどれが必要か自明ではないが、動かない機能に対応するやつを入れるかんじ: Audio, BT など.
• Caps lock を殺す: keyboard layout - Map capslock to control in Windows 10 - Super User
  • 最初は AutoHotKey というのを使ってみたが、キー入力が激しく messed up だったで諦めで regedit.
• Google Japanese IME を入れたが、郷に従おうと思い直してアンインストールし MS IME でがんばってみる。
• WSL を設定: Install WSL | Microsoft Docs
  • 結局本家のドキュメントが一番よくかけている印象。
• gcloud を入れる (code-server の VM に SSH するため。)
• code-server へのアクセスを確認
• VSCode 用にマシっぽいフォントを入れてみる - コーディングに最適な日本語対応の等幅フォントSource Han Code JPとは - ICS MEDIA

感想:

• Windows, なかなか速い. 7 年前の laptop (2 Core 4 HT の i5, 8gm ram) で全く問題なし。起動も速いのが印象的。再起動よくするからな・・・
• 一番のフラストレーションはキーボードショートカット類だが、これは完全になれなので頑張ります。フォントもいまいち好きじゃないが、これも慣れということで。
• こまごまとしたフラストレーションはあるが, Ubuntu で鍛えた身にはそよ風である。しかし Mac から来たらつらいかもな。てか regedit とか知らないと積んでしまうじゃん・・・。
• virtual desktop がデフォルトであるのもフルスクリーン志向の自分にはうれしい。最近は Mac にも CrOS にもあって、めでたいねえ。
• WSL の資源利用の少なさが謎. メモリとか全然使ってなさそうじゃん。

2022-03-11

• WunderMail という GMail クライアントを試してみた -> 遅すぎのため uninstall.
• Messenger desktop をインストール.

Building DuckDB

• 適当にビルドしてみると, Vmmem というプロセスがガンガンメモリを使い始める。知り合いはこれがいやで WSL を使うのをやめたといっていた。なんとかならんか調査してみる。
• Taking Back Memory From Vmmem/WSL | BlogLogBlog
  • 解決策を示している、としているが・・・解決してねー。WSL の VM はデフォルトで 4GB 確保するらしい。ただ lazy にしかページを触らないのでちまちまさわっているうちは大丈夫。 でもビルドのような作業をするとファイルがキャッシュに乗ってページが汚れてしまう。そして guest のキャッシュは host にとっては単なる heap なのでメモリは使われる。 そして guest (Linux) 側で file cache を捨ててもそのメモリが host (Windows) に帰ってくることはない。
• XPS13 は 8GB しかないので厳しいな。このスレ によると 4GB というよりはシステムの物理メモリの半分ということらしいが。
• Linux VM が host にメモリを返せればいいが、そういう host-guest 通信は存在しないのかなあ。あるいは Linux ではなく Windows が file cache を持ってくれるか・・・
• とかいってる間にビルドが終わったので task manager を見ると VmMem のメモリ使用量が 3.5GB くらいから 700MB に減っていた。つまり guest が host にメモリを返すことはできるらしい。ただそういうやり取りが追い付かないのでメモリ消費が spike したり、やりとり自体のコストで CPU が busy になったりする、のかな？それとも CPU の負荷は単に　guest での計算が VmMem プロセスに現れるだけなのだろうか。CPU については他にどのプロセスも動いてないので、VmMem が guest の proxy という理解でよさげ。
• 現実的には laptop のメモリをガンと増やすのがよいのだろうな。64GB… は $250 でちょい高し。32GB だと *$150. このくらいかな。
• なお duckdb のビルドはすっごい遅いね。これは XPS13 のせいな気がするが。
• あとビルドの負荷でシステムが遅くなってしまうので CPU を throttle する必要もあるげ。.wslconfig に proccessors というセクションがあるから、これを減らせばよい。

2022-03-14

• とりあえず .wslcofig でメモリと CPU を絞る.
• Task Scheduler でログイン時の SSH Port Forwarding を設定。PowerShell のコマンドは以下のような感じ:

ssh -i "C:\Users\Hajime Morrita\.ssh\id_rsa" xxx@xxx.xxx.xxx.xxx -fNT -L 1313:localhost:1313 -L 8080:localhost:8080

• Task Scheduler への registration に GUI が必要なところがいまいちなので自動化したいが、また今度ね・・・。

2022-03-21

• XPS13 メモリ少なすぎで厳しいためしびれを切らし XPS15 にも Windows をインストール。しかし XPS13 の product key を削除し忘れたため activation にてこずる。最終的には電話越しになんかすることで解決。だりー。
• Google Drive アプリを入れてみる。あら便利だこと。Chromebook の sync は使い物にならなかったが、こいつはさすがにちゃんと動くと期待。
• code-server の設定かったりーな・・・とかお思っていたが、実は VS Code のリモートでいいのでは、と試してみたら、よかった。びっくりするほど快適だわ。ただ VS Code はコード書きにも使うはずなので、混ぜてしまうのが良いアイデアなのかはわからないな。
• code-server の VM の IP アドレス毎回コピペするのかったりーな・・・と思っていたがふと世の中には DNS というものがあったのを思い出し Route53 で適当に命名。
• XPS ではまだ WSL を設定していない・・・がこれは明日だな。

2022-03-22

• XPS 15 に WSL を入れる。
• 再び Duckdb をビルドしてみる。CPU core を 6/8 に throttle しているにもかかわらず CPU の utilization が 100% 近くになってしまうのはイマイチだな。host 側の IO subsystem が CPU を使ってしまうんだろうけれど。VmMem process 自体を cgroup 的に縛れないとちょっとイヤだな。こういうかんじか やはり PowerShell をマスターする必要があるなあ。なおビルドの所要時間は 5min でした。
• make clean してビルドしなおすと 100% まではいかないけど 90% は使われている。VM ってなんだかんだで overhead あるよなあ。あるいは HT というのがそういう性質なのかもしれないが。Duck 業をするなら速い laptop が必要。まあ、しばらくはいいです。メモリは現状 (16GB) で一応足りてるはいるが, 32GB あった方が安心げ。