RegionalRubyKaigi レポート (23) 大江戸 Ruby 会議 01

RegionalRubyKaigi レポート (23) 大江戸 Ruby 会議 01

:

開催日

2011-04-10(日) 13:25 - 16:30

開催場所

深川江戸資料館レクホール

主催

Asakusa.rb

協賛（敬称略）

Doorkeeper

株式会社 永和システムマネジメント

株式会社スケールアウト

ユナイテッド・デザインワークス株式会社

参加者

およそ 80 名

動画、資料

公式ページ

公式タグ

oedorubykaigi01

公式ハッシュタグ

#odrk01

ニュース記事

@knsmrメンバーによる、@ITの記事

はじめに

東京で 6 回目の開催となる地域 Ruby 会議「大江戸 Ruby 会議01」が 2011年4月10日に開催されました。この記事ではその様子について、レポートします。

「大江戸 Ruby 会議 01」は地域 Ruby の会のひとつであるAsakusa.rbの 100 回目の meetup¹ を 記念して、8 名の Asakusa.rb メンバーそれぞれが日々取り組んでいることに ついて発表する「生活発表会」となりました。

発表は「コミュニティについて」 という大きな話から、Ruby 処理系や Ruby のライブラリといった技術的な話、 Rails のテストや実運用の生々しい話までと盛りだくさんの内容で、 来場された皆様には楽しんでいただけたのではないでしょうか。

また当日は午後からの開始というスケジュールと、満開の桜や天候にも恵まれた こともあって、下町情緒あふれる会場周辺の観光や味覚を楽しまれた方も 多かったのではないでしょうか。こうしたことも「地域 Ruby 会議」の楽しみの 一つですね。

基調講演：100.times { Asakusa.rb.meetup! }, @a_matsuda

最初は、基調講演として Asakusa.rb の発起人である松田明さんからの発表です。

松田さんは日本人としてはトップクラスの Rails Contributor² として有名で、 最近では Rails3 の Pagination[^3]プラグインである Kaminari の作者として海外でも注目を集めています。

松田さんには Asakusa.rb でこれまで行われてきた 100 回の meetup を振り返りながら、「Asakusa.rb とは何か」ということに ついて考えを説明していただきました。

コミュニティとは何か

冒頭に「Asakusa.rb とはコミュニティである」と説明があり、 松田さんが考えるコミュニティではないものの例として「勉強会（何かを学びたい人の集まり）」 「セミナー（先生とお客様）」 「もくもく会（集まって各自が好きなことをやる）」「ただの飲み会」を挙げていました。

松田さんの考えでは、コミュニティとは仲間たちとコミュニケーションをするための場 であり、仲間とは「Ruby に貢献したいと思っている人たち」なのだそうです。 そうした人たちとのコミュニケーションの場が Asakusa.rb であり、 「お客様ではなく仲間になりに来てください」と Asakusa.rb の心構えを示しつつ、参加を呼びかけていました。

日本の Ruby コミュニティに不足していること

また松田さんは日本の Ruby コミュニティに不足していることとして「生の交流」「異文化交流」「発信」を挙げ、Asakusa.rb ではその役割を担うことを意図して立ち上げたとのことでした。

「生の交流」については、メーリングリストやチャットによる コミュニケーションだけでなく実際に会える場を作りたかったそうです。

「異文化交流」については、古くから Ruby を使ってきた人たちと、 最近になって Ruby on Rails をきっかけに Ruby を覚えた人たちとの間の ギャップを挙げ、それを埋めるための場を目指したとのことです。 またもうひとつのギャップとして日本の Rubyist と海外の Rubyist との 交流を挙げ、海外の Rubyist の来日に合わせて Asakusa.rb の meetup への 参加の呼びかけをしたことなどの紹介がありました。

「発信」については、Asakusa.rb がモデルとしている海外のコミュニティ 「seattle.rb」ではコミュニティを通じて作ったものを公開する文化が あることに触れ、GitHub[^4]にAsakusa.rb 名義の Oragnizational Account（組織向けアカウント） を作成し、 成果を公表していきたいとの抱負が語られました。

地域 Ruby コミュニティ運営のコツ

また松田さんが Asakusa.rb で行った「継続するコミュニティを運営するコツ」の紹介がありました。

まずは「仲間の集め方」。これは第一回目の meetup で「すごい人」を意図的に集めることで、 「すごい人がすごい人を呼ぶ」という良いサイクルを回すことができたとのことでした。

次に「開催する会場と日程」については、会場探しや予定のすり合わせに苦労しないために、 「決まった日（毎週火曜日）に決まった場所で、来れる人だけ来る」 というルールを決めてしまうことで運営が楽になったとのことでした。

最後に「今日は楽しんでいってください！」の言葉で講演を締めくくられました。

特別講演：Ruby 処理系の構想（妄想）, 笹田耕一

2 番目は特別講演として、現在の Ruby1.9 系の VM(Rubyプログラムを実行する仮想マシン)の開発者である笹田耕一さんからの発表です。

発表の冒頭で Dave Thomas 氏（書籍「達人プログラマー」等の著者）による RubyConf 2008 でのキーノートスピーチから 4 つの「Ruby の別実装」のプロジェクトの例を挙げ、 用途に応じた多様な Ruby 処理系の可能性について、笹田さんの構想を語っていただきました。

色々なところで Ruby を使えるように

最初のお話は色々なところで Ruby を使えるようにするための取り組みについてです。 現在は様々な機器にコンピュータが組み込まれているため、 「組み込みシステム向けの Ruby」についてのお話がありました。

組み込みシステム向けには軽量であることが求められるので、 「アプリケーションが使う／使わない機能を半自動的に組み込んだり 組み込まなかったりする」ツールを笹田さんの研修室の学生さんが 作っていることを紹介されていました。

また組み込み向けで重要な要素として「リアルタイム性」「省電力」 を挙げ、省電力の例としてはタイマースレッドがタイマーのフラグの カウントを上げる度に CPU 使用率が上がる問題に着目して、 IO 待ちなどの待機中には CPU を使わないようにするパッチ を作成したことを紹介されました。そして 「使用していない CPU コアの停止など、OS や C コンパイラ、Ruby の どのレイヤで省電力を考えるべきかが悩ましい。いいアイデアが あれば教えて欲しい」との呼びかけがありました。

組み込み以外でも様々なところで Ruby を使えるようにする取り組みとして、 Ruby で書いたプログラムを JavaScript や C#、スーパーコンピュータ向けの X10 言語などの他のプログラミング言語に変換する研究を紹介されていました。

より速く、より信頼性の高い Ruby

その次はより速く、より信頼性の高い Ruby を実現するための取り組みについてです。 まずは「高速な Ruby」を実現する、Ruby の「AOT コンパイラ[^5]」や、 Ruby プログラム中の 1 文だけを C 言語で書いて高速化できる「Ricsin」、 I/O の改善などによる高速化などを挙げられていました。

高速化のもう一つのアプローチとしての「並列実行する Ruby」については、 複数 VM による並列化や VM 間通信の例や、複数台のマシンでの分散環境 （いわゆるクラウド）向けとしての dRuby や Fairy などの 分散環境を扱う既存のライブラリを例として挙げて、もう少し手軽に 分散環境を利用できるものを実現したいとの構想を語られていました。

またハードウェアを利用した高速化については、 行列計算を GPGPU[^6] によって処理させたり、FPGA[^7] を利用して Ruby の GC[^8] を速くする話、またハードウェアと 密接に関わる OS を極力 Ruby だけを利用して作るプロジェクトなどの 紹介がありました。

信頼性という観点では、セグメンテーション違反[^9]が起きない Ruby や、 プログラマがバグを出せない Ruby、また型付きの Ruby（型を付けると 型チェックをしたり、付けた型を高速化のヒントにしたりする） といったことについて語られていました。

近々実現できそうなこと

笹田さんの研修室の学生さんからの成果として近く実現できそうな話として、 Ruby 用のリアルタイム性能プロファイラと、実用を意識した AOT コンパイラを 紹介されていました。

最後に冒頭の話を再度引用して、「まだまだ Ruby にできることはたくさんあるので、色々とやって行きたい。続きは 7 月の日本 Ruby会議 2011で発表する予定なので、見に来て下さい。」 とお話を締めくくられていました。

Ninja Talks #1: 大江戸HTTPクライアント絵巻 @nahi

httpclientの作者である中村浩士さんが 様々な Ruby の HTTP クライアントのライブラリを調べた結果を発表されました。

クライアントライブラリには実装の面から見て Ruby に標準添付されている net/http をベースとしたもの、独自実装しているもの、curl をベースとしたもの、ラッパーとしての実装があると分類し紹介されました。

ライブラリを使用する際の API から見た視点、proxy の対応状況や、SSL の対応状況等セキュリティに関する視点、国内海外サイトへのアクセスによるパフォーマンスに関する視点、と三つの視点から各ライブラリを詳細に比較されていました。

大江戸 HTTP クライアント絵巻というタイトルのとおり、絵巻のようになっている資料や、各クライアントの詳細な機能比較から注目を集めた Ninja Talk だったと言えるでしょう。

Ninja Talks #2: Rails と C で作る大量広告配信システム @yamaz

株式会社スケールアウトの代表を務める最速配信研究会の 山崎大輔さん が、起業してからCとRubyを使って大規模な広告配信システムを作るに至るまでの話について発表されました。 株式会社スケールアウトでは、安価に数十億アクセス/day を捌くことができる純国産の広告配信管理システム「ScaleAds」の提供を行っており、億を超えるようなアクセスに対するシステム開発やコンサルティングをされています。

まず ScaleAds のパフォーマンスがどのような方法で実現されているのかについて話されました。 広告の配信部分は、スピードが要求される部分は C で書き、柔軟性が要求される部分には Ruby を用いるという方法で実装されているそうです。集計処理についてはログ形式を工夫したり、分散処理を行うことで Ruby でも十分に対応できるそうです。広告データを管理するためのマスタテーブルの管理画面にはActiveScaffold[^10] を使用しているとのことでした。

それから、ScaleAds をつくるにあたってなぜ Ruby と Rails を選んだかについて話されました。会社設立当初、山崎さんは DB や Web プログラミングが苦手だったそうで、使いやすい ORM を探していたそうです。Perl の Catalyst や PHP、Java を経てきましたが使い勝手の良い ORM が見つからず、Ruby on Rails と AR(ActiveRecord) にたどり着いたとのことでした。

最後に、会社のスタートアップ当時から如何に素晴らしい Rubyist たちに恵まれていたかについて話され、現在もメンバーを募集中とのことでした。

Ninja Talks #3: “mission critical” なシステムでも使える Thread の作り方 @emorima

2004 年から Ruby を使い始められている江森真由美さんはRubyのイベントには初参加とのことです。大江戸 Ruby 会議 01 では Thread を安全に使う上でのポイントをユーモラスな例えを交えながら発表されました。

まず、Thread を作るうえでのポイントとして

• メインスレッドでは起動したスレッドの状態を監視する
• 起動したスレッドの状態が異常な場合、スレッドを再起動する

を挙げて実際のサンプルコードを交えて説明されました。

ただしこれだけでは ”mission critical” なシステムには不十分であるとして、より信頼性の高い実装方法やテストについて、ご自身の経験を元に話されました。 Thread の通常のステータス監視に加え、Thread の内で情報を更新・親スレッドへの報告を行わせ、異常があれば再起動するという方法を、実社会での週報・日報の提出になぞらえて紹介してくださいました。

また、Thread 内の無限ループのテスト方法として、テスト用の変数やメソッドを使ってでループの実行判定するという方法をとっているとのことでした。 Thread の使い方として非常に参考になるセッションでした。

Ninja Talks #4: エンドツーエンドテストは Capybara にお任せ! @hsbt

永和システムマネジメントの柴田博志さんに Rails3 のテスト環境の最前線について話していただきました。 読まれた方も多いと思いますが、WebDBPress に “Rails3 テスト最前線” という記事の執筆をされたようで、 記事の紹介をしていただきつつ、発表の本題に入っていきました。

Capybara 経由で RSpec や Cucumber を経由して使う Rails のエンドツーエンドテストを実行するのはとても大変だが、 テストフレームワークである Capybara と、どの Web ドライバーを組み合わせて使うかが悩ましいところのようで、 高速にテストをこなしてくれる Rack , 忠実にブラウザの動きを真似してテストできる HtmlUnit, Javascript をバシバシテストできるが jQuery を使うことができない Javascript Engine, 本当にブラウザが立ち上がってテストを行う Selenium Webdriver などがあります。 用途に応じて、ドライバを切り替えてもれなくテストしましょう！とのことでした。

Ninja Talks #5: RubyにおけるClean Code戦略 @ukstudio

フリーの Web プログラマとして活躍されている赤松祐希さんが、コードをより洗練させ、それを保つためのノウハウについて、ご自身の関わったことのある様々なプロジェクトの例を交えながら発表されました。 コードを洗練させる過程での様々な障壁に対して、熱意をもって頑張りましょう(コードを守りましょう)として、そのための戦略についていくつかの手段を紹介してくださいました。

まず、まだやっていないのであれば実践できることとして、

• テスト駆動開発
• リファクタリング
• 継続的インテグレーション

を挙げ、上司や会社がそれを許さない場合でも、まずは自分の開発環境の中からそれらを始めることもできるのだということを話されました。 汚いコードがあまりにも手に負えない場合には、チーム内でリファクタリングにかける時間を予め決めて継続的に実践する(例えば、1 日の 20% など)、普段ストーリーに着手する際、それに近しい部分のリファクタリングを一緒に進めていく、ボーイスカウトの「来た時よりも美しく」というルールを実践することで徐々に綺麗にしていくなどの方法があるとのことでした。

また、設計については S.O.L.I.D 原則の単一責任、オープン・クローズドの原則について、Ruby の Mixin やダックタイピング、ブロックなどを用いて紹介されました。

最後に、どうすれば Ruby らしく洗練されたコードを書けのか、もっとチームで議論しようと話されました。赤松さんがこれまで関わった仕事の中で、綺麗とは言えないコードのプロジェクトではコードについての議論があまりされなかったそうです。まずは自分を変えるところから始めて、個々で身につけたスキルをチームで共有し、議論し、コードを洗練する文化をつくっていこうというお話をされました。

Ninja Talks #6: 高速なテストサイクルを回すには id:secondlife/@hotchpotch

Rails のテストを高速化するための取り組みを、クックパッドの舘野祐一さんが発表されました。

まずテスト時間を短くする価値(長いことによる弊害)について紹介されました。 テスト時間が長くなると、待ち時間が増えるので、他の仕事に取り組むことができますが集中力が下がり、業務外のことに集中してしまったり、テストを行うための労力が大きくなるため、きちんとテストを通さなくなってしまうとのことでした。

テスト高速化の軸として、現在取り組んでいるコードに対する単一のテストを高速化する方向、テストのフィードバックを高速化する方法、プロジェクトのテスト全体を高速化する三つの方向を示されました。 (コードを綺麗にして高速化するという方法もあるが) 一つのテスト高速化ソリューションとして、 spork で初期化の際の環境ロードの高速化を行う方法と、spork の弱点を克服するためにご本人が作られた prefetch-rspec を使って高速化する手法を紹介されました。 prefetch-rspec は、sporkと 違い環境のロードを毎回行います。テストの途中で環境が変化することにも prefetch-rspec は対応していると言えます。

テストのフィードバック高速化を行うソリューションとして、autotest と watchr を紹介されました。どちらも自動的にテストを行うツールなのですが、autotest は特定の規約に沿ってファイルに変更があったらテストを行います。しかし、明示的にエラーになるとわかっていても実行されてしまい、テストサイクルが乱されると考えていた時期もあったそうです。watchr は /lib 以下などと、自分で指定した場所にあるソースコードが変更されたら、何を行うかということを簡潔に書くことができる DSL です。autotest よりも抽象化されており、テスト以外にもアクションが可能です。ここでは、rspec を呼び出しテストを行う例を示していただきました。

最後にクックパッドのテスト環境を例にとり、テスト全体を高速化するソリューションを紹介していただきました。Ruby Enterprise Edition を用いることで、メモリを食うようにパラメータを調整することでの高速化、他にもテストの並列実行やテストのリモート実行を組み合わせることで、42 倍(20 倍) 高速化ができたとのことでした。 テストの高速化で、テスト環境が快適になればいいですねとのメッセージでした。

懇親会

懇親会会場も「Asakusa らしい」ところというテーマのもと、明治 30 年創業の みの家で行いました。みの家は、とても「Asakusa らしい」店のたたずまいのお店でした。さくら鍋のお店ということもあり、好き嫌いがわかれないか、若干不安なところもありましたが、参加者のみなさんに「おいしかった」という言葉をいただけて安心しました。懇親会でも Ruby の話題は尽きず、「Ruby 1.9 で johnson 動かないけど、どうすればいいんだろう?」や「1.9 で Thread が固まるケースって、どんなのがあるんだろう?」などの会話が行なわれていました。

裏話になりますが、懇親会の募集ページに Asakusa.rb のポールメンバーが所属しており、そしてスポンサーである mobalean さんの Doorkeeper を使用しました。Doorkeeperを使用することで、事前に参加者から参加費を支払ってもらことができました。そのおかげで、参加者、幹事ともに懇親会でお金の心配という不安を忘れて楽しむことができました。

地域Ruby会議はどこから来るのか

(このセクションは大江戸 Ruby 会議01実行委員長のかくたにが書いています)

まず、準備、運営、講演、協賛、参加、感想エントリなどさまざまなかたちで協力いただいた皆さんに感謝します。ありがとうございました。かくたにが地域 Ruby 会議の実行委員長を務めたのは東京Ruby会議01以来(大江戸 Ruby 会議01は東京で 6 回目の地域 Ruby 会議です)。当時( 2 年半近く前)とは東京の Rubyist を取り巻く環境や状況も変わったなあ、という感慨についてだけでもだいぶ語れそうな気がするのですが、それはまた別の話。「東京の地域Ruby会議のナンバリングとこの先の予定(2011-02-05)」という私の Web 日記の記事はいくらか参考になるかもしれません。

今回、大江戸 Ruby 会議 01 の開催に至るまでの経緯をふりかえると、3 つの大事なものがあったと思います。

• 1. 名前
• 2. コミュニティ
• 3. 中核となるコンセプト

順番に分けて説明できればよかったのですが、とりとめもなく綴ります。

名前重要……だが、名前だけでは十分ではない

‘『プログラマが知るべき 97 のこと』’という書籍の日本語版ボーナストラックその 10 に我らがまつもとゆきひろさんがその名も「名前重要」というコラムを寄稿しています。曰く「『まず名前から入る』というのは、あまり語られていない秘訣としてもっと広く知られてもよいように思います」と。

ところが今回の地域 Ruby 会議については、名前だけでは十分ではありませんでした(そもそもまつもとさんのコラムはプログラミングの話なのではありますが)。良い名前が、あたかも森田創さんによる同書のボーナストラックその1にあるような「命を吹き込む魔法」となるには、然るべき人たちにその名前が届いてこそなのだなあ、ということを感じました。

調べてみたところ「大江戸 Ruby 会議01」という名前そのものを最初に思いついたのは 2010 年 3 月 4 日でした。これは RubyKaigi 2010よりも前のこと。ただ、この頃は本当に「言ってみただけ」でした。ただの思いつきが、具体的な地域 Ruby 会議のかたちになるにはもう少しかかります。

その後、2010 年 8 月 6日に、地域 Ruby 会議としての構想を tweet していたようです。「次の東京でやるRegional RubyKaigi の構想を思いついてしまったが、本家の名前を使うにはアレなので、Tokyu みたいにしようかな。それ用の名前は決めた。大江戸 Ruby 会議」。東京の地域 Ruby 会議として、東京 Ruby 会議があって、Tokyu Ruby 会議があるなら、さらに別の形態として大江戸 Ruby 会議もあっていいんじゃないか、と本気で思いはじめたのがこの頃。ですが、やはりこの頃はまだ名前だけです。

さらに時が進んで、toRuby の皆さんが「toRuby勉強会 50 回達成記念で地域 Ruby 会議を開催したい」ということでとちぎ Ruby 会議 03の開催が囁かれるようになった頃(るびま 0033 号のレポート記事)、そこに決定的なインスピレーションを得て「#asakusarb のだいたい 100 回記念に浅草 Ruby 会議 01 or 大江戸 Ruby 会議 01 をやるべきか」とtweetしています。これが 2010 年 12 月 2 日。その後に Asakusa.rb の meetup で、Askusa.rb のだいたい 100 回記念として大江戸 Ruby 会議01を Asakusa.rb がホストして開催することを提案したのでした。

「大江戸 Ruby 会議」という名前を聞いたときの Asakusa.rb メンバーたちの目の輝きは今でも忘れられません。しかし、この名前が Askausa.rb のメンバーたちに届くまでの間には、Tokyu.rb による 2 回の TokyuRubyKaigi と、toRuby の 50 回の勉強会があったからこそだという思いを新たにしています。

「詳細があふれてくるような、中核コンセプトが必要である」

kdmsnr さんによる「ユーザーストーリー ビギンズナイト」という素晴しい講演と資料があります。この中で知ったのですが、 Jim Highsmith こうが言っていたらしいです。「詳細があふれてくるような、中核コンセプトが必要である」と。

大江戸 Ruby 会議 01 は、名前と枠組みは決まったものの、しばらく Kaigi の準備は滞っていました。具体的なコンテンツを詰めていくにあたってのコンセプトが欠けていたからです。正確には「お代は見てのお帰り」というのはかなり初期から決まっていました。これは、登壇者に何らかのかたちで金銭的な還元をしたかったからです(結果、懇親会の参加費用はすべて賄うことができました。皆さんのご協力に感謝します)。それに「お代は見てのお帰り」は主催者と参加者との関わりかたについてのコンセプトであって、コンテンツを詰める枠組みにはなりませんでした。明らかに、私たちには「詳細があふれてくるような、中核コンセプトが必要」でした。

そんなある日、「発表会です(保育園でよくやってるやつ)という思いつき(2011 年 2 月 5 日)から始まって、__「大江戸 Ruby 会議は、Asakusa.rb という地域 Ruby コミュニティの参加メンバーの普段の『生活』の成果を、周囲の人たちに見てもらう」__というコンセプトに結実しました。ちなみに、このコンセプトは息子の保育園(当時)の生活発表会に参加したことがヒントになっています。

自分たちの「生活発表会」というコンセプトが決まれば、あとの諸々は勝手についてきた気がします。自分たちの発表会なんだから、自分たちが楽しめることだけをやる。プログラムについても、肩肘張らずに 1 hop でトークをお願いできる人たちに声をかければ十分にバラエティに富んだ人選をできることにも気づきました。@emorima メンバー(くノ一!)や、@yamaz メンバー(門前仲町!)、@nahi メンバー(絵巻!)あたりは、案外初遭遇だった方も多かったんじゃないでしょうか。今回は「 Asakusa.rb っぽい人選」ができたと自負しています。

協賛企業各社の皆さんについても同様のアプローチを取っています(協賛各社の所在地はそれぞれ、牛込神楽坂、上野御徒町、門前仲町、飯田橋。すべて都営大江戸線沿線!)。

主催:Asakusa.rb

今回の大江戸 Ruby 会議01 は、良い名前があって、他の地域 Ruby コミュニティ(Tokyu.rb, toRuby)の活動があって、さらに、私が属していると思える地域 Ruby コミュニティである Asakusa.rb の皆さんがあってこそ、やり遂げられたと思っています。講演、協賛、参加、感想エントリなどさまざまなかたちで協力いただいた皆さんに重ねて感謝の意を表しますが、ここでは特に、準備と運営に携わってくれた、Asakusa.rb のメンバーたちを mention しておきたいと思います。

主に運営方面を担当した皆さん

@takeshinoda メンバーは、大江戸線沿線での会場を圧倒的なスプレッドシート力でまとめてくれました。@hsbt メンバーと @takkanm メンバーは同僚のよしみで、それぞれ会計や懇親会幹事に加えて、数々の労働をこなしてくれました。@a_matsuda は Asakusa.rb ファウンダーとして、様ざまな点で相談にのってもらいました。

主に広報に関連する作業を担当した皆さん

@maztomo メンバーは、素敵な公式 Web サイトをデザインしてくれました。それだけじゃなく、カッコイイ名札のデザイン(ちゃんと両面に名前が書ける!)と裁断まで担当してくれました。@maicos メンバーは @OedoRubyKaigi のアイコンの表裏をデザインしてくれました。@iogi メンバーは、大江戸 KaigiFreaks として、圧倒的な配信力で公式動画を担当してくれました。るびまレポート班のお三方は、このセクション以外を立派な記事に仕上げてくれました。

大江戸 Ruby 会議02へ向けて

次回のこのメンバーたちでやるのかどうかはまだ不明ですが、次回の大江戸 Ruby 会議 02は、Asakusa.rb の meetup 200 回開催を記念して実施する予定です。それまでの間に、東京での地域 Ruby 会議がたくさん開催されているといいなと思っています(地域 Ruby 会議を開催することに興味ある方は、日本 Ruby の会の RegionalRubyKaigi のページを参照してください)。

写真の提供

@igaigaさん 撮影 http://www.flickr.com/photos/igaiga/sets/72157626390739909/

@hsbtさん 撮影 http://www.flickr.com/photos/hsbt/sets/72157626467412016/

書いた人たち

菅井祐太朗(@hokkai7go)

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

郡司啓(@gunjisatoshi)

Asakusa.rb のすみっこで Twitter 実況中継する係りの人。回り回って、るびまのレポートを書くことに。

寺田玄太郎(@hibariya)

Asakusa.rb のインターホン係(補欠)。(株)永和システムマネジメント勤務。Ruby のことが大好き。

角谷信太郎(@kakutani)

自称 Asakusa.rb 幹部。初代インターホン係。(株)永和システムマネジメント勤務。日本 Ruby の会理事。東京 Ruby 会議01 実行委員長。大江戸 Ruby 会議01 実行委員長。日本 Ruby 会議 2011 副実行委員長。

---

行った人のこと [^3]: たくさんのデータを複数ページに 自動的に分けて表示できる機能 [^4]: ソースコードを介したコミュニケーションができる、 プログラマのためのソーシャルコーディングサービス [^5]: Ahead-Of-Time、 プログラムの実行前に事前にコンパイルするコンパイラのこと [^6]: 画像プロセッサ(GPU)を使った汎用計算 [^7]: 自由に構成を変えられる集積回路 [^8]: ガベージコレクション。プログラムが使用しなくなったメモリ領域を自動的に開放する機能 [^9]: アクセスが許可されていないメモリに アクセスしようとすると発生するエラー [^10]: モデルの関連も加味した CRUD 画面を簡単に作ってくれるプラグイン。現時点では Rails3 非対応