今年も最後となりましたので、自分の 2014 年の活動について振り返ってみます。去年の振り返りは[こちら](http://blog.mitsuruog.info/2013/12/2013.html)です。  
それから「来年こそはもっと質の良いアウトプットしたいと思います。」と締めくくってますね。果たして私は今年、何をやっていたのでしょうか。。。



今年も[html5j エンタープライズ部](http://www.html5biz.org/#/)を中心にたくさんのエンジニアとめぐり合うことができ、大変有意義な一年でした。支えていただいたたくさんの方々、本当にありがとうございました。来年も引き続きご指導のほどよろしくお願いします。

## 1 月〜3 月 SAPUI5/OpenUI5 と AWARD 受賞

昨年は Backbone.js をずっとやっていたのですが、仕事の都合で[SAPUI5/OpenUI5](https://sap.github.io/openui5/)という SAP 社製の UI フレームワークを利用して Web アプリを作成していました。

[業務系アプリケーションに特化した SAP 社製「SAPUI5」を触ってみた](http://blog.mitsuruog.info/2014/02/sapsapui5.html)

少数精鋭のプロジェクトでアジャイルっぽい要素を組み合わせて短期間で仕上げた仕事でした。この時の功績で、**SAP AWARD OF EXCELLENCE 2014**を取得しています。  
(今年の秋には AngularJS をやっていて、正直一年でこんなにも使うフレームワークが変わるとは思いませんでしたね。)

また、[Developers Summit 2014：開発者のための IT カンファレンス](http://event.shoeisha.jp/devsumi/20140213/)の Yet Another Your Story (Enterprise TED 3)にて講演させていただきました。いまとなってはいい経験です。

[デブサミ 2014 で 35 歳からフロントエンジニアにキャリアチェンジして 35 歳定年説を覆した話をしてきた](http://blog.mitsuruog.info/2014/02/20143535.html)

この辺りは日々忙しくて夢中で駆け抜けた時期でした。今思うと、何も考えず夢中で走り続けられるって大事だなとおもいます。

## 4 月〜6 月 個から組織へ

この頃、次にやりたいことのスケールが自分を超えていると感じていたので、今まで学んだフロントエンドのスキルなどを組織で活かそうと模索していた時期でした。  
いままで個人の成長に重きを置いてきましたが、その視点が組織や仲間にまで広がったということは、個人的にはずいぶん成長したとおもいます。

5 月に HTML5fun 立ち上げイベントにて声をかけられて講演する機会をいただきました。その時に感じている自身のエンタープライズ HTML5 感について話させていただきました。

[HTML5fun で「エンタープライズでの HTML5」について最近思うことを話してきた](http://blog.mitsuruog.info/2014/05/html5funhtml5.html)

今思うと、フロントエンドエンジニアを目指してからずっと、「エンタープライズでフロントエンドエンジニアが増えますように」と言っている気がしますね w。まじ変な人です。  
たぶん、一緒に Web アプリケーションを作って苦楽を共にする仲間が欲しかったのだとおもいます。

この時は、組織として強化するべきフロントエンドの技術や開発手法など広く探っている時期でした。見つけたのが後で出てくるハイブリッド開発手法や AngularJS でした。

## 7 月〜9 月 ハイブリッド開発手法と AngularJS

この頃はハイブリッド開発手法(Cordova)と AngularJS を有用性を見極めるため、ひたすらサンプルのアプリや Web サービスのコードを書いて検証を重ねていました。
Cordova のフロント部分に AngularJS が利用できることが分かったので、エンタープライズにて AngularJS でどのように Web アプリケーションを構築すればいいかを念頭に検討を重ねていました。

9 月には[いまや最も優れた JavaScript フレームワーク「AngularJS リファレンス」出版記念会](http://html5experts.jp/albatrosary/10855/)にて、AngularJS の取り組みについて話させていただきました。

[なぜ AngularJS を薦めるのか ー 個人的な思い](http://blog.mitsuruog.info/2014/11/angularjs.html)

## 10 月〜12 月 AngularJS をより深く

この頃は AngularJS の MEAN スタックを使ってもっと複雑な Web アプリケーションを作成していました。(とは言ってもあくまで β 版サービスレベルです。)

[MEAN(MongoDB, Express, AngularJS, Node.js)スタックが優れている理由 - Mozilla Open Web Day in Tokyo を終えて - albatrosary's blog](http://albatrosary.hateblo.jp/entry/2014/10/06/073638)

AngularJS 関連で、他の SIer にて講演させていただいたり、ハンズオンのチューターとして参加させていただきました。  
自身の持つ AngularJS、Cordova、Nodejs のスキルを駆使して多くのデモアプリやサービスを作成していました。この過程で AWS などのクラウドサービスを利用することが日常的となり、併せて弱点だったインフラのトレーニングを積むことができました。

## 来年の活動

といった感じで、個人としては成長できた一年でした。来年は、今年できなかった組織やチーム、仲間と共に自身も成長していきたいとおもいます。

特に今年の後半は徐々にアウトプットが少なくなったようで、勢いがなかったような気がします。これは、今年やりたかった「今まで学んだフロントエンドのスキルなどを組織で活かす」という部分がうまく機能しなかったため、自身の中にいろいろ迷いが生じていたためだと思います。  
これは使い慣れたガラケーが手放せない人に、最新式のスマートフォンを売っている、気持ちに通じるものがあります。

というわけで、来年はこういう無駄なところで悩まず、なるべく早い時期にまっすぐ走れる道を見つけたいとおもいます。
そして、チームや仲間と共にさらに成長していきたいです。

来年こそはもっと質の良いアウトプットしたいですね！！  
では、みなさん良いお年を。

### p.s.

35 歳からフロントエンドエンジニアを目指して走ってきたのですが、ここまでこれたのは妻の支えと娘の笑顔があったからです。本当に感謝したい。  
(と言える気持ちになったのが、今年一番の収穫なのかもしれない。)

2014年を振り返る

AngularJS を利用するメリットの 1 つとして、AngularJS が内包している[$resource](https://docs.angularjs.org/api/ngResource/service/$resource)を利用することで、バックエンドが提供する REST API との対話部分が簡潔に記述できることが挙げられます。

ところが、$resource の表面的な振る舞いを理解しただけでは、意外なところにハマりポイントがあるものです。今日はその辺りを少し紹介します。



[AngularJS Advent Calendar 2014 \- Adventar](https://adventar.org/calendars/350)16 日目の記事です。

- 15 日目[AngularJS - Promise を使おう - Qiita(@teyosh)](http://qiita.com/teyosh/items/d7d3c17f954318c88882)
- 17 日目[AngularJS 1.3 へのアップデート(@kon.yuichi)](https://note.mu/konpyu/n/n1eb6c13c69d6)

## $resource の使い方

> $resourceの細かい内容については[本家ドキュメント](https://docs.angularjs.org/api/ngResource/service/$resource)か[Qiita](http://qiita.com/search?utf8=%E2%9C%93&sort=rel&q=angular+%24resource)でググるといいと思います。

$resourceにURLを渡すだけで以下のような基本的なWebAPIが実行できるようになります。$resource を使う場合、`service`か`factory`の中で利用することがほとんどですね。

```
{
  'get':    {method:'GET'},
  'save':   {method:'POST'},
  'query':  {method:'GET', isArray:true},
  'remove': {method:'DELETE'},
  'delete': {method:'DELETE'}
};
```

また、`PUT`や異なるエンドポイント(URL)など、先ほどの基本的な API をカスタムしたい場合は、`actions($resourceに渡す3つめの引数)`で使うことで簡単に API を追加できるので、使いこなすことが出来るとバックエンドとの WebAPI 連携の部分で非常に重宝します。

**user.service.js**

```js
function User($resource) {
  return $resource('/api/user/:id', {
    id: '@id'
  }, {
    //PUT /api/user/:id
    updata: {
      method: 'PUT'
    },
    //GET /api/user/me
    me: {
      url: '/api/user/me'
    }
  });
});

angular.module('app').factory('User', User);
```

## "$resource の戻り値は実際の値ではない、参照である。"というハマりポイント

> し、しらなかったぜ・・・

結論から言うと、$resource の戻り値は**参照**なので、そこから直接プリミティブ型の値を取り出して他で使う場合には、タイミングによって`undefined`になったりならなかったりするということです。  
(ほとんどの場合、Object をデータバインドして参照経由で実際の値を見ているので、あんまり問題にならないと思います。)

このハマりポイント、あまり遭遇するケースはないかも知れませんし、原因がわからないままなんとなく回避している人もいるかと思います。私の場合、ui-router の`resolve`を使って controller で必要な情報を取得することが多かったため、よく遭遇していました。

**app.route.js**

```js
function Router($stateProvider) {
  $stateProvider.state("main", {
    url: "/",
    templateUrl: "app/main/main.html",
    controller: "MainCtrl",
    controllerAs: "vm",
    // ここでUserリストを事前に取得
    resolve: {
      user: function (User) {
        return User.get({
          id: 1, // ✌(-‿-)✌
        });
      },
    },
  });
}

angular.module("app").config(Router);
```

**main.controller.js**

```js
function MainCtrl(user, socket) {
  var vm = this;
  vm.user = user;

  // WebSocketのチャットルームに参加
  // [TODO]タイミングによってuser.roomIdがundefined
  socket.emit("chatRoom:join", {
    id: user.roomId,
  });
}

angular.module("app").controller("MainCtrl", MainCtrl);
```

こちらの Stack Overflow を参考にしたのですが、改めて[公式ドキュメント](https://docs.angularjs.org/api/ngResource/service/$resource#usage_returns)読むと書いてありましたね。

> It is important to realize that invoking a $resource object method immediately returns an empty reference  
> ($resource を実行するとね、すぐに空の参照を返すから、心して使え。このボケがぁ！・・・超約)

[json - AngularJs using $resource service. Promise is not resolved by GET request - Stack Overflow](http://stackoverflow.com/questions/20008244/angularjs-using-resource-service-promise-is-not-resolved-by-get-request/20008380?stw=2#20008380)

## $resource との正しい(安全な)付き合いかた

より安全なコードの書き方は、$resourceが返すpromiseを、次のように`$promise`から取り出して処理すると安全です。

**main.controller.js**

```js
function MainCtrl(user, socket) {
  var vm = this;

  user.$promise.then(function (user) {
    vm.user = user;
    // WebSocketのチャットルームに参加
    socket.emit("chatroom:join", {
      id: user.roomId,
    });
  });
}

angular.module("app").controller("MainCtrl", MainCtrl);
```

各コントローラで promise を処理するのが面倒な場合は、15 日目[AngularJS - Promise を使おう - Qiita(@teyosh)](http://qiita.com/teyosh/items/d7d3c17f954318c88882)で紹介されているような、promise を処理するための factory を作ってラップするといいと思います。  
(たしか、<a target="_blank" href="https://www.amazon.co.jp/gp/product/4873116678/ref=as_li_tl?ie=UTF8&camp=247&creative=1211&creativeASIN=4873116678&linkCode=as2&tag=mitsuruog-22&linkId=bdd0c9b0152b6260907ab4e64036c67a">AngularJS アプリケーション開発ガイド</a><img src="//ir-jp.amazon-adsystem.com/e/ir?t=mitsuruog-22&l=am2&o=9&a=4873116678" width="1" height="1" border="0" alt="" style="border:none !important; margin:0px !important;" />のサンプルもそうなってたはず。)

<iframe style="width:120px;height:240px;" marginwidth="0" marginheight="0" scrolling="no" frameborder="0" src="https://rcm-fe.amazon-adsystem.com/e/cm?ref=tf_til&t=mitsuruog-22&m=amazon&o=9&p=8&l=as1&IS1=1&detail=1&asins=4873116678&linkId=d152ad4c622d40713fb4691ba63bcb90&bc1=000000&lt1=_blank&fc1=333333&lc1=0066c0&bg1=ffffff&f=ifr">
    </iframe>
    
## まとめ

今日は$resource を使うと便利ですが、ちょっとハマるよという話をしました。

AngularJS はフロントエンドの実装を大変楽にしてくれるフレームワークです。しかし同時に、その裏でフレームワークが隠蔽している技術の難しさを軽視することはできないと改めて思い知りました。

今回のようなケースは、Javascript の実装についてある程度の経験がないとあたりがつけにくい問題だったと思います。(ドキュメント読めは置いといて・・・)  
AngularJS に限らず、JS フレームワークを利用する場合は、チームの中に本当の Javascripter(Hacker ともいう)がいるかが、成功の秘訣のような気がします。

AngularJSの$resourceの意外なハマりポイント

最近の AngularJS 開発では[DaftMonk/generator-angular-fullstack](https://github.com/DaftMonk/generator-angular-fullstack)をオレオレカスタムしたものを使っています。 fullstack だけあって使いこなすまで慣れがいると思いますので、私が普段使いしていていいなって思う機能を紹介します。  
AngularJS 開発の厳しい旅のお供にどうぞ。

この記事は[YEOMAN Advent Calendar 2014 - Adventar](http://www.adventar.org/calendars/356)9 日目の記事です。

- 8 日目[YEOMAN Advent Calendar 8 日目：generator-ember を紹介します - albatrosary's blog](http://albatrosary.hateblo.jp/entry/2014/12/08/120810)
- 10 日目[YEOMAN Advent Calendar 10 日目：generator-reveal を紹介します - albatrosary's blog](http://albatrosary.hateblo.jp/entry/2014/12/10/143324)



## 基本的な使い方

基本的な使い方はこちらを参照してください。そんなに難しくないはず。

[DaftMonk/generator-angular-fullstack | usage](https://github.com/DaftMonk/generator-angular-fullstack#usage)

注意点としては、アプリを generate する際に`mongodbあり`を選択した場合は、mongodb が起動していないと動作しないとこでしょうか・・・

> npm install する際に`grunt-contrib-imagemin`でエラーが発生する場合、もう一度 npm install するか、一度 uninstall して install するといいです。
>
> ```
> npm uninstall grunt-contrib-imagemin --save-dev
> npm install grunt-contrib-imagemin --save-dev
> ```

アプリケーションの雛形を作成したら、機能を追加する際にこちらのサブジェネレータを利用するとソースコードを自動生成してくれます。

[DaftMonk/generator-angular-fullstack | generators](https://github.com/DaftMonk/generator-angular-fullstack#generators)

では、ここから generator-angular-fullstack(以下、fullstack)の便利機能を少し紹介していきます。

## OAuth 認証テンプレート

fullstack には`google+`, `twitter`, `facebook`の OAuth テンプレートが付属しています。これに加えて`user/password`形式の Form も付属しているので、認証が必要なアプリケーションを作成する場合は、非常に助かると思います。  
OAuth のモジュールは[Passport](http://passportjs.org/)を利用しています。

利用方法は、`serve>config>local.env.sample.js`を同じフォルダにコピーして、`local.env.js`にリネームしてからファイルの中身に AppID などを設定すれば利用できます。

例) local.env.js

```
module.exports = {
  DOMAIN:           'http://localhost:9000',
  SESSION_SECRET:   'some-secret-key',

  FACEBOOK_ID:      'app-id',
  FACEBOOK_SECRET:  'secret',

  TWITTER_ID:       'app-id',
  TWITTER_SECRET:   'secret',

  GOOGLE_ID:        'app-id',
  GOOGLE_SECRET:    'secret',

  // Control debug level for modules using visionmedia/debug
  DEBUG: ''
};
```

注意点としては、local.env.js は`.gitignore`に指定されているので、各環境ごとに作成する必要があります。うっかり、作成忘れると認証エラーでハマります。  
それから、`DOMAIN`は OAuth の callbackURL として fullstack 側で利用しているので、これも環境ごとに正しく設定する必要があります。

## livereload & auto restart

今風の高速フロントエンド開発の象徴ともいうべき livereload と auto restart。当然 fullstack にも付属しています。

フロント側を変更した場合は、ブラウザがリロードされ、サーバー側を変更した場合は、Node が restart します。

## Node inspector

> まさか、まだ`console.log()`じゃないですよね！そんなあなたのために。

Node.js のデバックには[node-inspector/node-inspector](https://github.com/node-inspector/node-inspector)を使うのが一般的だと思うのですが、
しばらく触っていないと使い方をすぐ忘れてしまします。幸い fullstack ではサーバーをデバックモードで起動する Grunt タスクとして組み込まれているので忘れにくくなりました。

```
grunt serve:debug
```

コマンドを叩くと、Node inspector が立ち上がってくるのですが、`--debug-brk`指定されているので最初のステップのブレイクポイントで止まっています。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2014/node-Inspector.png)

ブレイクポイントから処理を進めると通常通りサーバーが起動してくるので`http://localhsot:9000`にてアプリの動作を確認しながら、Node 側のデバックもできます。

## mongodb テストデータ自動投入

サーバー起動時に動作環境を選択できます。デフォルトは`Development`になっていると思いますので、起動時に mongodb のテストの洗い替えを行ってくれます。  
テストデータは`server>config>seed.js`に初期設定されていて、最初は`Thing`と`User`のデータがセットされているはずです。ここにテストデータを追加してください。

テストデータ投入の有無は各動作環境ごとの config にて選択できます。`server>config>environment`以下の各環境ごとの設定ファイルが置かれているので、`seedDB`フラグを切り替えてください。

例) development.js

```
module.exports = {
  // MongoDB connection options
  mongo: {
    uri: 'mongodb://localhost/someapp-dev'
  },
  seedDB: true
};

```

## index.html へ必要なフロント側リソースの自動挿入

> 404...はいはい、あれね。

AngularJS でアプリケーションを作成していると、非常にファイル数が大きくなる傾向にあると思います。ファイル追加のたびにわざわざ`index.html`に`<script>`タグなど追加していくのが、非常に億劫になりますね。

fullstack では[klei/grunt-injector](https://github.com/klei/grunt-injector)を利用することで、面倒な`index.html`へのリソース追加を強力にサポートしてくれます。  
`index.html`を確認すると見慣れない``や``のコメントがありますが、この部分に必要な`*.js`や`*.css`を挿入します。bower モジュールも対応しているのがいいですね。

## 本番ビルド

Grunt コマンドで一発本番ビルドできるのも嬉しいですね。

```
grunt build
```

ちなみに次のようなことをしてくれます。

- js, css の結合と minify とリビジョン番号振り
- html の minify
- image の minify
- AngularJS の minify 地雷除去
- AngularJS のテンプレート結合と minify と cache

1 からタスク作ると大変だと思います。

## その他カスタム

これら普通にあるものを利用してもかなり捗るのですが、自分なりにカスタムしている部分を紹介します。  
(これも好みの問題でしょうが・・・)

### サブジェネレータのテンプレート

generator-angular-fullstack が作成するコードのテンプレートを変更したいケースがある場合は、`.yo-rc.json`の中身を変更します。  
`generator-ng-component`の中に`~Templates`というプロパティがあるので、そこにサブジェネレータが参照するテンプレートがあるパスを設定します。

.yo-rc.json

```json
  "generator-ng-component": {

    // 省略

    "directiveSimpleTemplates": "/templates/directiveSimple",
    "directiveComplexTemplates": "/templates/directiveComplex",
    "filterTemplates": "",
    "serviceTemplates": "",
    "factoryTemplates": "",
    "controllerTemplates": "",
    "decoratorTemplates": "",
    "providerTemplates": "",
    "routeTemplates": ""
  }
```

### jsLint, csslint

generator-angular-fullstack では jsLint は付属していますが、csslint は付属していません。 jsLint もチェックタイミングについてもファイル変更時に頻繁にチェックするようにしています。

とくに、css はコンポーネントっぽいフォルダ構成になっているため、スタイルクラス名などにプリフィクスなどつけてサンドボックス化までしてくれるかと期待してましたが、そこまではやってくれませんでした。  
さらにおかしな CSS を書くと minify した時にスタイル崩れが発覚して厄介ですので、`cssLint`は必須ですね。

### socket.io

フロントとサーバー側で socket.io のコンポーネントが付属するのですが、私の作るアプリではいまいちユースケースが合わないので、作り変えてます。  
ツールに使われず、必要に応じてカスタムして使いこなす姿勢が大事だと思います。

## まとめ

私が普段使いしている[DaftMonk/generator-angular-fullstack](https://github.com/DaftMonk/generator-angular-fullstack)の便利機能について紹介しました。  
まだ他にも便利機能があると思いますので探してみてください。

本格的は AngularJS 開発を行う場合は、このような開発を下支えするツールが必須だと思います。手に馴染んでくると本当に手放せなくなります。

> 本来であれば、こんなにも難しくなってしまった Web 開発の現状を嘆くべきでしょうが・・・

一度使ったらやめられないMEANスタック開発が捗るgenerator-angular-fullstackの便利機能の紹介

フロントエンドの世界では、日々新しいフレームワークやライブラリが生まれています。
初めてそういった新しいものを習得する場合に、なるべくなら近道したいと思うのが人の気持ちだと思います。  
まず大変なのが、Hello World から実際のプロダクトやプロトタイプで利用する場合で、これは初めてで何もわからない土地を一人で散策するような感覚にも似ています。

今日、紹介するのは私が進化の早いフロントエンドの世界で、より早く未開の土地に慣れるために**スタイルガイド**を有効活用しているという話です。



ちなみにこの記事は[Frontrend Advent Calendar 2014 - Qiita](http://qiita.com/advent-calendar/2014/frontrend)の 6 日目の記事です。

- 5 日目[はじめての CSS 設計 - Qiita(@moschann)](http://qiita.com/moschann/items/c7cbf62056d77cbc1d66)
- 7 日目[CSS のプリプロセスとポストプロセス、そして Rework と PostCSS(@morishitter)](http://morishitter.hatenablog.com/entry/2014/12/07/000205)

## 良いスタイルガイドとは

巷にはスタイルガイド(コーディング規約)と銘打ったものがあふれています。
そのため有効に活用できるスタイルガイドを自身で見極めなければなりません。  
頼りにするスタイルガイドが大雑把で必要なことが書いてなかったり、1000 ページもあってすぐ必要な場所が探せないようでは使えません。

私がスタイルガイドを見たときに良さそうだなと思うのは次のような場合です。

- 目次をみて言語やフレームワークの機能を網羅しているか
- `Bad`と`Recommended`の両方のスタイルが提示されているか
- そのスタイルに至った理由や背景が書かれているか
- スタイルの提示だけではなく、具体的なユースケースが提示されているか

このようなことを頭の片隅に置きながら、自分にあったスタイルガイドを探すといいと思います。

## なぜスタイルガイド？

私がスタイルガイドを読む理由はいくつかあるので紹介しますね。

### 良いコードを書くために悩む時間を短縮

例えば、Javascript でのオブジェクトや配列の定義の仕方については、通常`{}`と`[]`が使われると思いますが、Javascript の言語自体あまり普段やらない人にとってはそれすらわからないと思います。

```js
// bad
var item = new Object();

// good
var item = {};

// bad
var items = new Array();

// good
var items = [];
```

> [mitsuruog/Javacript-style-guide | オブジェクト](http://mitsuruog.github.io/javacript-style-guide/#objects)より

スタイルガイドを読むことで基本的な部分では悩まなくなります。基本的なことで悩まないということは、本当にやるべきところで悩むことに集中するために大切なことです。

様々な書き方存在する中で良いコードを書くために悩む時間を少なくしたいですね。  
(とはいえ、悩むのですが。。。)

### 地雷源を早期に把握

良いスタイルガイドには、先人達がその言語やフレームワークにて発見した地雷源が記載されています。

例えば、AngularJS で controller などを作成する際に、複数の書き方ができるのですが、スタイルガイドを読むことで悩むことなく自分が書くべきコードを見つけることができました。

> 世の中のサンプルは avoid で実装されていることが多いです。それを疑わないままそのまま覚えてしまうことは危険です。

```js
/* avoid */
angular
  .module("app")
  .controller("Dashboard", [
    "$location",
    "$routeParams",
    "common",
    "dataservice",
    function Dashboard($location, $routeParams, common, dataservice) {},
  ]);

/* recommended */
angular.module("app").controller("Dashboard", Dashboard);

Dashboard.$inject = ["$location", "$routeParams", "common", "dataservice"];

function Dashboard($location, $routeParams, common, dataservice) {}
```

> [johnpapa/angularjs-styleguide | Manually Identify Dependencies](https://github.com/johnpapa/angularjs-styleguide#style-y091)より

また、DI の部分を以下のように省略して書いてしまうとソースコードを Minify したときにエラーになるという地雷も発見することができました。

```
/* avoid - not minification-safe*/
angular
    .module('app')
    .controller('Dashboard', Dashboard);

function Dashboard(common, dataservice) {
}

/* recommended - minification-safe*/
angular
    .module('app')
    .controller('Dashboard', Dashboard);

Dashboard.$inject = ['common', 'dataservice'];

function Dashboard(common, dataservice) {
}
```

> [johnpapa/angularjs-styleguide | UnSafe from Minification](https://github.com/johnpapa/angularjs-styleguide#style-y090)より

これらの先人たちの地と涙を汗の結晶である**地雷源情報**を参考にしない手はありませんね。

### コードリーディング時間の短縮

チームで作業する場合に、同じスタイルガイドを参照することで統一感のあるコードを書くことができます。

これは OSS でも同じことで同じスタイルガイドに習うことで他人のコードも読みやすく、また自分のコードも読んでもらいやすくなります。

例えば、Nodejs では API 呼び出しの最後の引数に function を渡すことで、API 呼び出し後に callback を実行させることが慣例となっています。(引数が 1 つの場合はそれが callback になることが多いです。)

express のサーバー作成のコードを例として提示します。

```js
// Setup server
var app = require("express")();
var server = require("http").createServer(app);

// Start server
// [MEMO]3番目のfunctionがcallback
server.listen(port, ip, function () {
  console.log("Express server listening on %d", port);
});
```

> どこかでこんな内容のガイド見たのですが、忘れてしまいました。知っているかたいましたら教えてください。

自分が作成した node 製モジュールの API で、最初の引数を callback にしてしまった場合はどうでしょうか。
他人が読む場合とてもストレスを感じると思います。

**Go に入れば Go に従えで**はないですが、そのコミュニテイ内でのルールは守ったほうがいいですよね。

## スタイルガイドの紹介

私がよく参照するスタイルガイドを紹介します。これからフロントエンド習得しようと思う方は参照してみてください。  
(よく利用しているフレームワークに偏りあるので、全ては網羅していませんが。。。)

### Javascript

airbnb のスタイルガイドを私が翻訳したものです。(本家はこちら[airbnb/javascript](https://github.com/airbnb/javascript))  
有名なスタイルガイドは他にもいくつかあるのですが、内容とボリュームがちょうどいいと思います。

- [mitsuruog/Javacript-style-guide](http://mitsuruog.github.io/javacript-style-guide/)

もうちょっと手が動く様になるとこちらも読むといいです。

- [JavaScript Garden](http://bonsaiden.github.io/JavaScript-Garden/ja/)

### Backbone

スタイルガイドというかパターン集ですね。最近の Backbone は[Marionette.js](http://marionettejs.com/)を併用することが多いので、これはもうあまり出番がないかも。。。

- [rstacruz/Backbone patterns](http://ricostacruz.com/backbone-patterns/)

### AngularJS

AngularJS はこれを読んでおけばいいです。

- [johnpapa/angularjs-styleguide](https://github.com/johnpapa/angularjs-styleguide)

### CSS

基本ですね。

- [idiomatic-css/translations/ja-JP](https://github.com/necolas/idiomatic-css/tree/master/translations/ja-JP)

本格的に勉強したい場合はまずこちらを読むといいです。

- [SMACSS E-book 日本語](http://shop.smacss.com/products/smacss-e-book)

### HTML

結構マークアップで悩む事が多いので、参考になります。

- [hail2u/html-best-practices](https://github.com/hail2u/html-best-practices)

## まとめ

進化の早いフロントエンドの世界ですが、私が進化に追いつくためにスタイルガイドを有効活用しているという話をしました。  
特に最近は特定のフレームワークや言語のスタイルガイドが付属するようなトレンドになってきたような気がしています。  
(ここで言うスタイルガイドは、従来のスタイルガイドとは違うジャンルの新しいタイプのものなのかもしれませんね。)

他の習得方法として、書籍を読む方法もいいと思いますが、スタイルガイドで特性などを把握してから本を読み進んだほうが、途中で挫折しないような気がしています。  
スタイルガイドは面倒な前置きなどないので、忙しいエンジニアは普段使いするには向いていると思いますし。
(書籍の内容は StackOverflow で参照できる内容もおおくありますし。。。)

良いスタイルガイドを知ることは、自分の組織やプロダクトでどのようなスタイルガイドを作成すればいいか、重要なヒントが隠されていると思います。

進化の早いフロントエンドの世界についていくために、スタイルガイドを有効活用しているという話

この記事は[AngularJS Advent Calendar 2014 - Adventar](http://www.adventar.org/calendars/350)の 3 日目の記事です。

- 2 日目[AngularJS BootstrapUI を利用した FilterSelect(@takeyama)](http://qiita.com/takeyama/items/f6e0fbac4d3b4907193e)
- 4 日目[初心者マークの Angular.js - Uemmra3 のフルスタックエンジニア？日記(@Uemmra3)](http://d.hatena.ne.jp/Uemmra3/20141204/1417696122)

AngularJS でそれなりの規模のアプリケーションを書く場合、プロジェクトの構成って結構悩みます。  
いつも悩んでます。。。  
悩みすぎてちょくちょく構成変えるため、たまにアプリケーションが壊れてます。  
そんなとき心もポッキリ壊れそうになります。

そんな私が、最近いいなと思っている AngularJS のプロジェクト構成について紹介します。



## 参考資料(有名どころ)

AngularJS のプロジェクトの構成については、結構以前から議論されています。有名どころではこのあたりでしょうか…  
(正直、これで決まりといったものは無いような気がします。)

- [angular/angular-seed](https://github.com/angular/angular-seed)
- [johnpapa/angularjs-styleguide](https://github.com/johnpapa/angularjs-styleguide#application-structure)
- [Brian Ford/Building Huuuuuge Apps with AngularJS](http://briantford.com/blog/huuuuuge-angular-apps)
- [Angular Best Practice for App Structure (Public)](https://docs.google.com/document/d/1XXMvReO8-Awi1EZXAXS4PzDzdNvV6pGcuaF4Q9821Es/pub)

私の場合は[DaftMonk/generator-angular-fullstack](https://github.com/DaftMonk/generator-angular-fullstack)を利用することが多いので、基本的には generator-angular-fullstack 構成に
johnpapa/angularjs-styleguide の内容を加味しながらやってます。

## アンチパターン(folders-by-type)

まず、それなりの規模開発をする場合のアンチパターンの紹介。johnpapa/angularjs-styleguide にも載っているのですが、俗に`folders-by-type`と呼ばれるものがアンチパターンとされています。  
AngularJS のモジュールのタイプに合わせてディレクトリを作成して、その中に各機能の javascript ファイルを格納する方式です。

機能が増えるほど、ファイルが分散して大変そうなのが想像できるかと思います。

```
app/
    app.js
    controllers/
        hoge.controller.js
    directives/
        one.directive.js
        one.directive.html
        two.directive.js
        two.directive.html
    services/
        hoge.service.js
        fuga.service.js
    views/
        hoge.html
        some.html
```

## ベストプラクティス(Folders-by-Feature)

アンチパターン(folders-by-type)に対して、良いとされているのが`Folders-by-Feature`と呼ばれる機能単位にフォルダを分ける方法です。機能単位いうよりも**コンポーネント単位**と呼んだ方がしっくりくると思います。

generator-angular-fullstack を使った場合は、次のようなフォルダ構成になります。(`client以下`だけ抜粋)

```
app/
  main/             # 各機能単位のフォルダ
  assets/           # 画像ファイルなどのリソース
    images/
  components/       # 再利用する想定のコンポーネント
  bower_components/ # bowerモジュール
```

`main/`の中身は以下のような構成になっていて、URL の Path が`/`の場合に表示する画面のコンポーネント一式が格納されています。

```
main/
  main.js                 # Router
  main.controller.js      # Controller
  main.controller.spec.js # Test spec
  main.html               # Template
  main.css                # Style
```

AngualrJS を使った開発をする場合、Javascript ファイルを細かく分割しながら開発することが多いので、このように機能単位で 1 つのフォルダにまとまっていると見通しがいいです。  
さらにこうすることで、**機能単位で git の branch を作成して開発することが可能**です。

これらのこともあって、それなりの規模感の場合は`Folders-by-Feature`方式を採用する方がいいと思います。

## 自分がカスタムしている部分

基本的に generator-angular-fullstack で作成されたプロジェクト構成をベースに使ってますが、自分なりにカスタムしている部分もあります。そのあたり紹介したいと思います。

### Core モジュールフォルダ

バックエンドのデータアクセスや認証部品など、アプリケーション全体で利用するようなモジュールの置き場所として`app/core`以下を利用しています。

```
app/
  main/             # 各機能単位のフォルダ
  core/             # アプリケーション共有モジュール
    auth/
      auth.service.js
    someApicall/
      someApicall.service.js
  assets/           # 画像ファイルなどのリソース
    images/
  components/       # 再利用する想定のコンポーネント
  bower_components/ # bowerモジュール
```

プロジェクトでの再利用観点で`components/`との使い分けなのですが、私の場合は UI が付属するものは`components/`に格納しするように使い分けしています。

### partials テンプレートフォルダ

AngularJS ではテンプレート(html)にディレクティブを書き込んでいくため、テンプレートが大きくなりやすいと感じています。

そこで良く利用するのが`ng-include`です。そのため generator-angular-fullstack:route で作成したフォルダに`partials`フォルダを作成して inclide するテンプレートを格納するようにしています。

```
main/
  main.js                 # Router
  main.controller.js      # Controller
  main.controller.spec.js # Test spec
  main.html               # Template
  main.css                # Style
  partials/               # テンプレート部品
    megaButton.html
    hugeInputArea.html
```

あ、この画面だけで利用する filter なんかも格納しています。

### filters フォルダ

アプリケーション全体で使う filter については置き場所悩みました。現在は直下の`filters`に格納して様子を見ています。

```
app/
  main/             # 各機能単位のフォルダ
  assets/           # 画像ファイルなどのリソース
    images/
  components/       # 再利用する想定のコンポーネント
  filters/          # 再利用する想定のfilter
    snsAvater/
      snsAvater.filter.js
      snsAvater.filter.spec.js
  bower_components/ # bowerモジュール
```

### config フォルダ

開発と本番で config を分けたいケースがあるので、`config/environment`以下に実行環境ごとの config を格納しています。

```
app/
  main/             # 各機能単位のフォルダ
  assets/           # 画像ファイルなどのリソース
    images/
  components/       # 再利用する想定のコンポーネント
  config/
    environment/
      development.js  # 開発環境用
      production.js   # 本番環境用
      test.js         # テスト環境用
  bower_components/ # bowerモジュール
```

開発/本番の切り替えは generator-angular-fullstack の Grunt タスクを改造しています。テスト環境の config は`karma.conf.js`にてロードする config を指定しています。

## まとめ

私が普段使っている AngularJS のプロジェクト構成について紹介しました。たぶん半年くらい使ってみてちょくちょく変えると思います。

とはいえ、ぶっちゃけ好みの問題ですけどね・・・

そんな、試行錯誤の成果を[DaftMonk/generator-angular-fullstack](https://github.com/DaftMonk/generator-angular-fullstack)を Fork して[mitsuruog/generator-angular-mitsuruog](https://github.com/mitsuruog/generator-angular-mitsuruog)にまとめています。AngularJS できれいにアプリケーション作りたい人は、Yeoman でオレオレ AngularJS プロジェクトテンプレート作ってみるのもいいと思います。

December, 2014

2014年を振り返る

AngularJSの$resourceの意外なハマりポイント

一度使ったらやめられないMEANスタック開発が捗るgenerator-angular-fullstackの便利機能の紹介

進化の早いフロントエンドの世界についていくために、スタイルガイドを有効活用しているという話

いま一番気に入っているAngularJSのプロジェクト構成