markdownlint fix 2024

README.md

@@ -9,6 +9,7 @@
 * _profile.yml に追加
 
 ## setup
+
 ### SNSカウントを表示させるために、Facebook開発者用のトークンが必要
 
 1. Facebook開発者キーが必要
@@ -114,4 +115,4 @@ Lint with lint-staged(staged files only)
 ```sh
 git add source/_posts
 npx lint-staged
-```
+```

source/_posts/2024/20240109a_【合格体験記】（ドローン）二等無人航空機操縦士の振り返り.md

@@ -33,7 +33,6 @@ lede: "無人航空機操縦士試験（二等）に合格するまでの体験
 + 実地試験
 + 身体検査
 
-
 また資格には、以下の限定(車で言うとAT限定のようなもの)があり、限定解除する場合は、通常の資格に追加して講習や試験が必要になります。
 
 <dl>
@@ -144,7 +143,6 @@ https://ua-remote-pilot-exam.com/
 
 >身体検査は、①有効な公的証明書の提出、②-1医療機関の診断書の提出（一等25㎏未満限定及び二等）、②-2医療機関の診断書の提出（一等25kg以上）、③指定試験機関の身体検査受検（一等25㎏未満限定及び二等）のいずれかの方法で受検ができます。
 
-
 | 項目 | 身体検査基準 |
 |:-:|:-|
 | 視力 | 視力が両眼で0.7以上、かつ、一眼でそれぞれ0.3以上であること、または一眼の視力が0.3に満たない者若しくは一眼が見えない者については、他眼の視野が左右150度以上で、視力が0.7以上であること。 |

source/_posts/2024/20240117a_【合格記】Google_Cloud_Professional_Developer認定資格を振り返る.md

@@ -14,7 +14,6 @@ lede: "Developer力を試すべくProfessional Developer認定資格を受験し
 ---
 <img src="/images/20240117a/Professional_Level_Google_Meets_Background.png" alt="" width="1200" height="682" loading="lazy">
 
-
 ## はじめに
 
 TIG岸下です。
@@ -28,14 +27,15 @@ Futureに中途で入社して今月で2年になります。2年前に初めて
 Google Cloud 認定資格関連の過去記事：
 
 [【合格体験記】Google Cloudの入門試験：Cloud Digital Leader](https://future-architect.github.io/articles/20231226a/)
-[【合格記】Google Cloud Professional Cloud Security Engineer認定資格を振り返る ](https://future-architect.github.io/articles/20230921a/)
+[【合格記】Google Cloud Professional Cloud Security Engineer認定資格を振り返る](https://future-architect.github.io/articles/20230921a/)
 [【合格記】Google Cloud Professional Data Engineer認定資格を振り返る](https://future-architect.github.io/articles/20211013a/)
 [【合格記】Google Cloud Professional Machine Learning Engineer認定資格を振り返る](https://future-architect.github.io/articles/20220930a/)
 [Google Cloud Professional Cloud Architectの再認定に合格しました](https://future-architect.github.io/articles/20220411a/)
 [GCP Professional Cloud Network Engineer に合格しました](https://future-architect.github.io/articles/20200902/)
 [GCP Associate Cloud Engineer 合格記](https://future-architect.github.io/articles/20210625a/)
 
 皆さんの協力のおかげで残りの合格記は
+
 - Cloud Database Engineer
 - Cloud DevOps Engineer
 - Google Workspace Administrator
@@ -49,62 +49,62 @@ Google Cloud 認定資格関連の過去記事：
 ### スケーラビリティ、可用性、信頼性に優れたクラウドネイティブ アプリケーションの設計
 
 - コンテナの基礎知識
-  - アプリケーションのコンテナ化におけるベストプラクティス
+ - アプリケーションのコンテナ化におけるベストプラクティス
 - アーキ設計とサービスの使い分け
-  - Cloud Run、Google Kubernetes Engine、App Engine、Managed Instance Groupなどアプリケーションのデプロイ環境
-  - Cloud SQL、Spanner、Bigtable、Firebaseなどのデータベース環境
-  - 内部通信のみを利用したいケース（限定公開のGoogleアクセスを利用するなど）
+ - Cloud Run、Google Kubernetes Engine、App Engine、Managed Instance Groupなどアプリケーションのデプロイ環境
+ - Cloud SQL、Spanner、Bigtable、Firebaseなどのデータベース環境
+ - 内部通信のみを利用したいケース（限定公開のGoogleアクセスを利用するなど）
 - GKE（Kubernetes）の基礎知識
-  - Ingress、Service、Deployment、Podなどの役割、何を定義するのか
-  - Workload Identityを利用したサービスアカウントとの紐づけ
-  - Namespaceの使い分けにおけるベストプラクティス
-  - Pod同士の通信方法
-  - 水平スケーリングと垂直スケーリング
-  - Istio（Google CloudマネージドであればAnthos Service Mesh）
+ - Ingress、Service、Deployment、Podなどの役割、何を定義するのか
+ - Workload Identityを利用したサービスアカウントとの紐づけ
+ - Namespaceの使い分けにおけるベストプラクティス
+ - Pod同士の通信方法
+ - 水平スケーリングと垂直スケーリング
+ - Istio（Google CloudマネージドであればAnthos Service Mesh）
 - PubSubの基礎知識
-  - トピックやサブスクリプションの置き方
-  - トピックからPushされるのか、Pullするのか
+ - トピックやサブスクリプションの置き方
+ - トピックからPushされるのか、Pullするのか
 
 ### アプリケーションのデプロイ
 
 - デプロイ方法の理解
-  - カナリアリリース、Blue/Green、ローリングアップデートなど
+ - カナリアリリース、Blue/Green、ローリングアップデートなど
 - トラフィックの分割
-  - サービスそのものの機能としての分割（Cloud Runなど）、Kubernetesの機能としての分割
+ - サービスそのものの機能としての分割（Cloud Runなど）、Kubernetesの機能としての分割
 - デプロイタイミングの制御
-  - Cloud Buildを利用した自動化
+ - Cloud Buildを利用した自動化
 
 ### デプロイされたアプリケーションの管理
 
 - Cloud Loggingへのログ出力
-  - JSON形式による吐き出しの推奨
-  - エラー標準出力を利用した連携
+ - JSON形式による吐き出しの推奨
+ - エラー標準出力を利用した連携
 - Cloud Loggingの他サービスとの連携
-  - ログルーターを利用したPubSub、BigQuery、Cloud Storageとの連携
-  - Google Cloud外のサービスと連携するにはPubSubにルーティングしておくなど
+ - ログルーターを利用したPubSub、BigQuery、Cloud Storageとの連携
+ - Google Cloud外のサービスと連携するにはPubSubにルーティングしておくなど
 - Cloud Monitoringを利用したアラートの設定
-  - ログベースなのか、メトリクスベースなのか
+ - ログベースなのか、メトリクスベースなのか
 - Cloud ProfilerやTraceを利用したエラーやサービス遅延の解明
 - 権限回り
-  - 最小権限の法則に従う
-  - エラー内容から足りない権限のトラブルシューティング
+ - 最小権限の法則に従う
+ - エラー内容から足りない権限のトラブルシューティング
 
 ### アプリケーションのビルドとテスト
 
 - Cloud Buildを利用したイメージビルド
-  - Cloud Source Repositoryとの連携による自動化
+ - Cloud Source Repositoryとの連携による自動化
 - Artifact Registryを利用したイメージの脆弱性チェック
-  - Binary Authorization
+ - Binary Authorization
 - 単体テストのベストプラクティス
-  - PubSubやCloud Runエミュレータを利用したローカルでのテスト
+ - PubSubやCloud Runエミュレータを利用したローカルでのテスト
 
 ### Google Cloud サービスの統合
 
 - オンプレとGoogle Cloudサービスの統合
-  - Kubernetesクラスターの共存
+ - Kubernetesクラスターの共存
 - リフトアンドシフト
-  - 業務影響を最小に抑えた移行戦略
-  - データベースとして利用されているアプリケーションを考慮した移行
+ - 業務影響を最小に抑えた移行戦略
+ - データベースとして利用されているアプリケーションを考慮した移行
 
 ### 全体的な所感
 
@@ -128,4 +128,3 @@ Google Cloudのサービスは多岐にわたるため数が多く、存在を
 Developer力を試したい方は一度受けてみてはいかがでしょうか！
 
 アイキャッチ画像は[Google Cloud Certification](https://sites.google.com/robertsonmarketing.com/digitalassetdownloadportal/digital-toolkit)から付与されたものになります。
-

source/_posts/2024/20240118a_ウォーターフォールでもアジャイルでも「タイムラインふりかえり」をやってみたらどうでしょう？という話.md

@@ -47,6 +47,7 @@ Global Design Group所属の山本です。
 両者を比較すると、大きな違いとしてはステップサイクルの単位や期間が異なることが挙げられます。
 
 ## インクリメンタル開発モデルと「振り返り」
+
 <img src="/images/20240118a/image_2.png" alt="image.png" width="879" height="398" loading="lazy">
 
 今回、私ははじめてアジャイル開発でのプロジェクトに参加しました。ウォーターフォールとリリースサイクルや動き方が大きく変わるため、良い経験になりました。
@@ -67,6 +68,7 @@ Global Design Group所属の山本です。
 今回の経験を通して、短期間で振り返り・フィードバックを行うことは、アジャイルに限らず有意義なことと感じました。では、ウォーターフォール開発などのスプリント単位がない場合ではどうなるのでしょうか？
 
 ## シーケンシャル開発モデルと「振り返り」
+
 <img src="/images/20240118a/image_3.png" alt="image.png" width="806" height="533" loading="lazy">
 
 次に上の図のような、典型的なウォーターフォール開発とチーム内での「振り返り」について考えてみましょう。
@@ -92,7 +94,6 @@ Global Design Group所属の山本です。
 
 <img src="/images/20240118a/image_4.png" alt="image.png" width="885" height="551" loading="lazy">
 
-
 例えば、基本設計終了時に、基本設計フェーズに関する課題や学びが得られても、工程自体に依存するものであった場合は次にメンバーが関わる・活かせるのは数年後とかになりかねません。
 (※もちろん、課題が次のステップに関連があり有用なケースも考えられます)
 
@@ -125,14 +126,14 @@ KPTで振り返りをした個人の感想としては、以下のようなも
 
 ■メリット
 
-* シンプルでわかりやすい。チームメンバー全員が認識している可能性が高い。
-* 振り返りの成果として、次に繋げる(Try)ことを明文化しやすい
+- シンプルでわかりやすい。チームメンバー全員が認識している可能性が高い。
+- 振り返りの成果として、次に繋げる(Try)ことを明文化しやすい
 
 ■デメリット
 
-* 議論が発散しやすい、ファシリテーターの質に依存しやすい
-* Problemに集中していまい、反省会のようなムードになりやすい
-* チームメンバーが何をしていたのか分かりづらい
+- 議論が発散しやすい、ファシリテーターの質に依存しやすい
+- Problemに集中していまい、反省会のようなムードになりやすい
+- チームメンバーが何をしていたのか分かりづらい
 
 手法の選択肢としては良いところもありなのですが、個人的にはデメリットの部分が気になってしまいます。
 特に、Problemに話題が集中してお通夜のような雰囲気となってしまえば、「振り返り」自体にネガティブなイメージを持つことに繋がりかねません。
@@ -147,8 +148,8 @@ KPTで振り返りをした個人の感想としては、以下のようなも
 
 https://www.shoeisha.co.jp/book/detail/9784798165387
 
-* 社内やチームの出来事を時系列で付箋に書き出す
-* メンバーごとに時系列に対する「感情グラフ」を書き出す
+- 社内やチームの出来事を時系列で付箋に書き出す
+- メンバーごとに時系列に対する「感情グラフ」を書き出す
 
 ことが大きな特徴です。今回は会議室でホワイトボードでやったのですが、イメージとしては以下のようなものとなります。
 
@@ -162,8 +163,8 @@ https://www.shoeisha.co.jp/book/detail/9784798165387
 
 ■前準備
 
-* 振り返り会の前日、チームメンバーに時系列で発生したイベントをざっと書き出してもらう(スプレッドシートを使用しました)
-* 振り返り会の開催直前、ホワイトボードにチーム単位/時系列の枠を書き出す。また、時間節約のためわかっているイベントは付箋として張り出しておく
+- 振り返り会の前日、チームメンバーに時系列で発生したイベントをざっと書き出してもらう(スプレッドシートを使用しました)
+- 振り返り会の開催直前、ホワイトボードにチーム単位/時系列の枠を書き出す。また、時間節約のためわかっているイベントは付箋として張り出しておく
 
 ■実施手順
 
@@ -190,15 +191,15 @@ https://www.shoeisha.co.jp/book/detail/9784798165387
 
 ■Good
 
-* 時系列で振り返ることで、イベント・メンバーの感想を網羅して洗い出すことができた
-* 感情グラフを作成することで、チームのモチベーションを高く維持するためにはどうすればよいのか？ということまで検討できた
-* 関わりが少ないチームメンバーについても、タスク内容やモチベーションを共有することができた
-* 振り返り会の中で、極端にネガティブな雰囲気とならなかった(※実施したチームメンバーが良かったこともありますが)
+- 時系列で振り返ることで、イベント・メンバーの感想を網羅して洗い出すことができた
+- 感情グラフを作成することで、チームのモチベーションを高く維持するためにはどうすればよいのか？ということまで検討できた
+- 関わりが少ないチームメンバーについても、タスク内容やモチベーションを共有することができた
+- 振り返り会の中で、極端にネガティブな雰囲気とならなかった(※実施したチームメンバーが良かったこともありますが)
 
 ■Bad
 
-* 事前準備が必要になる
-* 実施自体に時間がかかる。とくに、タイムラインのレンジが広いほど実施時間がかかる
+- 事前準備が必要になる
+- 実施自体に時間がかかる。とくに、タイムラインのレンジが広いほど実施時間がかかる
 
 こうして考えると、チームメンバー間の共有や雰囲気作り、モチベーション設計の検討についてはかなり有意義な手法ではないかと思いました。