TRUSTDOCKでバックエンドエンジニアをやっている上村です。
今回は RubyKaigi や Go Conference につづき、 Kaigi on Rails 2024 に参加してきました。
弊社ではテックチャレンジ推進制度という、エンジニアのやりたいことの費用を会社負担で実施させてくれる社内制度があり、今回のカンファレンス参加もこちらの制度を使って大所帯で参加してきました。
当日の様子
ご覧のように大盛況でした。
Kaigi on Rails のことを知ったのは RubyKaigi で、その時は「RubyKaigi より全然規模は小さい」と伺っていたため、正直面食らいました。
最後にわかったのですが、オフライン参加した人数はなんと600人超！
ホールは2つあり、どちらもかなりの人数が入るサイズでしたが、セッションによっては立ち見が出るほどでした。
またスポンサーブースもたくさん出店されており、他のカンファレンス同様に趣向を凝らした楽しいブースばかりでした。
また、お喋りするための「ワイワイ部屋」に加えて、急な業務やアラート対応のための「モクモク部屋」があったのが非常にユニークで、どちらも多数の利用者がいました。
アラート（出ないにこしたことはありませんが）が発報された場合や、業務で急ぎの連絡を要する場合などでも静かに落ち着いて対応できる工夫がエンジニアフレンドリーでした。
スポンサーとしての参加
実は今回、弊社 TRUSTDOCK は Kaigi on Rails 2024 のスポンサーをさせていただいております。
カンファレンス参加も積極的に行っていく中で、よりコミュニティに貢献したいという思いが全社的に強まり、会社として初めてテックカンファレンスにスポンサーとして協賛させていただくことになりました。
弊社 CTO から「Kaigi on Rails 2024 へのスポンサーとしての参加について思いの丈を語りたい！」と言付けを預かっておりますので以下に紹介します。
CTOの荘野です。
この度、TRUSTDOCKは Kaigi on Rails 2024 のゴールドスポンサーとして協賛させていただきました。
TRUSTDOCKでは、2016年より長きに渡って本人確認（KYC）プロダクトを開発しており、柔軟性とスピードをもとにお客様へより価値を感じていただけるプロダクトを目指して提供を行っております。また、技術としてはRuby on Railsを選択し、RubyやRuby on Rails、そしてコミュニティにも支えられながら事業の成長を進めることが実現できております。
こういった中で、普段よりお世話になっている言語やフレームワーク、コミュニティに対してなにかしらの形でお返ししていきたいという想いがあり、Ruby on Railsを中心にWebの技術全般に関わる情報を共有・発信される場である Kaigi on Rails 2024 へスポンサーとして参加させていただきました。
TRUSTDOCKは、引き続きRuby on Railsを用いて本人確認領域の課題を解決するプロダクト開発を進めてまいります。
そして、エンジニアコミュニティへの貢献も継続したく、来年も積極的に参加していきたいと思っております。
今後とも、TRUSTDOCKをどうぞよろしくお願いいたします。
ということで、今後も積極的にカンファレンスへのスポンサー参加をしていければと思います。
印象に残ったセッション
肝心のセッションですが、Blue と Red の2ホールで開催されました。
ほぼ全ての枠に参加させていただきましたが、「どちらも聞きたいのに…」という嬉しい悩みが尽きないラインナップで、最初から最後まで楽しませていただきました。
素晴らしいセッションばかりでしたが、その中でも一部を共有させていただきたいと思います。
[Key Note] Rails Way, or the highway
Kaigi on Rails 2024 の最初を飾ったのは Gem を多数公開されている @palkan さんの基調講演で、 Rail Way に則ってアプリケーションを拡張し続けることの重要性とコードベースでその実演をされるといった内容になっていました。
お恥ずかしながら私は英語ニガテ民ですので、英語で話し始められた際に「どうしよう…」と思ってしまったのですが、スライドには日本語も記載されており、コードを中心に話を進めていただいたおかげで全く問題なく拝見することができました。
Rails のアプリケーションがグロースしていった際、複雑化するロジックを実装するたびに徐々に Rails らしくない作りのコードが増えていき、往々にして秘伝のお味噌のようなコードになってしまいがちです。
これは元からある Model, Controller, View のレイヤーで収めようとするから起きる事象であり、適切に抽象化レイヤーを用意してあげることで責務分担が明確化し、Rails らしいコードを維持できるという旨の内容で、実例としてステップ方式のフォームを挙げられていました。
対象となっていたフォームは単一モデルに対するフォームで、一枚の View に敷き詰められたフォームからステップ方式のフォームへの改修を Rail Way に則って実施する例を挙げられていました。
フォームオブジェクト的なものを作って処理するという、割とメジャーな手法で実装する方向性でしたが、フォームの抽象化が非常に洗練されており、明確にレイヤーを区切って実装されていました。
最終的に出来上がったフォームは見事にステップ方式で動作するのはもちろん、コントローラーやモデルに余計な Presentation レイヤーの事情が染み出しておらず、MVC 部分は rails g scaffold したものに少しだけ手を入れたような見通しのよいコードになっていました。あらためて自身のコード設計の至らなさと Rail Way の高みを垣間見たセッションでした。
モノリスでも使える！OpenTelemetry で Rails アプリのパフォーマンス分析を始めてみよう
OpenTelemetry をサクッと導入してオブザーバビリティを手軽に体験してみようという趣旨のセッションでした。
前半は OpenTelemetry の概要について説明されており、後半は OpenTelemetry の Gem を導入した Rails アプリケーションを動かしながら、実際に送られてくる情報を閲覧・活用してみるといった内容でした。
デモアプリにも意図的に処理速度が遅くなるようボトルネックが設けられており、バックエンドのテレメトリを見ながらボトルネックを特定するまでの実演もあり、OpenTelemetry 導入の有用性を肌で感じられるセッションになっていました。
私は元 SRE なので OpenTelemetry 自体の知見がある程度あったため真新しい情報などはありませんでしたが、Gem の導入の簡単さにあらためて Rails の良さを感じました。
弊社は Datadog さんを利用させていただいており、Rails のアプリでは Datadog Gem を計装として採用しているため、OpenTelemetry の Gem は使っていませんでした。
Datadog Gem は SaaS 謹製なので計装が簡単なのは想像通りという感じなのですが、OpenTelemetry も同じくらい簡単かつ出力される情報量も多くてびっくりしました。
Go のアプリでの計装も実装したことがありますが、あちらは最低限の記述だとそこまで多くの情報が出てこず、実際にワークさせようとすると色々と手をいれる部分も多かったので Rails（というか Ruby）の自由度の高さを再認識しました。
デプロイを任されたので、教わった通りにデプロイしたら障害になった件 〜俺のやらかしを越えてゆけ〜
Speaker である @izumitomo さんの新卒時代のデプロイ絡みの失敗談を赤裸々に振り返ってみる、という趣旨のセッションでした。
まずなんといっても話がおもしろい！スライドの構成と内容、話し方が非常にマッチしていて笑い声の絶えないセッションでした。
内容的には開発者あるあるが詰め込まれている感じだったのですが、 当時の @izumitomoさんの原因調査の丁寧さや社内展開の仕方がとても的確で、むしろ新卒でそこまでできていたからこそ現在登壇されるまでのエンジニアになられたんだろうなというのが感じられる内容でした。
Hotwire or React? 〜React の録画機能を Hotwire に置き換えて得られた知見〜
動画の録画を行うUIをReactから HotWire にリファクタリングしてみた際の知見を共有するという旨のセッションでした。
もともとインタラクティブな挙動をする部分だけ React で実装されていたものの、チームメンバーは Rails が得意で JS はそこまで…という状況だったので、HotWire にしてしまえば捗るのでは？というモチベーションのもと技術調査兼リファクタリングを実施されたようです。
最初は Stimulus メインで書き直してみたものの、「簡潔にはなったものの楽になるわけではない」という結論に一度着地したとのことです。新技術を投入しようとした際のあるあるですよね。
しかし再度 HotWire 関連の設計概念を見直して作り直すことで、コード数も1/4になり、ロジックもサーバー側に寄せることができたとのことでした。
HotWire を利用したサービスの開発はまだ携わったことがないものの、ごく一部インタラクティブなだけなのに React などを導入するのもなぁ…という場面は多々あったため、非常に興味深い内容でした。
従来の MVC 的なルーティングを前提とした頭で設計しないことが HotWire を活かすミソであるというのは、今までなんとなく感じていながらもちゃんと言語化できていなかった部分だったので新しい気付きを得ることができました。
Sidekiq vs Solid Queue
Rails 8.0 で実装予定の Solid Queue と ActiveJob のアダプターとしてデファクトスタンダードになっている Sidekiq を比較してそれぞれのユースケースを考察するといった内容のセッションでした。
前半は最新の Solid Queue に至るまでの Rails がサポートしてきたバックグラウンドワーカーたちの変遷を詳しく挙げてくださっていました。
Rails 歴がそんなに長くないこともあり、Sidekiq 以外の選択肢への造詣が浅かった自分にとって、初期は RDB を使ったものを使っていたことや、 Sidekiq もアダプター経由での使用ではなく直接使うほうがよい場面があるなど学ぶことが多い内容でした。
また後半はどちらをどのように使っていくのがよいかという結論部分に至り、Sidekiq を Pro バージョンで使うなら、多機能、高速であり技術も枯れている Sidekiq に軍配が上がるものの、あまりヘビーな用途でワーカーを利用しないのであれば Solid Queue が導入の敷居が低くてよいという切り分けになりそうとのことでした。
個人やスタートアップのコンパクトなアプリケーションにとってはファーストチョイスにもなりうる、The One Person Framework を体現した新機能ということで、8.0 のリリースが待ち遠しいですね。
[Key Note] WHOLENESS, REPAIRING, AND TO HAVE FUN: 全体性、修復、そして楽しむこと
トリを飾ったのは @snoozer05 さんの基調講演で、長年 Rails を扱ってこられた経験から、Rails を用いたシステムの設計観を話されていました。
トピックは大きく2つあり、システムコンポーネントレベルで設計することの大切さ、変更容易性をいかに保つのか、という点にフォーカスした内容になっており、シンプルに保ち続けるには The One Person Framework であり続けることであるという結論に帰着する構成になっていました。
トークの構成や数多くの興味深い引用は多数の著書を執筆されている @snoozer05 さんならではで、とても深遠な内容がスルスル頭に入ってくることに衝撃をうけました。
また自分自身、良かれと思ってついつい余計なコードを書いてしまいがちな癖があり、この修正に励んでいるところでした。
シンプルであることの大切さはもちろん、シンプルという概念をどう捉えるかといった大きな命題に対するアンサーの一例を見せていただいた、大変実りのあるセッションでした。
もちろん著書も拝見させていただこうと思います。
参加してみて
とても学びのある素晴らしいカンファレンスでした。
オフライン参加の数も想像していたよりも遥かに多く、会場全体から活気が溢れていたのが非常に印象的でした。
やはり日本における Ruby on Rails の存在感は大きいということを再認識しました。
セッション全体を通して、いい意味で敷居が低く、アカデミックというよりは実務に寄った内容が多く、アカデミックな領域まで踏み込めない自分でも「来年はプロポーザル出してみたい」という気持ちにさせてくれるカンファレンスでした。
一方で、Ruby on Rails というフレームワークに真摯に向き合い続けた熟達者の方々のセッションは目からウロコの連続でした。
Rails は良くも悪くもクセの強いフレームワークだと思っていたのですが、それは作りたいものに Rails を寄せていくような考え方をしていた自身のせいなのだと気付かされました。
あくまで Rail Way に乗せて、フレームワークがカバーしてくれている範囲を最大限に活かしつつ、その内側にビジネスロジックを実装していくような「余計なことをしない」設計に挑戦していこうと思います。
最後に
2日目後半にはじめてワイワイ部屋に訪れた際、ホワイトボードに参加企業の方々が求人を出していることに気付き、「初日に書いておくんだった…」と後悔していました。
弊社も絶賛エンジニア採用を強化中です。
バックエンドやネイティブアプリのエンジニア、PdMなど広く採用活動を行っています。エンジニア求人一覧はこちら
こちらよりカジュアル面談にご応募頂けます。
ちょっと話してみたいくらいの温度感でも大歓迎ですのでぜひ一度ご応募ください。
