RubyKaigi 2022に参加してきたので拙いながらもそのレポートです。
今回は初のオフライン参加で参加前は少し緊張していたのですが、3日間楽しみきることができました！

全部書いていくと長くなり書ききるのにも時間がかかってしまいそうなので開発体験に関わるいくつかテーマを絞って発表の感想などを書こうと思います。

WebAssemblyサポートについて

初回の発表はWebAssemblyについて。
RubyのWasm対応はこの以下の記事を見て気になっていたので楽しみにしていたセッションでした。
https://www.publickey1.jp/blog/22/rubywebassemblywasirubygems.html

CookpadさんによるRubyPuzzlesもこれを使っているみたいです。 https://ruby-puzzles-2022.cookpad.tech/

面白いなと思ったのはSwift, Rust, Goなど他の言語は実行するバイナリをWasmとしてビルドしてブラウザ上で実行するに対し、今回のセッションで紹介された仕組みではRubyのインタプリタ、ランタイムをWASMとして用意し実行するrbファイルと共にブラウザに渡し実行する点でした。これによりRubyアプリケーションのコードを再コンパイルすることなくそのまま動かせるのだとか。この仕組みは他のスクリプト言語でも応用できるそうです。

またシングルバイナリにする必要があったためインタプリタと実行するrbファイルをシングルファイルとしてデプロイするためにWebAssemblyバイナリに埋め込み可能なVFS仮想ファイルシステム）をつくったそうです。（しれっと言っていてビックリしました笑）
またファイルシステムやOS依存に関しては、WASI（WebAssembly System Interface）で対応しているそうです。

今まではWebAssemblyが盛り上がっていてもその恩恵がいまいち理解できていなかったのですが、実際に見て、会場で触れてみてその影響のインパクトを実感できました。

CRuby を WebAssembly に移植する際に「例外処理」, 「Fiber」, 「保守的なGC」の３つの問題に直面し、これをAysncifyを使うことで解決したそうです。 同期的なCの処理を非同期なものにできるものらしいですが、私はここで初めて聞いたのでよくわからず。。 気になったので勉強してます。

型について

Types teaches success, what will we do?

https://rubykaigi.org/2022/presentations/fugakkbn.html#day1

gem_rbs_collection についての発表でした。

Ruby3.0ではRBSの導入されるもあまり普及していない原因の一つとして型が付いているgemが少ないことが挙げられるのではないかと言う話から始まりました。 gemの型定義を集めたgem_rbs_collection（TypeScriptで言うところの DefinitelyTyped）があるそうなのですが、RubyGems には17万を超えるgemが登録されている一方でgem_rbs_collectionには44個しか型定義がないとのことでした(0.025%)。思っていたより少ない。。

そこでgem_rbs_collectionへのcontributionが必要ということで、contributionのやり方について発表されていました。

手動生成や自動生成の使い分けなど具体的なやり方を実際に登壇者の方が書いたPRや作業の内容を元に解説されていました。 また規模が大きいgemだと全てのAPIを対応するのは難しいので、主要なAPIや自分のプロジェクトで使っている部分を追加すれば良いとのことでコントリビューションへのハードルが下がりました。

gem_rbs_collectionにコントリビューションしていく方法について実際の経験を踏まえて説明されていたので分かりやすく、コントリビューションにチャレンジしてみたくなりました。

参考) https://github.com/ruby/gem_rbs_collection/blob/main/docs/CONTRIBUTING.md

RBS generation framework using Rack architecture

https://rubykaigi.org/2022/presentations/_ksss_.html#day3

この発表では orthoses の紹介が行われました。 モチベーションとしてはHappy Hackingをゴールに型をありふれた状態にするために型ファイルを自動生成することを目指しているようです。

型情報の生成でRack architectureを参考にして生成される型の量と正確性、型情報生成における拡張性と柔軟性を解消したという内容でした。 CLIで用意せず、以下のようにRakeタスクなどのスクリプトで複数のMiddlewareを繋げることで破綻することなく複数機能を組み合せるやり方は柔軟性があって良さそうでした。

include, extendの追従やattr_accessorなどで動的定義されるメソッドに対応することもできるらしく、それならRailsでもある程度使えるのかなと考えていたら orthoses-rails というRails向けのものが紹介されていました。

Rack architectureを参考にしてどういう実装をしたかが主な内容だったので、どのような使い方ができそうかは実際に触ってみて試してみようと思います。

Let’s collect type info during Ruby running and automaticall

https://rubykaigi.org/2022/presentations/pink_bangbi.html#day3

RBS::Dynamic についての発表でした。

静的解析によるアプローチはTypeProf で既に行われていてRubyKaigi Takeout 2021で発表されていましたが、このGemでは動的解析のアプローチをしていました。

RBSの呼び出し元も記述されるのは意図しない型が生成された際に呼び出し元を辿れるので便利に感じました。
シンボルは特定シンボルしか来ないケースと任意シンボルが渡される場合があって難しいとの話でしたが、TypeScriptのUnion型の様にSymbol | :hoge | :fuga のような定義の仕方で解消していました。
またハッシュのキーがどのような値になっているのか分かるのは嬉しいですね。

Railsアプリケーションへのリクエストに対して自動でRBSを生成したかったみたいな話もされていて、最近使ってみているRequestSpecからOpenAPI仕様書を生成するrspec-openapi と思想や目標としているものが似ている印象を受けました。

Ruby programming with types in action

https://rubykaigi.org/2022/presentations/soutaro.html#day3

Steepについての話をライブコーディングを交えて発表されていました。 印象に残った話をいくつか書いていきます。 英語での発表だったので聞き逃していたり、多少意味が間違っているかも知れませんがご了承ください。

まずは型があると何が嬉しいか利点としては以下のような点が挙げられていました。

  • コードを理解する助けになる
  • APIドキュメントとして使える
  • 新機能追加やリファクタリングを容易になる

私個人としても最後の「新機能追加やリファクタリングを容易になる」点で型が欲しいな〜と思っています。

他の話題としては、InheritanceとUnion型の比較について書かれていました。

  • Union型: データタイプが全てわかってる場合
  • Inheritance+ method call: データタイプが未知の場合

Union型だとcase whenで網羅性を検査してくれるそうで、「Let’s collect type info during Ruby running and automaticall」でもちょっと書きましたがTypeScriptの影響を受けているように見受けられました。
今回のRubyKaigiにおいては自動生成の話が多かったのですが、これらが実現すれば良し悪しは分かりませんが型定義を先に定義するTypeScriptとはまた違った開発体験になるのかなと思っています。

また型情報の定義をどのように行った方が良いか登壇者の方の私見について以下のようなお話をされてました。

  • 自分が必要な部分に全ての型エラーを最初から全て直す必要はない
  • 既存コードで型を書いていくよりも新しいコードで型を書いていく方が良い
    • 既存コードのタイプチェックは大変な割にクリティカルなバグが無いのがわかっているので、努力が必要な割に利益は少ない
    • 新規コードにSteepを適用すれば未知のバグを発見できる

納得できる話ですがリファクタリングする際に既存のコードに対しても型が欲しいなと思ってしまうんですよね。。

デモではgem_rbs_collectionを実際に使っているところを見ましたが、Gemfile.lockを見て必要な型定義を持ってきてくれるは便利だなと思いました。

また今回のライブコーディングではSteepはLSPのサポートをしているものありVSCodeが使われていました。
今回はツール周りの発表がVSCode関連が多かったためVSCode使っている身としては嬉しいです。

デバッグについて

Tools for Providing rich user experience in debugger

https://rubykaigi.org/2022/presentations/ono-max.html#day1

前半がdebug.gemをChrome DevTools Protocolを通してChromeでも使える様にする内容で後半がVSCodeでのdebug.gemの利用についての内容でした。

私は普段VSCodeの拡張機能を通してdebaseを使用しているので、debug.gemはまだ触ったことがないのですが興味があったので聞きに行きました。

まず広く使われているChromeの開発者ツールをUIとして利用することで、VSCodeに限らず誰でもdebug.gemをリッチなUIで利用できるようにするというデモを交えて発表されていました。 デモではステップ実行や、各ステップでの変数の状態も確認できたり、変数の値を書き換えてステップ実行を進めることで実行途中で値を書き換えて以降の処理を実行することもでき便利そうでした。 ただ流石にSyntaxHighlightは効いていませんでした。（それはそう）

設定が必要にはなりますが、一応Railsのdebugでも使える様です。

次にVSCodeでのデバッグをサポートする二つの機能について紹介されました。

  • History Inspectorというその時点の状態を確認する機能
  • Object Inspector: ActiveRecordで取得したインスタンスを見やすくする機（table, グラフ化）

特に後者に関しては私の職場ではバッチ処理の実行時間を計測しているモデルが存在するため、この機能を使って実行時間をグラフ化する等に使えそうでした。

error_highlight: user-friendly

https://rubykaigi.org/2022/presentations/mametter.html#day3

行番号と列番号を出されてもエラー箇所の特定が難しいことがあるので、地味かも知れませんがとても体験の良い嬉しい機能だなと思いました。
また文字列にエスケープ文字があると、表示時にエスケープを追加するのでハイライト位置がずれる問題に関して、エスケープ追加表示を止めるためにセキュリティのために足された処理のためにそれを消しても問題ないと言う根拠を集めるために一ヶ月くらいかかったそうです。 またRubyの一つのことをするにも表現が多いので全ての記法を考慮をしていくのが大変そうでした。

p e.messageで複数行出てくるのはログフォーマットがやだな〜と思っていたらException#detailed_messageに分けて実装したそうです。便利。

ちなみにSentryとDataDogがException#detailed_messageへの対応を表明しているらしいです。

SentryとDataDogは、Exception#detailed_messageを提案したチケットの中で、#detailed_messageを使うようにすることを約束してくれました。 https://techlife.cookpad.com/entry/2022/09/01/104312

個人的には普段仕事で主に使っているBugsnagも対応してくれると嬉しいなと思いました。 モニタリングツールからSlack通知が飛んできてサクッとエラーの箇所を特定して対応できるようになると嬉しいです。

Rubocopについて

Make RuboCop super fast

https://rubykaigi.org/2022/presentations/koic.html#day2

以下の4つの手法を用いて RuboCop を高速化したという内容でした。

  • キャッシュ: 解析結果をキャッシュする
  • 並列実行: マルチコアを活用しボトルネックになっている箇所を並列に実行できる様になる
  • 読み込みファイルの削減: 不要なrequire 'rubocop'を外すようにした（850倍早くなった）
  • サーバーモード（Daemonize）: Client/Serverモデルにして、プロセスを常駐化させる

実装やその結果に関しても驚きましたが、ユーザーに配慮した設計のお話が印象出来でした。 例えばrubocop-serverコマンドではなく、rubocop --serverで実装した理由として、使っている人がrubocopのまま早くしたいのではないかと思いオプションにすることに決定されたそうです。 またオプションの実装もサーバーのプロセスが起動しているならサーバーの起動処理は行われず未起動ならサーバーを起動するようされており、またこれらの処理に失敗した場合には既存挙動を実行するようにすることで一つコマンドに統一していて使い勝手が良いように考えられていました。

RubyKaigi駆動で実装したとのことで発表当日には既に使えるようになっていたので、タイムラグなく今すぐ高速化したRuboCopを試せる状態になっていて良い発表だなと思いました。

その他

Matz Keynote

https://rubykaigi.org/2022/presentations/yukihiro_matz.html#day2

オンラインだと何回か聞いてますが、今回は生で「Rubyは死んだ」の話を聞けました。

プログラミング言語の価値の軸を「Productivity」,「Community」,「Joy」,「Money」に定めて議論したいと言う話が印象的でした。 プログラミング言語は流行りもあるのでそれに乗って批判されたりもしますが、そのもの価値とは何か、どう生み出していくのかに主眼を当てて考えていくと言うお話が印象的で好きです。

TRICK 2022

https://rubykaigi.org/2022/presentations/rubylangorg.html#day2

TRICKとはRubyの超絶技巧コードコンテストです。

TRICK の理念

去年からのRubyKaigiTakeout2021で話に挙がっていて、是非見てみたいなと思っていたので現地で見れて大変嬉しかったです。 無駄に洗練された無駄なロジックすぎて解説されても分からなかったり、何でそんなことを思いつくのかみたいな。。とにかく発想が面白かったです。 発表のたびに会場で笑いと拍手が起こっていました。

こちらにソースコードが公開されているのでぜひ試してみてください。 https://github.com/tric/trick2022

金賞を受賞した金魚鉢の作品がすごかったです。。納得の順位でした。

感想

Rubyについて夢が広がる発表が多く私の職場のSlackのRubyKaigi2022チャンネルでもかなり盛り上がっていました。
話についていけてない発表もあって、C言語の話になると正直何となくこういうことかな〜と推測する話が多かったです。しかし、そういう難易度の高い発表を聞いていてためにならなかったかというと全くそんなことはなくて普段開発で使っているRubyやそのエコシステムのバッググラウンドを聞けるのはモチベーションが上がりました。
機能自体の便利さもさることながらこういった裏側の話を聞くのも楽しいでので次回参加したときにはわかる範囲を増やせるように、わからなかったことはメモしておいたのでちょっとづつ理解に努めたいと思います。

またオフラインイベントならではの交流に関して、エンジニアとしての自分自身の技術力への自信のなさからあまりこういった場で割と話すのをためらってしまうことが多かったのですが、会場の雰囲気がフレンドリーだったこともあり自分の職場が抱えている課題について相談させていただいたり、Ruby以外にも開発体制やサービスの構成など様々なお話を伺えてとても楽しかったです。 お話しを聞かせていだたいた皆様ありがとうございました。

元々情報の専門でも何でもない学生時代にRubyを触り始めてエンジニアとしてキャリアを積んでいけているのでそろそろRubyに何か恩返しが出来ればなとそう思えるイベントでした。これは来年のRuby Kaigiに向けての宿題にします。

登壇者の方々、運営の方々、参加者の方々、おつかれさまでした！

おまけ

  • 1日目でPCのバッテリーが持たなかったため2日目からPCを2台持っていきましたが、今度は体力がゴリゴリ削られました。参加するにあたってPCを充電できるモバイルバッテリーは持っていた方が良さそうです。
  • 2022年10月にリリース予定のmacOS VenturaではLLVMに関して変更があるためあらゆるRubyのビルドができないそうです。アップデートは待った方が良いとのこと（他言語も影響多いのでは？）
  • 「ソフトウェアは何もしないと壊れる」
  • 自作キーボードに関する催し物が廊下で行われていました。自分のキーボードも持って行けば良かった。。。