## はじめに
この記事では、Stable Diffusion 3 medium モデルを Google Colab で実装する手順を解説しています。

## 開発環境
Google Colab （L4GPU、A100GPU）

## ライブラリのインストール
```python
!pip install --upgrade diffusers[torch]
```

## コードの実行

### 1. Hugging Face へログイン
```python
from huggingface_hub import login
login()
```

### 2. Stable Diffusion 3 medium の読み込み
#### **つまづいた箇所**
- Hugging Face トークンの権限が write になっていないため、エラー
→ Hugging Face トークンの権限が write にすること
- local_files_only がデフォルトで True になっているため、モデルのダウンロード時にエラー
→ local_files_only=False で解決
```python
import torch
from diffusers import StableDiffusion3Pipeline

HF_TOKEN = "あなたのHuggingFaceトークン"

pipe = StableDiffusion3Pipeline.from_pretrained(
    "stabilityai/stable-diffusion-3-medium-diffusers",
    torch_dtype=torch.float16,
    use_auth_token=HF_TOKEN,
    local_files_only=False
)

pipe = pipe.to("cuda")
```

### 3. 画像を生成する
```python
image = pipe(
    "Top quality, 1 beautiful woman, long Hair, brown hair, wearing Camisole & skirt, shy-smile, Sunlight, at street",
    negative_prompt="",
    num_inference_steps=84,
    guidance_scale=7.0,
).images[0]

image
```

### 4. 参考
- [https://huggingface.co/stabilityai/stable-diffusion-3-medium-diffusers](https://huggingface.co/stabilityai/stable-diffusion-3-medium-diffusers)

### おわりに
- GPUメモリが21GBに張り付いていたので、GPUメモリ25GB以上ほしい。
- HuggingFaceトークンの権限管理が豊富に出来るようで勉強になった。

GoogleColabでStableDiffusion3mediumを実装する

20240615

GoogleColabでStableDiffusion3mediumを実装してみた

## この記事で分かること
プロンプトを自動で推敲するGPTsを作成する過程で考えたことなどを共有したいと思います。

思いのままにプロンプトを打ち込んでも希望の出力されなかったり、どのようにプロンプトを改善すれば良いのかを悩む方への参考になればと思います。

## 思いのままに書いたプロンプト（Before）
```
Next.js で開発した Webサイト を netlify サーバーに github を連携してサイト公開したい。
```

## 思いのままに書いたプロンプト（After）
```
Next.jsで開発したWebサイトをNetlifyサーバーにGitHubを連携して公開する手順を教えてください。
1. GitHubリポジトリの作成とプロジェクトのプッシュ方法。
2. Netlifyアカウントの作成とGitHubリポジトリとの連携方法。
3. Netlifyでのビルドコマンドや公開ディレクトリの設定、必要な環境変数の追加方法。
```

## GPTsプロンプト
```
# 役割
- あなたは世界最高のコンサルタントです

# システム指示
- 解説は不要です

# 思考支援フレームワーク
ポール＝エルダーのクリティカルシンキングフレームワーク

# 指示
- 下記のフォーマットを生成してください
- 質問内容（指示：思考支援フレームワークを適用し不十分な点や記載が必要な箇所を明確にする）
- {{質問内容}}の回答（指示：ラディカルシンキングでアイデアをふくらませて３個提案する）
- {{質問内容の回答}}に対する回答（指示：より具体的な３個の回答を行う）
- {{質問内容の回答に対する回答}}を適用したプロンプトの提案（指示：日本語のプロンプトを markdown形式で出力して下さい）
```

## GPTsプロンプト解説

1. 作成したプロンプト自動推敲の仕組み  
→ 「思考支援フレームワーク」を活用する

2. 思考の過程で不明な点・補足箇所などを洗い出す  
→ 「ラディカルシンキングでアイデアをふくらませて」とお願いする

3. 水平思考で不明な点・補足箇所を複数考えてもらう  
→ 多角的な視点で洗い出すことで思考のブレを防ぐ

4. 多段階の質問応答  
→ 前段で生成した内容に解答することでより内容をブラッシュアップする

5. MarkDown形式での出力  
→ そのままプロンプトとして扱えるようにする

## ベストプラクティス
出力されたプロンプトを再度入力に使用してみる（より洗練される）

## 学んだこと
思考支援フレームワークにはロジカル・ラディカル・クリティカルのような分類があること

## おわりに
思考支援フレームワークを活用して思考の道筋を指摘したり、思考を拡散させるのは楽しい。

プロンプト自動推敲

GPTｓでプロンプトを洗練させる！自動でプロンプトを推敲させてみた。

## はじめに
Next.js でサイトマップを自動作成するための手順を解説します。

## ライブラリのインストール

next-sitemap というライブラリをインストールする

```bash
# npm の場合
npm install --save-dev next-sitemap
```

## next-sitemap.config.js の作成

next-sitemap.config.js を作成して、下記のコードを記述する

```js
/** @type {import('next-sitemap').IConfig} */

module.exports = {
    siteUrl: process.env.SITE_URL || 'https://example.com',
    generateIndexSitemap: false,
    generateRobotsTxt: true,
    sitemapSize: 7000,
  }
```
- siteUrl: .envに記述したWebサイトURLを読み込む
- generateIndexSitemap: インデックスサイトマップの自動生成（個人サイト用なので無効にします）
- generateRobotsTxt: robots.txs の自動生成
- sitemapSize: 指定した数値（7000）を超えると、インデックス（sitemap.xml）とサイトマップファイル（sitemap-0.xml など）が生成されます。

## .env ファイルの更新

.env ファイルに下記の内容を追記する

```
SITE_URL='登録したいサイトURL'
```

## package.json ファイルの更新

package.json に下記の内容を追記する

```json
  "scripts": {
    "postbuild": "next-sitemap --config next-sitemap.config.js",
  },
```

## スクリプトの実行

スクリプトコマンドを実行する

```bash
npm run build
```

public 配下に sitemap.xml や robots.txt が自動生成されます。

## おわりに
非常に簡単にサイトマップを作成することができる便利なライブラリの使い方について解説しました。next-sitemap.config.jsで細かな設定が出来るようなので、見てみようと思います。

## 参考
- [https://osgsm.io/posts/next-sitemap](https://osgsm.io/posts/next-sitemap)
- [https://fwywd.com/tech/next-sitemap](https://fwywd.com/tech/next-sitemap)
- [https://chocolat5.com/tips/nextjs-sitemap-google-console/](https://chocolat5.com/tips/nextjs-sitemap-google-console/)

Next.jsのサイトマップ自動生成

Next.jsでサイトマップを自動生成するライブラリnext-sitemapを試してみた！

## はじめに
typescript の関数宣言とアロー関数の違いについて触れる機会があったため、まとめてみました。

## 関数宣言
```ts
function greet(name?: string): string {
  return Hello, ${name};
}
```
functionで関数宣言しているため、pythonに慣れているエンジニアからすると、分かりやすい。

## アロー関数
```ts
const greet = (name?: string): string => {
  return Hello, ${name};
}
```
ぱっと見でtypescriptに見慣れていないエンジニアからすると？が生まれる。

## 関数宣言とアロー関数の違い

### **関数宣言**
> 関数名をスコープ内で一意の識別子として使用できます。

#### どんな恩恵があるのか？
```ts
function greet(name: string): string {
  return `Hello, ${name}!`;
}

function greet(age: number): string { // エラー！ 関数名が重複しています
  return `You are ${age} years old.`;
}

console.log(greet("Alice")); // "Hello, Alice!"
```

このコードで実行すると、関数名が重複しているためエラーが出る。

### **アロー関数**
> スコープ内で関数名を一意の識別子として使用できない。

#### どんな恩恵があるのか？
```ts
const greet = (name: string): string => {
  return `Hello, ${name}!`;
};

const greet = (age: number): string => { // エラー！ 関数名が重複しています
  return `You are ${age} years old.`;
};

console.log(greet("Alice")); // エラー！ greet は既に定義されています
```

こちらのコードも重複でエラーが出る。

## 関数宣言の課題

> 意図しない動作
> 同じ名前の関数が複数存在すると、意図しない動作が発生する可能性があります。

```ts
function greet(name: string): string {
  return `Hello, ${name}!`;
}

let greet = "こんにちは"; // 変数 greet が定義されました

console.log(greet("Alice")); // "こんにちは" と出力される
```

どちらも重複によるエラーが発生するが、関数宣言では関数名と変数名が同一である場合に意図しない動作が発生する。サンプルプログラムだと、はじめに定義したgreetが後に記述しているgreetで変数の書き換えが行われている。

アロー関数は、変数定義をconstにすることで変数の書き換えが出来ないので、今回のような意図しない動作が発生しない。

## まとめ
可読性の観点からだと関数宣言を優先したくなる。
コードが複雑だったり膨大になったときにはアロー関数のほうを採用しようと思う。

関数宣言とアロー関数

【初学者必見】Typescriptの関数宣言とアロー関数って何が違うの？

## はじめに

以下のチェックリストは、コードレビューの際に考慮すべき観点をまとめてみました！  

各項目は具体な質問や確認ポイントと共に説明しており、レビューの質向上に役立てください！

### 1. 機能性
* **仕様との整合性**
    * 設計書や要件定義書に基づいて、実装されている機能が正しく動作するかを確認する。
    * 機能の抜け漏れや誤動作がないか確認する。
    * ユーザーストーリーやユースケースに基づいて、期待通りの動作になっているか確認する。
    * エッジケースや異常系を含めた、あらゆるケースで期待通りの動作をしているか確認する。
* **既存機能への影響**
    * 今回の変更によって、既存の機能が意図せず影響を受けていないか確認する。
    * 回帰テストを実施し、既存の機能が正しく動作していることを確認する。
    * 変更によってパフォーマンスやセキュリティに影響がないか確認する。
* **ユーザーフレンドリーな設計**
    * ユーザーが直感的に理解し、使いやすいインターフェースになっているか確認する。
    * ユーザーエクスペリエンス（UX）を考慮した設計になっているか確認する。
    * ユーザーにとってわかりやすく、誤解のないメッセージが表示されているか確認する。
* **エラーハンドリング**
    * 適切なエラーハンドリングが実装されているか確認する。
    * 例外処理が適切に行われているか確認する。
    * エラーメッセージがわかりやすく、ユーザーにとって親切な内容になっているか確認する。
    * エラー発生時のログ出力は適切か確認する。
    * ログ出力は個人情報や機密情報を含むものではないか確認する。

### 2. 可読性
* **命名規則**
    * ファイル名、変数名、関数名、クラス名などが、その要素が表現する目的や機能を明確にかつ正確に説明しているか。
    * ファイル名、変数名、関数名、クラス名などに、略語や省略形が含まれていないか。
    * 命名規則が統一されているか確認する。
    * 変数名、関数名、クラス名などが、意味が分かりやすく、読みやすいものになっているか。
* **コードのフォーマット**
    * インデント、空白、改行などが統一されているか確認する。
    * コーディング規約に従っているか確認する。
    * コードの整形ツールを利用して、コードの可読性を向上させているか確認する。
* **コメント**
    * コメントが適切に記述されているか確認する。
    * コメントが最新の状態に保たれているか確認する。
    * コードの内容を理解するために必要なコメントが記述されているか確認する。
    * 不要なコメントは削除されているか確認する。
    * コードとコメントの内容が一致しているか確認する。
* **コードの複雑さ**
    * コードのネストが深すぎないか確認する。
    * メソッドや関数が長すぎないか確認する。
    * 複雑な条件式が使用されていないか確認する。
    * コードの複雑さを軽減するための工夫が施されているか確認する。
* **コードの重複**
    * 同じようなコードが複数箇所で記述されていないか確認する。
    * コードの重複を解消するための工夫が施されているか確認する。
### 3. 保守性
* **モジュール化**
    * コードが適切にモジュール化されているか確認する。
    * モジュールの粒度が適切か確認する。
    * モジュール間の依存関係が適切に管理されているか確認する。
    * モジュール間の結合度が低く、疎結合になっているか確認する。
* **単一責任の原則**
    * クラスや関数、コンポーネントにおいて知識や責任が単一となっているか確認する。
    * クラスや関数、コンポーネントの名前が責務に適合しているか確認する。
* **変更への対応**
    * コードを変更しやすい設計になっているか確認する。
    * 変更が他の部分に影響を与えないように、適切な設計がされているか確認する。
    * 変更の影響範囲を最小限に抑えるための工夫が施されているか確認する。
* **テストコード**
    * 適切なテストコードが書かれているか確認する。
    * テストコードの網羅率が適切か確認する。
    * テストコードが最新の状態に保たれているか確認する。
    * テストコードが読みやすく、理解しやすいものになっているか確認する。
    * テストコードが適切に実行されているか確認する。
* **ドキュメント**
    * コードに関するドキュメントが適切に作成されているか確認する。
    * ドキュメントの内容が最新の状態に保たれているか確認する。
    * ドキュメントが読みやすく、理解しやすいものになっているか確認する。
    * ドキュメントがコードの内容を正確に反映しているか確認する。
### 4. パフォーマンス
* **実行速度**
    * コードの実行速度が適切か確認する。
    * 不要な処理やループがないか確認する。
    * データベースへのアクセス回数を最小限に抑えるための工夫が施されているか確認する。
    * キャッシュなどを利用して、パフォーマンスを向上させているか確認する。
* **メモリ使用量**
    * コードがメモリを大量に消費していないか確認する。
    * メモリリークが発生していないか確認する。
    * メモリ使用量を削減するための工夫が施されているか確認する。
* **ネットワーク通信**
    * ネットワーク通信の回数を最小限に抑えるための工夫が施されているか確認する。
    * ネットワーク通信の負荷を軽減するための工夫が施されているか確認する。
    * 通信量を削減するための工夫が施されているか確認する。
* **最適化**
    * 適切な最適化が施されているか確認する。
    * 非効率なコードが使用されていないか確認する。
    * パフォーマンスを向上させるための工夫が施されているか確認する。
### 5. セキュリティ
* **入力値の検証**
    * 入力値の検証が適切に行われているか確認する。
    * 入力値の型、長さ、範囲などが適切にチェックされているか確認する。
    * 入力値が不正な場合の処理が適切か確認する。
    * クロスサイトスクリプティング（XSS）対策が施されているか確認する。
    * SQLインジェクション対策が施されているか確認する。
* **出力値のエンコード**
    * 出力値のエンコードが適切に行われているか確認する。
    * 出力値に含まれる特殊文字が適切にエスケープされているか確認する。
    * クロスサイトスクリプティング（XSS）対策が施されているか確認する。
* **認証・認可**
    * 認証・認可が適切に行われているか確認する。
    * 権限のないユーザーがアクセスできないように、適切な対策が施されているか確認する。
    * セキュリティ上の脆弱性を発見するためのテストを実施しているか確認する。
* **セキュリティ対策**
    * セキュリティ対策が適切に施されているか確認する。
    * セキュリティに関するベストプラクティスに従っているか確認する。
    * セキュリティに関する最新の脅威情報に注意し、必要な対策を講じているか確認する。
### 6. 命名規則
* **命名規則**
    * ファイル名、変数名、関数名、クラス名などが、その要素が表現する目的や機能を明確にかつ正確に説明しているか。
    * ファイル名、変数名、関数名、クラス名などに、略語や省略形が含まれていないか。
    * 命名規則が統一されているか確認する。
    * 変数名、関数名、クラス名などが、意味が分かりやすく、読みやすいものになっているか。
    * 命名規則がチーム内で共有されているか確認する。
### 7. モジュール化
* **モジュールの粒度**
    * モジュールの粒度が適切か確認する。
    * モジュールが適切な機能に分割されているか確認する。
    * モジュールが小さすぎたり、大きすぎたりしていないか確認する。
* **モジュール間の依存関係**
    * モジュール間の依存関係が適切に管理されているか確認する。
    * モジュール間の結合度が低く、疎結合になっているか確認する。
    * サイクル依存が発生していないか確認する。
* **モジュール再利用性**
    * モジュールが再利用しやすい設計になっているか確認する。
    * モジュールが汎用性が高く、他のプロジェクトでも利用できるか確認する。
    * モジュールが独立して開発・テストできるようになっているか確認する。
### 8. テスト
* **テストの網羅率**
    * テストコードの網羅率が適切か確認する。
    * すべての機能を網羅するテストコードが書かれているか確認する。
    * 特に、エッジケースや異常系を含むテストコードが書かれているか確認する。
* **テストの品質**
    * テストコードが正しく動作しているか確認する。
    * テストコードが読みやすく、理解しやすいものになっているか確認する。
    * テストコードが適切に実行されているか確認する。
* **テストの効率性**
    * テストが素早く実行できるようになっているか確認する。
    * テストが独立して実行できるようになっているか確認する。
    * テストが自動化されているか確認する。
* **テストのメンテナンス性**
    * テストコードが変更しやすい設計になっているか確認する。
    * テストコードが最新の状態に保たれているか確認する。
    * テストコードがコードの変更に追従できるようになっているか確認する。
### 9. ログ
* **ログのレベル**
    * ログのレベルが適切に設定されているか確認する。
    * デバッグログは開発環境でのみ出力されるように設定されているか確認する。
    * ログレベルは、開発・運用環境によって適切に変更されているか確認する。
* **ログの内容**
    * ログの内容が適切か確認する。
    * ログに個人情報や機密情報が含まれていないか確認する。
    * ログに問題解決に必要な情報が記録されているか確認する。
* **ログの出力先**
    * ログの出力先が適切か確認する。
    * ログが適切な場所に記録されているか確認する。
    * ログの出力先がセキュリティ対策が施されているか確認する。
* **ログのローテーション**
    * ログのローテーションが適切に行われているか確認する。
    * ログファイルが大きくなりすぎないように、適切なローテーションが設定されているか確認する。
    * ログファイルのバックアップが適切に行われているか確認する。
### 10. その他
* **セキュリティ対策**
    * クロスサイトスクリプティング（XSS）対策が施されているか確認する。
    * SQLインジェクション対策が施されているか確認する。
    * セキュリティに関するベストプラクティスに従っているか確認する。
* **アクセシビリティ**
    * コードがアクセシビリティのガイドラインに従っているか確認する。
    * 視覚障碍者や聴覚障碍者など、すべての人が利用できるようになっているか確認する。
* **国際化**
    * コードが国際化に対応しているか確認する。
    * 複数の言語に対応できるように設計されているか確認する。
    * 言語設定が適切に反映されているか確認する。
* **パフォーマンスチューニング**
    * コードのパフォーマンスをチューニングする必要があるか確認する。
    * パフォーマンスに関する問題点があれば、適切な解決策を提案する。
    * パフォーマンスを測定するためのツールを利用しているか確認する。
* **コードレビューの文化**
    * チーム内でコードレビューが習慣化されているか確認する。
    * コードレビューの目的や重要性をチームメンバー全員が理解しているか確認する。
    * コードレビューのフィードバックが適切に受け入れられているか確認する。
### 注意点
* プロジェクトやチームの状況に合わせて、必要な項目を追加したり削除したりしてください！
* チェックリストに書かれている項目をすべて満たす必要はありません。状況に応じて、優先順位を付けてチェック項目を選択してください！

## まとめ
上記のチェックリストを活用することで、コードの品質向上に役立ちます。また、コードレビューを通して、チム全体のスキル向上や知識共有にも繋がります。継続的にコードレビューを行い、高品質なコードを開発することを目指してみてください！

デバッグとドリップコーヒー

Debug & Drip Coffee