本日9月14日から16日の3日間、札幌市産業振興センターにて札幌Ruby会議2012 が開催されます。3日間に渡り、随時レポートをお届けしていきます。なお、本イベントの事前特集が組まれていますので、ぜひこちら も確認してみてください。
今回のイベントでは、スタッフの皆さんは専用Tシャツを着用しています。気になることがあれば、気軽に話しかけてみてください。
連絡事項までに、メインルーム（Blue A；ルームA）のキャパシティの関係から、別部屋（Blue C；ルームC）での中継も予定されています。電源を取りやすそうです。
同会場ではアンカンファレンス形式の、ぬRubyKaigiも明日から行われます。その受付がメイン会場（Blue A）の後方の受付ボードですでに開始されています。話してみたいことがある方は是非検討してみてはいかがでしょうか。
Herokuランチ
本日12時からHeroku, Inc.より、先着100名の方に 「 Heroku弁当」と「Heroku特製タンブラー（非売品） 」がまつもとさん、ささださん、相澤さんから手渡しで（！）配布されました。そのため、早めに会場に来場する方も多く見受けられました。
オープニング
はじめに副運営委員長の前田智樹さんによる注意事項の案内の後、実行委員長の島田浩二さんから開会の挨拶がありました。
開会の挨拶
開会は島田さんの「みなさん、こんにちは」という挨拶から始まり、札幌Ruby会議について紹介しました。札幌Ruby会議は2008年から行なっている日本Ruby会議の地域開催のひとつで、特徴として世界各地から参加していただいていると言います。そして今回の札幌Ruby会議はこれまで開催された中で最大規模であり、3日間での参加者はのべ1,000名を超える予定だとのことです。そのうち、約1割が日本国外からの参加になるそうです。
続けて札幌Ruby会議が数多くの人の支援で成り立っているということに言及しました。スポンサーや金銭面以外でバックアップをいただいた方々、後援団体のほか、キーノート（基調講演）を快く引き受けてくれたMatzさんやAaron Pattersonさん、Eric Hodelさんの名前を挙げます。また、事前の一般発表募集で予想を超える数多くの応募があったことにも触れ、応募してくれた方々に感謝の言葉を述べました。
We code.
そして島田さんは、札幌Ruby会議2012のテーマである"We code."を取り上げます。このテーマは、コードを書くということと自分との関わりについて考え、そこで感じたことを持って帰ってもらえる場所を提供するという意図を込めていると説明しました。
最後に、実行委員一同、3日間参加者のみなさまとよい時間を過ごせるようがんばります、という決意表明の後に開催宣言が行われました。
スポンサー紹介の際、照れくさそうにえにしテックの紹介をした島田さんの姿に会場から笑いが起こるなど（島田さんはえにしテックの代表取締役） 、なごやかなムードで札幌Ruby会議2012は開幕しました。
相澤歩さん「Heroku」
今回のイベントでは4つのスポンサーセッションが行われました。最初は、相澤歩さんのHerokuの特徴についての発表です。（ スライド等はこちら ）相澤さんはHeroku のエヴァンジェリストであり、CRubyのコミッタです。
Herokuでは前述の通り、開幕前の時間で弁当とタンブラーの配布を行っており、相澤さんが来場者に弁当を食べたかを尋ねると、大半の来場者が挙手をしていました。
Herokuとは
相澤さんは、Herokuを「Leading PaaS for professional app developers」 、すなわちWebアプリケーションのプラットフォームを提供するサービス（PaaS ）の中でも先端を行く（leading） 、プロフェッショナル開発者のための（professional app developers）ものであると話します。
「先端を行く」という観点では、Herokuが現在220万以上のアプリケーションをホスティングしていることや、Herokuは2億5千万ドルという巨額でsalesforceに買収されたとのことを挙げていました。また「プロフェッショナル開発者のための」という観点では、Herokuの創業者の一人であるAdam Wiggins氏が、良いアプリケーションを作る上でのベストプラクティスを示したThe Twelve-Factor App をHerokuで実現している、と言います。
Herokuの哲学は「開発者の生産性を高める」ことであると、相澤さんは述べていました。具体的には、開発が楽しいと生産性が高くなり、そのことがイノベーションやビジネスの価値を生み出すとのことでした。Ruby会議で発表したり、ワークショップを開催したり、技術情報を提供したりすることで開発者を支える。このこともHerokuの哲学に沿った活動であるそうで、例えばHerokuでは、Heroku Meetupを2ヶ月に1回開催したり、RailsGirlsTokyoを支援しているそうです。また今回の札幌Ruby会議2012には、総勢10名のHeroku社員が訪れているとのことでした。
Heroku向けのアプリケーションを作ることについて
続いて相澤さんは、Heroku向けのアプリケーション作ることについて説明しました。
まず、Herokuの開発ツールは過去のものから変化してきており、以前はrubygemからライブラリをインストールしなければならなかったのですが、現在ではHerokuを開発、利用するための環境を一つにまとめたツールを様々なOSに提供していることを示します。また、Herokuへのデプロイはgitで行うことができます。これはデプロイ作業が「プログラマが日常で行っている作業」の流れを妨げないようしているためだそうです。
Herokuの大きな利点の一つに、スケールアウト(ハードウェアの増強・削減)が容易であることが挙げられていました。スケールアウト可能なハードウェアの構築は、自前で行うのは大変なのですが、これがHerokuであればGUIでの設定一つ、あるいはコマンド一つで可能とのことでした。その他、データベースの規模を容易に変更可能である、Ruby以外の言語も多数サポートしている(公式にはPython、Node.js、Scalaなど、それ以外にもPerlやOpenCOBOLが動いたとのこと)といった特長が述べられていました。
さらに現在では、Facebookアプリやmixiアプリを作る際、デフォルトではHerokuの上に作られるようになったのことで、大手SNSとの協業も進んでいると言及しました。
相澤さんはさらに来場者への質問として、Herokuでサービスを運営しているかを尋ねました。結果、まだそこまでは多くなかったのですが、海外では様々な大企業やベンチャー企業などに既に採用されており、また日本でも沢山の企業がHerokuを利用しはじめているとのことです。
Herokuの今後
最後にFAQとして、Herokuについてよく聞かれることを紹介しました。
「Herokuのサーバは東京に来るのか」については、「 技術的には可能であるが、現時点では置く予定はない。しかし、基盤となるクラウドに依存しないようHerokuを改善しているため、遠くない将来何らかの成果を見せられるだろう」と述べていました。
「日本語の技術情報の提供」については行なっていないわけではないけれども、あまり進んでおらず、日本人有志の記事に頼っているのが現状だそうです。またfacebookページ「herokujp」のいいね！が増えると優先度が上がるかも、と話していました。
「日本での採用」については、「 採用を始めたので、興味のある方は会場で声をかけていただければ」とのことでした。
平野和順さん「RubyやLinux対応を積極的に進めるマイクロソフトのオープンソース<3(LOVE)戦略」
日本マイクロソフト株式会社にて、クラウドプラットフォーム推進を担当している平野和順さんがWindows AzureとRuby実行環境である能楽堂についての発表です。（ スライド等はこちら ）平野さんRubyの関係は、以前よりartonさんと知り合いで、artonさんに「Rubyいいよ！」と勧められてRubyを使いはじめ、その後角谷さんを紹介されたことがきっかけだそうです。
発表はWindows Azureのマスコットキャラクターであるクラウディアさんのムービーとともに始まり、平野さんは「Mac率が高い中、Windowsを持って来ました」と笑いを誘いました。はじめにこれら2つの出来事で参加者の笑顔から本セッションはスタートしました。
Windows Azure
Windows Azureはマイクロソフトが推すクラウドプラットフォームの名称で、2008年からスタートし、今年でバージョン3といえる内容になりました。SDKを繰り返しリリースしながら、Hyper-VとAzure両方を進化させてきたとのことです。マイクロソフト製品はバージョンが3になると出来が良くなるという神話があるそうで、平野さんも楽しみにしていると述べていました。
Windows AzureのRuby対応
現在、本国のWindows Azureではnode.jsやPHP、Pythonの対応はうたわれているのですが、Rubyをサポートすると明言されていないため、平野さんをはじめとするメンバーが日本側でRubyを対応させているそうです。
特にRailsを利用したWindows Azureの実運用のために、能楽堂というWindows用Rails環境を開発したと話します。能楽堂にはIISの代わりに、演能とよばれる軽量なWebサーバを搭載しており、Windowsの特徴であるHttp.sysの機能を用いているため、Windows用Rails環境としては、かなり優れていることを示しました。また、マルチプロセスをサポートしているため、IIS（インターネットインフォメーションサービス）と共存できるそうです。
Windows AzureとRuby、Rails
Windows Azure仮想マシン（IaaS）では、Linux、Windowsサーバが利用可能です。しかし、IaaSでは仮想マシンのメンテナンスなどユーザーが運用する際の負担が大きいため、Windows Azureクラウドサービス（PaaS）も用意していることを紹介しました。WindowsサーバベースでRubyアプリケーションをパッケージとしてデプロイ可能とのことです。
中でも、能楽堂コンパニオンを用いると、毎回仮想マシンを立ち上げることなく、Railsアプリケーションの部分のみをデプロイ可能とのことです。その他、ファイルストレージやRDB、KSV、キャッシュなども簡単に利用できるそうです。
Windows Azureデモ
Windows Azureの管理ポータルを用いたデモとして、CentOSの仮想マシンをワンクリックで作成し、sshでサーバーへ接続しました。
続いて、Railsアプリケーションを動かすデモを行いました。通常のRailsアプリケーションのようにコマンドで動作させる他に、能楽堂コンパニオンを用いることでコマンドを使わずにデプロイを完了してみせました。
まとめ
マイクロソフトといえばプロプライエタリなソフトウェアを開発しているイメージの強
い会社ですが、オープンソースも積極的に取り入れようとしているとのことで、今回はWindows Azure上でLinuxやRubyが簡単に動作することを見ることができました。中でも、Rubyの実行環境である能楽堂と、演能を用いることで、Windows Azure上でRailsをアプリケーションを簡単に作成、デプロイできていました。
Windows Azureを試したいときには、WindowsAzure.com にて90日間無料で試すことができるそうです。
高橋健一さん「ふつうのソーシャルコーディング」
まずは今回の札幌Ruby会議に、高橋健一さんの所属する東京の永和システムマネジメントからは11名の社員と1名の卒業生が参加しており、そのうちの5名がスピーカー、1名がLightning Talkでのスピーカーで発表すると言及しました。
高橋さんのセッション（スライド等はこちら ）の主題は「プログラマーがお客さんと一つのソフトウェアをどう作るか」になるとし、しかしながら今回のセッションでは「話さないこと」があるとして次の4つを挙げました。
プロジェクトの始めかた
プロジェクトの進めかた
見積りのやりかた
計画の立てかた これらについてアジャイルサムライ などの書籍、そして良く書けたインセプションデッキとは 、アジャイル開発基本のキ Returns 完全版 などのスライドを参照してほしいと紹介しました。
ふつうのソーシャルコーディング
「プログラマーがお客さんと一つのソフトウェアをどう作るか」にあたり、「 ふつうのソーシャルコーディング」を実現するツールとして「Pivotal Tracker」「 GitHub」「 Heroku」などのサービスを挙げました。一般的な手順は次のようになると言います。
Pivotal Trackerにストーリーを挙げて、優先度が一番高いものをスタートする
Cucumberでエンドツーエンドテストを書く
RSpecでユニットテストを書く
プロダクトコードを書く
みんなでpull request単位でレビューをする
マージしてストーリーをフィニッシュ
ステージング環境にデプロイして、ストーリーを"Deploy"にする
ここではheroku以外にもデプロイしますが、本番環境に合わせてステージング環境を作ります
ステージング環境でお客さまにストーリーを確認してもらう レビューではリーダブルコードなどを参照し、ページ数を例示しながら議論してしているとし、レビューの場ではどうしても殺伐な空気になりがちなので、絵文字やおもしろい画像を貼ることで堅苦しくならないように、メンバー各人の工夫していると紹介しました。これについては16日に自社の三村益隆さんのソーシャルコーディング時代のふつうのプログラマサバイバルガイド で詳しい発表があるとしました。
以上、これらの手順を繰り返すことで、お客さまに動くものを見せながら開発を進めているそうですその上で、『 アジャイル宣言の背後にある原則』から引用して「動くソフトウェアこそが進捗の最も重要な尺度です」と結びました。
事例紹介
このようなソーシャルコーディングを実践した事例として、100人月程度の「BtoCフロント・BtoBバックエンドな業務アプリ」 、15人月程度の「学習塾向けCRM」 、30人月程度の「大手ISPトラフィック分析」 、そして他社と含めて200人月程度の「ECモール」などを挙げ、コードの量や各種テストコードの比率を紹介しました。具体的な例としては、RubyWorld Conference 2011でRubyエコシステムを活用したアジャイルな受託開発の成功事例 、QA@IT を取り上げました。
最近の永和システムマネジメントが取り組んでいる事例として、「 プロジェクトeiwakun」というものがあるそうです。これは現実に存在する制約をなくしたときにプログラマ自身が毎日使いたくなる、自信を持って発表できることができるものを作り上げることができるのか、という試みのようです。これについても自社の諸橋さんのセッションで触れられるとしました。
脇道から逸れた話としてですが、Travis CIはもともと無料でGitHubの公開リポジトリの継続的インテグレーションを行うサービスでした。永和システムマネジメントはTravis Proの契約を結んでおり、GitHubの非公開リポジトリでも活用しているそうで、コードとしてPull Requestも送っていると言及していました。このTravis CIにPull Requestを送っている件については、自社のhibariyaさんが15日のLT 自分のためのコードを書こう で取り上げると紹介しました。
質疑応答
セッションが終了し、「 Activity Specとは何か」との質問がありました。これは通常Controllerに書かれるCRUDとして書かれる「ユーザの一番小さな行動の単位」だそうです。なぜ通常の枠組みから外しているのかは、永和システムマネジメント社員の浦嶌啓太さんが明日（15日）に発表するセッション「"Ruby on Rails: The Bad Parts" 」で語られるそうです。
また、「 Request Specをたくさん書くと遅いと重いと思うが、どのように対処しているか」という質問がありました。これに対しては「重いが、特別にしていることはない」 、しかし「不必要なテストを積極的に捨てることを心がけている」と回答していました。また質問者の方によれば、その対処方法のひとつとして「明後日(16日)、（ 質問者の方の会社である）クックパッドの村田という者が分散RSpecについて語るのでぜひ聴いてください」と受け答えていました。
「プロジェクトメンバー以外がPull requestを送る権利はあるか」との質問には「少ないか、記憶にない」とのことでした。レビューにはプロジェクト外のメンバーも積極的に行ない、プロジェクト内にはない視点からの指摘も得られるようです。しかし、文脈がわからないプロジェクト外のメンバーがPull Requestを送ることまではめったにないようです。
海外の方からも「見積りについてどのように計測しているか」との質問があり（その場にいた松本さん（Matz）が通訳を引き受けてくださいました！） 、これに対しては「『 アジャイルサムライ』や『アジャイルな見積りと計画づくり』などの教科書通りにやっている。チーム全体で相対見積りをしている」とのことでした。
井原正博さん「クックパッドのつくりかた」
スポンサーセッションのトリをつとめるのは、クックパッドの井原正博氏（@ihara2525）です。日本最大級のレシピ検索サイトを開発・運用するクックパッドの組織について、その考え方や取り組みについて語りました。（ スライド等はこちら ）
クックパッドのミッションは、「 毎日の料理を楽しみにすることで心からの笑顔を増やす」ことです。そのミッションを実現する手段が、クックパットというサービスです。クックパッドは、料理の才能があるユーザが活躍できる場所であり、多くの女性ユーザが抱える料理の悩みを解決する世界です。
クックパッドの組織づくり
クックパッドでは、「 全社員が技術を正しく理解し、活用できている」ことを基本理念としています。インターネットが普及する前のサービスでは、開発にも展開にもたくさんのリソースを必要としていました。しかし、技術を正しく活用すれば、圧倒的なコストを圧縮できると指摘します。ただし、多様性の高まる中では、ユーザが必要としているものを理解するには過去のやり方は通用しません。クックパッドでは、これらの基本的な概念や進め方を学ぶため、「 ウェブ進化論」と「The Lean Startup」の2冊を社員の必読書としているそうです。特に、誰も欲していないサービスのために時間や才能を無駄に使うのはもったいないと話していたことが印象に残りました。
また、開発者としてどこにリソースを投入するかを判断するために活用できる「3つの輪」というフレームワークを紹介しました。このフレームワークでは、「 やりたいこと」「 得意なこと」「 やるべきこと」を見つけ、それらが重なる部分を実践します。そうすることで開発者にとってはやりたいことで、しかも得意なことなので楽しく、上手にできるので、会社に評価もされる。やるべきことなので会社としてもビジョンを実現でき、儲かるとのことです。ただし何を「得意なこと」にするかというのを決めることは難しいことでもあると述べていました。
さらに、組織の理想的な形として「インターネット型の組織」を紹介しました。インターネット型の組織とは、開発者がそれぞれ正しく動くこと、すなわち各ノードが「自立」し、「 分散」していることを前提とした組織構造です。さらに、それぞれのノードが「協調」して動くことで、特定のスキルに特化した人同士が高度な組織を作り上げるとのことです。
組織づくりについての話の最後に、次のクックパッドのエンジニア・マニフェストについて紹介しました。
ユーザ「ユーザの問題を解決させるために技術を使い、フィードバックが得られることに感謝しなければならない。」
技術「機能を作るのではなく、ユーザの問題を解決する」
技術力「誰にも負けない分野を持つ」
行動「他のエンジニアがよりはやく価値を生み出せるようにし続ける」
マインド「正直に行動する」
コミュニケーション「動くものと数字で語る」 「技術は問題解決の道具である」なのです。
クックパッドのものづくり
クックパッドでは、ユーザ中心のサービス開発は当然のことです。例えば、サーバのログを見たときに「1行のログの向こうには、1人のユーザがいる」と考えてものづくりに取り組んでいると言います。そうすることで、アクセスログはユーザが何かを行おうとした記録となり、500エラーのログは、ユーザをガッカリな気分にさせてしまった記録となります。この考えについての詳細は井原さんのブログ に掲載されています。
それらのサービスを支えている技術については、後述の館野さんのセッションに譲り、井原さんがクックパッドで目標としてきたことについて語りました。それは、「 世界で一番、エンジニアが働きたい会社にする」と「世界で一番、技術を活かして成果を出す会社にする」ことです。
井原さんはエンジニアが人月によって、ひとまとまりに計算するということに、仕方ないところはあったと理解は示すものの、個々の技術や想像性を評価される組織としたいとの思いがあったようです。そのため、「 個々の個性や想像力を活かして世の中に価値を提供し、それがきちんと評価されてほしい」との思いで仕事をしてきたと言います。その試みは、まだまだ満足のいくところではないとのことですが、これからもずっと続けていく終わりのない目標だと話されていたことは印象深いです。
井原さんがこれまでやってきたこととは主に「エンジニアが働きやすい環境」と「エンジニアの採用」に関することです。エンジニアが働きやすい環境としては、壁全面のホワイトボードの採用など、ちょっとしたことから、キッチンの分離（クックパッド社内にはキッチンがあります！）まで、エンジニアのモチベーションを高めるための試みです。採用については、「 一点でも良いので絶対に自分より優秀な人を採用すること」と「履歴書ではなく、ブログやGitHubなど作ったものを重視すること」を中心に行ってきたと話します。そして、この札幌Ruby会議2012へのスポンサードを含め、様々なオープンソース活動へのコミットを行ってきました。
このように、「 やる気がある人を集めること」と「やらせるんじゃなくて、やりやすい環境をつくること」を行ってきた結果として、数々の著名・無名のエンジニアがクックパッドに集まってきました。井原さんの「やらされて作ったものには魂はこもらない（良いものは作れない） 」という言葉は、筆者も常々感じるところです。
やりたいことをやりましょう
井原さんはこれまで、マネージャとして強い組織づくりを目指すか、エンジニアとして世の中の役に立つものづくりを行うかの選択をしてきました。多くの葛藤があり、これまでは前者を選択してきたものの、今はやっぱり物作りをしたいとの気持ちで後者を選択されているとのことです。
やりたいことをやっている人の方がパフォーマンスを発揮できるというのは本当にその通りだと思います。人生は短いですから。
舘野祐一さん「料理を支える技術 2012」
舘野さんはクックパッドの技術部長であり、かつては、はてなブックマークのリードプログラマ・ディレクターでした。このセッションでは、クックパッドにおけるRails 2.3から3.0への移行について発表しました。（ スライド等はこちら ）
2011年から2012年の大きな変化
クックパッドでは、利用するRailsを2.3から3.0にバージョンアップしています。それまでクックパッドではRails2.3が使われていましたが、Rails2.3系のままでいるべきか3系にするべきかを検討した結果、3系に移行することに決定したとのことです。と言うのもRails2.3系のままでは、最新のRailsに集約されている様々なライブラリを将来に渡って利用できなくなるため、手間と時間をかけてでも移行するメリットを選択したのです。
どのように移行したのか？
はじめに、gemを一気にバージョンアップし、Rails3.0とRSpec2.2にしました。この影響で、テストコードの大半が失敗します。まずは、地道にテストコードを通るように改修されたようです。
1つの問題箇所を修正するだけで100のテストケースが通ることもありましたが、1つの問題を解決するために1日かかることもあったそうです。さらに、なにかを修正すると別の問題が発生することもしばしば起きて、「 まるでゲームのよう」だと述べていました。
新たな問題 パフォーマンス
Rails3.0化の対応が進み、実際に動してみたところ、パフォーマンスに問題があることが分かったと言います。ベンチマークの取得には「Apache Bench 」や「JMeter 」などを使用していたよとのことです。測定した結果、最大200％のパフォーマンス劣化があり、いくつかの対策を行ったもののリリースできるパフォーマンスには至りませんでした。また、パフォーマンス改善のためにプロファイルを測定してみましたが、毎回遅くなる部分が様々で、どこが原因となっているのか不明でした。
最終的には、遅くなる部分が様々ということからGCの発生タイミングが問題ではないかという仮説を建て、GCのチューニングは未経験だったため、簡単にできる対策として、サーバーを「Passenger 」から「Unicorn 」に移行してみましたが、目立った向上はありませんでした。
しかしその過程で、GCを開始するタイミングをユーザーからリクエストを受けていない場合に限定するというUnicornのソースコードを発見したと話します。そこで、これをハックすることでGCの発生タイミングを制御し、GCの発生タイミングをユーザへレスポンスを返した後に実行するようにして、ユーザーのリクエストからレスポンスの間にはGCを行わないようにしました。
すると予想通りにパフォーマンスが改善しました。この成果は既にUnicornに取り込まれているとのことです。また、このアプローチはUnicornに対してのものであるため、Rails2.3のアプリケーションでもパフォーマンスの向上が見込めます。
RSpecだけでは見えなかった問題
テストも通り、パフォーマンスも改善されましたが、まだ安心してリリースできる状態ではありません。そこでテストでは見つけにくい問題に対して、実際に動かして見つけるアプローチを取ったそうです。なぜならば、テストはプログラマが問題であると思っている部分について書くので、プログラマが問題と認識できない状態や場所についてはテストを書くことができないためです。
ここで「em-proxy 」を使うことで、実際のユーザのリクエストに対し従来のRails2系の環境でレスポンスを返しつつ、Rails3.0の環境に同じリクエストを処理させることができます。すなわち、実際にユーザが使っているリクエストを用いて、ユーザーやデータへの影響は無いようにRails3のテストを行ったとのことです。ただし、この時点ではRails2.3のみMemcachedやDBマスターへの書き込みを行って、データの整合性を保っています。
このようにして、実際のリクエストに対して見つかるエラーを探りました。
実際に使ってもらう
Rails3.0への移行では、さらに慎重なアプローチを行っています。プロダクション環境において、クッキーに特別な値を持たせた約0.1％のユーザに対してのみ、Rails3.0環境を参照するようにしたとのことです。ここで発見された問題として、これまでのフェーズでは見つけられなかったJavaScriptのエラー、DBマスターへの登録や更新時に問題があるクエリが見つかりました。
このように、万全の準備をして移行を行いましたが、万が一、何か重大なトラブルがあってもすぐに戻せるように、2.3環境と全く同じサーバ構成で3.0環境を用意しておき、内部でリクエストを送る先を切り換えることで対応したとのことです。これはクックパッドのインフラ環境が、Amazonのクラウド環境への移行が完了していたためにできた対策だそうです。
結果として大きな問題もなく、無事に移行に成功しました。その日は舘野さんの30歳の誕生日でした。
最後に
Rails3.0への移行は完了しましたが、引き続き早速Rails3.2の対応とRuby1.9.3への対応が始まっているそうです。
なお、質疑応答では「Rails3.0化にどれくらいの時間がかかったか」という質問があり、2ヶ月かかったとのことでした。
また、Rails3.0化の他にもクックパッドのデザインを抽象化した「sara framework」というCSSフレームワークや、CIの分散に「Distributed CI」等の紹介がありました。それぞれのソリューションが1回のセッションになるほどのボリュームであるため簡単な紹介のみとなりましたが、2011年から2012年間のクックパッドの変化がよくわかる発表となりました。
宮下剛輔さん「Sqale の裏側」
レンタルサーバの「ロリポップ！」「 heteml（ヘテムル） 」でおなじみ、ペパボことpaperboy&co.に所属する宮下剛介さんの発表です。（ スライド等はこちら ）
ペパボの新サービスととして、先日8月22日にPaaS（Platform as a Service）のSqale （スケール）が正式版としてリリースされました。今回のセッションでは、このSqaleのバックエンドの仕組みについて発表しました。
Sqaleとは？
Squaleとは「Herokuみたいなクラウドアプリケーションプラットフォーム」とのことです。Ruby on RailsやSinatraなどRackアプリケーションをデプロイ・稼働できるPaaSです。
Herokuと比べると機能は少なく、セッション冒頭で流されたポップなテイストのSqaleを紹介するアニメーション動画 からも伺えるように、SqaleはRails初心者などライトユーザ向けに提供するサービスとのことです。
AWS
Herokuと同様、Sqaleはサービスの稼働基盤としてAWS（Amazon Web Services）を利用してます。Herokuとの違いは日本のユーザにとって嬉しいTokyo Regionのサーバを利用してる点とのことです。
Sqaleの環境に対し開発者側からはSFTP・Git over SSH・SSHの各プロトコルを通じてアプリケーションをデプロイでき、クライアント側からはHTTP/HTTPSのプロトコルを通じてアプリケーションにアクセスできます。アプリケーションは軽量Webサーバ・Nginx、Rackアプリケーションサーバ・Unicornの上で稼働します。
Containers
Sqaleは「Containers」という特徴的な機能をもっていると言います。Containerとはユーザごとに割り当てられた仮想端末環境のことで、もしアプリケーションに一時的にアクセスが集中するなどして負荷が高まった場合、アプリケーションをデプロイした新たなContainerを追加することで、アプリケーションを容易にスケールアウトできます。
1つのAWS EC2インスタンス環境で数多くのユーザに割り当てられたContainerがリソースを共有して稼働します。各Container毎にアプリケーションをデプロイするためNginx・Unicorn・sshd・supervisord等のデーモンプロセスが稼働します。
ContainersはLXC（Linux Containers）をベースにしたソフトウェアです。Sqale環境で稼働するOSはAmazon Linuxとなりますが、独自のセキュリティパッチを適用して使用しており、TCPポート番号の範囲を広げたり、fork bombを防止する独自処理が適用されていると紹介しました。
WebProxy
SqaleではクライアントからのHTTP/HTTPSアクセス時、ELBによって振り分けられたリクエストを受け取り、各Containerにさらに分散させるためのProxyとして動くNginxが存在します。これらの仕組みをWebProxyと呼びます。
WebProxyを実現するために振り分け処理を行うLuaスクリプト、Containerを管理するredis、それらをNginxから利用するモジュールをNginxに組み込みんでいると言います。例えばあるContainerがダウンしている場合、そのContainerに対し一定時間リクエストを振り分けないようにするフェイルオーバー機能を実装しています。
これらの仕組みに興味のある方は@hiboma氏のブログ を参照ください。
SSH Router
開発者がSqaleにアプリケーションをデプロイする場合SFTP・Git over SSH・SSHと多種多様なプロトコルを選択できますが、これらを一箇所で受け付けるのがSSH Routerであると言います。
SSH Routerは次の順番で機能を実行します。
SFTP・Git over SSH・SSHと各プロトコルでSqaleにアクセス
各プロトコルによって渡された公開鍵情報を条件にとり、リポジトリのMySQLに問い合わせを行う
各プロトコルで次に実行すべきコマンドをMySQL検索結果から取得し実行する なお、このSSH RouterはRubyで書かれたスクリプトで、このセッション中、唯一のRuby使用事例となります。
Deploy Server
Deploy Serverに関しては、説明する時間が足りないため興味のある方は、3日目にセッション を行う長永健介さん（@kyanny ）に直接尋ねてみてくださいとのことです。
最後に
あらかじめ「Rubyの話がほんの少ししか出ません」と事前に告知されたとおり、実際にRubyの話は少しだけしか登場しませんでした。ただ、PaaSをどのようなソフトウェアを使って構築するか、サーバサイド技術に興味のあるエンジニアにとっては有益な発表だったと言えます。
仕事以外では5人ものお子さん達を育てる家庭人の宮下さんですが、一方で現役の大学生でもあります。そして、大学の必修科目の課題をこなすため、本日の会議終了後にすぐ北海道を離れるという多忙な宮下さんならではのエピソードが語られてセッションが終了しました。
会場からは、Nginxのフォールバック設定でコンテナ自身の死活監視は行なっているか？という質問が寄せられました。コンテナのプロセスの監視までしかできていないので、監視を充実させることが今後の課題と回答していました。
David Calaveraさん「Scaling in the unknown, how GitHub develops, ships and supports GitHub Enterprise.」
GitHubのDavid Calveraさんが、GitHub Enterpriseについて発表しました。（ スライド等はこちら ）
業務でのソフトウェア開発においては、開発者がGitHubを使いたいと思ってもソースコードを公開するわけにいかない、外部のサーバに置けない、という理由でGitHubが使えないことが多々あります。そういった開発者のために、ユーザが用意したサーバにGitHubのシステムを導入するものがGithub Enterprise です。
Github Enterpriseの特徴
ところで、GitHubそのものは200万のユーザ・300万のレポジトリを抱える大規模なサービスである一方、業務での開発となると50のユーザ、500のレポジトリという規模で済むことも多く、少なくともGitHubが持っているような大規模なインフラを抱える必要はありません。
GitHub EnterpriseはOVA（open virtual appliance）形式の仮想マシンとしてシステムを提供しており、ユーザによるソフトウェアのインストールやメンテナンスは不要になっています。これによりユーザにとっては、導入に困ることがなく、またGitHub Enterpriseを実行する環境を移行することも容易であると説明しました。
またその環境づくりにはHUBOT が一役買っていて、仮想マシンを作った上でテストする、ということを自動的に行ってくれているとのことでした。
GitHub Enterpriseの工夫
GitHub Enterpriseはシステムを仮想マシンとしてブラックボックスのまま提供してはいるものの、運用するサーバを管理するのに必要な情報は取り出せるようになっています。ここでは例としてサーバのログの仕組みを紹介しました。GitHub Enterpriseにはサーバのログをrsyslogによって外部のサービスに送る機構があるため、仮想マシンに直接アクセスすることなく、サーバの状況を知ることが可能になっています。一方、それのみで不足な場合のために管理者ツールも用意されています。
また、GitHub EnterpriseのソースコードはGitHub.comと大部分を共有しており、EnterpriseとGitHub.comで利用可能な機能を変えているとのことでした。その例として、GitHub.comでは無効化されている一方GitHub Enterpriseでは利用可能な機能として、LDAPのユーザ認証を利用できるというものを挙げていました。
「竹の教訓」
Davidさんによると、これらの考え方はTEDxTokyoにおける、Garr Reynolds氏の発表"Lessons from the Bamboo "（竹の教訓）に共通すると述べていました。例えば「仮想マシンを通じてサービスを提供する」という方法は、弱体化しているように見えて信頼性の高さを確保できており、これは「竹の教訓」における"What looks weak is actually strong"（弱そうに見えるものが実際には強い）に通じている。またGitHub EnterpriseとGitHub.comでソースコードを共有させつつ、それらを振り分けるという柔軟な設計になっていることは、"Be deeply rooted yet flexible"（根は深く、しかし柔軟）に通じていると述べていました。
増井雄一郎さん「Ruby + iOS = Super awesome!」
「Titanium Mobile」の開発元として有名なAppcelerator,Inc.と料理をテーマにしたソーシャル写真サービス「miil」で有名なFrogApps,Inc.にて活躍されている増井雄一郎さんの発表です。増井さんはIKEAの製品で安価に自宅で快適な開発環境を構築する方法を紹介したり,プログラミングやプレゼン資料の作成をお風呂で行うという「フログラマー」としても有名です。
本セッションで増井さんは自らが開発を手がける「MobiRuby」についての全貌や構成部分について紹介しました。（ スライド等はこちら ）
MobiRubyの紹介
増井さんはまずMobiRubyについて説明しました。MobiRubyは今週リリースしたばかりの新しいプロダクトで、まつもとさんが開発を手がけるmrubyをベースとしたiPhoneアプリの開発環境です。MobiRubyはRubyを使ってCocoa Touchの機能を直接呼び出すことができます。
今後はiPhoneだけではなくAndroidアプリを開発できるバージョンをリリースする予定とのことです。デモとして既にAppStoreで公開しているパズルゲームをスクリーン上で実際に動作させながら紹介しました。
MobiRubyを開発する上で増井さんが掲げるビジョンは、Rubyが持つパワーをモバイルデバイスの開発に届けることだと言います。特にRubyのもつダイナミックさやDSLの機能が重要だと指摘します。本機能を用いてアプリケーションの特性に合ったフレームワークやラッパーを提供することでユーザがネイティブのAPIを詳しく知らなくても簡単にモバイル・アプリケーションを作ることのできる開発環境の提供を目標としています。
MacユーザであればGitHubからソースコードをダウンロードすることで実際にMobiRubyを試すことができます。既に試したユーザからいくつかの動作不具合が報告されており、増井さんは是非とも興味のある人にはデバックに協力してほしい、と会場に呼びかけました。
MobiRubyの構成
次にMobiRubyの構成について説明しました。MobiRubyの構成要素としてベースとなるmrubyの層の上に4つのパッケージを開発しました。
1つ目のパッケージはmruby-cfuncで、mrubyからC言語の関数を自由に呼び出すことができる機能を有しています。2つ目のパッケージはmruby-cocoaで、Cocoa Touchのライブラリの呼び出しやオブジェクトの生成をRubyの層から透過的に行える機能を有しています。課題としてはmruby上でのメモリ管理のパフォーマンスやマルチスレッドが使えないことについて挙げ、これらの分野に強い人で協力してくれる共同開発者を募集しているとのことです。3つ目のパッケージはmruby-iosで、AudioPlayerでの実装を例に挙げ、主にiOSに特化したラッパーなどのユーティリティ郡をパッケージングした部分です。ユーザはこのラッパーを用いることでRubyを用いた簡単な構文でiOSの機能を利用できるようになるとのことです。4つ目のパッケージはmobiruby-commonで、AndroidとiPhoneで共通に使える機能をまとめたものです。例としてファイルオープンやランダム関数を挙げ、現状はrequireメソッドを実装しているとのことでした。
増井さんはこれらの開発を行う上で苦労している点として、mrubyは日々進化しており仕様が変わりやすいことを挙げました。そのため毎朝mrubyのアップデートとMobiRubyのテスト実行および不具合修正を日課にしているとのことです。
今後の展望
今後のロードマップとしては、Cocoa Touchライブラリのラッパー開発を進めていくことやユーザ向けのドキュメントの整備を進めることだそうです。さらに直近のタスクとしてはテストコードの拡充やlonglong型のサポートについて実装方法も含め検討中とのことです。
現状のMobiRubyの完成度としてはまだα版とのことで、実際の製品レベルの開発に用いるにはまだまだ機能が不足していると言います。例えばデバック機能が十分でないことや開発の前提としてiOSの知識が必須であることがユーザにとっての壁になると述べました。
増井さんがMobiRubyの開発を行うモチベーションとして、海外向けのポートフォリオを作りたいという想いがあるといいます。今後さらに開発を加速するためにもコントリビュータを募集中とのことで、海外で知名度を上げたい人やmrubyの成功の流れに乗って行きたいとおもう人はぜひ一緒に開発していきましょう述べました。
また、セッション後に増井さんとまつもとさんによるパネルディスカッションが行われ、mrubyの今後について質疑が交わされました。MobiRubyを実際の開発に使えるようになるのが楽しみですね。
Josh Laneさん「Release Early and Release Often: Reducing deployment friction」
Engine Yardに勤めるJosh Laneさんの発表です。JoshさんはEngine Yardの所在地であるサンフランシスコ在住であると自己紹介しました。その際紹介されていたサンフランシスコの写真がとてもきれいで、筆者もサンフランシスコを訪れてみたくなりました。（ スライド等はこちら ）
自己紹介の後、Joshさんはサブタイトルの"Reducing Deployment Friction"について触れ、このセッションではデプロイ時のことだけではなく、開発全体でのFriction（摩擦）を減らすことについて話をすると前置きしました。
Engine Yardのやり方
はじめにEngine Yardで実際に開発に使用している様々なツールや方法を紹介しました。
Engine YardではYouTRACKというタスク管理ツールを使用しているとのことです。彼らはタスクを開始するときにチケットを発行し、チケットに対応するコードの変更はフィーチャーブランチを作成し、そのブランチ上で対応する手順を踏んでいるとのことです。この際ブランチ名やコミットログにチケットのIDを含めることで、チケットとの対応付けを行なっているそうです。
また、ペアプログラミングやTDD（テスト駆動開発）を開発に取り入れているとのことで、特にペアプログラミングについては開発者が斜めに向かい合って座っている写真を紹介し、これがやりやすいベストなポジションなのだと言っていました。利用しているCI（継続的インテグレーション）システムの紹介も行いました。
EyBot、MASON
次に彼らが使用しているツールの中からEyBot（イーワイボット）とMASON（メイソン）について紹介しました。
彼らはcampfire を通して各種通知やリビルドを行なっており、そのためのEyBotというcampfireのbotを使っているとのことでした。
このbotはビルドの完了やテストの失敗、チケットの発行など、様々な情報を監視してcampfire上に通知してくれるものです。その他にもチャットに反応して画像の表示を行なってくれる機能などもあるそうです。Joshさんはクールでシンプルなbotだと紹介しました。
またMASONというツールも使用していると言います。これはただのジョブランナーでとてもシンプルなツールだということでした。彼らがブランチを切って、チケットの対応を行いブランチをマージをするとMASONはチケットが"マージされた"ことをマーキングし自動的にチケットを閉じ、続けて自動テストが行われるとのことでした。このようなツールによって、コードのshipping（出荷）を素早くすることとマスターブランチが常にデプロイ可能な状態であることを両立しているということです。実際過去には1日当たり20回前後のデプロイを行ったこともあると言います。
デプロイテクニックの紹介
本番環境へのデプロイはコマンド一発で、完全なデプロイプロセスが実施されるそうで、デプロイの際に自動的にタグ付けまで行なってくれる仕組みとなっているとのことでした。
Engine Yardではプロダクトは常にデプロイ用のブランチからshippingされることになっており、shippingされたバージョンとその変更に含まれるチケットは関連付けられて、そこからチケットに含まれる各コミットを追跡することができます。
この仕組みについてもMASONを使用することでうまくいっていると言及しました。
最後にデプロイ時のサーバーマイグレーションにかかるダウンタイムをゼロにするためのテクニックを紹介しました。この仕組みにはUnicornを使用しており、columnの追加とリネーム、削除の方法を工夫することによってダウンタイムなしでのサーバーマイグレーションができるとのことでした。
この後Joshさんへの質問の時間が設けられました。ここでは会場からデプロイの自動化に関する悩みなどが寄せられ、Joshさんがそれを解決するアイディアを披露する一幕を見ることができました。
以上が1日目のレポートになります。
