OmniAICreator/Qiita-1.07M huggingface dataset:
FinOpsフレームワーク解説 〜第０回〜

## 記事の目的

FinOpsコミュニティ所属メンバーとして、フレームワークをなるべくわかりやすく解説進めていこうと思います。
実は最近少しずつ知名度が上がっているFinOpsですが、コミュニティとしては後発なところもあり、日本語ドキュメントがまだまだ少ない…

一方でこういった考え方は、海外のクラウドサービスを使うことが主流になっている日本企業だからこそ必要なものだと考えておりますので、ぜひこういった情報発信が皆様のお力になればと思っております。

なるべくフレームワークに準拠した形でそれを体形立てて整理していきます。（範囲が広いので美貌も兼ねて）


![スクリーンショット 2025-05-02 11.18.43.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3895754/1cd9d183-4c66-4df1-bc1b-f6e6af1e03e8.png)


## 今後書いていく目次
（あとで目次にリンクつけます）
第一回：FinOpsの概念、なぜ注目されているのか
第二回：フレームワークの全体像
第三回：FinOps構成要素① 行動規範（Principles）
第四回：FinOps構成要素② ペルソナ（Personas）
第五回：FinOps構成要素③ 実践サイクル（Phases）
第六回：FinOps構成要素④ 成熟度モデル（Maturity）
第七回：FinOps構成要素⑤ 活動領域（Domains/Capabilities）
第八回：FinOps実践のステップとポイント
第九回：まとめと今後の展望
おまけ：資格試験の取得とコミュニティ参加について


## 内容をブレイクダウン
第一回：FinOpsの概念、なぜ注目されているのか
　　・FinOpsとは何か、なぜ今注目されているのか
　　・クラウドコスト最適化とビジネス価値最大化の重要性
第二回：フレームワークの全体像
　　・フレームワークの目的と構成要素の概要
　　・FinOps Foundationによる標準モデルの紹介
第三回：FinOps構成要素① 行動規範（Principles）
　　・FinOpsにおける基本的な考え方や価値観（例：可視化、説明責任、継続的最適化、コラボレーションの重要性）
第四回：FinOps構成要素② ペルソナ（Personas）
　　・FinOpsに関わる主要なステークホルダーやチーム（例：エンジニア、財務、経営層など）
第五回：FinOps構成要素③ 実践サイクル（Phases）
　　・「インフォーム（可視化）」「オプティマイズ（最適化）」「オペレート（運用）」の3フェーズとその流れ
第六回：FinOps構成要素④ 成熟度モデル（Maturity）
　　・組織のFinOps実践レベルを「Crawl（初期）」「Walk（中級）」「Run（高度）」で評価し、段階的に成長させていくアプローチ
第七回：FinOps構成要素⑤ 活動領域（Domains）
　　・コスト可視化・配分、最適化、ガバナンスなど、FinOpsが対象とする具体的な領域
第八回：FinOps構成要素⑥ 組織的能力（Capabilities）
　　・各領域で求められる具体的なスキルや実践策（例：タグ付け、コスト分析、予算策定、ツール活用など）
第九回：FinOps実践のステップとポイント
　　・実際に取り組む際の流れや注意点
　　・組織文化・教育・ツール選定の重要性
第十回：まとめと今後の展望
　　・FinOps導入の効果と今後のトレンド
　　・読者へのアクション提案
おまけ：資格試験の取得とコミュニティ参加について


## 意気込み
頑張って更新するぞ！！
2025年5月 AIOps 定点観測

# 概要
AIOps の動向や学習のため、Google で AIOps を検索した結果を記録している記事です。

# 2025年5月2日の検索結果 (広告(スポンサー))

![スクリーンショット 2025-05-02 110518.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2345504/d0d9a425-a453-44cb-b8c7-6afcfcc0e8f4.png)

* Dynatrace
* IBM
* Dell

今月は Dynatrace が TOP で、IBM と Dell が続いています。

先月の結果はこちら --> [2025年4月 AIOps 定点観測](https://qiita.com/mkodera/items/f9fb479450169de34dfb)



# 2025年5月2日の検索結果 (広告以外)

![スクリーンショット 2025-05-02 110809.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2345504/08a7c455-f16f-4e23-9a8d-b6ec20db8b17.png)

* HPE
* AWS
* Palo Alto Networks
* 日立ソリューションズ・クリエイト
* Splunk

今月は HPE が TOP で、AWS と Palo Alto Networks が続いています。

先月の結果はこちら --> [2025年4月 AIOps 定点観測](https://qiita.com/mkodera/items/f9fb479450169de34dfb)
【Power Apps】ドロップダウン＆コンボボックスの色変更まとめ（FillやColorの扱いについて）①

# はじめに
Power Apps でドロップダウンやコンボボックスを使う時、
見た目を整えたいけどどのプロパティを触れば色が変更するかなどが
初見では分かりづらいと思います:sweat_drops:

本記事では以下のような色・スタイルのプロパティについて
わかりやすくまとめていきたいと思います！

+ Fill（背景色）
+ Color（テキスト色）
+ HoverFill（ホバー時の背景色）などなど...

## 色やスタイル関連のプロパティ一覧（ドロップダウン/コンボボックス共通）

|| プロパティ名 | 意味・用途 | 例 |
|:-:|:-:|:-:|:-:|
|:one:| Fill  |  背景色 |  RGBA(255, 255, 255, 1) , Color.White（白） |
|:two:| Color | テキストの色  |  RGBA(0,0,0,1) , Color.Black （黒） |
|:three:| HoverColor  | マウスホバー時のテキスト色  |  Color.White |
|:four:| HoverFill | マウスホバー時の背景色 | Color.Blue |
|:five:| PressedColor  | クリック時のテキスト色  | Color.White  |
|:six:| PressedFill  | クリック時の背景色  | Color.DarkBlue  |
|:seven:| BorderColor  | 境界線の色  | Color.Gray  |
|:eight:| BorderThickness | 境界線の太さ  | 1（ピクセル）  |
|:nine:| DisabledColor  | 無効化時のテキスト色  | Color.LightGray  |
|:one::zero:| DisabledFill | 無効化時の背景色 | Color.Gray |

## 実際に設定してみる（画像付き）
では、実際に設定してみましょう。
こちらはドロップダウンとコンボボックスのデフォルトの設定状態です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3719434/a337ecbc-6af0-4f2a-a0d7-8c5791b763eb.png)

:one: **Fill　背景色**
Fill は他のコントロールでも使用される一般的なプロパティです。
特に操作がされていない時の基本の背景色です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3719434/531d35dc-4ae5-42fe-8c21-320c623dbcb8.png)

ドロップダウンの Fill を変更してみました。
背景色が LightPink に変更されました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3719434/0974bec5-9a87-403d-8957-6bbdf48f3d10.png)


:two: **Color　テキスト色**
こちらも一般的なテキストの色を設定する箇所になります。

`Color` プロパティを `Color.White` に変更してみました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3719434/ac2fe836-fe32-425a-bad9-ba5bc1c2e0df.png)

:three: **HoverFill　マウスホバー時の背景色**
HoverFill はコントロールにマウスカーソルを合わせた時に変更される背景色のことです。
今マウスカーソルがどのコントロールを選択しようとしているかが視覚的に分かりやすくなります。

`HoverFill` プロパティを `Color.White` に変更してみました。
このような変化が起こります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3719434/ae945962-b72c-437d-9ecd-3e85eb4f21f9.png)

:four: **HoverColor　マウスホバー時のテキスト色**
HoverFill と同様にマウスカーソルを合わせた時のテキスト色のことです。

`HoverColor` プロパティを `Color.Red` に変更してみました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3719434/e3b683d3-047d-461b-b368-d2090f339cd7.png)

:five: **PressedColor クリック時のテキスト色**
PressedColor はコントロールをクリックしている状態の時のテキスト色になります。
押したままの色になるので、離せば色は元に戻ります。

`PressedColor` プロパティを `Color.Black` に変更してみました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3719434/2f7937f4-03f4-4679-8ddd-21974d1f8797.png)

## 後編につづく
:one:**～**:five:までの Fill や Color について説明しました。
残りの:six: **～** :one::zero:については後編の記事に記載していますので
そちらも併せてごらんください！

https://qiita.com/Sanwa_Paint/items/b59447ad54c6c3066c96
Ubuntu 25.04 Plucky Puffinの紹介と仮想環境への対応

##  Ubuntu 25.04 Plucky Puffinに移行したい！
最近、24.10 の環境で Thunar の gvfs-smbfs プラグインがコケてしまう現象になやんでいました。　もう我慢しきれなくなったので、25.04に行きます。

## 25.04 紹介
Ubuntu 25.04 "Plucky Puffin"は、Canonicalによって2025年4月にリリースされた最新のUbuntuディストリビューションです。この新バージョンでは、パフォーマンスの向上、最新のLinuxカーネルの採用、デスクトップ環境の改善など、多くの新機能と改良が施されています。

主な特徴：
- Linux カーネル 6.8を採用し、最新のハードウェアサポートと安定性の向上
- GNOME 46デスクトップ環境による洗練されたユーザーエクスペリエンス
- システム起動時間の短縮とリソース使用効率の改善
- セキュリティ機能の強化とプライバシー保護の向上
- Snapパッケージマネージャーの改良と新機能

##  Ubuntu 24.10からの更新

Ubuntu 24.10から25.04への更新は比較的簡単です。以下の手順に従って安全にアップグレードを行うことができます。

### 準備段階

まず、現在のシステムが最新の状態であることを確認し、不要なパッケージを削除します：

```bash
sudo apt update
sudo apt upgrade
sudo apt autoremove --purge
sudo apt clean
```

### 更新(コマンドライン）

準備が整ったら、以下のコマンドでリリースアップグレードを開始します：

```bash
sudo do-release-upgrade -d
```

このコマンドを実行すると、アップグレードプロセスが開始されます。画面の指示に従って進めてください。アップグレード中は、設定ファイルの変更に関する質問が表示される場合があります。プロセスが完了すると、システムの再起動を求められます。


## 更新後あるある・・・VSCodeが動かない・・・
* 基本的にこれらライセンス条件が異なるサードパーティ製品は入れ替えが必要です
* 最新バージョンに差し替えるだけで動きましたので特に書くことはありません。

## VirtualBox 7.1が起動しない問題
OS更新したことで、samba共有が開けなくなっていた問題は解決したのですが、仕事でよく使う機能でデスクトップ環境の仮想化アプライアンスが動かないと困ることが多いです。 Ubuntu 25.04へのアップグレード後、VirtualBox 7.1に互換性の問題が発生しました・・・起動時に次のようなエラーが表示されます・・・

![virtualbox-2025-05-02_09-45-21.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/91470/03e8c37d-98e9-43b4-af6a-df5c9f6dfbdd.png)


この問題の原因は、Ubuntu 25.04の新しいカーネルとVirtualBoxのカーネルモジュールの互換性にあります。VirtualBoxの開発チームは対応を進めているはず・・・　ですが、それを待ってはいられない事情があります。

## VMware Workstationへの移行

* すぐに使いたい、待ちきれないので、VMware Workstation Pro を使います。
* VirtualBox7.1でのWindowsゲストは時々応答が停止することがあり不安でした。
* 作業中の Ubuntu環境に既にVMware環境が存在し、動作しています。
* 別件でWindows上に Vmware Workstation Pro を入れているがVirtualBoxでは出来ないGPUデバイス扱いに優れた性能発揮していることを確認できています。
 
基本的に、VMware WorkstationはUbuntu 25.04との互換性が確認されています。仮想化環境として高い安定性も持ち合わせています。

### VMware Workstationのインストール

1. VMware公式サイトから最新版のVMware Workstation Proをダウンロード
2. インストールファイルに実行権限を付与：
   ```bash
   chmod +x VMware-Workstation-Full-*.bundle
   ```
3. インストーラーを実行：
   ```bash
   sudo ./VMware-Workstation-Full-*.bundle
   ```

### VirtualBoxから仮想マシンを移行する方法

#### OVAエクスポート/インポート方式
1. VirtualBoxの仮想マシンをOVAフォーマットでエクスポート
2. VMware Workstationで「ファイル」→「開く」からOVAファイルをインポート
3. 変換ウィザードの指示に従って設定を調整
4. VMware Toolsをインストールして最適なパフォーマンスを確保

#### ディスクイメージ変換方式（CLI）
VDIディスクイメージをVMDK形式に直接変換することも可能です：

```bash
qemu-img convert -f vdi -O vmdk Windows11.vdi Windows11.vmdk
```

このコマンドを使用するには、まず必要なパッケージをインストールします：

```bash
sudo apt install qemu-utils
```

変換後、VMware Workstationで新しい仮想マシンを作成し、既存のディスク（変換したVMDKファイル）を選択することで移行が完了します。

## 更新してみて・・

Ubuntu 25.04 Plucky Puffinは多くの改良と新機能を提供する素晴らしいリリースですが、仮想化環境との互換性には注意が必要です。VirtualBoxの問題が解決されるまでは、VMware Workstationなどの代替ソリューションを検討することで、引き続き仮想環境を活用することができます。
Windows Serverで時刻同期サーバーを変更するのにつまずいたのでメモ

時刻同期サーバーの変更がなかなかできなかったのでうまくいった方法をメモします。

FSMO機能を有するドメインコントローラーを落とした後、もう1台のドメインコントローラーの時刻をntpサーバーと同期させることにより、ドメインの時刻が正常化されるのか検証した際につまづきました。

# 構成
- ntpサーバー：WIndows Server2016で桜時計
- ドメインコントローラー：Windows Server2016 2台
- ドメインユーザー：Windows10 1台

# 結果
以下コマンドを実行するとうまくいきました。

```
w32tm /config /manualpeerlist:<NTP_server_IP_Address>,0x8 /syncfromflags:manual /reliable:yes /update
net stop w32time
net start w32time
w32tm /resync
```
resyncがキモのようです。

microsoftドキュメント
https://learn.microsoft.com/ja-jp/troubleshoot/windows-server/identity/time-synchronization-not-succeed-non-ntp
📘 サービスオブジェクトによるRuby on Railsのリファクタリングチュートリアル

![Dev Refactor.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4072406/e57b2046-1de4-4bed-8e1a-98dd35434492.png)


このチュートリアルでは、**ClinicSync** プロジェクトで行った2つのリファクタリングについて解説します。このアプリケーションは、私のRuby on Rails MBAの一環として開発された医療クリニック管理システムです。目的は、**サービスオブジェクト（Service Objects）** を活用して、コードの可読性、保守性、拡張性を向上させることです。

## サービスオブジェクトとは？

**サービスオブジェクト** は、モデルやコントローラー、ビューに属さない **ビジネスロジックを整理するためのシンプルなクラス** です。
これは、**単一責任の原則（Single Responsibility Principle, SRP）** を実践する方法の1つであり、システムの各部分に明確な役割を与えることができます。

---

## サービスオブジェクトを使うべきタイミング

次のような場合にサービスオブジェクトの導入を検討しましょう：

- ロジックが複雑でコントローラーに収まりきらないとき
- 機能が特定のモデルに自然に属さないとき
- 同じロジックを複数箇所で再利用したいとき
- よりクリーンでテストしやすいコードを目指したいとき

---

## サービスオブジェクトの基本構造

```ruby
class ExampleService
  def self.call(params)
    new(params).call
  end

  def initialize(params)
    @params = params
  end

  def call
    # メインのロジックをここに記述
  end
end
```

---

## リファクタリング①：`AuthorizeUser` サービス

### 目的：
コントローラーに繰り返し書かれていたユーザータイプの判定処理を外部化する。

### リファクタリング前：
```ruby
def require_admin
  unless user_signed_in? && current_user.is_a?(Admin)
    redirect_to root_path, alert: "You are not authorized to access this page."
  end
end
```

### リファクタリング後：
```ruby
def require_admin
  unless user_signed_in? && AuthorizeUser.call(current_user, Admin)
    redirect_to root_path, alert: "You are not authorized to access this page."
  end
end
```

### 作成されたサービス：
```ruby
class AuthorizeUser
  def self.call(user, user_type)
    user.is_a?(user_type)
  end
end
```

### メリット：
- ロジックの重複排除（DRY）
- 保守性の向上
- クリーンで再利用可能なコード

---

## リファクタリング②：`AuthenticateUser` サービス

### 目的：
ユーザー認証処理を `SessionsController` から分離する。

### リファクタリング前：
```ruby
if (user = User.authenticate_by(params.permit(:email_address, :password)))
  start_new_session_for user
  redirect_to home_path_for(user), notice: "Logged in successfully."
else
  redirect_to new_session_path, alert: "Try another email address or password."
end
```

### リファクタリング後：
```ruby
user = AuthenticateUser.call(params[:email_address], params[:password])

if user
  start_new_session_for user
  redirect_to home_path_for(user), notice: "Logged in successfully."
else
  redirect_to new_session_path, alert: "Try another email address or password."
end
```

### 作成されたサービス：
```ruby
class AuthenticateUser
  def self.call(email_address, password)
    User.authenticate_by(email_address: email_address, password: password)
  end
end
```

### メリット：
- コントローラーの簡素化
- ソーシャルログインや二要素認証などの拡張が容易
- 責務の明確な分離

---

## まとめ

この2つの小さなサービスオブジェクトにより、プロジェクトは：
- よりクリーンに
- テストしやすく
- 拡張しやすくなった

サービスオブジェクトは、クリーンコードを実現し、Railsアプリケーションを将来の拡張に備えるための強力な手法です。

---

作成者： [レオナルド・フラゴーゾ]
M5Stack Cardputerを BLE キーボードにしてみる

この記事は、
[M5Stack Cardputer](https://www.switch-science.com/products/10300?srsltid=AfmBOooFbOssB4f7bTXklbxhXg7gQaRZmeFGbq_8VWWvyP_PxU00T2Is)
を、小型のBLEキーボードにしてしまうまでを書いたものです。正しくはV1.1ではなくて初代を使っているのですが、きっと動くんじゃないかと思います。ぜひスマホのキーボードにどうぞ！

お急ぎの方は、最後にplatformio.iniを張っておきますので、そちらをまるっと使ってください。

作ってみたものは、
[M5PuterKey](https://github.com/ji6czd/M5PuterKey)
です。

## 開発環境

* macOS 15.5
* PlatformIO
* Arduino framework

## 依存するライブラリなど

* M5CardPuter
* M5Unified
* ESP32 BLE Keyboard
* NimBLE-Arduino

基本的にはこの４つのライブラリを導入できれば動くはずです。が、そう簡単ではなかったので、順番に解説していきましょう。

## そもそもBlueTooth接続ができない？

一見接続できるのですが、接続が失われると再接続できません。実際にデータをやり取りできていないので、本当に接続できていたのかどうか、ちゃんと検証していません。

調べてみると、どうやらNimBLEというものを使う必要があるとのこと。ということで、NimBLEライブラリを単体で動かしてみました。どうやらちゃんと動くようです。

ところが、キーボードライブラリと同時に使うとコンパイルが通りません。NimBLEライブラリが大幅に変更されているようで、まだこちらに追いついていない模様。

ということで、ライブラリのバージョンを1.4.3に固定します。これであっさりBLEキーボードとしては動くようになりました。


## Cardputerライブラリとの問題

次はCardPuterライブラリを組み込んで、本体のキーが押されたらそれっぽいコードをBLE送信するテストを行います。

一見順調に見えていたのですが、KEY_BACKSPACEを送信するとなぜか`*`が送信されてしまいます。

追ってみると、BLE KeyboardライブラリとCardputerライブラリの中に同じ文字列で違う数値のコードを発見しました。前者はconst uint8_tで後者は#defineです。どちらも定数で宣言されていればコンパイルエラーになって気がついたのでしょうが、#defineで単純に文字列置換されちゃったので気が付きませんでした。

ということで、Cardputerのライブラリ側を修正します。まず、
.pio/libdeps/m5stack-stamps3/M5Cardputer/src/utility/Keyboard_def.h
にある、#defineの定数っぽいものを全部const uint8_tにしちゃいます。これで衝突すればエラーになるはずです。

…、というか確実にエラーになるので、このキー定義を丸ごとm5ネームスペースに放り込んじゃいます。
.pio/libdeps/m5stack-stamps3/M5Cardputer/src/utility/Keyboard.h
を読むと、Keyboard_def.hをインクルードしている場所があります。これを、
``` namespace m5 { ```
の後に移動させます。

当然、これだとKeyboard.cppのコンパイルが通らなくなります。ということで、
.pio/libdeps/m5stack-stamps3/M5Cardputer/src/utility/Keyboard.cpp
に、
``` using namespace m5; ```
を追加します。関数定義が始まる直前に追加する必要があります。

## 注意点

Cardputerライブラリ内のキー定義をプログラム中で参照するときは、
``` m5::KEY_ENTER ```
のように、m5プレフィックスを付けて参照する必要があります。…、というかそうすることで名前の衝突を避けるようにしたのですから。

## サンプルのplatform.ini

ということで、上記の修正をしたものをGitHubに置きました。これを使ってビルドするサンプルを書いておきます。

``` ini
; PlatformIO Project Configuration File
;
;   Build options: build flags, source filter
;   Upload options: custom upload port, speed and extra flags
;   Library options: dependencies, extra library storages
;   Advanced options: extra scripting
;
; Please visit documentation for the other options and examples
; https://docs.platformio.org/page/projectconf.html

[env:m5stack-stamps3]
platform = espressif32
board = m5stack-stamps3
;board_build.f_cpu = 80000000L
framework = arduino
build_flags =
 -DARDUINO_USB_CDC_ON_BOOT=1
 -DUSE_NIMBLE
lib_deps =
	m5stack/M5Unified@^0.2.5
	t-vk/ESP32 BLE Keyboard@^0.3.2
	https://github.com/ji6czd/M5Cardputer
	h2zero/NimBLE-Arduino@^1.4.3
monitor_speed = 115200
```

## 識者の方にお願い

とりあえずこれで目的は達成していて、編集も必要最低限だとは思うのですが、「いやいやこうするべきなんじゃない？」とかありましたらコメントくださるとうれしいです。追ってPRを出そうかと思っています。

Happy Hacking!
CSS基礎　position: absolute / relative / fixedの違いと実務での使い分け

# はじめに

CSSでレイアウトを組むときに欠かせないのが `position` プロパティ。  
中でも `absolute`、`relative`、`fixed` の3つはよく登場しますが、初心者にとっては違いが分かりづらく、混乱しがちです。

この記事では、それぞれの違いや実務での使い分け方、よくあるつまずきポイントを自分用の備忘録としてまとめました。

---

# ①それぞれの違いをざっくり一言で！

| 種類 | 一言で言うと |
|------|--------------|
| `relative` | 元の位置から少しズラす |
| `absolute` | 指定した親要素の左上を起点に配置 |
| `fixed` | 画面（ビューポート）に固定表示される |

---

# ②詳しい違いと動作イメージ

## `relative`（相対配置）

- **自分自身の元の位置を基準に、微調整する**
- 文書の流れは維持される（レイアウトは崩れない）

```css
.box {
  position: relative;
  top: 10px;
  left: 20px;
}
```

**実務での使用例:**
- 疑似要素 ::before / ::afterの基準
- absolute要素の**親要素**に設定(基準点を作る)

## `absolute`(絶対配置)
- **一番近い relative/absolute/fixedの親要素を基準に配置される**
- 文書の流れから外れるため、レイアウトに重なりを作れる

```css
.container {
    position: relative;
}
.button {
    position: absolute;
    top: 10px;
    right: 10px;
}
```

**実務での使用例:**
- カードの右上のバッジ・アイコン配置
- モーダルウィンドウ・ツールチップ
- ホバーで表示されるメニュー

## `fixed`(固定配置)
- **画面(ビューポート)を基準に配置される**
- スクロールしても常に同じ場所に表示
```css
.back-to-top {
    position: fixed;
    botton: 20px;
    right: 20px;
}
```
**実務での使用例:**
- 固定ヘッダーやサイドメニュー
- ページトップに戻るボタン
- 通知やフロートバナーの表示

# ③よくあるつまずきポイント
- absoluteの基準になる要素がrelativeでなければ、**想定外の場所に表示される**
- fixedはモバイルで画面に収まりきらず、**重なりやスクロール問題が出やすい**
- relativeはズレるだけなので、**「レイアウトが壊れた？」と誤解されがち**

# ④まとめ表
![IMG_7870.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2246240/80505648-08b6-46c1-8b82-c7f419c993f7.jpeg)

# ⑤おまけ:実際に試すと分かる!
- Chromeの**デベロッパーツール**でpositionを切り替えて、挙動を見ると理解が深まります。
- 模写コーディングやパーツ制作を通じて「この配置、どれを使えば？」を体験しながら覚えるのが近道!
DB最適化入門：4つのアプローチで処理速度とスケーラビリティを向上


Webサービスの成長とともに、データベース（DB）のパフォーマンスはシステム全体のボトルネックとなることがあります。そこで重要なのが、DBのスケーラビリティと耐障害性を高める**構成技術**の導入です。
本記事では、代表的な4つの手法を比較しながら解説します。

---

## 1. レプリケーション（Replication）

### 複数サーバーに同一データを複製

**概要：**
同じデータベースを複数のサーバーにコピーして保持することで、読み取り性能を向上させたり、障害時の耐障害性を高めたりします。

**用途例：**

* 読み取り処理が多いシステム（例：ECサイトの商品一覧）
* フェイルオーバー対策

**メリット：**

* 読み取りの負荷分散が可能
* 冗長性による信頼性向上

**注意点：**

* 書き込みの整合性確保が必要（マスタースレーブ構成など）

---

## 2. テーブルパーティショニング（Table Partitioning）

### 大きなテーブルを意味的に分割

**概要：**
一つの大規模なテーブルを、日付やカテゴリなどの**データの意味的なまとまり**で分割します。

**用途例：**

* 時系列データ（例：注文履歴、ログデータ）
* 特定の列により自然に区切れるデータ

**メリット：**

* 一部データのみアクセス時の高速化
* メンテナンスしやすくなる

**注意点：**

* パーティションキーの設計が重要
* クエリ最適化が必要

---

## 3. シャーディング（Sharding）

### テーブルを行単位で分割し、複数のDBに分散

**概要：**
一つの大きなテーブルを、**行ごとに**分割して複数のDBに格納します。顧客IDの範囲でDBを分けるなど。

**用途例：**

* 数百万〜数億件のレコードを扱う大規模システム
* 書き込みも読み取りも多いサービス

**メリット：**

* 垂直・水平スケーリングが可能
* 書き込み性能も分散できる

**注意点：**

* アプリケーション側の分散ロジックが必要
* JOINやトランザクションの制限

---

## 4. データベースフェデレーション（DB Federation）

### 異なるDBを統合的に扱う

**概要：**
顧客情報は一つのDB、注文情報は別のDB、のように**異なるスキーマのDB**を連携して一つのDBのように扱うアーキテクチャ。

**用途例：**

* マイクロサービス構成のアプリ
* システム統合時のデータ連携

**メリット：**

* 専用DBごとの設計最適化
* チーム単位の開発分担が可能

**注意点：**

* 統合クエリのパフォーマンス
* 整合性管理が難しくなる

---

## まとめ：目的に応じて使い分けを！

| 手法        | 主な用途      | メリット       | 注意点         |
| --------- | --------- | ---------- | ----------- |
| レプリケーション  | 読み取り高速化   | 冗長性、可用性    | 書き込みの同期管理   |
| パーティショニング | 大テーブルの最適化 | 局所アクセス高速化  | キー設計が重要     |
| シャーディング   | 超大規模DB対応  | 水平スケーリング   | 開発・運用の複雑化   |
| フェデレーション  | 異種DBの統合   | モジュール設計が可能 | 整合性やパフォーマンス |

---

## おわりに

今回紹介した4つの手法を理解し、適切に組み合わせることで、パフォーマンス・スケーラビリティ・信頼性のすべてを実現できます。
DatabricksでPhi-4-mini-reasoningを試す

ローカルLLMは同じ時期にまとめて出すというルールでもあるのか。。。
いろいろ試してみたいものが続々でてきます。

# 導入

Microsoft社から大規模言語モデル(MS社の定義だとSmall Language Modelです)であるPhi-4の新モデル、Phi-4-reasoningシリーズが公開されました。
Phi-4-reasoning、Phi-4-reasoning-plus、Phi-4-mini-reasoningという3つのモデルがリリースされています。これらはReasoningモデルであり、最初に思考をした後に最終回答を返すモデルです。
特に数学的推論に最適化されているようです。

https://azure.microsoft.com/en-us/blog/one-year-of-phi-small-language-models-making-big-leaps-in-ai/

各モデルの特徴は以下のようになります。

- **Phi-4-reasoning:**
    - 140億パラメータの推論特化型オープンウェイトモデル
    - 複雑な推論タスクで大規模モデルに匹敵する性能
    - OpenAI o3-miniからの推論デモを用いた教師付き微調整で訓練
- **Phi-4-reasoning-plus:**
    - Phi-4-reasoningの機能を強化
    - 強化学習によりさらに訓練され、推論時に1.5倍多くのトークンを使用
    - より高い精度を実現
- **Phi-4-mini-reasoning:**
    - より小型の推論モデル
    - 数学的推論に最適化
    - 中学校からPh.D.レベルまでの100万以上の多様な数学問題で訓練

面白そうでしたので、いつものようにDatabricks上で動かしてみようという記事になります。
検証はDatabricks on AWS、ノートブックはGPU(g5.xlarge)の専用モードクラスタ、DBRは16.4 LTS ML(Beta)を利用しました。

# モデルの読み込み～エンドポイントへのデプロイまで

正直、内容は以下とほぼ同じです。(若干、ライブラリのアップデートをしているくらい）
そのため、モデル構築からデプロイまでの処理やコードについては以下記事を参照ください。ここの記事では割愛します。

https://qiita.com/isanakamishiro2/items/1104e65c7ebeb5b30c02

なお、今回は公開された3モデルのうち、Phi-4-mini-reasoningを利用しました。
3BモデルのSLMです。128Kという比較的大きなコンテキスト長をサポートしています。

https://huggingface.co/microsoft/Phi-4-mini-reasoning


# Playgroundから試す

Playgroundから試してみます。

:::note info

ストップトークンが標準だとうまく効いていなかったこともあって、custom_inputs経由で以下のようにLLMのパラメータを設定しています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/168727/d0b0d2fd-13da-4ef4-be61-4f4e58448b38.png)

:::


「Databricksについて、説明して」と指示して見ましょう。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/168727/566e596e-f32c-4ffa-abe8-9d7e0b150848.png)

ちょっと日本語はイマイチかな。。。

とはいえ、数学計算に最適化されたモデルですので、数学の問題を解かせてみます。
問題は[こちら](https://note.com/it_navi/n/n9cd0e10b336b)から拝借しました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/168727/07ada305-1f88-4806-86ce-7d683c2bc691.png)

思考過程が英語のせいか回答が英語になっていますが、正解です。


# おわりに

Microsoft社のPhi-4-mini-reasoningモデルをDatabricks Model Serving上にデプロイして簡単に試してみました。

MITライセンスで使えるオープンウェイトのReasoningモデルです。
小規模モデルですが、性能は十分に見えますね。

プロプライエタリモデルでは当たり前になりつつあるReasoningモデルがオープンウェイトモデルでも標準になりつつありますね。
思考時間の分レイテンシは大きくなりますが、高度な数学問題などを正しく解くという用途においては非常に有用なモデルだと思います。

というか、学生時代に欲しかったなあコレ。。。
SREノススメ　Part ２

 📘 Site Reliability Engineering 第2章 要約：「サービスの信頼性を測る」徹底解説

---

## ✅ この章の目的：信頼性とは「測れる」もの

SREの基本的な考え方の1つに、「**信頼性は感覚ではなく数値で語るべきである**」という前提があります。  
信頼性を“雰囲気”で語ることは運用や開発の意思決定を曖昧にし、エンジニア間やビジネスサイドとの誤解のもとになります。

本章では、**SREが信頼性をどう定量的に定義し、測定し、運用に活かすか**を、3つのキーワードで解説します：

- **SLI（Service Level Indicator）**
- **SLO（Service Level Objective）**
- **SLA（Service Level Agreement）**

---

## 📏 用語の定義と関係性

### 🔹 SLI：Service Level Indicator（サービス指標）

- **実際のサービス状態を表す定量的なメトリクス**
- 例：リクエスト成功率、レスポンスのP95/P99レイテンシ、エラー率、スループットなど
- SLIの選定は、**ユーザーの体験に直結する指標かどうか**が最重要

### 🔸 SLO：Service Level Objective（サービス目標）

- **SLIに基づく「内部向けの目標値」**
- 通常は99.9%や95%といった可用性目標など
- ユーザーとの契約ではないが、**運用ポリシーやリリース判断に使う基準**

### 🟥 SLA：Service Level Agreement（サービス契約）

- 顧客（社外）と結ぶ正式な契約。違反時はペナルティが発生する可能性もある。
- 通常、**SLOよりやや緩めに設定**される。

```text
🔁 関係性：SLI（実測値）→ SLO（内部目標）→ SLA（契約）
```

---

## 🧪 SLIの具体例

| 指標カテゴリ | 例 |
|--------------|----|
| 可用性 | 成功レスポンスの割合（HTTP 2xx/3xx） |
| レイテンシ | P95/P99の応答時間 |
| 正確性 | コンテンツの誤り率、同期ズレ発生率 |
| スループット | 処理件数、リクエスト数 |
| フレッシュネス | データが最新である割合（キャッシュ、レポート等） |

### ✅ 重要な観点：「ブラックボックス vs ホワイトボックス」

- **ブラックボックス監視**：ユーザーの視点から見たシステムの結果（例：curlでの死活監視）
- **ホワイトボックス監視**：内部メトリクス（例：gRPCのエラーレート、DBクエリ失敗数など）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/520895/3dce2cb0-4039-4898-a8fe-44af41c797cb.png)


---

## 🎯 SLOが必要な理由：妥当な信頼性のゴールを定める

SLOを設定することで、以下のような組織的判断が可能になります：

1. **信頼性に問題があるかどうかを定量的に判断できる**
2. **アラートの正当性を評価できる（ノイズの排除）**
3. **機能リリース vs 安定運用のトレードオフ判断の基準になる**

SLOは「何が正常か？」という合意形成の出発点でもあります。

---

## 📉 アラート設計の誤りと、SLOに基づく改善

### ❌ よくある誤り

- CPU使用率80%を超えたらアラート
- ディスク使用率が90%超でエスカレーション

これらは**システムの状態を監視しているだけで、ユーザー影響を直接反映していません。**

### ✅ SRE的な設計

- 「HTTP 5xxが10%超過」など、**SLO違反と連動したアラート**
- 「ユーザーに影響を与えるメトリクスに基づく通知」が重要

### アラートは“夜中に起きる価値がある”イベントかどうかで精査するべきです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/520895/f0b2a119-b56c-4cd9-a112-6d1c337679a6.png)

---

## 💡 実務での導入ステップ（SLI/SLO）

1. **現状モニタリングしている項目をリストアップする**
2. **ユーザー影響に直結する項目だけをSLI候補として残す**
3. **現状の数値分布（成功率、P99レイテンシ）を確認する**
4. **SLOを仮設定し、しばらく様子を見る（例：可用性99.9%）**
5. **アラートポリシーをSLOベースにリファクタリングする**

---
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/520895/8efcb558-1784-4174-a9aa-ea5e31279e2b.png)


## 🔚 まとめ：信頼性を“感覚”から“設計対象”へ

この章で得られる最大の学びは、以下のように整理できます：

- ✅ 信頼性は「測れる指標」に落とし込んで初めて議論できる
- ✅ SLI → SLO → SLAという階層で管理し、役割を分ける
- ✅ SLOをもとにアラート・運用判断・リリース管理を設計する
- ✅ チームにとっての「十分に良い信頼性（Good Enough）」を定義するのが第一歩

---

次章（第3章）では、実際に「良いSLIとは何か？」「SLOをどう設計するのか？」という設計論に踏み込みます。
SREノススメ

# 📘 Site Reliability Engineering 第1章 要約：「SREとは何か？」徹底解説

---

## ✅ この章の目的：なぜ「SRE」という職種が生まれたのか？

クラウド時代のサービス運用において、**可用性・拡張性・スピード**のすべてを満たすのは非常に困難です。  
従来の「運用チーム（Ops）」と「開発チーム（Dev）」の役割分担では、以下のような対立が起こりがちでした：

| Dev（開発）側の関心 | Ops（運用）側の関心 |
|----------------------|-----------------------|
| 新機能の高速投入      | サービスの安定運用     |
| ユーザーニーズへの対応 | 障害を起こさないこと   |
| リリースの柔軟性       | 手順・手続きの厳格さ   |

このような摩擦を解消するために、Googleが考案したのが **SRE（Site Reliability Engineering）** です。

SREは「運用をソフトウェアエンジニアリングで解決する」という明確な思想を持ち、単なる“運用の自動化”を超えた**信頼性のエンジニアリング**として機能します。

---

## 🧠 SREの基本哲学：「運用はバグである」

GoogleにおけるSREの起点は、「**運用が手作業に依存している状態は、ソフトウェア的に解決されていないバグと見なす**」という思想です。

つまり、SREの目的は以下のように定義できます：

> 「再現性がなく、人手に依存し、頻繁に発生する作業や障害は、必ず自動化または構造的に解消すべきである」

これにより、SREは以下のようなミッションを担います：

- 手動対応の排除（例：runbook対応の自動化）
- インフラのコード化（IaC）
- 監視・リカバリの自動化
- リリース管理の自動化（CI/CD）

---

## 🔁 SREとDevOpsの違いは？

SREとDevOpsはよく混同されがちですが、**DevOpsはカルチャー（文化）**、**SREは実装（エンジニアリング手法）**と捉えるのが適切です。

| 観点 | DevOps | SRE |
|------|--------|-----|
| 性質 | 原則・文化・ムーブメント | 実装ガイドライン・職種 |
| 中心思想 | DevとOpsの協調 | 運用はソフトウェアで解決 |
| 実践方法 | 柔軟に各社に委ねられる | Google流の具体的な手法に従う |

SREは、DevOpsの理念を“Google流に実践するための型”として確立されたものとも言えます。

---

## 📏 SREの特徴的な概念：「エラーバジェット（Error Budget）」

SREの中でも特に重要な概念が「**エラーバジェット**」です。

これは、「**100%の可用性は必要ない（むしろ非現実的）**」という前提に立ち、**“失敗を許容する枠”をあらかじめ設ける**手法です。

たとえば：

- SLO：可用性 99.9% → 許容される障害時間は 月に約43分
- エラーバジェット：残りの 0.1% = ダウンしてもよい時間

### エラーバジェットの概念図
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/520895/23cdec96-a760-4f4c-ba61-4342595883a7.png)

### ✅ エラーバジェットの活用方法：

- バジェットが **残っていれば** → 積極的なリリース・機能開発を許可
- バジェットを **超えたら** → リリースを停止し、信頼性回復を優先

これにより、開発スピードと信頼性のバランスを合理的に管理できます。

---

## 🧰 SREの具体的な業務例

SREの職務は運用業務だけでなく、開発・自動化・改善活動に多岐に渡ります。

| 業務カテゴリ | 具体例 |
|--------------|--------|
| 運用自動化 | 冗長構成、障害検知ツールの実装、自動フェイルオーバー設計 |
| 信頼性向上 | SLO/SLI設計、可観測性強化（Logging/Monitoring/Tracing） |
| Toil削減 | 毎日の定型作業の自動化、バッチやジョブの再設計 |
| インシデント対応 | 障害時の迅速な検出・復旧・原因分析と振り返り（ポストモーテム） |
| リリース管理 | カナリアリリース、ブルーグリーンデプロイ、リリース判定 |

---

## 📊 なぜSREが組織に必要なのか？

SREは、以下のような課題を抱える組織にこそ必要とされます：

- リリースのたびに運用チームが疲弊している
- システムは拡大したが、信頼性の担保が追いついていない
- 障害発生時の初動が属人化しており、ナレッジも蓄積されない
- モニタリングは入れているが、アラートが多すぎて逆に放置されている

SREはこれらを構造的に解決するための手段であり、単なる「運用代行チーム」ではありません。

---

## 💡 チームに取り入れるための第一歩

まずは、以下のようなアクションからSRE的な思想を取り入れてみるとよいでしょう：

1. **Toil（価値を生まない繰り返し作業）の洗い出し**
2. **SLOとSLIを仮でもよいので定義し、信頼性を“測定可能”にする**
3. **障害が発生したときに「自動で検知・通知されていたか？」をチェック**
4. **Postmortem（インシデント振り返り）の文化を始める**
5. **自動化できそうな領域（監視設定、定型手順など）を一つずつ着手**

---

## 🔚 まとめ

SREとは、「運用の品質と効率性をソフトウェアで高める」という、**ソフトウェアエンジニアによる運用手法の再定義**です。

単に「運用が得意なエンジニア」ではなく、信頼性というビジネス価値を支える存在として、プロダクト開発と一体になって活動します。

本章を通じて押さえるべきキーメッセージは次の3つです：

- ✅ 運用はコードで管理・自動化すべき
- ✅ 信頼性は100%でなく「ちょうど良い」ラインを見極める
- ✅ 開発と運用は対立ではなく、エラーバジェットで協調する

---

次章（第2章）では、SREが扱う「信頼性をどう測るか（SLO/SLI/SLA）」の定量的アプローチについて掘り下げていきます。
MacからiPhoneに画面ミラーリングで接続できない

## 事象

Macからiphoneに画面ミラーリングで接続した際以下のような事象が発生した
- 一瞬だけ接続して切断された
- 接続するがグレーの画面が表示されしばらくすると切断される
- そもそも接続できない

## 環境

### Mac
- ハードウェア : Macbook Air 13インチ M3 2024
- OS : Sequoia 15.4.1
- セキュリティソフト : ESET Cyber Security 8.2.3000.0

### iphone
- ハードウェア : iphone12
- OS : iOS 18.4.1

## 解決方法

### ESETの設定を変更する

1. ESETのダッシュボードを開く
1. ツールからアプリケーションを開く
1. iphoneミラーリングのメニューを開く（iphoneミラーリングが起動状態でないと一覧に表示されないので注意）
1. メニューから`高い更新頻度(1秒)`を選択する

### 追記　それでもダメだった場合
- ファイアウォールを一時的に無効化する
Gmailを使いこなせ！20億人のうち95%が知らない10の便利Tips

Gmailは世界中で20億人以上が利用するメールサービスですが、実はその大半がその真価を活かしきれていません。ここでは、Gmailをもっと賢く、便利に使うための10のテクニックを紹介します。

---

## 1. 【送信取り消し】誤送信にすぐ対応！

「しまった！」と思った瞬間でも大丈夫。送信後最大30秒以内なら取り消せます。

**手順：**

1. 右上の⚙️（設定）アイコンをクリック
2. 「すべての設定を表示」＞「全般」タブへ
3. 「送信取り消し機能」を有効にし、「30秒」に設定

---

## 2. 【スパム撃退】プロモーションメールを一掃

検索バーに「unsubscribe」と入力するだけで、配信停止リンク付きのメールを一括表示→削除可能。

---

## 3. 【機密モード】情報漏洩を防止！

メールの転送・コピー・印刷・ダウンロードを制限できます。

**使い方：**
新規メール作成時に、送信ボタンの右にある鍵と時計のアイコンをクリック。

---

## 4. 【オフライン使用】ネットがなくてもGmailが使える

**設定方法：**

1. 設定 ＞「すべての設定を表示」
2. 「オフライン」タブで「オフラインメールを有効にする」にチェック

---

## 5. 【予約送信】寝てても仕事してる風！

**使い方：**
メール作成時、「送信」ボタンの横にある▼をクリックして「送信日時を設定」。

---

## 6. 【あとで読む】メールをスヌーズする

忙しい時はリマインダーのように後で通知されるよう設定。

**方法：**
メール右上の「時計」アイコンから再表示の時間を設定。

---

## 7. 【ラベル活用】メールの整理整頓

「仕事」「家族」「旅行」など自分でラベルを作って分類すれば、見逃し防止に。

**操作：**
メール一覧画面でラベルアイコンをクリック → ラベルを選択 or 作成

---

## 8. 【テンプレート】定型文を一瞬で挿入

**設定方法：**

1. 「設定」＞「すべての設定」＞「詳細設定」タブ
2. 「テンプレート」を有効化
3. メール作成後、「︙」からテンプレート保存／呼び出し可能

---

## 9. 【検索演算子】迷子のメールを秒速で発見

たとえば：

* `from:example@gmail.com` → 送信者で絞り込み
* `has:attachment` → 添付ファイル付きのみ
* `older_than:1y` → 1年以上前のメール

---

## 10. 【スターとフィルタ】重要なメールを自動分類

重要なメールにスターを付けたり、フィルターで自動ラベリングやフォルダ振り分けも可能。

---

## まとめ

Gmailには、知らないと損する便利な機能が盛りだくさん。ぜひこれらのTipsを活用して、毎日のメール業務をスムーズ＆スマートにこなしてください。

https://www.google.co.jp/mail/help/intl/ja/about.html?vm=r
Step CIでpluginを独自実装する

## はじめに
[Step CI](https://docs.stepci.com/)のpluginを実装した際の覚書です。

Step CIでリグレッションテストを実装した際に、テストケース内で直接DBを操作する必要がありました。
しかし、Step CIではDB操作がサポートされていなかったためDB操作用のpluginを自作することにしました。

## フォルダ構成（抜粋）
```
.
├── db-handler/
│   ├── index.js
│   └── package.json
├── stepci.js         ・・・Step CIの実行ファイル
├── package.json
└── workflow.yaml
```

## 実装例 
処理内容は[公式ドキュメント](https://docs.stepci.com/guides/plugins.html)にあるボイラープレートをベースに、要件に応じて必要なロジックを実装します。

``` db-handler/index.js
import * as mysql from 'mysql2/promise';
const { checkResult } = require('@stepci/runner/dist/matcher');

module.exports.default = async (input) => {
  const connection = await mysql.createConnection({
    host: HOST,
    database: DATABASE,
    user: USER,
    password: PASSWORD,
  });

  let stepResult = {};  // Step CIが当該stepの実行結果として受け取るオブジェクト
  stepResult.request = input.query;
  try {
    const [result] = await connection.execute(input.query);
    stepResult.response = result;

    // 実行結果のアサーション
    if (input.check) {
      stepResult.checks = {};
      if (input.check.status) {
        const is_success = result[input.action == 'update' ? 'changedRows' : 'affectedRows'] >= 1;
        const given = is_success ? 'success' : 'failure';
        stepResult.checks.status = checkResult(given, input.check.status);
      }
    }

    return stepResult;
  } catch (error) {
    stepResult.response = error;
    stepResult.checks = {
      status: {
        expected: input?.check?.status ?? null,
        given: 'ERROR',
        passed: false,
      },
    };
    return stepResult;
  }
};
```

### テストケース内での使用
``` workflow.yaml
- name: テストデータ作成
  plugin:
    id: db-hundler
    action: insert
    query: 
      INSERT INTO users (name, email) VALUES ('test_user', 'test@example.com')
    check:
      status: inserted
```

## ハマったポイント
実装時にハマった点としては以下の箇所です。

### CommonJSで実装する
Step CI側の実装がCommonJSであり、自作したpluginをrequireで読み込んでいるのでそれに合わせてCommonJSで実装しmodule.exportsする必要があります。
``` db-handler/package.json
{
  "name": "db-hundler",
  "type": "commonjs",
  "version": "1.0.0",
  "main": "index.js"
}
```

### dependencyへの追加
実装したpluginをyaml内で使用するには、ローカルパッケージとして`db-handler`ディレクトリをプロジェクトの package.json に依存として追加し`npm install`を実行して`node_modules`に取り込む必要があります。
``` package.json
{
  "dependencies": {
    "db-hundler": "file:./db-hundler"
  }
}
```
yamlの`plugin.id`には`dependencies`に記載したキーを指定します。

## おわりに
Step CIでDB操作を可能にする自作プラグインの実装方法のメモでした。
公式でサポートされていない機能でも、プラグインを活用すれば柔軟に拡張ができるので便利です。

自動テストでは、システム固有の前処理や検証が必要になる場面も少なくありません。  
プラグインを積極的に活用し、より良いCI/CDの実現を目指していきたいです。
ハードウェアサイジングについて

ハードウェアサイジングは、システムの使用状況（ユーザー数やトランザクション量など）をもとに最適なハードウェア構成（CPU、メモリ、ストレージ、ネットワーク帯域など）を予測・決定するプロセスです  ￼。
一般には要件収集 → ワークロード分析 → リソース見積もり（ピーク/平均） → テスト → 調整、という反復的なアプローチで行われます。
適切に行うことで、コストの無駄遣いを防ぎつつ、必要な性能を確保できます  ￼。

## 1.ハードウェアサイジングとは
ソフトウェアを適切に稼働させ、所定の性能を満たすために必要なハードウェア（CPUコア数、メモリ容量、ディスクスペース、I/O性能、ネットワーク帯域など）を見積もる作業  ￼。

**資源要件（Resource Requirements）：**

CPUやメモリといったコンピューティング資源の量的需要を指す総称。

### 用語解説
**CPU（Central Processing Unit）**
コンピュータの演算・制御を担う中枢部品。コア数とクロック周波数が性能指標。

**メモリ（主記憶）**
処理中のデータやプログラムを一時的に格納する高速記憶装置。スワップ発生を防ぐために十分な容量が必要。

**ストレージ（補助記憶）**
永続的にデータを保存する装置。容量だけでなく、I/O性能（IOPS: 秒間入出力回数）も重視。

**I/O性能**
ディスクやネットワークを介したデータ転送速度・入出力回数の指標

**スループット（Throughput）**
単位時間あたりに処理または転送できるデータ量。システム全体の処理能力を測る指標。

**レイテンシ（Latency）**
要求から応答開始までの遅延時間（主にネットワークやI/Oにおける遅延）  ￼。

**ヘッドルーム（Headroom）**
予測ピーク以上の負荷に対応する余裕。通常は20～30％程度を見込む。

## 2.サイジングの目的と重要性

### 2-1.コスト最適化
無駄に過大なサーバ構成を避け、初期投資や運用コストを抑制します  ￼。

### 2-2.パフォーマンス保証
想定ピーク時にも十分な応答性能（レスポンス時間や同時接続数）を確保し、ユーザー体験を損なわないようにします  ￼。

### 2-3.サイジングのプロセス
**要件収集**
ユーザー数（同時・最大）、トランザクション種別や頻度、データサイズ、将来の成長率などをヒアリング・ログ分析。

**ワークロード分析**
実際の処理内容（CPU負荷、メモリ使用量、I/O量、ネットワークトラフィック）を測定。

**リソース見積もり**
平均負荷とピーク負荷を区別し、各リソース要件を計算。

**テスト（ベンチマーク）**
JMeterなどの負荷試験ツールで想定負荷を再現し、必要なハードウェア性能を検証。

**調整・反復**
テスト結果をもとに構成を再検討し、最適化。

## 3.主なサイジング項目と指標

### 3-1.CPU
**コア数**
同時に実行できるスレッド数に影響。

**クロック周波数**
単一スレッド性能を左右。

### 3-2.メモリ
**容量**
ワークロードに応じて、スワップを避けるため十分なサイズを確保。

**メモリ速度**
帯域とレイテンシが性能に影響。

### 3-3.ストレージ
**IOPS**
1秒間の入出力回数。ランダムI/O性能の指標。

**スループット（帯域）**
連続データ転送速度を表す。

### 3-4.ネットワーク
**帯域幅（Bandwidth）**
ネットワークが理論的に転送可能な最大データ量。

**レイテンシ**
往復時間（RTT）やパケット遅延。低レイテンシ化がユーザー体感速度を大きく改善。

## 4.ツールとベストプラクティス
### ベンチマークツール
JMeter、Sysbench、FIOなどで実際の処理負荷を模擬し、各リソースの許容度を測定。
    
### クラウド計算ツール
AWSやAzureの提供するリソース計算ツールを活用し、オンプレミスと比較しながら最適構成を検討。
    
### 反復的アプローチ
初回見積もり後も運用中にメトリクスを収集し、実績値を反映して継続的に調整。

## 5.まとめ
* ハードウェアサイジングは要件→分析→見積もり→テスト→調整の反復プロセス。
* 主要資源（CPU、メモリ、ストレージ、ネットワーク）の特性（スループット、レイテンシ、IOPSなど）を正しく理解し、適切に見積もる。
* ベンチマークやクラウドツールを活用し、理論値だけでなく実測値をもとに構成を最適化。
* コスト削減と性能保証のバランスをとることが重要。
「YAMLってなんか聞いたことある…」という方たちへ


# YAMLとはマークアップ言語じゃない！

YAMLとは、
"YAML Ain’t Markup Language"（YAMLはマークアップ言語じゃない！の略）の略語です。
名前の定義に名前がある再帰的なやり方がかっこいいですね。


YAMLは人間にとって読みやすいデータ記述フォーマットの1つで、設定ファイルやデータの構造を簡潔に書くためによく使われます。
HTMLやXMLのように、文章をコンピュータに理解させるためテキストにタグや記号などを埋め込むマークアップ言語とは異なります。

もっと簡単にいうと、設定ファイル界の「手書きメモ」みたいな存在です。

## ざっくり特徴3選

ざっくりと３つの特徴だけ覚えておきましょう。

* ✅ **とにかく見やすい**
  　→ もうXMLやカッコだらけのJSONに怯えなくていい。
* ✅ **スペースで階層を表現**
  　→ インデントが命。でも**タブは禁止！**（鬼のルール）
* ✅ **設定ファイルによく使われる**
  　→ 開発者がこっそり編集してるファイルの正体がYAMLです。



## 何に使われてる？

実はあなたの知らないところで、こんな風に使われています。

-  アプリやツールの設定ファイル
-   Kubernetes（クラウドでアプリを動かす）の構成管理
-   GitHub Actionsで「自動でテストしてね」と指示するスクリプト
-   Ansibleで「このサーバー、こうしておいてね」とお願いするファイル
など。

👨‍💻「いや、それってJSONでよくない？」
🤖「いやいや、YAMLは“人間が読む”ためにあるんだよ。」

## YAMLを実際に書いてみよう。

実際に書いてみると、JSONとの違いがわかりやすいです。
まずは、YAMLで人の情報を書いてみましょう。

```yaml
user:
  name: "田中太郎"
  age: 30
  skills:
    - Python
    - Azure
    - Databricks
```

見やすくないですか？
「田中太郎さん、30歳、クラウドとかデータ分析できそうだな」って、一瞬で伝わります。

これをJSONで書くと……

```json
{
  "user": {
    "name": "田中太郎",
    "age": 30,
    "skills": ["Python", "Azure", "Databricks"]
  }
}
```

😇「いや、JSONさん……君も悪くないんだけど、カッコ多すぎ」

YAMLのシンプルさ、可読性が高いことがわかルカと思います。

ただし、YAMLは見やすい分ちょっとしたこだわり屋さんでもあります。
スペースの数、改行の位置――そういう細かいところを気にします。
少しスペースがずれると表示されなかったりします。


## YAML vs JSON vs XML

「マークアップ言語と言えば、なんかJSONとかXMLってのも聞いたことあるけどそれらとは違うの？」
と思う方もいるかと思います。

これらは一般的に使用されるデータ形式として、それぞれ独自の特徴を持ち、異なるアプリケーションシナリオに適しています。

以下の項目で比較してみます。


| 項目             | YAML          | JSON         | XML                |
| -------------- | ------------- | ------------ | ------------------ |
| **読みやすさ**      | ◎（人間向け）       | ○（まあまあ）      | △（目が疲れる）           |
| **書きやすさ**      | ○（スペース命）      | ◎（カッコ多いけど簡単） | △（タグ閉じるの大変）        |
| **構造の表現力**     | ◎（柔軟）         | ○（入れ子構造得意）   | ◎（属性とか扱える）         |
| **よく使われる場所**   | 設定ファイル、インフラ定義 | API通信、Webアプリ | 古めのシステム、Office製品など |
| **初心者フレンドリーさ** | ◎             | ○            | △                  |


覚えやすいよう三兄弟をキャラで例えるとこんな感じです。

🟡 YAMLくん（末っ子）
　→ 見た目で勝負！感覚派。メモがうまくて、人に伝えるのが得意。几帳面だけど、ちょっと神経質（タブ禁止とか）。

🟢 JSONくん（次男）
　→ 真面目で合理主義。カッコは多いけどルールはシンプル。パソコンと仲良し。API界の人気者。

🔵 XMLさん（長男）
　→ 昭和生まれのベテラン。礼儀正しいけど、口調が堅い。昔は最強だったけど、今はちょっと距離感ある存在。


もっと詳しく知りたい方はこちらも参考になるかと思います。

https://aws.amazon.com/jp/compare/the-difference-between-yaml-and-json/

# あなたのPCでもすぐYAMLを見つけらるはず

あなたのすぐ手の届く範囲にも、すでにYAMLはいます。
試しに、以下の場所を探してみてください。

##  Mac編（Finderで探す）

1. Finderを開く
2. 「このMacを検索」を選ぶ
3. 🔍 検索欄に： `*.yml` または `*.yaml` と入力
4. 「種類：その他 → プレーンテキストファイル」にすると探しやすいかも


## Windows編（エクスプローラーで探す）

1. エクスプローラーを開く
2. 上の検索窓に： `*.yml` または `*.yaml` と入力
3. ユーザーフォルダ（C:\Users\あなたの名前）から探すとヒットしやすいです

見つけたファイル例：

* `docker-compose.yml`：Dockerという開発ツールの設定
* `.github/workflows/deploy.yml`：GitHubでの自動処理の設定
* `vite.config.yaml`：Webフレームワークの設定（Viteなど）




# 最後に：YAMLと仲良くなろう。

YAMLは **「とにかく書いてみる」** のが一番！
あなたの使ってるアプリにも、もしかしたら`.yml`ファイルが眠ってるかも？
設定ファイルを開いて「うわっ、なんか出た！」とならずに
「あ、なんだ〜これYAMLじゃん！」とドヤりましょう。
Firefox拡張機能でコンテンツスクリプトのログを出力する方法

# 概要

ブラウザ拡張機能でコンテンツスクリプトからコンソールへログを出力するための方法を記載します。

そのままだとコンテンツスクリプトからログが出力されないため、
コンテンツスクリプトからバックグラウンドスクリプトへログを送信します。

# 使用する関数

browser.tabs.sendMessageとbrowser.runtime.onMessageを使います。

| 構文 | 使う場所 |
| ---- | -------- |
| browser.tabs.sendMessage | Background script |
| browser.runtime.onMessage | Background script, Content script |

# サンプルコード

## コンテンツスクリプト

以下のコンテンツスクリプトを作ります。
main.jsとして保存します。

```javascript:main.js
// コンテンツスクリプト
function sendError() {
  browser.runtime.sendMessage("send content error");
}

sendError();
```

## バックグラウンドスクリプト

以下のバックグラウンドスクリプトを作成します。
background.jsとして保存します。

```javascript:background.js
// バックグラウンドスクリプト
browser.runtime.onMessage.addListener(getMessage);

function getMessage(message) {
    console.log(message);
}
```

このようにすることで、コンテンツスクリプトで生成された文字列が
バックグラウンドスクリプトへ送られ、バックグラウンドスクリプトが
出力することで開発ツールにも表示されます。


# 参考

[tabs.sendMessage()](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/sendMessage)

[runtime.onMessage](https://developer.mozilla.org/ja/docs/Mozilla/Add-ons/WebExtensions/API/runtime/onMessage)
(UNO3)Arduino-misakiUTF16で遊ぶ。文字列



参考
----

https://github.com/Tamakichi/Arduino-misakiUTF16

結果
----

![Screenshot from 2025-05-02 07-52-41.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/840352/9a34bf97-bd55-4f1b-88a4-68953191494e.png)


プログラム
----

```c++


#include <misakiUTF16.h>

void setup() {
  Serial.begin(115200);

  char font[8];                       // フォント格納バッファ
  char *str="Abcあいうえお、埼玉";    // 文字列

  char *ptr = str;
  while(*ptr) {  // 文字列分ループ
     ptr = getFontData(font, ptr);   // 1文字分のフォント取得
     if (!ptr)
        break;                       // エラーの場合は終了

    // 取得フォントの確認
    for (uint8_t row=0; row<8; row++) {
      for (uint8_t col=0; col<8; col++) {
         Serial.write( (0x80>>col) & font[row] ? '#':' ');
      }
      Serial.write('\n');
    }
  }
}

void loop() {

}


```
【予告】Python×GIS入門：「Automating GIS Processes 2024」の写経をはじめます

お仕事の関係で、[Automating GIS Processes 2024](https://autogis-site.readthedocs.io/en/latest/)」の学習を始める予定です。
手早く進めたいので、環境は[Google Colab](https://colab.google/)です。

写経をしながら得られた知見や、詰まったポイントなどを、ログ的にゆるく残していこうと思います。
この教材に関する日本語の情報はあまり多くないようなので、同じように試す方の参考になれば幸いです。

乞うご期待！
GitHubでSSH認証を実装する方法

## 事の発端...
### git push時に403エラーが発生
久しぶりにプッシュをしようとした所、「The requested URL returned error: 403」が表示されました。どうやらGitHubの認証が上手くいっていなかったらしいです。
色々な記事を読んでみて、下記のコマンドで資格情報の確認をしてみました。
```
$ git config credential.helper
```
すると、MacOSを使っていますので
```
osxkeychain
```
と表示されました。下のキーチェーンアクセスから
![Screenshot 2025-05-02 at 6.09.26.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2153036/78dba1cd-db62-4143-9820-eae15c1fada1.jpeg)
github.comのパスワード情報を検索しても、見つかりません。どうやら別の所に問題があるのかもしれません。![Screenshot 2025-05-02 at 6.11.56.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2153036/9698b867-8f79-4067-a8db-7a4fb7aa234a.jpeg)

### GitHubのPersonal access tokensの検証
GitHubの設定からDeveloperSettingさらにPersonal access tokensの Fine-grained tokensで生成したものを認証に使ってみましたが、結果的にこれも上手くいきませんでした。
![mosaic_20250502062513.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2153036/f75c958f-fb25-4fa8-bec3-24a8d13a57af.png)
アクセストークンは最初の一回しか表示されないので、画面をスクショしないといけないことに注意、またアカウント名・パスワードを聞かれるタイミングで**パスワードの代わりに発行されたトークンを貼って認証しないといけない**という何とも分かりずらい仕組み... 
こんなに長いトークン値をパスワードとして使うのは使い勝手が悪い。しかも認証もうまくできなかったし...

### GitHub公式ブログの確認
下の記事によると2021年8月13日以降、Git操作を認証する際はSSH鍵を使うことを推奨しますと書いてありました。
[Git操作のトークン認証要件](https://github.blog/security/application-security/token-authentication-requirements-for-git-operations/)
SSH接続が有効そうなので、頑張って調べて取り入れてみました。公開鍵認証が実際にどのよう使われているのか手を動かして理解できました。

## SSH認証の手順
### 公開鍵・秘密鍵の作成
GitHubアカウント用の公開鍵・秘密鍵を生成します。ターミナルを起動し、以下のコマンドを実行します。
```
#.sshディレクトリに移動する
$ cd ~/.ssh
```
```
# 公開鍵と秘密鍵のペアを生成する
$ ssh-keygen -t rsa
```
パスフレーズや鍵の名前など3つの質問が聞かれますが、ここでは簡易的に一つのアカウント認証をするとして、Enterキー3回押してスキップしてOKです。
![Screenshot 2025-05-02 at 7.08.04.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2153036/3467b0be-8abf-490b-8344-2296dd2e64bd.jpeg)
秘密鍵 **id_rsa** と公開鍵 **id_rsa.pub** が生成されました。次のステップでこの公開鍵をGitHubに登録します。
### 公開鍵をGitHubに登録する

GitHubアカウント上で新規のSSH鍵を登録する。下の新しいSSH keyを選択して新たに作成します。
![mosaic_20250502065411.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2153036/e24ce781-c1ba-4c78-911a-9b479cc1f6f7.png)

タイトルは仕事用・私用のアカウントなど名前をつけましょう。
![Screenshot 2025-05-02 at 7.11.14.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2153036/be9d04e6-c0ea-4c0b-9186-2c37c8f158f5.jpeg)

鍵の中身のクリップボードへのコピーは、下のコマンドでいけます。
```
$ pbcopy < ~/.ssh/id_rsa.pub
```
Key内にペーストすると末尾に自身のメールアドレスの情報も付いてくるのでセキュリティ上削除しておきましょう。

### configファイルにアカウント情報を記入
configファイルを作成します。
```
vim ~/.ssh/config
```
以下の内容を記入します。複数のアカウントを記入できますが、今回は簡単に一つのアカウントを使用するとします。

```
#メインアカウント
Host github #任意のホスト名
  HostName github.com
  IdentityFile ~/.ssh/id_rsa #メインアカウントの鍵のファイル
  User git
  Port 22
  TCPKeepAlive yes
  IdentitiesOnly yes
```

### GitHubとの接続確認
先ほどファイルに記入したホスト名を使用します。
ssh -T [Host]で接続できます。
```
$ ssh -T github
```
下記メッセージが表示されれば成功です。
Hi [メインアカウントのユーザー名]! You've successfully authenticated, but GitHub does not provide shell access.

>今回は一つのGitHubアカウントの認証のトラブルシューティングですが、一つのPCで仕事用と私用のアカウントを切り替えたいときはまた気をつけておかないといけない点がありますので、別記事で解説していきたいと思います！
>
windows11で、sketchup6 その93

# 概要
windows11に、sketchup6を入れてみた。
rubyで、3Dを書く。
式を評価して、グラフを描く、スクリプト見つけたのでやってみた。

# 写真


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/18104/4f92949b-209a-4d00-97b5-11a35d6fd7c2.png)

# サンプルコード

```
def graph_3d
	model = Sketchup.active_model
	model.start_operation "k_tools"
	entities = model.active_entities
	group = entities.add_group
	entities = group.entities
	Sketchup::set_status_text("Dessiner une surface 3D sur le plan XY", SB_PROMPT)
	xbeg = -1.0 if not xbeg
	xend = 1.0 if not xend
	stepx = 0.1 if not stepx
	ybeg= -1.0 if not ybeg
	yend= 1.0 if not yend
	stepy = 0.1 if not stepy
	prompts = ["Valeur X mini ", "Valeur X maxi ", "Valeur du pas X ", "Valeur Y mini ", "Valeur Y maxi ", "Valeur du pas Y "]
	values = [xbeg, xend, stepx, ybeg, yend, stepy]
	results = inputbox prompts, values, "Intervalle et resolution"
	xbeg, xend, stepx, ybeg, yend, stepy = results
	formula = "x*y" if not formula
	prompts = ["z = "]
	values = [formula]
	results = inputbox prompts, values, "Formule mathematique"
	formula = results.to_s
	$style = "Facetise" if not $style
	style_list = %w[Grille Triangle_Grille Facetise].join("|")
	dropdowns= [style_list]
	prompts = ["Style: "]
	values = [$style]
	results = inputbox prompts, values, dropdowns, "Visualisation"
	$style = results[0].chomp
	xbeg.step(xend - stepx, stepx) do |i|
	ybeg.step(yend - stepy, stepy) do |j|
	x1 = i
	x = x1
	y1 = j
	y = y1
		begin
			z1 = eval(formula)
		rescue
			z1 = 0
		end
		z1 = 100000000 if z1 > 100000000
		z1 = -100000000 if z1 < -100000000
		x2 = i + stepx
		x = x2
		y2 = j
		y = y2
		begin
			z2 = eval(formula)
		rescue
			z2 = 0
		end
		z2 = 100000000 if z2 > 100000000
		z2 = -100000000 if z2 < -100000000
		x3 = i
		x = x3
		y3 = j + stepy
		y = y3
		begin
			z3 = eval(formula)
		rescue
			z3 = 0
		end
		z3 = 100000000 if z3 > 100000000
		z3 = -100000000 if z3 < -100000000
		x4 = i + stepx
		x = x4
		y4 = j + stepy
		y = y4
		begin
			z4 = eval(formula)
		rescue
			z4 = 0
		end
		z4 = 100000000 if z4 > 100000000
		z4 = -100000000 if z4 < -100000000
		pt1 = [x1.m, y1.m, z1.m]
		pt2 = [x2.m, y2.m, z2.m]
		pt3 = [x3.m, y3.m, z3.m]
		pt4 = [x4.m, y4.m, z4.m]
		if $style == "Facetise" then
			face3d= entities.add_face(pt1, pt2, pt3)
			face3d= entities.add_face(pt2, pt3, pt4)
		else
			polyline3d = entities.add_line(pt1, pt2)
			polyline3d = entities.add_line(pt1, pt3)
			polyline3d = entities.add_line(pt2, pt4)
			polyline3d = entities.add_line(pt3, pt4)
			if $style == "Triangle_Grille" then
				polyline3d = entities.add_line(pt2, pt3)
			end
		end
	end
	end
	view = model.active_view.zoom_extents
	model.commit_operation
end

```

以上。
ChatGPTを使用したアプリ開発記【投稿削除ボタンを追加】

## 投稿削除ボタンを追加
```react
import React, { useState } from 'react';

function App() {
  const [text, setText] = useState('');
  const [posts, setPosts] = useState([]);

  const handleSubmit = (e) => {
    e.preventDefault();
    if (text.trim() === '') return;

    const now = new Date();
    const formattedTime = now.toLocaleString('ja-JP', {
      year: 'numeric',
      month: '2-digit',
      day: '2-digit',
      hour: '2-digit',
      minute: '2-digit'
    });


    const newPost = {
      text: text,
      time: formattedTime,
      likes: 0
    };

    setPosts([newPost, ...posts])
    setText('');
  };

  const handleLike = (index) => {
    const updatedPosts = [...posts];
    updatedPosts[index].likes += 1;
    setPosts(updatedPosts);
  }

//handleDelete という名前の関数を定義し、引数として index を受け取ります。
//これは、削除したい投稿が posts 配列の中で何番目か（0から始まる番号）取得する為です。
  const handleDelete = (index) => {

//posts.filter(...) は、posts 配列から特定の要素を除いた新しい配列を作ります。
//(_, i)：
//最初の引数 _ は各投稿の中身（ここでは使わないので _ にしている）。
//2番目の引数 i はインデックス番号（投稿が配列の何番目か）です。
//i !== index：
//今のループ中の投稿の i が、削除したい index と一致しないものだけを残します。
//つまり、「削除したい投稿以外を全部残す」ことで、削除された状態の配列を作ります。
    const updatedPosts = posts.filter((_, i) => i !== index);

    setPosts(updatedPosts);
  }

  return (
    <div style={{ padding: '2rem', fontFamily: 'sans-serif' }}>
      <h1>SNS</h1>
      <form onSubmit={handleSubmit}>
        <textarea
          value={text}
          onChange={(e) => setText(e.target.value)}
          placeholder="今なにしてる?"
          rows="4"
          cols="50"
          style={{ display: 'block', width: '100%', marginBottom: '1rem' }}
        />
        <button type="submit">投稿する</button>
      </form>

      <div style={{ marginTop: '2rem' }}>
        <h2>投稿一覧</h2>
        {posts.map((post, index) => (
          <div key={index} style={{ padding: '1rem', borderBottom: '1px solid #ccc' }}>
            <div style={{ fontSize: '0.8rem', color: '#666' }}>{post.time}</div>
            <div>{post.text}</div>
            <button onClick ={() => handleLike(index)}>❤️ いいね ({post.likes})</button>
            
//クリックされたときに、現在の投稿の index を使って handleDelete 関数を呼び出します
            <button onClick={() => handleDelete(index)} style={{ marginleft: '1rem', color: 'red'}}>
              🗑️ 削除</button>
          </div>
        ))}
      </div>
    </div >
  );
}

export default App;

```

![ezgif.com-video-to-gif-converter.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1058366/60b59ab9-e746-40fa-8b15-57c3b35efaba.gif)
個人的備忘録：Next.js × TypeScriptで発生した「未使用変数」のLintエラーを解決してみた話

## はじめに

この記事では、Next.js + TypeScript の開発中に発生する ESLint のエラー `_' is defined but never used` に関する原因と対処法を解説します。

:::note info
**個人の備忘録程度の走り書きとなっておりますが、温かい目で見守っていただければ幸いです。**
:::

特に `try...catch` 文で `catch (_)` のように未使用の引数を記述している場合に発生するパターンに焦点を当てます。

## 書こうと思ったきっかけ

受講しているITスクールのハッカソンの開発中にこのエラーに遭遇したため、チーム内で同じ対応を共有できるよう備忘録としてまとめています。

### エラー内容
`_' is defined but never used`
- ESLint は `_` を使っても「未使用の変数」とみなします。
- これは、`catch` 節の引数として `_` を書いても、実際に使っていなければエラーになるということです。

### 対処方法
引数自体を削除してしまうのが正解です。`catch (エラー)` の構文は省略可能なので、使わないなら完全に省いてOKです。

#### ✅ 修正前のコード：
```ts
} catch (_) {
  alert("通信エラーが発生しました");
}
```

#### ✅ 修正後のコード：
```ts
} catch {
  alert("通信エラーが発生しました");
}
```

### 対象ファイルと修正内容
| ファイル | 修正箇所 | 修正内容 |
|---------|----------|-----------|
| src/app/login/page.tsx | `catch (_)` → `catch` に変更 | ✔️ |
| src/app/register/page.tsx | `catch (_)` → `catch` に変更 | ✔️ |

### 修正後の確認
```bash
npx next lint
```
→ エラーが表示されなければ対応完了です。

## まとめ

- `_` を使っても ESLint では未使用として検出されることがあります。
- `catch` 節で例外オブジェクトを使わない場合は、引数ごと省略して書くのがベストです。
- 開発効率を落とさないためにも、こうしたLintの癖を理解し、すばやく対応できるようにしてみてください。
個人的備忘録：共通レイアウトを管理する Next.js の RootLayout 構成メモ

## はじめに

この記事では、Next.js アプリケーションにおける `RootLayout` コンポーネントのコード内容と、その目的について簡潔にまとめます。

:::note info
**個人の備忘録程度の走り書きとなっておりますが、温かい目で見守っていただければ幸いです。**
:::

全体のフォントやスタイル設定、レイアウト構成の基本となる部分です。

## 書こうと思ったきっかけ

受講しているITスクールのハッカソンの開発の一環で、共通レイアウトを構築した際の設定を忘れないように備忘録としてまとめています。

## コード

```src/app/layout.tsx
import type { Metadata } from "next";
import { Geist, Geist_Mono } from "next/font/google";
import "./globals.css";
import "../styles/common.css"; // ← 追加：和室用CSS（必要に応じて）

const geistSans = Geist({
  variable: "--font-geist-sans",
  subsets: ["latin"],
});

const geistMono = Geist_Mono({
  variable: "--font-geist-mono",
  subsets: ["latin"],
});

export const metadata: Metadata = {
  title: "Create Next App",
  description: "Generated by create next app",
};

export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <html lang="ja">
      <head>
        {/* さぶちゃん日記風フォント（M PLUS Rounded 1c）を読み込み */}
        <link
          href="https://fonts.googleapis.com/css2?family=M+PLUS+Rounded+1c:wght@700&display=swap"
          rel="stylesheet"
        />
      </head>
      <body
        className={`${geistSans.variable} ${geistMono.variable} antialiased`}
      >
        {children}
      </body>
    </html>
  );
}
```

## 内容

- `Geist` および `Geist_Mono` フォントを Next.js の組み込み Google Fonts 機能で読み込み、CSS変数として利用できるように設定しています。
- `common.css` を読み込むことで、和室風のデザインスタイルを全体に適用しています。
- `<head>` タグ内で、M PLUS Rounded 1cフォントを明示的に読み込み、日本語の表示に柔らかい印象を与えるようにしています。
- `<body>` にフォント変数と `antialiased` クラスを指定し、全体の文字表示を滑らかに整えています。
- 最後に、`children` を展開することで、このレイアウトがアプリ内のすべてのページに適用されるよう設計されています。

## まとめ

この `RootLayout` は、Next.js アプリの基本的な見た目や雰囲気を決定づける重要な部分です。

:::note warn
***フォント、CSS、構造を適切に定義することで、和風かつ整ったUIを全体に行き渡らせることができます。***
:::

ハッカソンなどで再利用する際にも役立つため、ここに記録しておきます。