ReactのViewとはどこか

  • ReactとVue, AngularはViewコンポーネントソースコードの構造に、JavaScriptが主かHTMLが主かという違いがある
    • ファイル単位としてのReact ComponentはViewだが、より詳細にみていくとrender()のなかのreturnのみがView(狭義)ともいえる
      • ReactはView(広義)までロジックが地続きになる
      • MVVMでのViewModel, ControllerがReact Component内のrender()以外と対応するのかもしれない
    • ロジックが地続きになっていると柔軟性は高そう
      • 柔軟性はコントロールが難しくてカオスになりやすい
      • React Componentの中にほとんどすべてのロジックが書かれたソースコードを我々はたくさん見てきた
    • この処理は間違いなくここ!という切り分けが常にできるとは限らず、現実世界に低い負荷で対応できる点で柔軟性は重要
      • ただし過剰な柔軟性ということもある
      • その他フォルダ問題
  • モジャッ
    • 難しくて思考が発散したので今日はここまで
    • やはりReactだけでフロントエンドGUIはいけるのでは
      • Reduxいらない派

Flowtypeの問題点

利用者のほとんどがOCamlを書けないので、OSSとしてのメリットが減ってしまう構造的問題。*1

*1:issueでflowの設計・実装の問題点についてではなく、いかにエラーを回避するかが議論されててかなしくなった

srknr.hatenablog.com

これを読んで気づいたのが以下。

AppStoreの上位が企業によるアプリケーションで占められているように、いくら生産手段が労働者に属しているとはいえ、分業と豊富なリソースでの殴り合いに個人は勝てない。そういう意味では富と人間を集約した労使関係が必要にはなるのだけど、会社組織の構成員はそれぞれ生産手段を独占しているので、資本家が生産手段を有していた時代に比べるとだいぶ労働者が強く、マネジメント層は労働者と仲良く働いていく必要が出てくる。

基本的にみなさんがエンジニアと呼んでいる労働者は、優秀であればあるほど上司や会社の言うことを聞く必要がない権利を有しているので、優秀な労働者を使ってうまくやっていくには快適な労働環境や労働者が共感できる文化が必要なのだろう。

このことにGoogleは相当前から気づいていたようで、組織に跨る文化を何よりも重視していたようだ。

属人化の問題はどうしようもないので、ユビキタス言語とか言い出した人がいるのかもしれない。

DDDを読んでる途中でのネットワークシステム設計雑感

フロントエンドGUIの設計について考えていたら設計沼にはまり背骨となる思想を求めてDDDを読んでいる状況です。
フロントエンドを含めたネットワークシステム全般の設計についての雑感。

  • RDBのテーブルの抽象としてORMで対応するモデルはドメインモデルではない
    • RDBの制約のうえでの最適な構造と、ドメインモデルの構造は必ずしも一致しない
    • 取れる対処はORMを介さず直接クエリを書いてドメインモデルに変換するか、ORMを使ったうえでテーブル抽象のモデルの上にドメインモデルを組み立てるか
  • サーバはAPIに特化してしまえば、サーバ側にドメインモデルは必要ないか?
  • クライアント(ネイティブ含む)の環境でドメインモデルは?
    • GUIは複雑なため絶対に必要
    • ただし、サーバとクライアントの間で情報を共有するのに、何らかのシリアライズフォーマットを経由する必要があり、シリアライズ / デシリアライズの仕組みが必須
    • ここでJSONの辛さが浮かび上がってくる
    • なるほどGoogleがProtocol Bufferを作るわけだ
  • クライアントとサーバでドメインモデルは同じ構造か?
    • 微妙に違うが同じにできるケースも多いと思う
    • 同じにできなくてもコアの要素集合は近く、生えているメソッドが異なりそう
    • ここでIsomorphicの利点がわかってくる
  • JavaScriptでシステムを書きたいか?
    • 絶対に嫌だ*1
    • できればC# が現実的な選択肢になってほしい……(個人の信仰です)
    • > Scala.js <

以上。

*1:オブジェクト指向で実装するには言語機能が貧弱すぎるため

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

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

 

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

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

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

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

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

 

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

gyazo.com

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

ご覧の通りである。

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

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

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

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

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

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

 

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

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

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で受けられる恩恵は大きそう。