福岡Rubyist会議05 参加レポート

こんにちは！Timeeでバックエンドエンジニアをしている志賀(@akitoshiga)です。

表題の通り「福岡Rubyist会議05 」に参加してきたのでそちらのレポートを書きたいと思います！ regional.rubykaigi.org

今回「Kaigi Pass」という社内制度を利用して参加しました。
「Kaigi Pass」とは、世界中で開催されているあらゆる技術カンファレンスへの参加を支援する制度です。

productpr.timee.co.jp

会場の様子

当日は福岡県福岡市博多区にある「リファレンス駅東ビル」というところで行われました。博多駅

会場いっぱいに来場者が集まりとても賑わっていました。

また、会場には福岡県八女市の名物である八女茶が提供されていました。
自分もいただいたのですがとても美味しかったです。

セッション

特に自分の関心が高かったセッションを3つほど紹介したいと思います。

SQLQL とは何だったのか

発表者 : yancya(@yancya)さん
www.slideshare.net

yancyaさんが取り組まれているSQLQLについての概要と、技術の変遷に伴ったアップデートのお話でした。
SQLQLとはWebクライアントからSQLクエリを送信して、その実行結果をJSONで返すというコンセプトです。
GraphQLのSQL版と考えるとイメージが掴みやすいと思います。
SQLQLに関しては以下で詳しく解説されています。
SQLQL #Rails - Qiita
Client Challenge

なお、ここではRDBMSにPostgresを使用することを前提としています。

SQLQLはクライアントが任意でSQLを送信できるので、これを安全に使えるようにするためにさまざまな工夫が施されていました。
WITH句によるCTEを使って取得対象のDBをラップすることでアクセスできる属性を絞り、秘匿すべきデータへのアクセスを制限しています。
INSERT, UPDATE, DELETEといった副作用を伴う操作に関しては自由に実行できないようにSELECTのみの権限しか実行ユーザーには与えず、定義した書き込み権限のあるストアドプロシージャでしか副作用のある操作を実行できないような仕組みを取られていました。
また、悪意のあるクエリの対策としてpg_queryによってクエリをパースしてAST（抽象構文木）をチェックしていました。
課題も存在していて、再帰処理にはうまく対応できないそうです。
SQL ServerやMySQLは再帰処理の深さを設定できるのですが、Postgresだと存在していないため代わりにタイムアウトのみで設定しているそうです。

クライアントでクエリをフェッチすることが可能になるので、これを用いたときにAPI開発コストの削減に繋がるのは良さそうだなと思いました。
ビジネスロジックがストアドプロシージャに集中してしまわないかなというのと、サーバー側ではクエリを効率化できないのでデータ量が多かったりリレーションの複雑なテーブルからデータを取得する場合はクライアント側で工夫が必要だなと感じました。
SQLをそのままパラメーターにしてWeb経由でクエリを投げるアイデアと、安全性を担保するためのさまざまな試みに技術者のロマンを感じました。
再帰処理に関してはPostgreSQLに存在するCYCLE句を使えば安全に扱えそうなのですが、そうすると特定のRDBMSに依存してしまうのと、クライアントとクエリの決め打ちをしなければならずコンセプトと乖離しそうな気がするので悩みどころだなと感じました。
今回はこのSQLQLのアップデートとしてWAL監視のアイデアを取り込んだデモアプリを披露されていました。
WAL（先行書き込みログ）とはデータベースに変更を行う前に操作内容を記録するログのことであり、このWALを監視することでリアルタイムなデータストリームの観測が可能で、このアイデアをSQLQLに応用されていました。
WAL監視については自分は初見だったのですが、CDC（Change Data Capture）の実装に利用されたりしているそうです。e.g. Debezium Server
このほかにもSQL標準の変遷やLive QueryなどSQLQLを起点としてDB 、データ基盤についての幅広いお話を伺いました。
Live Queryで話に上がっていたKafka Streamsについては内部動作と構造に興味が湧いたので後日その深掘りをしてみました。
また、WAL監視については今後複数コンポーネント間でリアルタイムにデータ更新を検知したいときなどにこのアイデアが役立ちそうだなと思いました。

型を書かないRuby開発への挑戦

発表者 : shia(@riseshia)さん
speakerdeck.com 自作GemのTypeGuessrのお話。
TypeGuessrは「型情報を開発者が追加せずに型情報を得る」ことをコンセプトに開発されたGemで、Ruby LSPのアドオンという形で使用します。 github.com

Rubyに型情報をもたらすツールはいろいろありますが、SteepやSorbetといったような型定義を行い正確な型情報を得るものとは明確に棲み分ける形で開発されています。 Hash/Arrayに対してStructural Typing（構造的部分型）をサポートしつつも複雑な型推論が走りそうな場合はあえてuntypedにして計算量をコントロールしています。特徴として、Duck Typingに基づくヒューリスティックな推論を用いて型情報を取得しており、クラスに定義されたメソッドをそのレシーバーから辿ることによってこれを実現しています。この方法でも行数が10万行以上のRailsプロジェクトであれば平均10%〜20%で型情報を得られるそうです。

Duck Typingを利用して振る舞いから型を推論する部分はRubyらしさを感じるとともにユニークで興味深いなと思いました。
まだできたばかりでパフォーマンスには向上の余地があるそうで、このアプローチでどのようにこれらを解決していくのか動向を追ってみたいなと思いました。

少し話は逸れますが、型検査ツールのパフォーマンス改善という話でふと去年の関西Ruby会議で聞いたpockeさんのこのキーノートを思い出しました。 speakerdeck.com Steepのメモリ削減のために自作のプロファイラで観測してプロセス間通信のレベルまで踏み込んで改善に取り組んだ過程がとても面白かったので、よかったらこちらもチェックしてみてください。

Ecosystem on parse.y

発表 : S.H.さん
S.H.さんが開発されているparse.yを利用したGemであるkanayagoとigata、そしてこれらを組み合わせたエコシステムのお話
parse.yとはRubyの文法定義ファイルのことで、昨今のRubyist界隈を取り巻くパーサームーブメントを語る上で欠かせないものです。
parse.yはRubyコミッターのydahさんの以下のスライドがparse.y周辺の情報やパーサー自体についても丁寧に解説されていて理解しやすいです
たのしいparse.y - Speaker Deck

S.Hさんはこのparse.yを利用して、パースしたAST（抽象構文木）ノードをRubyクラスとして扱うことができるkanayagoを開発されました。
github.com
ASTをRubyオブジェクトにすることで従来よりももっと手軽にASTを扱えるようになり、パターンマッチングにも対応可能になっています。
これによってコード解析・構文チェックなどといったRubyの文法のASTに関する操作がとても直感的・簡単に行えるようになっています。
またS.Hさんはこのkanayagoをベースとしてigataとkanayago-lspを開発されました。

github.com
igataはkanayagoが生成するRubyクラス名、メソッド名、引数の情報などを抽出してMinitestやRSpecに対応したテストファイルを自動作成します。
これに加えてLLMと組み合わせて、テストの中身まで自動補完させる運用も想定されています。
kanayago-lspはkanayagoを用いてVSCodeやVimなどで利用でき、Rubyの新しいパーサーであるPrismでは検知できないものも検知できるそうです。
S.Hさんはこのparse.y、これを利用したkanayagoを利用したエコシステムの構築を目指しており今後はLinterの開発を目指しているそうです。

S.HさんのASTに使われる各ノードを体系立った独自のRubyクラス群にラップするというアイデアがとても素晴らしいなと思いました。
parse.yから生成できるノードは100種類以上あるのでかなり根気がいる作業だと思いましたが、ここは生成AIをうまく活用されたそうです。
Ruby3.4からデフォルトパーサーがparse.yから生成されるパーサーからPrismに置き換わりましたがparse.yの根強い人気というか盛り上がりを感じました。
先ほど紹介したTypeGuessrもそうなのですが、何かを作るにあたりよりRubyらしさを追求するアプローチをみなさんされていて、このマインドはRubyistに通じるものなのかなと感じていました。
これらは開発のお手伝いをしてくれる方を絶賛募集中とのことです。自分もとても興味があるので機会があればパッチを投げたいなと思いました。
そのためにkanayago自体も積極的に使ってみたいと思います。

これらの他にもこの日のセッションはPicoRuby、VM、Deep Researchなど、とてもバラエティに富んでいて非常に面白かったです。

まとめ

福岡Rubyist会議に参加したのは初めてだったのですが、自分は人との距離が近い地域Ruby会議が好きなので今回行くことができて良かったなと思いました。
セッション終了後にも以前からオンラインでお世話になっていたコミュニティの方や、現地コミュニティの方々とも交流できたのも非常に嬉しかったです。
ぜひまた次回も参加したいと思います！