読者です 読者をやめる 読者になる 読者になる

the industrial

都内で働くITエンジニアの日記

Elasticsearch入門してます (4日目) しょぼいPRで名前を残した話と勉強会に参加した話

f:id:omiend:20160108155150p:plain

タイトル通り、僕がElasticさんに送ったPullRequestがマージされたお話。

とはいっても、内容は保育園児でも出来そうなちょーしょぼいものなのでなんの自慢にもならないのだけど、PRを送る方法は決められた手順をもってやっているので、一応書き残しておこうかなと。

肝心の修正内容は、"を1個追加するだけという、もう本当恥ずかしいくらいしょぼいものなのだけど、ソレ以上に余りある栄誉(Elasticsearchのプロダクトに名前が残るという自己満足)を頂けて光栄の極みにございます。

github.com

何を直したのかというと、とりあえずこのISSUEを見てもらえば。

github.com

ElasticsearchのオフィシャルサイトにあるDocumentationを読み漁っていたら、クエリの例文で " が抜けている箇所があったので、「よっしゃPullRequest送ってElasticsearchにomiendの名前残したろ!」と。

しかし、いきなりPRを送るのはいくらなんでも失礼なので、まずはContributingを読みましょう。

github.com

ここで要求されていることは、簡単に言うと...

  1. もしバグを見つけたら、Issueに上がってないか調べてね
  2. 修正するときはForkしてね
  3. テストしておいてね
  4. Contributor License Agreementにサインしておいてね

Contributor Agreement | Elastic

  1. OKだったらPR送ってね!

って感じかな?

僕はそんなに英語できる人間ではないので、良いか悪いかは別として変な誤解を生まないためにも、Elasticの方との文章でのやり取りは極力少なくしたかったんだよね。

なので、どういった内容のIssueで、どういった形が本来望ましいのか(つまり英語で言うとShould を使うのかなと)、そしてどういう修正内容を予定しているかをプログラムレベルで記載してみたのだ。

そう書いておけば、たとえ英語がヘタで文法が間違っていても、少なからず何がしたいのかは通じるかなと。

整理すると、まずはIssueから作成。次に、PRと紐付け。後は単語でソレらしく...(ここが一番むつかしいw)という感じ。

特に英語が出来ない勢で一番むつかしいのが、「4. Contributor License Agreementにサイン」なのだけど...そこはGoogle翻訳片手に頑張るしか無いw

でもやっぱり英語が出来ないと、こういったこともやり方がスマートにならないですなあ。課題は英語だ。

まあ、以前も同じようにPlayframework(Typesafeさん)にPRしたことあるので、今回はそんなにドキドキしなかったデス。だから、興味がある人は1回やってみると良いかもですな!そうすればプロダクトはどんどん良くなる!...ハズ!

omiend.hatenablog.jp


そして、1月7日は #elasticsearchjp という勉強会に行ってきました。

東京駅前にあるリクルートさんのビルは初めてで、1Fの受付から41階にある会場までエレベーターを2個乗り継ぐ程のダンジョンさを体験。

学習のモッチベーション維持の為に効果的な方法の一つが、こういった勉強会への参加だったりするわけでして、まあ、内容は初学者の僕には難しいのだけど(基本的に機械学習のお話だったし)、懇親会ではトレジャーデータの @repeatedlyさんや、Elasticの@johtaniさんとお話出来て楽しかったデス。