特集DraftPad/短期集中連載
D箱のアシスト事件
第7夜. 永遠のプライベートベータ
実はそれ以前に、Dropbox に配置したファイルと YQL を使った最初のバージョンが出来上がった時点で、一度、公開申請を出していたのでした。おっちょこちょいなぼくは、Dropbox の説明をろくに確認もせず、どうせ形式的なものだろうとタカを括り、紹介文にはアプリのタイトルとキャッチフレーズのようなものをやはりインチキな英語で一文添えただけでした。アシストをインポートするための URL も書きませんでした。
ちなみにアプリの名前は「DraftPad Assist - Path to Dropbox」としました。素直に考えれば Save to Dropbox ですけど、それだと公式のアシストとかぶってしまうので、パスを指定してセーブする点を強調して、Dropbox へのパス ( 経路 ) としてみたわけです。
申請に対する返事はなかなか戻ってきませんでした。数日が経過して、ちょうど、開発者以外のアカウントで OAuth できずに弱り果てていた頃、そっけない不合格通知が届きました。
レビューしてやるから、実際にきみのアプリを使うために必要な URLかなにかを教えなさい。それからアプリ名に「Dropbox」って入れないように。( ナントカ with Dropbox ならよし ) ... とのこと。
そこで、今回はちゃんと DraftPad をインストールするための URL と、アシストをインポートするための URL を伝えました。
そして、名前のほうですが、Dropbox という単語を含めると面倒なことになるようなので、file away (文書などをファイリングすること) から「DraftPad Assist - Away」と名付けました。いろいろいっても結局はファイリングですからね。そして、Dropbox は DraftPad からみれば、やっぱりアウェーだろうと。
すると、今度はなんと一日と空けず、たちまち審査結果が返ってきました。件名は日本語で、「Dropbox アプリプロダクション鍵不許可のお知らせ」！
やあ、使ってみたよ。でも、きみ、アプリに内蔵したブラウザで OAuth するのはナシだよ。これじゃまるでフィッシングみたいじゃないか。はい、失格～。
... いや、さすがにフィッシングとは言ってこなかったんですけど、まあ、そんなようなことが書いてありました。たしかに言われてみれば、信用の元になるサイトを iframe に入れて見せるようなものですからね。URL は隠されてしまっているし、それが本物なのか偽物なのか、ユーザーは識別することができない。OAuth の根本原理を台無しにしているわけです。
Dropbox いわく、OAuth をやるには Dropbox 公式のサイトまたはアプリを経由しなくてはいけない。アドレス欄の見えない内蔵ブラウザで Dropbox サイトにアクセスしても、それをもって公式サイトを経由したとは認められない。Safari を起動せず、アプリの内部ですべてを済ませたいなら、要するに XAuth をやりたければ、公式の iOS 向け SDK を使うように。それなら公式の Dropbox アプリを経由したことになるから ...
まったくもってごもっとも。しかし、これが DraftPad のアシストである以上、仕組みとして、いずれも無理な相談です。
ああ、万事休す。これで一巻の終わりです。... いや、本当にそうか？ ほかになにか手だてはないのか？
考えてみました。考えてみたところ、一応、次の A, B 案がまとまりました。
A案 / コードネーム「みんなデベロッパー」
ユーザーに、自分で Dropbox API アプリを名前だけでいいので登録してもらう。そして、発行された OAuth の Consumer Key と Consumer Secret を DraftPad に入力した状態で、OAuth 用のアシストを実行すれば ...
B案 / コードネーム「おすそわけトークン」
Safari で OAuth を行い、取得した AccessToken を一時サーバーサイドにプールしておく。それに紐づけたセッション ID を DraftPad に Insert して、ユーザーにはその状態で認証用のアシストを実行してもらう。そこでプールしておいた AccessToken をローカルに保存すれば ...
うーん、どっちも、邪悪でクレイジーですね。
やめておきましょう。
というわけで、調子に乗って長々とお話させていただきましたが、結局、DraftPad に書きつけたテキストを Dropbox の好きなフォルダに好きな名前で保存するためのアシスト「Away」 は、5 ユーザー限定の永遠のプライベートベータ版としてやっていくことになりました。
......。
さて、これでぼくの話はおしまいです。なんだか情報量に乏しい、たんなる身の上話みたいになってしまいましたが、最後までお付き合いいただき、どうもありがとうございました。では 、ちょっとせつないエンディングテーマを聞きながらお別れしましょう。
さようなら。
♪ D箱のアシスト事件 - エンディングテーマ: 誰も知らない / ラフィータフィー
おわり。
と、書いたのが実は今から4ヶ月前のこと。ところがこの話、これで終わりではなかったのです...。
2012年2月11日土曜日
2012年2月10日金曜日
D箱のアシスト事件 第6夜
特集DraftPad/短期集中連載
D箱のアシスト事件
第6夜. アシストのためのサーバーサイド
よーし、やっぱりまじめにアシストのためのサーバーサイドを自分で作ろう！
この際、小さくて、単純で、あまりたくさんのアクセスが発生しないようなものなら、自分でも Web アプリを作れるようになっておこう。ついにぼくはそう決心しました。でも、サーバーの設定とか開発環境の構築とかやりたくない、というか、人間のベーシックな部分がだいぶ迂闊に仕上がっているぼくには、そういうの、まともにできなくてきっとひどい目に合うにきまってるし ...
ところが最近はそのへん、本当にすごいことになってきてるんですね。PaaS とかいって。少し調べたら、DotCloud というのがよさそうでした。Windows + Cygwin 環境に、CLI という DotCloud クライアントをインストールして、サイトに掲載されている Quick Start Guide のとおりに設定してみたら、拍子抜けするほどあっさりと、静的なファイルをホストするサーバーができてしまいました。
そこで、まずはそれに、Dropbox のパブリックフォルダに配置していたアシストをコピーしてみました。すると案の定、開発者以外の Dropbox アカウントでも問題なく OAuth することができるようになりました。
友人にふたたび試してくれるようにお願いしてみると、友人の手元でも問題なく動きはじめたようです。友人は、ぼくのアシストを褒めてくれました。
理解者と勇気を得たぼくは、いよいよ、YQL に頼っていた部分を自前のサーバーサイドアプリに置き換える作業にとりかかりました。
サーバーサイドアプリといっても、クライアントサイドからの xmlHttpRequest を受けて、Dropbox の API へのリクエストとそのレスポンスを中継するだけの、いたってシンプルなものです。きっと node.js と express というWebアプリケーションフレームワークでなら、手っ取り早く必要十分なものが作れるだろうと踏みました。
クライアントもサーバーも、一貫して Javascript のシンタックスに適応しきった頭と手とエディタでやっていけるので、そのへんでもきっと楽ができるでしょう。
作業は非常にスムーズでした。ローカルでの開発サーバーを構築する際に、プロキシの設定の仕方ですこし戸惑ったくらいで、node-dbox なんていうすばらしいモジュールにも出会い、信じられないほど簡単に、ぼくは欲かったものを手に入れてしまいました。
YQL の概念を理解して、満足に設定を整えるまでのほうがよっぽど面倒で時間がかかったくらいです。
出来上がったものを動かしてみると、それはそれは、すばらしいパフォーマンスを見せてくれました。セーブもオープンもさくさく処理されていきます。エラーはちっとも発生しません。長いテキストでも大丈夫です。あの有名な「DraftPad 開発者への 16,820 文字インタビュー」も自由に出し入れできます。ぼくは、ソースコードからリトライの機構を外しました。
さあ、ぼくは有頂天でした。おもては凍えるような寒さでしたが、まさに、おらが世の春でした。たとえ帰り道で交通事故にあっても、生きてさえいれば、ま、そりゃそうだよね、うっふふ。魔でしょ？と、納得づくで笑っていられそうなくらい、それはぼくにとって好事でした。
さっそく公開して、みんなにも使ってもらおう。きっと他にもぼくと同じように喜んでくれる人がいるに違いない。ぼくは、拙い中学生なみの英語で、Dropbox のレビュアー向けに紹介文を一生懸命書きました。これは DraftPad という iPhone アプリの、アシストと呼ばれる拡張機能のひとつであり... インストールの仕方は ... 使い方は ... そもそも DraftPad というのは ... アシストというのはつまり ...。
公開申請ボタンをクリックしたぼくは、すっかり満ち足りた気持ちになって、深夜のD坂を踊るように下って帰りました。あ、団子坂じゃなくて、道玄坂なんですけどね ... 。
つづく。(次回はいよいよ最終回！)
D箱のアシスト事件
第6夜. アシストのためのサーバーサイド
よーし、やっぱりまじめにアシストのためのサーバーサイドを自分で作ろう！
この際、小さくて、単純で、あまりたくさんのアクセスが発生しないようなものなら、自分でも Web アプリを作れるようになっておこう。ついにぼくはそう決心しました。でも、サーバーの設定とか開発環境の構築とかやりたくない、というか、人間のベーシックな部分がだいぶ迂闊に仕上がっているぼくには、そういうの、まともにできなくてきっとひどい目に合うにきまってるし ...
ところが最近はそのへん、本当にすごいことになってきてるんですね。PaaS とかいって。少し調べたら、DotCloud というのがよさそうでした。Windows + Cygwin 環境に、CLI という DotCloud クライアントをインストールして、サイトに掲載されている Quick Start Guide のとおりに設定してみたら、拍子抜けするほどあっさりと、静的なファイルをホストするサーバーができてしまいました。
そこで、まずはそれに、Dropbox のパブリックフォルダに配置していたアシストをコピーしてみました。すると案の定、開発者以外の Dropbox アカウントでも問題なく OAuth することができるようになりました。
友人にふたたび試してくれるようにお願いしてみると、友人の手元でも問題なく動きはじめたようです。友人は、ぼくのアシストを褒めてくれました。
理解者と勇気を得たぼくは、いよいよ、YQL に頼っていた部分を自前のサーバーサイドアプリに置き換える作業にとりかかりました。
サーバーサイドアプリといっても、クライアントサイドからの xmlHttpRequest を受けて、Dropbox の API へのリクエストとそのレスポンスを中継するだけの、いたってシンプルなものです。きっと node.js と express というWebアプリケーションフレームワークでなら、手っ取り早く必要十分なものが作れるだろうと踏みました。
クライアントもサーバーも、一貫して Javascript のシンタックスに適応しきった頭と手とエディタでやっていけるので、そのへんでもきっと楽ができるでしょう。
作業は非常にスムーズでした。ローカルでの開発サーバーを構築する際に、プロキシの設定の仕方ですこし戸惑ったくらいで、node-dbox なんていうすばらしいモジュールにも出会い、信じられないほど簡単に、ぼくは欲かったものを手に入れてしまいました。
YQL の概念を理解して、満足に設定を整えるまでのほうがよっぽど面倒で時間がかかったくらいです。
出来上がったものを動かしてみると、それはそれは、すばらしいパフォーマンスを見せてくれました。セーブもオープンもさくさく処理されていきます。エラーはちっとも発生しません。長いテキストでも大丈夫です。あの有名な「DraftPad 開発者への 16,820 文字インタビュー」も自由に出し入れできます。ぼくは、ソースコードからリトライの機構を外しました。
さあ、ぼくは有頂天でした。おもては凍えるような寒さでしたが、まさに、おらが世の春でした。たとえ帰り道で交通事故にあっても、生きてさえいれば、ま、そりゃそうだよね、うっふふ。魔でしょ？と、納得づくで笑っていられそうなくらい、それはぼくにとって好事でした。
さっそく公開して、みんなにも使ってもらおう。きっと他にもぼくと同じように喜んでくれる人がいるに違いない。ぼくは、拙い中学生なみの英語で、Dropbox のレビュアー向けに紹介文を一生懸命書きました。これは DraftPad という iPhone アプリの、アシストと呼ばれる拡張機能のひとつであり... インストールの仕方は ... 使い方は ... そもそも DraftPad というのは ... アシストというのはつまり ...。
公開申請ボタンをクリックしたぼくは、すっかり満ち足りた気持ちになって、深夜のD坂を踊るように下って帰りました。あ、団子坂じゃなくて、道玄坂なんですけどね ... 。
つづく。(次回はいよいよ最終回！)
2012年2月9日木曜日
D箱のアシスト事件 第5夜
特集DraftPad/短期集中連載
D箱のアシスト事件
第5夜. ひとり OAuth
Dropbox に API アプリを登録すると、当初はデベロッパー版として API へのアクセスが許可されます。デベロッパー版のアプリを利用できるのは、開発者自身の Dropbox アカウントとその他 5 人分のアカウントに限定されています。さらに多くのアカウントで利用できるようにするためには、アプリの公開を申請し、Drobbox の審査をパスする必要があります。
公開する前に、なんとか格好がついたこの時点で、ぼくは信頼できる友人に使ってみてもらうことにしました。
すると、友人の手元では OAuth が失敗するというのです。あわてて自分でも別の Dropbox アカウントを取得して試してみたところ、やはり失敗しました。Dropbox の画面でアシストからのアクセスに許可を与えるボタンをタップすると、Dropbox のエラーメッセージ「Error (404)」が表示されてしまうのです。 しかし、ふたたび自分の開発者アカウントに切り替えると、何事もなくうまくいくのです。
自分で作ったアプリに許可を与えられるのは自分だけって、それじゃいったいなんのための OAuth ですか！
DraftPad をいったん離れ、Safari で実行できるように改造して試してみましたが同じことでした。PC でやってみても同じ。他に同じような悩みを抱えている人がいないかググりまくってみても空振り。一度は不思議な呪文でぼくを救ってくれた Dropbox の Developer forum にすがってみてももう何も出てきません。
ぼくは今度こそ本当にサジを投げました。
いや、いいんだ。いいんだよ。自分でほしいと思ったものが、いまこうして自分の手元で使えている。それで十分じゃないか。そのための OAuth だよ。ひとり OAuth ! ぼくにはまったくお似合いだよ、は、は、は、は！
なんて、自分で自分に強がってみせつつも、ぼくは未練がましく Error (404) になった URL を DraftPad に入れて持ち歩いていました。そして、暇さえあればそれをとり出しては眺め、結局途方にくれて、ただ、ため息ばかりついていました。
ところが、そんなことを当てもなく何度も繰り返しているうち、ある日突然わかってしまったのです。（そんなことってあるのものなんですネ！）
――― あっ、Dropbox のパブリック URL に uid というクエリパラメータをつけて、これに、自分の ID とは異なる値をセットしてリクエストすると、Error (404) になるんだ！
試してみたら、本当にそうでした。
ぼくは、ぼくの流儀に従い、相変わらず Dropbox 上に配置した Javscript + HTML + CSS だけでアシストを作っていました。OAuth でユーザーの許可をもらったあとにリダイレクトで戻ってくるコールバック URL も Dropbox のパブリック URL です。
そして Dropbox は、コールバック URL に uid というクエリパラメータをつけて、これに許可を与えたユーザーの ID をセットしてリダイレクトしてくるのです。 そのために、開発者以外のアカウントでは OAuth に失敗していたというわけでした。
な、なかなかやってくれるじゃないか、Dropbox ちゃん。いいよ、もういいよ、わかったよ。そっちがそうくるなら、こっちにも考えがある。はじめ腹の底のほうに生まれた黒い情念の塊のようなものが、みるみるうちに全身に満ちていくのを感じながら、ぼくは自分が今、はっきりと笑っていることを自覚していました ... 。
つづく。
D箱のアシスト事件
第5夜. ひとり OAuth
Dropbox に API アプリを登録すると、当初はデベロッパー版として API へのアクセスが許可されます。デベロッパー版のアプリを利用できるのは、開発者自身の Dropbox アカウントとその他 5 人分のアカウントに限定されています。さらに多くのアカウントで利用できるようにするためには、アプリの公開を申請し、Drobbox の審査をパスする必要があります。
公開する前に、なんとか格好がついたこの時点で、ぼくは信頼できる友人に使ってみてもらうことにしました。
すると、友人の手元では OAuth が失敗するというのです。あわてて自分でも別の Dropbox アカウントを取得して試してみたところ、やはり失敗しました。Dropbox の画面でアシストからのアクセスに許可を与えるボタンをタップすると、Dropbox のエラーメッセージ「Error (404)」が表示されてしまうのです。 しかし、ふたたび自分の開発者アカウントに切り替えると、何事もなくうまくいくのです。
自分で作ったアプリに許可を与えられるのは自分だけって、それじゃいったいなんのための OAuth ですか！
DraftPad をいったん離れ、Safari で実行できるように改造して試してみましたが同じことでした。PC でやってみても同じ。他に同じような悩みを抱えている人がいないかググりまくってみても空振り。一度は不思議な呪文でぼくを救ってくれた Dropbox の Developer forum にすがってみてももう何も出てきません。
ぼくは今度こそ本当にサジを投げました。
いや、いいんだ。いいんだよ。自分でほしいと思ったものが、いまこうして自分の手元で使えている。それで十分じゃないか。そのための OAuth だよ。ひとり OAuth ! ぼくにはまったくお似合いだよ、は、は、は、は！
なんて、自分で自分に強がってみせつつも、ぼくは未練がましく Error (404) になった URL を DraftPad に入れて持ち歩いていました。そして、暇さえあればそれをとり出しては眺め、結局途方にくれて、ただ、ため息ばかりついていました。
http://dl.dropbox.com/u/223789/dev/dp2drpbx/sign.html?oauth_token=mh7an9dkrg59&uid=57873456( oauth_token の値は Dropbox のサイトに掲載されているサンプルです。uid はぼくのアカウントのものです。 )
ところが、そんなことを当てもなく何度も繰り返しているうち、ある日突然わかってしまったのです。（そんなことってあるのものなんですネ！）
――― あっ、Dropbox のパブリック URL に uid というクエリパラメータをつけて、これに、自分の ID とは異なる値をセットしてリクエストすると、Error (404) になるんだ！
試してみたら、本当にそうでした。
ぼくは、ぼくの流儀に従い、相変わらず Dropbox 上に配置した Javscript + HTML + CSS だけでアシストを作っていました。OAuth でユーザーの許可をもらったあとにリダイレクトで戻ってくるコールバック URL も Dropbox のパブリック URL です。
そして Dropbox は、コールバック URL に uid というクエリパラメータをつけて、これに許可を与えたユーザーの ID をセットしてリダイレクトしてくるのです。 そのために、開発者以外のアカウントでは OAuth に失敗していたというわけでした。
な、なかなかやってくれるじゃないか、Dropbox ちゃん。いいよ、もういいよ、わかったよ。そっちがそうくるなら、こっちにも考えがある。はじめ腹の底のほうに生まれた黒い情念の塊のようなものが、みるみるうちに全身に満ちていくのを感じながら、ぼくは自分が今、はっきりと笑っていることを自覚していました ... 。
つづく。
2012年2月8日水曜日
D箱のアシスト事件 第4夜
特集DraftPad/短期集中連載
D箱のアシスト事件
第4夜. トラブルぶくみ
この「Save to Tumblr」、ちょっと長めのテキストをポストするとエラーになるんですよね。しかも、毎回かならずというわけではなく、同じテキストでもエラーになったり、ならなかったりする。
クライアントサイド、YQL、Tumblr のどこでしくじっているのか調べてみると、どうも、YQL が怪しい。 怪しいのはわかるんですが、かといって YQL にそれ以上、手の出しようもない。
そんな状態でモンモンとした日々を過ごしていたところ、なにかの拍子に、Dropbox の API に HTTP で PUT するメソッドがあるのを知ったんです。
よく REST なんていいますけど、あんまり PUT ってお目にかかれないもんですから、すこし関心を持ちまして、 これを使えば、公式アシストの Save to Dropbox のように、(勝手な想像ですが、) アプリの内部にファイルを作成して、それをマルチパートでポストするというやり方じゃなく、DraftPad のテキストを Javascript 製のアシスト経由で直接送信できるんじゃないか？ しかも、任意のフォルダに、任意のファイル名で？ なんて考えました。
トラブルぶくみではありますが、YQL に頼れば、やれることはやれるはず。Dropbox の場合でも、やっぱり Tumblr と同じようなエラーが出るものか試してみたくもあり、今度は、Dropbox にテキストをセーブするためのアシストを作ってみることにしました。
どんなふうに動くものなのかは、前々回でご紹介したとおりです。途中、OAuth がどうしてもうまくいかずサジを投げかけました。でも本当に投げてしまう寸前で、Dropbox の Developer Forum に 「 signature_method を PLAINTEXT にしてみ？」なんて、まあ、ほとんど呪文のような書き込みを見つけて、なんとか乗り切ることができました。そんなかんじで、Tumblr のときよりもだいぶ苦労はしたのですが、なんとかひととおり、目標にしていた機能を実装することができました。
さて、実際に手にとってみると、最初の回に何やらクドクドと書き連ねたような意味で、これは、ぼくの DraftPad ライフにうまくフィットしていくものだということがすぐにわかりました。気がつくと、夢中になって無限の一枚の紙をちぎりまくってました。道具のほうじゃなく、自分のほうがグーンと延長していく実感がありました。
... しかし、やっぱり Tumblr と同じ問題が起きてしまうのです。
その上、Dropbox の API は https でつなげないと使えないんですけど、YQL と Dropbox の間で SSL 通信を確立する際のものと思しき通信エラーが頻発して、そのままでは、とても実用に耐えられない状態なのです。
長いテキストが扱えないというのはまだしも、何か操作するたびに、しょっちゅう通信エラーが発生してしまうのはいくらなんでもいただけないでしょう。
そこで、幸い、というべきかどうか、諸々のエラーは確率的にしか発生しないので、暗黙のリトライをしまくってごまかすことにしました。
もともとつくりがシンプルだったせいもあって、ソースコードの半分近くが、エラーの検知やリトライのための処理で埋めつくされてしまうことになってしまいましたが、裏で何があろうと、表面上は何事もなかったかのようにしれっと動くようになりました。
きっとこういうのは何かの縮図なんだろうなとか、とりとめのないことを考えそうになりましたが、そういうのは早めに切り上げて、とりあえずこれでいいや、中くらいの、おらが世の春だと思うことにしました。
ところが、そうして一息ついたところを狙いすましていたかのように、さらにもうひとつ、新たな問題が浮上してきたのです ... 。
つづく。
D箱のアシスト事件
第4夜. トラブルぶくみ
この「Save to Tumblr」、ちょっと長めのテキストをポストするとエラーになるんですよね。しかも、毎回かならずというわけではなく、同じテキストでもエラーになったり、ならなかったりする。
クライアントサイド、YQL、Tumblr のどこでしくじっているのか調べてみると、どうも、YQL が怪しい。 怪しいのはわかるんですが、かといって YQL にそれ以上、手の出しようもない。
そんな状態でモンモンとした日々を過ごしていたところ、なにかの拍子に、Dropbox の API に HTTP で PUT するメソッドがあるのを知ったんです。
よく REST なんていいますけど、あんまり PUT ってお目にかかれないもんですから、すこし関心を持ちまして、 これを使えば、公式アシストの Save to Dropbox のように、(勝手な想像ですが、) アプリの内部にファイルを作成して、それをマルチパートでポストするというやり方じゃなく、DraftPad のテキストを Javascript 製のアシスト経由で直接送信できるんじゃないか？ しかも、任意のフォルダに、任意のファイル名で？ なんて考えました。
トラブルぶくみではありますが、YQL に頼れば、やれることはやれるはず。Dropbox の場合でも、やっぱり Tumblr と同じようなエラーが出るものか試してみたくもあり、今度は、Dropbox にテキストをセーブするためのアシストを作ってみることにしました。
どんなふうに動くものなのかは、前々回でご紹介したとおりです。途中、OAuth がどうしてもうまくいかずサジを投げかけました。でも本当に投げてしまう寸前で、Dropbox の Developer Forum に 「 signature_method を PLAINTEXT にしてみ？」なんて、まあ、ほとんど呪文のような書き込みを見つけて、なんとか乗り切ることができました。そんなかんじで、Tumblr のときよりもだいぶ苦労はしたのですが、なんとかひととおり、目標にしていた機能を実装することができました。
さて、実際に手にとってみると、最初の回に何やらクドクドと書き連ねたような意味で、これは、ぼくの DraftPad ライフにうまくフィットしていくものだということがすぐにわかりました。気がつくと、夢中になって無限の一枚の紙をちぎりまくってました。道具のほうじゃなく、自分のほうがグーンと延長していく実感がありました。
... しかし、やっぱり Tumblr と同じ問題が起きてしまうのです。
その上、Dropbox の API は https でつなげないと使えないんですけど、YQL と Dropbox の間で SSL 通信を確立する際のものと思しき通信エラーが頻発して、そのままでは、とても実用に耐えられない状態なのです。
長いテキストが扱えないというのはまだしも、何か操作するたびに、しょっちゅう通信エラーが発生してしまうのはいくらなんでもいただけないでしょう。
そこで、幸い、というべきかどうか、諸々のエラーは確率的にしか発生しないので、暗黙のリトライをしまくってごまかすことにしました。
もともとつくりがシンプルだったせいもあって、ソースコードの半分近くが、エラーの検知やリトライのための処理で埋めつくされてしまうことになってしまいましたが、裏で何があろうと、表面上は何事もなかったかのようにしれっと動くようになりました。
きっとこういうのは何かの縮図なんだろうなとか、とりとめのないことを考えそうになりましたが、そういうのは早めに切り上げて、とりあえずこれでいいや、中くらいの、おらが世の春だと思うことにしました。
ところが、そうして一息ついたところを狙いすましていたかのように、さらにもうひとつ、新たな問題が浮上してきたのです ... 。
つづく。
2012年2月7日火曜日
D箱のアシスト事件 第3夜
特集DraftPad/短期集中連載
D箱のアシスト事件
第3夜. OAuth するアシスト
そもそものはじまりは、この記事をみつけたことにありました。
How-to: Secure OAuth in JavaScript
これまでにも、いろいろと DraftPad アシストを作ってみたけど、一貫して、静的なファイルに記述した Javascript + HTML + CSS だけで完結するものばかりでした。
というのも、仕事でフロントエンドエンジニアの真似事のようなことはやりますが、サーバーサイドの Web アプリの開発に自分で手を出したことはなかったし、とても難しくて、自分でやれるようなことだとは思っていなかったからです。
その一方で、簡単なスクリプトを書いて、Dropbox の Public フォルダに配置すればすぐに使える、そういうカジュアルなスタイルが気に入っていました。負け惜しみじゃなく、DraftPad のアシストとしてなら、それで相当のことができるのです。
できないことのほうを挙げると、次の3つになると思います。
1. 他の人や他の利用環境とデータをシェアするために、サーバーサイドにデータを保存すること
2. クライアントサイドのシステムのリソースにアクセスすること
そして、
3. アプリケーションのみが知りうる情報を、アプリケーションの内部に秘密裡に保持すること
1. と 2. は、はじめから期待していないようなものだからいいんですが、口惜しいのは 3. です。3. ができたら、たとえば、OAuth ありきの API を使ったアシストも考えられるのにって。でも、ソースコードが 100% 誰にでも読めてしまう Javascript だけでは絶対に無理。
ところが、前掲の記事は、「でも YQL を使えば隠せるね。」と、こういうわけです。
YQL とは何か？ 一言でいえば、クライアントサイドからよそのドメインのフィードやAPI を利用するための、
・マッシュアップフィルター + JSONPラッパー
ということになります。が、この記事はさらに付け加えて、
・フィルター処理で使用する変数の値を、サーバーサイドに保持できるサービス
でもあることを示し、そして、ここに OAuth の Consumer Key や Consumer Secret を入れておけば、クライアントサイドで動く Javascript で、ちゃんとセキュアに OAuth アプリが作れるよ、と、実際に作り方までていねいにガイドしてくれていたのです。
あ、これだ！と、飛びつきましたよ。
最初に作ったのは、Tumblr にテキストをポストするアシストでした。「Save to Tumblr」 。実は、iPhone 版の Tumblr アプリのテキスト入力がアレなので、前々からせび欲しかったのです。
Save to Tumblr
すぐにできました。興奮しましたね。実用上の念願を果たせたことももちろんですけど、自分で OAuth するアシストを作れたことに。でも、でもですね ... 。
つづく。
D箱のアシスト事件
第3夜. OAuth するアシスト
そもそものはじまりは、この記事をみつけたことにありました。
How-to: Secure OAuth in JavaScript
これまでにも、いろいろと DraftPad アシストを作ってみたけど、一貫して、静的なファイルに記述した Javascript + HTML + CSS だけで完結するものばかりでした。
というのも、仕事でフロントエンドエンジニアの真似事のようなことはやりますが、サーバーサイドの Web アプリの開発に自分で手を出したことはなかったし、とても難しくて、自分でやれるようなことだとは思っていなかったからです。
その一方で、簡単なスクリプトを書いて、Dropbox の Public フォルダに配置すればすぐに使える、そういうカジュアルなスタイルが気に入っていました。負け惜しみじゃなく、DraftPad のアシストとしてなら、それで相当のことができるのです。
できないことのほうを挙げると、次の3つになると思います。
1. 他の人や他の利用環境とデータをシェアするために、サーバーサイドにデータを保存すること
2. クライアントサイドのシステムのリソースにアクセスすること
そして、
3. アプリケーションのみが知りうる情報を、アプリケーションの内部に秘密裡に保持すること
1. と 2. は、はじめから期待していないようなものだからいいんですが、口惜しいのは 3. です。3. ができたら、たとえば、OAuth ありきの API を使ったアシストも考えられるのにって。でも、ソースコードが 100% 誰にでも読めてしまう Javascript だけでは絶対に無理。
ところが、前掲の記事は、「でも YQL を使えば隠せるね。」と、こういうわけです。
YQL とは何か？ 一言でいえば、クライアントサイドからよそのドメインのフィードやAPI を利用するための、
・マッシュアップフィルター + JSONPラッパー
ということになります。が、この記事はさらに付け加えて、
・フィルター処理で使用する変数の値を、サーバーサイドに保持できるサービス
でもあることを示し、そして、ここに OAuth の Consumer Key や Consumer Secret を入れておけば、クライアントサイドで動く Javascript で、ちゃんとセキュアに OAuth アプリが作れるよ、と、実際に作り方までていねいにガイドしてくれていたのです。
あ、これだ！と、飛びつきましたよ。
最初に作ったのは、Tumblr にテキストをポストするアシストでした。「Save to Tumblr」 。実は、iPhone 版の Tumblr アプリのテキスト入力がアレなので、前々からせび欲しかったのです。
Save to Tumblr
すぐにできました。興奮しましたね。実用上の念願を果たせたことももちろんですけど、自分で OAuth するアシストを作れたことに。でも、でもですね ... 。
つづく。
2012年2月6日月曜日
D箱のアシスト事件 第2夜
特集DraftPad/短期集中連載
D箱のアシスト事件
第2夜. Dropbox にセーブするアシスト
DraftPad のアシストシステムはとても強力です。特に、オンラインから内蔵 UIWebView に Javascript コードを読み込み、それで DraftPad 上のテキストを取り扱うことができる機構は、はっきりいって最強です。これさえあればなんでもできる(ような気になれる)。きっと DraftPad を Dropbox クライアントにすることもできるはず。たとえば ...
DraftPad に書きつけたテキストをちぎってとっておきたくなったら、Dropbox の適当なフォルダに、適当な名前をつけて放り込んでおく。
そして手元に戻したくなったら iPhone の 「iPhoneを検索」みたいなかんじでフォルダ名やファイル名の一部を入力して、さっと検索して読み込む。
... こんなアシストはどうでしょう？ Dropbox ならデスクトップのテキストエディタと DraftPad の間で同じテキストを共有して編集するなんてこともできるしね！
たとえ万が一、意図しない上書きとかをやっちまったとしても、DraftPad、Dropbox の双方にくそ丁寧な履歴が残ってるから絶対なんとかなるし。具体的な使い勝手はこんなかんじで ...
セーブするとき。
最後の行に保存先となる Dropbox のパスを書いておく。「/memo/Dropbox にセーブするアシスト」とかね。この状態でセーブ用のアシストを起動すると、一発で Dropbox の狙った場所にテキストが飛んでいく。
一方、Dropbox 上のテキストを DraftPad に読み込むとき。
オープン用のアシストを起動すると検索フォームが表示される。ここにフォルダ名やファイル名(の一部)を入力すると、マッチするフォルダとファイルが表示される。
フォルダをタップすると、そのフォルダに含まれるフォルダとファイルが表示される。そして、ファイルをタップするとその内容が DraftPad に読み込まれる。
DraftPad に読み込まれる際には、自動的に最後の行にパスがついてくるようになっているので、テキストを編集した後、何も考えずそのままセーブ用のアシストを起動すれば、Dropbox 上の元のテキストが更新される。
... こ、これは便利だ！
って、実はコレ、すでにぼくの手元で動いているのです。ここに掲載しているキャプチャ画像も実際に動作している画面のものです。便利なのは本当ですよ。
でもわけあって、公開はできないことになってしまいました。なんということでしょう。ぼくはこの先、1人ぼっちでよがるしかないのでしょうか ... 。
( ここで紹介しているアシストは、公式アシストの「Save to Dropbox」とは別物です。念のため。)
つづく。
D箱のアシスト事件
第2夜. Dropbox にセーブするアシスト
DraftPad のアシストシステムはとても強力です。特に、オンラインから内蔵 UIWebView に Javascript コードを読み込み、それで DraftPad 上のテキストを取り扱うことができる機構は、はっきりいって最強です。これさえあればなんでもできる(ような気になれる)。きっと DraftPad を Dropbox クライアントにすることもできるはず。たとえば ...
DraftPad に書きつけたテキストをちぎってとっておきたくなったら、Dropbox の適当なフォルダに、適当な名前をつけて放り込んでおく。
そして手元に戻したくなったら iPhone の 「iPhoneを検索」みたいなかんじでフォルダ名やファイル名の一部を入力して、さっと検索して読み込む。
... こんなアシストはどうでしょう？ Dropbox ならデスクトップのテキストエディタと DraftPad の間で同じテキストを共有して編集するなんてこともできるしね！
たとえ万が一、意図しない上書きとかをやっちまったとしても、DraftPad、Dropbox の双方にくそ丁寧な履歴が残ってるから絶対なんとかなるし。具体的な使い勝手はこんなかんじで ...
セーブするとき。
最後の行に保存先となる Dropbox のパスを書いておく。「/memo/Dropbox にセーブするアシスト」とかね。この状態でセーブ用のアシストを起動すると、一発で Dropbox の狙った場所にテキストが飛んでいく。
一方、Dropbox 上のテキストを DraftPad に読み込むとき。
オープン用のアシストを起動すると検索フォームが表示される。ここにフォルダ名やファイル名(の一部)を入力すると、マッチするフォルダとファイルが表示される。
フォルダをタップすると、そのフォルダに含まれるフォルダとファイルが表示される。そして、ファイルをタップするとその内容が DraftPad に読み込まれる。
DraftPad に読み込まれる際には、自動的に最後の行にパスがついてくるようになっているので、テキストを編集した後、何も考えずそのままセーブ用のアシストを起動すれば、Dropbox 上の元のテキストが更新される。
... こ、これは便利だ！
って、実はコレ、すでにぼくの手元で動いているのです。ここに掲載しているキャプチャ画像も実際に動作している画面のものです。便利なのは本当ですよ。
でもわけあって、公開はできないことになってしまいました。なんということでしょう。ぼくはこの先、1人ぼっちでよがるしかないのでしょうか ... 。
( ここで紹介しているアシストは、公式アシストの「Save to Dropbox」とは別物です。念のため。)
つづく。
2012年2月5日日曜日
D箱のアシスト事件 第1夜
特集DraftPad/短期集中連載
D箱のアシスト事件
第1夜. DraftPad とセーブ
ファイルでもアプリでもない、あえて言うなら、永久に不滅の作業バッファ？ いや、DraftPad と呼ぶほかはない、テキストのヘイヴン。一枚の紙だから、New も Open もない。一枚の紙だけど、一種のタイムマシンでもあって、過去の好きな時点の状態にいつでも戻ることができる。だから、Save だっていらない。
それが DraftPad の哲学で、ぼくはその哲学がとても好きだ。好きだ、好きだ、好きなんだ。どうしようもなく好きなんだ。
それにひきかえ、どうだ。ファイルシステムだって？ すべてを「新規作成」し、「保存」し、「開く」世界。
いや、まあ、それもいいだろう。しかし、なんでもかんでも、いちいちその調子で押し通す必要はなかったんだ。むしろ、ほとんどのことは DraftPad 的に済ますことができたはずだ。すっかり騙されていた。
特に、セーブだなんてひどいじゃないか。
それは本当に、救い出すという意味だった。気取ったメタファーなんかじゃない。いつ消えてもおかしくないまぼろしのような作業バッファから、大切な成果を、もっと安全な場所に小まめに救い出しておく必要があった。
句点を打ったり、段落を変えたりするたびに、指が勝手に動いて、ほとんど無意識のうちにセーブしてしまう。心身の延長としての道具ではなく、いつの間にかこちらが、道具の延長になっていた。
そんな悪夢を見せられていたぼくらの目を覚まし、そこから救い出してくれたのが DraftPad という発明だ。もはや作業バッファこそが安息の地、ここからどこかにセーブすることのほうが危ない橋を渡ることのように思えるくらいだから、もうそれをセーブと呼ぶのはおかしい。
ところが、セーブという言葉にはもうひとつ、いまあるものを手放さずにとっておく、というニュアンスも含まれていて、この安息の地に立ってみると、そちらのほうの意味がぐんと際立ってくる。
無限に拡がる一枚の紙に書かれた言葉は、けっして失われてしまうことはないけれど、ただ、書けば書くほど、それらは次第に遠ざかっていく。紙は無限だけど、ぼくには限りがある。ぼくの手が届く範囲なんて、たかが知れている。
すると、無限の一枚の紙の、いま書いたところだけをビリっとちぎって、ちょっとわきにとっておき、必要になったらいつでもさっと手元に戻すことができるような、そんなセーブをしてみたくなる。
それは、そう、いまならタギングとか、スナップショットをとるとか、そんなふうに呼んだほうがふさわしい行為かもしれない。でもいいだろう、あえてセーブと呼び続けようじゃないか。言葉はおなじだけど、意味するところはすっかり変わってしまった。そこに、DraftPad の凄みを感じていくことにしよう。
――― と、そんなわけで、ぼくは、そういう意味でのセーブを、 DraftPad に付け足してみたくなったのです。
つづく。
D箱のアシスト事件
第1夜. DraftPad とセーブ
ファイルでもアプリでもない、あえて言うなら、永久に不滅の作業バッファ？ いや、DraftPad と呼ぶほかはない、テキストのヘイヴン。一枚の紙だから、New も Open もない。一枚の紙だけど、一種のタイムマシンでもあって、過去の好きな時点の状態にいつでも戻ることができる。だから、Save だっていらない。
それが DraftPad の哲学で、ぼくはその哲学がとても好きだ。好きだ、好きだ、好きなんだ。どうしようもなく好きなんだ。
それにひきかえ、どうだ。ファイルシステムだって？ すべてを「新規作成」し、「保存」し、「開く」世界。
いや、まあ、それもいいだろう。しかし、なんでもかんでも、いちいちその調子で押し通す必要はなかったんだ。むしろ、ほとんどのことは DraftPad 的に済ますことができたはずだ。すっかり騙されていた。
特に、セーブだなんてひどいじゃないか。
それは本当に、救い出すという意味だった。気取ったメタファーなんかじゃない。いつ消えてもおかしくないまぼろしのような作業バッファから、大切な成果を、もっと安全な場所に小まめに救い出しておく必要があった。
句点を打ったり、段落を変えたりするたびに、指が勝手に動いて、ほとんど無意識のうちにセーブしてしまう。心身の延長としての道具ではなく、いつの間にかこちらが、道具の延長になっていた。
そんな悪夢を見せられていたぼくらの目を覚まし、そこから救い出してくれたのが DraftPad という発明だ。もはや作業バッファこそが安息の地、ここからどこかにセーブすることのほうが危ない橋を渡ることのように思えるくらいだから、もうそれをセーブと呼ぶのはおかしい。
ところが、セーブという言葉にはもうひとつ、いまあるものを手放さずにとっておく、というニュアンスも含まれていて、この安息の地に立ってみると、そちらのほうの意味がぐんと際立ってくる。
無限に拡がる一枚の紙に書かれた言葉は、けっして失われてしまうことはないけれど、ただ、書けば書くほど、それらは次第に遠ざかっていく。紙は無限だけど、ぼくには限りがある。ぼくの手が届く範囲なんて、たかが知れている。
すると、無限の一枚の紙の、いま書いたところだけをビリっとちぎって、ちょっとわきにとっておき、必要になったらいつでもさっと手元に戻すことができるような、そんなセーブをしてみたくなる。
それは、そう、いまならタギングとか、スナップショットをとるとか、そんなふうに呼んだほうがふさわしい行為かもしれない。でもいいだろう、あえてセーブと呼び続けようじゃないか。言葉はおなじだけど、意味するところはすっかり変わってしまった。そこに、DraftPad の凄みを感じていくことにしよう。
――― と、そんなわけで、ぼくは、そういう意味でのセーブを、 DraftPad に付け足してみたくなったのです。
つづく。
DraftPad 1.5.2 
登録:
投稿 (Atom)