java-ja.OSS でOSSの話をしてきた
自分はべつにOSSの偉い人でもなんでもないのだが、YAPCで話したこととその発展みたいな感じでどうよということがあって、ざらっと話してきた。イベントはこちら。
で、スライドはこちら。YAPCの再演でもいいよってことだったけど自分がそれじゃつまらんので、その後の話なんかも含めて取捨選択した。これまでの話は知ってる人が(会場には)やっぱり多かったので、発展的な話題とか細かいところをひろっていくような話にしたつもり。
OSSそのものについてどう思うかっていうの、実際に自分に強い意見があるかというとそんなにはなくて、ストレスを感じなくていいケースではいちばんストレスのない方法を淡々と選びたいなあ、と思うくらい。
そうでないもの*1にはそれはそれで色々あるけど、それはまあ仕事だからなあ、という感じ。日本国内のコミュニティだと仕事としてOSSをやっている会社がほとんどない関係で、そのあたりの話はちょっと興味深い人はいたかもしれない。あるいは、現実離れして聞こえたかもしれない。……ところで仕事としてOSSをやっているTreasure Dataという会社があるらしいよ!
ところでOSSの話をするときに自分がどの視点に立脚しているかを前提として話しておくのは本当はけっこう大事で、それによって考え方や行動様式がだいぶ変わるから。というのは、イベント翌日にTwitterで流れてたtweetを見ても思った。
俺が「後方互換性はソフトウェア作者と利用者の信頼関係の源なんだよ。だから努力に努力を重ねて守るんだよ！！」という講演をした後で、松田さんが Rails の文脈で「互換性なんて💩」という講演を始めたの、かなり面白い流れだった #java_ja_oss
— Takuto Wada (@t_wada) 2015, 10月 6@t_wada そうですね。和田さんも、あと @tagomoris さんも、基本的に同じテーマについて喋ってるはずなんだけど僕が言おうと思ってたこととあんまり重ならないというかむしろ真逆みたいなことをけっこう言ってて、すごい面白いなーと思いながら聞いてました。
— Akira Matsuda (@a_matsuda) 2015, 10月 6これは当日に @a_matsuda さんの話を聞いててもすごく思っていたところで「あー莫大なユーザと大規模な開発者コミュニティをかかえてる超強力OSSプロダクト*2はやることが違うなー強いリーダー*3もいるしすげーなー」みたいな。立場が違うとやることが変わる。
ただし唯一(?)共通していたのが「走り続けないと死ぬ」みたいなやつで、これはRubyの開発とかでもコミッタの人々*4がよく言っていることだと思う。違う視点の話だけど毎日コミットするのを継続するっていうやつ、自分は怠惰なので不可能だけど、なるほどなあ、ということを思いはする。
なんにしろ、こういう機会があって自分の思うところをしゃべったり、他の人の話を聞きながら適度にツッコんだりできる機会はたいへんありがたい。
あと夜中まで超面白かった。ありがとうございました。
続: OSSプロダクトとコミュニティの話
先日書いた通りYAPC::Asia Tokyo 2015でOSSの開発とメンテナンスについての私見を話したところ、会場で id:t-wada さんから強烈な質問と、その後にまとまった量のエントリがきた。
t-wadaさんの問題意識については上記エントリを読んでいただくとして、これに関連してYAPC::Asia期間中にいろいろな人と話したこと、およびその後に考えたことなどをまとめて書き下しておこうと思う。
明快な結論は無い。無いが、自分にとってのなんとなくの指針のようなものには多分なっており、こういうことを考えて自分はこれからコードを書くんだろうな、という気がする。
なお前提として自分がYAPC::Asia Tokyo 2015で話した内容がベースにあるので、できればそちらを把握しておいてほしい。t-wadaさんのエントリにあるメモは話した内容をよく反映しているし、質疑応答の内容などもあるので動画を見るとよいかもしれない。
コントリビューション vs コードの統一性
ごく当たり前のことだが、ソフトウェアというのは、一人で書いたコードが100%を占めていれば、最も統一性のあるコードになる。ただし人間は2〜3ヶ月も経てば別人に等しい何かに変貌してしまうこともままあるため、ここには「短期間のうちに一人で書いたコード」という制約が付く、こともある。
そのコードに何らかの設計あるいは統一されたスタイルというものが無ければそれはその人の責任だが、それはとりあえず問題外として置いておくことにする。
あるソフトウェアがある。どういった目的のために書かれたのかが明確であり、理解しやすい外部APIを持ち、良い効率で動作する。全体の設計は十分にシンプルで理解しやすく、一瞥すれば統一性があって読みやすいことがわかる。いまこの時に限って言えば、完璧なソフトウェアと言ってよい。*1
さて、このソフトウェアに外部から何らかのコードの貢献がある。それは全く知らない誰かからの機能の追加であったり、(その人にとって)意図しない動作の修正であったり、あるいは数ヶ月後の未来の自分からの仕様の変更であったりする。
このコードの貢献は、元の完璧であったソフトウェアを必ず乱す。当初ありえなかった変更がありえなかったはずの場所に入り、シンプルだった内部APIは拡張された仕様に対応するために醜く引数を足され、ひとつのことだけを正しく行っていた関数はなぜか2つ3つと機能を内包するようになる。
貢献者が未熟だから起きるわけではない。どんなに優秀なプログラマでも他人のコードの統一性に完璧に寄り添うことはできないし、例え変更を加えるのがオリジナルの開発者であっても、数ヶ月あるいは数年も経つと書くコードの癖は変わる。ソフトウェア開発者はリリース後に必要となる変更を全て予期することはできないし、であれば、予期できなかった変更は元の完璧なコードに不可避な変更を押し付ける。
OSSプロダクトの開発と利用の促進を進める上で、これは必ず起きることだ、と思う。
もちろんあらゆる貢献を拒絶すればこの変化の進行を最小限に抑えることはできるが、ユーザとユースケースが広がらずメンテナンスの行われないソフトウェアの先に待つものは、単なる停滞でしかない。
プロダクトにおける沈降 vs コミュニティにおける浮上
最初は十分に小さく美しく軽快だったソフトウェアが、多方面からの多数のコントリビューションにより大きく醜く鈍重なものになっていく。一方OSSコミュニティにおける開発者たちは常に、小さく美しく、気軽にコントリビューション可能で、そして参入しやすいソフトウェアを求めている。
これは不思議でもなんでもないし、矛盾してもいない。誰だって同じことができるならより労力の小さいほうがいいに決まっている。既存プロダクトのコミッタなら既存プロダクトに変更を加えるほうが簡単だろうし、そうでなければ、まだ十分多くの人には使われていないかもしれないがしかし十分に小さく美しいソフトウェアがあれば、そちらに貢献するほうがおそらく合理的だ。
コミュニティはこうして、全体的には小さく美しいコードを志向する。これは個々のプロダクトが必ず肥大化し醜くなるという事実とバランスして動的平衡のような状態を作りだす余地を持っており、おそらく、そのふたつが完全にバランスしていれば、それはコミュニティ全体としては健全なのだろうと思う。*2
だからここまでを総合すると、t-wadaさんの疑問に対する答えを書ける。
健全な OSS 社会ときれいなソフトウェア設計との間には、やはり緊張関係はある、ということになるのだろうか。
ない。適切なバランスが保たれていれば。
プロダクトの長い寿命 vs コミュニティにおける新陳代謝
コミュニティ全体の動向に関係なく、各々のプロダクトはその寿命を可能な限り長くしようとする。これはそのプロダクトに主要開発者として関わっているチームがある限りは自然なことだ。自分が今現在開発しているソフトウェアについて「これはもう使うな」と言える人は多くはないだろう。
また別の事情もある。ユーザは大抵の場合、開発者よりもはるかに長い寿命をソフトウェアプロダクトに期待する、ということだ。今問題なく使えているものを変更する理由は普通のユーザには無い。
既に動いていて長い歴史をもっているプロダクトは、大抵強固な開発者チームをもっている。新規参入はやはり難しい……ケースが多い。長い歴史をもつプロダクトには過去様々なことが起きており、新規参入者にとっては理解不可能な設計やコードも、過去の経緯を知っていれば納得できることもある。
もちろんコアの開発者チームがあまり大きくなるとコミュニケーションにも影響が出る。
こういった事情がやはり、新規の参入者にとっては障壁になる。こうして若く元気のある人達はこぞって小さく美しいプロダクトの開発に夢中になり、長い寿命をもったプロダクトのコア開発者の平均年齢は、毎年ひとつずつ増える。
小さくて美しい vs 活発なメンテナンス
djbという開発者によって書かれた一連のソフトウェアがある。知らない人はぐぐってほしい。……昔は知らない人などいなかったものだが、今ではもしかして、知らない人の方が多いかもしれない。つまり、そういうことだ。
djbwareは小さく美しく、ひとつの目的を果たし、バグも(ほとんど)なく、また小さいツールの集合により機能を実現する形になっていたから、変化に対しても強靭だった。そしてそれ故に外部からの貢献といったものを受け入れず、孤立していた。
これはおそらく、djb本人にとっては本望だったのだろうと思う。そしてユーザから見れば、各OS/ディストリビューションのやり方を無視し、わかりにくい設定と操作方法を押し付け、必要な機能を足してくれないソフトウェアに見えたかもしれない。
世界はdjbwareに支配されなかったし、ApacheやPostfixやBindや、あるいはsupervisordやUpstartやsystemdや、そういった多くのソフトウェアが世界を分割している。
ここでは絶対的な基準や善悪を語っているわけではないから、djbのやりかたでもよいではないか、という意見はあるだろう。もちろん、どういうやり方をとるかはその人の自由だと思う。
All-in-one vs Plugin chaos
ソフトウェアに多くの機能を足しユーザコミュニティと開発者コミュニティを広げつつ、ソフトウェアのコアを小さく美しく保つ方法がある。プラグイン機構の導入だ。
ソフトウェアの機能の多くをプラグインに移譲し、誰でもプラグインを書き公開できるようにしておく。多くのユースケースを組込みのプラグインでカバーしつつ、それ以外に必要なものは必要な人が開発し公開できるようにする。
これはうまくいく。最初の設計が十分にうまく行われていればコアに必要な変更は後々までそう多くはない。多くの人が使いたい機能はもう誰かが過去に必要としたもので、うまくすればプラグインが公開されているからそれを使えばいい。無ければ書いて公開すればいい。
ユーザコミュニティが開発者コミュニティの性質を帯び、多数の機能とユースケースが自己増殖的に補完され、それが更にユーザコミュニティの拡大を後押しする。そしてソフトウェアのコアは小さく綺麗に保たれたままだ。
ではこのやり方をとれば何もかも全てがうまくいくかというと、もちろん、そんなことはない。待つのは膨大な数に膨れあがったプラグインの混沌だ。
目的の実現のためにどのプラグインを使えばよいか分からず、どのプラグインがメンテナンスされているかもわからない。似たような機能のプラグインがいくつも併存し、あまつさえそれぞれ使いかたが異なる……。
これは要するに All-in-one の場合にソフトウェア開発者が負っていた責任を、あらゆるプラグイン開発者に分割しただけとも言える。そしてもしかして、全体的な品質で言えば、悪くなってすらいるかもしれない。中心の開発者たちなら維持できたであろうある一定の品質の保証は、こうした社会では期待できないからだ。
それでもこれは、悪いことではない。コミュニティに多くのアクティブな開発者を供給し、より小さい単位でプロダクトの沈降と新陳代謝を促す。より早くより小さい単位でかかるフィードバックと分散された責任は、ひとつのチームの巨大な責任とそのチームの失敗による巨大なカタストロフの脅威よりは、たぶん我々にとっては扱いやすい。
整備されたガイドライン vs 10年ROMってろ
あるソフトウェアの品質を担保しようとするとき、もちろんコントリビュートされてくるコードの質の高低は非常に重要だ。そしてその質をどうコントロールするかは難しい問題だと思う。
ソフトウェアの変更にはいくつかの種類のものがあるが、最も行いやすいのは、機能を足すことだ。特に似たような機能が既に存在し、それとはちょっとだけ異なる機能を足す、というケースだろう。Linux kernelに新しいデバイスドライバを足す、Dockerに新しいロギングドライバを足す。
しかしこういうケースであれ、コントリビュートされてくるコードの品質には大きな差がある。既に存在する似たような機能のものを参考にすればいいのに、びっくりするくらい独特なコードで書く人は割といる。リポジトリ内のコードを読めばなんとなく受け取れる思想のようなものを考慮だにしないかのようなパッチとか。
この問題に対抗する方法はいくつかあるが、ひとつは、よく整備されたガイドラインを作ることだ。コードスタイル、設計方針、実装方針および使用してよいAPIなどについて詳細なガイドラインを書き、それを強制する。違反するコントリビューションは受け付けない。これにより最低限のコードの品質は保たれる。
しかしこれは非常に大きな手間と長い時間を必要とする。時代の変化や設計の変更に追従するための労力もわずかとはとても言えないだろう。小さく美しいソフトウェアプロダクトには似つかわしくない。
いっぽうもうひとつの方法は、もっとよく周囲のコードを見てそれを真似しろ、というフィードバックを出すことだ。明文化を避け、しかし明らかに空気を読んでいないコードは明確に拒否する。「10年ROMってろ!」
かくして閉鎖的なコミュニティができあがる……。
独裁者 vs 委員会
何を受け入れるべきで何を受け入れるべきでないかの判断は非常に難しい。いくつかの超有名プロダクトには独裁者が君臨していて、受け入れるべきないものを明確に拒否する力を振るっている。LinuxにおけるLinus、PythonにおけるGuidoそしてRubyにおけるMatz。彼らのキャラクターは既に知られているから、言下に拒否するその姿勢は*3おおむね誰にでも受け入れられている。いいなあ。
そうでないコミュニティはApache Foundation傘下あたりに特に多く存在し、それぞれ委員会制とでも言うべき方向で集団での開発を進めている。よく使われているソフトウェアプロダクトにおいてはこれらはほぼ完全にいくつかの企業の勢力争いの場となっているように見える。
業界の巨人たる各企業がイチ押しの変更をゴリゴリ入れつつ境界面で押し引きする姿はそのソフトウェアのユーザとしては頼もしいものの、開発者として参考にできるものがあるかというと、無い。ざんねん。
開発者個人としての自分 vs プロダクトメンテナとしての自分
開発者個人としては、パッチひとつ送るにもあれこれと面倒な手続きを要求されるコミュニティはできるだけ敬遠したい。あれこれのものを使いつつ、できるだけ明快に使える小さく美しいソフトウェアと関わり生きていきたい。それができるだけのフットワークの軽さと、技術的視点でプロダクトの選択ができるだけのものを維持したい。
プロダクトメンテナとしては、ユーザがいる以上はきちんとメンテナンスをしたいし、また使用範囲が拡大すれば嬉しい。機能拡張の提案は真剣に受け取り、ソフトウェアの肥大化を招くかもしれないとしても受け入れることもあるだろう。そのプロダクトに技術的優位性があると思っている限りはどっしりと座りこんで開発を続けたい。
自分がメンテナをしているプロジェクトに自分でパッチを送れなくなる日が来ないようにする、という努力を続けたい、というはかない決意をするのが精一杯だなあ。
まとめ
結局どうするんだよ! というと、あらゆる2項対立のどの極端な点にもどうせ正解はないので、あれこれバランスの取りかたを試しながら、よさそうなやりかたを模索するしかないのだろう。
それでも一番大切なことがあるとすれば、こういったことを絶えず検討しなおすべきだということ、他の開発者とコミュニケーションをとることを絶対に拒絶すべきでないということ、くらいかもしれない。
YAPC::Asia Tokyo 2015 にいってきた＆しゃべってきた
毎年おなじみのYAPC::Asia Tokyo 2015が今年も行われたので参加した。いやー、たのしかった。
しゃべってきた
Talk proposalは出してあって、acceptされたというので話してきた。前夜祭。ビール飲みながら発表ができるぞ! ということで、内容はガチでコードの話というよりはもうちょっとだけふわっとした気分で、OSSをどう開発するか、それをどう継続して広げていくか、みたいな話。
枠は前夜祭……と思ったら、前夜祭のところにはRejectconと書いてあって、えっそうなの、みたいな感じ。まあいいけど*1。思ったよりだいぶ多くの方に聞いてもらえてよかったです。満席になって立ち見も出てた。
ウケるOSSの作り方、そしてコミュニティを盛り上げる方法！ YAPCモリストーク #yapcasia #yapcasiaD - Togetterまとめ
スライド以外に口でしゃべったこともあるし、質疑応答も非常に濃い状態になっていたと思うので、気になる人は動画を見てみてほしい。
あとでTLを遡ってみたところ、けっこう評判よかったようで安心した。していたら、こんな反応エントリも出てきた。うわお。
@t_wada さんや @hsbt さんとはカンファレンス期間中などにも(他の人も含めて)いろいろ話した。この話題は長くなるので、別エントリに分けて書く。
いってきた
毎年様々な人から聞く「YAPCの同窓会感がすごい」っていうやつ、これまでは色々な人と会えるしすごいなーと思う程度だったんだけど、今年行くと前職の同僚とかがいっぱいいて、あっこれ同窓会だ! ってなってた。
同時に今年は他言語なんかのコミュニティ・カンファレンスの知り合いも本当に多く来ていて、あらゆるところであらゆるところからの知り合いに会った。この何でもアリという感じはすごい……というか、あらゆるプログラミング言語・あらゆる問題意識の開発者が集まってきてやるカンファレンスはこれしかないのかもしれない。
会場がビッグサイトになったのもあってスペース全体の問題は去年に較べればはるかに改善されてた。ただトークによっては(というか結構な数のトークが)満員になっていて、満員だからもう入れない、というのもけっこうあった。話す側としては満員になってるとモチベーション高く話しやすいのは確かだけど。
ということで、いくつか特に気になるトークはちゃんと聞きつつ、あとは適当に会場内をふらふらして知り合いと話したりもしてた。わいわい。コーヒースペースが本当にすばらしかった。
今年でJPA主催という形で行われるこのイベントは最後(来年は無い)とのことなので残念ではあるが、どんなプログラマでも来られるカンファレンスというのがBeaconなのかな、という気がする。
まあなんだかんだいってYAPC::Asia TokyoはPerlという枠で収めず大きくなり続けていったので、それをいったんリセットして、誰でも来られるカンファレンスと、Perlに集中したもうすこし小さいカンファレンス*2に分ける、というのは悪くないアイデアだと思う。
何にしろ、いいヤップシーだった。主催者、スタッフ、スピーカー、参加者のみなさま、おつかれさまでした。またね!
JRubyConf.EU と Eurucamp に行ってきた
JRubyConf.EU 2015 のCFPにsubmitしたproposalが通ったのでポツダムに行ってきた。……のは7月末〜8月頭にかけてだったのでもう2週間以上経ってしまった。反省。
ポツダムはドイツ北東部、ベルリンのすぐ隣の街。人生で最も遠くへの旅になった。旅費はTreasure Dataに出してもらった。ありがたい。
すごくよくオーガナイズされたカンファレンスで、主催者にはあれこれ親切にしてもらって、滞在中は不便なことは皆無だった。ぐれーと。
話したスライドはこちら。JRubyをJavaなソフトウェアの上にプラグイン層を作るために使うと良いよ、という話。
JRubyConf.EU は Eurucamp という別のRubyコミュニティのカンファレンスのイベント内イベントという感じ。なのでJRubyConfには参加せずEurucampのみの参加という人もすごく多くて、スピーカーとしての立場が使えない英会話を行わざるをえなかった。なけなしの英会話力をふりしぼっている側にはけっこうきつい。今回は日本から行ったのは自分だけだったので、途中でコミュ力を使い果たしてカンファレンス最終日はほとんどくたばっていた。Eurucampはコードよりはかなりコミュニティ側に寄った内容のトークばかりだったというのも、まあ、あるかなあ。参加者の人に聞いたらこのカンファレンスが特徴的にそうらしいけど。
話した中ではやはり日本は遠い……ということでTDもFluentdもあまり知られていない。けど話すとそれはいいね! みたいにわかってはもらえる。もっと人の行き来が増えるといいなー、というか、もっと向こう行って話さないとな、というところ。遠いんだけどねえ。
LogStashの開発者と話せたりというあれこれはあった。日本に長いこと住んでいたドイツ人の人とか、日本の企業でリモートで働いているベルリン在住の人とかとも話せて、いやはや世界は広いのか狭いのか。貴重な経験だった。
ということで面白かったんだけど、次は10月にEuruko 2015がオーストリアのザルツブルグであって、こっちも通っているので、また話しに行くのでした。
Docker 1.8 に Fluentd logging driver が入りました
以前に書いた話の続きなんだけど、Docker 1.8が出た。
で、それに Fluentd logging driver が入っている。これで Docker container で起動したプロセスのSTDOUTやSTDERRを直接Fluentdに向けて投げることが可能になった。Dockerにpull-reqを送ったのは初めてだったんだけど、無事マージされてリリースまでこぎつけたので、本当に出たときはほっとした。途中だいぶ大変だったので……。
Collecting All Docker Logs with Fluentd | Treasure Data Blog
5 Use Cases Enabled by Docker 1.8’s Fluentd Logging Driver | Treasure Data Blog
Treasure Data blogで既にいくつかエントリが出てる。あと既に試したりしてる人もいるよう。すごい。
概要などについては以下のスライドがわかりやすい。
ということで、Dockerもだいぶ便利になりました! Enjoy Logging!
YAPC::Asia前夜祭でOSS開発者としての話をします
俺の考えるISUCON
ISUCONというイベントがある。要するに技術コンテストイベントだ。領域はWebアプリケーションにかかわる全てといってよい。
これがなんなのか、そろそろ一発説明しておくか、という気分にちょっとなったので書く。実は何を隠すこともなく次の出題者なのでいかに出題内容にひっかからないように書くかがちょっと大変かもしれないが、どうせ出題内容とかまだ確定しているわけでもないので、いいや。
ISUCONとは何か
ある日の朝、Webアプリケーションが一式、適当に設定されたサーバごと渡されます。あとベンチマークツールも渡されます。
さて夕方までにこのベンチマークツールの計測するスコアを可能な限り上げてください、そのためなら渡されたサーバ上で何をやっても構いません。ただしベンチマークツールはアプリケーションの動作が変わっていないかどうかチェックするための機構を備えているので、そいつが違反を検出したらスコアは無効です。
これだけです。もちろんコンテストなので詳細は当日朝にレギュレーション文章として渡されます*1が、想定外の事態を防ぎたいだけで、内容としては本当に上のものだけです。
世の中一般におけるWebアプリケーションというやつは通常、Webサーバ、アプリケーションサーバ、アプリケーションサーバ上で動作するプログラムコード、およびデータベースから成ります。データベースは多くの場合はRDBMSですが、まれにNoSQLオンリーという強烈な構成のものも世の中にはあります。あとキャッシュサーバを追加したりもしますね。
ISUCONにおけるWebアプリケーションもだいたいはこういうやつです。学生の頃には自分もRDBMSをさわったりはほとんどしなかったけど、お金を稼ぐためにRDBMSは非常に強力なソフトウェアなので、だいたい働きはじめると使うことになります。
ISUCONにおける「何をやってもいい」というのは本当に何でもよくて、別言語でスクラッチから実装し直そうがサーバソフトウェアの構成を完全に変えようがOSから入れ替えようが、何でもいいです。Webアプリケーションの動作さえ変えなければ。これはそれらしい用語ではブラックボックステストとか言ったりします。
これは要するに「あなたに全てをぶっこわす権利をあげます」ということです。それで勝てるもんなら勝ってください。それを見てみたい。
現代のISUCON
むかしむかし、ISUCONには一人で参加できました。現代のISUCONには一人では参加できません。必ず2人か3人でチームを組む必要があります。なぜか。
極めて簡単で、これは1人で勝てるものではない、ということがやってみて明らかになったからです。1人では絶対に勝てません。本当は2人でもつらくて、これまでの優勝チームは漏れなく3人チームですし、上位入賞チームもほとんどが3人です*2。
むかしむかし、ISUCONは先着申し込み順での決勝1日だけのイベントでした。現代のISUCONは予選をリモートで行い、通過者が会場に集まって決勝を行うことになっています。なぜか。
最初はこんなコンテストにこんなに参加者が集まるとは思っていなかったからです。が、今となっては70以上のチームが参加*3するイベントになりました。他に似たようなイベントがなかったのが目新しいからでしょうか。
一方会場に集まって決勝をやるスタイルはそのままです。これは単純に、そのほうが盛り上がるからです。イベント後に飲みながらお互い何をやったか話し合うのが、もう、めちゃくちゃに面白いからです。
むかしむかし、ISUCONのWebアプリケーション提供はPerl, Ruby, Node.jsのみで行われました。現代のISUCONではPerl, Ruby, PHP, Golang, Python, Java, Node.jsなどから、増えたり減ったりしつついくつも提供されています。
これは主催者が考えるに、スコアが出せるかどうかは言語の問題ではない、と思うからです。どの言語だろうと勝つ人は勝ちます。速い言語遅い言語で勝負がつくようなつまんない問題は過去一度も出されませんでした。
だがしかし、過去4回の優勝チームの使用言語は全てPerlでした。今年はどうかな?
ISUCONの技術
ISUCONでは様々な技術が必要とされます。もちろん、ごく基本的なWebアプリケーションを書く能力は真っ先に求められます。いわゆるWeb一般の知識、HTTPやHTML/Javascript/CSSなどの基本および応用的な知識も必要でしょう。
性能を出すためには各種ミドルウェアを適切に設定する必要もあります。Webサーバ、アプリケーションサーバ、データベース、Key-Value-Storage、OSなどは少なくとも一ヶ所ずつ手を入れることになるでしょう。
ISUCON出題者はナンセンスな設定を参加者に押し付けることはありません。最初からそこそこ動く設定はおそらく行われています。しかしスコアを出すためにはそこに安住できないのはもちろんのことです。
ISUCONで勝とうと思ったらアプリケーションの改造を恐れてはいけません。高パフォーマンスなアプリケーションを作るためには、適切なキャッシュの管理、RDBMSへのクエリの最適化と適切なインデックスの作成、データの持ちかたの変更、その他ありとあらゆる計算量・処理データ量の削減の努力が求められます。
それを最適な形で実現するために、アプリケーションコード以外のあらゆる部分の変更の可能性を検討すると同時に、アプリケーションコードの変更を組み合わせることを考えてください。
現代のISUCONはチーム戦です。厳しい制限時間の中で、2人が同じことをやっている余裕はありません。コミュニケーションをとり、お互いを信頼して作業を進めましょう。
そしてその結果をお互いにチェックしあいましょう。人間はミスをするものです。ミスを相互にカバーできるのがチームです。
ISUCONの勝敗
最終的に、勝敗はつきます。勝敗は大事です。勝つために参加しているのです。
しかし、最も大事なものは勝敗ではありません。決勝なら25以上のチーム、予選なら去年はなんと185ものチームが、同じ時間に、同じ問題に、同じ目的で、最大限集中して取り組んだということが一番大事なことです。
普段我々が手にできない、全く同じ前提条件でのフラットな技術的な議論ができる場が、そこにできるのです。
その意味では、ISUCON参加前と参加後に最も多くのものを持ち帰った人こそが勝者と言えるでしょう。
まとめ
ISUCONは超面白いので、今年のもたぶん面白くなると思うので、みんな参加したらいいと思う。
とはいえ、普段Webサービスを開発している人にとっては普段の仕事領域だけど、学生の人達にはRDBMSなんか触ったこともない、という人もいると思う。まあ機会なけりゃそんなもんだよね。しかしRDBMSを使ってみたという経験がこの後に無駄になることは100%ありえないので、ぜひこの機会にやってみてほしい。
ということで機会があります。学生の方はいかがでしょうか。isucon.net
さー今年のISUCONの問題はどうしよっかなー!
