OmniAICreator/Qiita-1.07M huggingface dataset:
HTTPヘッダーとボディ

# はじめに
以前、『HTTP通信の仕組みと流れ』において、HTTP通信の全体像について解説しました。
この通信の中核を担っている、HTTPリクエストとHTTPレスポンスを中心に解説しましたが、共通しているで使用されている「ヘッダー（Header）」と「ボディ（Body）」については簡単に触れるにとどまりました。
この記事では、HTTPリクエストのヘッダーとボディの仕組みについて、以前の記事より深掘りして解説していきます。


## HTTPリクエスト・レスポンスの構造
まず、HTTP通信にはクライアントからサーバーに処理の依頼をするHTTPリクエストと、サーバーからクライアントへ結果を返すHTTPレスポンスがあります。
流れは以下の図のとおりです。
![Image 2025-05-03 at 21.24.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3907600/3c95406c-74a3-490c-aaf3-19d231b9a411.jpeg)
※https://shukapin.com/infographicIT/http より

このリクエストとレスポンスには、共通してヘッダーとボディがあります。

## ヘッダー（Header）

![Image 2025-05-03 at 21.42.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3907600/f29e07b2-6335-4a32-8c28-e48ae81eb2c0.jpeg)
※https://softuni.org/dev-concepts/everything-you-need-to-know-about-http-protocol/ より

HTTPリクエストは、リクエストライン（メソッドやURLなど）・HTTPヘッダー（メタデータ）・HTTPボディ（データ本体）の主に3つによって構成されています。

この中の HTTPヘッダー は、「メタデータ（＝データに関するデータ）」を含む部分であり、リクエストやレスポンスに関する付加的な情報をクライアントとサーバー間でやりとりします。
各ヘッダーは「フィールド名: 値」の形式で記述され、代表的なものには次のようなものがあります。
・Host: 接続先ホスト名（バーチャルホスト対応のため必須）
・Content-Type: ボディのデータ形式（例：application/json）
・Authorization: 認証情報（例：Bearerトークン）
・User-Agent: クライアントソフトウェアの情報（例：ブラウザ名）
・Accept: クライアントが受け入れ可能なレスポンス形式

### リクエスト時の主なヘッダー
クライアント（ブラウザやアプリ）は、リクエストヘッダーを通じてサーバーに対し「どのようなリクエストなのか」を伝えます。たとえば以下のようなものがあります。
・Accept ヘッダー：クライアントが受け取りたいデータの形式（例：JSON, HTML）を指定します。
・Content-Type ヘッダー：クライアントが送信するデータの形式（例：JSON, フォームデータ）をサーバーに伝えます。
※ Content-Type や Content-Length は、POSTやPUTなど、リクエストボディを含む場合に特に重要です。

### レスポンス時の主なヘッダー
リクエストヘッダーの内容によって、サーバーは以下の情報などを判断し、レスポンスを生成します。
・どんな形式でレスポンスを返すべきか
・リクエストされたデータをどう解釈すべきか
・クライアントにアクセス権があるかどうか
・どんな種類のデバイスか（表示を変えるかどうか）

サーバーからのレスポンスにもヘッダーが含まれており、たとえば以下のようなヘッダーを持ちます。
・Content-Type: レスポンスボディの形式を示し、クライアントはこの情報をもとにデータを解析します。
・Content-Length: レスポンスボディのサイズを示し、進捗表示や通信管理に利用されます。

これらの情報により、クライアントはレスポンスを正しく処理できます。


## ボディ（Body）
HTTPボディ は、やり取りされる実際のデータの本体が含まれる領域です。

**リクエスト時のボディ**
クライアントからサーバーにPOSTメソッドなどによってデータを送る際、ボディには次のような内容が含まれます。
・フォームから送信されたデータ（例：名前、メールアドレスなど）
・JSON形式のデータ（例：{"title": "記事タイトル", "body": "本文"}）
・ファイル（画像、PDFなど）
ボディに含まれるデータの形式は、Content-Type ヘッダーで指定します。

```sh: 例
Content-Type: application/json

{
  "username": "taro",
  "password": "1234"
}
```
サーバーは Content-Type を参照して、送られてきたデータを正しく解析します。


**レスポンス時のボディ**
サーバーからのレスポンスボディには、クライアントに返すべき実際のコンテンツが含まれます。
・HTML（Webページの内容）
・JSON（APIのレスポンス）
・ファイルデータ（画像やPDFなど）など
サーバーは Content-Type を使って、クライアントにボディの形式を伝えます。

```sh: 例
Content-Type: application/json

{
  "message": "ログイン成功",
  "token": "abcdef123456"
}
```
クライアントはこのボディを解析し、画面表示や次の処理に活用します。

HTTPボディは、リクエストやレスポンスの中身を実際にやり取りする部分ということです。


# まとめ
HTTPリクエストのヘッダーとボディは、ただの文字列ではなく、クライアントとサーバーの通信のルールを担う重要な情報のかたまりです。
リクエスト全体の構造を理解し、どのヘッダーに何の情報を含め、どう扱うかを正しく判断する力が不可欠になります。そのための理解の助けに少しでもなれば幸いです。

最後までお読みいただき、ありがとうございました。


## 参考・画像引用元URL
https://developer.mozilla.org/ja/docs/Web/HTTP/Guides/Messages
https://qiita.com/growsic/items/7b0b461303fd1e8995f2
https://medium.com/@tpsmith1992/headspace-a-closer-look-at-the-http-header-4ce94fbeb8cd
https://xtech.nikkei.com/it/article/lecture/20061115/253825/

https://shukapin.com/infographicIT/http
https://atmarkit.itmedia.co.jp/ait/articles/1508/31/news016.html
https://www.infraexpert.com/study/tcpip16.html
【React初心者メモ】JSXの条件文

JavaやPythonなどの他言語では、if文などを利用して、条件分岐を記述してきました。
Reactで利用されるJSXでは「式しか書けない」というルールがあるため、&&, ||, ?: などの論理演算を使って条件分岐を記述します。

### &&
{条件 && \<JSX\>}：条件が true のときに表示  
```
{isLoggedIn && <p>ようこそ！</p>}	
```
isLoggedIn=true → 「ようこそ！」が表示される  
isLoggedIn=false → 何も表示されない  

### ||
{条件 || \<JSX\>}：条件がfalsyのときに表示  
```
{isLoggedIn || <p>ようこそ！</p>}	
```
isLoggedIn=true → 何も表示されない
isLoggedIn=false → 「ようこそ！」が表示される  

### ? :
{条件 ? \<A\> : \<B\>}：条件によって2パターン切り替え  
```
{isAdmin ? <p>管理者</p> : <p>一般ユーザー</p>}
```
isAdmin=true → 「管理者」を表示
isAdmin=false → 「一般ユーザー」を表示
Linucレベル１勉強メモ #9

＃ 第一章　Linuxのインストールと仮想マシン・コンテナの利用

練習問題1.9
システム上で実行されている全てのプロセスを表示したい場合に、psコマンドに指定するオプションを２つ記述してください。ただし、「-」を指定しないオプションとします。

（解答）　ax

（解説）システム上のすべてのプロセスをpsコマンドで表示するには、a及びxオプションを指定するか、-eオプションを指定します。aオプションだけでは、制御端末のないプロセス、つまりシェル上でコマンドとして実行してのではなく、他のプロセスから起動したプロセスや、サーバープログラムなどのデーモンプロセスが表示されません。psコマンドのオプションには、「-」を指定するものとしないものが混在していますので注意する。



psコマンドは現在実行されているプロセスを表示します。
主なオプションについて
1. a<br>他のユーザーのプロセスも表示する。
1. f<br>親子関係をツリー状に表示する。
1. u<br>ユーザー名も表示する
1. x<br>制御端末のないデーモンなどのプロセスも表示する。
1. -e (=ax)<br>すべてのプロセスも表示する。
1. -l<br>詳細な情報表示する。
1. -p PID<br>特定のPID（プロセスID）のプロセス情報のみ表示する。
1. -Cプロセス名<br>指定した名前のプロセスのみ表示する。
1. -w<br>長い行は折り返して表示する。
SSD上に仮想メモリを作成する【Ubuntu】

# はじめに
メモリが足りないときの対応策として仮想メモリを設置することがある。
UbuntuでSSD上に仮想メモリを作成するときの方法をまとめておく。

# 注意
本記事によっておきた一切の事象に対して筆者は責任を負いません。

# SSDを設置する
今回はSSDにパーティションを設置して、そのパーティションすべてを仮想メモリに使用する (仮想メモリのサイズについては[仮想メモリのサイズについて](#仮想メモリのサイズについて)を参考)。

# パーティションの作成
パーティションを作成し、そこに仮想メモリを作成する。
パーティションのサイズはほしい仮想メモリのサイズにする ()。
パーティションの作成方法は以下：
https://qiita.com/biomemo/items/56a9d0164f0d08aa1016

# 仮想メモリ用にフォーマット
```
$ sudo mkswap /dev/your/partition
```

# 仮想メモリを起動する
```
$ sudo swapon /dev/your/partition
```
ちゃんと起動できているか確認するとよい。以下の例では600Gの仮想メモリを設置した (2行目)。
```
$ sudo swapon --show
NAME                TYPE      SIZE USED PRIO
/swapfile           file        2G   2G   -2
/dev/your/partition partition 600G   0B   -3
```
# swapの永続化
まずUUIDを調べる。
```
$ sudo blkid /dev/your/partition
12345678-90ab-cdef-1234-567890abcdef
```

そして以下を`/etc/fstab`に追記する (`UUID=`で指定する文字列は`blkid`で調べた値にする)。
```
UUID=12345678-90ab-cdef-1234-567890abcdef  none  swap  sw  0  0
```

# 仮想メモリのサイズについて
一般には物理メモリの1.5-2倍程度までが推奨されるようです ([リンク1](https://www.mouse-jp.co.jp/mouselabo/entry/2023/12/15/100021#%E4%BB%AE%E6%83%B3%E3%83%A1%E3%83%A2%E3%83%AA%E3%81%AE%E6%8E%A8%E5%A5%A8%E5%80%A4), [リンク2](https://faq.nec-lavie.jp/qasearch/1007/app/servlet/qadoc?QID=020452))。

# バージョン情報
Ubuntu 20.04
【ローカルLLM × MCP】OllamaとMCPでLINE風チャットAIを作ってみた【Node.js／TypeScript】


# 【ローカルLLM × MCP】OllamaとMCPでLINE風チャットAIを作ってみた【Node.js／TypeScript】

最近話題のローカルLLM「Ollama」と、外部機能連携が簡単になる「Model Context Protocol（MCP）」を組み合わせて、**LINE風のチャットUIを備えたAIチャットアプリ**を作ってみました。

この記事では、プロジェクトの概要、技術構成、インストール手順、そしてアーキテクチャのポイントをご紹介します。

---

## 🎬 デモ動画

まずは完成したチャットアプリの動作をご覧ください👇

📽️ <iframe width="560" height="315" src="https://www.youtube.com/embed/egD5knWnxPQ?si=DaZD9X4I_YPPvbIq" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

---

## 📝 プロジェクト概要

このWebアプリは、**ローカルで動作するOllama**と\*\*MCP（Model Context Protocol）\*\*を活用し、まるでLINEのようなチャット体験を提供するAIチャットエージェントです。

### 主な特徴

* ✅ LINE風のモダンなUI
* ✅ ローカルLLM（Ollama）による高速応答
* ✅ MCP経由で天気や時刻などの外部情報も取得可能
* ✅ ストリーミング応答でスムーズなチャット体験
* ✅ すべてブラウザ上で動作（クライアントと簡易サーバー）

---

## 📷 スクリーンショット

![screen-shot-2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/125746/928575c5-7767-467b-ae74-87b1e5e47d47.png)


---

## 🛠 技術スタック

| カテゴリ    | 使用技術                                                                     |
| ------- | ------------------------------------------------------------------------ |
| フロントエンド | HTML/CSS/JS, Express.js                                                  |
| バックエンド  | Node.js, Express.js, TypeScript                                          |
| AI/LLM  | [Ollama](https://ollama.com/)（ローカルLLM）                                   |
| 外部連携    | [Model Context Protocol (MCP)](https://github.com/modelcontext/protocol) |
| その他     | ESLint, Prettier                                                         |

---

## 🔧 セットアップ方法

### ✅ 事前準備

* [Node.js 18+](https://nodejs.org/)
* [Ollamaのインストール](https://ollama.com/)
* MCPに対応したサーバー（または自作）

### ✅ インストール手順

```bash
# Ollamaをバックグラウンドで起動しておく

git clone https://github.com/softjapan/ollama-mcp-agent.git
cd ollama-mcp-agent
npm install
npm run build
npm run start
```

ブラウザで `http://localhost` にアクセスすれば起動します。

---

## 🔍 アーキテクチャの概要

```plaintext
[ブラウザUI]
   ↓ HTTP
[Expressサーバー（Node.js）]
   ├─> Ollama（ローカルLLM）へのリクエスト
   └─> MCP対応モジュールで外部API（天気、時刻など）を呼び出し
```

Ollamaはローカルで動作するため、インターネットに依存せずに高速なレスポンスが得られます。さらにMCPを介することで、LLMが「天気を教えて」といった曖昧な質問にも外部情報と連携して対応可能になります。

---

## 🧪 応用アイデア

* ユーザーの質問に応じてニュースAPIや為替APIと連携
* スマホ対応にしてPWAとしてインストール可能に
* Ollamaのモデルを切り替えて精度や速度を比較

---

## 📄 ライセンス

このプロジェクトはMITライセンスで公開されています。
詳細は [LICENSE](https://github.com/softjapan/ollama-mcp-agent/blob/main/LICENSE) をご覧ください。

---

## 🚀 おわりに

ローカルLLMとMCPの組み合わせは、**AIを安全に・柔軟に使いたい開発者**にとって非常に魅力的な選択肢です。気になった方はぜひGitHubを覗いてみてください👇

🔗 GitHub: [https://github.com/softjapan/ollama-mcp-agent](https://github.com/softjapan/ollama-mcp-agent)

---
Ajaxでページが踊る!?

## はじめに
- 最近のWeb開発で大活躍中のAjaxについて、自分が学んだことをサクッと書いておこうと思う

## Ajaxとは
- ページ全体を再読み込みせず部分更新を行う技術 

## 主な特徴
- **非同期通信**：ページ全体をリロードせずに必要データのみ取得
- **JavaScript**：クライアント側でJSONなどを扱い通信制御
- **DOM操作**：受信データを基にページ内要素を動的に書き換え

## 利用例
- **検索エンジン**  
  ユーザー入力のたびに予測キーワードを非同期取得・表示する仕組み
![画面収録 2025-05-04 11.02.23.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4021892/29eeb88c-7295-45a2-8680-627b94b6b30f.gif)

- **地図アプリ**  
  スクロールに応じて地図タイルを非同期取得・表示更新する仕組み  
![aaaaa.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4021892/a939af6e-31d3-4b46-b3fb-de97ad853c9e.gif)

- **ECサイト**  
  ページ遷移なしに商品情報を非同期読み込みしスムーズな閲覧を実現する仕組み
![画面収録 2025-05-04 11.10.36.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4021892/49d8f31d-345d-4197-bb85-71ea7b9cd47e.gif)

- **SNSサービス**  
  スクロール操作でタイムラインをシームレスに読み込む仕組み 
![画面収録 2025-05-04 11.17.41.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4021892/0f83f987-24b0-48fe-9a41-afd58193f772.gif)


## 動作プロセス
1. **リクエスト作成**：XMLHttpRequestオブジェクトを生成し送信データを設定
2. **サーバー通信**：XMLHttpRequestを介してサーバーへリクエストを送信し応答を待機
3. **レスポンス処理**：受信データを解析しDOMを更新

## 補足：XMLHttpRequestとは
- ブラウザで非同期通信を行うためのAPIのこと

## まとめ
- Ajaxの仕組みと主要シーンを押さえて開発効率アップを目指す
- Gifとか添付すると映えて良い感じ（自己満）
#0121（2025/05/04）Bluetoothとは

# Bluetoothとは

## Bluetoothとは何か？

Bluetooth（ブルートゥース）とは、2.4GHz帯の無線を使って、近距離でデバイス同士をケーブルなしに通信させるための技術規格である。主にスマートフォン、イヤホン、スピーカー、マウス、キーボード、車載機器など、日常生活でよく使う電子機器同士の無線接続に利用されている。

Bluetoothの特徴には以下のようなものがある：

* 通信距離は数メートルから最大100メートル（機器のクラスによる）
* ペアリングによる簡単な接続
* 低消費電力（特にBluetooth Low Energy：BLE）
* 通信速度は数Mbps程度（用途による）

## Bluetoothの名前の由来

Bluetoothという名前は、10世紀にデンマークとノルウェーを統一したデンマーク王「ハーラルド・ブロタン（Harald Bluetooth）」に由来する。彼のあだ名「Bluetooth（青歯）」は、彼の歯の1本が変色していたという逸話から来ている。

異なる部族を統一したハーラルド王になぞらえて、Bluetooth技術も異なるメーカー・デバイス間の無線通信を統一するという意味合いを込めてこの名称が採用された。

Bluetoothのロゴは、ハーラルド王の名前を北欧ルーン文字で表した「ᚼ（H）」と「ᛒ（B）」を組み合わせたものである。

## Bluetoothの登場背景

1990年代、電子機器間の接続には大量のケーブルが必要で、ユーザーの利便性を損なっていた。こうした背景の中、スウェーデンの通信機器メーカーEricsson（エリクソン）が1994年に無線接続技術の研究を開始。

1998年には、エリクソン、インテル、ノキア、IBM、東芝の5社がBluetooth SIG（Special Interest Group）を設立し、Bluetoothを業界共通のオープンな無線通信規格として標準化・普及させる体制が整った。

## Bluetoothの歴史（1.0〜5.4）

| バージョン     | 発表年       | 主な特徴                                       |
| --------- | --------- | ------------------------------------------ |
| 1.0〜1.2   | 1999〜2003 | 初期版。不安定で普及は限定的。                            |
| 2.0 + EDR | 2004      | 最大3Mbpsへ高速化、省電力化も進む。                       |
| 2.1 + EDR | 2007      | Secure Simple Pairingにより簡単で安全なペアリング。       |
| 3.0 + HS  | 2009      | Wi-Fi併用で最大24Mbpsの高速通信（主にファイル転送向け）。         |
| 4.0       | 2010      | Bluetooth Low Energy（BLE）導入で超省電力通信が可能に。    |
| 4.1       | 2013      | LTE干渉への耐性強化、IoT対応改善。                       |
| 4.2       | 2014      | セキュリティ強化、IPv6/6LoWPAN対応。                   |
| 5.0       | 2016      | BLE強化、距離4倍、速度2倍、容量8倍。                      |
| 5.1       | 2019      | AoA/AoDにより方向検知が可能に。                        |
| 5.2       | 2020      | LE Audio登場（LC3コーデック）、マルチストリーム対応。           |
| 5.3       | 2021      | 電力効率・セキュリティ・接続管理改善。                        |
| 5.4       | 2023      | Encrypted Advertising Data、IoT用途の大規模展開に対応。 |

## Bluetoothの周波数帯と身近な周波数帯

Bluetoothは\*\*2.4GHz帯（2.400〜2.4835GHz）\*\*を使用する無線技術で、ISMバンド（産業・科学・医療用帯域）に分類され、世界中で免許なしに利用可能である。

この帯域は、Wi-Fiや電子レンジ、無線マウスなどとも共有されているため、干渉が起きることもある。

### 他の代表的な周波数帯と用途

| 周波数帯     | 主な用途                              |
| -------- | --------------------------------- |
| 13.56MHz | ICカード、NFC（近距離通信）                  |
| 400MHz帯  | 特定小電力無線（トランシーバー等）                 |
| 920MHz帯  | RFID、スマートメーター、LPWA（IoT向け）         |
| 2.4GHz帯  | Bluetooth、Wi-Fi（IEEE 802.11b/g/n） |
| 5GHz帯    | Wi-Fi（IEEE 802.11a/ac/ax）         |
| 28GHz帯   | 5Gミリ波（超高速・超低遅延）                   |

## Bluetoothの今後の発展

今後のBluetoothは、以下のような分野で大きく進化すると予測される：

### 1. IoT・スマートデバイス対応の強化

* より省電力
* 同時に多数の機器を管理
* スマートホームや工場設備、医療機器への普及拡大

### 2. LE Audioの普及

* 新しいコーデックLC3による高音質・低遅延
* マルチストリーム対応で音のズレが少ない
* Auracastによるブロードキャストオーディオ（駅や劇場で同時配信）

### 3. 高精度な位置情報技術の活用

* AoA/AoDによる方向検知
* 屋内ナビゲーションや人の動線追跡に応用

### 4. セキュリティと接続性の向上

* 暗号化の強化
* ペアリングの自動化と信頼性アップ

Bluetoothは今後、イヤホンやスマホの枠を超え、**日常のインフラ技術として静かに広がっていく**と考えられる。特にLE Audio、IoT、屋内位置情報の3つは今後の柱となるだろう。
【Web技術習得ログ #02】PHPアプリ開発基礎とLinux基礎

こんにちは、[spoooonn＠X](https://twitter.com/spoooonn)です。

現在、**Webセキュリティスキルの習得を目的として、開発未経験のCSIRT担当がWeb技術を基礎から学び直す取り組み**を進めています。  
今回は、PHPとLinuxの基礎を学習した進捗の記録です。

---

## 🔁 学習ロードマップの再掲（2024年後半〜2025年計画）

半年間のスパンで、段階的にWeb技術を習得していく計画です。  
全体方針と学習計画については、以下の記事で宣言しています。

📚本取組の概要はこちら👇  
[脱・机上セキュリティ！開発未経験CSIRTが挑むWeb技術習得記](https://qiita.com/spooooNN/items/2eee90b3a4924c4cd73d)

現在は **フェーズ①「Web構築基礎」** に取り組んでいます。

| フェーズ | 期間      | 学習内容・活動                                                                 | 使用予定ツール・教材                   | 進捗状況           |
|----------|-----------|--------------------------------------------------------------------------------|----------------------------------------|--------------------|
| **① Web構築基礎** | 4〜6月    | HTML/CSS、PHP or Python、Linux、Git、Web技術の基礎習得                       | 書籍 / Udemy / 公式ドキュメント       | ✅ **進行中**      |
| ② ポートフォリオ作成 | 7〜8月    | Flask or Laravel を使ったWebアプリ、メール送信、自宅サーバ公開              | Flask/Laravel、Postfix、Dovecotなど    | 未着手             |
| ③ セキュリティ診断   | 9〜10月   | OWASP Top 10をベースに脆弱性診断を実施し、自ら修正                           | OWASP ZAP、Burp Suite、DevTools       | 未着手             |
| ④ 応用・拡張         | 11月以降 | Docker、CI/CD、AWS再構築など（運用や実務への応用）                          | Docker、GitHub Actions、AWSなど       | 未着手             |

---

## 📘 今回の学習内容（フェーズ①「Web構築基礎」 - 第2回）

### ■ Linux
- Udemyの「未経験者がLinuxを怖がらなくなる講座」を活用し、基礎的なLinux操作を体系的に復習しました。  
  [未経験者がLinuxを怖がらなくなる講座（Udemy）](https://optagehrjp.udemy.com/course/unscared_linux/learn/lecture/16858760?start=7#content)

※私が本取組でとても参考にしている山浦さんの講座です！

### ■ PHP
- 書籍『初心者からちゃんとしたプロになる PHP基礎入門 改訂2版』を用いて、PHP + Apache + MySQL環境での書籍管理アプリを実装しました。  
  [書籍リンク](https://www.amazon.co.jp/dp/4295206776)

※セキュリティ脅威（XSS、CSRF）についてもしっかり解説していて、対策の実装も明確。初心者にもわかりやすい良書でした。

---

## 🧠 新しく学んだこと

### ◼ PHPの基礎とセキュリティ

- `require`と`include`の違い：エラーの発生有無による使い分け
- `htmlspecialchars()` によるXSS対策
- `json_decode()` でのJSON取り扱い
- `prepare()` + `bindParam()` を用いたSQLインジェクション対策（プリペアドステートメント）
- 正規表現を使った入力バリデーション
- ヒアドキュメント（`<<<EOD`）によるHTML埋め込みの可読性向上
- `__DIR__` 定数の活用によるパス解決の安定化
- セッションとhiddenフィールドによるCSRF対策の実装

### ◼ Linuxの再確認と新発見

- 基本コマンドの操作感を再確認（`cd`, `less`, `find`, `cp`など）
- ディレクトリ構成の理解（例：`/sbin`, `/dev`）
- `/dev/null` の使い方とリダイレクトの仕組み（`0`, `1`, `2` の標準入出力）
- シンボリックリンクとハードリンクの違い

---

## 💡 気づき・振り返り

- **PHPの学習を通じて、Webアプリ開発ではセキュリティ対策が実装段階から不可欠であることを再認識**しました。以前読んだ徳丸本（『安全なWebアプリケーションの作り方』）ではさらに詳しい内容（HSTSやCSPなど）もあったため、改めて復習する予定です。
- **Linuxに関してはコマンドの多くは既知だったものの、UNIXの設計思想や標準出力の仕組みについて体系的に理解できた点は大きな収穫**でした。
- 講座内で紹介されていた『UNIXという考え方』という書籍が気になったので、今後読んでみたいと思います。

---

## 📌 次回に向けて

次回は、**「Web構築基礎」フェーズの続きとして、データベース（MySQL）とGit/GitHubの使い方**に取り組む予定です。  
PHPとの連携や、ソース管理の基本操作についても重点的に学んでいきます。

---

📘 前回の記事はこちら👇  
[【Web技術習得ログ #01】HTML/CSSの基礎をひととおり学びました](https://qiita.com/spooooNN/items/7873c354334d237c60b5)
#0120（2025/05/04）HTTP/1.1とHTTP/2の違い

## はじめに

本記事はHTTP/1.1とHTTP/2の違いをプロトコルレベルから実装・運用まで深掘りし、**設計時・チューニング時に意識すべきポイント**を具体的に解説します。

---

## 1. コネクション管理とHOLブロッキング

### HTTP/1.1

* デフォルトで**1接続＝1リクエスト**。
* パイプライニングは多くの実装で無効化、並列性は**複数TCPコネクション**で実現。
* TLSハンドシェイク×Nで**接続オーバーヘッド**が発生。

### HTTP/2

* **単一TCP接続内に複数ストリーム**を多重化。
* TCPレベルではHOLブロッキングがストリーム間で共有され、**パケット損失時の影響範囲**に注意。
* **対策**: 長距離やモバイル回線ではTCPプロキシ／QUIC（HTTP/3）も検討。

---

## 2. フレーミングとバイナリ化

* HTTP/1.1はテキストベースで、ヘッダ境界は空行・改行。
* HTTP/2は**9バイトヘッダ＋可変長ペイロードのフレーム**を使用。
* **設計上の勘所**: フレーム分割・マージやバッファ管理を最適化し、**メモリ使用量**を制御。

---

## 3. HPACK（ヘッダ圧縮）のチューニングとセキュリティ

* **動的・静的テーブル参照**で差分圧縮。
* `SETTINGS_HEADER_TABLE_SIZE`で**圧縮率 vs メモリ消費量**のトレードオフ。
* BREACH/CRIME攻撃対策として、過度なテーブルサイズ増大を抑制。
* APIごとのヘッダパターンを分析し、`SETTINGS_MAX_HEADER_LIST_SIZE`を最適化。

> HPACKは、HTTP/2におけるヘッダー圧縮方式です。HTTP/2で通信する際、ヘッダー情報を効率的に圧縮し、通信量を削減する仕組みです。これにより、Webサイトの読み込み速度を向上させることができます

---

## 4. プライオリティとフロー制御

* **PRIORITYフレーム**でストリームごとの\*\*重み付け（weight）\*\*や依存関係を定義。
* クライアント・サーバー間で**接続単位／ストリーム単位**のウィンドウ制御を行い、`SETTINGS_INITIAL_WINDOW_SIZE`を調整。
* **注意点**: ウィンドウサイズが大きすぎるとメモリ圧迫、小さすぎると`WINDOW_UPDATE`頻発によるオーバーヘッド。

---

## 5. サーバープッシュの活用と注意点

* HTML → CSS/JSを**先行送信**し、RTTを節約可能。
* 不要プッシュによる帯域浪費やキャッシュミスを防ぐため、**キャッシュ状況の確認**や用途に応じた制御を実装。
* `PUSH_PROMISE`を正しく扱い、クライアントのキャッシュ状態を考慮した設計を。

---

## 6. TLS運用とALPNネゴシエーション

* HTTP/2はほぼ**HTTPS前提**（ALPNで`h2`を選択）。
* TLS1.2以上を必須化し、古いバージョンの無効化を徹底。
* 証明書管理やセッション再開（PSK）を組み合わせることで、**接続確立コスト**を最小化。

---

## 7. デバッグ・計測ツール

* **HTTP/1.1**: `curl`, `tcpdump`で平文ヘッダ参照。
* **HTTP/2**: `nghttp`, `h2load`, ブラウザ開発ツールの**フレーム単位タイムライン**。
* ログレベル`DEBUG`以上でフレーム送受信ログを取得し、**ボトルネック特定**。

---

## 8. HTTP/3移行への布石

* QUICベースでTCP HOLを解消。
* HTTP/2のストリーム管理／HPACK／プライオリティ知識はHTTP/3でも活用可能。
* **ステップ**: まずHTTP/2で最適化経験を積み、HTTP/3へのスムーズな移行を目指す。

---

## まとめ：意識すべきポイント

1. **HOLの恩恵と限界**：多重化×TCPレイヤの特性把握
2. **HPACK設定**：圧縮率・メモリ・セキュリティのバランス
3. **優先度／フロー制御**：適切なウィンドウサイズと重み付け
4. **Server Push**：帯域効率化とキャッシュ戦略
5. **TLS/ALPN**：HTTPS運用と接続コスト低減
6. **デバッグ**：フレーム単位の可視化で性能改善

これらを踏まえ、HTTP/2導入時やチューニング時に具体的な数値・ツールを活用し、パフォーマンスと運用性を両立させましょう。
pnpm install の nuxt prepareで依存パッケージから読み込まれるintlify/shared 由来のエラーを何とかできた話

npmとかpnpmとかでよく聞く話なのかもしれないですが、package-lock.json とか pnpm-lock.jsonを再作成しただけで、(package.jsonを触っていないのに）エラーがでることありますよね。


しかも、package.jsonが原因ならば一つ前のバージョンに戻して、エラーが出るようになった原因の修正を取り除けば良さそうなのですが、自動生成されるpackage-lock.jsonを戻すとエラーが出なくなるという事であれば、泣きたくなる状況です。

そもそも、パッケージをインストールするときに npm addとか npm installを実施するとか scriptを追記するとか程度しか通常実施しないですよね。
改めて、package.jsonのバージョン指定の仕方とか、devDependenciesとDependenciesの違いとかあまり理解していなかったです。

しかも、引き継いだvueプロジェクトが pnpmを使っていたので、更にハードルが上がってしまい、さらにはGoogleでエラーメッセージを検索しても役立つ情報が見つからなかったのです。。。



## 発生事象

依存パッケージの脆弱性問題があったので、依存パッケージのバージョンを上げて、`pnpm install`実施で以下のエラー。
package.json を戻して、pnpm-lock.json を削除して `pnpm install` を実施しても同じエラーが出る。。

### エラーメッセージ

> nuxt prepare
>
> [9:41:16 AM]  ERROR  [unhandledRejection] No "exports" main defined in /(省略..)/web/node_modules/.pnpm/@intlify+bundle-utils@4.0.0_vue-i18n@9.3.0-beta.16_vue@3.2.47_/node_modules/@intlify/shared/package.json

削除前と自動生成された、pnpm-lock.jsonの差分を見ると、エラーメッセージに出てきた @intlify/sharedでα版を参照している用になっていて、多分これが原因と考えたわけです


以前
```
  '@intlify/bundle-utils@4.0.0(vue-i18n@9.3.0-beta.16)':
    dependencies:
      '@intlify/message-compiler': 10.0.0-beta.1
      '@intlify/shared': 10.0.0-beta.1
      jsonc-eslint-parser: 1.4.1
      source-map: 0.6.1
      vue-i18n: 9.3.0-beta.16(vue@3.3.4)
      yaml-eslint-parser: 0.3.2
```

```
  '@intlify/bundle-utils@4.0.0(vue-i18n@9.3.0-beta.16(vue@3.3.4))':
    dependencies:
      '@intlify/message-compiler': 12.0.0-alpha.2
      '@intlify/shared': 12.0.0-alpha.2
      jsonc-eslint-parser: 1.4.1
      source-map: 0.6.1
      yaml-eslint-parser: 0.3.2
    optionalDependencies:
      vue-i18n: 9.3.0-beta.16(vue@3.3.4)
```

## 解決策

`overrides`設定を利用します。

https://docs.npmjs.com/cli/v9/configuring-npm/package-json#overrides

overrides設定により、依存パッケージから参照されるパッケージのバージョンを固定する事ができます。

ただし、pnpmで利用するには pnpmセクションに入れ込む必要があります。

一部抜粋するとこんな感じ

```
  "dependencies": {
    "@floating-ui/vue": "^0.2.1",
    "@pinia/nuxt": "^0.4.11",
    "@types/blueimp-load-image": "^5.16.6",
    "@vuepic/vue-datepicker": "^4.5.1",
    "blueimp-canvas-to-blob": "^3.29.0",
    "blueimp-load-image": "^5.16.0",
    "blurhash": "^2.0.5",
    "firebase": "^9.23.0",
    "fractional": "^1.0.0",
    "nuxt3-meta-pixel": "^1.0.9",
    "pinia": "^2.3.1",
    "vite": "^4.5.13",
    "vue": "^3.5.13",
    "vuedraggable": "^4.1.0"
  },
  "pnpm": {
    "overrides": {
      "@intlify/message-compiler": "^11.0.0",
      "@intlify/shared": "^11.0.0"
    }
  },
  "volta": {
    "node": "16.19.1"
  }
```

package.jsonのpnpmセクションとかはwebb検索しても見つからず、geminiに

"pnpm で overrides機能は使えないですか？"
と質問した結果として得たものです。

公式ドキュメントとしてはpnpm-workspace.yamlで設定しろと出てきました

https://pnpm.io/ja/settings#overrides
結局どのAWS保存サービスを使うか

# 背景

AWS の保存サービスをネットドライブとして使いたくて、調べる途中で段々わからなくなっているので、各保存サービスのコストとスピードを1回整理してみました。

# 本題

![Screenshot from 2025-05-04 09-41-00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/893830/7cc6b577-3cc8-4885-aa50-c2bdfb2da54a.png)

この画像を見たことがあるかもしれませんが、これは AWS 主な保存サービスのスピード（レイテンシー）の一覧表です。ただしスピードだけでは判断できないので、コストも追加してみました。


## コストとスピード一覧表

### 前提

- リージョンは全部東京
- AWS 外部に転送する料金は含んでいない
- USD だと数字が小さすぎてJPYに変換
- USD : JPY は 150 とする
- EBS io2は IOPS の費用もかかるけど一旦無視
- FSx はいろんなスペックがあるけど、今回は一番よく使うはずの Lustre: 125 MB/s/TiB、OpenZFS: Multi-AZ (HA) を選ぶ
- S3 Standard, S3 Standard-Infrequent Access, S3 Glacier Instant Retrieval それぞれがあるけど、今回は一番よく使うはずの S3 Standard を選ぶ

:::note warn
注意
サービスによって、一部特殊な費用要件があるけど、今回は簡単に説明したいため省きました。
:::

### 一覧表（数字）

![Screenshot from 2025-05-04 10-14-51.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/893830/228fa8f4-d1e9-4f47-b33b-a3e6d83b3b14.png)

### 一覧表（比較）

円でも見にくいので、さらに比較バーションを作ってみました。
S3 Glacier Flexible Retrievals の保存価格を星 1 つベースとして、ざっくりの比例を算出しました。

![Screenshot from 2025-05-04 10-14-56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/893830/ff803a0a-ceb8-4d83-845b-9f6eca4d75c4.png)

## 各サービスの解説

それではもう少しサービスごとを解説していきます。

### S3 Glacier

Glacier は基本アーカイブ用なので、ネットドライブとして使う想定はないけど、公式によりますと、S3 Glacier Instant Retrieval だと、「四半期に 1 回アクセスするような長期保存のアーカイブデータ」の場合で使う

### S3 Standard

一般的な保存サービスの選択肢で、Standard IA と Glacier 以外にはほぼ最安で、ただし、ややレーテンシーがあって、スピード敏感のタスクに向いていない

### S3 Express One Zone (画像はタイピングミス)

約1年前に発表された、One Zone (AZ) なので耐久性と可用性も落ちるけど、S3 Standard より相当早くて、コストもまだ安くて、もともと S3 の外部との接続方法手法が多いの観点も含めて、個人的に「ダークホース」の選択肢

### EFS

予想より相当高くて（星も星に見えないようなサイズになっちゃった）、複数 EC2 と繋ぐことができるメリットがあったとしても、コスパ的に悪い

### FSx

比較的に選択肢として考える方が少ないかもしれないけど、実は EFS よりやすいし、レーテンシーも低くて、外部との接続性だけは S3 Express One Zone の方が有利

### EBS

もちろん超早いけど、EC2 と繋がらないと使えないので、ネットドライブとして使う選択肢ではない(Instance storage ももちろん)

---

いかがでしょうか。ちなみにネットで S3 Express One Zone と EBS の詳しいスピード比較

https://www.idnet.co.jp/column/page_373.html

もあって、改めて S3 Express One Zone の凄さを感じました。
Kali Linuxでモニターモードを使うための手順まとめ（VirtualBox環境）



## はじめに

VirtualBox上のKali Linuxで、USB Wi-Fiアダプタを使ってモニターモードを有効にするまでの実体験を詳しくまとめます。この記事では、設定から基本的な使い方まで手順を追って解説します。

## 使用したWi-Fi子機

以下の製品を使用しました：

* 製品名：[GOWENIC AR9271 USB ネットカード](https://www.amazon.co.jp/dp/B0CK3LFQTV?ref=ppx_yo2ov_dt_b_fed_asin_title)
* チップセット：**Atheros AR9271**（モニターモード・パケットインジェクション対応）
* 対応周波数帯：**2.4GHz帯のみ**（5GHz帯は不可）

> 🔎 モニターモードを使うには、**対応チップセットを搭載したWi-Fi子機**が必須です。代表例としてはAR9271, RT3070, RTL8812AUなどがあります。

## VirtualBox環境での準備手順

### 1. Kali LinuxのVirtualBox版をダウンロード

1. Kaliの[公式サイト](https://www.kali.org/get-kali/#kali-virtual-machines)から `.7z` や `.ova` 形式のファイルをダウンロード。
2. VirtualBoxを起動し、メニューの「ファイル」→「仮想アプライアンスのインポート」で `.ova` を読み込む。

### 2. VirtualBox Extension Packのインストール

1. [VirtualBoxの公式サイト](https://www.virtualbox.org/wiki/Downloads)から Extension Pack を入手。
2. VirtualBoxで「ファイル」→「環境設定」→「拡張機能」を開き、Extension Packを追加。

### 3. USB設定でWi-Fiアダプタを有効化

1. Kali仮想マシンの「設定」→「USB」からUSB 2.0または3.0を選択。
2. 「＋」マークでAR9271（または目的のデバイス）を追加。

### 4. Kali LinuxでUSBデバイスが認識されているか確認

```bash
lsusb
```

出力に `Atheros Communications AR9271` が含まれていればOK。

### 5. ネットワークインターフェースの確認

```bash
ip link
```

`wlan0` などが表示されていれば無線LANアダプタが認識されています。

### 6. モニターモードへ切り替える方法

#### 方法①：iwconfigを使用

```bash
sudo ip link set wlan0 down
sudo iwconfig wlan0 mode monitor
sudo ip link set wlan0 up
```

#### 方法②：aircrack-ngのairmon-ngを使用（おすすめ）

```bash
sudo airmon-ng check kill
sudo airmon-ng start wlan0
```

※ 終了するときは `sudo airmon-ng stop wlan0mon`

## モニターモードでできること（例）

* 周囲のWi-Fiアクセスポイントの一覧を取得

```bash
sudo airodump-ng wlan0
```

* 特定のアクセスポイントに接続している端末を観察

```bash
sudo airodump-ng --bssid [BSSID] -c [チャンネル] wlan0
```

* DeAuthパケットを送信（例：自分のスマホのみ）

```bash
sudo aireplay-ng --deauth 10 -a [ルーターのMAC] -c [スマホのMAC] wlan0
```

## 注意点

* モニターモード中は通常のインターネット接続ができなくなります。
* 対象のWi-Fi・端末は**自分の所有物に限定**してください。
* 公共の電波や他人のアクセスポイントに対する解析や攻撃は**違法行為**です。

---

Kali Linuxでのモニターモードは、無線セキュリティ学習において非常に強力な機能です。正しく扱えばネットワークの理解が深まりますので、安全かつ合法的な範囲で活用しましょう。
Databricksチュートリアル(Day3): 初めてのテーブルを作成し、特権を付与する

## 前提
・利用環境：Databricks

https://www.databricks.com/jp/try-databricks?scid=7018Y000001Fi15QAC&utm_medium=paid+search&utm_source=google&utm_campaign=17377047998&utm_adgroup=138148229998&utm_content=trial&utm_offer=try-databricks&utm_ad=732035937815&utm_term=databricks%20%E3%83%88%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%AB&gad_source=1&gclid=CjwKCAiA8Lu9BhA8EiwAag16b8b3zbkIb3V7gp-8VUwKukXnhtVZRQ-1RY8SbETmGVgNT4bQramYmRoCX5wQAvD_BwE#account

## 参考ドキュメント
https://docs.databricks.com/gcp/ja/getting-started/create-table
## 操作手順（動画）
<iframe width="100%" height="315" src="https://www.youtube.com/embed/5n0SkH7rYWU?si=b3Bt5pGMJ7PN3boA" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
統計検定2級 最小二乗法

## はじめに
今回は統計検定2級の最小二乗法を学んでいきます。
前回、[単回帰分析](https://qiita.com/koji0705/items/45041f2aba8d6c180013)で最小二乗法で割り出しました。そういえば、最小二乗法ってなんだっけ、あー、そうだそうだとなることが多かったので、記事にしていこうと思います！！

## 🎯 最小二乗法（さいしょうにじょうほう）とは？

### 💡 定義  
最小二乗法とは、**観測データと回帰直線とのズレ（二乗誤差）を最小にする**ことで、  
回帰式（例：$y = \beta_0 + \beta_1 x$）の係数 $\beta_0$, $\beta_1$ を求める方法です。

---

### 🧠 目的  
データ点 $(x_i, y_i)$ が与えられたとき、直線の予測値 $\hat{y}_i = \beta_0 + \beta_1 x_i$ との**誤差**をできるだけ小さくする。

このときの「誤差」は：
$$
e_i = y_i - \hat{y}_i
$$

:::note info
定義だけ聞くと難しく感じる？んですが、大した話じゃないです。実測値をいくつか取り、大体こんな傾向だよねって、数直線を引く。その時に、どこら辺に線を引けばいいんだろうってはなしになります。
で、大体この辺かなってところを見つけるためのもの。数直線を引いた時に、数直線からの差の合計が一番小さくなるように引こうねって考え。ただ、そのまま差を足すとプラスがマイナスを打ち消してしまうので、2乗しておこうぜって考え
:::


---

### 🔢 最小にしたい指標（目的関数）：

$$
\text{誤差の二乗和} = \sum_{i=1}^{n} (y_i - (\beta_0 + \beta_1 x_i))^2
$$

この二乗誤差が**最小**になるように、$\beta_0$ と $\beta_1$ を選ぶ。

---

### ❓ なぜ「二乗」するのか？

- 正負の誤差が打ち消しあわないようにするため（単なる合計ではダメ）  
- 絶対値よりも数学的に扱いやすい（微分できる）ため

---

### ✅ 最小二乗法の解で得られる公式：

傾き $\beta_1$：

$$
\beta_1 = \frac{\sum (x_i - \bar{x})(y_i - \bar{y})}{\sum (x_i - \bar{x})^2}
$$

切片 $\beta_0$：

$$
\beta_0 = \bar{y} - \beta_1 \bar{x}
$$

---

最小二乗法は、**単回帰分析だけでなく、重回帰分析、時系列、機械学習（線形回帰）など幅広く使われる基本手法**です。
Cドライブ方法節約のまとめ①

###### 以下は、Cドライブ節約方法のまとめ
##    はじめに

　　　　こちらは、主に設定しておくと、Cドライブの使用が節約できる方法のまとめです。


## ○<font color="blue">Cドライブに出力されるデータをDドライブ等に保存する</font>

　 たとえば、Cドライブの容量削減のため、スクリーンショット保存先フォルダを設定上は変更しないまま、仮想的（見た目は通常フォルダに見えるが、実体は別の場所にあるフォルダ）にCドライブを、Dドライブへシンボリックリンクというで方法で保存先を変更します。

#### 【事前準備】
Link Shell Extension（LSE）をインストールしてください。
公式サイト：http://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html

ソフトウェアのインストール・使用方法（詳細）
[マウス操作だけでシンボリックリンクを作成できる](https://blog.halpas.com/archives/8258)


#### 【操作手順】
## ○<font color="blue">実態を保存するフォルダを設定する</font>（リンク元として選択）

　 (1) フォルダ「D:」を開く。
　 (2) 今のCドライブにある、スクリーンショットを保存しているフォルダと同じ名前のフォルダ（例：スクリーンショット）のフォルダを新規作成する。
　 (3) 作成したフォルダを右クリックして、[リンク元として選択（L）]を選ぶ  
　 (4) スクリーンショット等の保存先フォルダ（例：C:\Users\nano357\OneDrive\画像）に移動し、「スクリーンショット」フォルダを右クリックし、 →「リンクを作成」→「シンボリックリンク」を選びます。

#### 【動作確認と補足】
・これで、スクリーンショットがDドライブに保存されます。

#### 【トラブル防止のために】
・OneDriveの「画像フォルダ全体のバックアップ」を解除しておくとより安定します。

#### 【OneDriveの設定方法】
1. タスクバーのOneDriveアイコンを右クリック → 「設定」
2. 「バックアップ」タブ → 「フォルダーの管理」
3. 「画像」のチェックを外して、バックアップ対象から除外します
django restframeworkのSerializerのテクニック

djangoでrestframeworkを使っていて、リレーションなどの処理に関して
Serializerのテクニックを備忘録として書き残します。随時更新していきたいと思います。

## CRUD処理一括
CRUD処理を一つにまとめたViewSerという便利な機能があります。

"Product"というモデルがあったとしてこのモデルのCRUD処理を実装するには下記のように実装します。
```views.py
from rest_framework import viewsets #ViewSet使用

class ProductViewSet(viewsets.ModelViewSet):
    serializer_class = ProductSerializer
    queryset = Product.objects.all()
```

```urls.py
from rest_framework.routers import DefaultRouter
from .views import ProductViewSet

router = DefaultRouter()
router.register('products', ProductViewSet)

urlpatterns = [
    path('', include(router.urls)),#ViewSetのURL
]
```
これでCRUD処理が可能になります。
プロジェクトアプリで定義したパスに、この例だ"/products"をつけて
GET,POST,PATCH,DELETEのメソッドで通信します。
"router.register('******', ProductViewSet)"の******の部分がパスになり
自由に設定できます。(例ではproductsとしています)

・一覧(GET通信):/products/ 
・新規登録(POST通信):/products/ 
・詳細(GET通信):/products/(pk)/ 
・更新(PATCH通信):/products/(pk)/ 
・削除(DELETE通信):/products/(pk)/ 



## 単純なリレーション
例えば従業員モデル(Emproyee)に紐づく部署モデル(Department)を
単純にリレーションする時は下記のように書きます。
```python
class EmproyeeSerializer(serializers.ModelSerializer):
    department = DepartmentSerializer(many=True,read_only=True)#部署をリレーション
    class Meta:
        model = Emproyee
        fields = '__all__'
        read_only_fields = ('user',)
```
これで、フロントエンド(React)では下記のような感じでリレーションモデルの内容を表示できます。
```typescript
<p>{emproyee.department.id}<p>
<p>{emproyee.department.name}</p>
//出力結果(例):
13
経理部
```



## Slug(テキスト)でのリレーション
単純なリレーションから発展して、リレーション先のモデルの特定の1つのフィールドを
取り出してメインのモデルのフィールドに追加するような処理もできます。
単純なリレーションでは、従業員モデル(Emproyee)に部署モデル(Department)をオブジェクトで
紐付けていましたが、部署モデルのフィールドの値を従業員モデルのフィールドに追加できます。

```python
class EmproyeeSerializer(serializers.ModelSerializer):
    #部署モデルのフィールドの値をリレーション
    department = serializers.SlugRelatedField(
        read_only=True,
        slug_field='name'#ここでフィールドを指定する
     )
    class Meta:
        model = Emproyee
        fields = '__all__'
        read_only_fields = ('user',)
```

こうすると、オブジェクトではなく値でリレーションします。
"slug_field="のところでフィールドを指定します。ここは、好きなフィールドに指定可能です。
フロントエンド(React)では下記のような感じでリレーションモデルの内容を表示できます。
```typescript
<p>{emproyee.department}<p>
//出力結果(例):
経理部
```

https://www.django-rest-framework.org/api-guide/relations/#slugrelatedfield
【公ド読】IDE で GitHub Copilot に質問する

【公式ドキュメントを読もうシリーズ】IDE で GitHub Copilot に質問する

## シリーズ概要
[https://qiita.com/yasu_programming/items/cec66f9e8d5d571e9ce3](https://qiita.com/yasu_programming/items/cec66f9e8d5d571e9ce3)

## URL
[https://docs.github.com/ja/copilot/using-github-copilot/copilot-chat/asking-github-copilot-questions-in-your-ide](https://docs.github.com/ja/copilot/using-github-copilot/copilot-chat/asking-github-copilot-questions-in-your-ide)

## 説明

具体的なCopilot Chatの使用方法がまとめられている。

### プロンプトの送信

> 応答には、テキスト、コード ブロック、ボタン、画像、URI、およびファイル ツリーが含まれている場合があります。 応答には、多くの場合、対話型要素が含まれます。

Copilot Chatで画像をドラッグアンドドロップで添付することができるのは確認できた。
画像も出力されるという意味だと思うが、どうやるんだろう。
応答=入力という意味なのだろうか？
現時点(2025年5月4日時点)では、画像生成を確認できていない。

### プロンプトでキーワード (keyword)を使用する

#### チャット参加者

`@`を付けることで、特定のドメインに絞り込んだチャットを行うことができるみたい。
下記リンクで使えるチャット参加者についてまとめられている。

[https://docs.github.com/ja/copilot/using-github-copilot/copilot-chat/github-copilot-chat-cheat-sheet?tool=vscode#chat-participants](https://docs.github.com/ja/copilot/using-github-copilot/copilot-chat/github-copilot-chat-cheat-sheet?tool=vscode#chat-participants)

`@azure`,`@github`,`@terminal`,`@vscode`,`@workspace`

現時点では、パブリック プレビュー 段階であるので、今後変更になるかもしれない。
そもそもだが、質問モードだとか、エージェントモードでも使えるコマンドの種類違うことに今気づいたが、チャットモードの違いも気を付けないといけない。

#### スラッシュコマンド

参考URLがわかりやすいが、
`/explan`
コードの説明

`/fix`
コードの修正プログラムの提案

`tests`
単体テストの生成

`help`
Github Copilotの使用に関するクイックリファレンス

などほかにもあるが、使えそうなのいろいろある。

参考URL
[https://docs.github.com/ja/copilot/using-github-copilot/copilot-chat/github-copilot-chat-cheat-sheet?tool=vscode#chat-variables](https://docs.github.com/ja/copilot/using-github-copilot/copilot-chat/github-copilot-chat-cheat-sheet?tool=vscode#chat-variables)

#### チャット変数

`#`を付けると、いろいろと変数として扱うことができる。
スラッシュコマンドでも共有したリンクにチャット変数に関するドキュメントが書かれているが、若干vscodeで触るコマンドとで差異が発生している(2025年5月4日)。
vscode触りながら確認します。

### Copilot Chat とCopilot Editの違い

Copilot Chatはコードの修正案を提出してくれるが、Copilot Editは直接git diffのような感じで、差分を提案してくれる。

## 所感

ボリューミーなページでした。
エージェントモードだとか、画像入力に関することも書かれていました。
クイックチャットのコマンドが難しいけれども、ほかのコマンドと干渉しないようにするには、適切なんだろうなと思った。
`ctrl + shift + alt + l`
情報処理技術者試験　ネットワークスペシャリスト


情報処理技術者試験
https://qiita.com/kaizen_nagoya/items/749f46aeaceded85d570

情報処理技術者試験　受ける前に
https://qiita.com/kaizen_nagoya/items/da594cfeca93a39ea5f1

# ネットワークスペシャリスト
## 2025
午前 I
https://www.ipa.go.jp/shiken/mondai-kaiotu/nl10bi0000009lh8-att/2025r07h_koudo_am1_qs.pdf
午前　II
https://www.ipa.go.jp/shiken/mondai-kaiotu/nl10bi0000009lh8-att/2025r07h_nw_am2_qs.pdf
午後　I
https://www.ipa.go.jp/shiken/mondai-kaiotu/nl10bi0000009lh8-att/2025r07h_nw_pm1_qs.pdf
午後　II
https://www.ipa.go.jp/shiken/mondai-kaiotu/nl10bi0000009lh8-att/2025r07h_nw_pm2_qs.pdf
## 2024
午前 I

午前　II

午後　I

午後　II

## 2023
午前 I

午前　II

午後　I

午後　II

## 2022
午前 I

午前　II

午後　I

午後　II

## 2021
午前 I

午前　II

午後　I

午後　II

## 2020
午前 I

午前　II

午後　I

午後　II

## 2019
午前 I

午前　II

午後　I

午後　II

## 2018
午前 I

午前　II

午後　I

午後　II

## 2017
午前 I

午前　II

午後　I

午後　II

## 2017
午前 I

午前　II

午後　I

午後　II
## 2011
午前 I
https://www.ipa.go.jp/shiken/mondai-kaiotu/ug65p90000003ojp-att/2011h23a_koudo_am1_qs.pdf
午前　II
https://www.ipa.go.jp/shiken/mondai-kaiotu/ug65p90000003ojp-att/2011h23a_nw_am2_qs.pdf
午後　I
https://www.ipa.go.jp/shiken/mondai-kaiotu/ug65p90000003ojp-att/2011h23a_nw_pm1_qs.pdf
午後　II
https://www.ipa.go.jp/shiken/mondai-kaiotu/ug65p90000003ojp-att/2011h23a_nw_pm2_qs.pdf
## 2010
午前 I
https://www.ipa.go.jp/shiken/mondai-kaiotu/ug65p90000004d6f-att/2010h22a_koudo_am1_qs.pdf
午前　II
https://www.ipa.go.jp/shiken/mondai-kaiotu/ug65p90000004d6f-att/2010h22a_nw_am2_qs.pdf
午後　I
https://www.ipa.go.jp/shiken/mondai-kaiotu/ug65p90000004d6f-att/2010h22a_nw_pm1_qs.pdf
午後　II
## 2009
午前 I
https://www.ipa.go.jp/shiken/mondai-kaiotu/ug65p90000004d6f-att/2010h22a_nw_pm2_qs.pdf
https://www.ipa.go.jp/shiken/mondai-kaiotu/gmcbt8000000f3yi-att/2009h21a_koudo_am1_qs.pdf
午前　II
https://www.ipa.go.jp/shiken/mondai-kaiotu/gmcbt8000000f3yi-att/2009h21a_nw_am2_qs.pdf
午後　I
https://www.ipa.go.jp/shiken/mondai-kaiotu/gmcbt8000000f3yi-att/2009h21a_nw_pm1_qs.pdf
午後　II
https://www.ipa.go.jp/shiken/mondai-kaiotu/gmcbt8000000f3yi-att/2009h21a_nw_pm2_qs.pdf
[個人開発] VSCodeで作業時間を見える化する拡張機能を作ってみた

vscodeの拡張機能「Time Tracker」を作成したので共有します
## Time Trackerとは
一言で言うと、VSCode上でファイルごとの作業時間を自動計測する拡張機能です。
「どのファイルに一番時間使ったんだろう？」
「今日はプログラミングに何時間集中したかな？」
「タスクの見積もりにかかった実際の時間を知りたい」
そんな疑問に答えてくれるツールを目指して開発しました。
## 主な機能
#### 1. ファイルの切り替えで自動計測スタート 🚀
ファイルを開いた瞬間から時間計測が始まり、別のファイルに切り替えると自動でストップ＆新しいファイルの計測がスタートします。
普段通りにコーディングするだけで、時間データが溜まっていきます。
#### 2. ステータスバー ⏱️

![ステータスバー](https://github.com/kpab/images/blob/main/blog/timer/status-bar.png?raw=true)

VSCodeの右下には、以下の情報が常に表示されます：

今日の合計作業時間
現在開いているファイルの作業時間

「あ、もう2時間経ってる。休憩しよう」みたいな使い方ができます。
#### 3. タイムカードで振り返り 📊
作業データを可視化する「タイムカード」機能があります。


![タイムカード](https://github.com/kpab/images/blob/main/blog/timer/time-card.png?raw=true)

- グラデーション背景が綺麗
- ファイルごとの時間配分がグラフでわかる


#### 4. フローティングタイマー ⏳
常時表示できる小さなタイマーウィンドウ。

- 作業中も邪魔にならないサイズ
- 一時停止やミニマイズ機能付き
- ドラッグして好きな位置に配置可能

![フローティングタイマー](https://github.com/kpab/images/blob/main/blog/timer/float-timer.png?raw=true)

#### 5. 除外機能 🚫
以下のような時に便利：

- 設定ファイルは計測から除外したい
- チュートリアルを見てるだけの時間はカウントしない
- READMEの確認時間は省きたい

ワンクリックで計測対象から外せます。
#### 6. リセットボタンで気軽に再スタート 🔄
「新しいプロジェクトを始めるから時間をリセットしたい」そんな時に便利なリセット機能

## 実際に使ってみた感想
1週間使ってみましたが、以下のような発見がありました：

- READMEを書く時間が意外と長い：コーディングよりドキュメント作成に時間がかかっていた
- 休憩のタイミングがわかる：60分以上同じファイルを触ってたら休憩サイン

## インストール方法
下記リンクからインストールいただけます

https://marketplace.visualstudio.com/items?itemName=kpab.time-tracker-card

## こんな人にオススメ

- 個人開発者で作業ログを取りたい人
- タスクの見積もり精度を上げたい人
- 単純に「何に時間を使ってるか」を知りたい人

## さいごに
個人的なニーズから始まったこのプロジェクトですが、思いの外便利なツールが完成しました。時間管理に悩むエンジニアの皆さんの役に立てば幸いです。
ご意見やバグ報告は、GitHubのIssueでお待ちしています！

https://github.com/kpab/vscode-timer
デプロイ完全ガイド｜基本から応用・最近のトレンドまで


##  はじめに

アプリを開発しただけでは、ユーザーは使えません。  
「作ったアプリを、誰でもアクセスできる場所に公開する」こと、それが **デプロイ（Deploy）** です。

本記事では、

- デプロイの基本的な考え方
- よく使われる方法・ツール
- 開発規模に応じた応用パターン
- 2025年現在の最新トレンド

までを一気に解説します。

---

## 目次

1. [デプロイとは？](#デプロイとは)
2. [代表的なデプロイ方法まとめ](#代表的なデプロイ方法まとめ)
3. [ステージごとのデプロイ戦略](#ステージごとのデプロイ戦略)
4. [CI/CDとの関係](#cicdとの関係)
5. [デプロイのトラブルと対策](#デプロイのトラブルと対策)
6. [2025年のデプロイトレンド](#2025年のデプロイトレンド)
7. [まとめ](#まとめ)

---

##  デプロイとは？

> **アプリやサービスを、ユーザーがアクセスできる本番環境に配置・公開すること**

- 開発者のローカル環境 → 本番環境への「移動・配置・起動」
- Webサービス、API、バッチなど対象は多様
- チーム開発では、「安全・再現可能・自動化された」デプロイが重要

---

##  代表的なデプロイ方法まとめ

### 1. 静的サイトのデプロイ（HTML/CSS/JS）

| 方法 | 特徴 | 代表サービス |
|------|------|---------------|
| GitHub Pages | リポジトリにPushで即公開 | GitHub |
| Netlify/Vercel | 自動ビルド＋デプロイ | Jamstack系に強い |
| Firebase Hosting | SPA/PWA向け | Google連携◎ |

---

### 2. 動的アプリ（Node.js、Rails、Djangoなど）

| 方法 | 特徴 | 代表サービス |
|------|------|---------------|
| Heroku/Railway | PaaS（インフラ不要） | 学習用・中規模開発 |
| VPS（さくら/ConoHa） | SSHアップロード＋PM2等で起動 | 自由度高いが手動管理多め |
| Docker + VPS | コンテナ単位で管理 | 本番再現性◎、構成が複雑に |

---

### 3. クラウドコンテナ/サーバーレス

| 方法 | 特徴 | 代表サービス |
|------|------|---------------|
| AWS Elastic Beanstalk | PaaS寄りだが柔軟 | AWSフル活用に向く |
| Google Cloud Run | コンテナ1個から実行 | 手軽かつスケーラブル |
| AWS Lambda | サーバー不要でAPI提供 | 小規模〜イベント駆動 |

---

##  ステージごとのデプロイ戦略

### ローカル開発 ➝ ステージング ➝ 本番

| ステージ | 目的 | デプロイ対象 |
|----------|------|---------------|
| 開発環境 | 手元での動作検証 | localhost / Docker |
| ステージング | テスト・レビュー用 | staging.example.com |
| 本番環境 | ユーザーが触る環境 | example.com |

- ステージングでの**自動テスト/ビルド**が安全性のカギ
- 本番では**ロールバック戦略**が重要（例：Blue-Green Deploy）

---

##  CI/CDとの関係

**CI（継続的インテグレーション）**と**CD（継続的デリバリー/デプロイ）**は、現代のデプロイには不可欠。

###  一般的なCI/CD構成（例：GitHub Actions）

```yaml
name: Deploy to Vercel

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: npm install
      - run: npm run build
      - run: vercel --prod --token=${{ secrets.VERCEL_TOKEN }}
```

- GitHubにPushするだけで、**自動的にビルド＆本番反映**
- Firebase, Cloud Run, ECSなども同様に設定可能

---

##  デプロイのトラブルと対策

| よくある問題 | 原因 | 解決策 |
|--------------|------|--------|
| 動かない・落ちる | `.env`漏れ / パーミッション / ポート設定 | 環境変数とログをチェック |
| 前のコードが表示される | キャッシュ / CDN | キャッシュクリア、バージョン付与 |
| 差分だけ更新できない | 手動アップロード | GitベースのCI/CDに移行する |

---

##  2025年のデプロイトレンド

| トレンド | 解説 |
|----------|------|
| **Cloud Run + GitHub Actions** | 最小構成でフルCI/CDを実現。コスト効率・拡張性◎ |
| **Vercel + Edge Functions** | フロントとサーバーレスを統合。SSG＋動的APIが当たり前に |
| **Infrastructure as Code (IaC)** | Terraform/CDKで**インフラもコード管理**が主流に |
| **Preview環境の自動生成** | プルリクごとに自動でURL発行 → 非エンジニアレビューも可能 |
| **分散アプリの自動スケーリング** | KubernetesやFargateによるオートスケール化 |

---

##  まとめ

| 要点 | 内容 |
|------|------|
| デプロイとは | アプリを「公開する」ための一連の作業 |
| 手動より自動 | CI/CDを取り入れて安全＆効率化 |
| サービス選び | 静的ならVercel、動的ならRender、拡張性重視ならCloud Run |
| トレンド | コンテナ化、IaC、エッジ実行、オートスケールが今の主流 |
情報処理技術者試験 応用情報


情報処理技術者試験
https://qiita.com/kaizen_nagoya/items/749f46aeaceded85d570

情報処理技術者試験　受ける前に
https://qiita.com/kaizen_nagoya/items/da594cfeca93a39ea5f1

# 応用情報
## 2025
午前


https://www.ipa.go.jp/shiken/mondai-kaiotu/nl10bi0000009lh8-att/2025r07h_ap_am_qs.pdf

論理和
論理積
含意

午後

## 2024
午前
https://www.ipa.go.jp/shiken/mondai-kaiotu/m42obm000000afqx-att/2024r06a_ap_am_qs.pdf

午後
https://www.ipa.go.jp/shiken/mondai-kaiotu/m42obm000000afqx-att/2024r06a_ap_pm_qs.pdf
## 2023
午前
https://www.ipa.go.jp/shiken/mondai-kaiotu/ps6vr70000010d6y-att/2023r05a_ap_am_qs.pdf
午後
https://www.ipa.go.jp/shiken/mondai-kaiotu/ps6vr70000010d6y-att/2023r05a_ap_pm_qs.pdf
## 2022
午前

午後

## 2021
午前

午後

## 2020
午前

午後

## 2019
午前

午後

## 2018
午前

午後

## 2017
午前

午後
NPO TOPPERS SSP と OEK/VDX OS

toppers 3分岐
https://qiita.com/kaizen_nagoya/items/18e772db71a763b919a4

toppers/jsp/m16c, m32c版から、
次の３つが分岐しています。

１ TOPPERS　OSEK/VDX
２ TOPPERS edu jsp
3 TOPPERS SSP

全体の方向性の違いを説明するとともに、
具体的なファイルでの違いを順次説明予定。

のうち、次の３つの違いを個別に記載し、
4 JSPとOSEK/VDX
5 JSPとJSP EDU
6 JSPとSSP

その後、
7 SSPとOSEK/VDX
8 SSPとJSP EDU
の違いを詳細に記述し、相互に技術導入を計画する。

8は、６で、JSPのうちEduだけに限定したため既述となっている。

# osek/vdx

osekをuploadした。
https://qiita.com/kaizen_nagoya/items/6bc7eb2ec635e88afd5a

osek
https://github.com/kaizen-nagoya/osek



# ssp
toppers/ssp upload
https://qiita.com/kaizen_nagoya/items/cffa0aaf2c029cef7334

Github
https://github.com/kaizen-nagoya/toppersssp


# 比較
SSPは、OSEK/VDX OSのBCC1相当である。
上記OSEK/VDX OSは、ECC2しか既述していない。
SSPを参考に、BCC1を既述するとよい。
XAIO ESP32C6+SSD1306、(半角全角あり)「Abcあいうえお、埼玉」と表示して遊ぶ。



参考
----

https://github.com/Tamakichi/Arduino-misakiUTF16


結果
----

![image_original(28).jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/840352/c3e5a853-25dd-47b6-9944-3f57e3006f22.jpeg)



プログラム
----

```c++


//misaki_test5_XIAO_ESP32C6


//ヘッダーファイル
#include <Arduino.h>
#include <Wire.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306.h>
#include <misakiUTF16.h>


//定義
#define SCREEN_WIDTH 128     // OLED display width, in pixels
#define SCREEN_HEIGHT 64     // OLED display height, in pixels
#define OLED_RESET -1        // Reset pin # (or -1 if sharing Arduino reset pin)
#define SCREEN_ADDRESS 0x3C  ///< See datasheet for Address; 0x3D for 128x64, 0x3C for 128x32
Adafruit_SSD1306 display(SCREEN_WIDTH, SCREEN_HEIGHT, &Wire, OLED_RESET);


//初期化
void setup() {

  //I2Cの初期化
  Wire.begin(D9, D10);  //XIAO ESP32C6+SSD1306
  //Wire.begin(D10,D9); //XIAO ESP32C6+GROVE

  // I2Cアドレスは使用するディスプレイに合わせて変更する
  display.begin(SSD1306_SWITCHCAPVCC, SCREEN_ADDRESS);

}  //setup


//メインループ
void loop() {

  unsigned char font[8];  // フォント格納バッファ
  int x = 0;
  uint8_t width;   // フォント幅
  uint16_t ucode;  // utf16文字コード

  char *str = "Abcあいうえお、埼玉";  // 文字列
  char *pUTF8 = str;

  // 画面表示をクリア
  display.clearDisplay();

  while (*pUTF8) {  // 文字列分ループ

    pUTF8 += charUFT8toUTF16(&ucode, pUTF8);  // utf8 1文字分をutf16に変換
    width = isZenkaku(ucode) ? 8 : 4;         // フォント幅の取得
    getFontDataByUTF16(font, ucode);          // フォントデータの取得

    //ビットマップの表示
    display.drawBitmap(x, 0, font, width, 8, WHITE);
    x = x + width;

  }  //while

  // 描画バッファの内容を画面に表示
  display.display();

  delay(1000);  //1秒待つ

}  //loop



```
【SAS対策】IAM まとめ

## はじめに
ソリューションアーキテクトアソシエイト対策の学習メモ
## IAMとは
 - 「Identity and Access Management」の略
 - ユーザ、グループのアクセス権を適切に管理するための仕組み
 - ユーザは複数グループに所属できる、所属しないこともできる
 - グループ内にグループを作成することはできない
![IAMグループ.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3586050/45c10caa-90af-424f-be35-dbf27873860b.png)
## IAM ロール
 - AWSサービスが別のサービスにアクセスする権限を与えるための仕組み
 - 例：EC2サーバにロールをアタッチしてS3へアクセスを許可する
## ポリシー
 - ユーザ、グループ、ロール、特定のAWSリソースにJSONで書かれた権限を割り当てできる
 - アタッチされた対象が「どのような操作ができるか」
```
{
  // Version(必須、常に2012-10-17)
  "Version": "2012-10-17", 
  "Statement": [
    {
      // Statementの識別子、任意(オプション)
      "Sid": "ThirdStatement", 
      // アクセス許可、拒否(Arrow,Deny)
      "Effect": "Allow", 
      // このポリシーが適用されるアカウント/ユーザ/ロール
      "Principal": { 
          "AWS: ["arn:aws:iam:1234567890:root"]"
      }
      // このポリシーで許可/拒否されるアクション一覧
      "Action": [ 
        "s3:List*",
        "s3:Get*"
      ],
      // アクションの対象となるリソース一覧
      "Resource": [ 
        "arn:aws:s3:::amzn-s3-demo-bucket-confidential-data",
        "arn:aws:s3:::amzn-s3-demo-bucket-confidential-data/*"
      ],
      // ポリシーが適用される条件(オプション)
      "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
    }
  ]
}
```
## 管理ポリシーとインラインポリシー
- 管理ポリシー
  - AWS管理ポリシー
    - AWSによって事前に用意されたポリシーのこと(AmazonEC2FullAccessなど)
    - 複数のユーザ、グループ、ロール等に適用できる
  - カスタマー管理ポリシー
    - ユーザが作成したポリシー
    - 複数のユーザ、グループ、ロール等に適用できる
- インラインポリシー
  - IAM アイデンティティ (ユーザー、グループ、またはロール) に埋め込まれたポリシー
  - 作成したポリシーをユーザ等に適用すると、他のユーザ等に対して適用することが出来ない
## アイデンティティベースのポリシー
-  ユーザー、グループ、またはロールにアタッチ され、そのエンティティが実行できるアクションを定義
## リソースベースのポリシー
- 特定のAWSリソース（S3バケットなど）に直接アタッチされそのリソースにアクセスできるエンティティ（IAM ユーザー、ロール、AWS アカウントなど）を定義
個人的備忘録：「user_name」が足りなかった…フロントとバックの結合テストトラブルを振り返ってみた

## はじめに

Next.js と FastAPI を使ってユーザー登録機能を実装している中で、フロントエンドとバックエンドのAPIインターフェースの不一致によって、登録処理が失敗していることに気づきました。

**個人の備忘録程度の走り書きとなっておりますが、温かい目で見守っていただければ幸いです。**

## 書こうと思ったきっかけ

受講しているITスクールのハッカソンの開発の一環で、登録機能の不具合を解決した経験を忘れないように記事にまとめています。

## 内容

今回扱ったのは、Next.jsで作られた一般ユーザー登録ページです。このフォームでは「名前」「メールアドレス」「パスワード」を入力して送信します。

バックエンドのFastAPI側では、`user_name`, `email`, `password` の3つを含むJSON形式のデータを受け取ることを想定していました。

:::note alert
**しかし、元のフロントエンド実装では `user_name` が送られておらず、登録処理が失敗していました。**
:::

そのため、以下のように修正を行いました：

```tsx
body: JSON.stringify({
  email,
  password,
  user_name: userName, // ← FastAPIと合わせるために追加
})
```

**バックエンドの一部コード抜粋**

```py
new_user = User(
    email=user_data.email,
    user_name=user_data.user_name,
    password_hash=hash_password(user_data.password)
)
db.add(new_user)
db.commit()
```

- `User(...)` で新しいユーザーオブジェクトを作成

- `db.add(new_user)` でセッションに追加

- `db.commit()` でDBに永続化

**実際のコード**

https://github.com/2025SpringTeamA/frontend/blob/main/src/app/register/page.tsx

これにより、FastAPIの `/register` エンドポイントと正しく連携できるようになり、ユーザー登録後に `/home` ページへリダイレクトされるようになりました...！

## まとめ

フロントエンドとバックエンド間のAPI仕様の不一致は、よくある落とし穴です。

:::note warn
**特にスキーマが定義されているバックエンド（今回で言えば `UserRegister`）に合わせて、正しくデータを送信する必要があります。**
:::

今回の経験は、開発中のバグ発見・修正にとても役立ちました...！
pythonからCMLを操作する

シスコのCMLをpythonから操作するための環境設定に苦戦したのでメモを残します。
結論から言えば、なぜ動作しないのかよく分からなかったけど、
コードが動作するバージョンの組み合わせを確認しました、という内容です。

# CMLについて
シスコのルータについて勉強したいけど、実機を買うのは高いしかさばる。
そんな人はシミュレータCML(Cisco Modeling Labs)を使うことを考えてみてはいかがでしょうか。

https://www.cisco.com/c/ja_jp/products/cloud-systems-management/modeling-labs/index.html

最近無料ライセンスが登場したので、手軽に試せるようになりました。
導入方法は本題ではないので、別のドキュメントにゆだねます。

# いくつかの方法
CMLをpythonから操作する方法は複数あります。
+ virl2_clientを使う
CMLをpythonから操作するのに用意されたライブラリです。

https://developer.cisco.com/docs/virl2-client/

APIからノードを起動／停止したり、リンクを起動／停止したり、インタフェイスを起動／停止したり、できます。
しかし、装置にコマンドを投入して応答を取得する、みたいなことができなくて、以下の方法を探索することになりました。（ネットワーク運用の実務では、装置に直接コマンドを投入することも多いですので。。）

+ netmikoを使う
netmikoとは、ネットワーク機器にSSHで接続し、コマンドを実行できるライブラリの一つです。
virl2_clientのドキュメントでも以下のように言及されていたので、
便利なのかなと思ったけど、netmikoに関する情報が少ないのと、とりあえず後述するpyATSで動作したので、深掘りは保留中です。
```
The following example shows how the VIRL2 client library can be combined with Netmiko.
```

+ pyATSを使う
今回のトラブルの主役です。

https://developer.cisco.com/docs/pyats/

ネットワーク運用の自動化に対応するために、割と力を入れて開発されているみたいです。

# 動かしたいサンプルコード

ネットで見かけたサンプルコードを加工して作成しました。
```
from virl2_client import ClientLibrary

VIRL_CONTROLLER = "XX.XX.XX.XX"
VIRL_USERNAME = "username"
VIRL_PASSWORD = "password"
LAB_NAME = "lab_name"
TARGET_NODE = "target_node"

client = ClientLibrary(VIRL_CONTROLLER,
                    VIRL_USERNAME,
                    VIRL_PASSWORD,
                    ssl_verify=False)

our_lab = client.find_labs_by_title(LAB_NAME)[0]
our_lab.pyats.sync_testbed(VIRL_USERNAME, VIRL_PASSWORD)
node = our_lab.get_node_by_label(TARGET_NODE)
result = node.run_pyats_command("ping YY.YY.YY.YY timeout 1 rep 2") # タイムアウト1秒、繰り返し2回
print(result)
```
１行目の通り、virl2_clientを使っているのですが、
装置へのコマンドにはrun_pyats_commandを使っていて、
これを実行する前にsync_testbedをしておかないといけなくて、
その前提としてpyatsをインストールしておく必要があります。

# 結局バージョンが大事

以下のバージョンの組み合わせで動作しました。
```
CML==2.7.2
python==3.12.3
pyats==24.10
virl2_client==2.7.1
```


# 参考文献

参考にしたのは以下のページです。

https://qiita.com/tokatsu/items/58fbd2b2b219f33b8721

https://qiita.com/kykanno/items/8a7d4aae66767b7159a0
エンジニア歴4ヶ月目でハッカソンに参加してみた話

先日、APIを使ってサービスを開発するというお題のハッカソンに参加しました。
くじ引きでランダムにチームが編成され、私達は4人チームの一員として3時間で一つのサービスを作りました。

https://connpass.com/event/350972/


## 簡単な自己紹介
自分は普段UX/UIデザイナーとし活動しており、今年からReactの勉強を開始しました。今回は２回目のハッカソンの参加になります

https://qiita.com/kikotkk/items/b702b6c3a227690eeec6


## 何を作ったか

私たちのチームはまず最初にブレストを行い、天気APIの情報をもとに「犬の散歩ができるかどうか」を判定するアプリを開発することになりました。

## 使ったもの

* 犬のAPI
* 天気のAPI
* 開発環境：React + Vite + Chakra UI v2

https://qiita.com/kitao6/private/1d6bc8f48dfd262635f8

## チーム分担と自分の役割

![a.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3977506/54eb9025-6022-4275-a746-6017354e23e2.png)



まず、チーム全体で役割を分担をしました。
他の方は環境構築やAPIリサーチを行い、私は主にUIの設計と実装に注力しました。
天気に応じて、天気の絵文字と犬のコメントが切り替わる仕様になっています。

![Frame 6247824.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3977506/7a583349-2a96-4981-afd9-0e12d635e4da.png)

## よかったところ

3時間という短い制限時間の中で、チーム全員が優先順位をしっかりと認識し、"must"と"nice to have"を明確に分けて進められたことがとても良かったです。また、状況に応じて柔軟にタスクの損切りを判断できた点も、スムーズな進行に繋がりました。


## 改善の余地があったところ
チームでコーディングをする際、やはりみんなで一つのコードをゴリゴリ書くのは限界があるな、と感じました。Vs codeのLiveshareで一人の方の開発環境に他のメンバーも乗り込んで書いていく....と言うのは多少無理があったかもしれません。

またChakra UIのv3をインストールするとバグが発生し、その調査と対応に約45分程度を要してしまいました。色々なアクシデントがありましたが、エラーに対して全員で解決を目指して知恵を絞れたことは良い経験でした。

この件に関してはこの記事が参考になりました。

https://qiita.com/masa_code/items/ac1a9923ffbb0e616c28


## 感想

短時間でチーム開発を経験できたことで、技術面以外にもたくさんの学びがありました。
独り善がりにならず、初対面のチームで**作り切ることを目標に3時間がっつり集中力が持続できた経験**は個人開発等では実現できないことだと思います。

次回はより実装力を上げて環境構築もリードできるようにしたいです。