ITエンジニアのキャリアに本気で向き合うメディア
ITエンジニアのキャリアに本気で向き合うメディア
目次
■エンジニアの軌跡
2017.01.24 2024.03.28 約3分
さまざまな企業で働くエンジニアとリレー形式で対談を行うDevRelay。vol.10は、トレジャーデータの @kamipo こと上薗竜太氏！スキルがついたことで見えてしまった Rails の「ダメなところ」を伺います。この対談は、3部構成（vol.10・vol.11・vol.12）でお届けします。
idesaku：前回の新多真琴氏からのご紹介で、今回は上薗竜太氏の登場です。よろしくお願いします。
kamipo：よろしくお願いします。
idesaku：新多氏からは「飲み会では聞けないような話を聞きたい」というリクエストがあったのですが、そもそも知り合ったきっかけは何だったのでしょう。
kamipo：新多氏と最初に会ったのは2011年の YAPC (Yet Another Perl Conference) ですね。ただ、当時は仕事で Perl を使っていたというわけではなくて、PHP がメインでした。
idesaku：上薗氏は、Rails のコントリビューターとしての印象が強いのですが、PHP も使われていたのですね。
kamipo：もともと新卒で入ったのはアドウェイズで、その後に移ったピクシブで、PHP をメインに使っていました。
idesaku：2015年の4月からは、現在いらっしゃるトレジャーデータに移られていますが同社は、Fluentd をメンテしていて Java もやっている会社というイメージです。、Rails に本格的に関わるようになったのはいつごろなのですか。
kamipo：ピクシブを辞めた後の、2013年ごろからです。Rails について初めて知ったのは、学生だった2005年でした。まだバージョン1になっていないくらいのころで、当時流行した「Rails で15分で作るなんたら」のようなものを見ながら写経するような感じで使ってみて「これはスゴイ」と感激したのを覚えています。
その時の「スゴイ」というイメージを抱えたまま、改めて Rails を使ってみたのですが、10年前と比べると自分の知識も増えているせいで、特に Active Record まわりの細かいところで良くない点が見えてきちゃったんですね。
idesaku：どのへんが「わりとダメ」でした？
kamipo：ピクシブでは運用を担当していて、MySQL を専門にしていたのですが、Rails が吐き出すスキーマを見ていて、何か違和感を覚えたんです。まもなく気づいたんですけど、MySQL には Collation（照合順序）という概念があるのですが、本来「utf8_general_ci」がデフォルトで、普通に文字コードの順番で比較するようになっているはずのところを、Rails は「utf8_unicode_ci」に変更していたんですね。
idesaku：日本語だと良くない振る舞いをするから、真っ先に変更しないといけないところですよね。
kamipo：ええ。utf8_unicode_ci は、たとえばアクセントのついた文字などが、文字列の並び順にとってあまり重要じゃない言語だと、ORDER BY したときにノーマライズされていて、いい感じの並び順になるんですけれど、これを日本語でやられてしまうと、凄まじいダメージを受けるんです。
idesaku：そうですね。
kamipo：Rails に手を入れ始めた直接のきっかけはそれでした。当時、技術的なことは自分のブログに書いていたんですが、Active Record がらみのことについては、公共性を考えて Qiita に書いたりもしていましたね。そうした流れもあって、2014年にあった「Rails複数DB Casual Talks」という勉強会で「何か喋ってくれ」と頼まれて、「MySQL と Active Record」をテーマに話をすることになったんです。
idesaku：「複数DB Casual Talks」は、Rails で複数の DB を使うためのノウハウを共有するという趣旨の勉強会なので、上薗氏のテーマはちょっと毛色が違うような気がしますが、ネットでレポートを見る限り、結構盛り上がったようですね。
kamipo：複数 DB の話をすると、どうしてもネタが被ってしまうので後のほうで発表する人ほど辛くなるんですよ。毛色が違ったことで被らなくて良かったです（笑）。
勉強会で発表するのであれば適当にしゃべってしまうのは良くないので、きちんとコードを読んでウラをとっておこうと思ったのですが、コードを読めば読むほど「これはヤバい」と思うようになってきまして…。
その時、せっかく不具合を見つけたんだからと、いくつかプルリクエストを送ったんです。当時は、4.2のベータ段階で「正式リリースまでに直るといいな」と思っていたのですが、結局、それらがほとんど反映されずに、ダメなところだらけのまま4.2がリリースされてしまったんですね。
それで「イラッ」ときまして。
idesaku：「イラッ」ときた（笑）。
kamipo：「おー、直す気ないのかよ。なら、こっちもこっちで無限に直してやるよ」とムキになって、ひたすら直しはじめた…という感じですかね。
ただ、大量にコントリビュートした今なら分かることなんですが、4.2向けにプルリクしていたタイミングって、既にリリース直前のフィーチャーフリーズ期間だったんですよね。もう、あの段階じゃそんなにいろいろ直せなかったという（笑）。
idesaku：普通、「OSS にユーザーが手を入れる」という場合、仕事などで使っている中でたまたまバグを踏んで、とりあえず直してみて、せっかくだから上流に流しておく…という形が多いのではないかと思います。でも、上薗氏のプルリクエストを見ると、そういうプロセスでは到底見つけられないような細かい不具合の修正が含まれているようなので、きっちりとコードを読まれたのだろうなというのは感じていました。
上薗氏の場合、仕事の中で使っていてバグに当たり、そこを直すと言ったことはあまりしないのですか。
kamipo：ごくたまにありますね。100回に1回くらいの割合ですけれど。
idesaku：じゃあ、99回はがっつりソースを読みこんで直すべきところを見つけているわけですね（笑）。最近だと、「サブクエリを使っていると unscope が使えない」というバグを直すプルリクエストを投げていらっしゃいましたね。私は unscope を使うことがほとんどないもので、「へぇーそうなんだー、よく気づいたなー」と思いながら見ていたのですが、こういうのも、たまたま見つけたというより、自分から見つけにいった感じなんでしょうか。
kamipo：そうですね。私も unscope は使いません。そもそもクエリを直接文字列で書くと unscope できないですし。
idesaku：上薗氏は、Rails 5.0.0 のコントリビューターとして、トップ7に入っておられますよね。Active Record 関連だけで、このコミット数は驚きます。すさまじい怒りのパワーですね（笑）。
kamipo：今も「君がッ！ 泣いてマージするまで、プルリクを送ることをやめないッ！」と、本気で思っていますから（笑）。
idesaku：トレジャーデータでは、主にインフラ系のことをご担当されていると伺っているのですが、ハードなコントリビュート生活が、本業のほうに影響を与えるようなことはないですか。
kamipo：もちろん、ちゃんと仕事もしていますよ。トレジャーデータの場合、バックエンドへの投資規模が非常に大きいのですが、Fluentd のログ送信のようなものを含む Web API の部分は、基本的に Rails で書かれています。
idesaku：トレジャーデータで使っている Rails のバージョンはいくつですか。
kamipo：4.2.7.1 です。本当は、なるべく早く 5.0.1 に上げたいんですよね。5.0.0 は未完成の状態だったのでスキップするつもりでいたのですが、既に 5.0.1 RC1 が出てきています（註: 5.0.1 はこの後まもなく、2016年12月21日にリリースされました）。こんなに早いタイミングで出てくるなら、バックポートしとかなければいけない内容、いっぱいあったんですよね…。今日、ここに来る前にバックポートした内容は、仕事の中で見つけたものです。
idesaku：仕事の中で見つけて直すケースがあるにしても、それ以外の大量なプルリクについては、個人的に時間を作って作業しているわけですよね。
kamipo：既に「日課」になってしまっています。普通の人が、毎朝新聞を読むようなものですよ。
idesaku：「朝起きたら、まず git pull」みたいな感じですか。
kamipo：私の場合、Chrome に Rails のマスターブランチのコミットヒストリーを出すタブを作っているので、朝起きたら、まずそこで増えたコミットを見て、その後新しく増えた Issue とプルリクを見て…といった感じですね。
idesaku：人が出したプルリクを見て、コミットを入れるようなこともあるんですか。
kamipo：ありますね。「泣いてマージするまでやめない」を実践しようとすると、こちらとしてもひたすら、プルリクをジャブのように打ち出し続けなければいけないわけで、そうなってくると、自分ひとりの観測範囲では、どうしてもネタが無くなってくるんですよ。その場合、他人の Issue を参考にして、「これは純粋にバグだな」と分かれば、その場で直してしまうようなことはやっています。
idesaku：ひとつの Issue からの連想で、他の部分にもありそうな問題を見つけてしまうようなこともありそうですね。
kamipo：1つを直している最中に「あれ？ こっちも変だぞ」と気付くことは結構多いです。だいたい、1つバグが見つかれば、その背後に2、3個は隠れている感じで。
※本記事の内容は掲載当時の情報であり、現在の情報とは異なる可能性がございます。
本サイト掲載の全て記事は、フォークウェル編集部が監修しています。編集部では、企画・執筆・編集・入稿の全工程をチェックしています。
