RegionalRubyKaigi レポート (17) 札幌 Ruby 会議 03

初稿：2011-04-05

はじめに

: sapporo03_0.jpeg

2010 年 12 月 4 日に、札幌で開催される地域 Ruby 会議として今年で 3 回目となる、札幌Ruby 会議 03 が開催されました。 今回は、まつもとゆきひろさんによる基調講演があり、道内外の Rubyist たちが数多く参加されました。 発表者として参加された名立たる Rubyist の みなさんを見ていると、 地域 Ruby 会議 というよりも、RubyKaigi の縮小版であるような錯覚を覚えました。 会場の規模や距離感のおかげか一体感のある会議になりました。 2 時間あった休憩時間では、みなさんスープカレーなど北海道の味覚を楽しまれ、 充実した時間を過ごされたようでした。

札幌 Ruby 会議 03 について

開催日
2010/12/4 (土) 9:30 〜 19:00
開催場所
メディア MIX ホール
開催母体
札幌 Ruby 会議 03 実行委員会、Ruby 札幌
協賛
株式会社アンタス, 株式会社えにしテック, 株式会社サンエス・マネジメントシステムズ, マリモインターネット
後援
日本 Ruby の会、一般社団法人LOCAL
参加者
およそ 150 名
動画・資料
公式ページ
公式タグ
sappororubykaigi03
公式ハッシュタグ
#sprk03

プログラム

「Ruby のテスト文化とツール 2010」柴田 博志 (@hsbt) - 永和システムマネジメント/ asakusa.rb

札幌 Ruby 会議 03 最初の発表は、前回と同じく tDiary コミッタとして活躍されている柴田さんの発表からスタートしました。 アジャイル開発でおなじみの永和システムマネジメントに入社されてから半年の間に得られた Ruby と Rails のテスト環境についてお話されました。

RubyKaigi2010 で ThoughtWorks の Sudhindra Rao さんが言われていた 「Ruby には非常に成熟したテスト文化とツールもある。」「テストを書かなかったら、君は本当に Ruby 開発者かと言われてしまいますよね。」 という発言の紹介を切り口として、 この”非常に成熟したテスト文化とツール”とは何かを説明してくださりました。

永和システムマネジメントでのソフトウェア開発の文化

: sapporo03_1.jpeg

  • 文化その 1:テストを書く

Ruby を使うとどんどん書ける。 Ruby を使うとビジネスロジックをどんどん書ける。しかし書いているコードが動くかどうかが不安になるので、それを検証するためにテストを書くというスタンスのようです。 metric_fu という静的解析ツールを利用すると、 コード品質の把握ができ、テストが必要なメソッドの把握も可能です。 永和システムマネジメントでは基本的には RSpec を使い、最近は metric_fu をテスト環境に導入したとのことでした。

  • 文化その 2:テストを書くレイヤーを分割する

mock と stub の活用などにより、テスト対象とするレイヤーの切り分けについてお話されました。 stub とはテスト対象を機能にフォーカスしたもの、mock とは他のオブジェクトとの相互作用をテスト対象としたものという説明でした。 テストでの一時的な初期テストデータを投入する際に fixture を利用しますが、 この fixture を置き換えるためのツールとして factory_girl というライブラリが 古くからよく使われているとのことでした。 他にも Machinist というツールを紹介されました。

  • 文化その 3:動かないテストを放置しない
    • 月末をまたいだらテストが落ちる
    • 他の環境で実行すると落ちる
    • (単体のテスト実行では落ちないが) rake spec を実行すると落ちる

テストが動かなくなるケースとして以上の三つを挙げられました。 このように動かなくなったテストを放置しないために Hudson を用いて CI (Continuous Integration) 環境の構築を行っているそうです。 CI 環境とは、継続的にソフトウェアのビルドとテストを行う環境のことです。

テストが通らないことがわかった時点で、バグを直しにかかるそうですが、 もうひとつの文化として

  • 文化その 4:バグを再現するテストを書いてから直す

という文化があるそうです。 しかし、開発にノっている最中に再現するテストを書いているのは 時間的にもったいないということで、テストの高速化とリズムが必要だと説いています。 このリズムの確保として、spork や zentest というライブラリを紹介されました。

テスト駆動開発にすぐ役立ちそうなたくさんのツールを紹介していただけました。

「高速な乗除算の実現と性能評価」村田 賢太 (@mrkn) - 株式会社ジェネティックラボ && Ruby 札幌

: sapporo03_2.jpeg

札幌が誇る Ruby コミッタである村田さんが Ruby での高速な演算とその性能評価についてお話されました。

今回の発表では Ruby の数値系に属する Integer (整数の一部) と Rational (有理数の一部) についてお話されるとのことでまずは四則演算について人間が学校で習う解法を例に出しておさらいをし、その結果から桁数の二乗の計算回数が発生することを示されました。

「速さ==ロマン」ということで乗算、除算が速くなれば Ruby における様々な演算に速度的な恩恵があるという説明がなされました。例として有理数の場合は通分の処理に除算が必要となり、大きな桁ではコストが発生することや、素数に関するライブラリである prime.rb で行っている素因数分解の計算も高速になること、整数の演算が早くなると BigDecimal の演算も早くなることなどが話されました。そのなかで今回は「高速な乗算」にフォーカスして説明が進んでいきます。

乗算の高速化のために、乗算の回数を減らすアルゴリズムはすでに世の中にあるとのことで

  • Karatsuba
  • Toom-Cook
  • Shonhage-Strassen
  • Fuler

という４つのアルゴリズムが紹介されました。そのうち Karatsuba は既に 1.9.1 で実装されており 今回二つ目の Toom-Cook3 を村田さんが実装されたということで、前日の 23 時 30 分にまつもとさんからコミット OK をもらったというメーリングリストのログが示され、会場では拍手が起こりました。

実装の速度を 1.9.2p80 と比較測定したところ、10M 桁という大きな桁の掛け算や、5 の n 乗で n が大きくなるとそれぞれ 2 倍以上のスピードになることが示されました。

また、除算では Newton 除算を実装したのですが測定の段階でふつうの除算より遅い結果になってしまったとのことで残念ながら今回の発表には間に合いませんでしたが、 原因としては大きな数の掛け算が遅かったためとのことで、今後の高速化には期待が持てるようでした。今後の展望としては除算の高速化や、先ほど上げた残り 2 つのアルゴリズムの実装などを考えているとのことでした。

発表ではそれぞれのアルゴリズムについてどのように計算回数を減らしているかの説明も行っているので興味が有る方は、是非動画やスライドを御覧になっていただければと思います。Ruby の数値系ライブラリの今後が楽しみなセッションでした。

「Ruby の未来/未来の Ruby」まつもと ゆきひろ (@yukihiro_matz) - (株)ネットワーク応用通信研究所

: sapporo03_3.jpeg

Ruby の父である、まつもとゆきひろさんが基調講演としてこれからの Ruby について話してくださりました。 1993 年に作られたという Ruby も 18 歳になり、高校生になったと言えます。

Ruby という言語を作る際に、他の言語の特徴として取り入れたかった要素について話されました

  • 高階関数
  • オブジェクト指向

スクリプト言語でオブジェクト指向を用いるのは一般的ではないとされていたが、 C などの大規模言語で便利なのであれば、スクリプト言語で便利でないわけがないと思い、 Ruby はオブジェクト指向言語としてのパワーを持つことになったとお話しされました。

また、Ruby がもたらした影響についての話をされました。 日本発のプログラミング言語ということで、 マルチバイト文字を扱うためマルチエンコーディング環境をいち早く届けることができたのは Ruby の貢献によるところであることや、 ソケットをオブジェクト化し、システムコールをクラスライブラリにまとめることによってどれだけネットワークプログラミングを簡単にできるか ということを示すことができた言語は Ruby であるだろうということや、IPv6 への対応が迅速であったことも挙げられました。 Web プログラミングにメタプログラミングの要素を取り込んだことや、 テスト駆動開発を行いたい人たちを思想的に助けたのは、Ruby という触媒があったからであろうとお話しされました。

まつもとさんが発表中に何度も繰り返し述べていた言葉として “光あれ”という言葉をおっしゃっていました。 この言葉の意味するところとしては、「そこに良いものがあるならば、それを届けよう」「なければ自分で作ろう」という二つの意味を表す言葉ということでした。

Ruby のこれからということで、Ruby2.0 の新機能についてお話しされました。 RubyKaigi2010 でもお話しされたことなのですが、 詳細については 2010年11月13日のMatz日記を参照していただきたい。

Ruby の光が届いていない分野に Ruby という光を届けたいということで、 HPC (High Performance Computer) つまりスーパーコンピュータの分野とこれを使う研究者に対して Ruby の光を届けることにより、研究者の生産性を向上させることができるのではないかと語られ、 東京大学の平木研究室と共同で取り組みがなされているようです。

もう一つ Ruby という光を届けたい分野として、組み込み分野への取り組みが紹介されました。 RiteVM という一つの処理系を新たに作り、この処理系ひとつで幅広い組み込み分野をカバーできるのではないかと考えられ、 Lua 言語の VM を参考にし、Ruby の膨大なクラスライブラリの一部を起動時に読み込むサブセットの構成にするなどの方針が示されました。 この取り組みについての残念なお知らせとして、 この取り組みの終わりが見えるようになるまでオープンソース化がされないことと、 途中からプロジェクトに参加する方法がないことが明らかにされました。

「北の Rails 開発現場から’10」前田 智樹 (@tmaeda) - 株式会社アンタス、Ruby札幌

: sapporo03_4.jpeg

Ruby 札幌運営であり、RubyKaigi2010 実行委員、そして今回の札幌 Ruby 会議 03 運営委員長である前田さんが株式会社アンタスによるスポンサーセッションとして、「ペアプログラミング」(以下ペアプロ) の導入の経緯と感想について話して下さいました。セッション開始時に Mac が起動しなくなるというトラブルが起きてしまい、急遽順番を入れ替えての発表でしたが復帰までのトラブルシューティングの内容もネタにするなど、和やかな雰囲気で発表がスタートしました。

発表では「中途採用のベテランと新卒との技術力の差が時間では埋まらない」という問題が提起されました。なぜ時間がたっても新卒の人がベテランに追いつくことができないのかという視点で考えた結果「仕事っぷり」が見えないという気づきがあり、見える化することによって、新卒はベテランから学ぶことができ、ベテランは新卒に良い点、悪い点の指摘を行うことができるという大きな利点があると考え、ペアプロを導入されたとのことです。

その効果としてはコーディングとコードレビューと教育と引継ぎが一度にできることや、現在のプログラムでのボトルネックである”考える事”の高速化、高いの集中力とほどよい緊張感の獲得、動作したときの喜びの共有などがあり新卒の育成に実際に非常に効果があったとのことでした。

発表の後半には実際にペアプロを行なってきた中で、見えてきたものとして開発環境などについてベテランからすると当たり前に感じる script/console, script/dbconsole, エディタの入力補完, GNU screen, readline などについてお話いただきました。まるで参加者が新卒役として、一緒にペアプロを行っているかのような内容で初学者の方には非常に参考になる内容でした。

実際に実践している血肉になっている発表だったため、参加者の関心も高かったようで多くの質問が上がり

  • エディタ環境の差異などもお互いに勉強になる
  • 導入の敷居は高いが効果は高く、新卒のスキル向上がベテランの手が取られる分を差し引いても効率が上がっている
  • 見積りはペアプロとそれ以外で特に差異はない

など生の回答を聞くことができました。同じような悩みをもっている皆さんは是非参考にされると良いのではないでしょうか。

「Ruby の教えてくれたこと」島田 浩二 (@snoozer05) - 株式会社えにしテック、Ruby札幌

: sapporo03_5.jpeg

Ruby 札幌主宰の島田さんによる、えにしテックのスポンサーセッションでは、 島田さんが Ruby について感じている良さについてお話されていました。

Ruby を使っていて、島田さんが感じる良さとして 「オレってばスゲー感」があると仰られました。 自分のコードは平凡なものだが、Ruby がちょうどよくサポートしてくれているところに良さを感じるとのことでした。

Ruby を書いていて気持ちいいと思うのはなぜか？そう考えることが、 島田さんにとっての成長につながるのではないか、そう考えたそうです。 そこで、特に良さを感じられる”ブロック”という仕組みについて詳しくお話されました。

ブロックを使ってできることとして具体的に、

  • イテレータ
  • 具体的な処理の記述
  • 対称性のある処理の保証
  • アルゴリズムの差し替え

この四つを紹介され、ブロックを使うことで状況によって変化しそうな部分を、 コードを修正せずに差し替えることができると話されました。 ブロックを利用せずとも実装する方法はありますが、 ブロックを利用することで、構造を複雑にせずに程よい柔軟性を確保できる点が ブロックを利用することの良さだと話されました。

コードに入り込む複雑性には、

  • 問題にもともと存在している複雑性
  • 動かすために入れてしまった複雑性

この二種類あると話され、 達人プログラマからの引用として、

"ソフトウェアは複雑さの増大によってダメになる"

という記述を紹介されました。

島田さんのリスペクトしている考え方として “YAGNI” (You Aren’t Going to Need It) という言葉を紹介され、 推測に基づき、作り込んだコードは使われず 予想していない変化に対応できず、コードが複雑になってしまう。 そのために、どうしても必要がある場合以外には 作り込むことによって複雑性を持たせてはいけないとの考え方でした。

なぜ複雑性を取り除きたいのかという問いに戻ったとき、 変化に対応するという価値が大事なのであって、 実現するための手段が大事ではない。 その価値として、オブジェクト倶楽部での Open-Closed Principle とデザインパターンについての記事を紹介された。 ぜひ、一読していただきたいとのことでした。

変化に適応するためには

  • シンプルなコード
  • 包括的なテスト

この二つが大事だとお話されました。 シンプルなコードとは、変化が発生したときにいつでもコードを修正できるようにシンプルにしておくことという意味で、 包括的なテストとは、コードを修正した際にもテストが通るようにテスト対象をカバーできているテストを用いるという意味で使われているようでした。

ソフトウェアを育てていくために、どんな価値を大切にしたらよいのかという示唆を与えてくれるセッションでした。

「(カーリングとRuby) 2 投目 - Making Ricochet with the Ruby stone into Granites.」はしむかい としかつ (@curler_hashi) - 妹背牛カーリング協会

: sapporo03_6.jpeg

前回の LT で大好評だった、はしむかいさんの発表がセッションになって帰ってきました。 氏は北海道の妹背牛で稲作農家をされており、橋向農場謹製のお米のプレゼントも行われ 技術イベントとしては異様な盛り上がりを見せていました。

稲作農家とプログラミングは一見関係ないように見えますが、 はしむかいさんは大学卒業後、プログラミングの請負業を農業と並行して行っていた時期があるそうです。

はしむかいさんは妹背牛のカーリング協会に所属されており、 妹背牛協会の Web ページ作成に携わられ、 カーリングの試合結果をどのように文法化するかという問題にぶつかり、 Wiki のスタイルを踏襲しパーサを改変することでスコア表示機能を作成したようです。

ページの改善要望として、カーリングのスコアや試合結果を掲載できるようにという 要望が寄せられているようで、今後作成したいソフトウェアについても語られました。

試合の統計的なデータの掲載や、試合の動画記録公開、 試合中継機能、カメラからの画像を射影変換することによる石の位置を特定し位置を記録する機能、 試合時間を計測する計時ツールや、石やブラシにセンサを埋め込み情報を得ることで練習を補助するツール などのソフトウェアを作成したいとの意向を語られました。

最後に、カーリングとプログラミングの共通点として カーリングのルール変遷について語られた後に

  • ルールがあってカーリングがあるのではない
  • カーリングはいつだって変わってきた
  • 「カーリングをする人すべてが広報担当」

といったことを語られました。

カーリング場がオープンすることが決まった札幌で、 カーリングとプログラミングの橋渡しをされたようなセッションとなりました。 札幌に住むプログラマの息抜きとして、カーリングが流行する日も遠くないのかもしれません。

LightningTalk

「RVMについて語るときに僕の語ること」- takkanm - 永和システムマネジメント

Asakusa.rb のメンバーで Rails 勉強会@東京を主催されている m さんが RVM についてお話してくれました。

RVM とは、Ruby Version Manager の略で、一つの環境で複数の Ruby 環境を簡単に切り替えて使うことのできるライブラリです。 trunk の Ruby もインストールすることができるので、最新の Ruby を簡単に試すことができるとのことです。 また Ruby に必要なライブラリのインストールや RubyGems の管理もできるため、とても便利なライブラリだそうです。

JRuby や IronRuby など、MRI 以外の Ruby もインストールできるのですが、m さんによると GoRuby が足りないとのことでした。

GoRuby は CodeGolf の用の Ruby 実装で、Ruby をとても少ないコード量で記述することができます。

m さんは GoRuby を RVM に追加してもらうために RVM のプルリクエストを送ったそうですが、その 8 時間後には RVM に GoRuby が追加されていたそうです。

そのおかげで、以下のコマンドを入力することで ruby コマンドで GoRuby が使えるようになるとのことです。

$rvm update --head

$rvm install goruby

$rvm use goruby

GoRuby を RVM に追加してもらう際に、m さんは RVM を修正したそうです。 RVM は巨大なシェルスクリプトなので、実際に読んで修正することもできるとのことです。

中身を知っておくことで不意なトラブルに対応できるようになる、ということでこんなメッセージをいただきました。

道具を知って道具を選ぶ

最後に”GoRuby を始めたのでお使いください”と締めくくられました。

「文書検索ラングバ」- 須藤功平 - 株式会社クリアコード

Ruby 製プレゼンツール Rabbit を作られた須藤さんによる、文書検索ラングバの発表をしてくださるはずだったのですが、 リリースが間に合わなかったため、埋め合わせの話として”デバッグ力”についてお話されました。

須藤さんはデバッグ力とは前に進む力だと説きました。 島田さんの発表で紹介されたボーイスカウトの法則も取り上げつつ、 次に通る人が通りやすいようにするために、 自分の通ってきた道は少しでも歩きやすくして進みたい、 道がない場所を進むのは大変だし険しい だからまず自分が前に進むためにデバッグ力が必要であるとのお話でした。

デバッグのイメージは、人それぞれつらいものであったり、わくわくするものであるかもしれません。 デバッグの対象は、自分の作った物よりも他人の作った物の方が圧倒的に多いでしょう、 そして自分が作った物でさえ、結構間違えてしまうので、 他人の作った物に関してはそれこそ予想外だと話されました。

ではどのように、間違いを無くしていくかといったとき、 間違えないように慎重にする方法と、間違えるのは仕方ないと許容する二種類があると話されました。 しかし、本当に大丈夫なのか？と問われたとき、”なんとかできる”と 話せる人はデバッグ力がある人だとのことでした。

では、デバッグ力のつけ方とは？ やり方を覚えて、何度もやるうちにデバッグ力はついてくる、 やり方はひとつづつ、ひとつづつ、ひとつづつ 一つのことに集中してやっていくしかないのだと仰られました。

プログラマがデバッグを通してどう力を付けていけばよいのかという 非常に為になるお話でした。 —- —-

「Rails 3.1 “wiki_mode” Engine」 - 松田 明 - Asakusa.rb

今回はじめて北海道にいらっしゃったという、Asakusa.rb の発起人であり、浅草の Jeremy Kemper と言われる松田明さんが Rails3.1 の新機能を使って実装した「wikimode」のライブコーディングを行ってくださいました。

Rails 3.1 での新機能とは新機能は Ruby Summer of Code のプロジェクトにて開発が行われており Isolated Engine または Mountable Apps と言う名称で既に Edge Rails にはコミットされているとのことでした。 その機能を用いることによって「wikiwiki した感じ」で Rails アプリを作れるものとのことです。百聞は一見にしかずということで、定番のブログアプリのライブコーディングが軽快な音楽と共に始まりました。ポイントはコマンドラインを使わないということで、デモがはじまってからはコマンドラインからの入力はありませんでした。

今回見せてもらったデモでは次の 3 点を行っていました

  • 存在しないリソースの URL を打ち込むと Resource Missing を捕まえてジェネレータを起動し、パラメータを指定してリソースのジェネレートを行う
  • Wiki のようにその場で View のソースを編集し、リアルタイムに変更を反映
  • link_to や form_for を作ったときに、url for missing だった場合にもジェネレータが起動し、生成を行える

ブラウザ上だけで Rails アプリが作られていく様は魔法のようで会場でも大きな拍手が上がっていました。Request Driven という手法は Ymir という Java のフレームワークで実現されており、それが素晴らしかったので今回つくってみたとのことでした。

最後はそろそろ gem で公開するので乞うご期待！という言葉で締めくくられました。興味が有る方は是非お試しください。

「JRuby によるエンタープライズ Web 開発」 - takai - Akasaka.rb

「Java プログラマのための Ruby 入門」の著者であり、「エンタープライズ Rails」の監訳も行っている高井直人さんが JRuby を使ったエンタープライズ開発について語ってくれました。

えにしテックのお仕事や、その社員である @darashi の結婚ツイート (おめでとうございます) 、角谷さんの息子さんの笑顔などを示しながら「世の中の大部分は、エンタープライズで出来ている」ということを主張されます。

エンタープライズといえば Java、Java といえば Struts、そして Struts はほんと XX で … と dis りながら、Struts の Front Controller パターン、ActionServelet → Request Processer → Action という処理のうち Request Proseccer を JRuby をつかって処理先をRubyオブジェクトに委譲する方法を説明しました。そして更に発展形としてSinatra への委譲を示し Struts が置き換えられることを説明されました。

LT 前の発表であったカーリングネタも散りばめられた、ユーモアたっぷりの発表でした。

「HTML デザインをまったく崩さない、美しいテンプレートエンジンの作り方 パート2」 - 桑田誠

RubyKaigi2010 でも同タイトルで発表された桑田さんが、札幌 Ruby 会議 03 の場でその続編をお話いただきました。前回の発表ではビジネスロジックとは別にプレゼンテーションのレイヤにもプレゼンテーションのロジックが存在する、という主張を行い

  • プレゼンテーションロジックを HTML テンプレートに含めないことが重要
  • テンプレートの HTML デザインを崩さないだけでは不十分
  • Kwartz ではプレゼンテーションロジックを CSS のように外部ファイルに分離している

ということを振り返りとしてあげられました。

今回は HTML デザインを崩さないテンプレートエンジンの簡単な作り方について説明されるとのことで

  1. HTML をクラスに自動変換
  2. そのクラスを継承し、プレゼンテーションロジックを追加
  3. クラスを実行して HTML を生成

という手順をソースコードと具体例を示しながら解説を行われました。プレゼンテーションロジックの追加には Generation Gap パターンを用いて行うとのことです。

この仕組を用いると継承が使える言語ならば数百行程度で pure HTML のテンプレートエンジンを作成できるとのことで、実際に作成したものが「Kwartzite」とのことでした。

興味を持った方はソースコードを見たり、実際に作成されてみてはいかがでしょうか。

「たまには cgi.rb のことでも話してみる」 - 藤岡岳之 (@xibbar) - 株式会社ラビックス

cgi.rb のメンテナである藤岡さんが cgi.rb についてお話してくれました。

Web アプリケーションを稼動させる仕組みとして Rack が人気となってきていて、cgi.rb でしか動作しないアプリケーションはだんだん減りつつあります。 そこで藤岡さんは、Rack を使って cgi.rb を実装した rakugaki というライブラリを作成されました。

この rakugaki を利用することで tDiary などのレガシーなアプリケーションを、そのまま Rack 上で動作させることができます。

この rakugaki を作成するにあたり、Ruby のブロックを利用することで比較的容易に実装することができたそうです。

レガシーなアプリケーションを Rack に対応させることで、稼動できる環境を増やすことができる魅力を教えてくれる発表でした。

「Perl ♥ Ruby」 - 山川宣仁 (@havanacllub_) - Hokkaido.pm

Hokkaido.pm からお越しの山川さんが、Perl と Ruby の最近の関係についてお話してくれました。

まつもとゆきひろさんもおっしゃっていますが、Perl は Ruby のお兄さん的な存在です。 しかし最近の Perl は逆に Ruby からの影響を受けていて、Ruby にあるようなライブラリも多く登場してきています。

たとえば Web サーバのためのインターフェースである Rack に対応する Plack や、 簡単に Web サーバを書くための Sinatra に対応する Mojolicious::Lite といったフレームワークが登場してきています。

Perl は言語仕様が “グロい” ということで、言語自体を拡張することで “Ruby っぽい” 文法にするライブラリを紹介してくれました。 Rubyism というライブラリを利用すれば、かなり Ruby チックな書き方で Perl を書くことができます。 Ruby ではおなじみの yield も実現しています。

そして、これではまだ Ruby 度が足りないという方に向けて、Inline::Ruby も紹介してくれました。 Inline::Ruby は Perl のソースコード中に直接 Ruby を埋め込むことができるようになります。 これを使うことで、Ruby で書かれた関数やクラスを Perl から利用できるようになります。

この Inline::Ruby がどういう仕組みになっているかというと、 Ruby のインタプリタを C 経由で直接実行することで、Ruby-Perl 間の相互方変換を実現しているとのことです。

また、Ruby に大変影響を受けた Perl6 のオブジェクトシステムの Perl5 への移植として、Moose (&Mouse) の紹介もありました。 これを利用すると、Perl の “グロい” とされている部分の解消し、オブジェクト指向プログラミングを簡単に行えるようになります。

また最後には、Hokkaido.pm をよろしくお願いします、と締めくくられました。 Perl に対しても Ruby に対しても愛の詰まった発表でした。

「Ruby でネイティブスマートフォンアプリ開発」 - 前鼻毅 (@sandinist) - RICOH IT SOLUTIONS

オンラインストレージである Quanp の開発者である前鼻さんが、Ruby でのスマートフォンアプリ開発についてお話してくれました。

Ruby でスマートフォンアプリを作成するためのフレームワークとして Rhodes を紹介してくれました。 Rhodes は Ruby on Rails に影響を受けたフレームワークです。 コマンドからアプリの雛形を作成したり MVC に則って開発を進めていくなど、Rails を使ったことがある人には馴染み深い開発スタイルです。

またコマンドから iPhone 用にビルドすることができ、実際にビルドしたアプリのデモを見せていただきました。 Rails のようなコマンドから CRUD 機能を備えたアプリが簡単に作成できるとのことでした。

iPhone 以外にも Android や WindowsMobile、BlackBerry を網羅していて、同じソースコードからいろいろな環境用にアプリを公開できるのがとても魅力的です。

前鼻さんはこの Rhodes を利用して、札幌 Ruby 会議用のアプリを作成されたとのことでそのデモも披露してくれました。

発表内容の一覧や発表者の情報を閲覧でき、会場や懇親会会場の地図も表示されるので、

札幌 Ruby 会議の当日までに公開が間にあわなかったそうですが、 実際に使ってみたいと思われた方も大勢いらっしゃたのではないでしょうか。

スマートフォン向けのアプリ開発の際にはぜひ Rhodes の利用を検討してみたい、そう思わせてくれる発表でした。

「どこでもRubyといっしょ 〜WindowsMobile携帯にRubyを入れて遊んでみた〜」 - H.Hiro/Maraigue - Ruby札幌

Ruby 札幌の勉強会への参加や、今回の札幌 Ruby 会議 03 でのスタッフとして活動してらっしゃる 札幌の大学院生である H.Hiro さんが Windows Mobile 上で Ruby を動かして遊ぶ、というお話をされました。

会場で Windows Mobile ユーザーの方に挙手してもらったところ、意外といるということに驚きながら発表が始まります。 Ruby を動かすための環境については次のものをインストールする必要があるとのことでした。

  • Ruby のコンパイル済みバイナリ
  • CUI シェル

ワンライナーでの動作やファイル操作を行っているスクリーンショットを示して動いたことを説明しますが 標準入出力が貧弱で irb のようなインタプリタは今回の発表までには動作させられなかったとのことですが

  • Ruby バイナリを自分で作る
  • Windows GUI と一体化したアプリを作る

という目標をもって、これからも開発を行っていくとのことでした。

「コンサドーレ札幌の情報収集を ruby でやるには」 - ヽ（´・肉・｀）ノ(@niku_name) - 株式会社エスプランニング

コンサドーレ札幌のサポーターである肉さんはコンサドーレの情報収集を Ruby を利用して行っていらっしゃるとのことです。

2008 年から Ruby での情報収集を始められたそうで、その開発についてのお話をしてくれました。

情報は Web スクレイピングで収集されているとのことですが、Web スクレイピングだとテストコードを書く際に面倒な部分があります。

  • テストのたびに Web にアクセスするのか
  • 文字コードをどう扱うか

肉さんはこの面倒な部分を回避するために、テスト用のスタブを用意して、サイトごとにダウンロードしておいたファイルを読み込ませるようにしたそうです。

また、Web スクレイピングで値が取得できなくたったときにどこに通知するかという問題があります。 もしどこにも通知していないとひっそりとアプリケーションが死んでしまうので、値が取得できなくなったらどこかに通知するようにしましょう、とのことでした。

肉さんはコンサドーレ札幌関連情報を流す bot (@consadole) を管理していて、こちらのフォロワーが 1,000 人を超えたそうです。

「最も大事なのは、コンサドーレが好きなこと！」

まさにコンサドーレ札幌への愛を全力で表現されたお話でした。

「Pusher アプリの作り方」 - 大和田純 (@june29) - Ruby札幌

AKB48 のオマージュで、自己紹介から会場を湧かせてくれた大和田さんの発表です。

チーム A から着ました。

会いに行けるプログラマの大和田純です。

大和田さんは Pusher アプリの作り方を紹介してくれました。 まずは Twitter のタイムラインや Twitpic の画像をリアルタイムで取得するデモを紹介してくれました。 動的 Web を支える技術の一つとして、WebSocket があります。 WebSocket はサーバからクライアントにリクエストを送る技術で、遅延なし・無駄なリクエストなし・クライアント側の無駄なコードなしでリアルタイム通信を実現できます。

Pusher とは WebSocket をホスティングしてくれるサービスだそうです。

RubyKaigi2010、札幌 Ruby 会議 03 でもこの Pusher を利用したアプリを使って、サブスクリーンに Twitter のタイムラインを表示していたそうです。

ここで Pusher アプリの構成について解説してくださいました。 サーバ側ではチャンネルを指定して好きなラベルにデータを送り、これを受け取る JavaScript 側では指定されたラベルによってどんな処理をするかをそれぞれ書くそうです。 RubyKaigi2010 では、ピーク時には 1 分間に 4,000 メッセージをクライアント側に送信していたとのことで大規模なサイト構築にもオススメですし、個人で簡単なチャットを作るくらいなら数十行のコードで書けるそうなのでぜひ試してほしいとのことでした。

Pusher は便利なので、みなさんもお使いくださいとのことでした。

「或る Web サービス開発のこれから」 - “オープン Web サービス”という妄想 - 白土慧 - Ruby 札幌

Ruby 札幌の白土慧さんが最近作られたという Notwife というサービスを通じて、 Web サービス開発がどのようにありたいかという展望についてお話されました。

Notwife というサービスは Twitter での mention や follow や favorite などを、 notifo というサービスを使って通知してくれるサービスです。

この Notwife を開発する際に三つの “centers” と呼ばれる価値を決めたそうです。

  • Push の面白さを伝えたい!
  • サービスの運用をしたい!
  • オープンにしたい!

この”オープンにしたい!”という価値がこの発表での本題で、

 Notwife は"オープン Web サービス"を目指します

と仰られました。 オープンにするために以下の三つのことを実践するそうです。

  • Notwife は github でコードを公開します
  • Notwife は Pivotal Tracker で計画・進捗・展望を公開します
  • Notwife は Lingr での議論を公開します

ではなぜこのようなことをするのでしょうか。それは、 個人で開発するものは、その人が止まると改良が止まってしまうこと、 フリーソフトウェアの潮流として FLOSS (Free/Libre and Open Source Software) があることを挙げられ、 個人で開発を行うような Web サービスでもこの潮流に乗れるのではないかと考えられたからのようです。

目指すべきオープン Web サービスの光として、 日本 Ruby 会議の公式ページ rubykaigi.org を例に挙げられました この rubykaigi.org というサイトは、実際に動くコードが github で公開されていてとても参考になること、 Github や Pivotal Tracker、IRC というツールを用いてコミュニケーションの大事さを学んだことや、 良さを生み出す何かがありそう というこれらの良さに刺激を受けて、 より良い物を作るために、Notwife では開発を”開いてやってみる”実験を行うとのことでした。

開発に興味を持たれた方も多いようで、これからの Notwife と Web サービスの開発のあり方に 期待させてくれるお話でした。

「ご自宅用ツール間同期メカニズム兼ストレージのご提案 」 - 関将俊 (@m_seki) - druby.org

: sapporo03_8.jpeg

分散オブジェクト技術の Ruby 実装である dRuby の作者である関さんが、Drop についてお話してくれました。 Drop は Rinda の実用的な応用的の 1 つとのことです。 Drop が一番似ているものとして Twitter のタイムラインを挙げていただきました。

Drop ができることは以下の3つです。

  • 覚える
  • 思い出す
  • 待つ

まず「覚える」についてですが、これはキーを指定しないで保存する KVS のイメージだそうです。 キーを指定しない代わりに受け付けた時刻がキーとなって、このキーが保存操作の戻り値となっています。 またこのオブジェクトにタグをつけて、オブジェクトにグルーピングすることができます。 Drop の内部ではオブジェクトは保存された時系列で並ぶそうです。

つぎに「思い出す」です。 オブジェクトを覚えた際にキーが返ってくるので任意のオブジェクトを思い出すことができますし、キーが時刻なので時刻を指定して思い出すこともできます。 また思い出す操作には複数の API が用意されていて、以下のように様々な思い出し方ができるそうです。

  • 時刻を指定して思い出す
  • 特定の時刻より後に追加されたものを思い出す
  • 時間軸にそって前後にブラウズする
  • 覚える際に指定したタグでフィルタする

最後に「待つ」です。 これは新たしくオブジェクトを覚えるのを待つという操作です。 指定した時刻よりも後に追加されたオブジェクトがないときはブロックして、新しいオブジェクトが追加されたら処理を再開します。 このときもタグでフィルタすることができるとのお話でした。

それと、少し変わった機能として「忘れられない」というものがあります。 一度覚えたオブジェクトは更新・削除ができません。 このおかげで、並行処理を行う際にトランザクションを全く気にしなくてよいとのことです。

関さんはこの Drop を、以下のような用途に利用されたそうです。

  • RWiki の全文検索
  • メッセージングシステム
  • 自分用のメモ

またメモとしての利用例として、irb からポケモンのステータスを入力して覚えさせたとのことでした。

Drop を作る際に大変だったのが、ユニークなキーを安価に作る点だそうです。 キーがもし重複してしまってもどちらか一方が少しだけ待って登録する方式を選択されたとのことです。

またその他の利用例として、ストリームとして使うというのも有効だそうです。 Drop は待つことができるので Drop からコールバックする必要がなく、またアプリケーション側からポーリングする必要もないので、このためアプリケーション側で簡単に外部イテレータを書けるとのことです。 この特性からブラウズ中の中断や再開が容易になるので、バッチ処理のキューとしても向いているそうです。

ただし実装の性質から、メモリ・ディスクの上限に依存するという限界も存在します。 このため発表タイトルにあるように、Drop はご自宅用を想定されているということです。

分散ストレージについて様々な可能性を感じさせてくれるお話で、実際に Drop を利用してみたいと思う方もたくさんいらっしゃったのではないでしょうか。

(RubyDrop という全く別のプロジェクトができたため、2010/12/23以降 Drop は Drip というプロジェクト名で公開されています。)

「Railsアプリ開発 野生のカン」- 大場 寧子 (@nay3) - 株式会社 万葉

: sapporo03_9.jpeg

株式会社万葉で社長を勤められている大場さんがお話してくれました。

コードレビューは他人のコード見るための重要な機会なので

"どういった箇所を重要視してレビューするか" ということを通じて、

Rails アプリを作る際のプラクティスを丁寧に説明してくれました。

大場さんはコードレビューを行うときには設計資料から目を通すとのことです。 この設計資料に明確なゴールが書かれていることがとても大事であり、 実装の前に設計の構想がしっかりと練られていることがレビューの前提だそうです。

以下のようなポイントを注意してチェックしているそうです。

  • フィルタメソッドの指定は only を使う
  • メソッドの可視性を正しく設定する
  • コントローラのアクション内で独自例外処理を行わない
  • パラメータのチェックや加工処理はモデルに書く
  • 不要な SQL が発行されないようにする
  • フィルタメソッドには戻り値を記述する

また、「ガラスの仮面」のワンシーンを用いた RESTful な URL 設計の説明には会場が沸きました。

大場さんが伝えてくれたことは次のようなことです。

  • 未来に制約を生まないシンプルなコードを書く。
  • 自分ではない誰かがソースコードを見たときでもすぐに理解できるようにしておく。

集合体の一部としてコードを書くことの大切さをしっかりと教えてくれた発表でした。

「 私のプロフィール」高橋征義 (@takahashim) - 株式会社達人出版会/日本Rubyの会会長

: sapporo03_10.jpeg

高橋さん個人のお話ということで、達人出版会とそこに至るまでの流れについてのお話をしてもらいました。

発表タイトルの「わたしのプロフィール」というのも片桐麻美さんの曲名からの引用だそうで、高橋さんの大学生時代のエピソードから始まりました。

達人出版会は高橋さんの設立された会社です。

達人出版会では著者からもらった原稿を編集・組版してそれを販売するという事業を行っています。 電子書籍ということで、電子化のメリットを活かすことを目指しているそうです。 達人出版会では開発支援環境を書籍製作に応用するということで以下の 3 つを作成しています。

  1. 執筆支援環境
  2. 組版システム
  3. 販売サイト

まず「執筆支援環境」についてですが、これは Redmine と git で構築しています。 git を利用するメリットは原稿ファイルが破損した際でも容易に復元できるということです。 git に関しては「gitosis」という、リポジトリの管理やアクセス制御などを簡単に行えるようにするツールを利用されているそうです。 gitosis を利用して執筆者・編集者・レビュアにそれぞれアカウントを発行して文書の閲覧・編集を行っていらっしゃるそうです。

次に「組版システム」についてです。 1 つの原稿から PDF と EPUB の両方を生成するために「ReVIEW」を利用しています。 ReVIEW は書籍執筆用マークアップ言語で、元原稿からコマンドを利用して各ファイルを生成しているそうです。

この生成された電子書籍を販売するための「販売サイト」ですが、 こちらはデジタルデータダウンロードと対面販売が行えるようになっているとのことです。 こちらのサイトはもちろん Rails を利用して構築されています。

またここからは、今現在に至るまでの高橋さんの自身のお話をされました。

学生のころからスクリプト言語である AWK を授業で利用したり、 ミステリ小説を読んだり、サークルのサイトの作成、イベント運営の活動をされていたそうです。 このころから、Ruby を使い始めていたそうです。

就職した後も本読みのイベントを企画されたそうです。

このような経緯が、RubyKaigi につながる経験となったとのことです。

"何をしても無駄になることはない"
というより、
"無駄にならない道を選べる"

今までやってきたこととはまったく別の分野に持っていっても、何か役立たせられるということもやればできる。 それを選ぶかどうかというのは自分次第なので、みなさんもよい人生を選択してください。 というメッセージをいただきました。

「There Is No Spoon:Revisited」 - 角谷 信太郎 (@kakutani) - (株)永和システムマネジメント、rubykaigi.org

: sapporo03_11.jpeg

角谷さんは今回 RubyKaigi2010 での発表時に、話し切れなかった内容をこの札幌 Ruby 会議 03 で語るということで これからの Ruby コミュニティを考えるための材料としての、これまでの Ruby コミュニティでの自身の活動、経験を通しての思いや考えを語られていました。

発表には非常に多くの内容が詰まっていました。その中の大きな話題のひとつに Dave Thomas から 2007 年の RubyKaigi の時に出された宿題とその回答がありました。 その宿題とはその時の Rubykaigi の keynote で話されたもので次のような内容でした。

Ruby にはこれまで仲間内で大切にしてきた、次のような価値観がある。

  • Be nice to developers 開発者にやさしく
  • Be clear and readable わかりやすく、読みやすく
  • Be flexible and agile 柔軟かつアジャイルに
  • Be open オープンに

そしてこれから多くの人が Ruby を使い始め、世界が変わっていく。もはや孤島ではない。その時にどうするべきか。 自分たちのやり方を大切にしつつ、彼らに学ぼう。その人達に Ruby の価値感を伝えて Happy にしていこう。

そういう宿題があり、それに対しての中間レポート的な返答がこの発表であるとのことでした。 それに対する角谷さんの答えは

"I come here not to how good RubyKaigi is,
but to thank RubyKaigi that made my life much better."
「ここにきて Rubykaigi がどれだけ素晴らしいかという話をしてもダメで
私にとって RubyKaigi がなんだったのか」というのを皆とシェアし、それをうけて皆がなにかを考える。

という回答でした。そして角谷さんにとっての RubyKaigi が色々な側面から語られます。 その中でひとつの主題が「Ruby has “Quality”」でした。 ここでいう Quality とは「禅とオートバイ修理技術」に記載されている言葉で、 論理と感情、客観、主観などの人が認識を持つ、その前の段階で直感的に感じてしまう 「人と物とのつながりを表す言葉」とのことでした。

そして発表の中では繰り返し Ruby のもつ Quality が色々な形で提示されます。 それは今年の Rubyconf で keynote を行った 3 人、Dave Thomas, David Heinemeier Hansson, そして matz の言葉。 また RubyKaigi2010 で keynote を話した Chad Fowler の書いた記事。あるいは 2009 年に松江で開かれた Ruby World Conference での Tim Bray, Bruce A.Tate の言葉。 様々な形をとって、Ruby にはうまく説明できないが、価値がある、Quality があるということが示されます。

もう一つ繰り返し提示されるものとして、Quality へとつづく「門」が提示されます。 Christopher Alexander の著書「時を超えた建設の道」に記された言葉で

"Once we have built the gate,
we can pass through it to the practice of the timeless way."
「いいものに通じるための門を立てれば、そこをくぐって時を超えた道を実践していける」

この「門」が角谷さんにとっては RubyKaigi であり、この札幌 Ruby 会議 03 や 全国で 19 回開かれた地域 Ruby 会議や Asakusa.rb もまた「門」であると説明を行います。 高橋会長のるびま 28 号巻頭言からの引用でコミュニティとはあなたである。あなたみたいな人たちの集まりがコミュニティである、ということが語られ、ひとりひとりが感じている価値、楽しさへと通じる門を立ててほしいというメッセージが届けられます。

また「門」を建てるにあたって Ruby を取り巻く現実の砂漠である環境の説明と、それに対する心構えが示されます。 spoon を曲げるのではない、spoon はなく。自分を曲げる、自分を変えるのだというのがひとつ。 “Results are not the point.” 最初から今いるところを目指していたわけではない。 できることを積み重ねていく過程の方が大事であり、目の前のできることをやっていることが大事ということを繰り返し訴えられてました。

角谷さんにとっての RubyKaigi は「一年間、毎年毎年 Ruby を使って自分が楽しい、幸せな気持ちになったのを 作った人たちに恩返し、感謝をするための取り組みであり、だからその過程はなによりも楽しいと語り 最後はその全ての原因をつくった matz へのお礼の言葉で締められました。

自分にできることは何かと考えさせられ、また多くの人から価値を受け取っているのだということを改めて気付かされる発表でした。発表の雰囲気などを含めて全てを語ることはできませんので、すこしでも刺激を受けるものがあった方は是非動画などを御覧ください。この発表を聞いたみなさんからまた Ruby を使った楽しさが広がっていく、そう感じられる発表でした。

写真の提供

@koichirooさん 撮影 http://www.flickr.com/photos/koichiroo/sets/72157625433146321/

@bokusamaさん 撮影 http://www.flickr.com/photos/bokusama/sets/72157625418397717/

著者について

菅井祐太朗

北海道の学生 IT 勉強会を盛り上げる LOCAL 学生部に所属。春からは社会人に

佐藤竜之介

Sapporo.js という勉強会をやってます。職場でも Ruby の布教活動中。

前鼻毅

quanp の中の人。最近は Objective-C を使って Ruby の良さを再実感する日々を過ごしています。