Chefを使ってサーバの管理運用をする際に作りこむ対象としてまっさきに思いつくのがクックブックです。コミュニティクックブックを組み合わせたり自作のクックブックを書くことで作り込みを行っている人は多いのではないでしょうか。しかしクックブックばかりを作りこむだけがChefを拡張する方法ではありません。

knifeプラグイン

knifeプラグインはknifeコマンドのサブコマンドを追加する形でさまざまな拡張を行う機構です。knife-soloもknifeプラグインの１つです。knifeプラグインはrubyを使って開発する事が出来、Amazon Web ServiceやDigital Oceanなどのパブリッククラウド環境のサポートを追加するものや、KVMやVMwareなどの仮想化環境をサポートを追加するものが多数公開されています。またコミュニティクックブックの公開や開発を支援するようなプラグインも公開されています。下記のプラグインはChefが公式にメンテナンスしているプラグインです。

上記の他にはknife-eucalyptus knife-hp knife-terremark knife-blueboxなどのプラグインがあり様々な仮想化環境のAPIへ対応する機能を提供します。

また、コミュニティプラグイン公式ドキュメント にも50個以上のコミュニティによって作成されたプラグインがリストアップされています。コミュニティプラグインにはChef公式プラグインでサポートしない様々な仮想化環境への対応や、パブリッククラウドのAPI、Chef利用のワークフローそのものを拡張するものなど幅広いプラグインが存在します。その中でも代表的なプラグインはつぎのとおりです。

knifeプラグインはRubyGemsとして作られており、gemコマンドを使ってインストールを行います。

$ /opt/chef/embedded/bin/gem install knife-azure

標準ではChefに同梱されているgemの配下にプラグインがあるとChefクライアントはみなしています。その為、インストールしたRubyGemsが同じ場所に入るようにgemコマンドもChefに埋め込まれたコマンドを使います。gemの配置先を自分自身でコントロールしている場合は/opt/chef/embedded/bin/のパスを省略してインストールする事で普段使っているRuby環境と同じ場所に配置されます。

$ gem install knife-azure

上記の場合は利用しているRuby環境に見合った場所にRubyGemsがインストールされます。複数の方法を併用した場合に状況がわかりづらくなる事もあるので注意してください。特に理由がなければ開発者のPCなどワークステーションでは通常のgemコマンドを使い、実際の実行環境になるノード側ではChefに同梱されたGemを使うのが良いでしょう。

ohaiプラグイン

ノードのさまざまな情報を収集するohaiはプラグインを利用する事で独自の項目を収集し、Chef Server上に集約したり、クックブック内で参照できます。ohaiプラグインも簡単なRubyコードを記述する事で任意の処理をohai実行時に実行し結果を情報としてChefに提供できます。
ohaiのプラグインはgemなどの形にはなっていませんが、コミュニティによってさまざまなプラグインが作成されており公式ドキュメント内にリストアップされています。

chefプラグイン

knifeやohaiではなくChefクライアントの実行時の挙動を拡張するプラグインもRubyGemsとして公開されています。公式ドキュメントにリストアップされている以外のRubyGemsも日々公開されていますので用途にあったものがあれば導入したり、拡張するのがよいでしょう。

もちろん自作も可能

knifeプラグイン、ohaiプラグイン、chefプラグインのいずれも自作できます。コミュニティで公開されているプラグインの内容は公式ドキュメントの内容を参考にすればChefの細かな挙動をカスタマイズし、よりスムーズな運用ができるでしょう。

• Custom Knife Plugins — Chef Docs
• About Ohai — Chef Docs

The post Chefを拡張する3つの方法 appeared first on Engine Yard Blog JP.

PHPなどのさまざまな言語のオープンソースプロジェクトのCI環境として利用されているTravis CIでWebベースのテストを実行してみました。
通常は純粋なコードベースのユニットテストを実行する事が多いかと思いますが、CMSやEコマースエンジンなどオープンソースで配布し、インストールして使うようなソフトウェアではWebブラウザベースでの機能テストを自動化したいというニーズがあるでしょう。Travis CIにはfirefoxがインストールされておりブラウザベースのテストが出来る事は知っていたのですが、今回年末年始の宿題的にテストを実行する為の設定をひと通り行ってみました。

説明を抜きにして動作が見たい方はGitHubとTravis CIへどうぞ

yandod/candycane
https://github.com/yandod/candycane
candycane on Travis CI
https://travis-ci.org/yandod/candycane

テストの対象

今回はCakePHPに移植されたRedmine,CandyCaneのインストーラーを使ったインストールと管理画面へのログインをテストします。これにより機能の追加変更が初期のインストールプロセスを壊さないことを継続的に確認する事を目的としています。インストーラー及び管理画面へのログインには下記のような要素があります。

• Webブラウザからインストール画面にアクセス
• AJAXを利用した実行環境の確認、次のステップへのリンクのクリック
• 初期データベースの自動作成
• 管理者ユーザーでのログイン
• 管理者画面からの設定変更

今回は簡単なフローになっていますが、インストーラーと管理画面それぞれにJavaScriptを使った動的な画面制御が存在しています。この部分はブラウザでのテストを行わないと自動化できない部分でこれまで、自動化したテストができていませんでした。

ローカル環境でのテスト環境の構築

まずはローカル側でSeleniumとfirefoxを使ったテストの実行環境を構築する必要があります。検索したのですが残念ながら目的にあうChefのクックブックは見つからず、(中途半端なものは存在)今回はクックブックを作成しました。このクックブックをBerkshelfを経由してVagrantのVMに適用することでXvfbとfirefoxにSeleniumを使ったテスト環境が構築できます。またSeleniumの実行に必要なJavaは動けばいいのでこれもコミュニティクックブックをBerkshelfから突っ込んで適用します。クックブックの記述にあたっては下記のような試行錯誤がありましたが、皆様につきましては完成したクックブックを適用して頂ければ4メートル級の巨人の肩に乗れます。

• PhantomJSのビルドにかかる様々な手間
• SeleniumとFirefoxのバージョンの相性。
• xvfbのセッションのサービス化
• java -jarで起動したプロセスの再起動

yandod/selenium-grid
https://github.com/yandod/selenium-grid

Vagrantfile

Vagrant.configure("2") do |config|
  config.vm.box = "precise64"
  config.vm.box_url = "http://files.vagrantup.com/precise64.box"
  src_dir = './'
  doc_root = '/vagrant_data/app/webroot'
  app_name = 'candycane'
  config.vm.network :forwarded_port, guest: 80, host: 8080
  config.vm.synced_folder src_dir, "/vagrant_data", :create => true, :owner=> 'vagrant', :group=>'www-data', :mount_options => ['dmode=775,fmode=775']
  config.berkshelf.enabled = true
  File.open('Berksfile', 'w').write <<-EOS
    cookbook 'apt'
    cookbook 'php5_ppa', '~> 0.1.1'
    cookbook 'omusubi', git: "https://github.com/yandod/omusubi.git"
    cookbook 'java'
    cookbook 'selenium-grid', git: "https://github.com/yandod/selenium-grid.git"
  EOS
  config.vm.provision :chef_solo do |chef|
    chef.add_recipe "apt"
    chef.add_recipe "php5_ppa::from_ondrej"
    chef.add_recipe "omusubi"
    chef.add_recipe "java"
    chef.add_recipe "selenium-grid"
  end
end

余談：
自分しかやっているのを見たことがないですが、BerksfileをむりやりVagrantfileに埋め込むやり方が管理が楽なので気に入っています。あくまでVagrantfileだけでBerkshelfの恩恵を受けられます。

コミュニティクックブックについての衝撃的な知見

https://twitter.com/sawanoboly/status/418726580152573952

Seleniumのテストケースの記述

Seleniumを使ったテストケースについてはPHPUnitのサブパッケージであるPHPUnit_SeleniumをComposerで導入して記述しました。SeleniumIDEで生成したテストケースを使ってPhantomJSから実行する方法はテスト結果の出力があまり美しくありませんが、PHPUnit経由で実行すれば通常のPHPUnitのテスト結果と同様にCIに組み込むことができます。PHPUnit_Seleniumの利用方法については公式ドキュメントがあります。

PHPUnit Manual – 第17章 PHPUnit と Selenium
http://phpunit.de/manual/3.7/ja/selenium.html

実際にテストを記述してみて分かった間違いやすい点は下記の通りです。

• PHPUnit_Extensions_SeleniumTestCase
  Selenium RCの古いAPIを使ったテストケース。スクリーンショットの取得やさまざまなアサーションが実装されている。
• PHPUnit_Extensions_Selenium2TestCase
  Selenium WebDriverの新しいAPIを使ったテストケース。スクリーンショットの取得やアサーションなどは設計が変わった事で廃止されている。フラグを立てるだけの方法からコールバックとリスナーを使った実装に変更。
• 適度なウェイトを設定しないとコード変更をしていなくてもテストが失敗する。
• 一定の条件を満たすまで待機する場合はコールバックを利用する。
• URLは絶対パスで指定する

最大の落とし穴はPHPUnit_Extensions_SeleniumTestCaseとPHPUnit_Extensions_Selenium2TestCaseが全くの別物である点です。クラス名は1文字違いですが、共通するメソッドはほぼ無い別クラスです。Selenium RCがメンテナンスされていない現状からすると、基本的にはPHPUnit_Extensions_Selenium2TestCaseを利用するべきという事になります。

また所定のDOMなどが出現するまで動的に待機する場合にはコールバックを使った待機をしますが、ドキュメントにこの方法の記載がありません。PHPUnit自身のテストケース内に実例があるのでこれを参考に実装しました。

    public function testImplicitWaitIsRestoredAfterFailure()
    {
        $this->url('html/test_wait.html');
        $this->timeouts()->implicitWait(7000);

        try {
            $this->waitUntil(function($testCase) {
                $testCase->byId('testBox');
                return TRUE;
            });
            $this->fail('Should fail because of the element not exists there yet');
        } catch (PHPUnit_Extensions_Selenium2TestCase_WebDriverException $e) {}

        // in this case - element should be found, because of the implicitWait
        $element = $this->byId('testBox');
        $this->assertEquals('testBox', $element->attribute('id'));
    }

実際にCandyCaneのインストーラーを実行するテストは下記のようになりました。インストーラーにアクセス後、ページのタイトルや次の画面へのリンクの表示を確認しながらステップを進めていく形です。また引用では省略していますが、最終的には管理者ユーザーでログインし、メール配信の設定を変更して保存するという管理者機能の挙動をテストしています。

candycane/app/Test/Case/Selenium/InstallerTest.php at master · yandod/candycane

        $this->url('http://127.0.0.1/cc_install/cc_install/');

        $this->waitUntil(function($testCase){
            return $testCase->title();
        });

        $this->assertEquals('Installation: Welcome - CandyCane', $this->title());

        $this->timeouts()->implicitWait(3000);
        $this->waitUntil(function($testCase){
            $str = $testCase->byId('next-link')->text();
            return !empty($str);
         },100000);


        $link = $this->byId('next-link');
        $this->assertEquals('Click here to begin installation', $link->text());
        $this->moveto($link);
        $this->click();

        $this->assertEquals('Step 1: Database - CandyCane', $this->title());

        $this->select($this->byId('InstallDatasource'))->selectOptionByValue("mysql");
        $input = $this->byId('InstallDatabase');
        $input->clear();
        $input->value('test_candycane');
        $form = $this->byId('InstallDatabaseForm');
        $form->submit();

vagrant upし、下記のコマンドを実行する事でテストが実行できるようになりました。

cd /vagrant_data ;\
mysql -u root -e "drop database if exists test_candycane; \
create database test_candycane;";\
./vendor/bin/phpunit app/Test/Case/Selenium/InstallerTest.php
PHPUnit 3.7.28 by Sebastian Bergmann.

Configuration read from /vagrant_data/phpunit.xml.dist

.

Time: 9.12 seconds, Memory: 3.25Mb

OK (1 test, 9 assertions)

Travis CI上でのテストの実行

最後にTravis CI上で同じようなテストを実行できるように.travis.ymlを調整します。Travis CIのインスタンスにはfirefoxやXvfbなどは導入済みですので、Selenium Serverのダウンロード、Xvfbの起動などを before_scriptに設定します。

before_install:
  - "export DISPLAY=:99.0"
  - "sh -e /etc/init.d/xvfb start"
  - "wget http://selenium.googlecode.com/files/selenium-server-standalone-2.39.0.jar"
  - "java -jar selenium-server-standalone-2.39.0.jar > /tmp/selenium.log 2> /tmp/selenium.error &"

また、Webからのアクセスを受けるにはApache2を経由してphp-fpmにアクセスする形になります。この際にvhostsの設定ファイルなどをリポジトリに含めておき、同じくスクリプトから設定します。

before_script:
  - sudo apt-get install apache2 libapache2-mod-fastcgi
  - sudo cp ~/.phpenv/versions/$(phpenv version-name)/etc/php-fpm.conf.default ~/.phpenv/versions/$(phpenv version-name)/etc/php-fpm.conf
  - sudo a2enmod rewrite actions fastcgi alias
  - echo "cgi.fix_pathinfo = 1" >> ~/.phpenv/versions/$(phpenv version-name)/etc/php.ini
  - ~/.phpenv/versions/$(phpenv version-name)/sbin/php-fpm
  - mkdir build
  - cp app/Test/travis/travis-ci-apache build/travis-ci-apache
  - sudo cp -f build/travis-ci-apache /etc/apache2/sites-available/default
  - sudo sed -e "s?%TRAVIS_BUILD_DIR%?$(pwd)?g" --in-place /etc/apache2/sites-available/default
  - sudo service apache2 restart

これでVagrantのVMと同様の方法でテストが実行可能になりました。

今回の方法はやや泥臭い部分もありますが、PHPで動作するアプリケーションをSeleniumから自動でエンドツーエンドのテストを実行できる面白い方法です。オープンソースのプロダクトを公開している方はぜひテストの組み込みとTravis CIへのタスクの登録をしてみては如何でしょうか。コードを変更してもインストーラーや初期のログインなどの重要な機能が動作している事が担保されるというのはとても良いですよ。

The post Travis CI上でPHPアプリのWebベースのテストを自動化する appeared first on Engine Yard Blog JP.

商用アプリケーションにおけるパッチ適用

安定稼働しているアプリケーションシステムに対して、パッチを適用することほど億劫な作業はない、と思ったことのある保守・運用の担当者の方は多いのではないでしょうか。

私はERP/CRMパッケージを開発・販売する米国のベンダーの立場として、パッケージ導入に10数年にわたってお客様やビジネスパートナーを支援してきましたが、安定稼働しているシステムへのパッチ適用はまったく歓迎されるものではありませんでした。特にイントラネットでの利用が多いERPをご利用のお客様は、その傾向が強かったと言えます。

そのような状況を知りつつも、以下のような種類のパッチをお客様に提供し、それらの適用を促し続けていました。

• セキュリティアップデートパッチ (四半期に一度)
• 法改正用メンテナンスパッチ (半年に一度)
• 不具合修正のメンテナンスパッチ (随時)
• アップグレードパッチ (随時)

それは、パッチ適用を行っていただかなくては、不具合による障害や(たとえイントラネットのERPであったとしても)セキュリティの脆弱性によってサイバー攻撃の標的になりかねないことが理由としてあります。しかしそれだけではなく、パッチ適用をしないことで製品のアップグレードが保証されなくなり、保守費用をベンダーに支払っても、正規の技術サポートが受けられなくなる、もしくはサポートの範囲が限られるなどのベンダー都合の制約につながるためです。

オンプレミス形態のERP/CRMシステムの場合、OS層、ミドルウェア層(DBサーバー、APサーバー、開発ツール)、ランタイム層、アプリケーション層(共通基盤、会計、製造、人事など)といった、ありとあらゆるレイヤーへのパッチ適用が必要でその数も膨大になるため、どのレイヤーにどのレベルまでパッチを適用するかを、パッチ適用実施の半年前に定めるプロジェクトもある程です。それほどまでに骨の折れる大変な保守作業です。

そういう意味で、SaaS形態のアプリケーションを採用する利用者の視点に立てば、すべてのレイヤーのパッチ適用をSaaSベンダーに完全に委任できる画期的なソリューションであると言えるでしょう。

そしてまた、SaaS形態でアプリケーションを提供する先進的なアプリケーション開発ベンダーの視点に立てば、主なPaaSでアプリケーションを稼働させることで、プラットフォーム層(OS層、ミドルウェア層、ランタイム層)までのパッチ適用の保守作業をPaaSベンダーに委任でき、アプリケーションの継続的な開発保守に専念できるという大きなメリットを享受できます。

PaaSを用いた場合のパッチ適用

主なPaaSベンダーは、OS層、ミドルウェア層(DBサーバー、APサーバー、開発ツール)、ランタイム層における保守運用サービスを提供しています。つまり、そのレイヤーに対する各種パッチの検証はPaaSベンダー側で予め行い、それらのパッチ適用までベンダーで行うか、もしくは容易に適用できる仕組みを提供するかのいずれかに分かれます。

PaaSと称するサービスベンダーの中には、仮想マシンのプロビジョニングとアプリケーションのデプロイの仕組みを提供しつつも、プラットフォーム層に対するパッチ適用、もしくはそれを支援する仕組みの提供まで行っていないものもあります。そのようなPaaSは、本当の意味でPaaSとは言えないでしょう。

ここでは本当の意味でPaaSと言えるサービスにフォーカスを置いて話しを続けます。

一般的に「パッチ適用までベンダーで行う形態」は「マルチテナント PaaS」を提供しているPaaSベンダーとされます。それに対して「パッチ適用を簡易的に行う仕組みを提供する形態」は「シングルテナント PaaS」を提供しているPaaSベンダーとされています。

※「シングルテナント PaaS」と「マルチテナント PaaS」の優位性については、ブログ記事「PaaSレイヤーの「シングルテナント」と「マルチテナント」はどちらが優位か？」をご参照ください。

ではここで、パッチ適用という観点で「シングルテナント PaaS」と「マルチテナント PaaS」の長所と短所をご紹介します。

ブログ記事「PaaSレイヤーの「シングルテナント」と「マルチテナント」はどちらが優位か？」でご紹介しているとおり、Engine Yardは「シングルテナント PaaS」を提供するベンダーであり、われわれのお客様が『Engine Yardは商用で利用するのに適しているPaaSである』と評価してくださる理由がこの表に込められています。

商用のアプリケーションに対するパッチ適用のタイミングは、PaaSベンダーにコントロールされるべきものではありません。プラットフォーム層のパッチを適用することによって、動作していたアプリケーションに障害が起きては、お客様のビジネスの大きな機会損失にも繋がりかねないためです。

そこでEngine Yardでは、パッチ適用のベストプラクティスとして、クローン環境を構築する機能と組み合わせて、以下の手順を定めています。

パッチ適用のベストプラックティス：

1. クローン環境を構築する
2. クローン環境にパッチ適用を行う
3. クローン環境でアプリケーションの検証を行い、障害が発生しないことを確認する
4. 本番環境をアップグレードする
5. クローン環境を停止して削除する

ステップ3のパッチ適用後の動作検証については、お客様ご自身で行っていただく必要がありますが、ステップ1、2、4、5については、簡単に実施できる仕組みを提供しています。

※ クローン環境の構築に関しては、ブログ記事「アプリケーション環境のクローン機能」をご参照ください。

Engine Yardのパッチ適用

Engine Yard Cloudでは、ダッシュボードと呼ばれるGUIの画面から次の手順で簡単にパッチ適用を行うことができます。

1. パッチ適用が必要であることを確認
   Engine Yard Cloudのアプリケーション環境の詳細ページに表示される「Upgrade」ボタンが青くなり「▲」マークが表示されている場合、パッチ適用が必要であることを意味します。




2. どのようなパッチを適用する必要があるかを確認
   「Upgrade」ボタンをクリックすると、ご利用のアプリケーション環境に対して適用が必要なパッチがリストされます。




3. パッチ適用を実施
   「Upgrade Environment」ボタンをクリックし、適用の完了を待ちます。
   
   本番環境にパッチ適用を行う場合には、CLIを用いてメンテナンスモードに切り替えてから実施することをご検討ください。メンテナンスモードの切り替えコマンドについては、「eyコマンドの基本」をご参照ください。

なお、この機能で適用されるパッチとしては以下のような種類が含まれます。

• プラットフォームのバグ修正
• プラットフォームの新機能追加
• プラットフォームの既存コンポーネントのチューニング
• プラットフォームの既存コンポーネントのアップデート
• プラットフォームの既存コンポーネントのセキュリティ脆弱性
• プラットフォームの新規コンポーネントの追加
• 新規の仮想インスタンス種類への追加対応
• アドオンとの連携設定の追加・修正
  など

参考情報

ここでは、本トピックに関連して参考になる情報のリンクをご紹介します。必要に応じて、ご覧いただければと思います。

• PaaSレイヤーの「シングルテナント」と「マルチテナント」はどちらが優位か？
• アプリケーション環境のクローン機能
• 環境のアップグレード
• eyコマンドの基本
• Upgrade an Environment (英語版)
• Using Application Maintenance Pages (英語版)

The post 商用アプリケーションにおけるパッチ適用 appeared first on Engine Yard Blog JP.

サンフランシスコのEngine Yard オフィス

Chef、 PHPにつづき、Rubyの今年2013年を今年人気を集めた記事をテーマ別にまとめました。はてなブックマークの数と一緒に振り返っていきます。今年の2月24日にRuby20周年を迎え、ruby-2.0.0がリリースされました。他にもRails4のリリース、RubyKaigiの再開など多くのトピックがありました。

目次

• Ruby20周年！そしてruby-2.0.0, ruby-2.1.0のリリース
• 言語実装への興味、ガベージコレクションほか
• Rubyのひろがり
• Rails4のリリースとRailsの成熟
• テスト、CI
• 開発環境、手法、デザイン
• チュートリアル、Ruby, Railsを始める
• Ruby 話題の本
• 作りました！
• 新しいライブラリ
• ログ・マネージメント fluentd
• Tips! コーディング
• クライアントサイドとバックエンド
• Rubyを取り巻く環境、組織
• TwitterがRubyからJVM 言語群へ。関数型言語のトレンド
  

Ruby20周年！そしてruby-2.0.0, ruby-2.1.0のリリース

Rubyが20周年を迎え、その丁度記念日となる2月24日にruby-2.0.0-p0がリリース。クリスマスには2.1.0がリリースされました。そして、長らくお世話になったruby-1.8.7が引退しました。

言語実装への興味、ガベージコレクションほか

言語そのものの実装にも多くの興味が寄せました。Crubyのコミッターの方々のブログを中心に多くのブックマークが付けれれました。

Rubyのひろがり

iOSアプリ、任天堂3DS、OpenFlow、エクセル、結婚式からダジャレまでRubyで作られたものは様々な所に広がっています。さらにユーザも中学生から女優までさまざま。mruby, RubyMotionの話題も追加し、人気を集めたRubyでつくらたものを集めてみました。

Rails4のリリースとRailsの成熟

Railsの話題はつきません。今年はRails4がリリースされ、たくさんのノウハウが共有されました。

テスト、CI

開発は終わるものではなく、継続的に続けていくものに変わりました。効率よく効果的に開発していく必要があります。Ruby、Railsと切っても切り離せない、テスト、CIについて人気を集めた記事をまとめました。

開発環境、手法、デザイン

プログラマは常に開発環境、手法について疑問を持ち改善していきます。また、プログラマがデザインを学ぶというテーマも見られました。年末年始に自分の開発環境を見直すのもいいかもしれません。

チュートリアル、Ruby, Railsを始める

新しいことをはじめるために必要な情報、自分が始めた時に困ったこと、役に立ったことをまとめた記事も多く投稿されました。

Ruby 話題の本

学ぶためのソースはウェブだけではありません。Rubyについて話題になった本とその感想も人気を集めました。

作りました！

実践を大事にするプログラマー。ハッカソン、ゴールデンウィーク、休職中などに、作りその苦労や楽しかったことを共有した記事にもたくさんブックマークがされました。

新しいライブラリ

昔先輩のプログラマーにこんなことを言われました。「自分が解決したい悩みがあったらまず、同じことで困っている人がいて、解法を持ってないか調べてみなさい」と。「もしそれで、解法が見つからないならばそれをライブラリーやサービスにしたらいい。ただ、ほとんどの問題はすでに誰かが壁にあったっているから、解法はすでに世の中にある」と。
ライブラリーの紹介などなど、どんなものがあるのかチェック！

ログ・マネージメント fluentd

今年の人気ブックマークを調べていてダントツで人気があったのが、ログ・マネージメントのライブラリfluentd。クラウドの普及によるサーバの非固定化、またデータ解析の重要性などの傾向の結果かもしれません。

Tips! コーディング

まとめきれなかったけど、人気のあるTips、コーディングについての記事です。

クライアントサイドとバックエンド

Backborn.js, Ember.js, Angular.js, Meteorなど、たくさんのクライアントサイドJavascript Frameworkがでて、人気を集めています。RubyやRailsのプログラマはそれをどのように捉えているのでしょうか。バックエンドについての記事と一緒に紹介します。

Rubyを取り巻く環境、組織

Rubyを取り巻く環境について、イノベーション、OSS、他の言語やモバイル。そして働く組織の話も多くのブックマークを集めました。

TwitterがRubyからJVM 言語群へ。関数型言語のトレンド

最後にTwitterがRubyからJVM 言語群への移行をおこなった（おこなっている）。また、クロック数の限界とCPUコア数の増加から、関数型言語への注目が集まりました。これからのRubyやプログラミングについて考えるのにいいトピックだとおもい、このトピックで今年2013年の話題の振り返りを終わりにします。

2013年人気のあった記事を話題別にまとめてみました。トレンドや見逃していた記事、やり残したことが見つかると幸いです。

The post 2013年Rubyの話題を一挙に振り返るまとめ appeared first on Engine Yard Blog JP.

2013年も本当にあとわずかになりました。
本日は今年話題になったPHPについての記事を公式のリリースやはてなブックマークから抽出してきた内容を元に今年を振り返ってみましょう。PHPにとって今年はどのような一年だったのでしょうか。

参考：
2012年のPHP周辺の話題振り返り | Engine Yard Blog JP

PHPのバージョン

2013年中にリリースされたPHPのバージョンは5.3、5.4、5.5の3系統で合計29のリリースが行われました。リリースサイクルはほぼ毎月という形でした。またPHPの公式サイトがレスポンシブ対応の新しいデザインに切り替わりました。詳細は下記の通りです。

[重要] 頻繁にバージョンアップされるPHPを最新の状態に保つにはEngine Yard Cloudの利用をお奨めします。

PHP5.5の新機能

上記のとおり、6月にPHP5.5がリリースされました。機能の追加や廃止を含むリリースでメジャーバージョンアップではありませんが、重要なリリースです。PHP5.5で追加された新機能は下記の通りです。

• ジェネレータの追加
• finally キーワードの追加
• 新しいパスワードハッシュ API
• foreach が list() に対応
• empty() が任意の式に対応
• array リテラルと string リテラルのデリファレンス
• ::class によるクラス名の解決
• OPcache 拡張モジュールの追加
• foreach が非スカラーのキーに対応
• Apache 2.4 ハンドラが Windows に対応
• GD の改良

その他、廃止される機能などの詳細はPHPの公式ドキュメントをご覧ください。

ブログ記事の総評

今年話題になったPHPに関する記事から厳選した記事が下記の20個の記事です。見逃した記事があればぜひともチェックしてみてください。

• すぐれた PHP ライブラリとリソース
• Vagrant で作る PHP 開発環境
• 安全なPHPアプリケーションの作り方2013
• PHPでデータベースに接続するときのまとめ - Qiita [キータ]
• Devsの常識、DBAは非常識
• ソースコード20万行の大規模サイトのPHPを5.1から5.4に上げるためにやったことまとめ - DQNEO起業日記
• 16の言語と57のフレームワークを比較したベンチマークが凄い | A-Listers
• 本当に怖いパフォーマンスが悪い実装 #phpcon2013
• XSS再入門
• モダンPHPチュートリアル (LLまつり版) // Speaker Deck
• Spikaを公開して起こった事 - ヨーロッパで働く社長のブログ
• いまどきのPHP開発ノウハウを詰め込んだ『PHPエンジニア養成読本』が出るので、見所をまとめてみるよ - 頭ん中
• PHP の正規表現があまりに複雑なのでまとめてみた - A Day in Serenity @ kenjis
• PHPのinterfaceとは何か - 泥のように
• PHP開発環境のサンプルVagrantfile - Shin x blog
• 「CIを半年間まわしてみて」というお題でLTをしてきました - kaz29
• PHP 5.5の新機能：さっくり理解するPHP 5.5の言語仕様と「いい感じ」の使い方 (1/2) - ＠IT
• 「WEB+DB PRESS」で艦これで有名なDMMの開発体制の全貌が明らかに - 東洋黒客の凱旋
• PHPの開発に使えるVagrantfileのまとめ | Engine Yard Blog JP
• 2013年において注目すべき PHP フレームワークは Laravel - Sarabande.jp

それぞれの月の記事と概要は下記の通りです。

1月:PhpStormについてのスライドが話題に

1月の話題で特に注目すべきなのはFacebookが開発し公開しているPHPの仮想マシン、HipHopVMについての記事とPHPStormについて触れたスライドではないでしょうか。HipHopはPHPをC++に変換して実行するというコードトランスレーターをJITコンパイラへと近づけていく意欲的な試みです。この機能は最終的にはPHP本体に取り込まれるような可能性もあり今後も注目が集まりそうです。

また今年はPhpStormの利用が広がりましたが、その背景が@hisaterutanakaさんのスライドに述べられています。

「PHPはJavaの次に静的解析しやすい言語。これはRubyが気付いていないPHPの長所」 ―PHPメンターズと朝まで過ごしたときの言

PHPは言語としての弱さを指摘されることも多いですが、上記のようにコード生成や解析がしやすいという側面が先進的な取り組みの基礎になっているとも言えるでしょう。また年末年始の時間を利用したのかサイトを作ってみたという話題も（掲載できないようなサイトも含めて）話題になっていたのが特徴です。

2月:正規表現の話題とセキュリティ

2月はさまざまなTIPS系の話題が多く、何度か登場する正規表現の話題とセキュリティについての話題が出ています。また今年は一年を通じてエディタの話題も多かったのですが2月にVimの話題が出ています。

3月:PHPを何故使うのか

3月はPHPを何故使うのか、という意義について述べた記事が話題になっています。言語仕様の至らない点を指摘するといういつもの流れもある一方でとにかく動くサービスやプロダクトを作るべしという事を述べた体験談が見受けられます。

4月:LaravelとZend OPCache

4月はLaravelとZend OPCacheについての記事が話題になっています。軽量さで人気が高まってきているLaravelとAPCに変わるキャッシュとして標準化されるOPCacheは今後は実際に利用されるケースが増えてくるでしょう。
また有用なライブラリのリストを翻訳して紹介したエントリが話題になっていました。

5月:ベンチマークに関する記事とPaaS

5月で目を引くのはベンチマークに関する記事とGoogle AppEngineのPHP対応の記事でしょう。ベンチマークについては随時情報が更新されており、PHPはどちらかというと遅い部類に分類されていますがPhalconが特に高いパフォーマンスを出しており注目されました。以降、実際にPhalconを使っているという話題や使ってみたいという声の引き金になった話題と言ってよいでしょう。

6月:学習への関心

6月の記事は個別のトピックというよりも体験談や学習方法といった内容が多いです。見返してみると今年はどのように学習しどのように使うのかといった話題やオンラインで学習できるコンテンツへの言及が多かったように思います。
実際に勉強会などでお会いする方でもドットインストールで勉強しているというような方に会う機会が増えたなと感じました。

7月:Vagrant、Phalcon、浮動小数点

7月あたりからはPHPの開発にVagrantを使うという話題を聞くことが増えてきます。実際にPHPカンファレンス関西などでの講演を受けて試してみようという人が増えてきたのでしょう。またPhalconについてまとまった資料が出てきた事で注目が集まりました。
一方で浮動小数点というPHPにとっては伝統芸といってもよい話題も出てきています。

8月:モダンPHPとムック本

8月はLLまつりで行ったモダンPHPチュートリアルの記事と資料が話題になりました。このセッションではComposerの利用を強く勧めていますが、Composerも今年特に利用が進んだツールでしょう。またそういったさまざまなノウハウをまとめた「PHPエンジニア養成読本」が出版され、今年出版されたPHPの書籍の中でも特に注目が集まりました。

9月:セキュリティ問題とカンファレンス

8月の末にWordPressを利用しているユーザをターゲットにした大規模な攻撃が行われ、その問題についての考察が話題を呼びました。また9月にはPHPカンファレンスが開催されさまざまな資料が公開されました。PHPカンファレンスについてはこちらのページに資料が集まっています。

10月:オープンソースのメッセンジャーが話題に

PHPでバックエンドを実装したメッセンジャーアプリが公開され話題を呼んでいます。当初は炎上的な展開でしたがGitHubを利用してソーシャルにコードが改善され、またその際にはVagrantや継続的テスト、Composer、Symfonyなどのナレッジが効果的に活用されケーススタディとしても価値があるエピソードになりました。

11月:正しい手法への関心

11月は大規模なマイグレーションの事例やセキュリティ関連の話題に注目があつまりました。また採用市場というちょっとかわった観点の話題も登場しています。

12月:新機能の利用が進む

12月も引き続きセキュリティ関連の話題などがありましたが、PHP5.5の新機能であるジェネレータについての記事が印象的です。カンファレンスなどでも機能の概要は紹介されていましたが、実際に利用する中で得た知見について耳にする機会が増えてきました。
PHP5.5もリリースから約半年が経過していますが、まだ利用していない方は早めの導入とジェネレータなどの新機能を効果的に活用する事をご検討ください。

まとめてみるといかに最新のトピックをキャッチアップし続けるのが大変なのかという気もしてきますが、このタイミングで一気に追いついて2014年に備えましょう。みなさん、良いお年を。

The post 2013年PHPの話題を一挙に振り返るまとめ appeared first on Engine Yard Blog JP.

早いもので2013年もまもなく終わります。特にChefについては今年は大きな飛躍の1年になりました。Chefについては話題の流れも多く、自身としても何があったのかを即座には思い出せません。今回はすでにChefを使っている人の話題の復習や、Chefをまだキャッチアップしていない人が今からでも間に合う情報収集としてまとめてみます。

はてなブックマーク上でも2013年の記事でChefタグが付けられた3ブックマーク以上の記事が800エントリを超え、ブックマークの回数は3万2千回を超えるというとてつもない状況です。今回はその中でも100ブックマーク以上が付いた記事の中から特に注目が集まった話題を時系列で振り返ります。

2013年1月:「兆し」

2013年早々にChefの大躍進の契機になるエントリが@naoya_itoさんのブログに投稿されます。「開発メモ#4 : EC2スナップショットとの差分は chef-solo で解決」と題されたエントリでchef-soloを使ってEC2のスナップショットに新しいIPアドレスを反映するというような流れが紹介されています。今の時点ので考えるとこれはプロビジョニングというよりもオーケストレーションのような部分に近く、ソフトウェアのインストールなどではなく動作環境に適切な情報を埋め込む為の利用用途になっています。

ただすでにこの時点でツールチェインとしてレシピに対するテストを実行する事が示唆されています。

• ローカルでレシピ (chef) をがりがり書く
• chef レシピの lint foodcritic でチェック
• git commit して github に push
• chef-solo を Cinnamon を使って、リモートで実行
• リモートでは git fetch で最新のレシピを取ってきて、chef-solo が実行される

foodcriticは実際にクックブックを動作させるのではなく、シンタックスベースでのテストを行いますがすでにテストの必要性が提起されています。またこのエントリ内でも言及されていますが、@sawanobolyさんによる「Cucumber, ChefSpecとchefでテスト駆動のサーバ構築管理」と題されたエントリが公開されておりサーバーの構成を継続的にテストする手法が提示されています。

2013年2月:「勉強会、AWS OpsWorksの発表」

2月はEngine Yardで開催した「初めてのChefの教室」でのコンテンツなどに注目が集まり、方法論の交流が活発になりました。またFacebookでの大規模な採用事例やその知見を反映したChef11が公開されました。
Chefとセットで使われる事の多いツール、Vagrantが@naoya_itoさんのブログで紹介され事実上Chefを使う際の必須ツールになったのも2月の出来事でした。

2013年3月: 「入門 Chef Soloとserverspecの登場」

3月の出来事はなんといっても電子書籍「入門Chef Solo」の出版が大きいです。KDP上での出版という動きの中でもかなり早期のものでランキング上位に今でも入っています。一方で「Chefに挫折した」という層も出始めたのかFabricについての記事にも注目が集まりました。現在でも話題になっているserverspecに注目が集まったのも3月の出来事です。

Chefが中心の記事ではないですが「同僚の外国人プログラマ観察記録」はVagrantやBerkshelf、SublimeText2、NewRelicなどを使って楽をしていた外国人プログラマの姿が紹介されています。この時点ではある種「未来的なプログラマ像」のように描かれていたように思いますが、同じようなスタイルを取っている人は増えてきているかもしれません。

2013年4月: 「研修での採用事例とAnsible」

4月ということで研修の一環としてChefなどを使う事例が紹介されるようになります。サーバーの設定作業をChefなどを使って行うのが当たり前というエンジニアが続々と誕生していったという事でこれは後に繋がりそうです。またChefに馴染みにくかった方の中でAnsibleやFabricなどの同種のツールの活用も紹介されています。

2013年5月: 「serverspecを使ったCIが定着」

5月の時点ではこれまでに話題になってきた技術の組み合わせが普及する時期だったようです。さまざまな場面でserverspecとChefを組み合わせた事例が紹介されており、ChefSpecなどを使ってテストを行うという人よりもserverspecから始める人が主流になっていったようです。

2013年6月:「VPSでの事例とDocker」

引き続き利用が拡大し、AWSやVirtualBox以外の環境での利用例が話題になっています。また最近の話題をさらっているDockerが@naoya_itoさんによって紹介されています。

2013年7月: 「メディアへの露出」

7月にはVagrantの作者のMitchell Hashimotoさんが来日し講演した事がメディアにも掲載されました。DevOpsの流れの中でChefはツールセットの中の一部として定着し引き続き注目されています。またPHPカンファレンス関西での紹介がきっかけにPHPの開発にVagrantを使うという話題が出始めたころでもあります。

2013年8月: 「Immutable Infrastracture」

8月は引き続き活用の事例が話題になっています。特に印象的なのは現在のバズワードである「Immutable Infrastracture」についてのエントリが話題になっていた点です。f440さんのこの記事の書き出しの部分は簡潔にImmutable Infrastractureとはなにか、どのような経緯で話題に上がったかを述べています。

Immutable Server や Immutable Infrastracture っていう単語がいろんなところで目に入るようになった。とくに Chad Fowler がブログで取り上げたり、Food Fight に出たり して、世間でも関心が高まった感じがある。

プログラムを書く人にはご存じの通り、この Immutable っていうのは状態が変更出来ないことを指している。Immutable な Infrastracture っていうのは、ざっくり言うと「運用中のサーバーに変更を加えない」っていうアプローチでサーバーを管理しているスタイルのこと。

2013年9月: 「アプリケーションエンジニアへのVagrantの普及」

9月は新しい話題というよりも対象者がChefを使う必要のあるインフラ寄りのエンジニアではなく実際にアプリケーションの開発をするためにVagrantを使うというナレッジが数多く出てきています。アプリケーション開発に実際にVagrantを使い始めたのがこの辺りの時期だった方は結構居るのではないでしょうか。

2013年10月: 「メディアで報じられる普及」

10月に話題になっていた記事にはメディアの記事が2つ含まれています。センセーショナルな見出しだった事もあって多くの方の目を引いたのではないでしょうか。記事には具体的に日本の企業がChefを導入して活用しようとしている事が報じられています。

サイバーエージェントで消費者向けWebサービスを手がけるアメーバ事業本部では、現時点で20人いるOS/ミドルウエアの運用担当者を、2年後の2015年までにゼロにする計画だ。

　彼らは現在、OS/ミドルウエアをサーバーにインストールしたり、パッチを適用したり、アプリケーションの負荷に応じてサーバー台数を増減したりする業務を行っている。これらの業務を、オープンソースソフトウエアの運用管理ツール「Chef」を導入することで、自動化する計画だ。

要注目のツールとして浮かび上がったのが、「Redmine」「Jenkins」「Chef」という三つのオープンソースソフトである。
日経SYSTEMSはこれらを、IT現場の「新3種の神器」と定める。いずれも本格的な普及はこれからという段階だ。しかし、統合開発環境（ビルドツールを含む）やソースコード管理ツールが今どのIT現場でも使われているのと同じように、Redmine、Jenkins、Chefも数年の間に必須のツールとなると予測する。

2013年11月: 「加速するImmutable Infrastructure」

11月になると明確にImmutable Infrastructureへの言及が増加します。これによりChefの役割は実際のインスタンスの設定ではなく、Dockerなどのベースを作る為のプロビジョニングツールという形にスライドしていきます。また同時にオーケストレーションツールとしてのSerfにも注目が集まるようになります。
とはいえChefのレシピを記述している人は引き続き多いようで、クックブックの実行サイクルについて解説した記事にアクセスを頂きました。

2013年12月: 「OpsCode社の社名がChefに」

そして現在でもある12月。Chefが脚光を浴びたことで始まった一連の流れは改めて「Infrastructure as Code」の文脈で整理されています。これまでの流れを見てもわかるように、Chefを単体で使う事に意味があるのではなくプロビジョニングをコード化し、継続的にテストし、Immutable Infrastructureのような運用性を実現する事が肝要です。
直接話題になる事はすくなった部分もありますがクックブックを継続的にテストする事やワークフローの改善が今後も浸透していくのではないでしょうか。

おまけ：Chefに関する情報源

短期的に話題になった情報ではないですが、特に下記のコンテンツは量も豊富かつ正確なので参照するとよいでしょう。

• Rubyist Magazine - Chef でサーバ管理を楽チンにしよう！ (第 1 回)
  http://magazine.rubyist.net/?0035-ChefInDECOLOG
• Opscode Open Source Wiki(情報が古いが日本語の情報)
  https://wiki.opscode.com/pages/viewpage.action?pageId=24019581
• Chefについてのドキュメント(英語)
  http://docs.opscode.com/
• Resources and Providers Reference — Chef
  http://docs.opscode.com/chef/resources.html
• Recipe DSL — Chef
  http://docs.opscode.com/chef/dsl_recipe.html
• Esseintials nodes chef run
  http://docs.opscode.com/essentials_nodes_chef_run.html

動画で振り返る「Chef ゆく年くる年」

The post 2013年Chefの話題を一挙に振り返るまとめ appeared first on Engine Yard Blog JP.

私はEngine Yard Cloud上で稼働しているRailsアプリケーション上でパフォーマンス監視のためにNew Relicを使っています。
Engine Yard Cloudではアドオンとして様々な外部サービスを簡単に使用することができます。New Relicもその一つです。 本記事ではNew Relicを使う上での「メトリクスのカスタマイズ」と「デプロイの記録」という2つのTipsを紹介したいと思います。

メトリクスのカスタマイズ

New Relic は標準で以下のようにレスポンスにかかった時間の内訳を表示します。
それはController、View、Databaseといったメトリクスという単位で分かれています。

標準の結果では不十分だった場合に、NewRelicではControllerやViewにまとめて計測されている結果をより細かくカスタマイズする手段を提供しています。

Gem を使用する

いくつかのライブラリ向けにはすでに Gem が提供されていて、Gemfileに追加するだけで計測することができます。それがRedisだった場合、newrelic-redis を使うことで実現ができます。

gem 'newrelic-redis'

実際にRedisとのやりとりにかかる時間を独立したメトリクスとして計測することができます。

他にも Mongoid, Faraday用の Gem があります。詳しくは、こちらのリポジトリを参照してください。

自分で追加する

対応する Gem がないライブラリ、特定のメソッド等を計測したい場合、コードを書くことで実現できます。

例えば、コントローラ内で使っているメソッドを計測したい場合、以下のようなコードで実現することができます。

require 'new_relic/agent/method_tracer'

class SampleController < ApplicationController
  include NewRelic::Agent::MethodTracer

  def index
    do_something
  end

  private

  def do_something
    # do somthing...
  end

  add_method_tracer :do_somethiing
end

newrelic_rpm にはメトリクスを追加するためのモジュールNewRelic::Agent::MethodTracerが含まれています。
このモジュールに定義されている add_method_tracer メソッドに計測の対象にしたいメソッド名をシンボルで指定します。
これにより、指定したメソッド（この例ではdo_something）が独立したメトリクスとして表示されます。

デプロイを記録する

New Relic にはデプロイがどの時間に行われたか記録する仕組みがあります。これを使うと、デプロイ前後でのパフォーマンスの変化を比較しやすくなります。

Engine Yard Cloudへのデプロイから、NewRelicへ自動でデプロイを記録するのは簡単です。
newrelic_rpmに含まれているnewrelicコマンドとデプロイフックを組み合わせることで、自動でデプロイの記録ができます。

• deploy/after_restart.rb

require 'shellwords'
require 'yaml'

# Shell コマンドとして実行されるためエスケープをしている
def q(str)
  Shellwords.escape(str)
end

# アドオンの設定情報を読む
services = YAML.load_file("#{config.release_path}/config/ey_services_config_deploy.yml")
key      = services['NewRelic']['license_key']

# デプロイの説明を渡せるので、最新のコミットメッセージを使っている
message = `git log -1 --pretty='%s'`.chomp

run %(echo 'notify to newrelic...')
run %(cd #{config.release_path} && bundle exec newrelic deployments -a #{config.app} -u #{q config.deployed_by} -r #{config.revision} -l #{key} #{q message})

さらに、New Relic は Webhook をサポートしていて、デプロイが記録されたタイミングで HipChat、Campfire、Idobata といった外部のサービスに通知することができます。（参考）

まとめ

本記事では私が実際に使っている2つのTipsを紹介いたしました。
New Relic は手軽にパフォーマンスを監視できますが、 少し手を加えることでより自分のアプリケーションに合った結果を見ることができます。
本記事で紹介した以外にも便利なAPIが用意されているので、興味があれば調べてみるといいかもしれません。

The post New Relic on Engine Yard Cloud appeared first on Engine Yard Blog JP.

AngularJSの勉強会に参加して来ました。300人の定員があっという間に満席になるという事で注目の高さが伺える勉強会でした。参加者も発表の内容もバラエティに富んでいてこれから大きな飛躍があるであろう事を期待させる盛りだくさんの内容でした。
今回はEngine Yardから懇親会のスポンサードをさせて頂くと同時にPHPとAngularJSの連携のLTや動画の撮影を行ってきましたので紹介させて頂きます。

ng-mtg#4 AngularJS 勉強会 | 集客ならイベントアテンド
http://atnd.org/event/E0021975/
ng-mtg#4 AngularJS 勉強会 #ng_jp - Togetterまとめ
http://togetter.com/li/598391

AngularJS 20min

@naoya_itoさんによるAngularJSの入門講座。おなじみの軽妙語り口でAngularJSを始める際に理解するべきポイントや注意点を紹介していました。個人的に印象に残ったのは下記の点。

• 最初のサンプルがモンハンのスキルシミュレーターｗ https://github.com/naoya/mh4sim
• 「お前らのMVCは間違ってるなんて言ってないでコード書けよ = MVW」
• 双方向バインディングでリアルタイムにHTMLを更新
• DOM操作はしないという制約によりマークアップの変更の影響を受けない！
• 引数を勝手に変えると動かないよ(文字列的にAngularが扱うので)

OnsenUIについて ~Angular.js+Topcoat~

アシアルのお二人からはMonacaでも使われているOnsen UIにとても講演。Monaca自体はPhoneGapを利用したプロダクトですが、それと同様にAngularJSとTopcoatを活用して新しいコンポーネントを開発しているという意欲的な事例です。
OnsenUIについては公式サイトのドキュメント内で実際のデモを見ることもできます。
Reveal.jsを使ったスライドはスライド内でも実際のアプリが動いていてインパクトがあります。下記のIFRAME内でも動いていますので試してみてください。アプリがあるスライドで下向きの三角を押すとデモが始まります。

http://monaca.github.io/slides/2013-ng-jp/index.html

Home | Onsen UI
http://docs.monaca.mobi/onsen/ja/

WebAudioを利用したデモなどはとてもパワフルで印象的でした。今後はGUIで開発できるBuilderの開発を予定しているという事でコードを触らずにAngularJSの利点が活用できるようになりそうです。

AngularJS を実サービスで使ってみて

@sakatamさんによる実案件での採用事例の紹介。GILTでユーザー側にAngularを採用した話。すぐに開発を進めるのでなく評価や学習の期間をしっかりととっていた点が注目を集めていたように思います。

Angularでよくある質問とその回答

ほぼフリーディスカッション形式に移行したセッション。悩んだ際に直接開発者に聞けるといううらやましすぎる境遇とエピソードがとても印象的です。

LT:PHPとAngularの!ポンキーな関係

こちらはPHPでのAngularJSの実装例としてCakePHPとLithiumの２例を紹介しました。比較した中で特に強調したかったのは下記の点です。時間が不足していたので、同様のネタでまたどこかで話そうと思います。

• PHPとJavaScriptを合成したスクリプトはレガシーコード化する。(ポンキー)
• CakePHPの例: https://github.com/yandod/angularjs-cakephp-sample
• Lithiumの例: https://github.com/nateabele/li3-angular-presentation
• バックエンドはRESTを実装、フロントエンドは$resoucesを使うことでコード量が削減できる
• この記事もおすすめです。 リソース指向のWebアプリ 〜Nate Abele氏 来日講演〜 | Engine Yard Blog JP

動画

HD版への切り替えや再生速度(1.5倍　２倍速など)の変更が可能です！

AngularJS 20min, OnsenUIについて ~Angular.js+Topcoat~

AngularJS を実サービスで使ってみて, Angularでよくある質問とその回答