こんにちは。転職ドラフトでエンジニアをしている伊藤（verdy_266）です。
リブセンスではほとんどのプロダクトが Ruby を使って実装されています。今回、 RubyKaigi がオフライン開催されるということで、エンジニアの有志で参加してきました。
この記事では、RubyKaigi に参加したエンジニアでセッションの振り返りを行った模様をお伝えします。転職ドラフトでブースを運営した話についてはこちらをご覧ください。
今回参加したエンジニアは、以下の6名です。
マッハバイト：ayumu838, kimihiro031
転職ドラフト：iwtn, yamitani, yk, verdy_266
実務に直結する話から超絶技巧の話まで
verdy_266：
今回のセッションで印象に残ったものを挙げるとしたら何になりますか？
yamitani：
私は実務直結ということで debug gem 関連の話をあげたいと思います。
グラフ表示とかはまだリリースされていないものになりますが、デモがキャッチーでテンション上がりましたね。debug gem の知識がアップデートされたのも収穫で、実務で使ってなかったので使おうと思いました。
iwtn：
デモがキャッチーという点で Wasm の話もよかったですね。
Ruby は今までバックエンドが中心だったと思うんですが、Wasm 対応によってフロントも書ける可能性が高まりそうだなと感じました。フロントやUIを作るのが好きな私にとってはとても嬉しい変化です。
実際にはバイナリが重い問題が解決されたり、React や Vue.js みたいなフロントエンド用のライブラリが出てきたりしないと実用には耐えないと思いますが、そのレベルに至るまでの第一歩になりそうですね。
スライドはこちらから: Ruby meets WebAssembly - Speaker Deck
yk：
インストーラーを用意せずとも手軽に実行できるようになるのは非常に大きいですよね。私は Windows からプログラミングに入門しているので、インストーラーをダウンロードしなきゃとか、インストーラーが古くなっててうまくインストールできないとかで非常に苦労した記憶があります。
yamitani：
Cookpad さんがブースで出題していた Code Puzzle が実例として分かりやすいですよね。
まだ10問目までしか解いてないですが、 Ruby の言語仕様を学ぶ上で必要な内容が段階的に出てくるので、とても良い問題だなと思いました。
ruby-puzzles-2022.cookpad.tech
yk：
あれは面白すぎて時間が溶けるのが玉に瑕ですね笑 5分だけやろうと思ったら30分やってました笑
kimihiro031：
僕は Ruby のビルドの話が印象に残っています。
環境構築が大変な事例について扱っている話だったんですが、ちょうど今 Ruby のバージョンアップに取り組んでいるので、とても理解が深まりました。
「ソフトウェアは何もしないと壊れる」という最後のスライドがとても刺さりましたね。エンジニアでない人にもアップデートの重要性をわかりやすく伝えられる名言だなと思いました。
ayumu838：
このスライド、ネット上でも話題になってましたよね。
verdy_266：
僕はやっぱり TRICK が印象的でした。
和訳すると「超絶技巧 Ruby 意味不明コンテスト」となるだけあって何をしているのかさっぱりわからなかったのですが笑、これが Ruby だけで書かれているという驚きがすごかったですね。ソースコードと出力結果が同じになっている作品が多くて、面白いなあと思いました。
kimihiro031：
提出された作品を解読できる審査員がすごいなあと思ってみてました笑
yk：
金魚鉢の作品とか、あれだけ空白があっても誤り訂正でなんとかなるのすごいですよね笑
作品を見てもやってみようという気持ちにならないのがすごい笑 めちゃくちゃ時間かかってそうですよね。
ayumu838：
誤り訂正とか学生の頃勉強したのが懐かしかったです。
verdy_266：
学生の頃が懐かしいといえば、ポケモンカードの話も面白かったですね。デッキを検索したり、 diff をとったりすることのできるアプリケーションの話でした。
tf-idf とか久しぶりに聞いたし、疎なベクトルの保存形式を工夫して内積を簡単に計算できるようにしていたのも面白かったです。
kimihiro031：
何より楽しそうでしたね。ポケカの説明が長かった笑
verdy_266：
あれだけ細かく前提を話してくれる発表大好きです笑
たくさんのツールにお世話になっています
yk：
私が気になったのは Apache Arrow の話ですかね。
機械学習や科学計算の周辺では、内部実装が Ruby になっている Ruby は Cの実装が使える Python にどうしても勝てないんですよね。その辺りをサポートしてくれるツールの話です。
便利なツールという観点だと、 error_highlight もすごいなあと思いました。
エラーの場所まで特定してくれるのはとても利便性が高いですよね。エラーの箇所がピンポイントで把握できるようにするための細かい配慮もたくさんなされているようでした。
まだ一部のエラーにしか対応できていないようなのですが、今後をとても楽しみにしています。
verdy_266：
今後が楽しみといえば、ブロックの仮引数として _1 を使うのか it を使うのかという話もありましたね。
yk：
_1 が優勢になってたのはよくないですよね笑
_ って普通捨てる変数のためにあるものだし、「名前重要」って言ってるのに順番で決まる変数を使うのもよくないと思います。
k0kubun さんが「2個以上だったら名前をつけましょうよ」と言っていて、本当に正しいなあと思って聞いていました。
「俺たちでもできそう」感があるとモチベ上がりますよね
ayumu838：
僕は String#split の最適化の話ですかね。
発表ではパフォーマンス分析の方法から具体的に扱われていたため、自分でもパフォーマンス改善できそう感があってとてもモチベーションが上がりましたね。
iwtn：
これ、後日談が記事になってましたよね。RubyKaigi の1週間前まで速度改善できていなかったとか。
yk：
当日、「できませんでした！」っていう発表をするのでも全然アリですよね。こういうこと調べましたって共有するだけでも価値がありますからね。
iwtn：
発表者の方もプロポーザル出した時点でC言語が読めなかったそうですからね。勇気をもらった発表でしたね。
kimihiro031：
「俺たちでもできそう」といえば、gem_rbs_collection の話もよかったですね。
Ruby の型については周辺が整っていないので茨の道なんだなあと思わされましたが、コントリビューションの方法まで丁寧に解説されていたので、自分にもできそうと思いました。
iwtn：
Matz のキーノートでも「みんなの力が必要」とありましたが、勇気を与えてくれる発表は本当に価値がありますね。
僕はコロナ禍入社ということもありオフラインのカンファレンスは初めてだったのですが、セッションも企業ブースもかなり楽しくて、オフラインのありがたみをすごく感じていました。
難しい内容だらけだろうし行く意味ないだろうなあなどと思っていた時期もあったのですが、とても刺激になりましたし参加を決断して良かったと思いました。
RubyKaigi2023 は 5/11-13 に松本で開催されるようですね！ また次回の RubyKaigi でお会いしましょう！
