OmniAICreator/Qiita-1.07M huggingface dataset:
CodexやらClaude Maxやら使ってのポエム

### 日記です。技術的な話はあまりないです。
- ただただ最近思うことを書き連ねます
- 思考整理やまとめのためなので人に読むための配慮をあまりしていません
    - そんなもんパブリックにするなと言うツッコミは勘弁してください
    - ネットは自由であるべきです

### あれ？AI俺よりすごくね？
最近は本当にすごくなりました。
急に僕が雑魚になったんではなく、AIの進化が素晴らしいです。

２〜３年前のchatGPTがバズった時期は「都合のいい言い訳ツールが出てきたなー」くらいにしか思っていませんでした。
一般的なことを相手に伝える手段として「ChatGPTもそう言ってますよ」って言うためのツール
いかに自分が正当であるかを伝えるツールと言う認識です。
なので、これを業務に導入したいなーとまでは思ってませんでした。
「セキュリティリスクがー」おじさんを説得する方ことの方が面倒だったからです。
「面倒を解決するためのツールの導入が面倒であるなら導入はされない」と言う事例でした。

それがここ最近急激にすごくなりました。
１週間単位で進化しており、ツイッターでは毎日のように新しい情報が出てきます。
１週間前の情報がすでに古いとかよくあります。
Codex出た時結構話題だった気がするんですが、今じゃもうClaudeMaxの話しか聞きません。

バイブコーディングなんて言葉もよく聞くようになりました。
未経験の人がAIツール使ってバイブコーディングで良さげなプロダクトを作ってたりします。
すごいとしか言いようがありません。
実際に個人で利用してみても素晴らしい成果を出します。
もはや「業務に導入したいなー」レベルではありません。
「導入しなければならない」と思うレベルになってしまいました。
「セキュリティリスクがー」おじさんを説得しない方が面倒になる状況です。

### AIすごくなったけどプログラマーは結局必要だと思うよ。
AIは急激に成長し我々の仕事の効率を相当にあげています。
また、職業プログラマーではなくても素晴らしいプロダクトを生成している人もいます。
そのため、プログラマー不要論を唱える人まで出てきました。
私自身は不要論に対して、現状まだ必要だと感じていますし、今後も必要ではないか？と考えています。

我々の仕事は実は結構多岐に渡ります。
要件を聞き、仕様を考え、仕様を満たすためのプログラムを考え、製造する。
テストを行い、品質に問題なければ能忍する。
運用保守フェーズにて継続しての開発等が主たるものになります

要件定義〜納品、保守までの工程を洗い出すと結構多いです。
これ全てがAIで置き換わるかと言うと、難しいところもあるのが現状です。
大量レイオフありましたけど、ご用件聞き係はまだされてないです。まだね。

また、バイブコーディングだけだとセキュリティに関して不安が大きいのではないでしょうか。
決済システムを搭載するようなプロジェクトをAIの力だけで開発することには非プログラマーだと難しいのではないでしょうか。

細かいところをあげていけばあげていくほど、AIの出力を正しく判断ができる人の必要性を感じてくると思います。
それが出来るのは専門職である我々と言うことになります。
いずれは完全にプログラマーが不要になる世界線がくるかもしれませんが、まだ時ではありません。
このペースを鑑みても、後２年はプログラマーが必要だと思ってますし、
必要となる専門職の母数は減ってくかもしれませんが、完全に不要になることはないと思ってます。
「AIが仕事を奪うのではなく、AIに精通した人間が仕事を奪う」と言う言葉を社長からも聞きました。
強く共感します。

### AIの発展で気になること
https://x.com/kawaii73428831/status/1927679218995077170

このスレッドに書いてる内容が思っていたことになります。
色々自分でやってた際に得た学びがあったんだよね。
でもAIだとその学びの機会が喪失されちゃいそうなんだよね。
って言う話になります。

スレッドにもぶら下げてますが、以下の記事もAIに依存することへの危険性を説いています

https://hbr.org/2025/05/research-gen-ai-makes-people-more-productive-and-less-motivated

研究レポートではその問題に対して企業が取るべき施策についても言及していますが、
まぁ個人だと対応しきれない話もあるなぁと思ってます。
楽にはなるけど、良いことばかりとも言い切れないのかなーなんて老害じみたことを考えてます。
人間なので自分が思った感想に対して、都合の良い研究論が出てきたから危険だと思い込んでるだけかもしれませんが、（何バイアスって言うんだっけ。）
まぁちょっと時代の転換期であるのでわからないなーと思ってます。

便利な道具が出てきたら、それを使いこなしてさらに発展してきたと言うのが人類史でもあるので、
案外堕落しないでより良い世界を作成している気もします。
日記であり、ポエムなので結論が煮え切らない感じになってます。

### 終わりに
間違いなく１つ言えることがありまして、
それは生成AIを使うと短期的に見ると生産性が大きく向上することです。
１〜２年以内に生成AIを使って仕事をすることが当たり前になるでしょう。
今触ってない人で触りたくない人は今すぐ無理して触る必要はないと思ってますが、興味くらいはもっといた方がいいと思います。
今触ってもどうせ１週間後にはさらに便利になってるんで、落ち着いてから触るでもいいだろうとは思ってます。
終わり。
Ubuntu に neovim をインストールする

# neovim 本体をインストールする。
```
sudo apt update && sudo apt full-upgrade -y && sudo apt autoremove --purge -y
sudo snap install nvim --classic
```
apt repository の nvim のバージョンが古いため snap で nvim をインストール

# 開発環境のインストール
```
sudo apt install build-essential
```

# [LazyVim](https://www.lazyvim.org/) のインストール

```
git clone https://github.com/LazyVim/starter ~/.config/LazyVim
rm -rf ~/.config/LazyVim/.git
```

私の macOS 環境だと iTerm2 上で動作させた場合、vi コマンド実行時にコマンドの一覧を表示するプラグイン (which-key.nvim) が動作したタイミングで画面がクリアされる[問題](https://www.reddit.com/r/neovim/comments/1k03a76/lazyvim_on_iterm2_screen_clearing_when_entering/)が発生。以下の設定項目にチェックを入れることで問題は解決した。

iTerm2 > Settings > Profiles > Terminal > Emulation features > Disable session-initiated window resizing

which-key.nvim を無効にする場合は以下の記述を追加。

``` ~/.config/LazyVim/lua/plugins/disabled.lua
return {
  -- Disabling which-key.nvim
  { "folke/which-key.nvim", enabled = false },
}
```

(iTerm2 + 0.9.5 あるいは AstroNvim では which-key は問題なく動作するのだが。。。)

LazyVim を起動する

```
NVIM_APPNAME="LazyVim" nvim
```

# [AstroNvim](https://astronvim.com/) のインストール
```
git clone https://github.com/AstroNvim/template ~/.config/AstroNvim
rm -rf ~/.config/AstroNvim/.git/
```

AstroNvim を起動する

```
NVIM_APPNAME="AstroNvim" nvim
```

[Mappings](https://docs.astronvim.com/mappings/) を見ると Ctrl-Q が Force Quit になっている。個人的にはこれは要変更。。

# [NvChad](https://nvchad.com/) をインストールする

```
git clone https://github.com/NvChad/starter ~/.config/NvChad
rm -rf ~/.config/NvChad/.git
```

NvChad を起動する

```
NVIM_APPNAME="NvChad" nvim
```

# LazyVim と AstroVim の alias の例

```
alias nvim_lazy='NVIM_APPNAME="LazyVim" nvim'
alias nvim_astro='NVIM_APPNAME="AstroNvim" nvim'
alias nvim_nvchad='NVIM_APPNAME="NvChad" nvim'
```
# アンインストール方法

[AstroVim](https://docs.astronvim.com/reference/uninstall/)

```
rm -rf ~/.config/nvim \
  ~/.local/share/nvim \
  ~/.local/state/nvim \
  ~/.cache/nvim
```

おそらく LazyVim や NvChad もディレクトリ名を変えるだけ。
Tailwind CSS 使用時コンテンツ検出されず必要な css が出力されないとき


## はじめに

Tailwind CSS には記述されている CSS を検出し、必要な CSS のみ出力されるようになっている。
Tailwind CSS v4 から自動検出されるようになったが v3 以前や 明示的に参照してほしいファイルが有るときに指定する記述がある。

## `@source` について

タイトルの通り検出されなかった場合、 `@source` を明示的に指定することで回避可能である。
Tailwind CSS の Build process から認知されないような `node_modules` 上に無いライブラリやファイル。その他テンプレートファイル `php`, `slim` 等を明示的に指定する。

もし、 `../foo/bar` ディレクトリ配下のファイルを見てほしい場合は以下のように記述すれば良い。

```diff_css:example.css
  @import "tailwindcss";
+ @source "../foo/bar/"
```

## Ref

https://tailwindcss.com/docs/functions-and-directives#source-directive

https://tailwindcss.com/docs/detecting-classes-in-source-files

https://tailwindcss.com/docs/installation/framework-guides/laravel/vite

https://flowbite.com/docs/getting-started/vue/
コンポーネント間の調和：Reactでの状態管理にReduxを使う方法

## はじめに：Reactの状態、混乱してませんか？

小さなTODOアプリを作ったとき、気づいたら状態を3階層くらい下までpropで渡してて、「え？ なんでこんなに複雑？」って思ったんです。それがReduxとの出会いでした。今ではもう、**メッセージ**を一つの場所で管理できるありがたさに感謝してます。

---

## 問題：Reactの状態管理の壁

Reactの「部品ごとに分ける」アーキテクチャは素晴らしい。でもアプリが大きくなるにつれ、状態の管理が爆発的に難しくなるんですよね。私は一度、親コンポーネントに全状態を集めたことがあるんですけど、それが逆に**コネクション**（[リンク](https://maestrosespirituales.com/lectura-del-tarot-chicago/)）の断絶を生む原因になって…。Reduxが救世主でした。

---

![Before.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4101896/06a87c9f-4aa4-4656-96ca-e20e3e94ce7d.png)

## Reduxの基本用語（カジュアル解説）

- **Store**: アプリ全体の状態を持つ1か所の箱みたいなもの。
- **Action**: 「なにが起こったか」を伝えるJavaScriptオブジェクト。
- **Reducer**: Actionを見て「じゃあ状態はこう変えよう」と判断する関数。
- **Dispatch**: Storeに「こんなこと起こったよ！」って知らせる方法。
- **Selector**: 必要な部分だけ取り出す賢い関数。

---

## 実装ステップ（コードで理解しよう）

### パッケージのインストール

```bash
npm install redux react-redux
```

### ストアの作成

```javascript
import { createStore } from 'redux';
import rootReducer from './reducers';

const store = createStore(rootReducer);
```

### Reactにストアを提供

```javascript
import { Provider } from 'react-redux';
import App from './App';

ReactDOM.render(
  <Provider store={store}>
    <App />
  </Provider>,
  document.getElementById('root')
);
```

### アクションの定義

```javascript
const increment = () => ({
  type: 'INCREMENT'
});

const addTodo = text => ({
  type: 'ADD_TODO',
  payload: text
});
```

### リデューサーの作成

```javascript
const counter = (state = 0, action) => {
  switch (action.type) {
    case 'INCREMENT':
      return state + 1;
    default:
      return state;
  }
};
```

### コンポーネントとの接続

```javascript
import { connect } from 'react-redux';

const mapStateToProps = state => ({
  count: state.counter
});

const mapDispatchToProps = dispatch => ({
  onIncrement: () => dispatch(increment())
});

export default connect(mapStateToProps, mapDispatchToProps)(CounterComponent);
```

### セレクターの活用

```javascript
const getCompletedTodos = (state) =>
  state.todos.filter(todo => todo.completed);
```

---

## 実例：To-Do アプリの状態管理

複数のコンポーネントがタスクのリストを読み書きするアプリを想像してみてください。Reduxを使えば、タスクを一元的に保管して、どのコンポーネントからでも読み書きできます。propのバケツリレーとはおさらば！

---

## Reduxを使うと得られるもの

- 🎯 **予測可能な状態**：状態の流れが明確だから、バグの原因も追いやすい。
- 🛠 **開発ツールの強力さ**：Redux DevToolsで状態の変化を時間軸で追える。
- 🔧 **コードのメンテしやすさ**：処理の役割がはっきりしてて、後からでも読みやすい。
- 🚀 **スケーラビリティ**：アプリが大きくなってもReduxなら耐えられる。

---

## まとめ

Reactアプリが少しずつ成長していくとき、その状態管理にReduxを取り入れるだけで本当に楽になります。使わない手はないですよ。試してみてください。**メッセージ**がちゃんと届くようになりますから。

---

> おまけリンク：
- アプリの**保護**（[リンク](https://botanicavirgenmorena.com/amarres-de-amor-en-chicago/)）に関するスピリチュアルな視点も面白いかも？
- Reduxの使い方に関するさらなるTipsは[Qiita](https://qiita.com/)で探せます！
2025/05/26 〜 2025/05/3 振り返り

## はじめに
こんにちは。
@HayatoHanaoka です。
先週は仕事終わりに諸々の用事が立て込み、振り返りができませんでした...。
今週はしっかりやります。

## 今週の行動
先々週出したアクション

:::note info
設計や実装について考える時、
既存か新規かに関わらず自分の理解を図に起こし、
ペア相手にフィードバックをもらう
:::

### 良かった
- チームメンバー全員でアーキテクチャについて確認する場で、自らペンを握って主導して図を書くことができた
    - 自分が開発しているプロダクト（機能）への理解度と解像度を上げることができた
- 図にしてみることで、理解できていない部分が浮き彫りになり、改めて確認することができた
- 追加機能の実装の際、処理の一部をメソッドとして切り出す判断を自ら行い、提案できた
    - それが採用されたことで、プロダクト開発に貢献できた感覚が得られた

### 伸び代
- 自分が考えていることをうまく言語化して伝えることができず、
ペアプロでのコミュニケーションコストが増加したと感じた場面があった
    - 出来事を時系列で伝えてしまうのが良くなかった
        - 調査系であればそれで良いのかもしれないが、開発においてはそこまで細かに伝える必要はない
            - もっと情報を小さく核となる部分だけ伝える
        - 現状と理想をまずは認識し、差分がどこなのかを端的に説明するよう心がける
            - 現状と理想をどこかにメモしておくのも良いかも
        - 結論 -> 仮説や意図 の順で伝えることで、より明確かつ端的に物事を伝える
- 質問するまでに少し時間をかけてしまった場面があった
    - 「何がわからないから聞きたいのか」「自分の考えはどうなのか」をはっきりさせようとしすぎた
        - ある程度の時間を決め、粗くても良いのでその時間内で自分なりの結論を出す

## 来週のアクション
個人的には、伸び代の1つめが大きな課題と感じているため、そこを解消するアクションとします。

:::note info
自分の考えていることを言語化しやすくるために、
以下の軸で言語化できないか試してみる
- 現状と理想の差分
- 結論 -> 仮説や意図 の順で伝えられるか
:::
スマホで見ると最初の画面幅より下行くと色がかわってしまいます

最初の画面幅より下に行くとテキストのコンテンツなどは下まで行くんですがバックグラウンドカラーがかわってしまいカッコ悪いです![IMG_4857.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1230737/49828295-d298-4bc4-9e5f-cf913c2f82e6.png)
こういうのはどうしたらなおりますか？
Snippai：読み取り・解決・要約までしてくれるAIスクリーンショットツール

## スクリーンショットがただ溜まっていくだけで終わっていませんか？

**Snippai** は、これまで使った中で最もスマートな無料のスクリーンショットツールです。  
ただ画像を読むだけではなく、**内容を理解して処理**してくれます。

---

## 🧠 Snippaiの主な機能

- 📐 数式や方程式を **LaTeX形式** に変換  
![formula](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4101870/beac9e9c-8e62-49a1-b2c6-e4c5f250f82e.png)

- 📊 表やグラフを **Markdown形式** に変換
![table](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4101870/505f78d5-ffa6-468d-a510-36b855623ec7.png)

- 🧠 長文や画像内の情報を **要点に自動要約**  
![summarize](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4101870/44075f44-371d-4710-a8bb-bd25a6986b28.png)

- 💻 **コードスニペット** を検出して解説  
![code explanation](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4101870/eba21357-07bf-46f6-9510-e884c8f25106.png)

- 🧩 **プログラミング問題** を自動で解く  
![Coding problem](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4101870/26f12ee3-a2da-4cb6-86cf-f4523d4f9a8d.png)

- 🎨 **色やデザイン要素** を認識  
![Color](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4101870/fe00a756-4076-40d5-ac01-e9e9efba1683.png)


---

**視覚的に作業する** 学生、研究者、エンジニアに最適です。

---

## 🎯 Snippai v0.1.8 で作業効率を向上！

- ✅ macOS（Mシリーズ含む）対応  
- ✅ Windows対応  
- ✅ 現在**無料で利用可能**

📥 **ダウンロードリンク**  
[Download Link](https://sn.lovable.app/)

💬 **Discordコミュニティ**  
[Discord Invitation](https://discord.gg/tcwW7kve)

---

ぜひ使ってみて、フィードバックをお聞かせください！
SwiftUIとの向き合い方


https://x.com/yuki_arano/status/1900165464657219995?s=46&t=3ZRRL4XcziL3uyyVMGKAbQ

https://x.com/lovee/status/1928104383897624996?s=46&t=3ZRRL4XcziL3uyyVMGKAbQ

https://x.com/t_kis/status/1915584245579289060?s=46&t=3ZRRL4XcziL3uyyVMGKAbQ

ViewModel不要論

https://dimillian.medium.com/swiftui-in-2025-forget-mvvm-262ff2bbd2ed
Java Gold 11 合格したときの勉強方法（元調理師SE）

# はじめに
タイトルにある通りJava Gold 11に合格したので
勉強方法を振りかえるとともにこれから受ける人の参考になればと思います

# 筆者の経歴
調理師専門学校卒業、調理師で１年ほど働き、その後フリーター半年の間に独学でプログラミング学習
現在はパッケージを使用した業務系のSE５年目、主にピュアなjava6~8、Oracle11~19のシステムをいじいじしてる
結論的には大卒、理系や文系など関係なしにやる気あれば取得できるということを伝えたい

# 想定する読者
・社会人（学生でもかまいません）
・Oracle認定JavaプログラマSilver SE 11を所持している（Gold受けるために必須）
・Java Gold SE 11を受験することを検討している。
・平日は忙しくとも、土日は試験勉強する時間がある。
・会社に資格試験の費用を負担してくれる制度や合格手当などがある。(モチベ)

# 個人的に受けてみての難易度
silverのときより難しいです
silverはほぼ黒本覚えてれば行けた記憶ですが
今回のGoldは暗記もありますがしっかりコードの流れや、よく使用するコレクションのメソッドや特徴など
わかってないと落としてしまうと受けてみて思いました
ただ後述のようにほかのGold受験者同様黒本やりこめば問題はないと思います

# 勉強方法
期間は３週間で筆者は受験しました
使用教材は以下
「徹底攻略Java SE 11 Gold問題集[1Z0-816]対応」（通称：黒本）

あとUdemyで以下の教材をセールの時買いました
「Java言語【Java 17対応】の高度な機能（マルチスレッド、ラムダ式、ストリームAPI、ネットワーク、総称型など）を詳細に解説／豊富な企業システム開発経験を生かした実践的な内容」

ラムダやストリームAPIは業務で使用機会ないのでUdemyのもの購入で実際に受講しました
説明は丁寧なのですがやはり理解までは自分でかみ砕く必要あるという感じです

youtubeで黒本著者の志賀さんがSilver,Goldともに一部解説してるのがあるので
そちらで該当の部分あれば見るのが個人的にはわかりやすかったです
あとはいまだとchatGPTですかね
わからない部分あれば小学生にわかるように例えて教えてとプロンプト決めて質問すると
理解進むと思います

ただメインは黒本の周回です
これだけやればGoldを取るうえでは安心できます
具体的には４～５周はしてほしいです

最初の１～２周がきついですが３週目からは楽になっていきます
最初の１～２週の時は見開きごとの問題を解いてみてはすぐに答えを確認してました
（やりきるのが大事、完全理解は無理なので答え見てなんとなくこの選択肢になるのか～の温度感で
どんどん次に行く）

またこの時に自分はNotionなどメモ帳使用して問題ごとに解説を自分でかみ砕いてメモしてました
（やりきるのが大事なのでやらなくてもいいと思うが、自分の言葉で再度解説することで覚えやすくなるし、次から問題解くの楽になる）

実際に使用してたNotion以下例
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1128178/ba8743d4-c614-4bac-bdcf-8ffba7c25601.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1128178/d917cc15-4a84-489d-b396-82f9e60718a8.png)

また黒本の問題はEXCELで回答するようにしてました
他の行に答え書いといて入れたら下の行に〇×出して何度も手軽に答え合わせできて楽でした

以下は使用例で、章ごとにシート作成、答えは実際は非表示にしてる
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1128178/0d38952e-a3e6-4ad2-b909-ad0fb9c8d542.png)

黒本も電子と紙両方あり、どっちも使用したけど
紙はすぐ答え見れながら問題解けるけど、かさばるし、その都度開くのがめんどくさい

電子はNotionとか使うときに画像切り取って解説に使えたり便利
ただ問題から答えは紙のようにスムーズにいけないのでそこが不便（ページ指定しないといけない）

このような形で黒本５週くらいしたら83%で無事合格しました
実務の下積みも多少あるからと思いますが
１つの参考にしていただければと思います

ここまで読んでいただきありがとうございました
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

本記事の書き方参考

https://qiita.com/BLACK13/items/7234254c8455594a06c2#%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB

勉強参考

https://www.bold.ne.jp/engineer-club/howtolearnoracle-certified-java-programmer-silver-se-11
AYAのインフラエンジニア

# はじめまして
### このアカウントの目的
インフラエンジニアを始めて1年半年のAYAと申します。
初投稿になります。
このQiitaアカウントでは今まで私がインフラエンジニアとして学んできたこと、資格試験の話、今勉強中のAWSに関しての内容を投稿しようと思います。
この投稿で少しでも「インフラエンジニアって何？」という問いに対して、大まかでもイメージを持っていただければ嬉しいです。
## 私自身の話
私は今、IT業界でインフラエンジニアとして働いております。その理由はお金が欲しいからであり、今の自分にとって最も現実的にそれを叶えられる手段がITエンジニアになることでした。
## 小売業界からの転身
2021年に大学を卒業後、2年半ほど小売店業界で働きました。当時は「残業がないかつ好きなことで仕事をしたい」という今思えば甘ったれた考えでそこを選びました。
しかし、そんな考えに至れたのは親のおかげで何不自由ない暮らしをできたからで、自分で生計を立てたことがないからだということを社会人になって知りました。自分のやりたいことをやろうとすると、あっという間に手元の通帳からお金がとんでいくのです。
## 資格の勉強から転職
このままじゃダメと思った私は大学時代、買って満足してそのまま死蔵した基本情報技術者の参考書を思い出しました。
小売業界の平均年収は約300万円台後半、ITエンジニアは約400万円台後半。
情報系出身である私にとって、IT業界は現実的な選択肢でした。
私がお金を稼ぐためにはこれしかないと思い、IT業界への転職を決意。
はじめの一歩として、基本情報技術者の資格勉強を始めました。
勉強して半年してようやく合格。資格証明書を片手に無事、インフラエンジニアに転職することができました。
インフラエンジニアに転職後も資格勉強を続け、今は以下の資格を所有しております。

- **国家資格**
   基本情報技術者
- **ネットワーク系**
CCNA
- **サーバ系**
   LinuC レベル1〜3（304を所有）

- **AWS系**
   クラウドプラクティショナー
   ソリューションアーキテクト アソシエイト
   SysOps Administrator アソシエイト
- **Azure系**
   AZ-104：Azure管理者アソシエイト
   AZ-305：Azureソリューションアーキテクトエキスパート
# インフラエンジニアって何？
初投稿で語ることは、ずばりこちら。**「そもそもインフラエンジニアとは何なのか？」**
インフラエンジニアとはITエンジニアの一種なのですが、皆様はITエンジニアと聞いていったいどのような姿を思い浮かべるでしょうか？
子供のころの私であれば、2008年にテレビで放送されていたドラマ「ブラッデイマンデイ」の主人公のように、以下のようなコードの集合体ことプログラムを書いて対象のサーバからデータを書き換えたり盗んだりする人と答えるでしょう。
```terraform:program.tf
resource "aws_vpc" "vpc" {
         cidr_block    = "X.X.X.X/24"
  }
```
子供のころの私よ、それはエンジニアではないハッカーだ。
そしてこれは「プログラム」ではなく「IaC（Infrastructure as Code）」だ。
でも子供のころの私、それはインフラエンジニアの説明には実はぴったりなんだ。
## ドラマの中の「悪さ」を分解してみる
**1:ネットワークに接続**
**2:パソコンの設定を調整**
**3:対象サーバを特定**
**4:セキュリティ突破**
**5:サーバ操作・データ改ざん**

ということが行われます。(実際はもっと複雑)
ここにおける**ネットワークやサーバ、セキュリティの環境を整えるのが、インフラエンジニア。
システムを動かすために必要な土台（インフラ）を作るエンジニア。**
それが今の私の職業です。
## インフラエンジニアの種類
インフラエンジニアは範囲が広く、大まかに以下のように細分化することができます。

**ネットワークエンジニア**

ネットワークを作るエンジニア。まんまです。まさにその名の通りです。
皆さんがオンラインゲームをするとき、そのネットワークを支えているのがネットワークエンジニアです。
とてもお世話になっております。
流石にこれだけだといろんな方に怒られそうなので後々の投稿で語っていこうと思います。

**サーバエンジニア**
サーバを作るエンジニア。これも名の通り。
これも皆さんがソシャゲやネトゲをするとき、ネットワークエンジニアさんが作ったネットワークの中にあるサーバへ繋いでゲームをしております。
これも皆さん大変お世話になっております。
これも後々語っていこうと思います。

**セキュリティエンジニア**
システムのセキュリティを作るエンジニア。名は体を表すとはいったものですね。
これがおろそかになると、主人公に中身をやりたい放題されるというわけです。
セキュリティに関しては専門外になってしまうので、このブログでは取り扱わないで行こうと思います。仮に取り扱うにしても、セキュリティに関しての知識を得てからになります。

**クラウドエンジニア**
AWSやAzure,GCPといったクラウドコンピューティングサービスでインフラを作るインフラエンジニア。近年勢力を拡大している。私は今、このクラウドエンジニアになるべく勉強を行っております。

その他にもデータベースを取り扱うデータベースエンジニアだったりあります。

本日は以上です。


# まとめ
- インフラエンジニアは、**ITシステムの土台を構築・管理するエンジニアです
- 役割は多岐にわたり、ネットワーク・サーバ・セキュリティ・クラウドなどに細分化されます。サーバエンジニア等々細分化することができます
今後は、それぞれの分野について深掘りしていく予定です。

**みんなが知らないだけでインフラエンジニアは大活躍しております。**
本日はここまで。
最後までお読みいただき、ありがとうございました。
次回はネットワークを作るエンジニア「**ネットワークエンジニア**」をテーマに記事を書く予定です。
YUNZII RT68の入力と環境設定方法

YUNZII RT68の備忘録(環境構築メモ)


Amazonでほぼ一目惚れで、カッコつけて65%キーボードというものを買ってみました。しかし、中華キーボードであり、説明書がペランペランでなんだか頼りなく、重要なコマンドや記号が打てなくて結構悪戦苦闘しました。

ほぼ勘で色々いじってみた結果のキー入力についての私個人的な備忘録を書いてみました。
誰かのお役に立てれば一石二鳥です。

Macでの設定方法
USB-cコネクタでMac本体と接続する＞「システム設定」＞「キーボード」＞「キーボードの種類を変更...」＞「認証手順通りにShift+z, Shift+/」＞「ANSI(米国)102, 101」を選択＞完了



YUNZII 65%キーボードの入力方法
「数字」: Fn+該当する数字キー
「伸ばし棒ー」: Fn+-
「英語入力と日本語入力の切り替え」: Ctrl+スペースキー
「!@#$%^&*D()_+」: Shift+Fn+該当するキー
「コピー」: Alt+c
「ペースト」:Alt+v
「保存」: Alt+s
「1つ前の操作に戻る」:Alt+z
「同時にタブ下げ」: Tab
「同時にタブ上げ」: Tab+Shift
「全画面表示のそれぞれの画面の切り替え」:Ctrl+右左矢印

最低限これくらい知っておけば大きくは困らないかと思われます。買った当日にこちらの記事を書いています。
この謎の配列に全く慣れていないので、なんかの拍子に何かのキーを間違えた押し方で押して、意図しない操作ばっかり出てきててんてこまいです。

また何か発見したら投稿します。
それにしても、やっぱり65%配列はFnキーを押す手間がちょっとめんどくさいかなと思いました。でもミニサイズなのは魅力的ではあります。
可愛いキーボードで楽しいPCライフが送れそうです。
Qiita記事執筆を効率化するテンプレートの作り方

## 初めに
作業効率化のためにQiita記事作成用のテンプレートを作成しました。

## テンプレート

```
## 初めに

## 環境
| 開発環境   |バージョン    |
|-----------|------------|
| __-----__ | ---------- |
| __-----__ | ---------- |

## 目次
- [初めに](#初めに)
- [環境](#環境)
- [環境構築](#環境構築)
- [手順](#手順)
- [実装](#実装)
- [最後に](#最後に)

or

## 目次
[TOC]

## 環境構築
// ```
    // 環境構築の内容
// ```

## 手順

## 実装
// ```vuejs:vueConponent.vue
    // 実装内容
// ```

## 最後に
最後まで閲覧いただきありがとうございました。
ご意見、ご指摘ありましたら、コメントお願いいたします。

```

## 最後に
最後まで閲覧いただきありがとうございました。
もっとこうしたらいいよとか、ありましたらどしどしご意見お願いいたします。
【Laravel × Docker】http:localhost/xxx が Not Foundになる原因と解決法

## はじめに

Laravel + Docker + Apache 環境で、ルーティングがうまく動かずNot Foundになる問題に直面。
原因と解決方法を備忘録として残します。


## 環境
| 開発環境   |バージョン    |
|-----------|------------|
| __windows__ | 11 |
| __WSL Ubuntu__ | 20.04 |
| __Laravel__ | 12 |

## 🔥発生した問題

Laravelプロジェクトで以下のようなルートを定義しているのに。。。
```php:routes/web.php
Route::get('/hogehoge', function() {
    return view('welcome');
});
```

ブラウザでアクセスすると、以下のようにエラーになります。
```bash:ブラウザ
http://localhost:8080/hogehoge
→ Not Found
```

しかし以下なら表示される。
```bash:ブラウザ
http://localhost:8080/index.php/hogehoge
→ 表示される（Laravelに届いている）
```

## 原因
Apacheが .htaccess を読み込んでいない（=URLをlaravelに渡せていない）。
・mod_rewrite モジュールが無効
・.htaccess の読み込みが無効（AllowOverride Noneになっている）

## 解決手順
① コンテナに入る
```bash
docker exec -it コンテナ名 bash
```
※コンテナ名は自分の環境に合わせてください。

② mod_writeを有効にする
```bash
a2enmod rewrite
```

③ Apacheの設定を修正する
```bash
vim /etc/apache2/apache2.conf
```
以下のように修正する
```bash
<Directory /var/www/html/public>
    AllowOverride None→これを「All」に変更する
    Require all granted
</Directory>
```

④ Apacheを安全に再起動
```bash
apache2ctl -k graceful
```

ブラウザで再度アクセスしてLaravelの画面が表示されれば成功！
```bash:ブラウザ
http://localhost:8080/hogehoge
```

### なぜindex.php/xxx は動くのか？
Laravelのフロントコントローラは public/index.php にあるため、そこを直接指定すればルーティング処理が動きます。
ただし、本来は .htaccess により index.php を省略できるようにするのが正しい構成です。


## 最後に
最後まで閲覧いただきありがとうございました。
ご意見、ご指摘ありましたら、コメントいただけますと幸いです。
【Mac】duコマンドの使い方


`du`コマンドを使用するとファイルやディレクトリのサイズを確認できます。

## ディレクトリとサブディレクトリのサイズを指定した単位 (KiB/MiB/GiB) で一覧表示

```terminal
du -k|m|g path/to/directory
```

## ディレクトリとサブディレクトリのサイズを人間が読める形式で一覧表示

```terminal
du -h path/to/directory
```

## 単一のディレクトリのサイズを人間が読める単位で表示

```terminal
du -sh path/to/directory
```

## 特定のディレクトリとその中にあるすべてのファイルとディレクトリのサイズを人間が読める単位で表示

```terminal
du -ah path/to/directory
```

## ディレクトリとその中にあるすべてのファイルとディレクトリの人間が読めるサイズを指定したレベルまで表示

```terminal
du -h -d 2 path/to/directory
```

## 現在のディレクトリのサブディレクトリにあるすべての .jpg ファイルの人間が読めるサイズを一覧表示し累計を表示

```terminal
du -ch */*.jpg
```
SQLを少しでも早くするためのチェック

## なぜ構文のチェックを行うのか？
「別に動けばいいのでは？」「速度は遅くなってないので今のままでもいいのでは？」そんな声があるかと思います。
確かに今はいいのですが、元のデータが多くなった場合や実施回数が多くなった場合など
に少しずつ遅くなる可能性があります。

私が経験したのは、プロジェクトで1つのシステムで機能が増えて大きくなった場合や複数の会社が開発に携わった場合、処理速度差が発生し、全部のSQLを見直すようなことが時々ありました。

ハード増強による解決もいいのですが、まずは実行計画の見直しなどを行うかと思います。
それ以外にもSQLの記載の積み重ねによって速度が変わってきたりもします。

私も過去にプロジェクト全体で以下のような項目をチェックした結果速度を改善したことがあります。
備忘録的にも私がチェックした内容を記載致します。
このような部分になっている箇所がないか、見てみるのもいいかもしれません。
（保守しやすい書き方も含めてチェックシートを作成しておくのいいかもしれません。）

## チェック項目
### ■共通
- SQLのキーワードは大文字で書かれているか。
- 極値関数(MAX / MIN)でインデックスを活用しているか。
（データの重複を気にする必要がない・発生しない場合の）UNION、INTERSECT、EXCEPT には「ALL」を付けているか。

### ◇SELECT句		
- 不要な項目を指定していないか。
（＊：ワイルドカードを使用せず、明示的に項目名を記述しているか）	
- DISTINCTを使用していないか。	
- 行数を数えるときは「COUNT(*)」ではなく「COUNT(列名)」を使っているか。	
- 複数のテーブルをJOINしている場合、CASE式の検討をしているか。
（CASE式を使用し、最大、最小を取得したテーブル作成して、JOINする。）	
- カラム番号で取得項目の指定をしてしていにか。	
		
### ◇FROM句		
- SQL中で使用されないテーブルを記述していないか。	
- JOINの子表を結合する条件はPKもしくはインデックスを付与した項目を使用しているか。	
- JOINするテーブルが6個以上になる場合、回避方法の検討しているか。	
- LEFT OUTER JOINとINNER JOINで同じ結果が得られる場合、INNER JOINを使用しているか。	
- 直積（結合条件のないテーブルを複数指定）を使用していないか。	
- テーブルに別名をつけるいるか。	
		
### ◇GROUP BY句		
- GROUP BY句で指定されている項目にインデックスが付与されているか。	
- GROUP BYの利用で、可能な限り、HAVINGではなくWHEREで絞り込んでいるか。	
- GROUP BY句を用いた検索結果をソートする場合に、ORDER BYを指定しているか。	
		
### ◇ORDER BY句		
- ORDER BY句で指定されている項目にインデックスが付与されているか。	
- レコードの返却順を保証する必要がない場合に、ORDER BYを利用していないか。	
- 不要な項目がORDER BY句に指定されていないか。	
		
### ◇INSERT句		
- 連番を使用する場合、採番テーブルなどを使用していないか。
（連番であればシーケンスを使用する。採番テーブルを利用した場合、使用されるSQLはきわめて単純な構文になる為、改善する方法がない。）	
- 大量データのINSERTを１件ずつ行っていないか。	
		
### ◇UPDATE句		
- 大量データのUPDATEを１件ずつ行っていないか。	
- MERGE文の検討をしているか。
（OracleやDB2などMERGE文が利用できる場合、条件をON句にまとめることができるMERGE文を利用したほうがメンテナンス性、データ増加によるパフォーマンスの低下が少ない。）	
- 主キー項目に対する更新がされていないか。	
- 少ない回数で更新できる検討されているか。
（関数サブクエリなどを使用することでSQL実行回数を減らすことでパフォーマンスは上がる。）	
		
### ◇DELETE句		
- TRUNCATEの使用を検討したか。
（全てのデータを削除する場合は、利用を検討）	
		
### ◇WHERE句		
- 検索条件には、必ず主キーまたはインデックスが定義されている列（第１索引列は必須）を指定しているか。	
- 副問合せ内の抽出条件はPKもしくはインデックスを付与した項目を使用しているか。	
- 条件式の左辺には関数を指定していないか。(項目名を左辺に記述することが前提)	
- 条件式の左辺には算術演算等の式を含めていないか。(項目名を左辺に記述することが前提)	
- 条件式の左辺には文字列操作を行っていないか。(項目名を左辺に記述することが前提)	
- 条件式の項目は、同一のデータ型を使用して比較しているか。	
- 検索条件が複数ある場合、絞り込み結果がより少なくなる（データ分布が粗い）条件から先に記述しているか。	
- 検索条件でIN句を使用する場合、より見つかりやすい（データ分布が粗い）条件から先に記述しているか。	
- サブクエリの引数は「EXISTS述語」を使用することを検討しているか。（IN述語を使用する場合は、EXISTS述語で同じ結果を取得することができる）	
- 副問い合わせを行う場合、EXISTSの中に副問合せを書くのではなく、JOINの利用を検討しているか。
（ただし、JOINの利用は、EXISTS利用時と問合せ結果が異ならない場合に限る。）	
- NOT INの代替として、NOT EXISTSの利用を検討しているか。	
- 異なる列に対する条件の場合、可能な限りORではなくUNIONを利用しているか。	
- Like文では、前方一致検索（LIKE 'XXX%'）のみを使用しているか。	
- WHERE句の範囲指定は、不等号ではなくBETWEENを使用しているか。	
- 複数の固定値を条件とする場合、可能な限りLIKE述語ではなく、IN述語またはBETWEEN述語を使用しているか。	
- "パーティション分割するテーブルを検索する場合、必要なパーティションのみにアクセスさせるために、
検索条件にパーティション分割キーを指定しているか。"	
- テーブル設計でNULL状態の項目を持たせない、列値と条件比較する等の対策を実施し、IS NULLは利用されていないか。	
- 「<>」「!=」「NOT ～」などの否定演算子を利用せず、「=」「IN」「BETWEEN」などの肯定形で比較しているか。	
- 複数のSQL文がDECODE関数を使用して一つにまとめることができるか検討しているか。	
- 副問合せは原則2つまでとしているか。	
- サブクエリにてネストは原則使用していないか。	
- サブクエリにて相関サブクエリーは原則使用していないか。	
- 暗黙の型変換は回避しているか。	
- IN述語の引数は「最もありそうなキー」を左に記述しているか。	
		
### ◇その他		
- 選択する行に重複行を含んでも影響のない場合には、UNION ALLを指定しているか。	
- 暗黙的なソート処理が発生するSQL文
（DISTINCT、UNION、INTERSECT、MINUS、EXCEPT）を使用していないか。
配列を安全にコピーする方法（shallow copy vs deep copy）

# はじめに

**こんな経験ありませんか？**

表計算アプリ、グリッドレイアウトなどをJavaScriptやTypeScriptで扱っているとき、「次の状態を作るために配列をコピーしたのに、**なぜか元の配列まで変わってしまう**」

そんな不思議なバグに遭遇したことはありませんか？

```ts
const current = [
  [0, 1],
  [1, 0]
];

const next = [...current]; // コピーしたつもりが…
next[0][0] = 999;

console.log(current[0][0]); // 👉 999!? なぜ？
```

実はこれ、「**shallow copy（浅いコピー）**」が原因なんです。

# Shallow copy（浅いコピー）とは？

shallow copyとは、**配列やオブジェクトの「最上位の層」だけをコピーすること**です。
それに含まれる**ネストされた配列やオブジェクトはコピーされず、参照（ポインタ）だけがコピーされます**。

```js
const original = [[0, 1], [1, 0]]
const shallowCopy = [...original]

// shallowCopy[0] は original[0] と同じ参照を持っている
```

`shallowCopy[0][0] = 999` と書くと、**original\[0]\[0] にも影響が出る**というわけです。

# Deep copy（深いコピー）とは？

deep copyは、**配列やオブジェクトの中身まで含めてすべて新しく複製すること**です。

2次元配列の場合、**各行（内側の配列）も新しいインスタンスにする必要があります**。

```ts
const current = [
  [0, 1],
  [1, 0]
];

// deep copy
const next = current.map(row => [...row]);
next[0][0] = 999;

console.log(current[0][0]); // 👉 0（元の配列は変わらない）
```

# 次元ごとの正しいコピー方法

### 1次元配列（array）

```ts
const arr = [1, 2, 3];
const copy = [...arr]; // OK
```

### 2次元配列（grid）

```ts
const grid = [
  [1, 2],
  [3, 4]
];
const copy = grid.map(row => [...row]); // ✅
```

### 3次元配列（cube）

```ts
const cube = [
  [
    [1, 2], 
    [3, 4]
  ],
  [
    [5, 6],
    [7, 8]
  ]
];
const copy = cube.map(matrix => matrix.map(row => [...row])); // ✅
```

📌 一般ルール（再掲）

> 多次元配列のコピーは、**次元の数だけ map（またはループ）をネストしてコピーする**のが基本です。

# 🛠 補足：再帰やライブラリを使う場合

もっと深い構造（ネストされたオブジェクトや配列の混在など）の場合は、以下のような方法が便利です。

**標準ブラウザAPIの `structuredClone`**

* ブラウザやNode.jsが提供する**ネイティブなdeep copy API**。
* パフォーマンスが非常に良く、**軽量で高速**。
* ただし、**コピーできない型**がある（例：関数、プロトタイプ、DOMノード、Mapのキーがオブジェクトなど）。

```ts
function deepCopy<T>(value: T): T {
  return structuredClone(value);
}
```

**ライブラリ依存の `lodash.cloneDeep`**

* JavaScriptのあらゆる型に対応しており、**堅牢性が高い**。
* ReactやVueなど、さまざまな環境で実績あり。
* ライブラリ依存なので、バンドルサイズが気になる場合は注意。
```ts
import cloneDeep from 'lodash.clonedeep';

const copy = cloneDeep({ a: 1, b: [1, 2, 3] });
```

# おわりに

* `next = [...current]` はshallow copy。ネストされた配列は**コピーされず、参照のまま**。
* 2次元以上の配列では `.map(row => [...row])` などで**深くコピー**する。
* 「コピーしたのに元のデータが壊れる」現象の多くはshallow copyが原因。

バグの原因が「コピー方法のミス」だった…という経験、ぜひあなたは回避してください！
未来を感じたNLWebを触ってみた

こんにちは。
クリエーションラインのKodakです。

Microsoft Build 2025で発表された **NLWeb** にとても未来を感じたので、さっそく触ってみました。

https://news.microsoft.com/source/features/company-news/introducing-nlweb-bringing-conversational-interfaces-directly-to-the-web/

https://github.com/microsoft/NLWeb

## NLWebとは？


**Natural Language Web（NLWeb）** の略で、Webサイト上に会話型インターフェースを簡単に構築できることを目的としたオープンソースプロジェクトです。  

「HTMLがWeb上で共有できるドキュメントとして標準化されたように、今度はAI Webの基盤を構築したい」  
――そんなミッションを掲げているようです。

たしかに、Web上でAIと自然に会話して、欲しい情報をすぐに取得できるようになれば、かなり便利になりますよね。

## 今までと未来

これまでのような「入力」「検索」「クリック」といった操作から、  
「会話するだけで情報が得られる」――そんな未来がやってくるのでは？と期待しています。

![now_and_future.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/241956/8c245fd3-d557-4218-a660-1b77e35e5c67.png)

また、先日Googleが発表した **Agent2Agent（A2A）** を組み合わせれば、  
AIエージェント同士がNLWeb上で会話し、最適な回答を導き出す ―― そんな世界も見えてきます。

![a2a_future.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/241956/4314a817-0e6b-4829-88f3-638568b49175.png)


## さっそくNL Webを触ってみる

ローカル環境でNLWebを動かしてみます。  
NLWebでは **ベクターデータベース** を使用するため、**Embedding用のモデル**が必要です。

2025年5月時点では、Azure、OpenAI、Gemini、Snowflake に対応しています。  
これらを使うのが良さそうです。（**AWS Bedrock** も早く対応してほしいですね）

```shell
git clone https://github.com/microsoft/NLWeb
cd NLWeb
```

`README.md` だと`venv`使っていますが、`poetry`の方が使い慣れているため、`poetry`を使いました。

```shell
cd code
poetry init
poetry add $( cat requirements.txt )
```

`.env`を作成し、使用するモデルのAPI_KEYを入れます。
私は、Embedding用のモデルも使えるOpenAIのAPI_KEYを設定しました。

```shell
cp .env.template .env
```


`code/config_embedding.yaml` ここで、Embedding用のモデルを選択します。

```yaml
# code/config_embedding.yaml

- preferred_provider: azure_openai
+ preferred_provider: openai
```

`code/config_llm.yaml` ここで会話用のモデルを選択します。

```yaml
# code/config_llm.yaml

- preferred_provider: azure_openai
+ preferred_provider: openai
```

`code/config_retrieval.yaml` ここでベクターDBを選択します。ローカルで動かしたいので、ローカルで動くQdrantを選択します。

```yaml
# code/config_retrieval.yaml

- preferred_endpoint: azure_ai_search
+ preferred_endpoint: qdrant_local
```

今回は、自分の はてなブログのRSS をデータとして投入しました。
tools.db_load の引数として <データのURL> と <サイト名> を指定します。
この <サイト名> は、データに対するラベルのようなもののようです。

現時点では、さまざまな種類のデータを柔軟に扱える設計にはなっていないようなので、今後のアップデートに期待ですね。

```shell
python -m tools.db_load https://kodak.hatenablog.com/rss kodak-rss
```

最後に起動してみます。

```shell
python app-file.py
```

`Ask` からAIとの会話が可能で、きちんと応答してくれました。

![kodak-nlweb.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/241956/6c991d39-1c9b-4b66-b5e7-a46e5f12be87.png)

## さいごに

- アーキテクチャや内部の仕組みなど、まだまだ分からないことだらけ
- 用語も難しく、深掘りしたくても言語化が難しいと感じた
- それでも「未来を感じる」と思っていただけた方には、以下の動画もおすすめです

https://www.youtube.com/watch?v=EF6uywH-Yzo

👋
運用監視オペレータが資格勉強2週間でAWSSAAに合格してみた。


# 運用監視オペレータが資格勉強2週間でAWSSAAに合格できた話。


はじめまして、ぎらくさと申します。

わたしは昨年度10月から昨日まで
都内のSES企業で運用監視オペレータとして従事していました。
(6月初旬に転職が決定しました:v:)

そんなわたしが
**AWS SAA（ソリューションアーキテクト アソシエイト)**
に実務未経験で挑戦し、2025年5月24日に合格できました。
(運用監視の仕事をしているものの、AWSの実務経験はゼロです。)

本記事では、

✅ **前置き**
✅ **おすすめの教材や勉強方法**
✅ **2週間で合格できた理由**
✅ **これから受験する方へのアドバイス**


この4点を記録として残したいと思います。
(正直、同じような記事はたくさんあるので需要はないかもしれませんが…笑）

# ✅前置き

そもそも今回AWS SAAを受験した理由は、
2025年1月15日にAWS CLF（クラウドプラクティショナー）に合格したことで
「**いずれはSAAも**」と考えていたからです。

しかしその後は、LinuCの資格勉強をしており、
4月17日にLinuC101に合格 → LinuC102の勉強をしていました。
結果、AWSに3か月ほど触れていない状態でした。

そんな中、5月にピアソンVUEの再試験無料キャンペーン（公式サイト）が発表され
「**一度試験難易度を知るチャンスだ！**」と考え受験を決めました。
正直、AWSのサービス名や概要をうっすら覚えている程度で、ほぼゼロからのスタート
だったので不安しかありませんでした。
(ちなみに、LinuC102はまだ取得できていません…笑)

ピアソンVUEの再試験無料キャンペーン
(https://www.pearsonvue.com/us/en/test-takers/free-retake.html) 

前置きはほどほどにして、本題に入ります。

# ✅おすすめの教材や勉強方法
結論から言います。

👉 **CloudTech (https://kws-cloud-tech.com/)**

正直**これ一択**だと思います。

**【CloudTechの料金例】**

**・資格会員：5,480円（90日間）**

**・基本会員：13,700円（90日間、自動更新）**

**・永久会員：54,800円（一括買い切り）**

**クーポンコード「CloudTech-KK」で安くなるようです！**
**割引後 👉 資格会員→4,980円、基本会員→12,450円、永久会員→49,800円**
※会員数は7,000名を突破しており、多くのAWS学習者に利用されています。

興味があれば本当にオススメなのでぜひ！
##

### 🎯 CloudTech(メイン教材)

私の勉強方法としましては2週間の間
空いた時間にひたすらCloudTechの資格演習対策コースを解き続けました。
解説が非常に丁寧で、実務未経験でも理解しやすい内容です。

理解できない部分は、何度も解説を視聴して
**過去問を本質的に理解してから繰り返し解く。**
このサイクルで、全体の理解がどんどん深まりました。

実際、試験で出題された内容の半分ほどはCloudTechでカバーされていたと感じます。
CloudTechだけでインプット・アウトプットが完結できるので、「**とにかく合格したい**」人はCloudTechのみで十分だと思います。

私の場合は全体を5周ほど回し、その頃には正答率が9割を超えていました。

結果として、試験は750点でギリギリ合格。
「**合格は無理かも…**」と思いながら勉強していたので、自分が一番驚いています笑

### 📚 書籍（サブ教材）
夜勤中の暇な時間を活用して、以下の書籍でAWSサービスの概要をインプットしました。

AWS認定 ソリューションアーキテクト 教科書（SAA-C03対応）
(https://amzn.asia/d/hW4w2Qp ）

この書籍は、試験範囲の全体像を掴むには良い教材ですが
**書籍のみで試験に合格するのは効率が悪い**と感じています。
あくまでサブ教材として利用するのがオススメです。

###  ⚠️ 勉強方法について

正直なところ、**本質的な理解には及んでいない部分**も多いです。
2週間の詰め込み勉強で得た知識は、試験をパスするための
**必要十分条件**にすぎないと感じています。
ただ、「**資格取得が目的**」ならそれで十分だと感じました。

### これからAWS SAAに挑戦する方の参考になれば幸いです:bow_tone1:

# ✅2週間で合格できた理由

勝手に思っていることですが、
これが自分が**合格できた最大の理由**だと思っています。

## ✏️資格はあくまで入り口であり、資格勉強は資格勉強だと割り切ること

勉強中は「**暗記しかしてなくて不安だな…本当にこれでいいのかな？**」と悩みましたが
結果としてはそれでよかったと思います。

なぜなら

👉 「**焦らず、じっくり技術習得に励む時間が後からできるから**」

今は資格勉強が終わったので、技術習得のためにハンズオンに励んでいます！
##

以前の私は、技術習得と資格勉強を並行して進めようとして、
「**本質的に理解しないと…！**」と時間をかけていました。
ですが今回は、「**技術の習得と資格勉強は別物**」だと割り切ったのです。
一つ一つの問題に時間をかけていてはあまりにも効率が悪いです。
もしも時間をかけず、平行して進めていけるのであれば、それが正解かもしれません。
自分には2週間では無理でした笑

もし今、資格取得と技術習得を同時にやっていて、
「**理解が追いつかない…嫌になってきた…**」という方がいたら、
この記事を見て「**こんなやつでも受かるんだし大丈夫だな**」
と思ってもらえたら嬉しいです笑

結局、**終わりよければ全てよし**です。
ただし、資格だけ取って満足してしまったら意味はないので、その点は気をつけましょう！
（なにがあっても責任は取れませんよ！笑）

# ✅これから受験する方へのアドバイス

とにかく、やるしかないです。
運用監視オペレータをしていたこともあり
口だけで何もしない人をたくさん見てきました。

一番大事なのは、

👉 「**行動し、継続すること**」

大変なのは百も承知。あとは**根性論**です。
上から目線っぽい文章に見えてしまったらすみません。
でも間違ってはいないと思っています。

✅ 結局はどこへ行っても**努力を継続**している人が残ります。
✅ でも心身ともにおかしくなってきたら**休むことも大事**です。

### 無理せず、継続していきましょう！

# ✏️ 最後に
長文になってしまいましたが、
「**資格はあくまでスタート地点！**」と考え、今後も技術習得に励みます。

これから**AWS SAA**に挑戦する方の参考になれば幸いです！
ここまで読んでいただきありがとうございました🙇‍♂️
IT技術ニュース要約 - 2025-05-30

# IT技術ニュース要約 - 2025-05-30

本日 2025-05-30 の IT 技術ニュースの要約をお届けします。

## 1. 世界で最もうるさいメカニカルキーボードが誕生
*出典: [GIGAZINE](https://gigazine.net/news/20250530-world-loudest-mechanical-keyboard/)*

GIGAZINEは、過去最高の大ヒットにも関わらず、価格高騰の影響でサーバー運営が危機的な状況に陥っており、読者からの支援を呼びかけている。わずか1円でも構わないので、寄付による支援を募っている。一方、自作キーボード愛好家のuwo's labさんが、リレーや爆竹などを用いた「世界一うるさいキーボード」を製作したと話題になっている。このキーボードは、タイピングに合わせて鉄板を叩くリニアアクチュエーターや、圧縮空気で動くタングドラム、さらに一定速度でタイピングすると発火する加熱コイルと爆竹を備え、けたたましい音を奏でる。その製作過程はTwitchで配信されており、アーカイブも閲覧可能だが、保存期間...

---

## 2. ピクルス11枚＆ビーフパティ3枚をコメでサンドしたバーガーキングの「ピックルボールバーガー」はコメのうまさを再確認できる逸品
*出典: [GIGAZINE](https://gigazine.net/news/20250530-burgerking-pickleball/)*

バーガーキングは、アメリカで人気のラケットスポーツ「ピックルボール」をプロモーションするため、「ピックルボールバーガー」を5月30日に発売した。このバーガーは、直火焼きビーフパティ3枚と、なんとピクルス11枚という、インパクトのある構成が特徴だ。従来のバンズの代わりに、特製ライスパティを使用している点がユニークである。大量のピクルスとビーフパティ、そしてライスパティという組み合わせから、その味は想像を超えるものと予想される。バーガーキングは、この斬新なバーガーで、ピックルボールの認知度向上と、ブランドイメージの刷新を狙っていると考えられる。

---

## 3. 空中で変形して飛行形態から陸上モードに移行できるロボット「ATMO」が登場
*出典: [GIGAZINE](https://gigazine.net/news/20250530-transforming-morphobot/)*

カリフォルニア工科大学の研究チームが、飛行と走行の両機能を備えた革新的な車両「空中変形モルフォボット（ATMO）」を開発しました。ATMOは、ドローンと同様の飛行能力を持ちながら、着陸後には車輪を展開し、地上を走行できる点が特徴です。この変形機能は、複雑な地形や障害物のある環境でも柔軟に対応することを可能にし、災害救助や捜索活動など、幅広い用途への応用が期待されています。小型で軽量な設計も実現しており、従来の飛行車両や地上車両では困難だったアクセス困難な場所への到達も容易になります。ATMOは、複数のモジュールから構成され、それぞれのモジュールが独立して動作することで、高い信頼性と柔軟性を確保...
【React】ボタンの二重送信を防止するシンプルな方法

皆さん、こんにちは。

今回は「【React】ボタンの二重送信を防止するシンプルな方法」について紹介させていただきます。

# はじめに

Reactでフォーム送信やAPIリクエストを伴うボタンを作るとき、**二重送信（ダブルクリック）**の対策はとても重要です。
対策をしないと、意図しない重複処理が走ってしまい、以下のような問題が起こる可能性があります。

重複した注文や登録

サーバーへの過剰リクエスト

ユーザー体験の低下

この記事では、Reactで二重送信を防ぐための基本的な実装パターンを紹介します。

# 実装例

以下のようなボタンを例に説明します。

## ✅ 基本的な二重送信防止方法（isLoadingフラグの活用）

```
import React, { useState } from "react";

const SubmitButton = () => {
  const [isLoading, setIsLoading] = useState(false);

  const handleClick = async () => {
    if (isLoading) return; // 二重送信を防止

    setIsLoading(true);
    try {
      // ここにAPI呼び出しなどの非同期処理を記述
      await new Promise((resolve) => setTimeout(resolve, 2000));
      alert("送信完了！");
    } catch (error) {
      console.error("エラー:", error);
    } finally {
      setIsLoading(false); // 処理が完了したら再びクリック可能に
    }
  };

  return (
    <button onClick={handleClick} disabled={isLoading}>
      {isLoading ? "送信中..." : "送信"}
    </button>
  );
};

export default SubmitButton;
```

## 解説ポイント

- isLoading という状態フラグを使って、「送信中」かどうかを判定しています。
- 送信処理中 (isLoading: true) はクリックイベントを無視。
- ボタンの disabled 属性を使ってUI上でも無効にしています。
- 処理が終わった後に isLoading を false に戻すことで、再度送信可能になります。

## 応用：トースト通知やローダー連携も可能

以下のようなライブラリと組み合わせると、よりユーザーフレンドリーな体験が作れます。

- react-toastify：成功・失敗時のトースト通知
- react-spinners：ローディングスピナーの表示

# まとめ

Reactで二重送信を防ぐには、isLoading のような状態フラグを活用するのが最も簡単で効果的な方法です。
実際のプロジェクトでも、このパターンは多用されているので、ぜひ取り入れてみてください！


ボタンクリック以外にも、フォームの onSubmit に対して同様のロジックを組み込むことも可能です。
状態管理ライブラリ（ReduxやRecoilなど）を使ってグローバルな送信状態を管理することもできます。

今日は以上です。

ありがとうございました。
よろしくお願いいたします。
【解決】【ピアソンVUEオンライン受験】 onvue ネットワークチェック60%での失敗について

お主、試験直前にシステムチェックのし忘れに気づき、OnVUE.exeをダウンロードしたものの60%のネットワークチェックエラーに引っかかり焦っておるのか？？

以下を実行するのじゃ！！！！！！！！！！


<h2>手順</h2>
設定　＞　プライバシーとセキュリティ　＞　Windowsセキュリティ　＞　ファイアウォールとネットワーク保護

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1946734/48140ae3-d79b-4fe7-8c40-226bd6a7be55.png)


ファイアウォールとネットワーク保護の詳細設定をクリック
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1946734/678d1f1d-76ed-490b-9f8f-2f43d8d0af39.png)


受信・送信の規則をクリック
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1946734/d9a5d1e1-6e51-4d57-82ea-0295a115ea31.png)


どちらの画面でも一つ項目を選択して、ctrl+Aで全選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1946734/28c475e4-eb58-425c-b1eb-791531ac0d7a.png)


画面右の削除を選択　＞　以下の画像のように削除のダイアログが表示　＞　「はい」を選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1946734/a59d798d-32ec-4ff1-8206-158be7fd5782.png)

受信・送信の規則ともに全て削除されたのを確認する


<hr>

<h2>
どうじゃ！！！！突破できたかのお？？

ここで一句

「試験前　ピアソン殺意　記事感謝」

みんなも元気に資格ゲットじゃぞお~（VC:某ーキド博士）
【z/OS】TSOとISPFの関係について簡単にまとめてみた

# はじめに
z/OSなどのメインフレームに接続する際に使用するTSOとISPFの関係についてまとめました。

# 目次
 - [TSOとは](#tsoとは)
 - [ISPFとは](#ispfとは)
 - [TSOコマンド](#tsoコマンド)
 - [ISPFコマンド](#ispfコマンド)
 - [ISPFの起動方法](#ispfの起動方法)
 - [TSO/Eとは](#tsoeとは)

# TSOとは
TSO (Time Sharing Option) とは、1971年にIBMによって導入された対話型のコマンドラインインターフェースです。メインフレーム環境で効率的に作業を行えるようにするために導入されました。
TSOコマンドといわれるコマンドを入力して、システムの操作やデータ管理をリアルタイムで行うことができます。
他にもジョブの送信や監視など、ジョブの管理も可能です。

# ISPFとは
ISPF (Interactive System Productivity Facility) は、1975年に導入された、対話型のユーザーインターフェースです。TSO上で動かすソフトウェアとして開発されました。
プログラムの編集やデータセット、ジョブの管理などを視覚的に簡単に行うことができます。
TSO上で動くので、使用するにはTSOのログインが先に必要です。

# TSOコマンド
TSOコマンドとは、TSOのコマンドライン上で入力できるコマンドのことです。標準で用意されているTSOコマンドは約40種類ありますが、それらのコマンドの多くはプログラムやデータセットの操作に関するもので、現在はISPF上で行われることが主流になっています。
なのでTSOコマンドを入力してシステムを操作することは最近は少なくなっています。
TSOコマンドは下記にまとめられています。
- [TSO/E コマンドの要約](https://www.ibm.com/docs/ja/zos/2.5.0?topic=subcommands-summary-tsoe-commands)

# ISPFコマンド
ISPFコマンドとは、ISPF上で入力できるコマンドのことです。プログラムの実行やデータセットの操作などを行う際に使用されます。
- [ISPF 基本コマンド](https://www.ibm.com/docs/ja/zos/3.1.0?topic=commands-ispf-primary)

# ISPFの起動方法
TSOにログインすると、通常はTSOコマンドが入力できるコマンドラインの画面に遷移します。
※画面に「READY」と表示され、TSOコマンドの入力待ちの状態になります。 (READYプロンプトと呼ばれます)
そこで「ISPF」と入力すると、ISPFが起動されます。
ただ最近は、TSOにログインするとTSOのコマンドライン画面を表示せずにすぐにISPFを起動したり、ISPFを終了したらTSOもログアウトするようなカスタマイズを行った状態で運用されている企業もあります。
その場合は、TSOのコマンドライン画面を見ずにISPFの画面が表示される挙動になります。

:::note
TSOにログインすると直接ISPFが起動するようにカスタマイズされていても、TSOコマンドは入力できます。ISPFのメニューから「6. コマンド」を選択すると、TSOコマンドが入力できる画面に遷移します。
:::

# TSO/Eとは
TSO/E (Time Sharing Option/Extensions) はTSOがリリースされた後、TSOの機能拡張版としてリリースされたものです。TSOは元々英語版だけでしたが、TSO/Eでは日本語を含む複数の言語をサポートしています。なので現在はTSO/Eが一般的に広く利用されています。

# 参考
- [11.TSOとISPF](https://arteceed.squares.net/?p=169)
- [TSOにログオンする](https://arteceed.squares.net/?p=1464)
関数型プログラミングの利点

## 関数型プログラミングの利点と、私の設計哲学

関数型プログラミングは、私が個人的に好んで取り入れているスタイルです。この投稿は「関数型がオブジェクト指向より優れている」と主張するものではありません。私がなぜ関数型の考え方を好み、実際の開発にどう活かしているかを共有することが目的です。

---

### 表現方法か、物の見方か？

関数型とオブジェクト指向は、しばしば対立する設計思想のように語られますが、私は同じ問題を別の視点から表現しているにすぎないと考えています。
どちらが「正しい」というより、抽象化の手法や構造のアプローチに違いがあるという理解の方が本質的です。

プログラミングは、現実の問題をコンピュータで処理可能な形にモデル化する作業です。オブジェクト指向は「物とその役割」に焦点を当てるのに対し、関数型は「データの流れと状態の変換」に注目します。

私は、データを中心に流れを明確にする関数型の設計の方が、直感的でメンテナンス性が高いと感じています。

---

### TypeScriptで関数型コードを書くときの構成
TypeScriptで関数型アプローチを実践する際、私が重視しているのは **「データ」「計算」「副作用」の明確な分離**です。
以下のようなファイル構成にすることで、関心の分離が実現できます：

- `model.ts`: ドメインモデル、型定義
- `parser.ts`: 入力値の検証と変換（Validation / Parsing）
- `service.ts`: 純粋な計算ロジック
- `effect.ts`: API呼び出しやファイルI/Oなどの副作用
- `main.ts`: 実行エントリーポイント

例えば、以下のような面積を計算するコードがあったとします：

```typescript
// model.ts
type Square = {
  width: number;
  height: number;
};

// service.ts
const getArea = (square: Square): number => square.width * square.height;
```

```typescript
// parser.ts
const parseSquare = (input: any): Square | null => {
  if (typeof input.width === 'number' && typeof input.height === 'number') {
    return { width: input.width, height: input.height };
  }
  return null;
};
```

このように、それぞれの機能が**小さな純粋関数として分離**されていて、**依存関係がほとんどない**というのがポイントです。これは変更の影響範囲を局所化できるため、テストや再利用、保守がしやすくなります。

---

### オブジェクト指向 vs 関数型：思考スタイルの違い

オブジェクト指向は、`class`や`method`を中心にコードを構成し、「状態と動作」をひとまとまりにします。一方で関数型は、データを不変（immutable）とし、入力を受けて出力を返す**純粋関数**の組み合わせで処理を構築します。

これは**プログラミングの思考様式そのものにも影響**を与えます。  
オブジェクト指向は「このモノは何ができるか？」に焦点を当て、関数型は「このデータはどう流れ、どう変換されるか？」に注目します。

どちらが適しているかは、問題の性質によって異なります。関数型は、**データの流れや処理の組み合わせが重要な問題**に特に強みを発揮します。

---

### クロージャとインターフェースで構築するオブジェクト

関数型のスタイルでも、オブジェクト的な構造は作成可能です。`class`を使うのではなく、**クロージャとインターフェースの組み合わせ**で同様の構造を実現します。

```typescript
const createSquare = (width: number, height: number) => {
  return {
    getArea: () => width * height,
    getWidth: () => width,
    getHeight: () => height,
  };
};

const square = createSquare(10, 20);
console.log(square.getArea()); // 200
```

このように、`width`や`height`は外部から直接変更できず、 **情報隠蔽（encapsulation）** が自然に実現できます。テストもしやすく、状態の一貫性も保てます。

※このような構成は「Functional OOP」とも呼ばれ、関数型とオブジェクト指向の融合的アプローチです。


---

### パフォーマンスと関数型のトレードオフ

関数型プログラミングでは、不変データや関数合成、メソッドチェーンなどが頻繁に使われます。その結果、**一時オブジェクトの生成が増え、メモリ使用量が多くなりがち**です。

また、**GC負荷の増加やパフォーマンスへの影響**も考慮する必要があります。

ただし、これらは以下のような工夫によって緩和できます：

- `generator` による遅延評価（JSはデフォルトでは eager）  
- `memoization` による計算結果のキャッシュ  
- 必要最小限のデータ構造設計

また、状態を持つクロージャは軽量ですが、**リアルタイム性やリソース制限が厳しい環境では慎重に設計すべき**です。

---

### 私の開発哲学と関数型アプローチ

私の開発スタイルでは、まず問題を明確にし、要件や制約（法的条件、API仕様など）を整理した上で、**それらを最小限の構成要素に分解**します。

この際、**純粋関数を中心に構成する関数型の設計**は、以下の点で特に効果を発揮します：

- データの流れが明確になる  
- テストしやすくなる  
- インターフェース設計がシンプルになる  
- チーム開発でも読みやすく保守しやすいコードが書ける  

実装時には、以下の観点でコードを分割することを意識しています：

- **入力**: どのようなデータが与えられるか  
- **処理**: どのような純粋計算が行われるか  
- **出力**: 外部との連携（副作用）をどのように制御するか

このような設計方針は関数型の考え方と非常に親和性が高く、**一度慣れると、予測可能かつ堅牢なシステム設計が可能**になります。

---

## 結論

関数型プログラミングは、一時的な流行ではなく、**現実の複雑な問題を明快に構造化するための有効な視点**です。オブジェクト指向と同様、決して万能ではありませんが、適切に使えば非常に強力なツールになります。

私自身、このアプローチによって問題分析から実装までの一貫したスタイルを持てるようになりました。今後もこの哲学を軸に、より良いソフトウェアを作っていきたいと思います。
Rangeオブジェクト ー exclusiveとinclusive

一つ前に書いた[`times`メソットについての記事](https://qiita.com/KoSaxophone/items/5793b9da7452afd6ba4c)の中で、Range（範囲オブジェクト）に触れていたので、備忘録的にここにまとめておこうと思う。皆様、どうかお付き合いください。🙇


## 範囲オブジェクトとは
- 連続した値の集合を表すRuby標準クラスのこと

## 排他的範囲`(...)`とは
- 開始値を含み、終了値を含まない範囲を表すこと  
- 数値だけでなく、文字やオブジェクトにも適用可能なこと  
- 記法: `(a...b)`  　👈 a ≤ x < b

## 包括的範囲`(..)`とは
- 開始値を含み、終了値も含む範囲を表すこと  
- 数値だけでなく、文字やオブジェクトにも適用可能なこと  
- 記法: `(a..b)`  　👈 a ≤ x ≤ b

## 具体例①：配列のインデックス指定
```ruby
array = %w[a b c d e f g]

p array[0...5]  # => ["a", "b", "c", "d", "e"]
p array[0..5]   # => ["a", "b", "c", "d", "e", "f"]
```
## 具体例②：eachメソッドによる繰り返し
- 排他的範囲
```ruby
(1...5).each do |i|
  puts i
end
# 実行結果:
# 1
# 2
# 3
# 4
```
- 包括的範囲
```ruby
(1..5).each do |i|
  puts i
end
# 実行結果:
# 1
# 2
# 3
# 4
# 5
```
---
## 俺の覚え方
- ３アウトチェンジ＝終端排他

---
## まとめてみて
- `times` メソッドは包括的範囲のRangeを使って書くようにしたい。
```ruby
5.times do |i|
```
これよりも
```ruby
(0..4).each do |i|
```
こっちの方が見やすいし、`times` メソッドは「０スタートのn-1終わり」とか覚えてられなそう・・・
【z/OS】データ管理に関するワードをまとめてみた

# はじめに
z/OSにおけるデータ管理に関するワードについて、簡単にまとめてみました。

# 目次
- [データセット](#データセット)
- [ブロック](#ブロック)
- [レコード](#レコード)
- [順次データセット](#順次データセット)
- [区分データセット](#区分データセット)
- [区分データセット/拡張](#区分データセット拡張)
- [データセット名の構成](#データセット名の構成)
- [文字制限](#文字制限)

# データセット
データセットは、z/OS上でデータを格納するための基本単位になります。Windowsのファイルシステムでいえば、ファイルに該当します。
z/OS上でデータを保存するためには、データセットを使用することが一般的です。
例えばCOBOLやPL/I、アセンブリ言語などのプログラムのソースコードやバイナリファイル、JOBやJCLもデータセットに保存されます。
また、JOBが出力するログもデータセットに保存されることが一般的です。
そのほか、[VSAM](https://ja.wikipedia.org/wiki/Virtual_Storage_Access_Method)やDB2などのデータベースファイルもデータセットに保存されます。
データセットは後述する複数のブロックで構成されています。

# ブロック
ディスクやテープに記録される際の単位です。後述のレコードを複数まとめたものになります。
ブロックという単位で記録することで、ディスクやテープへのI/O処理の回数を減らすことができ、効率的にI/O処理を行うことが出来ます。
ブロックサイズはディスクやテープの物理的な特性によって決める形になります。
### 参考
- [ブロックサイズ（BLKSIZE）](https://arteceed.squares.net/?p=1197)

# レコード
データセットの中にある個々のデータの単位です。データセットを構成している要素の最小単位になります。
Windowsのファイルシステムでいえば、ファイル内の各行のようなイメージです。
レコードの形式や長さはデータセットの種類や用途によって異なります。
レコードはさらにフィールドと呼ばれるものにに細分化されますが、これにはz/OS側は関与しておらず、あくまでプログラム側の処理によって行われています。

:::note
- レコードは論理レコード、ブロックは物理レコードとも呼ばれます。
- 初期のコンピュータでは、データの入力や出力はパンチカードを使用していました。パンチカードのデータは順次データセットとして扱われており、これがのちのファイルシステムの基礎になりました。
z/OSのファイルシステムはレコードベースのデータ構成を採用しており、これはパンチカードのデータ処理方法から進化したものです。
:::

# 順次データセット
データセットの種類のひとつです。レコードが順番に格納されている構成になっています。各レコードは連続して配置されています。
主にテキストファイルやログファイルなど、シンプルなデータの格納やバッチ処理に使用されます。
SDS (Sequential Data Set) とも呼ばれます。

# 区分データセット
データセットの種類のひとつです。複数のメンバー (サブデータセット) によって構成されています。
各メンバーは独立したデータとなっており、メンバー単位でアクセスして編集や削除が可能です。
主にプログラムコードやJCLスクリプト、設定ファイルの集まりなどに使用され、複雑なデータやプログラムの管理に適しています。
PDS (Partitioned Data Set) とも呼ばれます。

:::note
- 順次データセットは連続してレコードが配置されているため順次アクセスですが、区分データセットはランダムアクセスになります。
- ISPF上では順次データセットと区分データセット、どちらも検索できます。
:::

# 区分データセット/拡張
区分データセットの機能を拡張したものです。
ディレクトリ管理やメンバー作成などの機能をより便利に拡張されたものになります。
PDSE (Partitioned Data Set/Extensions) と呼ばれます。

:::note
区分データセットやその拡張版であるPDSEは、「ライブラリ」とも呼ばれます。
:::

# データセット名の構成
データセット名の構成についてです。
データセット名は基本的に「プロジェクト名.グループ名.タイプ名」になります。

### プロジェクト
データセットの最初の部分です。プロジェクトの名前やユーザーIDを指定するとわかりやすいです。

### グループ
データセットの中間部分です。データのカテゴリやサブプロジェクトの名前を指定するとわかりやすいです。

### タイプ
データセットの最後の部分です。データの詳しい種類や用途を指定するとわかりやすいです。

### 例
例えばデータセット名が「HOGE.FUGA.PIYO」だと、
HOGEがプロジェクト、FUGAがグループ、PIYOがタイプになります。

また、グループ名のみ複数のセグメントを使用できます。
なので例えば「HOGE.FUGA.PIYO.TEST1.TEST2」という名前のデータセット名があった場合、
分解するとプロジェクト名は「HOGE」、グループ名は「FUGA.PIYO.TEST1」、タイプ名は「TEST2」になります。

:::note
これらはISPFでデータセットを検索する際に指定して検索することができます。
また、ISPFで「１. 表示」を押すとデータセットを検索できる画面に遷移し「ISPFライブラリー」という言葉が表示されますが、「ISPFライブラリー」はISPF環境で使用されるライブラリのことを指し、普通のライブラリと同じ概念です。
:::

# 文字制限
z/OSのデータセット名は最大44文字までというルールで制限されています。また、それぞれのセグメントには最大8文字の制限があります。

# 終わりに
まだ沢山他のワードもあるので、また追記していく予定です。
実務初年度はじめての製造・テストフェーズについて

# はじめに
月1投稿をなんとか続けています！今月も月末ギリギリです…😅
今回ははじめての製造・テストフェーズでした。（まだ途中ですが）
ほんとに右も左もわからず、調べながら進めていく感じだったので、
同じような方の参考になれば幸いです。

# これまで経験したこと
12月に初めての現場に入り、5月末で半年が経過しました。
半年で行ったことは以下です！

・12~3月末まで詳細設計書の修正対応
・4月で単体テスト仕様書作成と実施
・5月で受入テスト仕様書の作成

# 苦戦したこと
①コーディング：Javaバッチのデバッグ環境構築
②単体テスト　：そもそも単体テストってどうやるの？
③テスト仕様書：見やすい書き方を探すの難しい！

## ①コーディング：Javaバッチのデバッグ環境構築
今までの個人開発ではオンラインのデバッグしかやってこなかったので、
画面がないことにものすごく狼狽えました笑
「どどど、どうやってデバッグするんだ…？」ってなってました。
しかも連携された手順書が古く、内容が間違っておりなかなか進められずで大変でした。

### ・今回Javaバッチを実行するために重要だったこと！
そのバッチプログラムがどのように実行されて、何を出力するのか。

結果：バッチプログラムはシェルで実行していた。
（具体的にはシェルでDB情報を加工し入力ファイルを作成、Javaバッチプログラムに渡す）
　　↓
対応：シェルを解読し、必要な入出力ファイルやログファイルをローカルに用意
　　　そのパスを実行するときに渡してあげればOK

## ②単体テスト：そもそも単体テストってどうやるの？
基本情報で勉強したから名前は知ってるけど、、具体的に何したらいいの？
となったのでまずしたこと。「テストの流れなどを理解する」
↓この動画がめっちゃくちゃわかりやすいのでおすすめです！！！

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

あとはいろんな記事とかひたすら調べて読み込んでいく！

https://pm-rasinban.com/unit-test

https://qiita.com/nittannittan/items/2d8a342a8d77db53b70a#%E3%83%90%E3%83%83%E3%83%81%E6%A9%9F%E8%83%BD%E8%A6%B3%E7%82%B9

https://qiita.com/mutou__945/items/dae2cee8bb7b04360cb0

### ・今回単体テストケースを作成するために重要だったこと！
担当機能で必要なのはどういう観点か？どこが修正されたのか？を理解すること

例：今回はDBを更新するような機能じゃないな、条件分岐のルートが変わったんだな
　　　↓
結果：更新や削除のテストケースは不要！
　　　条件分岐が想定通りのルートになっているか、既存処理に影響はないか確認だな！

## ③テスト仕様書：見やすい書き方を探すの難しい！
先に作成された仕様書を参考に、いざ作成…！
って書き方むずすぎー！わかりにくすぎー！となりました。

「〜且つ、」「〜の場合、」のオンパレードで条件分岐がわかりづらい…
ということで、先輩に教えてもらったのがマトリックス図です（こういうやつ）↓

![スクリーンショット 2025-05-30 21.21.10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3782860/5aadb0af-df63-4a25-9cec-3aeadf41d1e3.png)

この画像は、下記サイトから引っ張ってきました。
わかりやすかったのでぜひ読んでみてください！

https://www.purin-it.com/test-case-matrix-search-normal

# さいごに
まだまだ途中段階なので、今の現場を完走できるように頑張ります🏃‍♂️💨
WSL2 の Ubuntu の起動を速くする (不要サービスを止める)

インストール直後の状態。

```powershell:
wsl.exe --install Ubuntu --name ubuntu-orig1
wsl.exe -t ubuntu-orig1
wsl.exe -d ubuntu-orig1
systemd-analyze plot > Desktop/ubuntu-orig1.svg
```

以下、全体。1.36秒かかってる。

![ubuntu-orig1.svg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/22754/23a5b73c-468e-4dc0-8c30-650370dd762c.png)

ubuntu-orig1.svg で、特に遅い部分

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/22754/e6fe47dd-0d66-487f-be1b-ac9096b3e93f.png)

* `landscape-client.service` : Canonical 提供のコンピュータの管理・監視ツール「[Landscape](https://ubuntu.com/landscape)」のクライアント。使わなければ不要。
* `snapd.service` : Snap パッケージの管理 daemon。Snapパッケージを使わなければ不要。
* `snapd.seeded.service` : snapd(snapd.service) のセットアップ状態を確認する OneShot サービス。Snapパッケージを使わなければ不要。
* `wsl-pro.service` : WSL上で Ubuntu Pro 機能を利用するためのサービス。ESM（Extended Security Maintenance）やLivepatchといった Ubuntu Pro 機能を使わなければ不要。

不要なサービスは `disable` で起動時に無効化しておけばよい。

```shell
sudo systemctl disable --now **.service
```

`landscape-client.service` `snapd.service` `snapd.seeded.service` の３サービスを止めた後の状態。0.77秒（▲0.59秒）

![_C__Users_ma2sh_Desktop_ubuntu-orig2.svg(iPad Pro).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/22754/69561941-ada7-483a-a0ba-464443835143.png)

EoT
PrismaでViewを扱う

## はじめに
Prismaを使っていると少し複雑な検索を行う時、生のSQLを使用してViewを作成することがありますが、型安全ではなかったりちょっと不便です。

ちょっといい感じの方法があったのでメモします。

## 参考
https://qiita.com/show-ei/items/572e7b872c37e1d92aec

https://www.prisma.io/docs/orm/prisma-schema/data-model/views



## 前提条件・環境

- Prisma 4.16.0以上
- PostgreSQL（本記事の例）
- TypeScript環境

## サンプルスキーマ

対象のテーブルはこんな感じ

```prisma
// schema.prisma
model User {
  id      Int      @id @default(autoincrement())
  email   String   @unique
  name    String?
  profile Profile?
}

model Profile {
  id     Int    @id @default(autoincrement())
  bio    String
  avatar String?
  user   User   @relation(fields: [userId], references: [id])
  userId Int    @unique
}
```

## 実装手順

### 1. Preview機能の有効化

`schema.prisma`のgeneratorブロックにpreviewFeatures = ["views"]を追加します

```prisma
generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["views"]
}
```

### 2. SQLビューの作成

データベースに直接SQLを実行してViewを作成します。

```sql
CREATE VIEW user_info_view AS
SELECT 
  gen_random_uuid() AS id,
  u.id AS user_id,
  u.email,
  u.name,
  p.bio,
  p.avatar,
  CASE 
    WHEN p.id IS NOT NULL THEN true 
    ELSE false 
  END AS has_profile
FROM "User" u
LEFT JOIN "Profile" p ON u.id = p."userId"
ORDER BY u.id;
```


### 3. スキーマ定義の取得

以下のコマンドを実行して、データベースからスキーマ定義を取得します

```bash
npx prisma db pull
```

`schema.prisma`に以下のような定義が自動追加されます：

```prisma
view user_info_view {
  id         String? @db.Uuid
  userId     Int?
  email      String?
  name       String?
  bio        String?
  avatar     String?
  hasProfile Boolean?
  
  @@ignore
}
```

### 4. スキーマ定義の修正

自動生成された定義をPrisma Clientで使用できるように修正します。

```diff_scheme
view user_info_view {
-  id         String? @db.Uuid
+  id         String  @id @default(uuid()) @db.Uuid
  userId     Int?
  email      String?
  name       String?
  bio        String?
  avatar     String?
  hasProfile Boolean?
}
```


### 5. マイグレーションファイルの作成

空のマイグレーションファイルを作成します

```bash
npx prisma migrate dev --create-only --name add_user_info_view
```

生成されたマイグレーションファイルに、Step 2で使用したSQL文を記述します。

```sql
-- CreateView
CREATE VIEW user_info_view AS
SELECT 
  gen_random_uuid() AS id,
  u.id AS user_id,
  u.email,
  u.name,
  p.bio,
  p.avatar,
  CASE 
    WHEN p.id IS NOT NULL THEN true 
    ELSE false 
  END AS has_profile
FROM "User" u
LEFT JOIN "Profile" p ON u.id = p."userId"
ORDER BY u.id;
```

## 動作確認

以下のコマンドを実行して、エラーが発生しないことを確認します。

```bash
npx prisma migrate dev
npx prisma generate
```

新たにマイグレーションファイルが作成されなければ、セットアップは正常に完了しています。

## 使用例

型安全にビューを操作できるようになります。

```typescript
import { PrismaClient } from '@prisma/client';

const prisma = new PrismaClient();

// 全ユーザー情報を取得
const allUsers = await prisma.user_info_view.findMany();

// プロフィールがあるユーザーのみ取得
const usersWithProfile = await prisma.user_info_view.findMany({
  where: {
    hasProfile: true
  }
});

// 特定のユーザーを検索
const userByEmail = await prisma.user_info_view.findFirst({
  where: {
    email: 'user@example.com'
  }
});

// 型安全性の恩恵
usersWithProfile.forEach(user => {
  console.log(user.email); // TypeScriptの型推論が効く
  console.log(user.bio);   // string | null として推論される
});
```



## まとめ

もうちょっとスマートな方法ありそうだなぁとも思います。