Art of the Ruby Proxy for Scale, Performance, and Monitoring (RailsConf2009レポート)

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

今回は、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で実装できるというのはかなり魅力的だと思います。ただ、やっぱりパフォーマンスに関しては実際に試してみないと気になります。プロキシに持たせる機能のアイデアとパフォーマンス等のデメリット(メンテナンスコストが上がるなど)の天秤だとは思いますが、今後は、発生した問題の解決策として「プロキシサーバーに実装してしまおう」という選択肢が増えたのは良いですね。

UI Fundamentals for Programmers (RailsConf2009レポート)

«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」といったテーマを掲げ、ヘルパーの使い方や、静的ファイルの管理方法について説明していました。

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

Quality Code with Cucumber (RailsConf2009レポート)

«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とはかなり相性が良いと考えています。今後の開発体制作りの中でもかなり注目されるツールの一つとなるでしょう。