RubyKaigi 2023 に現地参加しました
はじめに
5/11(木)～5/13(土)に、長野県松本市のまつもと市民芸術館にてRubyKaigi 2023が開催されました。
弊社からは4名のエンジニアが現地で参加しました。
この記事では、RubyKaigi 2023に参加したエンジニアの中で印象に残ったセッションをピックアップして紹介します。
印象に残ったセッション
The Resurrection of the Fast Parallel Test Runner
弊社ではRailsで作っているシステムはRSpecでテストコードを書いています。そのため、「ある箇所で破壊的な修正をしても、他のところでテストが落ちて気づいて救われる」と、テストコードの効果を実感しています。
テストコードのリファクタリングも随時行っているものの、基本的にはテストコードはプロダクトの成長とともに増え続けています。
その結果、最近、CIでのテスト実行時間が増えてきていることに対して課題感が出てきました。
そんな中、このセッションの説明に
I will share some lesser-known parallel testing insights I've gained in reviving the test-queue. And explore possibilities of parallel programming in Ruby.
とあったため、並列テストに関して何か得られそうだと思い参加しました。
セッションで印象に残ったのは、 parallel_tests と test-queue の仕組みの違いでした。
parallel_tests は事前にテストを分割してから各workerで並列実行するため、テスト全体のスループットは一番遅いworkerに引っ張られるとのことでした。
一方、 test-queue は空いているキューにテストを入れていくため、parallel_tests の問題点を解決しているとのことでした。
ただ、test-queue はテストフレームワーク特有の箇所があるため、もしRSpecが実装を変えたら動作しなくなるという説明もありました。
とはいえ、RSpec3のサポートに加え、以下のプルリクにある通りRSpec4.0(dev)もサポートしていることから、社内のコードを使って test-queue を試してみるのも良さそうと感じました。 https://github.com/tmm1/test-queue/pull/112
他には、セッションの冒頭にて
10分以内のビルドなど、テストの実行時間を短くするのは大切
RSpecで遅いテストを見つける方法
Database Cleanerのチューニング
についてもお話があり、このあたりの観点でもテストを見直していこうと感じました。
Revisiting TypeProf - IDE support as a primary feature
TypeProf の v2 を作っているというお話でした。
v1 はとにかく動作するものを実装する、速度は二の次という前提にしていた
実際に使ってみると本当に欲しかったものは「Rubyの型よりもIDEサポート」ということに気づいた
IDEサポートを強化するには解析速度は重要な要素
解析対象のコードは完全なコードではない（書きかけのコード）
v2 は解析結果を差分更新して速度を出している
対象としているエディタはVS Codeのようですが、Vimでも動きそうな情報を見かけたので試してみようと思います。
Implementing "++" operator, stepping into parse.y
個人的 one of the best talks on RubyKaigi 2023 です。
実際に"++"を実装する試みが小さなステップで非常にわかりやすく解説されていました。現状の parse.y が i++ というコードをどのように扱っているのかから始まり、具体的に試してみる→できた→まだ問題が…という流れが parse.y 初心者にとってとっつきやすく、自分も parse.y の中身を見てみたいという気持ちが出てきました。
最後の「"++"があるこの言語は Ruby じゃない Ruby++ だ！」というオチに至るまでのストーリーも面白かったです。
Make Regexp#match much faster
なぜ ReDoS が起きてしまうのか、Ruby の正規表現エンジンである Onigmo の特性や、バックトラックにより分岐が指数関数的に増えて行くことをわかりやすく解説していただき非常に勉強になりました。
また、高速化の手法としてメモ化を導入し計算量が線形時間になることや、 Regexp.linear_time? メソッドで正規表現が線形時間になることのチェックが可能であることも知ることができました。
今後の展望として Regexp.linear_time? が false となるような正規表現の場合に警告を出す RuboCop をスピーカー自身で開発するとのことで、弊社でもリリースされたらすぐに導入したいと考えています。
Multiverse Ruby
匿名モジュールを用いて名前空間の衝突を避けようという話でした。
匿名モジュールの名前空間の挙動はこのセッションを聞くまで知らなかったので興味深く聞くことができました。
また、オートロードを匿名の名前空間上で行うために Zeitwerk をフォークして Im という gem を作成した話もありました。リリースインフォに載らないような Ruby の改善をどのように用いて課題を解決したのか、という一連の流れが特に面白かったです。
Public な gem を開発することがなかなかないのでセッションの内容をすぐに活用することは難しいと思いますが、自分も細かいものも含めて Ruby の改善をキャッチアップしてみたいと思わせてくれるようなセッションでした。
おわりに
弊社のエンジニアたちは東北から関西まで様々な地域で暮らしているため、基本的にフルリモートで勤務しています。
日頃はSlackやGatherなどによるオンラインコミュニケーションを取っている一方、オフラインで直接会話する機会がなかなかありません。
そのため、今回のRubyKaigi 2023は、弊社のエンジニアたちが集まってランチを一緒に食べたり直接会話する良い機会となり、とても楽しく過ごせました。
最後になりましたが、RubyKaigi 2023を運営してくださったみなさま、本当にありがとうございました。
これからは来年沖縄で開催される RubyKaigi 2024を楽しみにして過ごしていきます。
本サイトの更新情報は、Twitterの株式会社プレセナ・ストラテジック・パートナーズエンジニア公式で発信しています。ご確認ください。
最終更新