Forkwell Press

エンジニアの生き様をウォッチするメディア

君がッ! 泣いてマージするまで、プルリクを送ることをやめないッ!-トレジャーデータ 上薗竜太氏

この連載では、「Forkwell Jobs」の開発にも関わるフリーランスエンジニアの後藤大輔 (@idesaku) が、さまざまな企業で働くエンジニアとリレー形式で対談を行っていきます。
前回のセオ商事・新多真琴氏からご紹介のあった第10回目のゲストは、トレジャーデータの上薗竜太 (@kamipo) 氏です。

上薗氏については、O/Rマッパー「Active Record」における「Ruby on Rails」(以下、Rails) のトップクラスコントリビューターとして、名前をご存じの方が多いかもしれません。また、数年前には「金髪の神エンジニア」として、あるブログで、その新人指導ぶりも話題を集めました。

今回のリレーインタビューは3部構成にてお届けします!

第1部:君がッ! 泣いてマージするまで、プルリクを送ることをやめないッ!
第2部:「この境地にいるのは自分だけ」ー 自身を追い込み続けてたどり着いた「高み」
第3部:金髪の神エンジニア・kamipo 伝説のもうひとつの真実

執筆:高橋美津

スキルがついたことで見えてしまった Rails の「ダメなところ」

後藤:
前回のあらたまさんからのご紹介で、今回は上薗竜太さんにお話しを伺います。よろしくお願いします。

上薗:
よろしくお願いします。思っていることを言語化するのが苦手なタイプなので、うまく話せるか不安なのですが…。

後藤:
あらたまさんからは「飲み会では聞けないような話を聞きたい」というリクエストがあったのですが、そもそも知り合ったきっかけは何だったのでしょう。

上薗:
あらたまさんと最初に会ったのは2011年の YAPC (Yet Another Perl Conference) ですね。ただ、当時は仕事で Perl を使っていたというわけではなくて、PHP がメインだったのですが。

後藤:
上薗さんは、Rails のコントリビューターとしての印象が強いのですが、PHP も使われていたのですね。

上薗:
もともと新卒で入ったのはアドウェイズで、その後に移ったピクシブで、PHP をメインに使っていました。

後藤:
2015年の4月からは、現在いらっしゃるトレジャーデータに移られています。トレジャーデータは、Fluentd をメンテしていて Java もやっている会社というイメージなんですが、だとすると、Rails に本格的に関わるようになったのはいつごろなのですか。

上薗:
ピクシブを辞めた後の、2013年ごろからです。Rails について初めて知ったのは、学生だった2005年でした。まだバージョン1になっていないくらいのころで、当時流行した「Rails で15分で作るなんたら」のようなものを見ながら写経するような感じで使ってみて「これはスゴイ」と感激したのを覚えています。

で、その時の「スゴイ」というイメージを抱えたまま、改めて Rails を使ってみたのですが、10年前と比べると自分の知識も増えているせいで、特に Active Record まわりの細かいところで「わりとダメ」なところが見えてきちゃったんですね。

「直す気ないなら、こっちもこっちで無限に直してやる」

後藤:
どのへんが「わりとダメ」でした?

上薗:
ピクシブでは運用を担当していて、MySQL を専門にしていたのですが、Rails が吐き出すスキーマを見ていて、何か違和感を覚えたんです。まもなく気づいたんですけど、MySQL には Collation(照合順序)という概念があるのですが、本来「utf8_general_ci」がデフォルトで、普通に文字コードの順番で比較するようになっているはずのところを、Rails は「utf8_unicode_ci」に変更していたんですね。

後藤:
それ、日本語だと良くない振る舞いをするから、真っ先に変更しないといけないところですよね。

上薗:
ええ。utf8_unicode_ci は、たとえばアクセントのついた文字などが、文字列の並び順にとってあまり重要じゃない言語だと、ORDER BY したときにノーマライズされていて、いい感じの並び順になるんですけれど、これを日本語でやられてしまうと、凄まじいダメージを受けるんです。

後藤:
そうですね。

上薗:
Rails に手を入れ始めた直接のきっかけはそれでした。当時、技術的なことは自分のブログに書いていたんですが、Active Record がらみのことについては、公共性を考えて Qiita に書いたりもしていましたね。そうした流れもあって、2014年にあった「Rails複数DB Casual Talks」という勉強会で「何か喋ってくれ」と頼まれて、「MySQL と Active Record」をテーマに話をすることになったんです。

後藤:
「複数DB Casual Talks」は、Rails で複数の DB を使うためのノウハウを共有するという趣旨の勉強会なので、上薗さんのテーマはちょっと毛色が違うような気がしますが、ネットでレポートを見る限り、結構盛り上がったようですね。

上薗:
複数 DB の話をすると、どうしてもネタが被ってしまうので後のほうで発表する人ほど辛くなるんですよ。毛色が違ったことで被らなくて良かったです(笑)。

で、勉強会で発表するのであれば適当にしゃべってしまうのは良くないので、きちんとコードを読んでウラをとっておこうと思ったのですが、コードを読めば読むほど「これはヤバい」と思うようになってきまして…。

その時、せっかく不具合を見つけたんだからと、いくつかプルリクエストを送ったんです。当時は、4.2のベータ段階で「正式リリースまでに直るといいな」と思っていたのですが、結局、それらがほとんど反映されずに、ダメなところだらけのまま4.2がリリースされてしまったんですね。

それで「イラッ」ときまして。

後藤:
「イラッ」ときた(笑)。

上薗:
「おー、直す気ないのかよ。なら、こっちもこっちで無限に直してやるよ」とムキになって、ひたすら直しはじめた…という感じですかね。

ただ、大量にコントリビュートした今なら分かることなんですが、4.2向けにプルリクしていたタイミングって、既にリリース直前のフィーチャーフリーズ期間だったんですよね。もう、あの段階じゃそんなにいろいろ直せなかったという(笑)。

後藤:
普通、「OSS にユーザーが手を入れる」という場合、仕事などで使っている中でたまたまバグを踏んで、とりあえず直してみて、せっかくだから上流に流しておく…という形が多いのではないかと思います。でも、上薗さんのプルリクエストを見ると、そういうプロセスでは到底見つけられないような細かい不具合の修正が含まれているようなので、きっちりとコードを読まれたのだろうなというのは感じていました。

上薗さんの場合、仕事の中で使っていてバグに当たり、そこを直すと言ったことはあまりしないのですか。

上薗:
ごくたまにありますね。100回に1回くらいの割合ですけれど。

後藤:
じゃあ、99回はがっつりソースを読みこんで直すべきところを見つけているわけですね(笑)。最近だと、「サブクエリを使っていると unscope が使えない」というバグを直すプルリクエストを投げていらっしゃいましたね。私は unscope を使うことがほとんどないもので、「へぇーそうなんだー、よく気づいたなー」と思いながら見ていたのですが、こういうのも、たまたま見つけたというより、自分から見つけにいった感じなんでしょうか。

上薗:
そうですね。私も unscope は使いません。そもそもクエリを直接文字列で書くと unscope できないですし。

後藤:
上薗さんは、Rails 5.0.0 のコントリビューターとして、トップ7に入っておられますよね。Active Record 関連だけで、このコミット数は驚きます。すさまじい怒りのパワーですね(笑)。

上薗:
「日本人を怒らせたら怖いぞ」というのを分からせてやろうという思いは強かったですね。今も「君がッ! 泣いてマージするまで、プルリクを送ることをやめないッ!」と、本気で思っていますから(笑)。

プルリクが「日課」になるまでの道のり

後藤:
トレジャーデータでは、主にインフラ系のことをご担当されていると伺っているのですが、ハードなコントリビュート生活が、本業のほうに影響を与えるようなことはないですか。

上薗:
もちろん、ちゃんと仕事もしていますよ。トレジャーデータの場合、バックエンドへの投資規模が非常に大きいのですが、Fluentd のログ送信のようなものを含む Web API の部分は、基本的に Rails で書かれています。

後藤:
トレジャーデータで使っている Rails のバージョンはいくつですか。

上薗:
4.2.7.1 です。本当は、なるべく早く 5.0.1 に上げたいんですよね。5.0.0 は未完成の状態だったのでスキップするつもりでいたのですが、既に 5.0.1 RC1 が出てきています(註: 5.0.1 はこの後まもなく、2016年12月21日にリリースされました)。こんなに早いタイミングで出てくるなら、バックポートしとかなければいけない内容、いっぱいあったんですよね…。今日、ここに来る前にバックポートした内容は、仕事の中で見つけたものです。

後藤:
仕事の中で見つけて直すケースがあるにしても、それ以外の大量なプルリクについては、個人的に時間を作って作業しているわけですよね。

上薗:
既に「日課」になってしまっています。普通の人が、毎朝新聞を読むようなものですよ。

後藤:
「朝起きたら、まず git pull」みたいな感じですか。

上薗:
私の場合、Chrome に Rails のマスターブランチのコミットヒストリーを出すタブを作っているので、朝起きたら、まずそこで増えたコミットを見て、その後新しく増えた Issue とプルリクを見て…といった感じですね。

後藤:
人が出したプルリクを見て、コミットを入れるようなこともあるんですか。

上薗:
ありますね。「泣いてマージするまでやめない」を実践しようとすると、こちらとしてもひたすら、プルリクをジャブのように打ち出し続けなければいけないわけで、そうなってくると、自分ひとりの観測範囲では、どうしてもネタが無くなってくるんですよ。その場合、他人の Issue を参考にして、「これは純粋にバグだな」と分かれば、その場で直してしまうようなことはやっています。

後藤:
ひとつの Issue からの連想で、他の部分にもありそうな問題を見つけてしまうようなこともありそうですね。

上薗:
1つを直している最中に「あれ? こっちも変だぞ」と気付くことは結構多いです。だいたい、1つバグが見つかれば、その背後に2、3個は隠れている感じで。
(To Be Continued... 第2部へ続く)

第2部:「この境地にいるのは自分だけ」ー 自身を追い込み続けてたどり着いた「高み」



Forkwell では、ITエンジニアが自身のアウトプットを簡単に連携・管理し、スキルを可視化することができる「Forkwell Portfolio」を運営しています。

GitHub アカウントの連携により、登録されたリポジトリのコミットログを解析。普段書いているプログラミング言語や、コードの変更量をグラフ化します。