C#続き
目的がプロトタイピングなので、細かい問題はさておき、必要となる技術一通りの動作が確認できれば良いわけで。
何のためにやってるのか
目的は、「一つの画面全体に任意の表示を好きなタイミングで表示できること」こう書くと簡単に思うが、
- その画面には余計なものが表示されないこと
- 別のブラウザでの操作・処理に同期して表示が更新されること
- 見栄えをよくできること
- 表示内容は容易に更新できること。できれば動的に生成したい。
といった制約がつく。PCにセカンダリディスプレイを接続するだとか、専用アプリで画面表示するだとか、色々考えた。この方式とするにあたっては
「C#使うなんて」「あり得ないでしょ」「バカかと」
「なんでわざわざ工数増やすの」「無理」
といった言葉を浴びて「責任は取るから」と私が強引に押し通した方式。だからプロトも重要。しかも時間をかけられない。3日でここまでだけど、これでも時間がかかってると思ってる。
実際何をしたのか
さて、ここ3日間でやったこと
- 関係ありそうなサンプルを探す
- Peer Messenger (C#)
- IP Messenger (C++)
- Visual Studio のメディアを作る
- インストールする
- C#の入門ページを探して読む
- IDEで特定URLを最大化状態で表示するフォームを作って動作確認
- 直接記述したコードはゼロ
- これを基に作っていく
- Peer Messengerをsvnで取ってくる
- Peer Messengerをビルド
- Peer Messengerで日本語が通るように修正
- Peer Messengerの動作の流れを追う
- (ここでdelegateにひっかかる)
- Peer Messengerからコードをどんどん組み込んでいく
- メッセージを受信したらブラウザ画面更新するようにコードをちょろっと書く
- 適当にリファクタリングしながらC#の癖を勉強
- きちんと終了しなかったところを修正
- メッセージでURLを受信したらそのページを表示するようにコード追加
- メッセージを受信したら音を鳴らすようにコード追加
- 特定メッセージ受信でプロセスが終了するようにコード追加
- 受信したメッセージの処理が終わったら返信するようにコード追加
- ESCキーで終了するようにコード追加
- WebBrowerコンポーネントだとキーを全部消費してしまうので対策を調査
今ここ。
まぁ順当な結果か。使った感想は「Javaと同時にやってると混乱しそう」。これも目論見どおり。先にやってて良かった。これで遠隔PCに好きな画面を表示できるお膳立ては完了。あとはこれを制御する側のJavaコードのプロトを用意するだけだ。
なぜこの構成としたのか
この構成に至るまでの思考のフレームワークをたどってみる。
(1)同一PCに縛られる必要はない
まず、別のブラウザでの操作に同期するという点から、デュアルディスプレイでなんとかしたくなる。が、ブラウザはカスタマイズできないものと考えているので、同一PCの別ディスプレイであろうと非常に面倒くさいことになる。
(2)無駄なものは表示しない
そして画面表示は仕組みなどまったく知らない(知る必要もない)人々に対してのものであるため、余計なものは出したくない。タイトルバーやらスクロールバー、マウスポインタですら。この部分の優先順位は低くない。そうすると画面表示はブラウザを最大化したものでは事足りない。更に言えば外部要因で表示を更新するのだからブラウザでは難しい。解決できたとしてもタイムラグは免れない。となればプログラムを作ることは必須となる。
(3)表示の柔軟性が必須
次に画面表示する内容だが、これは現時点で何も決まっていない。仕様すらない。そして画面数はかなり多い。動的に表示内容をカスタマイズする必要性すら予見されている。つまりVBのラベルを並べたみたいなものじゃ無理ということ。なんらか外部ファイルを使って表示するのが最低ライン。もちろんカラフル、きれいという必要性も存在する。ということはHTMLが最適解ということになる。
(4)分離可能であるべき
この画面は実はオプショナル的存在と考えている。利用形態によっては必要なしとなる可能性も考えている。存在を前提としたシステムではまずいということである。
(5)分割してテストすることが可能であるべき
今回は仕様がまだ決まっておらず、またシステムとしては結構面倒な構成なので、この部分くらいは分離してテストしたい。独自でガチガチのプロトコル実装でも良いが、時間が足りないこと、そしてテスト環境の構築という問題から、既存のプロトコルに乗っかったほうが幸せであると判断する。
(6)同期をとる仕組み
2つのブラウザウィンドウを表示し、片方からもう片方を制御するという方法は考えられなくない。が、制御のための仕組みが大掛かりになること、(4)などの事を考えると問題があることから却下の方向。ポーリングによって同期を取る方法もあるが、長期的な負荷が問題となる可能性、サーバダウン時の挙動などから取りたくない手法である。よってアプリケーションサーバ側からのPUSHによって更新というが一番素直であるし、望ましい方法だと考える。
(7)端末の耐障害性
端末は長い時間稼動することとなるため、障害発生時にはすぐ交換可能である必要がある。つまり特殊な構成は難しいし、OSもできればWindowsであってほしいし、インストールが必要なものは最小限であってほしい。
(8)開発期間・コスト
今回の開発は既に厳しい事が予測されていて、無駄な時間をかける余裕はない。
となると？
(1)で同一PCとなるとPCの構成に対する制約が発生する。また(2)の問題に引っかかるし、(6)を考えてみても同一PCにする理由はコスト以外には見当たらないと考えるのが順当。
(3)から何らかの既存ブラウザのレンダリングエンジンを使うことが順当であり、そのデータはアプリケーションサーバ側に持つ事への問題は何も見当たらない。
(2)(6)からブラウザ単体とするのは非常に困難であり取るべき選択肢ではない。となると(7)(8)から、WindowsのGUIで動作する難易度が低いプログラム言語で、ブラウザのレンダリングエンジンをコンポーネントとして組み込めるものをつかって開発するのは当然である。候補としてはVB、C#が残る。
(4)(5)の条件に合致するのは、HTTPdあるいはIP Messengerが考えられた。しかしHTTPdの場合、HTTPdのインストール以外にCGIなどの開発、そして画面GUIの3つが必要である。それに対しIP Messengerは「基本がUDPプロトコル」「端末のIPアドレスに縛られないIDが存在する」「軽量なソースコードがオープンソースとして提供されている」という点で最適と判断。
IP Messengerプロトコルを実装したオープンソースなコードはVC++、Java、C#、VBが見つかったが、ある程度ちゃんと実装されているっぽいこと、ゆるいライセンスであることなどからPeer MessengerのC#を採用することとした。
というわけで
C#を使ったことすらないのだが、とりあえず動作するプロトタイプは満足いく時間でぶち立てられたし、運よくJavaのソースがあることからアプリケーションサーバ側も早期にプロトを作れそうだ。
半年後、この決断の真価が問われることになる。
