RIZAPのエンジニアが、今年もRubyKaigi に参加してきました！（2024・那覇）【各講演のレポート集】

2024年6月18日 13:25

世界中からRubyを扱う「Rubyist」が集まる年次イベント、「RubyKaigi 」が今年５月、沖縄県那覇市で開催されました。
昨年この「お祭り」に初参加させていただいた、われわれRIZAP、今年も若手エンジニアたちが参加してきました！　ここでは、会期中に開催された数々の講演について、メンバーがそれぞれの言葉で感想をまとめています
（メンバー別⇒参加した講演別に目次を分けています）。

↓↓↓ 現場レポートはこちら ↓↓↓

▶プロフィール
梅田智大／プロダクト開発統括１部エンジニア
松永祐生／プロダクト開発統括１部エンジニア

バックエンドエンジニア梅田智大の感想まとめ

１．Writing Weird Code

登壇されたのは、「世にも奇妙なコード」を書くことで有名なTomoya Ishida（＠tompng 、通称：ぺん）さんです。ぺんさんは「TRICK（※）2022」で金賞を受賞された方です。

※TRICK…RubiyKaigiで開催される、奇妙なコードで競い合うプログラミングコンテスト。前回は（おそらく）2022に開催。

金魚が鉢の中を泳いでいるように見えるアニメーションをRubyコードで表現するだけでなく、一時停止をするとその場所から泳ぎを再開するという、まさに神業的なコードです（言葉で説明しても伝わらないと思うので、詳しくは下記をご確認ください…）。

先月、TRICK2022(超絶技巧Ruby意味不明コンテスト for RubyKaigi)で金賞をとってきたプログラム(Quine)です。
全てのフレームが、魚達がその場所から泳ぎを再開する実行可能なRubyのコードになっています。
魚・水草・泡でコードの一部が欠落していますが、誤り訂正により復元しています。 pic.twitter.com/vQsGG5o7Of
— ぺん！ (@tompng) October 18, 2022

私も最初にこれを見たときは、「なんだかすごいことをやる人がいるのだな」と驚く程度でしたが、このセッションでは、奇妙なコードに隠されたテクニックと、その魅力が語られていました。

奇妙なコードに隠されたテクニック

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

このコードをご覧ください。一見意味をなさないヘンテコなコードに見えますが、実はRubyの構文としては正しく、実行結果は空文字列「""」となります。

Rubyの「%」記号はさまざまなコンテキストで使われ、それぞれ異なる意味を持ちます。

先のコードは、こうした「%」記号が持つさまざまなコンテキストを組み合わせることで、Rubyとしてsyntax validなコードに仕上げているとのことでした。

ぺんさんは、こういった記号や文字がRubyではどのように解釈されるのか、複数並べたり、スペースを空けるとどう解釈が変わるかなどを一つ一つ解明していくことで、一見奇妙だけれどRubyとしてきちんと実行できるコードを生み出しています。

私には到底まねできない魔法だと思っていましたが、実はRubyを知り尽くして突き詰めていった境地であり、Rubyと実直に向き合っていった延長に過ぎないのだと気づかされました。

Self TRICK 2024
今年はTRICKの開催はありませんでしたが、ぺんさんはこのKeynoteのためにいくつもの奇妙な作品を生み出し、それを発表されていました。

その作品はビットマップ画像でありつつ、Rubyのコードとして実行可能なものや、CRubyとcanvas APIを使ってブラウザでアニメーションを実行するもの、実物かのように泳いでいるクラゲをクリックすると、触手が動くというコードなど、非常にユニークかつテクニカルなものばかりでした。

中でも興味深かったのが、波の動きを再現したアニメーションです。金魚のように、アニメーションを一時停止すると途中から再開することが可能です。一見金魚と似たようなコードに見えますが、実は別のロジックを採用しており、波がどのような状態かという演出に意味を持たせることで、全く同じ状態を復元するのではなく、同じ演出を再実行することで厳密には同じ状態ではないけれど同じように見えるようにしています。

似たようなアウトプットでも、複数のアプローチができる。まさにRubyの自由度の高さと楽しさを表現した、素晴らしい作品だと感じました。

↓↓↓ 下記より作品をチェック！ ↓↓↓

【感想】
「奇妙なコード」に隠されていたのは、Rubyへのひたむきな探究心でした。これは単なる遊びのカテゴリーに収まらず、Rubyを深く理解することが実務に生かされることを示しています。思考の幅を広げることで、新しいアプローチを発見でき、アプリケーションのパフォーマンスを向上させたり、予期しないバグや落とし穴に気がつきやすくなったりします。

会場が大盛り上がりした上に、初学者の心にも刺さるような内容で、まさにRubyKaigi 2024の開幕にふさわしい素晴らしいセッションでした！

２．An adventure of Happy Eyeballs

昨年のRubyKaigi 2023にも登壇され、Rubyにインクリメント演算子を導入するテーマで、その試行錯誤のプロセスをユーモラスに、かつ熱意を込めて語られたShioiさん。私もそのセッションに参加し、その場の熱気に心を躍らせました。
そのShioiさんが今年もステージに立ち、昨年を超える情熱を持って会場を盛り上げてくださいました！

今年のテーマはなんと「RubyにHappy Eyeballsを導入する」
今年のテーマは、「RubyにHappy Eyeballsをどう導入するか」というものでした。Happy Eyeballsはインターネット接続の問題を解決するアルゴリズムで、IPv4とIPv6のどちらが速く応答するかをテストし、最適な接続を選択します。このアルゴリズムは、ユーザーのオンライン体験をスムーズにし、IPv4とIPv6が利用可能な環境で、どちらのプロトコルが効率的に動作するかを迅速に判断します。

試行錯誤の末に行き着いた驚きの発見
Happy Eyeballsの導入にも、数多くの困難に直面したそうです。
特に難しかったのが、IPv4とIPv6のどちらを選択するかの複雑な条件分岐だったとのこと。

IPv4とIPv6のどちらに接続するのかはさまざまな条件によって決まり、ありとあらゆるケースを想定して条件分岐を組まないと、考慮漏れが発生してしまうため、何度も壁にぶつかったそうです。

試行錯誤の末に行き着いた結論が、リソースの状態によって適切に接続をしたりエラーハンドリングなどの処理をしたり、つまり状態管理であるというものでした。

この状態管理による解決策は、真の課題を抽象化し、それに基づいて解決策を考えるという、まさにエンジニアリングの精神そのものでした。Shioiさんの発想力にはただただ驚かされるばかりです。

Shioiさんに直撃インタビュー!!?
このセッションには私自身非常に感銘を受けたこともあり、その感動をShioiさんご本人に直接伝えに行きました！

「Happy Eyeballsについても初めて知ったので、セッションの内容をきちんと理解しきれなかったですが、アプローチや思考力の素晴らしさに感動しました…！」と私がお伝えしたところ、Shioiさんは「私もHappy Eyeballsのことは全然知らなかったので大丈夫ですよ！」と優しく答えてくださいました（知らない訳ないのに、本当に親切でお優しいShioiさんに心から感謝です…）。

さらに、複雑な状態管理をどのように設計し、どう考慮漏れを防いでいるのかが気になったので、質問いたしました。
するとなんと、

「セッションでは発表しきれなかったですが、実は全ての条件を片っ端からテキストで書き出しているんですよ…」

と驚きの返答が（笑）。
条件を書き出し続けたところ、途中から、大きく四つの前提に分類されることに気がつき、考慮漏れがなく全ての条件を洗い出すことに成功したそうです（実際に全ての条件を書き出したファイルを拝見させていただきましたが、本当にすさまじい文量でした）。

私もRubyKaigi 2024の半月ほど前、ちょっと複雑なビジネスロジックを組んだときに考慮漏れをしてしまい悩んでいたので、非常に勉強になりました。

【感想】
恥ずかしながら、このセッションを聴くまでHappy Eyeballsのことを知りませんでした。また、セッションの内容を完全に理解するのも難しかったのですが、エンジニアとしての思考プロセスを垣間見ることができ、非常に感動的な体験でした。

さらに、昨年の++メソッドは実際には採用されず、試行だけで終わりましたが、今年発表されたHappy Eyeballsは、なんとRuby3.4に導入が決まっているようです…！
エンジニアとして躍進めざましいShioiさんの活躍ぶりに、ただただ尊敬の念を抱くばかりです。駆け出しエンジニアの私にとって、勇気づけられる非常に素晴らしいセッションでした！

３．Embedding it into Ruby code

今回のセッションは、Rubyに型定義を導入できるOSS、RBSに関するものでした。RBSは、Rubyのクラスやモジュールの構造を定義するための言語で、メソッドの引数や変数などに型を指定できます。これにより、Rubyコードの型の安全性が向上し、プログラムの挙動をより正確に保証することが可能になります。

登壇された松本宗太郎さんは、RBSの主要なコミッターであり、昨年のRubyKaigi 2023のKeynoteスピーカーでもあります。

松本に始まり松本で終わる

従来のRBS
RBSは簡単に導入でき、gem install rbs コマンドでインストール後、以下のようにクラスの属性やメソッドの引数に型を指定します。

class User
  attr_reader :login, :email
 
  def initialize(login: String, email: String)
    @login = login
    @email = email
  end
end

型定義を完了した後、CLIで「rbs prototype」コマンドを実行すると、sig/ディレクトリにRBSファイルが自動生成されます。

この生成されたRBSファイルをもとに型チェックを行っており、別ファイルに書き出すことで、既存のコードを壊すことなく型定義ができるようにしているそうです。

ファイル分割の課題と革新的な解決策
従来、型定義を別ファイルに分割することは、CLIコマンドを定期的に実行しなければならないという課題がありました。GitHubでコードのレビューを行った際にCLIを実行し忘れると、RBSファイルと実装コードの間に乖離（かいり）が生じ、型チェックが正常に機能しないという問題が起こっていたようです。
そんな課題を解決すべく、今回の開発ではRBSコードをRubyファイル内のコメントとして埋め込むという画期的な方法を導入されたそうです。

具体的には、開発者は型情報をコメントで記述します。すると、Rubyを実行する際に、コメントを解析してrbsファイルを自動生成してくれるそうです。
このアプローチにより、RBSファイルと型定義の乖離（かいり）を防ぎながら、開発の効率を大幅に向上させることができます。

YARDとの互換性も！
さらに素晴らしいことに、YARDエコシステムとの互換性も持っており、ほとんどYARDを書いているのと同じ感覚でRBSの型定義を書けます。

YARD
# @param size [Integer]

RBS
# @rbs size Integer

すでにYARDを採用しているチームがRBSを導入するハードルが下がりますし、初学者でも感覚的に理解できる読み味になるので、これは非常にうれしいです。

【感想】
私たちのチームでは、静的型付けをやっていませんでしたが、Copilotの予測精度を上げるために、型情報をコメントしても良いよねという会話をしていました。RIZAPではRBSを導入していないこともありYARDでコメントを書くことを検討していますが、RBSを導入することで型チェックまでできるということ自体は素晴らしいなと思いました…！
ユーザーが使いやすいことを、常に心がけて開発をされている松本宗太郎さんの姿勢からは、学ぶことが尽きません！

バックエンドエンジニア松永祐生の感想まとめ

４．Good first issues of TypeProf

Yusuke Endoh (@mametter) さんによるセッションで、現在mametterさんが開発を主導しているTypeProfという型推論ツールの紹介でした。

自分は今回のRubyKaigiに参加するにあたり、予習としてmametterさんの『RubyでつくるRuby』という本を読んでいたので、ご本人にお会いできることをとても楽しみにしていました！

さて、気になるその内容ですが、TypeProfはvscodeなどのエディター上で動くツールだそうです。

例えば以下のようなコードがあるとします。

string = 'hoge' + 10

この場合、もちろんstringとintegerの加算はできないためエラーになりますが、TypeProfを入れていると、このようなときにエディターがバグとして警告を出してくれるそうです。 Typescriptで書いているときと同じですね。すごい！
そのほか、強力な入力補完機能などもあるとのことでした。

セッションの最後では、開発に貢献してくれる人を探しているというお話もありました。そのため、「どのように開発しているか」や、「TypeProfの内部構造などの説明」、「今後実装していく機能」などについても説明がありました。

【感想】
TypeErrorに対して書いた時点でエディターが警告を出してくれるのは、すごくうれしいと感じました！　また、自分はRubyMineが好きなのですが、諸事情によりvscodeを使っているため、入力補完機能を備えていることもかなりうれしいです。
まだまだ勉強不足なため、TypeProfの開発にすぐには貢献できませんが、今後ますます便利になるであろうTypeProfに、非常に期待しています！

５．Namespace, What and Why

Satoshi Tagomori(@tagomoris) さんによるセッションでした。
Rubyの新しい機能として実装されているNamespaseの解説、使用例、そして将来に関する説明でした。

Namespaseとは
Namespase(名前空間)は、アプリやライブラリをカプセル化する仕組みです。それぞれの名前空間は独立した空間として機能し、他の名前空間やグローバル空間からの影響を受けないそうです。

これにより、以下のメリットがあるとのこと。

依存関係の衝突回避: 異なるバージョンのライブラリを同時に使用可能です。
コードの分離: クラスよりも大きな単位で区切れ、各名前空間同士は影響し合いません。
開発効率の向上: 影響範囲を限定しやすく、モジュール単位での開発・デプロイが容易になります。

モジュラーモノリスにすごく良さそうな機能ですよね！
他の参加者の方からは「段階的なRails Upgradeが可能になるのでは」といった声もあり、これまできつかったさまざまな問題の解決につながりそうな機能だと思いました。

【感想】
これまでモジュラーモノリスをRailsでやるのにはいくつかの問題点がありました。

依存関係の管理
パフォーマンス
スケーラビリティ

Namespaseはこれら全てを解決できる可能性を持つ、素晴らしい機能だと感じました。まだまだ開発途中だそうですが今後のRubyを左右する大きな機能で、聞いていてとてもわくわくするセッションでした。

６．Matz Keynote

最後はRubyの生みの親、MatzのKeynoteです！
今回Matzは「パフォーマンス」に着目し、これからのRubyについて構想を語ってくれました。

Rubyはかつて「遅い言語」と言われてきました。
しかし、YARV, MJITそして3.0ではYJITが追加され、今や大企業が使うに十分なレベルで速くなりました。その上で、今後Rubyをより良くしていくために、「メモリ効率」や「並列性」について挙げられました。

また、Ruby開発の高速化という点でRubyとその周辺ライブラリにおけるParserの統一についても話されており、今回のRubyKaigiでも度々登場したPrismとLramaが候補に挙がっているそうです。

APIはPrismのインターフェースを採用しようとしているようですが、MatzはPrismが手書きParserであることが気になっているそうで、最終的な決定は保留のようです。その他、夢の話としてRubyのシングルバイナリ化のためにAOTコンパイラが欲しいという話もありました。

【感想】
とても面白くて、Rubyをやっていて良かったと思えるようなキーノートでした！技術的にはあまり理解できないところも多かったのですが、それでも聞き入ってしまう程いい話で、本当に面白かったです。Rubyの内部処理があまり理解できていないために、難しく感じるセッションもあったので、来年はRubyのもっと深いところまで勉強してから挑みたいと思います！

（了）

この記事が気に入ったらサポートをしてみませんか？