GO言語の入門書を読んでたけど、前半で読むのやめた。 出来ることが自由すぎる。何をするにしても副作用が大きいのに、プログラマの作法に頼らないといつ何が起こるか保証が出来ない。 何でこんな言語の人気がナンバーワンなのか、全く理解できない。 てか、…

一番レスポンスが要求されるであろう、receptor → conductor間の通信と、conductor →performer間の通信を考えると、conductorもメインスレッドに置いて、イベントハンドラにコールバック関数を登録する形にするのが一番コストが低い。 が、conductorはactor…

フレームワークとしてはコンダクター(conductor)が主役だなw コンダクターのAPIの出来が成否を分ける気がする。 成否の基準は、自分のやる気が持つかどうか、だけだけどw とりあえず考えるべきなのは、 レセプター(receptor)が叩くAPI パフォーマー(performe…

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

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

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

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

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

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

ということで、パッと見つけることが出来るような人気のフレームワークで、気にいるものは無かったw 趣味でやるソフト開発なんだから、気に入らないものを使ってストレスをためる必要もない。 まずは自分が気にいるようなフレームワークを自作するところから…

趣味のソフト開発を始めるにあたり、いろんな方面のサイトを見て、いろんなフレームワークを広く浅く調べた。 なんかさぁ、 「どのフレームワークにもオブジェクト主体信仰がはびこっていて生産性を下げてるなー」 「ビュー(に混ざったコントロール)に連結す…