サーバーサイドエンジニアの内藤(@naitoh) です。
RubyKaigi 2024に参加されていた皆さん、お疲れ様でした。 RubyKaigi のセッションの中で印象に残った発表をご紹介します。
タイムテーブル
タイムテーブルは以下から確認できます。
Namespace, What and Why
今回のRubyKaigi で非常に気になっていたセッションの一つです。
- アプリケーション、ライブラリをある空間の中でライブラリを読み込み、他の空間から隠す。
- 空間の中で定義されたメソッドを別空間から呼び出すこと
- 別空間から呼び出されたメソッドは、元の空間内で動作すること
という感じで複数のバージョンのライブラリに依存した場合のコンフリクト発生を解決するのが Namespace とのことで、内容が整理されておりわかりやすかったです。
Namespace "on read"ということで、 既存の gem をそのまま使いたいが特徴で、"on write"だと、Namespace を使うときに宣言して使うアプローチ(例: 別言語, python)になり、これだと既存の gem の対応が必要になるので、なるほどと思いました。
Namespace があると 1つの Ruby プロセス上で、複数のアプリケーションサーバーを動かすことが可能になり、コンテナレスで開発環境を構築するのが容易になりそうとのことで、柔軟性高いなーと感じました。
The FAQ about "Namespace on read"
— tagomoris (@tagomoris) 2024年5月20日
Namespace on readについて #rubykaigi中によくもらった質問などをまとめたFAQを作りました
---
"Namespace on read" for Ruby, FAQ https://t.co/pVKDeCTJxw
It's about time to pack Ruby and Ruby scripts in one binary
実行ファイル一つで実行できるOne Binary 形式の話です。 Ruby の One Binary 用途として、Rubyプログラムを配布したいときが想定されており、 通常の Ruby スクリプトをそのまま配布した場合、配布先のユーザーの Ruby 環境が古いなど、期待しないバージョンの環境の場合だと動作しない問題を解決できるとの事。 既存の one binary ツールには下記の課題があるため、kompo gemを作ったとの事です。
- Ruby 3.0 未満のサポート
- Ruby にパッチが必要
- Windows のみサポート
- 一時ファイル書き込みがある
クロスコンパイル未対応の課題はありますが、native(C拡張 gem?) にも対応してるそうなので、使い勝手が良さそうですね。
Ruby Committers and the World
毎年楽しみにしている、Ruby Committers and the World です。
今年は下記の内容が議論されていました。
#frozen_string_literal: trueをデフォルトにする話- ""をバッファに使うケースは多いので、+""にすれば良いのはわかるが手間が増える。
- Quine で 1文字増えるのは、それだけで厳しい。
- YJIT には効果ありそう
- Ractor は Frozen したい
- 型は他言語の静的方向の流れとは逆張りしたのに、
#frozen_string_literal: trueは他言語と同じimmutableの方向。
というような議論になっていました。 Ruby 3.4.0 preview1 はデフォルト有効になっているけど、引き続き議論中という流れでした。 個人的には性能UPに繋がりそうなのでデフォルト有効は賛成ですが、3.4 での変更ではなく 4.0 でのメジャーアップデート時の変更だとわかりやすくていいなと思いました。
- Embed RBS
YARDにも型があるぞということで、整合性をとるために YARD → RBS 変換できるといいねという話がありました。
個人的には別ファイルだと型は書かないだろうなという感じですが、メソッドのすぐ上に書けるなら型を書くのもありかなという感じです。
- GNU autotools を cmake に変更したい
- (Python のように)GVL を取りたい
async/awaitの usability の話async/awaitをいっぱい書くのは、書きにくいのでは- 最初から、対象のメソッドに
async/awaitが必要ってわかっていて書けているのか？ - 後から、必要になって
async/awaitを書くのは bad 体験
- Golang の defer が欲しい話
- ネストを深くなるのを回避できる
- いい文法があれば
- ensure は最後に書くことになるのが問題 (リソースを使用した直後に書きたい)
などの議論がありました。 Ruby開発者の温度感がわかって楽しかったです。
YJIT Makes Rails 1.7x Faster
YJIT みなさん使ってますか？
YJIT Makes Rails 1.7x faster / RubyKaigi 2024 - Speaker Deckで 紹介されたように MedPeer でも YJIT を有効にして速くなっています。感謝！
講演では Ruby 3.3 で高速化された YJIT の高速化された手法の紹介がありました。
- Method Call Fallback の仕組みでJIT できない場合、Ruby インタプリタに処理を戻していたケースのいくつかで、JIT 可能になり高速化。
- スタック変数をメモリ上で処理していたのをレジスタ上で処理するようになった。
- Active Support の
NilClass#blank?がインライン化され 1命令になるのは圧巻でした。
という感じで、素晴らしい改善ですね。 Ruby 3.4 でも改善が進んでいるみたいなので超期待です。
Speeding up Instance Variables with Red-Black Trees
毎回、わかりやすく説明頂ける @tenderloveさんの講演です。
ObjectShape キャッシュミス時の検索に 赤黒木を使うことで、計算量を O(n)から O(log(n))に減らしたという内容でした。
ObjectShape の各オブジェクトもツリー構造に配置されるので、赤黒木のアルゴリズムが使えるんですね。 該当の PR は https://github.com/ruby/ruby/pull/8744になると思います。
ただ、私は 赤黒ツリーを理解していなかったため内容にあまりついていけず、非常に残念な思いをしました。 観たいセッションの講演概要に知らないキーワードがある場合は、事前勉強が重要ですね！
コンピュータサイエンスの知識があると、最適なアルゴリズムを選択できるため知識は重要です。動画や資料が公開されたら再度確認したいです。
Lightning Talks
手前味噌ですが、LTで発表させて頂きました。 詳細は、下記を参照頂ければと思いますが、LT発表すると他の方のLT内容を聞けないのが残念ですよね。 こちらも動画が公開されたら確認したいです。
はてなブログに投稿しました#RubyKaigi 2024 LTで「Improved REXML XML parsing performance using StringScanner 」というタイトルで発表しました。 - @naitohの日記 https://t.co/Y8qSUgtPkX#はてなブログ
— NAITOH Jun (@naitoh) 2024年5月20日
おわりに
3日間に渡るRubyKaigi 2024が終了しました。 非常に魅力的な公演が目白押しでしたが、3トラックなので観れるセッションが限られていたのが辛いところです。
次回のRubyKaigiは 2025年4月16日から4月18日、場所は愛媛県松山市です。
今年もAfter RubyKaigi を開催します！
昨年に続き今年もZOZOさん、FindyさんといっしょにAfter RubyKaigiを開催します！！！
- イベントタイトル: 『After RubyKaigi 2024〜メドピア、ZOZO、Findy〜』
- 開催日時: 2024/05/28(火) 19:00 〜 21:30
- 会場: ファインディ株式会社
- 東京都品川区大崎1-2-2（アートヴィレッジ大崎セントラルタワー 5階）
- ※ オンライン参加枠有り
メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております！
■募集ポジションはこちら medpeer.co.jp
■エンジニア紹介ページはこちら engineer.medpeer.co.jp
■メドピア公式YouTube www.youtube.com
■メドピア公式note
style.medpeer.co.jp