« April 2007 | Main | June 2007 »
May 30, 2007
ColdFusion 8 ベータ版公開
ColdFusion 8 のベータ版が Adobe labs に公開されました。（ColdFusion 8 @Labs）
主な新機能は以下の通りです。英語ですみません。
- Server monitoring to help identify server bottlenecks, allowing for tuning and improved performance.
- Step through code debugging in a new Eclipse plug-in debugger.
- Adobe Flex™ and Ajax features that let ColdFusion power personalized, multimedia-rich applications to enhance users’ experiences on the web.
- High-quality, dynamically created on-demand multimedia presentations.
- PDF document and form integration for a printable, portable way to intelligently capture and share information.
- Image creation and manipulation with more than 50 new CFML tags and functions.
- Native support for .NET objects to easily integrate ColdFusion applications with enterprise data and infrastructure services.
- Significant application runtime and server performance improvements.
Posted by ackie at 07:41 PM | Comments (1)
May 28, 2007
AS3 で動的言語のススメ
AS3 は元来動的言語ですので、改めて勧めるというのも変な感じですが、今回はさらっと読んでいただければと思います。
AS2 と AS3 のコンパイル時の型チェック
まずは何も属性もメソッドも定義されていないクラスを定義してみます。
class Foo { }
次に、上のクラスを使って以下のような記述をします。2 行目で存在しないメソッドを呼び出しています。
var foo:Foo = new Foo(); foo.nonExistingMethod(); // 存在しないメソッドの呼び出し
このコードをコンパイルしたとき、AS2 ではコンパイル時にエラーが出力されます。一方 AS3 ではコンパイルエラーにはなりません。この結果から、AS3 のほうがコンパイル時のチェックがゆるい言語だということが分かります。
そんな結果にはならなかった！という人は strict というオプションを付けてコンパイルをしているからです。
Flash を使っている場合はパブリッシュ設定パネルの AS3 設定パネルに、Flex Builder であればプロジェクトのプロパティパネルのコンパイラの設定パネルを開いてみると、”strict” あるいは ”厳密な型” という言葉が含まれれるラベルの付いたチェックボックスがあると思います。これを見つけたら選択を解除しましょう。この状態が本来の AS3 コンパイラの動作です。
AS2 における型
Flash 5 で ActionScript 1 が導入されて以来、Flash コンテンツへのスクリプトの利用範囲もどんどん広がって、Flash MX の頃にはコードを大量に記述することも多くなっていました。そんな中、ActionScript でも OOP ができるようにと導入されたのが ActionScript 2 です。これで class キーワードも使えるようになりました。
ところで、AS2 は AS1 上のレイヤーとして実装されました。例えば AS2 は AS1 の上に OOP をサポートするためのフレームワークをのっけた環境であると考えてもよいでしょう。
このとき、AS1 の実行環境は型をサポートしていないので、同じ環境で実行される AS2 にも実行時の型サポートが無いという状況が起きています。つまり、AS2 における型の使用は、オーサリング時の ”生産性向上のベストプラクティス” としての位置づけ以上ではないわけです。実際 OOP をまじめに追求するほど AS2 のアプリケーションは遅くなる傾向を持っています。
それと、AS1 / 2 が実行環境を共有していることで、もうひとつの問題があります。それは実行環境がランタイムエラーを通知しないことです。
AS1 の始めの頃はごく補助的な使われ方を主に想定していたためエラー通知機能が省かれたのだと思いますが、AS2 ではこれは無視できない問題です。例えば、コンテンツの再生時にスクリプトの実行に失敗していても、どこかでエラーが起きているようだと気づいたところで状況を知る手段がないため、問題の箇所を特定することはかなり困難です。
そこで、AS2 のコンパイラは静的言語的な動作をするように設計されました。この記事の最初の例のように、存在しないメソッド呼び出しをコンパイル時にエラーとみなすのはそのためです。
一方、AS3 はデバッグプレーヤがランタイムエラーを報告します。この機能があるため、（ようやく） 動的言語らしく、様々なコンパイル時のチェックをオプションにすることができたのです。
動的言語と静的言語
ちょと聞きかじったところによると、静的言語がコンパイル時に決定できることはできる限り決めてしまえという考え方の言語であるのに対し、動的言語は実行時まで遅らせられることはできるだけ遅らせてみようという言語だということで、一般的には、静的言語はパフォーマンスや大規模開発における生産性に優れていて、動的言語は柔軟性や記述の簡潔さで勝っていると言われているようです。
とはいえ、動的言語と静的言語の間に厳密な線を引くのは難しく、この説明も、動的言語的な性質と静的言語的な性質の記述と理解したほうが適切かもしれません。例えば AS3 のコンパイラは strict オプションを付けることで静的言語的な振舞いを取るようになります。
AS3 も動的言語のはしくれですから、変数宣言 / 型注釈 / セミコロン等なしでプログラムの記述ができます。
foo = ["one", "two", "three"] for each (i in foo) trace(i)
for each 構文も AS2 にはなかったですね。
おわりに
AS3 は動的言語なりに柔軟性の高い言語です。問題は Flash CS3 のビジュアルオーサリング環境との統合がまだ最初のステップであること。これは CS4 に向けての大きな課題だと思いますし、是非今後フィードバックをお願いします。
Posted by ackie at 06:57 PM | Comments (0)
May 25, 2007
イベントリスナ （AS3） とガーベジコレクション
不要になったオブジェクトへの参照が残っていると、そのオブジェクトの使用しているメモリを開放することができません。特に複数の参照を持つオブジェクトに対しては、参照の消し忘れによるメモリリークが発生しないよう注意が必要です。
イベントリスナを登録すると、イベントのターゲットになるオブジェクトとイベントリスナを持つオブジェクトの間で参照ができます。AS3 では下のような記述になります。
eventTarget.addEventLisener("type", eventHandler);
このコードを実行すると eventTarget と this の間に参照がつくられます。（eventHandler は this オブジェクトのメソッド）
ところが、これは明示的な参照の追加ではありません。そのため、参照の削除が必要な場合でも見落としてしまいそうですよね。
というわけで、今回はイベントリスナ追加時の参照の扱い方についてです。
参照の方向
参照には方向性があります。つまりオブジェクト間の参照は一方向のみ可能ということです。例えば以下のようなコードがあったとします。
var foo = New Foo(); foo.bar = this; foo = null;
一行目で作られている参照は ”このオブジェクト （this）” → ”New Foo() で作られたオブジェクト” という方向の参照です。二行目で作られている参照はこの逆で ”New Foo() で作られたオブジェクト” → ”this” という方向です。三行目では一行目で作成した参照を削除しています。そのため ”this” から ”New Foo() で作られたオブジェクト” へと辿ることはもうできません。
前の記事にあるように、ガーベジコレクタはオブジェクトツリーのルートから参照を辿ります。まず、ルートの子オブジェクトを見つけて、次にその子オブジェクトの子オブジェクトを見つけるという動作を繰り返します。
とすると、上のサンプルが実行された場合、”this” が親オブジェクトであれば、ガーベジコレクタは ”New Foo() で作られたオブジェクト” を見つけることができません。つまり二行目で作成した参照は残っていたとしても、三行目が実行されていればメモリリークの心配は無いことになります。
メモリリークの原因になり得るのは、親から子への参照のみであるということですね。
子オブジェクトへのイベントリスナ追加
では、イベントリスナ追加時にはどの方向の参照ができるのでしょうか。
var foo = New Foo();
addChild(foo);
foo.addEventListener("click", clickHandler);
上の例では foo という子オブジェクトを作成して、その子オブジェクトである foo に clickHandler というイベントリスナを登録しています。clickHandler は親オブジェクトのメソッドです。
この場合には、子オブジェクトから親オブジェクトの方向の参照が作られます。 そのためイベントリスナはそのまま放置しておいてもメモリリークを引き起こすことはありません。親オブジェクトは不要になったら foo への明示的な参照を全て削除すれば十分です。
つまり、イベントリスナの追加時には、イベントリスナが追加されるオブジェクト → イベントリスナを持つオブジェクトの方向に参照が作成されているということです。（より正確には、イベントリスナが追加されるオブジェクト → イベントリスナ → イベントリスナを持つオブジェクト）
Flex ではイベントリスナの設定に以下のような記述が良く使われます。
<my:Foo id="foo" click="clickHander(event)" />
このケースでも、foo を後で削除する場合、イベントリスナが登録されているかどうかは気にしなくてもよいわけです。Flex 書いた事のある方は分かりますよね？
親オブジェクトへのイベントリスナ追加
次は下のようなケースを考えて見ます。
var foo = New Foo();
addChild(foo);
addEventListener("click", foo.clickHandler);
今度は親オブジェクトが子オブジェクトのメソッドを登録しています。ということは、親から子への参照が作成されているということです。
このような場合は、子オブジェクトへの参照を削除する際にイベントリスナも削除しないとメモリリークの原因になります。
下のように子オブジェクトから親オブジェクトにイベントリスナを設定する場合も同様です。
parent.addEventListener("click", clickHandler);
イベントリスナの削除には removeEventListener() を使います。
parent.removeEventListener("click", clickHandler);
また Flex に話を移しますが、特に Flex では親子関係が分かり難い場合があります。例えばポップアップ表示されるウインドウオブジェクトがあったとして、その中でクリックイベントのリスナを SystemManager に登録した場合、
SystemManager.addEventListener("click", clickHandler);
SystemManager からポップアップウインドウへの参照が作られます。
ところで SystemManager はポップアップウインドウを管理する親オブジェクトでもあります。そのため、SystemManager からポップアップウインドウへの参照が 1. popupChildren の配列からと、2. イベントリスナ経由、の 2 つ存在することになります。従って、この場合は、ポップアップウインドウを削除する時にイベントリスナも削除しないとメモリリークが発生します。
弱い参照の利用
弱い参照とは、たとえ存在していても、ガーベジコレクションの際に参照としてみなされない参照です。
これは大変便利で、イベントリスナにより生成される参照が全て弱い参照であれば、参照の方向とか気にせず登録したリスナを放置しておいて良いことになるからです。
都合の良いことに、イベントリスナの登録時に弱い参照を使うかどうかを指定することができます。addEventListener() の5 つ目の引数を true にすれば弱い参照が使われます。
addEventListener(”type”, listener, false, 0, true)
3 つ目と 4 つ目の引数は false と 0 を指定しておけば大抵問題ありませんので、上の形を覚えておけば大丈夫です （たぶん）。今後イベントリスナを登録する際はこれを使うように決めてしまうというのも結構お勧めかもしれません。
Posted by ackie at 06:09 PM | Comments (1)
May 24, 2007
Adobe Apollo Developers Night
昨日 Apollo mini Camp@Tokyo においでいただいた皆様、お疲れ様でいた。何かのご参考になれば幸いです。
さて、引き続き 7/10 （火） に Apollo Developers Night というイベントがあります。場所は EBIS303 で午後 6 時開始予定です。
定員は 600 名で申し込みも始まっていますので参加ご希望の方はお早目に。今回は有償です。（3,000 円）
詳細及び申し込みはイベントサイトからどうぞ。（Adobe Apollo Developers Night） なぜかイベント名に Developer が付いてますが、どなたでもご参加いただけます。
Posted by ackie at 01:17 PM | Comments (0)
May 23, 2007
Flash Player 9 のガーベジコレクション
Flash/Flex のアプリケーションを開発していると （たまには） メモリリークとか気になることもあるかと思います。今回は Flash Player 9 のガーベジコレクションについてです。詳細な実装レベルだと、Flash Player のアップデート時に、ガーベジコレクション周りでも多少の変更が行われたりしていますが、いまのところ基本的なモデルは変わっていません。今回はこの ”基本的なモデル” を紹介します。
Flash Player 8 以前は少し違ったモデルになっています。以下の記述内では Flash Player とあったら Flash Player 9 のことだと思ってください。
Flash Player のメモリ確保
Flash Player のメモリ確保時の動作は特にユニークなものではありません。が、話の基本になるのでとりあえず以下概要です。
メモリの確保は負荷の高い部類に属する処理です。そのため、Flash Player がメモリを確保するときは、必要になるたびに毎回確保するのではなく、一度にある程度大きなメモリ領域を確保しておいて、それを小さなブロックに分けて使用します。メモリの割り当てが必要になるごとにブロックを一つ一つ使用していきますが、これらのブロックは既にメモリ上に確保されています。すなわち、メモリの割り当てを行うけれども、実際のメモリの確保は必要は無い状態になるわけです。全てのブロックを使い切ると、次の大きなメモリ領域を確保します。
ちょっと、”たんす” と ”引き出し” の関係に似ています。買うのは ”たんす” 単位、使うのは ”引き出し” 単位、ということで。
なお、ビットマップデータのように大きなデータは個別にメモリの確保が行われます。
メモリ参照の削除
さて、今度は一旦確保したメモリ領域を開放するときの動きです。
例として下のコードを考えることにしましょう。
var foo = new Foo(); foo = null;
まず、一行目の右辺でオブジェクトを生成しています。その際に、新規オブジェクトに対してメモリ領域が割り当てられます。
以降の話を単純化するため、ここでは
「一つのオブジェクトに割り当てられる領域 ＝ ブロック （引き出し） 一つ」 と仮定
することにします。そうすると一行目では新規オブジェクトの格納されている "引き出し" への参照を foo という変数に渡していることになります。
二行目で foo の持つ参照を無効にしています。このとき削除されているのは "引き出し" へ の参照であって "引き出し" の中身ではないことは重要です。つまり、このままだと "引き出し" は空になっていないはずです。変数に null を代入するだけではメモリを開放するのに十分ではないわけです。
ところが、プログラム側からはこれ以上メモリの開放に関与することはできません。後は、どこかのタイミングで起動されるはずのガーベジコレクタに任せることになります。
ガーベジコレクションの動き
Flash Player 上ではオブジェクトの格納されている ”引き出し” はツリーとして管理されています。ツリーのルートは Stage です。（正確にはクラス定義とローカル変数がルートのツリーもあります）
ガーベジコレクタは、Stage から順番にツリー上のノード （ここでは ”引き出し” ） を辿ります。途中で見つかったノードには印を付けます。
上のサンプルコードに当てはめてみると、一行目の実行が完了した時点では foo から新規オブジェクトへの参照が存在します。ですので、このタイミングでガーベジコレクタが実行されると （Stage から foo を含むオブジェクトへたどり着くことができれば） foo を含むオブジェクトに印を付けた後に新規オブジェクトにも印を付けます。
ところが、二行目 （foo = null） の実行後には新規オブジェクトへの参照は削除されています。そのため、この時点でガーベジコレクションが実行されると foo を含むオブジェクトに印を付けた後、新規オブジェクトへとたどることができません。その結果、新規オブジェクトには印を付けません。
ガーベジコレクタがツリーを最後まで全て辿り終えて、それでも印の付いていない ”引き出し” は、ようやく再利用や開放の対象になります。この後実際にメモリを開放するのもガーベジコレクタの仕事です。
さて、ガーベジコレクタが動いても実際のメモリ開放までは行われないケースがあります。以下、3 点ほど理由を説明します。
重要な点ひとつ目
まず、メモリの割り当てや解除はブロック単位で行われますが、物理的なメモリの確保や開放は、ブロックの集合であるもっと大きな塊が単位です。前にも書いたように、使うのは ”引き出し” 単位、売ったり買ったりは ”たんす” 単位、ということです。
このため、たとえ一つでも "引き出し" が使用中だと、その "たんす" は返却できません。実際に、ガーベジコレクタが実行された結果、いくつかの "引き出し" を空にしていたとしても、 "たんす" が返却できなければ、確保しているメモリの量は減らないわけです。
このような場合にはガーベジコレクタが使用中の "引き出し" を他の "たんす" に移すことで、全ての "引き出し" を空にして （いわゆるコンパクション） "たんす" を開放できるようにします。が、これは必ず実行されるわけではありません。その理由は 2 つめの理由にあります。
重要な点ふたつ目
Flash Player のガーベジコレクタは控えめで、メモリの開放を積極的に行うようにはなっていません。
ガーベジコレクションは非常多くの作業を行うため、長時間に渡ってリソースを占有する可能性があります。その結果、例えばちょっとの間なり画面が固まった状態になってしまうかもしれません。これはユーザインターフェースとしては望ましくないことです。
そこで、ガーベジコレクタは全ての処理が完了していなくても、描画処理やインタラクションを邪魔しないように途中で実行を中断することがあります。コンパクションのように重い処理は、より完了しない可能性が高いと思われます。
これは、また、描画処理やスクリプトの実行でクライアントの負荷が高い状況が続いていると、メモリの開放が起きにくいということでもありますね。
重要な点みっつ目
繰り返しになりますが、ガーベジコレクションは重い処理です。そのため、起動される条件が限定されています。それは、
- 新しくメモリの割り当てが要求された
- 空いているブロックの残りが少ない
の2つが重なって、新しくメモリを確保する必要が出そうな場合です。
ということは、スクリプトが何も実行されていない状況では、ガーベジコレクタも起動されません。アイドル状態のアプリケーションを一生懸命観察していてもメモリは減らない訳です。
Posted by ackie at 07:36 PM | Comments (2)
May 21, 2007
Kuler の Apollo 版
Kuler （Kuler@Labs） の Apollo 版が公開されましたのでご紹介しておきます。編集機能は無いので、結局ブラウザも使うことになります。今後、機能が追加されていくのでしょうか？
air ファイルのダウンロードは kuler desktop@Labs から、Apollo ランタイムは Adobe Labs Downloads/Apollo Runtime からです。
Posted by ackie at 12:45 PM | Comments (0)
Adobe Visual Communicator 3 プレビュー版公開
Adobe Visual Communicator 3 のプレビュー版が Adobe Labs に公開されました。（Adobe Visual Communicator 3@Labs）
Visual Communicator は昨秋の Serious Magic 買収により Adobe の製品に加わったものです。Visual Communicator 3 を使うと、簡単に映像によるプレゼンテーションを作成して、Flash ビデオとして公開することができます。
US での出荷はこの夏を予定しています。既に Adobe US のサイトには製品ページも公開されています。（Adobe Visual Communicator）
プレビュー版のダウンロードが Adobe Labs から可能です。8月31日まで試用可能です。（Adobe Labs Downloads/VC3） サイズが大きいのでダウンロードは多少余裕のある環境で行うのがよさそうです。
Posted by ackie at 11:56 AM | Comments (0)
Spry framework for Ajax プレリリース版 1.5 公開
Spry のプレリリース版が 1.5 になりました。（Spry framework for Ajax@Labs） 先日発表された Dreamweaver CS3 では既に Spry のサポート機能が追加されていますので、Spry の正式版のリリースももう一息といったところでしょうか。
1.4 からの変更としては、バグフィックスの他 JSON Data Sets や Nested Data Sets やいくつかのウィジェットが追加されています。詳しくはドキュメント （Spry Documentation@Labs） をご参照ください。
ダウンロードページはこちらです。（Adobe Labs Download Spry）
Posted by ackie at 10:13 AM | Comments (0)
May 17, 2007
FreeHand 開発終了
公式な発表はまだですが、FreeHand の開発終了意向表明が出されるようです。今後は新規機能追加やバグフィックス等は行われなくなりますが、販売は続けられます。（日本での販売形態の詳細についてはまだ未確認） サポートは従来のものが引き続き提供されます。
Illustrator CS3 では FreeHand 形式のファイルが扱えるなどの改善がされていて、FreeHand ユーザには Illustrator への移行が推奨されることになりそうです。FreeHand であればどのバージョンからでも Illustrator CS3 に特別アップグレードが可能になるとのことで、これも未確認ですが元ネタ （FreeHand no longer updated） によれば Adobe Store では 24,762 円を予定となっています。
Vista 以外ならまだまだ使えるのですけどね。
Posted by ackie at 03:00 PM | Comments (3)
May 14, 2007
Adobe Apollo mini camp@Tokyo
今月 Apollo のエバンジェリストの Mike Chambers が来日します。それにあわせて 5 月 23 日（水） 18:00-20:00 に大崎ゲートシティホールで Apollo mini camp@Tokyo が開催されることになりました。（Apollo mini camp@Tokyo）
セミナー自体は無償ですが事前登録が必要です。セミナーの特設サイトからお申し込みください。（Apollo mini camp@Tokyo 事前登録） 定員は 150 名ですのでお早めに。
Posted by ackie at 10:56 AM | Comments (0)
May 09, 2007
FLVCheck アルファ版公開
FLVCheck のアルファ版が Adobe Labs に公開されました。（Adobe FLVCheck tool@Labs）
FLVCheck は Adobe 製品以外で作成された flv ファイルのフォーマットが仕様にしたがっているかどうかをチェックします。誤ったフォーマットの flv ファイルが存在して、FMS からのストリーミング再生時に問題を起こしていることが分かったために、公開前にファイルの検査ができるようこのツールは開発されました。
FLVCheck は内部タイムスタンプ、メタデータ、メッセージヘッダーに問題が見つかるとそれを修正して書き出すことができます。その際オリジナルは別ファイルとして保存されます。映像や音声のデータ本体が正しくない場合はエラーの通知のみで修正は行いません。
FLVCheck は Labs のダウンロードページから入手できます。（Adobe Labs Download/Adobe FLVCheck tool） チェックボックスをクリックするとダウンロードのリンクがアクティブになります。ダウンロードファイルには簡単なドキュメントも含まれています。
今回のアルファ版は Windows 版のみで、コマンドラインツールになっています。使用手順は以下のとおりです。
- まずは flv ファイルを用意します
- （初回のみ） ダウンロードした zip ファイルに含まれている vcredist_x86.exe を実行してランタイムをインストールします
- Windows のコマンドプロンプトのウインドウを開きます
- プロンプトから FLVCheck を実行 - このとき必要に応じてパラメータを指定します （パラメータは -h を付けて実行するとリストが表示されます）
Posted by ackie at 04:54 PM | Comments (0)
May 08, 2007
Adobe CS3 日本語版発表
本日、CS3 日本語版が発表されました。
従来の Macromedia Studio に相当するのは Web Standard （Web Standard の機能） で、Dreamweaver, Fireworks, Flash, Contribute がパッケージされています。これに Photoshop や Illustrator が加わると Web Premium （Web Premium の機能） というパッケージになります。
出荷はまだ少し先で6月下旬予定です。After Efffects や Premiere を中に含む Master Collection と Production Premium は7月中旬以降に出荷の予定です。
出荷に先立ってお披露目イベントも予定されています。6月8日（金）の午後 1 時半から品川プリンスホテルです。詳しくはこちらのページをご覧ください。（Adobe Creative Suite 3 発表記念イベント） 無償ですが事前登録が必要ですので参加予定の方はお早めに。
それから、既に Web 上では Adobe スゴロク CS3 が公開されています。結構はまります。携帯サイトにもいくつか入手可能なアイテムがあるようですよ。
なお、今回からアップグレードポリシーが 3 世代までに変更されましたのでご注意ください。（アップグレードポリシー変更について） ややこしいので Web 関連だけアップグレード情報をまとめておきますと、
Web Standard については旧マクロメディアの MX 以降の製品が対象で、いずれかの Macromedia Studio か Dreamweaver もしくは Flash をお持ちの方がアップグレード可能です。ちなみに Adobe Store の価格では Studio もしくは Dreamweaver + Flash Professional (MX は普通の Flash で可） をお持ちの場合は 49,800 円、Dreamweaver または Flash 単体をお持ちの場合は 102,800 円です。
Web Premium はこれに加えて、CS 以降の Suite, Photoshop, Illustrator もしくはPhotoshop 7 か Illustrator 10 もアップグレード対象製品になります。Adobe Store の価格では Studio もしくは CS1/2 Premium/Standard をお持ちの場合は 111,000 円、それ以外は 202,000 円です。
アップグレードの詳細のページ （アップグレードの詳細） の中ほどにある "アップグレードツール" タブをクリックすると、アップグレードに必要な条件をチェックするツールが使えます。よろしければこちらもお使いください。
Posted by ackie at 04:59 PM | Comments (0)
May 04, 2007
Flex Module for Apache and IIS アップデート
Flex Module for Apache and IIS が地味にアップデートされました。（Flex module for Apache and IIS@Labs） 主な変更項目は以下のようになっています。
- PowerPC サポート追加
- Windows Vista サポート関連の修正
- キャッシュによるコンパイル速度の改善
- JRE 1.4.2 互換性関連の修正
- IIS 6 で誤った content-length が送られる件への対応
- IE の自動キャッシュ機能への対応
- Windows の PATH 変数関連の対応
- template を若干変更
- Apache 1.3.7 / Windows サポート追加
Flex 2.0.1 以降と JRE 1.4.2 以降をお持ちの場合は、以下のインストーラをダウンロードしてください。
無い場合は SDK & JRE 込みのインストーラをどうぞ。
ライセンスアグリーメントは次の URL にあります。（Software License Agreement@Labs）
Posted by ackie at 08:56 AM | Comments (0)
May 01, 2007
Flash Player 9 Solaris 用プレリリース公開
Solaris プラットフォーム用の Flash Player 9 プレリリース版のアップデートが公開されました。Adobe Labs からダウンロードできます。 （Flash Player 9 Update）
Posted by ackie at 12:29 PM | Comments (4)