タイミーの新谷、亀井、甲斐、須貝です。
Kaigi on Rails 2024 が10月25日、26日の2日間で開催されました。タイミーは昨年に引き続きKaigi on Railsのスポンサーをさせていただきました。
また、タイミーには世界中で開催されているすべての技術カンファレンスに無制限で参加できる「Kaigi Pass」という制度があります。詳しくは以下をご覧ください。
この制度を使ってオフラインでは6名のエンジニアが参加しました。
参加して聞いたセッションのうち印象に残ったいくつかをピックアップしてご紹介します。
Keynote: Rails Way or the highway
https://kaigionrails.org/2024/talks/palkan/
https://evilmartians.com/events/keynote-rails-way-or-the-highway-kaigi-on-rails-2024
test-prof の作者であり Evil Martians の principal backend engineer である @palkan さんによる Rails way とは何なのか、Rails を拡張する際に考えていることについての発表でした。
Railsのレールを伸ばすときの考え方として、「カスタムアプリケーション開発者の考え方ではなく、フレームワーク作者の考え方を持とう」というメッセージは個人的に強く刺さりました。一方、Railsアプリケーション開発者にとってフレームワーク作者の考えを持つのは簡単なことではないと思います。rails/rails のコードを気軽に読むのはもちろん、main branch にあるコードだけでフレームワーク作者の意図を読み取るのには限界があるため Issue や Pull Request の議論のキャッチアップも必要だと感じます。
個人としてこの能力を持つための努力をしていきたいと思いつつ、組織としてこの能力を持ち続けるためには技術顧問の採用によってこの部分を補完するのも一つの手としてありそうだなと思いながら聞いていました。
（@euglena1215）
RailsのPull requestsのレビューの時に私が考えていること
https://kaigionrails.org/2024/talks/yahonda/
Rails コミッターをされている @yahonda さんが Rails に Issue / Pull Request を出すときに押さえておいてほしいポイントと @yahonda さんがコメント・レビューするかの判断基準についての発表でした。
1つ前の基調講演で「フレームワーク作者の考えを持とう」という @palkan さんの発表から実際に Rails コミッターはどんなことを考えながらコメント・レビューをしているのかという流れで繋がりを感じながら聞いていました。
ユースケースがあるか、という観点においては自身も Real world use case? と聞かれてうまく答えられなかったことがあるため Pull Request の例が出てきたときはヒヤヒヤしながら聞いていました。「誰のどの問題を解決したいのか」「その問題はこの解決方法で解決するのが適切なのか」という観点は普段のプロダクト開発においても重要な観点であり、OSS活動においてもプロダクト開発においても意識し続けたいと思います。
（@euglena1215）
Identifying User Identity
https://kaigionrails.org/2024/talks/moro/
@moroさんによる登壇です。昨年は Simplicity on Rails という話を Kaigi on Rails でされています。私の理解では昨年の登壇で地に足のついた Rails way とは？という話をされていたと思っており、そこからの流れで今年、基調講演も含めて Rails way についての言及が多く、大変にっこりしております。
そのうえで、今回の @moro さんのお話は User Identity にスコープを絞ったお話です。最初の方で「大雑多に『ユーザー』と呼びがち」という話をしてカラフルな名前について言及していたので、てっきりモデリングの文脈で言及される「よく『ユーザー』って名前をつけがちだけれど場面によってそれぞれの『ユーザー』の振る舞いが変わるんだからもう少し適切にモデリングしようよ」という話かと思ったのですが違いました。今回は User Identity です。おそらく、 Identity の話をしたかったが、「ユーザー」という表現にも納得感がない。とはいえ、伝えたい内容が Identity だから泣く泣く「ユーザー」という表現にしたかったので冒頭でエクスキューズされたのかな、と勝手に思っております。
架空のユーザー管理機能をつくるぞ、ということで、 Gem などを使わずにどうすれば適切に identify したい単位としてのユーザーをコードで表現すればいいのか？ということについて説明されておりました。ユーザーが「いる」こと = identity という説明をして、 users テーブルにはほぼ id だけあればいい、というお話です。これにはものすごく納得感があります。たしかに、ユーザーの属性としてメールアドレスだとか名前だとかをつけがちですが、システムとしてそれらが必要な場面はほとんどなく、大体の場合 association としての id （存在していること）さえわかれば十分です。そして、昨今の個人情報の扱いという点でも id とメールアドレスなどのユーザー属性のライフサイクルは異なります。そういう点でもこの主張にはとても納得感があり、かつ登壇内容も明快でわかりやすくとても参考になりました。
ユーザーの登録に関しての説明も良かったですね。「登録しようとしているコト」を表す UserRegistration モデルを用意すると Rails っぽくユーザー登録をハンドリングできる、というのは昨年の登壇を聞いているととても納得感のあるものです。個人的に面白いと思ったのは UserRegistration モデルに belongs_to :user, optional: true で UserRegistration モデルと User の association がオプショナルになりうる、ということです。これは、ユーザー登録途中で離脱した状態を表現でき、なかなかのアハ体験でした。
少しだけ懇親会でお話を伺い、こんな質問をしてみました。「ユーザー登録を表現する UserRegistration のようなイベントモデルを見つけるにはやはりチームメンバーにそれなりのスキルが必要でしょうか？」と。「いやーそうなんですよねー」という回答をいただきまして、このあたりのスキルは「一朝一夕では身につかないんだなー」と思い、今後もさらに興味を持って Rails と向き合っていきたいなと思いました。
（@yykamei）
Hotwire or React? 〜Reactの録画機能をHotwireに置き換えて得られた知見〜
https://kaigionrails.org/2024/talks/haruna-tsujita/
私はHotwireを触ったことがなく、個人的価値観としてはそこまで重きを置いていないのですが、だからこそ、このような場で実際に向き合っている方々の知見を得られるのは有用な機会であると思い、本発表を聞かせていただきました。
登壇者の@haruna-tsujitaさんが所属される株式会社キャタルは英語4技能塾を運営されており、前々職でガッツリ関わった分野なので非常に懐かしく感じています。そして、前々職と同様の少数精鋭だからこそ、バックエンドエンジニア2人が片手間でReactの面倒見るのがしんどいというペインがあり、Reactを捨ててHotwireに至るという意思決定がされたことがわかりました。
この事情は非常に理解できて、私の前職は技術者が数人規模のスタートアップで、Railsエンジニアが片手間でVue JS2を触っていましたが非常に開発量が多くしんどい思いをしていました。また、モダンなJSはプロジェクトの基幹部分の整備が非常に重たく、私は仕組みが出来上がったVueやReactのコンポーネントつくるくらいなら書けますが、まっさらな状態からモダンJSの実行基盤をつくる、という能力を持っていないことが結構なコンプレックスになっています。そして、これは私の個人的感情だけでなくそこを触れる人材を確保し続ける、というのがスタートアップにとっては重荷であるということを経験しています。会場の挙手の反応などを見てもHotwireを利用している企業は一定数存在するらしい、という空気があり、「Railsエンジニアが片手間でフロントを見る」という選択肢においては利用できるのかもしれないという学びを得ました。幸いにして弊社においては専業でReactを書いてくれるフロントエンドエンジニアの面々がいるおかげでこのような心配をせずに済んでいるのですが…。
話を戻しますが、HotwireはSPAとはアプリケーションを構成する考え方が違う、というnay3さんの話を孫引きして解説してくれているのがまた面白い話で、SPAのコンポーネント単位の考え方から離れて、違うURLで部品の差分を表現する「Web紙芝居」と呼ばれるちょっと昔に逆行した仕組みを敢えて用いることで設計をコントロールしているのは興味深いです。
ある程度ちゃんとした組織なら私はSPAを推すでしょう。ですが、数人規模の会社でよりにもよって私がテックリードをしなければならないような危機的状況に陥った場合、もしかするとHotwireは助けとなるかもしれない。そういう示唆を得られた登壇でした。
（甲斐 宏味）
Railsの仕組みを理解してモデルを上手に育てる - モデルを見つける、モデルを分割する良いタイミング -
https://kaigionrails.org/2024/talks/igaiga/
igaigaさんによるRailsらしいモデル設計とその分割についての発表でした。ご自身もおっしゃっていたようにpalkanさんのオープニングKeynoteの内容とも重なるところがあり、自分はこの手の話が好物なのでとても楽しく聞かせてもらいました。
モデリングをする際にイベント型モデルを見いだせるとRailsのレールにぴったりハマることが多いというのは自分の実感にもよく当てはまるところで、Railsアプリケーション開発者としてこのあたりのコツを掴んでいるかどうかは大きな差になると思います。イベント型モデルを発見できるとControllerはそのイベント型モデルに対するCRUDになるので基本のアクション（create, show, update, deleteなど）で表現できるようになり（いわゆる「DHH流ルーティング」）、このレールに乗せていく感覚を得られると開発が楽しくなってきます。
このあたりの話はigaigaさんが参考資料に載せられていたtexta.fmというポッドキャストでもよく議論されているので、このセッションが面白いと思った方にはぜひ聞いてほしいです。特にep3の「Low-Code Development」ではイミュータブルデータモデリングにも触れており、論理モデリング段階でupdateとdeleteをしないという思考の制約を入れるとイベントを発見しやすくなる、といったテクニックをt-wadaさんがされていて非常に勉強になります。
（@sugaishun）
今回の Kaigi on Rails は Conceptual な発表が多かったように思います。そのおかげで Railsway とは何なのかをより一層理解できました。
Kaigi on Rails を運営してくださったオーガナイザーのみなさん、発表されたスピーカーのみなさん、スポンサーとして Kaigi on Rails を盛り上げてくださった各企業のみなさんありがとうございました！
今年も一昨年もスポンサーのブース抽選に外れブース出展できなかったのですが、来年こそはブース出展できることを楽しみにしています。来年はブースで会いましょう！
また、Kaigi on Rails の後夜祭として LT イベントを TOKIUM さんと永和システムマネジメントさんと 11/12（火）で共同開催します。Kaigi on Rails ネタや Kaigi on Rails によらない Ruby/Rails ネタなどいろいろなことをお話しする会になるかと思うので、興味があればぜひご参加ください！
