ブルーモ証券でエンジニアをしている才記です。
普段は Ruby on Rails でブルーモのバックエンド開発をしています。
今日9月26日、 Kaigi on Rails が開幕しました！
RubyKaigi とはまた違った Ruby の大規模カンファレンス、
今回も現地で参加してきましたので、1日目の様子を速報的にお伝えできたらと思います！
というわけで早速 Day1 のセッションハイライトの紹介です。
私の独断と偏見で気になった、面白かった、印象に残ったセッションに絞っての紹介になるのでご了承ください。
Keynote: dynamic!
まずは一発目のキーノート、「dynamic!」 から。
タイトルがとても dynamic で素敵です。
IRB を使うような普段の開発者個人の小さな営みから、チームや会社でプロダクトを作っていくところまで、スケールややることは違えどそれらは動的である（動的にやれる）、というお話でした。
ここでいう動的は「継続的に変化し続けること」を指しています。
もう少し具体的に言うと「小さく試して改善する行為を繰り返す」ようなことになるのかな、と感じています。お話の後半でアジャイルへの言及もありましたが、まさに。
セッション内では「シンプルに作って後の変更に備える」という重要な考えが繰り返し出てきていたのが印象に残っています。常に心がけていたい考え方ではありますが、言うは易し、行うは難し…
この「シンプルに作る」を的確に行うために技術力や経験が大事になる、という。これをできるエンジニアを目指して頑張っていきたいですね…
お話の端々に「たのしい」というワードが出てきていたのが個人的に非常に印象に残っていて、また胸に刺さった発表でした。
最近ちょっと「Ruby を書くこと、プロダクトを作ることは楽しいこと」という気持ちを忘れかけていた気がするので、初心に戻って楽しみながら日々の開発をしていきたいと思いました。
そのpreloadは必要？──見過ごされたpreloadが技術的負債として爆発した日
Rails エンジニアが常日頃から活用しているであろうメソッド preload。
N+1問題の解決策としてみなさまよく使われているのではないでしょうか。
この高速化のための preload が不必要、不用意に使われることで深刻なパフォーマンスの劣化を招いてしまったという怖い話。内容としてはある意味タイトル通り、かつては使われていたが今は要らなくなった（が、残り続けてしまっている） preload が、ある日メモリを食い尽くしてしまったという話でした。
教訓としては「サーバのメトリクス監視と適切なアラートは大事」、「不要なコードの掃除や整理も大事」という感じ。
どちらもアプリケーション開発から少し逸れた部分で、微妙に優先順位が低かったり後回しにされがちなところだと思いますが、それが今回のような致命的な事象に発展することがある…というのは心に留めておきたいところです。
Railsアプリケーション開発者のためのブックガイド
昨今、開発に必要な知識や情報はインターネットでだいたい手に入ってしまうかと思います。
発表中でもありましたが、最近は AI に聞けば答えてくれることもだいぶ増えてきていますね。
そんな時代にありますが、それでも技術書というものが無くなったりはしていません。
書籍という媒体はそれ独自の情報であったり、あるいは魅力のようなものを持っていると感じます。
そんな技術書をお勧めしてくれたのが本セッション。 本だけに。
実際の本の紹介は…あまりのボリュームと速度だったのでここでの紹介は割愛します。
定番どころの本ももちろんありつつ、知らなかった本もかなり出てきていて聞いていて楽しかったです。
後日というか後ほど資料というかおすすめ本リストは公開いただけるとのことだったので、そちらを待ちましょう。
個人的には「本は積んでてもいいし、ざっくりペラペラめくるような読み方をしてもいい」というのが目から鱗でした。
真面目に頭からきっちり読むのは大事な一方、そこにハードルを感じて積みっぱなしになるぐらいならペラペラめくるぐらいの読み方をした方がはるかに良さそうですね。
「そういう読み方でもいいんだ」という気付きが得られたのがとてもよかった、そんな発表でした。
5年間のFintech × Rails実践に学ぶ – 基本に忠実な運用で築く高信頼性システム
Fintech 領域、信頼性というところで、弊社でも重要な部分の話、知見が聞けそうと思い聴聞。
開発の話もありましたが、どちらかというとタイトル通り運用の話が主だったのかなという感じ。
Fintech 領域とはいえ事業内容は違うのですが、行われている運用内容というか、特に対障害周りの運用ややっていることがほとんど同じだったのが印象的でした。
一方でまだまだ弊社ができていない部分もあり、例えばアラートのトリアージや通知先の絞り込み。この辺りはまだ弊社では甘く、広範囲に対して（必要以上の）多くのアラートが出てしまっていて疲弊する運用状況になっていたりするので、スマートバンクさんの別の発表を参考にしながら改善を進めていきたい気持ち。
2分台で1500examples完走！爆速CIを支える環境構築術
CI の速度は開発生産性に直結する重要な要素であると思っています。
現状の弊社の CI はあまりしっかりとした高速化ができておらず、実際この遅さが開発時、あるいはデプロイ時などに足を引っ張ることがままあるため、なんとかしたいと思っているところでした。
基本は並列実行をきっちり詰めていくところになるのかなと思いつつ、
tmpfs を使った IO リミットの突破が出てきたあたりはなるほどとなりました。
確かに揮発してもいいんだからメモリに乗せてしまえばいいですね。
最終的にはマシンスペックで殴るのが良いという話が出てきてしまったので流石に活かせるか微妙ですが、並列化周りの話や tmpfs 周りの話は活用していけたらなぁと思いました。
今改めてServiceクラスについて考える 〜あるRails開発者の10年〜
みんな大好き Service クラスの話。
10年ぐらい前というと私がちょうど新卒の頃になるかと思うのですが、確かにその頃 Service クラスはどうあるべきか（あるいはそもそも無いべきか）みたいな話が盛り上がっていたような記憶があります。
発表を通じて言われていたこととして「チーム内の共通認識を揃える」ことの重要性があるのかなと思いました。
Service クラスなり Form クラスなり、色々整理の仕方は考えられるが、何はともあれチーム内でちゃんと共通認識を持って、一貫性を持って、想像がしやすい状態を作っていきたい、という。
整理の仕方として上記のような方法こそあるものの、まずは Model や Rails の各機能（特に ActiveRecord とか）をしっかり理解して使いこなすをやるのが大事ですね、という話でした。
それはそれとして Service クラスの新しい用法としてモジュラーモノリスでの使用なども紹介されていました…が、この辺りはまたちょっとややこしそうな印象。
正解はないので常に考え続けなければならないというのはここでも言われてました。Dynamic。
ということで Day1 のセッションまとめでした。
Keynote の dynamic! もですが、全体的に「変化に立ち向かう」、継続的に変えて改善していくということの重要性について話されているセッションが多かったようなイメージを受けました。
トークテーマは様々あったかと思うのですが、それぞれがそれぞれの「動的」な話をしているのは非常に面白かったです。
2日目はまた少し毛色の違う発表が多そうなので、楽しみですね！
Views: 0
