しゅみは人間の分析です

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

■

感覚分解能と雑に言ったがたぶんニューロンの扱える次元の数が限界値。しかし、下記のように情報を圧縮している。

学習は、人間でも機械でもそんなに変わらなくて、正解と不正解をひたすら突っ込んで内部の状態を作っている。

 

究極的には、人間社会で後天的に学べる概念はネットワーク上の状態として蓄積することは可能なはずである。ネットワーク上の状態とは、まさしくニューラルネットワークの内部状態のことで、あれは情報を入れたら次元を圧縮して出してくるフィルタのようなものとも言えるのではないか。

人間が社会的に学習する概念はDNNで学習可能だとすると、感情はどうなのかという疑問が残る。私の偏見では感情は遺伝子レベルのプリインストールな状態で、他の種や生存上の競合に対抗するためには必須の仕組みだったのだろうと飼っている🐭たちを見て思う。

となると、上記の究極を達成して強い人工知能ができたとしたら、感情とか備えてない可能性はある。強い人工知能さんに人権を与えるかどうかがSF的なおもしろポイントで、我々は感情を持っている動くものに人権を認めているのか、それとも人間レベルの知能を持った種に人権を認めているのかという話になってくる。私の意見としては前者が優勢で、実際一部の人の間ではイルカやペットに人権らしきものが生じている。

なので、感情させ実装しなければ強い人工知能さんの人権問題は杞憂かもしれない。もちろん、強（略）さんのふるまいを見て勝手に人権を付与する人はたくさん出てくると思うので、対人インターフェイスの設計も問題になってくる。

 Twitterでまとまった妄想を書くのはたいへん。

 

余談だが、ニューラルネットワークの出力結果は最初に述べたタグづけに近いものになっていて

gyazo.com

Using deep learning to listen for whales — Daniel Nouri's Blog

ご覧の通りである。

弛緩して捗らないときは服を着替えるとよかった

休日には趣味で作ってるアプリの開発が捗らないという悩みがあった。

今朝、いろいろ考えて、外に出るときと同じ服に着替えてみるというアクションをとってみたところ、すぐに適度な緊張状態に移行して開発が捗った。

たぶん休日は一日中ゆるい服装でひきこもってるのがまずかったのだろう。

てきとうに理屈をつけてみると、「服は身体の一部なので、服を変えると身体と不可分な意識もかわってくる」「ズボンで足を締め付けることで物理的な緊張状態が得られる、血行がよくなる」などが思いつく。

逆に、作業をする必要がなく、精神などを回復させたいときはゆるい服装に着替えるとよさそう。平日の帰宅後などは家にいても仕事の緊張が続いてしまうこともあるので、弛緩する施策も大事にしていきたい。

 

さらに、他人の視線があることによっても緊張状態が得られることが経験的にわかっており、例えば職場、カフェ、コワーキングスペース、リモートワークの常時接続がそれにあたりそう。

リモートワークの常時接続は強制的に家を緊張状態にするアプローチで、即効性はあるのだけど、自宅という弛緩すべき場が職場と同等の緊張状態にされてしまうのは、それはそれでストレスがたまりそうだ。

■

たしかに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界はこのくらいとっくの昔に普及してそうだなぁ。

おまけ