普段よく使うやつをまとめて、
DraftPad PDA
というのを半分冗談で作ってみてたんですが、これ公開する前に DraftPad の開発ステータスが「discontinued」になってしまいました。
DraftPad Important Notice
... なんというんでしょう。終わり方まで完全にデザインされてますよね。かっこいいですね。
そして一週も休まずにもう次の新仮面ライダーが始まるみたいに、Textwell がやってきました。
ソシオメディア | オリジナル iOS アプ「Textwell」をリリース
DraftPad の作者 @manabuueno さんのツイート
そこで、なにはともあれ「DraftPad PDA」たちを Textwell で動くようにしてみました。
Schedule & Memo
インポート
Money
インポート
Calc
インポート
Transit(NAVITIME)
インポート
これらの元になった DraftPad アシストは、どれも、いわゆる WebDelegate という機構を使っています。
yrrez さんによる WebDelegate 解説記事
どうかなとも思ったんですけど、Textwell にも WebDelegate はあるんですね。よかったです。なので、移植作業は驚くほどスムーズでした。ほんの数行書き換えただけ。ちなみに公式アクション「Dropbox」のソースを追いかけて勘所を教わりました。
Textwell の WebDelegate については、きっとまた yrrez さんが調べて教えてくれるかも知れませんね。今頃、ソシオメディア社に潜入してたりして。
最後に。ぼくの大好きなDraftPad、ありがとう。さようなら。この記事は DraftPad で書きました。
2013年9月14日土曜日
2012年6月17日日曜日
DraftPad アシスト ”Away” が、ほかの Dropbox クライアントとは違うところ
Away はディレクトリツリーのビューをたどる逐次的なインタラクションを採用せず、パス表現にマッチしたすべてのアイテムをフラットにリスティングすることに専念しています。
Dropbox 上のリソースにアクセスするUIとして不十分に見えるかもしれませんが、これにより、図書分類法的にいえば、列挙型分類法と分析合成型分類法を必要に応じて自由に組み合わせて使える分類/検索インターフェースを実現しています。
列挙型分類とは、あらかじめカテゴリを定義しておき、オブジェクトをそれにふさわしいカテゴリに仕分けていく分類方法です。カテゴリを特定すれば、当該のカテゴリに所属するオブジェクトが得られます。ふつうファイルシステムといったときにイメージするディレクトリツリーは、列挙型分類法にしたがったUIだといえます。
一方、分析合成型分類とは、あらかじめオブジェクトの属性の種類を定義しておき、各対象の各属性にふさわしい値を与えていく分類方法です。属性の値（の組み合わせ）に関する条件を指定すると、条件にマッチするオブジェクトが得られます。ソーシャルブックマークのタギングは、分析合成型分類法の具体例のひとつだといえます。インフォメーションアーキテクチャの世界ではこれをファセット分類と呼ぶようです。
多くの Dropbox クライアントは、フォルダとファイルのツリー構造をビジュアル化したビューを持ち、いわば列挙型分類法のみにしたがっています。フォルダ名やファイル名でオブジェクトを検索する Away も、基本的に列挙型分類法にしたがっているといえますが、Dropbox の検索仕様と Away のパス記法ベースの UI に基づいて、列挙型分類法に分析合成型分類法を補完的に組み合わせて活用することも可能になっています。
Dropbox では、フォルダ名、ファイル名の部分一致で検索する際、検索範囲を特定のパス以下に限定することができます。
Away で ”/path/to/a” を検索すると、”/path/to/” の直下にあるフォルダやファイルの”/path/to/abc/” や ”/path/to/abc.txt” だけではなく "/path/to/foo/bar/abc" や ”/path/to/x/y/z/abc.txt” などもヒットします。
したがって、次のような規則を作って各種のテキストを保存すれば、ディレクトリ名と文書名とタグを組み合わせて、さまざまな角度から必要なテキストをすばやく取り出せるようになります。
< 規則 >
カテゴリをあらわすディレクトリ ( "/"区切り) + 時間をあらわすディレクトリ ( "/"区切り) + 文書名とタグ (スペース区切り)
< 例 >
/Aプロジェクト/2012/06/Aとはそもそも何なのか？ 社内 議事録
など。
すると、プロジェクト名や文書名を直接検索するだけではなく、たとえば、2012年6月に作ったAプロジェクトの社内資料を探したいときは、
/Aプロジェクト/2012/06/社内
と入力して検索することができるようになります。
また、2012年のAプロジェクトの議事録を探したいときは、
/Aプロジェクト/2012/議事録
と入力して検索することができます。
このように、Away でのファイル検索は、ディレクトリツリーベースのファイルシステムを操作しながら目的のファイルを格納した場所にたどり着くというよりも、検索範囲を狭めたり広げたりしながらタギングしたファイルを一挙に取り出すような操作感になります。
実は、Dropbox 社製の iPhone クライアントでも、同じような操作を行うことは可能です。特定のフォルダ以下に範囲を限定してフォルダ名やファイル名で検索することができます。しかし、ディレクトリをたどるUIが中心なので、こうした列挙型+ 分析合成型両分類法を総合した"超整理"の可能性は残念ながら影に隠れてしまっています。
PC向けOSのファイルシステムにも、特定のフォルダを指定し、サブフォルダを検索対象に含めて、部分一致でファイルやフォルダを検索できる機能が備わっているのがふつうです。しかし、やはりこれもある種のレスキュー的な機能として普段は隠されていることが多いようです。
こうしたファイルのファインダビリティに対する Away のアプローチに最も近いのは、コマンドラインでのファイルシステム操作でしょう。CUI のファイル操作では、列挙型と分類合成型の総合がごく自然に行われていました。GUI のディレクトリツリービューは、直感的な操作可能性をもたらした一方で、ユーザー自身がとりうる分類と検索に対する"情報戦略"上の選択肢を極端に限定してしまったともいえます。
そもそも検索とは、どんなものでも、しまった場所、名前、特徴の三次元の情報に着目して行うのが基本です。(分類法でみれば、しまった場所は列挙型、特徴は分析合成型となります。名前は分類項目ではなく個体識別子です。)
Away は、こうした三次元の情報を一行のコンパクトなテキストにまとめ、たとえうろ覚えでも、たいていの場合は一度か二度の部分一致検索で目的のファイルをうまく引き出せるようなインターフェースの実現を目指して設計されました。
あまり目立たない部分ですが、その一環としてたとえば、検索フォームのインタラクションをあえて標準的なマナーとは異なる仕様で実装してみました。クリアボタン(右端のx)をタップすると、つねに入力されているすべての文字列がクリアされるのではなく、パス表現が入力されている場合は、1階層分のパスだけが削除されるようになっています。
その結果、DraftPad + Away は、他の Dropbox クライアントアプリとは一線を画すものとなりました。というよりも、もともと Away は DraftPad を Dropbox クライアントにするためのアシストではありません。あくまでも、Dropbox をバックエンドに使って、DraftPad の"一枚の紙"の機能を、その哲学と美学を損なうことなく、ささやかに拡張するためのアシストなのです。
... 。
なんつって、うそ！
ほんとはディレクトリツリーの実装が面倒で日和った結果なんですけどね！
でも、それで使ってみたら、そういう可能性を感じてしまったわけです。それは、ほんと。
/memo/away/超整理
Dropbox 上のリソースにアクセスするUIとして不十分に見えるかもしれませんが、これにより、図書分類法的にいえば、列挙型分類法と分析合成型分類法を必要に応じて自由に組み合わせて使える分類/検索インターフェースを実現しています。
列挙型分類とは、あらかじめカテゴリを定義しておき、オブジェクトをそれにふさわしいカテゴリに仕分けていく分類方法です。カテゴリを特定すれば、当該のカテゴリに所属するオブジェクトが得られます。ふつうファイルシステムといったときにイメージするディレクトリツリーは、列挙型分類法にしたがったUIだといえます。
一方、分析合成型分類とは、あらかじめオブジェクトの属性の種類を定義しておき、各対象の各属性にふさわしい値を与えていく分類方法です。属性の値（の組み合わせ）に関する条件を指定すると、条件にマッチするオブジェクトが得られます。ソーシャルブックマークのタギングは、分析合成型分類法の具体例のひとつだといえます。インフォメーションアーキテクチャの世界ではこれをファセット分類と呼ぶようです。
多くの Dropbox クライアントは、フォルダとファイルのツリー構造をビジュアル化したビューを持ち、いわば列挙型分類法のみにしたがっています。フォルダ名やファイル名でオブジェクトを検索する Away も、基本的に列挙型分類法にしたがっているといえますが、Dropbox の検索仕様と Away のパス記法ベースの UI に基づいて、列挙型分類法に分析合成型分類法を補完的に組み合わせて活用することも可能になっています。
Dropbox では、フォルダ名、ファイル名の部分一致で検索する際、検索範囲を特定のパス以下に限定することができます。
Away で ”/path/to/a” を検索すると、”/path/to/” の直下にあるフォルダやファイルの”/path/to/abc/” や ”/path/to/abc.txt” だけではなく "/path/to/foo/bar/abc" や ”/path/to/x/y/z/abc.txt” などもヒットします。
したがって、次のような規則を作って各種のテキストを保存すれば、ディレクトリ名と文書名とタグを組み合わせて、さまざまな角度から必要なテキストをすばやく取り出せるようになります。
< 規則 >
カテゴリをあらわすディレクトリ ( "/"区切り) + 時間をあらわすディレクトリ ( "/"区切り) + 文書名とタグ (スペース区切り)
< 例 >
/Aプロジェクト/2012/06/Aとはそもそも何なのか？ 社内 議事録
など。
すると、プロジェクト名や文書名を直接検索するだけではなく、たとえば、2012年6月に作ったAプロジェクトの社内資料を探したいときは、
/Aプロジェクト/2012/06/社内
と入力して検索することができるようになります。
また、2012年のAプロジェクトの議事録を探したいときは、
/Aプロジェクト/2012/議事録
と入力して検索することができます。
このように、Away でのファイル検索は、ディレクトリツリーベースのファイルシステムを操作しながら目的のファイルを格納した場所にたどり着くというよりも、検索範囲を狭めたり広げたりしながらタギングしたファイルを一挙に取り出すような操作感になります。
実は、Dropbox 社製の iPhone クライアントでも、同じような操作を行うことは可能です。特定のフォルダ以下に範囲を限定してフォルダ名やファイル名で検索することができます。しかし、ディレクトリをたどるUIが中心なので、こうした列挙型+ 分析合成型両分類法を総合した"超整理"の可能性は残念ながら影に隠れてしまっています。
PC向けOSのファイルシステムにも、特定のフォルダを指定し、サブフォルダを検索対象に含めて、部分一致でファイルやフォルダを検索できる機能が備わっているのがふつうです。しかし、やはりこれもある種のレスキュー的な機能として普段は隠されていることが多いようです。
こうしたファイルのファインダビリティに対する Away のアプローチに最も近いのは、コマンドラインでのファイルシステム操作でしょう。CUI のファイル操作では、列挙型と分類合成型の総合がごく自然に行われていました。GUI のディレクトリツリービューは、直感的な操作可能性をもたらした一方で、ユーザー自身がとりうる分類と検索に対する"情報戦略"上の選択肢を極端に限定してしまったともいえます。
そもそも検索とは、どんなものでも、しまった場所、名前、特徴の三次元の情報に着目して行うのが基本です。(分類法でみれば、しまった場所は列挙型、特徴は分析合成型となります。名前は分類項目ではなく個体識別子です。)
Away は、こうした三次元の情報を一行のコンパクトなテキストにまとめ、たとえうろ覚えでも、たいていの場合は一度か二度の部分一致検索で目的のファイルをうまく引き出せるようなインターフェースの実現を目指して設計されました。
あまり目立たない部分ですが、その一環としてたとえば、検索フォームのインタラクションをあえて標準的なマナーとは異なる仕様で実装してみました。クリアボタン(右端のx)をタップすると、つねに入力されているすべての文字列がクリアされるのではなく、パス表現が入力されている場合は、1階層分のパスだけが削除されるようになっています。
その結果、DraftPad + Away は、他の Dropbox クライアントアプリとは一線を画すものとなりました。というよりも、もともと Away は DraftPad を Dropbox クライアントにするためのアシストではありません。あくまでも、Dropbox をバックエンドに使って、DraftPad の"一枚の紙"の機能を、その哲学と美学を損なうことなく、ささやかに拡張するためのアシストなのです。
... 。
なんつって、うそ！
ほんとはディレクトリツリーの実装が面倒で日和った結果なんですけどね！
でも、それで使ってみたら、そういう可能性を感じてしまったわけです。それは、ほんと。
/memo/away/超整理
2012年6月15日金曜日
D箱のアシスト事件 第8夜 ( おまけ )
特集DraftPad/短期集中連載
D箱のアシスト事件
第8夜. 今日からはパブリックベータ！
第7夜でお別れを告げてからはやいものでかれこれ4ヶ月。しょぼくれたぼくのところにも公平に春が来て、そして去っていきました。
その間、DraftPad + アシストまわりでは、iOS5.1 での LocalStorage に関するバグ騒動 (http://manabuueno.tumblr.com/post/20776637086/ios-5-1-localstorage) なんてのがありました。
Away (プライベートベータ版)も認証情報の保持に LocalStorage を使っていたので、 DraftPad を新しいバージョンに更新するたびに動かなくなっていました。しかし、どうせプライベートベータ、まともに使っているのはぼくだけだろうから、上記の URL にある「ウェブ開発者」向けの親切な勧告もどこ吹く風で、そのままほったらかしていました。
DraftPadの更新があったら、いったん削除して新規にインストールし直していました。そうすれば LocalStorage を使っているアシストも動きましたからね。そのたびに溜め込んだアシストやヒストリーが消えてしまうわけですけど、まあ、それも心機一転、ときどきこうしてこざっぱりするのも悪くないかな！なんて余裕をぶっこかせていただいておりましたよ。
ところがつい最近、さるお方(大物)から DraftPad をアップデートしたら Away が動かなくなって困っておる、どうにかならんのかね？アアン？というご連絡をいただきましてビーンとはね起きました。ここはひとつシャンと背筋を伸ばして誠心誠意対応せざるをえない状況というわけで、勧告に従い、localStorageの使用をやめて Cookieを使うように改造したわけです。
そうして4ヶ月ぶりに Away のコードをしみじみと眺め、また、あらためて一連の動作を確認しているうちに、ふと、ひょっとしてこうすれば Dropbox の審査をパスできるんじゃないかな？というアイディアが浮かびました。
いや、もうじつに簡単な話なのですが、あの第1～7夜ではヒートアップしておりましたからね、ああいうときはどうも、自分のやっていることに誇りを持ちたい一心で、つい必要以上に問題を複雑かつ大袈裟に捉えがちです。それに、作業の積み重ねで暗にもったいない精神にも取り付かれていますから視野狭窄になりがちですしね。
それにくらべたら4ヶ月後のシラけた自分は実に自由。そして柔軟。四の五の言わず、OAuth の アクセストークンをアシストの URL のクエリーに入れちゃえばそれでいいんじゃない？ で、ユーザー専用のアシストを Dropbox の認証のあとで動的に生成する Web サービスとして審査に出してみたらどうだ？ふつうに Web ブラウザで使うサービスとして。そうすればほら、第7夜で書いた問題なんていっぺんにみんな解決しちゃうわけだし。なんて、いやにカンタンに言い放つわけです。
で、もはやもったいないフリーな心と体でざくざくコードを削ったり書き直したりして、ゆうべ審査に出してみたんです。そうしたらあっさり通っちゃって、なんと数時間後には Dropbox から「おめでとうございます」なんてメールが届いていました。
というわけで、DraftPad に入力したテキストを Dropbox の任意のパスに保存できるアシスト「Away」 は、このたびめでたく年季が明けて、晴れて誰でも使えるようにあいなりました。今後はパブリックベータということでひとつよろしくお願いいたします。
Away アシストメーカー
こちらの URL にアクセスして「Make Assist」ボタンをタップすると DropBox につながります。そこで Away からのアクセスを許可していただければ、Dropbox 上のテキストファイルを開くための「Open」アシストと、Draftpad のテキストを Dropbox に保存するための「Save」アシストをインポートするためのリンクが表示されます。タップしてあなたの DraftPad にインポートしてください。
Away の使用方法は第二夜で画面キャプチャつきでご紹介しています。
D箱のアシスト事件 第2夜
より詳細な使用方法についてはこちらをご覧ください。
ところで、アシストの URL のクエリパラメータに OAuth のアクセストークンを直接書き込んじゃうなんてセキュリティ的に脆すぎないか？ってお思いの方もいらっしゃることでしょう。
アシストの本体はネットの向こうにあるんだから、実行のたびにアクセストークンが素っ裸のまま URL に含まれてネットワークを流れていくんじゃないかって。しかし、ここが DraftPad のアシスト機構のすごいところの1つでもあるんですけど、DraftPad はアシストを内蔵ブラウザに読み込んだ後で、クエリパラメータの値を直接注入してくれるんです。アシストのクエリパラメータはネットには流れないんですね。完全にローカルな、iPhone アプリの内部処理なんです。ついでにいうと、アシストメーカーからアシストをインポートするところもローカルですね。( 内蔵ブラウザに読み込まれた Javascript からサーバーに対してアクセストークンを含めた XMLHttpRequest を投げますが、これは SSL かつ POST でやっています。)
とはいえ、アシストの URL の取り扱いにはくれぐれも注意してください。間違ってお友達に教えてしまったら、お友達はあなたの Dropbox にアクセスし放題です。
D箱のアシスト事件
第8夜. 今日からはパブリックベータ！
第7夜でお別れを告げてからはやいものでかれこれ4ヶ月。しょぼくれたぼくのところにも公平に春が来て、そして去っていきました。
その間、DraftPad + アシストまわりでは、iOS5.1 での LocalStorage に関するバグ騒動 (http://manabuueno.tumblr.com/post/20776637086/ios-5-1-localstorage) なんてのがありました。
Away (プライベートベータ版)も認証情報の保持に LocalStorage を使っていたので、 DraftPad を新しいバージョンに更新するたびに動かなくなっていました。しかし、どうせプライベートベータ、まともに使っているのはぼくだけだろうから、上記の URL にある「ウェブ開発者」向けの親切な勧告もどこ吹く風で、そのままほったらかしていました。
DraftPadの更新があったら、いったん削除して新規にインストールし直していました。そうすれば LocalStorage を使っているアシストも動きましたからね。そのたびに溜め込んだアシストやヒストリーが消えてしまうわけですけど、まあ、それも心機一転、ときどきこうしてこざっぱりするのも悪くないかな！なんて余裕をぶっこかせていただいておりましたよ。
ところがつい最近、さるお方(大物)から DraftPad をアップデートしたら Away が動かなくなって困っておる、どうにかならんのかね？アアン？というご連絡をいただきましてビーンとはね起きました。ここはひとつシャンと背筋を伸ばして誠心誠意対応せざるをえない状況というわけで、勧告に従い、localStorageの使用をやめて Cookieを使うように改造したわけです。
そうして4ヶ月ぶりに Away のコードをしみじみと眺め、また、あらためて一連の動作を確認しているうちに、ふと、ひょっとしてこうすれば Dropbox の審査をパスできるんじゃないかな？というアイディアが浮かびました。
いや、もうじつに簡単な話なのですが、あの第1～7夜ではヒートアップしておりましたからね、ああいうときはどうも、自分のやっていることに誇りを持ちたい一心で、つい必要以上に問題を複雑かつ大袈裟に捉えがちです。それに、作業の積み重ねで暗にもったいない精神にも取り付かれていますから視野狭窄になりがちですしね。
それにくらべたら4ヶ月後のシラけた自分は実に自由。そして柔軟。四の五の言わず、OAuth の アクセストークンをアシストの URL のクエリーに入れちゃえばそれでいいんじゃない？ で、ユーザー専用のアシストを Dropbox の認証のあとで動的に生成する Web サービスとして審査に出してみたらどうだ？ふつうに Web ブラウザで使うサービスとして。そうすればほら、第7夜で書いた問題なんていっぺんにみんな解決しちゃうわけだし。なんて、いやにカンタンに言い放つわけです。
で、もはやもったいないフリーな心と体でざくざくコードを削ったり書き直したりして、ゆうべ審査に出してみたんです。そうしたらあっさり通っちゃって、なんと数時間後には Dropbox から「おめでとうございます」なんてメールが届いていました。
というわけで、DraftPad に入力したテキストを Dropbox の任意のパスに保存できるアシスト「Away」 は、このたびめでたく年季が明けて、晴れて誰でも使えるようにあいなりました。今後はパブリックベータということでひとつよろしくお願いいたします。
Away アシストメーカー
こちらの URL にアクセスして「Make Assist」ボタンをタップすると DropBox につながります。そこで Away からのアクセスを許可していただければ、Dropbox 上のテキストファイルを開くための「Open」アシストと、Draftpad のテキストを Dropbox に保存するための「Save」アシストをインポートするためのリンクが表示されます。タップしてあなたの DraftPad にインポートしてください。
Away の使用方法は第二夜で画面キャプチャつきでご紹介しています。
D箱のアシスト事件 第2夜
より詳細な使用方法についてはこちらをご覧ください。
ところで、アシストの URL のクエリパラメータに OAuth のアクセストークンを直接書き込んじゃうなんてセキュリティ的に脆すぎないか？ってお思いの方もいらっしゃることでしょう。
アシストの本体はネットの向こうにあるんだから、実行のたびにアクセストークンが素っ裸のまま URL に含まれてネットワークを流れていくんじゃないかって。しかし、ここが DraftPad のアシスト機構のすごいところの1つでもあるんですけど、DraftPad はアシストを内蔵ブラウザに読み込んだ後で、クエリパラメータの値を直接注入してくれるんです。アシストのクエリパラメータはネットには流れないんですね。完全にローカルな、iPhone アプリの内部処理なんです。ついでにいうと、アシストメーカーからアシストをインポートするところもローカルですね。( 内蔵ブラウザに読み込まれた Javascript からサーバーに対してアクセストークンを含めた XMLHttpRequest を投げますが、これは SSL かつ POST でやっています。)
とはいえ、アシストの URL の取り扱いにはくれぐれも注意してください。間違ってお友達に教えてしまったら、お友達はあなたの Dropbox にアクセスし放題です。
2012年2月11日土曜日
D箱のアシスト事件 第7夜 ( 最終回 )
特集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ヶ月前のこと。ところがこの話、これで終わりではなかったのです...。
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月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 通信を確立する際のものと思しき通信エラーが頻発して、そのままでは、とても実用に耐えられない状態なのです。
長いテキストが扱えないというのはまだしも、何か操作するたびに、しょっちゅう通信エラーが発生してしまうのはいくらなんでもいただけないでしょう。
そこで、幸い、というべきかどうか、諸々のエラーは確率的にしか発生しないので、暗黙のリトライをしまくってごまかすことにしました。
もともとつくりがシンプルだったせいもあって、ソースコードの半分近くが、エラーの検知やリトライのための処理で埋めつくされてしまうことになってしまいましたが、裏で何があろうと、表面上は何事もなかったかのようにしれっと動くようになりました。
きっとこういうのは何かの縮図なんだろうなとか、とりとめのないことを考えそうになりましたが、そういうのは早めに切り上げて、とりあえずこれでいいや、中くらいの、おらが世の春だと思うことにしました。
ところが、そうして一息ついたところを狙いすましていたかのように、さらにもうひとつ、新たな問題が浮上してきたのです ... 。
つづく。
登録:
投稿 (Atom)