前回、[Heroku Connect の Configuration ファイルが辛いので美しくするモジュールを書いた](http://blog.mitsuruog.info/2016/02/heroku-connect-configuration-comb.html)の続きっぽいもの。

通常のシステム開発では、開発、ステージング、本番など複数環境を利用することが多いので、複数環境間で Configuration ファイルの差分を出すモジュールを書いてみました。



## モチベーション

ここでの Configuration とは、Salesforce 上のオブジェクトと Heroku の postgres 上のカラムを紐付けている Mapping 定義のことです。

Mapping 定義から項目の Mapping が消えると、その項目が Heroku 上の postgres から消えます。
つまり、リリースなどで Mapping 定義がリグレッションすると、今まで動作していたアプリケーションが動かなくなります。

リリース時に Mapping 定義が正しくリリースされていることを証明するためには、Mapping 定義を Configuration ファイルに定義して各環境に import し、適用結果の差分を比べることが最も良い方法だと考えました。

> 適用 => 抽出 => 比較

そこで前回、作成した Configuration ファイルを整形するモジュールを利用して、Configuration ファイルの差分を抽出するモジュールを書きました。

[mitsuruog/heroku-connect-configuration-compare: Fetch two Heroku Connect Configuration and Compare together](https://github.com/mitsuruog/heroku-connect-configuration-compare)

## 使い方

使い方は簡単です。
npm モジュールをインストールして、比較したい Heroku アプリ名を指定してください。

```
npm install --global heroku-connect-configuration-compare
heroku-connect-configuration-compare one-heroku-appname other-heroku-appname
```

差分が Diff として参照できます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2016/heroku-connect-diff.png)

> 注）[ Heroku Toolbelt](https://toolbelt.heroku.com/)と[heroku-connect-plugin](https://github.com/heroku/heroku-connect-plugin)がインストールしていることが前提です。

## TODO

現在、次の改善点があります。モチベーションが続いたら改善したいです。

- 比較する対象に git remote の alias 名を利用する
- 比較除外プロパティの追加
  - applied_at, exported_at あたりは比較不要かと

## 最後に

HerokuConnect の利用者が増えると、もっと開発や運用する上での課題が明らかになりそうですね。
こんなのまだ、氷山の一角だと思います。

HerokuConnect Configurationファイルの差分を出すモジュールを書いた

[Heroku Connect](https://www.heroku.com/connect)は、Salesforce と Heroku 上の postgres とを接続するアドオンです。

Heroku Connect を使うことで、ほぼリアルタイムに Salesforce と Heroku のデータを同期させることができます。
これにより、Heroku 上で Salesforce のデータを利用することができ、これまでの Salesforce の常識にとらわれない新しい Saleforce の使い方が可能になります。

Heroku Connect を実際に利用して、Configuration ファイル仕様が辛かったので、うまく付き合うための npm モジュールを作りました。



## モチベーション

ここでの Configuration とは、Salesforce 上のオブジェクトと Heroku の postgres 上のカラムを紐付けている Mapping 定義のことです。
Configuration は Heroku Connect のダッシュボードや[heroku コマンドのプラグイン](https://github.com/heroku/heroku-connect-plugin)をインストールすることで、JSON としてエクスポートすることができます。

こちらがエクスポートしたものです。

```json
{
  "mappings": [
    {
      "config": {
        "sf_max_daily_api_calls": 30000,
        "sf_notify_enabled": false,
        "fields": {
          "Email": {},
          "LastName": {},
          "Id": {},
          "IsDeleted": {},
          "Title": {},
          "Rating": {},
          "Status": {},
          "Name": {},
          "SystemModstamp": {},
          "IsConverted": {},
          "CreatedDate": {},
          "Company": {},
          "FirstName": {}
        },
        "access": "read_only",
        "sf_polling_seconds": 600
      },
      "object_name": "Lead"
    },
    {
      "config": {
        "sf_max_daily_api_calls": 30000,
        "sf_notify_enabled": false,
        "fields": {
          "Description": {},
          "ContactId": {},
          "CaseNumber": {},
          "Id": {},
          "Subject": {},
          "ClosedDate": {},
          "Status": {},
          "SystemModstamp": {},
          "Reason": {},
          "Type": {},
          "IsClosed": {},
          "CreatedDate": {},
          "IsDeleted": {},
          "IsEscalated": {},
          "Priority": {}
        },
        "access": "read_only",
        "sf_polling_seconds": 600
      },
      "object_name": "Case"
    }
  ],
  "version": 1,
  "connection": {
    "organization_id": "00DE0000000L6REMA",
    "app_name": "heroku-connect-mitsuruog-dev",
    "exported_at": "2016-02-04T08:25:16.681265+00:00"
  }
}
```

もう一度、エクスポートしてみますね。

```json
{
  "connection": {
    "organization_id": "00DE0000000L6REMA",
    "exported_at": "2016-02-04T08:26:20.736598+00:00",
    "app_name": "heroku-connect-mitsuruog-dev"
  },
  "version": 1,
  "mappings": [
    {
      "config": {
        "sf_polling_seconds": 600,
        "sf_max_daily_api_calls": 30000,
        "fields": {
          "Email": {},
          "SystemModstamp": {},
          "CreatedDate": {},
          "LastName": {},
          "Status": {},
          "Rating": {},
          "IsDeleted": {},
          "IsConverted": {},
          "Title": {},
          "Id": {},
          "Company": {},
          "Name": {},
          "FirstName": {}
        },
        "sf_notify_enabled": false,
        "access": "read_only"
      },
      "object_name": "Lead"
    },
    {
      "config": {
        "sf_polling_seconds": 600,
        "sf_max_daily_api_calls": 30000,
        "fields": {
          "Description": {},
          "SystemModstamp": {},
          "CreatedDate": {},
          "Subject": {},
          "Status": {},
          "Reason": {},
          "IsEscalated": {},
          "IsDeleted": {},
          "ClosedDate": {},
          "Type": {},
          "Priority": {},
          "CaseNumber": {},
          "IsClosed": {},
          "Id": {},
          "ContactId": {}
        },
        "sf_notify_enabled": false,
        "access": "read_only"
      },
      "object_name": "Case"
    }
  ]
}
```

....え！？

Mapping を変更していないにも関わらず、エクスポートするたびに(気まぐれで)順序がバラバラになります。

システム開発を行う過程で Mapping の変更はそれなりの頻度があり、Configuration ファイルにて変更点を管理したいのですが、これでは変更点がわかりません。
そこで、アルファベット順でソートする node モジュールを書きました。

[mitsuruog/heroku-connect-configuration-comb: Makes your Heroku Connect Configuration beautiful](https://github.com/mitsuruog/heroku-connect-configuration-comb)

## 使い方

使い方は簡単です。
`input.json`にエクスポートした Configuration ファイルを指定してください。

```
npm install --g heroku-connect-configuration-comb
heroku-connect-configuration-comb input.json output.json
```

これで Configuration ファイルが見れるものになりました。

## 最後に

そのうち本家で改善されるでしょう。。。
(中の人が気づいたら、リポジトリに star してくれたらいいな。)

Heroku Connect のコンセプトは非常にいいのですが、プロダクトの完成度としてやや利用者視点に欠けた部分が多い印象を持っています。
今後のアップデートに期待したいです。

Heroku ConnectのConfigurationファイルが辛いので美しくするモジュールを書いた

最近の 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 で参照できる内容もおおくありますし。。。)

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

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

「Node.js って何それ。おいしいの？」
「それってお金になるの？」
そんな SIer の社内で業後に有志を集めて Node.js のハンズオンをやってみたという、夢のある話を少しします。



1.  教材について
2.  メンバー構成
3.  ハンズオンやってみた感想とか
4.  まとめ

## 1. 教材について

はじめに、教材の利用とリポジトリの Fork 許可してくれた[@yosuke_furukawa](http://twitter.com/yosuke_furukawa)さん、本当にありがとうございました！

本家のリソースはこちらです。

[https://github.com/yosuke-furukawa/node_study](https://github.com/yosuke-furukawa/node_study)

で、私が実際にハンズオンで使用した Fork したものはこちらです。

[https://github.com/mitsuruog/node_study](https://github.com/mitsuruog/node_study)

Fork した方は、以下の点を少し修正を加えています。

- jQuery 依存コードを VanillaJS に置き換え
- デバック関連についてのページを追加

目次については以下の内容となっています。

1.  REPL
2.  Node.js で HelloWorld
3.  Node.js のモジュールの作り方
4.  NPM でのモジュール探訪
5.  Express 環境構築
6.  Express 入門
7.  Socket.io 入門

Node.js の基礎から Express ＋ socket.io をつかった websocket のリアルタイム chat 作成まで網羅されていて、一通り Node.js の楽しさについて学べると思います。

個人的には、Node.js のモジュールの作り方、EventEmitter の使い方など、Node.js のコアとなる考え方について、丁寧に解説されていたことが採用の決め手となりました。

## 2. メンバー構成</span></u>

さて、肝心なハンズオンのメンバー構成は、講師役の私を含めて９名。

うちチューター役が１名の構成でした。

メンバーのほとんどは Javascript の経験がなく（中にはコード書かないマネージャもいたりして w）、エディタも windows のテキストエディタで行うといったような、開始前はゴールできるのか正直不安でした。

## 3. ハンズオンやってみた感想</span></u>

で、やってみた結果、19:30 から開始して３時間後の 22:30 に無事終了しました。

2 名を除いて完走することができました。

Websocket のチャットをやっていた終盤は、あちこちで「動いたー」「おーすげー」と少しお祭り騒ぎとなって、プログラムを作って動かす楽しさを体験できたかなと思います。普段、コードを書いていない SIer のエンジニアにとってはいろんな意味で新鮮だったと思います。

自分も初めて Node.js 触って悪戦苦闘していた頃を思い出したりして、教えている方も楽しかったですね。

## 4.まとめ

後日メンバーにアンケートに協力してもらったのですが、結構評判良かったです。
社外でもこの手のハンズオンは結構あるのですが、同じ社内ということもあり、分からない部分について質問しやすい環境だったと思います。
自分でやったときは、周りに Node 詳しい人皆無だったので、夜こつこつやって 1 週間くらい掛かったかと思います。やっぱり知っている人に教えてもらいながらの方が、学習効率はいいですね。

この教材であれば、初心者でも講師さえいれば 3 時間でゴールできますので、どんどん活用してみてください。

SIerでNode.js初心者を集めてハンズオンをやってみたという夢のある話

socket.io で有名な LearnBoost が公開している Node 製 SeleniumServer クライアントをさくっと紹介します。
だって、フロントエンドエンジニアは Javascript で Selenium 動かしたいんだもん。

この記事は[Selenium Advent Calendar 2013](http://www.adventar.org/calendars/128)の 19 日目の記事です。

前の記事は[[hinac0 さん]Selenium vs Mercury](http://0dan5.wordpress.com/2013/12/18/1-3/)

次の記事は[[らんさぶさん]Selenium Tips - つれづれなるままに。](http://dolias2010.hatenablog.com/entry/2013/12/20/012714)



1.  soda とは
2.  soda を使ってみる
3.  soda の注意点
4.  まとめ

## 1. soda とは

[soda](https://github.com/LearnBoost/soda)とは socket.io で有名な LearnBoost が公開している、Node 製 SeleniumServer クライアントです。
簡単に言うと、Selenium の実行コードを Javascript で書いて、Nodejs で実行するためのモジュールです。
公式では「**Selenium Node Adapter.**」と謳ってます。

# 2. soda を使ってみる。

（ちなみに、私の環境は Mac です。一応、会社の windows7 も動作してます。）

まず、SeleniumServer をインストールします。Mac の場合は brew で一発インストールです。
本当に brew 偉大。

```
brew install selenium-server-standalone
```

公式サイトからダウンロードしても、もちろん構いません。
[http://www.seleniumhq.org/download/](http://www.seleniumhq.org/download/)

brew でインストールすると起動用のコマンドが表示されまうので、一旦覚えておきます。
面倒なかたは ailas 張った方がいいでしょう。

```
java -jar /usr/local/opt/selenium-server-standalone/selenium-server-standalone-2.37.0.jar -p 4444
```

soda を動かす際は、事前に SeleniumServer を起動させておきます。

まさか、Selenium やるのに Firefox インストールしていない方はいないと思いますが、インストールしていない方はインストールしましょう。(自分がそうでした w)

それでは、サンプルのプロジェクトを作成して soda を動かしてみます。

適当なフォルダに soda を npm からインストールします。

```
mkdir soda-sample
cd soda-sample
npm init
npm install --save soda
```

プロジェクト直下に「google.js」ファイルを作成して、次のようなテストコードを書きます。

```js
/**
 * Module dependencies.
 */

var soda = require("soda"),
  assert = require("assert");

var browser = soda.createClient({
  host: "localhost",
  port: 4444,
  url: "https://www.google.co.jp/",
  browser: "firefox",
});

browser.on("command", function (cmd, args) {
  console.log(" \x1b[33m%s\x1b[0m: %s", cmd, args.join(", "));
});

browser.chain
  .session()
  .open("/")
  .type("q", "Hello World")
  .click("btnK")
  .waitForTextPresent("Hello World")
  .getTitle(function (title) {
    assert.ok(
      ~title.indexOf("Hello World"),
      "Title did not include the query: " + title
    );
  })
  .end(function (err) {
    browser.testComplete(function () {
      console.log("done");
      if (err) throw err;
    });
  });
```

後は node コマンドから起動してみます。

```
node google.js
```

そうすると、横で Firefox が勝手に起動してテストしてくれます。
正常にテストが行われた場合、ターミナルにはこのように表示されます。

```sh
mitsuruog:soda-sample mitsuruog$ node google.js
getNewBrowserSession: *firefox, https://www.google.co.jp/
http.createClient is deprecated. Use `http.request` instead.
open: /
type: q, Hello World
click: btnK
waitForTextPresent: Hello World
getTitle:
testComplete:
done
```

## 3. soda の注意点

このように簡単に Node から Selenium を呼び出せる soda ですがいくつか注意点があります。

まず、「http.createClient is deprecated. Use `http.request` instead.」が象徴しているように、ここ１年くらいメンテナンスされていません。また、Chrome など他の WebDriver には対応してないようです。つまり「Firefox only」です。

## 4. まとめ

Node で Selenium を起動できる Driver モジュール soda いかがだったでしょうか。

機能限定ながらフロントエンジニアが Javascript でテストコードを書けて Node で実行できるというのは、ハマればメリットがあると思いました。

また、Node から Selenium を起動できるものは他にも[wd（https://github.com/admc/wd/）](https://github.com/admc/wd/)というものがあり、他の WebDriver をサポートしているなど、機能が豊富でなかなか強力です。

機会があれば、こちらも紹介したいですね。

NodeからSeleniumServerを動かすLearnBoost製クライアントがあるsoda

nodejs で express を使って routing する際に、少し知ってると REST API っぽい URL 設計で routing できるので紹介します。



まず、基本編。

```js
var express = require("express"),
  http = require("http");

var app = express();
app.get("/content/*", function (req, res) {
  console.log(req.params);
  res.send(req.params);
});

http.createServer(app).listen(3000);
console.log("Express server listening on port 3000");
```

URL とそれを呼び出したときの req.params の内容です。

```
http://localhost:3000/content/
http://localhost:3000/content/aaaa
http://localhost:3000/content/aaaa/bbbb

[ '' ]
[ 'aaaa' ]
[ 'aaaa/bbbb' ]
```

次に REST API っぽく。

```js
var express = require("express"),
  http = require("http");

var app = express();
app.get("/products/:id/:operation?", function (req, res) {
  console.log(req.params);
  res.send(req.params);
});

http.createServer(app).listen(3000);
console.log("Express server listening on port 3000");
```

URL とそれを呼び出したときの req.params の内容です。

```
http://localhost:3000/products/
http://localhost:3000/products/12
http://localhost:3000/products/12/edit
http://localhost:3000/products/12/delete
http://localhost:3000/products/delete

Cannot GET /products/
[ id: '12', operation: undefined ]
[ id: '12', operation: 'edit' ]
[ id: '12', operation: 'delete' ]
[ id: 'delete', operation: undefined ]
```

「:id」に req.params[0]が「:operation」に req.params[1]がセットされています。
実際には指定している URL リテラルは、次で出てくるような正規表現に内部でコンパイルされるようです。

最後は URL に正規表現リテラルを指定する場合。

```js
var express = require("express"),
  http = require("http");

var app = express();
app.get(/^\/node?(?:\/(\d+)(?:\.\.(\d+))?)?/, function (req, res) {
  console.log(req.params);
  res.send(req.params);
});

http.createServer(app).listen(3000);
console.log("Express server listening on port 3000");
```

URL とそれを呼び出したときの req.params の内容です。

```
http://localhost:3000/node/
http://localhost:3000/node/10
http://localhost:3000/node/10..100

[ undefined, undefined ]
[ '10', undefined ]
[ '10', '100' ]
```

こんな感じで正規表現を使うと、ページ指定っぽいこともできます。

URL がばっちり決まると API 作ってるサーバサイドエンジニアもモチベーション上がりますね。（あくまで個人的感想です。）

nodejsとexpressでREST APIっぽいURLでroutingする方法

nodejitsu でホスティングした場合、ドメインは「_hoehoe_.jit.su」か「_hoehoe_.nodejitsu.com」（*hoehoe*は自分で決めれる。）となります。  
やっぱり自分で持ってるカスタムドメインで使いたいなと思ったので、やってみました。



とは言っても･･･
基本的に日本人で nodejitsu を使おうと思っているような人は、英語に抵抗がない部類の人だと思いますので、[ここのページ](http://dns.jit.su/)に書いている手順に沿ってサクッとやってしまうと思うのですが、nodejitsu の敷居を下げるために頑張ります。

## 1.nodejitsu.com の IP を調べる。

まず、nodejitsu.com の IP を調べます。私は windows ユーザーなので、黒い画面で ping コマンドを使います。

```
ping nodejitsu.com
```

おそらく、次の IP のうちのどれかが帰ってくると思いますので、メモしておきます。

```
165.225.129.253
165.225.130.235
165.225.130.237
165.225.130.238
165.225.130.239
165.225.130.240
165.225.130.241
165.225.131.4
165.225.131.5
```

## 2.ドメインを管理しているプロバイダの DNS を変更する。

私の場合は[GoDaddy](http://www.godaddy.com/)でドメイン持っているので、ここでの説明は GoDaddy をベースに行いますが他のプロバイダでも基本的にはやることは同じだと思います。

手順は GoDaddy の「DNS Manager」にて「A レコード」を変更します。

例えば、カスタムドメインが「mitsuruog.com」だったとして、

「mitsuruog.com」を nodejitsu のトップドメインとして使いたい場合は、次のような設定をします。

```
Host=@
Points to=1.で調べたIP（165.225.129.253とか）
```

カスタムドメインのサブドメイン（node.mitsuruog.com とか）を nodejitsu のトップドメインとして使いたい場合は、次のような設定をします。

```
Host=node
Points to=1.で調べたIP（165.225.129.253とか）
```

「TTL」は特に必要がなければそのままで、変更する必要はないと思います。

ちなみに、DNS を変更した場合、反映されるまで 48 時間くらい掛かります、気長に待ちましょう。
DNS が反映された場合、上のドメイン（`http://mitsuruog.com`とか）をブラウザで開くと、nodejitsu の 404 ページが表示されるようになりますので、目安にしてください。

## 3.package.json の変更

nodejitsu 側の設定はすべて package.json にて指定します。（さすが Paas！）

手順は package.json に上で指定したカスタムドメインを追加するだけです。

```
{
  "name": "mitsuruog",
  "subdomain": "mitsuruog",
  "domains": [
    "node.mitsuruog.com"
  ],
  "scripts": {
    "start": "./server.js"
  },


・・・（中略）・・・


  "engines": {
    "node": "v0.8.x"
  }
}
```

## 4.nodejitsu 上にデプロイ

最後は nodejitsu にデプロイして完了です。
黒い画面で操作してください。

```
jitsu login
jitsu deploy
```

以上の手順でカスタムドメインで運用できると思いますので、頑張ってみてください。

nodejitsuでカスタムドメインを使う方法

本ブログは[東京 Node 学園祭 2012 アドベントカレンダー](http://atnd.org/events/33022)の 6 日目の記事です。

今回は[nodejitsu](http://nodejitsu.com/)を使って sockect.io を使ったアプリをホスティングしたところ、websocket（以下、ws）まわりで思わぬハマりポイントがあったというお話しをします。  
（同じようなトラブルで悩む方に少しでもヒントをあげられたらと考えています。）



### このエントリでお伝えしたいこと。

1. ws 通信は 443 ポート（wss）で行った方が良い。
2. ws のみがブロックされた場合に socket.io が怪しい挙動をする…（Help me!）
3. nodejitsu なかなか好いよ。

## ws 通信は 443 ポート（wss）で行った方が良い。

既に周知の事実かもしれませんが、通常の HTTP（80 ポート）を使って ws 通信を行った場合、
サーバから送信された ws の通信データが、クライアントのブラウザに到達する前に（セキュリティソフト、firewall、proxy…などなど）ブロックされることがあります。  
（詳しく知りたい方は[こちらのエントリ](https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-firewall-software)を読んでみてください。）

サーバを正しく実装したにも関わらず ws が届かないようなときは、そもそもクライアントが ws 受信できる状態なのか、次の 2 つのサイトにて確認してみてください。

- [http://websocketstest.com/](http://websocketstest.com/)（ws と Comet の疎通確認ができるサイトです。）
- [http://wsping.jit.su/](http://wsping.jit.su/)（nodejitsu の websoketPing サイトです。）

例えばですが、80 ポートの ws がブロックされている場合は次のような結果となります。

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

で、厄介なのが、セキュリティソフトにてブロックされている場合で、
ws の疎通確認自体は OK なのですが、ws がなぜか届かない状態となってしまったので、原因を特定するのに少し時間がかかりました。

_（私の場合はウイルスバスタークラウド 2012 がブロックしていました。**こちらについては Trend Micro のサポートとやりとりしているので、**何か進展あっておもしろそうだったら書くかもしれません。）_

## ws のみがブロックされた場合に socket.io が怪しい挙動をする…

さて、nodejs で ws 使う際は socket.io を使うのがデファクトとなっているのは皆さんご存知だと思います。
socket.io ではクライアントが ws 使えない場合、通信手段を ws から XmlHttpRequest などに自動でダウングレードしてくれる便利機能があるのですが、今回のように ws のみがブロックされるような場合、そのダウングレード機能がうまく働きませんでした。

ws の正しい挙動としては、まず http でハンドシェイクを行い、ハンドシェイクができた後に ws にプロトコルを変更して通信する流れなのですが、どうやらハンドシェイクを確立した後に ws のみがブロックされている場合、socket.io にて通信手段の変更ができないようです。

（念のため、Chrome で取ったヘッダーとか載せときますね。）

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

```txt
Request URL:ws://wsping.jit.su/socket.io/1/websocket/dL7NXuBCnWhqnZMPAYkU
Request Method:GET
Status Code:101 Switching Protocols
Request Headersview source
Connection:Upgrade
Host:wsping.jit.su
Origin:http://wsping.jit.su
Sec-WebSocket-Extensions:x-webkit-deflate-frame
Sec-WebSocket-Key:4EjkGu1WajTwi0MOvQjOyw==
Sec-WebSocket-Version:13
Upgrade:websocket
(Key3):00:00:00:00:00:00:00:00
Response Headersview source
Connection:Upgrade
Sec-WebSocket-Accept:lbl4DxvLmfnTm2okzQxld/Yb/sE=
Upgrade:websocket
(Challenge Response):00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
```

正直、この挙動が仕様なのかバグなのか、それとも私の実装が悪いのか判断できず、一度詳しい方の見解を聞いてみたいです。（Help me!）

今回の件で、改めて新しいプロトコル導入期のライアント周辺環境（N/W とかセキュリティとか）の課題が大きいなと感じました。（SPDY もそうなんですが･･･）
現状、より多くのユーザの元に socket.io を使った通信を届けるためには、ws の通信を wss とするか、通信手段を XmlHttpRequest などにダウングレードするのが無難なのかもしれません。

（ちなみに先に紹介した nodejitsu の websocketPing サイトですが、ws が届いていない人も URL を https に変えてアクセスすると届いたりします。）
（ちなみに、私は windows ユーザなので、ならではの話題だったりして･･･）

## nodejitsu なかなか好いよ。

最後に 2 か月くらい[nodejitsu](http://nodejitsu.com/)使って遊んでますが。良かった点を書き連ねてみます。（CEO の[
Charlie Robbins 氏](https://twitter.com/indexzero)も来ることですし。）

- websocket が使える。
- 無料期間は 1 ヵ月。Micro プランで月$3。（円高最高！）
- jitsu を使ったクラウド上へのデプロイがシンプルで簡単（ただし、package.json にモジュールの依存関係を正しく書くこと）。
- サーバ側の実装を変えずに https 対応（ws も wss となる）できる。

実は nodejitsu、初めの頃は結構不安定（落ちてたり、デプロイできなかったり。。。）で「なんだかな～」と思った時期もあったのですが、9 月のアップデート以降は安定してます。

それから、まだ周辺ツール（ログの監視とか）がまだ充実してない印象があるので、これからの進化に期待といったとこでしょうか？
とにかく、これから nodejs 始める方は使ってみてはいかがでしょうか？

> **修正（2012/10/21)**  
> Jxck さんの指摘反映  
> websocket のセキュアなプロトコルは https ではなく wss。

websocketを使う際の意外な落とし穴

nodejs は http の Web サーバだけではなく、TCP や UDP サーバも少ない行数で作ることができます。
今回はコマンドプロンプトを使った対話型の TCP サーバを作ってみました。



普通に http サーバいつも書いている人であれば、そんなに難しいところはないと思います。
3000 ポートで listen させてます。

サーバ側

```js
var net = require("net");

var server = net
  .createServer(function (conn) {
    console.log("server-> tcp server created");

    conn.on("data", function (data) {
      console.log(
        "server-> " +
          data +
          " from " +
          conn.remoteAddress +
          ":" +
          conn.remotePort
      );
      conn.write("server -> Repeating: " + data);
    });
    conn.on("close", function () {
      console.log("server-> client closed connection");
    });
  })
  .listen(3000);

console.log("listening on port 3000");
```

クライアント側

```js
var net = require("net");

var client = new net.Socket();
client.setEncoding("utf8");

client.connect("3000", "localhost", function () {
  console.log("client-> connected to server");
  client.write("Who needs a browser to communicate?");
});

process.stdin.resume();

process.stdin.on("data", function (data) {
  client.write(data);
});

client.on("data", function (data) {
  console.log("client-> " + data);
});

client.on("close", function () {
  console.log("client-> connection is closed");
});
```

実行すると次のようにコマンドプロンプトに表示されます。

```
At Server
------------------------------------------------------
listening on port 3000
server-> tcp server created
server-> Who needs a browser to communicate? from 127.0.0.1:51196
server-> hoehoe
 from 127.0.0.1:51196
server-> Hello!
 from 127.0.0.1:51196

server-> client closed connection（←クライアントからの切断）



At Client
------------------------------------------------------
client-> connected to server
client-> server -> Repeating: Who needs a browser to communicate?
hoehoe（←コマンドプロンプトからの入力）
client-> server -> Repeating: hoehoe

Hello!（←コマンドプロンプトからの入力）
client-> server -> Repeating: Hello!

client-> connection is closed（←サーバからの切断）
```

nodejs で作ると簡単ですね。

nodejsでTCPサーバ

いまいち npm 使えてないなと思ったので、いろいろ調べてみました。  
内容は俺得仕様です。



### このエントリでお伝えしたいこと。

1.  nodejs を普通に使っていく上で困らない程度の npm コマンドの知識。

## では行きます。

まず、基本のインストール関係から。

```
npm install module_name
```

「-g」か「-global」オプションを付けるとグローバルインストールできます。
私は「node-inspector」をグローバルインストールしてますが、基本ローカルインストールで充分だと思います。

```
npm -g install module_name
```

次は、特定のバージョンをインストールしたい場合です。

```
npm install module_name@0.0.1
```

まだ npm にないとか、自分で Fork したモジュールをインストールしたい場合は、直接 Github のリポジトリを指定してもいいです。

```
npm install https://github.com/mitsuruog/socket.io/tarball/master
```

「Github の URL/tarball/ブランチ名」となってます。
tarball はリポジトリを tar でダウンロードするおまじないだと思ってください。
（ちなみに zip だと zipball です。）

モジュールをアンインストールしたい場合は。

```
npm uninstall module_name
```

モジュールをアップデートしたい場合は。

```
npm update module_name
```

続いてインストールされているモジュールや依存関係を見たいとき。

```
npm ls
```

ちなみに「la」「ll」でもいけます。（こちらの方が詳細な情報が見れます。）

次はインストールされているモジュールが古くなってないか確認。

```
npm outdated
```

古くなっていれば次のように差分が出ます。

```
jade@0.27.6 node_modules\jade current=0.22.0
mime@1.2.7 node_modules\express\node_modules\mime current=1.2.5
connect@1.9.2 node_modules\express\node_modules\connect current=1.8.6
qs@0.5.1 node_modules\express\node_modules\qs current=0.4.2
```

ちなみにどのコマンドも「-g」オプションを付けることで、グローバルインストールされたモジュールについても同じことが行えます。

最後は環境まわりの設定。

設定の一覧を取得。

```
npm config list
```

ちなみに get で狙い打てます。

```
npm config get keyname
```

設定の追加と削除。

```
npm config set keyname value
npm config delete keyname
```

よくやるのが proxy の設定で次のようにやればうまくいきます。

```
npm config set proxy http://localhost:8080
```

proxy 以外の設定は恐ろしいので手を出していません。

おまけ  
キャッシュのクリア

```
npm cache clear
```

以上です。  
このあたりのコマンド押さえれば、そう npm で困らないはず。

Tag: nodejs