OmniAICreator/Qiita-1.07M huggingface dataset:
二つの不確実性 Epistemic/Aleatoric Uncertainty に関するメモ書き - 1

:::note info
TLDR: 不確実性をモデリングする重要性は医療などのモデルの正確性が重大な影響を及ぼす際に重要になる。その不確実性は(i)おおまかに知識の欠如に由来するが、適切な知識の追加により減らすことのできるEpistemic Uncertaintyと、(ii)ノイズに由来する減らすことのできないAleatoric uncertaintyに分けられる。このモデリングの方法は頻度論者やベイジアンなど学派によって多岐にわたり、問題設定によっても多岐にわたる。ガウス過程での例を挙げると、クエリ点のConfidence Boundが不確実性の総和の目安としてみれるので、ノイズの大きさ(Aleatoric Uncertainty)を考えることで、残りの不確実性はEpistemic Uncertaintyと見られる。この点で言えば、Aleatoric Uncertainty自体は減らせなくとも、減らせるEpistemic Uncertaintyを定量化するのに役立ち、結果的にそれを減らすことにリソースを割り当てることができそうだ。
:::

以下のメモは、以下のサーベイ論文を読みながら、自分の質問に対する答えを学習の過程で書いてみたものです。

> Aleatoric and epistemic uncertainty in machine learning: an introduction to concepts and methods (Eyke Hüllermeier & Willem Waegeman)

https://link.springer.com/article/10.1007/s10994-021-05946-3

### 前提

- Epistemic Uncertainty (Systematic Uncertaintyとも呼ばれる)
  - 意思決定をするエージェントの知識の欠如
  - この不確実性は適切な知識を足すことで減らすことができる
- Aleatoric Uncertainty (Intrinsic Uncertainty, Statistical Uncertaintyとも呼ばれる)
  - ランダム性に由来する不確実性
  - この不確実性を減らすことは難しい

Epistemic Uncertaintyはreducibleな不確実性の部分である一方、Aleatoric Uncertaintyはirreducibleな不確実性であると述べられている。



### 自分の持っている疑問とそれに対するおおまかな回答

- **Q1 - 定量化するとはどういうことか？**
  - 実は機械学習でこれらの不確実性をモデリングするのには様々なやり方がある。Figure 11にまとめられているように、たとえば、frequentist vs Bayesianの人々でモデリングのやり方は違うことがわかる
  - 数多くの例の中でもガウス過程(GP)の例がSection 4.4に述べられている。GPでPredicative UncertaintyがConfidence Boundで定量化される。GPでの任意のクエリ点のpredicative uncertaintyが、そこでの不確実性の総和であると考えられるらしい。このBoundの$\sigma$はノイズとして寄与するので、Aleatoric Uncertaintyとして考えられ、前述の不確実性から$\sigma$を除いたものが、Epistemic Uncertaintyとなるようだ。
  - ここで思ったのは、Epistemic Uncertaintyを定量化することは、Aleatoric Uncertaintyを計算する、つまりノイズの大きさを計算することが必要になるようだ。
- **Q2 - Aleatoric Uncertaintyを減らすのが難しい場合、なんでわざわざ定量化するのか？**
  - 上のサーベイ論文では、この不確実性はirreducibleであると述べられている
  - ただ、上述のようにGPの不確実性の定量化の際に、Aleatoric Uncertaintyを推定することで、Predictive Uncertaintyの総和から、Epistemic Uncertaintyがわかるので、少なくとも知識を与えることにより減らせうる、おおまかな期待がわかるので、そこから精度を上げる努力にどれくらいのリソースを割くべきか、などが分かるかもしれない


あくまで部分的にサーベイ論文を読んで、自分の質問に対するおおまかな回答をしてみたので、私の書いたメモ書きの正確性は保証できません。上でまとめた例もガウス過程の部分なので、Uncertainty Quantificationという広いトピックをカバーはしていません。間違い等ありましたら、コメントでフィードバックお願いいたします :)

また気が向いたらメモを書きます。


### 次に読んでみたい論文

上記のサーベイ論文で言及されていた、医療分野でEpistemic/Aleatoricを区別することの有用性について書かれた次の論文に興味が湧きました。また時間があれば読んでみたいです。

https://www.sciencedirect.com/science/article/abs/pii/S0020025513005410
DVA第1章　AWSの概要・基礎・前提知識

# 第1章　AWSの概要・基礎・前提知識

DVAに向けて知識の整理をするべく概念をまとめていく。
## アベイラビリティゾーン
多数のサーバーからなる1つ以上のデータセンタからなる。
## エッジロケーション
アクセスを素早くするために物理的に近いユーザーが接続するためのデータセンタ。
## VPC(Virtual Private Cloud)
仮想プライベートネットワークを構築できるサービスで複数のアベイラビリティゾーンを跨げる。
## サブネット
小さなネットワーク、アベイラビリティゾーンごとに作る必要あり。
## VPN(Virtual Private Network)
VPCとオンプレミス環境を接続するためのAWS内のネットワークゲートウェイ。
## オンプレミス
サーバーなどを自社施設内で保管する形態。
## インターネットゲートウェイ
VPCとインターネットの通信用途で使われるネットワークゲートウェイ。通信元のリソースはIPアドレスを必要とする。
## NATゲートウェイ(Network Address Translation)
プライベートサブネット内でインターネットへの通信をしたい場合にパブリックサブネットへ設置する中継用ゲートウェイ。
## VPNゲートウェイ
VPCとオンプレミスとを接続する場合にAWS内で作るネットワークゲートウェイ。
## カスタマーゲートウェイ
AWSとのVPN接続におけるオンプレミス側のゲートウェイ。
## VPCピアリング接続
独立した2つのVPCを接続しプライベートアドレスを使って相互に通信する。
## VPCエントポイント
VPCの中からAWSマネージドサービスにアクセスするためのサービス。ゲートウェイ型とインターフェース型があり、前者はインターネットを経由せずAWSネットワークを使うプライベートな接続、後者はVPC内にエンドポイントを作ることで多くのAWSサービスへ接続可能。
## トランジットゲートウェイ
VPC間の接続を統合するアプリケーション方のネットワーク管理サービス。
## ルートテーブル
指定されたCIDR(Classless Inter-Domain Routing)表記のアドレスで通信するために定義するルールセット。
## セキュリティグループ
AWSのVPC内のインスタンスの通信を制御するファイアウォールでステートフルに動作する。ステートフルとは通信に対して自動的にレスポンスすること。
## ネットワークACL(Access Control List)
あらゆる通信をサブネットレベルで制御する機能でステートレスに動作する。ステートレスとは通信に対して送信ルールを明示しないとレスポンスがブロックされる仕組みのこと。
## Amazon EC2(Amazon Elastic Compute Cloud)
仮想的にサーバー環境を提供するサービス。
## インスタンス
配置する仮想サーバ。
## インスタンスの起動フロー
① 名前とタグの設定：インスタンスの名前と付与するタグを設定。

② AMI(Amazon Machine Image)の選択：仮想サーバとして動かすゲストOSを選択。

③ インスタンスタイプの選択：CPUやメモリ、ストレージなどのリソースキャパシティを定義したもの。

④ キーペア設定：インスタンスに接続するための公開鍵を設定。

⑤ ネットワーク設定：インスタンスを配置するVPCやサブネット、セキュリティグループを指定。

⑥ ストレージ総裁設定：インスタンスにアタッチするストレージを設定。

⑦ インスタンス詳細設定：インスタンスを配置するVPCやサブネット、ハードウェア専有オプションや、インスタンスに割り当てるIAM(Identity and Access Management)ロールやユーザデータを設定。
## プレイスメントグループ
AWS実行時に、アベイラビリティゾーンの物理的な配置戦略を選択するオプション。
## Amazon EC2インスタンスからのAWSリソースへのアクセス
EC2から他のAWSインスタンス(APIを実行)にアクセスする場合はIAMを使った権限付与を行う必要がある。
## Amazon EBS(Elastic Block Storage)
EC2向けにブロックストレージを提供するサービス。
## Amazon EFS(Elastic File System)
AWS上でファイルストレージを提供するサービス。
Route 53シャッフルシャーディングとAnycast ルーティング

Amazon Route 53 で提供される **シャッフルシャーディング（Shuffle Sharding）** と **Anycast ルーティング** は、どちらも信頼性や可用性を高めるための技術ですが、目的と仕組みが異なります。それぞれを以下にわかりやすく説明します。

---

## 🧩 1. シャッフルシャーディング（Shuffle Sharding）

### ✅ 概要

Route 53 の **ヘルスチェックや DNS クエリのレート制限などに使われる信頼性強化の技術**。
利用者ごとにランダムなサブセットのサーバーを割り当てて、**他の利用者の影響を受けにくくする**ための手法です。

---

### 🔍 仕組み（イメージ）

* たとえば、Route 53 のバックエンドに 100 個のサーバー（ノード）があるとします。
* 通常は全体からランダムにアクセスされると、あるユーザーの障害が他のユーザーに波及する可能性があります。
* シャッフルシャーディングでは、例えばその中から「ランダムに選んだ10個だけ」をあるユーザーの対象サーバー群とします。
* 結果的に、**「シャード」ごとの論理的な分離**が実現され、**一部障害の影響範囲を局所化**できます。

---

### 🧠 利点

| 項目       | 説明                            |
| -------- | ----------------------------- |
| 高可用性     | 他ユーザーの影響を受けにくい（障害がシャード単位に閉じる） |
| セキュリティ強化 | 一部のシャードを狙った DoS 攻撃の効果が限定的になる  |
| 拡張性      | ユーザー数が増えてもサーバー負荷の分散が可能        |

---

### 🛠 使われる場面

* Route 53 の **ヘルスチェック**
* Route 53 Resolver の **レート制限**
* CloudFront の内部 DNS 解決（強靭性向上）

---

## 🌐 2. Anycast ルーティング

### ✅ 概要

**同じIPアドレスを複数の地理的に異なる場所のサーバーで共有し、ネットワーク的に最も近いサーバーにルーティングする技術**。
Route 53 の DNS サーバーは Anycast IP を使っており、**グローバルに高速かつ耐障害性のある名前解決**を実現します。

---

### 🔍 仕組み（イメージ）

* 世界中に分散配置された Route 53 の DNS サーバーが **同じ IP アドレス（例：DNS の公開IP）** を持つ。
* クライアントが DNS クエリを送ると、**BGP（経路制御）により物理的に最も近い DNS サーバーに転送される**。

---

### 🧠 利点

| 項目   | 説明                        |
| ---- | ------------------------- |
| 高速   | 最寄りのサーバーに接続されるためレスポンスが早い  |
| 耐障害性 | 一部リージョンの障害時でも他のリージョンが代替   |
| 負荷分散 | クライアントからのトラフィックが地理的に分散される |

---

### 🛠 使われる場面

* Route 53 の **パブリック DNS 解決**（`8.8.8.8` のようなIPに似た扱い）
* CloudFront の **エッジロケーション最適化**
* AWS Global Accelerator の内部ルーティングにも応用されている

---

## ✅ 違いのまとめ

| 比較項目 | シャッフルシャーディング       | Anycastルーティング     |
| ---- | ------------------ | ----------------- |
| 対象   | ユーザー単位の論理的シャード     | ネットワーク経路で最も近いサーバー |
| 目的   | 耐障害性・フェアネス・セキュリティ  | 高速応答・グローバル冗長化     |
| レベル  | アプリケーション/論理構成      | ネットワークレベル（BGP）    |
| 主な用途 | DNSヘルスチェック、レート制限分離 | グローバルDNS応答の高速化    |
【Tips】Cursorをインストールして遊んでたら`code`コマンドでVSCodeが起動できなくなった話

## 概要と注釈
Cursorインストール時に`code`コマンドでCursorを呼び出せるよう設定したら逆に`code`コマンドでVSCodeが起動できなくなった。これを解決する。

環境はWindows11。それと
> この形式の文書はcopilotからの出力

である。

## どうやって解決したか
### 結論
実行可能ファイルとコマンドファイルをまとめて削除したら動いた。

### 経緯
CursorでAIの言いなりになってコーディングしていたけども、なんだかUIは気に食わないと思っていた。そんなとき、ふとCodyをインストールしてVSCodeを使えばよくね？（今更）の気持ちになった今日このごろ。なのでVSCodeに戻ろう…という試みをしたものの、
```bash
code .
```
を実行するとVSCodeが起動しない！！勝手にCursorが起動してしまう（そういう設定にしたのは自分だけども）。なのでこれを解決しよう。
なんとなくCursorをアンインストールするのも嫌だったのでコマンドの挙動だけを変更するという試みをした。まずは`code`コマンドの呼び出し元を確認。

```bash
$ where code
C:\Users\<user name>\scoop\apps\cursor\0.49.6\resources\app\bin\code
C:\Users\<user name>\scoop\apps\cursor\0.49.6\resources\app\bin\code.cmd
```

ふむふむ。これを削除すればCursorを呼び出せなくなるっぽい。というかなんだこの`code, code/cmd`って。

> - `code`: これは、実行可能ファイル (executable file) であることが多いです。拡張子がない場合、Windows では通常、実行可能ファイルとして扱われます。このファイルは、Cursor または VSCode の本体を起動するためのプログラムです。
> - `code.cmd`: これは、コマンドファイル (command file) またはバッチファイル (batch file) と呼ばれるものです。テキストファイルであり、一連のコマンドが書かれています。code.cmd は、code コマンドを実行するためのスクリプトのようなもので、例えば、環境変数を設定したり、引数を処理したりしてから、実際の code 実行可能ファイルを呼び出す、といった処理を行うことがあります。

へえ。エンジニアの赤ちゃんだから実行可能ファイルとかコマンドファイルとかわからない。もう少しかみ砕いてもらおう。

> ## 実行可能ファイル (Executable File)
> - 役割: 実行可能ファイルは、コンピュータが直接実行できる命令が書かれたファイルです。プログラムの本体であり、ダブルクリックしたり、コマンドラインから名前を入力したりすることで、プログラムが起動します。
> - 拡張子: Windows では、.exe、.com などが代表的な拡張子です。ただし拡張子がない場合でも実行可能ファイルとして扱われることがあります。
> - 例: VSCode の code (拡張子なし) や、多くのソフトウェアの .exe ファイルが該当します。
> - 仕組み: 実行可能ファイルには、CPU が理解できる機械語や、OS が解釈できる中間言語 (例えば、.NET Framework の場合は CIL) が含まれています。OS はこれらの命令を順番に実行することで、プログラムの機能を実現します。
>
> ## コマンドファイル (Command File) / バッチファイル (Batch File)
> - 役割: コマンドファイルは、一連のコマンドを記述したテキストファイルです。コマンドプロンプトや PowerShell などのコマンドインタープリタによって解釈・実行されます。複数のコマンドをまとめて実行したり、条件分岐や繰り返しなどの制御構造を記述したりすることができます。
> - 拡張子: Windows では、.cmd や .bat が代表的な拡張子です。
> - 仕組み: コマンドインタープリタは、コマンドファイルを1行ずつ読み込み、記述されたコマンドを実行します。コマンドファイルは、環境変数の設定、ファイルのコピー、プログラムの起動など、様々な処理を自動化するために利用されます。

要はカレントディレクトリで`code .`と打つと`code.exe`や`code.cmd`を探しに行って、実行しているわけだ。それでCursorをVSCodeより先に見つけてしまうので、`code`コマンドがCursorを呼び出してしまうということか（多分）。それでは`code`コマンドを削除してしまえばよさそう。

```bash
$ rm code code.cmd // cdしたうえで実行
```

ターミナルを再起動して`code`コマンドを実行してみるとVSCodeが起動した。解決。よかった。
完全な理解は将来の自分に丸投げしました。
Amazon EMR

Amazon EMR（**Elastic MapReduce**）は、

> **ビッグデータの処理・解析を簡単・スケーラブルに実行できるマネージドサービス**です。

HadoopやSparkなどの**オープンソースのビッグデータフレームワーク**を使って、大量データの処理、分析、変換、機械学習などを**AWS上で簡単に実行**できます。

---

## 🧠 一言でいうと…

> **「HadoopやSparkをAWS上で手間なく実行できるサービス」**

---

## 🔧 対応している主なフレームワーク

| フレームワーク              | 用途                   |
| -------------------- | -------------------- |
| **Apache Hadoop**    | 分散処理の基盤（MapReduce）   |
| **Apache Spark**     | 高速なインメモリ分散処理エンジン     |
| **Apache Hive**      | SQLライクにHadoopを操作     |
| **Presto/Trino**     | 高速な分散SQLクエリエンジン      |
| **Apache HBase**     | 分散型のNoSQLデータベース      |
| **Apache Flink**     | ストリーム処理エンジン          |
| **Jupyter Notebook** | データ分析・ML用のインタラクティブ環境 |

---

## 🛠️ Amazon EMRの特徴

| 特徴           | 説明                                |
| ------------ | --------------------------------- |
| ✅ **スケーラブル** | 数台〜数百台までノードを自動でスケーリング可能           |
| ✅ **安価**     | スポットインスタンスでコスト削減も可能               |
| ✅ **柔軟な構成**  | クラスタの構成（マスターノード、コア、タスクノード）を自由に選べる |
| ✅ **S3連携**   | 入出力データをS3と連携可能（EMRFS）             |
| ✅ **セキュア**   | IAMやVPC、Kerberosなどのセキュリティ機能も完備    |
| ✅ **ステップ実行** | バッチ処理をステップとして順に実行できる              |

---

## 🗂️ 主なユースケース

| ユースケース    | 説明                             |
| --------- | ------------------------------ |
| ビッグデータ処理  | ログやIoTデータのバッチ分析（Hadoop, Spark） |
| データレイク分析  | S3上のデータをPrestoやHiveで分析         |
| 機械学習      | Spark MLlibやJupyterでの分散学習      |
| ETLパイプライン | データ抽出・変換・ロード処理（Glue代替）         |

---

## 📊 アーキテクチャのイメージ

```
S3（データ） ←→ EMRクラスタ（Spark/Hadoopなど） ←→ 分析結果をS3やRDSへ
```

クラスタは必要なときだけ起動して、処理が終わったら削除することもできます（コスト最適化）。

---

## 💡 他の選択肢との比較（用途別）

| 目的          | サービス                    | 備考         |
| ----------- | ----------------------- | ---------- |
| 高速な分散バッチ処理  | ✅ EMR（Spark）            | 柔軟かつスケーラブル |
| データ変換中心のETL | AWS Glue                | ノーコードでも可能  |
| ストリーム処理     | Kinesis + Flink（on EMR） | 近リアルタイム分析  |
| データウェアハウス   | Amazon Redshift         | SQL分析に特化   |

---

## ✅ まとめ

| ポイント    | 説明                         |
| ------- | -------------------------- |
| 何ができる？  | HadoopやSparkなどを用いたビッグデータ分析 |
| 何が便利？   | 自動スケーリング、S3連携、豊富なOSSサポート   |
| 向いている用途 | ログ集計、機械学習前処理、大規模バッチ分析など    |
CloudFormation StackSet

CloudFormationの**スタックセット**は、

> **1つのCloudFormationテンプレートを複数のAWSアカウントやリージョンに一括デプロイできる仕組み**です。

たとえば、企業全体の標準的なIAMロールやVPC構成などを**複数アカウント・複数リージョンに展開したい**ときに使います。

---

## 🧱 StackSetsとは？

通常、CloudFormationは1つのスタックを**1つのアカウント・1リージョン**に作成します。
一方、StackSetsを使うと、同じテンプレートを複数のアカウント・リージョンに一括デプロイできます。

---

## 📌 用語の整理

| 用語                 | 意味                                      |
| ------------------ | --------------------------------------- |
| **StackSet**       | デプロイしたいCloudFormationテンプレートの定義          |
| **スタックインスタンス**     | 各アカウント／リージョンに作成された個別のCloudFormationスタック |
| **管理アカウント（管理者）**   | StackSet を作成・管理するアカウント                  |
| **実行アカウント（ターゲット）** | テンプレートを実際に展開するアカウント群                    |

---

## 🔧 2つの管理モデル

| モデル            | 説明                                          |
| -------------- | ------------------------------------------- |
| **サービスマネージド型** | AWS Organizationsを使って、組織内のアカウントに自動でデプロイ（推奨） |
| **セルフマネージド型**  | 手動でクロスアカウントロールを作って、各アカウントにデプロイ              |

---

## 🛠️ StackSetの使い方（基本ステップ）

1. **テンプレートを作成**（例：IAMロールの作成）
2. **StackSetを作成**
3. **展開先のアカウント・リージョンを指定**
4. **自動で各スタックインスタンスが作成される**
5. **更新も一括で実施可能**

---

## 🧾 例：簡単なテンプレート（IAMロール）

```yaml
AWSTemplateFormatVersion: '2010-09-09'
Description: Create an IAM role
Resources:
  MyRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: MyExampleRole
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: ec2.amazonaws.com
            Action: sts:AssumeRole
```

このテンプレートをStackSetにして、**複数アカウント/リージョンに同じIAMロールを作成**することができます。

---

## 💡 StackSets のユースケース例

* すべてのアカウントに共通のログ用S3バケットポリシーを展開
* 監査用IAMロールを各アカウントに一括作成
* 組織内の全リージョンにGuardDutyやConfigの設定を配布

---

## 🚧 注意点

* StackSetの更新時は、**すべてのターゲットアカウントに影響がある**ので慎重に。
* サービスマネージド型を使うには、**AWS Organizationsが有効になっている必要**があります。
* テンプレートエラーがあると、一部アカウント・リージョンで失敗する可能性がある。

---

## ✅ まとめ

| 項目      | 内容                                |
| ------- | --------------------------------- |
| 目的      | 複数アカウント／リージョンへのCloudFormation一括展開 |
| メリット    | 作業効率化、ポリシーの一元化、運用負荷の削減            |
| おすすめモデル | サービスマネージド型（Organizations利用時）      |
【Go】iotaの使い方メモ


## 概要

- Goの[iota](https://go.dev/wiki/Iota)は定数の連番を簡単に定義できる機能
- 実務で目にしたことがあるパターンのメモ

## iotaについて

- Goの`iota`は、**constブロックの中で連番の定数を簡単に定義できる予約語**
- 通常、0から始まり、1ずつインクリメントされる

```go
const (
    A = iota // 0
    B        // 1
    C        // 2
)
```


## 状態や種別の識別子

- 状態管理が数字ベースで統一でき、定義もすっきりする

```go
type UserStatus int

const (
    StatusActive UserStatus = iota
    StatusSuspended
    StatusDeactivated
)

```


## フラグのビット値管理（ビットマスク）

- 複数のフラグをビット単位でまとめて管理・判定できる

```go
const (
    FlagRead = 1 << iota // 1 << 0 → 0001
    FlagWrite            // 1 << 1 → 0010
    FlagDelete           // 1 << 2 → 0100
)

func hasPermission(flags, permission int) bool {
    return flags&permission != 0
}
```


## エラーコード番号の整理

- **エラーコードの先頭値を固定しつつ、連番管理**が簡単にできる

```go
type ErrorCode int

const (
    ErrNotFound ErrorCode = iota + 1000 // 1000
    ErrInvalidRequest                   // 1001
    ErrPermissionDenied                 // 1002
)
```


## iota利用時の注意したいこと

- **constブロックごとにリセットされる**
- 式が複雑になると、iotaの値がわかりづらくなることもあるので**コメントで値の意図を残すのがよいかも**
- あくまで**コンパイル時定数のみ**に使える（動的な値には使えない）
【VS Code】Copilotチャットを音声入力で効率上げる【GitHub Copilot】

# はじめに
VS Codeでの開発中、GitHub Copilotとのチャットを多用するのですが、キーボードでのプロンプト入力だけでそれなりの時間を使ってしまったり、面倒になって雑なプロンプトを書いてしまっていました。そこで、時間節約のためにもキーボード入力から音声入力へと切り替えました。
Microsoftから出ている拡張機能を入れるだけなので簡単ではありますが、日本語対応のためには追加設定がいるので記事として残します。

---

### 実際に使ってみて
聞き取りが甘かったりこちらの言い方が悪くて変な質問文になっても、AI側が良しなに解釈してくれるので、今のところ結構いい感じに使えています。
例えば、以下のような聞き取り結果でも望み通りの回答をしてくれるどころか、こちらに合わせてカタカナ表記までしてくれる親切設計！滑舌終わってても大丈夫！
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3894261/61c7f600-d2a7-4b19-982b-a90fc3179cf0.png" width=90%>
さらに良いのが、Command + i を押している間は音声入力を待ってくれているので、焦らず話すことができます。

---

### この記事でできること
VS CodeのGitHub Copilotチャットで音声入力を導入する
音声入力を日本語対応にする

<br>

# 音声入力の導入
### 1. 拡張機能のインストール
**〜VS Codeの拡張機能から、【VS Code Speech】と【Japanese (Japan) language support for VS Code Speech】をインストールする。〜**

1. VS Code左側の拡張機能ボタンか Command + Shift + x から、`Speech Japan`と検索します。

    <br>

2. 出てきた【Japanese (Japan) language support for VS Code Speech】のインストールボタンを押します。すると、自動的に【VS Code Speech】もインストールされるはずです。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3894261/53c90ea4-8f66-4185-9733-b087f4ef24ee.png" width=70%>

---

### 2. 設定ファイルに記入する
**〜Settings (JSON)に音声入力の日本語設定を書き込む〜**

拡張機能をインストールしただけでは、英語設定になっているので、こちらの言葉をうまく聞き取ってくれません。日本語に対応させるには設定ファイルに書き込む必要があります。

<br>

1. Command + Shift + p でコマンドパレットを開きます（もしくはVS Code上部の検索窓から【コマンドの表示と実行】を選択する）。

    <br>

2. `Preferences: Open Settings (JSON)`と入力して、設定ファイルを選択し開きます（`settings jason`や`設定 json`でも出てくると思います）。
普段の使用に応じて、ユーザーの設定ファイルか、ワークスペースの設定ファイルかを選んでください。

    <br>

3. そのファイルに下記のように記入して保存をします。
```
{
    "accessibility.voice.speechLanguage": "ja-JP"
}
```
※すでに他の設定が書き込んである人は、すでにある一番外側の波括弧の中に`"accessibility.voice.speechLanguage": "ja-JP"`を入れてください。

---

### 3. VS Codeを再起動して設定を適用させる
再起動すれば、チャットのところにあるマイクボタンか Command + i で音声入力ができます。
マイクボタンはこちらの声が途絶えると勝手に投稿してくれます。
Command + i は押している間ずっと入力待ちとなるので、こちらのタイミングで投稿できます。

<br>

お疲れ様でした！
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3894261/3074d17d-14ad-44da-a4a1-516a1ae4f1b0.png" width=70%>
年間の Claude Proプランから Maxプランに移行した時のメモ（年間プランの残高が Maxプランの価格を上回る場合）

## はじめに

タイトル通りの内容で、まず結論から書きます。

:::note info
「残高分のクレジットはアカウントに付与されて、このクレジットは将来のサブスクリプション費用に適用される」という状態になるようです。

【情報源（公式のヘルプセンター）】

[Maxプランにはどのように申し込めばよいですか？ | Anthropicヘルプセンター](https://support.anthropic.com/ja/articles/11049752-max%E3%83%97%E3%83%A9%E3%83%B3%E3%81%AB%E3%81%AF%E3%81%A9%E3%81%AE%E3%82%88%E3%81%86%E3%81%AB%E7%94%B3%E3%81%97%E8%BE%BC%E3%82%81%E3%81%B0%E3%82%88%E3%81%84%E3%81%A7%E3%81%99%E3%81%8B)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/50868/1c039876-954b-4446-b595-f2a23d7f0fb3.png)
:::


## 背景など

上で結論を書いていますが、そこに到るまでの過程を少し以下に書いてみます。


### プラン変更など

以前、期間限定割引の情報を見かけて年間の Claude Proプランに加入していました。

https://x.com/youtoy/status/1895102390657036725

それを Maxプランに移行した場合に、年間プランの残高が Maxプランの価格を上回る状況で「年間の Claude Proプラン ⇒ Maxプラン」の移行をした状況でした。


### プラン移行後の状況

ちなみに Maxプランに切り替えた後の状況（今現在の状況）は、以下のとおりです。

差額の「-41.49ドル」がどんな位置付けになっているか確認してみたのですが、日本語表示だと「利用可能与信額」という表現で微妙な訳だったので、念のため英語表示に切り替えて確認してみました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/50868/4d380d4a-8d18-4906-bc0d-59b7f33fe851.png)

「Credit available」という内容で、返金されそうな感じではなくチャージされてそうな感じがします。なお、日本語表示は以下でした。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/50868/e6083eb8-32d7-4a9e-80be-9ebdfafddefb.png)


それで、「Credit available」という状態になった「-41.49ドル」について、公式でどんな説明がされているかを検索していく中で、[冒頭の公式情報](https://support.anthropic.com/ja/articles/11049752-max%E3%83%97%E3%83%A9%E3%83%B3%E3%81%AB%E3%81%AF%E3%81%A9%E3%81%AE%E3%82%88%E3%81%86%E3%81%AB%E7%94%B3%E3%81%97%E8%BE%BC%E3%82%81%E3%81%B0%E3%82%88%E3%81%84%E3%81%A7%E3%81%99%E3%81%8B)へとたどり着いた感じでした。


## まとめ

払い戻しが発生せず、「Credit available」という位置付けになっていたので、何らかストックされた状態かな、とは思ったのですが、冒頭の公式情報にたどり着けて良かったです。

この後、Proプランではできない Maxプランならではのことを、何か試していければと思います。
『ドラゴンクエストIII リメイク』の画面UIを快適化するMod4選  

## ※注意点  
- 本記事の内容によって発生したいかなる問題・損害についても、責任を負いません
- 当記事ではゲームバランスを崩すModは扱いません
- 今後のアップデートで動作しなくなる可能性があります

## 記事の対象者
- Windows
- Steamでプレイしているユーザー

## 動作確認バージョン
本記事は『ドラゴンクエストIII リメイク』のVer.1.1.0.0で検証・執筆しています。

## 今回入れるmod
- 戦闘中もキャラクターの姿が見える
- 体力バーを上部に移動させる
- コマンドパレットのサイズ調整
- 固有アイコンの追加と文字の調整

## 事前準備
### NexusModsの登録とログイン
NexusModsのModを使用するので以下のURLから新規登録・ログインして下さい。
https://users.nexusmods.com/register

### コピー(保険)の作成
Gameデータが破損したときの保険として、コピーを作成します。
1. Steamを開きます
1. ライブラリから画像のようにゲームのローカルファイルを開きます
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3844553/09d09e9d-dcbe-4816-9451-6afbb282678a.png)
1. 画像のように`Game`フォルダのコピーを作成します
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3844553/0535f3b5-d323-4ee9-bac3-1c138477e155.png)


## 戦闘中もキャラクターの姿が見えるmodの導入
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3844553/fc784563-dd6a-4b4e-91ee-af98a4eb9072.png)
1. NexusModsからZipファイルをダウンロードします
(https://www.nexusmods.com/dragonquest3remake/mods/34)
1. ダウンロードしたzipを解凍します(右クリック→すべてを展開)
1. Steamのライブラリからゲームのローカルファイルを開きます
1. 解凍したフォルダの中に`Game`フォルダがあるので既存の`Game`フォルダを上書きします

## 体力バーを上部に移動させる
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3844553/e2564289-af1a-4218-a4c3-e12432f40756.png)
1. NexusModsからZipファイルをダウンロードします
(https://www.nexusmods.com/dragonquest3remake/mods/13?tab=files&file_id=73)
1. ダウンロードしたzipを解凍します(右クリック→すべてを展開)
1. Steamのライブラリからゲームのローカルファイルを開きます
1. `Game`→`Content`→`Paks`とフォルダを移動します
1. 解凍したフォルダの中に〇〇.`pak`ファイルがあるので`Paks`フォルダにコピーします

## コマンドパレットのサイズ調整
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3844553/319bf83b-b4c3-4228-b88f-83cb1617b443.png)
1. NexusModsからZipファイルをダウンロードします
(https://www.nexusmods.com/dragonquest3remake/mods/7?tab=description)
1. ダウンロードしたzipを解凍します(右クリック→すべてを展開)
1. Steamのライブラリからゲームのローカルファイルを開きます
1. `Game`→`Content`→`Paks`とフォルダを移動します
1. 解凍したフォルダの中に〇〇.`pak`ファイルがあるので`Paks`フォルダにコピーします

## 固有アイコンの追加と文字の調整
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3844553/47e00175-abc9-4401-af13-36797094eda2.png)
1. NexusModsからZipファイルをダウンロードします
(https://www.nexusmods.com/dragonquest3remake/mods/63)
1. ダウンロードしたzipを解凍します(右クリック→すべてを展開)
1. Steamのライブラリからゲームのローカルファイルを開きます
1. `Game`→`Content`→`Paks`とフォルダを移動します
1. 解凍したフォルダの中に〇〇.`pak`ファイルがあるので`Paks`フォルダにコピーします
Terraform × CloudWatch構成でつまずいた話と対処法

---

````markdown
# Terraform × CloudWatch構成でつまずいた話と対処法【AccessDeniedException】

TerraformでCloudWatch Log GroupをIaC化しようとした際に、  
**「AccessDeniedException」** に詰まったので、原因と対処法を記録としてまとめます。

初心者にも起こりがちなミスなので、構成の参考や学びの一助になれば嬉しいです。

---

## 🔥 発生したエラー

```bash
Error: setting CloudWatch Logs Log Group retention policy: 
AccessDeniedException: User is not authorized to perform: logs:PutRetentionPolicy
````

CloudWatch Log Groupにログの保持期間（retention）を設定しようとした際に出たエラーです。

---

## 🧠 原因

以下の2点が原因でした：

1. **IAMポリシーに `logs:PutRetentionPolicy` が含まれていなかった**
2. Terraformのリソース依存関係を制御する `depends_on` を設定していなかった

---

## ✅ 対応したこと

### IAMポリシーにアクション追加

```hcl
{
  "Effect": "Allow",
  "Action": [
    "logs:PutRetentionPolicy"
  ],
  "Resource": "*"
}
```

CloudWatchログの保持期間を設定するには、
このアクションが明示的に許可されていないとTerraformから操作できません。

### Terraformに `depends_on` を追加

IAMロールが作成されてからCloudWatch Log Groupが適用されるように、以下のように追記：

```hcl
resource "aws_cloudwatch_log_group" "main" {
  name              = "/aws/ec2/high_cpu_alarm"
  retention_in_days = 7

  depends_on = [aws_iam_role.cloudwatch_logs] # ロール名に応じて変更
}
```

これにより、IAMが未反映の状態でLog Groupが先に作られるといったタイミングバグを防げます。

---

## ✍️ 学び・気づき

* `PutRetentionPolicy` はあまり目立たないが、明示的に許可しないと操作できない
* Terraformでは「順序制御」が明示されない限り、並列実行になる点に注意
* `depends_on` の活用は本番環境でも重要なIaC設計の要

---

## 💻 構成リポジトリ（GitHub公開中）

この構成のコード・設計図はすべてGitHubにて公開しています。
🔗 [terraform-aws-portfolio](https://github.com/Kkasuga904/terraform-aws-portfolio)

---

## 🙌 最後に

Terraform初心者だった自分でも、エラーにぶつかりながら学びを積み上げることで、
IaCとしての構成力を高めることができました。

同じような構成で悩んでいる方の参考になれば幸いです！

📦 Terraform構成テンプレ（解説付き）販売中！  
👉 [ココナラで購入する（1,000円）](https://coconala.com/contents/xxxxxx)

## 📦 Terraformテンプレを販売しています！

本記事の構成をベースに、再利用可能な構成テンプレートをBoothで販売しています👇

👉 [Terraform × AWS構成テンプレ（Booth）](https://awsssteraform.booth.pm/items/6994781)

- 初学者向けでも使いやすい設計
- モジュール分離済み、保守性・可搬性を意識
- 初月は購入者特典で「コードレビュー」付き

※ぜひ導入・改善のベースにご活用ください！
Jupyter Labで株価チャートの分析や予測をする練習

copilotやいろいろなブログを参考にしました。

copilotさんから以下と教えてもらい、jupyter labで実行してみました。
【copilotさんの回答】
yfinance はシンプルで使いやすく、初心者にも優しいので、株価チャートや予測の第一歩にはぴったりです。
Jupyter Labで株価チャートの分析や予測をするなら、yfinance のほうが初心者には使いやすいと思います！なぜなら、yfinance はシンプルなコードで株価データを取得でき、過去のデータだけでなくリアルタイムの株価も取得可能だからです。一方で pandas_datareader は、データの取得元が多様（Yahoo Finance、FRED、Google Trendsなど）ですが、最近はYahoo Financeとの接続に制限があるため、設定が少し複雑になることがあります。

違いを比較
項目	yfinance	pandas_datareader
データ取得元	Yahoo Finance	Yahoo Finance, FRED, Google Trendsなど
リアルタイムデータ	取得可能	一部制限あり
使いやすさ	シンプルで初心者向け	設定が必要な場合あり
インストール	pip install yfinance	pip install pandas_datareader


【実行したコード】
pip install yfinance matplotlib pandas
ソースコードにコメントは必要？それとも不要？

# はじめに
仕事がら、ほかの人が作成したプログラムを見ることが多いのですが、最近まったくソースコードにコメントがないものを見る機会がありました。
そのことを同僚に話してみたところ、「ソースコードにコメントは書くべきでない」という考え方があるのを知りました。

私自身は自分の書いたプログラムのソースコードレビューをしてもらったときに、「コメントをちゃんと書こうね」といわれたりしていました。また、見知らぬソースコードを解読するときに「少しはコメント書いてくれないと何やっているかわからないよー」と思ったりしたこともありました。なので、自分の中では「コメントはきちんと書くもの」という考えしか持っていませんでした。

そんな中で、同僚から聞いた「ソースコードにコメントは書くべきでない」という考え方にちょっとびっくりしてしまいました。ただ、インターネットなどで検索すると、「ソースコードにコメントは必要」派の考え方と、「ソースコードにコメントは不要」派の考え方の人がどちらも結構いるようで、「ふーむ、そうなんだねえ」と考えさせられました。

そこで、それぞれの考え方について調べてまとめてみようと思い、この記事を書きました。

# まずはCopilotさんに聞いてみよう
ということで、最近は調べごとの第一歩は生成AIを使うことが多いので、Copilotさんに「プログラミングをする際にソースコードにコメントをつけるのは不要という人と必須という人がいます。それぞれどういう主張なのかをまとめてください。」と聞いてみました。

その結果がこちら。

> ソースコードへのコメントの必要性については、開発者の考え方やチームの方針によって意見が分かれます。主な主張をまとめると以下のようになります。
> 
> コメント不要派の主張
> - コード自体が十分に明瞭：適切な変数名、関数名、クラス設計をすれば、コードの意図が自然に伝わるため、コメントは不要。
> - メンテナンスの手間が増える：コードが変更されたときにコメントを更新し忘れると、誤った情報を伝える可能性がある。
> - 冗長な説明が逆に読みにくくする：意味のないコメント（例：「変数 x に値を代入する」）は、コードの可読性を損ねる。
> - 良いドキュメントがあれば十分：設計書やドキュメントでコードの意図を説明すれば、コード内部のコメントは不要になる。
>
> コメント必須派の主張
> - コードの意図を明示できる：変数や関数名だけでは伝わらない背景や目的を説明できるため、理解が容易になる。
> - 複雑な処理を解説できる：アルゴリズムや最適化の意図など、コードからすぐに読み取れない情報を補足できる。
> - 他の開発者や将来の自分への助けとなる：過去に書かれたコードを見直した際に、コメントがあるとスムーズに理解できる。
> - デバッグや保守の助けになる：特定の処理がバグ回避のために存在している場合、その理由をコメントで説明することで誤った削除を防げる。
>
> どちらの立場にも合理的な理由がありますが、一般的には「コードの可読性を損なわない適切なコメント」が推奨されます。たとえば、関数の役割を簡潔に説明したり、難解なロジックに補足を入れるなど、必要最小限のコメントが最適です。実際の開発環境では、チームの方針やプロジェクトの規模に応じて適切なバランスを取ることが重要ですね。

確かにどちらのご意見もなるほどというところ。
もともと私はコメント書いたほうがいいという考えだったので、コメント必須派の主張は全部納得できるのですが、コメント不要派の意見もなるほどなーという感じでした。特に、「メンテナンスの手間が増える」「冗長な説明が逆に読みにくくする」はその通りだなと。
私自身もソースを読んでいて、「いや、このコメントの内容、ソースコード修正前古い内容のままじゃない？」とか

```
// 変数xに100を代入する
x = 100;
```
みたいなコメントを見て、「え、このコメントはいらないでしょ。」と思ったことも多数あったので、理解できるなあと思いました。

ただ、「良いドキュメントがあれば十分」という考えは、理解はできるのですが、ちょっと納得いかないところもありました。今だったら、javadocとかdoxygenとか、ソースコードコメントから仕様書を自動生成できるようなツールもあります。なので、ソースコードにきちんとコメント書いておいたら、ドキュメントは生成できるし、メンテナンスも楽なんじゃない？とか思ったり。

# Qiitaでさがしてみた
せっかくQiitaというサイトがあるので、Qiitaの中でソースコードのコメントについて書いてある記事を探してみました。

https://qiita.com/cuongtv/items/c4dff73b80f3cf3ec617

https://qiita.com/imafukuf/items/6c6d70f29638dd585127

https://qiita.com/lococo123/items/75c06aa64b616dc3a6f1

https://qiita.com/ayaniimi213/items/886753eae8affc749ec2

https://qiita.com/peko-thunder/items/544697844b607103630b

https://qiita.com/ohakutsu/items/b087e6959699769b93a6

いろいろなご意見がありますが、私は
- できる限りわかりやすいコードを書こう（変数名、関数／メソッド名、ロジックなど）
- 意味のあるコメントを書こう（ソースコードだけではわからない意図など）
- うそのコメントは書かないで！（ソースだけ直して、コメントなおさないとこれがおこる）
とおっしゃっている方が多いのかなあという印象でした。

# おわりに
いろいろとご意見はありますが、私は「コメントがないコードはだめだ！」とか「コメントを書くのは意味ない！」などと、極論で議論しないほうがいいのかなと思います。

理想論は、コメントがなくてもソースコードだけですべてが理解できることなのでしょう。
ただ、そのようなソースコードを書くのはかなりのスキルが必要なのかなと思います。そこを目指すのは重要と思いますが、わかりづらいソースを書いて「コメントを書くのは意味がない！」といって、コメントを書かないのは、それはそれでどうなんだろうと思います。

プログラミングを仕事にしている場合、ほかの人が自分のソースコードを読んで理解してもらうことは、避けられないことだと思っています。コードレビューしかり、担当者間の引継ぎ、保守しかり。

その際に、ソースコード読んでもさっぱりわからないということにならないように、わかりやすいソースコードを書くことと、意味のあるコメントを書くことの2つを気を付けながらプログラミングをするひつようがあるのだろうなーと感じました。
ログファイルを作る

# 1. はじめに
組み込み機器では「辛うじてファイルシステムはあるものの、リモートデバッグができない」ということが多いのではないでしょうか。「どこを通ったのか記録しておきたい」と毎回考えるのも面倒なので、ここにメモっておきます。

# 2.ということでコード
``` mydebug.h
// MyDebug.h
#ifndef INCLUDED_MY_DEBUG_H
#define	INCLUDED_MY_DEBUG_H

#define MyLog(format, ...) MyLogSub(__FILE__, __LINE__, format, ## __VA_ARGS__)

#ifdef __cplusplus
extern "C" {
#endif

void MyLogSub(const char* pStrFileName, const long nLine, const char* pStrFormat, ...);

#ifdef __cplusplus
}
#endif

#endif // !INCLUDED_MY_DEBUG_H
```

``` MyDebug.c
// MyDebug.c
#include <stdio.h>
#include <stdarg.h>
#include "MyDebug.h"

void MyLogSub(const char* pStrFileName, const long nLine, const char* pStrFormat, ...)
{
	va_list marker;
	FILE* fp = fopen("/tmp/debug.log", "at");
	if (fp == NULL) {
		return;
	}

	fprintf(fp, "%s %d ", pStrFileName, nLine);

	va_start(marker, pStrFormat);
	vfprintf(fp, pStrFormat, marker);
	va_end(marker);

	fprintf(fp, "\n");
	fclose(fp);
}
```

使いかた(cでもcppでもいいはず)
``` main.c
#include "MyDebug.h"

int main()
{
    MyLog("%s value = %d", "Hello, World!", 42);
}

```

# 3. その後の拡張性
現在時刻を残したり、決まったバイト数(行数)でファイルを切り替えたり、排他処理を入れたり、__func__も入れたり。
structuredCloneとObject.assignの違いとは？【JavaScript】

## はじめに

プログラミングでオブジェクトをコピーする場面って、意外とよくあります。

私自身、システム開発の中で `structuredClone` や `Object.assign` を頻繁に使っているのですが、実はずっと「この2つって何が違うの？」とモヤモヤしていました。

今回は、同じように「とりあえず使ってるけど違いはよく分かっていない」という方向けに、双方の基本的な機能・使い方と違いを丁寧に解説していきます。

## 各用語解説

- **オブジェクト**：名前や年齢など、いくつかの情報を1つにまとめた「情報のセット」

- **配列**：いくつかのデータを**順番に並べて入れる長い箱のようなもの**（たとえば、1番目・2番目・3番目…と順番で取り出せる）

- **DOM要素**：画面に表示されている文字やボタンなどの「ページの部品」

- **モダン**：昔のやり方じゃない、今っぽい「新しい機能や技術」のこと

- **ネスト**：オブジェクトや配列の中に、さらに別のオブジェクトや配列が入っている「入れ子構造」

- **ディープコピー（深いコピー）**：データの中までそっくり別のものとしてコピーする方法

- **シャローコピー（浅いコピー）**：データの表面だけをコピーして、中身は元のデータと共有している状態

## structuredClone()とは

`structuredClone()` は、**オブジェクトの「深いコピー（ディープコピー）」を作る**ためのメソッドです。

例えば、オブジェクトの中にさらにオブジェクトや配列があるような**ネスト構造**をまるごとコピーしたいときに使います。

```javascript
// {サンプルコード}
const original = { a: 1, b: { c: 2 } };
const copy = structuredClone(original);

copy.b.c = 999;

console.log(original.b.c); // 2（元の値は変わらない！）
// 上記では、b.c を変更しても元のオブジェクトには影響しないことがわかります
```

## Object.assign()とは
`Object.assign()` は、オブジェクトの「浅いコピー（シャローコピー）」を作るためのメソッドです。

こちらはネストされたオブジェクトの中身まではコピーしません。

```javascript
const original = { a: 1, b: { c: 2 } };
const copy = Object.assign({}, original);

copy.b.c = 999;

console.log(original.b.c); // 999（元の値も変わってしまう）
// b の中身（c）は同じ参照を持っているため、変更が反映されてしまいます
```

## structuredCloneとObject.assignの主な違い

| 特徴        | structuredClone | Object.assign  |
| --------- | --------------- | -------------- |
| コピーの深さ    | ディープコピー（完全コピー）  | シャローコピー（浅いコピー） |
| ネストされたデータ | 独立してコピーされる      | 元と参照が共有される     |
| 使用可能なデータ  | 関数・DOM要素など一部は不可 | 基本的に全て（ただし浅い）  |
| サポート      | モダンなブラウザで対応     | 幅広い環境で対応       |


## 応用的な使い方
### structuredClone の応用例
Webアプリで状態管理（state）を巻き戻す処理など、元のデータを安全に保存しておきたいときに便利です。

```javascript
// 状態を安全にバックアップ
const currentState = { user: { name: "Alice", score: 100 } };
const backup = structuredClone(currentState);

// 状態を変更
currentState.user.score = 50;

// 元に戻す
const restored = structuredClone(backup);
console.log(restored.user.score); // 100
```

### Object.assign の応用例
スタイルや設定の上書きに便利です。初期値に対してユーザー設定を合成する、といった用途がよくあります。

```javascript
// デフォルト設定にユーザー設定を上書き
const defaultConfig = { theme: "light", fontSize: 12 };
const userConfig = { fontSize: 16 };

const finalConfig = Object.assign({}, defaultConfig, userConfig);
console.log(finalConfig); // { theme: 'light', fontSize: 16 }
```

## おわりに
オブジェクトのコピーと一言で言っても、その挙動には大きな違いがあります。

構造が単純なときや一時的なコピーなら `Object.assign`、
安全で確実なコピーが必要なら `structuredClone` というように、使い分けがポイントです。

「なんとなく」使っていた方も、今回の解説を通じて少しでも理解が深まれば幸いです。
新卒3年目エンジニアの学習記録：学習15カ月目

# はじめに

エンジニア歴3年目のAKです。
先月に引き続き、今月に個人学習でやっていたことを記録していきます。
**活動記録なので、あまり技術関連で有用な情報はないかもしれません**。。

先月の記事です↓

https://qiita.com/AK_React/items/d399e8a806de9737398c

# 学習15か月目にやったこと

### <font color="Red">１．LP作成</font>

先月に引き続き学習の一環で進めています。（詳細は前月の記事にあります）
Next.jsを使っているのですが、ヘッダー、ファーストビュー・・と**セクションごとにコンポーネントに切り出すことで、パーツを使いまわせるのが非常に便利**です。

また、**tailwind cssを書きまくったことでデザイン実装のスピードが上がりましたし、「この要素を調整すればこんな見た目になるんじゃないか」みたいな勘が働くようになってきました**。（二カ月前までは全然書けなかったのに）
やはり手は動かすに限ります。

### <font color="Red">２．Docker環境構築＠WSL</font>
**いったい何十時間を溶かしたことでしょうか。**
「Docker入れるのにそんなかからんやろ」と思うでしょうか、じゃあどこで詰まっていたのか？
**原因はPCのスペック不足でした。**

Dockerを入れたもののやたら重い、コンテナが起動しなかったり、途中でダウンしたり。
DesktopじゃなくてCLIはどう？不要なリソース削除したら？もしかして載せているPJ上の設定が悪いの？てかそもそもDockerってなんだっけ（おい）
私のGWはすべてDockerに吸い込まれていきました。睡眠も削りました。ちょっと病みました。

これだけ色々確認したのにも関わらず、**結局PCのメモリ不足**だったようです。
気づいたきっかけは、そういえばPC全体的に重くね？→タスクマネージャー確認→メモリ使用率が95％前後だった、という流れです。
載せているPJもモノレポ構成で重めだったので、16GBのWindows PCでは厳しかったみたいです。

**結局、32GBメモリのMacBook airを注文**しました。（Proは勘弁してください）
「**スペックは積んでおいて損はない**」という先輩方からのお言葉が響きました。

### <font color="Red">３．英語でLT</font>

**Japanglish Tech Talkにて英語LTを行いました！**
テーマは「AI」ということで、**`My AI Therapist: A Love Story ～Dear AI, Am I a Good Engineer?`** というタイトルで発表をしました。

https://japanglish.connpass.com/event/348703/

ざっくり発表の内容としては、「**自信をもってSEを名乗れなかった私が、学習パートナーであるAIとのやり取りを通じて自分の在り方を見つめ、肯定し、進み続けることで今に至る**」といった感じでしょうか。

英語LTは今回が初めてだったので凄まじく緊張していましたが、「英語に自信がなくてもわかりやすい構成だった」「AIがパートナーなの共感できる」といった嬉しい声をたくさんいただきました。
**英語LTで心がけた点としては「スライド内の英語は～中学生レベルの英単語でまとめる」ことです。仮に英語が聞き取れなくても、スライドだけみれば全体の内容が入ってくるような作りにしました。**

また今回のLTを通じて、やっぱり私は英語が大好きだと思いました。（元々大学でかじってました）というわけで、**しれっと運営にもジョインしています（笑）**


# おわりに
今月はDocker一色だった気がします。。
**特に環境構築がうまくいかないって、心が折れる要因TOP3に入ってくる気がする。**
エンジニア3年目じゃなくて3カ月目の間違いじゃないかってくらい気分が落ちていたのですが、**こういうときこそ外のもくもく会に参加しまくったり、周りの人に相談しまくったりしてました**。
まさかMac購入するとは思いませんでしたが、これでやっと事が前に進みました。
**SE何年目になろうが、人を頼れることって結構大切かもしれない**ですね。
【超難関は嘘？初心者でもできる！】VMware Workstation Proの無償ダウンロード方法

【免責事項】
本投稿は正確性・完全性を保証するものではありません。
万が一、本情報に基づいて被ったいかなる損害についても、一切の責任を負いかねます。
あらかじめご了承ください。

---

## 🎥 動画で確認したい方はこちら（サムネイル付きリンク）

[![【例】VMware Workstation Proの導入手順解説](https://img.youtube.com/vi/WZeZn5pN0JM/0.jpg)](https://www.youtube.com/watch?v=WZeZn5pN0JM)

**▶ VMware Proを初めて使う方向け：ダウンロード手順をわかりやすく解説した動画です！**


---

## ✅ 概要

2024年、VMware Workstation Pro（以下：VMware Pro）が無料化されました。
個人利用・商用利用ともに無償で使えるようになったのはうれしいですが…

> **ダウンロードが超・難解！**

という声が多く聞かれます。
本記事では、「**Broadcomアカウント登録→ダウンロード→インストール**」まで、初心者でもわかるように丁寧に解説します。

---

## 📌 VMware Proとは？

VMware Pro は、**仮想マシン（VM）をローカル環境で動かせる高機能なソフトウェア**です。

| 特徴        | 内容                      |
| --------- | ----------------------- |
| 複数OSの同時実行 | 1台のPCで複数のOSを並行で動かせる     |
| テスト・開発向け  | WindowsやLinuxを切り替えて検証可能 |
| 以前は有料     | 今は**完全無料**（2024年11月～）   |

![ChatGPT Image May 10, 2025, 09_26_16 PM.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4053535/ffe4e5e6-d5fd-47f8-b685-5b5d0d20ec28.png)

---

## 😓 なぜ“超難関”と言われるのか？

* ダウンロードリンクが**Broadcomのサポートページに移動**
* 公式サイトが**英語中心**
* **アカウント登録と手続きが多い**

つまり、「**無料なのに、そもそもたどり着けない！**」状態なのです。

---

## 🛠 ダウンロード手順（ステップバイステップ）

### ① Broadcomアカウントを作成

1. [Broadcom Support Portal](https://support.broadcom.com) にアクセス
2. 「**Register（登録）**」をクリック
3. メールアドレスを入力 → 認証コードが送られる
4. 届いたコードを入力して、情報を入力
5. アカウント作成完了！

---

### ② VMware Workstation Pro を探す

1. ログイン後、右上の「**VMware Download Portal**」をクリック
2. サイドバーの「**My Downloads**」をクリック
3. 「**Free Software Downloads**」をクリック
4. 製品名に `VMware Workstation Pro` を入力
5. 検索結果から `VMware Workstation Pro for Windows` を選択

---

### ③ ダウンロードと確認作業

1. 利用規約に同意して「**Download**」ボタンをクリック
2. 追加の情報入力が求められる → 入力後、再度ダウンロードクリック
3. ダウンロードファイル（.exe）を保存（例：デスクトップ）

---

## 🖥 インストール手順

1. ダウンロードした `.exe` ファイルをダブルクリック
2. セットアップウィザードが起動
3. 利用規約に同意 → すべて「次へ」連打でOK
4. 「インストール」をクリック
5. 「完了」でセットアップ終了

---

## 🚀 起動確認と仮想マシン作成

* スタートメニュー or 検索から `VMware Workstation Pro` を起動
* UIが表示されれば成功！
* ここから仮想マシン（VM）の作成が可能です

---

## 📝 まとめ

| 項目     | ポイント                   |
| ------ | ---------------------- |
| 製品名    | VMware Workstation Pro |
| ライセンス  | **無料化（商用利用OK）**        |
| 難所     | Broadcomアカウント登録と検索手順   |
| 所要時間   | 初回登録込みで20〜30分程度        |
| 利用メリット | 複数OSの同時実行、開発・検証に最適     |

> 一度やってしまえば、次回からはスムーズにダウンロードできます！

---

## 🔗 動画リンク（再掲）

[![【例】VMware Workstation Proの導入手順解説](https://img.youtube.com/vi/WZeZn5pN0JM/0.jpg)](https://www.youtube.com/watch?v=WZeZn5pN0JM)

**▶ VMware Proを初めて使う方向け：ダウンロード手順をわかりやすく解説した動画です！**


---

## ✨ おわりに
この記事が役立ったら、いいねやストックいただけると嬉しいです！

## 主のコンテンツ
<a href="https://www.udemy.com/course/active-directory-p/?referralCode=1BC8474484DCD2814852">Active Directoryの基礎※ハンズオン形式</a>
<a href="https://www.udemy.com/course/active-directory-n/?referralCode=FF51293A35539D596A6A">Active Directoryの基礎 グループポリシー編※ハンズオン形式</a>
<a href="https://www.udemy.com/course/joshishelp/?referralCode=7ECEB242C114FA3736F8">情シスヘルプデスク入門※一部ハンズオン形式</a>
<a href="https://twitter.com/naoya_itbegin">X</a>
<a href="https://www.youtube.com/@%E7%A4%BE%E5%86%85%E3%83%8D%E3%83%83%E3%83%88%E3%83%8A%E3%83%93">Youtube</a>
AWS SAM

AWS SAM（Serverless Application Model）とは、**AWS が提供するサーバーレスアプリケーション構築のためのフレームワーク**です。Lambda や API Gateway、DynamoDB などのサーバーレスサービスを**簡単に定義・構築・デプロイ・管理できる**ようにするためのツールセットです。

---

## ✅ ざっくり一言でいうと

> \*\*「サーバーレスアプリを簡単に書いて、簡単にデプロイできる便利な仕組み」\*\*です。

---

## 📦 AWS SAM の構成要素

| 要素                   | 説明                                                 |
| -------------------- | -------------------------------------------------- |
| **SAM テンプレート（YAML）** | CloudFormation の拡張。Lambda関数やAPI Gatewayなどを簡潔に定義可能。 |
| **sam CLI**          | 開発・ビルド・ローカル実行・デプロイなどを行うコマンドラインツール。                 |
| **SAM Runtime**      | ローカル実行のときにLambdaと同じような実行環境を提供する仕組み。                |

---

## 📁 典型的なSAMプロジェクト構成

```
my-app/
├── template.yaml         # SAMテンプレート（CloudFormationの拡張）
├── hello_world/          
│   ├── app.py            # Lambda関数のコード（例：Python）
│   └── requirements.txt  # 依存パッケージ
└── events/               # テストイベントJSON
```

---

## 🛠️ よく使う `sam` CLI コマンド

| コマンド                  | 説明                      |
| --------------------- | ----------------------- |
| `sam init`            | プロジェクトの初期化（テンプレート作成）    |
| `sam build`           | Lambda関数などのビルド（依存解決など）  |
| `sam local invoke`    | ローカルでLambda関数を実行        |
| `sam local start-api` | ローカルでAPI Gatewayのように動かす |
| `sam deploy --guided` | 対話形式でデプロイ（初回向け）         |
| `sam validate`        | テンプレート構文チェック            |

---

## 💡 AWS SAM のメリット

* ✅ YAML でシンプルにインフラを記述
* ✅ Lambda/APIGW/DynamoDB/SQS などを一括管理できる
* ✅ ローカル実行＆テストが可能
* ✅ CI/CD との相性が良い（CodePipeline等と連携可能）
* ✅ CloudFormation ベースなので他のリソースとも統合しやすい

---

## 🤔 AWS CloudFormationとの違いは？

| 項目         | CloudFormation | AWS SAM            |
| ---------- | -------------- | ------------------ |
| 記述量        | 多い（冗長）         | 少ない（シンプル）          |
| ローカル実行     | できない           | 可能                 |
| Lambda用の拡張 | なし             | あり（関数・APIを簡単に記述可能） |

---

## 🧠 まとめ：AWS SAMはこんな人におすすめ！

* サーバーレスアーキテクチャ（Lambda, API Gateway など）を使いたい
* シンプルにインフラをコードで管理したい（IaC）
* ローカルでデバッグや動作確認をしたい
* 小～中規模のLambdaベースのアプリを効率的に構築したい
面倒なファイル移動を1コマンドで完了！bashスクリプトでバックアップ作業を爆速にした話（初心者）

## 💡 なぜ作ろうと思ったのか（背景）

日々の本番環境反映作業の中で、毎回このような手順を踏んでいました：

1. リモートファイルを `hoge_bk.php` としてローカルに保存
2. 差分を確認して改修分のみアップロード
3. 作業完了後、バックアップフォルダへ手動でファイルを整理

特に3の作業が地味に面倒で、複数フォルダがあると非常に時間がかかる…。
そこで「コマンド1つでこの作業を自動化できないか？」と考えたのがきっかけです。

## やってみた方法

まず「backup フォルダ名 課題名」で動かせるようスクリプトを作成。
backup.shという名前で保存。
SRCの箇所でバックアップ対象のフォルダを指定していますので適宜自分の環境に合ったものに変更してください（DESTも同様）
_bkの箇所で移動対象のファイルを識別しているのでこちらも適宜変更してください。

補足：
	•	*_bk.* にすることで「_bk付きの拡張子ファイル」を対象にしています
	•	mv を使って元ファイルを移動（コピーではない点は注意）

```bash

#!/bin/bash

# 引数チェック：第1引数がフォルダ名、第2引数が課題名
if [ -z "$1" ] || [ -z "$2" ]; then
    echo "使い方： backup フォルダ名 課題名"
    exit 1
fi

FOLDER_NAME="$1"
TITLE="$2"
TODAY=$(date +%Y%m%d)

SRC="$HOME/Documents/Projects/$FOLDER_NAME"
DEST="$HOME/Documents/backup/$FOLDER_NAME/${TODAY}_${TITLE}/"

# 指定フォルダの存在チェック
if [ ! -d "$SRC" ]; then
    echo "フォルダが存在しません: $SRC"
    exit 1
fi

# *_bk.* ファイルの検索
FOUND_FILES=$(find "$SRC" -type f -name '*_bk.*')

if [ -z "$FOUND_FILES" ]; then
    echo "⚠️ バックアップ対象（*_bk.*）のファイルが見つかりませんでした。"
    exit 1
else
    mkdir -p "$DEST"
    find "$SRC" -type f -name '*_bk.*' -exec mv {} "$DEST" \;
fi

# 成功・失敗のログ出力
if [ $? -eq 0 ]; then
    echo "✅ バックアップ完了: $DEST"
else
    echo "❌ バックアップ中にエラーが発生しました"
    exit 1
fi
```

こちらで書いたものを/Users/[username]/binフォルダに入れる。
※binフォルダを作っていなかったら下記コードをターミナルで行うか手動で作成する。
```terminal
# binフォルダを作成
mkdir -p ~/bin  

# スクリプトを移動
mv backup.sh ~/bin/  

# エイリアス設定
echo 'alias backup="~/bin/backup.sh"' >> ~/.zshrc
source ~/.zshrc

# 実行権限付与
chmod +x ~/bin/backup.sh
```

これでターミナルでbackup hoge fooを実行するとバックアップフォルダが作られそこに_bkファイルが移動する仕組みが出来上がりました。

## まとめ
これで、今まで手間だったファイル整理がたった一行で完結できました。
作業時間の短縮だけでなく、ミスの削減にもつながりました。

bashやシェルスクリプトって難しそうな印象がありましたが、
実際に使ってみると、業務に直結する強力な武器になりますね

今後も作業の自動化や効率化をテーマに、いろんなツールを試していきたいと思います！

---

🙌 「こういう工夫もあるよ」「もっとこう書けるよ」などのアドバイスがあればぜひコメントください！
Universal Dependencies 2.16リリース

[Universal Dependencies 2.16](http://hdl.handle.net/11234/1-5901)がリリースされた、との連絡をいただいた。[半年前のUniversal Dependencies 2.15](https://qiita.com/KoichiYasuoka/items/59bee9ca9fefcf4260bd)と較べて、Bokota、Esperanto、Ika、Khoekhoe、Nenets、Occitan、Odia、Old English、Sindhi、Tangkul Naga、Turkish Englishが増えており、179の言語にまたがるツリーバンクとなった。なお、Occitanについては、現代語のTolosa Treebankと、中世語のCorpus de l'Ancien Gasconの2種類が、同時リリースだが、言語としては1種類のOccitanとみなされている。また、Turkish Englishは[ISO 639-3](https://iso639-3.sil.org)の言語コードが存在せず、とりあえず[qti](https://universaldependencies.org/qti/)が割り当てられている。ちなみに、179の言語のうち、ISO 639-3の言語コードが割り当てられていないのは、以下の7言語である。


* [Frisian Dutch](https://universaldependencies.org/qfn/)
* [Kʼicheʼ](https://universaldependencies.org/quc/)
* [NArabici](https://universaldependencies.org/qaf/)
* [Pomak](https://universaldependencies.org/qpm/)
* [Telugu English](https://universaldependencies.org/qte/)
* [Turkish English](https://universaldependencies.org/qti/)
* [Turkish German](https://universaldependencies.org/qtd/)

これら7言語のUniversal Dependenciesコーパスについては、今後、ファイル名が変わる可能性があるので注意されたい。
Redis vs Memcached

「**Amazon ElastiCache for Redis**」と「**Amazon ElastiCache for Memcached**」は、どちらも**インメモリキャッシュ**サービスですが、それぞれに**得意分野・特徴・使いどころ**があります。以下に違いと使い分けの指針を示します。

---

## 🔍 主な違い（Redis vs Memcached）

| 特徴               | ElastiCache for Redis           | ElastiCache for Memcached |
| ---------------- | ------------------------------- | ------------------------- |
| データ構造            | リッチ（文字列、リスト、ハッシュ、セットなど）         | シンプル（文字列のみ）               |
| 永続化              | 対応（RDB・AOF）※ElastiCacheでは一部制限あり | 非対応（キャッシュ専用）              |
| レプリケーション         | 対応（マスタースレーブ構成）                  | 非対応（各ノード独立）               |
| スナップショット（バックアップ） | 可能                              | 不可                        |
| ストレージ容量のスケーリング   | 水平＋垂直スケーリング可能                   | 水平スケーリングのみ（シャーディング前提）     |
| 高可用性             | 自動フェイルオーバー、マルチAZ対応              | 非対応                       |
| セキュリティ           | Redis AUTH対応                    | なし（VPCなどで制御）              |
| Pub/Sub や TTL    | サポート                            | 非対応                       |

---

## 🧠 使い分けの目安

### ✅ **Redis を選ぶべきケース**

* セッション管理やユーザーデータの一時保持（例：ログインセッション）
* キューやPub/Subの仕組みをキャッシュ内で実現したい
* データの再利用頻度が高く、**高可用性や永続性が重要**
* 高度なデータ構造（例：ランキング処理、セット演算など）を活用したい
* 自動フェイルオーバーやバックアップが必要

### ✅ **Memcached を選ぶべきケース**

* シンプルな**キー／バリューのキャッシュ用途**（例：APIレスポンス、DBクエリ結果）
* データの永続性やフェイルオーバーが不要（キャッシュミスしても問題ない）
* **読み取り性能重視で、スケーラブルかつ軽量な構成が求められる**
* システム側でシャーディング制御が可能、またはそれが望ましい

---

## 💡 結論（ざっくりまとめ）

| ケース                        | 推奨エンジン      |
| -------------------------- | ----------- |
| シンプルなキャッシュ用途（DB結果、HTML）    | ✅ Memcached |
| セッションストア、ランキング、トランザクション処理  | ✅ Redis     |
| 高可用性、フェイルオーバーが必要           | ✅ Redis     |
| データの永続性やバックアップが欲しい         | ✅ Redis     |
| とにかく軽くて速い、スケーラブルなキャッシュが欲しい | ✅ Memcached |
HTML/CSSで練習用Webページを作って学んだことまとめ

## はじめに

将来的にWeb開発をしたいと考え、その第一歩としてHTMLとCSSの基礎を学びました。

学んだことをアウトプットするために、生成AIにレイアウト例を出してもらい、それを元に簡単なWebページを実装してみました。

この記事では、実装の過程でつまずいたポイントや気づきについて、備忘録も兼ねてまとめます。

## つまずいたところ

### Flexの使い方

Flexによって解決したこと

- 要素を左右や上下の端に寄せる
    
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3841606/463918a2-3620-4770-b69e-9012bf5aefff.png)
        
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3841606/16273c4a-a747-4349-9075-36ac5e16ff0e.png)
    
- 左にプロフィール画像、右にテキストを配置するレイアウト
    
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3841606/99c6af71-9eec-41d1-9c42-a70279994060.png)

`display: flex`を使うことで簡単に実現できる場面が多く、驚きました。

Flexは、要素を横や縦に並べる、端に寄せるなどの調整にとても便利だと実感しました。

### Gridの使い方

カードのような要素をタイル状に並べるときは、`display: grid`が便利でした。

Flexとの違いは、1次元か2次元かという点で、Gridを使えば縦横に整ったレイアウトがしやすくなります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3841606/b4ec5e25-49f0-4ce7-a891-2c336dac398a.png)

### オブジェクトの中央寄せ

例えば、ボタンをページの中央に配置したいとき、最初はボタン要素自体に中央寄せのCSSを書いていました。

ですが、ページの中央に配置したい場合、ボタン単体ではなく、その親要素に対して中央寄せのスタイルを指定する必要があると気づきました。

### ラベルと値を整えるレイアウト

左にラベル、右に値を表示するレイアウトでは、ラベルの文字数が異なることで右側の整列が崩れやすく、揃え方に悩みました。

その際、`<span>`を活用することで調整できることがわかりました。

文章中で細かく調整したい場合には、`<span>`が有効だと感じました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3841606/b27b6e89-989d-427b-8575-1eb756fc4668.png)



## 感想

今回は、ページの構造を意識しながらHTML/CSSを書くことを意識して取り組みました。

まだ可読性やレスポンシブ対応までは手が回りませんでしたが、実際に作ってみたことで、Webページの構造が少しずつ見えるようになってきた気がします。

まだまだ学ぶことは多いですが、今回の取り組みは自分にとって良い第一歩になったと感じています。
MySQLのストレージエンジン

MySQLの**ストレージエンジン**とは、**テーブルのデータの保存方法や管理方法を定義する仕組み**のことです。MySQLは複数のストレージエンジンをサポートしており、それぞれのエンジンに特性があります。テーブルごとに異なるストレージエンジンを使うこともできます。

---

### 主なストレージエンジンとその特徴

| エンジン名         | 特徴                                                                                         |
| ------------- | ------------------------------------------------------------------------------------------ |
| **InnoDB**    | - デフォルトのストレージエンジン（MySQL 5.5以降）<br>- トランザクション対応（ACID準拠）<br>- 外部キー制約をサポート<br>- クラッシュリカバリ機能あり |
| **MyISAM**    | - 軽量・高速だがトランザクション非対応<br>- 外部キー非対応<br>- 読み取り中心のアプリに適する                                      |
| **MEMORY**    | - データをメモリに保存（再起動でデータ消失）<br>- 高速な一時テーブル処理向き                                                 |
| **CSV**       | - データをCSVファイルとして保存<br>- 他システムとのデータ連携に向く                                                    |
| **ARCHIVE**   | - 圧縮保存されるが、INSERTとSELECTのみ対応<br>- 履歴データやログ向け                                               |
| **BLACKHOLE** | - 受け取ったデータを保存せず破棄（開発・レプリケーション用途）                                                           |

---

### ストレージエンジンの確認・変更方法

#### テーブルのストレージエンジンを確認

```sql
SHOW TABLE STATUS LIKE 'テーブル名';
```

#### 新規テーブル作成時にエンジンを指定

```sql
CREATE TABLE sample (
    id INT PRIMARY KEY,
    name VARCHAR(100)
) ENGINE=InnoDB;
```

#### 既存テーブルのエンジンを変更

```sql
ALTER TABLE sample ENGINE=MyISAM;
```

---

### まとめ

ストレージエンジンは、**用途や求められる機能（例：トランザクション、外部キー、読み取り速度など）によって使い分ける**ことが重要です。一般的にはInnoDBが標準的で多くのシーンに適していますが、特定の用途ではMyISAMやMEMORYなどの他のエンジンが適する場合もあります。
底辺エンジニアがこの先生きのこるには

# 底辺エンジニアがこの先生きのこるには

はじめまして、この記事が初投稿となります。
普段はあまり文章を書く機会がないため、読みにくい点があるかもしれませんが、どうかお付き合いください。


## 現在に至るまでの軌跡

新卒でエンジニアとして就職してから、なんとなく働き続けて約10年が経ちました。
正直なところ、特別な努力もせず、ただ日々の業務をこなすだけの毎日でした。

キャリアのスタートはSES。
主な業務はテスト作業で、技術力が身につくような環境ではありませんでした。
気づけば5年が経ち、「このままではマズい」と思い立ち、転職を決意します。

その際、「個人事業主として働くのもアリかも」と思い、某フリーランスエージェント（レ〇テック）を利用して活動してみました。

ある日、客先へ同行する際にエージェントの担当者が持っていたメモがチラッと見えました。
そこには「スキルはあまりなさそう」との記述が——。
悔しさと恥ずかしさが入り混じり、あのときの気持ちは今でも忘れられません。

結局、個人事業主としてやっていく自信を失い、ふたたび会社員として働く道を選びました。

転職活動は急ぎだったため、企業研究もそこそこにIT派遣企業へ入社。
前職が業界大手のSES企業だったこともあり、入社早々「なんでもできる人材」と思われてしまい、〇菱系列の現場に即戦力として1人で派遣されました。

しかし現実は、「即戦力」など程遠い状況。
スキル不足のまま現場に入ったため、足を引っ張ることの方が多かったです。

それでも、そこで初めて「このままでは本当にまずい」と危機感を抱き、業務に必要な知識だけでなく、自発的な学習を始めました。

現場の上長には「基本がなってない」「嘘をつかないでください」とまで言われ、心が折れそうになりながらも働き続けました。
1年後に契約が終了し、送別会の帰り際にその上長から「パワハラしてすみませんでした」と謝罪されたのは、今でも印象に残っています。

その後、いくつかの現場を経験し、少しずつではありますが、スキルも積み上がってきたように感じています。


## 本題：35歳になったエンジニアが考えるこれから

現在、35歳。
「エンジニアの定年」とも揶揄される年齢に差し掛かりました（この説の真偽はともかくとして）。

ここまで、プロジェクトのリーダー経験はありません。
上流工程の経験も乏しく、一部で基本設計を行った程度です。

現実問題として、多くの企業が求めているのは「プロジェクトを引っ張れる人材」。
自分のような、現場作業はできるがリーダー経験のない人材は、派遣先でリーダーを任されることはまずありません。

そうなると、どうしても「管理する側」ではなく「作業する側」として働き続けることになります。
35歳を超えると、単価も上がりがちなので、採用側から見て「若手でもできる仕事にわざわざ高いお金を払う意味はあるのか？」という判断になりがちです。

つまり、35歳以上でリーダー経験もなく、上流工程の実績も乏しいエンジニアが生き残るには、リーダーとしての実績がカギになると考えています。

しかし、派遣という働き方では、そういったポジションにつく機会はほとんどありません。

自分のように、これまで「のらりくらり」とやってきたタイプの人間が、いきなりリーダー職をこなすのは正直かなり難しい。
でも、もう「難しい」と言っていられる年齢でもないのです。

今、考えている選択肢は以下の2つです：
	1.	会社に相談して、リーダー経験を積ませてもらえるよう働きかける
	2.	技術者として覚悟を決め、限界までスキルを磨き続ける

この不安は、たぶんこの先も続いていくのだと思います。

でも10年後には、きっと自分なりの答えが出ているはず。
そのときにまた、この記事を読み返して答え合わせができればと思っています。


## 最後に

同じような不安を抱えている人がいれば、少しでも共感してもらえるとうれしいです。
また、何かアドバイスや経験談があれば、ぜひコメントで教えてください。
ローカル環境で過去のコミットに戻す方法／【Render】特定のコミットをデプロイする方法

# 「ローカル環境で」一時的に過去のコミットに戻す方法

VSCode　ターミナルでコマンドを実行します。
```
git checkout コミットハッシュ
```
コミットハッシュは、（GitHubにpush済みなら）GitHubのコミット画面から戻したいコミットのSHAをコピーします。


:::note warn
注意
この時、未コミットのファイルが残っているとエラーになる。コミットするか、変更を削除する。
:::


実際にはVSCodeのソース管理メニュー ＞ 戻したいコミット ＞ 右クリック ＞ チェックアウト（デタッチ済） を実行した。


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3784177/e66b42a7-5930-4678-8d6d-7786bffc3a0d.png)

runserver して確認すると戻っています。


## 最新状態への戻し方

ソース管理メニュー ＞ 変更 ＞ チェックアウト先 ＞ main を選択

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3784177/fdd0ba3e-9389-4f00-ba5a-75163c1596a6.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3784177/8a57df35-6c4d-437f-ac86-dce9b56b7087.png)


# 「Renderで」特定のコミットをデプロイする方法

過去の特定のコミットをデプロイして、本番環境で見たいとき。

Render ＞ dashboad ＞ アプリ名 ＞ Events ＞ Manual Deploy ＞ Deploy a specific commit（特定のコミットをデプロイ）


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3784177/da19745f-6760-48db-b309-da9ebaf2277e.png)

戻したいバージョンを選択してデプロイ。


# 参考
以下の記事を参考にさせていただきました。

https://zenn.dev/yutabeee/articles/034fb9383f441c#1.-git-checkout
キャッシュてなんなん

# キャッシュてなんなん

next.jsで開発中に出くわす、奇妙な動作やエラー
next.jsのキャッシュクリアコマンドで、サーバーを再起動したら
すんなり正常動作に戻ることに、ふとなぜなのか理由を知りたくなった。


以下のようなトラブルシューティングの時に特に有効

**・コードの変更が反映されない**
**・404エラーが発生する**
**・モジュールが見つからないエラーが発生する**
**・ビルドに失敗する**

## Next.jsのキャッシュについて

キャッシュについて、Claudeに噛み砕いて教えてもらったので
アウトプットしていく。
キャッシュとは、 **「再利用するために保存されたデータ」** の事らしい。
主に開発速度を向上させるために使われている。

### キャッシュはどこに溜まるの？
Next.jsプロジェクトのルートディレクトリにある、`.nextフォルダ`
別名「ビルド出力ディレクトリ」
プロジェクトをnpm run devやnpm run buildで実行すると自動的に生成されるらしい
```
.next/ 　⭐️コレ
├── cache/          # ビルドキャッシュ
├── server/         # サーバーサイドのコード
├── static/         # 静的ファイル（JS、CSS、画像など）
└── ... その他の設定ファイル
```
具体的に何が溜まるか？
↪︎ Next.jsのビルドツールが生成した全ての一時的なファイルやコンパイル済のコード、最適化されたアセット（画像やCSS）
**開発モードでは一部のキャッシュ、本番ビルドでは完全なビルド出力が含まれる**


### 開発速度を向上させてくれるいいやつなのに、なぜたまに問題を起こすの？

理由１：古いキャッシュの使用
　・コードを更新しても、古い状態のキャッシュが使われ続けてしまう
理由２：キャッシュの破損
　・開発サーバーの予期せぬ停止
　・不完全な更新
理由３：依存関係の変更
　・パッケージを更新したけど、キャッシュは古いバージョンのまま

以上のような状態では、Next.jsがファイルがあるはずと考えているところに実際はなかったりとそんな理由でエラーになったりする。

### キャッシュのクリア方法

```terminal:ターミナル
rm -rf .next

```

## 一応リスクも知っておきたいよね

#### キャッシュクリアのリスク
.nextフォルダを削除することには**ほとんどリスクは無いらしいが以下の点に気をつけるべし**


1. 時間の損失
・大規模なプロジェクトでは、最初からビルドし直すのに時間がかかる
・通常の開発では数秒〜数分程度ですが、プロジェクトサイズによる
1. 増分ビルドの恩恵が失われる
・Next.jsは通常、変更された部分だけを再ビルドする「増分ビルド」を行うらしい
・キャッシュクリアするとこの最適化が一時的に失われる
1. 本番環境での注意
・本番サーバー上で.nextを削除すると、再ビルドするまでアプリが機能しなくなる😱
・デプロイプロセス中に.nextを削除するとデプロイが失敗する可能性

## キャッシュクリア、こんな時に使おう

Next.jsの.nextフォルダがなぜ問題の原因になることがわかった今、
以下のような時はキャッシュクリアを試してみよう！

・コードの変更が反映されない
・謎の404エラーが出る
・パッケージ更新後
・設定変更時