【速報】RubyKaigi 2014レポ：The Twelve-factor Ruby 「Ruby を良くするための12のポイント」

RubyKaigi 2014の参加レポート速報！ 二日目！

Session

9/19(金) 14:00　Hall B The Twelve-factor Ruby 「Ruby を良くするための12のポイント」 GMO Pepabo, Inc. , Hiroshi SHIBATAさん 　

参加レポート

@hsbtさんの自己紹介

• コミッターとしてやったこと

  • removed test-unit
  • removed minitest
  • make bundled gem mechanism
  • coordinate to Ruby Committers
    • Rubyコミッターは協調性がない（笑）
  • nagotiate to sponcers

• Rubyスポンサー企業に感謝！

• GMOペパボについて
  • 新しいプロダクトはRuby
• いろんなプロダクトのコミット権をもらっているので会社では午前の時間を使ってそれらの開発やってる（＝その辺りがよくなると、社内のエンジニアの効率もあがる）

Rubyの開発について

• Rubyのコアクラスはmatzが全てジャッジする
• スタンダードライブラリはメインメンテナー
• バンドルライブラリは@hsbtさん
• コミッターには燃料投下が必要
  • コミッターに適切に問題を伝えることが大事

Rubyをよくする12個のポイント

• Reporting Line
  • tweetでRubyおせーとか型欲しいとかいっても無駄
  • redmine(bugs.ruby.org)
    • 題名とほしい内容を書いてチケット作って
  • GitHub is OK
    • ここでpullrequest作ってコミッターに送る
    • ただ、GitHubはRubyのサブリポジトリ
    • matzもredmineにしか生息していない
      • matzの判断を仰ぐ系の修正とかは必ずredmine
  • your benefit
    • approved later
      • とりあえず出しておくだけでいいことがきっとある
      • ずっと放置されててもめげないで
    • related issues
    • good bikeshed
• usecase
  • その要望、思いが通ると何が嬉しいのか、何に使うのかを説明する
    • このメソッドの返り値はこうであるべき！以上！みたいなチケットが多い
  • Acceptable issue without usecase
    • symmetrical
    • POSIX
    • [BUG] [SEGV]
• codeをつける
  • !!!!!! I propose awesome function !!!!!!!!!!!!!!
    • 誰がつくるの・・・がポイント
    • 基本は欲しいといった人が作るべき
  • bugレポートでもコードをつけるべき
    • 問題の本質がRubyにあるのか、Rubyの上にあるRailsにあるのか切り分けしやすくなる
    • 試しに直してみましたというコードが綺麗である必要はない
  • git format-patch sha1 [dir]
• Naming
  • ここまでの前提があっても、ネーミングがいまいちだと却下される
• Avoid to Red Ocean
  • GCのチューニングとか・・
  • Blue Ocean
    • Win/AIX/Solaris
    • Rails with trunk
      • プロダクションじゃなくていいので、テスト走らせてみるとか、そこで落ちるみたいなフィードバックは大歓迎
    • documentation
• language
  • 日本語 is ok
  • English is better
  • ポイントはできるだけ多くの人に見てもらうことだけど、敷居が高すぎても意味ない
• expectation
  • Good bugreport
    • 直す側が知りたいのはどういう挙動を期待していて、それがどういう結果になったのかという点。
• minimum case
  • 問題が再現する最小限のコード
  • これがあると解決が速い
    • nakadaさんがすぐにパッチしてくれる
  • Railsで落ちましただけじゃわからないので、crashログを貼り付けて欲しい。
    • crashログを見ると、Rubyじゃなくてnative extensionで落ちてるとかわかりやすい
• trunkでも落ちるか
  • バグ修正はtrunkでしか行われず、それを各バージョンのブランチに展開しているので、trunkのどのバージョンで落ちますとかっていうのがあると助かる
• should be good report
• Dev MTG
  • Agenda
    • Matz Judge
    • Issue Triage
    • Release Planning
• Matz approval
  • Matzがいいといったものはいいみたいな文化
  • Matzを説得する技術が求められる（笑）