Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Oss貢献超入門

18,296 views

Published on

builderscon2017の発表資料です。

https://builderscon.io/tokyo/2017/session/182ba13a-ccd5-4ddd-9565-c4e20df1d871

Published in: Technology
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Oss貢献超入門

  1. 1. OSS貢献超入門 builderscon2017 2017/8/5 shigemk2
  2. 2. 自己紹介 ● shigemk2 ● アドテクエンジニア ● ScalaとかHadoopとかReactとか ● http://www.shigemk2.com/
  3. 3. 超結論 好きなリポジトリを ウォッチしよう
  4. 4. 今日の流れ 1. 対象者 2. OSSとは 3. 貢献できない理由 4. 出来ない理由を片付けていく 5. ケーススタディ
  5. 5. 今日の流れ 1. 対象者 2. OSSとは 3. 貢献できない理由 4. 出来ない理由を片付けていく 5. ケーススタディ
  6. 6. 皆さん OSS開発できてますか?
  7. 7. 今日の対象者 (いろいろ理由があって) OSS開発したくてもできない
  8. 8. (いろいろ理由があって) OSS開発したくてもできない =わりと昔の自分
  9. 9. 今はわりとできてると思う ● Emacs ● cookpad/kuroko2 ● rundeck ● github/hub ● なんか毎週Issueとかプルリクとか投げてる気がする
  10. 10. 今日の流れ 1. 対象者 2. OSSとは 3. 貢献できない理由 4. 出来ない理由を片付けていく 5. ケーススタディ
  11. 11. OSSとは ● 概念に基づき、ソフトウェアのソースコードが無 償で公開され、改良や再配布を行うことが誰に 対しても許可されているソフトウェアのこと ○ http://www.weblio.jp/content/オープンソースソフトウェア ● 概念(OSDが提唱する。次ページ参照) ○ http://www.opensource.jp/osd/osd-japanese.html
  12. 12. OSSの概念 ● 再頒布の自由 ● ソースコード ● 派生ソフトウェア ● 作者のソースコードの 完全性 ● 個人やグループに対す る差別の禁止 ● 利用する分野に対する差別 の禁止 ● ライセンスの分配 ● 特定製品でのみ有効なライ センスの禁止 ● 他のソフトウェアを制限する ライセンスの禁止 ● ライセンスは技術中立的で なければならない
  13. 13. なるほどわからん
  14. 14. 厳格はつらい OSSの概念を完全に理解してなくても パッチやバグレポートは出せる
  15. 15. GitHubなどにソースコードが 公開されているソフトウェアは だいたいOSS
  16. 16. You Ain’t Gonna Need It! 機能は実際に必要になるまで追加しない
  17. 17. 人力YAGNI ライセンスとかOSSの定義は パッチやバグレポートを出した後に 勉強しよう
  18. 18. 今日の流れ 1. 対象者 2. OSSとは 3. 貢献できない理由 4. 出来ない理由を片付けていく 5. ケーススタディ
  19. 19. 言語化の試み 問題解決のためには 問題を言語化する必要が ある
  20. 20. OSSに貢献できない理由 ● どこから手を付けていいか分からない ● ソースコードを読んでも分からない ● 時間がなくて無理 ● 技術的に無理
  21. 21. OSSに貢献できない理由 ● どこから手を付けていいか分からない ● ソースコードを読んでも分からない ● 時間がなくて無理 ● 技術的に無理
  22. 22. どこから手を付けていいか分からない ● どんなバグレポートやパッチを出せばい いか分からない ● OSS多すぎ ● 特に意識しないと普通に使えちゃう
  23. 23. どこから手を付けていいか分からない ● どんなバグレポートやパッチを出せばい いか分からない ● OSS多すぎ ● 特に意識しないと普通に使えちゃう
  24. 24. ケーススタディ Play Framework
  25. 25. なんかIssueとかPull Requestがいっぱい
  26. 26. なんかIssueとかPull Requestがいっぱい
  27. 27. 次のアクションが分からない ↓ もうこのままでいいんじゃないかな
  28. 28. どこから手を付けていいか分からない ● どんなバグレポートやパッチを出せばい いか分からない ● OSS多すぎ ● 特に意識しないと普通に使えちゃう
  29. 29. 自社プロダクトで使われているOSS ● プログラミング言語: 2 ● フレームワーク: 2 ● バックエンド部分のライブラリ: 55 ● フロントエンド部分のライブラリ: 60 ● ミドル: 10くらい ● 参照: build.sbt/package.json
  30. 30. 開発環境 ● ターミナル ● エディタ/IDE ○ Vim/Emacs/IntelliJ IDEA/Atomとか ○ 付随するライブラリとかプラグインとか ● ログインシェル ○ bash/zsh/fish
  31. 31. OSSが多すぎて どこから手を付けていいか 分からない
  32. 32. どこから手を付けていいか分からない ● どんなバグレポートやパッチを出せばい いか分からない ● OSS多すぎ ● 特に意識しないと普通に使えちゃう
  33. 33. 特に意識しなくても普通に使えちゃう ググったりQiitaを見たり知ってる人に聞い たりしたらだいたい解決する ↓ もうこのままでいいんじゃないかな
  34. 34. 結果、どこから手を付けていいか 分からない
  35. 35. OSSに貢献できない理由 ● どこから手を付けていいか分からない ● ソースコードを読んでも分からない ● 時間がなくて無理 ● 技術的に無理
  36. 36. 統計 ファイル数 行数
  37. 37. ファイル数多すぎて 手をつけたらええんか分からん
  38. 38. OSSに貢献できない理由 ● どこから手を付けていいか分からない ● ソースコードを読んでも分からない ● 時間がなくて無理 ● 技術的に無理
  39. 39. 使える時間(と気力)は限られてる 1. 夜9時とか10時とかに退社 2. 1-2時間かけて電車で帰る(しんどい) 3. 夜10時とか11時とかに帰宅 4. 飯食って風呂入って 5. アニメ見たりTwitter見たり家族とか友人 とかと話をしたり
  40. 40. 気づいたら深夜! 気力もない!(体力もない!)
  41. 41. しんどい
  42. 42. OSSに貢献できない理由 ● どこから手を付けていいか分からない ● ソースコードを読んでも分からない ● 時間がなくて無理 ● 技術的に無理
  43. 43. そうだ! ソースコードを読んでみよう!
  44. 44. 漫然と眺めてもわからん ● ソースコード ● Pull Request ● Issue
  45. 45. ちゅーかやっぱりこのままで いいいんじゃね?
  46. 46. 出来ない理由は 1つ1つ潰していこう
  47. 47. 今日の流れ 1. 対象者 2. OSSとは 3. 貢献できない理由 4. 出来ない理由を片付けていく 5. ケーススタディ
  48. 48. OSSに貢献できない理由 ● どこから手を付けていいか分からない ● ソースコードを読んでも分からない ● 時間がなくて無理 ● 技術的に無理
  49. 49. そもそも なぜOSSに貢献するのか ● プログラマーとしての成長のため ● バグってたりドキュメントがおかしかった りするのを直すため ● 欲しい機能を追加するため ● パッチが取り込まれるのは嬉しい
  50. 50. オープンソースへの取り組みは エンジニアにとって大きな「武器」 になる https://doda.jp/engineer/it/guide/001/02b.htm l
  51. 51. 具体的なアクションが分からん
  52. 52. キャリアアップを考えるのは 副次的なものであってゴールじゃない ↓ 自分の思う通りにOSSを 作り変えていく
  53. 53. 具体的なアクションの一例 ● 機能追加 ● バグ修正 ● リファクタリング ● ドキュメント編集 ● ドキュメント翻訳
  54. 54. 必要にかられないと人は動かない ↓ 必然性を高めていこう
  55. 55. 必要にかられないと人は動かない ↓ 必然性を高めていこう
  56. 56. 必要にかられないと人は動かない ↓ 必然性を高めていこう ↓ 使っているOSSの中身を 積極的に見る
  57. 57. OSS開発の必然性を高めていくために ● 公式ドキュメント/ソースコードを読む ● StackOverflowやQiitaは使わない ○ マイナス検索を使う ○ 副読書程度で
  58. 58. Google検索 -stackoverflow -qiitaの理由 ● 最新性 ● 正確性 ● 本家で今何が問題となっているか分か らない
  59. 59. 公式が間違っている説と自分が間違ってい る説を半々ぐらいで持ちながら開発する 心構え
  60. 60. OSSに貢献できない理由 ● どこから手を付けていいか分からない ● ソースコードを読んでも分からない ● 時間がなくて無理 ● 技術的に無理
  61. 61. なんかいろいろ実装されてて 分からない ↓ 雰囲気をつかもう
  62. 62. なぜ雰囲気をつかむ 必要があるのか ↓ 他の人が何をやっているか 分かるから
  63. 63. OSS開発の 雰囲気をつかむ ためにとても 参考になる本
  64. 64. さまざまなアセ ンブリ言語を フィーリングで読 む本
  65. 65. 熱血バイナリアン十訓(P1) ● まずは読め ● 楽しんで読め ● 無理やり読め ● 勘で読め ● 暇を見つけて読め ● 思うままに読め ● 納得行くまで読め ● 明日も読め ● 飽きたら次のを読め ● わからなくても気にせず 読め
  66. 66. その十戒はOSS開発にも適用できる ● まずは読め ● 楽しんで読め ● 無理やり読め ● 勘で読め ● 暇を見つけて読め ● 思うままに読め ● 納得行くまで読め ● 明日も読め ● 飽きたら次のを読め ● わからなくても気にせず 読め
  67. 67. 何を読むべきか
  68. 68. GitHubリポジトリのチャットツールGitter https://gitter.im/
  69. 69. READMEの on gitterをクリック(あれば) https://github.com/playframework/playframework
  70. 70. アプリもあるで https://gitter.im/apps
  71. 71. 気になるリポジトリはwatch! https://github.com/notifications
  72. 72. アプリもいろいろ(一長一短) CodeHub GHFeed
  73. 73. メーリングリスト
  74. 74. 今挙げたやつを とりあえず適当な時間を見つけて読む
  75. 75. いつ読むべきか ● 休憩時間 ● 通勤時間 ● 寝る前 ● ビルド時間 ● その他あいてる時間
  76. 76. ポイント ● 雰囲気で読む ● 分からなくても気にせず読む ● 飽きたら別のリポジトリをwatchする ● 毎日読む
  77. 77. 注意点 ● Linux/Emacsのメーリングリストは毎日数百数 千とかメールが来てやばい ○ メーリス購読してたらGmailの容量が死にか けた ● PrestoとかElasticSearchとかは毎日すごい数 のIssueやPull Requestが飛んでてやばい ● 通知をオンにすると通知がしんどいけど通知を オンにしましょう
  78. 78. これをやることで得られる雰囲気 ● 他の人がどんなIssueを出しているか ● 他の人がどんなPull Requestを出してい るか ● 他の人がどんな文章を書いているか ● 他の人がどんなコードを書いているか
  79. 79. http://xuwei-k.hatenablog.com/entry/20150930/1443641775 すごく参考になったブログ
  80. 80. OSSに貢献できない理由 ● どこから手を付けていいか分からない ● ソースコードを読んでも分からない ● 時間がなくて無理 ● 技術的に無理
  81. 81. 使える時間(と気力)は限られてる 1. 夜9時とか10時とかに退社 2. 1-2時間かけて電車で帰る(しんどい) 3. 夜10時とか11時とかに帰宅 4. 飯食って風呂入って 5. アニメ見たりTwitter見たり家族とか友人 とかと話をしたり
  82. 82. 時間がない問題の解決方法 1. 帰ったらすぐやる 2. 寝る時間を削って時間とやる気を捻出 する 3. 仕事の時間や昼の休憩時間を使う
  83. 83. OSSに貢献できない理由 ● どこから手を付けていいか分からない ● ソースコードを読んでも分からない ● 時間がなくて無理 ● 技術的に無理
  84. 84. 技術的に無理 ● 全てを理解しようと思わなくていい ○ 修正したい箇所だけを重点的に ● find-grep/検索
  85. 85. 技術的に無理 ● 最低限CONTRIBUTEページは読もう ○ IssueやPull Requestを投げるときの ガイドラインが記載されている ○ ここをクリアしないとそもそも見てもら えない ○ contribute xxxでググろう
  86. 86. 技術的に無理 ● どういうふうに書いていいか分からない ○ 他の人が書いたソースコードを参考に しよう ○ 分からない関数や処理が分かる ○ 純粋にすごく参考になる
  87. 87. 技術的に無理 ● テストコードを読んで挙動を知る ○ どういう動きになっているかはテスト コードを読めば分かる
  88. 88. 今日の流れ 1. 対象者 2. OSSとは 3. 貢献できない理由 4. 出来ない理由を片付けていく 5. ケーススタディ
  89. 89. ケーススタディ ● 歴史と伝統のある大きなOSS ● 最近出来た新興のOSS ● 全然開発されていないOSS
  90. 90. ケーススタディ ● 歴史と伝統のある大きなOSS ● 最近出来た新興のOSS ● 全然開発されていないOSS
  91. 91. https://github.com/rundeck/rundeck 高機能cron
  92. 92. https://github.com/rundeck/rundeck/pull/1836 リンク切れ修正
  93. 93. ポイント ● cronまわりのドキュメントを読み漁った 結果 ● 必要な箇所だけでいいので公式ドキュメ ントをちゃんと読みましょう ● ドキュメント修正も貢献です
  94. 94. https://github.com/cookpad/kuroko2 GUIベースのジョブスケジューラ
  95. 95. いろいろ便利な ワークフローエンジン ● Webの管理画面がある ● Webの管理画面でリトライできる ● DBはMySQL ● timeoutの値を設定できる ● Slack通知が簡単にできる
  96. 96. 問題点 ● ドキュメントにない機能の存在 ● kuroko2にはないDSLがある(echoとか retryとかif-elseとか) ● ドキュメントをなぞっても環境構築できな い
  97. 97. 問題点 ● ドキュメントにない機能の存在 ● kuroko2にはないDSLがある(echoとか retryとかif-elseとか) ● ドキュメントをなぞっても環境構築できな い
  98. 98. https://github.com/cookpad/kuroko2/pull/59
  99. 99. ドキュメントにない機能の存在 ● GUIではなくAPIからジョブを実行する ○ incoming webhook ● 当初この機能はドキュメントになかった ので、ドキュメント追加のプルリクエスト を投げた
  100. 100. ドキュメント追加の流れ 1. 機能が存在するかどうかググる 2. Issueやドキュメントを読む 3. ソースコードを読む 4. 実装されているけどドキュメントにない場 合は、該当機能のドキュメントを追加す る
  101. 101. 問題点 ● ドキュメントにない機能の存在 ● kuroko2にはないDSLがある(echoとか retryとかif-elseとか) ● ドキュメントをなぞっても環境構築できな い
  102. 102. https://github.com/cookpad/kuroko2/pull/65
  103. 103. DSL追加 ● 今まで ○ execute: echo “hello, world” ● 今回のプルリクエスト ○ echo: “hello, world”
  104. 104. 機能追加の流れ 1. IssueやPull Requestを見て、既知のも のか確認する 2. 作りたい機能のイメージを固める a. digdagのechoを流用したかった結果 3. 既存のプロダクトコード/テストコードを読 み、書き方と挙動を知る 4. 真似る
  105. 105. 問題点 ● ドキュメントにない機能の存在 ● kuroko2にはないDSLがある(echoとか retryとかif-elseとか) ● ドキュメントをなぞっても環境構築できな い
  106. 106. ドキュメントを なぞっても環境構築 できない
  107. 107. ≠何もしてないのに 壊れた
  108. 108. 参考: メーリングリスト サ ポートセンターではなく互 助会です http://www.hyuki.com/writing/techask.html
  109. 109. 確認事項
  110. 110. 下準備 1. ドキュメント側で指定している バージョンで試す 2. エラーログを読み、期待している 動作と実際の動作を確認する 3. ソースコードを読む
  111. 111. バグかどうかの確認 1. ドキュメント側で指定している バージョンである 2. エラーログとソースコードを読ん で、ソースコード側に起因するも のならそれはバグ
  112. 112. https://github.com/cookpad/kuroko2/issues/57
  113. 113. ドキュメント通りに環境構築 しようとしてエラーになる ● インストールコマンド実行後 ○ rails new -m app_template.rb ● Directly inheriting from ActiveRecord::Migration is not supported
  114. 114. Rails5にアップデートす るときに起きるアレ class CreateUsers < ActiveRecord::Migration[4.2] って書けよ http://tech.grooves.com/entry/2016/07/01/184458
  115. 115. https://github.com/cookpad/kuroko2/pull/63
  116. 116. Missing dependency commonmarker ● ジョブ登録時に起きた ○ GUIのところどころで起きる ● html-pipelineのバージョンアップデート で記載されていたgemspecの github-markdownが使われなくなった ○ https://github.com/jch/html-pipeline/pull/274
  117. 117. おまけ 開発前にソースコードを読んだら typoが見つかったのでプルリクを出した ↓ IDEさまさま!
  118. 118. 新しめのOSSはcontribution pointが割と多い
  119. 119. ケーススタディ ● 歴史と伝統のある大きなOSS ● 最近出来た新興のOSS ● 全然開発されていないOSS
  120. 120. Emacsにパッチを投げた ● zshファイルのsh-modeが起動しない ● sh-mode自体にはzshに対応してた https://www.emacswiki.org/emacs/ShMode ● 以前は自前のinit fileに書く→書きたくな いと思った結果 http://emacs.1067599.n8.nabble.com/bug-25217-PATCH-Enable-sh-mode-zshrc-td416040.html
  121. 121. 修正は1行
  122. 122. パッチを投げる前に ● contribute emacsでググる ● sh-modeのwikiを調べる ● るびきち氏にメルマガ経由で確認した
  123. 123. 苦しいポイント ● GitHubにプルリクエストを投げるスタイ ルではない ○ パッチファイルを作る ○ git send-email ● やり取り自体が少し面倒 ● GitHubみたいにGUIでレビューされない
  124. 124. 紆余曲折を経て
  125. 125. パッチが 取り込まれたときの 無上の喜び
  126. 126. ケーススタディ ● 歴史と伝統のある大きなOSS ● 最近出来た新興のOSS ● 全然開発されていないOSS
  127. 127. google-translate
  128. 128. Google翻訳をEmacs上で使う
  129. 129. Pull Requestを投げました
  130. 130. やりたかったこと ● Google翻訳の結果を出力 ○ ポップアップ ○ エコー領域 ○ 現在のバッファ ● 今の作業領域に翻訳結果を出力して欲 しいと考えた結果
  131. 131. 問題点
  132. 132. プルリクを出す前の最後のコミットが 半年前
  133. 133. プルリクを投げても 放置されるパターン
  134. 134. アプローチの必要性 1. @作者でGitHubにコメントする 2. @ツイートする 3. メールアドレスに直接メールを送る 4. 何もしない 5. forkして自前で開発をすすめる
  135. 135. 実際にやったこと 1. @作者でGitHubにコメントする 2. @ツイートする 3. メールアドレスに直接メールを送る 4. 何もしない 5. forkして自前で開発をすすめる
  136. 136. 無事マージされました
  137. 137. おまけ ● プルリク出すときにCIがコケてたのでCI で動かすテストコードを修正するプルリ クを投げました
  138. 138. まとめ ● 雰囲気をつかむのはとても重要 ● 毎日続けること ● ドキュメントとソースコードを読むこと ● 他人のコードを知ること
  139. 139. このセッションの後から アクションを始めよう

×