2010年6月13日，Adobe Station 5にて「Spark project 勉強会 SP3」が開催された。本稿では，本勉強会のレポートをお届けする。
Spark project 勉強会は不定期に開催されており，今回は久しぶりの開催となった。
今回はSpark projectのコミッター9人が発表した。発表者はSpark project代表の@beinteractive氏が制作した，ルーレットによって選ばれた。このルーレットはFlashが乗っていないIPadで動作し，AIR2.0で強化されたServerSocket APIを用いてHTTPサーバーを建て，そのレスポンスによって発表者を決めるというSpark projectならではのGeekな手法が採られた。
Flash Player 10.1でmicrophoneはどう変わったか。
そんなルーレットで選ばれた一人目は@kappaLab氏。Flash Player 10.1で強化されたMicrophoneに対するサポートについて詳細に解説した。
Flash Player 10まで，マイクに対するサポートはアクセスと音量操作のみだった。それが10.1では，音声入力データの取得と加工になったのだ。これにより，録音／再生／保存などのいわゆるボイスレコーダーがRed5（FMSクローン）に頼ることなく，Flashだけで実装できると示した。
また，エフェクトやフィルター処理をかけることで，ライブやカラオケのような効果が得られると言及し，カラオケでエコーが掛かったような"リバーブ"，ある特定帯域をカットする"レゾナンス"のといった効果のデモを行った。
最後に，Flash Playerのみで音声認識のデモを行った。氏は「今回のサンプルは自分の声帯にあわせたもの。個々人にあわせたチューニングをすることでもっと面白いものが作れるのではないか」と述べた。
図1 @kappaLab氏のプレゼン
Androidで遊ぼう
2人目は@daoki2氏 。氏は，AIR for Androidに関して詳細に解説した。
氏は，通常のAIRランタイムではandroidアプリ同士を連携するintentがサポートされていないため，それを克服するためにAVM（ActionScript Virtual Machine）の自作を決意。AdobeがMozillaに寄贈したスクリプトエンジンTamarinを使用して独自にビルドしたという（しかし現在，Tamarinはビルド環境としてSnow Leopardがサポートされていないため注意が必要とのこと）。
デモでは，実際に動いているAndroidアプリケーションを紹介した。ボタンなどのGUIはAndroidネイティブのものを使用していることに言及し，「AIR for Androidには，まだモバイル用のWidgetがないため，GUIをすべて自前で用意しないといけない。デスクトップ用のFlexコンポーネントは重すぎるので，Adobeが推奨していない」と述べた。
AndroidのネイティブWidgetを使用することで，ほかのAndroidアプリと全く同じ使用感で扱うことができ，ユーザーライクにアプリケーションを組むことができるという。ただ現状はprelereaseということもあり，開発のハードルはまだ高いようだ。
氏によれば，「ASとJAVA両方のデバッグが必要になるため，デバッグがやりにくい。こんなめんどくさいことするなら，最初から最初からJAVAでもいいのではないのか」と苦言を呈したが，intentのサポートも含め，これらは今後Adobeによって改善されるものと願いたい。
図2 @daoki2氏による，AIR for Androidのデモ。ボタンはAndroidネイ ティブのものを使用している
AIR 2.0で遊んでみた
3人目は@ll_koba_ll氏。氏は，AIR 2.0で追加されたNative Processを使ったデモを披露した。
pingを送受信するシェルスクリプトをNative Processで実行し，その結果が出力された。また，その応用としてAIRアプリで特定ディレクトリ下にある.svnファイルを削除するアプリも紹介した。
氏は，openWithDefaultApplication()メソッドについても解説した。これは指定したファイルを関連づけされたアプリで開くことができるもの。デモでは，AIRアプリからJSFL（Flash Professionalの基本操作をJavaScripで制御できるAPI）を実行し，パブリッシュを行った。
最後に，MacBook Proのキーを叩くとFlash Playerのダイナミックサウンドによって音を生成，音楽が奏でられるサンプルをデモ。氏は，「ライブコーディングの時にプログラムを書いてる際，音楽が奏でられるような何かを作りたかった」と述べていた。実際，キーを叩いているだけでもパラメータ次第では，それっぽい音楽を奏でることができるようだ。
AIR 2.0の新機能はそれのみで完結するものではなく，相乗効果によって新たな可能性を開くことができるということを証明するデモだった。
図3 @ll_koba_ll氏
JSFL for Flash Professional CS5
4人目は，本稿の著者である@KaedeASから，Flash Professional CS5で追加実装されたJSFLのAPIについて解説した（発表資料はこちら）。
デバッグ周り，そしてタイムライン操作に関するAPIが追加されたが，そのひとつ，モーションスパンの長さを設定できるframe.setMotionObjectDurationメソッドのデモを披露した。これは，ショートカットで手軽にモーションスパンを設定できるもの。JSFLの利点はFlashにない，ちょっとした拡張をすぐに実装できる点にあるだろう。
また，Flash Professionalから，Antタスクの実行するJSFLを実行するデモを披露した。Antはビルドツールのひとつで，ソフトウェアのコンパイルやパッケージに用いられる。Flashと連携することで，パブリッシュ後ファイル群をzipし，特定のディレクトリに移動，FTPにアップロードといったことが全自動で行えるようになる。
これら2つのデモは後日，Spark projectにコミットする予定だ。
コンパイル速度高速化のためのTips
5人目は@clockmaker氏。氏は，Flash CS4とFlash CS5のコンパイルに関する検証を発表した（発表資料はこちら）。
氏によれば，Flash CS4はコンパイルが遅く，一般的に高速になると言われているSWCを利用したコンパイル手法でも，Flash CS4では108秒，CS5ではたった4秒で完了することを説明した。筆者的にはこれだけでもFlash CS5を購入する価値があると思ったが，氏によればこの恩恵はSWCによるコンパイルの時のみで，実ソースコードからのパブリッシュはむしろCS5のほうが遅いと指摘した。
また，氏はFlex SDKのfcshによるコンパイル手法についても解説した。この方法は，コンパイル後キャッシュされるため，コードが数万行も書かれているプロジェクトでもかなり高速にコンパイルすることができ，Flash Professioanlを利用したコンパイルよりも断然早いことが特徴だ。
今後，Flash CS5で素材やアセットをSWCにした上で，fcshを利用してコンパイルするといった手法が主流になるのではないだろうか。
図4 @clockmaker氏
