GAEの新料金体系で、インスタンス課金がどうしても気に入らない（※）ため、Herokuに乗り換えようかと画策中。
※
だってね、インスタンスはほぼ１日中１個（時々０個か２個）上がってるから、インスタンス使用時間は約24H/Dayなんですが、CPU時間で見ると0.1%くらいしか使ってないわけですよ。それでも継続的にリクエストが来るからインスタンスが上がりっぱなだけで。
CPU使ってないんだからもったいないなあ、、、というのが正直なところ。まあ、メモリは食ってますけどね。
なんだけど、Herokuにアプリを登録するのは、rubyで動くherokuコマンドをインストールする必要があり、gitも必要です。あと、サンプルを動かすためにrailsなんかも必要で、gemから入れようとしたら失敗するし（Windowsだから、という原因もある）、どうすりゃいいんだわたしゃ、と思っている次第。
まあ、railsはgemで入れんでも良いような気がするが、誰か楽なHerokuの始め方を教えてくれー。
ただ、GAEの新料金のネック（Push It!における）はもう一つ、Channel数の制限があるんですが、
Herokuにしたところで、WebSocket（GAEだとChannelにあたる。Channelの方が対応環境が多いが）は標準では対応してなくて、Pusherというアドオンを入れると使えるんだけど、無料だと20connectionまでって、それGAEのChannel数制限と大差ないから！ということに気づく。
無料だと・・・どこ行ってもキツイね・・・。そらそうなんだが。
2011年11月30日水曜日
2011年11月19日土曜日
Datastoreのunittest(Python)
HRDネタが続いてますが、GAEの公式ドキュメントに、
http://code.google.com/intl/en/appengine/docs/python/tools/localunittesting.html#Writing_HRD_Datastore_Tests
こんな記事があるのを見つけました。
unittestのための記事なんですが、Eventual Consistencyな状態を、指定した条件で疑似れる模様。まだ使ってませんが。
あら素敵じゃない。HRDそのものはxx（←自粛）ですが・・・。
でもな〜、ドキュメントこれだけ？リファレンスは？ここに書いてあることが全部？
う〜ん・・・。
http://code.google.com/intl/en/appengine/docs/python/tools/localunittesting.html#Writing_HRD_Datastore_Tests
こんな記事があるのを見つけました。
unittestのための記事なんですが、Eventual Consistencyな状態を、指定した条件で疑似れる模様。まだ使ってませんが。
あら素敵じゃない。HRDそのものはxx（←自粛）ですが・・・。
でもな〜、ドキュメントこれだけ？リファレンスは？ここに書いてあることが全部？
う〜ん・・・。
2011年11月10日木曜日
High Replication Datastoreの扱いに困る話
第一章 はじめに
前回のエントリで書いたように、GAEのPython2.7で使えるDatastoreは、High Replication Datastore(HRD)というやつ一択で、こいつの扱いが難しいのに困っている。
具体的には、クエリの整合性が担保されないということなのだそうな。
・キーを使ったアクセスは「問題なし」
・祖先クエリ（Entityの親子関係を使ったクエリ）は「問題なし」
・その他のクエリは「過去の状態に基づく結果が返る可能性がある」
なので強い整合性を必要とする場合、memcacheやら何やらを駆使して、解決せよ、というのがGoogle始め、各人の御宣託なのであるが、しかし、memcacheも消えることがあるのだし、どうしようか。というお題である。
第二章 解決策
そこで考えたのが、- Datastoreへのアクセスをラッパーするクラスを作って、書き込み時はmemcacheにも必ず書き込む。
- クエリは、ラッパーを経由することで、Datastoreに対する検索結果とmemcacheのデータをマージして返す。
- クエリもパターン化されているなら、クエリの結果もキャッシュしておく。
- と、そこまでやってもmemcacheは消えることもあるので、Datastore操作ログをDatastoreに残す。ログは全数にアクセスできないといけないので、Key名はプログラム的に推定可能なものを採用する。
第三章 問題点
よし。ここまでやりゃ大丈夫か。いや、トランザクションとか使うともっとややこしいことになるが。ただ、機能的には大丈夫なんだが、問題もある。
- 「Datastoreに対する検索結果とmemcacheのデータをマージ」するコスト（CPU時間）がバカにならない気がする。
- 特にmemcacheデータが増えてきた場合。
- なので、memcacheを定期的に捨てないといけないのだが、Datastoreへのクエリがいつになったら整合性が取れるのか分からないので、捨て時がわからない。
- あるクエリの実行結果がmemcacheと一致するなら「そのクエリに関しては」整合性が取れたと言えるのだろうが、別のクエリでも一致するとは限らない（と思う）ので完全に整合性が取れたと言い切れるタイミングが図れない。
- Datastore操作ログもmemcacheと同様に捨て時がわからない。
第四章 HRDで整合が取れるまでの時間とは
で、実際HRDで整合性取れるのってどのくらいかかんのよ、ってことで実験してみたよ。
- Datastoreにput()する
- 直後に「put()したデータだけ」がひっかかるはずのクエリを投げる
- 引っ掛かった件数が1なら整合、それ以外なら不整合と判定する
ん～、データが軽すぎるのかも知れない。プロパティ数が数個かつエンティティ数も100件程度じゃ、あっという間にインデックスが構築されてしまう模様。
じゃ、プロパティを26個まで増やし、エンティティ数も1000件程度の状態まで持って行ったらどうか。
結果：数百回試して1回だけ0件となった。
なるほどね・・・。
スクリプト言語であるPythonごときの処理速度では、インデックス構築完了より先にクエリは投げられんよ、と、そういうことか？
てーことは、何？上に書いたような対策は杞憂なの？やりすぎなの？
でもさー、保証されてないんだから考えちゃうよね、そりゃ。
第五章 終幕
とかって実験しているうちに、Over Quotaとなった。。。
新料金体系では、無料枠は
Datastore Write Operations : 0.05 Million Ops
となっているので、Write Opsは5万回まで。
Write Opsってput()とdelete()の回数ですか？って甘かった。
put()/delete()の際のインデックスの更新もWrite Opsに含まれるんだってよ、奥さん！
インデックスは、Keyと、プロパティ１個１個に対して昇順と降順のインデックスが作られるので、
・データそのもの(1)
・Key用インデックス(1)
・プロパティの昇順、降順（プロパティ数 x 2）
だけのWrite Opsが発生するんだって！一回のput()で！
上記の実験では26個のプロパティを用意したので、一回当たり 1 + 1 + 26 * 2=54 Ops
5万 ÷ 54 ＝ 約1000
そう。たった1000回(未満)のput()でOver Quotaなのであった。
なーんーだーよー。
ろくろく実験もできねーじゃねーか。
なんかもー、こんな対策考えてる時点でベンダーロックインされまくってる弊害がありありだし、別に安くもなくなっちゃったし、もうGAEやめちゃおっかな、とか思うんだが・・・。
2011年11月1日火曜日
【備忘録】 GAEでPython2.5からPython2.7へマイグレーションするには
まだ途中なんだけど、GAEがPython2.7に対応した（但、experimental）。
Python2.7になると何が嬉しいかって、新料金体系で制限が厳しくなったインスタンス起動時間の制限を、スレッドの利用によって回避できる（かも？）なこと。
ちゅうことで、今はPython2.5で作られているPush It!サーバをPython2.7化しようと目論見中なのだが、若干はまったので、備忘録としておく。
とりあえずこの辺とかこの辺とかは読んどくこと。必要なことは多分ここから全部たどれる。
①アプリケーションの新規作成
Python25で作ってあるアプリケーションをPython27に変更できるかどうかは調べていないので不明だが、少なくとも現状DatastoreをMaster/Slaveにしている場合は、Python27だとHigh Replication一択なので、新規に作成しておく必要がある。
②app.yamlの変更（その１）
とりあえず、以下は必須だ。
①でアプリケーションを新規作成した場合はapplicationも変更しておこう。
それから、後でも良いが、スレッドを使いたい場合は、
ただし、threadsafeでないライブラリを使ってない場合は実行時に怒られるぞ。 アプリがthreadsafeかどうかは実装次第なのでそこは自前で頑張ること。
Djangoを使っている場合は、
③webapp2を使用するように変更する
webappフレームワークがwebapp2となりましたのでimportするモジュールを変更する。
が、しかし、Python27 on GAE環境ではwebappという選択肢がないので、webappモジュールはwebapp2へのエイリアスとなっている。
従って、結論としては変更の必要なし。
④とりあえずサーバにアップしてみよう
尚、Python27版のSDKは「ない」。ローカルでテストできないので必然的にサーバにアップしてテストすることになる。
アップロードの仕方は以前と変わりなし。
で、エラーになった。
app.yamlで怒られる。CGI Handlerはthreadsafeではありません、とな？
ここをよくよく見てみよう。
script: main.app
と書いてあるでしょう。
紆余曲折ありつつも、これは、main.pyのappという変数にマッピングすることを意味しているらしいことが分かる。なので、以下に続く。
⑤app.yamlの変更（その２）
④に書いた通り、
appが予約語なのか、main.pyのWSGIApplicationのインスタンスを指す変数名ならなんでも良いのか、は不明。
⑥ハンドラスクリプトの修正
③に書いた通り、webappほげほげのimportはエイリアスが張られているので変更不要。
変更が必要なところは、ここに書いてある。
要するにmain関数が不要になり、WSGIApplicationのインスタンスをappという名前の変数に格納する、ということ。
⑦サーバにアップロードする（２回目）
さあ、これで準備は整いました。
アップロードして、アクセスしてみよう。
よほど特殊なことをしていない限りは多分、それなりに動くはず。
⑧Django1.2対応
⑦でそれなりに動くことは動くんだが、Djangoのバージョンが0.96から1.2に変わっている影響で、templateモジュールに若干の変更あり。
テンプレートに埋め込む変数値が、0.96ではデフォルトではエスケープされないところ、1.2ではデフォルトでエスケープされるようになった。
なんらかの理由によりスクリプト側から既にエスケープした状態の値をテンプレートに渡している場合、二重にエスケープされることになるので、
みたいな感じで書いてあげること。
あと、HTMLタグを含む値（などのHTML的に意味のある値）を、HTMLタグとして埋め込みたい場合とかね。
⑨High Replication Datastoreへの対応
普通のアプリケーションなら⑧までやれば、それなりに動くようにはなるので、Python27化はそれほど高い敷居ではありません。
さて、問題はこれです。
従来、GAEのDatastoreはMaster/Slave（MSD）という構成でした。
MSDは１年ちょっと前にトラブルが続発していたことがあり、その反省から生まれたのが、High Replication Datastore（HRD）です。
以降、GAEでアプリケーションを新規作成する際には、MSDかHRDのどちらかを選ぶことができるようになりました。ですが、そのアプリケーションでは新規作成時以外ではDatastoreを変更することはできません。
どちらを選ぶべきか、は、この辺に書かれているのですが、気になるのは、
意訳すると、データの一貫性は保たれるが、インデックスの一貫性は保証できねー、ということらしい。インデックスを使わない（つまりクエリーを使わない）で、キーなどを使ってデータに辿りつける場合は無問題。クエリー使うと、最新でない結果セットが取れちゃうかもよ、てなことだそうだ。
情報系（ブログとかニュースとか）などのサイトであれば、多少結果が古かろうと「まあいいよね？」で済むと思うんだが、Push It!はしかし、そうではない。一貫性が保証されないと、クライアントとの同期が維持できない。
困ったことだよ・・・。
回避策としてはmemcacheの利用などが挙げられているものの、memcacheって揮発性だから、なくなっちゃった状態から、どうやって「最新と保証できる」memcacheを構築できるのか、全く思いつかない。
全ての情報がキーから辿れるなら（そしてそのキーが可知であれば）問題ないですけど、そんな風には作ってないわけで・・・。
しかし、今回のブログはリンクいっぱい埋め込んだな・・・。情報分散しすぎなんだよ・・・。
Python2.7になると何が嬉しいかって、新料金体系で制限が厳しくなったインスタンス起動時間の制限を、スレッドの利用によって回避できる（かも？）なこと。
ちゅうことで、今はPython2.5で作られているPush It!サーバをPython2.7化しようと目論見中なのだが、若干はまったので、備忘録としておく。
とりあえずこの辺とかこの辺とかは読んどくこと。必要なことは多分ここから全部たどれる。
①アプリケーションの新規作成
Python25で作ってあるアプリケーションをPython27に変更できるかどうかは調べていないので不明だが、少なくとも現状DatastoreをMaster/Slaveにしている場合は、Python27だとHigh Replication一択なので、新規に作成しておく必要がある。
②app.yamlの変更（その１）
とりあえず、以下は必須だ。
-runtime: python +runtime: python27
①でアプリケーションを新規作成した場合はapplicationも変更しておこう。
それから、後でも良いが、スレッドを使いたい場合は、
+threadsafe: trueも付けておこう。
ただし、threadsafeでないライブラリを使ってない場合は実行時に怒られるぞ。 アプリがthreadsafeかどうかは実装次第なのでそこは自前で頑張ること。
Djangoを使っている場合は、
+libraries: +- name: django + version: "1.2"こんなのもいるのだが、しかし、google.appengine.ext.webapp.templateとしてDjangoのTemplate機能のみを使っている場合は不要っぽい。
③webapp2を使用するように変更する
webappフレームワークがwebapp2となりましたのでimportするモジュールを変更する。
が、しかし、Python27 on GAE環境ではwebappという選択肢がないので、webappモジュールはwebapp2へのエイリアスとなっている。
従って、結論としては変更の必要なし。
④とりあえずサーバにアップしてみよう
尚、Python27版のSDKは「ない」。ローカルでテストできないので必然的にサーバにアップしてテストすることになる。
アップロードの仕方は以前と変わりなし。
で、エラーになった。
app.yamlで怒られる。CGI Handlerはthreadsafeではありません、とな？
ここをよくよく見てみよう。
script: main.app
と書いてあるでしょう。
紆余曲折ありつつも、これは、main.pyのappという変数にマッピングすることを意味しているらしいことが分かる。なので、以下に続く。
⑤app.yamlの変更（その２）
④に書いた通り、
-script: main.py +script: main.appてな感じに修正する（mainはあくまで例。任意のハンドラスクリプト名に置き換える）。
appが予約語なのか、main.pyのWSGIApplicationのインスタンスを指す変数名ならなんでも良いのか、は不明。
⑥ハンドラスクリプトの修正
③に書いた通り、webappほげほげのimportはエイリアスが張られているので変更不要。
変更が必要なところは、ここに書いてある。
要するにmain関数が不要になり、WSGIApplicationのインスタンスをappという名前の変数に格納する、ということ。
⑦サーバにアップロードする（２回目）
さあ、これで準備は整いました。
アップロードして、アクセスしてみよう。
よほど特殊なことをしていない限りは多分、それなりに動くはず。
⑧Django1.2対応
⑦でそれなりに動くことは動くんだが、Djangoのバージョンが0.96から1.2に変わっている影響で、templateモジュールに若干の変更あり。
テンプレートに埋め込む変数値が、0.96ではデフォルトではエスケープされないところ、1.2ではデフォルトでエスケープされるようになった。
なんらかの理由によりスクリプト側から既にエスケープした状態の値をテンプレートに渡している場合、二重にエスケープされることになるので、
somevariable|safe
みたいな感じで書いてあげること。
あと、HTMLタグを含む値（などのHTML的に意味のある値）を、HTMLタグとして埋め込みたい場合とかね。
⑨High Replication Datastoreへの対応
普通のアプリケーションなら⑧までやれば、それなりに動くようにはなるので、Python27化はそれほど高い敷居ではありません。
さて、問題はこれです。
従来、GAEのDatastoreはMaster/Slave（MSD）という構成でした。
MSDは１年ちょっと前にトラブルが続発していたことがあり、その反省から生まれたのが、High Replication Datastore（HRD）です。
以降、GAEでアプリケーションを新規作成する際には、MSDかHRDのどちらかを選ぶことができるようになりました。ですが、そのアプリケーションでは新規作成時以外ではDatastoreを変更することはできません。
どちらを選ぶべきか、は、この辺に書かれているのですが、気になるのは、
- Python2.7ではHRDしか選択肢がない（GoogleさんはMSDを捨てたい、と思っているのでしょう）
- Consistency（日本語にすると一貫性とか整合性、かな？）の「Most Queries」がStrongからEventualになっている。
意訳すると、データの一貫性は保たれるが、インデックスの一貫性は保証できねー、ということらしい。インデックスを使わない（つまりクエリーを使わない）で、キーなどを使ってデータに辿りつける場合は無問題。クエリー使うと、最新でない結果セットが取れちゃうかもよ、てなことだそうだ。
情報系（ブログとかニュースとか）などのサイトであれば、多少結果が古かろうと「まあいいよね？」で済むと思うんだが、Push It!はしかし、そうではない。一貫性が保証されないと、クライアントとの同期が維持できない。
困ったことだよ・・・。
回避策としてはmemcacheの利用などが挙げられているものの、memcacheって揮発性だから、なくなっちゃった状態から、どうやって「最新と保証できる」memcacheを構築できるのか、全く思いつかない。
全ての情報がキーから辿れるなら（そしてそのキーが可知であれば）問題ないですけど、そんな風には作ってないわけで・・・。
しかし、今回のブログはリンクいっぱい埋め込んだな・・・。情報分散しすぎなんだよ・・・。
2011年10月5日水曜日
【備忘録】 AIR1.5以前で作ったアプリをそれ以降に移植するには
直前のエントリでAIR1.5で作ったアプリをAIR2.6にしようとしたら、バージョンアップ扱いにならなくなった件を書きましたが、解決。
この辺を参考に（FxUGさんありがとう！）、この辺を見たら解決。
要するに1.5以前で作ったアプリを2.0以降にバージョンアップさせる場合、アプリケーション記述ファイルにpublisherIDが必須なんだと。
知るかそんなもん！と思ったがFxUGって頼りになるわ～と思った。
ただ、それはそれとして、今まではapp-storageが指す先のディレクトリが、
この辺を参考に（FxUGさんありがとう！）、この辺を見たら解決。
要するに1.5以前で作ったアプリを2.0以降にバージョンアップさせる場合、アプリケーション記述ファイルにpublisherIDが必須なんだと。
知るかそんなもん！と思ったがFxUGって頼りになるわ～と思った。
ただ、それはそれとして、今まではapp-storageが指す先のディレクトリが、
- adlから起動した場合（デバッグに使用） - application idそのもの
- インストールして起動した場合 - application id+publisherID
2011年10月3日月曜日
【備忘録】 AIRのHTMLLoaderは画面に表示しなくても使える
AIRをFlexスタイルで開発している、、、んだけど、世の中にはJavascriptの有用なライブラリがいっぱいあって、ActionScriptにはない、からJavascriptの部分だけ使いてーよー。という場合。
Javascriptを処理させるにはHTMLLoaderにJavascript（を含むHTML）ソースを食わせると良い。
HTMLLoader君は画面表示のための機能がいろいろあったりする（HTMLLoaderはDisplayObjectContainerを継承している）ので、表示しないと使えないかと思いきや、実はnewして、URLをloadさせてあげるだけでJavascriptは実行される。ナイス。
当然、AS側からコントロールできないと意味ないのでブリッジを作ってやる必要があるのだが、それもごく簡単。
AS側からJS関数を叩くなら、
var html:HTMLLoader = new HTMLLoader;
（・・・load・・・とか）
（completeイベント以降で）
html.windows.someJsFunc(x,y,z);
とかやるだけ。要はhtml.windowがJS側のグローバルスコープそのものになっている。
（ので、おなじみのgetElementByIdもAS側から呼べるぞ）
一方JS側からAS側の関数をコールバックさせたいなら、
var html:HTMLLoader = new HTMLLoader;
（・・・load・・・とか）
（domInitializeイベント以降で）
html.windows.someJsFunc = someAsFunc;
とかやっておけばよろしい。html.windowはリードオンリーではなく、オブジェクトの注入も可能だ。
JS側でsomeJsFuncを叩くと、AS側のsomeAsFuncが呼ばれる仕組み。
散々公式ドキュメント読んだんだけど、全然わからなくて泣いた。
上のを知ってからHTMLLoader.windowの説明を読むと「あ、そういうことですか」と合点が行くのだが・・・。
Javascriptを処理させるにはHTMLLoaderにJavascript（を含むHTML）ソースを食わせると良い。
HTMLLoader君は画面表示のための機能がいろいろあったりする（HTMLLoaderはDisplayObjectContainerを継承している）ので、表示しないと使えないかと思いきや、実はnewして、URLをloadさせてあげるだけでJavascriptは実行される。ナイス。
当然、AS側からコントロールできないと意味ないのでブリッジを作ってやる必要があるのだが、それもごく簡単。
AS側からJS関数を叩くなら、
var html:HTMLLoader = new HTMLLoader;
（・・・load・・・とか）
（completeイベント以降で）
html.windows.someJsFunc(x,y,z);
とかやるだけ。要はhtml.windowがJS側のグローバルスコープそのものになっている。
（ので、おなじみのgetElementByIdもAS側から呼べるぞ）
一方JS側からAS側の関数をコールバックさせたいなら、
var html:HTMLLoader = new HTMLLoader;
（・・・load・・・とか）
（domInitializeイベント以降で）
html.windows.someJsFunc = someAsFunc;
とかやっておけばよろしい。html.windowはリードオンリーではなく、オブジェクトの注入も可能だ。
JS側でsomeJsFuncを叩くと、AS側のsomeAsFuncが呼ばれる仕組み。
散々公式ドキュメント読んだんだけど、全然わからなくて泣いた。
上のを知ってからHTMLLoader.windowの説明を読むと「あ、そういうことですか」と合点が行くのだが・・・。
【備忘録】 AIR1.xから2.xへの切替
AIR1.xで作っていたアプリを2.x対応にするために、アプリケーション記述ファイルを書き換えて再コンパイル・・・するだけだとコンパイルエラーになる。
難しいことは良く分からないのだが、テーマとかいうのがHaloからSparkになったからなんだって！
今までmxmlファイルで「mx:ほにゃらら」としていたところを「s:ほにゃらら」にしなきゃいけなくって大変だ、というものぐささん（ていうか自分）の場合は、Haloを使い続けることもできる。
そういうものぐさ野郎はここを見て2.xでHaloを使い続けられるようにすべし。
難しいことは良く分からないのだが、テーマとかいうのがHaloからSparkになったからなんだって！
今までmxmlファイルで「mx:ほにゃらら」としていたところを「s:ほにゃらら」にしなきゃいけなくって大変だ、というものぐささん（ていうか自分）の場合は、Haloを使い続けることもできる。
そういうものぐさ野郎はここを見て2.xでHaloを使い続けられるようにすべし。
2011年9月22日木曜日
FlashDevelop
一個前のエントリでさらっと書いたけど、現在AIRアプリの開発環境としてはFlashDevelopを使ってます。
これがとても優秀です。
私が今まで使ってきた開発環境は、
1～3はどれもEclipseなんですが、重いんですよね（あくまで私の環境では、ですが）。
さらに2,3は今時の開発環境としてはチープで、コーディング以外はほとんどコマンドラインでやってました。
で、今使ってるFlashDevelopなんですが、
Push It!クライアントはGUIはそんなに必要ないんで、上の３つがあるだけで満足。いや、大満足。
もっと早く使っとくべきだった～。
Eclipseベースで重いことを除けばAIR GEARも期待してたんですけど（GUIビルダーも付いてるしね）、開発が止まっちゃってるみたいで、残念。
これがとても優秀です。
私が今まで使ってきた開発環境は、
- FlexBuilder（現FlashBuilder）のトライアル試用⇒Eclipseベース
- 素のEclipse＋Flex/AIR SDK（コマンドラインツール）
- Eclipse＋AIR GEAR（コード補完用として）
- FlashDevelop
1～3はどれもEclipseなんですが、重いんですよね（あくまで私の環境では、ですが）。
さらに2,3は今時の開発環境としてはチープで、コーディング以外はほとんどコマンドラインでやってました。
で、今使ってるFlashDevelopなんですが、
- 軽いです。Windowsネイティブなんで。
- コード補完効きます。
- デバッガもGUIから使えます。
ブレークポイントの設定とかコマンドラインでやると泣くんで、激助かる。 - GUIビルダー的なものはないです。
Push It!クライアントはGUIはそんなに必要ないんで、上の３つがあるだけで満足。いや、大満足。
もっと早く使っとくべきだった～。
Eclipseベースで重いことを除けばAIR GEARも期待してたんですけど（GUIビルダーも付いてるしね）、開発が止まっちゃってるみたいで、残念。
Channel APIがAIRで使えて、GAEがプレビュー卒業で
なんかもうわけわかんないタイトルですいませんね。ほんとに困ったことになったわけですよ。
前回のエントリ「GAEがプレビューを卒業します」で、Instance Hourがきつくて、無料枠が実質的に狭くなった（かなりね）ことを書いたわけなんですが、
Push It!において、ほとんどの処理って、ポーリングなんですよ。１クライアントあたり10秒間隔の。
で、こいつをなんとかやっつければ、Instance１個でもなんとかやってけるだろうと踏んでるわけです。
じゃ、どうやって、となるわけですが、ポーリング間隔を長くするのがしょぼいけど一番簡単。でも相手に届くまで時間がかかるのは嫌だ。Channel APIが使えりゃいいのになあ～。
でも、以前のエントリ「AIRでChannel APIを使う・・・続編」 で書いた通り、Adobe AIRでGAEのChannel APIが使えなかったわけですよ。
そんなことを嘆いていたところ、世界のどこかの気の効く人がこんな報告をGoogleに上げてくれてまして、9/1に修正されたっぽいです。修正されないだろうなと諦めてたんですけどね。やった！
で、遅まきながら最近試してみたところ、
あれ？以前と変わらず使えないけど・・・。
と相成りました。
困ったね～なんて思って、成功事例を探していたところ、またまたGAEのIssueTrackerですよ、あなた。
「Document that Channel API only support Air >= 2.6」というタイトルのIssueで、英語読解力のない私なので本文は読んでませんが、タイトルからして、AIR2.6以上でないとChannel APIは使えない模様。
調べてみると自分の開発環境はAIR2.0SDK。きた（なにが？）
早速2.6に入れ替えてみようと思ったけど開発環境として使ってるFlashDevelopでの入れ替え方が良く分からないのでやっぱりこれも検索してこのページを発見。いや、親切な人っているもんだね。日本もまだ捨てたもんじゃないよ。
さあやってみよー、キターッ！
AIRにてChannel API使えました！ステキ。
「AIRでChannel API使えねー（そんなタイトルだったっけ？）」の記事にリンクはってくれた「この人」もきっと喜んでいるだろう。
ということで、AIRでChannel API使えるようになったんで、これでポーリングやめてChannelに乗り換えだ！とか思った人！甘い！俺だけど！
ここで、GAEの新料金プランをもう一度おさらいだ。
Channel APIのとこ良く見て。
100 channels opened
と書いてあるから。ちなみにこれ、１日あたりね。
Channelはクライアント毎（ユーザ毎じゃないよ。ブラウザのタブ一枚毎とかそういうこと）に張る必要があります。そして１つのChannelの寿命は2Hです。
24時間PCをあげっぱでPush It!使ってる人はいなさそうなんで、仮に１クライアントあたり8H/日つないでたとして、そのクライアントは最低４回Channelを張ることになる。
すなわち100÷4で25クライアントが無料でサポートできる限界だ。
席を離れる度にスリープにしてるようなまじめな人とか、劣悪な無線LAN環境だとその度にChannelが切れるので、真の限界はさらに低い。
待て待て、本当か・・・？
サービスとして成り立ちませんけど。まあ、無料で使わせてもらってるんで文句言えないんですけど。でも今までは「8,640 Channel Create/Day」だったのにいきなり制限きつくないかと思うんですけど。
大した額じゃないんだから課金すればいいんじゃ？ってそれ趣味でやってる家族持ちには禁句だから。
困ったことだよ・・・。
前回のエントリ「GAEがプレビューを卒業します」で、Instance Hourがきつくて、無料枠が実質的に狭くなった（かなりね）ことを書いたわけなんですが、
Push It!において、ほとんどの処理って、ポーリングなんですよ。１クライアントあたり10秒間隔の。
で、こいつをなんとかやっつければ、Instance１個でもなんとかやってけるだろうと踏んでるわけです。
じゃ、どうやって、となるわけですが、ポーリング間隔を長くするのがしょぼいけど一番簡単。でも相手に届くまで時間がかかるのは嫌だ。Channel APIが使えりゃいいのになあ～。
でも、以前のエントリ「AIRでChannel APIを使う・・・続編」 で書いた通り、Adobe AIRでGAEのChannel APIが使えなかったわけですよ。
そんなことを嘆いていたところ、世界のどこかの気の効く人がこんな報告をGoogleに上げてくれてまして、9/1に修正されたっぽいです。修正されないだろうなと諦めてたんですけどね。やった！
で、遅まきながら最近試してみたところ、
あれ？以前と変わらず使えないけど・・・。
と相成りました。
困ったね～なんて思って、成功事例を探していたところ、またまたGAEのIssueTrackerですよ、あなた。
「Document that Channel API only support Air >= 2.6」というタイトルのIssueで、英語読解力のない私なので本文は読んでませんが、タイトルからして、AIR2.6以上でないとChannel APIは使えない模様。
調べてみると自分の開発環境はAIR2.0SDK。きた（なにが？）
早速2.6に入れ替えてみようと思ったけど開発環境として使ってるFlashDevelopでの入れ替え方が良く分からないのでやっぱりこれも検索してこのページを発見。いや、親切な人っているもんだね。日本もまだ捨てたもんじゃないよ。
さあやってみよー、キターッ！
AIRにてChannel API使えました！ステキ。
「AIRでChannel API使えねー（そんなタイトルだったっけ？）」の記事にリンクはってくれた「この人」もきっと喜んでいるだろう。
ということで、AIRでChannel API使えるようになったんで、これでポーリングやめてChannelに乗り換えだ！とか思った人！甘い！俺だけど！
ここで、GAEの新料金プランをもう一度おさらいだ。
Channel APIのとこ良く見て。
100 channels opened
と書いてあるから。ちなみにこれ、１日あたりね。
Channelはクライアント毎（ユーザ毎じゃないよ。ブラウザのタブ一枚毎とかそういうこと）に張る必要があります。そして１つのChannelの寿命は2Hです。
24時間PCをあげっぱでPush It!使ってる人はいなさそうなんで、仮に１クライアントあたり8H/日つないでたとして、そのクライアントは最低４回Channelを張ることになる。
すなわち100÷4で25クライアントが無料でサポートできる限界だ。
席を離れる度にスリープにしてるようなまじめな人とか、劣悪な無線LAN環境だとその度にChannelが切れるので、真の限界はさらに低い。
待て待て、本当か・・・？
サービスとして成り立ちませんけど。まあ、無料で使わせてもらってるんで文句言えないんですけど。でも今までは「8,640 Channel Create/Day」だったのにいきなり制限きつくないかと思うんですけど。
大した額じゃないんだから課金すればいいんじゃ？ってそれ趣味でやってる家族持ちには禁句だから。
困ったことだよ・・・。
2011年9月17日土曜日
GAEがプレビューを卒業します
もうだいぶ前からアナウンスされてるんですが、GAEがプレビューを卒業します。11月に。
で、その際に価格体系が変わります。（この辺）
これまでも無償の範囲、有償の範囲はあったんですが、今回の価格改定は、無償利用を相当制限しそうです。ちなみにPush It!は無償の範囲で今のところはなんとかやってます。
さて問題は、Instance Hourです。
Instanceって、まあ、アプリケーションサーバ１個ってことなんですが、これが１日あたり24時間までが無料。それを超えると有料です。
インスタンスはアクセス量に応じて増減しますが、Push It!の場合、基本的にアクセスされ続けているので、最低１つは必ず存在しています。これで24Instance Hour。
アクセスが一瞬でも集中すると、インスタンスが自動で追加されて、めでたく有料となりました。
まじか〜。
Admin Consoleってところで、自分のアプリがプレビューを卒業した後はいくら課金されるかが見れるんですが、毎日60Instance Hourは使ってる感じ。ほぼ2Instanceが常に存在して、忙しいときは3個いるくらいの感じでしょうか。
え〜、これを１個に抑えるんですか〜？
ていうか、１個しか使わないっていう設定にできるんでしょうか〜？
Push It!はですね、CPU時間で言うと、Push It!は0.3H/日しか働いてないんです。
GAE/Pythonだと1Instanceは一度に1リクエストしかさばけないので、同時にリクエストを受けると、インスタンスが１個だと、後着のリクエストは先着が終わるまで待たされることになるわけですけど、まあ、確率的には低いはず。
ブラウザからだと若干引っかかりを感じるかも知れないが、Push It!クライアントはそもそもバックグラウンドで勝手に通信してるから気にもならないだろう。
てことで、１個しか使わない設定にできるんですよね？＞Google様
勝手にインスタンスを増やしたあげくに、24Instance Hourを10時間くらいで使い切って、課金設定をしてないから残り14時間は使用できません、とかほんとやめてよね。
うむ、しかし困ったのぅ・・・。
で、その際に価格体系が変わります。（この辺）
これまでも無償の範囲、有償の範囲はあったんですが、今回の価格改定は、無償利用を相当制限しそうです。ちなみにPush It!は無償の範囲で今のところはなんとかやってます。
さて問題は、Instance Hourです。
Instanceって、まあ、アプリケーションサーバ１個ってことなんですが、これが１日あたり24時間までが無料。それを超えると有料です。
インスタンスはアクセス量に応じて増減しますが、Push It!の場合、基本的にアクセスされ続けているので、最低１つは必ず存在しています。これで24Instance Hour。
アクセスが一瞬でも集中すると、インスタンスが自動で追加されて、めでたく有料となりました。
まじか〜。
Admin Consoleってところで、自分のアプリがプレビューを卒業した後はいくら課金されるかが見れるんですが、毎日60Instance Hourは使ってる感じ。ほぼ2Instanceが常に存在して、忙しいときは3個いるくらいの感じでしょうか。
え〜、これを１個に抑えるんですか〜？
ていうか、１個しか使わないっていう設定にできるんでしょうか〜？
Push It!はですね、CPU時間で言うと、Push It!は0.3H/日しか働いてないんです。
GAE/Pythonだと1Instanceは一度に1リクエストしかさばけないので、同時にリクエストを受けると、インスタンスが１個だと、後着のリクエストは先着が終わるまで待たされることになるわけですけど、まあ、確率的には低いはず。
ブラウザからだと若干引っかかりを感じるかも知れないが、Push It!クライアントはそもそもバックグラウンドで勝手に通信してるから気にもならないだろう。
てことで、１個しか使わない設定にできるんですよね？＞Google様
勝手にインスタンスを増やしたあげくに、24Instance Hourを10時間くらいで使い切って、課金設定をしてないから残り14時間は使用できません、とかほんとやめてよね。
うむ、しかし困ったのぅ・・・。
2011年5月17日火曜日
話題を３件ほど
話題１．前回エントリのGAEのChannel APIがAIRで使えない件ですが、外国のどなたかがIssue Trackerにあげてくれてました。めでたし・・・なわけない。正直、使用者数から考えて優先度は低だろうな。だいたい、GoogleのWebAPIで、AIRだのActionScriptだの見たことないし。
話題２．GAEのSDKが、1.5.0になりました。大きく変わってるんですが、Quotaがまた変わりました。回数系の制限が取っ払われて、リソース使用量（帯域とかデータ容量、CPU使用時間など）のみになりました。APIを呼びまくってでも、いかにリソースを食わないプログラムを書くか、腕の見せ所です（前向きに捉えれば）。
話題３．すっげー久々にPush It!をバージョンアップしました。といってもサーバ側。でも有用だと思うのでぜひご活用を。
話題２．GAEのSDKが、1.5.0になりました。大きく変わってるんですが、Quotaがまた変わりました。回数系の制限が取っ払われて、リソース使用量（帯域とかデータ容量、CPU使用時間など）のみになりました。APIを呼びまくってでも、いかにリソースを食わないプログラムを書くか、腕の見せ所です（前向きに捉えれば）。
話題３．すっげー久々にPush It!をバージョンアップしました。といってもサーバ側。でも有用だと思うのでぜひご活用を。
- ニックネームを登録できるようにした。
→タグを共有/公開する際に、Googleアカウント（という名のメールアドレス）をさらさずに良くなりました。 - メールで付箋紙が登録できるようになった。
→出先などでふと思い立ったらその場でPush It!にメール！
2011年4月25日月曜日
AIRでChannel APIを使う・・・続編
GAEのChannel API
という前回のエントリにて、AIRでChannel APIが使えねーよー、と嘆いてはや・・・忘れたけど、打つ手なしで困って途方に暮れて放り出していたところ、ふとしたこと（あまり関係ないことだったんだが）からヒントが見つかりました。
ビンゴかな・・・困ったね。
う～ん・・・。う～ん・・・。
★★★★★★ 宣伝 ★★★★★★
という前回のエントリにて、AIRでChannel APIが使えねーよー、と嘆いてはや・・・忘れたけど、打つ手なしで困って途方に暮れて放り出していたところ、ふとしたこと（あまり関係ないことだったんだが）からヒントが見つかりました。
AIR でサポートされていない WebKit の機能
このページの先頭にて、
window.postMessage 経由のクロスドメインメッセージング（AIR は独自のクロスドメイン通信 API を提供）。
という文言が。
あやしいぞ、と思って、GAEのChannel APIのJavascriptの中を覗くと、
使ってるよ、postMessage・・・
ビンゴかな・・・困ったね。
独自のクロスドメイン通信APIを提供、って勝手なマネすんな！Adobe！世の中一般のJavascriptライブラリが使えなくなるじゃねーか！
おまけにChannel APIの将来の本命と目される「WebSocket」についてもお得意の「独自の・・・」なんだそうで。
アホなの？
う～ん・・・。う～ん・・・。
せっかくChannel APIっていう素敵な代物があるのに指を加えて見てろと・・・。読み込まれたHTMLにpostMessageを無理やり埋め込むってできるのかなあ。
できないんじゃ今のまま短周期ポーリングによる疑似Push継続だよ・・・悲しいし、しょぼい。
あ゛～！
どうしてくれよう。
★★★★★★ 宣伝 ★★★★★★
そんなこともありますが、オンライン＆オフライン付箋紙ソフトPush It!は今すぐ、誰でも、問題なく使えます。今すぐページ右上のリンクをClick!
2011年3月9日水曜日
GAEのChannel API
あ～さて、GAEのChannel APIが公開されてけっこうな時間が立ってるわけですが、未だに使えません。
Channel API自体は使えるんですが、AIRから使えないという話です。
Channel APIのクライアントライブラリはJavascriptになっていて、そのままじゃもちろんAIRでは使えない（FLEX形式の開発の場合）ので、HTMLLoaderクラスにJavascriptを読ませて、ActionScriptにブリッジする、みたいなことをしようとしてるんですが、ブリッジする以前に、HTMLLoader上のJavascriptがブラウザで動くようには動作してくれない。
困ったちゃんだなあ。。。
私がスーパープログラマなら、Javascriptを解析してActionScript化しないでもないのだけど、そんな技量はないし、あったとしても、ライブラリの中身が変わる可能性もある（現状はGoogle Talkのサーバを利用してるみたいだけど、将来的にはもっとネイティブなものに変わる可能性大）ので、あまりいじりたくないんだよね。いや、技量ないですけど。
かれこれ１ヵ月くらい悩んでるんだろか。もう諦めたい・・・。
Channel API自体は使えるんですが、AIRから使えないという話です。
Channel APIのクライアントライブラリはJavascriptになっていて、そのままじゃもちろんAIRでは使えない（FLEX形式の開発の場合）ので、HTMLLoaderクラスにJavascriptを読ませて、ActionScriptにブリッジする、みたいなことをしようとしてるんですが、ブリッジする以前に、HTMLLoader上のJavascriptがブラウザで動くようには動作してくれない。
困ったちゃんだなあ。。。
私がスーパープログラマなら、Javascriptを解析してActionScript化しないでもないのだけど、そんな技量はないし、あったとしても、ライブラリの中身が変わる可能性もある（現状はGoogle Talkのサーバを利用してるみたいだけど、将来的にはもっとネイティブなものに変わる可能性大）ので、あまりいじりたくないんだよね。いや、技量ないですけど。
かれこれ１ヵ月くらい悩んでるんだろか。もう諦めたい・・・。
2011年3月2日水曜日
AIR2.5
遅ればせながら、AIR2.5対応でもしようかと、最新のSDK（AIR SDKとFLEX SDKね）を落としてきて、コンパイルかけたら。。。あらら？mxmlで「そんなプロパティねぇ！」とか言われてしまう。
いつからなのかちゃんと調べてないのだが、従来使えていたプロパティは「Halo」とかいうテーマを使うことにしないと有効にならない模様。。。
って、ええと、、、どうやってテーマを適用するのかわかんないんですが・・・。
Flash Builderが欲しいよう！
と、アフィリエイトのテストをしてみる俺だった。
いや、欲しいのはほんとです。横の広告クリックしてみんな購入してください。30本くらい買ってもらえると多分自分が買えるだけの収入になります。
冗談はさておき、Adobe製品って高いなあ。。。AIR GEARって開発進んでるのかなあ。
いつからなのかちゃんと調べてないのだが、従来使えていたプロパティは「Halo」とかいうテーマを使うことにしないと有効にならない模様。。。
って、ええと、、、どうやってテーマを適用するのかわかんないんですが・・・。
Flash Builderが欲しいよう！
と、アフィリエイトのテストをしてみる俺だった。
いや、欲しいのはほんとです。横の広告クリックしてみんな購入してください。30本くらい買ってもらえると多分自分が買えるだけの収入になります。
冗談はさておき、Adobe製品って高いなあ。。。AIR GEARって開発進んでるのかなあ。
2011年1月18日火曜日
Channel APIが触りたいよ～！
去る12月くらいに、GAEにChannel APIというものが正式に追加されました。
これを使うと、簡単に言うとチャットアプリが作れます。
別にチャットアプリを作るためのAPIじゃないですけど。
要はリアルタイムに近い情報のやり取りがサーバとクライアントの間でできるようになるということです。
現在のPush It!は、サーバとの同期のためにポーリングモデル（定期的にサーバに「新しい情報ありますかね～？」と聞きに行く）を採用しているのですが、どうしてもタイムラグが発生するし、サーバ側も負荷がかかり過ぎないように色々工夫してあげないといけません。（GAEの無料Quotaに引っ掛かりやすくなるので）
ということで、すぐにでも対応したいChannel APIなのだが、全然時間が取れない。。。くやしい。。。
これを使うと、簡単に言うとチャットアプリが作れます。
別にチャットアプリを作るためのAPIじゃないですけど。
要はリアルタイムに近い情報のやり取りがサーバとクライアントの間でできるようになるということです。
現在のPush It!は、サーバとの同期のためにポーリングモデル（定期的にサーバに「新しい情報ありますかね～？」と聞きに行く）を採用しているのですが、どうしてもタイムラグが発生するし、サーバ側も負荷がかかり過ぎないように色々工夫してあげないといけません。（GAEの無料Quotaに引っ掛かりやすくなるので）
ということで、すぐにでも対応したいChannel APIなのだが、全然時間が取れない。。。くやしい。。。
登録:
投稿 (Atom)