ENECHANGE Developer Blog

ENECHANGE開発者ブログ

RubyKaigi 2023 に参加してきました!

ENECHANGE の小野と酒井です。
今年も ENECHANGE は2023年5月11日〜5月13日に開催された「RubyKaigi 2023」に、ゴールドスポンサーとして協賛しました!
そして RubyKaigi 2023 に我々を含め、弊社のメンバーも何人か参加してきました!

ENECHANGE は RubyKaigi 2023 に、ゴールドスポンサーとして協賛しました!

会場は長野県松本市にある、まつもと市民芸術館でした。

まつもと市民芸術館の階段付近

というわけで、今年の RubyKaigi で興味深いと思った内容や、感想について、書いていきたいと思います。

Matz Keynote

Rubyの生みの親、まつもとゆきひろ氏のキーノートで幕を開けました。
Rubyが生まれてから今まで、そしてこれからのことを教訓を交えてお話されていました。
そこでの話の中において、Rubyの型システムについての展望が興味深かったです。
静的型付けによる安全なプログラミングが現在のメインストリームになりつつありますが、Rubyは動的型付け言語のまま進んでいます。
実際にChatGPTにコードを読ませてみたところ型の推論ができているのだから、静的型付けだけが安全な型運用ではないはずだという主張をされていました。

Make Regexp#match much faster

Hiroya FUJINAMI さんの発表

Regexpの正規表現マッチングを高速化したというお話をされていました。

Ruby3.1まででは、ある条件を満たす正規表現をマッチングさせようとすると、処理時間が指数関数的に増加してしまう問題がありました。 その脆弱性を利用したReDoSという攻撃手法が存在します。 DoS攻撃の正規表現利用バージョンみたいなもので、アプリケーションに負荷をかけて利用不能に陥らせます。 実際この攻撃によりCloudFlareが27分間のダウン状態に陥った過去があるそうです。

Ruby3.2ではこれを改善させました。 今までは条件によっては検査して引き返してまた検査してというバックトラック処理が走り、インプット量に応じて指数関数的に処理時間が増えるケースがありました。 それに対して、メモ化という手法を使うことで一度実行した検査をスキップするようにし処理時間の削減に成功したとのことです。 今までかかっていた処理時間を削減することで、ReDoSを無効化することに成功しました。

とはいえ、全ての正規表現マッチングが解決したわけではないとのことです。

Regexp.linear_time?というメソッドで正規表現の処理時間が線形になるかどうか確認できるので、こちらがtrueになるかどうかで使用の判断をすると良いとのことでした。

脆弱性対応を目の当たりにし、感謝の気持ちでいっぱいになりました。

Power up you REPL life with types

codeTaktのCTO、石田智也さんの発表です。

石田さんは、 irb の自動補完機能を強化するGemである、 katakata_irb を開発されました。 irb はサジェストされるメソッドが不完全であったり、メソッドチェーンの呼び出しで補完が動かないといった問題があります。
katakata_irb を使うと、そのような問題が解消され、補完機能が強化されます。

詳しい使い方や導入方法はこちらの記事が参考になりました。
katakata_irb を導入してみた | Webシステム開発/教育ソリューションのタイムインターメディア

rails console の入力補完機能も強化されるということで、結構役立つ場面が多いかもしれません。気になった方は、ぜひインストールして使ってみてください。

Introduction of new features for VS Code debugging

サイバーエージェントのNaoto Ono さんの発表

debuggerを使ってコードリーディングする際の辛さを解決するためのソリューションについてお話ししていました。 trace inspectorというものを作成されまして、これによりデバッグ体験が改善するということです。 具体的には、あるメソッド内で呼ばれている別メソッドをツリービューで直感的にわかるようにしたというもの。 メソッド内で別メソッドが呼ばれ、さらにその中で別メソッドが呼ばれ、、、 「あれ、今見てるメソッドってどこから呼ばれてたっけ」みたいなことはよくあると思うのですが、trace inspectorはそれをツリー構造で表示してくれるので直感的にわかりやすいのです。

また VS Code Debug Visualizer というツールについても説明されていました。 こちらは情報を視覚的に表現することのできるものです。 例えば配列をグラフ化することができます。 あと個人的に使ってみたいと思ったのは、ActiveRecordの中身を表形式で表示できる機能です。 デバッグの際、binding.pryで一旦止めてActiveRecordの中身を見る、という作業をよくやるのですが、こちらはその手間がなくなるし視認性がかなり高まります。

Optimizing YJIT’s Performance, from Inception to Production

ShopifyでYJITの開発リーダーをしている Maxime Chevalier-Boisvert さんの発表です。

今年のRubyKaigiは、JITに関する話題が多かったのが印象的でした。他のセッションでもたびたび取り上げられていました。

YJITとは、Rubyを高速化するための技術の1つです。YJITが本番で使えるレベルに達したことで、ShopifyやTimeeなどで実際に本番環境でYJITが使われるようになりました。それにより10%程度のパフォーマンス向上を実現できたらしいです。

参考記事:
RubyのYJITコンパイラをShopifyが本番に投入、Railsアプリを高速化。Rubyも本格的にJITの時代へ
Ruby 3.2+YJIT 本番運用カンパニーになりました #rubykaigi - Timee Product Team Blog

このセッションでは、YJITを本番環境で動かせる状態にまで引き上げることができた経緯やプロセスについて詳しく説明されました。YJIT-Bench というRubyのベンチマークができるツールを用い、検証を繰り返しながらYJITのチューニングをしていったという内容でした。

正直、英語かつ内容も複雑だったのもあり、全部は理解できなかったのですが、YJITを開発するためにかなりの労力を費やしたことが伝わり、新しい技術を作る方々は本当にすごいなと思うとともに、感謝の気持ちでいっぱいになりました。ENECHANGEのプロダクトにも、YJITを導入することを検討してみたいと思います。

Build Your Own SQLite3

Monstar LabのHitoshi HASUMI さんの発表

まずSQLite3について説明されていました。 SQLite3は小さいリソースで使える割にはパフォーマンスが良いとされており、カーナビやモバイルアプリ、ブラウザのローカルDBやone-chipマイコンで使われているとのことです。

次にPicoRubyについて説明されていました。 PicoRubyは発表者のHitoshi MASUMIさんご自身が作成されており、マイコン上で実行できるとのことです。

その上で、マイコンでPicoRubyを操作してSQLite3を使用したデータベース操作のデモンストレーションが行われました。 まずマイコンにSDカードをマウントし、SQLiteでデータベースの作成・書き込みを実行。 その後SDカードをPCにマウントし、先ほど作成したデータを読み込む様子を見せていただきました。

マイコンの写真

画像が荒くて恐縮ですが、使用したマイコンはこんなにシンプルで小さなもの。 そこでデータベースを操作できる様子は大変興味深かったです。

続いて、打鍵ログをキーボード自体が取るというデモも見せていただきました。 キーボード自身がSQLite3で打鍵のデータを蓄積するという離れ業を披露されていました。 打鍵のデータを解析することで、最適なキーマップを導き出すことができるとのことで、HASUMIさんご自身の期待としてはr,u,b,yが多いのでは!とのことでしたが、結果はh,j,k,lが多かったです。

そう、HSUMIさんはvimerなのでカーソル移動に使う4文字が一番多いという、考えてみれば当然というオチでした(笑)

Load gem from browser

Shigeru Nakajima さんの発表です。

ruby.wasm の登場により、ブラウザでRubyを実行することができるようになりました。しかし、現在 ruby.wasm でgemを使おうとすると、標準のgemのみ使用可能で、サードパーティのgemを使うことができません。そこでこのセッションでは、ブラウザ上でサードパーティgemを使えるようにする取り組みについて説明されました。

どういうアイデアでgemを使えるようにするのか詳しく説明されたのですが、簡単に言うと、JavaScript の import-maps を ruby.wasm でも使えるようにするというものでした。そして現在の状況としては、まだ実装途中であるものの、相対パスでのインポートが一部機能するようになっているなど、着実に実現に向かって近づいていました。

もしこれが実現したら、フロントエンドを Ruby で書くという選択肢も考えられるようになるので、非常にワクワクしますし、 ruby.wasm が今後どうなっていくのかをウォッチしていこうと思いました。そして、こういう方のおかげで新しい技術が活発化していくんだろうなと思いました。

Nakajima さんが発表時に使用した資料を公開してくださっていますので、詳しく知りたい方はこちらの資料をご覧ください。

speakerdeck.com

全体を振り返って(小野)

思っていたよりも難しい内容が多く、英語での発表も多かったのもあり、正直2-3割程度しか理解できなかったと思います…
ただ、内容的にはまじめな話もあれば、キックボクシングマシンをRubyで動かすみたいな面白い話もあったので、飽きることなく最後まで楽しめました。
そして今回、 JIT や ReDoS についての話題が多く、色んな方が Ruby をより良いものにしていこうと頑張っていて、そのおかげで我々は快適に開発できているんだなと思い、感謝の気持ちでいっぱいになりました。
今後は、少しでも話についていけるように、コンピュータサイエンスなどの知識を深めていこうと思いました。

全体を振り返って(酒井)

まずもって全体的に超難しかったです(笑)
自分はWebエンジニアとして普段Ruby on Railsを触っていますが、RubyKaigiではRubyの根源的な題目が大半を占めていて、普段は触れない技術の話題が降り注ぐ3日間でした。
でも難しいから辛いという訳ではなく、日頃の自分の開発体験を向上させてくださる皆さんに畏敬の念を抱くと共に、自分も頑張ろうという前向きな気持ちになれました。
あとはカンファレンス後に行われるイベントで多くのRubyinstと交流することができ、とても楽しかったです。
Rubyコミュニティーの一員として、私も日々邁進してまいります!

おまけ(小野)

2日目の RubyKaigi終了後のイベント、 Agileware Drinkup at RubyKaigi 2023 でLTをしてきました!
内容は、「WebAssembly で 世界最速の数独ソルバーを作った話」です。
LT終わった後で色んな方から話しかけられたり、LTした人同士で色々話したりなど、貴重な経験ができて楽しかったです!

発表の様子

資料はこちら
speakerdeck.com

解説記事
Rust + WebAssembly で、世界最速の数独ソルバーを作った話 [bitboard] - Qiita