OmniAICreator/Qiita-1.07M huggingface dataset:
Azure VMでInfiniBandを有効化


# はじめに

az-305勉強中に「InfiniBand」という単語が出てきました。なにそれ知らない状態だったのでここに整理して投稿します。

# 公式ドキュメントをざっくり読む

https://learn.microsoft.com/ja-jp/azure/virtual-machines/extensions/enable-infiniband

> RDMA 対応の HB シリーズおよび N シリーズ VM の通信は、低待機時間で高帯域幅の InfiniBand ネットワークを介して行われます。 そのような相互接続を介した RDMA 機能は、分散ノードの HPC および AI ワークロードのスケーラビリティとパフォーマンスを向上させるために重要です。 InfiniBand 対応の HB シリーズおよび N シリーズの VM は、最適で一貫した RDMA のパフォーマンスのための、小直径設計の非ブロッキング ファット ツリーで接続されます。

どうやらRDMA対応通信はInfiniBandネットワークを使うみたいですね。

# 前提となるVM

InfiniBandドライバーが含まれるVMはHPC VMもしくはRDMA対応VMに適切なドライバを使用して構成するようです。

下記ドキュメントの通りHかNシリーズが前提となっています。

https://learn.microsoft.com/ja-jp/azure/virtual-machines/configure#vm-images

https://learn.microsoft.com/ja-jp/azure/virtual-machines/sizes/overview?tabs=breakdownseries%2Cgeneralsizelist%2Ccomputesizelist%2Cmemorysizelist%2Cstoragesizelist%2Cgpusizelist%2Cfpgasizelist%2Chpcsizelist#high-performance-compute

100Gb/secとかそれ以上でるみたいです。

# そもそもHPCって？

HPCとは
・ハイパー・パフォーマンス・コンピューティングの略
・従来のPCより性能がはるかに良いもの

AzureでいうHPCは？

・Hがつく仮想マシン（VM)のシリーズ
・RDMA（高スループットネットワークインターフェース）が使える


# まとめ

タイトルを「有効化」に焦点をあてたものにしたので
有効化する際のまとめです。

・ Ubuntu-HPC VM ⇒すぐ使える
・ AlmaLinux-HPC VM⇒すぐ使える
・ SR-IOV 対応の HB シリーズVM（Linux）⇒ドライバ必要※
・ SR-IOV 対応の N シリーズの VM （Linux）⇒ドライバ必要※

※

https://learn.microsoft.com/ja-jp/azure/virtual-machines/extensions/hpc-compute-infiniband-linux



PS:うーん。使うことあるのでしょうか（笑）
GitHubで１つのリポジトリにフロントエンドとバックエンドのアプリを管理する

フロントエンド(React)とバックエンド(Rails)を分けたアプリケーションを作成するにあたって、GitHubでのリポジトリ構成に悩んだ点のの自分記録。

最終的には、自分のは個人開発だし、pushは一回にしたいと思ったので１つのリポジトリに2つのアプリケーションを入れることにした。（モノレポというらしい）

## モノレポにした方法

①GitHubにリモートリポジトリを作成する
②ローカルでプロジェクトディレクトリを作成
③プロジェクトリポジトリ配下でrails new -apiとnpx create-react-upを実施
④プロジェクトリポジトリに.gitignoreを作成
⑤.gitignoreにrailsとreactのそれぞれの.gitignoreの内容をコピーして貼り付け
⑥プロジェクトリポジトリをgitの管理下にし、gitpushまで実行

## サブモジュールという方法

フロントエンドとバックエンドをそれぞれGitHub上にリポジトリを作成し
そのコミット歴を管理するリポジトリ（プロジェクトリポジトリとする）を別で作成する

プロジェクトリポジトリはフロントエンドとバックエンドのリポジトリのコミット歴を
管理し、各リポジトリへのリンクが作成できる。

こちらの説明がわかりやすかった。

https://blog.cloud-acct.com/posts/u-github-repository/

## それぞれのメリット

モノレポ
- 1つのリポジトリでプロジェクト管理できて見やすい
- それぞれのコミット歴が一度に参照しやすい
- issueやプルリクの場所が１つ

サブモジュール
- 各サブモジュールの更新やテストが独立して行える
- サブモジュール内でのコミット歴がわかりやすい
- リポジトリサイズが軽量

大きなプロジェクトで複数人が携わる場合は、モノレポにするとリポジトリが肥大化する、複数人の変更が衝突しやすいなど向かないように感じた。

一方で個人の場合には、１つのリポジトリで関連するコミット履歴が確認できるので管理しやすい。
そのため、今回はモノレポで作成してみた。

## まとめ
これまでRailsフルスタックのアプリのみ作成していたため、フロントとバックで分けた場合のGitHub管理はどうするのかという点で疑問を持った。
調べてモノレポにしたが、今のところ本番環境へのデプロイもでき、特に問題なく進められている。
VirtualBox に Manjaro Linux をインストールして日本語入力が出来るようにする

というわけで、どれだけ需要があるのかはさっぱり分かりませんが、**Manjaro Linux** をインストールして**日本語入力が出来るまで**をやります。

１．**Oracle VM VirtualBox** と **Extension Pack** をダウンロードしてインストール
　　します。
  
------ ダウンロードサイト ------
https://www.oracle.com/jp/virtualization/technologies/vm/downloads/virtualbox-downloads.html

２．**Manjaro** の **iso イメージ**をダウンロードします。種類はなんでも OK ですが、
　　自分は Xfce をダウンロードしました。
  
------ ダウンロードサイト ------
https://manjaro.org/products/download/x86

３．**VirtualBox** を立ち上げて、**仮想ドライブを生成**します

　A. メニューの『新規』を選択
　B. 仮想マシンの名前、ダウンロードした Manjaro の ISO イメージ選択
　C. メモリは６GB、プロセッサー数は２で次へ（お好み）
　D. ドライブの容量は ２０GB で次へ（お好み１５GB以上推奨）  
　E. 概要を確認して間違いなければ完了して作成

４．仮想ドライブを立ち上げます（デスクトップ環境で立ち上がり
　『Manjaroへようこそ』のメニューが表示されます）
 
　A. 左下にある**言語**を『**Japanese**』に変更
　B. 『**インストーラーを起動**』をクリック
　C. キーボードモデルの項目で『**japanese 106-key**』を選択
　D. ユーザー情報でユーザー名、パスワード、管理者（Root）パスワードを設定
　E. オフィスは**不要**なので『**No Office Suite**』を選択
　F. インストールが終わるまで待ちます
　G. インストールが終了すれば再起動を要求されますが、再起動の**チェックを入れず
 　　**に右下の**実行ボタン**をクリック
　H. Manjaro Linux内の右下に『**C→**』のようなアイコンがあるので、そこから
 　　**Shutdown** を選択
　I. VirtualBox マネージャーの方に戻り、ストレージから**光学ドライブを除去**して
 　　下さい

５．再起動すると、再び『Manjaroへようこそ』が表示される

　A. 下の方にある『**Applications**』をクリック
　B. 項目の中の『**Extended language support**』にある『**Fcitx**』に**チェック**を入れ 
 　　**UPDATE SYSTEM** ボタンをクリック
　C. **ユーザーのパスワード**を要求されるので入力すると、インストールの一覧が現れ
 　　ますので**適用ボタン**をクリック
　D. 次にオプション選択画面が出るので『**日本語**』を選択してインストール
　E. インストール後、**再起動**します（Manjaro Linuxの右下にある**C→**みたいなアイコン
 　　から）
　F. 再起動したら、右下に表示されている**キーボードアイコン**を右クリックして**設定** 
 　　を選択
   
　　F-1. **入力メソッド**タブにあるキーボード英語（US）を選択
　　　　  下欄にある**キーボードアイコン**をクリック
　　　　  既定から**日本語に変更**（順番はアルファベット順でイタリアの次）して OK 
 　　     　　ボタンを押す
　　F-2. **全体の設定**タブを選択
　　　　 『入力メソッドのオンオフ』を**左右**とも『**左Shift**』にする（枠をクリック
     　　　　して左Shiftを押す）
      
　　ここまでして、ようやく Manjaro において安定した日本語入力が可能になります
  （左Shiftで切り替え）

**---- あとがき ----**
Arch Linux を使っていて Manjaro Linux の存在を知ったので、どんなもんやろ？とインストールしてみたら、日本語入力全然出来ひんやんけ！ってなって、これはネタになるなと思い色々と試行錯誤して出来るようになりました。
デスクトップ環境の構築が簡単に出来る Arch Linux みたいな位置づけっぽいですので、興味のある方は触ってみてもいいかも知れません。
MMLU-CF: 大規模言語モデル評価の新基準 - データ汚染を克服した挑戦

# MMLU-CF: A Contamination-free Multi-task Language Understanding Benchmark

今回は、最新の研究成果である「MMLU-CF: A Contamination-free Multi-task Language Understanding Benchmark」という論文をご紹介します。本研究は、既存のベンチマークにおけるデータ汚染問題を解決し、より正確で信頼性の高い評価基準を提供することで、大規模言語モデル（LLMs）の性能評価を新たな次元へと引き上げるものです。

---

## 論文情報
- **タイトル**: MMLU-CF: A Contamination-free Multi-task Language Understanding Benchmark
- **リンク**: [arXiv](https://arxiv.org/abs/2412.15194)
- **発表日**: 2024年12月19日
- **著者**: Qihao Zhao, Yangyu Huang, Tengchao Lv, Lei Cui, Furu Wei, Qinzheng Sun, Ying Xin, Shaoguang Mao, Xin Zhang, Qiufeng Yin, Scarlett Li
- **DOI**: 不明

---

## 背景と目的

### 大規模言語モデル（LLMs）の進化
近年、大規模言語モデル（LLMs）は、自然言語処理（NLP）の多様なタスクで目覚ましい成果を上げています。これらのモデルは、文法的な正確さ、文脈理解、推論能力の点で人間に匹敵する、あるいはそれを超える性能を示しています。しかし、その能力を正確に評価するためには、信頼性が高く、公平なベンチマークが不可欠です。

#### 評価ベンチマークの役割
従来の評価ベンチマーク（MMLU、GLUE、SuperGLUE）は、以下の点で研究を牽引してきました：
- **標準化**: モデル性能を客観的に比較可能にする。
- **挑戦性**: モデルに新たな課題を提示し、進化を促進。
- **透明性**: 公開データに基づき、再現性を確保。

しかし、これらのベンチマークも限界を抱えています。特に、MMLUのような広範なベンチマークでは、データ汚染が大きな課題となっています。

---

### データ汚染の問題
データ汚染とは、評価データがモデルのトレーニングデータに含まれることで、モデル性能が過大評価される現象を指します。

#### 過去の具体例
たとえば、ある研究では、MMLUの問題がWebデータセットの一部に含まれており、これが特定のLLMsの性能向上に寄与していることが発見されました。このような汚染は、モデルが「暗記」した内容に基づいて高いスコアを出すだけであり、モデルの本来の汎化能力を測定することはできません。

#### 汚染の分類
1. **意図的汚染**: モデル開発者がベンチマークのスコアを向上させるために評価データをトレーニングデータに追加。
2. **非意図的汚染**: 公開データセットやWebスクレイピングによるトレーニングデータ内の重複。

---

## 研究の焦点
MMLU-CFは、データ汚染問題を根本的に解決するために設計されました。本研究は、以下の点に焦点を当てています：

1. **データ汚染の排除**:
   - 評価データがトレーニングデータに含まれる可能性をゼロにする。
   - 新たな非汚染化技術を採用。

2. **設問の質の向上**:
   - 難易度の最適化：簡単すぎる質問を排除し、モデル性能を正確に評価。
   - 多様性の確保：複数の分野からデータを収集し、モデルの汎化能力を測定。

---

## 方法論の詳細

### データ収集とクリーニング
- **データソース**: 公開ウェブサイト、学術データベース、オープンソースの問題集から約2.7百万件を収集。
- **クリーニングプロセス**:
  - 重複削除。
  - 不適切な質問や選択肢の排除。
  - モデルによる品質チェック（GPT-4oを使用）。

### 非汚染化技術
以下の手法で、評価データとトレーニングデータの重複を徹底的に防ぎました：
1. **リフレーズ**:
   - 質問文を別の言い回しに変更（例：「What is the capital of Japan?」を「Which city is the political center of Japan?」に変更）。
2. **選択肢のシャッフル**:
   - 選択肢の順序をランダムに並べ替え。
3. **選択肢の置換**:
   - 一部の選択肢を「None of the above」に変更。

---

## 実験と結果

### モデルの性能
主要なLLMsの結果は以下の通りです：
- **GPT-4o**:
  - 5ショット：73.4%
  - 0ショット：71.9%
- **Qwen2.5-72B**:
  - 71.6%
- **Llama-3.3-70B**:
  - 68.8%

#### 従来のMMLUとの比較
従来のMMLUでは、GPT-4oが88.0%のスコアを記録していましたが、MMLU-CFでは15%以上低下しました。これにより、MMLU-CFがより厳密な評価基準を提供していることが実証されました。

---

## 学術的および実務的インパクト

### 学術的意義
- **公正な評価**: 研究者がモデル間で正確な比較を行える。
- **研究の進展**: MMLU-CFの導入により、新たな研究課題が明確化。

### 実務的応用
- **教育分野**: 言語モデルの能力を教育目的で活用。
- **ヘルスケア**: 医療文書の理解能力を評価。

---

## 限界と今後の展望

### 現在の限界
- 現在のデータセットは言語理解に限定され、画像や音声などの多モーダルデータには対応していない。

### 将来展望
- **多モーダルベンチマークの構築**。
- **動的ベンチマークの開発**：モデルの進化に合わせた問題の動的生成。

---

この記事が、皆さんの研究や実務に役立つことを願っています。コメントやフィードバックがあれば、お気軽にお寄せください！
【React】 #1 計算機アプリを作成

# はじめに
現在、Reactを習得するために、23種類のReactアプリ開発に取り組んでいます。
今回はその第一弾として、Reactで電卓アプリを作成しました。

https://qiita.com/xYasi/items/0e223b8be80006ef9933

# 概要
一般的な電卓アプリを想定しています。以下の要件を満たすことを目標にしました。
+ 四則演算、負の数、整数、小数点の計算ができること
+ 入力中に「=」ボタンを押せないこと
+ 仕様やレイアウトをゼロから一つずつ作成すること

# 作成したアプリのイメージ
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3947973/87c9c237-bf14-c57b-3c63-369015632656.jpeg" width=60%>

# アプリ紹介動画
<iframe width="200" height="400" src="https://www.youtube.com/embed/ZvQa4U-kRgY" title="React 電卓アプリ" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

# 利用技術
+ React
+ TypeScript
+ Vite
+ Tailwind

# 意識したポイント
## useStateでデータを管理
Reactの状態管理には useState を使用しており、オペランドの情報を管理しています。
```react:Main.tsx
    const [leftOperand, setLeftOperand] = useState<string>("0");
    const [operator, setOperator] = useState<string | undefined>(undefined);
    const [rightOperand, setRightOperand] = useState<string | undefined>(undefined);
    const [result, setResult] = useState<string | undefined>(undefined);
```

## Buttonコンポーネントの作成
ボタンは繰り返し使用するため、コンポーネントを分割しました。
分割前と比較して、コードがかなりスッキリしました。
```react:CustomButton.tsx
const CustomButton = ({ isNumber, placeholder, onClick, disabled=false }: ButtonProps) => {
  const buttonStyle = isNumber
    ? { bgColor: disabled ? "bg-gray-400" : "bg-gray-300" }
    : { bgColor: disabled ? "bg-gray-400" : "bg-yellow-300" };
  return (
    <button
      className={`p-6 rounded-md text-2xl ${buttonStyle.bgColor} shadow-md w-full ${disabled ? "cursor-not-allowed" : ""}`}
      onClick={() => onClick(placeholder)}
      disabled={disabled}
    >
      {placeholder}
    </button>
  );
};
```

```react:Main.tsx 一部抜粋
<CustomButton isNumber={false} placeholder="AC" onClick={handleButtonClick} />
<CustomButton isNumber={false} placeholder="±" onClick={handleButtonClick} />
...
```

# 改善したいポイント
現状のコードでは、各ボタンに対して責務が分かれていません。
計算処理がすべてイベントハンドラ内に埋め込まれているため、
依存度が高くなってしまっています。
このままだとコードの保守性が低くなってしまうので、
後日コンポーネント分割を行い、リファクタリングする予定です。
その際には、改めて記事としてまとめる予定です。
```react:Main.tsx 一部抜粋

    const handleButtonClick = (value: string) => {
        setResult(undefined);
        switch (value) {
            case "AC":
                ...
            case "+":
            case "-":
            case "*":
            case "/":
            case "%":
                ...
```

# おわりに
コンポーネント分割に関しては、まだ改善の余地があると感じていますが、
State管理やReactコンポーネントの理解はかなり進んだと実感しています。

何より、ゼロからアプリを作り上げる楽しさを体験できて良かったです！
まだまだ始まったばかりですが、今後も継続的に学習を続けていきたいと思います。

# Github
GitHubにコードをアップロードしていますので、よかったら確認してみてください。

https://github.com/yasi1989/react-calcurator
day23 『TeamGeek』Googleのギークたちはいかにしてチームを作るのか

## はじめに
　本書籍の主張は、**ＨＲＴ「謙虚（Humility）」,「尊敬（Respect）」,「信頼（Trust）」** です。Googleのソフトウェア工学本でも触れられていました。

![Team Geek 目次2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/533414/6fbb528e-a7ef-02e2-5274-f4adf0381cb6.png)


## ポイント
### ソフトウェアの開発はチームスポートであり、技術的要素と同じだけ人的要素が影響する。

### １章　天才プログラマの神話 
- 隠したらダメになる。
- 早い段階で、高速に、何度も、失敗せよ。
- エンジニアには、コードに集中できるまとまった時間が必要だ。だが、それ以上にチームとの高帯域かつ高速な接続が必要。
- ３本柱HRT　「謙虚（Humility）」、「尊敬（Respect）」、「信頼（Trust）」
- あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ。
- 早い段階で失敗・学習・反復する。失敗を文書化する。「ポストモーテム」
- 悪いところを見せれば、それだけ強い人だと思われる。矛盾していると思うかもしれないが、違う。**間違いや能力不足を認めることは、長期的に立場を向上させるのである。**

### ２章　素晴らしいチーム文化を作る
- 文化に合わない人を面談で排除する。
- 優秀なエンジニアは優秀なチームリーダを求める。アホなリーダは優秀なエンジニアの扱いが下手。偉そうに命令する。
- 優秀なミッションステートメントは、プロジェクトが**目指さないこと**にも触れている。

### ３章　船にはキャプテンが必要
- 組立ラインの労働者は何年働いたとしても、数日間の研修を受けた労働者と交換可能だ。
- マネージャーになりたくない理由の１つ。・・・![「ピーターの法則」](https://qiita.com/AkmIOtUE4/items/983594f8f151a6129333)
- サーバントリーダ
- アンチパターン
    - 自分の言いなりになる人を採用すること。
    - パフォーマンスの低い人を無視すること。パフォーマンスの低い人をチームに残すことは、その人のためにもならない。
    - 人間の問題を無視すること。
    - みんなの友だちになること。友人関係と混同してはいけない。友人にならないとしても、昼食を一緒に食べよう。
    - 採用を妥協すること。採用にコストはかかる。
    - チームを子供扱いすること。
- リーダシップパターン
    
### ４章　有害な人に対処する
- 好ましくない振る舞いをする人は、それが悪いことだと気づいていない。あるいは、そおもそも気にしていない。無知や無関心は悪意よりもタチが悪い。**つまりはHRTが欠けている。**
- 他人の時間を尊重しない。自分の思考を垂れ流す人。
- 議論を蒸し返す人。文書を読もうという意思がない人。
- 完璧主義。
- **優しく追い出す。**

### ５章　組織的操作の技法
- オフィスの政治家には、近づかない。
- **最悪の組織は、封建制度のような指揮統制型の構造をしている。**
- 自分のアイディアが自分以外の人の口から出てくるのを耳にするのは苦痛かもしれない。でも、それがアイディアを広める唯一の方法だったりする。
- 忙しい経営者にメールでお願いする方法。短いメールのほうが返事をもらえる確率が高い。３つの箇条書きと、１つだけの行動要請を含める。

### ６章　ユーザも人間
- エンジニアリング文化は「事実」に満ちあふれている。マーケティングの人はウソばかりついている。ぼくたちはウソをつきたくない。
- Googleは、プロダクトの機能を事前に予告しない。だから、非現実的な期日に間に合わせるために![デスマーチ](https://qiita.com/AkmIOtUE4/items/9398d82bf00662f2cfac)をすることもない。ソフトウェアは、実際に準備されて利用できるようになってから、リリースされる。
- ユーザに集中すれば、他のことはすべてついてくる。
- 顧客を選ぶ。最も大事なこと：ユーザの技術的能力を考えよう。ユーザが増えると、技術の能力の平均も下がる。
- プロダクトは、最初の体験が超重要。
- 複雑さを隠す。Google検索画面。ただし、上級ユーザを不自由にしてはいけない。



## 書誌情報
- 書籍名：TeamGeek　Googleのギークたちはいかにしてチームを作るのか
- 著者：ブライアン・W・フィッツパトリック
- 出版社：オーム社
- ISBN：978--4-87311-630-3

## 参考
-
ABC385をPythonで（A～E）

ユニークビジョンプログラミングコンテスト2024 クリスマス（AtCoder Beginner Contest 385の解答等の速報的まとめ

https://atcoder.jp/contests/abc358



# A問題
https://atcoder.jp/contests/abc385/tasks/abc385_a

できるグループは
- 3つとも同じ
- 小さい2つの和が一番大きい

の2パターンに絞られる
```python:A
a, b, c = sorted(map(int, input().split()))
print("Yes" if a == b == c or a + b == c else "No")
```
# B問題
https://atcoder.jp/contests/abc385/tasks/abc385_b

問題文の通りにシミュレーションを行う
```python:B
h, w, x, y = map(int, input().split())
s = [input() for _ in range(h)]
t = input()

x, y = x - 1, y - 1
array = {"U":(-1, 0), "D":(1, 0), "L":(0, -1), "R":(0, 1)}
check = [[False] * w for _ in range(h)]
for t_i in t:
    i, j = x + array[t_i][0], y + array[t_i][1]
    if s[i][j] != "#":
        x, y = i, j
        if s[x][y] == "@":
            check[x][y] = True

print(x + 1, y + 1, sum(sum(c_i) for c_i in check))
```
# C問題
https://atcoder.jp/contests/abc385/tasks/abc385_c

等間隔に並ぶビルの開始地点と間隔を指定して全探索を行う
```python:C
n = int(input())
h = list(map(int, input().split()))

ans = 1
for start in range(n):
    for r in range(1, n):
        cnt = 1
        now = start
        while now + r < n and h[start] == h[now + r]:
            now += r
            cnt += 1
        ans = max(ans, cnt)

print(ans)
```
# D問題
https://atcoder.jp/contests/abc385/tasks/abc385_d

x軸方向とy軸方向をそれぞれ個別にSortedListで管理して探索していく
```python:D
from collections import defaultdict
from sortedcontainers import SortedList


n, m, i, j = map(int, input().split())
x = defaultdict(SortedList)
y = defaultdict(SortedList)

for _ in range(n):
    x_i, y_i = map(int, input().split())
    x[x_i].add(y_i)
    y[y_i].add(x_i)

ans = 0
for _ in range(m):
    d, C = input().split()
    c = int(C)
    if d == "U":
        lst = x[i].irange(j, j + c)
        data = [(i, l_i) for l_i in lst]
        j += c
    elif d == "D":
        lst = x[i].irange(j - c, j)
        data = [(i, l_i) for l_i in lst]
        j -= c
    elif d == "R":
        lst = y[j].irange(i, i + c)
        data = [(l_i, j) for l_i in lst]
        i += c
    else:
        lst = y[j].irange(i - c, i)
        data = [(l_i, j) for l_i in lst]
        i -= c

    ans += len(data)
    for x_i, y_i in data:
        x[x_i].discard(y_i)
        y[y_i].discard(x_i)

print(i, j, ans)

```
# E問題
https://atcoder.jp/contests/abc385/tasks/abc385_e

中心になる点を固定し、それの子になる頂点と葉になる頂点を計算する。

```python:E
n = int(input())

edge = [[] for _ in range(n)]
for _ in range(n - 1):
    u, v = map(lambda x:int(x) - 1, input().split())
    edge[u].append(v)
    edge[v].append(u)

ans = n
for i in range(n):
    lst = []
    for e_i in edge[i]:
        if len(edge[e_i]) > 1:
            lst.append(len(edge[e_i]) - 1)

    lst.sort(reverse=True)
    for i, l_i in enumerate(lst, 1):
        ans = min(ans, n - (1 + i + i * l_i))

print(ans)
```
「Experimental Demonstration of Logical Magic State Distillation」の紹介

# はじめに

本記事は、QuEra,Harvard,MITの論文「Experimental Demonstration of Logical Magic State Distillation」の概要と専門用語の解説です。

# 概要
量子情報科学における主要な目標の一つは、普遍的なフォールトトレラント量子計算の実現です。量子誤り訂正コードを用いて量子情報を論理的な量子ビットに符号化することで、物理的なエラーを検出・訂正し、論理的エラー率を大幅に低減できます。しかし、符号化された量子ビットで容易に実装できる論理操作のセットは制約されることが多く、普遍的で古典的に困難な回路を実装するには「マジック状態」と呼ばれる特別なリソース状態が必要です。

高忠実度のマジック状態を準備する主要な方法の一つが「Distillation」であり、複数の低忠実度の入力からこれらを生成します。本研究では、中性原子量子コンピュータ上で論理的量子ビットを用いたマジック状態Distillationの実験的実証を行いました。動的に再構成可能なアーキテクチャを活用し、多数の論理的量子ビットを並列に符号化し、量子操作を実行しました。d=3およびd=5のカラーコードに符号化されたマジック状態のDistillationを実証し、入力された論理的マジック状態と比較して出力の論理的忠実度が向上することを確認しました。これらの実験は、普遍的なフォールトトレラント量子計算の重要な構成要素を示しており、大規模な論理的量子プロセッサへの重要な一歩を意味します。 

# 用語の解説
1.	フォールトトレラント量子計算: エラーが発生しても計算結果に影響を与えないよう、エラー検出と訂正を組み込んだ量子計算の手法。
2.	量子誤り訂正コード: 量子情報を保護するために、量子ビットを冗長に符号化し、エラーを検出・訂正する技術。
3.	マジック状態: 普遍的な量子計算を実現するために必要な特別なリソース状態で、これを用いることで古典的に困難な計算を可能にする。
4.	Distillation: 複数の低忠実度の量子状態から高忠実度の量子状態を生成するプロセス。
5.	カラーコード: 量子誤り訂正の一種で、2次元の格子上に量子ビットを配置し、特定のパターンでエラーを検出・訂正する方法。

# 主要な図
![Screenshot 2024-12-21 at 23.01.32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1707407/b4a0b528-a461-7160-fb5b-c25eeacb8d02.png)
![Screenshot 2024-12-21 at 23.01.40.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1707407/f8babec8-f75e-16b4-2fdb-d610e6a7dbdf.png)
![Screenshot 2024-12-21 at 23.01.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1707407/b8d73fe7-1d20-62d6-e931-2496910443e5.png)
![Screenshot 2024-12-21 at 23.02.04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1707407/f6031cdf-77b8-58dc-bcb4-a42b0831770f.png)
Rocky Linux 9.4にOpenSSL 3.4をインストールする（ソースからビルド）

RockyLinux 9系では標準でOpenSSL 3系がインストールされていますが､あえて最新バージョンをソースからインストールしたい時に利用します。

## 環境

| ソフトウェア | バージョン |
|:-----------|------------:|
| OS  | rockyLinux 9.5 or Ubunt 22.04|
| OS  | OpenSSL 3.4.1 |

## 事前準備

予め以下のPerlパッケージをインストールしておく

```
sudo dnf install perl-FindBin perl-IPC-Cmd perl-Pod-Html perl-lib perl-File-Compare perl-File-Copy
sudo dnf install gcc make
```

### インストール

```
cd /usr/local/src
wget https://github.com/openssl/openssl/releases/download/openssl-3.4.1/openssl-3.4.1.tar.gz
tar xvzf openssl-3.4.1.tar.gz
cd openssl-3.4.1
./config -fPIC --shared --prefix=/usr/local/ssl
make -j 4
make install
```

### ライブラリのシンボリックリンクを作成
/usr/local/ssl/lib64に、ライブラリが配置されるため、一部のアプリケーションがライブラリを参照できないことがあるため、32ビットフォルダのシンボリックリンクを作成する

```
ln -s /usr/local/ssl/lib64 /usr/local/ssl/lib
```

以上で、/usr/local/sslに、OpenSSL3.3.xがインストールされます。
「--prefix」を付与しないと、/usr/local配下に直接インストールされるため、デフォルトインストールのOpenSSLとパスの設定によっては競合を起こすので部ディレクトリにインストールすることが望ましいと思います。
おまけ: IR通信のハッキング

### 背景
12/15にSpheroV2でIR通信を使うことができなさそうだということが分かりました。
せめて赤外光の送信内容だけでも調べて、ESP32からメッセージを送れないかと目論見ました。

### 波形測定
メイン基板の赤外光LEDの端子にオシロスコープのプローブを当て、メッセージの内容に対する赤外光LEDの両端電圧の波形を調べてみました。

上からメッセージ0, 1, ..., 7です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/103446/85fa0efb-f7b5-6c60-216d-50cbcc03d9de.png)

パルスの塊の短い場合がゼロ、長い場合が1を表していると考え、メッセージの番号との対応を次のように想像しました。
| メッセージの番号 | パルスの塊|
| ---- | ---- |
| 0 | 0000 0000 |
| 1 | 1110 0001 |
| 2 | 1101 0010 |
| 3 | 0011 0011 |
| 4 | 1011 0100 |
| 5 | 0101 0101 |
| 6 | 0110 0110 |
| 7 | 1000 0111 |

一方でSpheroEDUの通信にあるブロードキャストなどのメッセージの組み合わせを見ると、0と1、2と3のように隣り合った番号だったので、混信防止のために対にしている番号の片方は上位1バイトは反転して判別しやすくしているのかもしれません。

次に、パルスの塊の部分を拡大しました。
すみませんが、プローブのキャリブレーションし忘れていました。
この図からゼロを表すと思われる短いパルスの塊は0.024ms x 13、1を表すと思われる長いパルスの塊は0.024 x 25の波形に見えました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/103446/354ea29c-bdcf-8efa-442e-a304b2cc22aa.png)

この波形で赤外光をSphero Boltに見せればメッセージを受け取ったとだませるかもしれません。

なお、通信の距離の数字を変えた場合は、次のようにデューティが変化するようでした。
上から距離を64, 48, 32, 16にした場合です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/103446/a6d32d5f-4697-f1b3-242f-a98cf937ba47.png)

### ESP32で赤外光を送信する実験
最初はledcを使おうとしたのですが、version3以上で設定分が変わっており、何度か試したのですがうまくいきませんでした。

ダメもとでBLINKサンプルにdelayMicrosecondをいれて赤外光のLEDを接続したポートをオンオフしたところ、Sphero boltが認識してくれました。

なお、赤外光のLEDは昔捨てたテレビのリモコンから部品取りしました。


```
#define GPIO_PIN 18
#define PCOUNT0 13 
#define PCOUNT1 8
// the setup function runs once when you press reset or power the board
void setup() {
     // initialize digital pin LED_BUILTIN as an output.
    pinMode(GPIO_PIN, OUTPUT);
}

// the loop function runs over and over again forever
void loop() {
    while(1) {
        for (int j = 0; j < PCOUNT1; j++) {
            // 11 + 1 usでon / offするパルスを13個送る。1msまって8つパルスの塊を送る。
            for (int i = 0; i < PCOUNT0; i++) {
                digitalWrite(GPIO_PIN, HIGH); 
                delayMicroseconds(11); 
                // wait for a second
                digitalWrite(GPIO_PIN, LOW); 
                // turn the LED off by making the voltage LOW
                delayMicroseconds(11); 
                // wait for a second
            }
            delay(1);
        }
        delay(200);
    }
}
```

### まとめ
赤外光通信の内容を調べESP32でメッセージの送信を模擬しました。
強めに発光させる送信源を場に複数置いたり、応用して楽しめそうです。
「Aquila: QuEraの256量子ビット中性原子量子コンピュータ」の紹介

# はじめに

本記事は、QuEraの論文「Aquila: QuEraの256量子ビット中性原子量子コンピュータ」の概要と専門用語の解説です。

https://arxiv.org/pdf/2306.11727


# 概要
中性原子量子コンピュータ「Aquila」は、QuEra社の最新デバイスであり、Amazon Web Services（AWS）のBraketクラウドサービスを通じて利用可能です。Aquilaは「フィールドプログラマブル量子ビットアレイ（FPQA）」として機能し、ユーザーが構成可能なアーキテクチャ上でアナログハミルトニアンシミュレーターとして動作し、最大256の中性原子量子ビット上でプログラム可能なコヒーレント量子ダイナミクスを実行します。

このホワイトペーパーは、Aquilaの仕組み、主要な性能ベンチマーク、および代表的なアプリケーションを示す例を含む、Aquilaとその機能の概要を提供します。これには、中性原子量子コンピューティングの概要や、Aquila上で実装された単一量子ビットのダイナミクスから組合せ最適化まで、複雑さが増す5つの例が含まれています。

このホワイトペーパーは、中性原子量子コンピューティングについて詳しく知りたい読者、Aquilaの使用を開始する準備ができている方、およびアナログ量子コンピュータとしての性能の参考資料を求める方を対象としています。

# 用語の解説
1.	中性原子量子コンピュータ: 電気的に中性な原子を個々に捕捉し、量子ビット（qubit）として利用する量子コンピュータの一種。中性原子は相互作用が制御しやすく、高いスケーラビリティを持つとされる。
2.	フィールドプログラマブル量子ビットアレイ（FPQA）: ユーザーが構成可能な量子ビットの配列を指し、従来のFPGA（フィールドプログラマブルゲートアレイ）の量子版とも言える。量子ビットの配置や相互作用をプログラムによって柔軟に設定できる。
3.	アナログハミルトニアンシミュレーター: 物理系のハミルトニアン（エネルギー演算子）を直接模倣することで、量子システムの時間発展をシミュレーションする装置。デジタル方式と異なり、連続的な量子状態の変化を再現する。
4.	コヒーレント量子ダイナミクス: 量子ビット間の相互作用や外部操作によって、量子状態が時間的に一貫性を保ちながら変化する現象。コヒーレンスが保たれることで、量子計算の精度や効率が向上する。
5.	組合せ最適化: 複数の組み合わせの中から最適な解を見つけ出す問題。量子コンピュータは、特定の組合せ最適化問題に対して高速に解を求められる可能性があり、物流やネットワーク設計など多岐にわたる分野での応用が期待されている。

# 主要な図

![Screenshot 2024-12-21 at 22.51.22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1707407/8791c0d8-1458-bc76-5879-4da3dad1bd94.png)
![Screenshot 2024-12-21 at 22.51.28.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1707407/c2cc9f67-9e22-08db-8094-47fe967e4e31.png)
![Screenshot 2024-12-21 at 22.51.35.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1707407/e2590482-4b88-2a17-314b-b1a091115138.png)
![Screenshot 2024-12-21 at 22.51.41.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1707407/119617fb-7cda-6f4f-e594-33a9c5268452.png)
![Screenshot 2024-12-21 at 22.51.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1707407/16f7277d-2315-0dde-36e0-36509f20b8c1.png)
![Screenshot 2024-12-21 at 22.51.57.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1707407/34efdff3-4218-068a-003d-3da3a41d0a8f.png)
![Screenshot 2024-12-21 at 22.52.08.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1707407/b53bf4c8-644f-fb5f-6c7b-fcc381c61dc2.png)
ひとりアドベントカレンダーを終えて

お疲れさまです、みやもとです。

めでたくひとりアドベントカレンダーを完走することができました。
長かった。

周囲の知り合いが挑戦しているのを見て軽率に挑戦してみましたが、やってみるとめちゃくちゃ大変でした。
最終日は振り返りをしたいと思います。

# ネタがすぐ無くなる
いざ書くとなると本当にすぐネタがなくなりました。
LINEBOTのネタで多少埋めることができましたが、実際のところ意図した動きをするものが作れるまでに結構かかっていて、記事にできる段階にたどり着くまでを埋めるのに何を書こうか頭を抱えました。
イベント振り返り記事はそのための苦肉の策です。

# ネタのために作る
ネタがなくなるので書くために何か作ったり調べたりすることになりましたが、何もないとあれこれ理由をつけて初動が遅れがちな身としては一種の締切駆動となり悪くなかったように思います。
この約1か月間は私にしては驚くほど何かを作ったり調べたりした期間になりました。

# 終わった時の安堵と達成感
最後の記事を書きながら思うのは、これで明日からは公開に間に合わないことにおびえなくて済むという安堵と、25日間毎日公開できるだけの記事を書ききった達成感です。
記事の質を考えれば毎日公開するだけのために今ひとつの内容まで記事にしていたところもあるので反省すべきではありますが、やりきったこと自体は我ながら頑張ったと思います。

来年はもうやらないかもしれませんが、1か月結構楽しく続けることができました。
田舎と都会の差について

# 田舎と都会の差

## はじめに

日本の地域差として「田舎」と「都会」はよく取り上げられます。今回はこのお題について割と真面目にやっていきます。両者には文化、生活スタイル、インフラ、自然環境などさまざまな違いがあります。今回は、**田舎と都会の生活における違い**をいくつかの観点から紹介し、それぞれのメリット・デメリットを比較してみます。

## 1. 生活環境の違い

### 田舎の特徴
- **自然環境**：田舎は広大な自然に囲まれ、四季の移り変わりを感じやすい場所が多いです。農作物を育てることができる環境もあります。
- **静かさ**：人々の騒音が少なく、静かな生活が送れます。
- **広い土地**：住宅や土地が広く、庭付きの一軒家を安価で手に入れることができます。

### 都会の特徴
- **都市化**：ビルや道路、公共施設が整備されており、住環境は便利で快適です。
- **交通の便**：公共交通機関が充実しており、車を持たなくても生活できる環境が整っています。
- **利便性**：スーパー、病院、学校など生活に必要な施設が徒歩圏内に揃っており、買い物や仕事、遊びに行くのに便利です。

## 2. 仕事と経済活動の違い

### 田舎
- **農業や漁業が主な産業**：田舎では農業や漁業など、自然資源を利用した仕事が中心です。都会に比べて産業の選択肢は限られています。
- **雇用機会**：企業の本社や支社が少なく、就職や転職の選択肢が限られることがあります。

### 都会
- **多様な職業選択肢**：企業の本社が集中しているため、専門職からサービス業まで多くの選択肢があります。転職活動やキャリアアップも盛んです。
- **高賃金**：都会の企業では賃金水準が高いことが多く、特にIT業界や金融業界では高給を得やすい傾向があります。

## 3. 人々の交流とコミュニティ

### 田舎
- **地域密着型の生活**：小さなコミュニティでは近隣住民との交流が密接で、助け合いの精神が根強くあります。しかし、プライバシーが少なくなることもあります。
- **近所付き合いの重要性**：地域行事やお祭りなど、地域活動が活発で、人々とのつながりが重要視されています。

### 都会
- **匿名性が高い**：都会では個人のプライバシーが尊重され、他人と関わる機会が少ないため、孤独を感じることもあります。
- **多文化共生**：異なる文化を持った人々が集まり、多様な価値観やライフスタイルを受け入れる環境が整っています。

## 4. 教育と子育て

### 田舎
- **教育環境**：田舎の学校では、規模が小さく、先生と生徒の距離が近いといった利点があります。一方で、専門的な教育機関や選択肢は少ない場合があります。
- **子育ての環境**：自然と触れ合いながら育つことができるため、健やかな成長が促される一方で、子供の遊ぶ場所や友達が少ないこともあります。

### 都会
- **充実した教育施設**：都会には多くの教育機関や習い事、文化施設があります。選択肢が多く、専門的な教育が受けやすい環境が整っています。
- **子育ての課題**：都市部では遊ぶ場所が限られていたり、交通渋滞や騒音などが子供にとってのストレスになることもあります。

## 5. 生活費

### 田舎
- **安価な物価**：家賃や土地代が安いため、生活費を抑えることができます。また、地元の食材が手に入りやすく、食費を節約できます。

### 都会
- **高い物価**：家賃や食品、日用品の価格が高くなることが一般的です。しかし、便利さを享受するためにはその分のコストがかかります。

## 6. 建物・道路

### 田舎
- **駐車場が広い**：田舎では広大な土地が都会よりも安価で購入できるため、トラックや乗用車が入っても十分に止めることのできるスペースがあります。
- **精米所**：田舎には大体、徒歩十分圏内に精米所という玄米を白米にする建物があります。都会では白米の状態で売られているため見かけることがありません。
- **道が狭い**：田舎では多車線道路ではなく車両通行帯のない道路（片側一車線の道路）であるため右左折レーンが整備されてないことがあり、右左折車両の渋滞にはまることがあります。

### 都会
- **駐車場が狭い**：都会には広いスペースもなく安価な土地も少ないためどうしても駐車場が狭くなってしまう傾向にあります。そのため、トラックも止めるには十分なスペースが確保できないというのが現状です。
- **道が広い**：都会では多車線道路があり、単線とは違い渋滞がしにくくなるといった効果があります。又、右左折レーンが整備されているため、右左折車両の渋滞にはまることがありません。

## まとめ

田舎と都会には、それぞれに魅力と課題があります。田舎は自然に囲まれた静かな生活が送れる一方で、仕事や生活の利便性に欠ける部分もあります。都会は仕事や生活において便利で、選択肢も豊富ですが、その代わりに高い生活費や人間関係の希薄さが課題です。

あなたがどちらの生活を選ぶかは、何を優先するかによって大きく変わるでしょう。**田舎の落ち着いた環境**を重視するのか、**都会の利便性と多様性**を求めるのか、自分のライフスタイルに合った選択をすることが大切です。
SQLiteとRoomを解説

## はじめに
最近、新規開発中のアプリでSQLiteとRoomを導入する機会がありました。導入にあたって学習した内容を備忘録としてまとめておこうと思います。

## SQLiteとは？
SQLiteは、軽量でサーバーレスのリレーショナルデータベース管理システム（RDBMS）です。データベース全体が1つのファイルに保存され、アプリケーションに直接組み込んで使用します。Androidアプリでは、ローカルストレージ用データベースとして広く使われています。

**特徴**
・SQL文を直接記述してデータ操作を行う
・軽量でサーバーレス
・低レベルで柔軟だが、データ操作に冗長なコードが必要

## Roomとは？
Roomは、Googleが提供するSQLiteの抽象化ライブラリです。SQLiteの扱いを簡単かつ安全にするための仕組みを提供します。

**特徴**
・SQLiteの機能を利用しながら、簡潔で安全なコードが書ける
・コンパイル時にSQLやスキーマの検証を行い、エラーを防ぐ
・LiveDataやFlowを利用したリアクティブデータ処理をサポート

## 実際にコードを見て比較する
### Roomを使う前（SQLiteを直接操作する場合）
```kotlin
val dbHelper = object : SQLiteOpenHelper(context, "my-database", null, 1) {
    override fun onCreate(db: SQLiteDatabase) {
        db.execSQL("CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT, age INTEGER)")
    }

    override fun onUpgrade(db: SQLiteDatabase, oldVersion: Int, newVersion: Int) {}
}

val db = dbHelper.writableDatabase

// データ挿入
val values = ContentValues().apply {
    put("id", 1)
    put("name", "John Doe")
    put("age", 25)
}
db.insert("users", null, values)

// データ取得
val cursor = db.rawQuery("SELECT * FROM users WHERE id = ?", arrayOf("1"))
if (cursor.moveToFirst()) {
    val name = cursor.getString(cursor.getColumnIndex("name"))
    val age = cursor.getInt(cursor.getColumnIndex("age"))
    println("$name, $age")
}
cursor.close()
db.close()
```

**問題点**
・SQL文を手動で記述
・型安全性が低い
・コードが冗長
・保守性が低い

### Roomを使った場合

**エンティティ定義**
```kotlin
import androidx.room.Entity
import androidx.room.PrimaryKey

@Entity(tableName = "users")
data class User(
    @PrimaryKey val id: Int,
    val name: String,
    val age: Int
)
```

**DAO定義**
```kotlin
import androidx.room.Dao
import androidx.room.Insert
import androidx.room.Query

@Dao
interface UserDao {
    @Insert
    fun insert(user: User)

    @Query("SELECT * FROM users WHERE id = :userId")
    fun getUserById(userId: Int): User
}
```

**データベース定義**
```kotlin
import androidx.room.Database
import androidx.room.RoomDatabase

@Database(entities = [User::class], version = 1)
abstract class AppDatabase : RoomDatabase() {
    abstract fun userDao(): UserDao
}
```

**実行コード**
```kotlin
val db = Room.databaseBuilder(
    context,
    AppDatabase::class.java,
    "my-database"
).build()

val userDao = db.userDao()

// データ挿入
userDao.insert(User(1, "John Doe", 25))

// データ取得
val user = userDao.getUserById(1)
println("${user.name}, ${user.age}")
```

## まとめ
Roomを使うことで、安全性・保守性・効率性が大幅に向上します。

・SQLiteを直接操作する場合は柔軟性が高いものの、コードが複雑でミスが起きやすい。
・Roomは、SQLiteを利用したアプリ開発を簡略化し、特にモダンなAndroidアプリ開発において推奨される選択肢です。

SQLiteを直接使うのは古い手法になりつつあり、Roomを活用することで効率的にデータベース操作を行うことができます！
LibreChatでMCPを使ってみた

[LibreChat](https://github.com/danny-avila/LibreChat)はオープンソースでセルフホストできるChatGPTクローンです。先日MCP（Model Context Protocol）クライアントとしてツールを呼び出せる機能も実装されました。

![Screenshot 2024-12-21 22.19.53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/50391/2139913f-f4f9-a1a2-d137-ea43ba19d84f.png)

[▲MCPの公式ページにも掲載されています](https://modelcontextprotocol.io/clients#feature-support-matrix)。ちなみに掲載はとても早く、LibreChatのMCP対応版v0.7.6がリリースされるよりも前に（[対応がmainブランチにマージされて](https://github.com/danny-avila/LibreChat/pull/5015)からすぐ）掲載されていました。

LibreChatのMCPクライアントとして、すでに公開されているMCPサーバを設定することで、簡単にMCPを体験できます。早速使ってみましょう。

## LibreChatの環境構築
まずLibreChatをcloneして、v0.7.6以上のバージョンにチェックアウトします。

```
$ git checkout v0.7.6
```

今回はMCPサーバのうち、everythingというサンプル実装を使います。

https://github.com/modelcontextprotocol/servers/tree/main/src/everything

`librechat.yaml`を下記のように記述します。

```yaml:librechat.yaml
version: 1.2.0

cache: true

# https://github.com/danny-avila/LibreChat/pull/5015
mcpServers:
  everything:
    command: npx
    args:
      - -y
      - "@modelcontextprotocol/server-everything"
```


`docker-compose.override.yaml`で、設定ファイルのyamlを読み込むように設定します。なお`deploy-compose.yaml`の方を使う場合はこの変更は必要ありません。

```yml:docker-compose.override.yaml
services:
  api:
    build:
      context: .
      dockerfile: Dockerfile.multi
      target: api-build
    restart: 'no'
    env_file:
      - .env
    volumes:
      - type: bind
        source: ./librechat.yaml
        target: /app/librechat.yaml
```

`.env`に`OPENAI_API_KEY`などをセットしておきます。

準備ができたら起動します。

```
$ docker compose pull
$ docker compose up --build
```

`http://localhost:3080` でLibreChatにアクセスできます。

LibreChatでMCPを利用するには、LibreChatにv0.7.6から導入されたAgents機能を使います。`.env`や`librechat.yaml`でエンドポイントメニューを管理している場合、`agents`が出るように設定しておきましょう。

## LibreChatでMCPを呼んでみる
LibreChatの画面が表示されたら、エンドポイントメニュー（画面上部）で「Agents」を選択します。

<img src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/50391/76be4eed-806f-ebaa-0d29-7298f916c483.png width=320 />

適当なエージェントを作成します。

<img src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/50391/edeb61e2-27ff-47df-6e88-c14c4c0dde0c.png width=320 />

「ツールを追加」から、everythingのツールを追加します。ここでは、2つの数値を足し算する「add」を選択しました。

<img src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/50391/19b9330a-07b7-4f7f-d48f-ce40179e0a34.png width=320 />

これで準備は完了です。あとはエージェントに対して、適当なプロンプトを投げて実行できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/50391/154d3f0b-b12a-7a54-b041-295c7e1d71b2.png)

実行結果から、everythingをツールとして使ったことが分かります。

## まとめ
LibreChatをクライアントとして、MCPでツールを使うことができました。

MCPが今後発展していくかどうかは、まだ分かりません。[MCPの公式リポジトリ](https://github.com/modelcontextprotocol/servers)には様々なサーバの実装が公開されていますが、LibreChatの作者には[標準入出力を利用するサーバ実装が多い点が指摘](https://github.com/danny-avila/LibreChat/issues/4876#issuecomment-2536194078)されており、まだ課題のある技術であることが分かります。
MCPが今後どうなるかは、MCP自体の発展だけでなく、周辺のツールやサービスがどのように追従するかが重要だと思います。今後もLibreChatのようなMCP周辺ツールの動向が気になります。
サンタクロースの移動速度を試算してみる

クリスマスの夜、世界中の子供たちにプレゼントを届けるサンタクロース。
彼は一体どれだけのスピードで移動しているのでしょうか？

このテーマ自体はどこかの記事で既出だった気がしますが、自分でも検証してみます。

# 検証方法

地球上には約20億人の子供がいると仮定し、家庭あたりの平均子供数を2人とすると、配達先の世帯数は10億世帯。

地球の表面積は約5.1億平方キロメートルなので、各家庭が地球上に均等に分布していると仮定すると、家同士の平均距離は約0.71キロメートルと計算できます。

サンタクロースがすべての家庭にプレゼントを届けるには、この平均距離に世帯数を掛けた距離を移動する必要があります。

そして、配達にかかる時間を設定することで、必要な速度を計算できます。

# Pythonコード

以下は、サンタクロースの速度を計算するPythonコードです。

```python
import math

def santa_speed(delivery_time_seconds=3600):
    children = 2_000_000_000
    children_per_household = 2
    households = children / children_per_household
    earth_surface_area = 510_072_000
    average_distance_between_houses = math.sqrt(earth_surface_area / households)
    total_distance = average_distance_between_houses * households

    if delivery_time_seconds <= 0:
        print("配達時間は正の値を入力してください。")
        return None

    speed_km_per_sec = total_distance / delivery_time_seconds
    mach = speed_km_per_sec / 0.343
    speed_of_light = 299792.458
    c = speed_km_per_sec / speed_of_light

    return speed_km_per_sec, mach, c

# 8時間、1時間、1分の場合の速度を計算
eight_hours = 8 * 60 * 60
speed_8h, mach_8h, c_8h = santa_speed(eight_hours)
speed_1h, mach_1h, c_1h = santa_speed()
speed_1min, mach_1min, c_1min = santa_speed(60)

# 結果を表示
print(f"配達時間 8時間: 速度={speed_8h:.2f} km/s, マッハ={mach_8h:.2f}, 光速の{c_8h:.6f}倍")
print(f"配達時間 1時間: 速度={speed_1h:.2f} km/s, マッハ={mach_1h:.2f}, 光速の{c_1h:.6f}倍")
print(f"配達時間 1分: 速度={speed_1min:.2f} km/s, マッハ={mach_1min:.2f}, 光速の{c_1min:.6f}倍")

```

# 検証結果

このコードを実行した結果は以下の通り。

* 配達時間 8時間: 速度=2373.62 km/s, マッハ=6920.19, 光速の0.007919倍
* 配達時間 1時間: 速度=18989.00 km/s, マッハ=55361.51, 光速の0.063356倍
* 配達時間 1分: 速度=1139339.97 km/s, マッハ=3321690.84, 光速の3.801045倍


# 考察

サンタクロースが8時間でプレゼントを配り終えるためには、マッハ6920という驚異的な速度で移動する必要があります。
さらに、1分となると光速の約4倍という、物理的に不可能な速度になります。

もちろん、これは単純化されたモデルに基づいた計算であり、現実のサンタクロースの移動方法はもっと複雑で、様々なパターンを考慮する必要があります。


# おわりに

サンタクロースの速度を科学的に検証するのは難しいですが、この検証を通して、彼がいかに迅速な対応をしているかを実感することができました。

これからも、子供たちの夢のために、頑張って欲しいです。
containerlab, vrnetlab での vjunos-switch のポート数は最大でも12

## やりたかったこと

[containerlab](https://containerlab.dev/) で使っている [vJunos-switch](https://containerlab.dev/manual/kinds/vr-vjunosswitch/) に色々つなぎたくなった。

[vJunos-switchのドキュメント](https://www.juniper.net/documentation/us/en/software/vjunos-switch/vjunos-switch-kvm/topics/configuring-vjunos-switch-topic-map.html)には

>You can specify the number of active ports for the vJunos-switch to match the number of NICs added to the VFP VM. The default number of ports is 10, but you can specify any value in the range of 1 through 96.
>
>Run the `user@host# set chassis fpc 0 pic 0 number-of-ports 96` command to specify the number of active ports. Configure the number of ports at the [edit chassis fpc 0 pic 0] hierarchy level.

とあるので実行しポート数を増やしてみた。

しかし、`show interface`してみると `ge-0/0/11` 以降のポートのLinkがDownになっており通信できなかった。

## 結論

普通に使えばポート数は最大11（ge-0/0/10まで）。

[launch.pyの`num_nics`](https://github.com/hellt/vrnetlab/blob/21c3f5a0a3ac8a38fdb9f42b389be4988bc13c28/vjunosswitch/docker/launch.py#L98)を変更すれば、12個までは増やすことができた。

それ以上にする方法は分からなかった（vrnetlabのコードを読めば分かるかもしれない...）

## 原因

containerlab でのコンテナには`eth12`等のNICも作成されているが、コンテナ内部で動くvJunos-switch のVMに接続されていないことが原因だった。

`docker logs`で起動ログを確認するとコンテナ内部で実行されたQEMUのコマンドを確認できるが、そこでは `tap11`までしか作成されていない。コンテナのシェルに入りインタフェースを確認しても`tap11`までしかないことが分かる（分かりづらいが、tapXとethXの番号は1-indexなので、0-indexであるge-0/0/Xの値よりも1大きくなる）。

QEMUでのVM作成時にもっといっぱいtapを作成して繋いでくれたら嬉しい。[vJunos-switchのDockerfile](https://github.com/hellt/vrnetlab/blob/master/vjunosswitch/docker/Dockerfile)を読むと`launch.py`が実行されているようなので確認すると、[`num_nics`](https://github.com/hellt/vrnetlab/blob/21c3f5a0a3ac8a38fdb9f42b389be4988bc13c28/vjunosswitch/docker/launch.py#L98)というそれっぽい値が見つかった。


これを16に変更してみたが、
```
vrnetlab   DEBUG    highest allocated interface id determined to be: 12...
```
と出力され、1個増えただけであった。

コンテナ内部の `vrnetlab.py` を確認し、`gen_nics()` という関数がこれらNICの処理をしていることまでは分かった。が、これ以上の調査はかなり沼になりそうなので一旦12個まででなんとかすることにした。
また時間があるときにvrnetlabのコードを読んでみようと思う。
「データ解析のための数理統計入門」解答メモ 第2章 問1-問7

以下第2章問1-問7解答メモ
![1.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3959389/00825c32-d764-b12a-75fa-f04918ac8805.jpeg)
![2.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3959389/e4b9941c-3784-d065-73ee-4d4f4d4231b3.jpeg)
![3.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3959389/49b07546-c8b3-253c-714f-7148a76974f1.jpeg)
![4.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3959389/8bc4e336-8e53-56f6-fe30-46e591af9e29.jpeg)
![5.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3959389/48c5f716-f48d-a531-db7b-8dde3a072f9a.jpeg)
![6.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3959389/fbb2536d-55c3-a901-185a-bc0643f2b0e0.jpeg)
登壇者の立場でイベントレポート「IT/Webエンジニアによる『今年印象に残ったインプットLT会』」

お疲れさまです、みやもとです。

先日、エバンジェリストとして参加しているWAKE Community主催のLT会に登壇者のひとりとして参加させていただきました。

https://wake-career.connpass.com/event/339294/

登壇したイベントのレポートを書くのは初めてのような気がするので、今回は登壇者として登壇メンバー発表からイベント終了までの心境をメインに書かせていただきます。

# LT登壇メンバー発表
だいたいイベント開催1週間ぐらい前だったでしょうか。
Connpassのイベントページに登壇者とLTの内容が反映されていました。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3477580/13fe3208-6516-3e1c-f367-36bf5295424d.png" width="70%">

画像は一例ですが、正直この時点でちょっとうろたえました。
<b>すごい、みなさま概要がわかりやすいしすごくまじめな感じがする。</b>
もうちょっと詳しく書いた方がわかりやすかっただろうか、いやでもタイトルすら仮だし内容もそこまでかっちり決めてないし…と早くも葛藤し始めます。
ともあれ、申し込んだからにはやるしかないのだと腹をくくって発表用スライドの準備に入りました。
LT時間が5分と短めだったこともあり、資料作成自体はスムーズに作り終えることができました。

# イベント開始直前
イベント開始10分前からZoomの入室可能という連絡があり、接続確認のため少し早めに入らせてもらいました。
オンライン登壇は久しぶりだったのでこの点でも少し心配だったのですが、問題なく資料の共有ができることを確認して開始を待ちます。

# イベント開始～登壇直前
そうしてイベントが開始され、WAKE Careerの紹介や企画の説明を経ていよいよLTが始まりました。
私はプログラムの3番目だったので、前のお二人のLTを聞きながら待ちます。

<b>なんかみなさんめちゃくちゃ話が上手いな？</b>
私の前のお二人はどちらもLT初挑戦だったそうなのですが、そうは思えないほど落ち着いた話し方でわかりやすい。
スライドもテンプレートからして洒落た雰囲気ですごくスマートにまとまっています。
良いLTを聞けた満足度に比例するように私の緊張が高まっていくのがわかりました。

# 登壇
そしていよいよみやもとのLTの番になりました。
<b>実のところ自分がどんな感じで話していたのかあんまり覚えていません。</b>
LTの時は毎回そうなのですが、一人で複数人を相手にあれこれ説明する状況だと緊張度合いがぐんぐん上がっていって、気が付いたら全部終わってた…というのが常のパターンだったりします。
ただ、自分の発表パターンとして<b>場の持たなさからちょいちょい茶化しを入れてしまう</b>悪癖があるのは自覚しており、今回もそうだったとは思います。

# イベント終了まで
自分のLTが終わったところでかなり気が抜けて、残る三人の方のLTは登壇前よりはリラックスして聞けたと思います。
<b>やっぱりみなさんめちゃくちゃ話が上手いな？</b>
全体にすごく落ち着いてためになるお話でした。
本の紹介とか勉強法とか、私も試してみたい情報がいっぱいでした。

# 感想
イベント全体としてはすごく楽しく、充実した内容でした。
先述の通りみなさまお話も資料の作り方もすごくお上手で、イベントの間ひたすら感心しっぱなしでした。
しかし自分の発表を振り返るとひたすら恥ずかしく、もっと落ち着いて話せないのかと頭を抱えてしまうばかりです。
ファシリテーターの方やイベント参加者の方からポジティブな感想をいただけたことだけが救いでした。

WAKE Communityのイベントは後日アーカイブが公開されます。
普段はとても楽しみなのですが、今回に限っては恥ずかしくて見られない気がしています。
ChatworkのWebhookにGASを指定した際のsignature検証

弊社、社内のコミュニケーションツールはSlackなんですが、税理士さん＆社労士さんとのやり取りにはChatworkを使っています。
会社共通用のGmailの受信をSlackに通知するようにしたように、Chatworkも一元化できないかなー、と思い調べたら、無料プランでもwebhookを設定できる様子。太っ腹。
サーバー側として今回はGASを使うことにしました。

さて、Chatworkではセキュリティ上、webhookの利用時には署名の検証を推奨しています。
確かにこれがないと全然悪用ができちゃうので仕方がない。

ヘッダーとリクエストパラメーター（非・リクエストボディ）に署名(バイト配列)をBASE64でエンコードした文字列がくっついているので、こちらを検証します。

Chatworkでwebhookを作成するとトークンというBASE64でエンコードされた文字列が発行されるので、
こちらを利用します。


```javascript
function doPost(e) {
  // 別途保存しておいたトークンをbyte[]に
  const privateKey = Utilities.base64Decode(PropertiesService.getScriptProperties().getProperty("token"));
  // リクエストボディ自体をbyte[]に
  const data = Utilities.newBlob(e.postData.contents).getBytes();
  // HMAC-sha256で署名(byte[])を作成
  const x = Utilities.computeHmacSignature(Utilities.MacAlgorithm.HMAC_SHA_256, data, privateKey);
  // 署名(byte[])をbase64エンコードした文字列とくっついてきた署名文字列を検証
  const verifySig = Utilities.base64Encode(x) == e.parameter['chatwork_webhook_signature'];  
  if (!verifySig) {
    // 検証エラー
  }
}
```
【React】useImperativeHandleの使い方

# `useImperativeHandle`とは

親コンポーネントに対して子コンポーネントの特定のインスタンス値やメソッドを公開するために使用されます。これにより、親コンポーネントは子コンポーネントの内部状態に直接アクセスすることなく、必要な機能だけを利用することができます。

## 使用方法

```jsx
useImperativeHandle(ref, createHandle, [dependencies])
```

- `ref`: 親コンポーネントから渡された`ref`オブジェクト
- `createHandle`: 公開するハンドル（オブジェクト）を返す関数
- `[dependencies]`: ハンドルの再生成を制御する依存関係の配列

### カスタムメソッドを公開する

以下の例では、`MyInput`コンポーネントが`focus`と`scrollIntoView`のメソッドを親コンポーネントに公開します。

```jsx:MyInput.jsx
import { useRef, useImperativeHandle } from 'react';

function MyInput(props, ref) {
  const inputRef = useRef(null);

  useImperativeHandle(ref, () => ({
    focus() {
      inputRef.current.focus();
    },
    scrollIntoView() {
      inputRef.current.scrollIntoView();
    },
  }), []);

  return <input ref={inputRef} />;
}

export default React.forwardRef(MyInput);
```

- `useRef`を使って`input`要素への参照を保持します
- `useImperativeHandle`を使用して、親コンポーネントに公開するメソッドを定義します。この例では、`focus`と`scrollIntoView`の2つのメソッドを公開しています
- `React.forwardRef`を使用して、親から渡された`ref`を転送します

```jsx:Form.jsx
import { useRef } from 'react';
import MyInput from './MyInput.js';

export default function Form() {
  const ref = useRef(null);

  function handleClick() {
    ref.current.focus();
    // 以下の操作は許可されていないため動作しない:
    // ref.current.style.opacity = 0.5;
  }

  return (
    <form>
      <MyInput ref={ref} />
      <button type="button" onClick={handleClick}>
        編集
      </button>
    </form>
  );
}
```

- `useRef`を使って`MyInput`コンポーネントへの参照を作成します
- ボタンがクリックされると、`ref.current.focus()`を呼び出して、`MyInput`内の`input`要素にフォーカスを当てます
- 他のプロパティやメソッドは公開されていないため、直接アクセスすることはできません

なお、公開するメソッドは、DOM メソッドと正確に一致する必要はありません。自作のメソッドを公開することもできます。
QA が普段の業務の中で Google Apps Script を使用している事例集

本記事は「[MIXI DEVELOPERS Advent Calendar 2024](https://qiita.com/advent-calendar/2024/mixi)」の22日目の記事です。

## はじめに
普段、業務をする中で Google Apps Script (GAS)を使用し、便利ツールのひとつとして業務の効率化を行なっているので、僕のチーム内の事例を紹介します。ツールを作ってくれた他のメンバーにも感謝！以下の事例は QA っぽいものもあれば、職種問わず集団でお仕事をされている人なら使いそうなものも混ざっていそうですね。

お読みいただいている皆様が
+ 便利そうだから取り入れてみよう
+ QA ってこんなことしてるんだ、こんなこと効率化したいんだ
+ 具体的にどう書いているのだろう
+ いや、これは実はもっと良い実現方法がある

といったことを感じていただけるとありがたいなと思います。ご感想お待ちしております！

## Let's 列挙！
##### ■QA タスクのアサインを自動で選出するとともにテストケースが作成され、Slack に通知されるツール

+ 背景
     + 毎週いくつも依頼があり、一時的にひとりが複数持つような定常的な QA タスクを毎回誰にアサインするか迷う時間をなくしたい
  + 可能であれば、その QA タスクの所持数の少ない人からアサインされるようにしたい
  + ついでに、テストケースに担当者名や内容が記載された状態でその人に Slack 通知が飛ぶようにしたい
+ やったこと
    + スプレッドシートでタスク管理表を用意し、メンバーの所持数一覧がわかる箇所を用意する
    + 所持数一覧には名前の隣に Slack のメンバー ID も記載しておく
    + GAS で以下のスクリプトを作成し、新しいタスクを管理表に追加した後、走らせる
        + メンバーの所持数一覧を取得し、数の少ない人からランダムで選出する
        + 新しいタスクの担当者欄に選出されたメンバーの名前が貼られる
            + 所持数一覧は名前を COUNTIF しているのでこの時点で所持数は +1 される
        + テストケースのテンプレートがコピーされ、担当者名とタスクの内容が貼られる
        + Slack の api を使ってタスクの概要、テストケースのリンクをメンション付きで投稿する
+ その結果
    + 所持数を気にしながら誰にアサインするのか迷うことがなくなった
    + メンバーは Slack 通知でアサインされたことがすぐに気づけるようになった
#### ■デバッグ api の連携ツール

+ 背景
    + サーバーチームが QA 時に便利なデバッグツールを用意してくれている
    + QA 時、スプレッドシートを開きながらその api を叩きたいと思った
+ やったこと
    + GAS で以下のスクリプトを作成
        + スプレッドシートの特定の値を取得して、その値を header や request body に載せてデバッグ api を叩く
        + api のレスポンスをスプレッドシートに貼り付ける
+ その結果
    + 例えば以下のようなことを実行
        + ユーザー名からユーザー ID を取得するようなものをまず叩いて ID を取得した上で、そのまま別のデバッグ api を叩く
        + 複数のユーザー名がスプレッドシート上にあり、そのユーザー全てに対して同じデバッグ api を使った何かを実行する
        + マスターデータのチェックにおいて、スプレッドシート上に貼り付けたデータの値を用いてデバッグ api を叩く
#### ■Slack 上で行なった不具合報告を「不具合一覧」として分析用のスプレッドシートに自動でまとまるツール

+ 背景
    + シンプルかつ修正もすぐにできるような QA において、フィードバックの早さをメリットとして slack で不具合報告をしている
    + QA の依頼が来た投稿に対し、スレッドで不具合を報告している
    + 報告した内容を不具合一覧シートにまとめ、不具合分析や改善に繋げたい
+ やったこと
    + 不具合報告の投稿に特定のリアクションをつけるようにチーム内でルールを設ける
    + GAS で以下のスクリプトを作成
        + 翌日、slack の api を用いて前日の投稿を取得し、そのうち特定のリアクションが押されているものを抽出する
        + 該当の投稿の内容、投稿した人、そのスレッドの親投稿の内容(どの依頼に関する報告なのかもわかるように)を取得し、「不具合一覧」のスプレッドシートに貼り付ける
+ その結果
    + 報告者はリアクションをつけるだけで自動でリスト化されていき、後からみんなで振り返ることができる

#### ■その他
+ 定例ミーティングの議事録(Google ドキュメント)自動作成と当日の Slack リマインド
+ スプレッドシートにまとまっているタスク一覧のうち、当日が締切のタスクを Slack リマインド
+ 特定の件名のメールが届いたら Slack リマインド
+ スプレッドシートに貼り付けたデータと、期待値が書かれている別のファイルを比較し自動チェック

## まとめ
テスト管理ツールやバグ管理システムなど、QA 向けのツールを使えば上に書いたようなものは不要になることも多いですが、ツールを使わずに済んだり、より柔軟にカスタマイズできるスプレッドシートを使ったりする場合に GAS はとても便利なものになります。僕個人としては業務中 Slack を見る頻度が高いため、業務の記録や通知が Slack にまとまるのがとても助かっています。GAS で Slack 通知したがりかもしれません。笑

以上、何かの参考になれば幸いです。
【Java備忘メモ】Tomcatのバージョンとサーブレットのインポート

Tomcat9以前で実行→javax.servlet
Tomcat10以降で実行→jakarta.servlet

私のHerokuの実行環境はTomcat9だったので、jakarta.servletで書いていたプログラムが動かずしばらくハマってしまいました。。。
教える側と教わる側の心構え

# はじめに

今年は転職活動を経て転機を迎えました。
教える側と教わる側を経験しましたので、個人的な所感をかんたんにまとめてみました。
加えて、意識して良かったこと・良くなかったこともまとめてみました。

# 教える側
- 相手が何をしたいのか、そして前提情報を抑えよう
→とりあえずパッと思いついた回答をしても、後から前提情報を知って「その状況だと実は...」みたいな後戻りパターンもあるので...

<br />

- 相手が本当に理解しているか、確認しよう
→説明を聞いていると分かったようなつもりになりがちです。教えたあと、その後の行動について確認しよう
<br />

- 高圧的（感情的）にならないようにしよう
メリットがありません。むしろ相手や周囲の人に対してデメリットです


# 教わる側

- 相手のスケジュールは事前に確認しよう
→何も配慮せず忙しいときに「お時間ありますか」と聞くのは避け、クッション言葉を使い相手に配慮した上で相談しよう
「緊急度が高いのですが」「お忙しいと思いますが」「今取り込み中でしょうか」「この時間帯でお時間いただくことは可能でしょうか」

<br />

- 自分で考える時間を取り過ぎないようにしよう
→そもそも前提が間違っていたり、裏技があるパターンもあるので、自分で試せそうなことを試しても分からなかったら聞いてみよう

<br />

- 質問前に口に出して自分に説明してみよう
→言葉にすることで頭の中が整理され、実は見落としている箇所を発見できたりします
また、質問時に簡潔に伝える事前準備にもなります

<br />

- 質問する際は自分の考えを持とう
→似たような状況に遭遇した際また聞くことになります
また、「これはこの人に聞いた方がいいかも」と言われた場合、ただの伝書鳩になります

<br />

- 教えてもらえるだけで有り難い精神
→必ず感謝を伝えよう。相手は自分のために時間を割いてくれています。



# おわりに
教える・教わるのはいくつになっても経験することだと思いますので、お互いが気持ちよく働けるように配慮できるに越したことはないと思います。
ステータスコードまとめ

## はじめに
12月17日に行われた小テストの結果があまり良くなかったので復習も兼ねて理解が不足していた部分をまとめて残そうと思います。(特にステータスコードがボロボロだった…)

## ステータスコードとは
正式には**HTTPステータスコード**と言うらしい。
「HTTPにおいてWebサーバーからのレスポンスの意味を表現する3桁の数字からなるコード」のこと。(Wikipediaより)
HTTPのレスポンスの先頭行につけられている。

## ステータスコードの分類
ステータスコードの分類は以下の通り
<dl>
  <dt>100番台　情報レスポンス</dt>
  <dd> 一般的にはほとんど見かけない。 </dd>
  <dd>　</dd>
  <dt>200番台　成功</dt>
  <dd> クライアントからリクエストした処理が成功したことを表している。</dd>
  <dd>　</dd>
  <dt>300番台　リダイレクト</dt>
  <dd> リダイレクトが発生した時に表示される。 </dd>
  <dd> リダイレクト…Webサイトやホームページに訪れたユーザーを別のURLに自動で転送する設定のこと。例えば、Webサイトを新しくして新しいURLになった時、リダイレクトをしないと古いURLに飛ばされてしまう。 </dd>
  <dd>　</dd>
  <dt>400番台　クライアント側のエラー</dt>
  <dd>クライアント側から送られてきたリクエストが理解できなかったり、理解できたけど実行は許可されていない時に表示される。</dd>
  <dd>　</dd>
  <dt> 500番台　サーバー側に問題がある </dt>
  <dd>　サーバー側で何かしらのエラーが発生した時に表示される。　</dd>
</dl>

## 主に見かけるステータスコード
※100番台は上記の通り一般的には見ることが少ないため割愛。
| ステータスコード |  名前  |  解説  |
|:-----------|------------|------------:|
|200番台|
|200|OK|リクエストは成功したという意味。すごくよく見る。|
|201|Created|リクエストした結果、サーバー側でデータ作成が行われたと言う意味。リクエストメソッドとしては**POST**(データの更新、登録)が使われた。|
|202|Accepted|リクエストは受け付けたけど、まだ完了していないよという意味。処理は非同期で行われている。|
|204|No Content|レスポンスが空の時に返す。利用例として、DELETEメソッドを使ってデータを削除した時に返すのがある。また、PATCHやPUTでデータの更新をした時も204を返すのがいいのではないかという意見もある。|
|300番台|
|301|Moved Permanently|リソースは恒久的に移動したことを表す。新しいURLにアクセスし直す必要がある。|
|302|Found|リソースが一時的に移動していることを表す。|
|303|See Other|クライアントからのリクエストに対するレスポンスが、別のURLで利用可能であることを表す。POSTリクエストの後にGETリクエストを用いて新しいページを取得させるために使用される。|
|304|Not Modified|要求されたコンテンツは前回から更新されていないことを表す。クライアント側がきちんとそれまでのデータのキャッシュを行い、キャッシュの情報を返してくれた時にだけ返ってくる。|
|400番台|
|400|Bad Request|400番台のエラーでは表すことができないエラーのこと。|
|401|Authentication|認証のエラー。「誰だお前…」という感じの意味。|
|403|Authorization|認可のエラー。「お前のことはわかったけど、その操作の権限はないわ」と言う感じの意味。|
|404|Not Found|データは存在していないという意味を表す。存在しないエンドポイントにアクセスしようとしたり、存在しないユーザーの情報を取得しようとしたりすると返ってくる。|
|405|Method Not Allowed|エンドポイントは存在しているが、メソッドが許可されていないことを表す。GETでしかアクセスできないところにPOSTでアクセスしようとした時に返ってくる。|
|406|Not Acceptable|クライアントが指定してきたデータ形式にAPIが対応していない場合を表す。|
|408|Request Timeout|リクエストをクライアントがサーバに送るのに時間がかかり過ぎてサーバ側でタイムアウトを起こしたことを表す。|
|409|Conflict|リソース競合が起きたことを表す。すでに同じIDが存在した時などに返ってくる。|
|410|Gone|かつては存在したけれど今は存在していない時に返ってくる。このステータスコードを返すにはデータを削除したという情報を保持する必要がある。|
|413|Request Entity Too Large|リクエストボディが大きすぎることを表す。|
|414|Request-URL Too Long|リクエストしたURLが長すぎることを表す。|
|415|Unsupported Media Type|リクエストボディのデータ形式をサーバが対応していないことを表す。|
|429|Too Many Requests|アクセス回数が許容範囲の限界を超えたことを表す。アクセス回数の制限のことはレートリミットという。|
|500番台|
|500|Internal Sever Error|サーバ側のコードにバグがあることを表す。|
|503|Sever Unavailable|サーバが一時的に利用できない状態になっていることを表す。メンテナンスのためにサービスを止めている時に返ってくる。|

## まとめ
主に使用されると言われてもだいぶ量が多い…
404とかはよく見かけますがそれ以外はほぼ初めて見るものばかりでした。完璧に覚える必要はないと思いますが、記憶を探り出すきっかけとして知識をつけておくことは重要だと感じました。
【自習】AWS IAM

PMする上で必要になってきたのでおさらい

https://docs.aws.amazon.com/singlesignon/?icmpid=docs_homepage_security

## **AWS IAMとは？**
**AWSリソースへのアクセスを安全に管理するためのサービス**。要するに権限設定して制限をかけるやつ。

## **IAMの特徴**

1. **ユーザーとアクセス管理**
   - 個別のユーザーやグループにアクセス権限を付与。
   - 例: 開発者にEC2の管理権限、マーケティング担当者にS3の読み取り権限。

2. **詳細な権限制御**
   - 「最小権限の原則」を実現するため、必要最低限の権限を付与可能。
   - JSON形式で細かいポリシーを設定。

3. **多要素認証（MFA）**
   - パスワードに加えてワンタイムパスコードなどを要求し、セキュリティを強化。

4. **一時的な権限（STS: Security Token Service）**
   - 特定のタスクに必要な権限を一時的に発行。

5. **監査とログ**
   - IAMはCloudTrailと連携して、アクセスログや操作履歴を記録。

## **IAMの主な要素**

1. **IAMユーザー**
   - AWSリソースへのアクセスが必要な個人（またはアプリケーション）。
   - アクセス方法:
     - **コンソールアクセス**: AWS管理コンソールにログイン。
     - **プログラムアクセス**: APIやCLIを使用。

2. **IAMグループ**
   - 共通の権限を共有するユーザーの集合。
   - 例: 「開発者」グループにEC2管理権限、「運用チーム」グループにCloudWatchアクセス権限。

3. **IAMポリシー**
   - ユーザー、グループ、ロールに割り当てる権限を定義するJSON形式のドキュメント。
   - 例: S3の特定バケットに読み取り専用権限を付与するポリシー。

4. **IAMロール**
   - AWSリソースに一時的な権限を付与するためのもの。
   - 例: EC2インスタンスにS3へのアクセス権限を与えるロール。

## **IAMの主なユースケース**

#### **1. EC2インスタンスからS3にアクセス**
- **シナリオ**: アプリケーションがEC2で動作しており、S3にデータを保存する必要がある。
- **解決方法**:
  - IAMロールを作成し、EC2インスタンスに付与。
  - ポリシーでS3へのアクセス権限を設定。

#### **2. 最小権限のアクセス制御**
- **シナリオ**: 開発チームにS3の読み取り権限を付与するが、書き込みは許可しない。
- **解決方法**:
  - 「S3: GetObject」アクションのみ許可するIAMポリシーを作成。
  - 開発者グループに割り当て。

#### **3. MFA（多要素認証）の設定**
- **シナリオ**: 管理者アカウントのセキュリティを強化したい。
- **解決方法**:
  - IAMユーザーにMFAを有効化。
  - ログイン時にパスワード＋ワンタイムパスコードを要求。

#### **4. サードパーティツールのアクセス管理**
- **シナリオ**: CI/CDツール（例: GitHub Actions）がAWSリソースにアクセスする必要がある。
- **解決方法**:
  - IAMロールを作成し、一時的なトークンを発行。
  - 必要なサービス（例: CodeDeploy）への権限を設定。

## **IAMポリシーの例**

#### **S3バケットの読み取り専用ポリシー**
```json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::example-bucket/*"
        }
    ]
}
```

#### **特定のIPアドレスからのみアクセスを許可するポリシー**
```json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "NotIpAddress": {
                    "aws:SourceIp": "192.0.2.0/24"
                }
            }
        }
    ]
}
```

## **IAMのメリットとデメリット**

#### **メリット**
1. **セキュリティの向上**
   - 最小権限の原則で、過剰なアクセス権限を防止。
   - MFAで認証プロセスを強化。

2. **柔軟なアクセス制御**
   - JSONポリシーで細かい制御が可能。
   - 一時的なトークンで不要な長期権限を回避。

3. **監査とコンプライアンス**
   - CloudTrailで全ての操作をログに記録し、監査対応が容易。

#### **デメリット**
1. **設定の複雑さ**
   - 初心者にはポリシーの記述や権限管理が難しい場合がある。

2. **誤った設定のリスク**
   - 不必要に広い権限を付与すると、セキュリティリスクが増大。

## **IAMのベストプラクティス**

1. **最小権限の原則**
   - 必要最低限の権限のみ付与する。

2. **MFAを有効化**
   - 特に管理者ユーザーにはMFAを必須にする。

3. **ロールを活用**
   - アプリケーションやサービスにはIAMユーザーではなくロールを使用。

4. **ポリシーを定期的に見直す**
   - 不要な権限や古いポリシーを削除。

5. **CloudTrailを活用**
   - すべての操作を記録し、不正アクセスやミスを追跡可能にする。

## 感想
WordPressの案件でセキュリティ心配なものが多いので、とても良い勉強になった。