4 ポイント 投稿者 GN⁺ 2024-05-18 | 1件のコメント | WhatsAppで共有
  • D3 in Depth は D3 6・7 を基準に、D3.js でカスタムデータ可視化を作る過程を扱う学習資料
  • 単純なチャートの使い方より カスタム可視化の制作 に焦点を当て、Web可視化の構成要素まであわせて学べる
  • HTML、SVG、CSS、JavaScript の基礎が D3 の作業と結び付いており、Webベースのデータ表現 を理解する助けになる
  • React、Chart.js、Leaflet を活用したダッシュボード・データストーリー資料ともつながり、JavaScript可視化の学習フロー を作ることができる
  • D3 を深く学びたい読者にとっては、概念理解と実践をあわせて進められる入門・発展資料として活用できる

D3 in Depth が扱う範囲

  • D3 in Depth は D3 バージョン 6 と 7 を対象としている
  • D3.js を使って カスタムデータ可視化 を作る方法を学べる
  • Webベースの可視化制作に必要な基本要素として HTML、SVG、CSS、JavaScript をあわせて扱う

あわせて見られる JavaScript 可視化資料

  • Data Dashboards with JavaScript は React、Chart.js、Leaflet を使ってデータダッシュボードを作る方法を扱う
  • Visualising Data with JavaScript は Chart.js、Leaflet、D3、React を使ってチャートとデータストーリーを作る方法を扱う
  • ある読者の評価では、この資料は D3 本の中でも高く評価されており、内容が明快で追いやすく、概念がしっかりしているとされる

1件のコメント

 
GN⁺ 2024-05-18
Hacker News の意見
  • D3でデータ可視化をするという発想はよいが、もう少し高レベルなツールが欲しいなら、D3チームが作ったObservable Plot[1]を見る価値がある
    D3の上に、グラフ・チャート・プロットを作るための慣例や便利機能を多く載せたライブラリである
    さらにその先にはObservable Framework[2]もあり、Plot、D3、そのほか複数のライブラリをサポートする、可視化ダッシュボード向けの静的サイトジェネレーターである
    1: https://observablehq.com/plot/
    2: https://observablehq.com/framework/
    • 最近はむしろ逆のほうに惹かれる。多くの場合、成果物が正確にどう見えるべきかはすでに分かっているのに、フレームワークは本質的に多数のあらかじめ決められた設定を提供し、その設定から少しでも外れようとすると苦痛になる
      いろいろな種類のプロットは、単にSVGデータを直接操作するほうが実際には簡単なことが多く、それほど難しくもない
      SVGやキャンバス出力をもっと簡単に操作できるライブラリやフレームワークがあればよいと思う。小さな修正はとても簡単であるべきなのに、フレームワークが高レベルになるほど、決められた道から外れにくくなる
    • Observable Plotは素晴らしい。非常に柔軟で直感的に使えるので、以前使っていたPlotly.jsより今はこちらを好んでいる
      ドキュメントもかなり良いが、使えるAPIリファレンスのセクションが欠けているため、機能を見つけるには向いていない
    • Web可視化にMatlabのようなドラッグ&ドロップインターフェースがあるのか気になる
      HTML5キャンバスでグラフを作るのはできるだけ避けたいので、新しく設計する方法があるとよい
    • PlotとFrameworkはObservableエコシステムに結び付いていて、それ自体に学習曲線がある。柔軟性と制御という面では、D3を学ぶのが最もよい
    • このWebサイトがほかの人にももたついて感じられるのか気になる。コンテンツの多いWebページでは、頻繁にカクつきを感じた
      追記: ハードウェアアクセラレーションをオンにするとより滑らかになったが、Ryzen 9でも期待よりはまだもたつく
  • D3は好きでたくさん作ってきたが、数年使わずにいて戻ってくるたびに、覚えていることがほとんどなく、ドキュメントはさらに混乱させ、また振り出しに戻ったように感じる
    10年見ていない偏微分方程式を解けと言われたほうが、むしろもっと早く勘を取り戻せそうだ
    D3のリファレンスドキュメントも本当にひどいと思う
    • D3をバージョン2から7までかなり使ってきたが、その間のリファクタリングのせいで、オンラインの例はもともと理解しにくかったうえ、更新するのはさらに難しくなった
      それでも今はより安定したように思う。D3だけを使うより、Svelte+D3でより命令型スタイルに書き始めてから感覚がつかめた
      生成された要素をあとで開発者ツールで覗く方法より、生成要素をより簡単に理解できた
      D3とSvelteを一緒に使うには、このサイトが役に立つ: https://svelte.recipes/
    • ほかのプロットライブラリよりは、その問題ははるかに少ないと感じる
      自分の仕事の80%はアプリケーション、10%はシステム、10%はデータ分析に近く、しばしば2週間Jupyterノートブックを作って、その後2か月見ないこともある
      たいていのプロットライブラリには覚えなければならない恣意的なルールが多く、たいてい小さなドメイン特化言語がいくつもある。単純な文字列がatoiよりはるかに複雑に解釈されるようなものだ
      さらに、軸範囲の決定、大量の点の処理など、いくつもの領域で自分の観点からは何かがおかしい部分がある
      D3は多くのことを自分でやらせるが、そのためのインターフェースは概念的に直感的だ。瓶の中で船を組み立てるようなAPIで、他人の肥大化してバグの多い汎用コードを使うより、D3.jsできちんと作るほうがましだと思う
    • D3をかなり使い、AngularJSとAngular向けの統合まで作ったことがある。強力ではあるが、常に非常に直感的ではないと感じていた
      間違って使いやすく、デバッグしにくく、理解もしにくい
      この問題が簡単に解けるという意味ではない。非常に具体的なデータ駆動のグラフィックを作らなければならないなら、それでもなおD3を選ぶ可能性は高い
    • 微積分のための人間向け計算インターフェースは、何世代にもわたって丁寧に磨かれてきた。Newtonの原文を少し読んでみるだけでも、昔から常にそうだったわけではないことはすぐ分かる
      APIをその基準で比較するのは、実際のところ公平ではないように思う
    • 同じ経験をした。最近、テックリードとしては、高度なドメイン知識を要求するライブラリは使わないよう強く求めている
      書いた本人でさえ理解しにくいコードはできるだけ避けるべきで、D3はそのようなライブラリの代表例だ
  • D3を実務で使わなくなるとしても、学ぶ価値はあると思う。このライブラリの核心は、データの投影先とデータ自体の次元が常に異なるという点にある
    たとえば0〜100点の範囲のデータを1920x1080の1080p画面に描くなら、どこかの時点でデータを画面投影に合わせてどうスケーリングするかを決めなければならない
    自分で数学を計算してもよいし、D3のようなライブラリに計算を任せてもよい
    Webでデータを描かないとしても、いつかどこかにデータを描くことになり、そのエコシステムで同じ役割のツールを探すことになるので役に立つだろう
    • 初めて自作したPHPプログラムの1つが、二項分布グラフのPNG生成器だった
      作っていたPNGのサイズに合わせて、グラフに描く四角形をスケーリングする必要があったのを覚えている
      もちろん非常に些細なもので、D3ができる驚くようなこととはまったく違ったが、コンピューターで画像を作り出すものを初めて自分で作った、素晴らしい経験だった
    • 核心概念をつかむよい説明だ
      D3は個人的には直感的だったことがない。あまりにも多くの抽象化レベルで、あまりにも多くのことをしようとしているのが問題なのかもしれない
      単にデータを投影する話なら分かりやすいが、投影が軸やほかの要素とも密接に結び付いているためなのだろう
  • D3の本当の問題は、ライブラリとして実際に可視化してくれるわけではない点だ。自分で可視化を組み立てるための関数と例を提供しているだけで、その中核的な要件はJavaScript、特にクロージャと関数型プログラミングに対する専門家レベルの理解である

mbostock が D3 の中核的な抽象化だと言う selectselect の差分計算は、再入可能な paint() を書くための便利機能に近いと思う
ただ paint 文がビルダー文として表現され、それ自体が select のスコープ内に束ねられ、複数の効果のために分割できるという装飾が付いているだけ
特にアニメーションの例で D3 がやってくれることは驚くほど少なく、外側のループを書き、時間に応じた状態を追跡する作業は自分でやる必要がある
D3 は可視化を関数であれ別の形であれカプセル化する抽象化も提供しておらず、この部分は読者への宿題として残されている
新しい D3 ユーザーにとって、これらすべては大きな驚きや衝撃として映る。新しいデータベースを導入したら、ファイル入出力、B-tree インデックス、クエリ最適化ライブラリだけがあり、全部自分でつなぎ合わせなければならない状況に似ている

  • visx は見てみる価値がある。実際には D4、つまり宣言的データ駆動ドキュメント(Declarative Data Driven Documents)と呼ばれるべきかもしれない
    D3 の DOM 操作モジュールである d3-select を React に置き換えた形。これが可能で、うまく機能するという点が D3 の設計の優秀さを示している
  • D3 は matplotlib や ggplot のようなチャート用ツール集ではなく、データ可視化をゼロから作るための低レベルライブラリ
    目的によって必要な道具にもなるし、そうでない場合もある
  • D3.js が好きで、商用・個人用を含む数十のデータ可視化プロジェクトの中核技術として使ってきた。ただ、今ではレンダリング構文は jQuery 時代を思い出させるほど古く見える
    easing やスケーリングなどの各種補助関数はいまも使っているが、実際のコンポーネントは最近のフレームワークで作っている。自分の場合は Vue 3 と TypeScript
    それでも D3.js がもたらしてくれた美しい時代と、データ可視化における多くの良い実践を教えてくれたことには感謝している
    Mike Bostock のデフォルト値とデモはインスピレーションであり、良い基準の例でもあり、Tufte のミニマリズムともよく合っていた
    • Vue 3 と TypeScript に D3 の補助関数を組み合わせる例があるなら見てみたい
  • D3 を学んだあとは、チャートっぽいものを作るという前提なら、VisX や React ではない同等のツールに移って振り返らないのがよいと思う
    D3 と jQuery はある程度似ていて、どちらもスパゲッティコードになりやすい。VisX のようなツールは、使っている D3 の上に多くの構造を追加し、健全に保ってくれる
    • D3 はかなり長く断続的に使ってきて、今まさに React と visx を始めているところだが、両者のギャップをうまく埋めてくれて有望に見える
      ただ、純粋な D3 を使うときよりも、よりカスタムなものを作るにはツールと格闘しなければならないような制約を感じるのか気になる
  • D3 は Wilkinson のグラフィック文法に着想を得ている
    GG に着想を得たもう一つのツールが、名前も適切な ggplot2 で、R 言語向け
    はるかに簡潔で関数型に近いインターフェースを提供し、CSV をパイプで渡して素早くグラフィックを作れる Rush という珍しいツール、つまりシェル用の R ワンライナーとも相性がよい
  • 完全にWeb ベースではないダイアグラム・チャートソリューションをずっと探している。CLI やライブラリとして動かせて、SVG や PNG を出力できる必要がある
    こうしたツールはたいていブラウザ機能に依存しているか、サーバー側生成のためにヘッドレスブラウザを使う不格好なサーバーサイドレンダリングのソリューションを使っている
    特にプログラムからベン図を生成できるとよい。奇妙なことに、この領域にはほとんど何もない
    いくつかの JavaScript チャートライブラリは対応しているが、全体としては対応がほとんどないように見える
    gnuplot は良さそうだが、ベン図には対応していない
  • この資料だけが D3 を理解させてくれた。作者も反応が早く、よく助けてくれる
  • Vega[1] については良い評判をよく聞いており、D3 の上に載るツール
    OpenSearch Dashboards の依存関係でもあり、ユーザーがログやオブザーバビリティデータの上にカスタムダッシュボードを作れるようにしてくれる[2]
    Vega ライブラリは、他の人たちが言う D3 の学習難易度の問題をある程度和らげられそう
    [1] https://vega.github.io/vega/docs/
    [2] https://opensearch.org/docs/latest/dashboards/visualize/vega...