ぼくのかんがえたさいきょーのnode.jsの開発環境
この資料では「ボクのかんがえた最強のnode.jsの開発環境について」説明するよ!
はじめに ここでは僕の考えた最強のnode.jsの開発環境について説明します。 node.jsはJavascriptの一種でサーバーサイドの処理を実装できます。 つまり、JavaScript使えるだけで、Web開発ができます。 やったね、社長、人件費が下がるよ! node.jsのインストール方法 http://nodejs.org/ ここから、インストーラなりソースなり取得してインストールする。 Windows,Macはインストーラが存在しており、debianとかはソースから作成する。 Windowsの場合、ちょっと癖があり、VS2008や、VS2012との混在環境だとnpm installが失敗することがある。 その場合は、環境変数を調整してVS2010が動作するようにしておくこと。 node.jsのデバッグ方法 サーバーサイドのデバッグはできない。 そう思っていた時期が僕にもありました。 node-inspector とChromeを使えばデバッグできます。 https://github.com/node-inspector/node-inspector インストール方法 >npm install -g node-inspector デバッグ対象のアプリケーションの起動 >node --debug server.js--debugフラグを使用して対象のアプリケーションを起動すると、デバッグポートが表示される。 もしデバッグポートを変更したい場合は下記のようにする node --debug=5859 app.jsもし、一行目でブレークを賭けたい場合は次の通り node --debug-brk=5859 app.js node-inspectorの起動 デバッグ対象のアプリケーションを起動したらnode-inspectorを起動する。 これにより、ブラウザ経由でデバッグが可能になる。 >node-inspector --web-port 8081 --debug-port 5859--debug-portはデバッグ対象のプロセスのポート --web-portはブラウザでデバッグするために使用するポートである。 Chromeによるデバッグ chromeでnode-inspectorを実行時に支持されたURLにアクセスするとデバッグが可能になる。 先の例だと、以下のようなURLになる。 http://ホスト名:8081/debug?port=5859 node.jsのメモリーリークの調べ方 クライアントサイドのメモリのスナップショット クライアントサイドに関してはChromeなりなんなりの開発ツールを使えばいい。 Chromeの場合はF12を押下してProfilesタブでヒープのスナップショットをとれば、どの関数でどのオブジェクトがどれだけ、存在するかがわかる。 node-webkit-agentを使用して、 https://github.com/c4milo/ 1. node-webkit-agentのインストール >npm install webkit-devtools-agent 2.下記の命令を任意のソースに記述。 var agent = require('webkit-devtools-agent'); 3. アプリケーションを起動 4. 以下のコマンドを実行 kill -SIGUSR2 <the process id of your nodejs app> 5. その後、Chromeで以下のURLにアクセスする http://c4milo.github.io/node-webkit-agent/26.0.1410.65/inspector.html?host=デバッグ対象のホスト名:9999&page=0 その後は、Profileにてメモリのスナップショットを取得すればよい。 ガベージコレクションを確実に走らせたい場合は以下のような処理が必要である。 まず、プログラム中でガベージクレクタを実行したい箇所に次のコードを埋め込む。 if(global.gc) {そして、アプリを起動する際に--expose_gcを指定する >node --expose_gc server.js 静的解析 gjslintによる静的解析 gjslintで不味い書き方を調べる。 jenkinsによって日々検査するとよい。 http://needtec.exblog.jp/22639788/ platoによるコードメトリックスの収集 platoを使用することで、ソースの行数や複雑度を計測できる。 https://github.com/es-analysis/plato インストール方法: npm install -g plato 実行方法: plato -r -d report ./srcこれによりreportフォルダ以下にHTMLが作成される。 おおむねComplexityが高いものがバグを発生しやすいので、テストケースの数や、リファクタリングの目安として監視する。 これもjenkinsで日々作成するといい。 テストの自動化 jasmine-nodeによるサーバー単体テストの記述 サーバサイドの単体テストはjasmine-nodeで記述するといい。 https://github.com/mhevery/jasmine-node --junitreportと--outputfolderオプションを用いることでjunitの形式でXMLを出力できる。 これによりjenkinsでの集計が可能になる。 jasmine1.3とjs-test-driverによるクライアントサイドの自動化 クライアントサイドの処理は厄介だ。 なぜなら、同じテストを異なるブラウザで確認しないといけない。 これはjs-test-driverとjasmine1.3とjasmine-jstd-adapterを組み合わせることで実現可能だ。 http://www.atmarkit.co.jp/ait/articles/1301/21/news017_4.html jasmineは現在2.0も存在するが、js-test-driverと組み合わせて使うには1.3である必要がある。 これにより、サーバーサイドと同じテストコードの書き方でクライアントも記述できる。 seleniumによるUIテストの自動化 seleniumを用いることで、UIのテストが自動化できる。 ただし、これは導入コストと維持コストが極めて高いので、ここぞという時だけに絞ること。 http://www.atmarkit.co.jp/ait/articles/0908/19/news109.html
|
by mima_ita 検索
カテゴリ
最新の記事
以前の記事
2014年 07月
2014年 06月 2014年 05月 2014年 04月 2013年 12月 2013年 11月 2013年 10月 2013年 09月 2013年 07月 2013年 06月 2013年 05月 2013年 03月 2012年 10月 2012年 09月 2012年 08月 2012年 04月 2012年 02月 2012年 01月 2011年 10月
最新のコメント
最新のトラックバック
ブログパーツ
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||