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.5k
Rails 6.0 part 1
yyagi
0
3.5k
About mruby
yyagi
1
85
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
67
Let's Hanami
yyagi
1
620
Here Comes a Rails 5.1
yyagi
1
1.8k
Other Decks in Technology
See All in Technology
DMARC 対応の話 - MIXI CTO オフィスアワー #04
bbqallstars
1
160
OCI Vault 概要
oracle4engineer
PRO
0
9.7k
Incident Response Practices: Waroom's Features and Future Challenges
rrreeeyyy
0
160
【若手エンジニア応援LT会】ソフトウェアを学んできた私がインフラエンジニアを目指した理由
kazushi_ohata
0
150
Exadata Database Service on Dedicated Infrastructure(ExaDB-D) UI スクリーン・キャプチャ集
oracle4engineer
PRO
2
3.2k
なぜ今 AI Agent なのか _近藤憲児
kenjikondobai
4
1.4k
サイバーセキュリティと認知バイアス:対策の隙を埋める心理学的アプローチ
shumei_ito
0
380
ドメイン名の終活について - JPAAWG 7th -
mikit
33
20k
Evangelismo técnico: ¿qué, cómo y por qué?
trishagee
0
360
100 名超が参加した日経グループ横断の競技型 AWS 学習イベント「Nikkei Group AWS GameDay」の紹介/mediajaws202411
nikkei_engineer_recruiting
1
170
マルチモーダル / AI Agent / LLMOps 3つの技術トレンドで理解するLLMの今後の展望
hirosatogamo
37
12k
透過型SMTPプロキシによる送信メールの可観測性向上: Update Edition / Improved observability of outgoing emails with transparent smtp proxy: Update edition
linyows
2
210
Featured
See All Featured
Building a Modern Day E-commerce SEO Strategy
aleyda
38
6.9k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Measuring & Analyzing Core Web Vitals
bluesmoon
4
120
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
6
410
Fashionably flexible responsive web design (full day workshop)
malarkey
405
65k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
StorybookのUI Testing Handbookを読んだ
zakiyama
27
5.3k
Building Applications with DynamoDB
mza
90
6.1k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
250
21k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
126
18k
Agile that works and the tools we love
rasmusluckow
327
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の中に入る