会期中+αの感想エントリ

<a href="http://sue445.hatenablog.com/entry/2014/09/17/200021">Shibuya.rbのRuby Kajaとして1年間振り返ってみた #shibuyarb - くりにっき</a>

<a href="http://sue445.hatenablog.com/entry/2014/09/18/223445">RubyKaigi 1日目まとめ #RubyKaigi - くりにっき</a>

<a href="http://sue445.hatenablog.com/entry/2014/09/19/234914">RubyKaigi 2日目まとめ #rubykaigi - くりにっき</a>

<a href="http://sue445.hatenablog.com/entry/2014/09/20/221919">RubyKaigi 3日目まとめ #rubykaigi - くりにっき</a>

Keynote: Coming soon...

「Coming soon...」がセッションタイトル
過去のRubyConfのkeynoteでしゃべったrubyの新機能（未来）に関して、どれだけ実現したか・どれくらい時間かかったかの振り返り
rubyconf 2001からruby2.0のことを話していて実際にリリースしたのは10年後
-> { } のラムダ式の書き方は最初文句言われたが、いざ入れたら評判よかった。
- 他の人の印象を信じてはいけない
- 個人的にはlambdaがtypoしやすいのでアロー演算子の方をよく使ってる
実現率は 15/22 ≒ 68%。他の機能は言っただけで終わってる
OSSコミュニティはサメのようなものなので泳ぎ続けなければ死んでしまう

Ruby 3.0の話

過去の経緯からリリースは10年後くらいになるかも？
20世紀に生まれたスクリプト言語には型がないが、最近出たScala, TypeScript Dart, Golangはスクリプト言語っぽいけど型がある
StaticTypingの構想
- 静的解析によってバグの可能性をある程度検出できるが、型を導入すると柔軟性が下がる
- Static typing は duck typingに反する
- rubyにStatic Typingがない理由は、無くてもちゃんと動いたから
- 型はコメント以上に信頼性がある（型が間違ってたらコンパイルエラーになるが、コメントが間違えていてもコンパイルエラーにはならない）
- 型チェックを提供するとしたらrubyのサブセットに対して
  - requireに動的に変数を渡す、define_method, method_missingはおそらく制限がかかる
- 詳細は日経Linux 2014年9月号/10月号に原稿書いたので読んでね！

Just in Time compiler for CRuby (CRuby言語処理系向けJITコンパイラ)

https://github.com/imasahiro/rujit

コードを実行しながらよく使われているところを最適化してコンパイルする
- 実行しながらループの中で実行不要なコードをループの外に追い出すとか

Deep down fixtures

fixtureの特徴
- YAML(CSV)形式
- 実際（に近い？）のデータ
- 同じオブジェクトで複数の定義があるもの
ymlはシンプルに書けるが構造に関しては考える必要がある
テストスイートの前にfixtureをINSERTして、その後テストを実行する
fixureはARオブジェクトだがコールバックとバリデーションがスキップされる
yamlにnullを書けばrubyにロードしたらnilになる
erb形式で書くことにより動的に定義できるが、railsチームはあまり推奨していない
fixtureは順番が考慮されないので、順番が必要な場合はOMAPを使う(Ordered Fixtures)
テーブル名とModel名が一致しないような場合は set_fixture_class "テーブル名": ModelNameで指定できる
- Railsの規約にはずれているレガシーテーブルや、namespaceつきのmodelなど
test_with_transaction がRails 4.2に入る？
- https://github.com/rails/rails/issues/16831

The Twelve-factor Ruby 「Ruby を良くするための12のポイント」

最初「Rubyで書かれたソースコードを良くする」のかと思ってたら「Ruby自体のソースコードを良くする」のことだったｗ
rubyコミッタはあまり協調的じゃないのでしばたさんはそのとりまとめや渉外担当をしている
昼間の開発の半分をruby系のOSS開発している
コアクラスの仕様変更はmatzがきめる（どんなに良い機能でもMatzがダメと言ったらダメ）
スタンダードライブラリは各コミッタが自治権を持っている

コミッタに燃料投下する（問題を適切に伝える）方法

reporting line（正しい報告経路）
- メインラインはredmine（題名と内容の他は適当でおｋ）
- サブラインとしてgithubでもokだがPRしか受け付けない
  - サブなのでコアなコミッタは生息していない
  - 大きな変更は必ずredmineにパッチを投げること
- 新米コミッタは全部issueを見ている
- いいbenefit
  - あとで実現されるかもしれないのでとりあえず登録しておくとよい
  - 似たような議論を教えてもらえる
  - 議論が発展する
（その機能が入って）何に使うのか、何が嬉しいのかを書く
- it should be ◯◯'s behavior（この機能はこうあるべき！）だとその人の思い込みのように思える
- 例外ケース
  - symmetrical(upcaseがあるのにdowncaseがないよね的な)
  - POSIXにはある（カーネルの機能をrubyでラップ）
  - [BUG][SEGV]
- コードをくっつけるとベスト
新機能は欲しいと言った人が作る
- I propose awesome function !!!はダメ
バグレポートでもコードつけるのがおすすめ
- irbのバグかと思ったらrailsのバグだったのでrailsにパッチ送ったら直してもらった（いいはなし）
ネーミング重要
- 良い機能作ったけど名前がイマイチなら取り込まれない
- 名前を意識するといいissueレポートが書ける
レッドオーシャンは避ける
- ブルーオーシャン
  - Win/AIX/Solaris
    - マシン系は再現する・しないの報告は嬉しい
  - Rails with trunk
    - rubyのtrunkでrailsを動かした時の問題
  - ドキュメンテーション
    - ドキュメンテーションのカバー率は60%か70%
いいレポートの書き方
- 日本語 is ok, English is better
  - レポートは日本語でも受け付けてもらえるが、英語で書くとより多くに人に見てもらえる
- いいバグレポートは「こうなると思ったのにこうならない」
  - 問題が再現するミニマムケースをつける
  - クラッシュログをつけて送る
  - railsで落ちた時はクラッシュログをつけてほしい（どこに原因があるか特定するため）
不具合があったらとりあえずtrunkで試す
- 不具合はtrunkで先に直して各brnachにバックポートされるので、trunkでは直ってるかもしれない
  - trunkが最高のruby
- 複数のrubyのバージョンで試すとベスト
redmineのurgentフラグを使わない
- コミッタは優先順位をあまり見ない

Scalable deployments - How we deploy Rails app to 100+ hosts in a minute

Jenkinsで裏で本番環境でbundle installとか時間のかかるデプロイをさせておいて開発者は開発環境で確認しつつ、問題なければシンボリックリンクだけ変えて本番リリースというのが印象的だった
capistranoではなく https://github.com/sorah/mamiya でデプロイしてる