CRuby Committers Who's Who in 2013
CRuby Committers Who’s Who
はじめに
この記事は 2013 年 5 月 30 日から 6 月 1 日にかけて開催された RubyKaigi 2013 で筆者が行った発表 CRuby Committers Who’s Who in 2013 を再現して加筆したものです。
この発表後の反響をきいてみると、普段 Ruby を利用していても CRuby そのものの開発がどのように行なわれているのか、どんな人が Ruby を開発しているのかというのは、著者が思っていた以上に知られていないようでした。 そこで発表時からさらに数名のコミッターの紹介を追加して、どんな人が Ruby を開発しているのかその雰囲気を紹介してみたいと思います。
CRuby の開発について
筆者が 2011 年の RubyKaigi 2011 の LT で「ruby-trunk-changes 統計版」という発表をした当時、平均 1 日 9.2 回コミットがありました。 RubyKaigi 2013 での発表( 2013 年 5 月)時点の過去 1 年間の平均は 1 日 12.4 回になっていました。およそ 35% も変更頻度が増えています。
原因のひとつとしては 2013 年 2 月の 2.0.0 のリリースがあると思います。2.0.0 はメジャーバージョンアップということもあり、新機能の追加やその不具合修正など、特に feature freeze 前には大量の変更が行なわれた時期がありました。
もうひとつには最近コミッターになった方や、パッチを送ってくれる contributor が増えているからということもあるかと思います。 特にドキュメント関連のメンテナンスについては専属のコミッターが参加されたことで変更が活発になっています。
CRuby の開発の議論は主にメーリングリスト(ruby-core および ruby-dev)や Redmine による BTS 上で行なわれています(IRC や Twitter 上での場外乱闘もままありますが)。新機能の追加など重要な議題はコミッターが実際に集る開発者会議で Matz の采配を仰いだり開発者間で議論してアイデアを出し合ったりします。やはり実際に顔を合わせて議論すると話が早いようで、開発者会議後はどっと機能追加や仕様変更が行なわれる傾向にあります。 また開発者会議は主に日本語で行なわれていますが、Redmine 上での議論は英語のほうが流量が多く、日本語の ML だけ購読していると最新の機能の議論などには乗り遅れること必至という状態です。
CRubyコミッター紳士名鑑
svn.ruby-lang.org に登録されている SSH 鍵の情報によると現在 82 名(?)のコミット権を持つアカウントが存在するそうです。現在は既にあまり活発に活動されていないかたもいるので、ここ 1 年くらいに限定すると活動しているのはそのうち 40 名ちょっとくらいです。
そのうちから数名のコミッターを紹介します。この他にも標準添付ライブラリをメンテナンスをされているかたなどもいらっしゃいますが、主に Ruby 本体に手を入れているコミッターを中心に選んでいます。
また、筆者が CRuby のコミットを観察してきた経験を生かし、その人のコミットのなかから印象深いものを選んで一緒に紹介してみます。
matz
まずはいわずと知れた「Rubyのパパ」Matz です。 もちろん Matz も CRuby のコミッターです。CRuby の開発においては最近はあまり直接コミットをすることはなくて、主に新機能や仕様変更の提案について OK か NG かを判定するというのが主な仕事です。
そんなまつもとさんの最新のコミットは r39482 です。
https://github.com/ruby/ruby/commit/c5a7cf00660c8e1797772a357b2b0913c1fe4263
見ての通り ruby のバージョンを定義するマクロを 2.1.0 に更新しています。 最近(2.0.0 に上げる時から)のこのマクロの変更はなぜかまつもとさんにお願いするようになっているようです。 それまではリリースマネージャだった yugui さんや他のだれかが上げていましたが、一種の儀式ですね。
リリースマネージャ「先生、お願いします」
Matz 先生 「うむ(カチャカチャカチャ。ッタァーン!)」と、こんな感じです。
ところでこのコミットにはコミットログが書かれていません。コミットログなしでコミットして許されるのも matz だけだと思います(と、発表時に発言したら irc で「いや、許されないだろ」とツッコミが入ってました。次回は何卒一言お願いします)。
nobu
パッチモンスターこと nobu、なかださんです。
なかださんは CRuby に対して最も多くのコミットをしているコミッターで、不具合の報告をすると既にそれを修正するパッチを持っていてどこからかそれを取り出してくるということから「パッチ袋を持っている」「パッチモンスター」と呼ばれるようになりました。
なかださんは現在 Heroku 社に所属して CRuby の開発を本業としているフルタイムコミッターのひとりでもあります。
これは CRuby のコミッターである卜部さん(svn アカウント shyouhei)が公開された CRuby へのコミット件数の遷移をコミッター毎にプロットしたグラフです。 赤い線がなかださんで、圧倒的に多くのコミットをしていることがわかります。 2008年ごろにコミット数で matz を抜いて、すでに 2倍以上の差をつけて現在でも最もアクティブに活動しているコミッターです。
そんな圧倒的多数のコミットをしているなかださんなので、どれか1つを選ぶというのは難しいのですが、最近のおもしろいコミットということで r40806 を挙げてみます。
https://github.com/ruby/ruby/commit/3e8bba2fc1138fb072935b3f935810a78ce71a8c
これはスタックオーバフローの検出と例外処理などの大域脱出のしくみの組み合わせて発生していた不具合の修正です。
変更点は実質1行だけで、構造体のメンバの順番を入れ替えているだけなので、一見してなぜこれで修正になるのかわかりません。
CRuby では新たに生成する Fiber のマシンスタックのオーバフロー検出のために、Guard Page といってアクセスするとシグナルが発生するように設定したメモリ領域をスタックの最後に配置するようにしています。
関数の呼び出しが深く入れ子になりマシンスタックを使いきってしまうと、この Guard Page にアクセスすることで SIGSEGV が発生して、それを検出した CRuby インタプリタは SystemStackError 例外を発生させます。
なおこのしくみは Fiber でのみ有効で Thread では別の方法でオーバフロー検出をしているはずです。
そして大域脱出の処理時にマシンスタックを巻き戻すためのTH_PUSH_TAG()というマクロで、マシンスタック上に rb_vm_tag という構造体を置きます。 この構造体はリンクリストを構成していて、Ruby のスレッドを表す rb_thread_t 構造体のメンバ tag から、大域脱出時に巻き戻すべき状態(rescue や ensure など処理を挟むべきポイント)を順に辿れるようになっています。 実際に巻き戻す状態は rb_jmpbuf_t という型のメンバに格納しています。
不具合はこの rb_vm_tag 構造体の rb_jmpbuf_t 型のメンバが丁度ぎりぎり Guard Page の領域にひっかかってしまうときに起きていました。
TH_PUSH_TAG() で rb_vm_tag の linked list に繋ぐ処理までは rb_jmpbuf_t のメンバにはアクセスしないので、繋ぐことには成功してしまうのですが、現在の状態を rb_jumpbuf_t に保存しようとすると Guard Page へアクセスするため SIGSEGV が発生して、
スタックオーバフローを検出して例外の発生を行おうとするのですが、既に rb_vm_tag の linked list に最新の構造体が繋がれてしまっているため、まずその状態に復元しようとして再度 rb_jumpbuf_t のメンバにアクセスして SIGSEGV が発生、という
ある種の無限ループ状態に陥ってしまっていました。
そこで rb_vm_tag の構造体のレイアウトを変更して、linked list に繋ぐ操作の時に初期化を行う tag と prev というメンバが構造体の先頭と末尾に配置されるようにして、構造体が一部でも Guard Page にひっかかるように置かれたら linked list に繋ぐ前にオーバフローを検出するようにしています。
とまあ大変こみ入った問題でした。デバッグも大変だったと思います。よくこんなのに気がついたなーと思います。すごいですね。
ko1
次は ko1 ことささださんです。
ささださんは 1.9 から導入された、かつて YARV (Yet Another Ruby VM) と呼ばれた Ruby の VM の作者です。 2.1 では RGenGC という世代別GCもささださんが実装されました。 主に CRuby の処理速度を早くするための変更を仕事としていて、Ruby開発者の中ではスピード狂と呼ばれています。 ささださんも Heroku 社に所属するフルタイムコミッターです。
ささださんも沢山の仕事をされているのでどれか一つを選ぶのは難しいのですが、RGenGC を導入した r40703 を挙げてみます。
https://github.com/ruby/ruby/commit/4f401816ffaf9b641cfbc8ad12203eedcdb527de
実際には RGenGC の導入には前準備として複数のコミットに分けてリファクタリングやサポートする機能追加が入っているのですが、このコミットだけでもこれだけ長いコミットログが書かれています。 RGenGC はインタプリタ全体でオブジェクトの取り扱いに変更を入れないといけないので、非常に大規模な変更です。
手元で git show コマンドで差分の行数を調べてみたら 1921行でした。
$ git show 4f40181 | wc -l 1921
ささださんのコミットはrubyのcoreなところを変更するものが多くて、特にこのように完全に新しい機能や実装を追加する時には変更が大規模になりがちなので、毎日コミットを読んでいる身としてはささださんのコミットがあると身構えてしまいます。
しかし、ささださんがそんな大規模な変更をするたびに、CRuby は高速になったり、魅力的な新機能が追加されたりします。 ささださんが主にターゲットとしているのは、Refinements とか prepend のように言語仕様に関わる部分よりは、デバッグやプロファイルをサポートする機能であることが多いです。 CRuby そのものに興味がある人間からすると非常に魅力的で興味深い機能追加をたくさんされています。
akr
次は akr さんこと田中哲さんです。 akr さんは組込みクラスの Time や socket, stringio, open-uri, pathname など数々のライブラリのメンテタでもありますが、それに限らず広範囲に修正を行なっています。 時々あるテーマを決めて、そのテーマに沿った変更を継続的に入れていくというスタイルで多くのコミットをされています。 最近のブームは bignum.c のリファクタリング/高速化と Process.clock_gettime という新たに追加されたメソッドの周辺みたいです。
akr さんのコミットは1つではなくて、同じテーマに沿った一連のコミットを挙げます。 r33652 から始まる約3ヶ月強にも渡る、拡張ライブラリ dbm のビルド回りの一連の変更です。
https://github.com/ruby/ruby/commit/e4e5b7df4cca2cedba1ec2b52f75c450a0c618ce
この変更では拡張ライブラリ dbm が利用する DBM のライブラリの豊富な亜種のうち、どのプラットフォームでどのバージョンが使えるというのを検出する方法をひたすら精密にしています。
拡張ライブラリ dbm が wrap するライブラリの一覧を以下に挙げてみましたが、種類が多い上にバージョンによって検出に使えるマクロや関数が異なっていたり、libc に同梱されているケースもあるなど非常に多くのバリエーションがあります。
- libc(ndbm compatible)
- Berkley DB (libdb, libdb2, libdb3, libdb4, libdb5)
- GDBM (libgdbm, libgdbm_compat)
- QDBM (libqdbm)
- libndbm
これを extconf.rb で自動的にどのバージョンなのか検出して、適切なヘッダとライブラリを利用するように設定するために細かな修正を積み上げています。 実は RubyKaigi 2013 の田中さんの Keynote もこの dbm のライブラリ検出についてがテーマでした。その発表をみると、この仕事の複雑さと緻密さがよくわかると思います。 こういう面倒な仕事を時間をかけて取り組んでいるところに凄みを感じます。
ちなみにこの一連の修正については akr さんの RubyKaigi 2013 の Keynote Fight with Diversity で詳しく語られていますので、ぜひ動画でご覧ください。
usa
次は usa さんです。 usa さんは Windows のプラットフォームメンテナです。また安定版ブランチ 1.9.3 のブランチメンテナでもあります。 コミッター界随一の歴史家でもあり、歴史の話になるととめどなくネタが溢れ出してきます。
usa さんは Windows のプラットフォームメンテナとして、Unix 系のプラットフォームで作業している他の人達が変更/新規追加したものを Windows でも動くように修正したり、機能追加に追随したりという仕事をされています。 ここでは r40693 で拡張ライブラリ socket に追加された Socket.getifaddrs というメソッドが同じ名前の UNIX 系のライブラリが提供している関数(getifaddrs(3))に依存しているので、Windows 上でも動くようにエミュレーションする関数を追加しています。
https://github.com/ruby/ruby/commit/cb3fcdcdc3eeb4612c78d1fac10438214184642f
Ruby は UNIX の文化圏で産まれた言語なので、UNIX 的な環境を前提とした機能が多くて、それを Windows でも動くようにするためには少数のコミッタによって大きな労力がはらわれています。
naruse
次は naruse さんです。 成瀬さんは CRuby の Multilingualization(多言語化)や正規表現エンジン(鬼雲。鬼雲は田中さんという別のかたがメンテされていますが、CRubyに修正を取り込んだりするのは主に成瀬さんが行なっています)、拡張ライブラリ nkf のメンテナです。 Ruby は 1.9 から文字列がエンコーディングを持つようになりましたが、その実現に多大な貢献をされています。 また 2.1.0 のリリースマネージャを mame さん(遠藤さん)から引き継ぎ、2.1 は成瀬さんの旗振りによってリリースされることになります。
成瀬さんが ruby のビルドやテストを様々なプラットフォームで実行した結果をまとめて表示する rubyci.org というサイトを運営しています。
実際にビルド・テストを実行しているのはそれぞれ別の管理者が管理しているサーバですが、その結果を収集して一覧できるようにしてくれています。
各プラットフォーム毎のサーバでの自動テストの仕組みは akr さんの chkbuild というプロジェクトが利用されています。
このようにいろいろなブランチとプラットフォームの test-all の結果や RubySpec の実行結果が一覧できます。 複数のプラットフォームでの動作確認ができるため、安定版ブランチのメンテナンスのためにも非常に重要なサービスです。 また成瀬さんはテストがエラーになった時にその原因を追求して修正し、テストが常にグリーンになるように努めるという活動も熱心に行なっていらっしゃいます。 CI はエラーが発生している状態が続くと、他の変更によるエラーを見逃しやすくなったり、後から不具合の原因のコミットを調査する時にもわかりにくくなってしまいますので、CI をグリーンに保つというのは非常に重要なことで、環境依存や稀に起きるエラーの対処などにもかなり労力を割いています。
kosaki
次は kosaki さんです。 kosaki さんは「ガチャピン先生」という愛称で親しまれている愛されキャラですが、CRuby のコミッターの他に Linux Kernel の開発者としても活躍されていて、主にメモリ管理を担当されているとのことです。 CRuby の開発では Redhat Enterprise Edition と CentOS のプラットフォームメンテナで、Thread 管理や Signal 処理などシステムプログラミング回りの実装に深く関わっていらっしゃいます。 またメーリングリストでの発言等をみていると、オープンソースコミュニティでの議論のしかたが上手だなと思うことがよくあります。LKML(Linux Kernel Mailing List) で鍛えたコミュニケーション能力でしょうか。
kosaki さんは CRuby への貢献ももちろん多数ありますが、少し変化球で Linux Kernel へのコミット d84ba638e4ba3c40023ff997aa5e8d3ed002af36 を選んでみました。
ここでは select(2) に TCP ソケットの file descriptor の書き込み可能になるのを監視するために渡した時に、通信相手がソケットを閉じた時に select(2) から抜けないためにハングアップするという問題があったのを、 Kernel のシステムコールの仕様を変更するという方法で修正したというものです。
このシステムコールの挙動は CRuby の実装の都合には合わなかったものの、不具合と言えるものではなく、カーネル開発者の間では互換性を崩すことが問題視されたそうで、この変更を入れることを説得するのには苦労されたとのことです。
nari
次は Mr. GC こと nari さんです。 CRuby の GC (Garbage Collector) の開発をされています。 LazySweep や Bitmap Marking など Ruby の GC を改造して効率化する仕事をされています。 一部では Lazy Sweep により SEGV が誘発されるので Lazy Sweep を止めることができるようにするパッチが当てられているというのをきいたことがありますけど……。
nari さんのコミットからは、あえて GC とは全く関係ないものを選んでみました。 r37432 は Kernel#dir というメソッドを追加して、実行中のスクリプトファイルのディレクトリを簡単に取得できるようにしています。
https://github.com/ruby/ruby/commit/805b08f2925f5ceec67bf472e76e869bbddc8c39
Kernel#dir は 2.0.0から使えます。Load Path の設定などで比較的使いたくなる場面が多いので便利なメソッドです。 GC の権化のように思われている nari さんですが、こんな変更も行なっているということで紹介してみました。
zzak
次は zzak さんです。zzak さんは比較的最近コミット件を取得されたかたで、主にソースコード内にコメントとして埋め込まれた RDoc のドキュメントのメンテナンスを行なっていて、最近活発に活動されているコミッターのひとりです。 特に海外からのドキュメントの追加や修正の pull request は多くて、現在は主に zzak さんがこれを対処してくれています。
ドキュメントの修正が主ということでどれか1つのコミットを選ぶということができませんでしたが、るりまとの協調や Ruby の開発への貢献についてカンファレンスで発表するなど精力的に活動されています。
shugo
次は shugo こと前田さんです。 前田さんは mod_ruby や eruby といったプロジェクトの開発者であり、Ruby 本体ではセキュリティモデルのメンテナであり、古くは Continuation の発案者でもあります。 最近一番話題なのは Refinements の提案と実装ではないかと思います。
前田さんのコミットからは r38262 を選びました。
https://github.com/ruby/ruby/commit/537297d1cbcd2ed97488774e67c4fc001282a658
これは 2.0.0 のリリース直前に、Refinements の仕様を大きく絞って、スクリプトのトップレベルでしか使えないようにする変更です。
本来はもっと機能が豊富だったのですが、JRuby など他の実装で同じ仕様を効率的に実装できないなどの理由で議論が収束せずに、2.0.0 では一部だけリリースすることになってしまいました。
Github 上でのこのコミットの差分を表示したスクリーンショットを取ってみました。これでも実は全体の 2/3 くらいです。赤く色付けされているのが削除された行なので、こうしてみると折角作った実装をかなりの量削ることになってしまったのがわかります。 現在 2.1 では Module のスコープ内でも Module#using が利用できるようになり、Refinements の機能が復活しつつあるので、2.1 のリリースをお楽しみに。
mame
mame さんは 2.0.0 のリリースマネージャであり、キーワード引数、private 定数、Range#bsearch などの提案&実装を行ったコミッターです。 趣味では Quine や競技プログラミングの道を邁進していて、「超絶技巧プログラマ」「変態(褒め言葉)」としても有名です。最近発表されたQuineリレーでは海外にまでその名を轟かせているようです。正直読んでもなにがなんだかわかりません。
最近はこれらの趣味と本業で忙しいようで、Ruby 2.0.0 のメンテナンスは nagachika (著者) が、2.1.0 のリリースマネージャは naruse さんが引き継いでいます。
hsbt
hsbt さんは 2013 年 2 月 23 日 Ruby 生誕 20 周年パーティーの日に開催された開発者会議で www.ruby-lang.org の環境移行などを提案してコミッターになりました。 その後 www.ruby-lang.org の移行、Redmine の改修、サーバ管理業などなどまさに CRuby の開発を支える縁の下の力持ちとして八面六臂の活躍をされています。著者もリリースのたびにお世話になっています。最近は ruby-lang.org が乗っていたサーバの故障で FTP やメーリングリストに障害が発生した時にもその復旧に奔走されていました。本当にお疲れさまです。 Ruby を使っている人は皆 hsbt さんに足を向けて眠れません。
また hsbt さんは http://ci.hsbt.org/ というサイトで CRuby の trunk の最新版でメジャーな Ruby のプロジェクトのテストが動くかをチェックする Jenkins による自動テストを管理されていて、trunk の変更により動かなくなるプロダクトがないか監視するのに一役買っています。
luislavena
luislavena さんは Windows 版の Ruby のパッケージのひとつ RubyInstaller の作者の方です。 Windows 上で動作する CRuby は大きく分けて mswin 版、 mingw 版、 cygwin 版などがありますが RubyInstaller は MinGW を使ってビルドされているパッケージです。 また luislavena さんは RubyInstaller のパッケージのビルドとテストを自動的に実施する ci.rubyinstaller.org というサイトをメンテナンスされています。最近 rubyci.org にも mswin 版の環境が追加されて(そちらは unak さんがメンテナンスされています) Windows 版の CI が増えていますが、それまでは ci.rubyinstaller.org が唯一の Windows 版の CRuby の CI でした。 開発環境として Linux や Mac OS X を常用しているコミッターがうっかり Windows 環境を壊してしまうという事態はよく起きるので、それに一早く気づくためには非常に有用です。もっともこちらを常時チェックしている人はあまり居ないかもしれませんけど。 安定版ブランチメンテナとしても、rubyci.org と並んでバックポートで何か壊していないかチェックするために非常に助かっているサービスです。
charliesome
charliesome さんは数年前からちょくちょくメーリングリストやチケットで CRuby のコア部分について不具合報告や提案でパッチを送ってきていた方で、最近(と言ってももう去年のことでした)コミット権を取得されています。 送られていたパッチをみると CRuby の内部の構造にはかなり詳しいようで、最近はメソッドキャッシュの改善など、インタプリタのコアな部分に手を入れるコミットをしています。 そのメソッドキャッシュの変更が r42822 です。
https://github.com/ruby/ruby/commit/2f522b9cc6f3e184404040b12af4486520a73b26
CRuby のインタプリタにおいてメソッドの探索というのは重い処理で、その結果をキャッシュしておくのは性能のために重要な機能です。これまではこのキャッシュの無効化はどこかのクラス/モジュールでメソッドが定義されたりすると全体に影響を及ぼしていたのですが、それを継承関係を考慮して必要なところだけキャッシュを無効化することで性能への影響を低減しようとする変更です。 メタプログラミングを多用していて特異クラスつきのオブジェクトなどを頻繁に使い捨てるような場合にはパフォーマンス改善に大きな効果がありそうです。
なお charliesome さんは今 Github に所属しているみたいです。ずっとどんな人なのかわからなかったのですけど、最近写真を観て、思っていたよりもずっと若そうだったのでびっくりしました。なんとなくもうちょっと年かさな人だと思ってたので。 また現在 1.8 系の公式のメンテナンスは既に終了していますが、charliesome さんは RubyLTS という 1.8.7 の脆弱性修正を独自に継続するプロジェクトもメンテナンスされています。
svn
最後に svn さんを紹介します。 svn さんは長年にわたって、ほぼ毎日コミットしている古株のコミッターで、version.h というヘッダに定義されている更新日付を更新するという仕事を黙々と続けています。 svn さんはいつも同じ変更をしているので、特にピックアップすることもないのですが、印象深かったコミットとして r30000 を挙げました。 svn さんは他のコミッターがその日最初にコミットするとすかさずコミットするという性質があり、この日は r30000 というキリ番を svn さんがゲットしてしまったというのが印象に残っています。
RubyKaigi での発表のあと、この直前のコミットをした usa さんにきいたところによると、実は svn さんにキリ番を取らせるためにわざと調節していたんだそうです。
nagachika
一番最後に自己紹介になります。著者は現在安定版 2.0.0 ブランチのメンテナとして、不具合修正等をバックポートして、パッケージをリリースする仕事をしています。 また CRuby の trunk へのコミットを毎日読んで、日本語でブログに短い解説を書く ruby-trunk-changes という活動をしています。
http://d.hatena.ne.jp/nagachika/
ruby-trunk-changes は最初日々の変更を読むことで勉強になるかなと思って始めたことですが、長く続けていると次第に Ruby の変更についての外部記憶みたいなものになっていて、不具合っぽい挙動や欲しい新機能の話を聴いたら、心当たりのあるキーワードで検索してみると解説が書いてあって、それtrunk で直してるとか、その機能 trunk にはあるよとかわかって便利なので自分でも重宝しています。 ruby の最新動向に興味のある方はぜひ subscribe してみてください。
謝辞
本記事で紹介できたのは、最近活動しているコミッターのなかでも一部です。他にも添付ライブラリのメンテナのかたや Windows 環境の面倒をみてくださっているかた、サーバの管理などバックヤードを支えている方もいらっしゃいます。紹介から漏れてしまったのはひとえに筆者の力不足と寝不足によるもので申し訳ありません。 またコミッターではなくても CRuby へパッチを送ってきてくれたり、不具合報告をしたり、その不具合報告の対応をしてくれるコントリビュータのかたも多数いらっしゃいます。 今日紹介しきれなかったかたも含めたたくさんの方々の支援と協力があって Ruby の開発は成り立っています。 あらためて Ruby の開発に携わるみなさんへの感謝の言葉でこの記事のまとめとさせて頂きたいと思います。 いつもありがとうございます。