いっせいの!!細かなつぶやき

細かなことをぽつぽつと呟いてます

メッセージ駆動プログラミング

CRAPモデルの概要

CRAPモデルについて 概要 オブジェクト指向的概念のMVCをメッセージ駆動概念に置き換える試み。 (C)「コンダクター(conductor)」 メッセージを調整して各ユニットと授受する指揮者 (R) 「レセプター(receptor)」 画面からの入力を受け取りコンダクターに受け…

がらくたのイメージ追記

汎用性を考えると、同一ドメインの別ウインドウや別タブと協働できる仕組みも必要だな。 今後の課題としてw まあ、この考え方だと、conductor間の通信って形になるよなぁ

がらくたCRAPのイメージ

ユニットの概要 役割 スレッド 機能 receptor メイン UIによるイベントを受け付けてconductorに渡す performer メイン conductorからの指示によりDOMを操作する conductor WORK 各ユニットから通知を受け取り、調整して、必要な通知を飛ばす actor(s) WORK …

がらくたモデル (もしくは鯉)

DOMを扱う以上、パフォーマーがメインスレッドになるしか選択肢が無い。 画面入力を受け付けられるのもメインスレッドだけ。 となると、コンダクターはイベント全般を適切に管理するイベントマネージャーに徹するべきかもしれない。 画面入力受け付けは、別…

CAPモデルとworkerの仕様の齟齬w

ブラウザ上でCAPモデルを使うとするじゃん? シングルタスクで動かすわけないから、workerを使ってマルチスレッド化するじゃん? CAPモデルでは (C)コンダクター ⇆ (A)アクター (C)コンダクター ⇆ (P)パフォーマー の通信を行うんだから、コンダクターが親に…

CAPモデル

私が思うに、まずは分業体制の観点から、入力、内部状態遷移、出力は、完全に分離されなければならない。 また非同期処理について人間が(なるべく)意識せずに済むようにしなければならない。 分業体制を考えるにあたり、 (C)コンダクター 入力機能。(コント…

ノット MVC

何度も同じ話するけど、私は、MVC(モデル・ビュー・コントロール)って考え方はしない。 MVCモデルを否定してるわけじゃないよ。 コンピュータの黎明期から、てかその数学的モデルであるチューリング・マシーンにしてからが、「入力 → 内部状態遷移 → 出力」…

大体のイメージ

色々調べて、UX/UIはCSS3+HTML5を中心に考えることにした。 直接的な処理言語はTypeScriptにしよう。 CSS3についてはie11を無視できないとなったら変換ツール使う。 TypeScriptについてもE5に変換することを検討 あくまでUX/UIはバックエンド処理とはメッセ…

MV-VCモデル構想 003

JavaScriptのWorkerを使えば、ユニット毎にスレッドを分けてメッセージで駆動連動する並列処理が出来そうだ。 Web assemblyで使えるのか若干不安だけどwDOMに関しては子スレッドになるWorkerでは操作できないそうなので、ビューに相当するUI/UXが親スレッド…

Javascript による並列処理

Javascript で並行処理解説 概要 連絡は専用のメッセージ処理で Worker - Web API | MDN Web Workersを用いてJavaScriptをマルチスレッド化する JavascriptでWorkerを使った並列処理 (親スレッドから複数分岐可能。ただしシェアは出来ず)スマホ含めて対応済…

MV-VCモデル構想 002

なんか「オブジェクト」って名前で呼ぶとイメージが引きずられるな。 別の名前を考えないとな〜 ビューにせよ、コントロールにせよ、モデルにせよ、バックエンドに居る(仮想的な)サーバー群にせよ、当面これらをユニットと呼ぼう。 ユニットのザクッとしたイ…

MV-VCモデル構想 001

ザクッとMV-VCと言うけど、もう少し考えてみる。要するにUI/UX部分を「VC」って呼んでる。 で、その操作の結果に従って状態変化する部分が「MV」なわけだ。こう書くと対話型のフロントエンドとバックエンドに見える。 が、実はもっと抽象化できるんじゃね?…