OmniAICreator/Qiita-1.07M huggingface dataset:
JavaScriptにおけるモジュール設計：ESModulesとCommonJSの構造的選定と最適戦略

## 概要

JavaScriptのモジュール構文は、ただの構文選択にとどまらない。  
それは**“コードの依存構造、分割単位、実行タイミングを制御し、プロジェクト全体の設計哲学を反映するアーキテクチャ戦略”**である。

ESModules（ESM）とCommonJS（CJS）は互換性がありそうで実は根本的に異なる。  
**同期 vs 非同期、評価タイミング、ファイル分割の哲学、環境ごとの挙動差**。  
それらを踏まえた上で、モジュールの**選定・設計・切り替え判断**を明確にする必要がある。

本稿では、**ESM/CJS の構造的違い・適用環境・設計上の注意点・ハイブリッド戦略**を網羅的に解説する。

---

## 1. 基本構文の比較

### ESModules（ESM）

```ts
// add.js
export function add(a, b) {
  return a + b;
}

// index.js
import { add } from './add.js';
```

- ✅ **静的構文**（ツール・解析・最適化に強い）
- ✅ **トップレベル await** など最新機能に対応

---

### CommonJS（CJS）

```js
// add.js
function add(a, b) {
  return a + b;
}
module.exports = add;

// index.js
const add = require('./add');
```

- ✅ **同期読み込み**（Node.jsの標準構造）
- ✅ ファイル単位で実行時に評価される

---

## 2. 実行タイミングの違い

| 特性                     | ESModules            | CommonJS              |
|--------------------------|----------------------|------------------------|
| ロード方法               | 非同期（事前に解決） | 同期（即時評価）       |
| import/export の解釈     | 静的解析              | 動的（requireで評価） |
| 実行タイミング           | ロード後に評価        | 読み込み時に即時評価  |

- ✅ ESMは**事前解決（preloading）**により、依存関係の最適化が可能
- ✅ CJSは**実行時の柔軟性**に長けるが、最適化しづらい

---

## 3. 環境による選定ポイント

| 使用環境         | 推奨モジュール方式     |
|------------------|------------------------|
| フロントエンド    | ✅ ESModules（標準）    |
| Node.js (新規)    | ✅ ESModules（推奨）    |
| Node.js (旧構成)  | ✅ CommonJS（互換維持） |
| ライブラリ開発    | ✅ 両対応 or dual export |

---

## 4. ハイブリッド設計とDual Export戦略

```json
// package.json
{
  "type": "module", // ← ESMとして解釈される
  "exports": {
    ".": {
      "require": "./index.cjs",
      "import": "./index.mjs"
    }
  }
}
```

- ✅ ライブラリとして公開する際は**ESMとCJSの両対応**がベター
- ✅ `exports` フィールドで**エントリーポイントを切り分ける**

---

## 5. import/export の設計的ベストプラクティス

- ✅ **named export を優先**する（ツリーシェイキング可能）
- ✅ default export は**構造の意味が曖昧になりがち**
- ✅ ルートレベルで import すること（ネスト import は避ける）

```ts
// ❌ import のネスト
function load() {
  import('./module.js').then(mod => mod.init());
}

// ✅ 依存は事前に宣言する
import { init } from './module.js';
```

---

## 設計判断フロー

```text
① 実行環境はどこか？（Node / ブラウザ / 両方）

② ロードタイミングと構文の柔軟性どちらを優先すべきか？

③ モジュールの分割粒度と依存管理方針は定まっているか？

④ 今後ESMに移行する可能性があるか？ → デフォルトはESMで構築

⑤ ライブラリとして配布する？ → dual export戦略を選定
```

---

## よくあるミスと対策

### ❌ CJSで `import` を使いSyntaxError

→ ✅ `type: "module"` が設定されていない or 拡張子が `.js` のまま

---

### ❌ `require` と `import` を混在して不可解な挙動

→ ✅ **構文と評価タイミングが異なる**ため、統一 or 分離すべき

---

### ❌ default export に過度依存し、意味の不明瞭な構造に

→ ✅ **明示的な名前付き export に切り替え、構造を明確に**

---

## 結語

モジュール構文は「ファイルを分けるため」ではない。  
それは**“依存と責任の境界を設計し、実行環境に最適化された構造を提供するための構成戦略”**である。

- ESMは構造の静的最適化とモダン仕様に強い  
- CJSはレガシー互換性と即時評価に優れる  
- 最適解は「目的に応じた構文の選定と明示的設計」にある

**JavaScriptにおけるモジュール設計とは、  
“依存を構造として管理することで、拡張と保守を支える実行戦略”である。**
JavaScriptにおけるクラス設計：責務分離と継承/委譲の選定戦略

## 概要

JavaScriptにおけるクラス設計は、ただの構文糖ではない。  
それは**“責務を定義し、オブジェクトの振る舞いを明示的に構造化するための設計戦略”**である。

継承（extends）を使うのか、委譲（composition）でまとめるのか。  
これは機能の共通化だけでなく、**可読性・拡張性・責任の局所性**を左右する重大な設計判断だ。

本稿では、JavaScriptにおける**クラス設計の原則、継承と委譲の使い分け、責務の分割戦略**を包括的に整理する。

---

## 1. クラスの基本構造と責務定義

```ts
class User {
  constructor(name, role) {
    this.name = name;
    this.role = role;
  }

  greet() {
    return `Hello, ${this.name}`;
  }
}
```

- ✅ 状態（プロパティ）と振る舞い（メソッド）をひとまとめに定義
- ✅ クラス1つにつき「1つの責任」が原則（SRP）

---

## 2. 継承：親子関係で構造を拡張する

```ts
class Admin extends User {
  constructor(name) {
    super(name, 'admin');
  }

  hasAccess() {
    return true;
  }
}
```

- ✅ **is-a 関係**が成り立つ場合のみ採用
- ✅ 基本クラスの振る舞いを **拡張・オーバーライド**できる

---

## 3. 委譲（Composition）：機能の再利用と柔軟性の確保

```ts
class Logger {
  log(msg) {
    console.log(`[LOG]: ${msg}`);
  }
}

class Task {
  constructor(name, logger) {
    this.name = name;
    this.logger = logger;
  }

  run() {
    this.logger.log(`Running ${this.name}`);
  }
}
```

- ✅ 機能の再利用を目的とする場合は **has-a（委譲）** を採用
- ✅ コンポーネント単位で機能を差し替えやすく、**テストもしやすい**

---

## 4. 継承 vs 委譲：判断基準

| 観点               | 継承（extends）         | 委譲（composition）     |
|--------------------|--------------------------|--------------------------|
| 関係性             | is-a                     | has-a                    |
| 構造の固定度       | 高い                     | 低い（差し替え可能）     |
| 再利用性           | 限定的                   | 高い                     |
| 拡張性             | サブクラスごとに増殖     | 必要部品だけ差し替え可能 |
| テスト容易性       | 状態を持ちやすく重い     | 単機能なので軽量         |

---

## 5. 抽象化とインタフェース設計の意識（TypeScriptとの連携）

```ts
interface Storable {
  save(): void;
}

class FileStore implements Storable {
  save() {
    // ファイルへ保存
  }
}

class DBStore implements Storable {
  save() {
    // DBへ保存
  }
}
```

- ✅ **具象に依存せず、振る舞いの契約で設計できる**
- ✅ 複数の実装を **構文レベルで切り替え可能**

---

## 設計判断フロー

```text
① クラスが担う責務は1つに明確化されているか？

② 継承の関係は is-a を満たすか？ → それ以外なら委譲を検討

③ 再利用したいのは構造か振る舞いか？ → 構造なら委譲が向く

④ テスト対象の振る舞いを独立させやすいか？

⑤ 構成要素はコンポーネントとして交換可能に設計されているか？
```

---

## よくあるミスと対策

### ❌ 機能ごとにクラスを分けず、全てを1クラスに集約

→ ✅ **単一責任原則（SRP）を意識して分割**

---

### ❌ 明確な is-a 関係がないのに extends を使っている

→ ✅ **機能の再利用は委譲で行い、構造の健全性を保つ**

---

### ❌ クラスに直接Loggerや依存物を埋め込み、差し替えが困難

→ ✅ **外部から注入（DI）し、柔軟性を担保**

---

## 結語

クラスは「便利な構文」ではない。  
それは**“振る舞いと状態を構造として統合し、責任ある抽象化を行うための設計戦略”**である。

- 継承は拡張のために、委譲は柔軟性のために使う  
- SRP・テスト容易性・構造の健全性をすべて意識する  
- 機能単位で分離されたオブジェクト設計こそが、保守性を最大化する

**JavaScriptにおけるクラス設計とは、  
“責務と構造を秩序化し、進化に耐える抽象的インタフェースを構築する戦略である。”**
JavaScriptにおけるDOM操作設計：クリーンなセレクタ戦略と操作の抽象化


## 概要

JavaScriptによるDOM操作は「document.querySelectorで要素を取って、何かする」だけではない。  
それは**“ビューとロジックを安全かつ効率的に繋ぐための抽象化された制御構造”**である。

UIの複雑化、再描画の多発、イベントの動的登録が増える中で、**直感的で安全なDOMアクセス戦略と、操作の責務分離**が求められる。

本稿では、**セレクタ戦略、操作の抽象化、イベントの委譲、状態同期など**を踏まえたDOM操作設計の原則を解説する。

---

## 1. セレクタ設計：依存性を最小限に

```ts
const button = document.querySelector('.submit-button');
```

- ✅ クラス名は**スタイル変更で壊れるリスクあり**
- ✅ 理想は `data-*` 属性の使用

```ts
const button = document.querySelector('[data-action="submit"]');
```

- ✅ 明示的に**役割が分かる属性**を付与することで、**設計に意味を持たせる**

---

## 2. DOM操作の抽象化：ロジックを関数に分離

```ts
function setText(el, text) {
  if (el) el.textContent = text;
}

function showError(message) {
  const el = document.querySelector('[data-error]');
  setText(el, message);
}
```

- ✅ 再利用可能な関数単位で定義し、**操作をロジックから切り離す**
- ✅ DOMの取得 → 操作 → 状態反映 の流れを明示

---

## 3. 動的要素への対応：イベント委譲の活用

```ts
document.addEventListener('click', (e) => {
  if (e.target.matches('[data-action="delete"]')) {
    const id = e.target.dataset.id;
    deleteItem(id);
  }
});
```

- ✅ 動的に生成された要素にも対応可能
- ✅ **イベントをルートで拾い、必要な要素だけ処理する構造**

---

## 4. DOMと状態の同期制御

```ts
function toggleVisibility(el, show) {
  el.style.display = show ? 'block' : 'none';
}

function updateStateUI(state) {
  const loader = document.querySelector('[data-loader]');
  toggleVisibility(loader, state.loading);
}
```

- ✅ アプリケーション状態とUI状態を明確に同期
- ✅ `display` / `aria-hidden` など、**アクセシビリティにも配慮**

---

## 5. DOMキャッシュとパフォーマンス戦略

```ts
const DOM = {
  form: document.querySelector('form'),
  input: document.querySelector('[data-input]'),
  result: document.querySelector('[data-result]')
};

// 再取得せずキャッシュ経由で操作
DOM.result.textContent = 'Done!';
```

- ✅ 再取得コストを削減
- ✅ 大規模UIでは**DOM参照の統合管理**を検討（例：ViewModel）

---

## 設計判断フロー

```text
① DOM操作が散らばっていないか？ → 操作関数にまとめる

② セレクタは意味のあるものか？ → クラス名以外の構造で取得する

③ 状態とUIがズレていないか？ → 同期関数を設計する

④ 動的要素への対応はできているか？ → イベント委譲を検討する

⑤ DOM参照の重複取得が頻発していないか？ → キャッシュ構造を設ける
```

---

## よくあるミスと対策

### ❌ `.querySelector()` を毎回呼び出してコスト過多

→ ✅ **初期化時に取得 → キャッシュして再利用**

---

### ❌ クラス名でDOM操作 → スタイル変更で破壊

→ ✅ **`data-*` 属性でセマンティックに管理**

---

### ❌ 状態更新とUI変更がバラバラに記述されて同期が崩壊

→ ✅ **UI変更処理を状態変更トリガーの中に統一する**

---

## 結語

DOM操作は「要素をいじる手段」ではない。  
それは**“構造・意味・状態を一貫した形で反映し、ユーザーインターフェースの信頼性を設計するための制御構造”**である。

- セレクタは意味で選び、変更に強い構造へ  
- 操作はロジックから切り離し、責務を明示  
- 状態とDOMを同期させ、UIの整合性を保つ

**JavaScriptにおけるDOM設計とは、  
“UIをコードとして制御可能にするための構造的戦略”である。**
JavaScriptにおけるオブジェクトリテラル設計：構造的データ定義と動的プロパティの使い方

## 概要

JavaScriptのオブジェクトリテラルは、「データをまとめるための構文」では終わらない。  
それは**“構造を持った意味あるデータ定義を行い、プロパティと責務を柔軟に組み替えるための設計ユニット”**である。

特に、構造化されたデータ管理・辞書的アクセス・プロパティ合成などにおいて、  
**静的と動的のバランスをどうとるか**が設計の質を決定づける。

本稿では、**オブジェクトリテラルの基本構造・プロパティ操作・動的定義・設計的なベストプラクティス**を体系的に整理する。

---

## 1. 基本構造と静的定義

```ts
const user = {
  id: 1,
  name: 'Taro',
  active: true
};
```

- ✅ キーと値がペアで固定された構造
- ✅ 読みやすく、型推論や補完が効きやすい（TypeScriptに強い）

---

## 2. 動的プロパティの定義（Computed Properties）

```ts
const key = 'role';
const user = {
  id: 1,
  [key]: 'admin'
};
```

- ✅ 実行時に決定されるプロパティ名を安全に埋め込める
- ✅ **フォーム入力やAPIレスポンスの変換**などに活用可能

---

## 3. プロパティの追加・削除と副作用の制御

```ts
const obj = { name: 'Taro' };

// ❌ ミューテーション（避けたい）
obj.age = 25;
delete obj.name;

// ✅ 非破壊的に再構成
const newObj = { ...obj, age: 25 };
```

- ✅ 状態管理や比較が必要な場面では **非破壊的構築が望ましい**
- ✅ `Object.assign` やスプレッドで **柔軟に組み立てる**

---

## 4. 辞書型構造の設計（Record風）

```ts
const configMap = {
  production: 'https://api.prod.example.com',
  staging: 'https://api.stg.example.com',
  development: 'http://localhost:3000'
};

const baseURL = configMap[env];
```

- ✅ 動的なルックアップや設定切替が簡潔に記述可能
- ✅ **オブジェクトをMap的に使う構造**は汎用的で強力

---

## 5. オブジェクトベースのパターンマッチ戦略

```ts
const actions = {
  login: () => loginUser(),
  logout: () => logoutUser(),
  refresh: () => refreshSession()
};

const actionName = 'logout';
actions[actionName]?.(); // ✅ logoutUser() 実行
```

- ✅ `switch` よりも **メンテナンス性の高い分岐ロジック**
- ✅ 存在チェックと実行が同時に可能（`?.()`）

---

## 6. Object.entries / Object.keys / Object.values の活用

```ts
const user = { id: 1, name: 'Taro' };

for (const [key, value] of Object.entries(user)) {
  console.log(`${key}: ${value}`);
}
```

- ✅ オブジェクトの内容を **配列的に扱える** → map/filter 可能
- ✅ フロントUIやログ変換などで活躍

---

## 設計判断フロー

```text
① プロパティは固定か？それとも動的に定義されるか？

② 状態は破壊的に更新されていないか？（→ スプレッド再構築へ）

③ パターンマッチング的分岐は switch ではなく辞書で表現できないか？

④ 可読性・保守性を高めるためにオブジェクトベース設計が有効か？

⑤ 過剰に入れ子構造にしていないか？（→ 正規化・flattenを検討）
```

---

## よくあるミスと対策

### ❌ 動的プロパティを誤って `"key"` として文字列扱い

→ ✅ `[key]` と括弧で囲むことで評価を実行

---

### ❌ オブジェクトに直接代入し、状態が汚染

→ ✅ スプレッドや `Object.assign()` を用いた非破壊更新を徹底

---

### ❌ `switch-case` が肥大化して読みにくい

→ ✅ 分岐は **関数辞書に置き換え**て処理を閉じる

---

## 結語

オブジェクトリテラルは「単なる構文」ではない。  
それは**“構造化された意味のあるデータ定義と、動的制御を可能にする柔軟な設計要素”**である。

- 固定構造を表現するにも  
- 動的なルックアップ辞書として使うにも  
- 条件分岐の代替手段として利用するにも

**オブジェクトリテラル設計とは、  
“構造と柔軟性を両立させ、責務ごとに意味を持たせるためのデータ戦略”である。**
JavaScriptにおける例外設計とエラーハンドリング戦略：try-catchの越境と責務分離

## 概要

例外処理は「エラーを捕まえるため」だけにあるのではない。  
それは**“失敗する可能性を前提とした制御構造”であり、アプリケーションの堅牢性を支える設計要素**である。

JavaScriptの `try-catch` はシンプルだが、適用範囲や粒度を誤ると、**本来の責務が不明瞭になり、デバッグ困難なコードを生む**。  
本稿では、**例外設計の粒度、責任の分離、伝播戦略、ドメインとUI層での分担**を含め、エラーハンドリングを構造的に整理する。

---

## 1. try-catch の構文と基本原則

```ts
try {
  const data = JSON.parse(jsonStr);
} catch (err) {
  console.error('JSON parsing failed:', err);
}
```

- ✅ 失敗が「予想される」コードブロックにのみ適用
- ❌ すべての処理を try に包むのはアンチパターン

---

## 2. 層ごとのエラーハンドリング戦略

### ❖ ドメイン層（ビジネスロジック）

- ✅ 原因に応じた**具体的な例外クラスを throw**
- ✅ 曖昧な `throw 'error'` は避ける。**Errorオブジェクトを必ず使用**

```ts
class ValidationError extends Error {}

function validate(user) {
  if (!user.email) throw new ValidationError('Email is required');
}
```

---

### ❖ アプリケーション層（呼び出し元）

- ✅ try-catch で受け止め、ログやUI通知に変換
- ✅ 原則として「**処理と通知の責務を分離**」する

```ts
try {
  validate(input);
} catch (err) {
  if (err instanceof ValidationError) {
    showToast(err.message);
  } else {
    throw err; // 上位に再スロー
  }
}
```

---

## 3. 非同期処理での try-catch

```ts
async function fetchData() {
  try {
    const res = await fetch('/api/data');
    const json = await res.json();
    return json;
  } catch (err) {
    console.error('Fetch failed:', err);
    throw err;
  }
}
```

- ✅ async/await でも通常の try-catch を適用
- ❌ `.catch()` のみで副作用的に扱うのは構造的に脆い

---

## 4. 共通エラーハンドラの抽象化

```ts
function handleError(err: unknown) {
  if (err instanceof NetworkError) {
    logNetwork(err);
  } else if (err instanceof ValidationError) {
    notifyUser(err.message);
  } else {
    reportCritical(err);
  }
}
```

- ✅ **エラーごとに分岐を整理し、設計として定義**
- ✅ 呼び出し元では `handleError()` という責務のみに集中できる

---

## 5. 設計粒度の指針：どこで try-catch を置くべきか

| 処理範囲           | 例外処理設計                         |
|--------------------|--------------------------------------|
| 小さすぎる         | try が乱立し、構造が煩雑になる       |
| 大きすぎる         | 何が失敗したか分からなくなる         |
| 責務単位で配置する | ✅ ロジック単位ごとに try を設ける    |

---

## 設計判断フロー

```text
① 例外は予期された失敗か？ → ifによるバリデーションが適切では？

② どの層で try-catch を置くべきか？（UI/ドメイン/インフラ）

③ エラー種別は Errorクラスで定義されているか？

④ 処理と通知の責務は分離されているか？

⑤ エラーが再スロー or 回収で明示的に扱われているか？
```

---

## よくあるミスと対策

### ❌ catch ですべてを握りつぶしてログだけ吐く

→ ✅ **処理責任に応じて通知 / 再スローの判断を明示**

---

### ❌ `throw 'string'` のような雑な例外投げ

→ ✅ **必ず `new Error()` or カスタムエラーを使用**

---

### ❌ 非同期関数内で try-catch を使わず `.catch()` に処理を書きすぎる

→ ✅ **`await` + `try-catch` で構造を明確化**

---

## 結語

例外処理は「失敗を捕まえるもの」ではない。  
それは**“期待される制御フローの逸脱を、設計的に扱うための構造要素”**である。

- try-catch の配置には戦略が必要  
- 失敗は「例外」ではなく「分岐条件」として設計すべき場合もある  
- 責務の分離こそが、例外処理を「デザイン」に変える鍵

**JavaScriptにおけるエラーハンドリングとは、  
“失敗の発生を想定し、制御下に置くための設計戦略である。”**
Copilot活用：音声×Copilot（通称 オンコパ）による爆速記事作成

###### この記事は以下手順により5分くらいで仕上げています！

# 音声×Copilot（通称 オンコパ）とは？
某商社のAsadaさんが提唱？した、音声入力でのCopilot活用方法です。
勝手に参照させてもらっています↓

https://speakerdeck.com/kasada/yin-sheng-xcopilot-onkopanoshi-jie


## Copilotの音声入力についての解説
まず、Copilotの音声入力機能について簡単に説明します。

**音声入力の利点:**
- **効率性:** 手を使わずに入力できるため、作業効率が向上します。
- **自然な表現:** 話し言葉で入力することで、より自然な文章が作成できます。
- **アクセシビリティ:** 手が不自由な方や、タイピングが苦手な方にも便利です。


## 音声入力を使って記事を仕上げる様子
次に、実際に音声入力を使って記事を仕上げていく過程を示します。
<p><img alt="image.png" height="200" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4003209/96d12df6-4bb6-477f-be92-35a2a53dfcb8.png" width="200"/></p>


### ステップ1: 音声入力の準備
Copilotの音声入力機能を有効にします。
PCなら[Win]+[H]、モバイルなら音声入力を有効にするだけです。

### ステップ2: 記事の構成をテキトーに喋る
記事の大まかな構成を決めます（例：導入、音声入力の利点、実際の使用例、まとめ）。
多少間違えていても大丈夫です。栗田でもクイータでもキータでもそれは些細な問題です。本気で読み方間違えてました、恥ずかしい。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4003209/bca58cd1-0829-49b9-892b-a5fd81533e25.png)

### ステップ3: 違うところも口頭で指摘
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4003209/f2cfc0ea-9e7b-440a-8821-76103685d6c9.png)

### ステップ4: マークダウン形式にしてもらう
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4003209/b75265f7-96a9-498f-a1fb-bd9414051bba.png)

### ステップ5: 転記と微修正
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4003209/06e93f37-68b2-4c96-8f71-6eb4fbe2b0d9.png)

### ステップ: スクリーンショットを挿入
ちまちまペタペタします。



## まとめ
音声入力を活用することで、効率的かつ自然な記事作成が可能になります。ぜひ試してみてください！

![C9DA8F34-B994-42E1-9251-9F80DD029344.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4003209/7266ef70-44d7-45df-ac77-8f7d59213573.png)
Pythonの便利な組み込み関数集

Pythonの便利な組み込み関数・テクニック集
enumerate()のように、Pythonにはデータ操作を効率的に行うための便利な組み込み関数やテクニックがたくさんあります。以下にいくつか紹介します：

## enumerate()
```python 
# 元の配列
arr = [10, 5, 30, 15, 20]

# インデックスと値のペアを作成
indexed_arr = list(enumerate(arr))  # [(0, 10), (1, 5), (2, 30), (3, 15), (4, 20)]
```

## zip() - 複数のイテラブルを同時に処理
```python 
names = ["Alice", "Bob", "Charlie"]
scores = [85, 92, 78]

for name, score in zip(names, scores):
    print(f"{name}: {score}点")
```
## map() - イテラブルの各要素に関数を適用
```python
numbers = [1, 2, 3, 4, 5]
squared = list(map(lambda x: x**2, numbers))  # [1, 4, 9, 16, 25]
```
## filter() - 条件に合う要素だけを抽出
```python 
numbers = [1, 2, 3, 4, 5, 6]
even_numbers = list(filter(lambda x: x % 2 == 0, numbers))  # [2, 4, 6]
```
## リスト内包表記 - コンパクトなリスト生成
```python 
# map+filterの代わりに一行で書ける
squared_evens = [x**2 for x in range(10) if x % 2 == 0]  # [0, 4, 16, 36, 64]
```

## collections.Counter - 要素の出現回数をカウント

```python 
from collections import Counter

text = "mississippi"
letter_counts = Counter(text)  # Counter({'i': 4, 's': 4, 'p': 2, 'm': 1})
most_common = letter_counts.most_common(2)  # [('i', 4), ('s', 4)]
```

## collections.defaultdict - デフォルト値を持つ辞書

```python 
from collections import defaultdict

# リストをデフォルト値とする辞書
groups = defaultdict(list)
for name, group in [("Alice", "A"), ("Bob", "B"), ("Charlie", "A")]:
    groups[group].append(name)
# defaultdict(<class 'list'>, {'A': ['Alice', 'Charlie'], 'B': ['Bob']})
```

## itertools モジュール - イテレーション用ツール
```python 
import itertools

# 組み合わせ
combinations = list(itertools.combinations([1, 2, 3], 2))  # [(1, 2), (1, 3), (2, 3)]

# 直積
product = list(itertools.product([1, 2], ['a', 'b']))  # [(1, 'a'), (1, 'b'), (2, 'a'), (2, 'b')]

# グループ化
data = [('A', 1), ('A', 2), ('B', 1), ('B', 2)]
for key, group in itertools.groupby(data, lambda x: x[0]):
    print(key, list(group))
    # A [('A', 1), ('A', 2)]
    # B [('B', 1), ('B', 2)]
```

## any() と all() - 条件チェック

```python 
numbers = [1, 2, 3, 4, 5]
any_even = any(x % 2 == 0 for x in numbers)  # True
all_positive = all(x > 0 for x in numbers)  # True
```

## sorted() の高度な使い方
```python 
# 複数キーでのソート
students = [
    {"name": "Alice", "grade": "A", "age": 22},
    {"name": "Bob", "grade": "B", "age": 20},
    {"name": "Charlie", "grade": "A", "age": 21}
]

# まずgradeで、次にageでソート
sorted_students = sorted(students, key=lambda x: (x["grade"], x["age"]))
```

## functools.partial() - 関数の部分適用
```python 
from functools import partial

def power(base, exponent):
    return base ** exponent

# 2乗する関数を作成
square = partial(power, exponent=2)
print(square(5))  # 25
```
VSCodeのショートカット一覧

# はじめに

Visual Studio Code（VSCode）は、豊富なショートカットを活用することで、効率的にコーディングを進めることができるエディタです。本記事では、初心者から上級者まで知っておきたいVSCodeの便利なショートカットを、WindowsとMacの両方で紹介します。

---

# 基本操作

| **アクション**              | **Windows**          | **Mac**              |
|----------------------------|----------------------|----------------------|
| コマンドパレットを開く      | `Ctrl + Shift + P`   | `Cmd + Shift + P`    |
| 新しいウィンドウを開く      | `Ctrl + Shift + N`   | `Cmd + Shift + N`    |
| ウィンドウを閉じる          | `Ctrl + W`           | `Cmd + W`            |
| 設定を開く                  | `Ctrl + ,`           | `Cmd + ,`            |
| サイドバーの表示/非表示     | `Ctrl + B`           | `Cmd + B`            |
| ターミナルの表示/非表示     | `` Ctrl + ` ``       | `` Cmd + ` ``        |

---

# ファイル操作

| **アクション**              | **Windows**          | **Mac**              |
|----------------------------|----------------------|----------------------|
| ファイルを開く              | `Ctrl + O`           | `Cmd + O`            |
| 新しいファイルを作成        | `Ctrl + N`           | `Cmd + N`            |
| 保存                        | `Ctrl + S`           | `Cmd + S`            |
| 名前を付けて保存            | `Ctrl + Shift + S`   | `Shift + Cmd + S`    |
| ファイルを閉じる            | `Ctrl + F4`          | `Cmd + W`            |
| 最近閉じたファイルを再度開く| `Ctrl + Shift + T`   | `Shift + Cmd + T`    |

---

# コード編集

### 選択・移動関連

| **アクション**              | **Windows**          | **Mac**              |
|----------------------------|----------------------|----------------------|
| 行全体を選択                | `Ctrl + L`           | `Cmd + L`            |
| 次の一致箇所を選択          | `Ctrl + D`           | `Cmd + D`            |
| 全ての一致箇所を選択        | `Ctrl + F2`          | `Cmd + F2`           |
| 行の先頭/末尾に移動         | `Home / End`         | `Cmd + ← / →`       |

### 編集関連

| **アクション**              | **Windows**          | **Mac**              |
|----------------------------|----------------------|----------------------|
| 行のコピー                  | `Shift + Alt + ↓ / ↑`| `Opt + Shift + ↓ / ↑`|
| 行の削除                    | `Ctrl + Shift + K`   | `Cmd + Shift + K`    |
| コメントアウト（行単位）     | `Ctrl + /`           | `Cmd + /`            |
| コメントアウト（ブロック）   | `Shift + Alt + A`    | `Shift + Opt + A`    |

---

# ナビゲーション

### 検索・移動関連

| **アクション**              | **Windows**          | **Mac**              |
|----------------------------|----------------------|----------------------|
| ファイル内検索              | `Ctrl + F`           | `Cmd + F`            |
| 全ファイル検索              | `Ctrl + Shift + F`   | `Cmd + Shift + F`    |
| シンボルへ移動              | `Ctrl + Shift + O`   | `Cmd + Shift + O`    |

# まとめ
VSCodeのショートカットを紹介しました。︎︎︎︎︎︎︎︎︎最後まで読んでくださり、ありがとうございました。もし改善点や質問があれば、ぜひコメントしてください！
RaspberryPi Pico と trykernelで dualcoreマイコン開発　その0


## 思い立ったきっかけ

ちょっと仕事もひと段落してきて、家で何か電子工作したいなと思っていた今日この頃。どうせなからさわったことがないマルチコアのマイコンでいろいろやってみたいな～と思ったのがきっかけです。

## 手軽なマルチコアマイコンは何があるか？

組み込み開発の世界では、特にESP32とラズピコ（Raspberry Pi Pico）が有名なマルチコアマイコンとして知られています。価格と機能、情報を比較検討した結果、ラズベリーパイPicoが条件に最も合致していることがわかりました。

■ESP-wroom-32(S3)の特徴
Socのコアは、XtensaLX7(Tensillica)。(現在ケイデンス・デザインシステムに統合。）
デュアルコアだが、命令用のメモリとデータ用のメモリのメモリ空間が分離しており、各々のコアからアクセスできる領域が決まっている。

■ラズベリーパイPicoの特徴
Socのコアは、ARM Cortex-M0+。
この2つのコアは、同じROM,RAM領域にアクセスできる「ホモジニアス（同質）」構成。

## Interface誌 2023年7月2024年11月掲載のRTOS　trykernel
仕事でもFreeRTOSやITRONを使っており、今回もRTOSありきで作っていきたいと思っていました。ラズベリーパイPicoでもFreeRTOSを使用したサンプルはたくさんありますので、FreeRTOSかな～と思ってたそんな中、不定期購入しているinterface誌で面白い記事を見つけました。

特集「ゼロから作るマルチコアOS」で紹介されていたμT-Kernelベースで作られた豊山 祐一先生作のOSである「try-kernel」です。

TRON系OSのT-Kernelは、OSの仕様書が公開されているため、フルスクラッチでの設計が可能です。try-kernelは、μT-Kernel2.0に準拠しつつ、コード自体はフルスクラッチで作成されており、RTOSの細部まで理解できるのが魅力です。

## ライセンスについて

try-kernelの大きな利点の一つは、そのライセンス形態です。MITライセンスの下でオープンソースとして公開されているため、自由に再配布や公開を行うことができます。
一方、オリジナルのμT-Kernelを利用するには、T-Licenseへの契約が必要です。FreeRTOSもMITライセンスですが、try-kernelを選択することで、TRON系OSの学習とオープンな利用の両立が可能になると考えています。

## 標準規格への準拠

μT-Kernel2.0は「小規模な組込みシステム向けリアルタイムOSのIEEE標準規格」（IEEE 2050-2018）として国際標準規格になっているようです。try-kernelもこれに準拠しているため、標準的な設計思想に基づいたOSを学ぶことができます。この開発過程をGitHubなどで公開する際には、Interface誌2024年11月号の特集「ゼロから作るマルチコアOS」で紹介されたtry-kernelをベースに設計していることを明記する予定です。
Rの入門書を作成してみた

Rを昔から利用していた方には、RjpWikiやR-tipsのお世話になった方も多いかと思います。残念ながらどちらも閉鎖されてしまったようです。

[R-tips](https://www.amazon.co.jp/R-Tips-%E7%AC%AC3%E7%89%88-%E3%83%87%E3%83%BC%E3%82%BF%E8%A7%A3%E6%9E%90%E7%92%B0%E5%A2%83R%E3%81%AE%E5%9F%BA%E6%9C%AC%E6%8A%80%E3%83%BB%E3%82%B0%E3%83%A9%E3%83%95%E3%82%A3%E3%83%83%E3%82%AF%E3%82%B9%E6%B4%BB%E7%94%A8%E9%9B%86-ebook/dp/B0719QS6KG/ref=sr_1_1?crid=3H02VPTO0IPX9&dib=eyJ2IjoiMSJ9.BSBf57aWvWXai4y1CysuApGZxXnBNBuPvDA5Tg9GAcFnrOvA-HBNuqmgcMKQktPlNW2P7LVyWrQTO3qI89i3Vsbo5rDhj-TRLgeCR0x9eavSmdEEqFnMQBtiEyJFHmv0WW7CuzUgMIuuTSU9lJ_jfMFkyadVM0EJWeLDRfTKx8CcmHALnuJ8kfu78JB1qO8Iy8EOAlWd8Fo4Rz1Gxv45Q3FTPrIAZP2YGGdLTOCRhNzUCQWfsnoe8K7gCbB3V5LbzYVdIlJey770ubiy4kkikpUWPBUbyOfp0HDDdJNk0-vsxmUWOMRkr3J-nAt9jNdVchbVS214B4lzN_ZsgX8JdXi8GrL_YJnID-_O9F2r5-3MiDQ7W3CtNeMWe0TWjw9KuWdX4WNakSFHYeQYbrjzENGK6Ph9SZdQb3zT08mgtDPbg0AtvqbEh0bbByFqP1Dc.-Jkbo7kKLUPaKI2PSgWDzEnEaHSOLy3d93qPeZL46fo&dib_tag=se&keywords=the+r+tips&qid=1742115952&sprefix=The+R+Tips%2Caps%2C165&sr=8-1)を含め、現在ではたくさんの教科書が発売されており、学ぶ意思があれば誰でもRを学ぶことができます。しかし、海外にはWeb上にRの無料の入門書がたくさんあるのに、R-tipsがなくなってから、日本ではRを無料で学ぶことは比較的難しくなってしまいました。

そこで、Rにも統計にもそれほど詳しいわけではないのですが、無料で読めるRの入門書を作成してみました。

https://sb8001at-oss.github.io/Rnyuumon.io/

コードや画像は以下のgithubに保管しています。

https://github.com/sb8001at-oss/Rnyuumon

作成には[Quarto](https://quarto.org/)を用いています。また、githubに保存している画像ファイルには画像作成に利用した.aiファイル（Illustratorのファイル）が含まれています。

## 章立て

章は35章からなっていて、1～14章がRの基礎的なプログラミングに関する内容、15～19章がデータの取り扱いに関する内容+α、20～23章がグラフ作成の基礎、24～30章が統計解析の基礎、31～35章がよりアドバンスドな内容（purrrやShinyなど）となっています。

## 経緯

元々は自分が勤めている企業内でRの教育資料が欲しいと思って作成していました。

始めはプレゼンテーションで教育資料を作っていて、その後動画にしていたのですが、プログラミングの学習をプレゼンテーションで行うのはいまいちしっくりこない（自分が教科書で学んだからかもしれません）と感じ、テキストが欲しいなと思っていました。

以前はテキストとしてR-tipsを薦めていればよかったのですが、R-tipsが公開されなくなってしまったので、代替が欲しい、でも誰も作ってくれない、仕方ないから自分で作ってしまおう、という形でテキストを書き始めました。

ちょうどよいことに、Rでは教科書が簡単に書けます（[Quarto](https://quarto.org/)）。自分の勉強も兼ねてテキストとして仕上げてみることにしました。

2023年頃から書き始めて、概ね1年半ぐらいで形になりました。そこで社内で公開してみたのですが、誰も読んでくれないし、興味も持たれない。自分のための教科書として保管することもできましたが、せっかくなので公開してみることにします。勤めている企業のロゴを入れようかとも思ったのですが、コレを書くための教科書はすべて自費で購入しているし、著作権的に面倒くさいことも多そうなのでやめました。

## 注意

著者はRも統計もほぼ独学で、それほど詳しくありません。特に統計は下手の横好きで、細かい部分がよくわかっていません。テキストをレビューしてくれる人もいないので、内容には間違いを含んでいますし、誤字・脱字もあります。

どうしても間違いが気になる、自分の方がより良いものを作れる、という方がいらっしゃいましたら、上記の[githubリンク](https://github.com/sb8001at-oss/Rnyuumon)からコードをダウンロードし、修正してご自分で公開してもらえると嬉しいです。


## 今後の追加要素

当初思っていたよりもずいぶん分量の多いテキストになってしまいました。あまり追加要素を加える元気がないのですが、例えば欠測値補完やWebスクレイピングなどについては記載していませんし、カテゴリカルデータの統計解析やコーディング規約、クラスなどについても表面をさらっただけ、というところですので、やる気と元気が出たら追加していくかもしれません。

また、文中でShinyアプリのサンプルを引用し、アプリはgithubで公開しているのですが（sb8001atというアカウント）、スマホが壊れてこのアカウントの2重承認を乗り越えられなくなり、サンプルアプリに手を入れられなくなっています。サンプルアプリを修正する場合にはリンク先が変更になる予定です。

## 参考文献

参考文献は最後のページに記載しています。各章に記載している内容は参考にした教科書のほんの一部ばかりです。Rの学習に興味を持たれた方は是非参考文献に記した教科書を手に取ってもらえるとうれしいです。
コレクションの理解

# はじめに
elixirのコレクションを理解する

# 解説
コレクションとは
> ITの分野では、複数の要素を格納できる複合的なデータ構造をこのように呼ぶことが多い。

# リスト
https://e-words.jp/w/%E3%83%AA%E3%82%B9%E3%83%88.html

> リストは値の単純なコレクションで、複数の型を含むことができます。また、一意ではない値を含むことができます:

https://elixirschool.com/ja/lessons/basics/collections#%E3%83%AA%E3%82%B9%E3%83%88-0

```elixir
list = [3.14, "test", :pie]

> [3.14, "test", :pie]
```

# タプル
https://atmarkit.itmedia.co.jp/ait/articles/1703/14/news033.html

> タプルはリストに似ていますが、各要素はメモリ上に隣接して格納されます。 このため、タプルの長さを得るのは高速ですが、修正を行うのは高コストとなります。というのも、新しいタプルは全ての要素がメモリにコピーされるからです。タプルは波括弧を用いて定義されます:

https://elixirschool.com/ja/lessons/basics/collections#%E3%82%BF%E3%83%97%E3%83%AB-4

```elixir
tuple = {3.14, "test", :pie}

> {3.14, "test", :pie}
```

# キーワードリスト

> キーワードリストとマップはElixirの連想コレクションです。Elixirでは、キーワードリストは最初の要素がアトムのタプルからなる特別なリストで、リストと同様の性能になります:

sample_list = [test: hoge]

sample_list[:test] 

https://elixirschool.com/ja/lessons/basics/collections#%E3%82%AD%E3%83%BC%E3%83%AF%E3%83%BC%E3%83%89%E3%83%AA%E3%82%B9%E3%83%88-5

```elixir
key_list = [pie: 3.14, all: 42]

> [pie: 3.14, all: 42]

# another version

key_list_another = [{:pie, 3.14}, {:all, 42}]

> [pie: 3.14, all: 42]

```

別の書き方もできるが出力させると上記の書き方になるためあまり有用性はなさそう。
けど一応覚えておかないとコードを読むときに不便しそうではある。

# マップ

> Elixirではマップは”花形の”キーバリューストアです。 キーワードリストとは違ってどんな型のキーも使え、順序付けされません。 マップは %{} 構文で定義することができます:

https://elixirschool.com/ja/lessons/basics/collections#%E3%83%9E%E3%83%83%E3%83%97-6

```elixir
map = %{:name => "hoge", "12" => :id}

> %{:name => "hoge", "12" => :id}
```

# ちなみに
pythonやJavaだとこういう書き方でリストを表現する
紛らわしいのでelixirを書いているときは気を付けて下さい

python
```python
python_list = ["test", "hoge", "hey"]
python_list[0]
> "test"
```


Java

```java
int[] result = new int[3];
result[0] = 1
result[1] = 2
result[2] = 3

result[1]

> 2
```



# おわりに
なまじ色々なコードを触った経験があると基礎的な内容が疎かになったり年月とともに記憶が混濁してしまうのかもしれません。
今回知識を整理してキチンと理解に落とし込めるように記事に書き起こしました。

# 参考サイト
https://e-words.jp/w/%E3%82%B3%E3%83%AC%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3.html

https://elixirschool.com/ja/lessons/basics/collections#%E3%83%9E%E3%83%83%E3%83%97-6

https://docs.python.org/ja/3/tutorial/datastructures.html

https://www.javadrive.jp/start/array/index2.html
【k8s】Podのスケジューリング(Nodeとの関係性)

# 1. はじめに

この記事は筆者の学習用のアウトプットであり、誰かのインプットを想定して記述しない。
Podのスケジューリングについて、学習した内容を整理する。

# 2. Nodeの指定

### 2.1 Node selector

Nodeに付与されているラベルを指定して、Podをスケジューリングする。
例: disktype: ssd

Node selectorの場合、上記ラベルが付与されているNodeがない場合はPodがスケジューリングされない。
Node障害に弱いため、後述のNode affinityがある。


### 2.2 Node affinity

Node selectorとは違い、柔軟にNodeを指定することが可能である。
affinity.nodeAffinityいかに、次の2つを指定することで、柔軟にNodeを指定することができる。

- __requiredDuringSchedulingIgnoredDuringExecution :__
Node selectorと同様に、対応するNodeがない場合はPodがスケジューリングされない。(Nodeの指定方法はより柔軟に指定可能)
- __preferredDuringSchedulingIgnoredDuringExecution :__
対応するNodeがない場合でも、適当なNodeにスケジューリングされる。
こっちを選択した場合は`weight`の指定が必要であり、複数`preferredDuringSchedulingIgnoredDuringExecution`を指定したときに、各条件をもとに重みづけっし、一番weightの合計が高いNodeにスケジューリングされる。

### 2.3 Pod Affinity/Pod Anti-affinity

前述の方法はNodeのラベルに基づいたスケジューリングであったが、Pod Affinity/Pod Anti-affinityはNodeにスケジューリングされているPodのラベルに基づいてスケジューリングする。

ユースケースとしては、Podの冗長化として、既に同じアプリが乗っているNodeには新しく起動するPodをスケジューリングしないようにすることだ。
※ Pod Topology Spread Constraintsでも代替可能

Pod Anti-affinityを使用すると、特定のラベルがついているPodが割り当てられているNodeにはスケジューリングしない設定が可能。
※ topologyKeyにzoneを指定すればデータセンターへのPod配置も冗長化可能。上記はkubernetes.io/hostnameを指定

### 2.4 Pod Topology Spread Constraints

Pod Anti-affinityよりも後発のため、柔軟に設定できる。Pod anti-affinityはpreferredDuringSchedulingIgnoredDuringExecutionを指定するとPod数がNode数を超えてからは制御できず、単一Nodeに偏る可能性もある。
一方でPod Topology Spread ConstraintsはtopologyKeyを使用し、Pod分散を設定でき、Node数をPod数が超えても分散可能である。(maxSkewの値と実際のNode上のPod数との差分からどのNodeにスケジューリングするかを決める)

### 2.5 Taint/Toleration

TaintはNodeに対する設定、TolerationはPodに対する設定である。
Taintを使うと、Node側でスケジューリングするPodを制御できる。
Taintに対応したTolerationを設定したPod以外スケジューリングされないといった設定ができる。
Podスケジューリングができない場合はこのTaintを疑うのもよいかもしれない。
[備忘録]電卓の開発

## はじめに
初めまして。独学で、プログラミングの学習を行っているえむしたと申します。
今回は、PythonとTKinterを使った電卓開発の備忘録を記録していきます。
拙い記事ではありますが、読んでいただけると幸いです。
## 使用ツール
言語：Python
FW：TKinter
バージョン管理： Git, GitHub
開発ツール： VScode
## 要件
・四則演算
・入力した数字をリスト管理し、足し算、掛け算を１つのボタンで合計する

## メインウィンドウの設計
``` python:メインウィンドウ
root = tk.Tk()  # Tkinterのウィンドウを作成
root.title("計算機")  # ウィンドウのタイトルを設定
root.geometry("700x500")  # ウィンドウサイズを設定
```
``` python:ライブラリ
import tkinter as tk #asを利用し、tkで定義できるように指定
```

まずはアプリを起動した際の表示を作成しました。
今回は、ボタン数が通常の電卓より多いのでウィンドウサイズを大きめに設定しました。

### 計算結果エリアの作成
``` python:計算結果エリア
#計算結果エリア
display = tk.Label(root, text="0", font=("Arial", 24),anchor="e", bg="white", relief="sunken") 
display.pack(fill="both", padx=10, pady=10)
```
エリアに、初期値"0"を表示する為に、``` text=0 ```　と指定しています。
また、```sunken```を使い、ウィジェット自体が少しへこむように見せ、より市販の電卓っぽさを出しています

## ボタン配置のフレームを作成
``` python:ボタン配置フレーム
# 計算機のボタン配置用フレームを作成
button_frame = tk.Frame(root)
button_frame.pack()
```
```tk.Frame(root)```を利用し、メインウィンドウに対して、複数のウィジェットをグループ化するようにしています

## まとめ
今回は、アプリの大枠を作成しました。
全てを１つの記事にまとめると長くなりすぎるので、細かく書いていこうと思います。
次回は、四則演算のボタン配置を書いていきます。
ありがとうございました。
Instana | ユーザー・グループの解説 #3 プラットフォームについて

# はじめに

Instanaは個々のユーザーに対して直接権限を割り当てるのではなく、ユーザーを役割が定義されたグループに所属させることで、アクセス制御を管理します。

ロールベースアクセス制御（RBAC）ですね。
以前InstanaにおけるRBACの考え方をざっくりと解説しているので良ければ参照ください。

https://community.ibm.com/community/user/aiops/blogs/shu-adachi/2024/06/28/instana-rbac-1?CommunityKey=1507c7fa-70f3-451c-a5f6-eed79a229022

この記事では、Instanaのプラットフォーム(↓の画面です)の設定について、Airitech株式会社の小畑さん(@kei410)の協力のもと解説します。ご協力ありがとうございました！
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/118463/41abdc4c-cecc-4927-b982-6f6b2cd2b658.png)

ドキュメントはこちら

https://www.ibm.com/docs/ja/instana-observability/current?topic=instana-managing-user-access#platforms

# できること

以下については、Instanaのプラットフォームメニューへのアクセス可否を設定可能です。

- Cloud Foundry
- IBM Power HMC
- IBM Z HMC
- Nutanix
- OpenStack
- vSphere
- SAP
※記事執筆時点

:::note info
対象のデータがInstanaにない場合、そのプラットフォームはメニューに表示されません。
例えば、vSphere, SAP, Kubernetes を監視している環境の場合は以下のようになります。
![スクリーンショット 2025-04-03 21.17.06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/118463/c0eeceed-2df2-4419-afde-a4690a889097.png)
:::

Kubernetesについては、もう少し細かく設定可能です。

- プラットフォーム(Kubernetes)の画面へのアクセス可否
- アクセスできる範囲の絞り込み

そのため、本記事では基本的にKubernetesに対する設定を記載いたします。

## アクセスレベル

Kubernetesに対しては3種類のアクセスレベルが選択できます。
※権限の説明は後述します。

|アクセスレベル|説明|
|:-|:-|
|すべてにアクセス|Instanaに連携されているすべてのデータへのアクセスを許可|
|制限付きアクセス|Instanaに連携されている一部のデータへのアクセスを許可|
|アクセス権なし|すべてのデータへのアクセスを拒否|

Kubernetes以外に対しては2種類のアクセスレベルが選択できます。

|アクセスレベル|説明|
|:-|:-|
|すべてにアクセス|Instanaに連携されているすべてのデータへのアクセスを許可|
|アクセス権なし|すべてのデータへのアクセスを拒否|

### すべてにアクセス

![スクリーンショット 2025-04-03 21.25.08.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/118463/7264183d-180c-4b25-809c-2e1a87709345.png)

このアクセスレベルは、選択したプラットフォームに関するすべてのデータが参照可能になります。
必要な権限の チェックをON または ラジオボタンを選択 してあげましょう。

### 制限付きアクセス

![スクリーンショット 2025-04-03 21.27.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/118463/4eee3f66-3831-44b2-9d07-7a9d70c8dfa9.png)

アクセスを許可したい 名前空間 と クラスター を [XXXの追加] から選択します。
グループに所属する人に参照させたい範囲をこちらで指定しましょう。

### アクセス権なし

![スクリーンショット 2025-04-03 21.32.31.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/118463/61bf4658-abb1-473e-baea-e1f3946d8a0c.png)

Kubernetesのアクセス権なしを選択 および チェックをOFF にすると対象プラットフォームの画面へのアクセスができなくなります。
設定後は、INSTANAのメニューにある "プラットフォーム" にも該当のプラットフォームが表示されなくなります。
また、全ての権限がない場合は、以下の画像のように プラットフォームメニュー 自体が表示されなくなります。
![スクリーンショット 2025-04-03 21.33.42.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/118463/05471e13-24bb-4862-a1a7-7ccc1f69fa11.png)

# おわりに

Instanaのプラットフォームに関するRBACの解説は以上となります。
（もし間違ってるよ！というところがあったら優しくご指摘ください）
ネイピア数の定義とテイラー展開

# はじめに
ネイピア数は、反比例の積分を行うときにでてくる神秘的な数である。ネイピア数は、ある関数の極限として定義上表すことができるため、有限区間で区切りれば、計算機を用いて近似値を算出することができる。一方で、テイラー展開を用いて無限和で表すこともできる。そこで、今回は定義もしくはテイラー展開から導かれたネイピア数を表す極限式は本質的には等価であることを示す。次に、計算機を用いて定義もしくはテイラー展開を用いてネイピア数の近似値を算出する。


![e_approximation.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1686019/82f57de6-4e26-41db-a6ca-3e6c5e5d210b.png)



# ネイピア数の定義
ネイピア数$e$は、以下のように表すことができる。
```math
e=\lim_{n\to \infty} (1+\frac{1}{n})^n
```

したがって、二項定理で展開することを考えると以下のようになる。

```math
(1+\frac{1}{n})^n=\sum_{k=0}^{n}{}_n C_k(\frac{1}{n})^k=\sum_{k=0}^{n} \frac{n(n-1)\cdot \cdot \cdot (n-k+1)}{k(k-1)\cdot \cdot \cdot 1}\frac{1}{n^k}=\sum_{k=0}^{n} \frac{n(n-1)\cdot \cdot \cdot (n-k+1)}{n^k}\frac{1}{k(k-1)\cdot \cdot \cdot 1}=\sum_{k=0}^{n} 1(1-\frac{1}{n})(1-\frac{2}{n})\cdot \cdot \cdot (1-\frac{k}{n})\frac{1}{k!}=\sum_{k=0}^{n} \frac{1}{k!}
```

ただし、最後の式変形について、厳密には下記に示すような方法を用いるべきだと思うが、今回は難しいので省略する。

https://nikoja.hatenablog.com/entry/2021/09/25/013730

# テイラー展開を用いたネイピア数の表現

一方で、テイラー展開を用いると、ネイピア数は以下のように表現することが出来る。

```math
e=1+\frac{1}{1!}+\frac{1}{2!}\cdot \cdot \cdot=\sum_{k=0}^{\infty} \frac{1}{k!}
```


#  プログラム

```python e_approximation.py
import numpy as np
import matplotlib.pyplot as plt
import japanize_matplotlib
import math

#n_max 有限の区間
n_max=100
n_ary=np.arange(0, n_max, 1)

y1_ary=[]
y2_ary=[]

#階乗計算
def factorial(num):
  num2=1
  for i in range(1,num+1):
    num2=num2*i
  return num2

for i in range(len(n_ary)):
    y1=(1+1/n_ary[i])**n_ary[i]
    y1_ary.append(y1)
    if i==0:
        y2=1
    else:
        y2=y2+(1/factorial(n_ary[i]))
    y2_ary.append(y2)
    
plt.plot(n_ary, y1_ary, label='(1+1/n)^n', color='blue')
plt.plot(n_ary, y2_ary, label='Taylor', color='green')
plt.axhline(y=math.e, color='red', linestyle='--', label='e')
plt.title('eの近似')
plt.xlabel('n')
plt.ylabel('y')
plt.legend()
plt.grid()
plt.ylim(0, 3)
plt.savefig('e_approximation.png')
plt.show()
```

これを実行すると以下のようなグラフが出力される。

![e_approximation.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1686019/82f57de6-4e26-41db-a6ca-3e6c5e5d210b.png)

級数の収束としては、定義式よりも、テイラー展開による式のほうが収束が早いようである。

# まとめ
今回は、ネイピア数$e$の近似値を計算機を用いて推定してみた。具体的には、定義式による級数とテイラー展開による級数を比較してどちらのほうが早く収束するのか調査した。その結果、定義式よりもテイラー展開によるもののほうが早く収束した。



# 参考文献

ネイピア数と反比例の積分について

http://g2physics.web.fc2.com/math/analysis/logarithm_analysis.html
MS Learn の新しい調べ方

# 背景

GitHub Copilot を使えるようになって、

え！？　MS-Learn ってもう読む必要ないじゃん （言い過ぎ）

と思ったので、是非、試してみてくださいと思った共有

# 前提知識

- MS-Learn は、GitHub で提供されている
   - Contribute して気付いたことです :book: 
- GitHub Copilot の Free 版の制限は以下

> Copilot Free には次の制限事項があります。
> コード補完は **1 か月あたり 2,000 回**に制限されています。
Copilot Chat の**チャット メッセージは 1 か月あたり 50 回**に制限されています。 この制限には、Copilot in the CLI、Windows Terminal、VS Code と Visual Studio での標準および複数ファイル編集チャットの両方の使用が含まれます。 これらの制限に達した場合は、Copilot Pro にアップグレードして、引き続き Copilot を使用できます。

https://docs.github.com/ja/copilot/managing-copilot/managing-copilot-as-an-individual-subscriber/managing-copilot-free/about-github-copilot-free

# 新しい読み方

1. [GitHub へ飛ぶ](#github-へ飛ぶ)
1. [Copilot Chat で質問する](#copilot-chat-に質問する)

ただ、それだけ

## GitHub へ飛ぶ

普通に MS-Learn 開くと、GitHub へのリンクがない（と思う）ので、どうやっていくの？ってなります

例えば以下のページ

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/120072/06617ecb-ad10-4333-a4c3-3bae4f0b0667.png)

で、どうするかっていうと、

1. :earth_asia: ？をクリックして、原文に飛ぶ
1. :pen_ballpoint: で、GitHub へのリンクが出現するので、それを押す

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/120072/c0aa8b04-c526-4d75-a7fd-8d9d82dcfe52.png)

## Copilot Chat に質問する

あとは、チャット起動して、質問すれば、
対象のリポジトリ＝MS-Learn で調査したかった内容について、質問が出来てめっちゃ便利

MS-Learn の検索機能や、Felo とか genSpark 使うよりこっちの方が信頼感がある。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/120072/18507d5c-f277-49b1-8c18-b59ea4fd42d1.png)

# あとがき

Free 版でこれやると、あっという間に使い果たしちゃいそうなので、そこは注意

あと、外部blog の解説とかも役立つことはあるので、felo とかが無意味になるわけではないね
Solid.jsとMaterial Web Componentsを使いたいけど、型エラーが発生する

Solid.js(TypeScript環境)でMaterial Web-Componentsを使おうとした時、型エラーが発生した。
少し詰まったので自分用メモ。

# 原因
Solid.jsでWebコンポーネントを使おうとした時に、Solid.jsがmaterial web componentsの型定義を見てくれず、なんじゃこのタグと言われる。

.ex)
```tsx:App.tsx
import '@material/web/button/outlined-button.js';

function App {
    return (
        <md-outlined-button type="reset">Reset</md-outlined-button>
    );
}

export default App
```

# 解決法
必要に応じて、tsconfigに以下を追加
```json:tsconfig.json
{
    "include": ["src", "src/global.d.ts"]
}
```

続けて`src/global.d.ts`に以下を追加

```ts:global.d.ts
import "@material/web/all"

type WithAnyChildrenAndClasses = {children:any} | {} | {class?:string, classList?:Record<string,boolean>};

type SolidInterface = {
  [P in keyof HTMLElementTagNameMap]: HTMLElementTagNameMap[P] | WithAnyChildrenAndClasses;
};

declare module "solid-js" {
  namespace JSX {
    interface IntrinsicElements extends SolidInterface { }
  }
}
```

# 参考

https://stackoverflow.com/questions/78626992/solidjs-with-material-3-web-components-type-definitions
[Linux][system][directry] 初期化システム_systemdのデーモンプロセス

# systemdのデーモンプロセス
| デーモン名| 由来・英語表記 | 説明  |
|--|--|--|
| `systemd` | system daemon | システムとサービスを管理する主要なデーモン|
| `systemd-journald` | journal daemon  | システムのログを収集・管理するデーモン |
| `systemd-logind`  | login daemon| ユーザーのログインや起動停止、電源ボタン操作などを管理するデーモン |
| `systemd-udevd` | device daemon | デバイスの検出と管理を行うデーモン|

# Ping-t
- [3702_systemd-journald](https://mondai.ping-t.com/question_subjects/31/question_sessions/31718661/progressing_questions/486071294)
【Node.js】Please upgrade Node.js to version >=20.0.0 || >=22.0.0

# はじめに
Firebaseのインストールを試みたところ表題のエラーに遭遇しました。
今後も、versionの変更時にスムーズに対応できるよう備忘録として残します。

# 問題
Node.jsのバージョンをv.20にアップグレードしたい。

# 環境
Ubuntu 22.04.5 LTS

# 解決方法
以下の手順で解決しました。

### 1.Node.jsの現在のバージョンを確認
```shell
$ node -v
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3993509/c50e8195-5fa6-4f99-8f80-07ffd1298a51.png)

### 2.nvmコマンドのインストール

* nvmコマンドがインストールされているか確認。コマンドがあればスキップ

```shell
$　nvm --version
$ command -v nvm
```

* 結果が空の場合、使用しているシェルを確認
設定ファイルを開き、コードを追加する

```shell
$ echo $SHELL
~/.bashrc
# 設定ファイルを開く
$ nano ~/.bashrc
# 設定ファイルの下のほうに以下の行があるか確認、ない場合は追加
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion" # This loads nvm bash_completion
# 設定ファイル再読み込み
$ source ~/.bashrc
```

### 3.NodeSourceリポジトリを追加
```shell
$ curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
```

`setup_20.x`はアップグレードしたいバージョンを指定（v22の場合、`setup_22.x`）

### 4.Node.jsをアップグレード
```shell
$ sudo apt-get install -y nodejs
```

### 5.Node.jsのバージョンを確認
```shell
$ node -v
```

### 6.変わっていない場合、nvmコマンドでバージョンを変更
```shell
$ nvm install 20
$ nvm use 20
# 再度バージョンを確認
$ node -v
```

# おわりに
今回のエラーは1か月前にfirebaseの設定を行い、再度を試みたところ遭遇したエラーになります。
1か月でバージョンアップを求められ、技術の移り変わりの速さを実感しました。
【備忘録】VSCodeでmarpのPDF出力時にmermaidの図を正しく表示させる

タイトル書くだけでも頭ひねってどうしようとか考えてしまうぐらいアウトプットしてないなと…
たくさん他に有意義な記事を書かれているエンジニアの皆様に申し訳ない気持ちになりつつも、個人的になかなか他で設定情報が見つからなかったので、備忘の兼ねて投稿します。

# 結論から

## 1. setting.jsonに以下を追記

`"markdown.marp.enableHtml": true`

### **setting.json**の開き方

VSCode上で`Ctrl` + `Shift` + `p`でコマンドパレットを開き、`setting.json`と打ち込み

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/169143/d876400d-12e4-414d-949d-6142bc7c09f0.png)

この中のどれでもいいのですが、`ワークスペース設定`か`ユーザー設定`のどちらかに追記するのがいいかなと思います。

## 2. Markdownファイルに以下JavaScriptの記載を追加

事前にVSCodeのプレビューでmarpによるmermaidの図自体は表示されていることが前提です。  
こちらの記事等を参考に、mermaidが正しくプレビューされるようにしておきます。  
https://qiita.com/sato_kana/items/2a13f19017576488f017

```javascript
<script type="module">
  import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@latest/dist/mermaid.esm.min.mjs';
  mermaid.initialize({ startOnLoad: true });
</script>
```
記載箇所はどこでもいいのですがが、実際は分かりやすいように最初のスライド箇所にでも記載するといいと思います。

```markdown
---
marp: true
paginate: true
theme: default
---
<script type="module">
  import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@latest/dist/mermaid.esm.min.mjs';
  mermaid.initialize({ startOnLoad: true });
</script>

# ここからスライド作成開始
```
こんな感じで書き出す感じで

### どんな出来栄えのPDFになるの？
社内向けにgit研修を作っている資料でmermaidを利用してGitGraphでブランチの説明を図にしたときの1スライドから

- もともとVSCode上でのレビュー画面
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/169143/a5276d0e-0fb2-4759-8e83-2ec701f28ee2.png)

  
    

- JavaScriptの記載が無いとき
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/169143/06a305a9-a0a8-4200-8720-8b32515ddfe7.png)


- JavaScriptの記載を入れたとき
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/169143/a4cfd11b-e841-41f7-a310-5f1d5a9e8a3d.png)

    色味の差はあるけれど正しくmermaidの図が表示されています。

## 3. まとめ

この方法の何がいいかというと、marp、mermaidによるスライド作成がVSCodeのみで完結します。PDF出力だけではなくpptx出力でもいけました。
というか私がmarp使い始めたばかりなので慣れていないこともあり、状況によってはmarp-cli使わないとダメとかあると急に敷居が高くなるので…

シンプルに**VSCode+marp+mermaid**おすすめです！
DockerでMinecraftサーバーを起動する

# 概要
　dockerを今まで少し弄ってきてアウトプットをしてこなかったのと最初の頃dockerfileで躓きまくっていたので誰かのためになればなという思いで書いていきます。
 　そして今回はdockerへの理解を深める為に既存のイメージ等は使用せず最小構成で作っていきます。

# 環境
* Ubuntu 22.04
* Docker 27.3.1

# マシンスペック
* CPU
    * core i7-6700
* メモリ
    * 16GB
* ディスク
    * SATA SSD 1TB 

# はじめに
　dockerのインストール等は他の記事に分かりやすく書いてあるので、自分が分かりやすいなと感じた記事を紹介しておきます。
 
 https://qiita.com/ryome/items/29b3241d32cf63849f63

# DockerFile作成
```bash
$ touch MinecraftServer.docker
$ nvim MinecraftServer.docker
```
自分はnvimを使っていますがviなり、nanoなりお使いのエディタに置き換えてやってください。
```dockerfile:MinecraftServer.docker
FROM openjdk:21-slim
WORKDIR /MinecraftServer
EXPOSE 25565
VOLUME ["/MinecraftServer"]
CMD ["java","-Xms1G","-Xmx8G","-jar","server.jar","nogui"]
```
* `FROM openjdk:21-slim`
    OpenJDKのバージョン21の軽量バージョンを使用しています
* `WORKDIR /MinecraftServer`
    コンテナのなかにMinecraftServerというフォルダを作成しそのフォルダをワークディレクトリとします
* `EXPOSE 25565`
    25565番ポートをコンテナ内で使用します
* `VOLUME ["/MinecraftServer"]`
    `/MinecraftServer`でボリュームを作成しています。無くても動きますがあった方がいいです
* `CMD ["java","-Xms1G","-Xmx8G","-jar","server.jar","nogui"]`
    マイクラサーバーを起動するコマンドです

# コンテナを作成
```bash
$ docker build -t minecraft-server -f MinecraftTmp.docker .
```
`MinecraftTmp.docker`があるフォルダで実行してください。
* `-t minecraft-server`
    作成するコンテナに`minecraft-server`という名前(タグ)を付けます
* `-f MinecraftTmp.docker`
    使用するDockerFileを指定します

# コンテナの起動
```bash
$ docker run -d --name mc-server \
    -p 25565:25565 \
    -v /home/user/MinecraftServer:/MinecraftServer \
    minecraft-server
```
* `-d`
    バックグラウンドで実行します
* `--name mc-server`
    コンテナに名前を付けます
* `-p 25565:25565`
   PC側の25565番をコンテナ内の25565番に転送します
* `-v /home/user/MinecraftServer:/MinecraftServer`
    PC側の`/home/user/MinecraftServer`をコンテナ内の`/MinecraftServer`にマウント

# コンテナの停止、起動
```bash
$ docker stop mc-server
$ docker start mc-server
```
これだけで停止と起動が完了します。簡単ですね！

# 終わりに
dockerはとても難しいですが使えるようになるとシステム構築の幅が広がりますね。自分もまだまだ勉強中ですが...

# 参考

https://qiita.com/ryosuketter/items/c53352f1143366d8b9a9

https://qiita.com/cokemaniaIIDX/items/4b8dd5fd0a9309e5bde4
🛡️ セキュリティ対策 - ファイアウォールとプロキシサーバ

お久しぶりです。今回はファイアウォールとプロキシサーバの違いについてまとめてみました。
## 1. ファイアウォールとは？

ファイアウォールは、ネットワーク間の通信を監視・制御するセキュリティ機器です。外部から内部ネットワークへの不正アクセスを防ぐことを目的としています。

## ファイアウォールの役割
•	アクセス制御：IPアドレスやポート番号に基づき、通信を許可するか拒否します。
	•	トラフィックのフィルタリング：悪意のある通信や不正アクセスからネットワークを守ります。
	•	ステートフルインスペクション：接続が正常であるかを監視し、疑わしい通信を遮断します。

## ファイアウォールの動作
1.	外部からの接続リクエストを受け取る。
2.	ルールに従って、許可されたポートやIPアドレスからの通信のみを許可。
3.	不正なアクセスや疑わしいトラフィックは、ブロックして内部ネットワークを守ります。

⸻

## 2. プロキシサーバとは？

プロキシサーバは、クライアントと外部サーバとの間に立つ中継サーバで、主にHTTPやHTTPS通信を管理します。ユーザーのリクエストを代理で外部サーバに転送し、レスポンスをユーザーに返します。

## プロキシサーバの役割
•	アクセス制御：特定のWebサイトへのアクセスを制限したり、コンテンツフィルタリングを行います。
	•	キャッシュ：頻繁にアクセスされるデータをキャッシュし、通信速度の向上や帯域の節約を図ります。
	•	匿名化：ユーザーのIPアドレスを隠すことで、オンラインでのプライバシーを保護します。

## プロキシサーバの動作
1.	ユーザーがWebサイトにアクセスしたいリクエストをプロキシサーバに送信。
2.	プロキシサーバがリクエスト内容を検査し、アクセスを許可するか判断。
	•	許可された場合：リクエストを実際のWebサーバに転送。
	•	拒否された場合：エラーメッセージを表示し、アクセスを遮断。
3.	サーバから返されたレスポンスをユーザーに返送。

⸻

## 3. ファイアウォールとプロキシサーバの違い

ファイアウォールとプロキシサーバは、いずれもセキュリティ対策として使用されますが、役割や機能に違いがあります。

## 主な違い
•	ファイアウォール：
	 •	ネットワーク全体のアクセス制御を行い、パケットレベルでフィルタリングします。
	•	IPアドレスやポート番号に基づいて通信を許可または拒否します。
	•	通常、通信内容（データの中身）は確認せず、ヘッダー情報だけをチェックします。
    
•	プロキシサーバ：
	•	特定のアプリケーション層（主にHTTP/HTTPS）の通信内容を検査します。
	•	クライアントからのリクエストを代理で外部サーバに転送し、Webサイトのフィルタリングやキャッシュなど、詳細な制御を行います。

なぜ両方が必要なのか？
	•	ファイアウォールだけでは不十分：
ファイアウォールは主にネットワーク層で動作し、パケットのヘッダ情報（IPアドレスやポート番号）に基づいて通信を制御します。しかし、通信内容やWebサイトのアクセス制限、コンテンツのフィルタリングは行えません。つまり、悪意のある通信がポートやIPアドレスに隠れている場合には、ファイアウォールはそれをブロックできません。

•	プロキシサーバだけでは不十分：
プロキシサーバはWebサイトへのアクセスを制限し、コンテンツフィルタリングやキャッシュを提供しますが、外部からの不正なアクセス（例えば、外部から内部ネットワークへの侵入）を防ぐことはできません。また、悪意のあるアプリケーションや通信がプロキシを介さずに通信を試みた場合、プロキシサーバではその通信をブロックできません。

⸻

## 4. ファイアウォールとプロキシサーバの組み合わせ運用

企業や組織では、ファイアウォールとプロキシサーバを組み合わせて運用することで、より強固なセキュリティ対策が可能となります。

組み合わせる理由
	1.	ネットワーク層とアプリケーション層の防御：
	•	ファイアウォールがネットワーク層で不正なアクセスを防ぎ、プロキシサーバがアプリケーション層で詳細なフィルタリングを行うことで、両方の攻撃面をカバーできます。
	2.	多層防御：
ファイアウォールが外部からの侵入を防ぎ、プロキシサーバがWebサイトへのアクセス管理を行います。これにより、異なるレベルで防御が可能になり、攻撃者が突破しにくくなります。
	3.	監視と管理：
	•	ファイアウォールで基本的なネットワークアクセスを管理し、プロキシサーバでWebアクセスの詳細な監視ができます。これにより、通信の可視化とアクセス制限が強化されます。

⸻

## 5. 実際の運用例

企業では、インターネットへのアクセス管理やセキュリティ対策として、ファイアウォールとプロキシサーバを次のように組み合わせて運用しています。

ファイアウォールの設定例
	•	外部からの不正接続を防ぐために、許可されたポート（例えば、443/HTTPS）だけを通過させ、その他のポートは全て遮断。
	•	不正なIPアドレスからのアクセスや、DDoS攻撃に対する防御を行う。

プロキシサーバの設定例
	•	特定のWebサイト（例：ギャンブル、成人向け）へのアクセスをブロック。
	•	よくアクセスされるコンテンツをキャッシュし、ネットワーク帯域の節約とユーザーのアクセス速度を向上させる。
	•	企業のセキュリティポリシーに基づき、特定のWebコンテンツの閲覧を制限。

⸻

## 6. まとめ
•	ファイアウォールは、ネットワークレベルでのアクセス制御を行い、通信が不正でないかを監視します。主にIPアドレスやポート番号で判断します。
	•	プロキシサーバは、主にHTTP/HTTPS通信において、通信内容やアクセス先のWebサイトに対する制限を行います。
	•	両者を組み合わせることで、多層的な防御が可能となり、ファイアウォールだけでは不十分な部分を補完します。
【Sinatra】Rubyアプリの作成方法

# 記事概要
フレームワークSinatraによる、Rubyのアプリケーションを作成する方法について、まとめる

# 言語やフレームワーク
|| 使用技術 |
| ---- | ---- |
| フロントエンド | HTML |
| バックエンド | Ruby 3.2.0 <br> Sinatra |
| データベース | - |
| インフラ | - |
| API | - |
| その他 | - |

# 前提
- SinatraをPCにインストールしている
- PumaをPCにインストールしている

# サンプルアプリ(GitHub)
https://github.com/likapantrip/sinatra

# 手順
1. Sinatraの読み込み
    [こちら](https://qiita.com/likapantrip/items/655e2c8fc2d4c02eb12e#requireメソッド)を参照
1. リクエスト処理を記載
    ルーティングを設定し、リクエスト処理を記述する
    
    ```ruby
    HTTPメソッド '<URL>' do
      # 処理を記述
    end
    ```

    ```sinatra.rb
    # PCにインストールしたSinatraをファイルに読み込む
    require 'sinatra'
    
    # ルートパスへアクセスしたときのルーティング
    get '/' do
      
    end
    ```
1. レスポンス処理を記載
    ルーティングの`do`~`end`の間にレスポンス処理を記述する
    
    ```sinatra.rb
    # PCにインストールしたSinatraをファイルに読み込む
    require 'sinatra'
    
    # ルートパスへアクセスしたときのルーティング
    get '/' do
      # 変数titleに"ONE PIECE"という文字列を代入する
      title = "ONE PIECE"
      
      # 変数titleに代入された値をブラウザに表示する
      "<h1>今週の表紙は、#{title}です</h1>"
    end
    ```
1. Webアプリケーションを実行させるため、ターミナル.appで下記コマンドを実行
    ```
    # .rbファイルのフォルダへ移動済
    % ruby ファイル名.rb
    ```
1. 下記どちらかが表示されると、サーバーが起動している
    - パターン1
        ```
        Ignoring debug-1.7.1 because its extensions are not built. Try: gem pristine debug --version 1.7.1
        Ignoring rbs-2.8.2 because its extensions are not built. Try: gem pristine rbs --version 2.8.2
        == Sinatra (v4.1.1) has taken the stage on 4567 for development with backup from Puma
        Puma starting in single mode...
        ```
    - パターン2
        ```
        == Sinatra (v2.0.8.1) has taken the stage on 4567 for development with backup from Puma
        ```
    - 上記が表示されず、`gem install rackup`が表示された場合は、再度Rubyを起動する
    - 
        ```
        # 下記コマンドの実行
        % gem install rackup
        
        # ynの選択が必要となるので、"y"と入力
        Overwrite the executable? [yN]
        ```
        
1. ブラウザで[http://localhost:4567](http://localhost:4567)にアクセスすると、サーバーに接続できる
    [![Image from Gyazo](https://i.gyazo.com/c9b41b34a81e78bdbb01a49daeca75cc.png)](https://gyazo.com/c9b41b34a81e78bdbb01a49daeca75cc)
1. ターミナル.appで`control + C`を同時に押すと、サーバーを停止できる

# 備考
- SinatraとPumaのインストール方法は、[こちら](https://qiita.com/likapantrip/items/ac9b3c9262316213d259)を参照