Kaigi on Rails 2024に参加して高まりました

2024/10/30に公開

こんにちは!グロービスで技術広報をしているtsumichanです。
実は新卒の頃から5年ほどRailsを書いており、Ruby/Railsが大好きなのでKaigi on Rails 2024に参加しました。

初参加だったのですが、かなり気持ちが高まったのでアウトプットしたいと思います。

高まりポイント

めちゃくちゃ気持ちが高まった状態で帰宅したのですが、
何が私を高まらせたのか、高まりポイントを考えてみました。

セッションの内容のおもしろさ

はじめはRailsに関する具体的な内容だけだと思っていたのですが、
コミッターによるPRレビューの観点についてや、GraphQLの話、Sidekiqの話などWeb技術について広く取り扱われるのだな、と驚きました。

事前にセッションタイトルを見たときは、正直体が2つ欲しいと思うくらい興味深いセッションばかりでした。
実際に聴いてみると学びになる内容が多く、明日から使えるTipsがたくさんありました。
手元で実際に試してみたい!と思うことが多く、長らく離れていた個人開発へのモチベーションがめちゃくちゃ高まりました。

どのセッションも素敵だったのですが、このあと特に印象に残ったセッションをご紹介します。

スタッフの皆さんのかっこよさ

総勢30名ほどいらっしゃったスタッフさんですが、イベントをトラブルなく進行するためにテキパキと動き、かつご自身もセッションを聴いたり懇親会を楽しんでいたりされていて、かっこよすぎる!と思いました。

去年からあったかわからないですが、わいわい部屋ともくもく部屋があったのが良いなと思いました。
わいわい部屋では@ogijunさんのコーヒーをいただきながら休憩していたのですが、相席した方と軽くお話できたのがよかったです。

スタッフの皆さんのおかげで2日間楽しい時間を過ごせました。ありがとうございます。
かっこいいスタッフさんたちのおかげで2日間楽しめたことを考えると、私もKaigi on Railsに貢献したい!という気持ちが高まりました。

コミュニティの優しさ

前職でのつながりや、Ruby/Railsコミュニティで知り合った方が(ありがたいことに)たくさんいるのですが、その方たちにたくさんお会いできて嬉しかったです!
数年ぶりの再会という方もいました。
Xのハッシュタグ#rubyfriendsでは多くの方が仲良く写真を撮ったりしていて、ここまで参加者同士が仲良くなれるコミュニティってそんなにないんじゃないかな、と思いました(他のコミュニティをあまり知らないんですが)。

また、私は初参加だったのですが参加しづらく感じることもなかったです。
1日目の懇親会で疲れてテーブルでぼうっとしているとどこからともなく人がやってきて、おしゃべりしてくれたので、寂しさも感じませんでした。
話しかけてくれるの優しい。

なんていうんですかね、帰属意識というか、私はこのコミュニティの一部になれている、という気持ちになれるんですよね。
今までの知り合いに会えるし、さらに新しい方と知り合えるという楽しさが、
またこういったイベントに参加したいという気持ちを高めさせました。

印象に残ったセッション

ワークショップ:Rackを理解しRailsアプリケーション開発の足腰を鍛えよう

https://github.com/hogelog/kaigionrails-2024-rack-workshop

RackはRailsガイドでチラ見しただけで、ちゃんと勉強しなきゃな…と思っていたところのこのワークショップ。残り席数わずかなタイミングで滑り込んで申込みをしました。
内容を見るとわかりますがかなり噛み砕いた説明があり、理解がのんびりさんな私でもわかりやすくてよかったです。
私は開発環境が古すぎてRubyのバージョンを上げるところからのスタートになりましたが😇、
ルーティングは自分で実装するなどただのコピペだけじゃないところも楽しかったです。

Railsの仕組みを理解してモデルを上手に育てる - モデルを見つける、モデルを分割する良いタイミング -

https://speakerdeck.com/igaiga/kaigionrails2024/

グロービスでも業務委託としてご活躍いただいているigaigaさんの発表です。
実はこちら、会場で聴いたのではなくグロービス社内でβ版を発表していただいたのを聴きました。

発表の中で特に印象に残ったのは、
「modelを分割する良いタイミングはバリデーションを分岐したくなったとき」というものです。
今までいつ分割するか・どう分割するかで迷うところが多かったです。
バリデーションの分岐を書くことも多々あったので、これからはこの発表スライドをお守りにして分割タイミングを見極めていきたいなと思いました。

Sidekiqで実現する長時間非同期処理の中断と再開

https://speakerdeck.com/hypermkt/pausing-and-resuming-long-running-asynchronous-jobs-with-sidekiq

「重たいジョブを実行するのでリリースは控えてください」と言ったことがあります。。
Redisに進捗状況を記録しておくのはなるほどーとなりました。エラーメッセージなんかも保存しておくことで発生したエラーもしっかり確認できるのいいですね。
ファイルエクスポート処理はうちでもあったりするので、このやり方は試してみたいと思いました。
あと、テストにも触れられているのがよかったです。
and_wrap_originalなどのメソッドを知れました。

デプロイを任されたので、教わった通りにデプロイしたら障害になった件 〜俺のやらかしを越えてゆけ〜

https://speakerdeck.com/techouse/depuroiworen-saretanode-jiao-watutatong-rinidepuroisitarazhang-hai-ninatutajian-an-noyarakasiwoyue-eteyuke

これは共感の嵐でしたね。
私も「デプロイって緑のボタン押すだけだから便利だなあ」などと言っていた時期がありました。

この方がすごいのは、新卒1年目できちんと影響範囲を調査し、起こったトラブルに対して原因の切り分けをしたりソースを読みに行ったりする、ということができているところだと思います。
私が1年目の頃はそんなことできませんでした(白目)
内容としては全く笑えない話を笑い話にするプレゼン力もすごいし、それをカンファレンスで公開できる組織文化も素晴らしいなと思いました。

Capybara+生成AIでどこまで本当に自然言語のテストを書けるか?

https://speakerdeck.com/yusukeiwaki/capybara-plus-sheng-cheng-aidedokomadeben-dang-nizi-ran-yan-yu-notesutowoshu-keruka

業務に関係ない、趣味でやっていた内容の発表とのこと。私もそういうのやりたい。
今回のこの生成AIを使ったテストのすごいところは間違えたときのリカバリができるところだと感じました。
実際のデモも見ましたが、クリックする場所を何度か試行錯誤してフォームに入力していて、おおっと声が出ました。
ちょっと時間がかかりすぎる感じはしたので、将来もっと生成AIの精度が上がったら実用可能になるんじゃないか、と思える夢のある発表でした。

ActiveRecord SQLインジェクションクイズ (Rails 7.1.3.4)

https://speakerdeck.com/kozy4324/activerecord-sqlinziekusiyonkuizu-rails-7-dot-1-3-dot-4

User.exists?(params[:id])にインジェクション脆弱性があるのには驚きました。
Arrayの値をとることがあるんですね。
外部入力を安易に渡してはいけないんだと改めて気を引き締めました。
SQLフラグメントを受け取るメソッド一覧も読んでみます。
https://rails-sqli.org/

OmniAuthから学ぶOAuth 2.0

https://speakerdeck.com/ykpythemind/omniauthkaraxue-buoauth2-dot-0-kaigi-on-rails-2024

OmniAuthだけでなく、そもそもOAuthやOpenID Connectへの理解が浅かったので、この機会に理解したいと思って聴きました。
OmniAuthが裏側で何をやっているのかが説明されていてわかりやすかったです。
リポジトリも公開されていたので、これを眺めながら自分でも実装してみたいと思いました。
https://github.com/ykpythemind/kaigi-on-rails-2024

入門『状態』

https://speakerdeck.com/shinkufencer/state-for-beginners-with-rails

変数の値を変更する回数が多いと最終的な「状態」が分かりづらくなる、ということで、私もそういうコードを読んだことがあるし書いたこともあるので何度も頷いてました。
リファクタリングの観点として「再代入を少なくできるか」が加わったので、とても学びになりました。
また、想定しないところから値を変更されることがないようにメソッドを作成し、メソッド経由でのみ値を変更させるやり方はよく見かけますが、こういうメリットがあったのか〜というのも学びになりました。

omakaseしないためのrubocop.yml のつくりかた

https://speakerdeck.com/linkers_tech/how-to-build-your-rubocop-dot-yml-to-avoid-omakase

技術の話というより、チーム文化の話でした。
omakaseを知らなかったので、まずそこが収穫。
https://koic.hatenablog.com/entry/what-is-rubocop-rails-omakase

障壁である①時間の確保②ファシリテーションの難しさの対策について、
①は定例MTG内で15分ほど時間を取ること、②は(意見を尊重するため)表現の幅を広げ、でも採決ルールは細かくするというのを挙げていました。
ファシリテーションに関してはリファインメントでも使えそうだなと思いました。

やり切れたコツとして準備の担当を自分に固定していたという話をしていてしんどそうと呟いたら、
それに対して回答してくださって嬉しかったです。
忙しいだろうにタイムライン見ていてすごい。

要するに気合でやり切る、みたいな話で覚悟がいるなと思ったので、
私がやるとしたら誰か1人でも仲間いないと続けられなそうと思いました(弱腰)。

来年に向けて

RubyKaigiに続いて今回のイベントも業務として参加しました。
今年は私1人で参加しましたが、想像していた何倍も楽しく、学びになり、高まるイベントだったので
来年は同僚をたくさん引き連れて参加したいです。

また、かっこいいスタッフの皆さんの姿を見て私もKaigi on Railsに貢献したい!と思ったので、
来年はスタッフなど何らかのかたちで関わっていければと思います。
会社としてもRailsにはとてもお世話になっているので、こういったコミュニティに恩返しができないか、模索していきます。

GLOBIS Tech

Discussion