ペイトナーファクタリング事業部でEMをやっている脇田（@shimpeee_）です。 Kaigi on Rails2024参加レポです。
技術カンファレンスへの参加は、RubyKaigiを除くと今回が初めてでした。RubyKaigiのセッションは自分にとってはなかなか理解の難しい次元の話をされることが多いですが、Kaigi on Railsは明日から現場で使える知見がたくさん得られ、実践的な学びの多い二日間でした。
技術カンファレンスに参加し得られるメリットは、対象テーマについての知識獲得につながるのはもちろん、その周辺領域の体系的な知識、歴史や思想まで知れることですね。また、登壇者に感化され「自分もやっていくぞ！！！（何を？）」というエネルギーをもらえるのも良いですね。普段は仕事でもコードを書く機会は減ってきていますが、めちゃめちゃコード書きたい欲高まってます。熱が冷めないうちに、印象的なセッションの感想を書きます。
Rails Way or the highway
Palkanによる基調講演。「適切にRails Wayに乗っかろう。でも、設計上辛いタイミングって結構あるよね」という会話が弊社内でもよく発生します。面接でもこうしたテーマについて質問・議論させていただくこともあり、実践的なテーマとして興味深いセッションでした。
Railsの設計パターンを学び、規約の原則を受け入れるために、フレームワークの思想を理解することはとても重要なのだなと理解しました。
「Rails Wayに乗っかりながら隙間を埋める技術」として紹介されていた『』は英語書籍ですが挑戦してみたいです。テック系の書籍は未翻訳の良書が多いので、いつか英語でもスラスラ読書できるようになりたい。。そのきっかけになるか、、、！？
推し活としてのrails new
個人的な今年のNo.1セッションかもしれません。普段は業務以外でコードを書かない人がなぜ業務外でrails newをし、何を作り、その後どうなったかのお話でした。
僕も業務外ではコードを書かないタイプなのですが、技術ドリブンではなくどうしても解決したい課題が目の前にあれば確かに、同じようにコードを書くだろうなあと思いながら聴いていました。仮にそのタイミングが来た時に、コードを書こうと思えば自分で書ける職業であるエンジニアって素敵だなと思いました。この道を選んだ数年前の自分ナイス。
エンジニアとしてのスキルを業務外で発揮する場面を見つけるためにも、人生を豊かにする意味でも、まずは寝食を忘れるほど熱中できるものに出会うことが何より大事だよなと、大袈裟に言うと人生を見つめ直すきっかけになったセッションでした。
Hotwire or React? 〜Reactの録画機能をHotwireに置き換えて得られた知見〜
React製の機能を実際にHotwireに置き換える過程で得られた実践的な知見についての共有でした。「Hotwire or React、どちらを採用すべきか？」は、CRUDがあるかないか、リッチなインタラクションがあるかないか、あたりが観点になりそうです。CRUDに処理を寄せられる＆少しの動きが必要、くらいであれば十分Hotwireで対応可能とのこと。
ちょうど直近僕らのプロダクトでもフロントエンド技術選定で「Hotwire or (Vue or React)？」といった議論が生まれ始めているので、非常に参考になるセッションでした。
Sidekiq vs Solid Queue
弊社技術顧問、我らが前島さん（@netwillnet）のセッションです。2024年現在、RailsにおけるバックグラウンドワーカーのデファクトスタンダードであるSidekiqと、Rails8.0から標準採用されるSolid Queueを、歴史的な変遷と交えながら機能や特性を分かりやすく紹介してくださいました。
「今後はSolid QueueがRails標準になるので、Sidekiqから移行すべきか？」という論点だと、現状はそこまで移行メリットは薄そうとの結論でした。Solid Queueによって機能が増えるわけではなく、現状困っていることが解決するわけではない、というのが主な理由です。
また、これから新たに入れる場合はどちらがいいかでいうと、めちゃくちゃ大量のジョブを扱う場合を除くと、Sidekiq特有の機能を使いたい明確な理由がない限りSolid Queueでよさそうです。うちのプロダクトだと、Solid Queueでよさそうだなーと思いながら聴いていました。
Data Migration on Rails
本番データ操作、どうしてますか？がテーマ。rails consoleでの操作・rakeタスクでの実行・gem利用など、各手法にはそれぞれメリデメあり現状デファクトスタンダードが存在しない領域です。
セッション内で、おすすめのgemとして Shopify/maintenance_tasksが紹介されていました。UI上でタスクの実行管理ができます。
README内の「Should I Use Maintenance Tasks?」によると、大量のデータ操作を行うようなジョブがあり、UI上でタスクの進捗を見て一時停止・再開等したいような需要がある場合はこのgemが有効であり、そうでない場合は普通にコマンドラインでタスク実行すればいいよとのことでした。
現状のペイトナーファクタリングのアプリでは、このgemの導入までは不要そうだなと思いながら聴いていました。
WHOLENESS, REPAIRING, AND TO HAVE FUN: 全体性、修復、そして楽しむこと
島田浩二さんによる基調講演です。これからのエンジニアの人に向けて、島田さん自身が大事だと学んだことを教えてくれました。
「アプリケーションに閉じずシステム全体の視点を持つべし」という話は、最近読んだシステム思考の本でも語られており、僕もエンジニアリングに限らず組織開発等全ての業務において非常に大切にしている価値観なので非常に共感できました。共感はしましたが、プロダクト開発においてはシステム全体の視点を全然持てていないことも同時に分かりました。全体視点を持つための第一歩としては低レイヤー知識を身につけるのがいいみたいです。そうなんだ。
おわりに
みなさん、Railsについて語りたい欲高まってませんか・・？Kaigi on Railsの感想戦しませんか？
ペイトナーではバックエンド技術にRailsを採用しており、Webエンジニア大募集中です。それ以外にも、以下ポジション積極採用中です！！！
- Webエンジニア
- エンジニアリングマネージャー
- プロダクトマネージャー
お話聞いてみたいだけの方も大歓迎です。
少しでも興味お持ちいただけましたら、HPのカジュアル面談申し込みフォームからぜひお申し込みください。お待ちしております。
