RubyKaigi2011(初日)に参加してきた

午後から参加してきた。

とりあえず箇条書きのメモを載せておく。あとで感想を書こう。

Ruby を利用した大規模ウェブサービスの開発・運用 / @hotchpotch

cookpadの中の話。extensionsがとても興味深かった。 この後のgithubとかもそうなんだけど、テスト=CIがもう当たり前なんだな、という感じがした。

  • 1.8.7/2.3
  • varnish
    • 30ms
  • tofu
  • solr
  • ベストに集中
    • シンプル
    • キャッシュにのりやすい
    • 非同期を活用
      • 共通部分とユーザ固有とを分けることでキャッシュしやすくする
      • ユーザの体感速度的に問題ない
  • テスト
  • extensions
    • 特定の条件下のみで有効になる機能拡張
    • 新機能の試用などに利用
    • 没になったら rm -rf app/extentions/foo_ext
    • specなくてok
      • 仕様の変更が多い
    • 例外が発生したら自動的に無効になる

Shipping at the Speed of Life / @atoms

githubの中の人の話。マシンガントーク。凄くたくさんのツールを使ってるみたい。

  • githubの維持のためにたくさんのツールを作った
    • 単純作業の自動化
  • BrowserdMod
  • collectd
    • 時系列データの収集(mysqlの書き込み時間とか
  • nagios
  • redis counters
    • 何が何回使われたか
  • campfire
  • Haystack
    • hoptoadみたいなもの
    • 例外を監視
  • hubot
  • CI/Jenkinsの結果をcampfireに通知
  • new relic
  • silverline
  • デプロイ
    • トピックブランチをデプロイすることもある
      • それならmasterにロールバックできる
      • 一部のサーバーに
      • subset deploy
      • heaven というライブラリで、特定のサーバに特定のブランチをデプロイ
  • まとめ
    • 大きなリリースをするときにはブログにポストを書いてユーザの反応を見る
    • 常にデータを集めておく、必要になったときに便利
    • カスタムな機能でプロセスの簡略化、柔軟性
      • プロダクトの成長で変化する
    • いいものをリリースすことを心かける
      • 価値を頻繁に提供する
        • 2週間スプリントとか生ぬるい
  • ユーザを大事にする
  • Q&A
    • マイグレーションどうしてる
      • まずカラム追加
      • それからコードを投入して使う
    • チャットなんでcamfireなん?
      • 安いし十分
    • 物理サーバだけ?
      • 小さなツールはrackspace使ってる
      • puppetとchef knifeで管理してる

Toggleable Mocks and Testing Strategies in a Service Oriented Architecture / EngineYardの中の人

HTTPのテストの仕方。あまり聞けなかった。

  • single responsibility principle
  • コードベースを小さくできる
  • チームで別々の部分を開発できる
  • RESTで通信
  • サーバのテストをするのが難しい
    • 遅い
    • 元の状態に戻せない(変更を受ける側が切り離されている
  • モックを作る
  • mock
    • オブジェクトの偽物
  • stub
  • fake
    • データの偽物
  • fakeweb
    • net/httpに相当するstub
    • fakewebの実装を知っている必要がある
      • テストにfakewebの初期化コードが入ってくるから?
  • Artifice
    • https://github.com/wycats/artifice
    • Rackアプリケーションをnet/httpなテストのつなぎ先として指定できる
      • プロダクションのバックエンドのコードをそのままテストに利用できるかも
  • Q&A
    • mockするだけじゃだめ?
      • integrationalなテストとして
        • unitテストならmockでもいいのかも、適宜
    • 非同期のテストは?
      • あまり経験ない
    • 異常系のテストはどうする?
      • フェイクでエラー状態のデータを作る
      • できないところはユニットテストでカバー

Issues of Enterprise Rubyist ~SIerのなかのRubyistが考えるべきこと~ / @ayumin

今日一番興味深かった発表。Rubyは使いたいけど、リスク回避の回避でその方向に持っていくのは難しい。必要としている場所に必要であるということを提示できないといけない。

  • SIerの顧客がrubyに求めること

  • 自分の手元をrubyで変える

  • わざわざやるほど逼迫した需要がない
  • たのしいRubyより仕事の役に立つRuby。役立つRubyより、開発現場に欠かせないRuby
  • リスク回避の回避は難しい
    • 攻めの部署に、すぐに使えて、柔軟に変更できる。効果をちゃんと測定できるソリューションを提案
      • 攻めの部署
        • 企画、営業
      • まもりの部署
        • 開発、運用
  • Q&A
    • ruby/railsは何が向いてると思います?
      • 定型化されていないもの(営業管理?CRM,SFA

日本の図書館はどのようにRubyを使っているか - 「Next-L Enju」と「国会図書館サーチ」 / -

途中から見たけど、とても面白そうだったようなのでUstでみようと思う。 elispは衝撃的。

Rubyで作った "critical mission" システムについて / @emorima

TokyoRubyistMeetupでお聞きした、東京ガスでの事例。RubyWebサービス以外でも使われるべき。

  • 東京ガスの事例
  • リアルタイムにセンサからの情報を得るために、100プロセスx100スレッド/プロセス=10000スレッド
    • ディスクリプタ上限を超えていた
    • できるできないではなく、やらなければならない!
  • 計算量が必要な部分はCで実装
  • 230プロセスを使うプログラム、Cで作りたい?
  • "Rubyすげぇ"
    • 直感的
    • 容易
    • 便利なメソッド
      • yield
      • instance_eval
    • テストが簡単に書ける
      • 正常系は当たり前
      • 異常系もできる
  • 大規模システムでも使えると思う
    • もったいない
    • ただスピードと信頼性は課題
  • Q&A
    • なんでruby
      • お客さんがrubyを選んだから
    • rubyのアップグレードする?
      • 基本やらない
      • 安定稼働がなによりも大事
      • やるときは安定性のテストを行う