RubyKaigi2008 2nd Day
最終日であるところの二日目。大ホールに流れる電波な歌も、今日で聞き納めかと思うと寂しい。
拡張ライブラリの書き方講座
Rubyにつっこむ拡張ライブラリの書き方についてのセッション。
Rubyの拡張ライブラリについての情報は少ないらしく、Matz氏の『オブジェクト指向スクリプト言語Ruby』*1とWebにあるいくつかの情報、およびRubyの実装理解の手助けとしてRHGこと『Rubyソースコード完全解説』ぐらいしか無いという。従って、一時情報であるRubyのソースコードを読むことは大前提。
また、拡張ライブラリはスピードアップ目的で実装されることもあるが、単にCで書けば速くなる、というものでもない。例えば、ブロックを使うコードはスコープを扱うための前処理が入るので、そこをCにして削ってしまえば速くなる。しかし、そうした前処理が入らないfor文を単にネイティブコード呼び出しに変えても速くはならない。本質を外してはいけない。
スピードに限らず、拡張ライブラリを使うときはその特徴を生かすことを考える。Rubyが得意な文字列操作などを拡張ライブラリにしても仕方がない。
あとは、実際に拡張ライブラリをつかってのデモがあった。しかし、時間が足りなくて最後までいかず、「おもしろいところ」はお預けになった。
さらに仕事につかうRuby
スライドはこちらで公開されている。
Webデザイン系の会社でRubyを使っているよ、という事例の紹介。
顧客との連絡や案件の管理に、Rubyベースの環境を導入し、自分でいろいろカスタマイズして使っているそうだ。
- 顧客との連絡や進捗報告はHiki
- 案件管理にRedmine
- 伝票管理に影舞
- RSSフィードリーダとしてFastladder
- Fastladderは自分の環境にインストールできるのがよい。社外のサービス利用だと難しい、社内の情報も扱える。
- RSSフィードを作らないサービスについては、Rubyでスクレイピングしてフィードを作る。
Fastladderはいいね！ちょうどそういうのを探しているところだった。
複数種類のBTSが混在している点については、次の二つの理由があるそうだ。
- 権限管理。この情報はあの人たちだけに、でもあの情報はこの会社の人たちだけに、といったアクセス制御を
erbを偲んで
タイトルはハッタリで、ちっとも偲んでいないらしい。スライドはこちらで公開されている。
とりあえず、もっとも重要な「dRuby本の初版、まだ買えるよ！」という宣伝からスタート。後はMVCのViewについての意見を展開。
いまではViewにテンプレートを使うのが一般的で、それを「分業のため」だと言う。しかし、それは違う。単に「そうしたほうがプログラマが書きやすい」というのがテンプレート登場の背景であり、分業なんて考えてなかった。だから、協業すれば？
それに、ViewというのはつまるところView Objectであり、実行環境とテンプレートがセットになって初めて意味をなすもの。HTMLとCSSの関係みたいなもの。完全に分離ってわけにはいかない。
最後に、言いにくいこと。つまり、Ruby 1.8.7でのerb実装ミス。なんか、erbを高速化する実装に取り組んでいたものの、間もなく飽きてしまい、プロファイリングの前提を操作して（つっこむデータを速度が出やすいものにする）パフォーマンス向上率を見た目上げてみる、みたいなしょーもない遊びにふけっていたそうだ（笑）。そんなことをしていたら、すっかりstrscanが無い環境でのテストを忘れていたらしい。
Matzを説得する方法
Rubyに気に入らないところがあって何か変更したい場合、まずはMatz氏を説得しなければならない。ということで、Matz氏を説得するためのガイドラインについてのセッション。
Rubyで大きな変更といえばYARV(Ruby1.9のVM)の導入だが、これについては"スピードアップ"というわかりやすい理由がある。また、バグレポートも明らかに障害が起きていることを示せればよいわけで、受け入れられやすい。
しかし、新機能の追加となると簡単にはいかない。その機能が本当に必要なのか、代替手段ではだめなのか、などなどいろいろな考え方ができるからだ。
例としてスタックトレースが省略されないようにする変更が挙げられた。この提案は2002年から始まり、2007年にようやく追加されたという。
そういうわけで、なんとかMatz氏を納得させて提案を通すためにはどういうところに気をつけるべきなのか、というコツが披露された。ただ、ここで説明された方法は、一般的な企業で顧客や上司に提案するときに気をつけることと変わりないと思う。導入理由をはっきりさせるとか、明確で説得力のある事例を示す、余所ではどうやっているか調査しておく、大きすぎるリスクを取らせない、などなど。
Matz氏に特化した話としては、彼はPerlが大好きなので、「Perlではこうやっている」という話の持って行きかたをすると、通りやすいらしい？あと、Rubyでは一貫性よりも便利さを尊重している点に気をつけるべし、というところかな。
日本Rubyのリファレンスマニュアル2008・初夏
Rubyのリファレンスマニュアルを作り直すプロジェクトの現状とこれからについてのセッション。
あたらしいリファレンスマニュアルはこちら(1.8.6)。
このプロジェクトは2006年にスタートしている。目標は、メタデータを取りやすいフォーマットにすること、そしてより完全なドキュメントにすることだ。
現状のリファレンスのメソッドカバー率は次のようになっているそうだ。
今後は組み込みライブラリのカバー率を100%にすること、そしてRuby1.8.7のドキュメントをリリースすることを計画しているという。また、ライセンスがいいかげんなので、これはCCの「表示、継承」に。他にはシステムとしての改善に、Ruby言語使用の作成と、やること盛りだくさん。
RubyとMac OS Xの未来
これはすごいセッションだった。Mac OS XのRuby開発サポートはすごいね。
現在、Mac OS Xでの開発をRubyで行いたい場合は、RubyCocoaを使用する。これは藤本氏が制作したRuby-Cocoaブリッジで、Rubyを使ってObjective-Cのライブラリを使ったプログラミングができる。これを使ったアプリケーションはLimeChat等すでにいくつも存在しており、評判もよい。
また、RubyCocoaはMac OS Xに正式に組み込まれている。LeopardからRubyも標準添付されているから、いつでもだれでもRubyで開発できるわけだ。しかも、Xcodeの充実したサポートを受けながら。デモでは、Interface Builderをつかって簡単なダイアログを実装していた。
ただ、やはり型変換や例外変換などのオーバーヘッドが入ってしまうし、メモリ管理やスレッド関係についてもいくつか問題もあるという。
そこで、これらの問題を解決するためにAppleで開発を進めている新しいRuby処理系がMacRubyだ。こいつ、RubyCocoaとは異なりObjective-Cのオブジェクトを直接使うことが可能なのだという。
実際、デモで'foo'.classを表示させていたが、StringではなくNSCFStringと表示されていた。さらに、NSCFStringのメソッドは全て使えるという。これはすごい。他にも、オーバーヘッドが入らない分高速だし、世代別GCなども利用可能、スレッドもいけるといたれりつくせり。
ただ、これはObjective-CのスタイルをRubyにある程度持ち込んでしまうことになる。そこで、RubyらしくObjective-Cライブラリを使えるようにするためのインタフェースHotCocoa.rbを開発しているという。開発がスタートしたのは、昨日（！）。しかし、デモをできるところまで作ってあって、確かにブロックなどを利用したRubyらしいコードになっていた。
いやぁ、とてつもなく楽しみだな、MacRuby。
REST信者から見たRuby on Rails 2.x
タイトルこそこうなっているが、発表者の山本陽平氏はRESTafarianではあるがRubyistでは無いので、Railsはよく知らないという。そんなわけで、本セッションのタイトルは『REST信者から見たRuby and Rails』に変更された。
そんなわけで、RubyとRailsというよりは、あくまでRESTの話であった。
RESTfulである条件の一つに、ROA（リソース指向アーキテクチャ）というものがある。これはさらに４つの要素から構成される。
- アドレス可能性
- ステートレス性
- 接続性
- 統一インタフェース
これらの全てを守らないとRESTfulじゃないってわけでもないし、これらの要素がすべて同じ重みなのでもないという。山本氏の個人的な見解で重み付けすると、次のような順序になる。
アドレス可能性 > 接続性 > 統一インタフェース >>>>>>>> ステートレス性
重要度が高い２つに注目。
アドレス可能性を持たせようと思うと、リソース/URI駆動開発とでもいうべきスタイルになると考えられる。つまり、先にURI設計をして、後に実装するのだ。一般的には実装したらこんなURIになりました、というスタイルが多いが、これを逆にすべし。Railsはこのあたりの実装を実にシンプルにできるが、コードの構造に依存しがちなところがいまひとつであるという。山本氏としては、競合実装であるRestletの方法が気に入っているそうだ。
接続性を持たせようと思うと、ハイパーメディアとリンクの設計が重要になる。Railsはリンク作成の支援機能が充実していて、実にシンプルに実装できる。ただ、リンクの意味を理解できたらもっといい、という。例えば、link relを使ってどういう意味のリンクなのかを明記するのだ。そうすれば、プログラムが勝手に解釈できるようになる。このへんの詳しい話は、もうすぐ発売する『WEB+DB PRESS Vol.45』の連載記事に詳しく書いてあるとか。会場で先行発売していたので、購入して読んでみたが、まさしく。
しかし、実際のところRailsはRESTfulであると言ってよさそうである。これからRESTな設計をしようと思う人は、まずはアドレス可能性と接続性に注目すること。
ついでに、『RESTful Webサービス』の裏話。最初、タイトルを『RESTful Web Service with Ruby』とする案もあったそうだ。というのも、アメリカではRubyとつければ本が売れる傾向があるのだという。しかし、著者の一人Sam Rubyの名前にRubyってあるからいいや、ということで今の名前に落ち着いたらしい。また、アメリカ版は、表紙に「序文をDHHが書いてるよ」と明記してあるらしく、これのおかげでバカ売れしたらしい。Ruby人気、Rails人気は本物だ。
Real-World Enterprise Ruby
CTCの漫才コンビ（違）によるセッション。エンタープライズ分野に実際にRubyを持ち込んだときの経験について話してくれた。
Rubyをつかうことを経営層に提案する際、我々を引きつけてやまない「開発者が楽しい」「生産性が高い」という言葉は経営層にはぜんぜん届かないという。そうではなく、「新規顧客、新規案件の獲得」といったところから攻めるのが良いとのこと。関心の向き先も違えば、使う言葉も違うわけだ。
実際にRuby開発がスタートしても、教育はどうするか、見積もりはどうやるか、開発実績を問われたらどうするか、などなどあらゆる問題が発生する。だが、それらは研修の計画、Java同様の見積もり算出を行う、開発者を武者修行に出して実績を積ませるなどして愚直に一つ一つつぶしていくしかない。Rubyをエンタープライズ分野に導入するためにはこうした地道な努力、想像ではなくデータを出すこと、そしてきちんとビジネスと向き合うことが大事なのだそうだ。
Developing and Scaling iKnow
英語学習SNSとして有名なiKnowはRuby on Railsで実装されている。これをどのように開発し、スケールさせているのかという話。
ペースが速くて細かい数値を追えなかったが、iKnowのような人気サービスであってもRuby on Railsは十分に使えているという。このへんの詳しい話は、もうすぐ発売する『WEB+DB PRESS Vol.45』の記事に…って、また出てきたよ。まぁなんだ、みんな発売したら買ったらいいよ。今確かめてみたけど、スライドの内容がほぼそのまま載ってる。
雑誌に載っていない話としては、ActiveRecordのcount, size, lengthはなんか同じように見えるけどやってることはいろいろ違うんだよ、というものがあった。基本的にlengthよりsizeを使うようにした方が幸せになれるそうだ。というか、lengthを使って痛い目を見たそうで。
あと、１ユーザにつき１ディレクトリ作る、といった方法をとると、ファイルシステムによってはユーザ数が膨れあがったときに検索がめちゃくちゃに遅くなったりするらしいので注意、とか。
Inside Tabelog's Background
口コミグルメサイト『食べログ.com』もRuby on Rails実装で、高負荷と戦っているという。
元々Windows+ASPで実装してあったサービスを、Ruby on Railsに置換して今に至る。rails100で9位につけるほどのトラフィックを捌いているという。
Mongrelのクラスタとmemcashed、そしてDBの負荷分散により膨大なトラフィックに対処しているということで、各要素で起きたトラブルとその対処法についての説明があった。例えば、ActiveRecordは単一のDBを相手にするよう作られているので、分散DBの扱いが難しい。複数DBを扱うためのプラグインは２つほどあり、その一方を採用して対処している。ただ、そちらもフェイルオーバーできない等、決定打に欠けるところがあるようだ。
全体的にふつーのことをしているだけで*3、Ruby on Railsでやっていけるという。遅いのはDBなのだそうだ。
ガラパゴスに線路を敷こう: 携帯電話用RailsプラグインJpmobile
資料はこちら。
こいつはすごい！何がスゴイって、日本の携帯電話のフリーダムっぷりと、それにかっこよく対処してみせるjpmobile、そしてそれを開発した発表者であるdara氏の技術力と忍耐力が、だ。
俺は携帯電話を対象にした開発経験がほとんど無いのでよく知らなかったが、日本の携帯電話はキャリアによって仕様がバラバラらしい。ほんとに、なんでもかんでもバラバラ。Webブラウザの互換性問題なんて、こいつらに比べたら些細なもんだ。
しかし、Ruby on RailsのプラグインJpmobileはこの混沌とした世界をスマートに集約する。
スープカレーが大好きなdara氏が、どこにいても最寄りのスープカレー店を検索するサービスを作った際のノウハウを抜き出してJpmobileが作られたという。
これを使うと、キャリアごとに、または同じキャリアでもバージョンごとに異なる仕様を全て吸収し、欲しい情報を単一のメソッドで取得できるようになる。これ使うようになったら、もうこれ無しではケータイサイト開発なんてやってられなくなるのでは。
Jpmodileのお世話になっている人は多いらしく、質疑応答時間も「うちでも使わせてもらってます！ありがとう！」という質問ではないお礼コメントが出てくるほど。
Using Ruby to Build a Scalable Startup
クリエイターとiTMS, AmazonMP3の間を仲介するサービス（？）であるTuneCoreというサービスがやはりRubyを使って作成されているそうで、その事例についてのセッション。
フロントエンドにはRuby on Rails、配布エンジンにMerb（やはりRuby製のフレームワーク）、そしてバックエンドはRuby（not Rails）という構成。
特にRubyの使い方としておもしろいところは無かったように思えるが、システム構成はおもしろいと思った。メディアの配布エンジンをAmazon EC2上のXen（仮想マシン）で動かし、ストレージにはAmazon S3を使用しているそうだ。EC2とS3の間でデータ転送する分は無料なのだそうで、都合がよいのだ。
Rails症候群の研究
Ruby on Railsが普及して以来、どうもRubyを誤解している人が出てきているようである。こうした人々を"Rails症候群"と呼び、研究してみたというもの。
よくある症例は、次のようなもの。
- やたらprotected
- Javaのprotectedとは違いますからー。普通はprivateにしておけばOK。
- やたら既存クラスを再定義
- そんな怖いことしなくても対処できますからー。
- Rubyがなにかわかっていない
- 「Rubyって、Railsが無くても動くのかい？」
他にも、文字列とシンボルの区別がついていない、メソッド名の!の使い方が変、やたらブロックを使いたがる、などなど。ははは、どれもよく聞く話だな。
ただ、これはRailsのせいというより、Rubyのせいなのかもしれないという。
privateとprotectedは正直わかりづらい。OpenClassは確かに強力だが、ちと強力すぎる。そして、Rubyって何？と言われても明確な言語仕様が無いうえに処理系が増えている現状では、なにをRubyと定めたものかわからない。
そのため、Rubyとしても対処しなきゃね、ということで、Selector namespaceというアイデアもあれば、Rubyの言語仕様をドキュメントとして、あるいはRubySpecとして作成するつもりであるという。しかし、一番驚いたのは、OpenClassの廃止という案と、Matz氏が検討しているらしいという話。まじですか！？会場でも驚きの声、そして反対する意見が多数。いや、それはさすがにねぇ。
Closing
これにてRubyKaigi2008は終了。次回の"RubyKaigi2009"の開催は決まっており、計画は次のようになっている。
- 日時
- 2009年のいつか
- 場所
- 日本のどこか
…ばっちりですな！
次回の目標は、まずは多言語対応。RubyKaigiにも海外の方が多く参加するようになってきたので、充実させていきたいとのこと。また、"地域Ruby会議（仮）"というものを計画しているそうだ。年に一回だけ東京近辺で大規模に行う本家RubyKaigiだけでなく、全国各地でもっと小規模なRubyKaigiを頻繁に行ってもいいのでは、という考え。
RejectKaigi & RejectRejectKaigi & RubyKaigi2008撤収作業
本家RubyKaigiは終了したが、番外編が残っている。
RejectKaigiは、RubyKaigiのライトニングトークスに応募したものの残念ながら不採用になった（Rejectされた）人々のために、あとやっぱりなんか物申したいという人々のために用意される発表の場である。昨年実施され、好評だったのか今年もやることに。
それどころか、RejectKaigiでもRejectされた人々のためのRejectRejectKaigiまで実施、両者は同じ会場で平行してプレゼンテーションされることになった。
RejectKaigiはすでに不採用になった発表を扱うので、そのはっちゃけぶりというか、ヤケクソ具合がすばらしく、そこがまたおもしろい。RejectRejectKaigiともなれば、もうカオスとしか表現しようが…。
いやあ、おもしろかったよ！合計30のプレゼンテーションが２カ所平行で走るということで、さすがにメモを取る余裕が無くてレポートは書けない。うろ覚えながら頑張ってキーワードを出してみると…。
- RubyKaigi私物化
- やるおで学ぶJRuby
- Decimalの歌
- NDD = NicoNico Driven Development = ニコニコ駆動開発
- AutoPagerizeを作った人の、Identiconライブラリ
- String#succは高度（注：PDF）
とってもフリーダム。
最後に角谷氏のキーノートで締め。すでにスライドが公開されているが、内容はClosingでも出た地域Ruby会議のこと。Ruby Asociationも巻き込んで、みんなでやろうぜ！
