Create  Edit  Diff  FrontPage  Index  Search  Changes  History  Source  RSS  Note  wikifarm  Login

RailsMeetingKansai-0004-Memo

第 4 回 Rails 勉強会@関西 - 感想

私(babie)はついついたくさん書いてしまいましたが、感想なので4〜5行もあれば充分です。

Rails 初心者レッスン by かずひこさん・あゆさん

Saling Rails(Ruby on Rails の大規模化対応について) by rakuto さん

司会進行役だったため気もそぞろでちゃんと聞いていない部分があります。あしからず。by babie

  • 公の場でのプレゼンは初めてらしくちょっと早口だった。けど、堂々と貫禄充分にこなしてた。
  • 配布資料も実際のプレゼンもちょっと字が小さくて見にくかった。
  • カラープレゼン(オレンジの背景に白の字など)が DHH っぽい。
  • 出身同じだけど頭良さそう。いいなー・いいなー。
  • RubyGems の「gem」を「ゲム」と読んでた。「ふつー、ジェムだろ」とツッコミそうになったが、essa さんによる blog「アンカテ」改め「ゲム戦記」の引用かも知れないなと引っ込めた。
  • 元drecom、現UIEvolution(Evaluationと書きそうになった)
  • drecom 時代のエイプリルフールネタサイトでネタ元サイトに目を付けられたらしい。
  • 経歴。Web Service(Web API) 周りの実装が多いなぁ。REST なのか、SOAP なのか、XML-RPC なのか聞くの忘れた。
  • UIEvolution の紹介。中島聡さんの blog (個人blog "Life is beautiful"CNET 連載)は有名だけど、会場の人は知ってるだろうか? 知ってたらいいな。実際会ってどんな人か聞くの忘れた。
  • "Pair Programing 2.0" と "President!" はドドーンとでっかい写真&口で擬音を出して、インパクトが欲しかったかも。あと "President" だと一般的日本人は「大統領」を想起すると思うので、素直に「ご主人様」の方が良いと思った。が、わざと迂遠な表現にしてオタクっぽさを回避してるのかも知れない。ずるい。
  • Mongrel のメリットで、request.env の値が WEBrick に近いことを挙げてた。なる。環境ごとに微妙に違うらしい。例えば QUERY_STRING。
  • 各 Application Server 毎の比較はくまくまーさんとこのを引用
  • Mongrel の具体的な(そのまま使える)使い方が載っていて嬉しい。億劫な私も英語サイト読まずに資料片手に試せる。非常に嬉しい
  • ロードバランサは Apache2.2 with mod_proxy_blancer らしい。確か、はてなスクリーンショットもこの組み合わせ(どこで見たか忘れた)だなぁ。この組み合わせは Mogrel 作者のオススメでもある。
  • ロードバランサの列挙説明で、Pound が小規模用になってたが、実際に速度比較したわけではなく Mongrel 作者サイトからの引用らしい。速度比較が欲しいな(他力本願)。Pound についてはストヤンが運用経験を持ってるので聞くこと> all。
  • 構成の概要。ロードバランサ(Apache2.2 + mod_proxy_balancer)、ウェブサーバ群(Mongrel Cluster)、DB(memcached or dRuby)、永続化データ(MySQL 5.0クラスタの両マスタ構成)。データの格納は高速化のためできるだけmemcached や dRuby に振るようにしているということ。「MySQL 5.0 は遅くね?」という質問には、「わかんね」とのこと。実際に運用してみて様子を見るのだろう。
  • Apache(mod_proxy_balancer) の Mognrel 用設定方法も説明アリ。ウレシス。
  • 最適化。render_component は重いらしい。
  • セッションは memcache に。これももちろん具体的な設定方法あり。memcache-client を gem でインストールしてた。簡単だなぁ。
  • セッションの ActiveRecord Store と memchashd Store のベンチマーク比較は表があるがパッと見どっちが速いかわからない。
  • r/s は リクエスト/秒 なので値が大きいほど良い。ms/r は ミリ秒/リクエスト なので値が小さいほど良い。総じて memcached の方が速い。MySQLのクエリキャッシュが効いている場合は、ActiveRecord Store も(特に複雑なクエリが)大分速くなるが、やっぱり memcached が速い。
  • MySQL では「auto_increment_increment と auto_increment_offset を使えばウマー」らしい。複数DBで id の競合を避けられるらしい。寡聞にして知らなかったので「CREATE TABLE 文で使うのかな?マイグレーションが使えなくなるのかな?」と心配していたけど、調べてみたらシステム環境変数らしい。auto_increment_increment が自動インクリメントの際の間隔値、auto_increment_offset が自動インクリメントのオフセット値。Ruby で表すと、
auto_increment_offset.step(MAX_INT, auto_increment_increment) do |id|
   ...
end

て感じか?

  • 複数DBでウマイってことは、
auto_increment_offsetauto_increment_incrementつまり
サーバA02偶数
サーバB12奇数

でかち合わないということ?

  • 冗長性の確保のため・不可分散はできないって書いてあるけど、デュアルマスタで id の競合が起こらないようにしてるっつーのは、データ保全の冗長性ではないな。高速化はできないけど負荷分散になってるってい意味?

途中だけどここまで。

-> ゲム戦記と掛けてました。というのは嘘で、いいながら気づいたのですが、テンパっていてそのまま言ってました(笑 by rakuto


↓なんか勘違いして議事録になってますが、とりあえず貼っておきます(兼重)。

Rails 適用事例 by 福井さん

概要

福井さん御自身によるRuby on Rails 適用事例、 「販路マッチング・ナビゲート事業支援システム」について。

  • Rubyカンファレンスでの写真
  • 「販路マッチング・ナビゲート事業」の概要
  • 「マッチング」というコンセプトについて
  • 「販路マッチング・ナビゲート事業支援システム」のデモ&苦労話
  • 質疑応答

内容

Rubyカンファレンスでの写真
  • DHH、福井さん、まつもとさんの写真
  • くまくまーさんの写真
  • 関さんの写真
  • Yuguiさんの写真
「販路マッチング・ナビゲート事業」の概要
  • 各分野で定年を迎えられた人(ナビゲータ)が、商品の販路を求めているベンチャーと、新商品を求めている商社などを引き合わせる「マッチング」公共事業
「販路マッチング・ナビゲート事業支援システム」のデモ&苦労話
  • ログイン〜トップページ〜回覧板〜担当企業情報〜ファイルアップロード
  • ナビゲータは得意分野の新商品情報から自分が担当するものを探し、商談を仲介し、その進捗を記録
    • グループウェア的な機能
  • 一部Ajaxを利用(カレンダー部分ほか)
  • 多対多テーブルが多いので、habtmが重宝
  • 利用者はPCが苦手な方が多いので、操作性は重要
  • 予算がない(お堅い官公庁・社団法人でRailsを採用して貰えたのはこの事情が大きい)
質疑応答
  • テーブルの量は?
    • グループウェア部分で10個ぐらい、業務管理部分で30個ぐらい。
  • ファイルアップロードの際のファイルタイプの扱いは?(おそらく判別方法について)
    • ファイルタイプで分けています。(おそらく拡張子)
  • 対象企業の検索方法は?
    • 分類+全文検索で絞込み可能。
  • ファイルのウィルスチェックは?
    • 特にしていない。ログインできるユーザのみアップロード可能なのでユーザーを信用している。
      • そんなときにはアンチウィルスゲートウェイで!(PR)
  • 紹介される企業に公開されている機能は?
    • 自社情報の更新と進捗の確認と担当者とのメッセージのやり取り

参考リンク:

Last modified:2006/06/21 01:07:39
Keyword(s):
References:[RailsMeetingKansai-0004]