NaClの佐田です。
2024年5月15日(水)～2024年5月17日(金)に開催されたRubyKaigi 2024に参加しました。
弊社からはまつもと、前田、後藤、西田、原、佐田の6名が参加しました。
本記事では、私の参加したセッションに関する感想をまとめました。
RubyKaigi 2024
RubyKaigi 2024は、沖縄の那覇文化芸術劇場なはーとで開催されました。
飛行機で那覇空港に到着すると、RubyKaigi 2024のポスターが貼られていました。
那覇文化芸術劇場なはーとの3つの会場で同じ時間にセッションがおこなわれることもあるため、私が会場で聞いたセッションのみをまとめています。
1日目
会場で受付をおこない、会場の大ホールに向かう途中の通路にRubyKaigi 2024のスポンサーのロゴがありました。
その中にNaClのロゴもありました。
大ホールのスクリーンにもスポンサーのロゴが次々表示されており、その中にNaClのロゴがありました。
以下からは各セッションを見た感想です。
Writing Weird Code
TRICK 2022(Returns)で金賞を獲得された tomoya ishida さんの発表でした。
自己紹介でTRICK 2022(Returns)の金賞作品が紹介されました。
その作品であるQuineが表示する魚・水草・泡でコードの一部が欠落しますが、誤り訂正で復元されるという説明に驚きました。
また、TRICKが前回の開催から間が空いたということで、 Self TRICK 2024と題して作品を6つも作成されたとのことでした。
Most Dangerousというクラゲが泳ぐQuineの作品が紹介されました。そのクラゲを表現するのに、弊社の原がTRICK 2022で使用した点字を使用するアイデアを参考にされたそうです。
キーノートの終了後にLunch Breakがあったので、スポンサーのノベルティとして置かせていただいたスモウルビー甲子園のチラシとNaClのロゴのシールを見に行きました。
The grand strategy of Ruby Parser
Lramaの開発者の Yuichiro Kaneko さんの発表でした。
最初に、Lramaの開発するための参考書や論文について紹介されました。
パーサに関する論文は多いですが、ご自身がまとめられた Ruby Parser開発日誌 (14) - LR parser完全に理解した から読むのがお薦めとのことでした。
ただし、それを読めばRubyのパーサを理解できるわけではなく、パーサの各機能(LR Parser, Ripper, Lex State, Primitive bnf, Semantic analystic)についても詳しくないと難しいとのことでした。
このRubyの文法規則ファイル(parse.y)が、理解しやすいように改善されてきたとのことでした。
それと、CRuby以外のRubyはC言語のパーサをラッパーしたものを呼び出す形になっているので、パーサの言語仕様の生成をおこない、それを使用してCRuby以外のRubyのパーサを生成して使用することを検討中とのことでした。
Long journey of Ruby standard library
標準添付ライブラリに関する Hiroshi SHIBATA さんの発表でした。
標準添付ライブラリに提供されているgemパッケージには「Default Gems 」と「Bundled Gems」があり、それらの読み込みやインストールが改善されたとのことでした。
Standard Gemを確認する2つの方法が紹介されました。
- https://stdgems.org/ を確認
- irbを立ち上げてrequireしてから Gem.loaded_specs[“bigdecimal”].default_gem? メソッドを呼び出す
Ruby 3.3.2から標準添付ライブラリをrequireすると警告が表示されるとのことでした。
それと、今後のRuby 3.4やRuby 3.5ではDefault Gemsの数を減らしていき、Bundled Gemsを増やしていく予定とのことでした。
C拡張のgemパッケージが異なるバージョンの場合にインストールに失敗することがありますが、そうならないように改善に取り組まれていることが紹介されました。
- 参考情報
Namespace, What and Why
Namespaceの開発者の Satoshi Tagomori さんの発表でした。
Namespace.new で名前空間のインスタンスを生成し、その名前空間内で別バージョンのライブラリの読み込みができるようになるとのことでした。
以下の3つの衝突についての使用が考えられるとのことでした。
- 名前の衝突
- 定義の衝突
- バージョンの衝突
名前の衝突は、トップレベルのUserやConfigurationを定義した時に衝突せずに定義できます。
定義の衝突は、機能の動作が変わる設定の値が異なる場合でも衝突せずに読み込めます。
バージョンの衝突は、アプリケーションの異なるバージョンでも衝突せずに読み込めます。
Namespace のC拡張のライブラリを読み込む場合の対応についても紹介されました。
拡張ライブラリのアーキテクチャごとのディレクトリを .so/.dll/.bundle に用意する。
また、Rubyのオープンクラスのメソッドの再定義も名前空間の中に留めてくれるとのことでした。
Exploring Reline: Enhancing Command Line Usability
Relineの開発者の Mari Imaizumi さんの発表でした。
最初に、irbとRelineの関係(IRB -> Reline -> Terminal Emulator)について説明されました。
Reline は、Display Dialog Cursor などを表示する役割もしているとのことでした。
次に、Relineを使用しない場合の違いについてのデモをされていました。
Rubyのgetsメソッドでキー入力待ちにしてから、矢印キーを入力するとアスキーエスケープシーケンスが表示されました。
Reline.readline の場合は、カーソル移動ができました。
また、Relineの現在の状態についても紹介されました。
コマンドライン編集でまだ対応できていない部分があり、Rubyのバージョンアップでreadline-extからrelineに変更されたとのことでした。
それと、irbの設定として ~/.inputrc を紹介されました。
- 参考情報
Ractor Enhancements, 2024
RubyのフルタイムコミッタでRactorの開発者である Koichi Sasada さんの発表でした。
Ractor の機能変更で require と timeout をサポートされたとのことでした。
現在は Child Ractor で require を呼べないようになっているとのことでした。
Ractor.main.interruput_exec { $g= 1 } をChild Ractorで呼ぶことで、Main Ractorの処理に割り込んで処理を実行させることができるようにしたとのことです。
Child Ractorのrequireを変更し、interruput_exec do … end のブロック内でThread.newのrequireの呼び出しを追加されていました。
また、Ractor.main? でMain Ractorでない時に上記のrequireの呼び出しをするように変更されたとのことでした。
Ractor の変更後のGCの性能の比較を図にしたものを紹介されました。
2日目
Leveraging Falcon and Rails for RealTime Interactivity
Falconの開発者である Samuel Williams さんの発表でした。
最初に、Falconを使用したRailsへの変更について紹介されました。
Railsの各リクエストをFiberで処理するように変更されており、ActionCableをFiberに置き換えるのも予定しているとのことでした。
その後、Falconやliveを使用したFlappy birdの作成について紹介されました。
完成したFlappy birdのデモを、まつもとさんが会場から壇上にあがってプレイされたのが面白かったです。
- 参考情報
Community-driven RBS repository
RBSの開発者である Masataka Kuwabara さんの発表でした。
gem_rbs_collection リポジトリについて話されました。
このリポジトリはサードパーティ製のRBSがあるとのことです。
rbs collectionコマンドを使用することで、Gemfile.lock のgemの指定から取得するとのことです。
次に、RBSの変更のPRのレビュー依頼について以下の2つを紹介されました。
- .github/CODEOWNERS ファイルを使用してコードのオーナーにレビューを依頼。
- gem/_reviewers.yaml を変更して誰でもレビュワーになれる。
上記のレビュワーになった場合についてお話しされました。
すべてのissueやPRにコアチームが反応ができないので、レビュワーの活動を手伝って欲しいとのことでした。
ただし、活動が止まってしまったレビュワーは削除するとのことでした。
- 参考情報
RubyGems on ruby.wasm
ruby.wasmの開発者の Yuta Saito さんの発表でした。
ruby.wasm のRubyGemsのサポートについて紹介されました。
gemパッケージのインストールで以下の2つがあるとのことでした。
- On-the-fly installation: インターネット必要
- Pre-installation: インターネット不要。Rubyの起動前にビルドが必要。
今回はPre-installtionのデモとして、Mastodonをブラウザで動作させていました。
その後、C拡張のgemパッケージをどのようにビルドするのかの説明をされていました。
また、RubyGemsのC拡張の共有ライブラリのリンクが静的リンクのみで、現在は別プラットフォームで使いまわすことができません。
そのため、動的リンクのコンポーネントモデルを使用し、ビルドを実施後のバイナリを使用して依存関係を解消する方法について紹介されました。
- 参考情報
Unlock The Universal Parsers: A New PicoRuby Compiler
PicoRubyの開発者の Hitoshi HASUMI さんの発表でした。
RubyのパーサにPrismとLramaがあり、mrubyとPicoRubyはどちらも使用できるように対応するので、今回はそのLramaの対応について紹介されました。
最初にLramaを使用するように変更したところ、メモリ消費量が mrbc_lrama 9.985MB で他のパーサと比較すると多く、メモリ消費量が多い原因の脱GCを対応されたとのことでした。
脱GCのため、ruby_init()を削除するとSEGVするので、脱VALUE, 脱IMEMOをおこない、39.91KBまでメモリ消費量を減らすことができたとのことです。
今回は脱GCをされましたが、まだメモリの改善点があるとのことで、今後の対応に関するお話しがありました。
また、発表の中で前田が作成したmod_rubyが紹介されていました。
- 参考情報
RuboCop: LSP and Prism
RuboCopの開発者の Koichi ITO さんの発表でした。
RuboCopの起動が遅いので、LSP(rubocop --lsp)を使用して改善されたことについて紹介されました。
LSPがどのような時に呼び出されるかは、RuboCop::LSP::Routes でhandleメソッドで指定しています。
開発時にコード変更の度にRuboCopを起動して実行するよりも、LSPを使用したが速いとのことでした。
ただし、LSPを使用すると途中のコードもRuboCopの判定の対象になる問題が発生し、LSPの時はAutoCorrectしないようにしたとのことでした。
また、RuboCopにPrismを導入すると4倍の速度になったとのことですが、PrismとLramaのパーサがあるのでRuboCopがどちらに対応すべきかは決めかねているとのことでした。
Ruby 3.7ぐらいにPrismのLramaのどちらかの方向が決まるのではと予想されていました。
- 参考情報
Good first issues of TypeProf
Rubyのフルタイムコミッタで、TRICKの審査員の Yusuke Endoh さんの発表でした。
最初の自己紹介で、Rubyのエラーメッセージにクラス名を表示するように変更されたとのことでした。
TypeProfの開発の参加方法についてお話しされました。
まずはTypeProfを使用してみてくださいとのことでした。
- TypeProfを動作させる。
- Ruby/RBSをサポートさせる。
- 型推論のコマンドラインツールにまとめる。tool/scenario_runner.rb
この発表でTRICK 2025が開催される旨が発表されました。
- 参考情報
Squeezing Unicode Names into Ruby Regular Expressions
Martin J. Dürst さんの発表でした。
Rubyの正規表現でUnicode character propertyを指定できるようにするお話しでした。
'に' =~ /\p{Hiragana}/
'なにぬねの' =~ /\p{name=HIRAGANA LETTER NI}/
=> invalid character property name {name=HIRAGANA LETTER NI}
Unicode character propertyをRubyで使用するには各言語でのnameに対応する必要があり、そのnameを指定された場合にどのように該当データを探すのかをお話しされていました。
Lightning Talks
Visualize the internal state of ruby processes in Real-Time
Rubyのプログラムの内部状態を可視化するツールの metrics_monitor が紹介されました。
- 参考情報
The Frontend Rubyist
2024年からWeb版が公開された Ruby Koans が紹介されました。
- 参考情報
Enjoy Creative Coding with Ruby
RubyとProcessingを組み合わせたコードのプログラミングについて紹介されました。
- 参考情報
Rearchitect Ripper
Ripperの不具合を改善されたことが紹介されました。
- 参考情報
The Journey of rubocop-daemon into RuboCop
RuboCopに取り込まれたrubocop-daemonについて紹介されました。
- 参考情報
The test code generator using static analysis and LLM
RSpecのテストが未実装のメソッドを検知する構文解析CLIツールのomochiが紹介されました。
Contributing to the Ruby Parser
Rubyのパーサを改善されたことを紹介されました。
- 参考情報
Improved REXML XML parsing performance using StringScanner
RBPDFの改善で、StringScannerを使用してREXMLの速度を改善したことを紹介されました。
- 参考情報
Hotspot on Coverage
ISUCONのRubyアプリをプロファイリングするのに使用されたakainaaが紹介されました。
Drive Your Code: Building an RC Car by Writing Only Ruby
PicoRubyでラジコンカーを操作することについて紹介されました。
- 参考情報
An anthropological view of the Ruby community
Rubyコミュニティについて紹介されました。
- 参考情報
3日目
Ruby Committers and the World
Rubyコミッタが質問に答えてくれるセッションでした。
ただし、Rubyコミッタの中でもどちらにするべきなのか意見は分かれるような質問でした。
frozen_string_literal の今後についての質問がありましたが、Ruby 4.0からデフォルトになるとのことでした。
また、RBSのRubyコードの埋め込みについて、会場の参加者も挙手する場面がありました。
GNU AutotoolsからCMakeに変更するという話がありましたが、CMakeを使用するよりもRuby用の独自ツールにするべきではないかという話がありました。
それと、GVLは外したいか、という話がありました。
ただし、GVLを外すと並列処理が大変になりそうという話をされていました。
How to implement a RubyVM with PHP?
Ruby歴が4ヵ月でPHPのRubyVMを作成された memory さんの発表でした。
VMを作成すればRubyを理解できるということで作成されたとのことでした。
Ruby 3.2 から Ruby 3.3 になった時にYARVの構造が変わっており、The endian sectionとThe word size sectionが増えているとのことでした。
PHPはfread, fseek, unpack がバイナリの読み込みに使用するので、それらを使用して”Hello, World”のYARVのバイナリを操作したとのことです。
YARVのヘッダは各設定が4バイトになっており、PHPで読まれているとのことでした。
RubyVMは ibf_(?:load|dump_write)_small_value の形式で命令シーケンスが書かれているので、compile.c や ibf_xxx の箇所を読むことで理解が進むとのことでした。
OracleがJVMのドキュメントを公開しているので読むことをお薦めされていました。
ただし、RubyVMの命令シーケンスは100個近くあり、JVMは150個もあります。
そのすべてを実装するのは大変なので、最初は”Hello, World”やFizzBuzzなどに関するところから実装を始めることをお薦めされていました。
- 参考情報
Speeding up Instance Variables with Red-Black Trees
RubyとRailsのコアコミッターである Aaron Patterson さんの発表でした。
赤黒木を使用してインスタンス変数へのアクセスを高速化するという話でした。
赤黒木は、Chris Okasaki さんが書かれたのを参考にされたとのことでした。
Rubyの赤黒木を実装時にパターンマッチングを使用すると、コードの読みやすくなると紹介されました。
また、Ruby 3.3のキャッシュから赤黒木が導入されたとのことでした。
そのため、Ruby 3.2 と Ruby 3.3 と Ruby 3.4のキャッシュの比較が紹介されました。
ERB, ancient and future
ERBの開発者である Masatoshi SEKI さんの発表でした。
ERBの過去と未来に関するお話しでした。
最初にERBの開発された経緯がお話しされ、前田が作成したeRubyを参考にされたERBの仕様書が用意されたので作成し始めたとのことでした。
その後、ERb と ERbLight が作成されましたが、 ERbLight が ERB として名前が変更されたとのことでした。
ご自身がERBを使用して作成されたアプリが紹介されました。
そのアプリで使用されたERBの機能で、テンプレートとしてProcを作成し、callメソッドを引数付きで呼び出してHTMLを生成していました。
また、Rails互換のERBの実装について紹介されました。
- 参考情報
Porting mruby/c for the SNES(Super Famicom)
Ryota Egusa さんの発表でした。
スーパーファミコンを動かすのに画像処理システムのPPU(Picture Processing Unit)があり、PPUの描画はBG(Back Ground)とSpriteに分けられており、それらを適切に使い分けることで処理の重さが変わるとのことでした。
そのPPUのエミュレーターであるSNESがあり、以下の2つのコンパイラとリンカーがあるとのことでした。
- PVSneslib: コンパイラやリンカーのSNES I/Oのラッパー
- WDCTools: The Western Design Center, Inc. が配布しているツール群
上記の PVSneslib と mruby/c を使用し、デモ用のFlappy bird風のゲームを作成されていました。
本当は発表で音を鳴らしたかったとのことでしたが、今回は間に合わなかったとのことでした。
この後のAfternoon Breakでアイスが配られていたのでいただきました。
Using Ruby in the browser is wonderful.
ruby.wasm の開発者である Shigeru Nakajima さんの発表でした。
ruby.wasm はCRubyをブラウザで動作させることができ、CRubyとJavaScriptの橋渡しをする糊の役割を果たしています。
その例として、JavaScriptのnew演算子にあたるものがRubyにないので、代わりにJS.evalでJavaScriptのnewを呼び出したり、require_relativeのような動作をするJS::RequireRemoteを提供しているとのことでした。
デモとしてruby.wasmでテトリスを作成されたとのことで、その動いているデモをされていました。
ただし、まだJS::RequireRemoteを使用するにはモンキーパッチが必要ということでした。
また、ruby.wasmでひらがなの書き方を練習する紙を印刷するアプリケーションkakikataを紹介されました。
さらに、kakikataの実装で作成された世界初Ruby用のフロントエンドフレームワークOrbital Ringの紹介もありました。
auto loading、rendering、event bindingの機能を持ったフレームワークがたったの120行程度で書かれていました。
- 参考情報
Matz Keynote
過去のRubyKaigiでは最初にキーノートで発表されていた Yukihiro “Matz” Matsumoto さんの発表でした。
今回は最後の発表となり、いつもとは異なる雰囲気の発表となったとのことでした。
最初にこれまでのRubyの歴史について紹介されました。
その中で、2004年にRailsが誕生し、今年で20周年を迎えることも取り上げられていました。
最初のRubyConfのフロリダでは、RubyGemsが誕生したことも触れられていました。
Rubyは日本の成長しているスタートアップ(参考: Top Ruby Companies)でも採用されています。
YARV, MJIT, YJIT で性能向上してきたことで、Optcarrot で計測した場合にRuby 2.0からRuby 3.0の速度が3倍になりました。
ただし、VMが唯一のボトルネックではありません。
30年前はマルチコアのCPUがないため、Threadを大量に作成してもパフォーマンス改善はしませんでした。
それと、開発者のパフォーマンスも大事。
RuboCop, Profiler などの開発支援するソフトウェアについても触れられていました。
そのPrismの開発者のパフォーマンスのため、2024年のRubyの変更では文法を変更しない(Syntax Moratorium)と宣言されていました。
以前、Rubyを新しく作成し直したらどうなるかと検討されたRuby 2の機能も、最新のRubyには次々実現されているとのことでした。
NameSpace の機能が取り込まれ、Ruby 2の残りの機能も実現されたらRuby 4.0を名乗ってもよいのではとおっしゃられていました。
また、今後の性能向上は、Rubyの実行時の性能向上がまだできるとのことで改善するとのことでした。
まとめ
RubyKaigi 2024は1300名が参加されたとのことでした。
どのセッションも大変素晴らしかったです。
帰りにスポンサーのロゴのところを見ると前田と後藤がサインしていました。
スポンサーのノベルティは、NaClのロゴのシールは1日目の夕方にはなくなっていました。
もっと枚数を持ってくればよかったです。
RubyKaigi 2025は松山市であるとのことで大変楽しみです。
