OmniAICreator/Qiita-1.07M huggingface dataset:
jsで列挙型的データ構造で分岐処理を記載する

## 動機

以下のように分岐処理を記載するため、列挙型的データ構造(`MY_ENUM`の中身)を考案しました。
```js
const MY_ENUM = {/* ？ */};
// ...
const e = MY_ENUM.key0;
// ...
if (e.key0) {
    // ...このブロックにはいる...
} else if (e.key1 || e.key2) {
    // ...
} else if (e.key3) {
    // ...
} else {
    // ...
}
```

この例の場合、列挙型的データ構造は最低限、以下でないといけません。
```js
const MY_ENUM = {
    'key0':{'key0':true,},
    'key1':{'key1':true,},
    'key2':{'key2':true,},
    'key3':{'key3':true,},
    // ...
};
```

## 本案で解決される課題

本案は、以下のようなプログラムから移行するために考案しました。

### switch句
分岐が英単語(`case`、`default`や`break`)で表されるため見ずらい、`break`漏れによる意図しない落下(fall-through)、分岐で字句スコープが作成されない問題、などがあり、好ましく思わない意見があります。
```js
const key = 'key0';
// ...
switch (key) {
case 'key0':
    // ...このブロックにはいる...
    break;
case 'key1':
case 'key2':
    // ...
    break;
case 'key3':
    // ...
    break;
default:
    // ...
}
```

### 文字列型を使用して判定
`key===`冗長記載による可読性の低下が気になります。
```js
const key = 'key0';
// ...
if (key==='key0') {
    // ...このブロックにはいる...
} else if (key==='key1' || key==='key2') {
    // ...
} else if (key==='key3') {
    // ...
} else {
    // ...
}
```

### ユニークな値を持つ連想配列(固定化したオブジェクト)
`key===MY_ENUM.`冗長記載による可読性の低下が気になります。
```js
const MY_ENUM = Object.freeze({
    'key0':0,
    'key1':1,
    'key2':2,
    'key3':3,
    // ...
});
// ...
const key = MY_ENUM.key0;
// ...
if (key===MY_ENUM.key0) {
    // ...このブロックにはいる...
} else if (key===MY_ENUM.key1 || key===MY_ENUM.key2) {
    // ...
} else if (key===MY_ENUM.key3) {
    // ...
} else {
    // ...
}
```

### 連想配列の値に関数を定義
ケースによると考えます。
```js
const MY_ENUM = {
    'key0':()=>{/*...このブロックにはいる...*/},
    'key1':()=>{/*...*/},
    'key3':()=>{/*...*/},
    // ...
    'defaultKey':()=>{/*...*/},
};
MY_ENUM['key2'] = MY_ENUM['key1'];
Object.freeze(MY_ENUM);
// ...
const key = 'key0';
// ...
(MY_ENUM[key] ?? MY_ENUM['defaultKey'])();
```

## 付加情報

最低限の列挙型的データ構造だと、`e.key0`は`true`または`undefined`になります。
例えば`elem.classList.toggle('className', e.key0)`としたい場合などで、`e.key0`の値を`true`または`false`にしたいなら、最低限以下のデータ構造にしないといけません。
```js
const MY_ENUM = {
    'key0':{'key0':true,'key1':false,'key2':false,'key3':false,/*...*/},
    'key1':{'key0':false,'key1':true,'key2':false,'key3':false,/*...*/},
    'key2':{'key0':false,'key1':false,'key2':true,'key3':false,/*...*/},
    'key3':{'key0':false,'key1':false,'key2':false,'key3':true,/*...*/},
    // ...
};
```

データ構造を作成する関数を作ることができます。
以下は最低限の列挙型的データ構造を作成する場合。
```js
const makeEnum = keys=>{
    const m = {};
    for (const k of keys.split(' ')) {
        m[k] = Object.freeze({[k]:true,});
    }
    return Object.freeze(m);
};
// ...
const MY_ENUM = makeEnum('key0 key1 key2 key3');
// ...
```
Keep Rust Simple: Rustが持たない意外な10の機能

## はじめに

プログラミング言語の設計において「シンプルさ」は永遠のテーマです。新しい機能を追加すれば便利になるが、同時に複雑さも増します。この矛盾にRustはどう向き合っているのでしょうか？

今回は、Chad Nauseam氏による記事「[Keep Rust Simple](https://chadnauseam.com/coding/pltd/keep-rust-simple)」を中心に紹介します。

## Rustが持たない10の機能

Rustには、多くの言語が「便利」とする以下の機能がありません：

1. **名前付き引数**（Named arguments）
2. **デフォルト引数**（Default arguments）
3. **三項演算子**（Ternary operator）
4. **null**
5. **例外**（Exceptions）
6. **関数のオーバーロード**（Function overloading）
7. **継承**（Inheritance）
8. **コンストラクタ**（C++的な意味での）
9. **可変長引数関数**（Variadic functions）
10. **暗黙的な型変換**（Implicit type conversions）

> これらの機能がなくても、実際には何でもできます。これらは単なる「便利機能」であり、これらの便利機能がないことで言語がよりシンプルになります。学習しやすく、使いやすくなるのです。


## 「便利さのための複雑さ」vs「パワーのための複雑さ」

しかし、Rustが完全にシンプルかというと、そうではありません。例えば文字列型を見てみましょう：

- `&str`：「文字列参照」
- `String`：「所有された文字列」

もっと易しい言語から来た人には複雑に見えるかもしれません。なぜすべてを`String`にしないのでしょうか？

これが **「便利さのために追加された複雑さではなく、パワーのために交換された複雑さ」** だと主張しています。

```rust
fn get_first_word(s: &str) -> &str {
    s.split_whitespace().next().unwrap_or("")
}
```

`&str`があることで、「文字列の一部」への参照を、不要なコピーを作ることなく取得できます。これは実用的なパワーを提供する複雑さなのです。

## 静的解析によるシンプルさの実現

Rustのシンプルさの真価は、静的解析による間違いの防止にあります。以下のPythonコードを見てください：

```python
# Python - 間違いを見つけるのが困難
x = [2, 1, 4]
x = x.sort()  # これはNoneを返すため、xはNoneになってしまう
print(x)
```

同じことをRustで書くとどうなるでしょうか：

```rust
fn test() {
    let x = vec![2,1,3];
    let x = x.sort();
    // error: cannot borrow `x` as mutable, as it is not declared as mutable
    println!("{x:?}")
}
```

さらに、変数を可変にしても：

```rust
fn test() {
    let mut x = vec![2,1,3];
    let x = x.sort();
    println!("{x:?}")
}
```

Rustは正確に何が間違っているかを教えてくれます：

```
warning: this let-binding has unit value
 --> src/lib.rs:3:5
  |
3 |     let x = x.sort();
  |     ^^^^^^^^^^^^^^^^^
help: omit the `let` binding and replace variable usages with `()`
  |
3 ~     x.sort();
4 ~     println!("{():?}")
```

> 間違いを検出して説明してくれる強力な静的解析は、実は初心者にとって非常に便利なのです（多くの間違いを犯しがちな初心者にとって特に）。

## 表現式としてのif：三項演算子の代替

Rustには三項演算子がありませんが、実際には必要ありません。なぜなら`if`が式だからです：

```rust
let result = if condition { value_a } else { value_b };
```

これは三項演算子（`condition ? value_a : value_b`）と同じことができますが、新しい概念を言語に追加する必要がありません。

## 「機能の追加」より「制限の解除」

記事はRustの「シンプルな」側面を紹介していますが、Rustは比較的新しい言語で、次々に新たな機能が追加されています。ではシンプルさが失われつつあるかというとそうではありません。

十分に成熟した現代の言語設計では、「機能を追加する」よりも「制限を解除する」ことのほうが重要です：

- 新しく覚えることを追加する

ではなく

- 覚えることを減らす

ような言語変更です。

例えば：
- traitsでasyncが使えるようになった
- 借用チェッカーがPoloniusによってより寛容になる

これらは「新機能」ですが、学習者にとっては「当然できるはず」と感じられ、学習コストを下げることにつながります。



## まとめ

「Keep Rust Simple」：

1. **本当に必要な複雑さと、単なる便利さのための複雑さを区別すること**
2. **「機能の追加」よりも「制限の解除」を重視すること**
3. **静的解析によって間違いを早期発見すること**

**「シンプル」は目的ではなく、より良いプログラムを書くための手段なのです。**

## 参考リンク

- [Keep Rust Simple - Chad Nauseam](https://chadnauseam.com/coding/pltd/keep-rust-simple)
- [Reddit上の議論：Keep Rust Simple!](https://www.reddit.com/r/rust/comments/1l5txr0/keep_rust_simple/)
2025/6/10主にITとかセキュリティの記事

BADBOX 2.0ボットネット、数百万台のAndroidデバイスを感染させホームネットワークを標的に – FBI警告(6/8)
https://innovatopia.jp/cyber-security/cyber-security-news/57020/

iMessageのギャップは、iPhoneユーザーに対するゼロクリック攻撃に使用できます(6/8)
https://voi.id/ja/teknologi/487201

カスペルスキーは、2025年第1四半期にAndroidスマートフォンで180,000件以上の攻撃を発見しました(6/8)
https://voi.id/ja/teknologi/487280

Chrome緊急修正: V8エンジンのゼロデイ脆弱性CVE-2025-5419が悪用中、今すぐアップデートを(6/7)
https://innovatopia.jp/cyber-security/cyber-security-news/56999/

すかいらーくのテイクアウトサイトが不正アクセスから復旧し再開(6/8)
https://rocket-boys.co.jp/security-measures-lab/skylark-takeout-site-reopens-after-cyberattack/

Atomic macOS StealerがClickFix手法で急襲──Spectrum偽CAPTCHA経由のシステムパスワード窃取手法を徹底解剖(6/8)
https://innovatopia.jp/cyber-security/cyber-security-news/57023/

内閣官房 NISC サイバーセキュリティ戦略本部第43回会合 - インシデント報告様式の統一 (2025.05.29)(6/8)
http://maruyama-mitsuhiko.cocolog-nifty.com/security/2025/06/post-01f18e.html

OpenAIがChatGPT悪用の国家関与サイバー攻撃10件を阻止 中国・ロシア・北朝鮮の手法を分析(6/8)
https://innovatopia.jp/cyber-security/cyber-security-news/57017/

ウォルマート・IBM・ネスレが実証：ブロックチェーンが年間500億ドルの食品偽装問題を解決する可能性と課題(6/8)
https://innovatopia.jp/blockchain/blockchain-news/57052/

アクティオグループ、「なりすましメール」防止のためBIMIを導入(6/8)
https://www.excite.co.jp/news/article/Prtimes_2025-06-08-118744-12/

合成データのセキュリティリスクが浮上｜2030年までにAI訓練データの大部分が合成化、再識別リスクと対策を専門家が解説(6/8)
https://innovatopia.jp/ai/ai-news/57008/

あなたのGoogleアカウントも標的に Cookie盗難と乗っ取りの手口(6/8)
https://forbesjapan.com/articles/detail/79618

内閣官房 NISC イバーセキュリティ戦略本部第43回会合 - サイバー空間を巡る脅威に対応するため喫緊に取り組むべき事項　(2025.05.29)(6/8)
http://maruyama-mitsuhiko.cocolog-nifty.com/security/2025/06/post-902f2a.html

作業効率爆上がり！ 使わないともったいない生成AI「Copilot」の基本と使いこなし術をプロが伝授(6/8)
https://getnavi.jp/digital/1042550/

インサイダー取引事例まとめ：過去の重大事件から学ぶ金融犯罪の実態(6/8)
https://nikkeimatome.com/?p=61303

ロケット開発事業のセキュリティ革新：インターステラテクノロジズがシスコのSASEを選んだ理由(6/9)
https://news.yahoo.co.jp/sponsored/cisco_250609.html

ロシア衛星コスモス2588が米国USA 338をストーキング – 宇宙が新たな軍事競争の舞台に(6/8)
https://innovatopia.jp/spacetechnology/spacetechnology-news/57058/

北朝鮮のインターネットは完全に麻痺しています!研究者が考えられる驚くべき原因を明らかに(6/7)
https://voi.id/ja/teknologi/487180

北朝鮮で発生したインターネット接続障害が復旧…観光メディアなど通常アクセスに(6/8)
https://www.afpbb.com/articles/-/3582125?cx_part=top_category&cx_position=5

仮想通貨イベントに潜むリスク　「無防備な参加者が狙われている」＝クラーケンが警鐘(6/8)
https://jp.cointelegraph.com/news/crypto-eventgoers-fail-basic-situational-awareness-kraken

対ロ圧力の強化訴え＝ウクライナ支援で法と秩序守る―ノルウェー外相インタビュー(6/8)
https://sp.m.jiji.com/article/show/3535983

iPhoneの「ライブ留守番電話」機能は迷惑電話対策に有効？(6/8)
https://news.yahoo.co.jp/articles/1d075fc538bdb88fc526c8fba6d8201e9f3e80fc
【Project Euler】#006

https://qiita.com/umekikazuya/items/7062d91ddb8db112ef84

6問目です！

## 問題
> The sum of the squares of the first ten natural numbers is, $1^2 + 2^2 + ... + 10^2 = 385.$
> The square of the sum of the first ten natural numbers is,
> $(1 + 2 + ... + 10)^2 = 55^2 = 3025.$
> Hence the difference between the sum of the squares of the first ten natural numbers and the square of the sum is $3025 - 385 = 2640$.
> Find the difference between the sum of the squares of the first one hundred natural numbers and the square of the sum.

$1〜100$までの和の累乗から$1^2〜100^2$までの和を引く感じですね。

https://projecteuler.net/problem=6
## わたしの回答
```go
func main() {
	x := 0
	y := 0
	for i := 1; i <= 100; i++ {
		x += i * i
		y += i
	}
	fmt.Println(y*y - x)
}
```
ひねらずにまっすぐ解きました。

## GPT-4oの回答
```go
func main() {
	n := 100
	sumOfSquares := 0
	for i := 1; i <= n; i++ {
		sumOfSquares += i * i
	}
	sum := n * (n + 1) / 2
	squareOfSum := sum * sum
	// difference
	difference := squareOfSum - sumOfSquares
	fmt.Println("Difference:", difference)
}
```

## Gemini2.5 Flashの回答
```go
func main() {
	n := 100
	sumOfSquares := 0
	for i := 1; i <= n; i++ {
		sumOfSquares += i * i
	}
	sumOfNumbers := 0
	for i := 1; i <= n; i++ {
		sumOfNumbers += i
	}
	squareOfSum := sumOfNumbers * sumOfNumbers
	difference := squareOfSum - sumOfSquares

	fmt.Printf("The sum of the squares of the first %d natural numbers is: %d\n", n, sumOfSquares)
	fmt.Printf("The square of the sum of the first %d natural numbers is: %d\n", n, squareOfSum)
	fmt.Printf("The difference is: %d\n", difference)
}
```
あ、ループ全く同じ二回に分けて書いてる！冗長ですね。
## 感想
ちょっと納得行く感じで解けたのでよかったです。
【デジタル仮想量子アルゴリズム】のための量子物理学の私見

【デジタル仮想量子アルゴリズム】のための量子物理学の私見にまとめた。

１．量子物理学の前提条件は、一定の拡散確率が成り立つ数量の量子が
　　存在する場合のみ成り立つ。
２．量子は波である。
　　量子が粒になるのは、拡散確率が一方向に収束された場合のみである。
３．量子を波か粒かを決定しているのは観測器ではなく拡散確率である。
４．一定の拡散確率が成り立つ数量の量子が存在する場合のみ
　　干渉波等の波の現象が実現する。
５．量子のもつれとは、反射現象である。
６．量子の重ね合わせ状態とは、量子が未確定状態を差し実体は
　　未だ存在しない。
７．量子が実体として存在するのは拡散確率が一方向に収束された
   場合である。
８．量子物留学において拡散確率が一方向に収束された状態を
　　【世界観の崩壊】と云う。
９．量子物理学は、量子である必要は無い。
　　拡散確率を持つ物（人間、お金、データ値等）ならば成立する。
１０．必要としてる機能の量子コンピュータは、私見の量子物留学
　　　では作れない。
　　　古典コンピュータにおいて【コペンハーゲン多次元世界解釈】
   　の仮想現実でのみ作れる。
そのテッセレーション、絶対に四角形じゃないとだめ？

# 結論
## 99.99％の四角形分割は、三角形分割で代替できる
絶対に四角形テッセレーションが必要になるのは、この"分割形状"が重要な場合だけです。それは例えば「正方形のメッシュを作成し、それを凸凹させたい」という、幾何学的で特殊なケースだけです。

![image.png](https://www.khronos.org/opengl/wiki_opengl/images/QuadOuterAndNotris.png)
4辺からなる3D図形の内部を補完したいというだけであれば、三角形テッセレーションを二回することで代替できます


## → ツールが三角形分割しかできないことは、気にしなくていい
今まで私は、独自の四角形分割を実装するため、使用ツールの決定時に、シェーダーが四角形分割テッセレーションをできるかどうか見ていました。しかし多少凝った実装をするにしても、四角形分割は必須ではありません。

# Quad用のTessCoordさえ分かればいい
三角形分割では、分割後の頂点座標の計算のために、TessCoordがvector2ではなくvector3で与えられます。これは以下の図のように三角形の重心座標です。
![image2.png](https://upload.wikimedia.org/wikipedia/commons/thumb/b/b7/TriangleBarycentricCoordinates.svg/330px-TriangleBarycentricCoordinates.svg.png)


重心座標から三角形上の座標を計算する場合は、次のコードのvalueに、三角形の3つの頂点座標を代入します。
>```
>vec3 accum = vec3(0.0f)
>accum += gl_TessCoord[0] * value[0]
>accum += gl_TessCoord[1] * value[1]
>accum += gl_TessCoord[2] * value[2] 
>```
>[OpenGL Wiki](https://www.khronos.org/opengl/wiki/tessellation#:~:text=vec3%20accum%20%3D%20vec3(0.0f)%0Aaccum%20%2B%3D%20gl_TessCoord%5B0%5D%20*%20value%5B0%5D%0Aaccum%20%2B%3D%20gl_TessCoord%5B1%5D%20*%20value%5B1%5D%0Aaccum%20%2B%3D%20gl_TessCoord%5B2%5D%20*%20value%5B2%5D)



で、四角形を２つの三角形に分割してレンダリングする場合は、今分割している三角形の3頂点の、Quadテッセレーションの座標(下図参照) をvalueにしてやればいいんです。
![image3.png](https://www.khronos.org/opengl/wiki_opengl/images/QuadLevels.png)

つまり
```
vec2 quad_TessCoord = vec2(0.0f)
quad_TessCoord += gl_TessCoord[0] * (0,0)
quad_TessCoord += gl_TessCoord[1] * (0,1)
quad_TessCoord += gl_TessCoord[2] * (1,0)
```
または
```
vec2 quad_TessCoord = vec2(0.0f)
quad_TessCoord += gl_TessCoord[0] * (1,1)
quad_TessCoord += gl_TessCoord[1] * (1,0)
quad_TessCoord += gl_TessCoord[2] * (0,1)
```
でQuad用のTessCoordに変換できるってわけです。
※ この順番かどうかはわからないので注意してください
Javaで文字列とバイト配列の相互変換を行うユーティリティクラス

StringByteUtil.java

```java
import java.nio.charset.Charset;
import java.nio.charset.StandardCharsets;

public class StringByteUtil {

    // デフォルト文字エンコーディング
    private static final Charset DEFAULT_CHARSET = StandardCharsets.UTF_8;

    /**
     * 文字列をバイト配列に変換します。
     *
     * @param str 変換する文字列
     * @param charsetName 使用する文字セット名（例: "UTF-8", "Shift_JIS"）
     * @return バイト配列（null入力時はnull）
     */
    public static byte[] toBytes(String str, String charsetName) {
        if (str == null) return null;
        Charset charset = getCharset(charsetName);
        return str.getBytes(charset);
    }

    /**
     * バイト配列を文字列に変換します。
     *
     * @param bytes 変換するバイト配列
     * @param charsetName 使用する文字セット名
     * @return 文字列（null入力時はnull）
     */
    public static String toString(byte[] bytes, String charsetName) {
        if (bytes == null) return null;
        Charset charset = getCharset(charsetName);
        return new String(bytes, charset);
    }

    /**
     * 文字セット名から Charset を取得します。
     * 無効な名
     * 前が指定された場合はデフォルト UTF-8 を使用します。
     *
     * @param charsetName 文字セット名
     * @return Charset インスタンス
     */
    private static Charset getCharset(String charsetName) {
        if (charsetName == null || charsetName.isEmpty()) {
            return DEFAULT_CHARSET;
        }
        try {
            return Charset.forName(charsetName);
        } catch (IllegalArgumentException e) {
            System.err.println("指定された文字コードが無効です: " + charsetName + "。UTF-8を使用します。");
            return DEFAULT_CHARSET;
        }
    }
}
```

実行例

```java
String original = "こんにちは世界";
String charset = "Shift_JIS";

byte[] bytes = StringByteUtil.toBytes(original, charset);
String restored = StringByteUtil.toString(bytes, charset);

System.out.println("元の文字列: " + original);
System.out.println("復元された文字列: " + restored);
```

```sh
元の文字列: こんにちは世界
復元された文字列: こんにちは世界
```
【VS Code】プロジェクト（ワークスペース）ごとにGitHub Copilotを無効にする方法

# 手順
1. 対象プロジェクトを VS Code で開く
まず、GitHub Copilot を無効にしたい VS Code のプロジェクト（ワークスペース）を開きます。

2. `.vscode` フォルダの確認または作成
プロジェクトのルートディレクトリ直下に、`.vscode` という名前のフォルダが存在するか確認しましょう。もし存在しない場合は、新しく作成してください。
```
your-project/
├── .vscode/  <-- ここに作成（なければ）
```
### `settings.json` ファイルの作成
作成した（または既存の）`.vscode` フォルダの中に、`settings.json` という名前のファイルを作成します。
```
your-project/
└── .vscode/
    └── settings.json  <-- このファイルを作成
```
### 設定の記述
`settings.json` ファイルを開き、以下の JSON 設定を記述します。
```JSON

{
    "github.copilot.enable": {
        "*": false
    }
}
```
`"github.copilot.enable"`: これは GitHub Copilot の有効/無効を制御する VS Code の設定キーです。
`"*": false:` この設定は「すべての言語に対して GitHub Copilot の機能を無効にする」ことを意味します。
### 特定の言語のみ無効にしたい場合

もし、特定の言語（例: Python ファイルのみ）で Copilot を無効にし、他の言語では有効のままにしたい場合は、以下のように記述します。

```JSON

{
    "github.copilot.enable": {
        "python": false, // Python ファイルのみCopilotを無効にする
        "*": true        // その他の言語ではCopilotを有効にする
    }
}
```
この例では、python の設定が * の設定よりも優先されます。
JavaでHttpHeaders型の変数 から特定のキーを削除するユーティリティクラス

HttpHeaderUtils.java
```java
import org.springframework.http.HttpHeaders;

import java.util.List;
import java.util.Iterator;

public class HttpHeaderUtils {

    public static void removeHeaders(HttpHeaders headers, List<String> removeKeys) {
        if (headers == null || removeKeys == null) {
            return;
        }

        // removeKeys をすべて小文字に変換して比較に使う
        List<String> lowerCaseRemoveKeys = removeKeys.stream()
                .map(String::toLowerCase)
                .toList();

        Iterator<String> iterator = headers.keySet().iterator();
        while (iterator.hasNext()) {
            String key = iterator.next();
            if (lowerCaseRemoveKeys.contains(key.toLowerCase())) {
                iterator.remove(); // ヘッダーから該当キーを削除
            }
        }
    }
}
```
headers.properties
```properties
# headers.properties
remove.keys=Accept-Encoding,Authorization,Content-Length,Host,Transfer-Encoding
```

HeaderPropertyLoader.java
例外処理はサンプルなので省略

```java
import java.util.Arrays;
import java.util.List;
import java.util.ResourceBundle;
import java.util.stream.Collectors;

public class HeaderPropertyLoader {

    private static final ResourceBundle bundle = ResourceBundle.getBundle("META-INF/spring/headers");

    public static List<String> getRemoveKeys() {
        String raw = bundle.getString("remove.keys");
        return Arrays.stream(raw.split(","))
                     .map(String::trim)
                     .collect(Collectors.toList());
    }
}
```

実行例

```java
HttpHeaders headers = new HttpHeaders();
headers.add("X-Remove-This", "value1");
headers.add("Keep-This", "value2");
headers.add(HttpHeaders.AUTHORIZATION, "value2");
headers.add(HttpHeaders.HOST, "value2");
headers.setContentLength(1);
headers.add(HttpHeaders.TRANSFER_ENCODING, "chunked");
headers.add(HttpHeaders.ACCEPT_ENCODING, "gzip, deflate");

List<String> removeKeys = HeaderPropertyLoader.getRemoveKeys();
HttpHeaderUtils.removeHeaders(headers, removeKeys);

System.out.println(headers); 
```

```sh
[X-Remove-This:"value1", Keep-This:"value2"]
```
【デジタル仮想量子アルゴリズム】のメモ

【量子アルゴリズムのための量子物理学メモ】
当ブログの文献は、量子アルゴリズムと日本の量子物理学の
発展のために筆者がまとめた私見をまとめました。
なお、量子アルゴリズムを実現するための文献なので
本来の量子物理学との齟齬を生じることがある事をご了承下さい。
引用、検証、実証はフリーですが引用者個人の責任で行って下さい。
詳細は、下記のお断わりをお読み下さい。

お断わり：
当ブログで記載されている文献は著作権フリーです。
引用は、筆者に断る必要は一切ありませんし、当ブログから引用した旨を
記載も一切必要ありません。
但し、当ブログの文献は筆者の私見です。
ですので引用者の個人の責任となる事をご了承下さい。
また、引用、論文、検証、実証等は、筆者に断る必要は一切ありませんが
同時に責任を一切放棄します。

今まで私が考えている量子アルゴリズムは既存のものと切り分けるために上記の名称で
呼ぶ事にします。

１．【デジタル仮想量子アルゴリズム】
【デジタル仮想量子アルゴリズム】とは、0と1のデジタル信号で量子物理学ロジックを
仮想的に実現するアルゴリズムです。

特徴は以下の通りです。
（１）デジタル仮想量子アルゴリズムは、ON(=0)/OFF(=1)の2進数デジタル信号を扱う。
　　　既存の量子アルゴリズムで虚数は、一切使用しない。
（２）【量子のもつれ（反射）】は、NOT論理計算で反転させて反転値を計算する。
（３）【拡散波動関数計算】は、確率値を論理計算（AND、OR、NOT）で実現する。
（４）【デジタル仮想量子マップ】で生成した量子値、反転値と確率値を記録する。
（５）初期の確率値はマップの個数で等分される。
　　　確率値は、オペレーター（操作者）によって変更できる。
（６）確率値を変更して【拡散波動関数計算】をして結果を新たな【デジタル仮想量子マップ】
　　　生成してへスナッピングする。　
（７）オペレーター（操作者）が【拡散波動関数計算】する度に【デジタル仮想量子マップ】
　　　がスナッピングされる。
Geminiでリスと遊ぶ魔法少女を描いてみた。

# 概要

Geminiでリスと遊ぶ魔法少女を描いてみました。

# 実装

プロンプトと実行結果は以下の通りでした。

```
聖なるリスと遊ぶ魔法少女を描いてください。
```

![聖なるリスと遊ぶ魔法少女_20250610.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3192024/0393fdb5-26a3-4c4c-a44d-7d1dcade46da.png)

# まとめ

可愛いかも。何かの役に立てばと。
Gemini API の実験的機能「URL context」を Node.js で試す

## はじめに

この記事は、以下の記事で扱っていた Gemini API の新機能や実験的機能などに関する話です。

- [【Google I/O 2025】 Live API の「Gemini 2.5 Flash Native Audio（モデル： gemini-2.5-flash-preview-native-audio-dialog）」を試す - Qiita](https://qiita.com/youtoy/items/85f35c69bd8e12a2ddbe)
- [【Google I/O 2025】 Gemini API ＋ Node.js で音声合成（TTS）を試す - Qiita](https://qiita.com/youtoy/items/433b567bb84672b264c7)
- [【Google I/O 2025】 API の無料枠で Gemini・Gemma の新モデルを試す（Node.js を利用） - Qiita](https://qiita.com/youtoy/items/714a1bd58a80f856663c)
- [Gemini API ＆ SDK が MCP 対応したので試す（Node.js を利用）【Google I/O 2025】 - Qiita](https://qiita.com/youtoy/items/fd1b123c3f7fc3516264)


### 今回試す内容（Gemini API の URL context）

今回は、実験的機能として提供されている以下の「URL context」を試します。

https://ai.google.dev/gemini-api/docs/url-context
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/50868/17c1db77-efe9-44c3-83d7-5ba23be62e7f.png)




## さっそく試す

さっそく試していきます。今回は、以下の「Code examples with URL context only」という項目のサンプルを使います。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/50868/483df970-a1ea-44b2-a3df-652d53f79a16.png)

https://ai.google.dev/gemini-api/docs/url-context#code-examples-url-context
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/50868/f8606d91-dc57-422f-a261-03ec7026d4bf.png)

Python などのサンプルもありますが、JavaScript のサンプルでやってみます。


### 下準備

この後の内容を進める前の下準備として、「パッケージのインストール」「APIキーの設定」を行います。

パッケージは [@google/genai](https://www.npmjs.com/package/@google/genai) を以下のコマンドでインストールします。

```zsh
npm i @google/genai
```

また APIキーの設定については、環境変数 GEMINI_API_KEY に Gemini の APIキーをセットします。


### コードと実行結果

以下に、お試し用に使ったコードを示します。

```javascript
import { GoogleGenAI } from "@google/genai";

const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY });

const urls = [
  "https://qiita.com/youtoy/items/85f35c69bd8e12a2ddbe",
  "https://qiita.com/youtoy/items/433b567bb84672b264c7",
];

async function main() {
  const response = await ai.models.generateContent({
    model: "gemini-2.5-flash-preview-05-20",
    contents: [
      `${urls[0]} と ${urls[1]} の内容を比較して、共通点と違いをそれぞれ短く説明してください。`,
    ],
    config: {
      tools: [{ urlContext: {} }],
    },
  });
  console.log(response.text);
  console.log(response.candidates[0].urlContextMetadata);
}

await main();
```

冒頭に掲載していた Qiitaの記事（過去に書いた複数の記事）の中で、2つの記事を選んでそれらを比較してもらいました。


#### 実行結果

上記を実行した結果は、以下のとおりです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/50868/92b7e307-7af5-4f88-b467-3c7b630176e3.png)

2つの記事の内容を読み込んだ上で、それらの内容の共通点・差異を見つけ出し、さらに返答として示してくれていることを確認できました。
Spring Boot（非GraalVM）をAWSで動かす際の選択肢と現実的な判断軸

## 前書き
JJUG CCC（Japan Java User Group Cross Community Conference）に参加し、ある企業のブースで展示されていたアーキテクチャ図を見て疑問を持ち、スタッフの方にお話を伺いました。
その際、ECS Fargate を用いて Spring Boot アプリケーションを運用しているという事例が紹介されていました。

ちょうど最近 AWS 認定ソリューションアーキテクト – アソシエイト（SAA）を取得したこともあり、ある種のアウトプットとして、考察を記事としてまとめました。


- ECS Fargate（Elastic Container Service Fargate：コンテナのサーバレス実行）を用いて、Spring Bootアプリを稼働させている
- アクセスは一日のスケジュールから予測できるため、コールドスタート（初回起動の遅延）は大きな問題にはならない
- よって、予測ベースの時間帯スケーリングで十分対応可能であり、ECS採用の合理性が高い

「コールドスタートが問題になるのでは？」という疑問が発端でしたが、実際の業務要件を踏まえると、実運用されているもので十分であるという結論に至りました。
考えるにあたって比較した選択肢を以下に記します。


## 選択肢の比較と技術検討
以下に、AWS上で Spring Boot（非GraalVM）を実行するための主要な手段を比較・整理します。

### 選択肢1: EC2（Elastic Compute Cloud）

- **概要**: 仮想マシン型インスタンスで、自由度と制御性が高い。
- **Spring Bootとの相性**: JVMアプリに適しており、非GraalVMでも問題なし。
- **スケーリング**: Auto Scaling Group（ASG）を使ったインスタンス増減。
- **運用負荷**: OSパッチ、セキュリティ、モニタリング等、管理作業が必要。
- **適したケース**:
  - JVMウォームアップが必要な大規模アプリ
  - 高負荷 or 安定トラフィック
  - ミドルウェア制御が必要
  - オンプレから直接移行する場合もこれが適している
- **補足**: オートスケーリング等の制御を行うのはECS Fargateより難しい

---

### 選択肢2: ECS Fargate

- **概要**: サーバレスでコンテナを実行可能なフルマネージドサービス。
- **Spring Bootとの相性**: 非常駐時のコールドスタートは問題だが、常駐なら問題にならない。
- **スケーリング**: タスク単位でのスケーリングが可能。
- **起動時間**: 数十秒～1分（DockerイメージのpullとJVMウォームアップを含む）。
- **運用負荷**: OSやインスタンス管理不要。
- **適したケース**:
  - 常駐API、バッチなど予測可能な負荷
  - インフラ構成のコード化（IaC：Infrastructure as Code）
- **補足**: サーバーレスもできるので、運用コストを最小限に抑えることも可能。ただし、SpringBoot + 非GraalVMだとSpringの立ち上げとDBコネクションプールの作成にかなり時間がかかるので現実的ではない。

### 選択肢3: AWS Lambda

- **概要**: 関数単位で実行するFaaS（Function as a Service）。
- **Spring Bootとの相性**: JVM起動が遅く、非GraalVMでは致命的。
- **対応策**:
  - **GraalVM + Native Image**（AOT：Ahead Of Time コンパイル）
  - **SnapStart**（AWSのコールドスタート対策、ただしサポート限定）

---

### 選択肢4: AWS App Runner

- **概要**: ソースコードやコンテナイメージを即座にWebアプリ化。
- **Spring Bootとの相性**: 常時稼働なら問題なし。
- **スケーリング**: 簡易的なオートスケーリングあり。
- **利点**:
  - GitHubやECR（Elastic Container Registry）からの自動デプロイ
  - 開発者フレンドリー
- **適したケース**:
  - 手軽なホスティングをしたい
  - 初期開発・検証段階
  - CI/CDパイプラインとの統合重視

---

### 選択肢5: Elastic Beanstalk（EBS）

- **概要**: Java WAR/JARファイルをアップロードするだけで環境構築できるPaaS。
- **Spring Bootとの相性**: 特別な調整不要で即実行。
- **スケーリング**: 自動スケーリング可能。
- **運用負荷**: ブラックボックス性あり、細かいチューニングが難しい。
- **適したケース**:
  - 中小規模のWebアプリ
  - AWS初心者
  - 環境構築に時間をかけたくない場合

## まとめ

非GraalVMのSpring BootをAWSで実行する場合、以下の選択肢が現実的かと思います。

| 用途                          | 推奨選択肢          |
|-------------------------------|---------------------|
| 常時稼働・インフラ制御重視    | EC2                |
| 常時稼働・運用簡素化重視      | ECS Fargate        |
| 初期開発・お手軽実行          | App Runner / Beanstalk|

今回のブース展示では、常時稼働＋予測可能なトラフィックという条件下において、ECS Fargate の選定は合理的であると感じました。
スパイク的なアクセスがない場合、スケジューリングによるタスク起動で対応可能となり、コールドスタートの遅延問題も回避できます。
Spring Boot を Lambda で運用するのは、非GraalVMでは依然として非現実的です。

なお、他社クラウド（GCP Cloud Run, Azure Container Apps 等）においても、同様の考慮が必要です。GCPのApp Engineでも類似の課題に直面した経験があり、各クラウドに共通する検討ポイントであると感じました。

Javaでサーバーレスを考える場合は、Quarkus や Micronaut など軽量なフレームワークの利用も現実的な選択肢になるかと思います。
baserCMS5でローカル環境構築にDDEVを使う

## 概要
baserCMS5 の公式ドキュメントでは、ローカル開発環境の構築に docker-compose を使用する方法が紹介されています。
実際に私もこの方法を使って baserCMS のプラグイン開発を行ってきました。

参考:
https://baserproject.github.io/5/introduce/build_local_env

一方、他の CMS 開発では DDEV を利用しています。
というのも、DDEV には WordPress・Drupal・Laravel・CakePHP など
各フレームワーク専用のテンプレートが提供されており、開発環境の立ち上げが非常に簡単だからです。

実は、DDEV の公式テンプレートには CakePHP 向けのプリセットがあります。
つまり、baserCMS5 が CakePHP5 ベースで構築されていることを踏まえると、
このテンプレートを流用するだけで DDEV 上で baserCMS5 をそのまま動作させることができると考えました。
そして実際に検証した結果、問題なく動作したため、本記事ではその手順を紹介します。

## DDEVとは？
DDEV は、PHP や主要 CMS（WordPress、Drupal、Laravel、CakePHP など）のローカル開発環境を Docker ベースで簡易に構築・管理できるオープンソースツールです。

- Docker を使って仮想環境を自動構築
- CMSやPHPフレームワークに最適化(公式が提供しているテンプレートがある)
- ddev start で即ローカル環境起動
- 複数プロジェクトを簡単に切り替え可能
- ngrok、Xdebug、phpMyAdmin などもワンコマンド導入可能

## DDEVのインストール方法
こちらを参照してもらえばmacなら、簡単にインストールが可能です。
※ Windows: Chocolatey 経由でのインストールが推奨されていますが、初回セットアップに多少苦労する可能性があります(というか以前にwindowsで実験した時は苦労した...)

https://ddev.readthedocs.io/en/stable/

## cakephpの環境立ち上げ
### 公式のインストールテンプレート

https://ddev.readthedocs.io/en/stable/users/quickstart/#cakephp

※composerからcakeのプロジェクトの作成は不要


### 1. baserCMS5 プロジェクトの取得

任意のディレクトリで baserCMS のプロジェクトを clone します。

```bash
git clone git@github.com:baserproject/basercms.git
```

### 2. DDEV の初期設定（CakePHP プリセット）

```bash
ddev config --project-type=cakephp --docroot=webroot
```

- `docroot` は `webroot` を指定
- `.ddev/config.yaml` を開き、以下の設定を有効化：

```yaml
xdebug_enabled: true
```

### 3. 環境の起動と依存パッケージのインストール

```bash
ddev start
ddev composer install
```

### 4. アプリケーションをブラウザで確認

```bash
ddev launch
```

ちなみに、ブラウザを開かずに現在の DDEV プロジェクトのサービス状態を確認したい場合は以下で確認できます

```bash
ddev status
```


## phpMyAdmin の導入

```bash
ddev get ddev/ddev-phpmyadmin
ddev restart
# ddev statusでphpmyadminの起動状況を確認
ddev status
```

これだけでphpmyadminがインストールできます。

## おわりに
独自のCMSならテンプレートは用意されていないので...
フレームワークの上に載っていることで、こういったところでも、
恩恵に授かれるところがbasercmsの強みだと再認識しました。
ReactのStrictModeとは？副作用がバレるレンダー2回の謎に迫る！

# はじめに

Reactを使っていると、開発中に思わぬ **「2回レンダーされる」** 現象に出会ったことはありませんか？それ、もしかしたら `StrictMode` が原因かもしれません。

本記事では、Reactの`StrictMode`が何をしているのか、なぜレンダーが2回発生するのか、パフォーマンスへの影響は？といった疑問に答えていきます。


# StrictModeってなに？

`StrictMode` は、Reactが提供する**開発モード専用の検証ツール**です。

```tsx
import { StrictMode } from 'react';
import { createRoot } from 'react-dom/client';
import App from './App';

const root = createRoot(document.getElementById('root')!);

root.render(
  <StrictMode>
    <App />
  </StrictMode>
);
```

**✅ やってくれること**

* 副作用（`useEffect` など）の**意図しない挙動**を検出
* コンポーネントの **純粋性（Pure Component）** のチェック
* 非推奨APIの使用を警告


# レンダーが2回起きるのはなぜ？

`StrictMode`を使うと、**関数コンポーネントや`useEffect`などの副作用が一度「アンマウント→再マウント」されます**。これは意図的な仕様です。

```tsx
function Wave() {
  useEffect(() => {
    console.log("👋 Wave mounted");

    return () => {
      console.log("👋 Wave unmounted");
    };
  }, []);

  return <div>👋</div>;
}
```

StrictModeでこのコンポーネントを使うと、**以下のログが出ます**：

```
👋 Wave mounted
👋 Wave unmounted
👋 Wave mounted
```

これは、「副作用が再実行されても安全か？」を検証するための**開発用チェック**です。

**⚠️ パフォーマンスへの影響は？**

心配しなくて大丈夫です。`StrictMode`の影響は**開発モードだけ**です。**本番ビルドでは無効化され、自動的に除外されます。**

# どう使えばいいの？

基本的に、開発中は`StrictMode`を**有効にしておくのが推奨**されます。

**✔️ こんなときに便利**

* useEffectやuseRefの扱いに自信がないとき
* チーム開発で不具合の原因を早期発見したいとき
* 複雑な状態管理を使っていて、レンダーの副作用が気になるとき

| ポイント                    | 説明                    |
| ----------------------- | --------------------- |
| ✅ `StrictMode`は開発専用     | 本番には影響なし              |
| 🔁 副作用を検証するために2回レンダーされる | 安全性・純粋性を確認できる         |
| 🛠️ 有効にしても問題ないアプリが理想    | Reactの思想「UIは状態の関数」に合致 |

# おわりに

Reactの`StrictMode`は、開発者が**より堅牢なコンポーネント設計**をするための道しるべです。最初はレンダーが2回起きるのに戸惑うかもしれませんが、「UIは状態の関数」というReactの哲学を実感できるよい機会でもあります。
自己インダクタンス の理論計算


# 📘 電源電圧 $E$ の測定と自己インダクタンス $L$ の理論計算

コイル電圧 $E_{\text{rms}}$ を実測し、以下の理論式と補正係数を用いて自己インダクタンス $L$ を求める。

---

## 🔶 1. 自己インダクタンスの理論式（式 1.25）

$$
L = \mu \frac{\pi a^2 N^2}{l} \cdot k
$$

| 記号    | 意味                                           |
| :---- | :------------------------------------------- |
| $\mu$ | 真空の透磁率 $4\pi \times 10^{-7} \, \mathrm{H/m}$ |
| $a$   | コイルの平均半径（m）                                  |
| $N$   | コイルの巻数（Turn）                                 |
| $l$   | コイルの長さ（m）                                    |
| $k$   | 補正係数（形状依存）。表1.2より求める。                        |

---

## 🔶 2. 表：補正係数 $k$

| $\frac{2a}{l}$ | 0.0   | 0.2   | 0.4   | 0.6   | 0.8   | 1.0   | 1.2   | 1.4   | 1.6   | 1.8   | 2.0   |
| -------------- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- |
| $k$            | 1.000 | 0.945 | 0.884 | 0.818 | 0.748 | 0.640 | 0.630 | 0.620 | 0.580 | 0.550 | 0.520 |

> この表は、無次元比 $\frac{2a}{l}$ に対応する形状補正係数 $k$ を示す。間の値は補間で推定。

---

## 🔶 3. 補間式（表にない場合）

### ◆ 2点補間（線形補間）

$$
f(x) = \frac{(x - x_2)}{(x_1 - x_2)}f(x_1) + \frac{(x - x_1)}{(x_2 - x_1)}f(x_2)
\tag{1.26}
$$

### ◆ 3点補間（2次補間）

$$
f(x) = \sum_{i=1}^{3} \left( \prod_{\substack{j=1\\j\ne i}}^{3} \frac{x - x_j}{x_i - x_j} \right) f(x_i)
\tag{1.27}
$$

> 補間は $x = \frac{2a}{l}$、出力は対応する $k$

---

## 🔶 4. コイルの仕様

| 項目        | 単位     | コイル1                  | コイル2  |
| --------- | ------ | --------------------- | ----- |
| 透磁率 $\mu$ | \[H/m] | $4\pi \times 10^{-7}$ | 同左    |
| 平均半径 $a$  | \[m]   | 0.030                 | 0.030 |
| 巻数 $N$    | Turn   | 600                   | 800   |
| コイル長 $l$  | \[m]   | 0.050                 | 0.030 |

---

## ✅ 計算手順（例：コイル1）

1. $\frac{2a}{l} = \frac{2 \times 0.030}{0.050} = 1.20$
2. 表より $k = 0.630$
3. 式 (1.25) に代入して $L$ を求める：

$$
L = 4\pi \times 10^{-7} \cdot \frac{\pi \cdot (0.03)^2 \cdot 600^2}{0.05} \cdot 0.630
$$

---

## 🧠 ポイントまとめ

* 自己インダクタンスは形状によって変わるため、補正係数 $k$ が不可欠。
* 表にない $\frac{2a}{l}$ 値には **ラグランジュ補間** を用いる。
* 実験レポートでは、\*\*理論値と実測値の比較（誤差計算）\*\*を行うと良い。

---
第1章 データ理解と EDA

# 第1章 データ理解と EDA

## 1. はじめに

Titanicのデータセットは、乗客の属性（性別・年齢・階級など）から生存したかどうかを予測する二値分類タスクです。本章では、建模（モデリング）に入る前段階として、各変数の内容を把握し、データの傾向や欠損、潜在的な特徴量の可能性を探ることを目的とします。

EDA（Exploratory Data Analysis、探索的データ分析）は、モデル構築のための「地図作り」にあたる工程です。この段階で、意味のある変数やノイズになり得る変数を見分け、前処理や特徴量エンジニアリングの方針を立てておくことが、最終的な精度向上につながります。

本章では以下の点を中心に分析を進めていきます：

- データの基本構造（行数・列数、型）と統計的な要約
- 欠損値の有無とその可視化
- 各変数と生存の関係性の可視化と仮説形成
- モデルに活用できそうな特徴量の兆し

それでは、まずはデータの読み込みと構造の確認から始めましょう。

### 1. 各列（変数）の確認と要約

| 列名        | 内容                     | 確認ポイント                              |
|-------------|--------------------------|-------------------------------------------|
| PassengerId | 乗客ID                   | 特に使わない（識別子）                   |
| Survived    | 目的変数                 | 0＝死亡, 1＝生存                          |
| Pclass      | 等級                     | カテゴリ変数                              |
| Name        | 氏名                     | 整形すれば「称号（Mr/Mrsなど）」が得られる |
| Sex         | 性別                     | 生存率に強い影響                          |
| Age         | 年齢                     | 欠損あり、分布が鍵                        |
| SibSp       | 兄弟・配偶者の数         | 家族構成との関係性                        |
| Parch       | 親・子供の数             | 上に同じく                                |
| Ticket      | チケット番号             | 情報量は低いが加工次第で使えることも      |
| Fare        | 料金                     | 欠損なし・分布確認                        |
| Cabin       | 客室番号                 | 欠損多数・有無で扱うか検討                |
| Embarked    | 乗船地                   | 欠損あり・カテゴリ変数                    |

## 2. データの基本構造（行数・列数、型）と統計的な要約

- このデータセットは891行12列から成る。
- `Survived` は目的変数で、`int64` 型（0 or 1）で構成されている。
- `Age` に欠損が存在する（117/891がnull）。
- `Cabin` は欠損が多く、扱いに工夫が必要(687/891がnull)
- `Embarked`は(2/891がnull)
- `Fare` の最大値が高く、平均との乖離が大きいため外れ値の可能性あり。

### 生存者と死亡者の分布

Titanicデータセットの目的変数 `Survived` の分布は以下のようになっており、死亡が約6割、生存が約4割と軽度のクラス不均衡があることがわかります。

![survival_distribution.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4109160/79aac20e-4d46-413f-8813-e86748847394.png)

次の記事 👉 [第2章：前処理と特徴量エンジニアリングはこちら](https://qiita.com/ota_keito/items/bb0a7775bc0efe6369b2)
良い例と悪い例でみるREST API

# REST APIとは？

一行で言うと
REST APIとは、**RESTという設計ルールに従って作られたWeb API**のことです。
つまりRESTはあくまで**考え方**のことです。

## RESTとは？

REST（Representational State Transfer）とは、Webのリソース（情報）に対する**一貫したアクセスルール**を定義する考え方です。

ざっくり言えば、
「リソースをHTTPを使って扱うための決まりごと」です。
この
*>>リソースをHTTPを使って扱うための決まりごと*
にはいろんな種類があり、どのような考え方を利用してAPI設計をするかで異なります。
(REST以外にも,SOAP API、Graph QL、 gRPCなどがあります。)

---

## RESTの設計原則（超ざっくりにとどめます）

1. **リソースはURIで表現する**
   　例：映画情報 → `/movies`

2. **リソースに対する操作はHTTPメソッドで表す(URIで表そうとしない)**
   　- `GET`：取得
   　- `POST`：新規作成
   　- `PUT` or `PATCH`：更新
   　- `DELETE`：削除

3. **ステートレス**
   　→ サーバーはクライアントの状態を記憶しない。

4. **統一インターフェース**
   　→ どのAPIでも同じ操作ルール（GETで取得、POSTで登録など）を守る。

---

## movieリソースのCRUD操作例（正しいREST API）

```markdown
| URI            | HTTP method | していること
|----------------|-------------|-------------
| /movies        | GET         | 全映画を取得
| /movies        | POST        | 映画情報を新規に追加
| /movies/:id    | GET         | 特定の映画を取得
| /movies/:id    | PATCH       | 特定の映画情報を更新
| /movies/       | PUT         | 全映画に対しての更新
| /movies/:id    | DELETE      | 特定の映画情報を削除

```

▼PUTとPATCHの違いについて

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4001794/780bf097-1b6c-4c60-b1e6-9be02eb6ea65.png)

リソース全体に対する更新や変更　　→　PUT
リソースの一部の部部に対する変更　→　PATCH
とするのがよいみたいです。

引用元

https://www.geeksforgeeks.org/javascript/difference-between-put-and-patch-request/
    
---

## バッドな例（非RESTful）

以下のようなAPI設計は、RESTの原則に反していて**分かりづらく、保守性が低い**です。

```markdown
| URI                    | HTTP method |
|------------------------|-------------|
| /getAllMovies          | POST        |
| /createNewMovie        | GET         |
| /updateMovieData       | POST        |
| /deleteMovieById       | POST        |
```

### 問題点：

* 操作がHTTPメソッドではなく**URIに埋め込まれている**
* `GET`で「作成」など、HTTPメソッドの意味を無視している
* URIの構造に**リソースの概念がない**
---
Reactは子コンポーネントをなぜ再レンダーするのか？React.memoで制御する方法も紹介

# はじめに

Reactで開発していて、こんな経験はありませんか？

> 「親コンポーネントのstateを更新しただけなのに、関係なさそうな子コンポーネントまで再レンダーされてる…？」

今回は、**propsを受け取っていない子コンポーネントが再レンダーされる理由**と、**それを防ぐ方法（`React.memo`）**を、できるだけシンプルなコード例と**ログ出力の挙動**を使って紹介します。

# 実験：最小構成で確認してみよう

まずは以下の2つのコンポーネントを見てください。

```jsx:App.jsx
import React, { useState } from "react";
import Message from "./Message";

export default function App() {
  const [count, setCount] = useState(0);

  const handleClick = () => {
    setCount((prev) => prev + 1);
  };

  return (
    <div>
      <h1>Count: {count}</h1>
      <button onClick={handleClick}>+1</button>
      <Message />
    </div>
  );
}
```

```jsx:Message.js
import React from "react";

export default function Message() {
  console.log("👋 Message rendered");
  return <p>Hello!</p>;
}
```

* `App` はカウント用の state（`count`）を持っています。
* `Message` は props を一切受け取っていません。

**🖥 ログ出力の挙動**

ブラウザの開発者ツールのコンソールを開いて、ボタンを3回クリックしてみましょう。

```log
👋 Message rendered
👋 Message rendered
👋 Message rendered
👋 Message rendered
```

※ 初回マウント + クリック3回分 = 計4回のログが出力されます。

# なぜ props がないのに再レンダーされるの？

Reactの基本ルールはこうです：

> **stateが変わると、そのコンポーネントとすべての子が再レンダーされる**

つまり、たとえ `Message` に props がなく、何も変化していなくても、`App` の再レンダーに巻き込まれてしまうのです。

# `React.memo` で再レンダーを防ぐ

このような「見た目もpropsも変わらないのに毎回レンダーされる」のは、場合によってはパフォーマンスの無駄になります。

そんなときに使えるのが `React.memo` です。

```jsx:Message.jsx
import React from "react";

function Message() {
  console.log("👋 Message rendered");
  return <p>Hello!</p>;
}

export default React.memo(Message);
```

**✅ ログ出力の変化を確認してみよう**

`React.memo` 適用後に同じようにボタンを3回クリックすると、コンソールは次のようになります。

```log
👋 Message rendered
```

たった1回だけです。これは、**初回マウント時のログのみ**で、以降は再レンダーされていないことを意味します。

# `React.memo` は何にでも使ってよい？

いいえ。次のようなケースで使うのが効果的です。

* **重たい処理を行っているコンポーネント**
* **再レンダーのコストが大きいUI**
* **レンダーの頻度を下げたい場合**

軽いUIであれば無理に使う必要はありません。**パフォーマンスのボトルネックになってから導入する方が自然**です。

#  まとめ

* 親コンポーネントのstateが変わると、**propsが変わらなくても子も再レンダーされる**
* 小さなアプリでは問題になりにくいが、大きなアプリでは再レンダーのコストが気になる場合もある
* `React.memo` を使うと、**propsが変わらない限り再レンダーを防ぐことができる**
プライベートクラウドとオンプレミスの違い

## プライベートクラウドとは？
自社専用のクラウド環境のこと。
- サーバやネットワーク機器も自分で用意 → **オンプレミス型**
- クラウド事業者が用意 → **ホスティング型**

## オンプレミス型プライベートクラウド=オンプレミス？？

ではなく...
- クラウド環境を構築 → **オンプレミス型プライベートクラウド**
- 物理サーバで頑張る → **オンプレミス**
zipファイルの解凍コマンド

行いたい処理をクリックしてください．

1. [zipファイルを解凍](#zipファイルを解凍する場合)
1. [すべてのzipファイルを解凍](#すべてのzipファイルを解凍する場合)
1. [特定のフォルダーにzipファイルを解凍](#特定のzipファイルを特定のディレクトリーへ解凍する場合)
1. [特定のフォルダーにすべてのzipファイルを解凍](#すべてのzipファイルを特定のディレクトリーへ解凍する場合)


<br>

#### zipファイルを解凍する場合
```bash
unzip file_name.zip
```
※コードを実行したディレクトリー上に解凍される
<br>


#### すべてのzipファイルを解凍する場合
```bash
unzip "*.zip"
```
※コードを実行したディレクトリー上に解凍される
<br>


#### 特定のzipファイルを特定のディレクトリーへ解凍する場合
```bash
unzip -d directory_name sample.zip 
```
<br>

#### すべてのzipファイルを特定のディレクトリーへ解凍する場合
```bash
unzip -d directory_name "*.zip" 
```
Power Appsでmailtoを使う時の注意点

## 緒言
Power Appsから余計なコネクタ使わずにさらっとメール配信できる```mailto```。結論から言うと、```EncodeUrl()```しておけば解決！

## 問題点と解決策
こんなケースで、
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3670355/9e731d93-dae0-469f-8f3f-8e2d782e1615.png)

### ダメな例
```
Launch($"mailto:[メールアドレス]?subject=P & Gってなんの略?&body=答えはこちら%0A{ThisItem.url}")
```
日本語は危険。&は絶対ダメ。下図のようになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3670355/8ff31640-0e8f-4ac8-803e-f674dbbde8c3.png)

### 良い例
```
Launch($"mailto:[メールアドレス]?subject={EncodeUrl("P & Gってなんの略?")}&body={EncodeUrl("答えはこちら")}%0A{EncodeUrl(ThisItem.url)}")
```
日本語もurlもエンコード。下図のようにキッチリ。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3670355/e426ad37-2b5c-4645-8991-be43ddab6430.png)

## 結言
転ばぬ先のEncode。
PostgreSQL で Read-Only なユーザを作る

PostgreSQL で Read-Only なユーザを作るたびに「どうやって作るんだっけ？」となって調べているのでいい加減まとめておこうと思った次第だが、書いてみたらわざわざまとめるほどでもなかった...。

``` sql
CREATE USER readonly PASSWORD 'password';
GRANT pg_read_all_data TO readonly;
```

昔はもっと面倒な手順があったが、PostgreSQL 14 以降では `pg_read_all_data` role が使えるようになってめちゃくちゃ簡単になった。[^predefined-roles] いい時代になった。

ちなみに「データの書き込みができる」ようにしたければ `pg_write_all_data` role も GRANT すればよい。

また「GRANT したあとで作成したテーブルやスキーマに対しては権限付くのだっけ？」と気になって試してみたが問題なさそうだった。

| 操作 | `pg_read_all_data` | `pg_write_all_data` |
|---|:---:|:---:|
| `USAGE` | ◯ | ◯ |
| `SELECT` | ◯ | - |
| `INSERT` `UPDATE` `DELETE` | - | ◯ |
| `TRUNCATE` | - | - |
| `CREATE` `ALTER` `DROP` | - | - |
| `GRANT` `REVOKE` | - | - |

[^predefined-roles]: [PostgreSQL: Documentation: 17: 21.5. Predefined Roles](https://www.postgresql.org/docs/17/predefined-roles.html)
Cache-Controlヘッダとキャッシュを防ぐ方法についてまとめてみる

## そもそも、Cache-Controlヘッダとは？
Cache-Controlヘッダは、ブラウザやCDN等のプロキシサーバなどに対して、コンテンツをどのようにキャッシュするかの指示を与えるためのHTTPヘッダです。

ブラウザ、CDN、プロキシサーバなどに「このデータはどのくらい保存していいか」「いつ再取得すべきか」などのルールを伝える役割を持ちます。

これにより、Webアプリの高速化、セキュリティ、サーバ負荷軽減を期待できます。

ただし、キャッシュを禁止すべきケースもあります。
例えば、ログイン後のマイページなどのキャッシュがCDN等に残存していた場合は、誤って他ユーザーに表示されるリスクがあります。
このようなケースではキャッシュを残さないように設定する必要があります。


## 基本構文
Cache-Controlヘッダは下記のように記載します。
````
Cache-Control: ディレクティブA, ディレクティブB, ...
````
具体例として、下記のように記載します。
````:例
Cache-Control: no-cache, no-store, must-revalidate
````

### 主なディレクティブ


| ディレクティブ名      | 説明 |
|-----------------------|-------------------------------------------------------------|
| `no-cache`            | キャッシュされた内容の使用前に、必ずサーバーへ確認を要求する |
| `no-store`            | コンテンツをキャッシュに格納しない |
| `must-revalidate`     | 有効期限切れのキャッシュを利用する場合は必ずオリジンに問い合わせを行う |
| `public`              | 共有キャッシュ（プロキシなど）による保存を許可 |
| `private`             | ローカルへのキャッシュ格納のみ許可（共有キャッシュ禁止）     |
| `max-age=秒数`        | キャッシュの有効期限（秒単位）                               |
| `s-maxage=秒数`       | CDNやプロキシ用の `max-age` 指定（`max-age` より優先）       |
| `immutable`           | リソースが絶対に変わらないことを示す（再検証不要）

## キャッシュを防ぐにはどうすべきか？
上記記載を踏まえ、HTTPヘッダを設定する際にキャッシュを防ぐにはどうすべきなのか考えてみました。

結果、`no-store` があれば最低限のキャッシュによるセキュリティ対策は考慮されているものの、各CDNやProxy上でのディレクティブの解釈や仕様のブレが発生します。

この場合、`no-store` のみでは不十分な可能性があるため、`private, no-cache, no-store, must-revalidate `の4つを指定すること必要があるようです。

このため、キャッシュをどうしても禁止したい、防ぎたい場合には、`private, no-cache, no-store, must-revalidate `の4つを指定して、キャッシュをProxy上に残さない設定を忘れないようにしましょう。

### 【参考】
1. https://turningp.jp/network_and_security/http_header-cache
2. https://developer.mozilla.org/ja/docs/Web/HTTP/Guides/Caching#%E3%82%AD%E3%83%A3%E3%83%83%E3%82%B7%E3%83%A5%E3%81%97%E3%81%AA%E3%81%84
Kaggle Titanicで0.80突破を目指す実践ノート 序章

# Kaggle Titanicで0.80突破を目指す実践ノート 序章

## はじめに

KaggleのTitanic生存予測コンペティションは、データサイエンスの基礎を総合的に学べる絶好の教材です。本シリーズでは、0.80 以上の Public Score を目指して実践的なワークフローを段階的に解説します。

## 目標と評価指標

* Public Leaderboard で 0.80000 以上の Accuracy を達成する
* LightGBM やスタッキングを用いたアンサンブル学習で再現性のあるパイプラインを構築する

## 使用ツールと環境

* Python 3.11
* pandas 2.x / numpy 2.x
* matplotlib / seaborn
* scikit-learn 1.5
* lightGBM 4.x
* Jupyter Notebook もしくは Kaggle Notebook

## シリーズ全体構成

1. [第1章 データ理解と EDA（Exploratory Data Analysis）](https://qiita.com/ota_keito/items/bdb11338dcc857b4f7bb)
2. 第2章 前処理と特徴量エンジニアリング
3. 第3章 ベースラインモデルの構築
4. 第4章 高精度モデルとハイパーパラメータ最適化
5. 第5章 提出結果と考察（総括）

各章は独立した Qiita 記事として公開し、本序章から相互リンクで移動できるようにします。

## 公開リポジトリ

コード全体は GitHub で公開予定です。URL は記事公開後にここに追記します。

## 本シリーズで得られること

* データの可視化と要約統計の実践方法
* 欠損値補完とカテゴリ変数処理のベストプラクティス
* 複数モデルを比較し、アンサンブルする手法
* Leaderboard スコア向上のための実験・検証の進め方

## 免責事項

本記事は学習目的の情報提供を目的としています。実務環境での利用は自己責任でお願いします。

---

次の記事: 👉 [第1章：データ理解とEDAはこちら](https://qiita.com/ota_keito/items/bdb11338dcc857b4f7bb)
スクリプトの調査・解析のやり方

データベースの初心者です。
今日も仕事で１日長いスクリプトを読んでいたので、反省を書いておきます。
１日かけて１つぐらいしか潰せなかったので、もっと効率よくできたと反省しています。

# とりあえず読んでみる
ざっと見て、問題のありそうなところを洗い出します。
成果物として可視化できるようエクセルに書きましょう。
行数、推論、仮説程度はメモをしておきましょう。
nullや空白ないか？ 変なサブクエリ書いてないか？
グループ化は適切か？
変更による不具合が出ている場合は、バージョン管理から変更前と変更後を落としてきます。
VisualStudioCordのcompare機能は役に立ちます。

# 書き換えてみる
問題のありそうなところを書き換えて、実行してみます。当たったらラッキー程度です。

# データをよく見てみる
エクセルに貼ってフィルターで確認。
目視で確認。半角スペース' 'とか'文字列の後に空白   　'とか、割と分かりやすいのがあるかもしれません。よく見ないとだめです。

# データを追ってみる
たぶんデータベースはこれがいちばん大切です。
スクリプトを解体して、適当なSQL作って試すしかないです。
どこまで正しい値をとれていて、どこからバグっているのかを見極めましょう。
これだけで原因個所を特定できます。
ただレコードが何百万件もあると時間かかるので、適当にデータ絞ってやるのも必要です。
急ぎの時もあるので、時短のテクニックも覚える必要があります。
ひとつのスクリプトに三日ぐらいかけられる状況なら時間かけても構わないです。

# 上司の指示書を疑え
今日の指示書は、主語が省略されており、分かりづらかったです。
主語がどれなのかよく確認をする癖をつけたほうが、いい気がします。
上司も忙しくて意識朦朧としながら書いていること~~が多い~~もあると思いますので、自分が指示を補完するという姿勢は大切だと思われます。

反省は以上です。明日も頑張ります。
【競技プログラミング】AtCoder Beginner Contest 382問題_解法イメージ

# 既存投稿一覧ページへのリンク
[一覧ページ](https://qiita.com/o_chan_t/items/fc759695acfaef8df2cc)

# C問題解法アプローチ

https://atcoder.jp/contests/abc382/tasks/abc382_c

ナンバリングと美食度を降順に並べて解こうと思ってたけど、それだと普通にTLEしそう。
この問題から二分探索の発想は普通に出てこなかった・・・。

<iframe width="560" height="315" src="https://www.youtube.com/embed/xkxD0P1io7Y?si=2Z3ol78YnLpMETbb&amp;start=1885" 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>

最近、漫画熱が再燃してきてきたせいで、この問題読んだ瞬間「鉄鍋のジャン」や「食戟のソーマ」を思い出した。そもそも、「食戟のソーマ」が最近の漫画というカテゴリなんだけど、もう6年前に完了しているとかビックリですわ。葬送のフリーレンが始まるより、食戟のソーマが完結した方が早いのね。
AtCoderの問題を具体化する際、漫画の記憶年表にして出題してみたら面白そうな問題が出来上がるかも。ChatGPTとか使えば作れそうな気もするけど。

## 例1
美食度と美味しさが与えられる
![1uR9lRq9FMefGhit.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/530912/7bb7917e-6c2d-4782-95d0-e77dadac9277.png)

前に座っている人より美食度が高い人は寿司を食べられないので、前の人と同じ美食度に置き換える。
![2N8GneIT2yihyd35.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/530912/1c64a238-52f5-417e-ad30-65519b193196.png)

（前の人より美食度を小さくしてしまうと、二分探索で面倒になるので、同じ美食度にする）
→ 食べられる皿の数に制限を設けたり、並び順が円形で、取る順番を保持するようにしたら、若干難易度があがるのかな？少なくとも二分探索では解けなさそう。

各皿ごとに二分探索を行い、何番目の人に食べられるか解答していく。
![4JUsL0RJr8QciCRj.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/530912/347f7396-6fd1-4ab8-982f-aaccf14877f7.png)

## 例2 脳内トレース用
美食度と美味しさが与えられる

![4OylTuaNW26f7AsL.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/530912/1c04c140-b8e7-4786-a5a2-70eeeacaf184.png)

### 解答
2番目、3番目の人、美味いもの全部食べられててカワイソ・・・
![5fsAHsLMq8rFJalM.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/530912/ce84598b-ac8b-4de2-90a5-379df3ab07aa.png)


同じ手順でトレースすると下記のような解答になると。

あとは、これをTLEしないようにpythonを始めプログラミングコードに落とし込めば良いっと。

# D問題解法アプローチ

https://atcoder.jp/contests/abc382/tasks/abc382_d

<iframe width="560" height="315" src="https://www.youtube.com/embed/xkxD0P1io7Y?si=GUmEmJ2v8_YMjfH9&amp;start=4958" 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>

問題が掴みどころがないので、具体的数字で検証

1. N=5, M=41のとき
![1uR9lRq9FMefGhit.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/530912/2062703a-c898-49d0-a25c-8910eb8c10a8.png)


2. N=5, M=42のとき
![2N8GneIT2yihyd35.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/530912/b4033c2c-0673-45ab-ba17-dd163436d19f.png)


TLEするかどうかは別として、下以下のような木を作り、小さい順に列挙しろって問題か。
![4JUsL0RJr8QciCRj.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/530912/acfe22d9-af49-47bd-bd1e-6f9863c72ec8.png)


3. N=5, M=43のとき

![4OylTuaNW26f7AsL.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/530912/29f4a5d6-1b82-4a9e-9486-4ff1455ca0a2.png)

ACコードと同様の結果も得られそうだし、余裕があるときにコーディングしてみますか。
木なら嫌ってほどやったし。

最近、ペンタブ買ったのですが、6000円くらいなのに、物凄い良い買い物だった。
タッチパネルより使い勝手良いし、今までイラスト書かないから、不要なものという先入観で損してたわ。
Laravel開発者のためのLivewire入門。ドキュメント翻訳を通して見えた魅力

Laravelでのフロントエンド開発をもっと手軽にできないか？そう考えて個人的に注目しているのが **Livewire** です。実は少し前までInertia.jsを使っていたのですが、Laravelのノウハウ以上にVueやReactのノウハウががっつり必要なので、なかなか大変と感じました。

今回、Livewire v3の[公式ドキュメントを日本語に翻訳](https://yama.github.io/livewire-docs-ja/)したことで、Livewireの魅力を改めて実感しました。本記事では翻訳の話と併せて、Livewireがなぜ面白いのかを紹介します。

## なぜLivewire？VueやAlpine.jsとの違い

Livewireの特徴は、**フロントエンドのUI処理をPHP側のメソッドで実装できる**ことです。

```php
<button wire:click="increment">+</button>

// Livewire コンポーネント
public function increment() {
    $this->count++;
}
```

JavaScriptの記述は不要で、Bladeテンプレート上で完結します。これはAlpine.jsやVueとは大きく異なる点です。

| 技術        | 特徴             | 状態管理   | サーバ通信          | 向いている場面         |
| --------- | -------------- | ------ | -------------- | --------------- |
| Alpine.js | 軽量・記述がシンプル     | フロントのみ | 明示的にfetch等で実装可 | 小規模なUIにちょい足し    |
| Vue       | 本格的なSPA構築に最適   | フロント中心 | axiosなど        | 大規模・高度なUIが必要な場面 |
| Livewire  | PHPだけでUIを制御できる | PHP側   | 自動             | Laravelで完結したい場面 |

※ Alpine.jsもfetchやAxios等を使えば通信は可能ですが、それ自体にバックエンド通信の仕組みが組み込まれているわけではありません。

ページ全体をLivewireで構成することも、一部の要素だけをLivewireにすることもでき、**柔軟な導入が可能**です。

ちなみに、**Alpine.jsとLivewireはどちらもCaleb Porzio氏によって開発されています。**「Laravelでの開発をもっとシンプルにしたい」という思想のもと設計されており、両者は非常に相性が良く、LivewireのUI補助としてAlpine.jsを使う構成が公式にもよく登場します。

たとえば、モーダルの開閉やアコーディオンなど、ちょっとしたUIの動きはAlpine.jsで手軽に実装しつつ、状態管理やサーバ通信はLivewireに任せるといった組み合わせが実践的です。

## 翻訳の動機と工夫

Livewireに興味を持ったものの、英語ドキュメントでつまづいた経験から、日本語訳の必要性を感じて翻訳を始めました。つまり、まずは自分の理解のためです。

* GitHub Copilotを活用し、翻訳スタイルを明示的に指示
* コードと解説の対応が明確になるよう調整
* 自動翻訳任せではなく、すべての文章を目視で確認
* 納得のいく翻訳になるまで何度もやり直した

VueやLaravelなど、日本語情報が充実しているフレームワークは普及が早かったです。「翻訳によってLivewireが広まるきっかけになれば」との思いもあります。

## 日本語情報が少ない今こそ、チャンス

Livewireの日本語解説はまだ多くありません。ですが、Laravelと親和性が高く、小さな導入から本格的な開発までスケールできるLivewireは、今後確実に注目が集まる技術だと思います。翻訳したドキュメントは随時更新予定なので、ぜひ一度覗いてみてください。

[Livewire ドキュメント（日本語訳）](https://yama.github.io/livewire-docs-ja/)
Σx+ΣyがΣΣzみたいになるやつの理解のメモ

# 複数の総和（シグマ）を抽象化して1つにまとめる方法  
## 〜「りんごとバナナの売上データ」から学ぶ数式の一般化〜

---

## 背景

たとえば、以下のような売上データがあるとする：

- りんごの売上（2日分）：`x₁ = 100`, `x₂ = 150`
- バナナの売上（3日分）：`y₁ = 80`, `y₂ = 90`, `y₃ = 110`

これらを合計する式はこうなる：

```math
∑_{i=1}^{2} x_i + ∑_{j=1}^{3} y_j
```

---

## 直感的な例え：りんごとバナナを数える

この式は、次のような状況に置き換えられる：

> **「りんご2個とバナナ3本を数える」**  
> → **「果物の種類 `d` ごとに、個数 `k` を数える」**

このとき、`d = 1` をりんご、`d = 2` をバナナとすれば、  
「果物の種類ごとに、個数を数える」という形で統一的に表現できる。

---

## 抽象化の目的

このように「種類ごとに長さが異なる複数の和」を、**ひとつの統一的な構造で表現したい**ときがある。  
そのために、以下のような抽象化を行う：

```math
∑_{d ∈ {1, 2}} ∑_{k ∈ I_d} z_k^{(d)}
```

---

## 各記号の意味と具体例

| 記号 | 意味 | 具体例（売上データ） |
|------|------|------------------------|
| `d` | データの種類（グループ番号） | `d = 1` → りんご<br>`d = 2` → バナナ |
| `I_d` | グループ `d` に属する日数の集合 | `I₁ = {1, 2}`（りんご2日分）<br>`I₂ = {1, 2, 3}`（バナナ3日分） |
| `z_k^{(d)}` | グループ `d` の `k` 日目の売上 | `z_1^{(1)} = x_1 = 100`<br>`z_2^{(1)} = x_2 = 150`<br>`z_1^{(2)} = y_1 = 80`<br>`z_2^{(2)} = y_2 = 90`<br>`z_3^{(2)} = y_3 = 110` |
| `x_i`, `y_j` | 元の変数（売上データ） | `x_i`：りんごの売上<br>`y_j`：バナナの売上 |

---

## 例：売上の合計を求める

元の式：

```math
∑_{i=1}^{2} x_i + ∑_{j=1}^{3} y_j = 100 + 150 + 80 + 90 + 110 = 530
```

抽象化後の式：

```math
∑_{d ∈ {1, 2}} ∑_{k ∈ I_d} z_k^{(d)} = 530
```

---

## メリット

- 和の構造を統一できる
- データの種類が増えても同じ構文で処理できる
- プログラムや数式処理で汎用的に扱える
- データ構造の抽象化に役立つ

---

## まとめ

複数の和を抽象化して1つの式にまとめることで、数式の再利用性や可読性が向上する。  
「りんごとバナナの売上を合計する」という具体例と、「果物の種類ごとに個数を数える」という直感的な例えを使えば、抽象的な数式も自然に理解できる。
Ollamaでモデルの名前を変えて起動する

# Ollamaでモデルの名前を変えて起動する
表題の通り

## 経緯
Dify で Ollama モデルプロバイダーを使ってモデルを立ち上げようとした時に、とある理由で公式の名称以外のモデル名を使う必要があった

一応 OpenAI-API-compatible で別名で登録できるが、互換性がちょくちょく無かったので微妙だった（Function Calling 使えないとか普通に困る）

## 結論
Ollama のコピーコマンドを使って、同じモデルデータで別名のモデルを作成する
（下の例だと my-deepseek というモデル名になる）

```shell:shell
# Pull original model data
$ ollama pull deepseek-r1:8b

# Rename it
$ ollama cp deepseek-r1:8b my-deepseek

# Run
$ ollama run my-deepseek
```

試してないが、Modelfile でも同様のことはできると思う。Docker で動かすには ENTRYPOINT に仕込めば良い

```Dockerfile:Modelfile
FROM deepseek-r1:8b
```

```shell:shell
$ ollama create my-deepseek -f /Modelfile
```
route53にドメインをいじいじしたい

# route53の由来
DNSが標準的に使用するポート番号だかららしい

# 設定
route53の再度バーからホストゾーンを作成する。
管理するドメイン名を入れて作成する。

NSレコードの値とトラフィックの４つの値をコピーして、ドメインを取得したサイトでネームサーバー設定を開き対象ドメインのネームサーバーを修正する

# とりあえず見る記事

https://dev.classmethod.jp/articles/route53-domain-onamae/