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

Session

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

参加レポート

@hsbtさんの自己紹介

コミッターとしてやったこと removed test-unitremoved minitestmake bundled gem mechanismcoordinate 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の判断を仰ぐ系の修正とかは必ずredmineyour benefit approved later とりあえず出しておくだけでいいことがきっとあるずっと放置されててもめげないでrelated issuesgood bikeshedusecase その要望、思いが通ると何が嬉しいのか、何に使うのかを説明する このメソッドの返り値はこうであるべき！以上！みたいなチケットが多いAcceptable issue without usecase symmetricalPOSIX[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/SolarisRails with trunk プロダクションじゃなくていいので、テスト走らせてみるとか、そこで落ちるみたいなフィードバックは大歓迎documentationlanguage 日本語 is okEnglish is betterポイントはできるだけ多くの人に見てもらうことだけど、敷居が高すぎても意味ないexpectation Good bugreport 直す側が知りたいのはどういう挙動を期待していて、それがどういう結果になったのかという点。minimum case 問題が再現する最小限のコードこれがあると解決が速い nakadaさんがすぐにパッチしてくれるRailsで落ちましただけじゃわからないので、crashログを貼り付けて欲しい。 crashログを見ると、Rubyじゃなくてnative extensionで落ちてるとかわかりやすいtrunkでも落ちるか バグ修正はtrunkでしか行われず、それを各バージョンのブランチに展開しているので、trunkのどのバージョンで落ちますとかっていうのがあると助かるshould be good reportDev MTG Agenda Matz JudgeIssue TriageRelease PlanningMatz approval Matzがいいといったものはいいみたいな文化Matzを説得する技術が求められる（笑）