はじめに
ペイトナー請求書のフロントエンドエンジニアの@fuqda です。
本稿は、先日開催されたRubyKaigi2023の参加レポートになります。
フロントエンドの立場から見たRubyKaigiのセッションレポートが出来れば思いますので、最後までお付き合いください。
(弊社は昨年に続き、今回もSilver Sponsorとして協賛しております)
フロントエンドなのにRubyKaigiに何で？
フロントエンドなのに何でRubyKaigi？と思われる方もいるかもしれませんので、簡単に私の経歴を申し上げますと、元々前職では4年ほどRailsエンジニアをしておりました。 また、社外ではTama.rbという地域Rubyコミュニティのオーガナイザーとしても活動していた時期があります。
Rubyコミュニティのおかげでエンジニアを続けて来れた実感があるので、チャンスがあればまた参加したいなぁと思っていたところ、業務として参加するチャンスを頂けたので、参加する運びとなりました！ (ほんとに会社やチームのみんなに感謝です。)
参加したセッション
今回は数年ぶりに再会したRubyFriendsとお話することがメインになってしまったので、参加セッションは気持ち少なめです。
- 1日目
- Matz Keynote
- Develop chrome extension with ruby.wasm
- Lightning Talks
- 2日目
- How resolve Gem dependencies in your code?
- Yet Another Ruby Parser
- Revisiting TypeProf - IDE support as a primary feature
- Multiverse Ruby
- Keynote：Optimizing YJIT’s Performance, from Inception to Production
- 3日目
- Ruby Committers and The World
- Ruby + ADBC - A single API between Ruby and DBs
- Code indexing: How language servers understand our code
- Ruby JIT Hacking Guide
- Keynote：Parsing RBS
印象に残ったセッション
Develop chrome extension with ruby.wasm
WebAssembly上でRubyを動かせるようになったので、RubyでChrome拡張を実装した！という話でした。 個人的にRubyがフロントエンド技術にどう食い込んでくるのか気になったので見に行きました。
Rubyだけで全てコードを書くハックが聞けるのかな？と思ったものの、蓋を開けてみると、メインの言語はRubyだったのですが、JSをimportして書かなければならないようだったので、だったらJSでええやん…ってなったのを覚えていますw
上記の形式で書くとRubyの心地良い書き味が損なわれてしまうことから、Rubyのスクリプトを読み込むだけでChrome拡張機能を作成できるようなフレームワークである「unloosen」を開発することに至ったとのことでした。
unloosenを使うことで書き味は快適になっていそうなものの、実際のブラウザでは、ページアクセスの度に重めの通信が走ってしまうようなので、minifyする処理などが必要そう？でした。
実戦投入するなら、結局webpackで行なっていることを再実装することになりそうなので、なかなか険しい道かもなぁとしみじみ。
Revisiting TypeProf - IDE support as a primary feature
Ruby 3.0から標準搭載されている静的型解析器「TypeProf」のお話でした。 TypeProf v1では、解析速度がIDEなどで求められるスピードに達しておらず実戦で使うのは難しかったようです。
そこで、v1では変更があった際にコード全てに対して型推論を行っていたのに対し、 v2ではコードの変更部分のみ検査することでコード変更時の型推論のパフォーマンスが向上する見込みとのこと。 個人的にVSCodeでTypeScript同様の補完やコードジャンプが効いてはじめて実戦投入レベルかなと思うのでどんな着地点になるんだか気になります。
Ruby3.3でIDEの利用に耐えるパフォーマンスを目指して開発中らしいので気長に待ちたいですね。
フロントエンドエンジニア目線でRubyの型の話を聞いた所感
やっぱりRubyも型アノテーションや補完、コードジャンプは標準的にサポートして欲しいなと改めて思いました。 MatzのKeynoteでは、動的型付けを志向する人を「flat earth believer」、静的型付けを志向する人を「static type believer」と表現していました。
(余談ですが、飲み会に参加して、型が嫌いなRubyist数人と話した結果、型が嫌いと言っている人は、TypeScriptのジェネリクスのようなものを書きたくないっていう感じの人がいたり、「string | null」で定義しないといけないやつを「string」で定義するやつがいるから嫌だ！など様々でした。型が嫌な人の理由を聞くのが楽しかった)
私は普段フロントエンドを書いていて、型が無いと安全なコードが書けない実感があるので、Matzが言うところの「static type believer」だと思います。 Matzは型推論を頑張ることでプログラマーが型を定義しなくても済むようにしたいという例年通りの立場でしたが、エディタ上でエラーが出ないが故にRSpecをたくさん書かないといけないのもなんか違うし、型をいい感じに吐き出す機構があれば、OpenAPI嚙まさなくてもいいのになぁとしみじみ思ってしまいましたね。
おそらくRubyでコードベースを完結するモノリスのイメージなのか、自分のようにフロントエンドとバックエンドが分かれているイメージなのかで型を必要とする緊急度が違うんだろうなとも思ったり。 Ruby3.3で実装される予定のTypeProf v2でどこまで型の恩恵が受けれるのか？そして、その後でRubyコミュニティは型に対してどういったスタンスになるのか？来年のRubyKaigiが楽しみです。
おわりに
結論、参加して良かったです。 Rubyコミュニティの皆さんと再会出来たことがとても嬉しくて、次は沖縄で！なんて約束もしてしまったので、来年は会社としてもブースを出して皆さんと笑顔で再会出来ればなんて思いました。
