OmniAICreator/Qiita-1.07M huggingface dataset:
なぜアウトプットし続けるべきなのか？エンジニアが発信すると、未来が変わる理由

この記事はQiita Tech Festa 2025参加記事です。

約1年前から株式会社うるる 人事部にて、エンジニア採用を担当しています！
正直なところ、うるるは今年のQiita Tech Festaへ参加すべきか、少し悩んでいました。 

「エンジニアはただでさえ忙しいのに、ブログ執筆や登壇などの技術広報をお願いするのは果たして正しいことなのだろうか……」と。

そんな葛藤があったからこそ、**技術広報やアウトプットがもたらすメリットを改めて整理したい**と思い、この記事を書いています。



## 技術広報って、結局誰のためになるの？

技術広報というと、企業のブランディングやPR活動のようなイメージが強いかもしれません。  
でも実際は、**関わる人すべてにメリットがある行動**です。

この記事では、以下の3つの視点で技術広報の価値を整理してみました：

- エンジニア個人の視点  
- エンジニア組織の視点  
- 採用の視点  


## 技術広報のメリット

### 🔹 エンジニア個人にとってのメリット

- **自分の技術や思考を“見える化”できる**  
　→ 自己理解が深まり、周囲にも伝わりやすくなる

- **学びや考えが整理される**  
　→ 書いたり話したりする過程で理解が深まる

- **社内外でのプレゼンス向上**  
　→ 登壇依頼や執筆依頼が来たりして、チャンスが増える

- **人脈の輪が広がる**  
　→ カンファレンスや勉強会で「あの記事読みました！」と声をかけられたり、SNSで交流のある社外のエンジニアが増えたりする


### 🔹 エンジニア組織にとってのメリット

- **技術文化の発信・透明化**  
　→ 外部に向けて「中の人のリアル」が伝わる

- **採用効果が高まる**  
　→ 候補者が「どんなチームか」を事前に知れる

- **社内ナレッジの共有**  
　→ 書く文化が育つと、属人化の防止にもつながる


### 🔹 採用観点でのメリット

採用活動を行う中で日々感じるのは、**求職者は「現場のリアル」を求めている**ということです。

- **スカウト返信率・応募率が上がる**
- **選考時のミスマッチが減る**
- **カルチャーフィットした人材が集まりやすくなる**

企業公式のメッセージよりも、現場エンジニア自身による発信のほうが**圧倒的に信頼されやすい**ですし、  技術広報は候補者の「入社後のギャップを減らす手段」にもなります。

そして、会社・組織にマッチしている方を採用できれば、エンジニア組織が強化されることに繋がっていきます。


## 実体験：たった1本の記事が採用を変えた

前職で立ち上げ間もないスタートアップ企業のエンジニア採用人事をやっていた際に、CTOが書いた1本のnote記事がバズり、Xを中心に拡散されたことがありました。

すると採用にも予想以上の反響があり、**スカウトの返信率が一時的に2倍に跳ね上がった**んです。  
この追い風を活かして、わずか3か月でミドルクラスのエンジニア3名の採用に成功。これにより、エンジニア組織の拡大を一気に進めることができたのです。

もちろん採用人事の私は大喜びですが、以下2点の観点で現場エンジニアの方々にもすごく喜んでもらえました...！

### 🔹 ①良質な母集団の形成のおかげで、無駄な面談・面接が減る

バズった記事によって、自社のプロダクト開発の価値観や、技術スタンスがクリアに伝わり、それに共感した応募者が集まりました。その結果、志向性のミスマッチが少なくなり、面談・面接の数を無理に増やすことなく、効率よく候補者選考を進められました。



### 🔹 ②「チームを強くする」エンジニアが採用できる

採用できた3名は、いずれも入社後すぐに価値を発揮し、チームの技術力を底上げするような活躍を見せてくれました。技術広報を通じて、自社の価値観や技術スタンスに共鳴してくれる人に出会えたことで、単に枠を埋めるだけでなく、組織の質的な成長につなげることができたのです。


この体験から、技術広報は「余裕のある会社がやるブランディング活動」ではなく、  
**採用・組織づくりの強力なレバレッジになる行動**なんだと実感しました。


## 結論：エンジニアが発信すると、未来が変わる

エンジニアに技術広報をお願いするのは、負担をかける行為ではなく、  
**本人とチームの未来をより良くするための種まき**です。

そしてその種は、採用や技術的なつながり、仲間づくりといった形で、いずれ確実に実を結びます。

忙しい中でも、無理のない形でアウトプットをしていく文化を支えたい  
― そんな思いでこの記事を書いてみました。


## おわりに

この記事は、エンジニア採用担当として悩んできた自分自身への問いかけでもありました。

もし発信することに億劫さを感じているなら。  
あるいは、エンジニアに発信をお願いする立場で迷っているなら。

そんな方の背中をそっと押すきっかけになれば嬉しいです。
CEH(v12)にギリギリで受かった話

忘れないうちにどうだったかを書き残しておきたいと思います。参考になれば嬉しいです。

## 試験結果
まず、試験結果についてですが、2回目の試験で受かりました。
1度目は67%で落ちています。
2度目で、71％で合格しました。本当にギリギリでした。


## 学習に活用したもの

### (公式テキストの)電子書籍
GSX社の公式トレーニングを受けたので、その時の電子書籍です。これを全部覚えようと思ったのですが、量が多すぎてすぐに諦めました。基本的には、後述の問題集でのわからない単語を調べるのに使っていました。

### CEH Certified Ethical Hacker Practice Exams
周りにCEHに受かった人がいたので、その人に聞いてみると「この問題集ほとんどそこからで出たよ」と言われたので買いました。使い方としては、Google画像翻訳で日本語にしてnoteにまとめて、4周くらい問いて知らない単語を頭にいれるようにしました。とりあえず、この問題集はほぼ完璧に答えられるようにしました。

https://www.amazon.co.jp/Certified-Ethical-Hacker-Practice-Exams/dp/126426996X/ref=pd_sbs_d_sccl_1_1/358-4596371-7454329?pd_rd_w=thWWD&content-id=amzn1.sym.13eb81e1-7d13-4eb9-803d-fea9198bc9c1&pf_rd_p=13eb81e1-7d13-4eb9-803d-fea9198bc9c1&pf_rd_r=2W3KVGN7KGD5XN2K0VS6&pd_rd_wg=wdcEL&pd_rd_r=4b479650-5fd6-41fd-a5a1-b82080bebd14&pd_rd_i=126426996X&psc=1

結論ですが、1問も似た問題は実際に試験には出てきませんでした・・。ただ、意味がなかったわけではなく、事前に軽めな試験慣れができてよかったって感じです。

### Certified Ethical Hacker v9
他の方も上げている問題サイトです。若干バージョンが古いので試験前に適当にカテゴリを選んで見ていました。実際に試験でも出てきたので、見ていて良かったです。

https://yeahhub.com/cehv9-practice-exam-questions/index.php

### Chat-GPT
とにかく理解できない単語をずっと聞きまくっていました。全てを鵜呑みにするわけではないので、上述の公式テキストと合わせて活用していました。

### Quizlet
暗記アプリです。有料版を使っていました。基本的にはChat-GPTにnmapのオプションやGoogleハッキングのコマンドをQuizletにインポートできる形で出力してもらっていました。その他にも、他のユーザの方がCEH向けに作った暗記セットもあったので、使わせてもらっていました。

https://quizlet.com/jp


## 1回目と2回目の試験について
ほかの方の記事では2回目は日本語での試験が受けられなかったと書いてあったので心配していましたが、2回目も日本語で受けられました。試験内容は1回目と同じ問題が出ましたが、感覚では3〜4割くらいって感じです。私は1回目の落ちた直後に記憶にある単語（文中や選択肢など）をとにかくノートに書きまくり、覚え直しました。2回目で試験に受かったのはそれが大きかったと思います。

## 見直しは大事
２回目の試験で一通り終わったあとに、どうあがいても落ちてそうだなと思ったので、もう試験会場を出ようと思いましたが、迷った問題（ピン留めできるようになっています。）を見返すことにしました。すると「あれ、これってこっちの選択肢のほうがまだしっくりくるか、、」と思い解答を変えたのが２問あります。おそらくそれがなかったら、１度目の試験と同じくギリギリで落ちていたと思います。


## 最後に
ざっくりと書いただけですが、とりあえず受かってホッとしています。本当に出題幅が広い試験だなと思いますが、得意分野と苦手分野を早くみつけて、苦手分野を重点的に覚えていくと良い気がします。
とりあえずnampコマンドのオプションとgoogleハッキングのコマンドは覚えても絶対損は無いので暗記することをおすすめします。
頑張ってください！
【Salesforce】新規商談売上に関する考え方

お客様との会話で以下のようなことを学んだため、備忘として記録します。

・お客様からのご要望：「活動における新規活動の割合を～％以上にしたい」
→会社として新規顧客や商品の商談における売上を増加させたく、そこから新規開拓の活動数を全体の活動数の～%以上にしたいというもの
　ただ割合の算出の仕方（新規開拓活動数/全体の活動数にするのか、それとも新規活動に費やした時間/全活動に費やした時間など）については検討中のため、もし他社事例があれば共有してほしい

 ・SF様からのご回答：「新規商談数からブレイクダウンして考えるべき」
 →他社様でも使用している考え方だが、あくまでも目的は新規商談（新規取引先との商談、既存顧客との新規商品に関する商談）数を増やすことであるため、むやみに新規開拓活動の割合を追うのではなく、新規商談の件数が少ない部署や担当にフォーカスして活動の分析を行うのが良い
 　また活動を商談と紐づけることにより、新規商談受注のための活動に費やした時間なども算出できるようになるため、そのあたりも要検討
　仕組みよりもルール作りが大事なイメージ

 とのこと
[Linux] ローカリゼーション_文字コード

# 文字コード
| 文字コード      | 説明                                                                                                                                        |
| ---------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| ASCII      | - 7ビットの文字コード<br>- 128種類の文字（英数字、記号、制御コード）を表現                                                                                               |
| ISO-8859   | - ASCII を 8ビットに拡張したもの<br>- 256種類の文字を表現                                                                                                    |
| EUC-JP     | - UNIX 環境で標準的に利用されていた日本語文字コード                                                                                                             |
| Shift\_JIS | - Windows や Mac OS で標準的に利用される日本語文字コード                                                                                                     |
| Unicode    | - 多言語を扱うために作成された符号化文字集合（文字コード表）<br>- Unicode で定義された文字を表現する符号化方式には以下がある：<br>    - UTF-8（多くの Linux で標準的に利用）<br>    - UTF-16<br>    - UTF-32 |

# Ping-t
- [4741_ASCII](https://mondai.ping-t.com/question_subjects/32/question_sessions/33767513/progressing_questions/517007551)
『SSH・SCP簡易操作ツール for WindowsConsole』（ポータブルにも最適）

## きっかけ
ちょっと前にTeraTermがED25519に未対応だったりして（現行バージョンでは使えます。）
Windows標準で使えるようになったSSHクライアントを代替利用していました。
その後この軽量なSSH接続環境が思いの他快適だったので、すっかりメインで使っていましたが、相変わらずファイル転送はWinSCPに任せていました。
しかしそろそろこの軽量環境に合わせようと思い、
『SSH・SCP簡易操作ツール for WindowsConsole』としてまとめてみました。


## 実際のコード
- `SSH・SCP簡易操作ツール for WindowsConsole.bat`
  - ファイルの保存は、SJIS, CR+LF推奨。（UTF-8だと文字化けするため）

```batch:2025.6.19版
@echo off

cd %~dp0

REM 環境変数'[~]'を置き換える
SET ID=[ユーザーアカウント]
SET PWD=[パスワード]
SET IPADDR=[接続先サーバIPアドレス]
SET PORT=[SSH/SCPポート番号]
SET SSHPRVKEY=ssh\[秘密鍵ファイル(ED25519等)]

echo ========================================
echo SSH・SCP簡易操作ツール for WindowsConsole
echo 接続先: %IPADDR%
echo ユーザー: %ID%
echo ========================================
choice /c 12 /m どちらを使いますか？（1：コンソール、2：アップロード）： /N

if %errorlevel%==2 goto SCP
if %errorlevel%==1 goto SSH

goto END


:SSH
REM echo パスワード表示（非推奨）: %PWD%
ssh -i "%~dp0%SSHPRVKEY%" -p %PORT% %ID%@%IPADDR%

pause
goto END


:SCP
REM https://qiita.com/yaju/items/98ec88701e47298ec6ef
set InitialDirectory=%~dp0
set Title=アップロードするファイルを選択してください
set "FILTER=すべてのファイル (*.*)|*.*"
set diaglog="Add-Type -AssemblyName System.Windows.Forms;
set diaglog=%diaglog%$f = New-Object Windows.Forms.OpenFileDialog;
set diaglog=%diaglog%$f.Filter = '%FILTER%';
set diaglog=%diaglog%$f.InitialDirectory = '%InitialDirectory%';
set diaglog=%diaglog%$f.Title = '%Title%';
set diaglog=%diaglog%$f.ShowHelp = $true;
set diaglog=%diaglog%$f.Multiselect = $true;
set diaglog=%diaglog%[void]$f.ShowDialog();
set diaglog=%diaglog%if ($f.Multiselect) { $f.FileNames } else { $f.FileName }"

REM 一時ファイルに選択結果を出力
set TMPFILE=%TEMP%\selected_files.txt
del "%TMPFILE%" >nul 2>nul

powershell -ExecutionPolicy RemoteSigned -NoProfile -Command %diaglog% > "%TMPFILE%"

REM ファイルごとにSCPでアップロード
for /f "usebackq delims=" %%I in ("%TMPFILE%") do (
    echo アップロード: "%%I"
    REM scpでアップロード（ssh key認証orパスワード入力）
    REM echo パスワード表示（非推奨）: %PWD%
    scp -i "%~dp0%SSHPRVKEY%" -P %PORT% "%%I" %ID%@%IPADDR%:/home/%ID%/
)

del "%TMPFILE%" >nul 2>nul
pause
goto END


:END
exit /b
```

## 動作の様子
- 1：コンソール（SSH）
![SSH.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1667967/cd3225dd-f578-4c29-93f4-2981d2971d8c.gif)

- 2：アップロード（SCP）
![SCP.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1667967/6167fa26-f40e-4c4a-9460-14c4a6fa3e1a.gif)

以上です。
プロデル、調査 その47

# 概要
プロデルが、CLRらしいので、調べて見た。
注意事項あり。

# 注意事項

## メイン画面を使う場合、プロデルデザイナーがプロパティを読み取ってくれない場合があるので、設計画面を開いて、プロパティを確認すること。

以上。
How to git rebase

# Gitのコミット履歴を整理する（rebase と squash）

今回は、Gitのコミット履歴を綺麗に整理するためのテクニックである **rebase** と **squash** について解説していきたいと思います。

開発に集中していると、つい「不要なコメントを削除」や「typo修正」といった細かいコミットを積み重ねてしまい、後から履歴を見返したときに分かりにくくなってしまうことはないでしょうか。

```
feat: 機能Aを追加
fix: 軽微なバグ修正
refactor: コードのリファクタリング
fix: 再度の修正
docs: ドキュメントの typo 修正
```

このようなコミット履歴は、変更の意図が分散してしまい、後々のレビューやデバッグの際に追跡が困難になる可能性があります。

この記事では、そういった細かすぎるコミットを整理し、分かりやすい履歴を作成する方法を2つご紹介します。

## なぜコミット履歴を整理する必要があるのか

コミット履歴を整理することには、いくつかの重要なメリットがあります。

- **レビューの効率化**: 変更内容が一つのコミットにまとまっていることで、レビュワーは変更の全体像を把握しやすくなります。
- **変更履歴の追跡性向上**: 将来、特定の機能がいつ、どのような変更で追加されたのかを調査する際に、関連する変更が一つにまとまっていると非常に追いやすくなります。
- **プロジェクト品質の向上**: 整理されたコミット履歴は、プロジェクトそのものの品質と管理レベルの高さを示すことにも繋がります。

## 方法1: 現在のブランチのコミットを整理する (git rebase -i)

「現在のブランチで、少し細かくコミットしすぎてしまったな」という場合に有効なのが `git rebase -i` (インタラクティブ・リベース) です。このコマンドを使うと、指定した範囲のコミットを対話形式で編集できます。

### チュートリアル：最新3つのコミットを1つにまとめる

ここでは例として、最新の3つのコミットを1つに統合する手順を解説します。

#### 1. インタラクティブリベースの開始

まず、`HEAD~3` を指定して、最新から3つのコミットを対象にリベースを開始します。

```shell
git rebase -i HEAD~3
```

#### 2. エディタでの編集

このコマンドを実行すると、Vimなどのデフォルトエディタが起動し、以下のようなコミット一覧が表示されます。

```
pick 1a2b3c4 fix: ちょっとした修正
pick 5d6e7f8 feat: 機能Aの追加
pick 9g8h7i6 docs: 説明を追記
```

※コミットの順番は古いものが上になります。

今回は `feat: 機能Aの追加` というコミットに他の2つをまとめたいとします。残したいコミットの `pick` はそのままに、まとめたいコミットの行頭を `s` (squash) または `f` (fixup) に変更します。

```
pick 5d6e7f8 feat: 機能Aの追加
s 1a2b3c4 fix: ちょっとした修正
s 9g8h7i6 docs: 説明を追記
```

- **squash**: 前のコミットに統合し、コミットメッセージも後で編集するために残します。
- **fixup**: squash と同様に統合しますが、こちらのコミットメッセージは破棄されます。

#### 3. コミットメッセージの編集

ファイルを保存してエディタを閉じると、次に統合後のコミットメッセージを編集する画面が開きます。ここで、まとめられたコミットの新しいメッセージを記述して保存します。

```
# This is a combination of 3 commits.
# This is the 1st commit message:

feat: 機能Aの追加

# This is the 2nd commit message:

fix: ちょっとした修正

# This is the 3rd commit message:

docs: 説明を追記
```

不要な行を削除・修正し、分かりやすいメッセージに編集して保存すれば完了です。これで3つのコミットが1つに統合されました。

## 方法2：マージ時にコミットをまとめる (git merge --squash)

「開発ブランチ（featureブランチ）のコミットを、mainブランチにマージする前にきれいにしたい」というシナリオで役立つのが `git merge --squash` です。

このコマンドは、対象ブランチのすべてのコミットを、マージ先のブランチで一つのコミットとしてまとめることができます。

### チュートリアル：feature-branch のコミットを main に1つでマージする

#### 1. mainブランチへの移動

まず、取り込み先である `main` ブランチにチェックアウトします。

```shell
git checkout main
```

#### 2. --squash オプション付きでマージ

次に、`--squash` オプションを付けて `feature-branch` をマージします。

```shell
git merge --squash feature-branch
```

このコマンドを実行すると、`feature-branch` で行われたすべての変更が、コミットされずにステージングエリアに追加された状態になります。

#### 3. コミットの実行

最後に、`git commit` コマンドで分かりやすいメッセージを付けてコミットします。

```shell
git commit -m "feat: ユーザー認証機能の追加"
```

これにより、`feature-branch` での細かな作業履歴はブランチ内に残しつつ、`main` ブランチには「ユーザー認証機能の追加」という一つのまとまったコミットだけが記録されます。

## rebase を使用する際の注意点

`git rebase` はコミット履歴を書き換える非常に強力なコマンドです。そのため、**複数人で共有しているリモートブランチ（例: origin/main）に対して rebase を実行してはいけません**。履歴の不整合を引き起こし、他の開発者との間で深刻なコンフリクトが発生する原因となります。

基本的には、まだプッシュしていない、自分のローカル環境上のコミットに対して使用するようにしましょう。

## まとめ

今回はGitのコミット履歴を整理する `git rebase -i` と `git merge --squash` について解説しました。

綺麗なコミット履歴を保つことは、自分自身を含むチーム全体の開発効率を向上させるための重要な習慣だと思います。

ぜひ、日々の開発に取り入れてみてください。

以上です。

## 参考資料

- [Git公式ドキュメント - git-rebase](https://git-scm.com/docs/git-rebase)
- [Git公式ドキュメント - git-merge](https://git-scm.com/docs/git-merge)
【Python】datetimeモジュール

datetimeモジュールには以下の4つのオブジェクトがあります。

date（日付）
time（時刻）
datetime（日時）
timedelta（日付と時刻の計算）

この中でまぎわらしいのは、モジュールと同じ名前のオブジェクト「datetime」です。

Pythonでモジュールをインポートする場合は、以下のいずれかの記述をします。

-------------------------------
【1】from モジュール名 import オブジェクト名
【2】import モジュール名
-------------------------------

【1】の場合は、コードの中でモジュール名を記述せずに「オブジェクト名.関数名()」で使えます。

【2】の場合は、コードの中で「モジュール名.オブジェクト名.関数名()」と記述する必要があります。


datetimeモジュールの場合、【1】で「モジュール名.オブジェクト名.関数名()」と記述するとAttributeエラーになります。

また、【2】で「オブジェクト名.関数名()」と記述するとAttributeエラーになります。

現在日時を取得する場合、正しい記述は以下のいずれかとなります。

【1】
from datetime import datetime
datetime.now()

【2】
import datetime
datetime.datetime.now()
【ResponseEntity<Map<String, String>> とは？】

`ResponseEntity<Map<String, String>>`
これは「HTTPレスポンスを返すためのオブジェクト」です。そして中に含まれているのは Map（連想配列）形式のデータ です!

 `ResponseEntity<>`
Spring Frameworkのクラスで、HTTPステータスコード、ヘッダー、ボディを含むレスポンスを構成できる

たとえば、ResponseEntity.ok() で「HTTP 200 OK」というステータスを意味します！

```
Map<K, V>
```

`Map<String, String>`
これはJavaの「キーと値のペア」を表すデータ構造で、String型のキーと値を持つMap。

JavaのMapは、キー（Key）と値（Value）をセットで管理するデータ構造です。そのため、次のように型（データの種類）を2つ指定します：

最初のString → キーの型（たとえば "message"）

2つ目のString → 値の型（たとえば "スレッドを消しました"）

つまり `Map<String, String>` は：「キーも値もどちらも文字列（String）です」

という意味になります。

他の例を出すと…

```
Map<Integer, String>
```
だと、「キーが整数（例: 101）、値が文字列（例: "スレッドタイトル"）」という感じになります。

まとめると： 2つの String は、それぞれ「キーの型」と「値の型」なんです。セットで覚えておくと、他のジェネリクス型でも応用できるようになｒ
【Python】unicodedataモジュールのnormalize()関数

unicodedataモジュールのnormalize()関数は、次のコードのように文字列の正規化で使えます。

```python
>>> import unicodedata
>>> unicodedata.normalize('NFKC', 'ｱアAＡ')
'アアAA' # 結果
```

「NFKC」で正規化の条件を指定しており、ここでは「半角カナを全角カナに変換し、全角英数字を半角英数字に変換」しています。
【読書感想】プロになるためのWeb技術入門

# 書籍タイトル：プロになるためのWeb技術入門
読む時間：14:33

## はじめに

Webエンジニアとして5年間開発に携わってきた中で、「わからないことがあればググればなんとかなる」と思っていたし、「Udemyがあればテキストなんていらない」と感じていた時期もありました。

でも実際には、「調べて終わり（そして忘れる）」ということが多く、系統立てて理解できていなかったり、細かい部分まで理解が追いついていなかったりすることに気づきました。

4月から新しい案件で、バックエンドを一人で担当することになり、「こんな私で本当に大丈夫かな…」とかなり不安になっていましたそんなときに出会ったのが、この一冊でした。

## 📚 **本書の詳細情報**
https://gihyo.jp/book/2024/978-4-297-14571-2

## 印象に残ったポイント
### 1. 技術のつながりを把握し、「点」→「線」→「面」→「立体」
本書の第1章には「技術の学び方」という、一見すると地味で飛ばしてしまいそうなタイトルがついています。
でもじっくり読んでみたら、「まさにこれが自分の盲点だった！」と気づかされました。

私がエンジニアとしてキャリアをスタートした頃は、ちょうどHTTP/2の終盤からHTTP/3への移行期。
もはやHTML・CSS・JavaScriptだけでWebサイトを作る人は少なく、Reactなどのフレームワークから学び始める新人がたくさんいました。私自身もその一人です。

もちろん、それ自体が悪いわけではありません。
ただ、便利なフレームワークに頼るあまり、いざバグが発生したときに「リクエストの仕組みが抽象化されすぎて理解できない」「表面的な知識しかなくて本質がわからない」といった問題に何度もぶつかってきました。

そこで、本書の作者がおすすめしたのは、「点」→「線」→「面」→「立体」という勉強でした。

> 歴史を知って「点」の理解を「線」にする
> 技術のつながりを把握し「線」の理解を「面」にする
> 技術の「面」を階層としてとらえ「立体」的に理解する


技術が裏で何をしているのかを理解するには、必ずその当時の時代背景や、解決しようとしていた課題を知る必要があります。
たとえ今では時代が変わっていたとしても、「何がどう変わったのか？」「その結果、新たな課題は生まれていないか？」「もっと便利にできる余地はないか？」など、さまざまな視点や発想が生まれるはずです。

技術の発展の歴史をたどりながら、各ベース技術をしっかりと理解し土台を築いていかないと、たとえReactのコードが書けたとしても、それは単に「プログラムが書ける」だけの状態に過ぎません。

裏側の仕組みを理解し、根本的な問題を見抜いて解決できる力がなければ、本当の意味でエンジニアとは言えない──
本書を読んで、私は改めてそう感じました。

### 2. 定期的に技術サイトをチェックしよう
本書の著者は、私の“相棒”ともいえる w3schools や MDN を紹介していました。
以前はこれらのサイトでよく勉強していて、ほとんどのコンテンツを読んだことがあります。
ただ、Web技術の進化はとても速いので、定期的にチェックすることが大切だと改めて感じました。

本書では、Webまわりの技術キーワードを中心に、技術の発展の背景から具体的な使い方まで、とても丁寧に解説されています。
正直、w3schoolsやMDNを見るよりも「わかりやすい！」と思う場面も多くありました。

もちろん、w3schoolsやMDNのようなサイトはトピックごとに情報が整理されているので便利ですが、逆に言えば全体のつながりや背景を理解するのは少し難しいところもあります。
そういう意味でも、テキストとして体系的に学べる本書はとても貴重です。
そして、可能であれば英語で直接読むことで翻訳による情報のロスを避けながら、各トピックの最新情報にも触れられるのは大きなメリットだと思います。

https://www.w3schools.com/

https://developer.mozilla.org/en-US/

### 3. 細かいキーワードを補う
このロードマップにも書いたように、エンジニアの世界には本当に幅広い分野があり、それぞれに深い知識が求められます。
実際の業務で使っていないと、なかなか理解しづらい知識も多くありますよね。

本書では、私が業務の中であまり深く触れる機会がなかった「SPA」と「SSR」の違いについても丁寧に解説されていて、読みながら心の中がすっと整理され、「やっと点と点が線でつながった！」という感覚を味わえました。

そのほかにも、Web関連のさまざまなキーワードについての章があり、正直ここでは感想をすべて書ききれないほどです。
興味を持たれた方は、ぜひご自身で手に取って読んでみてください！

https://roadmap.sh/


## まとめ・感想
本書のタイトルには「入門」と書かれていますが、まったくの初心者には正直あまりおすすめできません。
確かに丁寧に、WWWの由来やHTTP/1の始まりから説明されていますが、いきなり系統的・俯瞰的に学ぼうとすると、登場するキーワードが多すぎて（「点」が多い）、難しく感じてしまうかもしれません。
内容が抽象的に思えて、集中力が続かなくなる可能性もあります。（「線」につながらず諦めてしまう。。。）

私自身の経験から言うと、まずは何かしらのフレームワークを使って手を動かしてみて、簡単でも「動くもの」を作ってみることが大切だと思います。心の中に、何らかの「点」や「線」ができていて、どう「面」につながるかわからなくなったタイミングで、また本書を読んだほうがいいと思います。

ある程度コーディングの経験を積み、フロントエンドとバックエンドそれぞれの仕組みが少しずつ見えてきら、この本を読んで体系的に学ぶ――その流れが一番しっくりくると思いました。
pytestでケースをまとめたいときの2つのtips

pytestでテスト関数をまとめたいときの2つのtipsを紹介します。

テスト対象の関数は、割り算をする関数（`operator.truediv`）とします。

## 正常処理と異常処理をまとめる

次がテストコードです。

```python:test1_before.py
import operator

import pytest


def test_ok():
    """正常終了するテスト"""
    numerator, denominator = 1, 2
    actual = operator.truediv(numerator, denominator)
    assert actual == 0.5


def test_error():
    """異常終了するテスト"""
    numerator, denominator = 1, 0
    with pytest.raises(ZeroDivisionError):
        operator.truediv(numerator, denominator)
```

正常処理のテスト関数と、例外を確認する異常処理のテスト関数があります。
この2つの関数を1つの関数にしましょう。

一般に、1つの関数で複数のケースを実行するのはわかりにくくなるので避けるべきですが、`parametrize`を使えばわかりやすくまとめることができます。

次が修正したテストコードです。

```python:test1_after.py
import operator
from contextlib import nullcontext

import pytest


@pytest.mark.parametrize(
    ("numerator", "denominator", "context"),
    [
        (1, 2, nullcontext(0.5)),
        (1, 0, pytest.raises(ZeroDivisionError)),
    ],
)
def test(numerator, denominator, context):
    """正常終了と異常終了のテスト"""
    with context as expected:
        actual = operator.truediv(numerator, denominator)
        assert actual == expected
```

`nullcontext`によりwithで統一して使えるようになります。
正常処理の場合は、そのままassertで確認がされます。
異常処理の場合は、例外が発生することが`pytest.raises`で確認され、assertは実行されません。

この方法は、pytestの公式ドキュメントに載っている方法です。

https://docs.pytest.org/en/stable/example/parametrize.html#parametrizing-conditional-raising

## 複数のフィクスチャをまとめる

次がテストコードです。
テスト対象の関数の引数がJSONのファイルに定義されているという想定です。
2つのフィクスチャがそれぞれPathオブジェクトを返します。

```python:test2_before.py
import json
import operator
import tempfile
from pathlib import Path

import pytest


@pytest.fixture
def file1():
    with tempfile.NamedTemporaryFile(mode="w+") as tf:
        tf.write('{"numerator": 1, "denominator": 2, "expected": 0.5}')
        tf.flush()
        yield Path(tf.name)


@pytest.fixture
def file2():
    with tempfile.NamedTemporaryFile(mode="w+") as tf:
        tf.write('{"numerator": 3, "denominator": 4, "expected": 0.75}')
        tf.flush()
        yield Path(tf.name)


def test1(file1):
    c = json.loads(file1.read_text())
    actual = operator.truediv(c["numerator"], c["denominator"])
    assert actual == c["expected"]


def test2(file2):
    c = json.loads(file2.read_text())
    actual = operator.truediv(c["numerator"], c["denominator"])
    assert actual == c["expected"]

```

フィクスチャが違うだけなのでテスト関数をまとめたいですが、`parametrize`ではフィクスチャを扱えません。
このようなときは、`request.param`が便利です。

次が修正したテストコードです。

```python:test2_after.py
import json
import operator
import tempfile
from pathlib import Path

import pytest


@pytest.fixture(
    params=[
        '{"numerator": 1, "denominator": 2, "expected": 0.5}',
        '{"numerator": 3, "denominator": 4, "expected": 0.75}',
    ]
)
def file(request):
    with tempfile.NamedTemporaryFile(mode="w+") as tf:
        tf.write(request.param)
        tf.flush()
        yield Path(tf.name)


def test(file):
    c = json.loads(file.read_text())
    actual = operator.truediv(c["numerator"], c["denominator"])
    assert actual == c["expected"]
```

`params`の要素が2つなので、`file`フィクスチャを使ったテスト関数は2回実行されます。

以上
手書き風アニメーションでプレゼンする【Excalidraw animate + HTML】



# Excalidraw


https://excalidraw.com/

animateさせることもできる。

https://dai-shi.github.io/excalidraw-animate/

draw.io以外でAWSアーキテクチャ図を書く方法がないか調べているうちに知った。

しかし、　GIFでの出力ができなくて、Google Slideに添付できない。

そのほかの方法を調べると、
Reveal.jsなど色々なOSSがあった。
しかし、この程度なら自力でHTMLで作れるということで、vibe coding で作成。

せっかくなのでインフォーマルめ、軽めのプレゼンなどに活用する予定。

# これ。

```

<!doctype html>
<meta charset="utf-8">
<title>Excalidraw Animate – 20 Slides with Replay & Counter</title>
<style>
  html,body{margin:0;height:100%;background:#fff;font-family:sans-serif}
  .slide{position:fixed;inset:0;display:none;justify-content:center;align-items:center}
  .slide.active{display:flex}
  object{max-width:90vw;max-height:90vh}

  /* ─ Replay ボタン（左下） ─ */
  .replay-btn{
    position:absolute;bottom:14px;left:14px;
    border:0;background:none;cursor:pointer;user-select:none;
    font-size:22px;line-height:1;color:#555;
    opacity:0.15;transition:opacity .2s,transform .2s;
  }
  .slide:hover .replay-btn,.replay-btn:hover{
    opacity:0.85;transform:scale(1.15);
  }

  /* ─ カウンタ（右下） ─ */
  #counter{
    position:fixed;bottom:16px;right:16px;
    font-size:14px;color:#666;
    opacity:0.4;transition:opacity .2s;
    user-select:none;
  }
  #counter:hover{opacity:0.8}
</style>

<div id="deck"></div>
<div id="counter"></div>

<script>
(() => {
  /* ===== 設定 ===== */
  const NUM_SLIDES = 20;
  const FILE_PREFIX = 'frame';   // frame01.svg など
  const PAD_LENGTH  = 2;         // 01, 02 …

  /* ===== スライド生成 ===== */
  const deck = document.getElementById('deck');
  for (let i = 1; i <= NUM_SLIDES; i++) {
    const slide = document.createElement('div');
    slide.className = 'slide' + (i === 1 ? ' active' : '');

    const obj = document.createElement('object');
    obj.type = 'image/svg+xml';
    obj.data = `${FILE_PREFIX}${String(i).padStart(PAD_LENGTH,'0')}.svg`;
    slide.appendChild(obj);

    const btn = document.createElement('button');
    btn.className = 'replay-btn';
    btn.textContent = '↺';
    btn.onclick = () => { obj.data = obj.data; };
    slide.appendChild(btn);

    deck.appendChild(slide);
  }

  /* ===== ページ送り & カウンタ更新 ===== */
  const slides  = [...document.querySelectorAll('.slide')];
  const counter = document.getElementById('counter');
  let idx = 0;
  const updateCounter = () => { counter.textContent = `${idx+1} / ${slides.length}`; };
  updateCounter();

  const show = n => {
    slides[idx].classList.remove('active');
    idx = (n + slides.length) % slides.length;
    slides[idx].classList.add('active');
    updateCounter();
  };

  document.addEventListener('keydown', e => {
    if (['ArrowRight','L',';'].includes(e.key)) show(idx + 1);
    if (['ArrowLeft' ,'H',','].includes(e.key)) show(idx - 1);
  });
})();
</script>

```

# 使い方

・Excalidraw animateで手書き風のアニメートされたSVGファイルを作る(frame01.svg 〜 frame20.svgの名前にする)。
・index.htmlに上記コードをペースト。
・同じフォルダに frame01.svg 〜 frame20.svg を置く
この index.html をブラウザで開きフルスクリーン
← / → でページ移動、左下の ↺ でそのページだけリプレイ
右下に薄く 「現在枚数 / 総枚数」 が常に表示される
半導体設計と数値計算



## ✅ A-1：**半導体における基本方程式（P型・N型シリコン）**

### ● ポアソン方程式

$$
\nabla^2 \psi = \frac{q}{\varepsilon_s} (N_D - N_A + p - n) \tag{A-1}
$$

### ● 電流密度方程式

$$
j_n = q\mu_n n \cdot \nabla \psi - q D_n \cdot \nabla n
$$

$$
j_p = q\mu_p p \cdot \nabla \psi + q D_p \cdot \nabla p \tag{A-2}
$$

### ● 電流連続方程式

$$
\frac{\partial n}{\partial t} = \frac{1}{q} \nabla \cdot j_n + G_n - R_n
$$

$$
\frac{\partial p}{\partial t} = -\frac{1}{q} \nabla \cdot j_p + G_p - R_p \tag{A-3}
$$

### ● 熱平衡下のキャリア密度

$$
n = n_i e^{\frac{q(\psi - \psi_r)}{kT}}, \quad
p = p_i e^{\frac{q(\psi_r - \psi)}{kT}}
$$

---

## ✅ A-2：**光に関する測光・放射量の定義と関係**

### ● 測光量の導出式（放射照度 → 照度）

$$
E = K_m \int_{\lambda_1}^{\lambda_2} E_e(\lambda) \cdot V(\lambda) \, d\lambda \tag{A-4}
$$

* $E$：照度（lx = lm/m²）
* $E_e(\lambda)$：分光放射照度
* $V(\lambda)$：標準比視感度
* $K_m$：683 lm/W（λ = 555nm）

---

## ✅ A-3：**照度と輝度の関係**

（式番号なし・補足的）

$$
E_e = \int_{\lambda_0}^{\lambda_1} E_{e\lambda}(\lambda) \, d\lambda
$$

---

## ✅ A-6：**ノイズに関する式（kTCノイズ・光ショットノイズ）**

### ● kTCノイズ（電圧ノイズ）

$$
v_n = \sqrt{\frac{kT}{C}} \tag{A-20}
$$

### ● 光ショットノイズの確率分布（ポアソン分布）

$$
P(x) = \frac{e^{-M} \cdot M^x}{x!} \tag{A-21}
$$

* $M$：平均飛来フォトン数
* $P(x)$：x個のフォトンが到達する確率

---

## ✅ 用語略記一覧（抜粋）

| 記号              | 意味           |
| --------------- | ------------ |
| $\psi$          | 静電ポテンシャル     |
| $q$             | 電子の電荷量       |
| $\varepsilon_s$ | シリコンの誘電率     |
| $N_D, N_A$      | ドナー・アクセプタ濃度  |
| $n, p$          | 電子・正孔密度      |
| $\mu_n, \mu_p$  | 電子・正孔の移動度    |
| $D_n, D_p$      | 拡散係数         |
| $G, R$          | キャリアの生成・再結合項 |

---
PATHを通すとは？環境変数とは？

# 概要
"ファイル名だけで実行できる！"までは様々な記事にあるが、仮想メモリにまで突っ込んだ内容は少なかったため、カジュアルにまとめてみました。

# 表面上
パスと拡張子を省略しても実行ファイルを指定・実行できる

# 実際の実装
私も最初は「“環境変数を設定”に値を追加すれば、Windowsが勝手にいろいろな箇所に適用してくれる」程度の認識でした。
しかし実際には、プロセスが作られる際、その仮想メモリ空間にOSから環境変数の内容（例：PATH）が複製・格納されているという仕組みになっています。
つまり、全てのプロセス（＝アプリやコマンドなど）は、実行時に共通の環境変数セットを受け取るということです。
これは、エクスプローラーや PowerShell、レジストリエディタなどのWindows標準ツールに限らず、サードパーティ製のソフトやコマンドラインツールなどにも共通です。
それらは必要に応じて、仮想メモリ上に格納された環境変数の内容を参照することで、PATH に基づいて実行ファイルを見つけ出したり、動作を切り替えたりします。

# 環境変数ってなんぞや
環境変数とは、OSやアプリケーションが参照する名前付きの設定情報の集合です。
たとえば PATH（実行ファイル検索パス）のほかにも、ユーザー名（USERNAME）、端末名（COMPUTERNAME）、一時保存先（TEMP）、OS名（OS）などがあります。
もっと具体的に書くと、プロセス実行時、仮想メモリ構築の際に記載するデフォルトの基本情報のようなものです。

# 環境変数の本質とプロセスとの関係
Windowsでは、新しいプロセスが作られる際に、OSがそのプロセスの仮想メモリ空間内に環境変数のコピーを配置します。
つまり、各プロセスは独立した環境変数のセットを持っており、実行中はそのコピーを参照・利用する仕組みです。

このコピーは、たとえシンプルなバッチファイルのような小さなプロセスでも例外ではなく、必ず仮想メモリ内に環境変数の情報が格納されます。

そのため、エクスプローラーやPowerShell、レジストリエディタのようなWindows標準ツールはもちろん、サードパーティ製のソフトでも同じく、必要に応じて自分の仮想メモリ内の環境変数を参照できます。
例えば PATH に基づいて実行ファイルを検索したり、動作を切り替えたりしています。

# 環境変数の更新と影響範囲
仮想メモリはプロセスごとに分離されているため、あるプロセス内で環境変数を変更しても、他のプロセスやシステム全体には影響しません。
この性質により、アプリケーションは環境変数を自由に参照・一時的に変更できます。

一方で、「大本」の環境変数、つまり新しいプロセスの雛形となる設定値――はWindowsのレジストリに永続的に記録されています。
代表的な場所としては以下のキーが挙げられます：

HKEY_CURRENT_USER\Environment（ユーザー単位）
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment（システム全体）

これらの値は電源を切っても保持され、プロセス起動時にここから複製されます。

通常のプロセスはこのレジストリ値を直接変更できません。
そのため、もしこのレジストリ値が意図せず変更されていた場合、何らかの高権限コマンドや不正なプログラムが実行された可能性があるためセキュリティ上の警戒が必要です。

# 具体的にどう環境変数は利用されるのか
例として、コマンドプロンプト（cmd）で「calc」と入力して電卓を起動する場合を考えます。
まず、cmd.exe が起動されると、OSはこのプロセス専用の仮想メモリ空間を構築します。
その際、レジストリに保存されている環境変数（例：PATH や TEMP などの変数）がこの仮想メモリ空間に複製され、格納されます。
ここまでの仮想メモリの動作はいわばテンプレートのような挙動でありcmd.exe に限らず、word.exe や explorer.exe など、どんなプロセスでも共通です。

その後、ユーザーが calc と入力すると、cmd は次のような順で処理を進めます：

・まず calc が内部コマンド（組み込みコマンド）かどうかを確認（例：cd や echo など）。
・該当しない場合、.exe, .bat, .cmd などの拡張子を補完しながら、仮想メモリ内に格納されている環境変数：PATH に指定された各ディレクトリを参照し、順番に検索。
・PATHの一つ、C:\Windows\System32\ 内にcalc.exeが見つかれば、それを実行。

このように、環境変数はプロセス起動時にセットされ、cmd のようなシェルはその内容を動的に参照してコマンド解釈や実行を行っています。

# 要点まとめ
・環境変数はプロセスごとにコピーされる設定情報で、実行時に仮想メモリに配置される。
・すべてのプロセスは、この環境変数セットを自分専用に持ち、自由に参照・変更できる。
・環境変数の「大本」はレジストリにあり、通常のプロセスからはこの大本は変更できない。
まだ画像探しで消耗してる？革命的なAIジェネレーター「FeetGen」で、あなたの創造力を輝かせよう！

皆さん、こんにちは。長年の友人である私からです。専業のコンテンツクリエイターとして、皆さんの心に響く質問をさせてください。たった一枚の適切な画像のために、数え切れないほどの素材サイトを何時間も探し回った経験はありませんか？著作権問題を懸念して、あの「完璧な」一枚を諦めたことはありませんか？あるいは、高額な撮影依頼料やライセンス購入費用のために、自身のクリエイティブなアイデアを断念したことはありませんか？https://feet-gen.com

もしあなたの答えが「はい」なら、おめでとうございます。今日のこの記事は、あなたの創作活動における重要な転換点となるでしょう。なぜなら、私のワークフローを根底から変えた「秘密兵器」——FeetGen.com をご紹介するからです。

FeetGenとは何か？それは、ありふれた画像素材サイトではありません。

端的に言えば、FeetGen は最新の Flux Kontext モデルを基盤とした、最先端のAI画像生成ツールです。それはただ一つのことに特化し、それを極限まで突き詰めています。それは、高品質で多様なスタイルの、完全にオリジナルな足の画像をワンクリックで迅速に生成することです。

なぜ足なのか、と疑問に思うかもしれません。なぜなら、ファッションブロガー、アーティスト、小説家、ゲーム開発者、ウェブデザイナーといった私たちクリエイターにとって、足のクローズアップやリファレンスは、非常に具体的でありながら、高品質で著作権フリーの素材を見つけるのが極めて困難な領域だからです。FeetGenは、その悩みを完璧に解決してくれます。

FeetGenは私たちの創作プロセスをどう覆すのか？

100%オリジナルで、著作権リスクに永遠にさよなら
これこそがFeetGenの最も中心的な価値です。生成される画像は一枚一枚がユニークで、AIによって即座に創造されます。これは、あなたがその画像の完全な使用権を持つことを意味し、もはや弁護士からの警告書やプラットフォームからの警告に怯える必要がなくなるということです。コンテンツで生計を立てている私たちにとって、これは何よりも重要です。

無限のカスタマイズ性で、創造性を完全にコントロール
従来の素材サイトでは受動的に受け入れるしかありませんでしたが、FeetGenはあなたを監督にします。どんな角度、どんなポーズ、どんな光と影、さらにはアニメ風かリアルなスタイルか……簡単な操作でAIに伝えるだけで、あなたのためにオーダーメイドしてくれます。この「思った通り」の体験は、他のどの素材サイトも提供できません。

究極の効率性、数時間から数秒へ
想像してみてください。かつては何時間もかけて検索し、選び、画像を加工していた作業が、今では https://feet-gen.com を開き、アイデアを入力し、生成ボタンをクリックするだけ。コーヒーを飲み終える前に、あなたの全ての要件を満たす何十枚もの高解像度画像が準備完了です。この節約できた時間で、私たちはより本質的な創作活動そのものに集中できます。

驚くほどの使いやすさとコストパフォーマンス
AIの専門家である必要はありません。FeetGenのインターフェースは非常に直感的で、真のワンクリック操作を実現しています。さらに重要なのは、高品質なオリジナル素材を入手するコストを劇的に削減してくれることです。一枚あたり数千円もするライセンス料や高額なモデル撮影費用と比較すれば、FeetGenが最もコストパフォーマンスに優れた選択肢であることは間違いありません。

FeetGenを最も必要としているのは誰か？

セルフメディアクリエイターとブロガー：記事や動画、SNSの投稿に、ユニークで目を引くビジュアル素材を添えましょう。
ウェブマスターと開発者：ウェブサイトやアプリ、製品紹介に高品質なプレースホルダーや恒久的なビジュアル要素を提供し、プロジェクトの美観と専門性を向上させます。
アーティストとデザイナー：絵画や3Dモデリングのための正確なリファレンスを迅速に入手。モデルを探したり、自分でポーズをとったりする手間が省けます。
小説家と脚本家：文字による想像を視覚化し、キャラクターやシーンの細部描写に、より具体的なインスピレーションを得られます。
結び

コンテンツが王様であるこの時代において、効率性と独創性は私たちの最も重要な競争力です。FeetGenは単なるツールではありません。それは、忠実で、疲れを知らない24時間オンラインの「AIアートアシスタント」のような存在です。それは私たちを煩雑で非効率な素材探しの作業から解放し、全てのエネルギーを私たちが最も得意とする創造の領域に注ぎ込ませてくれます。

創造の未来はすでにここにあります。それは自由、効率、そして無限の可能性に関わるものです。今すぐ https://feet-gen.com にアクセスし、現在進行中のこの創作革命を自ら体験してみてください！
【HTML】マイクロデータとは

　**マイクロデータ**とは、HTMLドキュメントに機械が識別可能なデータを埋め込むための技術です。
　検索エンジンなどの機械がHTMLドキュメント内のコンテンツの意味を把握できるようになるため、検索エンジン対策などに役立ちます。

**表：マイクロデータの主な属性**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387980/a3fb280c-5179-4720-9f38-1714b31b799d.png)
Amazon Q CLI でゲームを作ろう Tシャツキャンペーンに応募してみる

## Amazon Q CLI でゲームを作ろう Tシャツキャンペーンに応募してみる

以下の公式記事を参考にAmazon Qをインストールします(私はWindows環境で行いました)
[Amazon Q CLI でゲームを作ろう Tシャツキャンペーン ](https://aws.amazon.com/jp/blogs/news/build-games-with-amazon-q-cli-and-score-a-t-shirt/)

今回はpygameを利用してQさんに作ってもらいます
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4116626/47a16a06-066c-437c-8c2b-c9c24ceef80a.png)


インストールしたら、Qとのチャットを始めましょう
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4116626/9f38d190-18b6-420c-8547-221e2a824d0d.png)

上記のような表示がされれば成功です。

プロンプトを打ち込みます
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4116626/eb33d224-dc0a-48cb-9ac1-f044c1270a32.png)

早速作ってくれました。
ルールは以下です :
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4116626/0559bb50-f152-417a-aae2-d7f8ff0fdf2c.png)


実行してみると。。。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4116626/5970d56b-4dc8-4b0f-ac03-45452a1728eb.png)
**？？？？**

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4116626/8d43c0f6-b458-4be9-bd48-6036bb50d2d7.png)
**???????????**

指遊びですらないしマッチなのか割りばしなのかもわからないゲームができました(動作自体はできますね)



さすがにアレなのでちょっとブラッシュアップしてもらいます
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4116626/e6aeba7b-3ddf-4cdd-be14-8390a3b08d63.png)

(wavまで作ってくれてる。。。)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4116626/350b84d9-ed4a-4365-af41-0b8061d2b00d.png)

出来上がったQによる渾身の力作がこちら :
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4116626/e51497c1-2fd9-4c3d-88ce-65ed78b7ed29.png)
**ッチゲーム～割りばしの戦ㇾ‵**
|

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4116626/22e7a73d-06cc-4d0b-b872-1f7f02ea4e30.png)

たいありでした。

#### 感想
環境構築がすこし面倒なくらいで、ゲーム作成まではチャットをするだけなので簡単でした。
性能を確かめたかったので、あえてアバウトなプロンプトを使いましたが、さすがにしっかり見栄えのいいものができるわけではなかったです。
wavファイルを作って効果音等を用意することまで行えるのにはすこし驚きました(どうやってるんだろう...)
おそらく、フィードバックを行わせたりミクロに行ったりすればもっと良いものができるでしょうが、指遊びですらなくってしまったのには少し限界を感じました。
(Claud3.7 Sonnetって結構つよつよなイメージ)
ただ、少しの入力と時間だけでコンセプトを持って動くものが出来上がるという経験は面白いと感じました。
Docker、新と議論に満ちたその盛衰

# Docker、金色の卵を産むガチョウの腹を裂く？革新と議論に満ちたその盛衰
コンテナ技術の代名詞、Docker。かつて開発者たちの熱狂的な支持を受け、ソフトウェア開発とデプロイの方法を革新しましたが、その過程で多くの課題と議論に直面しました。果たしてDockerはどのように登場し、どんな危機を乗り越え、現在どのような位置にあるのでしょうか？これまでの対話に基づき、Dockerの盛衰をブログ記事形式でまとめてみました。
## 1. 問題解決者としての華々しい登場：Dockerの台頭
2013年、ソロモン・ハイクスは「サーバーへのコードデプロイは難しい」という長年の問題を解決するため、Dockerを世に送り出しました。当時、開発環境と運用環境の不一致や、複雑な依存関係は開発者の頭痛の種でした。
DockerはLinuxカーネルの隔離機能を活用し、アプリケーションとその依存関係を**「コンテナ」**という軽量で移植性の高い単位にパッケージングする概念を普及させました。「私のPCでは動いたのに…」という言い訳をなくし、開発・運用（DevOps）文化を促進する中核ツールとして定着しました。Docker Hubを通じたイメージ共有は、開発者コミュニティの爆発的な成長を牽引し、Dockerはあっという間に「最も望まれるツール」となったのです。
## 2. 金色の卵を産むガチョウ、危機に瀕する：挑戦と議論
順風満帆に見えたDockerは、すぐに多くの挑戦に直面します。
# 2.1. コンテナオーケストレーションの必要性とKubernetesの登場
単一のコンテナだけでなく、多数のコンテナを効率的に管理する必要性が高まるにつれて、コンテナオーケストレーションが重要になりました。Dockerは自社でDocker Swarmを提供しましたが、Googleが開発したKubernetesがその強力な機能と拡張性で急速に業界標準の地位を確立しました。これにより、Dockerはオーケストレーション市場で主導権を失うことになります。
# 2.2. Dockershim論争とOCI標準
Kubernetesは当初Dockerランタイムに依存していましたが、2020年にDockershimのサポート終了を発表し、Dockerランタイムへの直接的な依存を減らし、Open Container Initiative (OCI) 標準に準拠する様々なランタイム（例：containerd、CRI-O、Podman）をサポートすることを明らかにしました。これは、Dockerがコンテナランタイム市場で独占的な地位を失い、多様な代替案が台頭するきっかけとなりました。
# 2.3. 「金色の卵を産むガチョウの腹を裂く」？：Docker Desktopの有料化とログイン強制の議論
最大の議論は、2021年のDocker Desktopの有料化ポリシー変更でした。一定規模以上の企業ユーザーに対し、サブスクリプション料を課し、ログインを強制し始めたのです。
このポリシーは、開発者コミュニティから激しい批判にさらされました。
 * オープンソース精神の毀損論争： 何年もの間、無料でDockerエコシステムに貢献してきた開発者たちは、Docker Inc.がコミュニティの信頼を裏切り、「金色の卵を産むガチョウの腹を裂いた」ようなものだと批判しました。
 * 一方的なコミュニケーション： ポリシー変更の発表時、多くのユーザーはDocker Inc.がこのような重要な変更についてコミュニティと十分にコミュニケーションを取ったり、意見を募ったりするプロセスを経なかったと感じました。
 * 既存ユーザー体験の低下： 何年も無料で便利に使ってきたツールに突然ログインやサブスクリプション料が課せられることで、既存ユーザーは不便さと裏切られた気持ちを経験することになりました。
もちろん、Docker Inc.の立場からすれば、資金回収、企業の存続、サービス品質向上など、持続可能なビジネスモデルのための避けられない選択だったと主張することはできます。しかし、この過程で企業倫理の側面から多くの批判を受けることになりました。
## 3. 未だに強力な存在感：Dockerの現在と未来
数々の浮き沈みを経験したものの、Dockerは依然としてコンテナ技術の「顔」であり、最も広く使用されているツールです。
 * 変わらぬ開発者フレンドリーさ： Docker Inc.は、コンテナオーケストレーションの競争ではなく、**開発者体験（Developer Experience）**の向上に注力しています。Docker Desktopのパフォーマンス改善や、様々な統合機能を提供することで、開発者がローカル環境でコンテナを簡単かつ便利に利用できるよう支援しています。
 * クラウドネイティブエコシステムの中核： Kubernetesとともに、クラウドネイティブアプリケーション開発の核となる技術として確固たる地位を築いています。主要なクラウドプロバイダーはすべて、Dockerコンテナをベースとしたサービスを提供しています。
 * 活用分野の拡大： マイクロサービス、CI/CD、エッジコンピューティング、機械学習など、様々な分野でDockerの活用は拡大し続けています。
結論：イノベーターからビジネスモデル再構築へ
Dockerは技術的にソフトウェアデプロイメントに革命をもたらしましたが、商業的に成功するためのビジネスモデルを模索する過程で、多くの成長痛を経験しました。特にDocker Desktopの有料化論争は、「オープンソース精神」と「企業の存続」という2つの重要な価値が衝突する際に何が起こるかを示す象徴的な事例となりました。
批判の中でも、Dockerは開発者から依然として愛されるツールであり続け、コンテナ技術エコシステムの重要な一翼を担っています。今後、Dockerがどのような形で進化し、開発者の傍にあり続けるのか、その動向が注目されます。
メールが来たときにTeamsのFlow botで自分だけに通知する方法

## はじめに

TeamsのWorkflowsがうまく使いこなせなくて四苦八苦したのでメモ

---

## やりたいこと

- Outlookにメールが来た際にTeamsに通知
- 通知は自分だけに来るようにしたい
    - テンプレートをそのまま使うとチャネルが対象になってしまう
- メールの内容は全文でなくてもよいので確認したい

---

## 解決方法

Flow Botを使うことでうまくできました。

:::note
AIに聞いたところ，トリガーやアクション名を英語で返して来たので自分はTeamsの言語設定を英語にして設定しました。
:::

1. Teamsを開きWorkflowsを選択する
2. 「+New flow」を選択
3. 「+ Create form blank」からテンプレートを使わずに作成する
4. トリガーに「When a new email arrives (V3)」を選択する
    
    :::note
    2025年6月現在，自分の環境だと(V2)だとうまく動かなかった。

5. Folderに通知したいメールのディレクトリを選択する
    
    :::note
    Outlook側でメールの振り分け設定をやっておき，重要なものだけ集めておくと良い
6. アクションに「Post message in a chat or channel」を選択する
7. 以下のように設定する 
    - 「Post as」に`Flow bot`
    - 「Post in」に`フローボットとチャットする。
    - 「Recipient」に自分のメールアドレス
    - 「Message」にメッセージをいれる。この時，`Subject`とか`From`とか`Body`とか入れるとメールの内容が取得できる
    
    ::: note
    自分は「Recipientに自分のメールアドレス以外に`From`とか選択できたので入れることで通知分がリッチになると勘違いしていたが，メールの内容は全部メッセージ側に記載すればよい。

メッセージ設定例
```
件名: `Subject`
From: `From`
---以下本文---
`Body`
```

これでoutlookの特定のディレクトリにWorkflowsからメールが来た場合にWorkflowsから通知がもらえるようになった。

## TODO

お家のTeams(ブラウザ)だとWorkflowsがうまく使えなかったので画像がない。
うまく家で再現できたら文章部分を画像に差し替える。
JUnitとは？初学者向けKotlinでのテストケース

# はじめに
こんにちは。最近Androidアプリ開発を始めたばかりの初学者です。今回は、アプリ開発でよく聞く**JUnit**について、実際に手を動かして学んだ内容をまとめてみました。
・JUnitとは？
・テストの書き方は？
・Android Studioの注意点は？
など、**初心者実体験ベースで説明**していきます。

# JUnitとは？
まず最初にそもそもJUnitとは
⇒JUnitは、JavaやKotlinなどで使える**単体テスト（ユニットテスト）用のフレームワーク**です。
「関数が正しい出力を返すか？」「意図しない挙動をしていないか？」などを、コードでチェックすることができます。

バグの早期発見や保守性の向上につながるそうです。

# 環境
環境はAndroid Studioで、Kotlinでコードは書いています。
当たり前かもしれませんが、一応VScodeとかのIDEでもできるらしいけどAndroid Studioがいろいろ用意してくれてるから楽。

今回は簡単な足し算関数を用いてテストを試しました。

Add.kt
```kotlin
package com.example.junit_test

fun add(a: Int, b: Int): Int {
    return a + b
}
```


Add_test.kt
```kotlin
package com.example.junit_test

import org.junit.Assert.assertEquals
import org.junit.Test

class MathUtilsTest {
    @Test
    fun testAdd() {
        assertEquals(5, add(2, 3))
    }
}
```


# 実行手順と注意(自分が詰まったとこ)
まず最初にディレクトリ構造に注意してください。


![ディレクトリ構造.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4116314/f0d58822-b9c8-4bf1-be6c-7192795e8a33.png)
図1. ディレクトリ構造

①com.example.(プロダクト名)/Add.kt
を用意してください。次に、
②com.example.(プロダクト名)(test)/Add_Test.kt
を用意してください。

(test)・・・ローカルテスト用、サクッと実行するとき。←今回はこっち
(androidTest)・・・実機やエミュレーターの時のテスト用。UIテストなど

# 実行結果

![実行結果_pass.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4116314/d67b503a-b764-445a-a264-db0e0e318676.png)
図2. 正常な実行結果

問題なくテストが通った時はこのようにtests passed：1と表示されます。
実行の際にはAdd_Test.ktのclass MathUtilsTestの横の実行ボタンを押してください。いつも通り関数横の実行ボタンでもOKです。

![expected6.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4116314/634a6cf7-3341-407c-a86d-bc27cbe3e545.png)
図3. 2 + 3 = 6の実行結果

次にエラーになる実行をしてみました。実行結果として、
Expected :6
Actual :5
と親切に教えてくれています。

また、複数テストしたい場合にはtestAdd1(), testAdd2など名前を変える必要があります。

```kotlin
@Test
fun testAdd1() { ... }

@Test
fun testAdd2() { ... }
```



# 学び・感想
・AndroidStudioが至れり尽くせりで、とても便利だと改めて感じました。
・よくあるコーディングテスト、AtCoderとかの裏側の正誤判定は裏でこんなプログラムが回っているのかなぁと感じました。
・慣れない記事を書くことも楽しかったです。今後もいろいろと学んでいきたいと思います。


※本記事のコードはすべて筆者の個人学習目的で作成したものであり、GitHub連携や既存プロジェクトとは無関係です。
「git checkout」は古いから使うな！

社内で`git checkout` でブランチを切り替えたり、変更を破棄したりしている方がいたので、`git checkout`を使用している方に向けて「`checkout`は使わんで！」という内容を書きます。

# `git checkout`は多機能で怖いから `switch`, `restore`使え！

突然ですが、ブランチの切り替えやちょっとした修正の取り消しに、git checkout コマンドを使っていませんか？ 手に馴染んだコマンドで、つい指が動いてしまう方も多いかと思います。自分ちょうど一年前までは`checkout`使ってました。

ですが、その便利なはずの `git checkout` には、 **意図しない事故を引き起こしかねない「怖さ」** が潜んでいるんです。

# `checkout` の何がそんなに「怖い」のか？
結論から言うと、`checkout` は役割が多すぎるのが問題です。
このコマンドは、大きく分けて以下の2つの全く異なる操作を実行します。

- **ブランチを切り替える**
- **ファイルの変更を元に戻す**


「ブランチ操作」と「ファイル操作」という、コンテキストが全く違う作業を同じコマンドが担当しているため、こんな悲劇が起こり得ます。

## [怖い話] ブランチ名とファイル名を間違えたら…？
あなたが feature/AB-123 というブランチに切り替えようとして、うっかりこう入力したとします。

```bash
# ブランチ名をタイポした
$ git checkout feature/AB-12
```

もし feature/AB-12 という名前のファイルやディレクトリが過去のコミットに存在した場合、Gitは「お、このファイルの状態に戻したいんだな」と解釈して、あなたの作業ツリーにある同名のファイルを警告なしに上書きしてしまう可能性があります。

# 安全な新コマンド `switch` と `restore`を使おう
このような事故を防ぐため、Git 2.23から checkout の機能は2つの専門家コマンドに分割されました。

## ブランチ操作の専門家 `git switch`

ブランチを「切り替える(switch)」ことだけに責任を持ちます。ファイル操作は一切行いません。

## ファイル復元の専門家 `git restore`

ファイルの変更を「元に戻す(restore)」ことだけに責任を持ちます。ブランチ操作は一切行いません。
役割が完全に分かれているため、もう間違うことはありません。


# まとめ
## 今日から checkout 依存を卒業しよう！
もちろん、git checkout がすぐに使えなくなるわけではありませんが、コードを守るために、より安全で明確な方法があるなら、それを使わない手はありません。

今日から**ブランチを移動するときは `git switch`** を、**ファイルの変更を取り消すときは `git restore` ** を意識して使ってみてください。

皆さんの日々の開発が、少しでも安全で快適になりますように。
PiKVM DIY V2 用の USB Type-C (ラズパイ電源) → USB Type-A (Power), USB Type-A (Data) を 220 円で作る

[先達が使って成功したというスプリッター](https://www.amazon.co.jp/dp/B0C4T8R9HR?ref=fed_asin_title)を買ってみたものの、残念ながら動作せず、また、[PiKVM の DIY の画像で使われてるっぽいスプリッター](https://ja.aliexpress.com/item/1005007166251401.html?src=google&pdp_npi=4%40dis!JPY!584!584!!!!!%40!12000039675061363!ppc!!!&src=google&albch=shopping&acnt=742-864-1166&isdl=y&slnk=&plac=&mtctp=&albbt=Google_7_shopping&aff_platform=google&aff_short_key=UneMJZVf&gclsrc=aw.ds&&albagn=888888&&ds_e_adid=748703396344&ds_e_matchtype=search&ds_e_device=c&ds_e_network=g&ds_e_product_group_id=295990060787&ds_e_product_id=ja1005007166251401&ds_e_product_merchant_id=5088408920&ds_e_product_country=JP&ds_e_product_language=ja&ds_e_product_channel=online&ds_e_product_store_id=&ds_url_v=2&albcp=22485969970&albag=182138631081&isSmbAutoCall=false&needSmbHouyi=false&gad_source=1&gad_campaignid=22485969970&gbraid=0AAAAA99aYpcw9k_yLsSrL0tT9Zg7Dha1D&gclid=CjwKCAjwpMTCBhA-EiwA_-MsmcG5L-lumqAZ9fEzSV-2MTF2ySG71J7Ng8wnepJaf1qETESdSK2SXxoCzQMQAvD_BwE) は、手元に届くまで 2 週間くらいかかるということだったので、自作をするに至った。

紆余曲折があり、時間を無駄に使った。動くかわからないものを買うよりも、簡単でお金もかからないので、自分で作った方がいいと思う。はんだ付けをしなくても動く。必要な工具は、ケーブルの被覆を剥すのに必要なはさみくらいで、100 均のはさみで十分。

1. ダイソーで、[片側が USB Type-C で、もう片側が USB Type-A の USB 2.0 充電・転送ケーブル](https://jp.daisonet.com/products/4549131497656?srsltid=AfmBOorlZdu8Zq5frei2I9R9tDkJYZ4LAiRm36mfWOHCwpPgaU8BrsUD) を 2 つ買ってくる。USB 2.0 でないと、中にある線の数が変わるので USB 2.0 であることは重要。
1. 1 つのケーブルの真ん中の部分の外皮を 10cm 程度剥す。
1. 黒い線を、剥した部分の中心で切り、切った両側の先端の皮膜を剥して、銅線を出す。
1. 赤い線を、剥した部分の中心で切り、USB Type-C 側の先端の皮膜を剥して、銅線を出す。
1. もう一つのケーブルを半分に切り、USB Type-A 側について、先程のケーブルと同様に、外皮を剥ぎ、赤と黒の線の先端を剥して銅線を出す。USB Type-C 側は捨てる。
1. 3 つの黒い線の先端を継げて、はんだ付けする。
1. 2 つの赤い線の先端を継げて、はんだ付けする。

図にすると、
```
電源
|   | - 白 - X
|   | - 青 - X
| A | 
|   | ------ 黒 -+
|   | ------ 赤  |
             |   |
データー      |   |
|   |        赤 -)---- |   |
|   | ------ 黒 -+---- |   |
| A | ------ 白 ------ | C | ラズパイ
|   | ------ 青 ------ |   |
|   | - 赤 - X         |   |
```

まとめると、
1. 電源、データー、ラズパイの黒の線を継げる。
1. 電源とラズパイの赤の線を継げる。
1. 他にはなにもしない

これで [PiKVM Handbook DIY PiKVM V2 quickstart guide](https://docs.pikvm.org/v2/) の、`2. USB cable and power supply` の、`... or Variant #3: Power supply + DIY Y-splitter for soldering` で説明されているものが出来る。
Raspberry Pi: OS の複製

OS の複製というのは、SDカードの複製になります。

## img ファイルへの変換

```bash
sudo dd if=/dev/sda of=raspi_backup.img bs=4M status=progress
sync
```

## img ファイルの縮小

pishrink.sh　を使います。

pishrink.sh のダウンロード

```bash
wget https://raw.githubusercontent.com/Drewsif/PiShrink/master/pishrink.sh
chmod +x pishrink.sh
```

pishrink.sh を実行

```bash
./pishrink.sh raspi_backup.img
```

実行前のサイズ

```text
15931539456
```

実行後のサイズ

```text
7891841536
```

## SD カードへの書き込み

rpi-imager　を使います。
host 名や、WiFi の設定を変更できます。

    Use custom を選びます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/179446/b81d37f0-fc0b-47e3-9a51-17f3ef526939.png)

設定を編集する

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/179446/df616709-02f8-43aa-bad0-124b0cd020e3.png)

ホスト名
    Wi-Fi 設定などが変更できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/179446/291703a0-07b1-4b87-af8d-55bde69ef9d5.png)
Visual Studio Codeとは

## Visual Studio Codeは高機能エディター
　**Visual Studio Code**（以降**VSCode**）は、Microsoft社が開発・提供する**ソースコードエディター**です。オープンソース（VSCodeのプログラムソースコードを公開すること）でかつ無償で、WindowsやmacOS、Linuxなどマルチプラットフォームで利用できます。VSCodeはとても人気があり、様々な開発などで利用されています。
　**Microsoft Word**が文字を書くためのサポート機能を多く備えるのと同じように、VSCodeにはプログラムを書くためのサポート機能が満載されています。
　VSCodeはコア部分をオープンソースソフトウェア(OSS)としてMITライセンスで公開しています。また拡張機能によって様々な機能追加が可能です。有料無料問わず多くの拡張機能が様々なベンダーから提供されています。

### ※オープンソースのライセンス
　オープンソースは無制限に権利を破棄しているわけではなく、ライセンス条文で行っていいことが定められています。この決まりのテンプレートが「MITライセンス」や「GPL」、「BSDライセンス」といったものです。MITライセンスは「再頒布時に著作権とライセンスを表示することで、商用利用も含めて自由にプログラムを利用可能である」ことを定めています。なお、著作権者はいかなる責任も負わないことも明記されています。オープンソースの代表的なライセンスには先ほども挙げたGPL(GNU General Public License)やBSDライセンスなどがあります。

### プログラミングだけでなくWeb開発にも利用できる
　さらに、VSCodeは単なるプログラムソースのためのエディターのみではなく、Web開発にも利用されています。VSCodeはWebサイト向けのHTML記述にも利用でき、拡張機能を導入することで記述したHTMLがどういった画面になるのか即時にプレビューすることも出来るようになります。

## 他のソースコードエディターと何が違う？ 
　VSCodeは多機能なエディターですが、このような機能を持ったエディターはほかにも多数あります。同様のソースコードエディターで有名なものといえば**Eclipse**や**Visual Studio**などが挙げられます。
　Eclipse(https://www.eclipse.org/ )は、当初はJavaのプログラムコードを記述するための開発ツールでした。プラグインを用いた拡張機能が搭載されており、そのほかのプログラム言語はプラグインを活用して開発できるようになっています。
　Visual Studio(https://visualstudio.microsoft.com/ja/ )は、VSCodeと同じMicrosoft社が提供している開発ツールです。「.NET」を中心としたWindowsアプリケーション開発からWeb開発、果てはAndroid/iOS向けの開発まで対応しています。

### ※.NET（ドットネット）
.NETは、アプリケーション開発用のフレームワークです。C#、F#、Visual Basicで記述でき、また複数のオペレーティングシステム(OS)で実行できるアプリケーション（クロスプラットフォーム）開発が可能です。

### 統合開発環境
　これら２種類の開発ツールは「エディター」ではなく「IDE（統合開発環境）」と呼ばれます。プログラムコードの記述をサポートするだけでなく、画面のビジュアル開発機能やテスト支援機能、プログラミング支援機能といった高機能なシステム開発を助ける機能群を備えるためです。
　また、業務で開発する際には複数人での共同開発が必要ですが、これらのツールには共同開発で活用できる機能が多数用意されています。EclipseもVisual Studioも無料で利用できるエディションがあるため、用途を意識して使い分けるとよいでしょう。

## IDEを使う？それともVSCodeを使う？
　開発ツールにはそれぞれの特徴があるため、用途に応じて使い分けることが重要です。それでは、どういった点に注目して利用するツール・エディターを決めればよいのでしょうか。
　判断の１つの指針としては、VSCodeは「画面の開発には向かない」ということがあります。Windowsアプリケーションのように画面とロジックが融合したようなものを開発したい場合は、Visual StudioなどのIDEの利用がおすすめです。
　逆に、コンソールアプリやWeb APIといった画面を伴わないプログラムコードを書きたい場合は、VSCodeを活用するとよいでしょう。

## IDEのほうが動作環境の必要スペックが高い
　IDEとVSCodeでは、機能量からくる要求スペックに違いがあることも忘れてはいけません。VSCodeは1.6GHz以上のプロセッサと1GBのメモリを要件としています(https://code.visualstudio.com/Docs/supporting/requirements )。一方で、IDEは8GB以上のメモリがないと快適な動作は見込めません。
　機能が統合されていない分、余計なパワーが必要なく、手軽に活用できるのがVSCodeというわけです。
 
## 参考文献
これ1冊でできる! Visual Studio Code 超入門 単行本（ソフトカバー） – 2023/3/14
三沢友治 (著)
p.8-11
Oracle GoldenGate入門: リアルタイムでのデータレプリケーションを実現するソリューション

# Oracle GoldenGateとは

Oracle GoldenGateは、異種IT環境におけるリアルタイムデータ統合とレプリケーションのための包括的なソフトウェアパッケージです。異種システム間でのデータベーストランザクションのリアルタイムキャプチャ、変換、および配信を提供します。

## 主な特徴とメリット

### 高可用性と災害復旧
- フェイルオーバー保護のための二次データベースコピーの維持
- ゼロダウンタイムアップグレードと移行の実現
- アクティブ-アクティブデータベース構成のサポート

### リアルタイムデータ統合
- サブ秒レベルの遅延での変更検出と配信
- 異種環境のサポート（OracleからOracle以外へ、またはその逆も）
- グローバルデータセンター間のデータ同期を実現

### 柔軟な構成オプション
- 選択的データレプリケーション（サブセット、フィルタ、変換）
- 一対多、多対一、および双方向トポロジー
- 競合検出と解決メカニズム

## 基本アーキテクチャ

Oracle GoldenGateはモジュール式アーキテクチャを持ち、以下の主要コンポーネントで構成されています：

### Extract プロセス
Extractプロセスは、データベーストランザクションログを読み取ることでデータベースの変更をキャプチャします。DML/DDL操作の変更を検出し、ソース側にトレイルファイルとして保存します。

```sql
-- Sample Extract configuration
EXTRACT EXT1
USERID gg_admin, PASSWORD gg_admin
EXTTRAIL ./dirdat/et
TABLE SCHEMA.TABLE;
```

### Data Pump（オプション）
Data Pumpプロセスは、プライマリExtractによって生成されたトレイルファイルを読み取り、データをリモートシステムに送信するオプションの二次Extractです。

```sql
-- Sample Data Pump configuration
EXTRACT PUMP1
USERID gg_admin, PASSWORD gg_admin
RMTHOST target_host, MGRPORT 7809
RMTTRAIL ./dirdat/rt
TABLE SCHEMA.TABLE;
```

### Replicat プロセス
Replicatプロセスはトレイルファイルを読み取り、変更をターゲットデータベースに適用します。

```sql
-- Sample Replicat configuration
REPLICAT REP1
USERID gg_admin, PASSWORD gg_admin
ASSUMETARGETDEFS
DISCARDFILE ./dirrpt/rep1.dsc, PURGE
MAP SCHEMA.TABLE, TARGET SCHEMA.TABLE;
```

## 実装のベストプラクティス

1. **パフォーマンスチューニング**
   - バッチ操作には配列処理を使用
   - 適切な場所で並列処理を実装
   - 圧縮によるネットワーク帯域幅の最適化

2. **監視と管理**
   - 包括的な監視とアラートの実装
   - Oracle GoldenGate DirectorまたはOracle Enterprise Managerの使用
   - 定期的な健全性チェックと検証の設定

3. **セキュリティに関する考慮事項**
   - AES暗号化によるトレイルファイルの暗号化
   - SSL/TLSによる安全なデータ送信の実装
   - GoldenGateユーザーには最小権限の原則を適用

## 一般的なユースケース

### データベース移行とアップグレード
GoldenGateは、最小限のダウンタイムでデータベースバージョン間、あるいは異なるデータベースプラットフォーム間のシームレスな移行を容易にします。

### レポーティングと分析
本番OLTPシステムからデータウェアハウスやレポーティングシステムへのデータレプリケーションを、ソースシステムのパフォーマンスに影響を与えることなく実現します。

### データ配信
データのサブセットを地域別または部門別のデータベースに配信し、パフォーマンスと自律性を向上させます。

## 結論

Oracle GoldenGateは、リアルタイムデータレプリケーションと統合のための堅牢で柔軟なソリューションを提供します。異種環境間での複雑なデータ移動を必要とする組織にとって、そのモジュール式アーキテクチャと包括的な機能セットは理想的な選択肢となります。

今後の投稿では、高度な構成オプション、他のOracle製品との統合、および実世界の実装シナリオについて探っていきます。
【決定版】全Labubuファンに捧ぐ。究極の高画質壁紙コレクション

Labubu仲間のみんな、集まれ！

ネットの画質が悪いLabubuの壁紙、正直もうウンザリじゃない？だから、週末全部使って、最高の高画質壁紙ライブラリを本気で作ってみたよ！

ほとんどが4K+の高画質で、もちろんウォーターマークは無し。PCでもスマホでも使えるように、一枚ずつ丁寧に調整したんだ。

完全に趣味でやってるから、広告も登録もいらないよ。みんなにも好きになってもらえたら、最高に嬉しいな！
アプリケーションのパフォーマンス最適化のTipsをシェアしよう！～PHP編～

こんにちは！CureSabaです。  
高校生ですが、趣味でPHPのWebアプリを触っています。今回は「キャッシュ」と「DBアクセスの最適化」にテーマを絞って、自分の経験を元に具体例を紹介します。

# 1. キャッシュを使って「毎回同じ処理」を減らそう

最初に作った掲示板アプリは、アクセスが増えるとどんどん遅くなりました。  
調べてみたら「同じデータを何度もDBから取ってる」「ランキング集計を毎回やってる」みたいなムダが多かったです。

## 実際にやったこと

- **PHPのOPcacheを有効化**  
  サーバーの`php.ini`で  
  ```
  opcache.enable=1
  ```
  を入れるだけで、PHPのコード読み込みが速くなりました。

- **Redisでランキングをキャッシュ**  
  人気投稿のランキングを毎回計算するのをやめて、5分に1回だけ計算→Redisに保存するようにしました。

  ```php
  $redis = new Redis();
  $redis->connect('localhost', 6379);
  $ranking = $redis->get('ranking');
  if (!$ranking) {
      $ranking = getRankingFromDB(); // ←DBから重い集計
      $redis->setex('ranking', 300, json_encode($ranking)); // 5分キャッシュ
  } else {
      $ranking = json_decode($ranking, true);
  }
  ```

  これで「急に重くなる」ことがほぼ無くなりました。

# 2. データベースアクセスを減らす・まとめる

掲示板で「投稿一覧」を表示する時、投稿ごとに「ユーザー名」を取るために毎回SQLを叩いていました。これが超ムダで、ページ表示が遅くなる原因でした。

## 実際にやったこと

- **JOINで一気に情報を取る**
  ```php
  // 悪い例：ループで毎回ユーザー取得
  foreach ($posts as $post) {
      $user = getUserById($post['user_id']); // ←毎回SQL
  }

  // 良い例：JOINでまとめて取得
  $stmt = $pdo->query("SELECT posts.*, users.username FROM posts JOIN users ON posts.user_id = users.id");
  $posts = $stmt->fetchAll();
  ```

  これだけで「ページ表示が一瞬で終わる」ようになりました。

- **インデックスをつける**  
  WHEREやORDER BYでよく使うカラム（例：user_id、created_atなど）にインデックスを貼ると、検索が速くなりました。

# 使用例まとめ

例えば「投稿が多い掲示板」でも、  
- 投稿一覧はJOINで一括取得  
- ランキングはRedisでキャッシュ  
- OPcacheも有効化

この3つをやっただけで「アクセス増えても落ちにくい」アプリになりました。

# まとめ

今回紹介したのは「キャッシュの活用」と「DBアクセスの最適化」だけですが、  
どちらも実際に自分でPHPアプリを作ってみて「体感で速くなった！」と感じた方法です。

特に、**Redisによるキャッシュ**は「同じ集計を何度もしない」だけでサーバーの軽さも全然違いましたし、  
**JOINでの一括取得**は「ユーザー名がたくさん必要なランキング」などで本当に効果がありました。

小さな工夫を積み重ねていくと、  
「遅くてイライラする」→「サクサク動く！」に変えられるので、  
これからも色々試していきたいです。

# 終わりに
「この記事が少しでも役に立った！」と思ったら、いいね、コメントであなたの工夫もぜひ教えてください！