Google Wave @ pySpa

pySpa こと、python 温泉 2 日目です。昨日から今日にかけて、@atusi さんと、Google Wave のロボットを作ってみました。pyzon (旧 pyAWWS) を使って、asin:[ASINコード] をタイトルに変換するというボットです。アカウントをお持ちの方は、amzbot@appspot.com を追加すると試すことができます。今のところ、html を blip に表示することはできないので、リンクもテキストになっています。
参考にさせていただいたサイト、およびコード
以下が実際のコードです。

# coding:utf-8

from waveapi import events
from waveapi import model
from waveapi import robot
from pyzon import AWSECommerceService

ROBOT_NAME = 'amzbot'
PROFILE_URL = 'http://%s.appspot.com/' % ROBOT_NAME
IMAGE_URL = PROFILE_URL + 'icon.gif'

awsecapi = AWSECommerceService(
  ACCESS_KEY_ID,
  SECRET_ACCESS_KEY,
  associate_tag = ASSOCIATE_TAG,
  locale = LOCALE
)

DEBUG = True

def get_title_from_asin(contents):
  pass
  """
  contents の中身を変換するための関数
  """

def OnBlipSubmitted(properties, context):
  # blip の取得
  blip = context.GetBlipById(properties['blipId'])
  logging.info(u'blip (%s -> %s' % (blip.GetWaveId(), blip.GetId()))

  # blip のテキストを取得
  contents = blip.GetDocument().GetText()

  # テキストを変換
  result = get_title_from_asin(contents)

  # blip に変換後のテキストをセット
  if result:
    blip.GetDocument().SetText(result)

if __name__ == '__main__':
  # ボットの作成
  bot = robot.Robot(
    ROBOT_NAME.capitalize(),
    '1',
    image_url=IMAGE_URL,
    profile_url=PROFILE_URL
  )

  # サブミット時のハンドリング
  bot.RegisterHandler(events.BLIP_SUBMITTED, OnBlipSubmitted)
  bot.Run(debug=DEBUG)

appengine で bot 書いて wave に突っ込むというのは、すっごい楽ですね。メールやチャットでのコミュニケーションではできない、情報に付加価値をつけていくことが wave では可能となると思います。

コメント

コメントを投稿

このブログの人気の投稿

Disqus のスケール - Django 編

イメージ
やり直し。2010 年の Django Con のスライド より。 Disqus は多くのサイトに組み込まれているサービスのため、メンテナンスによる停止が難しい。 >>> サーバの構成 エッジロードバランサーに HAProxy: heartbeat 構成。レポートが素敵。 HTTP ゲートウェイキャッシュに Varnish Django サーバとして Apache + mod_wsgi: 30 台ぐらい。メモリリークを防ぐために maximum-requests をセット。Ganglia で監視 キャッシュに memcached: 25 台ぐらい PostgreSQL ロードバランサーに HAProxy/ PgBouncer : コネクションプール用。 PostgreSQL: 10 台ぐらい。 Slony-I で非同期レプリケーションとフェイルオーバー。 ログは syslog-ng: pgFouine でスロークエリーをロギング。 全部でサーバ 100 台ぐらい。他にユーティリティサーバ 15 台、後は HAProxy と heartbeat 用に 20 台ぐらいの構成。Varnish と syslog-ng を除けば Django のデプロイ手順に掲載されているような教科書通り (良い意味です) の構成です。(なんで Apache なの？nginx + gunicorn 速いよって突っ込まれてますね >>> データベースのパーティショニング Django はアプリケーションレベルで簡単に 垂直 パーティショニングができます。アプリケーションごとに DB 分けたり、DB をアプリケーションレベルでルーティングできます ( ドキュメント )。 水平パーティショニング (a.k.a シャーディング) もアプリケーションで 書ける (なるほど・・・)。 >>> キャッシュの削除 Django は QuerySet の結果をキャッシュするけど、それがかなりメモリを消費する。なので SkinnyQuerySet を作った (たぶん Johnny Cache の方が有名？...
続きを読む

Disqus のスケール - Django で月間80億PVを処理する

私が把握してる限り Django で一番大きなサービス Disqus のスケール (執筆時点ではサービスダウンしてる)。元ネタは Scaling Django to 8 Billion Page Views です。 月間80億PV 、 45k req/s のほぼすべてのトラフィックを Django で処理しているとのこと。抄訳になるかな。 WAF は 高速開発とパフォーマンス 、 新しい人が入ってすぐに開発に参加できることとカスタマイズ 等のトレードオフがあります。この記事ではそのトレードオフである高速開発とパフォーマンスをどう両立させるか、Disqus のノウハウが紹介されています。 >>> なぜ WAF (Web Application Framework) は遅いのか 最初に思い浮かぶのは、アプリケーションに必要ではないボイラープレート ( django.contrib とか?) や不要なコードがあるため。そもそも Django の思想が Python 同様 " バッテリー同梱 (batteries included) " のため、Django は他の Python 製 WAF よりボイラープレートが多いです。Disqus 曰く "実は 言語や WAF は遅さにあまり関係ない " それより " ネットワーク内の他のサービスとの通信 " のオーバーヘッドが原因とのこと。これは一般的によく言われてることですし、大規模になればなるほどそう。Disqus の場合は PostgreSQL, redis, Cassandra , Memcached 等のサービスが使われているそうです。DB へのスロークエリーやネットワークのレイテンシーは Django のようなボイラープレートによるオーバーヘッドを軽く上回ります。この待ち時間を回避する一番メジャーな方法はキャッシュの使用です。Django では キャッシュフレームワーク を使用します。Django でキャッシュを使うのは簡単ですし、バックエンドに Memcached を使うと充分高速化できます。 はい。ここまでは一般的な話です。こっから。 >>> 45k req/seq を処理する キャッシュしたところで...
続きを読む

#PySpa アドベント (23 日目)

PySpa がどんなイベントかは 既に紹介されつくした感じ ですね。そもそも勉強会は "特定のテーマを共有し理解を深める" という目的のものが多いと思っています。PySpa は、それより "勉強したくなるようなテーマを発見する" ってのが大きいと個人的に思っています。私は 勉強したいテーマを見つける 童心に返って技術を楽しむ 煙草エリアのベンチを温める ために行っています。与えられてばかり、お世話になってばかりです。モチベーションしかり、趣味しかり、仕事しかり。
続きを読む