書いた人: tanabe sunao
8/21 に、初めての Regional Ruby Kaigi である、 東京 Ruby 会議 01 が開催されました。 比較的急な案内と締切、平日の開催などの条件にも関わらず、定員を越える参加応募が集まりました。 当日の参加者も雷雨の中最後のセッションでは 84 人を数えるなど、 Regional Ruby Kaigi への期待がうかがえました。
記念すべき Regional Ruby Kaigi のトップバッターは和田卓人さんでした。自身の体験をもとに、 他の言語から Ruby へライブラリを移植するときの方法と注意点を発表しました。
第一部は移植の対象とした S2DAO の 2-Way SQL についての説明でした。
第二部は移植の方法と注意点について、
などのポイントが述べられました。
また、質疑応答で「動く状態にするだけの移植にかかった期間は二日間」と回答され、会場からは感嘆の声が挙がっていました。
最初と最後に、各地の Rubyist に向けて「(東京 Ruby 会議に)続け!」のメッセージが強調されたのも印象的で、 これからの Regional Ruby Kaigi への期待が膨らむすばらしい内容の発表でした。
吉見さんが、Ruby で Moose に似たアクセサを実現するライブラリ classx について発表しました。 Moose は Perl5 で洗練されたオブジェクト指向プログラミングを実現する拡張ライブラリのことで、 classx ではその Moose のように宣言的にアクセサを使うことができます。
DSL 的な単純な宣言から始まり、:default, :optional, :writable, :validate と オプションの指定を追加していくことでアクセサに機能が追加されていく様子は、 見ていてわくわくするものでした。
メインの話ではないものの、個人的に興味をひかれたのは、CLI アプリのオプションを簡単に扱えるという ClassX::Commandable の存在です。 extend ClassX::Commandable をして classx 形式でアトリビュートを宣言してやるだけで、 オプションのパースやヘルプメッセージの作成などを自動的に行ってくれるという機能は、 ポスト optparse として魅力的でした。
最後に「パフォーマンスにまだ課題がある」という話はありましたが、十分に今後への期待を抱かせる内容でした。
なお、classx の仕様については、東京 Ruby 会議でのフィードバックを受け、 ClassX クラスを継承するという方法からモジュールを include する方法へ変更 されています。 公開されている発表資料の PDF も、module 版に差しかえたものとなっているそうですので、是非参照してみてください。
こしばさんが 、Excel と Ruby を連携するためのライブラリ XLS モジュールを作ったときのエピソードを発表しました。 XLS モジュールは、CSV クラスを使うようなイメージで Excel シートを二次元配列のデータとして扱うことができるライブラリで、 Win32OLE 経由で使う Excel API の複雑さを抽象化しています。
Excel のシートから Java ソースコードを出力するツールを Ruby で作った際のエピソードを説明しながら、 Excel (と Win32OLE, ERB) のよさを熱心に語る様子が印象的でした。 中でも、入力フォーマットとして XML や YAML を選択するよりも、 Excel ワークブックを使えば誰もが使いこなせる優れたエディタ(=Excel)が付いているという主張には納得でした。
Ruby の話も所々で触れられており、Win32OLE を使うと Workbook オブジェクトなどを Workbooks.each で Enumerable に扱えることなどが、Ruby を使った Excel 活用の魅力として語られました。
最後の言葉も “Happy Exceling!” で締められ、狙いどおりの東京 Excel 会議だったのだろうと思います。
職業”編集者”という森田さんが、自分でほしいテキスト比較ユーティリティとして作った DocDiff の紹介を発表しました。
既存の diff では「読みにくい」「行の中の文字ごとの違いを見たい」などの課題があり、 自分でツールを作りましたという内容でした。途中、ツールのデモもあり、 色で相違箇所を見やすくハイライトするなど、プログラマでも十分に魅力を感じるツールでした。
修正 BSD スタイルライセンスを採用しているので、他のアプリケーションに導入することも可能なところもポイントだそうです。
「リアルな世界で人間的なつながりを持ちたい」という動機から設立された Asakusa.rb の紹介を松田さんが発表しました。
「東京には Ruby に関わる『中の人』がたくさんいる。その人たちには日本語も通じる。 このようなメジャープロジェクトのプログラマと直接コミュニケーションできるという状況は、 日本のプログラマ史上初のことで活かさなければもったいない」という指摘がおもしろく、 またこうして東京 Ruby 会議に参加すると共感できる言葉でした。 (もちろん、他の著名 OSS のコミッタで日本人の人というのもたくさんいるわけですが、 たとえば高橋正義さんや助田さんが発表者ではなく聴き手として来場し、 それでも地域 Ruby 会議が成り立ってしまうという裾野の広さは魅力なわけです。)
今後への期待も込めて、このような発表があったこともお知らせしておきます。Asakusa.rb は Seattle.rb のように 「成果を出す」活動へも力を入れていくそうです。どんな方向性のプロダクトが出てくるのか、非常に楽しみです。
Tokyu.rb を紹介し、参加者募集をする発表でした。設立メンバーの住まいが近所だったという Asakusa.rb に対し、 こちらの Tokyu.rb は東急沿線の Rubyist のためのコミュニティだそうです。沿線を決めてしまうことで、 参加する人が集まりやすいのではないかという予想のもと、Tokyu.rb という名前になったそうです。
Tokyu.rb も「何か成果が出るといいなぁ」という集まりなのだそうですが、今のところ 「無線 LAN がなくても生きていけるけど、お酒がないと生きていけない」という声に従い 飲みながら開発の会となっているようです。
今後は喫茶店で開発というようなこともしたいそうなので、飲まない人も参加歓迎ということでした。
「最近の LT では笑いをとろうという悪弊があるので、この発表は淡々と行きます。」という高井さんは、Akasaka.rb の紹介をベースに、地域.rb を設立するといろいろメリットがあるので 今後もどんどん勝手につくってしまえばいいのではないか、という主旨の発表をしました。
地域.rb 設立のメリットとして “membership categorization devices” を挙げ、 地域.rb という名目で集まれば、
などの事前に共通の理解がなければ中々できないようなことを実現できてしまう、 ということをメリットとして挙げられていました。
職場や学校で技術の話をしたいけど話の合う人がいないというような人は、 まず自分の職場や自宅の地域をつかって地域.rb を立ち上げてしまうのがいいのかもしれません。
柳澤さんが、Rails Outliner というアウトラインエディタについて発表をしました。
Rails Outliner は(ほぼ)リアルタイムにドキュメントへの変更を共有できるという点と、 変更履歴を管理しているのでロールバックが利く点が特長のアウトラインエディタだそうです。
Wiki のようなページ単位のテキスト形式ではなく、ノードごとで管理されているアウトラインエディタなので、 マインドマップや議事録、ToDo リストの管理などの用途に向くようです。
「Shooting Star を使用」という話だったので、変更の自動反映の仕組みは Comet で実現されているようです。 気になる変更履歴の管理は発表時点では機能を外していたようですが、 仕組みとしては都度全文を保存して実現しているそうです。
ちなみに、この発表ではブラウザを二つ並べて変更が共有される様子のデモがあったのですが、 デモの最中に突然「舞波」と編集されるというハプニングがあり、会場を沸かせました。 結果的に実際に誰もがリアルタイムに変更を共有できるということが目の前で実証されることにもなりました。
今後の課題としては、
などが挙げられていました。
開発は毎月第二・第四土曜日に株式会社パンカクのオフィスにて行われているそうなので、 興味のある方は遊びにいってみるといいかもしれません。
「会場でマックを使っている人はどのくらいいますか?」という質問から始まった ogijun さんの発表は、 Rubyist へ Mac を布教しようというもの。会場でも半分くらいは挙手があったのですが、 それでも RubyConf の圧倒的な普及率に比べるとまだ日本は遅れているということでした。 文字に起こして再現するのがむずかしいため省略しますが、たびたびジョークが混ざるとても楽しい発表でした。
残念だったのは、時間の都合で予定されていたデモがほとんど省略されてしまったことです。 それまでの説明で興味を惹かれていただけに、今度はぜひデモも含めた完全版の発表を聞いてみたいと思う内容でした。
10 の理由の内訳は、このようになっていました。
一番気になったのは、Growl と ZenTest を使うことで、 テストを常駐で実行し続けエラーになったときだけ通知をすることができる、という点です。 これはぜひ一度体験してみたいと思いました。
須藤さんが、Ruby でできているプレゼンテーション用ツール Rabbit について発表しました。
今年の Rabbit の姿を伝えると同時に、その設計思想や Rabbit を通して 須藤さんのプレゼンの思想までも伝えるという、魅力的な発表でした。
Rabbit は Ruby と GTK+ で実装されているプレゼンツールで、大きな文字と抽象化の二つが特徴だそうです。
大きな文字で書くことには、プレゼンについての思想が込められているそうです。 その思想は、プレゼンの聴衆にはすべてを伝えることはできないので、大事なことだけを話すようにするべきだというものです。
そして、大事なことだけ伝えるには、「短く」「わかりやすい言葉」で「直感的に」伝えることが必要で、 それに適しているのが大きな文字によるプレゼンなのだそうです。
次に抽象化についてです。Rabbit のシステムはおおまかに入力・出力・外部インターフェースで抽象化されています。 この抽象化は積極的なメンテナンス(生きるためのメンテナンス)を実現するために必要なことで、意識的に実践されているということでした。
最後の発表は、Ruby1.9 系統リリースマネージャーの yugui さんによる、 今後リリースされる予定の Ruby 1.9.1 についての発表でした。
Ruby1.9.1 は 、1.9 系初の安定版としてリリースされる予定のもので、 改善された文法や整理されたライブラリなどの恩恵が受けられるものになるそうです。
何よりも強かったメッセージは、 「1.9.1 はいいものなんですよ。」「皆が使ってくれないと安定しない。でも、ある程度安定しないと誰も使ってくれない。」 という言葉に集約されると思います。
「Rubyist は最終的には 1.9 系統を使うべきです。それだけの価値があります。」とのことなので、 早くその良さを活かしたい人はバグ出しに協力をしましょう。(私もしようと思いました。)
また、ソースコードを読む目玉も足りません。 バザールモデルの開発を機能させるには今よりも多くの人の目に触れる必要があるそうです。
最後に求人のまとめを転記しておきます。
そんなわけで、締めの言葉も「とにかく使ってください。」ということでした。
LT での発表に代表されるように、Ruby を楽しむ人と場が多い東京を象徴した Regional Ruby Kaigi でした。 発表内容も業務よりの話から自作のライブラリやアプリケーションの話、 そして Ruby 自身についての話と多様で、次回以降の開催への期待が膨らみました。
地元に近い(かもしれない)、チケット代がかからないなど参加にあたってのハードルが本体の Ruby 会議より低くなっていますので、 次回以降の東京 Ruby 会議、そして各地の Ruby 会議の開催を知る機会があれば、ぜひ一度のぞいてみてください。
blog.hacklife.net。Ruby 歴は約 4 年。好きなメソッドは、Expectations::Suite#expect 。