だいぶ前に、Flex Builderの期間限定試用版の期限が切れちゃって悲しい・・・という話を書きましたが、今日、ふと思い立って、
「eclipse actionscript」
とかやってみたところ、
でたーっ!
あるんだ、フリーのAIR/ActionScript開発環境が!
素敵だ!素敵すぎる!
AIR GEAR(またの名をAmaterasAIRというらしい。どっちが本名かはわからないが、EclipseにはAIR GEARという名前でしか登場しない)
まだまだ開発途上のようで、mxmlで書いた(コンパイルすればちゃんと表示される)フォームがWYSIWYGエディタでちゃんと表示されないとか、アウトライン表示がデフォルトOFFになってて、ONにできるけどテスト導入という注意書きがあったりするけど、それなりに使えます。いや、非常に使えます、と言っておこう!
Flex Builderと比べて機能は劣るわけだが、比べてはいけない。むしろフリーでここまでできることに感謝!
特にアウトライン表示は非常に嬉しい。いろんな関数を飛び回る時に、現状、古来より伝わる、
「関数の場所は行番号で覚える」
方法しかなかったので(あとは検索するか)、アウトラインからズバッと飛べるのはとても助かる。
なんだよ、こういうのがあるなら教えてよ~。
☆☆☆☆☆ 宣伝 ☆☆☆☆☆
そんなわけで、AIRクライアントの開発効率もズバッとアップするであろう、オンライン/オフライン付箋紙ソフトPush It!をぜひご使用ください。
準公式サポートページもあります。右上のリンクから。
2009年12月11日金曜日
2009年12月1日火曜日
2009年11月29日日曜日
GAEのGoogleアカウント利用
Googleアカウントを使ってユーザ認証をおこなうためのAPIがGAEには用意されています(多分PythonでもJavaでも)。
ただ、この認証結果はCookieに保存されるんですが、その保持期間が1日しかなくて、24時間以上空けてアクセスすると、再度認証しないといけなくなってました。
毎日のようにアクセスするサイトでもない限りそれは鬱陶しいですよね・・・。平日は使うけど、土日は使わない、とか、その逆とかもあるし。
認証及びその結果としてのCookieを管理しているのはGAEのアプリケーションではなくてGAEのAPIなので、そのあたりはアプリケーション開発者としては手出しできない(したくもないし。大変だから)ため、どうにかしてくれないかなあ、と思っていました。
が、GAEの設定画面[Application Settings]を開くと、Cookieの保持期間が選べるようになっているではないか!
これって前からありました?
ということでPush It!は早速1日から1週間に変更しましたよ、と。
設定画面って、時々こっそりとメニューが増えてたりするんですよね。マメに見ないとダメですね。
☆☆☆☆☆ 宣伝 ☆☆☆☆☆
会社にいる平日にしか使わないので、土日をはさんで月曜日に出社したら再度ログインを求められてうざったい!なんてこともなくなった(汗)、
オンライン/オフライン二刀流付箋紙ソフトPush It!
はβ版ですが、地味~にバージョンアップを続けてますので、ぜひ使ってみてください。
ただ、この認証結果はCookieに保存されるんですが、その保持期間が1日しかなくて、24時間以上空けてアクセスすると、再度認証しないといけなくなってました。
毎日のようにアクセスするサイトでもない限りそれは鬱陶しいですよね・・・。平日は使うけど、土日は使わない、とか、その逆とかもあるし。
認証及びその結果としてのCookieを管理しているのはGAEのアプリケーションではなくてGAEのAPIなので、そのあたりはアプリケーション開発者としては手出しできない(したくもないし。大変だから)ため、どうにかしてくれないかなあ、と思っていました。
が、GAEの設定画面[Application Settings]を開くと、Cookieの保持期間が選べるようになっているではないか!
これって前からありました?
ということでPush It!は早速1日から1週間に変更しましたよ、と。
設定画面って、時々こっそりとメニューが増えてたりするんですよね。マメに見ないとダメですね。
☆☆☆☆☆ 宣伝 ☆☆☆☆☆
会社にいる平日にしか使わないので、土日をはさんで月曜日に出社したら再度ログインを求められてうざったい!なんてこともなくなった(汗)、
オンライン/オフライン二刀流付箋紙ソフトPush It!
はβ版ですが、地味~にバージョンアップを続けてますので、ぜひ使ってみてください。
2009年11月3日火曜日
AIRでCookieで
ここのブログにやってくる人は「adobe air cookie」なんかでググってくる人が多いみたいなんだけど、せっかく来てもらって、間違った前提で理解されると「嘘つき!」って言われちゃうので、一応フォローしておきますね。
過去エントリ、
・AIRのCookieの扱い
・「AIRのCookieの扱い」のその後
で、問題にしたのは、あくまでも、
CookieをAIRとブラウザの間で共有したい時
なんです。
共有したいのはIEかもしれないしFireFoxかも知れないしChromeかもしれない。でも、Cookieの保存先はIEと一緒(Windowsの場合ね。MacはSafari)なので、普段使うブラウザFireFoxなんだけどな~、な場合に困っちゃうよね、という話です。
それ以外のケースでは上記のキーワードで検索しないかな。
例えば、ブラウザに渡したいわけじゃなくて、自分で自由にCookieを扱いたいんだ!という意思をお持ちの方は、いちお、AIRも自前でCookieは扱えます。すんごくがんばる必要がありそうですが(ただしFlex方式の開発の場合のみ。FlashやHTML方式は分かりません・・・)。
自分が困ったのは、自前でCookieを扱ったところで、ブラウザに渡す手段がない!ということで「その後」において、サーバを経由してCookieをAIRからブラウザに渡す技に思い至ったというわけ。
自前で扱う方法はここには書いてませんので、「ちっ、使えん」とか言って他をあたってみてください。ごめんなさい。
過去エントリ、
・AIRのCookieの扱い
・「AIRのCookieの扱い」のその後
で、問題にしたのは、あくまでも、
CookieをAIRとブラウザの間で共有したい時
なんです。
共有したいのはIEかもしれないしFireFoxかも知れないしChromeかもしれない。でも、Cookieの保存先はIEと一緒(Windowsの場合ね。MacはSafari)なので、普段使うブラウザFireFoxなんだけどな~、な場合に困っちゃうよね、という話です。
それ以外のケースでは上記のキーワードで検索しないかな。
例えば、ブラウザに渡したいわけじゃなくて、自分で自由にCookieを扱いたいんだ!という意思をお持ちの方は、いちお、AIRも自前でCookieは扱えます。すんごくがんばる必要がありそうですが(ただしFlex方式の開発の場合のみ。FlashやHTML方式は分かりません・・・)。
自分が困ったのは、自前でCookieを扱ったところで、ブラウザに渡す手段がない!ということで「その後」において、サーバを経由してCookieをAIRからブラウザに渡す技に思い至ったというわけ。
自前で扱う方法はここには書いてませんので、「ちっ、使えん」とか言って他をあたってみてください。ごめんなさい。
2009年10月28日水曜日
GAEでのメール受信
そうそう、SDK1.2.6でプロキシにやられた俺ですが、一つ朗報もありました。
メールの受信機能が付いたことです。
(SDKだけでなく本物のGAEサーバもこのタイミングでサポートだと思う)
素晴らしい!んですが、、、てこずってます。
文字エンコードの問題なのかなんなのか、受信したメールの本文がうまく取れません。
で、その辺がドキュメントにちゃんと記されてないんですよね。読み方が甘いのかなあ。
これができるようになったらPush It!に、メールから付箋紙投稿なんて機能もつけられると思うんです。
あともうちょっとだ、がんばれ!
2010/3/29続報
「GAEでのメール受信」のその後にて、文字コードを取得する方法を書きました。一歩前進。
☆☆☆☆☆☆ Push It!の宣伝 ☆☆☆☆☆☆
将来的には、メールで付箋紙投稿もできちゃう(笑)オンライン付箋紙ソフト、Push It!は、右上のリンクから。
メールの受信機能が付いたことです。
(SDKだけでなく本物のGAEサーバもこのタイミングでサポートだと思う)
素晴らしい!んですが、、、てこずってます。
文字エンコードの問題なのかなんなのか、受信したメールの本文がうまく取れません。
で、その辺がドキュメントにちゃんと記されてないんですよね。読み方が甘いのかなあ。
これができるようになったらPush It!に、メールから付箋紙投稿なんて機能もつけられると思うんです。
あともうちょっとだ、がんばれ!
2010/3/29続報
「GAEでのメール受信」のその後にて、文字コードを取得する方法を書きました。一歩前進。
☆☆☆☆☆☆ Push It!の宣伝 ☆☆☆☆☆☆
将来的には、メールで付箋紙投稿もできちゃう(笑)オンライン付箋紙ソフト、Push It!は、右上のリンクから。
appcfg.py プロキシ、最近
このタイトルでこのブログを見に来た方、残念でした。
前に同じタイトルで、GAEにファイルをアップロードするappcfg.pyをプロキシの中から使うようにする方法を書いたのですが、、、
なんだか分かりませんが、GAEのSDKを1.2.7にしたらhttpsプロキシ経由のアップロードが失敗するようになってしまいました。
尚、appcfg.pyとプロキシに関するGoogle様の正式なドキュメントは、
Uploading and Managing a Python App
でございます(日本語版のページはちょっと古いので参照しないように)。
ま、書いてある通りに動けば何も悩むことはないんですがね。
SDKのリリースノートを探ると、1.2.6の時に、
・Appcfg now uses https by default.
こんな記述があります。
・・・あれ?今までってhttps使ってなかったの?ほんと?
疑問は尽きないが、これが影響した可能性大。
(多分)既存の動作と同じだと思われる動作をさせるためには、--insecureオプションを付けてやると良いです。とにかくセキュアだろうがなんだろうがアップロードできりゃいいんじゃい!っていうなら、それで解決です。
しかし!それってなんか怖いなあ。httpsでアップロードしたいよう。せめて認証くらいはhttpsでやって欲しい。
--insecureをつけない場合に、プロキシ君にはじかれてしまうわけですが、Wiresharkでちょろっと見たところ、httpsなのにプロキシサーバにGETを要求してやがる。HTTPSなんだからそこはCONNECTでしょ!?GETじゃ失敗するよ、そりゃあ。(追記:必ずしもCONNECTでないと失敗するわけでもない模様。認証そのものはPOST over HTTPSでやっていて、それは成功している。謎)
原因がappcfg.pyなのか、pythonのHTTP/HTTPS要求ライブラリなのかわかりませんが、なんとかならんものか。
前に同じタイトルで、GAEにファイルをアップロードするappcfg.pyをプロキシの中から使うようにする方法を書いたのですが、、、
なんだか分かりませんが、GAEのSDKを1.2.7にしたらhttpsプロキシ経由のアップロードが失敗するようになってしまいました。
尚、appcfg.pyとプロキシに関するGoogle様の正式なドキュメントは、
Uploading and Managing a Python App
でございます(日本語版のページはちょっと古いので参照しないように)。
ま、書いてある通りに動けば何も悩むことはないんですがね。
SDKのリリースノートを探ると、1.2.6の時に、
・Appcfg now uses https by default.
こんな記述があります。
・・・あれ?今までってhttps使ってなかったの?ほんと?
疑問は尽きないが、これが影響した可能性大。
(多分)既存の動作と同じだと思われる動作をさせるためには、--insecureオプションを付けてやると良いです。とにかくセキュアだろうがなんだろうがアップロードできりゃいいんじゃい!っていうなら、それで解決です。
しかし!それってなんか怖いなあ。httpsでアップロードしたいよう。せめて認証くらいはhttpsでやって欲しい。
--insecureをつけない場合に、プロキシ君にはじかれてしまうわけですが、Wiresharkでちょろっと見たところ、httpsなのにプロキシサーバにGETを要求してやがる。HTTPSなんだからそこはCONNECTでしょ!?GETじゃ失敗するよ、そりゃあ。(追記:必ずしもCONNECTでないと失敗するわけでもない模様。認証そのものはPOST over HTTPSでやっていて、それは成功している。謎)
原因がappcfg.pyなのか、pythonのHTTP/HTTPS要求ライブラリなのかわかりませんが、なんとかならんものか。
2009年10月1日木曜日
DropboxがiPhoneからアクセスできるようになった模様
自分はiPhoneもiPod touchも持ってないので関係ないですが。
オンラインファイル共有サービスのDropboxを前に紹介しましたが、その後ZumoDriveという強力なライバルが現れて、Web上の評価では「お互いの長所・短所があるので使い分けだよね?」的な論調が多いようです。
差分としては、
・Dropboxは、共有ファイルは全てローカルにも置かれる。ZumoDriveはキャッシュとして設定したサイズの分だけ置かれる。つまり全てのファイルにローカル並みの速度でアクセスしたいか、オフライン状態でも全てのファイルを触れないと困るならDropbox、そんなのは不要で、ローカルHDDに容量が心もとないので拡張する意図があるならZumoDriveを使う、という棲み分け。
・iPhoneアプリがZumoDriveにはあり、Dropboxにはない。
・無料で使える容量が、Dropboxは2GB、ZumoDriveは1GB
とかいうあたりか。
で、2つ目のiPhoneアプリについて、近頃Dropbox用が登場したらしいです。
自分関係ないですが、Dropbox派としては「Dropboxを選ばない理由」が一つ減ってめでたいな、と思った。
オンラインファイル共有サービスのDropboxを前に紹介しましたが、その後ZumoDriveという強力なライバルが現れて、Web上の評価では「お互いの長所・短所があるので使い分けだよね?」的な論調が多いようです。
差分としては、
・Dropboxは、共有ファイルは全てローカルにも置かれる。ZumoDriveはキャッシュとして設定したサイズの分だけ置かれる。つまり全てのファイルにローカル並みの速度でアクセスしたいか、オフライン状態でも全てのファイルを触れないと困るならDropbox、そんなのは不要で、ローカルHDDに容量が心もとないので拡張する意図があるならZumoDriveを使う、という棲み分け。
・iPhoneアプリがZumoDriveにはあり、Dropboxにはない。
・無料で使える容量が、Dropboxは2GB、ZumoDriveは1GB
とかいうあたりか。
で、2つ目のiPhoneアプリについて、近頃Dropbox用が登場したらしいです。
自分関係ないですが、Dropbox派としては「Dropboxを選ばない理由」が一つ減ってめでたいな、と思った。
登録:
投稿 (Atom)