chore: update deps (#126)

Author: azu

ja/ESLint/README.md

@@ -123,7 +123,7 @@ debug("Hello");
 - [Documentation - ESLint - Pluggable JavaScript linter](http://eslint.org/docs/developer-guide/working-with-rules "Documentation - ESLint - Pluggable JavaScript linter")
 - [コードのバグはコードで見つけよう！｜サイバーエージェント 公式エンジニアブログ](http://ameblo.jp/principia-ca/entry-11837554210.html "コードのバグはコードで見つけよう！｜サイバーエージェント 公式エンジニアブログ")
 
-## どういう仕組み?
+## どのような仕組み?
 
 ESLintはコードをパースしてASTにして、そのASTをJavaScriptで書いたルールを使いチェックする
 という大まかな仕組みは分かりました。
@@ -184,7 +184,7 @@ function lint(code){
 ```
 
 Pub/Subパターンを上手く使うことで、ASTを走査するのが一度のみで、
-それぞれのルールに対してどういうコードかという情報が`emit`で通知できていることがわかります。
+それぞれのルールに対してどのようなコードかという情報が`emit`で通知できていることがわかります。
 
 もう少し具体的にするため、実装して動かせるようなものを作ってこの仕組みについて見ていきます。
 
@@ -240,7 +240,7 @@ add(1, 3);
 
 このようにして、ルールは `context` という与えられたものだけを使うので、ルールがMyLinter本体の実装の詳細を知らなくても良くなります。
 
-## どういう用途に向いている?
+## どのような用途に向いている?
 
 このプラグインアーキテクチャはPub/Subパターンを上手く使い、
 ESLintのように与えられたコードを読み取ってチェックするような使い方に向いています。
@@ -250,7 +250,7 @@ ESLintのように与えられたコードを読み取ってチェックする
 また、ルールは `context` という与えられたものだけを使うようになっているため、ルールと本体が密結合にはなりにくいです。
 そのため`context`に何を与えるかを決めることで、ルールが行える範囲を制御しやすいといえます。
 
-## どういう用途に向いていない?
+## どのような用途に向いていない?
 
 逆に与えられたコード(AST)を書き換える場合には、
 ルールを同時に処理を行うためルール間で競合するような変更がある場合に破綻してしまいます。

ja/Redux/README.md

@@ -68,7 +68,7 @@ Reduxでは第三者が拡張できる仕組みを _middleware_ と呼んでい
 - [Middleware | Redux](http://redux.js.org/docs/advanced/Middleware.html "Middleware | Redux")
 
 どのような拡張を _middleware_ で書けるのか、実際の例を見てみます。
-次の _middleware_ はStoreがdispatchしたActionと、その前後でStateにどういう変更があったのかを出力するロガーです。
+次の _middleware_ はStoreがdispatchしたActionと、その前後でStateにどのような変更があったのかを出力するロガーです。
 
 [import, logger.js](../../src/Redux/logger.js)
 
@@ -143,7 +143,7 @@ const middleware = (store) => {
 Reduxの _middleware_ の仕組みは単純ですが、見慣れないデザインなので複雑に見えます。
 実際に同じ仕組みを実装しながら、Reduxの _middleware_ について学んでいきましょう。
 
-## どういう仕組み?
+## どのような仕組み?
 
 _middleware_ は`dispatch`をラップする処理ですが、そもそも`dispatch`とはどういうことをしているのでしょうか?
 

ja/connect/README.md

@@ -50,7 +50,7 @@ Echoサーバでは `req.pipe(res);` という形でリクエストをそのま
 
 > **Note** _middleware_ となる関数の引数が4つであると、それはエラーハンドリングの _middleware_ とするという、Connect独自のルールがあります。
 
-## どういう仕組み?
+## どのような仕組み?
 
 Connectの _middleware_ がどのような仕組みで動いているのかを見ていきます。
 
@@ -130,7 +130,7 @@ Junctionは、`use(middleware)` と `process(value, (error, result) => { });`を
 [import junction-example.js](../../src/connect/junction-example.js)
 
 
-## どういう用途に向いている?
+## どのような用途に向いている?
 
 ConnectやJunctionの実装を見てみると分かりますが、このアーキテクチャでは機能の詳細を _middleware_ で実装できます。
 そのため、本体の実装は _middleware_ に提供するインタフェースの決定、エラーハンドリングの手段を提供するだけでとても小さいものとなっています。
@@ -150,7 +150,7 @@ app.use("/foo", function fooMiddleware(req, res, next) {
 そのため、ConnectやRackなどのHTTPサーバでは「リクエストに対してレスポンスを返す」というのが決まっているので、
 このアーキテクチャは適しています。
 
-## どういう用途に向いていない?
+## どのような用途に向いていない?
 
 このアーキテクチャでは機能の詳細が _middleware_ で実装できます。
 しかし、多くの機能を _middleware_ で実装していくと、 _middleware_ 間に依存関係を作ってしまうことがあります。

ja/gulp/README.md

@@ -46,7 +46,7 @@ gulp.task("sass", function() {
 - [現場で使えるgulp入門 - gulpとは何か | CodeGrid](https://app.codegrid.net/entry/gulp-1)
 - [gulp入門 (全12回) - プログラミングならドットインストール](http://dotinstall.com/lessons/basic_gulp)
 
-## どういう仕組み?
+## どのような仕組み?
 
 実際にgulpプラグインを書きながら、どのような仕組みで処理同士が連携を取り動作しているのかを見ていきましょう。
 
@@ -242,7 +242,7 @@ Node.js Streamのデフォルトでは流れるデータが`Buffer`となり、
 このようにして、gulpはタスクに必要な単機能のプラグインを既存のライブラリで作りやすくしています。
 これにより再利用できるプラグインが多くできることでエコシステムを構築しているといえます。
 
-## どういう用途に向いている?
+## どのような用途に向いている?
 
 gulp自体はデータの流れを管理するだけで、タスクを実現するためにはプラグインが重要になります。
 タスクにはさまざまな処理が想定されるため、必要になるプラグインも種類がさまざまなものとなります。
@@ -260,7 +260,7 @@ gulpでは[vinyl](https://github.com/gulpjs/vinyl "vinyl")オブジェクトを
 - 既存のライブラリをプラグイン化しやすい
 - 必要なプラグインがない場合も、設定としてコードを書くことで対応できる
 
-## どういう用途に向いていない?
+## どのような用途に向いていない?
 
 プラグインを複数組み合わせ扱うものに共通することですが、プラグインの組み合わせ問題はgulpでも発生します。
 

ja/jQuery/README.md

@@ -15,7 +15,7 @@ jQueryでは`$.fn`を拡張することで、`$()`の返り値となるjQueryオ
 <script src="greenify.js"></script>
 ```
 
-## どういう仕組み?
+## どのような仕組み?
 
 このjQueryプラグインがどのような仕組みで動いているのかを見てみましょう。
 
@@ -39,14 +39,14 @@ $(document.body); // 返り値はjQueryのインスタンス
 
 つまり、jQueryプラグインはJavaScriptのprototypeをそのまま利用しているだけに過ぎないということがわかります。
 
-## どういう用途に向いている?
+## どのような用途に向いている?
 
-jQueryプラグインの仕組みがわかったのでどういう用途に有効な仕組みなのか考えてみましょう。
+jQueryプラグインの仕組みがわかったのでどのような用途に有効な仕組みなのか考えてみましょう。
 
 単純なprototype拡張なので、利点はJavaScriptのprototypeと同様です。
 動的にメソッドを追加するだけではなく、既存の実装を上書きするmonkey patchのようなものもプラグインとして追加することができます。
 
-## どういう用途に向いていない?
+## どのような用途に向いていない?
 
 これもJavaScriptのprototypeと同様で、prototypeによる拡張は柔軟すぎるため、
 jQuery自体がプラグインのコントロールをすることは難しいです。

package.json

@@ -24,6 +24,7 @@
     "eslint": "eslint src/**/*.js",
     "eslint:md": "summary-to-path | xargs eslint -c .md.eslintrc --ext .md",
     "textlint": "summary-to-path | xargs textlint -f pretty-error",
+    "textlint:fix": "summary-to-path | xargs textlint --fix",
     "test:example": "find ./src -name '*-example.js' | xargs babel-node",
     "test:js": "mocha",
     "test": "npm-run-all --parallel test:js test:example textlint eslint:md eslint build",
@@ -43,25 +44,25 @@
     "babel-register": "^6.9.0",
     "codecov.io": "^0.1.6",
     "connect": "^3.4.0",
-    "eslint": "^2.3.0",
+    "eslint": "^3.10.2",
     "eslint-plugin-markdown": "^1.0.0-beta",
     "gitbook-cli": "^2.1.2",
     "gitbook-plugin-edit-link": "^2.0.0",
     "gitbook-plugin-ga": "^1.0.0",
     "gitbook-plugin-github": "^2.0.0",
-    "gitbook-plugin-include-codeblock": "^1.9.0",
+    "gitbook-plugin-include-codeblock": "^2.1.0",
     "gitbook-plugin-japanese-support": "0.0.1",
     "gitbook-plugin-richquotes": "0.0.7",
     "gitbook-summary-to-path": "^1.0.1",
     "jsdom": "^9.2.1",
     "lcov-summary": "^1.0.1",
-    "mocha": "^2.2.5",
+    "mocha": "^3.1.2",
     "nlcst-to-string": "^2.0.0",
     "node-fetch": "^1.3.2",
-    "npm-run-all": "^2.1.1",
+    "npm-run-all": "^3.1.1",
     "power-assert": "^1.4.1",
     "redux": "^3.5.2",
-    "remark": "^5.0.1",
+    "remark": "^6.2.0",
     "stemming-x-keywords": "^1.0.3",
     "textlint": "^7.0.0",
     "textlint-filter-rule-comments": "^1.2.1",
@@ -84,7 +85,7 @@
     "textlint-rule-sentence-length": "^1.0.4",
     "textlint-rule-spellcheck-tech-word": "^5.0.0",
     "textlint-rule-unexpanded-acronym": "^1.2.0",
-    "unist-util-is": "^1.0.0",
+    "unist-util-is": "^2.0.0",
     "unist-util-parents": "^0.1.1",
     "unist-util-select": "^1.0.0"
   },