RubyKaigi 2023 セッションレポート Day3 - メドピア開発者ブログ

こんにちは！サーバーサイドエンジニアの伊藤(@yuma_ito_bd)です。

RubyKaigi 2023に参加されていた皆さん、お疲れ様でした。 3日目（5/13）のセッションの中で印象に残った発表をご紹介します。（現地参加したエンジニアの複数人による共同執筆になります。)

Day 1のレポートはこちら tech.medpeer.co.jp

Day 2のレポートはこちら tech.medpeer.co.jp

タイムテーブル

タイムテーブルは以下から確認できます。

rubykaigi.org

Ruby Committers and The World

（執筆：伊藤）

YJITやパーサ、GC、Ractorなどの各トピックに対してRuby 3.3で実装したい機能に関してコミッター同士の公開トークがありました。 Ruby 3.3だけでなく、その次のバージョンに向けた将来的な話もあり、興味深かったです。 5/12（RubyKaigiの2日目）にRuby 3.3.0-preview1がリリースされたようなので、自分でも触ってみようと思います！

www.ruby-lang.org

セッションの最後にはコミッターの方々の写真撮影タイム 📸

The Adventure of RedAmber - A data frame library in Ruby

（執筆：貞元）

Rubyでデータフレームを取り扱うRedAmberについてのお話しでした。 RedAmberはApache Arrow の Ruby 実装である Red Arrowと連携し、Rubyらしいインターフェース用意し、Rubyistsにとって扱いやすいデータフレームとなっています。

https://github.com/red-data-tools/red_amber https://arrow.apache.org/

RedAmberの以下のような機能の紹介があり、メソッド名など使用しやすく感じました。

Aggregation: vec.sum
Element-wide: vec.cumsum
Binary Element-wide: vec > 3
pick, drop（列選択, 列削除）
slice remove（行選択, 行削除）

また、RubyKaigiが行われた都市のデータを用意し、都市と緯度経度を結合した内容をプロットした例もあり、より実践的な例でイメージしやすい内容でした。

Ruby向けのデータフレームはまだ触ったことがなかったので、これを機会にRedAmberを使用してみたいと思います。

Let's write RBS!

（執筆：千葉）

speakerdeck.com

このセッションでは、RBS 3.1で導入された新機能と既存アプリケーションにRBSを導入する方法について紹介されました。

紹介されたRBS 3.1の新機能は以下の2つです。

rbs subtract: 複数ファイルでRBS定義が重複している場合に片方を削除してくれる機能
rbs parse: RBSファイルをパースし、Syntax Errorを教えてくれる機能

これらの機能は、既存アプリケーションにRBSを導入する際に詰まりがちな部分を補ってくれるため、今後RBSを導入する予定がある方にとっては非常に重宝する機能になります。

また、既存アプリケーションにRBSを導入する方法については以下の手順でデモンストレーションが行われました。

rbs collectionの導入
steepの導入
rbs subtractの導入
RBSの記述方法

デモンストレーション形式で実際にコーディングを行いながら型についての解説が行われたため、これまでRBSに馴染みがなかった人でも理解しやすいセッションでした。

今回のセッションを通じて、RBS導入への敷居がまた一段と低くなったと感じたため、今後さらに多くのプロダクトでRBSが導入されることが期待できると思いました。

Load gem from browser

（執筆：熊木）

ruby.wasmでサードパーティ製のgemを動かしたいというお話しでした。 ruby.wasmとはRubyスクリプトをブラウザ上で実行できるようにする技術です。

サンプル github.com

現状の課題として、ruby.wasmでは標準gemは使用可能ですが、サードパーティ製のgemが使用できない点が挙げられていました。

その理由は、ruby.wasmのファイルシステムが読み取り専用であり、あらかじめ用意されたgemしか読みこめないためです。この問題への対応策を考えるに当たり、JavaScriptの歴史が参考になったそうです。その結果、以下の2つのアプローチが提案されました。

実行前にバンドリングして一つのファイルにまとめる
import-mapsのように実行時にgemを読み込む

しかし、スクリプト言語の特性を維持したいなどという考えから、後者の方法が採用されることになったようです。

後半では、現在の実装内容や困難な点が紹介されました。

まずrequire_relativeを使ってgemを呼び出す様子がデモで示されました。

現在、Rubyのファイルから別のファイルを呼び出すことは可能ですが、再帰的な読み込みはまだできないことが示されました。また、ブラウザでファイルをダウンロードする際に使用するFetch APIから返却されるPromiseがRubyではないため、これを適切に扱うのに苦労したとのことでした。

将来的な展望として、ブラウザ向けのプログラミングをRubyでJavaScriptと同等の簡便さで行えるようにしたいと述べられました。具体的には、UNpkgのような仕組みでgemを実行可能にし、デプロイを容易にし、初心者でも簡単にアプリケーションを公開できる環境を作りたいとのことでした。

発表の中で、何度も「Rubyプログラミングをより楽しくしたい」とおっしゃられていたのが印象的で、 Rubyが楽しく書ける言語として評価されるのは、こういった開発者の方々の努力のおかげだと、強く感じる発表でした！

Ruby + ADBC - A single API between Ruby and DBs

（執筆：内藤）

slide.rabbit-shocker.org

Red Data Tools (Ruby でデータ処理ツールを提供するプロジェクト)で開発されている ADBC(Apache Arrow Database Connectivity) API を用い大量( 1カラム100万レコード以上)のデータ読み書きを Ruby で実施する話です。

データ交換処理では、通常、シリアライズ・デシリアライズに伴うデータ変換が行われます。この変換処理時間は少量のデータでは無視できるのですが、大量のデータの場合には無視できない時間になります。

ADBCを用いることで、下記の三つの点から大量データを扱うのに最適化しているとのことでした。

Apache Arrow データFormat を使う：データ交換コストがめっちゃ安い
結果セットの分割：並列で分割して読み込みを行っているので、高速なデータ読み込みが可能
バルクインサート：高速なデータ書き込みを実施

なお、Apache Arrow データFormat を使うとなぜ良いのかは、下記の資料を読んで下さいとのことでした。

slide.rabbit-shocker.org

アーキテクチャ

Apache Arrow データ形式を返す形で、各種DBにアクセスするための Single(単一形式) API を定義しているため、(Active Record のように)DBを変更してもクライアント側のコードを変更は不要です。

ただし、このAPIはそのままでは Active Recordから使えないので、 Active Record ADBC adapter を開発中(ただ、普段 Active Record を使っていないので、協力してくれるメンバーを募集中)とのことです。

利用可能な Driver は下記になり、MySQLの Driver は存在しないようです。

現状、1000万レコードの処理で libpq と比較して ADBC(libpq Driver)は変換のオーバーヘッドがあり、まだ最適化されていないので遅く、ADBC(Flight SQL Driver) はArrow フォーマットを使った高速RPC通信ができているので、2倍速い結果となっています。

Flight SQL(Apache Arrow Flight) は下記の特徴を持っており、Arrowフォーマットのまま(=シリアライズ・デシリアライズに伴うオーバーヘッドが無い)並列転送をしているのがポイントのようです。

今回、 PostgreSQL で Flight SQL を話せるようにPostgreSQLの拡張機能を用いたアダプタも作ったそうです。

前述のセッションレポートで述べた RedAmber が ADBC で処理できるようなるとDBに大量データが格納されている場合でも、全てApache Arrow データFormat で処理できる事になるのでオーバーヘッドが無く、高速に処理できそうですね。

Ruby でのデータ処理に興味を持った方は、ぜひ Red Data Tools に参加しましょう！

Parsing RBS

（執筆：伊藤）

rubykaigi.org

3日目のkeynote講演です。 RBSの型定義ファイルで文法エラーが発生していても抽象構文木（Abstract Syntax Tree、以下ASTとする）を取得できるようにパーサを改善したお話でした。

正しいRBSのコードの場合、パーサによってコードに対応するASTを得ることができます。

文法エラー時にツリーを返すように変更

既存のパーサでは文法エラー時は例外が吐かれるように設計されており、抽象構文木を得ることができない仕様でした。そこで、文法エラー時はMissingTreeというツリーを返却するように変更しました。

これによって、文法エラーが発生していてもASTを得ることができるようになりました。

最後にパースが成功した結果を利用して正しいASTを得る

文法エラーが発生している場合、コーダーの意図とは異なるASTを取得してしまうパターンがありました。

例えば以下のようなConferenceクラスを定義したRBSのコードがあるとします。

class Conference
  def initialize: (String, Integer) -> void
end

そして、以下のようにTalkクラスの定義を（途中まで）追加します。

class Conference
  class Talk

  def initialize: (String, Integer) -> void
end

class Talkに対応するendがないので文法エラーとなっています。

ここでinitializeメソッドはもともとConferenceクラスのメソッドだったのですが、Talkクラスのメソッドとして解析されてしまっていました。

以下のようなイメージです。

- class Conference
  - class Talk
    - def initialize

そこで、最後にパースが成功したASTの結果を用いて、変更があったトークンによるツリーを挿入することで正しくASTを取得できるようにしました。

先程の例では最後にパースが成功したASTは

- class Conference
  - def initialize

なので、そこからclass Talkというトークンが追加されると

- class Conference
  - class Talk
  - def initialize

のようなASTを取得することができます。このようなアプローチをすることで文法エラーが発生していてもコーダーの意図に近いASTを取得でき、文法エラーであることを適切に表示することができるようになりました。

私は今回のRubyKaigiでパーサに関するセッションをいくつか聞いたのですが、どのセッションでも文法エラー時のエラートレランスについて言及しており、パーサ共通の課題であり難しい部分であることを認識しました。パーサが改善されることによって、IDEで適切にエラー表示されて開発者体験が向上するので、今後もパーサについて着目してみようと思いました。