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 するんだ（会場笑）
ペット画像で笑いを取る
Speedup Rails
adequote2倍速
テストを繰り返し計測
ブラックボックスの機能のテスト。
例えば 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日目のまとめはこれで終わり。