@mirakui / CookPad
- 1000 models
- 300 controllers
- 2000 routes
CookPadでは： 200msより遅い = 改善されるべき遅いページ
- Completed time (Railsの実行時間)
- X-Runtime (Rackの実行時間)
Railsは遅い？
Rubyに処理をさせない。 静的ファイルはUnicornで配らない。
Nginx → Unicorn
Apache → Varnish → Nginx → Unicorn
- ARのオブジェクト作成
- クエリ以外にも時間がかかる
- オーバーヘッド・メモリ消費が多い
- ルーティング
- ヘルパー
- 速い → hello_index_url
- 100倍遅い！→ controller: 'hello', action: 'index'
- ヘルパー
- テンプレート
- コンパイル時間は重要ではない。一回しか実行されないから
- レンダリング時間が重要 今のところSlim < ERB < Hamlの順で遅い
- Unicorn GC.disable
- 止めといてまとめて実行
http://github.com/cookpad/arproxy
スロークエリを捕まえてfluentd MongoDBに貯めておく
Developers 対 Users, Servers
- find_in_batches
- AR#crack
- mysql2を直接叩く
- newrelic
- munin
- パフォーマンスに影響があったらスロークエリをチェック
- 次にデプロイされるコードをステージングで動かして、チェックできるツールがある
- serializeは使ってないのでよくわからない
- rubyprof, kcachegrind ←詳しすぎるのでおすすめできない。「to_sが重いよね」とかいう結果になったり
- ActiveSupport::Benchmark
===
@kyanny
- 継続が大事！
- ちょっとずつ改善する
- rubygems
- bundler
gemは日々更新されている
そんなことはない！なぜなら
- たくさんのひとが改善している成果を使わない手はない!
- 古いバージョンに縛られてその制約を回避していくのは非生産的
- アップデートが後手にまわるとどんどんたまっていく
- こまめにやるべき
- やる気だけでは続かない
- 日々の作業と相容れない
- email通知だと義務感にかける
- やる気がなくても動く
- Jenkins
- Gemfile.lockの更新を自動でコミット
- 開発者に判断させるには？
- Pull Requestを送る
- 目立つ
- 開発者の見たさ・マージしたさを逆手に取る
- Diffを取りやすい
- 放置できない
傷の浅いうちにgemの振る舞いの変更に追従したい
gemを修正してPull RequestすることでOpen sourceに貢献できる！
- 継続的に依存関係を更新するのは重要
- でも難しいよね
- bnudle updateをJenkinsで自動化
- Pull requestで見える化
- 改善し続けることは大事！
===
@indirect / CLOUDCITY development
多かった
これも多かった
- common vulnerabilities and exposures
- 権限のある企業が番号をふる
- CVEデータベース
- cve.mitre.org
- nvd.nist.gov
- attackを受ける全てだった
- 多数のgemで構成されている
- セキュリティホールが入る機会が増える
- すごく基本的なgemにもsecurity issueがある
- 更新は大変
- 「更新作業してると開発が止まるんでしょ？」
- 更新 = 保険
- 更新しなければ、破滅的な結果になる
- ユーザへの開示
- 責任
- 訴訟
更新を行う価値はある！
- 企業は開示したがらない
- 開発者は認めたがらない
なので
Responsible disclosure policy
- github
- engine yard
公開する前に
- 自分以外の情報が見れる？
- 自分以外の人の何かを無効にできる
どちらかに当てはまるなら、責任ある公開を。
一般にその情報を公開する前に作者にコンタクトをとる
一緒に協力。だめなら、自分で直しちゃえ！
- easy: 直してリリース
- medium: すでに問題が広まっていたら
- 一般に公開する前に直してリリース
- hard: セキュリティ報告者から連絡を受けたら
- すぐに、常にコンタクトを取る
- 見通しを伝える
- 直して、リリースして、感謝
- 個人なら
- gemspec email
- github email
- チームなら
- security address
- PGP key
- disclosure policy
#####古いバージョンの面倒は？ Railsみたいにバックポートしてあげるのがいいよね
#####リリースにあたっては セキュリティパッチはセキュリティーリリースだけにしましょう。
#####一般に公開されてしまったら ASAPで直しましょう
===
@a_matsuda
前進し続ける
- 適切なユースケース
- 適切なapi
- 適切な実装
が必要
却下された
where.notだけRails4に入った
- ideaをgemに
- Jeremyはすごい
- DHHはもっとすごい
- AR4にはwhere.notが入った！
アクションのparamsを引数で受け取る
http://github.com/asakusa_rb/action_args
デコレーターを使おう
http://github.com/amatsuda/active_decorator
Validationをdryに
http://github.com/amatsuda/html5_validators
- Edgeをつかおう
- 注意深く、批判的に
- 自分の問題を解決
- Pull Requestを送ろう！
===
josevalim
4コア → 4 Rails Server
50コア → ？
50コアCPUがそんな高くなく入手可能に
- ドメインロジックで起こる問題
- 例：クラス変数
- shared mutable state(global)
- クラス変数をリクエスト中で変更しないで！
- Ruby coreで起こる問題
- Ruby実装ごとにThread safetyが変わる
- 例：ActionController::Base
- 全controllerが同じinstanceを共有
- YARVではOK, JRuby/Rubiniusではthread unsafe
- でも、GVLは他のコードを止めちゃうのでよくない
- ドメインロジックに関係ない → メンテ性を損ねる
- YARVのパフォーマンスを損ねる
- 開発者がうれしくない
もっといい抽象化が必要！
- 並行性を保証したクラス群
- 数は多すぎ
- Hashで言えばConcurrentHashを作っては？
- ↑あんまよくないと思う。なぜなら
- Hashは要素数によって内部構造を変える
すべてを支配する、単一のクラスが必要
Hash#concurrent_read, Hash#concurrent_writeみたいなの。
- AtomicReferenceをthread.rbに追加
- atomic_accessor
- compare_and_swap
- lock freeなデータ構造に必要
- 共有メモリをつかって通信しない。
- 通信によって共有メモリを作る。
- Channels
- Goroutines
- どっちもfirst-class
- Queue
- SizedQueue
Queueを強化する
- 軽量スレッドがある
軽量なprimitiveを提供する
- semanticsの違いが、並行性への対応を難しくする
- 並行性への理解が足りない。並行的に考えるよう教育が必要！
===
http://gist.github.com/moro/5652724
- Railsが現実世界の、複雑な問題に解決に適用されつつある
- Skinny controllers, Fat models
- モデルが肥大化！
- Rubyのモジュールを拡張したもの
- extend ActiveSupport::Concern
- インスタンスメソッド
- クラスメソッド
- 宣言的メソッド
をひとまとめに扱っていることを規約で示せる！
modelの共通の振る舞いに名前をつけて切り出す
- Taggable
- Commentable
- Censorable
- UsersResource
- Concernで切り出したモジュールはglueに留める
- ロジックはPlain old Rubyなクラスに切り出す
- ベースクラスにあんまり影響を与えない
- 疎結合
あんまり決め手っぽい方法はない
- ベタに条件分岐
- baseクラス側にメソッドを生やす
対策として
- Ruby2.0で追加された
- Concernと相性がいい
- ActiveSupport::Concernはアプリをきれいにするのに役に立つ
- ロジックは別途書く。Concernをでっかくしない
===
Bryan Helmkamp
https://github.com/codeclimate/refactoring-fat-models
RailsはOOPなシステムを作る手段を提供してくれない
- 利点：単純さ
- 欠点：DBスキーマに縛られる
- ☓ Skinny Controller, Fat Model
- ○ Skinny Controller, Skinny Model
mix-inに分けちゃうのはよくない！
- mix-inは継承
- ゴミ捨て場
- オブジェクトを取り出すのが困難
- Value Objects
- Service Objects
- Form Objects
- Query Objects
- View Objects
- Policy Objects
Underengineering / Overengineering
Rails appはUnder engineeringになりがち
複雑さを制御する！
===
nari
http://gist.github.com/authorNari/3812118
- 死んだオブジェクトを回収する
- 二度と参照されなくなった
- Rootsからたどれなくなった = 死んだ
- Mark&Sweep
- Mark Phase
- 到達可能なオブジェクトをマーク
- Sweep Phase
- マークされていないオブジェクトを回収
今まで
- クヌースのアルゴリズム
- Marking buffer
- それもいっぱいになったら、全部再スキャン
- 問題
- リスキャンはおそい
- stack overflowのチェックが完全ではない
- Fiberを使っている時なんか落ちたり
マシンスタックを使わずに、自前のスタックを持ってマーキング
- 足りなくなったらallocate
- 利点
- 複雑なスタックチェックがなくせた
- SEGVしない
- 欠点
- 本当に速いの？
- GC中にstack chunkを割り当てなきゃいけないかも
1.9.3にもbackport済み
- マークビットを一箇所に集める
- Copy on writeとの親和性高
特定のオブジェクトがどのビットなのかをどう見つける？
- 16KB区切りのブロックで確保
- 0x3fffと&して、heapのヘッダーを見つける
- グラフ
- 非再帰マーキングとBitmapマーキングがRuby2.0で実装されたよ！
- RgenGCはcool！
===
@nagachika
コミュニティの話
- 開発スピード
- 35%ほど１日あたりのコミット数増加
- 2.1.0
- 1.9.3
- メンテは続く
- 略
===
- 既存のを置き換える
- agentを効率的に
- コストを減らす
- 句会
- 文化をシステムとして紹介する
- I18nを使っておこう！
- 画像をこわす
- s/a/b/g
- Rubyを学ぶのに、全部はなかなか頭に入らない
- 本を読んでいて、カードに気になる内容のQ&Aを書く
- http://ankisrs.net/
- fluentd
- 手作業では管理できない
- haikanko
- rspec-kickstarter
- http://www.3dcg-arts.net
- Rails, WebGL
- Jenkinsで4,000近くのmodelの変換を検証
- 単純バグを検出する静的解析ツール
- 15のOSSに試して、2つを見つける
- 3パターンしかない
- terminalをbroadcastできる
- http://screenx.tv/demo
- ruby.tw
- RubyConf Taiwan
- 戦おう。ここがオレたちの世界だ
- thunder-image
- http://thunder-image.kibitan.com/
- 失業中