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

今回は、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版ですね　僕は予約しましたので皆さんも買えばよいと思います

RailsConf2009に参加中の高田悟史です。RUNNING THE SHOW: CONFIGURATION MANAGEMENT WITH CHEFを聞いてきました。

Chefというのは、Puppetのようなシステム管理ツールです。

Puppetとの違いをいまいち分かっていないのですが、サーバー(Chef Server)とクライアント(Chef Clients)という構成で、サーバーの設定(cronやApacheなど)をrubyで記述し(これをCookbookと呼ぶ)、新しく導入するサーバー(Chef Clientにあたる)のセットアップや設定変更やRailsアプリケーションのデプロイなどを自動的に行うことができるツールです。また、このCookbookという設定情報はバージョン管理されます。例えば、Apacheの設定ファイルをERBで記述し、rubyで変数値を指定するというような書き方ができるのは便利そうです。

Chef Soloという仕組みもあり、ネットワーク上やセキュリティー上の問題からChef Serverに接続できないサーバー(Chef Client)でもCookbookを含むターボールを指定することで同様のことをすることができます。

その他にも、WebUIでCookbookの参照や編集や検索をすることができるのは便利そうでした。このCookbookの操作にはREST APIも準備されていて、コマンドラインからこれらの操作をすることもできます。

PoolPartyというクラウドを管理するツールは、Chefが元になっているらしいです。

ちなみに、Puppetの日本情報wikiにPuppetの作者がChefをどう思ってるか書いてありました。

Chef ServerとChef Clientのデモには、VirtualBoxを使っていました。まだ試していないのでどのくらい手間がかかるのかは分かりませんが、ローカル環境でChefを試してみたい場合なんかにはよいかもしれませんね。

クックパッドでも、近々サーバーの増設をすることになるのだろうというところですが、100台を越え始めるので、このような一元管理できるしくみを導入したいと考えています。Puppetと比較してChefも検討しようと思います。

RailsConf2009のレポート一覧»