しゅみは人間の分析です

いらんことばかり考えます

■

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

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

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

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

 

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

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

 

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

f:id:non_117:20170412214915j:plain

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

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

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

 

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

家用に購入したのは、

コクヨ 軽量ホワイトボード マグネットシート 無地 900×600mm マット FB-HSM23W

コクヨ 軽量ホワイトボード マグネットシート 無地 900×600mm マット FB-HSM23W

 

この商品で、マーカーは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界はこのくらいとっくの昔に普及してそうだなぁ。

おまけ

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

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

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

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

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

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

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

さいきんReact, Reduxでやっている設計

はじめに

ブラウザでGUIアプリケーションを作らなくても良い牧歌的な時代は終わりつつあります。個人的な意見としてはブラウザはドキュメントビューアのままでいて、複雑なGUIアプリケーションはネイティブアプリケーションとして実装されてほしいのですが、そうは言ってもお仕事で人間にとって負担の低いUIを作っていく必要があるのです。
Railsでサーバアプリケーションを書きつつ管理画面はネイティブでなんてことはコスト的に実現できません。かといって長期的に運用されるシステムを作ると、システムを運用するためのUIが操作しやすいに越したことはありません。Bootstrapを使っててきとうなフォームを並べただけの画面を作って怒られた経験はありませんか？ たとえサーバ開発者だとしても、我々は使いやすいUIを求め続ける必要があります。

react, redux

複雑なGUIを作るためのフレームワークも乱立の時代を終えて、react, vue, angularなどに人気とリソースが集約されてきたような気がします。私はたまたまreact, reduxという組み合わせを習得しましたが、本質的にはfluxによるコマンドクエリ責務分離なデータフローができていればどれをつかってもなんとかなるんじゃないかと思っています。

今回作ったもの

みんな大好きTODOアプリです。
TODOアプリ簡単かと思いきや、ユーザ入力がそれなりに多いので実験としてはよい対象だと思います。
我々サーバ開発者はたくさんの入力フォームを相手にしなければならないので、実務と共通する知見も多いでしょう。

https://gyazo.com/e7bf20da140f535ef85dbef510bbec04

ソースコードはこちら github.com

model, stateたち

redux design models

特徴としてはImmutable.jsを使っている点、StateもImmutable.Recordとして実装している点でしょうか。
このTodoStateは自身と他のモデルたちの状態を適切に管理する責務を持っており、ユーザ入力に起因する状態の変更は各メソッドをactionとして呼び出してもらうようになっています。
つまり、TodoStateはTaskやその他オブジェクトのFacadeになるように設計しています。
また、Recordのメンバとしてtasksを持っているので、TodoStateインスタンスをルートコンポーネントに渡せば勝手に値を参照してもらうことができます。

reducer

redux design ducks

ユーザ入力によって発行されたアクションをTodoStateのメソッドへ適切に振り分けるのがreducerの責務です。
このファイルはducksと呼ばれるスタイルになっており、action定義、reducer, action creator, ついでにsagaをひとつのファイルに混ぜ込んでいます。

github.com

reducerにとってのinitial stateをTodoStateクラスとして定義しているので、newすれば良いだけなのも便利です。

非同期処理

redux本体が非同期処理と相性の悪いフレームワークだからか、redux-*はほんとうにたくさん存在します。
今回はその中でもredux-sagaを用いてコードの見た目としては同期的に書けるようにしています。
sagaのcall作用とtask.submit()を共存させるのが今回一番悩んだところでした。結論としては、sagaを経由するactionにTaskインスタンスをそのままぶちこんでやることになりました。(33, 34行目)
正直なところちょっとダサい方法だとは思うのですが、Taskインスタンスではなくidを突っ込んだにしても、select作用でstateを取ってきてからTaskインスタンスを取得するだけなので、パフォーマンスに影響がでない限りはこれでもいいんじゃないかと思っています。
あるいは、task.submitParams()のようなメソッドを作り、requestに必要な情報だけを切り出して非同期処理を引き起こすactionに託すのもありだと思います。

components

redux design components

さいきんPropTypes.funcとtypeするのに疲れてきたので思い切ってactionsはcontextで流すことにしました。
なにか困ったことが起きたら真面目にpropsドンブラコをしていこうと思います。お困りポイントに見当がつくかたはお知らせください。
上の例では、Container Componentで定義したchangeInputTargetアクションとcheckTaskアクションがcontext経由で受け渡されているのがわかるかと思います。

f:id:non_117:20170325203133p:plain これは内容とはまったく関係のない挿絵です

まとめ

pros, cons

pros
  • reducerが見通しやすくなる
  • stateとmodelsに対するテストが書きやすくなる
  • stateとmodelsをちゃんと設計しておけばreduxを捨てるのも簡単
cons
  • Facadeになるstateクラスが肥大化する

所感

  • stateクラスがFacadeになっていることが最重要なので、Immutableに依存する必要はない
    • ピュアES6で書くとより移植性が増す
    • しかし個人的にはImmutable + TypeScriptでやりたい
  • stateクラスが肥大化する問題はそれこそreduxが得意とする分割統治で解決してはどうか
    • reducerの分割単位をまたいで参照が必要なだけならcontextで流せなくもないと思う
    • reducerの分割単位をまたいで変更が必要な場合はUIから考え直すと良いのではないか……
    • 分割したうえでロジックが複雑化した場合はモデル内の層を増やすしかないかも
  • 実際にはTODOアプリ程度の複雑さだとまだreduxを使う要件ではない
    • ちょうどImmutableなStateができているので、Reactオンリーで十分やっていける
  • 上記のTaskといったモデルがサーバ上のモデルと一致するかというと微妙なところ
    • UIの表現をするための状態がでてくる
  • サーバから渡す初期状態をつくるには(react_on_rails)
    • UIのための状態が存在するのでas_jsonでは力不足
    • Application, Domain, Infrastructureの3層でモデルをつくりInfrastructureの管理する状態をサーバ側モデルの部分集合にすれば、as_jsonでも良い？
  • client side validation
    • validationロジックがstateクラスの管理下にあるのは間違いないが、現状のモデル構造では肥大化の要因となって厳しい気がする
    • サーバとvalidationロジック二重持ち問題発生
  • Fluxの非同期処理やコマンドクエリ責務分離って所有権と相性いいのでは？
    • 今回はリクエスト発行後にユーザ入力でnameが書き換えられても問道無用でレスポンスが勝つようになっている
    • 非同期処理が入るとレースコンディションが発生しやすいので、プログラマは何らかの方法で解決しておく必要がある
    • コマンドクエリ責務分離もView系クラスとModel系クラスが状態を変更する権限の管理という話になるはず
    • Rust + WebAssemblyに期待したい

ここまで書いて、この記事で提案したモデル構造ではモデル内の複雑さを克服できない問題が残ることに気づいてしまいました。
モデルの複雑さをサーバに押し付けることで対処が可能ではありますが、本質的には解決しないのでまた別の設計論は必要そうですね。
DDDとかに詳しい方の知見をお待ちしております。