OmniAICreator/Qiita-1.07M huggingface dataset:
AWSアーキテクチャの設計原則とWell-Architected Framework

# AWSアーキテクチャについて

## 設計原則

### リージョンとAZの活用
- 1つのリージョンにつき2つのAZを利用してアーキテクチャを設計すること
- 3つ以上はコスト効率が低下するため、2つが適切
- ロードバランサ―によるトラフィック制御するのが基本的な姿
- インスタンス、DBどちらもマルチAZ構造を採用することで、サーバーやDBの冗長構成を確立し高い可用性を実現する

### VPC
- 基本的に1つのアプリケーションは1つのVPCで設計すること
- ネットワークの通信の連携などが複雑になってきてしまうが、システムを複数にわけることが必要な場合に２つ以上利用することもある（テスト用と本番用にわける場合などはVPCを分割する）
- ネットワークの分割方法は`マルチVPC方式`と`マルチアカウント方式`がある
  - マルチVPC方式：アカウント内のVPC自体をシステムによってわけていくこと
  - マルチアカウント方式：アカウントごとにVPCを持っており、所有するシステムをわけていることによって分割すること

### サブネットの分割
- インターネットアクセスに必要なものだけをパブリックサブネットに配置
- `/24`以上のサブネットマスクによる設定が推奨されている
- プライベートサブネットに多くのIPアドレスを割り当てることが一般的

### データの分散
- 別リージョンにDBのレプリカを配置するなどしてデータアクセスを分散する
- 冗長性を確保することで災害対策としても良い

## Well-Architected Framework

AWSで推奨されるクラウド設計原則（ベストプラクティス）のこと。
6本の柱で体系化している。

1. __優れた運用効率（Operational Excellence）__  
   システムの実行とモニタリングおよびプロセスと手順の継続的な改善に焦点を当てる
   - コードに基づいて運用実施を自動化
   - ビジネス目的に沿った運用手順を整備する
   - 定期的かつ小規模に運用手順を更新する
   - 予期せぬイベント発生に備えて事前にプロセスを確認する
   - 運用イベントと障害から学習して運用手順を更新する
   - 常に運用手順を最新のものにしておく
2. __セキュリティ（Security）__  
   情報とシステムの保護に焦点を当てる
   - すべてのレイヤにおいてセキュリティを適用
   - アクセス追跡・モニタリングを実施
   - 条件によるアラートをトリガーとしてセキュリティイベントへの応答を自動化する
   - AWS責任共有モデルに基づく対象範囲の保護に集中
   - セキュリティのベストプラクティスの自動化
3. __信頼性（Reliability）__
   期待通りの機能を実行するワークロードと異常時に迅速に回復する方法に焦点を当てる
   - 基本対応領域は基盤、変更管理、障害管理
   - 障害復旧の自動化による影響を軽減する設計を行う
   - 復旧手順をテストして事前に検証しておく
   - 需要変化に応じた水平方向へのスケーラビリティによる高可用性を確保する
   - モニタリングと自動化を進める
   - キャパシティの推測をやめる（オートスケーリング）
4. __パフォーマンス効率（Performance Efficiency）__  
   IT およびコンピューティングリソースの構造化、合理化された割り当てに焦点を当てる
   - システム要件を満たすためのコンピューティングリソースを効率化する
   - AWSサービスの進化に応じてAWSインフラの効率化を推進する
5. __コストの最適化（Cost Optimization）__ 
   不要なコストの回避に焦点を当てる
   - 不必要なリソースを削減
   - コストを計測して透明性のある費用賦課を実現（コストを分析していく）
   - マネージド型サービスを利用して運用コストを削減
   - 固定の償却コストを変動コストへと転換
   - スケールによるコストメリットを享受する
   - データセンターへの投資を不要にする
6. __持続可能性（Sustainabillity）__  
   実行中のクラウドワークロードによる環境への影響を最小限に抑えることに焦点を当てる

### Well-Architected Framework の活用方法

準拠するために以下のガイドラインやツールなどが提供されている。

- **Well-Architected Framework ホワイトペーパー**  
  クラウドの知識を深めるために提供される技術情報。  
  原則やベストプラクティスについて説明したり AWS クラウドでのシステム設計や運用に役立つガイダンスを提供している。
- **Well-Architected Framework パートナープログラム**  
  AWS の SA または認定パートナーによる支援制度。  
  サポートを受けて実装やベストプラクティスの適用に関する助言や支援を得ることができる。
- **セルフチェック向けの Well-Architected Tool**  
  ワークロードの状態を評価しベストプラクティスと比較するための無料ツール。  
  自身の AWS 環境やアプリケーションの設計を評価し、改善のための指針を得ることができる。

あくまでこれらはベストプラクティスを利用することで最適解や改善点を把握するため参考にするもので、絶対ではない。

要件定義を検討する材料、適切な設計の材料として、インフラ構成にリスクや改善点がないかを確認するものとして、運用として定期的にレビューを行う観点としてホワイトペーパーなどを使用すると良い。

## まとめ

AWSの設計では「ベストプラクティスの理解」と「ビジネス要件とのバランス」が鍵となる。

ベストプラクティスを理解していればリスクだったり改善点に気付くことができるため、 **ベストプラクティスを理解した上でビジネス的に判断すること** が重要。
rex0220 計算式プラグイン チェックボックス単一選択その２

[計算式プラグイン](https://qiita.com/rex0220/items/ae83c6d5ce50ff7a9a73)で、チェックボックスの単一選択のその２です。

# 概要

複数の選択肢を持つチェックボックスを単一の選択にする例その２です。
[rex0220 計算式プラグイン チェックボックス単一選択](https://qiita.com/rex0220/items/94c4d51cf4edb906087b) の制御項目を文字列項目一つにします。
対象のチェックボックスが増えても制御項目を増やさずに済みます。

![2025-06-04_10h31_46.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100572/83939161-3382-4c2e-8aa8-48cee0335ef0.png)

# 操作例

![2025-06-04_10h38_18.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100572/6233e48f-7a0f-4631-a9cf-1a518e78a514.gif)

# フォーム設定

文字列で制御用項目を配置します。

![2025-06-04_10h34_38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100572/6ad8f453-064b-41ac-957d-820e04393ded.png)

# 計算式プラグイン設定

制御用項目に、JSON形式で複数のチェックボックスの選択肢を保存します。
チェックボックスが複数選択の状態になったら、制御用項目にある以前の選択肢を除外します。

![2025-06-04_10h33_17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100572/1ff82824-8a4f-4ed4-a326-712028205e51.png)

```JavaScript:
OPTION: 循環参照を許可

// チェックボックス CHECK_BOX (editable)
IF(ARRAY_COUNT(チェックボックス)>1,
  ARRAY_DEL(チェックボックス, DIC_ITEM(JSON_P(制御用),"チェックボックス")),
  ARRAY(チェックボックス)
)

// チェックボックス２ CHECK_BOX (editable)
IF(ARRAY_COUNT(チェックボックス２)>1,
  ARRAY_DEL(チェックボックス２, DIC_ITEM(JSON_P(制御用),"チェックボックス２")),
  ARRAY(チェックボックス２)
)

// 制御用 SINGLE_LINE_TEXT
JSON_S(DIC(
  "チェックボックス", ARRAY(チェックボックス),
  "チェックボックス２", ARRAY(チェックボックス２)
))
```
VSCodeで「php.validate.executablePath」のエラーにハマった話とMac環境での正しいPHP設定方法


## 🐘 はじめに

MacでVSCodeとPHPを使って開発しているとき、突如として現れたこのエラー：

```
Cannot validate since a PHP executable is not set.
Use the setting 'php.validate.executablePath' to configure the PHP executable.
```

「え、ちゃんとPHP入れてるのに……？」と動揺。しかもなぜか設定ファイルにはWindowsのパスが混入していて混乱。

この記事では、このエラーが起きた背景から、Mac環境での正しい対処法、設定ファイルの修正手順までを詳細に解説します。

---

## 🧨 エラーの原因

### ✅ 原因1：VSCode設定にWindowsのPHPパスが残っていた

過去にWindowsでXAMPPを使っていた名残で、以下のような設定が `settings.json` に残っていました：

```json
"php.executablePath": "C:\\xampp\\php\\php.exe"
```

Macでは使えないパスなのに、VSCodeがこれを見に行こうとしてしまい、PHPのバリデーションができなくなっていた。

### ✅ 原因2：Mac環境にインストールしたPHPのパスが正しく設定されていない

Macでは通常、Homebrew経由でPHPをインストールすると、実行ファイルの場所が `/usr/local/bin/php` または Apple Silicon 環境なら `/opt/homebrew/bin/php` にあります。

このパスを明示的にVSCodeに教えてあげる必要があります。

---

## 🛠️ 対処法

### 1. 現在のPHPパスを確認

```bash
which php
```

出力例：

```
/usr/local/bin/php
```

または M1/M2 Mac なら：

```
/opt/homebrew/bin/php
```

### 2. `settings.json` を修正

VSCodeの設定ファイル `settings.json` を開き、以下のように修正します：

```json
"php.validate.executablePath": "/usr/local/bin/php"
```

※ `which php` の出力に合わせて適宜変更してください。

### 🔍 settings.jsonの開き方（初心者向け）

1. **VSCodeの左下ギアアイコン（⚙️）をクリック**
2. 「**設定（Settings）**」を選択
3. 右上の「**{}アイコン（設定ファイルを開く）**」をクリック
   → これで `settings.json` を直接編集できます！

### 3. Windowsパスが混在していたら削除！

以下のような記述は Macでは不要なので削除します：

```json
"php.executablePath": "C:\\xampp\\php\\php.exe"
```

---

## ✅ 修正後の設定ファイル例

```json
{
  "php.validate.enable": true,
  "php.validate.executablePath": "/usr/local/bin/php",
  "php.validate.run": "onType",
  "php.suggest.basic": true,
  "php.problems.exclude": {}
}
```

---

## 🧪 HomebrewでPHPのインストール状況を確認したいとき

```bash
brew list | grep php
```

バージョンを確認するには：

```bash
php -v
```

PHPの複数バージョンがある場合、切り替えには `brew link` を使います：

```bash
brew link --overwrite --force php@8.2
```

---

## 😫 詰まったポイント・気持ちの記録

* 「Windowsの設定残ってるとか罠すぎない！？💥」
* 「そもそも `php.validate.executablePath` が何をしているのか分からなかった」
* 「HomebrewでPHP入れたのに `command not found: php` が出てパニック」
* 最後には「`which php` の神さまありがとう🙏」ってなった。

---

## 🎉 結果

* エラーが消えて、VSCodeがPHPを正しく認識！
* バリデーション・補完・エラーチェックがしっかり動作✨
* 設定ファイルの謎も理解が深まって気持ちスッキリ！

---

## 🔚 まとめ

MacでVSCodeを使う際は、過去のWindows設定が残っているとエラーの原因になります。

特に `php.validate.executablePath` のパス設定はとても重要です。

以下の3ステップで解決できます：

1. `which php` で現在のパスを確認
2. `settings.json` を修正
3. 古い設定を削除

同じエラーに悩む人のヒントになれば嬉しいです！

---

## 💬 コメント歓迎！

「わたしもハマった！」「M1 Macではこうだった！」などあれば、ぜひコメントで共有してください🙌

---

## 🧷 参考リンク

* [Visual Studio Code - PHP extension](https://marketplace.visualstudio.com/items?itemName=felixfbecker.php-debug)
* [Homebrew 公式サイト](https://brew.sh/index_ja)
AWS 接続に関するメモ

この記事に対して、ネガティブな書き込みや指摘はご遠慮下さい
基本的な備忘録として随時更新しております。

```
Transit Gateway

仮想プライベートクラウド（Amazon VPC）とオンプレミスネットワークを相互接続するために使用できる
ネットワークの中継ハブ（クラウド上にあるルータ）

料金は以下
アタッチメントごとの料金 (USD):0.07 USD　　　 ⇨ 10.06円
処理データ 1 GB あたりの料金 (USD) :0.02USD　⇨　2.87円

メリット
1.ネットワークの統合管理が容易になる
⇨一元管理されたネットワークインフラを提供し、異なるVPCやオンプレミスのネットワークを簡単に接続できるため

2.VPN接続を集約できる
⇨VPCごとにVPN接続が必要だったのが1つに集約できるため、VPN接続料金を大幅に減らすことができる

3.AWS Direct Connectとの接続を集約できる
⇨ルーティングで接続するVPCの制御が可能になり、VPC間通信も制御ができるようになる。

■デメリット
複数のVPCやVPNを接続する場合、ルーティングテーブルの設定が複雑になり、運用難易度があがる。﻿

接続数の制限:Transit Gatewayには、接続できるVPCやVPNの数に制限が存在する。﻿

セキュリティグループの相互参照不可
VPC Peeringでは、セキュリティグループを相互に参照できますが、Transit Gatewayではできない。

その他
NAT Gatewayの影響について
Transit GatewayとNAT Gatewayを組み合わせる際、アプリケーションの送信元IPアドレスが変化するため、外部システムとの連携に影響が出るリスクも考慮する必要がある。

コスト
Transit Gatewayの月額固定費はVPN接続よりも高い場合もあり、データ転送料金も追加で発生する。
```
Direct Connect Gateway

```
Direct Connectは(オンプレ環境とAWSを繋ぐ専用線)を意味する

仮想プライベートゲートウェイ (VGW) とプライベート仮想インターフェイス (VIF) をグループ化する機能

料金は以下
AWSのリージョンとAWS Direct Connectのロケーションが日本国内の場合、0.0410 USD/GBとなる

□メリット
1.低コストのデータの転送送信料金
⇨アウトバウンドのデータの転送送信料金を削減できる。

2.高品質なネットワーク
専用線を利用するので、高スループットで低遅延の通信が可能。

3.セキュリティレベルの安全性の向上
インターネットを介さずに独立した専用ネットワークで通信するのでセキュリティリスクが低減する。

4.安定性と信頼性
3と同じくインターネットを経由しないので回線の状況に影響されずに安定した通信が確保できる。

■デメリット
・回線の準備が必要になる
ユーザー拠点から「AWS Direct Connecロケーション」までの回線、その他セキュリティに関しては「サービス範囲外」になるのでユーザー自身で用意する手間が発生する。
単一回線では AWS メンテナンス時に通信できなくなるので、回線の冗長化が必須となる
VPN 接続と違い Direct Connect 接続は転送中の暗号化は行われない。
⇨転送中に何らかの暗号化を行う必要がある点は注意事項
最大で20個までのVPCしか接続できない。Direct ConnectGWで接続した VPC 同士は相互に接続不可。



```

AWS Transit Gateway

```
個人学習時の注意点。

1.VPCにわかりやすい名称をつけること
2.敷居が高すぎる資料を参考にしないこと
3.一定の段階まで勧めたら記録を取得しておくこと

個人的な感想
思ったより設定箇所が多かったし、最初は思っているより難しく見えます。
なのでTransit Gatewayに関しては最初の段階ではpingが通るまでで一区切りにしてみる。

その後次のステップへ進むなど。
一気に理解しようとしないことが挫折防止になるかもしれません。

```
貧困の撲滅：AIに何ができるのか？

ジェフリー・D・サックスは２００５年１２月３０日に"The End of Poverty"を出版した。それに先立つ３月６日付けのTimeにその要約を掲載した。それを短くまとめる。

私たちの世代で極度の貧困を終わらせることは可能だ。毎年８００万人が貧しさゆえに命を落としている。少しの支援があれば彼らは生き延び、成長できるはずだ。

「貧困が殺す」

１日１ドル未満で暮らし、食糧・医療・安全な水・教育・住まい・衣服など生存に不可欠なものを欠く状態が極度の貧困だ。世界銀行によれば１１億人が該当する。

臨床経済学

貧困の原因は多面的だが、その解決策も多面的だ。そのため診断と総合的な処方箋が必要だ。それを可能にするのが臨床経済学だ。アメリカは軍事費に５０００億ドルを投じながら、最貧層支援には国民所得の0.15％しか費やしていない。

サウリ村の５つの大介入策

１．農業生産性の向上  
２．基礎医療の充実  
３．教育への投資  
４．電力と交通・通信の供給  
５．安全な水と衛生の確保  

である。

2025年に極度の貧困を終わらせる９ステップ

１．貧困撲滅という目標の達成  
２．行動計画をもつ  
３．貧しい人々の声を届ける  
４．米国の役割を回復  
５．IMF・世銀を再生  
６．国連を強化  
７．科学技術の力を活用  
８．持続可能な開発を推進  
９．個人の関与  

その後の分析  

サックスが提言した方策を、多くの人たちが実現しようとした。しかし、２０２５年現在、部分的には達成されたが、COVID１９、気候変動、紛争という予期せぬ事態があり、不平等、ガバナンスという根強い構造的問題があるため、２０３０年になっても、その達成は不可能である。当時の貧困率は２８％、貧困者数は１８億人であったが、現在は８.５％、７億人である。

これらの失敗の要因は、確かに戦略が楽観的過ぎたという部分もある。しかし、より根本的には援助の押し付けになっていることだ。必要なのは自立した貧困の撲滅だ。

AIで何ができるのか？

現地主体の意思決定を最優先し、自立型開発システムをつくることだ。

極度の貧困撲滅は依然として実現可能だが、技術と制度を「所有者＝当事者」にするガバナンス転換が不可欠であり、AI はその加速装置として機能し得る。

これが 2025 年時点で得られた最大の示唆である。
ONES Projectの「かんばんボード」でタスク管理をラクラク視覚化しよう！

## はじめに
プロジェクト管理をよりスムーズに、そしてチーム全体で見える化したい・・・。そんな時にオススメなのが、[ONES Project](https://systemcon.co.jp/products/onesproject/)の「かんばんボード」機能です！

今回は、ONES Projectのかんばんボードの基本的な使い方から、効果的な活用方法までをわかりやすく解説します。

## かんばんボードって何？
かんばんボードは、タスクや課題を「カード形式」で視覚的に管理できる便利なツールです。ONES Projectのかんばんボードは、次のような特徴があります。

* **タスク状況が一目でわかる！**：課題がカードとして表示されるので、進捗が一目で確認できます。
* **自由にカスタマイズできるカラム**：「未着手」「進行中」「完了」など進行状況に合わせたカラムを自由に設定できます。
* **リアルタイムで更新**：チームメンバーがタスクを更新すると、ボード上にすぐに反映されます。
* **ドラッグ＆ドロップ操作**：課題カードを動かすだけで、直感的に進捗を変更できます。

## ONES Project「かんばんボード」の基本操作
### 1. かんばんボードを表示する
1. プロジェクトのメイン画面から「カンバン」を選択します。
2. デフォルトで「作業前」「進行中」「完了」などのカラムが表示されますが、チームに合わせて自由にカスタマイズできます。

![かんばんボードの表示.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3483972/95ba7739-861f-436a-b8bc-11e140c04776.png)

### 2. 課題の作成と管理
* **新しい課題を作る**
画面右上にある「＋ 課題」をクリックして新しい課題カードを追加できます。タスク名、担当者、期限、優先度など項目を設定しましょう。

![新しい課題を作る.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3483972/1fb40994-cf07-494c-b3bf-0e26fd78eb76.png)

* **課題の詳細を確認＆編集**
カードをクリックすると詳細画面が開くので、いつでも簡単に確認・編集できます。

![課題の詳細を確認.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3483972/ff479668-b961-4758-8468-c66f2e6ce3a7.png)

* **課題を移動（進捗状況の更新）**
カードをドラッグ＆ドロップで別のカラム（ステータス）に移動するだけで、進捗状況をすぐに更新できます！

![課題を移動.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3483972/6a743ffb-3161-41e9-b5a1-7d74c657d949.png)

## まとめ：ONES Projectのかんばんボードでプロジェクトをもっとラクに見える化！
ONES Projectのかんばんボードなら、チーム全員がタスク管理の状況を、リアルタイムで共有できプロジェクトをスムーズに進められます。

ドラッグ＆ドロップの直感的な操作で、誰でも簡単に使えるので、チームの業務効率がグンとアップすること間違いなしです。

かんばんボードの作り方と細かな設定については、また[別の記事で紹介しますね！](https://qiita.com/SystemConcierge/items/2f75d6fe38d9a210e57a)

プロジェクト管理をもっと簡単に、効果的にしたいなら、ぜひONES Projectのかんばんボードを試してみてください！
備忘録その1（PHPの歴史）

# 今更の今更、PHPと仲良くなりたくなった

## はじめに
これは、僕がただ「そういや、これってどういう起源で誕生した言語なんだっけ」「どういう目的で生まれたんだっけ」を一から勉強するための備忘録です。特に役立つことを発表したりはしませんが、ご容赦ください。

## PHPの誕生（1994年）
- 作者はRasmus Lerdorf
- 自分のWebサイトのアクセス記録をとりたくてC言語でツールを自作
- 名前は「Personal Home Page Tools（PHP Tools）」

## なぜWebに特化していたのか？
- 当時のWebはHTML + CGIが主流
- PHPはHTMLの中に埋め込めて、動的処理がすぐできた
- “プログラミング初心者でも使いやすい”という点が大ヒット

## PHP3.0以降の進化
- 世界中で使われるようになり、オープンソース化
- PHP3.0（1998年）でオブジェクト指向が導入
- PHP4.0〜7.0で速度・安全性・拡張性が強化

## 自分が感じたこと
- 「便利にするための言語」ではなく「誰かの課題を解決するために生まれた言語」だった
- 僕自身、普段は不安を抱えていたり、踏み出す勇気が出ないメンバーの後押しをするのが大切に思っているので、この起源は自分の価値観にも合ってるな、と今更気付いた笑

## 参考資料
- https://www.php.net/manual/ja/history.php.php

## 次
CGIについて
片っ端から備忘録に上げていくぞ
【城間勝行】ChatGPTを設計レビューに使ってみた

最近、ChatGPTを日常的に開発に取り入れていますが、なかでも「設計レビュー」に使ってみたところ、意外と実用的だったので簡単に共有します。

■ 背景
フリーランスとして少人数のスタートアップと開発していると、設計レビューをする時間も人も足りない、という場面が多々あります。
でも、レビューって実はかなり重要。特に複数人で開発する際は、初期設計のズレが後々の技術的負債に直結します。

そこで、「AIに初期レビューさせてみよう」と軽い気持ちで試してみました。

■ 使い方（ざっくり）
機能要件と設計メモ（例：ユーザー認証＋API設計）をMarkdownでまとめる

ChatGPTに貼り付けて、「技術的な観点からレビューして」と依頼

指摘内容をもとに、自分で再考＋修正

必要に応じて、コードサンプルを求める

■ 実際に言われたこと
「このエンドポイントはRESTの原則から外れていませんか？」

「スキーマ設計がこのままだとN+1問題が出る可能性があります」

「この認可ロジック、業務上のルールと整合性取れてますか？」

…など、けっこう鋭い指摘も多く、単なる表面的なチェックだけでなく、思考の整理ツールとしても有効だと感じました。

■ メリットと注意点
メリット：

時間のないときでも最低限のレビューを受けられる

自分の思考を言語化する練習になる

特定技術に偏らない「広めの視点」をもらえる

注意点：

100%鵜呑みにしない（前提がズレてる場合も）

文脈の共有はできるだけ丁寧に

機密情報はもちろんNG

■ まとめ
ChatGPTを「技術顧問」的に使うのは、特にフリーランスや小規模開発チームにとって強い味方になります。
レビュー文化をゼロから作るより、まず「AIと1on1レビュー」から始めるの、けっこうおすすめです。

「AIを使ったレビュー、気になってた」という方は、ぜひ一度試してみてください！
storage class 2: Functions, The C Puzzle book

職業訓練
https://qiita.com/kaizen_nagoya/items/95368b63fa21d64271ec

Programmer, Day 6
https://qiita.com/kaizen_nagoya/items/632d8f191268e88eb86a

C Puzzle Bookの有り難み5つ、C言語規格及びCコンパイラの特性を認識, error(21), coding(28)
https://qiita.com/kaizen_nagoya/items/d89a48c1536a02ecdec9

The C Puzzle Book
https://efrei.poupa.net/Programmation%20en%20C/Cours/The_C_Puzzle_Book.pdf

defs.h "The C Puzzle Book"
https://qiita.com/kaizen_nagoya/items/6d284651ac1244963bd9


```c:sc2.c
#define LOW 0
#define HIGH 5
#define CHANGE 2

int i=LOW;

void main(void)
{
        auto int i=HIGH;
        reset( i/2 ); PRINT1(d,i);
        reset( i=i/2 ); PRINT1(d,i);
        i = reset( i/2 ); PRINT1(d,i);

        workover(i); PRINT1(d,i);       // (Storage Classes 2.1)
}

int workover(int i)
{
        i = (i%i) * ((i+1)/(2*i) + 4);
        PRINT1(d,i);
        return(i);
}

int reset(int i)
{
        i = i<=CHANGE ? HIGH : LOW;
        return(i);
}




```

```shell-session:bash
$ gcc sc2a.c
sc2a.c: In function ‘main’:
sc2a.c:12:9: warning: implicit declaration of function ‘reset’ [-Wimplicit-function-declaration]
   12 |         reset( i/2 ); PRINT1(d,i);
      |         ^~~~~
sc2a.c:16:9: warning: implicit declaration of function ‘workover’ [-Wimplicit-function-declaration]
   16 |         workover(i); PRINT1(d,i);       // (Storage Classes 2.1)
      |         ^~~~~~~~
inst19@teachB:~$ ./a.out
i = 5
i = 2
i = 5
i = 0
i = 5
```
【備忘録】ラップ型について

## 初めに
とある関数に処理をさせて、その返り値を元にあれやこれやしよう！としたとき、その処理が正しく処理されたかは、戻り値からだとわかりませんよね。
例えば、割り算をする関数があったとします。
分母が０だと計算できずエラーになる為、例外として処理できますが、これだと呼び出し元の処理であれやこれやがしずらいですよね。
```cs
public int Divide(int numerator, int denominator)
{
    if (denominator == 0)
    {
        throw new DivideByZeroException("0で割ることはできません");
    }
    return numerator / denominator;
}
```
それを解消方法として、ラップ型という方法があります。
今回は、そのラップ型についてのメモです。

## ラップ型とは何か
ラップ型（Wrapper Type）は、あるデータや値を「包み込む」ことで、追加の情報や機能を付加した型のことを指します。
言い換えると、**「元データ単体では扱いにくい部分を改善するために、それを包んで別の形で扱えるようにした型」** のことです。

例えば、「初めに」で記載した「その処理が正しくできていたか」は
以下の**Resultクラス**の「成功か失敗かの状態」や「エラーメッセージ」などの付加情報を加えるとで分かります。
``` cs
public class Result<T>
{
    public bool IsSuccess { get; }  // 成功かどうか
    public T Value { get; }         // 成功時の値
    public string Error { get; }    // 失敗時のエラーメッセージ
}
```
このように「元の値 + 追加情報」で返すことで、より扱いやすくする型がラップ型です。

よく使われる用途として、
**・成功や失敗の状態を一緒に返したい。**
**・追加情報を格納したい（例：エラーについての詳細情報など）。**
があります。

## 実際のコード
割り算を計算する処理を例に作成します。
・Result：ラッパー、Divideをラップする結果のクラス
・Divide：割り算を計算する処理
・Main：メインの処理


#### Resultクラス
```cs:Result.cs
public class Result<T>
{
    public bool IsSuccess { get; }  // 成功かどうかを示すプロパティ
    public T Value { get; }         // 成功時に返す値
    public string Error { get; }    // 失敗時のエラーメッセージ
    private Result(T value, bool isSuccess, string error)
    {
        IsSuccess = isSuccess;
        Value = value;
        Error = error;
    }
    // 成功の時の静的メソッド
    public static Result<T> Success(T value)
    {
        return new Result<T>(value, true, null);
    }
    // 失敗の時の静的メソッド
    public static Result<T> Failure(string error)
    {
        return new Result<T>(default, false, error);
    }
}
```
Resultクラスには、成功と失敗のメソッドを用意しインスタンス時にそれぞれの結果を格納しています。
成功時には結果を与え、失敗時には、エラーメッセージを付けることで原因が明確化します。

#### Divideメソッド
```cs
public Result<int> Divide(int numerator, int denominator)
{
    if (denominator == 0)
    {
        return Result<int>.Failure("エラー: 0で割り算はできません");
    }
    int result = numerator / denominator;
    return Result<int>.Success(result);
}
```

メソッドの返り値の型を**Resultにラッピングされたint型**にします。
```cs
return Result<int>.Failure("エラー: 0で割り算はできません");
```
ResultのFailureメソッドでエラー理由を渡して、失敗判定にしています。

```cs
return Result<int>.Success(result);
```
ResultのSuccessメソッドで、計算結果を渡して、成功判定としています。


#### Mainメソッド
```cs
public  void main ()
{
  Var result = Divide(10, 2);
  If (result.IsSuccess)
  {
      Console.WriteLine($"成功しました！ 結果は: {result.Value}");
  }
  else
  {
      Console.WriteLine($"失敗しました。理由: {result.Error}");
  }
}
```
代入されている**result**はResult\<T>クラスなので、
**IsSuccess**を使うことで成功・失敗の判定ができ、
成功時はValueを使うとDivideの結果を取得し、
失敗時はErrorでエラー理由を取得することが出来ます。

## 最後に
今回の例は、割り算処理にResultクラスをラップしましたが、他にもデータ通信やファイル操作など処理の成功・失敗を明確にしたい処理にラップすることでより扱いやすくすることが出来ます。
以上、ラップ型のメモでした。


##おまけ
Result\<T>のTが何かというと、ジェネリクス（Generics） というC#の仕組みで使われる **「型引数（Type Parameter）」** の名前です。
ジェネリクスでは、具体的なデータ型（例: int, string, MyClass など）を明示せず、 **「まだ決まっていない型」** を表すために、仮の記号（プレースホルダー）として名前を使います。
なぜTなのかと言うと、 "Type" (型)の略称で、「ここに型が入るよ」と示唆しています。
ただの名前なので、Result<Type>としても問題が無いらしいですが、今までの慣例的にResult\<T>が主流らしいですね。
New Relicの新機能を安心して使おう！ Advanced CCUとCompute Management画面活用術

New Relicは、日々新しい機能やサービスがリリースされます。その中で「これ、使ってみたいけど、どんな風に活用できるんだろう？」「料金がどうなるのか気になる…」といった疑問をお持ちの方もいらっしゃるのではないでしょうか。今回は、そんな皆さんの疑問を解消し、New Relicの強力な機能を最大限に活用していただくための鍵となる「**Advanced CCU**」と、その力を最大限に引き出す「**Compute Management画面**」についてご紹介します。

# Advanced CCUとは？
Advanced CCUは、New Relicにおける新たな利用形態であり、従来のユーザーモデルによるFull Stack Observabilityに加えて、より高度なコンピューティングリソースを利用するための契約オプションです。Compute Capacity Unit(CCU)という単位で、実際に機能を利用して消費したCCU分だけ請求というものになります。Advanced CCUを契約することで、New Relicの最新かつ最先端の機能をスムーズにご利用いただけるようになります。New Relicが今後提供していくであろう革新的な機能の多くは、Advanced CCUを基盤として設計されています。どのような機能にAdvanced CCUが必要になるのかは[公式ドキュメント](https://docs.newrelic.com/jp/)などをご確認ください。

# Compute Management画面でできること
Advanced CCUを契約すると、New Relicプラットフォーム上に「**Compute Management**」という新しいメニューが表示されます。この画面は、皆さんのCCU利用状況を可視化し、最適化するための強力なダッシュボードになります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/53287/455884c5-10ab-452e-b4be-63671b518ae7.png)
  
Compute Management画面では、主に以下のことが実現できます。
* **CCU消費状況の可視化**: 契約しているCCUがどの程度利用されているのかを把握できます
* **CCU消費量の内訳分析**: 機能別やアカウント別、ユーザー別のCCUの消費状況の内訳を詳細に確認できます。これにより、リソース消費の多い箇所を特定し、改善策を講じることが可能になります
* **利用トレンドの分析**: 過去のCCU利用履歴をグラフで確認し、利用量のトレンドを分析できます。これにより、将来的なリソース需要を予測し、計画的な利用料の増強や最適化に役立てることができます

このCompute Management画面を活用することで、皆さんはNew Relicの高度な機能を安心して使いこなし、最適なコストで最大のパフォーマンスを引き出すことができるようになります。

# プレビュー機能の利用料金の見積もりにも活用可能
Compute Management画面の特に注目すべき機能の一つに、「`Non-billableトグル`」があります。これは、現在プレビュー提供されている機能の使用状況を、現在の請求に影響を与えることなく確認できる画期的な機能です。新機能やベータ機能を試す際、「これを使ったら、どのくらい料金がかかるんだろう？」と不安に思うことはありませんか？ このNon-billableトグルを切り替えることで、実際にその機能を利用した場合のCCU消費量をシミュレーションし、将来の利用料金を見積もることができます。
これにより、安心して新しい機能を試すことができ、導入の計画や予算策定に役立てることが可能です。New Relicは常に新しい技術を積極的に取り入れていますが、皆さんがその最先端の恩恵を最大限に享受できるよう、このような透明性の高い仕組みを提供しています。

![スクリーンショット 2025-06-04 9.57.34.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/53287/8a24e8f0-8294-469a-8b58-2f2b32c6cb69.png)


# 新機能をスムーズに試すためにAdvanced CCUを
繰り返しになりますが、New Relicが今後提供していく革新的な機能の多くは、Advanced CCUを前提として設計されています。例えば、複雑な分散環境における高度なトレース解析や、AIを活用したプロアクティブな問題検知など、New Relicの未来を担う機能は、Advanced CCUの柔軟なコンピューティングリソースによって支えられています。
もし、あなたがNew Relicの最先端の機能をいち早く試してみたい、または将来的に高度なオブザーバビリティを実現したいと考えているのであれば、契約にAdvanced CCUを含めておくことを強くお勧めします。Advanced CCUがあれば、新たな機能がリリースされた際に、スムーズに試用を開始し、すぐにその効果を実感できるでしょう。

# まとめ
New RelicのAdvanced CCUとCompute Management画面は、皆さんのNew Relicの利用体験を次のレベルへと引き上げる強力な組み合わせです。
* **Advanced CCU**：New Relicの最新機能を活用するための契約オプション
* **Compute Management画面**：Advanced CCUの利用状況を詳細に可視化し、最適化を支援するダッシュボード
* **Non-billableトグル**：プレビュー機能の将来の料金をシミュレーションし、安心して新機能を試せる

これらの機能を最大限に活用し、New Relicと共にあなたのシステムのオブザーバビリティをさらに深化させていきましょう。

:::note info
[New Relic株式会社のQiita Organization](https://qiita.com/organizations/newrelic)では、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。
:::
:::note info
無料のアカウントで試してみよう！
[New Relic フリープランで始めるオブザーバビリティ！
](https://qiita.com/ktst79/items/5ee74b34e6adb8a7a6fa)
:::
[![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/535230/66d6a010-e4fe-4004-a09b-c01eaad5a614.png)](https://newrelic.com/jp/contact-sales)
storage class 3: More Functions, The C Puzzle book

職業訓練
https://qiita.com/kaizen_nagoya/items/95368b63fa21d64271ec

Programmer, Day 6
https://qiita.com/kaizen_nagoya/items/632d8f191268e88eb86a

C Puzzle Bookの有り難み5つ、C言語規格及びCコンパイラの特性を認識, error(21), coding(28)
https://qiita.com/kaizen_nagoya/items/d89a48c1536a02ecdec9

The C Puzzle Book
https://efrei.poupa.net/Programmation%20en%20C/Cours/The_C_Puzzle_Book.pdf

defs.h "The C Puzzle Book"
https://qiita.com/kaizen_nagoya/items/6d284651ac1244963bd9

```c:sc3.c
#include "defs.h"
int i=1;

int reset();
int next(int);
int last(int);
int new(int);

int main()
{
	auto int i, j;
	i = reset();
	for ( j = 1; j <= 3; j++)
	{
		PRINT2(d, i, j);
		PRINT1(d, next(i));
		PRINT1(d, last(i));
		PRINT1(d, new(i + j));
	}
}

int reset()
{
	return (i);
}

int next(int j)
{
	return ( j = i++ );
}

int last(int j)
{
	static int i = 10;
	return ( j = i-- );
}

int new(int i)
{
	auto int j = 10;
	return ( i = j += i );
}

/*
nagai@compB05:~/Conpairu$ ./a.out
i = 1   j = 1
next(i) = 1
last(i) = 10
new(i + j) = 12
i = 1   j = 2
next(i) = 2
last(i) = 9
new(i + j) = 13
i = 1   j = 3
next(i) = 3
last(i) = 8
new(i + j) = 14
*/
```
```shell-session:bash
$ gcc sc3.c
$ ./a.out
i = 1   j = 1
next(i) = 1
last(i) = 10
new(i + j) = 12
i = 1   j = 2
next(i) = 2
last(i) = 9
new(i + j) = 13
i = 1   j = 3
next(i) = 3
last(i) = 8
new(i + j) = 14
```
storage class 1: file, The C Puzzle book

職業訓練
https://qiita.com/kaizen_nagoya/items/95368b63fa21d64271ec

Programmer, Day 6
https://qiita.com/kaizen_nagoya/items/632d8f191268e88eb86a

C Puzzle Bookの有り難み5つ、C言語規格及びCコンパイラの特性を認識, error(21), coding(28)
https://qiita.com/kaizen_nagoya/items/d89a48c1536a02ecdec9

The C Puzzle Book
https://efrei.poupa.net/Programmation%20en%20C/Cours/The_C_Puzzle_Book.pdf

defs.h "The C Puzzle Book"
https://qiita.com/kaizen_nagoya/items/6d284651ac1244963bd9


```c:sc1.c
#include "defs.h"

int i = 0;

int main()
{
        auto int i = 1;
        PRINT1(d, i);         // (1)
        {
                int i = 2;
                PRINT1(d, i);     // (2)
                {
                        i += 1;
                        PRINT1(d, i); // (3)
                }
                PRINT1(d, i);     // (4)
        }
        PRINT1(d, i);         // (5)
}

/*
nagai@compB05:~/Conpairu$ ./a.out
i = 1
i = 2
i = 3
i = 3
i = 1
*/
```
```shell-session:bash
$ gcc sc1.c
$ ./a.out
i = 1
i = 2
i = 3
i = 3
i = 1
```
チェックボックスの値を復元

今回はセッションに持たせ、複数のチェックボックスを保持することを考慮しました。
if (Session["checkbox"] != null)
{
checkedStates = Session["checkbox"] as Dictionary<string, bool>;
}else{
checkedStates = new Dictionary<string, bool>();
}

既にチェックがあればセッションから取得、なければ新規で作成をする。

// クリックされたチェックボックスから行を特定する
CheckBox target = (CheckBox)sender;
GridViewRow row = (GridViewRow)target.NamingContainer;

//復元する際の主キーを取得する
string ID = grdList.DataKeys[row.RowIndex].Value.ToString();

// 行番号を取得
int rowIndex = row.RowIndex;

// チェックボックスの状態取得
bool isChecked = target.Checked;

// キーを指定しチェックボックスの状態を保持
checkedStates[ID] = isChecked;

// 取得した情報をセッションに保存
Session["checkbox"] = checkedStates;

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
再バインド時
grdOwnedShipList.DataSource = DtOwnedShipList;
grdOwnedShipList.DataBind();


// セッションからチェックボックスの状態を取得
var checkedStates = Session["checkbox"] as Dictionary<string, bool>;
// データが存在するか確認
if (checkedStates != null)
{
//最新のグリッドビューを1行ずつ見ていく
foreach (GridViewRow row in grdList.Rows)
{
//データ行か念のため確認
if (row.RowType != DataControlRowType.DataRow)
{
continue;
}
//行を特定する為のキーとして[ID]を取得する
string ID = grdList.DataKeys[row.RowIndex].Value.ToString();
CheckBox chk = row.FindControl("chk") as CheckBox;

//キーを元にチェックボックス復元
if (chk != null && checkedStates.ContainsKey(shipId))
{
chk.Checked = checkedStates[shipId];
}                            
}
}
【比較してみる】並び替え機能のデータ設計、どの方式が良いの?

## はじめに

ToDoアプリやタスク管理ツールを作っていると、「あれ、このレコードたちの順序ってどうやってDBで管理するのが正解？」ってなることありませんか？
小規模ならなんとなくで済ませがちですが、ユーザーが並び替え機能を多用し始めると「思ったより運用がしんどいぞ？」となることも多いです。

今回は「順序付きリストをどうDB設計するか？」というテーマで、代表的な3パターンをサクッとまとめておきます。
一通りメリデメや使い所も添えてみたので、悩んでる方の参考になればうれしいです。



## 並び替えのアプローチの代表例

### 1. 序数（整数インデックス）方式

最初に思いつくのがこの「順序番号（orderカラムとか）」を各レコードに持たせるパターンです。
例えばこんな感じ↓

| id | name | order |
| -- | ---- | ----- |
| 1  | りんご  | 1     |
| 2  | ゴリラ  | 2     |
| 3  | らくだ  | 3     |

順序の管理はシンプル。
1, 2, 3... のように番号を振って、`ORDER BY order` で好きな順に出せます。

ただし並び替えや挿入が頻繁だと、途中に1件追加したい時とか、前後のレコードを全部更新する必要が出てきます。
タスクを「3番目から1番目」に持っていく、みたいな場合も同様です。

**メリット**

* 実装がシンプル
* SQL初心者でもわかりやすい

**デメリット**

* 並び替えや追加が多いと、更新件数がどんどん増える
* 大規模・高頻度な並び替え用途にはあまり向かない

---

### 2. float（分数インデックス、Fractional Indexing）方式

最近流行りのやつ。
sort\_index カラムに float 値を入れて「並び順」を表現します。

例えば↓

| id | name | sort\_index |
| -- | ---- | ----------- |
| 1  | りんご  | 100.0       |
| 2  | ゴリラ  | 200.0       |
| 3  | らくだ  | 300.0       |

「ゴリラ」と「らくだ」の間に新しいアイテムを挿入したい場合、
(200.0 + 300.0) / 2 = 250.0 みたいに、中間値を計算して入れるだけ。

移動の場合も同じで、間に入れたい時はその間の値にするだけで済みます。
ドラッグ＆ドロップUIとの相性も良いです。

**メリット**

* 並び替え・挿入時に「1件だけ」更新で済む
* パフォーマンスが安定しやすい
* Trello や Notion などでもこの方式が使われている

**デメリット**

* 何度も間に挿入しまくると、小数点以下がどんどん細かくなりリインデックスが必要になる場合がある
* 実装がやや複雑になる

参考：[Realtime Editing of Ordered Sequences | Figma Blog](https://www.figma.com/blog/realtime-editing-of-ordered-sequences/)

---

### 3. Linked List（前後IDでつなぐ）方式

ちょっとマニアックだけど「prev\_id」や「next\_id」を持たせて、レコード同士をつなぐ方式もあります。

| id | name | prev\_id |
| -- | ---- | -------- |
| 1  | りんご  | NULL     |
| 2  | ゴリラ  | 1        |
| 3  | らくだ  | 2        |

データベース上で「実際にリスト構造を再現する」イメージです。

レコードの移動・削除は、前後のレコードの prev\_id/next\_id だけ更新すればOK。
（ただし、隣接関係の更新ロジックが必要で、SQLだけだとちょっと扱いづらい）

**メリット**

* 挿入・削除が隣接レコードだけの更新で済む
* 極端な場合にも対応しやすい

**デメリット**

* 実装がやや複雑、SQLだけでゴリゴリやるのは面倒
* 順序付きで全件取得したい場合は再帰 or N+1問題に注意

---

## それぞれの使いどころ & ベストプラクティス

* **序数（整数）方式**
  シンプルな管理画面・レコード数が少ない or 並び替え頻度が低いケースにおすすめ。
  「時々順序を変えたい」程度ならこれで十分。

* **float（分数/Fractional Indexing）方式**
  並び替え・挿入が多い、もしくはドラッグ＆ドロップUIを作りたい時は圧倒的にこっち。
  TrelloやNotionの「スムーズな並び替え」体験を自作したいなら迷わずどうぞ。

* **Linked List方式**
  極端な並び替え・挿入・削除操作や、何らかの事情で順序情報以外にも「リスト的な構造」を活かしたい場合に。
  （個人開発やお遊びプロジェクトで試してみるのもアリ）

## まとめ

* 並び替えのDB設計、用途や規模によって選ぶ方式が変わります
* 小規模・簡単な用途なら「序数方式」
* ドラッグ＆ドロップや大規模リストなら「float（Fractional Indexing）方式」
* リスト構造そのものを活かしたい・チャレンジしてみたいなら「Linked List方式」

どれを選ぶにしても、「運用後にどうなるか？」をイメージして設計するのがコツです！
他にも「こんな方法あるよ」とか「運用で詰まった話」あればぜひコメントで教えてもらえるとうれしいです。

## 参考資料
https://www.figma.com/blog/realtime-editing-of-ordered-sequences/
【太治奨揮】技術選定で迷わないための3つの視点

プロジェクトが立ち上がると、必ず議論になるのが「技術選定」。
ReactかVueか？RailsかFastAPIか？最近では「とりあえずNext.js」となりがちですが、本当にそれでいいのでしょうか。

これまで10年以上、多様な現場で開発してきた中で、「選定で迷わないために意識すべき視点」がいくつか見えてきました。今回はその中から3つを紹介します。

1. チームの技術資産に合っているか
トレンドの技術を使いたくなる気持ちはわかります。ですが、開発は一人では完結しません。既存のナレッジやリソースと親和性があるかどうかは、立ち上がりのスピードにも大きく影響します。

「学習コスト」よりも「継続可能性」に目を向けると、後々の運用が楽になります。

2. スケールと保守性のバランス
初期段階では「小さく作る」が正解。でも、そのまま大きくなるケースも珍しくありません。
そのとき、「機能を追加しやすい構造か」「メンテが属人化しないか」は中長期で見たときに重要です。

最近では、FastAPIやtRPCなど、開発スピードと保守性を両立できるフレームワークも増えてきました。目的に応じた選択が鍵です。

3. プロダクトのフェーズを見極める
技術選定は「どれがベストか」ではなく、「いま何を重視するか」で決まります。

・初期検証段階：スピードと仮説検証のしやすさ
・成長段階：安定性と開発体制の拡張性
・成熟段階：保守・運用負荷の最小化

プロダクトのライフサイクルに応じて、選択肢は変わるはずです。

僕自身、過去に「流行っているから」と選んだ技術で、運用フェーズで苦労したこともあります。逆に、堅実な選定がプロジェクトを支えてくれた経験もあります。

技術選定に正解はありませんが、「なぜこれを選ぶのか」を言語化できれば、チームにとっても大きな力になります。

こんな視点が誰かの参考になれば幸いです。
まとめ ~ JavaScript の非同期を理解する

## まとめ ~ JavaScript の非同期を理解する

本記事は、個人的に学んだ JavaScript の非同期処理についてまとめた記事シリーズのまとめとなります。
まだ読んでいない方は、よければぜひご覧ください。

- 第 0 章 [はじめに](https://qiita.com/ZawaP/items/40bf6bac110c9e02fe45)
- 第 1 章 [JavaScript の歴史と特徴](https://qiita.com/ZawaP/items/87147c38dd2ec754b86e)
- 第 2 章 [JavaScript 実行モデル (ECMAScript が定める実行モデル)](https://qiita.com/ZawaP/items/cff743fc724e72ee3b8c)
- 第 3 章 [ブラウザでの JavaScript の実行 (HTML Living Standard が定める実行モデル)](https://qiita.com/ZawaP/items/16cafaba3b60bf2b2d71)
- 第 4 章 [実装レベルで見る JavaScript の実行 (V8 & Chromium)](https://qiita.com/ZawaP/items/d185453455dd80cc2b68)
- 第 5 章 [非同期処理の基本 (Callback)](https://qiita.com/ZawaP/items/4f5914bfb5fbb67538b7)
- 第 6 章 [非同期処理の基本 (jQUery Deferred)](https://qiita.com/ZawaP/items/ffdde0a83f322002642c)
- 第 7 章 [Promise と async/await](https://qiita.com/ZawaP/items/1362951ebc86b76dcea1)
- 第 8 章 [終わりに](この記事)

### まとめ

ここまで 3 ヶ月ほど、JavaScript の非同期処理について学んできました。
当初は、`async / await` の書き方がなんとなくわかる。程度の理解しかありませんでしたが、ここまで勉強することで、JavaScript の非同期処理の基礎的な仕組みやそのベースとなっている概念。
また、内部的にどのように動いているのかといった部分の基礎を学ぶことができました。

そういった知識の上で、WebAPI, Promise, async/await を学んだことにより、各メソッドがなぜそのような挙動をするのか、といったことが概念的に理解できるようになりました。
詳細な仕様や挙動はまだまだ理解できていない部分も多いですが、ベースとなる概念を抑えることができたため、今後、新しい知識を学ぶ際にも、比較的スムーズに理解することができるのではないかと思っています。

また、この記事を書くにあたり、さまざまな記事や動画を参考にしながら、非同期処理を勉強させていただきました。
おかげさまで、これまであまりよくわかっていなかった非同期処理の仕組みについて、基本的なことが理解できたと感じています。
参考資料として記載しているものの他にも、さまざまな動画や記事を拝見させていただきました。改めてこの場を借りて、お礼を申し上げます。ありがとうございました。

### 各記事のまとめ

以下は各記事の内容のまとめとなります。

#### 第１章 JavaScript の歴史と特徴

- JavaScript は、1995 年に登場したプログラミング言語です。
- `agent`や`realm`といった概念、そして シングルスレッドでの実行を前提とします(ブラウザ)

#### 第２章 JavaScript 実行モデル (ECMAScript が定める実行モデル)

- JavaScript はそれぞれが Task として処理、実行されます
- キューとスタック、イベントループによる Task 処理が行われます
- Promise は、非同期処理として優先的に処理される必要があると定義されています

#### 第３章 ブラウザでの JavaScript の実行 (HTML Living Standard が定める実行モデル)

- 実行コンテキストと呼ばれるものがあり、その中で実行されます
- 実行コンテキストはメモリに保存され、必要に応じてスタックに積まれます
- マイクロタスクと呼ばれる、一部の処理だけを優先して行う機構が定義されています

#### 第４章 実装レベルで見る JavaScript の実行 (V8 & Chromium)

- ブラウザは、JavaScript の実行以外にも、画面描画や I/O などさまざまな処理を行い、イベントループで制御します
- JavaScript の実行では、通常のタスクキューとマイクロタスクキューがあり、マイクロタスクはスタックが空になるたびに優先的に実行されます
- 結果として、マイクロタスクは、メインスレッドの実行をブロックせず、処理が完了したタイミングで、マイクロタスクとして優先処理されるため、非同期処理として扱うことができます

#### 第５章 Callback 関数による非同期処理

- Callback 関数を使った非同期処理は主に、WebAPI を利用したものです
- マイクロタスクは利用せず、WebAPI が処理を完了した時点で、Callback 関数を Task として登録、実行されます
- 利用時に、Callback 地獄と呼ばれるネスト構造が発生しやすくなります

#### 第６章 jQuery Deferred

- jQuery は、JavaScript のライブラリとして、非同期処理を扱うための Deferred オブジェクトを提供しています
- これまで扱いづらかった、非同期処理のステータスと処理結果を、より直感的に扱うことができます
- しかし、非同期処理の結果はチェーンとして記述するため、複雑な条件分岐を扱う場合にはネスト構造になりやすくなります

#### 第７章 Promise と async/await

- Promise は JavaScript が ES2015 にて導入した、非同期処理を扱うオブジェクトです。jQuery Deferred と類似しており、チェーン構造による処理の記述が必要です
- ES2017 での async / await 導入により、さらに直感的に非同期処理を記述することができるようになりました

#### 第 0 章 はじめに

- 第 0 章ですが、書いたのは一番最後になります。これまで学んだことをもとに、JavaScript の非同期処理について理解できているかどうかをチェックするクイズを作りました。
- 全 10 問ですが、3 ヶ月前の自分であれば、おそらく 1 問も解けなかったと思います。もしよかったらぜひ皆さんも解いてみてください。
実業務で使えるGeminiの利用方法


### 私は 2025/05 現在、利用するAIの 98%は **GeminiPro**です。

他は、リアルタイムかつ、情報源が欲しい時に、
GenSpark：https://www.genspark.ai/

資料の図を作成する際に、

napkin.AI：https://www.napkin.ai/

を利用しています。(この資料の図のイラストは napkin.AIを利用しています。)

![image1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3734047/bd36dce9-af48-4432-ab6b-148c9052d884.png)


# Geminiを推す理由

![image2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3734047/20a4120f-9c99-4ec1-9aa9-16136b9e3a98.png)

Geminiを使う一番の理由は情報が学習されない環境かつ、
10,000行を超える共通ライブラリのソースコードを渡しても細かく理解してくれていて、
ライブラリの追加、改修、それを利用したプログラムの製造、仕様書の作成
これらすべてを良い精度で行ってくれます。

特に製造面での利用では
**「コピペして利用するので完璧なソースを出力してください。**
　**複数のファイルを出力する際は、３ファイルずつ出力してください。」** と
お願いすることでコピペするだけでプログラムが動くように出力してくれます。

99％くらいはビルドエラーもなくやってくれるのでとても優秀です。
(環境が原因の参照関連でエラーなることだけでした。)

![image3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3734047/35880865-6968-4d79-8bd6-41acfdb7cb1d.png)

# ライブラリを作成するにあたって意識していたこと

### 1. AIに命令、指示をしすぎないようにすること。
こちらからの指示だけでは指示が不完全な場合があり、期待した結果が得られないかもしれません。
なので、指示したいことに必要な情報をリストにしてほしい、どのようなプロンプトがいいですか？
とAIに聞くことです。
実例）
「私と協力してプロジェクトで使用するプログラムを作成しましょう。
　まずはどのような情報を伝えればいいかをリストにしてください。」
  
  
### 2. Canvas機能を利用すること
会話だけでやり取りするのは手間で時間がかかります。
Canvasという機能を利用すると
(Proの新規チャット画面にあるボタンをクリックしてプロンプト実行。途中からだとできないことがあるので注意！)

右側に自分とAIが書き込みあえるテキストエリアが現れます。
AIが出してきた必要な情報リストに書き込んだり、AIが作成した成果物を直接修正することができます。
    
![canvas1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3734047/d0f4a06c-b7e4-47ae-95f4-65ada11045e4.png)

    
### 3. プログラム設計とステップ案を作成すること
大きいものを作る場合には1回では対応できないことが多いです。

AIに負荷が大きくなりすぎないように気を付けながら、
優秀な新人と一緒に仕事をするように、
全体像と理想を常に細かく伝えて、
丁寧にレビューすることでより良いものが出来上がります。

![canvas2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3734047/e46e3d7c-2fe1-4c0e-b440-e60f9df448a6.png)

    
### 4. 出力したファイルを製造場所に組み込む。
CursorなどのモダンなAIエディタであれば直接適用してもらえるかもしれませんが、
現在のGeminiではできません。
プログラムのしっかりとした理解が必要になる場面ですね。

### 5. 改修の方法
ライブラリが完成した後に改修や追記が必要になった、
別のチャットに移行したいなどがあると思います。
この際に作成したコードがたくさんのファイルに分かれている場合があります。

私は、手動で行うのではなく、
AIに作成してもらったファイルの文字列結合ツールを利用して
全てのソースをつなげたファイルを作成します。

それを利用して新しいチャットでも既存のライブラリを理解した状態での作業ができるようになります！
(これの詳細は今後記事にできたらと思います。)
rex0220 計算式プラグイン チェックボックス単一選択

[計算式プラグイン](https://qiita.com/rex0220/items/ae83c6d5ce50ff7a9a73)で、チェックボックスの単一選択を行ってみました。

# 概要

複数の選択肢を持つチェックボックスを単一の選択にする例です。
制御用チェックボックスを使って、チェックボックスから前の選択肢を削除します。

![2025-06-04_09h04_04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100572/1d8a62a4-160d-4dc3-baf6-1a340fe75c10.png)


# 操作例

![2025-06-04_09h06_17.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100572/1dcccebd-06bc-4758-8f08-f1b7535fbba5.gif)

# フォーム設定

チェックボックスと同じ選択肢と初期値を持つ制御用チェックボックスを配置します。

![2025-06-04_09h09_08.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100572/21697111-3c6e-4f63-b413-0c6d3d2c2445.png)


# 計算式プラグイン設定

制御用チェックボックスには、変更前の選択肢を保存しておきます。
チェックボックスが複数選択の状態になったら、制御用チェックボックスにある以前の選択肢を除外します。

通常は、制御用チェックボックスを非表示にしてください。

![2025-06-04_09h16_57.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100572/c4b1ef95-5e4e-4b64-93c8-e58f1433d01c.png)

```JavaScript:
OPTION: 循環参照を許可

// チェックボックス CHECK_BOX (editable)
IF(ARRAY_COUNT(チェックボックス)>1,
  ARRAY_DEL(チェックボックス,OLDチェックボックス),
  ARRAY(チェックボックス)
)

// OLDチェックボックス CHECK_BOX
ARRAY(チェックボックス)

// チェックボックス２ CHECK_BOX (editable)
IF(ARRAY_COUNT(チェックボックス２)>1,
  ARRAY_DEL(チェックボックス２,OLDチェックボックス２),
  ARRAY(チェックボックス２)
)

// OLDチェックボックス２ CHECK_BOX
ARRAY(チェックボックス２)
```
機械学習モデル評価検証フォーマット

# 1. 概要
本ドキュメントは、機械学習モデルの新規構築時およびスコア更新時における評価検証の観点と手法を統一的に記録・報告するためのフォーマットである。

# 2. 実施タイミング
- 新規モデル構築時  
- スコア更新時（再スコアリング）  
- 定期検証（例：月次、四半期ごと）

# 3. 検証観点

## ＜新規モデル構築時＞
- モデル精度の検証（ROC-AUC, F1スコアなど）  
- 過学習の有無（交差検証）  
- 特徴量重要度の確認  
- モデルの安定性（fold間ばらつき）

## ＜スコア更新時＞
- データドリフト（入力特徴量の分布変化）  
- スコア分布の変化（平均・分散・外れ値）  
- スコアの再現性・一貫性  

# 4. 評価指標と基準値
- **ROC-AUC**：0.75以上を合格基準とする  
- **F1スコア**：0.6以上が望ましい  
- **PSI**：0.1未満を許容範囲とする  

# 5. 検証方法
- データ分割方法：k-fold（例：5-fold）、Hold-out法  
- モデル評価は訓練データ・検証データを分離して実施  
- データドリフトは前回スコアリング結果との比較により確認  

# 6. 結果と考察（記載例）
- ROC-AUCは5-foldの平均で0.78を記録し、基準値を満たしている。  
- スコア分布の分散が大きくなっており、入力データの一部に変化が見られる。  
- データドリフトの可能性があるため、データ前処理を見直す。  

# 7. 今後の改善・アクション（記載例）
- 外れ値除去ロジックの見直し  
- 一部特徴量のスケーリング方法を変更予定  
- モデルのキャリブレーション検討（Platt Scalingなど）  

# 8. 補足資料・付録
- 使用したハイパーパラメータの一覧  
- 特徴量一覧  
- 評価スクリプトへのリンク  
- 検証に使用したデータの概要
【仮想化技術】Docker-machineを使用してAWS-EC2上にコンテナ環境を作成する

### docker-Machineとは
下記の記事を参照

https://qiita.com/etaroid/items/40106f13d47bfcbc2572


## 事前
IAM（Identity and Access Management）は、AWSリソースのアクセス制御を管理するサービスで、アクセスキーはAWSのAPIやCLI経由で認証するための情報です。

- aws_access_key_id：公開識別子（アクセスID）
- aws_secret_access_key：認証用の秘密鍵（非公開）

これらの認証情報は、AWS CLI や SDK を使って、AWSのリソース（EC2、S3、RDS など）にプログラム的にアクセスするために使用されます。下記のようにcredentialsに登録しておきます。

```bash
user@host .aws % cat credentials
[default]
aws_access_key_id = xxxxxxxx
aws_secret_access_key = xxxxxxx
```

## docker-machineを作成

```docker
docker-machine create \
　--driver amazonec2 \
　--amazonec2-access-key xxxxxxxx \
  --amazonec2-secret-key xxxxxxxx \
  --amazonec2-instance-type t2.micro \
  --amazonec2-region us-east-2\
  --amazonec2-root-size 16 \
  --amazonec2-security-group docker-machine \
  --amazonec2-vpc-id vpc-xxxxxx \
  --amazonec2-subnet-id subnet-xxxxxxx \
  --amazonec2-open-port 8000  \
 aws-sandbox2
 ```

下記のようにdocker-machineが作成される。
```bash
user@host .aws % docker-machine ls
NAME           ACTIVE   DRIVER      STATE     URL                       SWARM   DOCKER    ERRORS
aws-sandbox2   -        amazonec2   Running   tcp://xx.xx.xx.xx          v28.0.1
```

### コンテナを起動

この状態でnginxのコンテナを起動してみます。そしてこのコンテナのipアドレスも確認してみます。
```
docker run -d -p 8000:80 --name webserver nginx
docker-machine ip aws-sandbox2
x.xx.xx.xx
```

実際に、ブラウザからこのパブリックIPに8000ポートに接続すると、IPがルーティングされてEC2上で起動しているnginxのコンテナ80ポートにつながり画面が表示されました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/381629/e1ad8d2b-9999-45c7-98b9-b25a951944f2.png)
Next.js＋TypeScript＋Tailwind CSSの案件テンプレ構成を完全解説【2025年版】

## はじめに

2025年のフロントエンド案件では
**Next.js × TypeScript × Tailwind CSS**
が完全に案件対応の定番構成になっています。

* 単なるトレンドではなく「実労で採用されている」
* 保守性・開発効率・SEOパフォーマンスまで高水準
* クライアント提案でも刺さりやすい構成

この記事では、受課開発・企業案件・SaaS開発などの現場で実際によく使われている「**案件対応のNext.js構成**」を、セットアップから設計までまとめます。

---

## 想定読者

* フロントエンド案件で提案・受注したい人
* Next.js＋TypeScript構成に乗り換えたい人
* 案件で提案できる「鉄板構成」を作りたい人

---

## 全体構成のイメージ

```bash
Next.js 14 (App Router構成)
TypeScript
Tailwind CSS (PostCSS)
Zustand / React Query (状態管理・API連携)
ESLint / Prettier / Stylelint (静的解析)
GitHub Actions (CI/CD)
Vercel or Netlify (ホスティング)
Figma連携 (UI実装)
Core Web Vitals最適化 (SEO/パフォーマンス)
```

---

## 1. Next.jsのApp Router構成

Next.jsは現在 **App Router（`/app`ディレクトリ）構成**が主流です。

### 主なメリット

* File-based Routingの進化系
* Server Component対応
* API Routesも使用可
* SSG / SSR / ISRの自由な運用

### インストール例

```bash
npx create-next-app@latest my-app
# オプションでTypeScript、Tailwind、App Router等を全てYes。
```

---

## 2. TypeScriptの型安全化

### 案件で求められるポイント

* Generics活用
* Props型共通管理
* API応答型管理
* `zod`連携

#### 型定義例

```typescript
import { z } from "zod";

const UserSchema = z.object({
  id: z.number(),
  name: z.string(),
  email: z.string().nullable(),
});

type User = z.infer<typeof UserSchema>;
```

---

## 3. Tailwind CSSでスタイリング

### カスタム設定例

```javascript
module.exports = {
  theme: {
    extend: {
      colors: {
        primary: '#0070f3',
        secondary: '#ff4081',
      },
      fontFamily: {
        body: ['Inter', 'sans-serif'],
      },
    },
  },
};
```

---

## 4. Zustand、React Queryによる状態管理

### Zustand

```typescript
import create from "zustand";

type State = {
  count: number;
  increment: () => void;
};

export const useStore = create<State>((set) => ({
  count: 0,
  increment: () => set((state) => ({ count: state.count + 1 })),
}));
```

### React Query

```typescript
import { useQuery } from "@tanstack/react-query";

const { data, error, isLoading } = useQuery(['user'], fetchUser);
```

---

## 5. ESLint / Prettier / Stylelint

### インストール

```bash
npm install -D eslint prettier stylelint stylelint-config-standard-tailwindcss
```

---

## 6. GitHub Actions での CI/CD

#### サンプル YAML

```yaml
name: CI

on:
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install dependencies
        run: npm ci
      - name: Lint
        run: npm run lint
      - name: Build
        run: npm run build
```

---

## 7. Vercel / Netlify ホスティング

* **Vercel**: SSR/ISR 対応、Next.js官方ホスト、Previewが便利
* **Netlify**: SSG案件で定番。ドメイン設定も楽

---

## 8. Figma連携

* spacing、color、fontをTailwindに同期
* デザイナー連携力の証明に

---

## 9. Core Web Vitals最適化

* LCP: 画像最適化（lazyload含む）
* INP: JS変更抜き出し
* CLS: レイアウト固定

---

## まとめ

* Next.js (App Router)
* TypeScript 型安全
* Tailwind CSS スタイリング
* Zustand＋React Query
* CI/CD (自動化)
* Vercel/Netlify
* Figma連携＆Core Web Vitals対応

---

## おわりに

これらを採り入れると、案件では
**「安心して任せられるフロントエンドエンジニア」**
になれます。

Qiitaでは案件に刺さる情報を発信し続けますので、LGTM・フォローよろしくお願いします！

---

## 関連タグ

Next.js, TypeScript, TailwindCSS, Zustand, ReactQuery, API設計, CI/CD, GitHubActions, Vercel, Netlify, CoreWebVitals, SEO, Lighthouse, Figma, フロントエンド案件, 受託開発
Word　変更履歴を出力するマクロ

```
Sub ExportRevisionsToExcel()
    Dim wdDoc As Object
    Dim xlApp As Object
    Dim xlBook As Object
    Dim xlSheet As Object
    Dim rev As Object
    Dim i As Integer
    
    ' WordとExcelを開く
    Set wdDoc = ActiveDocument
    Set xlApp = CreateObject("Excel.Application")
    xlApp.Visible = True
    Set xlBook = xlApp.Workbooks.Add
    Set xlSheet = xlBook.Sheets(1)
    
    ' ヘッダーを設定
    xlSheet.cells(1, 1).Value = "インデックス"
    xlSheet.cells(1, 2).Value = "開始位置"
    xlSheet.cells(1, 3).Value = "変更タイプ"
    xlSheet.cells(1, 4).Value = "変更内容"
    
    ' 変更履歴をExcelに転送
    i = 2
    For Each rev In wdDoc.Revisions
        xlSheet.cells(i, 1).Value = rev.Index
        xlSheet.cells(i, 2).Value = rev.Range.Start
        xlSheet.cells(i, 3).Value = rev.Type
        xlSheet.cells(i, 4).Value = rev.Range.Text
        i = i + 1
    Next rev
    
    ' Excelを保存
    xlBook.SaveAs "C:\Users\Public\Documents\Revisions.xlsx"
    xlBook.Close
    xlApp.Quit
    
    ' オブジェクトの解放
    Set wdDoc = Nothing
    Set xlApp = Nothing
    Set xlBook = Nothing
    Set xlSheet = Nothing
End Sub
```
【備忘録】マルチデータトリガー(MultiDataTrigger)によるスタイル変更

## 初めに
WPFのViewを作り込むとき、ViewModelの複数フラグに応じて表示を切り替えたり、
Viewで複数個所が表示されたら一緒に表示したいときありませんか？
それが、マルチデータトリガー(MultiDataTrigger)を使うことでこれらが可能となります。
今回は、そのマルチデータトリガーを使ったスタイル変更についてのメモです。

## マルチデータトリガーとは何か
通常のトリガー(Trigger)やデータトリガー(DataTrigger)は単一の条件に基づいて動作しますが、マルチデータトリガーを使用すると、複数の条件がすべて満たされる場合にスタイルやプロパティを変更できます。

マルチデータトリガーを使うためには、次の要素を使います。
**１．\<MultiDataTrigger>タグ**
マルチデータトリガーを定義するタグです。このタグを使うことで、複数の条件を持つトリガーを設定できます。

**２．条件のリスト (\<Condition>)**
マルチデータトリガーの中に、評価する条件をリストとして記述します。各条件でバインディングプロパティをチェックし、特定の値を持つかどうかを確認します。

**３．Setter**
条件がすべて満たされたときに、適用するプロパティの変更を定義します。この部分で、どのプロパティが新しい値に設定されるかを指定します。


### 使用例
Viewである個所が全て非表示だったら一緒に非表示とする場合です。

```xml:MainWindow.xaml
<Window x:Class="WpfApp.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Data Binding Example" Height="300" Width="350">
    <Window.DataContext>
        <local:TextViewModel />
    </Window.DataContext>
    <Grid>
        <!-- 3つのテキストブロックにバインド -->
        <TextBlock Text="Text 1" Margin="10" Visibility="{Binding Text1Visibility}" />
        <TextBlock Text="Text 2" Margin="10,40,10,0" Visibility="{Binding Text2Visibility}" />
        <TextBlock Text="Text 3" Margin="10,80,10,0" Visibility="{Binding Text3Visibility}" />
        <!-- すべてが非表示の場合に表示されるテキストブロック -->
       
<TextBlock x:Name="FinalTextBlock" Text="All texts are inactive."
                   Margin="10,120,10,0">
            <TextBlock.Style>
                <Style TargetType="TextBlock">
                    <Setter Property="Visibility" Value="Visible"/>
                    <Style.Triggers>
                        <MultiDataTrigger>
                            <MultiDataTrigger.Conditions>
                                <Condition Binding="{Binding Visibility, ElementName=Text1}" Value="Collapsed" />
                                <Condition Binding="{Binding Visibility, ElementName=Text2}" Value="Collapsed" />
                                <Condition Binding="{Binding Visibility, ElementName=Text3}" Value="Collapsed" />
                            </MultiDataTrigger.Conditions>
                            <Setter Property="Visibility" Value="Collapsed" />
                        </MultiDataTrigger>
                    </Style.Triggers>
                </Style>
            </TextBlock.Style>
        </TextBlock>
    </Grid>
</Window>
```

※ViewModelは割愛

### コードのポイント
* Text1,2,3が表示がVisibilityのBindingで切り替わるようになっています。
* \<MultiDataTrigger.Conditions>で、複数のデータの状態をみて、
\<Setter Property="Visibility" Value="Collapsed" />にしています。
今回の場合は、すべてのテキストが非表示だったら、FinalTextBlockも非表示になります。

これにより、Viewの複数の表示状態を元に表示を切り替えることが出来ました。

## 最後に
今回の例では、ViewをトリガーにしましたがViewModelのみでトリガーにすることも可能です。
以上、マルチデータトリガーによるスタイル変更のメモでした。
【Shell】ログファイルを自動リネームして保管：エビデンス収集に便利なシェルスクリプト

# ログファイルを自動リネームして保管：エビデンス収集に便利なシェルスクリプト

テスト自動化や運用作業で .log ファイルが生成される中で、環境情報付きでログを保存しておきたいと思ったことはありませんか？

たとえば、こんなケースです：
- テストのエビデンスとしてログを残したい
- 実行したマシンごとにログファイルを分けたい
- IPアドレスやホスト名をファイル名に含めて識別しやすくしたい
- 他のテスターのログとファイル名がかぶらないようにしたい（上書き防止）

そんなときに便利なのが、**ログファイルをリネームしてコピーするシンプルなスクリプト**です。

---

## 🛠️ `test.log` を環境情報付きで保存

```bash
#!/bin/bash

# 元ファイルのパス
SRC="/usr/local/logs/test.log"

# IPアドレス取得（127.0.0.1以外の最初のIPを使用）
IP=$(hostname -I | awk '{print $1}')
IP_SAFE=${IP// /_}

# ホスト名取得
HOST=$(hostname)
HOST_SAFE=${HOST// /_}

# 複製＆リネームして保存
cp "$SRC" /usr/local/test1.log
cp "$SRC" /usr/local/test_${IP_SAFE}.log
cp "$SRC" /usr/local/test_${HOST_SAFE}.log
```


# ファイル名のサンプル
```bash
# 出力例:
# /usr/local/test1.log
# /usr/local/test_192.168.0.10.log   ← IPアドレス例
# /usr/local/test_myhost.log         ← ホスト名例
```
【備忘録】データトリガーによるスタイル変更

## 初めに
WPFのViewを作り込むとき、ViewModelのフラグに応じて表示を切り替えたり、
Viewである個所が表示されたら一緒に表示したいときありませんか？
それが、データトリガーを使うことで可能となります。
今回は、そのデータトリガーを使ったスタイル変更についてのメモです。

## データトリガーとは何か
DataTriggerは、特定のデータの状態に基づいて、UIコンポーネントの見た目や動作を変更できるものです。
簡単に言うと、ある条件が満たされたときに「何かをする」というルールを作ることができます。

## 実際のコード
以下、ViewModelのフラグに応じて表示を切り替える例です。
この例では、ボタンの背景色を緑色、赤色に切り替えています。

```xml:MainWindow.xaml
<Window x:Class="WpfApp.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="DataTrigger with ViewModel" Height="200" Width="300">
    <Window.DataContext>
        <local:MainViewModel /> <!-- ViewModelをデータコンテキストに設定 -->
    </Window.DataContext>
    <Window.Resources>
        <Style x:Key="ButtonStyle" TargetType="Button">
            <Setter Property="Background" Value="LightGray"/>
            <Style.Triggers>
                <DataTrigger Binding="{Binding IsEnabled}" Value="True">
                    <Setter Property="Background" Value="Green"/>
                </DataTrigger>
                <DataTrigger Binding="{Binding IsEnabled}" Value="False">
                    <Setter Property="Background" Value="Red"/>
                </DataTrigger>
            </Style.Triggers>
        </Style>
    </Window.Resources>
    <Grid>
        <Button Style="{StaticResource ButtonStyle}" Content="Toggle Color" Width="150" Height="40" 
                Command="{Binding ToggleEnabled}" Click="Button_Click"/>
    </Grid>
</Window>
```

```cs:MainViewModel.cs
using System.ComponentModel;
using System.Runtime.CompilerServices;
public class MainViewModel : INotifyPropertyChanged
{
    private bool isEnabled;
    public bool IsEnabled
    {
        get { return isEnabled; }
        set
        {
            isEnabled = value;
            OnPropertyChanged();
        }
    }
    public MainViewModel()
    {
        // 初期値を設定
        IsEnabled = true;
    }
    public void ToggleEnabled()
    {
        IsEnabled = !IsEnabled; // ボタンの状態を切り替える
    }

    // 以下は表示の切り替えをする為のもの
    public event PropertyChangedEventHandler PropertyChanged;
    protected void OnPropertyChanged([CallerMemberName] string propertyName = null)
    {
        PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
    }
}
```
### コードのポイント
**View**
* Window.ResourcesにButtonStyleを定義しています。
ここで、データトリガーの条件も記載しています。

**処理の流れ**
* DataTriggerでBindingしているIsEnabledがTrueだと緑色になりFalseだと赤色になります。
* ボタンをクリックすると、ToggleEnabledメソッドを呼び出し、IsEnabledの値が切り替わります。

これにより、ViewModelのデータを元に表示を切り替えることが出来ました。

## 最後に
今回の例では、ViewModelをトリガーにしましたがViewのみでトリガーにすることも可能です。
以上、データトリガーによるスタイル変更のメモでした。
【備忘録】　SASE（サシー）

## 初めに
コロナ禍を期にリモートワークが普及し、それに伴って様々なセキュリティ対策がされてきました。
今回のSASEは、そのセキュリティ対策のアプローチ方法の一つです。

会社内のネットワークだと一般的にはプロキシサーバーを用いて通信ログの監視やフィルタリング、データ漏洩防止などを行っています。
ですが、リモートワークだと社外ネットワークになる為、このプロキシサーバーを使った監視が出来なくなります。
そこで使用されるのがVPNです。VPNを使用することで、社内のプロキシサーバーを経由するようにして、監視することが出来ます。また、通信は暗号化されますが、プロキシサーバーはそのトラフィックを解析することが出来ます。

しかし、従来のVPNセキュリティモデルでは問題もあります。リモートワークが増える中で、多様なデバイスや場所からのアクセスが行われるため、専用の通信路を設けるVPNではスケーラビリティ（システム規模や利用負荷の増大に対応できる能力）や管理の複雑さが課題となります。そこで登場するのが**SASE（Secure Access Service Edge**です。

## SASEとは何か
SASEは、ネットワークとセキュリティの機能を統合した新しいアプローチであり、クラウド基盤で提供されるサービスの形態です。
これにより、企業は社内ネットワークの境界を越えて、より柔軟で安全な接続を提供することが可能になります。
SASEは、以下の主な要素から成り立っています。

**1. クラウドベースの仕組み**
SASEは、インターネットを通じて提供されるため、特定の場所にいる必要がありません。
つまり、オフィスにいなくても、自宅やカフェなど、どこからでも安全にアクセスできるということです。従来の方法では、物理的な機器を使ってネットワークを守っていましたが、SASEではそれが不要で、必要に応じて増やしたり、減らしたりすることが簡単にできます。

**2．統合されたセキュリティ機能**
　SASEは、「SD-WAN」という技術と、さまざまなセキュリティ機能（例えば、ネットワークを監視・保護するツール）を組み合わせて使用します。これにより、全てのインターネットトラフィックを一元的に管理でき、問題が発生したときにすぐに対処することができます。

**3．ユーザーおよびデバイス認証**
　SASEでは、「ゼロトラストセキュリティモデル」という考え方に基づいて、ユーザーやデバイスが本当に信頼できるかどうかの確認します。信頼できる接続だけを許可し、悪意のある攻撃から企業を守る仕組みです。

**4．可視化と分析の向上**
　SASEは、ネットワーク上での全ての活動を監視して可視化し、データを詳しく分析することができます。この機能により、何かおかしな動きがあった場合や、セキュリティの脅威があった場合に、すぐに見つけて対策を取ることが可能になります。

## まとめ
SASEは、企業が安全にデータを管理し、リモートワークを行うための新しいアプローチ方法です。従来の方法と比べて、どこからでも安全にアクセスできる柔軟性があり、ユーザーやデバイスの安全を高めるためのさまざまなセキュリティ機能を統合しています。これにより、企業は現代の多様な働き方に対応することができます。
【公ド読】複雑なアルゴリズムまたはロジックの説明

【公式ドキュメントを読もうシリーズ】複雑なアルゴリズムまたはロジックの説明

## シリーズ概要

[https://qiita.com/yasu_programming/items/cec66f9e8d5d571e9ce3](https://qiita.com/yasu_programming/items/cec66f9e8d5d571e9ce3)

## URL

[https://docs.github.com/ja/copilot/copilot-chat-cookbook/documenting-code/explaining-complex-algorithms-or-logic](https://docs.github.com/ja/copilot/copilot-chat-cookbook/documenting-code/explaining-complex-algorithms-or-logic)

## 説明

コードの説明をしてくれる。
複雑なアルゴリズムにコメントを追加して、コードの説明をしてくれる。

## 所感

引継ぎで前任者がいなくなった後に、コードを読まなければいけないケースで役に立ちそう。