2011年9月10日に神戸大学で行われたRuby関西主催の「第51回Ruby/Rails勉強会@関西」で発表したgithubでpull requestを行った経験談の資料です。

1. 私はいかにして
pull request を
行ったか
あるいは Social Developping
について
よしだあつし

2. 自己紹介
お名前: よしだあつし
Twitter ID: @yalab
職業: プログラマ兼ニート
興味: Rails 3.1、 scala、
android

3.
まずはGithubにつ
いて簡単に説明し
ます

4. Github とは?

5. Github とは?
https://github.com/
git リポジトリのホスティングサー
ビス
wiki や Ticket などのプロジェク
ト支援ツール多数
コードコラボレーションのプラット
フォーム

6. Github を使っているプロジェ
クト
Ruby On Rails
Rubygems
Node.js
jquery
その他多数...

7. 言語の割合
Javascript 20%
Ruby 16%
Python 9%
Shell 8%
https://github.com/languages

8.
github を使用し
た開発サイクル

9. 1、プロジェクトをフォークする

10. 1、プロジェクトをフォークする

11. 2、プロジェクトを clone

12. 3、fix->commit->push

13. 4、pull requset

14. 5、説得

15. 5、説得後
マージ or リジェクト
たまに放置

16.
ここからが
本題です

17.
ある日よしだ君は
当時最新版だったrails
3.0.0.beta3 を使って
開発をしていました

18.
「最新版のRailsを使って
アプリを作ってみるお」

19.
カタカタカタカタ

20.
「よし、後はメールが
送信できればおk」

21.
カタカタカ.....

22.
「あれ？」

23.
From: do-not-reply@localhost
To: test@localhost
Subject: 縺皮匳骭ｲ縺ゅｊ縺後→縺_縺斐＊縺_縺ｾ縺
Date: Fri, 04 Jun 2010 21:00:00 +0900
縺薙_Γ繝ｼ繝ｫ繧貞女菫｡縺輔ｌ縺滓凾轤ｹ縺ｧ縺ｯ縺ｾ縺_
逋ｻ骭ｲ縺ｯ遒ｺ螳壹＠縺ｦ縺翫ｊ縺ｾ縺帙ｓ縲莉·荳九_Μ繝
ｳ繧ｯ縺ｫ繧｢繧ｯ繧ｻ繧ｹ縺励_∫匳骭ｲ繧堤｢ｺ螳壹＠縺ｦ縺上□縺輔＞
https://localhost:3000/users/confirmation?confirmation_
token=X4VLMPc4iqyyVzCTWOK3
繧ゅ＠縺薙_Γ繝ｼ繝ｫ縺ｫ隕壹∴縺檎┌縺_蝣ｴ蜷医_♀謇区焚縺ｧ縺吶′
anmitsu64@gmail.com縺ｾ縺ｧ縺秘_｣邨｡縺上□縺輔＞縲_

24.
「文字化け!?」

25.
「えっとどうすればいいんだ？」

26.
カタカタカタカタ

27.
「なんかActionMailerの基底が
tmailじゃなくってmail
ってのになってる。」

28.
「ってことはrails2のフィックスのさせ
方じゃダメなのかな?」

29.
Google様....

30.
「....やはりググっても何も出てこない
か」

31.
「よろしい。ならば戦争モンキーパッチ
ングだ」

32. モンキーパッチングとは?
オリジナルのコードを変更すること
なく動的に格調したり変更したりす
る方法
class String
def cat
"nya~"
end
end
# あるいは
String.module_eval do
def cat
"nyan"
end
end

33.
カタカタカタカタカタカタカタカタカタカ
タカタカタ

34.
できた

35. ブログで公開

36.
ここから時間は
半年ほど進む

37.
「さて久々にまた新しいRailsアプリで
も作るかな」

38.
カタカタカタカタ

39.
「よし、後はメールが
送信できればおk」

40.
「あれ？」

41.
From: do-not-reply@localhost
To: test@localhost
Subject: 縺皮匳骭ｲ縺ゅｊ縺後→縺_縺斐＊縺_縺ｾ縺
Date: Fri, 04 Jan 2011 21:00:00 +0900
縺薙_Γ繝ｼ繝ｫ繧貞女菫｡縺輔ｌ縺滓凾轤ｹ縺ｧ縺ｯ縺ｾ縺_
逋ｻ骭ｲ縺ｯ遒ｺ螳壹＠縺ｦ縺翫ｊ縺ｾ縺帙ｓ縲莉·荳九_Μ繝
ｳ繧ｯ縺ｫ繧｢繧ｯ繧ｻ繧ｹ縺励_∫匳骭ｲ繧堤｢ｺ螳壹＠縺ｦ縺上□縺輔＞
https://localhost:3000/users/confirmation?confirmation_
token=X4VLMPc4iqyyVzCTWOK3
繧ゅ＠縺薙_Γ繝ｼ繝ｫ縺ｫ隕壹∴縺檎┌縺_蝣ｴ蜷医_♀謇区焚縺ｧ縺吶′
anmitsu64@gmail.com縺ｾ縺ｧ縺秘_｣邨｡縺上□縺輔＞縲_

42.
ア〜〜〜〜

43.
「まだ直ってない」

44.
「モンキーパッチじゃだめだ」

45.
「よろしい。ならば戦争pull request
だ」

46. pull request とは?
github でパッチを取り込んでもら
うためのアクション

47.
pull requestを考えたものの

48.
ここで一つの葛藤が生まれる

49. 葛藤
メンドくさ...誰かが直してくれるの
を待ったほうがいいんじゃないか？
僕が書くようなコードを送ってもい
いんだろうか？
っていうか僕英語できないんです
けど (英検3級)

50.
「悩んだ結果」

52. 送ってみた

53. 送ってみた
「やぁマイケル。iso-2022-jpってエン
コーディングでメール送りたかったけど
なんか今のmail gemじゃ扱えなかった
んだ。だから修正してみたよ。」

54. 返事があった
「ありがとう。で、これってruby 1.8でも
動くの？」

55. 説明する
「ごめん動かない。Ruby 1.8はマルチ
バイト文字をサポートしてないからね。
Ruby 1.8 で動かした場合単純に何も
しないようにしてる。」

56. 他の人のコミットで壊れた
「あそ。HEADをいじったらエラーになっ
たんだ。ルイスってやつの最近のコミット
が原因なんだけどrebaseして直して。そ
の後にマージするか決めるわ」

57. rebase とは
自分のコミットを載せる基準コミッ
トを変更する作業
今回の件でいうとコミットの順番を
並べ変えてルイスの変更の後に僕
の変更を行ったことにした

58. 修正する
「rebaseして直したよ」

59. 野次がはいる
「ちょっと待って、iso-2022-jpってダミー
エンコーディングだよ。Rubyがフルサ
ポートしてないのにこのパッチを取り込
むのってまずくない？」

60. 反論する
「iso-2022-jpがダミーなんて知ってる
よ。encodingが欲しいならgemを作
れ。そこは問題なんじゃなくってascii非
互換(とされている)とをmail gem が
まったく使えない事が問題なんだよ」

61. そしてマージされる
「ありがとう。マージしたよ」

62.
万歳

63. pull request をして得られ
るもの
自分のコードが認められた承認欲
求
自信がつく
野良ビルドを作らなくていい
プレゼンでしゃべるネタになる

64. pull request 時の注意点
READMEにcontributeについて
書いてある場合はそれに従う
テストは全て通す
インデントなどは元プロジェクトに
従う
必要以上のことはしない(ファイル
末尾に改行を加えるとか)

65. pull request 時の注意点
pull request 後はそのブランチを
いじってはいけない
リジェクトされても泣かない
マージされた暁には勉強会でプレ
ゼンする
リジェクトされても勉強会でプレゼ
ンする

66.
ソフトウェアは完璧ではなく
バグや機能不足があります

67.
OSSなプログラムならば自身の手で
直すことが可能です

68.
せっかく直した(あるいは回避した)の
だったらその成果で世界に貢献すると
いうのはどうでしょうか？

69.
なんちゃって英語でもわりといけまし
た

70. まとめ
github で pull request をした
経験をお話しました
あなたが見つけたバグは直されて
いないから見つかったものです
待っていても直らないので積極的
に直しましょう(報告だけでも十分な
貢献です)

71. まとめ
英語のコミュニケーションも辞書や
google翻訳を使えばなんとかなり
ます
何よりも我々にはコードというコ
ミュニケーション手段がある

72.
ちなみに

73.
パッチを送る以外にも
いろいろ出きることはある

74. 出きること
利用して広める
不具合や改善案の報告をする
ドキュメントを書く
パッチを書く

75.
RubyもOSSソフトウェアです

76.
すでにOSSソフトウェアを利用してな
にかしらの恩恵を受けています

77.
OSSから受けた恩
恵は是非OSSへ
貢献することでか
えしてください

78.
ご清聴ありがとう
ございました