Home

スーパー肩パッドの大開発者養成ブログ

「Yahoo! 3.11、検索は応援になる。」の検索ビッグデータのビジュアライザを作りました

  • 2014-03-11 (火)
  • ̃Gg[͂ĂȃubN}[Nɒlj

3.11、検索は応援になる。 | Help Tohoku. Search “3.11”. – Yahoo!検索 (2014年3月31日まで公開)

今日、Yahoo!検索で「3.11」というキーワードで 検索された方おひとりにつき10円が、 Yahoo!検索から公益財団法人東日本大震災復興支援財団の「一般寄附金」へ 寄付されます。

とても意義のあるプロジェクトのビジュアライザをバスキュールがお手伝いさせていただきました。

震災前と震災後、そして現在に至るまでのYahoo!で検索された震災に関わるキーワードを可視化しています。

いくらか知見を得ましたので、ここでは

  • ビジュアライズの知見
  • ビジュアライズを実現するための高速プロトタイピング

という2点を書こうと思います。

ビジュアライズの軸のすえ方

データのどの特徴をx軸とy軸に置くのか?といった軸のすえ方が非常に重要でした。

今回のデータの大きな特徴は以下です。

  • 検索ワードの検索回数、順位
  • 時系列で検索ワードが増えたり減ったりする

いくらかプロトタイプを作り、試したが…

  • 見栄えはとてもいいが、データをわりと無視しているもの
  • データの大小を反映しているが、見栄えが悪いもの
  • データの順位を正確に表しているが、読みにくいもの

など、なかなかバランスが取れないものばかりでした。

もうすこし具体的に言うと

  • 色はワードごとに変えるのか?透明度は?
  • 出現したら場所は固定か?流動するか?
  • 大小をフォントサイズで表現するか?文字の領域の面積で表現するか?

などです。ちなみにフォントサイズで表現したほうが面積よりも正確に見えます。

これらの他に、ニュースマップボロノイ図なども検討しましたが、やはりしっくりきません。

Box2dで中央に配置

  • データの大小を美しく配置する
  • 日毎のデータの推移がわかりやすいようにする

という、二軸を重点に置きました。これが数多く試した中で、いちばんしっくり来た結果でした。

Box2dという物理演算ライブラリをつかい、画面中央に引力がある状態にし、自然と中央に集まるようにレイアウトしています。また、検索ワードの時間軸での移り変わりもわかりやすくなりました。

image

また、ずっと見ていても飽きないようにするには気持ちよいモーションだけでは持ちません。「おっ」と目を引く気持ち悪さもアクセントとして必要です。気持ちよさと気持ち悪さを絶妙のブレンドで仕上げています。

高速プロトタイピングで正解に近づく

どんなデータになるのか?どのくらいの量になるのか?どうすれば見栄えと意味を両立できるのか?

まったくの未知の課題であり、一発で正解にたどり着くことはありません。

効率よくスピーディに確かめるほかありません。

  • Flashでいろんなパターンをサクッとつくる
  • gitでいろんなバージョンを作りまくって巻き戻ったりできるようにする
  • 自分でデータを整形する
  • gruntですぐさまテストアップして確認してもらう

というサイクルを高速に回せればいい感じでした。

Flashで画面作成 + Nodeでデータ整形して、すぐに画面で確認する

Webで公開するのとあわせて、映像用素材としても書き出しが必要だったのでFlashで作っています。他の案件でCSS3 AnimationやCanvasゴリゴリしたりしてますが、やっぱりFlashだとできることが多いくて速いですね。

データ整形ですが、バスキュールでは他の案件でもビッグデータのビジュアライズをやっていますが、MySQLでデータを解析 + JSON書き出しという手段も使っていました。

が、どのようにデータを整形してどのようなJSONにすべきか?というのをサクッとやってしまわないといけなかったので、

NodeでCSVパース → ゴニョゴニョ → JSON 

としました。Nodeじゃなく、rubyでもpythonでもなんでもいいんですが、Nodeも手軽で楽ちんです。

あと、データはものすごく偏りが出る場合もあったり、震災直後はものすごく大きな数字だったりするので、対数変換などを使って慣らしていました。


こんな感じでいろいろいじくって、きれいな落とし所を探っていました。

gruntですぐさまテストアップ

を書くには長いので、Qiitaにでも投稿します!

みんなで「3.11」を検索しましょう

僕も阪神大震災を体験しています。友だちが死にました。毎年1.17になると「そいつのぶんまで生きよう」だとか「ダラダラ生きてきて、おれはそいつのぶんまで生きてないじゃないか」などという思いで心臓の下のほうが黒い煙でモヤモヤします。毎年です。

「3.11」は、とりわけ多くの感情がネットに広がっていることと思います。

自分の手で検索して、ネットの空間に存在している、誰かの何かの思いを見つけてみてはいかがでしょうか?

  • Comments (Close): 0
  • Trackbacks (Close): 0

[FlexUnit] 〜テストの拳〜 世紀末終わったけど、Flashまだ終わってないし、あべし言いたくないし、FlexUnitでテストする?

  • 2013-04-23 (火)
  • ̃Gg[͂ĂȃubN}[Nɒlj

200X年!世界はSNSの炎に包まれた!

Tweenは枯れGraphicsは裂け・・・・・・あらゆるノウハウが絶滅したかにみえた

・・・・・・だが

・・・Flashは死に絶えてはいなかった!!

別に伝承するほどでもなく、簡単だったFlexUnit

SNSの登場とスマホアプリの普及、もはやAPIを叩かない日はなくなりました。そしてAIRやゲーム用途への接近によるFlashのアプリ化が起きています。しかし、制作はいまだレガシーな根性スタイルであることが多いかと思います。

とはいえ普段の開発では「ダミーのボタンを作ってAPIとの通信をテストする」というテストもどきをやってると思います。

テスト駆動開発とはそれを体系立ててやるだけです。ルールがあるぶん、むしろ楽だったりします。

ながれ

  1. testフォルダをつくる
  2. テストコードを書く
  3. Run/Debug Configurations(実行の構成)にてテストランナーの設定
  4. テストを走らせる!

うん、むずかしくない!

あべしと言わせるテスト(奥義)を書こう!

 [Test]
 public function 絶叫テスト():void {
    Assert.assertEquals('あべし', zako.断末魔());
 }

これだけ!簡単!Functionの上に[Test]って書くだけでテストコード! 伝承しやす!
でも!読みにくい!なにこれ!

さっそくテスト(奥義)も覚えたし、もうちょっと読みやすいテスト(奥義)を書こう

さっきのテスト(奥義)を日本語化すると

「’あべし’はzako.断末魔()を実行したときに期待される値である」

と、なんだかとても読みにくい。

なので、hamcrestというライブラリを使うと↓みたいな書き方になる。

assertThat(zako.断末魔(), equalTo(‘あべし’))

「zakoが断末魔()すると、’あべし’になる」

となり、こっちのほうが読みやすいね!

ちなみに、テスト(奥義)は最初に一発目は必ず失敗するのがルールなので、シンとかサウザーのことを思い出してやってください。

非同期のテスト(奥義)をしよう!

あんまり覚えたくないのでひとつだけ覚えよう!

image

 [Test(async, timeout='1000', description='お前はもう死んでいる')]
 public function 非同期のテスト():void
 {
      var context:Object = {};
      var you:Function = Async.asyncHandler(
          this, function (event:FlexEvent, ctx:Object):void {
               assertThat(context.result, equalTo('死んでいる'))
          }, 1000);

      var timer:Timer = new Timer(500, 1);
      timer.addEventListener(TimerEvent.TIMER, function(e:*):void{
          contenxt.result = '死んでいる'
          you();
      });
      timer.start();
 }
  1. metaデータに[Test(async)]を入れる (これは奥義じゃない)
  2. Async.asyncHandlerで待ち状態にする (秘孔をつく)
  3. 非同期が終わったら、Async.asyncHandlerで作った非同期待ち関数を叩く (決め台詞をいう)
  4. おわり (死んでいる)

非同期なときのassertcontextみたいなオブジェクトを作って受け渡しするいい感じにテストできるかと思います。

これ以外にも非同期のメソッド(経絡秘孔)はあるみたいだけど、とりあえずこれ(奥義)を一つ覚えたらいいんじゃないかな。

以下、IntelliJ IDEA(すごい伝承者)でテストを走らせるやりかた

FlashBuilder(アミバ)でもだいたい同じかと思われます。IntelliJ IDEAもFlashBuilderもFlexUnit(奥義)を簡単に使えるようになってるので、この上なく楽です。

FlashDevelop派のひとはこちらの記事がよさげ

–ここからIDEAでの設定–

  1. Testディレクトリの設定
  2. Run/Debug Configuration (実行の構成)
  3. できたら実行ボタンを押す

1.Testディレクトリの設定

testディレクトリを作る→右クリでMark as → Test Source Root

testディレクトリ

ここにテストコードを書いたクラスをほりこんでいきます

2.Run/Debug Configuration (実行の構成)

実行の構成
実行の構成の追加。FlexUnitを追加する。

testディレクトリ
FlexUnitの設定

  • All in Package → パッケージ内の[Test]が書かれてるやつを全部実行
  • Classかスイートの実行
  • メソッド単位で実行

普段はパッケージ単位かClass単位で設定してテストをすると、実行時間も短くて楽です。

3.できたら実行ボタンを押す!

右下にFlexUnitの実行結果が出る!ここがグリーンのバーならOK
成功

失敗すると赤になる
失敗

IDEAでのtraceのだしかた

ながれ

  1. Run/Debug Configurations → Optionsでログが出るようにする
  2. 実行をすると、ログが見れる
    • (デバッグ実行では出力されたり、されなかったりと不安定)

やりかた

Run/Debug Configurations → Optionsでログが出るようにする
config

デバッグでなく、実行をする(Shift + F10)
config

すると、エラーでテストが止まったときにもログが出る。

テストに16秒くらいかかることがある→デバッグ実行でなおる

config
さっきまで2秒前後で終了していたものが、突然16秒になることがある。

そのときはデバッグ実行をすると直る。

これで救世主になれたかな?

これだけテスト(奥義)できるようになったら、もう、まちがいなくバグはない!!

なので「バグってます」と言われたら、こう言い返そう!

image

つぎの世紀末まで、いっしょにがんばろう!

FlashでいうパブリッシュのないHTML開発で、死なないためにやっといたらいいんじゃない的なこと。〜Ctrl+Enter Again〜

  • 2012-11-05 (月)
  • ̃Gg[͂ĂȃubN}[Nɒlj

2013.4.23追記、cakefileよりgruntを使うのが正解です!

11/3のf-siteでしゃべってきました。

伝えたいことがいっっっっっっぱいあって、超かけあしになってしまったところがたくさんありました。そのうちのひとつ、htmlまわりの話をフォローします。

たぶん、このくだりを3-4分くらいでやっちゃったので、ポカーンとなってたことと思います。ほんとすみません!

あ、でもhtmlをディスってるわけじゃなく、Flash開発→HTML開発に移行するときに問題となるところはどこか?というところが焦点です。

  • 大炎上生テレビ、っていう案件でスマホhtml開発をやってたときの話です。で、そのときに感じたことを話します
  • Flasherならjsはそんなにむつかしくないです
  • asとjsの差はあれど、プログラムの書き方など基本はあまり変わらない感じです。
  • だが、しかし!Flashとjs開発の差はそこではなく、パブリッシュの有無、という点が大きいです…
  • Flashのパブリッシュがやってたこととは?
  • MacのひとはCommand + Enterに置換してください…。「Ctrl(Command) + Enter」と表記してたらあんまりキレイでなかったので…
  • いままで気にしてなかったけど、Flashが解決していたことは多かった
  • HTML開発となると変わります
  • swfなら1ファイルですんだところが、大量のimg,js,cssの対応に…
  • スマホだと、容量とHttpRequestを極力減らさないといけないのです
  • Ctrl+Enterを取り戻すためにすべきこと
  • 8月からMacに移行しました。で、9月28日が生放送本番の日だったので、2ヶ月くらいでモノが作れるようにはなった。移行は多少苦労はありますけど、慣れます
  • いまやNodeがHTML開発を支えているといっても過言ではない
  • Nodeを操るにはMacのほうがやりやすげ
  • 最近Nodeの本がでてます。買いました。めっちゃ詳しいです。
  • メソッドって書いてますが、ほんとはミックスインっていう名前があります
  • CoffeScript
  • jsのクソな部分を補ってくれます。
  • でも型指定とかはないです。
  • HaxeとかTypeScriptみたいな感じのやつです。
  • HaxeのほうがFlasherにやさしいかもしれないです。型指定もあるし、AS3まんまです。
  • でも、今後のことを考えるとCoffeeScriptかなあと思っています。js界隈でのCoffeeScript化がすごいです
  • CoffeScriptはググったらいっぱい日本語ドキュメントがあるので、詳しくはそちらで…。
  • もしくは1冊だけ本がでてます。僕も買いました
  • これがパブリッシュの代わりになるやつ
  • ファイル操作とかできます。
  • 後述するSublimeTextなんかではCommand + BでCakefileを実行できます(WebStorm系も設定すればできる)
  • なので、ショートカット一発で、コンパイル→圧縮→アップロードまでできたりします
  • WebStormはHTML開発では鉄板
  • SublimeTextも超モダンで超軽快でPythonでプラグイン書ける、ということで、ちかごろ大人気です
  • でも、Flasherにぜひとも使ってほしいのがIntelliJ IDEAです。
  • FlashDevelopが超イケてるおかげで、Windows→Macへの移行をためらうひとも多いと思いますが、IDEAがFDの代わりになってくれます
  • FlashやりつつJS書ける。IDEがひとつですむのはクソ便利!リファクタリングとかちゃんとした機能も充実しすぎで、まじ便利です。
  • あと、すんごい軽快な動作をします。Eclipseとは大違い
  • 次のバージョン(IDEA12)からはiPhoneに直接ipaを転送できるようになります。そういう対応とかもめっちゃしてくれてて、しかも安い!$199!
  • あと、IDEAはWebStorm系の最上位版で、スライドに書いてる以外にもpython, ruby, phpもかけます。Objective-Cだけ別製品です。
  • このスライド、セミナーでは飛ばしました
  • テンプレートのところ
    • Nodeのejsというテンプレートエンジンがわりと使いやすいです
    • テンプレートをつかって、画像のパスを一括変更とか、共通パーツを使い回すとか、そういうことはちゃんとしたほうがいいです
  • Require.js
  • LiveReload
  • いちおうWebStormもLiveEditという機能が10月に追加されて、似たようなことができるのですが、LiveReloadのほうが使いやすかったです
  • 個人的にもうちょっと勉強したいところ

まとめオレオレCtrl+Enterを作ったら、すこしは楽になれるんじゃないか。Flashでできたことをあきらめないで実現したら、ストレスなしにできるかと…。

HTMLやっていると、Flashという仕組みはさすがAdobeということがわかりました。

HTML、IE、Android、iOS6…。なんとかこの荒波を乗り切りたいですね。

f-siteでしゃべったAIRのところはまた今度…。

CreateJSで作ってる!ぬりぬり育成 ジェルミィ

ネットがなくて、ちゃんとデモできなくてすみませんでした!

wonderflで有名な@buccchiさんが作ったCreateJS製のmixiアプリ「ぬりぬり育成 ジェルミィ」です!

こちらからチェックしてね!

CreateJSののスライドは準備ができたらどっかにアップします。しばしお待ちを!

で、f-siteで伝えたかったことってなに?

セミナーではちゃんとまとめを言えなくてごめんなさい。いろいろあるんですが、

  • Flasherのコミュニティ力、もったいないから復活させたいなあ。みんなでてら子とかBlogとかTwitterで技術のことをしゃべりまくってwonderflで競い合ってた3年前くらいがなつかしい…。
  • この変化の大きいタイミングだからこそ、新しいところ(AIRとかHTMLとかCreateJSとかスマホとか)にチャレンジしてみるのもいいんじゃないか!?

的なことです。恥ずかしくてちゃんと言えてないこともあるけど、なんかそんなかんじです。

関係者のみなさま、会場にいらしてたみなさま。ありがとうございました。

AIRあげぽよ~!iPhone/Android両対応アプリを本格的に作ったよ!のまとめ

  • 2012-06-08 (金)
  • ̃Gg[͂ĂȃubN}[Nɒlj

Flashはオワコンですか?そんなFlashのAIRでiPhone/Android両対応アプリを作りました。

ぼくはObjective-CでもPELOというアプリを作っていたのですが、Objective-Cは難しいなあーという印象でした。

そんな折に、AIRが3にバージョンアップし、動作速度が改善されたり、ANE(AIR Native Extension)でネイティブとのやりとりができる(要するに何でもできる)ようになって、なかなかいい感じに仕上がっていると聞き、仕事で使ってみました。

まだ本格的なAIRアプリが出まわっていないこともあって、世間的にも実際どうなの?というところなので、今回ざざーっとFAQ方式で書いてみますネ!

その前になんのアプリを作ったかといいますと、スポーツ応援アプリです。ぼくの所属する会社バスキュール号が「ソーシャルスタジアムシステム(Social Stadium System)」というスポーツ観戦応援システム開発しており、その仕組みを載せたAIRアプリを先日リリースしたのでした。

とりあえず、AIRのポイントを6つ!

まずざっくり6つ挙げましょう。

  • 20~30FPSは出ます。軽快です
  • 普通に作ればアプリが落ちたりしません
  • ANEがあれば、なんでもできます
  • AppStoreの審査にちゃんと通ります
  • ハマりポイントを抑えておけば、それほどハマりません
  • Flashそのままで作れてワークフローがそんなに煩雑じゃない

思ったより全然イケてました

イメージとしてはスマホの機能(カメラやセンサーとか)も使えるFlashPlayerがそのまま入ってる感じです。

Objective-Cはデザイナーには難しいと思うし、iPhoneアプリでアニメーションしようとしても、けっきょくFlashで作ってスプライトアニメーションに変換して……、とかそんな手間があったのが夢のようです。まったく楽ちんです。

動作速度は?

  • 思ったより速くて、20~30FPSくらいは出ます。
  • 描画モードにRenderModeというものが3つあります。
    • CPUレンダリング(ふつうのFlashと同じ)
    • GPUレンダリング(GPU使う。Flashのフィルター系エフェクトが使えない)
    • Direct(Stage3D、StageVideoを使うときに使う)
  • AndroidだとCPUが速くて、iOSだとGPUが速いです。iOSでGPUだと頑張らなくても60FPS出たりします。

使用メモリは?

  • 2010年前半までのAndroidの端末では使用メモリ80MBを超えると落ちちゃうらしいですが、むちゃくちゃでかい画像を大量にロードしない限り大丈夫です。
  • 作り方や画像の大きさによるところですが、普段は20~30MBくらいに収まるかと。

容量は?

  • AndroidはSWFの容量とほとんど変わらないです。
  • というか逆に軽いくらいです。SWFだとSWFの中で透過PNGをJPG圧縮したりできるので、大量の透過PNGを用意するより、ひとつのSWFのほうがずいぶんと軽いです。
  • ただ、AIRランタイムを同梱すると7-8MB増えます
  • iOSはAIRランタイムを同梱するので7-8MB増えます

ガベコレ、メモリリーク

  • Flashと同じく、きちんとやってくれているようです。
  • Objective-Cのように、すっごい気を使う必要はありません。

アプリは落ちないか?

  • きちんと作ればまったく落ちません。
  • 今回作ったアプリがスポーツ応援アプリということで2時間ずっと立ち上げっぱなしが求められていたのですが、落ちませんでした。
  • ただ、iOSではASでエラー処理をハンドリングしないと落ちます。
  • メモリリークも、ちゃんと画像を消すとか、要らなくなったものは消すとか、そういう基本をおさえればOK

通信速度は?

  • Twitterのアイコンを10000個ほどロードするテストを行いましたが、バリバリイケてました。
    • iOSではまったく遅くない
    • Androidはちょっともたつく
    • 感じでした。Androidはネイティブでも遅いので、それのせいかもしれません。が、特に落ちたりメモリリークしたりもまったくなく完璧でした

AIRで特別おぼえないといけないことは?

  • AIRじゃないけど、スマホアプリ制作に必須な知識と手間がいります。
    • 証明書・プロビジョニングファイルなど
  • Objective-C / javaはまったく覚える必要はないです。
  • Flashと違い、以下のポイントを抑えておけばよいでしょう。
    • アプリケーションの起動と終了
    • ローカルファイルの読み書き

ANEって難しい?

開発環境は?Flash CS5.5? FlashBuilder?

  • コードはFlashDevelopで書いて、デスクトップAIRとして書きだして作っていました
  • 実機転送するときは、最初はFlashCS5.5でやっていましたが、途中からFlashBuilderにしました。
  • FlashBuilderだと高速パッケージングというのがあって、10秒くらいでiOSのパッケージを作ってくれます。
    • (FlashCS5.5だと1分30秒くらいかかります。大規模になればもっとかかる)
    • Androidへの転送もFlashBuilderのほうが楽でした。デバッグもやりやすいです

開発期間は?

  • 普通のFlashを作る+iPhone/Android個別対応分、とハマりポイントでのタイムロスとかを考える感じです。
  • はじめてのときは単純にFlashの2倍くらいを考えればいいのではないかと思います。慣れたら普通のFlashと同じになると思います
  • 習得が容易ではないObjective-Cに比べると、非常に楽チンです。AIRのハマりポイントもあるので、そこをいかに速く抑えるかがポイントではないかと思います。
  • 一人ではやらないほうがいいです。検証するひとと、開発するひと、最低2人は必要だと思います。

簡単に作り方を教えて!

  • iOS
    • iOS dev Centerにて、デベロッパー登録→お金払う→証明書やプロビジョニングを取得
    • FlashCS5.5 or FlashBuilderでipa書き出し
    • iTunesかiPhone構成ユーティリティで実機に転送
    • リリース用にはリリース書き出しして、AppStoreに提出→審査
  • Android
    • 証明書を準備(FlashCS5.5 / FlashBuilderで作れる)
    • FlashCS5.5 / FlashBuilder で書き出し→そのまま実機に転送
    • リリース用にはリリース書き出しして、GooglePlayで登録

作成にあたって参考にしたものとかある?

AIR書き出しの際に、書いたらNGな関数があれば

  • 意外なことに、とくにないです

何故AIRだったのか?(Webアプリ・HTML5/CSS3じゃダメなの?)

  • アニメーションが楽
    • HTMLでアニメーションをやろうとすると結局Flashから書きだしてJSで制御、という流れもあって、画像入れ替えが生じたときも煩雑…。
    • まだ制作フローが完成されていないので、まだまだこれからというところですかね…。
  • クロスコンパイル
    • 少人数でiPhone/Android対応ができる、というのはお金的な面でも工数的な面でも品質的な面でも有利です

ハマりポイントは?

  • たくさんありましたよ…。それはまた別の機会に…。

まとめ

Flashそのまま作れてしまうし、よくわからないObjective-Cやjavaも覚えなくていいので、AIRだととにかく楽でした。

あと、やっぱりデバッグのしやすさ、アニメーション/演出の作りやすさはピカイチですね。

もちろん、ネイティブのUIフレームワークを使ったほうがよいアプリもたくさんあると思うので、適材適所ですが、Flash的なアプリだとばっちりなんじゃないでしょうか

またこんどはAIRのハマりポイントについて詳しく書きましょうー!

ご清聴ありがとうございました。

デザイナ上がりの2年目Flasherが読んだ本21冊の感想をだいたい3行くらい書きました。4行になった感想もあります。

  • 2009-12-24 (木)
  • ̃Gg[͂ĂȃubN}[Nɒlj

1年前に、「デザイナー上がりのFlasher1年生が読んだ19冊の本を、これほどかというほどに感想を書きます。だいたい3行だけど。」という記事を書きました。

思ったよりブクマされていたので、今年も紹介をしていきたいと思います!

今回紹介する全21冊!とページ内リンク

紹介するには多すぎますね!
読む側も途中で飽きてしまうと思うので、1冊だけB’zのモノマネをしながらレビューしますネ!
押しにくいですが、数字のセルがページ内リンクです!

ページ内
リンク
タイトル
1★★★☆☆Flash Math & Physics Design:ActionScript 3.0による数学・物理学表現[入門編]
2★★★★☆ビジュアライジング・データ ―Processingによる情報視覚化手法
3★★★★★アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣
4★★★★★
オススメ!
Foundation Actionscript 3.0 Image Effects
5★★★★★
オススメ!
初めてのFlash Video
6★★★☆☆よくわかるJava
7★★★★★
オススメ!
About Face 3 インタラクションデザインの極意
8★★★★☆AIRアプリケーションレシピブック
9★★★★★
オススメ!
禁煙セラピー―読むだけで絶対やめられる
10★★★☆☆Papervision3Dではじめる Flash3Dアニメーション
11★★★★★ActionScript 3.0 エラーアーカイブス コンパイルエラー・コンパイラ警告・ランタイムエラーの解法
12★★★★☆写真の撮り方手帖 ~たいせつなもの、撮ろう~
13★★★★★ディジタル画像処理
14★★★★★
オススメ!
ActionScript3.0辞典 [FlashPlayer10/9対応]
15★★★★☆ビデオカメラでいこう
16★★★★★
オススメ!
.fla2
17★★★☆☆After Effects Illusionist
18★★★★★
オススメ!
Adobe After Effects トレーニングブック サンプルデータを触りながら学べるハンズオン形式の解説書
19★★★★★Flash3Dコンテンツ制作のためのPapervision3D入門
20★★★★★フリーランスを代表して 申告と節税について教わってきました。
21★★★☆☆コミュニケーションをデザインするための本

2009年1~3月までに読んだ本

1. Flash Math & Physics Design:ActionScript 3.0による数学・物理学表現[入門編] ★★★☆☆

enterFrameでモーションを作るのに慣れていない人向け

「入門編」とあるので、かなり初心者向けに書いてあります。初心者向けなので、コードの美しさよりも動くことが重視されています。最後のほうのサンプルは応用できそう?ちょっと偏ってる気もしますね。

すべてのサンプルが公開されているので、確認してから買うかどうか決めるのがいいと思います。
http://furukata.com/fmpd/

2. ビジュアライジング・データ ―Processingによる情報視覚化手法 ★★★★☆

情報の整理や正規化など、その道の手法が学べる。

「データ収集」「解析」「フィルタリング」「マイニング」「表現」「精緻化」「インタラクション」というビジュアライズの7つのステップに沿って解説されています。

ビジュアライズは散布図、折れ線グラフ、ツリーマップネットワークグラフ、などなどです。

情報の取り扱い方に対する姿勢が学べます。これを読んだ直後に案件に活かせることがあって、とても重宝しました。何はともあれ「正規化」して「マッピング」するようになりました。

この本ではツールとしてProseccingを用いていますが、Flashでも十分書ける内容だと思います。

3. アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣 ★★★★★

悪魔と天使のささやきを対比させ、アジャイルな開発の心構えを教えてくれる

達人プログラマー―システム開発の職人から名匠への道

と同じような本。200ページほどの薄い本。すぐに読めました。

「正しい軌道に乗せるために、変化を起こし続ける」ということがアジャイルの本質なのでしょうか。

「いつでもリリース可能に」「インクリメンタルな開発」「フィードバック」「テストファースト」「ソリューションログをつける」「あらゆる例外を報告する」など、プラクティスが45個も掲載されています。どれもすぐに実践できる内容で、アジャイルな開発の心構えを教えてくれる1冊です。

4. Foundation Actionscript 3.0 Image Effects ★★★★★ オススメ!

Bitmapの操作を掘り下げまくった洋書

FlashPlayer10のPixelBender、ネイティブな3D、高度なBitmap操作などなど、Flashでできる画像処理をメインにした本です。はやく和訳本が欲しいくらいの出来です。

PixelBenderに関しては、50ページも書いてあります。これだけのことが書いてある本は他にないと思うので、それだけでも大きな価値があると思います。

他にはBlendMode、BitmapFilterの基礎から、テキストやビデオエフェクト、エフェクトのアニメーションなど応用の範囲も広く扱われています。

洋書なので読むのが億劫になることもありますが、サンプルコードと結果がわかればいいんです!読んだ気になって実践実践!

2009年4~6月までに読んだ本

5. 初めてのFlash Video ★★★★★ オススメ!

FLVの本というより、映像入門書。「FLV?なんとなく知ってます」程度なら絶対読んどけ!

扱っている内容がFMS2、AS2というのが難点ではありますが、FLVの技術的なことだけでなく、構図やビデオの撮影方法、編集まで書かれています。

その他にもFMSで録画、ストリーミング、PHPとDBとの連携、FlvPlayBackの基礎など、非常に多岐に渡る内容です。

また、オライリーにしては珍しく和訳本ではなく、日本人による執筆なので、とても読みやすくなっています。

あやふやな知識しかない映像初心者ならば、読んで絶対得をする内容です。

6. よくわかるJava ★★★☆☆

プログラムをあんまり知らない初心者向け

Red5というFMSクローンアプリがjavaで書かれており、必要にかられて買いました。「if文とは」「forとは」から始まる、よくある初心者向けの本です。

この手の本は店頭で適当に眺めて買うほうがいいですね。「Eclipseで始めるjava」みたいな本でもいいかもしれません。

7. About Face 3 インタラクションデザインの極意 ★★★★★ オススメ!

それは本当にユーザーのことを考えているのか

ユーザーのゴールを知ること。「ツールによって便利になったが、それによりユーザーが仕事を失う」ことはゴールではない

冒頭付近でこのくだりがあって、ハッとさせられました。「使いやすい」というのは表層的なものでしかなく、ユーザーが真に何を求めているのかを知ろうとしなければなりません。

本の内容は、ユーザー調査・ペルソナなどの概念的なことから、アンドゥやダイアログボックスなどUIまで、非常に多岐にわたります。

550ページもある上に、どれも濃くって難しい用語もたくさんでてきます。それでもオススメできるいい本です。きっと今までよりもユーザーのことを考えたモノづくりができるはずです。

8. AIRアプリケーションレシピブック ★★★★☆

WebDesigningのAIR記事をまとめた本。AIR初心者向け。いい編集されています。

AIR1.5対応。「ブラウザについてはこの記事」「ドラドロはこの記事」というように1記事1テーマなので、とても読みやすくとっつきやすいです。実際にリリースされているAIRアプリの紹介もたくさんある親切設計。これ1冊でだいぶカバーできると思います。

2009年7~9月までに読んだ本

9. 禁煙セラピー―読むだけで絶対やめられる ★★★★★ オススメ!

「タバコ吸いたい洗脳」を解いて、「タバコ吸わんでええやん洗脳」をしてくれ、めったにできない洗脳体験できる!

喫煙とは洗脳であり、麻薬中毒です。タバコがなければ落ち着きがなくなるし、お金がかかるし、肩身の狭い思いもたくさんしますね。これだけデメリットがあるのに、なぜ冷静に考えられないのか。

それは「タバコがあると落ち着き、活力がもらえる」と洗脳されているからです。

この洗脳を簡単にといてくれるのがこの本です。
様々な言葉で洗脳を解いてくれるのですが、僕は「喫煙者は口が臭い」という言葉に一番圧倒されてしまいました。その瞬間、「タバコが必要」という洗脳が解けた気がします。いままで臭い口をして生きてきて、本当にごめんなさい。

禁煙して最初の1週間は、ちょっと辛い時もありましたが、いま思うと微々たるものでした。周りのひとからも「なんでそんなに簡単にやめられるの?」って不思議がられました。「これで勝ち組になれたんだ!」という新たな洗脳が役に立ちましたね。

禁煙できたことよりも、

  • 「本質を見抜かず、洗脳されていることを知り」
  • 「自分に有利な洗脳をかけること」

という、洗脳体験、他では得られませんでした。洗脳サイコー!!

10. Papervision3Dではじめる Flash3Dアニメーション ★★★☆☆

まったく3Dを知らずにPV3Dから触る人向け

PaperVisioin3Dを触って初めて3Dの世界に飛び込んだひとも多いと思います。僕もそうでした。あやふやな単語の意味を知れるだけで有意義ではあります。

ただ、至る所にギャグが織りまぜられていて、合う合わないが分かれます。これは閾値を超えていて、気になるひとは大いに気になると思います。

後述するclockmakerの池田さんのPV3D本の方がよいのでそちらにしましょう。書評はこっち

11. ActionScript 3.0 エラーアーカイブス コンパイルエラー・コンパイラ警告・ランタイムエラーの解法 ★★★★★

「初心者」「AS2からの移行する人」に救いの手を差し伸べてくれる本

AS2→AS3への移行時に苦労したのが訳のわからないエラーの山。また、非プログラマでAS3から入った人もエラーには悩まされるはずです。そういったターゲットにはドンピシャです。

何よりこういうマニアックな本が出版されたことが喜ばしいことですね!Flashが盛り上がる!

12. 写真の撮り方手帖 ~たいせつなもの、撮ろう~ ★★★★☆

初心者向け。小さくてすぐ読めて、マニュアルモードで撮れるようになる。

デジタル一眼を買って1年。ちゃんと勉強しようと思って、買いました。知識があるなしでは全然違いますね。

こういう初心者向けの本は他にもあるので、1冊は読んだ方がいいですね。これを読んでマニュアルモードで撮れるようになりました。

あと、シグマ の単焦点も買ったのですが、この本とあわせて読むことで、少しは上達できたかと思います。光や構図など意識することが増えました。

2009年10~12月までに読んだ本

13. ディジタル画像処理 ★★★★★

超難しいけど、絶対役に立つ日がくるはず

以下のサイトさんでされている画像処理など書いてあります。
主にコーディング
http://mainly-coding.blogspot.com/search/label/Image%20processing

撮像素子などの入力、3次元空間から2次元への変換など基礎的なことから、最終的にはナンバープレートの文字を認識するところまでいっちゃいます。

僕にはあまりにも難しすぎて、まだ半分くらいしか読めていません。フーリエ変換とか全然わかりません。それでもいくつか理解できるところもあり、大変勉強になりました。ConvolutionFilterやBlurなどのFilter系がきちんと理解できただけでも、それはもうかなりの前進です。

この本を制圧すればARToolkitの中にいる小人さんが、何をしているのかわかるようになるはずです。

14. ActionScript3.0辞典 [FlashPlayer10/9対応] ★★★★★ オススメ!

必須というより、必読!ヘルプの丸写しじゃない!

800ページもある逆引き辞書。FlashPlayer10の機能を網羅し、FLVPlayBackなどUIComponentまでもカバーしています。

この手の辞書ってヘルプ丸写しが多いのですが、サンプルがしっかり作ってあり、1周読むだけでだいぶ世界が変わります。

僕は50ヵ所以上の付箋を貼りました。まだまだこんなに知らないことがあるなんて。。。ちょっと賢くなった気分も味わえてお得です。

15. ビデオカメラでいこう ★★★★☆

ドキュメンタリーは誰でも撮れる

ビデオカメラを買ったので、適当に選んだ1冊。でしたが、なかなかおもしろかったです。企画書から撮影テク、編集までの流れをさらっと解説してあります。薄くてすぐ読めます。

ドキュメンタリーはプロのものでなく、一般市民にも撮れる、あるいは市民目線の方がおもしろい、というようなスタンスで書いてあります。勉強する気になれますし、心強いです。

著者はOurPlanet-TVという独立放送局の人で、市民のドキュメンタリー制作などもサポートしているようです。OurPlanet-TVには素人とは思えないような骨太作品もあり、映像制作がとても身近に感じれる本でした。

16. .fla2 ★★★★★ オススメ!

偉人の思考回路をのぞき見できる

いわずと知れた.fla2。前作もすばらしい内容でしたが、今作もすごく濃い。

著者のみなさんは、やりたいこと、実現したいことを明確に持ち、困難に見えることを実にポジティブな姿勢でやってのけています。前作同様「どうすれば実現できるのか」というような過程を見せてくれます。

毎日グチっているリーマンFlasherにはうってつけの治療薬となるかもですね。

公式サイトでは出版イベントのYoutubeなどの情報もあります。みなさん濃い話してますね。http://dotfla.net/

17. After Effects Illusionist ★★★☆☆

AfterEffectsの標準搭載されているプラグインエフェクトを網羅したサンプル本。サンプルはCS4のみ対応。

189種類もの標準搭載エフェクトのカタログとなっています。すべてカラーページで画像も豊富でわかりやすいです。辞書よりもちょっと詳しく解説されています。

僕はayato@webさんで表現の勉強をしながら、この本でエフェクトの意味を確認する、という使い方をしました。「ああーコロラマってこういうことなんだー」っていう確認がすぐできると理解も深まります。

また、「これは使えないエフェクトです」と、きちんと教えてくれるのも独学する人間にとってありがたいですね。

ただ、サンプルがCS4だけってのはちょっと…。

18. Adobe After Effects トレーニングブック サンプルデータを触りながら学べるハンズオン形式の解説書 ★★★★★ オススメ!

超大量の図版でめっちゃくちゃわかりやすい

AE始めるなら、まさにこれ!とってもわかりやすい。いきなりショートカットキーの一覧から始まるのも超イイ!

ルミナンス、マスク、トラッキング、タイムリマップなど、初心者がつまづくことをきちんと書かれていて、操作やできることが全部覚えられるんじゃないかと思います。

僕はこの冬、こいつを制覇します!

19. Flash3Dコンテンツ制作のためのPapervision3D入門 ★★★★★

PV3Dの基礎を網羅した良書。ネットに散らばったPV3Dの情報が集まっている

clockmakerこと池田さんの本。まさにあのBlogの通り、ものすごく丁寧な内容です。政治的な意味で★5つしてるワケではなくって、ほんとによくできてる本だと思います。

オブジェクト同士のhitTestやカリング、3D内部でのマウス取得、頂点操作など、Flasherなら必ず1度はググったことのある内容が網羅されています。なのでリファレンスとしても優良。最後にはAS3Dmodまで!

逆に何が書かれていないのかを確認した方が早いかもですね。AR、jiglib、被写界深度の実現などは書かれていません。本のタイトルが「入門」とのことなので、出るかもしれない「応用編」にも期待しましょう!

20. フリーランスを代表して 申告と節税について教わってきました。 ★★★★★

おちゃらけながら、楽しく税のことがわかる本

きたみりゅうじさんというフリーのライター・イラストレーターさんが、税理士と対話形式で、節税について語ってくれます。

著者はとってもおもしろい文章を書く方で、すいすい読めちゃいます。あと、青色には2種類あって、簡単なやつと細かいやつがあり白色申告するくらいなら簡単な方の青色申告すればいいことが、よ~くわかりました。

あと僕、今はまだサラリーマンなんですけど、この本を紹介するってことは…、そういうことなんです!何かあればお願いしますネ!ゲヘゲヘ!!

21. コミュニケーションをデザインするための本 ★★★☆☆

話題を集めてGood コミュニケイシャーン!

ティーティーティリッティーリー ティッティーティリッティーリー!!!
wow wow wow wow wow wow wow !
バッド カミュニケイシャ~~ ン!

ぅWebを中心にぃー、ぃひとつのキャンペーンを掘り下げて解説してありますぅわふぅー。ぅ著者が言ってるけど、ぉこれだけ深く掘り下げる本はあまり例がないですねぃぇぃ。
んんそぉの多くが「話題にのぼるよう」に設定しぃひぃーん、ぅーバイラルやメディアに取り上げてもらって拡散するように計算されていますぅっぅー。 (Yeah) 話題性があれば、それ以上の広告効果が期待できるようですぅぅ (Oh) 。

AISASモデルを使って立体的に捉え、人や情報が流通するような緻密な計画、やり手のプランナーはすごいですね。

ぅぃいずれの事例も消費者に対し「共有したい」「共感する」「発見する」といったポジティブな気持ちにさせるようにやっていて、愛のままにわがままに 僕は君だけを傷つけない。

そしてぇー 羽ばたく ウルトラソウル (Hi)

BulkLoaderで「もう悩まない!」ための6つのtipsをまずは14日間で売上No.1!!

  • 2009-10-01 (木)
  • ̃Gg[͂ĂȃubN}[Nɒlj

海外製のライブラリは日本語の情報が少なくて、英語のASDocやwikiを見たりしますよね。でも英語って読むのが難しいですよね…。

僕なんかね、キィーーッ!!ってなりますね。ぜんぜん読めないから。みなさんもキィーーッ!!ってなってますよね。でもBulkLoaderに関しては安心してください。もう、傷つく事に怯えなくていいんです。

BulkLoaderプロジェクトのDebeloperGuideってところにおトク情報がありました

BulkLoaderに同梱されているサンプルはほとんど説明がないのですが、GoogleCodeのプロジェクトのwikiに結構な情報がありました。

http://code.google.com/p/bulk-loader/wiki/DeveloperGuide

このうち、おトク情報を6つピックアップすることにしました。
以下目次がわりのページ内リンクです。

  1. weightプロパティで各Itemのパーセントの重み付けをして、精度のいいパーセントを取得する
  2. BulkLoaderのインスタンスはプールされている
  3. stringSubstitutionsでパスの切り替えなどができる
  4. 設定を外部ファイル化して勝手にロードしてくれるLazyBulkLoader
  5. add()するときのプロパティ一覧
  6. 一つでもエラーがあると止まってしまうから、エラーハンドリングしとこう

1. weightプロパティで各Itemのパーセントの重み付けをして、精度のいいパーセントを取得する

この間「超便利なローダーBulkLoaderの落とし穴にハマってきました」という記事を書きました。その中で、パーセント取得がちょっと難しいなーという話をしました。

よくよく調べてみると、もうひとつ打つ手がありました。

BulkLoaderのドキュメント・見出し「By weight」のところ
http://code.google.com/p/bulk-loader/wiki/ReportingLoadingProgress

ここをかいつまんで説明しますね。
あと、これから「Item」と呼ぶものは「ロードするもの」っていう意味で使います。

weightってこんな感じで動いてる

  • ロードするItemが10個あって
  • それぞれのItemにweightが設定されていない

というケースでは、各Itemに割り当てられるパーセントは1/10、つまり10%ずつです。

このうち1つのItemがFLVなどで他のファイルより重いときにweightを設定します。この重いItemをweight=11と設定しましょう。あと、Itemのデフォルトのweightは1ということを覚えておいてください。

_bulkloader.add("hoge.flv", { type: BulkLoader.TYPE_VIDEO, weight: 11 } );

すると、

Item 割り当てられるパーセント
weightを11にしたItem 11/20
他のItem 1/20

こんな感じであがります。元の分母はItem数なので10。それに、増えた重みを足して10+10で分母が20になります。たぶん!これで、FLVのパーセントが55%分を占めるようになり、期待している値に近づきました。

このweightが設定されたパーセントを取得するにはweightPercentを使用します。

weightPercentでもうすこし正確なパーセント表示

BulkProgressEvent.weightPercentにweightを考慮したパーセントが入っています。

(item._bytesLoaded / item._bytesTotal) * item.weight;

いたってシンプルですね。こういった形で加算されていくので、かなり実際と近いパーセントが取得できそうです。

weightの設定にひと手間かける分、ratioLoadedbytesLoadedよりもわりと正確な値を取得できます。

2.BulkLoaderのインスタンスはプールされている

BulkLoaderのインスタンスはBulkLoaderクラスの静的なプロパティに保存されていて、いつでも再利用できるようになっています。

BulkLoaderクラスのstaticメソッドには取得・破棄の2種類があります。

//インスタンスの取得
BulkLoader.getLoader(name);

破棄メソッドについては、すべてのBulkLoaderインスタンスを削除するものしか用意されていないようです。

BulkLoader.removeAllLoaders();

再利用しないのであれば、removeするのがいいでしょう。

3.stringSubstitutionsでパスの切り替えなどができる

ロードしたいパスに変数ぽいものを仕込んで柔軟性を上げることができます。

_bulkLoader.stringSubstitutions = {
	"base_path": "http://example.com/test/"
}
_bulkLoader.add("{base_path}test.jpg");
// これが→http://example.com/test/test.jpg に変換されます。

テスト用パスと、本番用のパスを変えるときに便利そうですね。

4.設定を外部ファイル化して勝手にロードしてくれるLazyBulkLoader

ロードしたいItemとその設定を書いたxml・jsonを書くだけで、自動でロードしてくれるクラスがLazyBulkLoaderです。以下の2種類あります。

  1. LazyXMLLoader
  2. LazyJSONLoader

xml・json内部で設定できることはasで書けることとほぼ同じだと思われます。以下のxmlを見るとよくわかります。

BulkloaderのLazyサンプルに同梱されているサンプルxml

使い方はBulkLoaderのサンプルに含まれている
/examples/serialized-loaders/SerializedTestMain.as
に書いてあります。

使い方は簡単です。

lazy  = new LazyXMLLoader("http://www.emptywhite.com/bulkloader-assets/lazyloader.xml", "theLazyLoader")
lazy.addEventListener(LazyBulkLoader.LAZY_COMPLETE, onLazyInfoLoaded); //設定xmlを読み込んだときのハンドラ。特に何かするときだけ使う
lazy.addEventListener(Event.COMPLETE, onAllLoaded); //すべてのItemがロードされたら(いつもの)
lazy.addEventListener(ProgressEvent.PROGRESS, onAllProgress); //ロードのプログレス(いつもの)

AS側でやることがほとんどなくなるように見えますね。ロードしたあとのパースにしわ寄せがきますが、うまく使いこなせば楽になるかもしれません。

5.add()するときのプロパティ一覧

ASDocではわかりにくいので超意訳してみました。

プロパティ Classのconst データ型 説明
preventCache PREVENT_CACHING Boolean urlにランダム文字列を付与して、キャッシュを防ぐかどうか
id ID String getXML()などで取得するためのID。とくに指定しないとurlがIDになる
priority PRIORITY int 読み込みの優先順位。intが大きい順に読み込む。
maxTries MAX_TRIES int ロード失敗したときに何回リトライしにいくか。デフォは3
weight WEIGHT int weightPercentを使うときのパーセントの重み
headers HEADERS Array 追加のリクエストヘッダ
context CONTEXT LoaderContext or SoundLoaderContext 追加のContext
pausedAtStart PAUSED_AT_START Boolean VideoItemのみ。nestreamがロードした直後からVideoを再生するかどうか 

6. 一つでもエラーがあると止まってしまうから、エラーハンドリングしとこう

IO_ERRORやセキュリティエラーが発生したら、そのItemは失敗とみなされ放置されます。放置されると「すべてのItemがロードされました」というイベントCOMPLETEが呼ばれなくなります。

以下のようにエラーハンドリングすると、まあ、なんかできるでしょう!

_bulkLoader.addEventListener(ErrorEvent.ERROR, errorHandler)
private function errorHandler(e:ErrorEvent):void
{
 	//失敗したファイルをremoveする
	_bulkLoader.removeFailedItems();
 	//まだファイルのロードが残ってたら
	if (_bulkLoader.isRunning)
	{
		//コンプリートイベント待つなどする
	}
	else
	{
		//失敗したやつ以外は終了したので、終了処理に移る
		bulkLoadComplete(null);
	}

}

MultiProgressManagerのBulkLoaderのモデルも対応させました

ついでに、SparkにコミットしたMultiProgressManagerのBulkLoaderのモデルもweightPecentに対応させました。だいぶまともな動作になりそうです。

ハイ!ということでね!

今回はBulkLoaderを眺めるだけの記事でしたー。

特に何も茶々を入れなかったので、期待してくれてたみんなからは大ブーイングだね!むしろ大ブーイングの方が嬉しい!「今回みたいに普通に書いてよ。しょうもないこと書かんでいいから」とか思われたくないんです!

い、イヤー!心の声が聞こえるー!!それ以上言わないで!!やめてー!!ロマンティックとめてー!!もう、傷つく事に怯えたくないー!キィーーッ!!

複数ロードのプログレスを一本化できる「マルチプログレスマネージャー」で幸運パワーを掴め!

  • 2009-08-25 (火)
  • ̃Gg[͂ĂȃubN}[Nɒlj

パーセント表示のとき、ちょっと面倒な複数のプログレスの監視

たくさん外部ファイルを読み込むコンテンツを作る際、ローディングの表示ををまとめるのって厄介だったりします。

そこで、あらゆるProgressEventをまとめちゃおうというクラスがマルチプログレスマネージャー(MultiProgressManager)です。

Spark Projectにコミットしました!

複数ロードのプログレスが多いと、ホントやっかいですよね!

最初のロード画面で、以下のような流れを行うFlashは比較的多いですよね。

  1. PreloaderからメインのSWFを読むプログレス
  2. xmlを読むプログレス
  3. 画像を読むプログレス
  4. 読み込んだ画像などからビルドするのに時間がかかるときのプログレス
  5. ようやくコンテンツがスタート

わかりにくい図にするとこのような感じです。
m_normal1

これらを最初にまとめて読み込んで、パーセントをうまく100%にまとめようとすると、下図のように、よくわからないことになります。
m_gonyo1

Preloaderがloader経由でmain.swfを読んで、そのプログレスを監視して、main.swf側でconfig.xmlを読んで、その中の…、ああー、もうややこしいわ!30歳近くなったし、将来に不安あるし、湿度高いし、イライラするわ!

そんな悩めるFlasherにお届けするのが今回のマルチプログレスマネージャー!

使い方はとても簡単!面倒だったパーセント表示が、たちどころにまとまります!

マルチプログレスマネージャーは、パーセント表示のMVCのM(モデル)部分

マルチプログレスマネージャーはモデルに徹します。大きな流れとしては以下の3点!

  1. MultiProgressManagerのインスタンスを作って
  2. それぞれのプログレスを見張るをモデルを突っ込むと、
  3. 全部をまとめて0~1までに変換された進捗率が吐き出されます
//マルチプログレスマネージャーのインスタンス生成
_progressManager = new MultiProgressManager();
//ローダーのプログレスを70%に設定して突っ込む
var loader:Loader = new Loader();
var model:AbstractProgressModel = new ProgressEventModel(loader.contentLoaderInfo, 0.7);
_progressManager.addProgress(model);

//他の素材読み込みを残り30%に割り当てて突っ込む
var urlLoader:URLLoader = new URLLoader();
_progressManager.addProgress(new ProgressEventModel(urlLoader, 0.3);

//読み込み開始
_progressManager.start();
loader.load(new URLRequest("main.swf"));
urlLoader.load(new URLRequest("config.xml"));

パーセント表示はMultiProgressManagerのイベントを監視するだけ。それもプログレスとコンプリートの2つだけ!

MultiProgressManagerを稼動させるとプログレスのイベントが通知されるのでそれをリスンします。

//このイベントにまとめられたパーセントのプログレスが入っています。
_progressManager.addEventListener(ProgressPercentEvent.PERCENT_PROGRESS, progressHandler);
//パーセントの完了イベント
_progressManager.addEventListener(ProgressPercentEvent.PERCENT_COMPLETE, completeHandler);

//プログレスのイベントハンドラ
private function progressHandler(event:ProgressPercentEvent):void 
{
	//パーセント表示を更新
	loadingBar_mc.scaleX = event.percent; //event.percentは0~1までのNumber
}
private function completeHandler(event:ProgressPercentEvent):void 
{
	trace("終了");
}

さっきのわかりにくい図が驚くほど簡単に!

担当すべきクラスを分けることで、みるみるあっさりしました!これこそ宇宙の波動!

m_result1

UMLっぽくするとこうなります(でっちあげのUMLです)
m_uml

モデルの拡張も簡単!いろんなプログレスに対応できる!

AbstractProgressModelを継承すれば、標準のプログレス以外にも対応できます。しかも、考えるのは2点だけ!

  1. progressイベントをリスンすることを書く
  2. 完了したときの処理を書く

を書くだけで簡単に拡張できます。同梱しているBulkLoader用のBulkLoaderProgressModelがまさにこれです。

「main.swfは全体の50%くらい、config.xmlは10%くらいで」といった、割り当てもサクっとできる!!

個別にプログレスを監視するクラス(AbstractProgressModel)にはpercentRangeというプロパティがあります。こいつが「main.swfは全体の50%にしよう」といったプロパティになります。

//50%で読み込む
var model:AbstractProgressModel = new ProgressEventModel(loader.contentLoaderInfo, 0.5);

下図のような割合でやるときも、引数を割り当てるだけで実現できちゃいます。

さらに、今回は「パーセントが上昇するときのスムージング(線形補完)」もお付けします!

new MultiProgressManagerするときの第二引数をtrueにするだけで、スムージングします。
いちいちView側で操作する必要がありません。

//引数は EnterFrameの監視にStage
//スムージングをtrue
//スムージングのfrictionを0.3
//パーセントがいっきに上がりすぎないための、最大の上昇幅
new MultiProgressManager(stage, true, 0.3, 0.05)

未対応なところもあるけれど、今後もっと成長する余地があるってことだネ!

  • エンターフレームで監視しているときに、常にProgressPercentEvent.PERCENT_PROGRESSを飛ばしている(以前のフレームと比較して、パーセントに変化がなければ飛ばさなくてもいいかも)
  • IOエラーなどは監視していない(これは監視しなくてもいい?ロードしてる本体が処理すべき?)
  • キャンセルがちょっと雑?

というわけで、みなさんの風水パワーを待ってます!

無人島でもくもくとやってきたので、ライブラリとはどういう流儀で、どのようなものが求められるのかあまりわかっていません。とにかくコミットしてみました。

「ここおかしい!」というところがございましたら、ガンガンつっこんでください!

サンプルの中身を普通に説明

サンプルも作りました。Sparkのリポジトリに入っています。

サンプルでは普通のFlashでありがちな流れをやっています。

  1. preloader.swf起動
  2. main.swf読み込み
  3. 設定xml読み込み
  4. 複数画像の読み込み
  5. パーセント表示の終了処理
  6. main.swfの表示開始

1.preloader.swf起動(Preloader.as)

2.preloaderがmain.swf読み込み(Preloader.as)

reloader.as 66行目付近から

  1. インスタンスの生成(シングルトンバージョンを使用します)
    SiMultiProgressManager.getInstance(stage, true, 0.3, 0.05);
  2. イベントハンドラの設定
  3. 読み込み開始

3.main.swfを読み終えたら、設定xmlの読み込み

  1. Preloader.as 95行目付近 mainLoadCompleteHandler内部で
  2. Main.as の86行目 start()を呼び、Mainの構築用のスレッドを開始します
  3. LoadConfigThread.as内部でxmlを読み込みます。

4.設定xmlに指定された複数画像の読み込み

AssetsLoadThread.as内部で複数画像の読み込みを行います。
ここではBulkLoaderを使って複数読み込みをまとめています。

5.読み込んだ素材を配置していきます

複数読み込みが終われば BuilderThread.asで配置します。

6.パーセント表示の終了処理

  1. すべての読み込みが終了し、パーセントが100%になったら、パーセント表示をフェードアウトさせて消します。
  2. Main側ではOpenContentsThread.asでパーセント表示が消えるまで待機状態になります。
  3. Preloader.as の116行目付近 completeHandler()が呼ばれるので、そこでパーセント表示をフェードさせます。

7.main.swfの表示開始

パーセント表示のフェードアウトが終わったら、待機していたOpenContentsThreadが動きだし、mainの表示を行います。

ハイ!ということでね!

そないたいしたクラスでもない上に、書き方の幅ちょっとを広げようとして、また失敗してしまいました。「イライラするわ!」のくだり以降、途中で飽きてきてるのもわかりますね。

はい。今回の記事はスクリーンセーバーの記事で使う予定のライブラリの説明でもありました。複数ロードを使うので、ここらで説明する必要があったのでした。

あと、Threadライブラリにも影響を受けてます。ほんとはThreadのIProgressも対応したかったのだけど、まだまだ理解不足なので次のバージョンで対応とかしたいです。

あーあ、なんつーか、輝いてへんわ。ガイアのやつ、ぜんぜん囁いてくれへんから輝きもせえへんわ。全部ガイアのせいや。ガイア君、どこいってもうたんや。

更新できるスクリーンセーバーを作ろう(3):fla:verでの制作の流れと注意点

  • 2009-07-09 (木)
  • ̃Gg[͂ĂȃubN}[Nɒlj

前回では作る手前の話をして、ずいぶんウコンウコンしましたね。またfla:verの開発者さんからもコメントがありました。自動更新に対応してくれるかもしんない!スゲー!応援して待ちましょう。

さて、今回からは技術的なことをお話したいと思います。具体的なコードの手前、設計まわりから見ていきましょう。

fla:verでの制作の流れ

Macで再生するときにいくらかの地雷がありますが、知っていれば回避できるので恐くありません。

1.小さなプレビュー画面かどうか

fla:verでは、小さなプレビュー画面でもスクリーンセーバーの本体(swf)が再生されます。小さなプレビュー画面とは以下のものです。

  • Win「画面のプロパティ→スクリーンセーバー」上の小ないプレビュー画面
  • Mac「システム環境」→「スクリーンセーバ」上の小さなプレビュー画面

そのまま本体のswfを再生すると画面サイズが小さすぎて不都合が生まれることも多いので、ここで分岐をとり、プレビュー画面ならプレビュー用の画面を見せる、といったことをします。

スクリーンセーバーで再生されているとFlashvars"flavermode"にプレビューかどうかのstateが入ります。

trace(stage.loaderInfo.parameters["flavermode"]) //preview プレビュー
                                                 //normal  スクリーンセーバー再生時
AS3での簡易チェックコード
 public static function isPreview(stage:Stage):Boolean
 {
 	var mode:String = stage.loaderInfo.parameters["flavermode"];
 	var result:Boolean;
 	switch (mode)
 	{
 		case "normal" :
 			result = false;
 			break;
 		case "preview" :
 			result = true;
 			break;
 		default :
 			result = false;
 			break;
 	}
 	return result;
 }

補足)previewのときでもstageWidthとheightがゼロじゃないかをチェックする必要があります。Macでは初期値がゼロになります

2.ネットワークチェックとSWFの縦横サイズがゼロじゃないかのチェック

2-1.ネットワークにつながってるかどうかのチェック

  • ネットワークにつながっていれば、サーバから最新の情報をダウンロードする
  • ネットワークにつながっていなければ、ローカルに同梱したファイルを見るようにする

実装方法は外部サーバの適当なファイルに接続を試し、IOErrorが返るかどうかでチェックをします。

という分岐があるので、ここでネットワークのチェックをします。

チェックするファイルにはキャッシュ対策をする

スクリーンセーバーもファイルをキャッシュするので、対策を施します。以下のような簡単なもので大丈夫です。

new URLRequest(url + new Date().getTime());

2-2.stageWidthとstageHeightがゼロじゃなくなるまで待つ(Mac対策)

Macで再生するとstageWidthとstageHeightの初期値がゼロになり、意図しない配置になります。以前のエントリに詳しい実装方法を載せていますので参考にしてください。

SWFObjectのDynamic Publishingを使うとIEとかでStage.stageWidthとheightが一瞬ゼロになるという都市伝説は実在した! | Katapad Design

3.外部設定ファイル読み込み

外部の設定ファイルを読みに行きます。この設定ファイルには

  • 本体となるswfが最新の状態かどうか
  • 読み込む素材はどれどれ

などといったことを記述しておきます。

4.素材読み込み

外部設定ファイルに書いてある素材を読み込んでいきます。

たいていの場合、複数の素材を読み込むことになるので、まとめて読み込めるローダーを使うと便利です。僕はBulkLoaderを使ってガスガス読み込みます。BulkLoaderについてはこないだ書いたのも参考にしてください。

また、すぐに必要のない素材は少しずつ先読みしていくだけのプリローダーを裏で動かし、キャッシュ化しておくと効果的なケースもあります。ドデカいFLVとかは厳しいかもしれませんが、いずれすべて読み込むことになるのなら、ささっと読み込んじゃいましょう。

5.コンテンツビルド

素材のロードが終わり、さまざまな設定を格納したら、ページや配置する画像などの要素をビルド(生成して配置)していきます。

6.コンテンツスタート~ループ

要素の準備ができたら、やっとコンテンツをスタートできます。

スタートさせればあとはループするだけです!

さてさて、大雑把なスクリプトの流れはご理解いただけたでしょうか?ちょっと駆け足過ぎたかもしれないですね。

続いてはちょっとした注意点を見てみましょう。

知っておくと健康にいい注意点4つ

mailto:でメーラー立ち上げようとすると、ブラウザまで立ち上がってしまう

winならIEも開いてしまうので、実質使えません。

「友達に教える」機能を付けるときはWebサイト側にリンクを貼って、

  • 「友達に教える」フォームを用意する、もしくは
  • mailtoのリンクを置く

のがベターです。

インストール時に一緒にインストールされる追加ファイルにフォルダを作れない

fla:verではどの素材も、スクリーンセーバーの本体となるswfと同じ階層に置かれてしまうので、素材の名前付けに注意しましょう。

これには前回のコメント欄で開発者さんが補足してくれました。セキュリティ的に階層がない方がいいそうです。

スクリーンセーバーを再生している途中で「ネットあり」→「ネットなし」になったら落としたほうがいいときもある

途中で設定を「ネットあり」から「ネットなし」に変更すると大変な労力が必要になることがあります。ならば、いっそのことスクリーンセーバーを強制的に落としてしまいましょう

スクリーンセーバーが再生されている=「PCが放置されている状況」が多いので、落としてもしばらくすると「ネットなし」としてスクリーンセーバーが立ち上がります。

ロードする状況化でIO_ERRORなどを見張っておいて、エラーがでたらスクリーンセーバーを落とすコマンドfscommand("quit");を叩くようにします。

あと、落とす前にエラー画面として

「ネットに繋がらなくなったので、落としますね」

と出すのが優しいかと思います。

Macでマウス操作などを許可しているときにブラウザを開いてもスクリーンセーバーが落ちない

マウス操作許可し、親サイトへのリンクやRSSのリンクを張ったりすることがあります。Windowsではリンクを押してブラウザが開くタイミングで、スクリーンセーバーも一緒に落ちてくれます。

このケースではMacでうまくいきません。スクリーンセーバーが落ちずに、裏でブラウザが開きます。ですので、明示的にスクリーンセーバーを落としてやる必要があります。


//リンクを押したら、落とすことも明示する
navigateURL(~~~);
fscommand("quit"); //スクリーンセーバーを落とすコマンド
		

インストーラ用の素材:アイコン素材と背景画像を用意する

http://flaver.jp/からProfessional版をダウンロードし、実際のインストーラがどんなものかを体験してみてください。
シリアルを入力せずに開始すると「試用版」になるので、気軽に試せます。試用版ではスクリーンセーバーを再生したときに「試用中です」と文言がでますが、すべての機能が使えます。

windows用の素材

アイコン素材 icon形式。48、32、16をそれぞれTrueColorと256色を用意します。vista用に特大サイズのアイコンを用意してもいいかもしれません。
IcoFXというソフトを使うと簡単に作れます。IcoFXはMacのicns形式も作れます。
インストーラ画面用の画像 64px * 294px: png, jpg

mac用の素材

アイコン素材 icns形式。img2icnsというソフトが簡単です。
インストーラ画面用の画像 最大567px * 320px: png, jpg

さてさて、こうして骨組みは出来上がりましたね。いっきに説明したので、わけわかんないところもあると思います。

今回もまじめに書いてしまいました。楽しみにしてくれていたみなさん、本当にすみません。ただ、頭にパンティーをかぶって記事を書いていたことだけは覚えておいてください。

次回は実際にサンプルを作ってみましょう。

スクリーンセーバーのことシリーズ

大阪teraco23でRed5のことを話してきました

  • 2009-07-01 (水)
  • ̃Gg[͂ĂȃubN}[Nɒlj

大阪てら子23に参加してきました。発表する人がたくさんいて、とても有意義でおもしろかったです。みんなすごいんです。刺激的な一日でした。

僕はRed5というFMSクローンアプリの軽い紹介をしてきました。

マルチユーザのサンプル・ENGACHO

発表内容のスライド(wiki)

サンプル http://lab.unko.me/engacho/
(サーバの問題で期間限定です。1ヶ月くらいたったら消えます)

Red5を使ったマルチユーザのサンプルです。一人でやってもまったくつまらないので、お誘いあわせの上、触ってみてください。人数が多いとほんのすこしだけマシになります。

  • unkoに触れるとunko状態になります
  • unko状態で他のユーザに触れると伝染します
  • unko状態でステージ左に配置されてるハブラシでこすると、きれいになります
  • 右上のフキダシに触れると、感情を表示します(キーボードの1~4でもできます)
  • コナミコマンドを叩くと全員が感染します
  • よくグダグダになります。グダグダになったら広い心でリロードしてあげてください

サンプルのスクリプトなど、細かい解説ができなかったので、ここで補足

sequence

サーバサイドの処理の流れ

  1. サーバサイドに接続されたら、サーバの中でアプリケーションインスタンスが生成される
  2. appStartが呼ばれるので初期化
  3. appConnect()で接続してきたユーザにユーザIDを発行して返す
  4. appDisconnect()で切断されたユーザからユーザIDを取り出して、SharedObjectにsetしたそのユーザのプロパティを削除する

といったことをしています。

クライアントサイド(SWF)の処理の流れ

  1. rtmpにコネクト
  2. ユーザIDを取得
  3. SharedObjectに自分のIDとデータ(マウスの座標などのプロパティ)を登録
  4. SharedObjectの更新にあわせて他人のマウスカーソルを追加する
  5. EnterFrameで描画の更新をする
  6. 接続が切れたらサーバ側で、切断されたユーザのプロパティをSharedObjectから消す
  7. SharedObjectのプロパティが削除されたイベントが飛んでくるので、それを受けて他人のマウスカーソルを除去する

といったことをしています。文字だとちょっとわかりにくいですね。

SharedObjectのSyncEventが鬼門で慣れるまでが大変ですが、けっこう簡単に作れそうな感じです。

サーバへのインストールとかはwikiで

実はひっそりとwikiを書いてたりしてました。メモなのでそこまで裏は取っていませんので間違いもあると思います。何かの役に立つかもしれませんのでそんな目でみてもらえると助かります。

その他わけわからん現象とか作った感想とか

マウスのロールオーバーがおかしい(追記:意味がわかった!

マウスのロールオーバーが、左から右へマウスを移動しているときにしか利かなかったり、おかしな挙動をしています。
右上のフキダシも同様、マウスの移動方向でおかしくなってます。
追記:カーソルに色をつけたかったので、Mouse.hide()をして、カーソルのビットマップを置いているのですが、そこに問題がありました。mouseChildrenをfalseにすればokぽいのですが、衝突判定をhitTestObjectでやっていて、mouseChildrenをfalseにするとhitTestが効かなくなってしまいます。とりあえず放置!
ストーリーや目的、オチがないと、劇的につまらない
これがいわゆる出オチというやつです!

反省

スライドを作って行かなかった

htmlをスクロールして見せてました。u-stream見てる人には文字が細すぎて見えてなかったかと思います。次はそのへんを改善します。

何をしゃべってるのかわからなかった

スライドを読み上げているだけだったなーと思います。ここが一番の失敗でした。スライドと原稿をわければよかった。

芸風がダメなんじゃないかと思った

国道43号線ネタはしばらく公の場では封印します。ポップさが圧倒的にたりませんでした。そんで新しいのを考えました。二次会で期待してください。

収穫

作ることはいいこと

「どうやって楽しませよう」とか「どうやって驚かせよう」とか、久しぶりにそういうことを考えれてよかったですし、なにより反応を間近で見れるのはいいですね。稚拙な内容でしたが、ライブ感が楽しかったです。今度はもっとクオリティをあげていきます。

更新できるスクリーンセーバーを作ろう(2):作成ツールを比較したらどれも一長一短あるね!

  • 2009-06-02 (火)
  • ̃Gg[͂ĂȃubN}[Nɒlj

前回はスクリーンセーバーの基礎知識や周辺などを考察し、ずいぶんアヘアヘしましたね。
今回はスクリーンセーバー作成ツールの比較をしましょう。

スクリーンセーバー作成ツール比較

まずはおおまかな特徴だけを比較してみましょう。GIZMOはまだ使ったことがないので、サイトの情報から推測してたりします。

  スクリーンタイム fla:ver GIZMO
vista対応 非公式
MacLeopard対応 まだ(でもベータ的なものはある)
FlashPlayerのバージョン win:Player8まで
Mac: Player9まで
制限なし たぶん制限なし
as3対応 ×
再生の有効期限 ×
ローカルディレクトリ、
ファイルの操作
× たぶん○
自動更新 × ×
スクリーンセーバー
停止方法が複数ある
日本語入力 たぶん× 不明
外部ファイルを
インストール時に追加できる
不明
外部ファイルの
ディレクトリを保つ
× 不明
マルチモニター再生の選択肢 ×
(すべてのモニターで再生される)
win版とmac版の
合計価格
74,550円 34,800円 320,000円~
(winのみ?、macは不明)

スクリーンタイム(ScreenTime for Flash)


http://www.screentime.jp/

特徴

  • いいところ
    • コンポーネントをfla側に埋め込んで「STFコマンド」を打つといろいろできる
      • ローカルファイルを読み書きできたりするコマンドがいろいろある
    • 有効期限付き
  • 残念なところ
    • AS2.0まで
    • vistaに正式対応してない
    • win版はFlashPlayer8まで
    • mac版はFlashPlayer9まで(AS2)
    • ヘルプがかなりわかりにくい

as2までしか対応していないなど、イケていない面もありますが、最大の特徴としてディレクトリを保ったまま様々な外部ファイルを同梱できるという強みを持っています。

また、スクリーンタイムにはコンポーネントのインストールmxpが配布されています。mxpをインストールすればFlashのヘルプにスクリーンタイムのヘルプが追加されます。

事例

昔はSTFしか選択肢がなかったようで、プリミティブなスクリーンセーバーによく使われています。

zozotownにたくさんあります(ログインの必要あり)
http://gallery.zozo.jp/

見分け方

  • winならインストーラの詳細に「会社名 FIVESTAR~~」と出ます。これは消したり変更はできないようです。
  • スクリーンセーバーのインストーラ画面(win)

    (スクリーンタイムではこの白場に任意の画像を埋め込めます)

fla:ver


http://flaver.jp/

特徴

  • いいところ
    • as3使用可
    • win, mac対応
    • 安い(Win/Mac2つのバージョン合わせて34,800円)
  • 残念なところ
    • 同梱させるファイルにディレクトリ階層を設けられない。
  • それ以外
    • winはActiveXプラグインFlashPlayer、macはsafariのプラグインFlashPlayerで再生する
    • ローカルファイルの読み書きはできないが、スクリーンセーバーとしての基本的な機能は網羅してある

大量のファイルを同梱させるとちょっと大変になりますが、問題がないといえば問題ありません。

それとスクリーンセーバーの再生の機能は強いですが、有効期限やネットワークにつながっているかどうかのチェック機能などもありません。しかし、そういった機能はFlashで代替できるので、ごまかせます。

事例

G’z One CA002 by CASIO
http://gzone.jp/
ぷっちょくんをつくろう!
http://create.pucchokun.jp/
Play MUJI
http://www.muji.com/playmuji/
エディックス(公開終了)
http://www.honda.co.jp/Edix/editSCR/

見分け方

  • スクリーンセーバーのインストーラ画面(win)

    (インストーラ左にある画像はfla:ver側で変更可能です)
  • macならスクリーンセーバーの設定画面のオプション→アンインストールというボタンがあります。

GIZMO


http://gizmo.anthill.jp/

スクリーンセーバー作成代行もしているが、基本的にはフォーマットに則ったswfを渡し、スクリーンセーバー化してもらうサービスとのことです。

Web Designing2009年 06月号のP64にHONDA INTERNAVIの事例とあわせてGIZMOのことも少し書いてありました。

特徴

  • いいところ
    • 自動アップデートあり
    • 超大手で使われた実績
  • 残念なところ
    • 高い

      http://gizmo.anthill.jp/service_screensaver_pack/

      • 初期費用 300,000円(税込315,500円)~
      • 月額費用 20,000円(税込21,000円)~

      (パッケージに、スクリーンセーバーにするFlashコンテンツの制作費用は含まれておりません。)

さすが高いだけあって、自動アップデートがついています。不明な点も多く、詳細は問い合わせなければなりませんが、いろいろカスタムできるようです。

簡単には試せないけれど、失敗が許されない状況や、それを凌駕するコンテンツならこれがベストなのでしょうかね。なにより実績があるのでとても安心できそう。

見分け方

  • winだと裏でGIZMOが立ち上がります
  • スクリーンセーバーのインストーラ画面(win)
  • macならsaverファイルの中を見るとGIZMOのフレームワークが入っています。

まとめ fla:verで十分、より安心感を求めるならGIZMO

案件規模にもよるでしょうが、fla:verである程度カバーできるかと思います。自動更新っぽいことも全部外部にすればなんとかなりますね。それ以上の複雑なことになればGIZMO、といったところでしょうか。

僕はこのfla:verで作るようにしています。次回はfla:verにおける制作のポイントをお話します。

あー、まじめに書いたよー、はぁーまじ疲れるわー、あー、あー、うー、う、ウコンー!!

スクリーンセーバーのことシリーズ

Home


Search
Feeds
Meta

Return to page top