From 99285e6ff43af4ed95da52b917ea9c080a9aa5a4 Mon Sep 17 00:00:00 2001 From: KUWASHIMA Yuichiro Date: Mon, 4 Sep 2017 19:43:03 +0900 Subject: [PATCH] Fix typos (#94) --- README-ja.md | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/README-ja.md b/README-ja.md index 5ebe309..57ac047 100644 --- a/README-ja.md +++ b/README-ja.md @@ -36,7 +36,7 @@ ### 1.1 Gitのルール -いくつかのGitのルールを覚えて起きましょう +いくつかのGitのルールを覚えておきましょう * featureブランチで作業しましょう _Why:_ @@ -54,9 +54,9 @@ * featureブランチをPushしてプルリクエストを作成する前にローカルの`develop` ブランチを最新にして、featureブランチをインタラクティブrebaseしましょう。 _Why:_ - >リベースはブランチ（`master`か`develop`か`）をマージします。またlocalに作ったコミットtをマージコミットを作成せずにGitのヒストリーのトップに並べ替えます。コンフリクトがなければ。そうすることで綺麗で素晴らしいヒストリーが残ります。[もっと読む](https://www.atlassian.com/git/tutorials/merging-vs-rebasing) + >リベースはブランチ（`master`か`develop`か`）をマージします。またlocalに作ったコミットをマージコミットを作成せずにGitのヒストリーのトップに並べ替えます。コンフリクトがなければ。そうすることで綺麗で素晴らしいヒストリーが残ります。[もっと読む](https://www.atlassian.com/git/tutorials/merging-vs-rebasing) -* リベースする間やプルリクエストを作る前にコンプリクトを解消しましょう +* リベースする間やプルリクエストを作る前にコンフリクトを解消しましょう * マージした後のブランチはlocal, remote共に削除しましょう _Why:_ @@ -187,7 +187,7 @@ ![開発環境](/images/laptop.png) -* 必要なら`development`, `tesst` と`production`の環境を分けて定義しましょう。 +* 必要なら`development`, `test` と`production`の環境を分けて定義しましょう。 _Why:_ > データやトークンやAPI、ポートなど環境によって必要とされるものは様々です。。。テストの自動化と手動のテストを簡単にさせるために、`development`モードは予測可能なデータを返すフェイクのAPIが欲しいかもしれません。もしくはGoogle Analyticsは`production`でだけ有効にしたかったり様々でしょう。[もっと読む](https://stackoverflow.com/questions/8332333/node-js-setting-up-environment-specific-configs-to-be-used-with-everyauth) @@ -241,7 +241,7 @@ * チームメンバーが同じ依存関係を取得できることを確認しましょう。 _Why:_ - > コードにはどんな開発マシンで同じ挙動をしてほしいからです。[もっと読む](https://medium.com/@kentcdodds/why-semver-ranges-are-literally-the-worst-817cdcb09277) +    > コードにはどんな開発マシンでも同じ挙動をしてほしいからです。[もっと読む](https://medium.com/@kentcdodds/why-semver-ranges-are-literally-the-worst-817cdcb09277) _how:_ > `npm@5`以上で`package-lock.json`を使いましょう。 @@ -261,7 +261,7 @@ * 無関係であったり使っていないパッケージを確認しましょう: `depcheck`. [もっと読む...](https://www.npmjs.com/package/depcheck) _Why:_ - > もしかしたら使っていないライブラリーがproductioのサイズを増加させているかもしれません。使っていない依存関係を見つけてそれを消すようにしましょう。 + > もしかしたら使っていないライブラリーがproductionのサイズを増加させているかもしれません。使っていない依存関係を見つけてそれを消すようにしましょう。 * ライブラリをインストールする前に、そのライブラリがコミュニティでよく使われているかどうかを確認しましょう。`npm-stat`。[もっと読む...](https://npm-stat.com/) @@ -290,7 +290,7 @@ _Why:_ > 通常はend to endのテストを`production`に行うだけで十分なですが、例外がいくつかあります。統計データを`production`環境で有効にしたくなく、テストデータでダッシュボードを汚したくない場合です。あとは`production`のAPIに制限があって、テストをする際のリクエスト数が制限に達してブロックされてしまう場合です。 -* 単体テストコードはテストされるファイルの隣におきましょう。 `moduleName.spec.js`のように`*.test.js` や `*.spec.js` のようなファイル名が慣例kkkkkkkkkとなっています。 +* 単体テストコードはテストされるファイルの隣におきましょう。 `moduleName.spec.js`のように`*.test.js` や `*.spec.js` のようなファイル名が慣例となっています。 _Why:_ > ユニットテストを探すためにフォルダ構造を掘り進めたくないでしょう。[もっと読む...](https://hackernoon.com/structure-your-javascript-code-for-testability-9bc93d9c72dc) @@ -481,7 +481,7 @@ * クライアントサイドのconsole ログをプロダクション環境で出力するのは避けましょう。 _Why:_ - > ビルどプロセスを通してConsoleログを取り覗くことができます(すべきです)が、コードスタイルチェックが吐き出すconsole logについてのwarningの情報を確認しましょう。 +    > ビルドプロセスを通してConsoleログを取り除くことができます(すべきです)が、コードスタイルチェックが吐き出すconsole logについてのwarningの情報を確認しましょう。 * プロダクションのログは読みやすいように出力しましょう。理想的にはプロダクションモードで使われているロギングライブラリを使いましょう([winston](https://github.com/winstonjs/winston) もしくは [node-bunyan](https://github.com/trentm/node-bunyan)のようなものがあります。) @@ -499,7 +499,7 @@ ### 9.1 APIデザイン _Why:_ -> 私たちは明快に構築されたRESTfulのインターフフェースでの開発を強制することで、チームメンバーやクライアントがシンプルに矛盾なくそれを使えることができます。 +> 私たちは明快に構築されたRESTfulのインターフェースでの開発を強制することで、チームメンバーやクライアントがシンプルに矛盾なくそれを使えることができます。 _Why:_ > 一貫性やシンプルさがないAPIはシステムの結合やメンテナンスのコストを増加させます。だから`API design`をこのドキュメントに含めて説明しています。 @@ -514,7 +514,7 @@ _Why:_ > 上記のことは開発者(あなたのAPIを使う人たち)に周知されていることです。可読性や使いやすさを別にして、REST APIではそのAPIの詳細を知らずとも汎用なライブラリやコネクターを書くができます。 * URLにはkebab-caseを使いましょう。 -* クエリストリングないのパラメータやリソース内のパラメータにはcamelCaseを使いましょう。 +* リクエスト内のパラメータやリソース内のパラメータにはcamelCaseを使いましょう。 * URL内のリソース名は複数形のkebab-caseにしましょう * コレクションを表すurlには常に複数形の名詞を使いましょう。`/users` @@ -560,7 +560,7 @@ _Why:_ _Why:_ > このドキュメントはJavaScriptプロジェクトのガイドラインであるため、JSONの読み書きにはJavaScriptが使用されてることを想定しています。
 -* リソースオプジェクトインスタンスやDBのレコードと同じような単一なものであったとしても、`table_name`や`column_name`はリソース名やプロパティ名にしないようにしましょう。 +* リソースオブジェクトインスタンスやDBのレコードと同じような単一なものであったとしても、`table_name`や`column_name`はリソース名やプロパティ名にしないようにしましょう。 _Why:_ > あくまでリソースを公開するのであってDBのスキーマの詳細を公開するためのものではないからです。 @@ -584,7 +584,7 @@ _Why:_ > `DELETE`: 存在するリソースの削除。 -* ネスとしているリソースのために関連するURL間にリレーションを使用しましょう。例えば会社の従業員を関連されるために、idを使用したりします。 +* ネストしているリソースのために関連するURL間にリレーションを使用しましょう。例えば会社の従業員を関連されるために、idを使用したりします。 _Why:_ > 各リソースを探索しやすくするための自然なやり方です。 @@ -653,11 +653,11 @@ _Why:_ > `201 Created` 新しいインスタンスが作成された時に返却されます。新しいインスタンスの作成、`POST`メソッドの使用は`201`のステータスコードを返します。 - > `304 Not Modified` レスポンスをはユーザーがすでにキャッシュを持っている場合に返却されます、最小の転送に抑えることになります。 +    > `304 Not Modified` ユーザーがすでにレスポンスのキャッシュを持っている場合に返却されます、最小の転送に抑えることになります。 > `400 Bad Request` リクエストが処理されなかった場合に返却されます。サーバーがクライアントの要求するリクエストを理解できなかったような時です。 - > `401 Unauthorized` リクエストの認証情報が不足している時に返却されます。要求された認証情報で再リクエストするを行うことになるでしょう。 + > `401 Unauthorized` リクエストの認証情報が不足している時に返却されます。要求された認証情報で再リクエストを行うことになるでしょう。 > `403 Forbidden` サーバーはリクエストを解釈できていますが、認証を拒否したという意味です。 @@ -672,7 +672,7 @@ _Why:_ * レスポンスにはリソースの数の合計を提供しましょう。 * `limit`と`offset`のパラメータを受けつけましょう。 -* リソースの後悔するデータ量はよく考える必要があります。APIの利用者は常にリソースの全ての表現が必要というわけではありません。フィールドのカンマ区切りリストを含むフィールドクエリパラメータを使用します。 +* リソースの公開するデータ量はよく考える必要があります。APIの利用者は常にリソースの全ての表現が必要というわけではありません。フィールドのカンマ区切りリストを含むフィールドクエリパラメータを使用します。 ``` GET /student?fields=id,name,age,class ``` @@ -707,12 +707,12 @@ _Why:_ * JSONをシリアライズしましょう。 _Why:_ - > JSONエンコーダの悩みの種は、ブラウザ内でリモートからの任意のJavaScriptの実行を防ぐことです。もしくはnode.jsを使用しているのであれば、サーバーサイドも同様です。ユーザーから与えられた入力がブライザ内で実行されないように、ユーザーからの情報をエンコードできる適切なJSONシリアライザーを使用することが重要です。 +    > JSONエンコーダの悩みの種は、ブラウザ内でリモートからの任意のJavaScriptの実行を防ぐことです。もしくはnode.jsを使用しているのであれば、サーバーサイドも同様です。ユーザーから与えられた入力がブラウザ内で実行されないように、ユーザーからの情報をエンコードできる適切なJSONシリアライザーを使用することが重要です。 * Content-TypeをValidateするようにしましょう。多くの場合で `application/*json` (Content-Typeヘッダ)を使いましょう。 _Why:_ - > 例えば、`application/x-www-form-urlencoded`のmine-typeを受け入れることは、攻撃者にフォームを作成させ、シンプルなPOSTリクエストを誘引させることを許すことになります。サーバは受け入れるContent-Typeを決して推定させないべきです。Content-Typeヘッダもしくは予期しないContent-Typeヘッダに対しては`4XX`のレスポンスでリクエストを拒否する結果を返却しましょう。 + > 例えば、`application/x-www-form-urlencoded`のmime-typeを受け入れることは、攻撃者にフォームを作成させ、シンプルなPOSTリクエストを誘引させることを許すことになります。サーバは受け入れるContent-Typeを決して推定させないべきです。Content-Typeヘッダもしくは予期しないContent-Typeヘッダに対しては`4XX`のレスポンスでリクエストを拒否する結果を返却しましょう。 * APIのセキュリティをチェックリストを見て確認しましょう。[もっと読む](https://github.com/shieldfy/API-Security-Checklist)