OmniAICreator/Qiita-1.07M huggingface dataset:
MIT App Inventorでchatbotの回答を制御する方法（その1）回答をList形式にする．

## はじめに
MIT App Inventorでチャットボット使用するの便利ですよね~~~！！！生成AIの解答をjsonschemaを使用して制御します．

:::note info
**注意**
ここで作成するシステムはGoogle Documentに記載されているコードのパクリです．
[Gemini API を使用して構造化された出力を生成する](https://ai.google.dev/gemini-api/docs/structured-output?hl=ja&lang=rest)
:::

## 作成するアプリ
>モデル構成でスキーマを指定する
次の例では、次のことを行います。
JSON でレスポンスを返すようにスキーマで構成されたモデルをインスタンス化します。
クッキーのレシピを返すようにモデルに指示します。
[Gemini API を使用して構造化された出力を生成する モデル構成でスキーマを指定する](https://ai.google.dev/gemini-api/docs/structured-output?hl=ja&lang=rest#supply-schema-in-config)

## デザイナー画面
![スクリーンショット 2025-03-08 223549.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3928359/0762f254-7d82-49e1-8783-1dd2b7c0eba4.png)

|機能|内容|
|:-:|:-:|
|Button_ai|クリックしたらgeminiに質問|
|Button_reset|Labelをきれいにする|
|Label1|geminiからの返答|
|Web1|Geminiへのアクセス|

## ブロック画面
### 変数
#### GeminiへのURL
```
https://generativelanguage.googleapis.com/v1beta/models/gemini-1.5-flash-latest:generateContent?key=
```
![blocks (1).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3928359/eb327ec2-02e5-43f9-ac96-3ce96f2570c3.png)

#### APIKey
ご自身キーをいれてください
![blocks.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3928359/cc710c2e-d27f-4b14-812f-282e760bdf94.png)

### when Button_ai .Click
ボタンをクリックしたらgeminiに質問
[Gemini API を使用して構造化された出力を生成する モデル構成でスキーマを指定する](https://ai.google.dev/gemini-api/docs/structured-output?hl=ja&lang=rest#supply-schema-in-config)
![blocks (4).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3928359/7865ede4-059e-49a1-a3c7-6dc9d846f240.png)

### when Web1. GotText
Geminiからの解答
![blocks (3).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3928359/df48a234-1d71-4627-889d-dd59a8d01b68.png)

## 実行結果
![Screenshot_20250308-223444.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3928359/fce57223-090e-4b1c-944d-e37c2ac9dcb0.png)

## おわりに
取得したいテキストを分けたいときにこれは便利そう．
Springの進化の歴史を完全解説！〜 Java開発者なら知っておきたい、Springの誕生から最新トレンドまで 〜

# 🛠️ はじめに  

**「Springっていつからこんなに使いやすくなったの？」**  
**「設定って昔はどうやってたの？」**  
**「Spring Bootが出たとき、何が変わったの？」**  

29歳の筆者は日々Springで開発をしていますが、ふと「なぜSpringは今の形になったのか？」という疑問が湧きました。  
歴史を知ることは、技術の本質を理解する上でとても大切です。  

そこで、**Springの誕生から現在までの進化を徹底解説！**  
この記事を読めば、Springの全体像とトレンドがスッキリ整理できるはずです！  

---

# 📌 1. Springの誕生と初期の発展（2003年〜2008年）  

## 🔰 Springは「EJBの呪縛」からの解放だった  

### 🔸 2003年：Rod JohnsonがSpringの原型を発表  
当時のJavaでは、**「EJB（Enterprise JavaBeans）」** という技術が標準でした。  
しかし、EJBには以下のような**致命的な問題**がありました。  

- **設定が複雑すぎる** → XML地獄 & 煩雑な設定  
- **パフォーマンスが悪い** → オーバーヘッドが大きい  
- **開発効率が低い** → 環境構築だけで一苦労  

これに対し、「こんなの使ってられない！」と考えたのがRod Johnson。  
彼は**DI（依存性注入）**や**AOP（アスペクト指向プログラミング）**を活用し、**軽量かつシンプルなフレームワーク**を構想しました。  

👉 そのアイデアをまとめたのが、書籍 **『Expert One-on-One J2EE Design and Development』**（2003年出版）。  
👉 これが**Spring Frameworkの原型**となります！  

---

### 🔸 2004年：Spring Framework 1.0 リリース  
- **EJBを使わずにDI & AOPを導入**  
- **軽量でシンプルなアーキテクチャを実現**  
- **Javaアプリ開発が一気に楽に！**  

この時点ではまだXMLでの設定が必須でしたが、EJBよりは圧倒的に簡単でした。  

---

### 🔸 2006年：Spring 2.0 登場！  

Spring 2.0では、**設定の柔軟性が大幅アップ！**  

✅ **AOPのサポート強化**（AspectJ統合）  
✅ **XML設定の改善**（スキーマベース設定の導入）  
✅ **Spring SecurityやSpring WebFlowなど、周辺プロジェクトが始動**  

💡 **当時はまだXMLで設定するのが主流だったが、EJBと比べると圧倒的にシンプル！**  

---

# 📌 2. アノテーション時代の到来（2007年〜2013年）  

## 🔰 Java 5の登場で「アノテーション」が使えるように！  

**2007年：Spring 2.5 → `@Autowired` の登場！**  
これにより、**XMLを書かずにDIを設定できるようになりました！**  

```java
@Component
public class MyService {
    @Autowired
    private MyRepository repository;
}
```

この記述だけで、MyRepository がDIされる時代となります。
---

# 📌 3. Spring Bootの衝撃（2014年〜2017年）  

## 🚀 Spring Boot 1.0（2014年） → 設定の革命！  

**それまでのSpringには、以下の問題がありました。**  

- 設定が多すぎる  
- 環境構築に時間がかかる  
- プロジェクトごとに設定がバラバラ  

👇 **ここで登場したのが「Spring Boot」！**  

✅ **Auto Configuration（自動設定）** → 依存関係を自動解決！  
✅ **組み込みWebサーバー（Tomcat, Jetty, Undertow）** → すぐ動く！  
✅ **`application.properties` で簡単設定！**  

💡 **「Springのセットアップがめんどくさい問題」がついに解決！**  

---

# 📌 4. クラウド・コンテナ時代（2018年〜現在）  

## 🔵 Spring 5.x（2017年〜） → リアクティブプログラミング時代へ  

✅ **Spring WebFlux導入**（非同期＆リアクティブ対応）  
✅ **Java 9以降のモジュールシステム対応**  
✅ **Kotlinサポート強化**  

💡 **クラウド・コンテナ環境に最適化！**  

---

## 🔵 Spring Boot 2.x（2018年〜） → Kubernetes & Docker時代  

✅ **Kubernetes、Dockerとの親和性向上**  
✅ **Spring Security、Spring Dataの強化**  
✅ **Actuator改良（モニタリング機能強化）**  

💡 **マイクロサービスとの相性バツグン！**  

---

## 🟣 Spring Boot 3.x（2022年〜） → Java 17＆GraalVM最適化  

✅ **Jakarta EE 10移行（Java EEが完全廃止）**  
✅ **GraalVMネイティブイメージ対応（超高速起動！）**  
✅ **Java 17以上が必須**  

💡 **クラウドネイティブ時代の最適解へ！**  

---

# 📌 まとめ：Springの進化を一気に振り返る！  

| 年代 | 主要バージョン | 進化のポイント |
|------|--------------|-----------------|
| **2003年〜2008年** | Spring 1.x / 2.x | EJBを捨て、DI & AOPを導入 |
| **2009年〜2013年** | Spring 3.x / 4.x | アノテーション化、REST API対応 |
| **2014年〜2017年** | Spring Boot 1.x | 自動設定で爆速開発が可能に |
| **2018年〜2022年** | Spring 5.x / Boot 2.x | クラウド・マイクロサービス対応 |
| **2022年〜現在** | Spring 6.x / Boot 3.x | GraalVM最適化、Java 17以上対応 |

**Springは「開発者を楽にする」方向へ進化し続けている！**  

💬 **間違いや補足があればコメントで教えてください！**  
🚀 **Springを使いこなして、もっと開発を加速させましょう！**
LLMはベイズ推論をするのか？コイントス実験で検証

# **Enough Coin Flips Can Make LLMs Act Bayesian: LLMは本当にベイズ推論をしているのか？**

今回は、最新の研究成果である **「Enough Coin Flips Can Make LLMs Act Bayesian」** という論文をご紹介します。本研究では、**大規模言語モデル（LLM）がインコンテキストラーニング（ICL）を通じてベイズ的な推論を行っているのか、それとも単なるパターンマッチングなのかを検証** しました。

---

## **📄 論文情報**
- **タイトル**: Enough Coin Flips Can Make LLMs Act Bayesian
- **リンク**: [arXiv:2503.04722](https://arxiv.org/abs/2503.04722)
- **発表日**: 2025年3月6日
- **著者**: Ritwik Gupta, Rodolfo Corona, Jiaxin Ge, Eric Wang, Dan Klein, Trevor Darrell, David M. Chan
- **所属**: University of California, Berkeley

---

## **🔍 背景と目的**
### **1. インコンテキストラーニング（ICL）とは？**
LLMは、プロンプト内の事例から学習し、新しいタスクに適応する能力を持っています。このプロセスを **「インコンテキストラーニング（ICL）」** と呼びます。  
例えば、「コインを投げたら表が出た」という例を数回示すと、LLMはコインのバイアスを推定することができます。

しかし、ICLが本質的に **ベイズ推論に基づくものなのか、それとも単なるパターンマッチングにすぎないのか** という疑問は未解決でした。

---

## **🎯 研究の焦点**
本研究では、LLMが **バイアスのあるコイントスの結果をインコンテキストで学習し、どの程度ベイズ的な推論を行うのか** を検証しました。

### **実験の概要**
1. LLMに **「コインを投げたら、表が出た」** というデータを何回か与える。
2. LLMがコインのバイアス（表が出る確率）をどのように推定するかを観察。
3. **ベイズ推論の基礎である「ベータ分布」を用いた後更新と比較し、LLMの推論がどの程度一致するのかを測定。**

---

## **📊 実験結果**

### **1. LLMの事前分布（Prior）のバイアス**
- LLMは事前学習の影響で、**「表の確率が高め」** というバイアスを持っていることが判明。
- **モデルごとのバイアスの違い**
  - **Llama-3.1-8B** → **「表」60-80%**
  - **Mistral-7B** → **「表」70%前後**
  - **Gemma-2** → **「表」やや控えめ**
  - **Phi-2** → **「表」バランス型**

このバイアスは、事前学習データにおける **「heads」** の出現頻度の影響と考えられる。

---

### **2. 明示的なバイアス指示の影響**
「このコインは80%の確率で表が出る」というバイアス指示を与えた場合：
- **LLMは明示的な指示よりも、インコンテキストのデータを優先する**
- **指示を無視しやすいモデル**
  - **Gemma-2, Llama-3.1-8B**
- **指示を反映しやすいモデル**
  - **Mistral-7B-Instruct, Phi-3.5-mini-Instruct**

この結果から、**明示的な指示（プロンプトの記述）よりも、過去の具体的な例の方が強く影響する** ことが分かります。

---

### **3. インコンテキストラーニング（ICL）による後更新**
LLMは提供されたインコンテキストデータ（過去のコイントス結果）に応じて、 **ある程度ベイズ的な後更新を行う**。

ただし、いくつかの課題もあります：
- **誤った事前分布を持っていると、後更新が適切に機能しない**
- **短いシーケンスでは正しい分布に収束しない**
- **大規模モデルほど、後更新の質が低下する（Llama-3.1-8B-Instructなど）**

この結果から、**LLMの事前分布（Prior）を適切にキャリブレーションすることが非常に重要** だと考えられます。

---

## **📖 数式と理論的背景**
ベイズ推論では、事後分布は以下の式で求められます：

$$
p(\theta | D) = \frac{p(D | \theta) p(\theta)}{p(D)}
$$

具体的には、ベータ分布 \( Beta(\alpha, \beta) \) を用いると：

$$
p(\theta | D) = Beta(\alpha + k, \beta + n - k)
$$


LLMがこの更新を正しく行っているかどうかを検証するために、研究では **TVD（Total Variation Distance）** を計測し、LLMの出力分布と理論的なベイズ更新後の分布を比較しました。

---

## **🏛️ 研究の意義と応用可能性**
### **✅ 実用面での応用**
1. **金融市場の予測**
   - 過去のデータから確率分布を更新し、トレンドを予測。
2. **ロボット制御**
   - ベイズ的推論を活用し、不確実性のある環境での意思決定を最適化。
3. **医療診断**
   - インコンテキストデータを利用し、患者の病状予測を動的に更新。

---

## **📝 まとめ**
- **LLMは、ICLによってベイズ的な後更新を行うが、事前分布の影響が大きい**
- **明示的な指示よりもICLのデータを優先する**
- **大規模モデルほど、ICLの後更新精度が低下する傾向がある**
- **確率推論を応用する分野（金融・医療・ロボット制御）での活用可能性がある**

---

**🎯 さらなる研究の方向性**
1. **より複雑な確率分布での実験**
2. **連続確率分布を扱う LLM の評価**
3. **異なる学習データによる LLM の事前分布の変化の分析**

この記事が、皆さんの研究や実務に役立つことを願っています！ 🚀
一番簡単なVBAのSort、並び替えの方法


https://learn.microsoft.com/ja-jp/office/vba/api/excel.sort

並び替え範囲が「テーブル以外の場合」は,.SetRangeが必要です。テーブルの場合は不要です。
.SetRange Range("A1:A11")
    
    Sub ソート()
    'テーブル変数の宣言
    Dim tbl As ListObject
    ' テーブルを代入
    Set tbl = Worksheets(1).ListObjects(1)
    
    With tbl.sort　'←　.sort省略しています
    
        (.sort).SortFields.Clear
        (.sort).SortFields.Add2 _ '←アンダーバー
                                  key:=tbl.ListColumns(1).Range, Order:=xlAscending
        (.sort).SortFields.Add2 _'←アンダーバー
                                  key:=tbl.ListColumns(2).Range, Order:=xlAscending
        (.sort).SortFields.Add2 _'←アンダーバー
                                  key:=tbl.ListColumns(3).Range, Order:=xlAscending
       '((.sort).SetRange Range("A1:A11")テーブル以外は必要)                        
        (.sort).Apply
        
    End With

    End Sub


データタブの並び替えボタンを押して、並び替えが設定されていれば成功です
JavaScriptで配列がnull/undefinedではないが空であることの判定法

## 概要
JavaScriptで、配列がnullやundefinedではないが、空であることを示す関数です。

## 定義
```js
function isEmptyArrayButNotNullish(arr){
    return typeof arr !== "undefined" && arr !== null && Array.isArray(arr) && arr.length === 0; 
}
```

## 呼び出し例
```js
const x1 = isEmptyArrayButNotNullish(null);
const x2 = isEmptyArrayButNotNullish(undefined);
const x3 = isEmptyArrayButNotNullish([]);
const x4 = isEmptyArrayButNotNullish([1, 2]);
console.log(x1,x2,x3,x4);
```
## 表示結果
```text
false false true false
```
LLMは長文出力の時代へ——長い入力から長い出力へ研究のシフト

# **Shifting Long-Context LLMs Research from Input to Output: 長文生成LLMの研究シフト**

大規模言語モデル（LLMs）の進化により、AIは長大なコンテキストを処理する能力を獲得しました。従来の8Kトークンから、**128Kトークン、さらには1Mトークン**までの長文解析が可能になり、書籍レベルの読解や複数文書の統合的解析が大幅に向上しました。しかし、これらの進展は主に**長い入力の処理（Long-Input LLMs）**に焦点を当てたものであり、**長い出力を生成する能力（Long-Output LLMs）**についてはほとんど研究されていません。

本論文では、**LLM研究の焦点を「長文生成」にシフトすることの必要性**を提唱し、技術的課題、既存のモデルの限界、評価方法、今後の研究の方向性、社会実装の可能性について包括的に議論しています。

---

## **論文情報**
- **タイトル**: *Shifting Long-Context LLMs Research from Input to Output*
- **リンク**: [arXiv:2503.04723](https://arxiv.org/abs/2503.04723)
- **発表日**: 2025年3月6日
- **著者**: Yuhao Wu, Yushi Bai, Zhiqing Hu, Shangqing Tu, Ming Shan Hee, Juanzi Li, Roy Ka-Wei Lee

---

## **1. 背景と問題提起**
### **LLMsの進化と長文処理の課題**
現在のLLMsは、長いコンテキストを処理する能力が向上し、以下のようなタスクで高いパフォーマンスを発揮しています：
- **長編ドキュメントの解析（法律文書・研究論文など）**
- **マルチドキュメント検索と情報統合**
- **長文要約・生成（要点抽出・論文要約など）**

しかし、現在のLLMsは「長い出力を一貫性のある形で生成する能力」に関して大きな課題を抱えています。長文生成には、単にコンテキスト長を拡大するだけでなく、**論理的整合性（Coherence）、情報の一貫性（Consistency）、長期的な文脈追跡（Long-range Dependencies）**が求められます。

---

### **長文生成が求められる応用領域**
本論文では、長文生成LLMsが必要とされる分野として以下の応用を挙げています：
1. **創作領域**:
   - 小説執筆（プロットの一貫性維持、長編構成）
   - 脚本作成（ストーリーの流れを保持）
2. **専門文書の自動生成**:
   - 研究論文・技術文書の作成
   - 法律文書・契約書の自動生成
3. **長期計画・推論**:
   - 企業戦略立案（長期シミュレーション）
   - 科学的仮説の検証（実験設計とレポート生成）
4. **複雑なチェーン・オブ・ソート（Chain-of-Thought, CoT）**:
   - 数学・プログラミング問題の解決
   - 長期的な戦略的意思決定

---

## **2. 研究の焦点**
### **1. 長文生成の需要**
本研究では、実際のユーザーリクエストを分析し、長文生成の需要が増加していることを定量的に示しました。

| 出力長 | 需要の増加率 |
|--------|------------|
| 2K-4Kワード | 3.1倍 |
| 4K-8Kワード | 15倍 |
| 8K-16Kワード | 5.2倍 |
| 16Kワード以上 | 0.6倍 |

これは、既存のLLMが短い出力に最適化されており、長文生成の要求に対応しきれていないことを示しています。

---

### **2. 研究の不均衡**
2024年の主要ML/NLPカンファレンス（ICLR, ICML, NeurIPS, ACL, EMNLP, NAACL）で発表された104本の論文を分析した結果、**長文入力処理に関する研究が圧倒的に多い一方で、長文生成に関する研究はわずか2本**でした。

| カテゴリ | 論文数 |
|----------|--------|
| 長い入力処理の研究 | 102本 |
| 長い出力生成の研究 | 2本 |

この結果は、**「長文生成」の研究が著しく不足している**ことを示しており、今後の研究の方向性として、長文生成の重要性を強調する必要があります。

---

## **3. 既存モデルの課題**
### **(1) データ不足**
現在のLLMsのトレーニングデータは、短い出力に最適化されており、長文生成には適していません。

| データセット | 平均入力長（ワード） | 平均出力長（ワード） |
|-------------|----------------|----------------|
| LongAlpaca-12k | 5,945 | 218 |
| LongAlign-10k | 12,134 | 169 |
| Suri | 347 | 4,371 |
| LongWriter-6k | 262 | 5,333 |

この結果は、**長文生成のためには新しいデータセットが必要であることを示唆**しています。

---

### **(2) 評価手法の未成熟**
長文生成LLMsの性能を評価するための指標は、以下の3つに分類されます。
1. **ルールベース評価**: 生成されたトークン数を測定（単純な長さ制約）
2. **LLMによる評価**: LLMを用いた整合性・品質評価（コストが高い）
3. **セグメントベース評価**: 長い出力を部分ごとに評価（構造化テキスト向け）

しかし、現行の評価基準では**長期的な論理整合性や創造性を測ることが困難**であり、新しい評価指標の開発が求められています。

---

## **4. 今後の研究の方向性**
### **1. 長文データセットの拡充**
- エージェントベースのデータ収集（シミュレーションデータの活用）
- リアルワールドデータの統合（人間による長文作成ログ）

### **2. モデルアーキテクチャの改善**
- **Mamba, KAN, LongRoPE** などの新技術の導入
- **Transformer のスケーリングと最適化**
- **KVキャッシュ管理の改良**

### **3. 長文生成の評価指標の確立**
- **構成の一貫性（Coherence）**
- **情報の網羅性（Coverage）**
- **論理的整合性（Logical Consistency）**

---

## **5. まとめ**
本論文は、**LLM研究の重点を「長い入力の処理」から「長い出力の生成」に移すべき**であると主張し、新たな研究領域としての可能性を示しました。今後の技術開発により、長文生成LLMがさまざまな分野で活用されることが期待されます。
LLMVoX: LLMを拡張する軽量ストリーミングTTSの革新

# LLMVoX: Autoregressive Streaming Text-to-Speech Model for Any LLM

今回は、最新の研究成果である「LLMVoX: Autoregressive Streaming Text-to-Speech Model for Any LLM」という論文をご紹介します。本研究では、LLM（Large Language Model）を変更せずに**リアルタイムで高品質な音声を生成できる軽量ストリーミングTTS（Text-to-Speech）モデル「LLMVoX」**を提案しています。従来の音声対応LLMが抱える**計算コスト、品質劣化、遅延の問題を解決**し、LLMの言語能力を損なわずに音声対話を実現する手法として注目されています。

## 論文情報
- **タイトル**: LLMVoX: Autoregressive Streaming Text-to-Speech Model for Any LLM
- **リンク**: [https://mbzuai-oryx.github.io/LLMVoX](https://mbzuai-oryx.github.io/LLMVoX)
- **発表日**: 2025年3月6日
- **著者**: Sambal Shikhar, Mohammed Irfan Kurpath, Sahal Shaji Mullappilly, Jean Lahoud, Fahad Khan, Rao Muhammad Anwer, Salman Khan, Hisham Cholakkal
- **所属**: Mohamed Bin Zayed University of Artificial Intelligence（MBZUAI）、Linköping University
- **DOI**: 未公開

---

## 背景と目的

近年、LLMを活用した音声対話システムが急速に発展しています。しかし、**既存の音声対応LLMには以下のような課題が存在**します。

### 既存の課題
1. **LLMの改変が必要**: 既存の音声対応LLMは、LLMのファインチューニングが必要であり、本来の言語理解能力が損なわれる可能性がある。
2. **計算コストの増大**: 大規模な音声データでのトレーニングには、多大な計算リソースが必要。
3. **高遅延**: LLMのテキスト生成とTTSの音声生成が同期せず、遅延や音声品質の低下を引き起こす。

本研究では、これらの問題を解決するため、**LLMの構造を変更せずにストリーミングTTSを可能にする「LLMVoX」**を提案します。これにより、LLMの自然な言語理解能力を維持しながら、**リアルタイムで流暢な音声対話を実現**します。

---

## 研究の焦点

LLMVoXの主な特徴は以下の通りです。

1. **LLM非依存のストリーミングTTS**: 既存のLLMを変更せずに音声機能を追加できる。
2. **マルチキュー方式のストリーミング設計**: テキストと音声処理を並列化し、遅延を最小限に抑える。
3. **軽量なモデル設計**: 30MパラメータのコンパクトなTTSモデルを採用し、計算コストを削減。
4. **多言語対応**: 訓練データを変更するだけで、新しい言語に容易に適応可能。
5. **視覚言語モデル（VLM）との統合**: 追加のマルチモーダル学習なしで、テキスト・音声・視覚の統合が可能。

特に、従来の音声対応LLMと比較して、**Word Error Rate (WER) を低減し、リアルタイム性を向上**させた点が大きなポイントです。

---

## 実験の概要と結果

本研究では、LLMVoXの性能を以下の観点で評価しました。

### 1. 音声品質（Speech Quality）
- **評価指標**: Word Error Rate (WER)、UTMOS（音声の自然さを評価する指標）
- **結果**: WER = **3.70%**、UTMOS = **4.05**
- **比較対象**:
  - Whisper+LLM+XTTS（WER = 1.70%, UTMOS = 4.23）
  - MiniCPM-o（WER = 10.60%, UTMOS = 3.87）
  - Freeze-Omni（WER = 14.05%, UTMOS = 4.38）

### 2. 遅延（Latency）
- **評価指標**: 入力音声から出力音声までの時間
- **結果**: LLMVoXの遅延は **475ms** と、従来モデルと比較して大幅に低減。
- **比較対象**:
  - Whisper+LLM+XTTS（4200ms）
  - Llama-Omni（220ms）
  - MiniCPM-o（1200ms）

### 3. マルチリンガル適応能力
- **対象言語**: 英語、アラビア語
- **評価指標**: Character Error Rate (CER)
- **結果**: アラビア語での CER = **8.2%**
- **比較対象**:
  - XTTS（6.2%）
  - ArTST（26.4%）
  - Tacotron 2（66.3%）

### 4. 視覚言語モデルとの統合（VSQA）
- **統合モデル**: Qwen 2.5-VL-7B + LLMVoX
- **評価指標**: WER, CER, GPTスコア
- **結果**:
  - WER = **4.2%**
  - CER = **2.2%**
  - GPTスコア = **6.41**

この結果から、**LLMVoXは既存の音声対応LLMと比較して、より高品質な音声を低遅延で生成可能であり、多言語対応能力も持つ**ことが示されました。

---

## 賛否両論

### **賛成意見**
- **LLMを改変せずにストリーミングTTSを実現**しており、汎用性が高い。
- **低遅延（475ms）と高品質（WER=3.70%）を両立**し、リアルタイム音声対話に適している。
- **新しい言語への適応が容易**であり、アラビア語でも高い性能を示した。
- **視覚言語モデルとも統合可能**であり、将来的にマルチモーダルAIの構築に貢献できる。

### **反対意見**
- **音声クローン機能がない**ため、特定の話者の声を再現できない。
- **ASR（音声認識）部分の最適化が不十分**であり、さらなる遅延削減の余地がある。
- **対話中の音声の一貫性維持に課題がある**（長時間対話時に音声トーンが変化する可能性）。

---

## まとめ

LLMVoXは、LLMに依存せずにストリーミングTTSを実現する革新的な手法であり、従来の音声対応LLMの問題を解決する有望なアプローチです。特に、**低遅延かつ高品質な音声生成を実現し、マルチリンガル対応やマルチモーダルAIへの応用も可能である**ことが示されました。

今後の研究では、**音声クローン機能の追加**や、**ASR統合によるさらなる遅延削減**が期待されます。

---

この記事が、皆さんの研究や実務に役立つことを願っています。ご質問やフィードバックがありましたら、コメント欄にお寄せください。
【フロントエンド】スキップリンクは実装すべきなのか

## Bypass Blocks
アクセシビリティの Aレベルである [Bypass Blocks](https://www.w3.org/TR/WCAG/#bypass-blocks) についてご存じでしょうか？



[WAIC（ウェブアクセシビリティ基盤委員会） が運営しているサイト](https://waic.jp/translations/WCAG21/Understanding/bypass-blocks.html)で以下のように記述があります。
>達成基準 2.4.1 ブロックスキップ (レベル A): 複数のウェブページ上で繰り返されているコンテンツのブロックをスキップするメカニズムが利用できる。

要は、スキップリンクを活用することでなんらかの障害を持つユーザーがウェブページのメインコンテンツに素早く辿り着ける、ということ。

例えば、
ページの中央にメインの記事があり、周囲を広告、検索、ナビゲーションなどが多用されたサイドメニューに囲まれていると、ページが切り替わるたびに毎回Tabキーでそれらのコンテンツを先に処理する必要があって手間である。
また、画面を拡大しているユーザーにとって、メインコンテンツを見つけ出すのが難しい。

そういった時にスキップリンクがあると、素早くメインのコンテンツにたどり着けるので便利だということ。

## スキップリンクによるユーザビリティの向上

メインコンテンツへのスキップリンクを追加することは、ユーザー体験をよくする方法の一つとして知られています。

### 簡単な例をAIに作らせてみた
Tabで「メインコンテンツへスキップ」を選択するとナビゲーションを無視して、メインコンテンツへカーソルが移動します。
- リンクは通常ページの上部に配置され、初のフォーカス可能な要素である
- スキップリンクのターゲットは、インタラクティブな要素である(リンク、ボタン、またはtabindex属性が割り当てられている）

![画面収録 2025-03-08 20.54.40.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2508607/e851979b-9604-49d9-a734-267c09abd057.gif)

上記の例では `<main id="main-content" tabindex="-1">` とすることで、スキップリンクから辿った場合はフォーカス可能ですが、タブで順番にフォーカスを移動しても、この要素にフォーカスが当たるのを防ぐことができます。

```html
<a href="#main-content" class="skip-link">メインコンテンツにスキップ</a>

// 略

<main id="main-content" tabindex="-1">
```



実装方法は[WebAIM（Web Accessibility In Mind）のスキップリンク解説](https://webaim.org/techniques/skipnav/)なども参考になります



## ランドマーク(role='main')や見出しでは不十分か 

[When Is a Skip Link Needed?](https://www.tpgi.com/when-is-a-skip-link-needed/) によると、

>To clarify, SC 2.4.1 does not strictly require a skip navigation link in all cases. If a page includes a <main> sectioning element (or ARIA role="main" landmark) that wraps the main content, or a semantic heading at the top of the main content area, it will technically meet the requirements of this Success Criterion, even if a skip link is not present.

とあり、**技術的には、WAI-ARIAランドマーク（role='main'の指定）や 見出し構造（`<main>`セクションの使用） を適切に実装することで、SC2.4.1の達成基準を満たすことは可能** であるようです。

ただし、SC2.4.1の意図を完全に満たすわけではなく、**ユーザビリティの観点からは、スキップリンクと組み合わせることが推奨されます**。

というのもランドマーク検索の存在を知っている必要があったり、キーボードのみを使用する視覚ユーザーはランドマークに直接アクセスする機能を使えない場合があるからです。

※ そもそもランドマークとは？ となる場合、[ウェブアクセシビリティの基本：ランドマークロールを理解する](https://www.to-r.net/media/landmark/)がわかりやすかったです。

## スキップリンクは全てのページで実装すべきなのか

>ほとんどのウェブブラウザは、利用者がフォーカスをページの先頭に移動するためのキーボードショートカットを提供しているので、ナビゲーションリンク一式をウェブページの下部で提供している場合は、「スキップ」リンクの提供は不要かもしれない

とある通り、Webサイト・ページの構造によって採用を考えた方が良さそうです。

## まとめ
最低限のWCAG要件を技術的に満たすため、ページに適切なランドマークや見出しを含めたい。

多くのユーザーにとってアクセシビリティとユーザー体験を向上させる方法の一つとして、キーボードでアクセス可能なスキップリンクを追加することを検討したい。


## 最後に
ここまで見ていただきありがとうございます。

最近知ったスキップリンクについて、思考の整理として記事にしてみました。
スキップリンクはユーザーにとって便利な機能ではありますが、本機能と比べて優先度が落ちると思うので、`a nice-to-have` として余力があれば着手したいと思いました。

## 参考
- [Bypass Blocks](https://www.w3.org/TR/WCAG/#bypass-blocks)
- [WCAG21 日本語訳](https://waic.jp/translations/WCAG21/)
- [When Is a Skip Link Needed?](https://www.tpgi.com/when-is-a-skip-link-needed/)
- [WebAIM（Web Accessibility In Mind）のスキップリンク解説](https://webaim.org/techniques/skipnav/)
- [ウェブアクセシビリティの基本：ランドマークロールを理解する](https://www.to-r.net/media/landmark/)
Jetson Orin NanoとJetPack 6.2で YOLO11(v8.3.85)を動かす（2025年3月確認版）

* Jetson Orin Nano 8GB
* logicool C270N
* SanDisk 128GB microSD Extreme micro SDXC A2
* JetPack 6.2

## パッケージ一覧の更新、ブラウザのインストール等
sudo apt update
sudo apt install -y chromium-browser
sudo apt install python3-pip

## torchのインストール
```
pip3 install --no-deps torch-2.3.0-cp310-cp310-linux_aarch64.whl
pip3 install --no-deps torchaudio-2.3.0+952ea74-cp310-cp310-linux_aarch64.whl
pip3 install --no-deps torchvision-0.18.0a0+6043bc2-cp310-cp310-linux_aarch64.whl
```

参考：https://forums.developer.nvidia.com/t/pytorch-for-jetson/72048

## その他ライブラリのインストール
```
pip3 install psutil==5.9.5
pip3 install typing_extensions==4.12.2
pip3 install tqdm==4.66.4
```

### YOLO11をダウンロードします

* 「pypi.org」から「ultralytics-8.3.85-py3-none-any.whl」をHome直下にダウンロードします。

https://pypi.org/project/ultralytics/#files

### YOLO11をインストールします。
```
pip3 install --no-deps ultralytics-8.3.85-py3-none-any.whl
```

## YOLO11の動作確認
```
yolo predict model=yolo11n.pt source="https://ultralytics.com/images/zidane.jpg"
```
:::note info
検出結果は「Home/runs/detect/predict」内に保存されます（zidane.jpg）。
:::

```
yolo task=detect mode=predict model=yolo11n.pt source=0 show=True imgsz=256
```
Jetson Nanoで YOLO11(v8.3.85)を動かす（2025年3月確認版）

* Jetson Nano 4GB
* micro SDXC 64GB
* logicool C270N
* Ubuntu 20.04

## Jetson Nanoで YOLO11を動かす
### Jetson Nano with Ubuntu 20.04 OS image(2025/03/05時点：20.04 3b)を入手します
https://github.com/Qengineering/Jetson-Nano-Ubuntu-20-image

※username：jetson、password：jetson

### キーボード、タイム ゾーンの設定
Settings
-> Region & Language -> Input Sources：Other -> Japanese
-> Data & Time -> Time Zone：JST(Tokyo, Japan)

### モジュールの追加・更新
```
pip3 install psutil==5.9.5
```

### YOLO11をダウンロードします

* 「pypi.org」から「ultralytics-8.3.85-py3-none-any.whl」をHome直下にダウンロードします。

https://pypi.org/project/ultralytics/#files

### YOLO11をインストールします。
```
pip3 install --no-deps ultralytics-8.3.85-py3-none-any.whl
```

## YOLO11の動作確認
```
yolo predict model=yolo11n.pt source="https://ultralytics.com/images/zidane.jpg"
```
:::note info
検出結果は「Home/runs/detect/predict」内に保存されます（zidane.jpg）。
:::

```
yolo task=detect mode=predict model=yolo11n.pt source=0 show=True imgsz=256
```
【VSCode】VSCodeからローカルに構築したSQL Serverに接続する２ステップ


VSCode からローカルに構築した SQLServer に接続する方法について少々詰まってしまったため、同じように詰まった型のために記事に残します。

## 準備

前提として VSCode に SQL Server の拡張機能を追加しておきます。

https://learn.microsoft.com/en-us/sql/tools/visual-studio-code-extensions/mssql/connect-database-visual-studio-code?view=sql-server-ver16

## 接続

今回はプロファイルを使用した方法で接続します。

| 列名                | 値                           |
| ------------------- | ---------------------------- |
| プロファイル名      | 任意(接続後に表示されるため) |
| Server name         | (localdb)\MSSQLLocalDB       |
| Authentication type | Windows Authetication        |
| Database name       | BizCardKeeper-DB1            |

接続した SQL Server は EFCore でのマイグレーションで作成した DB です。その際に使用した接続文字列は下記になります。

```json
{
  "ConnectionStrings": {
    "LOCAL_SQL_CONNECTIONSTRING": "Server=(localdb)\\mssqllocaldb;Database=BizCardKeeper-DB1;Trusted_Connection=True;MultipleActiveResultSets=true"
  }
}
```

:::note info
C#以外の言語を習得している方のために説明しますと`EF Core`とは Microsoft が開発している C#用の ORM です。上記の状態でマイグレーションを行うとユーザー直下に「BizCardKeeper-DB1.mdf」と「BizCardKeeper-DB1.log.ldf」が生成されます。
:::

## おわりに

ローカルに DB を作成した際に Server name にどのような値を設定したらよいかわからず詰まってしまったため、同じように詰まった方の助けになれば幸いです。

良いコーディングライフを！

## 参考

https://learn.microsoft.com/en-us/sql/tools/visual-studio-code-extensions/mssql/connect-database-visual-studio-code?view=sql-server-ver16
議事録の書き方ススメ

■■■■■■■■■■プロンプト■■■■■■■■■■
依頼内容
あなたは、優秀な議事録作成担当です。
会議の内容を深く読み取り、主要な各議論と決定事項をわかりやすく要約してください。
以下のルールに従って議事録を作成してください。
 
ルール
1. 概要の要約
   ・会議全体の概要を簡潔にまとめてください（500文字以内）。
2. 議論ごとの詳細
   ・会議で議論された主要なトピックを一つずつ整理し、それぞれについて以下の情報を記載してください。
     ・議題の説明（何について話し合われたのか、背景や目的を含む）
     ・議論の要点（どのような意見や見解が出たのか）
     ・決定事項（具体的な結論、今後のアクションや責任者）
3. 形式
   ・箇条書きを使用して、見やすい形で整理してください。
   ・項目を明確に分け、読みやすい日本語で記載してください。
   ・冗長な表現は避け、必要な情報のみを簡潔にまとめてください。
4. 議事メモファイルの読み込み
   ・議事内容の詳細が記載された添付ファイルを深く読み込んだ上で、正確に内容を反映してください。
 
STEP BY STEP 指示
1. 添付ファイルの内容を確認し、会議の全体的なテーマと目的を把握してください。
2. 会議の中で議論された主要なトピックをリストアップしてください。
3. 各トピックについて、**「議題の説明」→「議論の要点」→「決定事項」**の順で情報を整理してください。
4. 整理した情報を基に、箇条書き形式でわかりやすい議事録を作成してください。
5. 完成した議事録を再確認し、不明点や追加情報が必要な場合は指摘してください。
 
例: 作成された議事録フォーマット
----------
会議概要
・日時: YYYY年MM月DD日
・参加者: ○○、△△、□□
・主な議題: ○○○についての議論
 
主要な議題
議題1: [トピック名]
・議題の説明: ○○○について議論されました。背景として、△△が挙げられました。
・議論の要点:
  ・△△の意見: ○○○
  ・□□の意見: △△△
・決定事項:
  ・今後のアクション: ○○を担当者□□が実施
  ・次回の確認タイミング: MM月DD日
議題2: [トピック名]
・議題の説明: ○○○
・議論の要点: ○○○
・決定事項: ○○○
----------
■■■■■■■■■■プロンプト■■■■■■■■■■
【Salesforce認定上級アドミニストレーター】やったこと

## この記事は
筆者が、2025年3月にSalesforce認定上級アドミニストレーターを取得した際に使用した教材などのまとめです。

### 筆者のスペック
+ エンジニア2年目
+ Salesforce実務未経験
+ これまでに認定アドミニストレーター、認定Platformデベロッパー、認定Platformアプリケーションビルダーを取得
    + [【Salesforce認定アドミニストレーター】やったこと](https://qiita.com/shi-mashimashima/items/9217fa657897538b571f)
    + [【Salesforce認定Platformデベロッパー】やったこと](https://qiita.com/shi-mashimashima/items/d3f86fe1b6468b3a68c8)
    + [【Salesforce認定Platformアプリケーションビルダー】やったこと](https://qiita.com/shi-mashimashima/items/ad663a388592a0e01337)

### 認定上級アドミニストレーター資格概要
#### 試験の詳細
+ 多肢選択式の60問
+ 試験時間は105分
+ 合格点は65%
+ 受験料は30,000円（税抜）
（20,000円だったのに2025/02/01～値上がり・・・泣）
#### 試験概要
+ セキュリティとアクセス：20%
+ オブジェクトとアプリケーション：19%
+ 監査と監視：10%
+ Cloud アプリケーション：11%
+ データと分析管理：13%
+ 変更管理とリリース：7%
+ プロセスの自動化：20%

## 勉強の流れ
だいたい2週間くらいでTraillmixと問題演習並行して取り組みました。

### Trailmix
認定資格用のTrailmixをこなしていきました。
価格表とかテリトリー管理とか新しい用語がちょいちょい出てきますね～

https://trailhead.salesforce.com/ja/users/strailhead/trailmixes/prepare-for-your-salesforce-advanced-administrator-credential

### 問題演習
問題集を周回していきます。
+ 1周目：初見の用語をスプレッドシートにまとめつつ解く
+ 2周目：復習しつつ解く、わからなかった問題は後でまとめてもっかい解く

という流れで進めていきました。
ほんとは3周したかったのですが時間なくて諦めました…

ネットの問題集は、どれを選ぶにせよ
正解が間違っている・問題集によって正解がブレている・問題文の翻訳が変
という難儀な三拍子が揃っている印象です。
ググる・ヘルプ読む・実際に操作する・Copilotに投げるなどで都度都度検証しつつ進めました。

たまにTrailblazer Communityで解説をしている方がいるので、それに当たればラッキー。

https://trailhead.salesforce.com/ja/trailblazer-community/feed/0D5KX000000NWaM0AW

スプレッドシートにはこんな感じでまとめてます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3978744/e3b424a6-1333-4b37-ad87-06f8fd115bda.png)
自分は書いて頭に入る人間なので、とにかく自分なりに殴り書いていました。
答えが間違っている問題に関しては、正答を記録しておくと後の周回で便利です。


#### 使った問題集
##### note「Salesforce認定上級アドミニストレーター試験の対策講座」
https://note.com/salesforce777/n/n1923af4339f0

全180問。有料。
他のSalesforce資格でもお世話になりました。
正解の選択肢の解説がついています。
不正解の選択肢については解説はないので注意。

##### JPN試験過去問
無料。
日付が最新だった以下の二つだけ取り組みました。
翻訳がゆるっゆる（本当にゆるっゆる）&答えが間違っている割合高めなので、上記の問題集を終えてから解き進めるとよいです。
（たまに選択肢だけあって問題文がないやつとかもありました…）

+ 全98問

https://www.jpnshiken.com/shiken/Salesforce.Advanced-Administrator-JPN.v2024-12-28.q98.html

+ 全117問

https://www.jpnshiken.com/shiken/Salesforce.Advanced-Administrator-JPN.v2024-07-08.q117.html

## 受験
### 試験会場
+ 週末にオンサイト受験しました。通信トラブルなどもなかったです。
### 試験内容
+ 回答15分+見直し20分、で35分ほどで終わりました。
+ 見たことのある問題が6割、えっなにこれ知らない！な問題が4割でした。
+ とはいえ初見の問題も落ち着いて考えれば解ける、という印象でした。
問題集の周回を通して考える道筋を頭にいれられていたのが良かったっぽいです。
+ 参考：得点率
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3978744/0d38c7d0-f20a-4acd-9233-8bd81b217b26.png)

## 終わりに
+ 割といいペースで取得できている、気がします。
+ 次はSales Cloudコンサルタント。国語をがんばります。
【TypeScript】ユニオンの分配法則？？

# はじめに
TypeChallengesという型パズルの問題集の中である問題の答えを見たとき、ユニオンの分配法則というものを当時は知らず、「なんだこれ？」となりましたので、記事へ残すことにしました。

# そもそもTypeChallengesって？
[TypeChallengesの公式サイト](https://github.com/type-challenges/type-challenges/blob/main/README.ja.md)によると下記のように書かれています。
> このプロジェクトは、型システムがどのように動作するのかを理解したり、独自の型ユーティリティを書いたり、課題へのチャレンジを楽しむことをサポートします。

簡単に言うとお題として出された型を実装しましょうといった感じですかね。
難易度は初級、中級、上級、最上級の４つに分かれています。
正直、初級の時点で難しいです笑（自分のスキルレベルの問題かもしれないですが、、、）

# 解いた問題
問題は[Exclude](https://github.com/type-challenges/type-challenges/blob/main/questions/00043-easy-exclude/README.ja.md#exclude---)で、内容としては以下です。
```typeScript
// 組み込みの型ユーティリティExclude <T, U>を使用せず、Uに割り当て可能な型をTから除外する型を実装します。
// 例：
type Result = MyExclude<'a' | 'b' | 'c', 'a'> // 'b' | 'c'

// 満たすケース(Equalの第一引数に対して第二引数の値が返ってくればOK)
type cases = [
  Expect<Equal<MyExclude<'a' | 'b' | 'c', 'a'>, 'b' | 'c'>>,
  Expect<Equal<MyExclude<'a' | 'b' | 'c', 'a' | 'b'>, 'c'>>,
  Expect<Equal<MyExclude<string | number | (() => void), Function>, string | number>>,
]
```

# 答えをみたものの理解できず、、、
解いてもわからなかったので答えを見てました。
```typescript
type MyExclude<T, U> =  T extends U ? never : T;
```
ですがこれを見ても僕は「？」でした。
「え、これだったらほぼneverにならないか？」と思ってしまったのです。
```typescript
type Result = MyExclude<'a' | 'b' | 'c', 'a'> // 'b' | 'c'じゃなくてneverにならないか？
```

# 正体はユニオン分配法則だった
同じような形のコードをもとに調べていくとどうやらユニオン分配法則とやらが関係していることがわかりました。
### ユニオン分配法則とは
> ユニオン分配はジェネリクスで使われる型変数Tに対しユニオン型が指定された場合、その各要素に対してジェネリクスの型変数を適用することを指します。

[参考: サバイバルTypeScript](https://typescriptbook.jp/reference/type-reuse/union-distribution)

サバイバルTypeScriptによると上記のように記載されています。
`MyExclude`の例をつかうなら、Tに`'a' | 'b' | 'c'`が入った場合、
`'a' | 'b' | 'c'`型としていっぺんに評価するのではなく、
`'a'`,`'b'`,`'c'`それぞれ分配して評価するようです。

### イメージ
以下のような感じで評価されているみたいです。
```typescript
// 「T」に「"a" | "b" | "c"」、「U」に「"a"」を入れた場合
type MyExclude<T, U> = T extends U ? never : T;
type MyExclude<"a" | "b" | "c", "a"> = "b" | "c"
// 実は以下のように分配して評価されていたため、上記の値になる
"a" extends "a" ? never : "a"; // never
"b" extends "a" ? never : "b"; // "b"
"c" extends "a" ? never : "c"; // "c"
```

調べる際、こちらの記事を参考にさせていただきました。ありがとうございました。

https://zenn.dev/mizchi/articles/union-condition-types

# おわりに
最初、ユニオン分配法則を知らなかったため、なんでそのような答えになるのかわかりませんでした。
ただ、知識が増えたということで、結果OKとします笑
まだまだ学ぶことが多いですが、引き続きTypeScriptについては理解を深めていきたいと思います！
Qiitaの自分の記事閲覧回数一覧をGitHubPagesに作ってみた


## 概要

- Qiita記事閲覧回数一覧取得ツール（GitHub Pages 版）
- このツールは、Qiita APIを利用して、自分の投稿した記事一覧を取得・閲覧できるWebアプリです。
- GitHub Pages上で動作し、Qiitaのアクセストークンを入力するだけで、記事情報を簡単に取得できます。
- アクセストークンがまだない場合は、Qiitaにログイン後、「設定＞アプリケーション＞個人用アクセストークン＞read_qiita」から、新しくトークンを発行してください。

## デモ

https://kubo-4ka.github.io/chk-qiita-pv/


## ソース

https://github.com/kubo-4ka/chk-qiita-pv

## 主な機能
- 記事一覧の取得
Qiita APIを利用し、自分の投稿した記事の一覧を取得
タイトル・タグ・公開日・更新日・閲覧数・いいね数・ストック数 を表示
- ソート機能
各列をクリックすると、昇順・降順を切り替え可能
閲覧数・いいね数・ストック数などでランキング化できる
- セキュリティ配慮
アクセストークンはDBなどに保存せず、Qiitaへ送信のみ利用
入力欄は「●●●」で非表示、👁ボタンを押すと可視化
Qiita APIに直接アクセスし、その他サーバーを経由しない設計
- その他便利な機能
ページネーション対応（すべての記事を取得可能）
QiitaのAPIドキュメントと説明記事へのリンクをフッターに表示
取得成功時はアクセストークン入力欄を非表示に
GitHub Pagesで動作するため、インストール不要で即利用可能
3/9追加　csv、pdfダウンロード機能
- 使い方
GitHub PagesのURLにアクセス
Qiitaのアクセストークンを入力
「取得」ボタンを押すと、自分のQiita記事一覧が表示される
並び替えや記事タイトルクリックで詳細確認も可能
- 技術スタック
フロントエンドのみで動作
HTML / CSS / JavaScript（Vanilla JS）
GitHub Pagesでホスト
Qiita APIを直接利用（Node.js / サーバー不要）
- デザイン
ダークテーマ対応
見やすいリンクカラー
シンプルな操作性

## きっかけ
- Qiitaの記事を書いてるけど、意外な記事の閲覧回数が多かったことに気付いた。
  - そう言えば記事の一覧に閲覧回数は出てない。
    - じゃあ作るか。

## 考えてたこと
- 閲覧回数って記事それぞれ表示しないと見れないのか。面倒だな。
- 移動中とかにふと眺めたい。パソコンなくてもぱっと見たい。
- 推移とかも見れたら見たい。
- スマホのネイティブアプリは面倒だな。
  - ブラウザで見ることになるだろうけど、何かAPIを利用するならスクリプトとか必要かな。
  - 閲覧回数ってログインしてないと見れないってことは認証情報スクリプトに直書き？
  - 推移見るとなると定期的にスクリプト実行と、記録の保管が必要かな。
  - サーバ用意とか必要になるけどそれは面倒だな。
    - GitHubPagesでどうにかならないかな。
    - アクセストークンはもう手入力ということにしてしまえ。
    - 推移は今回は諦めよう。
- 取り敢えず欲しい情報を一覧で取得はできた。でもテストで何回もAPI使ったけど制限とか大丈夫かな。
  - それっぽいAPIあるけどブラウザだと取得できないっぽい。諦めよう。

以上
DBeaverでフォントを変更する設定のメモ

久しぶりにDBeaverを使う時用にフォントの種類やサイズの変更方法、およびフォントサイズのショートカットキーの情報をメモしておく。
バージョン25.0のWindows版で確認。設定画面はバージョンによって変わる場合がある。

# フォント設定変更画面のたどり方
設定画面(メニューバーの`ウィンドウ`から辿れる)の`ユーザーインターフェース`-`外観`-`色とフォント`を開く。
<img src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/181011/27ecb6ec-d0e9-42be-babe-24a45f1b34dd.png width=40%>

`フィルタ入力`のところに`font`と入力する。
<img src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/181011/ee97b25d-7ed5-40b0-bb8a-d192ba4c9195.png width=50%>

そうするとフォントの設定項目がフィルタリングされて表示される。
<img src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/181011/68b7819e-4b7e-4f3c-9526-079273a403ba.png width=70%>

# 検索結果のグリッドのフォントを変更したい時
`データベースクエリ結果`の`結果グリッドフォント`を変更する。
ただしデフォルトの状態だと`DBeaver Fonts`の`Main font`が使用される。

# SQLエディタのフォントを変更した時
`DBeaver Fonts`の`Monospace font`を変更する。

# ER図のテーブル名のフォントのみを変更した時
`ER図`の`ダイアグラムフォント`を変更する。
ただしデフォルトの状態だと`DBeaver Fonts`の`Main font`が使用される。

# ER図のカーディナリティのフォントを変更したい時
`ER図`の`ER diagram notation label font`を変更する。
カーディナリティとは「1..n」みたいなやつのこと。だだしカーディナリティはER図の表示方式がデフォルトの`IDEF1X`の時は表示されず、`Crow's Foot`に変更した時だけ表示される。
また、フォントの設定変更後すぐには反映されず、表示形式を一旦`IDEF1X`に変えて再度`Crow's Foot`に戻すと反映される。ER図表示時の操作については関連記事（本記事冒頭のリンク）を参照。

# 上記以外のフォントを変更したい時
`DBeaver Fonts`の`Main font`を変更する。

# フォントサイズ変更ショートカットキーの確認・変更
設定画面の`ユーザーインターフェース`-`キー`を開く。
または`Ctrl`+`Shift`+`L`(macの場合は`Cmd`+`Shift`+`L`)を2回押しても下記設定画面が開く。
<img src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/181011/1b770068-fcd2-48cb-8efb-1d127b461831.png width=40%>

フィルタ入力欄に「grid」と入力すると**検索結果グリッド**のフォントサイズ変更のショートカットキーが確認できる。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/181011/75c3bfe0-46cb-4fc9-bb75-154d842ec11f.png)

フィルタ入力欄に「ズーム」と入力すると**SQLエディタ**のフォントサイズ変更のショートカットキーが確認できる。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/181011/1e092b40-390f-45b9-af57-75954952daf0.png)

ショートカットキーを変更したい場合は変更したい行をクリックして画面下の`バインディング`を変更して適用して閉じる。

なお、デフォルトのキーバインディングはおそらくUSキーボード用なのでJISキーボードの場合はうまくいかない場合がある。

例えばSQLエディタのズームインにデフォルトで定義されている2種類のバインディングのうち、`Ctrl++`のほうは`Ctrl`を押しながら`Shift`も押しながら`;`を押せば反応するが、`Ctrl+=`のほうは同じように`Ctrl`を押しながら`Shift`も押しながら`-`を押しても反応しない(このバインディング定義がすでに存在するから？)。

なのでデフォルトのままだとズームアウトはできてもズームインはできない状態なので、ズームインのバインディングを例えば`Ctrl+;`などに変更すると良い。
【Github actions】workflow_dispatchのinputsでmatrixの内容を動的に変更する

### 背景
弊社のQAチームでは、E2EテストをPlaywrightを用いて実行しておりますが、シナリオ数増大に伴ってテスト実行時間の増加・テストが不安定になるなどが課題になっておりました。（純粋にPlaywrightのWorkersを増やして並列実行するとやや不安定な挙動になるように見受けられました。）
そこでE2Eテストをディレクトリで分けて、Github actionsのmatrixを使ってディレクトリごとに並列実行することにより上記の課題を解決できないかと考えました。

#### matrixを使用してPlaywrightのテストを実行
純粋にmatrixを使用してディレクトごとに並列でPlaywrightのテストを実行するコードの例は以下のような形になるかと思います。（nameの配列で指定している名前でテストがディレクトリ分けされているものとします。）

```test.yaml
name: e2e
on:
  workflow_dispatch:
jobs:
  test:
    strategy:
      fail-fast: false
      matrix:
        name: ["apple", "banana", "orange"]
    timeout-minutes: 60
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - name: Install dependencies
        run: npm ci
      - name: Install Playwright Browsers
        run: npx playwright install --with-deps
      - name: Run Playwright tests
        run: npx playwright test --project=e2e-${{ matrix.name }}
```

#### workflow_dispatchのinputsを使うように修正
しかし上記のコードでは、ひとつのディレクトリのテストのみを実行したいシチュエーションに対応できない形となっています。そこでworkflow_dispatchのinputsからmatrixの内容を動的に変更して、テストを実行したいディレクトリを指定できるように修正します。
```test2.yaml
name: e2e
on:
  workflow_dispatch:
      inputs:
          tenant:
            description: "tenant"
            type: choice
            options:
              - '"apple","banana","orange"'
              - '"apple"'
              - '"banana"'
              - '"orange"'
            required: true
jobs:
  test:
    strategy:
      fail-fast: false
      matrix:
        name: ${{ fromJSON(format('[{0}]', inputs.tenant || '"apple","banana","orange"')) }}
    timeout-minutes: 60
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - name: Install dependencies
        run: npm ci
      - name: Install Playwright Browsers
        run: npx playwright install --with-deps
      - name: Run Playwright tests
        run: npx playwright test --project=e2e-${{ matrix.name }}
```

Actionsでのinputsの選択イメージとしては以下のような形となるかと思います。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3977516/1e0d3dee-6275-4f36-9fe3-786be067da36.png)



以下の記述をすることで、workflow_dispatchで選択した値をmatrixに指定することができます。例えばappleを選択した場合は、appleディレクトリのファイルのみテストが実行されます。特に指定がない場合は、"apple","banana","orange"ディレクトリすべてが実行されます。
``` yaml
matrix:
        name: ${{ fromJSON(format('[{0}]', inputs.tenant || '"apple","banana","orange"')) }}
```
コマンド実行時間の計測スクリプト

## 本記事では、コマンドの実行時間を計測するシェルスクリプト `measure_time.sh` を紹介します。

## 本コマンドの詳細

- **正しいシバン行とエラーチェック**  
  スクリプト冒頭を `#!/bin/bash` と正しく記述し、引数が渡されなかった場合には使用方法を表示して終了します。

- **柔軟なコマンド引数の受け取り**  
  `$@` を使用して、渡された全ての引数をそのままコマンドとして実行可能にし、複数の引数やオプションにも対応しました。

- **正確なタイムスタンプ取得**  
  `date +%s` を用いて、秒単位で開始時刻と終了時刻を取得し、計算処理をシンプルにしました。

- **実行時間の分解と表示**  
  秒単位で得られた実行時間を「時間」「分」「秒」に変換し、見やすいフォーマットで出力します。

- **ログの追記とエラーハンドリング**  
  実行結果（開始時刻、実行したコマンド、実行時間、終了ステータス）をログファイルに追記することで、後からの参照やデバッグが容易になるようにしました。

## スクリプト

以下は、`measure_time.sh` のコードです。

```bash
#!/bin/bash
# Usage: measure_time.sh <command> [arguments...]

# 引数がない場合は使用方法を表示して終了
if [ $# -eq 0 ]; then
    echo "Usage: $0 <command> [arguments...]"
    exit 1
fi

# ログファイルのパス（必要に応じて固定パスや環境変数で指定しても良い）
log_file="$(pwd)/record_exec_time.txt"

# 開始時間を取得
start_time=$(date +%s)
echo "[$(date)] 開始: $*"

# 渡されたコマンドを実行し、終了ステータスを取得
"$@"
exit_status=$?

# 終了時間を取得し、実行時間を計算
end_time=$(date +%s)
runtime=$(( end_time - start_time ))
hours=$(( runtime / 3600 ))
minutes=$(( (runtime % 3600) / 60 ))
seconds=$(( runtime % 60 ))

# 結果を表示
echo "実行時間: ${hours}時間 ${minutes}分 ${seconds}秒"

# ログに結果を追記（タイムスタンプ、コマンド、実行時間、終了ステータス）
echo "[$(date)] コマンド: $* | 実行時間: ${hours}時間 ${minutes}分 ${seconds}秒 | 終了ステータス: $exit_status" >> "$log_file"

# コマンドの終了ステータスで終了
exit $exit_status
```

## 実行手順

1. **スクリプトの保存**  
   `~/Software` など、管理しやすいディレクトリに上記の内容を `measure_time.sh` として保存します。

2. **実行権限の付与**  
   次のコマンドでスクリプトに実行権限を付与します。
   ```bash
   chmod +x ~/Software/measure_time.sh
   ```

3. **パスを通す**  
   任意のシェル起動時に、`~/Software` ディレクトリが PATH に含まれるように設定します。  
   例えば、`~/.bashrc` や `~/.profile` に以下の行を追加してください。
   ```bash
   export PATH="~/Software:$PATH"
   ```
   その後、以下のコマンドで変更を反映させます。
   ```bash
   source ~/.bashrc
   ```

4. **スクリプトの実行例**  
   例として、10秒間待機する `sleep 10` コマンドの実行時間を計測する場合は、以下のように実行します。
   ```bash
   measure_time.sh sleep 10
   ```
   実行後、端末に実行時間が表示されるとともに、`record_exec_time.txt` にログが追記されます。

## まとめ

今回は、実行時間計測スクリプトを紹介しました。コード開発において、そのコードを実行して終了するまでにどのくらいの時間を要したのかを確実に把握することは重要です。
エラーチェックや柔軟な引数処理、ログ出力機能により、コマンド実行の履歴管理やデバッグが容易になり、非常に役立つツールとなります。
AIエージェントデザインパターン実践：投票ベースの協調

## AIエージェントのデザインパターンを実装する

AIエージェントをLanggraphで実装する「LangChainとLangGraphによるRAG・AIエージェント［実践］入門」を読み、AIエージェントのデザインパターンを実際のユースケースに当てはめてColaboratory上で実装してみる。

https://gihyo.jp/book/2024/978-4-297-14530-9

他のデザインパターンについての記事は以下にまとめている。
- [プロンプト・レスポンス最適化](https://qiita.com/k5o/items/f24ae8b8583c0f355e89)
- [リフレクション](https://qiita.com/k5o/items/8ae34e4d45d261bddad1)
- [パッシブゴールクリエイター、プロアクティブゴールクリエイター](https://qiita.com/k5o/items/b7bd1c96f3602749352a)
- [シングルパスプランジェネレータ](https://qiita.com/k5o/items/5b5db14f6203b5e7f75d)

今回は「投票ベースの協調」パターンを実装してみる。投票ベースの協調とは、簡単に言えばエヴァンゲリヲンの「マギシステム」である。３つの独立したAIが議題に対して投票を行って、多数決により結論を出す。こちらのシステムをColaboratory上で実装してみる。

## 投票ベースの協調

以下のフローチャートをもとにAIエージェントを実装した。議題を各LLMに並列に配布し、各LLMからの投票結果を集計した最終的な結論を出す。今回は３つのLLMはコード中のllm1,llm2,llm3で定義されており、OpenAIの「gpt-4o-mini」、「gpt-3.5-turbo」、「gpt-4-turbo」を指定しているが、AnthropicのClaudeやMistral AIのMistralなど、異なる企業のなるべく異なるデータセットで学習されたLLMを指定する方が好ましいと思われる。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2517503/a7951f24-aea9-4457-9345-7c850fb8d667.png)

https://colab.research.google.com/drive/1eacKWb8ibkBVFK9kfthTI_k1Z-Seh7YI?usp=sharing

議題例としては、以下を設定した。

```
少子高齢化が進むなか、経済が低迷している国で、以下の政策を検討しています。どちらの政策が良いか、政策番号とその理由を回答してください。

1. 増税をして、教育と福祉を手厚くする。
2. 減税をして、国民の消費を促す。
```

投票結果としては「２」となったが、複数回実行すると毎回投票結果が異なるので、明確な答えのある議題であれば投票結果も安定すると思われる。なお、各LLMには投票の理由についても尋ねており、Langsmith側で確認ができる。
RaspberryPi Raspbian GNU/Linux 11 (bullseye)

RaspberryPi
OS Raspbian GNU/Linux11 (bullseye) 2025/03/08

Kernel Version 6.1.21+
RaspberryPi model B+ (初期型)

そこそこ快適に動きます(めったにGUIは使わない)です

2025年3月に出張から帰宅して
Raspberrypiを起動して
sudo apt update
sudo apt upgrade　しました。

設定は以下のコマンド
sudo raspi-config
でOverClock Midium 900MHzに設定しています

現在のDebianはGNU/Linux12ですが私の環境はひとつ前のGNU/Linux11でめちゃくちゃにソフトウェアを詰め込んでいてバージョンアップできていません。

Linuxの学習に使用中

職業はLinuxとは程遠い電気屋の見習い工です
電気工事で使用するケーブルは
.POWER
.制御
.計装
とComputerに少しは関係があるのかな...

うれしいのは
新品のDBサーバーやUPS装置やI/O盤へのケーブルの入線とかLANケーブルとか
古くなったケーブルの撤去など保守業務

Windows11を使用してこの記事を書いていますが
やはり感触(アーキテクチャmipsとかarm)が好きでUNIX LINUXを、学んでいます。
SONY PLAYSTATION2が好きでコンピューター全般について興味を持ちました。
Lpicや情報処理の資格を目指していましたが今は、とほほ(涙,,)

好きなパッケージ
mc(MidnightCommander) sudo apt install mc - CUIのツール
busybox - 十徳ナイフ
htop - topの色付き
di - df風のコマンド
pydf  dfの色付き
sl - XXXX用途は不明(入れないほうがいいよ！)

最後に
Linux (PC)は、シンプルで無駄の少ない環境
(wikipediaのUNIX哲学を参照)
(自分も大きくしてしまうけどなるたけレジストリを書き換えないアプリの選択
ドキュメントをUSBに退避させる等メインのマシン(母艦)は軽く負荷を取ってあげる)です。
【VBA】任意の範囲のセルを結合(中央揃え:１行毎)

任意のセル範囲を結合(中央揃え)にするコード。
※繰り返しのループを使用


Sub Macro1()
  For e = 4 To 68
　　Range("M" & e & ":O" & e).Select
　　With Selection
    　　.HorizontalAlignment = xlCenter
    　　.VerticalAlignment = xlCenter
    　　.WrapText = False
    　　.Orientation = 0
    　　.AddIndent = False
    　　.IndentLevel = 0
    　　.ShrinkToFit = True
    　　.ReadingOrder = xlContext
    　　.MergeCells = False
　　End With
　　Selection.Merge
　　Next
End Sub
Fast APIで動画ファイルのダウンロードをできるようにする

# はじめに
こちらの記事は[過去に作成した記事](https://qiita.com/ryo0819/items/adfde9b905cbdffb2be1)に機能を追加してみたものになります

過去の記事に目を通してからみていただくと良いかもしれません

# 何をしたかったか
元々の機能としてはFast APIで作成したエンドポイントにURLを渡した時に、動画ファイルがダウンロードできるようにするという名目で作成しました

そして、作成できたものとしてはdocker経由でコンテナを立てた後に、ローカル内でファイルをダウンロードして保存するという機能でした

これでは、保存した後に一旦ファイルが保存された場所まで確認しにいかなければいけません

今回の修正では、エンドポイントにリクエストを送った際に実際に動画ファイルが返却される(=保存される)という内容に変更してみたいと思います

# やったこと
Fast APIでファイルをレスポンスする際に使用できるものといえば「FileResponse」・「StreamResponse」の2つくらいがあると思います

自分の理解では
FileResponseがファイルの準備が完璧になってからレスポンスを返すもの
StreamResponseが逐次レスポンスを返すもの
というような認識です

フロントと結合する際、ダウンロード中に動作ができなくなるのが個人的に好きではないので「StreamResponse」を使って動画ファイルを返却できるようにしてみました

これまでは以下のようにファイルをただローカルに保存していました

```py
with YoutubeDL(ytdlp_opts) as ydl:
    ydl.download(target_url)
```

そこから以下のように処理を加えました(importなど省略しているものはあります)

```py
def generate_unique_filename():
    return str(uuid.uuid4()) + ".mp4"


@app.post("/yt_download")
async def download_yt_video(jsonbody: get_yt):
    try:
        filename = generate_unique_filename()
        ytdlp_opts = {
            "format": "best[ext=mp4]",
            "outtmpl": filename 
        }
        
        with YoutubeDL(ytdlp_opts) as ydl:
            ydl.download(target_url)
        
        return StreamingResponse(
            open(filename, "rb"),
            media_type="video/mp4",
            headers={"Content-Disposition": "attachment; filename=video.mp4"}
        )
    except:......
    <省略>
```

## 変更点
- これまでは動画ファイルの名称が「URL先の動画のタイトル.mp4」という形で保存するようにしていました
    - この問題点は、同じ動画を保存しようとした場合にダウンロード処理がされないというところが問題でした
    - なので「uuid.mp4」という形式で動画ファイルを保存できるようにしました
    - (今考えると、ダウンロード処理をスキップできるようにすれば、同じものをダウンロードしたい人がいた時に時間が省略ができたかもしれないとも思います)

- ytdlp_optsのオプション追加
    - outtmpl
        - 出力先の指定
        - 名前の付け方変えたので、ここを変えないとダメですね

- return StreamingResponse
    - ここが今回の肝になります
    - 一時的にファイルを保存してその内容をopenで読み込み、StreamingResponseの処理に乗っけるような形にしています

# 結果
この状態で以下のような形でcurlを実行してみると、実行したディレクトリ内にファイルがダウンロードされるようになりました

```sh
curl -vX "POST" "http://localhost:xxxx/yt_download" -d "{\"url\": \"https://www.youtube.com/watch?v=xxxxxxx\"}" -H 'Content-Type: application/json' -o video.mp4
```

![スクリーンショット 2025-03-08 20.06.59.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/701238/a79ff0ea-725a-4a3f-8b4e-617f429b2038.png)


# おわりに

ということで今回はStreaminResponseを使ってみたというところでした
これができるようになったということは、フロントエンドにこの情報を渡して画面からファイルがダウンロードできるようになるのかなとイメージしております

次回はその内容で記事が書ければと思います
cscの作法 その568

# 概要
cscの作法、調べてみた。
練習問題やってみた。

# 練習問題

USB メモリの情報を取得せよ。

# 参考にしたページ

https://smallgeek.hatenablog.com/entry/obrain_usb_drive_info


# サンプルコード

```
using System;
using System.Management;

namespace DevicesViewer
{
	class Program {
		private static void ShowDevices() {
			var mos = new ManagementObjectSearcher("Select * from Win32_DiskDrive where InterfaceType='USB'");
			foreach (var mo in mos.Get())
			{
				Console.WriteLine(mo);
				foreach (var prop in mo.Properties)
				{
					Console.WriteLine(String.Format("  {0} : {1}", prop.Name, prop.Value));
				}
			}
		}
		static void Main(string[] args) {
			ShowDevices();
		}
	}
}
```

# 実行結果

```
>hid2
\\DESKTOP-6CLR6AB\root\cimv2:Win32_DiskDrive.DeviceID="\\\\.\\PHYSICALDRIVE1"
  Availability :
  BytesPerSector : 512
  Capabilities : System.UInt16[]
  CapabilityDescriptions : System.String[]
  Caption : I-O DATA USB Flash Disk USB Device
  CompressionMethod :
  ConfigManagerErrorCode : 0
  ConfigManagerUserConfig : False
  CreationClassName : Win32_DiskDrive
  DefaultBlockSize :
  Description : ディスク ドライブ
  DeviceID : \\.\PHYSICALDRIVE1
  ErrorCleared :
  ErrorDescription :
  ErrorMethodology :
  FirmwareRevision : 1100
  Index : 1
  InstallDate :
  InterfaceType : USB
  LastErrorCode :
  Manufacturer : (標準ディスク ドライブ)
  MaxBlockSize :
  MaxMediaSize :
  MediaLoaded : True
  MediaType : Removable Media
  MinBlockSize :
  Model : I-O DATA USB Flash Disk USB Device
  Name : \\.\PHYSICALDRIVE1
  NeedsCleaning :
  NumberOfMediaSupported :
  Partitions : 1
  PNPDeviceID : USBSTOR\DISK&VEN_I-O_DATA&PROD_USB_FLASH_DISK&REV_1100\25C21150000600C1&0
  PowerManagementCapabilities :
  PowerManagementSupported :
  SCSIBus : 0
  SCSILogicalUnit : 0
  SCSIPort : 0
  SCSITargetId : 0
  SectorsPerTrack : 63
  SerialNumber : 25C21150000600C1
  Signature : 3272027672
  Size : 7756439040
  Status : OK
  StatusInfo :
  SystemCreationClassName : Win32_ComputerSystem
  SystemName : DESKTOP-6CLR6AB
  TotalCylinders : 943
  TotalHeads : 255
  TotalSectors : 15149295
  TotalTracks : 240465
  TracksPerCylinder : 255
  
```

以上。
Gitの超基本について忘備録

# Gitとは
　プログラムのソースコード等を管理し、さらに変更履歴を記録・追跡するための分散型バージョン管理システム。例えば、仮にソースコードを上書きしてしまっても、簡単に元に戻したりといったことができる。
 Gitといったバージョン管理システムを利用すれば、「データに対して更新版や修正版といったファイルが増えてしまう」「どのファイルを編集していいか分からなくなる」といった問題を解決できる。

 # Gitの注意点
 　Gitは便利でメリットだらけだが、以下の点に注意すべきである。
 - 学習コストがかかる
 - 運用ルールをチームで決める必要がある

# Gitの基本用語
|用語|意味|
|---|---|
|リポジトリ|ファイルや変更履歴を保存しておけるデータベース|
|リモート<br>リポジトリ|ネットワーク上にあるリポジトリ<br>他ユーザと変更履歴を共有するために使う
|ローカル<br>リポジトリ|ローカルにあるリポジトリ<br>ローカル環境でソースコード等の編集を行う|
|コミット|ファイルや変更をリポジトリへ登録する|
|プッシュ|ローカルリポジトリ上のファイルや変更をリモートリポジトリへアップロードする|
|プル|リモートリポジトリ上のファイルや変更を、ローカルリポジトリへダウンロードする|
|クローン|リモートリポジトリ上のファイルや変更を、全てローカルリポジトリへダウンロードする<br>何も登録されていないローカルリポジトリへコピーしたいときに使用|
|ブランチ|同一リポジトリ内で履歴を分岐させること、もしくはその作成した分岐<br>ブランチ側で変更を反映させても、他のブランチには影響しない。<br>バグ修正や機能追加などの場合に使用|
|マージ|作成したブランチをメインのブランチへ統合すること|

# GitHubとの違いは？
　GitHubは「Gitという仕組みを利用したweb上のバージョン管理サービス」であり、Gitという仕組みそのものではない。

# コマンド
## ブランチを指定してクローンする
```
git clone -b {ブランチ名} {リポジトリのアドレス}
```
uvでglobalにライブラリをインストールしたい

# TL;DR

uvでglobalにcliライブラリをインストールしたい場合は次のコマンドを使ってください。

```bash
uv tool install <a library which you want to install>
```

[Commands | uv](https://docs.astral.sh/uv/reference/cli/#uv-tool-install)

---

# ブログを書いた背景

毎回、uv で globalにライブラリをインストールする方法と検索しても引っかからない状態が定期的に発生していたためブログにしました。

# 考察

なぜ、「uv global」などと検索をしても検索性が悪かったのでしょうか。
理由としては、検索の方法が悪いことが原因です。

公式ドキュメントの内容を逆算すると、cli というワードを含めないといけないようです。

[Commands | uv](https://docs.astral.sh/uv/reference/cli/#uv-tool-install)

# 教訓

検索しても何も出てこないときは、なるべく言い換えることに頭を使っても良いかもしれないと感じました。
リバースプロキシとは

## リバースプロキシとは
クライアントのリクエストを受け取り、内部のサーバに転送する役割を持つサーバです

## プロキシとの違い
プロキシはクライアントのリクエストを代理で処理し、外部のサーバにアクセスします。
一方、リバースプロキシはサーバ側に位置し、クライアントからのリクエストを受け取り、適切な内部のサーバに振り分けます

## リバースプロキシのWebサイトを表示する流れ
1. クライアントがインターネットを通じてリクエストを送信します
2. リバースプロキシがリクエストを受け取ります
3. リバースプロキシがリクエストを適切なWebサーバへ転送します
4. Webサーバーがリバースプロキシに対してレスポンスを返します
5. リバースプロキシがクライアントに対してレスポンスを送信します

## リバースプロキシのメリット
### サーバの負荷分散(ロードバランシング)
複数のバックエンドサーバーにリクエストを分散し、単一のサーバがオーバーロードになるリスクを低減します

### セキュリティの向上
バックエンドサーバのIPアドレスを隠し、攻撃を防ぎます

### キャッシュによるパフォーマンスの向上
静的コンテンツ（画像、CSS、JavaScript など）をキャッシュし、応答速度を向上させます

### SSL/TLS 終端処理（HTTPS化）
SSL、TLSで通信の暗号化を行います

### コンテンツの圧縮・圧縮解除
クライアントに送るデータを圧縮し、転送速度を向上させます

## リバースプロキシのデメリット
### リバースプロキシ停止による全体のシステム停止
リバースプロキシがダウンすると、すべてのバックエンドサーバが利用できなくなる可能性があります

### データの転送や応答の速度低下
リバースプロキシを介することで、通信の処理時間が増える可能性があります
- 特に以下の処理が原因となることが多いです
  - HTTPの終端処理(SSL/TLSの暗号化・復号化)
  - キャッシュの確認
  - ロードバランシングの計算

### セキュリティリスク
- `X-Forwarded-For`ヘッダーの適切な処理がされていない場合、IPアドレスが露出します
- 誤設定により、攻撃者がプロキシ経由で不正リクエストを送信できます
- DDoS攻撃の標的になりやすい
  - すべてのリクエストがリバースプロキシを通過するため、攻撃者に狙われる可能性が高くなります
- キャッシュポイズニング
  - 悪意のあるレスポンスをキャッシュしてしまうと、他のユーザーに不正なコンテンツを配信するリスクがあります

### リソース消費の増加
暗号化・復号化や圧縮・解凍処理、キャッシュ管理などでCPUやメモリの負荷が増加します

### 設定と管理の複雑さ
- 適切な設定を行わないと、意図しない挙動（例：ヘッダー情報の欠落、キャッシュの問題）を発生させる可能性があります
- SSL/TLSの終端処理やロードバランシングの設定も必要になり、管理が複雑になります

## 代表的なリバースプロキシソフトウェア
* Nginx
* Apache HTTP Server
* HAProxy
* Traefik
* Cloudflare

## まとめ
リバースプロキシは、Webアプリケーションのパフォーマンス向上やセキュリティの強化、負荷分散に役立つ重要な役割を果たします。リバースプロキシを適切に導入することで、システムの可用性や拡張性を向上させることができます。しかし、導入にあたっては、適切な設定と管理が求められ、誤った構成や過度な負荷が発生しないように注意が必要です。リバースプロキシを選ぶ際には、目的に応じたソフトウェア（Nginx、Apache、HAProxyなど）の選定と、セキュリティ対策を十分に考慮することが重要です。