DEV Community: Origami

Promise/async関数でthrowとtry~catchはやめておこう

Origami — Tue, 11 Feb 2020 06:32:16 +0000

こんにちは。Twitterで完全に俺の意見ということが判明しましたが、残しておきます

async関数の場合

const f1 = async () => {
  return await Promise.reject(new Error("e"));
};

const f2 = async () => {
  throw new Error("e");
};

f1()
  .catch(e => console.log(e));


try {
  f2();
} catch (e) {
  console.log(e);
}

さて、間違っている箇所がわかるでしょうか？

実行すればすぐにわかることですが、async funcitonの中で投げられた例外はPromise.prototype.catch()でないと受け取ることができません。そもそもこのような間違いを犯さないためにも、Promiseの中のエラー送出はPromise.reject()を利用すべきです。

Promiseの場合

前を踏まえれば当然次のようなコードになります。

const f1 = () => new Promise(() => {
  throw new Error("e")
})

const f2 = () => new Promise((resolve, reject) => {
  reject(new Error("e")
})

f1().catch(e => console.log(e));

f2().catch(e => console.log(e));

終わり。asyncの中でthrow new Error()、asyncの利用側でtry~catchはやめておきましょう。

PWAで動いてる？isPWA();

Origami — Tue, 28 Jan 2020 16:41:25 +0000

JavaScript

ChromeとFirefox、iOS Safari 13以降であれば次の方法が可能です。詳しい利用可能状況はcaniuseで。

https://caniuse.com/#search=display-mode

(window.matchMedia('(display-mode: standalone)').matches
// true: working on PWA
// false: not working on PWA

iOS Safari 12以前ではdisplay-modeを利用できないので、次の方法を利用します。

window.navigator.standalone
// true: working on PWA
// undefined: not working on PWA

CSS

CSSではdisplay-mode media queryを利用すればPWAで動いているかどうかでスタイルを変更できます。

@media all and (display-mode: standalone) {
    // styles for PWA
}

Don't use custom hooks as like global state

Origami — Fri, 24 Jan 2020 17:06:36 +0000

yes. look this.

const useInvalidHooks = () => {
  const [state, setState] = useState(false);
  const handler = useCallback(() => {
    setState(true);
  }, []);

  return [state, handler];
};

export default function ParentComponent() {
  const [state] = useInvalidHooks();
  console.log(`parent: ${state}`);
  return (
    <div>
      <InnerComponent />
    </div>
  );
}

function InnerComponent() {
  const [state, handler] = useInvalidHooks();
  console.log(`children: ${state}`);
  return <button onClick={handler}>hai</button>;
}

Click button in InnerComponent. And if you think update ParentComponent const [state] = useInvalidHooks, its wrong.
This code is equivalent to the following code.

export default function ParentComponent() {
  const [state, setState] = useState(false);
  const handler = useCallback(() => {
    setState(true);
  }, []);

  console.log(`parent: ${state}`);
  return (
    <div>
      <InnerComponent />
    </div>
  );
}

function InnerComponent() {
  const [state, setState] = useState(false);
  const handler = useCallback(() => {
    setState(true);
  }, []);

  console.log(`children: ${state}`);
  return <button onClick={handler}>hai</button>;
}

it's obvious.

custom hooks may misunderstanding: custom hooks is globally... isn't it.
custom hooks is locally.

If you need global state on custom hooks, use context api. or redux...

そのContext呼び出しはProvider以下にあると保証できますか？

Origami — Fri, 24 Jan 2020 16:31:49 +0000

はい

reactのcontextは便利です。Reduxキラーとして君臨し、多くの開発者を苦しめてきました。特にhooksが登場してからというもの、useContext()によりその利便性はさらに高くなりました。

const {data} = useContext(DataContext);

あるいは

<DataContext.Consumer>
    {({data}) => /* render something */}
</DataContext.Consumer>

さて、このときDataContext.Provider以下でこれらが呼び出されることを保証できるでしょうか？結論から言うとできません。TypeScriptにおいても同様です（そりゃそうだ）
ちなみに、ProviderがなければcreateContextのデフォルト値がそのまま利用できます。

const DataContext = createContext({ hai: "haijanaiga" } as
    {
        hai: string
    });

export default App: React.FC = () => {
  const data = useContext(DataContext);
  return <h1>{data.hai}</h1>;
}; // its equally `<h1>haijanaiga</h1>`

しかし、たいていの場合において<Context.Consumer />およびuseContext()はProvider以下で呼びたいことが殆どでしょう。
しかし、Reactはこのときエラーになってくれません。デフォルト値が存在するためです。
また、ほとんどの場合開発時にのみ問題になりうるものですから、そのときにエラーになってくれればよいものです。すると、次のようなコードを書くことになるでしょう…

type SomeContextType = {
    hai: string
}

const DataContext = createContext(undefined as undefined | SomeContextType);

const DataProvider = DataContext.Provider;

const useDataCtx = (): SomeContextType | never => {
    const ctx = useContext(DataContext);
    if (!ctx) throw new Error("Not children of DataContext.Provider")
    return ctx;
}

このとき、<DataProvider state={{hai: ""}}>がない状態でuseDataCtx()が呼び出されても、適正にエラーが送出されるため、健全性が高まると言えます。
あるいは、非同期処理を利用などの理由でわざとundefinedを挿入しているとしても、if (typeof ctx === "undefined")などで代替し、読み込みの状態についてはnullを注入することもできます。もっとも、nullを注入するような行為は健全性に欠けますが…
単純に考えましょう。読み込み中であるstateたとえば{suspending: true}をProviderに注入する方法が効きます。

ところであなたのContextは健全ですか？

custom hooksをグローバル変数みたいに扱わないで

Origami — Thu, 23 Jan 2020 09:43:51 +0000

english: https://dev.to/origamium/don-t-use-custom-hooks-like-global-state-dda

はい、まずこのコードを見てください。


const useInvalidHooks = () => {
  const [state, setState] = useState(false);
  const handler = useCallback(() => {
    setState(true);
  }, []);

  return [state, handler];
};

export default function ParentComponent() {
  const [state] = useInvalidHooks();
  console.log(`parent: ${state}`);
  return (
    <div>
      <InnerComponent />
    </div>
  );
}

function InnerComponent() {
  const [state, handler] = useInvalidHooks();
  console.log(`children: ${state}`);
  return <button onClick={handler}>hai</button>;
}

このとき、InnerComponetのbuttonを押下したさい、その親であるParentComponentでstateの変更と更新を期待していると、ものの見事に打ちのめされます。変更されません。
経験豊かなReactエンジニアにはその理由はすぐわかると思います。

はい、理由は生成されたhooksは他のhooksの状態とは完全に別ですからです。私はこれに2時間ぐらい悩みましたが…

webpack-dev-serverでdisableHostCheckを使うのはもうやめろ

Origami — Mon, 23 Dec 2019 09:41:34 +0000

TL;DR

DO NOT USE disableHostCheck. because its potentially vulnerable.
USE host: "0.0.0.0 and useLocalIp. its safe, for now.

ハローこんにちは。disableHostCheck: trueを使うのをやめろ。

disableHostCheckを使うのにはだいたい理由があって、たとえばiPhoneからPC上のlocalhostで動いているサイトを見たいという理由でdisableHostCheckをtrueにしたりしてアクセスしたりします。

[マシン名].local:[ポート番号]でアクセスするのはiPhoneを使った開発ではよく見る光景ですね。このときdisableHostCheckはだいたいInvalid Host headerを回避するために使います。

しかし、disableHostCheckを有効にするとDNS rebinding attack脆弱性を抱えてしまいますし、実際に webpack-dev-serverのdocumentationでも非推奨 の方法となっています。
代わりに今の所、useLocalIP: trueを使えば解決することができます。

config.devServer = {
    host: "0.0.0.0",
    useLocalIp: true,
}

host: "0.0.0.0"はないと動かないので注意。
この方法を使えばdisableHostCheckを回避できます。自分のローカルIPアドレスを使ってやればアクセスできるので、ネットワークによってURLは変更されますが。

Houdini初心者のためのローレンツ方程式の数値解導出とビジュアライズ

Origami — Wed, 18 Dec 2019 18:32:23 +0000

CPSLab Advent Calendar 2019 20日目の記事です。

みなさんは プロシージャル（手続き的） な3Dモデリングの経験があるでしょうか。この記事はプロシージャルモデリングの手法でローレンツ方程式の計算の過程を解説します。

プロシージャルな手法

ググれば腐るほど詳細が出てきますが、ソフトウェアエンジニアの方々ならば「プロシージャルな手法」という言葉に魅了的な響きを感じるものがあるのではないでしょうか？
あまりピンとこなかった方にピンとこないであろう解説をすると、 （数学的な意味も含む）関数の組み合わせ によってモデルを生成するという手法です。

これを実用的なものに落とし込んだものが、プロシージャルな手法でマテリアル（テクスチャ）を作成するSubstance Designer、そして今回紹介・使用するHoudiniです。

Houdiniとは？

プロシージャルモデリングを恐らく最も積極的に行っているソフトウェアであり、水や煙、炎におけるビジュアルエフェクトについて強力なソリューションを有しているソフトウェアです。
試用については無料であり、開発元のSideFXのページからApprentice版を無期限かつ無料利用することができます（制限はありますが、今回は全く問題にならないため省略します）。

インストールすると最上位ライセンスであるHoudini FXなど全部のライセンスバージョンがインストールされますが、起動するのはHoudini Apprenticeです。

今回の目標

次のようなモデルが出力されることをゴールとしています。

よく目にするローレンツ方程式の図ですね。今回はローレンツ方程式が表現する状態を求めることまでを目標にします。ローレンツ方程式についてはググればたくさん出てきますが、難しいことはさておいて以下の方程式で与えられます。

Houdiniことはじめ

まず、Houdiniの細かいUIはさておくとして、プロシージャルモデリングを実施するにあたりHoudiniはノードベースのエディタを利用します。その中で今回利用するノードは大きく分けて SOP(Surcace OPerator 、 Wrangle 、SOP Solver の3種類です。また、Houdiniのプログラミング言語として VEXpression を利用します。
恐ろしいことにHoudiniではこれ以外にもノードの種類があり、プログラミング言語においてはHScript(deprecated)やPython、C++を使う機会も存在しますが、今回は使いません。

SOP

まず先にSOPから説明します。Surface OPeratorの通り、サーフェスに対して行う処理です。が、頂点や辺、点に対してもオペレーションが行われます。これらはそれらを作成する、あるいは変更を加えるものがあります。また、出力や状態を司るものまで多種多様揃っています。まるでRxのようです

基本的に、ルートのノードでは作業を行わず、 Geometry ノード以下で行います。この関係はディレクトリ構成とよく似ています…

ノードエディタ（デフォルトでは画面右下）にフォーカスした状態でTabキーを押下し、geoまで入力するとGeometry SOPが候補に上がります。今回はこれを利用します。
Enterを2回押下し、ノードを配置します。
そしてgeo1ノードをダブルクリックし、ノードの中に入ります。これはサブウィンドウ右上の戻る進むボタンからいつでも上の階層あるいは下の階層に戻ることができ、さながらディレクトリのようです。

たとえば正多面体を生成するPlatonic Solid SOPです。こちらはgeo1ノードに入った状態でふたたびTabキーを押下し、platonicまで押下すると候補が出てくるので、やはり同じように配置します。

このSOPのふるまいはデフォルトの画面右上のアトリビュートエディタから変更可能です。たとえば、デフォルトではSolid TypeがTetrahedron（正三角錐）ですが、画像ではDodecahedron（十二面体）に変更しています。この他にもPlatonicではありませんが、サッカーボールやUtah Teapodなどが選択できます（Utah Teapodは有名ですよね！）

では、Utah TeapodからSOPの強力な機能を見ていきましょう。Platonic Solid SOPにおけるUtah Teapodは（恐らく）NURBSサーフェスの集合ですが、これをポリゴンに変更してみましょう。
手法はおそろしく簡単で、Platonic SolidからConvert SOPノードに接続するだけです。Convert SOPを作成し、Platonic SolidからConvertへ接続し、Convertノードの一番右側、マウスホバー時に青色になる部分をクリックすればポリゴン化されたUtah Teapodが出現するはずです。

あっというまです…このとき、Convert SOPにフォーカスした状態でアトリビュートエディタのU, Vの値を変更すると、それぞれの方向についてポリゴンがどれほどの密度になるのかを変化させることができます。

このとき、ノードを削除あるいはバイパス（ノード左の黄色になる部分を有効）にすれば瞬時にそのオペレーションは無視された状態のオブジェクトが生成されます。

また、数学的な側面も存在します。IsoSurface SOPでは、Implicit Surface（陰関数曲面） 注:正式な和訳を知りません… の描画が行えます。

デフォルトでは球が描画されます。アトリビュートエディタのImplicit Functionを見ると、球の描画に使われるx^2 + y^2 + z^2 - 1 = 0の左辺がそれとなく表現されていますね！このままでは不便なポリゴンなので、Remesh SOPを用いるとメッシュが再構成されます。

ほんの片鱗ですが、これがHoudiniの強力さのあらわれです。ほかにもたくさんの種類のSOPが存在し、それらは非破壊的に行われます…つまり、もとのオブジェクトに変更は一切かかっていないということです（いつでももとに戻せます！）

そして、重要なSOPに、Group SOPが存在します。

これは要するにpointやedgeを選択したものを保存しておくSOPですが、この後のSOPなどでこのGroupを指定してそこだけ効果を適用する、などという器用なことが可能になります。この場合入力したサーフェスのpoint番号1から100までのポイントをGroup1として保存しています。

WrangleノードとVEXPression(VEX)

WrangleノードはPoint Wrangle, Attribute Wrangleなど各種ありますが、どれもVEXpressionというプログラミング言語を利用したSOPです。種類によりますが、たとえばAttribute Wrangleはアトリビュートの調整を行うSOPです。

注：このままでは見づらいので、上記の図では線をポリゴンチューブにするWire SOPを利用しています

このサンプルのために、まずはLine SOPを作成し、アトリビュートのLengthを10に設定します。このノードをResampleノードに接続し、Lengthを0.01に設定します。そしてAttribute Wrangleに接続し、次のコードをアトリビュートエディタ内のコードエディタに記述します…

@P.x = 0;
@P.z = float(@ptnum) / 100;
@P.y = sin(radians(@ptnum));

ソフトウェアエンジニアの方へ…セミコロンでの文の終端から、floatへの型キャスト、関数呼び出しなど、見慣れたオペレータ群が揃っていますね！

セミコロンは文の終端にないとエラーになります。ご注意！

しかし、暗黙的に利用されているアットマーク開始の変数たちにフォーカスする必要がありますね。まず、@Pが何なのかについて解説する必要があるでしょう。これはWrangleが処理しているポイントのひとつを指しており、x, y, zのプロパティを持っています。そして@ptnumは現在のポイントの番号を指しています。

これらをなんとなく理解するために、Attribute Wrangleにフォーカスし、メインの画面からGeometry Spreadsheetを開きます…そこは地獄のようです

落ち着いて見ていきましょう。@Pの持つ値が一覧として表示されています。これらをアトリビュートと呼び、これらの値に代入することでアトリビュートを変更しています。また、アトリビュートは任意にジオメトリに挿入することができます。

f@amount = @ptnum;

fは浮動小数点であるfloatを表しており、float型としてamountを定義し@ptnumの値を代入しています。これをAttribute Wangleに代入すると、Geometry Spreadsheetにamountの項目が追加されていることに気がつくでしょう。これは値を保存し、後々のWrangleで利用したいときに便利です。

SOP Solver DOP

SOP Solver DOPは特殊で、アニメーションにおいて（画面下のタイムラインに関することです）、前のフレームを参照して現在のフレームを作成するDOPとなっています。

…いきなりDOPという言葉が出てきましたね。もう面倒になっているのであまり解説しませんが、Dynamic Operator nodeの略です。文字通りダイナミックに変化するものに対して使えるオペレータですが、私はこれ以外のDOPを知りません…

たとえばsin波をアニメーションしてみましょう。先ほどのネットワークからWrangleを削除し、次のようにSOP Solverを配置します。

そして、SOP Solverにダブルクリックし、SOP Solverの中に入ります。

SOP Solverのネットワークは至極単純です。前のフレームを表すPrev_Frameノード、そしてSOP Solverにつないだ入力4つのノードです。

今回はPrev_Frameを主に利用します。Prev_FrameにAttribute Wrangleを繋ぎ、次のコードを挿入します。

@P.x = 0;
@P.y = sin(radians(@Frame*10 + 500 * @ptnum / 1000));
@P.z = float(@ptnum) / 100;

そして、ウィンドウ左下の再生ボタンをクリックします。するとサイン波が横に移動している（ように見える）でしょう。

青色の部分が計算（キャッシュ）済みの部分です。ここの部分については計算なしで再生できますが、より複雑な計算をSOP Solverで利用するとメモリが枯渇しがちです。

もし計算が重くて、動かなくなってしまった場合、Escキーを押下することで計算をキャンセルできます。覚えておくと便利です。

さあ、ローレンツ方程式を計算しよう！

Add SOPで始点を作成

Add SOPは何かと便利なものですが、ここではローレンツ方程式を計算するに当たり、始点をひとつ登録するだけのことをします。
アトリビュートエディタでPointタブを開いた状態で、始点を0.1, 0.1, 0.1にし、チェックボックスを有効化して点を登録します。

last Groupを作成する

ここでは何も選択せず、group nameをlastにします。これで後ほどlast groupを利用することができます。今の所、中身は空っぽですが…

Solver SOPを作成する

Solver SOPを作成し、中に入りPrev_FrameにAttribute Wrangleを作成します。このとき、WrangleのGroupをlastに設定します。これは"last" Groupにのみこの処理を行うという意味です。この効果は後ほど。

そして、Wrangleは次のようにコードを記述します。

float dx(vector Point) {
    float p = 10.0;
    return p*(Point.y - Point.x);
}

float dy(vector Point) {
    float r = 28.0;
    return Point.x*(-Point.z + r) - Point.y;
}

float dz(vector Point) {
    float b = 8.0/3.0;
    return Point.x * Point.y - b * Point.z;
}

float dt = 0.01;

int newpointnumber = addpoint(geoself(), @P + set(dx(@P), dy(@P), dz(@P)) * dt);
setpointgroup(geoself(), "last", @ptnum, 0);
setpointgroup(geoself(), "last", newpointnumber, 1);

関数の宣言と実装、返り値についてはここで語るまでもないでしょうが、念の為解説をします。

float dx(vector Point) {
    float p = 10.0;
    return p*(Point.y - Point.x);
}

この関数dx()はvector - つまりx,y,z3つの座標(float)を持つ型を受け取り、その値についてfloat型の値を返す関数です。中身の計算については、かつて上に示したローレンツ方程式の一式目とほぼ同様なことが伺えます。
ローレンツ方程式については2式目、3式目についても同様の関数を作成します。 - これがこの処理の中核をなします。

ですが、まだいくつかのことについても解説が必要ですね。
set()関数は与えられた引数の数にもとづいて vector2, vector, vector4, matrix型の値を返す関数です。今回は3つの引数が与えられているため、vector型の値が返ってきます。

geoself()関数は処理している自分自身のジオメトリ番号を示しています。この場合ジオメトリは1つしかありませんから、0です。そのためgeoself()の代わりに0でも差し支えありません。

addpoint()関数はジオメトリに文字通り点を追加し、追加された点の番号を返却します。返却された点番号はint型です。

ここで最も肝要なのは、setpointgroup()関数です。これはpointをどのグループに属させるのかという選択の関数であり、引数は対象となるジオメトリ番号（*注:この関数は現状、0以外を受け取りません)、グループ名、ポイント番号、そして選択されている1かされてないか0をとります。

ここで@ptnumは現在処理しているポイントを指しており、これは"last"グループから非選択とします。そして、新しく生成されたポイントであるnewpointnumberを選択としています。

この"last" Group指定は重要です - このWrangleは最初に"last"グループに対して処理するという宣言をしました。"last" Groupが継続的に変化することによって、最後のポイントに対してのみ処理を行えるのです。

経過確認

ここまでの処理を終えたら、一旦上の階層にまで戻り、SOP Solverを可視状態にし、再生ボタンを押します。
ローレンツ方程式が求まっていく様子が確認できると思います。

tips: アニメーションが短すぎてよくわからない！と思ったら、Solver SOPにフォーカスし、アトリビュートエディタからSub Stepsを10にまで増やしてみましょう。1フレームにつき10回計算が行われるようになり、見かけ上光速になります。また、アニメーションの左下Global Animation OptionsからEndを1000程度にし、Applyすると1000フレームまでアニメートされます。

そして、ある程度まで計算されたローレンツ方程式の結果を見てみましょう。うまくいけば次のようになっているはずです…

点群ですね！これは点群なので、「それらしい見た目」とはなっていません。点と点を結び、線にする必要があります。そこで、ふたたびAdd SOPの出番です！SOP Solverに新たにAdd SOPを接続し、アトリビュートエディタからPolygonsタブ>By Groupを選択すると、線分が作成されます。

線分になったからにはやりたい放題です - ここにPolywire SOPをつないでもよいし、Copy To Point SOPの第2入力に入れて、Sphereなどを第一引数に入れて点をもっと大きく描画することも可能です - これが私達のゴールです。

ですが、もう少しあがいてみましょう。ここからはHoudini特有の「お作法」です。

お作法

記述したWrangleの中に直書きの数値があったことに気づきましたか？これらをひとつのCONTROLLERというノードにまとめて一括で管理できるようにします。

AddやSolver SOPと同じ階層にNullノードを作成します。名前をCONTROLLERとします。

アトリビュートエディタのヘッダにある歯車アイコンをクリックし、Edit Parameter Interfaceを選択します。すると次のウィンドウが表示されます。

左側のペインからFloatを選択し、ドラッグ・アンド・ドロップで右側のペインに移動します。これを4回繰り返しましょう。

そして右側ペインから上から順にp, r, b, dtと命名します。このとき、dtは値が大きすぎると数値解が発散してしまうため、Rangeにチェックを入れて0.001から0.01とし、両側の鍵のボタンを押します。

すべてが済んだら"Accept"で変更を保存しましょう。

次のようになっているはずです…

これにそれぞれ、p=10, r=28, b=2.6666666667を挿入します。dtは0.01にします。

そして、SOP SolverのWrangleコードを次のように変更し、コードエディタの右側にあるスライダーと+アイコンを一緒にしたようなボタンを押します。すると、コード下部にパラメータが追加されます。

float dx(vector Point) {
    float p = ch("p");
    return p*(Point.y - Point.x);
}

float dy(vector Point) {
    float r = ch("r");
    return Point.x*(-Point.z + r) - Point.y;
}

float dz(vector Point) {
    float b = ch("b");
    return Point.x * Point.y - b * Point.z;
}

float dt = ch("dt");

int newpointnumber = addpoint(geoself(), @P + set(dx(@P), dy(@P), dz(@P)) * dt);
setpointgroup(geoself(), "last", @ptnum, 0);
setpointgroup(geoself(), "last", newpointnumber, 1);

一旦CONTROLLERノードまで戻り、pの値を右クリックして「Copy Parameter」を実行します。

ふたたびSOP SolverのWrangleノードに戻り、パラメータPの値を一旦殻にしてから右クリックし、今度は「Paste Relative References」をクリックします。

するとch("../../../../CONTROLLER/p")が挿入されます。まさにrelative referencesです。これはCONTROLLER(Null)ノードのパラメータを参照しています。同様に他のパラメータについても同じことを行いますが、面倒なのでこれをコピペし、

ch("../../../../CONTROLLER/r")
ch("../../../../CONTROLLER/b")
ch("../../../../CONTROLLER/dt")

と言った具合に推定できるものはとっとと書いてしまいましょう。さいわいなことに、補完が効いてくれます。

もう一度実行してみましょう…何も変わりません。では、CONTROLLERからパラメータのスライダーを色々いじってみて、ローレンツ方程式がどのように変化するのかを観察してみましょう…これからは遊びの時間です！自由にローレンツ方程式の係数を変えて、様々な形に表情を変えていく様を見ましょう！

補足

説明が完全に入り込む隙間がありませんでしたが、最後の解説としてVEXについて説明せねばならないでしょう。「なぜローレンツ方程式をSOP Solverを経由して解かなければならなかったのか？」
答えはVEXが完全に並行に実行されるプログラミング言語なためです。これはある点あるいはエッジの前後を参照できないということを指しており、これがローレンツ方程式のビジュアライズにとっては非常にネックとなってしまいます…ローレンツ方程式のビジュアライズには、前のポイントの情報が必要なのですから。そのため、今回のローレンツ方程式のビジュアライズはVEXのパワーを活かしきれていないということです…

そう、VEXはとても強力な言語です。意識せず並行処理が行われ、SIMDなどの支援による高速な実行が期待できます。ですから、可能な限りVEXで完結するような処理を考えるべきです。

なお、無視していましたがPythonのノードが用意されており、Pythonでとっととローレンツ方程式を描写することもできます。今回はもうやりませんが。何度も言いますがVEXで書けることはVEXで書くべきなのです。

おわりに

この動画に助けられました: https://www.youtube.com/watch?v=saA6-edb-OE

Houdiniは3Dデザインを主としており、上記の特性を利用してアルゴリズミックなデザインも可能になります…フィボナッチ数を用いて花をそれらしく表示したり、マンデルブロ集合を3Dに拡張したものを表示したり…またその特性から無機物と自然物のモデリングも得意です。そして、忘れないでおいてほしいのが、Houdiniは炎や水、破壊の表現も得意です…これらの組み合わせはとても強力なものばかりです。Houdiniワールドは広い。この荒野をもっと旅する気分になったなら、Appertanceライセンスでいつまでも冒険を続けることが可能です…

ようこそ、プロシージャルモデリングの世界へ！

package.jsonの各種要素を読み込みたい！

Origami — Wed, 24 Jul 2019 18:53:10 +0000

ラーメン今日食べたものです。package.jsonに書かれたデータが欲しいことが往々にして存在します。たとえばversionです。普段からnpm versionコマンドを利用するように意識していると、やはりどうしてもアプリケーション内でpackage.json内のversionを読み込んで表示したり、console.errorを繰り出す際にversionも併記してSentryなどのエラー監視ツールなどの補助情報として利用し、問題の絞り込みをしてみたくなるものです。

Node.js

process.env.npm_package_versionを呼び出せばよい。かんたん

Web Application

ひとくちにWeb Applicationといってもなんか世界が広すぎて解説しきれないので2つの手法を提示する。

package.jsonを読み込む

ES6であれば次のように読み込める。

import packageJson from "../package.json"
console.log(packageJson.version)

ただし、src以下のディレクトリしか読み込みのみを許可されている場合はpackage.jsonを直接読み込むことができない。対処法としてはsymbolic linkを貼ってやればよい。

ln -s package.json src/package.alias.json

これで次のように読み込める。

import packageJson from "./package.alias.json"
console.log(packageJson.version)

create-react-appの場合

そもそもpackage.jsonを読み込んでしまうのは中々穏やかではない（気がする）。create-react-appは最初から色々揃っており、.envに次のように記載すればよい。

REACT_APP_VERSION=$npm_package_version

するとprocess.env.REACT_APP_VERSIONとして読み込みが可能である。

おっと、これはWindowsでは動きませんよ!
このコードをwindowsでビルドしてしまうと、process.env.REACT_APP_VERSIONはバージョン情報を出さず、$npm_package_versionと表示してしまいます。困りましたね。

Windowsでのnpmの環境変数の読み込みは次の形式となります。

REACT_APP_VERSION=%npm_package_version%

しかしこれではmacOS, Linuxでうまく読み込めません。

解決方法は、上記の.envのやり方を諦めてpackage.alias.jsonを読み込むか、泥臭い方法で頑張るかです。

REACT_APP_VERSION_UNIX=$npm_package_version
REACT_APP_VERSION_WIN=%npm_package_version%

export const appVersion = process.env.REACT_APP_VERSION_WIN === "%npm_package_version%" 
    ? process.env.REACT_APP_VERSION_UNIX 
    : process.env.REACT_APP_VERSION_WIN

泥臭いですがこれでWindows, macOS, Linuxどれでもversion情報を読み込むことができました。こんなことするぐらいならpackage.jsonをimportした方が良い気もしますが。

他にもnpmの環境変数が欲しい？

process.envには様々な情報が含まれています。パッケージ名を含むnpm_package_name、ライセンス情報を含むnpm_package_license等。各自見てください。全部紹介する気にはなりません。とはいえWeb開発にはpackage.jsonの中身さえ読めれば十分とは思います。

ReactとElectron間のデータの送受信の手法と一例

Origami — Mon, 01 Oct 2018 14:50:46 +0000

注意！

この記事内のいくつかの項目はoutdatedになりました。特に、remote.requireは非推奨です。

バーチャルユーチューバーです。皆さんもバーチャルユーチューバーですか？

前回のReact+Electronアプリを作る話ではアプリを作るまでの事しか話しませんでした。そして、React及びRedux上で物事がだいたい済むのならば、ElectronやNode.jsについて深く思い悩むこともないでしょう。

しかし、Electronでアプリケーションを作りたいのならば、Node.jsおよびその上で動作するパッケージを使用したいことや、Electron上で取得したデータをReact上で表示したい、という望みがあるはずです。
ここで問題になるのは、そのElectron-メインプロセス-とReact+Redux-レンダラプロセス-の間をどのように処理するか、についてです。

`remote.require`

次に示すコードは、レンダラプロセスで使用している部分です。

// レンダラプロセス
//@flow
const { remote } = window.require('electron');
const app = remote.require('electron').app;

export default (): Promise<string> => new Promise((resolve) => {
    resolve(app.getAppPath()); //アプリケーションの実行場所が絶対パスとして返ります
});

remote.requireはレンダラプロセスで利用可能なrequireの変わりだと思えば十分です。内部的にはinter-process communication (IPC)を利用してメインプロセスのメソッドを呼び出しており、最もシンプルにメインプロセスとのやり取りが可能です。
基本的に、シリアライズ可能なデータであれば受け渡しが可能です。

// レンダラプロセス
//@flow
const { remote } = window.require('electron');
const app = remote.require('electron').app;
const fs = remote.require('fs');

export default (): Promise<any> => new Promise((resolve, reject) => {
    try {
        fs.writeFileSync(app.getAppPath()+"/internet.json", {googlePublicDns: "8:8.8.8"});
        resolve();
    } catch (e) {
        reject(e);
    }
});

`ipcMain`、`ipcRenderer`

ipcMainとipcRendererはそれぞれEvent-Drivenな方策でメインプロセスとレンダラプロセスのデータの受け渡しを可能にする機能です。基本的な使い方はElectron ipcMainのドキュメントに載っていますが、実際に使用するとなると（データフローをすべてredux上で済ませたいという気持ちがあるため）reduxとそのmiddlewareを利用した上でipcRendererを利用する場合があります。
少し複雑になりますが、redux-sagaを用いてipcRendererを利用した例を次のコードに示します。

// レンダラプロセス
// @flow
import { eventChannel, END } from "redux-saga";
import { fork, take } from 'redux-saga/effects';

const { ipcRenderer } = window.require('electron');

const ipc = function* () {
    try {
        const channel = yield eventChannel(emit => {
            ipcRenderer.on('asynchronous-reply', (event, arg) => {
                console.log(arg);
                emit({type: "EVENT_RECEIVED", payload: {}});
            });

            return () => {};
        });

        while (true) {
            yield take(channel)
        }
    } catch (e) {
        console.error("ipc connection disconnected with unknown error");
    }
};

export default function*() { // redux-sagaのrootsagaで1度だけ呼び出す
    yield fork(ipc);
}

eventChannelはイベントエミッターを監視するのによく使用されます。emit => {}の中でリスナーを実装し、emitでactionをdispatchすることができます。
本来であればoncloseかなにかが送信された時点でemit(END)を利用しイベントが終了したことをsagaに通知すべきですが、ipcRendererには無いので無視します。

// メインプロセス
ipcMain.on('asynchronous-message', (event, arg) => {
    console.log(arg); // prints "ping"
    event.sender.send('asynchronous-reply', 'pong')
});

今回の場合、asynchronous-messageという名前のついたイベントがレンダラプロセスから送信された場合、メインプロセスはasynchronous-replyイベントを返送し、データとして'pong'を返送するようにしています。勿論、イベント名は何でもよく、レンダラプロセスとメインプロセス側で名前さえ一致していればよいです。
そして、やはりシリアライズ可能なものであれば何であれ送受信可能です。

試しに、レンダラプロセスの適当な場所で'asynchronous-message'イベントを投げてみましょう。

// レンダラプロセス
const ipcRenderer = window.require('electron').ipcRenderer;

setInterval(() => {
    console.log('sending...');
    ipcRenderer.send('asynchronous-message', 'ping');
}, 1000);

成功しているならば、コンソールは次のように表示されているでしょう。

`WebContents.send`

ipcMainのドキュメンテーションにレンダラプロセスに一方的に送信するメソッドがないことに気付きましたか？
レンダラプロセスからメインプロセスへ一方的に送信しまくることはできますが、ipcMainでは基本的に「返送」しかできませんでした。
メインプロセスからレンダラプロセスに何かを一方的に送信しまくりたいときもあります。その時は、WebContents.sendを用います。

// メインプロセス
// BrowserWindowのインスタンスmainWindowがあることを前提にしています
mainWindow.webContents.send("asynchronous-message-from-love", "yeah");

ここまで読んできたならもう分かると思いますが、"asynchronous-message-from-love"イベントを送信しています。これを受信するには先程のipcRendererの実装を使い回せばよいだけです。

`WebContents.executeJavaScript`

これはかなり直球的なやり方です。見たままのコードが実行されます。

// メインプロセス
// BrowserWindowのインスタンスmainWindowがあることを前提にしています
mainWindow.webContents.executeJavascript("console.log('yeah')");

このコードが実行されると、レンダラ側のコンソールにyeahが表示されます。文字列を組み合わせることで、最強のコード実行が可能です。ただし、evalと同様、セキュリティ的な危うさもあるため、基本的にはハードコートした文字列の組み合わせのみでexecuteJavascriptを実行すべきです。

conclusion

レンダラプロセスではremote.require、ipcRendererを利用すればよい
メインプロセスではwebContents.send、ipcMain、webContents.executeJavasSriptを利用すればよい

おわり

なぜreducerで副作用を起こしてはならないか

Origami — Wed, 25 Jul 2018 14:02:03 +0000

TL;DR

reducerで副作用を起こすと、最悪の場合、コンポーネントのチューニングが不可能になる

本題

こんにちは。まずこのようなコードがありました。

class Account {
    constructor(id, name){
        this.id = id;
        this.name = name;
        this.aka = [];
    }

    pushAka(name){
        this.aka.push(name);
        return this;
    }
}

このインスタンスをreducerで管理したい。そんなことありますよね。たとえば次のように…（redux-actionsを暗黙的に使用している点はご容赦ください）

const initState = new Account('Donald Trump');

export default handleActions({
  "ADD_AKA": (state, action) => (state.pushAka(action.payload.aka))
}, initState);

これは、特に何も考えなければ、とりあえずはうまく動きます。しかし、Reduxの3つの基本概念である大前提副作用を起こしてはならないという点において、間違っています。

問題はAccountクラスのpushAka(name)メソッドにあります。結局のところ、これは自分自身のメンバ変数を変更した上で自分自身を返しているという事そのものに問題があります。しかし、今の所うまく動きます。

この時点でのStackblitzのサンプルです。

さて、今の所は動いています。すでに大問題ですが、ここから取り返しのつかないことが起きてきます。

Reactは高速ですが、それでもチューニングが必要になる場合が多々あります。コンポーネントの無駄な再レンダリングを防止するために、状況に合わせて主に以下の3つのチューニングが行われます。

componentShouldUpdate(prevState, nextState)の使用
React.ComponentではなくReact.PureComponentを使用
Stateless Functional Componentsではrecompose/pure,recompose/onlyUpdateForKeysを使う
自分でpure HoCを書く

さて、この場合でもチューニングを行ってみましょう。今回は先程のサンプルにおいてはcomponents/AkaList.jsがStateless Functional Componentsですから、試しにpureを使ってコンポーネントのチューニングを行ってみます。単に次のように書き換えるだけです…

import React, {Fragment}from 'react';
import {pure} from 'recompose';

const AkaList = (props) => (
  <Fragment>
    {props.account.aka.map((v, i) => (<p key={i}>{v}</p>))}
  </Fragment>
)

export default pure(AkaList);

recomposeのpureでコンポーネントの再レンダリングを抑えようとしています(例として少し極端ですが、ご容赦ください。時間がなかったんだでも動かないサンプルがこちらにある)

すると、リストがあるはずの場所に、何もレンダリングされなくなります。もっと具体的に言うと、コンポーネントがマウントされ、最初のレンダリングがされてからは一切の再レンダリングが行われなくなります。

ある意味では最高のパフォーマンスを得たわけですが、全ての場合においてこれは問題です。

この時点のStackblitzのサンプルです。

どうするべきなのか

副作用があるような設計が悪いとしか言いようがありません。

ここでは、一番はじめのコードで示したAccountクラスのpushAka(name)メソッドが悪いです。そこで、次のようなコードに置き換えます。

class Account {
    constructor(name){
        this.id = Date.now();
        this.name = name;
        this.aka = [];
    }

    pushAka(name){
        const r =  Object.assign(Object.create(Object.getPrototypeOf(this)), this);
        r.aka = [...r.aka, name];
        return r;
    }
}

rに自分自身を浅いコピーを行い、その上で新しい配列を作っています。とりあえず、これで動きます。

そしてStackblitzのサンプルです。

なお、この場合はこれでうまく動きましたが、さらに複雑なインスタンス、オブジェクト、配列ではこれだけでは解消しないこともあるでしょう。ただし、そのような複雑なデータ構造はそもそも設計が悪い可能性があります。

Conclution

KEEP PURE FUNCTION, SIMPLE DATA STRUCTURE!

余談

これまでのすべてのStackblitzサンプルにはredux-loggerが導入されています。特に、副作用が起きている時の1個めと2個めで開発ツールを開き、実際にプログラムを動かして、Donald Trumpの二つ名を追加してやりましょう。

何度か試しているうちに、loggerがとても興味深い挙動を記録していることがわかってきます。

なんとprev stateとnext stateが同一のものになっています。それだけではありません。

過去の出力までもが改変されています――とても興味深く、面白い話ですが、この現象を解説するには私はreduxとredux-loggerの実装に精通していません。誰かこの解説記事を書いてください。私はこれが限界です。

HoCとStorybook/addon-infoの落とし穴

Origami — Thu, 19 Jul 2018 15:36:26 +0000

TL;DR

Higher-Order Componentsをaddon-infoで表示させようとするとバグる

Storybook? Storybook/addon-info?

みなさん、storybookを使ってますか？コンポーネントを作っていく時に便利すぎるので是非使ってください。説明だるいのでプロジェクトページのexamples見ればすぐわかりの取得ができます。

さて、storybookのプラグインであるaddon-infoも超便利です。コンポーネントがどのような役割を果たすのか、何を意図して作られたのかをmarkdownで記述すると表示してくれますし、実際にstoryのコード内でどのように使われているかを表示したり、Flowによる型チェックが(たぶんTypeScriptも)定義されていた場合、それも表示してくれます。

たとえば、以下のようなコンポーネントがあるとします。

// @flow
import React from 'react';

type Props = {
    /* クエスチョンマークの前につく文字列です */
    label: string,
    /* クエスチョンマークの数 */
    amount: number,
};

/* めっちゃクエスチョンマークをあれします */
const SuperQuestionLabel = ({label, amount}: Props) => (
    <a>{label + '？'.repeat(amount)}</a>
);

SuperQuestionLabel.defaultProps = {
    label: "は",
};

export default SuperQuestionLabel;

そして、story用のコードは次のようになります。

// @flow
import React from 'react';
import { storiesOf } from '@storybook/react';
import { withInfo } from '@storybook/addon-info';

import SuperQuestionLabel from "../SuperQuestionLabel";

storiesOf('何もわからん', module)
    .add(
        'basic usage',
        withInfo(
            '感動する文章'
        )(() => (
            <SuperQuestionLabel
                label={"これからは飲酒の時代"}
                amount={8} />
        )))

すると、storybookの当該ページにはInfoボタンが表示され、クリックすると次のようなすばらしいインフォメーション情報が表示されます。

感動する文章、コンポーネントがどのように使われるのかの一例、そしてプロパティの詳細情報、感動ですね。Reactに限らず、今やReactコンポーネントを作るのであればstorybook、そしてaddon-infoは欠かせないものになりつつあります。(残念な点としては、今の所addon-infoはReactにしか対応してない点でしょうか)

Main Issue

そんなaddon-infoには天敵が存在します。Higher-Order Componentsです。

その例として、Stateless Functional Componentsで、recomposeの機能を使用している場合です。

うまくいかない例を見てみましょう。

// @flow
import React from 'react';
import {pure} from 'recompose';

type Props = {
    /* クエスチョンマークの前につく文字列です */
    label: string,
    /* クエスチョンマークの数 */
    amount: number,
};

/* めっちゃクエスチョンマークをあれします */
const SuperQuestionLabel = ({label, amount}: Props) => (
    <a>{label + '？'.repeat(amount)}</a>
);

SuperQuestionLabel.defaultProps = {
    label: "は",
};

export default pure(SuperQuestionLabel);

recomposeのpureを用いてコンポーネントの再レンダリングを抑えています。高いパフォーマンスを求められるWebアプリケーションであれば、pureやonlyUpdateForKeysを用いてチューニングを行うことも多々あるでしょう。しかし、StorybookのInfoページは次のようになってしまいます。

感動どころか、失望してしまいます。

なぜこのようになるか?理由はこれらのpureやonlyUpdateForKeysはHigher-Order Componentsだからです。するとひとつコンポーネントにコンポーネントがラップされた形になってしまいますから、そのためにaddon-infoが各種情報を拾ってくれなくなるのです。

Solution

HoCしたコンポーネントであることが問題なのですから、素のコンポーネントをstoriesに記述すればいいわけです。

つまり、次のようなコードにします。

// @flow
import React from 'react';
import {pure} from 'recompose';

type Props = {
    /* クエスチョンマークの前につく文字列です */
    label: string,
    /* クエスチョンマークの数 */
    amount: number,
};

/* めっちゃクエスチョンマークをあれします */
const SuperQuestionLabel = ({label, amount}: Props) => (
    <a>{label + '？'.repeat(amount)}</a>
);

SuperQuestionLabel.defaultProps = {
    label: "は",
};

export const SuperQuestionLabel_ = SuperQuestionLabel;
export default pure(SuperQuestionLabel);

export constを使用して、素のコンポーネントを追加で出力するようにしただけです。

そして、story用のコードも、importするものを変更すればいいのです。

// @flow
import React from 'react';
import { storiesOf } from '@storybook/react';
import { withInfo } from '@storybook/addon-info';

// ここを変更！
import {SuperQuestionLabel_} from "../SuperQuestionLabel";

storiesOf('すべてが理解できた', module)
    .add(
        'basic usage',
        withInfo(
            '感動する文章'
        )(() => (
            <SuperQuestionLabel_
                label={"これからは飲酒の時代"}
                amount={8} />
        )))

少々(exportする名前が)雑ではありますが、これでaddon-infoは次のように、期待通りの表示をしてくれます。

Conclusion

Higher-Order Componentsをdefaultで出力しているコンポーネントは、少なくともStorybookのaddon-infoで概要を表示させたいのであれば、素のコンポーネントもexportしてあげよう

END OF FILE

最後の画像のAlt textは「感動！君も泣け」です。

そして私はこの問題におもいっきりハマり、2日無駄にしました。人生は短く、みなさんの人生も短い、だから私は人生の時間をさらに削り、みなさんの人生の時間を無駄にしないよう、記事を書いている…

React tutorial code in Stateless Functional Components and Redux

Origami — Fri, 09 Mar 2018 20:46:48 +0000

TL;DR

Reduxばっか使ってると脳がへんになるぞ

はい

こんにちは。もうおれはつかれた。そしてこれを見てください。

https://stackblitz.com/edit/react-tutorial-sfc-and-redux
(github repository is here)

埋め込みのやり方わかりません。もう眠いのでどうでもいいです。

内容的にはReactのこのページで書くマルバツゲーム(tic-tac-toe)をStateless Functional Components + Redux(react-redux, redux-actions, reselect, redux-undo@beta)で全部書き直したというだけのことなんですがまあとりあえず見てください。コードがわりと汚い自信はあります。

Conclusion

Reduxは小規模なプログラムで書いてもただ煩雑なだけ

もう見出しのとおりです。
ただ、学習という意味合いではそれほど無駄ではないかな、とは思いますが。

そもそもReduxを使う意味

これは若干ポエム要素を含みます（完全に個人の見解です）が、Reduxはプロジェクトの構造を少し複雑にする分、それぞれのアクションの責任を小さく分割するような制約を要求してくるため、ある程度の規模を持ち、かつ複数人が関わるようなプロジェクトでその効果を存分に発揮してくれるものと認識しています。

「規模」というのが肝要で、どれほど大きくなればReduxが威力を発揮するのか？
それはグラデーション的な曖昧な境界線を挟む問題なので、ここで説明はしませんが、このぐらい小規模だとReduxはむしろコードの分量をいたずらに増やし、煩雑にしてしまうだけである以上、やはり「Reduxを使わない」という選択肢は十分に有り得る、という、当たり前のような無意味な解答をみなさんに提供します。

DEV Community: Origami

Promise/async関数でthrowとtry~catchはやめておこう

async関数の場合

Promiseの場合

PWAで動いてる？isPWA();

JavaScript

CSS

Don't use custom hooks as like global state

そのContext呼び出しはProvider以下にあると保証できますか？

はい

custom hooksをグローバル変数みたいに扱わないで

webpack-dev-serverでdisableHostCheckを使うのはもうやめろ

TL;DR

Houdini初心者のためのローレンツ方程式の数値解導出とビジュアライズ

プロシージャルな手法

Houdiniとは？

今回の目標

Houdiniことはじめ

SOP

WrangleノードとVEXPression(VEX)

SOP Solver DOP

さあ、ローレンツ方程式を計算しよう！

補足

おわりに

package.jsonの各種要素を読み込みたい！

Node.js

Web Application

他にもnpmの環境変数が欲しい？

ReactとElectron間のデータの送受信の手法と一例

注意！

remote.require

ipcMain、ipcRenderer

WebContents.send

WebContents.executeJavaScript

conclusion

なぜreducerで副作用を起こしてはならないか

TL;DR

本題

どうするべきなのか

Conclution

余談

HoCとStorybook/addon-infoの落とし穴

TL;DR

Storybook? Storybook/addon-info?

Main Issue

Solution

Conclusion

END OF FILE

React tutorial code in Stateless Functional Components and Redux

TL;DR

はい

Conclusion

Reduxは小規模なプログラムで書いてもただ煩雑なだけ

そもそもReduxを使う意味

`remote.require`

`ipcMain`、`ipcRenderer`

`WebContents.send`

`WebContents.executeJavaScript`