OSS 貢献体験記 - ビデオ会議サービス Zoom API バージョンアップに伴う Ruby API クライアントのメソッド修正

先日、ひょんなことから**人生初の OSS 貢献**を果たしました。

色々試行錯誤しながら取り組み、学ぶことが多くありました。貴重な経験ができたと思うので、体験記としてまとめます。

僕のように、初めて OSS 貢献を始めようと思っている方の参考になれば幸いです。

## 作成した Pull Request

[Update user_create action changeable and update meeting_create endpoint by gotchane · Pull Request #2 · hintmedia/zoom_rb · GitHub](https://github.com/hintmedia/zoom_rb/pull/2)

ビデオ会議サービスの [Zoom](https://zoom.us/) の API が V1 -> V2 にバージョンアップすることに伴い、Zoom の Ruby クライアントのメソッドを修正した Pull Request です。

## 背景

* 2018/11/1 で Zoom API V1 が depreciated になり、Zoom API V2 の利用がメインになる
* 社内で開発している Web アプリで、Zoom API クライアント の gem である[zoomus](https://github.com/mllocs/zoomus) を使っていた
* しかし [zoomus](https://github.com/mllocs/zoomus) が V1 の対応しかしておらず、[Issue](https://github.com/mllocs/zoomus/issues/25) はあるが対応メドはたっていない状況だった
* depreciated まであと約1ヶ月。割と詰んでいる、どうしよう。。

## 対応方針検討

最初は [zoomus](https://github.com/mllocs/zoomus) 自体に修正は入れず、Web アプリ側で、[zoomus](https://github.com/mllocs/zoomus) のメソッドをオーバーライドして対応できないかと考えていました。

そんな中会社の先輩 @aki77 さんから、「別のプロジェクトでも同様に [zoomus](https://github.com/mllocs/zoomus) を使ってるので、**直接 PR 送ればいいのでは？**」というアドバイスが。

とはいえ、[zoomus](https://github.com/mllocs/zoomus) は V1 の対応のみ。API エンドポイントや認証方法の修正なども対応範囲が広く、大変そうでした。

どうすればよいかあれこれ調べていたところ、会社の先輩 @mat_aki さんからの助け舟が。

[zoomus](https://github.com/mllocs/zoomus) の **fork リポジトリ群から、API V2 の対応を進めていそうなリポジトリ**を見つけてくださいました…！

https://github.com/hintmedia/zoom_rb

コミットログも活発で、ガンガン更新していそうな感じ。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/222030/dca410a1-ff08-5663-4242-b6c86e8bb528.png)

また gem もリリースしているようでした。これは有力。

https://rubygems.org/gems/zoom_rb

こちらを使えると、利用しているメソッド修正のみの対応に範囲が絞られ、見通しが立ちそうです。このリポジトリを fork して、今回の Web アプリで利用するメソッドを書き換える対応を進めていきました。

## Pull Request を送るまで

こちらを参考に PR 作成を進めました。

https://github.com/hintmedia/zoom_rb#contributing

GitHub Help に[Creating a pull request from a fork](https://help.github.com/articles/creating-a-pull-request-from-a-fork/) というガイドがあるので、こちらも参考になります。

fork して Pull Request を送るのも初めての経験でした。。

### 1. Fork it

まずリポジトリを fork します。fork してできたリポジトリは以下の通り。

https://github.com/SonicGarden/zoom_rb

### 2. Create your feature branch

ローカルにリポジトリを clone し、開発ブランチを作成します。

```
$ git clone https://github.com/SonicGarden/zoom_rb
$ cd zoom_rb
$ git checkout -b my-new-feature
```

### 3. Commit your changes

ここからは修正対応を進めていきました。簡単に対応について書いていきます。

#### 依存 gem インストール

今回は gem の開発なので、依存している gem をインストールします。

```
$ bundle
```

#### テスト実行

gem で準備されているテストを実行し、テストがすべて通ることを確認します。今回は特に修正の必要はありませんでした。

```
$ bundle exec rspec
```

#### 開発開始

Zoom API ドキュメントをそれぞれのバージョンで確認して、レスポンスの違いを確認しながら修正を進めました。

* V1: https://zoom.github.io/api-v1
* V2: https://zoom.github.io/api

社内アプリで利用しているのは `user_create` と `meeting_create` というメソッド。それぞれ以下のような差分がありました。

メソッド|API V1|API V2
:--|:--|:--
`user_create`| 作成オプションが `create` のみ| 作成オプションが `create`,`custCreate`, `autoCreate`, `ssoCreate`の4パターンに
`meeting_create`|URLが`/meeting/create`| URLが`/users/{userId}/meetings`

リクエストパラメータは Zoom API の Playground を参考に確認しました。

https://developer.zoom.us/playground/

修正はこんな形で。URLや、パラメータの渡し方を修正する感じです。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/222030/0368e719-3f2f-9c78-113e-644005645dae.png)

修正ができたら、実際にローカルのコンソールで API 実行できるか確認し、

```
$ bundle exec irb
```

関連する spec も追加し、All Green になることを確認しました。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/222030/d359dabb-c687-f6f7-91e5-a16ef119eb56.png)

### 4.Push to the branch

開発が完了したら リモートリポジトリにプッシュします。社内ではこの時点で、**fork したブランチを基に、社内の Web アプリを先に修正して使えるように**しました。これも fork の利点だなと思います。

```
$ git push origin my-new-feature
```

あとは Pull Request を作成し、マージされるのを待つのみ…！

### 5. Create new Pull Request

いよいよ Pull Request を作成します。

fork 先で Pull Request を作成すると、fork 元の master ブランチが base になった状態で差分確認画面に移ります。便利ですね…！

![image.png](https://qiita-image-store.s3.amazonaws.com/0/222030/a16e8300-8fb4-3324-50e5-de942e247069.png)

慣れない英文、初めての OSS への PR だったので、社内の人に書いた description を確認してもらってから出しました。できる限り丁寧に書いたつもりです。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/222030/d7bae121-dc29-33bb-568a-a0b4e4c6463f.png)

関連して、CI が spec と関係ないところで失敗していたので、併せてコメントを残しておきました。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/222030/09dcd42a-e04d-0e2f-0b35-78d72f5862ee.png)

## 待望のコメント

そして PR を出してから 20日ほど経ち、ついに PR にコメントが来ました！

![image.png](https://qiita-image-store.s3.amazonaws.com/0/222030/5d936f89-cbb8-bff4-7d83-4d1bb6bfdbdf.png)

概ね OK だけど、 Hash の Key と Value を入れ替えてくれ、というリクエストでした。

Public Beta 版の[Suggested Change](https://help.github.com/articles/incorporating-feedback-in-your-pull-request/#applying-a-suggested-change) 機能を使ってコメントくださいました。見やすい…！

![image.png](https://qiita-image-store.s3.amazonaws.com/0/222030/d9fac940-1ec6-4d0a-af93-5d7cf1729733.png)

## そしてマージへ

修正完了の連絡後、ついにマージされました！！
gem のバージョンも上げてくださりました。このときの達成感は尋常ではありませんでした…！

![image.png](https://qiita-image-store.s3.amazonaws.com/0/222030/478e938c-5810-34c9-106f-39f8981f28c3.png)

## 今回の OSS 貢献を通して学んだこと

* Pull Request を出すという目的を持つと、必然的にコードを理解しようとして読むようになる
* 仕事で使っているライブラリを修正する必要が出てきたときは、まず fork して修正して使える状態にしておき、本家リポジトリに PR を出しておくと良い
* fork 先に必要な修正をしているリポジトリがあるかもしれない
* 海外のプログラマと直接英語でやり取りするのは非常に刺激的。日本にいても英語を使ういい機会になる
* 今回は偶然 API クライアントの修正だったが、分量的にも、API クライアントはとっかかりとしては良い題材だと思う
* 修正していて気づいたことは Pull Request にコメントを入れておくと、メンテナーが対応してくれるかも

## おわりに

今回の OSS 貢献を通して、OSS 貢献の魅力を体感することができました。これからも OSS 貢献できたら記事にまとめようと思います！