RubyKaigi 2018 参加記録（2日目）
RubyKaigi 2018 2日目のメモです。
1日目はこちら
Keynote
130個くらいの gem をメンテナンスしている @kstou さんによる基調講演。 自分がメンテしている gem とメンテすることになった経緯についてひたすら紹介していくという圧倒的物量なセッション。
ちょくちょく「自分が必要だったのでメンテナになったのでメンテナンスすることにした」という発言があり、それ自体はよくあることだよなぁと思いつつも、あれだけの量のライブラリをその理由でメンテナンスしていくというのは本当にすごいことだな、と。
また、「Rubyでできることを増やしていきたい」という信念を貫いているのもすごいなぁ、と。
Faster Apps, No Memory Thrash: Get Your Memory Config Right
Ruby のメモリ管理の概説と、それを踏まえた上で現在の Ruby で有効なメモリ節約テクニックとメモリ管理に関する測定方法の紹介。
メモリ節約については
という4つのテクニックを紹介。特に2については適切なパラメータを実際の実行結果から割り出すenv_memというツールでできるそうで、これは Rails に限らず長時間実行されるアプリケーションでは大変有用に見える。
Guild Prototype
Ruby 3 で導入予定の新しい並列プログラミングのための仕組みである Guild のプロトタイプ実装に関する紹介と測定結果について。
GC がグローバルに動くと聞いてさすがにそれはパフォーマンス的に致命的では思ったが、Future work にギルド単位での GC があると聞いて一安心。
とはいえ、Guild が本当にプログラミングを簡単にするかというと個人的にはまだ疑問で、例えば Guild 間でオブジェクトを move した際によからぬ例外が起きるのではとか、その辺がとても不安。理解が足りてないだけだと思うけど……
Scaling Teams using Tests for Productivity and Education
プロジェクトメンバの認知負荷を減らしていくにはどうすればいいかという話。
- 人間は必ずミスする
- 一度にすべてのルールを教えて覚えさせるのは無理がある
という前提に立った上で、テストファイル名の typo といった現実に起こりうるミスに対して具体的なユニットテストを書き、効率的に対処/教育をしていく。
この発表では何かしらミスを検出した際にはWhat/Why/Howを丁寧に示すべきというメッセージが強く推されていた。エラーメッセージは一見すると物事の枝葉のように見え軽視しがちだが、人間が実際に目にするという観点でいうと最も気を使うべき箇所として考えてもいいだろう。
Ruby Programming with Type Checking
昨年の RubyKaigi でも発表があった Steep が2018年現在でどうなっているか。そして実際に既存 Rails app に導入できることを示す発表。
去年の発表を聞いていた時から 3rd party ライブラリはどうしたもんかと思っていたが、YARD などの型注釈コメントをパースして Steep の型定義に変換する機能があるだけで結構な数のライブラリが Steep で解釈できるのではと思った。実際のところどうなんでしょう。
RNode with code positions
2.5 からRubyのASTに追加された code location についての情報と2.6に入る予定の AST API、そしてそれらの実装について。
個人的に Ruby に限らずプログラミング言語は AST を構築するための API を標準で提供してほしいと思っているので、AST の API が追加されたのはとても嬉しい。マルチバージョン対応しないといけない Rubocop では採用は難しいかもしれないが、ツール実装の幅はかなり広がったのではないだろうか。
あともっと個人的には発表に yacc/Bison 成分が想像以上に多く、聞いていてとてもたのしかった。
Type Profiler: An analysis to guess type signatures
これまでの Ruby の型チェックに関連するアプローチの紹介と、それを踏まえた Ruby 3 で導入予定の TypeDB の現在のステータスについて。
示された3つのプロトタイプはどれもメリデメがあるが、個人的には void を解釈するというのはとても大事だと思うので、是非対応してほしいところ。紹介されたアプローチの1つである TracePoint を使って観測する方法に、呼び出し側でその値を使っているかの情報を組み合わせることで void を検出するのは難しいだろうか……
Ruby Commitors vs The World
Ruby コミッタの方たちがコミッタ内外の質問に答えていくセッション。
今年も興味深いトピックが多かったが、とりわけ「yield_selfの別名どうするの？」と「&method(:foo)を短くしたい」はぜひいい方向に向かってほしいなぁ、と。
でもいざ自分でyield_selfのもっといい名前を考えようとすると悩む……
なんとか2日目も書けました。3日目も書けるといいなぁ。
