OmniAICreator/Qiita-1.07M huggingface dataset:
JavaScriptにおけるユーティリティ設計：再発明を避ける構造・抽象化戦略・依存ライブラリとのバランス

## 概要

ユーティリティとは「便利な関数」ではない。  
それは**再利用される前提で、構造的に責任を持たされた小さな設計単位**である。  
本稿では、ユーティリティ関数/モジュールを「共通化」「抽象化」「責務明示」の3軸で再定義し、**合理的かつ破綻しない共通機能の構築法**を解説する。

---

## 1. ユーティリティを再定義する

```js
// ❌ なんでも入る「utils.js」
export function doSomething() { ... }
export function isOk() { ... }
```

→ ✅ 責務ごとに分類された設計

```text
utils/
  ├─ date.ts
  ├─ string.ts
  ├─ array.ts
  ├─ dom.ts
```

- ✅ “機能の名前”ではなく“責任の範囲”で構成する
- ✅ ドメイン関数との境界を明確に

---

## 2. 名前で責務を伝える

```js
// ❌ 曖昧
format(val);

// ✅ 意図を具体化
formatDateToISO(date);
formatCurrencyToJPY(price);
```

- ✅ ユーティリティ関数は“名前だけで意味が読める”のが理想
- ✅ 意味が曖昧なら抽象化のしすぎ or 共通化する必要なし

---

## 3. 外部ライブラリ vs 内製ユーティリティの判断軸

| 機能                         | 対応         |
|------------------------------|--------------|
| ソート、マップ、グルーピング | Lodashなどで可 |
| 特定業務ルールを含む処理     | 内製化       |
| 一般的な日付フォーマット     | date-fnsなど |
| 日本語特有の表記変換         | 内製ユーティリティ化 |

→ ✅ 外部ライブラリは**“共通知識”の委譲**  
→ 内製ユーティリティは**“ドメイン固有の知識”の形式知化**

---

## 4. ユーティリティを設計する7つの原則

1. **引数は少なく、シンプルに**
2. **副作用を持たない（純粋関数）**
3. **引数・戻り値の型を明確に**
4. **ドメインロジックと分離する**
5. **依存関係を最小限に保つ**
6. **名前に処理内容と目的を込める**
7. **テストを書いて初めて完成**

---

## 5. “地獄のutils.js”を避ける設計指針

### ❌ なんでもutilsに入れてしまう

→ ✅ `useXxx()`（フック） or `services/`, `adapters/` に責任を分離  
→ ✅ “純粋な値処理だけ”をutilsに限定する

```text
utils/
  ├─ formatDate.ts
  ├─ parseCSV.ts
  └─ escapeHTML.ts ← OK

adapters/
  └─ localStorageAdapter.ts ← 副作用を扱う
```

---

## 6. ドメインロジックと汎用処理の明確な境界

```js
// ❌ 業務ロジックと混在した関数
function validateUserAge(age) {
  return age > 20 && String(age).length === 2;
}

// ✅ 汎用処理を抽出
function isAdult(age) {
  return age >= 20;
}

function isTwoDigit(num) {
  return String(num).length === 2;
}
```

→ ✅ “何が業務知識か”“何が再利用対象か”を設計時に分離する

---

## 設計判断フロー

```text
① この関数は純粋か？ → OKならutils対象

② 名前だけで何をするかわかるか？ → NGなら分割or明示命名

③ 依存ライブラリで十分では？ → 再利用性の高い処理なら外部委譲を検討

④ ドメイン知識が混在してないか？ → 責務に応じてservicesやadaptersへ

⑤ テストで扱いやすいか？ → 非同期や副作用を含んでいないか確認
```

---

## よくあるミスと対策

### ❌ `utils.ts` が 1000行を超えて肥大化

→ ✅ **機能単位 + 責任範囲ごとにファイル分割**

---

### ❌ “便利だから”と無計画に関数化

→ ✅ 「同じ処理が3回以上登場したとき」が関数化の起点

---

### ❌ 再利用前提で作ったが、実際には1箇所でしか使われてない

→ ✅ 共通化の前に「使い回す必要があるか？」を冷静に判断

---

## 結語

ユーティリティとは、“便利”ではなく、“意味を持った最小単位”である。

- それは再利用されるために設計され
- 責務のない共通化を拒絶し
- 明確な名前と構造で存在する

**JavaScriptにおけるユーティリティ設計とは、  
「無秩序な関数群」ではなく、「知識の再利用戦略」である。**
JavaScriptにおけるオブジェクト設計：データ vs 振る舞い・POJO・クラス構造・責務の分離と再利用

## 概要

オブジェクト設計とは、「この塊は何を表していて、何ができるのか」を言語化する行為である。  
JavaScriptでは、関数・オブジェクト・クラス・プロトタイプと複数の表現手段があり、**柔軟ゆえに混乱しやすい**。  
だからこそ、**「構造」「振る舞い」「責務」を明確に分離・設計すること**が、メンテナブルなコードの前提となる。

---

## 1. POJO（Plain Old JavaScript Object）による構造設計

```js
const user = {
  id: 'u01',
  name: 'Toto',
  isAdmin: false
};
```

- ✅ シリアライズしやすく、状態のスナップショットとして機能
- ✅ 特に状態管理（Redux等）やAPI通信との親和性が高い
- ❌ 振る舞い（関数）を内包し始めると構造が曖昧に

---

## 2. クラス設計：意味のある「型」として構築する

```js
class User {
  constructor(id, name, isAdmin = false) {
    this.id = id;
    this.name = name;
    this.isAdmin = isAdmin;
  }

  displayName() {
    return `${this.isAdmin ? '[ADMIN] ' : ''}${this.name}`;
  }
}
```

- ✅ データと振る舞いを**一つの意味としてパッケージ化**
- ✅ 再利用・拡張しやすく、テスト対象としても明確
- ❌ 状態と副作用を混在させると破綻しやすい

---

## 3. クラス vs ファクトリ関数：選定基準

### ✅ クラスで設計すべきケース

- “型”の意味が明確（User, CartItem, Timerなど）
- newによるインスタンス制御が自然
- `instanceof`による型判定を活用する場合

### ✅ ファクトリ関数で構築すべきケース

- **状態のみが必要**で、プロトタイプ継承は不要
- データをベースに“加工”する関数が主
- インスタンスを隠蔽し、純粋関数として扱いたい場合

```js
function createUser(id, name) {
  return {
    id,
    name,
    isAdmin: false,
    displayName() {
      return `${this.name}`;
    }
  };
}
```

---

## 4. 振る舞いを責務単位に分割する

```js
class Cart {
  constructor() {
    this.items = [];
  }

  add(item) {
    this.items.push(item);
  }

  total() {
    return this.items.reduce((sum, item) => sum + item.price, 0);
  }
}
```

- ✅ データ保持（items）と操作（add/total）を**意味ある単位で提供**
- ✅ クラスが「文脈と機能の集合体」であることを明示する設計

---

## 5. 合成 vs 継承：再利用の構造的選択

### ❌ 継承を多用すると依存関係が崩壊しやすい

```js
class AdminUser extends User {
  deleteUser() { ... }
}
```

→ ✅ 再利用の基本は「合成（Composition）」による柔軟な設計

```js
function withLogger(obj) {
  return {
    ...obj,
    log() {
      console.log(`[${obj.name}]`);
    }
  };
}
```

---

## 6. 設計的判断のフレームワーク

| 目的                       | 手法                      |
|----------------------------|----------------------------|
| 状態だけを扱いたい         | POJO                      |
| 意味ある型と動作を束ねたい | クラス or ファクトリ関数  |
| 動作を切り替え可能にしたい | Strategyパターン + 合成   |
| インスタンス制御したい     | クラス構文 + `instanceof` |
| 動作だけ再利用したい       | 関数 or Mixin             |

---

## よくあるミスと対策

### ❌ オブジェクトに処理と状態が無秩序に混在

→ ✅ クラスを導入 or 関数を分離し、**意味の単位で設計する**

---

### ❌ 継承で「is-a」関係が破綻（例：AdminUser → GuestUser）

→ ✅ **共通機能は合成（has-a）で再利用**

---

### ❌ どこからでも直接プロパティを参照してしまう

→ ✅ **アクセサを導入し、内部構造を隠蔽**

```js
get isLoggedIn() {
  return !!this.token;
}
```

---

## 結語

オブジェクトとは、データではなく「概念の実体化」である。  
それは構造であり、振る舞いであり、**意味を持った単位で再利用可能にする設計の中心**である。

- POJOで構造を定義し  
- クラスで意味を定義し  
- 合成で振る舞いを再利用する

**JavaScriptにおけるオブジェクト設計とは、  
“意味と再利用を両立させるための、最小構成の建築技法”である。**
JavaScriptにおけるエラーハンドリング設計：例外構造・エラー分類・通知設計・ユーザー体験の担保

## 概要

エラーハンドリングとは“例外が起きたときに止める”ことではない。  
それは“壊れても崩壊しないための設計”であり、**開発者とユーザーの双方に意味あるフィードバックを返すための構造的判断**である。

本稿では、JavaScriptにおけるエラーハンドリング設計を以下の観点で整理する：

- try/catchの構造化と責務範囲
- ドメインごとのエラー分類と再throw戦略
- UIとエラーの分離・通知連携
- ログ収集と監視との統合
- 想定外のエラーに対する“最後の砦”設計

---

## 1. try/catchの構造と設計的境界

```js
try {
  const res = await fetch('/api/user');
  const data = await res.json();
  render(data);
} catch (err) {
  showError('ユーザー情報の取得に失敗しました');
}
```

- ✅ tryは**“例外が起こり得る最小範囲”**をカバー
- ✅ catchは**ユーザー向けorログ向けの責務に分けて**設計

---

## 2. エラーの分類とカスタムエラー設計

```js
class AppError extends Error {
  constructor(message, code = 'APP_ERROR') {
    super(message);
    this.code = code;
  }
}

class ValidationError extends AppError {
  constructor(message) {
    super(message, 'VALIDATION_ERROR');
  }
}
```

→ ✅ catch時にエラー種別を判別して**処理を分岐**

```js
try {
  validate(input);
} catch (e) {
  if (e instanceof ValidationError) {
    notifyUser(e.message);
  } else {
    logError(e);
  }
}
```

---

## 3. 非同期・チェーンの中でのエラー設計

```js
async function load() {
  try {
    const data = await fetchUser();
    display(data);
  } catch (e) {
    report(e);
  }
}
```

### ✅ `.catch()`は構造的責務で分ける

```js
fetch('/api')
  .then(handleResponse)
  .catch(logError); // 全体的な責任
```

---

## 4. ユーザー体験に応じた通知設計

- ✅ 軽微なエラー → トースト or 非同期通知
- ✅ 重大な処理失敗 → モーダル or 再試行UI
- ✅ バリデーション系 → input欄付近に個別表示

```js
try {
  await save();
  showToast('保存に成功しました');
} catch {
  showToast('保存に失敗しました', { type: 'error' });
}
```

→ ✅ UIの破壊を避け、**“伝わるフィードバック”を常に提供する**

---

## 5. 例外監視とログの最終設計

### ✅ グローバルエラーのハンドリング

```js
window.addEventListener('error', (event) => {
  reportFatalError(event.error);
});

window.addEventListener('unhandledrejection', (event) => {
  reportFatalError(event.reason);
});
```

- ✅ 想定外の例外も**収集・通知設計に統合**
- ✅ 例外発生位置・スタックトレース・ユーザー環境を含めて送信

---

## 設計判断フロー

```text
① 例外が起きうる範囲は？ → try/catchの範囲を絞る

② ユーザーに伝える必要がある？ → UIと通知構造を分離

③ 同じcatchで全部処理してない？ → エラー分類を導入

④ ログは必要？ → スタック情報を含めて送出設計を入れる

⑤ 未処理例外に備えてるか？ → window.onerror / unhandledrejection で最後の砦
```

---

## よくあるミスと対策

### ❌ try/catchの範囲が広すぎて“どこで失敗したか”不明

→ ✅ **最小粒度のtry/catchに分割する**

---

### ❌ catchの中でconsole.errorだけ

→ ✅ **UI通知・ログ送信の両方を設計に組み込む**

---

### ❌ どのエラーも“ただのError”として扱っている

→ ✅ **カスタムエラーを定義し、意味のある分類を導入**

---

## 結語

エラーとは設計の不備ではない。  
それは**“設計が準備できていなかった現実”の現れ**である。

- 例外は想定され
- 通知は最小限に伝えられ
- ログは未来のために残される

**壊れたコードではなく、壊れても崩壊しないコードへ。  
それがエラーハンドリング設計の使命である。**
JavaScriptにおけるパフォーマンス設計：計算最適化・メモ化・イベント制御・描画抑制の戦略的アプローチ

## 概要

速さとは“副産物”ではなく“設計”である。  
JavaScriptのパフォーマンスは、コードの書き方よりも、**処理の設計・頻度の制御・無駄な描画の削減**により決定される。

本稿では、UIレスポンスを保ったまま処理を最適化するために、以下の観点から戦略を体系化する：

- 演算コストの見積もりと分割
- メモ化（Memoization）の正しい適用
- スクロール/リサイズ等の高頻度イベントの制御
- 再描画の抑制と構造最適化
- 非同期処理と処理バッチ化

---

## 1. 計算コストの局所化と分割戦略

```js
// ❌ 毎回重い計算を通る構造
function expensiveFilter(arr) {
  return arr.filter(item => heavyComputation(item));
}
```

### ✅ 解決策：

- 計算を**遅延化 or キャッシュ化**
- 結果を次回に再利用（メモ化）

```js
const memo = new Map();

function memoizedFilter(arr) {
  const key = JSON.stringify(arr);
  if (memo.has(key)) return memo.get(key);
  const result = arr.filter(item => heavyComputation(item));
  memo.set(key, result);
  return result;
}
```

---

## 2. イベントバースト制御（デバウンス / スロットル）

### ✅ デバウンス：最後の操作だけを処理

```js
function debounce(fn, delay) {
  let timer;
  return (...args) => {
    clearTimeout(timer);
    timer = setTimeout(() => fn(...args), delay);
  };
}
```

### ✅ スロットル：一定間隔で処理

```js
function throttle(fn, interval) {
  let last = 0;
  return (...args) => {
    const now = Date.now();
    if (now - last >= interval) {
      last = now;
      fn(...args);
    }
  };
}
```

→ ✅ スクロール・リサイズ・入力監視などの**リアルタイム処理に不可欠**

---

## 3. DOM操作のバッチ化と再描画制御

```js
// ❌ 連続DOM操作
for (let i = 0; i < 1000; i++) {
  const el = document.createElement('li');
  el.textContent = `Item ${i}`;
  list.appendChild(el);
}
```

### ✅ DocumentFragment + requestAnimationFrame

```js
const fragment = document.createDocumentFragment();
for (let i = 0; i < 1000; i++) {
  const el = document.createElement('li');
  el.textContent = `Item ${i}`;
  fragment.appendChild(el);
}
requestAnimationFrame(() => list.appendChild(fragment));
```

- ✅ DOM変更は**一括で行う**
- ✅ 描画タイミングに合わせて最適化

---

## 4. レンダリング最適化：スタイル・レイアウト・ペイント分離

- ✅ スタイル変更は**一括して書き換える**
- ✅ `style.transform`, `opacity` など**GPUレイヤに委ねられるプロパティを使用**
- ❌ 連続で `offsetTop`, `getBoundingClientRect()` を参照・更新 → レイアウトスラッシングに注意

---

## 5. メモリリークと監視対象の明示的解除

```js
// ❌ イベントリスナーを永続化
window.addEventListener('resize', handler);

// ✅ removeEventListenerで明示的解除
window.removeEventListener('resize', handler);
```

- ✅ モーダル・非表示エリアなどで**不要になった監視は破棄**
- ✅ IntersectionObserverやMutationObserverも**disconnect()を設計に組み込む**

---

## 設計判断フロー

```text
① 計算が重い？ → メモ化 or 遅延処理を検討

② 高頻度イベントがある？ → debounce/throttle で頻度制限

③ DOM操作が大量？ → DocumentFragment や requestAnimationFrame で一括描画

④ レンダリングが遅い？ → GPU最適化プロパティ、再レイアウト回避

⑤ 見えないイベントが残っている？ → removeEventListener / disconnect() を設計に含める
```

---

## よくあるミスと対策

### ❌ ユーザー操作ごとに即座にAPI呼び出し

→ ✅ debounceで**操作の意図が明確になってから処理**

---

### ❌ ページ遷移後もイベントが残り続ける

→ ✅ **ライフサイクルでイベント解除の設計**を含める

---

### ❌ アニメーションがカクつく

→ ✅ GPU描画プロパティと**レイアウトスラッシング対策**を実施

---

## 結語

パフォーマンスとは“速度”ではなく“設計のバランス”である。  
- 処理を遅らせる勇気  
- 頻度を制御する冷静さ  
- 描画をまとめる設計力  

**速いコードではなく、**  
**「速さが継続する構造」こそが、真のパフォーマンス設計である。**
初心者でも安心💡30分でディープラーニングを学ぼう！

こんばんは、韓国在住のsanaです！

Pythonやデータ分析の知識がないけど、ディープラーニングを学びたい！そんなあなたにぴったりな講座をご紹介します🎉


📚 無料で学べるディープラーニング講座
この講座では、ディープラーニングの基本的な考え方をわかりやすく解説し、実際にどんな場面で活用されているかも紹介します✨　無料で学べるので、気軽に学習できます🚀




どうやって学ぶの？💻
:star:30分で完結：忙しいあなたでも、短時間でディープラーニングの基礎を学べます:hugging:

:star:実例紹介：実際に使われているディープラーニングの事例を紹介して、理解を深めます🔍

:star:初心者向け：専門的な知識がなくてもわかりやすく解説！どこからでもスタートできます！



https://u.inf.run/3DXnovd

https://u.inf.run/41VRdWd

https://u.inf.run/42d5GM6



こんな方にオススメ✨
(1)人工知能や機械学習の基本を知りたい方

(2)データ分析の基礎を学びたい方

(3)Pythonに自信がないけどディープラーニングを学びたい方

(4)ディープラーニングを早く理解したい方
[小ネタ]毎月指定の日に特定処理を実行するが休日なら前後の営業日にずらす、というフローをholiday_japanを使って実装する

クレジットカードは毎月、指定された日に引き落とされる仕組みですが、その日が休日の場合は、翌営業日に引き落とされるのが一般的です。
逆に給料は特殊な契約でなければ、毎月指定された日に振り込まれる仕組みですが、その日が休日の場合は、前営業日に振り込まれることが多いでしょう。

上記のような、特定の日に○○して欲しい、ただしその日が休みなら前後にずらすという処理を今回は[holiday_japan](https://github.com/masa16/holiday_japan/tree/master)というgemを使って実装します。

## holiday_japanとは

1948年7月20日以降の日付に関して、日本の祝日かどうかを判定することができるgemです。
非常にコンパクトで、執筆時点(2025/04/01)で最新版はコア部分のrubyファイルが232行しかありません。

https://github.com/masa16/holiday_japan/blob/master/lib/holiday_japan.rb

checkという関数にDate型の変数を渡すと、祝日かどうかをtrue/falseで教えてくれます。

```
HolidayJapan.check(Date.new(2023, 7, 17)) # この日は海の日
=> true
```

## 今回実装するもの

- 今回は例としてクレジットカードの引き落とし日を教えてくれる処理を実装します
    - 年、月、通常の引き落とし日を渡すと、`x年y月の引き落とし日はx年y月z日です`と出力する
- クレジットカードの引き落としは原則毎月同じ日に行うが、土日もしくは祝日の場合翌営業日に引き落とすこととする

## 処理を実装する

- 処理としては非常に簡単で、土日もしくは祝日なら翌日にずらして判定するだけ
    - 土日に関してはDate型に存在する`saturday?`メソッドと`sunday?`メソッドで判定
    - 祝日は先述の`HolidayJapan.check`を利用

```ruby
require 'holiday_japan'

year = ARGV[0].to_i
month = ARGV[1].to_i
payment_day = ARGV[2].to_i
payment_date = Date.new(year, month, payment_day)

while payment_date.saturday? || payment_date.sunday? || HolidayJapan.check(payment_date)
  payment_date += 1
end

puts "#{year}年#{month}月の引き落とし日は#{payment_date.strftime('%Y月%m日%d日')}です"
```

## 実際に試してみる

- 15日が引き落としの場合の2025年5月
    - 2025年5月15日は平日なので、予定通り引き落とされる

```irb_
❯ ruby credit_card_payment_day.rb 2025 5 15
2025年5月の引き落とし日は2025月05日15日です
```

- 15日が引き落としの場合の2023年7月
    - 17日が海の日なので、土日と祝日で3日ずれて18日になる

```irb
❯ ruby credit_card_payment_day.rb 2023 7 15
2023年7月の引き落とし日は2023月07日18日です
```

- 27日が引き落としの場合の2019年4月
    - 5/1日が新天皇即位日(2019年のみの祝日)で、更に[祝日と祝日に挟まれた日は休日になるという法律](https://www8.cao.go.jp/chosei/shukujitsu/gaiyou.html)により、4/30と5/2も休日になる
    - その結果4/27から5/6まで休日なので5/7が引き落とし日になる

```irb
❯ ruby credit_card_payment_day.rb 2019 4 27
2019年4月の引き落とし日は2019月05日07日です
```

問題なく、特定日に処理を実行するが、休日であれば翌営業日にずらす処理が実装できていそうです。

## まとめ
今回月初にある処理をさせたいが、休日もしくは祝日なら後にずらす処理を趣味で組むタイミングがあり、今回の記事を書きました。
他の言語でも祝日に関するライブラリは存在するので、今回の記事のような処理が必要になったときは是非探して利用してみてください。
文学と機械学習(日記)

文学や機械学習は、美術や音楽に比べると比較的理解されやすいと思いますが、機械学習をどのように広めていくかは、慎重に考える必要があります。雑なメモをしていきます。


https://qiita.com/mhiro216/items/74db409d2cbd4c6c2d7a




![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4046871/c471280a-5f0b-4e9a-ae06-b810c61ef76e.png)


https://ledge.ai/articles/akutagawa_prize-winning_works_use_genai


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4046871/1f380b6e-3379-42fc-97a8-1c7f1292de99.png)



https://www.amazon.co.jp/Text-%E8%87%AA%E7%84%B6%E8%A8%80%E8%AA%9E%E5%87%A6%E7%90%86%E3%81%AE%E5%9F%BA%E7%A4%8E-%E5%B2%A1%EF%A8%91-%E7%9B%B4%E8%A6%B3/dp/4274229009

https://qiita.com/cvusk/items/c1342dd0fff16dc37ddf
AIが社会に与える影響と、開発者として考えておきたいこと

AI（人工知能）と聞いて、どんなイメージが思い浮かびますか？

便利そう、未来っぽい、仕事が楽になる、一方でちょっと怖い、制御不能になるかも……そんな印象を持っている人も少なくないでしょう。

実際、ここ数年でAIは私たちの生活の中にしっかりと入り込んでいます。スマートスピーカーや翻訳アプリ、カスタマーサポートのチャットボット、自動運転技術、さらには採用選考や与信審査の一部にも活用されています。

ただ、そうした中で、「本当にこのAIの判断って信じていいの？」「誰が責任を取るの？」「どうやってこの結論が出たのか説明できるの？」といった疑問や不安も生まれています。

これは単なる技術論ではなく、**社会と技術の関係そのもの**に関わる、とても大事な問題です。

---

## 技術だけではカバーできないAIの「あり方」

AIの精度が高ければ、すべてがうまくいくわけではありません。なぜなら、AIの判断は人間の価値観やデータのバイアスに大きく影響されるからです。

たとえば、

- 顔認識システムが特定の人種に対して誤認識しやすい  
- 採用AIが、過去のデータに基づいて特定の性別を優遇してしまう  
- クレジットスコアの仕組みが所得や出身地で差別を生む可能性がある

こうした事例は実際に世界中で報告されています。そして、これらは「AIが悪い」のではなく、「AIの使い方」や「設計思想」によって起きているものなのです。

---

## 責任あるAI（Responsible AI）という考え方

こうした問題意識を背景に、最近注目を集めているのが「責任あるAI（Responsible AI）」というアプローチです。

責任あるAIとは、ただ高性能なAIを作るのではなく、**人間中心の視点**を持ち、社会との共生を前提にしたAI開発・運用のあり方を指します。

具体的には、次のような原則が大切にされています：

- **公平性**：あらゆる人に対して偏りのない判断がされること
- **信頼性と安全性**：バグや予期せぬ動作を防ぎ、安定して動作すること
- **プライバシーとセキュリティ**：個人情報が不適切に扱われないこと
- **包括性**：誰一人取り残さない、あらゆる人にとって使いやすい設計
- **透明性と説明可能性**：AIが何をどう判断したのかが理解できること
- **説明責任**：そのAIを誰が、どう管理しているかが明確であること

これらは一見当たり前のように見えますが、実際のAI開発現場では、精度やスピードを優先するあまり、後回しにされがちな要素でもあります。

---

## では、実際にどうすればいいのか？

理想論としての「責任あるAI」ではなく、実装可能な形で現場に落とし込むにはどうすればいいのか――。

そのヒントになる考え方や実践ステップが、Omomuki の以下の記事に非常にわかりやすくまとめられています。

👉 [責任あるAI開発入門：倫理的なAIを社会実装するために](https://omomuki-tech.com/archives/944)

この記事では、開発の各フェーズ（企画、設計、実装、テスト、運用）でどういう観点を持つべきか、どんなツールやフレームワークを活用できるのか、といった具体的なアイデアが紹介されています。

また、ビジネス・技術・倫理それぞれの観点がバランスよく盛り込まれていて、単なる理想論や啓蒙ではなく、**「実際にどう進めていくか」の参考になる実用的な内容**です。

---

## こんな方におすすめ

- 自社プロダクトにAIを導入予定のエンジニア・企画担当者
- 「AIに判断を委ねる」ことに漠然とした不安を感じている方
- 技術者として、AIの使い方に責任を持ちたいと思っている人
- データサイエンスと社会課題の接点に興味がある学生や研究者

---

## 最後に

AI技術は間違いなく、私たちの社会をより便利で豊かにする力を持っています。けれど、その力が正しく使われなければ、誰かを傷つけたり、社会の分断を深める可能性すらあるのです。

責任あるAIとは、「AIを信じて使う」ために、**人間側が持つべき態度や知識、仕組み**だと私は感じました。

もしあなたが、AIを「作る側」でも「使う側」でも、少しでも関心を持ったなら、ぜひこの記事を読んでみてください。

👉 [責任あるAI開発入門：倫理的なAIを社会実装するために](https://omomuki-tech.com/archives/944)
CSV / openpyxl いいcodeと悪いcode

[CSV崩れるかも]
csv保存時、
cleaned_data がwrite(line + "\n")で文字列に
されてる
(リストで入れないといけない)

```ruby : 
    for line in cleaned_data:
        outfile.write(line + "\n") 

    →
    writer = csv.writer(outfile)
    writer.writerows(cleaned_data)
   
```

    
    
3. Excel書き込みで IndexError 起きる可能性
```ruby:悪いcode
ws[f'A{start_row}'] = row[0]  # 日付
ws[f'B{start_row}'] = row[1]  # 勤務先
ws[f'C{start_row}'] = row[2]  # 経路
ws[f'D{start_row}'] = row[3]  # 交通費(往復)
ws[f'E{start_row}'] = row[4]  # 給料
```


```ruby:good code
ws[f'A{start_row}'] = row[0] if len(row) > 0 else ''
ws[f'B{start_row}'] = row[1] if len(row) > 1 else ''
ws[f'C{start_row}'] = row[2] if len(row) > 2 else ''
ws[f'D{start_row}'] = row[3] if len(row) > 3 else ''
ws[f'E{start_row}'] = row[4] if len(row) > 4 else ''
```

Excel 文字→ 数値にする

```ruby : excel
=VALUE(A1)
```

<h4>自動化参考サイト</h4>

https://hoshi-it-o.com/python-automation/
ディスク枯渇の調査で使うドリル

# ドリル

sudo du -xh / --max-depth=1 2>/dev/null | sort -hr

これがドリルです。 
##### ひたすらこれを使う。
このドリルを使って穴を掘っていくイメージ。

![スクリーンショット 2025-04-01 18.48.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2780693/e96286ff-5cc6-47a1-affd-b3a62f486399.png)



# こんな感じ

sudo du -xh / --max-depth=1 2>/dev/null | sort -hr

で、まずはどこに容量を食っているファイルがありそうか見ましょう。

varの下にありそう。ドリルをチューニングします。

sudo du -xh /var --max-depth=1 2>/dev/null | sort -hr

var libにありそう

sudo du -xh /var/lib --max-depth=1 2>/dev/null | sort -hr

という感じで掘っていく。

# コンテナイメージじゃね？となる

docker images
で見てみましょう。

docker ps
で今使っているのはどれかを確認。必要性を確認し、pruneしてください（使ってないからと言って消していいわけではない）。

# 以上

久々にドリル使ったのでメモでした。他にも使えるツールがあればぜひコメントで教えてください。

![スクリーンショット 2025-04-01 18.48.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2780693/bf2f1c6d-8483-4e52-9cd5-23fcfc77a766.png)
スレッドセーフではないJavaクラス一例と注意点

# スレッドセーフではない Java クラスとその注意点

Java開発者ではなじみがあるクラスだと思いますがマルチスレッド環境では注意点が必要なクラスを記載します。
スレッドセーフについて：
https://qiita.com/naoyoshinori/items/507c5c3ea6027033f4bb

本記事では `ArrayList`、`HashMap`、`SimpleDateFormat` について、それぞれのスレッドセーフでない理由と注意すべき使用例を解説します。

## 1. ArrayList

`ArrayList` は内部的に配列を使用しており、サイズ変更や要素の追加・削除時に競合が発生する可能性があります。複数のスレッドが同時に `ArrayList` を変更すると、データの不整合や `ConcurrentModificationException` が発生することがあります。

### 解決案
スレッドセーフな `CopyOnWriteArrayList` を使用する。
```java
import java.util.List;
import java.util.concurrent.CopyOnWriteArrayList;

List<Integer> safeList = new CopyOnWriteArrayList<>();
```

## 2. HashMap

`HashMap` は内部で `put()` や `remove()` を行う際に、バケットの再配置（リハッシュ）が発生することがあります。このとき、複数スレッドが同時に操作すると、データの不整合や無限ループが発生する可能性があります。

### 解決案
スレッドセーフな `ConcurrentHashMap` を使用する。
```java
import java.util.concurrent.ConcurrentHashMap;

ConcurrentHashMap<Integer, String> safeMap = new ConcurrentHashMap<>();
```

---

## 3. SimpleDateFormat

`SimpleDateFormat` は、`parse()` や `format()` を実行する際に内部状態を変更します。複数のスレッドが同時に `format()` や `parse()` を呼び出すと、不正なフォーマットや `ParseException` が発生する可能性があります。

### 注意すべき使用例
```java
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Date;

public class SimpleDateFormatExample {
    private static SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");

    public static void main(String[] args) {
        Runnable task = () -> {
            for (int i = 0; i < 1000; i++) {
                try {
                    Date date = sdf.parse("2024-04-01");
                    String formattedDate = sdf.format(date);
                    System.out.println(formattedDate);
                } catch (ParseException e) {
                    e.printStackTrace();
                }
            }
        };

        Thread t1 = new Thread(task);
        Thread t2 = new Thread(task);
        t1.start();
        t2.start();
    }
}
```
このコードでは、複数のスレッドが `SimpleDateFormat` の `parse()` メソッドを同時に呼び出すため、データの競合が発生する可能性があります。

### 解決案

1. `DateTimeFormatter` を使用する
```java
import java.time.LocalDate;
import java.time.format.DateTimeFormatter;

DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd");
LocalDate date = LocalDate.parse("2024-04-01", formatter);
```

---

## まとめ
| クラス | 発生可能性がある場面 | 解決策一例 |
|--------|----------------|------|
| `ArrayList` | 要素の追加・削除時にデータ競合が発生 | `CopyOnWriteArrayList`を使用 |
| `HashMap` | 同時書き込みでデータ競合が発生 | `ConcurrentHashMap` を使用 |
| `SimpleDateFormat` | `format()` や `parse()` の内部状態が変更される | `DateTimeFormatter`を使用 |

今回は一例になりますがスレッドセーフの問題がある場合は性能などの検討も行い設計を確認したうえで適切な代替手段を選択をしましょう。
デジタル名刺アプリを作成


# 実践内容
今回はReact,Typescriptでデジタル名刺アプリを作成しました。


### 成果物はこちら

Github

https://github.com/wws225/businesscard

アプリ

https://businesscard-9435d.firebaseapp.com/


### アプリ紹介
[トップ画面]
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3973178/f749832c-f42f-43ac-86e3-57df647dbae6.png)
作成した名刺のIDを入力してその名刺を閲覧する画面に遷移します。
新規登録からは新しい名刺を作成する画面に遷移します。


[名刺画面]
トップ画面で検索したIDに紐づく名刺を閲覧できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3973178/75304822-b153-4a1c-9fdd-946507db5d34.png)
SNSのアイコンをクリックすると各々のアカウントページが開きます。


[新規作成画面]
各項目を埋めて登録ボタンで新しく登録できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3973178/f599b92d-5192-4ecd-bcc7-903c57055a5c.png)

必須項目の存在チェックをして、問題がなければDBにデータを保存してトップ画面に遷移します。

### 実践内容

viteでのReact＋Typescriptの開発環境構築、
バックエンドとしてデータベースはsupabase、アプリのホスティングにfirebaseを使い、ライブラリはchakra uiやvitestなどを使用しました。
またGithub actionsで前日に作成したデータを自動削除するワークを実装しています。



### 覚え書き
テストコードはvitestで作成しましたが、jestとほとんど記法も変わらず、chakra ui v3のライブラリを使っていてもエラーを吐くことなく実行できるのでよかったです。
jestとの違いとして下のインポートを忘れるとエラーを吐くので忘れないように。

```typescript
import "@testing-library/jest-dom";
```

後は専用の結果表示機能もあって結果が見やすい
```
$ npx vitest --ui
```

### さいごに
今回はchakra-uiのライブラリを公式サイトを漁りながら色々と触って実装を行いました。ロード時のアニメーションやアイコンなど。
前よりはまだ見やすいレイアウトが作れるようになり、思い浮かべた実装を調べる前にある程度できるくらいにはなれたと思います。
引き続きスキルアップするためにアウトプットによる学習を進めていきます。

# JISOUのメンバー募集中！
プログラミングコーチングJISOUでは、新たなメンバーを募集しています。
日本一のアウトプットコミュニティでキャリアアップしませんか？
興味のある方は、ぜひホームページをのぞいてみてください！
▼▼▼

https://projisou.jp
エッジコンピューティング最前線：AIと5Gで実現する次世代インフラ

## エッジコンピューティングとは？次世代インフラの最前線

### 1. はじめに

クラウドコンピューティングの時代から、現在は **エッジコンピューティング** へと進化しています。特に **5Gの普及** と **AI技術の進歩** により、データをエッジ（デバイスやゲートウェイ）で処理することで、

✅ **リアルタイム処理**（低レイテンシ）
✅ **ネットワーク負荷の軽減**
✅ **セキュリティとプライバシーの向上**

といった多くのメリットを得られるようになりました。本記事では、**エッジAI、5G、分散コンピューティング** を軸に、エッジコンピューティングの最新技術と最適なアーキテクチャについて深掘りします。

---

### 2. エッジコンピューティングの基礎概念

**エッジコンピューティング** とは、従来のクラウド中心のデータ処理モデルとは異なり、**データの生成地点（IoTデバイス、スマートフォン、産業機器など）で処理を行うアーキテクチャ** です。

例えば、
- 自動運転車がクラウドを介さずに **瞬時にAI処理** を行い障害物を回避。
- 工場内のセンサーが **リアルタイムに異常を検知** し、生産ラインを制御。
- スマートシティのカメラが **その場で映像解析** を実行し、渋滞や事故を予測。

このように **リアルタイム処理が求められるユースケース** において、エッジコンピューティングは不可欠な技術です。

---

### 3. 5Gとエッジコンピューティングの関係

エッジコンピューティングを支える重要なインフラが **5G** です。

✅ **5Gの特徴:**
1. **超高速通信**（最大10Gbps）
2. **超低遅延**（1ms以下）
3. **大量接続**（IoTデバイスの増加に対応）

**従来の4Gでは遅延が大きく、クラウドと連携するリアルタイム処理が困難** でしたが、5Gの登場により、
- **遠隔医療（リアルタイム診断）**
- **スマートファクトリー（ロボット制御）**
- **スマートシティ（リアルタイム監視）**

といった高度なエッジコンピューティングアプリケーションが可能になりました。

---

### 4. エッジAI：ローカルでの機械学習推論

エッジコンピューティングにおいて、**AIの推論処理をローカルで行う「エッジAI」** は非常に重要です。

✅ **エッジAIのメリット:**
- **リアルタイム性:** クラウドを介さずに処理するため、遅延が最小限。
- **帯域削減:** クラウドへのデータ送信を減らし、ネットワークコストを削減。
- **セキュリティ強化:** データをローカルで処理するため、プライバシーリスクを軽減。

例えば、
- スマートカメラがクラウドを使わずに **AIで異常を検知**。
- 工場のロボットが **エッジAIで動作最適化** を実施。
- スマートフォンが **デバイス内AIで顔認識や音声解析** を行う。

**代表的なエッジAIハードウェア:**
| デバイス | 特徴 |
|-----------|----------|
| NVIDIA Jetson | GPU搭載、小型ながら強力なAI推論 |
| Google Coral | 高速なTensorFlow Lite推論向け |
| Intel Movidius | 低消費電力AI処理向け |

また、**AWS Greengrass, Azure IoT Edge, Google Edge TPU** などのクラウドサービスもエッジAIに対応しつつあります。

---

### 5. 分散コンピューティングとエッジの統合

**分散コンピューティング** を活用することで、エッジデバイス間の協調処理が可能になります。

✅ **アーキテクチャ例:**
1. **エッジ + クラウドハイブリッドモデル:**
   - **エッジで前処理**（ノイズ除去、特徴抽出）
   - **クラウドで高度な分析・学習**（機械学習モデルの更新）

2. **ピアツーピア（P2P）エッジネットワーク:**
   - **デバイス同士が直接データ交換**（例：車両間通信）
   - **クラウドの負荷を削減**

3. **エッジフェデレーションラーニング:**
   - データをクラウドに送らず、**エッジデバイス上で機械学習を実施**。
   - 例えば、スマートフォンで個別に学習したデータを **中央クラウドで統合** し、より良いAIモデルを構築。

---

### 6. まとめと今後の展望

エッジコンピューティングは、**AI・5G・分散コンピューティング** の進化とともに発展しています。

✅ **今後の技術トレンド:**
- **エッジAIのさらなる進化**（高性能な推論デバイスの普及）
- **5G SA（Standalone）によるエッジ最適化**
- **ブロックチェーン + エッジの組み合わせ**（分散データ管理）

今後、エッジコンピューティングは **自動運転、スマートシティ、IoT、医療** など幅広い分野で活用が進むでしょう。

**あなたのプロジェクトでは、エッジコンピューティングをどのように活用していますか？**
コメントでぜひ意見を共有してください！🚀
kintoneで3Dオブジェクトを表示してみた

## 構想
技術書典18で頒布予定の「Babylon.jsレシピ集 vol.6」のネタとして、ずっと構想してました。ただ、kintoneのJavaScriptカスタマイズはしたことがなく、どんな感じになるのかわからなかったため、ChatGPTと相談しながら構想を練っていました。

結果、ビューにCanvas要素を埋め込み、そこに描画する流れを提案してくれて納得でした（GPTくん、優秀）。

## 実装
ここもChatGPTにコード全体を考えてもらいましたが、なかなかうまく行きませんでしたので、切り分けとして下記ステップで実装していきました。

### ステップ①　GLBファイルのPlaygroundへの表示
Babylon.jsのPlaygroundへGLBファイルを表示するだけのコードです。GLBファイルは、Github PagesにアップすることでWebからアクセスできるようにしました。

Github Pagesの設定の仕方もわからなかったので、GPT君に確認しながらの作業で、無事に完了しました。

👉　ま、これぐらいは当然できますわなｗ

### ステップ②　kintone上にBOXメッシュを表示
GLBファイルはBabylon.jsで表示できるのは確認取れたので、次はkintone上でBabylon.jsが動くのかの確認。
これも無事に動きました。

### ステップ③　kintone上にGLBファイルの表示
ステップ①＋ステップ②の状態ですね。
こちらも、無事に表示できました。

https://x.com/_0447222690292/status/1906175170659917963

この状態は、kintone上に登録されたファイルを見ているのではなく、無条件にRX-78を表示しているだけでした💦

とりあえず、ここまではそれほど苦労なくこれました。
※ホントは、もっと躓いたところがあるのですが、そのあたりはレシピ集の方で。

### ステップ④　kintone上に登録されたGLBファイルを表示
ここが一番苦労しました。
何が苦労したかと言えば、"KintoneRestAPIClient" を利用するためのライブラリのインポート方法。

やり方としては、2パターンあるんですが、自分はめんどくさがりなので、CDN形式を採用したのですが…GPT君の最新情報では、上記ライブラリがver1.2.0ぐらいで止まっていて、それがどこ探してもない！
実態は、ver5.6.0まで進んでたという…笑

ここの苦労話もレシピ集の方で書きます。

## 動きました

https://x.com/_0447222690292/status/1906717004616401289

ぐりんぐりんに動きます（笑）
これで、レシピ集の執筆に入れますｗ

ちなみに、サイボウズの青野さんにも、いいね押してもらえました👍
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952925/b4e3cf5a-e05d-4c69-91e5-c4f5357d9113.png)

ということで、GPT君を相棒してコードを全面的に生成してもらいました。生成してもらったコードは、ちゃんと自分なりには理解しています！
あと、ちゃんとリファレンスマニュアルも見て、使い方違うじゃん！とGPTに教えたり、ライブラリの最新版情報を教えたりと、案外、持ちつ持たれつの関係でした笑

## 最後に
コードや説明、苦労話などは5月31日から始まる技術書典18の[Babaylonjs勉強会](https://techbookfest.org/organization/dqewxtYMsQVP3EiYjeQyCH)から頒布される「Babylon.jsレシピ集 vol.6」に書かせてもらいますので、お楽しみに～(^^)/
サーバーレスでコストとパフォーマンスを両立する方法：AWS Lambda最適化完全ガイド

## サーバーレスでコストとパフォーマンスを両立する方法：AWS Lambda最適化完全ガイド

### 1. はじめに

クラウドコンピューティングの発展により、企業は**コスト削減とスケーラビリティ向上**を同時に達成できるアーキテクチャを求めるようになりました。その中でも **サーバーレス** は、**インフラ管理不要・従量課金モデル・自動スケール** などのメリットを提供し、特に **AWS Lambda** はその代表格です。

しかし、**適切な設計と最適化を行わないと、サーバーレスのメリットが十分に活かされず、コストが予想以上に高くなる** こともあります。本記事では、**AWS Lambdaの最適化** に焦点を当て、クラウドコストの削減とパフォーマンス向上の両立を実現するための戦略を解説します。

---

### 2. AWS Lambda の基本構造とコストの仕組み

AWS Lambda の料金体系は、**リクエスト数** と **実行時間**（プロビジョンドメモリサイズ × 実行時間） に基づいて計算されます。そのため、コスト最適化のためには、

1. **不要なLambda実行を減らす**
2. **実行時間を短縮する**
3. **メモリ設定を適切に調整する**

という3つのアプローチが重要になります。

また、**AWS Lambda は 1ヶ月あたり100万リクエストまでは無料枠** が提供されるため、これを活用することもコスト削減のポイントです。

---

### 3. AWS Lambda の最適化戦略

#### 3.1 メモリとCPUの適切な設定

AWS Lambda は **メモリサイズ** によって **CPU性能も比例して増加** します。そのため、

✅ **推奨戦略:**
- 必要最低限のメモリを割り当ててコストを抑えるのではなく、**処理速度を向上させるために適切なメモリを設定し、結果的に実行時間を短縮する**。
- Lambdaの**「パフォーマンステスト」** を実施し、**最適なメモリサイズ** を見つける。

🛠 **活用ツール:**
- **AWS Lambda Power Tuning（AWS Step Functions）**：最適なメモリサイズを自動的に分析。
- **AWS X-Ray**：Lambdaの実行時間やボトルネックを可視化。

---

#### 3.2 コールドスタートを最小限に抑える

AWS Lambda には **コールドスタート**（初回実行時の遅延）があります。特に **VPC接続** や **言語の初期化** が影響します。

✅ **推奨戦略:**
- **軽量なプログラミング言語を選択する**（例：Python, Node.js → 速い / Java, .NET → 遅い）
- **Lambdaのプロビジョンドコンピューティング（Provisioned Concurrency）を利用** し、常時ウォーム状態にしておく（ただし追加コストが発生するため、必要な場面でのみ使用）。

---

#### 3.3 外部API・データベースとの接続最適化

多くのLambda関数は **RDSやDynamoDBなどのデータベースと連携** していますが、適切に最適化しないと **コストとパフォーマンス** に悪影響を及ぼします。

✅ **推奨戦略:**
- **Amazon RDS Proxy** を利用し、コネクション管理のオーバーヘッドを削減。
- **DynamoDBのバッチ書き込みと読み取り最適化** を行い、コストを抑える。
- **キャッシュを活用（Amazon ElastiCache / Redis）** し、Lambdaが直接DBにアクセスする回数を減らす。

---

#### 3.4 ストレージとログ管理の最適化

AWS Lambda はログを**CloudWatch Logs** に自動送信しますが、このログ管理が適切でないと **予想外のコスト増加** につながります。

✅ **推奨戦略:**
- **CloudWatch Logs の保持期間を適切に設定（例：30日間など）**
- **S3 + Athena を活用し、安価なログ分析環境を構築**
- **不要な詳細ログを削減（DEBUGログを減らす）**

---

### 4. AWS Lambda のコスト削減シナリオ

| 最適化手法 | メリット | 推奨利用ケース |
|-----------|---------|------------|
| メモリサイズ最適化 | コスト削減 & パフォーマンス向上 | 計算量が多い関数 |
| コールドスタート削減 | 初回遅延を最小化 | API Gatewayとの組み合わせ |
| RDS Proxy の利用 | DB接続の効率化 | LambdaからRDSを利用する場合 |
| CloudWatch ログ管理 | ログコスト削減 | 大量ログを出力するLambda |

---

### 5. まとめ

サーバーレスは、適切な最適化を行うことで、**高パフォーマンスかつ低コスト** なクラウドアーキテクチャを構築できます。

✅ **AWS Lambda の最適化ポイント:**
1. **メモリサイズを適切に設定し、実行時間を短縮**
2. **コールドスタートを削減し、APIのレスポンスタイムを改善**
3. **外部APIやデータベース接続を最適化し、スループットを向上**
4. **不要なログを削減し、CloudWatchのコストを最小化**

適切な最適化を行うことで、**サーバーレスのメリットを最大限に活かすことができます！**

あなたのプロジェクトでは **どの最適化手法を活用していますか？** コメントで意見を共有してください！ 🚀
リアルタイムシステムのアーキテクチャ設計完全ガイド：低レイテンシを実現する秘訣

## リアルタイムシステムのアーキテクチャ設計完全ガイド：低レイテンシを実現する秘訣

### 1. はじめに

近年、オンラインゲーム、ライブストリーミング、金融取引システム、IoTデバイスなど、リアルタイム性が求められるアプリケーションが増加しています。リアルタイムシステムの設計では、**低レイテンシ（Low Latency）**、**高スループット（High Throughput）**、および**スケーラビリティ（Scalability）**が重要な要素となります。本記事では、リアルタイムシステムを構築する際に考慮すべきアーキテクチャの設計原則、および **WebSocket、メッセージキュー、レイテンシ最適化** のベストプラクティスについて詳しく解説します。

---

### 2. リアルタイム通信の基盤技術

リアルタイムシステムを実現するためには、以下の主要な技術を理解し、それぞれの特性を適切に活用することが重要です。

#### 2.1 WebSocket: 効率的なリアルタイム通信
**WebSocket** は、クライアントとサーバー間の双方向通信を可能にするプロトコルであり、HTTPのようなリクエスト/レスポンスモデルではなく、常時接続によるリアルタイムデータ交換を実現します。

✅ **メリット:**
- HTTPに比べてオーバーヘッドが少なく、レイテンシが低い。
- クライアントとサーバーの間でリアルタイムなデータのやり取りが可能。
- メッセージキューやイベント駆動型アーキテクチャと組み合わせることで、スケーラブルなシステムを構築可能。

⚠️ **課題:**
- サーバーの負荷管理が必要（多数の接続を維持するためのスケール戦略）。
- WebSocketが利用できない環境ではフォールバック（Long Polling, SSEなど）が必要。

#### 2.2 メッセージキュー: 非同期処理と負荷分散
リアルタイムアプリケーションでは、**メッセージキュー（Message Queue）** を活用することで、負荷を分散し、スケーラブルなアーキテクチャを構築できます。

🎯 **主なメッセージキューシステム:**
- **RabbitMQ**（AMQPベース、高い信頼性）
- **Apache Kafka**（高スループット、分散型処理に最適）
- **Redis Pub/Sub**（軽量で高速）

🛠 **適用シナリオ:**
- **イベントドリブンアーキテクチャ**：ユーザーのアクションに応じたリアルタイム処理。
- **データストリーム処理**：IoTや金融取引データのリアルタイム解析。
- **負荷分散**：複数のワーカーが処理を分担し、効率的な処理を実現。

#### 2.3 Server-Sent Events（SSE）とLong Polling
WebSocketが使用できない環境では、**SSE（Server-Sent Events）** や **Long Polling** などの代替技術が活用されます。
- **SSE:** 一方向のデータストリームに適し、リアルタイム通知（例: SNSのフィード更新）に利用。
- **Long Polling:** 定期的なHTTPリクエストで最新データを取得する方式。WebSocket未対応のシステムで利用されるが、効率は低い。

---

### 3. 低レイテンシのための最適化戦略

リアルタイムシステムでは、**遅延（レイテンシ）** を最小限に抑えることが重要です。以下の最適化戦略を活用しましょう。

#### 3.1 ネットワーク最適化
- **CDN（Content Delivery Network）** を活用し、ユーザーに近いサーバーからデータを配信。
- WebSocket接続を **Keep-Alive** し、不要な接続の確立を減らす。
- **UDPプロトコル** を活用する（例: WebRTC）ことで、TCPのオーバーヘッドを削減。

#### 3.2 データ処理の最適化
- **バッチ処理を最小化**：リアルタイム処理のためには、小さなデータ単位での即時処理が望ましい。
- **イベント駆動アーキテクチャ（EDA）** を採用し、データフローを最適化。
- **メッセージの圧縮**（例: Protocol Buffers, Avro）を行い、データ転送量を削減。

#### 3.3 スケーラビリティの向上
- **ロードバランサ（Nginx, HAProxy）** を活用し、WebSocketサーバーの負荷を分散。
- **マイクロサービスアーキテクチャ** により、コンポーネントごとのスケールを最適化。
- **データベースの最適化**（例: Redisキャッシュの活用）により、データ取得のレイテンシを削減。

---

### 4. 高パフォーマンスリアルタイムシステムの設計パターン

| 設計パターン | 特徴 | 利用シナリオ |
|-------------|------|------------|
| WebSocket + メッセージキュー | 高速な双方向通信 | チャットアプリ、ゲーム、ライブ配信 |
| Kafka + WebSocket | 大量データのリアルタイム処理 | IoT、ログ監視、データ分析 |
| Server-Sent Events (SSE) | 軽量なリアルタイム通知 | SNS、ニュースフィード |
| WebRTC | ピアツーピアのリアルタイム通信 | ビデオ通話、音声チャット |

---

### 5. まとめ
リアルタイムシステムの構築では、**WebSocket、メッセージキュー、低レイテンシ最適化** などの技術を組み合わせることが鍵となります。適切なアーキテクチャを選択し、ネットワーク・データ処理・スケーラビリティを最適化することで、高パフォーマンスなリアルタイムシステムを実現できます。

**あなたのプロジェクトでは、どのリアルタイム技術を使用していますか？** コメントで意見を共有してください！ 🚀
データベースレプリケーション完全ガイド：高可用性と高速データ同期の最適解

## データベースレプリケーション完全ガイド：高可用性と高速データ同期の最適解

### 1. はじめに
データベースの可用性とデータ同期速度は、現代の分散システムにおいて最も重要な課題の一つです。特に、ユーザーが世界中に広がる大規模なシステムでは、データの一貫性を保ちつつ、低遅延でレプリケーションを行うことが求められます。本記事では、データベースレプリケーションの主要な種類を解説し、それぞれのメリット・デメリット、そして最適な選択肢について深掘りします。

---

### 2. データベースレプリケーションの基本概念

データベースレプリケーション（DB Replication）とは、あるデータベース（プライマリ）から他のデータベース（セカンダリ）にデータを複製するプロセスのことを指します。これにより、システム全体の耐障害性を高め、負荷分散を実現できます。

レプリケーションは以下の目的で利用されます：
- **高可用性（HA）**：障害発生時に迅速なフェイルオーバーを可能にする。
- **負荷分散（Load Balancing）**：リードクエリを複数のレプリカに分散し、パフォーマンスを向上させる。
- **データのバックアップ**：レプリカを災害復旧（DR: Disaster Recovery）に活用。
- **地理的分散**：ユーザーに近いデータセンターでデータを提供し、遅延を削減。

---

### 3. レプリケーションの種類と特性

データベースのレプリケーション方式にはいくつかの主要な種類があり、それぞれ特徴が異なります。

#### 3.1. **同期レプリケーション（Synchronous Replication）**
**特性:**
- トランザクションがプライマリDBにコミットされる前に、すべてのレプリカにデータが反映される。
- 一貫性が高いが、ネットワーク遅延の影響を受けやすい。

**適用シナリオ:**
- ミッションクリティカルなシステム（金融取引、医療システムなど）。
- データの整合性が最優先される環境。

**課題:**
- レイテンシの増加によるパフォーマンス低下。

#### 3.2. **非同期レプリケーション（Asynchronous Replication）**
**特性:**
- プライマリDBがコミットした後、一定の遅延でセカンダリDBにデータが適用される。
- 高速な書き込みが可能。

**適用シナリオ:**
- グローバルに分散されたシステム（CDN、ソーシャルメディアなど）。
- 読み取り負荷が高いが、一貫性よりも可用性を優先する環境。

**課題:**
- データロスのリスクが存在（プライマリ障害時のデータ未適用問題）。

#### 3.3. **セミ同期レプリケーション（Semi-Synchronous Replication）**
**特性:**
- プライマリDBが少なくとも1つのレプリカにデータ適用を確認した後にコミット。
- 整合性と可用性のバランスを取る。

**適用シナリオ:**
- 可用性と整合性の両方を求めるシステム。
- マルチリージョンアプリケーションでの利用。

**課題:**
- 一定の遅延は避けられない。

#### 3.4. **マルチマスターレプリケーション（Multi-Master Replication）**
**特性:**
- 複数のデータベースが同時にプライマリとして機能し、書き込みが可能。
- 柔軟なデータ管理が可能だが、コンフリクト解決が必要。

**適用シナリオ:**
- 高可用性が求められるSaaSシステム。
- 書き込み負荷が複数のデータセンターに分散される環境。

**課題:**
- データ競合（Conflicts）の管理が複雑。

---

### 4. レプリケーション方式の選択基準

システムに最適なレプリケーションを選択するためには、以下の要素を考慮する必要があります。

| 基準 | 同期 | 非同期 | セミ同期 | マルチマスター |
|------|------|------|------|------|
| データ整合性 | 高 | 低 | 中 | 中 |
| 可用性 | 低 | 高 | 高 | 非常に高 |
| 遅延 | 高 | 低 | 中 | 中 |
| 複雑性 | 中 | 低 | 中 | 高 |

例えば、**銀行の取引システム**であれば**同期レプリケーション**が最適ですが、**グローバルなコンテンツ配信システム**では**非同期レプリケーション**の方が適しています。

---

### 5. 高速データ同期のための最適化戦略

高可用性と低遅延を両立するための具体的な最適化手法をいくつか紹介します。

1. **書き込み圧縮（Write-Ahead Logging, WAL）最適化**: 変更データのみをログに記録し、転送量を削減。
2. **レプリケーション遅延モニタリング**: PrometheusやGrafanaを用いてレプリケーション遅延を監視。
3. **マルチリージョンデプロイメント**: Geo-Distributedデータベースを採用し、ユーザーに近いリージョンでデータを提供。
4. **リードレプリカの活用**: 負荷分散のためにリードクエリをレプリカへ振り分ける。

---

### 6. まとめ
データベースレプリケーションは、システムのスケーラビリティや可用性を向上させる強力な技術ですが、その選択と実装には慎重な検討が必要です。用途に応じた最適なレプリケーション方式を採用することで、高速なデータ同期と高可用性を実現できます。

**皆さんのシステムでは、どのレプリケーション方式を採用していますか？** コメントで意見を共有してください！
C# で Excel を画像に変換する方法

Excel は、データや情報などを保存および編集するために使用できる非常に実用的なドキュメント形式です。Excel ドキュメント内のテーブルやデータを Word や PowerPoint ドキュメントに貼り付ける場合、Excel を画像に変換するのは良い選択肢です。また、それを画像に変換することで、他の人によって内容が変更されるのを防ぐことができます。この記事では、無料の.NET ライブラリを使用して、**C# で Excel を JPG または PNG 画像に変換する**方法を紹介します。
* [ワークシート全体を画像に変換する](#ワークシート全体を画像に変換する)
* [特定のセル範囲を画像に変換する](#特定のセル範囲を画像に変換する)


## 無料の.NETライブラリをインストールする
始める前に、[**Free Spire.XLS for .NET**](https://www.e-iceblue.com/Introduce/free-xls-component.html) ライブラリをインストールする必要があります。  このライブラリは、無料でExcelファイルを作成、編集、変換することができますが、ページ数の制限があります。

それをインストールする方法は 2 つあります。
**1.** Free Spire.XLS for .NET パッケージをダウンロードし、それを解凍してから、.NET プログラムに dll を手動で参照設定します。

https://www.e-iceblue.com/Download/download-excel-for-net-free.html

**2.** Nuget を介して直接無料のライブラリをインストールします。

https://www.nuget.org/packages/FreeSpire.XLS/

## ワークシート全体を画像に変換する

以下は詳細な手順です。

1. **`Workbook`** インスタンスを作成します。
1. **`Workbook.LoadFromFile()`** メソッドを使用して Excel ドキュメントをロードします。
1. **`Workbook.Worksheets[]`** プロパティを使用して、特定のワークシートを取得します。
1. **`Worksheet.SaveToImage()`** メソッドを使用して、ワークシートを画像として保存します。

C#のコード：
```csharp
using Spire.Xls;
namespace Xls2Image
{
    class Program
    {
        static void Main(string[] args)
        {
            //Workbook インスタンスを作成する
            Workbook workbook = new Workbook();

            //Excel サンプルドキュメントをロードする
            workbook.LoadFromFile(@"sample.xlsx");

            //最初のワークシートを取得する
            Worksheet sheet = workbook.Worksheets[0];

            //ワークシートを画像として保存する
            sheet.SaveToImage("result1.jpg");
        }
    }
}
```

結果：
![ExceltoImage.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2811193/6d2dc024-d0fc-4c34-85b2-cbc7ebf64d0e.png)


## 特定のセル範囲を画像に変換する

以下は詳細な手順です。

1. **`Workbook`** インスタンスを作成します。
1. **`Workbook.LoadFromFile()`** メソッドを使用して Excel ドキュメントをロードします。
1. **`Workbook.Worksheets[]`** プロパティを使用して、特定のワークシートを取得します。
1. セル範囲を指定し、**`Worksheet.ToImage()`** メソッドを使用して Image オブジェクトとして保存してから、**`Image.Save()`** メソッドを使用してオブジェクトを特定の画像形式で保存します。


C#のコード：
```csharp
using Spire.Xls;
using System.Drawing.Imaging;

namespace SpecificCellsToImage
{

    class Program
    {
        static void Main(string[] args)
        {
            //Workbook インスタンスを作成する
            Workbook workbook = new Workbook();

            //Excel サンプルをロードする
            workbook.LoadFromFile(@"sample.xlsx");

            //最初のワークシートを取得する
            Worksheet sheet = workbook.Worksheets[0];

            //セル範囲を指定して、特定の画像形式で保存する
            sheet.ToImage(1, 1, 6, 5).Save("result2.png", ImageFormat.Png);
        }
    }
}
```

結果：
![CellRangetoImage.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2811193/d1cfbece-a296-463a-bfa2-c4c28c03e7c5.png)
九九表を罫線入りで出力 を Array.from()と.repeat() でスマートに！

Paizaの九九表を作る問題で、最初はただの`for`ループでしっかり書いてたんだけど…気づいたらコードがだいぶ長くなってて「うーん…」ってなった…。そこで登場したのが`Array.from()`！これを使うと一気にコードがスッキリした！メモを記録するよ。

## <br>問題: 九九表を整列して出力せよ！

📌 入力なし
📌 出力例：
```
 1 |  2 |  3 |  4 |  5 |  6 |  7 |  8 |  9
==========================================
 2 |  4 |  6 |  8 | 10 | 12 | 14 | 16 | 18
==========================================
 ...（省略）...
==========================================
 9 | 18 | 27 | 36 | 45 | 54 | 63 | 72 | 81
```

- 横の数値間では | (半角スペース 2 つとバーティカルライン)、縦の数値間では = で区切って出力
- ただし、数値を出力する際は 2 けたになるよう半角スペース埋めで出力
- また、縦の数値間で = を出力する際は、その上の行と文字数が等しくなるように出力


https://paiza.jp/works/mondai/stdout_primer/stdout_primer__specific_format_step3

## <br>最初のコード: 
```js
for (let i = 1; i <= 9; i++) {
    for (let j = 1; j <= 9; j++) {
        if (j === 9) {
            process.stdout.write(String(i * j).padStart(2, ' ') + "\n");
        } else {
            process.stdout.write(String(i * j).padStart(2, ' ') + " | ");
        }
    }
    if (i !== 9) {
        console.log("==========================================");
    }
}
```

## <br>解決法：`Array.from()`を使う
```js
for (let i = 1; i <= 9; i++) {
    console.log(Array.from({ length: 9 }, (_, j) => String(i * (j + 1)).padStart(2, ' ')).join(" | ")
    );
    if (i !== 9) console.log("=".repeat(2 * 9 + 3 * 8));
}
```

💡 改善ポイント

✅ `Array.from()` でループを削減！
- `Array.from({ length: 9 }, (_, j) => ...)` で九九の各行を配列に変換
- `(_, j) => i * (j + 1)` で九九の結果を生成
- `.join(" | ")` で簡単に整列

<br>✅ 区切り線の計算もスマートに！
- 2 * 9 = 18 （各数字を2桁分確保）
- 3 * 8 = 24 （区切り`|`は8個）
- 18 + 24 = 42 文字の `=` を出力
    
<br>📌基本構文
```js
str.repeat(count);
```
- `str`: 繰り返したい文字列。
- `count`: 繰り返す回数。`count` が `0` 以下の場合、空文字列を返します。

<br>✅ 可読性アップ！
- `console.log()` だけで一気に出力できてスッキリ



## <br>まとめ

少しでもシンプルに、見やすく、効率的なコードを書くためには、このような小さな工夫が大事！以下のポイントを覚えておこう！

- `Array.from()` で配列を簡単に生成
- `padStart()` で数字を2桁に整列
- `repeat()` で区切り線を簡単に作成

これらを使いこなせれば、コードがスムーズに書けるし、可読性もUP！

<br>[僕の失敗談と解決話！](https://paizabeginner.wordpress.com/2025/04/01/paiza%e3%81%a7%e5%9f%ba%e6%9c%ac%e3%83%9e%e3%82%b9%e3%82%bf%e3%83%bc%ef%bc%9a%e4%b9%9d%e4%b9%9d%e8%a1%a8%e3%82%92%e7%bd%ab%e7%b7%9a%e5%85%a5%e3%82%8a%e3%81%a7%e5%87%ba%e5%8a%9b-%e3%82%92%e3%82%b9/)
Python(Matplotlib)で円グラフや箱ひげ図を描くためのメモ

# はじめに

Matplotlibを使って、円グラフや箱ひげ図を作ります。Copilotにいろいろ聞きました。

# 円グラフ

以下のような関数を用意。

~~~ Python hoge1.py
#-------------------------
# 円グラフ(一つだけ)を作成
# 値を表示するカスタム関数
def custom_autopct_for_pie_chart(pct, all_values):
    total = sum(all_values)
    value = int(round(pct * total / 100.0))  # 値を計算
    return f'{value}'  # 値を返す

def make_pie_chart(value, label, str, colors, filename):
    print('draw ' + filename)

    # グラフの設定
    #my_explode = (0, 0, 0, 0, 0, 0.1)  # "最初の項目"を少し外に出す
    fig, ax = plt.subplots(figsize=(10, 10))
    wedges, texts, autotexts = ax.pie(
        value,
        startangle=90,
        colors=colors,
        autopct=lambda pct: custom_autopct_for_pie_chart(pct, value),  # autopctは自家製
        wedgeprops={'edgecolor': 'white', 'linewidth': 2},
        explode=my_explode,
        textprops=dict(fontsize=14),
        #labels=label,
        #labeldistance=1.2,
    )
    # autopctの文字サイズ変更
    for autotext in autotexts:
        autotext.set_fontsize(20)  # 文字サイズを変更

    # タイトルを追加
    plt.title(str)
    plt.legend(label, bbox_to_anchor=(1.05, 1), loc='upper right')  # ラベルを凡例として表示

    # 保存
    plt.savefig(filename)
    
    plt.show()
~~~

# 箱ひげ図

箱ひげ図は`boxplot`というそうです。

~~~ Python hoge2.py
# 箱ひげ図の作成
def make_boxplot(values, title_str, colors, filename, legend_flg=False):
    print('draw ' + filename)

    # 箱ひげ図＝boxplot
    fig, ax = plt.subplots()
    box = ax.boxplot(values, patch_artist=True, labels=out_column_a)

    # 箱ひげ図の色を指定
    for patch, color in zip(box['boxes'], colors):
        patch.set_facecolor(color)
    
    # グラフのタイトルとラベルを設定
    ax.set_title(title_str)
    ax.set_xlabel('カテゴリー')
    ax.set_ylabel('歩数')

    # 保存
    plt.savefig(filename)

#    plt.show()
~~~

Copilotに聞きながら作れるので、今後はこのような関数を予め用意するメリットが薄れていくのか？　とはいえ、仕様が理解できている関数の方が拡張性や保守性は高いからなぁ。

（おわり）
outlook メール下書き使って、ネット検索

<h3>いるもん</h3>

```ruby:インスト
 pip install whoosh
```

<br>

<h3>前提条件</h3>
Gmailでやりたい時、管理者アカウント作らんと有効にできない

管理者アカウント設定方法

```ruby:
このリンクにアクセス↓

https://admin.google.com/

メニュー →  [アプリ] > [Google Workspace] > [Gmail] > [エンドユーザーのアクセス]→[POP と IMAP アクセス] 
→[どのユーザーも IMAP アクセスを使用できるようにする] 
→保存
```

<br>
<h3>やる手続き</h3>

```ruby:IMAPをGmailで有効にする

    Gmailにログイン → 設定 → すべての設定を表示 → 
    
    「転送とPOP/IMAP」→ 「IMAPアクセス」 → 
    
    「IMAPを有効にする」 →  「変更を保存」をクリック
```

<h3>code</h3>

```ruby: ✅ 
import imaplib
import email
import requests
from bs4 import BeautifulSoup

# IMAPの設定
IMAP_SERVER = "outlook.office365.com"
EMAIL_ACCOUNT = "your-email@outlook.com"
APP_PASSWORD = "your-app-password"  # もし2段階認証を使っている場合のアプリパスワード

# IMAPで接続
mail = imaplib.IMAP4_SSL(IMAP_SERVER)
mail.login(EMAIL_ACCOUNT, APP_PASSWORD)
mail.select("Drafts")  # 下書きフォルダを選択

# "メモ"というタイトルの下書きを検索
status, messages = mail.search(None, 'SUBJECT "メモ"')

# メールIDを取得
email_ids = messages[0].split()

for e_id in email_ids:
    status, msg_data = mail.fetch(e_id, "(RFC822)")
    for response_part in msg_data:
        if isinstance(response_part, tuple):
            msg = email.message_from_bytes(response_part[1])
            subject = msg["Subject"]
            body = msg.get_payload(decode=True)
            text = body.decode("utf-8", errors="ignore") if body else ""
            
            print(f"📄 メモの内容:\n{text}\n")
            
            # メモの内容を検索する
            search_query = text.strip()  # 検索ワードを取り出す
            if search_query:
                print(f"検索中: {search_query}")
                
                # 例：Googleで検索
                url = f"https://www.google.com/search?q={search_query}"
                response = requests.get(url)
                
                # BeautifulSoupでHTMLをパース
                soup = BeautifulSoup(response.text, "html.parser")
                results = soup.find_all('h3')  # 検索結果の見出しを抽出

                for result in results:
                    print(result.get_text())  # 見出しを表示

```
Next.jsを企業向けに最適化！2025年のアプリ構築術 | シリーズ総概観

## シリーズの目的
このシリーズは、Next.jsを活用して企業向けウェブアプリケーションを構築し、最適化する方法を学ぶことを目的としています。ブログをベースに、多言語対応、状態管理、データ処理、ダッシュボード、スケーラビリティといった企業ニーズに応える機能を段階的に実装しました。初心者から中級者までが、実践的なスキルを習得できる内容です。

---

## シリーズの概要
全5エピソードで構成され、企業向けアプリの主要機能を網羅しています。以下は各エピソードの要点です：

### エピソード1: Next.jsで多言語システムを構築
- `next-i18next`で多言語対応をセットアップ。
- 日本語と英語をブログに追加。

### エピソード2: Zustandで状態管理を強化
- Zustandで軽量な状態管理を実装。
- 「いいね」機能をブログに追加。

### エピソード3: GraphQLとApollo Clientの統合
- Apollo ClientでGraphQLデータを取得。
- SupabaseからGraphQLにデータソースを切り替え。

### エピソード4: 管理ダッシュボードの構築
- Chart.jsで投稿統計を視覚化。
- 管理者権限でダッシュボードを保護。

### エピソード5: Redisでスケーラビリティを強化
- Redisでキャッシュを実装。
- 読み込み速度を最適化し、大規模運用に対応。

---

## 学べる技術と成果物
このシリーズを通じて、以下の技術を習得できます：
- **多言語対応**: `next-i18next`でグローバル化。
- **状態管理**: Zustandで効率的なインタラクション。
- **データ処理**: GraphQLとApollo Clientで柔軟な取得。
- **管理機能**: Chart.jsと権限管理。
- **スケーラビリティ**: Redisで高速化と負荷分散。

**成果物**：
- 多言語対応のブログ。
- インタラクティブな「いいね」機能。
- GraphQLベースのデータ取得。
- 管理者向けダッシュボード。
- キャッシュ付きでスケーラブルなアプリ。

---

## シリーズの価値
- **実践的**: 企業ニーズに基づいた機能を実装。
- **最新トレンド**: 2025年の技術（Next.js、GraphQL、Redis）を活用。
- **段階的学習**: 基礎から応用まで無理なく進行。

---

## 各エピソードへのリンク
以下に各エピソードへのリンクをまとめました。ぜひ振り返って復習してください：
- [エピソード1: Next.jsで多言語システムを構築](https://qiita.com/BNR-Long/items/c85b6430dadb2b5ada12)
- [エピソード2: Zustandで状態管理を強化](https://qiita.com/BNR-Long/items/3da2bbd31b052604b8fd)
- [エピソード3: GraphQLとApollo Clientの統合](https://qiita.com/BNR-Long/items/cc81968218393df86f82)
- [エピソード4: 管理ダッシュボードの構築](https://qiita.com/BNR-Long/items/ac919ff647492407bbdd)
- [エピソード5: Redisでスケーラビリティを強化](https://qiita.com/BNR-Long/items/f727ba0525cae4961eaa)

※リンクは後で追加してください。

---

## 最後に
このシリーズは、Next.jsを使った企業向けアプリ開発の全貌を体験する旅でした。学んだ技術を活かして、独自のプロジェクトを拡張したり、新たな挑戦を始めたりしてください。2025年のウェブ開発で、あなたのスキルが輝くことを願っています！

この総概観が役に立ったと思ったら、ぜひ「いいね」を押して、ストックしていただければ嬉しいです！シリーズを振り返りながら、次のステップへ進んでください！
DifyにOllamaを追加する手順

## はじめに

DifyからOllamaを使えるようにする設定です。
OllamaにLLMがインストールされていることが前提になります。

## 環境
Ubuntu20.4 （Windows10 + Vagrant）

## 手順

oolamaデーモンの設定ファイルに１行追加します。この１行を追加することで、DifyにOllamaを登録するときのエラーが回避されるようです。

```
$vi /etc/systemd/system/ollama.service
```

```
[Service]
Environment="OLLAMA_HOST=0.0.0.0"
```

デーモンを再起動します。

```
$systemctl daemon-reload
$systemctl restart ollama.service
```

ブラウザからローカル環境のDifyを起動してログインします。

```
http://IPアドレス/install
http://192.168.33.10:8080/install
```
画面から、設定－モデルプロバイダーを選択します。モデルプロバイダーの中から「Ollama」を選択して「モデルを追加」をクリックします。

![無題.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/94029/b4f36c5a-7fb1-f824-6116-9ba16236a054.png)

Ollamaの設定を行います。


![無題.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/94029/5d07cf3d-b2ee-6b43-a641-55177aad650f.png)

「Model Name」はOllamaの公式サイトからインストールしたモデルを検索すれば分かります。

「Base URL」にはDockerのIPアドレス（ローカル環境からDifyを起動するときのIP）を設定します。ポート番号は「11434」固定値です。

「Model context size」はOllamaの公式サイトのモデル一覧から確認ができます。分からない場合はデフォルト値でいいようです。


## トラブルシュート

Base URLの設定が異なっている可能性があります。

![無題.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/94029/01accd72-46c9-79dd-c064-7377eb45fdc9.png)

大きなモデルをインストールしてしまい、動かすのにメモリ容量が少ないと言われました。もっと軽いモデルをインストールしましょうということです。

![無題.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/94029/401ca949-1212-667a-84c9-de0f4c15e3c2.png)
【#0】C言語未経験がC#を触ってみた【学習方針編】

## 1. 記事の概要
・タイトルの通りです。著者はC言語を一切触ったことがありませんが、Unityでゲームを作りたいので、C#の学習記録を備忘録的に残せたらいいなと思い執筆しました。
・著者はSwiftの実務経験が3年ほどで「LaravelやFlutterちょっと分かります」くらいのスキル感です。

## 2. 学習方針
下記の方が紹介されているサイトを使って勉強することにしました。
https://qiita.com/YouKnow/items/34a24351991c6744b691

紹介されている中で、今回は「未確認飛行C」様が執筆されている「C#によるプログラミング入門」の記事を読みつつ、適宜コードをコンパイルしていきます。現状、学習の段階ではローカルで何かを作る予定はないので、環境構築はローカルじゃなくオンラインで十分と判断し、paiza.ioを使って出力を確認しようと思います。

https://ufcpp.net/study/csharp/

ただ、paizaの言語仕様のページを見ていると、バージョンが`Mono JIT compiler version 6.8.0.105`なので、学習を進めていく上で、ローカルで最新版のバージョンを指定した状態でコンパイルを通さなければいけない羽目になりそうではありますw

https://paiza.jp/guide/language

ひとまず、Hello,Worldを実行してみると、早速コードの差分がありますね。

●C#によるプログラミング入門
```C#
Console.WriteLine("皆様、はじめまして");
```

●Paiza.io
```C#
// 省略
System.Console.WriteLine("Hello C#");
// 省略
```

Print文1行に絞ってみると、10.0.0では**Console.WriteLine**からprintしたい文字列を呼び出せるのに対して、古いバージョンのpaiza.ioではSystemのメソッドであることを明示的に示さないといけないようです。

ただ、「C#によるプログラミング入門」はアップデートのたびに各バージョンで何が新しくできるようになったのかを一覧で示してくれているため、そちらも併用して理解を進めていけば問題がなさそうな気がしています。

<hr>

（追記）
コメントで教えていただきました。
using System;をインポートし、下記のように記述することでpaizaでもコンパイルが通ります。

```C#
using System;

public class Hello{
    public static void Main(){
        Console.WriteLine("Hello C#");
    }
}
```
<hr>

またC#ではこのような概念があるようです。
> usingは「名前空間」で、 classは「クラス」で、 publicは「実装の隠蔽」で、 staticは「静的メンバー」で、 voidは「関数」で説明していきます。

 ●C#で使われるプログラムのまとめ
|プログラム|定義|
|:---|:---|
|using|名前空間|
|class|クラス|
|public|実装の隠蔽|
|static|静的メンバー|
|void|関数|

（実装の隠蔽は初めて聞いた名前だ......）

## 3. コメント

ソースコード内で使われるコメントは以下の3つがあるようです。

|コメント|使用用途|
|:---|:---|
|//|単行コメント|
|/**/|複数行にわたるコメント|
|///|Docコメント|

<hr>

この投稿ではここまで。
次回は値の入力などを学んでいきます。