OmniAICreator/Qiita-1.07M huggingface dataset:
finch vm start で "WSL_E_USER_VHD_ALREADY_ATTACHED" が発生したら

確認環境

* finch: v1.1.1
* WSL: 2.0.14.0
    * kernel: 5.15.133.1-1

## 論よりコード

`finch vm start` で `WSL_E_USER_VHD_ALREADY_ATTACHED` が発生したら...

```powershell
dir $env:LOCALAPPDATA\.finch\.disks\*.vhdx
wsl --unmount $env:LOCALAPPDATA\.finch\.disks\{見つけたvhdxファイル}
```

これで `finch vm start` できるはずです。

#### 例:

```powershell
dir $env:LOCALAPPDATA\.finch\.disks\*.vhdx
#
#    Directory: C:\Users\***\AppData\Local\.finch\.disks
#
#Mode                 LastWriteTime         Length Name
#----                 -------------         ------ ----
#-a---          2024/02/06     1:28     3359637504 6b456cb759bdbc3f.vhdx
wsl --unmount $env:LOCALAPPDATA\.finch\.disks\6b456cb759bdbc3f.vhdx
#この操作を正しく終了しました。
```

## 概要

Finch の Windows 実装は、containerd 等が入った WSL ディストリビューション "lima-finch" を WSL 上で動かして実現しています。vhdx ファイルは "lima-finch" そのものです。そのため lima-finch ディストリビューションを動かしておく必要があります。
※ ちなみに finch コマンドは、lima-finch 上の各 daemon とソケット通信(sshかな？)する仕組みです。

しかし v1.1.1では `finch vm init` もしくは `finch vm start` で起動した lima-finch ディストリビューションは、実行後にプロンプトこそ表示されますがフォアグラウンドで動いている状態です。すなわち、当該ウィンドウを閉じると WSL ディストリビューションが終了してしまいます。
※ Bash の `&` 付きで起動したプロセスと同様です。

lima-finch ディストリビューションの正しい終了の仕方は `finch vm stop` です。この中では `wsl.exe --unmount *.vhdx` を行っています。逆に `finch vm start` では、unmount されていることを前提に vhdx ファイルをマウントを試みます。

ウィンドウを閉じて終了をすると unmount されず、そこに `finch vm start` の mount が実行されたところで失敗 (`WSL_E_USER_VHD_ALREADY_ATTACHED`) しているのが、今回の背景です。

```powershell:起動できない
finch vm start
# time="2024-02-06T01:28:46+09:00" level=info msg="attaching disk at path: C:\\Users\\****\\AppData\\Local\\.finch\\.disks\\6b456cb759bdbc3f.vhdx"
# time="2024-02-06T01:28:46+09:00" level=fatal msg="could not attach persistent disk: failed to attach disk: exit status 0xffffffff, command output: ディスク '\\\\?\\C:\\Users\\****\\AppData\\Local\\.finch\\.disks\\6b456cb759bdbc3f.vhdx' を WSL2 にアタッチできませんでした: Error: 0x80040312\r\nError code: Wsl/Service/AttachDisk/MountVhd/WSL_E_USER_VHD_ALREADY_ATTACHED\r\n"
```

そこで `finch vm stop` が行うはずだった unmount をすることで、`finch vm remove` と `finch vm init` をせずとも回復できるというのが今回の趣旨です。

`finch vm start` 時の `wsl.exe --mount` のエラーハンドリングを強化してあげれば解決できそうなので、issue を立てておこうと思います。

### どうやって調べた？

`--debug` 付きでの実行と、ソースコード

### 気になる

`wsl.exe --mount` を実行しているのは [disk_windows.go/EnsureUserDataDisk]( https://github.com/runfinch/finch/blob/52fb8b2fe5fb4523076a4bfbd2da8861df120adf/pkg/disk/disk_windows.go#L46) だが、[その呼び出し元](https://github.com/runfinch/finch/blob/52fb8b2fe5fb4523076a4bfbd2da8861df120adf/cmd/finch/virtual_machine_start.go#L83)  を見ると `TODO: don't run this on Windows` って書いてある😂

## あとがき

このくらいは、調べておきたいし、issue を立てるあたりまでやっておきたいね。

[EoT]
1.Amazon Web Servicesの基礎知識

AWSクラウドエンジニアのロードマップに沿って、
学習内容をまとめて知識を確立していきたいと思う。

本日は
一周目として
【Amazon Web Servicesの基礎知識について】①

1.Webサーバーとは
2.オンプレミスとクラウドサーバーの違い

以上2点を学習のポイントとしてまとめることとする。


1.サーバーとは

そもそもサーバーとはどんな意味なのか？調べてみると
給仕する人　サービスを提供するといった意味が出た。
ウォーターサーバーも水を提供するものである。

水が欲しいとき、ボタンを押すと、水が出る。
この一連の動きがウォーターサーバーの働きになる。

ウォーターサーバーの話とwebサーバーの話を混ぜて
以下の図を書いてみた。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2653198/a0a7c12a-b5ed-cc00-8c8e-23a62ca76f76.png)

このようにクライアントの要望するリクエストに対して
必要な処置を行うコンピュータをサーバーという。

2.オンプレミスとクラウドコンピューティングの違い

スパイ映画では
コンピューターがラック詰めされた部屋に侵入し、
企業の重要な情報を盗み取るシーンがある。
これの部屋がデータセンターというもので、
このデータセンターにサーバーは配置されている。
(他にもストレージやネットワーク機器もここに用意されている。)

データセンターは厳重なセキュリティと温度管理、
補助電源等の電源確保のシステムが確立されている。
このように企業が自社のサーバーやストレージ、
ネットワーク機器を物理的に管理する運用をオンプレミスという。

これに比べて
AWSのように自社でデータセンターを持たずにリソースを間借りして、
クラウドでサーバーやストレージ、ネットワーク機器運用することを
クラウドコンピューティングという。

AWSクラウドコンピューティングの利点は以下の通り
1.固定費から変動費へ
従量課金制であること(利用した分だけお金がかかる)

2.規模の経済(スケールメリット)
AWSでは数十万人以上のユーザーが利用することによって
年々利用料の値下げが行われている。

3.キャパシティ予測が不要
リソースの設定が用意(後から増設が簡単)

4.速度と俊敏制の向上
即時利用可能(数分で設定が終わる)

5.データセンターの運用や保守への投資が不要
設備への時間やお金の投資を必要としない。
→ソフトウェア自体の開発に集中できる。

6.グローバル化を即座に実現
グローバルインフラであるため世界中のどこの環境にも適用できる。

+α 技術の標準化(サービスの充実により共通言語が多い)
ECSを使ったLaravelの本番環境をざっと理解する

## なぜこの記事を書いたか？
Laravelの場合、ローカル環境ではphp artisan serveのような簡易サーバを使えば画面が見えます。しかし、本番環境の場合こんなに簡単ではないです。

初心者の自分としては意外とサーバ構築が複雑だったので、一回クライアントからのリクエストがあった際に画面が見えるまでの仕組みをきちんと理解しておこうと思い、本記事を書きました。

本記事では省略しているルートテーブルやNATゲートウェイ、セキュリティグループなどまだ色々設定することはありますが、今回の目的はリクエストの流れを簡潔に追うことにしたいので、大まかな流れの説明をしようと思います。
(Laravelに関連して、本番環境のデプロイでcorsエラーと戦った記録: 
https://qiita.com/tryuuu/items/c6969b00e24b3a0a4914)

## 使用技術
#### バックエンド
Laravel(11.x)
#### フロントエンド
Vue.js
#### サーバサイド
Docker, ECS on Fargate, ALB, nginx
#### データベース
RDS

## ファイル構成
Laravelをサーバにデプロイする際のよく見かけるような構成です。

フロントページの表示にVue.jsを使っているので、nginx/Dockerfileにおいてnpm run buildを行い、生成された静的ファイルをLaravelのpublic配下に配置するようにしています。この状態のイメージをECRに登録します。
php/Dockerfileの方も同じようにビルドしてイメージをECRに登録します。
これらのイメージをECSのタスク定義において参照することで使用します。

![名称未設定.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3474661/527aa8cf-5c91-810c-7071-199725cd1de2.png)



## サーバ構成
以下のような構成になります。

![nippou.drawio (5).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3474661/0152d49d-159b-257e-c07b-15da03a71039.png)


## リクエストの流れ
エンドユーザからのリクエストがあったときの大まかな流れとしては、
1. インターネットゲートウェイを通じてVPC外からのリクエストをVPC内に通す

2. ロードバランサー(HTTPの場合ポート80、HTTPSの場合ポート443)によるリクエストの分散→ECS on Fargateで実行されているサービス(nginxコンテナ)にリクエストを転送

3. nginxコンテナ(ポート80)でリクエストを受け取り、ビルドされpublic配下に置かれている静的ファイル(Vue.js)をレスポンスとして返し、画面を表示する(nginxは元々静的ファイルの配信が得意)

4. 動的処理(Laravel)が必要な部分はnginxからphpコンテナ(ポート9000)にリクエストを転送(nginxがリバースプロキシとして機能)

5. php-fpmによりphpの実行を行い動的な処理を行う

6. 生成されたコンテンツをnginxを通じてクライアントに伝送
 
ざっと図で上記の説明を補足するとVPC内部はこのような処理になります。
(参考: https://cloudonaut.io/how-to-dockerize-your-php-application-for-aws-fargate/)

![補足.drawio (3).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3474661/29be76c4-977f-0a2c-5ffb-e352f0f8357a.png)


## (補足)nginxとphp-fpmコンテナ間の通信
ECS on Fargateで同じタスク内に二つのコンテナがある場合、**localhost**で通信することができます。
nginxはリバースプロキシとして機能し、動的な処理が必要なリクエストはphpコンテナに転送します。nginxにはphpのモジュールがないためです。
従って、nginxはphp-fpmに対してphpの実行を依頼する、という形式を取るわけです。

この際、nginxとphpコンテナ間の通信では、FastCGIのインターフェースであるphp-fpmへリクエストを転送します。phpファイルをFastCGI(php-fpm)で接続するように設定するなどの操作をnginx/*.confで記述します。
　一例として、
 `fastcgi_pass localhost:9000;`
 といった記述は、nginxがphpファイルの実行をFastCGIサーバに委ね、localhost:9000で9000番ポートでリッスンしているphp-fpmに接続をする、という意味です。
(参考: https://www.spiceworks.co.jp/blog/?p=12317)

## まとめなど
結構個人的にはこのようなサーバ構築においては、一度で全部理解しようとするのではなく(天才を除き)、まず大まかな流れをきちんと把握してから細かいところを詰めていく、という勉強の仕方が良いのではないかと思っています。
今後は監視・CI/CDパイプラインの作成を行なっていきたいと思っています。
ここまで読んでくれた方、ありがとうございました。
【flutter】よく使う用語をおさらいしたい！！！

こんにちは！
今回は今までflutter開発をしてきた中でよく使う用語5選を紹介したいと思います！
今回も最後まで読んでいただけたら嬉しいです！

## 1,widget(ウィジェット)
FlutterにおけるWidget（ウィジェット）は、画面上のビューを構築するための基本的な要素やコンポーネントです。Flutterでは、ほぼすべてのものがウィジェットとして表現されます。ウィジェットは画面上のレイアウト、要素、装飾、アニメーションなど、あらゆるものを表現するために使用されます。
Widget（ウィジェット）は画面上のビューの一部であり、テキスト、ボタン、コンテナ、行、列などがウィジェットとして表現されます。
Flutterのアプリケーションはウィジェットのツリーとして構築され、これらのウィジェットが組み合わさってアプリケーションのUIが形成されます。
```php
Widget myButton = ElevatedButton(
  onPressed: () {
    // ボタンが押された時の処理
  },
  child: Text('Click me'),
);

```

## 2,メソッド
メソッドはプログラム内で特定の処理を実行するための手続きや関数です。
DartやFlutterのコード内で、特定の処理を実行するためにメソッドが定義されます。
メソッドは関数とも呼ばれ、一連のコードをまとめて再利用可能にします。
```php
void myFunction() {
  // 何らかの処理を実行する
}
```

## 3,パラメーター
パラメーター（Parameter）は、関数やメソッドに渡される値や情報を指します。関数が呼び出される際に、特定の処理を行うために必要なデータを引き渡すために使用されます。パラメーターは関数の宣言やメソッドの定義において指定され、その関数を呼び出すときに実際の値が渡されます。
```php
void printMessage(String message) {
  print(message);
}

void main() {
  // 関数呼び出し時に引数（実際の値）を渡す
  printMessage("Hello, World!");
}
```
上記の例では、printMessageという関数がString messageというパラメーターを受け取り、その値を出力しています。main関数からprintMessageを呼び出す際に、実際のメッセージ文字列を引数として渡しています。


## 4,null許容
null許容を使用することで、nullに関連する潜在的なエラーや予測不可能な動作を減少させ、コードの信頼性を向上させることが期待されます。
### null許容の機能
1,null許容が有効なコードでは、変数の型に?を追加します。
```php
String? nullableString;
```
2,null許容型と非null型
null許容が有効な場合、変数の型は「null許容型」と「非null型」に分かれます。
String?はnull許容型で、Stringは非null型です。

3,非nullアサーション演算子
!を使用して、null許容型の変数を非null型に変換できます。ただし、これを使う際は変数がnullでないことを確認する必要があります。

4,null許容型の操作
null許容型の変数に対しては、nullチェックを行ったり、null条件演算子（?.）を使用して安全に操作できます。
```php
if (nullableString != null) {
  // nullでない場合の処理
}

var length = nullableString?.length;
```

## 5,リロード

Flutterの"リロード"は、コードやリソースの変更を検知し、それを即座に反映させるための機能を指します。Flutterの開発者がアプリケーションのコードを変更したり、リソースを更新したりした際に、手動でアプリケーションを再起動することなく変更を即座に確認できるようにするための仕組みです。

## 終わりに
以上で、記事の紹介を終わります！
今回も最後でも読んでいただき、ありがとうございます！
では、また次の記事で〜！
Enterprise Agile Forum 2024 に参加してみた

# このページについて

Enterprise Agile Forum 2024
～情報子会社・SIerがデジタル社会の共創パートナーになるために～
のイベントに参加しました。私自身の備忘のために感想をまとめておきます。

イベント概要はこちら。

https://www.agileleadershipsummit.org/

## 基調講演①　ちんもさん　「人がつくるソフト　～SIerがアジャイルになる旅について～」

大きなSI企業の中でアジャイルが広がっていくことについて、[ちんもさん](https://speakerdeck.com/chinmo)のアジャイル史をベースにした講演でした。アジャイルの立ち上げ→失敗→再度立ち上げ→徐々に拡大していく流れをとてもリアルに感じられました。
講演の中で一番刺さったのが「ファンタジーの力を求められる、OneTeamになるという「共同幻想」に合意、本気で目指す。そのためにも**受託側からは放棄してはいけない**」ということ。変えにくいこと・現実がある中で理想を目指すからこそ、目指す立場から放棄してはいけないのだなと耳が痛い話でした（~~引っ張る存在が妥協してちゃ、そりゃ周りもついてこないよなぁと~~）
講演者はみんな神みたいな存在だと思っていますが、それでもうまくいかないこともあるというのが新鮮な驚きでした。

### 学び
- チェンジエージェントの心理：変えにくいからこそ挑む
- 人を増やすことだけでなく増やさないことにも注力
- 社内事例発表→他のチェンジエージェントともつながり拡大
- 概念としてのブチョー
- エバンジェリスト就任：名前が付くことで役員や他部署の人が呼びやすくなった
- 現実がある中で理想を目指すファンタジーの力が必要
- バックオフィスの改革はバックオフィスにいたアジャイルエバンジェリストと結びつき、改革を加速
- 20年でうまくいかないこともある、それでもいつか増える
	- →荒野をアジャイルにするのはいつもチェンジエージェント
- 協働というより協働体験の蓄積（あの時一緒にあれやったね、など成功していない体験でも良い）


## 基調講演②　横塚さん 「ビジネス×アジャイルなら　イノベーションを創造できる」

横塚さんは日本企業のビジネスの問題という切り口で、価値創造ができないことの原因とその解決策の話についての講演でした。
多くの大企業で本質的なDXができていないことについて、課題を見つけるプロセスやそのスキルが無いなど視座の高い話が聞けました。「システム開発さえアジャイルをやらない会社は見捨てる」とまで言い切るくらい、変革しないと未来がないのだと強く感じました。

### 学び
- 新しい価値の創造や価値創造がマネジメントできない
    - 解決策は自律したプロ人材がアジャイル**するしかない**
- 各人がプロとしての能力を生かし、組織の忖度なしで真の問題を探る
- 議論ではなく対話をとことん行う　←　議論と対話の違いを深堀出来なかった（後悔）
- 企業に対して今の認知をUNLOCKするプロ人材

## 午後：OST(Open Space Technology)

午後はOST形式で、計4つのカンファレンスに参加しました。

### OST1：アジャイルでよくある失敗を共有したい
失敗談をふせんに書き出してみたら、全員出るわ出るわと、ボートに収まりきらないくらいでてました。改めて眺めてみると、アジャイルの失敗というけれど、WFでも失敗してたよね、の内容もあって面白かったです。
失敗談に「社内でOSTやったけどテーマが出なかった」というのがあり、社内でOSTにチャレンジしてみたこと自体が凄すぎて脱帽してました。

### OST2：ファンタジーの作り方
ちんもさんテーマ。アジャイルの理想と現実のすり合わせ方について。
プラクティスで話をしていた時に「体制図でメンバー間の関係性を書いたものって恋愛相関図みたいだよね」というコメントからしばらく盛り上がりましたｗ
（でも恋愛相関図と表現するのはとてもいいメタファーだと思う）
ファンタジーでうまくいっていても、現実に引き戻されることがあり、その時にどうするか？が悩ましい…

### OST3：アジャイル×マネジメント
OST1と近いテーマとして、PJの各フェーズでチーム・PJ・組織の切り口から何をやっている？をお互い出しあって話し合いました。
ここでの気づきは、PJのが見なければならない観点がめちゃめちゃ多い事。そしてスクラムは小さな単位で行っているからこそ、1チーム=1PJになりがちで、結果PMの仕事がスクラムチームに降ってくる（そしてSMがその業を負わされる）こと。SMにもやることがあるからこそ、PMの仕事を誰がどうこなしていくかを考えなければいけないなと学びになりました。

### OST4：WELL BEING GAME CENTER
タイトルの通り、チームで使えるゲーミフィケーションのプラクティスを体験する回でした。
- Improv Cards
    - 絵が描かれたカードを3枚配り、1枚ずつカードを出しながらストーリーを創造していく
    - 感想：
        - テーマと絵とつなげながら前の人とつながるストーリを考えるので、頭がとてもよく回る
        - スクラムのふりかえりとかにも使えそう
- 生き甲斐カード
    - 「私の好きなこと」についてカードを引いて、裏に書かれたテーマについて話す。周りはコーチ、メンターとして質問する（他に2つのテーマがあるが、時間の都合で１つのみ）
    - 感想：
        - 深いところを突く質問なので、赤裸々に話すことになる（例：幸せ、健康、仕事、人間関係、富について10段階評価）
        - 「しゃべるか」というカードを持っているけど、それに近い感じで人となりを知れるプラクティスだった


## その他つぶやき

OST形式のイベントに初めて参加しましたが、最初はめっっっちゃ緊張しました(；ﾟДﾟ)
「え？今からテーマを自分で出すの？」「変なテーマ出したらどうしよう？」とか、OST初めて & ぼっち参加ゆえの不安感が半端なかったです。
実際に始まってみると、同じテーマを持つ人で議論になるので結構盛り上がり、あっという間に時間終了でした。そして集中して話すから結構疲れてしまい、帰宅時には頭がクタクタ。
最初はどうなるか不安しかなかった状態ですが、それでもOSTに初めて参加できました。
ちょっとズレますが「テスト自動化で0と1とではまるで違う」という話を聞いたことがあります。今回経験したことで未経験の時の私とは~~きっと~~違うので、これを糧に頑張ろうと思います。

## 最後に
情報子会社、SIer向けのイベントということであまりない機会でしたが、とても得られるものが多いイベントでした。周りも同じ立場の人が多い中で、一緒に考える場があるのはとてもラッキーだったなと思います。
ありがとうございました！
【実践編】リスク管理計画｜ログイン機能

> ログインの機能について
「プロジェクト管理：リスク管理計画」を作成してください。
開発者のチームに対してどのような指導を行いますか？
重要なポイントを教えてください。
どのようなステップがありますか？

ログインの機能についての「プロジェクト管理：リスク管理計画」を作成し、開発者チームへの指導を行う際の重要なポイントとステップは以下の通りです。

# リスク管理計画の内容
### リスクの識別

ログイン機能に関連する潜在的なリスクを識別します。セキュリティ、機能の不具合、スケジュール遅延などのリスクを特定します。
### リスクの評価

各リスクの影響度と発生確率を評価し、リスクの重要度を決定します。高リスク、中リスク、低リスクなどの分類を行います。
### リスク対策の策定

各リスクに対する対策策定し、リスクを軽減または回避するためのアクションプランを作成します。セキュリティの向上、バックアッププランの作成などの対策を考えます。
### リスク監視と報告

プロジェクトの進行中にリスクを監視し、新たなリスクが発生した場合には適切に報告します。リスクの変動や対策の進捗を追跡します。
# 開発者チームへの指導ポイント
### リスクの共有

開発者チームにリスクの存在と重要性を共有し、リスク管理の重要性を認識させます。
### リスク対策の共同作業

開発者はリスク対策の策定と実施に参加し、リスクを軽減または回避するためのアクションを共同で考えます。
### リスク報告の仕組み

リスクの監視と報告の仕組みを確立し、リスクが発生した場合には迅速に関係者に報告できるようにします。
# リスク管理計画の作成ステップ
### リスクの識別

ログイン機能に関連するリスクを特定し、リスク一覧を作成します。
### リスクの評価

各リスクの影響度と発生確率を評価し、リスクの重要度を決定します。
### リスク対策の策定

各リスクに対する対策を策定し、アクションプランを作成します。
### リスク監視と報告の仕組みの設定

リスクの監視と報告の仕組みを設定し、リスクの状況を定期的に評価します。

リスク管理計画はプロジェクトの成功に向けて重要な要素であり、リスクを事前に識別し、適切な対策を講じることでプロジェクトのリスクを最小限に抑えます。開発者はリスク管理に協力し、プロジェクトの安定性と品質を確保します。
【実践編】プロジェクト計画書｜ログイン機能

> ログインの機能について
「プロジェクト管理：プロジェクト計画書」を作成してください。
開発者のチームに対してどのような指導を行いますか？
重要なポイントを教えてください。
どのようなステップがありますか？

ログインの機能についての「プロジェクト管理：プロジェクト計画書」を作成し、開発者チームへの指導を行う際の重要なポイントとステップは以下の通りです。

# プロジェクト計画書の内容
### プロジェクトの概要

プロジェクト計画書の冒頭に、ログインの機能についてのプロジェクトの概要を説明します。プロジェクトの目的、範囲、背景などを記述します。
### プロジェクトの目標と成果物

プロジェクトの具体的な目標と期待される成果物を明示します。ログイン機能に関する目標や期待される成果物を詳細に記述します。
### プロジェクトスケジュール

プロジェクトのスケジュールを計画します。ログイン機能の開発、テスト、デプロイメントなどのスケジュールを記載し、重要なマイルストーンを設定します。
### リソースと役割分担

プロジェクトに必要なリソース（人員、ツール、予算など）を明示し、それぞれの役割と責任を割り当てます。開発者、テスター、プロジェクトマネージャーなどの役割を明確にします。
### リスク評価と対策

プロジェクトに関連するリスクを評価し、それに対する対策を計画します。ログイン機能の開発やテストにおけるリスクとその対処策を記述します。
### 品質管理

ログイン機能の品質管理計画を策定します。テスト戦略や品質基準を設定し、品質を確保するための計画を明示します。
# 開発者チームへの指導ポイント
### 明確な目標設定

プロジェクト計画書でログイン機能に関する明確な目標を設定し、全ての開発者がその目標に向かって作業を行えるようにします。
### 役割と責任の明示

各開発者の役割と責任を明示し、プロジェクト全体の調整がスムーズに行えるようにします。
### リスク管理と品質保証

開発者にリスク管理の重要性を認識させ、品質保証の計画に従った開発を行うよう指導します。
# プロジェクト計画書の作成ステップ
### プロジェクトの概要の記述

プロジェクト計画書の冒頭に、ログイン機能についてのプロジェクトの概要を記述します。
### プロジェクトの目標と成果物の明示

プロジェクトの目標と期待される成果物を具体的に明示します。
### プロジェクトスケジュールの計画

プロジェクトのスケジュールを計画し、開発、テスト、デプロイメントなどのステップをスケジュールに組み込みます。
### リソースと役割分担の設定

必要なリソースと各メンバーの役割と責任を設定します。
### リスク評価と対策の計画

プロジェクトに関連するリスクを評価し、リスク対策を計画します。
### 品質管理計画の策定

品質管理計画を策定し、品質基準とテスト戦略を明示します。

プロジェクト計画書はプロジェクトの成功に向けて重要なガイドラインであり、全ての開発者がプロジェクトの進行状況を理解し、協力して取り組むための基盤となります。
ボタンタグのオンクリックイベントに、関数を設定するときの注意点

## 初めに
今回map関数内で`<button>`タグを設置して、onClickイベントでクリックしたら、関数を実行するという記述をしました。
ですがクリックしていないのに、勝手に関数が動き始めるというアクシデントが...


## 問題のコード
以下が勝手に動き始めたコードです。
`<button onClick={onClickDelete(index)}>削除</button>`
こちらはTodoアプリに埋め込まれているボタンで、削除ボタンをクリックしたらその項目(index番目)をTodoリストから削除する、という機能を持たせました。
ですが一度クリックをしたら、その後もどんどんと削除されます...

## 原因と解決方法
今回の原因となる部分は`{onClickDelete(index)}`この部分でした。
こちらの部分を`{() => onClickDelete(index)}`このように変更したところ、正常に動作しました。
`{関数名()}`としてしまうと、勝手に関数が実行されてしまうので注意が必要です。

## 終わりに
ボタンのクリック時に引数を持った関数を発火させる場合、自動で処理が行われるので注意が必要ですね！
ちなみに仮に引数なしの場合は`{onClickDelete}`で問題なく実装できそうです！
【実践編】運用マニュアル｜ログイン機能

> ログインの機能について
「リリースフェーズ：運用マニュアル」を作成してください。
開発者のチームに対してどのような指導を行いますか？
重要なポイントを教えてください。
どのようなステップがありますか？

ログインの機能についての「リリースフェーズ：運用マニュアル」を作成し、開発者チームへの指導を行う際の重要なポイントとステップは以下の通りです。

# 運用マニュアルの内容
### イントロダクション

運用マニュアルの冒頭に、ログインの機能についての概要と目的を説明します。
### システムへのアクセス

運用者がシステムにアクセスする方法やツールを明示します。管理コンソールへのログイン手順を提供します。
### ログインのモニタリング

ログインの機能におけるモニタリングやログの確認方法を説明します。異常なログインアクティビティの検出方法についても記載します。
### ユーザーアカウントの管理

ユーザーアカウントの作成、編集、削除などの管理手順を提供します。ユーザーアクセス権の設定方法も説明します。
### セキュリティ対策

セキュリティに関するガイドラインや対策方法を提供します。パスワードポリシーやセキュリティベストプラクティスについても説明します。
### 障害対応

ログインに関する障害発生時の対応手順や連絡先情報を提供します。運用者が障害を迅速に解決できるようにサポートします。
### バックアップと復旧

ログインデータやユーザーアカウント情報のバックアップ方法とデータ復旧手順を説明します。
# 開発者チームへの指導ポイント
### 運用者向けに書く

運用マニュアルは運用者を対象としており、技術的な専門知識を持たない人にも理解しやすく書かれるべきです。
### 具体的な手順

具体的な手順やスクリーンショットを使用して、運用者が実際に作業を行えるようにします。
### セキュリティ重視

ログイン機能のセキュリティに関する注意事項や対策を強調し、運用者にセキュリティ意識を持たせます。
運用マニュアルの作成ステップ
### イントロダクションの記述

運用マニュアルの冒頭に機能の概要と目的を説明します。
### システムへのアクセス手順の提供

運用者がシステムにアクセスするための手順やツールの提供を行います。
### ログインのモニタリング方法の説明

ログインのモニタリングやログの確認方法を詳細に説明します。
### ユーザーアカウントの管理手順の記述

ユーザーアカウントの作成、編集、削除などの管理手順を提供します。
### セキュリティ対策の説明

セキュリティに関するガイドラインや対策方法を説明します。
### 障害対応手順の提供

ログイン関連の障害発生時の対応手順や連絡先情報を提供します。
### バックアップと復旧手順の記載

ログインデータやユーザーアカウント情報のバックアップ方法とデータ復旧手順を記載します。

運用マニュアルは運用者がシステムを効果的に管理し、問題を迅速に対処できるようにサポートします。開発者は運用マニュアルを継続的に更新し、運用プロセスを円滑に維持します。
【AWS】S3-APIGateway-Lambda間リクエスト・レスポンス確認方法

## はじめに
CORSエラーなどが解消せず、
リクエスト/レスポンス情報を見たい経験はありませんか？

対応方法やエラー発生時の切り分けをまとめた備忘になります。

## 直面した問題
静的ホスティングしているS3からAPIGateway経由でLambdaを呼び出そうとした時に、
CORS関連のエラーが発生
> CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

## 結論
APIGatewayでCORS設定に必要な設定項目が不足していたためエラーが発生

## 確認方法
### ブラウザ開発者ツールによるリクエスト確認
1. F12を押下してブラウザに備わっている開発者ツールを表示
2. Networkを選択すると各リクエスト情報など通信ログが表示される
![2024-02-05_17h41_23.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1764568/0b733412-103a-5815-199c-649cbea6d6ee.png)
3. CORSエラーが発生している通信を選択
各タブの情報は以下の通りであり、レスポンス情報が取得できていないことがわかる。
この情報だけでは「S3」-「APIGateway」-「Lambda」いずれの間に問題があるのか不明。
`Headers`：ブラウザがサーバーに送信した情報（Request URL, Request Headers）とサーバーがブラウザに返信した情報（Response Headers）とステータスコードを確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1764568/f26f6776-8128-f0cb-21a1-5e78704e0532.png)
`Payload`：Request URLに含まれるパラメータを読みやすい形で確認できます。「view decoded」をクリックすることでURLエンコードされた内容も読める形で表示することができます
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1764568/129c78af-6dba-09db-5002-92d67ccf0890.png)

`Preview`：通信が返してきたリソースの画像などを確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1764568/ca1abb58-7456-1b73-b893-858f71cfbb5f.png)

`Response`：サーバーがブラウザに返したHTMLやJSファイルの内容やAPIのレスポンス情報など
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1764568/813f46a6-7731-3621-4a41-a72bca9d4ec6.png)

`Initiator`：この通信を発生させる元となった他のリクエストとコード、この通信が元で発生した別のリクエストを確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1764568/17558f2d-b6a8-9bf2-3c6d-24f73f23743c.png)


`Timing`：通信が発生・終了したタイミングとその間に何に時間が使われたのかを確認できます。各タイミングの意味はこちらを参照。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1764568/9694a3b3-a615-e7ad-77a1-8f88dec1393d.png)


### APIGateway-Lambda間の通信確認
1. AWSコンソール上APIGatewayトップページより「リソース」を選択
2. 通信を確認したいメソッドを選択し、「テスト」タブを選択
3. 「クエリ文字列」「ヘッダー」「リクエスト本文」を入力
ここではS3からAPIGateway経由でLambdaにリクエストを行うための情報を入力。
入力内容はS3側の静的ページに記載のheaderとbody情報でよい
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1764568/c6d3f20c-5161-9abd-1e15-522d77f7957d.png)
4. テスト実施
この実施結果が想定通りのため、「APIGateway」-「Lambad」間に問題がないことがわかる。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1764568/3c06a01c-0ec5-4a6f-b04c-1e4abbb2f8f9.png)

### エラー情報のまとめ
開発者ツールのリクエストから「CORS」関連のエラーが確認でき、
「S3」-「APIGateway」間に問題があることがわかった。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1764568/6c646ace-9a9e-dba7-709d-336c592b95fa.png)

「APIGateway」「CORS」等で検索すると、APIGateway側でCORS設定の有効化が必要であるとわかる。
従って以下のような簡易的なCORS許可の設定を行う。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1764568/b7820596-8597-7260-35d7-1305da849cea.png)

上記設定を加えることで、リクエストの成功を確認。


また、`console.log(data);`のような記述をhtmlファイルに記載することで、
開発者ツールの`console`より変数や処理の中身を確認することができる

## 最後に
同様にエラー切り分け方法で悩んでいる人の助けになれば幸いです。


## 参考先
https://ayudante.jp/column/2022-12-01/15-00/#a2

https://qiita.com/att55/items/2154a8aad8bf1409db2b
【実装メモ】隣接リストモデルに基づくクエリサンプル

## 概要
**特定の組織のすべての子孫を取得するクエリ:**
隣接リストモデルでは、すべての子孫を取得するには再帰的なクエリやプログラムが必要です。SQL標準では再帰的なクエリをWITH RECURSIVEという構文で実行できますが、すべてのデータベースシステムがこれをサポートしているわけではありません。

**特定の組織のすべての先祖を取得するクエリ:**
こちらもWITH RECURSIVEを使用した再帰的なクエリが必要ですが、全てのデータベースで可能ではないため、アプリケーションコードで階層をたどることが一般的です。

隣接リストモデルは、単純な親子関係のクエリでは効果的ですが、複雑な階層クエリを実行するには再帰的な操作が必要であり、クエリが複雑かつ実行時間が長くなる可能性があります。閉包テーブルは、このような複雑な階層クエリを効率的に実行できるように設計されています。

## 実際のサンプル1

隣接リストモデルを用いた場合、特定の組織のすべての子孫や先祖を取得するためのSQLクエリは、データベースが再帰クエリをサポートしている場合には、再帰的共通テーブル式（Recursive Common Table Expressions: Recursive CTEs）を使用して実行できます。以下は、再帰クエリを使ったサンプルです。


**特定の組織のすべての子孫を取得するクエリ:**

```sql
WITH RECURSIVE Subordinates AS (
    SELECT org_id, org_name, parent_org_id
    FROM organizations
    WHERE org_id = 2 -- 例として財務部の子孫を取得
    UNION ALL
    SELECT o.org_id, o.org_name, o.parent_org_id
    FROM organizations o
    INNER JOIN Subordinates s ON o.parent_org_id = s.org_id
)
SELECT org_name FROM Subordinates WHERE org_id != 2;

```

**特定の組織のすべての先祖を取得するクエリ:**

```sql

WITH RECURSIVE Ancestors AS (
    SELECT org_id, org_name, parent_org_id
    FROM organizations
    WHERE org_id = 4 -- 例として経理の先祖を取得
    UNION ALL
    SELECT o.org_id, o.org_name, o.parent_org_id
    FROM organizations o
    INNER JOIN Ancestors a ON o.org_id = a.parent_org_id
)
SELECT org_name FROM Ancestors WHERE org_id != 4;

```

これらのクエリは、PostgreSQLやMySQL 8.0以降など、再帰クエリをサポートするデータベースシステムで動作します。WITH RECURSIVEは再帰的共通テーブル式を構築し、UNION ALLを使用して再帰的に自己を参照します。


## 実際のサンプル2


再帰的共通テーブル式（Recursive CTE）は、あるレコードに関連するレコードを階層的にクエリする際に使用されるSQLの強力な機能です。一般的な用途としては、階層データやグラフデータの探索に使われます。

再帰クエリは2部分から成り立っています：

**アンカー部分：**
再帰の基点となる初期クエリです。通常、階層の最上位レベルまたは特定の出発点を選択します。

**再帰部分：**
アンカー部分から得られた結果を使用して、自身を再帰的に参照するクエリです。

以下は、階層データを再帰的にクエリするためのシンプルな例です。
この例では、会社の組織構造をクエリするために使用されます。
会社には「CEO」がおり、その下に「部門マネージャー」がいて、さらに「チームリーダー」がいます。

```sql

WITH RECURSIVE EmployeeHierarchy AS (
    SELECT
        EmployeeID,
        EmployeeName,
        ManagerID,
        0 AS Depth -- アンカー部分での深さは0
    FROM
        Employees
    WHERE
        ManagerID IS NULL -- 最上位の従業員（例えばCEO）

    UNION ALL

    SELECT
        e.EmployeeID,
        e.EmployeeName,
        e.ManagerID,
        eh.Depth + 1 -- 再帰部分での深さは、一つ上のレベルの深さに1を加える
    FROM
        Employees e
    INNER JOIN EmployeeHierarchy eh ON e.ManagerID = eh.EmployeeID
)
SELECT * FROM EmployeeHierarchy;

```

このクエリは、まずManagerIDがNULLである従業員（CEO）を選択します（アンカー部分）。その後、UNION ALLを使用して、Employeesテーブルに再帰的に参加し、各従業員のManagerIDが前の結果のEmployeeIDと一致するすべての従業員を選択します（再帰部分）。
Depthフィールドは階層の深さを表し、各再帰ステップで1ずつ増加します。


このクエリの結果は、企業の全従業員をCEOから最下位の従業員までの階層構造として返します。各従業員のレコードには、その従業員のID、名前、上司のID、およびその従業員が
階層内のどの深さにいるかが含まれます。
【JavaScript】配列から条件に一致する要素を取得する方法

## 条件に一致する最初の要素を取得

`find`を使用して以下のように記述すると条件に一致する最初の要素を取得できます。

```js
const array = [10, 20, 40, 30, 60];
const sampleFind = array.find((element) => element >= 35)
console.log(sampleFind) //　40
```

https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array/find

## 条件に一致する要素の配列を取得

`filter`を使用すると条件に一致する要素の配列を取得できます。

```js
const array = [10, 20, 40, 30, 60];
const sampleFilter = array.filter((element) => element >= 35)

console.log(sampleFilter) // [40, 60]
```

https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array/filter
リリースバージョン毎のエラー数変化を楽々追跡！

1日に複数回リリースを行うような開発を行われているシステムが増えています。
開発中からAPMを使ってエラーを捕捉しデバックしていても、今発生しているエラーがいつのバージョンで発生しているのかわからない or 確認に時間がかかってしまうのは勿体無いですよね？

そんな時に便利な、発生しているエラーのリリースバージョンを特定しやすく機能が、New RelicのErrors Inboxに新しく追加されました！

:::note info
このアップデートの詳細はこちら。
[New Relic アップデート(2023年11月)](https://newrelic.com/jp/blog/nerdlog/new-relic-update-202311)
[New Relic アップデート](https://newrelic.com/jp/blog/nerdlog/new-relic-update "New Relic アップデート")
:::

## 設定方法
Errors Inboxでバージョン情報を収集するためには、APM および OpenTelemetry アプリケーションで次のイベント フィールドを追加する必要があります。下記の順番で表示されます

service.version
tags.service.version
tags.releaseTag
tags.commit

モバイル アプリケーションの場合、イベント フィールドは `appVersion`。
ブラウザ アプリケーションの場合、イベント フィールドは `application.version`。

各言語毎の設定方法に関しては下記リンク先のドキュメントをご参照ください。

Open Telemetry は [`service.version`](https://docs.newrelic.com/docs/more-integrations/open-source-telemetry-integrations/opentelemetry/best-practices/opentelemetry-best-practices-resources/)

APM は以下
[Go](https://docs.newrelic.com/docs/apm/agents/go-agent/api-guides/guide-using-go-agent-api/#error-fingerprinting)
[Java](https://docs.newrelic.com/docs/apm/agents/java-agent/api-guides/java-agent-api-register-error-group-callback-to-set-fingerprint/)
[.NET](https://docs.newrelic.com/docs/apm/agents/net-agent/net-agent-api/seterrorgroupcallback-net-agent-api/)
[Node.js](https://docs.newrelic.com/docs/apm/agents/nodejs-agent/api-guides/guide-using-nodejs-agent-api/#errors)
[Python](https://docs.newrelic.com/docs/apm/agents/python-agent/python-agent-api/seterrrorgroupcallback-python-agent-api/)
[Ruby](https://docs.newrelic.com/docs/apm/agents/ruby-agent/api-guides/sending-handled-errors-new-relic/#error-fingerprinting)

mobile は [`appVersion`]()
browser は [`application.version`]()



## できること
Errors Inbox に収集されたエラーの中に「Occurrences by version」が追加され、バージョンごとのエラーを確認できるようになっています
Change Trackingを使用してデプロイメントを設定している場合は、このグラフにデプロイメント マーカーが表示されます。これらのマーカーは、各デプロイメントがいつリリースされたかを示しています。
マーカーをクリックするとデプロイメントの詳細画面に遷移することも可能です。

![スクリーンショット 2024-02-05 22.23.46.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/313446/23a7e4f2-229d-3a71-3b0a-7f02d46bcbb9.png)

バージョン情報を取得できるようになると、エラーグループからアプリケーションのバージョン毎でフィルタリングも可能になり、絞り込んだ確認が可能になります。

![スクリーンショット 2024-02-05 22.50.19.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/313446/d96608ca-cea3-8ed2-3824-bd7e6fcf4d17.png)

とても便利！


## まとめ
この機能を使うことによって下記のようなメリットがあります

<B>根本原因の迅速な特定</B>: エラーが最初に発生したコード リリースのバージョンを特定することで、エラーの発見ではなくコードの修正に集中できます。
<B>問題解決の加速</B>: 問題の検出、特定、解決に必要な手順と画面を削減し、労力を軽減します。
<B>リアルタイムのエラー可視性</B>: 最近のソフトウェア リリースによって導入された新しいエラーの最新の概要を取得し、顧客に影響を与える前に問題を先取りします。

是非この機能をご活用ください！！


:::note info
このアップデートの詳細はこちら。[New Relic アップデート(2023年11月)](https://newrelic.com/jp/blog/nerdlog/new-relic-update-2023１1)
:::
:::note info
無料のアカウントで試してみよう！
[New Relic フリープランで始めるオブザーバビリティ！](https://qiita.com/ktst79/items/5ee74b34e6adb8a7a6fa)
:::
:::note info
[New Relic株式会社のQiita Organization](https://qiita.com/organizations/newrelic)では、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。
:::
【実践編】ユーザーマニュアル｜ログイン機能

> ログインの機能について
「リリースフェーズ：ユーザーマニュアル」を作成してください。
開発者のチームに対してどのような指導を行いますか？
重要なポイントを教えてください。
どのようなステップがありますか？

ログインの機能についての「リリースフェーズ：ユーザーマニュアル」を作成し、開発者チームへの指導を行う際の重要なポイントとステップは以下の通りです。

# ユーザーマニュアルの内容
### イントロダクション

ユーザーマニュアルの冒頭に、ログインの機能の概要と目的を説明します。
### アクセス方法

ユーザーがログイン機能にアクセスする方法や手順を明示します。
### ログイン手順

ユーザーがログインするためのステップバイステップの手順を提供します。ユーザー名、パスワード、認証方法などを説明します。
### パスワードのリセット

ユーザーがパスワードをリセットする方法や手順を説明します。
### セキュリティガイドライン

ログイン機能のセキュリティに関するガイドラインやベストプラクティスを提供します。パスワードの強化、セキュアなログイン方法などを説明します。
### トラブルシューティング

ユーザーがログインに関する問題に遭遇した場合のトラブルシューティングガイドを提供します。一般的な問題とその解決策を列挙します。
### よくある質問（FAQ）

ユーザーから寄せられるよくある質問とその回答を掲載します。
### 連絡先情報

ユーザーがサポートに連絡するための情報を提供します。サポートチームの連絡先やオンラインヘルプデスクへのリンクを含めます。

# 開発者チームへの指導ポイント
### ユーザーフォーカス

ユーザーマニュアルはユーザーの立場から書かれるべきです。ユーザーが理解しやすく、実際の操作をサポートする内容を提供します。
### ステップバイステップの説明

ログイン手順やパスワードリセット手順はステップバイステップで説明し、画像や図を使用して視覚的に理解しやすくします。
### セキュリティ意識の強調

ユーザーマニュアル内でセキュリティに関する重要性を強調し、ユーザーにセキュアなログイン方法を教育します。
# ユーザーマニュアルの作成ステップ
### イントロダクションの作成

ユーザーマニュアルの冒頭にログイン機能の概要と目的を説明します。
### アクセス方法の記述

ユーザーがログイン機能にアクセスする方法や手順を記述します。
### ログイン手順の詳細な説明

ユーザーがログインするためのステップバイステップの手順を詳細に説明します。
### パスワードのリセット手順の記載

ユーザーがパスワードをリセットする方法や手順を記載します。
### セキュリティガイドラインの提供

ログイン機能のセキュリティに関するガイドラインやベストプラクティスを提供します。
### トラブルシューティングガイドの作成

ユーザーが問題に遭遇した場合のトラブルシューティングガイドを作成します。
### よくある質問（FAQ）の追加

ユーザーからのよくある質問とその回答を追加します。
### 連絡先情報の提供

サポートに連絡するための情報を提供します。

ユーザーマニュアルはユーザーの利便性と満足度を向上させ、ログイン機能を効果的に利用できるようにサポートします。開発者はユーザーマニュアルの作成と更新を通じて、ユーザーに価値を提供します。
みんな大好きカオスエンジニアリング

みんな大好きカオスエンジニアリング。
令和５年度の情報処理安全確保支援士の午前２で出ました。一生忘れられません。

## カオスエンジニアリングとは
カオスエンジニアリングは、大規模な分散システムの耐障害性を評価し、向上させるための実践的な手法です。このアプローチでは、システムの安定性と信頼性を意図的にテストするために、プロダクション環境で予期せぬ状態や障害を模倣します。カオスエンジニアリングの目的は、システムが予期せぬ問題にどのように反応するかを理解し、その結果を基にシステムの弱点を特定して修正することにあります。これにより、システムの全体的な耐障害性が向上します。

## メリット
1. システムの弱点の特定
カオスエンジニアリングによって、システムやアプリケーションの隠れた弱点や脆弱性を発見し、修正することができます。これにより、未知の問題が実際の障害となる前に、予防的な措置を講じることが可能になります。
2. 耐障害性の向上
実際の障害を模倣することで、システムが実際の障害状況にどのように対応するかを理解し、耐障害性を向上させることができます。これにより、システムが障害に対してより強固になり、ダウンタイムを最小限に抑えることができます。
3. 信頼性と可用性の向上
システムの弱点を特定し、修正することで、システムの全体的な信頼性と可用性が向上します。これは、ユーザー体験の向上に直結し、ビジネスの継続性を支える要因となります。
4. インシデント対応の強化
カオスエンジニアリングは、インシデント発生時の対応プロセスをテストし、強化する機会を提供します。これにより、チームは実際の障害発生時に迅速かつ効果的に対応できるようになります。
5. チームのスキル向上
カオスエンジニアリングのプロセスを通じて、チームメンバーはシステムの深い理解を得ることができます。また、障害対応のスキルを向上させ、チームワークを強化することができます。

## 歴史
カオスエンジニアリングの概念は、2010年代初頭にNetflixで形成され始めました。当時、Netflixは自社のサービスの信頼性を高めるために、プロダクション環境で意図的に障害を発生させる実験を開始しました。このアプローチの目的は、システムが潜在的な障害に対してどのように反応するかを理解し、その耐障害性を向上させることでした。

 ## カオスエンジニアリングの基本原則
1. システムの複雑性理解：分散システムは非常に複雑であり、その振る舞いは予測が難しいことがあります。カオスエンジニアリングは、この複雑性を実際に体験し、理解するための方法を提供します。
2. 障害を前提：障害は避けられないものとして前提し、それに対処するための準備を常にしておく必要があります。カオスエンジニアリングは、障害が発生したときのシステムの振る舞いをテストし、改善するための実践です。
3. 実際の環境でのテスト：システムの真の耐障害性を理解するためには、実際のプロダクション環境でテストを行うことが重要です。これにより、理論上ではなく実際の負荷やデータに基づいた結果を得ることができます。
4. 小さな実験から始める：大規模な障害を一度に導入するのではなく、小さな実験から始めて徐々に範囲を広げていくことが推奨されます。これにより、リスクを最小限に抑えつつ、システムの弱点を段階的に特定し、修正することができます。

## 実践方法
1. 目標の定義
システムの耐障害性を向上させる具体的な目標を設定します。これは、特定のサービスの可用性を高める、レスポンスタイムを改善するなど、具体的な目標であるべきです。
2. 基準の設定
正常時のシステムパフォーマンスの基準を設定します。これには、通常のトラフィックパターン、応答時間、エラーレートなどが含まれます。
3. 仮説の立案
システムに特定の障害が発生した場合の挙動についての仮説を立てます。この段階では、「このサービスがダウンした場合、システムはリクエストを別のサービスに自動的にリダイレクトするはずだ」といった具体的な予測を行います。
4. 実験の設計
小規模から始め、影響を最小限に抑える実験を設計します。例えば、非ピーク時間にトラフィックの一部に対してのみ障害を導入するなどの方法があります。
5. 実験の実施
計画した実験を実施し、システムの反応を観察します。実験は、モニタリングツールを使用して細かく観察されるべきです。
6. 結果の分析と学習
実験の結果を分析し、仮説が正しかったかどうか、システムが期待通りに振る舞ったかを評価します。問題点や改善の余地が見つかった場合は、これを学習の機会とします。
7. 改善策の実施
実験から得られた知見をもとに、システムの修正や改善を行います。これには、コードの変更、インフラの再構成、新たな監視ツールの導入などが含まれます。
NextAuth.jsで実現するLINEログイン

## NextAuth.jsとは何か、及びそのメリット
NextAuth.jsは、Next.jsアプリケーション向けに設計された認証ライブラリです。サーバーサイドとクライアントサイドの両方で動作し、簡単にセットアップできることが特徴です。OAuth、Email、そしてJWT（JSON Web Tokens）など、多様な認証プロバイダーとの統合をサポートしています。

#### メリット
・簡単なセットアップ: Next.js環境に特化して設計されているため、数行のコードで認証システムを追加できます。
・柔軟性: 多数のOAuthプロバイダー（Google, Facebook, GitHubなど）に対応しており、カスタムプロバイダーも追加できます。
・セキュリティ: セキュアなJWTベースのセッション管理を提供し、CSRFトークンとHTTP Onlyクッキーを使用してセキュリティを強化します。
ユーザーフレンドリー: サインインとサインアウトのプロセスが簡単で、ユーザーエクスペリエンスを向上させます。
・サーバーレス対応: Vercelなどのサーバーレスプラットフォームで簡単にデプロイできます。

## LINEログインとは何か、及びそのメリット
LINEログインは、LINEのアカウントを使用して他のアプリケーションやウェブサービスにログインするためのシステムです。ユーザーはLINEの認証情報を使って、追加の登録プロセスを経ずにサービスを利用できます。

#### メリット:
・ユーザビリティの向上: 既存のLINEアカウントを使ってログインするため、新規登録の手間が省け、利用開始までのハードルが低くなります。
・セキュリティ: LINEログインはOAuth 2.0プロトコルを使用し、セキュアな認証プロセスを提供します。
・マルチプラットフォーム: スマートフォンアプリだけでなく、ウェブアプリケーションにも容易に統合できます。

# 実装方法

### 1. LINE Developersコンソールでのアプリケーション登録
a. LINE Developersサイトにアクセスします。 まず、LINE Developersサイトにアクセスし、アカウントを持っていない場合は作成します。
b. プロバイダーの作成: LINE Developersコンソールで「新規プロバイダー作成」をクリックし、プロバイダー名を入力します。プロバイダーは、アプリケーションの所有者や管理組織を指します。
c. チャネルの作成: プロバイダーを作成した後、「新規チャネル作成」を選択し、LINEログインを選びます。ここでアプリケーション名、アプリケーション説明、プライバシーポリシーURLなどの情報を入力します。

### 2. 認証情報の取得
チャネルを作成した後、チャネル基本設定ページから以下の認証情報を取得します。

Channel ID: アプリケーションを識別するためのID。
Channel Secret: アプリケーションの秘密鍵。認証時に使用されます。

### 3. コールバックURLの設定
コールバックURLの設定: アプリケーションやウェブサイトでLINEログインを利用する際、ユーザーがログイン認証後にリダイレクトされるURLを設定します。NextAuth.jsを使用する場合、通常は/api/auth/callback/lineのようなパスになります。

### 4. LINEログイン機能の統合
NextAuth.jsでLINEログインを統合するには、NextAuthの設定ファイルにLINEプロバイダーを追加します。この際、先ほど取得したChannel IDとChannel Secretを使用します。
```
// src/pages/api/auth/[...nextauth].ts
import LineProvider from "next-auth/providers/line"
import NextAuth from "next-auth"

export default NextAuth({
  providers: [
    LineProvider({
      clientId: process.env.LINE_CHANNEL_ID,
      clientSecret: process.env.LINE_CHANNEL_SECRET
    })
  ],
  callbacks: {
    session: async ({ session, token }) => {
      if (session?.user) {
        session.user.id = token.sub as string
      }
      return session
    },
  },
  session: {
    strategy: "jwt", 
  },
})

declare module "next-auth" {
  interface Session {
    user: {
      id: string
    }
  }
}
```

### 5. 環境変数の設定
```
// .env.local
LINE_CHANNEL_ID=あなたのチャネルID
LINE_CHANNEL_SECRET=あなたのチャネルシークレット
```

### 6. サインイン画面の作成
```
import { signIn, useSession } from "next-auth/react";

const SignInPage = () => {
  const { data: session } = useSession();

  if (session) {
    return (
      <div>
        <p>Hello, {session.user.name}!</p>
      </div>
    );
  }

  return (
    <div>
      <h1>サインイン</h1>
      <button onClick={() => signIn('line')}>LINEでログイン</button>
    </div>
  );
};

export default SignInPage;
```
【実践編】リリースノート｜ログイン機能

> ログインの機能について
「リリースフェーズ：リリースノート」を作成してください。
開発者のチームに対してどのような指導を行いますか？
重要なポイントを教えてください。
どのようなステップがありますか？

ログインの機能についての「リリースフェーズ：リリースノート」を作成し、開発者チームへの指導を行う際の重要なポイントとステップは以下の通りです。

# リリースノートの内容
### リリースのバージョン番号

リリースのバージョン番号を明示します。例：v1.0.0
### リリース日

リリースが予定されている日付または実際のリリース日を記録します。
### 新機能の概要

ログインの機能に追加された新機能や改善点を簡潔に説明します。
### 既知の問題

リリース時点で既知の問題やバグを列挙し、ユーザーに対して透明性を提供します。
### 変更点

前のバージョンと比較して、ログイン機能に対する変更点や修正内容を詳細に説明します。
### アップグレード手順

ユーザーや管理者が新バージョンにアップグレードする際の手順や注意事項を提供します。
### 連絡先情報

ユーザーが問題を報告したり、フィードバックを提供したりするための連絡先情報を提供します。
# 開発者チームへの指導ポイント
### 明確な情報提供

リリースノートはユーザーにとって理解しやすく、必要な情報を提供することが重要です。説明は簡潔で明確に行います。
### 既知の問題の誠実な共有

リリース時点で既知の問題やバグを正直に共有し、ユーザーに対して透明性を提供します。
### アップグレード手順の詳細

ユーザーや管理者が新バージョンにアップグレードするための手順を詳細に説明し、スムーズなアップグレードをサポートします。
# リリースノートの作成ステップ
### バージョン番号の設定

リリースのバージョン番号を設定します。
### リリース日の記録

リリースの予定日または実際のリリース日を記録します。
### 新機能の概要の記入

新機能や改善点について簡潔に記述します。
### 既知の問題の列挙

リリース時点で既知の問題やバグをリストアップします。
### 変更点の詳細な記述

ログイン機能に対する変更点や修正内容を詳細に説明します。
### アップグレード手順の提供

ユーザーや管理者がアップグレードを行うための手順や注意事項を提供します。
### 連絡先情報の記載

ユーザーが問題を報告したり、フィードバックを提供したりするための連絡先情報を提供します。

リリースノートはユーザーにとって新機能や変更点の理解を助け、アップグレードプロセスを円滑にします。開発者はユーザーやクライアントに向けてリリースノートを作成し、新バージョンの導入と利用をサポートします。
ECCメモリについて調べた

## 経緯

MINIFORUMのMS-01の記事を読んでいた。、
インストールするOSの選定で、下記が選択肢となっていた。

>・Ubuntu 22.04 LTSのデスクトップ版(Kernel 5.15 or 6.5)
>・Ubuntu 22.04 LTSのサーバー版(Kernel 5.15 or 6.5)
>・Ubuntu 23.10のデスクトップ版(Kernel 6.5)
>・Ubuntu 23.10のサーバー版(Kernel 6.5)

そこで、気になった記述があった。

>どうせ本格運用するなら、より新しいカーネルとソフトウェアセットのほうが気分が良い。もちろん安定>志向を目指すならUbuntu >> 22.04 LTSだが、安定志向を目指す人が(ECCメモリでもない)こんな装置を買>うわけがない。いや買いはするかもしれないが、安定性が求められるクリティカルな部分で使うことはな>いはずだ。たぶん。もしかするとそういう猛者も多少はいるかもしれない。多少どころかごろごろいそう>な気がしてきた。

おそらく、安定性が必要なサーバー向けの仕様ではないという事だろうと思うが、
ECCメモリってなんだったっけ？と思った。

サーバー向けのメモリはECCが付いているという漠然としたイメージはあったが、
何が違うのか明確に理解していなかった事に気付いた
明確化するために、ECCメモリについて調べた

## ECCメモリとは？

Error Check and Correct Memoryの略

データ破損を検出し、修復を行うメモリのことらしい。

エラー訂正機能により、長期稼働時のデータ化けや異常終了を防ぐ事ができる。

コンピュータ内部の電磁気的な干渉により、DRAMの１ビットが自発的に反転することがある。
これがメモリエラーと呼ばれるハードウェア障害だ。

メモリエラーはマシンのクラッシュを起こすもっとも一般的なハードウェア的原因の1つであるらしい。
そのため、長期稼働するサーバーなど、安定性が求められる場合にECCメモリを使うようだ。

訂正・検出方法が気になったが、
ハミング符号を用いているらしい。
応用情報技術者を取得した時に学んだ知識が繋がった。

## 参考

https://store.minisforum.jp/products/minisforum-ms-01

https://news.yahoo.co.jp/articles/f5bfead692c520f84bb0e4e39cfad977c25b136c

https://ja.wikipedia.org/wiki/ECC%E3%83%A1%E3%83%A2%E3%83%AA

https://kawauso-lab.hatenablog.jp/entry/2021/10/23/155044

https://ccmp.jp/technical-info/engineerblog/278-2013-11-29-08-17-32.html
【実践編】テスト結果報告書｜ログイン機能

> ログインの機能について
「テストフェーズ：テスト結果報告書」を作成してください。
開発者のチームに対してどのような指導を行いますか？
重要なポイントを教えてください。
どのようなステップがありますか？

ログインの機能についての「テストフェーズ：テスト結果報告書」を作成し、開発者チームへの指導を行う際の重要なポイントとステップは以下の通りです。

# テスト結果報告書の内容
### 報告書のタイトル

テスト結果報告書のタイトルを付け、報告の目的を明示します。
### 報告書の作成日

テスト結果報告書の作成日付を記録します。
### テスト実施概要

テストの実施範囲、期間、テスト対象の機能、テストケースの実行状況などを概要で説明します。
### テストケース実行結果

各テストケースの実行結果を記録します。正常、異常、未実施などのステータスを示します。
### 不合格テストケースの詳細

不合格と判定されたテストケースについて、問題点やバグの詳細情報を提供します。
### テスト環境情報

テストを実施した環境（ハードウェア、ソフトウェア、ブラウザなど）の情報を提供します。
### バグ報告

不合格と判定されたテストケースに関連するバグ報告を記録し、バグの重要度や緊急度を指定します。
### テスト結果の評価

テスト結果を評価し、ログイン機能の品質や安定性についての意見や提案を含めます。
### テスト結果の承認

テスト結果報告書を承認する責任者の署名と日付を記録します。
# 開発者チームへの指導ポイント
### テスト結果の明確な記録

テスト結果報告書はテストケースの実行結果を詳細に記録し、不合格のテストケースについて問題点を明示化します。
### 不合格テストケースの詳細な説明

不合格と判定されたテストケースに関連する問題やバグの詳細な説明を提供し、修正に役立つ情報を提供します。
### バグ報告の適切な提出

バグ報告はテスト結果報告書内に適切に記録し、バグの重要度と緊急度を適切に評価します。
# テスト結果報告書の作成ステップ
### 報告書のタイトルの設定

テスト結果報告書のタイトルを付け、報告の目的を明示します。
### 報告書の作成日の記録

テスト結果報告書の作成日付を記録します。
### テスト実施概要の記入

テストの実施範囲、期間、テスト対象の機能、テストケースの実行状況などをまとめて記述します。
### テストケース実行結果の記録

各テストケースの実行結果を正常、異常、未実施などのステータスで記録します。
### 不合格テストケースの詳細情報の提供

不合格と判定されたテストケースについて、問題点やバグの詳細情報を提供します。
### テスト環境情報の記入

テストを実施した環境に関する情報を提供します。
### バグ報告の評価と提出

不合格テストケースに関連するバグ報告を評価し、重要度と緊急度を設定して提出します。
### テスト結果の評価と承認

テスト結果を評価し、報告書を承認する責任者が署名と日付を記録します。

テスト結果報告書はテストの進捗状況と品質に関する情報を提供し、バグの早期発見と品質向上に貢献します。報告書は開発者とテスター間のコミュニケーションを円滑にし、問題の迅速な修正をサポートします。
【実践編】テストケース定義書｜ログイン機能

> ログインの機能について
「テストフェーズ：テストケース定義書」を作成してください。
開発者のチームに対してどのような指導を行いますか？
重要なポイントを教えてください。
どのようなステップがありますか？

ログインの機能についての「テストフェーズ：テストケース定義書」を作成し、開発者チームへの指導を行う際の重要なポイントとステップは以下の通りです。

# テストケース定義書の内容
### テストケースの識別子

各テストケースに一意の識別子（テストケースID）を割り当てます。
### テストケースのタイトル

テストケースの目的や内容を簡潔に表すタイトルを付けます。
### テスト対象の機能

テストケースが対象とするログイン機能の具体的な部分や機能を明示します。
### 前提条件

テストケースを実行するために必要な前提条件を列挙します。例えば、特定のユーザーアカウントが存在することなど。
### テストステップ

テストケースを実行するための具体的なステップを順番に記述します。各ステップは入力、アクション、期待結果を含めます。
### テストデータ

各テストステップに必要なテストデータ（ユーザー名、パスワードなど）を指定します。
### 期待される結果

各テストステップの実行後に期待される結果を明示します。正常な場合と異常な場合の結果を記述します。
### 備考

テストケースに関する追加情報や注意事項を記述します。
# 開発者チームへの指導ポイント
### テストケースの完全性

テストケースはログイン機能のすべてのシナリオを網羅するように設計します。漏れや重複がないことを確認します。
### テストデータの準備

開発者はテストデータを適切に設定し、各テストケースを実行するための環境を整えます。
### 期待される結果の明確化

テストケースごとに期待される結果を明示的に定義し、バグの早期発見をサポートします。
### テストステップの詳細

テストステップは具体的で詳細なアクションと期待結果を含めることで、誤解や誤解釈を防ぎます。
# テストケース定義書の作成ステップ
### テストケースIDの割り当て

各テストケースに一意のIDを割り当て、一覧を作成します。
### テストケースのタイトルの設定

各テストケースに対するタイトルを設定し、テストケースの目的を明確にします。
### テスト対象の機能の指定

テストケースが対象とするログイン機能の具体的な部分や機能を指定します。
### 前提条件の列挙

テストケースを実行するために必要な前提条件をリストアップします。
### テストステップの詳細な記述

各テストケースのテストステップを詳細に記述し、実行手順と期待結果を文書化します。
### テストデータの指定

各テストステップに必要なテストデータを指定し、テストケースの実行をサポートします。
### 期待される結果の明示化

各テストケースの期待される結果を明確に定義し、テストケースの成否を判断する基準とします。
### 備考の追加

テストケースに関する追加情報や注意事項を記述し、テスト実施時の支援を提供します。

テストケース定義書はテストの効率性と品質向上に貢献し、開発者とテスター間のコミュニケーションを円滑にします。開発者はこのドキュメントを参考にして、テストの実施を行います。
PowershellをSJIS環境下でも使ってみたい

## SJISの環境下でなにが不安かというと
削除リストをはいって渡されてSJISだったとき、どうしよう・・・

前回でも使ったNETライブラリのコードページから文字コードを指定してテキストを読み込めばいいのではないか？と思ったので、即席で関数を作成してみた。

```OperateDeletion.ps1
function OperateDeletion ($tgtDirectory){

    # [Step 0]: Create an empty log file
    Set-Content -Path $logFile -Value ""
    
    # [Step 1]: Set target directory
    
    # [Step 2]: Find list.txt file
    $listFile = Join-Path `
                    -Path $tgtDirectory `
                    -ChildPath "\..\list.txt"
                    
    $logFile = Join-Path `
                    -Path $tgtDirectory `
                    -ChildPath "\..\DELETE_FROM_LIST.log"
                    
    $flg = 0

    if (-not (Test-Path -Path $listFile)) {
    
        # [n]: Abort. 
        Add-Content `
            -Path $logFile `
            -Value "ERROR: DELETE LIST FILE NOT FOUND. Aborting process."
        
        $flg = 1
        
    } else {
    
        # [y]: Proceed.

        # [Step 3]: Read list.txt 
        $reader = New-Object IO.StreamReader $listFile, ([System.Text.Encoding]::GetEncoding('shift_jis'))
        
        while ($null -ne ($line = $reader.ReadLine())) { 
        
            $tgtPath = Join-Path `
                        -Path $tgtDirectory `
                        -ChildPath $line


            # [Step 4]: Log full path of matched file or folder
            if (Test-Path -Path $tgtPath) {
            
                Add-Content `
                    -Path $logFile `
                    -Value "DELETING: $tgtPath"
                
                # [Step 5]: Delete matched result
                Remove-Item -Path $tgtPath -Force -Recurse
                
            } else {
            
                Add-Content `
                    -Path $logFile `
                    -Value "Path not found: $tgtPath"
                
            }

            
        }
        
        $reader.Close()
    }

    # [Step 6]: Log process completion with flag value
    Add-Content `
        -Path $logFile `
        -Value "Process Completed. Abnormal termination: $flg"
    
}  

```

こんな感じ。

>【使い方】
>``. OperateDeletion.ps1 OperateDeletion -tgtDirectory "C:\work\test\001"  ``


ぱぱっと削除してくれた。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3679069/595ff278-18c9-cc49-17a2-03ef565cd663.png)

とりあえず、フォルダ毎削除してくれそうだし日本語のファイル名も削除できた。
BaseTemplateAndroidAppで強力なAndroidアプリを作成する

<h2> はじめに </h2>
はじめまして、Hridoy Chandra Das(リド)（@ihridoydas）です。

 #### BaseTemplateAndroidApp: Androidアプリ開発の新しいスタート

テンプレート：[BaseTemplateAndroidApp](https://github.com/ihridoydas/BaseTemplateAndroidApp)

<h2> 概要 </h2>
BaseTemplateAndroidAppは、Androidアプリの開発プロセスを合理化し、堅牢で洗練されたアプリケーションを迅速に作成するためのオープンソースのAndroidテンプレートです。このテンプレートは、ベストプラクティス、ライブラリ、アーキテクチャのパターンを組み合わせ、開発者が毎回同じコードを書かなくても済むようサポートします。

このテンプレートは、[Hridoy Chandra Das](https://www.linkedin.com/in/ihridoydas/) によって設計され、コードの構築において意見を押し付けず、開発者が自由に選択できる環境を提供します。必要なツールが手に入ることで、ユーザーは自分のスタイルでプロジェクトを進めることができます。
<h2> なぜこのテンプレート？ </h2>

<b>選択の自由:</b> コード構造やアーキテクチャに対する意見はありません。開発者が自分で決めます。
<b>意見を述べるツール: </b>設定済みの依存関係管理、gitフック、コードフォーマッティング、静的解析など、開発を向上させるためのツールが含まれています。

<h2> 主な特徴 </h2>

1. モジュラーなアーキテクチャ
モジュラーなアーキテクチャにより、プロジェクトは整理され、拡張が容易になります。クリーンなモジュール構造は、メンテナンス性を向上させます。

2. MVVMデザインパターン
MVVMデザインパターンを採用しています。これにより、ユーザーインターフェースの開発が簡素化され、テスト可能でメンテナンス性の高いコードが可能となります。

3. Dagger Hiltによる依存性の注入
Dagger Hiltを使用した依存性の注入は、効率的で簡潔なコードを実現し、アプリのアーキテクチャを向上させます。

4. Jetpackコンポーネントの統合
Android Jetpackコンポーネント（ViewModel、LiveData、Navigationなど）を積極的に統合し、最新のGoogleのベストプラクティスに従います。

5. Retrofitを用いたネットワーキング
Retrofitを利用したネットワーキングは、簡潔なネットワークリクエストの実行とAPIの統合を容易にします。

6. UIコンポーネントとテーマ
一貫性のあるビジュアルを提供するためのUIコンポーネントとテーマが組み込まれています。これにより、魅力的なユーザーインターフェースを構築できます。

<h2> スタートガイド </h2>

1. "Use this template"をクリックして、アカウントにリポジトリを作成します。

2. [setup.gradle](https://github.com/ihridoydas/BaseTemplateAndroidApp/blob/develop/buildscripts/setup.gradle)を調整し、`./gradlew renameAllModules`を実行してカスタマイズします。

```gradle
    templateName             : "template",
    templateAppId            : "template.app.id",
    templateMaterialThemeName: "TemplateTheme",
    newTemplateName          : "Project", [ここにプロジェクト名を入力]
    newTemplateAppId         : "domain.yourname.app", [ここにプロジェクトのパッケージ名を入力]
    newMaterialThemeName     : "MyMaterialTheme", [ここにプロジェクトのテーマ名を入力]
    useHiltDependencies      : true,
    useRoomDependencies      : true,
    useRetrofitDependencies  : true,
    usePaparazziDependencies : true,
```

<h2> 含まれるもの </h2>

・/documentation：サードパーティーの依存関係とドキュメンテーション。
・コードフォーマット用のKtlint。
・コードスメル検出のためのDetekt。
・静的解析チェックのためのGit Hooks。
・継続的な統合のためのGitHub Actions。
・メモリリークの検出のためのLeakCanary。
・HiltおよびRoomの依存関係（必要に応じてsetup.gradleで削除可能）。
・Paparazziの依存関係（必要に応じてsetup.gradleで削除可能）。
・Dokka 依存関係、すべてのプロジェクトとモジュールをドキュメント化します。
・Spotless 依存関係、コードを清潔に保ちます。
・sortDependencies 依存関係、build.gradleファイル内の依存関係を整理します。

<h2> 依存関係の設定 </h2>

依存関係は[/buildscripts](https://github.com/ihridoydas/BaseTemplateAndroidApp/tree/develop/buildscripts)に構造化されています。アプリモジュールの依存関係は、[libs.versions.toml](https://github.com/ihridoydas/BaseTemplateAndroidApp/blob/develop/gradle/libs.versions.toml)にあるGradleバージョンカタログを使用して定義されています。


テンプレートを使用して、効率的で強力なAndroidアプリを開発しましょう！
<h2> まとめ </h2>
BaseTemplateAndroidAppは、洗練されたアプリを構築するための堅牢な基盤を提供します。これにより、開発者は独自の機能に焦点を当て、開発プロセスを迅速かつ効果的に進めることができます。

ぜひお試しください！コメントで感想を教えていただければ嬉しいです。Happy coding！
【実践編】テスト計画書｜ログイン機能

> ログインの機能について
「テストフェーズ：テスト計画書」を作成してください。
開発者のチームに対してどのような指導を行いますか？
重要なポイントを教えてください。
どのようなステップがありますか？

ログインの機能についての「テストフェーズ：テスト計画書」を作成し、開発者チームへの指導を行う際の重要なポイントとステップは以下の通りです。

# テスト計画書の内容
### テスト対象

ログイン機能のテスト対象範囲を明確に定義します。どの部分をテストするかを詳細に記述します。
### テストの目的

ログイン機能のテストの主要な目的を述べます。なぜこのテストが行われるのかを説明します。
### テスト戦略

ログイン機能のテストにおけるアプローチや方法論を指定します。手動テスト、自動化テスト、統合テストなどの戦略を明示します。
### テストケース

個別のテストケースを作成し、テストステップと期待される結果を列挙します。正常なケースと異常なケースを含めます。
### テストデータ

テストケースの実行に必要なテストデータを準備し、データの生成方法や取得方法を記述します。
### テスト環境

テストケースを実行するためのテスト環境（ハードウェア、ソフトウェア、ブラウザなど）を定義します。
### スケジュール

テストのスケジュールやタイムラインを設定し、テストの実施予定日を示します。
### リスク評価

ログイン機能のテストに関連するリスクを評価し、リスクの管理計画を記述します。

# 開発者チームへの指導ポイント
### テスト対象の理解

開発者はテスト対象の範囲を正確に理解し、それに基づいてテストケースを作成する必要があります。
### テストケースの適切な設計

テストケースは正常なケースと異常なケースを網羅するように設計し、期待される結果を明確に定義します。
### テストデータの準備

テストデータの生成や取得方法を開発者に指導し、テストの実施をスムーズに行えるようにします。
### テスト環境の準備

開発者はテスト環境のセットアップと準備を行い、テストを実施するための環境を整えます。
# テスト計画書の作成ステップ
### テスト対象の確認

ログイン機能の仕様と基本設計書を参照し、テスト対象を確認します。
### テスト目的の設定

ログイン機能のテスト目的を明確に定義します。例えば、セキュリティの確認やユーザーエクスペリエンスの評価など。
### テスト戦略の策定

テスト方法（手動、自動化）、テストの範囲、優先順位などのテスト戦略を検討します。
### テストケースの設計

テストケースを作成し、各ケースの実行手順と期待される結果を詳細に記述します。
### テストデータの準備

テストデータの生成や取得方法を定義し、テストデータを準備します。
### テスト環境の整備

テストを実施するためのテスト環境を整えます。
### スケジュールの設定

テストの実施スケジュールを策定し、テストの開始日と終了日を決定します。
### リスク評価と管理計画の策定

テストに関連するリスクを評価し、リスクの管理計画を策定します。

テスト計画書は品質保証の重要な要素であり、テスト活動を計画的かつ効果的に進めるためのガイドとなります。開発者とテスターの協力が必要ですが、品質の確保とバグの早期発見に貢献します。
【実践編】開発ガイドライン｜ログイン機能

> ログインの機能について
「開発フェーズ：開発ガイドライン（コード規約、開発ツールの使用方法、バージョン管理システムの利用ガイド、擬似サーバーの使用の方法など）」を作成してください。
開発者のチームに対してどのような指導を行いますか？
重要なポイントを教えてください。
どのようなステップがありますか？

ログインの機能についての「開発フェーズ：開発ガイドライン」を作成し、開発者チームへの指導を行う際の重要なポイントとステップは以下の通りです。

# 開発ガイドラインの内容

### コード規約

プログラミング言語に応じたコーディング規約を明確に定義し、コードの一貫性と可読性を確保します。

### 開発ツールの使用方法

開発に使用するツール（統合開発環境、デバッガーなど）の適切な使用方法を説明し、効率的な開発を支援します。

### バージョン管理システムの利用ガイド

バージョン管理システム（例：Git）の基本的な操作方法とベストプラクティスを説明し、コードのバージョン管理を行います。

### 擬似サーバーの使用方法

ローカル開発環境での擬似サーバーのセットアップ方法と使用方法を案内し、実際のサーバーへのアクセスを模擬します。

# 開発者チームへの指導ポイント

### コード規約の遵守

コード規約は一貫性と可読性を確保するために重要です。開発者はコード規約を遵守するように指導します。

### バージョン管理の重要性

バージョン管理システムを適切に使用し、コードの変更履歴を管理することの重要性を強調します。

### 効率的な開発ツールの活用

開発ツールを活用して効率的な開発を行う方法を指導し、時間の節約と品質向上を目指します。

### 擬似サーバーの利用

擬似サーバーを使用してローカルでの開発を効率化し、実際のサーバーへのアクセスをシミュレートする方法を説明します。

# 開発ガイドラインのステップ

### コード規約の作成

開発チームと協力して、コード規約を作成します。言語に応じたベストプラクティスを取り入れます。

### 開発ツールのドキュメント化

開発ツールの使用方法をドキュメント化し、開発者に提供します。

### バージョン管理の手順の整備

バージョン管理システムの適切な手順とワークフローを整備します。

### 擬似サーバーのセットアップ

ローカルでの擬似サーバーのセットアップ手順を文書化し、開発者に提供します。

### 開発ガイドラインの共有

開発ガイドラインを開発者チームと共有し、質問や疑義疑問に対応するためのコミュニケーション手段を提供します。

開発ガイドラインは効率的な開発プロセスとコード品質の向上に貢献します。開発者はこれらのガイドラインに従って作業し、一貫性のあるコードを提供することが期待されます。指導とコミュニケーションを通じて、開発者チームが効果的にガイドラインを活用できるよう支援します。
Google Chrome の開発者コンソールでspanタグを120回クリックしてみた

# はじめに
はじめまして[ほしいも](https://twitter.com/hoshiimo_se)です。
今回はGoogle Chrome の開発者コンソールでJavaScriptを実行する方法について書いてみました。

# 何がしたかったか
昨日、フォトスタジオで七五三の写真を撮ってもらってきました！
画像データをいただけるんですが、カット数に応じて値段が違うんですよね。
基本料金だと50枚なんですが、良い写真が多くて120枚にしちゃいました。（料金も倍以上になりました...）

今日待ちに待った写真のダウンロードがPhotoRecoというサイトでできるようになったんですが、一括ダウンロードボタンがない...。
120回ダウンロードボタンを押すのは辛いので、JavaScriptで連打してみました。

ダウンロードボタンは↓のように写真ごと配置されています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/521440/d291f0f2-775a-a4c5-2468-00c361d4dd68.png)


# 開発者コンソールでJavaScriptを実行する
## ①開発者コンソールを起動
Google Chromeを開いてF12を押下します。
↓こんな画面が出てきます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/521440/a131615a-00cc-013b-9306-4e61dfdfff64.png)

## ②JavaScriptを実行
コンソールタブで以下のコードを貼り付けます。
※PhotoReco以外のサイトで使う場合は適当にセレクター変えてね。
```
const clickAllSpansWithClassWithDelay = async () => {
    // 'btnDL_1 boxer' クラスを持つすべての span タグを取得
    const spans = document.querySelectorAll('span.btnDL_1.boxer');
    const delay = ms => new Promise(resolve => setTimeout(resolve, ms));

    for (const span of spans) {
        span.click(); // クリックイベントを発火
        await delay(1000); // 次のクリックまで1秒待機
    }
};

clickAllSpansWithClassWithDelay();
```

:::note info
以下のメッセージが出てきたら言われた通り「allow pasting」を入れてみてね。日本語のメッセージだったら日本語で入れてね。

Warning: Don’t paste code into the DevTools Console that you don’t understand or haven’t reviewed yourself. This could allow attackers to steal your identity or take control of your computer. Please type ‘allow pasting’ below to allow pasting.
:::

# 動作イメージ
![photoDL.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/521440/492b64fd-0d0a-601b-818a-1b7cb90e6d65.gif)
【実践編】詳細設計書｜ログイン機能

> ログインの機能について
「設計フェーズ：詳細設計書」を作成してください。
開発者のチームに対してどのような指導を行いますか？
重要なポイントを教えてください。
どのようなステップがありますか？

ログイン機能に関する「設計フェーズ：詳細設計書」を作成し、開発者チームへの指導を行う際の重要なポイントとステップは以下の通りです。

# 詳細設計書の内容
### 概要

ログイン機能の目的と基本設計の概要を簡潔に記述します。

### クラス設計

ログイン機能を実装するためのクラスやモジュールの設計。各クラスの責務、属性、メソッドを詳細に記述します。

### データフロー図

ユーザーからのログイン要求から認証プロセスを経てセッションが開始されるまでのデータフローを図式化します。

### シーケンス図

ログイン処理のシーケンス（プロセスフロー）を図示し、各オブジェクト間のやり取りを詳細に記述します。

### データベース設計

ログイン情報を保存するためのデータベーステーブルの詳細設計。フィールド名、データ型、制約などを記載します。

### API設計（必要な場合）

ログイン処理に関わるAPIのエンドポイント、リクエストとレスポンスのフォーマット、認証方法などを記述します。

### エラーハンドリング設計

認証失敗、セッションタイムアウト、システムエラーなど、各種エラーシナリオとそのハンドリング方法を詳細に記述します。

### セキュリティ設計

パスワードの暗号化方法、セッション管理のセキュリティ対策、入力値の検証など、セキュリティに関わる詳細設計を記述します。

# 開発者チームへの指導ポイント
### 詳細設計の徹底理解

開発者が詳細設計書の内容を正確に理解し、設計に基づいて実装を行うことが重要です。
### セキュリティ対策の徹底

セキュリティ要件の実装が重要であることを強調し、セキュリティ対策の実施を指導します。

### コードレビューの実施

設計書に基づいたコーディングが行われているかを確認するために、定期的なコードレビューを実施します。

### テストケースの作成

詳細設計書に基づいてテストケースを作成し、実装が設計通りに行われているかを検証します。

# 詳細設計のステップ
### 基本設計の確認

基本設計書を参照し、ログイン機能の全体像を確認します。

### クラスとモジュールの設計

ログイン機能を構成するクラスやモジュールの詳細を設計します。

### データフローとシーケンスの図示

ログイン処理のデータフローとシーケンスを図示し、プロセスを明確にします。

### データベースの詳細設計

ログイン情報を管理するデータベーステーブルの設計を詳細化します。

### セキュリティとエラーハンドリングの設計

セキュリティ対策とエラーハンドリングの詳細を設計します。

### 詳細設計書の作成

上記の情報をもとに、詳細設計書を作成します。

### レビューと調整

関係者と設計書を共有し、レビューを受けて必要に応じて調整します。

詳細設計書は実装の直接的な指針となるため、開発者は設計書の内容を正しく理解し、設計に忠実な実装を行う必要があります。また、セキュリティやエラーハンドリングなどの重要な要素に特に注意を払い、品質の高いソフトウェアを開発することが求められます。