Hiroshi Yoshiokaさん「Ruby業務システムの広がりとホットスポット島根」

島根で長年システム開発を行っているというYoshiokaさんは，「⁠今日はスーツ族の代表として来ました」と述べてから，島根でのRubyを使ったシステム開発の取り組みについて発表されました。

島根では，まつもとさんをテコにしてRubyがマスコミにも取り上げられ，松江市民の半分くらいが"Ruby"をコンピュータ言語だと知っているそうです。 吉岡さんはメインフレームが普及する以前からシステム開発をされていましたが，2009年頃から小規模システムを中心に，Rubyの開発事例を拡大したそうです。産業振興として，Rubyで開発を行うと1/2の補助がでるなど，行政の後押しも強いことが言及されました。

行政などの業務システムではCOBOLを使ったシステムが多く，ベテランのエンジニアはCOBOLerが多いそうです。そんななか，若手のRubyエンジニアの育成と，開発現場から遠ざかってしまったCOBOLエンジニアがWebシステムの開発に参加できるよう，COBOLer向けRuby/Rails教育を行われていることが語られました。

また，テスト駆動開発などには抵抗を感じるエンジニアが多いそうですが，あるべき姿として，厳格なコーディング規約やソースのレビューなどを実施しているそうです。ベテランSEと若手エンジニアが一緒に取り組むことでできることがいっぱいあるはずだ，と語っていたのが印象的でした。

質疑応答では，「⁠進めていくなか，気持ちの上での難しさは？」という質問に対して，ベテランエンジニアにオブジェクト指向が誤解されてしまっている点をあげ，「⁠シンプルに業務システムに合わせて示してあげられれば，ノウハウを活かせるのではないか」と述べられていました。

淡々とした語り口のなかに，RubyKaigi2010のテーマである「Conflicts and Resolution（衝突と解決⁠）⁠」が詰まった発表でした。

Shintaro Kakutaniさん「There Is No Spoon -- Think Global，Act Regional」

Kakutaniさんの発表は，"I come here not to how good RubyKaigi is，but to thank RubyKaigi that made my life much better."との言葉で始まりました。

角谷さんは，いまだにRubyの良さはうまく語れないが，「⁠禅とオートバイ修理技術」という書籍から「Rubyには『クオリティ』がある」と述べ，時代を超えて受け継がれてきた価値がRubyにあると言及しました。そして，Clistoper Alexanderの「時を超えた建設の道」からこう語りました。「⁠質に通じるための道がある。質に通じるための道の入口に門を建てなさい。門を建てれば，そこをくぐって価値に通じることができる。わたし（わたしたち）が建てた門は，RubyKaigiだった。」

この世界に対する違和感（スーツや人月商売）があった，これを映画Matrixから「The Matrix」であるとし，本当の世界に行くための赤いピルとしてRubyを選んだ，と語りました。しかし，少なくとも日本では，Rubyを選んだからといって簡単にうまくいくわけではないという「砂漠のような現実」があった，とも述べました。それを踏まえて，「⁠私が今日確信を持ってお話するのは，コミュニティのこと」といい，「⁠コミュニティとは何か？」と提起しました。

これに対して，高橋さんがるびまにて「コミュニティとは誰か。もちろん、あなたのことだ。あなたがコミュニティであり、それ以外にコミュニティはいない。あなたのような人々の集まりを、コミュニティと呼ぶのだ」と述べたことを紹介し，Rubyを好きなひとが集まる場所がもっとたくさんあっていいのではないか，と考え，「⁠地域Ruby会議（Regional RubyKaigi⁠）⁠」の提案をしたそうです。

Regional RubyKaigiについて，「⁠RubyConfの下にRubyKaigiがあり，その下にRegionalがあるわけではない。コミュニティはツリーではない」といい，コミュニティは複雑な全体があり，構造がどうなっているのかわからないようなものではないか，と述べました。そして「⁠『⁠結果』は焦点ではない」とも述べ，大事なことは，ひとりひとりの活動を続けていくプロセスである，最初から大きな結果を求めていたわけではなく，できることをひとつづつやっていくうちにできることが増えていった，と，RubyKaigiとAsakusa.rbの活動を通じて語りました。

では，最初の一歩をどうすればいいのかと思ったときに，Matrixから"There is no spoon"，「⁠スプーンを曲げようとするから曲がらないんだ。スプーンなんか無いんだ」と引用し，目の前のものにとらわれすぎると先へ進めなくなる，少しでもいいから自分にできることを始めてみる，それを積み重ねることで大きな成果につながるものができるのではないか，と語りました。

そして，あなたがRubyに感じる価値を見つけ，そこに通じる道の入口に，自分ができることをみつけて「門」を建て，進んでほしい，と語りました。

角谷さんは最後に，「⁠むかしは人との関わりがうまくとれなかった。RubyKaigiを始めてRubyを好きな人たちと会い，話し，なにかすることで，それがすごく大切なことだと思えるようになった。なので，みなさんRubyistと，Rubyistが存在する世界に感謝したい。そして，そんなRubyを作ってくれたまつもとさんに感謝します」と締めくくりました。

準備していたプレゼンテーションがうまく動かないアクシデントもありましたが，ひとつひとつ言葉を探しながら語る姿が印象的でした。

SHIBATA Hiroshiさん「before Rails 時代のプログラマが如何にして after Rails の世界にたどりついたか」

RubyKaigi2010のテーマである「Conflicts and Resolutions（衝突と解決⁠）⁠」を軸に，before Rails世代とafter Rails世代という定義の元でのギャップについて語りました。セッションの途中でPCがフリーズしてしまい，中盤を口頭だけで話すというアクシデントに見舞われましたが，資料がなくてもわかるよう丁寧に進められました。

まず，Confictsをテーマとしてbefore Rails世代とafter Rails世代を以下のように定義しました。

• tDiary, Hiki, Kagemaiがリリースされてはじめた時期
• SourceForgeやRubyForgeにホスティングしていた
• RAAからライブラリをDLしていた

このような時代を経て育ってきた世代をbefore Rails世代とし，それ以降の世代をafter Rails世代としました。

そして，よく観察するとその2つの世代ではプログラミングスタイルには，以下のような違いがあると説明されました。

• ベタなeachメソッドではなく，mapやinjectメソッドを好む
• 文字列よりもSymbolを好む
• Metaprogrammingを好む

そして，Resolutionsとして，普段の行いはあまり変わらないはずなのに，なぜこのようなスタイルの違いが生まれてくるのだろうか，という疑問に対して，GitHubが大きな役割を果たしているのではないかと気がついたそうです。 ソースコードのホスティングとしてはSourceForgeもあるのですが，GitHubの場合はコミュニケーション，フィードバックを受け取る機構が優れており，独自にforkして修正したコードが気がついたらfork元に取り込まれてお礼を言われたりすることがあり，そのような交流から良いサイクルが生まれてくるのでろうと分析していました。

そのことに気がついてから，tDiary（hsbtさんはtDiaryのコミッタの一人です）をGitHubに移行させたそうです。

最後に行われた質疑応答では「after Rails時代に持っていきたいものは？」という質問に対して，「⁠tDiaryとHikiを持っていきたい」と述べられました。

Makoto Kuwataさん「HTMLデザインをまったく崩さない，美しいテンプレートエンジンの作り方」

Makoto Kuwataさんは，テンプレートエンジンとして必要なもの，テンプレートエンジンを正しく使うためにはどのようなことを意識する必要があるのかを詳しく紹介しました。

ビジネスロジック層（サーバサイドでのロジック部分）とプレゼンテーション層（HTMLテンプレート部分）の分離するだけでは不十分で，正しくはビジネスロジック層とプレゼンテーション層，そしてプレゼンテーションロジック層の3点に分けられるという切り口から話が始まりました。

Matzにっきに記載されていた内容を引用し，テーブルの行ごとに色を変えるという処理はプレゼンテーション層に入るべきではなく，プレゼンテーションロジック層として分離するべきであると語りました。

また，テンプレートエンジンに求められるものとして，できるだけデザインの担当者が難なく編集や確認ができるようにpure HTMLであることが望ましく，デザインとロジックで作業がコンフリクトしないような形式が良いと話しました。

そこで，Kuwataさんが開発したKwartzを使うことで問題を解決できるとして，Kwartzの詳細が説明されました。HTML内にはid属性にキーワードを含んだ形での名前をつけ，別ファイルで用意するKwartzファイルにその名前と紐づいたCSSライクな記法を用いてロジック部分を記述する，というスタイルで開発ができるようになるそうです。これにより，HTMLはpure HTMLに近く，プレゼンテーションロジックはKwartz用のファイルに集約でき，作業ファイルのコンフリクトも避けられると言及されました。

また，最後に改めて「テンプレートが pure HTML であること」と「プレゼンテーションロジックを分離・独立させること」の2つが大事なことですと述べていました。