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
220
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.5k
Rails 6.0 part 1
yyagi
0
3.5k
About mruby
yyagi
1
84
Rails 5.2(part1)
yyagi
1
1.6k
Rails 5.2(part2)
yyagi
0
1.6k
Ruby 2.5 on Rails 5.2
yyagi
0
110
Thinking about Rails upgrading
yyagi
0
65
Let's Hanami
yyagi
1
620
Here Comes a Rails 5.1
yyagi
1
1.8k
Other Decks in Technology
See All in Technology
Sidekiq vs Solid Queue
willnet
12
7.5k
CAMERA-Suite: 広告文生成のための評価スイート / ai-camera-suite
cyberagentdevelopers
PRO
3
250
ガチ勢によるPipeCD運用大全〜滑らかなCI/CDを添えて〜 / ai-pipecd-encyclopedia
cyberagentdevelopers
PRO
3
180
生成AIとAWS CDKで実現! 自社ブログレビューの効率化
ymae
2
290
アジャイルと契約 エッセンシャル版 / Agile Contracts Essential Edition
fkino
0
110
Hotwire光の道とStimulus
nay3
6
2.4k
サイバーエージェントにおける生成AIのリスキリング施策の取り組み / cyber-ai-reskilling
cyberagentdevelopers
PRO
2
170
AWSコンテナ本出版から3年経った今、もし改めて執筆し直すなら / If I revise our container book
iselegant
13
3.7k
Figma Dev Modeで進化するデザインとエンジニアリングの協働 / figma-with-engineering
cyberagentdevelopers
PRO
1
410
AIを使って小説を書こう!【2024/10/25講演資料】
kamomeashizawa
0
180
使えそうで使われないCloudHSM
maikamibayashi
0
150
Apple/Google/Amazonの決済システムの違いを踏まえた定期購読課金システムの構築 / abema-billing-system
cyberagentdevelopers
PRO
1
210
Featured
See All Featured
BBQ
matthewcrist
85
9.3k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
6.9k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
246
1.3M
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Designing on Purpose - Digital PM Summit 2013
jponch
115
6.9k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.4k
Bash Introduction
62gerente
608
210k
Become a Pro
speakerdeck
PRO
24
5k
What's new in Ruby 2.0
geeforr
342
31k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.8k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
37
1.8k
A Philosophy of Restraint
colly
203
16k
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の中に入る