preload
5月 11

自分で本を書いてみると、売れ行きや評価などはそれなりに気になるもので、ちょくちょく Amazon.co.jp の商品ページやらブログ検索などを見に行ってしまうのですが、せっかくなので、そういうニッチなニーズに応えられるサービスでも作ってみるかと思いたちました。以下の URL で個人サービスとして公開しています。

Amazon SalesRank Tracker α version

Screenshot-25

あらかじめ書籍を登録しておくと、登録済みのカテゴリ内での表示順や、Amazon.co.jp ランキングの情報を追跡・記録、それに Twitter やソーシャルブックマーク、ブログ検索結果などをひとまとめにしたダッシュボード画面を作成します。

最初はAWSのAPI経由でごにょごにょしていたのですが、ランキング情報がサイトで見られるものと微妙に違っていたり、そもそもAPIの利用規約的にアレだったりするところもあったので、いろいろ調整&データの素性がわかる範囲でまとめました。道楽で作っているので、今ひとつ足りない機能や不具合などあるかもしれませんが、よろしければご利用ください。

なお、本サービスの稼働環境は暫定的なものなので、あくまでアルファ版です。突然、終了するかもしれませんのでご了承ください。

ちなみに、下記書籍、連休中は在庫切れになっていたようですが、現在は在庫が回復しているようです。こちらも引き続きよろしくお願いいたします。


Ruby on Rails携帯サイト開発技法

伊藤 祐策. ソフトバンククリエイティブ 2010, 大型本, 312ページ, ¥ 2,940

ところで、作る前に探した感じではこういったサービスが無いように感じたのですが、作った後で探したら、似たような商用サービスや海外サービスがいっぱいありました。。けど、ランキング情報以外の情報もダッシュボード的にまとめてくるっていうのが欲しかったので、まあいいか、と納得することにします。作ってるのも面白かったし。(実はニフティクラウドのモニターアカウントをいただいていたので、それの実験サイトでもありました。といっても、これといってあんまし時間取れなくて、実験らしいことはできなかったですが。。コントロールパネルは使いやすかったです(それだけか))

Tagged with:
4月 24

このたび「Rails で携帯サイトを作る」という趣旨の解説書の執筆に参加させていただきました。共著者のお二方、お声がけいただいた編集者様には、大変お世話になりました。このたびは、ご一緒させていただき、ありがとうございました。


Ruby on Rails携帯サイト開発技法

伊藤 祐策. ソフトバンククリエイティブ 2010, 大型本, 312ページ, ¥ 2,940

いわゆる「スマートフォン」向けサイト開発の解説書ではありません。iPhone も android も出てきません。あまり好きな表現では無いですが、あえて言えば「ガラケー」サイト開発の解説書です。

今さら?という声も聞こえてきそうですが、僕は、ある意味良いタイミングだったかも、と思ってます。まだまだ今の状況では「スマートフォン」サイトに(堅実に)お金をかけられるところは少ないという印象ですし、一方で「ガラケー」は「ガラケー」で、わりと基本的なところは変わらなくなってきつつありますし。

個人的には「ガラケー」に固執するつもりはさらさらないですし、かといって今すぐ「スマートフォン」に飛びついてズッポリ浸かりたいというノリでもない感じです。が、まあ、一方で、僕は「ケータイ」がわりと好きなので、どっちにせよ、携帯向けサービスを Ruby/Rails で作っちゃおうぜ、という流れが少しでも広がると、周りから楽しいサービスが生まれていったり、便利なライブラリやノウハウが蓄積されていったりで、そしたら僕もずっと楽しく Ruby と付き合っていけたりで嬉しいので、そんなきっかけになればいいなーと思いながら書きました。

ちなみに、僕はメールに関する章と、Flash Lite に関する章を書きました。Flash Lite の章は Rails からだいぶ離れた話題になっていますが、昨今の携帯サイトを作るという意味では外せない話題だったと思います。概要だけとはいえ、 SWF の内部構造やら、(Flash Liteの各種制限に着目しつつ)オープンソースソフトウェアを併用した SWF のサーバサイドでの生成について扱っている書籍は、他にあまり見ないな、と思いますです。(Flash Liteに限らなければ洋書では何冊かあるのですが。)

あとは、これに動画/音楽系サイト、オートGPS、モバイル向けソーシャルアプリとかの話が加えられるとさらに良かったかな、と思いますが、その辺の話はまだまだ非公開部分が多いので何ともですね。テスト周りが書けなかったのは惜しかったかな。とはいえ、そこそこ守備範囲の広い内容になっていると思います。

最後に、Flash Lite の章で、ページの都合で載せられなかった幾つかのコラムについて、許可をいただいたので、こちらに紹介しておきます。(ちょっと文脈が無いと意味わかんないところがありますが、Flash Lite の章は、こういう文章が途中に入るような内容になっているとご想像いただく材料になれば。)

コラム 利用できるActionScriptバージョンに注意

ActionScriptはFlashプレーヤおよびFlash Liteプレーヤ上で動作するスクリプト言語で、よりインタラクティブなFlashコンテンツを制作するうえで欠かせない存在です。本書執筆時点の最新バージョンは3.0(Flash Liteプレーヤでは利用不可)です。Flashプレーヤのバージョンアップに伴い、ActionScriptの言語仕様やプログラミング環境/実行環境は大きく様変わりしてきています。表7-1で示した通り、Flash Liteバージョンを決定することは、利用できるActionScriptバージョンを決定することにもなりますので、対象のFlash Liteプレーヤバージョンを選択する際は、注意しておきましょう。

コラム Flash Liteコンテンツ内での絵文字利用

バージョン/キャリアによっては、Flash Liteコンテンツ内で各キャリアの絵文字を利用できます。ただし、(本書でこれまで紹介してきた通り)絵文字の表記方法はキャリア別に異なりますし、上記で示した通り、プレーヤバージョンごとに利用できる文字符号化方式も異なっていますので、絵文字の利用には十分に注意が必要です。

コラム SWFの動的生成はボトルネックになりやすい

本章では、swfmillを利用した “元のSWF→元のXML→書き換え後XML→書き換え後SWF”というSWF動的生成の一連の流れを紹介しました。しかしながら、swfmillの利用やXMLの解析/書き換え処理は、それなりに時間のかかる処理ですので、Webアプリケーション内でこれらの処理を実行する際は注意が必要です。必要に応じて、書き換え後のXMLやSWFをキャッシュしたり、非同期(バッチ)処理でSWFを生成したりといった方策、あるいは、より用途に見合ったswfmill以外のソフトウェアの利用も検討すると良いでしょう。

ところで、Amazon.co.jp からも案内が来てました。笑

Screenshot-24

Tagged with:
4月 23

初期投資を抑えつつサーバインフラを手軽に拡大/縮小できる、いわゆるクラウドサービスが人気みたいです。Amazon EC2 みたいなやつ。聞くところによると、ソーシャルアプリなどは、アクセス規模とかユーザの増加傾向が見積りにくいようで、そういうところで利用が進んでいるらしいです。

ところで、そういったサービスは、何もサービスを受け付ける側を作るのに使うだけでなく、(負荷試験やパフォーマンスチューニングのための)Web アクセス負荷を大量に発生させるインフラとしても使えるんでないかなあと思っていたら、やっぱりそういうモノがありました。JMeter in the Cloud という AMI (Amazon Machine Image) です。

JMeter In The Cloud – A cloud based load testing environment

元々 JMeter では、複数のホストに JMeter を入れておき、JMeter Master/Slave という構成をとることで、Master から複数の Slave に対してテストシナリオ(テストプラン)の実行を指示することができるようになっています(下記リンク参照)。ですが、上のリンクで紹介されている AMI を使うと、JMeter を使った(超高負荷を発生させる)分散負荷テスト実行環境を、Amazon EC2 上に、驚くほど簡単に(慣れれば10分もかからずに)構築できます。同時10,000接続とか、それ以上のリクエスト環境をサクッと作れちゃいます。

参考:

使い方は、上に書いた AMI 紹介ページに、PDF が置いてあるので、それを読めばわかります。とても簡単。以下、その PDF に書いてあることを試したので、そのログをそのまま紹介します。

注意

以下の手順では、簡単に膨大な量のアクセス負荷を発生させることができます。悪用厳禁はもちろんですが、たとえば、単体ホストから  JMeter  や ab などを使う程度の負荷で音を上げるような状況のサービスの負荷試験には向きません。下手に大量のトラフィックを発生させることは、第三者に迷惑をかけることもありますので、利用にはご注意ください。

前提知識

というほどではないですが、適当に端折りますので、以下の経験があったほうがいいかもしれません。

  • EC2でインスタンスを起動したり、管理コンソールをいじってみたりしたことがある
  • JMeterを使ったテストシナリオの作成&実行をやってみたことがある

準備するもの

  • AWSアカウント
  • NXクライアントソフト(後述)
  • 負荷試験対象となるサービス
  • お金(EC2でインスタンスを起動してる時間に応じてかかる。1インスタンスあたり0.085USD~/h)

概要

JMeter in the Cloud は、ドイツのIT Beratung Jörg KalsbachというITコンサルティング会社の方が公開している AMI です。このイメージの正体は JMeter In The Cloud というデスクトップアプリケーションがインストールされた Ubuntu (8.10) です。このイメージを使うことで JMeter を分散環境で利用しようというわけですが、全体の流れは以下のようになります。

  1. 上記イメージを EC2 で起動します
  2. 起動したホストに、この後紹介する NX クライアントソフトで接続すると、リモートで X Window System のデスクトップ環境が利用できます
  3. デスクトップに置かれた JMeter In The Cloud というアプリを起動し、JMeter Slave となるインスタンス数と AWS のアクセスキー&秘密鍵を指定します
  4. JMeter Slave ホストが指定数分起動し、リモート利用設定がなされた状態で JMeter GUI が起動してきます
  5. 起動した JMeter GUI でテストプランを設計し、Remote Start All などとすることで、JMeter Slave に対して一斉テストを指示します

以下、スクリーンショットぺたぺたしながら紹介します。

実行の流れ

NXクライアントソフトのインストール

NXというのは、今回初めて知ったのですが、X Window System をネットワーク越しに利用するためのテクノロジで、VNC と同じようなものだと思うのですが、比較的狭いネットワーク帯域(遅い転送速度)でも利用できるのが特徴らしいです。紹介したものの、Wikipedia に書いてあることを引用しただけで、それ以上のことはよくわかりません。冒頭紹介したリンク先にあるマニュアルで、この技術の開発元である NoMachine(イタリアの会社らしい) が紹介されています。というわけで、そこのリンク先(以下)から NX クライアントソフトをダウンロードして、インストールします。

NX Download – NoMachine

Screenshot-8

NX Client Products というところから、利用環境に合わせてダウンロード&インストールします。僕は Mac OS X(10.5)版と Linux(DEBパッケージ)版を試してみましたが両方問題なく使えました。

EC2でのSecurity Group設定

次に、ブラウザで AWS の管理コンソールに接続し、Security Group を作成します。Security Group というのは、複数のインスタンスの集合単位で、これを設定しておくと、グループの内外でネットワークレベルでのアクセス制御ができたりします。作成済みの Security Groups は管理コンソールの左側のメニューから一覧できます。(今回紹介している JMeter in the Cloud は US East か EU West の Region でしか使えないみたいです。できれば US West で使いたいですが、今のところ調べきれてません。。)

Screenshot-6

JMeter in the Cloud では、”All Incoming” という名前の Security Group を決め打ちで要求しているので、上の方にある “Create Security Group” で、グループ作成します。

Screenshot-7

ここでは、Descriptionは上のように書いてますが、何でもOK。

JMeter in the Cloud イメージ起動

では、JMeter Master となるメインのインスタンスを起動します。

Screenshot-3

“Launch Instance” のメニューから、Community AMIs のタブで、AMI を検索します。US East であれば ami-0cf21065、EU West であれば ami-9b9fb4ef で検索してください。見つかったイメージの右側の “Select” ボタンから起動していきます。いろいろ起動オプション選べますので変えたい場合は変えてください。適当にぽちぽち進んでいけば OK。

Screenshot-4

Screenshot-14

Screenshot-15

Security Groups は、さっき作成した All Incoming でもいいんですが、その場合、All Incoming のネットワークポリシをちょっといじってやる必要があるみたいです。そのままだと、この後の NX クライアントからの接続がうまくいきません。マニュアルには TCP 22,80,1099 と UDP 161 をあけろ、と書いてあるので、多分、これでしょう(試してない)。僕は、上の図のとおり Default を選択しました。

この後、確認画面が出て、ボタンを押すと、インスタンスが起動します。ここから時間課金です。こういうのに、未だにドキドキしてしまう。

起動したら、My Instances 一覧画面で割り当てられた FQDN 名をチェックしておきましょう。この後の接続先設定に使用します。

Screenshot-10

起動したイメージへの接続

既に説明したとおり、起動したイメージへは NX クライアントを使用します。先ほどインストールした NX Client を起動して、まずは接続(セッション)設定を作成します。

Screenshot-9

Screenshot-11

セッション名は適当です。接続先ホストには、先ほどチェックした起動済みインスタンスの FQDN 名を指定します。

Screenshot-12

このあとの画面で Finish すれば、接続先作成は完了。この設定を使って、EC2 上で起動しているリモートのインスタンスにログインします。

Screenshot-13

起動済みインスタンスは、ログインユーザ/パスワードが作成済みです。ともに jmeter と指定すればログインできます。

Screenshot-17

こんな感じで、リモートマシンのデスクトップが手元にやってきます。EC2 でデスクトップ環境を動かしたのが初めて(いつもは CLI しか使用しない)なので、これが US East で動いてるとおもうと、なぜだか感動。

JMeter In The Cloud アプリの起動

上のデスクトップに置いてあるアプリを起動すると、JMeter Slave として起動するインスタンス数と、AWS のアクセスキー/秘密鍵を入れるダイアログが表示されます。このアプリを介して、JMeter Slave インスタンスを起動する、というわけです。

Screenshot-18

ここで起動させるインスタンスは m1.small タイプ($0.085/hour)になります。Number of Instances to start は、起動するインスタンス数。10って入れたら10個起動します。課金スピードは10倍です。ちなみに、AWS key やら AWS secret key にはコピー&ペーストしたいところですが、リモート接続してるデスクトップなので、ローカル環境からはコピーしてこれません。僕は Firefox 起動して AWS アカウント管理画面に接続して、そこからこぴぺしました。なんかでクリップボード共有もできたような気がしたけど忘れた。

Screenshot-19

起動にはだいたい2分くらいかかるよ、と出ます。が、起動した数量によっては、もっとかかります。あと、先ほど AWS の管理コンソールから作成した “All Incoming” Security Group が無いと、ここでエラーが出ます。

Screenshot-21

うまく起動すれば、こんな感じに、JMeter の GUI が表示されてきます。やった!

Screenshot-22

リモートホスト(JMeter Slave)に先ほど指定した10個のホストが登録されていることもわかります。

起動後に、AWS の管理コンソールで My Instances をみると、ばっちり起動しまくっています。これらは、上で起動した JMeter を動かしている限り動きつづけます。

Screenshot-20

JMeter でテストプラン作成&実行

あとは、JMeter そのものの使い方になるので、マニュアルとか他の解説サイトを参考にしてください。以下は、僕の管理している某サーバに HTTP GET を 10 Threads, 10 Loop で発行するスレッドグループを作成して、これを Remote Start All したときの Graph Result です。10 インスタンス起動しているので、10 x 10 x 10 で 1,000 リクエストが飛んでいます。

Screenshot-23

JMeter は、テストシナリオをかなり細かく設定していけますし、乱数発生やif分岐、foreachループなどちょっとしたスクリプティングもできてしまうので便利ですね。リポート形式もいろいろあるのもありがたいです。

細かいプランはローカルマシンの GUI で作って xml 出力しておいて scp で運んでも良いと思います。ブラウザが使えるので、その辺のファイルの共有は、Dropbox など使うのもアリかも。

テストが終わったら、忘れずにインスタンスをシャットダウンしておきましょう。リモート起動した JMeter Slave は、ここで起動した JMeter GUI を終了することで、終了処理がコールされるようになっています。

まとめ

JMeter in the Cloud 便利だな!という話でした。これがパブリックイメージで無償で利用できるというのは驚きです(寄付歓迎とのこと)。いつ有償になってしまうか、突然請求書が届いたりしないか不安ですが。。

しかし、こんなかんじで、数時間負荷をかけるための利用であれば、10,000円でお釣りが来てしまうくらいなんですね。便利な時代になったものです。

(2010/05/04追記: Amazonから先月利用分の請求書が来ましたが、このために利用した分の請求額は $2.28 でした。2, 3 の負荷テストを実験してみたり、このエントリ書くために 1, 2 時間起動しっぱなしでキャプチャとったりしてましたが、概ね、こんなものですね。安い!)

Tagged with:
7月 27

先日、SwfmillRuby に hokaccha さんのブランチをマージしました。hokaccha さんのブランチでは、32bit png の image2xml に対応いただいておりましたが、これに xml2image の処理を追加実装しています。これにより、32bit png (DefineBitsLossless2 の image format=5) に暫定対応しました。

ただし、今回追加実装した xml2image は、透過色を含む PNG の扱いについて完全ではないので、あくまで暫定対応という位置づけです。32bit png を SWF 内部のビットマップに変換する際に RMagick(ImageMagick) を経由して得られる各ピクセルの情報と、Flash IDE がパブリッシュするビットマップの各ピクセルの情報とで、微妙に誤差が出てしまっており、現時点で、Flash IDE が出力するビットマップデータと完全に一致させる事ができていません。

具体的には、DefineBitsLossless2 の ARGB データから RMagick::Image の png イメージを作成する部分が怪しい感じです。確証はないのですが、どうも、SWF File Format Specification にある:

The RGB data must already be multiplied by the alpha channel value.

の “multiplied” の解釈が単なる乗算ではないみたいような気がしています(除算で逆変換しても適当な数値にならないのです)。今のところ、幾つか透過色を含む PNG で動作検証してみた限りでは、ここを逆変換する際に、RGB それぞれの値と opacity との OR を取る事で、元のイメージの再現性がある程度確認できたので、ひとまずこの方法で実装してみました。何か勘違いしている気がしないでもないのですが、、お気づきの方、コメントいただけると幸いです。

ちなみに、上記の更新以外でも、partialize や templatize の機能を追加し、partizlize や templatize において、SWF を再生成(regenerate)する際の XML 処理コストを少しでも削減するための事前処理をおこなえるように改修を続けています。これは、ちょっと複雑な SWF の動的生成/書き換え/合成をしようとすると、再生成に XML 中の ID 体系を付け替えたり、要素を入れ替えたりといった処理のコストがとても大きくなる事がわかってきたからです。詳しくドキュメントを書く時間が取れていないのですが、サンプルやソースコードコメントから意図を汲んでいただけると幸いです。(少なくとも FlashLite 1.1 の携帯サイト向けには、わりと面白い事ができるくらいのものにはなってきていると思います。)

まだ公開して間もない SwfmillRuby ですが、いつの間にか、いくつかの方面からご利用のご連絡をいただいており、とても励みになっております。ライセンス上、ご利用のご連絡は必須ではありませんが、よろしければご利用コメントやご意見などお寄せいただければとうれしいです!

Tagged with:
5月 28


2009/06/04追記: こちらのサンプルコードは、その後のバージョンアップにより動作しないものが含まれています。大きな変更点としては「テンプレート」と言葉の用法を変更し、これまで「テンプレート」と呼んでいたものを「パーツ」と呼ぶようにしています。詳細は配布ファイルに含まれるテストコードもしくは別エントリ(そのうち書くかも)をご参照ください。

先日こちらで紹介した SwfmillRuby をバージョンアップして、いろいろ便利機能を追加してみました。機能追加以前に、SWF 内のタグの対応数が絶対的に少ないのですが、基本的に SwfmillRuby が対象にしているのは FlashLite 1.1 でパブリッシュされた SWF なので、この用途に限れば、そこそこ使えるものになってきたと思います。ライセンスに変更はありません(GPL2)。無保証です。

今回追加された機能は、大きく次の3点です。

  • ムービークリップの検出と入れ替えに対応
  • 入れ替えのための事前処理として、ムービークリップをテンプレート化しておけるようにした
  • XML Parser を rexml から libxml2 に変更

上記のほか、SwfmillUtil::Swf 初期化の方法が変更されていたり、SwfmillUtil::DefineSprite というクラスが追加されていたりといった、こまごまとした修正が入っています。が、できるだけ外側からは、xml 使って云々とか、SWF のタグがほげほげということは意識しなくても良いように作っているつもりです(といっても、まだまだうまい書き方できそうなところは多いですけど)。

では、使い方は、アーカイブ中の sample を見ていただくとして、以下、それぞれ、日本語で解説していきます。

ムービークリップの検出と入れ替えに対応

Swf#movieclips により、SWF 内のムービークリップのリストが取得できるようになりました。SWF 内部で採番されているID => SwfmillUtil::DefineSprite のハッシュの配列が返ります。

これを使って、以下のような形で片方の SWF のムービークリップを、もう片方の SWF のムービークリップと差し替える、というようなことができます。

require '../lib/swfmill_util'
require 'pp'

################################################################################
# test to replace movieclip

# initialize
swf = SwfmillUtil::Swf.parseSwf(File.open("data/sample_original.swf").read)
swf2 = SwfmillUtil::Swf.parseSwf(File.open("data/sample_original2.swf").read)

# check included movieclips (object_id => SwfmillUtil::Swf::DefineSprite)
pp swf.movieclips.keys #=> ["8", "5"]
pp swf2.movieclips.keys #=> ["6", "3"]

# check included movieclip_ids by instance_name
pp swf.movieclip_ids_named("animation") #=> ["5"]
pp swf2.movieclip_ids_named("animation") #=> ["6"]

# replace movieclip
swf.movieclips["5"] = swf2.movieclips["6"]

# write swf replaced movieclip
swf.write("data/replaced_mc.swf")

上の例では、まず、Swf#movieclips により、ふたつの SWF に含まれるムービークリップの ID 体系を確認しています。ムービークリップの ID を確認する際は、実用上は、そのうしろの行にあるような、Swf#movieclip_ids_named が便利かもしれません。これにより、ステージ上に置かれる際に付与されたインスタンス名を指定し、対象のムービークリップの ID が確認できます。

実際の入れ替えは、上のように、ハッシュを操作するような形式でおこなえます。ムービークリップは、内部で各種形状(シェイプ)や画像(ビットマップ)、テキスト情報などを参照していますが、入れ替え自体は、上のようなハッシュへの代入操作一発で、参照関係にあるリソースを丸ごと入れ替える事ができます。また、このとき、単純に上書きしてしまうと、内部で使用している ID が重複してしまうなど、ID 体系が狂ってしまうことになるので、Swf#write (のなかで呼ばれる Swf#regenerate) したタイミングで、よしなに ID の体系を調整(adjust)する処理が走るようになっています。

入れ替えのための事前処理として、ムービークリップをテンプレートパーツ化しておけるようにした

これは、FlashLite コンテンツの動的生成サイトを作ろうとした際、実用上必要になる事が多いので、ちょっと強引に作ってみた機能です。実際に、前節のようにムービークリップの入れ替えをおこなうと、内部的には SWF を XML に戻し、XML を書き換えて、XML を SWF に戻す、ということをやることになるため、Swfmill プロセスの起動コストがかさんでしまいます。また、ムービークリップの入れ替えでは、関連するリソースも一気に処理対象になるため、前節最後で書いたような、入れ替え後におこなう ID 体系の調整コストも無視できなくなってきてしまいます。

そこで、あらかじめ、入れ替え対象となる(元の) SWF と、そこに差し込むムービークリップをあらかじめ調査しておき、差し込みをおこなうムービークリップをテンプレートパーツ化しておくことを考えてみました。

以下は、対象の SWF を調査し、片方の SWF に含まれるムービークリップをテンプレートパーツとして保存しておく際のコードサンプルです。

require '../lib/swfmill_util'
require 'pp'

################################################################################
# test to templatize movieclip                                                                                                                              

# initialize
swf = SwfmillUtil::Swf.parseSwf(File.open("data/sample_original.swf").read)
swf2 = SwfmillUtil::Swf.parseSwf(File.open("data/sample_original2.swf").read)

# check included movieclips (object_id => SwfmillUtil::Swf::DefineSprite)
pp swf.movieclips.keys #=> ["8", "5"]
pp swf2.movieclips.keys #=> ["6", "3"]

# check included movieclip_ids by instance_name
pp swf.movieclip_ids_named("animation") #=> ["5"]
pp swf2.movieclip_ids_named("animation") #=> ["6"]

# templatize movieclip specifying the mapping of object_ids
#  and available, unused object_id (if you want to adjust object_ids)
File.open("data/animation_template.xml", "w") do |f|
  f.puts swf2.movieclips["6"].templatize(true, 6, 5, 1000)
end

上の通り、DefineSprite#templatize は 4 つの引数をとります。これらは手前から:

  • あらかじめ ID の調整をおこなうか(true/false)
  • 対象のムービークリップに付与されている ID
  • 対象のムービークリップを、SWF に入れ込む際の ID
  • テンプレート化の際におこなう ID の再編成時に使用できる、未使用の ID の最小値

を表しています。真ん中のふたつは、上記の前半で得られるような、SWF の調査結果をもとに指定します。最後の引数は、明らかに重複の無い大きめの値をバッファを持って指定しておくと良いと思います。なお、引数を何も指定しなければ、テンプレート化の際に ID の調整はおこないませんので、regenerate の際に調整する必要が出てきます。

なお、ここでは、テンプレート化されたムービークリップは XML 化してファイルで永続化していますが、DB に突っ込んだり、容量が許すなら memcache などのキャッシュに載せておいたりという手を使っても良いと思います。

こんなかんじで作成したテンプレートを、以下のようなコードで差し込みます。ここでは、あらかじめ Swfmill#swf2xml した xml から初期化することで、元の SWF を読み込む際に Swfmill 起動が必要ないようにしています。

require '../lib/swfmill_util'
require 'pp'

#################################################################################
# test to regenerate swf using template movieclip

# initialize original swf by preserved xml generated by Swfmill::swf2xml.
# avoid analysing swf's structure using "template_mode".
swf = SwfmillUtil::Swf.parseXml(File.open("data/sample_template.xml").read, true)

# initialize template movieclip by preserved xml generated by Swf#templatize
# avoid analysing swf's structure using "template_mode".
animation = SwfmillUtil::DefineSprite.parseXml(File.open("data/animation_template.xml").read, true)

# check a target object_id
pp swf.movieclip_ids_named("animation") #=> ["5"]

# change movieclip
swf.movieclips["5"] = animation

# write swf changed movieclip.
# avoid adjusting object_id using "adjustment=false"
swf.write("data/regenerated.swf", false)

初期化時の最後の引数は、テンプレートモード (template_mode) を表しています。テンプレートモードで Swf を初期化すると、初期化時に SWF の構成チェック処理がおこなわれません(つまり、Swf#images や Swf#movieclips で、現在の構成をダンプすることができません)。これにより、初期化の際の処理ステップを、ある程度スキップする事ができます。テンプレートモードは、templatize により、テンプレートがあらかじめ作ってある&元の SWF が調査済みで、入れ替えをおこなう相手もわかっているというときに限り、使用される事を想定しています。

また、Swf#write の最後の引数で指定している論理値は、入れ替え時の ID 調整(adjustment)要否を表しています。templatize の際に adjustment=true とし、入れ替え後の ID 調整を先におこなってあれば、ここで adjustment=false とすることで、さらに Swf 生成前のコストを削減する事ができます。

このあたり、冒頭にも書きましたが、ちょっと強引な仕上がりになってますので、ぱっと見た感じ、何が起こるのかわかりにくいのが難点です。もっと使いやすいインタフェースを考えてますが、今のところはこんな感じでご容赦ください。

XML Parser を rexml から libxml2 に変更

オモテからはほとんど意識する必要のない変更点なのですが、これにより今回追加された機能の処理部分のパフォーマンスが劇的(概ね1桁以上、場合によっては2桁)に上がりました。libxml-ruby は Ruby の標準添付ではないので、別途インストールが必要になってしまうのが懸念点だったのですが、実用上こちらの方が望ましいと思いましたので、思い切って全体を書き換えることにしたのでした。

この乗り換えのきっかけは、このライブラリは、内部では XML 処理がごりごりおこなわれているのですが、rexml を使っていたときは、とくにムービークリップ周りの解析や、ムービークリップ入れ替えの際におこなわれる XPath 検索にかなりのコストがかかっていたことがわかった、ということでした。たとえば、50KB のムービークリップが 30 件くらい入った SWF を解析するのに、デスクトップ環境で5-6分かかり、テンプレートを使用したムービークリップの入れ替えに3-4秒かかるといった具合でした。(そもそもの書き方がアレだった部分は重々ありますが。)

解析処理をおこなう際の変数スコープを調整したり、メソッド化してあったところをブロック付きの Hash に書き換えたりすることでソコソコ改善はしたのですが、結局は rexml の XPath 検索が一番のボトルネックになっていたようで、libxml2 利用に置き換えたのが一番効果的だったようです。

libxml2 の利用により、これまで2-3分かかっていた解析処理は3-4秒、入れ替え処理も0.2-0.3秒程度まで短縮できました。同時大量アクセスのあるサイトには厳しいかもしれませんが、他の面でもいろいろ工夫をいれる余地のある環境/状況でしたら、そこそこ実用に耐え得るのかな、と思います。

以上、今回の大きな変更点を紹介しました。まだまだ不具合等内在しているかもですが、ご利用いただけましたら感想など聞かせていただけるとうれしいです。

Tagged with: