はじめに
ブルーモ証券でエンジニアをしている才記です。
普段は Ruby on Rails でブルーモのバックエンド開発を主にやっています。
4月16日、待ちに待った RubyKaigi 2025 が開幕しました！
年に一度の Ruby のお祭り、楽しみにしていた方も多いのではないかと思います。
かくいう私も楽しみにしていた一人です。
今回は Kaigi の様子や活気をいち早くお届けするため、速報記事という形で現地の様子をお伝えしようと思います！
（現在、ブルーモ公式技術ブログの準備中のため、暫定的に私個人の記事になっています。後ほど会社の技術ブログ記事として移動する予定です。）
ブルーモと RubyKaigi
お気づきの方も居るかと思いますが、ブルーモ証券は今回の RubyKaigi 2025 で Silver Sponser をしています！
また、弊社からはCTO 小林と私の2名が参加していますので、
会場で見つけた際はお気軽にお声がけください！
セッション紹介 Day1
さて、というわけで早速 Day1 のセッションハイライトの方を紹介していきたいと思います。
私の独断と偏見で、気になったり面白かったりしたセッションを紹介していきます。ご了承ください。
Ruby Taught Me About Encoding Under the Hood
最初はやはり @ima1zumi さんの JA Keynote, Ruby Taught Me About Encoding Under the Hood から。
@ima1zumi さんはここ数年 RubyKaigi でエンコーディングの話で継続的に発表されている方というイメージなのですが、
今回 JA Keynote として一発目の発表をされるのを知って少し感動してしまったところがあります。
（全然 @ima1zumi さんと面識はないのですが…）
さて、トークの内容の方ですが、タイトルの通り「Ruby が教えてくれた文字コードの奥深い世界」という話でした。
そもそも文字コードとはなんぞや、コンピュータ以前（何なら電気のない時代）の歴史の話に始まり、
メインフレーム、COBOL、EBCDIC…などなど、普段 Ruby を書いていたらまず触れることのない内容が盛りだくさんでした。
文字コード周りの話も、なんとなく知ってはいるものの細かい仕様や Ruby 内部での取り扱い、バージョンアップ方法など、
これまた普段触っているだけではなかなか知ることのできない内容が多く、非常に聞いていて面白く、ためになりました。
合字概念、なんとなく知ってると思っていたのですが、日本語の「ぶ」とかもできるんですね…知らなかった…
Ruby と文字コードの深い話という点でも興味深く、とてもいい発表だったのですが、自身の経験に基づいて
「自分がワクワクできる何かを RubyKaigi で見つけて、楽しんで欲しい」と締め括っていたのがとても良いなと思いました。
Goodbye fat gem 2025
続いて @ktou さんの Goodbye fat gem 2025。
そもそも fat gem とは？という話があるかと思うのですが、これは「ビルド済みバイナリ入りの gem」ということだそうです（単にデカい gem のことなのかと思ったら違った）。
Ruby だと、手元環境で依存ライブラリをビルドしようとして謎エラーで失敗する、みたいなことに遭遇した経験のある方は多いかと思います。
fat gem だと手元で依存ライブラリをビルドしなくていいのでその分利用者的には楽なのですが、
その楽さの代償として gem のメンテナの負担が増えてしまう、という。
（脆弱性対応だったり、クロスコンパイルがめんどくさかったり、最新の Ruby への迅速な追従を求められたり）
gem のメンテナの負担が増えるのはエコシステム的にはよろしくないので、
できれば fat gem をやめて手元ビルドで済む世界を広げたほうが良いのでは？という提言でした。
自分はこれまであまり fat gem という概念を気にしたことがなかったのですが、興味深い発表でした。
1ユーザとしては、ビルド時に依存ライブラリ関連でエラー吐いて動かないやつにハマると非常に面倒なので、 fat gem の有り難さはよく分かってしまうところがあります。
が、それによって gem 開発者の負担がそんなに増えているというのは知らなかったので、
それであれば手元環境でのビルドを手軽にできる方向になると確かに良さそうだなとも思ったり。なかなか難しい問題。個人的には fat gem 脱却方向に協力したい気持ち。
Automatically generating types by running tests
お次は @sinsoku_listy さんの Automatically generating types by running tests。
ここ数年で RBS 周りはかなり進歩してきている…ものの、実際に活用、運用できている例はどれぐらいあるんでしょうか…？
弊社でも入れてはいるものの、運用体制がしっかり整備はできておらず、あまり活かせていないというのが正直なところです。
テスト実行時に型を生成するアプローチは以前の RubyKaigi でも聞いたことがあるような気はしつつ、実際の方法はあんまり見かけたことがなかったので聴講しに行きました。
内容としては rbs-trace gem の紹介という感じ。
テストの実行前にトレース処理を仕込んでおき、 save_comments をやると型を勝手に挿入してくれるという感じ。便利。
実際にいくつかの Rails App で使ってみた感じではある程度妥当な型が生成できていたとのこと。
とはいえ常に動かすにはテストパフォーマンスの劣化がそこそこあるので、必要なときだけピンポイントで動かすのが良さそうです。timee や mov の例だとだいたい 1.5 倍弱ぐらい遅くなったとのこと。
遅くはなるものの得られるものを考えたら許容できるものな気はします。
テストがしっかりと書かれている、という前提条件があるものの、それさえ満たしていればかなり手軽に型定義が手に入るので、これはぜひ使ってみたいところ。
余談ですが、最近弊社内では AI をうまく活用するにはどうするのが良いか、という話が活発に行われているのですが、
そこで「テストをドキュメント的に整備して、それを AI に読ませてタスクをこなしてもらうとよいのでは？」という話がありました。TDD ですね。
こちらの型定義も似たようなところがあるというか、テストがあることを前提としているのであれば、TDD 的な開発手法との相性が良さそうです。
あまり最近ちゃんと TDD できていないのですが、今一度テスト駆動的な開発に立ち返ってみたいと思いました。
TRICK 2025: Episode I
最後はみんな大好き TRICK。ある意味最も RubyKaigi らしい時間だと思っています（個人の感想です）。タイトルの Episode I とはいったい…
そもそも TRICK とは？と思われる型もいらっしゃるかと思うのですが、すごくざっくり言うと「超絶技巧Rubyコードコンテスト」みたいな感じです。
興味のある方は昨年の RubyKaigi 2024 でキーノート講演をされた @tompng さんの記事もぜひご覧になってみてください。
今年も訳がわからない Ruby コードだらけで最高でしたね！
一瞬上位5名全部 @tompng さんなのではと思わされたりもしましたがそんなことはなかった。
みなさんそれぞれ好きなやつが1つはあるのでは無いでしょうか。
個人的にはお花のやつと wav のやつが好きです。特に音がちゃんと波の音になってるの凄い。
イベントの様子 Day1
せっかくなので RubyKaigi 全体の雰囲気をいくつか写真付きでお伝えします。
こちらは今回会場の愛媛県県民文化会館。想像よりもかなり広々としていました。
例年に比べてぱっと見の RubyKaigi 感が薄い…？一体何が行われているんだと思われそう…
メインホールは2F, 3F 席もありかなり広いですが、ここが数多の Rubyist で埋め尽くされます。
今回は会場入ってすぐの広場がスポンサーブースになっていました。
各社趣向を凝らし、気合の入ったブースがたくさん。
Day1 まとめ
以上、 RubyKaigi Day1 の様子を簡単にですがお伝えしました。
少しでも現地の雰囲気や熱気が伝われば幸いです。
明日以降の発表やイベントも楽しみですね！
明日 Day2 の速報記事も執筆予定ですので、お楽しみに！
ブルーモは Ruby エンジニアを積極採用中です
最後に、ブルーモでは Ruby エンジニアを積極採用中です。
少しでも興味がある方は私に各種SNS経由でお声がけ頂ければ、
カジュアル面談でも、もう少しざっくばらんに食事しながらお話などもできますので、お気軽にどうぞ！
もちろん、以下のページからカジュアル面談を申し込んで頂いても大丈夫です！
また、Ruby 以外でも、興味とご経験に応じて、エンジニア、デザイナー、PdM、事業開発など多岐にわたるポジションの仕事をお任せします。
会社やポジションについて、もっと知りたい方も上記ページをご覧いただければと思います。
ブルーモ証券株式会社のプロダクトチームブログです。「投資をみんなのものに」をミッションに、ポートフォリオをコピーして簡単に米国株・ETFで資産運用できるアプリ＂ブルーモ＂を提供しています。 各種エンジニア・デザイナー・PdMポジションを積極採用中です！ careers.bloomo.co.jp/
Discussion