RegionalRubyKaigi レポート (03) 関西 Ruby 会議 01

初稿：2009-02-07

RegionalRubyKaigi レポート (03) 関西 Ruby 会議 01

書いた人：こなみ (各プログラムのログおよび KOF 関連の記事を参考にして再構成しています)

はじめに

2008 年 11 月 7/8 両日にわたって、関西で初めての Regional Ruby Kaigi として、関西 Ruby 会議 01 が KOF2008 との共催で開かれました。KOF2008 には 2004 年に日本 Ruby の会の関西在住の有志として参加し、それをきっかけとして Ruby 関西が結成されるなど、浅からぬ協力関係を保ってきています。今回初めての共催、そして初めての関西 Ruby 会議ということで、試行錯誤の中で KOF2008 の実行委員会にも助けられながら 2 日間の日程を終えました。

関西 Ruby 会議 01 について

開催日: 2008/11/7 (金) 13:00〜18:00、- 2008/11/8 (土) 10:00〜18:00
開催場所: 大阪南港 ATC ITM 棟 6F マーレギャラリー (受付・展示会場)
〒559-0034 大阪市住之江区南港北 2-1-10
開催母体: Ruby 関西 (KOF2008 と共催)
後援: 日本 Ruby の会
参加者: 延べ 200 名ほど
動画・資料: 関西 Ruby 会議 01 ＠関西 - KOF2008

プログラム

Redmine でチケット駆動開発を実践する―チケットに分割して統治せよ（あきぴーさん）

概要と前振り

Redmine は Ruby on Rails という Web アプリケーションフレームワークを用いて開発されたプロジェクト管理ツールです。発表者のあきぴーさんは Web 開発のプロジェクト管理の立場から Redmine を使ったチケット駆動開発の有効性について講演されました。

冒頭、Redmine を使ったことがありますか？と聴講者にたずねたところ、手を挙げた人は約半分でした。

他の管理ツールとの比較

この種の管理ということでは Excel がよく使われています。しかし、タスクの管理に時間がかかることや、結合テスト以降のプロジェクト管理や繰り返しの管理が難しいといった問題点が指摘されます。

次にソフトウェアのプロジェクト管理ツールとして知られる Trac を Redmine と比較すると、Redmine の方が SVN のコミットログとチケットの連携が簡単であること、Trac は複数のプロジェクトを作れないのに対して Redemine ではそれができる、といったことが優位な点であるといえます。

実際の開発スタイル

ロードマップによる Redmine による開発管理の流れの説明の後、チケット駆動開発でアジャイルな開発をどう進めるかという、実践的な開発スタイルについての紹介がありました。

Redmine の運用フローはアジャイル開発そのもの。チケットを受け取ってから仕事を行うという「チケットファースト」の徹底が重要ということです。また、チケットの粒度を追跡可能な単位にまで分割して「分割統治」に持ち込むこと、バージョンごとに小刻みにリリースしていき振り返りをきちんと行うことも重要です。

チケット駆動開発においてガントチャートはそれほど重要ではありません。開発の特徴としては、運用保守においてソースからのリバートが楽であること、チームのコミュニケーションの活発化が期待できること、チケットで問題点が見えるようになることといった点が挙げられます。

最後に、チケットを乱発しないことと放置しないこと、大規模開発においてはチケット管理の専用要員を置いた方がよいといった注意点を述べて締めくくられました。

質疑応答

Q:一番悩むのはチケットの粒度。どうすれば良いか？
A:アウトプットが出る単位。長くても一週間。2、3 日が理想
Q:メトリクスについて説明して欲しい
A:バグ修正の曲線。チケットのすべての和と残りのチケットの数から作る。

講演の印象として、Redmine を活用したあきぴーさんのやりかたはプロジェクト管理の方法として有効と感じました。問題は、この利点を社内でどううまく説明して導入に持っていくか、また、質問にもあったようにチケットの粒度をどれぐらいにするか、といったところのようです。

Ruby Lightning Talk

大怪獣もぎゃさん「 RoR でつくるメールアプリケーション」

メール受け取って返信するアプリケーションを Ruby on Rails で作ってみました。

サイロス誠さん「 ATOK で Ruby を使えばモテるか？」

Justsystem から、ATOK ダイレクトを Ruby で作れるという API が公開されました。これを使って、色々遊びます。

ema さん「 Ruby で Wii リモコンを使う」

Ruby から Wii リモコンのボタンや加速度センサーの情報を取得します。まだ、少し情報をとれる程度ですが、簡単なデモを行いたいと思います。現時点では Windows 限定です。

よしだあつしさん「楽して作った Rails アプリ」

プログラマたるものいかに楽をして成果を出すかが重要。ということでフレームワーク、ライブラリ、プラグインの使用するといかに楽に Web アプリができるかをプレゼンします。

いまいさん「ターミナルアプリ on Ruby on Rails 」

script/console の TIPS 集です。 Live coding は手が震えてしまってプレゼン失敗するので、すべて irb のヒストリに仕込んで「 LiveHistory 」しました。使い方は、config/initializers に置いてください。モデルとかは適当に作ってください。

Nov’s Diary

スライド

ujihisa さん [LazyList の紹介]

遅延リストの意義と、Ruby でどのようにして実現するかを簡単に、触りだけ。濃ゆいマニアックネタだったのですが、ライブコーディングがトラブって時間切れしてしまいました。後で聞いたら、風邪で苦しくて頭が回らなかったとのこと。うじひさ節が聴けなくて残念！

ブログ

発表資料

吉川正晃さん「地方 SI 会社での Ruby 事情」

2001 年、1.6 系から業務用 CGI システムで Ruby を使用して来て、全国 274 団体に Ruby で作ったシステムが稼働しています。PHP、ASP、Perl、 Java も開発に使ってみましたが、Ruby はアプリの規模に見合っていて、かつ日本語の扱いが楽だったので決まり。tDiary が出てきたので、ソースを印刷して一生懸命に読んで勉強しました。最近になってdRuby を使いこなし始めて、連携先のシステムまで Ruby に切り替えるということもあります。

困っているのは、バージョンの移行の問題。まだ 1.6 で稼働している資産がかなりあるので、どう移行したらよいのかが悩み。さらに 1.8.5、1.8.6、1.8.7 と微妙に互換性のないものが並列する状況で、それぞれのメンテナンスがいつまでなされるのかが気になっているところです。さらにその上に 1.9.1 が登場したらどうなるのか、Rails は 1.9.x に対応するのか、そこいらの悩ましさが増しています。

発表資料

Hatena Diary

Ruby 初級者向けレッスン出張版 (okkez さん)

こじんまりと

12 月以降の勉強会に参加してもらうことを考えての出張版勉強会です。会場は定員 16 名の PC トレーニングルームで、2 回に分けて実施されました。1 回目は満員、2 回目は定員よりもやや少ない入りでした。

Ruby 関西で用意した DevianLive の CD を会場の PC で起動して、トレーニング環境を構成しましたが、アンダースコアの入力がうまくできないというトラブルが起きました。幸い X に詳しい人の助言で解決したものの、時間ロスが発生してしまいました。

Ruby で電卓を作ろう―その心は？

勉強会のお題は Ruby で動く電卓を作ろうというもので、配列をスタックとして利用することで RPN (逆ポーランド記法) 電卓を実現しようというものです。ただし、主眼としてはむしろテストを行いながらコードを書いていく開発手順を知ってもらおうという内容でした。プログラミングのレッスンとしては異例という印象もありますが、それはそれで okkez さんの狙いなのでしょう。配列を表示させるサンプルプログラムの部分はほとんどの人に理解していただけていたようです。ただし、# で始まるコメント行を律儀に打ち込むといった人もありました。

TA がいっぱい！

この手のイベントでは受講者のレベルの差が大きくなりがちですすが、そんな条件の中で、初心者には TA がつきっきりで教えていました。残念ながら時間が足りないこともあって、テストのとっかかりを少し書いたところで終わった初心者の参加者もかなりいました。

まとめ

全体として、Ruby 勉強会の雰囲気を伝えることには成功していたようです。最初のサンプルからいきなり Unit テストというやり方には賛否両論があるかもしれませんが、テストの重要性を認識してもらう意味では意義があったのではないでしょうか。16 名という少数の参加者に大勢の TA がついて教えることは、聴講者にとって収穫だったと思います。

dRuby and Rinda ―その実装と応用を (再び) 関西で (咳さん)

概要

20 世紀の終わり、京都の Linux Conference 2000 Fall & Perl/Ruby Conference の講演「dRuby による分散オブジェクト環境」からはじまった dRuby 入門行脚を、2008 年の秋、再び関西で行うこととなりました。 dRuby は Ruby のメソッド呼び出しを拡張し、プロセス、マシンを越えて行うことを可能にするシンプルなライブラリです。本講演は dRuby を使える・書けるきっかけとなる入門です。dRuby の簡単な使い方を紹介し、その実装を解説します。タプルスペースモデルを用いた並列処理糊言語「Linda」の Ruby による実装である Rinda について述べます。

前振り

RubyKaigi2008 における池澤さんの感動のプレゼンで一躍有名になった toRuby から来ました。第一水曜日に開催してます。みなさん来ますね？（笑）

dRuby は 2001 年に京都のイベントで初お披露目したのですが、再び関西で。それもついに関西 RubyKaigi 01。実は京都でやるもんだとすっかり思い込んでました。

Ruby ってどんな言語？

Ruby っぽく書いていると OOP な自分になれたように勘違いさせてくれる超かっこいい言語。

かっこいいクラスライブラリ
型のない変数
豪華なリフレクション
ユーザレベルスレッド

dRuby とは

‘D’ は Distributed。なので dRuby は分散な Ruby。原型は原さんが公開された shttpsrv + servlet。Ruby のモジュールを動的にロードできるようにしたもので、別のプロセス／マシンのオブジェクトにメッセージを送り、メソッドを起動する仕組みです。つまり dRuby は Ruby の RMI ( Remote Method Invocation )です。言葉を換えれば、「あらゆるプロセスはサーバでありクライアントである」、まるで OOP のよう（咳さんて言葉のうまい人だなあ:こなみ）。

実験

同じマシンの中で2つのターミナルを起動して、irb を使って 2 つのプロセスの間でメッセージを送る実験をしてみます。ちなみに咳さんは Mac OSX で実演。

irb を二つ起動して、ハッシュを公開
環境変数 ENV を順番に代入していくと、サーバ側でも値が入っている！
irb で $stdout を参照渡しして、”Hello World” を送ると、もう一方に “Hello World”. はい拍手。

SizedQueue も実験

生産者消費者問題を解いてみました。スレッド同期のメカニズムがそのまま動く例です。地味でした。

実装

実装は [ruby-list:15406]にある初版のソースをじっくり読んでみましょう。いろいろバグはあるけど、細かいことは気にしない。約 200 行をしっかり読んで。はい、これで dRuby を書けるようになりましたね。

応用例

たぶん、たくさんありそう。

hatena screenshot
RWiki すべてメモリの中にある Wiki (25000 ページくらいの Wiki は実績あり)

Rinda と Linda

最初に Linda の紹介、Linda は並列処理糊言語で、TupleSpace 上の Tuple というデータレコードがやり取りされる。エンジン（サーバと同じ役割？）やクライアントは Tuple Space だけを知っているというかっこいい並列処理。

Rinda は Ruby による Linda の実装で dRuby を意識してくれる。Tuple は Array で表現、要素ごとに Marshal する。TupleSpace への書き込み／読み出しは、 Linda では in/out、Rinda では write/take。

話はどんどん脱線、そして結び

最後に Tiny MapReduce by TupleSpace、Tokyo Cabinet 一族はかっこいい、OODB Koya は

世界は Hash だと思っていた。しかし実は BigTable であることに気がついた。

質疑応答

Q: どうやってオブジェクトの公開を通知するか？(たぶん Service Discovery のような事を意図した質問)
A.明示的に書くしかない
Q.特異メソッドを飛ばせないか
A.僕も知りたい

資料

Ruby ビジネスのワクワク・ドキドキ (最首さん)

概要

仕事で Ruby っていう話をよく聞くようになりました。同時に、地域 Ruby という切り口が、そこかしこで聞かれます。なんでそうなってるんだろう。どんな文脈なんだろう。福岡を中心に活動を続ける「 Ruby ビジネス・コモンズ (RBC) 」は、Ruby が持つ新たな可能性を感じながら行動をしています。このセッションでは、RBC が行っている活動。そして、そこから広がって来ている様々な動きを紹介することで、Ruby が開くビジネス領域での可能性について考えました。

RBC って何？

「仕事は楽しいですか？」、「仕事に思いを込めていますか？」講演の冒頭、最首さんは聴講者にこう問いかけました。そして人脈の大切さを語って、そこから RBC の活動の紹介になりました。2007 年の 7 月から多数の勉強会を主催、海外でもプレゼンを行い、579 名のメンバーがいて、その 9 割が勉強会つながりということです。

RBC 立ち上げのきっかけは、開発会社を福岡で作ったものの実際には下請け仕事ばかりで、そんな状況を打破したかった。街ぐるみで技術を勉強できるような仕組みを立ち上げたかったからとのことでした。

勉強会でやっていること

初心者でも分かって、1 日でできるようなコンテンツ作成、たとえば次のような感じで。

Rails を NetBeans を使って簡単なプログラムをとにかく作る
開発環境を作ってとにかく持って帰ってもらう！
具体的な文法は後回し(!)

最初のうちは、パソコンを持ってきてもらって Ruby の開発環境を環境構築するのが大変だったが、今はなれたのでそれほどでもないとのこと。町のふつうのおっちゃんに Ruby を教えて、Ruby にとにかく慣れてもらう話が最高でした。

コミュニティーから出てきた成果

無線 LAN の情報から現在の位置情報を知るプログラムをつくる
JRuby の使い方の勉強会→簡単に GUI を作るフレームワーク

まとめ

これ以外にビジネスの勉強会もこれまで 5 回やっている。いわゆるスーツとギークという対立しそうな二者だが、どうやってうまくビジネスをやっていけるかを模索している。

これまでの実績を振り返ると、まず参加比率はソフトウェア開発者よりもそれ以外の人の方が多い、IT 系ではない人とつきあうことで開発の幅が広がるのではないかと期待しているとのことでした。

最近の行政（福岡）としては、箱ものよりも人に投資していくこと、地元のニーズを地元でカバーするといった姿勢を持つようになっている。しかし、コンテンツが既存のルートでしか出てこないのは問題。これはなんとかならないものだろうか。

感想

開発するにはアイデアを提案できる会社が需要を起こすこと、というお話は感慨深かったです。この考えこそ、IT のゼネコン体制を打破できるのでは？

これからはもっとビジネスサイドの場を提供したいとのことなので、これにも期待したいと感じました。

The plan and worth of Ruby 1.9 (Yuguiさん)

「はじめての Ruby」の著者にして Ruby 1.9.1 のリリースマネージャの Yugui さんから、1.9.1 の内容とプロジェクトの現況について紹介。

Ruby1.9 の位置付け

Ruby 1.8.x はメジャーバージョンとして現在のアプリケーションを支えているメジャーバージョン、1.9 は 1.8 までとは大きく異なる、次へのステップとなるバージョンであり、2.0 は理想の姿だということです。

Ruby 1.9 とは何か。

1.9 になって新しくなったことは沢山ありますが、その中で重要なものはというと次のようなところです。

YARV: Virtual machine を採用
スレッドへの対応（ネーティヴスレッド、fiber ）
Multilingualization
RubyGems の標準添付

YARV について。1.8 までは構文木を生成し構文木を直接実行していたのですが、1.9 で Virtual machine を採用してたことで速度は 5 倍以上となり、シューティングゲームのようなものを Ruby だけで書けるようになりました。なお、バイトコードにいったん変換するようになっており、Java でいうクラスファイルに書き出すことができます。

スレッドへの対応ということでは、まずネイティブスレッドに対応しました。スイッチングは軽くなりましたが、スレッドの生成は重くなっています。マルチコアには対応していません。また Fiber という一種の軽量スレッドを採用しています。

Multilingualization の対応も大きな変化です。Ruby 1.9 では文字列オブジェクト自身が自分のエンコーディングを覚えていて、的確な文字処理を可能にしています。入力された文字列のエンコーディングは自動的に決定されます。またこれまでは Fixnum を返していた文字リテラルが、String を返すようになりました(ここで「文字リテラル ?d って (100 の意味で) 使ってないですよね？」と会場に尋ねたところ、挙手2名)。ソースコードの文字コードを指定するためのマジックコメントに対応して、$KCODE は廃止しました。

Ruby 1.9 on Rails

最もメジャーな Ruby アプリケーションである Rails を Ruby 1.9 上で走らせることは当然重要な課題ですが、まだ衝突する機能が多く、そのままでは走りません。multiple VM が可能になるわけですが、これも現状ではまだです。また eval を使うような処理は 1.9 系統では遅くなるので注意が必要です。最適化と eval は両立しません。

とはいえ、パフォーマンスの改善はまちがいなく期待できるわけですから、Rails は来年初頭に Ruby 1.9.1 が出たら¹すぐに対応するだろうと思います。

リリーススケジュール

1.9.1 は 2009/01/25 にリリースされる予定です²。1.9.2 は 2010 年になるかどうか、まだ分かりません。

リリースマネジメント

この辺がリリースマネージャとしての Yugui さんの本領発揮というところです。マネジメントのためにやったことは次のようになります。

サポートレベルを設けた。
メンテナの対応領域を整理し責任の所在を明確にした。
機能の凍結を行い突然の仕様変更がなされないようにした。
クールダウンのフェーズを設けてリリースを行なう。
issue tracker を使うようになった。

サポートレベルは Supported ( perfect )、Best effort ( enough to use )、Perhaps 、Not supported の 4 つに区別され、OS 等の実行環境をサポートレベルにわけてサポートを管理します。例えば FreeBSD は Best Effort 扱いです。

Issue tracker には Rails によるプロジェクト管理ツールの Redmine を使用しています（あきぴーさんの講演を参照）。Ruby の開発者はあまり Rails に興味がないのだけど Redmine を使っているわけで、これで Rails も安泰ですね（笑）。

1.8 からの移行で気をつけること

ブロックパラメータ、ブロック内ローカル変数の扱いが変わったので、Syntax Error になるソースもある。ソース内のマルチバイト文字はマジックコメントを挿入して対応。(エンコーディングを明示しておらず、潜在的に文字化けしていたようなコードはエラーになる)だいたいこんなところに気をつけてください。

まとめ

現代的で、より速く、より使いやすいのが新しい Ruby です。リリースされたらその時点で安定した Ruby なので、ぜひ使ってくださいな。

質疑応答

Q: Multi VM は?
A: 笹田さんが Ruby 1.9.5 からと言っている。
Q: 1.8 系はいつまでサポートされるのか。
A: 1.8 系はこのさきも暫くはメンテナンスはされる。
Q: Ubuntu のようにロングサポート等の制度はないのか。
A: 古いバージョンの時の管理等は酷かった。今後メンテナンスをうまくやっていけたらと思う。
Q: 1.8 系から1.9 系へのトランスレーテョンするような tool はあるか。
A: 1.9 系に移行してエラーが発生するというのは、そもそも潜在的なエラーを抱えているということ、そして文法上の細かな違いの部分なのでトランスレーターで対応する事はできない。
Q: 安定というのはどういうことを意味するのか。
A: 仕事で Ruby1.9 を使うのはかまわないけど、Ruby1.9 で作られたオンラインバンキングシステムがあったとして、それは使いたくないという程度の安定度

バックナンバー

RegionalRubyKaigi レポート (03) 関西 Ruby 会議 01