Immutable.RecordとFlow問題はImmutable v4でなおってそう?

izumin.hateblo.jp

 

Flowに入門して今まで作ってきたReduxのモデルに型をあてようとしてみた。モデルは一部界隈でおなじみの、Immutable.Recordを継承したやつなのだけど、上記の記事のようにImmutable.Recordの型定義がよろしくない問題がある。

なんでそんな酷い型定義が存在するのかと思ってmasterブランチを見にいったらまともっぽい型定義で???と思ったら、以下のcommitで改善されてた。

github.com

よかったですね。v4で入りそう。

 

余談

Immutable v4でRecordがkeydCollectionを継承しなくなってる。

github.com

つまりMap-likeなオブジェクトではなくなった。

It also refactors the internals to no longer rely on a Map, but instead a fixed size List which should result in dramatically faster performance.

とのこと。すごくよかったですね。

Map的なオブジェクトであることを前提にしたコードは死にますが、私はOOP的な場としてRecordを使っているのでImmutable v4で受けられる恩恵は大きそう。

たしかにDSLでサーバ構成は書けるのだけど、書いててあんまり楽しくないというモチベーション。必要以上に構成管理のコードを綺麗にしても意味はないのだけど、サーバアプリばかり書いている人にとっては、コマンドをメソッド呼び出しとして記述するほうが自然に読めると思う。まともなシステム構成ならプロセスの責務は分かれているし、コマンド体系もおおよそ似たようなものだから、各プロセスをオブジェクトと見立てるのに無理はないのではないか。

と、ここまで書いたところでTLのインフラエンジニアより「Chef / itamae, puppetの哲学は、操作手順を記録することが目的ではなく、最終的なサーバの状態をコードに落としているだけだよ」というツッコミが入り、

という理解をして得心を得た。おわり。

必要なのは手続きではなく状態というのは正しいので、書きやすさの文句を言うならDSLの文法だとか実行環境、ツールの複雑さあたりを対象にするのが筋かもしれない。

 

人間の曖昧さによってユーザ入力は何が起こるかわからないので、特にテキスト入力が多ければ多いほどOptionalを扱える言語が相性よさそう。逆に、曖昧な入力が少なければスクリプト言語でえいやっとやってしまってもよいと思う。

自由な入力はnullとの戦いがつきものなので、武器は多いほうがよさそう。

 

ホワイトボードのシートを机に置くと便利

f:id:non_117:20170412214915j:plain

オフィスでやり始めたのだけど、タスクの備忘録とか考えごとの一時避難は机のうえに広げたホワイトボードで管理するようになった。あまりに自分の性格に合ってたので家でも同じことをはじめた。

コード書く前に設計するのにも便利だし、仕事の割り込みをとりあえず書いておいて放置してもよい。また、他人に難しい概念だとか設計の方針を説明するのにも重宝している。雑にタスクを羅列しておけばまわりの人が見て何の業務をして何を積んでいるかもわかってもらえるかもしれない。

普通のホワイトボードは移動式だったり壁に貼ってあったりするものだけど、壁に向かって文字や図形を書くのは結構たいへんで腕が疲れる。訓練を積んでいないと綺麗に文字を書くこともできないと思う。

 

最初はA4サイズのホワイトボードノートを使っていたのだけど、全然紙面が足りない問題があった。そこで、思い切って0.5平方メートルくらい机のスペースを開けてホワイトボードに専有させてみたところ、楽園が訪れたのが数週間前。今では朝にやることを書き出して、キーボードの横のスペースで設計しながらコードを書く生活になっている。

家用に購入したのは、

この商品で、マーカーはPILOTのボードマスターS極細を使っている。ペンは細ければ細いほどよい。

このホワイトボードシートの消しやすさは良好で、ちょっとペラいのが気になるくらい。埃が積もって消しにくくなっても各ご家庭にある無水エタノールを使えば何も問題はないと思う。

 

想定される問題点

机が狭くなる

シートの上に普通に物を置いています。

それでも狭ければ諦めるか整理整頓する気合を発揮してください。空間は縦方向に有効活用できます。

飛沫で服とか床が汚れる

ちゃんと(とは?)消せば消しかすをクリーナーに集めてゴミ箱にぽいできている。マメさはいるかもしれない。

高性能なホワイトボードクリーナーで解決する手もある。

 

以上です。ホワイトボードは書きやすくて消しやすくて最高。

フロントエンドGUIの状態の整理

昨日の🍺のあとに考えていた雑感。フロントエンドから見たGUIの状態を個人の主観をもとに整理しています。

 

背景

複雑なJavaScriptアプリケーションを考えながら作る話

id:Pasta-K がReact + Canvasで色々やっていた話

などなど。

Reactなどの現代フロントエンドはたいへんしんどいGUIであるという前提もあります。

 

GUIの状態の種類

f:id:non_117:20170411223655p:plain

人間

諸悪の根源。

だいたいこいつが状態を変更してくる。バリデーションが必要なのもこいつのせい。

わかりやすいUIを提供しないと人間が弱る。

View

Viewの中の状態。UI上の選択状態とか。

Viewに状態を持ちたくない宗派としては、できれば非永続化層(メインのビジネスロジックと状態を持った層)か永続化層(DB)にすべての状態を持っていて欲しいが、パフォーマンス上の問題でthis.stateに状態を持つことはありえる。ReactとCanvasでやっていくにはここに状態を持ってもパフォーマンスが厳しいとかなんとか。

コンポーネント単位でのユニットテストは書けるが、非永続化層よりはめんどくさい。結合テストはもっとめんどくさい。

状態がUIコンポーネントの中に閉じている、パフォーマンス上仕方ないといった条件が揃ったらここに状態を持つ設計を選択したい。

非永続化層

main()にあたる我々がよくいじっているレイヤ。メモリの中の永続化されていない状態とロジックを持つ。PDS(Presentation Domain Separation)を推し進めると、ここと永続化層ですべての状態を管理することになる。

FluxにおけるStoreとかStateとか言ってるやつがここ。Fluxの場合はImmutableであると扱いやすいと思う。適切に責務ベースでドメインモデルを分割していればテストも楽。

永続化層から取り出した状態、サーバへ投げるための状態、UIの状態などもここに突っ込まれるので、ちゃんと設計しないと簡単にカオスになる層。

たぶん低〜中程度の複雑さのアプリなら永続化層を扱わなくてもなんとかスケールできると思う。複雑度が高くなると状態をいったん永続化層に逃して正しくCQRS(コマンドクエリ責務分離)したほうが楽になるはず。*1

永続化層

サーバ屋的にはDB. インメモリなDBであることもある。ブラウザでなければファイルでもよい。高級なDBであるほどトランザクション処理に対応してたりしてとても便利。フロントエンド環境ではインメモリDBが主な対象。よくシングルトンなMapオブジェクトで実装されているような気がするが、欲を言うとブラウザ内にACIDなDBがほしい。IndexedDBは使ったことないので何も言えません。

ここの層もちゃんとデータ構造を設計しないとスケールしない。永続化層へのデータ挿入は非永続化層にいるロジックたちの責務なので、テストはロジックを通して行われる。

サーバ

ネットワーク越しにつながれた状態で、非永続化層から適切なタイミングで状態を反映してやる必要がある。

フロントエンドで非同期処理といったらだいたい半分がこれ。役割とかについては特に説明不要でしょう。

図ではサーバへの状態の反映しか描かれてないが、サーバから状態を取り出すこともある。どんなリクエストを送ったとしても、レスポンスの結果を切り出して非永続化層の状態とマージすることが多い。また、人間による状態の変更をブロックするためにリクエスト中であることを示す状態を必要とすることもある。

各アプローチ

人間 -> View, 非永続化層のループ

フロントエンドGUIはブラウザという環境の制約からここに閉じることが多い。FluxはこのループにCQRS的な発想を導入したものだと思ってる。上でも述べたようにサーバが登場したり状態が複雑になるとこれらの層だけではスケールしなくなることがある。

this.stateやReduxは永続化層を扱うことを想定していないし、扱うのも直接は難しい気がする。

上図全部のスタック

複雑なJavaScriptアプリケーションを考えながら作る話 が対象としているもの。おそらくネイティブアプリと基本的な構成は変わらない?

 

その他

状態を変更するのは誰か

ふつうのFluxだと人間による状態の変更を特別扱いしている問題がある。

Fluxの一派?であるCycle.jsはその点ぶっ飛んだ発想をしていて、main()ロジック以外のすべてが状態を変更してくると言っている。Cycle.jsはRxでだいたいすべてのロジックを実装しろという恐ろしいフレームワークだが、誰が状態を変更するかという問いに対してはおそらく正しいことを言っていて、たしかに我々が書くmain()の状態を変更してくるやつはユーザ操作もサーバとの通信も平等に作用(action)である。

だから、Reduxではユーザ操作以外の作用をミドルウェアで解決するしかないのであり、Redux単体では特別扱いしたユーザ操作作用の問題解決のみに注力しているのだと私は思っている。

そしてユーザ操作作用以外の作用が登場すると、それは競合状態のはじまりであり、作用と作用の間でどちらを優先するかという問題が出てきたりするがそれはまた別のはなし……。*2

どの設計方針を選択するか

所属する組織の特徴*3と要件をよく観察して考えて各位で判断するしかない。やっぱり銀の弾丸はないし、現実に合った選択を都度やっていくしかない。流行りものも上記の問題点がいくつかあり、場合によっては合う合わないがある。

おまけ

Cheek Pouch — moko-oxygen: はかどる!ハッカドール3号くんのSlack用カスタム絵文字 を配布します ...

Cheek Pouch

上で概念を説明した図に登場するハッカドール3号くんです。 

*1:非永続化層で行う状態の監視やトランザクションのロジックを永続化層に移譲する

*2:reduxは非永続化層への作用はatomicであるという制約をいれてるということか?

*3:組織構造によって技術選択は変わる

えも

理性、論理的な言動がエモやエモ的な言動より「よい」いうことは言えない。

おそらく教育とか社会の洗脳の結果ではあるのだけど、エモい状態になって自分のエモい気持ちを絶対に譲る気はないのに、言語インターフェイスとしては論理的にやる人が多い。私もやる。

いったんエモい状態になってエモ度が高まると、言葉ではどんなに論理的であっても自分の気持を変えることはなかなか難しいので、そのエモい気持ちを素直に言語化して感情として伝えたほうが効率的なコミュニケーションになるのではないかと思っている。*1

また、我々は勝手に論理がエモに優越すると勘違いしているが、1対1のコミュニケーションで相手も論理を重視する宗教であればそうかもしれない。しかし、多人数の目がある場だとコミュニケーションによる説得の裁定者は会話をしている二者ではなくまわりの聴衆であることが多い。つまり、論理がエモに優越するかどうかは背景にいる聴衆の属性によるとしかいえない。事実として、人間はエモ説得に弱く、public度合いが高いテレビなどではエモ言説がかなり多くみられる。

なので、論理とエモのどちらが優れているかという価値判断は意味がなく、会話をしている場の特性によってどちらがより効率的に人間を説得できるかが決まるまでしか言えない。

じゃあどうすればいいのかという話に入ると、自分がエモってる時はそれを自覚した時点で、できれば自分のエモい状態を伝え、できなければ一旦引くとよさそうだ。逆に相手がエモい状態になってきたら、一旦相手のエモい気持ちを汲み取ってとりあえず肯定してやるのがよい。あるいは、自分が悪いことがわかっていたらさっさと謝罪したほうがいい。

とはいうものの、実は文章を介したコミュニケーションでは自分の出力した言語をセルフレビューで直していくことができるので、エモよりは純粋に論理ベースな会話をしやすい特徴はある。しかし、これもセルフレビューをする訓練を積んだ人ができるという話であって、おそらくほとんどの人はできない。また、文章を書き始める取っ掛かりの気持ちが強いエモだった場合はもうどうしようもない。

 

という、以上のこの文章も論理嗜好宗派で書かれている。ここで私がこの文章を書くに至ったエモを素直に書いておきたかったのだが、書いているうちに気持ちを忘れてしまったのが正直なところだ。「プライド高いやつらめんどくさい(自分を含む)」くらいだったかもしれない。皆さん負けるのがいやなのでプライド高いのは生物的なレベルでしょうがない*2とは思うのだけど、自覚しておくと得をするシーンも多いのではないかという話になる。

*1:なぜなら、コミュニケーションの目的が説得や意思決定である場合は、誰かが意思を絶対に曲げない状態だと会話をしても無駄だから

*2:合理的な判断しかしない人間を経済人と呼ぶが、そんなもんは存在しないという立場がさいきん流行っている行動経済学

Optimizing React Apps in Practiceの記事がよかった

marmelab.com

がよかった。

書いてある知見

  • プロファイリングツールの使い方
    • ChromeでDeveloper Toolを開いてrecordした間のイベントから、どの処理に何ミリ秒かかったか表示される
  • 遅いのはだいたいre-renderだよという話
    • わかるけどついやっちゃう
  • shouldComponentUpdate()のはなし
  • acdlite/recomposeを使うとPureComponentもfunctional componentでらくらく書けるよという話
    • Reduxでもますますべんりなrecomposeのpure()
  • reselectでmapStateToPropsのコストを削減
  • Beware of Object Literals in JSX
    • JSXでcomponentのpropsに{{ marginTop: 10 }}みたいな渡し方すると毎回オブジェクトが作られて毎回renderされちゃうよという話
    • これ気づかなかった
    • ちゃんとconstで定義しておきましょう

所感

私はあんまりfunctionalなReact派ではないので宗教的に使えない知見もあったが、acdlite/recomposeとかObject Literalの話は役に立ちそうだった。

今日ようやくReact Componentの切り方について悟りを得たのだけど、「propsが変わったときに同じタイミングでrender()される必要があるか」という基準でドンドコ分けていけば良いと思った。
よくやりがちだったのが、同じComponent classの中にrender_hoge()を定義して、それをrender()の中から呼ぶというやつ。これはrender関数の中身をきれいにはするのだけど、本質的にはrenderされる対象が減っていないので塵が積もるとどんどん重くなる。
なので、ここではfunctionalなReactの教えに従ってrender_hoge()のかわりにfunctional componentを書いていくべきである。もともといたComponent classがpropTypesはだいたいチェックしてくれるだろうから、ほんとうにrenderだけするpure functionを定義すればよいはず。
こうすれば、ファイルをえいやっと分けたり面倒なことはしなくともある程度re-renderを減らせるはず。render_hoge()を定義するならfunctional componentにせよというのはコーディング規約にしてもよいと思う。

とは考えたのだけど、pure React界はこのくらいとっくの昔に普及してそうだなぁ。

おまけ

データ構造とアルゴリズム

アルバイトも含めてプログラマとしてはそこそこ経験を積んだが、年々データ構造とアルゴリズムの偉大さを噛みしめるばかり。とはいえまだデータ構造とアルゴリズムを理解した!といえるほどメンタルモデルができてないので、その理由についてはうまく言語化することができない。

計算機科学をやる学科では最初の頃にこの分野を習うのだけど、コードを書いた経験が少ないうちはなかなか有り難みが理解できなかった。習うより使わないとわからん度が高い領域ではあると思う。

私はインターネットを使ったシステムを作る屋さんだからだとは思うが、超難しいアルゴリズムを駆使して実装なんてことはほとんどなくて、実際にはデータ構造の定義で難しい問題がシュッと解けることが多い。

つまり実務であてはめるとモデル設計の時点で多くの問題を解決できるともいえる。ではあるのだけど、我々は想像力が足りないのである時点での局所最適なモデル設計をしてしまって、あとから改修するはめになる。

しかし、データ構造の設計は解こうとしている問題、つまりその場その場での要求や仕様に依存するので、一般的な解はなく、我々の経験に暗黙知が蓄積されて各々の問題に対していい感じにやるしかないのが現状かもしれない。

注意しておきたいのは、データ構造とアルゴリズムが可分でデータ構造のみを称揚する意図はないという点である。現実の問題を解くという点ではデータ構造だけで解決できるものはなく、両方を使ってようやくまともな解ができるような気がする。つまり、データ構造もアルゴリズムも両方手足として使えるようになり、全体最適を目指しましょうというオチになりました。