シェア
はてブ
特定のリポジトリに対して機能追加・変更やバグ修正などを行う場合、エンジニアはPull Requestを発行します。プログラミングを続ける過程で数えきれないほど発行されるPull Requestは「エンジニアが歩んできた道のりそのもの」と言っても過言ではありません。
ならば、オープンソースコミュニティで活躍する方々が「特に印象に残っているPull Request」には、その人のOSS活動への思いや日々の研鑽が結実しているのではないでしょうか。今回は6名の著名エンジニアの方々に回答していただきました。
※人名の50音順に掲載。回答者は敬称略。
- 天野卓（usualoma）が紹介『perf: Reduce object generation and optimize performance.』
- Kyoheiが紹介『XSS vulnerability prevention for replacePlaceholders function』
- 高田雄大（ydah）が紹介『Implement parameterizing rules』
- 西嶋悠貴（yuki24）が紹介『enable to paginate throurh embedded documents in mongoid』
- 古川陽介が紹介『tools: switch from closure-linter to eslint』
- mox692が紹介『rt: add infrastructure code for io_uring』
天野卓（usualoma）が紹介『perf: Reduce object generation and optimize performance.』
私にとって思い出深いPull Requestは、TypeScript製フレームワーク「Hono」のNode.jsアダプタのパフォーマンスを2.7倍に改善したものです。
アイデアとしてはシンプルで、重いオブジェクトの生成処理を簡略化し、利用頻度の低いプロパティの初期化をデフォルトではスキップして必要なときにだけ行うというものです。この変更は既存の機能に影響を与える懸念もあったので、2週間ほど「より互換性の高い代替案」などを含めて活発に検討が行われましたが、総合的に判断したうえで当初の方針のままマージされることになりました。
このマージは劇的な改善であったので注目を集め、「Hono」の認知向上の効果もありました。また設計上の大きな判断のポイントでもあったので、この件に関わったそれぞれのメンバーにとって強く記憶に残るものであったものと思います。
「Hono」ではしばしば、オーナーの和田さんが「このコードいいね！」というコメントを付けてくれます。Pull Requestは単に「よい」「悪い」の判定や「修正の指摘」のみを行う場ではなく、そういったコメントも含めたコミュニケーションの場であるといいなと常々思っているのですが、よいコミュニケーションが行われた一つの例という意味でも記憶に残っているPull Requestです。
プロフィール
OSSにおいては「Hono」の初期の頃からのコミッターとしてTypeScriptを書き、業としてはシックス・アパート株式会社に所属し、PerlやTypeScriptを書いている。ふと新しいアイデアを思いついて力業で実装して、議論の対象となるようなPull Requestを作成することがある。長野県在住。
Kyoheiが紹介『XSS vulnerability prevention for replacePlaceholders function』
苦い思い出ですが... シェアさせていただきます。
このPull Requestは、私が開発しているOSSのPDFライブラリ「pdfme」において、自身のセキュリティ認識の甘さと、OSSコミュニティの価値を痛感させられた一件として深く記憶に残っています。
当時、「pdfme」はありがたいことにユーザーが増え始めており、これまでにも機能追加やバグ修正のPull Requestは何度もいただいていました。しかし、セキュリティの脆弱性に関する報告はこれが初めてで、強い危機感を覚えました。
発端は、私個人宛に届いた一通のメッセージでした。
「I'm a security researcher and have discovered an XSS vulnerability in pdfme.（私はセキュリティ研究者で、「pdfme」にXSSの脆弱性を発見しました。）」
という報告と共に、丁寧な説明と再現コード（PoC）が添えられていました。Issueで公にするのではなく、まずは開発者に直接連絡するという、まさにホワイトハッカーの文化とOSSへのリスペクトを感じるコンタクトでした。
このPull Requestは、その報告を受けて公開で修正作業を行ったものです。脆弱性を発見してくださった方は私の修正案に対して、夜遅くまでレビューに付き合ってくださいました。ログにも残っている通り、当初の私の修正では不十分であり、さらに深刻な「プロトタイプ汚染」攻撃が可能であることも鋭く指摘していただきました。
正直、脆弱性を作り込んでしまったこと自体は良い思い出ではありません。ですが、この一件が私にとって大きな転機となりました。対応としてコミュニティへの警告、リポジトリ セキュリティ アドバイザリの公開やCVEの登録といった初めての経験をしました。また、自分の認識の甘さを猛省し、セキュリティの勉強や発信を始めるきっかけとなりました。
今振り返ると元々のコードはかなり甘い設計でしたが、OSSを支えるコミュニティの「集合知」の素晴らしさを味わった、忘れられないPull Requestです。
高田雄大（ydah）が紹介『Implement parameterizing rules』
私にとってもっとも印象深いのは、Lramaに新しい機能を追加したパッチです。
LramaとはRuby製のLRパーサージェネレーターです。このパッチは、私が構文解析器の世界に本格的に足を踏み入れるきっかけとなった思い出深いものです。
このパッチで実装したのは、パーサージェネレーターが構文解析器を生成する際にインプットとして受け取る文法定義に新しい文法構造を導入する機能です。これは、プログラミング言語のメソッド呼び出しのように、GNU BisonスタイルのBNFを拡張できるようになる機能で、文法定義の構造化や抽象化の実現、処理の再利用が可能になります。つまり、GNU BisonスタイルのBNFでもこのような抽象化が書けるようになります。
このパッチがなければ、私はおそらくここまでLramaやRubyの構文解析器にパッチを送ることはなかったでしょう。一つの機能を追加できたという成功体験が大きな転機となりました。構文解析器についてもっと知りたいという意欲が湧き、気がつけば構文解析器の世界にどっぷり浸かっていました。
知識がない状態でも興味を持って飛び込んでみることの大切さを改めて実感しました。飛び込んだ先では、そこを取っ掛かりにどんどんできることが増えていきます。一つ突破口を見つけると、そこからハックしていくのが楽しくなり、知識は後からついてきます。
もし何か興味がある分野や興味があるOSSがあれば、まず気になったところからコードを書いて飛び込んでみることをお勧めします。完璧な知識なんてなくても問題ありません。気がつけば熱中している自分に気づくでしょう。
プロフィール
プログラミング言語Rubyのコミット権を有するOSSプログラマー。Lrama、committee、rspec-sidekiqのコミッター、RuboCop RSpec teamのメンバー。Kyobashi.rbの創設メンバー。2024年からは関西圏における最大規模のRubyに関するカンファレンスである大阪Ruby会議 / 関西Ruby会議の実行委員長を務める。
西嶋悠貴（yuki24）が紹介『enable to paginate throurh embedded documents in mongoid』
私が初めてオープンソースに貢献したのは、Rails用ページネーションライブラリ「Kaminari」への一つのPull Requestだった。当時、MongoDBで作りたい機能がうまく動かず、原因を探るうちにソースコードを読み、数行を修正して送ってみた。それが、私にとって初めて「世界に向けて書いたコード」になった。
自分の変更にコメントが付き、誰かが目を通してくれる――それだけのことが新鮮で、世界のどこかで動いている仕組みの一部に自分が関わった実感があった。それまで「オープンソースは誰かが遠くでやっているもの」と思っていたが、その瞬間、自分にもできると感じた。
気づけば「Kaminari」の開発に関わり続け、やがてRailsやRuby本体にも修正を送るようになった。最初はほんの小さな行動だったが、その一歩が今の自分を形づくっている。これからも初めてPull Requestを送った日の“day 1 mentality”を忘れず、静かに一歩を積み重ねていきたい。
プロフィール
Rubyコミッター。Ruby on Railsを中心に、オープンソース開発やライブラリ設計に携わる。代表作に「did_you_mean」などがあり、Ruby本体や周辺エコシステムへの貢献を続けている。かつてニューヨークで約7年間勤務し、米国スタートアップの東京オフィス立ち上げにも携わる。RubyKaigiをはじめ国内外のカンファレンスで多数登壇し、ソフトウェア開発の分野で幅広い実績を持つ。グローバルな職務経験を活かし、日本を拠点に開発者コミュニティ向けの技術支援・教育にも注力している。
古川陽介が紹介『tools: switch from closure-linter to eslint』
2015年の春なので10年前ですね。Node.jsリポジトリのJavaScript部分で使われていたClosure Linterをやめ、ESLintに切り替える提案を出したPull Requestのことです。タイトルは端的に、「tools: switch from closure-linter to eslint」というもので、目的はNode.jsの中で新しい言語機能を堂々と使えるようにすることでした。
当時はES6（後のECMAScript 2015）がいよいよ現実になるタイミング。仕様は同年6月に正式策定され、クラス、アロー関数、テンプレートリテラル、let/constなどが言語に入っていきます。現場でも「そろそろ本格的に使っていこう」という空気が濃くなっていました。(Ecma International)
しかし現実には、Closure Linterが新構文を理解できないため、書こうとする度にlintで弾かれてしまう。後年の公式情報でも、Closure LinterはES6との相性の悪さが明示され、事実上deprecatedな扱いとなっていきました。
https://developers.google.com/closure/utilities?hl=ja
だからこそ、「ES6フレンドリーなLinterへ」というのが提案の出発点でした。提案の芯はシンプルです。Closure Linterを外し、ESLintを導入する。まずは広く壊しすぎない範囲で既存のJSにESLintを掛け、エラーを潰していくという入口を設計しました。Pull Request本文にもその方針を書き、ESLintを導入しつつも大きく変更しすぎない範囲で段階的に進めています。
レビューでは、たとえばトップレベルの間に空行をどれだけ入れるかとか、クォート規則、未使用引数の扱いといった細部で議論が起きました。つまり、「新しい構文を使う」だけではなく、プロジェクトとしての可読性の基準をどう置くかという問い直しです。議論のやりとり（two blank linesルールやquotes設定の提案など）は今見ても示唆に富んでいます。
レビューを経て、作業は「tools: replace closure-linter with eslint」というコミットとして着地しました。コミットメッセージには複数のレビュアーが並び、PR-URLとして #1539 が明記されています。Pull Request自体は2015年5月9日にクローズし、切り替えはNode.jsリポジトリの歴史の一部になりました。
ESLintへの移行で一番効いたのは、チームとして可読性の上限が上がったことです。「新しいJavaScriptの構文」を遠慮なく使えるようになり、結果として可読性もメンテナンス性も底上げされました。
一方で、新構文に寄せすぎると古いラインへのバックポートが難しくなるのは現実的な悩みでした。LTSラインや保守ブランチでは、当時のV8/Nodeの事情から、ES2015のすべてを受け入れられない場面が少なからずあったのです。そこで「移行可能性と保守性のバランスを取りながら少しずつ前へ」という進み方を選ばざるを得ませんでした。
年月が経った今、Node.jsのコードベースでは多くのモダン構文が自然に使われ、Lint もアップデートし続けています。今では普通に色々な構文が書ける上にさらに新しい構文も使われるようになってきました。非常に大変な作業でしたが、楽しかったなと振り返って思います。
プロフィール
一般社団法人 Japan Node.js Association 代表理事
mox692が紹介『rt: add infrastructure code for io_uring』
このPull Requestは「tokio-rs」というRustのライブラリにio-uringというLinux Kernelの機能を導入するための変更です。これは私が最近取り組んだPull Requestの中で比較的大きい変更だったので心に残っています。
「tokio-rs」にio-uringを導入するというアイデア自体はかなり昔からあったのですが、なかなか実装されてきませんでした。
ただ、今年の春あたりにメンテナの1人と日本で会う機会があり、そこの中の雑談で「io-uringの実装ってできないのかなー」と軽く持ち出してみたところ、「技術的には可能だと思うよ」というお墨付きをもらい、取り組んでみようと思ったのがきっかけです。
いざ取り掛かる際、これは大きな変更になるだろうと予想がついていたので、私は実装に入る前にhack.ioにデザインのスケッチを書き出すことからスタートしました。また、実際に自分のforkリポジトリで「tokio-rs」のランタイムを改造してio-uringを使った場合にどのようになるのかの実験も裏で色々して、それをデザインdocsに反映していました（今年のGWはこの検証作業にかなりの時間を溶かしていた気がします...笑）。
その検証の結果がこのPull Requestです。このPull Requestはその後無事にマージされ、これに続いていくつかのio-uring関連のAPIの実装もマージされました。晴れてv1.48.0からExperimentalでio-uringの使用が一部のFile APIで利用可能になっています。
プロフィール
Software Engineer / Rust / OSS / interested in performance, observability, etc / maintainer for tokio-rs.
編集：中薗昴
