OmniAICreator/Qiita-1.07M huggingface dataset:
[React]Viteを用いたReactアプリの作成手順

# はじめに
Reactアプリケーションの起動時の手順やブラウザ表示までのおおまかな流れを備忘録としてまとめます。

# アプリケーションの作成方法
### 1. アプリの作成
Viteを使ってアプリケーションの雛形を作成。

```terminal
npm create vite@latest アプリケーション名
```

コマンド実行をすると、以下のような構成のフォルダが作成される。

```
my-vite-app/         # プロジェクトのルートディレクトリ
├── node_modules/
├── public/
│   └── vite.svg
├── src/
│   ├── assets/
│   │   └── react.svg
│   ├── App.css
│   ├── App.jsx
│   ├── index.css
│   └── main.jsx
├── .gitignore
├── index.html
├── package.json
├── README.md
├── vite.config.js
└── jsconfig.json（TypeScriptで作った場合は tsconfig.json）

```
#### 各ファイル・ディレクトリの説明
- public/
静的ファイルを置く場所(例: favicon, 画像, アイコン など)

- src/
ソースコード一式を格納するフォルダ。

|ファイル名|内容|
|---|---|
|main.jsx|アプリのエントリーポイント。ReactDOMでAppをレンダリング。|
|App.jsx|メインコンポーネント。初期状態では簡単なUIが表示される。|
|index.css|グローバルCSS。|
|App.css|App.jsxに対応するCSS。|
assets/|アイコンや画像ファイルなど静的アセット。|

- プロジェクトルート
 
|ファイル名|内容|
|---|---|
|index.html|ルートHTMLファイル。Viteはこれを基にビルド。|
|package.json|依存パッケージやスクリプトの管理。|
|vite.config.js|Viteの設定ファイル（ポート、エイリアス、プラグインなどを定義可能）。|
|.gitignore|Gitで無視するファイル。|
|README.md|初期README。|
|tsconfig.json|Typescript用設定ファイル（パスエイリアスなどの指定用）。|

### 2. アプリケーションの起動
`npm run dev`コマンドでアプリケーション起動が可能。
```terminal
npm run dev
```
`localhost:5173`にアクセスして以下のような画面表示がされれば成功。
![スクリーンショット 2025-06-16 12.18.34.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1693405/7d077b64-5306-4c63-ac7b-827ddf0b75bc.png)


## ブラウザに表示されるまでの流れ

1. ユーザーがlocalhost:5713にアクセスする。

2. Vite開発サーバが起動をして、`index.html`ファイルを返す。

3. index.htmlファイル内の以下の記述をブラウザが読み込む。
```ts:index.html
<script type="module" src="/src/main.tsx"></script>
```

4\.Viteが main.tsx を検出し、`esbuild`を使ってトランスパイル（TSX → JS）
```ts:
import { StrictMode } from 'react'
import { createRoot } from 'react-dom/client'
import './index.css'
import App from './App.tsx'

// id="root"を持つ要素に<App />コンポーネントを描写するという記述
createRoot(document.getElementById('root')!).render(
  <StrictMode>
    <App />
  </StrictMode>,
)
```

5\. main.tsx 内の import に応じて他の `.tsx` や `.ts` ファイルを個別に変換・提供

6\. ブラウザが変更後のJSコードを読み取って、Reactアプリが描写される。

## 補足：トランスパイルとバンドル
### トランスパイラーとは？
ブラウザではJSXやTypescriptのコードをそのまま実行できないため、利用可能なJavascriptの形式に変換しておく必要がある。この「ある言語で書かれたコードを別の言語に変換する作業」を`トランスパイル`という。

### バンドルとは？
複数のファイルやコードをブラウザで動くように1つにまとめること。
複数のモジュールを1つずつ読み込んでいくのは非効率であるため、1つの使える形にまとめて効率的にブラウザで読み込めるようにファイルをまとめておくと便利。
このバンドル作業を担ってくれるのが`バンドラー`と呼ばれるツール。

### esbuildとは？
一言で言うと「JSXやTypeScriptのコードを、ブラウザで使える形に高速で変換してくれるトランスパイラー」のこと。

esbuildはJavascript/TypeScriptコードを変換（トランスパイル）するツールで、他のツールよりも処理が高速。かつ、複数のファイルを1つにまとめてくれる`バンドル`も行うことができる。


## DOMとは？
[DOM(ドキュメントオブジェクトモデル)](https://developer.mozilla.org/ja/docs/Web/API/Document_Object_Model/Introduction)は、Web上の文書のコンテンツと構成からなるオブジェクトのデータのこと。

WebページはHTMLの集まりでできており、そのHTMLをツリー状に表現したものをDOMという。

見出しや段落、画像、ボタンなどはDOMのノード(枝や葉っぱ)のように部品として扱われる。

JavascriptではこのDOMを操作して、見た目を変えたり内容をhんかさせたりできる。

### 仮想DOMとは？
Javascriptでページの要素を変える場合、実際のDOMに対して直接手を加えるが、この操作はとても重たい作業。

Reactでは高速に変更を加えるために、仮想DOMというメモリの軽いコピーを操作して、仮想DOMが変化した場合に差分だけ抽出する。抽出した差分のみ本番のDOMに変更することで、無駄な更新が減り画面をスムーズに動かすことができる。
Streamlit Community Cloudアカウント開設＆GitHub連携【画像付き】

# 1. Streamlit Community Cloudへアクセス
[SCCのトップページ](https://streamlit.io/cloud)にアクセスし、「Continue to sign-in」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4112242/fe91f2f8-3ddd-4658-8dcb-f716d8e6b120.png)

# 2. 「Continue with GitHub」を選択
Streamlitアプリは**GitHub**にアップロードしたものをデプロイする形となるため、
**アプリが保存されているGitHubアカウント**と連携します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4112242/c0201364-8d33-4b0a-a952-0822f334a50a.png)

# 3. GitHub連携の権限を許可
画面の指示に従い、必要な権限を付与します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4112242/485c891c-f4cb-4a25-8863-a11e2ac1fc1c.png)

# 4. 必要事項を入力してアカウント作成
引き続き指示に沿ってプロフィールなどを記入します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4112242/c2dbca67-1ccc-4aad-afe0-9bbb3b8ba591.png)

# 5. アカウント連携の詳細設定変更（Settingsから）
ホーム画面右上のアイコンをクリックし、「Settings」へ移動します。

::: note alert
プライベートリポジトリをSCCと連携したくない場合は、この手順以降はスキップしてOKです。
この時点でパブリックリポジトリのデプロイは可能です。
ここでアカウント作成は完了です👍
:::
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4112242/7607b1a6-f7f6-44b2-b016-7699a9a08532.png)

# 6. 赤枠の「Connect here→」を選択
Settings内の **「Linked accounts」タブ** にある「Private access」項目の
赤枠「Connect here→」をクリックします。
これにより、GitHub上のプライベートリポジトリにもSCCからアクセスできるようになり、
プライベートリポジトリのアプリもデプロイ可能となります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4112242/89f46ec2-2383-4890-8e01-1f7e39cb7fc9.png)

# 7. 再度権限の許可
表示される画面の案内に沿って、権限付与の手続きを行ってください。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4112242/26405858-91cf-48fe-a90b-c5a50733d3cd.png)

# これで準備は完了です！👍
ここまでで、SCCとGitHubアカウントの連携が完了しました。
これ以降は、公開したいアプリのリポジトリを指定してSCC上でデプロイ設定を行うだけです。

# 最後に
Streamlit Community Cloudを使えば、GitHubリポジトリ上のStreamlitアプリを手軽にWeb公開できます。
記事内容で不明点や誤りなどありましたら、ぜひコメントでご指摘・ご質問ください！
プロンプトエンジニアリングの落とし穴：情報配置の順序が生成結果に与える影響

# はじめに

プロンプトエンジニアリングにおいて「大事な情報ほど先に書く」という原則をよく耳にします。しかし、実際には「前の情報を忘れる」という相反する現象も存在します。

本記事では、この一見矛盾する2つの現象について、LLMの特性を踏まえながら、効果的な情報配置の戦略を解説します。

# プロンプトにおける情報配置の重要性

## なぜ「大事な情報を先に書く」のか

### 1. 注意力の減衰
AIモデルは長いプロンプトを処理する際、後半の情報よりも前半の情報により強く影響を受ける傾向があります。特に複雑なタスクや長いコンテキストでは、重要な指示を最初に配置することで、より確実に従ってもらえます。

### 2. コンテキストウィンドウの制約
モデルのコンテキストウィンドウには限界があり、非常に長いプロンプトでは後半の情報が十分に考慮されない可能性があります。

### 3. タスクの枠組み設定
最初に主要な目的や制約を明示することで、AIがプロンプト全体を解釈する際の枠組みが設定されます。

## 実例：良い例と悪い例

```
❌ 悪い例：
「昨日、私たちのチームでは新しいプロジェクトについて議論しました。
参加者はAさん、Bさん、Cさんで、会議は2時間続きました。
様々な意見が出ましたが、最終的に3つの重要な決定事項がありました。
これを簡潔に3点でまとめてください。」

✅ 良い例：
「以下の会議内容を3点で簡潔にまとめてください。
昨日、私たちのチームでは新しいプロジェクトについて議論しました。
参加者はAさん、Bさん、Cさんで、会議は2時間続きました。
様々な意見が出ましたが、最終的に3つの重要な決定事項がありました。」
```

# 「前の情報を忘れる」現象との矛盾

## 系列位置効果（Serial Position Effect）

実は、LLMには以下の2つの効果が同時に作用しています：

- **プライマシー効果**：最初の情報が強く記憶される
- **リーセンシー効果**：最後の情報も比較的よく記憶される

つまり、**中間部分の情報が最も忘れられやすい**という特性があります。

## なぜこの現象が起きるのか

1. **注意機構の特性**：TransformerベースのLLMは、位置エンコーディングと注意機構により、特定の位置の情報により強く注目する傾向があります。

2. **タスクコンテキストと即時コンテキスト**：
   - 最初の情報：タスク全体の方向性を決定
   - 最後の情報：直接的な応答生成に影響

# 効果的な情報配置戦略

## 1. サンドイッチ構造

重要な情報を最初と最後の両方に配置します。

```
【主要な指示】3つのポイントで要約してください

【詳細な内容】
...（長い説明）...

【リマインダー】上記を3つの主要ポイントにまとめてください。
```

## 2. 構造化による可視性向上

```
### タスク
- 要約を作成
- 3つのポイントに限定
- 各ポイントは1-2文で表現

### 背景情報
...（内容）...

### 出力形式
1. ポイント1：
2. ポイント2：
3. ポイント3：
```

## 3. 重要度に応じた反復

クリティカルな制約は、異なる表現で複数回言及します。

```
「技術的な専門用語は使わずに説明してください。」

...（内容）...

「なお、説明は一般の方にも理解できるよう、専門用語を避けてください。」
```

# 実践的なガイドライン

## プロンプトの長さ別戦略

### 短いプロンプト（～500文字）
- 重要な指示を最初に配置
- シンプルで明確な構造

### 中程度のプロンプト（500～2000文字）
- サンドイッチ構造を採用
- 見出しや番号付けで構造化

### 長いプロンプト（2000文字～）
- 重要情報を3箇所（最初・中間・最後）に配置
- 明確なセクション分けを使用
- 各セクションの冒頭に要約を配置

## タスク別の最適化

### 創造的なタスク
```
1. 制約条件を最初に明示
2. インスピレーション素材を中間に
3. 期待する出力形式を最後に
```

### 分析的なタスク
```
1. 分析の観点を最初に定義
2. データや情報を中間に配置
3. 求める結論の形式を最後に指定
```

# よくある失敗パターンと対策

## 1. 指示の埋没

**問題**：重要な制約が長い説明の中に埋もれている

**対策**：
```
【必須要件】
- 500文字以内
- 敬語を使用
- 結論を最初に述べる

【詳細な背景】
...
```

## 2. 矛盾する指示

**問題**：プロンプトの前半と後半で異なる指示

**対策**：一貫性のチェックと、最終的な指示の明確化

## 3. 暗黙の期待

**問題**：「わかっているはず」という前提での指示

**対策**：すべての要件を明示的に記載

# まとめ

プロンプトエンジニアリングにおける情報配置は、単純に「大事なことを先に」というだけでなく、LLMの特性を理解した上での戦略的な設計が必要です。

**重要なポイント**：
1. プライマシー効果とリーセンシー効果の両方を活用する
2. 中間部分の情報損失を構造化で補う
3. タスクの性質に応じて配置戦略を調整する

効果的なプロンプト設計により、AIからより期待に沿った出力を得ることができます。ぜひ、これらの原則を意識して、プロンプトを作成してみてください。

# 参考資料

- [Attention Is All You Need](https://arxiv.org/abs/1706.03762) - Transformer構造の原論文
- [効果的なプロンプトエンジニアリング](https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview) - Anthropic公式ドキュメント

---

この記事が役に立ったら、ぜひストックやLGTMをお願いします！プロンプトエンジニアリングに関する質問やご意見もコメント欄でお待ちしています。
Amazon Q CLIで障害物ジャンプゲーム作ってみた。

# Amazon Q CLIで障害物ジャンプゲーム作ってみた。

## 概要
社内でも話題になってましたが、Amazon Q CLIを使ってゲームを作って、それをblogやSNSで発信するとTシャツがもらえる[キャンペーン](https://aws.amazon.com/jp/blogs/news/build-games-with-amazon-q-cli-and-score-a-t-shirt/)があるそうです。


自分は[JAWS-UG 茨城のイベント](https://jawsug-ibaraki.connpass.com/event/356490/)を見ていたら、このようなキャンペーンがあることを知って、事前にトライしてみました。


## 環境
- windows11
- WSL(Ubuntu 24.04.2 LTS)

## 準備
- [WSLの準備](https://community.aws/content/2v5PptEEYT2y0lRmZbFQtECA66M/the-essential-guide-to-installing-amazon-q-developer-cli-on-windows?trk=e07eca93-fa2f-4351-b567-f293b83eb635&sc_channel=el_)
- [Amazon Q CLIを準備](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/command-line-installing.html)
- [pygameのインストール](https://www.pygame.org/wiki/GettingStarted)
※自分の場合は,名前解決ができなかったので、一時的にセキュリティソフトを停止しました。

## 手順

- まずはプロンプロを実行してゲームを作ってみます。
    - pygameを使って、障害物をジャンプで飛び越えるゲームを作って。2段ジャンプできるようにして。

- そこからよりゲームっぽさを出そうと以下のように追加で命令しています。追加したプロンプトは以下のような内容です。
    - 落とし穴を飛び越えるアップデートをして。
    - ゲームのアイコンをかわいいキャラクターにして。
    - ハイスコア上位10位まで表示して。
    - キャラクターを走っている人にして。
    - 背景の緑を一色にして。

## 結果

![side_scrole3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/39476/9f6d8872-e451-415f-a653-d6c66a244912.png)


![side_scrole1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/39476/a80f059a-47ca-4066-b210-a6aabbd6796f.png)



## 感想
落とし穴を超えるとか、ハイスコアを記録するとか、ロジックを考えると時間かかりそうなところも
簡単に作ってくれるの非常に便利でした。「かわいくして」という抽象的な命令も汲み取ってくれるところとかすごいです。アイディアの部分だけを考えてゲームを実現できる体験は面白かったです。
メモ

Sub ReplaceNoWithSymbolInSheetNames()

    Dim ws As Worksheet
    Dim originalName As String
    Dim newName As String

    For Each ws In ThisWorkbook.Worksheets
        originalName = ws.Name
        If InStr(originalName, "No") > 0 Then
            newName = Replace(originalName, "No", "№")
            On Error Resume Next
            ws.Name = newName
            If Err.Number <> 0 Then
                MsgBox "シート名変更エラー: " & originalName & " → " & newName, vbExclamation
                Err.Clear
            End If
            On Error GoTo 0
        End If
    Next ws

    MsgBox "シート名の置換が完了しました。", vbInformation
End Sub
AWS SDK for JavaScript v3に色々あるDynamoDBクライアントの違い

AWS SDK for JavaScript v3のDynamoDBクライアントはなんか色々あって紛らわしいので、GetItemする処理をそれぞれで書いて違いを確認してみた。

## 結果

No|クラス|ライブラリ|サイズ|"S": "a"形式|書き方|
---|---|---|---|---|---
1|DynamoDBClient|@aws-sdk/client-dynamodb|軽量|である|client.send(new GetItemCommand(params))
2|AWS.DynamoDB|@aws-sdk/client-dynamodb|重量|である|client.getItem(params)
3|DynamoDBDocumentClient|@aws-sdk/lib-dynamodb|軽量|でない|docClient.send(new GetCommand(params))
4|DynamoDBDocument|@aws-sdk/lib-dynamodb|重量|でない|docClient.get(params)

1は一番基本的。
2はv2互換スタイルで、[v4では削除される可能性があるとのこと](https://www.npmjs.com/package/@aws-sdk/client-dynamodb)。
3は1のラッパーで、paramsや戻り値が"S": "a"形式でなくなる。インポート元が1, 2と異なることに注意。
4は3に加えてcommandを使わなくてよくなるが、全commandをインポートするため重くなる。[3を継承している](https://github.com/aws/aws-sdk-js-v3/blob/bfe38d0075ff6e707852b00437fbc3bd4540cdf5/lib/lib-dynamodb/src/DynamoDBDocument.ts#L82)。

- `Document` がつくやつは"S":"a"形式でなくて良い
- `Client` がつくやつは `.send()`

と覚えよう。

## 1. DynamoDBClient

```javascript
import { DynamoDBClient, GetItemCommand } from "@aws-sdk/client-dynamodb";
const client = new DynamoDBClient({});

async function main() {
    const params = {
        TableName: "test1",
        Key: {
            id: {
                S: "a"
            }
        },
    };
    const res = await client.send(new GetItemCommand(params));
    console.log(res.Item); // { id: { S: 'a' }, num: { N: '1' } }
}

main();
```

## 2. AWS.DynamoDB

```javascript
import * as AWS from "@aws-sdk/client-dynamodb";
const client = new AWS.DynamoDB({});

async function main() {
    const params = {
        TableName: "test1",
        Key: {
            id: {
                S: "a"
            }
        },
    };
    const res = await client.getItem(params);
    console.log(res.Item); // { id: { S: 'a' }, num: { N: '1' } }
}

main();
```

## 3. DynamoDBDocumentClient

```javascript
import { DynamoDBClient } from '@aws-sdk/client-dynamodb';
import { DynamoDBDocumentClient, GetCommand } from "@aws-sdk/lib-dynamodb";
const client = new DynamoDBClient({});
const docClient = DynamoDBDocumentClient.from(client);

async function main() {
    const params = {
        TableName: "test1",
        Key: {
            id: "a"
        },
    };
    const res = await docClient.send(new GetCommand(params));
    console.log(res.Item); // { id: 'a', num: 1 }
}

main();
```

## 4. DynamoDBDocument

```javascript
import { DynamoDBClient } from '@aws-sdk/client-dynamodb';
import { DynamoDBDocument } from "@aws-sdk/lib-dynamodb";
const client = new DynamoDBClient({});
const docClient = DynamoDBDocument.from(client);

async function main() {
    const params = {
        TableName: "test1",
        Key: {
            id: "a"
        },
    };
    const res = await docClient.get(params);
    console.log(res.Item); // { id: 'a', num: 1 }
}

main();
```
powerpointとgoogleslidesの混在環境に耐えうるフォントを探す

## 調査結果

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/53489/a47b1b96-22f9-4c04-834b-a99670b33fb0.png)

GooglidSlidesとPowerPointの相互運用をするには、Noto Sans JPを使うしかない。

## GoogleSlidesのクセ

- メイリオとか一見つかえるように見えるが、Mac環境では使えない
- Mac環境のローカルにメイリオを入れるとGoogleSlides環境ではWindowsでもMacでもメイリオは使える
- ただしクライアント側で使えてもGoogleSlidesのサーバ側ではメイリオは存在しないのでPDF出力の際にはフォントが化ける
- GoogleSlidesのフォント化けはArialという欧文フォントに置換されるので、日本語フォントは何も設定してないのと同じで表示環境によってバラバラという最悪の置換
- 置換した結果1行に収まらないこともあるので、大事な情報が溢れてしまうこともありえる
- Mac,WindowsのローカルにもGoogleSlideのサーバー側にもデフォルトで入っていて、なおかつ相互に互換性をもつフォントを探すと以外になくて、実験してみるとNoto Sans JPしか残らない
- Noto Sans JPは悪くはないんだけど、アジアグローバルなフォントなのでやや「中華フォント感」は残る
- Mac、Windowsを超えて使えるユニバーサルなフォントで言えばBIZ UDシリーズがいいんだけど、GoogleSlidesはBIZ UDが使えるにも関わらず、PowerPointをGoogleSliesで開いたときにはBIZUDフォントを殺しにかかる
- 限りなくバグにみえる仕様だけど受け入れるしかない

### 結論：これも一つのビジネスチャンス

- 「他人様に渡してこその文書」という発想が抜け落ちてドキュメンテーションツールが作られてるので、これも一つのビジネスチャンス
- GoogleSlidesが使い物にならないからこそ、Office＋BOXみたいなソリューションが重宝されているのかも
- Canvaも使えるのかなと思ったけど、以下の制約でドキュメンテーションツールとしてはいまいち
    - EMFが貼れない
    - 文字を長体にできない
- 互換性を語る時に「同じフォントが使えるかどうか」という観点でテストしている例が少なすぎる。フォント置換で文字が溢れて見えなくなったらその時点でアウト。嘘情報を渡すくらいなら真っ白の方がまだまし
-
【Python】uvはいいぞ【脱 pip】

Pythonのパッケージ管理、正直しんどいと思ったことはありませんか？
私は何度もあります。特にpipを使っていると、依存解決や環境の再現性で悩まされることが多々あります。そんな中で登場したのが**uv**です。この記事では、pipや他のツールと比較しながら、uvの魅力を紹介します。

https://github.com/astral-sh/uv

## pipはここがしんどい

pipはPython標準のパッケージマネージャーですが、以下の点で苦労することがあります。

* **依存解決が弱い**
  pipは依存パッケージのバージョン衝突をうまく解消できないことがあります。例えば、Aはpackage-X>=1.0,<2.0が必要で、Bはpackage-X>=2.0が必要、のようなケースで詰みます。

* **Lockファイルが標準でない**
  pip単体では、環境の完全な再現性を担保する仕組みがありません。requirements.txtはありますが、依存関係の解決順序や環境差異によって微妙に違う環境が出来上がることもあります。

* **速度が遅い**
  インストール時に毎回依存解決をしてネットワークにアクセスするため、環境構築に時間がかかりがちです。

## pip, poetry, pipenv, uvの違い（ざっくり）

| ツール    | 依存解決  | Lockファイル                | 速度   | 特徴                    |
| ------ | ----- | ----------------------- | ---- | --------------------- |
| pip    | 弱い    | なし（手動でrequirements.txt） | 遅い   | 標準、最小限                |
| pipenv | 改善あり  | Pipfile.lock            | 遅め   | 開発用に人気があった            |
| poetry | 強い    | poetry.lock             | やや遅い | モダンで多機能（ビルド、パブリッシュも可） |
| uv     | 非常に強い | uv.lock                 | 爆速   | Rust製、高速で信頼性が高い       |

## uvの良さ

では、uvのどこが素晴らしいのか？

* **とにかく速い**
  Rustで実装されているため、pipやpoetryに比べて桁違いに高速です。初回インストールも、キャッシュ後の再現も非常に速いです。

* **優れた依存解決**
  依存関係の衝突検出・解決が非常に強力で、poetry同等かそれ以上の解決能力があります。

* **Lockファイル標準対応**
  uv.lockが標準で生成され、チームでの環境再現が容易になります。CI/CDパイプラインの再現性もバッチリ。

* **pip互換**
  pipのサブコマンド互換性があり、既存プロジェクトでも導入しやすいのが魅力です。

* **今後の進化が楽しみ**
  現在も活発に開発されており、機能の追加や改善が続いています。

## まとめ

Python界隈の依存地獄に悩んでいる方には、ぜひ**uv**を試してほしいです。速さ・正確さ・再現性の三拍子が揃ったパッケージマネージャーとして、今後ますます普及していく可能性があります。

**uvはいいぞ。**
latexチートシート #latexworkshop

<style>
.column-left{
  float: left;
  width: 47.5%;
  text-align: left;
}
.column-right{
  float: right;
  width: 47.5%;
  text-align: left;
}
.column-one{
  float: left;
  width: 100%;
  text-align: left;
}
</style>

先日、Xを漁っていたところ、すごく有益なvscodeの拡張機能(Latex workshop)でのlatexスニペットのまとめ記事を英語で見つけたので、自分の暗記する機会も兼ねて記事を作成します。
* 以下のような方を対象とした記事になっています
    * 既にlatexを導入された方
    * VScodeも使用している方
    * 数式入力が多い方(効率化の恩恵が大きです)
    * Latex workshopを使用している方
    

> [英語のまとめ記事](https://cheatography.com/jcwinkler/cheat-sheets/latex-workshop-visual-studio-code/)を参照して記事を書いています。([workshop公式ページはこちら](https://github.com/James-Yu/LaTeX-Workshop/wiki/Snippets))
少し省いている部分があるので、全て気になる方はそこまで遡って見てみますと確認しやすいと思います。

# 見出し1
この下にそれぞれのスニペットをまとめていきます。
以下はmacのvscode環境での確認をしていますが、windowsでは動作確認してないです。(多分大体のものは動くと思います)

:::note warn
  灰色背景(例：`TAB`)では特定のkeyを表します。
 ただの文字では(例：spa)ではそのままspaを表します。
 よって、spa+`TAB`ではspaを打ち込んだ後にtabキーを押すことを指します。
 
 (『\sectionなど』と『環境について』は以下のルールに則ります。
 『数式について』は灰色背景でもkey typeしてください。)
:::
## \sectionなどについて
SPA + `enter`：\part{}という文字に自動で変換されます。
SPC + `enter`：\chapter{}　〃
SSE + `enter`：\section{}　〃
SSS + `enter`：\subsection{}　〃
SS2 + `enter`：\subsubsection{}　〃

## 環境について
BFI + `TAB`：\begin{figure}環境を作ります(\endもついてきます) 
BEQ + `TAB`：\begin{equation}環境を作ります(\endもついてきます)  
BSEQ + `TAB`：\begin{equation*}環境を作ります(\endもついてきます)  
BAL + `TAB`：\begin{align}環境を作ります(\endもついてきます)  
BSAL + `TAB`：\begin{align*}環境を作ります(\endもついてきます)  
BCAS + `TAB`：\begin{cases}環境を作ります(\endもついてきます) 

## 数式について
| `@(`： `\left( \right)` | `@{`： `\left\{ \right\}` |              
| ---------------------- | ------------------------ |  
| `@[`： `\left[ \right]` | `__`： `\_{ }`            |             
| `**`： `^{ }`           | `...`： `\dots`           |              
| `@.`： `\cdot`          | `@8`： `\infty`           |              
| `@6`： `\partial`       | `@/`： `\frac{ }{ }`      |              
| `@%`： `\frac{ }{ }`    | `@^`： `\hat{ }`          |              
| `@_`： `\bar{ }`        | `@@`： `\circ`            |              
| `@0`： `^\circ`         | `@;`： `\dot{ }`          |              
| `@::`： `\ddot{ }`      | `@=`： `\equiv`           |              
| `@\*`： `\times`        | `@<`： `\leq`             |              
| `@>`： `\geq`           | `@2`： `\sqrt{ }`         |              
| `@I`： `\int_{ }^{ }`   | `@\|`： `\Big \|`         |
| `@\`： `\setminus`      |                          |              
  


### ギリシャ文字(これはなんとなく使っている人も多い気がします）
これは@aのように表示すると\alphaとなるスニペットとなっています。以下対応表

| a = α | b = β |
|---|---|
| c = χ | d = δ |
| e = ε | f = φ |
| g = γ | h = η |
| i = ι | k = κ |
| l = λ | m = μ |
| n = ν | o = ω |
| p = π | q = θ |
| r = ρ | s = σ |
| t = τ | u = υ |
| x = ξ | y = ψ |
| z = ζ | D = Δ |
|F =　Φ |G = Γ  |
|Y = Ψ | W = Ω  |

## 豆知識
\frac{}{}などで、一つ目の{}内にカーソルから→のkeyで移動するのがめんどくさいことは多々あると思います。
そのようなとき、macでは`control`+f によって一つ右に移動できます。これを駆使すると→keyを探す手間が消えるのでおすすめです。

------------

以上です。
これでみなさんのtex生活が効率化されることを願っています。

修正や、動作がおかしいものがありましたら、コメントまでお願いします
Shopifyテーマをローカル環境で確認する方法

Shopifyテーマをローカルで開発・確認するには、**Shopify CLI**を使うのが公式で推奨されている方法です。この記事では、Shopify CLIのインストールからローカルサーバーでの動作確認まで、現行仕様に即して解説します。



## 前提条件

- Shopifyパートナーストアまたは開発ストアを所有していること
- ローカルPC上でテーマ（Liquidファイル群）を操作できる環境が整っていること



## 1. Shopify CLI のインストール

macOSの場合は以下のコマンドでインストールします。

```bash
brew tap shopify/shopify
brew install shopify-cli
```

※Windows / Linuxユーザーは [公式ドキュメント]() を参照してください。



## 2. テーマの準備

### 新規テーマを作成する場合

```bash
shopify theme init
```

テーマテンプレートを選択して、任意のテーマを作成できます。

### 既存テーマを取得する場合

```bash
shopify theme pull --store your-store-name.myshopify.com
```

> ⚠️ **注意：独自ドメインを利用していても、`--store` に指定するのは `.myshopify.com` ドメインです。**
>
> たとえば `example.com` などの独自ドメインや `admin.shopify.com/store/xxxxx` の形式は使えません。



### 🔍 `.myshopify.com` ドメインの確認方法（2025年現在）

管理画面URLが `https://admin.shopify.com/store/xxxxx` 形式になっている場合は、以下の手順で確認します。

1. 管理画面左下の「設定（Settings）」をクリック
2. 「ドメイン（Domains）」を開く
3. 「Shopifyが提供したドメイン」一覧に表示される
    　→ `xxxxx.myshopify.com` がCLIで使うストア識別子です



## 3. ローカル開発サーバーを起動

テーマディレクトリに移動したうえで、次のコマンドを実行します。

```bash
cd your-theme-directory
shopify theme dev --store your-store-name.myshopify.com
```

初回実行時は、ログイン用のコードが表示され、自動的にブラウザで認証画面が開きます。
 認証完了後、以下のようなURLが表示されます：

```bash
http://127.0.0.1:9292
```

このURLにアクセスすることで、**実際のストアデータを使ったローカルプレビュー**が可能です。



## 4. よくあるエラーと対処法

### ⚠️ `It doesn't seem like you're running this command in a theme directory.`

現在のディレクトリに `theme.liquid` や `layout/`, `templates/` 等が存在しない場合に出る警告です。
 **正しいテーマディレクトリに `cd` で移動してから再実行してください。**



## 5. 編集内容の保存

ローカルでの編集はリアルタイムにプレビューに反映されますが、ストアには反映されません。
 ストアに反映したい場合は次のコマンドでアップロードします：

```bash
shopify theme push --store your-store-name.myshopify.com
```



## まとめ

Shopify CLIを使えば、テーマをローカル環境で安全かつ効率的に開発・確認できます。
 **CLIで指定するストア名は、独自ドメインではなく `.myshopify.com` ドメインである必要がある点に注意**しましょう。

環境や仕様変更によりCLIの挙動は変わるため、常に公式ドキュメントを参照することをおすすめします。
クイックソートについて調べてみた

## はじめに
　大学の授業でクイックソートについて習ったので、自分自身の理解を深める目的で、最低限の情報だけ記事にまとめてみました。

## 操作
基準値（ピボット）を決めて、その値より小さいグループと大きいグループに分け、それぞれのグループに対して同様の操作を繰り返すことで、ソートを行います。基準値は先頭にする場合など、決め方はいくつかありますが、この記事では配列の中央にしています。

### 可視化

![quick_sort_animation.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3922095/09b766f1-157a-4c12-9267-c145f63aee9d.gif)


#### ピボットの選び方が悪い場合（毎回最大値を選ぶ）
![quick_sort_animation.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3922095/247df734-002a-41c8-8667-621ea9e259d4.gif)



## 計算量
　最悪計算量がO(n^2)で、最良計算量はO(nlogn)です（底はeではなく2）。最悪になるのは、毎回ピボットが最大値か最小値になり、分割が極端に偏るときです。また、最良になるのは、毎回うまく2分割した場合です。
 
### 最悪ケース
要素数n~2まで一つずつ減りながらピボットと比較を行うので、n-1~1までの和になります。

$$ 比較回数=(𝑛−1)+(𝑛−2)+⋯+1 = \frac{(𝑛−1)((𝑛−1)+1)}{2} = \frac{𝑛^2−n}{2}=O(n^2) $$

### 最良ケース
 
各段階で部分配列ごとに、ピボットと比較していくと考えると、要素数-1が部分配列内での比較回数になります。これに部分配列の数をかければいいので
$$比較回数=(\frac{n}{2^k}-1)×2^k = n-2^k = O(n)$$
と表せます。

何回半分にすれば要素数がnから１になるかを考えればいいので、
$$ 2^x = n$$
となるようなx。つまり定義からlognが分割回数です。したがって、logn回O(n)の計算をするので計算量はO(nlogn)になります。

:::note warn
後述のコードでいうところのleftとrightがpivotの位置で一致する場合は、pivotがその位置に確定するなど、完璧に計算するのが難しかったので、ざっくりとした計算ですが、オーダー自体がざっくりしたものなので、問題ないでしょう。（と思いたい）
:::

平均計算量は、完全ランダムで十分な要素数の配列で考えると、大体二等分に近い形で分割が進むので、最良ケースに近いと考えています。

↓詳しい計算はこちらに載っていました。

https://qiita.com/warper/items/ae769e105862bfa25310

## 安定ソートではない
　先頭と末尾からそれぞれ探索し、入れ替えを行うので、同じ大きさの値が頻繁に入れ替わります。したがって安定ソートではありません。
 
## 内部ソート
　先頭と末尾から条件に合う値を見つけ、それぞれを交換していきますが、後述のコードを見ればわかる通り、入れ替えの操作が配列自身のメモリ領域内で完結できるので、内部ソートです。

## コード
pythonで書くと、こんな感じです。
```python
def quick_sort(arr, start, end):
    if start >= end:
        return
    pivot = arr[(start + end) // 2]
    left = start
    right = end
    while left <= right:
        while arr[left] < pivot:
            left += 1
        while arr[right] > pivot:
            right -= 1
        if left <= right:
            arr[left], arr[right] = arr[right], arr[left]
            left += 1
            right -= 1
    quick_sort(arr, start, right)
    quick_sort(arr, left, end)
```

`left`と`right`が交差した、もしくは重なった時点で`while`を抜けるので、次の部分配列は`start ~ right`、`left  ~ end`になります。また、`left`と`right`が重なった時はその点が基準値と等しいので、`left += 1`、`right += 1`をそれぞれ適用することで、その点を除いて部分配列を作成しています。

pythonらしく書くと、こんな感じです。再帰に慣れていない初心者の方は、こちらの方が分かりやすいと思います。
```python
def quick_sort(arr):
    if len(arr) <= 1:
        return arr
    pivot = arr[len(arr) // 2]
    left = [i for i in arr if i < pivot]
    middle = [i for i in arr if i == pivot]
    right = [i for i in arr if i > pivot]

    return quick_sort(left) + middle + quick_sort(right)
```
内包表記でフィルタリングすることで、基準値以上、基準値に等しい、基準値以下に分けています。

この場合、内部ソートではなくなりますが、安定ソートになります。内包表記を使っているため高速に動作しますし、メモリを気にしないなら、こちらの方がいいかもしれません。
## 総評

### 強み
- 基本的に高速

### 弱み
- 安定ソートではない
- かなり限定されるが、遅い時は遅い

→　特定のパターンに気を付ければ、多くの場面で活用できる。

## 最後に
　ここまで読んで下さりありがとうございました。Pythonだとかなり楽に書ける書き方もありますが、ちゃんと交換で実装するとややこしいです。可視化したことで、コードの目的がはっきりとしてよかったと思います。
初心者による自分のためメモ ~HTML_リスト要素編~

## はじめに
こんにちは。プログラミング学習中の大学生です。
今回は、HTMLのリスト要素についてまとめたいと思います。


### 前回の記事:初心者による自分のためメモ ~HTML_構成編~
url: https://qiita.com/Ryoga_Eve/items/76abef0458c0aa7e6aa6

## リスト要素
リスト要素には順序のないリスト要素である`<ul>`と、順序のあるリストである`<ol>`がある。
各要素の中には`<li>`要素を入れる。これはリストの中身の要素である。
### `<ul>`順序なしリスト要素
・C
・C++
・python
のように、順序のないリストを表す要素である。
```html
<ul>
    <li>C</li>
    <li>C++</li>
    <li>python</li>
</ul>
```
というように書くことができる。

### `<ol>`順序ありリスト要素
1.HTML
2.CSS
3.JavaScript
のように、順序があるリストを表す要素である。
こちらも`<ul>`要素と同じように
```html
<ol>
    <li>C</li>
    <li>C++</li>
    <li>python</li>
</ol>
```
と書くことができる。

また、これらのリスト要素はリストをさらにネスト(入れ子)することができる。
```html
<ol>
    <li>HTML
        <ul>
            <li>CSS</li>
            <li>JavaScript</li>
        </ul>   
    </li>
</ol>
```
と書くことによって
1.HTML
&nbsp;&nbsp;&nbsp;・CSS
&nbsp;&nbsp;&nbsp;・JavaScript
というように表すことができる。
トラブルシューティング: `docker-credential-desktop` が見つからず Dockerイメージが起動できない


## 先に結論だけ

```
MCP error -32000: Connection closed
```

Dockerイメージを取得してMCPサーバーを起動しようとした際にこのエラーが発生したら、Docker DesktopのAdvanced設定から、`Choose how to configure the installation of Docker’s CLI tools` を`System (requires password)`に変更してください。

## 対象とする環境

- macOS 15.5（24F74）
- Docker version 28.1.1, build 4eba377
- Docker Desktop for Mac V4.41.2
  - .dmgからApplicationsフォルダーへドラッグ＆ドロップでインストールしています
- backlog-mcp-server v0.3.0 
  - mcpサーバーをDockerコンテナーで起動しようとした際に発生

:::note warn
将来のバージョンでは挙動が変わるかもしれないので、記事を読む前にお手元の環境のバージョンを確認してください。
:::

## 対象とする読者

- Docker初心者
  - MCPサーバーの利用にDockerが必要になったが、前提知識がない方

:::note warn
この記事はDockerをはじめて使うユーザーを対象として想定しています。
:::

## 発生した問題

Clineに[backlog-mcp-server](https://github.com/nulab/backlog-mcp-server)をセットアップしようとしたところ、以下の表示が出力されて起動しませんでした。

```
MCP error -32000: Connection closed
```

backlog-mcp-serverの起動コマンドを直接ターミナルで実行すると、以下のエラーが発生しました。

```
  docker: error getting credentials - err: exec: "docker-credential-desktop": executable file not found in $PATH, out: ``
```
 `~/.docker/config.json` に `"credsStore": "desktop"` が設定されていると、このエラーが出力されてコンテナーが起動しません。`config.json` から `"credsStore": "desktop"` を削除すると一時的に解決しますが、Docker Desktopを再起動すると削除した設定が復元されてしまいます。

 ## 原因

Docker Desktop for MacではCLIツールが `$PATH` に登録されず、`docker-credential-desktop` 実行ファイルを参照できないため問題が発生しています。

## 解決方法

### A. Docker DesktopのAdvanced SettingでCLIツールを/usr/local/binにインストールする

1. Docker Desktopを起動  
2. 画面右上の歯車アイコンをクリックし、`Settings` を開く  
3. 左メニュー最下部の `Advanced` タブを選択  
4. `Choose how to configure the installation of Docker’s CLI tools` を切り替える  
   - `System (requires password)` を選択
5. `Apply & Restart`ボタンをクリック

→ これにより `/usr/local/bin/docker-credential-desktop` などにCLIツールが配置され、`credsStore: "desktop"` のまま問題なく認証情報を扱えるようになります。

### B. 代替手段（参考）

手動でシンボリックリンクを張る方法もありますが、推奨しません。この問題がどのような原因で発生するのかを理解するための参考情報として記録しておきます。

```bash
sudo ln -sf \
  /Applications/Docker.app/Contents/Resources/bin/docker-credential-desktop \
  /usr/local/bin/docker-credential-desktop
```
## 問題が解決したかの確認

```bash
which docker-credential-desktop
```
でパスが通っていることを確認してください。

以上、ありがとうございました。
生成モデルの基礎知識4 Mixed Precision

こんにちは。
最近、NVIDIA-Certified Associate: Generative AI and LLMs (NCA-GENL)を習得しました。
その際に知っておいた方が良い基礎知識とコードの書き方を共有したいと思います。
生成AIのチュートリアル:

https://github.com/Yuji-github/Gen_AI_Tutorial

https://colab.research.google.com/drive/1YCG8NlrF1iILMp362RoY99esnKVKaqFu?usp=sharing

1. Mixed Precisionとは？（モデルをトレーニングする際に使います。）

モデルは基本的にFP32（32ビットのフロート）で作られます。
これにより、より細かなベクトル化が出来ます。

```
test_tensor = torch.tensor([0.01, 0.25, 1.5, -0.81])
print(test_tensor)
--> torch.float32
```
しかし、FP32のデメリットとしてモデルが大きくなりすぎる。
（ChatGPT3は1750億のパラメーターがあり、1TBのメモリーが必要。）
現在の市販されているハードウェアのスペックでは、ChatGPT3等の大きなモデルをFP32のままファインチューンしたら、トレーニングのスピードが遅くなる上にGPUメモリーが足りなくなる等の問題があります。
（ChatGPT等はMixed　Precision以外にもLoRAを使います。）

そこで、考えられたのがFP32をFP16に変換すればトレーニングするモデルが半分になるMixed　Precision（FP32とFP16をミックスする）と言うアイデアです。

![precision.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4108653/1859650d-7c58-435e-a3c0-e5746ec8525a.png)

上記の写真はMixed Precision（FP32とFP16をミックスするが使用される場所を表してます。

上記の写真から重みのマスターコピーはFP32で保存し、各トレーニングイテレーションの一部（1回の順伝播、バックプロパゲーション、および重み更新）中にFP16に変換します。
イテレーションの最後に、重みの勾配は、オプティマイザーステップ中にFP32マスター重みをアップデートするために使用します。

FP32で重みのコピーを保持する利点に下記が挙げられます。
多くの学習率が小さ為、重みの勾配（グラディエント）と乗算されると、非常に小さな値になること。
FP16の場合、2＾−24よりも小さい絶対値の数値は、表現できないためゼロとみなされる。

２．FP16の種類
FP16にはFP16とBF16の２種類がある。
BF16を使用する際はNVIDIA Ampere/Hopperがサポートしているか確認する必要がある。

|  |FP16  |BF16  |
|---|---|---|
|メモリー  |16 ビット (2 bytes)  |16 ビット (2 bytes)  |
|符号ビット  |1  |1  |
|指数部  |5  |8  |
|仮数　ビット |10  |7  |
|Numeric 精密 |高い  |低い  |
|Numeric　ダイナミックレンジ  |低い  |高い  |
|使用 |GPUベース  |CPU/TPUベースで大規模のモデル  |

Pytorchでの使用方法
```
import torch

model = myModel()
loss_fn = torch.nn.MSELoss().cuda()
opt = torch.optim.SGD(net.parameters(), lr=0.001)

use_amp = True
scaler = torch.amp.GradScaler("cuda" ,enabled=use_amp)

for epoch in range(epochs):
    for input, target in zip(data, targets):
        with torch.autocast(device_type=device,
        dtype=torch.float16,
        enabled=use_amp): # FP16が使われる　dtype=torch.bfloat16ならBF16
            output = model(input)　# FP16が使われる
            loss = loss_fn(output, target)　# FP16が使われる
        scaler.scale(loss).backward()　# FP32が使われる
        scaler.step(opt)　# FP32が使われる
        scaler.update()　# FP32が使われる
        opt.zero_grad() # FP32が使われる
```
PyTorchをanacondaに入れる, pipで入れる

Pytorchの公式サイトからcondaコマンドを使ってPyTorchを入れる方法が消えてた。いっぱい詰んだのでメモしておく。

# PyTorch公式サイトを確認する

[PyTorch公式](https://pytorch.org/get-started/locally/) で自分の環境を入れて、後で使う予定のコマンドと、集めるべきもののバージョンを確認する。condaがPackageにないことも確認する。
- Python 3.9 以降
- CUDA 11.8 か 12.6 か 12.8

CUDAのバージョンは他のソフトに合わせて決めればいいが、変えないこと
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4114634/b378539d-27a7-4951-a448-3619e844bbdb.png)

# CUDA をダウンロードする
**必ず指定されたバージョンを落とすこと**。新しければいいわけではない。そのバージョンでpytorchがコンパイルされてるっていうことだから。

[CUDA Toolkit Archive](https://developer.nvidia.com/cuda-toolkit-archive) または「cuda [バージョン]」でググって、前項で決めたバージョンをダウンロードする。

Versionは Windowsのバージョンのこと。自分の端末に合わせる。

Installer Typeはどちらでもいい。localは全てのファイルをダウンロードする完全版。インストーラー実行時に必要なファイルをダウンロードする形式。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4114634/874826fe-0d78-4c56-baa1-240aa811c81a.png)

# (一応) GPUが対応しているか調べる
公式サイトより英語Wikipediaのほうがわかりやすい。
https://en.wikipedia.org/wiki/CUDA#GPUs_supported

CUDA 12.8ならGeForce GTX 750以降対応なのでゲームしてるならおそらく平気。

# GPUのドライバのバージョンもチェックする
[CUDA Toolkit の release notes の CUDA Driverの章](https://docs.nvidia.com/cuda/cuda-toolkit-release-notes/index.html#cuda-driver) を見ると必要とされるバージョンが書いてある。
CUDA 12.x の場合は 528.33 以上が必要。

NVIDIAコントロールパネル（スタートメニューにたぶんいる）を開いて、左下のℹ️システム情報を押すと書いてある。バージョンの上げ方はゲーマー向け解説記事が詳しい。

# CUDAを入れる
適当にyes押すだけ。インストール終わったあとにこんなのが出たりするけど特に気にしなくていい。使うだけなら必要ないため。
```
Installed:
     - Nsight for Visual Studio 2022
     - Nsight for Visual Studio 2019
     - Nsight Monitor
Not Installed:
     - Integrated Graphics Frame Debugger and Profiler
       Reason: see https://developer.nvidia.com/nsight-vstools
     - Integrated CUDA Profilers
       Reason: see https://developer.nvidia.com/nsight-vstools
```

## 補足 (2025/06/22追記)
Visual Studioが入ってないと、エラーを吐きます。

開発者人生やってたらそのうち使うので入れてしまうほうがいい。入れない場合は、ここでカスタムにして、CUDA>Nsight Computeのチェックを外す。Visual Studioで使えなくなるだけ。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4114634/ae0d5532-2f23-4845-9801-16bd6b2d6110.png)

# Anaconda
Anaconda は入っている前提。Anaconda Promptをスタートメニューから開いて以下のコマンドを打っていく。
y/n 聞かれたらy で大丈夫。
```
conda create –n envname python=3.10
conda activate envname
```
仮想環境を作成してアクティベートする。python 3.9 以上必要なので3.10を選択。```envname``` は仮想環境の名前になるのでわかりやすい名前にするとよい。

```
pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu128
```
ここは最初に [PyTorch公式](https://pytorch.org/get-started/locally/) で確認したコマンドを打つ。


```
python
```
正しくGPUを使える環境が立っているか確認するために、ここでPythonのインタープリターに入り、以下を入力して実行する。
```
import torch; torch.cuda.is_available()
```
これを入れてEnter押してTrueと帰ってきたら正常に入っている。お疲れ様でした。

# 補足
### さまざまな詰み
matpliotlibはcondaで入れてはいけない。numpyとかPytorchとかと競合するのか、依存関係がすべて破壊される。```pip install matplotlib```が壊れない入れ方。

### Anaconda Prompt操作

環境から抜けるときは ```conda deactivate```
環境を消すときは環境から抜けてから```conda env remove --name envname```
1.5ビットパイプラインADCの構成と動作をわかりやすく整理してみた



# 1.5ビットパイプラインADCの構成と動作をわかりやすく整理してみた

## はじめに

パイプラインADCは高速かつ高分解能なA/D変換方式として、通信機器や画像処理回路などで幅広く使われています。
なかでも「1.5ビットステージを連結する方式」は、**高い直線性**と**冗長性による誤差耐性**を実現することで知られています。

本記事では、**1.5ビットADCステージ**の基本構成から**判定ロジック**、**MDAC（Multiplying DAC）による残差処理**まで、数学式と図表でわかりやすく解説します。

---

## 1. 各ステージの基本構成：1.5ビットってどういう意味？

### ▶ 構成のポイント

* 各ステージは**コンパレータ2個**を使って、入力電圧を3領域に分類します。
* この3値を\*\*2ビット（冗長）\*\*で表現し、後段の誤差訂正が可能になります。
* これにより、1ビット当たり以上の精度を確保しつつ、次段ステージに残差を渡すことができます。

---

## 2. 判定レベル → 出力ビット → High/Low分類の対応表

| 判定レベル | 出力ビット（例） | 判定条件                                                      | 分類            |
| ----- | -------- | --------------------------------------------------------- | ------------- |
| Low   | 00       | \$V\_{in} < \frac{1}{4}V\_{ref}\$                         | **Low**（ロー）   |
| Mid   | 01       | \$\frac{1}{4}V\_{ref} \le V\_{in} < \frac{3}{4}V\_{ref}\$ | **Mid（再量子化）** |
| High  | 10       | \$V\_{in} \ge \frac{3}{4}V\_{ref}\$                       | **High**（ハイ）  |


---

## 3. ビット分類 → ハイ／ローの最終出力

| 出力ビット | 意味      | ハイ／ロー分類       |
| ----- | ------- | ------------- |
| 00    | 入力が最小領域 | Low（ロー）       |
| 01    | 入力が中間領域 | Mid（再計算・再量子化） |
| 10    | 入力が最大領域 | High（ハイ）      |

この「ビット分類→分類出力」は、簡単な組合せ論理回路で実装可能です。



---

## 4. ステップ2：MDACで残差を生成（Multiply DAC）

### ▶ 使用素子と記号定義

| 記号           | 意味            |
| ------------ | ------------- |
| \$V\_1\$     | 入力電圧          |
| \$V\_{ref}\$ | 参照電圧          |
| \$C\_s\$     | サンプリングキャパシタ   |
| \$C\_f\$     | フィードバックキャパシタ  |
| \$D\_x\$     | 出力ビット値（0または1） |
| \$V\_{out}\$ | 残差電圧（次段への入力）  |

---

### ▶ 一般式（電荷保存則から導出）

$$
V_{out} = \left( \frac{C_s + C_f}{C_f} \right)V_1 - \left( \frac{C_s}{C_f} \right)V_{ref} \cdot D_x
$$

### ▶ 理想条件：\$C\_s = C\_f\$

このとき、式は以下のように簡略化できます：

$$
V_{out} = 
\begin{cases}
2V_1 & (D_x = 0) \\
2V_1 - V_{ref} & (D_x = 1)
\end{cases}
$$

これは、**「2倍して参照電圧を引く」演算**が、スイッチ付きキャパシタ（SC）回路で物理的に実装されることを意味します。

---

## 5. 最終構成：パイプライン連結で高分解能を実現

* 各ステージが「**1.5ビット判定 + 残差生成**」を行います。
* 残差は次段ステージの入力となり、逐次ビット決定が進行。
* 最終的に **nステージ → 実効分解能 nビット程度** のA/D変換が完了します。

---

## 6. 多段構成とデジタル補正（全加算器・半加算器）

* 各ステージ出力ビットは **Dフリップフロップ** によって一時保存し、**タイミングずれを補正**。
* **全加算器（Full Adder）**や**半加算器（Half Adder）**によって、各ステージ出力を**ビット加算処理**。
* これにより、冗長ビットを含む複数段の出力を、**1つのバイナリデータ列**へと変換できます。

---

## 7. 設計上のトレードオフ

| 項目    | 内容                              |
| ----- | ------------------------------- |
| 精度向上  | 1.5ビット構成によって、**オーバーレンジ誤差にロバスト** |
| 高速化   | パイプライン構成により、**サンプルを並列に処理可能**    |
| デメリット | **回路規模が大きくなる（比較器、アンプ、スイッチが多数）** |

---

## 8. 全体動作まとめ

1. 入力電圧を3領域に分類（Low / Mid / High）
2. 判定結果を2ビットで符号化（冗長性あり）
3. MDACで残差を計算（SC回路で「2倍−Vref」処理）
4. 残差を次段ステージの入力にし、繰り返し処理
5. 最終的に加算器・クロック同期により出力を整形

---

## おわりに

1.5ビット構成は、一見すると「非効率」なように思えますが、誤差耐性と直線性の観点から非常に優れた方式です。
特にアナログ誤差が無視できない回路設計においては、この冗長性が大きな武器になります。

---

## 参考

https://miscellaneous.tokyo/blog/pipeline-adc/
GitHubで、自分がレビュアー&レビュー済み&まだOpen、なプルリク一覧を確認する

## 結論

```
is:open is:pr reviewed-by:@me -author:@me 
```

でフィルタをかける

[URL化したもの](https://github.com/pulls?q=is%3Aopen+is%3Apr+reviewed-by%3A%40me+-author%3A%40me)

# 背景

GitHubデフォルトの[Review Request](https://github.com/pulls/review-requested)では、レビューをしちゃうと消えちゃって確認できなくなるので
Google Cloud ClassroomAPIを使えるようにする方法

## 概要

Google CloudのAPI（ClassroomAPI）を使えるようにする方法を簡単にまとめる。

## 方法

1. Google Cloudにアクセス
1. サイドバーにて「APIとサービス」をクリック
1. 「APIとサービスを有効にする」をクリック
1. 「classroom」と検索

    ![CleanShot 2025-06-16 at 13.00.55@2x.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/306417/3cf23383-47a2-4682-b6be-ffd60e4612e9.jpeg)


1. ヒットしたGoogle Classroom APIの詳細を開く

    ![CleanShot 2025-06-16 at 13.01.05@2x.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/306417/37c7af43-0747-421d-8a9b-2cd077611c19.jpeg)

1. 「有効にする」をクリック

    ![CleanShot 2025-06-16 at 13.01.25@2x.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/306417/b7878ea7-bb43-4a25-b4db-f4a74f44dacd.jpeg)
ファイル存在確認はos.path.existsだけじゃない？──コーディングの癖から学ぶPython実務ロジック

### はじめに：存在確認ロジックに潜む“癖”

Pythonでファイルの存在確認をする方法として、`os.path.exists`は定番中の定番です。私自身もこの方法に長らく慣れ親しんできました。しかし、あるとき他のエンジニアが書いたコードで、「ファイルの存在を<em>ファイル数のカウント</em>でチェックしている」場面に出会い、ハッとしました。「存在確認」の目的は同じでも、**ロジックの組み方に“癖”が出る**という事実──本記事では、このようなコードスタイルの違いと、その背景や実務での影響について整理していきます。

### Pythonにおけるファイル存在確認の基本

公式ドキュメントでは、Pythonでファイルやディレクトリの存在確認を行うには`os.path`モジュールを使うのが一般的とされています。中でも以下の関数はよく利用されます。

- `os.path.exists(path)`: ファイル・ディレクトリの両方を対象に存在確認
- `os.path.isfile(path)`: ファイルのみを対象に確認
- `os.path.isdir(path)`: ディレクトリのみを対象に確認

しかし、公式には「存在確認」そのものの手法は示されているものの、**どのようにロジックを構成すべきか**といった実践的な部分はほとんど触れられていません。ここが実務での実装方針に個性が出るポイントとなっています。

### よくある“数で確認する”存在チェックの癖

実際に私が遭遇したコードは次のようなものでした。

```py
import os

def is_folder_empty(folder_path):
    return len(os.listdir(folder_path)) == 0

if not is_folder_empty("/path/to/dir"):
    print("ファイルがあります")
else:
    print("ファイルがありません")
```

このコードでは`os.listdir()`を使ってファイル一覧を取得し、その **件数が0かどうか** で存在確認をしています。一見遠回りにも思えますが、実はこの方法には **「中身が空かどうかも同時に判定したい」** という意図が隠れている場合があります。

### 比較：`os.path.exists` と `os.listdir` の使い分け

```py
# os.path.existsを使うケース（ファイル・フォルダの有無を知りたいだけ）
import os

if os.path.exists("/path/to/file_or_dir"):
    print("存在します")
```

```py
# os.listdirを使うケース（ディレクトリ内が空かどうか確認したいとき）
import os

files = os.listdir("/path/to/dir")
if len(files) > 0:
    print("ファイルがあります")
```

このように、前者は **存在の有無**、後者は **空かどうか** を判断したいときに向いています。ただし、<span style="color:red;">空であることが「存在しない」と同義ではない</span>点に注意が必要です。


### なぜ“癖”が出るのか？背景にある意識と設計

このようなコードスタイルの違いは、単なる記法の違いではなく、次のような背景が影響しています。

- 例外処理の設計方針（try-exceptを使う vs 条件分岐で逃がす）
- エラーの原因調査を容易にしたいという保守性の意識
- コードレビュー文化：明示的な意図の共有が求められるプロジェクト
- 個人の習慣や、過去に遭遇した不具合経験

例えば「フォルダはあるけどファイルが0件」な状態で不具合になった経験があるエンジニアは、以降`len(os.listdir()) == 0`のようなスタイルを好む傾向があります。

### 実務でのTipsと注意点

以下に、**存在確認** に関するベストプラクティスと注意点をまとめます。

- 単純な存在確認だけなら `os.path.exists` を使うのがベスト
- `os.listdir`は<span style="color:red;">フォルダが存在しない場合エラー</span>になるので例外処理が必要
- ファイルの種類まで厳密に確認したい場合は `os.path.isfile` も併用
- データ処理系のバッチなどでは「ファイルがN件以上なら処理実行」といった条件で `len()` を使うのが実務では一般的
- ユニットテストの際は **モックを使って存在確認の挙動を再現** するのがベター

### まとめ：ロジックは「何を守りたいか」で変わる

ファイルの存在確認という単純な処理であっても、ロジックの組み方にはエンジニアの **経験・思想・責任感** がにじみ出ます。コードに正解は1つではありません。大事なのは、その意図が他者にとっても明確であることです。
また、今回のように`os.path.exists`と`os.listdir`のような **似て非なる手法** の違いに気づくことで、自分の“癖”を俯瞰し、より良いコーディングに繋げるきっかけになります。コードレビューで出会う小さな違和感を見逃さず、自分のロジックの棚卸しをしてみるのはいかがでしょうか。

今後は、より柔軟に構成できる存在確認処理のユーティリティ化（例：存在＋中身＋更新日時）も視野に入れつつ、チーム内での共通ルール作成にも活かせるでしょう。
[25卒]　AWS：CLF　新人エンジニアが9日（総学習時間17時間）で合格してみた話



## はじめに
はじめまして！新人エンジニアのyukiと申します。  
文系かつIT知識に乏しい自分がAWS Certified Cloud Practitionerを9日（総学習時間17時間）で取得したので、どのように勉強したのかをシェアしようと思っています！

こんな人にこの記事はおすすめです:

- CLF資格を短い期間でとりたい！
- 資格を取るだけじゃなくてAWSのおおざっぱな理解をしておきたい！
- 資格勉強とか右も左もわからない！

## 受験しようと思ったきっかけ
~~ぶっちゃけ資格とってほめられたかったから、12冠って響きだけに惹かれた~~  
AWSが入社した会社で使われていて会話についてけなさそうだったから。  
つまるところ、社内のクラウドの会話でところどころ自分がナニソレオイシイノ状態になっているのが嫌だったという理由です。

## やったこと一覧＋α

### 1. 目的の設定
正直ここが一番重要です。目的にあった計画があるはずなので・・・

~~・9日という短い時間で取ってドヤ顔をする~~  
- AWS関連の会話についていけるようになる  
  　先述の通り
- AWSのほかの資格を取る踏み台にする  
  　どうせなら12冠！
- 自分の市場価値をあげるため

### 2. 計画

#### 前提

自分の目的はただ資格を取るではなくAWSについてある程度「理解」をする必要があるため、
資格を取る最短方法の問題集だけ解いちゃう！という方法は採用せず。
問題集だけ解くと、いわゆるこのキーワードはこのサービス！って感じで紐づけられて、キーワードとサービスの中身を理解しないまま問題だけが解けるようになる不思議な現象が起こる・・・（TransformerでいうAttentionみたいな感じ？笑）

自分は資格勉強の右も左もわからなかったので、CLF持っている先輩に自分の目的コミコミで計画を一緒に立ててもらいました。そこで参考教材のおすすめももらってきた感じです。

#### 計画内容と実際にかかった時間

試験日程は土日がいいなと思ってたので来週の土曜受けるって決めて勉強を始めました。（勉強を始めたのは金曜日でした）

なお自分のモチベ、体力的に勉強は1日2時間が限度だろうなって思ってました。（勉強時間がゼロの日もありました）
仕事が終わってからの勉強ってキツイですよね。


1. 3日：[教科書](#教科書)読む（5時間）
2. 3日：[Udemy](#問題集)の390問を解く×2周（解く時間6時間＋直し、[教科書](#教科書)の確認4時間)
3. 3日：[Cloud License](#問題集)の本試験モード×2周(解く時間1時間＋直し1時間）

なお後ほど良し悪しについて語りますが、Cloud Licenseは3か月で4000円は最低でかかります。自分は落ちたら受験料15000円無駄になるしと思って課金しました。

### 3. 参考書ざっと1周で気を付けたこと
ここでは「理解」をすることに重点をおきました。

まず理解をしたいなって考えていたので、3日でざっと1周しました。ただわからないカタカナ、概念が多かったので（疎結合ってなんやねんみたいな？）その都度調べてメモって「理解」をすることに重点をおきました。

また各サービスがどのように違うか言語化ができているか章ごとに確かめていました。（サービスの内容の違いを壁に向かって説明してみる）
これをすることで「理解」しているかどうかを計りました。

### 4. 問題集と直しで気を付けたこと
ここでは「覚える」ことに重点をおきました。

問題を解きながらわからないサービス、概念はすべてメモってました。
間違えた問題は理解ができていないところ、覚えていないところはどこなのかを示してくれるので、理解ができて覚えるまで解きなおしをしました。

### 5. Cloud Licenseについて
最後に自分がどれくらい本試験で取れそうかという目的で主に使用しました。  
Cloud Licenseの良い点、悪い点

- 良い点
  - 実際に出る問題とほぼ同じ
  - ほとんど本試験の点数と同じような結果が出た
  - Udemyと同じくではあるが解説がある
- 悪い点
  - 3か月で4000円は最低でかかる（渋い）
  - なくてもUdemy自体で合格可能だと感じた。

## まとめ

自分の目的にあった資格勉強をしましょう。  
計画については経験者の方に相談すると力になってくれます！  
この場を借りて自分に情報をくださった、相談してくれた先輩方にお礼申し上げます。  
本記事がどなたかの参考になれば幸いです。

## 参考教材一覧

### 教科書
  - [緑本って呼ばれているやつ](https://www.amazon.co.jp/AWS%E8%AA%8D%E5%AE%9A%E8%B3%87%E6%A0%BC%E8%A9%A6%E9%A8%93%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88-AWS%E8%AA%8D%E5%AE%9A-%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%89%E3%83%97%E3%83%A9%E3%82%AF%E3%83%86%E3%82%A3%E3%82%B7%E3%83%A7%E3%83%8A%E3%83%BC-%E6%94%B9%E8%A8%82%E7%AC%AC3%E7%89%88-%EF%BC%A1%EF%BC%B7%EF%BC%B3%E8%AA%8D%E5%AE%9A%E8%B3%87%E6%A0%BC%E8%A9%A6%E9%A8%93%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88-%E5%B1%B1%E4%B8%8B%E5%85%89%E6%B4%8B/dp/4815625387/)
### 問題集
  #### Udemy
  - [Udemyの問題集](https://works-hijp.udemy.com/course/aws-4260/learn/quiz/4766842/results?expanded=1603576885#overview)
  #### Cloud License
  - [Cloud License（課金）](https://cloud-license.com/)
IaCの観点から学ぶDockerの基礎

<h2>導入（読者の共感・問題提起）</h2>
<p>Dockerを使い始めて1〜3年の皆さん、こんな経験ありませんか？「Dockerイメージを手動でビルド・起動するのは良いけれど、環境構成の再現性が怪しい」「IaCを学びたいけどTerraformやAnsibleへの移行が大変」「CI/CDの中でDocker周りをどう管理すれば安全か・効率的か分からない」——これらはまさに実務でぶつかる壁です。本記事では<strong>IaCの観点</strong>からDockerの基礎を振り返りつつ、実務に使えるヒントや失敗回避の知見を体系的にまとめます。</p>

<h3>背景や技術の概要（公式情報や社会背景）</h3>
<p>まず、IaC（Infrastructure as Code）はインフラ構成をコードとして置き、AWSやGCPなどで再現性のある環境を構築・管理する手法です 。Dockerfileやdocker-compose.ymlも広義ではIaCの一部です 。</p>
<p>近年、DockerはTerraform、Ansible、KubernetesなどのIaCツールと密に連携され、開発から本番運用まで一貫した自動化が主流になっています</p>
<p>また最近は「docker run」からCloudFormation・HelmチャートなどのIaCフォーマットに自動変換する試みも増えており、運用効率の次なるステージに入っています</p>

<h3>具体的な課題・エラー</h3>
<ul>
<li><strong>再現性の欠如</strong>：DockerfileやComposeファイルを書いても微妙に環境差異が出やすく、#“it works on my machine”問題につながりやすい</li>
<li><strong>ファイルの肥大化</strong>：Dockerfileが成長すると、イメージサイズやビルド時間が増加し、保守が難しくなる傾向</li>
<li><span style="color:red;">セキュリティリスク</span>：ベースイメージの脆弱性対策や誤認証構成の見落としなどが多く、Clairなどでのスキャンが現実的な対策です</li>
<li><strong>IaCとの統合の複雑さ</strong>：TerraformとDocker連携時、State管理やボリューム・ネットワークのマッピングなど細かい調整が必要</li>
</ul>

<h3>解決策とコード例</h3>
<pre><code>FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --production
COPY . .
CMD ["node", "index.js"]</code></pre>
<p>① **マルチステージビルド**でサイズとビルド時間を最適化<br>
② **FROM固定＋タグ指定**で再現性を担保<br>
③ **スキャン付きCIパイプライン**でセキュリティ担保<br>
④ Terraform連携例：</p>
<pre><code>provider "docker" {
  host = "tcp://your-docker-host:2375"
}

resource "docker_image" "app" {
  name = "myapp:latest"
}

resource "docker_container" "app" {
  image = docker_image.app.image_id
  ports {
    internal = 3000
    external = 3000
  }
}</code></pre>
<p>⑤さらに、「docker run」→CloudFormation／Helm変換ツール（例：awesome-docker-run）をCIで自動化 </p>

<h3>ベストプラクティス・運用上の注意</h3>
<ul>
<li><strong>Dockerfileリファクタリング自動化</strong>：リファクタリングでイメージサイズ32％削減、ビルド時間6％短縮の報告あり</li>
<li><strong>モノリシックな構成を避ける</strong>：Terraform側ではモジュール分割し、小さく保つことが推奨されます</li>
<li><strong>セキュリティゲートの導入</strong>：IaCスクリプトに対して静的分析（terraform with checkov やClair）を組み込み、誤構成や脆弱性を防ぐ</li>
<li><strong>CI/CDに「Docker＋IaC」パイプラインを整合させる</strong>：DockerイメージとTerraform/Pulumi構成は同一リポジトリ・同一パイプライン管理が現代的。</li>
</ul>

<h3>まとめと今後の展望</h3>
<p>本記事では、IaCの視点から<strong>Dockerの基礎</strong>を整理し、実務で使えるノウハウを解説しました。次の進化として、以下の3点が重要です：</p>
<ol>
<li>「docker run」ベースのIaC自動変換ツール活用とCI連携</li>
<li>Dockerfileの品質向上（自動リファクタリング）による運用効率化</li>
<li>静的コード／セキュリティ分析を組み合わせた堅牢なDocker＋IaC運用</li>
</ol>
<p>1〜3年目エンジニアの皆さんにとって、これらは今後のスキルアップにもつながる取り組みです。ぜひ日々の開発環境やCI/CDに積極的に取り入れて、実践的な成長を続けてください。</p>

<h3>参考リンク</h3>
<ul>
<li>Terraform × Docker連携サンプル</li>
<li>awesome-docker-run（docker→IaC変換ツール）</li>
<li>Dockerfile自動リファクタリング研究</li>
<li>セキュリティチェック（Clair/Checkovなど</li>
</ul>
HP Wolf Security が Windows Updateを阻害

HP ProBook の標準アプリ HP Wolf Securityがupdateしたことにより、Windows Updateを検出しない事象が発生したので記録します。（2025/6/16）


### 状況
- HP ProBook 450 G9 3台全て
- 2025/4中旬以降からWindows Updateが適用されていない（更新をしてもみつからない）
- プログラムと機能を見たところ、4/16頃インスールで、HP Wolf Security がある
- アンチウィルスソフトで、Apex Oneが入っている
- Windows 11 Pro 24H2


HP Wolf Securityを試しにアンインストールしたところ、Windows Updateの更新プログラムチェックが更新を検出するようになり、更新プログラムの適用ができるようになった。


従来から入って動作はしていたはずだが、4月中旬ごろのHP Wolf Securityにより、それ以降のWindows Updateの更新が阻害されていた。
JetBrainsがKotlinでAIエージェントを構築できる「Koog」を発表

![ChatGPT Image 2025年6月16日 12_26_30.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3978583/bacbfc95-d5da-4b3c-b6a8-4c7bfea1b7b2.png)


## JetBrainsがKotlin開発者向けのAIエージェントフレームワーク「Koog」を発表

どうも、Jetbrains公式代理店NATTOSYSTEMの私です。

2025年5月、JetBrainsはKotlinConfにてKotlin開発者向けのAIエージェントフレームワーク「Koog」を発表しました。  
この記事では、Koogの特徴や使い方についてまとめました。

---

## Koogとは？

Koogは、JetBrainsが開発したKotlin製のAIエージェントフレームワークです。  
既存のPython中心のAIフレームワークとは異なり、Kotlinネイティブで動作し、完全にJVMエコシステムに統合されています。


---

## Kotlin製のAIエージェントフレームワークとは？

Kotlin製のAIエージェントフレームワークとは、Kotlin言語で構築・制御できるAIエージェント開発基盤のことを指します。

AIエージェントとは、特定の目標に向かって、入力を理解し、ツールを使い、適切なアクションを選択・実行する自律的なソフトウェアのことです。

その開発をKotlinで行えるようにしたフレームワークには、以下のような特徴があります：

- Kotlin DSLで思考・行動・目標を記述できる
- JVMエコシステムとの親和性が高く、JavaやSpringとも連携しやすい
- LLM（大規模言語モデル）や外部ツールとの統合が可能
- JetBrainsのIDEなどとの相性が非常に良い

これまでAIエージェント開発といえばPython一強でしたが、Kotlin製のフレームワークが登場したことで、モバイルやJVMサーバー領域でもAIの活用が広がる可能性があります。

---
## Koogの主な特徴

| 特徴 | 内容 |
|------|------|
| Kotlinで完結 | JVM上でネイティブに動作。外部サービス不要。 |
| モジュール式機能 | エージェントのスキルや思考方法を柔軟に追加可能。 |
| ツール統合 | API呼び出し、ファイルアクセス、独自ツールとの統合が可能。 |
| トレーシング機能 | LLMの呼び出しやツール利用の履歴を詳細に追跡。 |
| ワークフロー定義 | 複雑なフローもKotlin DSLで簡単記述。 |

---

## Koogのはじめ方

Koogはオープンソースで提供されており、以下のGitHubから使えます：

https://github.com/JetBrains/koog

JetBrainsによるQuick Startガイドも非常に充実しており、環境構築から最初のエージェント作成までスムーズに進められます。


---

## 今後の展望とコミュニティ

Koogはまだ発展途上ですが、JetBrainsが積極的に開発を進めており、今後以下のような機能強化が期待されています。

- 複数エージェントの連携
- UI統合機能（JetBrains IDEとの連携）
- より高度な履歴圧縮・プロンプト最適化

---

## まとめ

Kotlin開発者にとって、KoogはまさにAIエージェント開発の扉を開く新たな武器です。  
今後のAI×Kotlinの展開が非常に楽しみですね。


---

## 参考リンク

- JetBrains公式ブログ記事: [Meet Koog: Empowering Kotlin Developers to Build AI Agents](https://blog.jetbrains.com/ai/2025/05/meet-koog-empowering-kotlin-developers-to-build-ai-agents/)
- GitHub: [JetBrains/koog](https://github.com/JetBrains/koog)

##  JetBrains製品の最新情報をXでチェック！

JetBrains製品に関する最新情報や、展示会での様子は随時公式Xでも発信予定です。

 **公式X - [Nattosystem](https://x.com/nattosystem)**  



---

> 📝 この記事は一部AIによって要約・編集されたものです。
【iOS個人開発備忘録】Xcode × Source Tree 環境構築

# 準備
## 必要なアカウント
- **Apple Account**
- **GitHub**

## インストールと初期設定
基本的には最初の1度だけ。
アカウント、トークン等に更新があれば再度設定。

- **homebrew**：[参考](https://www.kikagaku.co.jp/kikagaku-blog/homebrew-install-howto/)
    1. インストールコマンド(要パスワード)
    1. pathを通すコマンド
    1. `brew help`でインストールを確認
- **Xcode**：App Storeまたは「Xcodes」から
    - `Xcode > Settings... > Accounts`からApple Accountを連携
    - 上と同じ画面からGitHubを連携
    - `Xcode > Settings... > Source Control`から名前(コミット時の表示)とEメールを入力
- **Source Tree**：[参考](https://qiita.com/suzutatsu/items/817f58cfb6e69f56d134)
    - GitHubアカウントをPersonal Access Token,プロトコルHTTPSで連携：[参考1](https://qiita.com/RyutoYoda/items/c6908025c0aef4b35cdd),[参考2](https://qiita.com/naente/items/d66fe1ae2b6e70acd38c)

# つくる
新しいアプリ(プロジェクト)をつくるたびに実行。

1. `Create New Project...`から進めていき、`Create Git repository on my Mac`にチェック。
(プロジェクトと同時にローカルリポジトリが作られる)
![スクリーンショット 2025-06-16 11.55.57.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3552658/c86e70af-ebb0-48d6-b238-3f1f5ceeddc8.png)
1. Source Treeでローカルリポジトリを読み込む
1. ナビゲーターエリアのソースコントロールナビから`Repositories > Remotesを右クリックし > New”プロジェクト名”Remote…`を選択。(リモートリポジトリが作られる)

これで差分が管理されるようになるので、必要に応じて
- ブランチ作成
- コミット
- プッシュ

https://kaiyou9.com/xcode-git/

# リリースする
準備中
DockerでSpring Bootをコンテナ化しaws ECR・ECSを利用しデプロイ part 1

## 目次
1. Spring Boot プロジェクト作成
   - Spring InitializrやIDEで基本プロジェクトを作る。
2. アプリをローカルで動かす
    - Spring Bootがちゃんと起動するか確認。
3. Dockerfile を作成
    - Spring Bootアプリをコンテナ化するための設定を書く。
4. Dockerイメージをビルド＆ローカルで動作確認
    - docker build と docker run で動くかテスト。
5. 必要なら docker-compose.yml 作成
    - 複数コンテナや連携を扱いたい場合。

## Spring Bootでプロジェクト作成
* https://start.spring.io/にアクセス
* Project:Maven
* Language:Java
* Spring Bootバージョンは最新安定板推奨（例：3.x系）
* Group:com.example
* Artifact:demo
* Dependenciesに「Spring Webを追加」（API用）
* 「Generate」を押してzipをダウンロード、展開する

## ローカルで起動確認
```bash
./mvnw spring-boot:run
```
* ブラウザでhttp://localhost:8080にアクセスし、４０４でなければ起動は成功。

## Dockerfileを作成
```dockerfile
# 1. ベースイメージは OpenJDK 17 のJRE（軽量版）
FROM eclipse-temurin:17-jre-jammy

# 2. 作業ディレクトリを作る
WORKDIR /app

# 3. ビルド済みのjarファイルをコンテナにコピー
COPY target/demo-0.0.1-SNAPSHOT.jar app.jar

# 4. ポート8080を開放
EXPOSE 8080

# 5. アプリを起動するコマンド
ENTRYPOINT ["java","-jar","app.jar"]
```

### 作成手順
1. Spring Bootプロジェクトのルートで./mvnw package を実行してjarファイルを作成。
    - target/demo-0.0.1-SNAPSHOT.jarが生成される
2. プロジェクトルートの上にDockerfileを作成
3. Dockerイメージをビルドする
```bash
docker build -t springboot-demo .
```
4. ローカルでコンテナを起動する
```bash
docker run -p 8080:8080 springboot-demo
```
* ブラウザで http://localhost:8080 にアクセスして、APIや画面が動くか確認しよう！
### ルートに一工夫したいい場合は：プロジェクト名\demo\src\main\java\com\example\demo\DemoApplication.javaを修正
```java
package com.example.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController; 

@SpringBootApplication
@RestController
public class DemoApplication {

	public static void main(String[] args) {
		SpringApplication.run(DemoApplication.class, args);
	}

	@RequestMapping("/")
	public String hello(){
		return "<h1>Hello Spring Boot!!!!!</h1>";
	} 

}
```
`Hello Spring Boot!!!!!と表示`

## 必要なら docker-compose.yml 作成
### コンテナをまとめて動かしたい場合や複数のコンテナを管理する場合は利用を推奨する。
```DockerCompose
services:
  web:
    image: openjdk:17
    container_name: spring_container
    command : ./mvnw spring-boot:run
    ports:
      - "8080:8080"
    volumes:
      - ./demo:/demo
    working_dir: /demo
```
#### part2は後日掲載します