Windows8 ConsumerPreviewが出たので、自宅MacのVirtualBoxに入れてみたんだが・・・。何しろ重い・・・。
重いというか、良く固まる（落ちるわけではない）。これはVirtualBoxのせいなんだろうか。とてもじゃないが実用に堪えない感じ。
とりあえずいろんなIT系ニュースサイトに使ってみたよレポートは出てるので、今更自分が書くようなこともないが、印象としては、
企業（仕事）で使うWindowsじゃあない。
ってとこだろうか。
・Metroが中心に据えられてて主としてMS Officeを使うようなオフィスワーカーには迷惑なだけ。
・クラウドを使っての共有が簡単にできるようになって個人利用には便利だが、会社にとっては「何が流出するかわからない恐怖」を煽るだけ。
とにかく、良くできてるWindows7にタブレットのお洋服を着せた結果、タブレットOSをPCで使わされている印象。ひどい。タブレット専用として売って下さい、これ・・・。
Windows8がリリースされて何年かたてば慣れるのかなあ・・・。
2012年3月9日金曜日
2012年2月9日木曜日
Node.js on Herokuのベンチマーク
Node.js on Herokuの開発環境がとりあえずできてみたので、ちょっとベンチマークをとってみた。といっても、相手はHello Worldを返すだけの最小Webアプリなので、その辺は割り引いて考えてください。
サーバ環境：Herokuの公開用サーバのWeb Dynos（無料枠なので1Dynos）
アプリ環境：Web DynosのCedarスタック上のNode.jsアプリ（Hello Worldを返すだけ）
クライアント環境：MacOSX(Lion)上の標準Java上のJmeter
最初、MacOSXに標準で同梱されているApache Bench（abコマンド:こんなのも同梱されてるって、どんだけ開発者寄りなんだOSX！）で、さくっと感覚だけ掴んでみるべ、と思ったんだけど、並列リクエスト数4（-c 4）あたりからなんだか挙動がおかしなことになってきて、Socketエラーが出てしまう。
これは明らかにHerokuの問題じゃなさそうだな、、、と思ってググってみると、標準のabはイケてないので、ソースからビルドし直した、なんて記事があったりしてガックリ。
ソースから入れ直すのもいいけど、標準abと入れ直したabが混在するのも構成管理上気持ち悪いし、いっその事Jmeterで真剣にやるか、ってな感じに決着がついた（自分内で）。
で、結論的には、
350req/sec（Keep-Alive無効時）
500req/sec（Keep-Alive有効時）
あたりのスループットまで到達した。
ここまでくるとそれ以上に行くためのネックがサーバなのかクライアントなのかネットワークなのかは置いておいても、十分すぎるほどの性能。
前述の通り、アプリは何も処理してないに等しいのは確かだけど、1Dynos(＝1プロセス＜1物理CPUcore、でいいのかな)だけで、350ものコネクション(/sec)の切った張ったをできるだけでも超優秀と言ってもいいんじゃないだろうか。
いじりがいがあるな〜。
（尚、レスポンスタイムはおおむね400ms前後で、こっちはちょっと残念な感じ。サーバが米国だから仕方ない面もあるけど、400msあると人は引っかかりを感じるだろうから、アプリっぽいWebアプリを、サクサク動かすにはちょっとつらいか）
2012年2月7日火曜日
HerokuでNode.jsを始めてみる
Heroku公式サイトのここを見る。おしまい。
・・・いや、ほんとにそうだから。
簡単すぎて半笑いでやりました。
Windowsだとちと大変かも知れない。
Mac(Lion)だと得体の知れないラクさ加減。
Node.jsをローカルにインストールするところで若干戸惑うが、Node.jsとnvmを初めてインストールするときのハマりポイントと対策を参考にさせてもらいました。
（尚、ここに書いてあるのはNode.js v0.4.0時点のもので、自分はv0.4.7で試したところ、wgetは不要でいけました。nvmコマンドの出力形式も多少違う）
あとは、Xcodeさえ入ってれば、Lionにはgitも入ってるし何にも悩むことがない。
学んだこと・・・
・・・いや、ほんとにそうだから。
簡単すぎて半笑いでやりました。
Windowsだとちと大変かも知れない。
Mac(Lion)だと得体の知れないラクさ加減。
Node.jsをローカルにインストールするところで若干戸惑うが、Node.jsとnvmを初めてインストールするときのハマりポイントと対策を参考にさせてもらいました。
（尚、ここに書いてあるのはNode.js v0.4.0時点のもので、自分はv0.4.7で試したところ、wgetは不要でいけました。nvmコマンドの出力形式も多少違う）
あとは、Xcodeさえ入ってれば、Lionにはgitも入ってるし何にも悩むことがない。
学んだこと・・・
- nvmコマンドって、Node.jsのパッケージマネージャなんですけど、Node.jsそのものまでインストールできるのにビビる。Node.jsが存在しない状態で実行できる。まじか。。。
- MacOSXの開発者フレンドリーな環境にビビる。gitまで入ってんのか〜。。。
- Herokuって、多言語に対応してるんだけど、どこで「僕はNode.jsを使うの！」って指定するのかな、っと疑問だった（何しろHerokuといえばRoR、の記事ばっかで・・・）が、Procfileというファイルで指定すれば良いらしい。悩まないでプログラミング界の格言（？）「考えるな、真似ろ」に従っておけば良かったわ。
- gitでデプロイするのは分かってしまえば（GAEのappcfgとの比較で言うと）バージョン管理も直感的だし（つうか、そもそもgitはバージョン管理するためのプロダクトなのだが・・・）好きかも。ただ、いかんせんgitはちゃんと触ったことがないので、慣れるまでは我慢か。
- Windowsで環境を作るのは正直おっくう。
さあ、バリバリ遊ぶぞ〜。
2012年2月1日水曜日
WebSocketとかChannelとか
GAEのChannelは、無料枠では1日100オープンまでだし、HerokuのWebSocket(Pusher)は無料枠で20コネクションまでだし、リアルタイム性の高いPush通信は、コストが高くついて困るなあなんて話を過去のエントリでしたわけですが、
考えてみると、Push It!は、通信対戦アクションゲームのようなギチギチのリアルタイム性を求めているわけでなく、数秒程度の遅延で付箋が更新されれば良くって、だったらChannelやWebSocketである必要なくね？と思い返した。
ただ、短周期のポーリングは避けたいね、クライアントにもサーバにもネットワークにも負荷だし、というのがそもそもChannelやWebSocketを使おうとしたそもそもの理由。
ってことは、Long Pollingでいいんじゃね？という気がした。
GAE/Python2.5だと、CPUすかすかでも１リクエストが１インスタンスを占有するから現実的ではないのだが、GAE/Python2.7（か、Java）だったらマルチスレッド対応なので、CPUすかすかなら対応できるかもしれない。
ただ、GAE/P（多分Jもだが）、リクエスト処理中に外部からのイベントを受け付けられる仕組みにはなってないので、更新があったかどうか、内部では短周期でポーリング（Datastoreなりmemcacheなりに対して）してあげないといけない。これがネック。
HerokuだとNode.jsが使えるので、外部からのイベントが来るまでリクエスト処理は放置しておけるんじゃないか？だとしたら、Long Pollingがかなりラクかつ低負荷で実施できそうな気もする。
どうなんだろ。試してみたい。
考えてみると、Push It!は、通信対戦アクションゲームのようなギチギチのリアルタイム性を求めているわけでなく、数秒程度の遅延で付箋が更新されれば良くって、だったらChannelやWebSocketである必要なくね？と思い返した。
ただ、短周期のポーリングは避けたいね、クライアントにもサーバにもネットワークにも負荷だし、というのがそもそもChannelやWebSocketを使おうとしたそもそもの理由。
ってことは、Long Pollingでいいんじゃね？という気がした。
GAE/Python2.5だと、CPUすかすかでも１リクエストが１インスタンスを占有するから現実的ではないのだが、GAE/Python2.7（か、Java）だったらマルチスレッド対応なので、CPUすかすかなら対応できるかもしれない。
ただ、GAE/P（多分Jもだが）、リクエスト処理中に外部からのイベントを受け付けられる仕組みにはなってないので、更新があったかどうか、内部では短周期でポーリング（Datastoreなりmemcacheなりに対して）してあげないといけない。これがネック。
HerokuだとNode.jsが使えるので、外部からのイベントが来るまでリクエスト処理は放置しておけるんじゃないか？だとしたら、Long Pollingがかなりラクかつ低負荷で実施できそうな気もする。
どうなんだろ。試してみたい。
2012年1月31日火曜日
（続）モバイルアプリ開発、何使う？
前回のエントリでモバイルアプリ開発に何を使うか書いたばかりだが、非常に参考になるブログがあったので、紹介。
どうしてTitanium Mobileなの？
どうしてTitanium Mobileなの？
て、３日前に書かれた記事ですね。
みんな同じような悩みを抱えつつ、自分なりの答えを探しているんですね～。
ぼかぁ、どれもこれもまだ触ってないので、オモテから見える部分でしか評価できないんで非常に参考になりました。
モバイルアプリ開発、何使う？
PCクライアント版PushIt!も完成してないのになんだが、モバイルアプリ（正確にはスマホ向けというべきか）にも手を出したい今日この頃。
さて、モバイルアプリと言えば、昨今はいろいろと作り方があるので、最初を間違えると後で不良債権を抱えてしまうことになり、選び方に慎重になってしまう。
ちょっと比較をしてみた。ターゲットはiOSとAndroidだ。
で実際5ってどうなんですかねえ。開発者ついてるんですかねえ。
さて、モバイルアプリと言えば、昨今はいろいろと作り方があるので、最初を間違えると後で不良債権を抱えてしまうことになり、選び方に慎重になってしまう。
ちょっと比較をしてみた。ターゲットはiOSとAndroidだ。
- 1. ネイティブアプリ
言わずと知れたObjective-C（iOS）とJava（Android）である。実行速度と「オワコン」にならなさ加減では間違いない選択。しかし、なるべく手間をかけずに両方対応したいならまず外すべき選択肢。Push It!のようなツール系アプリなら実行速度をあまり気にしないので忘れても結構。 - 2. Unity
Mono（Windowsの.NETフレームワークのオープンソース版）を使った開発・実行環境。事前にネイティブコンパイルするので、実行速度はネイティブ並み（Javascriptでも開発できるらしいが、それもコンパイルするのかは不明）を確保しつつ、サポートプラットフォームが半端無い。ネイティブ形式にパッケージングされるのでアプリストアで売れる。
基本、ゲーム向けのフレームワークなので、ライトな用途には重量級すぎるかも？使ってみないとなんとも言えないが。移植性はわからん。 - 3. HTML+CSS+Javascript
言わずと知れた。アプリっぽくするにはjQuery Mobileなんかを使いつつ、キャッシュやローカルストレージを駆使してローカルでも動くようにしないとね。
実行速度的にはまあそれなり。ツール用途で、かつデバイスの機能をフル活用しなくていいならありな選択肢。デバイス特化な機能を使わないなら移植性も高い。
iOS向けにAppStoreで売って小遣い稼ぎしたいならなし。 - 4. PhoneGap
基本的に3と同じだが、ネイティブ形式にパッケージングされるのでアプリストアで売れる。
デバイス機能へのブリッジもある程度用意されているので、そこそこ凝ったアプリもイケる。 - 5. Titanium Mobile
1と同じことを言語にJavascriptを使う、といったら良いだろうか。同じくJavascriptを使う3,4との違いはViewの部分（つまり見た目）もJavascriptで構築するところ。
当然、ネイティブ形式にパッケージングされるのでアプリストアで売れる。
Javascriptがネイティブコードにコンパイルされるなんて情報もあるが定かではないので、実行速度は不明。
移植性に関しても良く分からないが、ViewとI/Oをうまく切り出せれば大部分は流用できるだろう。
どんだけ流行るか不明。 - 6. Adobe AIR (for Mobile)
AIRランタイムを使ったアプリをネイティブ形式にパッケージングするもの。
思想的には2や5に近い。Flash(Flex)開発者にとっては取っ付きやすいが、そのFlashがモバイル向けから手を引いたので、衰退の予感。HTML＋Javascriptでも開発できるけど、その場合は3,4でもいいわけだし。
PCとのマルチデバイス展開もやりやすいといえばそうだが、PC向けとは（ある程度コードは共有できるけど）別物だと思った方が良い。
個人的には、実行速度的にはどれでも満足できる用途なので良しとして、1はマルチデバイス展開の点でナシ、2は重量級すぎてナシ、6はオワコンの予感でナシ、3やるくらいなら4の方が楽できる（し売れる。実際売れるかどうかは別だが）のでナシということで、残るは4,5になる。
で実際5ってどうなんですかねえ。開発者ついてるんですかねえ。
4は時々ニュースになるし、PhoneGapそのものの魅力ではないけど、UI周りではjQuery Mobileが巨大なコミュニティを持っているおかげで凝ったViewも作りやすそうなので、今後も有望なんじゃないかと思うんだけど、どうかな。
2012年1月28日土曜日
Aptana Studio with Pleiades on MacOSX
Push It!のサーバ側は、俗にいうGAE/Pであり、つまりPythonなのである。
で、Pythonの開発環境として有名なものにはPyDev(Eclipseのプラグイン)というものがある。
PyDevはもちろんただで使えるのだが、基本、Aptanaという会社が作っていて（多分）、AptanaはEclipseベースの開発環境であるAptana Studio（これもただ）を配布しており、当然その中にはPyDevも入っている（だけでなくスクリプト系Web開発環境のほぼすべてが揃っていると言っても過言ではないくらいてんこ盛りである）。
さて、そのAptana Studio、Eclipseベースなので当然Javaであり、当然Macでも動く。
Mac用インストーラも配布されているので楽チンなのだが、残念ながら日本語化されていない。
Eclipseを日本語化するには有志の皆さんが作っているPleiadesというプラグインがあり、（Windows版なら）Eclipse込みのパッケージも配布されている、が、前述の通り自分は
「Macに」
「Aptana Studioを」
入れたのであり、Eclipseは既に存在しているところにPleiadesを入れたいのだ、わたしゃ。
Pleiadesは単なるプラグインではなく、ものすごく乱暴に言うと、
「Eclipseのテキスト表示をインターセプトして、その場で翻訳して日本語で表示しちまうぞ、こら！」
という仕組みであるらしく、plugins & featuresフォルダにファイルを突っ込むだけでは足りず、インターセプトするために起動オプションに仕込みが必要になる。
で、前置きが長くなったが、起動オプションなんである。
Pleiadesの配布パッケージには優しい（易しくはない・・・）READMEがついているんだけど、Eclipseの起動オプション設定として、世界で70億人くらいが使っているであろうeclipse.iniがAptana Studioには、ない！
どーすりゃいいんすか〜、まあ、メニュー等が日本語でなくてもソースに日本語が使えないわけではないのだし、なんとかなるけど・・・と思いながらも諦めきれず探していたら、ありました。別の名前で。
その者の名は、
/Applications/Aptana Studio 3/AptanaStudio3.app/Contents/MacOS/AptanaStudio3.ini
である。
第一のトラップは「AptanaStudio3.app」であり、MacのFinderでは通常「.appなフォルダ」は実行ファイルに見える。が、実体は特殊なフォルダなのであり、それに気がつかなかったというか、知ってたけどその中まで探さなかったこと。
第二のトラップはeclipse.iniではなく、AptanaStudio3.iniであること。まあ、こちらは第一のトラップがわかれば容易くわかる、のだが、それに気がつかない間、「.appフォルダ」を特別扱いしないツールであるコンソールから、一生懸命
find "/Applications/Aptana Studio 3" -name eclipse.ini
しても見つからなかったのでプチトラップである。
恐るべしMac、そしてAptana Studio・・・の巻。
で、Pythonの開発環境として有名なものにはPyDev(Eclipseのプラグイン)というものがある。
PyDevはもちろんただで使えるのだが、基本、Aptanaという会社が作っていて（多分）、AptanaはEclipseベースの開発環境であるAptana Studio（これもただ）を配布しており、当然その中にはPyDevも入っている（だけでなくスクリプト系Web開発環境のほぼすべてが揃っていると言っても過言ではないくらいてんこ盛りである）。
さて、そのAptana Studio、Eclipseベースなので当然Javaであり、当然Macでも動く。
Mac用インストーラも配布されているので楽チンなのだが、残念ながら日本語化されていない。
Eclipseを日本語化するには有志の皆さんが作っているPleiadesというプラグインがあり、（Windows版なら）Eclipse込みのパッケージも配布されている、が、前述の通り自分は
「Macに」
「Aptana Studioを」
入れたのであり、Eclipseは既に存在しているところにPleiadesを入れたいのだ、わたしゃ。
Pleiadesは単なるプラグインではなく、ものすごく乱暴に言うと、
「Eclipseのテキスト表示をインターセプトして、その場で翻訳して日本語で表示しちまうぞ、こら！」
という仕組みであるらしく、plugins & featuresフォルダにファイルを突っ込むだけでは足りず、インターセプトするために起動オプションに仕込みが必要になる。
で、前置きが長くなったが、起動オプションなんである。
Pleiadesの配布パッケージには優しい（易しくはない・・・）READMEがついているんだけど、Eclipseの起動オプション設定として、世界で70億人くらいが使っているであろうeclipse.iniがAptana Studioには、ない！
どーすりゃいいんすか〜、まあ、メニュー等が日本語でなくてもソースに日本語が使えないわけではないのだし、なんとかなるけど・・・と思いながらも諦めきれず探していたら、ありました。別の名前で。
その者の名は、
/Applications/Aptana Studio 3/AptanaStudio3.app/Contents/MacOS/AptanaStudio3.ini
である。
第一のトラップは「AptanaStudio3.app」であり、MacのFinderでは通常「.appなフォルダ」は実行ファイルに見える。が、実体は特殊なフォルダなのであり、それに気がつかなかったというか、知ってたけどその中まで探さなかったこと。
第二のトラップはeclipse.iniではなく、AptanaStudio3.iniであること。まあ、こちらは第一のトラップがわかれば容易くわかる、のだが、それに気がつかない間、「.appフォルダ」を特別扱いしないツールであるコンソールから、一生懸命
find "/Applications/Aptana Studio 3" -name eclipse.ini
しても見つからなかったのでプチトラップである。
恐るべしMac、そしてAptana Studio・・・の巻。
2012年1月18日水曜日
FlashDevelop4系正式リリース
今か今かと待ちわびたFlashDevelopの4がいつの間にか（クリスマスのちょい前）リリースされていたらしい。（待ちわびてる割に見逃すってどういうこと・・・）
べらぼうに増えた機能（しかし配布サイズはたったの16MBだ！）を使う日は当分先なんだろうな・・・。
目先の嬉しさといえば、標準で組み込まれるAIR/FLEX SDKのバージョンが最新化されたことだろうか。
FlashDevelop3でもSDKだけAdobeから落としてきて差し替えることもできる（このあたりにお世話になりました）のだが、しかし、
難易度が超絶高い！
というのは言い過ぎにしろ、標準で入ってくれているのは非常にありがたい。
新機能としては、AndroidSDKが不要な、（AIRによる）Androidアプリ開発ができるとかあるみたい。素敵すぎてヨダレが出そう。
Eclipseもいいけど、Flex/ActionScript/AIRの開発は絶対こちら！おすすめ！本も買って読むべし！でもやっぱりFlashBuilder（Eclipseベースだったりする）欲しい！
目先の嬉しさといえば、標準で組み込まれるAIR/FLEX SDKのバージョンが最新化されたことだろうか。
FlashDevelop3でもSDKだけAdobeから落としてきて差し替えることもできる（このあたりにお世話になりました）のだが、しかし、
難易度が超絶高い！
というのは言い過ぎにしろ、標準で入ってくれているのは非常にありがたい。
新機能としては、AndroidSDKが不要な、（AIRによる）Androidアプリ開発ができるとかあるみたい。素敵すぎてヨダレが出そう。
Eclipseもいいけど、Flex/ActionScript/AIRの開発は絶対こちら！おすすめ！本も買って読むべし！でもやっぱりFlashBuilder（Eclipseベースだったりする）欲しい！
2011年11月30日水曜日
Herokuに浮気・・・が始まらない
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数制限と大差ないから！ということに気づく。
無料だと・・・どこ行ってもキツイね・・・。そらそうなんだが。
※
だってね、インスタンスはほぼ１日中１個（時々０個か２個）上がってるから、インスタンス使用時間は約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月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!にメール！
登録:
投稿 (Atom)