8月から仕事がWeb系のコンテンツ開発になりまして、
既存と新規のコンテンツに混沌としつつも、主にFlashのActionScriptを書く日々を送っています。
Macromediaの提唱するRIAをやりたいとは思っていたけど、
実際に作ったのは納品するプログラムの操作マニュアルのムービー(ここをクリック、ここをドラッグ、さあやってみよう! …)とか。
まあ、頑張るしかない。
ActionScript2.0はJavascript2.0のサブセットであるECMAScript 4ベースで、
Subclass extends Superclass {
}

構文とか、try..catch..finally節とか、Javaライクでして、以前のActionScriptの
プロトタイプベースのプログラミングに慣れた身としてはちょっとペースが狂います。
なんといっても
Object.prototype.helloworld = function() {
    trace("Hello, world!");
};
とランタイムに定義すれば、全てのオブジェクトがhelloworld()メソッドを持つ、
という言語環境でしたからね。ActionScript 1.0までは(こちらはECMA262-3ベース)。
2.0でもプロトタイプベースであることには何ら変わりはないものの、動的に親クラスにプロパティを定義(注入)するようなコードは、
構文チェック時に弾かれるようになりました。
ちょっとだけ静的なフレーバーが増したという印象が今のところあります。

まあそれはさておき、納品するコンテンツの作成で困ったことが発生。
帯域が厳しい環境も考慮して欲しい、と要求が来まして、
具体的には厳しい帯域とは56kモデムの接続環境を指すんですが、
その「厳しい帯域」のシミュレーション(と環境構築)が･･･困難!

Flashは読み込み時に何パーセント読み込まれたかを表示する「プリローダ」を
組み込んで、待ってもらう際に進捗がわかるように作るのが定番ですが、
その動作の検証も低速な環境がないため、あまりうまくいっていなかったのです。
そんな事もあり、ちょっとがんばって低速で応答するHTTPサーバを建てる事に。

社内LANは速すぎるし、かといってすぐ利用できる低速なIP環境(SLIP等)も無いときた。
遅いデバイスといえばまず思い浮かんだのはフロッピーでした。
コンテンツをフロッピーにコピーした上で、そのファイルを開けばいいじゃないか、と。
が、これはあっさり却下に。
フロッピーからのデータは非同期で送られてこないので、
ファイルを開く関数のコールすると、何時までたっても返ってこないではないか。
ファイルの中身が全部読み込まれてから、ようやく返ってきた。これじゃあ駄目だ。
データのストリームが少しずつ送られてくる状況が必要なのに。

SLIPやPLIPも考えたけど
(そういやAmiga3000にEthernetカードが無いので、PLIPでLinuxに繋いでから
  インターネットに出て行ったんだっけなーと、遠い目)、
やっぱ面倒。
物理的に2台のマシンをあんまり長くも無いケーブルで繋ぐ必要があるのはちょっと･･･。

ググったところ、Sloppyという、ある程度低速に振舞う、
Javaで書かれたクライアントサイド(?)のProxyらしきものも見つかったのですが、
手軽感が沸かずパス。

その後もうろうろと思いをさまよわせたあげく、
結局ふと思い出したACME Laboratoriesのthttpdの導入に決定。

うーん、長くなりそうなので、詳細は次のエントリへと持ち越し決定。