techlifeライトニングトークは、実践的な技術交流のためのイベントです。

毎回テーマを決めて、それについてプレゼンをして頂きます。

・1人5分、参加者全員発表

・LTの内容は動画で公開予定

・あなたのtechlife（技術のある楽しい生活）に役立った内容のみ発表可能

・申し込み人数が10名を超える場合は、抽選とさせて頂きます。

techlifeライトニングトークは、平日19時から！

11/20　分散処理

12/3　　Puppet

12/11　 Hive

-申込方法

下記項目をご記載の上、までメールをお送りください。

〆切は開催2日前。ご参加頂く方には、詳細のメールを差し上げます。

—————————————————

■タイトル（例えば分散処理の会なら）

「分散処理参加希望」

■本文

・お名前

・ご年齢

・ライトニングトークのおおまかな内容

—————————————————

twitterはじめました！ライトニングトークのテーマ募集中☆

＠techlifecookpad

はじめまして。インフラチームの菅原といいます。

今年の7月に入社してから、コンソールとにらめっこする毎日を過ごしています。クックパッドのようにアクセスの多いサイトのサーバを扱うことが今まで無かったので、いろいろと勉強になることが多いです。

さて、インフラチームではサーバの状況をモニタリングして、サーバに問題がないかを常に把握するようにしています。そのため日常的にtailでログを追いかけているのですが、そんなときはAWKが非常に便利なことに気付き、最近はかなりAWKにハマっています。

今回は絶賛マイブーム中のAWKの活用例をご紹介したいと思います。

なぜAWKなのか？

残念ながらAWKの知名度はあまり高くないようで、社内でも「なぜRubyでやらないのか？」と聞かれることがありました。僕も入社するまではcutの代わりぐらいにしか使っていなかったのですが、あるときログ出力の整形に使って以来、AWKのおもしろさにすっかりハマってしまいました。

AWKの魅力はいろいろとあるのですが、ひとつあげるとすれば「ワンライナーの書きやすさ」です。もちろんRubyでもPerlでもワンライナーは書けるのですが、AWKはさらにワンライナーが書きやすい言語です。

仕事での活用例

普段、僕が仕事で使っているAWKスクリプトをいくつかご紹介します。AWKの文法についてはGNU Awk User’s Guideなどを参照してください。

Railsの500msec以上かかっている処理を追いかける

後からRailsのログを集計してもよいのですが、その場で状況を知りたいときは tail -f と AWK の組み合わせが強力です。次の簡単なAWKスクリプトは、遅くなっている処理をさくっと把握したいときに使っています。

$ tail -f log/production.log | ¥
 awk '/^Completed/{if($3 > 0.5) print }'
Completed in 0.56046 (1 reqs/sec) | Rendering: 0.23351 (41%) ...
Completed in 0.59227 (1 reqs/sec) | Rendering: 0.00010 (0%) ...
Completed in 1.90438 (0 reqs/sec) | Rendering: 1.87990 (98%) ...
...

Apacheの平均応答時間を追いかける

アクセスが多くなると tail -f でaccess_logを追いかけようとしても、流れが速すぎて状況を把握できません。そこでAWKで100リクエストごとの平均応答時間を計算して、現在の応答時間がどのくらいなのかを把握しています。

$ tail -f access_log | awk '
{i++; t+=$4}
i > 100 {
  print strftime("%H:%M:%S"), "|", t / i / 1000, "ms"
  i=t=0
}'
18:58:34 | 97.1538 ms
18:58:38 | 80.6553 ms
18:58:42 | 75.4794 ms

ちなみにクックパッドのaccess_logは以下のようなフォーマットで出力されます。

# ステータス, 時間, 処理時間(マイクロ秒), リクエストuri, パラメータ...
LogFormat "%>s\t%{%Y-%m-%d %H:%M:%S}t\t%D\t%U\t%q..."

上記のスクリプトを少し修正して、単位時間あたりのリクエスト数を出力するようにすると、サービスへどのくらいアクセスがあるのかを把握できるようになります。

[...]$ tail -f access_log | awk '
BEGIN{st=systime()}
{i++}
i > 200 {
  et=systime()
  printf("%s | %.1f req/sec\n",
    strftime("%H:%M:%S"),  i / (et - st))
  i=0; st=et
}'
19:10:45 | 16.8 req/sec
19:10:55 | 20.1 req/sec
19:11:06 | 18.3 req/sec

slow-query.logを追いかける

mysqldumpslowというスロークエリログ用のツールがありますが、その場で状況を知りたいときには tail -f で追いかけるのが手軽です。しかし、そのままでは少々見にくいので、次のようなAWKスクリプトで整形します。

[...]$ tail -f slow-query.log | awk '
/^# Time/ {
  q=substr(q,0,64)
  printf("%s %s %-17s %2d %s\n", d, t, h, s, q)
  d=$3; t=$4
}
/User/ {h=$5}
/Query_time/ {s=$3}
/^[^ ]/ {q=$0}'
091010 17:46:45 [192.168.xxx.xxx]   2 SELECT foo, bar, zoo FROM...
091010 17:55:29 [192.168.xxx.xxx]   3 SELECT foo FROM...
091010 17:56:08 [192.168.xxx.xxx]   3 SELECT foo FROM...

ANSIエスケープシーケンスを使えば、10秒以上かかったクエリだけ赤く表示することもできます。

awk '
/^# Time/ {
  if (s > 9) {
    printf("33[0;31m")
  } else {
    q=substr(q,0,64)
  }
  printf("%s %s %-17s %2d %s\n", d, t, h, s, q)
  printf("33[0m")
  d=$3; t=$4
}
/User/ {h=$5}
/Query_time/ {s=$3}
/^[^ ]/ {q=$0}'

まとめ

今回は、仕事で使っているAWKスクリプトをいくつかご紹介させていただきました。僕もまだAWK初心者なのでお世辞にも洗練されたコードとはいえませんが、それでも非常に役に立っています。
ちなみに、AWKのワンライナーには何か癖になるものがあり、最近はワンライナーばかり書いているので、historyがスクリプトの保存先と化しつつあります。

みなさんもAWKで一行野郎を使いこなしましょう！

おまけ

GNU Awkはソケットが使えるので、カレントディレクトリをDocumentRootとするWebサーバを、ワンライナーで書いてみました。

awk 'BEGIN{s="/inet/tcp/80/0/0";"pwd" |& getline;r=$0;while((s |& getline) >; 0){gsub(/[\r\n]/,"");if($0 ~ /^\s*$/){c="cat " r path;printf "HTTP/1.0 200 OK\r\n\r\n" |& s;while((c |& getline) > 0){print |& s}close(c);close(s)}else if($0 ~ /HTTP/){print;path=$2}}}'

きちんと改行をいれるとこんな感じになります。

awk '
BEGIN {
  s = "/inet/tcp/80/0/0"
  "pwd" |& getline
  r = $0

  while ((s |& getline) > 0) {
    gsub(/[\r\n]/, "")

    if ($0 ~ /^\s*$/) {
      c = "cat " r path
      printf "HTTP/1.0 200 OK\r\n\r\n" |& s

      while ((c |& getline) > 0) {
        print |& s
      }

      close(c)
      close(s)
    } else if ($0 ~ /HTTP/){
      print
      path = $2
    }
  }
}'

AWKを使ったことがなくても、わかりやすいコードではないでしょうか？

GNU Awkのネットワーク機能はとても面白いです。AWKを始めた人には、ネットワーク機能のマニュアルを一読することをお薦めします。

はじめまして。今年の5月に入社した勝間@さがすチームです。

入社してからは、なかなか大変なことも多いですが、最近はお酒好きが集まって月曜から飲み合う 「勝間会」なるものも発足して、仕事面でも仕事以外の面でも密度の高い毎日を過ごしています！

さて、僕は「さがす」チーム所属ということで、普段はレシピを「さがす」ユーザの満足度を上げるために、 クックパッドの検索まわりについて、いろいろな開発を行っています。 一方で、ユーザの「さがす欲求」について深く知るために、大規模なデータ解析を行い、欲求の分析を行う機会も増えてきました。

ところが、クックパッドのログは膨大な数があるので、一口のデータ解析と言っても通常のバッチ処理だと間に合わないため、 分散処理環境の必要性が高まってきました。 そこで、まずは手軽に試せる分散処理の王道ということで、最近ではHadoopを使ったデータ解析環境を整備しています。

そんな中、ちょうどtech lunchで発表の順番が僕に回ってきたので、いい機会なので 「そもそもHadoopって何？」ということや「Map & Reduceを行っているとき、各プロセスは何をしているの？」な話をデモを含めながら発表してみました。 今回は、そのときの内容の資料と質疑応答の内容を共有したいと思います。

発表資料はこのようなものを利用しました。

その後は、このような質疑応答が行われました。

HDFSのNameNodeがボトルネックにはなりえないのか？

NameNodeは障害が起こると、HDFSのクラスタ全体が利用不能になるので、SPOFという観点で考えると、構成上どうしてもボトルネックになり得ます。
ただし、NameNodeが扱うメタデータを保護できれば、NameNodeに障害が起きても復旧できるため、次のような方法が提唱されています。

• メタデータについては、RAIDを組んで多重にディスクに書き込む。
• または、NFSマウントされた領域にメタデータを書き込む。
• SecondaryNameNodeはNameNodeのメタデータのバックアップを定期的にとっているため、NameNodeとSecondaryNameNodeを物理的に別ノードに分けて運用する。

また、NagiosやGangliaでモニタリングを行うことも可能で、ここから障害を検知することも可能です。

Hadoop MapReduceの処理コードはmasterにだけ置いておけば配布されるのか？

処理コードはMap&Reduce実行時にmasterからslaveに配布することができます。もちろんあらかじめrsyncなどで配布しておく方法も取ることが出来ます。

HDFSの安定性は？

レプリケーションの数を増やすことで安定稼働されます。 バックアップ失敗を想定して、レプリケーション数は3以上が推奨されています。また、HDFSに対してファイルシステムチェックを行うことも可能です。

Hadoop MapReduceとHDFSを分けた方がリソースを効率的に使えるのでは？

そういう発想もありかと思いますが、Hadoop開発陣の方針として、基本的には標準的な設定の使用を推奨しているようです。
標準的な設定は、YahooやFacebookなど大規模に利用されているケースをベースにして設定されたものなので、これに習うのが結果的に一番安定して動作するのでしょう。

Taskを割り振るのに優先度が付けられるのか？

複数Jobを与えるときに、優先度を付けることができます。

UU測定のサンプルコードで、複数プロセス存在するはずのReduceがハッシュマップのようなオブジェクトをどうして持てるの？

ハッシュマップのようなキーごとに処理を行うオブジェクトを持つためには、Reducerはキーごとに同じノードが処理を行っている必要があります。このとき、Mapの出力を同じキーごとに同じグループに属するように分割できれば、Reduceは分割可能となります。

ここでの、「Mapの出力を、ソートし、Reduceに渡す」フェーズは「Shuffle」、「Reduceへの入力をキーに基づいてグループ化してまとめる」フェーズを「Sort」フェーズと呼びます。 HadoopではShuffleやSortは完全に隠蔽されているので開発者がこれらのコードを書くケースはありません。

つまり、今回のようなMapの出力がkeyごとに分割されている場合は、Shuffle, SortによってMapの出力を分割、グループ化してReduceが処理できるようになるのでうまく扱うことができます。

HDFSを画像サーバなどに利用できるのか？

HDFSからのレスポンスは特に速いわけではなく、転送速度がボトルネックになるので、画像サーバには向いていません。HDFSは、データの行き来がそれほど起こらない、ログデータのようなものの保存が最も適していると思います。 画像サーバを分散ストレージで検討する場合は、他のプロダクトを利用したほうがよさそうです。

HadoopはHDFSに特化してるのか？

Hadoopを利用する場合は、必ずしもHDFSしか使えないわけではないです。他にもAmazon S3, CloudStoreなんかの選択肢があります。実際は、HDFSが一番ポピュラーで標準的に利用されているので、今回はこれを試してみました。

Hiveたのしそうですね

試してみましたが、なかなかたのしいです。 RDBと親和性高く、Joinなんかもできるのは魅力的なので、導入を検討しています。

クックパッドではHadoopはどのように使われるの？

直近では、様々な条件下でのログ解析や、バックエンドのDB更新などに利用される予定です。

まとめ

クックパッドにおいてデータ解析の需要が高まってきたことで、Hadoopへの取り組みをまとめてみました。今後、本格導入していく際にはまた改めてエントリを上げたいと思います。

また、このような分散環境におけるデータ解析についてご興味ある方を、クックパッドでは募集しています！

• [技術部] Webシステムエンジニア
• [技術部] サーバシステムエンジニア

こんにちはみなさん、とんかつってうまいですし目黒のとんきは哲学ですよね、8/1付けで商品部エンジニアになったnegipoです。すてきな上司とかわいい同僚に囲まれてとても幸せです！

さて、今回はクックパッドのバックエンドで動いているバッチシステムの紹介スライドを共有します。

大事なことは全部かいてあるので読んで下さい。
けっこう大胆な修正が入っていますが、なんとか趣旨をよみとってもらえるとうれしいです。

という訳で、クックパッドでは2週間に1度みんなでお昼ごはんを食べながら一人のエンジニアが何かをしゃべる、”tech lunch”というものを開始しました。技術部はもちろん、商品部や編集部のディレクターなど多岐にわたる人たちがクックパッドがどうやって動いているか、将来どうなっていくのかという話にふむふむと頷いています。
今後このtech lunchで共有された技術的な内容は、順次この開発者ブログに掲載していく予定です。皆様のお役に立つ情報がどんどん集まればよいなと思います。
今後ともクックパッド開発者ブログをよろしくお願いします。

こんにちは、高田悟史です。クラウドとかスケールとかそういうインフラよりのセッションを選んで参加しています。

今回は、Ilya Grigorik氏によるセッションArt of the Ruby Proxy for Scale, Performance, and Monitoringのレポートです。

スライドは下記のアドレスで参照できます。
http://www.slideshare.net/igrigorik/ruby-proxies-for-scale-
performance-and-monitoring-gogaruco-igvitacom-1396734

本セッションは、プロキシラブという同氏によるプロキシのすすめともいうべき発表でした。静的ページのキャッシュという本来の機能だけではなく、ロードバランサーとして使うということはありますが、もう少し踏み込んだ使い方をしてみようというお話です。

例えば、一つのリクエストをproductionとstagingの両方にプロキシして(もちろん返すのはproductionのレスポンスだけ)、stagingのベンチマークをしたりだとか、ログを採集してリアルタイムに監視したり、あるいはデータそのものをダイナミックに書き換えたり、などになります。採集したログを元に、パフォーマンステストを行うためにautoperfというツールも紹介されていました。

そして、ポイントは、このようなことが、同氏作のEM-Proxyというライブラリを使うことで簡単に実装可能だということでした。このライブラリはRuby製なので、やはりパフォーマンスが気になるところですが、EventMachineを使ってイベント駆動になっているので、ほとんど影響はないとのことでした。

同氏のブログエントリRuby Proxies for Scale and Monitoringも参考にして下さい。

プロキシをミドルウェアとして機能を持たせるというのはおもしろいし、それを慣れ親しんだRubyで実装できるというのはかなり魅力的だと思います。ただ、やっぱりパフォーマンスに関しては実際に試してみないと気になります。プロキシに持たせる機能のアイデアとパフォーマンス等のデメリット(メンテナンスコストが上がるなど)の天秤だとは思いますが、今後は、発生した問題の解決策として「プロキシサーバーに実装してしまおう」という選択肢が増えたのは良いですね。

«RailsConf2009のレポート一覧

開発とデザイナー的ポジションを兼務してます須藤です。
railsconf２日目、37signalsのデザイナーRyan Singerのセッションに参加しました。

「UI FUNDAMENTALS FOR PROGRAMMERS」と題したこのセッションはかなりの人気のようで、用意された大きめの会場でも立ち見が出る程の盛況ぶりでした。

曰く、UI設計を行なうときにModeling,Screens,Actions,Templatesの4つが重要ということでした。

まずModelingですが、UIはソフトウェアレイヤの一番表側にあり独立して存在している訳ではないということ、但しユーザーから見ればUIが全てでありソフトウェアの設計はUIから（必要なものから）始めなければならないと言っていました。
最終的なインターフェースに適したなモデル設計をすべきという話もしていて、プログラマ脳とデザイナー脳を交互に使って仕事をしている自分としては、とても共感できる内容でした。
どのメソッドをどのコントローラに書くべきか、どの部分をどういう規則に基づいてpartialに切り出すかなど、普段なんとなくやってしまう事が多いですが、最終的なUIによって決定すべきというのは斬新かつ納得できる話でした。

2つ目のScreensでは、ページ内の各要素がきちんとデザインされることによってどのような印象となるのか、とても分かり易いきれいなスライドを用いて具体的に説明していました。
ジャンプ率や版面率、情報の分類毎に取るべき適切な余白、コントラストによる視認性・操作性の優劣などといった、デザイナーならではの内容でした。
見出し、本文、サイドバー、ボタンリンクを含んだサンプルページをいくつか表示しながら、各要素のデザインが与える操作への影響について説明していました。

その他、Actionsの項では、「every action has a beginning middle and an end」というテーマで、一つのアクションが完結するまでのユーザービリティ的な配慮を、Templatesの項では「NO HTML in HELPERS DONT BE CLEVER」「CSS and JS follow the same REST-inspired naming conventions」といったテーマを掲げ、ヘルパーの使い方や、静的ファイルの管理方法について説明していました。

今回プログラマーの視点でこのセッションを聞いていましたが、こういうことを体系的語れるデザイナーは本当に少なく、プログラマーとデザイナーがなかなか歩み寄れない様な状況を解決するヒントを得たような気がしました。
自分の目指すべき方向性も再確認でき、とても楽しい時間を過ごせました。

«RailsConf2009のレポート一覧

こんばんは。ホテルの廊下にかかっている絵がみんな猥雑でRails hackerに与えられる心理的な影響の心配をしている根岸です。
本稿はCucumberのdeveloperであるAslak Hellesøyさんの講演内容のレポートです。

講演資料は下記のアドレスにアップロードされています。
[講演資料]
現在85人のコミッタがいるtesting frameworkであるCucumberの理念と概略がプレゼンされていました。

CucumberはBDD(Behavior Driven Development – ビヘイビア駆動開発)を実現するソフトウェアです。なんらかのアプリケーションを書く際にはビヘイビア、つまり要求仕様を特定してから開発することになりますが、Cucumberの実現するBDDは、その要求仕様通りにクライアントアプリケーションが動いているかどうかをチェックしながら行う開発です。
要求仕様をCucumberでは
given(元々の条件は何か) -when(さらに何が行われるのか)-> then(何が起こるのか)
という単純なグラフで多くのパターンを記述することにより実装可能としています。

Cucumberでは二種類のファイルで要求仕様が記述されます。
・feature
featureファイルでは振る舞いテストのシナリオを、先述したGiven, When, Thenの他に、追記を示すAndを加えて自然言語に近い形式で記述でき、また入力値の一部を動的に変更可能とすることでコードの重複を押さえることができます。
・step
stepファイルではfeatureで記述された内容の結果、アプリケーション側でどのような操作が行われるのかを正規表現ベースで記述します。ここでのアプリケーションに対するアクセスの記述方式の一部はWebratというrubygemによって実装されており、Webratの作者は今日のruby heroes awardの受賞者でもあります。

上記の内容はかなりはしょったCucumberの記述方式ですが、他にもフックが実装されていたり、また他のユニットテスト用のプラグイン(RspecやShoulda)をstep内で使うことができるなど、BDDを容易に行うための機能は揃っているように感じました。詳細仕様はdocumentを参照してほしいこと、また昨日の発表に添付されていたRailsプロジェクトで、本体のコードはともかくなかなか凝ったテストがCucumberで書かれているように思えたので参考にしてみて下さい。帰ってきたhtmlの検証をNokogiriでやるのは鉄板ぽいです。

さて最後に感想ですが、Cucumber、すげえいいと思います。今回のRailsConfは薄目で眺めるとtesting! testing! testing! refactoring! testing!と言った感じで、やはりかなりエンタープライズな用途(と、プログラマの幸せ)を意識した印象があるのですが、我々がクックパッドを開発するときの強くユーザを意識した姿勢は、outside-inな思想を持つCucumberとはかなり相性が良いと考えています。今後の開発体制作りの中でもかなり注目されるツールの一つとなるでしょう。

«RailsConf2009のレポート一覧

@hashikemです。

RailsConf 二日目の朝は、DHHのキーノートでした。

Railsの歴史的な話や、Rails3のポリシーや新機能の紹介などがあったのですが、 個人的に響いたのは最後に話していた創造性についての話しでした。

DHH曰く、創造性の鍵になるのはずばり「要求の再調整(to renegotiate requirement)」とのことです。

彼が好きなベルギーチョコレートを例に出して、大好きなのだけれど、手にいれるのは大変。 じゃあ、本当にベルギーチョコが欲しいのか、チョコレートならいいのか、もっとどこでも 手に入るTwixでも満足できるのかといった調整が大切ということでした。

これって、実はクックパッドの日常の仕事の中でも日々気をつけていることで、必用だと思っていることを、 どうして必用なのかをつきつめていくと、最初に思っていたこととは全く違うことが重要だったということが良くあります。

創造性については、質と時間の二つの軸で考える必用があるのですが、 ベルギーチョコレートが質に関する話だとしたら、時間軸についての話しもしていました。 面白かったのは、時間軸とモチベーションの高さを関連付けていること。高いモチベーションを保てる時間は とても短くて、その高いモチベーションの間にできることになるように、再調整することが重要とのことです。

聴衆からの質問に答えて、The greatest danger is too much time. と言いきっていたのが、印象的でした。

この創造性についての考え方はクックパッドにも非常に近くて、cookpad.com のフレームワークとして Ruby on Rails を選択したのは、こういった匂いを感じたからだったなと思い出しました。

«RailsConf2009のレポート一覧

@hashikemです。

秒間1000回更新されるシステムの発表ということで、興味深々で聞いてきました。

高級ブランドの招待制ファミリーセールのサイト「ギルトグループ」のシステムについての発表でした。

ギルトグループでは、決った時間のみのセールなどを行なうため、短い時間にショッピングカートの更新が集中します。 20秒間に、20万人が使用することもあるそうです。 1秒間に、1000リクエストのアップデートを処理するために、以下のような技術を使用しています。

• 自前のCDNを構築してキャッシュデータを載せる
• トランザクションの処理をスケールするために、JRuby + EC2 + SQS + Rails のシステムを、EC2上に構築
• 商品をショッピングカートに入れる処理を扱うために、商品毎にDBサーバを分割。ここでは、H2 DBも使用。

スケールに対応するための新しい技術をうまく組み合わせて使っています。

また、今回のカンファレンスでは、ここのシステムのように、スケールに対応するために積極的にクラウドの技術を 導入している発表が、数多く見られました。さらに、ギルトグループでは、$100Mの売り上げを得てもいるとのことで、スケールに対応するための新しい技術を用いて成功している好例だと思います。

これまでギルトグループについては良く知らなかったのですが、技術駆動型の企業として今後も見習っていきたいと思います。

«RailsConf2009のレポート一覧

こんばんは根岸です。会社のマニーでべガスに来ています。

本稿はrakeの作者、Jim WeirichさんとJim O’brienさんのテストやリファクタリングに関する表題の発表のレポートです。
リファクタリング用のサンプルプロジェクトとスライドがアップロードされていました。

http://onestepback.org/download/refactor.zip

以下軽く紹介するので、興味がわいたらプレゼンを眺めたりあとで公開されるであろうビデオを眺めたりして下さいね。

前半は要するに良いオブジェクト指向のデザインとは何かというテーマです。
・凝集性を高める
・低い結合性を保つ
・明確さを維持する
これを実行するために単一責任原則だとか、リスコフの置換原則だとか、役割の局所性を利用したオブジェクト間のやりとりの粗結合性だとか、最少のクラスとメソッドの実装だとか、様々な設計ポリシーがあるよと説明したあと、ではそれを維持するためにリファクタリングをしよう！という話につながりました。
・新しいテストを書く
・それが全て通るようなコードを書く
・リファクタする
というリファクタリングのループを前提として、メソッド分割やらパラメータの導入やらといった一般的なリファクタの手法を説明していました。

後半はgreedというおもしろRailsゲームをリファクタリングしつつ仕様変更しよう！という内容だったんですが、cucumber前提なのも割とついていけないポイントだったんですが1時間ちょっとのリファクタリング講義の為にわざわざいろいろ穴のあるこのサイズのアプリ作ったんですか…と驚きあきれました。僕は持ち時間使い切ってまずアプリを動かせる状態にしてcucumberのシナリオの書き方の学習とコードリーディングを大体やってリファクタリングに入り始めたところで終わっちゃったんですが、基本的に周囲の外人さんは課題の仕様変更を終わらせてAIの改善とかに手をつけはじめる感じで、完全に差を感じました。

開発の技術的な体制やマインド・ポリシーの共有は、クックパッド技術部にとって注力したいテーマの一つです。今回の発表はきわめて一般的な話ではありましたが、こういった形で一種の最適解みたいなものに直に触れられたことは今後の良い糧になると考えています。
個人的にオブジェクト指向の説明のためにテーブルにJimさんが配ってくれたさいころは宝物にします :)

ちなみにそのうちこんな本が出るそうです
Refactoring: Ruby Edition
http://www.amazon.com/dp/0321603508
Martin Fowlerのリファクタリング本のRuby版ですね　僕は予約しましたので皆さんも買えばよいと思います