より良いコーディング方法

翻訳者から：

私はプロのプログラマーでもプロの翻訳者でもありませんが、人気のあるD3.js



作成者からの記事で説明されているツールの外観は、私に強い印象を与えました。



Habréで、そして実際にロシア語を話すインターネットで、このツールが1年以上も不当に無視されてきたことに驚いた。 したがって、私は、特にJavaScriptのプログラミングの技術の発展に貢献する義務があると判断しました。



統合された研究環境であるd3.expressをご覧ください。

（2018年1月31日以降、d3.expressはObservableと呼ばれ、beta.observablehq.comに存在します ）



コードを調べたり、他の人のコードを理解したりしたことがあるなら、あなたは一人ではありません。 この記事はあなたのためです。



過去8年間、情報を視覚化するツールを開発してきました。 私の努力の中で最も成功した結果は、 D3 jsライブラリーでした。 しかし、ツールボックスのこのような長い開発の危険性は、あなたがそれをしている理由を忘れてしまうことです。ツールはそれ自体で終わりになり、その使用の利点は背景に消えつつあります。



視覚化ツールの目的は、視覚化を構築することです。 しかし、視覚化の目的は何ですか？ ベン・シュナイダーマンへの言葉：

「視覚化の結果は 写真ではなくインスピレーション ''

視覚化が重要です。 洞察の鍵。 この世界について何かを考え、理解し、明らかにし、伝える方法。 視覚的な解読を見つけるタスクのみを視覚化で見る場合、重要なデータの検索、クリーニング、効果的な構造への変換、統計分析、モデリング、調査の説明など、他の多くのタスクを無視します...



これらのタスクは、多くの場合、コードを使用して解決されます。 残念ながら、プログラミングは非常に複雑です！ 名前自体はすでに理解不能であることを暗示しています。 「プログラミング」という言葉は、 マシンコード（プロセッサによって実行される低レベルの命令）に由来します。 それ以来、コードはより親しみやすくなりましたが、まだ長い道のりがあります。





攻殻機動隊（1995）



代表的な例として、カリフォルニアの人口密度の背景マップを生成するbashチームがあります。 単純化されたジオメトリを返すだけです。 SVGを取得するには、さらにいくつかのコマンドが必要です。







これはマシンコードではありません。 マシンの観点から見ると、これは非常に高度なプログラミングです。 一方、これは人間の言語とは言えません。奇妙な句読点、理解できない略語、ネストのレベル。 そして、2つの言語：JavaScriptはBashに不自然に織り込まれています。



Bret Victorは、プログラミングのこのような簡単な定義を提供します 。

プログラミングはシンボルのブラインド操作です

「盲目」とは、操作の結果を見ることができないことを意味します。 プログラムを編集し、再起動して結果を確認できます。 しかし、プログラムは複雑で動的なので、編集結果を直接、直接観察することはできません。



「記号」とは、プログラムの出力を直接操作するのではなく、抽象化を使用することを意味します。 これらの抽象化は効果的ですが、制御が難しい場合もあります。 ドナルドノーマンの定義では、これは評価湾と実行湾です 。



ただし、一部のスクリプトは他のスクリプトより読みやすいことは明らかです。 人間以外のコードの症状の1つは「スパゲッティ」です。構造とモジュール性のないコードです。プログラムの一部を理解するには、プログラム全体を理解する必要があります。 これは共有の可変状態によってしばしば引き起こされます。 構造の一部がプログラムのさまざまな部分によって変更される場合、その重要性を推測することは非常に困難です。



実際、プログラムが何をするのかをどうやって知るのでしょうか？ 頭の中のすべての環境条件を追跡できない場合、コードを読むだけでは十分ではありません。 ログ、デバッガー、テストを使用しますが、これらのツールには制限があります。 たとえば、デバッガーは、特定の時点でいくつかの値のみを表示できます。 私たちはコードを理解するのに途方もない困難を経験し続けており、何かが基本的に機能する場合、それを奇跡と認識することができます。



これらの問題にもかかわらず、私たちは今まで以上に多くのアプリケーションのためのコードを書いています。 なんで？ 多分私たちはマゾヒストですか？ （たぶん）取引できませんか？ （部分的に。）本当に良い解決策はありませんか？



一般的に-これは重要な定義です-いいえ。 コードは、私たちが持っているものの中で最も一般的であるため、多くの場合、私たちの武器庫で最高のツールです。 コードの表現力はほぼ無限です。 高レベルのプログラミングインターフェイスや言語など、コードの代替手段は、特定の領域でうまく機能します。 しかし、これらの選択肢は、これらの分野での効率を高めるために汎用性を犠牲にします。



ドメインを決定できない（ドメインを制約する ）場合、コードの実行可能な代替を見つけることができません。 少なくとも人々が主に言語を通して考え、コミュニケーションする限り、普遍的な代替はありません。 科学分野を決定することは非常に困難です。 科学は基本です。世界を研究し、経験的観察から意味を引き出し、システムをモデル化し、定量的な量を計算します。



発見を促進するツールは、新しい独創的な考えを表現できる必要があります。 フレーズテンプレートを使用して書かれた単語を作成しないため、視覚化用のグラフィックテンプレートや統計分析用の式の限定リストに制限することはできません。 構成以上のものが必要です。 独自のデザインを形成するには、プリミティブの構成が必要です。



私たちの目標が人々が観察から洞察を得ることを支援することであるなら、人々がどのようにコードを書くかを考慮しなければなりません。 ビクターが数学について述べたことは、コードに適用できます。

私たちの世界の量的指標を理解し予測するための武器は、抽象的な記号を操作するためのばかげた（奇妙な）トリックに限定されるべきではありません

プログラミングの能力を向上させることは、ワークフローをより便利または効率的にするだけではありません。 これは、人々が自分の世界をよりよく理解できるようにするためです。

Observableの紹介

コードを取り除くことができない場合、少なくともソーセージのような指と脳の大きさの脳を持つ人々にとってそれを簡単にすることができますか？



この問題を明確にするために、私はObservsableと呼ばれる統合された研究環境を構築しています。 データ分析、システムとアルゴリズムの理解、さまざまなプログラミング手法のトレーニングと提示、およびインタラクティブな視覚的説明の共有に役立ちます。 視覚化をより簡単にし、ひいては発見をより簡単にするために、最初にプログラミングプロセスを簡単にする必要があります。



プログラミングプロセスを簡単にするふりはできません。 表現、調査、および説明するアイデアは、非常に複雑な場合があります。 しかし、プログラミングの認知的負荷を減らすことで、より多くの人が利用できる定量的現象の分析を行うことができます。

1.反応性

Observableの最初の原則は反応性です。 一般的な状態を変更するコマンドを発行する代わりに、リアクティブプログラムの状態の各部分が計算方法を決定し、環境がそれらの評価を制御します。 ランタイムは受信した状態を配布します。 一般的な状態を変更するコマンドを発行する代わりに、リアクティブプログラムの状態の各部分が計算方法を決定し、環境自体が評価を制御します。 環境自体が派生状態を伝播します。 Excelで数式を作成する場合、リアクティブプログラミングを行います。



これは、リアクティブプログラミングを説明するためのシンプルなObservableメモ帳です。 ブラウザのデベロッパーコンソールに少し似ていますが、作業内容が自動的に保存され、今後ここにアクセスしたり、他のユーザーと作業を共有したりできる点が異なります。 また、反応的です。







命令型プログラミングでは、 c=a+b



はcをc=a+b



設定します。 これは値の割り当てです。 a



またはb



変更された場合、値をc



再割り当てするまでc



は変わりません。 リアクティブプログラミングでは、 c=a+b



は変数の説明です。 これは、たとえa



またはb



が変化してもa+b



cは常にa+b



等しいことを意味します。 環境自体は現在の値c



維持します。



プログラマーとして、私たちは現在の状態のみを気にしています。 環境自体が状態の変更を管理します。 これはここでは取るに足らないことのように思えるかもしれませんが、大規模なプログラムでは、これにより大きな負担が軽減されます。



研究環境では、いくつかの数字を追加する以上のことを行う必要があります。データを操作してみましょう。 データをダウンロードするには-数年間の Apple株価統計-d3.csvを使用します 。 Fetch APIを使用してGitHubからファイルをダウンロードし、解析してオブジェクトの配列を取得します 。







require（ 'd3'）およびデータ要求は非同期です。 命令型コードが問題になる可能性がありますが、ここで明確に気付きました。「d3」を参照するセルは、データがロードされるまで計算されません。



反応性とは、ほとんどの非同期コードを同期のように記述できることを意味します。



データはどのように見えますか？ 見てみましょう：







d3.csvは保守的であり、数値や文字列などのデータ型に関する結論を導き出さないため、すべてのフィールドは文字列です。 より正確な型が必要です。 「+」演算子を適用して「close」フィールドを数値に変換し、すぐに効果を確認できます。紫色の線が緑色の数値になります。







日付を盗むには、JavaScriptがこの形式をネイティブにサポートしていないため、もう少し作業が必要です。



文字列を解析して「Date」エンティティを返すparseTime関数があるとします。 彼女に電話したらどうなる？







おっと！ エラーを投げました。 ただし、エラーはローカルおよび一時的なものです。他のセルは影響を受けず、parseTimeを定義すると消えます。 したがって、Observableのノートブックはリアクティブであるだけでなく、構造化されています。 グローバルエラーはなくなりました。



parseTimeを定義すると、再びデータがリロードされ、解析されて表示されます。 私たちはまだ抽象記号を操作していますが、少なくともやみくもにそれをやっていません。







これで、たとえば、時間範囲を計算するためのデータを要求できます。







ああ、データに名前を付けるのを忘れていました！ それを修正しましょう：







ここでは、もう1つの「人間」機能を見つけます。セルは任意の順序で記述できます。

視覚的結論

開発者コンソールと同様に、Observableでセルを実行した結果は、コードのすぐ下に表示されます。 ただし、コンソールとは異なり、Observable cellはグラフィカルユーザーインターフェイスを表示できます！ シンプルな折れ線グラフでデータを視覚化しましょう。



まず、チャートのサイズを決定します：幅、高さ、マージン。







スケールは 、xに対して一時的で、yに対して線形です。







そして最後に、SVG要素。 この定義は以前のセルよりも複雑であるため、中括弧（{and}）を使用して、式ではなくブロックとして定義できます。







DOM.svgは、 document.createElementNSを便利に呼び出すためのメソッドです。 特定の幅と高さを持つ新しいSVGノードを返します。 d3-selectionを使用してDOMを操作するように拡張してみましょう。





画面サイズが制限されているため、コードとグラフを同時に表示することはできません。そのため、最初に作成するグラフを見てみましょう。 これにより、グラフの3つの主要コンポーネントであるx、y軸、および線を識別するときに得られる視覚的なフィードバックの感覚が得られます。







このアニメーションは、コードの各行を順番に入力することによって行われました（すべてを見るために必要なので、リターンを除く）。







これは単純なスケジュールですが、プログラムのトポロジはすでに複雑になっています。 以下は、 GraphVizを使用してObservable自体で作成された有向非循環リンクグラフです。







ノード93はSVG要素です。 いくつかの観察：このグラフを反応させるのは非常に簡単です。 オブジェクトの幅、高さ、およびマージンは定数ですが、それらが動的である場合、軸とグラフ自体は自動的に更新されます。 同様に、データを再定義することでチャートを動的にすることも簡単です。 これは、ストリーミングデータの例ですぐにわかります。



しかし、リアクティブコードを詳しく見てみましょう。 命令型プログラミングでは、変数の定義は1か所で行われるのではなく、コード全体に広がります。 たとえば、ページを読み込んだ直後にxスケールのスケーリングを収集できますが、データを受信するまでドメイン定義を延期できます。







このような断片化された定義は、他のデータでシャッフルされ、コードの純度に影響を与える可能性があります。 また、再利用を支持します。自己完結型のステートレス定義は、他のドキュメントにコピー/インポートするのが簡単です。



HTML、キャンバス、WebGLなど、あらゆる種類のDOMを作成でき、あらゆる種類のライブラリを使用できます。



Vega Liteを使用して作成されたグラフは次のとおりです。

アニメーション

キャンバスはどうですか？ 地球が必要だとしましょう。 世界の国々の国境を 積み込み 、 正射影を適用できます。





（ メッシュは、興味がある場合、破線で表された結合された境界線です。このデータセットにはポリゴンが含まれているため、メッシュメソッドを使用します。







リアクティブプログラミングの強力な機能は、固定サイズの直交投影などの静的な定義を、回転投影などの動的な定義にすばやく置き換えることができることです。 環境自体は、投影が変更されるたびにキャンバスを再描画します。







Obsesrvable dynamic variablesはgeneratorsとして実装され、複数の値を返す関数です。 たとえば、while-trueループを持つジェネレーターは、値の無限ストリームを生成します。 環境は、アクティブな各ジェネレーターから新しい値を1秒あたり最大60回抽出します。





（60 FPSでより良く見える）



キャンバスの定義は、開始するたびに新しいキャンバスを作成します。 これは許容できるかもしれませんが、キャンバスを再処理することでパフォーマンスを向上させることができます。 変数の以前の値はthis



として表示されthis



。







ああ！ 古いcanvas



を使用して、グローブをぼかします。





グリッチは、再描画する前にcanvas



クリーニングすることで簡単に修正できます。







したがって、物事を少し複雑にすることで、パフォーマンスを向上させることができます。また、生成されるアニメーションには、通常のJavaScriptと比較してわずかなオーバーヘッドがあります。

相互作用

ジェネレーターがアニメーションシナリオに適している場合、相互作用はどうですか？ ジェネレーターが再び役立ちます！ ジェネレーターは非同期になり、新しい入力が表示されるたびに解決されるプロミスを返します。



回転をインタラクティブにするために、まず範囲入力を定義しましょう。 次に、ジェネレーターに接続します。ジェネレーターは、入力が変更されるたびに現在の値を提供します。 このジェネレーターは手動で実装できますが、 Generators.input



と呼ばれる便利な組み込みメソッドがあります。







次に、インタラクティブグローブの回転の経度として値を代入します。







これは、ユーザーインターフェイスの簡単な定義です。 ただし、Observable viewof



演算子を使用してrange



とangle



定義を1つのセルに折り畳むことで、さらに減らすことができます。 ユーザーへの入力が表示されますが、コードについては現在の値が表示されます。







任意のDOMを表示し、コードに任意の値を設定する機能により、Observableのインターフェースが非常に良くなります。 スライダーとドロップダウンメニューに限定されません。 これは、各カラーチャネルに1つずつ、スライダーテーブルとして実装されたCubehelixカラーピッカーです。







スライダーをドラッグすると、対応する出力の値が更新され、ジェネレーターが現在の色を表示します。







必要なグラフィカルインターフェイスを作成できます。 そして、その意味をコードに提示するスマートプログラミングインターフェイスを設計できます。 これにより、データを調査するための強力なインターフェイスをすばやく作成できます。 これは、5年間の数百株の行動を示す棒グラフです。 （コードを短縮しましたが、 このように見えます。）







他の環境では、このようなヒストグラムは視覚的な行き止まりになります。 確認できますが、基本的な値を確認するには、コード内のデータを個別に要求する必要があります。 Obsesrvableでは、視覚化をすばやく補完し、選択範囲をインタラクティブに表示できます。 その後、直接操作することでカーソルの下のデータを見ることができます。







デフォルトのオブジェクトインスペクターを使用しますが、たとえば、ライブ合計、リアルタイム統計、または関連する視覚化など、何でもインタラクティブに実行できます。







これが魔法ではないことを示すために、上記のコードはd3-brushをObsesrvableに適合させるためのものです。 brush



イベントによって、新しいフィルター処理されたデータを計算し、SVGノードの値として設定し、入力イベントを送信します。

アニメーション化されたトランジション

デフォルトでは、反応は即座に発生します。変数値が変更されると、ランタイムは派生変数を再カウントし、すぐに表示を更新します。 しかし、そのような緊急性は常に必要とは限らず、オブジェクトの現実を感じるために遷移をアニメーション化することが時々有用です。 ここでは、たとえば、列が再ソートされたときにそれを追跡できます。







この図の実装を理解するには、D3に精通している必要があります。つまり、キー関連のデータと段階的な移行が必要ですが、このコードが不透明であっても、今日のオープンソースライブラリがObsesrvableで簡単に使用できることを示してほしいです。

2.可視性

プログラムの視覚的な出力は、プログラムの現在の状態をよりよく把握するのに役立ちます。対話型プログラミングは、入力、変更、削除、順序の変更、および何が起こっているかを観察することにより、プログラムの動作をより徹底的に分析するのに役立ちます。



たとえば、下のチャートのコメントから拘束力を削除すると、図の全体的な配置に対するそれらの寄与をよりよく理解できます。





（YouTubeでこれをどのように再生するかを



見てください。）同様のおもちゃを見たことがあるはずです。たとえば、Steve Harozはd3-force用のすばらしいサンドボックスを持っています。ここでは、再生用のユーザーインターフェイスを作成する必要はありません。インタラクティブプログラミングが無料で提供されます。

アルゴリズムの可視化

プログラムの動作を調査するためのより詳細なアプローチは、内部状態を表示するコードを補足することです。ジェネレータもここで役立ちます。このような通常の関数を使用して、数値の配列を合計します。







そして、最後に通常の戻り値に加えて、実行時にローカル状態を返すジェネレーターに変換します。







次に、動作を理解するために、内部状態を視覚化または確認できます。このアプローチは、アルゴリズム内の視覚化コードを直接実装するのではなく、アルゴリズムの実装とその調査を明確に分離します。







例として、D3 circlesの 階層的なパッキング構造を見てみましょう。







南極大陸のペンギンのクラスターのように、重なり合うことなくできるだけ小さなスペースに詰めたい円のセットがあります。私たちのタスクは、すべての円が配置されるまで、円を1つずつ配置することです。



円をできるだけ密に詰めたいので、配置するすべての円が少なくとも1つ（実際には2つ）の既に配置した円に接触する必要があることは明らかです。ただし、既存の円を接線円としてランダムに選択した場合、パッケージの中央に新しい円を配置するのに多くの時間を費やし、そこで他の円と重なります。理想的には、パッケージの外側にある円のみを考慮します。しかし、どの円が外にあるのかを効果的に判断するにはどうすればよいでしょうか？







Wangアルゴリズムは、これらの同じ外側の円を表す赤で示されている「外側のチェーン」をサポートしています。新しい円を配置するとき、彼は最初に最も近いフロントチェーンの円を選択します。新しいサークルは、このサークルとそのフロントチェーンネイバーの隣にあります。



この配置がフロントチェーンの他の円と重ならない場合、アルゴリズムは次の円に進みます。重なる場合は、接線円と重なる円の間のフロントチェーンを切断し、重なる円が新しい接線円になります。重複がなくなるまでこのプロセスを繰り返します。







このアニメーションは魅力的です。よく見ると、フロントチェーンが切り取られたときに、大きな円がパッケージから押し出された瞬間が表示されます。これは目に優しいだけでなく、D3の実装における長年のエラーを特定するのにも非常に役立ちます。



円を組み立てたら、階層構造で円形のパッキングを繰り返すことができるように、パッケージの円周を計算する必要があります。これを行う通常の方法は、原点から最も遠い円のフロントチェーンをスキャンすることです。これはかなり適切な仮定ですが、正確な仮定ではありません。幸いなことに、計算用のWelzlアルゴリズムの簡単な拡張があります線形時間における最小の閉じた円。







Waelzアルゴリズムがどのように機能するかを確認するために、一部の円の外側の円が既にわかっていて、その中に新しい円を含めたいとします。新しいサークルが現在のサークル内にある場合、次のサークルに進むことができます。新しいサークルが悪循環の外側にある場合、サークルを拡大する必要があります。





サークルが悪循環の外側（左）にある場合、新しい外側のサークル（右）に触れる必要があります。



ただし、この新しい円についてはわかっています。外側の円の外側にある唯一の円であるため、新しい外側の円に触れる必要があります。そして、外側の円の接線円を見つける方法を知っていれば、他の円を再帰的に見つけることができます！



少しジオメトリがありますが、私はもちろん少しハックしています。また、再帰の境界ケースを計算する必要があります。1つ、2つ、または3つの接線の外側の円。 （これはアポロニウスの問題です）ジオメトリは、3つ以上の接線円がないこと、または環境にすでにすべての円が含まれていることを指示しているため、再帰アプローチが最終的に終了することがわかります。



スタックを示す、より完全な再帰アルゴリズムの概要を次に示します。







左側は最高レベルで、タッチする円のセットは空です。アルゴリズムは、新しい円が円の外側にあるたびに繰り返されます。再帰の間、この新しい円は、それと接触する円のセット上に置かれなければなりません。そのため、左から右へ、黒で網掛けされた0、1、2、3つの連続した円があります。



アルゴリズムの仕組みの説明に加えて、このアニメーションは、アルゴリズムがさまざまな再帰レベルで費やしている時間の感覚を与えます。円をランダムに処理するため、囲む円は急速に拡大し、最終的な回答を近づけます。しかし、それが繰り返されるたびに、以前のすべての円を再確立して、それらが新しい周囲の円に収まるようにする必要があります。

3.再利用性

少ないコードを記述する1つの方法は、再利用することです。 npmで公開された440,000個程度のパッケージは、このアプローチの人気を証明しています。



しかし、ライブラリは積極的な再利用の例です。再利用のために意図的に設計する必要があります。そして、これは大きな負担です。効果的な一般的な抽象化を開発するのは十分に困難です！ （オープンソースの開発者に連絡してください。）D3の例でよくあるように、ワンタイムコードの実装は、タスクの抽象クラスではなく特定のタスクのみを考慮する必要があるため、簡単です。



Observableでより良い受動的再利用ができるかどうかを考えています。リアクティブドキュメントの構造を使用すると、このコードが再利用のために特に設計されていない場合でも、コードを簡単に再構成できます。



手始めに、あなたは事実上ノートブックをライブラリと見なすことができます。あるノートブックでカスタムカラースケールを実装するとしましょう







。別のノートブックでは、このカラースケールをインポートして使用できます。







インポートは、アイデアを探索するために多くのノートブックを作成し、それらを1つのブロックに結合する場合にも役立ちます。



さらに興味深いことに、Observableを使用すると、インポート時に変数の定義を再構築できます。ここでは、リアルタイムデータからWebSocketを介してストリームを定義します。 （繰り返しますが、このコードの詳細は重要ではありません。簡単にするために、想像上のライブラリを想像することができます...）







このデータセットは、以前の折れ線グラフと同じ形状をしています：時間と値を持つオブジェクトの配列。このチャートを再利用できますか？うん！演算子をwith



使用すると、インポートした変数にローカル変数を入力して、元の定義を置き換えることができます。







動的データを以前の静的ダイアグラムに挿入できるだけでなく、必要に応じて座標軸をスケーリングすることもできます。ここでは、軸のドメインを変更x



し、y



データのための適切なサイズに。軸にx



は、最後の60秒程度が表示されます。







新しい定義を追加x



し、y



オペレータにwith



、スケジュールは現在、60 FPSに滑空し、軸がy



痙攣を邪魔していません。

4.移植性

観察可能なノートブックは、デスクトップアプリケーションやクラウドではなく、ブラウザで動作します。スクリプトを保存するためのサーバーがありますが、すべての計算とレンダリングはクライアントでローカルに行われます。ウェブ上に研究環境があるとはどういう意味ですか？



Web環境は、バニラJavaScriptやDOMなどのWeb標準をカバーしています。インターネットまたはnpmで公開されているライブラリで見つかったコードの断片に関係なく、オープンソースで動作します。これにより、新しい環境で生産的に作業するために必要な専門知識が最小限に抑えられます。



Observableには反応性のための新しい構文がありますが、たとえばジェネレーターを使用するなど、できるだけ小さくて使い慣れたものにしようとしました。これらは、変数定義の4つの形式です。







標準ライブラリも最小限であり、プラットフォーム固有ではありません。既存のコードと知識をObservableに取り込むことができ、その逆も同様です。コードと知識をObservableから取得します。



Web環境では、ブラウザーで動作するため、コードはどこでも動作します。何もインストールする必要はありません。他の人が分析を繰り返して検証しやすくなります。さらに、研究用のコードは、説明用のコードにスムーズに移行できます。アイデアを共有したいときは、最初から始める必要はありません。







ジャーナリストと科学者がデータとコードを共有しているのは素晴らしいことです。ただし、GitHubのコードは必ずしも簡単に実行できるとは限りません。必要な環境、オペレーティングシステム、アプリケーション、パッケージなどを再現する必要があります。コードが既にブラウザーで実行されている場合、他のブラウザーで実行されます。そして、これがインターネットの美しさです！



分析用の移植性の高いコードを作成すると、コミュニケーションスタイルに影響を与える可能性があります。私は再びビクターを引用します：

積極的な読者は質問をし、代替案を検討し、仮定を疑問視し、さらに著者の信頼性に疑問を呈します。積極的な読者は、特定の例を要約し、一般化のための具体的な例を考えます。積極的な読者は情報を受動的に吸収しませんが、著者の議論を批判的思考と深い理解のための踏み台として使用します。

PS



オブザーバブルの設計を手伝いたいなら、それは素晴らしいことです！私に連絡してください。私のGitHub プロファイルで私のメールアドレスを見つけて、Twitterで私に連絡できます。



beta.observablehq.com



読んでくれてありがとう！