OmniAICreator/Qiita-1.07M huggingface dataset:
AtCoder ABC400 振り返り(緑コーダーがPythonでAB+CD問題)

## [AtCoder Beginner Contest 400](https://atcoder.jp/contests/abc400) 振り返り

今回はABの2問解答でした。Bまでは順調に解けたのですが、C問題で数式変形がうまくできずに正解が求まらず...。D問題は幅優先探索が正着なところを、深さ優先探索で解こうとして解けず...。

C, D問題はコンテスト終了後に、復習して解きました。

またしてもレーティングが減ってしまい、そろそろ緑陥落が見えてまいりました(あと−30)。


## [A - ABC400 Party](https://atcoder.jp/contests/abc400/tasks/abc400_a)

400 で割り切れるかを判定しています。

``` python
A = int(input())

if 400 % A == 0:
    print(400 // A) 
else:
    print(-1)
```

## [B - Sum of Geometric Series](https://atcoder.jp/contests/abc400/tasks/abc400_b)

数式通りに計算していきました。Pythonだとオーバーフローを考えていなくて良いのが楽ですね。

``` python
N, M = map(int, input().split())

X = 0
for i in range(M+1):
    X += N ** i

    if X > 10 ** 9:
        print("inf")
        exit()

print(X)
```

## [C - 2^a b^2](https://atcoder.jp/contests/abc400/tasks/abc400_c) (解説AC) 

これは解説を見て解きました。

考え方としては...
* a は 1 から 60 までループさせれば良い
* b が偶数の場合、2 ^ a の項に統合してしまって良い
    * 2^2 * 6^2 → 2^4 * 3^2

なので、aをループさせて、そのa に対して条件を満たす B=1,3,5,7... の個数を求めれば良いということになる。 


また、 他の方の解答を見ていて ```math.isqrt()``` を知りました。これだと平方根の整数部分だけが求められて、誤差が気にならなくなります。

``` python
N = int(input())

count = 0

for a in range(1, 61):
    A = 2 ** a
    if A > N:
        break

    B2 = N // A
    max_B = math.isqrt(B2)
    # 奇数だけカウント
    count += (max_B + 1) // 2

print(count)
```

## [D - Takahashi the Wall Breaker](https://atcoder.jp/contests/abc400/tasks/abc400_d) (解説AC) 

壁を壊すパターンも含めて、幅優先探索を行えば良い。最短距離のものから処理したいので、通常は優先度付きキュー ```heapq``` を使用したいところですが、この問題では1問だけどうしてもTLEになってしまいます。

そこで、  ```01-BFS``` という手法を使うと良いとのことでした。これであれば ```deque``` を使えるので、より高速に処理することができます。

``` python
H, W = map(int, input().split())
S = [list("*" + input() + "*") for _ in range(H)]
S.insert(0, ["*"] * (W + 2))
S.append(["*"] * (W + 2))
A, B, C, D = map(int, input().split())

visited = [[INF] * (W + 2) for _ in range(H + 2)]
visited[A][B] = 0

# 幅優先探索
queue = deque()
queue.append((0, A, B))

while queue:
    break_count, x, y = queue.popleft()

    if x == C and y == D:
        break
    
    for dx, dy in [(-1, 0), (1, 0), (0, -1), (0, 1)]:
        # 通路を進むパターン
        if S[x + dx][y + dy] == ".":
            if visited[x + dx][y + dy] > break_count:
                visited[x + dx][y + dy] = break_count
                # 現状の最短距離なので、キューの左側に追加
                queue.appendleft((break_count, x + dx, y + dy))
                continue

        # 壁を壊すパターン
        if S[x + dx][y + dy] == "#":
            # 1個目の壁
            if visited[x + dx][y + dy] > break_count + 1:
                visited[x + dx][y + dy] = break_count + 1
                # 壁を壊したので、キューの右側に追加
                queue.append((break_count + 1, x + dx, y + dy))

            # 2個目の壁を壊せれば壊す
            if 0 < x + dx*2 < W + 1 and 0 < y + dy*2 < H + 1:
                if S[x + dx*2][y + dy*2] == "#" or S[x + dx*2][y + dy*2] == ".":
                    if visited[x + dx*2][y + dy*2] > break_count + 1:
                        visited[x + dx*2][y + dy*2] = break_count + 1
                        # 壁を壊したので、キューの右側に追加
                        queue.append((break_count + 1, x + dx*2, y + dy*2))

print(visited[C][D])

```
TailwindCSS IntelliSenseで補完されない場合の対処法

## 対象：VSCのTailwindCSS IntelliSenseで補間されなくて困っている方

最近、tailwindcssがver4.0が公開されました。

それに伴って、色々な機能が追加されたのですが、前々からあるVSCの拡張機能の

「TailwindCSS IntelliSense」が使えなくなってしまいました。

しかし、簡単に復活させることができるので、その方法について記述していきます。

その方法はすごく簡単で、

### プロジェクトフォルダにtailwind.config.jsを作るだけです。

中身は空でも問題ありません。

追加後、適当に<div class="">の""の中に入力してみてください。

すると、補完されるようになると思います。

まとめ

tailwindCSSのver4.0にしてvscの拡張機能のTailwindCSSが使えなくて困っている方は

## プロジェクトファイルにtailwind.config.jsを作りましょう！
爆速でReactでChrome拡張機能を作る

ReactでChromeの拡張機能を作る方法です。

Chromeの拡張機能はHTML、JavaScript、CSSで作れますが、JavaScriptよりもReactの方が作りやすいので、やり方をご紹介します。

「ReactでとりあえずChromeの拡張機能を作って動かす」を目的としているので、Reactの解説などは行わないのでご注意ください。

## Reactのプロジェクト作成

まずはReactのプロジェクトを作成します。

```bash
npm create vite@latest
```

## App.tsxの修正

Reactのプロジェクトが作成されたら、App.tsxを以下のように修正します。

```App.tsx
function App() {
  return <button onClick={() => alert(1)}>テスト</button>;
}

export default App;
```

### Reactアプリのビルド

`yarn build` or `npm run build`でReactアプリをビルドします。
すると、distディレクトリが作成されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2382613/7b4ac39f-262e-473a-a63f-334bbef0342b.png)

## manifest.jsonの作成

Reactアプリとは別にディレクトリを作成します(ここではchrome-extensionとします)。
そのchrome-extensionの中に`manifest.json`を作成し、さらにdistディレクトリ以下のファイル全てをコピーします。
chrome-extensionのディレクトリ構成とmanifest.jsonは以下のようになります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2382613/7926cec3-9efe-46cf-95e3-b8e313cdc2d9.png)

```json
{
  "name": "Sample",
  "description": "Sample Extension. Show alert!",
  "version": "1.0.0",
  "manifest_version": 3,
  "action": { "default_popup": "index.html" }
}
```

## Chromeで拡張機能を動かす

あとは、Chromeから作成した拡張機能を読み込み(「パッケージ化されていない拡張機能を読み込む」からchrome-extensionのディレクトリを選択)すれば拡張機能が動かせます

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2382613/bc408b0d-d2fb-4873-8571-147c49017ef9.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2382613/bebb2348-5546-4003-a7b1-4ba6da0f5d57.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2382613/9929eaee-6c4a-41b3-8b68-750c9c13eea3.png)
npx tailwindcss init -p が動作しない時の対処法

恐らくここに辿り着いた方は、tailwindcssをフレームワークと結びつけたりするために色々と試行錯誤しているのではないでしょうか。

現に、サジェストの上位には

npx tailwindcss init -pをしろという記述が多くある記事がいっぱいです。

ただ、それらは全てバージョン2や3の話です。

2025/03/20現在、tailwindcssの最新バージョンは

4です。（tailwindcss v4と書いたりする）

なので、tailwindcss v4のセットアップ方法を調べましょう。

以下が v4の公式ドキュメントです。

https://tailwindcss.com/docs/installation/using-vite

中身を見ると分かりますが、もう

npx tailwindcss init -p

なんて使ってないんです…

Qiitaの記事を鵜呑みにしてしまった私は、これを知らなくて3時間くらい取られてしまいました…

もし、tailwindcssのインストールで困っている方がいらっしゃったら、上記のリンク先の公式ドキュメントを参照してください。

とても分かりやすく順序立てて説明してありますので、私が説明するより分かりやすいですw
vanilla jsで動作するテンプレートライブラリを作った



## ほしかった機能

vanilla jsのみで動作する。

html側で設定、変更が可能なもの。

簡単に導入できること。

## なぜ作ろうと思ったか

サーバーにnode.jsが入らなかったから。

レイアウトが複雑な要素を編集するのが大変だから。

かといって、templeteでjsを書くまでもないような場合に、ほしいなと感じていたから。

## 使用方法

replaceクラスの中に、テンプレートを記述し、その内容を参照し、テンプレートとする。

基本的には、テンプレートの内容を重視し、innerhtmlのみを呼び出し元から参照させる。

テンプレートを使用する物にはp_tempクラスを追加する。



![スクリーンショット 2025-04-08 204532.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3880618/017a3a2d-6cdf-4919-b700-99ecfd6653b8.png)

![スクリーンショット 2025-04-08 210156.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3880618/93cfbf53-7940-4019-9b69-e100dcdc4be7.png)

呼び出し側は、p_tempと呼び出し用のクラスを設定する。
そうすると、テンプレートからその要素を探し、置換する。

tailwild cssのようなクラスが大量に記述されるようなものを簡潔に書くのにも使用できる。

基本的に、呼び出し元のタグは無視され、タグごとすべて変更される。inner_htmlとsrc,
hrefは継承される。

呼び出し側は、関数のような構造になっており、中に引数を設定できる。画像のbtnの場合、class bigを引数に取っており、これがtemplateのHELLOを置換し、hhhとなる。
複数設定可能で、かつ、テンプレート側に複数の同一クラスがあった場合、そのすべてが置換される。

テンプレート側の要素の中に、タグが存在しない場合、特別に、呼び出し元のinner_HTMLを取得し、全置換する。

引数がある場合、引数ごとの置換になるため、注意。

基本的に、引数は設定しなくてもよい。

設定しない場合、テンプレートのまま置換される。
中身を書いておけば、そのまま表示されるので、
変更したい要素があったときだけ、引数を記入する方式でもよい。

bodyはdisplay:none;しておくことをお勧めします。ちらつくので。

bodyは処理が終わったら、display:block;するように実装されています。

すべて読み込まれてからの処理になるので、既存のjsコードがある場合は、干渉することが考えられます。そこはお気をつけください。


https://github.com/kemii279/tiny_templete
.DS_storeとはなんなのか？毎回.gitignoreに入れるのめんどくさい

# はじめに
macでプログラミングしていると、勝手に現れる`.DS_Store`
.gitignoreに入れるファイルであることしか知らないので、調べてまとめた。
# .DS_Storeとは何か？
`.DS_Store`（Desktop Services Store）は、macOSのFinderが自動的に生成する隠しファイルである。このファイルは、アイコンの位置やウィンドウサイズなどのメタデータが含まれている、

このファイルをgit等のバージョン管理含まれると、他のOSのユーザーには不要なファイルとなる。また、過去にあったファイル名などの情報がファイル内に残っている可能性もあり、セキリュティ上の懸念に繋がるため。

そのため、.gitignoreに`.DS_Store`を書いて、バージョン管理しないようにする。
しかし毎回.gitignoreに`.DS_Store`を書いていたが、Global設定をすることで毎回.gitignoreに`.DS_Store`を書かなくていいらしい。

そこで、プロジェクトごとに`.DS_Store`をignore設定するのではなくて、グローバルに設定してみた。

# グローバルなgitignoreを設定する方法
Gitはデフォルトで、`~/.config/git/ignore` へignoreの設定を参照する。つまり、ここに書いておけば、すべてのプロジェクトに適用される。

1 ignoreファイルを格納するためのディレクトリを作成
```bash
mkdir -p ~/.config/git/
``` 
2 ignoreファイルを作成し、全プロジェクトでignoreしたい内容を入れる
```bash
cursor ~/.config/git/ignore
```
cursorエディタを使っているが、ignoreファイルを作成して、その中に`.DS_Store`を書いて保存。
このファイルに、`.DS_Store`を入れておけば、`DS_Store`は自動でGitの追跡から除外される。

# 参考文献 (2025/04/08 アクセス)
公式ドキュメント : https://git-scm.com/docs/gitignore
https://bossagyu.com/blog/025-git-ignore/
https://yoshitaku-jp.hatenablog.com/entry/2021/12/03/180000
https://zenn.dev/thousanda/articles/5c7dcd8d6bd9bd
pfsence で BGP の設定メニューを表示させる

# pfSense で BGP を有効化する方法

皆さんこんにちは。今回は pfSense（ピーエフセンス）で BGP（Border Gateway Protocol）を設定する方法について解説します。

## BGP とは

BGP（Border Gateway Protocol）は、インターネットの経路制御に使用される重要なプロトコルです。異なる AS（Autonomous System）間でルーティング情報を交換するために使用され、インターネットのバックボーンを支える技術として広く採用されています。

pfSense で BGP を利用するには、追加パッケージのインストールが必要です。初期状態では設定メニューが表示されないため、まずはその有効化手順から説明します。

## 設定手順

１. pfSense のインスタンスを起動します
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/531208/27867133-318b-4012-8cbe-2fb3de98a9ac.png)
※ pfSense の初期設定に関しては他の記事を参照してください

２. pfSense の Web UI にログインします

- LAN インターフェイスの IP アドレスがあればそちらに、なければ WAN インターフェイスの IP アドレスに HTTP で接続します
- デフォルトの認証情報は以下の通りです：
  - ユーザー名：`admin`
  - パスワード：`pfsense`
- セキュリティ上の理由から、ログイン後は自分用の管理者ユーザーを作成し、デフォルトの`admin`アカウントは無効化することをお勧めします

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/531208/0f705e00-d1d8-465e-b43c-0fc42c1612cf.png)

３. 画面上部のメニューから `System` → `Package Manager` を選択します
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/531208/4373b96d-1923-44f7-a067-4737868d0c18.png)

４. `Available Packages` タブを選択します
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/531208/44931f8a-a612-4b8d-8591-133a6764a189.png)

５. 検索ボックスに `frr` と入力して検索し、表示されたパッケージの `Install` ボタンをクリックします
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/531208/19ca9176-3ae3-4830-901a-a5f5fc318744.png)

６. インストールの確認画面が表示されるので、`Confirm` をクリックして承認します
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/531208/c643218b-c189-4f34-86f1-a5f552f11755.png)

７. `Success` と表示されればインストール完了です
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/531208/8efe0f5c-8df4-42cb-bfb7-2dc4549a64d0.png)

８. 画面上部の `Services` メニューに `FRR BGP` が表示されていることを確認します
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/531208/ffa0c45c-cae1-4073-8cd2-56aa023ee1b7.png)

## BGP の基本設定

FRR BGP パッケージをインストールしたら、以下の手順で BGP の基本設定を行います：

1. `Services` → `FRR BGP` を選択します
2. `Global Settings` タブで以下の項目を設定します：
   1. `Enable`: チェックを入れて BGP を有効化
   2. BGP AS Number`: 自身の AS 番号を入力（プライベート AS 番号: 64512-65534）
   3. `Router ID`: ルーター ID を設定（通常はループバックアドレスか固定 IP アドレス）
3. `Neighbors` タブでピア接続先を設定します：
   1. `Add` をクリックして新しい BGP ネイバーを追加
   2. 接続先の IP アドレスと AS 番号を設定
   3. 必要に応じて認証設定を行う
4. `Networks` タブで広報するネットワークを設定します
5. 設定後、`Save` をクリックして変更を保存します
6. `Apply Changes` をクリックして設定を反映させます

## まとめ

以上で pfSense で BGP 設定を行うための準備と基本設定の手順を説明しました。公式ドキュメントでは当然のように「FRR BGP」から設定するよう記載されていますが、初期状態ではこのメニューが表示されないため、戸惑いました。

BGP の詳細な設定はネットワーク環境によって異なりますので、実際の運用では接続先の ISP やピアリングパートナーの要件に合わせて適切に設定してください。また、BGP はインターネットの経路制御に直接影響するプロトコルですので、設定ミスによる影響を最小限に抑えるため、テスト環境での十分な検証をお勧めします。
RHEL 9のquadlet+podman環境でコンテナの自動起動が失敗してた話

# 結論
podmanの最近のバージョンはデフォルトのネットワークバックエンドにpastaを使っていた。
これが良くなかった。
```/usr/share/containers/containers.conf```の内容の一部を次のように変更した。
変更前: ```default_rootless_network_cmd=pasta```
↓
変更後: ```default_rootless_network_cmd=slirp4netns```

上述の変更により自動起動が成功するようになった。

# 原因
使っているVPN(tailscale)かpastaに原因があるのかはわかっていないが、pastaかtailscaleのどちらかが起動する前にコンテナを起動しようとしてインターフェースを見つけられずに起動が失敗するようだった。

# 経緯
1. vaultwardenをセルフホストしたかった。
2. 追加でインストールするものを極力減らしたかったので、DockerではなくRHEL上にデフォルトインストールされているpodmanを使うことにした。
3. podman-compose.ymlを使ってvaultwardenコンテナの立ち上げに成功した。
4. 作成したpodman-composeの内容を参考にquadletを使ってユニット化した。
5. ```systemctl --user start vaultwarden.container```では起動するが、再起動時に自動起動しない問題があった。
kube-bench を理解する

# 目的
- kube-bench を理解する

# 手段
KillerCoda で手を動かす

### 環境
KillerCoda

### やってみる

基本形は以下の通りです。

```bash
$ kube-bench run -s master
# -sオプションでコマンド実行対象を指定
```

特定の CIS を確認するコマンドは以下の通りです。

```bash
$ kube-bench run -s master --check 1.1.19
[INFO] 1 Control Plane Security Configuration
[INFO] 1.1 Control Plane Node Configuration Files
[PASS] 1.1.19 Ensure that the Kubernetes PKI directory and file ownership is set to root:root (Automated)

== Summary master ==
1 checks PASS
0 checks FAIL
0 checks WARN
0 checks INFO

== Summary total ==
1 checks PASS
0 checks FAIL
0 checks WARN
0 checks INFO
# 1.1.19 は PASS している
```

FAIL している場合は以下の通りです。

```bash
$ kube-bench run -s master --check 1.1.12
[INFO] 1 Control Plane Security Configuration
[INFO] 1.1 Control Plane Node Configuration Files
[FAIL] 1.1.12 Ensure that the etcd data directory ownership is set to etcd:etcd (Automated)

== Remediations master ==
1.1.12 On the etcd server node, get the etcd data directory, passed as an argument --data-dir,
from the command 'ps -ef | grep etcd'.
Run the below command (based on the etcd data directory found above).
For example, chown etcd:etcd /var/lib/etcd


== Summary master ==
0 checks PASS
1 checks FAIL
0 checks WARN
0 checks INFO

== Summary total ==
0 checks PASS
1 checks FAIL
0 checks WARN
0 checks INFO
# Remediations master の説明に沿って対処すれば PASS できます
```

# あとがき
サービス問題ですね。

# ソース
- [CIS](https://www.cisecurity.org/benchmark/kubernetes)
Blenderで共同編集しようとして詰まった話 [Mixer1.01]

# はじめに
Blenderで共同編集をする際に、2台のパソコンにMixer1.01をダウンロードしてアセットをインポートし、一方のパソコンでroomを作成したが、もう一方のパソコンでroomが見つからない問題にぶつかった。

簡単に解決できたので方法を示す。

# 動作環境
Mac AppleSilicon Sequoia 15.0
Mac AppleSilicon Somoma 14.4

Blender 2.9.2
Mixer 1.01

# 前提
![スクリーンショット 2025-04-08 19.35.16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3860255/6560162d-cebe-42fe-bafb-7c0795692543.png)

Mixerタブが出現していて、CreateボタンよりRoomを作成できること。
2台のパソコンが同じWifiに接続していること。
(検証していないがZeroTierなどのVPNソフトを使用して遠隔で接続している際も可能と思われる)

# 解決法
サーバー側のパソコンと接続側のパソコンでやることを示す。

### サーバー側のパソコン
![スクリーンショット 2025-04-08 20.11.00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3860255/6c11c3c7-4a06-46c7-9063-030c2031161d.png)

Host: の部分をlocalhost から __0.0.0.0__ に変更しRoomを作成する。次に、

 　
![スクリーンショット 2025-04-08 19.51.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3860255/138f1a7c-87d4-41b3-8c21-86eddd601393.png)

設定→Wifi→詳細→TCP/IPから、接続中のWifiのIPアドレスを確認する。
接続側のパソコンで使用するためメモしておく。

### 接続する側のパソコン
![スクリーンショット 2025-04-08 20.10.16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3860255/e23a00c0-4f02-4332-808b-f1a216ce478f.png)

Host: をlocalhostから __メモしたIPアドレス__ に変更する。
接続ボタンを押してサーバー側パソコンで作成したRoomが見つかれば成功。

# まとめ
意外と簡単に解決できてよかった。
【JavaScript】v = +e.target.valueの+って何？？

## はじめに

[Vue.js公式サイトの実装例](https://ja.vuejs.org/examples/#temperature-converter)を見ていたところ、以下のプログラムがありました。

```vuejs
<script setup>
import { ref } from 'vue'

const c = ref(0)
const f = ref(32)

// ここで+e.target.valueが出てくる！
function setC(e, v = +e.target.value) {
  c.value = v
  f.value = v * (9 / 5) + 32
}

function setF(e, v = +e.target.value) {
  f.value = v
  c.value = (v - 32) * (5 / 9)
}
</script>

<template>
  <input type="number" :value="c" @change="setC"> Celsius =
  <input type="number" :value="f" @change="setF"> Fahrenheit
</template>
```

ここで`v = +e.target.value`というコードがあります。

ん？ `v += e.target.value`なら見たことがあるけど、この`+`は何？？

`+`を取り除いて`v = e.target.value`にしても動作は変わらないし...と思って調べました。

## 単項プラス演算子

結論から言うと、この`+`は**単項プラス演算子**といい、**数値への変換**に使われています。

https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Unary_plus

今回のコードでは、`e.target.value`で受け取った値は"32"のような文字列なので、`+e.target.value`とすることで数値に変換しています。

## なぜ`+`を取り除いても動作が変わらなかったのか？

`+`を取り除いても動作が変わらなかったのは、Vue.jsが`<input type="number">`の場合に自動で数値として型変換してくれるためです。

https://ja.vuejs.org/guide/essentials/forms.html#number

また、Vue.jsでなくとも、JavaScriptの暗黙の型変換で文字列を数値に変換してくれて上手くいく場合もあります。

https://jsprimer.net/basic/implicit-coercion/

今回の場合ですと、`v * (9 / 5) + 32`や`(v - 32) * (5 / 9)`は暗黙の型変換が行われています。

ただ、バグを防げるので**明示的に型変換した方が望ましい**です。

## 他の型変換方法

`Number(e.target.value)`でも数値への型変換は可能です。

こちらの方が一般的ですし、一目見て「数値に変換しているんだ」とわかりやすいので、正直こちらの方が良いと思います。

## おわりに

`+`自体はVueの特殊機能ではなくJavaScriptの単項プラス演算子でした。

なぜ`+`がなくても正常に動作するのか？については、Vueの機能によるものでした。

## 参考

https://qiita.com/tonkotsuboy_com/items/04feedc8f7e19290efca
ビットコインの基礎からエアドロップまで！初心者向けブロックチェーン入門

# ビットコインの基礎からエアドロップまで！初心者向けブロックチェーン入門

最近、ビットコインをはじめとする仮想通貨の話題を耳にする機会が増えたと感じませんか？  
しかし、いざ調べ始めると「ブロックチェーン」「マイニング」「エアドロップ」など、初めて見る単語や専門用語が多く、挫折してしまう方も多いのではないでしょうか。

そこで今回は、仮想通貨・NFT関連のニュースを幅広く解説している [NFT LABO][nftlabolink] さんの記事を参考に、ビットコインの基本やエアドロップの概要など、初心者の方がまず押さえておきたいポイントをまとめてみました。

---

## ビットコインとは？

ビットコインは、2009年に「サトシ・ナカモト」と名乗る人物（またはグループ）によって提唱された世界初の分散型デジタル通貨（仮想通貨）です。  
従来の銀行や管理主体に依存せず、**P2P（Peer to Peer）** での取引が可能という点が大きな特徴となっています。

> ビットコインはブロックチェーン技術を基盤としており、データ改ざんが非常に困難な仕組みを持っています。

[ビットコイン解説ページ][bitcoinlink] では、  
- ビットコイン誕生の経緯  
- ブロックチェーンの仕組み  
- マイニングの原理  
- 価格変動の理由と投資リスク  

など、初心者でもわかりやすい言葉で解説されています。ビットコインの全体像を把握したい方は必見です。

---

## ブロックチェーン技術の要点

Qiitaをご覧のエンジニアの方であれば、ブロックチェーンの内部構造やアルゴリズムに興味を持つ方も多いでしょう。  
ビットコインはブロックチェーンの代表例とも言われ、下記のような仕組みで成り立っています。

1. **分散台帳**  
   - 従来の中央集権型データベースとは異なり、すべての参加者が取引履歴（台帳）のコピーを保持します。

2. **PoW（Proof of Work）**  
   - マイナーが暗号的な計算作業を通じてブロックを生成し、その正当性を証明します。  
   - 正しいブロックを作ると報酬としてビットコインが与えられる仕組みです。

3. **改ざんが困難**  
   - あるブロックを改ざんすると、そのブロックから後続すべてのブロックを再計算する必要があり、実質的に不可能に近いと言われます。

これらの技術的な要点を押さえることで、ビットコインや他のブロックチェーンプロジェクトがどう動いているのかがイメージしやすくなります。

---

## エアドロップとは？

「エアドロップ」とは、一定の条件を満たすことで新しい仮想通貨（トークン）を無料でもらえるイベントのことです。プロジェクトの認知度を高める目的で実施される場合が多く、うまく活用すれば仮想通貨を無償で手に入れるチャンスがあるかもしれません。

[仮想通貨エアドロップページ][airdroplink] では、最新のエアドロップ情報や参加方法、注意点などがまとめられています。エアドロップは期間限定のものが多いので、こまめにチェックするのがおすすめです。

> 例：SNSフォローやメール登録など簡単なタスクでトークンを受け取れるものもあり、初心者にも比較的ハードルが低いです。ただし詐欺的なエアドロップも存在するため、十分に注意しましょう。

---

## NFT LABO とは？

[NFT LABO][nftlabolink] は、ビットコインやイーサリアムなどの主要コインから、NFTやメタバースなど先端トレンドに至るまで、幅広い仮想通貨・ブロックチェーン関連のニュースや解説記事を提供しているサイトです。  
初心者向けの記事はもちろん、多少テクニカルな話題にも触れているので、エンジニアの方にも有益な情報が得られると思います。

### 主な掲載内容

- **ビットコインなど仮想通貨の基礎知識**  
- **NFTの最新トレンドや活用事例**  
- **エアドロップ情報や取引所の紹介**  
- **ウォレットの作成手順やセキュリティ対策**  

これから仮想通貨やブロックチェーン技術を学び始める方にとっては、総合的な入門サイトとして活用できるでしょう。

---

## まとめ

- ビットコインはブロックチェーン技術を基盤とする分散型デジタル通貨。  
- エアドロップは仮想通貨を無料で得られる可能性があるイベントだが、参加条件や期間に注意が必要。  
- [NFT LABO][nftlabolink] は仮想通貨やNFT関連のニュース・解説がまとまっており、初心者でも理解しやすい。

ブロックチェーンの進化は目覚ましく、日々新しいプロジェクトや技術が生まれています。エンジニアの皆さんも、この波に乗って最新情報をキャッチアップし、自分なりのプロジェクトやアプリケーションに活かしてみてはいかがでしょうか？

気になった方は、ぜひ以下のページをチェックしてみてください！

- [ビットコイン解説ページ][bitcoinlink]  
- [仮想通貨エアドロップページ][airdroplink]  
- [NFT LABO（サイト本体）][nftlabolink]

---

### 参考リンク
- [Bitcoin (公式サイト)](https://bitcoin.org/)
- [Ethereum (公式サイト)](https://ethereum.org/)

以上、仮想通貨に関する基礎知識と参考サイトのご紹介でした。  
「こういう技術的な部分も知りたい」「他のコインについて詳しくまとめてほしい」などありましたら、ぜひコメントやLGTMでご要望をお知らせください！

---

<!-- ここからリンク先をまとめて管理します -->

[bitcoinlink]: https://nft-labo.tokyo/bitcoin/
[airdroplink]: https://nft-labo.tokyo/airdrop/
[nftlabolink]: https://nft-labo.tokyo/
Pythonで実装するInterpreterパターン：ドメイン言語の構文解釈を実現する構造



## 概要

**Interpreter（インタプリタ）パターン**は、  
ある言語や表現を定義し、その**文法構造に基づいて文を解釈・実行するためのデザインパターン**である。

主に小規模な**ドメイン固有言語（DSL）**や、  
**表現の解析・評価・翻訳処理**などに用いられ、  
構文木を構築し、再帰的に評価することが特徴である。

---

## 1. なぜInterpreterが必要か？

### ❌ DSLや条件式を文字列のままif文で処理

```python
if expression == "A AND B":
    ...
```

→ 新しい構文を追加するたびにロジックが肥大化し、**拡張性が破綻する**

---

### ✅ 文法と意味論をクラスで明確に構造化し、評価可能にする

```python
expr = And(Variable("A"), Variable("B"))
expr.interpret(context)
```

→ **構文解析・意味解釈の責務を分離し、再利用と拡張が容易に**

---

## 2. 基本構造

### ✅ AbstractExpression（共通インターフェース）

```python
class Expression:
    def interpret(self, context):
        raise NotImplementedError
```

---

### ✅ TerminalExpression（終端記号）

```python
class Variable(Expression):
    def __init__(self, name):
        self.name = name

    def interpret(self, context):
        return context.get(self.name, False)
```

---

### ✅ NonTerminalExpression（構文ルール）

```python
class And(Expression):
    def __init__(self, left: Expression, right: Expression):
        self.left = left
        self.right = right

    def interpret(self, context):
        return self.left.interpret(context) and self.right.interpret(context)

class Or(Expression):
    def __init__(self, left: Expression, right: Expression):
        self.left = left
        self.right = right

    def interpret(self, context):
        return self.left.interpret(context) or self.right.interpret(context)
```

---

### ✅ Context（評価用の環境）

```python
context = {
    "A": True,
    "B": False
}
```

---

### ✅ 使用例

```python
expr = And(Variable("A"), Variable("B"))
print(expr.interpret(context))  # → False

expr2 = Or(Variable("A"), Variable("B"))
print(expr2.interpret(context))  # → True
```

---

## 3. Python的応用：構文木の文字列→構造変換（簡易パーサ）

```python
def parse(tokens):
    if len(tokens) == 1:
        return Variable(tokens[0])
    else:
        left = Variable(tokens[0])
        op = tokens[1]
        right = Variable(tokens[2])
        if op == "AND":
            return And(left, right)
        elif op == "OR":
            return Or(left, right)
```

```python
tokens = "A AND B".split()
expr = parse(tokens)
print(expr.interpret({"A": True, "B": True}))  # True
```

→ **簡易構文解析器としての活用が可能**

---

## 4. 実務ユースケース

### ✅ 独自クエリ言語の設計と評価

→ 例: `"name == 'Alice' AND age > 30"` のような**条件式DSLの処理**

---

### ✅ ルールエンジンの構文解釈

→ ビジネスルールや制御フローを**構文木として定義・評価**

---

### ✅ 数式エンジン・式の評価機能

→ 数学式・論理式の**動的な解釈と再利用**

---

### ✅ マクロ・テンプレート言語の内部処理

→ `{% if %}` や `{% for %}` などの**制御構造の内部解釈**

---

## 5. よくある誤用と対策

### ❌ 複雑な言語構文に無理してInterpreterを適用

→ ✅ Interpreterは**小規模なDSLや制限付き文法**に適する。複雑な文法にはParser Generatorを使用

---

### ❌ Expressionクラスが状態を持ちすぎる

→ ✅ Expressionは**構文と評価の責務のみに留める**

---

### ❌ Contextの設計が曖昧

→ ✅ Contextは**シンプルなキー・バリューマップまたは環境クラス**で分離する

---

## 結語

**Interpreterパターンとは、“文をクラスで表現し、評価可能な構造として解釈する構文的設計”である。**

- 言語的な記述（DSL）を、**クラス階層と構文木で明示的に構造化**  
- 評価処理をオブジェクト化することで、**ルールの再利用・動的生成・拡張が可能に**  
- Pythonではシンプルな構文DSLや条件式の評価ロジックを、**直感的に構築できる構文設計が可能**

**Pythonicとは、“コードがそのまま表現になり、意味を持つ”こと。  
Interpreterパターンはその設計的な言語化を、構文という形で具現化する知的技法である。**
Pythonで実装するFlyweightパターン：インスタンスの共有によるメモリ最適化



## 概要

**Flyweight（フライウェイト）パターン**は、  
大量に生成されるオブジェクトの中で**状態が共通している部分を共有し、必要最小限のメモリ消費で動作させる構造パターン**である。

特にゲーム・UI・文字処理・描画システムなど、**同種のオブジェクトが大量に発生する領域**で効果を発揮する。

---

## 1. なぜFlyweightが必要か？

### ❌ 毎回新しいオブジェクトを作る設計

```python
for _ in range(10000):
    icon = Icon("folder.png")
```

→ 同じ画像・構造にもかかわらず、**メモリに1万個の実体が生成される**

---

### ✅ 共通部分を共有し、最小限のインスタンス化に留める

```python
icon1 = factory.get_icon("folder.png")
icon2 = factory.get_icon("folder.png")
assert icon1 is icon2  # 同一インスタンス
```

→ **共通の内部状態は1つに保ち、外部状態のみを個別に持つ構造へ**

---

## 2. 基本構造

### ✅ Flyweight（共有されるオブジェクト）

```python
class Icon:
    def __init__(self, filename):
        self.filename = filename

    def draw(self, position):
        print(f"{self.filename} を {position} に描画")
```

---

### ✅ FlyweightFactory（インスタンス共有管理）

```python
class IconFactory:
    def __init__(self):
        self._icons = {}

    def get_icon(self, filename):
        if filename not in self._icons:
            self._icons[filename] = Icon(filename)
        return self._icons[filename]
```

---

### ✅ 使用例

```python
factory = IconFactory()
icon1 = factory.get_icon("folder.png")
icon2 = factory.get_icon("folder.png")

icon1.draw("top-left")
icon2.draw("bottom-right")

print(icon1 is icon2)  # → True
```

---

## 3. Python的応用：文字列や色の共有

```python
class Color:
    def __init__(self, name):
        self.name = name

class ColorFactory:
    _cache = {}

    @classmethod
    def get(cls, name):
        if name not in cls._cache:
            cls._cache[name] = Color(name)
        return cls._cache[name]
```

```python
c1 = ColorFactory.get("red")
c2 = ColorFactory.get("red")
print(c1 is c2)  # True
```

→ **イミュータブルなデータを中心に、明示的なキャッシュを使った軽量化**

---

## 4. 実務ユースケース

### ✅ フォント・アイコン・スプライトの共有描画

→ UI上の同一画像リソースを**再利用して描画コストを削減**

---

### ✅ 文字列解析や構文木の再利用（例：トークンの共有）

→ トークンやキーワードの**同一インスタンス化により高速処理**

---

### ✅ 地図上のピンやマーカーの共通構造管理

→ 共通の見た目を共有し、**位置やラベルのみ外部状態として持たせる**

---

### ✅ HTML DOMの仮想化（例：Reactの仮想DOM）

→ 構造の再利用と状態差分による**描画最適化**

---

## 5. よくある誤用と対策

### ❌ 外部状態を共有してしまう

→ ✅ **共有されるのは「内部状態」のみ**、外部状態は使用側で個別に保持すべき

---

### ❌ キャッシュが肥大化しすぎる

→ ✅ Factoryに**キャッシュ破棄・再利用の適切な制御機構を導入する**

---

### ❌ 可変オブジェクトをFlyweightとして共有する

→ ✅ **イミュータブルであることが前提**。可変な場合はコピーやクローンを用意すべき

---

## 結語

**Flyweightパターンとは、“共通の重さ（weight）を一つにまとめて、多数の個体を軽く保つ”ための設計技法である。**

- オブジェクトの内部状態を共有することで、**メモリ使用量を最小限に抑えながら高パフォーマンスを実現**  
- 状態の分離（内部と外部）によって、**柔軟な表現と最適な資源管理を両立**  
- Pythonではファクトリパターンや辞書ベースのキャッシュを活用することで、**シンプルかつ強力なFlyweight構造を実装可能**

**Pythonicとは、“同じものは一つに、違うものは分けて”扱うこと。  
Flyweightパターンはその効率的なリファクタリングの知恵を、構造に昇華させる技法である。**
Pythonで実装するDecoratorパターン：機能を包み込む拡張可能な設計


## 概要

**Decorator（デコレーター）パターン**は、  
あるオブジェクトに対して、**元のインターフェースを保ったまま、機能を段階的に追加する構造パターン**である。

継承ではなく**構成（composition）を用いることで、既存コードの修正を一切加えずに柔軟な機能拡張を可能にする**。  
Pythonの文法におけるデコレーター構文（`@`）とは異なるが、設計思想としては共通している。

---

## 1. なぜDecoratorが必要か？

### ❌ 機能追加のために継承を繰り返す構造

```python
class Coffee:
    def cost(self): return 300

class MilkCoffee(Coffee):
    def cost(self): return super().cost() + 50
```

→ 継承チェーンが増えるほど、**柔軟性が低下し組み合わせの爆発が起こる**

---

### ✅ 機能をラップして動的に積み重ねる

```python
coffee = MilkDecorator(SugarDecorator(PlainCoffee()))
coffee.cost()  # → 拡張された合計
```

→ **拡張の順序・有無を自由にコントロール可能に**

---

## 2. 基本構造

### ✅ Component（共通インターフェース）

```python
class Beverage:
    def cost(self):
        raise NotImplementedError
```

---

### ✅ ConcreteComponent（元のオブジェクト）

```python
class PlainCoffee(Beverage):
    def cost(self):
        return 300
```

---

### ✅ Decorator（共通のラッパー構造）

```python
class CoffeeDecorator(Beverage):
    def __init__(self, beverage: Beverage):
        self._beverage = beverage
```

---

### ✅ ConcreteDecorators（拡張ロジック）

```python
class MilkDecorator(CoffeeDecorator):
    def cost(self):
        return self._beverage.cost() + 50

class SugarDecorator(CoffeeDecorator):
    def cost(self):
        return self._beverage.cost() + 30
```

---

### ✅ 使用例

```python
coffee = PlainCoffee()
print(coffee.cost())  # 300

decorated = MilkDecorator(SugarDecorator(coffee))
print(decorated.cost())  # 300 + 30 + 50 = 380
```

---

## 3. Python的応用：関数デコレーターと構造パターンの融合

```python
def logging_decorator(func):
    def wrapper(*args, **kwargs):
        print(f"[LOG] 呼び出し: {func.__name__}")
        return func(*args, **kwargs)
    return wrapper

@logging_decorator
def greet(name):
    print(f"Hello, {name}!")
```

```python
greet("Alice")
# → [LOG] 呼び出し: greet
# → Hello, Alice!
```

→ **関数ベースでもDecorator思想を自然に適用可能**

---

## 4. 実務ユースケース

### ✅ UIコンポーネントへの装飾

→ ボタンに影・枠・アイコンなどを**動的に追加する**

---

### ✅ 認証・ロギング・トレースの挿入

→ メソッドやサービスに**関心の横断的機能を非侵入的に注入**

---

### ✅ ミドルウェアの設計（例：Flask / Django）

→ リクエスト処理を**チェーン構造で構築する**

---

### ✅ ストリーム処理（ファイル→暗号化→圧縮）

→ **段階的な加工をDecoratorで表現**

---

## 5. よくある誤用と対策

### ❌ 複数のデコレーターを順序依存で設計してしまう

→ ✅ **各Decoratorは順序に依存しない独立性を保つ設計**を心がける

---

### ❌ Decoratorが元のインターフェースを壊してしまう

→ ✅ `Decorator` は **元のメソッドと引数を忠実に模倣**すべき

---

### ❌ Decoratorのネストが可読性を損なう

→ ✅ **構成順に名前を付けて変数に代入し、明示的なスタック構造に**

---

## 結語

**Decoratorパターンとは、“機能を段階的に包み込みながら拡張する柔構造設計”である。**

- 継承に頼らず、**構成とラップによって機能を動的に追加・削除できる**  
- 主処理と副作用（ログ・認証・スタイル等）を**分離可能にし、再利用性を高める**  
- Pythonでは関数・クラスの両レベルで、**デコレーターの思想を直感的に実装可能**

**Pythonicとは、“動的で柔軟な拡張性を最小限の変更で実現する”ことであり、  
Decoratorパターンはその重ねられた機能美を、洗練されたレイヤーとしてコードに織り込む技法である。**
Pythonで実装するAdapterパターン：既存インターフェースを変換して再利用性を高める



## 概要

**Adapter（アダプター）パターン**は、  
既存のクラスやコードのインターフェースを**クライアントの期待する形に変換するための構造的デザインパターン**である。

このパターンを使うことで、**互換性のないインターフェース同士を繋ぎ、既存コードを再利用しやすくする**ことができる。

---

## 1. なぜAdapterが必要か？

### ❌ クライアントが期待するメソッド名と既存APIが合わない

```python
# クライアントは .request() を期待
# しかし実装クラスは .specific_request() を持つ
```

→ 名前や引数が異なることで、**既存コードを再利用できない**

---

### ✅ Adapterでクライアントに合わせたインターフェースを提供

```python
adapter = Adapter(LegacySystem())
adapter.request()
```

→ **インターフェースを変換して、透明に利用可能にする**

---

## 2. 基本構造

### ✅ Target（クライアントが期待するインターフェース）

```python
class Target:
    def request(self):
        raise NotImplementedError
```

---

### ✅ Adaptee（既存の実装）

```python
class LegacySystem:
    def specific_request(self):
        return "結果：レガシーAPI呼び出し"
```

---

### ✅ Adapter（変換ラッパー）

```python
class Adapter(Target):
    def __init__(self, adaptee: LegacySystem):
        self.adaptee = adaptee

    def request(self):
        result = self.adaptee.specific_request()
        print(f"変換されたインターフェース: {result}")
```

---

### ✅ 使用例

```python
legacy = LegacySystem()
adapter = Adapter(legacy)

adapter.request()
# → 変換されたインターフェース: 結果：レガシーAPI呼び出し
```

---

## 3. Python的応用：dictをクラスAPIに変換

```python
class DictAdapter:
    def __init__(self, data):
        self._data = data

    def get_name(self):
        return self._data.get("name")

    def get_age(self):
        return self._data.get("age")
```

```python
data = {"name": "Alice", "age": 30}
user = DictAdapter(data)
print(user.get_name())  # Alice
```

→ **動的構造（辞書やJSON）をクラスAPIとして扱うことで柔軟性と型安全性を両立**

---

## 4. 実務ユースケース

### ✅ 外部ライブラリやレガシーコードのラップ

→ 期待するインターフェースと合わないライブラリを**適応して利用可能に**

---

### ✅ APIレスポンス（JSON）のデータ構造変換

→ API仕様に依存せず、**統一された内部インターフェースを提供**

---

### ✅ デザイン変更時の互換レイヤー構築

→ 新旧のクラスを並行稼働させる**中間層としてAdapterを活用**

---

### ✅ テスト用のモック・スタブとして既存APIを再利用

→ クライアントコードを変更せず、**テスト対象を差し替え可能に**

---

## 5. よくある誤用と対策

### ❌ Adapterが過度にロジックを持つ

→ ✅ Adapterは**変換のみに責任を持つ**べきであり、処理はAdapteeに委ねる

---

### ❌ Adapteeに手を加えて対応しようとする

→ ✅ 既存コードには**変更を加えず、Adapterで対応するのが前提**

---

### ❌ Adapterが複数の責務を抱える

→ ✅ **単一の変換目的ごとにAdapterを設計**し、責務を分離する

---

## 結語

**Adapterパターンとは、“合わない形を無理に変えるのではなく、インターフェースを通訳する構造設計”である。**

- 名前や構造の不一致を、**変換クラスで吸収することで再利用性を高める**  
- 特に既存コードや外部ライブラリと連携する際の、**境界インターフェースとして機能**  
- Pythonでは柔軟なDuck Typingを活かし、**静的型言語に比べてAdapterの導入がより直感的に可能**

**Pythonicとは、“現実のギャップをコードで吸収し、構造の統一を図る”ことであり、  
Adapterパターンはその接続性と柔軟性を、実装の中に美しく融合させる技法である。**
Pythonで実装するBridgeパターン：実装と抽象の独立した拡張を可能にする構造



## 概要

**Bridge（ブリッジ）パターン**は、  
抽象部分（Abstraction）と実装部分（Implementation）を**分離し、それぞれ独立に拡張可能にするための構造設計パターン**である。

一般的に、継承によって抽象と実装を結びつけると、**クラスの組み合わせ数が爆発的に増える**。  
Bridgeパターンはこの問題を避け、**構成（Delegation）を用いて柔軟な拡張性と組み合わせの自由度を提供**する。

---

## 1. なぜBridgeが必要か？

### ❌ 継承ベースの組み合わせが爆発する構造

```text
- 丸い図形 × 青色
- 丸い図形 × 赤色
- 四角い図形 × 青色
- 四角い図形 × 赤色
...
```

→ **抽象と実装が固定結合され、拡張性が失われる**

---

### ✅ 抽象と実装を分離し、構成で結びつける

```python
circle = CircleShape(RedColor())
circle.draw()
```

→ **自由な組み合わせが可能な構造に**

---

## 2. 基本構造

### ✅ Implementor（実装部のインターフェース）

```python
class Color:
    def paint(self, shape_name):
        raise NotImplementedError
```

---

### ✅ ConcreteImplementor（実際の実装）

```python
class RedColor(Color):
    def paint(self, shape_name):
        print(f"赤色で{shape_name}を描画します。")

class BlueColor(Color):
    def paint(self, shape_name):
        print(f"青色で{shape_name}を描画します。")
```

---

### ✅ Abstraction（抽象部分）

```python
class Shape:
    def __init__(self, color: Color):
        self.color = color

    def draw(self):
        raise NotImplementedError
```

---

### ✅ RefinedAbstraction（具体的な抽象）

```python
class CircleShape(Shape):
    def draw(self):
        self.color.paint("円")

class SquareShape(Shape):
    def draw(self):
        self.color.paint("四角")
```

---

### ✅ 使用例

```python
shape1 = CircleShape(RedColor())
shape2 = SquareShape(BlueColor())

shape1.draw()  # → 赤色で円を描画します。
shape2.draw()  # → 青色で四角を描画します。
```

---

## 3. Python的応用：動的インジェクションによるBridge構築

```python
class Logger:
    def log(self, message):
        raise NotImplementedError

class ConsoleLogger(Logger):
    def log(self, message):
        print(f"[Console] {message}")

class FileLogger(Logger):
    def log(self, message):
        with open("log.txt", "a") as f:
            f.write(message + "\n")
```

```python
class App:
    def __init__(self, logger: Logger):
        self.logger = logger

    def run(self):
        self.logger.log("アプリケーションを起動")
```

→ **ログ出力先を変更するだけでアプリ本体を変更せずに振る舞いを拡張**

---

## 4. 実務ユースケース

### ✅ UIテーマ × コンポーネント（色・動作の分離）

→ ダークテーマ/ライトテーマ × ボタン/スライダーの独立拡張

---

### ✅ デバイス × プラットフォーム

→ プリンタ × OS、メディアプレーヤー × 出力形式（HDMI / Bluetooth）

---

### ✅ ロガー × 出力先（DB / ファイル / コンソール）

→ **出力先の切り替えによるログ設計の柔軟性向上**

---

### ✅ データ変換 × 形式（CSV / JSON / XML）

→ 変換ロジックとデータソースの独立管理

---

## 5. よくある誤用と対策

### ❌ 継承で抽象と実装を結びつける設計

→ ✅ 実装はクラス外から構成（Delegation）として注入すべき

---

### ❌ 実装クラスが抽象部分に依存している

→ ✅ **依存は一方向（抽象 → 実装）に保つこと**

---

### ❌ 抽象/実装の責務が曖昧

→ ✅ 抽象は**構造と意味**、実装は**動作と処理の実体**に分離すべき

---

## 結語

**Bridgeパターンとは、“抽象と実装の結合を緩め、拡張性を最大化する設計技法”である。**

- 継承ではなく構成により、**機能の組み合わせの自由度と柔軟性を実現**  
- 実装と抽象をそれぞれ独立に設計・拡張可能にすることで、**将来の変更に強い構造が生まれる**  
- Pythonの動的型と依存注入により、**直感的かつ強力にBridge構造を組むことができる**

**Pythonicとは、“構造と処理の独立性を意識して設計する”ことであり、  
Bridgeパターンはその設計原則に基づく分離と再構成を、コードに理論的美しさとして刻む技法である。**
Pythonで実装するCompositeパターン：ツリー構造を透過的に扱うための再帰的設計



## 概要

**Composite（コンポジット）パターン**は、  
**個（Leaf）と集合（Composite）を同一のインターフェースで扱う**ことで、  
ツリー構造のような階層的なオブジェクトを**透過的に処理可能にする再帰的構造設計パターン**である。

これにより、**個別要素と複合要素を統一的に操作できる**ため、  
再帰的な構造を持つドメイン（ファイルシステム、UIコンポーネント、シーン構造など）に適用される。

---

## 1. なぜCompositeパターンが必要か？

### ❌ 個と集合を分けて処理する複雑なロジック

```python
for item in items:
    if isinstance(item, Leaf):
        item.operation()
    else:
        for sub in item.children:
            sub.operation()
```

→ **処理の分岐が必要となり、コードが汚染される**

---

### ✅ 個も集合も同一の操作インターフェースを持つ

```python
root.operation()
```

→ **ノードとツリー全体を同様に扱える再帰的かつ透過的な設計に**

---

## 2. 基本構造

### ✅ Component（共通インターフェース）

```python
class Component:
    def operation(self):
        raise NotImplementedError
```

---

### ✅ Leaf（個のオブジェクト）

```python
class Leaf(Component):
    def __init__(self, name):
        self.name = name

    def operation(self):
        print(f"Leaf: {self.name}")
```

---

### ✅ Composite（子を持つオブジェクト）

```python
class Composite(Component):
    def __init__(self, name):
        self.name = name
        self.children = []

    def add(self, component: Component):
        self.children.append(component)

    def operation(self):
        print(f"Composite: {self.name}")
        for child in self.children:
            child.operation()
```

---

### ✅ 使用例

```python
root = Composite("root")
child1 = Leaf("A")
child2 = Leaf("B")
child_group = Composite("group1")
child_group.add(Leaf("C"))
child_group.add(Leaf("D"))

root.add(child1)
root.add(child2)
root.add(child_group)

root.operation()
```

出力:
```
Composite: root
Leaf: A
Leaf: B
Composite: group1
Leaf: C
Leaf: D
```

---

## 3. Python的応用：__iter__で再帰的走査を可能に

```python
class CompositeIterable(Composite):
    def __iter__(self):
        for child in self.children:
            yield child
            if isinstance(child, CompositeIterable):
                yield from child
```

```python
tree = CompositeIterable("root")
tree.add(Leaf("1"))
sub = CompositeIterable("sub")
sub.add(Leaf("2"))
tree.add(sub)

for node in tree:
    node.operation()
```

→ **ツリー構造をPythonイテレータで柔らかく展開可能に**

---

## 4. 実務ユースケース

### ✅ ファイルシステムの構造表現

→ フォルダ（Composite）とファイル（Leaf）を統一的に操作

---

### ✅ UIコンポーネントツリーの構築

→ ボタン、ラベル、パネルなどを再帰的に組み合わせて描画

---

### ✅ シーン構造やゲームオブジェクトの管理

→ 子ノードを持つEntity構造のトラバース処理に活用

---

### ✅ ドキュメント・HTMLなどの構文構造表現

→ セクション、段落、テキストを階層的にレンダリング処理

---

## 5. よくある誤用と対策

### ❌ 子要素の追加・削除をLeafにも許容してしまう

→ ✅ Leafは add/remove を持たず、**Composite専用に定義する**

---

### ❌ コンポーネント間の依存性が密結合

→ ✅ Componentインターフェースを厳格に定義し、**個と集合の責務を明確に分離**

---

### ❌ 複雑すぎる再帰構造をそのまま出力してしまう

→ ✅ 再帰処理における深さや出力制御を**適切に設計する**

---

## 結語

**Compositeパターンとは、“個と集合を統一的に扱い、階層構造を透過的に表現するための構造デザイン”である。**

- 再帰的構造において、**共通インターフェースによる柔軟で一貫した操作が可能に**  
- ツリー構造の設計において、**構造と処理の責務分離を明確化**  
- Pythonではクラスと動的な型の組み合わせにより、**型安全かつ柔軟にComposite構造を構築可能**

**Pythonicとは、“複雑な構造も一つの統一的な視点で捉える”ことであり、  
Compositeパターンはその抽象と具体を、コードの中で優雅に溶け合わせる設計手法である。**
Amplify Gen 2 × React × Tailwind CSS で始めるモダンなフルスタック開発環境構築

## はじめに
こんにちは！この記事では、**Amplify Gen 2、Vite + React、Tailwind CSS** を組み合わせたモダンな開発環境をゼロから構築する手順をまとめます。
コードベース＆Gitブランチで完全管理する構成を採用しています。

## 📦 技術スタック
フロントエンド：React 19（+ TypeScript）
CSS：Tailwind CSS
バンドラ：Vite
バックエンド：Amplify Gen 2（Cognito、Lambda など）
デプロイ：Amplify Console（GitHub連携）

### 1. React プロジェクトの構築（Vite）
```bash
npm create vite@latest my-app --template react-ts
cd my-app
npm install
npm run dev
```
--template react-ts によって TypeScript + React の構成が自動で準備されます。

### 2. Tailwind CSS の導入
```bash
npm install tailwindcss @tailwindcss/vite
```
vite.config.ts を編集する
```bash
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import tailwindcss from '@tailwindcss/vite'

export default defineConfig({
  plugins: [
      react(),
      tailwindcss()],
})
```
src/index.css を編集する
```css
@import "tailwindcss";
```
App.tsx を編集する
```tsx
function App() {
  return (
    <div className="flex items-center justify-center min-h-screen">
      <h1 className="text-3xl font-bold text-blue-500">
        Hello, Tailwind CSS with Vite!
      </h1>
    </div>
  )
}
```
### 3. Amplify Gen 2 の導入
```bash
npm create amplify@latest
```
対話形式で「このディレクトリに作成」(.)を選択

自動的に amplify/ ディレクトリ が生成されます

### 4. GitHub に push ＆ Amplify Console に連携
```bash
git add .
git commit -m "feat: initial Amplify Gen2 + Vite + Tailwind project"
git push
```
Amplify Console から GitHub を連携 → 対象リポジトリとブランチを選ぶ！

### 5. amplify.yml の構成
```yaml
version: 1
frontend:
  phases:
    preBuild:
      commands:
        - npm ci --cache .npm --prefer-offline
    build:
      commands:
        - npm run build
  artifacts:
    baseDirectory: dist
    files:
      - '**/*'
  cache:
    paths:
      - .npm/**/*
backend:
  phases:
    build:
      commands:
        - npm ci --cache .npm --prefer-offline
        - npx ampx pipeline-deploy --branch $AWS_BRANCH --app-id $AWS_APP_ID
```
## まとめ
この記事では、**Amplify Gen 2、Vite + React、Tailwind CSS** を使ったモダンなフロントエンド開発環境の構築手順を解説しました。
ハッカソン個人備忘録⑱：FastAPI × Fargate を安定稼働させるための Dockerfile の書き方を整理してみた

## はじめに
本記事では、AWS Fargate 環境で FastAPI アプリケーションを動かす際の Dockerfile のベストプラクティスについて解説します。

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

特に、本番運用を前提とした設定に焦点を当て、一般的な開発用構成からの改善点を紹介します。

## 書こうと思ったきっかけ
Fargate を使って FastAPI アプリケーションをデプロイしようとした際、`--reload` オプションが含まれた Dockerfile の構成となっておりました。

これは開発には便利ですが、本番環境ではパフォーマンスやリソース効率の面で不適切なため、正しい構成と改善ポイントを整理していきます。

## Fargate 環境における Dockerfile のベストプラクティスと改善ポイント

### 背景
Fargate 環境で FastAPI アプリケーションを動かすために作成された以下の Dockerfile について、本番運用を見据えた改善が必要かどうかを検討します。

```Dockerfile
FROM python:3.11-slim

WORKDIR /app

COPY app/requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

COPY app/ .

EXPOSE 8000

CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000", "--reload"]
```

### ✅ 現状の構成で問題ない点
- **軽量なベースイメージ**：`python:3.11-slim` を使用しており、Fargate のようなコンテナ実行環境に適しています。
- **作業ディレクトリの設定**：`WORKDIR /app` により作業ディレクトリが適切に指定されています。
- **依存関係のインストール**：`pip install --no-cache-dir -r requirements.txt` により、キャッシュを抑えた効率的なインストールが行われています。
- **アプリケーションのコピー**：`COPY app/ .` によりアプリケーションがコンテナに配置されます。

### 🔧 修正・改善すべきポイント（本番環境運用を前提に）

#### ① `--reload` は開発用
`--reload` オプションはコードの変更を即時反映するための機能であり、本番環境では不要かつパフォーマンスに悪影響を与える可能性があります。

**修正前：**
```Dockerfile
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000", "--reload"]
```
**修正後：**
```Dockerfile
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]
```

#### ② requirements.txt に必要なパッケージが記載されているか
FastAPI アプリの場合、以下のような記述が `requirements.txt` に含まれている必要があります：
```txt
fastapi
uvicorn[standard]
```

#### ③ COPY 命令の改善
より簡潔に記述するためには、次のように記載すると良いでしょう：
```Dockerfile
COPY app/requirements.txt requirements.txt
```

#### ④ ログレベルの明示（必要に応じて）
CloudWatch Logs にログを送る場合などは、ログレベルを `uvicorn` 起動時に指定しておくと便利です。
```Dockerfile
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000", "--log-level", "info"]
```

### ✅ 修正後の推奨 Dockerfile
```Dockerfile
FROM python:3.11-slim

WORKDIR /app

COPY app/requirements.txt requirements.txt

RUN pip install --no-cache-dir -r requirements.txt

COPY app/ .

EXPOSE 8000

CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000", "--log-level", "info"]
```

### 補足（自分調べ）
`main.py` の内容が FastAPI 以外（例：Flask）の場合、CMD の内容は変更が必要になります。その場合は、別途アプリケーションの構成に応じて調整してください。

また、`requirements.txt` や `main.py` の内容確認も含めて、さらに最適化したい場合は、それらのファイル内容も確認しながら進めるのが良いでしょう。

## まとめ
本記事では、Fargate 環境で FastAPI アプリを運用するための Dockerfile を見直し、特に `--reload` の削除やログレベルの指定など、本番運用における最適化のポイントを紹介しました。

Dockerfile はアプリケーションの安定性やパフォーマンスに大きな影響を与えるため、正しい設定で運用することが重要です！
[備忘録]カテゴリをDBに登録＆取得してフロントに表示してみた

## まえおき
### 自分用なので端折ってるところ多いです
## やりたいこと
- SQLALchemyでDBとカテゴリーテーブルを初期化
- 初期カテゴリーデータを登録
- Flask APIでカテゴリー一覧を返す
- JavaScriptでカテゴリー取得→ボタン表示
- ついでにCIRSエラー対処

## DBを初期化してカテゴリー登録
モデル定義
~~~python:models.py
from flask_sqlalchemy import SQLAlchemy

db = SQLAlchemy()

class Category(db.Model):
    __tablename__ = 'categories'

    id = db.Column(db.Integer, primary_key=True)
    name = db.Column(db.String(50), nullable=False)
    expence_type = db.Column(db.String(10), nullable=False)
    
~~~
初期化スクリプト
~~~python:init_db.py
from flask import Flask
from models import db, Category

app = Flask(__name__)
app.config['SQLALCHEMY_DATABASE_URI'] = 'sqlite:///your_db.sqlite'
app.config['SQLALCHEMY_TRACK_MODIFICATIONS'] = False

db.init_app(app)

initial_categories = [
    # expense
    ("食費", "expense"), ("交通費", "expense"), ("娯楽", "expense"),
    ("日用品", "expense"), ("医療", "expense"), ("通信費", "expense"),
    ("交際費", "expense"), ("教育", "expense"), ("光熱費", "expense"),
    ("家賃", "expense"), ("貯金", "expense"), ("その他", "expense"),
    # income
    ("給料", "income"), ("ボーナス", "income"), ("副業", "income"),
    ("投資収入", "income"), ("その他収入", "income"),
]

with app.app_context():
    db.drop_all()
    db.create_all()

    for name, expence_type in initial_categories:
        db.session.add(Category(name=name, expence_type=expence_type))
    
    db.session.commit()
    print("DB初期化＆カテゴリ登録完了！")

~~~
実行
~~~bash
python init_db.py
~~~

## Flask APIを作成
~~~python:app.py
from flask import Flask, jsonify
from flask_cors import CORS
from models import db, Category

app = Flask(__name__)
app.config['SQLALCHEMY_DATABASE_URI'] = 'sqlite:///your_db.sqlite'
app.config['SQLALCHEMY_TRACK_MODIFICATIONS'] = False

db.init_app(app)
CORS(app)

@app.route("/api/categories")
def get_categories():
    categories = Category.query.all()
    result = [
        {
            "id": cat.id,
            "name": cat.name,
            "expence_type": cat.expence_type
        }
        for cat in categories
    ]
    return jsonify(result)

if __name__ == "__main__":
    app.run(debug=True)

~~~

## JavaScriptでカテゴリを取得＆表示
~~~js
async fetchCategories() {
    try {
        const res = await fetch("http://localhost:5000/api/categories");
        const data = await res.json();

        const categories = { expense: [], income: [] };
        data.forEach(item => {
            const type = item.expence_type;
            if (type === "expense" || type === "income") {
                categories[type].push(item.name);
            }
        });

        this.categories = categories;
        this.render(); // 表示更新
    } catch (err) {
        console.error("カテゴリ取得エラー:", err);
        alert("カテゴリーの取得に失敗しました");
    }
}

~~~

## CORS対策
- pip install flask-cors
- from flask-cors import CORS
- CORS(app) を追加

## 最後に
~~~
# DB初期化（1回だけ）
python init_db.py

# Flaskアプリ起動
python app.py

# フロントから http://localhost:5000/api/categories
にアクセス

~~~
Ubuntu24.04 / Docker Compose で immich を環境構築する

# immich とは
Googleフォトの代わりとなる、オープンソースのソリューションです。クラウドでの写真・動画の保存は、容量制限があるためこういったオープンソースを使用し管理するのに向いているそうです。

そんなわけで自宅の検証環境(Proxmox)に、immich をインストールしたかったので調べてみました。ちなみに公式サイトでのインストール方法で簡単にできまので・・・いつもの個人的な備忘録として残しておきたかったのです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/44540/4b0de704-7e89-4fb3-9518-c3981bd98481.png)

# Ubuntu24.04 に doker をインストール
下記で doker をインストールします。毎回ググルのでこれこそ備忘録。

https://www.kagoya.jp/howto/cloud/container/dockerubuntu/

https://qiita.com/tf63/items/c21549ba44224722f301

# immich をインストール
Docker を使用したインストールを推奨されています。公式サイトとおりに実行すれば最新の immich がインストールされます。

https://immich.app/docs/install/docker-compose/

ちなみに個人的に NAS で写真・動画を管理したかったのでそこだけ変更しています。PostgresのID/PWがありセキュリティの観点から変更したほうが好ましいですが、自宅なのでそのままとしています。

.env の設定

https://zenn.dev/nori_suke/articles/c9d5b3f230a4c7

# nfs クライアントの設定
nfsマウントはシステム起動時でなく、アクセス時に NFS をマウントするようにします。

https://www.server-world.info/query?os=Ubuntu_22.04&p=nfs&f=2

# アクセスしてみる
immich のアクセスは `http://localhost:2283` です。
外部からアクセスするのには、SSLを設定したりするのがベストですね。

# アップグレードする
immich を使用していると”アップグレードがあるよ”というダイアログが表示されるので、下記手順にてアップグレードしましょう。公式のリンクを貼り付けておきます。

https://immich.app/docs/install/upgrading/

# スマフォのアプリがある
アプリを使用してみた感じかなりいい。当然ですが自宅wifiの場合、うらでバックアップ処理が走ってくれるし顔認証してのグループ化などいい。

https://immich.app/docs/features/mobile-app/

# immich を使用してみて
iOSのアプリと連動し自宅(wifi)の場合、写真・動画をアップするようにしていると便利でした。自分はそんなにアプリいれていないつもりで 128G を使用していますが、長くスマフォ使っていると結構、写真があるのだなと。。。あとやっぱりバックアップは大切かなとｗ

意外だったのは、Windows に WSL2 いれて immich 構築している方が多い。いい時代です。
ハッカソン個人備忘録⑰：カジュアルな稼働確認で理解する！CloudFormationテンプレート解説【ECS on Fargate + RDS構成】

## はじめに
本記事では、AWS CloudFormationを使ってECS（Fargate）とRDS（MySQL）を組み合わせたシンプルなWebアプリケーション環境を自動的に構築するテンプレートの内容を紹介します。

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

開発・検証環境の立ち上げや、AWSにおけるモダンな構成の学習にも役立ちます。

## 書こうと思ったきっかけ
インフラのコード化（Infrastructure as Code）の学習を進める中で、CloudFormationにより自動化しています。

https://github.com/free-honda/backend/tree/main/infra

実際に手を動かしてテンプレートを作成することで、VPCやECS、RDSといった各リソースのつながりを深く理解することができたため、備忘録としてまとめようと思いました。

## 全体構成図

```
+--------------------------+
|      AWS Infrastructure |
+--------------------------+

     └─────────────────────────────────────────────┘
     │                VPC (10.0.0.0/16)            │
     │                                             │
     │  ┌─────────────┐   ┌─────────────┐          │
     │  │ Subnet A    │   │ Subnet C    │          │
     │  │ (Public AZ1)│   │ (Public AZ2)│          │
     │  └────┬────────┘   └────┬────────┘          │
     │       │                 │                   │
     │       ▼                 ▼                   │
     │   ECS Service (Fargate Tasks)               │
     │     - Dockerコンテナ                          │
     │     - HTTP:8000                             │
     │     - 環境変数にRDSの情報を添付                  │
     │                                             │
     │       ▼                 ▼                   │
     │       RDS Subnet Group (2AZに跨る)           │
     │         └→ RDS MySQL                        │
     │            - 非公開アクセス(PubliclyAccessible: false)│
     │            - ECSから接続可                    │
     └─────────────────────────────────────────────┘

            ↑
     Internet Gateway（パブリックサブネット経由）
```

## 主なリソースと役割

| リソース名 | 説明 |
|------------|------|
| **VPC** | 独自のネットワーク空間（10.0.0.0/16） |
| **PublicSubnet1, PublicSubnet2** | 2つのAZにまたがるパブリックサブネット |
| **InternetGateway, RouteTable** | ECSサービスを外部と通信させるためのルート |
| **SecurityGroup, RDSSecurityGroup** | HTTP(80,8000)とMySQL(3306)用のアクセス制御 |
| **MyRDS** | パスワード付きMySQL RDS（パブリックアクセスなし） |
| **DBSubnetGroup** | RDSに必要な複数AZ対応のサブネットグループ |
| **ECSCluster** | Fargateタスクの実行先クラスター |
| **ECSTaskDefinition** | 環境変数にRDS接続情報を含むDocker定義 |
| **ECSService** | タスクの実行と自動再起動（Fargate） |

## 補足・改善ポイント

### セキュリティ強化
- `MYSQL_PASSWORD` は Secrets Manager などから取得する設計が推奨です。
- RDSのポート(3306)は開発中以外では `0.0.0.0/0` にしないよう注意。

### スケーリングを考慮
- `DesiredCount: 1` のままでは1インスタンスのみ。ALBを導入すれば将来的なオートスケーリングにも対応できます。

### 公開アクセスの調整
- `AssignPublicIp: ENABLED` は検証用としてはOK。本番ではALB経由での非公開構成が推奨。

## 今後追加できる構成例

| 追加リソース | 説明 |
|--------------|------|
| **ALB (Application Load Balancer)** | ECSの前段に配置。HTTPSやスケーリング対応が可能に |
| **Secrets Manager** | DBパスワードやAPIキーを安全に管理・参照 |
| **CloudWatch Logs** | ECSやアプリケーションのログ収集・監視 |
| **EFS** | 状態を持つアプリケーションに便利な共有ストレージ |
| **Private Subnet** | RDSやバックエンドアプリを非公開サブネットに配置 |

## まとめ
このテンプレートは、シンプルながら拡張性のあるベース構成となっており、検証・開発環境として最適です。

:::note warn
**本番環境へ発展させる際は、セキュリティやスケーラビリティへの配慮を加えることで、安全かつ堅牢なインフラを構築することができます。**
:::

CloudFormationを活用することで、AWSインフラの構築をスピーディかつ再現性のあるものにできるため、学習やチーム開発にも非常におすすめです！！