OmniAICreator/Qiita-1.07M huggingface dataset:
【Python初心者】よく使うPythonコマンドまとめ（-i, -m, -c など）

Pythonの勉強を進める中で、「スクリプトをどうやって実行するのか」や「コマンドラインオプションにはどんなものがあるのか」について気になったことがありました。

ここでは、自分の学習記録として、Pythonのコマンドに関する基本的な使い方をまとめておきます。実際にターミナルなどで使ってみることで理解が深まるかもしれません。

## Pythonコマンドの基本

Pythonスクリプトは以下のように実行するのが基本です。

```bash
python ファイル名.py
```

ここにオプションを加えることで、さまざまな便利な使い方ができます。

## よく使うオプションの解説

### `-i`：スクリプト実行後に対話モードに入る

```bash
python -i example.py
```

スクリプトを実行し、その後に対話モード（インタラクティブシェル）に入ります。スクリプト内で定義された変数や関数をそのまま使って操作を続けたいときに便利です。

### `-m`：モジュールをスクリプトのように実行する

```bash
python -m http.server
```

`http.server` のようなモジュールをコマンドラインから直接実行できます。標準モジュールだけでなく、インストール済みのモジュールにも使えます。

### `-c`：1行だけPythonコードを実行する

```bash
python -c "print('Hello, world!')"
```

ちょっとした処理を1行で試したいときに便利です。スクリプトファイルを作成せずに動作を確認できます。

### `--version` または `-V`：Pythonのバージョンを確認する

```bash
python --version
# または
python -V
```

現在使っているPythonのバージョンを確認できます。

## 補足：sys.argv で引数を受け取る

次のようなスクリプトを作っておくと、コマンドライン引数がどのように渡されるかを確認できます。

```python
# example.py
import sys

print(sys.argv)
```

このファイルを実行すると、渡された引数がリストとして出力されます。

### 実行例1（引数なし）：

```bash
python example.py
```

出力：
```python
['example.py']
```

### 実行例2（引数あり）：

```bash
python example.py apple banana 123
```

出力：
```python
['example.py', 'apple', 'banana', '123']
```

引数はすべて文字列として受け取られます。たとえば `"123"` も数値ではなく文字列です。

## 補足：シバン（shebang）でスクリプトを直接実行する

Pythonファイルの先頭に「シバン（shebang）」と呼ばれる1行を加えると、スクリプトを直接実行できるようになります。

たとえば `example.py` の中身を次のように書きます：

```python
# example.py
#!/usr/bin/env python3
print("Hello, world!")
```

このファイルに対して実行権限を与えると、以下のようにコマンドとして直接実行できます。

```bash
chmod +x example.py
./example.py
```

これにより、`python example.py` と打たずにスクリプトそのものを実行できるようになります。

macOSやLinuxではこの形式がよく使われますが、Windowsではあまり一般的ではありません。

## おわりに
Pythonのコマンドはつい忘れがちですが、しっかり覚えておくことでPythonをより便利に使えるようになると感じました。
もしまだ使ったことがないコマンドがあれば、ぜひターミナルで試してみてください。
CloudWatch Logsタイプ

AWS CloudWatch の「低頻度アクセス（Infrequent Access）」と「スタンダード（Standard）」は、ログデータの保存クラス（ログの保存先）の種類に関するものです。それぞれ、**保存コストとアクセス頻度**に応じて使い分けられます。

---

### ✅ 違いの比較表

| 項目            | スタンダード（Standard） | 低頻度アクセス（Infrequent Access） |
| ------------- | ---------------- | -------------------------- |
| **用途**        | 頻繁にログにアクセスする場合   | ほとんどアクセスしない古いログ            |
| **保存コスト**     | 高い（通常料金）         | 安い（約50%コスト削減）              |
| **取り出しコスト**   | 無料               | 有料（アクセス時に課金）               |
| **アクセス頻度の目安** | 毎日〜週1程度          | 月1回以下                      |
| **保存期間の目安**   | 最近のログなど          | 古いが残しておきたいログ               |
| **移行方法**      | デフォルトで保存される      | 明示的に移行が必要（自動移行も可）          |


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

* **直近のトラブル対応用ログ** → スタンダードで保持
* **監査用に1年以上残すが見ないログ** → 低頻度アクセスに移行してコスト削減
Bitbucket Pipelineで使用されているOSはAmazon Linuxです。だからyumを使おう

# 結論
- Bitbucket Pipelineで使用されているOSはAmazon Linux
- パッケージのインストールにはyumを使う

# 背景
業務で[Bitbucket Pipeline](https://support.atlassian.com/ja/bitbucket-cloud/docs/get-started-with-bitbucket-pipelines/) を用いてデプロイする際に必要なパッケージのインストールでこけました。（aptを使ってパッケージのインストールを行いました）

# 解決
原因をいろいろと考えそもそもOSは何なのかを調べることにしました。そうするとAmazon Linuxを使用していたことがわかりました。Amazon Linuxはyumを使ってパッケージをインストールすることを知っていたので、yumでインストールしたところうまくいきました。

(参考）OSを調べるコマンド
```
cat /etc/os-release
```
OACの新しいビジュアライゼーション、ゲージでの視覚化

# はじめに
2025年3月の更新で、OAC（**Oracle Analytics Cloud**）に新しいビジュアライゼーション・タイプが追加されました。
ゲージ・ビジュアライゼーションです。
早速紹介します。

# データの準備
こんな簡単なデータをExcelで用意しました。

|製品|在庫数|下限値|上限値|
|:-:|:-:|:-:|:-:|
|A|140|150|170|
|B|102|90|100|
|C|30|28|33|

# ビジュアライゼーションの作成
サンプルデータをデータセットとしてアップロードします。
新しいワークブックを作成し、登録したデータセットを選択します。

Ctrlキーを押しながら列を全部選択して、右クリックします。
「ビジュアライゼーションの選択」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/99e3246a-93ed-4ac1-a64c-2c36996f3d11.png)

ゲージをクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/3c34233c-2b42-4099-a211-9cba3217b70e.png)

トレリス列に「製品」、値（ゲージ）に「在庫数」、値（ターゲット）に「下限値」と「上限値」を配置します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/ea253d51-281d-4e7f-a39a-f77b0ed6e121.png)

製品ごとの在庫数が、下限値と上限値の間に収まっているかを確認するためのビジュアライゼーションが作成できました。

# 条件付き書式でカスタマイズ
せっかくなので、少しカスタマイズしてみます。

ゲージ・ビジュアライゼーションの「条件付き書式ルールの管理」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/71a83849-ef4b-4a23-9ba4-6b3ca1315b50.png)

対象となる列を「在庫数」とします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/d8092a3f-9c04-4b19-803e-6b5dd7f5607c.png)

「在庫数」が「下限値」を下回った時の色を指定します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/446ad85f-b82a-4c95-8f30-f297ae3d8e9e.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/38f2183f-238e-4cee-ac05-a1cab96d315a.png)

同様に「在庫数」が「上限値」を上回った時の色も指定します。
同じ色にしました。「保存」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/77abd204-1f5d-412b-8cf9-f7f76648a96c.png)

製品AとBは、在庫数が適正在庫の範囲から外れているので赤く表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/246ab4ba-dfa0-4e9b-a2fa-426c3a42c04c.png)

# その他のゲージ・ビジュアライゼーションの使い所

## 業績評価
例えば、販売目標の達成率を示す際に、ゲージを使用すると進捗状況を直感的に把握できます。ゲージチャートで月ごとの売上目標に対する達成度を色分けで表示することで、チームがどの程度目標に近づいているか一目で分かります。

## KPIモニタリング
企業の重要業績評価指標（KPI）の監視に使用できます。例えば、ウェブサイトのトラフィック量や顧客満足度スコアなどをリアルタイムで監視し、設定された目標範囲に対する現在の値をゲージで示すことで、問題の発見や迅速な対応を容易にします。

## エネルギー消費のモニタリング
工場やオフィスビルのエネルギー使用量を測定する際に、ゲージは現在の消費量が設定されたターゲット範囲内に収まっているかを示すのに有効です。これにより、効率的なエネルギー管理が可能になります。

## プロジェクト進捗管理
チームプロジェクトで、タスクの進捗状況を可視化するためにゲージを使います。全体の完了率や、個別のマイルストーン達成率を一目で確認することができます。
テストコードによる単体テストの自動化

# はじめに単体テストについてのおさらい
ソフトウェアの最小単位（関数やメソッド、クラスなど）の部品単体で、詳細設計書通りにその部品が正しく動作しているかどうかを確認するテストです。その部品に対する入力値と期待結果を定義しておき、正しい結果が返ってくるか、または、期待通りにエラーが発生するか、また、部品の中にDB操作があれば、DBへの保存処理が正常にできているか、DBからデータを取得できているか、それらのデータが正しいか等も確認します。

単体テストについての詳しい説明やテスト技法は、こちらの記事をご参照ください。↓
https://qiita.com/h_nakahata_361/items/7eedc1d788c99e98f717

# テストコードとは？
主に単体テストを対象に使われることが多いもので、コンポーネントが詳細設計書通りに機能するかどうかを自動で確認するプログラムです。例えばMVC(Serviceクラス含む)フレームワークであれば、このフレームを構成する、

・View：画面の見た目、入出力担当
・Controller：リクエストの受け取り、検証、出力の返却
・Service：ビジネスロジック
・Model：データ構造の定義、DBの操作

のようなものをコンポーネントと呼びます。
このうち、View以外のようなバックエンドに位置するコンポーネントのメソッド単位でテストをしていきます。ちなみに、この中で、一番テストの優先順位が高いのは、ビジネスロジックを実装しているServiceです。

# テストコードのコードの構成
テストコードの構成は三つあり、Arrange（準備)、Act（実行）、Assert（検証）から構成されます。
今回は、C#のXUnitを用いて説明していきたいと思います。

```csharp
//実際のテストコードの構成（DB関連は省力）
public class ProductServiceTests
{
    [Fact]
    public void CalculateTotalPrice_ReturnsCorrectTotal()
    {
        // Arrange（準備）
        var product = new Product { Price = 1000, TaxRate = 10 };
        var service = new ProductService();

        // Act（実行）
        var result = service.CalculateTotalPrice(product);

        // Assert（検証）
        Assert.Empty(result.Error);//エラーが無いことの確認
        Assert.Equal(1100, result.Money); // 1000 + 10% = 1100
    }
}
```

## Arrange（準備）
ここでは、主にテストデータの作成を実施していきます。

#### まず、テストデータとは？
テストデータとは、プログラム(メソッド等)に渡す入力値、テストの期待値、DB操作が関連する場合、DBに事前にINSERTするテスト用のデータのことを指します。

※DB操作が関連するときは、対象のDBの中身を全てDELETEしてから、テスト用のデータをDBにINSERTすることが多いです。また、テストクラスの後処理で、DBの状態はロールバックできるので、開発用の環境を汚すことなくテストできますのでご安心を。

## Act（実行）
ここでは、Arrangeで準備した入力値をテスト対象のプログラム（メソッド等）に渡して、プログラムを実行します。
実行結果を受け取った変数は、次のフェーズで、検証に使います。

## Assert（検証）
文字通り、プログラム（メソッド等）の実行結果を検証します。
検証は、以下の順番で行うのが好ましいでしょう。

#### 1.正常系、異常系の確認
正常系を想定しているのであれば、まずは、エラー情報が無いことの確認をします。（逆に異常系の想定ならば、エラーメッセージが発生していることと、メッセージが正しいかを確認します。）

#### 2.期待値と実行結果の比較
Arrangeで準備した期待値とプログラム（メソッド等）の実行結果の値が等しいことを確認します。また、DB操作が絡んでくるときは、以下のような確認も必要です。

登録系：「Arrangeで準備したプログラム（メソッド等）への入力値」がDBに欠損なく登録されていること

更新・削除系：「Arrangeで準備したプログラム（メソッド等）への入力値」に紐づくDB内のレコードが更新・削除されていること

検索・参照系：「ArrangeでDBにINSERTしたデータ」が実行結果として正しい形式で出力されていること

# 導入により、期待できる効果
### アプリケーションが起動可能になるまで待たずにテストできる
アプリケーション全体（WebサーバやDB、画面など）が立ち上がる前でも、個々のクラスやメソッドはテスト可能です。

### 関連するコンポーネントの実装が終わっていなくてもテストができる。
依存している他のモジュールが未実装でも、モック（擬似オブジェクト）を使って仮の動作を再現しながらテストできます。

### プログラム改修時の回帰テストの作業時間が短縮できる。
プログラムを改修・追加したあとに、既存の機能が壊れていないかを確認するテストを回帰テストと言います。
手動テストの場合と自動テストの場合の比較をしながら説明をしていきます。

#### 手動テストの場合
手動テストの場合は、バグ修正をした後に、画面を開いて、ボタンをクリックして、結果が正しいか人間が目視確認することになります。それが、数十画面、数百パターンあると、毎回全部試すのは時間がかかり、漏れも出やすくなります。

#### テストコードの場合
「修正前のコードがどう動くべきか」がテストコードとして残っている状態です。修正後に dotnet test などでワンクリック（またはCIが自動実行）すれば、数百のテストケースが数秒〜数分で完了します。
つまり、毎回人間が目確認する必要がなく、作業時間が圧倒的に短くなります。

# まとめ
ここまで、沢山の特性やメリットを説明してきましたが、デメリットとして手動確認のテストと違って、プログラミングの知識が必要なことやテストフレームワークの使い方に慣れるまでに時間がかかることが挙げられます。これにより、単体テストが誰でもできるものではなくなってしまうことから、学習コストがかかってしまい、導入しづらい事情もあるでしょう。しかし、バグの早期発見や回帰テストの自動化により、工数削減を実現し、テストの網羅性が高いことやリファクタリングの安心感から品質担保の向上が見込めることを考えると、これからの開発作業の負荷を軽減し、将来的にエンジニアの心身の健康を守るという意味でも学習するべきだと思っています。そのためにも、会社から指示をもらってスキルを磨くのではなく、各々で時間を見つけて、自主的に学習・提案をすることが重要になってくると思います。
AWS Auto Scaling ターミネーションポリシー

AWS Auto Scalingの**ターミネーションポリシーTermination Policy**は、スケーリングイン（インスタンスの削減）が必要になったときに、**どのインスタンスを終了させるかを決定するルール**です。これをうまく設定することで、不要なコストやサービス停止のリスクを抑えられます。

---

### ✅ 主要なターミネーションポリシー

Auto Scalingは以下の順番でポリシーを評価します（複数指定可）：

1. **OldestInstance**
   → 最も古いインスタンスから終了。Blue/Greenデプロイ後の旧インスタンスの削除などに有効。

2. **NewestInstance**
   → 最も新しいインスタンスを終了。テスト目的で新規起動したインスタンスを優先的に削除したいときなど。

3. **OldestLaunchConfiguration**
   → 最も古いLaunch Configurationを使用しているインスタンスを終了。Launch Configの切り替え後の整理などに。

4. **ClosestToNextInstanceHour**
   → 次の請求時間に最も近いインスタンスを終了。時間単位の料金が適用されるインスタンスタイプに有効。

5. **Default（AZバランス）**
   → 各アベイラビリティゾーンのバランスを維持しつつ、ランダムで選択される。

6. **OldestLaunchTemplate**
   → 最も古いLaunch Template（バージョン）を使っているインスタンスを終了。

7. **AllocationStrategy**（スポットFleet用）
   → スポットインスタンス使用時の割当戦略。

---

### 🎯 ポリシーの設定場所

Auto Scalingグループの作成または変更時に、CLI／コンソール／CloudFormationなどから以下のように設定します：

#### 例（AWS CLI）:

```bash
aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name my-asg \
  --termination-policies "OldestInstance" "ClosestToNextInstanceHour"
```

---

### 💡補足

* 複数ポリシーを設定した場合は、**上から順に評価**され、条件に合致するインスタンスが対象になります。
* ターミネーションポリシーは**スケーリングイン時のみ有効**です（スケーリングアウト＝インスタンスの追加時には関係しません）。
Cloudfront max-ageディレクティブ

`Cache-Control: max-age` ディレクティブは、CloudFront や ブラウザなどのキャッシュ機構に対してこのコンテンツは何秒間キャッシュしてよいかを指示する HTTP ヘッダーです。

---

### ✅ `max-age` の基本

```http
Cache-Control: max-age=3600
```

これは、「**このレスポンスは、取得後3600秒（=1時間）までは再取得せずキャッシュを使ってよい**」という意味です。

---

### ✅ CloudFront との関係

CloudFront はオリジンからのレスポンスに `Cache-Control` ヘッダーが含まれている場合、以下のように動作します：

| ヘッダー設定                     | CloudFrontのキャッシュ動作       |
| -------------------------- | ------------------------ |
| `Cache-Control: max-age=N` | N秒間、CloudFrontでキャッシュ     |
| `Cache-Control: no-cache`  | キャッシュはするが、毎回オリジンに検証      |
| `Cache-Control: no-store`  | キャッシュしない                 |
| `Cache-Control: public`    | 共有キャッシュ（CloudFront含む）を許可 |
| `Cache-Control: private`   | ブラウザなどのユーザー専用キャッシュのみ     |

---

### ✅ 使用例：長めのキャッシュ設定

```http
Cache-Control: public, max-age=86400
```

* すべての中継キャッシュ（CloudFront含む）が 1日（86400秒）キャッシュ可能。

---

### ✅ CloudFront キャッシュ期間の優先順位

CloudFront がオブジェクトをどれくらいキャッシュするかを判断する優先度：

1. オリジンの `Cache-Control: max-age`
2. オリジンの `Expires` ヘッダー（`max-age` より優先度は低い）
3. ディストリビューションの**キャッシュポリシー設定**（明示的に上書き可能）

---

### ✅ CloudFront キャッシュポリシーで上書きする場合

CloudFront 側でオリジンのヘッダーを無視して `max-age` を上書きするには、**キャッシュポリシーで TTL を設定**します：

* 最小 TTL（Minimum TTL）
* 最大 TTL（Maximum TTL）
* デフォルト TTL（Default TTL）

例：デフォルトで 1 時間キャッシュし、最長でも 1 日キャッシュ

```plaintext
Default TTL: 3600
Min TTL: 0
Max TTL: 86400
```

---

### ✅ 補足：更新頻度に応じた設定

* 静的ファイル（画像、CSS、JS など）：`max-age=31536000`（1年）＋バージョニング（`?v=2`など）
* 動的コンテンツや頻繁に変わるAPIレスポンス：`max-age=0, no-cache` などで都度取得
Type-C一本で！ラズパイと自作液晶を同時駆動してみた

# CH224KでUSB-C PDから5Vと12Vを取り出した話

PD対応のUSB充電器から、5Vと12Vを同時に取りたかった。  
Raspberry Pi3と液晶をAnkerの65WPD充電器から1本のType-Cケーブルで動かしたかった。  
CH224Kでそれっぽい回路を組んだ。案外うまくいった。

---

## 完成図（まずは見てくれ）

実物の写真はこちら。全部入りで動くやつ。


![1000003150.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/142016/b7d3cbe7-1dc5-4653-959d-144d489d49b0.jpeg)

写真だと配線の雑多感があるが、type-cケーブル1本で液晶コントローラとラズパイ3に電力が供給されている。



---

## なぜ作ったか

液晶ディスプレイを自作した。Raspberry Piも載せた。  
動いた。嬉しかった。が、電源ケーブルが2本になった。  
配線がゴチャゴチャした。コネクタも種類が違った。  
「これって、もうちょっとスマートにできるんじゃ？」と思った。  
Type-CのPDで1本化しよう。ついでに出力も分けよう。  
そう思った。

---

## やりたいこと

- PD充電器から15Vをもらう  
- 15Vから5V（Raspberry Pi用）を作る  
- 15Vから12V（液晶用）も作る  
- 電源ケーブルを1本にまとめたい  
- 出力電圧をArduinoで監視したい

※自分が使うAnkerの充電器には12Vの出力に対応していないため、15Vを出力するようにした。

---

## 構成概要

この回路はArduinoのシールドとして作った。  
Arduinoには、出力された5Vと12Vの電圧をモニタリングさせている。  
アナログピンで電圧を読むには分圧が必要なので、1kΩの抵抗を4本使って20Vまで測れるようにした。

### 全体構成図

![.trashed-1749685151-Arduino-S_cir~2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/142016/e22b54bf-4cae-4b4b-aede-ce212a4185b4.png)

---

## 分圧回路の構成

1kΩの抵抗を4本直列にして、Vinの1/4の電圧をA0ピンで読む。

この構成だと、A0ピンにはVin × (1/4)の電圧がかかる。  
Arduinoが5Vまで測れるなら、Vinは最大で5V × 4 = 20Vまで対応できる。

## Arduinoでの電圧読み取りコード

```cpp
int raw = analogRead(A0);
float ref_voltage = 5.08;  // 実測したArduinoの5Vピンの電圧
float vin = raw * (ref_voltage / 1023.0) * 4.0;
```
ArduinoのanalogRead()は0〜1023の値を返す。
USB給電では5Vピンが必ずしも5.00Vとは限らないので、テスターで測った実測値を使うのがコツ。筆者のテスタでの計測では5.08Ｖだったのでそれをソースコードに反映した。


---

## 使ったもの

- **CH224K**  
  PDデコイと呼ばれるやつ。Type-Cの相手に「15Vちょうだい」とお願いする。  
  素直にくれる。いいやつ。  
  **ただし、VDDとGNDの間に0.1μFのセラミックコンデンサが必須。**  
  これがないと動かない。

- **LM2596（×2）**  
  降圧モジュール。15Vを5Vと12Vにそれぞれ落とす。  
  最大3A流せるので安心。Amazonでだいたい5個セット売りされてるあれ。

- **1kΩ抵抗（×4）**  
  分圧用。20Vまでのアナログ測定を可能にする。各電圧（5V,12V,15V）の計測用に3セット準備。スルーホール用の抵抗がたくさん余ってたので、１kオーム抵抗をたくさん使うようにした。

---

## 実装したもの

- 基板でシールド化した。Arduino Unoの上にガチャっと載せられる。
- **左中央**にCH224KとType-Cポート  
- **中央**に2つのLM2596  
- **右側**に各電圧の出力ポート
![1000003139.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/142016/e9a68a1f-0e15-4a30-b305-8dc2db3ddb31.jpeg)

---

## 注意点（絶対読んで）

- **CH224Kはコンデンサ必須**  
  VDDとGNDの間に**0.1μFのセラミックコンデンサ**を入れないと、PDの電圧交渉が始まらない。  
  入れ忘れると「ん？動かないな？」ってなる。筆者はなった。

- **PD充電器は15V出せるか確認**  
  たまに9V止まりのやつもある。CH224Kが頑張っても、相手が対応してないと無理。

- **プリント基板の配線幅に注意**  
  今回の基板は**1mm幅で設計**したけど、ラズパイ3をフル負荷で動かすにはちょっと細いかも。  
  実験用にはOK、本番用途には**2mm以上**や**ベタGND**を検討したい。
【Next.js】webpack.cache.PackFileCacheStrategy の警告が出るときの対処法

# はじめに
Next.js を使って開発していると、`npm run dev` 実行時に以下のような警告が大量に表示されることがあります。

```
<w> [webpack.cache.PackFileCacheStrategy] Serializing big strings (100kiB) impacts deserialization performance (consider using Buffer instead and decode when needed)
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/318188/ad99d45e-e791-4bb4-a364-303e75716579.png)

この記事では、この警告の原因と対処法を記載します。

# 結論
`next.config.js` または `next.config.mjs` に `optimizePackageImports` を追加することで、パッケージのバンドルサイズを抑え、警告を抑制できます。

```js
// next.config.mjs
export default {
  experimental: {
    optimizePackageImports: ['@mantine/core', '@mantine/hooks'],
  },
};
```

今回のようにコンポーネントライブラリを使っている場合は特に効果的です。

# 発生環境

* OS: Windows 11
* VSCode
* Next.js 15.3.2
* Mantine 7.15.3
* Node.js 22.13.1
* npm 11.0.0

# 警告の詳細と原因

この警告は Webpack の `PackFileCacheStrategy` によるものです。

開発時に Webpack がキャッシュを高速化するために使用するシリアライズ処理で、100KB 以上の長い文字列を扱うと、逆に復元（デシリアライズ）時のパフォーマンス低下の可能性があります。

```
Serializing big strings (100kiB) impacts deserialization performance
```

ライブラリが未最適化の状態で大量のコードを含んでいるとき、特に発生しやすいです。

# 対処法

## 1. Mantine の最適化設定を追加する
Mantine はツリーシェイキングに対応していますが、Next.js に `optimizePackageImports` を指定しないと、不要なコードも読み込まれてしまう可能性があります。

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

以下のように設定します。

```next.config.mjs
export default {
  experimental: {
    optimizePackageImports: ['@mantine/core', '@mantine/hooks'],
  },
};
```

これにより、使用しているコンポーネントのみがバンドルに含まれ、警告の発生が抑えられます。

:::note
Chakra UI など他のコンポーネントライブラリでも同様の最適化が可能です。
:::

## 2. キャッシュと依存関係の再構築

警告が出続ける場合は、一度キャッシュと依存関係をリセットしてみてください。

```bash
rm -rf .next node_modules
npm install
npm run dev
```

## 3. パッケージのアップデート

Next.js、Mantine、Webpack のバージョンが古いと、最適化されないことがあります。

```bash
npm outdated
npm update
```


# 警告を放置してもいいの？

この警告は「致命的なエラー」ではなく、あくまで「開発体験のパフォーマンス低下」の注意喚起です。

ただし、警告が大量に出ている状態では、以下のような不都合を引き起こす可能性があります。

* `npm run dev` の起動が遅くなる
* ホットリロードが重くなる
* 開発中の UI のレスポンスが悪くなる

そのため、なるべく早めに対処するのがおすすめです。


# まとめ

Next.js での開発中に `webpack.cache.PackFileCacheStrategy` の警告が出る場合、以下を試してみましょう。

* `optimizePackageImports` を `next.config.mjs` に追加
* `.next` ディレクトリと `node_modules` を削除して再インストール
* パッケージをアップデート

警告の意味を理解し、適切に対処することで、より快適な開発環境を整えることができます。

## 参考
* [How to debug "[webpack.cache.PackFileCacheStrategy] Serializing big strings" in NextJS?](https://stackoverflow.com/questions/78471919/how-to-debug-webpack-cache-packfilecachestrategy-serializing-big-strings-in)
* [optimizePackageImports](https://nextjs.org/docs/app/api-reference/config/next-config-js/optimizePackageImports)
* [Using Chakra UI in Next.js (App)](https://chakra-ui.com/docs/get-started/frameworks/next-app)
WidgetTester.viewでゴールデンファイルのディスプレイサイズを変更する

ゴールデンファイル、ゴールデンテストが何かについては省略。

参考記事

- [Golden Testを導入してUI開発の不安を解消する](https://zenn.dev/taisei_dev/articles/f88b46aad05dba)
- [Flutterで始めるGoldenTest](https://qiita.com/beeytnh/items/3051f3e6237fc3269ed2)
- [Flutterのアプリにゴールデンテストを導入]()

# 課題

- [matchesGoldenFile](https://api.flutter.dev/flutter/flutter_test/matchesGoldenFile.html)呼び出し時に取得できる画像のサイズがデフォルトで`800 X 600`になっている
  - モバイルアプリの画面表示結果（横持ちを想定したアプリで限りは縦長のスクリーンに表示される）の確認をしたいのに、ゴールデンファイルが横長
  - **ゴールデンファイルを縦長のサイズにしたい**
- Flutterのゴールデンテストについて書かれた記事では[golden_toolkit](https://pub.dev/packages/golden_toolkit)を紹介することが多い
  - これを使えば縦長のスクリーンに表示されたときのゴールデンファイルを簡単に取得できるが、このライブラリは開発が止まっている（2025/5/13現在）ため使いたくない
  - [alchemist](https://pub.dev/packages/alchemist)というのもあるらしいが見なかったことにする（ただの怠惰）
    - こっち使うほうが色々細かく設定できてよさそう

# 解決方法

[WidgetTester.view.physicalSize](https://api.flutter.dev/flutter/flutter_test/TestFlutterView/physicalSize.html)にファイルのサイズを設定する。

```dart
import 'package:flutter_test/flutter_test.dart';

void main() {
  testWidgets('test golden', (tester) {
    // ゴールデンファイルのサイズを指定
    final imageSize = Size(320 /* width */, 600 /* height */);
    tester.view.physicalSize = imageSize * tester.view.devicePixelRatio;

    // Widget作成
    await tester.pumpWidget(WidgetToTest());

    // ゴールデンファイルと比較
    // 320 X 600 サイズの画像と比較できる
    await expectLater(
      find.byType(WidgetToTest),
      matchesGoldenFile('golden_file_name.png'),
    );
  }
}
```
Automating GIS Processes 2024 写経　Lesson 2 （Overview、Key concepts）


今回はオンハンズなしです。

# Overview

https://autogis-site.readthedocs.io/en/latest/lessons/lesson-2/overview.html

> In this lesson, we will learn how to handle spatial data in Python using Geopandas. Geopandas combines the power of Pandas to analyse tabular data and shapely for handling geometries.
> We will learn how to read and write spatial data from and to files, how to manipulate geometries, and how to transform data between different coordinate reference systems (CRS).

Geopandas を使って Python で空間データを扱う方法を学びます。

http://geopandas.org/

ファイル経由で空間データを読み書きする方法、ジオメトリを操作する方法、異なる座標参照系 (CRS) 間でデータを変換する方法を学びます。

## Learning goals

> - read and write spatial data from and to common file formats,
> - filter and re-group data by spatial and non-spatial characteristics, and
> - manage and transform a data set’s coordinate reference system.

- 一般的なファイルフォーマットで空間データを読み書きします
- データをフィルタしたり、再グループ化します
- データの座標参照系を変換します


# Key concepts

https://autogis-site.readthedocs.io/en/latest/lessons/lesson-2/key-concepts.html

> Check your understanding
Before diving into this week’s Python lesson, you should already be familiar with some basic spatial data file formats and projection definitions, such as these:

ハンズオンを始める前に、空間データフォーマットや座標参照系の基本を理解しておく必要があります。

**原文の翻訳よりも日本語のサイトのほうがわかりやすいと思いますので、関連するサイトのリンクのみとします。**

- Shapefile

https://www.zenrin.co.jp/product/article/Shapefile-benefits/index.html#:~:text=Shapefile%E3%81%A8%E3%81%AF%E3%80%81GIS%E3%83%87%E3%83%BC%E3%82%BF,%E7%A9%BA%E9%96%93%E8%A6%81%E7%B4%A0%E3%82%92%E7%A4%BA%E3%81%97%E3%81%BE%E3%81%99%E3%80%82

> Shapefileとは、GISデータのフォーマットのひとつで、GISソフトで扱えるベクター形式のデータです。特定の建物を点で示す「ポイント」、河川や道路を線で表す「ライン」、湖沼や森林などを面で表す「ポリゴン」などの形で地図上の空間要素を示します。

- GeoPackage

https://qgis.mierune.co.jp/posts/howto_1_about_geopackage

> 「GeoPackage（GPKG）」とは、地理空間データを保存するためのデータ形式の1つで、データベース管理システムのSQLiteをベースとしています。これは、OGC（Open Geospatial Consortium）が策定した標準規格のデータ形式であり、GISや地理データの取り扱いに特化した多機能なフォーマットです。


- CRS

https://sinrintech.com/knowledge/gis/crs/

> 座標参照系（CRS）とは、Coordinate Reference Systemの略語で、緯度や経度をはじめ、球体である地球上の位置を平面に投影する方法を意味する概念です。
> CRSは、以下の2つの組み合わせによって構成されています。
> - 測地系：地球上を楕円形にとらえた上で、地球上の位置と経緯度を対応させる基準のことです。
> - 座標系：数値による位置の表し方を指します。経度と緯度で表現される地理座標系と、それ以外の方法（球体を平面に変換するなど）の方法で表現される投影座標系の2種類が存在します。

- datum

https://pen.envr.tsukuba.ac.jp/~torarimon/?%C2%AC%C3%CF%B7%CF%3A+datum#:~:text=%E6%B8%AC%E5%9C%B0%E7%B3%BB%20(datum)%E3%81%A8%E3%81%AF,%E5%80%A4%E3%81%8C%E3%81%82%E3%82%8A%E3%81%88%E3%82%8B%E3%81%AE%E3%81%A7%E3%81%82%E3%82%8B%E3%80%82

> 　測地系 (datum)とは、ひらたくいえば、地表の地点と座標(緯度，経度)の対応のことである．多くの人は、この対応は一意的なものと思っているだろうが、実はそうではない。つまり、ある地点の位置を表すのに、様々な緯度・経度の値がありえるのである。

- EPSG

https://club.informatix.co.jp/?p=1225#:~:text=EPSG%E3%82%B3%E3%83%BC%E3%83%89%E3%81%A8%E3%81%AF%E3%80%81GIS,%E6%8A%95%E5%BD%B1%E6%B3%95%E3%81%AA%E3%81%A9%E3%81%8C%E3%81%82%E3%82%8A%E3%81%BE%E3%81%99%E3%80%82

> EPSGコードとは、GISで使用される様々な要素に必要なパラメータを1つにまとめ、そのパラメータの集合体どうしを区別するためにコードを割り振ったコード体系のことです。
> GISで使用される要素には、座標参照系、測地系、本初子午線、地図投影法などがあります。
> EPSG（European Petroleum Survey Group）という団体によって作成され、現在ではいろいろなGISで使用されています。

次回からハンズオンです。
配下のディレクトリとファイル構成を階層的に表示してくれるコマンド Tree

## Tree
```
tree
```

配下のディレクトリとファイル構成を階層的に表示してくれるコマンドです。

## 例
```
$ tree
.
├── README.md
├── lib
│   ├── main.dart
│   └── feature
│       └── todo
│           └── presentation
└── pubspec.yaml
```

## コマンドが入っていない場合(mac)
`brew install tree`

## よく使うオプション
- tree -L 2 → 階層を2階層までに制限

- tree -a → .gitignoreされてるような隠しファイルも表示

- tree -I "build|.git" → 特定のディレクトリを除外して表示
S3のリクエスト支払い

AWS S3のリクエスト支払い（Requester Pays）は、S3バケットの所有者ではなく、**バケットにアクセスするユーザー（リクエスター）に対して、データリクエストやデータ転送料金の支払い責任を課す機能**です。

---

### ✅ 特徴

* デフォルトでは、**バケットの所有者がすべてのコストを支払います**。
* 「リクエスト支払い」を有効にすると：

  * **データ取得（GET、HEADなど）の料金をアクセスユーザーが支払う**
  * **データ転送コスト（アウトバウンド）もアクセスユーザーが負担**
* **ストレージ料金はバケット所有者が引き続き支払う**

---

### ✅ ユースケース

* 公開データセット（例：地理データや天文データなど）を多数のユーザーが使うときに、**アクセスコストを分担させたい**場合。
* 特定の外部パートナーやサービスにデータを提供するが、**転送料金を請求したくない**とき。

---

### ✅ 有効化方法（バケットオーナー側）

```bash
aws s3api put-bucket-request-payment \
  --bucket バケット名 \
  --request-payment-configuration Payer=Requester
```

---

### ✅ アクセスする際の注意点（リクエスター側）

リクエスターは、**明示的に `--request-payer requester` を付ける必要があります**。

```bash
aws s3 cp s3://バケット名/ファイル名 ローカルファイル名 \
  --request-payer requester
```

---

### ✅ 補足

* アクセス側がこのオプションを指定しないと、「403 Access Denied」になります。
* S3 バケットポリシーで、リクエスターに対するアクセス権限（`s3:GetObject` など）を明示的に許可しておく必要があります。
CloudFront 署名つきCookie/URL

CloudFront における「署名つきCookie（Signed Cookies）」と「署名つきURL（Signed URL）」は、**限定されたユーザーのみに特定のコンテンツ（例：動画、画像、PDFなど）を配信するためのアクセス制御方法**ですが、用途や使い勝手に明確な違いがあります。

---

## 🔍 違いの比較表

| 比較項目         | 署名つきURL（Signed URL）      | 署名つきCookie（Signed Cookie）                     |
| ------------ | ------------------------ | --------------------------------------------- |
| 📦 対象        | **個別のURL単位**で制限          | **複数ファイル/パス単位**で一括制限                          |
| 🧾 配布方法      | URLに署名情報を埋め込む（クエリパラメータ）  | クライアントにCookieとして付与                            |
| 🔄 適しているケース  | 一時的に1つのファイルを渡す場合（例：動画1本） | 同じユーザーに対して複数ファイルをまとめて制限したい場合（例：ログイン後の会員専用ページ） |
| 🔐 認証ロジックの実装 | サーバー側で署名付きURLを生成して配布     | サーバー側でCookieを設定し、以降のリクエストすべてに適用               |
| 👤 対象ユーザー数   | 少人数向けに最適（個別にURLを渡す）      | 多数ユーザーの継続的アクセスに最適                             |
| 🛠 Cookie使用  | なし                       | 必須（Cookieに署名情報を入れる）                           |
| 🌐 URLの見た目   | 長くなる（署名や期限付きクエリが付く）      | 通常のURLのまま見える                                  |

---

## 🔑 共通点

* 両方とも「CloudFrontの署名付きアクセス制御」の一部
* 有効期限、IP制限、ポリシーなどが指定可能
* どちらも CloudFront の **カスタムオリジン／S3オリジン** 両方で利用可能
* 共に「キーグループ」または「カスタム署名キー」で署名を生成・検証

---

## 🧠 選び方の目安

| シナリオ                             | おすすめ         |
| -------------------------------- | ------------ |
| 限定動画の一時配布、ダウンロードリンクなど            | ✅ 署名つきURL    |
| ログインユーザーが複数ページ・ファイルに継続的にアクセスする場合 | ✅ 署名つきCookie |

---

## 🛠️ 補足：構成イメージ

* **署名つきURL**：
  `https://d123.cloudfront.net/video.mp4?Expires=...&Signature=...&Key-Pair-Id=...`

* **署名つきCookie**：

  ```http
  Set-Cookie: CloudFront-Policy=...;
  Set-Cookie: CloudFront-Signature=...;
  Set-Cookie: CloudFront-Key-Pair-Id=...;
  ```

ブラウザにこのCookieを渡すと、**同じドメイン内のファイルすべてに署名制御がかかります**。

---

## ✅ まとめ

| 署名方式       | メリット                   | 向いている用途               |
| ---------- | ---------------------- | --------------------- |
| 署名つきURL    | 手軽に個別ファイル制御、シンプルなリンク配布 | 限定リンク、単一ファイルアクセス      |
| 署名つきCookie | 複数ファイルの一括制御、ユーザー単位の認可  | 会員サイト、複数ファイルを含むWebアプリ |

---
Windows 環境で dig.exe を使用可能にする設定手順


### Windows 環境で `dig.exe` を使用可能にする設定手順

#### 1. BIND ツールのダウンロード
- **目的**: `dig.exe` を含む BIND ツールを公式なソースから取得。
- **操作**:
  - 以下のリンクにアクセス：
    ```
    https://ftp.iij.ad.jp/pub/network/isc/bind/
    ```
  - 最新の `BIND9.xx.xx.x64.zip` ファイルを探す（例: `BIND9.17.14.x64`）。
    - **注意**: `tar.xz` 形式は Windows 向けではないため、必ず `.zip` ファイルをダウンロード。

#### 2. ファイルの解凍と `dig.exe` の確認
- **目的**: ダウンロードした ZIP ファイルを解凍し、`dig.exe` が含まれていることを確認。
- **操作**:
  - ダウンロードした `BIND9.xx.xx.x64.zip` を右クリックし、「すべて展開」（「すべてを展開」）を選択。

  - 解凍したフォルダを開き、`dig.exe` が存在することを確認。
- **補足**:
  - 解凍先は任意ですが、システムドライブ（`C:`）直下や `Program Files` など、アクセスしやすい場所が推奨。

#### 3. コマンドプロンプトで `dig` コマンドの動作確認
- **目的**: `dig.exe` が正しく動作するか、コマンドプロンプトでテスト。
- **操作**:
  - 「コマンドプロンプト」を起動：
  - 解凍したフォルダに移動：
    ```
    cd C:\Tools\BIND
    ```
  - `dig` コマンドをテスト実行：正常に動作すれば、DNS 応答（A レコードなど）が表示される。
    ```
    dig www.google.com
    ```

#### 4. `dig.exe` のパスをシステム環境変数に登録
- **目的**: `dig` コマンドをどのディレクトリからでも実行できるようにする。
- **操作**:
  - **環境変数設定画面を開く**:
    - デスクトップの「このPC」を右クリックし、「プロパティ」（「プロパティ」）を選択。
    - 「システム」画面で「システムの詳細設定」（「高级系统设置」）をクリック。
    - 「システムのプロパティ」ウィンドウで「環境変数」（「环境变量」）をクリック。
  - **Path を編集**:
    - 「システム環境変数」セクションで `Path` を選択し、「編集」（「编辑」）をクリック。
    - 「環境変数の編集」ウィンドウで「新規」（「新建」）をクリック。
    - `dig.exe` があるフォルダのパスを入力（例: `C:\Tools\BIND`）。
    - 「OK」を押してすべてのウィンドウを閉じる。
  - **設定の反映**:
    - 新しいコマンドプロンプトを開き、`dig` を入力して動作確認：
      ```
      dig
      ```
      ヘルプメッセージが表示されれば成功。
Amazon Redshift拡張VPCルーティング（メモ）

「**拡張VPCルーティング（Enhanced VPC Routing）**」は、**Amazon Redshift** に特有の機能で、**Redshiftクラスターからの通信（特にCOPY/UNLOADなどのS3通信）をVPC内ルートに制御する機能**です。

---

## ✅ 拡張VPCルーティングとは？

通常、RedshiftがS3や他のAWSサービスと通信する際、一部のトラフィックは**パブリックインターネットを通ることがあります**。
拡張VPCルーティングを有効にすると、**これらのトラフィックもVPC内（プライベートネットワーク）経由で流れるように強制**されます。

---

## 📌 主な目的とメリット

| 項目                             | 内容                                                           |
| ------------------------------ | ------------------------------------------------------------ |
| 🔐 セキュリティ強化                    | 通信を **NAT Gateway/VPCエンドポイント経由** に限定可能。インターネット非経由でS3などに接続できる |
| 📊 トラフィック制御                    | **VPCのルートテーブル、セキュリティグループ、NACL** のポリシーが適用される                  |
| 📈 ロギング                        | VPC Flow Logs でRedshiftのS3アクセスログを取れるようになる                    |
| ☁️ PrivateLinkやVPC Endpointと併用 | S3やDynamoDBのVPCエンドポイントと組み合わせて、**完全な非公開構成**が可能に               |

---

## 🔧 有効にするタイミングと方法

* Redshiftクラスター作成時に `--enhanced-vpc-routing` オプションをONにする
* 既存クラスターでも変更可能（ただし一時的に停止が発生する）

例（CLI）：

```bash
aws redshift modify-cluster \
  --cluster-identifier my-cluster \
  --enhanced-vpc-routing
```

---

## ⚠️ 注意点

| 項目                              | 内容                              |
| ------------------------------- | ------------------------------- |
| ❌ NAT Gateway または VPCエンドポイントが必要 | Privateサブネットではインターネットに出られないので注意 |
| ❌ 必ずS3アクセスが成功するとは限らない           | 正しいルート設定とIAMロールが必要              |
| ❗ UNLOAD/COPYが失敗しやすくなることも       | 特にVPC Endpoint設定ミス時にエラーになりやすい   |

---

## ✅ まとめ

| 特徴   | 内容                                  |
| ---- | ----------------------------------- |
| サービス | Amazon Redshift                     |
| 機能名  | 拡張VPCルーティング（Enhanced VPC Routing）   |
| 目的   | RedshiftのS3通信などをVPC内経由に限定           |
| メリット | セキュリティ強化・通信制御の向上・監査性アップ             |
| 要件   | 適切なルート・NAT Gateway・VPCエンドポイント・IAM設定 |

---
AWS RDS拡張モニタリングメモ

AWS RDS（Relational Database Service）の**拡張モニタリング（Enhanced Monitoring）**とは、RDSインスタンスの**OSレベルのメトリクスをリアルタイムに収集・表示する機能**です。通常のCloudWatchモニタリングよりも詳細かつ高頻度の情報が得られます。

---

## ✅ 主な特徴

| 項目      | 内容                                         |
| ------- | ------------------------------------------ |
| 🔍 取得範囲 | CPU、メモリ、ディスクI/O、ネットワーク、プロセスなど「OSレベル」の詳細情報  |
| 📈 取得間隔 | **1秒～60秒の範囲**で指定可能（CloudWatchは最小1分）        |
| 🧠 監視対象 | DBインスタンスの**仮想マシン（ホストOS）で実行されているプロセス情報**も含む |
| 💾 出力先  | CloudWatch Logs（ロググループ）にJSON形式で出力される       |
| 🛠️ 有効化 | RDSインスタンスの「拡張モニタリング」設定でONにするだけ（再起動不要）      |

---

## 🧪 CloudWatchとの違い

| 比較項目 | CloudWatch（標準）             | 拡張モニタリング                      |
| ---- | -------------------------- | ----------------------------- |
| 粒度   | 最小1分                       | 最小1秒                          |
| 情報範囲 | DBの論理状態（CPU使用率、ストレージ使用量など） | OSレベルのリソース詳細、プロセス単位情報         |
| 出力先  | CloudWatch                 | CloudWatch Logs               |
| 料金   | 無料（基本）                     | **CloudWatch Logsの出力量に応じて課金** |

---

## 📊 取得できる具体的メトリクス例

* CPU使用率（システム、ユーザ、アイドル）
* メモリ使用量（実メモリ、スワップ）
* ディスクIO（読み書きバイト数・IOPS）
* ネットワーク帯域
* プロセス一覧（MySQL, PostgreSQLなどのプロセス単位負荷）
* OSスレッド数やファイルディスクリプタ使用量

---

## 🧰 有効化方法（マネジメントコンソール例）

1. RDSインスタンスの設定画面へ
2. 「モニタリング」タブを開く
3. **「拡張モニタリング」→ 有効化**
4. モニタリング間隔（例：1秒、5秒、60秒）を選択
5. IAMロール（`rds-monitoring-role`など）を指定または自動作成

---

## 💰 コストに注意

* 拡張モニタリング自体は無料ですが、出力されるデータは**CloudWatch Logsの課金対象**になります。
* 例えば1秒間隔で設定すると大量のログが出力され、費用がかさむことがあります。
* 通常は **5秒または10秒間隔** がバランス良好。

---

## ✅ まとめ

| 項目   | 内容                                       |
| ---- | ---------------------------------------- |
| 機能名  | Enhanced Monitoring（拡張モニタリング）            |
| 目的   | OSレベルの詳細な監視                              |
| 利点   | 高速・高解像度、プロセス単位で分析可能                      |
| 欠点   | CloudWatch Logs費用が発生する                   |
| 推奨用途 | パフォーマンスボトルネック調査、CPUスパイク分析、詳細チューニング前の確認など |

---
ディスクストライピング

ディスクストライピング技術（**Disk Striping**）とは、**複数のディスクにデータを分散して書き込むことによって、ディスクの読み書き性能を向上させる技術**です。主に **RAID 0（Redundant Array of Independent Disks, level 0）** として実装されます。

---

## 🔧 ディスクストライピングの基本

### ■ 概要：

* データを小さなブロック単位（ストライプ）に分けて、複数のディスクに並行して書き込みます。
* データの冗長性（耐障害性）はありませんが、**性能向上（特にスループットとIOPS）が目的**です。

---

## 📊 特徴

| 特徴      | 説明                                    |
| ------- | ------------------------------------- |
| ✅ 高速化   | 複数ディスクに同時にアクセスすることで、読み書き速度が向上         |
| ❌ 冗長性なし | どれか1本のディスクが故障すると、**全体のデータが破損**する      |
| 🎯 主な用途 | 一時ファイル、キャッシュ、非重要な大容量データ、高速I/Oが求められるDB |

---

## 🧰 実装方法

### OSレベルでの実装：

* **Linux**：`mdadm` や `LVM` で RAID 0 を構成
* **Windows**：ディスクの「ストライプ ボリューム」機能

### クラウド（AWS, Azure, GCP）での実装：

* 複数のブロックストレージ（例：EBS）をRAID 0で束ねる
* 例：4本のEBSをストライピング → 1つの高速論理ボリュームとして利用

---

## 📌 AWSでの利用例（EBS Striping）

* EBS 1本の最大IOPSやスループットには制限があるため、**複数のEBSボリュームをRAID 0で束ねて性能向上**。
* AWS公式も[一部のユースケースで推奨](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/raid-config.html)（例：Oracle DBやログ処理など）

---

## ⚠️ 注意点

* **バックアップは必須**：1台でも壊れるとデータ全体が失われる
* **EBSスナップショットの扱いに注意**：RAID 0構成だと一貫性のあるスナップショットを取るのが難しい

---

## ✅ まとめ

| 項目   | 内容                    |
| ---- | --------------------- |
| 技術名  | ディスクストライピング（RAID 0）   |
| 目的   | I/O性能の向上（並列アクセス）      |
| 長所   | 高速、スループット向上           |
| 短所   | 冗長性なし、1本の障害で全損        |
| 主な用途 | キャッシュ、高速DB、分析処理、一時データ |

---
streamlitを用いて，月間カレンダーをWebブラウザに表示する

# 西暦と月を選択すると，Webブラウザ上に月間カレンダーを表示するPythonスクリプト

## ポイント
１．西暦と月はプルダウンメニューで選択
２．サイズ可変（幅と高さをピクセル指定）
３．月曜日始まり
４．土曜日は青色，日曜日は赤色で表示
![スクリーンショット 2025-05-07 8.03.54.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1979979/2315583a-f3e5-4d91-8de5-b52aefa9d802.jpeg)

＜実行方法＞
コマンドプロンプトで，以下をタイプして実行
streamlit run disp_month.py

```disp_month.py
# -*- coding: utf_8 -*-
import streamlit as st
import calendar
from datetime import date

def create_monthly_calendar(year, month, day_width, day_height, font_size):
    """月間カレンダーを作成する関数"""
    cal = calendar.Calendar(firstweekday=0)  # 月曜日を週の始まりとする
    month_days = cal.monthdayscalendar(year, month)
    month_name = calendar.month_name[month]
    day_names = ["月", "火", "水", "木", "金", "土", "日"]

    st.subheader(f"{year}年 {month}月")

    # カレンダーのヘッダー（曜日）
    cols = st.columns(7)
    for i, day_name in enumerate(day_names):
        cols[i].markdown(f"<div style='text-align: center;'>{day_name}</div>", unsafe_allow_html=True)

    for week in month_days:
        cols = st.columns(7)
        for i, day in enumerate(week):
            if day == 0:
                cols[i].markdown(f"<div style='width: {day_width}px; height: {day_height}px;'></div>", unsafe_allow_html=True)
            else:
                day_style = f"width: {day_width}px; height: {day_height}px; border: 1px solid #ccc; text-align: left; vertical-align: top; font-size: {font_size}px; padding-left: 2px;"
                if i == 5:  # 土曜日
                    day_style += " background-color: #e0f2f7; color: blue;"
                elif i == 6:  # 日曜日
                    day_style += " background-color: #ffe0b2; color: red;"

                cols[i].markdown(f"<div style='{day_style}'>{day}</div>", unsafe_allow_html=True)

st.title("月間カレンダー表示")

current_year = date.today().year
years = list(range(current_year - 10, current_year + 11))
months = list(range(1, 13))

selected_year = st.selectbox("西暦を選択してください", years, index=years.index(current_year))
selected_month = st.selectbox("月を選択してください", months, index=date.today().month - 1)

day_width = st.number_input("各日の幅（ピクセル）", min_value=20, value=50)
day_height = st.number_input("各日の高さ（ピクセル）", min_value=20, value=50)
font_size = st.number_input("フォントサイズ（ピクセル）", min_value=8, value=12)

if st.button("カレンダーを表示"):
    create_monthly_calendar(selected_year, selected_month, day_width, day_height, font_size)
```
ChatGPTを使用したアプリ開発記【プロフィール画面のReactデバッグ】

## コード
funciton関数でconsole.logを記述。return文には記載しない。
```Profile.js
  // ログ
  console.log('currentUserId:', currentUserId);
  console.log('userId:', userId);
  console.log('typeof currentUserId:', typeof currentUserId);
  console.log('typeof userId:', typeof userId);
  console.log('isCurrentUser:', isCurrentUser);
  console.log('currentUserId:', `"${currentUserId}"`);
  console.log('userId:', `"${userId}"`);
  console.log('一致してる？', currentUserId === userId);
```
## コンソール
コンソール上で、変数が適切な値か確認。

![スクリーンショット 2025-05-13 7.09.52.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1058366/f2ddfa06-b9ee-4132-b7e1-1af276689001.png)
ChatGPTを使用したアプリ開発記【プロフィール画面に詳細情報を表示】

## UIコード
```Profile.js
        {profile ? (
          <div className="bg-white p-4 rounded-lg shadow-md">
            {profile.photoURL && (
              <img
                src={profile.photoURL}
                alt="プロフィール画像"
                className="w-24 h-24 rounded-full mb-4"
              />
            )}
            <p><strong>名前：</strong>{profile.name}</p>
            <p><strong>自己紹介：</strong>{profile.bio}</p>
          </div>
        ) : (
          <p>読み込み中...</p>
        )}
      </div>
```
## Firestoreからデータを取得するロジック
```Profile.js
useEffect(() => {
  const fetchUserProfile = async () => {
    try {

    // db: これは Firestore のデータベースインスタンスです。import { db } from './FireBase' のようにインポートされているはずです。
	// doc(): これは Firestore の doc メソッドで、指定したコレクション（ここでは 'users'）とドキュメント ID（ここでは userId）を使って、特定のドキュメントへの参照を作成します。
	// userId: この値は現在表示しているユーザーの ID です。例えば、userId = 'abc123' のように渡されます。
      const userRef = doc(db, 'users', userId);

      	// getDoc(): これは Firestore の getDoc メソッドで、指定したドキュメント参照（ここでは userRef）からデータを取得する非同期関数です。このメソッドはドキュメントのスナップショット（DocumentSnapshot）を返します。
	// await: getDoc は非同期操作なので、await を使ってデータの取得が完了するまで待機します。
	// userRef: 先ほど作成した、users コレクションの特定のユーザーに対応するドキュメントへの参照です。
	// { source: isOnline ? 'default' : 'cache' }: このオプションは、データの取得方法を指定します。
	// source: データをどこから取得するかを指定するオプションで、'default'（通常のデータ取得）か 'cache'（オフラインキャッシュからのデータ取得）を選べます。
	// isOnline: ネットワーク接続がオンラインかどうかを確認するフラグで、オンラインの場合は通常のデータ取得を行い、オフラインの場合はキャッシュから取得します。
      const userSnap = await getDoc(userRef, { source: isOnline ? 'default' : 'cache' });

      if (userSnap.exists()) {
        setProfile(userSnap.data()); // ← name や bio を含むオブジェクトをセット
      } else {
        setProfile({ name: '未設定', bio: 'プロフィールが設定されていません' });
      }
    } catch (err) {
      setProfile({ name: '未設定', bio: 'オフライン中です' });
    }
  };

  if (userId) {
    fetchUserProfile();
  }
}, [userId]);
```
## Firestoreの構成

![スクリーンショット 2025-05-12 12.53.58.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1058366/7f196afa-e15e-407d-9b64-571206ba74a2.png)


## UI

![スクリーンショット 2025-05-12 12.50.34.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1058366/ab6f60c5-520b-4f02-bc6e-3b6ff11c96b2.png)
【公ド読】タスクに適した AI モデルの選択

【公式ドキュメントを読もうシリーズ】タスクに適した AI モデルの選択

## シリーズ概要

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

## URL

[https://docs.github.com/ja/copilot/using-github-copilot/ai-models/choosing-the-right-ai-model-for-your-task](https://docs.github.com/ja/copilot/using-github-copilot/ai-models/choosing-the-right-ai-model-for-your-task)

## 説明

> GitHub Copilot は、さまざまな能力を持つ複数の AI モデルをサポートします。 選ぶモデルによって、Copilot Chat とコード補完の回答の品質と関連性は影響を受けます。 待機時間が少ないモデルや、特定のタスクではハルシネーションが少ない、またはパフォーマンスが高いモデルがあります。

自分のプロンプトの悪さから出力の精度が悪いんだなあと思うことと同時に、モデルが適切かどうかも考えることで、解決時間が早くなるのかもしれないので、解決できる選択肢を増やすというのは大事なアプローチなんだろうなと思った。

ざっくりとしたユースケースが公式ドキュメントに載っていた(2025年5月13日現在)

> - コストとパフォーマンスのバランスを取る場合は、GPT-4.1 または または Claude 3.5 Sonnet を試してください。
> - 深い推論や複雑なコーディングの課題には、o3、GPT-4.5、または Claude 3.7 Sonnet を試してください。
> - マルチモーダル入力とリアルタイム パフォーマンスを求める場合は、Gemini 2.0 Flash または GPT-4o を試してください。



## 所感

ずっとClaude 3.5 Sonnetを使ってきたが、Copilot Freeで使えるGPT-4.1も精度がいいというのをxで見たような気がするので、試してみようかなとも思っている。

ProプランだとClaude 3.7 Sonnet、Pro+プランだと現在(2025年5月13日現在)パブリックプレビュー段階ではあるが、o3を試してみたい。
0と1を0と任意の値(たとえば、46)にして遊ぶ。


いろいろ、注意
----

- UNOでの予定は、未定
- こんな、どうでも、いいので、ややヒット。
- 用途しては、どうしても、高速化が必要なところ。


プログラム
----

オンラインコンパイラーPAIZA

```c++


//8ビット分、2進数に変換して表示するマクロ(注意!!!入力は、破壊される
#define bit8_put(aa) for(int ii=8;ii!=0;ii--){if(aa&0x80){printf("1");}else{printf("0");}aa=aa<<1;}

#include <iostream>
using namespace std;
int main(void){
    // Your code here!

    char a;

    a = 0;
    
    printf("IN[%d]\n",a);
    
    a  = (0 - a) & 46;
    
    printf("OUT[%d]\n",a);
    bit8_put(a);
    printf("\n\n");
    
    a = 1;
    
    printf("IN[%d]\n",a);

    a  = (0 - a) & 46;

    printf("OUT[%d]\n",a);
    
    bit8_put(a);
}


```

```

IN[0]
OUT[0]
00000000

IN[1]
OUT[46]
00101110


```

・

・


・




おまけ(掛け算でのやり方)
----


```c++




//8ビット分、2進数に変換して表示するマクロ(注意!!!入力は、破壊される
#define bit8_put(aa) for(int ii=8;ii!=0;ii--){if(aa&0x80){printf("1");}else{printf("0");}aa=aa<<1;}

#include <iostream>
using namespace std;
int main(void){
    // Your code here!

    char a;

    a = 0;
    
    printf("IN[%d]\n",a);
    
    a  = a * 46;
    
    printf("OUT[%d]\n",a);
    bit8_put(a);
    printf("\n\n");
    
    a = 1;
    
    printf("IN[%d]\n",a);

    a  = a * 46;

    printf("OUT[%d]\n",a);
    
    bit8_put(a);
}



```


```

IN[0]
OUT[0]
00000000

IN[1]
OUT[46]
00101110

```
OpenSSLの “Secure Renegotiation IS NOT supported” について

## そもそもTLSにおいて再ネゴシエーション (Renegotiation) とは
> 既存のセキュア・セッション中に新しいハンドシェーク・ネゴシエーションを開始することを、再ネゴシエーションといいます。
[参考サイトより](https://www.ibm.com/docs/ja/i/7.3.0?topic=settings-renegotiation)

### 再ネゴシエーションの脆弱性
まず書いておかないといけない背景的なところから書きます。TLS v.1、SSL v.3では脆弱性が見つかり、2010年頃に更新されたTLS/SSLプロトコルがリリースされました。具体的には、TLS/SSL 再ネゴシエーションによる中間者 (MITM) 攻撃 (CVE-2009-3555)が実行可能でした。サーバ証明書とクライアント証明書を利用した相互の証明書ベースのクライアント認証接続であっても、再ネゴシエーションによる中間者攻撃を防ぎきれません。

https://rms.ne.jp/sslserver/basis/ssl-renego/

## 当該メッセージが出たコマンド
`openssl s_client`で自己署名証明書でのTLS/SSL接続をテストした時に “`Secure Renegotiation IS NOT supported`” というメッセージが表示されることがあります。
``` .bash
openssl s_client -connect localhost:443 -cipher ECDHE-RSA-AES128-GCM-SHA256  < /dev/null
CONNECTED(00000003)
......
..........
---
SSL handshake has read 1378 bytes and written 315 bytes
Verification error: self-signed certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 18 (self-signed certificate)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 06F79634BC3689E......
    ......
......
..........
DONE
```

以下の各サイトを参考にすると、上述の再ネゴシエーションによる攻撃の脆弱性は、0.9.8以降のOpenSSLバージョンで修正されていると思われます。

https://serverfault.com/questions/822361/openssl-secure-renegotiation-not-supported

https://access.redhat.com/articles/20490

下記コマンドで確認したところ、私が使用しているOpenSSLのバージョンは`3.0.8` (かつhttpdやvsftpdとともにTLSv1.3を使用してTLS/SSLしている)となっているので、あたりまえですが「`Secure Renegotiation IS NOT supported`」というのは、『 (現在ユーザが使用している) OpenSSLが安全な再ネゴシエーションを実装していない』というわけではなく、OpenSSLを利用しているサービス提供者側 (今回は個人的な利用ですが）が、サーバーやクライアントに対して設定をおこなううえで、安全な再ネゴシエーションが実施されるようになっていない、という意味だと思われます。

```
/usr/bin/openssl version -a
OpenSSL 3.0.8 7 Feb 2023 (Library: OpenSSL 3.0.8 7 Feb 2023)
```

## 対処法
筆者の以下の投稿で、暗号化スイートの優先設定を適切に行うことにより`Secure Renegotiation IS supported`にすることができます。

https://qiita.com/Am_nine/items/77a449e0560815647391
生成AIの歴史についてまとめてみた。

生成AIの歴史は、比較的最近の発展ではありますが、その根底にあるアイデアや技術は数十年前から存在していました。その進化の道のりを段階的に見ていきましょう。

# 萌芽期（1950年代 - 1980年代）：初期の試みとルールベースのアプローチ

・1950年代 - 1960年代：初期の自然言語処理（NLP）: アラン・チューリングのチューリングテストに代表されるように、コンピュータに人間のような知性を持たせる試みが始まりました。初期のNLP研究では、ルールベースの手法を用いて簡単なテキスト生成が行われましたが、複雑な文章を生成するには限界がありました。
・1960年代 - 1970年代：ELIZAとパリー: ELIZAは、簡単なパターンマッチングと置換ルールを用いて人間らしい対話を行うプログラムとして有名です。パリーは、精神病患者の思考を模倣した対話プログラムでした。これらは、対話生成の初期の試みと言えますが、真の意味での「生成AI」とは言えませんでした。
・1980年代：エキスパートシステム: 特定の領域の専門家の知識をルールとして記述し、推論を行うエキスパートシステムが開発されました。テキスト生成も、事前に定義されたテンプレートやルールに基づいて行われることが一般的でした。

# 統計的アプローチの台頭（1990年代 - 2010年代初頭）：データ駆動型生成

・1990年代：統計的自然言語処理（Statistical NLP）： 大量のテキストデータから統計的なパターンを学習し、それに基づいて言語処理を行う手法が主流となりました。N-gramモデルなどがテキスト生成に用いられ、以前のルールベースの手法よりも自然なテキストを生成できるようになりましたが、文脈の長期的な依存関係を捉えるのは困難でした。
・2000年代：潜在的意味解析（LSA）と潜在的ディリクレ配分法（LDA）： これらのトピックモデルは、文書集合から潜在的な意味構造を抽出し、それに基づいてテキストの生成や分析を行うために用いられました。
・リカレントニューラルネットワーク（RNN）の初期の研究: 時間的な依存性を持つデータの処理に適したRNNの研究が進められ、テキスト生成や音楽生成などの分野で初期的な成果を上げました。しかし、長期依存性の学習が難しいという課題がありました。

# 深層学習による飛躍的な進化（2010年代後半 - 現在）：真の生成AIの登場

・2014年：敵対的生成ネットワーク（GAN）： イアン・グッドフェローらによって提案されたGANは、生成器（Generator）と識別器（Discriminator）という2つのニューラルネットワークを競わせることで、リアルな画像を生成する画期的な手法です。GANの登場は、画像、音楽、テキストなど、多様な種類のデータを高品質に生成するAIの可能性を大きく広げました。
・2015年：Transformerアーキテクチャの登場（自然言語処理）： Googleの研究者らによって提案されたTransformerは、自己注意メカニズム（Self-Attention）を用いることで、テキスト内の離れた単語間の依存関係を効率的に捉えることができる新しいニューラルネットワークの構造です。Transformerは、翻訳、テキスト要約、質問応答など、様々な自然言語処理タスクで圧倒的な性能を発揮し、大規模言語モデル（LLM）の基盤技術となりました。
・2018年：GPT（Generative Pre-trained Transformer）シリーズの登場: OpenAIによって開発されたGPTシリーズは、Transformerアーキテクチャをベースとした大規模言語モデルです。GPT-1に始まり、GPT-2、GPT-3、そして現在のGPT-4に至るまで、モデルの規模と学習データ量を増やすことで、人間が書いたような自然で多様なテキストを生成する能力が飛躍的に向上しました。
・拡散モデル（Diffusion Models）の台頭（画像生成）： 近年、GANと並んで、あるいはそれ以上に高品質な画像生成を実現する手法として拡散モデルが注目を集めています。拡散モデルは、ノイズから徐々に画像を復元していくプロセスを学習することで、非常にリアルで多様な画像を生成することができます。
・マルチモーダル生成AI: テキストと画像を組み合わせた画像生成（DALL-E 2、Stable Diffusion、Midjourneyなど）、テキストからの音楽生成、動画生成など、複数の種類のデータを組み合わせて生成するAIの研究開発も活発に進んでいます。

# 現在の動向と今後の展望:

生成AIは、文章、画像、音楽、動画、コードなど、様々な種類のデータを人間が作成するのと遜色ないレベルで生成できるようになりつつあります。その応用範囲は、コンテンツ制作、デザイン、研究開発、教育など、多岐にわたります。

今後の展望としては、以下のような点が挙げられます。

・生成能力のさらなる向上: より高品質で、より多様で、より文脈に合ったデータを生成する能力の向上。
・制御可能性の向上: ユーザーの意図や指示をより正確に反映した生成結果を得るための技術開発。
・解釈可能性の向上: 生成AIがどのような根拠に基づいて出力を生成したのかを理解するための研究。
・倫理的・社会的な課題への対応: 偽情報の生成、著作権侵害、雇用への影響など、生成AIの普及に伴う倫理的・社会的な課題への対応策の検討。

生成AIは、まだ発展途上の技術であり、その可能性と課題の両面を理解しながら、社会に貢献する形で活用していくことが重要です。
2025/5/13主にITとかセキュリティの記事

米国 FBI サポートが終了したルータを悪用したサイバー犯罪について警告(5/11)
http://maruyama-mitsuhiko.cocolog-nifty.com/security/2025/05/post-64f246.html

Cursor・rand-user-agent侵害事件：3,200以上の開発者に影響したnpmサプライチェーン攻撃の実態(5/11)
https://innovatopia.jp/cyber-security/cyber-security-news/53854/

大学の研究室ネットワークをCloudflare Zero Trustで武装した話(5/10)
https://zenn.dev/kabos0809/articles/4d015b53ef4e2a

【週刊AI】Apple、AI検索へ移行検討でGoogle株価急落。Figma、AIサイト作成ツール発表 | #15 2025年5月5日~5月11日(5/11)
https://chatgpt-lab.com/n/n391a14fa7104

IoTボットネット解体：米国・オランダ当局が7,000台規模のTheMoonマルウェア感染デバイスを摘発(5/11)
https://innovatopia.jp/cyber-security/cyber-security-news/53880/

190億の漏洩パスワードが公開、スマホを狙うフィッシングSMSの猛威が拡大中(5/11)
https://forbesjapan.com/articles/detail/78982

拡張ファインチューニングが鍵 – Google DeepMind、PFN、NRIの技術と自社ナレッジ学習(5/11)
https://innovatopia.jp/ai/ai-news/53867/

混乱する時代のリーダーに欠かせない5つのスキル
革新と成長を実現するために(5/11)
https://dhbr.diamond.jp/articles/-/11868

パロアルトネットワークは、若い世代にとってのサイバー教育の重要性を強調しています(5/11)
https://voi.id/ja/teknologi/481492

日本企業も無関係ではないGDPRと個人情報保護法：プライバシー侵害の代償は？(5/11)
https://innovatopia.jp/tech-social/tech-social-news/53864/

カリフォルニア州 プライバシー保護法案の修正案についての意見募集 (2025.05.08)(5/11)
http://maruyama-mitsuhiko.cocolog-nifty.com/security/2025/05/post-d98af5.html

量子コンピューターの“方式”は主に5つ──其の伍【超伝導方式】IQM(5/11)
https://wired.jp/article/vol56-different-strokes-for-different-folks-iqm/

PR TIMESにサイバー攻撃　個人情報漏えいの可能性は？(5/11)
https://news.infoseek.co.jp/article/itmedia_bizmakoto_20250509094/?tpgnr=it

Dream HEART vol.632　横河デジタル株式会社社長 鹿子木宏明さん　「日本産の誇りを取り戻したい」(5/10)
https://www.tfm.co.jp/dreamheart/index.php?catid=1745&itemid=205786

『中国・ロシアは実は対立関係にある？』中露関係に潜む3つの亀裂とは(5/11)
https://kusanomido.com/study/overseas/106408/

1年前：世紀の夜明け：嵐は私たちに何を教えたのか？
https://ja.futuroprossimo.it/2025/05/un-anno-fa-le-aurore-del-secolo-che-ci-ha-insegnato-la-tempesta/

【二宮町】二宮町の学校卒業アルバムデータにランサムウェア被害、児童生徒202名分の情報漏洩の可能性(5/11)
https://shonanjin.com/news/ninomiya-ransomware-incident/

在留カード偽造で中国籍の男2人逮捕　偽造データ1万点超を押収　戸籍謄本の偽造も(5/11)
https://rocket-boys.co.jp/security-measures-lab/two-chinese-nationals-arrested-for-residence-card-forgery/
amazon linux2023で複数ディレクトリで、双方向同期をする方法

## 概要
諸事情で急遽同期設定の検証を行うことになりました。
(同期設定すらしたことなかったのでかなりしんどかったです。)

手順を忘れないために書き残します。
今回は、EC2でサーバーを2つ用意しこの2つで同期をします。

### 前提条件
- lsyncdインストール済

### 利用するツール
①lsyncd
- 指定したディレクトリの監視を行う、変更が発生した際rsyncを動かす 

②rsync
- 設定されたサーバーに対し、同期を行う

③amazon linux2023
- AWSが提供しているLinux

### 検証に利用するサーバー情報
#### web01
- プライベートIP 10.0.2.11

#### web02
- プライベートIP 10.0.2.22

### 同期させるディレクトリ
- /var/www/test1
- /var/www/test2

:::note
同期設定を行う際、プライベートIPを利用するのでIPに注意すること
:::

## 手順
### rsync.confに以下を追記する
```
uid = root
gid = root
read only = no
log file = /var/log/rsync/rsyncd.log
pid file = /var/log/rsync/rsyncd.pid
port = 873
 
[var-www-test1]
path = /var/www/test1
hosts allow = 10.0.2.22
read only = false
 
[var-www-test2]
path = /var/www/test2
hosts allow = 10.0.2.22
read only = false
```

### lsyncd.confに以下を記載する
```
settings {
    logfile    = "/var/log/lsyncd/lsyncd.log",
    statusFile = "/var/log/lsyncd/lsyncd.status",
    statusInterval = 1,
}
 
sync {
    default.rsync,
    source = "/var/www/test1",
    target = "10.0.2.22::var-www-test1",
    init = false,
    rsync = {
        archive = true,
        links = true,
        update = true,
        verbose = false
    }
}
 
sync {
    default.rsync,
    source = "/var/www/test2",
    target = "10.0.2.22::var-www-test2",
    init = false,
    rsync = {
        archive = true,
        links = true,
        update = true,
        verbose = false
    }
}
```

::: note
上記にはweb01側のファイルになります。
web02側にはweb01のIPにした内容を記載してください。
:::
### ログ用のディレクトリとファイルを作成する
```
mkdir /var/log/lsyncd
touch /var/log/lsyncd/lsyncd.log
touch /var/log/lsyncd/lsyncd.status
```
### 同期するディレクトリの作成
```
mkdir /var/www/test1
mkdir /var/www/test2
```

- この状態で、lsyncdをリスタートする

### まとめ
これで同期するようになりました。
初めて同期設定をしたので、最初わけがわからず困惑しました。
【Rails初学者】Railsで `annotate` を導入して、モデルにスキーマ情報を表示できるようにした話

# Railsで `annotate` を導入して、モデルにスキーマ情報を表示できるようにした話

こんにちは。
reilsを学習中の看護師です。
Railsアプリでモデルの構造（テーブル名やカラム情報）を確認したいとき、いちいち`schema.rb`を見に行くのが面倒だと感じてきました。  
そんなときに便利なのが`annotate`というgem。
モデルファイルの先頭にスキーマ情報を自動で追記してくれるらしいです。
実際に導入して、便利だったのでその手順と感想を残しておきます。

---------
## 環境

- Rails 8.0.2
- Ruby 3.4.2
- annotate 3.2.0

## 導入手順
 `Gemfile` に追加
```ruby
group :development do
  gem 'annotate'
end
```
インストールする
```bash
bundle install
```
設定ファイルを生成する
```bash
rails g annotate:install
```
 `lib/tasks/auto_annotate_models.rake`が生成され、開発環境限定で`annotate`を使うように設定される。

## 試してみた
マイグレーションを実行すると、自動的にモデルファイルの先頭にスキーマ情報が追加されました
 ```bash
 rails db:migrate
Annotated (1): Article
```
```ruby
# == Schema Information
#
# Table name: articles
#
#  id         :integer          not null, primary key
#  title      :string
#  content    :text
#  created_at :datetime         not null
#  updated_at :datetime         not null
#

class Article < ApplicationRecord
  validates :title, presence: true
  validates :content, presence: true

  def display_created_at
    I18n.l(self.created_at, format: :default)
  end
end
```

## 良かったこと
- モデルを開いただけでDB構造がすぐわかる
- 他人のコードを読むときにも助かる
- コードとDBが離れがちな初期フェーズで特にありがたい


導入もシンプルなので、今後のRailsプロジェクトでも積極的に使っていきたい。
競プロ日記#25/05/12

# アルゴ式
[正規表現 3-1](https://algo-method.com/tasks/293)
- C++ではバックスラッシュ二つ必要だったのを忘れていた

```
int main() {
    string S;
    cin >> S;
    if (regex_search(S,regex("\\d+") )){
        cout << "Yes" << endl;
    } else{
        cout << "No" << endl;
    }
}
```

[正規表現 3-4](https://algo-method.com/tasks/296)
- 前後に「^」「$」を付ける癖をつｋ
```
int main() {
    string S;
    cin >> S;
    if (regex_search(S,regex("^\\w+@\\w+\\.\\w{1,4}$") )){
        cout << "Yes" << endl;
    } else{
        cout << "No" << endl;
    }

}
```