style: fix by textlint

.github/workflows/reviewdog.yaml

@@ -0,0 +1,32 @@
+---
+name: reviewdog
+
+on:
+  pull_request:
+
+jobs:
+  textlint:
+    name: runner / textlint
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+        with:
+          submodules: true
+
+      - name: Setup node/npm
+        uses: actions/setup-node@v4
+
+      - name: textlint-github-pr-check
+        uses: tsuyoshicho/action-textlint@v3
+        with:
+          github_token: ${{ secrets.github_token }}
+          reporter: github-pr-check
+          textlint_flags: "doc/**"
+
+      - name: textlint-github-pr-review
+        uses: tsuyoshicho/action-textlint@v3
+        with:
+          github_token: ${{ secrets.github_token }}
+          reporter: github-pr-review
+          textlint_flags: "doc/**"

.textlintrc.json

@@ -17,7 +17,9 @@
          "allow": ["か"]
       }
     },
-    "preset-jtf-style": true,
+    "preset-jtf-style": {
+      "3.1.1.全角文字と半角文字の間": false
+    },
     "preset-ja-spacing": {
       "ja-space-between-half-and-full-width": {
         "space": "always",

Makefile

@@ -0,0 +1,2 @@
+lint:
+	npx textlint --fix . || true

ansible/ansible-inventory-command.md

@@ -2,7 +2,7 @@
 
 inventory file の情報をいい感じに整形して出力してくれるコマンド
 通常の `ansible-*` と同様に `-i` で inventory file 指定や、 `-l` で limit 指定が可能
-inventory が 従来の ini 形式ではなく yaml inventory だったら `-y` をつける。outputも yaml になる
+inventory が従来の ini 形式ではなく yaml inventory だったら `-y` をつける。output も yaml になる
 
 
 [enginyoyen/ansible-best-practises](https://github.com/enginyoyen/ansible-best-practises) を使って試す

ansible/file-module-atomic-mv.md

@@ -4,7 +4,7 @@
 ansible の file module での file 操作は atomic な置き換えである :tada:
 
 ## 経緯
-symlink を `ln -sf` すると `rm` + `ln` になるので神のタイミング(rm から ln するまでの間)でpath を参照されると見えなくなる場合がある  
+symlink を `ln -sf` すると `rm` + `ln` になるので神のタイミング（rm から ln するまでの間）で path を参照されると見えなくなる場合がある  
 そのため safe な置き換えのためには、隣に new を作成し `mv -T new old` で atomic に置き換える必要がある  
 ansible の file module の `state: symlink` は `ln -sf new old` をしているのか new を作って `mv -T` 相当をしているのか不明だったので調査  
 

ci/drone_uses_buildkit.md

@@ -5,7 +5,7 @@ drone の中で docker image を build する plugin/docker でちょっと前
 https://github.com/drone-plugins/drone-docker/pull/227
 
 
-雰囲気で .drone.yml を編集してあげると(environment が必要かはわからない)
+雰囲気で .drone.yml を編集してあげると（environment が必要かはわからない）
 
 ```diff
 -   image: plugins/docker

cncf/cloud_native_meetup_tokyo_4.md

@@ -23,7 +23,7 @@ Cloud Native Meetup Tokyo #4
     - performance, L4/L8 network proxy, pluggable filter chain model
     - master is always RC
         - Lyft とか couple は weekly くらいでデプロイされているらしい
-    - Envoy のtaggingはあまり気にしなくていいよ
+    - Envoy の tagging はあまり気にしなくていいよ
     - Place to watch
         - `DEPLICATED.md`
         - What happend
@@ -36,26 +36,26 @@ Cloud Native Meetup Tokyo #4
     - xDS
         - LDS Listener Discovery Service
             - 通信を listen したいやつ
-            - 1インスタンスが 1サーバ
+            - 1 インスタンスが 1 サーバ
         - RDS Route Discovery Service
             - HTTP, HTTPS gRPC だけ
             - RDS 毎に異なるサーバから持ってこれる
         - CDS Cluster Discovery Service
             - Cluster の後ろにいるのを探す
-            - 1インスタンスが 1サーバ
+            - 1 インスタンスが 1 サーバ
         - EDS Endopint
             - それぞれの endopoint を envoy に配布するやつ
         - SDS Secret
             - 暗号化通信をするときに秘密鍵と証明書を配布する
-            - 別のルートから 鍵と証明書を配布するしくみ
-            - ingress controller の証明書更新されるとIstio が hot restart していたけど、それが再起動無しで適用できるようになる
+            - 別のルートから鍵と証明書を配布するしくみ
+            - ingress controller の証明書更新されると Istio が hot restart していたけど、それが再起動無しで適用できるようになる
         - HDS Health
             - envoy 同士で health check する
             - envoy 数 * endpoint でめっちゃ増えるのが問題
             - HDS で envoy が見る Endpoint を分けて、HDS で aggregate する
         - Aggregated ADS
             - 複数の xDS をまとめて一貫性をもたせる
-        - UDS Unix Domain Socket(discovery service じゃない)
+        - UDS Unix Domain Socket(discovery service じゃない）
     - 今後
         - L7 プロトコルサポート
         - scalability from improved xDS
@@ -95,7 +95,7 @@ Cloud Native Meetup Tokyo #4
 - UseCase
     - Web-Service: 人事の給与サービス
         - 自分は自分の給与が見れる
-        - manager は 自分と member が見れる
+        - manager は自分と member が見れる
         - 人事は全部見れる
     - Docker
         - docker の authorization plugin として opa を指定できる

cncf/cloud_native_meetup_tokyo_7.md

@@ -36,7 +36,7 @@ https://www.telepresence.io/
     - Service Configration
         - KVS, transaction, watch
 - ペパボ consul 使ってる
-    - k8s 移行してるが, いい感じに既存 consul と連携したい
+    - k8s 移行してるが、 いい感じに既存 consul と連携したい
 - Consul Connect
     - 通信の許可/禁止
     - sidecar proxy
@@ -45,14 +45,14 @@ https://www.telepresence.io/
             - https://www.consul.io/intro/vs/proxies.html
     - CA もいい感じに管理してくれる
     - アプリケーション自身に proxy を組み込める
-    - 簡単に service-to-service の暗号化,制御ができる
+    - 簡単に service-to-service の暗号化、制御ができる
 - consul kubernetes integration
-    - consul cluster は k8s 跨いで クラスタを作れる
+    - consul cluster は k8s 跨いでクラスタを作れる
     - daemonset として consul client をデプロイすると、k8s node がそれぞれ Consul member となる
-    - helm を使うと pod IPになって node IP じゃないので注意
+    - helm を使うと pod IP になって node IP じゃないので注意
     - 既存インフラに Consul cluster があるとよさそう
     - k8s <-> Consul で同期ができる
-- istio + Envoy じゃなくて consul connect でいける?
+- istio + Envoy じゃなくて consul connect でいける？
 
 ## 分散イメージレジストリの検討 〜Beiran & Dragonfly〜 @yupeji @furkanmustafa
 - Docker pull 遅すぎ問題
@@ -73,6 +73,6 @@ https://www.telepresence.io/
 	- P2P based image registry
 - Beiran
 	- https://gitlab.beiran.io/beiran/beiran
-		- クリエーションラインだから GitLabなのか
+		- クリエーションラインだから GitLab なのか
 	- 隣の人が image 持ってたらそれを引っ張れる
 

confluence/sum_in_table_row.md

@@ -32,7 +32,7 @@ AJS.toInit(function ($) {
 </script>
 ```
 
-confluence table で合計を出したい列を見出し行(`th`) にして、`#sum` にする
+confluence table で合計を出したい列を見出し行（`th`) にして、`#sum` にする
 
 ## 参考
 

database/how_to_use_sql_calls_to_secure_your_web_site.md

@@ -3,7 +3,7 @@
 
 # 静的プレースホルダ
 
-JIS/ISO では "準備された文(Prepared Statement)" と定義される。
+JIS/ISO では "準備された文（Prepared Statement)" と定義される。
 DB 側にプレースホルダのまま文を送り、実行時に SQL パラメータを DB に送信し、DB 側がバインド処理する。
 SQL の準備段階で SQL 構文が確定するため後から SQL 文が変化することがないため安全である。
 

datadog/openmetrics.md

@@ -8,7 +8,7 @@ Pod が OpenMetrics(Prometheus) 形式で metrics export してくれている
 
 ## 基本的な書き方
 https://docs.datadoghq.com/ja/agent/kubernetes/prometheus/
-pod annotation に`ad.datadoghq.com/<CONTAINER NAME>.*` を基本として埋める
+pod annotation に `ad.datadoghq.com/<CONTAINER NAME>.*` を基本として埋める
 実際には deployment とか StateFullSets とかの `spec.template.metadata.annotations` に書くことになると思う
 
 ```yaml
@@ -27,7 +27,7 @@ pod annotation に`ad.datadoghq.com/<CONTAINER NAME>.*` を基本として埋め
             ]            
 ```
 ここの `CONTAINER_IDENTIFIER` は `spec.template.spec.containers.name` と一致させる必要がある
-`check_names` は DD integration の名前なので `openmetrics` 固定(ほかに integration 入れるなら足す 
+`check_names` は DD integration の名前なので `openmetrics` 固定（ほかに integration 入れるなら足す 
 ```yaml
         ad.datadoghq.com/<CONTAINER_IDENTIFIER>.check_names: |
                         ["openmetrics"]
@@ -78,8 +78,8 @@ metrics mutation したい場合は mapping を書く
 
 ## Advanced
 
-また、OpenMetrics 側で、例えば `hoo{name="hoge"}` みたいな metrics を投げていて、DD agent がつける `name` (ここでは EC2 の instance name の `name`) と conflict するような場合、`labels_mapper` で label 側を 張り替えれる。
-2つ tag (label) がついていると、sum() とか rollup とかがうまく動かないので極力 ばらしたほうが良い。
+また、OpenMetrics 側で、例えば `hoo{name="hoge"}` みたいな metrics を投げていて、DD agent がつける `name` (ここでは EC2 の instance name の `name`) と conflict するような場合、`labels_mapper` で label 側を張り替えれる。
+2 つ tag (label) がついていると、sum() とか rollup とかがうまく動かないので極力ばらしたほうが良い。
 
 例えば `hoge{name="bar"}` の metrics を吐いていた場合以下のような config は DD 上では
 `foo.hoge{app_name="bar}` として投げられる。

docker/alpine_apk_add.md

@@ -9,7 +9,7 @@ RUN apk update && apk upgrade && apk add nginx && rm /var/cache/*
 
 みたいな Dockerfile を書いていたが、https://github.com/hadolint/hadolint/wiki/DL3017 を見ると、
 
-`apk upgrade` は 本質的ではないパッケージが多数アップグレードされるので非推奨
+`apk upgrade` は本質的ではないパッケージが多数アップグレードされるので非推奨
 
 
 また、https://github.com/hadolint/hadolint/wiki/DL3019 では

docker/buildkit_cache.md

@@ -7,11 +7,11 @@ apt add とか apk instal とか bundle install とか npm install とか go mod
 
 `DOCKER_BUILDKIT=1` を入れると、各 stage 毎はキャッシュが効くが、1 stage で COPY 後に RUN とかすると、RUN の以前の cache は使われない。
 
-そこで、`--mount-type=cache,targer=/PATH/TO/CACHEDIR` を入れると、1つの RUN に対して cache が作られ、2回目以降の build でその cache が mount される。
+そこで、`--mount-type=cache,targer=/PATH/TO/CACHEDIR` を入れると、1 つの RUN に対して cache が作られ、2 回目以降の build でその cache が mount される。
 
 ---
 ## 使い方
-1行目に呪文を入れる
+1 行目に呪文を入れる
 
 cache したい RUN で、頭に `--mount=type=cache,target=/app/node_modules` (node の npm install なので WORKDIR/node_modules) を入れる
 

docker/buildkit_cache_tips.md

@@ -2,9 +2,9 @@ BuildKit `--mount-type=cache` の Tips
 =====
 
 # COPY `--from` 問題
-Multi Stage Build で`target=/hoge` の path の先を COPY  で引っ張ろうとすると虚無なので注意が必要
+Multi Stage Build で `target=/hoge` の path の先を COPY  で引っ張ろうとすると虚無なので注意が必要
 
-つまり 成果物は cache できない
+つまり成果物は cache できない
 
 
 

docker/buildkit_dns.md

@@ -3,7 +3,7 @@ BuildKit は `--dns` オプションを読まない
 
 https://github.com/moby/buildkit/issues/734
 
-普通の docker run は読む(buildkitじゃないので)
+普通の docker run は読む（buildkit じゃないので）
 
 ```
 ➜ docker run --privileged -e DOCKER_BUILDKIT=1 -d docker:dind --storage-driver=overlay --dns 8.8.8.8

docker/container-structure-test.md

@@ -28,11 +28,11 @@ commandTests:
     expectedOutput: ["Version:.*"]
 ```
 
-- `commandTests`: コマンドを実行して期待する出力, エラー出力で判断
+- `commandTests`: コマンドを実行して期待する出力、 エラー出力で判断
 - `fileExistenceTests` 指定したファイルパスに指定した uid, gid などで配置されているか
 - `fileContentTests` 指定したファイルの中身のテスト
 - `metadataTest`: Docker image のテスト
-  - label がついているか, expose port がただし以下, CMD, WORKDIR がただしいか
+  - label がついているか、 expose port がただし以下、 CMD, WORKDIR がただしいか
 - `globalEnvVars`: 指定した環境変数があるか
 
 

docker/docker-meetup-tokyo-26.md

@@ -25,7 +25,7 @@ https://speakerdeck.com/superbrothers/kubecon-plus-cloudnativecon-china-2018-rec
 - Kubecon Recap
     - CNCF サーベイ
         - 58% の企業が kubernetes を本番利用
-        - そのうち 40% が 5000人移譲の会社
+        - そのうち 40% が 5000 人移譲の会社
     - kubernetes is boring
     - Harbor
         - cloud native registory
@@ -70,16 +70,16 @@ https://speakerdeck.com/superbrothers/kubecon-plus-cloudnativecon-china-2018-rec
     - OCI
     - runc
         - OCI のリファレンス的実装
-        - Linux のリソース分離, セキュリティ機能をフル活用
+        - Linux のリソース分離、 セキュリティ機能をフル活用
         - rootless もある
     - runsc(gVisor)
         - syscall を sentry というプロセスを挟んでハンドルする
-        - 限定的なシステムコールを発行, 50種程度
+        - 限定的なシステムコールを発行、 50 種程度
         - 各アプリケーションは Go routeine として動作
         - スケジューリングも Go のランタイムがやる
     - runnc(Nabla Containers)
         - コンテナランタイム上で unikernel を実行する
-        - systemcall が コンテナランタイムで裁く
+        - systemcall がコンテナランタイムで裁く
         - 突き抜けるのも 7 種類しかない
         - unikernel ベースの image が実行可能
     - kata-runtime(Kata Containers)
@@ -126,7 +126,7 @@ https://speakerdeck.com/superbrothers/kubecon-plus-cloudnativecon-china-2018-rec
 - https://speakerdeck.com/orisano/multi-stage-builds-patterns-and-practice
 - build 中に test を通す
 - base image に alias を貼る
-- 重い処理を 分けて cache を効かせる
+- 重い処理を分けて cache を効かせる
 - CI に Multistage Build はつらい
 
 ## LT: 中国AlibabaのManaged Containerのあれこれ @mosuke5

docker/docker-meetup-tokyo20.md

@@ -3,11 +3,11 @@
 
 ## nvidia-docker 2.0について，大嶋悠司，NTT
 
-k8s で gpu cluster 管理したい!
+k8s で gpu cluster 管理したい！
 
 https://www.slideshare.net/Oshima0x3fd/kubernetesgpu
 
-- nvidia-docker2, nvidia-container-runtimeを使う
+- nvidia-docker2, nvidia-container-runtime を使う
 	- OCI runtime spec 準拠の container runtime
 - k8s -> docker -> containerd -> nv-runtime
 	- resources に指定してあげれば k8s でのスケジューリングができる

docker/dockerize.md

@@ -1,7 +1,7 @@
 Dockerize で依存コンテナを待つ
 ===
 
-[dockerize](https://github.com/jwilder/dockerize) を使うと、他のコンテナのポートが listen するまでコマンド(CMD)を叩かない、ということが簡単に実現できる
+[dockerize](https://github.com/jwilder/dockerize) を使うと、他のコンテナのポートが listen するまでコマンド（CMD)を叩かない、ということが簡単に実現できる
 
 Dockerfile
 ```Dockerfile

docker/image_diet_with_multistage_build.md

@@ -1,9 +1,9 @@
 スリムな Rails image を Docker Multi Stage Build で作る
 =====
 
-Rails 5.1 + webpack, Ruby 2.5.1 な imageを作る
+Rails 5.1 + webpack, Ruby 2.5.1 な image を作る
 
-bundle と asset pipeline & webpack 用の builder image と その成果物を COPY --from=builder で必要な部分だけ抜き、小さめな 実行用 imageを multi stage build で作る
+bundle と asset pipeline & webpack 用の builder image とその成果物を COPY --from=builder で必要な部分だけ抜き、小さめな実行用 image を multi stage build で作る
 
 - bundle install の成果物は /usr/local/bundle
 - nodoe_modules は precompile にしか使わないので  /public/asseert だけ引き抜く

elasticsearch/kibana-x-pack-monitoring-on-container.md

@@ -18,7 +18,7 @@ cpu 使用率とか load average がでない
 
 [Kibana Monitoring Elasticsearch nodes doesn’t show CPU usage](https://discuss.elastic.co/t/kibana-monitoring-elasticsearch-nodes-doesnt-show-cpu-usage/86505)
 
-kibanaに `xpack.monitoring.ui.container.elasticsearch.enabled: false` を食わせれば良い
+kibana に `xpack.monitoring.ui.container.elasticsearch.enabled: false` を食わせれば良い
 
 https://www.elastic.co/guide/en/kibana/current/monitoring-settings-kb.html
 

elasticsearch/rolling-restart-shard.md

@@ -3,15 +3,15 @@
 
 ## ES 6.x
 
-おもに3つ設定するとめちゃ速になる可能性がある
+おもに 3 つ設定するとめちゃ速になる可能性がある
 - `cluster.routing.allocation.node_concurrent_recoveries (default 2)`
     - https://www.elastic.co/guide/en/elasticsearch/reference/current/shards-allocation.html
     - cluster.routing.allocation.node_concurrent_{incoming,outgoing}_recoveries を設定する
     - restart 時の shards relocating の in/out の並列度を設定する
 - `indices.recovery.max_bytes_per_sec (default 40mb)`
     - https://www.elastic.co/guide/en/elasticsearch/reference/current/recovery.html
     - index recovery 時の network の limit を設定する
-    - (多分)最大で indices.recovery.max_bytes_per_sec * cluster.routing.allocation.node_concurrent_recoveries 分 network 帯域を使える
+    - (多分）最大で indices.recovery.max_bytes_per_sec * cluster.routing.allocation.node_concurrent_recoveries 分 network 帯域を使える
 - `cluster.routing.allocation.node_initial_primaries_recoveries (default 4)`
     - https://www.elastic.co/guide/en/elasticsearch/reference/current/shards-allocation.html
     - 直接的には関係はないが、primary shards 持ちの node が死んだ時に primary shards の recovery 並列を設定する

github/action_os_matrix.md

@@ -5,7 +5,7 @@
 ツール (ちょっとした ShellScript) を作ってる時に利用者の実行環境を縛れないケースのあるあるだと思うが、特に Mac はデフォルト BSD コマンドなので自分環境では動くけど他人にやらせたら実行できないみたいなのがある。
 なのでそれを事前に検出して潰したい。
 
-Golang で作って goreleaser とかで multi arch build すりゃいいじゃん?というのはそれはそうで、HomeBrew/LinuxBrew 用に Fomula 合わせて更新していくみたいなのが筋がいいとは思っている 。
+Golang で作って goreleaser とかで multi arch build すりゃいいじゃん？というのはそれはそうで、HomeBrew/LinuxBrew 用に Fomula 合わせて更新していくみたいなのが筋がいいとは思っている 。
 用意が面倒。
 
 あとは試してないけど Docker image に包んで multi-arch で配るのも考えられる。

gitlab/api-limit.md

@@ -1,6 +1,6 @@
 # api の一括取得数
 
-gitlab api で帰ってくる項目数はdefault で 20 に制限されている
+gitlab api で帰ってくる項目数は default で 20 に制限されている
 
 https://docs.gitlab.com/ee/api/#pagination
 >  Number of items to list per page (default: 20, max: 100)