WebGL版です。

クリックで別ウインドウで開きます。

今回は、はじめてHTML5を触ってみた中でわかったことを書きたいと思います。

HTML5でJavascriptからグラフィックを操作するには、従来のdivの操作に加えてSVGとCanvasを使う方法が加わったらしく、とりあえず今回はCanvasを使ってみました。

3Dライブラリthree.jsについて

ご存じのとおり、SVGはベクターを扱うタグでして、Canvasはピクセルを扱う場所になります。AS3だとベクターもラスターもどっちもよく扱うのでJSでも出来るんだろうけど流石に今回ピクセル操作ばっかりプログラミングするのは面倒くさかったので何かいいライブラリはないかと思っていると、どうやら3Dのライブラリthree.jsが何やら面白そうです。
ある程度のJavascriptの知識と、3Dライブラリを使ったプログラムの経験があればすんなりと使うことが出来ました。
がんばってAPIを掘り下げれば、かなり面白いものが作れそうです。

注意すべき点は、たぶんバージョンアップのためだと思うのですがAPIの仕様が変わっていて、古い解説文書などですと動かない場合があることです。
あとどうしてもドキュメントが少ないので、特にリファレンスが無いと何も出来ない僕にとっては、慣れ親しんだASDocくらい詳しいリファレンスが無いのが地味に大変でした。

ただし、クラス名やプロパティに変な癖も無いのでリファレンスが足りて無くても何とかなりました。
一般的な3Dライブラリと似たような感じで

• シーンを作って、カメラを作って、レンダラーを作って
• シーンや表示オブジェクトは入れ子構造にできて
• ジオメトリとマテリアルを持つメッシュを作成して表示オブジェクトに追加
• シーンとカメラを指定してレンダリングを実行

という、ごくごく自然な流れでプログラミングできました。

面白いことに、WebGLでレンダリングするレンダラーと、素のCanvasにレンダリングするレンダラーがあるんですが、その二つをかなり簡単に切り替えられるんです。
ここらへんは型付けがゆるいJavascriptならではの面白みだと思いました。

制作環境について

かなり残念な英語力と記憶力、たぐいまれなるタイピングミスの持ち主の僕にとって、開発環境こそが頼みの綱です。
今回は@kotaro_tanさんに教えて頂いたWebStormというIDEを使ってみました。

なにやらかっこいいクラスを作ってるなう

Javascriptをクラスで開発していくことについて

前回の記事「Actionscript3erが覚えるJavascriptでのクラス開発まとめ」でJavascriptでクラスを作って開発するスタイルをまとめてみたわけですが、手前味噌ながらこれが非常に役に立ちました。
javascriptにはjavascriptの面白さがあるので、AS3のクラスっぽい作り方が無理矢理なのであれば何もわざわざjavascriptの面白さを消してまでクラス作りをする必要は全くないと思っていたのですが、無理矢理どころかむしろだいぶ自然にクラスが使えたので、だいぶ効率よく作ることが出来ました。
後述するjsファイルの重複ロード問題も今回はクラスを使って解決できましたし、デザインパターンが使えるのもなによりうれしいひなまつりです（こんど娘が初節句なんです。楽しみで楽しみで）。
クラスは僕も最初かなり苦手意識を持っていましたが、品質を上げるための先人の知恵の結晶なので今後ももっともっと勉強していきたいです。

Javascriptのゆるさについて

Javascript特有の「ゆるさ」は長所でもあり短所でもあるんですが、久々にまあまあの量のJavascriptをコーディングして、このゆるさもかなり楽しめました。
個人的にはガチガチの型付け言語をガチガチのIDEで扱った方が実質的なコーディング速度は速いと思うんですが、Javascriptの設計のゆるさからくる「アイデアが形になるまでの速度感」はAS3とはまた違った面白さがあります。
AS1の頃の面白さとHTML5の新鮮さの良いところどりはずるいと思います。

javascriptの楽しさをたっぷり楽しんだ上で、今後の課題も書き留めておきたいと思います。
あくまでActionscript3よりな人間が久々に遊びでJavascript触ってみて対応というか妥協した程度の記録ですので、今後かならず解決するべきだしもっといいノウハウは他にあるはずです。

変数やオブジェクトがいくらでも上書きできてしまう

定数は無理としても、prototypeに閉じ込めるなどしてprivateな空間は作るべきなのでしょうが、今回はそこまでしませんでした。変数のアクセス範囲を出来るだけ狭くすることが鉄則なのに、非常に悩みどころです。

名前空間について

いちおう最初のファイルに

if(!jp_utweb_namespace){
    var jp_utweb_namespace = {};
}

こういう事書いておくことで「俺はグローバルの名前空間をあんまり汚染しない男だぞ」アピールをしているのですが、正直気に入っていません…。
最低でもプロジェクトごとにも別けたいし、ネームスペースの変数名そのものを持ち回りたいんですが、そこらへんは今後の課題として残りました。

重複ファイルのロードについて

こういったjavascriptファイルがあったとして、
onece.js

;(function(ns){
    alert('一回しか実行を想定していない処理！');
})(jp_utweb_namespace);

HTMLで二回読み込まれてしまうと

当然二回実行されてしまいます。
実行前にDOMを調べて、src属性に自分のファイル名と同じscriptタグが２つ以上ある場合は一回しか実行しない、といった処理をすればいいのですが、うまくライブラリ化できなかったので、それは今後の課題になります。

今回とった方法では、クラスを作成する処理ばかりにしておいて、最後にrun.jsというスクリプトファイルのみ、重複チェックを行って、ActionScriptでいうドキュメントクラスに相当するクラスを一回だけ実行する、というやり方にしました。

クラスを作成する直前に

;(function(ns){
    if(!!ns.Mein){
        return;
    }
    ns.Main = functino(){};
})(jp_utweb_namespace);

こんな感じでチェックを入れても良かったのですが、タイプミスなどによるデバッグがしづらくてかえって危険なのでやめました。
実際に上のコードはこんなに短いのに見つけるのが困難なバグがあります。
ここは素直に

;(function(ns){
    ns.Main = functino(){};
})(jp_utweb_namespace);

こう書くことにしました。
重複ロード時にクラスが複数回生成されてしまうコストが発生しますが、プログラムの意図しない箇所でバグるよりはマシかと。

まとめ

いまのところまだちょっと触って遊んでみた程度ですので、今後案件に投入できるかどうかの判断もまだ現段階ではつきませんが、面白い技術であることには間違いないです。
少なくともWEB上でリッチなインターフェースやモーション、体験を作るということにおいてはActionScripterこそ親和性の高い技術なので、これからどんどんと横断的に開発できるノウハウを見つけ出してハイブリッドな開発者がたくさん増えると面白いかと思います。

そこでJavascriptでクラスを作ったりするときに「あれ？ASだとこうやるやり方、JSだとどうやるんだっけ」ってのを減らせるように、完全に個人的な備忘録を作ってみました。自己流なうえにオレオレ規約ばっかりで恥ずかしい限りですがせっかく作って公開したのでなんらかのお役にたてばうれしいです。

Javascriptでのクラスの作り方は本当にたくさんの方法がありますが、その中で僕が一番馴染んでいる書き方だけを勝手に選んでのせています。
さっきふと思い立ってやった方法をそのままばんばんのせている感じです。
あと、JSとの類似性を浮き上がらせるためにASにはあえて型を宣言しないで書いています。
ASやJSの綺麗なコードの書き方ではなく、あくまでもASに似せたやり方でJSを書いていく方法を探った記事ですのでご了承ください。
あと、技術書でも何でもなくあくまで個人の備忘録ですので恥ずかしながら盛大に間違えている箇所がたくさんあるかと思います。その場合間違いは常に正していきたいのでご指摘頂けると大変嬉しいです。
ほんと僕のブログ間違いもおおいんで前置きも長々となってしまってすいません。

同じ処理を最初にAS3、次にJSの順番で書いてみたいと思います。

クラスを使ってみる

クラスを使う方法はまさに全く同じです。
actionscript3

//インスタンスメンバを使う場合。
var d = new Date();
trace(d.getTime());
//クラスメンバを使う場合。
trace(Math.random());

javascript

//インスタンスメンバを使う場合。
var d = new Date();
console.log(d.getTime());
//クラスメンバを使う場合。
console.log(Math.random());

つまり作り方の違いさえうまく吸収できれば、クラスを使うぶんにおいてはほぼ全くといっていいほど同じように使えるようになるってことではあーりませんか。
こりゃいいや、さっそく作り方をまとめてみよう。

クラスを作ってみる

AS3のほうは意図的にpackageブロックを書いていません。
actionscript3

public class Human {
	public function Human() {}
}

javascript

/**
 * @constructor
 */
function Human(){};

Javascriptではfunction宣言するだけでクラスが作れます。この部分がそのままコンストラクターになります。
作ったクラスは先ほどみたいにASでもJSでも全く同じように

var John = new Human();

こういうふうに使えるようになります。

プライベートプロパティ、プライベートメソッドを作ってみる

JSでは言語としてprivateをサポートしてないっぽい？
言語がサポートしていない以上、なんとかして隠匿化するコードを書いた方が良いのかもしれませんが、個人的にはオリジナルで処理を組むよりは規約を作ってこういったチェックツールに頼る方が好みなので、JSのほうはGoogleのコーディング規約を参考にこうしてみました。
まあClosure Linterまだ使ったことないですが。
actionscript3

public class Human {
	public function Human() {}

	private var himitsu_ = 'わりと最近うんこをもらした';

	private function think_() {
		trace('（´-`）.｡oO（蛇口からビールが出ればいいのになあ…。');
	}
}

javascript

/**
 * @constructor
 */
function Human(){
    /** @private */ this.himitsu_ = 'わりと最近うんこをもらした';

    /** @private */ this.think_ = function() {
        console.log('（´-`）.｡oO（蛇口からビールが出ればいいのになあ…。');
    };
};

JSのほうは、コンストラクタ内で宣言することで「これはプライベートな空間なんですよ」と（自分が）強く思い込むことにしました。

2012/01/29 追記
コンストラクタ内でvar で宣言しておいて、getter/setterで操作するってやり方を今知りました。うーん、それ使うかどうしようか迷う…。

2012/01/29 さらに追記
さっそく@taikikenさんからpublic/privateをわける方法を教えて頂きました。
ツイッター
JavaScriptでOOP – Classみたいなのにprivateな関数と変数 | イナヅマtvログ
コンストラクタ内でvarでプライベート宣言しておいた上で、mainというfunctionもprivateで保持しつつそこのprototypeにpublicな変数と関数を入れておいてreturnするというやり方ですね（僕が言葉にするとかえってわかりにくいですが教えて頂いたコードはすごい明快です）。プロトタイプベースのクラス、奥が深い！

パブリックプロパティ、パブリックメソッドを作ってみる

JSがprivateをサポートしていない（未確認）以上、publicもファブリックもあったもんじゃない（最近IKEAに行きました）のですが、JSのほうではprototypeに宣言することで「これはパブリックな空間にあるんですよ」と（自分が）強く思い込むことにしました。
actionscript3

public class Human {
	public var syumi = 'プリクラ集め、水に向かって綺麗な言葉を言い続けること';

	public function work() {
		trace('|^o^|＜ひきこもりぎみなのでそとをあるくのはにがてです');
	}
}

javascript

/**
 * @constructor
 */
function Human(){};
/** @public */ Human.prototype.syumi = 'プリクラ集め、水に向かって綺麗な言葉を言い続けること';

/** @public */ Human.prototype.work = function() {
    console.log('|^o^|＜ひきこもりぎみなのでそとをあるくのはにがてです');
};

スタティックなプロパティやメソッドを作ってみる

JSではクラス（正確にはFunctionオブジェクト？）に直接定義することでstaticになりました。
actionscript3

public class Human {
	public static function help() {
		trace('困ったときはお互い様。');
	}
}

javascript

/**
 * @constructor
 */
function Human(){};
Human.help = function() {
    console.log('困ったときはお互い様。');
};

助け合いの心は人が誰もが持っている心。美しいですね（美）

継承してみる

僕の作ったクラスがだいぶ人としても完成されてきた頃なので、ここらで継承して新たなクラスを作ってみたいと思います。
actionscript3

public class Hentai extends Human{
	public function Hentai() {}

	public function zenra() {
		trace('╰⋃╯');
	}
}

javascript

/**
 * @constructor
 * @extends {Human}
 */
function Hentai() {};
Hentai.prototype = new Human();
Hentai.prototype.zenra = function() {
    console.log('╰⋃╯');
};

Javascriptでは新たなクラスのprototypeにスーパークラスをインスタンス化させると継承できました。

オーバーライドしてみる

JSはそのまま親クラスを上書きするだけとしています。
actionscript3

public class Hentai extends Human{
	public override function work() {
		//super.work();
		trace('三╰⋃╯');
	}
}

javascript

/**
 * @constructor
 * @extends {Human}
 */
function Hentai() {};
Hentai.prototype = new Human();
/** @override */ Hentai.prototype.work = function() {
    //this.constructor.prototype.work.call(this , arguments);
    console.log('三╰⋃╯');
};

インターフェースを使ってみる

JSではインターフェースもサポートされていないので、インターフェースに似たふるまいをするコードを書くか書かないか、書くとしたらどこまで書こうか、ここ一番悩んだんですが、結局コードとしては一切書かないことにしました。
だいたいこの辺の記事を参考に、規約で実現する方法を探っているところです。今のところコメントにinterfaceと書いてるだけですが。
actionscript3

public interface IBijin {
	function yasashii();
	function iinioi();
}

public interface IIsya {
	function care();
}

public class Jyoi implements IBijin, IIsya{
	public function Jyoi() {}
	public function yasashii() {}
	public function iinioi() {}
	public function care() {}
}

javascript

/**
 * @interface
 */
function IBijin() {};
IBijin.prototype.yasashii = function() {};
IBijin.prototype.iinioi = function() {};

/**
 * @interface
 */
function IIsya() {};
IIsya.prototype.care = function() {};

/**
 * @constructor
 * @implements {IBijin, IIsya}
 */
function Jyoi() {};
Jyoi.prototype.yasashii = function() {};
Jyoi.prototype.iinioi = function() {};
Jyoi.prototype.care = function() {};

こんな感じでしょうか？コードがなんかだいぶ投げやりになってきたなあ。

さいごに

僕がまとめた限りではまあだいたいこんなものではないでしょうか。
無理矢理にしてまでJSをASのクラスライクに書いていく必要はないと思いますが、わりかし自然にASっぽく書くことも出来なくはなさそうな感じはします。
今話題のArctic.jsやenchant.jsなど（ふたつとも僕はまだ残念ながら使えていないんですが）のようにASライクに書けるJSのライブラリも増えてきましたし、とりあえず横断的に開発してみたくてまとめてみました。
ASもそうですがJavascriptも独学の完全自己流なので本当は晒せるほどは自信がないですが、何かしら役に立てばなによりです。

1. ObjectタグのIDのどこかに「external」を入れる。
2. Javascriptの名前空間を出来るだけ汚染しない。
3. 初期化の実行順序を守る

2011/10/23 追記
ひろゆきさんに教えていただいたんですが（こちら）、IDに「external」を付けなくても動くそうです。

AS側でやっといて便利なのは次の点です。

1. JavaScriptとの連携は必ずシングルトンを介して行う。

順番にみてみたいと思います。

Cap1.ObjectタグのIDのどこかに「external」を入れる。

こちらの記事にあるように、IEのアホウはトンマなヤロウであるわけです。
本来ならばIEのマヌケなバグにこちらが付き合ってやるいわれはないわけですが、ObjectタグのIDのどこかしらに「external」と入れてやれば万事解決するのであれば、そうしてやろうではありませんか。
それが大人というものではないでしょうか。
なのでSWFObjectの記述はこんな感じになるかと思います。

;(function(){
	var swfDirectory = "/";
	var swfFileName = "index.swf";
	var targetId = "flashcontent";
	var width = "800";
	var height = "600";
	var version = "9.0.45";
	var expressInstall = swfDirectory+"commons/scripts/swfobject/expressInstall.swf";
	var flashvars = {};
	flashvars.jsNamespace = "jp_utweb_ExternalInterface_sample";
	var params = {};
	params.menu = "false";
	params.quality = "best";
	params.scale = "noscale";//showAll
	params.salign = "tl";
	params.wmode = "transparent";//opaque wmode
	params.swliveconnect = "true";
	params.allowfullscreen = "true";
	params.allowscriptaccess = "always";
	params.allownetworking = "all";
	var attributes = {};
	attributes.id = "external_content";
	attributes.name = "external_content";
	attributes.align = "middle";
	swfobject.embedSWF(swfDirectory+swfFileName, targetId, width, height, version, expressInstall, flashvars, params, attributes);
})();

まずは22行目、23行目、ObjectのID属性に「external」が出現していることに注目してください。
10行目の

flashvars.jsNamespace = "jp_utweb_ExternalInterface_sample";

は次のCap2で説明します。

Cap2.Javascriptの名前空間を出来るだけ汚染しない。

基本的には匿名関数とか使って、ぱっと実行された間に必要なときだけ呼び出されてあとは何事もなかったかのようにぱっと消えるのは格好良いんですが、ASからJSを呼び出そうとした場合、いろいろ試してみたんですがどうしても最低ひとつはJSの名前空間を汚染する必要があるという結論に至りました。
これに関しては結構いろいろためして、一見して無駄だと思えるような、匿名関数の中でSWFObjectを実行してその中でSWFはJS側の関数を呼ぶことで全く名前を消費しない方法を使えないかとかいろいろ試したのですが僕のスキルではどうにもならず、結果としてどうしても一個だけ名前を消費する方法しか作れませんでした。
これがそのJavaScriptのテンプレートです。

;var jp_utweb_ExternalInterface_sample;
(function(){
	this.getElementFromName = function(name){
		if (navigator.appName.indexOf("Microsoft") != -1){
			return window[name];
		}else{
			return document[name];
		}
	};
	jp_utweb_ExternalInterface_sample = function(){};
	jp_utweb_ExternalInterface_sample.ready = function(){
		//ActionScriptが実行可能状態になったら最初に呼び出される。
		//JS側からAS側に関数を呼び出すときは必ずこの関数が実行された後にしなくてはならない。
	};
	jp_utweb_ExternalInterface_sample.hoge = function(){
		//ActionScriptから適時呼び出される。
		var swf = this.getElementFromName("external_content");
		if(swf){
			//ActionScriptの関数を実行。
			swf.asFunction();
		}
	};
})();

一行目の

;var jp_utweb_ExternalInterface_sample;

これが唯一の名前空間となります。
これと全く同じ名前を、Cap1の10行目で

flashvars.jsNamespace = "jp_utweb_ExternalInterface_sample";

というふうにFlashに伝えてあることによって、Flash側ではJavaScriptへの呼び出しを可能にします。
Flash側での呼び出しはCap4で説明します。

コーヒーブレイク：ぼくのかんがえたさいきょうのJS名前空間

一旦休憩です。
非常にくだらない事を書くので、読み飛ばしてCap3まで進めることを強くおすすめします。
僕がJavaScriptを触っていて特に気を遣うのが名前空間の汚染なわけですが、大規模案件にかかわらず一人で開発しているような趣味のプログラミングでもどうしてもグローバルの名前空間の汚染が避けられない状況がよく出てきます。
僕は僕なりにいろいろ調べてはみたんですが、JavaScriptは言語仕様としてどうしてもこれは避けられないのではないかと思うようになったわけです。
名前空間を擬似的に扱うクラスを作ってみたりもしたんですが、そのクラスに一つ名前空間を使うという仕様になってしまい、これはだめだということで他のアプローチで名前空間を確保する方法を考えてみました。

1:僕を褒める言葉を使用する。

調べてみたんですが、少なくともインターネット上では僕を褒める言葉が使われている回数は皆無なのですね。
そこでこれを利用して僕を褒め称える変数名を使用すると、絶対に名前空間が保証されるというアイデアです。
こんなふうに使います。

var 正宗さんは格好いい = "ほげ";
var 正宗さんの言うことは常に正しい = "ふが";

2行目のように、僕を恒常的に肯定する言葉を用いるとより強固になります。

2:自作ポエムを変数名にする。

変数名などを自作のポエムにすることで著作権によってプログラマーの死語50年間まで担保される非常に強固な名前空間を仕様することができます。
この場合の名前空間の強度はディズニー法の強度に依存します。

var かにをたべ　るとくちのなか　かゆくなる = "hoge";

プログラムが一気に風流になるという副次的効果付きでとてもおすすめです。
仕方のない話しはここまでにして、本題に戻ります。
今まではSWFを表示させるためにブラウザ側やHTML側、JavaScript側の問題でしたが、次はActionScript側の問題になります。

Cap3.初期化の実行順序を守る

よっぽどの理由がない限り、JS側からAS側に働きかける場合、AS側が準備完了かどうかを待ってJSは働きかけたほうがより安全だと思います。
つまりAS側が準備完了になった時点ではじめてJSに通知して、JSはその通知を待ってASに働きかけるようにするのが定石と言えます。
Cap2の11行目から14行目

jp_utweb_ExternalInterface_sample.ready = function(){
 //ActionScriptが実行可能状態になったら最初に呼び出される。
 //JS側からAS側に関数を呼び出すときは必ずこの関数が実行された後にしなくてはならない。
};

を用意しておき、必ずActionScript側から最初に呼び出されてJSの初期化をここで行うようにします。
ここまでが僕が作った必ず守るべきルールになります。
次からはActionScript側からJSと連携するのに便利な方法をまとめたものになります。

Cap4.JavaScriptとの連携は必ずシングルトンを介して行う。

この記事の最初に提示したgithubのサンプルソースを見ていただくとわかりやすいんじゃないかと思うんですが、Javascriptとの連携はそれを専門にしたシングルトンクラスにまかせることにします。
ちょっと簡単に書いてみます。
ActionScript3です。

package
{
	import flash.events.Event;
	import flash.events.EventDispatcher;
	import flash.external.ExternalInterface;

	public class JavascriptTool extends EventDispatcher
	{
		public static const DO_HOGEHOGE:String = "doHogehoge";
		public static const DO_FUGAFUGA:String = "doFugafuga";

		private static var _instance:JavascriptTool;

		private var _jsNamespace:String;

		public static function getInstance(jsNamespace:String = null):JavascriptTool
		{
			if(!JavascriptTool._instance){
				JavascriptTool._instance = new JavascriptTool(new Enforcer());
				if(!jsNamespace){
					throw new JsNamespaceError("Javascriptと連携する名前空間を指定してください。");
				}else{
					JavascriptTool._instance._jsNamespace = jsNamespace;
				}
				try{
					ExternalInterface.addCallback("jsHoge", JavascriptTool._instance.hogehoge);
					ExternalInterface.addCallback("jsFuga", JavascriptTool._instance.fugafuga);
				}catch(error:Error){

				}
			}
			return JavascriptTool._instance;
		}

		public function ready():void
		{
			try{
				ExternalInterface.call(_jsNamespace + ".ready");
			}catch (error:Error){

			}
		}

		public function hogehoge():void
		{
			dispatchEvent(new Event(DO_HOGEHOGE));
		}

		public function fugafuga():void
		{
			dispatchEvent(new Event(DO_FUGAFUGA));
		}

		function JavascriptTool(enforcer:Enforcer):void{}
	}
}
class Enforcer{}
class JsNamespaceError extends Error{
	public function JsNamespaceError(message:String):void
	{
		super(message);
	}
}

シングルトンの説明は省いたとして、これ。
ExternalInterface.addCallback
第一引数がJavascript側から見える関数。
第二引数が実際のActionScriptの関数。
APIとして多言語に対しての接続部分が隠匿化できるので非常に優れてるといえますけど作業する本人達にとってはややこしいことこの上ないです。
この部分を埋めるデバッグツールは存在しないわけですし。
そうは言ってもわざわざJS側とAS側で呼び出す関数名を指定できるってことはJS側とAS側で違う名前にしておいたほうがいいって事ですかね？
僕はそう解釈して実行していますが、このへんの名前の命名規則になにか良い方法があったら教えていただきたいです。

あと21行目、他はイレギュラーな使われ方をしたときにわざわざコンパイルエラーを出すように作ってあるのに対して、この部分だけはランタイムエラーになるようにしか作れませんでした。
シングルトンの生成される最初だけ値を渡して初期化したいときに、初期化のタイミングで値が渡されたときとそれ以外で値が渡されたときの両方でコンパイルエラーを出す何か上手い方法があればどなたか教えてください。

というわけでまだまだ未完成ながらもこのシングルトンクラスをいきなりドキュメントクラスで使ってみたのがこちら。
ActionScript3です。

package
{
	import flash.display.Sprite;
	import flash.events.Event;
	import flash.text.TextField;
	import flash.text.TextFieldAutoSize;

	public class externalinterfaceSample extends Sprite
	{
		private static const _DEFAULT_JS_NAMESPACE:String = "hogehoge_msturi";
		public function externalinterfaceSample()
		{
			if(stage){
				_init();
			}else{
				addEventListener(Event.ADDED_TO_STAGE, _init);
			}
		}

		private function _init(e:Event = null):void
		{
			if(!(!e)){
				removeEventListener(Event.ADDED_TO_STAGE, _init);
			}

			var tf:TextField = new TextField();
			tf.border = true;
			tf.autoSize = TextFieldAutoSize.LEFT;
			addChild(tf);

			var jsNamespace:String = _DEFAULT_JS_NAMESPACE;
			var flashVars:Object = stage.loaderInfo.parameters;
			if(!(!flashVars.jsNamespace) && flashVars.jsNamespace.length > 0){
				jsNamespace = flashVars.jsNamespace;
			}
			var jsTool:JavascriptTool = JavascriptTool.getInstance(jsNamespace);
			jsTool.ready();

			tf.text = "Javascriptからの呼び出しが実行可能になった。";

			jsTool.addEventListener(JavascriptTool.DO_HOGEHOGE, function(e:Event):void{
				tf.text = "JavascriptからjsHogeが呼び出された。";
			});
			jsTool.addEventListener(JavascriptTool.DO_FUGAFUGA, function(e:Event):void{
				tf.text = "JavascriptからjsFugaが呼び出された。";
			});
		}
	}
}

こんな感じでどこでもシングルトンクラスからJSを実行できるし、逆にJSからの呼び出しもいつでもどこでもEventを受け取る形でキャッチできるようになるんだよ〜、というサンプルでした。
ActionScript、スマートすぎる。

このCap4は全てgithubのままですが、最後にいちおうgithubのindex.htmlのソースも載せておきます！

ちょっと実験用に名前のスコープをいじっております。
特にjp_utweb_ExternalInterface_sampleを返す48行目は、明示的にpublicな関数を指定してやるとJavaScript側からも実行できるようになります。

まとめ

やっと最近コードスニペットというのを覚えたので、コードの再生産がだいぶマシになりました。
毎回毎回こんだけ再発明するのしんどいですもんね。
まだまだ未完成な部分も多いですが、もっと上手い方法を随時見つけていきたいと思います！

ではFlashで呼び出してみよう！

ここまでの道のりが長かったですね。安心してください。それまでのほとんどが僕のゴタクです。
僕がはじめるにあたって先ず理解しておかないといけないことが多すぎただけで、ほとんどの人は実際にはここまですいすいと来られたはずです。

PixelBenderのpbjファイルをFlashのActionScriptで使うには二種類の方法があります。
実行時に外部ファイルとして読み込むか、Embedであらかじめ埋め込んでおくかです。

前者はXMLや外部JPEGファイルと同じく、URLLoaderを使って読み込む方法です。
Progressionだとこんな感じで

addCommand(
	new LoadURL(new URLRequest(Directory.PBJ_DIR + "myPixelBender.pbj"), {dataFormat:URLLoaderDataFormat.BINARY}),
	function():void{
		var t:Command = this as Command;
		_shader = new Shader(t.latestData);
	}
);

Progressionを介さずに普通にAS3で書く場合も、URLLoaderのdataFormatをちゃんとURLLoaderDataFormat.BINARYにしておけばうまくいくと思います。
こんな感じ。

var loader:URLLoader = new URLLoader();
loader.dataFormat = URLLoaderDataFormat.BINARY;
loader.addEventListener(Event.COMPLETE, _onCompleteHandler);
loader.load(new URLRequest(Directory.PBJ_DIR + "myPixelBender.pbj"));
private function _onCompleteHandler(e:Event):void
{
	var shader:Shader = new Shader(loader.data);
}

実際にはエラーハンドリングなんかも行う必要ありますがそれはまた別の話なのでここではあえて触れないでおきます。

Embedであらかじめ埋め込んでおく方法は、こんな感じで

[Embed(source="/../shaders/myPixelBender.pbj", mimeType="application/octet-stream")]
private var _myPixelBenderKernel : Class;
private var _myPixelBenderShader : Shader;

クラスのインスタンス変数として埋め込んでおいて、適切な場所で

_myPixelBenderShader = new Shader(new _myPixelBenderKernel());

として呼び出してやるやり方です。

実行時に外部ファイルとして読み込むか、Embedであらかじめ埋め込んでおくか、どちらのやり方もメリットデメリットあるので自分で適切だと思う方法で呼び出せばいいのですが、もしその判断が出来ない・迷うようであれば後者のEmbedで埋め込む方法をおすすめしておきます。
シェーダーを外部読み込みにするメリットが思いつかないのであればほとんどの場合外部読み込みのデメリットのほうがEmbedする方法のデメリットを上回るからです。

呼び出したのでどうやって使おう？

2種類の呼び出しの方法のどちらを使っても、ActionScriptではShaderクラスとして読み込まれることがわかりました。
ここでActionScriptリファレンスのShaderクラスとそれに付随するShader何々クラスを一読しておくとだいたい何すればいいかわかるかと思います。
僕みたいにクラスの動作が全て頭に入っているわけではないひよここそ、リファレンスの存在は欠かせません（いまだにArrayにさえ、こんなメソッド無いかな〜とリファレンス引きながら作業してるくらいです）。

FlashがPixelBenderをShaderで読み込んだら、いろいろ出来ることがあるんですが、いまのところ僕はShaderJobを使うことをおすすめします。
理由としてはShaderJobが圧倒的に速いからです。
ブレンドモードとして使ったり、塗りに使ったり、フィルタとして使ったり、も確かに面白いのですがそれらがどうしても最終的にFlashの処理を挟む必要があるのにたいして、ShaderJobは同じ事が出来てしかも完全にFlashと処理が切り離せるので「Flashの処理速度という概念を無かったことに出来る」という冒頭の売り文句が発揮できるからです。
しかもFlashとの同期処理・非同期処理のどちらで処理するかを実行時に選べるのです。
これのおかげでShaderJobを使うことによってFlashの描画処理を徹底的にチューニングすることが出来るようになると思います。僕もまだそこまでには達していませんが、少なくともその入り口には立てた気がします。

ShaderJobを使うには、まず入力側のBitmapDataと出力先のBitmapDataが必要になります。
入力の指定については、PixelBenderのKernelの書き方によって違うのですが、

_shader.data.src.input = _inputBitmapData;

こんな感じで指定してやります。
「src」っていう変数名が、ここがKernelで使ってる変数名によって違うので注意が必要です。
PixelBenderで
input image4 src;
と書かれてあれば

_shader.data.src.input = _inputBitmapData;

と書きますし、もし
input image4 sauce;
だと

_shader.data.sauce.input = _inputBitmapData;

こういう感じでActionScriptを書くようになるかと思います。

あとはShaderJobの処理のさせ方ですが、
ShaderJobのリファレンスを読むとコンストラクタの第二引数に出力先のBitmapDataを指定しないといけないことになっているのがわかります。
そこでこんなふうに

var _shaderJob:ShaderJob = new ShaderJob(_shader, _outputBitmapData);

ShaderJobクラスのインスタンスを生成します。
そのあとおもむろに

_shaderJob.start();

してやってもいいんですが、面白いことにShaderJobはstartする際に処理を非同期で実行するか同期して実行するかを選べます。

//_shaderJob.start();
_shaderJob.start(false);

このいずれの場合も非同期で実行します。
なので

_shaderJob.addEventListener(ShaderEvent.COMPLETE, _onShaderJobCompleteHandler);
//_shaderJob.start();
_shaderJob.start(false);

こんな感じでイベントリスナーを登録しておくとシェーダーの処理が完了したタイミングを捕捉できるようになります。
画面の処理のために入力や画面の更新などFlashの他の処理を遅らせたくない場合に、完全に処理を分離できるので非常に効果を発揮します。

_shaderJob.start(true);

こうした場合には同期して実行します。
どのみち同期しててもPixelBenderのShaderJobの処理はほとんどの場合は一瞬で終わるので誤差は一瞬ですが、画面更新のタイミングと処理を完全に同期させておきたい場合に効果的です。

さいごに

書いててほんと自分でもびっくりするくらい長い記事になったのですがどうでしょうか。
ほとんどがPixelBenderの技術の話しではなくてPixelBenderとはどういう動作をするものなのかの概念の話しばかりだったと思います。
それだけ僕にとってPixelBenderは概念的な障壁が高く、でも一旦概念を理解してしまえば技術的にそんなにハードルの高いものではない、むしろとっつきやすく奥の深いとても楽しいものだと言うことが解りました。
それに一旦こうして記事にして書いてしまえば、次からPixelBenderの技術的な記事書くときに「概念についてはこちらを参考にしてください」と言えるので、むしろ今後PixelBenderを研究していく布石になったと思います。

僕がPixelBenderを学びはじめるに当たって参考にしたAS3アニメーションのオライリー本にも書かれてあることですが、PixelBenderはOpenGLのシェーダー言語GLSLに非常によく似た言語で、そのノウハウがだいぶ参考になるかと思います。

僕個人の考えとしては、ブラウザ上での描画に限って言えば並列処理を実現するための方法はさまざまに企画が立ち上がっていますが、3年以上も前から提供されていてしかもFlashさえ走ればブラウザを問わず納品レベルできちんと動くPixelBenderには一日の長があるかと思います。
PixelBenderそのものが意外にもとっつきやすくて奥が深く、それでいてFlashが何十倍も楽しくなる面白い技術なのも今回学ぶに当たって新鮮な驚きでした。

この技術がもっと普及して研究がされたら、もっと面白い使いどころが増えると思いますし今までFlashの処理速度が枷だったことがいろいろと解決する可能性が高いかもしれません。
今回の記事ではあえて書かなかったのですが、僕はPixelBenderをByteArrayとかVectorで処理する方法にも非常に興味を持っています。
この記事がきっかけになって、少しでもPixelBenderの使いどころの上手い人が増えて今まで処理速度がネックになっていた問題が解決できれば、WEBの表現はもう一段階自由になるのではないでしょうか。

そこまでは夢見すぎだとしても、少しでも処理速度による表現の限界を解決するヒントになれば幸いです。

さてさて、今さらながらPixelBenderについて勉強してみました。PixelBenderって登場したの確か3年以上も前ですよねえ。
普段から情報共有が 盛んなFlashにおいて、僕が今まで3年もPixelBenderを使っていなかった理由はひとえに「PixelBenderが何をするものなのかわかりにくい！」からでした。
PixelBenderを使うとどうなるのか、Flashのどんな場面で使えるのか、どうやって使うのか、いやいやそれ以前の問題でただひたすら「PixelBenderが何をするものなのかわかりにくい！」のでした。
もちろん、Adobeの告知不足とかそういった事が言いたいわけではなくて、僕のスペックではPixelBenderはわかりにくいからとっつきにくかった。というお話です。

で、勉強してみてわかった結果は、「PixelBender、かなり使える」ということです。
簡単に言うとFlashの処理能力が別次元で向上します。
おおげさですがおおげさでない表現として「Flashの処理速度という概念を無かったことに出来る」ほどのパフォーマンスです。
「別次元」とか「処理速度という考え方を無かったことに」というのは、太字にしたのは煽りでもなんでもなく実際に本当に処理方法が違うからです。これに関しても出来るだけ簡単に説明します。
いったんサンプルを見てください。

ウエブカメラがあれば接続の許可を求められると思いますので許可してください。
ウエブカメラがない、あっても許可しなかった場合は、僕が今年の夏にバラ園にいったときの思い出の写真がかわりに表示されることになると思うので、そういった悲しい事故がないよう、是非ともウエブカメラを使って遊んで頂くことを強くおすすめします。

マウスをうごかしてもらうとわかると思うんですが、昔からよくある、水面の波紋のような画像処理を効果に加えたサンプルです。
DisplacementMapFilterとかで手垢がつきまくっているので、アンテナの高い人には今さらなサンプルです。
ここで見て貰いたいのは、処理のほとんどをPixelBenderにまかせたことによる処理速度の安定です。

サンプルのソースコードはこちら。
https://github.com/masamunet/blog_samples_pixelbender_practice

ソースコードをみてもらってもわかるように、基本的に僕はなにもしていません。処理のほとんどを外部のPixelBenderファイルに頼っています。
具体的にはこちらのソースをほとんどの部分で使用しています。
僕がやったことと言えば、もともとDisplacementMapFilterで処理していた部分もShaderJobを用いてPixelBenderで行うように変更したくらいですが、そのPixelBenderもこちらの記事を参考にしてあります。
このように、PixelBenderの概念を一旦理解したら、あとは自分でオリジナルなPixelBender処理を書くもよし、海外にあるいろいろなPixelBenderのファイルを（ライセンスに従って）使いこなすも良し、いずれにせよ処理速度という表現の枷からかなり自由に解き放たれるPixelBenderは是非是非習得すべき楽しい技術だと思います。

ちなみにPixelBenderの習得にあたって参考にした本はこちら。

この本の第9章にPixelBenderについて書かれています。
だからこの本以上のことはこのブログに書かれていないのでこの本を読んだ方はあんまり期待できる記事ではないと思いますが、PixelBenderについて僕なりに理解したことをまとめてみました。

PixelBenderはそんなに敷居の高い技術ではないです。
実験レベルならすぐにはじめられて、効果は非常に高い（なにせ処理速度が別次元になるので）技術なので、ぜひともわかりやすく説明出来るようにまとめられたらと思います！

とはいえさて何から書こう。
やっぱり初心者にとってはそもそもまずPixelBenderが何かを知らないですよね。並列処理というちょっと特殊な処理の流れもあって、非常にとっつきにくい印象を受けるので、先ずはPixelBenderについて少し細かく説明してみたいと思います。
なお、僕という初心者が理解した程度の説明を初心者を対象に説明するので情報の正確性については基本的に自信がないです。
しかもピクセルシェーダーとかプログラマブルシェーダーと呼ばれる技術を意図的に全て「PixelBender」という名称を用いて説明しています。
並列処理についても仮想化の話しとかまで説明し出すと僕が混乱するので、すべてハードウェアとして、つまり「並列処理を行う、そういう機械があるものとして」書いています。
つまりここに書かれてあることをそのまま人に話すと笑われるかもしれないということです。

はじめよう。先ず最初に、PixelBenderって何なん？

PixelBenderとは、Adobeが開発したピクセルシェーダーを記述する言語のことです。その言語の記述やテスト、ビルドコンパイルするソフトのことをPixelBenderツールキットと呼びます。

画像はCS5についてきてたPixelBenderツールキット2

なるほど、わからん。もっと簡単に説明して？

そのためにはまず最初に「パソコンはどうやって画面が表示されるのかな？」について考えないといけません。
PixelBenderは凄く簡単に言うと「ピクセルを処理する言語」、もっと限定的に言うと「画像を処理するための言語」だからです。

ではパソコンはどうやって画面が表示されるのかな？

パソコンの画面の最小単位は1pxからできていることは説明の必要がないと思います。
では仮に1pxだけ表示するディスプレイがあるとして、その1pxに赤を表示させてみましょう。

1ピクセルの画面に赤を描く

CPUは1ピクセルずつ処理している

620×480の画面に表示する

こればっかりはCPUが進化して速くなっても、画面の表示処理だけはまともにやると解像度の処理回数がかかってしまうのはかつては避けられない問題でした。
この問題を面白い方法で解決したのが次の考え方です。

1ピクセルずつに専用のCPUを割り当ててしまう

全ては同時に行われる

実際には本当に297600個も並べているのかというと半分本当で半分嘘になります。本当のところはもうちょっとソフトウェアやハードウェアレベルで仮想化なども行われているのですが、画像処理の並列処理についての考え方は基本的にこれまで説明したような処理で行われていることになります。
しかもここまでの説明を「GPU」と説明すればわかるひとには一発でわかるものを、なぜ「仮想化とかそういう処理は置いておいて、「画像を表示させるための機械」というものがあることにしておく」などとまわりくどい説明を行ったかというと、PixelBenderはGPUが無くても動くからです。

では改めて問う。PixelBenderとは何ぞや。

PixelBenderとは、
「つーかその1ピクセルごとに専用のCPUがあるならさ、そのCPUにプログラム走らせれば良いんじゃない？」という発想の元に生まれた、ピクセルを描画するためだけのプログラムです。

先ほど説明した「画像を表示させるための機械」が行っている1ピクセルの描画処理の流れはこんな感じです。

1ピクセルの描画処理の流れ

PixelBenderの処理の流れ

なんとなくPixelBenderというものがわかってきたでしょうか。
冒頭（といっても記事の中盤）で説明した言葉をもう一回書いてみます。
PixelBenderとはある一つのピクセルを計算して描画するプログラムの事です。

正体が分かればそんなに怖くない

つまりPixelBenderが行う処理は、言ってしまえばRGBの値（正確にはあとアルファ値も）だけが入力されることと、出力もRGBの値（と正確にはあとアルファ値と）を出力するためだけのプログラムです。
一個のプログラムは1ピクセルの色だけを出力するためのものです。
そしてそれが何万個（場合によっては何千万個）も同時に実行されます。
ActionScriptやJavaScriptなどのように、順番に実行される言語でプログラムしていると最初ちょっと戸惑いますが、PixelBenderは

1. 一個のピクセルを描画するためだけの言語
   • そしてそれだけしかできないのでたいして難しいわけではない
   • そもそも言語的にそれ以上の難しい事を出来るようにはなっていない
2. 全てが同時に実行される

という二点のミソを理解すれば最初感じていた取っつきにくさは消え去りました。

PixelBenderをFlashで使うことのメリット・デメリット

そしてこのPixelBenderはFlashでもノーコストで使用できます。
FlashのActionScriptにおいて、
保守管理しやすい綺麗なコードを白魔法
高速化のために全てを犠牲にするような過激なチューニングが為されたコードが黒魔法
とするなら、PixelBenderはさしずめ召喚魔法です。
全く異世界の力を借りることになり、威力は絶大。しかもノーコストです。

メリット

• 同時に実行しなければならない処理がノーコストで一瞬にして終わる。
• FlashのFPSを落とさない。

実際にはFlashPlayerの実行環境の構成によりますが、理論上はFlashのFPSを落とすことはありません。

デメリット

ByteArrayについてはまた別途書きます。

2011/09/08追記
ByteArrayと同じくVector.型も使えると教えて頂きました。

ピクセルを描画するというPixelBenderの仕組み上、扱える描画オブジェクトがBitmapDataに限られます。
BitmapData型を保持していない描画オブジェクトの場合、処理の前に常にbitmapData.draw()を発生させなければいけないので、このコストがいちばんの悩みどころになります。
逆に言えば、BitmapData型を保持していればどんどん積極的にPixelBenderを使っていきたいところです。

さっそく使ってみよう！PixelBender！

とここまで書いておいてなんですが、悩んだんですがこの記事ではPixelBenderの言語については解説は書かないことにしました。
理由は僕もまだはじめたばかりなので説明出来るほど言語にたいして理解が深くないためです。
みなさんと同じく僕も目下勉強中なので、いずれ記事に出来るくらいには理解を深められたらと思います。

ただし、PixelBenderについては「PixelBender お目当ての処理」で検索するとけっこうな数で海外のPixelBenderのソースがヒットします。
それらを参考にするも良し、ライセンス的に問題がないのであればそのままFlashに使用するもよしなので、およそ汎用的な処理であればPixelBender初心者でもかなりなことができてこの技術を手っ取り早く楽しむことは出来ます。

PixelBenderというプログラム言語についての解説は今回は省きますが、PixelBenderツールキットの使い方について、おおまかに説明してみたいと思います。
ちなみに冒頭（といってもこの記事の中盤頃）でも書きましたがPixelBenderツールキットとはPixelBenderというプログラムを書いたり実行したりテストしたりコンパイルしたりするアプリツールのことです。Flashを作るあのソフトのことをFlashIDEと呼んだりするのと同じです。

PixelBenderツールキットは、AdobeCS4かAdobeCS5を買ってインストールしていれば標準で入っていると思います。CS5.5ではどうかわかりませんし、CS以外の他の方法で手に入れるやり方はわかりませんが、とにかくCSでインストールされているものとして話しをすすめてみます。
ちなみにCS5ではPixelBenderツールキット2が入っていました。1と比べてどこか新しくなったんですかね？
Macだと
/アプリケーション/ユーティリティ/Adobe ユーティリティ
/アプリケーション/ユーティリティ/Adobe ユーティリティCS5
あたりに入ってると思います。

New Kernelで新規作成

画面は大きく3つにわかれています。

Export For Flash Player...

後半へ続きます。

中段あたりにチェックボックスがあるよ

いきなりですがswcファイルって「スウィック」って読むらしいですね。アドビの中の人もそう読んでたんで確かな情報です。
しかしながら僕は慣れなくていつも「エスダブルシー」って読んでしまうんですね。そこらへんのモサさが自分流さ、なんて無頼を決め込んで今日も「エスダブルシーエスダブルシー」と 読んでいます。
僕が「エスダブルシー」って言う度に周りが若干イラっとした顔されるんですが、それでもかわまず「エスダブ…エスダボースィー」とか呼び続けてるのに未だ怒られた事がないのは 、ひとえに僕の人徳だと思います。

無駄な軽口はこのくらいにして、先日行われたひよこの会で少しだけ要望があったのでSWCと連携してProgressionでのFlashサイト開発環境を超快適にする方法をご紹介したいと思います。
今までのやり方にもよりますが、体感100倍速いと言っても全くおおげさでないくらい、爆速開発が可能になりますよ！

そもそもパブリッシュが遅い…

Progressionに限らずですが、Flashサイトを作っていて一番のネックになるのが「パブリッシュに時間がかかる」事なんですよね。
それもflaファイルが肥大すればする程パブリッシュに時間がかかるようになり、納品間近の追い込みの時期になるにつれてパブリッシュだけで1分以上かかるようになるし…（ヒーッ）。

デバッグなんかもそうですが、「よりわかりやすく、より気持ちよく」動くことを心がけているFlashサイトにとって、1pxの位置や0.1秒の速度までこだわってなんべんも動かしてみて作り込むことはよくあることなのに、パブリッシュに時間がかかるようになるとそれもままなりません。

書き出せるものは先に書き出しておけば…

そこで今回ご紹介するswcなんですが、これは言ってしまえば頻繁に変更しない素材はあらかじめswc形式で書き出しておいて 、それを使うことによって開発を進めていこう、という方法なんですね。
この方法自体は、僕もkatapadさんから教えて頂きました。
ちなみに僕というひよこ向けの備忘録なので、最初はswcとは何か、どうやってswcを書き出すのかなどの事が書かれてありますが、Progression連携のミソは一番最後なので、swc書き出しに精通されてる方はこのまま最後まですっ飛ばして読まれてもいいかもしれません。

ものには順序がある。まずはFlashBuilderとProgressionを連携させるようにしておく

僕の現在のFlash開発環境は100％FlashBuilder+Progressionなので、その方法でご説明します。
基本的なところは同じなので他の開発環境 でも工夫してswc連携スタイルが作れることと思います。

まずは僕の以前の記事
Progression4をいい感じにFlashBuilderで作業できるようにする
を参考にしてください。
これはFlashBuilderがsrcにあるflaファイルを勝手にbin-debugフォルダにコピーしてしまう現象を回避できなかったので、思い切ってflaファイルを削除してそれでもちゃんとswfがパブリッシュできるように設定し直した方法ですが、基本的にこのスタイルで開発を進めていくことになります。

記事に沿って、index.flaとかpreloader.flaを思い切って捨てちゃって下さい。次に進みます。

新規flaファイルを作る

FlashCS5の「ファイル」→「新規」から新規flaファイルを作ります。Progressionと連携させるのでASのバージョンはもちろんAS3です。
僕はFlashBuilder連携を前提にこの記事を書いていますんで、今回FlashCS5指定ですがFlashDevelopとかFDT、FlexBuilderなどお使いの環境に合わせて読まれてる方にとっては、特にFlashCSのバージョンは関係はありません。

新規flaファイルの保存場所はどこでもかまいません。どこでもかまいませんがFlashBuilderのワークスペース以外のところに作るのがおすすめです。flaファイルのファイル名も何でもいいですが、ここではmaterial.flaと名付けました。

SWCファイルを書き出す

おやこんなところにSWC書き出しのチェックが！

そのままFlashの「ファイル」→「パブリッシュ設定」で真ん中らへんに「SWC書き出し」というチェックボックスがあるので、ここにチェックを入れます。
そのままパブリッシュしたらflaファイルと同じフォルダに「material.swf」が出来たと思います。

おやこんなところにSWCファイルが出来ちゃった！

material.flaのライブラリの中はリンケージ書き出しのシンボルでいっぱい！

さてさて、これでswc書き出し用のflaファイルが新規作成できましたので、早速作業に入っていきましょう。
基本的にはmaterial[素材]というファイル名からも想像がつくように、このflaファイルの役割は「素材倉庫」です。長年慣れ親しんできたflaファイルをただの素材倉庫にするのは僕もしのびないですが快適環境作りのため。最終的にはFlash全体の開発環境が快適になることによって自然とこのflaファイルの活躍の場も以前より増してきますのでご心配なく！

最終的にライブラリの中にたくさんリンケージ書き出しのシンボルが作れました。

ライブラリの中は汗と涙と夢でいっぱい！

書き出したSWCファイルをProgression開発環境にコピーする

この記事ではProgression開発環境イコールFlashBuilderのワークスペースな意味合いで使っています。
先ほど書き出したswcファイルを早速Progressionの開発環境で使ってみましょう。

具体的にはProgression開発環境のlibというフォルダに先ほどのswcファイルをコピーするだけで良いです。

わかりにくくてすみません。スクリーンショットでは800_material.swcとリネームされていますが特に意味はないです。

たったこれだけ！

FlashBuilder+Progression環境だと、この「swcをlibフォルダに入れる」だけであとは何もせずにswcの中にあるリンケージをそのままクラスとして読み込めるようになります！

快適すぎて死ぬｗｗｗ！

他の環境だとクラスパスの設定とかしないといけないかもしれないですが、本来はひよこ的には「クラスパスって何？」ってところから記事を書きたいところなのですが今回の記事ではそれは割愛して、まあ他の環境でよくわからない場合は本番開発用flaと同じフォルダにswcファイルも入れておけば同じような感じにはなるかと思います。

まじで便利なコンポーネント連携！

さてさて、ここまでは普通にswc書き出しとの連携なんですが、Progressionが凄いのはここからなんです。

とちょっとそのまえにProgressionのAddChildコマンドについて少しお話を…。

FlashのActionScript3では、表示オブジェクトを画面上に入場/退場させる命令としてaddChildとremoveChildがあります。
Progressionではそれをさらに便利にしたjp.progression.commands.displayパッケージがあって、ようはわかりやすく言うとAddChildコマンドやRemoveChildコマンドっちゅうのがあります。
（他にもAddChildAtコマンドやRemoveAllChildrenなどなどいろいろ便利なコマンドもありますが、ややこしくなるのでこの記事では一律AddChildコマンド、RemoveChildコマンドと呼ぶことにします）
ただ便利なだけでなく、Progression側で何が表示されてて何が退場していったのかの管理とか、それこそ重なり順とか、表示されたときに実行される処理とか、かなりProgressionの根幹に関わる処理が、このAddChild系コマンドの実行されたタイミングで行われています（いるような気がします）。
なのでAddChildコマンドを使わずにaddChildだけで表示した場合、これがProgressionが管理しきれない表示オブジェクトとなってしまうので、使ってる経験上こういうのが思いがけずちょっとしたトラブルを招くことが多いです。

Progression始めた人で、僕が個人的にはまりやすいなと思うのが、この部分なので、例えばCastSpriteやCastMovieClip系の表示オブジェクトをAddChildコマンド経由せずにふつうにflashの addChildで表示させてしまってatCastAddedが正しく実行されないなどのミスで戸惑っている人がいるんじゃないかなと思っています。

swc連携に限ったことではないですが、Progressionでは特に初心者の場合でAddChildコマンドが何しちょるのかようわからん、といった場合はパフォーマンスを稼ぐなどの特別な理由がない限りはaddChildは使わずほぼ全てAddChildコマンドを使うようにしよう！と決めておくとそこらへんのミスが減るんじゃないかと僕は思います。

で、少し脱線したんで本題に戻りますが、とにかくProgresisonのAddChild系コマンド、RemoveChild系コマンドはコンポーネントとも連携が利くので、ここからが本領発揮です。

Flashの強力なタイムライン機能を活かしてInOutMovieコンポーネントでわしわしアニメーション描くもよし！

複雑なアニメーションもInOutMovieコンポーネントで思いのまま！

ボタンなんかもRollOverButtonコンポーネントでさくさく！

どうせswcの中に素材としてボタン置いてるんだからついでにコンポーネントでボタン化までしておいてしまえ！

new AddChildするだけの簡単なお仕事

あとはリンケージさえ設定してもらえれば、あとはプログラム側ではnew AddChildするだけの簡単なお仕事です。本当に。
ビジュアルとロジックの分離は当制作所でも必須課題なのですが、Progression導入でそこらへんも本当にやりやすくなりました。タイムラインでしっかり作り込みたいところはタイムラインで作って、Tweenerなどでぴっちり制御したいところはロジックを作って、それらの違いを意識せずに最終的に扱えるようになるのは、本当にパワフルな開発環境を整えることが出来ます。

この記事中、ほとんどが僕の無駄口で長くなってしまいましたが、実際はやってみると本当に簡単なので是非試してみて下さいね！
デメリットとしては先ほど書いたように今まで慣れ親しんだflaファイルをただの素材置き場としてしか使わなくなる事への心の抵抗くらいですが、最終的にはFlashのタイムラインというパワフルな環境を十二分に発揮できるスタイルに移行するわけなので、かえって以前よりFlashCS5の出番が増えるようになります。
「もっとこうしたほうがいいよ」とか「うちではこうしてるよ」ですとか、「うそばっかりやんけ！」などのご意見ありましたらコメント下さいね。
最近「ブログ読んでます」という反応が少しだけ得られるようになって、本当嬉しいです。

Progression4がFlashBuilderとの連携ができるようになっていたのがきっかけだったのと、あとFlashのコンパイル（パブリッシュ）がその都度グラフィックを書き出し直すので時間がかかるようになったのが嫌でグラフィックはあらかじめswc書き出ししておいてFlashBuilderからasだけをコンパイルできるようになったらいいなと思ったので、FlashBuilderを使いこなせるように勉強してみることにしました。

常々お伝えしているように、うちのFlash請負制作業務のほぼ100%をProgressionフレームワークを使用していますので、ProgressionとFlashBuilderがうまいこと連携できていないと困ります。いろいろ試してみてうまい感じに連携できるようになったので書いておきたいと思います。

あとFlashBuilderについての本や情報が多いですがだいたいがFlex技術者向けになっていて、MXMLとか僕もよくわからないのですが僕のやりたいFlash開発とは微妙に違う気がするので、Flash向けにFlashBuilderの設定方法なんかの情報があっても良いなーと思っていたので、今回の記事はProgressionとあわせて是非ともマスターしたい技術だと思います。

先ずはFlashを立ち上げて

最初はFlashを立ち上げてProgressionプロジェクトを作成するところからはじめます。

はじまりはいつもFlash

種類：「クラス」にするのを忘れないで！

「FlashBuilderに対応させる」のチェックも忘れるな！

プロジェクトの設定で気をつけるところはここまでです。
おもむろに「作成」ボタンを押すとしばらくしてProgressionプロジェクトが作成されるはずです。

できたできたー！

プロジェクトが出来てしまえばもうFlashには用がありません（ひどい）。
Flashはそのまま終了しましょう。

ここからFlashBuilderで作業する

ここから先はFlashBuilderで作業します。長年使い慣れたFlashを捨てて慣れないFlashBuilderを使っての作業になりますのでかなりドキドキします。

FlashBuilderのワークスペースの概念はおわかりでしょうか？
もしまだでしたら今後FlashBuilderを使っていくにあたってワークスペースはよく切り替えることになるのでこの記事を読む前に「Eclipse ワークスペース」などで調べておく事をお勧めします。それ以前にFlashBuilderとEclipse との関係についても調べておいて損はありません。
ワークスペースやEclipseについてよくはわかってないけど、手っ取り早くこの記事を読む場合、「とりあえずワークスペースとは作業フォルダを決める事なので、先ほどProgressionプロジェクトを作成したフォルダーの一階層上を選択しておけば良い」とだけ覚えておいてください。
（僕の理解度もだいたいそのへんです）

※2010/11/10追記
最近Dropboxで作業スペースを同期とってるんですが、ワークスペースをDropbox内に設定すると他のPCと同期をとったときにFlashBuilderのライセンス違反が起こるらしく、えらい大変なことになります。
Dropboxなどで共有してる人は、プロジェクトファイルはDropbox上で、FlashBuilderのワークスペースは各PC固有のディレクトリで設定するのがお勧めです。

ワークスペースを決めたら、先ほど作ったProgressionプロジェクトフォルダをFlashBuilderに登録します。

ファイルメニューから開く

FlashBuilderのメニュー「ファイル」→「Flexプロジェクトを読み込み」を選びます。

プロジェクトフォルダーからさっき作ったフォルダを選ぶ

うまく読み込めた！

上手く読み込めました！

ただ、ファイル構成をよくよくみてみると、srcフォルダにあるはずのflaファイルがbin-debugフォルダにもコピーされるんですね。このままではまずいですよね。

どうしたらいいかというと解決方法は簡単で、srcフォルダにあるflaファイルを削除すればいいんです。
index.fla と preloader.fla の二つを削除します。

で、Progressionプロジェクトを作った時に自動的に「Index.as」が「bin-debug/index.swf」にパブリッシュされるようにFlashBuilderプロジェクトを設定してくれているんですが、同じように「Preloader.as」ファイルを「bin-debug/preloader.swf」として書き出すようにFlashBuilderプロジェクトを設定し直す必要があります。

他にもFlashBuilderのみでパブリッシュできるようにFlashBuilderプロジェクトの設定をいろいろ変更しておきましょう。

FlashBuilderプロジェクトの設定をいい感じに設定し直す

FlashBuilderプロジェクトの設定を変更するには、プロジェクトそのものを右クリックして「プロパティ」を選びます。

プロジェクトを右クリックで「プロパティ」

Flexコンパイラでは「HTMLラッパーファイルの生成」のチェックを消す。Hey YO!

「HTMLラッパーファイルの生成」のチェックを外すんですよ。つけるんじゃないですよ。

Flexモジュールでは追加ボタンを押す

書き出されるswfファイル名の大文字小文字に気をつけて

「モジュールの追加」画面で気をつける事と言ったら、通常「Preloader.as」からは「Preloader.swf」が書き出されようとするので、大文字小文字に気をつけることですね。index.htmlを書き換えたくないのであれば、ここで出力SWFのファイル名を「preloader.swf」と小文字に直しておきましょう。
モジュールSWFのサイズは「最適化しない」にしておきましょう。

これでFlashBuilderプロジェクトの設定は完了です。
いろいろ警告が出るとは思いますが、警告文を良く読むとほとんどの方にとっては問題ないケースかと思われますので、理解して問題ないならOK連打で元の作業画面に戻りましょう。

選択したファイルを削除だ！

あとはsrcのindex.fla 、preloader.fla、bin-debufのindex.swfとindex.fla、preloader.swfとpreloader.flaを削除してみましょう。

そしてFlashBuilderメニューの「プロジェクト」→「クリーン」で一回プロジェクトをやり直して、bin-debugフォルダにflaファイルが出来なくなって、さらにindex.swfとpreloader.swfが作られていればOKです！

あとはがんがん開発するのみ！よいProgression+FlashBuilderライフを！

おまけ

MacではFinderからswfを右クリックして「情報を見る」で

「このアプリケーションで開く」を設定

「このアプリケーションで開く」で Flash Player Debuggerを選んでおいてね。

flaファイルは死んでしもうたん？

このやり方ではindex.flaとpreloader.flaを大胆にも削除してしまうので、今後一切をasファイルで行わなければならなくなります。flaファイルは果たして使えないのでしょうか？

いいえ違います。

flaファイルはswc書き出しをするようにして、プロジェクトフォルダのlibsフォルダに突っ込むようにしましょう。
InOutMovieコンポーネントなどを使ったMCをリンケージ書き出ししておけば、「タイムラインを上手く使いつつ爆速コーディング可能な」Progression4+FlashBuilderというなかなか厨房臭いほど最強なコーディング環境が整うかと思います。

これはかなり万人向けな便利スタイルですので、また今後是非とも掘り下げて紹介したいとおもいますが、swcを駆使してうまいことFlashBulderとFlashとの両立スタイルも研究していきましょう！

※2010/10/27追記

さらにswcを駆使して使う方法はこちらの記事に書きました。
SWC+Progressionで快適コーディング生活はじまる！

JavaScriptでもActionScriptでも、関数を登録する場面ってけっこうよくあって、ActionScriptでいえば特にaddEventListenerですね。そんなときに引数を渡したい事もあると思うんです。
その方法を書いておきたいと思います。

jQuery（JavaScript）の場合

jQuery( '#hogehoge' ).load( 'nanika.html', myFunc );
function myFunc() {
	alert( 'こんにちは' );
}

こういうやつのmyFuncに引数を渡したいとき。

jQuery( '#hogehoge' ).load( 'nanika.html', myFunc( 'こんにちは' ) );
function myFunc( argment ) {
	return function(){
		alert(argment);
	}
}

渡され先でreturn functionするのがコツです。コツなのです！

ActionScriptの場合

どんどんいきましょう

_mc.addEventListener( MouseEvent.CLICK, __click__( 'クリックされたよ' ) );
functioin __click__( argment ):Function {
	return function( e:MouseEvent ):void {
		trace( argment );
	}
}

Progressionの場合

こういう書き方が出来るってことはProgressionのaddCommand内でも使えるはず！

 new SerialList( null,
	myFunc( 'コマンドにFunctionを登録するときにも引数がわたせる' ),
	myFunc( 'どんどん渡そう' )
);
function myFunc( argment ):Function {
	return function():void{
		trace( argment );
	}
}

何故こうなるの？

書き方だけわかっても、理屈がわからないと気持ち悪いですよね。一見意味不明な書き方にも見えるし、まる覚えしないと次もういちど書けないようでは身につけたとは言えません。
僕なりに解釈した考え方を書いていこうと思います。
ちなみに型が明記できるActionScriptで書いていきます。

function は（）で実行される

function myFunc( ) {
	trace( 'hogehoge' );
}
//関数を実行
myFunc( );

当たり前のルールなんですが、一度作った関数は、その関数の名前のお尻に() 「括弧」を付ける事で実行されます。
ということは逆に言うと括弧を付けないと実行されないという事です。

関数を実行せずとりあえず登録だけしておく

function myFunc( e:MouseEvent ) :void {
	trace( 'クリックされました' );
}
_mc.addEventListener( MouseEvent.CLICK, myFunc );

こういう書き方をしている場合、ようは「マウスクリックされたときにmyFuncっていう関数を実行してね」と書いている訳です。

_mc.addEventListener( MouseEvent.CLICK, myFunc() ); //まちがい

こう書いちゃうと、マウスクリックの時に実行してほしい関数なのに今実行してしまいます。
つまり、「あとで実行したい関数は、名前だけ登録しておく」のが正解なわけで、通常はそう書いている訳ですね。

関数の「戻り値」をおさらいしよう

本来関数を登録だけしておくはずの場所で、あえて実行する訳ですから通常だとエラーなわけです。間違いです。そこをあえて実行してみた場合、スクリプトの世界ではどのような事が行われるでしょうか。
その謎を考える前に関数の「戻り値」というやつをもう一回おさらいしてみます。

function myFunc1( ) :int {
	return 100;
}
var a:int = myFunc1( ); //変数aには数字の100が入る
 
function myFunc2( ) :String {
	return "こんにちは";
}
var b:String = myFunc2( ); //変数bには文字の「こんにちは」が入る
 
function myFunc2( ) :Object {
	return { test:"ごはんおいしいです" };
}
var c:Object myFunc3( ); //変数cにはObjectが入る

関数が関数を返す

結論から言うと、イベントリスナーやコールバック関数など、「関数を今実行せず登録だけしておく」場所で「あえて実行させてみる」わけですから、そこで実行された関数が関数を返してしまえばいい、とある頭のいい誰かが考えた訳ですね。

function myFunc( ) :Function {
	return function( ) { trace( 1+1 ); };
}
var f:Function = myFunc( ); //変数fに関数が入る
f( ); //関数が実行され1+1の計算結果が表示される

たとえばイベントリスナーの第二引数には

function ( e:Event) :void { }

この形が入れば言い訳ですから、

function myFunc( ) :Functioin {
	return function ( e:Event) :void { };
}

こういう形を返す関数を作っておいて

_mc.addEventListener( Event.ENTER_FRAME, myFunc( ) );

こういうふうにイベントリスナーの登録時にはmyFuncを実行してしまえば、関数が返ってくるので、その返ってきた関数のほうをイベントリスナーは登録してくれる、というのがこの書き方の謎の正体です。

はじめに発見した人はそうとう頭良いと思います。ぼくはこの理屈を発見したとき芸術性すら感じました。
実用性もさることながら、こういった動作の合理性を考えていくのもかなり楽しいです。昔中学校の技術の時間にエンジンの仕組みを勉強して以来、その動作の合理性に魅せられて車オタクバイクオタクというよりはエンジンオタクになったのを思い出します。

Windowsの場合（vista）
file:///C:/Users/＜ユーザー名＞/AppData/Local/Adobe/Flash%20CS5/ja/Configuration/Progression/Help/ASDoc/index.html

Macの場合（Snow Leopard）
file:///Users/＜ユーザー名＞/Library/Application%20Support/Adobe/Flash%20CS5/ja_JP/Configuration/Progression/Help/ASDoc/index.html

あわせてActionScriptそのもののリファレンスのローカルの場所を探す場合には次の記事も参考にしてみてください。
ActionScriptリファレンスをダウンロードする

そしてひろゆきさんの記事はこちら！

Flashに限らずものごとには基礎が必要なんですが、この基礎の学習という奴がえらく退屈でわけわからんものが多いんですよね。晴子さんにイイカッコ見せたくてバスケ部に入ったのに最初はドリブルの練習ばっかりみたいな。
この基礎を通り越してしまえば、あとは楽しい世界が開ける訳でして、絵が思った通りグリグリ動かせて楽しいとか、思った通りいかなくてもそれがちょっとしたパズルみたいで楽しいとか、何をやっても楽しくなる訳ですが、いかんせん基礎を通り越すまでが恐ろしくわけわからないつまらない部分が続きます。

なのでこのFlashの初歩的な部分をみんなで集まって楽しく勉強したらいいんじゃないっていう集まりがひよこの会になります。

ちなみにいつも形から入る僕のスキルはというと自称上級者といううさんくさいやつでして、基礎的な初歩的な事はわかってなかったりするのでこの機会に皆さんと一緒に勉強していけたらと思います！お手柔らかによろしくおねがいします！

先ずは結論から

いきなりですがミーティングで決まった事から書いていきます。ざくざくっと。

• マニアックに走りすぎない。あくまで初心者のひよこの会なのでテーマをマニアックなことに持っていかないよう心がける。「隣の人に聞ける」とかそういう場。
• かといって初心者こそ「この質問がどのレベルなのか」判断できないもの。とりあえずはひよこの会では初心者の全ての質問を受け付けておいて今後「たまごの会」とか「にわとりの会」とか分科会が出来れば良いなあ。
• 目標は月一回だがまずは年六回の開催を。
• 場所はなるべく無料でお借りできるところを持ち回りで。
• 今のところTwitterで運営してATNDで募集する形。今後必要になってくれば掲示板などのツールを増やしても良いかな？
• 誰かに負担が集中する事を極力避ける。
• 会の報告なども、いまのところ各自のブログにまとめるなど参加者の自主性に全面的に頼る事にする。

運営に関してはこんなところですか。まあまだ実際に勉強会を一回もやった事が無い会なので、ツールや受け皿については追々きめていけばいいかと思います。
基本的に僕があんまり何もやらない派だし、ひろゆきさんはものすごく几帳面な方ですので、誰かに負担がかかるとするとそれは絶対ひろゆきさんにかかると思います（苦笑）！そうならないためにも、ひよこの会は皆さん の自主性で成り立っていますので是非積極的な参加をよろしくお願いします！！

いちおう次回からは早速勉強会をはじめるわけですが、次回のテーマは「みんなが明かす勉強法公開！」となっています。開催日時はまだ未定。

初心者勉強会の意義とか

ここから先は僕のゴタクになります…。

僕はFlashを触り始めて10年ですがActionScript3を触り始めてまだ3年目です。Flashではベテランのほうだと思いますしAS3では初心者です。もともと建築作業員でして工事現場で働きながら家で独学でFlashを勉強してきたのでもとからプログラムが得意だった訳でもないですし、初心者の苦労や基礎の難しさを現在進行形で味わっている一人でもありますし、10年やってきてFlashの楽しさを少しでも多くの人に伝えたい人間でもあります。

僕自身が「誰とでも声をかけたらすぐ仲良くなる」ような社交的なタイプでもないので、誰に対しても気後れしてしまって人と全然仲良くなれなかったりするほうでして、常々「こんな自分でもFlasherと仲良くなるにはFlashの話題をする場を作るしか無い！」と考えていました。名刺交換してもうまく仲良くなれませんが、目の前でPCを開いて一緒にFlashを見たりするのはたまらなく嬉しい訳です。

正直にいうと初心者勉強会と言っても、学校でしっかり管理されたカリキュラムとかそういうのではないので、どこまで効果的な学習が出来るかと言うと疑問が残ります。でも、Flashが楽しくなる前段階に必要な基礎の部分をみんなで持ち寄ってなるべく楽しく勉強して交流を深める事にはとても意義があると思います。

どうしても僕がうだうだと意見を書いていくとなんか変なテンションになっちゃうので、ひよこの会の意義なんかについては是非ともATNDやTwitter上の皆さんの意見を参考にしていただくとして、今後もみなさんの積極的な参加をお待ちしておりますよ！