http://d.hatena.ne.jp/m-hiyama/20081120/1227159984 :
全体で90分、質疑応答でだいぶ時間を使ったので、スライドにあることを全部しゃべったわけではありません。特に、後半の Web Communication Channels は簡単なデモをしただけでした。機会があれば、もう少し説明したいと思っています。
「ちゃんと準備をしてから」とか言っていると来年になりそうなので、年内にやります。12月20日(土曜)午後にやります。
- 日時：2008年12月20日(土曜日)
14:0015:00 より - 時間：150分程度を予定
- 場所：(株)シンメトリック（安達ビジネスパークビル）3F
- 最寄り駅：小田急・代々木八幡駅、千代田線・代々木公園駅
- 地図：Googleマップ
- 定員：20人（空間と椅子に起因する上限値です）
- 申し込み：メール、またはPayPal寄付
- 必要なもの：なし
内容的には、次のエントリ（時間順）で書きかけになっているようなことです。
申し込みは、subjectに文字列「参加希望」を含めて、hiyama{at}chimaira{dot}org にメールください。本文はなくてもかまいません（あってもいいです）。[追記]檜山が目で見て手で返答するので、処理が遅くなることもあります。ご了承ください。[/追記]
面倒でまだセットしてないのですが、明日とかに有料にしますよ（[追記 date="翌日"]やっぱり面倒だー、法律で決められた文面とか必要なのかも。[/追記]）。これ、煽りとかじゃなくて、PayPal課金を試したいので、申し込み＝PayPal送金 にします。ただし、金額は任意ですけど。
[追記 date="2008-12-12"]結局、申し込みは寄付方式にしました→詳細。あと、メールだけでもOKです。[/追記]
ここから下（続き）は、PTTのときのスライド原稿の一部です。これに沿ってやる気はありませんがやるかもしれません、多少の参考にはなるでしょう。
ことの発端
- Webアプリケーションとはいうが…
- 作る（or 作らせる）のはWebサイト所有者
- ブラウザ利用者はサイトと独立にアプリケーションを作れないの？
ブラウザ上のアプリケーション
- GUIはHTMLレンダリングエンジン
- 実装言語はJavaScript
- ストレージがない
- 実は自発的に通信もできない
- Ajaxは？
- サイトに依存し縛られる
通信機能とストレージ
- 中立な中継サイトを設けて、できるだけ透過的にブラウザ-ブラウザ通信をサポートする。
- 永続的なストレージも提供する。
- クロスドメインHTTP通信が必須
- 現状、変な方法しかない -- 悲しいがしょうがない
- 逆方向（サーバー --> ブラウザ）通信も必要 -- COMET
- 参考： http://d.hatena.ne.jp/m-hiyama/20080528/1211950144
別な動機
- サーバー側もJavaScriptで書けたらいいじゃない？
- -- 既にあるけどあんまり流行ってない
- JavaScriptプログラムがローミングしたら面白いのでは？
- そりゃ無理でしょ
- JavaScriptの小さな小さなサブセットくらいなら、、、、
- この未練は今でも尾を引いている
Erlangがお手本
単に実装言語としてだけでなく、分散モデルも借用。
| Erlang | WCC |
|---|---|
| 分散ノード | ブラウザもノード |
| プロセス | エージェント（動作主体） |
| PID | エージェントID（AID） |
| メッセージ | マイクロ・メッセージ |
| ターム | JSONデータ |
| gen_server Call | RGenic Call |
| gen_server Cast | RGenic Cast |
アリモノをツギハギ
- JavaScriptのイベントモデルはW3C DOM3から
- 外部からのコールバックはActionScriptのExternalInterface
- データ形式は徹底的にJSON、ただし抽象的データ形式として
- OMG IDLのサブセットで仕様記述の予定（全然できてない）
100%コンフォーマントはめざしてないが、それでも標準と折り合いを付けるのは大変。用語の混乱やネーミングの理不尽さに泣く、泣く、泣く。
COMET
- 原理は簡単
- やってみると、ブラウザごとの挙動の違いに泣く
- JavaScriptのシングルスレッドにも泣く -- IOブロックとかsleepしてポールとかができない
- On Demand JavaScript方式（a.k.a JSONP）とCOMETを組み合わせて、なんとか双方向通信、… くっ、苦しい。
COMETは資源を消費する
いっぱいプロセスやスレッドがいるぞーー。が、Erlangなら、、、
- http://www.sics.se/~joe/apachevsyaws.html Apache vs. Yaws -- Apache が同時接続数約4千で応答なし、Yaws 同時接続数8万以上(?)まで応答。
- http://groups.google.com/group/comp.lang.functional/msg/33b7a62afb727a4f?dmode=source 2000万個のプロセス(64-bit erlang on a 1.5 GHz SPARC with 16 GB RAM)
Erlangで作って感じたことは
- たしかに考えやすい、作りやすい
- 他の言語とものすごく変わるわけではない
- スレッドのような難しさはない
- 静的な型概念、型チェックがないのは痛いときもある
- YAWSというプラットフォームもあることだし、Webアプリケーションには向いているのではないか
- 逆に、Web的手法がErlangプログラミングに生かせることもある
- テンプラもよろしくー
- 500メッセージ／秒くらいはさばけそう
- フォールトトレランスや実行時コード置き換えは今後
- 最近やっと「不要なことは書かない」「いさぎよく死ぬ」「一人で死ぬ」が分かってきた。これは、Erlangのポリシーで納得が難しい部分。
アプリケーション
- ジャンケン大会が最初設定した目標だった
- 多人数でやるクイズやゲーム
- 同時アンケート／投票
- ブラウザ・サーバー（「神社」とか）
- ブラウザ不在時はスクリプトで動く（と、いいな）
