RegionalRubyKaigi レポート (05) 仙台 Ruby 会議 01

RegionalRubyKaigi レポート (05) 仙台 Ruby 会議 01

書いた人: monya_kata

はじめに

RejectKaigi2008 におけるかくたにさんの基調講演「 RegionalRuby 会議のご提案」で開催地候補に「仙台」と名指ししていただいてから約 6 ヶ月。東北の Rubyist が中心となって実行委員会が結成され、仙台 Ruby 会議 01 がついに開催されました。

冬の仙台、午後から小雪が舞う一日でしたが、東北各地からそして全国から、寒さをものともせず Rubyist 達が集まりました。会場は熱気に溢れており、OSC2009Sendai の中でも参加者の数は最多でした。

仙台 Ruby 会議 01 の web

仙台 Ruby 会議 01 の web ではちょっと工夫して東北らしさを出しています。 まず、LT を含め発表者の方々には、発表内容の他に「東北で一言」をお願いしました。皆さんと東北との関係、東北への思い入れを知ることができます。

また、会場となる仙台の「牛タン情報」「お土産情報」「地酒情報」「たい焼き情報」などが充実しています。仙台 Ruby 会議 01 が終わっても是非お役立てください!

仙台 Ruby 会議 01 について

テーマ
東北の Rubyist を知る
日時
2009/1/24 (土) 10:15 〜 15:45 ※オープンソースカンファレンス 2009 Sendai と併催
場所
東北電子専門学校
主催
仙台 Ruby 会議 01 実行委員会
後援
日本 Ruby の会
Web
http://regional.rubykaigi.org/sendai01
公式タグ
sendairubykaigi01 (はてなブックマーク はてなキーワード)
Ustream
http://www.ustream.tv/sendairubykaigi
参加人数 (セッションごと)
約 45 〜 70 人

プログラム

tDiary などのレガシーウェブアプリを Ruby1.9 で動かす方法 ( 藤岡岳之 (xibbar) / 日本 Ruby の会 有限会社ラビックス)

資料 補足

秋田県合川町出身、福島で Ruby で起業した有限会社ラビックスの藤岡さん。Ruby のコミッタとして担当されている cgi.rb 関連、さらに Ruby1.9 の M17N についてのお話です。

いかに 1.9 の cgi.rb が腐っていたか

cgi.rb のメンテナになった過程とともに、cgi.rb の現状を説明。cgi.rb は様々な人に dis られ Matz さんにも見捨てられかけていたそうですが、藤岡さんは Rails 以前から Ruby での Web アプリに使っていたため「まだ使いたい!」と、メンテナになったそうです。1.9 の cgi.rb は多くの改良を加える必要がありました。

改良した結果、cgi.rb はこうなった

1.9 での cgi.rb の改良点、変更点の説明です。大まかな変更は、テストの追加、CGI.new の際にエンコーディング指定、CGI.new にブロックを渡せる、マルチパートの受け取りが String になった、など。さらに機能追加、スピードアップなど今後もさらに改良を加えていきます。

1.9.1 の M17N はこうなった

続いて Ruby1.9 での Multilingualization について、どのように変わったかの説明がありました。注意すべき点は以下の通りです。

  • String が encoding を持っている
  • データをファイルや DB に保存するときは、データなのか Encoding ごとなのか、意識する必要あり
  • 日本語を含む場合はマジックコメントをつける (マジコメる) 必要がある

レガシーアプリはこうやって動かせ

具体的な Ruby1.9 対応として tDiary を取り上げる予定でしたが、tDiary が 1.9 対応を表明したので、予定を変更して Hiki の対応例です。

  1. まずは、日本語の入ったソースにすべてマジックコメントを入れる
  2. default external を EUC-JP にする → この時点で表示は OK、しかし新規ページ作成時エラーに
  3. 受信する Encoding を CGI.new する時点で EUC-JP を指定
  4. Array.to_s が 1.9 で仕様変更しているのでそれに対応し修正
  5. PStore を独自拡張した部分、まるごとコメントアウト

この手順で 1.9 でも動くようになりました。 レガシーウェブアプリを動かすポイントをまとめると、

  • ひたすらマジコメる
  • Default external の encoding を意識
  • UTF-8 以外を使用するときは Accept Character Set を指定
  • あとは地道につぶす

全体的なまとめ

  1. cgi.rb は 1.9 でもちゃんと動きます
  2. Ruby1.9 では M17N でのハマりポイントに注意

質疑応答

Q1. マルチパートで受信したものを無条件にメモリ上に展開するとまずい場合もあるのでは?

上限をつけるように変更しました。

Q2. 受信するときのエンコーディング、default は変更できそうに思えますが?

現在はこのままですが、変更できると思う。default external を default にしたほうがよいという流れになっている

「まず好きなこと、そしてそれを続けること」 (須藤功平 / 株式会社クリアコード COZMIXNG)

青森県出身、岩手の盛岡で学生時代を過ごし、現在東京でお仕事されている須藤功平さん。「プログラミングが好きで、地方にいて、そして悶々としている人向け」です。仙台 Ruby 会議 01 で一番人気のセッションとなり、立ち見が出る程でした。

資料

これまでの歩み

高校までパソコンやプログラミングは未経験。でも興味があったので、情報専門の学科がある岩手大学へ進学、大学院を含め 6 年間を過ごしました。大学から COZMIXNG という自由に使えるネットワーク・サーバスペースの運営に参加し、そこでソフトウェアを作成し公開しはじめました。代表的なものがプレゼンテーションソフトの Rabbit。「好きなこと」であるプログラミングを続けていたお陰で、奨学金返済が免除になったり、Google Summer of code で奨学金をもらえて「スーパーハッカー」と呼ばれるようになりました。

開発するソフトウェアは「自由」。それまで使ってきたソフトウェア同様、自由に実行、自由に改変、自由に配布できるものとしました。自由であることは、ソフトウェアを利用する人のみならず、作者としても、いいことがたくさんあります。

岩手での大学時代は、そんな日々を送る一方で悶々としていました。もっと濃い話がしたいのにまわりに話ができる人がいない。そこで東京に行ってイベントに参加したら、詳しい人がたくさんいて濃い話ができて、とてもいい思いができました。

イベントなどでいい思いをするためには、「◯◯の××です」と言えるようになっておくことが大事。通常は有名な人にまず挨拶しに行って、まず自己紹介に時間を取られてしまう。でもソフトウェアを開発していて「Rabbit の須藤です」というように言えると相手も自分の持っている知識がすぐわかるので、すぐに濃い話に入れます。もっといいのは、逆に話しかけられる立場になること。ただし、すぐにはそんな凄い人にはなれません。

好きなことをし続ける

凄くなるためには、「ここ」にいる間にすることがあります。「好きなこと」=「プログラミング」という前提ですので、 「好きなこと」を、続けてください。少しずつしか上達しなくても、手を動かし続けスキルアップしていくことが大事です。「好きなこと」を続けるとやる気を持続できるし、楽しい。そしてもっと好きになるかもしれません。

好きなことを、熱く語れる人と話していると楽しいし、見ていて「ああ、好きそうだな」という「ほわん」とした感じがあってイイ!です。

例えば大好きな「たいやき」。「たいやき好き!」と言い続けたらまわりに好きな人が集まり「たいやき部」ができました。たいやきツアーなど行われています。好き好きオーラを出し続けるといいことがあるんです。

今日から始めよう

すぐ皆さんにやって欲しいことは次の3つです。

1) 作る
須藤さんにとっての Rabbit のように、自分で好きだと認識できるもの、そして自分が必要なものを作る。理想は「あの人が通ると道ができる」
2) 直す
デバッグはとても力がつくし、喜ばれ、結果ソフトが良くなる。理想は「流しのプログラマ」。
3) 参加する
ソフトウェアのコミュニティに参加すると、共通の話題があって、楽しくなりやすい。おすすめはテストを作ること。後回しになりがちのテストを書くことによって参加しやすいし、勉強になる。

そんな学生さんにピッタリなのが、クリアコードのインターンシップ。参加者募集中です。

最後に、おすすめしたいことのまとめ

  • 好きなことを続ける。結果はすぐにはでないけど続けていればついて来ます。
  • 機会があったら、いろんなことをやってみる。インターンシップに行ったり、RubyKaigi2009 に出たり。どこかで喋るときは、まず好きなことを喋ると熱く語れます。「好き好きオーラ」を放ち続けてください。

「Happy Life Hacking with Ruby on Rails 〜二人で育てる Ruby on Rails 〜」 (大場光一郎 / Akasaka.rb Meadowy.org、大場寧子 / 株式会社 万葉)

Ruby 界隈でそのラブラブぶりが評判の大場夫妻の 公開ノロケ セッションです。夫の光一郎さんは、宮城県多賀城市出身です。東北生まれの NetBeans キャラクター「ねこび〜ん」T シャツのペアルックでお話いただきました。次々に明らかになる大場家のユニークな生活ぶりに会場は何度も笑いに包まれ、とても楽しい雰囲気でした。

資料

エンジニアと家庭

家庭を持つエンジニアからは、時々悲痛な声が聞こえてきます。ある人は自由に本が買えない、ある人は休日に勉強会やコミュニティ活動に出かけづらい。そして、家でパソコンに向かっていると文句が。しかし、エンジニア同時で結婚すれば happy 。すべては円満解決なのです。

…… しかし夫婦といえども、エンジニアという共通点以外には異なる部分も多いのです。うまくやっていくための工夫は欠かせません。

(1) 家庭と仕事と家庭を区別しない

仕事も家庭も両方合わせて人生である、と大場家ではとらえ、普通に「家庭に仕事を持ち込」みます。

また同業でないとできない技ですが、夫婦で同じ仕事に参加することもあります。そしてお互いの仕事で知り合った人を紹介しあい、飲み会なども可能であれば一緒に参加します。

(2) 生活のリズムを会わせる

寝起き、食事の時間だけでなく、同じ時間に同じ種類のことをするようにしています。毎日することは、好きなこと・そうでもないけどやらなきゃいけないこと・生きるために必要なこと……大体これらのカテゴリーに分類されます。お互いが違うカテゴリーのことをすると「カチン」と来ることがあるので、夫婦で大体このカテゴリは一致するようにしています。

実はこれ「ペアプログラミング」における緩い協力と共有に通じるものがあります。ただしお互い楽しいことをしすぎてしまい、しなければいけないことに手が付けられないうデメリットも。

(3) 場所をそろえる

生活の場所をそろえるため、大場家ではパソコンをリビングに置きました。パソコンに向かっている時間が一番長いので、いたって自然な選択です。部屋の性質上、本をたくさん置けないなど気になる点もありますが、機能やインテリアと折り合いをつけつつ、快適なリビングにしています。

(4) 好きな事をする

「好きなこと」は夫婦で違うこともありますが、それを理解するように努めています。理解できなくても「好きなんだ」と認め、相手が好きなことをしていることを喜んであげるのが大切。具体的には

  • 本はどんどん買う (お互い好きなので)
  • Perfume を許す
  • ニコ動 (アイマス、初音ミク) を毎晩見ても許す。むしろ「自分で動画作れ」と Xbox とアイマスを誕生日にプレゼント
  • 一日中集中してゲームをしていても怒らない……この集中力がハックする時に生きるんだ!と、生暖かい目で見守る
  • たいやきが好きでもいい

家事なども好きなことベース。例えば寧子さんは食事を作るのが好きだけど、片付けは苦手。そこで片付けは光一郎さんが、というように分業しています。

プログラミングと家庭生活両方に役に立つ、Rails の考え方

実は Ruby on Rails の考え方、家庭生活にも役立つ部分がたくさんあります。

  • オブジェクト指向 → 個人主義。財布は別。二人で出し合った財布と個人の財布は別に運用
  • オープンクラス → 夫婦の情報が筒抜け。お互いの PC の設定も知り尽くしてる。ports の upgrade も勝手に
  • MVC → うまく分担。苦手なことを強いるのではなく、お互い得意なことをやる。例えばインフラ周りが光一郎さん、英語は寧子さん。
  • DRY → これについては、逆。PG の世界では繰り返しは悪ですが、「愛してる」は何度も言っていい
  • バージョンアップしつづける → Rails はバージョンアップが頻繁。しかし人間にとっては当たり前のこと。昔はあんなに仲良かったのに……ではなく、今仲良くすればいい。相手が変わったら自分も変わろう
  • CoC → よく、家庭の理想でいちいち言わなくても阿吽の呼吸で……と言いますが、むしろ設定重要、「親しき仲にも設定あり」

最後に

工夫して生活しても、どうしても問題が起きることがあります。そんなときにこれさえあれば大丈夫「適切な例外処理」。 失敗してもうまく後処理してリカバリすれば、前よりも仲良くなれます。

Rails やプログラミングの tips は、生活においても役に立つことが多く、プログラミングは人生の縮小版と言ってもいいかもしれません。よいと言われる部分は家庭生活にもあてはめて考えてみてはいかがでしょうか。

「Rails テスティング環境 2009 - Cucumber, Webrat and RSpec. -」 (諸橋恭介 / 株式会社永和システムマネジメント Rails勉強会@東京)

諸橋さんは宮城県の海沿いの北の町、岩手に近い気仙沼の出身で、大学から仙台で過ごしました。仙台では人生で一番楽しい時期を過ごし、仙台が大好き!だそうです。

資料

Cucumber を中心とした新しいテスト戦略

Rails のテスト環境の歴史を振り返ります。Rails は始めから Unit Test、Functional Test が含まれ TDD に適したフレームワークと言われていました。

その後、RSpec が使用されるようになり、また Rails 自体にも Integration Test の機能も含まれるようになります。RSpec は BDD をやりやすくするツールで、非常に便利。しかし、Integration Test の方は書くのが難しく使いづらい。RSpec では Integration Test のような機能には対応していないため、統合テストは自動化できず手作業で実行していました。

そこに Cucumber が登場しました。Cucumber は「プレーンテキストドキュメントに対応したコードを実行するツール」です。

  1. プレーンテキストを書く (feature)
  2. それを対応するRubyのコードに書き換える (step definitions)

という手順で作成したものを実行してくれます。Webrat を使用することで、link をたどったりボタンをクリックしたりといった動作を DSL で記述することができ大変便利です。仕事で使ったものを公開しているので、是非皆さん使ってください。日本語も馴染むので、書きやすいし、読み易いです。

メリットは

  • Rails アプリを外側からブラックボックステストできる
  • Webrat のお陰で簡単に記述できる

ただし Integration Test と同様の限界もあります。JavaScript や CSS のテストはできません。将来的には Johnson でできるようになるかもしれません。対応できない部分は Selenium など他の手段でカバーします。

このようにテスト環境がだいぶ変わって来た中の Rails の勝ちパターンは、ロジックのほとんどを model に寄せて、controller や view をなるべく薄くすることと考えています。海外の人でも同意見の方がいました。

現在のテスト環境は、頑張ってロジックを model に寄せて、model は RSpec でテストし、controller や view は Cucumber で一気にテストするという方法をとっています。今後この方向で試してみたら良いのではないでしょうか。

開発サイクルがどうなっていくのか?

Cucumber の公式サイトに、紙芝居のように開発サイクルが書いてあります。通常の TDD のサイクルに加え、最後に「お金を稼げるまで繰り返す」と、あります。ビジネスまで考えている姿勢がとてもかっこいいと思いました。 アジャイルな開発をしていく上で、Cucumber と RSpec を使用していくと、TDD のサイクルがキレイに回っていきそうです。

質疑応答

Q1. プレーンテキストで書いたものがテストで実行できるということは、プレーンテキスト自体が納品ドキュメントになるような世界を目指していると思われますが、実際現場での最近の傾向は?

納品ドキュメントのフォーマットという点では、なんとかコンバートして対応可能。内容については、お客様と合意するには充分すぎる位。プレーンテキストなので、お客様の担当者と一緒に書いて、内容を詰めていくというのも可能になってくる。

Q2. 複数メンバーで開発している場合、自然言語で書けるため表現が異なってしまうこともありうるのでは。表記のゆれを防ぐいいやり方は?

表記の違いがそんなに問題になったことはない。テストのために改めて書く必要があるのはアプリーケーション独自の部分で、それはデータのセットアップが主。そこは個別に好きなように記述している。実際に動かすところの手続き部分は Webrat が提供しており、重要な部分は、あまり書き足すことがない。基本的に、既にあるもののステップの繰り返しのみで充分。

意見
受託など大規模開発の場合、Excel で書かれた大量の仕様書がなくなるかというとそうはいかない。でも、Cucumber を使いはじめて、難しくない仕様の案件では簡単にテストを書いて動かせて……ということが可能になり、今わくわくしている所です。
意見
「controller を薄く」は、正しいし経験を積んだ人は皆そのようにしている。しかしそれを布教する際は注意が必要。controller のコードを減らし model のテストをすることだけを目的にしてとんでもないコードになったのを目撃したことがある。オブジェクト指向、MVC の文脈が浅い所では「controller を薄く」だけ言っていると誤って理解される可能性あり。

FAQ

1. AJAX のテストは可能?

できない。そこだけ手で確認。

2. Cucumber のハマりポイントは?

認証が難しい。OpenID は頑張った。独自の SSO は厳しい。

3. テストの変更コストは?

悪くない。修正が必要な部分は最小限。

4. テストの網羅性は?

CO カバレッジは 80% は余裕、90% も余裕で行けるのではないか。

Lightening Talks

北は北海道、南は福岡から、8 名の方々が集まってくれました。

「Java から Ruby へ」 (武田広幸/武田ソフト)

仙台 Ruby 会議 01 開催に至るまでの、Ruby 関係者が織りなす数々のドラマ、汗、涙……。東北には Ruby だけでなく scala、Python、PHP、数々の開発者コミュニティ、勉強会があるので是非皆さん参加してください。

「日本 Ruby の会のほうから来ました」 (角谷信太郎 / 日本Rubyの会 株式会社永和システムマネジメント ) 資料

日本 Ruby の会では色々なプロジェクトが立ち上がっています。でも人手が足りません。Regional RubyKaigi、RubyKaigi2009、るびま、るりま……開発以外にも貢献することがたくさんあります。是非協力してください。

「5 分で分かる JRuby 最新事情」 ( 高井直人 / Akasaka.rb) 資料

JRuby の最新マイナー機能、1.9 対応、NVM、FFI についての紹介でした。

「Ruby 構文まねて Fun Ladder! サイト作りました」 ( 伊藤勝良 / 有限会社伊藤ソフトデザイン)

工場の機械などの制御装置 PLC はプログラミングが特殊で、編集がとても大変です。そこで Ruby をまねた構文を入力し、フォームを送信するとダウンロードしてラダーとして使用できる、Fun Ladder! を作り公開しました。

「福岡に於ける Ruby 熱狂現象に関する一考察」 ( 新井俊一 / Rubyist 九州Asiajin、株式会社もぐら、有限会社メロートーン)

福岡では今 Ruby が盛り上がっています。九州 Ruby 会議 01 では 200 名を超える参加者がありました。 しかし、実際仕事で Ruby を使っているのは数社ではないでしょうか。 受託開発が中心になってしまうため、他の言語、フレームワークになってしまいがち。受託の泥沼からどうやって脱却するのか、どうやってこれから生きて行くのか、地方エンジニアの皆さんぜひ一緒に考えていきましょう。

「たのしい Ruby がすごい件について」 ( 島田浩二 / Ruby 札幌) 資料

Ruby の楽しさはとても価値があります。Ruby で仕事すると超楽しい。わくわくし、あっという間に一日がすぎます。楽しい状態をつくりあげ、こだわりではなく愛情を持つこと、それがプログラマとして生き残るための戦略だと考えています。

「IPA『自治体・企業等の情報システムへの Ruby 適用可能性に関する調査』御協力のお願い」 (橋本明彦 / みずほ情報総研株式会社)

IPA「Ruby 適用性調査」を行っています。「Ruby の潜在的ユーザに向けた提案」の報告に向けて、既存の Ruby 企業、あるいは先進的な Ruby 開発者インタビューをしたいと考えています。しかし回答者が少なく、困っています。聞きにきて欲しいという企業、開発者を募集中です。

「Rails 2.3 で 5 分で作るトランプゲーム(仮)」 (松田明 / Asakusa.rb) 資料

Rails 2.3 ではアプリケーションに近いコードを再利用する仕組みができています。Web プログラマが作るのはデータという「乗客」を乗せる「電車」を作ること。この電車をもっと早く、確実に走らせるには「車体」を再利用しよう、という方向への進化です。 プログラマは「メタ (アプリケーションをメタレベルで作っていく人) 」と「ベタ (そのつくられたメタアプリケーションを使って業務ロジックを作っていく人) 」に分かれていくのではないでしょうか。

書いた人

monya_kata
仙台市在住のフリーランス。色々なものを「創る人」でありたいと、Web を作ったりぬいぐるみを作ったり文章を書いたり絵を描いたり、たまにプログラム書いたりしています。今回レポート作成のために Ustream やプレゼン資料を見直して、仙台 Ruby 会議 01 の最高に楽しい時間を思い出すことができました。執筆の機会を与えてくださった関係者の皆様に感謝します。ありがとうございました。