RubyKaigi 2014 3日目まとめ #rubykaigi

# RubyKaigi 2014 3日目まとめ #rubykaigi
## 前日-当日
2日目のまとめも手間どって睡眠時間2時間だったり。
前日と合わせて3時間半睡眠とかでもうふらふら。
## 入場前
初日・2日目同様、駅前のモスバーガー（会場とは逆の出口）で朝勉強しながら開場待ち。

## 入場
おはよう Rails が9:30からということで、9:15頃に入場。 
特に新たなノベルティはなかったので今日の成果物は無し。

## Ohayō Rails (おはよう Rails) 
Railsを利用している各社エンジニア6名＋司会1名によるパネルディスカッション。
最初に自己紹介。詳細は略。

### Railsどう？
このメンバーの中で一番触ってない立ち位置として。
やはりスタートアップ楽。

PHPの予定だったがRailsに。
Railsで良かった。
おかげで入社した。
自分はRuby,Railsをやりたくて入社したし、そのような同僚は
他にもいる。Ruby＋Railsがなければここにいなかった。

Pの付く言語ハラスメント禁止とのツッコミ(会場の笑)。

Railsのエコシステムが良い。

弊社は人の入れ替わりが早い。
RailsだとReadmeがあれば人が変わってもなんとかできる。
他のフレームワークだとそうもいかない。

ActiveRecordが良いので設計で迷わない。

ActiveRecordは他のフレームワークにも大きな影響を与えている。

ActiveRecordでRuby側で無茶をできるのが良い。
取得した後、各種メソッドでほげほげしたり。

他言語だと ORM まわりで問題がでることが多い。
ActiveRecord だと、あまり問題が発生しない。
少し困っても Arel でなんとかなる。

新人がSQLを知らなくてもデータ操作のロジックを作成できる助かってる。

### エコシステムの話題
まずはテストだけど何使ってる？

RSpec、RSpec、RSpec

一部仕様が固まらないところはテストなし

Railsとテスト。
必要に応じて gem で選択できる。
規模や状況に合わせた拡張が楽。

テストの Fixture とかは？

factory_girl 派が多い

gem 全般について。

Rails 定番の gem 構成が固まっていて統一感がある。
統一感があるので情報量が多い。

gem が多すぎる。100個くらい入る。
知らなきゃいけないことが多い。
エコシステムを覚える必要がある。
slim,haml,cap,rspec‥。

でも、なんだかんだ数が多いって言っても
ある程度定番で、聞いたことのあるものが多い。
あー、あれね。みたいな。

Rails の話じゃなくなるけど、 Rails 以外のフレームワークを
利用していると苦労する。
Rails と合わせて使っていた gem が Rails 依存の実装になっていて
中身をハックする必要がある。

他のフレームワークで Rails ならできる「あれをやりたい」となった時に苦労する。

### gemをなおしたいときどうする？
プルリク　or モンキーパッチどっち？

プルリクが理想なのは分かっているけど、放置されたり
急いでたりすると、まずはモンキーパッチで凌ぐ。

プライベートな gem サーバーに fork する。

しかしフォークを持つと苦労する。
アップデートの際などに、エコシステムの恩恵を受けられなくなる。

でも、本流がマージしてくれないのはツライよね。
あまり活発な動きのない gem 。

自分の場合は、放置されて動きのない gem ならもらってしまう。
「私がメンテしますのでください」って。

すぐマージされるなら、プルリク投げたい。

公開できない gem とかある？

公開すると世界中から様々な要望が来るのが目に見えていて、
メンテが爆発するのが目に見えて公開できない場合がある。

gem は最低限にしたほうが、後で苦労しない。

### fluentd使ってる？
使ってる。ログどうしてる？

使ってる。（複数名）

### gemの話に戻って
gem を使いたい。
使わないと世界規模でコピペをしているような罪悪感。

色々と買収したりするのだが、引き取ったシステムを確認すると
消し忘れの Gem があることが多い。

弊社は開発サイクルが早いがゆえに必要な gem で保たれている

未使用の gem を検出してくれるツールとかあるといいよね

### 開発構成について
キーワード
Apache
Unicorn
AWS
capistrano
Jenkins
Slack
Nginx
AWS
オンプレ
国内クラウド

### cronつらくない？
レールに乗ってない要素
良いスケジューラが欲しい
バックグラウンドをレールに乗せたい

バッチこそ業務。
私の場合は、別アプリケーションでもいいのかな？

### 辛い話
ゲーム業界の人はなぜ Rails を選択するの？
そっちは、 json ベースが多いことを考えると他の選択肢がよくなる場合もあるのでは？

確かに json だけ必要なら他がいいかな、でも他を試すと Rails のほうが楽で Rails に戻る。

Rails は Html を返すのはよいが、 json はどうなの？

Rails はオレオレ構成になりにくいので、安心感がある。
定番があるため。

Rails で、シングルページアプリケーション辛い。
node の方が良い。

そもそもシングルページを作る目的が早く操作することなら、
turbolinksで良いのでは？

Rubyは楽しいけど、 Rails は、そんなに楽しくない
サービス自体を作ることは楽しいけど、Rails の開発自体は
似たような物を作ることが多い。

簡単すぎてつまらない。

Railsを捨てる理由はパフォーマンスぐらいしか見当たらない。
そのパフォーマンスについても色々と改善してきている。

## Hall A : Speeding up Rails 4.2
11:00
Aaron Patterson 様

### 自己紹介
Redhatに勤めてます
赤い鳩の画像（red hato）で笑いを取る

Ruby,Rails Committer
railsコミットナンバーワン

ナンバーワンの秘訣が知りたい？教えよう。
間違ったコミットをして、 `revert` するんだ（会場笑）

http://contributors.rubyonrails.org/

ペット画像で笑いを取る

### Speedup Rails
adequote2倍速

* benchmark-ips  
https://rubygems.org/gems/benchmark-ips
https://github.com/evanphx/benchmark-ips

テストを繰り返し計測

ブラックボックスの機能のテスト。

例えば routes と、 link_to の関係は？
ベンチマーク結果を確認。
urlの数は影響しない。
長さは影響する。線形に遅くなる。
=> 以上からどこかで、線形データがあり配列操作のようなものがあるはず。これを、定数（N）に置き換えて高速化する。

計測し、確認することで原因を予想できる。

その他、計測例を説明。

パフォーマンス対応のためにリファクタリングを続けたら実装コードが無くなった

高度なコード

一番早いコードは存在しないコード

ポイント。いらないオブジェクトをけす。
オブジェクトの対応型を減らせばコードは単純になり、高速化。

大事なのは測って測って測って・・・測ること。

・QA
次のパフォーマンスターゲットは？
View周りかな。

## Hall A : Practical meta-programming in Application
11:30
Kyosuke MOROHASHI 様
永和システム

Idobata の紹介

* この話のゴール
    * 身近に感じるメタプロ
    * 理解して程よく使う

* Rubyの要素
    * class,module
    * object
    * method
    * procedure

* 定番ともいえる attr_accecor の話で解説

* RubyはReflectionAPIが充実している。

* メタプログラミング＝言語の構成要素を実行時に制御する

* RailsのActiveRecord#has_many をお題に説明
    * has_many 関連オブジェクトを返却。そのままのリストを返すわけではない。
    * この例で Associations を返却するように、クラスに切り出せる箇所を抽出することで該当部がただのOOPのコードになり、メタプロの複雑さを軽減できる

* 似たような事例をもう1件説明

＜私のコメント＞
単なる attr_accecor みたいなケースはよく聞く話なんだけど
ActiveRecord#has_many を例にとった クラスの抽出＋クラスマクロで宣言風に呼び出し
という合わせ技は初めて聞いた。
確かに、黒魔術が抑えられて保守しやすく理解しやすい。

## Everything is Broken: A Story of Hope
13:30
Jonan Scheffler 様

@1337807
このアカウント名は leet speak です。
leet speak はアルファベットと見た目が似た数字を使うハッカーの文化。
ギャル語みたいなものです（会場笑）
http://ja.wikipedia.org/wiki/Leet

DNS の説明をひたすら Ruby 関係者に置き換えて会場から笑いが絶えず

詳細は Togetter のまとめを 23-25あたり（更新されたらずれるけど）
http://togetter.com/li/721581?page=23
http://togetter.com/li/721581?page=24
http://togetter.com/li/721581?page=25

## メモ
体力切れ。3日目のまとめはこれで終わり。

## 参照
[Togetter まとめ3日目](http://togetter.com/li/721378)
[Togetter まとめ3日目A](http://togetter.com/li/721581)
[Togetter まとめ3日目B](http://togetter.com/li/721583)