RegionalRubyKaigi レポート (27) とちぎ Ruby 会議 04
とちぎ Ruby 会議 04
はじめに
12 月 3 日(土)は前日の夜から冷たい雨が降っていました。当日朝は JR 宇都宮線ダイヤが乱れてたりして、参加者のみなさんが無事に着けるか心配でしたが、無事に開催することができました。
今回の会場は東那須野公民館で、ここはとちぎ Ruby 会議 01 が開催された場所でもあります。
とちぎ Ruby 会議 04 について
- 開催日
- 2011 年 12 月 3 日(土) 13:00 - 17:00
- 開催場所
- 栃木県那須塩原市東那須野公民館
- 開催母体
- とちぎ Ruby の会
- 参加者
- およそ 40 名
- 公式ページ
- とちぎ Ruby 会議 04
- 公式タグ
- tochigirubykaigi04
- 公式ハッシュタグ
- #tochirk
招待講演
松田明さん「オブジェクト指向ソーシャルコーディングスクリプト言語 Ruby」
松田さんの GitHub のアカウントは “amatsuda” で”あまつだ”さんと間違えられたことがあるそうです。苗字(まつだ)も名前(あきら)も普通すぎるためアカウント確保が難しいとのこと。
講演は二部構成でした。 第一部では Ruby と GitHub をめぐる歴史を紹介し、Ruby がいかにソーシャルコーディングに向いているかを説明されました。 第二部ではソーシャルコーディングをうまく実践するためのプラクティスを紹介されました。
第一部「オブジェクト指向ソーシャルコーディングスクリプト言語 Ruby 」
まず Ruby の成長と成長とともに表れた特徴について話されました。Ruby は日本で生まれアメリカで大きく成長したオブジェクト指向スクリプト言語で、日本の Ruby の歴史は逆輸入の歴史でもあったと述べます。RubyConf は 2001 年にはじまり日本 Ruby カンファレンスは 2006 年にはじまったし、Rails により Ruby でメシが食えるようになったと具体的な例をあげられます。 松田さん自身もここ数年は Rails でメシが食えていると述べられていました。
松田さんは GitHub にいち早く注目し WEB+DB PRESS Vol.48 に GitHub に関する記事を書いています。そこには GitHub はプロジェクトではなく人にフォーカスをあてコードで語り合う SNS とかかれています。 また Rails は開発のリポジトリを GitHub に移行し、Ruby (特に Rails)を使う人にとって Git は既に欠かせない存在になっていたそうです。
Ruby と GitHub の相性がよかったのは 2 つの理由があると述べます。Ruby はオブジェクト指向スクリプト言語であり、Matz は“Ruby is designed to be human-oriented.”と語っており、Ruby は可読性が高いソースコードを書けるようにデザインされています。 そしてソースコードでコミュニケーションをとる SNS (つまり GitHub)にとっては可読性は重要である、という点が相性が良い理由のひとつ。もうひとつは Ruby は人間が気分よくプログラミングするための言語であり、Ruby を使って話しかける相手はコンピュータではなく人間である。 そして対象の人間は自分だけでなくインターネットの向こうに繋がっている人もいる。Ruby でプログラムを書いて GitHub でコミュニケーションすることで、もっと気分よく楽しくなれるような関係にあることも相性の良さの理由というわけです。
Ruby Community では日本人の名前はあまり見かけないのは、日本の国民性が要因のひとつだろうと松田さんは考えます。英語が苦手とか地理的条件が大きな障害にはならないのだから、もっとコードを見せびらかしていいんじゃないか？東京とか栃木とか関係ないからチャンスでもあると述べました。
この話をうけて第 2 部では、うまく SNS で活動するためのプラクティスを紹介していきます。
第二部「Social Coding Practices」
ところが時間が足りなくなってしまったので、紹介できたのは用意したスライドの中のいくつかだけでした。
まずは Git を知ること。WEB+DB PRESS Vol.50 特集 2 の Junio C Hamano さんが書いた記事をおすすめしていました1。 つぎに良いコミットを目指そうというプラクティスでは”良い”とは何かを説明されました。 他人に読まれてはずかしくないコミットオブジェクトのつくりかた、コミットコメントの書き方を実例を交えて紹介しました。 “ソーシャルコーティングとしてのプログラミングとは日々のコミットを紡ぐ作業”だと述べられて、素敵な言いかただなと思いました。
また”人のバグを直す”というプラクティスを紹介されましたが、Rails はバグの宝庫なのでオススメ(?)だそうです。 人のプロダクトを使ってみてバグを踏んだら直して pull request するのはマナーとのことで、pull request するときのプラクティスも紹介されました。
自分のプロダクトを作ろうというプラクティスは難しく感じました。 しかし松田さんが作った Kaminari は自分が必要になったものを作って公開したら多くの人が使ってくれたというエピソードをあげました。 プロダクトの種は身近なところにある例だと思います。
最後に紹介されたプラクティスは自分は意外に感じましたが、”meet the people”。 普段のコミュニケーションがインターネット越しだからといって、インターネットだけが手段ではないし機会があれば人に会うのは良いこと、RubyConf や RailsConf に出かけてみるといいよ、ということでした。 言われてすぐに気づきましたが、このとちぎ RubyKaigi も人に会いたいとか話を聞きたいという気持ちの方々に来ていただいているんですよね。
松田さんといえば Rails のイメージが強いのですが、とちぎ Ruby では Rails の濃い話についていける人がすくなさそうな気配を感じられたのか、Ruby と GitHub によるソーシャルコーディングをすすめて、みんな恥ずかしがらずにコードを晒そうぜ!という強いメッセージを送っていただけました。
資料
オブジェクト指向ソーシャルコーディングスクリプト言語 Ruby
スポンサー講演
関将俊さん「Drip: instant replay」
予定されていた館野さんが残念ながら欠席となり、代役として関さんに講演していただきました。
館野さんとの出会いは RubyKaigi2006 で、館野さんがとても緊張して挨拶していたことを覚えているそうです。 当時、館野さんははてなスクリーンショットを dRuby を使って実装したというエピソードを披露されました。
関さんの講演ではおなじみですが幸福の王子本の宣伝からはじまりました。 ただし今回は”初刷”ではなく”日本先行発売”の幸福の王子本になっていました。 というのも”The dRuby Book”が Amazon で予約できるようになったためです。こちらの発売もたのしみですね(レポートを書いている時点では 2012 年 5 月発売予定)。
今回は RubyKaigi2011 の Drip の再演といくつかの補足を話されました。
Drip はストリーム指向のストレージであり、数年前の RubyKaigi でも話した PTupleSpace の別解であるそうです。Drip は追記のみで、かっこいいログといえる。 また失敗してもやりなおせる協調機構を提供してる点と、履歴付きの Hash に見える点が特徴であると紹介しました。
Drip の性質を説明するための比較対象として Queue と Hash をあげました。Queue との比較においては、Queue と似ている点と異なる点を説明しました。バッチ処理はたいがい失敗するが、途中からやりなおせるように作られている点が特徴的です。また Hash との比較においては、Drip は辞書のように見えるが、タグを使うことで履歴付きの Hash に見ることもできるとのことです。
次に Drip をつかった要素のブラウズ例を説明した後で、Drip の実装 (とくに key と index) についてお話されました。
関さんにとって識別子 (key) を安価に生成することは OODB の習作 (Koya) の頃からの主要なテーマであったそうです。Drip の key は時刻からつくられているので、tv_usec の分解能を持ちますが、それでもたりない場合は1加えた値になるそうです。このような方法で関さんの手元の環境ではそうそうぶつからないとのことです。こうしてつくられる key は Fixnum なので、安価に生成するというテーマのひとつの回答になったようです。注意する点としては key は情報が発生した時刻ではなく Drip が受け付けた時刻になるので、情報が発生した正確な時刻が必要な場合は要素に含めるべきですね。
index は効率よくブラウズできるように [key,value] と [tag,key] の二つをもっており、どちらも赤黒木(RBTree ,RubyTree ではないよ)を使って実装されているとのことです。
また Drip の応用例として ImmutableDrip (更新されないデータはソート済みの配列と BSearch でよさげ)をつくったことや Partitioning について話をされました。
Drip#keys と Drip#each は一度作ったけど消したそうです。なんとなく以前 RubyKaigi2010 で話されたカスタマイズは誘惑する(オプションを安易に増やすことは仕様の議論からの逃避)という話を思い出しました。API が多い方がよいわけではなく、意図した使い方を伝えるために API を減らすことがあるのですね。
資料
一般講演
休憩をはさんで一般講演となりました。
sasata299 (ささたつ)さん「クックパッドのものづくりについて」
ささたつさんはクックパッドでエンジニアで、最近は”NoSQL データベースファーストガイド”という本を執筆されました。
ささたつさんは最初に CookPad のミッション”毎日の料理を楽しみにすることで、心からの笑顔を増やす”を紹介しました。 クックパッドでのものづくりはこのミッションを達成する、そのことだけを考えて実行しているそうです。
クックパッドの社員は約 90 名で、そのうちの 4 割がエンジニアだそうです。エンジニアは大きく 「サービス開発」、「インフラ」、「開発基盤」 の 3 つのグループに分かれているそうです。
ものづくりにおいては”Best に集中”するそうです。 やりたい(情熱がある)＆得意(No.1 になれる)＆やるべき(儲かる仕組み)の3つを満たしているものが Best で、それ以外はやらないという意味だそうです。
Best なサービスを提供するための開発で使う “Emotion Oriented Goal Setting” を説明しました。 キャストを設定し、キャストの欲求を洗い出し、その欲求を満たす方法を考えるとのことです。 このようにざっくり書いてしまうと簡単な気がしますが、すべてのキャストの欲求を満たす解決方法を模索するのはとても難しいと述べられていました。 クックパッドではこのゴール設定に EOGS シートを使います。 このシートを使って、欲求→欲求は何をすれば満たされるか→どうやってそれを実現するか→成功のイメージはどんなものか→それを表す指標を決める、という内容をとことん考えるそうです。 最初に”シート”と聞いて穴埋めっぽいものを想像したのですが、ささたつさんの話ぶりからシートを土台にして提供するサービスについて熱心に話合う様子が感じられました。
後半はクックパッドの開発環境や使っている技術について説明されました。 ささたつさんは入社当日に「自腹で Mac 買ってこい」といわれ、なんてブラックなところに来てしまったのかと思ったそうです(後日、ちゃんと会社から支給されたそうです)。
またクックパッドのいいなと思うところは、おいしいごはんが食べられて、尊敬できるエンジニアと働けて、エンジニアの意思が尊重される、という 3 点をあげられました。 笑顔を増やすというクックパッドのミッションをささたつさんは楽しく遂行しているのだなという様子が伺える講演でした。
arton さん「演能」
arton さんは toRuby 勉強会拡大版(とちぎ RubyKaigi の前身(?))の頃から参加していただいています。
今回は “The Microsoft Conference 2011” で話された”オープンソースとマイクロソフトの良い関係 〜Ruby on Rails on Azure〜”をベースに、Windows 上での Ruby と Windows 上での Rails を中心にお話されました。
Ruby がサポートするプラットフォームはいくつかの段階にわかれていて、Supported なのは Debian GNU/Linux 4.0 on IA32 だけです。Windows は Best effort というレベルで、Mac OS X(Intel) などと同等であり高いレベルにあります。arton さんは usa さんをはじめとするメンテナの努力によるところが大きいとおっしゃいました。
Windows での Ruby のバイナリパッケージはいくつかあるが、おすすめは Windows の作法に則っている ActiveScriptRuby (arton さんが作成)とのことです。
拡張ライブラリをつくったり Gem の作成には自分でビルドできる環境が必要ですが、その環境はRuby 環境構築講座 Windows 編2を読んでつくる事ができ、Windows で Ruby を使って開発できることを伝えました。
次に話題は Rails に移り、arton さんが作成された Ennou (演能)というライブラリを紹介されました。Ruby on Rails による Web アプリケーションは起動に時間がかかるため、”仮想ホスト＋マルチプロセスで Rails は一度起動したら起動しっぱなし”が効率的であると考えられます。Windows には Http.sys というカーネルモードドライバがありますが、Ennou はこれを利用する Rack ハンドラでマルチプロセスを実現しています。
NougakuDo (能楽堂)は x64 ネイティブの Ruby と Ruby on Rails、その実行に必要なライブラリをパッケージしたものです。とちぎ Ruby 会議が行われた 12 月時点では Ruby1.9.3 で Rails は v3 系が入っており簡単に Rails アプリケーションの開発を始められるようになっているそうです。
さらに荒井省三さんが作成された能楽堂コンパニオンを紹介されました。これは NougakuDo を使って開発した Rails アプリを WindowsAzure にデプロイするツールだそうです。
このように Windows だからといって Ruby や Rails を諦める必要はない、Windows で Rails は運用できて、Windows Azure は Rails の運用プラットフォームとして有力な選択肢であると述べられました。
このあと時間が多少あまったので、arton さんは Ruby のマルチスレッドについて説明されました。 ご存知の方が多いかと思いますが、Ruby のマルチスレッドはグリーンスレッドなので普通は並列実行はないです。 ただし IO 待ちが発生したときだけ並列実行ができます。 これは Ruby の IO ライブラリは IO の待機状態になるときに GVL を解放しているためで、IO が完了したら GVL を待って実行を継続します3。 並行動作は C の拡張ライブラリで制御可能で、さきほど紹介した Ennou は並行動作に対応したライブラリだと付け加えられました。
Windows に詳しい arton さんならではの発表になりました。
資料 1
資料 2
http://msdn.microsoft.com/ja-jp/windowsazure/hh531535
村田賢太さん「続・Float is Legacy」
最後の一般講演は mrkn さんです。mrkn さんは CRuby のコミッタで bigdecimal や Mac OS X のメンテナをされいます。 数値系に興味があるということで、Float や Rational の話をされました。
まず Float について説明されました。Ruby の Float class は C でいう double のラッパで Boxing している。オブジェクトをアロケートする必要があるので生成コストは安くはない。また Float は実数の近似値であって、ほとんどの実数を正確に表せないという性質を詳しく説明されました。Ruby は小数の表記を Float として解釈するのだけれど、先に説明した Float の性質を知らない人によって Ruby の redmine にはたくさんの Float に関する issue があげられているそうです4。Float に関しては “What Every Computer Scientist Should Know About Floating-Point Arithmetic” を読んでほしいと仰っていました。
次に本題の Rational を紹介されました。Rational を使えば Float がもつ誤差なくすことができる。 けれでもリテラルがないので、知らない人には届かない。知っている人は Rational を使って書く、というジレンマがあります。そこで mrkn さんは小数表記を Rational に解釈してくれるパッチを書いたそうです。5
Float で発生していた誤差は Rational を使うと誤差なく計算できることを実例で説明されました。
誤差がないのは良いことだけど、その代償として速度を気にする方がいると思います。そこでベンチマークの結果を説明されました。結果は Raitonal は Float の 2 〜 5 倍遅い、C の double より2桁遅いという結果になったそうです。やっぱり C スゲー、Rational 遅いけど、Float も速くはないなという感想を持ったようです。
Float と Rational はその特徴から用途は異なります。多くの人にとっては Float より Rational の方が human oriented でその挙動は理解しやすいものであると思います。mrkn さんは Ruby が小数リテラルを Rational として解釈することの利点を述べ講演を終えました。
資料
http://speakerdeck.com/u/mrkn/p/float-is-legacy
勉強会
プログラムの最後は、月イチの toRuby 勉強会の続きを行いました。Ruby レシピブックを読んで写経するという(いつもの)スタイルです。 勉強しながらわからないことや訊いてみたいことを自由に発言し、知っている人がそれに答えるというやりとりがありました。 レシピブックの 181 〜 186 を一時間ほどかけて行い、エンコーディングに関する話題で盛り上がりました。 またクックパッドにはコーディングガイドってあるの?という質問には松田さんは「Rails のスタイルは意識する」と回答されていました。
おわりに
このように 4 回目となるとちぎ Ruby 会議は無事終了しました。今回はクックパッド社員の参加が多かったことと、はじめて栃木にきた人が多いことも印象に残りました。
本編がおわったあと懇親会は那須塩原駅近くのウニコというお店で行われました。 懇親会では toRuby メンバであるという自覚がある人がポジペを用意して喋りました。toRuby のポジペについては関さんから紹介がありましたが、toRuby の毎月の勉強会でのポジペの雰囲気を感じていただけたと思います。
そしてとちぎ Ruby 会議 04 は 2011 年最後の RegionalRubyKaigi となったようです。2011 年で RubyKaigi は終わってしまったので、2012 年はどこかの RegionalRubyKaigi に出かけてみてはいかがでしょうか?
書いた人
佐々木 揚(@you_ssk)