株式会社TOKIUMの坂上(HN: にしこりさぶろ〜)です！この記事では、9月8日(木)-10日(土)の3日間に渡り開催されたRubyKaigi 2022にて、聴講したセッションの中でも印象に残ったモノをいくつか紹介していきます。
仕事では、AndroidエンジニアとしてKotlinのコードを書いている時間が最も長く、コミュニティ活動もKotlin開発者として参加することが多いため、「特定の企業が開発し、OSS化された」「静的型付け言語」の世界を主戦場とする開発者の目線からレポートを残そうと思います。
Day1で印象に残ったセッションは、以下の3つです
- Ruby meets WebAssembly
- Ruby Archaeology: Forgotten web frameworks
- Types teaches success, what will we do?
Ruby meets WebAssembly
RubyKaigi 2022の先陣を切ったKeynoteは、Ruby 3.2に追加されたWebAssemblyサポートに関するセッションでした。発表者のYuta Saitoさんは、WebAssemblyサポートの実装を実際に担当したRuby Commiterです。
アジェンダ
- Ruby 3.2の新機能として追加された、WebAssemblyサポートに関する解説
- WebAssemblyサポートに対するモチベーション解説
- ライブコーディングによる動作デモ
- どのようにCRubyをWebAssemblyへとコンパイルするのかの解説
解説 #1: WebAssemblyサポートに対するモチベーション
Rubyはプログラマーが楽しく実装できるよう設計されたプログラミング言語であり、また豊富なGemのエコシステムに支えられ、高速にプログラミングを行うことが可能です。
ですが、Rubyコードの実行に必要なインタプリタにはインストール先のプラットフォームに制限があり、これまでWebブラウザやモバイルデバイスでのRubyコードの実行は非常に難しいものでした。
また、Day3のセッション『Why is building the Ruby environment hard?』でも紹介されていましたが、Rubyのローカル環境へのインストールは時に予想外の困難を伴います。
この「プラットフォームによる実行環境の制限」「インストールの難しさ」を同時に解決するのが、WebAssemblyのサポートの機能です。WebAssemblyは、Webブラウザを含むスタックベースな仮想マシン上で実行されるプログラミング言語であり、これを利用することでRubyコードをWebブラウザ上で簡単に実行することができます。
解説 #2: 簡単な動作の解説とデモ
WebAssemblyサポートにより、RubyインタプリタのWebAssembly実装が追加されています。このWebAssembly版RubyインタプリタをHTMLで読み込ませるだけで、簡単にWebブラウザ上でRubyコードを実行することができます 🎉
セッション中のデモで実際に使われたコードがこちらです。たったこれだけのHTMLで、console上でのHello, World!とシンプルなおみくじアプリがブラウザ上で動作します 😳
また、Webブラウザ上でirbを動作させたデモアプリも紹介されました。なんとGemの読み込みまで可能です。
解説 #3: CRubyをWebAssemblyにコンパイルする原理の詳細
では実際にどのようにCRubyのコードをWebAssemblyにコンパイルしているのか。
CのコードをWebAssemblyに変換するコンパイラは既に存在することから、CRubyのコンパイルも簡単にできる！と思いきや、そうもいかなかったようです。
困難のポイントとしては「例外処理の実装」「Fiberへの対応」「保守的ガベージコレクション」の3点。これらの解決には、Javascriptの非同期なメソッドをCの同期的なメソッドから呼び出せるよう設計された、WebAssemblyのツールチェインの1つであるAsyncifyを利用した、とのことでした。
感想
Ruby以外の言語でも耳にするWebAssembly対応ですが、その機能追加がもたらすインパクトの大きさを今回初めて体験することができたように感じます。実行速度(mrubyとほぼ同速)やバイナリサイズ(gzip圧縮で最小2.9MB)の面での課題があることから、大規模なWebアプリ開発への即時導入は難しいと思いますが、Webブラウザ上で簡単にRubyの機能やGemを試すことが可能になる点は、コミュニティの成長に間違いなく大きな価値をもたらすでしょう。
余談ですが、僕はプライベートでKotlinコードをJavascriptにコンパイルし、Webブラウザ上で実行させるKotlin/JSでWebアプリを実装した経験が複数あり、特定の言語をWebブラウザ上で実行可能な形式に変換させる技術には非常に大きな関心があります。まさか初っ端から、ここまで大きなインスピレーションを得られるとは思っていなかったため、3日間の中でも印象深いセッションとなりました💓
Ruby Archaeology: Forgotten web frameworks
「2000年代はみんなRubyのWebフレームワークを書いていた」という概要の通り、RailsやSinatoraといった現在でも広く利用されているフレームワーク以外の、忘れ去られたフレームワークを紹介するセッションです。
※容赦のないNative Englishのセッションだったため、重要なAssesmentの部分が全く聞き取れませんでした😇 アーカイブ動画の公開後、もしかしたら追記するかもしれません。
紹介されたフレームワーク
-
CGI
- Perlっぽく書ける
-
nitro
- Web 2.0時代、Ajax/XMLのサポートがついたフレームワーク
- MVCアーキテクチャ + ASP/JSP/PHPスタイルでWebアプリを実装できた
- ogというORMを搭載、独立したgemとしても利用可能
- waves
-
Remaze
- 現在でも動作するフレームワーク
- MVCアーキテクチャ、記法もRailsに近い
- テンプレートエンジンとしてetanniが使われている
感想
僕自身、2016年に業務でRailsを触り出したことがRuby歴の始まりのため、紹介されたフレームワークは全て初見でした。2000年代はWebの急速な発展・普及の時代と一致するタイミングでもあり、混沌としつつも創造の熱量に溢れていたことを発表から感じ取ることができました。
言語・フレームワークにまつわる考古学的なセッションは、僕のような狭い経験しか持たない開発者にとって他では得難い情報を得られる場であるため、貴重な時間だったと思います。もう少し英語のリスニング能力があれば…😇
Types teaches success, what will we do?
こちらのセッションは、Ruby 3.0から追加されたRubyのコードに型定義を提供するRBSに関するモノです。発表者のFu-gaさんは、Gemに対する型定義情報をまとめたリポジトリ「gem_rbs_collection」のContibutorです。
アジェンダ
- Rubyでの開発における型の現状
- 型を導入するメリット
- 導入がなかなか進まない理由
-
gem_rbs_collectionの紹介とコントリビュート手順の詳細解説
- 型定義追加の作業に対する心構え
- ハマりやすい箇所の説明
解説 #1: Rubyの型の現状
セッションはまず、参加者へのアンケートからスタート。「みなさんはRubyプロジェクトに型を導入していますか？」という質問には殆ど手が挙がらず、対して「みなさんはTypeScriptをプロジェクトに導入していますか？」という質問には大多数が挙手。
プログラミング言語における型は、開発者体験を向上し、バグの混入確率を減らす、プロジェクトを成功に導くための非常に強力なツールであり、アンケートの結果からも分かる通り多くの開発者が型から得られる利益を理解し、享受したいと考えています。Rubyでも、バージョン3.0でRBSが追加され、プロダクトコードとは別に定義する形で型を扱うことが可能となっています。
しかしなぜ、Rubyのプロジェクトでは型の導入が進まないのでしょうか。その大きな理由の1つとして、既存のGemに対する型定義が全く足りていないことが挙げられます。
- RubyGems.orgに登録されているGemの数: 約17万件
- gem_rbs_collectionに追加されているRBSファイルの数: 44件 😭
解説 #2: gem_rbs_collectionの紹介とコントリビュート手順
この問題の解決策として、発表者が提案したのがgem_rbs_collectionへのコントリビュートです。その方法として、「既存のRBSファイルへ型定義を追加」「新規にRBSファイルを作成」の2つを取り上げ、それぞれの手順について詳細な説明がされました。
特に「新規にRBSファイルを作成」する際について、公式に推奨されている心構えとして「自身のアプリケーション内で使用しているAPIに注目し、型定義を追加する」ことへの言及がありました。
感想
Rubyコミュニティへの直接的な貢献に繋がり、かつ間口の大きなアプローチの紹介といったセッションで、大変興味深い内容でした。
サードパーティライブラリへの型定義の追加は、僕自身もKotlin/JSでのWebアプリ開発で経験があるのですが、作業に対するモチベーションの維持には大きな困難を伴います。利用するか分からないメソッドに対して型定義を追加すべきなのか悩むことが多く、頑張って追加した型定義が結局使われなかったケースでは、「無駄なことをしてしまった」という後悔に苛まれます。
このセッションで特に良いと感じたのは、「使用しているAPIに注目し、型定義を追加する」心構えが公式に推奨されていることを手順とともに丁寧に伝えていたことです。無理に完璧な定義をしなくていいことが分かるだけで、初心者・上級者問わずコントリビュートへのハードルは大きく下がるはずですし、コミュニティへのインパクトの強い内容だったのではないかと思いました。
【Day2・Day3のセッションレポートはこちら】
Discussion