ただのにっき

■ pocketer増刷

RubyKaigiも近づいていることだし、以前作った名刺がそろそろ底を尽きそうだったこともあり、またpocketerで50枚追加した。

今回、写真のバリエーションは変えず。以前使った写真をフォト蔵に残しておけば、ぽんぽん選ぶだけなので楽だ。どうせなら裏面の文字も残しておいてくれればいいのにね。

で、勢い余ってレザーケースまで買ってしまった。このオレンジ色がまたいい感じに好みなんだな。

■ Amazon API認証のPROXYを書いたよ(2)

amazon-auth-proxyの仕様

(2009-07-07:URL形式の仕様追加。レスポンスについて仕様追加。)
(2009-07-23:レスポンスとして302リダイレクトを強く推奨。)
(2009-07-29:Styleパラメタ対応について追記。)

先月公開したamazon-auth-proxyだが、実は満足に動いてなかった(笑)。というか、単純なPROXYになればいいと考えていたけど、ちょっと複雑な事情があったので、仕様をもう少し確定する必要があった。コードは引き続きGitHubから:

amazon-auth-proxy

とりあえずこれで、手元のtDiaryは動いてる。

仕様的には、これくらい決めておけばいいかなー、と:

• 提供するURLは「http://(任意)/(locale)/」とする。(locale)はca、de、fr、jp、uk、usから任意のものを選択できるが、それぞれに対応するAmazon APIを呼び出すこと
• RESTタイプのAPIに対応し、認証抜きの呼び出しを認証付きに変更してする
• パラメタ内にあるAWSAccessKeyIdもしくはSubscriptionIdは、自身のアクセスキーに変更*1
• Timestampはパラメタにあっても無視し、現在時刻で付け直す
• AssociateTagが指定されていない場合は自身のものを付加してよい*2
• Styleパラメタが指定されている場合は、XSLT用のエンドポイント(xml-(locale).amznxslt.com/onca/xml)を使う
• レスポンスは以下のいずれかを選択可能
  • 【強く推奨】認証signature付きのURLを302でリダイレクト(受け取ったクライアントはそのURLを使ってAmazon APIをcall)
  • AmazonのAPIをcallして、その結果を丸々返す

こうやって仕様を決めておかないと、従来のアプリのエントリポイントだけをPROXYのものに置き換えれば余計な変更なしで動くという目標が達成できない。ということで、異なる実装をする人はこのへんに準拠して欲しい。今のところこの方向の実装になりそうなのはこのふたつ?:

• poppen版(on Google App Engine)
• furyu-tei版(on Google App Engine)

逆に、danさんの実装はシンプルでいいかも知れないけど既存のAPI利用者が嬉しくない。

amazon-auth-proxyクラスタに関するアイデア

ところで、open proxyにする場合に、毎秒1回制限とか、不正利用による利用停止の問題が指摘されているが、これは複数のPROXYを束ねて順番に使いまわすことでリスクを低減できると考えている。最初は提案されたDNSラウンドロビンで良いと考えていたけど、参加制約がありすぎるので没。

あとはreverse proxyを用意するか(背後で複数のproxyに振り分け)、302リダイレクトを使うかどっちかかなー。一長一短があるけど後者が楽か。もっとも、Rubyでは$SAFE=1のときにopen-uriが302リダイレクトを処理してくれないという(バグ|仕様)があるので前者じゃないと困るというのがある(笑)。

あと、reverse proxyにするとアクセス元を絞れるので、ダイレクトに不正利用されるのを防げるという利点もあるな。というわけで、誰かreverse proxyを提供してくれないかのぅ。

Web APIに対する私見

あと最後に、これだけは書いておきたい。

デジモノに埋もれる日々のProduct Advertising APIの秘密鍵とクライアント型ソフトに関する公式見解という記事にこんな記述があったけど:

これは本来あるべき姿に戻ったというか、javascriptなどから直接APIを 呼んでいたケースについてはこのように自前のサーバ(CGI等)をクッションとして クライアント直コール型からサーバ型に変換されるべきという意味で 非常にいい仕組みだと思います。

冗談じゃない。こんなクソみたいな仕掛けを考えなきゃいけないなんて、間違ってるとしか言いようがないだろ。

「Amazon APIが無尽蔵に使える共有DB」ではない、という点にはおおいに同意するが、それはあらゆるリソースについて言えることだ。今回の新しい制限によって、APIを嫌がってWebページのスクレイピングに戻る開発者だって出てくるだろう*3。そんな実装のせいでHTMLへのアクセスが1日数百万回になったら、AmazonはAPIと同じようにWebへのアクセスも認証制に移行するか? しないよね。

Web APIは、サーバだろうがクライアントだろうが、HTTPというプロトコルさえ喋れれば誰でもcallできることに意味があるのだ。WebブラウザさえあればどんなWebページも表示できるように、HTTPさえ喋れればどんなAPIにもアクセスできるべきだ*4。真にユビキタスな社会がすぐそこまで来ているこの時代に、Amazonの今回の仕様変更は考えうる最悪のやり方だよ。Amazon超カッコワルイ。

■ 川崎 1-1 鹿島@等々力競技場

あーあ、勝てる試合を落としちゃって……。

前半はホントいい感じで、1位相手とは思えないくらい押し気味だったんだけど、前半の終盤に内田のハンド、退場でPK。ここで1点取れたのはいいものの、悪い予感が。なにしろ川崎は、10人のチームにとても弱いのである。

案の定、後半はぱったりと得点の匂いがしなくなり、DFが攻撃意欲ゼロでだらだらと回していたボールを奪われて同点。そのまま終了。

今日は勝たないと～。鹿島は引き分けでも痛くも痒くもないのにさー。

■ iPhoneはMMSで写真を送れば(あまり)リサイズされない

iPhoneで撮った写真は1600x1200ピクセルなんだけど、これをメールに添付すると800x600にリサイズされて送られる。サイズを指定できないが、3G回線で送るのに適切なサイズということなんだろう*1、まぁ良い。

ただ、800x600でも大きすぎると感じる場面で、(AppStoreで買ったツールを使って)リサイズした写真でも、800x600に拡大して送ってくれる。どう考えてもバグです、本当に(ry*2。おまけに拡大具合が微妙で、例えば320x240に縮小した写真をメールで送ると、届いた写真のサイズは800x599だったりする。算数できない?

ところがOS 3.0からサポートされたMMSで写真を添付すると、最大サイズこそ1024x768に制限されるものの、縮小してもそのまま送ってくれることに気づいた。おお、これなら使い物になる。ちなみに上の日記の写真は320x240に縮小してから送ったもの。

もっとも、MMSで送られるメールの文字コードはShift_JISだったりするので(なんでやねん)、受け取る側がISO-2022-JPやUTF-8前提だったりすると困るかも知れないけど。