TAKUYA’s CODE RECORDER

AMEE仕様・Overview

AMEE |

AMEEの仕組みについての調査結果を、しばらく書いていこうと思っています。AMEEについては、こちらをご覧ください。

No such app

• 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 |

下記のエントリー経由。

• Lingr and Comet - 技術解説編:Kenn's Clairvoyance - CNET Japan

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

• Comet
  • HTTPのセッションをつなぎっ放しで、疑似的にサーバ・プッシュを実装する手法
  • Dojo作者のAlexRussell氏が命名
  • Cometに代表されるサーバ・プッシュ技術の復権：安藤幸央のランダウン（38） - ＠IT
• Jetty6
  • Continuations(継続)機構
  • ｢サーバ・プッシュ型のサービスを提供するためのアプリケーション・サーバ／コンテナ技術｣の一つ
  • ページが見付かりません ? recompile.net
  • ページが見付かりません ? recompile.net
  • ページが見付かりません ? recompile.net
• Tomcat6
  • Tomcat 6で実現！Ajaxを超える通信技術Comet：Tomcatはどこまで“安全”にできるのか？（3） - ＠IT
• BlazeDS
  • JavaサーバーからFlex/AIRクライアントにプッシュ
  • ｢サーバ・プッシュ型のサービスを適用するためのフレームワーク｣の一つ

『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が、そのサーバーのメッセージング機能を利用するだけ
  • メッセージの接続先(クライアント側のコード)
    • http://IP:PORT/コンテキスト/messagebroker/チャンネル
    • チャンネルは接続方式/プロトコル(streamingamf/amfpolling)
• JRuby
  • Servlets in JRuby on Tomcat
  • http://www.okisoft.co.jp/esc/ruby/jservlet

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

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

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

• Page not found · GitHub Pages
• 404 Not Found
• [予告編 30分]AIRとBlazeDSとRubyでメッセンジャーを作る[129ページ] – @masuidrive blog
• 404エラーページ
• 404エラーページ
• BlazeDSとAMFでWebとデスクトップのアプリケーションを構築する
• Blaze Data ServicesかLiveCycle Data Servicesか
• JavaとFlex／AIRをつなぐ「炎」のオープンソース（1/3） ─ ＠IT

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回目のレンダリングでエラーが発生する点など)