Linux版のAIRがとうとう正式リリースされましたね。
（関連ニュース）
まだテストしてませんが、物理的に手に入れないといけないMacとは違って、LinuxはVMwareとかでいいから時間があればテストしてみたいです。
ついでですが、Push It!のAIRクライアントのバージョンが0.9.1になりました。
ちょっといやんなバグ（でも普通は表出しないと思います）がいくつか修正されてますので、なにとぞお早めにバージョンアップしてください。
正式リリース（ver1.0）までカウントダウンが始まりました。
正式リリースになったからって、β版のデータはそのまま使えます。β版とはいえ安定して動いてますので、今からでもぜひ、ご利用ください。
ご要望があれば、今のところはここのブログにコメントして下さい。
正式リリースまでにGoogleグループとかmixiのコミュとかも用意したいなあとは思ってます。
では、ぜひぜひ。
2008年12月19日金曜日
2008年12月17日水曜日
GAEの管理画面がパワーアップ
いつからか分からない（多分ここ２，３日）ですが、GAEの管理コンソールに、
「Quota Details」
なるメニューが加わってました。
おお、素晴らしい。
今まで制限としては書いて（Quotaの解説）あっても、自分がどれだけ使ってるかわからない制限もあったので、これは原因もわからず、
Over Quota
が出ることに悩まされ夜も眠れなかった人には福音だろう。
で、ちなみにこれを機にQuotaをよくよく見なおしてみると、
だとしたら早いところGoogle版memcacheを実装してDatastoreより制限を緩くして欲しいすねえ。
☆☆☆☆☆ 宣伝 ☆☆☆☆☆
ネットに保存のデスクトップ付箋紙、Push It!公開してます。
Googleがつぶれない限りずっと使えるサービスです。その点は安心していいです。
まずは使ってみましょう！
「Quota Details」
なるメニューが加わってました。
おお、素晴らしい。
今まで制限としては書いて（Quotaの解説）あっても、自分がどれだけ使ってるかわからない制限もあったので、これは原因もわからず、
Over Quota
が出ることに悩まされ夜も眠れなかった人には福音だろう。
で、ちなみにこれを機にQuotaをよくよく見なおしてみると、
- 以前HTTPとHTTPSの制限は同一なのでなんでもかんでもHTTPSでいいんじゃん？とか書いたが、知らないうちに減らされていた。残念・・・というかまあごもっともではある。
- memcacheの方がDatastoreより制限がきつい。・・・えぇ！？Datastoreのオフロードのためにmemcache使いまくってんすけど！？となると、memcacheを使うのはレスポンスを限界まで短くしたい場合だけにしとけ、って感じ？（Datastoreとmemcacheのレスポンスの差異は・・・また次回に書きます）
だとしたら早いところGoogle版memcacheを実装してDatastoreより制限を緩くして欲しいすねえ。
☆☆☆☆☆ 宣伝 ☆☆☆☆☆
ネットに保存のデスクトップ付箋紙、Push It!公開してます。
Googleがつぶれない限りずっと使えるサービスです。その点は安心していいです。
まずは使ってみましょう！
2008年12月8日月曜日
AIR1.5
AIRのランタイム1.5が出たのは知っていたのだが、開発環境は1.1のままにしていた。SDK等も全部1.1のままで使ってました。
なのですが、AIRのアプリケーションであるPush It!のクライアントを起動するたびに1.5が出てます、今アップデートしますか？みたいに聞かれるので、いい加減アップデートしましたよ。ええ。
SDKは1.1、アプリケーションディスクリプタも1.1仕様ですが、特に問題なく動いてる模様。
あと、心持ち早くなったような気がしないでもないです。
ランタイム1.1のまま使ってる人には悪いですが、今後テストはランタイム1.5上でやらせてもらいます（1.1上でも動くでしょうが）。
でも1.1の人ってきっと1.5へのバージョンアップを催促されてると思うからほとんどの人は1.5になってるんじゃないかな？
☆☆☆☆☆ 宣伝です ☆☆☆☆☆
そんな中、クライアント0.8を12/5にリリースしましたよ。
細かいけど、今までのちょっとした表示の不行き届きなんかをかなり改善しました。
それからサイトデザインも若干ブラッシュアップしました。
ぜひ一度Push It! インターネット付箋紙をお試しください。
なのですが、AIRのアプリケーションであるPush It!のクライアントを起動するたびに1.5が出てます、今アップデートしますか？みたいに聞かれるので、いい加減アップデートしましたよ。ええ。
SDKは1.1、アプリケーションディスクリプタも1.1仕様ですが、特に問題なく動いてる模様。
あと、心持ち早くなったような気がしないでもないです。
ランタイム1.1のまま使ってる人には悪いですが、今後テストはランタイム1.5上でやらせてもらいます（1.1上でも動くでしょうが）。
でも1.1の人ってきっと1.5へのバージョンアップを催促されてると思うからほとんどの人は1.5になってるんじゃないかな？
☆☆☆☆☆ 宣伝です ☆☆☆☆☆
そんな中、クライアント0.8を12/5にリリースしましたよ。
細かいけど、今までのちょっとした表示の不行き届きなんかをかなり改善しました。
それからサイトデザインも若干ブラッシュアップしました。
ぜひ一度Push It! インターネット付箋紙をお試しください。
2008年12月2日火曜日
Adobe MAX
ちょっと遅れ気味の話題だが、Adobe MAXで気になるニュースがいくつかありましたね（ありましたね、といっても興味のない人には関係ないのだが・・・）。
１．AIRの1.5が出た。
おかげでPush It!クライアントを何回か実行してると「アップデートの準備ができました」というダイアログが表示される。現在Push It!クライアントはAIR1.1ベースで作っているので、ランタイムも1.1のままにしているのだが、、、正直悩む。みんながみんな1.5にあげてくれるだろうか。ランタイム1.5の上で、1.1をターゲットにしたAIRアプリは動くだろうが、開発環境のランタイムを1.5にしてしまったら、1.1特有の問題が出た時にどうしようかと思わないでもない。杞憂だろうが。
とりあえず自分的には1.5にとても魅力的な機能があるわけじゃないのでしばらく放置・・・しようと思ったら、
akihiro kamijo: FlexBuilder 3.0.2 / SDK 3.2 の公開
こんな記事も。気になるのは最後の方。
「1.5 の名前空間は Flash Player 9, 10 ともに使えますが、1.1 の名前空間は Flash Player 9 の時だけ使えます。」
え？どゆこと？1.1のままで作ってるアプリはFlash10を入れてある環境では使えないと？
AIRのランタイムとFlash Playerのランタイム（プラグイン）って、独立してないの？
謎は深まる。。。誰か教えてくれ～～！
２．Adobe Wave
要するにリアルタイムコンテンツ配信プラットフォームか？
Push It!の付箋紙更新を配信できれば面白いと思ったのだけど（GAEを使ってそれをやるのはどうにもツラいので・・・まあ頑張ってやってますが）、どうやら限られた（つまり大手の）サービスプロバイダがコンテンツを提供できるだけなのかな？良く分からん。
他にも面白いネタがありました（Visual StudioでFlex開発をするプラグインとか。Adobe製じゃないけど）が、もうちょっと日本語リソースを充実させて欲しいな、Adobe様。
☆☆☆☆☆ 宣伝 ☆☆☆☆☆
無料のデスクトップ付箋紙ソフトPush It!をこの機会にぜひお試し下さい。
最近チュートリアルも追加しましたので、使用イメージはそちらをご覧下さい。
１．AIRの1.5が出た。
おかげでPush It!クライアントを何回か実行してると「アップデートの準備ができました」というダイアログが表示される。現在Push It!クライアントはAIR1.1ベースで作っているので、ランタイムも1.1のままにしているのだが、、、正直悩む。みんながみんな1.5にあげてくれるだろうか。ランタイム1.5の上で、1.1をターゲットにしたAIRアプリは動くだろうが、開発環境のランタイムを1.5にしてしまったら、1.1特有の問題が出た時にどうしようかと思わないでもない。杞憂だろうが。
とりあえず自分的には1.5にとても魅力的な機能があるわけじゃないのでしばらく放置・・・しようと思ったら、
akihiro kamijo: FlexBuilder 3.0.2 / SDK 3.2 の公開
こんな記事も。気になるのは最後の方。
「1.5 の名前空間は Flash Player 9, 10 ともに使えますが、1.1 の名前空間は Flash Player 9 の時だけ使えます。」
え？どゆこと？1.1のままで作ってるアプリはFlash10を入れてある環境では使えないと？
AIRのランタイムとFlash Playerのランタイム（プラグイン）って、独立してないの？
謎は深まる。。。誰か教えてくれ～～！
２．Adobe Wave
要するにリアルタイムコンテンツ配信プラットフォームか？
Push It!の付箋紙更新を配信できれば面白いと思ったのだけど（GAEを使ってそれをやるのはどうにもツラいので・・・まあ頑張ってやってますが）、どうやら限られた（つまり大手の）サービスプロバイダがコンテンツを提供できるだけなのかな？良く分からん。
他にも面白いネタがありました（Visual StudioでFlex開発をするプラグインとか。Adobe製じゃないけど）が、もうちょっと日本語リソースを充実させて欲しいな、Adobe様。
☆☆☆☆☆ 宣伝 ☆☆☆☆☆
無料のデスクトップ付箋紙ソフトPush It!をこの機会にぜひお試し下さい。
最近チュートリアルも追加しましたので、使用イメージはそちらをご覧下さい。
2008年11月22日土曜日
久々にGAEのSDK更新
GAEのSDK1.1.6が出ました。
（日本語のダウンロードページは相変わらず1.1.0のままですので気をつけましょう）
久々ですね。1.1.2～1.1.5までは２～３週間でバージョンアップしてましたが、今回は１ヶ月半以上。
完成度が高くなってきてあんまり直す内容もないのかな、、、と思いきや、今回も割と盛りだくさんな内容。
でも自分の使ってるAPIにはあまり関係がないようだ。
というかそれ以前に、最近はPush It!の開発・テストのメインは、GAE本番サーバの開発専用ドメインだったりするので、SDKの擬似Webサーバ（dev_appserver.py)の改修はあまり関係なかったりもする。
ま、でも一応入れますけどね。
（appcfg.pyの改修は関係ありますし）
☆☆☆☆☆☆☆☆☆☆ 宣伝 ☆☆☆☆☆☆☆☆☆☆☆
インターネット越しに共有可能でありつつ、オフラインでも使える付箋紙ソフト、
Push It!をぜひとも使ってみてください。
（日本語のダウンロードページは相変わらず1.1.0のままですので気をつけましょう）
久々ですね。1.1.2～1.1.5までは２～３週間でバージョンアップしてましたが、今回は１ヶ月半以上。
完成度が高くなってきてあんまり直す内容もないのかな、、、と思いきや、今回も割と盛りだくさんな内容。
でも自分の使ってるAPIにはあまり関係がないようだ。
というかそれ以前に、最近はPush It!の開発・テストのメインは、GAE本番サーバの開発専用ドメインだったりするので、SDKの擬似Webサーバ（dev_appserver.py)の改修はあまり関係なかったりもする。
ま、でも一応入れますけどね。
（appcfg.pyの改修は関係ありますし）
☆☆☆☆☆☆☆☆☆☆ 宣伝 ☆☆☆☆☆☆☆☆☆☆☆
インターネット越しに共有可能でありつつ、オフラインでも使える付箋紙ソフト、
Push It!をぜひとも使ってみてください。
2008年11月20日木曜日
CSSでDIV要素の行の高さを揃えよう
以前のエントリCSSのシブい技にて、CSSを使って横並びのDIV要素の高さを揃えようって話を書いたんだが、しばらくしてみて不具合発覚。
同一ページ内のリンクをクリックしてジャンプすると、上の方の内容が隠れてしまうのです。
これはやっぱり見えないけどこっそり存在しているpadding領域のせいなのかな？
う～ん、今度こそJavaScriptですか～？と思っていたところ検索してみると、CSSを使った別の方法が見つかりました。
複数カラムの高さをそろえるクロスブラウザなCSS | CREAMU
というやつで、簡単に言うと、DIV要素を重ねて、列の幅のぶんだけずらしていく方法（はみでたところはやっぱり隠すんだけど）。
前よりこっちの方がマニアック度は低いかもしれない。
だが、widthとかleft/rightの値に何を設定すれば良いか、すぐに頭の中で算出できない自分がいました。
でもとりあえず同一ページ内リンクでもくずれなくなったし、FireFox/Chrome/IEどれ使ってもちゃんと同じように表示されたし（ついでにmargin/paddingとwidthの同時指定によるIEのバグにも引っかからなくしたし。これはまたいつか書こう）、言うことなし。
しかしいろんな方法があるもんだねぇ。。。
昔ながらのtable使ったレイアウトの方が100倍楽だよな～。。。
同一ページ内のリンクをクリックしてジャンプすると、上の方の内容が隠れてしまうのです。
これはやっぱり見えないけどこっそり存在しているpadding領域のせいなのかな？
う～ん、今度こそJavaScriptですか～？と思っていたところ検索してみると、CSSを使った別の方法が見つかりました。
複数カラムの高さをそろえるクロスブラウザなCSS | CREAMU
というやつで、簡単に言うと、DIV要素を重ねて、列の幅のぶんだけずらしていく方法（はみでたところはやっぱり隠すんだけど）。
前よりこっちの方がマニアック度は低いかもしれない。
だが、widthとかleft/rightの値に何を設定すれば良いか、すぐに頭の中で算出できない自分がいました。
でもとりあえず同一ページ内リンクでもくずれなくなったし、FireFox/Chrome/IEどれ使ってもちゃんと同じように表示されたし（ついでにmargin/paddingとwidthの同時指定によるIEのバグにも引っかからなくしたし。これはまたいつか書こう）、言うことなし。
しかしいろんな方法があるもんだねぇ。。。
昔ながらのtable使ったレイアウトの方が100倍楽だよな～。。。
2008年11月19日水曜日
AJAXで取り込んだHTMLのtable要素が表示されない件
タイトルの通り、Push It!において、AJAXで取り込んだHTMLの中にtable要素が含まれる場合にIEだとどーーーーーーーしても表示されない件で悩み続けて１週間。
ようやく解決方法が分かりました。
table要素とtr要素の間にtbody要素が必須、なみたいだ。
AJAXでない普通のHTMLだと、tbodyはオプションなのだが、なぜかAJAXだと厳密にその辺を要求するらしい。IEだけは。まだIE6でしかテストしてないけどIE7でも同じだろうな。
もちろんtbodyはあってもいい存在なので、FireFoxやChromeでもtbodyがあっても問題ない。よって、ブラウザ別にコードを分ける必要はなくて常にtbodyは入れておいて良い。
いやしかし、、、長かった。ここに至る道は、ほんとに。
どうやって検索しても見つからないんだもんな～。これって常識？
XML（もしくはJSON）を取り込んでそれを表に整形する、とかは見つかるんだけどね。別に自分はそんなにAJAXで取り込んだデータをあれやこれやと使いまわす気もなかったのでまんまHTMLを取り込んでそれをそのまま表示させていたのだけど、どうしてもだめならXMLで取り込んで整形して表示しようとも思ったりした。
そこまで思いつめてたのだ（ま、そっちの方がスマートなのは重々承知してますが・・・）。
いや、でも、ほんと、なんで見つからないんだろ。。。
☆☆☆☆☆☆ 宣伝 ☆☆☆☆☆☆
AIR版とブラウザ版（FireFox/Chrome/IEの動作を保証・・・するつもりでがんばってます。表示はしょぼいけど）の２種類のIFでいろんなニーズにお答えするオンライン＆オフライン付箋紙Push It!をどうぞよろしく。もちろん無償です。
ようやく解決方法が分かりました。
table要素とtr要素の間にtbody要素が必須、なみたいだ。
AJAXでない普通のHTMLだと、tbodyはオプションなのだが、なぜかAJAXだと厳密にその辺を要求するらしい。IEだけは。まだIE6でしかテストしてないけどIE7でも同じだろうな。
もちろんtbodyはあってもいい存在なので、FireFoxやChromeでもtbodyがあっても問題ない。よって、ブラウザ別にコードを分ける必要はなくて常にtbodyは入れておいて良い。
いやしかし、、、長かった。ここに至る道は、ほんとに。
どうやって検索しても見つからないんだもんな～。これって常識？
XML（もしくはJSON）を取り込んでそれを表に整形する、とかは見つかるんだけどね。別に自分はそんなにAJAXで取り込んだデータをあれやこれやと使いまわす気もなかったのでまんまHTMLを取り込んでそれをそのまま表示させていたのだけど、どうしてもだめならXMLで取り込んで整形して表示しようとも思ったりした。
そこまで思いつめてたのだ（ま、そっちの方がスマートなのは重々承知してますが・・・）。
いや、でも、ほんと、なんで見つからないんだろ。。。
☆☆☆☆☆☆ 宣伝 ☆☆☆☆☆☆
AIR版とブラウザ版（FireFox/Chrome/IEの動作を保証・・・するつもりでがんばってます。表示はしょぼいけど）の２種類のIFでいろんなニーズにお答えするオンライン＆オフライン付箋紙Push It!をどうぞよろしく。もちろん無償です。
2008年11月17日月曜日
「AIRのCookieの扱い」のその後
「AIRのCookieの扱い」
のエントリで書いたとおり、AIRがURLRequest等を使ってHTTPアクセスした場合のCookieはWindowsの場合はIEのCookieとして（Macの場合はSafariか？）保存される。
従って、AIRアプリからnavigateToURL関数でブラウザを開いた時、通常使うブラウザがIEでない場合Cookieが引き継がれないので、Cookieに認証情報を持たせていた場合、開いたブラウザの方で再度ログイン操作をユーザに強いることになって不便、という話を書いた。
で、しょうがないから以下のようにしてみた。
(1) AIRクライアントは、自分の使ってるCookieを知ってるので、navigateToURLを実行する時にクエリの一部としてCookieを持たせてやる。
(2) サーバ側にはそのクエリをCookieとして設定してやるページを特別に用意する。
(3) ブラウザは最初に(2)のページにアクセスしCookieが設定され、その後目的のページにリダイレクトする（そのように(2)を作っておく）。
（正しくはちょっと違うやり方を取ったけど、詳細は伏せておこう。大枠はこんな感じだ）
Cookieをクエリとして送るのはセキュリティ的にどうなのという気もしないではないが、そもそもCookie自体、毎HTTPアクセス毎に飛んでるわけで、それを見られたらセッションをのっとられることには変わりはない。そう考えると、ま、いっか、と思う。
どなたか反論があればお願いしまっす。
(2009.11追記)
補足が「AIRでCookieで」にあります。
☆☆☆☆☆☆☆ 宣伝です ☆☆☆☆☆☆☆
そんなことをしながらちょっとずつですが着実に使いやすくなりつつある付箋紙ソフト、Push It!をぜひ使ってみてください。
オンラインでもオフラインでも使えて知り合いと共有もできてWindowsでもMacでも使える付箋紙ソフトです。
興味がある人は右上のリンクから。
のエントリで書いたとおり、AIRがURLRequest等を使ってHTTPアクセスした場合のCookieはWindowsの場合はIEのCookieとして（Macの場合はSafariか？）保存される。
従って、AIRアプリからnavigateToURL関数でブラウザを開いた時、通常使うブラウザがIEでない場合Cookieが引き継がれないので、Cookieに認証情報を持たせていた場合、開いたブラウザの方で再度ログイン操作をユーザに強いることになって不便、という話を書いた。
で、しょうがないから以下のようにしてみた。
(1) AIRクライアントは、自分の使ってるCookieを知ってるので、navigateToURLを実行する時にクエリの一部としてCookieを持たせてやる。
(2) サーバ側にはそのクエリをCookieとして設定してやるページを特別に用意する。
(3) ブラウザは最初に(2)のページにアクセスしCookieが設定され、その後目的のページにリダイレクトする（そのように(2)を作っておく）。
（正しくはちょっと違うやり方を取ったけど、詳細は伏せておこう。大枠はこんな感じだ）
Cookieをクエリとして送るのはセキュリティ的にどうなのという気もしないではないが、そもそもCookie自体、毎HTTPアクセス毎に飛んでるわけで、それを見られたらセッションをのっとられることには変わりはない。そう考えると、ま、いっか、と思う。
どなたか反論があればお願いしまっす。
(2009.11追記)
補足が「AIRでCookieで」にあります。
☆☆☆☆☆☆☆ 宣伝です ☆☆☆☆☆☆☆
そんなことをしながらちょっとずつですが着実に使いやすくなりつつある付箋紙ソフト、Push It!をぜひ使ってみてください。
オンラインでもオフラインでも使えて知り合いと共有もできてWindowsでもMacでも使える付箋紙ソフトです。
興味がある人は右上のリンクから。
2008年11月15日土曜日
BloggerとAdSense
見て分かる通りこのブログはGoogleの提供するブログサービスであるBloggerを使ってます。
Bloggerはレイアウトを割と自由に設定できて、コンテンツの周りに自分の好きな部品を追加できたりします。
自分で作った部品でももちろんOKなんですが、Bloggerが用意してくれてる部品をはっつけるのももちろんアリです。
で、そんな用意された部品の中にAdSenseてーのがありまして、このページの右のエリアにある通りなんですが、ま、広告です。ページ表示回数やクリック回数によってブログの管理者に収益が発生する仕組みです。
で、さてさて一方そのAdSenseですが、当然こちらにも管理するためのページがございまして、自分が持っててAdSenseを貼り付けてあるページで、どのくらい表示されたか、クリックされたかがわかるようになってるんです。
が。
どうにもこうにもBloggerで表示されたはずのAdSenseが集計されていないような気がする。
AdSenseにはチャネルという名でサイトを管理してるのですが（厳密にはちょっと違うのかな？）、このブログのチャネルの集計を見てもデータがないとかぬかしおる。
そんなこんなで気になって調べてみると、
Bloggerで追加した広告をAdSenceでチャンネル管理できないのですか？
こんなページが見つかりました。
結論としては、チャネル別統計とサマリーの差分がどうやらBloggerで設定したAdSenseの結果のようだ。そしてカスタムチャネルでは集計されず、URLチャネルだとOKらしい。なるほど。。。
しかしそれじゃあ細かい分析ができんので、URLチャネルを使うか、AdSenseをBloggerの用意した部品ではなくHTML/JavaScriptコード貼り付けにすると行けそう。ということでそれぞれでトライ中。
しかし、部品を用意するのはいいけどその辺りまでちゃんと手を延ばして欲しいなあ。。。
どうもGoogleは新しいサービスをばんばん出すのはいいけど、その後のフォローがいまいちな感じがするのは自分だけか。
もはやMSやYahoo!も超えて業界を代表する企業になりつつあるのだから、そのあたりキッチリしてもらわないとね。そこらのベンチャーとは違うんだよ。
Bloggerはレイアウトを割と自由に設定できて、コンテンツの周りに自分の好きな部品を追加できたりします。
自分で作った部品でももちろんOKなんですが、Bloggerが用意してくれてる部品をはっつけるのももちろんアリです。
で、そんな用意された部品の中にAdSenseてーのがありまして、このページの右のエリアにある通りなんですが、ま、広告です。ページ表示回数やクリック回数によってブログの管理者に収益が発生する仕組みです。
で、さてさて一方そのAdSenseですが、当然こちらにも管理するためのページがございまして、自分が持っててAdSenseを貼り付けてあるページで、どのくらい表示されたか、クリックされたかがわかるようになってるんです。
が。
どうにもこうにもBloggerで表示されたはずのAdSenseが集計されていないような気がする。
AdSenseにはチャネルという名でサイトを管理してるのですが（厳密にはちょっと違うのかな？）、このブログのチャネルの集計を見てもデータがないとかぬかしおる。
そんなこんなで気になって調べてみると、
Bloggerで追加した広告をAdSenceでチャンネル管理
こんなページが見つかりました。
結論としては、チャネル別統計とサマリーの差分がどうやらBloggerで設定したAdSenseの結果のようだ。そしてカスタムチャネルでは集計されず、URLチャネルだとOKらしい。なるほど。。。
しかしそれじゃあ細かい分析ができんので、URLチャネルを使うか、AdSenseをBloggerの用意した部品ではなくHTML/JavaScriptコード貼り付けにすると行けそう。ということでそれぞれでトライ中。
しかし、部品を用意するのはいいけどその辺りまでちゃんと手を延ばして欲しいなあ。。。
どうもGoogleは新しいサービスをばんばん出すのはいいけど、その後のフォローがいまいちな感じがするのは自分だけか。
もはやMSやYahoo!も超えて業界を代表する企業になりつつあるのだから、そのあたりキッチリしてもらわないとね。そこらのベンチャーとは違うんだよ。
日本語を含むURLとChrome
ここを見にくるような人にとっては常識なのかも知れないが、URLはASCII文字列で構成しないといけないらしい。
UTF-8ですらなく、ASCIIなのだ。
これは歴史的なものもあるだろうし、そういうブラウザが世に出回ってしまっているから今更変えにくいのもあるのだろう。
なので、基本的に日本語をURLに乗せたいとなったら、サーバ側がデコーディングできる文字エンコード（Shift_JISとかUTF-8とか）にした上で、URLエンコード（っていうのかな？）、つまりASCII外の文字は%49%2a%45%acみたいな感じにしてやるべし、なのだそうだ（ASCII内でも?とか&とか%とかエスケープする必要のある文字もあるけど）。
で、そんなエンコードをしたURLをaタグのhrefの部分に指定してやると、ま、それをクリックしたらそのページに飛びますわな。で、ブラウザのロケーションエリアには当然そのページのURLが出ますわな。
・・・おや？？？こ、これは日本語だよな・・・。
そう。%エンコードしたはずのUTF-8文字列が日本語で表示されてるでないの。
え？ええぇ！？
とりあえず試した範囲ではFireFoxとChromeがこんな動作をする。IEはどうだか。
まあ、分かりやすくて良いではないか。。。
と、思いきや、そのURLをコピペして友達に教えたいってことがあったりしますよね。
なのでコピペして例えばメールにはっつけるとしますよね。すると、
・FireFoxは元の%エンコード形式のURLになる
・Chromeは表示した日本語そのまんまがペーストされる
なるほど、FireFoxすばらしい。この形式なら他のブラウザで開いてもちゃんと開けるはずだ。
しかし、Chromeよ。日本語にデコードしてしまったら、そのURLにはASCII文字でないものが含まれてしまうので、その辺をよきに計らってくれるブラウザでないと「そんなもんはない」と怒られてしまうではないか。
実際、FireFox→ChromeはOKだったが、Chrome→FireFoxはNGだった。そしてChrome→ChromeはOKだった。てめー自分だけ良けりゃいいのかよ。
それに、メーラーなどがURLを自動認識してクリックできるようになってたりする機能があるよね。
ああいうのって大体ASCII文字の連続してる部分だけを取り出すから日本語が含まれてると、それをURLとは認識してくれないのよね。
というわけで、URLの深遠に一歩近づきつつ、Chromeこのやろと思ったそんな一日であった。
☆☆☆☆☆宣伝です☆☆☆☆☆
そんな初心者なんだかマニアックなんだか良く分からない自分の作った「Push It! インターネット付箋紙」公開中です（右上のリンクからGO）。オンラインでもオフラインでも使える付箋紙です。
UTF-8ですらなく、ASCIIなのだ。
これは歴史的なものもあるだろうし、そういうブラウザが世に出回ってしまっているから今更変えにくいのもあるのだろう。
なので、基本的に日本語をURLに乗せたいとなったら、サーバ側がデコーディングできる文字エンコード（Shift_JISとかUTF-8とか）にした上で、URLエンコード（っていうのかな？）、つまりASCII外の文字は%49%2a%45%acみたいな感じにしてやるべし、なのだそうだ（ASCII内でも?とか&とか%とかエスケープする必要のある文字もあるけど）。
で、そんなエンコードをしたURLをaタグのhrefの部分に指定してやると、ま、それをクリックしたらそのページに飛びますわな。で、ブラウザのロケーションエリアには当然そのページのURLが出ますわな。
・・・おや？？？こ、これは日本語だよな・・・。
そう。%エンコードしたはずのUTF-8文字列が日本語で表示されてるでないの。
え？ええぇ！？
とりあえず試した範囲ではFireFoxとChromeがこんな動作をする。IEはどうだか。
まあ、分かりやすくて良いではないか。。。
と、思いきや、そのURLをコピペして友達に教えたいってことがあったりしますよね。
なのでコピペして例えばメールにはっつけるとしますよね。すると、
・FireFoxは元の%エンコード形式のURLになる
・Chromeは表示した日本語そのまんまがペーストされる
なるほど、FireFoxすばらしい。この形式なら他のブラウザで開いてもちゃんと開けるはずだ。
しかし、Chromeよ。日本語にデコードしてしまったら、そのURLにはASCII文字でないものが含まれてしまうので、その辺をよきに計らってくれるブラウザでないと「そんなもんはない」と怒られてしまうではないか。
実際、FireFox→ChromeはOKだったが、Chrome→FireFoxはNGだった。そしてChrome→ChromeはOKだった。てめー自分だけ良けりゃいいのかよ。
それに、メーラーなどがURLを自動認識してクリックできるようになってたりする機能があるよね。
ああいうのって大体ASCII文字の連続してる部分だけを取り出すから日本語が含まれてると、それをURLとは認識してくれないのよね。
というわけで、URLの深遠に一歩近づきつつ、Chromeこのやろと思ったそんな一日であった。
☆☆☆☆☆宣伝です☆☆☆☆☆
そんな初心者なんだかマニアックなんだか良く分からない自分の作った「Push It! インターネット付箋紙」公開中です（右上のリンクからGO）。オンラインでもオフラインでも使える付箋紙です。
2008年11月12日水曜日
2008年11月2日日曜日
とりあえず公開
ここのブログで今までぶちぶち言ってきたGAEとAIRを使い、インターネットにデータを保存することによって実現した「どこでも付箋紙ソフト（でもオフラインでも使えるぞ）」、Push It!を公開します。
Push It! インターネット付箋紙
まだベータ版ですが、興味があったら使ってみてください。
（サイトになんの説明もないので、ちと戸惑うかも知れませんが、ま、色々いじってみてください）
機能も少しずつ増やしていきますので、ご愛顧ください。
あ、大事なことを言い忘れた。IEだとまだうまく動かないところがあります。
☆11/20追記。
AJAXで取り込んだHTMLのtable要素が表示されない件
で書いたようにIEでもちゃんと動作するようになりました。IEユーザの方もご利用ください。
Push It! インターネット付箋紙
まだベータ版ですが、興味があったら使ってみてください。
（サイトになんの説明もないので、ちと戸惑うかも知れませんが、ま、色々いじってみてください）
機能も少しずつ増やしていきますので、ご愛顧ください。
あ、大事なことを言い忘れた。IEだとまだうまく動かないところがあります。
☆11/20追記。
AJAXで取り込んだHTMLのtable要素が表示されない件
で書いたようにIEでもちゃんと動作するようになりました。IEユーザの方もご利用ください。
2008年10月31日金曜日
SDKの管理コンソールを本番サーバでも使う
Google App EngineのSDKについて
のエントリで書いたけど、今までもSDK（ローカルの試験環境）では、memcacheを参照する仕組みがあったのだ。だけど本番サーバ上にはなくて、どうしたもんだろと思ってたのですが、
アプリの構成 - Google App Engine - Google Code
にずばりと書いてあるじゃないですか！
つまりこれはSDKの管理コンソールと同じものをSDKでも使えるようにするにはこうするんですよ～、というものなのだ。
で、早速やってみたさ。
すると、Pythonのエラースタックのようなものが。。。いや、幻じゃない、ほんとにエラーだ。
なんだよ！
管理コンソールのデフォルトページがDatastore関連のページなんだけど、ここで、DatastoreAPIにアクセスしようとして失敗しているようだ。
なんで？なんででもないか。SDK環境と本番環境じゃあDatastoreへのアクセス方法が違うんだろうし。 Datastoreは本番サーバ本来の管理コンソールからアクセスできるし、それが表示できなくても困る事はない。
でもそれがデフォルトページだとちょっと困るなあ。
ま、でも、
<管理コンソールのURL>/memcache
とするとmemcache用のページがちゃんと表示されたから良しとするか。
のエントリで書いたけど、今までもSDK（ローカルの試験環境）では、memcacheを参照する仕組みがあったのだ。だけど本番サーバ上にはなくて、どうしたもんだろと思ってたのですが、
アプリの構成 - Google App Engine - Google Code
にずばりと書いてあるじゃないですか！
つまりこれはSDKの管理コンソールと同じものをSDKでも使えるようにするにはこうするんですよ～、というものなのだ。
で、早速やってみたさ。
すると、Pythonのエラースタックのようなものが。。。いや、幻じゃない、ほんとにエラーだ。
なんだよ！
管理コンソールのデフォルトページがDatastore関連のページなんだけど、ここで、DatastoreAPIにアクセスしようとして失敗しているようだ。
なんで？なんででもないか。SDK環境と本番環境じゃあDatastoreへのアクセス方法が違うんだろうし。 Datastoreは本番サーバ本来の管理コンソールからアクセスできるし、それが表示できなくても困る事はない。
でもそれがデフォルトページだとちょっと困るなあ。
ま、でも、
<管理コンソールのURL>/memcache
とするとmemcache用のページがちゃんと表示されたから良しとするか。
勘弁してください、のその後
勘弁してください、ほんと・・・
で書いた、memcache排他の件だが、とりあえず以下のように回避しました。
１．memcacheをgetする。
２．memcacheに「使用中です」と書いてあったら、memcacheをgetしつつループで使用中でなくなるのを待つ。
３．memcacheに「使用中です」という値を追加して、setする。
４．やりたい処理をする。
５．「使用中です」を取り去って更新したmemcacheを書き込む。
set直後にgetしても値は更新されたものが取れるので、別プロセスが「使用中なのに使用中でなく見える」ということはなさそう。
ただこれも厳密には、１～３の間に、別プロセスの処理で１がきちゃったらアウト。でもそこまでは考えないようにしよう。
で書いた、memcache排他の件だが、とりあえず以下のように回避しました。
１．memcacheをgetする。
２．memcacheに「使用中です」と書いてあったら、memcacheをgetしつつループで使用中でなくなるのを待つ。
３．memcacheに「使用中です」という値を追加して、setする。
４．やりたい処理をする。
５．「使用中です」を取り去って更新したmemcacheを書き込む。
set直後にgetしても値は更新されたものが取れるので、別プロセスが「使用中なのに使用中でなく見える」ということはなさそう。
ただこれも厳密には、１～３の間に、別プロセスの処理で１がきちゃったらアウト。でもそこまでは考えないようにしよう。
2008年10月30日木曜日
appcfg.py プロキシ
どうもこのブログ、
「appcfg.py プロキシ」
とかで検索で引っ掛けてくる人が多いようなのは気づいていたんですが、今日ふと思い立って自分でも検索してみたんですよ。
そしたらまあ２ページ目くらいに出てくるんですけどね、クリックするとこのブログの一番最初のエントリが表示されたりするんですよ！
こらBlogger！もしくはGoogleインデックス！
おかげで、訪れた人が「それってどこやねん」て探し回ってくれるので、訪問あたりのページビューは上がるんですがね。。。でも不憫です。
このキーワードで引っ掛けた人。お探しのページは
http://pushit-dev.blogspot.com/2008/09/appcfgpy.html
になっておりますよ。
てかな～、どうなんだこれは。インデックスが更新されてないだけかなぁ？
「appcfg.py プロキシ」
とかで検索で引っ掛けてくる人が多いようなのは気づいていたんですが、今日ふと思い立って自分でも検索してみたんですよ。
そしたらまあ２ページ目くらいに出てくるんですけどね、クリックするとこのブログの一番最初のエントリが表示されたりするんですよ！
こらBlogger！もしくはGoogleインデックス！
おかげで、訪れた人が「それってどこやねん」て探し回ってくれるので、訪問あたりのページビューは上がるんですがね。。。でも不憫です。
このキーワードで引っ掛けた人。お探しのページは
http://pushit-dev.blogspot.com/2008/09/appcfgpy.html
になっておりますよ。
てかな～、どうなんだこれは。インデックスが更新されてないだけかなぁ？
ああ、そういえば
思うところあって、Google App EngineでのHTTPSの使い方を調べようと思って検索してみたら、つい最近、
https サポート - Google-App-Engine-Japan | Google グループ
というエントリができておりましたとさ。
最近なのか。確かに前に単にURLをhttpsに変えてやってみた時はダメで、急ぎでもなかったから深く調べることもなくそのまま放置してたのだが、やっぱり前はダメだったのね。
そういえば、GAEを使ってる人は知ってると思うけど、GAEの管理コンソールからDashboardを開くと、「Application Quotas」の欄に、
・Data Sent(HTTPS)
・Data Received(HTTPS)
という２つの項目が増えてた。
HTTPよりはHTTPSの方が多少なりとも負荷はかかるはずだが、Quota値はHTTPと同じ。太っ腹。
（でも自分の場合はCPUの方が先に引っかかりそうだが。。。）
Quotaが同じなんだったら、ユーザの入力したデータを扱うようなページは基本的にHTTPSにしちゃおうかな～、とか思ったりしてます。レスポンスが（ほとんど変わらないと思うけど）多少は落ちるのかな？
https サポート - Google-App-Engine-Japan | Google グループ
というエントリができておりましたとさ。
最近なのか。確かに前に単にURLをhttpsに変えてやってみた時はダメで、急ぎでもなかったから深く調べることもなくそのまま放置してたのだが、やっぱり前はダメだったのね。
そういえば、GAEを使ってる人は知ってると思うけど、GAEの管理コンソールからDashboardを開くと、「Application Quotas」の欄に、
・Data Sent(HTTPS)
・Data Received(HTTPS)
という２つの項目が増えてた。
HTTPよりはHTTPSの方が多少なりとも負荷はかかるはずだが、Quota値はHTTPと同じ。太っ腹。
（でも自分の場合はCPUの方が先に引っかかりそうだが。。。）
Quotaが同じなんだったら、ユーザの入力したデータを扱うようなページは基本的にHTTPSにしちゃおうかな～、とか思ったりしてます。レスポンスが（ほとんど変わらないと思うけど）多少は落ちるのかな？
2008年10月29日水曜日
AIRのCookieの扱い
常識なのかも知れないが、知ってる人は知っている、知らない人は知らないと思うので（当たり前だ）、備忘録程度に書いておこう。
AIRは（いやFlash/Flexもだが）HTTPを簡単に扱うことができる。
で、Flash/Flexの場合はWebブラウザの中で動くので、キャッシュやCookieはそのブラウザに保存されるだろうと誰もが思う。その通り。
しかしAIRアプリはブラウザの中で動いているわけじゃないので、キャッシュはまあAIRアプリから使うことはないだろうからいいとして、Cookieはどうしてるのだろうか。自前で保管する仕組みを持ってるのだろうか。などと思ったりする。
だが、いきなり結論。AIRアプリは自前でCookieを持たない。じゃあ、誰が持っててくれるのか。
WindowsならIE、MacならSafari、が持つことになってるらしい。
ま、確かにその２つなら必ず入ってるはずだからね。
（Linux版AIRはどうするのだろう・・・）
これはWindowsでいう「通常使うブラウザ（だったっけ？）」に何を指定しても同じこと。
で、それが悲しい事態を招くのだ。
困った。
Adobeに泣きついてなんとかなる話でもない。メジャーどころならともかく、Adobeのあずかり知らぬブラウザも含めて、AIRからブラウザを起動する時に、AIRの知ってるCookieを起動するブラウザに引き渡せ、ってことだから。
Cookieじゃなくて、アカウント情報（ユーザ名とかパスワード）をAIRアプリで覚えておいて、GETやPOSTのパラメータとして引き渡すことならできるんじゃないか？という意見もあろうかと思う。イグザクトリィ！その通り。
わかっちゃいるのだ。
が、如何せん相手がGoogleアカウントであって、自前の認証機構ではないのだよ。もちろんGoogleアカウントの認証プロキシを作りたいわけもない。さて・・・困ったな。
(2009.11追記)
その後の顛末は『「AIRのCookieの扱い」のその後』に、
補足が『AIRでCookieで』にあります。
AIRは（いやFlash/Flexもだが）HTTPを簡単に扱うことができる。
で、Flash/Flexの場合はWebブラウザの中で動くので、キャッシュやCookieはそのブラウザに保存されるだろうと誰もが思う。その通り。
しかしAIRアプリはブラウザの中で動いているわけじゃないので、キャッシュはまあAIRアプリから使うことはないだろうからいいとして、Cookieはどうしてるのだろうか。自前で保管する仕組みを持ってるのだろうか。などと思ったりする。
だが、いきなり結論。AIRアプリは自前でCookieを持たない。じゃあ、誰が持っててくれるのか。
WindowsならIE、MacならSafari、が持つことになってるらしい。
ま、確かにその２つなら必ず入ってるはずだからね。
（Linux版AIRはどうするのだろう・・・）
これはWindowsでいう「通常使うブラウザ（だったっけ？）」に何を指定しても同じこと。
で、それが悲しい事態を招くのだ。
- IEとAIRアプリで同一のサイトに対して別々のアカウントが使えない。
知っての通りCookieはログインの結果を保存しておいて同一サイト内で、認証済みかどうかを確認するために使われたりすることが多いと思うのですが、AIRとIEでCookieを共有しているせいで、どっちかでログアウトすると両方とも未認証の状態にされてしまうのだ。
普通に使ってる分には特に問題ないのだが、Googleアカウントのように広範なサービスで同一Cookieを利用されてる場合はやっかいなのだ。ましてやGAEの認証機構（Googleアカウントを使わずに自前でやれなくもないんだが面倒）もGAEの管理者コンソールもどっちもGoogleアカウントなんだ。つまり、AIRアプリの試験をしていてログアウトしたら開発コンソールも未認証の状態にされてしまうってこと。（でもこの辺はちゃんと試したわけじゃないので、鵜呑みにしないように。時間があったら追試しますが） - AIRアプリでログインした状態で、AIRからブラウザを開くと未認証だったりする。
AIRにしろFlexにしろ、navigateToURLという関数を使うと、（擬似ではなく本物の）ブラウザが開きます。指定したURLの内容を表示して。
Flexから作ったFlashの場合だと、Flashはブラウザの中で動いてますから、当然同じ種類のブラウザが開きます。IEならIE、FireFoxならFireFox。当然Cookieは共有されてますよね。
でも、AIRの場合はブラウザの中で動いてません。じゃあ開かれるブラウザは何かっていうと、「通常使うブラウザ」に指定されているブラウザ。IEが嫌でFireFoxにしてるとかいう人も結構いるはずです。
で、何度も言うけど、AIRはIEとはCookieを共有してるけど、FireFoxとは共有してない。つまりAIRアプリがサイトから認証を受けた状態になってその証拠のCookieを持っていても、そこから開いたFireFoxが認証されているとは限らない、ということなのだ。
つまり「AIRアプリが接続できるようにしてある認証が必要なサイト」で、そのAIRアプリからブラウザを開くと、ユーザーは２回、認証情報を入力しないといけないってわけ。
困った。
Adobeに泣きついてなんとかなる話でもない。メジャーどころならともかく、Adobeのあずかり知らぬブラウザも含めて、AIRからブラウザを起動する時に、AIRの知ってるCookieを起動するブラウザに引き渡せ、ってことだから。
Cookieじゃなくて、アカウント情報（ユーザ名とかパスワード）をAIRアプリで覚えておいて、GETやPOSTのパラメータとして引き渡すことならできるんじゃないか？という意見もあろうかと思う。イグザクトリィ！その通り。
わかっちゃいるのだ。
が、如何せん相手がGoogleアカウントであって、自前の認証機構ではないのだよ。もちろんGoogleアカウントの認証プロキシを作りたいわけもない。さて・・・困ったな。
(2009.11追記)
その後の顛末は『「AIRのCookieの扱い」のその後』に、
補足が『AIRでCookieで』にあります。
2008年10月28日火曜日
CSSのシブい技
参照先のタイトルがそのものずばりを表しているのですが、
[CSS]高さの異なるカラムを揃えるスタイルシート
シ、シブい・・・。
要するにどの列も収まるくらいのピクセルサイズをpadding-bottomに、そのマイナス値をmargin-bottomに指定し、はみ出た部分はhiddenで隠してしまえぃ！ということのようだ。
いやいや、これ気づいた人エラいよ。
検索してみたら一発でしたが、それまではページのレンダリング終わった段階でJavaScriptで調整すんのかな～とかそんなことを考えたのですがCSSで済むなら何より。
どのくらい標準準拠なんだとか、どのくらい恒久性があるんだとか気にならないではないが、少なくともIE6/FF3/GCでは問題なく表示できたので良しとしよう。
しかし、この
[CSS]高さの異なるカラムを揃えるスタイルシート
シ、シブい・・・。
要するにどの列も収まるくらいのピクセルサイズをpadding-bottomに、そのマイナス値をmargin-bottomに指定し、はみ出た部分はhiddenで隠してしまえぃ！ということのようだ。
いやいや、これ気づいた人エラいよ。
検索してみたら一発でしたが、それまではページのレンダリング終わった段階でJavaScriptで調整すんのかな～とかそんなことを考えたのですがCSSで済むなら何より。
どのくらい標準準拠なんだとか、どのくらい恒久性があるんだとか気にならないではないが、少なくともIE6/FF3/GCでは問題なく表示できたので良しとしよう。
しかし、この
32768pxて値はどうなんでしょう。
2の15乗てことはわかるけど、16bit符号付整数だとMAXは32767なので収まらない（負のほうは収まる）し、32bitだと小さすぎるし。
CSS標準か何かで定められた最大値、なんすかね？それとも経験則のカタマリ？
2008年10月27日月曜日
勘弁してください、ほんと・・・
何度もお話しているように、Google App Engineにはmemcacheという仕組みがあって、簡易な（そして不揮発でない）データベースのように使えるので、うまく使えばデータベースアクセスを減らすことができ（GAEではDatastoreアクセス回数にもQuotaがかかっているのだ→詳しくは：Understanding Application Quotas with Google App Engineの辺を見ると良い）、かつレスポンスも多少なりとも早くなるのでGoodなのだ。
だがしかし、memcacheの痛いところはロックができないことで、２つのプロセス（GAEに限定すれば２つのHTTPリクエストの処理が、と言い換えてもいい）が同時に同じエントリを更新しようとすると、どっちが採用されるかわからない。これはレスポンスのために割り切ってることなのでしょうがない。memcacheのせいではない。
んで、アプリ側でそれを回避するように作りたいので、以下のようにしてみた。
１．更新するmemcacheデータを読み出す
２．更新するmemcacheデータをキャッシュから消す
３．何やら処理をする
４．memcacheをaddで更新する
addはエントリがあると失敗するので、同時に同じ処理が走れば、後続のプロセスはaddが失敗するはずなのだ。失敗したとわかれば、その後の処理のしようもあるってもんだ。再度１からやるとかね。
（一方のプロセスが１～２の間にいるときに、もう一方が１～４まで終わらせちゃうとデータの矛盾がおきるかも知れないがそこまで考えるのはやめておこう）
で、SDK環境ではうまく動きました。サーバにアップデートしました。
結果。複数プロセスを同時に走らせなくてもaddが失敗するでないの。。。また本物環境とSDK環境の差ですか。。。勘弁してください、ほんとに。。。
多分、類推なのだが、deleteのあと、しばらく置かないとエントリはまだあるとみなされてaddが失敗するのではなかろうか。
代わりにエントリがあろうがなかろうが値をmemcacheに書き込むsetを使ってみると、何事もなく成功する。・・・成功するが目的は達成できんのだよそれじゃあ！
むぅ。。。なんとかならんのかね。。。
だがしかし、memcacheの痛いところはロックができないことで、２つのプロセス（GAEに限定すれば２つのHTTPリクエストの処理が、と言い換えてもいい）が同時に同じエントリを更新しようとすると、どっちが採用されるかわからない。これはレスポンスのために割り切ってることなのでしょうがない。memcacheのせいではない。
んで、アプリ側でそれを回避するように作りたいので、以下のようにしてみた。
１．更新するmemcacheデータを読み出す
２．更新するmemcacheデータをキャッシュから消す
３．何やら処理をする
４．memcacheをaddで更新する
addはエントリがあると失敗するので、同時に同じ処理が走れば、後続のプロセスはaddが失敗するはずなのだ。失敗したとわかれば、その後の処理のしようもあるってもんだ。再度１からやるとかね。
（一方のプロセスが１～２の間にいるときに、もう一方が１～４まで終わらせちゃうとデータの矛盾がおきるかも知れないがそこまで考えるのはやめておこう）
で、SDK環境ではうまく動きました。サーバにアップデートしました。
結果。複数プロセスを同時に走らせなくてもaddが失敗するでないの。。。また本物環境とSDK環境の差ですか。。。勘弁してください、ほんとに。。。
多分、類推なのだが、deleteのあと、しばらく置かないとエントリはまだあるとみなされてaddが失敗するのではなかろうか。
代わりにエントリがあろうがなかろうが値をmemcacheに書き込むsetを使ってみると、何事もなく成功する。・・・成功するが目的は達成できんのだよそれじゃあ！
むぅ。。。なんとかならんのかね。。。
2008年10月21日火曜日
日本語化Eclipse
くどいようですが、Flex Builderが使えなくなってしまいました。
これまで、Google App EngineにアップするPythonスクリプト、HTMLコード、JavaScriptなどもFlex BuilderにAptanaとかPyDevとか入れて使ってたんですが（ベースがEclipseなんでね）、Flex Builderの起動すらできなくなってしまったので、これらの環境も一から作り直してたわけです。
で、最初にAptana StudioっていうWeb（特にAJAX）開発の超強力な（と言われている）環境を入れてみたんですが、まあ、普通に使えるんですが、メニューとかが日本語じゃないわけですよ。
ついでにベースのEclipseのバージョンも3.2で古かったりするので、気に食わねぇ、ってんで、Eclipse3.4（Ganymedeってーの？）にAptanaのEclipseプラグインと日本語化プラグインをぶち込んで、、、てなことをやろうと、ダウンロード＆展開＆インストールなんぞしつつ、その待ち時間に良く良く検索してみると、だ。
http://mergedoc.sourceforge.jp/index.html#/pleiades.html
あるじゃないいいものが！
しかも欲しいもの（Eclipse3.4＋日本語化＋Aptana＋PyDev）が全部入りのパッケージがあるでないの！
ああ、こんなステキなプロジェクトがあったのね。。。最近All-In-One-Eclipseってリリースされてないなあと思ったら、こういう形で存在してたか～！ステキだ！ステキすぎる！
これまで、Google App EngineにアップするPythonスクリプト、HTMLコード、JavaScriptなどもFlex BuilderにAptanaとかPyDevとか入れて使ってたんですが（ベースがEclipseなんでね）、Flex Builderの起動すらできなくなってしまったので、これらの環境も一から作り直してたわけです。
で、最初にAptana StudioっていうWeb（特にAJAX）開発の超強力な（と言われている）環境を入れてみたんですが、まあ、普通に使えるんですが、メニューとかが日本語じゃないわけですよ。
ついでにベースのEclipseのバージョンも3.2で古かったりするので、気に食わねぇ、ってんで、Eclipse3.4（Ganymedeってーの？）にAptanaのEclipseプラグインと日本語化プラグインをぶち込んで、、、てなことをやろうと、ダウンロード＆展開＆インストールなんぞしつつ、その待ち時間に良く良く検索してみると、だ。
http://mergedoc.sourceforge.jp/index.html#/pleiades.html
あるじゃないいいものが！
しかも欲しいもの（Eclipse3.4＋日本語化＋Aptana＋PyDev）が全部入りのパッケージがあるでないの！
ああ、こんなステキなプロジェクトがあったのね。。。最近All-In-One-Eclipseってリリースされてないなあと思ったら、こういう形で存在してたか～！ステキだ！ステキすぎる！
またプロキシ？
前のエントリで、Google App Engineのサーバへのファイルアップロードのコマンド（appcfg.py）がプロキシ環境だとうまく動かなくて、環境変数を設定するに至った話を書いたけど、また引っかかりました。プロキシ。
今度はAIR SDKです。
AIRの配布用ファイル（拡張子air）を作るために、今まではFlex Builderを使ってたんだけど、前に書いた通り試用期限切れで使えなくなっちゃったので、AIRのSDKに付属してるコマンドを使って自力で作るようにしたんです。で、家ではうまくいったんです。
しかし会社でやると（あ、もちろん休憩時間にやってんですけどね）、
Could not generate timestamp: timestamp.geotrust.com
こんなん出て怒られる。
なんのことやら全然想像がつかないので、ググって見る。と、あるもんだね、
http://www.fxug.net/modules/xhnewbb/viewtopic.php?topic_id=1681
この辺に書いてある通り、、、ていうか何を話してるのかついていけてないんだけど、要するにプロキシの設定をしてないとだめだそう。
・・・またプロキシですか・・・もういいです・・・。
と言いたいのだが、しぶしぶJavaのプロパティファイルにプロキシ設定を書いたところ、無事通るようになりました。万歳。
今度はAIR SDKです。
AIRの配布用ファイル（拡張子air）を作るために、今まではFlex Builderを使ってたんだけど、前に書いた通り試用期限切れで使えなくなっちゃったので、AIRのSDKに付属してるコマンドを使って自力で作るようにしたんです。で、家ではうまくいったんです。
しかし会社でやると（あ、もちろん休憩時間にやってんですけどね）、
Could not generate timestamp: timestamp.geotrust.com
こんなん出て怒られる。
なんのことやら全然想像がつかないので、ググって見る。と、あるもんだね、
http://www.fxug.net/modules/xhnewbb/viewtopic.php?topic_id=1681
この辺に書いてある通り、、、ていうか何を話してるのかついていけてないんだけど、要するにプロキシの設定をしてないとだめだそう。
・・・またプロキシですか・・・もういいです・・・。
と言いたいのだが、しぶしぶJavaのプロパティファイルにプロキシ設定を書いたところ、無事通るようになりました。万歳。
2008年10月19日日曜日
楽しかった日々の終焉
落ち込んでます。
前回ちょろっと書きましたが、Flex Builder3の60日試用版の試用期限が過ぎてしまったのです。
これがなくてもAIRの開発はできます。
Flex SDKとAIR SDKを入れればね。全部コマンドラインで。とほほ。
Flex Builder3はいわゆる統合開発環境ってやつで、
・構文解析、カラー化、アウトライン表示。
・インテリジェントな文字の補完。
・デバッガのブレークポイントが設定できるエディタ。
・インタラクティブなGUI設計。
など、Visual StudioとかEclipseとかNetBeansとかを使ってる人には当たり前な機能なんだけど、それがFlex/AIRの開発に使えるか、コマンドラインでがんばるかは本当に効率が雲泥の差なのだ。とほほ。
60日以内になんとか形に・・・はまあなったけど、広範なテストをしてない（周囲にすらアナウンスしていない）ので、まだまだいじる可能性が大きいだけに痛いすねぇ。
ま、ちゃんと買うべきなんですがね、本来。もしもAdSenseで儲かるようなことがあったらちゃんと買います。ごめんなさい。＞Adobe様
ちなみにオープンソースのOpenLaszloって知ってますか。これもAIRとかのアプリが作れるらしく、かつ無料の統合環境もあったはずだけど、Flex（MXML+ActionScript）とはソースコードレベルで互換性がない（コンパイルしたものはAIRランタイム上で動くんだから当然互換性がある）。似てるんだけどね、ソースコード。
今更乗り換えられないっす。。。最初からOpenLaszloでやるべきだったか。でも情報少ないだろうしなあ。。。
前回ちょろっと書きましたが、Flex Builder3の60日試用版の試用期限が過ぎてしまったのです。
これがなくてもAIRの開発はできます。
Flex SDKとAIR SDKを入れればね。全部コマンドラインで。とほほ。
Flex Builder3はいわゆる統合開発環境ってやつで、
・構文解析、カラー化、アウトライン表示。
・インテリジェントな文字の補完。
・デバッガのブレークポイントが設定できるエディタ。
・インタラクティブなGUI設計。
など、Visual StudioとかEclipseとかNetBeansとかを使ってる人には当たり前な機能なんだけど、それがFlex/AIRの開発に使えるか、コマンドラインでがんばるかは本当に効率が雲泥の差なのだ。とほほ。
60日以内になんとか形に・・・はまあなったけど、広範なテストをしてない（周囲にすらアナウンスしていない）ので、まだまだいじる可能性が大きいだけに痛いすねぇ。
ま、ちゃんと買うべきなんですがね、本来。もしもAdSenseで儲かるようなことがあったらちゃんと買います。ごめんなさい。＞Adobe様
ちなみにオープンソースのOpenLaszloって知ってますか。これもAIRとかのアプリが作れるらしく、かつ無料の統合環境もあったはずだけど、Flex（MXML+ActionScript）とはソースコードレベルで互換性がない（コンパイルしたものはAIRランタイム上で動くんだから当然互換性がある）。似てるんだけどね、ソースコード。
今更乗り換えられないっす。。。最初からOpenLaszloでやるべきだったか。でも情報少ないだろうしなあ。。。
2008年10月11日土曜日
Adobe AIRのTextArea
Push It!はサーバにGAE、クライアントにAdobe AIRを使用するので（つか現時点では公開してないけど）、Adobe AIRも触ってます。Flex Builder3の試用版使って（もうじき期限が切れてしまう・・・）。
そのAdobe AIR、内部にWebKitを持っているので、簡単なブラウザなんざ余裕で作れるのです。
で、画面表示用部品としてTextAreaという部品があって、そこのプロパティにhtmlTextというものがあるので、これはてっきりWebKitでHTMLをレンダリングしてくれるのかと思いきや、ものすごく制限されたHTMLしか扱えないのね。。。しょんぼり。
フォントの強調とかアンダーラインとかくらい。htmlTextという割にしょぼいぞ！せいぜい修飾されたテキストじゃねーか。こんにゃろ。
尚、フルHTMLをレンダリングするためにはHTMLというコンポーネントを使う（多分）が、これはAIR専用。できればFlash（ブラウザ内で動作）版とAIR版とを両方用意したくて、手をかけないようになるべくソースを共通化させようとするとこれは使えない。残念。
そのAdobe AIR、内部にWebKitを持っているので、簡単なブラウザなんざ余裕で作れるのです。
で、画面表示用部品としてTextAreaという部品があって、そこのプロパティにhtmlTextというものがあるので、これはてっきりWebKitでHTMLをレンダリングしてくれるのかと思いきや、ものすごく制限されたHTMLしか扱えないのね。。。しょんぼり。
フォントの強調とかアンダーラインとかくらい。htmlTextという割にしょぼいぞ！せいぜい修飾されたテキストじゃねーか。こんにゃろ。
尚、フルHTMLをレンダリングするためにはHTMLというコンポーネントを使う（多分）が、これはAIR専用。できればFlash（ブラウザ内で動作）版とAIR版とを両方用意したくて、手をかけないようになるべくソースを共通化させようとするとこれは使えない。残念。
2008年10月7日火曜日
SDK1.1.5リリース
Google App EngineのSDK1.1.5がリリースされました。
こちらへどうぞ。
（日本語のページのは1.1.0のままで古いから使わないほうが良いよ。←ていうかこれも何とかして欲しい）
リリースノートの超適当な訳はこちら。
→うおーこれこれ！これだよ前回のブログエントリで書いたのはさ！
ということで、だ。
例のContent-Typeの件、試してみましたよ。
結果OK!!!でした。ぐっじょぶ！SDKチーム！
これで、SDKと本番用でコードを分けずに済むよ。
こちらへどうぞ。
（日本語のページのは1.1.0のままで古いから使わないほうが良いよ。←ていうかこれも何とかして欲しい）
リリースノートの超適当な訳はこちら。
- Additional fixes for file paths on Windows and OSX.
- Sped up the datastore stub.
- Allow different types in list properties in datastore.Entity and Expando.
- Add add_multi and replace_multi to memcache API.
- Ignore errors from the API proxy when calling memcache read methods.
- Set the webapp Request charset property more accurately from CONTENT_TYPE.
→うおーこれこれ！これだよ前回のブログエントリで書いたのはさ！
- Fixed an issue in the development console with schema caching.
- Fixed an issue with StringListProperty not returning a class
- Fixed an issue in the development console where quotes couldn't be used within fields.
- Fixed an issue with TimeProperty("0:0") (midnight).
ということで、だ。
例のContent-Typeの件、試してみましたよ。
結果OK!!!でした。ぐっじょぶ！SDKチーム！
これで、SDKと本番用でコードを分けずに済むよ。
2008年10月2日木曜日
SDKのバグ？
Google App Engineネタです。
ブラウザから日本語を含む文字列をPOSTするとき、基本的にはGAEは文字コードをUTF-8として扱ってくれるようです。OK。
でも、POSTをXMLHttpRequest、いわゆるAJAX的な方法でSDKのサーバに投げると、そのデータをDatastoreに格納するところで怒られます。
File "C:\Program Files\Google\google_appengine\google\appengine\api\datastore_types.py", line 1092, in PackString
pbvalue.set_stringvalue(unicode(value).encode('utf-8'))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 0: ordinalnot in range(128)
こんな風に。
でもそもそもが、ブラウザからはUTF-8で送信されているはずで、エンコードの必要などないはずなのに。それに普通にフォームからPOSTした時は怒られないよ？
てーことで色々調べてみたら、フォームからの場合とAJAXからの場合とでHTTP Requestのヘッダがどのように違うかというと、
フォームの場合
'Content-Type': 'application/x-www-form-urlencoded'
AJAXの場合
'Content-Type': 'application/x-www-form-urlencoded; charset=utf-8'
ふむ。。。Content-Typeにcharsetが指定されてるかそうでないかね。なるほど。
ではこれをフォームに合わせて消してやれば同じ動きをするはず。
・・・で、うまくいかず。
自分が使ってるAJAX系ライブラリのmootoolsというやつで、このライブラリで、charsetだけを消す方法が見つけられず断念（数時間悩みましたけど）。
でもね、ちょっと待ってよ。そもそもcharsetでUTF-8って言ってるんだから、やっぱり変換の必要ないのは同じじゃね？と思う。
思ったところでSDKは聞いてくれないので、試しに「これはUTF-8の文字列ですよ～」と指定してUnicodeに変換する。
↓こんな感じ。
mydb.nihongo = unicode(self.request.get('nihongo'), 'UTF-8')
mydb.put()
OK。通りました。代わりにフォームから通らなくなりました・・・がっくし。
ブチギレ３秒前です。
もう、これって、SDKのバグじゃねーの？ってことで本番サーバに元のままでアップロードする。
・・・通った！！もちろんフォームからでもAJAXからでも。
ブチギレ0.1秒前、ギリギリでセーフです。
ですが、このままだとSDK環境でAJAXの試験ができないことには変わりないんで、困りましたねえ。
DeadlineExceededErrorの件で使ったみたいに、localhostで、かつ、charsetがありなら、って分岐を入れるのか？バカバカしい。ブチギレ。
自分の入れてるPythonとの相性でも悪いのかなあ？？？
ブラウザから日本語を含む文字列をPOSTするとき、基本的にはGAEは文字コードをUTF-8として扱ってくれるようです。OK。
でも、POSTをXMLHttpRequest、いわゆるAJAX的な方法でSDKのサーバに投げると、そのデータをDatastoreに格納するところで怒られます。
File "C:\Program Files\Google\google_appengine\google\appengine\api\datastore_types.py", line 1092, in PackString
pbvalue.set_stringvalue(unicode(value).encode('utf-8'))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 0: ordinalnot in range(128)
こんな風に。
でもそもそもが、ブラウザからはUTF-8で送信されているはずで、エンコードの必要などないはずなのに。それに普通にフォームからPOSTした時は怒られないよ？
てーことで色々調べてみたら、フォームからの場合とAJAXからの場合とでHTTP Requestのヘッダがどのように違うかというと、
フォームの場合
'Content-Type': 'application/x-www-form-urlencoded'
AJAXの場合
'Content-Type': 'application/x-www-form-urlencoded; charset=utf-8'
ふむ。。。Content-Typeにcharsetが指定されてるかそうでないかね。なるほど。
ではこれをフォームに合わせて消してやれば同じ動きをするはず。
・・・で、うまくいかず。
自分が使ってるAJAX系ライブラリのmootoolsというやつで、このライブラリで、charsetだけを消す方法が見つけられず断念（数時間悩みましたけど）。
でもね、ちょっと待ってよ。そもそもcharsetでUTF-8って言ってるんだから、やっぱり変換の必要ないのは同じじゃね？と思う。
思ったところでSDKは聞いてくれないので、試しに「これはUTF-8の文字列ですよ～」と指定してUnicodeに変換する。
↓こんな感じ。
mydb.nihongo = unicode(self.request.get('nihongo'), 'UTF-8')
mydb.put()
OK。通りました。代わりにフォームから通らなくなりました・・・がっくし。
ブチギレ３秒前です。
もう、これって、SDKのバグじゃねーの？ってことで本番サーバに元のままでアップロードする。
・・・通った！！もちろんフォームからでもAJAXからでも。
ブチギレ0.1秒前、ギリギリでセーフです。
ですが、このままだとSDK環境でAJAXの試験ができないことには変わりないんで、困りましたねえ。
DeadlineExceededErrorの件で使ったみたいに、localhostで、かつ、charsetがありなら、って分岐を入れるのか？バカバカしい。ブチギレ。
自分の入れてるPythonとの相性でも悪いのかなあ？？？
2008年9月24日水曜日
Google App Engineのアプリバージョン
GAEでは、アプリケーションのバージョンを、
app.yamlというファイルで指示するメジャーバージョンと、GAEサーバにアップロードする度にカウントアップされるマイナーバージョンの2つで管理していたようなので、変更してはアップロードを繰り返していたら、Push It!は、1.180とかとんでもないバージョンになっていました。
そう。なっていました。過去形。
いつの間にかマイナーバージョンの表示がなくなってます。
Dropboxを使い始めた時期とかぶるので、それが関係してるのかなあとか思ったけど、マイナーバージョン管理・参照するのはGAEサーバだけだと思うしなあ。SDKが見てるとしてもDropbox関係なさそうだし。
サーバの方もちまちまと手が入ってるのね～。と思た。
app.yamlというファイルで指示するメジャーバージョンと、GAEサーバにアップロードする度にカウントアップされるマイナーバージョンの2つで管理していたようなので、変更してはアップロードを繰り返していたら、Push It!は、1.180とかとんでもないバージョンになっていました。
そう。なっていました。過去形。
いつの間にかマイナーバージョンの表示がなくなってます。
Dropboxを使い始めた時期とかぶるので、それが関係してるのかなあとか思ったけど、マイナーバージョン管理・参照するのはGAEサーバだけだと思うしなあ。SDKが見てるとしてもDropbox関係なさそうだし。
サーバの方もちまちまと手が入ってるのね～。と思た。
2008年9月23日火曜日
プロキシ環境内のappcfg.py
Google App Engineの話。
会社内などで、社外に出るにはプロキシを通す必要がある場合がありますよね。
Ｇoogle Ａpp Ｅngineでコンテンツをサーバにアップロードするためにはappcfg.pyというコマンドを使ってHTTPで送信するのですが、これがＯＳの（というかWindowsならＩＥの、かな）プロキシ設定を勝手に使ってくれるわけではく、プロキシを環境変数に設定してやる必要があります。
で、ここ↓
http://code.google.com/intl/ja/appengine/docs/appcfgpy.html
に、どのように設定すればいいか書いてあります。解決。
・・・じゃなかったんだよ！
Windowsだけなのかな？ここに書いてある方法だけじゃHTTPS通信がこけるんです。
で、試行錯誤した結果、
https_proxy=http://.....
という環境変数を設定すれば通ることを確認した。
環境変数名はhttps_proxyだけど、値はhttp:で始まるとかわけわからんよ。。。
というか、ちゃんとどっかに書いておけ～！
会社内などで、社外に出るにはプロキシを通す必要がある場合がありますよね。
Ｇoogle Ａpp Ｅngineでコンテンツをサーバにアップロードするためにはappcfg.pyというコマンドを使ってHTTPで送信するのですが、これがＯＳの（というかWindowsならＩＥの、かな）プロキシ設定を勝手に使ってくれるわけではく、プロキシを環境変数に設定してやる必要があります。
で、ここ↓
http://code.google.com/intl/ja/appengine/docs/appcfgpy.html
に、どのように設定すればいいか書いてあります。解決。
・・・じゃなかったんだよ！
Windowsだけなのかな？ここに書いてある方法だけじゃHTTPS通信がこけるんです。
で、試行錯誤した結果、
https_proxy=http://.....
という環境変数を設定すれば通ることを確認した。
環境変数名はhttps_proxyだけど、値はhttp:で始まるとかわけわからんよ。。。
というか、ちゃんとどっかに書いておけ～！
2008年9月22日月曜日
Dropboxを使い始める
Google App Engineとはちょっと話題がずれますが、Dropboxっていうオンラインストレージ、知ってますか？
自分、家と会社の休み時間でちょこちょことコーディングしたりするので、ソースコードを持ちまわってたんですが、わりとめんどくさいんですよね。いちいち固めてUSBなり既存のオンラインストレージにアップして、またそれを解凍して配置して、、、って。
で、Dropboxなんですが、これ、OSのファイルシステムと統合されてるんです。
どういうことかというと、マイドキュメントに作られたMy Dropboxというフォルダに普通にファイルやフォルダを置いたり、更新したりすると、自動的にインターネット上のストレージと同期されるってわけ。
つまりこれまでのオンラインストレージのように、ローカルのファイルをわざわざ専用ツールやブラウザからアップしなくていいってこと。劇的に楽だ！
強いて言えばWindowsのオフラインフォルダのインターネット版のようなもの。
でもオフラインフォルダはオンライン状態では、共有ディスクの方が原本になるのに対して、こちらはインターネットというLANよりは信頼性の落ちるネットワークを使ってるので、ローカルディスクが原本となって、インターネット上へは逐次同期される感じ。rsyncのイメージ。
もちろんタイムラグは発生するわけですが、遅いネットワークにアップし終わるのを待たされるより全然いい。ファイルの書き込み時間はローカルと同等（ローカルだから当たり前だが）なので快適。素敵。
昔の「.Mac」。今の・・・なんだっけ？あれもインターネット上のフォルダをOSからシームレスに使えたけど、あれはネット上が原本だから、読み書きのレスポンスは期待できなかったし、ネット未接続だと使えない。でもDropboxはいい！
しかも変更前のファイルも保存してくれる（subversionのイメージ）とか、もう至れりつくせりだな、おい！
そんなわけでとても気に言ってます。
唯一気になるのは、ブラウザ用インタフェースが、シンプルなんだがなんだか微妙にしっくりこないこと、くらいかな。慣れればオッケー！
皆さんも使ってみてください。
自分、家と会社の休み時間でちょこちょことコーディングしたりするので、ソースコードを持ちまわってたんですが、わりとめんどくさいんですよね。いちいち固めてUSBなり既存のオンラインストレージにアップして、またそれを解凍して配置して、、、って。
で、Dropboxなんですが、これ、OSのファイルシステムと統合されてるんです。
どういうことかというと、マイドキュメントに作られたMy Dropboxというフォルダに普通にファイルやフォルダを置いたり、更新したりすると、自動的にインターネット上のストレージと同期されるってわけ。
つまりこれまでのオンラインストレージのように、ローカルのファイルをわざわざ専用ツールやブラウザからアップしなくていいってこと。劇的に楽だ！
強いて言えばWindowsのオフラインフォルダのインターネット版のようなもの。
でもオフラインフォルダはオンライン状態では、共有ディスクの方が原本になるのに対して、こちらはインターネットというLANよりは信頼性の落ちるネットワークを使ってるので、ローカルディスクが原本となって、インターネット上へは逐次同期される感じ。rsyncのイメージ。
もちろんタイムラグは発生するわけですが、遅いネットワークにアップし終わるのを待たされるより全然いい。ファイルの書き込み時間はローカルと同等（ローカルだから当たり前だが）なので快適。素敵。
昔の「.Mac」。今の・・・なんだっけ？あれもインターネット上のフォルダをOSからシームレスに使えたけど、あれはネット上が原本だから、読み書きのレスポンスは期待できなかったし、ネット未接続だと使えない。でもDropboxはいい！
しかも変更前のファイルも保存してくれる（subversionのイメージ）とか、もう至れりつくせりだな、おい！
そんなわけでとても気に言ってます。
唯一気になるのは、ブラウザ用インタフェースが、シンプルなんだがなんだか微妙にしっくりこないこと、くらいかな。慣れればオッケー！
皆さんも使ってみてください。
Google App EngineのSDKについて
DeadlineExceededErrorの話を前回書いたけれども、こいつにはもう一つ困ったことがあって、ローカル環境で開発するためのSDKにDeadlineExceededErrorクラスが存在しないの。
もちろん発生もしないのだが。
そのせいで、DeadlineExceededErrorのインポートでエラーになるから、ホストの判定がlocalhostだったらインポートしないようにしつつ、例外キャッチの部分ではどうしてもDeadlineExceededErrorを書かんとあかんので、ダミーのDeadlineExceededErrorクラスを定義してやるというような工夫を余儀なくされている。
インポートをifブロックに入れるなんてできるとは知らなかった頃は、ローカルの時はDeadlineExceededErrorをコメントアウトして、アップするときはコメントを消す、なんて涙ぐましい努力をしていたのだった。消し忘れてDeadlineExceededErrorをトラップできなかったりね。
ちなみにもう一つ、memcacheという非常に有効な仕組みがGAEにはある（というかGoogleが作ったわけじゃないので、使えるようにしてある、と言うのが正しいか）のだが、これも昔のSDKでは使えなかったようだ。
しかし、少なくともSDK1.1.1のあたりでは使えたはずだし、現時点で最新の1.1.3ではローカル環境の管理ツールで、memcacheの内容を確認できるようになった。めでたい！
でも逆に本番サーバ上で確認する方法はないのだろうか？？
追記：memcacheはSDK1.1.0から使えるようでした。
もちろん発生もしないのだが。
そのせいで、DeadlineExceededErrorのインポートでエラーになるから、ホストの判定がlocalhostだったらインポートしないようにしつつ、例外キャッチの部分ではどうしてもDeadlineExceededErrorを書かんとあかんので、ダミーのDeadlineExceededErrorクラスを定義してやるというような工夫を余儀なくされている。
インポートをifブロックに入れるなんてできるとは知らなかった頃は、ローカルの時はDeadlineExceededErrorをコメントアウトして、アップするときはコメントを消す、なんて涙ぐましい努力をしていたのだった。消し忘れてDeadlineExceededErrorをトラップできなかったりね。
ちなみにもう一つ、memcacheという非常に有効な仕組みがGAEにはある（というかGoogleが作ったわけじゃないので、使えるようにしてある、と言うのが正しいか）のだが、これも昔のSDKでは使えなかったようだ。
しかし、少なくともSDK1.1.1のあたりでは使えたはずだし、現時点で最新の1.1.3ではローカル環境の管理ツールで、memcacheの内容を確認できるようになった。めでたい！
でも逆に本番サーバ上で確認する方法はないのだろうか？？
追記：memcacheはSDK1.1.0から使えるようでした。
2008年9月19日金曜日
Google App Engineで遊んでいます。でも・・・
Google App Engine。知ってますか？
要するにホスティングサービスみたいなもんなんですけどね。
ただGoogleの潤沢なインフラを使える、無料、DBも（ちょっと変わってるけど）使える。などなどのメリットがあり、それで遊んでます。
でも、ちょいと困ったことがありまして、このGAEのサーバは、一つのHTTP Requestに対して8秒前後くらいでタイムアウトしてしまうのです。
で、それを放置すると、DeadlineExceededErrorというエラーが出てしまい、HTTPエラーが返ってしまうという仕様。
これをトラップして、DeadlineExceededErrorが出たらそれなりの正常応答を返すという方法もあって、
http://webdba.blogspot.com/2008/07/deadlineexceedederror.html
この辺を参考に、トラップして逃げることはできました。
しかし、ですよ。
どっ ちにしても８秒前後でタイムアウトしてしまうことには変わりないので、例えば誰かの書いたコメントを即時ブラウザに反映させるチャットのようなサービスを 作るためにComet的IFを用意したとすると、８秒に１回HTTP Requestを投げないといけないわけで、そうするとどうなるか。
８秒に１回HTTP Requestを投げ続けて、しばらくすると、
「Over Quota」
といって怒られる（HTTP Requestがはねられる）。
おいー、どないせいっちゅうねん！
いちお、GAEにはCPUだのストレージ容量だのに制限があって、気を付けてそれらをバカ食いしないようにしてるんですが、なぜか怒られます。
引っかかるとしたら単位時間あたりCPU使用時間くらいなんですが、このComet的IFの中身は９割以上sleep時間のはずで、そのくらいで引っかかっててもらったら全然楽しくないんですけど。
自分一人のためのサイトを作ってるなら我慢するけど、それだったらGAEのインフラなんぞ使う必要ないわー！と一人不満をためこんでいる毎日です。
英語が得意ならGAE担当に苦情のメールでも投げてやるんだが。。。
☆☆☆2009/12/26追記☆☆☆
あ～これ最初のエントリだったんだね～。
最新のDeadlineExceededErrorの情報については→ここ←が詳しいですよ。
で、相変わらずCometは使えませんが。
WebSocketとか後でいいから早くCometを・・・。
要するにホスティングサービスみたいなもんなんですけどね。
ただGoogleの潤沢なインフラを使える、無料、DBも（ちょっと変わってるけど）使える。などなどのメリットがあり、それで遊んでます。
でも、ちょいと困ったことがありまして、このGAEのサーバは、一つのHTTP Requestに対して8秒前後くらいでタイムアウトしてしまうのです。
で、それを放置すると、DeadlineExceededErrorというエラーが出てしまい、HTTPエラーが返ってしまうという仕様。
これをトラップして、DeadlineExceededErrorが出たらそれなりの正常応答を返すという方法もあって、
http://webdba.blogspot.com/2008/07/deadlineexceedederror.html
この辺を参考に、トラップして逃げることはできました。
しかし、ですよ。
どっ ちにしても８秒前後でタイムアウトしてしまうことには変わりないので、例えば誰かの書いたコメントを即時ブラウザに反映させるチャットのようなサービスを 作るためにComet的IFを用意したとすると、８秒に１回HTTP Requestを投げないといけないわけで、そうするとどうなるか。
８秒に１回HTTP Requestを投げ続けて、しばらくすると、
「Over Quota」
といって怒られる（HTTP Requestがはねられる）。
おいー、どないせいっちゅうねん！
いちお、GAEにはCPUだのストレージ容量だのに制限があって、気を付けてそれらをバカ食いしないようにしてるんですが、なぜか怒られます。
引っかかるとしたら単位時間あたりCPU使用時間くらいなんですが、このComet的IFの中身は９割以上sleep時間のはずで、そのくらいで引っかかっててもらったら全然楽しくないんですけど。
自分一人のためのサイトを作ってるなら我慢するけど、それだったらGAEのインフラなんぞ使う必要ないわー！と一人不満をためこんでいる毎日です。
英語が得意ならGAE担当に苦情のメールでも投げてやるんだが。。。
☆☆☆2009/12/26追記☆☆☆
あ～これ最初のエントリだったんだね～。
最新のDeadlineExceededErrorの情報については→ここ←が詳しいですよ。
で、相変わらずCometは使えませんが。
WebSocketとか後でいいから早くCometを・・・。
登録:
投稿 (Atom)