何でも屋エンジニアのブログ

ソフトウェア関連技術、コミュニティ、日々の雑貨

Step-to-Rails-Expert.rb第11回を開催しました

9/25(月)にStep-to-Rails-Expert.rb第11回を実施しました。

step-to-rails-expert-rb.connpass.com

流れ

当日の流れは

  • 自己紹介
  • レビュー会
  • 懇親会

という形で進めました。

会の様子

今回は、主催者とスタッフのtwo_sannの二人分のレビューを行いました（他にもチャレンジしてくださった方がいましたが時間が足りなかったそう）。 元リポジトリはこちら

github.com

結構いろいろな指摘・質問・議論が出てきました。一部を並べると

  • nullを許容するようなカラムにはnull: false, default: '' の方が良いのでは
  • 文字列とシンボル両方かならシンボルの方が（本当に若干）パフォーマンスが良い
  • bulletで、N+1クエリがあったら例外投げる設定がある
  • I18n#l便利
  • I18nを使う場合、viewでplaceholder: trueにyamlに使用する文字列を定義することができる
  • 1コミットはテストが通る状態がベスト（あくまでベスト）なので、rubocopのコミットはなるべく別コミットにしない方が良い
  • Strong Parameterで、params.require(:task).permit(Task.columns.map(&:name).map(&:to_sym))（全てのカラムを許可する）はカラムが増えたときに危険
  • POSIX準拠違反（See: https://www.slideshare.net/koic/stairway-to-the-pragmatic-rails-programmer#54）

I18n周りの機能について色々知れて勉強になりました。 また、nullを許容するか否かについて、個人的には「ない状態」を表すためにnullではなく""を使うと、場合によってはnullを使用し別の場合は""を使用するケースがあり、複雑性が増すのではと思っていたので、極力nullableなカラムを定義しないようにし（テーブル分割する）、やむをえない場合はnull可にするという方向性で考えていました。 ですが、そもそも意味論的にnullより""の方がふさわしいです。nullは不明な状態なので、""とは意味が違います（指摘され思い出した）。あとはGemでカラムを生やすものは、null: false, default: ""を使っているのが多いので、統一できるという利点もあると思い考えを改めました。あとは空文字だとユニーク制約にひっかかってしまうので、validates :hoge, uniqueness: true, if:のように:ifオプションをつけないとなぁと思うなどしました。 ところで、カラムにNULLを許可する弊害については以下の書籍がとてもわかりやすく解説しているので、ぜひ一読することをおすすめします。 gihyo.jp

議論の中で紹介されたリンクを貼っておきます。

次の仕様

必須以外はランダムで選びました。この中から、順番に解いても例えばLevel 3だけでも解いても良いです。 前回までの課題の最小仕様までを自分で実装して頂いても構いません。

  • 必須: タスクの状態変更（単数タスク）
  • Level 1 is: 通常ユーザーの作成時に確認メールを送信する
  • Level 2 is: タスクへのファイルのアタッチ（複数）
  • Level 3 is: タスクの状態変更（複数一括）

次回について

次回は10/30（月）で、ExpertTodoのもくもく回です！ 今まで参加したことない方は、雰囲気をつかむのに丁度良いのでぜひご参加ください。普段参加されている方もぜひ来てくださいね。 なお、途中参加も可能なので、既に最小実装をしてある人のリポジトリをforkするなどしてぜひご参加頂ければと思います。 ご興味ある方は、Step-to-Rails-Expert.rbのslackへこちらから招待を受けてください。