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
OSS初心者がつまづきながらOSSマナーを学んでいく話
Search
fuqda
July 05, 2019
Programming
3.5k
4
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
OSS初心者がつまづきながらOSSマナーを学んでいく話
Tama Ruby会議01の発表資料です。
fuqda
July 05, 2019
More Decks by fuqda
See All by fuqda
Composition API時代の Pub/Subパターンでの状態管理
fuqda
4
4.1k
RubyでPrettierを使ってみた
fuqda
0
420
RSpecによるOpen API自動テスト
fuqda
3
1.2k
OSSへの プルリクエスト作成の手引き
fuqda
1
360
Rails Girls Tokyo 13th Sponsor LT by STORES
fuqda
0
260
黒歴史リポジトリを使ったリファクタリング勉強法のススメ
fuqda
1
1.2k
Ruby2.7の新機能で簡易版Rubyインタプリタを実装してみる
fuqda
0
660
カンファレンスで技術的お土産を 増やすために出来ることを考えた
fuqda
2
610
Other Decks in Programming
See All in Programming
AI時代に設計が 最大の生産性レバーになる 意図駆動開発とデータを消さない設計|Don't Delete Your Data or Your Intent — Design as the Deepest Lever in the AI Era
tomohisa
0
120
Embedded SREと共に達成した会員管理システムのAWS移行 - SRE NEXT 2026 ランチスポンサーセッション
niftycorp
PRO
1
3.2k
AWS CDK を「作」ってみた 〜フルスクラッチで見えた CDK の裏側〜 / aws-cdk-from-scratch
gotok365
3
2.6k
OpenSpecのproposalにbrainstormingを持たせてみた
tigertora7571
1
140
php-fpmのプロセスが枯渇した日-調査・対処・そして本当にやるべきだったこと-
shibuchaaaan
0
170
「正の参照」と 「負の導出」で組む ハーネスエンジニアリング
cottpan
1
150
変わらないものが、変わるものを決める — 意図駆動開発 × イベントソーシング × イミュータブル | What Doesn't Change Decides What Can — IDD × Event Sourcing × Immutability
tomohisa
0
690
地域 SRE コミュニティ最前線 - ホンマでっかSRE勉強会
tk3fftk
0
280
壊れたパーサから始める関数型設計と構成的なパーサ #fp_matsuri
raiga0310
2
420
型も通る、synthも通る、それでも危ない 〜AIのCDKの権限とコストを機械で検証する〜 / It Passes Type Checks, It Passes Synth Checks, but It’s Still Risky — Automatically Verifying Permissions and Costs in AI’s CDK —
seike460
PRO
1
480
AI時代のPHPer生存戦略 ~「言語、もうなんでもよくない?」に本気で向き合う~
vivion
0
210
えっ!!コードを読まずに開発を!?
hananouchi
0
280
Featured
See All Featured
The Director’s Chair: Orchestrating AI for Truly Effective Learning
tmiket
1
220
XXLCSS - How to scale CSS and keep your sanity
sugarenia
249
1.3M
How to make the Groovebox
asonas
2
2.3k
Digital Projects Gone Horribly Wrong (And the UX Pros Who Still Save the Day) - Dean Schuster
uxyall
1
2.1k
職位にかかわらず全員がリーダーシップを発揮するチーム作り / Building a team where everyone can demonstrate leadership regardless of position
madoxten
64
56k
SEO for Brand Visibility & Recognition
aleyda
0
4.6k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
49
10k
From Legacy to Launchpad: Building Startup-Ready Communities
dugsong
0
270
Mobile First: as difficult as doing things right
swwweet
225
10k
Lessons Learnt from Crawling 1000+ Websites
charlesmeaden
PRO
1
1.5k
Making Projects Easy
brettharned
120
6.7k
Accessibility Awareness
sabderemane
1
160
Transcript
OSS初心者がつまづきながら OSSマナーを学んでいく話 Tama Ruby!"01 2019.07.06 @fuqda90
fuqda(ふくだ)と申します! ・Tama.rb Organizor ・Ruby/Rails歴 1.5年〜 fuqdaと申します ・Tama.rb Organizor !Ruby /
Rails"1#$
fuqda(ふくだ)と申します! ・Tama.rb Organizor ・work@STORES.jp, inc. ・Ruby/Rails歴 1.5年〜 本日のお話
(OSS初心者&経験の浅いプログラマーが) 失敗の中で OSSマナーを 学んでいく話
自分は強くないけれど... 憧れの先輩方を 真似て始めてみたら 学びが深くなったので オススメしたい
こう言う人がいる
そもそもOSSって 強い人がやるものじゃないの? 自分はそんなに強くないから...
本日の目標
経験の浅い自分の取り組みを話すことで まだ取り組んだことのない方に (自分にはまだ早いと思ってる方に) 「自分もやってみようかな」 そう思ってもらうこと ※あくまで取り組み方の一つとして聞いて頂ければ幸いです
本題
【本日のメニュー】 第1章 OSSに取り組むきっかけ 第2章 初コントリビュートしたときの話 第3章 やらかし & 気付き
第1章 OSSに取り組むきっかけ 第2章 初コントリビュートしたときの話 第3章 つまづき & 気付き
業務でRailsに当てた モンキーパッチ ※コードの詳細は割愛
この経験の中で気付いた... 出来合いのライブラリを そのまま使えば良いわけでは ないかもしれない
きっと今後も 複雑なアプリの要件に 立ち向かうたびに こうした機会は訪れるだろう...
決意する!
普段使ってる OSSにパッチを送ったり 自力で直せるようになるぞ
モンキーパッチ(社内に閉じた修正) じゃなく、OSSに プルリクエストを送ってみたい!
第1章 OSSに取り組むきっかけ 第2章 初コントリビュートしたときの話 第3章 やらかし & 気付き
無い知恵を絞る...
パッチを送るために 2つのアプローチを取ることに
1. 気になるリポジトリのコードを 片っ端から追いかける 2. 業務で困っていること(不便)を考える
1. 気になるリポジトリのコードを 片っ端から追いかける 2. 業務で困っていること(不便)を考える
ある日 Railsのリポジトリを 読んでいたら...
軽微だがパッチを送れそうな箇所を発見
直す対象はわかったが... OSSって どうプルリク送れば良いのか 分からない
いろんな先輩 エンジニアの方々に 質問してみた
自分の中で目から鱗だった回答
Q. プルリクでメンテナーに分からないことを 質問してもいいものなんですか? A. 仕事と同じで長く関わっている人の方が仕様に 詳しいのは当たり前! 疑問に思ったことは質問しても大丈夫だよ!!
その後も疑問点を相談しつつ 拙い英語でプルリクを出した
この時のPRを投げる手順は以前Qiitaに 投稿したので気になる方はそちらも 参考までに...
OSS初プルリクだったもののRails にマージしてもらえた
第1章 OSSに取り組むきっかけ 第2章 初コントリビュートしたときの話 第3章 やらかし & 気付き
今度は業務にも活きる パッチを送りたい
1. 気になるリポジトリのコードを片っ端から追いかける 2. 業務で困っていること(不便)を考える
そういえば、 あれ...直したいかも
None
mongoid (gem) MongoDBをActiveRecord的に操作する ためのODM(Object Documen Mapper)
不便に思うところを 直してみた
実際にやったこと
mongoidのデフォルトでは rails g model で生成されるクラスに created_at と updated_at が付与されないので デフォルトで付与するようにした
⏰ ※これをやらない場合、毎回モデル生成のたびに rails g model モデル名 --timestamp で打つことに
例の如くプルリクを送ってみた
この時の私は自分が 最低の修正をしてしまったこと に気付いていなかった
その後プルリクに コメントが付く...
雑な訳) ActiveRecordはこのオプションを サポートしている。ActiveRecordに合わせるため、 このPRはリジェクトされるべきだ!!
最低の修正の中身
オプション(--timestampオプション) そのものを消した(最低) (このオプションそもそもいらなくない?と思ったので...)
その後、懸命な消火活動は続く
しかし、クローズしようぜ的な コメントがつき万事休す
その直後、この件について Twitterで呟いた際に 貴重なアドバイスが✨
None
None
このとき、 大切なことに気付く...
OSSにパッチを送る 行為(修正内容&PR内での振る舞い)にも マナーがあるということを
今回の場合だと mongoidのオプション そのものを消すのではなく それを生かした上で期待する修正をしてあ げるのがマナーだとわかった
@kamipoさんの アドバイスに則って 修正し直してみた
mongoidが目指す方向性に寄せて ActiveRecordのやり方に 準拠して直すようにした
None
色々やらかしましたが... なんとかmergeされることに✨
このプルリクエストは その後に修正内容に 関してマナーを意識する大 切な気付きになった
まとめ
年数は関係ない! 取り組んだ方の経験に応じた学びが きっとある!興味ある方は是非 → 当該リポジトリの思想に触れる事による学び → 自分が使っているOSSの中身を知る学び
OSSは公共物なので 使わせてもらえることを 当たり前にしない メンテナーに感謝しつつ (マナーある)PRが送れると最高かと✨
それでも一人で やるのは不安... そんな方は!
コミュニティにおいでよ!
Tama.rbでもOSSコードリーディング部 という活動をしており、 コミュニティでOSSのコードに触れる 機会を不定期で設けています (あわよくばパッチも送ったり!)
まだOSSに 取り組んだことのない方も! 是非コミュニティと一緒にやってい きましょう!!
ご静聴 ありがとう ございました!