はいさい！ 沖縄が恋しいエンジニアの小山です。
今回 Gold Sponsor として RubyKaigi 2024 に協賛させていただき、多くのメンバーと参加してきました。本記事はそのレポートです。
RubyKaigiとアカツキゲームス
RubyKaigi は、プログラミング言語 Ruby に関する国際会議です。
私たちは2013年からほぼ毎年協賛をさせていただいており、今年で12回目のスポンサーとなります。
去年の様子:
当日の様子
印象に残った発表
参加したメンバーより、印象に残ったセッションの感想を参加レポートとして紹介します。
Unlocking Potential of Property Based Testing with Ractor / @ohbarye
@shivashin495 です。まず、簡単にこのセッションの振り返りをします。
Ractorを知っている人は会場でも多く、9割くらいはいました。しかし、Ractorを趣味もしくは仕事で使ったことがある人となると急に3割くらいに減ってしまいます。では、なぜ使ったことがある人が少ないかというとユースケースが少ないからだと発表者は述べています。その上で、Property Based Testingこそが良いユースケースであると仮定し、その検証をしたという発表になります。
私のいるゲームプロジェクトではExample Based Testingが書かれています。これは、あるテストを書くときに任意のExample(具体的な振る舞い例)を用意してその中で正しい振る舞いをするか確認するテストです。ゲームは入力や状態が多岐にわたるため、複雑なケースでの検証やテストが用意されてます。しかし、どれほどテストを用意してもエッジケースや意図しないデグレによってバグが発見されることがしばしばあります。そこで今回のProperty Based Testingに注目しています。具体的なExampleではなくランダムな値を使うことで、潜在的なバグを発見できる可能性もあるためです。
ゲームアプリケーション以外にも、スクリプトやインフラのテストなどで使えると面白そうです。アイデアが広がる素晴らしいセッションでした。
RubyGems on ruby.wasm / @kateinoigakukun
こんにちは、竹下です。私からは、かねてより関心のあったWASMに関するセッションがとても印象に残っているので、そちらを紹介させて頂きます。
WASMでRubyランタイムを実現し、ブラウザ上でRubyのプログラムを実行することができるruby.wasmの機能追加に関するセッションでした。
ruby.wasmではGemを使用することができますが、従来はRubyのみのGemにしか対応しておらず、C拡張を含むGemは使えませんでした。そこで、事前にパッケージをインストールする手法を選択し、Cを含むパッケージも利用できるようになったとのことでした。
今後の展望として、ruby.wasmを通常のプラットフォームの一つとすることができることを目標としているとのことで、ハンディな実行環境として有用なものになりそうだと感じました。実際、セッション内で行われたデモでは、Mastodonのサーバーをブラウザ内で起動し、ブラウザからアクセスするといった、圧巻の実演をして頂きました。Webサーバを含めて実現したいことのすべてがブラウザ内で実現する世界観が近づいてきているのだなということが感じられる内容だったと思います。
ゲームのサーバーサイドを開発するうえで、今回紹介されたデモのようにブラウザ内でハンディに動かそうということは難しいかもしれません。しかし、ゲームを開発するうえで必要なものはサーバーとクラアントだけでなく、検証ツールや諸々の管理ツールなど様々にあり、今後のツール開発の形を変える技術になるのではないかと思います。
Leveraging Falcon and Rails for Real-Time Interactivity / @ioquatix
@nkpoidです。Railsを使ってリアルタイム性の高いインタラクティブなWeb体験を構築する方法に焦点を当てたセッションについてご紹介します。
発表者の@ioquatixさんが開発したFalconというGemは、Async Gemを基盤としたイベント駆動型アーキテクチャをRailsに導入するRack Middlewareです。デモでは、このFalconとRailsを用いて、インタラクティブな操作が必要なWebゲーム「Flappy Bird」を実装していました。Pumaの代わりにFalconをbundle installするだけで導入でき、実際にサーバサイドロジックで動くFlappy Birdを見ることができました。
テクノロジーの進化とともに、ソフトウェア開発の複雑さも増しています。しかし、RubyやRailsはその複雑さをうまく隠蔽し、「書くのが楽しい」言語であることが魅力です。今回紹介されたFalconを使うことで、インタラクティブなコードも楽しみながら学ぶことができると実感しました。ただし、パフォーマンスの観点で言えば、サーバサイドでのロジックの限界もあるため、学習用途として利用するのが現実的かもしれません。
ちなみに、私のプロジェクトでもFalconを導入しようとしてみましたが、私たちの環境ではそのままでは動作しませんでした。とはいえ、Falconの導入によるパフォーマンス改善は魅力的なので、ベンチマークを取るところまでは検証を続けたいと思います。
Embedding it(RBS Type Declaration) into Ruby code / @soutaro
こんにちは @fumihumi です
RBS commiterの soutaroさん のセッションでは既存のRBS定義への課題から、soutro/rbs-inline の紹介がありました。またday3のRuby Committers and the World では Matz から”rbs-inlineのようなコメントで形定義を書くスタイルについては黙認する”というコメントもありましたね。(うろ覚えなため表現が正確ではないかもしれません。)
私のいるプロダクトでは、RBSの導入を部分的に進めており、 基本的に自動生成を用いる + 一部のみ手書きによる型定義を実施するが、チームとしてRBS定義を書くということは必須ではない、というような導入状況です。
セッション中に触れていた、型定義が別ファイルにあると更新しづらく、いわゆる手書きの型定義ファイルは適切に更新されない、されにくいという問題は事実あり、これは導入時に型定義を必ずかくという強制をせずにあくまでも書きたい(欲しい)メンバーが書くというスタイルをとったため一定仕方がないとも思っています。
そんな中でrbs-inlineによって今まで yard 相当で記載していたDocを型定義として扱えるようになる、というのは個人的にとても嬉しいものでした。
yard 自体は一定数のメンバーが書いているため、これらのメンバーに rbs-inlineのsyntaxを受け入れてさえもらえれば自然と型定義が潤っていくということになります。今までの開発フローに近い形で、型定義が潤うのは嬉しいですね。
day3では会場投票によって型定義のシンタックスについての投票があったり、セッション中でもシンタックスについては検討段階、というような形で触れていたため、まだ変わることがあるとは思いますが、さっそくプロダクトにて試してみたいと思いました。
YJIT Makes Rails 1.7x faster / @k0kubun
@shivashin495 です。こちらはYJITに導入されている最適化に関する発表です。
day2にもBreaking the Ruby Performance Barrier / @maximecbの発表がありました。このセッションでは、YJITはRubyのバージョンを重ねるごとに高速化しており、C拡張への依存を減らして純粋なRubyで実装されたものを使用し、JIT化可能な割合を増やすことで更なる速度アップをしているという内容でした。
day3のこのセッションでは、より詳しくYJITに導入された高速化に関するテクニックの内容で、valueをstackではなくregisterを使えるようにすることで処理が高速になったなどの紹介がありました。
弊社でもRailsを使用しており、こうした高速化にワクワクしています。以前Ruby v3.1.0でYJIT有効化を試したことがありますが、当時の検証ではパフォーマンスへの改善を大きくみることができませんでした。(ref: https://hackerslab.aktsk.jp/2022/09/26/183545 )
つい最近 ruby3.3.1 へのアップデートを実施しており、セッションで聞いたような改善の恩恵を受けられるため、今回の発表の内容でどういった結果が出るのか非常に楽しみです。パフォーマンスの比較などを発表できるようにYJITの導入に挑戦してみたいと思います。
Using “modern” Ruby to build a better, faster Homebrew / @MikeMcQuaid
村上です。私からは、Macを使っているエンジニアの多くが利用していると言っても過言ではない、Homebrewのセッションについてご紹介します（そう、HomebrewもRuby製なのです）。
発表では、まずHomebrewが利用してきたRubyバージョンの変遷の確認から始まりました。リリースからつい最近まではOSに同梱されたRuby（”System Ruby”と呼ばれることが多いようです）を使っていたようなのですが、OSの更新や年月が経過してもなかなか新しくならず、2023年になってもRuby 2.6で動作していたとのことでした。Ruby 2.6は2018年に初版リリースされたものになるので、相当古いランタイムを使い続けていたわけですね。
そんな状況に痺れを切らしてか、2023年にHomebrewは独自ビルドのRuby（Portable Ruby）に切り替えを果たします。切り替え当初はRuby 3.1でしたが、ちょうどRubyKaigiの期間中にRuby 3.3に対応したとのことでした 🎉
コマンドの出力を見ると、確かにRubyが更新されています。自分たちの都合に合わせてランタイムのバージョンを制御できるようになった点は、メンテナンスの面でかなり良いことなのではないでしょうか。
また、HomebrewとRubyエコシステムの関係も説明がありました。Homebrewのパッケージ定義はFormulaと呼ばれるRubyのDSLで記述されているのですが、その記法チェックやテストにRuboCopやSorbet, RSpecを利用しているそうです。これらによりPRレビューを一定自動化できているとのことで、広く認知されているツール群が活用されていることが分かりました。
発表中はHomebrew FormulaのDSLにも少し触れられていたのですが、設定ファイルと似た形で簡単かつ綺麗に記述ができる点から、Rubyとの相性の良さが伺えます。
これを見ると、アプリケーション組み込みのスクリプトでもmrubyを用いればもっと綺麗なDSLで書けるかもしれないと希望を感じました。その分野で有名な Lua(JIT) の組み込みやすさとパフォーマンスの高さはもちろん魅力的なのですが、Ruby特有の「書きやすさ」は開発効率・メンテナンス性の面でこそ輝きます。ユースケース次第とはいえ、プロダクトで使えるかを積極的に検討してみても良いのかもしれませんね。
まとめ
今回は沖縄での開催ということで、講演の挨拶も「はいさい！」と明るい雰囲気でした。海外の方も観光を含め非常に楽しんでいる様子でした。開催地を楽しめるのもRubyKaigiの素敵なところですね！
また、RubyKaigiの1週間ほど前に、弊社が公開しているOctoballというOSSにPRを送っていただいた方とOfficialPartyで偶然お会いしました。こんな出会いがあるのもRubyKaigiのいいところです！
来年度は松山で開催されるとのことで、今から非常に楽しみです！！
