読者です 読者をやめる 読者になる 読者になる

さいきん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ロジック二重持ち問題発生

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

GUIを作るならRPCのほうが向いている説 / 読めるようにコードを書くこと

たしかにドキュメントビューア向けならともかく、フルGUIのアプリケーションに向けてRESTのAPIを返すのはなんか違う。いつかのデザイン系の記事で、ユーザはオブジェクトを見つけて〜の行動をしたいのではなく、〜をしたいからアクションを始める云々というのを読んだことがある。もちろんRESTは前者である。

昔はXML RPCとかもあったそうだが、今はまだREST APIの全盛期。GithubからGraphQLが出てきたり、たしかに動詞単語APIJSON中身いい感じにしてくれやも増えてきている。

しかし、現代のふつうの人はブラウザのアプリケーションとか使ってくれるわけもなく、スマートフォンネイティブのアプリケーションを使い、その使いやすさにも敏感*1なので、UIリッチなアプリケーションに寄せて設計をすると自然とRPC的なAPIができていくのではなかろうか。

個人的な設計の好みとしては、GraphQLのようなぶっといRPCを謎の責務的まとまりごとにエンドポイントを分けて中身はいい感じにやっていくのが良いような気がする。ここでは何をするかではなく、何に対して操作するかという切り分けが出てくるかもしれない。

 

ブラウザバックのボタンがこの世から消えたらアプリ作ってもいいよ

QAまともにやってないところのアプリだいたいブラウザバックで壊れる

ブラウザでアプリを作るな甘えるな 

上記の文脈などに呼応した思いです。ここでのアプリとはUIリッチなブラウザで動くアプリケーションのことです。

 

読めるようにコードを書くこと

その他本日の思いがひとつあって、プログラミングは文章を書くのに近いものがあるような気がしてきたという話です。

たとえば、hoge_enabledというbooleanの変数があったときに、!hoge_enabledと書くよりhoge_disabledという変数あるいはメソッドを定義したほうが読みやすいよねという話です。

!hoge_enabledくらい難なく読める、確かにそうですが、これを読み解くときにhoge_enabledの中身がtrue, falseどちらかを確認してから反転し、そのときの値を意識しながら&&の続きを読むといったスタックを多めに使う認知が働きます。対して、hoge_disabledと書かれていればプログラマ英語がふつうにできる人は、ほぼ無意識レベルの認知で読み下すことができます。なので、あきらかに後者のほうが読みやすいのは間違いないです。ここで、それくらい読めるというのもよいですが、!を使って書き下すかどうかで自転車小屋の議論をするよりhoge_disabledを選んだほうが生産的です。

まとめると、変数名は本当に重要なので手を抜くな。頭を少しでも使う処理は切り出しておけということになりそうです。こんな知見たぶん50年くらい前には発見されているでしょうが、独立に気づいたので主張した次第です。

ここで少し気になったのが、コードを書くうえで英語ネイティブの人は有利なのでは?という点です。データがないので何もいえませんが、もしかしたら有意な差は出ているかもしれません。しかし、我々はいまさら日本語でコードを書ける気がしないし、言語が統一されていると世界レベルで知見を共有できるので我々は英語を書いて読み続けるしかないのです。

*1:というかこのUIわけわからんてなると投げ出して罵倒レビューをしていく

利尿作用困る / gemのjQueryなくなってほしい / サブカルクソにおい棒

昨日の続きなんですが、webで広告一本でお金稼いでいくなら社会属性推定やらないと競争力維持できないのではというあれ。さらに、webサービス自体のプラットフォームが他のサービスとは違う集団に向けて提供されていると広告市場としてもより差別化ができるのだろう。

 

この世の飲み物から利尿作用だけ無くなってほしい

大変な頻尿持ちなので会議とかでかなり困っている。水自体にも量飲むと利尿作用があるような?

 

nested_formとsimple_formの組み合わせでハマり、よく見たらREADME.mdに有用な情報が書いてあるパターン。

しかし、この手のviewを弄るgemはだいたいjQueryに依存しており、バグの温床になりやすい。実際にnested_formの挙動はだいぶ怪しい。DHHも脱jQueryに舵を切っているみたいなので、gem界もReact(web) Componentとして機能を提供するオプションを用意してくれないだろうか。React Component自体は全然難しくないので。。。

 

サブカルクソという呼称を好んで使う程度にはサブカルクソ界隈が好きです。

今までに発言したサブカルクソタームで一番怒られたのは「サブカルクソにおい棒」です。

gyazo.com

正しくはリードディフューザーといいます。京都のサブカルクソほっこりカフェにはだいたい設置してあり、たまに加減を間違って公害になっている。最悪。

斜めがけ鞄よくない / カット野菜の可能性 / 広告

恐ろしいことに斜めがけ鞄で生活していると、左右半身で筋肉の付き方、首の傾き、歩く癖などが目に見えるレベルで変わります。重いものを持ち運ぶ場合は絶対にリュックにした方がいい。

 

社会上の問題をシステムで解決するときに銀の弾丸はない。生物という系も社会と同じくらいには複雑である。銀の弾丸はない。 

 

はてなブックマークを見たらわかるように、皆さん文章を読まずに雰囲気で怒るので、態度には気をつけないといけない。物理空間でも同様だと思う。

 

10分で作れる完全栄養食を目指したい

野菜を買ってきたらすぐに刻んで冷凍する運用はやっぱり美味しくないのかしら

美味しい冷凍カット野菜あればそれ買うんだけどな

冷凍の方が栄養アレかと思ってたんだけど、昔こんな記事をブクマしていた。

www.ponparemall.com

作業の分散は効率が悪いので、料理のたびにカットせずに冷凍された野菜を使うのが最適。野菜を買ってきたら自分で冷凍しても良いが、私は大量生産大好きマンなので冷凍済みのものがあればそれを使うようにします。不味ければまた考える。

 

何者かになりたい業界は新しいトレンドで何者かにならないと意味がないので、媒体が世代交代していく説

今はYoutuberとブロガーが最新な気がする。

 

手書きでも良いのだけど、図のわかりパワすごいので、業務用ペンタブ欲しいかもしれない。

仕様書とかドキュメント書いてもどうせ誰も読まないので、誤解を与えない程度にわかりやすい図を高速に生産できる環境が必要だと思っている。最初は手書きでも良いので。iPad Proが良いのではないかという結論に。

テレビ広告

風呂での妄想です。

あらゆる製品はどんな属性の誰に売るかを考えて作るわけで、広告も誰に広告コンテンツを見せるかは検討されている必要がある。問題になるのがテレビの広告で、近年のテレビは若者が観ていないという*1。昔のテレビであれば社会属性に関わらず様々な人が視聴していたのだろうが、現代ではその仮定が通用しない。

広告というのは視聴者がCMを観て実際に購買行動を起こさないと意味がなく、製品がある程度ターゲティングされているのならば、広告もその集団に対して投射するのが効率の良い方法であるはずだ。

なので、テレビ視聴者が偏る現代において、特に若者へのパスがテレビで無くなるのはテレビ局にとっても広告出稿者にとっても度し難い問題なのではないだろうか。

本来であればテレビ局が、様々な属性とまでは言わなくても様々な年齢層の人々に狙いを定めて番組の編成を設計すべきだが、今どうなっているのだろうか。

翻ってここで強いのがやはりGoogleで、Googleは昔からユーザの社会属性の推定を行っている。また、動画のわかりやすさというのは凄まじく、Youtubeはその動画広告を強制的にユーザに観させる仕組みを実装している。Youtubeが人口に膾炙した今では特に若者購買層への露出はそれなりに多いはずで、正確なターゲティングと相まって広告としての効果は高い状況と言えるのではないだろうか。

個人的にはテレビも頑張って若者向けの多様なパスを維持できる番組構成にしてほしいのだけど*2、テレビ局の人々がメインの視聴者に向けて構成してしまうのも致し方ないとは思う。

 

*1:印象論

*2:面白ければ私も観る

キャラクター販売とステータス販売 / 新うどん体験

 主張です。世界的に動いてはいるけど、実現するんだろうか。

 

前提としてキャラクターの好悪は文化に強く依存していて、日本のオタク用のキャラはアジアの一部と世界のごく一部のオタクにしか受けないとかそんなん。また、人によって当然好きなキャラが違うので、とりあえずたくさん用意しましたというのが、妹がn人いるやつからの系譜だろうか。いやもっと前からかも。

というわけで、日本をターゲットにしたスマートフォンゲームとかガチャのあるやつは大抵キャラクターを売っている。そして、付加価値として市場価値の高いキャラクターはゲームの中で強いステータスが振られている。

しかし、主に私が不満なだけなのだけど、キャラクターへの愛着がほとんどない人々が、ゲームの進行としてはオレツエーをしたい場合にガチャで大金を出せというのはあんまりではないか。私はキャラクターが買いたいのではなく、ゲームを楽にプレイするためのステータスを買いたいだけなのに。

なので、私のわがままとしての主張は、ステータスとキャラクターを別々に売り、キャラクターは高価に、ステータスは安価にしてほしいというものである。例えばステータスを装備として販売するとか。*1

ここで問題になるのはキャラクター本体に強さを残すかどうかで、たぶん残すのは残した方が良い。強くて市場価値の高いキャラクターを所有したいユーザも当然たくさんいるから今の市場があるわけで、市場価値高い - 強い, 市場価値低い - 強い or 装備品で強い を別々の販売システムとして提供すると私のようなキャラ愛わからん人間も満足できそうではある。

一応、自分が嬉しい以外のメリットを挙げると、

  • キャラクターを差し替えてローカライズ、カルチャライズするだけで国際展開ができるかもしれない
  • 脳を使わずにとりあえず微課金*2でゲームを進めたいユーザを挫折させずに済む*3
  • FGOのような面倒すぎる戦闘は楽してキャラクターとのコミュニケーションができる

など。

こんな施策をやって全体としての売上がどうなるかは誰にもわからないので、どこかの会社が実験してくれないかな。

 

うどん凄くてジムについて柔軟、有酸素運動、筋トレをする間、うどんを耳から外す必要が全くない。これは体験ですよ。

もちろん家でも同様に外す必要がないです。

*1:FGOがそれと言えないこともないけど、ガチャとしてのシステムがクソなので厳しい

*2:本当に微課金

*3:みんな疲れてるんやで

哲学は精神に悪そう / ウェアラブルいつの間にか来てた / 転の合理性

哲学とか自己分析は精神に悪いということが言いたかった。しかし、無自覚で透明な人間はオッさんである。オッさんは場に悪い影響を与えるのでオッさんにはならない方が良い。

 

特に文脈はありません。 

 

テストはドキュメントの一種というやつです。この意見自体の新規性は無くて、古い本にすら書かれていそう。 

ただ、テストのデータを用意するのがほんとうにほんとうにめんどうでどうにかなってほしい。factory_girlもそんなに使いやすいかというとびみょう……。

 

私が学部に入学したくらいの頃はウェアラブルがまだ流行っていたような気がする。ユビキタスもあった。

しかし、気がつくとスマートフォンによって計算機が持ち歩けるようになり、無線規格でハードウェアとの連携ができるようになっていた。身の回りで見たことあるハードウェアだけでもfitbit, Apple watch, Air Pods, Pokemon Go Plus, vufineが挙げられる。

本命はやはり視覚をARでアレすることだろうけど、物体認識とか目の位置の計測、熱、重さ、バッテリーなどの課題が山積みなのでもう少しかかりそう。ハードウェアベンチャーが実現するのが先か、巨人が自前で作ってしまうのが先か、どうなるだろうか。

日常生活で使うとなると、シースルーのHMDみたいな眼鏡になるとは思うのだけど、シースルーのHMDは映像を重畳させることで文字とかが読めなくなるという問題がある。屋内なら兎も角、都市で使うとなるとさらに課題はありそうだ。Hololensがその辺をどう対処してるのかは気になるので一度体験してみたい。

 

一時期メディア露出していたウェアラブル研究者といえば神戸大学の塚本先生なのだけど、今もウェアラブルバイスの研究をやっているみたい。ただし、軸足はHCIとか空間計測の方向に寄ってそう。とにかく研究のタスク決めと評価がたいへんそう……。

なんでかしらないけど、VRの研究室もAIの研究室も結局人間について研究をすることになる。この領域、認知心理学に片足を突っ込んでいるので実験を行っても直接的に何かを証明することはほぼできない。そこで、代替手段としてアンケートとか脳波、発汗、筋電を取ることになるが、それでも直接的に人間の内部状態を説明するデータになるかというと怪しい……。つらい……。人間は複雑すぎるし嘘をつく……。

 

生物に発現する特性はランダムだから協力行動が強いのだなぁ

逆に向いてることをやらないと集団にする意味が薄れるな

けものフレンズでの、得意なことが違うというのはこのことだろう。なので、社畜は自分にあった仕事をやっていき、合わないのであれば合うところにたどり着くまで転職するのが最適行動になるのかもしれない。

考えたこと / 人間をハックしない🙅 / gitはGUIも使うと良いのでは

 エナジードリンクはカフェインと砂糖。エスプレッソはイタリアでは大量の砂糖をいれて飲みます。つまりエスプレッソはエナジードリンク

 

写真を投稿するViewの機能で一度CDNに乗ったものをinvalidateしてないようなそんな感じ。もしかしたら、同じファイル名のものはバイナリが変わっていても同じパスとして配信してるかもしれない。ファイル量の節約としては正しい戦略ではあるけど、invalidateと組み合わせないとバグるかも。これは妄想です。

 

プルリクエストを通すことを目的にするんじゃなくて、レビューによってコードの品質の分散を抑えることを目的にしましょうね。人間をハックしない🙅。

レビューする側は朝とかてきとうな調子の良い時間を選ぶほうが良い。

 

gitのクライアントCLIじゃなくても困らないので、GUIにしようかしら。何か良いクライアントがあれば良いけど、GHE対応してるかがほげ。

Github for xxxは結構できが良くてGHEにも対応している。最近私はneovimからAtomに8割くらい以降していて、特に困っていない。となるとオペレーションするとき以外はshellを使う必要がないわけで。

git add -p hoge.rbとかやるの結構めんどくさい作業なので、すばやく良いcommitを作っていく作業はGUIの方が向いていると思う。

ただし、rebaseはGithubのクライアントでできるのかわからない。

 

なんか短期記憶とかワーキングメモリがゴミのようにないなぁと思ったらADHDというのがあるのだなぁ。

任意の人類はアスペルガー度合いとかADHD度合い、その他なんかの軸を幾らかずつ持ってる気がしてきた。

お風呂で考えていたら私自身の思考方法に対する仮説モデルができた

主記憶が少ないのと、処理中のプロセスが一定以上の難しい問題だと処理を打ち切ってコンテキストスイッチするんだけど、コンテキストを遅いストレージにスワップアウトしてるので、コンテキストが戻ってきても何もできない。対策としては無限に広いホワイトボードを用意してコンテキスト書き出しておく 

表面上普通に仕事と社会生活はできているので、重度なものでもないんだけど短期記憶がゴミで困っているのでした。しかし、プロセスの打ち切りが速いと結果的により広い可能性を検討する利点もあるような気がしていて悪いところばかりでもない。