「AkkaにPull Requestをあげようハッカソン」に参加してきたよ
先日、「AkkaにPull Requestをあげようハッカソン」 に参加してきました。
akkaコミッターの Konrad さん (https://github.com/ktoso) に加え、 Scala Matsuri 運営の @OE_uia さんと @RichardImaokaJP さん、 さらに会場提供していただいたセプテーニオリジナルの @kawachi さん と @AoiroAoino さん といった Scala 界の豪華メンバーに囲まれて、 Akka の PR を出すために直接相談しならが作業を進めるという、何とも素敵な体験をしましたのでその報告をします。
ちなみに私は時間内に PR を出すことができませんでしが、宿題という形でちゃんと出しました。 敷居は高くないんだよということをお知らせしたいと思います。
私について
- アーキテクト的な立ち位置で、普段は Javaを書いていてここ最近は C#, Azure
- Scala はほぼ趣味で Play 書いたり、コップ本、 FP in Scala, Akka in Action 読んだりしました
- 4月に社内のプロトタイプで好きにやっていいと言われたので、 akka-http の webSocket でチャットボット作ったりしました
- 英語力はほぼなしで、読みはどうにかなるくらい。
- OSS の貢献はしたいと思っていたが、結局やってなかった
参加したきっかけ
このイベントの趣旨を見たときは、正直畏れ多いと思いましてためらいましたが、 http://blog.scalamatsuri.org/entry/2017/11/15/133342 などをみて、気軽に行ってみようと思いました。 OSS やりたいけど英語や腕に不安のある私のような人は多いはずですし、良い試金石になるかもという思いもありました。
なお、Scala 大好きな後輩に参加を薦めておいて、私だけ当選しました。ごめんね。
当日について
まず、どの Issue を対応するかについての説明がありました。 https://github.com/akka/akka-http/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22 のように、 "help wanted" がついた issue は有志のパッチを受け付けてくれるそうで(知らなかった)、そこから興味があるものを選択して作業し、わからないことは konrad さんや運営スタッフと相談という感じでした。
実装方法の相談、テストの仕方、 PR の相談などを何でも聞いてくれて、 英語のコミュニケーションは @OE_uia さんと @RichardImaokaJP がサポートしてくれて本当に万全の体制でした。ありがとうございます。
他の参加者の @takashima0411 さん, @KojiMatsumiya さんがそれぞれ、 alpakka, akka の issue に着手したので、私は経験もあるし、 akka-http の issue をやることにしました。
簡単そうだなーと思ってやってみると、意外に難しいとか、実はもう対応されてたとか色々 issue をあさり、 URLエンコーディングの解析不具合によるエラーがでるという issue を対応することにしました。
多分簡単だろうと思っていたら、呼び出し場所によって挙動が変わったり、URL解析のための割と複雑なコードがあったりと原因を見つけ、対策を考えるのに割と時間を食い、あえなく時間切れとなりました。 後日絶対 PR 出してやるぞと思いました。
なお、URL解析は結構面倒だし色々な場所で呼ばれるので、ちゃんとパフォーマンスを考えないといけない。 if文一つの追加でもパフォーマンスには影響がでるかもしれないから、 ベンチマークをちゃんとやってから、PRマージするか決めるねという、ありがたいアドバイスをいただきました。
そういう意図なのかわかりませんが、私が直そうとしていたコードは、普通に var や while がありました。 なので、FP 詳しくなくても大丈夫ですよ。
あと、私は Windows マシンで参戦しましたが、開発上は特に問題ありませんでした。 ただし、 PR 出す際に全てのテストを流してわかりましたが、 Windows ではいくつかのテストが失敗またはスキップされます。 なので万全を期すなら Bash on Windows や Docker などでビルドできる環境も用意したほうがいいです。
あと、パエリアおいしかったです。ごちそうさまでした。
PR 出したよ
PR 出した後、速攻で Konrad から応答いただけてうれしかったです。
ただ、verup の関係か、修正箇所とは違う場所のCIテストがこけているので、もう少し調べてマージされるまで付き合います。 コア機能に手を入れると色々な箇所に影響を与えそうですね。
そのあと、半日程度で検証・マージされました。 多分ふつうのルートだとこんなに速攻でマージされることはないはずなので、本当にありがたいことです。
思ったこと・感想
前述のブログ記事にもある通り、海外では今回のようなみんなで集まって OSS のパッチを出すイベントが結構あるらしく、それを日本でもという趣旨が素晴らしいと思いました。
OSS への貢献は、特に日本では言語の壁もあるし、コミュニティに参加する人も少ないこともあって敷居が高いと感じていました。初めの一歩が難しいというやつですね。 その初めの一歩を手厚くサポートしてくれるというのは、とてもありがたいことでした。 今日だけでなく、今後もこの活動を続けていきたいと思いました。 何らかの形で、この活動に関わっていければと思います。
あとは英語について。
個人的な話ですが、年、別件で海外のすごいエンジニアの方と会食をするという機会をいただいたことがあったのですが、自分は全く何もできなくて勿体無い思いをしました。
今回も Konrad さんがいらっしゃっていて、Akka だけでなく Scala の動向だとかコミュニティに関する話など色々と直接聞ける機会だったのに、自分は何をやっていたんだろうと。
この業界にいるなら、英語はできないよりできたほうが圧倒的に楽しいし仕事の幅も増えるはずなので、もっと勉強しなければと思いました。努力が必要される場所に身を置きたい。
また、自身の反省として、コントリビューションガイドはちゃんと読んでおくべきだったことが挙げられます。 例えば、"help wanted" という誰でもパッチを上げていいという issue の存在自体をまず知りませんでしたし、 よく読めばどうやって作業したらいいかということが書いてありました。
反省ついでに、akka-http の コントリビューションガイドの抜粋を書いておきます。 PR作るにあたって重要そうな箇所だけを抜き出したので、より詳しく知りたい方は原書を参照してください。
akka-http/CONTRIBUTING.md at master · akka/akka-http · GitHub
Contribution Guideの 抜粋
タグについて
t:
で始まるタグはトピックを表し、issue がどの要素に対するものなのかを示します。 t:http:core
などです。
すべての issue が開かれていますが、初めての場合は次の2つのタグが付いているものから着手するといいでしょう。
help wanted
タグはコアメンバーが作業する時間がないか入門にちょうどいいissue です。不明点があれば気軽に訪ねてほしい。nice-to-have (low-priority)
は重要度が低いものです。興味があるならやってみてください。コントリビューションを歓迎します。
数字のついたタグは、開発状況を示しています。
0 new
は要件が不明瞭なものです。議論をするために、discuss
も一緒についていることがあります。内容が変わったりクローズするかもしれません。1 triage
は、有意義なチケットです。パッチを送るなら、このタグがついているものがいいでしょう。2 pick next
は作業対象にしたいチケットで、次回のリリースに含めたいPRに主にコアメンバーが付与します。3 in progress
は誰かが作業中のものです。
他に次のタグが使用されます
bug
- バグを示し、feature よりも優先して対応することを示します。
failed
- Jeknins の夜間ビルドが失敗したものを示します。
また、 PR の進捗状況のタグは次のように遷移します。
validating => [tested | needs-attention]
PRのワークフロー
| ※ PR を出す前に、6の CLA の登録はしておいたほうがいいです。
- 対応するissue を探し、決定する
- リポジトリを自分のgithubアカウントにフォークする
git checkout -b wip-custom-headers-akka-http
など追加したい featureのブランチを作成して作業する- 変更内容の検証をするためには、 sbt の
validatePullRequest
タスクが役に立ちます。このタスクはmaster ブランチからの変更箇所から影響のあるプロジェクトを特定し、影響のあるプロジェクトすべてのテストを実行します。- 例えば akka-http-core のソースを修正すると、akka-http-coreに依存するすべてのプロジェクトでテストが行います。
- 変更内容の検証をするためには、 sbt の
- コミットを以下のルールで作ります
Adding compression support for Manifests #22222
のように作業内容の概要とチケット番号を必ず先頭に含めます- 簡単なPRならば概要は
minor fix
などでもOKです
- 簡単なPRならば概要は
- 詳細が必要なら1行開けて、詳細な内容を追加します
- 複数のコミットを行った場合は squashでコミットを1つにまとめてください。
- akkaリポジトリにたいして、PR を発行してください。
- ここ で CLA(Contributor License Agreement) に登録してください。
- githubアカウントが、CLA に登録されていない場合、 PR の検証が OK になりませんので、事前に登録しておいた方がよいです。
- 初めてのPRの場合など、アカウントがホワイトリストに登録されていない場合、 Bot が
Can one of the repo owners verify this patch?
とたずねてきます。コアメンバーが確認をして、OKを回答します。これは悪意のあるPRによって、ビルドが壊れることを避けるためです。 - コアメンバーや興味のある人によってレビューや場合に応じて質問や修正依頼が来ます。質問などは気軽にしてください。通常 2つの LGTM が得られたらマージする対象として認められたことになります。
- 次回のリリースで、PRが本体にマージされます!
最後に
とても貴重な体験をしました。ありがとうございました!