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

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

ソフトウェア開発考

がらくたのイメージ追記

汎用性を考えると、同一ドメインの別ウインドウや別タブと協働できる仕組みも必要だな。 今後の課題として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モデルを否定してるわけじゃないよ。 コンピュータの黎明期から、てかその数学的モデルであるチューリング・マシーンにしてからが、「入力 → 内部状態遷移 → 出力」…

再確認

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

ソフト開発だって製造業なんだよw

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

99里をもって半端とせよw

さくらVPS(開発用サーバー環境)に入れるもの デーモン関係 apache OpenSSL Servlet環境 CGI PHP Perl MySql FTPD 開発ツール Git JDK Kotlin npm nodejs JQuery TypeScript Clang LLVM rust 場合によってはrust-native Webpack2 autoprefixer Babel Browseri…

新しいものが好き

あれだな、これからは JavaScript → Typescript Java → Kotlin C → Rust てことだな

Windows10でのlocalhostの名前解決について

Windows 10でApacheとIISのサーバーを立ち上げ、ローカルホストからのアクセスだけ受け取るように頑張ったw Apacheはバーチャルホストを「127.0.0.1」にして、とりあえずServerAliasで「localhost」を定義したら「http://localhost:ポート」でアクセスできる…

TODO

開発環境に入れるもの クライアント側(WindowsとWSLそれぞれに) SQLServer 2019 IIS apache nodejs MySql npm nodejs JDK Kotlin Webpack2 autoprefixer TypeScript Babel Browserify 2019/8/10 追加 Parcel VSCode プラグイン Easy sass Bracket Pair Color…

こっとり〜ん萌え

何となく調べたけど、Kotlin は結構使える気がする。 サーバーサイドで使ってみたい。 クライアントでは、、、まあいつかはやってみたいかなw

大体のイメージ

色々調べて、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」なわけだ。こう書くと対話型のフロントエンドとバックエンドに見える。 が、実はもっと抽象化できるんじゃね?…

また〜りと

MV-VCでWebAssemble使ったクライアントアプリを作ってみよう。 どうせなら汎用的なギミックにしよう。 と思うけど、まずは手作業で経験を積まないと何が汎用的なのかも分からない罠wrustもnode.jsもPWAもWebassembleも素人だから、ボチボチやるか。どうせ趣…

さらに脱線

メソッド呼び出しが単純なメッセージ駆動より優れてる点は、戻り値を得られること。 メッセージ投げっぱなしだと戻り値をなんらかの方法で待つことになるから、プログラムが複雑になるんだよね。今どきのコーティングだと、 obj.methodA().Iterater().each()…

さらに横道に逸れるけどオブジェクト思考ってナニ?って話し

クラスがどうとか継承がどうとかがオブジェクト思考の大原則ではないことは有名になってきたと思う。私が大学院で研究してきたときは、メソッド呼び出しも本質ではないってのが持論でした。 オブジェクト思考言語においては、「オブジェクトはプロパティとい…

横道にそれるけどMVCと言う集団幻想について笑

MVCって言葉には違和感があるんだよね。 モデル・ビュー・コントロールって実体(オブジェクト)を主体としたネーミングで、ソフトを設計する側もこの常識にとらわれちゃう。 本来、コントロールでのイベント発生時にビューとモデルに通知して、それぞれが自分…

大雑把な目標

MV-VCで考えるなら、VC(画面表示とコントロール)がUI/UX(入出力)担当でMV(擬似画面とモデル)が処理担当だ。 なんかサーバー・クライアントモデルに回帰してるけど、それだけ分かりやすくて実装しやすい気がする笑どうせなら両者ともブラウザで動かす場合も、…