Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Railsコントリビューション
Search
y-yagi
October 19, 2017
Technology
0
230
Railsコントリビューション
Rails Developers Meetup #6
y-yagi
October 19, 2017
Tweet
Share
More Decks by y-yagi
See All by y-yagi
Rails 6.0 part 2
yyagi
0
3.6k
Rails 6.0 part 1
yyagi
0
3.6k
About mruby
yyagi
1
95
Rails 5.2(part1)
yyagi
1
1.6k
Rails 5.2(part2)
yyagi
0
1.7k
Ruby 2.5 on Rails 5.2
yyagi
0
120
Thinking about Rails upgrading
yyagi
0
84
Let's Hanami
yyagi
1
660
Here Comes a Rails 5.1
yyagi
1
1.8k
Other Decks in Technology
See All in Technology
Devin(Deep) Wiki/Searchの活用で変わる開発の世界観/devin-wiki-search-impact
tomoki10
0
230
Introduction to Sansan for Engineers / エンジニア向け会社紹介
sansan33
PRO
5
38k
Grafana MCP serverでなんかし隊 / Try Grafana MCP server
kohbis
0
310
Bill One 開発エンジニア 紹介資料
sansan33
PRO
4
12k
CSSの最新トレンド Ver.2025
tonkotsuboy_com
11
4.4k
Snowflake Intelligenceで実現できるノーコードAI活用
takumimukaiyama
1
160
New Cache Hierarchy for Container Images and OCI Artifacts in Kubernetes Clusters using Containerd / KubeCon + CloudNativeCon Japan
pfn
PRO
0
140
OpenTelemetry Collector internals
ymotongpoo
5
510
AWS Lambdaでサーバレス設計を学ぼう_ベンダーロックインの懸念を超えて-サーバレスの真価を探る
fukuchiiinu
4
960
Contract One Engineering Unit 紹介資料
sansan33
PRO
0
6.3k
Digitization部 紹介資料
sansan33
PRO
1
4.2k
エンジニア採用から始まる技術広報と組織づくり/202506lt
nishiuma
8
1.6k
Featured
See All Featured
Automating Front-end Workflow
addyosmani
1370
200k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
35
2.3k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
A Modern Web Designer's Workflow
chriscoyier
693
190k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
47
2.8k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
How to Ace a Technical Interview
jacobian
276
23k
How to train your dragon (web standard)
notwaldorf
92
6.1k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.7k
Faster Mobile Websites
deanohume
307
31k
Why You Should Never Use an ORM
jnunemaker
PRO
56
9.4k
Art, The Web, and Tiny UX
lynnandtonic
299
21k
Transcript
Rails コントリビューション @y-yagi
自己紹介 • @y-yagi • Ginza.rbの主催の一人
今日お話すること 過去のRailsへのコントリビュートの経験を元に、 RailsにPRを送る際にどのような事に気をつければ良いか、どう すればPRを送れるようになるかをご紹介出来ればと思います。
自己紹介 • Rails Contributors(http://contributors.rubyonrails.org)では24 位(598コミット) • 最初のコミットが2014-07-15なのでコントリビュートしはじめて3年 4ヶ月
Rails Contributors • Railsのcore memberの一人であるXavier Noria(@fxn)が作成した サイト • OSS( https://github.com/fxn/rails-contributors
) • マージコミットやバックポートのコミットもカウントされる • また、コミットメッセージに特定のフォーマットで名前を記載した場 合、その記載されている名前全てコントリビューターとしてカウント される • なので、GitHub上でのコミット数とは大分事なる
何故コントリビュートするようになったの か
コミットログを読んでいる
コミットログ • Railsのコミットログを読んでブログにメモを記載するという事をやっ ている • 2014-04-07から
コミットログ • 当時、なんとなくRailsを使ってコードは書けるが、ちゃんとした書き 方がわからないなあと思うことが多かった • ちゃんとRailsについて勉強したいなと思い、色々考えた結果コミッ トログを読み始めた ◦ あと当時暇だった
読み始めた結果どうだったか
コミットログ • わからない事だらけ • コンポーネントの構成がどうなっているとか、クラスの継承関係等 がさっぱりわからなかったので • 何でこれで動くの…? という事が多かった
コミットログ • わからなかったら動かして確認した ◦ Railsは動かすのが簡単 • 割とテストがちゃんと書かれるようになっていた頃だったのでテスト をよく見ればなんとなく意図がわかった
コミットログ • 2,3ヶ月もするとなんとなくRailsのコードに慣れた • 慣れると色々とミスに気付くようになる ◦ docに記載されている説明と実際の挙動が違う、そもそも動かない、等々 • 問題がある状態をそのままにしておくのは良くない •
この頃からコントリビュートをはじめるようになって今に至る
本題
Rails コントリビューション
どういう時にコントリビュートするのか • Railsが期待通りに動かないとき • Railsに機能追加したいとき
期待通りに動かない • まあまあある ◦ バグなのか仕様なのか難しい問題もある • Railsは良く使う道具なので期待通り動いて欲しい ◦ よく使う道具が期待通りに動かないとストレスになる •
SNSで文句を言っても直らない
期待通りに動かない • Issueをつくる or PRをつくる ◦ Issueをつくるのも大事なコントリビュート • 英語が苦手なので、私はPRを投げてしまう事の方が多い
機能追加したいとき • 新しく追加された機能は大体機能が足りない • Railsは良く使う道具なので機能が足りてて欲しい
Rails コントリビューション • 具体的なアプローチについて • なお、ここでの説明は https://github.com/rails/rails のみを対象と して話します ◦
github.com/rails 配下の他のリポジトリだと方針が多少違う事もある
Rails コントリビューション • コントリビュートの方法について記載したRails guide(http://edgeguides.rubyonrails.org/contributing_to_ruby_ on_rails.html) もあるので、こちらも合わせて参照してください ◦ ちょっと内容古い部分もあるが……
Issue
Issue • rails/railsのIssueはバグの管理にのみ使われいる • 質問や新機能の提案などには使われておらず、それらのissueを 作成しても、無視、又は即closeされる ◦ https://github.com/rails/rails/issues/30762#issuecomment-333337344 のよう になる
• Core member / committerが機能提案にIssueを使う事もあるが、 基本的にはNG
Issue • 新機能についての議論をしたい場合は rails-core mailing list(https://groups.google.com/forum/?fromgroups#!forum/rub yonrails-core)へ • PR投げちゃってPR上で議論をするでも大丈夫 ◦
どちらかというとこっちの方が多い印象
Issue • バグ報告用にIssueテンプレートが用意されているので出来ればそ のフォーマットに従う ◦ https://github.com/rails/rails/blob/master/.github/issue_template.md • バグの報告をする際は(可能な限り)再現手順を記載する
Issue • 再現手順作成用のテンプレートファイルが用意されているので使え るならそれらを使用する ◦ https://github.com/rails/rails/tree/master/guides/bug_report_templates ◦ 上記テンプレートを使用すると、ファイル単体でActie RecordやActive Jobを使用し
たスクリプトが準備出来る • 上記を使って手順を再現するのが難しい場合、GitHub上に再現手 順をまとめたRailsアプリをアップロードしてくれたりすると大変助か る ◦ 例:https://github.com/saneef/reproduce-couldnt-find-template-for-digesting
Issue • masterブランチでも問題が再現するか確認する • サポート対象外の古いRailsでのIssueを報告しても即close or 無視 されるので、古いRailsを使っている場合はまず頑張ってRailsの バージョンを上げる ◦
メンテナンスポリシーについては http://guides.rubyonrails.org/maintenance_policy.html 参照
Pull request
Pull requestを出すその前に • 似たようなPRがもう無いかGitHubで検索してみる ◦ OpenされているPRだけではなくClosedになっているPRも検索する • 幸いRailsは早い時期にGitHubに移行したため、GitHubを検索す れば大体事足りる
Pull requestを出すその前に • 同じようなPRがあってそれがMergeされる事無くCloseされている なら何故Closeされてしまっているかを確認する • 理由を確認した上でそれでもPRを投げたいならPRのdescription にそのあたりの理由もちゃんと記載する
Pull requestを出すその前に • 同じようなPRがやりとりが止まってしまっている事もある • そのPRの作者にpingしてまだやる気ある? というのを確認してみて みる ◦ やる気なさそうなら引き継いでやってしまう
◦ 一言断り入れてからやるのが紳士的
Pull requestを出すその前に • その機能本当にRails本体にいる? かを考える • gemじゃ駄目なのか考えてみる ◦ リリースとかテストとかgemの方が楽な事も多い •
foreignerやmigration_commentsのように、gemから機能を本体 にインポート、みたいなケースもある
Pull request 実際にPRを出す際に気をつけていること
Pull request • こちらもフォーマットが用意されているので出来ればそのフォーマッ トに従う ◦ https://github.com/rails/rails/blob/master/.github/pull_request_template.md • descriptionちゃんと書くの大事 •
既にIssueがあるBugの修正の場合コミットログにそのIssueの番号 を入れる ◦ 例: https://github.com/rails/rails/commit/52422f2af60c0830da6e5749700f911c6 c0b22ea
Pull request • コードの修正や機能追加の場合、テストの実行・追加を忘れずに • テストの実行方法はちょっとややこしいので割愛 • 大体はbundle exec rake
testで動く • 予想外の所が壊れる事があるので、CIの結果も確認する ◦ CIちょっと不安定なので全然関係無いところがエラーになってしまう事もある……
Pull request • docやコード内のコメントの修正の場合CIが実行されないようコミッ トログに"[ci skip]"をいれる ◦ 例: https://github.com/rails/rails/commit/88dc74b78468546748fdfdc4133e153ef cc1f1c9
• "[skip ci]" でも大丈夫 ◦ https://docs.travis-ci.com/user/customizing-the-build/#Skipping-a-build • RailsのCIは割と時間がかかるので、不要な場合はCIを実行しない ようにする必要がある
Pull request • 性能改善のPRの場合、 性能チェックに使ったスクリプト及び結果を そのままコミットログに入れてしまう ◦ 例 :https://github.com/rails/rails/commit/338127869a4b62ddda5c75647ac1fb9 28361db70
• コミットログに入れておくと、後からコミットを見た人が直ぐ結果の再 取得が出来てちょうべんり • 性能チェック用のスクリプトファイルのフォーマットも提供されている ◦ https://github.com/rails/rails/blob/master/guides/bug_report_templates/bench
Pull request • コミットログに説明が必要な事は全て入れてしまう ◦ PRのdescriptionに記載が必要な内容はコミットログに全部入れるようにしている • 後から何か確認したい時にコミットログを見れば済むので大変楽 例 :https://github.com/rails/rails/commit/ffc4710c2bff273b82dd
b76675701f986d82ef4f
Pull request • その対応が何故必要なのか、何故妥当なのかの説明もコミットロ グに入れている • 証拠や参考になるコミットやPRがあればそれへのリンクも入れる ◦ 例: https://github.com/rails/rails/commit/0e47e58a96c2cd6d7f655d0ccf35737ac
5fbf80c
Pull request • レビュアーの負担を減らせるよう、必要そうな情報はすべて渡す ◦ レビューする側がRailsすべての機能に対して詳しいとは限らない ◦ そのPRを作ったあなたの方が詳しい、という事も普通にある
Pull request • public APIの挙動を変えない ◦ Railsにおけるpublic APIとは API doc(http://api.rubyonrails.org/)にのっているAPI
• public APIの挙動を変えたい場合はまずDeprecateから ◦ https://github.com/rails/rails/commit/58f10a31b37e9bb6e975a71aa63744f3 18ee043d ◦ https://github.com/rails/rails/commit/fbcc4bfe9a211e219da5d0bb01d894fcd aef0a0e
Pull request • 適切な単位にcommitをsquashする ◦ rails/railsではPRは一つのcommitになっている事が望まれる ◦ Reviewの指摘対応のcommitもsquashして一つにする
コントリビュートをしてみたい、と思って いるが何からはじめたら良いかわから ない方に
コントリビューションのはじめかた • 公式のdocを見る • 新しいバージョンをさわる
doc • Railsの公式のドキュメントは二つ • http://api.rubyonrails.org/ と http://guides.rubyonrails.org/ • 上記二つはリリース済み(gemとして公開されている)のRailsに対応 している
• edge(GitHubのmasterブランチ)版は http://edgeapi.rubyonrails.org/ と http://edgeguides.rubyonrails.org/
doc • 普段から公式のドキュメントを見る癖をつける • ドキュメントは今は全てrails/railsリポジトリで管理されているので、 内容が間違えてる・フォーマットが崩れている等があればPRチャン ス ◦ 割とよくある
新しいバージョンをさわる(Rails) • 新しいバージョンをちゃんと触る ◦ rcをまたずbeta1が出たらすぐ試す • 新しい機能はだいたいバグがある • 既存のコードも割と壊れる事がある •
壊れてたらコントリビュートのチャンス
新しいバージョンでさわる(Ruby) • Rubyの機能追加・変更に伴いRails側で対応が必要な事がある ◦ Ruby 2.5の場合、Hash#transform_keysが追加されたことによる対応等 • テストが壊れる事もある • コントリビュートのチャンス
Issuesを見る • 適当なIssueをピックアップしてバグフィックスしてみる ◦ コードを見る際の取っ掛かりとしてIssueを利用する • 意外とやってみると簡単に直せるバグもある
コントリビューションの壁? • 英語が出来ない • 何か怖い
英語が出来ない • 私も出来ない • コミットログやPRを参考にする
コミットログやPRを参考にする • コミットログを適切そうな単語で検索してみる ◦ rails/railsには大量のコミットログがある • 同じ事をしているコミットやPRを見つけて参考にする ◦ rails/railsには大量のissue /
PRもある • 私はgit log + pecoでコミットログを検索できるようにしてる
何か怖い • たまにきく • 普段やらない事や慣れていない事に不安に感じるのはしょうがな い
何か怖い • これについては慣れるしか無い ◦ 誰も怒らないので、とりあえず気になる事があったらやってみる • 普段OSSにコントリビュートしている知り合いに協力してもらう等が 出来ると良さそう • そういう知り合いがいない場合、OSS
Gate(https://oss-gate.github.io) に参加してみるのも良いと思いま す • Rubyのコミュニティに行って相談してみる、とかも良いと思います
まとめ • 私が普段コントリビュートしている事について説明しました • ただ、こういう事は慣れてきたら気にする、位で良いと思います • Issueを報告する際はテンプレートに従う事と再現手順をつけること • PRを投げる際はdescriptionをちゃんと書くこととテストが通ること •
位が出来れば大丈夫
Appendix(時間があまったときよう) Rails 5.2つまみぐい
Active Storage • ファイルアップロード処理用ライブラリ ◦ carrierwave や shrine の仲間 •
クラウドサービスに簡単にファイルをアップロード、及び、Active Recordから参照ができるようになっている • https://speakerdeck.com/willnet/file-upload-2017 に良くまと まっているので詳細は左記参照
Early Hints for HTTP/2 • https://github.com/rails/rails/pull/30744 • HTTP/2のEarly Hints対応 •
今のところはPumaじゃないと動かない
credentials.yml • https://github.com/rails/rails/pull/30067 • 秘密情報を保持する為の新しい仕組み ◦ アプローチはEncrypted Secretsと同じ • config/secrets.yml、config/secrets.yml.enc、
SECRET_BASE_KEYはお役御免
recyclable cache keys • https://github.com/rails/rails/pull/29092 • fragments cachingのcache keyのフォーマットが再利用可能な フォーマットに変わる
• 元々はcache keyにassocationのversion(timestamp)を含んでい たが、これは含まなくなる ◦ cache keyとcache versionが別に管理される ◦ version情報はcacheの中に入る