書いた人: monya_kata
RejectKaigi2008 におけるかくたにさんの基調講演「 RegionalRuby 会議のご提案」で開催地候補に「仙台」と名指ししていただいてから約 6 ヶ月。東北の Rubyist が中心となって実行委員会が結成され、仙台 Ruby 会議 01 がついに開催されました。
冬の仙台、午後から小雪が舞う一日でしたが、東北各地からそして全国から、寒さをものともせず Rubyist 達が集まりました。会場は熱気に溢れており、OSC2009Sendai の中でも参加者の数は最多でした。
仙台 Ruby 会議 01 の web ではちょっと工夫して東北らしさを出しています。 まず、LT を含め発表者の方々には、発表内容の他に「東北で一言」をお願いしました。皆さんと東北との関係、東北への思い入れを知ることができます。
また、会場となる仙台の「牛タン情報」「お土産情報」「地酒情報」「たい焼き情報」などが充実しています。仙台 Ruby 会議 01 が終わっても是非お役立てください!
秋田県合川町出身、福島で Ruby で起業した有限会社ラビックスの藤岡さん。Ruby のコミッタとして担当されている cgi.rb 関連、さらに Ruby1.9 の M17N についてのお話です。
cgi.rb のメンテナになった過程とともに、cgi.rb の現状を説明。cgi.rb は様々な人に dis られ Matz さんにも見捨てられかけていたそうですが、藤岡さんは Rails 以前から Ruby での Web アプリに使っていたため「まだ使いたい!」と、メンテナになったそうです。1.9 の cgi.rb は多くの改良を加える必要がありました。
1.9 での cgi.rb の改良点、変更点の説明です。大まかな変更は、テストの追加、CGI.new の際にエンコーディング指定、CGI.new にブロックを渡せる、マルチパートの受け取りが String になった、など。さらに機能追加、スピードアップなど今後もさらに改良を加えていきます。
続いて Ruby1.9 での Multilingualization について、どのように変わったかの説明がありました。注意すべき点は以下の通りです。
具体的な Ruby1.9 対応として tDiary を取り上げる予定でしたが、tDiary が 1.9 対応を表明したので、予定を変更して Hiki の対応例です。
この手順で 1.9 でも動くようになりました。 レガシーウェブアプリを動かすポイントをまとめると、
上限をつけるように変更しました。
現在はこのままですが、変更できると思う。default external を default にしたほうがよいという流れになっている
青森県出身、岩手の盛岡で学生時代を過ごし、現在東京でお仕事されている須藤功平さん。「プログラミングが好きで、地方にいて、そして悶々としている人向け」です。仙台 Ruby 会議 01 で一番人気のセッションとなり、立ち見が出る程でした。
高校までパソコンやプログラミングは未経験。でも興味があったので、情報専門の学科がある岩手大学へ進学、大学院を含め 6 年間を過ごしました。大学から COZMIXNG という自由に使えるネットワーク・サーバスペースの運営に参加し、そこでソフトウェアを作成し公開しはじめました。代表的なものがプレゼンテーションソフトの Rabbit。「好きなこと」であるプログラミングを続けていたお陰で、奨学金返済が免除になったり、Google Summer of code で奨学金をもらえて「スーパーハッカー」と呼ばれるようになりました。
開発するソフトウェアは「自由」。それまで使ってきたソフトウェア同様、自由に実行、自由に改変、自由に配布できるものとしました。自由であることは、ソフトウェアを利用する人のみならず、作者としても、いいことがたくさんあります。
岩手での大学時代は、そんな日々を送る一方で悶々としていました。もっと濃い話がしたいのにまわりに話ができる人がいない。そこで東京に行ってイベントに参加したら、詳しい人がたくさんいて濃い話ができて、とてもいい思いができました。
イベントなどでいい思いをするためには、「◯◯の××です」と言えるようになっておくことが大事。通常は有名な人にまず挨拶しに行って、まず自己紹介に時間を取られてしまう。でもソフトウェアを開発していて「Rabbit の須藤です」というように言えると相手も自分の持っている知識がすぐわかるので、すぐに濃い話に入れます。もっといいのは、逆に話しかけられる立場になること。ただし、すぐにはそんな凄い人にはなれません。
凄くなるためには、「ここ」にいる間にすることがあります。「好きなこと」=「プログラミング」という前提ですので、 「好きなこと」を、続けてください。少しずつしか上達しなくても、手を動かし続けスキルアップしていくことが大事です。「好きなこと」を続けるとやる気を持続できるし、楽しい。そしてもっと好きになるかもしれません。
好きなことを、熱く語れる人と話していると楽しいし、見ていて「ああ、好きそうだな」という「ほわん」とした感じがあってイイ!です。
例えば大好きな「たいやき」。「たいやき好き!」と言い続けたらまわりに好きな人が集まり「たいやき部」ができました。たいやきツアーなど行われています。好き好きオーラを出し続けるといいことがあるんです。
すぐ皆さんにやって欲しいことは次の3つです。
そんな学生さんにピッタリなのが、クリアコードのインターンシップ。参加者募集中です。
Ruby 界隈でそのラブラブぶりが評判の大場夫妻の 公開ノロケ セッションです。夫の光一郎さんは、宮城県多賀城市出身です。東北生まれの NetBeans キャラクター「ねこび〜ん」T シャツのペアルックでお話いただきました。次々に明らかになる大場家のユニークな生活ぶりに会場は何度も笑いに包まれ、とても楽しい雰囲気でした。
家庭を持つエンジニアからは、時々悲痛な声が聞こえてきます。ある人は自由に本が買えない、ある人は休日に勉強会やコミュニティ活動に出かけづらい。そして、家でパソコンに向かっていると文句が。しかし、エンジニア同時で結婚すれば happy 。すべては円満解決なのです。
…… しかし夫婦といえども、エンジニアという共通点以外には異なる部分も多いのです。うまくやっていくための工夫は欠かせません。
仕事も家庭も両方合わせて人生である、と大場家ではとらえ、普通に「家庭に仕事を持ち込」みます。
また同業でないとできない技ですが、夫婦で同じ仕事に参加することもあります。そしてお互いの仕事で知り合った人を紹介しあい、飲み会なども可能であれば一緒に参加します。
寝起き、食事の時間だけでなく、同じ時間に同じ種類のことをするようにしています。毎日することは、好きなこと・そうでもないけどやらなきゃいけないこと・生きるために必要なこと……大体これらのカテゴリーに分類されます。お互いが違うカテゴリーのことをすると「カチン」と来ることがあるので、夫婦で大体このカテゴリは一致するようにしています。
実はこれ「ペアプログラミング」における緩い協力と共有に通じるものがあります。ただしお互い楽しいことをしすぎてしまい、しなければいけないことに手が付けられないうデメリットも。
生活の場所をそろえるため、大場家ではパソコンをリビングに置きました。パソコンに向かっている時間が一番長いので、いたって自然な選択です。部屋の性質上、本をたくさん置けないなど気になる点もありますが、機能やインテリアと折り合いをつけつつ、快適なリビングにしています。
「好きなこと」は夫婦で違うこともありますが、それを理解するように努めています。理解できなくても「好きなんだ」と認め、相手が好きなことをしていることを喜んであげるのが大切。具体的には
家事なども好きなことベース。例えば寧子さんは食事を作るのが好きだけど、片付けは苦手。そこで片付けは光一郎さんが、というように分業しています。
実は Ruby on Rails の考え方、家庭生活にも役立つ部分がたくさんあります。
工夫して生活しても、どうしても問題が起きることがあります。そんなときにこれさえあれば大丈夫「適切な例外処理」。 失敗してもうまく後処理してリカバリすれば、前よりも仲良くなれます。
Rails やプログラミングの tips は、生活においても役に立つことが多く、プログラミングは人生の縮小版と言ってもいいかもしれません。よいと言われる部分は家庭生活にもあてはめて考えてみてはいかがでしょうか。
諸橋さんは宮城県の海沿いの北の町、岩手に近い気仙沼の出身で、大学から仙台で過ごしました。仙台では人生で一番楽しい時期を過ごし、仙台が大好き!だそうです。
Rails のテスト環境の歴史を振り返ります。Rails は始めから Unit Test、Functional Test が含まれ TDD に適したフレームワークと言われていました。
その後、RSpec が使用されるようになり、また Rails 自体にも Integration Test の機能も含まれるようになります。RSpec は BDD をやりやすくするツールで、非常に便利。しかし、Integration Test の方は書くのが難しく使いづらい。RSpec では Integration Test のような機能には対応していないため、統合テストは自動化できず手作業で実行していました。
そこに Cucumber が登場しました。Cucumber は「プレーンテキストドキュメントに対応したコードを実行するツール」です。
という手順で作成したものを実行してくれます。Webrat を使用することで、link をたどったりボタンをクリックしたりといった動作を DSL で記述することができ大変便利です。仕事で使ったものを公開しているので、是非皆さん使ってください。日本語も馴染むので、書きやすいし、読み易いです。
メリットは
ただし Integration Test と同様の限界もあります。JavaScript や CSS のテストはできません。将来的には Johnson でできるようになるかもしれません。対応できない部分は Selenium など他の手段でカバーします。
このようにテスト環境がだいぶ変わって来た中の Rails の勝ちパターンは、ロジックのほとんどを model に寄せて、controller や view をなるべく薄くすることと考えています。海外の人でも同意見の方がいました。
現在のテスト環境は、頑張ってロジックを model に寄せて、model は RSpec でテストし、controller や view は Cucumber で一気にテストするという方法をとっています。今後この方向で試してみたら良いのではないでしょうか。
Cucumber の公式サイトに、紙芝居のように開発サイクルが書いてあります。通常の TDD のサイクルに加え、最後に「お金を稼げるまで繰り返す」と、あります。ビジネスまで考えている姿勢がとてもかっこいいと思いました。 アジャイルな開発をしていく上で、Cucumber と RSpec を使用していくと、TDD のサイクルがキレイに回っていきそうです。
納品ドキュメントのフォーマットという点では、なんとかコンバートして対応可能。内容については、お客様と合意するには充分すぎる位。プレーンテキストなので、お客様の担当者と一緒に書いて、内容を詰めていくというのも可能になってくる。
表記の違いがそんなに問題になったことはない。テストのために改めて書く必要があるのはアプリーケーション独自の部分で、それはデータのセットアップが主。そこは個別に好きなように記述している。実際に動かすところの手続き部分は Webrat が提供しており、重要な部分は、あまり書き足すことがない。基本的に、既にあるもののステップの繰り返しのみで充分。
できない。そこだけ手で確認。
認証が難しい。OpenID は頑張った。独自の SSO は厳しい。
悪くない。修正が必要な部分は最小限。
CO カバレッジは 80% は余裕、90% も余裕で行けるのではないか。
北は北海道、南は福岡から、8 名の方々が集まってくれました。
仙台 Ruby 会議 01 開催に至るまでの、Ruby 関係者が織りなす数々のドラマ、汗、涙……。東北には Ruby だけでなく scala、Python、PHP、数々の開発者コミュニティ、勉強会があるので是非皆さん参加してください。
日本 Ruby の会では色々なプロジェクトが立ち上がっています。でも人手が足りません。Regional RubyKaigi、RubyKaigi2009、るびま、るりま……開発以外にも貢献することがたくさんあります。是非協力してください。
JRuby の最新マイナー機能、1.9 対応、NVM、FFI についての紹介でした。
工場の機械などの制御装置 PLC はプログラミングが特殊で、編集がとても大変です。そこで Ruby をまねた構文を入力し、フォームを送信するとダウンロードしてラダーとして使用できる、Fun Ladder! を作り公開しました。
福岡では今 Ruby が盛り上がっています。九州 Ruby 会議 01 では 200 名を超える参加者がありました。 しかし、実際仕事で Ruby を使っているのは数社ではないでしょうか。 受託開発が中心になってしまうため、他の言語、フレームワークになってしまいがち。受託の泥沼からどうやって脱却するのか、どうやってこれから生きて行くのか、地方エンジニアの皆さんぜひ一緒に考えていきましょう。
Ruby の楽しさはとても価値があります。Ruby で仕事すると超楽しい。わくわくし、あっという間に一日がすぎます。楽しい状態をつくりあげ、こだわりではなく愛情を持つこと、それがプログラマとして生き残るための戦略だと考えています。
IPA「Ruby 適用性調査」を行っています。「Ruby の潜在的ユーザに向けた提案」の報告に向けて、既存の Ruby 企業、あるいは先進的な Ruby 開発者インタビューをしたいと考えています。しかし回答者が少なく、困っています。聞きにきて欲しいという企業、開発者を募集中です。
Rails 2.3 ではアプリケーションに近いコードを再利用する仕組みができています。Web プログラマが作るのはデータという「乗客」を乗せる「電車」を作ること。この電車をもっと早く、確実に走らせるには「車体」を再利用しよう、という方向への進化です。 プログラマは「メタ (アプリケーションをメタレベルで作っていく人) 」と「ベタ (そのつくられたメタアプリケーションを使って業務ロジックを作っていく人) 」に分かれていくのではないでしょうか。