RubyKaigi2014に参加してきた
1日目
気になった事をつらつらと
Ruby2.3 からSymbolのGCはいるよ
Rails5.x系ではSymbol GC使いたいからRuby2.2必須にするよ
APIの話は最高だった
APIの変更には二種類ある。
Breaking Change(Client側のUpdateが必要になる破壊的な変更)
と
Non-Breaking Change(Client側のUpdateが必要ではない非破壊的な変更)
前者はコストが大きく、後者はかんたんである。
後者が望ましい。
できるか？できる。プロトコルを決め、クライアント側で受け取った内容をパースすれば。実現している具体的な例をあげよう。ブラウザだ。
airbnbはすでにやっている
発表資料はこちら。最高だからぜひ見てほしい。ベストスピーカー賞あげたいくらい
Hypermedia: The Missing Element to Building Adaptable Web APIs in Rai…
ドリコムの話
重複したコードをgem化した。
共通した処理をgem化することでコード資産を扱いやすくなった。サイコー。
いまでも開発リソースの一部を割いてgem化を進めている。
「エースの技術力をモブエンジニアにレバレッジするのに役立つ」「エースのソウルジェムも奇麗になる」
腐敗したgemなどのいくつかの要素を可視化し、計測しやすくしている。
オフィシャルパーティー
RubyKaja の発表
@sue445 さん受賞おめでとうございます。
料理は最高に美味しかった。高級ホテルのディナーって感じだった。
何人かの人と話せた。
ほぼぼっちだった。
2日目
Matzの基調講演
型があるといいとは思う。
でもRubyに型を後付けするのは難しい。
(最終行が返り値になるってことみんな意識してコード書いてる？)
だから型推論機能をつけることにした。
型推論は最初は外付けでつける。型推論を使えば、強力なインセンティブがある。
使いたくなければ使わなければいい。今までと同じRubyが書ける。
今までのRubyに型をつける試みは失敗した。これは後づけが困難だったこと、厳格な型定義を行おうとしたこと(?)が原因である。
Rubyの開発チームによるゆるやかな型推論の追加は十分可能である
そのほかの講演
プロダクトコードとテストコードの比率は1:1がよいバランスらしい。
@t_wada もそういっていたからほぼ間違いない
