RubyKaigi2011 スペシャルレポート

日本Ruby会議2011 2日目レポート[更新終了]

この記事を読むのに必要な時間:およそ 18 分

関将俊さん「Drip: Persistent tuple space and stream.」

恒例の"まだ初刷買えます"のdRuby本紹介から始まった関さんの発表。今年は「もうすぐ英語版が出るので,英語版の初刷も是非」と少し変化球をつけ,さらに英語版には今回の発表で触れるDripに関する章も追加収録されている,との朗報も伝えていました。

PTupleSpaceの反省

関さんが過去のRubyKaigiで発表したPTupleSpaceは,TupleSpaceの永続化版です。そもそもTupleSpaceとは,分散したプログラム同士が協調してデータ(タプル)を置いたり(write⁠⁠,取ったり(take⁠⁠,読んだり(read)ができる空間を提供するもので,Rubyの標準ライブラリの一つRindaにも含まれています。

このTupleSpaceを永続化すれば,障害が起きても復元できてストレージのように使えるかもしれない,として実装してみたPTupleSpace。ところが,dRubyで扱う制約上,PTupleSpaceから見て別プロセスへ渡ってしまったタプルは復元できないし,takeの途中でクラッシュするとタプルが削除前だったのか削除後だったのかわからないなどの欠点がありました。

また耐障害性以外の点でも,ストレージとして見たときのTupleSpaceは辞書ではなく同一データの重複を許す「Bag」であり,キー重複を許さないHashを模倣するには全体をロックしてチェックすることが必要でコストが高くなってしまう,といった部分があるようでした。以上から,TupleSpaceを単純に永続化するだけではイケテナイと結論づけていました。

新機軸のDrip

そこで今回発表するのが,Dripです。関さん曰く,Dripとは「かっこいいログ⁠⁠。TupleSpaceとは違い追記はできてもデータの削除ができない点が特徴で,増加する番号(時刻を利用するが,同時にwriteが来た場合は片方に少しだけ数値を足す)が順にふってあるデータが並ぶ一次元のストリームのようなもの,とのことです。Dripではふってある番号を利用することがポイントで,例えばread時に番号を指定して「この番号以降をread」といった使い方をするようです。そして削除がないのでtakeがなく,Drip#writeとDrip#readがあるのですが,それ以外にもDrip#headという「最新の要素をn個くれ」というメソッドが追加されているとのことでした。

Dripでのクラッシュ時のデータの復元という点については,データに振ってある番号を覚えておけばそこから再開可能であるとのことです。また番号に時刻を利用しているので,時刻から推測してあたりをつけて再開することもできるのも嬉しい,といった点も挙げていました。

またDripはHashのように使えるかという点でも,データにタグをつけて保存し,そのタグがついたデータのうち最新のものを読み出すことで,それらしいことが可能になるとのことでした。ただしデータの削除はないから該当タグにnilを入れることで対応する等の工夫が必要,と述べていました。

結論としては,DripはTupleSpaceっぽさをバッサリ切り,協調機構から考え直したのがよかった,ということでした。最後に,実際にDripを使って動いているアプリとして,電力消費量のロガー&レポートがあるよ,という紹介もありました。

画像

画像

松田明さん「たのしいRails」

Railsのコントリビューターであり,Railsプラグインkaminariの作者でもある松田さんの発表です。 松田さんの発表と同じ時間の枠に,RubyGems の作者でもあり,Seattle.rbの創始者であるEricさんの発表があるということを説明し,⁠そちらを観に行かなくて大丈夫か?」との問いから始まりました。

ソーシャルコーディングとは

自分以外の誰かのために開発をしたりもくもくとキーボードを叩くのではなく,コンピュータの向こうにいる人に対する開発者の開発スタイルのことをソーシャルコーディングと呼んでいるそうです。 そして,RubyKaigiに来ているようなRubyプログラマーはRubyのコードを使ってコミュニケーションを取れる人たちですよね。今回でRubyKaigiも終わってしまうし, Rubyを使って新しいコミュニティに入っていこうという呼びかけを行いました。 そして,ソーシャルコーディングの力を高めるためにはどうしたら良いかというTipsを紹介しました。

Tips

  • Read Rails

毎朝,"git log"を読みましょう。毎朝読む新聞のようなもので,フレッシュな情報を得ることができると言います。logを見続けることで,Rails3.2やRails4.0に入る機能等をいち早く知ることができること,誰がどんなコミットをしているかがわかるようになってくると述べました。 また,自分が良いコードを書くための良い指標になりますし,コミットコメントの書き方も参考になると述べました。

  • 人々を知る

毎日git logを見ることで,常連のコミッタがどんな人かわかってくると言います。そこで気になる人が見つかったら, githubやtwitter,blog等を見てどんな人となりなのかを見にいってみることを勧めていました。

  • 良いコミットを知る

数々のコミットを見ることで,どんな単位が良いコミットかがわかるようになってくると言います。例えばテストを絶対に付けるということや,コミットコメントの一行目でどんな修正なのかが伝わるような書き方などが良い参考になるそうです。

  • English

ソーシャルコーディングを行う人にとっては必須の能力ですが,日本人は英語が苦手です。特に会話が苦手。そんな人には,RailsCastsのサイトを見ると良いかもしれない,と述べていました。動画が見られるので,ヒアリングの助けにもなるそうです。

  • Railsに貢献する

https://github.com/lifo/docrails/ はドキュメント専用のリポジトリなので,一番,失敗しても影響がありませんので気軽に関わることができるとのこと。すごく単純なスペルミスからでも良いのでコミットしていくと良いと述べました。

  • モンキーパッチをpullする

何かRails自体の不具合等を踏んでしまった場合,ブログに書いたり,そのRailsアプリのlibディレクトリに書いたままにしてませんか?と問います。そのような場合はfork railsして,pull requestを送ろう,と言います。モンキーパッチでは自分一人しか幸せになりませんが,pullして受け入れられれば,何人もの人が幸せになれると述べました。

  • 会いに行こう

ここまでのことをしていると,きっとRailsにコミットしているメンバー達に興味がわいてくるはずだと言います。そうしたら,ぜひ年に一度開催されるRails Confに参加してみよう,と説きます。今までネットワーク越しでしか知らなかった人と実際に会えるとのこと。

  • 本を書こう

本を書こうとすると,色々調べる必要があがあるし,バグを踏んだりしてハックしたりするので,大変勉強になるそうです。

というようなRailsについての話だったのですが,Rails以外にも有効なコミュニティに関わっていくためのTipsと言えるでしょう。

画像

画像

Eric Hodelさん「Writing Friendly Libraries」

seattle.rbのEric Hodelさんによる発表です。 ライブラリを作る際に気をつけるべきことを,作成手順をこと細かに追いながら説明しました。これまでに90以上のgemやライブラリを作ってきた経験から生まれたtipsであるので,ライブラリ開発者の方の参考になる内容でした。

Friendlyなライブラリを書くのに大切にしてほしいこと

一番大切にして欲しいこととして,楽しくやることを挙げました。やはり楽しさを持ってやらないことには続かないことだということはみなさんが強く感じられていることではないでしょうか。

その他にも,以下のtipsを挙げました。

  • 命名規則に従う
  • ディレクトリ構造を決める
  • 意味のあるバージョン番号をつける
  • 例外を実装する場合にサブクラスを使う
  • どうしてエラーになったのかエラーメッセージに書く
  • 例外にデータを含めてデバッグしやすくする
  • 振る舞いを定義してすべてをテストする
  • 後方互換性を確保するためにAPIと実装を分離する
  • 内部ドキュメントは書かず,動く例を提示する
  • フックを提供することで,ユーザがきれいに拡張できる
  • READMEで説明を載せ,バグトラッカーのURLを掲載する
  • 手動だと間違いが発生するので,自動的にリリース作業を行う

会場からの質問では,リリース時の文書としてニュースとチェンジログのうち,なぜニュースを勧めるのかという問いに対し,ニュースはユーザに向けて重要なことを提供するのに向いており,チェンジログは開発者向けの情報であることを提示しました。拡張のためにC言語でコードを書くよりも,Rubyで書くことを勧める理由を問う質問には,Cのラッパーと高速処理のうち,Ericさんはラッパーを書くことが多いため,ラッパーを書く際にはRubyで書きたいと話しました。

画像

画像

著者プロフィール

KaigiFreaks レポート班

KaigiFreaksとは,会場に来れなかった人にも,雰囲気や内容を楽しんでもらえるように動画収録や配信を行うことをミッションに,RubyKaigi2008で結成された特別編成チーム。

RubyKaigi2009からはgihyo.jpを中心にテキストと写真で現場の様子を伝えるレポート班が加わり,現在のKaigiFreaksは配信班とレポート班の2班編成。


三村益隆(みむらみつたか)

(株)永和システムマネジメントサービスプロバイディング事業部所属。Asakusa.rb & Rails勉強会@tokyo。このところRailsのお仕事をしています。言語好き。

blog:http://d.hatena.ne.jp/takkan_m
twitter:http://twitter.com/takkanm


すがわらまさのり

ハンドルネームはsugamasao。

Mitaka.rb や 若手IT勉強会に参加しています。仕事では自社プロダクトのデーモンの開発あたりでRubyを使ったりしています。伊坂幸太郎さんと荒木飛呂彦さんが好きです。

blog:http://d.hatena.ne.jp/seiunsky/
twitter:https://twitter.com/sugamasao


小松崎典之(こまつざきのりゆき)

ハンドルネームはO-Show。

RubyKaigi2010に参加したことで触発されRubyistを自称するようになる。ブログでRubyやGit関連記事の翻訳をあげています。もっとRubyとGitの情報の流通増えろ!と願ってやまない。

blog:http://keijinsonyaban.blogspot.com/
twitter:http://twitter.com/oshow


菅井祐太朗(すがいゆうたろう)

仕事でも Ruby を使えたらいいなぁと考えている新社会人LOCAL 所属。この春からAsakusa.rbにjoin。

twitter:http://twitter.com/hokkai7go


赤松祐希(あかまつゆうき)

2010年よりRuby on RailsでのWebアプリケーションの開発を中心にフリーランスのRubyプログラマとして活動中。最近はHaskellに興味を持ち出し、勉強しはじめている。

blog:http://ukstudio.jp/
twitter:http://twitter.com/ukstudio