では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...

後半へ続きます。

シーン遷移と言えばFlashの画面展開として最も重要な部分。
FlashサイトからFlashゲーム、Flashアニメに至るまで、必ずといっていいほど考えなくてはいけない部分です。
必ずぶち当たる問題なのに、ほとんど直接作品とは関係ない部分でもありますし、かといってこれまた必ず制作の途中段階で変更を余儀なくされる部分でもあります。
なので本来の作品性に関係ない部分を出来る限り省力化をしながら作らないといけないし、かといって出来る限り柔軟に作っておかないと作品の作り込みに影響するという、ほぼ全てのFlasherのジレンマとして君臨し続けているのではないでしょうか（言い過ぎか）。

そんなシーンに対する、僕たちひよこたちの方法とは？
僕はProgressionのシーン遷移の部分に焦点を当てて（本来僕はProgressionの目玉を大きく三つにわけて、シーン遷移、キャスト、コマンドとしています。今回はそのシーン遷移の部分）、技術的なお話はおいておいて「何故Progressionを使うのか」についてお話しさせて頂きました。
ほとんど資料無しのお粗末な内容ですが、皆様ご静聴ありがとうございました！
「本やネットにある情報だけど、あえて口頭で説明した方がわかりやすいな」みたいな内容も交えてたので、ブログに残せるほど有意義な情報はありませんでしたが、一旦レポートしておきたいと思います。

そもそも何故Progressionを使うのか

Progressionとは何かをあえて間違って定義してみる

Progressionとかフレームワークとか、何かをインストールしないといけないとか勉強しないといけないとか、一旦難しい事はおいておいて、シーン遷移だけに限って言えばProgressionはとても便利なクラスライブラリと考えていいと思います。
クラスライブラリというのは、AS3を書く方なら一回は使ったことがあると思いますが、Tweenerとか、ああいったような、誰かがあらかじめ作ってくれたとても便利なクラスということになります（誰かが、とか言い回し失礼します）。

AS1やAS2しか触ったことがなくても、色を変えるColorとか時間を計算するDateとかあれもクラスですので、やはり一回は使ったことあると思うんです。
ですので、誤解を恐れずあえて極端なことを言うと、「Progressionのシーン遷移も、Dateなどのクラスと一緒なのだから、使い始めるのに何も特別なことはない」と言えると思います。

Progressionに対して抱いている（おそらく必要以上に）高い敷居を下げるためにあえて極端なお話をしましたが、この方法が正しいかどうかはわかりませんが、もちろん最終的には公式ページや技術書などでしっかりと理解することをお勧めします。

Progressionは難しい？

Progressionのシーン遷移は難しいか？いいえ簡単です。
難しいのはシーン遷移のほうです。
僕は長年シーン遷移に悩まされてきました。
最初は簡単なgotoAndPlayの分岐にはじまり、attachmovieやaddChildなどのアクションスクリプトに頼り、デザインパターンやMVCを引っ張り出しても完璧なものができませんでした（その原因の全てはデザパタやMVCが悪いんじゃなくて僕自身のスキル不足にあります）。
将来的な作り込みを見越して柔軟性に富んだ作りにしたつもりが、使いにくいAPIとスパゲッティな内部を持ったゴミの固まりみたいなのが出来たり、全く想定してなかった箇所に変更が入って作り直しを余儀なくされたり…。思い出すだけでも胃に穴が空きそうです（苦笑）。

そういった、「シーン遷移の難しさ」を簡単にしたものがProgressionのシーン遷移なのです。
ここは誤解でも極論でもないです。

具体的に知りたいProgressionのシーン遷移のこと

Progressionのシーン遷移で重要なクラスは
SceneObjectです。
（注意：公式のASDocのフレームに直リンク張っています）
このSceneObjectの主に四つの関数を呼ばれるタイミングを駆使するだけで複雑なシーン遷移をコントロールします。
その4つとは
atSceneGoto()
シーンから出発したときに呼び出される関数。

atSceneLoad()
シーンが読み込まれたときに呼び出される関数。

atSceneInit()
シーンが到着したときに呼び出される関数。

atSceneUnload()
自分より上の階層のシーンに移動して、自分が必要なくなったときに呼び出される関数。

です。
こちらも公式サイトに直リンクを張っていますので詳しくはリンク先でお調べ下さい
（注意：フレーム内に張っています）。

これについては、どの解説書でも丁寧に説明がなされています。
詳しくはそういった技術書で身につけることをお勧めしますが、まずはひよこのとっかかりとして口頭でこれらがどういった動きをするかを会では説明させて頂きました。

慣れないうちはとくにatLoadとatInitの使い分けに苦しんだ記憶がありますが、
それでも複雑なシーン遷移をこの４つの関数が呼び出されるタイミングで処理するやり方はとても理にかなったものなので、慣れれば多階層シーンの移動の際に、
atLoadはメモリの初期化など
atInitは描画処理など
atUnloadeでメモリの解放など
というようにうまく使い分けることで破綻せずシーン遷移が楽に行えるようになるかと思います（注意：ここに書かれてあるのは必ずしもatLoadでメモリの初期化をしないといけない、ということではないです）。

さいごに

まいどまいど長いばっかりで中身のないブログ内容で本当ごめんなさい。
基本的には技術的な検証あんまりしないし文章も推敲しないし自分の駄文レポートなので、読んでくださってる方には毎回申し訳ない気持ちで一杯です。

まあそんなありがたくも申し訳ない心情をつらつらと書いてても仕方がないので話を進めますと、あのあと帰ってから次の日にぎっくり腰になりまして、ただいま寝返りも打てない状態で安静中です（笑）。
ぎっくり腰になったきっかけというのも、ゴホンゴホンと咳き込んでいたらいきなりぐきっといったという地上最弱生物の名をまたしてもほしいままにしてしまいましたｗ

ひよこの会も僕が幹事とはいえあんまり何もしてない派なので、いつも細やかに仕切ってくださるひろゆきさんはじめ皆さんのご協力あって成り立っています。お忙しい中、ご協力もご参加も本当に感謝です！
「初歩的な質問をする会」なので、決して上級者お断りではないので、初心者も上級者もいろんな「いまさらな話」でみんなで盛り上がれたらと思います。

かといって「ひよこの会と聞いたけど自分ばかりが初心者でまわりがとてもレベルが高く感じた。こんな初歩的な質問していいのか迷った」という方が居ましたら、それこそまさしく初歩的な質問ですのでどしどし参加してくださいね！
僕ももうちょっと緊張しないようにやっていきますので、これからもよろしくお願いします。

FlashBuilderの画面。なにやら小難しそうだが…？

そもそもFlashBuilderって何？

FlashBuilderはEclipseというソフトのプラグインです。
もともとはFlexBuilderという名前だったそうですが、AdobeCS5のときに名前が変わってFlashBuilderとなりました。
EclipseについてはWikipediaにリンクを張りましたので、詳しく知りたい方はそちらを参考にして下さい。
ようはEclipseとはJAVAのコードを書くのにとっても便利なフリーソフトなんです。
で、ただJAVAを書くのに便利なだけでなく、プラグインでいろいろな機能を追加できるようになっているので、そのEclipseでActionScript3を書けるようにしたプラグインをAdobeが発売してる、そのプラグインがFlashBuilderということになります。

FlashBuilderを入れるとEcripseでAS3が書けるようになると言うことは、ほかにもPHPが書けるプラグインとか（有名なのはPDT）HTML+CSS＋JavaScriptが書けるプラグインとか（aptanaとか）いろいろプラグインを入れることによってEclipseをどんどんいろんな物を作れる便利な開発環境にすることもできます。
できます、が、そういう「ぼくのかんがえたさいきょうのえくりぷす」は実際使いにくいですしプラグイン同士の競合や不具合で壊れたりもするので、おおまかにプラグインごとにいくつもEclipseをインストールする事を僕はおすすめします。
そう、EclipseはひとつのPCにいくつもインストール出来るんです。
なので、AS3用のFlashBuilder入りEclipse、PHP用のPDT入りEclipse、HTML用にAptana入りのEclipse、データベース設計用にERMaster入りEclipse、というように僕は大きく分けて４つのEclipseをインストールしてあります。FlashBuilder以外でも興味もたれたプラグインありましたら是非検索して使ってみて下さい。
FlashBuilderのAdobeのページはこちら。

FlashBuilderは2種類ある

FlashBuilderは機能によって2種類に分けられます。
Standard Edition ¥31,500-
Premium Edition ¥89,250-
高いですね。
僕は、自分の作るFlashっていつも激重なので、どこに処理の負荷がかかってるのか知りたいと思いプロファイラー付きの高い方買いましたが、ふつうは安い方で全く問題ないです！
高いFlashBuilder買ったのに、相変わらずへぼいFlash野郎の僕を見てれば、Flashを作るのに高いソフトは必要ないことがよくわかると思います。

どうやって手に入れるの？

FlashBuilderは大きく分けて３つの方法で手に入ります。

1. Adobe Creative Suite 5 webpremiumを買ったらStandard Editionがついてくる
2. FlashBuilderを直接買う（AdobeStoreでオンラインで買えます）
3. 60日間無料の体験版をDLする

この記事を読む人はたぶん1番の方法が多いんじゃないでしょうか。
この記事の最初で「FlashBuilderはEclipseのプラグインです」と書きましたが、単純にプラグインだけのやつとEclipseとセットになったやつの2種類あるので、初めての人はEclipseとセットになったやつを選ぶと良いです
（実際に1番の方法でインストールされてるのはEclipseとセットのやつです）。

FlashBuilderを使うとなにが嬉しいの？

そもそもFlashのアクションパネルだけでも手一杯なのに、FlashBuilderなんてプログラマーの使うような小難しいソフトの使い方なんて覚えてられない、なんて方も多いと思います。
半分正解で半分間違いです。
確かにFlashBuilderはちょっとだけ敷居が高いですが、使いこなせばプログラムが苦手な人ほど重宝するようになるかと思います。
FlashBuilderの魅力は強力なコード補完。これに尽きると思います。
例えばブラウザ上で「ほげー」とアラートを表示させるためだけにAS3では

package
{
	import flash.display.Sprite;
	import flash.external.ExternalInterface;
	public class Main extends Sprite
	{
		public function Main():void
		{
			ExternalInterface.call('alert', 'ほげ〜');
		}
	}
}

こんだけのコードを書かないといけないのですが、
（AS2までは
getURL('javascript:alert("ほげ〜");');
とタイムラインの一行書いてただけでいけてた）
FlashBuilderではここまでのコードをほとんど自動化で作ってくれます。
Mainっていうクラスを作るまではマウスでちょいちょいするだけだし、
キーボードといえば「Ex」の二文字しか入力せず、あとは自動的に出てくる候補からスクリプトを選んでいくだけです。
さいしょにほんのちょっとだけ、FlashBuilderの使い方を覚えればあとはほとんど自動的にコード書いてくれるようになるので、面倒なことはFlashBuilderにまかせて作ることに集中できるかと思います。
僕みたいな、プログラムに自信のないひよこにこそ、こういったFlashBuilderやFlashDevelopなどのツールは必須アイテムなのでもっと早く使っとけば良かったと思います。

さっそく立ち上げてみよう

ここまでFlashBuilderのたいしたことない紹介で埋まってしまったので、そろそろ実際にFlashBuilderを立ち上げてみましょう。
僕はFlashBuilderをただ立ち上げるだけのことをするまでに、ここまで心の準備が必要だったので。
新しいツールってわくわくすると同時にちょっと怖いですよね。

Eclipseの洗礼、ワークスペース

はじめて立ち上げた場合、Eclipseのワークスペースの場所をどこにするか聞かれるかと思います。

これはいったいなんなんだ！？

ワークスペースを切り替えている様子。

ワークスペースについてもう少し。
僕は元々、ワークスペースを「作業ファイルもここに保存する」場所だと思っていたんですが、どうやらワークスペースと別の場所にあるファイルを読み込めるので、作業ファイルとワークスペースは別のフォルダにしておいたほうがよさそうです。
何故かというと、僕は作業ファイルをDropbox上においているんですが、同じ場所をワークスペースにも設定してしまうと、Dropboxが複数台のPCで同期したときにFlashBuilderのライセンス違反が起きてとんでもないことになるんです。
「お前ッ！2台のPCでFlashBuilderライセンス認証しただろッ！このくされワレザーめ！二度とお天道様拝めなくしてやる！」といわんばかりにFlashBuilderが凄いことになって、それはもう怖かったです。

そういうこともあるので、というか別にDropbox使って無くてもFlashBuilderみたいにライセンス認証のいらないフリーのプラグイン使ってる場合でも、とにかく僕はワークスペースと作業ファイルは別々にして運用しておくことを今はお勧めしています。
なのでここではワークスペースを「設定ファイルの保存場所を決める」くらいにとどめておきます。

プロジェクトを作ってみる

やっとFlashBuilderを使ってみましょう。ただ使うだけでここまで僕のチラシの裏が続いたのって、たぶんEclipseの記事でも世界最長ではないでしょうか。
そんくらい僕には最初の敷居が高かったんですよ…。

FlashBuilderでは、ひとつモノを作るたびに「プロジェクト」という単位で管理します。
このへんも「ちょっと何か作ってみよう」と考えたらさっとflaファイル作ってパブリッシュできるFlasherからするとありえへんくらい敷居が高いと思います。
そうなんですが、逆に言うとプロジェクト単位でものをつくっておけば、プロジェクト内のコードのやりとりがびっくりするくらいFlashBuilderが補完してくれるようになるのでここはぐっと我慢です。

FlashBuilderでプロジェクトを作るには大きく分けて3つの方法があります。

1. FlashIDEプロジェクトを作る
2. ActionScriptプロジェクトを作る
3. すでにあるプロジェクトをインポートする

他にもFlexプロジェクトを作るなんて方法もありますが、Flexに関しては完全に僕は分からない世界なので説明できませんです。
今回は１のFlashIDEプロジェクトを作る方法をとってみましょう。
最終的にはおすすめは２と３です。それぞれ僕の拙い過去の記事ですが
2に関しては
SWC+Progressionで快適コーディング生活はじまる！
3に関しては
Progression4をいい感じにFlashBuilderで作業できるようにする
あたりを参考にしてみてください。
そのものずばりなことは書いていませんが、ヒントになれば幸いです。

あとちなみに、FlashIDEって何のことかというと、Flashのことです。
あのタイムラインとかライブラリとかの、フツーのいつものFlashのことをこのブログではFlashIDEと呼んでいます。
IDEというと統合開発環境という意味らしいです。プレイヤーのFlashと区別するため、Flashを作るほうのFlash（flaファイルを開くやつね）をFlashIDEと呼ぶことに決めてます。ややこしくてすいません。

おれはFlashプロジェクトを作るぞオォッ！

実はこの記事書くに当たって僕も初めてこのプロジェクト作ってみましたｗわくわくしますねｗ

おっそれらしいのがあった

flaファイルを選べばいいみたい。

できたできた〜！

プレビュー！

ちょっと使ってみたんですが、このFlashIDEとFlashBuilderの連携は、どうやら今までFlashIDEでASするよりはマシ、みたいな感じですね。
今までASをFlash上で書いてた所をFlashBuilderに徐々に移行していって、最終的にはActionScriptプロジェクトなんかに移行するのをおすすめしますよ。

その他FlashBuilderで僕がつまづいたところ

基本的にまじでFlashBuilderを立ち上げて使えるようになるまでを記事に書きましたんで、具体的なFlashBuilderでの使い方はこの記事ではやめておこうかと思います。
そのかわり、僕が一番最初にFlashBuilderをつかってつまづいたところを少しだけ補足しておきます。

これはパースペクティブ

具体的な使い方はまた機会を設けて…

まじで立ち上げるまでをごちゃごちゃつまらない話しで長々と説明してしまいました。
記事中も何度も言いましたがひとえに僕が立ち上げるまでの敷居が高かったからです。
実際は立ち上げてさえしまえば、あとは適当に使ってると使えるようになるかと思いますが、とりあえず僕が一番最初に書きたかった「立ち上げるまで」を記事に書けたのでまた今度ぜひとも機会を見つけて実際の使い方も記事でまとめてみたいと思います。
僕自身も最近FlashBuilderさわり始めたぴよぴよのひよこちゃんですので、「こういう使い方できるよ！」みたいなお話ありましたら是非ともお聞かせ下さい。
これを機会に、実際にお会いした方ともそうでない方とも、ネット上や居酒屋でFlashBuilderひよこ談義とかできるようになれば僕は嬉しいです！

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

いきなりですが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の出番が増えるようになります。
「もっとこうしたほうがいいよ」とか「うちではこうしてるよ」ですとか、「うそばっかりやんけ！」などのご意見ありましたらコメント下さいね。
最近「ブログ読んでます」という反応が少しだけ得られるようになって、本当嬉しいです。

このサンプルでは30fpsで30秒かけてちょうど30px移動しています。

ただトゥイーンさせているだけという素材そのものを活かした作りになっております。

・・・なんですが1pxごとにしか進まないような感じで、カクついた動きになってしまっているのがお分かりになりますでしょうか。 これを解消するためにはこの為だけにAS仕込むか、別途FLV化させるか、と悩んでいたのですが、とっても簡単な方法で解決することができました。

みなさんもよくご存知の「スムージング」。

ライブラリ上のビットマップを右クリック→「プロパティ」にあるコレ！

これをポチっとチェックをいれるだけでほらこの通り。

画像のジャギー解消だけに有効なのかと思ったら、こんな使い方もあったんですね。 よく使ってた機能なだけにびっくりしました。

俗に言う「大重本」この写真はクリックするとアマゾンへ

著者である大重様、発送いただいたソーテック社様、この場をお借りしてお礼申し上げます。

献本していただくなんていう体験、僕自身の人生の中でそうあることでもないのでものすごくうれしいです。ましてやAS3を覚えるときに相当お世話になった大重さんからとなっては、これはもう本気でレビューするしかありません！！
僕も業務フレームワークとしてProgressionをがっつり使っている人間の一人として、また実際に自分が入門の時にどこでつまづいたのかとかも思い出しながら、かなり突っ込んでレビューしたいと思います！
考えてみれば本のレビューなんてそんなにやったことがなくて、もしかしたらかなりとんちんかんなことになるかもしれませんが、少しでも皆さんのほんの購入時の参考になればと思います。がんばります。

最初の印象

基本的には、AS3入門書で有名な「詳細！ActionScript3.0入門ノート」と雰囲気が一緒で前ページ青と黒の二色刷。
チャプター1でProgression4の基礎をひととおり習った後は、Proression4をフルパワーで使うためにほぼすべてのチャプターでクラススタイルでの説明になります。
なのでメインとなる読者の対象としては「詳細！ActionScript3.0入門ノート」などでAS3をある程度入門した方、といったところでしょうか。
技術書である以上、専門用語やスクリプトもよく出てきますが同じように画面写真も豊富なので、特に難解な印象は受けません。
多くの人が入門書を手にするとき「この本は自分のレベルにみあった入門書か」を気にすると思いますが、何をもって簡単そうとか難しそうと印象するのかは人それぞれですので、このへんは先もいったようにAS3入門ノートの雰囲気と一緒なのでそちらを読まれたことがある方はそれを参考にするといいでしょう。

入門ノートの名に恥じない、細やかな操作手順。こっから先の写真はクリックすると拡大します。

目次ごとの感想

全部でチャプター７まであります。

• チャプター1：Progression4の基礎
  • Progressionとは何なのかの説明に始まり、インストールから各プロジェクトの作成方法、さらにはコンポーネントスタイル、タイムラインスタイル、クラススタイルの3つのスタイルで実際にHelloWorldを表示させるまでが説明されています。
    このチャプターでひとまず全体にわたって動かしてみて、徐々に順を追ってこれから学習を進めるという構成になっているようです。
• チャプター2：シーンツリーの基本パターン
  • Progressionの肝のひとつである「シーン」についてかなり詳細な説明がされています。
    シーンの概念は、HTMLでいう「ファイル（ページ）」と同じく場面を構成する1単位なわけです。ほとんどの場合シーン構造がそのままサイトマップになりますので、このシーンの概念にチャプターをまるまる一つ費やして説明されているのはかなりわかりやすいと思いました。
• チャプター3：シーンの移動とシーンイベント
  • シーンの構造が理解できたら、次はいよいよシーンの移動を行います。
    このへんからスクリプトの記述が多くなってきます。
    
    

    ぱっと見でくじけそうになる人も！

    
    もしかしたらスクリプトに慣れていない方はこのへんから難しく感じるかもしれません。でも、大重さんの本（というかプログラミング技術書全般）には読み方のコツがあって、長いスクリプトの中でも重要なのは1行だけだったりするので、あとのほうにその重要な1行を抜き出してちゃんと説明されてあるんです。
    
    

    ちゃんと重要なところを抜き出して説明してくれる！

    
    なので長いスクリプトが苦手な方も、そこを読み飛ばして後から書かれてある重要なところだけを注目していけばいいのでそういう読み方をすれば安心です。
    シーンの移動に関してですが、前章でわざわざシーン構造だけを一章使って学習したことが活きてきます。シーン構造さえわかってしまえばProgressionは「前のシーンへ」「次のシーンへ」「上のシーンへ」「いきなり孫のシーンへ」などという便利なシーン移動がいろいろとできるので、この章はその移動方法が書かれただけですので一見スクリプトが多くてややこしいそうに見えますが、コツさえわかってしまえば易しいと思います。
• チャプター4：コマンドとコマンドリスト
  • ここから本の厚み的に後半に向かいます。
    コマンドもProgressionの機能の中核をなす技術の一つですが（ちなみにほかには、さっきやった「シーン」と次にやる「キャスト」）、配列を用いたSerialListとParalelListの入れ子など、かなり実践的な機能の紹介まで踏み込んで説明されています。
    あと173ページの虫がかわいいです。
• チャプター5：キャストオブジェクトを利用する
  • この章は全体から見るとさらっと流されているようにも見えますが、先ほどもいいましたようにProgression三本柱のひとつ（キャスト）について学習できます。
    僕が特に重要だと感じたのが、本で言うと185ページあたりに実際のFlashのムービークリップからCastMovieClipを作るやり方でして、これを知らないと多くの人が入門できたはいいけど実際のサイト作るにはどうしたらええのん？ってなっちゃうと思うんです。なのでこの説明からもこの本がより実践向けに書かれてあるんだなあと重ね重ね感じたのでした。
• チャプター6：外部ファイルの読み込みとプリロード
  • FlashのActionScriptの中でも特に難しいと感じる人が多いのが「外部ファイルの読み込み」だと思うんですが、Progressionはそこを比較的簡単に扱うことができます。
    簡単とはいっても、Progressionなりの書き方を覚えないといけないのはそれはもう仕方がないので、この章で勉強します。
    一括読み込みやリソース管理や先読み機能など、覚えるのも難しいけど自分で作るともっと難しい、つまり是非とも覚えて使いこなしたいかなり便利な機能もあります。
    こういった機能を、じっくり読みながら学習が進められるのも本ならではですね。
• チャプター7：さらに進んだ使い方
  • フルフラッシュサイトのディープリンク機能についてのつまづきやすい点の説明やカスタムコマンドなど基本的な機能をさらに突っ込んだ使い方からSWFをそのままシーンとして読み込む、リキッドレイアウトなどの夢のような機能までひととおり学習できます。
    ここまで読めば、もうProgression4の機能はひととおり学習したと言えますし、実際にFlashサイト制作に投入してもかなりの部分で応用できるようになるでしょう。

総評

気になった点としましては、たとえば82ページなどの「contentloaderInfo.bytesTotal」と「contentloaderInfo.bytesLoaded」など、説明ページの英数字が半角全角がどちらかに統一されていないところでした。文字の間隔がそれぞれ違うので少し見づらい点でした。見づらいのは説明文だけで、見たところソースコードなどは大丈夫だったので、問題はないんですがちょっと気になるな、というところです。
※大重さんより、半角全角統一されていないんじゃなくて、半角で統一されているけど均等割り付けで文字幅が広がっているとの事でした。長い単語を途中で改行しないようにするとどうしてもこうなってしまうらしいです。
それ以外に関しては先ほどから繰り返し言ってきた言葉なんですが、この本はProgression4の機能紹介だけにとどまらず、実際に使う側の立場としてどう学習していけば本当にFlashサイトが作れるのかを突き詰めた「かなり実践的で使える参考書」だと感じました。
僕の周りでも「Progression4の機能や出来ることについてはわかったし、今までも本やネットで基本的な作り方も学べたけど具体的に自分のFlashサイトでどう適用して良いのかわからない」といった声を多く聞きました。「詳細！Progression 4 Flashフレームワーク入門ノート」は機能紹介から一歩踏み込んだ、まさに使えるようになるための入門ノートとして最適ではないでしょうか。
Flashの開発環境はCS3/CS4/CS5にまたがって対応している点もありがたいですね。
今日からでもこの本読みながら学習したことを仕事に投入していきます！

最後に、僕自身がProgressionのファンであり大重さん本のファンでもあるので、こんな僕のつたないレビューですが皆さんの購入の判断にちょっとでもお役に立てれば幸いです。

あ、あと本の中身の写真に関しては著作権を侵害しないよう最大限配慮したつもりですが、もし至らない点などありましたらお知らせください。

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リファレンスをダウンロードする