OmniAICreator/Qiita-1.07M huggingface dataset:
Body exceeded 1mb limitの対処法（画像を大量に送りたかった）

# どういう環境で何をしているのか？について
* NEXT.jsでWebアプリ（Webサイト）を構築中に、
* pages/apiにinsert.jsというAPI用のスクリプトを準備中に、
* insert.jsでは複数以上の画像や登録情報をリクエストで受け、それら登録する機能を実装していた

# エラー事象
```:エラー内容
POST http://localhost:3000/api/insert 413 (Body exceeded 1mb limit)
```
insertのAPIに対し、bodyに画像を大量につけて送ってもこのエラーがレスポンスとして返却されており、その対処法が分からなかったための忘備録✏️エラーコードを見る限り、容量に制限があることはわかるものの「AIに聞いても"next.config.js"にコードを追記すれば直ります」と言いつつも解決せず、調べても日本語サイトがなかったので、その忘備録を記録したものです。ちなみに私の環境では"next.config.js"というものは存在せず、"next.config.mjs"があったが、そこを修正しても解決しなかった🤮

# 対処法
私はinsert.jsに対して次のコードを挿入することで解決した。英語のサイトで確認して実装したところ、画像を大量に送れるようになった💡
```:insert.jsに追記したコード
export const config = {
  api: {
    bodyParser: {
      sizeLimit: "10mb",
    },
  },
};
```
なおこれを前提にAIに話しかけたら、AIもこれが正しいみたいなことを言い始めた💦

# 補足事項⚠️
前回、同じ記事を投稿したのですが、投稿した直後から別のエラーが発生し、解決しなかったので前回の投稿を削除しました🖐️この時のエラーはこの記事の内容とは全く別の原因だったので、再投稿しています☁️
Delphi 11.3 + Xcode15.3 iOS17.Xの開発について

環境
・Delphi 11.3
・Xcode15.3
・iOS17.5～
上記でiOSのアプリを開発しています。

3つ目のiOS17.5ではなく、15.3ではアプリがiPadに表示され、インストールも完了しました。
iOS17.5の端末にインストールするのに苦戦しています。
いろいろ調べてますと、
library/Platforms/iphoneOS.platform/Devicesupport/配下に16.4以降がない、CoreDevice に変わった等見ましたが、解決に至ってません。

Delphiから配置を行った際に下記のエラーが表示されます。
Unable to mount developer disk image. (e8000007).

申し訳ありませんが、どなたか解決法を教えて頂けないでしょうか。
よろしくい願いします。
【初級者】インデントのイメージ

# 初めに
このサンプルは初めての人用、にインデントのイメージです

## 注意
あくまでもこちらのインデントの考え方以外にもいろいろあるので、そのうちの一つです。


## インデントタイミング　

### 関数の始まりと終わり
関数の宣言後の内容についてインデントします
（これは定義はインデントしない流派もあります）

```vb
function fncProg() as String
　　'インデント　
   
    '定義
     dim hoge as string

    '本文
    hoge = "テスト表示"
    msgbox(hoge)

    fncProg = ""
end function

```

### 判定式の内容
判定分の場合の実行方法もインデントします

```vb
Select Case Cells(i, 4)
Case "投手"
    cnt1 = cnt1 + 1  '←インデントする
Case Else
    cnt4 = cnt4 + 1  '←インデントする
End Select

```

```vb
If cnt4 > 1 Then
    msgbox("")  '←インデントする
End If

```
### 繰り返し文の中身
繰り返し処理での実行内容もインデントします
```vb
For i = 3 To 最終行
    i= i +1  '←インデントする
Next

```

### 二重入れ子
上記のインデント条件が重なる場合は再度、再度インデントをします

```vb
For i = 3 To 最終行
    i= i +1  '←インデントする
    
    'For文の中のFor文なのでインデントする
    For cnt = 1 To 最終行
        cnt= cnt +1  '←インデントする
    Next
Next

```




## サンプル

```vb:入れ子サンプル

'--------------------------------
'関数名　:選手カウント
'内容　　：それぞれの守備登録人数を数え、E列に表示する       
'引数    :なし
'戻り値  :なし
'--------------------------------
Sub カウント()
    Dim i As Long
    Dim j As Long
    Dim cnt1 As Long
    Dim cnt2 As Long
    Dim cnt3 As Long
    Dim cnt4 As Long

    Dim 最終行 As Long

    最終行 = Cells(Rows.Count, "C").End(xlUp).Row

    For i = 3 To 最終行

        For k = 2 To 最終行

            Select Case Cells(i, 4)
            Case "投手"
                cnt1 = cnt1 + 1
            Case Else
                cnt4 = cnt4 + 1
            End Select

            If cnt4 > 1 Then
                msgbox("")
            End If

            If Cells(i, 4) = "投手" Then
                cnt1 = cnt1 + 1
            ElseIf Cells(i, 4) = "捕手" Then
                cnt2 = cnt2 + 1
            ElseIf Cells(i, 4) = "内野手" Then
                cnt3 = cnt3 + 1
            Else
                cnt4 = cnt4 + 1
            End If


        Next

        If cnt4 > 1 Then
            msgbox("")
        End If

    Next

    Dim setFlg As Boolean

    For i = 3 To 最終行

        setFlg = False

        If Cells(i, 4) = "投手" Then
            cnt1 = cnt1 + 1
            setFlg = True

        End If

        If Cells(i, 4) = "捕手" Then
            cnt2 = cnt2 + 1
            setFlg = True
        End If

        If Cells(i, 4) = "内野手" Then
            cnt3 = cnt3 + 1
            setFlg = True
        End If

        If setFlg = False Then
            cnt4 = cnt4 + 1
        End If
    Next

    Cells(4, 7) = cnt1
    Cells(5, 7) = cnt2
    Cells(6, 7) = cnt3
    Cells(7, 7) = cnt4


End Sub


```
Laravel Breeze

## AIに質問した回答
### 次、breezeを入れるときに参考にする用。
> ## Laravelのガード（Guard）について説明します。
> Laravelなどのフレームワークでは、認証機能を定義する仕組みを「ガード」と呼びます。
>
> ガードとは
> 認証システムの「方法」を定義するコンポーネントです。つまり、「どのように」ユーザーを認証するかを決定します。
>
> Webアプリケーション → セッションガード
> モバイルアプリ → Sanctumガード（APIトークン）
> 外部サービス → Sanctumガード（APIトークン）
> 
> ## Laravelのauthミドルウェアとauth:sanctumミドルウェアの主な違いを説明します：
>
> ### authミドルウェア
> - セッションベースの認証を使用
> - 主にWebアプリケーションで使用
> - Bladeテンプレートを使用する従来のLaravelアプリケーション
> - auth.phpのデフォルトガード（通常は'web'）を使用
> ```
> <?php
> Route::middleware('auth')->group(function () {
>     // セッションベースの認証が必要なルート
> });
> ```
>
> ### auth:sanctumミドルウェア
> - APIトークンベースの認証を使用
> - SPAやモバイルアプリのAPIで使用
> - Vue.js, React, Angular などのSPA
> - Bearerトークンによる認証
> - クロスオリジンリクエストに対応
>
> ```
> <?php
> Route::middleware('auth:sanctum')->group(function () {
>     // APIトークン認証が必要なルート
> });
> ```
> ## sanctumの設定ファイルの場所
> `api/vendor/laravel/sanctum/src/SanctumServiceProvider.php`
> 
> ## 動作の仕組み
> 以下のように使用する時：
> ```php
> Route::middleware('auth:sanctum')->group(function () {
>     // APIトークン認証が必要なルート
> });
> ```
>
> 以下の処理が行われます：
>
> 1\. リクエストが来た時に`auth:sanctum`ミドルウェアが起動
> 2\. リクエストヘッダーの`Authorization: Bearer {token}`を確認
> 3\. トークンの検証
> 4\. 認証成功/失敗の判定
>
> 主な処理の流れは：
>
>```mermaid
> graph TD
>     A[リクエスト] --> B[auth:sanctumミドルウェア]
>     B --> C{トークン存在?}
>     C -->|Yes| D[トークン検証]
>     C -->|No| E[401 Unauthorized]
>     D -->|Valid| F[ルート処理へ]
>     D -->|Invalid| E
> ```
(AIのやつコピペしたけどqiitaってこんな図みたいの書けるんだ)

> Laravelのbreeze:installコマンドでapiオプションを選択すると、自動的にSanctumが設定されます。
> ```
> php artisan breeze:install api
> ```
> 
> ## 特徴的な違い：
> ### セッション認証（Web）:
> - クッキーベース
> - CSRF保護が必須
> - サーバーサイドでセッション管理
> ### Sanctumトークン認証（API）:
> - Bearer tokenベース
> - ステートレス
> - クライアントサイドでトークン管理

>なお、SPAでもSanctumのstateful機能を使うとセッションベースの認証も可能です。これはconfig/sanctum.phpのstateful配列で設定できます。
GithubとSourcetreeでgit管理をする方法

## まえがき
Xcodeでアプリを作成しているのですが、
修正した後に前の状態に戻したくなることが多々ありました。
Sourcetreeでの管理に慣れているので、題名のとおり
GithubとSourcetreeでgit管理をできるように設定したいと思います。

## 確認環境
XCode Version 15.4
MacOS Sonoma 14.4.1
Sourcetree 4.2.11(271)

## GithubとSourcetreeでgit管理をする
自分が設定した時と同じ順番で説明します。

### 1. Xcodeでプロジェクトを作成する
バージョン管理したいプロジェクトがXcodeで作成されていることを前提とします。
ここでは作成方法は割愛します。

### 2. XcodeでGitを有効化する
ターミナルを開いて以下のコマンドを実行します。
```
cd プロジェクトのフォルダ
git init
git add .
git commit -m "Initial commit"
```

### 3. SourceTreeのセットアップ
SourceTreeをインストールして起動します。
左上の「ローカル」を選択→「ディレクトリをスキャン」でローカルにあるプロジェクトを選択して追加します。

![スクリーンショット 2025-02-17 17.00.53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3805527/4a54d92f-d148-4629-a22d-d009ec368ca3.png)

![スクリーンショット 2025-02-17 17.02.11.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3805527/d878f889-2444-4815-8819-440152d612f2.png)

![スクリーンショット 2025-02-17 17.02.25.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3805527/41917595-a697-446c-93c9-a310aaf7bfa0.png)

反映したプロジェクトをクリックすると、
手順2.でコミットしたのでmainブランチが作成されていると思います。
![スクリーンショット 2025-02-17 17.04.37.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3805527/573b3d08-1a0a-4391-af42-8e6cfed7552f.png)

### 4. Githubでリポジトリを新規作成
右上の「New Repository」からリポジトリを作成します。
「Repository name」だけ入力して、
あとは特に触らずに右下の「Create Repository」をクリックして完了。

:::note info
公開したくない場合は「Private」にチェックを入れてください
:::

![スクリーンショット 2025-02-17 17.12.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3805527/08991661-ed86-4b4e-b755-1a1de6df8187.png)

![スクリーンショット 2025-02-17 17.15.13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3805527/81e98d84-53e6-4ac8-9b18-a34c8708ed33.png)


### 5. ローカルとリモートのリポジトリを連携
手順4.で作成したリモートのリポジトリとローカルのリポジトリを連携します。
< GitHubのリポジトリURL >はGithubで新規作成したリポジトリからコピーできます。

![スクリーンショット 2025-02-17 18.38.30.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3805527/f5092d83-09be-4299-af88-089b7f6def8b.png)

:::note info
Soucetreeでブランチ名がmainになっていない場合のみ「git branch -M main」を実行してください
:::

```
git remote add origin <GitHubのリポジトリURL>
git branch -M main　※必要な方のみ
git push -u origin main
```

### 6. Soucetreeにorigin/mainが追加されていればOK
origin/main（リモートのmainブランチ）がSoucetree上で表示されていれば設定は完了です。

![スクリーンショット 2025-02-17 19.06.15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3805527/d81257ba-0be4-4ec4-b464-aaa168d07bd2.png)


:::note info
表示されていない場合は、Soucetreeを再起動するか、フェッチしてください
:::

![スクリーンショット 2025-02-17 19.06.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3805527/10d60599-d64d-4a47-bca2-2ae58d52f105.png)


## あとがき
SoucetreeのUIが見やすくてGit管理しやすいので、今回導入してみました。
ターミナルからコマンドでgitの操作もしつつ、
ブランチの作業状況の確認はSoucetreeで行いたいと思います。
2/15 tecHub（LT&トークセッション＋懇親会）を開催しました！

![image1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3670233/277ce829-600a-4aa1-ac99-ccfc370adf23.png)

2025年もLT&トークセッションをやっていきます。
AIの発展が凄まじい、ここ数ヶ月。
今の時代の働き方を考える会になりました。

**目次▼**
<INS>[2025年2月のtecHubを開催しました！](#2025年2月のtechubを開催しました)</INS>
<INS>[キャリアを考えるトークセッション](#キャリアを考えるトークセッション)</INS>
<INS>[tecHubは毎月イベント開催しています！](#techubは毎月イベント開催しています)</INS>
<INS>[参加者の声](#参加者の声)</INS>
<INS>[Discord（tecHubコミュニティ）を運営しています](#discordtechubコミュニティを運営しています)</INS>
<INS>[次回の開催](#次回の開催)</INS>

<h3>2025年2月のtecHubを開催しました！</h3>
2/15にtecHubを水道橋で開催しました。
参加者は62名となり、大盛況でした。

日付：2/15(土) 14:00～17:00
場所：TIME SHARING 水道橋
参加者：62名
内容：LT&トークセッション、懇親会

<h3>キャリアを考えるトークセッション</h3>

![image2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3670233/20302ef2-517d-4732-8cda-23b15d5346ad.png)

前回好評だったトークセッションを今回も開催しました。
今回はゲストに、株式会社コスモレナの代表取締役：形部秀さんをお招きしました。

https://cosmorena.space/

会社員とフリーランスを経験し、法人化している方々の体験談は、非常に刺激になる会でした。
エンジニア・デザイナーとして、仕事・働き方の考え方が広がりました。

**次の4つのトークテーマからキャリアアップとフリーランスについてのトークで盛り上がりました。
将来のキャリアを考えるエンジニアなら、誰もが聞きたい内容でした。**

1.キャリアアップについて

2.収入アップについて

3.フリーランスのメリットデメリット

4.キャリアビジョンの描き方

**フリーランス・法人化して収入がアップした話、ただ作るだけでなく上流工程で必要とされるものを作る話、人との繋がりから来る仕事の話など、他では聞けない内容ばかりでした。**



<h3>tecHubは毎月イベント開催しています！</h3>

![image3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3670233/c3a48028-cf4c-40a4-99fa-4020e1df0bf8.png)

毎月60〜80名ほどの方が参加している人気のイベントです。

3ヶ月に1度：LT（ライトニングトーク）と懇親会の2部構成イベント
その他：リアルでIT交流会イベント

LT＋懇親会では、前半は「働き方」をテーマにLT・プレゼンテーションを、後半は懇親会で自由に交流の時間を設けています。
LTでは、外部スピーカーをゲストに招くこともあります。

懇親会にはスピーカーも参加し、発表内容をさらに掘り下げてディスカッションすることも可能です！
色々な方が自由に意見・情報交換をできる場となっています。

<h3>参加者の声</h3>
今回も幅広い分野のIT関係者が集まり、会社員からフリーランス、法人化まで様々なエンジニアが参加していました。

交流会では参加者一人一人の実体験から来る仕事の話で盛り上がり、参考になる話を聞ける時間でした。
「今後のキャリアをどうするか？」考えている話も多かったです。
幅広い分野と様々なキャリアの話は、異なる視点や考え方を知る機会になっているようでした。

参加者からは、
**「参加してよかった」
「転職やフリーランス転向などキャリアアップを考えるきっかけになった」
「自分にとって身近な体験談を聞くことができた」**
などの声をいただいています。

tecHubは、今後も毎月イベントを開催していきます。
<b>他にもITエンジニアがより活躍し、理想のキャリアを切り拓けるように、コミュニティを運営しています。</b>
会社員、フリーランス、法人の方向けに、オフラインコンテンツと人脈形成の機会を提供しています。

<h3>Discord（tecHubコミュニティ）を運営しています</h3>

■キャリアアップ
・キャリア相談／キャリアプランサポート
・スキルシート査定／レビュー
・転職・フリーランス転向サポート

■システム開発
・開発案件への参画
・スペシャリストに技術相談
・もくもく会などサブイベントへの参加

ぜひぜひDiscordから一緒に参加しましょう。
<h3>次回の開催</h3>

次回の開催は、以下の日程を予定しております。
日時：3/15(土) 14:00～16:30
場所：LIFORK 秋葉原
内容：IT交流会

来月のIT交流会とは別に、次のLT&トークセッション＋懇親会は5月に開催予定です。
決まり次第connpassに掲載しますので、ご確認ください。

https://tecworks.connpass.com/
箱庭でUnityを動かしてみる（3日目）

# 2025/02/17（3日目）実施内容
## シミュレータの構造の憶測
ディレクトリ構成やコード，READMEをパッと見た感じ，
- コントローラが `ros2/workspace/src/tb3/src/tb3ctrl.cpp` ，
- メッセージデータは，Unityのロボットの構成次第で，Unityから `Hakoniwa/Generate` で自動生成

-> まずはロボットの構成を考えるべし！

## ロボットの構成
やらせたい動作は何か？
### ロボットの行動 -> アクチュエータを組み込む
- 初期状態：静止
- t秒間静止
- 一定速度でt秒間前進
- 一定速度でt秒間後退
- 一定角速度でt秒間その場右回転
- 一定角速度でt秒間その場左回転
- 弾を1発射撃

### フローの条件 -> センサを組み込む
- 前方に相手がいるか
- 後方に相手がいるか
- 自HPがn%以下か

## 実装
Qiita記事やREADME
- https://qiita.com/kanetugu2018/items/28c137b78ec6ec74033a
- https://qiita.com/kanetugu2018/items/29ee98bc434191eee8f1#%E3%82%B7%E3%83%9F%E3%83%A5%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E5%AE%9F%E8%A1%8C%E6%96%B9%E6%B3%95
- https://github.com/toppers/hakoniwa-ros2sim/blob/main/README_jp.md

を参考にロボットを組み立てる
まずは移動が欲しいので，サーボモータ2組だけで実験...したが，衝突判定等の設定が分からず結局記事通りのロボットをとりあえず運用してみることに

-> なぜかインスタンスで呼ばれない...なんでだろう？
-> Configuratorシーンで `Hakoniwa/Generate` を実行しなければいけなかったのに，Toppers_Courseシーンで実行していたのが原因だった

### ロボットのコントローラが分からない！
`tb3ctrl.cpp` ， `DifferentialMotorController.cs` ， `WheelMotor.cs` の，なんとなく「ここだろ」と思ったパラメタをいじっても変化しなかったし，ロボットの向きをUnity Editor上で変えても，シミュレータ実行開始時に向きを戻された
-> コントローラはUnityではなく箱庭に置いてある（責務は箱庭に持たせている）と憶測しているが，間違っているのか...？
-> 箱庭入門会のアーカイブ
- https://www.youtube.com/playlist?list=PLvZDKbhDfoh2VO6nlYgKKQjdA74LcXw5I

を見直して勉強する（次回はここから）
rex0220 データ生成プラグイン テーブルの製品毎にレコード生成

[rex0220 データ生成プラグイン](https://qiita.com/rex0220/items/8e760adbfd69b9416b2d)で、テーブルの製品毎にレコード生成してみます。

# 概要

アプリAにあるテーブルの製品名毎にアプリBのレコードを生成します。
伝票番号 A000001 のテーブルにある 製品-A,B,C から、アプリBに製品-A,B,C のレコードを生成
データ生成プラグインのループ配列機能で、製品-A,B,C を処理します。

![2025-02-17_18h09_09.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100572/3d975fdb-333d-4875-bd9c-40949c496461.png)

# アプリ設定

アプリAをコピーしてアプリBを作成し、識別IDを追加します。

- アプリA

![2025-02-17_18h20_13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100572/0dbaaf09-5c38-4895-b2c2-905658b953f8.png)

- アプリB：　識別IDを追加

![2025-02-17_18h20_40.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100572/d995162b-d6e9-441a-a06d-887339a2b807.png)


# データ生成プラグイン設定

アプリAにデータ生成プラグイン設定を行います。

- アプリ：　出力先のアプリBを指定

![2025-02-17_18h22_30.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100572/b250d548-efad-4f6f-8ce4-792ae8478bb3.png)

- 対象アプリ条件：　アプリAのユニークキーである伝票番号を指定

![2025-02-17_18h22_46.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100572/e1e463e2-ac41-4f96-ac8a-624d6475ebc1.png)

- 設定項目：　
    - 自動設定でフィールドコードが同じものを設定
    - 識別IDをチェック
    - ループ配列で、製品名の配列（ユニーク）を指定
        - TDSIF(製品名,製品名)
            - 製品名が設定されている製品名の配列["製品-A","製品-B","製品-C"]を作成
            - ["製品-A","製品-B","製品-C"]の要素数分ループする
        - 変数名$val に、ループ毎に 製品-A, B, C が設定される

![2025-02-17_18h22_59.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100572/8800c695-e042-40b6-8729-c19b876ecb7b.png)

- テーブル項目：アプリAのテーブルからアプリBのテーブル
    - 自動設定でフィールドコードが同じものを設定
    - 出力条件：　製品名=$val
        - ループ変数$valと製品名が同じものを対象にする
            - 1ループ目:"製品-A"
            - 2ループ目:"製品-B"
            - 3ループ目:"製品-C"

![2025-02-17_18h23_16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100572/82629e87-9e97-4372-8ad8-c6114cec60cf.png)
@starting-style には詳細度が効く


　タイトルの通りです。

```CSS
.popover {
    width: 100px;
    height: 100px;
    transition: opacity 3s;
}

.popover1 {
    inset: 0 auto 0 0;

    &:popover-open {
        opacity: 1;

        @starting-style {
            opacity: 0;
        }
    }
}

.popover2 {
    inset: 0 0 0 auto;

    &:popover-open {
        opacity: 1;

        /* @starting-style {
            opacity: 0;
        } */
    }
}

@starting-style {
    :popover-open {
        opacity: 0;
    }
}
```


<p class="codepen" data-height="300" data-default-tab="result" data-slug-hash="MYWaJqR" data-pen-title="@starting-style と詳細度" data-user="lhankor_mhy" style="height: 300px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;">
  <span>See the Pen <a href="https://codepen.io/lhankor_mhy/pen/MYWaJqR">
  @starting-style と詳細度</a> by lhankor_mhy (<a href="https://codepen.io/lhankor_mhy">@lhankor_mhy</a>)
  on <a href="https://codepen.io">CodePen</a>.</span>
</p>
<script async src="https://public.codepenassets.com/embed/index.js"></script>


　`@starting-style`を入れ子式で書くとフェードインするのに、外部にまとめて書くとフェードインしなくなってしまって、なんでだろ、と小一時間悩んでしまいました。
　正解はこちらでした。

```CSS
@starting-style {
    .popover:popover-open {
        opacity: 0;
    }
}
```

　CSS入れ子の外に出してしまったので、詳細度が020から010に下がっていたんですね。メディアクエリでもたまにやってしまうやつでした。
　よく考えれば当たり前なんですが、うーん、悔しい。個人的には、starting状態に関するスタイルがstarting状態ではないスタイルに負ける、というのはかなり直観的ではなく感じるので、納得度の低い仕様だな、と思っています。まあ、疑似クラスとかではないから仕方ないのかもしれないけれど、負けると何かいい場面があるのかな。
　詳細度は悪い文明。
C#での丸め計算で0.445が0.44になるのはデフォルトがBanker's Rounding（銀行まるめ）だから

0.445を小数第２位で丸めるとき、次の結果は0.44になります。
```
Math.Round(0.445,2); //結果：0.44
```
これはC#が"最近接偶数丸め"（Bankers' Rounding） を採用しているからです。

具体的には...
・丸め対象の桁が５の場合、四捨五入の結果は偶数になるようにします。（結果的に五捨六入）
・0.445 → 0.44（0.44 が偶数なのでこちらに丸める）
・0.455 → 0.46（0.46 が偶数なのでこちらに丸める）

解決策：MidpointRounding.AwayFromZeroを使う

```
double value = 0.445;
double rounded = Math.Round(value, 2, MidpointRounding.AwayFromZero);
Console.WriteLine(rounded); // 出力: 0.45
```
でも、dubleだと結果が異なる場合がある。

この場合、decimalを使う
```
double value = 70.445;
double rounded = Math.Round(value, 2, MidpointRounding.AwayFromZero);
Console.WriteLine(rounded); // 出力: 70.44

decimal value = 70.445m;
decimal rounded = Math.Round(value, 2, MidpointRounding.AwayFromZero);
Console.WriteLine(rounded); // 出力: 70.45
```

このような現象が起こる原因は0.445は2進数で表すと無限になるため。
doubleが2進数の浮動小数点でdecimalが10進数の固定小数点なので、誤差を許容しないときはdecimalを使う。

例えば、計算速度は劣るが、計算誤差は桁あふれを除いて無いため金融ではこの型が用いられる。
[Rails] foreign_key が必要となるケース

## 概要

モデルの関連付けで `foreign_key` が必要となるケースについてまとめました。

## foreign_keyが必要となるケース

前提として、Railsの規約を理解していきましょう。
Rails は [CoC](https://qiita.com/Jackson123/items/71f987b7c57116bca12e) を設計思想として取り入れているため、基本的には以下のようなDB設計をするようにしてください。
  - RailsのActiveRecordはデフォルトで外部キーを`<関連モデル>_id`（例: `user_id`）として期待する  

<br>

それを踏まえて、以下のようなケースで、`foreign_key` が必要となります。
  - モデルで期待する外部キー名が、実際のデータベースのカラム名と異なる場合  
  - 例: `Post`モデルで`User`モデルと関連付く外部キーに **`author_id`** を使用する場合


## サンプルコード
  ```ruby
  class User < ApplicationRecord
    has_many :posts, foreign_key: :author_id, dependent: :destroy
  end

  class Post < ApplicationRecord
    belongs_to :user, foreign_key: :author_id
  end
  ```

参照元テーブルと、参照先テーブルで `foreign_key`の指定が必要になります。

## まとめ
以上です。
どなたかの参考になれば幸いです。
「SQLアンチパターン」の気づき（アプリケーション開発2）

## はじめに

こんにちは。小川です。
以前から気になっていた「SQLアンチパターン」という本を読みました。
とても良い本で今まで気づかずにやっていたことがSQLアンチパターンなんだと知ることができました。
勉強になったので、学んだことを言語化して量が多いのでいくつかの記事に分けて紹介していこうと思います。
今回は第Ⅳ部のアプリケーション開発のアンチパターンについて記載します。
この記事は[「SQLアンチパターン」の気づき（アプリケーション開発1）](https://qiita.com/pesysyon/items/cfdaa542249cac1f41a9)の続きになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3780649/edfcea05-fe0b-f2b8-c4c9-0881241eae1e.png)

## 20章.SQLインジェクション
#### SQLインジェクションとは
多くの場合、SQLはアプリケーションコードと連携して使われます。
SQLクエリを文字列として作成し、文字列内にアプリケーション変数を挿入する方法を動的SQLと呼びます。

SQLインジェクションとは、動的SQLの変数に悪意のある文字列を埋め込むことで、実際の使い方と異なる意図しない挙動をさせることです。

#### アンチパターン：未検証の入力をコードとして実行する
SQLインジェクションの典型例は、挿入された値によって、元のSQL文の実行に続けて別のSQL文も実行されるというものです。

```sql
例
-- $bugIdは変数
SELECT * FROM Bugs WHERE bug_id = $bugId

-- 変数$bugIdに123;DELETE FROM Bugsをセットする
SELECT * FROM Bugs WHERE bug_id = 123;DELETE FROM Bugs
```

このSQLではデータを取得していただけなのに、データが全て削除されてしまいます。
これは開発者の意図しない結果になっています。

#### デメリット
SQLが不当に実行されることにより、データの削除、更新、取得など開発者が意図しない挙動をします。
ユーザIDとパスワードが盗まれてしまうことや、大事な顧客データが削除されたり、個人情報の流出など引き起こされる可能性があります。

#### 解決策：誰も信用してはならない
SQLコードの安全性を保障するための唯一の方法などというものは存在しません。
そのため以下の技法習得し、状況に応じて適切に使い分けるようにしましょう。

1. 入力のフィルタリング
ユーザからの入力に危険な文字列が含まれていないかどうかを探るよりも、その入力にとって無効な文字を初めからすべて取り除くようにすべきです。
正規表現を用いて安全な文字列を判別し、無効な内容をフィルタリングする方法もあります。

1. 動的値のパラメータ化
動的な部分がシンプルであるならSQLから分離させるためにプリペアドステートメントを使用できます。
SQLから分離するとは、例えば変数に悪意のある文字列が渡ってきたとします。
    ```sql
    例
    SELECT * FROM Bugs WHERE bug_id = ?
    -- 入力値を全て文字列として置き換えることで悪意のあるSQLをそのまま実行しないようにする
    SELECT * FROM Bugs WHERE bug_id = '123;DELETE FROM Bugs'
    ```

1. ユーザの入力をコードから隔離する
エスケープやプリペアドステートメントはほとんどの場合に有効ですが、テーブル識別子、列識別子、SQL予約語には適用できません。
そういった場合はユーザの入力を直接SQLの変数に置き換えるのではなく、コードで制御する必要がある

## まとめ
今回は第Ⅳ部のアプリケーション開発のアンチパターンについて一部まとめてみました。
この記事はこの本を読んで、私がこういう理解をしましたということを言語化してみました。
とても勉強になる本なので皆様もぜひ読んでみてください。

以上、小川でした。
3週→3時間 ―― Trae を使って WeChat チャットログの自動出力を実現

https://www.trae.ai/?utm_source=content&utm_medium=qiita

Trae は ByteDance がリリースした AI IDE です

初めに

みなさん、はじめまして。前端開発者の r1ader です。
以前から WeChat チャットログを自動出力することを実現したかったのですが、WeChat の開発エコシステムの特性上、ずっと実行できませんでした。しかし、最近 Apple が "iPhone ミラージング" を支援し始めたため、チャットログを長画像や文字として自動出力することが可能になるのではないかと思い、実際に自分でコードを書いて試してみました。

しかし、前端開発者の私にとって Python のスキルはあまり高くありません。そして、文書、バージョン、依存関係などの問題で困っていました。殆ど数週間試行錯誤を繰り返しましたが、最終的に完成することはできませんでした。

そこで、ソーシャルメディア上で Trae という新しい製品を見つけたため、これを使ってみることにしました。Trae の支援を受けた結果、これまで困っていた問題がすべて解決され、わずか 3 時間でチャットログ自動出力のシステムが完成しました。


1. 苦戦した前半部

開発の初期段階では、技術的な問題と WeChat の開発エコシステムの関係で、すごく困難な状況でした。

WeChat は公式 API を提供していないため、反射学を使う必要があり、Python や iOS システムのミラージの技術を要する。

依存関係の問題、バージョン互換性の問題、文書の不足。

Python の Pillow ライブラリを使ってスクロールショットを出力するだけでも 2 週間かかった。

2. Trae との運命的な出会い

Trae を使用してみた結果、わずか 3 時間でチャットログの自動出力が完成し、長画像の作成や OCR 識別も済みました。その効率性の高さに驚きです。

3. AI との共働のコツ

AI を最大限利用するために、正しくニーズを伝えることが必要です。AI が想実現していることを詳しく伝えるには、要求を明確にすることが重要です。

Trae のおかげで、我々はより効率的に開発を進めることができます。ぜひ一度試してみてください。
Gitの直近コミットの作業者の名義を改変する

会社のパソコンが壊れてしまって、急遽貸与してもらったパソコンで作業することになった。

ら、他人のノートパソコンを使っていたので、コミットログが他人の物になってしまった。ほんとに困った。
幸い、直前のもの３つ分を何とかすればよかった。

Gitのコミット履歴を修正して、**直近3つのコミットの名義を変更する手順**　をメモしておく。

# Gitの直近コミット名義を変更する

まず、Git のコンフィグを設定し直す。

## 自分の名義を設定する

```
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"
```


## インタラクティブリベースを開始
直近3つのコミットを修正するため、以下のコマンドを実行。
3という部分は適宜、直したいコミットの数に応じて変更すること。

```sh
git rebase -i HEAD~3
```

以下のようなログのエディタが開いた。
（内容は、改変してある）

```
pick a1b2c3d 修正：ログ出力のフォーマットを統一
pick e4f5g6h 追加：CLIのオプションを改善
pick i7j8k9l 変更：APIのリクエストパラメータを整理
```

⬇ すべての pick を edit に変更

```
edit a1b2c3d 修正：ログ出力のフォーマットを統一
edit e4f5g6h 追加：CLIのオプションを改善
edit i7j8k9l 変更：APIのリクエストパラメータを整理
```

編集が終わったら、保存してエディタを閉じる。

### 1つ目のコミットの修正
1つ目のコミットの修正モードになっているので、以下のコマンドを実行：

```sh
git commit --amend --author="Your Name <your.email@example.com>"
※ Your Name <your.email@example.com> をあなたの名前とメールアドレス に置き換えてください。
```

できたら、次へ。

```sh
git rebase --continue
```

それでまた、名義を書き換える。

```sh
git commit --amend --author="Your Name <your.email@example.com>"
```

できたら、次へ。

```sh
git rebase --continue
```

全部終わるまで、繰り返す。

4. 修正をリモートリポジトリに反映
すべての修正が完了したら、ローカルの履歴をリモートに反映。

```
git push --force
```
⚠️ --force を使うので、チームで作業している場合は影響が出る可能性があるため注意！

最後に、修正が適用されているか確認。

```
git log --oneline --author="Your Name"
```

正しく名義が変更されていることを確認できたら完了。
（とはいえ、きちんと書き換えられているかどうかの確認は、VSCode上の拡張機能で見て、OKとした。）

### Vimで焦った

きちんと編集画面が開いたと思ったが、どうあがいてもpickをeditにできない。
ものすごく焦ったが、Vimで開いているためだった。
Vimだと、iを押すと編集モードになる。

Vimやだよ～、気持ち悪いよ～。えーん。
パソコンを貸してもらってる以上、文句言えねぇ……。
えーん……。nanoがいいよ～。
（nanoで編集すりゃいいとおもいｍ）

### おわりに

（企業秘密を含まないようなメモの場合、）オンラインで適当に投稿しておくと、パソコンが壊れても掘り出せて何とかなるようである。ので、こうして残しておくと役に立つっぽいな。
私はまたあと何回かこのやらかしをする予定なので、記事も書いておいたのだった。

あーあー。歴戦の怒られ、やらかしメモが……。全部飛んでしまった……。
【初心者向け】ファイルシステムのベンチマーク【５分で読める】

# ファイルシステムのベンチマーク

理解のために小咄形式でまとめました。

:::note info
システムパフォーマンス関連記事の目次
- [【初心者向け】システムパフォーマンス関連まとめ【それぞれ５分で読める】](https://qiita.com/nouernet/items/d3efe67e0f52a92e061d)
:::

**登場人物**
- **太郎（後輩）**：入社1年目の若手エンジニア。
- **花子（先輩）**：システムエンジニア歴3年の先輩。

**場面：オフィスの開発ルーム**
*太郎が `ファイルシステムのパフォーマンス測定` に関する資料を見ながら、花子に質問する。*

**太郎**：「花子先輩、`ファイルシステムのパフォーマンスを評価する実験手法` について調べてるんですが、 `どのツールをどう使うのか` がよく分かりません…。」

**花子**：「いい質問ね！ `ファイルシステムの実験` には、 `パフォーマンスを評価するための 3 つの方法` があるの。それぞれ詳しく説明するわね。」

---

### **ファイルシステムのベンチマーク**
**花子**：「`ファイルシステムのベンチマーク測定` には、 `3 つの主要な手法` があるの。」

1. **アドホックテスト**
2. **マイクロベンチマークツール**
3. **キャッシュのフラッシュ**

---

### **1. アドホックテスト**
**花子**：「`アドホックテスト` とは、 `手軽に I/O のパフォーマンスを評価する方法` よ。」

- **単純な `dd` コマンドを使って I/O 性能を計測**
- **`ls -lR` でディレクトリ構造のスキャン速度を評価**
- **`time cp` を使ってファイルコピーの時間を測定**

「例えば `お湯を沸かすのに、簡単に手をかざして温度を測る` のと同じで、 `ざっくりとしたテスト` ね。」

**太郎**：「なるほど、 `細かい分析はできなくても、ざっくりと I/O パフォーマンスを把握できる` んですね！」

---

### **2. マイクロベンチマークツール**
**花子**：「`マイクロベンチマークツール` は、 `より詳細な I/O パフォーマンスを測定するための専用ツール` よ。」

- **Bonnie, Bonnie++** → `単純な I/O ワークロードの評価に適している。`
- **iozone** → `シーケンシャル I/O と ランダム I/O の両方を測定可能。`
- **fio** → `最も推奨されるツールで、複雑な I/O ワークロードのシミュレーションが可能。`
- **FileBench** → `実際のアプリケーションワークロードを模倣してテスト可能。`

「例えば `車の燃費テスト` みたいなもので、 `実際にどのくらいの負荷でどれくらいのパフォーマンスが出るのかを評価する` のよ。」

**太郎**：「fio が推奨されてるんですね！ `実環境に近い I/O 負荷テスト` をするのに便利そうです！」

---

### **3. キャッシュのフラッシュ**
**花子**：「`キャッシュのフラッシュ` は、 `キャッシュが I/O 測定に影響を与えないようにするための手法` よ。」

- **`sync` コマンド** を実行して、 `ディスクに書き込まれていないデータをフラッシュする。`
- **`echo 3 > /proc/sys/vm/drop_caches`** を実行して、 `キャッシュをクリアする。`
- **システムの再起動** を行い、 `キャッシュの影響を完全に排除する。`

「これは `水泳のタイム測定をする前に、水中の抵抗を一定にする` みたいなもので、 `正確な測定をするための準備` なのよ。」

**太郎**：「確かに！ `キャッシュの影響をなくして、純粋なディスク I/O の性能を測定できる` んですね！」

---

**花子**：「これらの `ファイルシステムの実験手法` を `コーヒーマシンの性能テスト` に例えると、こんな感じね。」

1. **アドホックテスト** → `一杯のコーヒーを淹れる時間をざっくり測る`
2. **マイクロベンチマークツール** → `異なる豆や抽出方法で細かく淹れ時間や温度を測定`
3. **キャッシュのフラッシュ** → `フィルターをリセットして、影響を取り除いた状態でテスト`

**太郎**：「なるほど！ `実験手法を組み合わせることで、より正確な I/O パフォーマンスの評価ができる` んですね！」

---

### **まとめ**
**花子**：「ファイルシステムの `実験手法` を活用すれば、 `I/O パフォーマンスの問題を的確に把握し、最適化の方針を決めることができる` わ。」

**太郎**：「ありがとうございます！ `fio` を使って `SSD と HDD の I/O パフォーマンスを比較するベンチマーク測定` をやってみます！」

# 参考リンク

システムパフォーマンス関連記事の目次

- [【初心者向け】システムパフォーマンス関連まとめ【それぞれ５分で読める】](https://qiita.com/nouernet/items/d3efe67e0f52a92e061d)

システムパフォーマンス関連記事は、以下の書籍を参考に記述しています。

- [［改訂新版］プロのためのLinuxシステム構築・運用技術](https://www.amazon.co.jp/dp/B01LZURAPK)
- [改訂2版 ネットワークエンジニアの教科書](https://www.amazon.co.jp/dp/B07NXQ4TDV)
- [絵で見てわかるシステムパフォーマンスの仕組み](https://www.amazon.co.jp/dp/B00LHFOTF4)
- [詳解 システム・パフォーマンス 第2版](https://www.oreilly.co.jp/books/9784814400072/)
- [入門 モダンLinux](https://www.oreilly.co.jp/books/9784814400218/)
- [Linuxシステム管理](https://www.oreilly.co.jp/books/9784873113463/)
【Angular】お天気アプリを開発してみた ‐ 開発備忘録 #1


こんにちは、SDの伊藤です。
私がAngularについて学ぶ過程で、理解を深めるために天気情報アプリを作成しました。（ちょっとした機能を作成してみたぐらいのニュアンスですが…）
今回、その経験を整理し、備忘録として残しておこうと思います。

# 1.学習目標
以下、２項目を今回の学習目標として設定しました。

**1)HTTPクライアントでAPIからデータ取得**
* Angular の HttpClient を使って API からデータを取得する方法

**2)RxJSのObservableの基本的な使い方**
* Observable.subscribe() の next / error の役割

# 2.開発手順
開発手順を以下の通りに組んでみました。

1) APIデータ取得の基本（HttpClientModule を使った API 通信）	
2) RxJSのsubscribe()の仕組み( RxJS の Observable で非同期データ取得)	
3) エラーハンドリングの実装	
4) LocalStorage を活用した検索履歴の保存	
5) Chart.js を使った天気データの可視化	

# 3.開発環境
今回天気アプリを作成するにあたって必要なパッケージと使用するツールのバージョンは、以下の通りとなります。

Angular CLI: 19.0.6
Node: 22.12.0
開発用エディタ：Visual Studio Code

※Angular CLIとNode.jsのインストールは割愛

必要なパッケージのインストール
天気データの可視化のためのchart.jsをインストールします。
```
npm install chart.js ngx-chartjs
```

# 4.ディレクトリ構成と状態遷移
今回作成する天気情報アプリ(weather-app)のディレクトリ構成は以下の通りとなります。
主に編集するファイルは太字で示しました。

weather-app/                # プロジェクトルート
│── src/
│   ├── app/
│   │   ├── components/ 　# UIコンポーネント
│   │   │   ├── weather/ 　# 天気検索フォーム・天気情報表示
│   │   │   │   ├── **weather.component.ts**        # 天気コンポーネント本体
│   │   │   │   ├── **weather.component.html**      # 天気情報のテンプレート
│   │   │   │   ├── **weather.component.css**       # スタイルシート
│   │   │   │   ├── weather.component.spec.ts   # 天気コンポーネントのテスト
│   │   │   ├── weather-chart/     # 天気データのグラフ表示
│   │   │   │   ├── weather-chart.component.ts        # グラフコンポーネント
│   │   │   │   ├── weather-chart.component.html      # グラフのテンプレート
│   │   │   │   ├── weather-chart.component.css       # スタイルシート
│   │   │   │   ├── weather-chart.component.spec.ts   # グラフコンポーネントのテスト
│   │   ├── services/           # サービス（API通信）
│   │   │   ├── **weather.service.ts**        # 天気APIのデータ取得処理
│   │   │   ├── weather.service.spec.ts   # WeatherServiceのテスト
│   │   ├── **app.component.ts**              # メインコンポーネント
│   │   ├── **app.component.html**            # メインテンプレート
│   │   ├── **app.component.css**             # メインスタイル
│   │   ├── app.component.spec.ts         # AppComponentのテスト
│   │   ├── app.routes.ts                 # ルーティング設定
│   ├── assets/                           # 静的ファイル（アイコン、画像など）
│   ├── environments/
│   │   ├── environment.ts                # 環境変数（APIキーの管理）
│   │   ├── environment.prod.ts           # 本番環境用設定
│   ├── **index.html**                        # アプリのエントリーポイント
│   ├── main.ts                           # アプリの起動エントリーファイル
│   ├── styles.css                        # グローバルスタイル
│── angular.json                          # Angular 設定ファイル
│── package.json                          # パッケージ管理ファイル
│── tsconfig.json                         # TypeScript 設定ファイル

また、下図は天気情報アプリの状態遷移です。

TOP画面
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3991405/3b44675f-8ac3-42ce-84d5-ed8e3a2d8c37.png) 

入力フォームに「東京都」と入力し、検索した結果
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3991405/0ecb2288-fa40-44d5-8b06-1b840b14810e.png)

以上が、天気情報アプリを作成するための準備となります。
次回の #2 では、具体的なソースコードに入っていきます。
【超悲報】Excel の内容を DB に取り込みたいのに、スペースと改行のせいで取り込めないよぉ

## Excelの内容をRubyXLを使用して、DBに簡単に取り込めたら便利だな...
結果↓
>
>
>　/n/n/n/n/n/n/n(takusannospace)     相手先名：ryoryotarosu      /n/n/n/n/n/n (takusannospace) 
>
>    

絶望しました。世の中はこんなに腐っていたなんて...

もちろんこのままでは取り込めないので、何とかして

>相手先名：ryoryotarosu

のように修正したいわけです。

## 逃げ続けた正規表現と向き合う
正規表現って記号がいっぱいあってよくわからないので逃げていましたが、先輩に「正規表現で直しておいてね☆彡」と言われたので血涙流しながら、正規表現と向き合いました。

## Rubularを使う（https://rubular.com/）
上記サイトを使用して、余計な括弧や改行を指定することで、正規表現が正しいかどうかを判断します。

こうして出来上がった正規表現がこちら
>x.gsub(/[\r\n]/,"").gsub(/\A( |　)+|( |　)+\z/, "")

これで、全角と半角のスペース、改行コードを文頭と文末からとることに成功しました。

## 追記（2025/02/18）
上記の書き方では、ダメ見たいです..。また時間があるときにコメントを参照して正しい正規表現を記述したいと思います。明日やる、いつかやる。

ちなみに、最初、先輩にレビューしてもらったときに私が使用していた strip （Ruby のメソッド）ニキは全く役に立たなかったです。（strip では全角スペースを削除することができない）

# 正規表現頑張ろうね、あたい
Vue.js 自分用Q&A


<details><summary>Option API VS Composition API</summary>

Options API
data、methods、computed などがそれぞれ別々のオプションとして記述される。
ロジックの再利用は難しい場合があり、コンポーネントが大きくなると管理が難しくなることがある。
定型的な記述が必要で、決まった構造に従う。
Options APIは、シンプルで理解しやすく、小規模なプロジェクトやコンポーネントに適しています。


Composition API
ロジックは setup 関数内で記述され、ref や reactive などを使って状態管理を行う。
複数のコンポーネントで同じロジックを簡単に再利用でき、ロジックを関数単位で整理できるため、管理しやすい。
より自由度が高く、複雑なロジックを扱いやすい。
柔軟で再利用性が高く、大規模なアプリケーションや複雑なロジックを扱う際に有利です。

</details>



<details><summary>increment vs decrement</summary>

i++ を increment
i-- を decrement
と呼ぶことを知った

javascriptでは、呼び方を知っている事は当たり前の事らしい
</details>
仮想環境で開発していたら、github の差分ですべてのファイルが一行ずれちゃう泣

## Winパソコンのターミナルで git 操作、 Linux の仮想環境で開発をしていたら、差分が一行ずれて泣いた
解決策
> sed -i 's/\r//' <ファイル名>

あと、普通にこれを未然に防ぐためにもリナックスなどの環境で作業する際は、WSLなどをインストールしてそっちで、git clone しましょうね。
【初心者向け】ファイルシステムのパフォーマンス調査の方法論（メソドロジ）メモ

# ファイルシステムのパフォーマンス調査の方法論（メソドロジ）メモ

**ファイルシステムのパフォーマンス分析と最適化を行う際には、体系的な方法論（メソドロジ）が重要です。以下の 8 つの手順に沿って分析を進めることで、ボトルネックを特定し、効果的なチューニングが可能になります。**

---

### **🔍 1. ディスク分析**
- **目的**: ディスクの物理的な性能や使用状況を把握する。
- **手法**:
  - `hdparm` や `fio` で **ディスクの速度測定**
  - `df` や `iostat` で **ストレージの使用状況を確認**
  - **ストレージの種類（HDD, SSD, NVMe）を考慮する**
- **ポイント**: まず、ハードウェアの制約を知ることが大切。

---

### **⏳ 2. レイテンシ分析**
- **目的**: I/O の遅延（レイテンシ）の原因を特定する。
- **手法**:
  - `iostat -x` で **I/O 待ち時間を分析**
  - `latencytop` で **アプリケーションの I/O 遅延を可視化**
  - `strace` で **システムコールの遅延をトレース**
- **ポイント**: 遅延が発生する場所を突き止めることが重要。

---

### **📊 3. ワークロードの特性の把握**
- **目的**: 実際の I/O パターンを分析し、最適な設定を考える。
- **手法**:
  - `blktrace` で **ディスク I/O の詳細なトレース**
  - `iotop` で **I/O を大量に消費するプロセスを特定**
  - **ランダム I/O vs シーケンシャル I/O のバランスを評価**
- **ポイント**: どのタイプの I/O が多いかを理解し、それに適した最適化を行う。

---

### **📈 4. パフォーマンスモニタリング**
- **目的**: システム全体のリソース使用状況をリアルタイムで監視する。
- **手法**:
  - `top`, `htop` で **CPU・メモリ・I/O の状態を確認**
  - `sar` で **長期的なトレンドを分析**
  - `dstat` で **リアルタイムのリソース使用状況を可視化**
- **ポイント**: 常にシステムの動作を把握し、異常を早期に発見する。

---

### **⚙ 5. 静的パフォーマンスチューニング**
- **目的**: 事前にシステム設定を最適化して、I/O を効率化する。
- **手法**:
  - **マウントオプションの調整** (`noatime`, `data=writeback`)
  - **I/O スケジューラの選択** (`mq-deadline`, `none`)
  - **スワップ設定の最適化** (`swappiness` を調整)
- **ポイント**: 事前に適切な設定をすることで、無駄な I/O を減らせる。

---

### **🛠 6. キャッシュのチューニング**
- **目的**: キャッシュを適切に活用し、I/O 負荷を減らす。
- **手法**:
  - **ページキャッシュの利用状況を確認** (`free -m`)
  - **`drop_caches` を使ってキャッシュをクリア** (`echo 3 > /proc/sys/vm/drop_caches`)
  - **適切なバッファサイズを設定**
- **ポイント**: キャッシュをうまく使えば、I/O のボトルネックを回避できる。

---

### **🔄 7. ワークロードの分離**
- **目的**: 異なる種類の I/O 負荷を適切に分けて処理する。
- **手法**:
  - **データベースのログとデータを別のディスクに配置**
  - **バックアップ処理と通常業務の I/O を分離**
  - **SSD と HDD を適切に使い分ける**
- **ポイント**: 一つのストレージにすべての負荷を集中させないことが重要。

---

### **📏 8. マイクロベンチマーキング**
- **目的**: 実際のパフォーマンスを測定し、最適化の効果を確認する。
- **手法**:
  - `fio` で **シーケンシャル・ランダム I/O の測定**
  - `bonnie++` で **ファイルシステムの総合的なベンチマーク**
  - `sysbench` で **ディスク負荷テスト**
- **ポイント**: 設定変更の前後でパフォーマンスを測定し、最適化の効果を確認する。

---

### **🎯 まとめ**
- **ファイルシステムのチューニングは、計画的に行うことが重要。**
- **まずは「どこが遅いのか？」を分析し、最適なアプローチを選択する。**
- **静的なチューニングだけでなく、キャッシュやワークロードの調整も重要。**
- **最終的には、ベンチマークで効果を確認しながら最適化を進める。**

---

### **💡 実世界の例え**
**「ファイルシステムのチューニングを飲食店の効率化に例えると？」**
1. **ディスク分析** → `店の広さや席数をチェック`
2. **レイテンシ分析** → `オーダーから提供までの時間を測る`
3. **ワークロードの把握** → `ピーク時間帯の混雑状況を分析`
4. **パフォーマンスモニタリング** → `売上データや在庫状況をチェック`
5. **静的チューニング** → `メニューやレジの配置を最適化`
6. **キャッシュの活用** → `よく出る料理の仕込みを事前に用意`
7. **ワークロードの分離** → `注文と会計を別担当にする`
8. **マイクロベンチマーキング** → `試食会を開いて提供スピードを測る`

---

# 参考リンク

システムパフォーマンス関連記事の目次

- [【初心者向け】システムパフォーマンス関連まとめ【それぞれ５分で読める】](https://qiita.com/nouernet/items/d3efe67e0f52a92e061d)

システムパフォーマンス関連記事は、以下の書籍を参考に記述しています。

- [［改訂新版］プロのためのLinuxシステム構築・運用技術](https://www.amazon.co.jp/dp/B01LZURAPK)
- [改訂2版 ネットワークエンジニアの教科書](https://www.amazon.co.jp/dp/B07NXQ4TDV)
- [絵で見てわかるシステムパフォーマンスの仕組み](https://www.amazon.co.jp/dp/B00LHFOTF4)
- [詳解 システム・パフォーマンス 第2版](https://www.oreilly.co.jp/books/9784814400072/)
- [入門 モダンLinux](https://www.oreilly.co.jp/books/9784814400218/)
- [Linuxシステム管理](https://www.oreilly.co.jp/books/9784873113463/)
変更されたファイル一覧を取得する

# 特定のコミットで変更されたファイル一覧を取得する

特定のコミットで変更されたファイルの情報だけを取得したい場合は、`git show`コマンドの`--name-only`オプションを利用します。

```
git show --name-only <hash>
```

## 実行例

```
C:\myrepository>git show --name-only c19fd19df1c4a92d359e016ea92440224f7cc36d
commit c19fd19df1c4a92d359e016ea92440224f7cc36d
Author: hajime.nakamura <h.nakamura0903@gmail.com>
Date:   Thu Oct 10 20:42:51 2024 +0900

    FIX TYPO

path/to/aaa.txt
path/to/bbb.txt
path/to/ccc.txt
```

---

# 特定のコミットで変更されたファイルとそのステータスを取得する

ファイル名だけでなく、追加、更新、削除などのステータスも確認したい場合は、`--name-only`ではなく`--name-status`オプションを利用します。

```
git show --name-status <hash>
```

## 実行例

```
C:\myrepository>git show --name-status c19fd19df1c4a92d359e016ea92440224f7cc36d
commit c19fd19df1c4a92d359e016ea92440224f7cc36d
Author: hajime.nakamura <h.nakamura0903@gmail.com>
Date:   Thu Oct 10 20:42:51 2024 +0900

    FIX TYPO

A    path/to/aaa.txt
D    path/to/bbb.txt
M    path/to/ccc.txt
```

# 特定のマージコミットで変更されたファイル一覧を取得する

マージコミットを通常のコミットと同様に扱いたい場合は、`-m`オプションを使用します。このオプションは、`--name-status`オプションと併用できます。

```
git show -m --name-only <hash>
```

## 実行例

```
C:\myrepository>git show -m --name-only 55e860d0aaba7d970e70e47f5720af621c64bd60
commit 55e860d0aaba7d970e70e47f5720af621c64bd60 (from 269cff0456c1f17a0278caf80e16926e95e7a861) (origin/develop, origin/HEAD, develop)
Merge: 269cff0 1b15adb
Author: hajime.nakamura <h.nakamura0903@gmail.com>
Date:   Tue Oct 22 02:02:19 2024 +0000

    Merge branch 'feature-fix-typo' into 'develop'

    FIX TYPO

    See merge request hajime/nakamura/myrepository!27

path/to/aaa.txt
path/to/bbb.txt
path/to/ccc.txt
```

# 2つのコミット間で追加・修正されたファイル一覧を取得する

これまでの説明は単独のコミットに関するものでしたが、2つのコミット間で変更されたファイルを確認したい場合は、`git show`ではなく`git diff`コマンドを使用します。`git diff`コマンドは、`-m`オプションや`--name-status`オプションと組み合わせて利用することもできます。

```
git diff --name-only <hash1> <hash2>
```

## 実行例

```
C:\myrepository>git diff --name-only 98f72ce386198e7df4adde1ec9afa8414622fcbd 85f9d458bf396fc2e442e60685d993dea607b058

path/to/aaa.txt
path/to/bbb.txt
path/to/ccc.txt
```


# 環境情報

```
C:\myrepository>git --version
git version 2.41.0.windows.1
```
(QA) Copilotキーのせいで右Ctrlキーが無くなって5250画面の実行キーが入力できない件

というキャッチーな？ｗご質問がございまして、、

### 参考wikipedia Copilotキー

https://ja.wikipedia.org/wiki/Copilot%E3%82%AD%E3%83%BC

マイクロソフトさんのIBM i　イヂメか？ｗ　とのご質問でしたが(^^;、大MS様がそんなことするわけもなく(^^;
ホスト系エミュレーター使わないユーザーさんはほぼ使ってないキーではないでしょうか・・？

※ところでおいらのThinkPad も次買い替えたらコパイロット・キーになるのだろうか・・選べるようにしてほしいなあ…(^^;

## ACSでEnterキーを入力する代案です。

### 案① ACSのキーパッドを表示して実行する

ACSのメニューからキーパッドの表示　というのをチェックすると下記のように Enter キーボタンが場面表示されるのでこれをマウスクリックする。

![thumbnail_image001.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1011394/ce9c1dcb-07ed-42a1-91b6-137c0c706562.png)

### 案②　ACSのキーマップ変更

ACSでキーボード機能の再マップというアイコンを押して、
![thumbnail_image002.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1011394/a24645e2-a412-4027-adc4-a11669d937f1.png)

 
下記の画面から、カテゴリーをホスト機能　を選択して、　実行　キー　その他のマップを変更できます。

![thumbnail_image003.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1011394/724075e1-f07f-4af4-84e1-d3909c5a0efe.png)
【初心者向け】ファイルシステムの動作モデル【５分で読める】

# ファイルシステムのモデル

理解のために小咄形式でまとめました。

:::note info
システムパフォーマンス関連記事の目次
- [【初心者向け】システムパフォーマンス関連まとめ【それぞれ５分で読める】](https://qiita.com/nouernet/items/d3efe67e0f52a92e061d)
:::

**登場人物**
- **太郎（後輩）**：入社1年目の若手エンジニア。
- **花子（先輩）**：システムエンジニア歴3年の先輩。

**場面：オフィスの会議室**
*太郎が `ファイルシステムの動作モデル` に関する資料を見ながら、花子に質問する。*

**太郎**：「花子先輩、`ファイルシステムの動作モデル` について調べているんですが、 `具体的にどのような構成になっているのか` がいまいちピンときません。」

**花子**：「いい質問ね！ `ファイルシステムのパフォーマンス` を理解するためには、 `どうやってデータがやり取りされるのか` という `モデル` を押さえておくことが重要よ。 `ファイルシステムの基本的な 3 つの要素` を説明するわね。」

---

### **ファイルシステムの動作モデル**
**花子**：「ファイルシステムには、 `基本的な 3 つのコンポーネント` があるの。」

1. **ファイルシステムインターフェイス**
2. **ファイルシステムキャッシュ**
3. **2次キャッシュ**

---

#### **1. ファイルシステムインターフェイス**
**花子**：「`ファイルシステムインターフェイス` は、 `アプリケーションとファイルシステムの間のやり取りの仕組み` のことよ。」

- **アプリケーション** → `ファイルを開く、読む、書く、閉じる`
- **カーネル** → `要求を処理し、適切なストレージデバイスへ指示`
- **ストレージデバイス** → `物理ディスクへのアクセス（HDD、SSD など）`

「この関係を `レストランのオーダーシステム` に例えると、 `お客さん（アプリケーション）` が `ウェイター（カーネル）` に注文を伝えて、 `シェフ（ディスク）` が料理を作るのと同じね。」

**太郎**：「なるほど、 `アプリケーションが直接ディスクにアクセスするわけじゃなくて、間にカーネルが介在してる` んですね！」

---

#### **2. ファイルシステムキャッシュ**
**花子**：「`ファイルシステムキャッシュ` は、 `頻繁にアクセスするデータを一時的にメモリに保存` する仕組みよ。」

- **リードキャッシュ（Read Cache）**: よく使うデータをキャッシュし、高速な再利用を可能にする。
- **ライトキャッシュ（Write Cache）**: データを書き込む前に一時的にキャッシュし、後でまとめてディスクに書き込む。

「たとえば、 `本棚に並べられた参考書` みたいなもので、 `毎回図書館に行かなくても、よく使う本が手元にあると素早く読める` のと同じよ。」

**太郎**：「ってことは、 `キャッシュをうまく活用すると I/O の負荷を減らせる` んですね！」

---

#### **3. 2次キャッシュ**
**花子**：「`2次キャッシュ` は、 `OS のキャッシュとは別に、ストレージデバイスや専用ハードウェアで追加されるキャッシュ` のことよ。」

- **HDD のキャッシュ** → `ディスク内部のバッファ（数 MB～数 GB）`
- **SSD のキャッシュ** → `フラッシュメモリ上のキャッシュ`
- **RAID コントローラのキャッシュ** → `RAID カード上に搭載されたキャッシュメモリ`

「これを `コンビニの冷蔵庫` に例えると分かりやすいわ。 `家の冷蔵庫（OSのキャッシュ）` にない商品でも、 `コンビニの冷蔵庫（2次キャッシュ）` にあれば、すぐに取り出せるのと同じよ。」

**太郎**：「なるほど、 `複数のキャッシュのレイヤー` があることで、 `ストレージアクセスの高速化` ができるんですね！」

---

**花子**：「これらの `ファイルシステムの動作モデル` を `会社の文書管理システム` に例えると、こんな感じね。」

1. **ファイルシステムインターフェイス** → `社員が会社の書類を閲覧・編集するシステム`
2. **ファイルシステムキャッシュ** → `よく使う書類をデスクに置いておく`
3. **2次キャッシュ** → `オフィスの倉庫にある古い書類のストック`

**太郎**：「なるほど！ `キャッシュを適切に活用すれば、無駄な I/O を減らせる` ってことですね！」

---

### **まとめ**
**花子**：「ファイルシステムの `3 つの要素` を理解すると、 `なぜ I/O が遅くなるのか` や `どこを改善すればよいのか` が見えてくるわ。」

**太郎**：「ありがとうございます！ `ファイルシステムキャッシュの効果` を確認するために、 `free` コマンドで `メモリのキャッシュ状況` を調べてみます！」 

# 参考リンク

システムパフォーマンス関連記事の目次

- [【初心者向け】システムパフォーマンス関連まとめ【それぞれ５分で読める】](https://qiita.com/nouernet/items/d3efe67e0f52a92e061d)

システムパフォーマンス関連記事は、以下の書籍を参考に記述しています。

- [［改訂新版］プロのためのLinuxシステム構築・運用技術](https://www.amazon.co.jp/dp/B01LZURAPK)
- [改訂2版 ネットワークエンジニアの教科書](https://www.amazon.co.jp/dp/B07NXQ4TDV)
- [絵で見てわかるシステムパフォーマンスの仕組み](https://www.amazon.co.jp/dp/B00LHFOTF4)
- [詳解 システム・パフォーマンス 第2版](https://www.oreilly.co.jp/books/9784814400072/)
- [入門 モダンLinux](https://www.oreilly.co.jp/books/9784814400218/)
- [Linuxシステム管理](https://www.oreilly.co.jp/books/9784873113463/)
【RAG】開発における苦労した点

# はじめに
同じAIエンジニアの友人より、RAG開発に関する苦労した点を聞かれたので整理してみることにしました。

# こんな人におすすめ
・これからRAGにかかわる予定の方
・AIエンジニアの方

# 開発における段階
RAGの開発には、いくつかの段階が存在します。

1．セマンティック検索用資料を取込
2．プロンプトをベクトル化して、1をセマンティック検索
3．検索結果をLLMへ提供して自然言語を取得
4．取得した情報を画面へ展開

大きくはこの4つです。
サービスとして追加で機能を実装する場合を除くと、これでRAGは完成します。
では、この4つの中で苦労する点を順に説明します。

# セマンティック検索用資料を取込
取込が難しいというよりも、取込後の検索で想定しているものが抽出できるように取り込むにはどのようにしたらよいか、という点を悩む段階です。

ここで何度もやり直す点としては、**チャンク数**です。
チャンク数は、取り込む資料のテキスト情報をどの程度のサイズでデータベースに保存するかの値です。

この値が大きすぎると、意味検索にヒットしづらくなりますが、その分1度で検索時に抽出できる情報が多くなります。
逆に小さいと、意味検索にヒットしやすくなりますが、小さすぎると意味として成り立たず抽出時の情報量も少なくなります。

これらの状況を加味しながら、適切なチャンク数を探っていくことが大切です。
また、取り込む資料について不要な情報は極力削除したほうがいいので、
ヘッダー、フッター、目次削除は基本必須です。

# プロンプトをベクトル化して、取り込んだ資料をセマンティック検索
無事に資料を取り込んだ後の段階です。

ここで困ることは、セマンティック検索でどのようにして、目的の情報を抽出するのかにあります。
コサイン類似度で検索が行われるのですが、これがまた厄介です。

それは、数字さえ近ければ一致するものがうえに上がってしまうからです。
例えば、うえの不要な文章の削除が甘いと、文章ともいえないものがこのタイミングで検索順位上位となる可能性もあります。

その為、ここでやることとして、1つセマンティック検索を行うことですが、必ず**リランキング**も実施するようにしてください。

実装する手法として、
①CohereのAPI連携による実施
②Langchainでの実装
の方法があります。

私は①の手法をとっており、おすすめしております。

2025年2月現在で、V3.5が登場しており、かなり精度が高くお勧めです。
体感、リランキングで10位くらいまで抽出すれば希望したものは抽出できると考えています。

# 検索結果をLLMへ提供して自然言語を取得
ここでは、どのLLMを呼び出して利用するのかによります。

私は現在、3つほど呼び出せるように構築しておりますが、こだわりがないなら普通にChatGpt4oでいいと思います。
最近では、インプットのトークン数も増えてアウトプットのトークン数を上がってきたため、ある程度雑に情報を渡しても回答精度は保証できます。

しかし、唯一気を付けていただきたいことが、先日、OpenAIはアクセス過多で利用制限が発生しました。
そのため、サービスとして可用性を担保させたいなら、2つはモデルを利用できるように構築しておくと、そのような事態にも対処することが可能です。

個人的には、Geminiがおすすめです。

ぜひ、検討してみてください。

# 取得した情報を画面へ展開
実際にサービスを展開する場合は、画面が必須となります。

上記の開発を行うのは、Pythonとなる可能性が高いと思いますが、それを画面で表示できるように構築が必須です。
私は、単独で開発を行っていたため、１から作ることができず、ローコードツール【OracleAPEX】で作りました。

ただし、OracleAPEXは、直接Pythonを利用できないため、FunctionsというサーバーレスでサービスをたてることができるOCIの機能を利用しました。

OCIでまとめることができた為、かなり楽に構築を進めることができました。

# まとめ
サービスとしての実装の観点を切り離し、RAGとしての苦労した点のみを今回はまとめました。
今後は、サービスとしての実装における苦労した点など、Ver2の記事も考えております。

ぜひ今後ともよろしくお願いいたします。
VScode 残存ファイル消 +. VScode関係　

<h3>残存ファイル調べるコマンド</h3>

```ruby:全件一致(両端に必ずアスタリスクつける)じゃないと、ヒットしない
find ~/Library -iname "*vscode*" 2>/dev/null
```

<h3>残存ファイル 調べた結果</h3>

```ruby:あ〜たくさんあんじゃんよ
/Users/chomechomesuke/Library/Application Support/Code/logs/20250216T155506/window1/exthost/vscode.github-authentication
/Users/chomechomesuke/Library/Application Support/Code/logs/20250216T155506/window1/exthost/vscode.github
/Users/chomechomesuke/Library/Application Support/Code/logs/20250216T155506/window1/exthost/vscode.git
/Users/chomechomesuke/Library/Application Support/Code/logs/20250216T155640/window1/exthost/vscode.github-authentication
/Users/chomechomesuke/Library/Application Support/Code/logs/20250216T155640/window1/exthost/vscode.github
/Users/chomechomesuke/Library/Application Support/Code/logs/20250216T155640/window1/exthost/vscode.git
/Users/chomechomesuke/Library/Application Support/Code/CachedExtensionVSIXs/ms-ceintl.vscode-language-pack-ja-1.97.2025021209
/Users/chomechomesuke/Library/Saved Application State/com.microsoft.VSCode.savedState
/Users/chomechomesuke/Library/Preferences/com.microsoft.VSCode.plist
/Users/chomechomesuke/Library/HTTPStorages/com.microsoft.VSCode
/Users/chomechomesuke/Library/Caches/com.microsoft.VSCode.ShipIt
/Users/chomechomesuke/Library/Caches/com.microsoft.VSCode
```

<h3>残存ファイル、消すコマンド</h3>

```ruby:全部、消すべし！
rm -rf ~/Library/Application\ Support/Code
rm -rf ~/Library/Saved\ Application\ State/com.microsoft.VSCode.savedStat
rm -rf ~/Library/HTTPStorages/com.microsoft.VSCode
rm -rf ~/Library/Caches/com.microsoft.VSCode*
rm -rf /Users/myユーザー名/Library/Saved\ Application\ State/com.microsoft.VSCode.savedState
rm -f /Users/myユーザー名/Library/Preferences/com.microsoft.VSCode.plist
```

<h3>拡張機能</h3>

![スクリーンショット 2025-04-10 17.09.43.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/628823/3dd4a2e1-de8d-4dbf-a339-6556372f2015.png)



```ruby:better Comments
comman + / +  !  : 赤

comman + / + ?  : 水色

comman + / +.TODO : 黄
```
<br>

![スクリーンショット 2025-04-10 16.50.52.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/628823/b16aac5e-02c5-4fae-b914-0a5020015655.png)

![スクリーンショット 2025-04-10 17.10.29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/628823/d1ab87de-e4f9-47c9-87cc-4b0e43d96cca.png)
個人的備忘録：言語化が苦手だった自分が、自信を持って言語化できるようになったコツと、そのスキルを高める方法

## はじめに

言語化とは、自分の考えや感じたことを言葉にすることです。

:::note info
**これにより、思考が整理され、相手に伝えやすくなります。仕事や人間関係のコミュニケーションがスムーズになり、問題解決や意思決定の質も向上します。**
:::

本記事では、言語化の重要性と実践のコツを紹介します。

## 言語化とは？
言語化とは、自分の考えや感じたことを言葉にすることを指します。

:::note warn
**これにより、思考が整理され、相手に伝えやすくなります！**
:::

また、言語化のスキルを磨くことで、仕事や人間関係のコミュニケーションがスムーズになり、意思決定の質も向上します。

## 言語化が重要な理由
1. **思考の整理ができる**
   - 言葉にすることで、自分の考えが明確になり、思考の混乱を防ぐことができます。

2. **相手に伝わりやすくなる**
   - 頭の中で考えていることを適切な言葉に変換することで、相手に理解してもらいやすくなります。

3. **問題解決がスムーズになる**
   - 問題を具体的に言葉にすることで、解決策を見つけやすくなります。

4. **チームのコミュニケーションが向上する**
   - 仕事やプロジェクトでの意思疎通がスムーズになり、誤解を防ぐことができます。

## 言語化のコツ
### 1. **目的を明確にする**
言語化するときは、まず「何のために伝えるのか？」を明確にしましょう。目的が明確でないと、伝える内容がブレてしまいます。

### 2. **具体例を交える**
抽象的な表現だけでは伝わりにくいため、具体例を交えて説明すると相手に伝わりやすくなります。
- 例：
  - ×「このシステムは使いやすい」
  - ○「このシステムはワンクリックで予約が完了するので、初心者でも簡単に使える」

### 3. **5W1Hを意識する**
「誰が（Who）」「何を（What）」「いつ（When）」「どこで（Where）」「なぜ（Why）」「どのように（How）」を意識して話すことで、相手に伝わりやすくなります。

### 4. **短くシンプルにする**
長すぎる説明は、かえって伝わりにくくなります。無駄な言葉を削り、できるだけシンプルにまとめましょう。

- 例：
  - ×「このプロジェクトは、複数の関係者が連携するための重要な役割を担っています。」
  - ○「このプロジェクトは、関係者の連携を支える役割を持つ。」

### 5. **事実と意見を分ける**
事実と意見を分けて表現すると、誤解が減り、議論がスムーズになります。
- 例：
  - 事実：「リリース日は3月1日です。」
  - 意見：「リリース日は早すぎると思う。」

### 6. **相手の視点で考える**
相手がどの程度の知識を持っているかを考え、適切な言葉を選びましょう。専門用語が多すぎると伝わりにくくなります。

### 7. **フィードバックをもらう**
自分の言葉が正しく伝わっているか確認するために、他人からフィードバックをもらいましょう。相手の反応を見ながら改善していくことが大切です。

## 言語化スキルを高める方法
1. **日記（記事）を書く**
   - 日々の出来事や考えたことを文章にする習慣をつけると、言語化能力が向上します。

2. **プレゼンや説明の機会を増やす**
   - 人に説明することで、自分の考えを整理し、的確に伝える力が鍛えられます。

3. **わかりやすい文章やスピーチを参考にする**
   - 上手なプレゼンや記事を読むことで、良い言語化のパターンを学べます。

## まとめ
言語化は、思考の整理や円滑なコミュニケーションのために重要なスキルです。

:::note info
**目的を明確にし、具体例を使いながら、シンプルに伝えることを意識すると効果的です。**
:::

***私自身も、今回の内容を習慣として意識しながら、努力を続けていきます！***
効果的なコードレビューの観点

# はじめに

コードレビューは、ソフトウェアの品質向上やチームのスキル向上に欠かせない重要なプロセスです。しかし、適切に行わないと単なる形式的な作業になってしまい、期待される効果を得られないこともあります。本記事では、効果的なコードレビューのポイントを詳しく解説します。

## 1. コードレビューの目的
コードレビューには、以下のような目的があります。

- **バグの早期発見**: 開発者が気づかないバグや不具合を見つける。
- **コードの可読性向上**: 他の開発者が理解しやすいコードになっているかを確認する。
- **設計の改善**: コードの設計やアーキテクチャが適切かを評価する。
- **チームの知識共有**: レビューを通じて、チーム内で知識を共有し、スキル向上を図る。
- **一貫性の維持**: チームのコーディング規約やベストプラクティスに沿ったコードが書かれているか確認する。

## 2. レビューの進め方
### 2.1 レビュイー（レビューを受ける人）の準備
レビュイーは、コードを提出する際に以下の点を意識しましょう。

- **小さな単位で提出する**: 変更が大きすぎると、レビューの負担が増える。可能であれば100〜200行程度に収める。
- **説明を明確にする**: プルリクエスト（PR）には、変更内容や背景を明記する。特に「なぜこの実装を選んだのか」を説明すると、議論がスムーズになる。
- **自己チェックを行う**: 静的解析ツールやLintを活用し、基本的な問題は事前に修正する。テストが実行されていることを確認する。
- **影響範囲を明確にする**: どの部分に影響が出るのか、既存機能との互換性はどうかを把握する。

### 2.2 レビュアー（レビューをする人）の視点
レビュアーは、以下の観点でコードをチェックすると効果的です。

- **動作の正しさ**: 仕様通りに動作するか。ユニットテストや結合テストが適切にカバーされているか。
- **コードの可読性**: 変数名、関数名が適切であるか。関数やクラスの責務が明確か。
- **保守性**: 将来的に修正しやすい構造になっているか。DRY（Don’t Repeat Yourself）の原則が守られているか。
- **パフォーマンス**: 不必要な計算や処理が含まれていないか。データ構造やアルゴリズムの選択は適切か。
- **セキュリティ**: SQLインジェクションやXSSなどの脆弱性がないか。認証・認可の処理が適切に行われているか。
- **スタイルと規約**: チームのコーディング規約やフォーマットに沿っているか。

## 3. 良いコードレビューのポイント
### 3.1 ポジティブなフィードバックを心がける
コードレビューは開発者の成長にもつながるため、改善点だけでなく良い点も指摘しましょう。

- 「この関数の設計がシンプルで分かりやすいですね。」
- 「命名が適切で、意図が伝わりやすいです。」
- 「このリファクタリングでコードの再利用性が向上しましたね。」

### 3.2 指摘は具体的に
抽象的な指摘ではなく、具体的な改善提案を行うと、より効果的なレビューになります。

**NG例:** 「この関数は分かりにくいです。」  
**OK例:** 「この関数は一度に多くの処理をしているため、処理を分割すると可読性が向上しそうです。」

### 3.3 議論が必要な点は建設的に
意見が分かれる点については、感情的にならず建設的に議論することが大切です。

- 「この実装方法について、他のアプローチも検討できるかもしれません。」
- 「パフォーマンスの観点から、もう少しシンプルな方法も考えられますね。」
- 「この処理はスレッドセーフではない可能性がありますが、どのように考えていますか？」

## 4. ツールを活用する
コードレビューを効率化するために、以下のツールを活用すると良いでしょう。

- **GitHub / GitLab / Bitbucket**: PRベースのコードレビュー
- **Lint / 静的解析ツール**: 事前チェックの自動化（ESLint, RuboCop, Flake8 など）
- **CI/CDパイプライン**: 自動テストの実行（GitHub Actions, CircleCI など）
- **コードメトリクスツール**: コードの複雑度やカバレッジを分析（SonarQube, CodeClimate など）
- **ペアプログラミング**: リアルタイムでのレビューとフィードバック

## まとめ
効果的なコードレビューを行うことで、コードの品質向上だけでなく、チーム全体のスキル向上にもつながります。ポジティブなフィードバックを意識しつつ、具体的な指摘を行うことで、より良い開発環境を作りましょう。

皆さんのチームでは、どのようなコードレビューを行っていますか？ぜひコメントで教えてください！
【Power Automate】トリガーの作成方法について ～スケジュール済みクラウドフロー編～

## はじめに
Power Automate は、さまざまなトリガーを使って自動化のプロセスを開始することができます。
この記事では、Power Automate におけるトリガーの作成方法の１つである
「スケジュール済みクラウドフロー」の作成方法について説明します。
トリガーの基本的な種類に関して、簡単にではありますが以下の記事において説明をしています。

https://qiita.com/Sanwa_Paint/items/659e451d33f011a59bf5

## スケジュール済みクラウドフローとは？
スケジュール済みクラウドフローは、指定した日時や繰り返しの間隔でフローを実行するためのトリガーです。
定期的な作業を自動化する場合に使用します。

今回は
**毎朝10時になると Microsoft Teams にリマインドメッセージを投稿するフロー**
を作成してみたいと思います。

## スケジュール済みクラウドフローの作成手順
1\. Power Automateにサインイン
+ Power Automate にサインインして、フローの作成を開始します。


2\. 新しいフローを作成
+ Power Automateのホーム画面で「+ 作成」をクリックします。
+ 「スケジュール済みクラウドフロー」を選択します。
　スケジュール済みクラウドフローは、イベントトリガーを使って自動的に実行されるフローです。


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3719434/3664df67-e4fb-4e42-95eb-95a3b1cac81b.png)

3\. フローを構築する
+ フローの詳細を指定します。フローの名前や実行タイミングをここで設定します。
繰り返し間隔は開始日より起算して、どんな間隔で実行するかを指定します。
`ヶ月` `週間` `日` `時間` `分` `秒` の6パターンから選択できます。

今回は以下のように **`毎朝10時にフローを実行する`** で設定してみたいと思います。
設定ができれば「作成」を押します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3719434/a9ff3d1d-b6c9-4465-8e1f-db8d7851d50e.png)

:::note warn
フロー作成時に `タイムゾーン` の確認および変更を必ず行ってください。
UTC時刻で表記されるため、デフォルトで設定した時間よりも -9時間 となっている可能性があります。
その際はタイムゾーンを +9時間にして時差が起きないようにしてください。
:::

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3719434/c3449433-d3c7-449a-8f77-a7e70b770522.png)



4\. アクションの設定
+ フローが実行された時に行いたいアクションを追加します。
`今回は選択したリストにアイテムが追加された際に、Microsoft Teams に通知が飛ぶように設定します。`

+ 「チャットまたはチャネルでメッセージを投稿する」を選択します。
+ 各項目に値を入力し、メッセージを入力します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3719434/21773d57-7f03-4c58-84a9-8a2168dec70b.png)

5\. フローを保存してテスト
+ `保存`を押してフローを保存を行い、保存ができたらフローのテストを行います。
+ 実行されたフローの確認履歴を表示し `開始時刻` が正しく設定されているか必ず確認を行ってください。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3719434/0dbfaa23-b17c-4d77-93bb-5a739fd749a8.png)


## まとめ
とても簡易的な一例ではありますが、以上が「スケジュール済みクラウドフロー」の作成方法になります！
ただTeamsやメールの送信を行うだけではなく、データを取得して更新を行うなど、勤務時間外の夜の間にフローを回しておいて朝に確認するとデータの更新が完了しているなど作業時間の削減にもつながり上手くつかいこなせばかなり作業効率をアップさせることが可能となります。
この他にも随時、他の種類のフローやトリガーについて記事を作成していく予定です！
ぜひ、ご活用ください！