RubyKaigi2011（初日）に参加してきた
午後から参加してきた。
とりあえず箇条書きのメモを載せておく。あとで感想を書こう。
Ruby を利用した大規模ウェブサービスの開発・運用 / @hotchpotch
cookpadの中の話。extensionsがとても興味深かった。 この後のgithubとかもそうなんだけど、テスト＝CIがもう当たり前なんだな、という感じがした。
- 1.8.7/2.3
- varnish
- 30ms
- tofu
- solr
- 集合を扱う（Facet
- 重み付け検索（Boost Search
- 動的なフィールド追加（Dynamicfields
- 速度は変わらない、検索の柔軟性
- 空間検索できるらしい
- amebaの事例http://www.cyberagent.co.jp/news/press/2010/0708_2.html
- ベストに集中
- シンプル
- キャッシュにのりやすい
- 非同期を活用
- 共通部分とユーザ固有とを分けることでキャッシュしやすくする
- ユーザの体感速度的に問題ない
- テスト
- rspec 1.x
- unit
- functional
- integration
- JS周りの重視
- capybara-webkit
- JS周りの重視
- リモートサーバ上でテスト
- http://d.hatena.ne.jp/secondlife/20110410/1302442313
- CIを通ったコードのみリリース
- みんなテストを書く
- CIで動かないテスト→将来的に価値のないテスト
- rspec 1.x
- 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
- コミュニケーション
- http://propaneapp.com/
- Haystack
- hoptoadみたいなもの
- 例外を監視
- hubot
- CI/Jenkinsの結果をcampfireに通知
- new relic
- http://newrelic.com/
- パフォーマンスプロファイラ
- レイヤごとに表示
- silverline
- https://silverline.librato.com/
- アプリケーション別にリソースを監視
- デプロイ
- トピックブランチをデプロイすることもある
- それなら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でもいいのかも、適宜
- integrationalなテストとして
- 非同期のテストは？
- あまり経験ない
- 異常系のテストはどうする？
- フェイクでエラー状態のデータを作る
- できないところはユニットテストでカバー
- mockするだけじゃだめ？
Issues of Enterprise Rubyist ～SIerのなかのRubyistが考えるべきこと～ / @ayumin
今日一番興味深かった発表。Rubyは使いたいけど、リスク回避の回避でその方向に持っていくのは難しい。必要としている場所に必要であるということを提示できないといけない。
- SIerの顧客がrubyに求めること
- 安い早い柔軟
- エンタープライズに耐えられる品質
- 自分の手元をrubyで変える
- わざわざやるほど逼迫した需要がない
- たのしいRubyより仕事の役に立つRuby。役立つRubyより、開発現場に欠かせないRuby。
- リスク回避の回避は難しい
- 攻めの部署に、すぐに使えて、柔軟に変更できる。効果をちゃんと測定できるソリューションを提案
- 攻めの部署
- 企画、営業
- まもりの部署
- 開発、運用
- 攻めの部署
- 攻めの部署に、すぐに使えて、柔軟に変更できる。効果をちゃんと測定できるソリューションを提案
- Q&A
- ruby/railsは何が向いてると思います？
- 定型化されていないもの（営業管理？CRM,SFA
- ruby/railsは何が向いてると思います？
日本の図書館はどのようにRubyを使っているか - 「Next-L Enju」と「国会図書館サーチ」 / -
途中から見たけど、とても面白そうだったようなのでUstでみようと思う。 elispは衝撃的。
- solr
- 目録登録がemacs lispで動く
Rubyで作った "critical mission" システムについて / @emorima
TokyoRubyistMeetupでお聞きした、東京ガスでの事例。RubyはWebサービス以外でも使われるべき。
- 東京ガスの事例
- リアルタイムにセンサからの情報を得るために、100プロセスx100スレッド/プロセス=10000スレッド
- ディスクリプタ上限を超えていた
- できるできないではなく、やらなければならない！
- 計算量が必要な部分はCで実装
- 230プロセスを使うプログラム、Cで作りたい？
- "Rubyすげぇ"
- 直感的
- 容易
- Thread
- UDP/TCP Socket
- 便利なメソッド
- yield
- instance_eval
- テストが簡単に書ける
- 正常系は当たり前
- 異常系もできる
- 大規模システムでも使えると思う
- もったいない
- ただスピードと信頼性は課題
- Q&A
- なんでruby？
- お客さんがrubyを選んだから
- rubyのアップグレードする？
- 基本やらない
- 安定稼働がなによりも大事
- やるときは安定性のテストを行う
- なんでruby？