SENRIでWebアプリケーションの開発をしている宮本です！☕️
先日、松山（Matz-yama）で開催されたRubyKaigiに参加してきたので、個人的に気になったトピックや思ったことなどを簡単にレポートしたいと思います。
RubyKaigiは、昨年の沖縄開催が初参加で、今回が2回目の参加でした。
今年は、セッションやブースへの臨み方、RubyKaigi全体の解像度が上がっていたり、知り合いが増えていたり、エンジニアとして話せることが増えていたりと、昨年よりも幅広く楽しめた気がしています。
※昨年は全額自腹でしたが、今年は会社の支援があったのもありがたかったです…！
fat gem（ビルド済みバイナリがあらかじめ含まれており、インストール時の不便さを解消するgem）をやめて、ビルド環境を自動で用意できる仕組みにしませんか？というセッションでした。
恥ずかしながらfat gemの存在自体を知りませんでしたが、技術選定の際に「その技術が何に依存しているか」を知ることは非常に大事だと思うので、新しい観点を得られたのが嬉しかったです。
RuboCopにはこれまで公式の拡張ポイントがなく、Custom Copなどの外部Copを追加する際は、内部実装に依存した読み込み方法がデファクトになっていました。
このセッションでは、それに対して公式APIとして plugin 機構を追加したという話でした。
ちょうど最近DDD（ドメイン駆動設計）の本をいくつか読んでいたため、「Parserを入れ替え可能にした」という話から、中間層を挟んで抽象化することで依存をコントロールする設計の意義をより実感できました。大きくなりすぎたメソッドやモデルのリファクタリングでも、「依存の方向性はこれでいいのか？」といった視点を持ち続けたいと思わされました。
Rubyを書いてる人で使ったことがない人はいないであろう、Class#newの最適化の話でした。
これほど基本的なメソッドでも最適化の余地がある、というのが個人的には刺さりました。（できるかは置いといて）
つい完成されたものを使うだけ、になりがちですが本当にそれが最適とは限らないんだという発見があり面白かったです！
見どころ盛り沢山のKeynoteでしたが、個人的にはPrograming language for AI ageのセクションで言われていた「静的型付けは型間違いを見つけやすいが、未来にそれは必要なのか？いや、型間違いは大したエラーではない」という部分が面白かったです。
実務でがっつり静的型付けをやったことがない＆巷でよく聞くメリットとして挙げられていたので、特に疑いなく型間違いによるエラーを見つけやすいのは大きいメリットだと考えていました。
が、たしかにヒューマンエラーによる型間違いは今後AIがコーディングしていく中でなくなっていくと思われるためとても納得しました。こういった今の当たり前が未来の当たり前でなくなっていく状況で、変な前提に引っ張られないようにアンラーニングしていく力も大事になってくるのだろうなと思わされました…！
Pico Ruby
昨年もpico rubyについての発表がありましたが、今年もLTでシンセサイザーを作られている方がいてやってみたい気持ちが高まったので、今年中になにかやってみようと思います！
「はじめに」でも書きましたが昨年と比べて分かる事が増えて、それにより実務に活かせるポイントも考えられる様になり、とても充実したRubyKaigi 2025でした！
また、隠れ目標だった松山グルメの制覇もできたのではないかなと思います。笑
鯛めし2種、三津浜焼き、鍋焼きうどん、焼き豚たまご飯、松山ラーメン、じゃこ天、etc...
鯛めしは間違いなく美味しかったですが、個人的には松山ラーメンが甘めの醤油とプリプリの背脂？で好みでした！
CTO目線でのレポートはこちら
前回書いた記事はこちら
