しかし、ちょっと前にsencha社のオープンソース（GPLv3）としての扱いがイマイチになったりしたもんで、「もうそろそろExtJSから離れるか」となってた。

その後、クライアントサイドで大掛かりなアプリ設計をする機会がなく、jQueryでお茶を濁してたりしてたのだけど、そろそろExtJS4の「自分なりの後釜」を決めて使えるようにしとかなきゃってことで、AngularJSに手を出してみたので、使った感じをまとめておく。

MVW（Model-View-Whatever）パターン

Model-View-*なパターンはいろいろあって、ご多分にもれず「どれがいい？どれが悪い？」みたいな不毛で無駄な話をよく聞くけど、AngularJSは「MV*？、*はなんでもいいじゃん」パターンで、そういう無駄な論議をしないところが、なかなかイカしてる（ExtJSはMVCだし、MVVMだ）。

とはいえ、基本的に「Whatever＝Controller」だ。

ViewはもちろんHTMLで記述されるDOMのセットだし、そこにはAngularJS独自にPresentation LogicとしてFilterやDirectiveがある。

Modelは、$scopeで参照されるすべての「データ」だし、Business Logicを含むServiceが定義されてる。

で、もちろんControllerはViewとModelを繋ぐもの。

$watch()、、、強力だ

「データバインディング」や「DI（依存性注入）」がAngularJSを語る上で重要ポイントだけど、それを差し置いて$watch()が気に入った。

$watch()はデータバインディングを支える仕組みで、オブジェクトやプロパティの変化を文字通りwatchできる。

「要素Aにバインドされている値が変化したので、要素Bを非表示から表示状態にするぜ」

なんてことが簡単にできる、イベントリスナーってわけだ。

Serviceでビジネスロジック

どんなフレームワークでもModelの概念の中にビジネスロジックを含めたい。

AngularJSでは、それはService定義という形で実装できる。

これをちゃんと使わないと、アホほどControllerが太っていくし、Unitテストもできないし、AngularJSを使う意味がなくなる。

i18n/l10nの仕組みはナカッタ

どうも理解困難だったのはこのポイント。

「Developer Guide – i18n and l10n」を読んでみると、わりと手数を要求してくる。

つまりは、そういう仕組みは「自分でやる」のが前提みたい（？いや、多分、AngularJSプロジェクトがまだこの部分が洗練されるような状況になっていないような気がする）。

というわけで、将来どうなるかが分からないし、変なpluginを使ってそのルールにしばられたくないので、自分で実装した。l10n部分だけだけど。。。w

• どうせサーバーサイドでもl10nするので、そこでクライアントサイド用のリソースデータを作る
• 作ったリソースデータは、ページロード時にng-appなモジュールに「value」として渡す（もちJSON形式）
• 以下の様なServiceを作る
• 各ControllerでこのServiceの依存性注入して、_()メソッドでリソースをロードさせViewに渡すなどする

[js]
webapp.factory("translate", function(l10n) {
return {
_: function(key) {
return eval("l10n[‘"+key+"’]");
}
};
});
[/js]

“l10n”は、サーバーサイドで作られたリソースデータでvalueとしてng-appに渡されたもの。
Controllerでは、

[js]
webapp.controller(‘SomethingCtrl’, [‘$scope’,’translate’, function($scope,Upload,appconfig,$timeout,translate) {
$scope.hoge = translate._(‘gegege’);
}]);
[/js]

ってな具合に使う。
i18nでlocaleについてもインプリメントしようと思ってるが、現時点では未着手。

ファイルアップロード

どうもAngularJSのダメなところがこういうところに現れている気がする。
まだ進化中なんだな。。と思うことで許せる範疇ではあるけどw

フォームを作って、その入力データをサーバーにPOST送信する時に、$httpという標準に用意されているAjax非同期通信するためのServiceを使ってもtype=”file”なinputで指定されたファイルが送信されない。。。

なんだか酷いな～。。。と思いつつ、$httpがデフォルトでつけるContent-Typeヘッダが問題だとわかった。

いろいろ見てたら「ng-file-uploadってpluginがいいぞ」ってことなんで、これを使ってファイルアップロードを実装した。

というわけで。。。

一通りAngularJSを使ってみたわけだが、ExtJSなんかに比べてシンプルでなかなかよかった。
「なんだよー」ってなる部分もあるわけだけど、まあ、そのうちなんとかなるんじゃないかと思う（AngularJS2も進んでるみたいだし！）

今後は、AngularJSとjQueryの両刀使いでやっていこうと思う。
それぞれの特徴を活かせるように、適材適所で。

あと、調査してて感じたこと。
AngularJSについてだけじゃないけど、、、ネット上で情報を探すときはクソな「ノウハウのみ（しかもバッドノウハウだったりするし！）」な記事に惑わされないようにすることをオススメしとく。
AngularJSみたいに過渡期なソフトウェアについては特にいえることかと。
基本的にはオフィシャルサイトや、信頼できる書籍なんかで「考え方」を掴むのが最初でノウハウはその後でっていうスタンスを崩しちゃいけない。。。って、再確認した。

いろんな人に会ったり、いろんな場所にオフィスORAとして行くことを想定して、できるだけ「なにをやっているか」を明確に提示できるようにしたいと思っているので、PRにも力を入れていこうってことでオフィシャルサイトを作ってみた。

オフィスORA

サイトとしては、わかりやすく1ページサイトにしたくて、wrapbootstrap.comからお気に入りの1ページサイトのテンプレートを1000円くらいで購入して摘要（jQuery+Twitter Bootstrapペースの様々なデザインテンプレートがあるので、使うWebアプリフレームワークに合わせてこれに手をいれて使うといい感じになる）。

拡張性・メンテナンス性を考慮して、フレームワークはFuelPHPで。

プロフィールのページには、自分の顔写真も使ってみた。。。w
まあ、顔が見えるというのは重要だと思うので。

個人事業で、プロジェクト構築とかPMOとかっていうのがどこまでニーズがあるかわからないのだけど、開発やプロマネやコンサルに加えて、中小企業のIT活用においても、大企業とわたりあえるだけのITチームやスキームをもつことの重要性をどんどんアピールして、わかっていただける顧客には誠心誠意お手伝いしたいと考えている。

「そのうちAWSでDockerをうまく使えるようになっとかなくちゃ」

とずっと思ってたが（Beanstalkがdockerをサポートする前からw）、ずっと頭の中でペンディングしてる。。。というのが現状。
いわゆる、こっち方面では「初心者レベル」。
Dockerは使ってて、オフィスORA用redmineやgitlabなんかをEC2インスタンス上で稼働してたりするし、Dockerfileも自分のアプリ用にわりと書いてはいるけど。。。

そんな中、「オフィスORAのDevOpsな取り組み」が少しずつ進んでついに「IaaSやPaaSの現状チェックしなきゃ。。。あ、、、ってかまずDocker周辺を。。。あ、、、ってかAWSでのDockerの件…」となってて「ECSが東京リージョンでも。。。」の件を思い出して、いきなりつついてみたというわけだ。。

「よくわからず、いきなり触る」というアンチパターンを実践。
（「遠回りしてこそわかることもある」と、悔し涙をながしつつわざとこういうアプローチを取る傾向は個人的な趣向デス）

案の定、動かすところまでいったものの、「ただ動いただけ」でよく把握できなかった。。。

問題の1つは「言葉の定義」が曖昧でなにしてるのかよくわからないこと。
そこで、動いたECSを放置して、まずは「言葉の定義」をチェック。。。

「What is Amazon EC2 Container Service?」

AWSのECSドキュメントを開いた途端、いくつかの「言葉の定義」が記述されてた（やっぱり先にこれに目を通すべきだった）。

【クラスタ】
タスクを追加できるコンテナインスタンスの論理的グループ
【コンテナインスタンス】
クラスタの中に登録され、Amazon ECS Agentが走るEC2インスタンス
【タスク定義】
1つ以上のコンテナを含むアプリケーションの定義
【スケジューラー】
コンテナインスタンスにタスクを配置する為の手段（Serviceとして常にタスクが走るように監視するタイプと、ただTaskとして1度走らせるだけのタイプがあるっぽい）
【タスク】
コンテナインスタンス上で走るタスク定義のインスタンス
【コンテナ】
タスクの一部として作られるLinuxコンテナ

というわけで、なるほど納得。
Dockerだしコンテナはわかるよ。。って思ってたが、ECSが扱うのはあくまでLinuxコンテナ（Dockerのベース）だし、複数コンテナを含む枠としてタスクがあり、それをタスク定義で記述できて、コンテナインスタンスと呼ばれるEC2インスタンス内でECS Agentがタスク群をスケジューラーに沿って走らせるぞ。。。と、そういうわけですな。

管理コンソールで、なにもわからずゴソゴソした時点では、タスクとコンテナの違いがイマイチわからなかったし（なんでコンテナをタスクと呼ぶの？って感じでマチガッテタ）、スケジューラーがなんなんだか分からなかった。。けど、これで納得。

というわけで、AWSのECSドキュメントに目を通してから、クラスメソッドさんの

• GA&東京に来たAmazon EC2 Container Service(ECS)を触ってみた #AWSSummit
• Amazon EC2 Container Serviceで構築されたシステムでDockerコンテナを入れ替える

この辺を読みながら触ってみると、私みたいに「迷える駄馬」にならないで済むとおもわれる。

ちなみに「AWSでDocker」という意味で整理すると。。。。

• ECSで
• Elastic Beanstalkで
• EC2インスタンスで独自に

の3パターンがあるわけで、Beanstalkも含めてこれで全部触ってみたわけだけど、まだ「CoreOSなEC2インスタンスを作って独自にやる」のがピンとくる感じ。

もう少し、いろいろ情報を整理しつつ、いじったりもしながら考察していこうと思う。

Twitterではabraham/twitteroauthを使ってて、安定の「楽で確実なインプリメント」を実施。

FBでは、公式のSDK for PHPを使うわけだけど、いつの間にかv5.0.0になっていた。
v3からv4の時も、かなり仕様が変わっててリファクタリングを余儀なくされたので、v5でも。。。と思っていたら案の定であった。
まあ、それでも「使わせてもらう側」としては文句をいわずに対応。

まずはcomposer.jsonに以下を追加して、composer.phar update。

[code]
"facebook/php-sdk-v4" : "~5.0"
[/code]

こんなコントローラを作成

[php]
use Facebook\Facebook;
class Controller_Auth_Fb extends Controller
{
public function action_request()
{
$fb = new Facebook([
‘app_id’ => Config::get(‘app.sns.facebook.app_id’),
‘app_secret’ => Config::get(‘app.sns.facebook.app_secret’),
‘default_graph_version’ => ‘v2.4’,
‘persistent_data_handler’ => new MyFbPersistentDataHandler(),
]);
$helper = $fb->getRedirectLoginHelper();
$url = $helper->getLoginUrl(Config::get(‘base_url’).’auth/fb/’);
Response::redirect($url);
}

public function action_index()
{
$fb = new Facebook([
‘app_id’ => Config::get(‘app.sns.facebook.app_id’),
‘app_secret’ => Config::get(‘app.sns.facebook.app_secret’),
‘default_graph_version’ => ‘v2.4’,
‘persistent_data_handler’ => new MyFbPersistentDataHandler(),
]);
$helper = $fb->getRedirectLoginHelper();
try {
$accessToken = $helper->getAccessToken();
if(!isset($accessToken)) {
throw new Exception();
}
Log::debug(print_r($accessToken,true));

$client = $fb->getOAuth2Client();
if(!$accessToken->isLongLived()) {
$accessToken = $client->getLongLivedAccessToken($accessToken);
}
Log::error(print_r($accessToken,true));

$response = $fb->get(‘/me’,$accessToken);
$data = $response->getGraphObject()->asArray();
$data[‘token’] = (string)$accessToken;
Log::error(print_r($data,true));

} catch(Exception $e) {
Log::error($e->getMessage());
Session::set_flash(‘msg’, "danger:Faild to login with facebook…");
}

Response::redirect(Uri::base(false));
}
}
[/php]

action_request()でログイン用URLを生成し、そこにredirect（ページ上のログインリンクはauth/fb/request/を張っとく。事前にログインURL取得してページにそれを晒してもいいのだけどこちらを選択）。

action_index()は、FBからのコールバック受け取り用メソッド。
action_request()でのgetLoginUrl()呼び出し時に指定してる。

問題は、action_request()/action_index()どちらでも生成しているFacebookオブジェクト。
ここでconfigデータで’persistent_data_handler’としてMyFbPersistentDataHandlerオブジェクトを渡している。

これ、デフォルト（configで指定しなければ）ではPHPのsessionが使われる（session_start()とかのアレね）。
でも、FuelPHPのセッションクラスでは、PHPのsessionを偽装してインプリメントされている。
よって、Facebookオブジェクトをデフォルトで生成し使おうとすると、「Sessions are not active. Please make sure session_start() is at the top of your script.」なんて例外が投げられる。
v3とかv4では、session_startしてるかどうかはチェックされてなかったので、FuelPHPの偽装でも動いてた。
v5では、チェックするようになったみたい。

こんな例外が投げられたからといって、session_start()してもダメ。
FuelPHPのセッションクラスと整合性が保てない。

そこで、自身でPersistentDataHandlerを用意してあげなくてはいけない。

[php]
use Facebook\PersistentData\PersistentDataInterface;

class MyFbPersistentDataHandler implements PersistentDataInterface
{
public function __construct() {
Session::instance();
}

public function get($key) {
return Session::get($key);
}

public function set($key, $value) {
Session::set($key,$value);
}
}
[/php]

こんな具合にPersistentDataInterfaceをインプリメントしてあげる。
これをPersistent Data Handlerとして使うことで、FuelPHPでもSDK for PHP v5を使えるようになる。
ちゃんと、Long Lived Tokenもゲットできる。

Could not fetch https://api.github.com/repos/fuel/docs, please create a GitHub OAuth token to go over the API rate limit
Head to https://github.com/settings/tokens/new?scopes=repo&description=Composer+on+gege+2015-07-15+1342
to retrieve a token. It will be stored in “/home/vagrant/.composer/auth.json” for future use by Composer.
Token (hidden):

なーんて言われた。
これまで見たことなかったけど、「GitHub OAuthトークンのアクセス制限ひっかかったぜ」と。。。

1日に60回のアクセスが制限らしいんだけど、そんなにアクセスしてないんだけどなぁ。。。まあ、composerが中でどうやってるのか知らないので、なんともいえないけど。

とはいえ、ここは場当たり的対応じゃくて、CIやCDする時のことも考えて、プロビジョニング時に./composer/auth.jsonつくれるようにしておかなくてはいけないなと。。。

• まずは、GitHubでtokenゲット
• auth.jsonの元ファイルになるファイルを作成し、tokenを書いとく

ってした。

ただ、いちいちauth.jsonを用意するのなんとなくキモチワルイので。。。しらべていると

「composerに事前に教える」というアプローチもあるなっ！となりまして、、

[text]
$ php composer.phar config -g github-oauth.github.com [your token]
[/text]

ってするのもアリとわかった。

CIやCDでプロビジョニングする際に、なにをどうするかは自由なんだけど、tokenが記述されている元ファイルだけは用意して置かないとダメ。
でも、このファイルをリポジトリで管理するわけにもいかない（みんなに見えちゃう！）ので、このファイルの扱いはもう少し工夫しないといけない感じ。