こんにちは柴田です。RubyKaigi のスポンサーについて書いていたら、CEO からオーストラリアのことを社内に共有してほしい、という依頼が来たのでテックブログに書けば社内にも社外にも伝わって便利だなと思いエイッと書いてしまいました。こういうのは書き始めるまでが一番難易度高いのでちょうどいいきっかけでした。
というわけで、今回は 4/11-12 にオーストラリアのシドニーで開催された RubyConf AU 2024 と私の発表についてご紹介します。
RubyConf AU 登壇の経緯
RubyConf AU は Ruby Australia というオーストラリアの Ruby コミュニティが主催する Ruby のカンファレンスです。Ruby conferencesによると 2014 年に Sydney で開催され、その後は Gold coast でも開催された年もありますが、Melbourne と Sydney で交互に開催されているようです。
私は 2018 年と 2023 年の開催時の CFP に proposal を応募しましたが、どちらも reject という結果に終わっていました。いつかはオーストラリアのカンファレンスでも発表したいと考えていたところに昨年 2023/11 頃に 2024 年の RubyConf AU で登壇しませんか、という招待のメールが届きました。
RubyConf AU での最初の登壇が招待講演になるとは思いもよりませんでしたが、私は
- やりたいことのチャンスが来るまで自己研鑽とアウトプットを継続する
- チャンスが来たら迷わず快諾する
という生き方をこれまで続けて来たので、この招待講演についても快諾して登壇することにしました。
RubyConf AU での発表内容
今回の発表は「Long journey of Ruby standard library」という題名で、Ruby が持つライブラリのロードの仕組みから、外部ライブラリや RubyGems/Bundler の誕生の歴史、2024-25 年にかけての開発計画について紹介しました。発表資料は以下で公開しています。
今回は発表の中から RubyGems と Bundler の仕組みについてポイントだけ紹介します。
実はみなさんが普段使っている Ruby の require は RubyGems によって拡張がなされたものです。オリジナルの Ruby の require はグローバル変数である $LOAD_PATH に含まれるディレクトリから指定したライブラリを検索します。
RubyGems はこのオリジナルの挙動に対して、require に渡された文字列が RubyGems によってインストールされた gem の中に存在するかを調べ、存在する場合はそのライブラリの RubyGems 向けメタデータが記述されている gemspec の内容にしたがって $LOAD_PATH へライブラリのパスを追加します。
さて、この RubyGems の require 拡張には大きな欠点があります。それは RubyGems によってインストールされたライブラリ、gem が多くなれば多くなるほど require が遅くなる、ということです。具体的には、上のスライドにあるように、追加すべきライブラリパスを検索するメソッドでは、インストールされている gem 全てから .find していることがわかります。
ちょっと特殊ではありますが、私の手元では RubyGems でインストールしている gem が 3000 近くあります。そのような環境では単純に bigdecimal を require するだけでも 0.27 sec かかります。これをオリジナルの require で実行すると 0.0007sec で終わるため、300倍以上も遅い事がわかります。
この RubyGems の遅さは Rails などのたくさんのライブラリを require する環境では致命的な問題となります。それを解決しているのが Bundler です。Bundler は依存関係を解決してライブラリをインストールする仕組みもありますが、以下のような仕組みによって、RubyGems によって遅くなったライブラリのロードを高速化しています。
- $LOAD_PATH からオリジナルの Ruby が持っているパス以外全てを削除する
- PubGrub を用いて必要なライブラリのみを抽出する、詳細は Ruby フルタイムコミッタの仕事報告 2023年Q2-3 - ANDPAD Tech Blog を参照してください
- RubyGems によって拡張された require などを全てもとに戻す
- PubGrub によって抽出されたライブラリのパスを
$LOAD_PATHに追加する
上記の処理によって、bundle exec を実行した環境下では Gemfile に記載したライブラリをオリジナルの Ruby の require によって高速に読み込むことが可能となります。
他にも RubyGems や Bundler が、皆さんが快適に Ruby でプログラミングをするために備えている仕組みは多数あります。今後も仕事報告という形で紹介していきたいと思います。
RubyConf AU で気になった発表
さて、カンファレンスの方に戻ると、RubyConf AU はソフトトークと呼ばれるエンジニアのキャリアやチームビルディング、マインドセットにフォーカスした話とテックトーク、Ruby のコードや技術にフォーカスした話の2つがバランスよく選択されたカンファレンスでした。
特に、Melbourneに住んでいる 今年 Ruby コミッタになった KJ Tsanaktsidis が発表した Zendesk における redis-rb と Redis のクラスタモードにおける技術的困難さについてと、Gusto の Ruby Ecosystem チームに所属している Maple によるプロダクトの Ruby や Rails のバージョンアップを行いつつ、発見した課題とその解決を積極的にアップストリーム、すなわち Ruby や Rails 本体の開発の方へ戻すことをやっているという発表は面白かったです。
というのも、上の写真の右の KJ は Ruby コミッタなので、よく会話しますが、Maple の発表で登場したチームメンバーは「RubyGems でよく見かけるこの人たちは、そういう背景があったんだな」と色んな点が繋がったと感じた出来事でした。休憩時間に KJ と、Zendesk で何をやっているのか、と雑談をしたら「Shopify の byroot みたいなことをやっている(プロダクトの進化の障害となるライブラリをひたすら直す)」と話して笑ってしまいましたが、プロダクトを進化させているサービスには、どこにも似たような取り組みをしているチームや人が存在している、ということを見つけられたのも大きな収穫でした。
アンドパッドにも、似たような取り組みをしているチームや人がいるので、Shopify, Zendesk, Gusto のような先輩に追いつけるように頑張りたいと思います。
RubyConf AU は日本からの参加者は数名いたようですが、日本人はおそらく私一人だけだったようです。オーストラリアは移動距離は長いものの、タイムゾーンがほとんど同じでリアルタイムにコミュニケーションができる国です。このエントリを読んで、RubyConf AU への登壇やオーストラリアの Ruby コミュニティに興味を持つきっかけとなれば幸いです。
アンドパッドではプロダクト開発だけでなく、登壇発表や開発を通じて Ruby のエコシステムも発展させたい、欲張りな Rubyist を募集しています。
