RubyKaigi2008 2nd day Photoレポート［随時更新］

本日（6月22日）行われている、RubyKaigi2008 2nd dayのPhotoレポートです。随時、更新予定です。本日もメインセッションを中心にお届けします。

各セッションの模様は、角田さんにレポートしていただきました（角田さんのスケジュールの都合上、大場さん・高井さんのセッションまでのレポートになります⁠）⁠。

2日目のセッションは朝9時という早い時刻から始まりましたが、大ホールには多くの人が集まっていました。

拡張ライブラリの書き方講座（artonさん）

2日目の最初のセッションは、田島あきお（arton）さんの「拡張ライブラリの書き方講座」です。

まずは1999年に発売された『オブジェクト指向スクリプト言語Ruby』（⁠アスキー）から引用し、拡張ライブラリの定義を確認しました。

CまたはC++言語で記述されていて、Rubyに組み込むことのできるライブラリ
重い処理の本質的な部分を任せる
コンパイラ型言語によるプログラムと大差ない実行速度と比較にならない開発効率を両立させることも可能

1から10までの数字を出力する処理を、Rubyのコードと、Ruby APIを使ったCのコードで示し、Cで書かれたコードが余計な処理が入らずいかに速いか、またCで書いても余り速度に大差がない箇所もあることを説明しました。

次に、拡張ライブラリを書くにあたっての情報源として、1995年以降全く更新されていないREADMEや書籍、関連ヘッダファイル、技術などを紹介しました。

そして拡張ライブラリの配布方法を説明した後に、拡張ライブラリの雛形を生成する「extrails」という自作ライブラリのデモを行いました。デモ中、typoにより上手くデモが出来ずに悩んでいる間、後ろのスクリーンに移っているIRCログでtypoの指摘と「うしろうしろー!」といった発言が流れたことは、非常に一体感がある場面でした。

さらに、テキストやネットワーク処理、ファイル操作などはRubyが得意とする処理なのでRubyに任せ、アドレス操作、割り込み処理、ネイティブAPIなどが拡張ライブラリに適していると主張しました。その後、拡張ライブラリの本質にそって作った「HeapShow」という自作ライブラリを使って、メモリのヒープ領域の利用状況を視覚化するデモを行ったところでセッションの持ち時間が終了してしまいました。

このセッションの模様の一部です。

ニコニコ動画：https://www.nicovideo.jp/watch/sm3730488

さらに仕事に使うRuby（後藤謙太郎(ごとけん)さん）

このセッションでは、発表者の後藤謙太郎（ごとけん）さんが仕事で使っている以下のRubyツールを、それぞれの特徴や利点ともに紹介しました。

Hiki：お客様との連絡用のツール
Redmine：案件の管理用のツール
影舞：伝票管理のツール

Hikiは、お客様と同じ情報を見ることができIssue Trackingのプラグインが使えることが導入のきっかけになっています。また画面構成をカスタマイズしたりプロジェクト毎に新しいHikiを作成できるよう自動化に取り組んでいるようです。

RedmineはTracと比較して機能の充実さや分かりやすいUI、Railsで書かれたコードが手本になる、などの理由で採用しました。また日本語ファイル名の添付ファイルの扱いでトラブルがあった体験を話しました。

古くからずっと利用している影舞は、カラムソート機能やよく使うリンクなどのカスタマイズをしていることを紹介しました。

そして、グループウェアや社内掲示板など、社内にあるRSS出力に対応していないアプリケーションのフィード管理にmechanize、hpricot、fastladderを利用しているようです。

質問の「Issue Tracking機能がどれもカブっている」には、「⁠お客さんに見せたくないチケットなどがあるため現状はシステムを分けている」と答えていました。

erbを偲んで（関将俊さん）

dRubyやERBの開発者、関将俊さんの発表です。毎度おなじみ「初版まだ買えます」と、自著『dRubyによる分散・Webプログラミング』（⁠オーム社）の紹介から始まりました。Pragmatic Programmers（達人プログラマー⁠）⁠ シリーズより英語バージョンの発売も予定しているようです。

セッションでは主に2007年に行われたオブジェクト倶楽部のライトニングトークでの発表を元に、「⁠MVCのVはテンプレートのことではなくView Objectだ」ということを説明しました。

最後に、ERBがstrscanが無い環境でのテストが抜けていて1.8.7で動作しなかったことの事情について、ERBのパフォーマンスチューニングの試行内容を解説しました。

「erbを偲んで」スライド

matzを説得する方法（田中哲さん）

産業技術総合研究所の田中哲さんの発表では、Rubyのこれまでの開発において、取り込まれた提案と受け入れられなかった提案を検証し、どうアプローチすればまつもとさん（matz）に受け入れてもらえるか、について話しました。

当然のことながらバグレポートは通りやすいですが、その際に再現可能な報告やコード、実行例などを示す必要があります。

それ対して、新機能や機能変更はなかなか通らないことが多く、「⁠途中省略されて表示されるスタックトレースを全部表示させたい」という過去にあった提案を例に話を進めて行きます。ちなみにその提案をやり取りした内容はruby-devのメーリングリストで見ることができます。

この提案は2002年から行われており、9回目となった2007年に田中さんによってやっと受け入れられました。そしてそれまでの提案を検証したところ、「⁠設定という概念の導入」「⁠話が大きすぎる」「⁠悪影響が出る可能性が高い」という理由により受け入れられませんでした。これにより受け入れられにくい提案というのは、以下の問題を抱えていると指摘しました。

必要性が納得出来ない
なにが問題なのかわからない
本人以外が困っているのか疑わしい
解決策が疑わしい

逆に受け入れられやすい提案は、以下の傾向があることを指摘しました。

必要性が納得出来る
解決策が妥当で副作用が少ない
Perlが採用している（matzはPerlが好き）

また、受け入れられる要素として「一貫性」はあまり当てはまらず「多態性」を重視して便利さを重要視した方がよいようです。

そして、名前は非常に重要らしく、機能は問題ないのに名前が決まらないだけが理由で受け入れられないことが、たくさんあったことを例を挙げて紹介しました。

最後に、最近の提案をとりあげました。提案内容は「Time#strftimeに小数点以下を取り出したい」というものです。田中さんの指摘通り、現在この提案は進んでいないようです。

この提案の問題として「どういう用途で欲しいのか書いてない」と挙げ、実際に提案者に聞いたところ、「⁠誰か他の人が欲しいって言ってた」という回答だったようで、この提案が通ることは難しいといえると話しました。そして、GNU DateやJava、C#が%Nを使って表せることを調べて、まずは「%Nが適切な用途を見つける」ことが提案採用に近づく道なのではないか、と述べました。

日本Rubyのリファレンスマニュアル2008・初夏（青木峰郎さん）

Rubyのリファレンスマニュアルを刷新作業を行っている、青木峰郎さんの発表です。2006年8月から新リファレンスマニュアルを作成を開始しており、最新の状況は「Rubyリファレンスマニュアル刷新計画」のサイトで参照できます。

今年の5月にsnapshotをリリースしましたが、今月にもupdateした内容をリリースしたいと発言していました。進捗状況として昨年のカバー率が2％だったのに対して、現在は31.2％にまで上がっています。規模が大きいtkとsoapを除けば52％にまで上がり、組み込みライブラリに関してはほぼ100％カバーしているそうです。

続いて、プロジェクトの概要について説明しました。まずはコミット数ランキングを表示し、sheepmanさんがダントツの多さでした。管理システムにはRedmineを利用しており周辺システムの改善を行っているようです。

今後の予定として、1.8.7対応を6月中に行い、組み込みライブラリを100％にし、来年のRuby会議までにはtkとsoapを除いて100%を目指しているようです。Ruby言語仕様やC APIリファレンスに関しては現状誰も行う予定はなく、言語仕様に関しては水面下で交渉を行っている段階のようです。質問された英語バージョンとの整合性についても、今のところは特に考えておらず、別々に進めればいいのではないか、という考えを示していました。

The future of Ruby in Mac OS X（Laurent Sansonettiさん）

現在、RubyCocoaのメンテナンスを行っており、Appleに勤めるLaurent氏による発表です。

Mac OS X 10.2より標準でインストールされたRuby（当時のバージョンは1.6.7）は、最新の10.5でrubygemsやrailsが入り、DTraceをサポートするなど着実に環境が良くなっています。

次に、RubyCocoaの概要と歴史を説明し、Objective-Cで実装された既存のフレームワークを使用してプロトタイピング用途で手早く楽しくプログラミングできる良さをアピールしました。RubyCocoaで作られたアプリケーションであるブログエディタ「Blogo」とIRCクライアント「LimeChat」を紹介し、RubyCocoaの親であるhisa（藤本尚邦）さんとLimeChatの中川智史さんがそれぞれスピーチを行いました。

hisaさんがRubyCocoaを作ったきっかけとして、2001年にMac OS Xが登場した当時は仕事がなく、暇になったため、RubyとNeXTSTEPが好きだったhisaさんは、Objective-Cで作られたオブジェクトをirb経由でアクセスしようと思い開発を行いました。元々RubyでCocoaアプリを作りたかったわけではなく、成りゆきでそうなってしまったそうです。

次に中川さんは、IRCクライアントをなぜRubyCocoaで作ったのかについて語り、ハマる原因が多くなるブリッジを用いた仕組みでは作りたくなかったけれども、RubyやObjective-CにはどちらもSmalltalkの思想が含まれていて、RubyCocoaで開発しても特に困ることがなく楽に実装できたからだ、とRubyCocoaの良さを語りました。

Laurent氏のセッションに戻り、Xcodeを使ってRubyCocoaを使った簡単なアプリケーションを作成するデモを行い、RubyCocoaがどのように動いているのかについて図を用いて説明しました。そして、RubyCocoaが抱える問題点として、以下の項目を挙げました。

ブリッジ機構にて、クラスとオブジェクトモデルの管理が必要になり、パフォーマンスがネックである
RubyとObjective-Cの分法において、引数の与え方やメッセージ送信の構文が全く異なる
Rubyはスレッドセーフでないので、Objective-Cのスレッドコードを使えない

上記の問題を解決し、「⁠Rubyを使う楽しみのためにパフォーマンスを犠牲にすることなく、成熟したMac OS Xアプリケーションの作成を可能にする」こと目指して「MacRuby」が誕生しました。

MacRubyの概要とどのように動くかについて説明した後、MacRuby版のirbである「macirb」を用いてデモを行いました。「⁠puts "arigato".transform("Latin-Hiragana")」というコードを実行すると「ありがとう」と結果が出力され、Ruby 1.9ベースで動いていることを示しました。また100行に満たないコードで作られたGUIの画像ブラウザ（おそらくsampleに含まれているPhotocastViewer）を披露し、会場の関心を集めました。

最後に、MacRubyの今後のロードマップを示しました。現在のバージョン0.2はCore Foundationベースの実装を完了しておりXcodeのサポートも行っています。0.3ではRubyCocoaの互換性やHotCocoaの導入、全テストケースのパス、Railsを動かすことを目標としているようです。

そして、0.3より導入予定のHotRubyについて説明しました。CocoaアプリをもっとRubyらしく書けるようにするライブラリで、なんと「昨日の夜」に320行ほどのコードで作ったそうです。HotCocoaで作ったサンプルコードは以下のような感じになります（モニタ上のコードを写経したので間違っているおそれがあります⁠）⁠。

require 'hotcocoa'
include Hotcocoa
app do
  window :title => "Hello World", :frame => [0, 0, 120, 120] do |win|
    b = button :title => "click me"
    win << b
    b.on action do
      puts "ouch"
    end
  end
end

また、0.3以降もAppleScriptの代わりとして使えるようAppleEvent APIのサポートやパフォーマンスの向上を目指しているようです。

会場は大きな関心に包まれ、数多くの質問が行われました。たとえば、iPhoneはGCをサポートしていないため、今のところMacRubyが入る予定はないそうです。

MacRubyの開発はフルタイムで行っているわけではないことや、MacRubyの開発を日本に来てからもガリガリ行っていること（一昨日も開発していたそうです⁠）⁠、1.9とのマージを2週間おきにやっていること、string.cに見られる気が遠くなりそうなObjective-Cへの変換作業など、Laurent氏の「超人ぶり」が会場に伝わったセッションでした。

REST信者から見たRuby on Rails 2.0（山本陽平さん）

数々のブログ記事や『RESTful Webサービス』（⁠オライリー）の監訳者として知られるXML guyでありRESTianである山本陽平さんによる発表です。RESTとRuby、Railsは仲が良いというテーマで話を展開しました。

Ruby界ではruby-devメーリングリストの2002年の投稿から「REST」という言葉が登場しており、Rubyはこの段階ですでにRESTを意識していたと、RESTとRubyは仲が良いことを示しました。ちなみにこの内容はruby-devのメーリングリストで参照できます。

また、Rails ConfでRESTの提唱者であるRoy Fielding氏が講演を行っていることや、『⁠RESTful Webサービス』の著者と『Agile Web Development With Rails』（⁠Pragmatic Bookshelf⁠）⁠、『⁠Rubyクックブック』（⁠オライリー）の著者が同じであること、『⁠RESTful Webサービス』の原著表紙にDHHの名前が書かれていることなどを挙げました。海外では書籍表紙に「Ruby」の文字が入っていると（Sam Ruby氏のように著者の名前でも可⁠）⁠、バカ売れするそうです。

そしてRESTの概要説明を行い、ROA（リソース指向アーキテクチャ）の以下の4つの構成要素のうち、（⁠山本さんが思う）重要な2つ「アドレス可能性」「⁠接続性」について、Railsとの関連性も絡めて深く掘り下げて話しました。

アドレス可能性
ステートレス性
接続性
統一インターフェース

「アドレス可能性」について、『⁠RESTful Webサービス』に記載された難解な定義を引用し、アドレス可能性を実現するためにURIを設計してからURIを実装する「リソース/URI 駆動開発」を提案しました。そして、Railsの実装であるmap.resourcesを挙げて「URIは設計目標であって実装結果ではない」という観点から、「⁠シンプルだけど、コードの構造に依存しがち」である点を指摘しました。山本さんはRestletやDjangoの実装が気に入っているようです。

続いて、「⁠接続性」について論文から定義を引用し、ハイパーメディアを設計するにはリソースとリンクを設計すればよいと説明しました。リンクの設計には、Web開発によく使われるWeb遷移図を使えばよいそうです。リンクの実装について、Railsのurl_forやlink_toをとりあげ「シンプルだけど、リンクの意味を意識出来ればもっといい」との指摘を行いました。接続性についての詳細は、WEB+DB PRESS Vol.45で丁寧に解説されています。

「上手く設計する際のコツは？」という質問には「全部リソースで考える⁠」⁠、「⁠確認画面のようなリソースと言えないものはRESTfulでありえるのか？」という現実的な質問には「例えば、mixiの日記確認画面は本当にサーバサイドでやらないといけないのか？」と、理想と現実のギャップを感じさせる回答をしていたのが印象的でした。

Real-World Enterprise Ruby (大場光一郎さん・高井直人さん)

書籍や雑誌記事などを多く書いている大場光一郎と高井直人さんの発表です。2人ともセッションのテーマを意識してかスーツで登場しました。しかしセッションが進んで行くうちに、2人のやりとりを見ていると漫才コンビのようにも思えてきました。ちなみに質問コーナーでの回答は「どちらもボケ」だそうです。

セッションの内容は、2人が勤める会社も属する「ITサービスプロバイダ」と呼ばれる企業がRubyを導入するにはどうすればよいか、という話でした。

まず、エンタープライズ、エンタープライズアーキテクチャの定義を説明し、エンタープライズRubyを実現するには、まず自社でRubyを位置づけることが大切だ、と主張しました。また、Rubyを上司に説得する際には「開発者が楽しい」「⁠生産性が高い」などの理由は通用せず、新規顧客や新規案件の獲得に使えることをアピールするとよい、と述べ「From Java to Ruby」ではなく「Java and Ruby」というアプローチをすすめていました。

そして、Rubyを導入した後に推進していく体制を作っていく方法についてQ＆A形式で説明しました。営業向け資料や開発環境の導入手順書を用意したり、ファンクションポイント法での事前見積もりと実際のデータを次の見積もりに役立てたり、トレーニングや定期的なコードレビューを実施したりなど地道な活動が重要なようです。上司説得の武器として、役員クラスの後援者を見つけることが大事だと、経験にもとづくポイントを披露していました。

質問コーナーでは、同じ業界に属する人からの質問が多く、以下のような現場に沿った内容で占められました。