私にとって初めてのデベロッパーカンファレンスだった「RubyKaigi」に参加してから、もう丸 1 年が経ったなんて信じられるでしょうか？　この 3 日間、私はことしのトークやセッションを楽しむ機会に再び恵まれました。残念ながらここ最近は自身の業務のためにしばらく離れていた Ruby のエコシステムでしたが、それに再び浸ることができたのです。この記事では、カンファレンスでのお気に入りの瞬間をいくつか紹介したいと思います。

RubyKaigi について

バラエティに富んだセッションの詳細を説明する前に、そもそも RubyKaigi とは何かを改めて説明することで、われわれの共通認識を確認させてください。RubyKaigiは、2006 年から（2012 年を除いて）毎年開催されている日本最大の Ruby プログラマのためのカンファレンスです。昨年同様、発表や議論の一部は日本語で行われますが、日本語を知らない多くの国際的なメンバーのために、同時通訳サービスが用意されていました。

それから昨年同様、ことしの RubyKaigi はオンラインのみのカンファレンスに変更されました。来年は本来のイン・パーソン形式のカンファレンスに戻れることを願っています。

TypeProf for IDE

遠藤侑介さんの基調講演では、静的型付けの利点と、Ruby 3.0 に同梱されているコード解析ツールTypeProfについての説明があり、カンファレンスは大いに盛り上がりました。TypeProf を搭載した Visual Studio Code の拡張機能である TypeProf for IDE の発表がこの直後に行われ、これがこの日の特別発表でした。

TypeProf for IDE は、今日すでに、メソッドのシグネチャに関するヒントをオンザフライで提供したり（Code Lens に便利に表示されます）、入力中にエラーを報告したり、呼び出したメソッドの定義場所を見つけたり、型を考慮したコード補完を提供したりできます。もちろん、いつものように、TypeProf がメソッドの型を間違って推測した場合は、RBS を使ってメソッドのシグネチャを手書きして推測された型を上書きすることもできます。TypeProf for IDE は Ruby 3.1 とともにリリースされる予定ですが、上記の説明に興奮した方は、いくつかの手動ステップを踏むことでいますぐに使い始めることができます。

簡単なスクリプトを書いたり、コードにちょっとした変更を加えたりするために、本格的な IDE（心配無用です、私はまだ RubyMine を愛しています）を開く必要はありませんからね。

"Ruby Archaeology", "Parallel testing with Ractors: putting CPUs to work" and "Regular Expressions: Amazing and Dangerous" 💎⛏

RubyKaigi の初日にはほかにも多くの素晴らしいセッションが行われましたが、もし 3 つだけ紹介するとしたら、Nick Schwaderer 氏による「Ruby Archaeology」は間違いなくその 1 つになるでしょう。ニックさんの講演では、Ruby の古代史を調べ、12 年前のバージョンの Ruby を動かすために乗り越えなければならなかった試練や罠をすべて説明してくれました。驚いたことに、Ruby 自体は当時の OS で問題なく動作するにもかかわらず、ほとんどの問題は別のところにあるようでした。特に、昔と同じようにはアクセスできないかもしれない、あるいはデジタル天国では完全になくなっているかもしれないリモートリソースに依存していることです。幸いなことに、ニックの足跡をたどって自分もタイムトラベラーになりたいと思っても、彼のように頑張る必要はないのです。

それから、Ractor を利用してテスト実行を高速化するテストフレームワークの研究（テストスイートが遅いと、開発者の実行意欲が減退してしまいますからね）についての Vinicius Stock 氏の発表と、Martin J. Dürst 氏の驚くべき、しかし時に危険な正規表現の世界へのツアーがこの日のハイライトでした。

キーボードは実質 Ruby、あるいは ⌨ = 💎

さてさて、これは私の偏見かもしれませんが、それでも言わなければなりません。カンファレンス全体とは言わないまでも、2 日目の個人的なハイライトは、弊社 Monstarlab の羽角均によるPRK Firmwareです。他のスピーカーやプレゼンテーションがどれほど素晴らしかったかを考えれば、これはかなりの快挙です。

羽角によるライブプレゼンテーションは、一定の間隔でオーディエンスの心を揺さぶり続けていました。まず、自作のキーボードのファームウェアを Ruby でプログラムできるということ自体が、非常に素晴らしいことです。彼が「フィボナッチ」キーや「パスワードジェネレータ」キーで示したように、特定のキーを Ruby コードの実行に割り当てることができるのは、さらに素晴らしいことです。そしてさらに完全に別世界へぶっ飛んだレベルでは本当に驚かされました --- 「Ruby」キーが、キーボードと任意のテキストエディタ（Notepad.exe のようなシンプルなものでさえ）を、IRB シェルへと変えてしまいました。どこへでも Ruby を持ち歩くことができます。ただしその前に、PicoRuby における静的型チェックの記事をお読みになることをお忘れなく。

Graphical Terminal User Interface of Ruby 3.1

率直に言って、私はスマートで直感的でユーザーフレンドリーなターミナル・ユーザー・インターフェース（TUI）の大ファンです。IRB は、強力な自動補完機能、自動インデント、シンタックスハイライトなどを備える、すでに非常にスマートな REPL（read-evaluate-print-loop --- 自尊心のあるプログラミング言語ならば提供すべき）環境ですが、糸柳茶蔵さんの野心はそれだけに留まらないようです。Reline ライブラリを改良することで、Ruby 3.1 の IRB は、これまでのようにTabキーでコードを自動補完するだけでなく、他の IDE のように、可能なすべてのオプションを美しいドロップダウンメニューで表示するようになります。

Do regex dream of Turing Completeness? 😴💭

Conway's Game of Lifeを正規表現で完璧に実装することで、正規表現がチューリング完全であるかどうかを調べるという Daniel Magliola 氏の調査目的で、RubyKaigi の 3 日目（最終日）がスタートしました。正規表現は十分にはチューリング完全ではないが、それほど的外れではないことがわかったという結論をお伝えするくらいなら、あまりネタバレにならないと思います。このトーク全体が非常に見応えがあり、Daniel 氏の創意工夫だけでなく、これまで気づかれていなかったかもしれないような正規表現の力と奇抜さを示しています。

Native extensions and dead ends

続いて、Mike Dalessio 氏によるネイティブ・エクステンション（"this could take a time..."というメッセージは、誰もが過去に見たことがあり、端末に表示されるたびに少しため息をついたものです）とネイティブ gems（特定のアーキテクチャ用にコンパイル済みのライブラリを含み、C 言語のエクステンションを自分でコンパイルする必要がないもの）についての興味深い講演が行われました。

Richard Schneeman 氏は、非常にプロフェッショナルなプレゼンテーションで、dead_endに関する彼の研究を実演しました。これは、次回から「予期せぬ終了」エラーメッセージを簡単に診断して修正するのに役立ちます。これによって、 end や do といったキーワードの欠落や、 | や } といったシンボルの不一致を診断することができるのです。

まつもとゆきひろ "Matz" さんのクロージング・キーノート

最後に、まつもとゆきひろさんのクロージング・キーノートでカンファレンスは締めくくられました。

前半では、比較的最近リリースされた Ruby 3.0 を振り返りました。このリリースは、（Ruby 2.0 以来）約 8 年ぶりのメジャーリリースであると同時に、後方互換性の重要性を念頭に置いたリリースでもありました。というのも、一部のコミュニティにとっては驚くべきことかもしれませんが、開発者は古いコードが動かなくなって書き直さなければならなくなるほどに新しいものを、あまり好きではないからです。

まつもとさんは、Ruby 3.0 が開発者にもたらした素晴らしい追加機能を紹介しました。例えば、RBS による型定義のサポートは、概念的には TypeScript の d.ts ファイルに似ていますが、個人的には、性質も構文も Elixir の Dialyzer と Typespecs に非常によく似ていると感じています。番号付きのブロックパラメータとパターンマッチのサポート（面白いことに、私が Elixir で気に入っていて、Ruby でも見られることをとても喜んでいる 2 つの機能です）も、より良い並行プログラミングのための 2 つのアプローチと同様に言及されました。高速なコンテキストスイッチを備えた Fiber スケジューラーは、I/O を多用する処理において理想的であり、Ractor は CPU を多用するすべてのタスクの窮地を救ってくれます。

話題は、次期リリースの Ruby 3.1 に焦点を移しました。Ruby 3.1 は、安定性の向上、より多くのバグ修正、そして特に 2 つのことを主な目的とした保守的なリリースになると述べられました。より強力な IRB と TypeProf for IDE による「開発者の快適さ」と「さらなるスピード」--- ただし理想的には、人工的なベンチマークで数値を無意味に追い求めるようなスピードではなく、現実のアプリケーションで本当に必要とされるスピードです。

私は、開発者の快適性がプログラミング言語の存続に関わる重要な要素の一つであると考えているので、この 2 つの側面に焦点を当てた決断を称賛せずにはいられません。来年の RubyKaigi にも参加したいと思っていますので、どうぞよろしくお願いします。