Postmarkというメール送信のSaaSをやっているWildbitという会社の人へのインタビュー。WildbitはBeanstalkというSubversionホスティングもやってる。
Amazon Web ServicesがAmazon Simple Email Service (Amazon SES)を始めたけどどうよ、という問いにたいして、「価格面で勝負せずとも、安定性、サポート、使いやすさなどで競うことはできる」という認識。また、Amazonが乗り出してきたということはそこに市場があることの証明である、とも。
今日はRailsでPayPalの即時支払い通知(IPN)を叩く一日であった。IPNについては、PayPal側からどのタイミングでどのレスポンスが飛んで来るのかということについて包括的な説明が見つからなかったのだけど、Paypal subscriptions IPN demystifiedというページが具体的に解説してくれていてとても参考になった。
ところで、PayPalは、各種名称やサイトの説明、実際の処理フローにいたるまで、すべてのことを要以上に複雑化しすぎだ。例えば開発者としてPayPalをサービスに組み込もうとした場合、自分が使うべきソリューションを選ぶ段階で挫けると思う。つまり、
これらがどのように異なっていて、どれを利用すべきかがぜんぜん直感的にわからない。まあモバイル決済くらいはわかるけど、少しはRecurlyやChargifyのわかりやすさを見習っていただきたい。
PayPalはAPIを叩いたりせずに、HTMLレベルでボタンを貼るだけで済ませておくのが一番バランスがよさそうだ。
以下、今日の気になったURL。
そういや今日はheroku consoleでこんなエラーが出た。
$ heroku console
Your application is too busy to open a console session.
Console sessions require an open dyno to use for execution.
heroku consoleが原因でブラウザからのアクセスがブロックされる場合がある。
という挙動が手元では確認できているのですが、いまいち因果関係がつかめないので、確認できたことだけ書いておきます。Herokuで運用中のアプリケーションをheroku consoleでメンテする時は気に留めておくといいかもしれません。
Herokuにデプロイしたアプリケーションはheroku consoleで対話的な操作が可能となるため、簡単なメンテナンス作業やデバッグをここで済ませてしまうこともあると思いますが、ここで時間のかかる処理を行うと、その間ブラウザからのリクエストが（heroku consoleのレスポンスが返るまで）待たされることがあります。のんびりループとか回してると、その間誰もアクセスできない恐怖。
このことは、たとえばheroku consoleでsleep 20といったコマンドを実行している間に、ブラウザでアプリケーションにアクセスするとリクエストの完了までに20秒以上待たされることから確認できると思います。
調べてみてわかったことは、heroku consoleコマンドが裏側でHeroku APIに対してPOSTリクエストを送るような構造になっていることと（/lib/heroku/client.rb#L209）、そのリクエストが最終的にDynoで処理されているということ。
例として、アプリケーションのDynoが1つだけの場合、以下のようにしてheroku consoleを実行すると、
$ heroku console "puts 'console with 1 dyno'"
heroku logsで取得できるログは次のようになります。
2011-03-23 00:29:15 +0900 app[web.1]: console with 1 dyno
2011-03-23 00:29:15 +0900 heroku[router]: POST myapp.heroku.com/_heroku/console dyno=web.1 queue=0 wait=0ms service=4ms bytes=189
2011-03-23 00:29:15 +0900 heroku[nginx]: POST /_heroku/console? HTTP/1.1 | 50.16.64.138 | 171 | http | 200
Heroku APIに向けて投げられたconsoleコマンドのPOSTリクエストが、Router、Nginxを経由して自分のアプリケーションのDyno（=この場合はweb.1）までたどり着いています。各行の順序がしっくりこないのはたぶんそういうもの。
heroku consoleがDynoを専有するから…ということであれば話は簡単で、アプリケーションに割り当てるDynoを2や3にすれば解決しそうですが、実際に試したところ、タイミングによってブロックされたりされなかったりという感じで、Dynoだけの問題ではなさそう。複数のDynoを起動して、heroku consoleとブラウザからのリクエストを何度か行ったケースのログを見ると、Dynoがレスポンスを返した後のNginxかRouterで詰まっているような気がしないこともない。
そうでなくても以下のようなこともあるし、基本的にheroku consoleで待ち時間の発生する処理はしないということで今のところは逃げています。
$ heroku console
>> sleep 70
Timed out. Long running requests are not supported on the console.
Please consider creating a rake task instead.