てっく煮ブログ

四則演算を JavaScript で実装する

aki note ≫ Google 電話面接を受けました orz （いまは消えてるけど）にて

割り算が壊れました。自分で実装してみてください

という質問が紹介されていた。

せっかく(?)の機会なので、割り算だけでなく、四則演算を全部壊してみて、JavaScript で実装して見ることにした。

JavaScript を選んだのは、コンパイル不要、ビット演算がある、Firebug で手軽に確認できる、という理由から。それ以上の深い意味はない。

ということで、次のような問題に一般化してみた。

問い

四則演算を JavaScript で実装しなさい。

演算子は ==、!= およびビット演算子のみ使ってよいものとします。

補足

例えば、for 文で

for(var i = 0; i < 10; i++){
    // ...
}

と書くためには、< 演算子と ++ 演算子を自前で実装しなきゃならない。

++ 演算子は次のように定義できる。

function increment(i){
    var c = 1;
    while(c){
        if(i & c){
            i &= ~c;
            c <<= 1;
        }
        else{
            i |= c;
            break;
        }
    }
    return i;
}

一番右のビットから見ていって、1 である限りは 0 にしていく。0 ならそのビットを 1 して終わり。桁あふれなら終了、としている。

例を書くと分かりやすいかもしれない。

   01001111
 +)       1
 ----------
   01010000

ソースコード中の while や if の条件式では != 0 を省略している。厳密にはいちいち書くべきなんだけど、めんどくさいし読みにくいので。

加算

前置きが長くなったけど、まずは足し算から。

すごく簡単にやるなら、さっきの increment を使って

function add_simple(a, b){
    while(b){
        a = increment(a);
        b = decrement(b);
    }
    return a;
}

と書いてしまえば終わり。decrement は increment とほぼ同じコードで実装できる。

ただ、この実装だと、b が -1 (0xffffffff) のときに42億回 while 文が回ってしまうのでダメすぎ、実用に耐えなさすぎ。

ということで、改良。

function add(a, b){
    var sum = a;

    while(b){
        var carry = (a & b) << 1;
        sum = a ^ b;

        a = sum;
        b = carry;
    }

    return sum;
}

a ^ b で各桁単独の足し算を取得しつつ、a & b で繰り上げを計算。繰り上げがある場合は、繰り上げ部分を足して、それでも繰り上がればまた足して・・・の繰り返し。

a   01011010
b +)01001001
  ----------
a   00010011 <- a ^ b
b +)10010000 <- (a & b) << 1
  ----------
a   10000011
b +)00100000
  ----------
a   10100011
b   00000000 <- b が 0 なので終了

だいぶ早くなる。

Firebug で試してみる。

>>> add(1, 1)
2
>>> add(99, 1)
100
>>> add(99, -1)
98
>>> add(-3, 5)
2

負の数でもうまく理由が分からない人は２の補数（後述）を勉強してね。

減算

これはだいぶ簡単。

// 正・負を入れ替える
function reverse_sign(a){
    return add(~a, 1);
}

function sub(a, b){
    return add(a, reverse_sign(b));
}

2の補数って知ってる？ で終わり。

2の補数は慣れるまで分かりにくい概念だけど、こう考えてみるのはどうだろう。

• 10進数で12桁の電卓があります
• でも、壊れていて下4桁しか表示できません
• 3 + 9999 は 10002 だけど、この電卓で表示したら 2
• 同じように 5 + 9999 = 4、9 + 9999 = 8
• この壊れた電卓では 9999 は -1 と同じ！？
• 9999 = 10000 - 1
• 10000 を足そうが引こうが表示中の値は変わらない
• 3 + 9999 = 3 + (10000 - 1) = 3 - 1

乗算

次は掛け算。桁あふれは無視してる。

function mul(a, b){
    var product = 0;

    while(b){
        if(b & 1){
            product = add(product, a);
        }

        a <<= 1;
        b >>= 1;
    }

    return product;
}

筆算のやり方を思い出せば簡単。

     1010
   x)0101
   ------
     1010
    0000
   1010
+)0000
---------
  0110010

b の i ビット目が 1 なら、a を i ビット左にシフトしたものを足す、というだけの実装。

上の実装は負の値を無視してしまってるので、まじめにやるならこうなる。

// 正の数かどうか調べる
function is_positive(a){
    return (a >>> 31) == 0;
}

function mul2(a, b){
    if(!is_positive(a) && !is_positive(b)){
        return mul(reverse_sign(a), reverse_sign(b));
    }
    else if(!is_positive(a)){
        return reverse_sign(mul(reverse_sign(a), b));
    }
    else if(!is_positive(b)){
        return reverse_sign(mul(a, reverse_sign(b)));
    }
    else{
        return mul(a, b);
    }
}

is_positive 関数で int が 32bit だと仮定しているあたりがかっこ悪いけど、これが一番シンプルかと。

除算

長かった。いよいよ割り算。Google の電話面接で聞かれるだけあって複雑。

0 での除算や正負は考えずに実装した。

// 比較演算子の代わり
function cmp(a, b){
    var s = sub(a, b);
    return s == 0 ? 0 : is_positive(s) ? 1 : -1;
}

// MSB = 最上位ビット(Most Significant Bit) を取得
function msb(i){
    var ret = 0;
    while(i){
        i >>>= 1;
        ret = add(ret, 1);
    }
    return ret;
}

function div(a, b){
    var quotient = 0;

    if(cmp(a, b) == -1){
        return 0;
    }

    var i = sub(msb(a), msb(b));
    while(is_positive(i)){
        quotient <<= 1;

        if(cmp(a >> i, b) != -1){
            a = sub(a, b << i);
            quotient = add(quotient, 1);
        }

        i = sub(i, 1);
    }

    return quotient;
}

これも筆算をイメージして実装。でも複雑なので説明する体力なし。

もっとスマートな実装はないものか...　もしくはもっとアクロバティックなの。

すごい人達に期待。改良案や別の言語での実装をお待ちしています。

まとめ代わりに種明かし

こうやって記事にすると、私がすごくできる人間に見えるかもしれないけど、実はかなり苦しみました。

そんな中、非常に参考になったのが 基礎から学ぶコンピュータ というサイト。そこに書いてあることを理解して、JavaScript に移植しただけ、といっても過言ではない。

四則演算の実装といえば、コンピュータ・サイエンスの基礎中の基礎なんだけど、そこをちゃんと理解しているか聞いてくる Google 先生はさすが。普段からコンピュータの仕組みを理解した上で使っているかを問われているわけですね。

この辺の内容を基礎から勉強するなら、パタヘネがよいんじゃないでしょうか。

Permalink | コメント(5) | トラックバック(2)

Adobe Edge にコメントが掲載されたよ

10日ほど前、Twitter で むらけん さんが

今Adobe 社に頼まれ、Apollo記事書いてるんですけど、Apolloについてポジティブかつ、具体的な期待とか展望とか一言位の感じで書ける人、書きたい人いますかー？

Twitter / muraken: 今Adobe 社に頼まれ、Apollo記事書いてるん ...

と言っていたのに食いついて、コメントを送ってみました。

で、さきほど、その記事が公開されたようです。

• Adobe Edge: 2007年6月 Adobe Apollo mini Camp@Tokyo レポート

わたしのコメントは最後のほうにあるので、よければ読んでみてくださいませ。

Adobe 公式のメールマガジンに自分の発言が載ったわけで、うれしいような、はずかしいような、申し訳ないような。

Permalink | コメント(0) | トラックバック(0)

第４回 大阪てら子 で学んだ10個の Flash 製作 Tips

タイトルが軽く煽りっぽいですが、行ってきました。Flash 勉強会＠大阪の４回目。

今回は Flash ライブコーディング。

「Flash だからライブオーサリングじゃないの？」と思ってたけど、蓋をあけてみると、大部分がコーディング。Flash 8 はほとんど使わずに、ActionScript だけで SWF が出来上がっていく様子は、軽くカルチャーショックでした。

ソースは [Saq.] 第4回「大阪てら子」まとめ からダウンロードできますよ。

５時間にわたりコーディングしてくださった さくーしゃさん、ありがとうございます。そしてお疲れ様でした。ライブ配信と突っ込みシステムを作った hirossy さん、お疲れ様です。

ということで、今回、学んだポイントを10個にまとめてみましたよ、っと。ちょっと Tips じゃないのも含まれている気がするけど、そこはご愛嬌で。

1. Photoshop からの書き出しは地味

1. 最初に素材の各レイヤーを png に書き出す。
2. それぞれを MovieClip に入れて、インスタンス名をつけていく。
3. MovieClip を下絵に合わせて配置していく。ピクセル単位の細かな作業。

png の書き出し部分では、Flash で画像の外側が崩れるバグに対応するために、

• 偶数ピクセルで書き出す
• 少し幅を広くとる
• MC の右下を中心に配置する

といったバッドノウハウが紹介されました。Flash 8 では問題なくなっている、という話も。

（感想）華やかなアニメーションの裏には、こんなにも地味な下準備があるのか！　CS3 ではだいぶ改善するのかな？

2. タイムラインアニメーションのマスクは手書き

筆で書いていくようなアニメーションはマスクの変形で行う。

マスクは、１フレームずつ手書き。

最後に「フレーム反転」で逆に並び替えて完成。

手書きの方が味がでるし、細かい調整ができるらしい。

3. Flash 8 の出番はここで終了

ここからは Flash 8 は使わず、FDT (Development for Flash) という Eclipse プラグイン上でコーディング。

MC のステージへの配置や、アニメーションの設定は、全て AS2.0 でやってしまいます。

（感想）FDT(Development for Flash) の存在を初めて知りました。199ユーロだそう。(現在の日本円で 32,000円ぐらい)

4. ライブラリはプロジェクトごとに

ライブラリを１箇所にまとめておくと、バージョンを上げたときに、過去の遺産が動かなくなって悲しいので、各プロジェクトのディレクトリにライブラリを展開。

スタティックリンクの感覚に近い。

5. _root を自作クラスに

ステージの１フレーム目には

App.main(_root);

と書いておく。

App.main() の実装は次の通り。

static public function main(target:MovieClip):Void {
    target.__proto__ = App.prototype;
    Function(App).apply(target, null);
}

何をやってるかというと...

• prototype を書き換えることにより、_root を App クラスにしてしまう
• App のコンストラクタが呼ばれたことにする

ということ。__proto__ とか apply あたりは、かなり技術的に込み入ってるので、分からない人は おまじない と考えてもよいかも。

これで準備完了。残りは全部 AS でコーディングできる。

（補足）CS3 からは DocumentClass を設定できるようになるので、こういうバッドノウハウも必要なし。

6. FuseKit でアニメーション

var f:Fuse = new Fuse({...}) 形式でコンストラクタの中に全部書いちゃう。

var f:Fuse = new Fuse(
    { target:this.bg_mc, alpha:100, time:1, easing:'linear' },
    [
        { target:this._memberImg_mc, y:10, time:2, easing:'easeOutCubic' },
        { target:this._mirrorImg_mc, y:130+120, time:2, easing:'easeOutCubic' }
    ]
    { target:this.name_mc, y:135, time:1, easing:'easeOutCubic' },
    { target:this, alpha:0, delay:2, time:0.5, easing:'linear' },
    { scope:_root, func:_root.showAllMembers }
);
f.start();

それぞれの MC は Flash 8 で アルファ 0% にしておくのを忘れずに。

（感想）FuseKit は使い方を覚えたら簡単そうだ。Trick7 さんの Fuseアニメーションの実行順序 が分かりよい。

7. MovieClipUtil.attachMovieRegisterClass() で MC をステージに配置

CASA フレームワークの MovieClipUtil.attachMovieRegisterClass() を使えば、MC とクラスを関連付けてステージに配置できる。

var mc:MovieClip = 
    MovieClipUtil.attachMovieRegisterClass(
        LogoAnimation,    // クラス名
        this,             // 親 MC
        'Logo Animation', // リンゲージ名
        '_logo'           // インスタンス名
    );

１つの MC に対して、複数の実装を割り当てられるわけで、これはちょっと面白い。

attachMovieRegisterClass は、内部で Object.registerClass を呼んでいるようだ。リンゲージプロパティの 「AS 2.0 クラス」をいじる関数の模様。なるほどなるほど。

8. XmlUtil.xmlToObject() で XML をオブジェクトに変換

CASA フレームワークの便利な関数。XML を受け取って、Object にして返してくれる。

var obj:Object = XmlUtil.xmlToObject(this._xmlLoad.getXml())

Perl で言うところの XML::Simple、JavaScript で言うところの JKL.ParseXML みたいなもの。

（補足）AS3.0 には E4X があるから、こういうのは不要かな。

9. LoadGroup 便利

またまた CASA フレームワークから。LoadGroup は URL を複数登録しておいて、まとめてロード、全部読み込み終わったら教えてもらえる。

１〜２個の画像なら手作業でも書けるけど、たくさんの画像を読み込む場合はかなり便利。

var loadGroup:LoadGroup = new LoadGroup();
for (var i:Number = 0; i < info.length; i++) {
    var mc:MovieClip = MovieClipUtil.createEmptyMovieClip(this, 'img' + i);
    loadGroup.addLoad(new MediaLoad(mc, 'images/' + info[i].image, false));
}
loadGroup.addEventObserver(this, LoadGroup.EVENT_LOAD_COMPLETE, 'handleLoadComplete');
loadGroup.start();

10. さくーしゃさんでも、はまる

途中、Saqoosha さんが、うまくいかずに30分ぐらい(?)、はまっていた。

問題解決までのプロセスまで知れるっていうのは、ライブコーディングの魅力。

個人的には、はまっているときが、みんな一番いきいきして見ていた気がする。ああ、さくしゃーさんでもはまることあるんだ、ちょっと安心、みたいな。

最後に...

掲載してるサンプルコードは さくーしゃさん が公開してくれてるソースコード を、ちょっといじって分かりやすくしたものです。

改めて、手の内を明かしてくれた さくーしゃさんに感謝。

(追記) 参加者のレポートが続々と。

hirossy javaとFlex2と。 - 第4回大阪てら子終わりました (hirossy さん)

Flex2＋Red5＋つっこみシステムの裏話。

IDV-DESIGN | 第四回大阪てら子の勉強会 (タケさん)

_root を自作クラスにする方法と HTML テンプレートについて。

gotoand… ≫ 【teraco】大阪てら子　第4回「さくーしゃのFlashライヴコーディング」 (れんさん)

詳細なメモ！　ありがたや。

こういうレポートが、今の倍ぐらいは出てきたら素敵なのになぁ・・・＞参加者各位(笑)

Permalink | コメント(1) | トラックバック(1)

Flasher 必見！　第４回 てら子がライブ中継されるよ

6月17日開催の Flash 勉強会第4回 大阪てら子「さくーしゃのFlashライヴコーディング」 が ライブ中継される ようです。

ライブコーディングしてくれるのは、さくーしゃさん。もはや説明は不要な気もしますが念のため。DARAO の作者でもあり、Web 業界でも超有名な制作会社 AID-DCC Inc. でバリバリに Flash 使ってる方です。

そうそう。ライブコーディングが見たい、との提案をしたのは私です。

というのも、思うところがあってですね、Flash って入門書はたくさんあるんだけど、中級以上の本ってなかなかないんですよね。それはプログラマの業界もそうなんだけど、プログラム業界では誰かが作ったサンプルとか OSS のソースコードがその役割をしてくれてると思うんですよ。

でも、Flash にはそれがない。fla ファイルを見る機会はほとんどないじゃない。製作過程なんてもってのほか。

第２回、第３回てら子で話を聞いてると、フレームワークの話は出たりするんだけど、結局のところどう作るかは共有できてなかったんですよね。それだと、結局みんな自己流でやってる現状は変わらないと思ったので、CSS Nite でやってるような、「ライブコーディング」が見たい、と思ったわけです。

長くなってしまったので強引にまとめると…

すごい人の Flash 使い方に興味がある人は、ライブ中継見てね！　レイヤ構造どうしてるんだろう、FuseKit どう使うんだろう、Flash のカスタマイズはどうしてるんだろう、とか色々参考になるはず。遠隔からの質問も受け付けてるようなので、ばしばし質問・つっこみしちゃってください。

以上。

Permalink | コメント(0) | トラックバック(0)

AIR の app-storage:/ はどこに保存される？

AIR ではアプリケーションの設定を app-storage:/ に保存することが推奨されています。

使い方はこんな感じ。

var file:File = new File("app-storage:/myfile.txt");

もしくは、File.applicationStorageDirectory を使って、次のようにもできます。

var file:File = File.applicationStorageDirectory.resolve("myfile.txt");

file:/ ではなく、app-storage:/ を使うことで、Windows でも Mac でも、ディレクトリ構造を意識せずに設定を保存できるというメリットがあります。

じゃあ、ファイルは一体どこに保存されるかというと...

Windows XP

C:\Documents and Settings\username\Application Data\appId\Local Store

Windows Vista

(2007/6/19修正) C:\Users\username\AppData\Roaming\appId\Local Store

Mac

/Users/username/Library/Preferences/appId/Local Store

だそうです。appId の部分は ADF(Apollo Descriptor File) で指定したものに置き換えてください。（参考：Apollo File Path Gotcha ≫ Brandon Ellis Dot Org、AMOSTYLE2.0 ≫ AIR の app-storage:/ はVistaではどこに保存される？）

例えば、先ほどのアプリケーションの appId が「com.nitoyon.sampleApp」だったとすると、app-storage:/myfile.txt に保存したファイルは XP では

C:\Documents and Settings\username\Application Data\com.nitoyon.sampleApp\Local Store\myfile.txt

に保存されるわけです。

ちなみに、AIR アプリケーションをアンインストールしても、app-storage に保存されたファイルは消えません。ちょっとお行儀は悪いところに注意が必要です。

app-storage と似たものとして、app-resource（もしくは File.applicationResourceDirectory）があります。app-resource は AIR アプリケーションがインストールされたディレクトリを表します。

app-resource にファイルを出力したとしても、アンインストール時に自動的に消えることはありません。

どうやら、アンインストール時には .air パッケージに含まれていたファイルのみを削除している模様です。

Permalink | コメント(0) | トラックバック(0)

Flex 3 beta1 のドキュメントまとめ

Flex Doc Team: Flex 3 Beta 1 (Moxie) Documentation にて、Flex 3 beta 1 のドキュメントファイルがまとめられています。また、AIR:Documentation - Adobe Labs にもまとめられています。

現在、３つの ZIP 形式のファイルが利用できるようです。もちろん、全て英語です。

それぞれの中身を簡単に眺めてみました。

(追記：2007/6/15) HTML 開発者向けのドキュメントの解説を追加しました。また、一部のリンク先が間違っていたのを修正しました。

Flex 3 Beta 1 documentation zip file

html

Programming ActionScript 3.0。
Flex 2 の prog_actionscript30.pdf に相当。HTML ファイル。

langref

Flex 3 と AIR のクラスリファレンス。
なぜかフレームじゃない。

Adobe AIR documentation for Flex developers

Flex を利用して AIR を作る人のためのドキュメント。Flex 開発のドキュメントも含んでいる。

langref

Flex 3 と AIR のクラスリファレンス。
フレーム版。英語。

air_dev_guide_flex.pdf

Flex Builder で AIR を開発するためのマニュアル。
Apollo SDK の HTML が PDF 化。

air_QS_Flex.pdf

クイックスタート。AIR サンプルの解説。
新登場。

flex3_appdev_beta1.pdf

MXML と ActionScript での Flex 開発。
Flex 2 の flex2_devguide.pdf に相当。

flex3_builddep_beta1.pdf

Flex アプリケーションの構築と展開。
Flex 2 の flex2_buildanddeploy.pdf に相当。

flex3_createcomps_beta1.pdf

Flex コンポーネントの作成と拡張。
Flex 2 の flex3_createcomps_beta1.pdf に相当。

UsingFlexBuilder3_beta1.pdf

Flex Builder 2 ユーザーガイド。
Flex 2 の flex2_usingflexbuilder.pdf に相当。

Adobe AIR documentation for HTML developers

HTML+JavaScript で AIR を作る人向けのドキュメント。

Samples

HTML+JavaScript のサンプル。FileSearchHTML、PrefsXMLDemoHTML、TextEditorHTML を含む。

AIR_JavaScript_Lang_Ref_06-07-2007.zip

JavaScript 向けの AIR クラスリファレンス。AIR 専用のクラスを知るにはこちらの方が手っ取り早いかもしれない。

dev_guide_html.pdf

HTML で AIR を開発する方法を網羅的に解説。

QS_HTML.pdf

クイックスタート。サンプルの解説。

Flex 3・AIR(Flex)・AIR(HTML) が分散していて、探し出すのが大変でした。今後は、ドキュメントの場所を分かりやすくしてほしい...

Permalink | コメント(0) | トラックバック(0)

Apollo アプリを AIR β版で動かすための方法

まだ途中のため、中途半端かもしれないけど参考程度に。

(2007.6.13 1:00 追記) Adobe AIRメモ さんが早速 AIR β版に対応しています。すばやい対応！　ここよりも、Adobe AIRメモ さんのほうがお勧め。

1. 開発環境のアップグレード

Flex Builder 2 を使っている人は 3 を、Flex 2 SDK を使っている人は Flex 3 SDK を導入します。

Builder はどうか知らないけど、Flex SDK は共存できるので Flex 2 が必要な人は残しておいたほうがいいでしょう。

2. ADF の修正

ADF(Apollo Descriptor File) と呼ばれるアプリケーションの情報を記述した XML ファイルの仕様が変更になっています。

手順はこう。

• xmlns の apollo/application/1.0.M3 を air/application/1.0.M4 に変更
• properies タグを取り除いて、name や publisher を application 直下に配置

例。

Apollo α版でこうだとすると

<?xml version="1.0" encoding="UTF-8"?>
<application appId="com.nitoyon.sample" version="0.1"
  xmlns="http://ns.adobe.com/apollo/application/1.0.M3">
  <properties>
    <name>application name</name>
    <publisher>nitoyon</publisher>
    <description>sample application</description>
    <copyright>2007 nitoyon</copyright>
  </properties>
  <rootContent systemChrome="standard" visible="true">hoge.html</rootContent>
</application>

AIR β版ではこうするよ。

<?xml version="1.0" encoding="UTF-8"?>
<application appId="com.nitoyon.sample" version="0.1"
  xmlns="http://ns.adobe.com/air/application/1.0.M4">
  <name>application name</name>
  <publisher>nitoyon</publisher>
  <description>sample application</description>
  <copyright>2007 nitoyon</copyright>
  <rootContent systemChrome="standard" visible="true">hoge.html</rootContent>
</application>

あとは、仕様変更になったクラスを使っていなければ、そのままのソースで動くと思います。

再コンパイル(amxmlc)・パッケージング(adl) はまだ試してないので中途半端だけど時間切れ。

Permalink | コメント(0) | トラックバック(0)

Flex3 SDK 速攻レビュー

flex

Apollo は AIR になるのでは？という記事を書いた途端に発表になって焦ってます。

それはそうと、Flex3 SDK を早速落としてみました。

ダウンロード

http://labs.adobe.com/technologies/flex/sdk/flex3sdk.html

AIR（旧Apollo）の開発環境も含まれています。

langref のリンクが見つからなかったが、AIR SDK ダウンロードのページ の「Download Adobe AIR documentation for Flex developers (ZIP, 32 MB) 」に今までの langref に相当するドキュメントが含まれていました。

ファイル構成

今まで、Adobe Labs などで個別に発表してきた技術が SDK に含まれて居ます。

さらに、frameworks フォルダの中には、今まで公開されていなかったソースが公開され始めており、オープンソース化に向けて、着々と準備が進んでいる印象です。

ファイル構成を簡単に覗いてみました。

ant

ant が SDK についてきてます

asdoc

Flex 2.0.1 に引き続き、asdoc 用のファイルが入っています

bin

AIR 用の adl, amxml が含まれて居ます。また、Flex Compiler Shell(fcsh) も同梱されるようになってます。さらに、digest と optimizer も追加されています（詳細まだ調べられていない）。

frameworks

SDK のソースが入っています。ディレクトリ構成が大幅に変わっているので注意。今まであったフレームワークのソースは、frameworks/projects/framework/src に移動しています。
新たに追加されたものは以下のもの：

javascript/fabridge

FABridge のソースコード

project/airframework

AIR の mx 以下のソースコード

flash_integration

Flex Component Kit のソースコード

project/haloclassic

Flex の標準スキン HaloClassic のソースコード

project/utilities/src

現在は ViewSource のソースコードのみ。今後追加される？

rsls

Flex ランタイムのキャッシュが格納されているフォルダ(?)

themes

各テーマのソースコード。６個あるが、サンプルのレベル。

lib

bin フォルダの実行ファイルが内部で参照する *.jar ファイル。

samples

Flex 2 のサンプルと同じ。手が回らなかったか。

runtimes

Flash Player のβ版。Flex3 の機能をフルに活用するためには、この Flash Player を使う必要があります。

Permalink | コメント(0) | トラックバック(0)

Apollo の正式名称は Air？

Apollo というのは実は開発コードで、正式名称はまだ発表されていません。

この記事を公開した数時間後に、akihiro kamijo: Adobe Apollo 改め Adobe Integrated Runtime (AIR) パブリックベータ開始 というように、正式に AIR と発表されました。ということで、この予測は大正解でした。

β版の発表と共に正式名称も発表になるのでは？という話だったのですが、ここにきて、この正式名称が 「Air」になるのではないか、という噂が流れ始めています。

根拠１．Adobe Apollo Developers Night の仮登録書

Adobe Apollo Developers Night に申し込みをしたユーザーからの声によると、自動返信メールのタイトルが

『Adobe Air Developers Night』仮登録完了書

だったようです。

根拠２．Ted さんブログの中途半端なぼかし

Flex 3 の新機能を紹介する Ted On Flex: Flex 3 - Friday: Apollo という記事のスクリーンショットにぼかしが入っています。そして、ぼかしについて「そのうち、ぼかしの理由が分かるはず」と書いてあります。これは、正式名を隠しているとしか考えられません。

このぼかし、現在は修正されていますが、最初のころはかなりいい加減でした。いい加減なときのスクリーンショットが The Warp: New name for Apollo... に掲載されています。

うっすら、Adobe AIR Project と読めませんか？

根拠３. それっぽい名前

AIR という名前のそれっぽい理由が考えられます。

Apollo の配布ファイル形式が .air

Apollo α版の配布ファイルは air という拡張子なのですが、これが何の略なのかは誰も知りません

RIA のアナグラム

RIA を逆から読むと、AIR。ばんざーい。

空気のように普通だけど大事な存在

という期待をこめて…。

おわり

誤報だったらすみません。

ちなみに、Apollo の前には Macromedia 時代に ２度の失敗があり、そのコードネームは Mercury、Gemini というものでした。どれもアメリカの有人宇宙飛行計画の名前に由来しています。（参考：Adobe Edge: Apolloの原点）

２度の失敗の後、ついに Apollo で空中（air）に飛び出した、と考えると感慨深いものがあります。

個人的には Apollo に慣れちゃったので、Apollo の方が愛着あります…。

Permalink | コメント(0) | トラックバック(0)

Flex 3 の新機能が続々発表中

flex

Adobe エバンジェリストの Ted さんのブログ Ted On Flex にて、Flex 3 の新機能が続々紹介されていっています。

Flex Builder 3 のデザイナ向け新機能

Monday: Designer/Developer Workflow

Flex Builder 3 の開発者向け新機能

Tuesday: Code Enhancements

Flex SDK 3 の新機能

Wednesday: Components and SDK Enhancements

Flex Framework 3 のキャッシュ機構

Thursday: Dramatically Smaller Flex SWF Files

Flex 3 と Apollo

Friday: Apollo

これらの記事を簡単に日本語訳して、FxUG に投稿してます。

• http://www.fxug.net/modules/xhnewbb/viewtopic.php?viewmode=flat&topic_id=936&forum=18

ブログの記事にしてもいいかも！というぐらいの密度で書いてるので、ぜひご覧ください。

今のところ、気になる新機能は

• Flex Builder 3 のリファクタリング機能
• Flex SDK 3 での DataGrid 強化
• Flex Framework のキャッシュ機構と別ドメインからのライブラリ取得

といったところです。

そのうちまとめる（かも）。

Permalink | コメント(0) | トラックバック(0)

Google Gears 発表前と発表後のオフライン事情

先日の Google Gears の使い道 という記事用に既存のオフライン技術についてまとめていたのですが、長くなったので割愛してしまいました。とはいえ、もったいないので別エントリの形で公開します。

紹介するのは３つのオフライン技術と、それぞれの Google Gears への反応です。はじまりはじまり。

Dojo Offline

オフライン機能をいち早く実装したのは Dojo Offline というライブラリです。

Dojo という名前からも分かるように、JavaScript ライブラリ「Dojo」の Dojo.Storage という機能を活用して実装されているようです。Dojo.Storage は Cookie・SharedObject・ActiveX File API・XPCOM File API などの中から適切なものを選ぶ、という実装のようです。

Google Gears の発表を受け、Dojo Offline は Dojo.Storage を使うのをやめ、Google Gears を使うように修正する、と発表しています。また、この作業は Google と協力しながら行うことも明言されています。（斜め読みなので少し間違えているかも）

参考リンク：

• The Dojo Offline Toolkit の News
• Audible Ajax Episode 21: Dojo Offline on Google Gears）

Firefox 3

Firefox 3 では目玉機能としてオフライン機能が実装されます。

Firefox 3 のオフライン機能って何だ？ （えむもじら）が詳しいです。

Google は Firefox に Google Gears を組み込むことを提案しています。これに対し、Firefox の開発陣は「現在実装中のオフライン機能をそのまま使うか、Google Gearsを使うかは未定」と発言しているようです。（参考リンク：(6/3) Firefox 3 と Google Gears）

Apollo

Google Gears と微妙にかぶっていて、でも、微妙に違うのが Apollo です。

Google Gears の３つの機能は Apollo では次のように対応します。

LocalServer

Apollo の air ファイルによるパッケージングと同じと考えられます。Apollo は前もってダウンロードしますが、Google Gears は動的にダウンロードすることになります。

Database

Apollo β版に同等のものが実装されることが発表されています。

WorkerPool

Apollo には該当する機能はないため、Google Gears の有利な点となります。

Apollo にしかない機能としては、

• ローカルファイルへのアクセス
• クロスドメインのネットワーク接続
• ブラウザから独立したクロスプラットフォーム性
• １つのアプリケーションとして見える

と、色々思いつきます。

とはいえ、Google Gears と Apollo は完全には競合はしません。

状況に応じて、Apollo の中から Google Gears を使う、Google Gears の中から Flash を使う、といったように、お互いのいいところをつまみ食いできる関係にあります。

まとめ

３つの技術と Google Gears 側が協力関係を結ぼうとしているのが面白い。Google Gears がオープンソースなところからも分かるように、Google Gears の立場は「みんな、一緒にオフライン技術を作っていこうよ！」というものなのでしょう。

蛇足となりますが、オフライン機能を持ったサービスとしては Zimbra on your Desktop が挙げられます。インストール型でローカルサーバー・DB を持つ構造は Google Gears と同じのようです。

詳しくは、Zimbra Desktop、ローンチ―オンラインの機能をフルに移植（TechCrunch Japanese）で分かりやすかったです。日本では Zimbra はサイボウズの子会社フィードパスと組んで普及を狙っているようです。

Permalink | コメント(1) | トラックバック(0)

Google Gears の使い道

Google Gears (BETA) が発表されました。

Google Gears はウェブサービスにオフライン機能を付け加えやすくするためのフレームワークです。

フレームワークが提供するのは次の３つの機能です。

LocalServer

オフラインになったときにも HTML や JavaScript、CSS にアクセスできるようにする。ブラウザのキャッシュ（一時ファイル）を強化したイメージ。

Database

オフライン時に行った動作を記録しておく。SQLite ベース。ブラウザの Cookie を大容量化したイメージ。

WorkerPool

CPU を消費する機能をバックグラウンドで実施する機能。setTimeout で無理やり細切れに実行していた部分を任せることができる。スレッド機能とも考えられる。

開発者は、これら３つの機能を駆使して、オフライン機能を実装することになります。

ありがちな実装パターンはこうなるでしょうか。

• LocalServer を使ってオフライン時にも必要なファイルが手に入るようにする
• オフライン時に行われた変更はサーバーには投げずに、Database に保存
• オンラインになったときに、WorkerPool を使って Database に蓄えたオフライン中の処理データをサーバーに送信

素朴な疑問：オフライン機能って必要？

利用者の立場から考えて見ます。

オフラインのときにも使いたくなるサービスって何があるでしょうか。RSS リーダーや GMail、Google Docs & Spreadsheets…。ここまで挙げたあと、続きが思いつきません。

日曜プログラマが開発するようなちょっとしたアプリケーションでは、オフライン機能を使いたくなるところまでいかないと思います。

また、オフライン中の操作を Database に保存したり、オンラインになったときに送信したりする部分の実装はかなり煩雑です。

ばっさり言ってしまえば、ユーザーからの需要は少ない上に、実装コストが高いのです。

では、Google Gears は不要な技術なのでしょうか。

いいえ、実は超絶に魅力的です。

３つの機能を単体利用するだけでも、実装効率は格段によくなりそうです。

１つ１つ説明していきます。

LocalServer はブラウザキャッシュをコントロールするための技術

ブラウザのキャッシュ（一時ファイル）は、キャッシュする条件がブラウザによってことなるなど、アプリケーション側から完全にコントロールするのは不可能でした。

それを Google Gears の LocalServer 機能で解決します。

例えば、こんな使い方はどうでしょう。

• 初回ロード時に読み込んだファイルを LocalServer にキャッシュする
• 次回ロードからは、LocalServer のファイルを利用してロードする → 表示の高速化
• ロードが完了して落ち着いたころを見計らって、サーバーにアップデート確認
  • 更新があった場合には、その場でページを書き換えてもいいが、何もしなくてもいい。既存のブラウザも、キャッシュがある場合には手動でリロードして初めてサーバーにとりに行く実装になっている。
• 次に読まれそうなデータを先読み（ページ遷移があっても大丈夫!!!）

重要なのは、アプリケーション側からブラウザのキャッシュを完全にコントロールできることです。

Database は SQL ベースの大容量 Cookie

現状のブラウザベースのアプリケーションでは、ちょっとした設定データやセッションデータを Cookie に保存します。

しかし、Cookie には 4KB 容量制限が重くのしかかります。

この制限を克服するために、Flash の SharedObject や、DOM Storage（Firefox only）、userData（IE only）を利用する といったバッドノウハウがあるのですが、インターフェースもばらばらな上に、環境依存の問題も併発してしまいそうで、なるべくなら使いたくないのが現状でした。

そこで、Google Gears の Database です。

大容量な上に、検索も SQL ベースで高速なのです。

また、Apollo β版にも Gears の Database と同様に SQLite ベースのデータベースが付属することが決まっています。

Adobe の中の人のブログによると、Google Gears と Apollo はこの部分で連携していくようです。

Apollo アプリでもウェブアプリでも、同じようにローカル DB を使えるようなインターフェースがあったら便利だよね。Adobe と Google は、そのインターフェースを連携しながら考えていくよ。

I meant to add that we are working on aligning the Apollo DB and Gears DB apis, with the goal of making it easier to build applications and code that can leverage both API implementations (on the desktop and in the browser).

Apollo Beta will include SQLite Embedded Database at Mike Chambers

Google と Adobe の連携話からも SQL ベースのローカルストレージが流行っていくような予感がします。

WorkerPool で setTimeout 地獄からの開放

JavaScript の実装をしていると、ちょっと複雑な処理が入ると、ブラウザが応答しなくなり、CPU 使用率が 100% になってしまいます。

これを解決するためには、実装すべき機能を細切れにして、setTimeout で呼び出さなければなりませんでした。

しかし、ソースの可読性が下がってしまうため、あまりやりたくない手段です。

そこで、Google Gears の WorkerPool です。

思い処理を WorkerPool に任してしまって、バックグラウンドで処理してもらいます。ついに、JavaScript でスレッドを手に入れられるのです。

まとめ

• Google Gears をオフライン機能のために利用するのではなく、それぞれの機能を個別に活用する。
• いままで制御できなかった部分や、泥臭かった部分をすっきり実装できるようになる。
• それだけでも、かなり魅力的。

Permalink | コメント(0) | トラックバック(0)