モデルの世界線、、2015.06.23 JST 未明のゆめうつつ

モデルの世界線.md

モデルの世界線

Object Oriented - モデルと密結合な指向

Unix model : resource and operating system

RubyはUnixのメンタルモデルを反映したLispに手続き言語としての構文糖衣をまぶしたもの

• File (Open/Read/Write/Close)-er
• Pipe : standard in , standard out : File discreptor

Rails model : service

POST -> Router 
          |
          V
        Controller <-State-> Stateの永続化：RDBMS
         |  |
GET  <---+  +--> Log : Fluented

RailsのDuck TypingはRPCでもよかった。microsevicesで。これをRubyのreflectionの黒魔術というかlast minutes (or lazy) monkey patchingでやる必然性は無い。少なくとも性能面では。

Phoenix による性能向上

これはRubyの黒魔術とgreen thread (process)モデルの重さを差し引いた分が素直に出てくるはず。

Heroku (Docker, LXC container)のモデル : PaaS : Platform

OSのresourceは消える。ArchitectureのコアはRailsのままでいい。

POST -> Router (暗黙のsupervisor, job queue)
          |
          V
        Controller(Worker) <-State-> Stateの永続化：RDBMS
         |  |
GET  <---+  +--> Log : Fluented

問題はController (Worker)とsupervisor, clusteringがアーキテクチャの重点となってくるところ。

Microservicesの視点　Riak - Bashoのモデル

分割、それはworkerのinterfaceというだけではない。

• Scaleの切り口
• 冗長性、Robustnessの切り口-homeostasisのありかた
  • split-brain
• 契約：ASIDと結果完全性（同時性と相対性）

CONS

ネットワーク通信のLatency, RTTがshared memoryに比して現状ではデカイということ。

この先にあるもの

• Latencyの解消

  • just in place computing

• Storageの再定義

  • PUとメモリの海
  • storageやRDBMSは、問題の形によっては消えるかもしれない。PUとメモリ内のデータの配置がストレージそのもの

• JITする＞結果をFPGAにする

JITがconnectionについて起こる。可塑性

Computingの海に夢が生まれる

computing (PU, Memory)の海に外界の現象のモデルが再現されて、ノイズやcomputing内部の事象を入力として自走（発火）し始め（＝夢）、それが動的平衡を保ち続ける。それが意識、心の実態で、それを言語化されて外界にNotifyされる（computing側から自発的に発せられる）と「意識」「こころ」となる。

サービスはDelphoyの神託となる

神託になる前も外界へアウトプットはあって、外界が作用を受けている。というところはgivenなんでどうしても見落とされがち。

storageやRDBMSは、問題の形によっては消えるかもしれない。PUとメモリ内のデータの配置がストレージそのもの、、というあたりMapReduceなんかとどういう関係になるだろうか、ほかの配置はありうるだろうか？swarm computingはどう実装されるか、とか。

ネットワークの可塑性について、実は深いのだと。脳が卵から発生していき、新生児の状態から拡充、そして結線が変換していく過程について、どんな構築アルゴリズムが実態に近いのか、そしてそのアルゴリズムが進化の過程にどれくらいしがらみを受けているか、というあたり、まだ完璧にわかっているわけではない（Networks of the Brain)。もちろん、それにこだわることなくやってみてもいいが、実際に動いているものをちゃんと研究しないってのはナシだろう。