参加してきました。
内容
rails newしたプロジェクトに、要件をリクエストスペックにしたものが3段階のレベルで1ファイルずつある状態。それらのスペックが通るようにコーディングし、みんなでレビューする。
タイムアタック
まっさらな状態からコーディングすると、意外とシンタックスを正確には覚えていなかったので、Railsガイドを参照しながら進めた。
最新のRailsガイドを見ると、Strong Parametersの書き方が変わっていたので驚いた。
def person_params
params.expect(person: [:name, :age])
end
以前はrequireとpermitの組み合わせだったような🤔
制限時間内に幾つのレベルまでクリアできるか...
本当に誰も喋らない。
私はレベル1を完了するあたりで制限時間ちょうどだった。
レビュー
他の人のコードも含めて、印象に残った項目を挙げていきます。
- モデルバリデーションとDBの制約は両方とも設定しておきましょう
- モデル側には不要、という説もあるけど、一般的な開発体制や後からDBを直接触る可能性を考慮すると、モデルとDBの両方に入れておくのがベター
- createやupdateの際にはロックすると安全
- ある設定された容量に対して、溢れない必要がある要件の場合はロックしてからcreateやupdateすべし。同時リクエストで溢れてしまうのを防ぐ
- emailの正規表現あったよね
- ActionMailerから自動的にActiveJob化してメールを送ってくれる
deliver_laterの機能
- Rigdepoleは便利な反面、大規模プロジェクトや歴史の長いシステムで既存テーブルにカラム追加したりインデックスを張り替えたりする場合にタイムアウトする可能性があり、修正内容をデプロイする前にALTER文を流しておく必要がある。Active Recordマイグレーションなら、差分ごとの適用になるのでその点が便利になる
- annotateをカスタマイズすると、必要な項目をみんなが書いてくれる話
- エラークラスなどは、1つのファイルにたくさん書きたくなるが、参照でコケることがある。本番では一度に読み込んでから実行されるのでどちらでも影響はないが、開発の手間を考えると面倒でも独立ファイルにしたほうが良い
- Structの参照でコケて困ったことがあるので、1行だけでも面倒でも独立ファイルが良い
おわりに
レビュー会はとても盛り上がっていて、日付を超える勢いだった。私は終電間近になったところで先に帰ったが、その後の展開は気になるところ。次回もぜひ行きたい！