酒と泪とRubyとRailsと

Ruby on Rails と Objective-C は酒の肴です!

Rails へのコントリビューションについて調べてみた

Rails へのコントリビューションに関する以下のドキュメントを読んでみました。

この中で特に参考になった部分を中心に書いていきます。


コントリビューションの基礎

  • Ruby On Railsのバグを見つけたら「Issues · rails/rails - GitHub」で既存のものがないか探して、無ければPOST
  • 最新版(edge)はバグがある可能性があるし、バグが有った場合に取り込まれやすいのでコントリビュートのチャンスが多い。コントリビュートのチャンスが多い

セキュリティの問題が見つかった場合

  • GitHub ISSUEにあげてはダメ(悪用される可能性があるから)
  • Ruby on Rails: Security policy」あたりにセキュリティのISSUEの立て方が書かれています。

バグなどのISSUE

  • ISSUEには再現可能なサンプルコードをつけよう
  • 実行可能なテストケースをちゃんと作ろう。テストケースのテンプレートを活用しよう => 1.2 Create an Executable Test Case - Ruby on Rails Guide Contributing to Ruby on Railss
  • テストケースは、gistなどに貼って使おう
  • バグの調査に役立つ情報があれば、ISSUEに書き込もう
  • failするテストはコントリビュートのチャンスだ

テストバッチ

  • forkしてテストパッチを作ろう
    • 変更が確実に動作しているかを確認しよう
    • テストによってより良くなっているか?変更点のテストがきちんと存在しているか?
    • ドキュメンテーションが適切にアップデートされているか?
    • 変更点はコードとして適切で、高速に動作するか?

Gistのテンプレート

ActiveRecordActionController のgistテンプレートのです。バグをレポートするときに使います。

機能追加のリクエストについて

  • 必ず動作するパッチを作ってGitHubにISSUEを作ろう(動作するパッチがない場合はinvalidになる)
  • 機能追加は他の機能に影響を与える可能性があるのでコアチームによって判断される
  • アイデアを相談したいときは「rails-core mailing list」に投げてみよう

健全性のチェック

もしRails開発者の知り合いがいるなら、予め修正したコードをみせることで、 適切なコードか否かをちゃんとチェックしよう。

Feedbackを受けよう

Merge Request を出したら、幾つかのフィードバックや意見が来るので対応しよう。 マイナーチェンジは悪いことじゃないのでポジティブに意見を受け入れよう。 あまりにも Merge Request に反応がないようなら、MLにPostしてみよう。

コードを書くときの注意点

バグフィックスや機能追加でコードを書く際には以下の点に注意しよう。

- 正しいコードを書こう
- Railsのイデオム/Helperを適切に書こう
- テストが通過しない場合は、テストが通過するように修正しよう
- 変更点に関するドキュメントもアップデートをお忘れなく

Railsのcoding style

- 2スペースを使う。タブは使わない
- 不要なスペースをつけないようにしよう
- private/protectedの後はindentをつけよう
- 1.9以降のhashシンタックス { a: b } を使おう
- `&&` や `||` を使おう
- `class << self` を使おう
- `MyClass.my_method(my_arg)` が望ましい
- `a = b` としよう
- `assert_not` を使おう
- `{ do_stuff }` としよう

パフォーマンスに影響する変更

  • gem 「benchmark-ips 等を利用してベンチマークを取ること。
1
2
3
4
5
6
7
8
9
10
11
12
13
require 'benchmark/ips'

Benchmark.ips do |x|
  x.report('addition') { 1 + 2 }
  x.report('addition with send') { 1.send(:+, 2) }
end

Calculating -------------------------------------
            addition   132.013k i/100ms
  addition with send   125.413k i/100ms
-------------------------------------------------
            addition      9.677M (± 1.7%) i/s -     48.449M
  addition with send      6.794M (± 1.1%) i/s -     33.987M

テストの実行

テストの実行方法は次の通り。

1
2
3
4
5
6
7
8
9
10
11
12
13
# Rails 全体のテスト
$ cd rails
$ bundle exec rake test

# ActionMailerに関するテスト
$ cd actionmailer
$ bundle exec rake test

# ActiveRecordに関するテスト DBの種類ごとのテストも可能
$ cd activerecord
$ bundle exec rake test:sqlite3
$ bundle exec rake test:mysql2
$ bundle exec rake test:postgresql

ドキュメンテーション

Rails には次の2つのドキュメントがある;

Ruby on Rails Guides - help you learn about Ruby on Rails,
APIドキュメント - serves as a reference.

また、それぞれにガイドラインがあるので読んでみよう。

それから、ドキュメンテーションの変更だけの場合は CI を動かす必要はない。 [ci skip] をつけよう。

CHANGELOGをちゃんと更新しよう

1
2
3
4
5
6
7
8
9
10
11
12
*   Summary of a change that briefly describes what was changed. You can use multiple
    lines and wrap them at around 80 characters. Code examples are ok, too, if needed:

        class Foo
          def bar
            puts 'baz'
          end
        end

    You can continue after the code example and you can attach issue number. GH#1234

    *Your Name*

コミットメッセージ

コミットは1つにsquashしておこう。そして、コミットメッセージも簡単なサマリーをちゃんと書こう。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Short summary (ideally 50 characters or less)

More detailed description, if necessary. It should be wrapped to
72 characters. Try to be as descriptive as you can. Even if you
think that the commit content is obvious, it may not be obvious
to others. Add any description that is already present in the
relevant issues; it should not be necessary to visit a webpage
to check the history.

The description section can have multiple paragraphs.

Code examples can be embedded by indenting them with 4 spaces:

    class ArticlesController
      def index
        render json: Article.limit(10)
      end
    end

You can also add bullet points:

- make a bullet point by starting a line with either a dash (-)
  or an asterisk (*)

- wrap lines at 72 characters, and indent any additional lines
  with 2 spaces for readability

あと、ちゃんとリベースしておこう。

1
2
3
4
5
$ git checkout master
$ git pull --rebase

$ git checkout my_new_branch
$ git rebase master

Forkしよう

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 自分のリポジトリをForkして作ろう
$ git remote add mine git@github.com:<your user name>/rails.git
# 自分のリポジトリへのpush
$ git push mine my_new_branch

# rails 本家のブランチをremoteに追加
$ git remote add rails git://github.com/rails/rails.git

# rails 本家をfetch
$ git fetch rails

# rails/masterでリベースしよう
$ git checkout master
$ git rebase rails/master

バックポーティング(BackPorting)

次のメジャーリリースまでにHEADの変更を取り込みたい場合は、patchを作って自分のブランチに適用しよう。

1
2
3
4
5
6
7
8
9
# master と HEAD(現在のブランチ)とのdiffを取る
$ git log master..HEAD

# patchを作ろう
$ git format-patch master --stdout > ~/my_changes.patch

# 自分のブランチにpatchを適用仕様
$ git checkout -b my_backport_branch 3-2-stable
$ git apply ~/my_changes.patch

開発環境の構築

テスト用のアプリを作る

1
2
$ cd rails
$ bundle exec rails new ~/my-test-app --dev

コントリビューターの一覧

Rails Contributors

あとがき

英語のドキュメントを読みながら書いたので間違っている部分も多々あると思います。もしお気づきの点等あれば @zyunnosuke まで

Special Thanks

おすすめの書籍