リブセンスでは転職ドラフト、マッハバイト、転職会議など多くのプロダクトでRubyを利用しています。
今年もリブセンスエンジニア有志がRubyKaigi2024に参加してきました。この記事では、参加したエンジニアたちの振り返りの様子をお伝えします。
昨年の記事はこちらです。
おととしの記事はこちら。
参加したエンジニアは以下6名です
- 赤坂：技術部エンジニア
- 伊藤、岩田：転職ドラフトエンジニア
- 今井、村山、望月：マッハバイトエンジニア
印象にのこったセッション
赤坂：どのセッションが印象に残りましたか？
Writing Weird Code
伊藤：キーノートセッションはびっくりしました。国際通りのディスプレイにRubyKaigiの広告動画が流れているのは知っていましたが、あれ自体がQuineで作られているとは……
赤坂：正規表現で連立方程式を解く、とかRubyとして実行できるビットマップ画像とか、ちょっと想像できないようなコードが沢山あって興味深かったですね。ビットマップ画像が実際に実行されアニメーションが動き出したときは会場は拍手喝采で、「ハッカーのお祭りに来たな」と楽しくなったことを覚えています。
Optimizing Ruby: Building an Always-On Production Profiler
望月：Datadogの英語の発表は割と印象に残っています。その中で一番衝撃だったのは、ブランチを全部とってくるという処理があって、ブランチが5000くらいあるらしいんですね。それで不要なブランチを全部消したと。
Unlocking Potential of Property Based Testing with Ractor
岩田：私はRactorの発表です。Property Based Testing という手法にも興味があって、そちらの解説も序盤にされて参考になりました。そのPBTの性質を踏まえて、テストを実行したときに何回も試行することになり、そこをRactorで並列化したら良いんじゃないか、というアイディアをセッションの最初で聞いて、確かに効果がありそうだなと。
今井：結局Ractor使って早くなるのはCPU boundな一部のケースで、他はむしろ遅くなる、みたいな話をされていました。オプションでオフにしている、というお話でしたね。
Long journey of Ruby standard library
岩田：標準ライブラリの話も印象に残っています。コミュニティのコントリビュート能力を高めるためにbundledとdefaultライブラリを分けた経緯などの話がわかりやすかったです。セキュリティ観点でも問題のあるgemが発生したときにRuby本体にgemが入っているとRuby全体をアップデートする必要がある。それを避けるために分離しているとのことで、そういう観点もあるのかと、一石二鳥という感じで勉強になりました。
赤坂：サステナビリティの観点でbundled gemsを分けている、という話もありましたね。Rubyにコミットする人をなるべく増やしたいという気持ちがあると。
An adventure of Happy Eyeballs
伊藤：塩井さんの発表もわかりやすかったですね。Happy Eyeballs とは何か、という話から始まって「できました」→「いやそんなに簡単ではない」みたいな話の流れもわかりやすかった。
RubyGems on ruby.wasm
望月：wasmの話はどうだった？
今井：gemをbundleできるように、という話だった。
赤坂：C拡張のGemも含め、gemをwasmで動かせるようにした、ということでした。C拡張のGemをクロスコンパイルするためにmkmf（拡張ライブラリを作るためのライブラリ）にオプションを追加したり、ビルドシステムの深いところまで改変する必要があったと。
今井：C言語の話といった印象を受けました。かなり込み入った話でしたね。
CSの知識と英語
赤坂：RubyKaigiといえば、毎年英語のことが話題に上がります。今年は英語のセッションに参加されましたか？
伊藤：どうしても日本語セッションを優先して聞きたくなりますね。
村山：2日目のお昼開けは全部英語で、ちょっとつらかったですね。
赤坂：個人的には英語よりはコンピュータサイエンスや低レイヤの知識が話を理解する上でのボトルネックになっている、という気がしました。
望月：コンパイラやJITなど。
今井：ドメインや実装についての知識がないとわからないことも多い。コミッターの人でもわからないこともあるのでは。
望月：JITの話とか継続的に触れていると、少しは何を言っているのかわかるようになってきた。
岩田：今井さんと赤坂さんは今年が初参加ですよね。毎年参加していると、強弱はあれど話題は似ているなということがわかってきます。継続は大事。
望月：英語がわかりやすい人と言うよりはわかっている分野を聞いた方がいいのではないかと思います。自分は英語のセッションでは字幕を必死に読んでいました。
Matzのキーノート
赤坂：Matzのキーノートはどうでしたか？
岩田：パフォーマンスの話を聞いて、「ハッカーになろう」を思い出しました。
C はとても高効率ですし、マシンのリソースもドカ食いしません。残念ながら、C がそれだけの効率性を実現するには、あなた自身が低レベルのリソース管理（たとえばメモリ管理）を手作業でやってあげなくてはならないのです。それだけ低レベルコードがあると、複雑でバグも起こりやすいし、デバッグですさまじい時間をとられることになります。今日のマシンはずいぶん強力になっているので、これは通常は悪いトレードオフです――マシンの時間を少し非効率に使っても、自分の時間をずっと効率的に使う言語を使うほうが賢明でしょう。
岩田：RubyはLL（軽量言語）なので人間の生産性は良くなる。一方で実現する機能に対する計算機のパフォーマンスも考える必要がある、という話をしていてそこまで考えるのか、と思いました。PerlやPythonの話がキーノートで出たと思いますが、「ハッカーになろう」にも上の文章の続きに、以下のような文章があります。
他に特に大事な言語としては、それ以外に Perl と LISP があります。Perl は実用的な意味からも勉強しておく価値があります。アクティブ Web ページやシステム管理にとても広く使われているからです。自分では Perl を使わなくても、読めるようにはなっておきましょう。多くの人は、わたしが Python 利用を奨めるのと同じ形で Perl を使います。つまり、C のマシン効率を必要しないような仕事で C プログラミングを避けるために使うわけです。そういう人たちのコードを理解できなくてはなりません。
※原文ママ
岩田：私達がやっているWebアプリケーションは、まさしく「C のマシン効率を必要としないような仕事で C プログラミングを避けるために使う」だったはずなんですが、その仕事で使う言語でもマシン効率を意識し始めている、というのが面白かったですね。
来年はMatz山
赤坂：来年は松山ということで、また楽しみですね。
岩田：毎回一定の規模の地方都市か、近くに観光名所があるところが会場になるので、松山だと会場はもちろんですが道後温泉あたりとの距離感を考えつつ、宿をとりたいですね。今回、会場と宿が近かったので、昼にちょっと帰って休んだりもできたので、とても便利でしたし。
また、松山には路面電車があるらしいので、個人的にはそこもとても楽しみです。東京だと地下鉄ばかりで、街を見ながら移動するということが難しいので、そういう景観も楽しめればな、と思っています。もちろんRubyKaigiでRubyの進化の様子を聞くのも楽しみですがｗ
村山：RubyKaigiには魅力的なセッションが多くある一方で、英語のセッションには壁を感じてしまいます。また、アフターパーティーなどで外国エンジニアの方に話しかけていただけても十分な交流ができないのは不甲斐ないな、と思ってしまいました。
ただ今回は「Cross-platform mruby on Sega Dreamcast and Nintendo Wii」のような視覚的にも楽しめるセッションは楽しかったし印象的でした。
さいごに
私（赤坂）は今回のRubyKaigiが初参加でしたが、想像以上に盛り上がっていて、驚きました。コミッターの皆さんに対するリスペクトを感じると同時に、コントリビュートの間口は広い、そういう懐の深さを感じるよい経験になりました。来年のRubyKaigiも楽しみですね。
