OmniAICreator/Qiita-1.07M huggingface dataset:
🚀 Warpで変わる開発体験：AI × モダンUIの次世代ターミナルを徹底紹介！


## 🧩 はじめに

従来のターミナル、たとえば`iTerm2`やVSCode統合ターミナルを使っていて、こんな不満はありませんか？

- 🔍 コマンド履歴の管理がしにくい  
- 🧠 コマンドが覚えられない  
- 🎨 UIが時代遅れで使いづらい  

そんな悩みを一気に解決してくれるのが、**次世代ターミナル「Warp」**です！

> 🛠️ Warpは、Rust製・高速・構造化UI・AI補完という現代的な機能を備えたターミナル。初心者にも優しく、熟練者にも便利！


---

## 🔎 Warpとは？

| 特徴 | 内容 |
|------|------|
| ⚡ 高速 | Rustで書かれていて動作が軽快 |
| 🧠 AI補助 | コマンドの自動提案やエラー解説 |
| 📚 構造化UI | コマンドと出力がブロックで管理できる |
| 💻 クロスプラットフォーム | macOS / Linux / Windows対応（2025年〜） |
| ☁️ Warp Drive | よく使うコマンドを保存・共有可能 |



## 🖥️ イメージ
![スクリーンショット 2025-05-17 22.33.15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/75802/e6133a5d-a192-4f63-aab5-e51f401ffe52.png)

---

## 🛠️ Warpの主要機能5選！

### ✍️ 1. IDEライクなエディタUI

- マルチカーソルや選択、`⌘ + Enter`でコマンド実行
- Vimキーバインドも対応で、Vimmerも安心  


---

### 📦 2. コマンドブロックで履歴管理が神！

```bash
tree -L 2
```

- コマンドと出力がセットで「ブロック化」される
- ブロックごとにコピー・共有・再実行ができる
- 履歴が視覚的に把握できるのが最高✨  


---

### 🤖 3. Warp AIとAgent Mode

自然言語で聞くだけで、適切なコマンドを提案してくれる！

```
「Dockerコンテナを一覧表示したい」
```

➡️ `docker ps`を提案してくれる。

- エラーの原因も自然言語で解説可能
- 「この状態でpushするには？」と聞くだけでGit操作も補助

---

### 📚 4. Warp Drive & Notebooks

- よく使うコマンドは**保存してすぐ再利用**できる！
- Markdownと組み合わせて手順書を作成 ⇒ チーム共有も可能✨

```
# プロジェクト初期設定
npm install
git init
warp notebook save setup
```

---

### 🔍 5. スマートな補完 & 検索

```bash
docker run --<TAB>
```

- オプションやパラメータの補完がUIで表示される  
- `Ctrl + R`で履歴から高速検索も可能！



---

## 🚀 Warpのインストール方法

### macOS
```bash
brew install --cask warp
```

### Linux
[公式サイト](https://warp.dev)から`.deb`または`.rpm`をダウンロード

### Windows（β公開中）
[warp.dev/windows](https://www.warp.dev/windows) よりダウンロード

---

## ⚙️ 実践：Warpを使った開発フロー

### 例：Gitを使った開発
```bash
git status
# AIに「この状態でpushするには？」と聞く
```

### 例：Dockerの操作
```bash
docker ps
# 「AIにcomposeの設定作って」と聞くとテンプレ提案！
```

### 例：プロジェクトセットアップ
- Notebooksに手順を保存して再利用！

---

## ✅ メリットと注意点

### ✅ メリット
- 視覚的な履歴とブロックで、作業効率UP！
- AI補助で初心者もコマンド迷子にならない
- チーム開発にもフィットする共有機能

### ⚠️ 注意点
- 一部機能はアカウント登録が必要
- タイル型ウィンドウやtmuxなどの高度な操作は未対応

---

## 🎯 まとめ

> Warpは「ターミナル＝難しい・無骨」といった常識を覆す、**モダンでスマートな開発体験**を提供してくれます。

- 👶 初心者でも安心して使える補完とUI
- 👨‍💻 上級者も納得の効率的な操作性
- 👥 チーム利用で更にパワーアップ

まだ触ってないなら、**ぜひ一度使ってみてください！**

---

## 🔗 参考リンク
- [公式サイト（warp.dev）](https://www.warp.dev)
- [導入ドキュメント](https://docs.warp.dev)
CloudFront OAI/OAC

CloudFront の **OAI (Origin Access Identity)** と **OAC (Origin Access Control)** は、
**S3 バケットへのアクセスを CloudFront 経由のみに制限するための認証方法**です。
OAC は OAI の後継となる新方式です。

---

## 🧩 1. OAI（Origin Access Identity）

### 🔹 概要

* CloudFront から **S3 オリジンにアクセスするための仮想ユーザー（IAMのようなもの）**
* S3 バケットポリシーで、**CloudFront の OAI からのアクセスのみ許可**することで、
  直接S3へのパブリックアクセスを遮断

### ✅ 特徴

* 長年使われてきた旧方式（レガシー）
* CloudFront ⇒ S3 の制限に特化
* **署名付きURL/署名付きCookie**と併用可能

### ⚠️ 注意点

* **2022年11月以降、非推奨（Deprecated）**
  → 新しい機能（例：Headerベース制御）は非対応

---

## 🧩 2. OAC（Origin Access Control）

### 🔹 概要

* OAIの進化版。**より柔軟でセキュアなアクセス制御が可能**
* IAMの署名（SigV4）を使用して CloudFront → S3 アクセスを認証
* CloudFrontディストリビューション設定に OAC をアタッチ

### ✅ 特徴

* より **詳細なアクセス制御**（ヘッダー、リクエストタイプなど）
* **IAMポリシーと統合可能**
* **署名付きリクエスト（SigV4）** を使用しセキュア
* **新規構成では OAC 推奨**

### 📌 対応オリジン：

* S3（パブリックURL不可）
* CloudFront Functions や Lambda\@Edge と併用可

---

## 🆚 OAI vs OAC 比較表

| 項目    | OAI                     | OAC                      |
| ----- | ----------------------- | ------------------------ |
| 提供時期  | 古い（従来の方式）               | 新しい方式（推奨）                |
| 認証方式  | CloudFront専用ID          | IAMベースのSigV4署名           |
| 柔軟性   | 低い                      | 高い（ヘッダー、メソッド対応）          |
| 今後の推奨 | ❌ 非推奨                   | ✅ 推奨                     |
| 設定場所  | CloudFront + S3バケットポリシー | CloudFront + IAMロール/ポリシー |

---

## 🛠️ OAC の設定イメージ（概要）

1. CloudFrontディストリビューションで OAC を作成
2. OAC に IAMロール・署名設定を定義
3. S3バケットのポリシーでその IAM ロールのアクセスのみ許可

---

## 🎯 どっちを使えばいい？

| シナリオ                     | 推奨                       |
| ------------------------ | ------------------------ |
| これから新規構築                 | **OAC を使用（AWS公式推奨）**     |
| 既存環境が OAI を使用している        | すぐの移行は不要だが、段階的に OAC 移行検討 |
| 複雑な条件での制御（例：ヘッダー付きリクエスト） | OAC のみ対応                 |

---

## ✅ まとめ

| 用語  | 説明                                 |
| --- | ---------------------------------- |
| OAI | CloudFrontからS3を守る旧方式。簡単だが機能制限あり    |
| OAC | OAIの進化版。IAMベースで柔軟・高セキュリティ。新規はOAC推奨 |
DynamoDB読み取り整合性

DynamoDB の「読み取り整合性」は、**データの一貫性（Consistency）をどう保証するか**に関する設定です。DynamoDB では主に以下の2種類があります：

---

## 🧩 1. **Eventually Consistent Reads（結果整合性のある読み取り）**

### ✅ 特徴：

* デフォルトの動作
* **直前に書き込んだ値が、すぐに反映されない可能性がある**
* 少し待てば正しいデータが読める（最終的に整合性が取れる）

### 🔍 利点：

* **スループットが高く**、読み取りコストが安い（1/2ユニット）
* 読み取り性能を重視するユースケースで有効

---

## 🧩 2. **Strongly Consistent Reads（強い整合性のある読み取り）**

### ✅ 特徴：

* **常に最新のデータを返す**（書き込み後すぐに反映）
* パーティション間での整合性を保証

### 🔍 利点：

* 読み取りの正確性が重要な場面（たとえば在庫数、残高）に最適

### ⚠️ 注意点：

* スループット使用量が多く、結果整合性の2倍の\*\*読み取り容量ユニット(RCU)\*\*を消費
* グローバルテーブルでは使用不可（最強整合性はリージョンをまたいで保証できない）

---

## ✅ 比較表

| 特性          | 結果整合性 (Eventually Consistent) | 強い整合性 (Strongly Consistent) |
| ----------- | ----------------------------- | --------------------------- |
| 最新データの保証    | ❌ すぐには保証されない                  | ✅ 常に最新の書き込みが反映              |
| RCU消費量      | 1                             | 2                           |
| デフォルトかどうか   | ✅ はい                          | ❌ 手動指定が必要                   |
| グローバルテーブル対応 | ✅ 対応                          | ❌ 非対応                       |

---

## 💡 使い分けのポイント

| ユースケース          | 適した整合性       |
| --------------- | ------------ |
| ユーザー投稿一覧の表示など   | 結果整合性（速さ重視）  |
| 在庫確認・口座残高・設定値確認 | 強い整合性（正確性重視） |

---

## 🔧 強い整合性を使う方法（例）

AWS SDKやCLIで `ConsistentRead` を明示的に `true` にします：

```bash
aws dynamodb get-item \
  --table-name Products \
  --key '{"ProductId": {"S": "123"}}' \
  --consistent-read
```

---

## ✅ まとめ

| 用語    | 説明                            |
| ----- | ----------------------------- |
| 結果整合性 | 高速・安価だが直前の書き込みが見えない可能性あり      |
| 強い整合性 | 常に最新のデータ取得が保証されるが、スループット消費が多い |
DynamoDB ポイントインタイムリカバリ

DynamoDB の **ポイントインタイムリカバリ（PITR: Point-In-Time Recovery）** は、
テーブルのデータを過去最大 **35日間の任意の時点に復元**できる機能です。

---

## ✅ 概要（何ができる？）

* **誤操作（削除・上書き）やアプリケーションのバグ**によって失われたデータを、**過去の任意の時点に戻して復元**できます。
* 1秒単位で復元可能（UTC 時間指定）
* 最大 35日間の履歴を保持
* オンデマンドバックアップとは異なり、**継続的な自動バックアップ**

---

## 🔧 有効化方法

* AWS コンソール、CLI、または SDK から有効化可能
* テーブルごとに設定（**デフォルトでは無効**）

```bash
aws dynamodb update-continuous-backups \
  --table-name YourTable \
  --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
```

---

## 🔄 復元方法

* 新しいテーブルとして復元される（**既存テーブルを上書きしない**）
* UTC 時間で復元時刻を指定する

例：

```bash
aws dynamodb restore-table-to-point-in-time \
  --source-table-name YourTable \
  --target-table-name RestoredTable \
  --restore-date-time "2025-05-17T08:00:00Z"
```

---

## 🧠 PITR と オンデマンドバックアップの違い

| 項目    | ポイントインタイムリカバリ  | オンデマンドバックアップ  |
| ----- | -------------- | ------------- |
| 自動/手動 | 自動             | 手動            |
| 復元対象  | 任意の時点（1秒単位）    | 特定時点のスナップショット |
| 保存期間  | 最大35日間         | 無制限（削除するまで）   |
| コスト   | ストレージ量に応じた従量課金 | 容量ベースの従量課金    |

---

## 💡 使用例（ユースケース）

* 誤ってアイテムを削除 or 上書きしてしまった場合に元に戻す
* アプリのバグで複数データに誤操作 → その直前にロールバック
* ロールバックテストや災害復旧（DR）用途

---

## ⚠️ 注意点

| 項目              | 内容                 |
| --------------- | ------------------ |
| 既存テーブルに上書きできない  | 新しいテーブルとして復元される    |
| リージョン内のみ        | クロスリージョンには対応していない  |
| グローバルテーブルとの併用制限 | 有効化のタイミングや仕様に注意が必要 |

---

## ✅ まとめ

| ポイント | 説明                      |
| ---- | ----------------------- |
| 目的   | 過去最大35日間、任意の時点に復元       |
| 利点   | 自動・1秒単位で復元、簡単にロールバックできる |
| 注意点  | 復元は新規テーブル、コストは保存データ量に比例 |
DBにおけるリレーションとは

# 今日のトピック
- DBにおけるリレーションとは

## DBにおけるリレーションとは
端的に言うと、テーブル同士が持つ「関係性」のこと。
この関係性（リレーションシップ）をテーブル間で適切に定義し、データの整合性を保つためには、以下のキー概念が基本となる。
- 主キー（Primary Key - PK）：テーブル内の各レコードを一意に識別するためのキー
- 外部キー（Foreign Key -FK）： 他のテーブルの主キーを参照することで、テーブル間の関連付けを行うためのキー

リレーションシップには、主に以下の3つパターンがある。
- 1対1
- 1対多
- 多対多

これら3つのリレーションシップをどのように構築していくかについて記載する。

### 1対1リレーションシップ
例）Users テーブルと UserProfiles テーブル（ユーザーは1つのプロフィールを持ち、プロフィールは1人のユーザーに属する）
- DBスキーマ設計 (SQL例):

```
Users
id (PK), username, email, etc.
```
``` 
UserProfiles 
id (PK), user_id (FK, UNIQUE references Users.id), etc.
```
user_id に UNIQUE 制約をかけることで1対1を保証する。
もしくは、UserProfiles の主キーを user_id にする設計も考えられる。

### １対多リレーションシップ
例）Authors テーブルと Posts テーブル（著者は多数の投稿を持つことができ、投稿は1人の著者に属する）
- DBスキーマ設計 (SQL例):
```
Authors
id (PK), name, etc.
```
```
Posts
id (PK), title, content, author_id (FK references Authors.id)
```

### 多対多リレーションシップ
例) Posts テーブルと Tags テーブル（投稿は多数のタグを持つことができ、タグは多数の投稿に適用できる）
- DBスキーマ設計 (SQL例):
```
Posts
id (PK), title, content, etc.
```
```
Tags
id (PK), name, etc.
```
```
Post_Tags（中間テーブル）
post_id (FK references Posts.id),tag_id (FK references Tags.id), PRIMARY KEY (post_id, tag_id)
```

## おわりに
間違いがあれば、ご指摘いただけますと幸いです(__)
AWS認定試験 DEA-C01 受けてみた！(2025-05-17)

## はじめに
- CLF/SAA/SOA/DVA/AIF/MLA/MLSを取得済
- 最後のAssociate試験

## 受験前の気持ち
- 試験を受ける前には対策として受験体験記を見るようにしている
- 今回も受験体験記を見て、Web問題集を理解できていれば、ということで取り組んだ

## 試験結果
- 720点以上が合格なのでギリギリ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4045441/ebfc6eaa-b4ba-4b55-9983-748447bfdd59.png)

## 試験中の気持ち①
- 今まで何度も試験を受けてきて、最初の10問でそれ以降が流れを掴んできた
- 今回は正直かなり厳しいと思った
- 苦しくなってきた
- なぜなら受験前の想定と大きく異なっていたから

## 試験中の気持ち②
- とはいえ、やりきる気持ちに切り替え
- 何度も何度も問題を読んでねばった
- 「後から見直す」のチェックだけではなく、全問題見直した
- 制限時間最後までねばった

## 所感
- 試験範囲の各サービスをどこまで理解できていたのか
- 自分自身で腑に落ちるところまで理解できていたのか
- 上っ面で理解したつもりではなかったのか
- パターン化して理解しているだけで、他のケースになると弱かった
- **反省しかない**
- **Web問題集に頼りすぎる学習はリスクであると感じた（もちろん自分の責任である）**
- **今回の件を教訓にして次につなげる**
sunoで作ったオリジナル曲をComfyUI-FLOAT

すんなりできた。

https://note.com/bakushu/n/n1f884f4f40fd

一応注意点。

comfyuiの使い方は


ワークフローをダウンロード
https://github.com/yuvraj108c/ComfyUI-FLOAT/blob/master/float_workflow.json


上記をcomfyuiで読み込み
ファイルが足りないと出るので、
右上のmanagerをクリックし、installmissingcustomnodesをクリック

時間がたつと、再起動してねと表示される。
結構待たなきゃいけないみたい。
裏側でインスコしているから。

ブラウザのタイトル欄になにか表示されいてるので、待つ。
![1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/31338/0ac7081b-5a91-4319-8509-bac342ee3ec1.png)

このパーセンテージが動けばOK
rails8でenum使ったらダメぺこ？

:::note info
コメントにて有識者から変更理由と思しきリンクを共有いただきました。
興味のある方は是非そちらをご覧ください。
:::

## 始まりは自己紹介から
初めまして　あおげばにゃんこです。
rails 8でウキウキしながら開発をしていたある日、悲劇が起きました。


## enumを使うとエラーが発生する

### コード
```article.rb
class Article < ApplicationRecord
  belongs_to :user

  enum status: { draft: 0, publish: 1 }
end

```
```user.rb
class User < ApplicationRecord
  has_many :articles
end

```
```schemafile.
create_table :users, force: :cascade do |t|
  t.string :name, null: false
  t.timestamps
end

create_table :articles, force: :cascade do |t|
  t.string :name, null: false
  t.integer :status
  t.timestamps
end
```
※ridgepoleを使っているのでマイグレーションファイルじゃないです。ファイル名の.は無視してください

発生した問題は以下のとおりです。

```index.html
 - current_user.articles.each do |user|
    p user.id
    p user.name

  => Undeclared attribute type for enum '' in Article. Enums must be backed by a database column or declared with an explicit type via `attribute`. (RuntimeError)

```

### GPT訳
Undeclared attribute type for enum '' in Article. Enums must be backed by a database column or declared with an explicit type via `attribute`. (RuntimeError)

>Articleモデルのenumで型が宣言されていません。
enumとして定義する属性には、データベースカラムとしてサポートされている型が必要です。
または、attributeメソッドを使って明示的に型を指定する必要があります。

って言われましても…って感じですよね。
具体的にどうすればええねんって感じです。

GPTに聞くと、
- ほんとにschemafileでintegerで定義してる？
- キャッシュ残ってる？
- 関連付けできてる？
とか聞いてきます。

ま、まあそりゃ定義してるよって感じですよね。
これで私は手詰まりになりました。


## 解決方法
```article.rb
class Article < ApplicationRecord
  belongs_to :user

  enum :status, { draft: 0, publish: 1 }
end

```

何が違うか、わかりますか？

```article.rb
## 失敗
enum status: { draft: 0, publish: 1 }

## 成功
enum :status, { draft: 0, publish: 1 }
```

### そうです！定義の仕方違うんです！

「こんな微妙な変更して誰も幸せにならないだろ。」って思いましたが、変わってしまったんだからしょうがない。
大人しく従いましょう。

## 最後に

てなわけで今回の記事はこれで終わりです。
久しぶりに書いたせいか文章力が見事に落ちていますが、
まあいいでしょう。

この記事参考になったらわかりますよね？
伝わりますよね？

お互い幸せな気持ちで開発に戻りましょうね😉
FastCGIとは何か？


## ✅ 1. 背景：CGIとは何か？

まずは前提となる「CGI（Common Gateway Interface）」から整理します。

### 🔹 CGI（旧来の仕組み）

- Webサーバーが `.php` や `.pl` などの動的なスクリプトを実行するために、**リクエストごとに外部プログラムを起動していた**方式
- 毎回「PHPを起動 → 実行 → 終了」を繰り返すため、**非常に遅く、負荷が大きい**

---

## ✅ 2. FastCGI とは？

### ▶ CGI の「高速版」

> **FastCGI は、Webサーバーがアプリケーション（PHPなど）にリクエストを高速に渡すための通信プロトコル**です。

---

### 🔧 仕組み（ざっくり）

- Webサーバー（NginxやApache）は、**FastCGIプロトコル**を使ってリクエストをPHP実行エンジンに渡す
- PHP側には、**php-fpm** というプロセスマネージャが常駐していて、**リクエストを待ち受けている**
- つまり：
  - 毎回PHPを起動するのではなく
  - **常駐しているPHPプロセスに繰り返しリクエストを送る**

---

## ✅ 3. なぜFastCGIが重要なのか？

| 課題（CGI） | 解決策（FastCGI） |
|-------------|------------------|
| 毎回PHPを起動するため遅い | PHPプロセスを常駐させておき、高速に処理 |
| 起動・終了にコストがかかる | リクエストだけを渡して処理を続けられる |
| スケーラブルでない | プロセス管理ができ、並列処理も可能 |
| 安定性に欠ける | プロセスごとに監視・再起動などの制御が可能 |

---

## ✅ 4. FastCGI を使う構成例（Laravel）

```text
[ ブラウザ ]
     ↓ HTTP
[ Webサーバー（Nginx） ]
     ↓ FastCGI（通信プロトコル）
[ PHP実行エンジン（php-fpm） ]
     ↓
[ Laravelアプリケーション ]
     ↓
[ DBサーバー（MySQLなど） ]
```

---

## ✅ 5. FastCGIで通信する方法（2パターン）

| 通信方法 | 説明 |
|----------|------|
| Unixソケット | 同じマシン内で通信（例: `/run/php/php8.2-fpm.sock`） |
| TCPソケット | 異なるホスト間やDockerコンテナ間で通信（例: `127.0.0.1:9000`） |

---

## ✅ 6. php-fpmとは？

- 「FastCGI Process Manager」の略
- **PHPのリクエストを処理するFastCGI対応の実行エンジン**
- LaravelやWordPressなど、PHPアプリの実行に使用される
- `php.ini`とは別に、`php-fpm.conf` や `www.conf` により細かいプロセス制御が可能

---

## ✅ FastCGI vs mod_php

| 項目 | FastCGI（php-fpm） | mod_php（Apache） |
|------|---------------------|---------------------|
| 処理方法 | 外部プロセスに渡す | Apacheが直接実行 |
| 性能 | 高速・分離型 | 単純・柔軟性に欠ける |
| スケーラビリティ | ◎ | △ |
| 本番適用 | ◎（現在の主流） | △（古い） |

---

## ✅ FastCGIまとめ

| 観点 | 内容 |
|------|------|
| 目的 | WebサーバーとPHPなどを分離・高速に連携するため |
| 通信方式 | FastCGIプロトコル（Unixソケット or TCP） |
| 実行エンジン | php-fpm（FastCGI対応） |
| 使う理由 | 高速・安定・スケーラブルで本番運用に最適 |

---

## ✅ FastCGIを使った典型構成（Laravel開発やDockerでも）

- Webサーバー：Nginx
- アプリ実行：php-fpm（Laravelなど）
- DB：MySQL/PostgreSQL

```text
[Nginx] → FastCGI → [php-fpm] → Laravel
                              ↓
                           [MySQL]
```

---

## ✅ 補足：FastCGI以外の選択肢

| 選択肢 | 状況 |
|--------|------|
| mod_php | Apacheで直接PHPを処理（古い構成） |
| Proxy | Node.jsなどではHTTPプロキシでリクエストを転送 |

FastCGIは特にPHP界隈（Laravel, WordPressなど）で現在も主流の手法です。

---

## ✅ まとめ

- FastCGIは**PHPを高速かつ安定的に実行するための通信方式**
- Webサーバーとは分離されているが、プロセス間通信で高速処理が可能
- 本番環境・Docker構築・モダン開発環境では**FastCGI + php-fpm**がベストプラクティス
【9999無量大数＜無量大数＞ダメージ】桁の暴力でぶん殴るゲームの中身を冷静に考察する

## 1. イントロ ― ガンダムトライヴと桁インフレ

ガンダムトライヴはブラウザで遊べる放置系ソシャゲです。最大の特徴は “インフレが止まらない数値表記” です。2025 年のサービス終了告知イベントでは、∀（ターンエー）ガンダムが

```
9999 無量大数＜無量大数＞ ダメージ／秒
```

という狂気のステータスを披露しました。
デカい即ち強い。

### 1.1 “無量大数＜無量大数＞”って何？

| 単位   | 10 の何乗 |
| ---- | ------ |
| 京    | 10^16  |
| 垓    | 10^20  |
| …    | …      |
| 無量大数 | 10^68  |

ガントラでは **〈無量大数〉** のように “角括弧” で同じ単位を再度掛ける独自拡張があります。

* `無量大数＜無量大数＞` = 10^(68×2) = **10^136**
* さらに前に付く 9999 は ≈ 9.999×10^3 なので、

  * `9999 × 10^136 ≒ 9.999 × 10^139 ≈ 1×10^140`
* ざっくり 10^140 付近 のダメージ！ こんなん草枯れるわ。

---

## 2. Python の数値型をざっくりおさらい

| 型       | 特徴                  | 表せる桁の目安                  |
| ------- | ------------------- | ------------------------ |
| `int`   | **任意精度整数**。桁数はメモリ依存 | 数千桁でも平気                  |
| `float` | 64-bit IEEE-754 倍精度 | 約 ±1.8×10^308（有効桁 15〜16） |

つまり `int` なら 10^140 なんて余裕で扱えます。ただし演算は遅くメモリも喰います。リアルタイムゲーム内では、もっと軽い工夫をしているはず──ということで、次章では５つの実装仮説を立てて考察してみます。

---

## 3. 巨大ダメージをどう実装する？

### 仮説① : 丸め付き IEEE-754 `float`

* **発想**：とりあえず深く考えずに `float` へ放り込む。指数差が 16 桁以上離れると小さい方は自動で 0 になる特性を利用。

  ```python
  big  = 1e136           # 10^136
  tiny = 8.53e32         # 8.53×10^32
  res  = big + tiny      # tiny が消えた! → 1e136
  ```
* **長所**：実装ゼロ秒／超高速。Cookie Clicker など他のインフレゲーでも採用例。
* **短所**：桁差が大きいと “かすり傷” が完全に消える。

### 仮説② : Mantissa + Exponent（自作 BigFloat）

* **発想**：`9.999 × 10^136` の “左側 4 桁＋右側の指数” を自作クラスで保持。

  ```python
  class BigFloat:
      def __init__(self, mant: int, exp: int):
          self.mant = mant  # 1〜9999（固定桁）
          self.exp  = exp   # 10 の指数
  ```
* **加算**：指数差が大きければ小さい方を無視。差が小さければ桁合わせして足す→正規化。
* **長所**：丸め閾値を好きに設定／“9999 無量大数” のような表示が楽。
* **短所**：四則演算を全部自前実装。

### 仮説③ : 桁バケツ方式

* **発想**：万・億・兆…とタッパーを並べ、はみ出したら上位タッパにキャリー。

  ```python
  class BucketNum:
      # [万, 億, 兆, 京, 垓, …, 無量大数]
      def __init__(self):
          self.bucket = [0]*17
  ```
* **長所**：誤差ゼロ／直感的なシンプルさ。
* **短所**：新しい単位が出るたびにコードと DB を更新。10^67 のような “半端指数” は実装不可。

### 仮説④ : ログ空間 (log-space) 近似

* **発想**：数そのものではなく “桁数 (log10)” を持つ。掛け算＝足し算、割り算＝引き算。
* **加算**：`logsumexp` を使う；桁差が大きければ小さい方はほぼ 0。
* **長所**：オーバーフロー知らず／乗除が激速。
* **短所**：加算で毎回 `pow` と `log` が走り、整数精度も失う。

### 仮説⑤ : `int` + スケール指数（BigInt × Scale）

* **発想**：Python の無限整数 `int` を “本体”、10 の指数を “タグ” に分離。

  ```python
  @dataclass
  class Scaled:
      value: int   # 任意精度整数
      scale: int   # 10 の指数
  ```
* **加算**：`scale` を合わせてから `value` を加算。乗算は `value` 同士掛け、`scale` は足すだけ。
* **長所**：誤差ゼロ／Python ならすぐ書ける。
* **短所**：ブラウザ JS で同じ仕組みを動かすと重い。

---

## 4. どれが有力？

1. **速度と実装コスト**が最優先なら、迷わず **仮説①（float 丸め）**。
2. ガントラの魅力は “とにかく桁がド派手”──**小さなバフが誤差で消えても誰も困らない**。むしろ演出がスッキリ。
3. とはいえ **1e308 近辺** に到達する未来も想定し、**HP やボス専用で仮説② (BigFloat) を部分的に併用**しておけば安全。
4. **仮説③〜⑤** はロマン枠かなー。正確だけれど開発コスト or パフォーマンスコストが高い。インディーで作るなら試してみたい。

**結論**：*たぶん float で爆速に回しつつ、ヤバいときだけ自作 BigFloat に逃がす*――この折衷案が、派手さとコストのバランス的に “一番ガントラっぽい” と私は考えます。


## 5. 終わりに

ガンダムトライヴはほぼ未プレイ、プログラミングもまだまだ修行中の身です。記事中に勘違いや誤植があれば容赦なく指摘してください！　**9999 無量大数＜無量大数＞** のインパクトに負けない面白い実装案、ぜひコメントでお待ちしてます!
Joint distributionnのMarginalのメモ書き

### Marginal of X とは

TDLR: Joint distributionで、X, Y, ... の複数の確率変数を考えるときに、それらの確率変数の取りうる値をX以外に関して全て足し合わせた時の値。

X, Yが離散値を取る時の例を考える。P(X, Y)のJoint distributionを考えているときに、二次元の格子のような確率のダイアグラムを考える。この格子では 片方の軸がx, もう片方の軸がyとなっていて、このマス目の全てを足し合わせると1になる。X=1, Y=2に対応するマスの確率、P(X=1, Y=2)の具体的な値が乗っている。

この時、たとえば、X=1の行に関して、Yに関して端から端まで変化させることを考える。そのそれぞれの値を足し合わせるとそれはMarginal of Xとなり、これはJoint distributionではないXだけの分布における、X=1をとるときの確率値P(X=1) になる。


メモ書きなので、間違っていたらコメントお願いします。

みていたYouTubeのTutorial:

https://www.youtube.com/watch?v=Hxs4GSPActc
Tailwind CSS × Vite × React でのセットアップ手順をまとめた

この記事ではVite + React + TypeScript 環境に Tailwind CSS を導入する方法を備忘録として残します。



### Tailwind CSSとは
Tailwind CSS は**クラス名だけでデザインができる CSS フレームワーク**です。

事前に用意された小さなクラス（ユーティリティクラス）を組み合わせてスタイルを作れるので、CSSを書かずにHTMLやJSXの中で直接見た目を指定できます。



### プロジェクト作成（Vite）

```bash
npm create vite@latest my-app -- --template react-ts
cd my-app
npm install
```
先にViteで環境構築します。

### Tailwind CSS インストール

```bash
npm install -D tailwindcss postcss autoprefixer
npx tailwindcss init -p
```

これで `tailwind.config.ts` と `postcss.config.js` が生成されます。



### Tailwind 設定ファイルを編集

`tailwind.config.ts`

```ts
export default {
  content: [
    "./index.html",
    "./src/**/*.{js,ts,jsx,tsx}"
  ],
  theme: {
    extend: {},
  },
  plugins: [],
}
```
contentの中を記述します。

### Tailwind を CSS に読み込む

 `src/App.css`をこのように記述します。


```css
@tailwind base;
@tailwind components;
@tailwind utilities;
```


###  CSS を読み込む

`src/main.tsx`

```tsx
import React from 'react'
import ReactDOM from 'react-dom/client'
import App from './App.tsx'
import './App.css' // ここを記述

ReactDOM.createRoot(document.getElementById('root')!).render(
  <React.StrictMode>
    <App />
  </React.StrictMode>
)
```


### 不要なCSSを削除

Viteを使用するとデフォルトで`index.css` や `App.css` に最初からCSSが記述されていますが、それらはすべて削除してOKです。



### 公式ドキュメント
こちらに手順が載っています。

https://tailwindcss.com/docs/guides/vite
【学習記録　５月17日】AWS SAA対策まとめ：Route 53／Redshift／Storage Gateway／Kinesis／CloudFormationなど

# 【学習記録】AWS SAA対策まとめ：Route 53／Redshift／Storage Gateway／Kinesis／CloudFormationなど

## 📌 Route 53（DNSサービス）

- **唯一SLAが100%** のAWSサービス。
- **TTL（Time To Live）**：DNSリゾルバーがIPアドレスをキャッシュする時間。
- **レコードタイプ**：最低限、基本的な種類（A、CNAME、MX、TXTなど）を覚える。（試験番号：262）
- **トラフィックフロー**：複雑なルーティングをしたい場合に使用。
- **ホストゾーン**：ドメインを使用するには、対応するホストゾーンの作成が必須。
- **外部ドメインの場合**：ネームサーバーの設定などが異なるので注意。
- **ルーティングの種類**：以下の各ルーティングポリシーをしっかり理解。
  - シンプル
  - 重み付け
  - レイテンシー
  - フェイルオーバー
  - 地理的
  - 近接（トラフィックフロー使用時）

---

## 🗄️ Amazon Redshift（データウェアハウス）

- **スナップショット用の無料ストレージ** が提供されているが、上限を超えると**課金が発生**。
- **コスト削減ポイント**：
  - 不要な**自動スナップショットの保存期間**を短縮。
  - **手動スナップショット**の削除。
  - 自動と手動の併用に注意。

---

## ⚙️ AWS ParallelCluster（HPC環境）

- 実証環境や本番環境向けに、**HPC（ハイパフォーマンスコンピューティング）環境を迅速に構築・デプロイ**可能。

---

## 🔗 AWS Storage Gateway（ハイブリッドストレージ）

- **オンプレミスとAmazon S3** を接続することで、バックアップや拡張ストレージを実現。
- 主なゲートウェイの種類：
  - **ファイルゲートウェイ**
  - **ボリュームゲートウェイ**
    - **保管型（Stored）**
    - **キャッシュ型（Cached）**
  - **テープゲートウェイ**

---

## 🔄 Amazon Kinesis（ストリームデータ処理）

### ▶️ Kinesis Data Streams
- **リアルタイムのデータ取得と処理**に特化。
- 例：Webのクリックストリームを処理するアプリケーションなど。

### 🚰 Kinesis Data Firehose
- ストリームデータを **変換・保存・データベース配信**。
- 例：**Amazon S3データレイク** への自動転送に使用。
- ストリームは大容量になるため、バケット管理が重要。

---

## 🧱 AWS CloudFormation（インフラ自動化）

- AWSのリソースを **コード（テンプレート）として定義・管理**できるサービス。
- EC2やRDSなどのインフラ構成を一括で定義・作成可能。
- インフラの**プロビジョニングと設定を自動化**。

---

### 📝 まとめ

本記事では、AWS認定ソリューションアーキテクト – アソシエイト試験に関連する主要サービスについて学習内容を整理しました。Route 53の特徴的なSLAやRedshiftのコスト管理、KinesisやCloudFormationの実用的な活用まで、試験対策・実務の両面で有益な知識となります。
SAM Localコマンドについての備忘録

以下２つのコマンドについて、違いがわからなかったので調べました。
```
sam local invoke <arguments> <options>
sam local start-lambda <options>
```

# sam local invokeコマンド
https://docs.aws.amazon.com/ja_jp/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-local-invoke.html

> sam local invoke サブコマンドは、 AWS Lambda 関数の 1 回限りの呼び出しをローカルで開始します。


### 想定ユースケース:
- <b>Lambda 関数の単体テスト</b>
API Gateway や Step Functions を介さず、特定のイベントを直接渡して動作確認が可能です。
- <b>デバッグ</b>
ローカル環境で関数をデバッグし、標準出力を確認しながら動作を調整できます。



# sam local start-lambdaコマンド
https://docs.aws.amazon.com/ja_jp/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-local-start-lambda.html

> sam local start-lambda サブコマンドは、 AWS Lambdaをエミュレートするローカルエンドポイントを起動します。


### 想定ユースケース:
- <b>ローカル環境で API Gateway などから Lambda を呼び出す</b>
例えば、Lambda を API Gateway や AWS Step Functions などの外部サービスと連携させたい場合、ローカル環境でその動作を確認できます。
- <b>外部ツール（Postmanなど）を使って関数をテスト</b>
sam local start-lambda を起動すれば、Lambda をローカル API として動かせるので、Postman や curl を使って手軽にリクエストを送信し、レスポンスを確認できます。


# 結論
sam local invokeは、
```
1. ローカル上でLambdaコンテナを起動し、
2. ローカルでイベントを渡して、
3. １回だけ実行できる
```
というコマンドでした。

一方、sam local start-lambdaは
```
1. ローカル上でLambdaのエミュレーター（エンドポイント）を作り、
2. ローカル上でAPIを起動して、
3. 複数回の動作確認を手軽に実行できる
```
というコマンドでした。

- Lambdaコンテナをローカル上で起動して呼び出すのがinvoke
- Lambdaのエンドポイントをローカル上で作成するのがstart-lambda
と覚えればよいと思います。
（invokeはLambdaを"起動"すること、start-lambdaは実行環境を"開始"すること、という意図の命名だと思います）
📘基本情報技術者試験のためのやさしいIT用語まとめ【自分用メモ　5月17日】

# 📘基本情報技術者試験のためのやさしいIT用語まとめ【自分用メモ　5月17日】

基本情報技術者試験の勉強を進める中で、わかりにくかった用語をできるだけやさしく、身近な言葉でまとめてみました！  
「言葉だけで混乱する」ことを減らしたい方におすすめの用語解説です✍️

---

## 💻 コンピュータの基本用語

### 🔹 ニモニックコード  
**コンピュータにわかりやすく命令を出すための、かんたんな文字のコード。**  
→ たとえば「ADD」「MOV」などの命令は、難しい機械語のかわりに使える省略記号。人間にとってもわかりやすくなる！

### 🔹 命令取り出し（フェッチ）  
**コンピュータが命令を1つ取り出す作業のこと。**  
→ 実行の最初のステップ。CPUが「次に何をするか」をメモリから読み込む！

---

## ⚙️ コンピュータの仕組みや管理

### 🔹 メモリリーク  
**コンピュータが使っていたメモリ（作業のための机）を片づけずに放置しちゃうこと。**  
→ 長く続くと、メモリが足りなくなって動作が遅くなったり、止まったりしてしまう…

### 🔹 SDRAM  
**パソコンが「いま作業していることをすばやく覚えておくための特別なメモリ」。**  
→ CPUと一緒に高速でやりとりできる、作業用のメモリ。DDR SDRAMなどもよく出る！

### 🔹 ストライピング  
**データを小さく分けて、いくつかのハードディスクに分けて保存する方法。**  
→ 複数のHDDに同時にアクセスできるから、高速化される！RAID0などが代表例。

---

## 📩 通信やメールに関する用語

### 🔹 SMTP-AUTH  
**メールを送るときに「この人が本当にメールを送っていい人か？」をチェックするしくみ。**  
→ 不正なメール送信を防ぐための認証。SMTPとセットで覚える！

---

## 🏭 生産管理系の用語

### 🔹 MRP（資材所要量計画）  
**工場で「いつ・なにを・どれだけ作るか」を考えて、必要な材料をムダなくそろえるしくみ。**  
→ 生産スケジュールに合わせて、部品や材料をきちんと準備するための管理方法。

---

## 🕒 CPUのスケジューリング方式

### 🔹 ラウンドロビン方式  
**コンピュータが「みんなに順番で、同じ時間だけ仕事をさせる」しくみ。**  
→ みんな平等に処理できるけど、ひとつひとつが完了するまでに時間がかかることもある。

---

## 📝 まとめ

IT用語は、難しく感じても「身近なもの」に置きかえると一気にイメージしやすくなります！  
今後もこうした形で、試験対策メモをどんどんまとめていきます💪
Makefileの環境切り替えの提案

# 動機
Makefileでクロスコンパイル環境を実現したい。
切り替えの方法を楽にしたい。

## 一般的な方法
環境変数で指定する。
```bash
$ make ENV=linux all  # Linux環境
$ make ENV=win all    # Win環境
```
## 嫌だな、と思うところ
- TAB補完で出てこない
- 変数の名前を覚えてないといけない
- どれだけの環境があるかぱっとわからない

## 解決方針
ターゲット指定で環境を切り替えられるようにしたい

# 実現方法
## サンプル
```
.PHONY: all DEV_LINUX DEV_WIN

# MAKECMDGOALS による環境自動設定
# 最初に指定された DEV_XXX を ENV にいれる
ENV :=  $(firstword $(filter DEV_LINUX DEV_WIN,$(MAKECMDGOALS))

#####################################
# ENVによるコンパイラなどの切り替え
#####################################

# デフォルトターゲット
all: 
	@echo "building for $(ENV) with $(CC)"

# 環境切替ターゲット　何もしない
DEV_LINUX DEV_WIN:
	@:
```
## 実行サンプル
```
$ make DEV_WIN all
building for DEV_WIN with cc

$ make DEV_LINUX all
building for DEV_LINUX with cc
 ```
初心者ITエンジニア向け：将来性の高いキャリアを築くロードマップ【2025年版】

## はじめに  
デジタル化の加速、DX（デジタルトランスフォーメーション）推進、リモートワークの普及──これらはすべてITエンジニアへの需要を飛躍的に高めています。まだAIエンジニアではない、純粋なITエンジニアとしてのキャリア構築にフォーカスし、2025年以降も安定して市場価値を保つための具体的なステップを解説します。

---

## なぜITエンジニアの将来性が高いのか？  
### 1. DX推進と業務自動化の波  
- 製造、物流、金融、医療など幅広い業界で業務システムの刷新・自動化が急務  
- コードを書ける人材は“問題をシステムで解決できる”唯一の存在  

### 2. クラウドネイティブへの移行  
- AWS/GCP/Azureの利用率が急増中、サーバレスやマネージドサービスの導入が常識に  
- インフラ管理から解放された分、アプリケーション実装やアーキテクチャ設計の領域が拡大  

### 3. コンテナ＆マイクロサービスの定着  
- Kubernetesをはじめとするコンテナオーケストレーションが標準技術へ  
- マイクロサービス設計はスケーラブルなシステム構築の要。学べば即戦力に  

### 4. セキュリティ・ガバナンス強化のニーズ  
- サイバー攻撃の高度化に伴い、セキュアな設計・運用が必須要件に  
- セキュリティ知識を備えたエンジニアは市場価値がさらに向上  

### 5. リモートワークとグローバル案件  
- 地理的制約が薄れ、日本国外のハイレベルなプロジェクト参画も現実的  
- コミュニケーション力と自己管理能力を備えれば、年収レンジも大幅アップ  

---

## ITエンジニアに求められる基本スキル  
### 1. プログラミング言語・フレームワーク  
- **Go / Python / TypeScript**：高速処理・データ操作・フロントエンド開発  
- **フレームワーク**：Gin, Django/Flask, React/Vue.js など  

### 2. 基本ソフトウェア開発技術  
- **バージョン管理**：Git/GitHubを使ったブランチ戦略・コードレビュー  
- **設計原則**：SOLID、DRY、KISSを理解し、可読性と保守性を担保  

### 3. インフラ＆クラウド  
- **AWS/GCP/Azure基礎**：EC2/Compute Engine、RDS/Cloud SQL、S3/Cloud Storage  
- **IaC**：TerraformやCloudFormationで環境構築をコード化  

### 4. コンテナ＆オーケストレーション  
```bash
# Docker イメージビルド
docker build -t myapp:latest .
# Kubernetes デプロイ例
kubectl apply -f k8s/deployment.yaml
````

* Pod, Service, ConfigMap, Secret の基本操作をマスター

### 5. CI/CD＆自動化

* **GitHub Actions / GitLab CI** でビルド・テスト・デプロイを自動化
* **シェルスクリプト** や **Makefile** で日常タスクを効率化

---

## 今すぐ始めるロードマップ（30日プラン）

| Week | 目標           | 主要タスク                                              | アウトプット例                      |
| :--: | :----------- | :------------------------------------------------- | :--------------------------- |
|  1週目 | 環境構築＆Git基礎習得 | ・Git/GitHubアカウント設定<br>・VSCode＋ターミナル環境整備            | README付きリポジトリ                |
|  2週目 | Webアプリ開発基礎   | ・フレームワーク選定（Flask/Express等）<br>・CRUD機能実装            | ユーザー登録・一覧表示API               |
|  3週目 | インフラ＆Docker化 | ・Dockerfile作成<br>・Docker ComposeでDB連携<br>・ローカル動作確認 | docker-compose.yml + 動作マニュアル |
|  4週目 | クラウド＆CI/CD   | ・Terraformでクラウド環境構築<br>・GitHub Actionsでデプロイ        | デプロイ用設定 + ステータスバッジ           |

---

## 初心者向けおすすめプロジェクト

* **個人ブログシステム**

  * Go＋Reactでフロント・バックエンド分離
  * Markdown投稿、コメント機能、CI/CD

* **チャットアプリ**

  * WebSocketを使ったリアルタイム通信
  * Docker＋Kubernetesでスケール検証

* **タスク自動化ツール**

  * PythonスクリプトでSlack通知や定期処理
  * cron＋Dockerでコンテナ実行

---

## 習得を加速する５つのコツ

1. **毎日30分、必ずコードを書く**
2. **Qiitaに学習ログを投稿**（タグ付けで発見されやすく）
3. **OSSにIssueやPRで貢献**
4. **勉強会・コミュニティに定期参加**
5. **ポートフォリオを常に更新**（GitHub Pagesなどで公開）

---

## モチベーション維持のポイント

* **KPI設定**：「今月中にCI/CDパイプラインを構築」など具体的に
* **進捗共有**：週次でSNS／Slackに書く
* **メンターを見つける**：技術共有の約束をすると継続しやすい
* **小休憩＋リワード**：タスク完了ごとに短いリフレッシュ時間を設ける

---

## まとめ

1. **ITエンジニアは今後10年、安定して高需要**
2. **30日間の集中プランで着実に基礎固め**
3. **日々の積み重ねが市場価値を大きく引き上げる**

── 今こそ手を動かし、将来性抜群のITエンジニアへの第一歩を刻もう！
NonNullable<T>の実装が簡略化されていた（TS 4.8）


# どしたん

TypeScript には、型 `T` から `null` と `undefined` を除外するユーティリティ型 `NonNullable<T>` が用意されています。過去の動画を参照していたところ、以下のような定義が使われているのを確認しました。

```ts
type NonNullable<T> = T extends null | undefined ? never : T;
```

一方、現在の TypeScript のバージョンでは、次のような実装に変更されています。

```ts
type NonNullable<T> = T & {};
```

この変化について気になったため、変更の経緯を調べてみました。

## 実装変更の背景

TypeScript 4.8 のリリースノートに、次のような記述がありました。

> Another change is that `{}` intersected with any other object type simplifies right down to that object type. That meant that we were able to rewrite NonNullable to just use an intersection with `{}`, because`{}` & null and `{}` & undefined just get tossed away.
> [TypeScript 4.8 Release Notes](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-8.html#errors-when-comparing-object-and-array-literals)

つまり、交差型の簡略化により、`T & {}` という形で `null` や `undefined` を自然に排除できるようになった、ということのようです。

具体的には、以下のような挙動が保証されるようになったとのことでした。

```
null & {}       → never
undefined & {}  → never
string & {}     → string
```

この結果、従来のように条件型を使わなくても `NonNullable<T>` の目的を達成できるようになった、というわけです。

## そもそも変更前の `NonNullable<T>` とは

`NonNullable<T>` は、型 `T` から `null` と `undefined` を除外するためのユーティリティ型です。従来の定義は次のとおりでした。

```ts
type NonNullable<T> = T extends null | undefined ? never : T;
```

この定義は、**分配型条件型（Distributive Conditional Types）** という機能を利用しています。

### 条件型の動作確認

以下のような型を定義するとします。

```ts
type A = string extends null | undefined ? null : boolean;
```

`string` は `null | undefined` に代入できないため、この評価結果は `boolean` になります。

一方、次のような型の場合：

```ts
type B = (string | null) extends null | undefined ? null : boolean;
```

このときは、`string | null` 全体が `null | undefined` に代入可能かどうかを判定するため、分配されず `boolean` になるようです。

ただし、以前までのNonNullableのようにジェネリクス型を用いた場合には、分配されるようになっています。

```ts
type NonNullable<T> = T extends null | undefined ? never : T;
```

```ts
type C = NonNullable<string | null | undefined>; // 結果: string
```

この処理の流れは以下の通りです。

1. `string extends null | undefined` → false → `string`
2. `null extends null | undefined` → true → `never`
3. `undefined extends null | undefined` → true → `never`

結果として、`string | never | never` → `string` となり、`null` と `undefined` を除外できるわけです。

## 実装が変更された理由

前述のとおり、TypeScript の型システムの仕様変更によって `{}` との交差による型の簡略化が行われました。これにより、以下のような効果が得られるようになったそうです。

```ts
null & {}       → never
undefined & {}  → never
string & {}     → string
```

これによって `T & {}` という記述だけで `null` や `undefined` を排除できるようになり、よりシンプルな形で `NonNullable<T>` を定義できるようになったとのことです。

## じゃあ無害なんですか
少なくとも、普通に使う分には問題はなさそう。

ありそうなところは、voidに交差型をすると
```ts
// 元の実装
type NonNullable_before<T> = T extends null | undefined ? never : T;

// 新しい実装
type NonNullable_new<T> = T & {};

// void型との相互作用
type Test1_before = NonNullable_before<void>; // void
type Test1_new = NonNullable_new<void>; // void & {}
```
となり、`void & {}`となってしまうことだったり、奥深いところで違ってkくる可能性がありそうです。

~~まぁ少なくとも私が関わってきた極細プロジェクトに影響出ることはないからヨシ！~~
お名前ドットコム　netlify google eorkspace

# お名前ドットコム
新規登録、または、ログインする
好きなドメインを取得する

# netlify
githubログイン
デプロイしたいリポジトリを選択
（next.jsのデプロイをした）
ビルドとデプロイが始まる
そのままデプロイできなかった

next.config.js
```
import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  output: 'export',
};

export default nextConfig;

```
↑これに修正

デプロイ設定で
`Build command`　は　`npm run build`
`Publish directory`　は　`out`

お名前のドメインを設定するときは`Domain management`から追加する

ネームサーバーをnetlifyの方にしないといけなくてそれはドメイン追加するときにコピペの案内が出るからそれをお名前にコピペする

# google workspace
ここをやろうとして詰んだ
元々google workspaceを先に設定していてその後にnetlifyを設定した
そうしたらメールが送受信できなくなった
（ネームサーバーをnetlifyの方にしていたから）
MXレコードとかちゃんと設定してるし、googleの公式のヘルプページ？説明ページ？見たいのも見てDigっていうやつ確認しろって書いてあって確認したら
`Record not found!`
って出るしわけわからんってなってた

MXレコードを登録しなおしたらこのネームサーバを登録してくださいとお名前のメールに書いてあり、そのネームサーバを登録したらメールの送受信ができるようになった

# netlifyとgoogle workspace
googleのためにネームサーバーを修正したらnetlifyでデプロイした方が404エラーで見れなくなった
これが厄介だった
お名前にnetlifyのネームサーバー登録してnetlifyでgoogleのDNSレコードを登録しないといけないらしい
難しいって
とりあえずnetlifyに集約して何とかなった
お名前で集約させる方法はわからなかったのでまた調べたい
VSCode Github copilotでAzureのエンドポイント(BYOK)を使う

# BYOK on VSCode github copilot
Vscodeの2025/4月のアップデートにて、AzureのエンドポイントなどのBYOK(Bring Your Own Key)を利用することができるようになった。

Vscodeのgithub copilotは無料（制限付き）＆有償で利用できる。が、企業でAzureのみ利用可能な場合、github copilotのライセンスまでなかなか出してくれるところは少ないはず。このためなんとか無料枠で耐えるか、個人で有償プラン加入をしている人には朗報で、Azureのエンドポイントを利用できるようになった。

実は2025/4月版から正式版でのAgent modeに加え、MCP Server接続もできるようになり、なにかとvscodeを使うことが増えてきたので、心配していたところだったので嬉しい限り。（ただし、現状まだ制限あり。）


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3288299/494bfc5e-141d-40ef-82dd-e57c0ad9060a.png)

## 設定方法
VSCodeにてcopilot chatを開き、チャットのモデル選択画面にて、Manage Modelsを選択。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3288299/9f8345f4-30ed-468c-bdd2-09fa718ff138.png)



Azureを選択

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3288299/6a9b2119-8676-4891-aa2d-f8eeace22cfe.png)


モデルIDを入力。モデルIDとは？？

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3288299/1e39993a-f449-465d-b664-a660f1bf15fd.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3288299/60812b25-bd5d-4c5e-91e8-bd14fdf09be0.png)


Azureポータルから該当デプロイの
Azure AI Foundry | Azure OpenAI→デプロイ→“モデル名”を指定した先の「モデルID」をコピペして入力する。

★モデル名やデプロイ名でないので注意！

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3288299/34dae9c4-b6ba-4ff8-bf15-001708e92dc0.png)


デプロイURLの入力

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3288299/87917ae6-4478-4977-a029-e2b97f0a3ce2.png)

Azureポータルから該当デプロイのAzure AI Foundry | Azure OpenAI→デプロイ→“名前”を指定した先の「ターゲットURI」をコピペして入力する。

★いつも入力のエンドポイントではないので注意！

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3288299/1a1907c0-11a3-4996-90c4-60e1fb0c8cb5.png)

APIキーの入力
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3288299/4fc94c22-b53a-4071-81d5-0a37a3f06127.png)

アドバンスト設定はYesにて詳細を。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3288299/03600cba-00d9-473f-91d5-faa5e35cc5f9.png)


MaxTokenSizeとoutputのmaxtokenの指定、Vision対応許可などがあるので設定する。トークンサイズは公式の値を拾うのが無難。（gpt-4.1なら1047576 / 32768 等）
※一度設定すると現状は修正ができず削除→再設定をする必要あり。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3288299/bb13e0ec-4903-423e-99f2-c1836be3e424.png)

https://learn.microsoft.com/ja-jp/azure/ai-services/openai/concepts/models?tabs=global-standard%2Cstandard-chat-completions#model-summary-table-and-region-availability

設定完了すると指定できるようになる。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3288299/85f3b4cf-9b9f-4985-838b-205c831b14e5.png)


## Agent modeについて
Agent modeについてはAzureのモデルは登録しても利用できなかった。（不具合？非対応？）
現時点では色々試したがダメだが、まだプレビュなのでじきに対応すると思われる。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3288299/369a000f-78dc-4a00-bb49-47dae7ade864.png)


なお、Gemini (2.5 Flash) についてはAPI Keyを登録すればAgent modeで実行可能だった。
https://ai.google.dev/gemini-api/docs/api-key?hl=ja

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3288299/0d485141-aec0-4c09-b560-313edfd16d94.png)
Raspberry Pi Zero w 2 でWifiに接続できない問題の解決方法

:::note warn
個人的な備忘録
:::

# 前提
+ Raspberry Pi Zero w 2
+ OSの書き込みはRaspberry Pi Imagerを使用
+ OSはRaspberry Pi OS Lite 32-bitを選択
+ 繋げるWifiはWPA2-PSKを使用

# 問題内容
Raspberry Pi Zero w 2にRaspberry Pi ImagerでOSを書き込み
電源をつなげると起動はするがWifiに接続できていないようで
IPアドレスが検出できない

# 解決方法
[こちらを参照](https://github.com/raspberrypi/linux/issues/4976)

1. SDカードにRaspberry Pi ImagerでOS書き込み
    1. Wifi接続情報は普通に設定
1. OS書き込み後、一度SDカードを抜き、もう一度差し込む
1. SDカードの`` ルート配下/cmdline.txt `` を開く
1. 行末に空白を挟み下記を追加する（改行はしない）
```
brcmfmac.feature_disable=0x82000
```

後は普通に電源をつなげればWifiにつながる
CentOS Stream 9 に Oracle Database 23ai Free をインストールする

タイトル通りの環境構築の備忘録です．

## 環境
CentOS Stream release 9
Oracle Database 23ai Free Release 23.0.0.0.0


## 手順
### 1. rpmパッケージのダウンロード

CLIからCurlで引っ張ろうとするとうまくいかなかったので大人しくサイトから引っ張ります．
[Oracleのダウンロードページ](https://www.oracle.com/jp/database/free/get-started/ "Oracleのダウンロードページ")よりrpmパッケージをダウンロードしましょう．
必要なものは下記の２つです．
- oracle-database-preinstall-23ai-1.0-2.el9.x86_64.rpm
- oracle-database-free-23ai-1.0-1.el9.x86_64.rpm

### 2. rpmパッケージのインストール
```bash:bash
$ sudo dnf install -y oracle-database-preinstall-23ai-1.0-2.el9.x86_64.rpm
$ sudo dnf install -y oracle-database-free-23ai-1.0-1.el9.x86_64.rpm

```

### 3. データベース構成

```bash:bash
$ sudo /etc/init.d/oracle-free-23ai configure
Specify a password to be used for database accounts. Oracle recommends that the password entered should be at least 8 characters in length, contain at least 1 uppercase character, 1 lower case character and 1 digit [0-9]. Note that the same password will be used for SYS, SYSTEM and PDBADMIN accounts:
Confirm the password:
Configuring Oracle Listener.
Listener configuration succeeded.
Configuring Oracle Database FREE.
SYSユーザー・パスワードを入力してください:
**********
SYSTEMユーザー・パスワードを入力してください:
***********
PDBADMINユーザー・パスワードを入力してください:
*********
DB操作の準備
7%完了
データベース・ファイルのコピー中
29%完了
Oracleインスタンスの作成および起動中
30%完了
33%完了
36%完了
39%完了
43%完了
データベース作成の完了
47%完了
49%完了
50%完了
プラガブル・データベースの作成
54%完了
71%完了
構成後アクションの実行
93%完了
カスタム・スクリプトを実行中
100%完了
データベースの作成が完了しました。詳細は、次の場所にあるログ・ファイルを参照してください:
/opt/oracle/cfgtoollogs/dbca/FREE。
データベース情報:
グローバル・データベース名:FREE
システム識別子(SID):FREE
詳細はログ・ファイル"/opt/oracle/cfgtoollogs/dbca/FREE/FREE.log"を参照してください。

Connect to Oracle Database using one of the connect strings:
Pluggable database: vbox/FREEPDB1
Multitenant container database: vbox
$ 
```
ここまで完了したらデータベースの構成が完了です．
次は実際に接続できるか確認します．
### 4. データベース接続
```bash:bash
$ export ORACLE_HOME=/opt/oracle/product/23ai/dbhomeFree
$ export PATH=$ORACLE_HOME/bin:$PATH
$ export ORACLE_SID=FREE
$ sqlplus sys as sysdba
SQL*Plus: Release 23.0.0.0.0 - Production on 土 5月 17 19:11:14 2025
Version 23.7.0.25.01

Copyright (c) 1982, 2025, Oracle.  All rights reserved.

パスワードを入力してください: 


Oracle Database 23ai Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free
Version 23.7.0.25.01
に接続されました。
SQL> 
```
無事に接続できました．
ちなみに，接続できたはいいものの下記のように文字化けすることがあります．
```
Oracle Database 23ai Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free
Version 23.7.0.25.01?????????????
```
この場合`$ export NLS_LANG=Japanese_Japan.AL32UTF8`とすれば直ります．

以上です．
OracleDB管理機能学習まとめ

# 挨拶
初めまして、日本システム開発株式会社の鈴木です。
技術者として更なる向上を目指すためQiitaアウトプットをする取り組みを行っています。
技術者としては経験が浅く発信内容はとにかく試したものの覚書になります。
今回は資格取得勉強中に苦戦したOracleデータベース管理機能について備忘録を書いていきます。

## Oracle Universal Installer(OUI)
Oracle Universal Installer (OUI) は、オラクル社が提供するJavaベースのグラフィカルなインストールツールです。BronzeDBA試験では以下の機能について出題範囲となっています。

## デフォルト値
Oracleユーザの環境変数は任意ですが設定することでOUIのデフォルト入力となります。対象になる環境変数はORACLE_BASE（ORACLEソフトウェアやデータファイルの起点となるディレクトリ）ORACLE_HOME(ORACLEソフトウェアの配置ディレクトリ)ORACLE_SID（ORACLEインスタンスの識別子）があります。

### インベントリ管理
インストールされたOracle製品の情報（Oracleホーム、インストールディレクトリ、バージョンなど）をインベントリディレクトリに記録・管理します。これにより、システムにインストールされているOracle製品の情報を一元的に把握できます。「oraInventoryグループ名」はOracleインベントリグループであるOSグループ（通常oinstall)を指定する必要があります。

### 前提条件チェック
インストール前に、オペレーティングシステムのバージョン、必要なパッケージ、ディスク容量、メモリ要件など、インストールに必要な前提条件が満たされているかどうかを自動的にチェックします。

## EM Express（Enterprise Manager Express）
EM Expressを使用すると、Webブラウザを通じて以下の主要な管理タスクをタブごとに実行できます。反面、DB自体の起動/停止、バックアップ/リカバリ機能はありません。
### パフォーマンス監視
CPU使用率、メモリ使用量、I/O統計などのシステムパフォーマンス情報をリアルタイムに監視できます。
SQLチューニングアドバイザ・SQLパフォーマンスアナライザが選択できます。
過去のパフォーマンス情報をグラフで表示することも可能です。その場合は「パフォーマンスハブ」を用いて
### 記憶域管理
表領域の使用状況、データファイルや制御ファイルの情報などを確認できます。
表領域の拡張やデータファイルの追加などの基本的な管理操作もWebインタフェースから実行できます。
### セキュリティ
データベースユーザーの作成、編集、削除などのユーザー管理操作を行えます。
ロールの作成や削除といった基本的なセキュリティ設定も可能です。
### 構成管理
データベースの初期化パラメータの編集が可能です。

## Oracle Enterprise Manager Cloud Control
Oracle Enterprise Manager Cloud Control（通常、Cloud ControlまたはOEMと呼ばれます）は、オラクルの包括的なエンタープライズ管理プラットフォームです。EM Expressが単一のデータベースインスタンスの管理に特化しているのに対し、Cloud Controlは、複数のデータベース、アプリケーションサーバー、ミドルウェア、ハードウェア、オペレーティングシステムなど、広範囲にわたるコンポーネントを一元的に管理することを目的としています。
### 表領域管理
EM Expressは表領域の管理を行えますが、CloudControlではスキーマの管理も行えます。また、インスタンスの起動/停止も行うことができます。
### バックアップ
Cloud Controlではリカバリ/バックアップが可能です。
【Next.js】build時に環境変数を参照した静的ファイルを出力させる方法

## 本記事から得られること
- Next.jsでbuild時に静的ファイルを出力させる方法
- build時にenvファイルを読み込ませる方法
- image loaderの使い方


## こんな人向け
- Next.jsでフロントエンドを作成しており、S3へ静的Webホスティングを行いたい人
- build時に環境変数が読み込まれず、undefinedになって苦しんでいる人
- S3にファイルをアップロードしたものの、画像が上手く出力されない人


## 自己紹介 🧑‍💻
最近AWSを本格的に触り始めたnaokiです。

案件に入りながら自社（SES）サービスの立ち上げメンバーとして、PM兼テックリードとしてMVP開発を進めています。

今回、MVPのフロントエンドをS3にWebホスティングを行うことになり、静的ファイルを出力する際に苦戦したので、方法と詰まった箇所を書き留めておこうと思います。


## 技術スタック(バージョン)
```
Next.js: 15.1.4
TypeScript: 5.8.3
npm: 11.1.0
node: 22.11.0
```

## 内容
### 1. 静的ファイルの出力設定をする
next.config.jsを開き、以下のように設定します。

```
const nextConfig = {
  output: 'export',
  trailingSlash: true
}

module.exports = nextConfig
```

もしくは、

```
const nextConfig = {
  output: 'export' as const,
  trailingSlash: true
}

module.exports = nextConfig
```
と設定します。
　
 
2つの設定事項については以下の通りです。
```
output: 'export' -> 静的ファイルを出力するために必要な設定
trailingSlash: true -> パスに階層がある場合に必要な設定
```

これらの設定を行うと、`npm run build` で静的ファイルが出力されるようになります。

https://nextjs.org/docs/app/guides/static-exports

 
https://nextjs.org/docs/app/api-reference/config/next-config-js/trailingSlash

---

### 2. 画像の最適化を行う
S3にファイルをアップロードした後、画像が反映されない事象が発生しました。
反映されなかった画像は、`next/image`を用いたImageコンポーネントを用いているもののみで、解決するには**画像の最適化**を行う必要がありました。

以下、公式ドキュメントを引用します。

> Image Optimization through next/image can be used with a static export by defining a custom image loader in next.config.js.

つまり、next.config.jsでimage loaderの設定を行うことで表示させることができます。

```
const nextConfig = {
  output: 'export',
  trailingSlash: true,
  images: {
    loader: 'custom',
    loaderFile: './my-loader.ts',
  },
}
 
module.exports = nextConfig
```

　
今回開発していたサービスのディレクトリ構成は以下のようになっていました。
```
frontend
├─ src
|  └─app
├─ ...
└─ next.config.js
```
　
app配下にimage loaderのファイルを置きたかったので、以下のように設定しました。

```
const nextConfig = {
  output: 'export' as const,
  trailingSlash: true,
  images: {
    loader: 'custom' as const,
    loaderFile: 'src/app/image-loader.ts',
  },
};
```

#### image-loader.ts (参考)
```
export default function imageLoader({
  src,
  width,
  quality,
}: {
  src: string;
  width: number;
  quality?: number;
}) {
  // 画像のパスがすでに完全なURLの場合はそのまま返す
  if (src.startsWith('http')) {
    return src;
  }

  // それ以外の場合は、width と quality パラメータを追加
  return `${src}?w=${width}&q=${quality || 75}`;
}
```
　
そして、Imageコンポーネントを用いている箇所で読み込ませます。(参考)
```
import imageLoader from '@/app/image-loader';

/** 省略 **/

<Image
  loader={imageLoader}
  src='/images/header/register.png'
  alt='登録'
  width={20}
  height={20}
/>
```

これで画像が最適化された状態で出力できるようになります。
 
---
### 3.(環境変数を用いている場合) env内の環境変数を読み込ませる
2まで行った後にS3にファイルをアップロードしたのですが、環境変数が上手く読み込まれない問題が発生しました。

環境変数が読み込まれない原因は、build時に.envが弾かれていることが原因です。
npmパッケージの```env-cmd```で解決する流れはこちらから↓

https://qiita.com/nkkn_prog/items/2197b7e99de371647073

### その他参考記事
https://dev.classmethod.jp/articles/nextjs-static-cache/


## 終わりに
ここまで読んでいただき、ありがとうございました！
今回は、Next.jsの静的ファイル出力や画像最適化、環境変数の罠について、実際に詰まった経験をもとにまとめてみました。同じようにハマっている方の助けになれば嬉しいです。もし「ここが分からない」「こうしたらもっと良くなったよ」などあれば、ぜひコメントやフィードバックをもらえると励みになります！
IntelliJ IDEAをGit bashから実行できるよう格闘した話

### 何の記事か
Javaユーザーならだれもが使ったiIntteliJ IDEA(以下idea）。windowsでは
```bash
idea64.exe .
```
で[カレントディレクトリを開けるらしい](https://pleiades.io/help/idea/opening-files-from-command-line.html)が長い。そこで
```bash
idea .
```
とたたけば起動してほしい。

### 解決まで

まずはコマンドの実行先を見に行く。
```bash
$ where idea64.exe
C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2025.1\bin\idea64.exe
```
ふむふむ。ここにあるのか。

余談だがGit bashにて`C:\Program Files`へチェンジディレクトリをするには
```bash
cd \c\Program/ Files
```
のように空白をエスケープする必要がある。

さてここではシェル関数を`~/.bashrc`に記載することで解決しよう。`~/.bashrc`とは…

> #### .bashrc は、Bash シェルが起動されるときに自動的に読み込まれる設定ファイルです。主に以下のような目的で使われます：
> 🧾 .bashrc の概要
> - 項目	内容
> - 目的	Bash（ログインしないシェル）が起動されるときに、自動的に実行される設定
> - 使い道	エイリアス定義、関数定義、環境変数の設定、プロンプトのカスタマイズなど
> - 対象	インタラクティブ・非ログインシェル（例：Git Bash、WSLの新しいターミナルなど）
> - 位置	通常は ~/.bashrc（~ はホームディレクトリ）に存在
> - 使用タイミング	ターミナルを開いたとき、または bash を新しく起動したときに読み込まれる

らしい。GPTさんが言っていました。さて

```bash
vim ~/.bashrc // vimを起動
# ~/.bashrc に追記。`:wq`で保存
idea() {
  "/c/Program Files/JetBrains/IntelliJ IDEA Community Edition 2025.1/bin/idea64.exe" "$@"
}
```
を実行。ターミナルのタブを一度閉じるか、
```bash
source ~/.bashrc
```
を実行。これで目的が達成されました。うれしい。
「立体四目並べAIのルールベース実装と戦略ガイド」

# 立体四目並べAIの実装と戦略
# 目次
- [はじめに](#はじめに)  
- [ゲームの基本ルール](#ゲームの基本ルール)  
  - [盤面サイズ](#盤面サイズ)  
  - [勝利条件](#勝利条件)  
- [AIの基本戦略](#aiの基本戦略)  
- [問題点と改善案](#問題点と改善案)  
- [今後の展望](#今後の展望)  
- [まとめ](#まとめ)  

## はじめに

今回は、立体四目並べAIの実装についてまとめます。これは通常の四目並べにZ軸を追加した拡張版であり、駒を縦・横・奥行きに積み上げるルールで構築しています。この記事では、基本的な実装から、単純な勝ち手や防御の戦略までを解説し、今後の改良点についても触れます。
この記事を読めば、ルールベースでの立体四目並べAIの基本実装と、その戦略ロジックをサクッと理解できるようになります
## AI戦略の選定理由
今回、実装したAIは機械学習ではなく、自分の頭を整理する目的と処理の軽さ、実用化しやすさ、短期間でも安定した結果を残しやすいルールベースを採用しました。

## ゲームの基本ルール
### ルールの概要

* **盤面サイズ**: 4x4x4
* **勝利条件**: 任意の方向に同じ色（駒）が4つ連続で並ぶこと
* **駒の積み方**: 各列においてZ軸方向に積み上げていく

### 勝利の判定

* 横・縦・奥行き方向
* 対角線
* 3次元の斜め

## 初期実装と基本戦略

### 基本アルゴリズム

実装したAIは、以下のような基本戦略に基づいています。
今回は、長くなるのでソースコードは省いています
最後に、添付してあるGithubのページからソースコードの飛べるのでそこから確認してみてください

1. **勝ちの一手**

   * 自分が3連続している場合、4目を揃える手を優先。方向ベクトルをもちいて盤面を調べて、そろうところがあれば置きます

2. **相手の勝ちを防ぐ手**

   * 相手が3連続している場合、それを阻止する手を優先。上記の逆です
3. **必勝形を防ぐ**
    * 作れば勝ちの形である必勝形を相手が作るのを防ぐ
4. **四隅一番下優先**
   * 四隅の一番下に配置します。基本的に最初における場所の中で一番優先度が高い気がします。
5. **リーチ作成**
    * 自分がリーチを作れるよう、自分の駒のみが2つある列に置く。これは次の相手の行動を強制できます。
6. **中央優先**
    * 最大7方向の4目が狙える非常に価値の高い場所や必勝系にもかかわってくる
7. **四隅一番上優先**
    * ここも7方向の4目が狙える位置です
8. **リーチ阻害**
    * 相手がリーチを作ないよう、相手の駒のみが2つある列に置く。これでダブルリーチなども防げます
9. **ランダムな手**
   * 見つからない場合は妥協で、空いている位置にランダムに配置。

基本的な考え方は、
3マス揃っている状態や、必勝の形ができる寸前など次の一手で勝ち負けが決まる際の行動を優先度を一番高くしています。
他は、序盤で意識する手や勝つことにも、相手の勝ちを防ぐことにもつながる高い価値の、位置を防いだりする手もなども意識して優先順位を付けました。
正直、ここら辺は自分でも迷うところなので実践で調整した部分もあります


## 問題点と改善案

* **必勝パターンの検出**

  * 今回はそろった寸前しか検知しないので、攻撃面での検討が難しかったです。また、攻撃に使用するためには、どこら辺のタイミングでどこの位置で必勝形を作成しようかのルールを定義できなかったので難しかったです。
* **攻撃パターンの強化**

  * 単なる勝ち手の発見だけでなく、より積極的な攻撃手を考慮するアルゴリズムに進化させたい。攻撃は防御よりも計画性が必要なため、今回のような、今の盤面だけを見て、決めるようなルールでは難しかったです

## 今後の展望(次に取り組みたいこと)

- ターン数に応じた戦略の導入  
  - 序盤・中盤・終盤で優先すべき着手を切り替える仕組み。  
- ログ記録 → 新勝ち筋ルール定義 & 強化学習  
  - 自動生成したゲームログから有効パターンを抽出してAIを強化。  
- 勝利パターンの優先度設定  
  - 価値の高い連結線をスコア化し、AIの評価関数に組み込む。  
- 人間の直感に近い判断ルール導入  
  - “コーナーは安全地帯”などヒューリスティックを追加。  
- 強化学習モデルの組み込み  
  - ルールベース＋学習ベースのハイブリッドAIへの発展。  

## おわりに
本記事では“行き当たりばったり”のルールベースAIを実装しましたが、初心者〜中級者相手なら十分勝負できます。  
次のステップとして、ターン数による戦略分岐や強化学習を組み込んだハイブリッドAIの開発を目指していきます。  

ご意見・ご質問はコメントでお待ちしています！

## 参考リンク

* [Reactで作成したコードが書かれているサイト](https://github.com/H10-1217-MY/3D4row)
* [一応こちらで遊べます](https://h10-1217-my.github.io/3D4row/)
今回は、ルールベースのAIを実装することが目的だったのでUIはかなり適当で、このUIのおかげで人間の勝率はかなり低いです
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3841466/a4a3d69d-c532-4a8d-9635-6fd55d7364e1.png)
Flutterで汎用的なバリデーション基盤を作る

# はじめに
Flutterでのフォームバリデーションの基盤を作成してみました。
バリデーションルール（ValidationRule）とバリデーター（Validator）を定義し、
各入力に対してルールを通じて検証（validate）する仕組みを実装しています。

# 見出し
- Validationの基盤を作成する流れ
    1. Validation rulesを作成
    1. 基盤となるValidatorを作成
    1. 作成したValidation rulesを使用し、TextField専用のValidatorを作成


## 参考コード
https://github.com/life-with-meat/flutter_todo_clean_arch_riverpod/tree/releases/base_validation

# Validationの基盤を作成する流れ


### Validation rulesを作成
`core/validation/rules`配下にバリデーションルールを作成していきます。
※ 今回の例として、２つのValidation ruleを作成します。
※ 新たにルールが必要な場合は、`core/validation/rules`配下に追加してください。

`abstract`を使用して、Validation ruleで共通となるインターフェイスを作成します。

```validatoinRule.dart
abstract class ValidationRule {
  String? validate(String value);
  String get errorMessage;
}
```

「必須」ルールとして、RequiredRuleを実装します。

`ValidationRule`インターフェースを`implements`して、`RequiredRule`クラスを作成します。

```required_rule.dart
class RequiredRule implements ValidationRule {
  @override
  String? validate(String value) {
    return value.trim().isEmpty ? errorMessage : null;
  }

  @override
  String get errorMessage => '入力してください';
}

```

文字数制限ルールとして、LengthRuleを実装します。

RequiredRuleと同様に、`ValidationRule`インターフェースを`implements`して、`LengthRule`クラスを作成します。

```dart:length_rule.dart

class LengthRule implements ValidationRule {
  final int? maxLength;
  final int? minLength;

  const LengthRule({this.maxLength, this.minLength});

  @override
  String? validate(String value) {
    final trimmed = value.trim();
    if (maxLength != null && trimmed.length > maxLength!) {
      return '$maxLength文字以内で入力してください';
    }
    if (minLength != null && trimmed.length < minLength!) {
      return '$minLength文字以上で入力してください';
    }
    return null;
  }

  @override
  String get errorMessage => '文字数制限を超えています';
}

```


### 基礎のValidatorを作成

```dart:

class Validator<T> {
  final List<ValidationRule> rules;

  const Validator(this.rules);

  String? validate(T value) {
    for (final rule in rules) {
      final error = rule.validate(value.toString());
      if (error != null) return error;
    }
    return null;
  }

  /// 指定された型のルールを取得
  R? getRule<R extends ValidationRule>() {
    for (final rule in rules) {
      if (rule is R) {
        return rule;
      }
    }
    return null;
  }
}
```


### 作成したValidation rulesを使用し、TextField専用のValidatorを作成

`Validator`クラスを継承して`TextFieldValidator`を作成します。
Validation rulesは、`TextFieldValidator`のコンストラクタ時に、`super([...])`を使用して親クラスの`Validator`に渡します。

```dart

class TextFieldValidator extends Validator<String> {
  TextFieldValidator({int? maxLength, int? minLength, bool required = true})
    : super([
        if (required) RequiredRule(),
        if (maxLength != null || minLength != null)
          LengthRule(maxLength: maxLength, minLength: minLength),
      ]);

  int? get maxLength => getRule<LengthRule>()?.maxLength;
  int? get minLength => getRule<LengthRule>()?.minLength;

  @override
  String? validate(String value) {
    final trimmed = value.trim();
    return super.validate(trimmed);
  }
}


```

## 最後に

汎用的なValidationを作成してみました。
まだまだ改善が必要ようそうなので、更新していきたいです。