「銀座Rails#15」に参加して Rails の設計と貢献方法についてのヒントを得た

「銀座Rails#15」 に参加してきました．今までにも何回か参加したことがありますが，ふと「そういえば最近，イベントレポート書いてないぞ！」と思い，イベント内容の復習も兼ねてイベント内容と感想をまとめていきます．

ginza-rails.connpass.com

出張！Railsウォッチ in 銀座Rails @morimorihoge

• 11/5 に Rails 6.0.1 がリリース
• 11/7-8 RubyWorld Conference 2019 が開催
  • Ruby Prize で糸柳さんが受賞
    • スピーチがとても良い話
• production? development? staging? の意味がややこしい
  • これらの用語はプロジェクトによって
    • アプリケーションの動作モード
      • Rails における「RAILS_ENV」
    • deploy 先のサーバー環境
    • Git のブランチ・タグ名

  など様々な意味合いが含むことがあることで，チームメンバーが混乱すること・想定外なオペレーションミスが起きる要因の一つになる．

  • 混乱を防ぐために用語のルールを設ける
    • 「RAILS_ENV」を指す場合は「モード」をつける
    • サーバー環境を指す場合は「サーバー」をつけたり，別の単語を使う
    • Git のブランチ・タグ名を指す場合はブランチ・タグ名であることを明示する

今回が 4 回目となる「出張！Railsウォッチ」は雑多なテーマを取り上げた内容でした．「production? development? staging?」の内容は，私が経験してきた開発の中では特段大きな混乱や事故などはありませんでしたが，言われてみると確かに開発をする上で混乱のもとになるケースの一つだと思いました．

Slack などのチャットでのコミュニケーションはスピードを求められることがあります．その場面でも省略化せず，明確な用語でコミュニケーションを取る必要があると感じました．

「公開つっつき会」が毎月第一木曜日に開催しているとのことなので，参加してみたいと思いました． techplay.jp

Service クラスと Form Object をやめよう。サブクラスを使おう @yalab

• そもそも service クラスとは？
• PoEAA や DDD などの service レイヤーからの出自だと思われるが，プロジェクトや人によって定義が曖昧なケースが多い
• 乱用が多く，コードレビューがし辛い
• service クラスはそもそも fat model を何とかするために使うようになった
• model を分割して責任範囲を分割したいならサブクラスで分割しよう
• 責務からコードの振る舞いを定義しよう

開発するプロダクトの規模が大きくなるにつれて，どのチームでも直面する話だと思いました．service クラス．．．私もこのクラスとの向き合い方は普段から悩まされています．

サブクラスを使うというやり方については賛否両論がある雰囲気でしたが，個人的には「あ！そういうやり方があるんだ！！」と素直に参考になりました．

どの方法がベストかや銀の弾丸になるかを決めるのではなく，開発するプロダクトやチームメンバーによって，どの方法を取り入れることで fat model を何とかできそうなのかを考えることが大事であると思いました．

serviceクラスをやめようサブクラスを使おう from よしだ あつし

個人アプリをRails 6.0.0rc2に上げたらバグを踏んだのでRailsにIssueを投げた話 @shiroemons

• Rails 6.0.0rc2 に Issue を投げた話
• 「Rails 6 リリースするか？ Party」への参加をきっかけに個人アプリの Rails のバージョンを上げることに
• Active Model の COUNT のエイリアスのアンダースコアが 2 つになっているを発見
  • 例: count__articles_id
• 「Rails ガイド」の「Ruby on Rails に貢献する方法」を参考に再現コードを作成． railsguides.jp
• Issue のタイトルで悩んでいたので「ruby-jp」コミュニティの「#rails」で質問・相談
  • 再現コードのエラーをタイトルにすることに
• Rails に Issue を投げることができた！バグも無事に修正された！
• Issue を投げる時は再現コードのあるリグレッション報告をするのが最強
• @kamipo さんはすごい人

「Rails 6 リリースするか？ Party」をきっかけに，個人アプリの Rails のバージョンを 4.2 から 6.0.1 に怒涛の勢いで上げた @shiroemons さんの発表．個人アプリへのプロダクト愛もとても伝わった内容でした．

私は「rc のバージョンは開発中だからあまり触らないでおこう」というような考え方をしていましたが， Rails へ何かしら貢献したい気持ちがあるなら，むしろ rc をどんどん触っていくのが良いことがよくわかりました．

私も過去に「OSS Gate」のイベントに参加した時に 「RubyGems」に Issue を出したことがあります．「ruby-jp」コミュニティと併用するとさらに良さそうだと思いました．

今度はプルリクエストを出すのも挑戦していくぞ！！

oss-gate.doorkeeper.jp

@kamipo さん と @yahonda さんのフリートーク

• @kamipo さんの Rails のプルリクエストを皆で見ていく内容
• 本当にほぼノープランだったのか？と思うくらいの @yahonda さんの進行の上手さ
• プルリクエストはまずテストケースを見ていく
• 紹介されたプルリクエスト
  • Maintain eager loading joining order as before by kamipo · Pull Request #37235 · rails/rails · GitHub
  • commit 成功されるのに rollback されちゃう
    • Rollback in `after_commit` should not rollback state that already been succeeded by kamipo · Pull Request #37251 · rails/rails · GitHub
  • Fix new instance creation on association relation to respect unscope by kamipo · Pull Request #37511 · rails/rails · GitHub
  • Fixed performance regression introduced MySQL 8.0 by alpaca-tc · Pull Request #37465 · rails/rails · GitHub
  • @kamipo さん の最初のプルリクエスト
    • Use `SchemaStatements#initialize_schema_migrations_table` instead of `ActiveRecord::SchemaMigration.create_table`. by kamipo · Pull Request #12962 · rails/rails · GitHub
  • Only use BINARY for mysql case sensitive uniqueness check when column has a case insensitive collation. by kamipo · Pull Request #13040 · rails/rails · GitHub
• これから Rails に貢献していきたい人は「good first issue」を見てみよう
  • 内容が「good first」ではない場合もある😅
• プルリクエストを作る時は，解決したい現象を必ず解明しよう
  • 現象を解明しないと大抵はマージされない
  • 現象が解明されていて必要十分なプルリクエストは，コードレビューで質問することが無いため，ほぼ無言でマージされることがある
  • 見本となるプルリクエスト
    • Don't recursive call for value local variable that type is Array in `ActiveSupport::ParameterFilter::CompiledFilter#value_for_key` by kamillle · Pull Request #37689 · rails/rails · GitHub

時間が許す限りで @kamipo さんが作成してきたプルリクエストを皆で見ていきました．特に「commit 成功されるのに rollback されちゃう」のを解決したプルリクエストは盛り上がりました．

「再現コードは必ず作る」，「@kamipo さんでも Rails に初めて貢献した時があった」などのエピソードはこれから Rails に貢献したい人の肩を押してくれるとても良い内容でした．

まとめと所感

• 「銀座Rails#15」に参加してきました
• 開発をする上で，用語は明確化することと fat model を解決するための一つの解決策・ Rails への貢献方法の事例を学びました
• 普段の開発で思っていることと共感する内容が沢山あった
• 登壇者・参加者の皆さん，スポンサーの Forkwell・SONY さん ありがとうございました！