[RubyKaigi 2019] 3日目レポート: 公開開発者会議、巨大リポジトリの整理法、Bundler、 超絶技巧最適化術など

セッションまとめ

先日行われたRubyKaigi 2019 ３日目の様子をレポートいたします。

Ruby Committers vs the World

3日目最初は、毎年恒例のRubyコミッターの方々によるセッションです。

Q & A

前半は、質問に答える形で進んでいきます。 「以前より非互換の変更に対して保守的になっているが、保守的になることについてどう思うか」という質問に対し、新機能は追加していると前置きしつつ、後方互換性を保ちつつアグレッシブに変えていけば良いのではないかとの回答でした。なお、会場ではアグレッシブな方が多いこともあり、もっと攻めてほしいという方が多くいました。
また「RubyとC以外で使っている言語は」という質問に対し、Matzは最近プログラミングはしていないが、ElixirやClojureを勉強しているとのことです。 最後に「メンテナいると嬉しいライブラリは」という質問に対しては、放置されているライブラリは使われていないため、メンテナンスは特に必要ないとのこと。一方で、Windows対応は足りておらず、またドキュメントやGVL、date、jsonライブラリなどはいると嬉しいとの回答でした。

公開開発者会議

後半には、公開開発者会議が開催されました。 この日は、まずMat’zからRange#eachなどを呼び出す際にRange オブジェクトを括弧で括る必要があることから、これに代わる新たな文法の提案がありました。Elixirのパイプラインが例に取り上げられ、　話題は右代入の導入に関することまで広がっていきました。 2つ目の議題は、現在活発な議論がされている”Numbered parameters”が取り上げられました。Numbered parametersは@1と表現されていますが、これに代わる記法がないかと様々な意見が交わされました。
公開開発者会議の様子
これらの議論は、議事録に絵文字が多数飛び出し、会場からも時折笑いが起こるなど終始良い雰囲気で進んでいきました。

Cleaning up a huge ruby application

Cookpad社は長年、Ruby on Railsを使われていることで有名ですが、十年以上に渡って育てて来た超巨大リポジトリをいかに整理しているのかという内容のセッションでした。Cookpad社で使われているcookpad_allというリポジトリはコード量が50万行以上あり、その中にはアップデートできない古いgemが使われていたり、monkey patchなどが大量に存在しているという状態でした。そこで”Project Odaiba”が立ち上げられ、それらのコードがコンテナ上で動くようにする、システムを分割する削除するなどの試みが行われました。このセッションのテーマである”コードの整理”についてもこのプロジェクトの一環として実施されました。 そもそもなぜコードを消すのかという点については、コードが理解しやすくなる、ライブラリの依存性が減る、アプリケーション/テストの実行速度が上がる、生産性が上がるなどのメリットがあります。しかしなぜそれが難しいのかというと、コードを削す判断をするのに時間がかかり、優先順位は低くなるという点が挙げられます。 そこで開発されたのが、“KitchenCleaner” です。月に１度、KitchenCleanerは1年間更新された痕跡がないコード、 三ヶ月以上実行されたバッチ、呼び出しがないユニットなどを自動で検出し、GitHubにIssueを立てます。アサインされる人はgit logsからランダムから選出され、アクションとしては削除するかpending alertの期間を設定するかの２択を迫られます。 また別の仕組みとして、“IseqLogger”を用いるものもあります。これは、iSeqというRuby のソースコードをコンパイルして得られる命令の集合を解析して、使われていないRubyコードを検出するという手法でした。このデータをRedShiftに送りレポートすることである程度まで使用していないコードが判別できました。一番のメリットは、低コストにコードの使用状況が分かることですが、Rubyにパッチを当てないといけないというデメリットもあります。 Ruby 2.6には“oneshot coverage”という機能があります。oneshot coverage とは、各行の実行回数ではなく、各行が 1 回でも実行されたかどうかを計測するコードカバレッジです。先述のIseqLoggerの仕組みである程度までコードの使用状況を把握し、その後にこのoneshot coverageを使用することでソースコードを一行ごとのより正確な使用状況を確認することができるようになります。 このような取り組みは、さすがRubyコミッターがいる会社だという感想でした。サービスの問題を解決するためにRubyの内部にまで熟知したエンジニアがいるという強みを非常に感じます。 このようなプロジェクトを経て大幅にコード量を削減することができたそうです。

The future of the Bundled Bundler with RubyGems

RubyそしてRubyGems, Bundlerのコミッターでもある@hsbt氏のセッションです。
この写真は弊社ブースで行ったアンケートの結果です。「最初に入れるgemは？」という質問にbundlerが圧倒的多数となっています。hsbt氏は“first step でbundlerをインストールさせることをやめたい”と言っていました。実際に、ruby 2.6系ではdefaultでbundlerがインストールされるようになっていますね。 現在はrubygems4を開発しており、すでに入っているgemは無視するというconservative optionがデフォルトになる変更が入ります。また、–defaultオプションの挙動が変化したり、–user-installがデフォルトになるという変更がはいるとのことでした。今後のロードマップとしてはRuby2.7にRubyGems 3.1がRuby 3.0にはRubyGems 4.0がデフォルトになります。 ２日目で紹介されてたGelですが、npmとyarnの関係性のようにお互いの良いところを補完しあって行ければいいというような話があったのが印象的でした。

Optimization Techniques Used by the Benchmark Winners

RubyKaigi 2019のラストとなるKeynoteは、ベンチマークで圧倒的な速さ叩き出すRodaやSequelの開発者であるJeremy Evans氏（@jeremyevans0）による、どのような最適化を駆使してこのパフォーマンスを実現したかを発表していました。
参考：RubyのFrameworkのベンチマーク比較
はじめは、不要な処理を削ったりinitialize時に処理を行うことで計算量をへらす方法が紹介されました。また、includeやextendといった処理に時間のかかる処理に代わるSequelのpluginシステムや、文字列をimmutableにすることで割当を減らす、キーワード変数を多用するなど様々な最適化手法が飛び出します。 最適化手法は更に高度化していき、メソッド定義やループの最適化、ルーティング定義を計算量O(n)からO(1)まで削減する手法などが解説されていきます。しかし、このあたりから私はついて行くのもやっとで大変でした。その他の最適化手法は、発表資料やレポジトリをご覧いただければと思います。 各レポジトリをみると、これらの最適化はJeremy氏がほぼ一人で行ったことがわかるかと思います。徹底した最適化に対する熱意には感服するあまりです。みなさんも、ぜひ最適化テクニックを味わって見てください。

次回は松本開催！

クロージングでは、次回のRubyKaigiが2020年4月9日から11日までの3日間、長野県松本市で開催されることが発表されました。 

# 開催期間をrubyで書くと、このように書けます
Date.parse("20100")..Date.parse("20102")
今年らしい発表の仕方
大盛況のうちに幕を閉じたRubyKaigi 2019ですが、Speakerの方々、運営に携われた方々、このような場を創り上げてくださり感謝の思い出いっぱいです。また、弊社ブースに起こしくださった方々も誠にありがとうございました。 次回のRubyKaigi、ぜひ松本でお会いしましょう！！

関連記事