blog.katsuma.tv
当然のごとくmemcachedが最速だろう。。。と思いきや、そうでもない結果に。むしろ一番遅い結果に。なんだこれーーーと思って調べ続けていたのですが、バインディングのgemのコードを追いかけるかぎり、どうもこれはmemcache-clientの実装が原因のよう。 これは、memcache-clientの実装はpure-rubyで実装されているのに対して、TokyoCabinet/TokyoTyrantのバインディングの実装はnativeコードで実装されてあるのが原因のようです。事実、TokyoTyrantはmemcacheプロトコルを実装しているので、memcache-clientを利用してTokyoTyrantにアクセスすると両者はこんな結果になりました。 user system total real
blog.katsuma.tv
前回のエントリー「Pyapalを使った「今すぐ購入」ボタンの作り方 」の続きです。今回、および次回ではPaypalの決済を終えた後に、Paypalからコールバックされる情報を元に、バックエンドとの統合方法、およびマルチバイトを扱う際の注意ポイントを解説していきます。 Paypalからコールバックされる仕掛けはPDT(支払いデータ転送)、およびIPN(即時支払い通知)の２種類があります。これらは一見似ているもので、実際コールバックされる内容はほぼ同じだったりするのですが、実はまったく違う仕掛けなものなので、どちらか一方だけを考慮してもダメで、両方のコールバックともに考慮すべきものです。これらの違いは次の通りです。 PDT PDT の主要機能は、買い手が支払い完了時に自Paypalのサイトから自サイトに自動的にリダイレクトされた時に、支払い取引の詳細を表示することです。つまり、Paypalと自
blog.katsuma.tv
今回もPaypalシリーズの続きです。前回まではこれらのエントリーをご参照ください。 Paypalを使った「今すぐ購入」ボタンの作り方 Paypal「PDT」「IPN」を使った決済とバックエンドの統合(1) さて、前回まででPaypalを利用した場合の自サイトとPaypalサイトとのデータの流れについて、概略を説明しました。今回はその中でPDT、IPNを実際に実装する際の注意点についてまとめておきたいと思います。今回の話は、主に次のPDFファイルの内容を重要な点だけまとめ直して、ハマった点を追記したものなので、あわせて読まれることをお勧めします。 注文管理インテグレーションガイド Sandbox ユーザーガイド Sandbox いきなり本物のクレジットカード情報でやりとりをするわけにはいかないので、閉じられたテスト環境内でまずは実験を行うことになります。Paypalは、このテスト環境を提供
blog.katsuma.tv
(2008.12.19 22:00追記) peer IDをnear IDに修正 先日のAdobe MAXでFlashの新しいプロトコルRTMFPを扱うことができるサービス「Stratus」について発表がありました。これは簡単に言うと、ブラウザで何もインストールすることなくP2Pを実現できる神がかったプロトコル(=RTMFP)と、RTMFPをサポートするサービス(=Stratus)、という位置づけです。上の写真は実際にStratusを介してRTMFPによる通信で僕の家とオフィス（夜中なので真っ暗ですね）をつないでいるものです。 これらについては、Adobe Labsでの次の文章が非常に分かりやすいです。 Stratus service for developing end-to-end applications using RTMFP in Flash Player で、この文章があまりに分
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
blog.katsuma.tv
