自己紹介
フィヨルドブートキャンプで学習しています、motohiroと申します。
完全未経験（元医療職）から学習を開始し、現在自作サービスのプラクティスに着手しています。
Kaigi on Rails 2024に参加しました！
2024/10/25~26で有明に行ってきました！
初めてのKaigi on Railsでとても楽しみにしていました🙌
- 自己紹介
- Kaigi on Rails 2024に参加しました！
- 発表全体について
- 印象的だった発表
- 10/25 基調講演 Palkanさん Rails Way, or the highway
- igaigaさん Railsの仕組みを理解してモデルを上手に育てる - モデルを見つける、モデルを分割する良いタイミング -
- kotatsuさん 推し活としてのrails new
- yana-giさん カスタムしながら理解するGraphQL Connection
- katty0324さん リリース8年目のサービスの1800個のERBファイルをViewComponentに移行した方法とその結果
- TAKEYUWEBさん 現実のRuby/Railsアップグレード
- haruna-tsujitaさん Hotwire or React? 〜Reactの録画機能をHotwireに置き換えて得られた知見〜
- kozy4324さん ActiveRecord SQLインジェクションクイズ (Rails 7.1.3.4)
- ykpythemindさん OmniAuthから学ぶOAuth 2.0
- ohbaryeさん Data Migration on Rails
- expajpさん omakaseしないためのrubocop.yml のつくりかた
- moroさん Identifying User Identity
- 10/26 基調講演 島田浩二さん WHOLENESS, REPAIRING, AND TO HAVE FUN: 全体性、修復、そして楽しむこと
- 印象的だった発表
- 会場＆懇親会
- まとめ
- 発表全体について
発表全体について
頑張ったらちょっとだけ理解できそうな発表があったりとか、そこまでいかないにしても単語は聞いたことがある発表があって、少しでも自分が分かるものがあって嬉しかったです！
それでもまだまだ難しかったですが、来年自分もWebエンジニアとしてパワーアップして聞きたいなと思える発表ばかりでした。
発表全体として、当たり前ですが、「Rails wayにのる」ことをとても重視されていたように思いました。
Rails wayの話を聞くたびに、今自分が作っているサービスがRails wayから外れていないかと不安になってコード確認しようか悩んだのを覚えています。
（確認し出すと止まらないのでその場で確認するのはやめました笑）
印象的だった発表
以下に印象に残った発表と感想を書きました。
初学者で、理解違いなどもあるかと思いますがご了承ください。
今の自分にはレベルが高かった発表や聞きそびれてしまった発表もあったので、またアーカイブを見つつ復習したいなぁと思っています！
10/25 基調講演 Palkanさん Rails Way, or the highway
まずスライドがおしゃれでかっこよかったです！見入ってしまいました。
Railsは、０（rails new）から１（最初の動作（リリース））までRails wayにのっていけば問題なく進められて、そのあと１からIPO（上場）までいくには？という始まりでした。
元々のRails wayのMVCから、どのように拡張していくのがよいのか、それは何かを混ぜるのではなく他と担当分野を分離したものを追加するということのようでした。
担当分野の分離には新しい抽象化が必要で、その新しい抽象化の4つのルールはちょっと難しかったです。
Formオブジェクトが最後に例ででていて、UIの画面もあったのでわかりやすかったです。
Rails wayから外れず正しく拡張していけば１から成長していくことができる、ということだったのかなと思いました。
igaigaさん Railsの仕組みを理解してモデルを上手に育てる - モデルを見つける、モデルを分割する良いタイミング -
フィヨルドブートキャンプ内でもお世話になっているigaigaさんの発表でした！
お昼休みに初めてご挨拶できたのが嬉しかったです！
行為を記録するモデル＝イベント型モデルであり、このイベント型モデルが適切に探し出せると責務が適切になって処理も適切に書けるし、そのモデルはRails wayにのった設計になっているとのことでした。ただ、責務がしっくりくるモデルが作れないときやテーブルに保存はしなくて良いけどモデルっぽいオブジェクトがあるときは、PORO（Plain Old Ruby Object）をつくることもあるそうです。ActiveRecordを継承せずテーブルと紐づかない、Rubyの素のクラス、がPOROなのですが、なんか聞いたことあるなと思ってたら、ぱRailsの467~477Pでやっていました。ぱRails。読んでてよかったです。
FatModelについて、私はコードの行数が判断基準なのかと思っていたので、「書き続けるとしんどい」かつ「いい分割方法がある」とき、という判断基準は良い知見でした。自作サービスで、自作バリデーションも条件分岐しているし、updateも条件分岐していて、それってFormオブジェクトが使えるのでは…？というモデルがあるので、Formオブジェクトを実装するのが適しているのかどうかはまだわかりませんが、今回のスライドとぱRailsなどをもう一度読んで必要ありそうであれば検討してみようと思いました！
kotatsuさん 推し活としてのrails new
Ruby Kaigiで同じyada houseに宿泊したkotatsuさん！発表自体とても面白くあっという間に終わってしまいました！
最低限動くものを！最短でリリースを！という部分が我々のプラクティスの自作サービスにおいても一番大事な部分な気がして、そういう意味でRailsは本当に適しているしRails wayは大事で、基調講演で言ってた通り（０→１）だなって思いました。うまく言語化できないんですがとにかくかっこよかったです。kotatsuさん最高！
必要なものを最低限取り入れ、不要なものはいれない、の取捨選択が私のような初学者にはかなり難しいんですが、本当に大事な部分だと思ったので丁寧に見極めつつ、まずは最低限のリリースを目指して私も頑張ろうと思いました！
yana-giさん カスタムしながら理解するGraphQL Connection
GraphQLのお話でした！GraphQLは以前少しだけ勉強したときに本当によくわからなかったのですが、 yana-giさんが最初にGraphQLについての説明をしてくださっていたので、なんとなくのイメージはできるようになりました！
1つのページを取得するときに、REST APIだとリソース1つに対して1リクエスト（GET）なのでproducts,categories,cart,viewerと４回APIを実行する必要がある＋不要なデータのattributesも含めて取得してしまうのに対し、GraphQLでは1つのリクエストで複数のデータ（products,categories,cart,viewer）を取得できる＋必要なattributesのみ取得できる、というメリットがあるそうです。
またページネーションの種類に、「オフセットページネーション」と「カーソルページネーション」があることを初めて知りました。
オフセット：ある地点から何個分、と指定してデータを取得
カーソル：ある地点からある地点まで、と指定してデータを取得
そしてGraphQLでのページネーションはカーソルページネーションはConnectionパターンというもので実装できるようですが、今回はオフセットページネーションで実装しなければならず、その実装方法がCustomConnection、というお話しだったのかなと思います。
卒業して頑張ったらあんなに難しいことができるようになれるのかな…👀✨すごいな…！！という気持ちで発表を聞かせていただきました！
CustomConnectionの具体的な実装は難しかったのですが、以前は理解できなかったGraphQLをminneのページで具体的に説明していただいたことでイメージできたことと、ページネーションの取得方法に種類があることを知れて学びになりました！
katty0324さん リリース8年目のサービスの1800個のERBファイルをViewComponentに移行した方法とその結果
始まってすぐに「N organicじゃん！！！！！」って思いました笑
有名ですよね！すごい〜
ViewComponentのメリットがとても分かりやすかったです！
複雑なロジックがviewに入ってしまっていたり、条件分岐があったり、あちこちで使われている（再利用）場合に良いそうです。テストもviewのパーシャルではコンポーネント単位のテストはできますが、view vomponentならメソッド単位でのテストもできてテストもしやすく保守性が増すとのこと。
私の自作サービスで、現時点ではたとえばmodalは使用箇所が1箇所でそのままコードをベタ書きしてしまっていたりするので他でmodalを使う箇所が増えるようであればview componentで分離しても良いのかも知れないなと思いましたし、そういえばflashもパーシャルにしているけど条件分岐してけっこう煩雑な感じもするので、どちらも確認してみようと思いました。
TAKEYUWEBさん 現実のRuby/Railsアップグレード
Ruby・Railsのアップグレードのお話でした！
アップグレードをするのに、思っていた以上の準備が必要で驚きました。
アップグレード自体もその具体的な手順やそのとき注意することなど細かく解説してくださり、元々「1つずつ順番に上げていく」というイメージはできていたものの、実際にこうやってやっていくんだ、というイメージがしやすかったです。
個人的には、「非推奨警告は将来壊れることがわかっているのですぐ対処する」とおっしゃっていたのが印象的でした。おっしゃっていることは当たり前なんだけれども、自分は正直（気をつけなきゃな〜）くらいしか思っていなかったので、今まで自分の認識が甘かったなと思わされました。
今まで同じサービスを運用保守していくという経験がないこともあるかもしれません。
今回のお話は今後働くときにはきちんと覚えておこうと思いました！
このご本人のZennの記事がお話ししてくださった内容も書いてあってとてもわかりやすかったです！！！
haruna-tsujitaさん Hotwire or React? 〜Reactの録画機能をHotwireに置き換えて得られた知見〜
Hotwire、TurboとStimulusのお話でした！
「Web紙芝居」の考え方は以前から知っていましたが、最初のボタンで画面遷移を考えているところになんの疑問も感じずお話を聞いていました。
その後見方を変えてCRUD操作による画面の切り替えはHotwireのTurbo、録画機能はStimulus、となったときに、たしかに👀！！！！！と腹落ちしたというか、なるほど！とめっちゃ脳汁出た感じがしました。笑
私の自作サービスはメインががっつりCRUD操作なのでそこはTurbo、その中でmodalを出したりとかをstimulusを使うようにしたので、考え方的に合ってたようで安心しました。
あと、何をどのように考えてどのように上司に相談して、という時系列順に発表してくださったことで、みなさんこうやって建設的に業務をされてるんだな、自分もこうやって働いていきたいな、とイメージできたのもとてもよかったです！
スライドの終盤の、Hotwire or React ?のまとめ部分はとてもわかりやすくまとめてくださっているので、自作サービスでHotwireがいいのかReactがいいのか、どの部分にどれを使えば良いのか悩んでいるフィヨルドブートキャンプ生にはとても良い判断基準になると思います！！ぜひ見てもらいたいです！！！
kozy4324さん ActiveRecord SQLインジェクションクイズ (Rails 7.1.3.4)
SQLインジェクションをクイズ形式で答えたりしましたが、がっつり間違えました。
SQLインジェクションの一般的な対策と、Rails側がやってくれている対策の説明がわかりやすかったです。
自分の自作サービスでは、いろんなところでいろんなparamsの受け渡しをしているので、paramsを雑に渡してしまっていないか、適切に対策しているかきちんと確認しようと思いました。
自作サービスはRails7.2なのでBrakemanはデフォルトで入っていたけれど、どの程度脆弱性を検出してくれるのか全然わかっていませんでしたが、むしろ偽陽性が多いくらい検出してくれるとのことで上手に使えば便利なことがわかって良かったです！
ykpythemindさん OmniAuthから学ぶOAuth 2.0
そもそもの認証と認可の違いから解説があり、自分が認証認可をあまり理解せずにいたことがわかりました。
認証は個人を識別すること（誰であるか）、認可は権限を与えること、だそうです。
自作サービスでOmniAuthを使ってGoogleログインを実装していますが、おまじないをそのまま書いているような状態だったのでどういったことが中で行われているのかの説明は興味深かったです。
OAuth2.0（認可）を拡張して作られているOpenID Connect（認証）というプロトコル（OpenID Connectの解説）があって、それを理解しておくとOmniAuthなしで自分でサードパーティログインが実装できるそうです。
自分の現在の知識では実装を理解することは難しかったので、具体的な実装の手順は、アーカイブで再度解説を聞こうと思っています。
今までOmniAuthに丸投げしていたのが、中身に興味をもてて良かったなと思いました！
ohbaryeさん Data Migration on Rails
data migrationのお話でした！
私はチーム開発のissueで小さいものですがdata migration用のファイルを書いていたので、あれか〜って思いながらお話を聞きました。（そのときのPR）
（フィヨルドのdata migrateについてはこちらを参考）
いろんな方法があるのだけれど、rake task,ruby scriptで行うのがアンケートによると一番多いらしいです。
たしかにBootCampアプリでも最初はrake taskでやってたという経緯が載っていました。
今回個々のやり方の特徴を聞いたことで、BootCampアプリがなぜ他の方法ではなくdata-migrate gemを使っていたのかの理由に納得がいったように思います。
BootCampアプリがdata-migrateというgemを使う理由として幾つか書いてありますが、PRで実装する人（例：私）とデプロイする人（例：komagataさん）が異なる場合がほとんどなので、PRをデプロイする前にrake taskを実行しなければいけないのにそれが忘れられることが起きやすい状況にあるため、との理由があって納得でした。デプロイ時に含まれるPRの数もその時々で結構多かったりするので、だったらデプロイする時に一緒にrake taskを実行してくれるほうがたしかに便利だな、と思いました。
自分がフィヨルドで学習しているとフィヨルドのやり方が最初に覚えるものだからその方法（今回だとgem）に固執してしまいがちなので、いろんなやり方があることが知れて良かったです！
DHHはBasecampではruby scriptを実行しているそうで、Rails8ではrails g scriptコマンドが入ってくるそうです。
アンケート結果でもrake task,ruby scriptでやっている企業が多いようだし、そちらの書き方も勉強したいなと思いました！
expajpさん omakaseしないためのrubocop.yml のつくりかた
私はRails7.2で自作サービスを作成しているので、rubocop-omakase gemが入っていることは知っていましたが（結局自分で設定しているので削除してしまいました）、有効に設定されている数が46/554と結構少ないということを知りませんでした。
実際にチームでrubocopのルールを作成していく上での苦悩とか、それを乗り越えるための対策工夫が、自分はやったことのないことなので聞いていて興味深かったです！
特に「表明の幅は広く、採決ルールは細かく」の説明にあったの具体的な対策（意見が割れたときのルールを設定、「気にしない」選択肢をいれる、希望のオプションを表明できるようにする）は、確かにこの対策がなされていたら話し合いしやすそう〜と思えましたし、実際それを実践してうまくいっていたのですごいなぁと思いました。
自分もいざ働くとなった時には、そのようなルールが整備されているチームで働きたいと思いました！
moroさん Identifying User Identity
「ユーザーがいること」という哲学の話のようなテーマが、しっかり技術で解説されていて、面白かったし聞いていて引き込まれました。
idだけをもつusersテーブルは、どのようなときに便利なんだろうと思っていたのですが、「たとえば無料ゲームとかログインいらないもののときはテーブルを分けておいたほうがいい」とおっしゃっていました。サービス利用時点でログインをしなくて良いということは、ログイン自体を障壁と思っているユーザーが離れることを防ぐことができる、という視点もなるほどと思いました。自分が使う側だったらどう考えてもログインしない方が気軽に始められて便利なのに、いざ自分が作るとなるとログインして当たり前というか何でもかんでもログインさせようとしてるかもしれない、と思ったりして視野が狭くならないように気をつけようと思います。
また、個人情報のテーブルをわけておくことで、ユーザーの退会時に個人情報だけ消すことができて、そのユーザーが存在した事実のみ残すことができる、という部分は目から鱗でした。私の自作サービスはチャット風の機能があり自分がユーザー削除しても自分が書いた文章はそのまま残るようになっていて、でも私のusersテーブルは1つに全部まとまっているので、ユーザー削除されてしまったらその人がしたコメントはそのまま残して退会者用のアイコン画像を出すようにしています。家族という小さい規模でのチャットなのでそれでも良いかなと思ってはいますが、usersテーブルから個人情報を分けておくことでユーザー削除時に個人情報だけ消してユーザーのアイコン情報は残しておけるので、そうするとその人がいた事実は残せるんだな、なるほどな、と思いました。
userはuserだから1つのテーブル、という盲目的な考えから新しい視点をいただけて勉強になりました！
10/26 基調講演 島田浩二さん WHOLENESS, REPAIRING, AND TO HAVE FUN: 全体性、修復、そして楽しむこと
最初にソフトウェアを設計する際に大事だと考えていることとして2つのテーマをお話ししてくださいました。
１つめは、全体が機能するように設計する、というテーマでした。
アプリケーションを綺麗に作れたら終わりではなく、システム全体が機能して、システムとしてユーザーに価値を提供するという意識が大切とおっしゃっていました。データベースは円柱じゃないしサーバーはただの四角じゃない、とおっしゃってたときは思わずくすっと笑いましたが、あらい解像度でシステムを見てしまうというのはやってしまっているなぁと思いました。システムの構成要素と設計のパターンを知ることで適切なシステム構成ができアプリケーションをユーザーに届けられるともおっしゃっていて、自作サービスを作成していく上で、サーバーとかCDNとかのシステムのコンポーネントを全然よくわからない（そして正直今もよくわかっていない）なと思いながらもそのまま進めている部分があって、本来はきちんとそれらも学習してやっていくべきなんだなと反省もしましたし、でもそんなすぐわかるものではないし深いものだと思うので今後地道に学習していこう、とも思いました。
２つめは、変化に向けて設計する、というテーマでした。
設計開始時は一番何もわからない状態な訳でそこから今後の変化に対応してにはどうしたらよいか、ということで、オプションを手に入れるということでした。オプションは「将来的な選択肢を買う権利」で、どんな選択でもできるようにする、ということなのかなと思いました。そのとき「選択肢を広げて構えるということは、実際にはその選択肢の範囲になってしまうので狭めて待ち構えることになる。だからこそ、どの方向にも進めるようにシンプルに作る」とおっしゃっていたのが印象的でした。
たしかに、闇雲に走り出す（まだよくわかってないのにその選択肢を選んで実装しちゃう）わけじゃないにしても、左足を前に出して走り出す姿勢にしちゃってたら、いざ走る（変化に対応する）ってときには右足しか前に出せない（範囲が狭い）から、運動できる格好で運動靴でまっすぐ立てる状態にする（標準の道具で標準の方法で必要十分にシンプルに作る）ことでどの方向にも進める、ってことなのかな〜と思いました。
（思いついたので書きましたがわかりづらい例えになってしまいました…苦笑）
つまりはRails wayでRailsを使いこなすことが設計のポイントだそうです。
その上で、変化に向けてシンプルさを維持し続けることが難しいのであって、変化に適応し続けるには修復を続ける必要とのことで、修復とは、元に戻すということではなく、いろんな変化がそうあるべきで変化していったものなのだから変わった後の状態と調和し続けるようにすることだとおっしゃっていました。Railsもその時代その時代に合わせて変化していっている、修正され続けているとおっしゃっていて、確かにと思いました。
修復をする上ではProcess Feel（直感的に感じろ）が大事で、それを養うためには我々の認知負荷を減らすことが必要で、Railsは概念圧縮だったりOnePersonFrameworkだったりで認知負荷を減らすように作られているので、Rails wayに沿うことで修復箇所を感知する能力を高められるということでした。
今まではRailsでアプリケーションを作る、コードを書くということに集中して学習してきましたが、Railsはシステム全体の中の一部分に過ぎずシステムの構成要素それぞれに関しても勉強したいと思いましたし、Railsの考え方や思想的な部分も知りたいなと思いました！
そして今後も楽しむことを忘れないようにしたいです😄
会場＆懇親会
いつもフィヨルドでお世話になっているmoegiさんのデザインがあちこちにあって、とてもテンションがあがりました！🙌
会場ではたくさんの企業ブースが出ていて賑わっていてお祭りみたいで楽しかったです！
フィヨルドで普段お世話になっている方から初めましての方までいろんな方とお話ができて、みんな頑張っているんだなぁ私も頑張ろうって思えました！
また会場や懇親会の時にRuby Kaigiのときにお世話になったみなさんにもご挨拶できてよかったです！
まとめ
初参加でしたが、とても充実してたし楽しかったです！！！
来年は自分もWebエンジニアになってもっとパワーアップして、より有意義に参加できるようになりたいなと思いました！💪
発表者のみなさん、スタッフのみなさん、スポンサーのみなさん、本当にありがとうございました！
