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/超整理

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 にアクセスし放題です。


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ヶ月前のこと。ところがこの話、これで終わりではなかったのです...。

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.jsexpress という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 に入れて持ち歩いていました。そして、暇さえあればそれをとり出しては眺め、結局途方にくれて、ただ、ため息ばかりついていました。

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 通信を確立する際のものと思しき通信エラーが頻発して、そのままでは、とても実用に耐えられない状態なのです。

長いテキストが扱えないというのはまだしも、何か操作するたびに、しょっちゅう通信エラーが発生してしまうのはいくらなんでもいただけないでしょう。

そこで、幸い、というべきかどうか、諸々のエラーは確率的にしか発生しないので、暗黙のリトライをしまくってごまかすことにしました。

もともとつくりがシンプルだったせいもあって、ソースコードの半分近くが、エラーの検知やリトライのための処理で埋めつくされてしまうことになってしまいましたが、裏で何があろうと、表面上は何事もなかったかのようにしれっと動くようになりました。

きっとこういうのは何かの縮図なんだろうなとか、とりとめのないことを考えそうになりましたが、そういうのは早めに切り上げて、とりあえずこれでいいや、中くらいの、おらが世の春だと思うことにしました。

ところが、そうして一息ついたところを狙いすましていたかのように、さらにもうひとつ、新たな問題が浮上してきたのです ... 。

つづく。

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 するアシストを作れたことに。でも、でもですね ... 。

つづく。

2012年2月6日月曜日

D箱のアシスト事件 第2夜

特集DraftPad/短期集中連載
D箱のアシスト事件

第2夜. Dropbox にセーブするアシスト

DraftPad のアシストシステムはとても強力です。特に、オンラインから内蔵 UIWebView に Javascript コードを読み込み、それで DraftPad 上のテキストを取り扱うことができる機構は、はっきりいって最強です。これさえあればなんでもできる(ような気になれる)。きっと DraftPad を Dropbox クライアントにすることもできるはず。たとえば ...

DraftPad に書きつけたテキストをちぎってとっておきたくなったら、Dropbox の適当なフォルダに、適当な名前をつけて放り込んでおく。

そして手元に戻したくなったら iPhone の 「iPhoneを検索」みたいなかんじでフォルダ名やファイル名の一部を入力して、さっと検索して読み込む。

... こんなアシストはどうでしょう? Dropbox ならデスクトップのテキストエディタと DraftPad の間で同じテキストを共有して編集するなんてこともできるしね!
たとえ万が一、意図しない上書きとかをやっちまったとしても、DraftPad、Dropbox の双方にくそ丁寧な履歴が残ってるから絶対なんとかなるし。具体的な使い勝手はこんなかんじで ...

セーブするとき。

away screen save

最後の行に保存先となる Dropbox のパスを書いておく。「/memo/Dropbox にセーブするアシスト」とかね。この状態でセーブ用のアシストを起動すると、一発で Dropbox の狙った場所にテキストが飛んでいく。

一方、Dropbox 上のテキストを DraftPad に読み込むとき。

オープン用のアシストを起動すると検索フォームが表示される。ここにフォルダ名やファイル名(の一部)を入力すると、マッチするフォルダとファイルが表示される。

away screen open

フォルダをタップすると、そのフォルダに含まれるフォルダとファイルが表示される。そして、ファイルをタップするとその内容が 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 に付け足してみたくなったのです。

つづく。

DraftPad 1.5.2 App Store
対象デバイス: all
カテゴリ: 仕事効率化   価格: ¥0
販売業者: Manabu Ueno