RubyConf2011レポート

初稿：2011-11-28

1日目
2日目
3日目

1日目

How Getting Buff Can Make You a Better Rubyist

話した人: Rob Sanheim
書いた人: みうら

ストレッチから始まったのは、「健康」に関するセッションでした。両手を身体の前で合わせて力を入れるストレッチ(祈るようなポーズ)では、「through test…」などとジョークを交えながら世界のRubyist がストレッチを行う姿はとても壮観な光景でした。

食事や運動、休憩や瞑想など色々な事柄がこのセッションで触れられました。これを機会に身体に気遣ってなにか初めてみるのはいかがでしょうか？

Implementation of Ruby 1.9.3 and later

話した人: Koichi Sasada
書いた人: みうら

「Engine Yard is very Nice! Engine Yard is very Nice!」と大事な事を 2 回言うアイスブレイクから始まった笹田さんのセッション。 RubyKaigi でも発表されていた Ruby 1.9.3 の大きな変更やパフォーマンスに関する研究成果の報告、今後の Ruby に欲しい機能について会場の Rubyist とのディスカッションを行いました。

また Ruby1.9.3rc1 (2011/09/30 現在) を使ってみて何か不具合を発見したら報告してくださいとのことでした。ぜひ Ruby1.9.3rc1 を使ってよりよい Ruby にしましょう !

Writing Solid Ruby Code

話した人: Jim Weirich
書いた人: kei-s

Rake の作者である Jim Weirich さんの発表です。Writing Solid Code ¹ という本を紹介しました。この本では、コーディングにおける 7 つのノウハウが C 言語を対象にして説明されています。これらのノウハウを Ruby に当てはめてコードをよりよくするにはどうすればいいかをトークしました。

Assert Yourself

実行の前提になる条件自体をプログラム自身に判別させるノウハウです。 Ruby の場合は、

ASSERT { !pbTo.nil? && !pbFrom.nil? }

などとして nil 判定を行ったり、Duck Typing による型判定などをするといいと説明しました。また、respond_to? を使ってメソッドが定義されているかを判別することを “Chicken Typing” と呼んでいました。 Assetion を使うことはコードの正当性を高めることであり、そのためには “Write Test!” とフォントを巨大にして訴えました。アドバイスとして、仕様のようにテストを書くこと、可読性の高いテストを書くために RSpec を使おうと述べました。

Fortify your subsystems

ユーザの入力やデータベースからの入力、外部システムからの入力を信じずに、自分のコードを範囲を意識しようと述べました。

Step through your code

「Ruby Debuggerを使ったことがある人 ?」と問いかけ、「最初は使っていなかったが、使ってみたところ探していたものにぴったりだった」と自身の経験を語りました。また、pry という名前の、cd などのコマンドでオブジェクトのコンテキストに移動して中身を調べることができる irb like なツールを紹介しました。

Candy Machine Interfaces

商品の番号と金額が区別しにくいキャンディの自動販売機を例にあげ、API Interface の重要性を述べました。また、悪いインタフェースの例として、C 言語の getchar() 関数の返り値が int 型であるという例も挙げていました。

Risky Business

1 つのメソッドが大きすぎる等のリスクになりうるコードを見つける方法として循環的複雑度という指標を紹介しました。これはメソッド内の分岐やループの数を複雑さの指標とするもので、この指標を使って Rake ライブラリでの複雑なメソッドを洗い出す例をあげていました。

Treacheries of the Trace

case when と三項演算子だらけのコードを紹介し、アジャイルな言語は簡単にコードを書くことができるが、汚いコードも容易につくりだしてしまうと述べました。これに対して、簡単な問題に複雑な解決策を使うなとアドバイスし、例としてモンキーパッチ、メタプログラミング、alias method chain は必要なときだけ使うようにと言い、”Don’t be overly clever.” と述べました。

Rest is Attitude

「バグは勝手に無くならない。”あとで直そう”ではなくいますぐ直せ。」と訴えました。

最後に「Your code is your responsibility.」と述べ、より良いコードを書く重要性を改めて訴えました。

Blueprint: configuration management for busy people

話した人: Richard Crowley
書いた人: いわもと

Blueprint は Puppet や Chef と同じように、サーバの設定を統合管理するためのシステムです。(Blueprint については、別のカンファレンスで発表された資料も参考にしてください。)

Puppet や Chef がトップダウンのアプローチ(マニフェストを書いて、設定を適用) に対し、 Blueprint はボトムアップのアプローチ(設定をして、マニフェストを生成) というような印象を受けました。

また、生成したマニフェストを Puppet/Chef の形式にも export できるので、既存のシステムに設定ファイルの統合管理を導入したいといったときに、Bluprintを使うと便利だと思いました。

トップダウンとボトムアップを組み合わせて、「かゆいところに手が届く」統合管理ができるのではないかという期待を抱かせてもらえたセッションでした！

matzキーノート “Ruby Everywhere”

話した人: まつもとゆきひろ
書いた人: 五十嵐邦明

「私は言語開発者です。すごい言語の開発者です。」で会場から笑いと拍手をもって迎えられ、まつもとさんのキーノートが始まりました。

最初に新しい肩書きの Heroku チーフアーキテクトとなったことを紹介。セールスフォースの Marc Benioff との「君を雇いたいんだけど」「えっ」という馴れ初めを紹介されました。「私を雇ったら私の収入は増えてうれしいけど、Ruby を推進するためには Ruby デベロッパーを雇った方がいいよ。」というやりとりを紹介し、同じく Heroku にフルタイムで雇用された中田さん (nobu) を紹介しました。中田さんはパッチモンスターと呼ばれるコミット数 1 位のコミッターです。紹介された中田さんは、いつも通りの自然体で会場からの拍手を受けていました。そして、これからも Ruby のコアコミッターを雇用する企業があれば歓迎したいとのことでした。

去年の RubyConf のキーノートから引き続き、今年もまつもとさんは「もっと多くの開発者を Ruby で幸せにしたい」という想いを語りました。例えば、JRuby は Java 開発者に Ruby を使えるようにし、Rubot は JRuby を Android 上を使えるようにし、Rhodes はモバイルフォン向けのアプリを Ruby で書けるようにしたという事例を紹介。まつもとさんは携帯や、ロボット、車といったモバイルの分野にリーチしたいとのことでした。

去年の Ruby 会議でも紹介した RiteVM と組み込み Ruby の mruby。今年はついに「動いている！」と宣言し（会場拍手）、マンデルブロー図形を描くデモを披露しました。（のちに twitter で -O オプションを付け忘れた、付けてたらもっと速かったのに！とコメントしてらっしゃいました。）（Rite と mruby の関係については、Rite は VM の部分、mruby は Ruby としての名前とのことです。Ruby1.9 と YARV の関係と同じで、YARV にあたるのが Rite, Ruby1.9 にあたるのが mruby です。）

mruby はまだ若くて弱い存在だけど、ロボットや、TV の中とか、いろんな可能性があると、まつもとさんは語ってくれました。完璧な言語はない、Ruby でさえも完璧ではないとのこと。だからこそ選択を提供するのだと。最後にまつもとさんは、会場の Rubyist へ「私は Ruby で世界の幸せをもっと増やしたいと思ってる。今、私たちが Ruby を使って感じているように。Ruby を愛してくれているみなさんに感謝します。ありがとう。」というメッセージを贈り、キーノートを締めくくられました。

Powerful (but easy) Data Visualization with the Graph Gem

話した人: Aja Hammerly
書いた人: 五十嵐邦明

DOT は graph を書くためのシンプルな言語です。graphViz や Tulip といったツールを使うとレンダリングできます。

これを Ruby で使うための RubyGraphLibraryというライブラリがあり、gem install graph でインストール可能です。 graph を使うと、以下のコードで A→B という図が書けるようになります。

diagraph do
  edge "A","B"
end

save メソッドを使うと “foo”, “png” で png や jpg へ export でき、ほかにも色を付ける機能もあります。Ruby で書くことができるので、XML からデータを読み込んでグラフにすることもできます。さらに応用例としては、Rubygems や Homebrew などのデータからモジュールの依存関係を図にするなんてこともできるとのことです。

フローチャートなどはグラフィカルなツールを使うと要素と要素の間に挿入するといった操作が面倒です。Ruby Graph Library を使うと簡単に図を書けるだけでなく、コードで図を表現できるのでメンテナンスが容易になるといったメリットがあると思いました。

2日目

MongoDB to MySQL: the How and the Why (Sarah Mei)

話した人: Sarha Mei
書いた人: いわもと

Diaspora というオープンソースのソーシャルネットワークプラットフォームにて、開発当初より採用してきたMongoDB を、9ヶ月の運用の末 MySQL に乗り換えた理由について述べていました。セッションの序盤で「MongoDBを採用したことがあり人はいますか?」という問いかけがあり、会場内では20人ほどの人が挙手しました。しかし、「継続的に利用している人は?」という質問になると、挙手していた人の半数ほどになりました。

乗り換えた理由の一つは、データの性質によるものでした。当初は、よくあるソーシャル系アプリに見られるフレキシブルなデータ構造を考慮して MongoDB を採用したとのことでしたが、開発を進めていくうえでリレーションを持つデータが増えていき、SQL でいう JOIN をサポートしない MongoDB では効率的な実装に限界があったとのことでした。 QA では、「Q. いくつまでのリレーションなら許容できるか？」「A. 明確ではないが、よくて2つ、3つを超えてくると転換点だと感じている」とのやりとりがありました。

もう一つの理由は、MongoDBの mapper に関係するものです。これに関しては、コミュニティの未成熟な点を指摘していました。 bugが存在する、ドキュメントが少ない、検索しても明確な答えは得られない、コミュニティも活発ではない。それによって開発のスピードが思うように加速できなかったとのことでした。(もうひとつ、migration についても述べていましたが、うまく聞き取れませんでした。orz)

KVS と RDBMS はそれぞれに得手・不得手があると思いますが、その境界がまだ不明確な部分があるのではないかという印象を受けました。

コミュニティという点では、個人的には最近東京での MongoDB に関する活動が活性化してきた感がありますが、そのような活動がうまく英語圏のコミュニティと連携して知識が蓄積されていければ、きっと多くの開発者がハッピーなことになるのではないかなと思いました :)

Lightning Talks

書いた人: 卜部

Eric Hodel, “RDoc”

新バージョン出すよ。

Alex Sharp, “Bldr - A minimalist JSON templating DSL”

プロダクト紹介。

Ken Robertson, “Metis - Merging Nagios, Ruby, and TDD to make your systems safer”

プロダクト紹介だけどプレゼン下手でちょっと残念。

Ray Hightower, “Four Steps, Five Minutes (Based on Steve Blank’s book.)”

アントプレナーが失敗するまでの 4 つのステップについて。

Ernie Miller, “You Should Write a Ruby Gem”

シャット・ザ・ファッキン・アップ・アンド・ライト・ア・ジェム

Corey Haines, “What madness have I unleashed (twitterbots made easy)”

これはひどい。

Aaron Patterson, “BetaBrite LED sign”

電子工作系。Ruby を使った USB 電光掲示板のエレガントな制御 DSL の紹介。慣れてる。

Tim Connor, “Company_fit.should_not == monoculture”

プログラミングはべつに男の仕事じゃねえだろ、という。まったくそのとおりです。

Jonan Scheffler, “You are going to die”

椅子座ったままコード書いてると死ぬよ! ウォーキングマシンで歩きながらコードを書こう! …しかしウォーキングマシンで歩いても結局は死ぬと思うが…

Phil Nash, “Stop building features”

プロダクトが成功するのに必要なのは新機能じゃなくて、バグのないクリーンなコードじゃねのという話。

Coby Randquist, “Regional Ruby Conferences - Tones & Flavors”

これはregional ruby confのアナウンス

Gary Bernhardt, “Raptor”

プロダクト紹介。raptorという革命的にシンプル過ぎるweb frameworkについて

Michael Bumann, “Awesomebotfactory”

じかんぎれ。

Joshua Ballanco, “Keyword – A new gem for keyword method arguments”

キーワード引数を (lambda のカリー化を用いて) 無理やり実装する方法について。実装面白い。

Toshiaki Koshiba, “Let’s go to Shibuya Rubyist Lunch at Shibuya, Japan”

うけてた

Evan Light, “Conference Different”

俺の話を聞いてるそこのおまえら! カンファレンスは座って聞いてるもんじゃねえ! おまえらもイベントをオーガナイズしろ yp! という話。 “open space technology”でぐぐれ、だそうです。

Ayumu AIZAWA, “Lokka CMS for Cloud”

プロダクト紹介。そつなく危なげもない感じで。

Chris Parsons, “Three things I wish we’d done before the big launch”

突然の炎上をのりきるためにローンチの段階でやっとくべきことについて。

Stephen Touset, “Twitter Bootstrap Forms”

twitter_bootstrap_form_forというライブラリの紹介。Web のフォームを作成。発表短すぎてほとんど何も分からん。

Paul Wilson, “The hierarchy of values, or why we passionately disagree”

これはわかんなかったなあ、価値観の話をしているのは分かった

Ryan Davis, “RubyParser and 1.9”

Ruby Parser が 1.9「をパースできる」んだけど 1.9「では走らない」のでだれか直して pull request くれというおねがい。

John Paul Ashenfelter, “Muscle-driven development and cardiovascular coding (treadmill desks ftw)”

筋肉! 脳ミソで考えるな筋肉で考えるんだ! つうかメリケンどもはプログラム組むときノンストップでポテチ食ってんのか? そりゃ死ぬよ

Nick Howard, “How do I love thee Enumerators? Let me count the ways.”

Enumerable::Enumerator の紹介。知ってるといちだん差がつくね。

David Kapp, “How to be more easily understood by non-native English speakers”

日本で英語教えてたけどニホンジンはマジで英語わからんね、

ゆっくり
短いセンテンス
明瞭に
スラングは通じない

この4点を守ると通じるよ。という経験談。これはよい++

Pawel Szymczykowski, “/usr/lib - building a dead tree library for techies”

dead tree library って図書館のことかよ。 usrlib.org 図書館ソフトウエアネタとか Wifi の運用とか。あまり深いことは言ってないかなー。5分だししょうがないか。

Brian Guthrie, “The Cult of Magical Thinking”

黒魔術な意味で。どのようなコードが黒魔術でありどのように生まれてくるかについて。20 分くらいの内容を超早口で…。

Konstantin Haase, “Live Release Of Sinatra 1.3.0”

リリース失敗。

JRuby: Polygrot Heaven

話した人: Thomas E Enebo, Charles Oliver Nutter
書いた人: 中村

JRuby と JVM 上で動く他の言語をどうやって一緒に使うか、という発表でした。ruby-maven を使って rhino を入れてユーザが書いた Javascript を rhino 上で制限を付けた状態で実行する例や、Clojure の SoftwareTransactionalMemory を Ruby から使う例、Scala の Actor を Ruby から使うといった例を上げて、他の言語の機能を Ruby から使う様々な方法を紹介していました。Closure の STM を使う時は clobyを，Scala の Actor を使う場合はmikka を使うといいようです。

発表の最初の方で、JRuby を –1.9 付きで使っている人に手を挙げさせていましたが、まだ –1.9 を付けて使っている人は少ないようでした。わかりやすく、面白いプレゼンテーションだと感じました。

Nikita: The Ruby Secret Agent

話した人: Brian Ford
書いた人: 中村

途中からこのセッションに移動してきました。入った時に去年の OSCON で行われた Twitter のプレゼンテーションの動画を流していました。”From ruby on rails to JVM” というこの動画では、Ruby の問題点として、

GC
concurrency
performance
toolsの不足

以下の 4 つ挙げ、その為 Twitter では、Scala 等の JVM 上で動く言語に切り替えたという話をしていました。

ここで Brian さんは「また Java を使わなければならないのか? Ruby を使い続けることはできないのか?」という話をした後に、Rubinius ではこれらの問題をどう解決しているかという話に進みました。Rubinius では GC は世代別 GC を持っていて、true concurrency であり、JIT によってパフォーマンスの問題を解決したと言っていました。そして 4 番目のクラスの状況やコードがどう動いているかを調べるツールの不足に対しては、to_ast、 to_sexp によるコードの解析機能がついていたり、compiled method のデータを見る事ができるため、ツールを作ることはできる環境がそろっていて、解決できる問題だとしていました(だからみんなツール作ってよとも言っていました)。この発表のタイトルにもなっている Nikita は、まだアイディアの段階で実際になにかものができているわけではないけれど、client/server モデルを使ったアプリケーションで、server 側に compiled method の情報をストアするデータベースを持ち、モニタリングやクラスの情報を見るブラウザを実装するとの事でした。来年には、Rubinius はツールを持っているだろうとの事でしたので、楽しみですね。

Services Inception with Ruby

話した人: Dave McCrory
書いた人: 中村

Cloud Foundry の DaveMcCroy さんによる発表。PasS を使ってアプリケーションをデプロイする時には、アプリケーションが使う MySQL や Redis などの他のサービスを PaaS 側が知っている必要があります。これを自動的に行うにはどうすればよいかという話でした。

例として resque と resque-mongo を挙げ、resque の場合は Redis と MySQL, resque-mongodb の場合は Redis, MySQL, MongoDB がないと動かないといことを紹介しました。特に resque-mongo の場合は、MongoDB のバージョンなど，README を読んで手動で設定を行うのが大変で、こういった外部のサービスへの依存性を PaaS が、自動的に解決する為の方法をいくつか提示していました。

マニフェストに書くようにする
Chef や Puppet の設定に追加する形にする
コードの中に外部サービスへの依存性を書けるようにする

という3つの選択肢を挙げ、3 番目のコードの中に依存性の解決を書けるようにする為の機能を実装した話をしました。この発表は発表自体は短めで、最後に「ちゃんと動いたし自分はいい解決方法だと思うが、どうだろう？」という問いに会場に投げかけ、議論をしていました。

Manifest や Chef の設定でいいじゃないかという人や複雑な場合、例えば MySQL に依存するにしても複数の master/slave が欲しい場合はどうするんだという議論が展開されているようでした。

3日目

Q&A

話した人: まつもとゆきひろ
書いた人: 卜部

Q&Aのログなので参考程度に。

質問 1

Q. mruby はいつ MRI のコアに入りますか ?

A. 入りません。mruby はコア機能のサブセットです。

質問 2

Q. Heroku/SFDC は今後も継続的にコアコミッターの採用を続けますか ?

A. とりあえず予算の都合というものがあるが、採りたいとは思っている。また Heroku 以外の企業にも働きかけていきたい。

質問 3

Q. 1.9.3 と 2.0 のおすすめ機能はありますか ?

A. 1.9.3 は GC が強化されてます。2.0 は… Module#prepend

質問 4

Q. rubyspec の中の人として。現在、Ruby でメソッドディスパッチが遅いのを特定の引数の時だけ最適化しようとすると、C でメソッドを書き直す (VM ループから抜ける) しかありません。これはどうにかなりませんか。

A. インラインキャッシュを強化してたとえば整数引数の場合だけ特別な最適化をしたバージョンに振るとかの最適化 (脱最適化) は考えられる。

質問 5

Q. 以前のインタビューで Ruby に今後追加したい機能として Actor を挙げていたように思うが 2.0 に入るのか ?

A. 2.0 は 1.9 の延長線上であまり大きな変更は入れない予定なので、Actor が入るとしたらその次の 3.0 とか。

質問 6

Q. で、次は 1.9.4 なの? 2.0 なの?

A. 1.9.3 が出たら trunk はともかく 2.0 にする。1.9.4 の可能性は否定しないが出すとしたら1.9.3 (の枝の分岐?) から。

質問 7

Q. 会社で QA 部隊に Cucumber 使わせようとしてみたわけよ。したら、QA のやつらってWindows好きじゃん? Windows の 1.9 で Cucumber を feature 流すと 1.8 の 10 倍以上遅いわけよ。まあそんで、そのときは結局 JRuby に逃げたんだけど、MRI は Windows のことを何だと思ってんの ?

A. 何、というか、ようするにコアデベロッパに Windows で Cucumber を実行するとかいう人がいないのでしょうがない。人的リソースの問題。Windows の Ruby に継続的に関わろうとする人大歓迎。

質問 8

Q. 新規の参加者も多いと思いますので、2.0 の新機能をざっとまとめて教えてください。

A. Module まわりで mix(注 : その後の議論により、mix の導入は中止となりました。)とか prepend とか。あとキーワード引数。それからまだちょっと流動的だけど selector namespace

質問 9

Q. サイン(電子署名)についてどう思いますか?

A. gem に署名する機能はちゃんと作れば便利なんじゃないかなあ。

質問 10

Q. Matz、あなた自身も最近は “MRI” という言い方をしますが、あなたが言ってる時には “My Ruby Interpreter” の略なのですか ?

A. いやあ(笑) 。MRI と言ってるときは大抵 1.9 のことだけど、1.9 のインタープリタは _ko1 の作品だし、違うんじゃない。

質問 11

Q. じゃあCRubyの事を呼ぶ新しい名前考えようぜ。

A. いや MRI でいいよ。

質問 12

Q. 2.0 に向けてコミュニティが、何か行えることはありますか

A. 処理系実装の人たちとのデザインミーティングはまたやりたい。けど前の時のは、IRC 固有の問題 (時間調整とか) もあったから、なんか別のツールを試すべきかも。あとそれ以外の人は、rubyspec に参加するといいんじゃないでしょうか。

質問 13

Q. Rite と mruby の関係がよく分からない

A. それらは別プロジェクト。Rite は日本の政府からスポンサーされてる案件で、6 ヶ月後くらいにオープンソースになります。Herokuの人とかも使えるようになるよ。

質問 14

Q. Syck がぶっ壊れてから長い時間がたつわけだが。こういうのは掃除しないの?

A. 言っている通り 2.0 では大規模な変更は行わない予定です。削除はないかな。ただ gem にできるやつは gem に移行するのはありうる。

質問 15

Q. 削るとしたら何を?

A. getoptとか古いのはあるよね

質問 16

Q. 2.0 の classboxing について、他の言語にあるような別のディスパッチ方法も考えられるのでは ?

A. パフォーマンスがどうなるかだよね。 Rubinius とかなら他の方式もトライしてみてもいいんじゃない。

質問 17

Q. -wって使う?

A. ええまあ。たまには。

質問 18

Q. お子さんに Ruby を教えるとしたら何才くらいから

A. 実は子供はもういるんだ。一番上はもう 19 だけど Ruby に興味があるようには見えないし、強制しようとも思わないよ。自分も親からプログラミングを強制された記憶もない。

質問 19

Q. 長時間動きつづける Ruby プロセスのデバッグが面倒なんですけど。introspection API のようなものは提供する予定はないの?

A. DTrace のプローブを入れようという試みはある。

質問 20

Q. 2.0 のパフォーマンスはどうなりますか?

A. パフォーマンスは専門じゃないからよく分からない部分も多いが _ko1 は継続的に改善しようとしていると思う。

質問 21

Q. Ruby プログラマが誤解している事の中でもっとも重要なのは?

A. パフォーマンスかな(笑) マイクロベンチマーキングでは何も分からないよ。

Advanced API design: how an awesome API can attract friends, make you rich, and change the world

話した人: Jonathan Dahl
書いた人: いわもと

API, 特に Web 業界における、API のよいデザインとはどのようなものか ? という話でした。

近年 Web サービスが成長していくうえで重要な要素として API があるとし、 API の実装にあたってケアすべき点をいくつか挙げて、それに対して「例えばこんな場合、みんなならどう実装する ?」というような参加者との対話が多く見られるセッションでした。

API デザインの質と価値の関係は、スポーツのそれに似ているとの例え、質がある一定の基準にならなければその価値はさほど上がらない (あまり使われない) と述べ、より良いデザインの重要さを強調していました。

また API は UI でもあり、実社会に存在している様々なインタフェースにも学ぶところがあるはずだ、という議論もされていました。

個人的には結論は発散的な印象でしたが、もしかしたら API 実装のベストプラクティス集や、 API 実装のためのライブラリやフレームワークなどがあれば需要があるのかもしれないな、と感じました。

How GitHub Uses GitHub to Build GitHub

話した人: Zach Holman
書いた人: いわもと

「みんなgithub 使ってるよな？いえーい!」とでも言わんばかりの、サービスの勢いがそのまま現れているような、かなりノリノリのセッションでした。

github 内でのワークスタイルについての話でした。キーワードとして、

asynchronous (非同期)
simple

が挙げられており、より集中しやすい (いわゆる “zone” に入りやすい) 環境で仕事して生産性を高めようぜ、という話でした。

資料はこちら。

発表内容もそうですが、自信に満ち溢れた発表者も含め思わず「cool!」と言えるようなセッションでした:)

simple tool + better process = awesome product.

Complex Ruby concepts dummified

話した人: MATT AIMONETTI
書いた人: 五十嵐邦明

「Rubyの難しいところを簡単に解説するよ !」というセッション。parser, Lexer, AST, VM, GC といった Ruby の内部の様々な話題を幅広く、分かり易く解説していました。例えばスレッドに関しては 1.8 と 1.9 のそれぞれの仕組みの違い、GIL など存在する問題、そして GIL を解消する際に新たに発生する問題と、RubyConf のほかのセッションでも話題になった内容に関して説明していました。断片的に聞いたことはあるけどよく知らなかった、という各種の情報を分かり易くまとめてあるこの発表はとてもありがたかったです。資料を後で読み返したいです。

“ライティングソリッドコード―バグのないプログラミングを目指して” http://www.amazon.co.jp/dp/4756103642 ↩

バックナンバー