AMEE仕様・API概要

AMEE

AMEEがどんなAPIを提供しているのかについてのページを読みました。こういったAPIを今まで使ったことがなかったので、良い勉強なりそうです。
http://my.amee.com/developers/

AMEE仕様・Overview

AMEE

AMEEの仕組みについての調査結果を、しばらく書いていこうと思っています。AMEEについては、こちらをご覧ください。
http://wiki.amee.com/index.php/Overview

  • AMEEは何をやるのか
    • developerがフロントエンドのウェブページを作ることができる
      • エンドユーザーからデータを受け取るようなサービス
      • 広く公開するシステムでもいいし、一つの企業の中の閉じたシステムでもいい
      • 受け取ったデータをAMEEに送る
    • AMEEサーバーの目的
      • profileにデータを保管しておく
      • 二酸化炭素の排出量の変換して、その値を返す
    • 例えば
      • エンドユーザーが、大きなディーゼル車を使って、毎月1000km運転していると入力したら
      • AMEEは、そのデータを保管し、かつ、それは264.5kgの二酸化炭素排出に相当すると伝える
  • なぜAMEEを使うのか
    • AMEEに保管されたデータの特質
      • 研究や開発に費やされた数多くの努力の結果を示している
      • それは、AMEEの考えやドキュメントの背後にある仮定の正しさを証明するものでもある
    • その他の特質
      • データが時間・時期情報と結びついている
      • ガスや電気の価格のようなデータは、月毎に変わる可能性がある
      • パソコンや車などは、技術が進歩すれば値段が変わる
      • もし値段情報をアプリケーションの中にハードコーディングしてしまったら、値段の変動を常にチェックして、定期的にアプリケーションを変更しなければならななくなる
      • AMEEを使うことで、これらの変更を自動的に行なうことができる
  • Profile items
    • これは何か
      • ユーザーのライフサイクルの一つの側面に関する情報
      • 二酸化炭素排出量を算出するための、一つの単位となる
    • 例えば
      • ユーザーが大きなディーゼル車を使っていて、1000km運転した場合
      • 一つのprofile itemを作成する
      • size属性は"large"にする
      • fuel属性は"diesel"にする
      • distanceKmPerMonthというprifile itemのvalueを"1000"にする
    • 生成されたprifile itemはどうなるか
      • この時点における二酸化炭素排出量を、いつでも取得することができる
      • profile itemに設定された情報も参照することができる
      • だから、ユーザーが見たい時に、その情報をAMEEから取得し、それを見せることができる
    • その他の特質
      • profile itemのvalueは変更や削除が可能であり、'"valid from"データを関連付けることもできる
      • AMEEは、prifileの履歴情報も保持している
      • profileを生成した時はvalueを1000kmに設定し、その後、ライフスタイルを変えて300kmになった場合
      • そのどちらの情報も参照することができる
      • 二酸化炭素排出量の増減とともに
  • Data items
    • これは何か
      • 生のデータ
      • profile itemsの二酸化炭素排出量を算出するために使われる
    • どのように使うのか
      • 通常は、profile itemsだけを扱っていれば、必要な情報は得られる
      • ただし、以下のようなことをやりたいのならば、data itemsは有用な情報となる
      • データが意味すること、算出処理の仮定、ユーザーに入力させるべき情報の選定
      • このdata itemsの情報を文章化することが、このwikiページの主な目的
  • Algorithms
    • これは何か
      • profile itemの二酸化炭素排出量を、関連するdata itemを使って算出するために利用される
    • 例えば
      • 大きなディーゼル車に関するdata itemがあり、1kmあたりの二酸化炭素排出量が0.230kgだった場合
      • このような車を一ヶ月で1000km運転したら、以下のようなアルゴリズムが適用される
      • 1.15 x 0.230 x 1000 = 264.5 kgCO2 per month
      • 1.15の意味については、このwikiのcarsのページに書いてある
    • 計算ロジック
      • ほとんどのアルゴリズムは、ユーザーが入力した値(value)を、data itemの値に掛け合わせる
      • しかし、一部のアルゴリズムはもっと複雑な仕組みになっている
      • 様々なdata itemが関わってくることもある

調査メモ２

BlazeDS Comet

下記のエントリー経由。

Cometについて調べたことのメモを書き残しておきます。

『Release It!』からの引用

MEMO
  • What if I can't make the initial connection?
  • What if it takes ten minutes to make the connection?
  • What if I can make the connection and then it gets disconnected?
  • What if I can make the connection and I just can't get any response from the other end?
  • What if it takes two minutes to respond to my query?
  • What if 10000 requests come in at the same time?
  • What if my disk is full when I try to log the error message about the SQLException that happened because the network was bogged down with a worm?
  • What if you actually have to deliver in this decade?

調査メモ１

BlazeDS

わけあって、BlazeDSについて調査をしています。こちらのサンプルを動かしてみたら、かなり衝撃を受けてしまい、一気に興味が沸いてきました。RailsやFacebookAppとからめながら、こちらの方も触っていきたいと思っています。
こちらの記事のプレゼン資料が非常にわかりやすいと思いました。

  • Message
    • クライアント間でメッセージのやり取りができる
    • シリアライズしたActionScriptのオブジェクトをメッセージとして扱う
    • クライアント間のメッセージ交換はXMLだけで作れる
      • サーバーから何か能動的に送る必要がない場合は、サーバーに追加的なコードは必要なし
      • クライアントのAIR/Flexが、そのサーバーのメッセージング機能を利用するだけ
    • メッセージの接続先(クライアント側のコード)
  • JRuby

また、Adobeのマニュアルも参考にしながら、BlazeDSのサーバー側の実装を追っているところです。コードの方も非常にわかりやすく、しかも読めばとても勉強になるような感触を受けました。AIRとかFlexとか触ったことがないので、クライアント側のコードはよくわかりませんでしたが、いずれはやってみたいと思います。

  • Endpoints
    • クライアント側のチャンネルとサーバー側のエンドポイントが対になっている
    • この対の間でのメッセージのフォーマットは統一されている必要がある
    • エンドポイントのフォーマットで何を受け入れるかはWEB-INF/flex/services-config.xmlで定義する
  • MessageBroker
    • メッセージをservicesへ振り分ける
    • エンドポイントがメッセージを受け取ったら、それをMessageBrokerへ渡す
    • メッセージの中に書かれているDistinationを見て、適当なServiceへ渡す
  • TODO
    • ServicesとDistinationsについては、後で調べる
    • EC2上でセットアップして接続してみる(shell操作の練習も兼ねて)

以下のサイトを参考にしました。全てを読み切っていないので、今後も勉強のタネにしていくつもりです。

config/routes.rbの役割

FacebookApp

前回の続き。FacebookApp本で、config/routes.rbを以下のように編集せよと書いてありました。

ActionController::Routing::Routes.draw do |map|

　map.root :controller=>"invitations", :action=>"new"
　map.resources :invitations

end

これがどういうことなのか、ということを今回は追って行きたいと思います。｢RailsによるアジャイルWebアプリケーション開発｣を参考にしました。今後も参考にしていくと思います。
config/routes.rbに書かれた内容(アプリケーションのルーティング定義)は、ActionController::RoutingモジュールのRouteSetオブジェクトに読み込まれます。下記のようにすると、そのオブジェクトにアクセスすることができます。定義されているルートを確認するためには、このオブジェクトのroutesメソッドを呼び出せばよさそうです。

script/console
↓
rs = ActionController::Routing::Routes
puts rs.routes

map.rootを使うと、以下のようなルートが定義されます。URLがルート指定された時に使われるコントローラなりアクションなりを指定してやるわけですね。

ANY    /     {:controller=>"invitations", :action=>"new"}

また、map.resourcesを使うと、以下のようなルートが定義されます。

GET    /invitations(.:format)?                  {:controller=>"invitations", :action=>"index"}
POST   /invitations(.:format)?                  {:controller=>"invitations", :action=>"create"}
GET    /invitations/new(.:format)?              {:controller=>"invitations", :action=>"new"}
GET    /invitations/:id/edit(.:format)?         {:controller=>"invitations", :action=>"edit"}
GET    /invitations/:id(.:format)?              {:controller=>"invitations", :action=>"show"}
PUT    /invitations/:id(.:format)?              {:controller=>"invitations", :action=>"update"}
DELETE /invitations/:id(.:format)?              {:controller=>"invitations", :action=>"destroy"}

このmap.resoursesについては、Rails本の｢リソースベースのルーティング(日本語版：P378)｣に詳しく掲載されているので、後ほど掘り下げてみたいと思っています。
先ほどのRouteSetオブジェクトを使うことによって、ルーティングの動きを確認することも可能です。

rs.recognize_path "/"
=> {:controller=>"invitations", :action=>"new"}
rs.generate :controller => :invitations, :action => :new
=> "/invitations/new"
  • 次回までのTODO
    • RailsとRESTの関係
      • Railsが自動的にやってくれるのはどこまでなのか？
      • 自動化されることで、どんな手間が省けるのか？
      • ルートの(.:format)は何なのか？(Rails本P390にヒントあり)
    • ControllerとViewの関係
      • Viewを呼び出す方法(render/redirect_to/send_xxxの違い)
      • Viewを呼び出すタイミング(2回目のレンダリングでエラーが発生する点など)

外部サーバーからローカルへリダイレクトさせる方法

FacebookApp

｢Developing Facebook Platform Applications with Rails｣に掲載されている事例を参考にしながら、気づいた点を随時メモしていきたいと思います。
ローカルマシンでFacebookアプリをRailsで構築して、それをFacebook上で動かすためには、ローカルマシンをInternetに接続する必要がある(FacebookからのCallbackRequestを受け取る必要ある)のですが、それができない場合は、sshを使ってInternetにつなげるサーバーにローカルから接続して、そのサーバーにローカルとFacebookを中継させます。例えば、InternetにつなげるサーバーとしてAmazonEC2を選んだ場合、以下のようにローカルから実行すると、

ssh app@ec2-xxx-xxx-xxx-xxx.compute-1.amazonaws.com -R :3001:localhost:3000 sleep 99999

FacebookからEC2の3001ポートへCallbackされれば、それがローカルの3000ポートへリダイレクトされるようです。

  • 上記を実行する前に、appユーザーのパスワードを指定しておく(passwd app)
  • EC2のインスタンスを起動する時に、ポート3001を開放しておく
  • Facebook側の設定箇所もけっこうたくさんある(それぞれの役割については調査中)
    • Canvas Callback URL
    • Post-Remove URL
    • Post-Authorize URL
  • それぞれのCallback URLには、｢http://ec2-xxx-xxx-xxx-xxx.compute-1.amazonaws.com:3001｣のように記入
    • 固定IP(Elastic IP)を割り当てれば、インスタンスを再起動しても、Facebook側の設定を変える必要がなくなるのか？

その他、FacebookerをRailsアプリケーションにインストールすると、

script/plugin install git://github.com/mmangino/facebooker.git

config/facebooker.ymlというファイルが生成されるので、そこにFacebook側の情報(API KeyやSecret)を記入する必要があります。また、tunnelにEC2のホスト名や開放しているポートを記入します。

development:
  api_key: <<api_key>>
  secret_key: <<secret_key>>
  canvas_page_name: <<canvas_path>>
  callback_url: http://ec2-xxx-xxx-xxx-xxx.compute-1.amazonaws.com:3001
  pretty_errors: true
  set_asset_host_to_callback_url: true
  tunnel:
    public_host_username: app
    public_host: ec2-xxx-xxx-xxx-xxx.compute-1.amazonaws.com
    public_port: 3001
    local_port: 3000
    server_alive_interval: 0

これで、ローカルでscript/serverを実行して、http://apps.facebook.com/<>を開けば、ローカルのRailsのコードがFacebook上で動きます。

  • 次回までのTODO
    • Railsの仕組みそのものの勉強
    • 特に、config/routes.rb