diff --git a/.github/workflows/reviewdog.yaml b/.github/workflows/reviewdog.yaml new file mode 100644 index 0000000..f3bf130 --- /dev/null +++ b/.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/**" diff --git a/.textlintrc.json b/.textlintrc.json index 00642c2..ccda569 100644 --- a/.textlintrc.json +++ b/.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", diff --git a/Makefile b/Makefile new file mode 100644 index 0000000..456a95c --- /dev/null +++ b/Makefile @@ -0,0 +1,2 @@ +lint: + npx textlint --fix . || true diff --git a/ansible/ansible-inventory-command.md b/ansible/ansible-inventory-command.md index 88c5096..a7fb0f3 100644 --- a/ansible/ansible-inventory-command.md +++ b/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) を使って試す diff --git a/ansible/file-module-atomic-mv.md b/ansible/file-module-atomic-mv.md index aa1678a..34c329e 100644 --- a/ansible/file-module-atomic-mv.md +++ b/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` 相当をしているのか不明だったので調査 diff --git a/ci/drone_uses_buildkit.md b/ci/drone_uses_buildkit.md index 041f3f2..7b1294f 100644 --- a/ci/drone_uses_buildkit.md +++ b/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 diff --git a/cncf/cloud_native_meetup_tokyo_4.md b/cncf/cloud_native_meetup_tokyo_4.md index dbebae5..9c717ce 100644 --- a/cncf/cloud_native_meetup_tokyo_4.md +++ b/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 を指定できる diff --git a/cncf/cloud_native_meetup_tokyo_7.md b/cncf/cloud_native_meetup_tokyo_7.md index a0ac4ad..060ddf3 100644 --- a/cncf/cloud_native_meetup_tokyo_7.md +++ b/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 持ってたらそれを引っ張れる diff --git a/confluence/sum_in_table_row.md b/confluence/sum_in_table_row.md index b721e59..2a330f7 100644 --- a/confluence/sum_in_table_row.md +++ b/confluence/sum_in_table_row.md @@ -32,7 +32,7 @@ AJS.toInit(function ($) { ``` -confluence table で合計を出したい列を見出し行(`th`) にして、`#sum` にする +confluence table で合計を出したい列を見出し行（`th`) にして、`#sum` にする ## 参考 diff --git a/database/how_to_use_sql_calls_to_secure_your_web_site.md b/database/how_to_use_sql_calls_to_secure_your_web_site.md index 4b793b3..104cb83 100644 --- a/database/how_to_use_sql_calls_to_secure_your_web_site.md +++ b/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 文が変化することがないため安全である。 diff --git a/datadog/openmetrics.md b/datadog/openmetrics.md index 91f004d..84a94bf 100644 --- a/datadog/openmetrics.md +++ b/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/.*` を基本として埋める +pod annotation に `ad.datadoghq.com/.*` を基本として埋める 実際には deployment とか StateFullSets とかの `spec.template.metadata.annotations` に書くことになると思う ```yaml @@ -27,7 +27,7 @@ pod annotation に`ad.datadoghq.com/.*` を基本として埋め ] ``` ここの `CONTAINER_IDENTIFIER` は `spec.template.spec.containers.name` と一致させる必要がある -`check_names` は DD integration の名前なので `openmetrics` 固定(ほかに integration 入れるなら足す +`check_names` は DD integration の名前なので `openmetrics` 固定（ほかに integration 入れるなら足す ```yaml ad.datadoghq.com/.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}` として投げられる。 diff --git a/docker/alpine_apk_add.md b/docker/alpine_apk_add.md index d481851..8c3f9c8 100644 --- a/docker/alpine_apk_add.md +++ b/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 では diff --git a/docker/buildkit_cache.md b/docker/buildkit_cache.md index b739f1f..88d5861 100644 --- a/docker/buildkit_cache.md +++ b/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) を入れる diff --git a/docker/buildkit_cache_tips.md b/docker/buildkit_cache_tips.md index ea82398..305f3b5 100644 --- a/docker/buildkit_cache_tips.md +++ b/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 できない diff --git a/docker/buildkit_dns.md b/docker/buildkit_dns.md index 5bda0a8..6205f69 100644 --- a/docker/buildkit_dns.md +++ b/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 diff --git a/docker/container-structure-test.md b/docker/container-structure-test.md index 108c80e..5587968 100644 --- a/docker/container-structure-test.md +++ b/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`: 指定した環境変数があるか diff --git a/docker/docker-meetup-tokyo-26.md b/docker/docker-meetup-tokyo-26.md index 89247f1..0707620 100644 --- a/docker/docker-meetup-tokyo-26.md +++ b/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 diff --git a/docker/docker-meetup-tokyo20.md b/docker/docker-meetup-tokyo20.md index f520fe4..aa0b885 100644 --- a/docker/docker-meetup-tokyo20.md +++ b/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 でのスケジューリングができる diff --git a/docker/dockerize.md b/docker/dockerize.md index fc97ab1..b734fa5 100644 --- a/docker/dockerize.md +++ b/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 diff --git a/docker/image_diet_with_multistage_build.md b/docker/image_diet_with_multistage_build.md index 6b66443..3edcc89 100644 --- a/docker/image_diet_with_multistage_build.md +++ b/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 だけ引き抜く diff --git a/elasticsearch/kibana-x-pack-monitoring-on-container.md b/elasticsearch/kibana-x-pack-monitoring-on-container.md index 8f4fade..2636bad 100644 --- a/elasticsearch/kibana-x-pack-monitoring-on-container.md +++ b/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 diff --git a/elasticsearch/rolling-restart-shard.md b/elasticsearch/rolling-restart-shard.md index a35ea51..c453b18 100644 --- a/elasticsearch/rolling-restart-shard.md +++ b/elasticsearch/rolling-restart-shard.md @@ -3,7 +3,7 @@ ## 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 を設定する @@ -11,7 +11,7 @@ - `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 並列を設定する diff --git a/github/action_os_matrix.md b/github/action_os_matrix.md index 2fd23b9..8c9ad0f 100644 --- a/github/action_os_matrix.md +++ b/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 で配るのも考えられる。 diff --git a/gitlab/api-limit.md b/gitlab/api-limit.md index 6f55bb9..e7e4e53 100644 --- a/gitlab/api-limit.md +++ b/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) diff --git a/gitlab/meetup-tokyo-6.md b/gitlab/meetup-tokyo-6.md index 2874eb8..b957fc4 100644 --- a/gitlab/meetup-tokyo-6.md +++ b/gitlab/meetup-tokyo-6.md @@ -5,13 +5,13 @@ - GitLab Inc. 本家 - git -> github 誕生 - github は Public だからエンプラ使いにくい - - github EE は ブラックボックスでわからん! + - github EE はブラックボックスでわからん！ - OSS な github clone として gitlab の立ち上げ - 初めは code management + MR(PR) - + CI/CD , monitoring というアプリケーションすべてのマネジメントに -- (質問)なんでたぬきのロゴ? - - 最初のロゴはたぬきで怖かった(娘もびびってた) - - デザイナにいい感じな tanuki を依頼したら、google translateにタヌキをかけると Japanese Fox になるので今のキツネになった +- (質問）なんでたぬきのロゴ？ + - 最初のロゴはたぬきで怖かった（娘もびびってた） + - デザイナにいい感じな tanuki を依頼したら、google translate にタヌキをかけると Japanese Fox になるので今のキツネになった ## State of Community Contributions to GitLab CE @@ -20,24 +20,24 @@ - [Gitlab.com architecture](https://about.gitlab.com/handbook/infrastructure/production-architecture/) DB - Master/Slave 構成 - - 基本Master で読み書きしてるけど負荷が高いときは Slavekに流す + - 基本 Master で読み書きしてるけど負荷が高いときは Slavek に流す スケール感 - Azure に乗ってる - Consul + terraform + chef 管理 - 120 コンポーネント位ある - - sidekick が大変(MR遅くなったり) - - 今はAzure 1本だけどそのうちGCPにも載せたい + - sidekick が大変（MR 遅くなったり） + - 今は Azure 1 本だけどそのうち GCP にも載せたい - モニタリング - Kubernetes - フロントは Graphana - Prometheus alert manager - Prometheus -- GitLabl.comの運用自体は5人位で運用してる - - infra設計, 構築は 5-10人くらい -- 100M単位のユーザ -- (質問) サイジング目安は? +- GitLabl.com の運用自体は 5 人位で運用してる + - infra 設計、 構築は 5-10 人くらい +- 100M 単位のユーザ +- (質問）サイジング目安は？ - (https://docs.gitlab.com/ce/install/requirements.html) - - 自動化でガンガンAPI叩くならその限りではないよ + - 自動化でガンガン API 叩くならその限りではないよ ## Cloud Native GitLab ChartでGitLabをk8sにデプロイする diff --git a/gitlab/upgrade-gitlab-runner10.x.md b/gitlab/upgrade-gitlab-runner10.x.md index 90d0aff..90f5c59 100644 --- a/gitlab/upgrade-gitlab-runner10.x.md +++ b/gitlab/upgrade-gitlab-runner10.x.md @@ -14,8 +14,8 @@ https://docs.gitlab.com/runner/install/linux-repository.html # curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash # yum install gitlab-runner ``` -9.x で install されていた`/etc/systemd/system/gitlab-runner.service` の unit file まできれいに消されるので install コマンドで再生成する -9.x までは default installすると directory が /home/gitlab-runner, user も gitlab-runner なので合わせる(無指定だと /home/admin, root になる) +9.x で install されていた `/etc/systemd/system/gitlab-runner.service` の unit file まできれいに消されるので install コマンドで再生成する +9.x までは default install すると directory が /home/gitlab-runner, user も gitlab-runner なので合わせる（無指定だと /home/admin, root になる） ``` # gitlab-runner install -u gitlab-runner -d /home/gitlab-runner ``` diff --git a/golang/cli-cobra.md b/golang/cli-cobra.md index fdbb91b..0659988 100644 --- a/golang/cli-cobra.md +++ b/golang/cli-cobra.md @@ -1,5 +1,5 @@ # [cobra](https://github.com/spf13/cobra) -Go の cli フレームワーク。Moby(Docker)やKubernetes の cli tool としても使われている。 +Go の cli フレームワーク。Moby(Docker)や Kubernetes の cli tool としても使われている。 ## init `github.com/nekottyo/go-cli` を作る ```bash @@ -61,5 +61,5 @@ $ go run main.go add 2 3 ``` ## flag -flag はglobal と local があり、subcommnad に引き継ぐ設定もある +flag は global と local があり、subcommnad に引き継ぐ設定もある https://github.com/spf13/cobra#working-with-flags diff --git a/golang/database_sql_tuning.md b/golang/database_sql_tuning.md index 527c4bc..00e2f85 100644 --- a/golang/database_sql_tuning.md +++ b/golang/database_sql_tuning.md @@ -3,7 +3,7 @@ database/sql のチューニング # 前提 -DataBase は connection pool を持っている(idle and open connection)。 +DataBase は connection pool を持っている（idle and open connection)。 SQL の実行などの DB タスクを実行する時、connection は open connection としてマークされ、タスクが終わると idle connection に戻る。 @@ -23,7 +23,7 @@ idle connection が connection pool に無い場合は、 Go は新しいコネ - connection を再利用できるため、メモリ効率が良くなり、allocate 回数が減る - idle connection を維持する事自体もメモリを消費するため、単純に大きくすればいいというわけではない - - コネクションが正常ではなくなった場合、Go は接続を2回試してだめだったら connection pool から削除して新しく connection を作るが、`MaxIdleConns` が大きかった場合より大きなリソースを消費する可能性がある + - コネクションが正常ではなくなった場合、Go は接続を 2 回試してだめだったら connection pool から削除して新しく connection を作るが、`MaxIdleConns` が大きかった場合より大きなリソースを消費する可能性がある - `MaxIdleConns <= MaxOpenConns` にする必要がある # `SetMaxOpenConns` diff --git a/golang/directory_structure.md b/golang/directory_structure.md index 622fc90..40eeb17 100644 --- a/golang/directory_structure.md +++ b/golang/directory_structure.md @@ -24,7 +24,7 @@ Golang directory structure - tow most common patterns - このパターンは or ではなく and もありうる - `cmd` layout pattern - - 1つ以上の binary が必要なときによい + - 1 つ以上の binary が必要なときによい - `your_project/cmd/your_app` - main を持っているので、それぞれのパッケージが `go get` 可能 - `cmd/your_app` 以下で上の structure を作るパターン diff --git a/golang/golang_tokyo_23.md b/golang/golang_tokyo_23.md index 6129e53..62aa471 100644 --- a/golang/golang_tokyo_23.md +++ b/golang/golang_tokyo_23.md @@ -29,7 +29,7 @@ https://speakerdeck.com/mom0tomo/golang-tokyo-go-tools - test 周り - `testing` - `_test.go` は build 時には使われない - - Table Driven Testいいぞ + - Table Driven Test いいぞ # Delveを用いたデバッグ & pprofを用いたプロファイリング / 渡邉 光 diff --git a/golang/jason.md b/golang/jason.md index d321453..7e381ae 100644 --- a/golang/jason.md +++ b/golang/jason.md @@ -1,7 +1,7 @@ # [jason](https://github.com/antonholmquist/jason) > Easy-to-use JSON Library for Go -軽量json パーサ +軽量 json パーサ ## jason parse diff --git a/golang/static-link-build.md b/golang/static-link-build.md index 921e616..e085278 100644 --- a/golang/static-link-build.md +++ b/golang/static-link-build.md @@ -2,7 +2,7 @@ static link な binary を build する ===== https://github.com/golang/go/issues/26492#issuecomment-435462350 -(Go 1.13 からは `go build -static` でよくなるかも?) +(Go 1.13 からは `go build -static` でよくなるかも？) 基本的には `-tags netgo -ldflags '-extldflags "-static"'` があれば良さそう。 diff --git a/helm/helm_docs.md b/helm/helm_docs.md index 5421820..36a2472 100644 --- a/helm/helm_docs.md +++ b/helm/helm_docs.md @@ -21,7 +21,7 @@ config: - hashbash ``` -なお、type は values から `int`, `string`, `float`, `bool` を類推するが、`# -- ()` で 型ヒントを与えることが出来る。 +なお、type は values から `int`, `string`, `float`, `bool` を類推するが、`# -- ()` で型ヒントを与えることが出来る。 ```yaml controller: diff --git a/kubernetes/federation-v2.md b/kubernetes/federation-v2.md index 9617511..01d9c33 100644 --- a/kubernetes/federation-v2.md +++ b/kubernetes/federation-v2.md @@ -185,7 +185,7 @@ for c in cluster1 cluster2; do done ``` -cluster 設定を 両方に戻すと +cluster 設定を両方に戻すと ```sh $ kubectl -n test-namespace patch federatednamespaceplacement test-namespace \ diff --git a/kubernetes/k8s_dev_tools.md b/kubernetes/k8s_dev_tools.md index 144f1bf..f031770 100644 --- a/kubernetes/k8s_dev_tools.md +++ b/kubernetes/k8s_dev_tools.md @@ -38,4 +38,4 @@ https://github.com/solo-io/squash - vscod/intellij で remote debug できる。ぱない - 活発 -- remote debug したいなら一択? +- remote debug したいなら一択？ diff --git a/kubernetes/k8s_meetup_14.md b/kubernetes/k8s_meetup_14.md index 46aefc2..a2466be 100644 --- a/kubernetes/k8s_meetup_14.md +++ b/kubernetes/k8s_meetup_14.md @@ -16,7 +16,7 @@ https://k8sjp.connpass.com/event/104450/ - Quipper SRE - 東京 3 - マニラ 1 - - ロンドン1 + - ロンドン 1 - Kubernetes への移行 - CTO のトップダウンで移行が始まった @@ -26,18 +26,18 @@ https://k8sjp.connpass.com/event/104450/ - Quipper - 2012~ heroku - 2018/02~ Deis Workflow(Deis v2) - - 2018/08~ Kubernetes(本番も) + - 2018/08~ Kubernetes(本番も） - モチベーション - Deis が EOS - Deis V2 は k8s 上で動いてるのでそれほど苦じゃない - - fork された Hephy もあったが... + - fork された Hephy もあったが。.. - Deis Workflow は k8s のラッパー定期位置づけ - 機能が足りない部分もあった - 移行の流れ - Dockerfile - - Heroku Buildpackだからそんな難しくない + - Heroku Buildpack だからそんな難しくない - Twelve Factor App だから難しくない - Monorepo 化 - subtree で入れてった @@ -58,15 +58,15 @@ https://k8sjp.connpass.com/event/104450/ - monorepo - サービスのほぼ全てを含むアプリケーションコード - - アプリケーションに近い部分は SRE から開発者に移譲(nginx の設定とか) + - アプリケーションに近い部分は SRE から開発者に移譲（nginx の設定とか） - cluster 構成 - - production は 1つ + - production は 1 つ - staging - - develop: develop branch用 cluster + - develop: develop branch 用 cluster - release: release branch 用 - pr-XXX: PR を作るたびに生成される - - branch-router という pod (ngnx?) をおいて、各namespace にルーティングさせる + - branch-router という pod (ngnx?) をおいて、各 namespace にルーティングさせる - 課題 - クラスタの継続アップデート @@ -76,7 +76,7 @@ https://k8sjp.connpass.com/event/104450/ - 質疑 - - k8s cluster を世代管理したのは? + - k8s cluster を世代管理したのは？ - EKS に Tokyo region がない - kube-aws を使ってるから @@ -91,7 +91,7 @@ https://nulab-inc.com/ja/blog/cacoo/cacoo-microservices-with-kubernetes/ - 課題 - モノリシックなアプリケーション - - 1アプリ1インスタンス + - 1 アプリ 1 インスタンス - build/deploy が大変 - 依存関係が強い - EOS なライブラリ @@ -101,13 +101,13 @@ https://nulab-inc.com/ja/blog/cacoo/cacoo-microservices-with-kubernetes/ - 部分的な変更が容易 - リソース最適化 - 疎結合 - - 目標: "変更を容易に" + - 目標： "変更を容易に" - 方針 - オーナーシップ - 小さいほどよい - スクラッチ - - サービス間は強い片付け. protocol buffers + - サービス間は強い片付け。 protocol buffers - 開発環境はサービスごとに自由 - Backend/Middleware @@ -146,7 +146,7 @@ https://nulab-inc.com/ja/blog/cacoo/cacoo-microservices-with-kubernetes/ - Protocol Buffers - サービス間の型定義 - - 1つのレポジトリで管理 + - 1 つのレポジトリで管理 - 各レポジトリで submodule - gRPC でやりとり @@ -160,7 +160,7 @@ Yahoo https://github.com/yahoo/athenz -- 大規模なOpenStack +- 大規模な OpenStack - Kubernetes as a Service, PaaS 両方 - めっちゃ cluster ある diff --git a/kubernetes/kubectl-use-context.md b/kubernetes/kubectl-use-context.md index 7502665..b9c8b8d 100644 --- a/kubernetes/kubectl-use-context.md +++ b/kubernetes/kubectl-use-context.md @@ -1,7 +1,7 @@ kubectl config set-context と use-context ===== -kubectl config get-context で current contextが取れる +kubectl config get-context で current context が取れる ``` ~> kubectl config get-contexts diff --git a/kubernetes/microservice.io.md b/kubernetes/microservice.io.md index 69ec4cb..c71aa16 100644 --- a/kubernetes/microservice.io.md +++ b/kubernetes/microservice.io.md @@ -16,22 +16,22 @@ https://microservices.io/articles/applying.html マイクロサービスアーキテクチャパターン・ランゲージは多数のパターンのグループからなります。パターン・ランゲージの価値はパターンの合計を超えます。 -それは、パターン間での関係性を定義しているからです: +それは、パターン間での関係性を定義しているからです： -- Predecessor(先行要素?): “先行要素パターン”はこのパターンの必要性を動機づけるパターンです。 例えば、マイクロサービスアーキテクチャパターンは、モノリシックアーキテクチャパターンを除く残りのパターン・ランゲージの先行要素です。 -- Successor(後継): “後継パターン” はもたらされた問題を解決するパターンです。例えば、マイクロサービスアーキテクチャパターンを適用した時に、サービスディスカバリパターンやサーキットブレイカーパターンなどの多数の後続パターンを適用する必要があります。 -- Alternative(代替): “代替パターン”は代替案を提供します。例えば、モノリシックアーキテクチャパターンとマイクロサービスアーキテクチャパターンはアプリケーションアーキテクチャパターンの代替案です。2つの要素があるとき、一方を選択しなければなりません。これらの関係は、パターン言語を利用する時に貴重な方向性を提供します。あるパターンを適用すると、後継パターンを適用しなければならない問題が発生します。後継のパターンが存在しなくなるまで再帰的にパターンが選択されます。２つ以上のパターンがある場合は、１つを選択して適用しなければならなりませｎ。これは、多くの点でグラフ探索に似ています。 -それでは、あなたのアプリケーションにどのようにしてマイクロサービスアーキテクチャを適用するかを見てみましょう。この記事では、あなたがしなければならない3つの決定を見ていきます。今後の記事では、他の重要なものも見ますが、非常に重要というわけではありません。 +- Predecessor(先行要素？): “先行要素パターン”はこのパターンの必要性を動機づけるパターンです。 例えば、マイクロサービスアーキテクチャパターンは、モノリシックアーキテクチャパターンを除く残りのパターン・ランゲージの先行要素です。 +- Successor(後継）: “後継パターン” はもたらされた問題を解決するパターンです。例えば、マイクロサービスアーキテクチャパターンを適用した時に、サービスディスカバリパターンやサーキットブレイカーパターンなどの多数の後続パターンを適用する必要があります。 +- Alternative(代替）: “代替パターン”は代替案を提供します。例えば、モノリシックアーキテクチャパターンとマイクロサービスアーキテクチャパターンはアプリケーションアーキテクチャパターンの代替案です。2 つの要素があるとき、一方を選択しなければなりません。これらの関係は、パターン言語を利用する時に貴重な方向性を提供します。あるパターンを適用すると、後継パターンを適用しなければならない問題が発生します。後継のパターンが存在しなくなるまで再帰的にパターンが選択されます。2 つ以上のパターンがある場合は、1 つを選択して適用しなければならなりませ n。これは、多くの点でグラフ探索に似ています。 +それでは、あなたのアプリケーションにどのようにしてマイクロサービスアーキテクチャを適用するかを見てみましょう。この記事では、あなたがしなければならない 3 つの決定を見ていきます。今後の記事では、他の重要なものも見ますが、非常に重要というわけではありません。 ## Decision #1: モノリシックアーキテクチャかマイクロサービスアーキテクチャか -1つ目の決定はモノリシックアーキテクチャパターンかマイクロサービスアーキテクチャパターンかを決める必要があります。マイクロサービスアーキテクチャパターンを選択した場合、他の多数のパターンも決定する必要があります。 +1 つ目の決定はモノリシックアーキテクチャパターンかマイクロサービスアーキテクチャパターンかを決める必要があります。マイクロサービスアーキテクチャパターンを選択した場合、他の多数のパターンも決定する必要があります。 ![img](https://microservices.io/i/PatternsRelatedToMicroservices.jpg) ご覧のように、数多くのパターンを適用しなければなりません。いくつかの選択肢を見てみましょう。 ## Decision #2: どのようにしてアプリケーションをサービスに分割するか -あなたはマイクロサービスアーキテクチャを使うと決めた時、サービスを定義する必要があります。それには２つのオプションがあります。 +あなたはマイクロサービスアーキテクチャを使うと決めた時、サービスを定義する必要があります。それには 2 つのオプションがあります。 - ビジネス機能による分割 - ビジネスの機能に対応するサービスを定義する - サブドメインによる分割 - DDD におけるサブドメインでサービスを分割する @@ -40,7 +40,7 @@ https://microservices.io/articles/applying.html ## Decision #3 どのようにしてデータの一貫性の維持ととクエリの実行するか マイクロサービスの主な機能は、サービスごとのデータベースパターンです。別の方法として、データベース共有パターンがありますが、基本的ににはアンチパターンであり、避けることをおすすめします。 -サービスごとのデータベースパターンは、データの一貫性の維持とクエリの実行が動的に変わります。将来的には Saga パターンを使う必要があるでしょう。多くの場合コマンドクエリ責任分離パターン(CQRS パターン)を使用してクエリを実装する必要があります。 +サービスごとのデータベースパターンは、データの一貫性の維持とクエリの実行が動的に変わります。将来的には Saga パターンを使う必要があるでしょう。多くの場合コマンドクエリ責任分離パターン（CQRS パターン）を使用してクエリを実装する必要があります。 @@ -65,40 +65,40 @@ microservice architecture * 他のサービスとも粗結合で、影響しないしされない。自分たちの開発が独立してできる * 独立したデプロイで他チームとの調整もいらない * ちっちゃいチームで出来る。生産性高い - * マイクロサービス１つあたりはちっちゃい - * IDE も早いよ(なるほど) + * マイクロサービス 1 つあたりはちっちゃい + * IDE も早いよ（なるほど） * 障害にも強い - * １サービス落ちても分割されてるから他は生きてる + * 1 サービス落ちても分割されてるから他は生きてる * 新規マイクロサービス開発する時は新しいテクノロジスタックを選べる * cons: * 分散システムは複雑になる * サービス間テストむずい * 複数サービスにまたがる機能むずい - * (組織とマイクロサービスが 1:1 みたいな文脈) + * (組織とマイクロサービスが 1:1 みたいな文脈） * IDE とかはモノリシック前提だから大変かも * サービスいっぱいあるから全体のデプロイ大変 * メモリ効率は良くない HTTP/REST のような動機的津神か、 AMQP みたいな非同期通信でやりとりする。 -それぞれのサービスは他のサービスから切り離すために自身のDB を持つ。 +それぞれのサービスは他のサービスから切り離すために自身の DB を持つ。 サービス間のデータの一貫性は Saga パターンを使う ### いつつかうん? -新規開発は恩恵がないことが多い。大変な分散システムだと開発効率落ちるかも。スタートアップだと問題になるかも? ただ、サービスを垂直スケールし続けてモノリスになった頃に分割すると大変だぞ +新規開発は恩恵がないことが多い。大変な分散システムだと開発効率落ちるかも。スタートアップだと問題になるかも？　ただ、サービスを垂直スケールし続けてモノリスになった頃に分割すると大変だぞ ### どうやってサービス分割するの * ビジネス機能による分割  [https://microservices.io/patterns/decomposition/decompose-by-business-capability.html](https://microservices.io/patterns/decomposition/decompose-by-business-capability.html) * サブドメインによる分割 [https://microservices.io/patterns/decomposition/decompose-by-subdomain.html](https://microservices.io/patterns/decomposition/decompose-by-subdomain.html) -* 動詞, ユースケース, 特定のアクションに責任を持つサービス定義による分割 +* 動詞、 ユースケース、 特定のアクションに責任を持つサービス定義による分割 * Shipping Service -* 名詞, 与えられたエンティティーやリソース の全ての操作責任を持つサービスによる分割 +* 名詞、 与えられたエンティティーやリソースの全ての操作責任を持つサービスによる分割 * Account Service ### データの一貫性は -* サービス間を疎結合にするためにはそれぞれでDB を持つ。2相コミット/分散トランザクションは選択肢にならないため、 Saga pattern を使う。サービスはデータの変更を publish して、 consumer は Event sourcing と Transaction Log Tailing などを使ってデータを更新する +* サービス間を疎結合にするためにはそれぞれで DB を持つ。2 相コミット/分散トランザクションは選択肢にならないため、 Saga pattern を使う。サービスはデータの変更を publish して、 consumer は Event sourcing と Transaction Log Tailing などを使ってデータを更新する ### クエリの実装は @@ -118,13 +118,13 @@ DB 隠して API からのみ更新できるようにする * それぞれのサービスで好きな DB 使える。DB が Elasticserach でもいいし RDBMS でもいいし Mongo でもいいし cloud でもいい * cons * 複数サービスに跨ったビジネストランザクションは簡単じゃない。分散トランザクションは CAP 定義により避けるべき。さらにモダンな DB はサポートしてない。 Saga pattern を使うべき - * 複数DB に跨った変更加えるのむずい + * 複数 DB に跨った変更加えるのむずい * 複数の SQL, NoSQL 管理するの大変 * solusion: * API Composison - * api gateway 的なの用意する。DB を join するのではなく(多分) データを結合する。最初に customer service からカスタマー情報貰ってから、 order service からカスタマーの最近の注文をもらうみたいな + * api gateway 的なの用意する。DB を join するのではなく（多分）データを結合する。最初に customer service からカスタマー情報貰ってから、 order service からカスタマーの最近の注文をもらうみたいな * Command query Responsibility Segregation(CQRS) - * つまり Publish/Subscribe かな? + * つまり Publish/Subscribe かな？ * * * @@ -139,7 +139,7 @@ Saga Data base per Service 適用してて、それぞれのサービスが自分の DB を持っている状況で、複数サービスに跨ってデータの一貫性を保ったビジネストランザクションをする。 例えば、e-commerce store がクレジットカードの上限を持って居る時、アプリケーションは新規注文が顧客のクレジットカード上限に当たらないかを確認する必要がある。 -オーダーとカスタマは別のDB にあるため、単純にlocal ACID トランザクションは使えない。 +オーダーとカスタマは別の DB にあるため、単純に local ACID トランザクションは使えない。 ### problem @@ -147,17 +147,17 @@ Data base per Service 適用してて、それぞれのサービスが自分の ### 制約 -2PC(2相コミット)は使えない +2PC(2 相コミット）は使えない ### solution saga として複数のサービスにまたがるビジネストランザクションを実装する。saga はローカルトランザクションのシーケンスである。 それぞれのローカルトランザクションはデータベースのアップデートとメッセージかイベントを発行し、saga の次のローカルトランザクションをトリガする。 -もしトーかるトランザクションがビジネスルールに違反して失敗した場合、saga は前のローカルトランザクションによる変更を戻す一連の補償トランザクションを実行する(つまりロールバック)。 +もしトーかるトランザクションがビジネスルールに違反して失敗した場合、saga は前のローカルトランザクションによる変更を戻す一連の補償トランザクションを実行する（つまりロールバック）。 ![https://microservices.io/i/data/saga.jpg](https://microservices.io/i/data/saga.jpg) -saga では2つの調整方法がある: +saga では 2 つの調整方法がある： * Choreography: それぞれのローカルトランザクションは他のサービスのローカルトランザクションをトリガするドメインイベントを発行する * Orchestration: オーケストレーターは参加者にどのローカルトランザクションを実行するのかを伝える @@ -166,7 +166,7 @@ saga では2つの調整方法がある: ![https://microservices.io/i/data/Saga\_Choreography\_Flow.001.jpeg](https://microservices.io/i/data/Saga_Choreography_Flow.001.jpeg) -このプローチを使うe-commerce アプリケーションは次のステップからなる choreography-based saga を利用し注文を作成する +このプローチを使う e-commerce アプリケーションは次のステップからなる choreography-based saga を利用し注文を作成する 1. `Order Service` は保留状態の注文を作成し、 `OderCreated` イベントを発行する 2. `Customer Service` はその注文のクレジットを予約を試みるためのイベントを受信する。`Credit Reserved` イベントか、`CreditLimitExceeded` イベントを発行する @@ -176,7 +176,7 @@ saga では2つの調整方法がある: ![https://microservices.io/i/data/Saga\_Orchestration\_Flow.001.jpeg](https://microservices.io/i/data/Saga_Orchestration_Flow.001.jpeg) -このプローチを使うe-commerce アプリケーションは次のステップからなるOrchestration-based saga を利用し注文を作成する +このプローチを使う e-commerce アプリケーションは次のステップからなる Orchestration-based saga を利用し注文を作成する 1. `Order Service` は保留状態の注文を作成し、 `CreateOrderSaga` を作成する 2. `CreateOrderSaga` は `Customer Service` に `ReserveCredit` コマンドを送信する @@ -189,7 +189,7 @@ saga では2つの調整方法がある: * pros * 複数のサービスに跨ったデータの整合性を、 分散トランザクションを使わずに維持できる * cons - * プログラミングモデルは複雑になる。例えば、開発者はsaga の早い段階の変更を明示的に戻す補完トランザクションを設計しなければならない + * プログラミングモデルは複雑になる。例えば、開発者は saga の早い段階の変更を明示的に戻す補完トランザクションを設計しなければならない * 信頼性を高めるために、サービスはデータベースのアップデートとメッセージ/イベントの発行を自動で行わなければならない。 データベースとメッセージブローカにまたがる分散トランザクションは、従来のメカニズムでは利用できない。代わりに、以下のパターンを使う必要がある diff --git a/linux/brace_variable.md b/linux/brace_variable.md index e087998..7ba2cd5 100644 --- a/linux/brace_variable.md +++ b/linux/brace_variable.md @@ -40,9 +40,9 @@ ls: cannot access {hoge,fuga}/aaa.txt: No such file or directory > * word splitting > * filename expansion -`$HOGE`の時点では braceではないため進んで、 variable expansion で展開されてそのまま `ls` の引数となったため +`$HOGE` の時点では brace ではないため進んで、 variable expansion で展開されてそのまま `ls` の引数となったため -`eval` や subshell 経由の実行をすると再度上から式評価されるため brace expansionされる +`eval` や subshell 経由の実行をすると再度上から式評価されるため brace expansion される # 解決策 diff --git a/linux/epoch_milli_seconds.md b/linux/epoch_milli_seconds.md index 27e07ab..01a091a 100644 --- a/linux/epoch_milli_seconds.md +++ b/linux/epoch_milli_seconds.md @@ -2,16 +2,16 @@ --- datadog の metrics がめちゃめちゃでかい epoch time を返していたので調べた -ちゃんと書いてたけど最初 46万年とかなって dd ぶっ壊れてるかと思った +ちゃんと書いてたけど最初 46 万年とかなって dd ぶっ壊れてるかと思った https://docs.datadoghq.com/logs/processing/parsing/?tab=matcher#parsing-dates -4.6万年とか表示されていたが +4.6 万年とか表示されていたが ```code ❯ gdate -d @1412978400000 Tue Jul 3 16:00:00 GMT 46745 ``` -1000 するか、下4桁目で `.` 打ってあげるといい感じになる +1000 するか、下 4 桁目で `.` 打ってあげるといい感じになる ```code ❯ gdate -d @1412978400.000 diff --git a/linux/expand_nested_variable_in_shell.md b/linux/expand_nested_variable_in_shell.md index a515083..a43cdeb 100644 --- a/linux/expand_nested_variable_in_shell.md +++ b/linux/expand_nested_variable_in_shell.md @@ -3,7 +3,7 @@ shell でネストされた変数を展開したい # 問題 -例えばRuby の bundle install 時に、 development なら `bundle install --without development` で、 +例えば Ruby の bundle install 時に、 development なら `bundle install --without development` で、 production なら `bundle install --without development:test` みたいなことをやりたい。 ```bash diff --git a/linux/hub-ci-status.md b/linux/hub-ci-status.md index 7113c2e..77046c4 100644 --- a/linux/hub-ci-status.md +++ b/linux/hub-ci-status.md @@ -1,7 +1,7 @@ `hub ci-status -v` ===== -便利! +便利！ ```sh ➜ hub ci-status -v diff --git a/linux/remove-busy-lv.md b/linux/remove-busy-lv.md index 114335a..531d13d 100644 --- a/linux/remove-busy-lv.md +++ b/linux/remove-busy-lv.md @@ -14,12 +14,12 @@ VG1--hoge 253 7 L--w 2 1 0 LVM-AAAAAAAAAAAAAAAAAAAAAaaaaaaaaaaaaa VG1--hogep1 253 8 L--w 0 1 0 part1-LVM-AAAAAAAAAAAAAAAAAAAAAaaaaaaaaaaaaaaaaa ``` -hoge が hogep1, p2 から参照されていて Openが 2 なので busy +hoge が hogep1, p2 から参照されていて Open が 2 なので busy ## 削除方法 -partから消して参照をなくす +part から消して参照をなくす ``` # dmsetup remote /dev/mapper/VG1-hogep2 @@ -28,7 +28,7 @@ partから消して参照をなくす ``` -その後lvremove +その後 lvremove ``` # lvremove /dev/VG1/hoge Logical volume "hoge" successfully removed diff --git a/linux/terminal.md b/linux/terminal.md index 88f80ff..7019581 100644 --- a/linux/terminal.md +++ b/linux/terminal.md @@ -31,10 +31,10 @@ https://github.com/albfan/terminator https://github.com/jwilm/alacritty -日本語表示に難あり。2バイト文字以外なら使いやすい。 +日本語表示に難あり。2 バイト文字以外なら使いやすい。 GPU Accelareted。 -フォントサイズ Up/Down のキーバインドが、config ファイルを共有する場合 Mac/Linux でうまくいかない(Mac は Command だが, Linux は Ctrl) +フォントサイズ Up/Down のキーバインドが、config ファイルを共有する場合 Mac/Linux でうまくいかない（Mac は Command だが、 Linux は Ctrl)
ssh 経由だと表示が崩れる。ダブルクリックでの copy on select が不発するときが多い。 diff --git a/misc/cookpad-tech-kitchen-20.md b/misc/cookpad-tech-kitchen-20.md index ffc63ff..b5660dc 100644 --- a/misc/cookpad-tech-kitchen-20.md +++ b/misc/cookpad-tech-kitchen-20.md @@ -14,9 +14,9 @@ Cookpad Tech Kitchen #20 クックパッドのマイクロサービスプラッ - ELB -> ECS -> internal ELB -> ECS みたいな構成 - 問題 - - トラブルシュート, debug が大変 + - トラブルシュート、 debug が大変 - capacity planning -- 解決策1 +- 解決策 1 - Expeditor - aws-xray - distributed tracing @@ -24,7 +24,7 @@ Cookpad Tech Kitchen #20 クックパッドのマイクロサービスプラッ - からの network proxy - service mesh - - library で リトライとか circuit braking を envoy でやる + - library でリトライとか circuit braking を envoy でやる - Envoy proxy - data-plane @@ -56,7 +56,7 @@ Cookpad Tech Kitchen #20 クックパッドのマイクロサービスプラッ # 岩間 雄太 gRPC in Cookpad(仮) - これまでの cookpad - - Garage, GarageClient で API共通化 + - Garage, GarageClient で API 共通化 - Autodoc でドキュメンテーション - つらみ - IDL, schema ほしい @@ -67,13 +67,13 @@ Cookpad Tech Kitchen #20 クックパッドのマイクロサービスプラッ - generate code - 運用 - - ECS の hako(自作) 上で動作 + - ECS の hako(自作）上で動作 - cookpad/sds + Envoy で Client side Loadbalancing - Envy 経由で受ける -- Protocol Buffers は 1つのレポジトリ +- Protocol Buffers は 1 つのレポジトリ - 各サービスに submodule で配布 - - CI で ドキュメント生成 + - CI でドキュメント生成 - Prometheus with envoy - mtail が envoy のアクセスログを Prometheus 用に流す @@ -118,6 +118,6 @@ Cookpad Tech Kitchen #20 クックパッドのマイクロサービスプラッ - コンテナモニタリングは cAdvisor -- AWS, ECS に最適化されすぎてない...? -- スケールイン, スケールアウトを自分でやってるのがつらそう +- AWS, ECS に最適化されすぎてない。..? +- スケールイン、 スケールアウトを自分でやってるのがつらそう diff --git a/misc/devsumi2018.md b/misc/devsumi2018.md index 8eea376..d72e76b 100644 --- a/misc/devsumi2018.md +++ b/misc/devsumi2018.md @@ -5,7 +5,7 @@ https://event.shoeisha.jp/devsumi/20180727/timetable ソニーが取り組む DL, ML の話 -- DL は簡単 だし汎用 +- DL は簡単だし汎用 - 小さい規模から導入可能 - DL, AI は破壊的テクノロジー - 難しかったことを簡単にする @@ -24,7 +24,7 @@ https://event.shoeisha.jp/devsumi/20180727/timetable - Console のでも - 手書き文字の 4,9 の判別 - GUI で学習 - - Jupyter notebook で Librariesを使って手書き認識 + - Jupyter notebook で Libraries を使って手書き認識 - ブログ書くから見てね コード自体は簡単そうに見えるがそのコードを書く前提知識が多い @@ -33,26 +33,26 @@ https://event.shoeisha.jp/devsumi/20180727/timetable ## AI時代におけるエンジニアの生存戦略 -立ち見, みんな転職に興味ある? +立ち見、 みんな転職に興味ある？ - AI, データサイエンティストの求人は伸びてる -- AIは専門家の代わりになるものとして使われている - - 量, 速度が圧倒的にAI有利 +- AI は専門家の代わりになるものとして使われている + - 量、 速度が圧倒的に AI 有利 - 事例 - 証券会社の公開コンテンツの校閲 - 法規制のための文言 - それまでの言い回しか - チェックを行い修正提案ができる -- ビジネス, データサイエンス, データエンジニアリングが必要 - - 全部持っている人は少ないから, 組織としてカバーする +- ビジネス、 データサイエンス、 データエンジニアリングが必要 + - 全部持っている人は少ないから、 組織としてカバーする -会社紹介, 会社が持っているサービス紹介の色がつよい +会社紹介、 会社が持っているサービス紹介の色がつよい ----- ## Hashicorp Vault on Google Cloud Platform -credential 管理を楽にしたいな? +credential 管理を楽にしたいな？ - https://dev.classmethod.jp/tool/hashicorp-vault-basic-knowledge/ - MySQL account のダイナミック発行 @@ -60,8 +60,8 @@ credential 管理を楽にしたいな? - 定期的にクレデンシャルを変更したい - Seal 状態 - Vault 使えない状態 - - Unseal Key が 5つあって、そのうち3つないと UnSeal できないみたいな各発射ボタンシステムな仕組みが使える - - Seal にするには１つの key でよい + - Unseal Key が 5 つあって、そのうち 3 つないと UnSeal できないみたいな各発射ボタンシステムな仕組みが使える + - Seal にするには 1 つの key でよい ----- @@ -73,7 +73,7 @@ credential 管理を楽にしたいな? - 力技 - とにかく手を動かす - いろんな論文を片っ端から試す - - すでに実装があっても自分の利会のために自分で書く(積極的車輪の再発明) + - すでに実装があっても自分の利会のために自分で書く（積極的車輪の再発明） - 機械学習に必要な数学 - 線形代数 - 機械学習ライブラリを使うが、前処理をちゃんとしたい @@ -83,7 +83,7 @@ credential 管理を楽にしたいな? - 積がどのくらいのサイズになるか意識する - 全部ゴリゴリに書きたい 2. 線形空間に関する感覚を身につける -- データサイエンティストには数学は必要? +- データサイエンティストには数学は必要？ - 多くの場合必要ない - が、強みの可能性にはなる - キャリアとして @@ -95,23 +95,23 @@ credential 管理を楽にしたいな? ### 富士フィルムソフトウェア -GHE の必要となった経緯, 導入の障壁の話 +GHE の必要となった経緯、 導入の障壁の話 -"""Github は エンジニアにとっての SNS""" +"""Github はエンジニアにとっての SNS""" - コードレビュ - - h2h で DiffView で 見せながらやってた + - h2h で DiffView で見せながらやってた - Excel でレビューの議事録をとってた - つらそう - レビューの指摘事項によって重み付けをしてたが、PR だとその情報が失われる - - コメントで クリティカル、重要みたいなカウントを入れて、API 経由で別の Webアプリからコメント読んで集計出して GH Pages で品質見える化 + - コメントでクリティカル、重要みたいなカウントを入れて、API 経由で別の Web アプリからコメント読んで集計出して GH Pages で品質見える化 - コメントは Chrome Extention で自動で入れるようにする - レビュアーが PR 貯まる問題 - API 経由で PR 持ってきてレビュアー一覧を出す画面を作った -- 早朝リファクタリングマラソン(15分) - - 静的解析の指摘, テスト拡充などの技術的負債の返済 - - コーディングは毎朝15分 - - その日のうちにPR, その日にレビュー +- 早朝リファクタリングマラソン（15 分） + - 静的解析の指摘、 テスト拡充などの技術的負債の返済 + - コーディングは毎朝 15 分 + - その日のうちに PR, その日にレビュー - 50 step 以内 - レビュアーはその修正内容のみを見る - 1 step でもいい @@ -121,7 +121,7 @@ GHE の必要となった経緯, 導入の障壁の話 ### マクニカネットワークス -会場では GitHub or GHE 使っているのは２割 +会場では GitHub or GHE 使っているのは 2 割 パンフレットに IIJ さん @@ -132,7 +132,7 @@ GHE の必要となった経緯, 導入の障壁の話 - https://api.rakuten.co.jp/ja/ - 社内 API と外側の HUB - Single interface で API あ提供者と API 利用者をつなぐ - - 50万 developer + - 50 万 developer - 課金もまとまるし、analytics もできる - 一括で料金管理 - Vue で RapidAPI を叩くライブコーディング @@ -152,7 +152,7 @@ GHE の必要となった経緯, 導入の障壁の話 ----- -データと戦うエンジニアLT！ +データと戦うエンジニア LT！ ## 【世界初！Go言語とMySQL UDFで実現する超高速データ前処理/分析基盤】 [ミーカンパニー] @@ -161,10 +161,10 @@ GHE の必要となった経緯, 導入の障壁の話 go udf はいいぞ -- 紙(物理) を OCR してとか -- 公開情報の誤字脱字, key と value があっていないとか +- 紙（物理）を OCR してとか +- 公開情報の誤字脱字、 key と value があっていないとか - UDF(User Definition Function) を利用して前処理 - - ストアドプロシージャから600倍くらい早くなった + - ストアドプロシージャから 600 倍くらい早くなった ----- @@ -178,7 +178,7 @@ go udf はいいぞ - ルールベースでキーワードをもとに判別してみる - 人気レシピに多く、必ず手順の後ろに存在 - 51%くらい - - 例) 〜さんがマヨネーズを足してくれました + - 例）〜さんがマヨネーズを足してくれました - 機械学習 - TF-IDF - ロジスティックス回帰 @@ -192,10 +192,10 @@ go udf はいいぞ - 自然言語処理で typo は大敵 - 適切な分かち書きができない -- 単語分割しなくてもいいのでは? +- 単語分割しなくてもいいのでは？ - Character level CNN - - 最小単位が単語(文字) -- 100文字程度変えても 精度は 0.8 + - 最小単位が単語（文字） +- 100 文字程度変えても精度は 0.8 ----- diff --git a/misc/live_performance_technology.md b/misc/live_performance_technology.md index 76f5b95..f37046b 100644 --- a/misc/live_performance_technology.md +++ b/misc/live_performance_technology.md @@ -9,67 +9,67 @@ twitter: https://twitter.com/hashtag/sight?src=hashtag_click - 真鍋大度 @Rhizomatiks - https://www.youtube.com/channel/UCg_m3Y7A_K12cvIDNxzhH4A -- MIKIKO - 演出振付家, ELEVENPLAY, Perfume, BABYMETAL +- MIKIKO - 演出振付家、 ELEVENPLAY, Perfume, BABYMETAL -- エンジニアと振付家/ダンサーとのコミュニケーションは? +- エンジニアと振付家/ダンサーとのコミュニケーションは？ - ライゾマは音楽に長けた人が多い - ビデオコンテを渡すことが多い - iMovie 使ってる - ライゾマとダンサーの橋渡しをしている - レクサスの展示 - https://www.daito.ws/work/lexus-leading-with-light.html - - 照明256, 台車6台 + - 照明 256, 台車 6 台 - 台車の動きも MIKIKO 先生が作ってる - 台車の動きは、ダンサーにセンサーつけてキャプチャで撮ってる - その後にダンサーの動きを作るので、台車の振り付けができることは大変なようで楽 - - 普通台車の振り付けするの? - - 台車と踊ることも少ない... + - 普通台車の振り付けするの？ + - 台車と踊ることも少ない。.. - ドローン 24 台のインスタレーションもドローンの振り付けをした - ドローンの振り付けもするので、ダンサーとのシンクロ率が高い - - ドローンにマーカーをつけて、センサー で場所, 角度を出す + - ドローンにマーカーをつけて、センサー で場所、 角度を出す - 外でやるのは GPS - - ドローンの動き > ダンサーの動き > ダンスのときのドローンの色とか点滅 の順で振り付け + - ドローンの動き > ダンサーの動き > ダンスのときのドローンの色とか点滅の順で振り付け - 最初はできるネタを出して、MIKIKO 先生にインスピレーションを起こしてもらう - 最初のでもは技術的に可能なこととこを動画とかで見せる - 使ってもらえないネタもある - システムが安定してきたら CG ソフトとかで作るけど最初からではない - その場で色々変更するのでダンサーが集まっても何もやらない日とかもある - ライゾマはハードとコンピュータビジョンが強い - - 室内で既製品で24台のドローンを制御しようとすると今でも難しい + - 室内で既製品で 24 台のドローンを制御しようとすると今でも難しい - 屋外の GPS 制御はそこそこ - - ハードウェア, オリジナルのデバイスを作っているのが強い + - ハードウェア、 オリジナルのデバイスを作っているのが強い - border - https://www.youtube.com/watch?v=DdYw3ZZ0XLQ - https://www.youtube.com/watch?v=-xIx9DIgI9o - WHEEL の制御も作ってた - https://whill.jp/ - - ダンサーとどうコミeュニケーション? + - ダンサーとどうコミ e ュニケーション？ - Perfume, ELEVENPLAY は頭の中でカウントしながら踊れる - どののタイミングで柱がどこにあるかみたいなのも覚えている - 舞台装置とダンサーはセット - Perfume も ELEVENPLAY も毎回同じ動きができるから成り立っている - 提案の時点でハードウェアも構成もシステムもバシッと決めてる - - 構成, 設置時間, スタッフの数も + - 構成、 設置時間、 スタッフの数も - Perufume 5G - https://www.youtube.com/watch?v=BjNMbDXJJ4c - - 東京, NY, ロンドンで同じ時間に踊る + - 東京、 NY, ロンドンで同じ時間に踊る - 遅延は 1s で一定なので安定してる - キャリブレの時間とかも出す - - 3会場 16台が同じ位置と角度で置かれているか + - 3 会場 16 台が同じ位置と角度で置かれているか - キャリブレーションの速度を出すための三角錐 - - 4K 映像, 2ch オーディオ + - 4K 映像、 2ch オーディオ - ワイプの仕組みを新しく考えた - 会場を 3D スキャンしてカメラの位置と場所をモッチ得るので 3D でワイプを入れれる - カメラカットもスキャンデータで 3D で踊る - 演出に落とし込むのはライズオマはやらない - 映像ができてから音楽を発注 - 演出は ELEVENPLAY で試す - - vコンは最初は文字 + - v コンは最初は文字 - その時点では振り付けはない - `すごみのあるCG効果` - - ライゾマとやることによって Perfume, ELEVENPLAY の変化は? - - 1人でソロを踊ることが初めて + - ライゾマとやることによって Perfume, ELEVENPLAY の変化は？ + - 1 人でソロを踊ることが初めて - 一人で踊っても先に手がある感覚 - 派手にするために LED をするのではなく、後ろの映像をどのくらい感じられるか - ステージ全体にどのくらい関与できるか @@ -78,9 +78,9 @@ twitter: https://twitter.com/hashtag/sight?src=hashtag_click - korosuke - WHEEL の車輪部分 - ネタ出し会 - - ライゾマ, MIKIKO 先生, ELEVENPLAY でライゾマが得たを持ち合う + - ライゾマ、 MIKIKO 先生、 ELEVENPLAY でライゾマが得たを持ち合う - 持ちネタいっぱいある - - dot 表現なドローンに レーザーを当ててベクタ表現 + - dot 表現なドローンにレーザーを当ててベクタ表現 - ネタは普段はライゾマができることを色々提供している - Perfume の大きい舞台でこういうことやりたいのでどうすればみたいなのは MIKIKO 先生から - 過去の元ネタはかなり調べる @@ -90,17 +90,17 @@ twitter: https://twitter.com/hashtag/sight?src=hashtag_click - 質疑 - インスタレーションを見る側のリテラシーも必要になってくるのでは - アートはコンセプトを知った上で見るもの - - その時に分かる必要はない, 5年後分かるでもいい + - その時に分かる必要はない、 5 年後分かるでもいい - エンタメは見ただけで感じれる - 発表場所で演出変えたりするのか - 変えずにやるのがモットー、海外は人数が少ないから自分たちで設営ができるかみたいなのはある - - ヨーロッパの方がアートの目が厳しい, 批評文化 + - ヨーロッパの方がアートの目が厳しい、 批評文化 - 同じことをやっているけど言い回しを変えるテクニック - ダンサーはなぜ女性しかいないかとか、同じ服装しかいないかみたいなジェンダーバランスの質問もある - 言われて嬉しかったこと - discreet figure だとテクノロジーで 3G のダンサーと踊ることはすごい評価された - テクノロジーが父でダンサーが母でこのインスタレーションが生まれたのね - - 他の業界に応用した例は? + - 他の業界に応用した例は？ - ない - そういうオファーがあってもあまりやらない - 表現にフォーカスしている @@ -111,8 +111,8 @@ twitter: https://twitter.com/hashtag/sight?src=hashtag_click - MRI, Brain decoding - https://researchmap.jp/y_kamitani/?lang=english - 脳の活動から見ている映像を再現する - - 音を聞いて映像を再現する, ダンスを考えていれば映像になる未来 + - 音を聞いて映像を再現する、 ダンスを考えていれば映像になる未来 - 無声映画を見て音楽をつける未来 - - 脳に電気信号を与える(言語野を刺激して言葉が出にくくなるとか) + - 脳に電気信号を与える（言語野を刺激して言葉が出にくくなるとか） -次回: https://techplay.jp/event/join/756734 +次回： https://techplay.jp/event/join/756734 diff --git a/misc/noops_meetup_tokyo_6.md b/misc/noops_meetup_tokyo_6.md index d6f0249..8353693 100644 --- a/misc/noops_meetup_tokyo_6.md +++ b/misc/noops_meetup_tokyo_6.md @@ -24,16 +24,16 @@ http://bit.ly/20190604-noops-meetup - SLI, SLO, SLA - エラーバジェット - 運用の課題をソフトウェア・エンジニアリングで解決する - - ビジネス, 開発, 運用 も含めて SLO を元に動く必要がある + - ビジネス、 開発、 運用も含めて SLO を元に動く必要がある - そのデータをどうやって取るかが Ovservability - - 従来ではハードウェア, OS + 実行環境のモニタリングをしていたのはマネージド側で管理できるようになってきた + - 従来ではハードウェア、 OS + 実行環境のモニタリングをしていたのはマネージド側で管理できるようになってきた - アプリやサービス全体のオブザーバビリティが重要になってくる - **オブザーバ日リティは勝手に上がらない** - Stackdriver (GCP) - GCP が Stackdriver を提供する意味 - API より内側はプラットフォームでしか提供できない - SRE の実戦経験を共有する近道 -- 運用プロセスで必要なデータ, ツールは異なる +- 運用プロセスで必要なデータ、 ツールは異なる - 通常運用 (Stackdriver Monitoring) - メトリクス - 統計的に動いているか @@ -43,18 +43,18 @@ http://bit.ly/20190604-noops-meetup - 構造化ログベースからチャート - アラート - SLO 違反していないか - - 高付加, 調査 + - 高付加、 調査 - プロファイラ - 統計情報を取得 - - Ccpu 使用率, メモリ, + - Ccpu 使用率、 メモリ、 - 分散トレース - 特定の負荷を見つける - 復数のサービスにまたがったトレース - 障害対応 - エラーレポート - 種類ごとにグルーピング - - 似たようなエラーを勝手にまとめてくれる.すごい - - 頻度, 回数も集計 + - 似たようなエラーを勝手にまとめてくれる。すごい + - 頻度、 回数も集計 - IRM - インシデントレポートを一元管理 - めちゃすごい @@ -66,14 +66,14 @@ http://bit.ly/20190604-noops-meetup # 物理データセンターでも NoOps @ymmt2005 https://speakerdeck.com/ymmt2005/wu-li-detasentademo-noops -- 標準PC メモリ 32GB の人 +- 標準 PC メモリ 32GB の人 - https://twitter.com/ymmt2005/status/833896090155962368 - cybozu.com - 規模が単調増加 - サーバ数十台の頃からアーキテクチャが変わらず - - 手作業, Toil が多い + - 手作業、 Toil が多い - スケーラビリティが低い -- 手順書を作る, レビューは辛い +- 手順書を作る、 レビューは辛い - リハーサルも辛い - 時間もかかる - 求めるもの @@ -83,7 +83,7 @@ https://speakerdeck.com/ymmt2005/wu-li-detasentademo-noops - Kubernetes 中心アーキテクチャ - 設計原則 - Be Declarative - - Kubernetes 意外もすべて 宣言的操作 + - Kubernetes 意外もすべて宣言的操作 - Define by Software - Test Everything - 仮想データセンターを活用した CI/CD @@ -93,7 +93,7 @@ https://speakerdeck.com/ymmt2005/wu-li-detasentademo-noops - Kubernetes の上と下でデリバリを分割 - Argo CD で kubernetes 上のアプリはデリバリ - Kubernetes の下は宣言的デリバリ - - 当てる前の状態を作って, 更新をかけるとか, 電源喪失シナリオのテストなどもある + - 当てる前の状態を作って、 更新をかけるとか、 電源喪失シナリオのテストなどもある - 今後 - ストレージ管理 - 自作 CSI プラグイン @@ -106,30 +106,30 @@ https://speakerdeck.com/katsuhisa91/class-sre-implements-noops - 標準作業手順書 - NoOps とは - コラボレーションを重視する DevOps - - NoOps は Operation と密なコミュニケーションを取らなくてもオペレーションが回る...? + - NoOps は Operation と密なコミュニケーションを取らなくてもオペレーションが回る。..? - どこまでを Ops とするか - DevOps と NoOps は対立構造ではない - NoOps is not No Operation - Toil の計測 - 作業を分類 - kanban で管理 - - 現在は 5~10% の Toil + - 現在は 5〜10% の Toil - Toil の減らし方 - Engineer Toil Out of the System - Toil をへらす前にシステムを変更して Toil が生まれにくようにできないか - 不可逆性が高い部分はどこか - 性能面で詰まる部分はどこか - Design Document を必ず書く - - Postmortem(障害報告書) を書くのと同じくらい重視 + - Postmortem(障害報告書）を書くのと同じくらい重視 - より信頼性の高いコンポーネントに置き換える - SLO - ダウンタイムを許容する - Provide Self-Service Method - - 開発者から依頼を受けて仕事するのではなく, 開発者自身にやってもらう + - 開発者から依頼を受けて仕事するのではなく、 開発者自身にやってもらう - チケットドリブンでは組織の経済的な無駄を生む - Self Service - Define - Execute - Govern - - Define, Execute は開発者が持って, Govern は SRE が持つのが理想? + - Define, Execute は開発者が持って、 Govern は SRE が持つのが理想？ diff --git a/openid_connect/CoLab_OpenID_Connect.md b/openid_connect/CoLab_OpenID_Connect.md index 67b3f78..e9687c5 100644 --- a/openid_connect/CoLab_OpenID_Connect.md +++ b/openid_connect/CoLab_OpenID_Connect.md @@ -12,7 +12,7 @@ 比較的古い SOAP, XML でやりとり ## OAuth は認可 -ユーザのリソースに(Web APIが)アクセスすることが目的 +ユーザのリソースに（Web API が）アクセスすることが目的 - 1.0a - リクエストパラメータに署名 @@ -55,7 +55,7 @@ https://openid.net/connect - implicit Flow に比べて認証強度が高い - Refresh Token を発行するため長期間でもいける - Hybrid Flow - - サーバ, クライアント両方で認証 + - サーバ、 クライアント両方で認証 - あんまり使わない ## 用語集 @@ -65,7 +65,7 @@ https://openid.net/connect - OP: OpenID Provider - IdP とほぼ同じ、 OpenID での呼び方 - RP: Relying Party - - IdP の認証を利用して ユーザにサービスを提供する + - IdP の認証を利用してユーザにサービスを提供する - Resource Server - ユーザの属性情報などを提供 - Claim @@ -84,11 +84,11 @@ https://openid.net/connect - `id_token` を検証してユーザ認証 # ID Token -issuer(idp: id_token発行したひと) が audience(RP) のために subject(id_tokenの対象, End-User) を認証したかを示すトークン +issuer(idp: id_token 発行したひと）が audience(RP) のために subject(id_token の対象、 End-User) を認証したかを示すトークン ## format: JSON Web Token -JSON を URL Safeな Base64 エンコードしたシグエンチャつきトークン +JSON を URL Safe な Base64 エンコードしたシグエンチャつきトークン - ヘッダ、ペイロード、シグネチャで構成 @@ -122,28 +122,28 @@ Base64 エンコード - URS Safe - `+` -> `-` - `/` -> `_` - - `=` -> `''` (削る) + - `=` -> `''` (削る） -- JSON の `{"` を Base64 にすると eyJ になる(アゲアゲ) +- JSON の `{"` を Base64 にすると eyJ になる（アゲアゲ） - ピリオドで繋ぐ -- シグネチャにかけて Base64 にで URLセーフにエンコード +- シグネチャにかけて Base64 にで URL セーフにエンコード - ピリオドでつなげる ### 検証 - ヘッダとペイロードを入力 -- 3つ目を公開鍵で検証 +- 3 つ目を公開鍵で検証 # UserInfo Endpoint -OpenID Connect ではよく利用される指名, 住所, メールアドレスなどの属性情報を取得しやすいように Claim を指定する +OpenID Connect ではよく利用される指名、 住所、 メールアドレスなどの属性情報を取得しやすいように Claim を指定する - Req - bearer つける - Res - いろんな属性が帰ってくる - - 氏名, 送信可能なメールアドレス, 住所, 電話とか + - 氏名、 送信可能なメールアドレス、 住所、 電話とか - scope - 必要な属性情報の group 的なやつ diff --git a/paas/paas_38.md b/paas/paas_38.md index 64ea2fd..7cedfb8 100644 --- a/paas/paas_38.md +++ b/paas/paas_38.md @@ -14,8 +14,8 @@ - node に Nutanix Controller VM を載せてそいつが制御する - Nutanix Era - Amazon RDS と同じ位置づけ - - オンプレでも楽にしたい(クラウドっぽい使い方をしたい) - - Virtual Appliance が 任意のスナップショットから DB 込み VM を生成してくる + - オンプレでも楽にしたい（クラウドっぽい使い方をしたい） + - Virtual Appliance が任意のスナップショットから DB 込み VM を生成してくる - DB の Clone とかもしてくれる - Time Machine がよろしくやってくれる - トランザクションログと組み合わせて任意時点のバックアップが取れる @@ -23,8 +23,8 @@ - 未リリースだよ - Mysql と SQL Server も - Demo - - デプロイ時にSLAが選べて、スナップショットの間隔が選ばれる - - 世代が古くなるほどトランザクションログ,デイリーバックアップ, ウイークリーバックアップと粒度が変わってくる + - デプロイ時に SLA が選べて、スナップショットの間隔が選ばれる + - 世代が古くなるほどトランザクションログ、デイリーバックアップ、 ウイークリーバックアップと粒度が変わってくる ## IaaSをいじっている人がPaaSを調べてやったこと - @tnmt @@ -34,11 +34,11 @@ - ~2015 - ロリポレンタルサーバ - 物理サーバ調達から - - リードタイム2ヶ月 + - リードタイム 2 か月 - オンプレ課題 - リードタイム長すぎ問題 - 管理大変問題 - - プライベートクラウド Nyah(かわいい) + - プライベートクラウド Nyah(かわいい） - OpenStack - 開発者が環境用意できる - コスト削減 @@ -67,23 +67,23 @@ ## 最強のクラウドネイティブ基盤？ Knativeのあれこれ - @jacopen -- みんなで筋肉体操をやろう! -- Kubernetes 難しい... -- さらに Istio も難しい... +- みんなで筋肉体操をやろう！ +- Kubernetes 難しい。.. +- さらに Istio も難しい。.. - サーバレスめっちゃ盛り上がってる - Kubernetes + Serverless = Knative - - ケイは発音するんだぞ [kay-nay-tiv] + - ケイは発音するんだぞ［kay-nay-tiv] - Google, Pivotal, IBM, Red Hat, SAP - Kubernetes + Knative + Istio - ソースコードデプロイ - Blue green - 使われていないコンテナは消えて、アクセスされると生えてくる - - サーバレスとは違う... + - サーバレスとは違う。.. - Knative でいう Serverless != FaaS - ステートレス - アプリケションレベルからリクエストされるトラフィックで駆動 - Riff - - Lambdaっぽくいける + - Lambda っぽくいける - Kwsk - Open Kwsk - 所感 diff --git a/ruby/ampersand_proc.md b/ruby/ampersand_proc.md index 0aa7857..2055f27 100644 --- a/ruby/ampersand_proc.md +++ b/ruby/ampersand_proc.md @@ -7,7 +7,7 @@ from http://gihyo.jp/book/2017/978-4-7741-9397-7 proc を渡す時は & をつける -& は to_proc を呼び出して 戻り値の proc を引数として与える動きをする +& は to_proc を呼び出して戻り値の proc を引数として与える動きをする ```ruby @@ -22,7 +22,7 @@ symbol は proc 変換できる >> upcase_proc.class #=> Proc ``` -symbol から作った proc は 第1引数はレシーバ, 第2引数以降は symbol のメソッドの 第1, 第2... 引数となる +symbol から作った proc は第 1 引数はレシーバ、 第 2 引数以降は symbol のメソッドの第 1, 第 2... 引数となる ```ruby >> upcase_proc = :upcase.to_proc #=> # @@ -33,8 +33,8 @@ symbol から作った proc は 第1引数はレシーバ, 第2引数以降は s - :upcase という symbol を to_proc し proc オブジェクトにする - map の引数として proc オブジェクトがブロックで渡される -- map によりproc の第1引数として各要素を受け取る -- 第1引数が レシーバとなり upcase が呼び出され戻り値となる +- map により proc の第 1 引数として各要素を受け取る +- 第 1 引数がレシーバとなり upcase が呼び出され戻り値となる - map は proc の戻り値を新しい配列に入れる ということをしている diff --git a/ruby/rails_security.md b/ruby/rails_security.md index 99199b8..42df0ab 100644 --- a/ruby/rails_security.md +++ b/ruby/rails_security.md @@ -10,7 +10,7 @@ production: secret_key_base: <%= ENV["SECRET_KEY_BASE"] %> ``` -- セッション固定攻撃対策に,ログイン成功したらセッション作り直す +- セッション固定攻撃対策に、ログイン成功したらセッション作り直す - ユーザ管理に [Devise](https://github.com/plataformatec/devise) 使う - サーバ側でセッション切れを管理しといたほうが安全 - セッションテーブルに作成日も入れといて期限を過ぎたセッションは消す @@ -20,7 +20,7 @@ ``` ## CSRF 対策 -- `protect_from_forgery with: :exception` (default で入る) でトークン入れる +- `protect_from_forgery with: :exception` (default で入る）でトークン入れる ## リダイレクト, ファイル - リダイレクトはパラメータから取らない。ユーザから与えられないようにする @@ -38,9 +38,9 @@ end end ``` -- アップロードとDBへの保存は非同期にする +- アップロードと DB への保存は非同期にする - ダウンロードもファイル名が期待されている path に置かれているかチェックする - - あるいは ファイルを id 管理にする [attachment_ru](https://github.com/technoweenie/attachment_fu) + - あるいはファイルを id 管理にする [attachment_ru](https://github.com/technoweenie/attachment_fu) ## イントラネットとAdminのセキュリティ @@ -56,9 +56,9 @@ - ログイン画面では失敗理由を表示しない - パスワード忘れでも失敗理由を表示しない - 複数回失敗したら CAPCHA 義務付ける -- パスワード変更は(おそらくログイン済みの時)古いパスワードを入力させる +- パスワード変更は（おそらくログイン済みの時）古いパスワードを入力させる - メールアドレス変更もパスワードを入力させる -- つまり重要な変更を加える前にパスワードを変更させる! +- つまり重要な変更を加える前にパスワードを変更させる！ - パスワードはログに出さない - filter_parameters を設定する ``` @@ -68,7 +68,7 @@ - ユーザの入力値はアクセス権なども含め確認する - ホワイトリストとブラックリストは、まずはホワイトリストの適用を考える - ブラックリストに引っかかったらこねくり回さずに拒否する -- SQL で外部文字列はサニタイズする,プレースホルダーを使う +- SQL で外部文字列はサニタイズする、プレースホルダーを使う - ユーザ入力はホワイトリストで弾く ``` tags = %w(a acronym b strong i em li ul ol h1 h2 h3 h4 h5 h6 blockquote br cite sub sup ins p) diff --git a/ruby/ruby-on-rails-grade-schrool.md b/ruby/ruby-on-rails-grade-schrool.md index f8cb5b8..3b1da03 100644 --- a/ruby/ruby-on-rails-grade-schrool.md +++ b/ruby/ruby-on-rails-grade-schrool.md @@ -127,13 +127,13 @@ class UsersController < ApplicationController end ``` -twitter っぽくしたいとき `http://hoge.com/users/show/nekottyo` みたいに名前 が URI になるのはどうすれば? +twitter っぽくしたいとき `http://hoge.com/users/show/nekottyo` みたいに名前が URI になるのはどうすれば？ # ルーティング -`http://hoge.com/users/show/nekottyo` がしたい！ -> ルーティング +`http://hoge.com/users/show/nekottyo` がしたい！　-> ルーティング -- Rails での アクセスした URL を元に振り分けるもの +- Rails でのアクセスした URL を元に振り分けるもの >ユーザーがURLにアクセス ⇒ ルーティングが仕分け ⇒ コントローラーが値を入れる ⇒ ビューがコントローラーから渡された値を表示 @@ -152,12 +152,12 @@ end http://127.0.0.1:3000/user/show/nekottyo -で名前ベースで 表示できるようになる +で名前ベースで表示できるようになる # DB -- DBの構造 -> スキーマ +- DB の構造 -> スキーマ - マイグレーションファイル -> スキーマ定義 > 注 migrationという名の通り、移住をしやすくするためのようなイメージです。 移住するときに家を立てなければなりませんが、家の設計図さえあれば、いくらでも同じ家を立てることができます。 その家の設計図がmigration fileです。しかし、このmigration fileだけでは、住めません。 家をたてるために、その設計図から家を実際に建てなければなりません。それがmigrateです。 @@ -261,7 +261,7 @@ rails g model tweet title:string context:text ![new](https://raw.github.com/mitakalab/wiki/master/screenshots/rails/rails-10.png) -view の form を入れる(フォームヘルパー) +view の form を入れる（フォームヘルパー) `app/views/tweets/new.html.erb` @@ -278,7 +278,7 @@ view の form を入れる(フォームヘルパー) undefined method `tweets_path' for #<#:0x00007f1e7c3db1b0> ``` -form の投げ先がわからん ので route に足す +form の投げ先がわからんので route に足す ```diff Rails.application.routes.draw do diff --git a/ruby/turnip.md b/ruby/turnip.md index c487ad1..990601a 100644 --- a/ruby/turnip.md +++ b/ruby/turnip.md @@ -4,35 +4,35 @@ Turnip # はじめに turnip を調べると食べ物の名前がいっぱい出てくるので整理 -- Cucumber(きゅうり) - - BDDテストフレームワーク +- Cucumber(きゅうり） + - BDD テストフレームワーク - https://github.com/cucumber/cucumber -- Gherkin(きゅうりのピクルス) +- Gherkin(きゅうりのピクルス） - cucumber 等で使う言語 - https://github.com/codegram/gherkin-ruby -- Turnip(カブ) +- Turnip(カブ） - Cucumber 派生で、Cucumber のイケてないところを強くしたやつ - Graken 使う - - 日本語DSLで書ける + - 日本語 DSL で書ける - https://github.com/jnicklas/turnip -- Spinach(ほうれん草) +- Spinach(ほうれん草） - Gherkin で動く BDD フレームワーク - Cucmber と比較して、Step のメンテナンス性や再利用性を重視している - - 日本語DSLで書けない + - 日本語 DSL で書けない - GitLab で使ってる - https://github.com/codegram/spinach - Capibara - UI テストのためのフレームワーク - form に値を入れたりボタン押したりできる - - Driver が必要(headlesschrome とか) + - Driver が必要（headlesschrome とか） - https://github.com/teamcapybara/capybara -Ruby の テスト界隈食べ物好きすぎなのでは... +Ruby のテスト界隈食べ物好きすぎなのでは。.。 ## BDD: Behavior Driven Development -TDD(テスト駆動開発)から派生。振る舞い(仕様)や制約条件を記述する。自然言語に近い形で記述。 +TDD(テスト駆動開発）から派生。振る舞い（仕様）や制約条件を記述する。自然言語に近い形で記述。 利用者目線でシナリオを書いてシステムに対してテストを行う。 diff --git a/security/tokumaru.md b/security/tokumaru.md index 374720f..2a90c0b 100644 --- a/security/tokumaru.md +++ b/security/tokumaru.md @@ -11,20 +11,20 @@ ## セッションID ### 要件 -セッションID を第三者 +セッション ID を第三者 1. が推測できないこと 2. から強制されないこと 3. に漏洩しないこと ### セッションID は自作しない -ツールのセッションID 管理機能を使う +ツールのセッション ID 管理機能を使う ### セッションID は認証した後に変更する -1. 攻撃者認証前にセッションID もらう -2. そのセッションID を正規利用者が認証 -3. 攻撃者がセッションID つきでアクセス +1. 攻撃者認証前にセッション ID もらう +2. そのセッション ID を正規利用者が認証 +3. 攻撃者がセッション ID つきでアクセス ###　クッキーの `Domain` 属性は指定しない @@ -37,7 +37,7 @@ JavaScript から取れなくなる # 3.2 ## 同一生成元ポリシー JavaScript のポリシー -- 同一FQDNである +- 同一 FQDN である - 同一プロトコルである - 同一ポートである @@ -73,7 +73,7 @@ JavaScript のポリシー - クッキーに HttpOnly - TRACE メソッド無効 - JS 動的生成 - - Unicode 文字 にする + - Unicode 文字にする - DOM based XSS - クエリパラメータを元に画面描画する場合 - エスケープするライブラリを使う @@ -100,24 +100,24 @@ XSS との違いはサーバ側で実行される脆弱性。 `hidden` 属性などで隠しながら正規の利用者の権限で内容を変更したりできる。 -セッション変数でパラメータ受け渡しでも iframe 2個とか使って攻撃が成立する +セッション変数でパラメータ受け渡しでも iframe 2 個とか使って攻撃が成立する 対策 - CSRF 対策の必要なページを区別　 - - ECサイトは実際に商品を購入するリクエストや個人情報を変更するリクエスト + - EC サイトは実際に商品を購入するリクエストや個人情報を変更するリクエスト - 正規利用者の意図したリクエストを区別 - トークン - 前のページにトークン埋め込んどいて、遷移先で検証する - パスワード再入力 - Referer チェック - 重要な処理の後にメールを飛ばす - - (パスワードなどの)重要な内容は含まないように + - (パスワードなどの）重要な内容は含まないように # 4.6 セッション管理の不備 ## 4.6.1 セッションハイジャック -セッションID の +セッション ID の - 推測 - 盗み出し - 強制 @@ -125,9 +125,9 @@ XSS との違いはサーバ側で実行される脆弱性。 ## 4.6.2 推測可能な セッションID 攻撃手法 -- セッションID を集める +- セッション ID を集める - 規則性の仮設を建てる -- 推測したセッションIDを試す +- 推測したセッション ID を試す 有りがちな生成方法 - user id , mail address @@ -137,18 +137,18 @@ XSS との違いはサーバ側で実行される脆弱性。 対策 - 自分でセッション管理機能を作らない -- クッキーにセションID を入れる +- クッキーにセション ID を入れる ## 4.6.3 セッションID の固定 攻撃手法 -- セッションID を入手 -- 攻撃者がセッションIDを強制 +- セッション ID を入手 +- 攻撃者がセッション ID を強制 - 被害者がログイン -- 攻撃者がそのセッションID を利用 +- 攻撃者がそのセッション ID を利用 対策 -- 認証後にセッションID を変更する +- 認証後にセッション ID を変更する # 4.7 リダイレクト処理にまつわる脆弱性 ## 4.7.1 オープリンダイレクタ @@ -160,12 +160,12 @@ XSS との違いはサーバ側で実行される脆弱性。 - リダイレクト先を固定する - リダイレクト先を直接指定しない - ドメインチェックをする -- (直接の対策ではないが)クッションページを用意する +- (直接の対策ではないが）クッションページを用意する ## 4.7.2 HTTP ヘッダインジェクション 攻撃手法 -- リダイレクト先URL, クッキーとなｒ URL パラメータの中に改行入れてヘッダをいじる +- リダイレクト先 URL, クッキーとな r URL パラメータの中に改行入れてヘッダをいじる 対策 - 外部パラメータを　 HTTP レスポンスヘッダにしない @@ -273,7 +273,7 @@ https only なページは全部セキュア属性をつける 対策 - 積極的なパスワードチェック - 簡単なの拒否る -- ログインIDの秘匿 +- ログイン ID の秘匿 - アカウントではなくメールアドレスで認証させる - ログイン失敗率の監視 @@ -293,7 +293,7 @@ https only なページは全部セキュア属性をつける 対策 - ソルト - ストレッチング - - 例) ユーザID に固定長文字列をつけてバイナリ文字列をソルトとして ハッシュ値にソルトとパスワードくっつけて sha-256 に N 回通す + - 例）ユーザ ID に固定長文字列をつけてバイナリ文字列をソルトとしてハッシュ値にソルトとパスワードくっつけて sha-256 に N 回通す 自動ログインについて - セッションタイムアウトの延長 @@ -302,26 +302,26 @@ https only なページは全部セキュア属性をつける ## 5.1.5 ログインフォーム -- パスワード入力欄はマスクする? +- パスワード入力欄はマスクする？ - https 使う - エラー表示は何で失敗したか表示しない - - 例) `ID または パスワードが違うか、アカウントロックされています` + - 例）`ID または パスワードが違うか、アカウントロックされています` ## 5.1.7 ログアウト機能 - ログアウト処理は副作用があるので POST にする - ログアウト処理ではセッションを履き -- 必要な場合CSRF 対策をする +- 必要な場合 CSRF 対策をする # 5.2 アカウント管理 ## 5.2.1 ユーザ登録 - メールアドレスの受信確認 - 1. メールにトークン付きURL を添付してメールクリックで処理継続 + 1. メールにトークン付き URL を添付してメールクリックで処理継続 - 操作性いいけど実装面倒、メールの url クリックさせたくない 2. トークン入力画面に遷移して、メールのアドレスにトークンを送りつけてそのトークンを入れてもらう - 実装簡単だがメールをすぐ受け取れないとだめ -- ユーザID の重複防止 +- ユーザ ID の重複防止 - UNIQUE つけたほうがいいよ - 自動登録対策には CAPTCHA @@ -332,7 +332,7 @@ https only なページは全部セキュア属性をつける ## 5.2.3 メールアドレスの変更 - 新規メールアドレスの受信確認 - 再認証 -- メール通知(新旧両方) +- メール通知（新旧両方） ## 5.2.4 パスワードリマインダ いわゆるパスワード忘れ @@ -342,9 +342,9 @@ https only なページは全部セキュア属性をつける - 管理者の仮パスワード発行 利用者向け -- 秘密の質問(非推奨) +- 秘密の質問（非推奨） - メールアドレスへの通知 - - パスワード変更URL 通知(メールクリックさせたくないので非推奨) + - パスワード変更 URL 通知（メールクリックさせたくないので非推奨） - 仮パスワードの発行 - メールアドレス入力 -> 秘密の質問 -> 再発行 - メールにトークン発行 -> トークン入力 -> 秘密の質問 -> 再発行 @@ -398,11 +398,11 @@ https only なページは全部セキュア属性をつける - 結果 # 6.1 文字コード -- 全体で文字集合をunicodeで統一する +- 全体で文字集合を unicode で統一する - 入力時に不正なエンコーディングをエラーにする - 処理でエンコーディングを正しく扱う - 出力時にエンコードを正しく指定する -- DBのエンコードを正しく指定する +- DB のエンコードを正しく指定する # 6.1 Web サーバの攻撃と対策　 - 不要なソフトウェアは稼働させない diff --git a/terraform/merge_aws_iam_policy_document.md b/terraform/merge_aws_iam_policy_document.md index c0fa359..64c90d4 100644 --- a/terraform/merge_aws_iam_policy_document.md +++ b/terraform/merge_aws_iam_policy_document.md @@ -18,11 +18,11 @@ resource aws_iam_policy_document a { } ``` みたいなことをやりたい。 -ユースケースとしては、1の policy json を再利用して複数の policy に紐付けたい時にほしい。 +ユースケースとしては、1 の policy json を再利用して複数の policy に紐付けたい時にほしい。 しかし上記の書き方は policy は string (json)なのでうまくいかない。 -また、`data.aws_iam_policy_document` には `source_json` や `override_json` もあるが 各 policy に食わせるように新たに作り直さなきゃいけないのでめんどい。 +また、`data.aws_iam_policy_document` には `source_json` や `override_json` もあるが各 policy に食わせるように新たに作り直さなきゃいけないのでめんどい。 ## 失敗 ```hcl diff --git a/terraform/s3_restrict_path.md b/terraform/s3_restrict_path.md index 887bf63..80084d0 100644 --- a/terraform/s3_restrict_path.md +++ b/terraform/s3_restrict_path.md @@ -1,7 +1,7 @@ terraform で s3 で特定の path だけアクセスを許可する policy の書き方 === -path を限定させて, `s3:GetObject` と`s3:List*` を特定 path に許可させる +path を限定させて、 `s3:GetObject` と `s3:List*` を特定 path に許可させる 同時に、`s3:List*` は bucket に対して与え、 condition で prefix check をする。 list object を dynamic block で `for_each` で回すのと、 condition の values も list で展開するといい感じに書ける。 diff --git a/textlint/ignore_rule.md b/textlint/ignore_rule.md index 76dc351..ad4222d 100644 --- a/textlint/ignore_rule.md +++ b/textlint/ignore_rule.md @@ -15,7 +15,7 @@ https://github.com/prh/rules/blob/master/media/WEB+DB_PRESS.yml#L2236-L2239 ``` 以下のルールによって、`マスタ merge` となってしまう。 -大体は [textlint-filter-rule-allowlist](https://github.com/textlint/textlint-filter-rule-allowlist) で回避可能なのだが、 rule 評価のタイミング(ちゃんと調べてないから分からん) 起因なのか、 +大体は [textlint-filter-rule-allowlist](https://github.com/textlint/textlint-filter-rule-allowlist) で回避可能なのだが、 rule 評価のタイミング（ちゃんと調べてないから分からん）起因なのか、 `.textlintrc` の `filters.allowlist.allow: ["/master/"]` のように書いても rule を無視できない事がある。 ## prh.yaml による ignore diff --git a/vim/gorillavim2.md b/vim/gorillavim2.md index 3dcf933..5a6e714 100644 --- a/vim/gorillavim2.md +++ b/vim/gorillavim2.md @@ -15,7 +15,7 @@ https://twitter.com/search?f=tweets&q=%23gorillavim&src=typd&lang=ja - Modes - Normal, Insert, Visual - Operator - - d,y : operator は2回叩くと行志向になる + - d,y : operator は 2 回叩くと行志向になる - 変更と繰り返し - . - u @@ -34,8 +34,8 @@ https://twitter.com/search?f=tweets&q=%23gorillavim&src=typd&lang=ja https://docs.google.com/presentation/d/1uNouaZOLsYDwtaFBGhWdX4u1V-9uWWWqX7U2gl_Ou3k/edit#slide=id.p -- 社内 vim slack があるけど活発じゃない... - - 実践Vim 読書会 +- 社内 vim slack があるけど活発じゃない。.. + - 実践 Vim 読書会 - 1H 会議室 - 目次を眺めて、読む場所決めて、時間まで読みながら雑談 - `'`, で戻れる @@ -57,7 +57,7 @@ https://speakerdeck.com/mtsmfm/vscodevim-is-also-vim # mastering vim という本について @okuramasafumi -- ユースケース別(機能別ではない) +- ユースケース別（機能別ではない） - ぷらぎん豊富 - `:arg` であとから引数を足せる