こんにちは。RubyKaigi 2022に参加してきました。
今年は久々のオフライン開催ということで、現地三重に行ってまいりました！
現地の様子も合わせてレポートしていきたいと思います。
会場の三重県総合文化センター！(初日は生憎の雨だったため、こちらは2日目の写真になります)
近づいてみるとRubyKaigiの看板が…
やってまいりました！
Day 1
Ruby meets WebAssembly
初回はWebAssemblyについて。
Rubyの実行環境を用意するのが大変な人にも、WebAssemblyが使えれば、かんたんにRubyを試す環境が提供できる。
デモンストレーションで実際にブラウザ上でRubyが動いたときは、会場から拍手が起きました
Webブラウザ上で動作するときは、wasmはファイルシステムもネットワークもsystem時間もないので、一部の機能をJavaScript側にサポートされて動いている。
一方で、WebAssembly自体はWEBブラウザだけのためのものでなく、他のプラットフォームでも利用される可能性がある…
ということで、WASI(WebAssembly System Interface)という、どのプラットフォームにおいても利用できるようにすシステムインターフェースが必要となる。
これらのサポートが3.2でされるようになる、というお話でした。
自分の手元でも実際に動くことを確認できました、楽しい！
https://irb-wasm.vercel.app/
Lunch Break
Making MaNy threads on Ruby
大量の並列スレッドを作るために、複数のネイティブスレッド（M)に対してRubyのスレッド（N)を作ることを目標としたMaNyプロジェクトのお話。
Ruby1.8まではRubyのスレッドはすべて1つのネイティブスレッドに対してしか作成されず、CPUが仮に複数あったと場合でも、それを活用することができませんでした。（1:N)
Ruby1.9以降は、複数のCPUが並列で活用できるようになりましたが、1:Nのときに比べてオーバーヘッドが大きくなりました。(1:1)
これを、複数CPUが活用でき、なおかつ軽量で扱いしやすくするのがM:Nスレッド…という理解です。
並列処理がかんたんにできるようになるのはすごく嬉しい。3.2は難しいかも？という話でしたが、今後が楽しみです。
Types teaches success, what will we do?
gem_rbs_collection という、gemのRBSファイルを管理するためのrepositoryの話と、それにどうcontributeしていくかを具体的な例をあげてのお話。
存じていなかったのですが、gemではなく、このようにプロジェクトのsubmoduleとして使うものだそうです。
# Add new submodule inside your project
$ git submodule add https://github.com/ruby/gem_rbs_collection.git vendor/rbs/gem_rbs_collection
型のエコシステムが浸透するのにこのように一括で管理できる便利なツールがあると導入しやすそうと感じました。一方で、各gemに型が浸透した場合、今後役割が変わっていくこともありうるのかなというのが気になりました。
Tools for Providing rich user experience in debugger
VSCodeの開発環境が充実していく一方で、そうでない人にもリッチなデバッガを提供したいというところからChrome/DevToolsをサポートしたデバッガを開発したお話。
デモンストレーションではChrome上でデバッガが、JavaScriptでイメージするDevTools上のデバッガのように動いていて、途中までエディタを見ているのかと錯覚してしまいました…。
また、VSCode上での実行も充実しており、実行ログを保存していて、ログのフィルタリングができたり、配列の値をビジュアライズしてみることができたり、機能がかなり充実していて、よい開発体験が得られそうでした。
Towards Ruby 4 JIT
JITのお話。英語だったので、あまり聞き取れた自信はないのですが…
Ruby 2.6で登場したMJITから、3.1で新しく導入されたYJITを取り入れ方、そしてRuby4では更に速度を改善してJavaやJavaScript相当にしていきたい…というお話だったと思っています。
速度を体感したい！
TRICK 2022 Returns
TRICKとはTranscendental Ruby Imbroglio Contest for rubyKaigiの略とのことで、「現世利益はない」がすごいコードが次々と…
技術力と発想力に驚き笑った1時間でした。
Day 2
Keynote
MatzによるKeynote。
RubyへできるContributionと、3.2の主な特徴について。
今年も無事「Rubyは死んだ」を聞くことができました。
ruby/debug - The best investment for your productivity
デバッグツール ruby/debug について。
使い方はいくつかありますが、byebugやpryのように、binding.breakという文言をソースコードに差し込むことでデバッグが可能です。
byebugの機能は一通り網羅していて、なおかつcolorizedされていたり、Backtraceで引数がチェックできる、リモートデバッグがしやすいなどの長所があります。
Rubyのコアチームにメンテナンスされていて、一方でbyebugの開発頻度は現状高くないため、該当するバージョンを使えるなら、移行しない理由は今の所ないのかなと思いました。
Make RuboCop super fast
Rubocop2に向けて、開発体験を向上させるための速度改善について。
速度改善はいろんな方針があるが、Deamonizeが今回のメインで、これを行うとかなり早くなる。(850倍だったと思います)
もととなっているのは rubocop-daemon という3rd party gemで、これが速い理由としては、Client/Server modelを採用していて、Serverの方でmoduleを読み込んでおくので、ロードを毎回する必要がない、ということのようです。
rubocop --serverでサーバが立ち上がるようになっていて、ただまだ期待していない動きをすることもあるので、 そういうときはrubocop --server-restart してねとのこと。
とりあえず rubocop --server と rubocop --server-restartを覚えました。
Lunch Break
Method-based JIT compilation by transpiling to Julia
MJITやYJITを使っても速くならないケースがあり、それにどう対応していくかのお話。
Pythonでも似たような問題を抱えており、NumbaというJITでの解決法が、2つのJIT mode（Object mode/nopython mode）のうち、nopython modeを採用するというもの。
（きちんとした理解かわからないですが、動的言語故に何度も型を確認する必要があるところを、型をある程度固定して扱うことで、処理を早くしているという話かと理解しました）
このNumbaに相当するものをRubyに採用し、なおかつ処理の速いJuliaに任せることで、高速化を図ります。
実際の実行結果として、どの結果も数msかかっていたところが数μsになっていたため、かなり速くなっているようでした。
ただ、配列は変換の際にオーバヘッドがあるのと、動的であるというRubyの特徴とどう付き合っていくかが今後の課題のようでした。
How fast really is Ruby 3.x?
Ruby3ではRuby2より速度を3倍速くするというスローガン(Ruby3x3)があり、それが本当に達成されたのか？をアプリケーション側から検証するお話。
アプリケーションはログ収集で有名なFluentdであり、また過去のバージョンはスナップショットとして取ってあるため、テスト環境としては十分。
スループットを2.7と3.2で比較したところ、たしかに3倍になっているとのこと。
一方で、他の言語と同様の処理をしたとき、どれが一番早いの？という話で、Python, Lua, Perlなどと比較したクイズが出題され、
この話であればRubyもそこそこ速いのかな？という安易な予想をしてしまいましたが、期待を裏切ってRubyは3.2のYJITを利用した場合であっても他の言語より遅く、まだ他の言語と比べて速いとは言えないという結論でした。
Packet analysis with mruby on Wireshark - dRuby as example
Wiresharkというネットワークパケットアナライザで、対象でないプロトコルの解析をするにはどうすれば？というところから、WiresharkのdessectorをRubyで作るお話。
Wiresharkが公式にdessectorの環境として提供しているのはCとLuaのみであり、これをRubyで実装するために自分のための拡張Wiresharkを作られたとのこと。
この回、実は現地では配信が途中で止まってしまうなどのトラブルに見舞われていたのですが、現地の方の機転で待機時間に質疑応答があったりと、最後までセッションを楽しむことができました。
運営の方及び発表者の方、お疲れさまでした。
Create my own search engine
ポケモンカードの類似デッキを表示するサイトで検索エンジンを作成する話。
デッキの類似度と自然言語テキストは似ている、と考えたところから、自然言語処理と似た処理が適用できると考え、適用していくお話が面白かったです。
あまりポケモンカードに詳しくないのですが、基本エネルギーカードが1つのデッキにいくつも入れられるせいで、類似度に強く影響しすぎてしまう…という特有の問題があるのを知り、ちょっと興味深かったです。
Ruby Committers vs The World
RubyのCommittersが一同に集まって壇上でディスカッションする貴重な場。一人ひとりの思い描くRubyの"future"が紹介されていました。
Day 3
error_highlight: user-friendly error diagnostics
3.1にあったerror_hightlightという機能がどのように改善されたのか？のお話。
- カバーするエラークラスが広くなった
- Exception#messageをoverwriteして複数行にしてしまうと発生する諸々の問題について対応するために、新しくException#detailed_messageを作成した
- エラー箇所にフォーカスするための表示(
^^^^となっている箇所)が本来のエラー箇所とずれてしまう問題
実装はすぐ終わったのに解決に至るまでの論拠を探すところで1ヶ月かかったエスケープをやめる話が興味深かったです…。
RBS generation framework using Rack architecture
型をありふれた状態にするために、RBSの型ファイルを自動生成をしたい、というお話。
コード実行時に解析すれば、正確な型を得ることができるため、RackのMiddlewareとしてその機能を作成すればうまくいきそうと考え、
Rackのアーキテクチャを参考にし、Orthousesという自動生成ツールを作ったとのこと。
細かくカスタムできるようで、今後の活用法が広がりそうだと思いました。
Let's collect type info during Ruby running and automaticall
先程聞いたセッションと同じく、RBSの型ファイルの自動生成のお話。
こちらも、静的解析ではなく、動的解析での自動生成で、rbs-dynamic というgemを入れて作成が可能とのこと。
こちらはcliでRBSが作成できるようで、導入自体の難易度が低く、また動的解析ということで精度がより高いものが得られそうだと思いました。
Why is building the Ruby environment hard?
"環境構築マニア"の方がこれまで出会った、周りの人が苦労しているビルドエラーの具体例についてのお話。
- Ubuntu22.04でOpenSSL3.0のみ提供されるようになったことが起因してRubyの2.6のビルドができない
- Ruby2.6や2.5のビルド時にfiddleでエラー
- macOS13.0 (Ventura)でビルドができない
- mysql2がビルドできない(mysql_configが見つからない)
- mysql2がビルドできない(libsslとlibzstdでリンクエラー)
想像していたよりかなり具体的な話で、特にmysql2のビルドエラーは私もよく遭遇するものでした。
「ソフトウェアは何もしないと壊れる」
Lunch Break
The Better RuboCop World to enjoy Ruby
よりよくRuboCopを使っていこう、そのためにはどうしたら？という観点でのお話で、Rubyを利用している開発者としてかなり身近に感じました。
RuboCopは開発者の状況に関わらず一貫してルールに反したものを違反とするので、デフォルトで利用していると、RuboCopの制約をかなり受けることになる。RuboCopでどのCopを適用するかを各組織で検討すると、その水準はだいぶマシになるものの、全てのCopを見直して決めていくことは各組織や開発者にとって、かなり負担になりうる…
なので、Copに強制/参考に分けて、参考レベルには違反を出さないことで、これらの問題が解決されるのでは？という提案でした。
個人的には、このルールを守るとどんな恩恵が受けられるか、どういう背景で生まれたものなのか、というCopを採用した理由が知りたいと思うことが多いです。それであれば、知らない人はただただ従うでなく参考になるし、仮に組織でどれを採用すべきかを検討する際にも話がしやすいと思っています。
Fast data processing with Ruby and Apache Arrow
Rubyのデータ処理は残念ながら速いとは言えず、その問題にどう対処していくか？を、Cross-language dev platform for dataとしてApache Arrowで解決していこうとする視点でのお話。
String Meets Encoding
前回のRubyKaigi Takeout 2021セッション後に、twitterでとある機能を改善してほしいという声から、CSV.readの高速化を始めたお話。
Stackprofでの計測から始まり、結果から推測してC実装へさらに深ぼっていく調査から、最終的に1.4倍の効果を得るに至ったまでの過程を詳しくお聞きすることができました。
問題解決に至るプロセスが明快で、聞いていてとても楽しかったです。
終わり
今回私が聞いたセッションは以上でした。
カンファレンス楽しいですね。問題解決に至るプロセスが聞けるのが楽しいし、一方で知らないことやわからないこと、忘れていることとても多いのですが、そういうのを振り返るきっかけにもなりました。
また、オフラインで現地の空気を味わえたのもよかったです。近年の難しい時勢の中、オフライン開催まで漕ぎ着けた運営の方に感謝致します。
全体的に型の話が印象的で、型を導入したけどまだ活用するに至っていないRuby開発者が多い中、どうやってもっとよい体験として型を提供できるか？に苦心されている印象でした。
また、個人的な話ですが、この一年英語の勉強をしてきたつもりだったのに、英語のセッションを聞けるようになるという目標がほとんど達成できなかったことが反省点でした…。
また来年に向けて精進していきたいと思います。