From be5afc499e6955939064e1d020d0b4738509b000 Mon Sep 17 00:00:00 2001 From: azu Date: Fri, 6 May 2016 10:47:45 +0900 Subject: [PATCH 1/4] =?UTF-8?q?refactor(textlint):=20=E6=95=AC=E4=BD=93(?= =?UTF-8?q?=E3=81=A7=E3=81=99=E3=81=BE=E3=81=99=E8=AA=BF)=E3=81=A8?= =?UTF-8?q?=E5=B8=B8=E4=BD=93(=E3=81=A7=E3=81=82=E3=82=8B=E8=AA=BF)?= =?UTF-8?q?=E3=81=AE=E4=BD=BF=E3=81=84=E5=88=86=E3=81=91=E3=82=92=E5=8E=B3?= =?UTF-8?q?=E5=AF=86=E3=81=AB?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit https://github.com/azu/textlint-rule-no-mix-dearu-desumasu @ 2 でpreferオプションが導入されて、 本文は"ですます"、箇条書きは"である"で書くように設定したので、それに合わせてリファクタリング。 --- .textlintrc | 6 ++- ja/ESLint/README.md | 18 ++++----- ja/connect/README.md | 78 +++++++++++++++++++-------------------- ja/gulp/README.md | 14 +++---- ja/introduction/README.md | 2 +- ja/jQuery/README.md | 8 ++-- package.json | 2 +- 7 files changed, 64 insertions(+), 64 deletions(-) diff --git a/.textlintrc b/.textlintrc index bb065f8..d72f19f 100644 --- a/.textlintrc +++ b/.textlintrc @@ -18,7 +18,11 @@ "interval": 2 }, "spellcheck-tech-word": true, - "no-mix-dearu-desumasu": true, + "no-mix-dearu-desumasu": { + "preferInHeader": "", + "preferInBody": "ですます", + "preferInList": "である" + }, "prh": { "rulePaths": [ "test/prh.yml" diff --git a/ja/ESLint/README.md b/ja/ESLint/README.md index 4ccd290..3e7a7b4 100644 --- a/ja/ESLint/README.md +++ b/ja/ESLint/README.md @@ -73,8 +73,7 @@ console.log("Hello!"); - [JavaScript AST explorer](http://felix-kling.de/esprima_ast_explorer/#/FNrLHi8ngW "JavaScript AST explorer") -ESLintではこのASTを使って、変数が未使用であるとか[no-console.js](#no-console.js)のように -`console.log`などがコードに残ってないかなどをルールを元にチェックすることができます。 +ESLintではこのASTを使って、[no-console.js](#no-console.js)のように`console.log`などがコードに残ってないかなどをルールを元にチェックすることができます。 ルールをどう書けるかという話に戻すと、`context`というオブジェクトはただのユーティリティ関数と考えて問題ありません。 ルールの本体は関数が`return`してるメソッドをもったオブジェクトです。 @@ -99,8 +98,7 @@ ESLintではこのASTを使って、変数が未使用であるとか[no-console } ``` -[no-console.js](#no-console.js)のルールを見ると`MemberExpression` typeのNodeが `node.object.name === "console"` であるなら -`console`が残ってると判断してエラーレポートすると読めてくると思います。 +[no-console.js](#no-console.js)のルールを見ると`MemberExpression` typeのNodeが `node.object.name === "console"` となった場合に、`console`が残ってると判断してエラーレポートすると読めてくると思います。 ASTの探索がイメージしにくい場合は以下のルールで探索の動作を見てみると分かりやすいかもしれません。 @@ -184,8 +182,8 @@ function lint(code){ } ``` -Pub/Subパターンを上手く使うことで、ASTをtraverseするのが一巡のみでそれぞれのルールに対して -どういうコードであるかという情報が`emit`で通知できていることがわかります。 +Pub/Subパターンを上手く使うことで、ASTを走査するのが一度のみで、 +それぞれのルールに対してどういうコードかという情報が`emit`で通知できていることがわかります。 もう少し具体的にするため、実装して動かせるようなものを作ってこの仕組みについて見ていきます。 @@ -234,8 +232,8 @@ add(1, 3); この`RuleContext`はルールから使えるユーティリティメソッドをまとめたものです。 今回は`RuleContext#report`というエラーメッセージをルールからMyLinterへ通知するものだけを実装しています。 -ルールの実装の方を見てみると、直接オブジェクトをexportしてるわけではなく、 -`context` つまり`RuleContext`のインスタンスを受け取っていることが分かると思います。 +ルールの実装の方を見てみると、直接オブジェクトをexportしないで、 +`context`として`RuleContext`のインスタンスを受け取っていることが分かると思います。 [import, no-console.js](../../src/ESLint/no-console.js) @@ -258,7 +256,7 @@ ESLintのように与えられたコードを読み取ってチェックする そのため、この仕組みに加えてもう1つ抽象レイヤーを設けないと対応は難しいです。 -つまり、read-writeなプラグインアーキテクチャとしては単純にこのパターンだけでは難しい部分が出てくるでしょう。 +つまり、read-writeなプラグインアーキテクチャとしては単純にこのパターンだけでは難しい部分が出てくると思います。 > **NOTE** ESLint 2.0でautofixing、つまり書き換えの機能の導入が予定されています。 > これはルールからの書き換えのコマンドを`SourceCode`というオブジェクトに集約して、最後に実際の書き換えを行うという抽象レイヤーを設けています。 @@ -271,7 +269,7 @@ ESLintのように与えられたコードを読み取ってチェックする ## エコシステム -ESLintのルールは関数を公開したただのJavaScriptモジュールであるため、 +ESLintのルールはただのJavaScriptモジュールなので、 ルール自体を[npm](https://www.npmjs.com/ "npm")で公開することができます。 また、ESLintはデフォルトで有効なルールはありません。 diff --git a/ja/connect/README.md b/ja/connect/README.md index 8d4d75f..59fca32 100644 --- a/ja/connect/README.md +++ b/ja/connect/README.md @@ -2,10 +2,9 @@ > この文章は[Connect](https://github.com/senchalabs/connect "Connect") 3.4.0を元に書かれています。 -[Connect](https://github.com/senchalabs/connect "Connect")はNode.jsで動くHTTPサーバーフレームワークです。 -_middleware_という拡張する仕組みを持ち、Connectが持つ機能自体はとても少ないです。 +[Connect](https://github.com/senchalabs/connect "Connect")はNode.jsで動くHTTPサーバーフレームワークです。 _middleware_ という拡張する仕組みを持ち、Connectが持つ機能自体はとても少ないです。 -この章ではConnectの_middleware_の仕組みについて見て行きましょう。 +この章ではConnectの _middleware_ の仕組みについて見て行きましょう。 ## どう書ける? @@ -22,19 +21,19 @@ Echoサーバとは、送られてきたリクエストの内容をそのまま } ``` -`app.use(middleware)` という形で、_middleware_と呼ばれる関数には`request`や`response`といったオブジェクトが渡されます。 -この`request`や`response`を_middleware_で処理してログを取ったり、任意のレスポンスを返しことができるようになっています。 +`app.use(middleware)` という形で、 _middleware_ と呼ばれる関数には`request`や`response`といったオブジェクトが渡されます。 +この`request`や`response`を _middleware_ で処理してログを取ったり、任意のレスポンスを返しことができるようになっています。 Echoサーバでは `req.pipe(res);` という形でリクエストをそのままレスポンスとして流す事で実現されています。 ### middlewareをモジュールとして実装 -もう少し_middleware_をプラグインらしくモジュールとして実装したものを見てみます。 +もう少し _middleware_ をプラグインらしくモジュールとして実装したものを見てみます。 次の[connect-example.js](#connect-example.js)は、あらゆるリクエストに対して、 `"response text"`というレスポンスを`"X-Content-Type-Options"`ヘッダを付けて返すだけのサーバです。 -それぞれの処理を_middleware_としてファイルを分けて実装し、`app.use(middleware)`で処理を追加しています。 +それぞれの処理を _middleware_ としてファイルを分けて実装し、`app.use(middleware)`で処理を追加しています。 [import nosniff.js](../../src/connect/nosniff.js) @@ -45,46 +44,46 @@ Echoサーバでは `req.pipe(res);` という形でリクエストをそのま [import connect-example.js](../../src/connect/connect-example.js) -基本的にどの_middleware_も`app.use(middleware)`という形で拡張でき、 +基本的にどの _middleware_ も`app.use(middleware)`という形で拡張でき、 モジュールとして実装すれば再利用もしやすい形となっています。 -> **Note** _middleware_となる関数の引数が4つであると、それはエラーハンドリングの_middleware_とするという、Connect独自のルールがあります。 +> **Note** _middleware_ となる関数の引数が4つであると、それはエラーハンドリングの _middleware_ とするという、Connect独自のルールがあります。 ## どういう仕組み -Connectの_middleware_がどのような仕組みで動いているのかを見ていきます。 +Connectの _middleware_ がどのような仕組みで動いているのかを見ていきます。 -`app`に登録した_middleware_は、リクエスト時に呼び出されています。 -そのため、`app`のどこかに利用する_middleware_を保持していることは推測できると思います。 +`app`に登録した _middleware_ は、リクエスト時に呼び出されています。 +そのため、`app`のどこかに利用する _middleware_ を保持していることは推測できると思います。 -Connectでは`app.stack`に_middleware_を配列として保持しています。 -次のようにして`app.stack`の中身を表示してみると、_middleware_が登録順で保持されていることがわかります。 +Connectでは`app.stack`に _middleware_ を配列として保持しています。 +次のようにして`app.stack`の中身を表示してみると、 _middleware_ が登録順で保持されていることがわかります。 [import connect-trace-example.js](../../src/connect/connect-trace-example.js) -Connectは登録された_middleware_を、サーバがリクエストを受け取りそれぞれ順番に呼び出しています。 +Connectは登録された _middleware_ を、サーバがリクエストを受け取りそれぞれ順番に呼び出しています。 -上記の例だと以下の順番で_middleware_が呼び出されることになります。 +上記の例だと以下の順番で _middleware_ が呼び出されることになります。 - nosniff - hello - errorHandler -エラーハンドリングの_middleware_は処理中にエラーが起きた時のみ呼ばれます。 +エラーハンドリングの _middleware_ は処理中にエラーが起きた時のみ呼ばれます。 そのため、通常は [nosniff.js](#nosniff.js) → [hello.js](#hello.js) の順で呼び出されます。 [import nosniff.js](../../src/connect/nosniff.js) `nosniff.js`は、HTTPヘッダを設定し終わったら`next()`を呼び出し、 -この`next()`が次の_middleware_へ行くという意味になります。 +この`next()`が次の _middleware_ へ行くという意味になります。 次に、`hello.js`を見てみると、`next()`がありません。 [import hello.js](../../src/connect/hello.js) -`next()`がないということは`hello.js`がこの連続する_middleware_の最後となっていることがわかります。 -仮に、これより先に_middleware_が登録されていたとしても無視されます。 +`next()`がないということは`hello.js`がこの連続する _middleware_ の最後となっていることがわかります。 +仮に、これより先に _middleware_ が登録されていたとしても無視されます。 つまり、処理的には以下のようにstackを先頭から一個づつ取り出し、処理していくという方法が取られています。 @@ -102,10 +101,10 @@ next();// 初回 ``` -このような_middleware_を繋げたものを_middleware stack_と呼ぶことがあります。 +このような _middleware_ を繋げたものを_middleware stack_と呼ぶことがあります。 -_middleware stack_で構成されるHTTPサーバとして、PythonのWSGI MiddlewareやRubyのRackなどがあります。 -ConnectはRackと同じく`use`で_middleware_を指定することからも分かりますが、 +_middleware stack_ で構成されるHTTPサーバとして、PythonのWSGI MiddlewareやRubyのRackなどがあります。 +ConnectはRackと同じく`use`で _middleware_ を指定することからも分かりますが、 Rackを参考にした実装となっています。 - [Ruby - Rack解説 - Rackの構造とRack DSL - Qiita](http://qiita.com/higuma/items/838f4f58bc4a0645950a#2-5 "Ruby - Rack解説 - Rackの構造とRack DSL - Qiita") @@ -114,16 +113,16 @@ Rackを参考にした実装となっています。 ## 実装してみよう -Connectライクな_middleware_をサポートしたJunctionというクラスを作成してみます。 +Connectライクな _middleware_ をサポートしたJunctionというクラスを作成してみます。 Junctionは、`use(middleware)` と `process(value, (error, result) => { });`を持っているシンプルなクラスです。 [import junction.js](../../src/connect/junction.js) -実装を見てみると、`use`で_middleware_を登録して、`process`で登録した_middleware_を順番に実行していきます。 -そのため、`Junction`自体は渡されたデータの処理をせずに、_middleware_の中継のみをしています。 +実装を見てみると、`use`で _middleware_ を登録して、`process`で登録した _middleware_ を順番に実行していきます。 +そのため、`Junction`自体は渡されたデータの処理をせずに、 _middleware_ の中継のみをしています。 -登録する_middleware_はConnectと同じで、処理をしたら`next`を呼んで、次の_middleware_が処理するというのを繰り返しています。 +登録する _middleware_ はConnectと同じもので、処理をしたら`next`を呼んで、次の _middleware_ が処理するというのを繰り返しています。 使い方はConnectと引数の違いはありますが、ほぼ同じような形で利用できます。 @@ -132,11 +131,11 @@ Junctionは、`use(middleware)` と `process(value, (error, result) => { });`を ## どういう用途に向いている? -ConnectやJunctionの実装を見てみると分かりますが、このアーキテクチャでは機能の詳細を_middleware_で実装できます。 -そのため、本体の実装は_middleware_に提供するインタフェースの決定、エラーハンドリングの手段の提供するだけでとても小さいものとなっています。 +ConnectやJunctionの実装を見てみると分かりますが、このアーキテクチャでは機能の詳細を _middleware_ で実装できます。 +そのため、本体の実装は _middleware_ に提供するインタフェースの決定、エラーハンドリングの手段の提供するだけでとても小さいものとなっています。 今回は紹介していませんが、Connectにはルーティングに関する機能があります。 -しかし、この機能も「与えられたパスにマッチした場合のみに反応する_middleware_を登録する」という単純なものです。 +しかし、この機能も「与えられたパスにマッチした場合のみに反応する _middleware_ を登録する」という単純なものです。 ```js app.use("/foo", function fooMiddleware(req, res, next) { @@ -152,11 +151,10 @@ app.use("/foo", function fooMiddleware(req, res, next) { ## どういう用途に向いていない? -このアーキテクチャでは機能の詳細が_middleware_で実装できます。 -その中で多くの機能を_middleware_で実装していくと、_middleware_間に依存関係を作ってしまう事があります。 +このアーキテクチャでは機能の詳細が _middleware_ で実装できます。 +しかし、多くの機能を _middleware_ で実装していくと、 _middleware_ 間に依存関係を作ってしまう事があります。 -この場合、`use(middleware)` で登録する順番により挙動が変わります。 -_middleware_の利用者が、間で起きる前提の解決を行う必要があります。 +この場合、`use(middleware)` で登録する順番により挙動が変わります。 _middleware_ の利用者が、間で起きる前提の解決を行う必要があります。 そのため、プラグイン同士の強い独立性や明確な依存関係を扱いたい場合には不向きといえるでしょう。 @@ -164,14 +162,14 @@ _middleware_の利用者が、間で起きる前提の解決を行う必要が ## エコシステム -Connect自体の機能は少ないですが、その分_middleware_の種類が多くあります。 +Connect自体の機能は少ないですが、その分 _middleware_ の種類が多くあります。 - [github.com/senchalabs/connect#middleware](https://github.com/senchalabs/connect#middleware) - [Express middleware](http://expressjs.com/resources/middleware.html "Express middleware") -また、それぞれの_middleware_が小さな単機能であり、それを組み合わせて使うように作られているケースが多いです。 +また、それぞれの _middleware_ が小さな単機能となっていて、それを組み合わせて使うように作られているケースが多いです。 -これは、_middleware_が層として重なっている作り、つまり_middleware stack_の形を取ることが多いからであるとも言えます。 +これは、 _middleware_ が層として重なっている作り、つまり _middleware stack_ の形を取ることが多いだと言えます。 ![pylons_as_onion](img/pylons_as_onion.png) @@ -182,7 +180,7 @@ Connect自体の機能は少ないですが、その分_middleware_の種類が ## この仕組みを使っているもの - [Express](http://expressjs.com/ "Express") - - Connectと_middleware_の互換性がある + - Connectと _middleware_ の互換性がある - 元々はConnectを利用していたが[4.0.0](https://github.com/strongloop/express/blob/4.0.0/History.md "4.0.0")で自前の実装に変更 - [wooorm/retext](https://github.com/wooorm/retext "wooorm/retext") - `use`でプラグイン登録していくテキスト処理ライブラリ @@ -193,9 +191,9 @@ Connect自体の機能は少ないですが、その分_middleware_の種類が ここではConnectのプラグインアーキテクチャについて学びました。 -- Connectは_middleware_を使ったHTTPサーバーライブラリである +- Connectは _middleware_ を使ったHTTPサーバーライブラリである - Connect自体の機能は少ない -- 複数の_middleware_を組み合わせることでHTTPサーバを作ることができる +- 複数の _middleware_ を組み合わせることでHTTPサーバを作ることができる ## 参考資料 diff --git a/ja/gulp/README.md b/ja/gulp/README.md index ac00521..dc2ec86 100644 --- a/ja/gulp/README.md +++ b/ja/gulp/README.md @@ -50,7 +50,7 @@ gulp.task("sass", function() { 実際にgulpプラグインを書きながら、どのような仕組みで処理同士が連携を取り動作しているのかを見ていきましょう。 -先ほどのgulpタスクの例では、既にモジュール化された処理を`pipe`で繋げただけであるため、 +先ほどのgulpタスクの例では、既にモジュール化された処理を`pipe`で繋げただけで、 それぞれの処理がどのように実装されているかはよく分かりませんでした。 ここでは`gulp-prefixer`というgulpプラグインを書いていきます。 @@ -214,7 +214,7 @@ export function prefixStream(prefix) { やってきたBufferの先頭に`prefix`の文字列をBufferとして結合して返すだけの処理が行われています。 この変換処理自体は、gulpに依存したものではないため、通常のライブラリに渡して処理するということが可能です。 -BufferはStringと相互変換が可能であるため、多くのgulpプラグインと呼ばれるものは、`gulpPrefixer`と`prefixBuffer`にあたる部分だけを実装しています。 +BufferはStringと相互変換が可能なので、多くのgulpプラグインと呼ばれるものは、`gulpPrefixer`と`prefixBuffer`にあたる部分だけを実装しています。 つまり、prefixを付けるといった変換処理自体は、既存のライブラリで行うことができるようになっています。 @@ -226,17 +226,17 @@ gulpプラグインは[vinyl](https://github.com/gulpjs/vinyl "vinyl")オブジ gulpのプラグインが行う処理は「入力に対して出力を返す」が主となっています。 この受け渡すデータとして[vinyl](https://github.com/gulpjs/vinyl "vinyl")オブジェクトを使い、受け渡すAPIのインタフェースとしてNode.js Streamを使っています。 -gulpではプラグインが持つ機能は1つ(単機能)であること推奨しています。 +gulpではプラグインが持つ機能は1つ(単機能)とすることを推奨しています。 > Your plugin should only do one thing, and do it well. > -- [gulp/guidelines.md](https://github.com/gulpjs/gulp/blob/master/docs/writing-a-plugin/guidelines.md "gulp/guidelines.md at master · gulpjs/gulp") gulpは既存のNode.js Streamに乗ることで独自のAPIを使わずに解決しています。 -元々、Transform Streamは1つの変換処理を行うことが得意であり、その変換処理を`pipe`を繋げることで複数の処理を行う事できます。 +元々、Transform Streamは1つの変換処理を行うことが得意なので、その変換処理を`pipe`を繋げることで複数の処理を行う事できます。 -また、gulpはタスク自動化ツールであるため、既存のライブラリをそのままタスクとして使いやすくすることが重要だと言えます。 -Node.js Streamのデフォルトでは流れるデータが`Buffer`であるため、そのままでは既存のライブラリでは扱いにくい問題を +また、gulpはタスク自動化ツールなので、既存のライブラリをそのままタスクとして使いやすくすることが重要だと言えます。 +Node.js Streamのデフォルトでは流れるデータが`Buffer`となり、そのままでは既存のライブラリでは扱いにくい問題を データとして[vinyl](https://github.com/gulpjs/vinyl "vinyl")オブジェクトを流す事で緩和しています。 このようにして、gulpはタスクに必要な単機能のプラグインを既存のライブラリで作りやすくしています。 @@ -244,7 +244,7 @@ Node.js Streamのデフォルトでは流れるデータが`Buffer`であるた ## どういう用途に向いている? -gulp自体はデータの流れを管理するだけであり、タスクを実現するためにはプラグインが重要になります。 +gulp自体はデータの流れを管理するだけで、タスクを実現するためにはプラグインが重要になります。 タスクには様々な処理が想定されるため、必要になるプラグインも種類が様々なものとなります。 gulpでは[vinyl](https://github.com/gulpjs/vinyl "vinyl")オブジェクトを中間フォーマットと決めたことで、 diff --git a/ja/introduction/README.md b/ja/introduction/README.md index d105b31..2b1dad8 100644 --- a/ja/introduction/README.md +++ b/ja/introduction/README.md @@ -4,7 +4,7 @@ JavaScriptの世界では1つの大きなライブラリよりも小さいなものを組み合わせていくようなスタイルが多く見られます。 -小さものを組み合わせて使えるようなエコシステムの土台となるものを書こうとした際に、プラグインアーキテクチャの仕組みが重要となると言えます。 +小さものを組み合わせて使えるようなエコシステムの土台となるものを書こうとした際に、プラグインアーキテクチャの仕組みが重要です。 > ソフトウェアの構造に「プラグイン機構」を設け、ユーザコミュニティから開発者コミュニティへの質的な転換を図るのは、ソフトウェア設計からエコシステム設計へとつながる > -- [OSS開発の活発さの維持と良いソフトウェア設計の間には緊張関係があるのだろうか? - t-wadaのブログ](http://t-wada.hatenablog.jp/entry/active-oss-development-vs-simplicity "OSS開発の活発さの維持と良いソフトウェア設計の間には緊張関係があるのだろうか? - t-wadaのブログ") diff --git a/ja/jQuery/README.md b/ja/jQuery/README.md index 6bbde28..a75c8be 100644 --- a/ja/jQuery/README.md +++ b/ja/jQuery/README.md @@ -2,7 +2,7 @@ > この文章は[jQuery](http://jquery.com/ "jQuery") 2.1.4を元に書かれています。 -jQueryでは`$.fn`を拡張する事で、`$()`の返り値であるjQueryオブジェクトにメソッドを追加することが出来ます。 +jQueryでは`$.fn`を拡張する事で、`$()`の返り値となるjQueryオブジェクトにメソッドを追加することが出来ます。 次の`greenify`プラグインでは、`$(document.body).greenify();`というメソッド呼び出しが可能になります。 @@ -21,7 +21,7 @@ jQueryでは`$.fn`を拡張する事で、`$()`の返り値であるjQueryオブ jQueryプラグインはprototype拡張のように `$.fn.greenify = function (){}` と拡張するルールでした。 -`jQuery.fn`の実装を見てみると、実態は`jQuery.prototype`であるため実際にprototype拡張していることがわかります。 +`jQuery.fn`の実装を見てみると、実態は`jQuery.prototype`なので、prototype拡張していることがわかります。 ```js // https://github.com/jquery/jquery/blob/2.1.4/src/core.js#L39 @@ -43,7 +43,7 @@ $(document.body); // 返り値はjQueryのインスタンス jQueryプラグインの仕組みがわかったのでどういう用途に有効な仕組みなのか考えてみましょう。 -単純なprototype拡張であると言えるので、利点はJavaScriptのprototypeと同様です。 +単純なprototype拡張なので、利点はJavaScriptのprototypeと同様です。 動的にメソッドを追加するだけではなく、既存の実装を上書きするmonkey patchのようなものもプラグインとして追加することができます。 ## どういう用途に向いていない? @@ -105,7 +105,7 @@ calculator.fn = calculator.prototype; ``` -まだNode.jsで使われているCommonJSやES6 Modulesといったものがなかった時代に作られた仕組みであるため、 +まだNode.jsで使われているCommonJSやES6 Modulesなどがなかった時代に作られた仕組みなので、 それらと組み合わせる際には少し不向きな拡張の仕組みといえるかもしれません。 ## まとめ diff --git a/package.json b/package.json index 5ff2194..42fae0d 100644 --- a/package.json +++ b/package.json @@ -71,7 +71,7 @@ "textlint-rule-no-doubled-conjunctive-particle-ga": "^1.0.2", "textlint-rule-no-doubled-joshi": "^3.2.0", "textlint-rule-no-dropping-the-ra": "^1.0.2", - "textlint-rule-no-mix-dearu-desumasu": "^1.1.0", + "textlint-rule-no-mix-dearu-desumasu": "^2.2.1", "textlint-rule-no-nfd": "^1.0.1", "textlint-rule-no-start-duplicated-conjunction": "^1.0.7", "textlint-rule-preset-jtf-style": "^2.0.0", From 1e6a523c566e70395ac0cf0743d4afe4da8f309f Mon Sep 17 00:00:00 2001 From: azu Date: Fri, 6 May 2016 10:56:12 +0900 Subject: [PATCH 2/4] =?UTF-8?q?chore(coverage):=20coverage=E3=81=AE?= =?UTF-8?q?=E3=83=AB=E3=83=BC=E3=83=AB=E3=82=82=E6=9B=B4=E6=96=B0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- coverage.textlintrc | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/coverage.textlintrc b/coverage.textlintrc index 9bf5fb8..31ad600 100644 --- a/coverage.textlintrc +++ b/coverage.textlintrc @@ -6,6 +6,9 @@ "strict": true }, "unexpanded-acronym": true, + "no-nfd": true, + "no-doubled-conjunctive-particle-ga": true, + "no-doubled-conjunction": true, "no-double-negative-ja": true, "no-doubled-joshi": { "min_interval": 1, @@ -18,7 +21,11 @@ "interval": 3 }, "spellcheck-tech-word": true, - "no-mix-dearu-desumasu": true, + "no-mix-dearu-desumasu": { + "preferInHeader": "", + "preferInBody": "ですます", + "preferInList": "である" + }, "prh": { "rulePaths": [ "test/prh.yml" From 57dcaaa16a9e4c14b5d735e063a9cf73b382e5c9 Mon Sep 17 00:00:00 2001 From: azu Date: Fri, 6 May 2016 11:10:45 +0900 Subject: [PATCH 3/4] =?UTF-8?q?chore(docs):=20=E6=94=B9=E8=A1=8C=E3=82=92?= =?UTF-8?q?=E8=BF=BD=E5=8A=A0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ja/ESLint/README.md | 3 ++- ja/connect/README.md | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/ja/ESLint/README.md b/ja/ESLint/README.md index 3e7a7b4..d111db2 100644 --- a/ja/ESLint/README.md +++ b/ja/ESLint/README.md @@ -98,7 +98,8 @@ ESLintではこのASTを使って、[no-console.js](#no-console.js)のように` } ``` -[no-console.js](#no-console.js)のルールを見ると`MemberExpression` typeのNodeが `node.object.name === "console"` となった場合に、`console`が残ってると判断してエラーレポートすると読めてくると思います。 +[no-console.js](#no-console.js)のルールを見ると`MemberExpression` typeのNodeが `node.object.name === "console"` となった場合に、 +`console`が残ってると判断してエラーレポートすると読めてくると思います。 ASTの探索がイメージしにくい場合は以下のルールで探索の動作を見てみると分かりやすいかもしれません。 diff --git a/ja/connect/README.md b/ja/connect/README.md index 59fca32..93f4b69 100644 --- a/ja/connect/README.md +++ b/ja/connect/README.md @@ -2,7 +2,8 @@ > この文章は[Connect](https://github.com/senchalabs/connect "Connect") 3.4.0を元に書かれています。 -[Connect](https://github.com/senchalabs/connect "Connect")はNode.jsで動くHTTPサーバーフレームワークです。 _middleware_ という拡張する仕組みを持ち、Connectが持つ機能自体はとても少ないです。 +[Connect](https://github.com/senchalabs/connect "Connect")はNode.jsで動くHTTPサーバーフレームワークです。 + _middleware_ という拡張する仕組みを持ち、Connectが持つ機能自体はとても少ないです。 この章ではConnectの _middleware_ の仕組みについて見て行きましょう。 From 5a26a5baca37730065c924cedc811481d689d9fe Mon Sep 17 00:00:00 2001 From: azu Date: Fri, 6 May 2016 11:23:31 +0900 Subject: [PATCH 4/4] =?UTF-8?q?chore:=20=E6=94=B9=E8=A1=8C=E3=81=AE?= =?UTF-8?q?=E8=BF=BD=E5=8A=A0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ja/connect/README.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ja/connect/README.md b/ja/connect/README.md index 93f4b69..57173a8 100644 --- a/ja/connect/README.md +++ b/ja/connect/README.md @@ -155,7 +155,8 @@ app.use("/foo", function fooMiddleware(req, res, next) { このアーキテクチャでは機能の詳細が _middleware_ で実装できます。 しかし、多くの機能を _middleware_ で実装していくと、 _middleware_ 間に依存関係を作ってしまう事があります。 -この場合、`use(middleware)` で登録する順番により挙動が変わります。 _middleware_ の利用者が、間で起きる前提の解決を行う必要があります。 +この場合、`use(middleware)` で登録する順番により挙動が変わります。 +_middleware_ の利用者が、間で起きる前提の解決を行う必要があります。 そのため、プラグイン同士の強い独立性や明確な依存関係を扱いたい場合には不向きといえるでしょう。