今回は、Flashのキャッシュ対策のTipsと、それを一歩踏み込んだものを紹介します。
一歩踏み込んだ・・・ってのをカンタンに説明しておくと、
「キャッシュ対策の定番となっている手法を使うと、クエリのせいでログ解析が困難！」
というのを解決するものです。

では早速。

まずは、rss的なXMLを読み込む場合を考えて見ましょう。

FlashのHelpにも書いていますが、基本的には下記のようなコードでXMLを取得することができます。

var rssXml:XML = new XML();
rssXml.ignoreWhite = true;
rssXml.load("http://hoge.com/rss.xml");

しかし、これだけでは問題があります。
ブラウザによって挙動は違いますが、物によってはキャッシュが強く、ブラウザの更新ボタンなどで更新しただけではXMLの内容がリフレッシュされないことがあります。
これでは非常にマズイです。最新の情報を表示することができません。

そこで、定番となるTipsが下記です。

var rssXml:XML = new XML();
rssXml.ignoreWhite = true;
rssXml.load("http://hoge.com/rss.xml?"+Math.floor(Math.random()*1000));

どこが変わったかというと、読み込む対象のXMLのURLが
“http://hoge.com/rss.xml?”+Math.floor(Math.random()*1000)となっています。

これは、“http://hoge.com/rss.xml”に、GET方式でクエリとして乱数（ランダムな数字）をくっつける事で、ブラウザに「前回とは違うファイル（リクエスト）である」と認識させることにより、しっかり新しいファイルを読み込ませるというものです。

Math.floor(Math.random()*1000)というのは、言葉で書くと
括弧の中の数字の小数点以下を切り捨て！（ランダムな0～1までの小数点以下ありの数字をつくります！それを1000倍！）ということです。

結果、0～1000までの数字（正確には0 <= n < 1000です）を通常のURLにクエリとして追加することとなります。
つまり、“http://hoge.com/rss.xml?123″というURLをリクエストすることになります。

ひとまずは、これにより当初の問題は解決します。
（もちろん、1/1000程度の確率でクエリもかぶりますが・・・一般的には無視することが多いみたいです。）

*追記　乱数ではなく、 “?”+new Date().getTime(); とすれば読み込み時刻をクエリとするので、上記問題は回避しやすくなります。ただ、ログのファイル名がほぼ無限になりますが・・・

・・・しかし！ここで新たな問題が発生します。
リクエストするURLが

“http://hoge.com/rss.xml?123″
“http://hoge.com/rss.xml?321″
“http://hoge.com/rss.xml?456″

といったように、リクエストするURLが毎回違うわけですからサーバーのログにも当然そのようにのこります。

見慣れたApacheのログであれば、
hoge.com – - [02/Dec/2008:22:46:49 +0900] “GET /rss.xml?523 HTTP/1.1″ 200 1272
hoge.com – - [02/Dec/2008:22:46:51 +0900] “GET /rss.xml?778 HTTP/1.1″ 200 1272
hoge.com – - [02/Dec/2008:22:46:53 +0900] “GET /rss.xml?515 HTTP/1.1″ 200 1272といった感じで残ってしまいます。

これでは、ログ解析が大変煩雑になります。
rss.xmlについているクエリ自体はまったく意味を持ちません。

ですので解析時にクエリを無視しなければなりませんが、その場合は
「rss.xmlのクエリだけ無視する」
という設定にしなければ、意味を持つクエリまで無視されるような状況が想定されます。

これがカンタンにできるログ解析ソフトであれば問題ないでしょうが、その作業が必要なことを明示しておかなければログ解析する人がとっても困ります。

そこで、クエリを使わずにキャッシュが強いブラウザでも大丈夫な読み込み方法が下記です。
実装する際のコードなども含まれた状態にしています。

System.useCodepage = true;//XMLがShift_Jisの場合に必要
var rssXml:XML = new XML();//XMLを作成
rssXml.ignoreWhite = true;//お約束
var result_lv:LoadVars = new LoadVars();//sendAndLoadで読み込むので、結果格納用のLoadVars
result_lv.onLoad = function(success:Boolean) {//読み込み完了時動作
 if (success) {
  trace(unescape(this));//読み込み結果を出力ウインドウで確認。unescapeが重要です。
  rssXml.parseXML(unescape(this));//読み込んだ結果をXMLにパース。unescapeが重要です。
  txt.text = rssXml.firstChild.firstChild.firstChild.firstChild.nodeValue;//ノードの値を表示したり格納したり。
 } else {
  trace("Error connecting to server.");//読み込み失敗。
 }
}
 
var send_lv:LoadVars = new LoadVars();//読み込みLoadVars
send_lv.id = Math.floor(Math.random()*1000);//上記に、POST用の乱数くっつけます。
send_lv.sendAndLoad("http://hoge.com/rss.xml",result_lv,"POST");//POSTで読み込みます。

何をしているかと言うと・・・

• 用意されたXMLのload関数を使わずに、外部プログラムと通信するLoadVarsのsendAndLoad関数を用いる
• POSTメソッドでXMLファイルにアクセスする
• さらにPOSTに乱数を仕込む事によって新しいリクエストであることを強調。
• 上記で得られるのは、新しいXMLの内容であるが”テキスト”として読み込まれる
• そこでXML.parseXML()関数を使い、テキストをXMLにパースする

という方法を取っています。
これにより、クエリを残さずに最新ファイルを表示することができます。

ただ・・・当然ですが
hoge.com – - [02/Dec/2008:22:46:33 +0900] “POST /rss.xml HTTP/1.1″ 200 1272
というように、POSTでの要求というログが残ります。

また、サーバー環境やログ解析環境によっては期待した効果が得られないこともあるかもしれません。
結局、ログ解析者との意思疎通は必要になってくるかもしれません。

以上、意外とググっても見つからない問題だったので自分のやり方を書いてみました。
ほかにもやり方があるかも知れません。いい方法があれば、ぜひ教えてください！！

みなさまおなじみの、「知ったかFlash」のお時間です。

今回は、Flashを使う事例の一つとして、ブログパーツを説明したいと思います。

ちなみに最近のブログパーツブームはなかなかのもので、企業のキャンペーンサイトにいけばかなりの確率で配布されており、ブログパーツポータルなども更新材料に困らない程の賑わいです。

ブログパーツとは

さて、ブログパーツってなんなの？と言うわけで、wiki先生に聞いてみたところ

ブログパーツとは、ブログのページ上に配置し、そのブログに関する情報などのコンテンツを表示することができる部品（パーツ）である。ブログツール、ブログアクセサリー、ブログシール、（ブログ）プラグイン、ウィジェット、ガジェットなどとも呼ばれる。
類似した機能を持つものとしてiGoogle用のウィジェットやデスクトップ向けのウィジェットがあるが、これらは利用者当人が使用する目的で製作されたものが多いのに対して、ブログパーツはサイトの管理者がブログの閲覧者へ向けて情報を提供するといったサービスをおこなっていることが多い。

引用元：wiki

となってます。

要は、ブログをより便利に、より楽しくするためのツールです。
時計・ゲーム・占い・画像・動画・音楽などなど、様々なジャンルのものが存在します。

おなじみのアクセスカウンターやアクセスランキング、一行ゲストブックなどもブログパーツといえなくはないです。
が、ブログよりも以前からある事やブログを対象に作られているわけではない事から、厳密には違うかもしれません。
しかし配布側が「ブログ専用だよ！」って言ってしまえば、それはブログパーツになるでしょう。
まあ、曖昧って事なのであまり気にしないのがいいかと思います。道具は使いようです。

では、実際にどんなものがあるのでしょうか？

ブログパーツ参考　【時計型】

※この時計の時刻は、閲覧しているパソコンのものであり、必ずしも正確な時間とは限りません

ブログパーツで懸賞ゲット！ブログパーツの新しいカタチ FirstBuzz

ひとまずは、シンプルな時計型のブログパーツを見てみましょう。
ちなみに右二つは僕が制作したものです。
やはりブログに一個は欲しいって人が多いみたいで、定番で根強い人気を誇るジャンルです。
故に数も多く、競争率が高い感じです。

内容としては、Flashで作った時計です。
ほとんどが、表示しているユーザーのPCに設定された時間を表示しています。
なのでユーザーのPCの時間がずれていればもちろんずれます。
正しい時間を表示する事も可能なのですが、その場合は正しい時間をサーバーに聞きに行くという行程が増えるので、
多数配布されサイトとは段違いなPVをたたき出すブログパーツにおいては、
単純でも一つサーバー側処理・通信が増えるだけでコストが跳ね上がります。
コストといっても開発コスト自体はこの程度のプログラムならばそこまで増えませんが、
サーバー側の処理、サーバーとの通信量がブログパーツの表示分だけ増えるので、
それに耐えうるサーバースペックと回線帯域確保に多大なコストがかかる事になります。

ちなみにブログパーツのPVですが、ちょっと人気があるものですと簡単に1万pv/day とか10万pv/dayを越えます。
一日10万アクセス以上のサーバー側処理となると、ちょっと気軽には考えないほうがいいですよね。
特にクライアントワークともなると、安定したサービスレベルを確保しなければなりませんし。

この事も踏まえ、ブログパーツについては次のような事が言えると思います。

• 配布すると多数のブログに貼られるため、PV数が掛け算で増えていく。（各ブログのPVおよびその平均値　×　貼り付けブログ数）
• 一日のPV数が簡単に万単位になるので、ファイルサイズが大きいととんでもない転送量になる
• 上記と同じ理由で、サーバー側処理もとんでもない負荷になる

PVが稼ぎやいというのは非常に魅力的なメリットです。
ですがその反面、大きなリスクも潜んでいます。

ブログパーツを制作する際は

• 一連の総ファイルサイズ
• できるだけシンプルなシステムフロー

に気をつけなければなりません。

今回は、ひとまずこれまでとしておきます。
次回は、さらに高度なブログパーツについての説明をしたいと思います。
最近人気の、「フロートタイプ」とよばれるようなブログ全体に覆いかぶさったり
ブログ内を自由に動き回ったりするようなものも説明しようかと思います。

あ、最後に宣伝宣伝。
会社でこんなサービスやってます。
ブログパーツを貼るだけで、懸賞・プレゼントがもらえるサービス　 FirstBuzz（ファーストバズ）
ブログパーツに興味がある方は、貼り付けてみてはいかがでしょうか。
ついでに懸賞も当たったりしちゃうかもしれないんで。

では、また次回！

前回に引き続き、これを知っていれば多少Flash知ってる顔ができる、「知ったかFlash」のお時間です。

前回はちょっとFlasherとデザイナーとの軋轢が垣間見えるような内容でしたが、
今回はプランナー・プロデューサー・ディレクター　vs　Flasher　な内容です。

Flashだけで、できる事とできない事

Flashは素晴らしいツールです。
アニメーションもできるし、サーバーサイドプログラム（cgiやphp）との連携も得意です。
演算による描画もできますし、様々なクリエイティブを可能にしてくれます。

ですが、Flashも万能ではありません。Flash単独でできる事というのは限られています。
基本的にはFlashは自分の表示領域の中でしか動かないものであり、
外の領域には干渉しないのと思っていただいていいかと思います。

ここで、前提知識として知っておいて頂きたい事があります。

WEBでお目にかかる様々な技術ですが、大きく分けて
ユーザーのPC上で処理されるものとサーバー側で処理されるもの
に別れ、
FlashはユーザーのPC上で処理されるものである
という事です。
HTML、CSS、JavaScript、Ajaxなどは前者、
CGI、PHP、Ruby、Pythonなどは後者です。

では、Flash単独でできる事とできない事を分けていきましょう。
できない事については、僕の場合ならこうするっていう解決策の例を提示してみます。
例としては、ノリノリなクライアントorプロデューサー相手の、通販ありのサイトを思い浮かべてください。

ズバーンとこの画像とコピーが入ってきてさ、そこでブワワァーーって光の玉とかでちゃって、ドーンとロゴ+主力商品がでてくるのよ！！

可能です。

PhotoShopやIllustrator、FireWorks（Flashだけでもできますが左記を使うのが一般的）で画像、ベクターデータを用意し、Flash上でフレームアニメーション、ActionScriptを駆使すれば可能です。
もちろん、表現に凝るのであれば相応の労力を伴います。

でさ、ロゴと商品でたらグワッって枠がひろがってロゴと商品も飛んでって、そこから商品紹介のページがでてくるとかどう！？

不可能です。

といっても、その言葉の通りの事をすればですが。
Flashはあくまで独自の描画エンジンに従って動作しますので、完全なWEBページレンダリング（描画）する事はできません。
なので、WEBページをFlash内で描画することはできません。（HTMLには対応していますが、WEBページという程の物を描画する例はあまりありません。）

解決策
WEBページのキャプチャ画像をアニメーションし、アニメーションが終わった時点でページ遷移をすることで同様に見せる事は可能です。画像を駆使すれば結構なんとでもなります。

でさ、商品が立体的にぐるぐるまわったり、カテゴリ別に整列できたりしてさ、サクサク欲しいもの探せちゃうのよ！

可能です。・・・が、一応可能、というレベルです。

というのも、Flash単独で行うのが効率的ではないからです。
立体的にぐるぐるまわったり・・・というのはFlashが得意とするところです。
商品が気持ちのいい動きで並び変わったりするのもFlashの得意なところでしょう。
しかし、整列させるためのカテゴリ分けや探すための検索については、Flash単独でも可能なのですが、
データベースやPHPを併用したほうがぐっと効率がいいかと思われます。
これについては、商品の更新・管理なども関ってくるからなのですが。
更新頻度も低く、商品数も本当に大したことない！という場合はFlash単独でも問題ないと思います。
しかし、頻繁に更新・追加・削除があり、商品数もそれなりの数になってきた場合は、
それらの情報をFlash内に記述しなおし、パブリッシュ（swf化）する作業が必要になってきます。
これは非常に非効率であり、ミスも起こりやすくなります。
与件をしっかり整理し、適切な判断が必要になります。

でさ、気に入った商品を買い物カゴにドラッグ＆ドロップでポイポイできて、ドーンと一括購入できちゃうんよ！

もちろん不可能です。

買い物カゴにドラッグ＆ドロップでポイポイはできます。
が、一括購入するためには決済システムと連携する事が必須です。
FlashはユーザーのPC上で処理を行うものですので、サーバーサイドにアクセスするためにはCGIやPHPなどの力を借りなければなりません。
ちなみにFlash単独では、サーバー上の単純なテキストファイルの編集もできません。

解決策
決済システムを用意し、Flashと連携させるフローを構築しましょう。
システム側と綿密な打ち合わせを行い、Flashで使用する事を前提に
システムを構築・カスタマイズして実現させます。

でさ、付加要素として自分のアバター持てたり、時間とか天気表示させたりしちゃってさ！

半分可能です。

まずアバターですが、これはFlash内に用意された数種類のアバターを組み合わせて選択・表示させることができます。
で、ここで問題になるのが次回訪問時です。
前回つくったのが維持されてなければ意味がありません。
このサイトがSNSのようなユーザー間コミュニケーションがないのであれば、
Flashに用意されているSharedObjectという物を使えば次回訪問時も同じアバターを表示できます。

このSharedObjectと言うものですが、ブラウザについているCookieという物のFlash版と考えてください。
Flash専用の記憶領域をユーザーのPC上に設けるものです。
これがなかなかに便利で、ゲームのセーブデータや、サイトへの訪問回数などを記録できたりするわけです。
しかし、ユーザーのPC上にしかないため、当然他のユーザーからは見えません。
アバターを他のユーザーにも公開するためには、サーバーサイドにアバター情報を保存するしかありません。

時間についてですが、ユーザーのPCに設定された時刻を表示するのであればなんら問題ありません。
しかし決済システムの営業時間などと絡んだり、全ユーザーが同時間帯でないとマズイような場合は、
サーバーサイドから正確な時刻を取得させる必要があります。

天気についてですが、Flash単体では完全に不可能です。
天気情報をサーバー上に更新してくれるようなサービスを用意するか、天気情報を提供しているAPIなどを使うしかありません。
ちなみに天気情報は、商用利用だと有料なものしかないと思われます。

解決策
サイトの性質、目的等から機能に優先順位を付けていき、労力・費用に見合わないものは削るように調整します。
これについては、クライアントやプロデューサーと綿密に打ち合わせる必要があります。

というわけで、書いてて誰が読むんだというくらい長ったらしくなってしまいましたが、
案件受注時には本当によくある話です。
できるだろって思って軽返事をし、自社に持ち帰ってえらいこっちゃなんて笑えません。
とかくシステム構築はお金も時間がかかります。
これはシステムが必要だ！というのを嗅ぎ分ける嗅覚は、本当に大事です。

では、やっとの思いでまとめです。

・Flashはサーバーサイドができないので、システムが絡むと当然システム人員が必要だよ
・両者の連携は実装もデバッグも時間かかるよ
・結構クリエイティブ合気道で返せる事も多いよ
・そのために相手の目的を汲み取り、代案、すり替え案を提案できる知識は大事だよ

ってお話でした。

ぶっちゃけ、駄エントリな気がしてきました。

次回は・・・・
「ちょっとまった、ＳｈａｒｅｄＯｂｊｅｃｔって便利だけど、本当に大丈夫！？」

で行こうかなと思ってます。
変わるかもしれません。すいません。

本当にありがとうございました。

なにを書こうかなーと考えてたんですが、意外とベタなFLASH技術について書かれているブログって少ないんじゃないかなーと思ったんですよ。
なんで、Flashを触れない、ちょっとしか触ったことがない、または触る必要も無いけど知っておく必要がある人にもタメになる、
「これくらい知っといたら、ちょっとFlash知ってるぜ的な顔ができる」的な記事を書いていこうかと思います。
いわゆる、コツってやつですかね。

じゃあ第一回の今回は・・・

ベクターか、ビットマップか　それが問題だ
って事にしときます。

Flashでグラフィック要素を扱う場合、イラストレーターやファイヤーワークス、Flashで図形ツールやパスツールなどで作った、ベクター要素と、イラストレーターやフォトショップ、ファイヤーワークスなどで用意したビットマップ要素（つまり画像。ラスタデータとも呼びますね）のどちらかを扱うことになります。

この二つは当然の事ながら別々の長所と短所を持っていて、対極に位置する関係です。
この二つを、しっかりと効果的に使いこなせるかどうかというのが、基本ですがとても重要になります。
このエントリは、是非デザイナーさんにも読んでほしいです。
よく、デザイナーさんとこのあたりで揉める事があるので・・・・。

で、この二つ根本的に何が違うの？って言うのを簡単に説明するとですね・・・

ベクターデータとは、直線、曲線、色、位置などを数値化した情報データのことです。
Flashでは数値化された情報データを、独自の描画エンジンにて描画し、グラフィックにします。

また、ビットマップデータ（ラスタデータ）とは、1ドットにひとつづつの色を置いた、点打ち情報のデータ
です。*1Flashでは、そのままいわれた通り表示する感じですかね。

*1　画像のエンコード方式によって、もちろん差異があります。
GIFなんかは色情報を横一列に記述するので、横一列が同じ色の場合、非常に軽くなります。
ためしに、フォトショップなんかで300pix*300pixあたりで縦グラデーションと横グラデーションでGIF書き出ししてみてください。
容量に大分差があります。豆知識豆知識ｗ

で、じゃあ具体的にどういう差が生まれるの？ってとこですが、
それぞれ長所短所があるわけです。
まず長所から見てみましょう。

■ベクター
• 点と点を結び、それに色を追加した情報の塊なので、超複雑な図形で無い限り、データ量が少ない（容量が少ない）*2
• Flash上でそのまま変形や色変更ができるなど、編集が容易
• 拡大、縮小などをしても、画質が乱れるようなことがない。

■ビットマップ
• ベクターでは表現できないような、高度な表現が可能。（フォトショップのフィルタ機能など）
• ベクターにくらべて、描画処理が劇的に少ない*2
• イラストレーターやフォトショップでのデザインデータからFlashに取り込む際に、変化なく取り込める（環境依存が少ない）

などが挙げられるかと思います。

で、短所ですが・・・

■ベクター
• 描画に演算処理が必要なため、複雑な図形になると、処理が重くなる。
• 基本的には点、線、色で描画するため、表現に限界がある。
• イラストレーターなどからFlashに取り込む際、データが変化する（ぶっ壊れる！）事がある。

■ビットマップ
• 凝った画像、でかい画像、色数が多い画像、アルファ（透明）を使った画像などは、ファイル容量がクソでかい
• 修正があった場合、非常に面倒（フォトショなどで元データ修正して書き出し、そして取り込み）

見たいな感じですかねー。

なので、ベクターかビットマップかを判断するには、
表示したいグラフィック要素が

• ビットマップでないと表現不可能なのかどうか？
• ベクターで表現して、処理の重さは許容範囲内か？
• 編集の容易性は、どれほど必要か？

などを考慮する必要があります。

つまり、グラフィックの再現性と処理パフォーマンス、そして編集の容易さを天秤にかけます。
グラフィック命の表現であれば、多少処理パフォーマンスに影響を与えようとも、文字や図形はベクターでやった方がキレイです。
逆に動きの表現重視であれば、要素を極力ビットマップにして行き、許容できる処理パフォーマンスまで抑えます。
単純に最終アウトプットの事だけ考えるのならば再現性と処理パフォーマンスだけ見ればいいのですが、
編集の容易さを無視すると、後で泣きます・・・・

というわけで、両方の長所・短所がわかり、使いどころもなんとなく見えてきたかと思います。
長かったですが、ココから本題。
それぞれのデータを使う上でのコツ、注意点です。

ベクター

とにかく、パスを最小限に抑える。

とくにイラストなどでよくありますが、スキャンした画像データなどをライブトレースした場合などは、イラストレーター上でスムーズツールなどを使って極力パスの数を減らします。
イラストレーターであれば、「パスの合流」や「透明部分の分割・統合」などを駆使すれば、よりパスを減らす事ができます。塗りの下側にある、表示されないパスなどはこの方法で消してください。

無駄なグラデーションを使わない。

グラデーションもかなりの描画処理を必要とします。小さいところや、単色でもまかなえる部分はグラデーションを取り払いましょう。どうしても必要な場合は、ビットマップと十分な検討をしてください。

ビットマップ

適切なサイズで

ビットマップはその性質上、拡大すると画質が乱れます。だからといって、「大は小を兼ねる」と大きく書き出して取り込むような事をしてしまうと、ファイルサイズが大変です。最適なサイズで書き出しましょう。

適切な形式で

画像にはJPG,GIF,PNGなどなど色んな形式があります。その都度に合わせた形式で書き出してください。具体的には・・・
・色数が少なく、簡単な図形的なものであれば容量が少ないGIFで。
・写真などの色数が多いデータはJPGで。
・アルファ（透明）が必要な場合は、PNGで。
となりますが、ここで注目！
最後のPNGですが、イラレ・フォトショで作ると、PNG-24で書き出さなければ透明部分のアンチエイリアスが効かないため、やむを得ずPNG-24で書き出します。
が！！ファイヤーワークスにてPNG-8で書き出すと、なんとアンチエイリアスが効くじゃないですか！これで、容量かなり抑えれます。
イラレやフォトショで作ってしまっていても、個別にファイヤーワークスに持っていって書き出すくらいの価値はあります。

とまあ、少ないですがこんな所じゃないでしょうか。

ちなみに、上記の特性のいいとこ取りな方法もあることはあります。
たとえば、ベクターデータで作っておいて編集の容易さを確保しつつ、表示する際にはActionSctiptで
cacheAsBitmap = true;
を設定することにより、ベクターデータをビットマップデータとして扱う事もできます。
ただ、cacheAsBitmapは拡大・縮小・回転の際に再描画されてしまうため、それらの動きをする要素には使用禁止です！！余計重くなります。
なので、BitmapData.draw()などでムービークリップ自体を一旦ビットマップに描画してしまう、などの扱いがいいかと思います。

こちらの詳しいやり方は、機会・要望があれば書いてみようかと思います。

本日は、ひとまずこれまで！
またよろしくお願いいたします～～