OmniAICreator/Qiita-1.07M huggingface dataset:
# Node.jsってフレームワークですか？ランタイム環境!?ナニソレ、、、


JavaScriptを学び始めると、よく出てくるのが「Node.js」や「ランタイム環境」という言葉です。この記事では、

- JavaScriptとNode.jsの関係性
- ランタイム環境の意味
- Node.jsを使えるようにするためのセットアップ方法

について、解説します。



## JavaScriptとNode.jsの関係

### JavaScriptとは？

JavaScriptはもともと**Webブラウザ上で動くプログラミング言語**です。
Webページ上でのユーザー操作（クリック、入力など）に対して動的な処理をするのが主な役割です。

ただし、以前は**ブラウザの中でしか動かない**という制約がありました。

### Node.jsとは？

Node.jsは、**JavaScriptをブラウザの外でも動かせるようにした仕組み**です。
Google Chromeで使われている「V8エンジン」をベースにしており、PCやサーバー上でもJavaScriptを実行できます。

Node.jsの登場により、Webアプリの**サーバーサイド処理（API、データベース操作など）をJavaScriptで記述できる**ようになりました。



## ランタイム環境とは？

「ランタイム環境（Runtime Environment）」とは、**プログラムを実行するために必要な基盤や仕組み**のことを指します。

例えば：

- JavaScript：ブラウザ or Node.js
- Python：Pythonインタプリタ
- Java：JVM（Java Virtual Machine）

JavaScriptの場合、**Node.jsがランタイム環境**として機能することで、ブラウザ以外の場所でもJavaScriptを実行できるようになります。



## Node.jsのセットアップ方法

Node.jsを使えるようにするには、以下の手順で環境を整える必要があります。

### 1. Node.jsのインストール

公式サイトからNode.jsをダウンロードします。

- 公式サイト：https://nodejs.org/
- 「LTS（推奨版）」を選ぶのがおすすめです

インストールすると、Node.js本体とnpm（パッケージ管理ツール）も一緒に導入されます。

### 2. インストール確認

ターミナル（コマンドプロンプト）で以下を実行します。

```bash
node -v     # Node.jsのバージョン確認
npm -v      # npmのバージョン確認
```
どちらもバージョン番号が表示されればインストール成功です。


### 3. 動作確認（Hello World）

ファイルを1つ作ってみましょう。

`hello.js` を作成し、以下のコードを記述します。

```js
// hello.js を作成し、以下を記述
console.log('Hello, Node.js!');
```

その後、ターミナルやコマンドプロンプトで `node hello.js` を実行してください。

`Hello, Node.js!` と表示されれば、Node.jsは正しく動作しています。




## npmとは？

Node.jsと一緒にインストールされる `npm` は、JavaScript用の**パッケージ管理ツール**です。

LaravelにおけるComposerと似た役割で、ライブラリやフレームワークのインストール、依存関係の管理を行うことができます。


例：Webアプリ用のフレームワークExpressをインストールする場合
```
npm install express
````

## まとめ

| 項目 | 内容 |
|------|------|
| JavaScript | 本来はブラウザ上で動く言語 |
| Node.js | JavaScriptをブラウザの外（サーバーなど）で動かすためのランタイム環境 |
| ランタイム環境 | プログラムを実行するための土台。Node.jsもその一つ |
| HTMLとの関係 | Node.jsでも最終的にHTMLを生成・出力する場面が多い |
| セットアップ方法 | Node.js公式からインストール後、ターミナルで確認 |
| npm | パッケージの管理・導入ができる便利なツール |
Gmailの特定期間のメールをGASで一括削除する

## はじめに

こんにちは、限界ちゃんです。普段はサイバーセキュリティ関連の記事を書くことが多いですが、今回はちょっと趣向を変えて作業効率系の内容を書いてみようと思います。

実は、小学生の頃から使っているGoogleアカウントの容量がついに上限に達してしまいました。「容量が足りません」という通知を見てもずっと放置していたのですが、ある日 **「お客様宛のメールは送信者に返送され、後から復元することもできません。」** という警告が届き、さすがに焦りました。（ここまで放置するのはよくない）

「これはマズい、そろそろ本気で整理しないと…」と思い、GAS（Google Apps Script）を使って特定期間の不要なメールを一括削除するスクリプトを作成しました。

Gmailの容量不足で困っている人の参考になれば嬉しいです。（ほぼ自分用のメモです）

## Gmailの削除制限と問題点

GASでは `GmailApp.search()` を使ってメールを取得できますが、一度に取得できるスレッド数の上限は**500件**です。そのため、一回の実行だけではすべてのメールを削除できません。

そこで、500件ずつ削除を繰り返すバッチ処理を組み込み、効率的にメールを整理できるようにしました。

## GASを使ったGmailのメール削除スクリプト

このスクリプトでは、一度に最大500件のメールを取得し、削除する処理を繰り返します。Gmailの `GmailApp.search()` には**一度に取得できるスレッド数が500件まで**という制限があるため、大量のメールを削除する場合にはループ処理が必要になります。

また、削除が進むごとに `Logger.log()` を使って削除されたメールの件数を記録することで、処理の進捗が確認できるようにしています。さらに、Gmail APIにはリクエスト制限があるため、短時間で大量のリクエストを送るとエラーになる可能性があります。その対策として `Utilities.sleep(3000)` を挿入して、3秒の待機時間を設定することで、APIの制限を回避しながら安定して処理が進むようにします。

```javascript
function deleteEmails() {
  var startDate = "yyyy/mm/dd"; //削除開始日（この日以降のメールを削除）設定してね
  var endDate = "yyyy/mm/dd";   //削除終了日（この日以前のメールを削除）設定してね
  var searchQuery = "after:" + startDate + " before:" + endDate;
  var batchSize = 500;
  var deletedCount = 0;

  while (true) {
    var threads = GmailApp.search(searchQuery, 0, batchSize);
    if (threads.length === 0) {
      Logger.log("削除がおわりました: " + deletedCount);
      break;
    }

    for (var i = 0; i < threads.length; i++) {
      threads[i].moveToTrash();
    }

    deletedCount += threads.length;
    Logger.log(deletedCount + "件のスレッドを削除");
    
    Utilities.sleep(3000);
  }
}
```

## ゴミ箱のメールを消去

このスクリプトでは、削除されたメールはゴミ箱に移動するだけなので、消去したい場合はこれを追加してください。

```javascript
function emptyTrash() {
  var trashThreads = GmailApp.getTrashThreads();
  for (var i = 0; i < trashThreads.length; i++) {
    trashThreads[i].deleteForever();
  }
  Logger.log("消去完了");
}
```

もしこれがめんどくさい場合は、Gmail上のゴミ箱から「ゴミ箱を今すぐ空にする」ボタンをクリックすることでもできます。
Typora の自動画像アップロードを Qiita に設定する


# 目的

Markdown エディタとして Typora を使っています。

https://typora.io/

以前は、Typora の自動画像アップロード先を GitHub に設定していました。

https://qiita.com/khayama/items/935b97adf744645b47c9

今回は、Typora の自動画像アップロード先を Qiita に設定します。

```mermaid
graph LR

User:::hidden
Typora
Qiita

User --> |Paste Image|Typora --> |Auto Upload|Qiita
classDef hidden display: none;
```

> - [Upload Images - Typora Support](https://support.typora.io/Upload-Image/)
>
>   ![a](https://support.typora.io/media/image-upload/main.png)

# Typora カスタムアップロードコマンド設定

Typora では、カスタムアップロードコマンドの結果として返ってくる URL を画像の参照先として置換することができます。

https://support.typora.io/Upload-Image/#custom

>Typora will fetch image urls from the last N lines of the standard output of your custom command. (N is the number of images to upload).
>...
>and replace the original local images used in the Markdown document.

カスタムアップロードコマンドは `~/qiita-upload.sh` として、以下のスクリプトを活用します。

![image-20250328010112947](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101361/8bf17033-fdf5-4bb2-8fa0-972c0f11691b.png)

https://gist.github.com/kyouheiab/3153a9f1fee2f29df3cfaaa245db6772

# Qiita への投稿

Qiita 記事のドラフトとして Typora 書いた内容は `Copy as Markdown` としてコピーして、そのままペーストすることで記事を投稿できます！

![image-20250328014016020](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101361/2a49b91c-9c40-49c4-9e62-c41d8e38dc16.png)

# 参考

- [Qiitaに自動投稿と画像アップロード #Python - Qiita](https://qiita.com/6e5d/items/57c0f186a220178ec2ab)
- [Amazon S3 へのファイルアップロードで POST Policy を使うと、かゆいところに手が届くかもしれない - カミナシ エンジニアブログ](https://kaminashi-developer.hatenablog.jp/entry/2024/02/28/083000)
- [jsonファイルを環境変数に展開する #shell - Qiita](https://qiita.com/reflet/items/c2015383dc56c92db12d)
Codewars 8 kyu Total amount of points

# Codewars 8 kyu Total amount of points
https://www.codewars.com/kata/5bb904724c47249b10000131/train/python
Task
We need to write a function that takes this collection and returns the number of points our team (x) got in the championship.

# Verbalization
Split by “:”
Compare first row (use [0]) and second row (use [1]), treat [0] and [1] as number.
if x > y, add 3. if x < y, add 0, if x = y, add 1
 
# Code 
```py
def points(games):
    n = 0
    for i in games:
        i = i.split(":")
        if int(i[0]) > int(i[1]):
            n += 3
        if int(i[0]) < int(i[1]):
            n += 0
        if int(i[0]) == int(i[1]):
            n += 1
    return n
```


# Other solution.
```py
# Wow, can be solved without using “split”.
def points(games):
    result = 0
    for item in games:
	    result += 3 if item[0] > item[2] else 0     
	    result += 1 if item[0] == item[2] else 0
    return result
```
PBSのZFSデータストアの削除方法

Proxmox BSのZFSデータストアの削除方法を間違えたのでメモしておきます。
ZFSプール作成時に`データストアとして追加`にチェックを入れてデータストアを作成しているので、ZFSプールとディスクもきれいにして再度利用できる状態にします。

## 正しい削除方法

1. `proxmox-backup-manager datastore remove データストア名`
2. `zpool destroy ZFSプール名`
3. GUIの`管理-ストレージ/ディスク-/dev/sdx-ディスクの消去`


## ダメな？削除方法

### /etc/proxmox-backup/datastore.cfg から該当データストア削除しちゃうパターン

一応出来たけど、ちゃんと削除出来ていない可能性あり。
※ちなみに正しい削除方法やっても`/mnt/datastore/データストア名/`のディレクトリは残ってました。

1. `/etc/proxmox-backup/datastore.cfg` から該当データストア削除
2. `zpool destroy ZFSプール名`
3. GUIの`管理-ストレージ/ディスク-/dev/sdx-ディスクの消去`

### zpool labelclear -f /dev/sdx1 で削除出来たパターン（かなりうろ覚え）

再現性がないけど、GUIの`管理-ストレージ/ディスク-/dev/sdx-ディスクの消去`で以下が出たパターン。
`zpool destroy ZFSプール名`とかは通らなかった（はず）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2459468/371953e1-6e24-4b60-b6c7-1aaa8ece6c94.png)

ちゃんと消えてZFSとして再利用は出来た。

1. GUIの`管理-ストレージ/ディスク-/dev/sdx2-ディスクの消去`(ZFS Researvedの方)
2. `zpool labelclear -f /dev/sdx1`(ZFS Researvedではない方)
3. GUIの`管理-ストレージ/ディスク-/dev/sdx-ディスクの消去`
Python3.12でPyradiomicsを利用する

# はじめに
Python 3.12 がリリースされましたが、多くのライブラリがまだ対応していません。その中でも、Pyradiomics を使おうとするとインストールやビルドで以下のような問題が発生します。
~~~
AttributeError: module 'configparser' has no attribute 'SafeConfigParser'. Did you mean: 'ConfigParser'?
~~~

この記事では、Python 3.12 で Pyradiomics を正常に動かすための手順を解説します。

## 環境
- OS: Ubuntu 22.04
- Python: 3.12.9
- 仮想環境: venv

## 解決法
まず、pip install pyradiomicsではなく、以下を実行します。
~~~:terminal
git clone https://github.com/Radiomics/pyradiomics.git  
cd pyradiomics  
~~~

次に、Pyradiomics の versioneer.py は古い構文を使っているため、修正が必要です。

### 修正 1: configparser.SafeConfigParser の修正
versioneer.py を開いて次の行を修正します。

変更前:
~~~python:versioneer.py
parser = configparser.SafeConfigParser()  
~~~

変更後:
~~~python:versioner.py
parser = configparser.ConfigParser()  
~~~

### 修正 2: readfp() を read_file() に変更
Python 3.2 以降では readfp() は read_file() に変更されています。

変更前:
~~~python:versioneer.py
parser.readfp(f)
~~~
変更後:
~~~python:versioneer.py
parser.read_file(f)  
~~~

### pyradiomicsのインストール
cd ~/pyradiomicsを行い、以下を実行します。
~~~:terminal
pip install .  
~~~

## まとめ
この記事ではPyradiomicsをPython3.12でインストールする方法を解説した。
高火力DOKでDocker Hubの認証情報を登録してタスクを実行する

## はじめに
高火力 DOK上でDocker Hubの認証情報を登録し、プライベートイメージを用いたタスクを実行する方法について解説します。

高火力 DOKは、さくらインターネットが提供するコンテナ型GPUサービスです。
https://www.sakura.ad.jp/koukaryoku-dok/

## 前提
- 高火力 DOKのアカウントを持っている
    - [サービスを使い始めるには](https://manual.sakura.ad.jp/cloud/koukaryoku-container/getting-started.html#id11)
- Docker Hubのアカウントを持っている
    - https://hub.docker.com/

## 認証情報の登録
- [プライベートレジストリーの使用方法](https://manual.sakura.ad.jp/cloud/koukaryoku-container/using-private-registries.html)を参考に認証情報を登録します

高火力 DOKのダッシュボードにアクセスし、
サイドバーから「レジストリー認証情報」を選択したのち「新規登録」を選択します。
![registries add.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/282233/ceabfea6-d257-485e-b782-b6922ef44274.png)

レジストリー認証情報登録画面では、以下の情報を入力します。
| 項目 | 設定 |
|:-----------|:------------|
| ホスト名    | https://index.docker.io/v1/ |
| ユーザー名 | Docker Hubのユーザー名        |
| パスワード   | Docker Hubのパスワード(またはアクセストークン)  |

情報の入力が終わったら、「登録」ボタンを押します
![registries add2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/282233/cd5f9e8d-978a-445e-8083-46a33e6ab423.png)

確認画面が表示されたら、再度「登録」ボタンを押します。
![registries add3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/282233/f7eb85d3-e0ff-4d9d-9bf6-e83244c4fd7f.png)

認証情報の登録は終わりです。
![registries add４.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/282233/5bdc60dd-8f5b-4467-8937-a4c5c07039bd.png)

## プライベートイメージの実行

高火力 DOKのダッシュボードのサイドバーから
「タスク」を選択したのち「新規作成」を選択します。
![task add.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/282233/ead451e3-83c4-4273-9ed5-4a98310d257e.png)

タスク登録画面では、以下の情報を入力します。
| 項目 | 設定 | 補足 |
|:-----------|:------------|:------------|
| イメージ | <ユーザー名>/<リポジトリ>:<タグ>        |  例：fluent/fluent-bit:latest   |
| レジストリー認証情報   | 先ほど登録した認証情報          |  |

その他必要情報を入力してください。
![task add2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/282233/5116b07d-9e79-4e87-9b35-d97af4ecef2b.png)

情報の入力が終わったら、「作成」ボタンを押します

デプロイが完了すると実行中になり、ログが表示されますYatta!!!
![kidou.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/282233/b934578a-3b13-4a08-b68b-49808e693ac6.png)

### 終わるとき
:::note warn
停止を忘れると従量課金されていくので忘れずに停止しましょう
:::
高火力 DOKのダッシュボードにアクセスし、
サイドバーから「タスク」を選択したのち、今回使用したタスクを選択します。
![dok task select.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/282233/fc88942b-8275-d929-9f7b-ae2a14a8e2cc.png)
タスク詳細画面から「中断」を選択します。
![dok kill.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/282233/36c21d9b-b3f3-a27d-a2c8-5c663a7be24b.png)

## まとめ
この記事では、高火力 DOK上でDocker Hubの認証情報を登録し、プライベートイメージを用いたタスクを実行する手順を説明しました。

ここまで読んでいただきありがとうございました

## 参考文献
[高火力 DOK ドキュメント](https://manual.sakura.ad.jp/cloud/manual-koukaryoku-container.html)
[docker login](https://docs.docker.jp/engine/reference/commandline/login.html)
GitHub Actions x SAMで苦労した部分まとめ


## 概要
- 基礎を終えて、独自に構築したらめちゃ大変だったのでまとめる。
- 主に理解が浅いsam側の性であれこれ大変だった認識。

## 完成したワークフロー定義

まずは、動作する完成版のGitHub Actionsワークフロー定義を見てみる：

```yaml
name: Deploy-AWS-SAM-Application
on:
  push:
    branches:
      - 'deploy'
env:
  SAM_CLI_TELEMETRY: 0
permissions:
  id-token: write
  contents: read
jobs:
  deploy:
    runs-on: ubuntu-22.04
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-python@v3
        with:
          python-version: '3.11'
      - uses: aws-actions/setup-sam@v2
        with:
          use-installer: true
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::XXXXXXXXXX:role/XXXXXXXXXXXXXXXXXXXX
          aws-region: ap-northeast-1
          role-session-name: SamDeploy
      - name: Build and Deploy SAM Application
        working-directory: ./sam-deploy
        run: |
            # 最初のビルドとデプロイ
            sam build --template-file template.yaml
            sam deploy --no-confirm-changeset --no-fail-on-empty-changeset
            
            # 2回目のビルド前に既存のファイルをリネーム
            mv samconfig.toml samconfig.toml.bak
            mv template.yaml template.yaml.bak
            mv .aws-sam/build/template.yaml .aws-sam/build/template.yaml.bak
            
            # Edge用のビルドとデプロイ
            sam build --template-file XXXXXXXXXXX.yaml
            sam deploy --stack-name XXXXXXXXXXX --region us-east-1 --capabilities CAPABILITY_IAM --resolve-s3
```

このワークフローは、`deploy`ブランチにプッシュされたときに実行され、SAMアプリケーションを自動的にAWSにデプロイする

## 苦労ポイント1: 作業ディレクトリの指定

最初の課題は、SAM設定ファイルが特定のサブディレクトリに配置されている場合の作業ディレクトリの指定だった。

### 問題点

最初は単純に`cd ./sam-deploy`コマンドで移動しようとしたが、うまく機能しなかった。

### 解決策

GitHub Actionsには`working-directory`というパラメータがあり、これを使用することで簡単に作業ディレクトリを指定できる：

```yaml
- name: Build and Deploy SAM Application
  working-directory: ./sam-deploy
  run: |
      # コマンド...
```

これにより、すべてのコマンドが`./sam-deploy`ディレクトリから実行されるようにる。相対パスの基準点はリポジトリのルートからの相対パスとなる。

## 苦労ポイント2: 複数のSAMテンプレートを連続でビルド・デプロイする

より難しかった課題は、同じジョブ内で複数のSAMテンプレートをビルドしてデプロイする際の問題だった。

### 問題点

2回目の`sam build`実行時に、前回のビルド設定やファイルが残ってしまった。特に`samconfig.toml`の設定が引き継がれてしまい、使用していないはずのECRの設定エラーが発生した。

### 解決策

この問題を解決するために、2回目のビルド前に以前のビルド関連ファイルをリネームする方法を採用した：

```bash
# 2回目のビルド前に既存のファイルをリネーム
mv samconfig.toml samconfig.toml.bak
mv template.yaml template.yaml.bak
mv .aws-sam/build/template.yaml .aws-sam/build/template.yaml.bak
```

これにより、2回目のビルドが1回目のビルド設定の影響を受けることなく、クリーンな状態で実行できるようになった。

## 特別な要件: リージョンをまたいだデプロイ

この例では、通常のSAMアプリケーションを東京リージョン（ap-northeast-1）にデプロイした後、CloudFront + Lambda@Edge用のリソースをバージニアリージョン（us-east-1）にデプロイしている。

これは、Lambda@EdgeがCloudFrontと連携して動作するため、us-east-1リージョンにデプロイする必要があるため、2回目のデプロイでは、明示的にリージョンと追加のパラメータを指定している：

```bash
sam deploy --stack-name XXXXXXXXXXX --region us-east-1 --capabilities CAPABILITY_IAM --resolve-s3
```

## まとめ

AWS SAMアプリケーションをGitHub Actionsで自動デプロイする際には、いくつかの注意点がある：

1. 作業ディレクトリは`working-directory`パラメータで指定する
2. 複数のテンプレートをビルド・デプロイする場合は、前回のビルド設定が影響しないように注意する
3. リージョンをまたいだデプロイが必要な場合は、適切なパラメータを指定する

後はSAMの仕様をきちんと理解することが大事、、
レビューを受ける側として気をつけてきたことの雑記

### はじめに

これまでレビューを受ける側（レビューイ）としてやってきた工夫を整理します。

観点が混ざるとややこしくなりそうなので、レビューをする側（レビュアー）としての工夫は別記事にします。

プログラム等のレビューに限らず、資料作成などにも通じるものとして書いているつもりですが、半ば無意識にプログラミングを前提にしている項目もあるかも。

2025/04/05 追記

レビューをする側の別記事を作成しました↓

https://qiita.com/fujithuro/items/d76d0fa6db56b2991d9f


### レビュー依頼を出すまで編

#### できれば小さい単位で

変更量の多いレビューは、見るのがとても大変です。あまり大きすぎると、細かいところまで気を回せなくなる場合もあります。

どれくらいのボリュームが適切かは状況によっても違うでしょうけど、悩んだ時は「できれば小さい単位で」を一つの指標にできるかなと。
小さくなりすぎて問題になったら、その時に改めるくらいで丁度いいかもしれません。

特に、大きな手戻りが発生するような事態は避けるべきです。

例えば2週間かけて書き上げた、もうほとんど出来上がってますみたいなコードがそれまで一度もレビューされておらず、いざレビューに回ってきた時に「これ、そもそもの設計がマズいのでは？」みたいなちゃぶ台返しが発生すると、大幅な手戻りになってとても辛いことになります。
大きめの判断については、早い段階で人に相談するなりレビューに出すなりしましょう。

「大きめの設計や実装を3日誰にも見せてない（1人だけで作業してる）のはマズい」みたいな定量的な指標をチームで設けてもいいかもしれませんね。


#### 持っている情報は明確に伝える

情報が足りないと、レビュアーが想像するか、作業者（レビューイ）に聞くかしないといけないけど、どちらもあまり効率が良くないです。
もちろん、内容に疑問があってレビュアーから質問がいくのは普通のことですが、できれば先回りで「疑問に思いそうな箇所」は補って、質問が少なく済むと親切。

持っている情報、の具体的な例は、参考にした資料や、作業の前提となる情報など。

* 他システムとの連携を行う場合、連携相手の仕様が分かるようにする、とか
* こういう方針で作業しました、とか
  * 設計の打ち合わせをやったときのホワイトボードなど
* こういう作業がまだ残ってます／この作業はもう終わってます、とか
  * これがないと、漏れているのか、後でやる予定なのか等が分からない


進捗を示す場合、具体的に何が終わっていて何が残っているのか明示されると親切です。
例えば何らかのマスター保守画面を作成する場合なら↓のような感じ。

```md
1. マスターを作成する（テーブル作成のDDLなど）
2. 参照系のバックエンド処理を作成する <- 今ココです
3. 更新系のバックエンド処理を作成する
4. フロントエンドを作成する
```

#### 特に見て欲しいところや懸念点があればハッキリ書く

例えば「テストパターンが十分足りているか少し不安です」など懸念点が示されていれば、レビュアーもそこを気にして見るので、的確なフィードバックをもらいやすくなります。

注意点として、「不具合がないか確認して欲しい」と書きたくなったら、それは原則として実装者の責務のはずなので自分でやりましょう。
「自分でも全力を尽くしたつもりだけど、複雑なロジックなのでレビュアーさんの力も借りたい」とかならOKかも？

逆に、「まだあまり動作確認できていないザックリの実装なので、バグってないかの観点は一旦いらないです。大きな処理の流れに問題ないかを見てもらいたいです」とか、そういうのはあって良い。

何を見てもらいたいのかを明確にするのは大事です。


#### 面倒くさがらない

ここまでに書いてきたことを「ちゃんとやる」のって、結構面倒くさいです。

でも、実装者にとって「ちゃんと説明するのが面倒」な内容は、レビュアーが理解するのはもっと面倒（大変）です。
レビュアーの負荷軽減のためにも、情報をきちんと残す意味でも、「ちゃんとやる」のはとても大事です。

ちなみに、最初の「できれば小さい単位で」を意識できていると「ちゃんと説明する」ことの大変さも少し軽減されるかも。

あとは、コードレビューを依頼するときのテンプレートを用意しておいたり、過去の類似レビューを真似るなどすれば「ゼロから全部自分で書く」必要がなくなるので、コストを下げられます。


### 指摘を受けてから編

#### 納得していないなら修正しない

よく分かっていないのに、「レビュアーの人がそう言うならそうなんだろう」みたいな姿勢で対応しない。

忙しかったり、とにかく目先の仕事をやっつけたい時に起こりがち。
あとはレビュアーの方が組織上の立場が上なことも多いと思うので、そういう場合も起こりがち。
でもこれだと、チーム内での知識共有に繋がらない。

指摘内容がよく分からないなら、納得できるまで質問する。
そうでないと、成長の機会を逃すことになります。


#### 質問に「修正しました」で返さない

先程の「納得していないなら修正しない」にも近い話ですが、例えば「このパターンではXXXを使うことが多いと思いますが、そうしなかった意図がありますか？」みたいな質問をもらったとして「XXXを使うように修正しました」とだけ返すと、納得した上での変更なのか「言われたからその通りに直した」のかがレビュアーに伝わらないです。

修正する場合も「〇〇だと思ってこう書いてたんですが、確かにXXXの方が良さそうなので修正しました」みたいにやり取りできると、受け手（レビュアー）の印象はかなり違います。
【Zed】修飾キー を押下しているときのみ編集予測が表示されるようにする方法

## 設定ファイルに記述

設定ファイルに以下を追記すると修飾キー を押下しているときのみ編集予測が表示されるようになります。

```jsonc:settings.json
{
  "features": {
    "edit_prediction_provider": "zed"
  },
  "edit_predictions": {
    "mode": "subtle"
  },
}
```

## ステータスバーから設定

ステータスバーの「Edit Prediction」ボタンを押下し、「Display Modes」の「Subtle」を選択することでも同様に設定可能です。

![screen-shot-27.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342443/6c86f0bc-074e-454e-93f5-9acb4e81f7f3.png)

![screen-shot-26.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342443/b8c8dd77-1155-4fc7-8c35-2dcc420424d2.png)

## 参考

https://zed.dev/blog/out-of-your-face-ai

https://zed.dev/docs/completions#switching-modes
【WSL2エラー解決】「system.vhd をアタッチできませんでした」「ERROR_FILE_NOT_FOUND」の対処法まとめ

# ある日突然 Windowsのubunts が起動しない…

いつも通り Windowsで Ubuntu を使おうとしたら、こんなエラーに遭遇しました：
```
ディスク 'C:\Program Files\WSL\system.vhd' を WSL2 にアタッチできませんでした: 指定されたファイルが見つかりません。
エラー コード: Wsl/Service/CreateInstance/CreateVm/MountVhd/HCS/ERROR_FILE_NOT_FOUND
Press any key to continue..
```

自分は特にアップデートや設定変更をしていないのに、突然このエラーが出るようになりました。

調べたところ、system.vhd ファイルが存在しない、もしくは壊れていることが原因のようです。
この記事ではこの問題の簡単な復旧方法をご紹介します。


## 環境
OS：Windows 11

状況：Windows で Ubuntu を起動しようとしたときにエラー発生

エラー内容：system.vhd が存在しない旨のエラー

## 原因
C:\Program Files\WSL\system.vhd という仮想ディスクが何らかの理由で削除または破損してしまい、WSL2 が起動できなくなっている状態です。

## 解決手順
以下の手順で、system.vhd を復元し、WSL2 を再度正常に動作させることができました.

### 1. system.vhd が存在しないことを確認
まずは以下のパスにファイルがあるか確認します：
```
C:\Program Files\WSL\system.vhd
```

### 2.公式 GitHub リポジトリから、最新の WSL の .msi インストーラをダウンロード
 https://github.com/microsoft/WSL

ページ内の「Releases」から2.4.13を探してダウンロードします。

### 3. 適当な作業ディレクトリに移動
ダウンロードフォルダにある「wsl.2.4.13.0.x64.msi」を
C:\wslErrorFolder にファイルを移動します。

:::note info
wslErrorFolderは自分で作成したフォルダです。
:::

### 4. コマンドプロンプトを起動
次のコマンドで .msi を展開します：
```
msiexec /a C:\wslErrorFolder\wsl-2.1.5.0.msi /qb TARGETDIR=C:\wslErrorFolder\wsl
```
TARGETDIRで指定した場所に展開できます。任意の場所で大丈夫です。

### 5. 展開された中から system.vhd を探す
以下のパスにあるはずです（x64 の場合）：
C:\wslErrorFolder(任意のフォルダ)\wsl\PFiles64\WSL\system.vhd

### 6. system.vhd を元の場所にコピー
最後に、system.vhd を次の場所にコピーします：
```
copy C:\wslErrorFolder\wsl\PFiles64\WSL\system.vhd "C:\Program Files\WSL\"
```

### 7. WSL を起動して動作確認
もう一度 Ubuntu などの WSL を起動して、正常に動作するか確認します

:::note info
お知らせ
この方法は WSL の完全な再インストールではないので、既存のファイルやフォルダが削除されることはありません。
:::

:::note warn
注意
万が一に備えて、WSL のバックアップはとることをおすすめします。
:::
タスク漏れを防ぐ！ToDoとスケジュールで仕事を効率的に進める方法☆


# １年間タスク管理を続けてきて感じたこと

今回は個人的にタスク管理を１年間意識して続けてきて良かった点をまとめます！

2024年の4月から社会人２年目になるにあたって、
タスク管理のスキルアップ向上を目標の１つに掲げて、

:::note info
・ToDo管理
・タスクの優先順位
:::

の2点を意識して取り組んできました。

１年間タスク管理を続けてきて良かったことは、


:::note info
・業務の効率が上がった
・いつまでに何をやればいいか明確になった
・タスクの優先順位がはっきりした
・自分ですべきタスクと他のメンバーに依頼する内容を整理できた
・タスクの抜け漏れがなくなった
・突発的なタスクにも柔軟に対応できた
:::

などたくさんありました！

具体的にどのようなタスクの管理をしてきたか、
簡単に２つのことを記述していきます！

# 1.タスク整理

まずタスクの整理については、
私はobsibianの表機能を活用していました

https://obsidian.md/

以下のような項目を持った表を作成して、管理していました。
obsibinの表機能は簡単に**並び替え**ができるので便利です！

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3509157/9dc8832a-5a7c-4148-8e75-c3b8b6d16650.png)

タスク整理するうえで意識した点は、

:::note info
1.「タスクが発生したらすぐこの表に追加する」
2.「取り組むべきタスク順に並び替えをする」
:::

ことです。

1を徹底することでタスク漏れを防ぐことができます。
やるべきことあった気がするけど何だったっけ？という現象を無くすことができました！

2に関しては、次の「デイリー作業スケジュール」に繋がるので後述します。

また、タスク整理するうえで、大きいタスクだと、
細かいタスクに分解して記載することも意識していました。

例えば、エラー対応だと、
<blockquote>
・エラー対応

→　原因調査
→　原因整理
→　対応
→　レビュー依頼
</blockquote>
のような分け方です。

# 2.デイリー作業スケジュール

続いては「いつ、なにをするか」を明確にする作業です。

とにかく1で作成したタスク表をもとにして、何時にどのタスクをするかを立てていきます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3509157/483da80c-0a56-4437-ac8f-ed385b455708.png)

ここで大切なのは、とにかく一旦決めることです。

時間を区切ることで、淡々と仕事を進めるのではなく、
その時間までに終わらせようという意識でタスクを進めることができます。

また、
タスクに手を付ける前に、
その日中にどこまでタスクを進めることができそうか目途が立つことと、
毎日継続してスケジュールを作成することで作業工数を見積もる力がつくなどのメリットも！

ただし、仕事をしていると、急遽緊急のタスクが発生する場合もあります。
そういう場合でも、1のタスク表に追加して、優先度を考慮して、都度2のスケジュールを修正する
という流れで解決していきます。

あと1つ、スケジュール作成をするうえで意識したことは、
よく言われる「緊急度が低いけど、重要度の高いタスク」
をタスク表に置いたままにはしないということです。

タスク表だけを作った状態だと、期限の近いタスクを淡々とこなしていくことが多いため、
永遠に後回しになることが多いように感じます。

そこで、そのようなタスクもスケジュールに組み込むことで、
タスク表に置いたままにすることなく時間を確保できました！


# おわりに

この１年間タスク管理を意識的に続けてきて、
複数のタスクを並行して進める場合にも冷静にどのタスクに取り組むべきかが
整理されて、効率よく対応することができるようになりました！

今まではタスクを複数抱えている場合だと、やることが多いというストレスから
タスクを進めることに100%の意識を注ぐことができていなかったように感じます。

実際に手を動かして見ればすぐに終わるケースも多いですし、
とにかく頭をすっきりした状態で何事も取り組むことが大切だと思います！

自分のタスクだけでなく、プロジェクト全体として何を優先すべきかを
考えながらより良い選択をしていけるように今後も励んでいきます。

最後まで読んでいただきありがとうございました！
TypeScript:3.classListとCSSセレクタ

# classListとは
・HTMLElementが持っている「クラスの一覧（リスト）」を表すプロパティ
・クラスを追加、削除、切り替え、チェックするためなどのメソッドが用意されている
```typescript:exe.ts
<div class="food hidden active"></div>
```
上記は"food hidden active"という３つのクラスがあるが
JavaScriptやTypeScriptではこれを classList を使ってリストして扱う事ができる



### よく使うclassListのメソッド一覧
・add()	クラスを追加	element.classList.add('active')
・remove()	クラスを削除	element.classList.remove('active')
・toggle()	クラスをON/OFF切り替え	element.classList.toggle('active')
・contains()	指定のクラスを持ってるかチェック　　　　
element.classList.contains('active') → true/false

## 具体例
```typescript:exe.ts
const div = document.querySelector('.food') as HTMLDivElement;

//クラスを追加
div.classList.add('active'); // class="food active"

//クラスを削除
div.classList.remove('food'); // class= "active"

//クラスが含まれてる確認
if (div.classList.contains('active')){
    console.log('アクティブ状態です');
}

// クラスをON/OFF切り替え（トグル）
div.classList.toggle('hidden');// class="active hidden" または class="activr"
```

### まとめ：classListとは？
何を表す？　
　HTML要素のclass属性を「リスト」として扱うもの
 
 何ができる？
 　クラスの追加・削除・切り替え・確認

  どんな時に使う？
  　見た目を切り替える、アニメーション、状態管理などに便利

   ## 疑問：なぜ classList.add('food--active') の引数は .food--active（ドット付き）じゃなくていいの？

### 結論：classList.add()に渡すのは「クラス名」そのものだからドット「.」は不要である

比較して理解しよう
・CSSのセレクタ　.food--active{...}
ドットはクラスを意味しておりCSSクラスタクラス以外も指定する場合があるためクラスを指定する場合クラスを意味するドットを付与しなければならない。

・JavaScriptのclassList classList.add('food--active')
ドットなしでクラス名のそのものを指定
classListはクラスを操作するためのものすなわちクラスを指定する前提のプロパティのためクラス名だけでよい。

## 例
```typescript:exe.ts
this.foods = document.querySelectorAll<HTMLDivElement>('.food');
```
上記はCSSセレクタの文法を使って、HTMLの要素を検索している。
そのためクラスを指定する場合はクラスを意味する「.」が必要

セレクタの書き方
・.food	class="food" の要素を探す
・#main	id="main" の要素を探す
・div	全てのdiv要素を探す
・ul > li	ulの直下のli要素を探す

## まとめ

シーン	目的	書き方	ドット必要？	理由
querySelectorAll()	要素を検索（セレクタ指定）	.food	✅ 要る	CSSセレクタのルールだから
classList.add()	クラス名を追加	'food'	❌ 要らない	単なる名前（文字列）だから
| シーン | 目的 | 書き方 | ドット必要 | 理由 |
|:-:|:-:|:-:|:-:|:-:|
| querySelectorAll()  |  要素を検索(セレクタ指定) | .food  | 要る  | CSSセレクタのルールだから  |
|  classList.add() |  クラス名を追加 |  'food' | 要らない  |  クラス名を指定するものだから |
セキュリティ分野の学習ロードマップ

はじめに

応用情報技術者試験（午後）のセキュリティ分野では、暗号技術・認証・アクセス制御・攻撃手法など、幅広い知識が求められます。本記事では、それぞれの技術の意味や背景を整理し、効率的な学習ロードマップを紹介します。

## 1. 暗号技術（基礎から実践）

🔹 なぜ暗号が必要なのか？ → どの方式がどう違うのか？ → 実際の活用例

🔑 暗号の基本（情報を秘匿する技術）

暗号技術は、データの盗聴・改ざんを防ぐための基礎技術です。
	•	共通鍵暗号方式 → 送信者と受信者が同じ鍵を使う（AES, DES など）
	•	公開鍵暗号方式 → 送信者と受信者が異なる鍵を使う（RSA, ECC など）
	•	ハイブリッド鍵暗号 → 共通鍵と公開鍵を組み合わせて効率化（TLS など）
	•	ブロック暗号 / ストリーム暗号 → 暗号化の方法（ブロックごとか、連続的か）

📌 ポイント
	•	共通鍵暗号は処理が速いが、鍵の安全な共有が課題
	•	公開鍵暗号は安全性が高いが、計算コストが高い
	•	実際のシステム（HTTPSなど）では、ハイブリッド鍵暗号が使われる

⸻

🔑 鍵交換と管理（安全な鍵のやり取り）

暗号を使うためには、安全に鍵を交換する方法が必要。
	•	DH法（Diffie-Hellman） → ネットワーク上で安全に鍵を共有する技術
	•	KDC（鍵配布センター） → 信頼できる第三者が鍵を配布する仕組み（Kerberos など）

📌 ポイント
	•	DH法は通信経路上で鍵をやり取りするが、盗聴には弱い（MITM攻撃）
	•	KDCはサーバーが鍵を管理するため、管理の負担が大きい

⸻

🔑 認証とハッシュ（改ざんやなりすまし防止）
	•	ハッシュ関数 → データの指紋を作る技術（SHA-256 など）
	•	メッセージ認証（MAC, HMAC） → メッセージが改ざんされていないかを確認
	•	デジタル署名 → 送信者の本人証明＋データの改ざん防止
	•	タイムスタンプ → いつ作られたデータか証明（電子契約などに活用）

📌 ポイント
	•	ハッシュ関数は「一方向」のみ（元のデータは復元できない）
	•	デジタル署名は「本人確認＋改ざん検知」

⸻

🔑 PKI（公開鍵基盤）と認証局
	•	PKI（Public Key Infrastructure） → 公開鍵の信頼性を保証する仕組み
	•	認証局（CA, Certificate Authority） → 信頼できる第三者が証明書を発行
	•	OCSPステープリング → 証明書の有効性を即座に確認する技術
	•	Certificate Transparency → 不正な証明書の発行を防ぐ仕組み

📌 ポイント
	•	PKIはインターネットのセキュリティを支える重要技術（HTTPS, 電子契約など）
	•	証明書の有効性を確認する方法を理解する（CRL, OCSP など）

⸻

## 2. 認証技術（なりすましを防ぐ技術）

🔹 なぜ認証が必要か？ → どの方法が安全か？ → 実際のサービスでの活用例

👤 ユーザー認証の基礎
	•	ベーシック認証 → IDとパスワードを送るだけ（HTTP基本認証）
	•	チャレンジレスポンス認証 → パスワードを直接送らない方式（Digest認証）
	•	ワンタイムパスワード（OTP, s/key, HOTP, TOTP） → 毎回異なるパスワードを生成
	•	パスワード管理（LDAP） → 大規模ユーザー管理に利用

⸻

🌐 ネットワーク認証技術
	•	IEEE802.1X → 有線/無線ネットワークでの認証（企業のWi-Fiなど）
	•	シングルサインオン（SSO） → 一度のログインで複数のサービスを利用（Google, Microsoft）
	•	ケルベロス認証 → KDCを使った認証（Windows Active Directory など）
	•	SAML → Webサービス間の認証連携（クラウドサービスのログインなど）

📌 ポイント
	•	SSOを使うと、ログインの手間を省きつつセキュリティを向上できる

⸻

## 3. アクセス制御とセキュアOS（権限管理）

🔹 誰が何をできるかを管理する技術
	•	ラベル式アクセス制御（MAC） → 軍事レベルの厳格な制御
	•	ロールベースアクセス制御（RBAC） → 役職ごとにアクセス権を割り当て（企業のシステム管理）

⸻

## 4. 攻撃手法と対策

🔹 攻撃の仕組みを知り、事前に対策する
	•	ポートスキャン → 開いているポートを探す
	•	ウォーターホール攻撃 → 特定サイトを狙う攻撃
	•	エクスプロイトコード / バックドア / 踏み台 → 不正アクセスの手法

⸻

## 5. ハードウェアセキュリティ

🔹 物理的なセキュリティ対策
	•	TPM（Trusted Platform Module） → PC内部の暗号鍵を安全に管理

⸻

学習ロードマップ（優先度順）

✅ まず学ぶべきこと
	1.	暗号技術（共通鍵・公開鍵・PKI）
	2.	認証技術（SSO, LDAP, ケルベロス）
	3.	アクセス制御（RBAC, セキュアOS）
	4.	攻撃手法（ポートスキャン, マルウェア, パスワード攻撃）

✅ 余裕があれば学ぶこと
	•	OCSP, Certificate Transparency, TPM

⸻

まとめ

セキュリティは範囲が広いですが、体系的に学ぶことで効率よく理解できます。本記事を参考に、応用情報の午後対策を進めてみてください！
【React】タイマーアプリを作ってuseEffectのロジックに慣れよう

前提
TypeScriptの利用部分は簡単な説明にとどめます🙇
Nextで作りましたが、react18以降であれば同じコードで動作すると思います。
---

## 完成品

![画面録画 2025-03-27 224749.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3909033/f19b8db2-4203-430f-b8fb-da35bf129e49.gif)


## 機能要件

- 「スタート」ボタンを押すと、1秒ごとに秒数が増える
- 「ストップ」ボタンを押すと、カウントが停止する
- 「リセット」ボタンを押すと、秒数が0に戻る＆停止状態になる

## 非機能要件

- ボタンの状態に応じて「スタート/ストップ」が切り替わる
- カウントは`setInterval`で実行されるが、重複せず常に1つのインスタンスのみで動作
- ステートや副作用の管理は`useEffect`と`useState`を活用

---

## まずはコードの全体像

```tsx
import { NextPage } from 'next';
import { useEffect, useState } from 'react';
import Button from '@/components/common/parts/Button';

const Page: NextPage = () => {
  const [seconds, setTime] = useState(0);
  const [isActive, setIsActive] = useState(false);

  useEffect(() => {
    // 初期状態は undefined、setInterval の戻り値で上書きする
    let interval: NodeJS.Timeout | undefined = undefined;

    if (isActive) {
      // スタート時：1秒ごとにカウントアップ
      interval = setInterval(() => {
        setTime((prev) => prev + 1);
      }, 1000);
    } else if (!isActive && seconds !== 0) {
      // 停止時：前回の setInterval を停止
      clearInterval(interval);
    }

    // クリーンアップ関数：再実行やアンマウント時に前の interval を停止
    return () => clearInterval(interval);
  }, [isActive, seconds]);

  const handleClickToggle = () => {
    setIsActive((prev) => !prev);
  };

  const handleClickReset = () => {
    setTime(0);
    setIsActive(false);
  };

  return (
    <div className="mx-auto max-w-4xl">
      <div className="mt-10 flex justify-center gap-x-8">
        <div>
          <h3>時間: {seconds}</h3>
        </div>
        <div className="ml-10 flex gap-x-8">
          <Button
            variant="text"
            label={isActive ? 'ストップ' : 'スタート'}
            onClick={handleClickToggle}
          />
          <Button variant="text" label="リセット" onClick={handleClickReset} />
        </div>
      </div>
    </div>
  );
};

export default Page;
```

---

## 簡単な説明

このコンポーネントは、「タイマーの状態（動作中 or 停止中）」と「経過秒数」という2つの状態を管理しています。ユーザー操作（スタート/ストップ/リセット）に応じて、タイマーの実行・停止・リセットを切り替える処理を`useEffect`内で制御しています。

---

## ロジック詳細

- `isActive` の状態が変化するたびに `useEffect` が実行されます。
- `setInterval` は毎秒1回、カウントアップ処理を行います。
- `useEffect`のクリーンアップ関数（`return () => clearInterval(...)`）を活用し、常に古いタイマーを解除してから新しいタイマーを開始することで、**重複して複数のタイマーが走ることを防いでいます**。
- `seconds` が変わることで `useEffect` は再実行されますが、そのたびに前回のタイマーが正しく停止されているため、ロジックは安全に保たれます。

---

## 細かい部分の解説

### タイマーIDの型について

```ts
let interval: NodeJS.Timeout | undefined = undefined;
```

- `setInterval` の戻り値の型は `NodeJS.Timeout`
- 初期はタイマーが存在しないので、型として `undefined` を含める
- `= undefined` と明示しているのは、初期状態を明確にするためです

### 条件分岐：ストップ処理

```ts
else if (!isActive && seconds !== 0) {
  clearInterval(interval);
}
```

- 停止状態（`!isActive`）かつ、秒数が0でない場合だけ `clearInterval` を呼びます
- これは「すでにタイマーが動いていた場合のみ、止める必要がある」からです

### クリーンアップ関数のタイミング

```ts
return () => clearInterval(interval);
```

- `useEffect`が再実行される直前に必ず呼ばれます
- 前の `setInterval` を明示的に解除することで、**タイマーが多重に動作するのを防ぎます**
- `ポイント！！`このコードだと毎秒secondsが変わるため、毎秒useeffectが走り新しいintervalが作成されちゃうからintervalが重なってバグるのでは？と思う方もいるでしょう。・
    - その対策で再度useeffectが走る前にクリーンアップ関数で前のintervalを削除しています。少し凍のロジックがややこしいですね。

---

## コメント・フィードバック歓迎

補足や疑問点、もっと良い書き方があればぜひコメントお願いします！
超初心者エンジニアが入社５ヶ月目でクライアントからの要望をcursorのみで改修

# 管理画面の改修で学んだこと（初心者 + AI活用編）

## 🔰 状況
ゲームの管理画面（php、cakephp、Laragon）
業務で初めて既存の管理画面を自走で修正するタスクがきた。

## 🤔 分からなかったこと
- どのファイルを見ればいいのか
- viewとcontrollerのつながり
- CSSの当て方

## 🤖 AI（Cursor）に助けてもらったこと
- 要望の画面イメージを投げて構造案をもらった
- 他の機能実装を渡し、参考にしながら追加してくれとお願いした
- 既存のindex/editを渡して、コードの流れを解説してもらった

## ✅ 最終的にやったこと
- 他の機能で実装されていないCSSを削除
- controllerに要望機能追加
- CSSを一部改修
- ローカルで要件通りの動作を確認

## 🧠 学び
AIはすごい。
でも、どのファイルが何をしているか理解した前提じゃないと、的確な要望を伝えられない。
最悪、上司にコードレビューして貰えばいいので思い切って、AIの改修した内容を適応させてみればいいと思う。だが、上司になぜこのコードを実装したのかを聞かれた時に答えられるように、実装させたコードの理解をする必要がある。
この工程は、今の未経験エンジニアが将来、AIを使用を前提としたAI駆動開発の最前線で活躍できる最強兵士として生き残っていけるのではないかと思っている。
リモートデスクトップ接続について

## はじめに
リモートデスクトップ接続時、コンピュータ名、ユーザ名、パスワードを入力しますが、それは何かを記載します。
しっかり入力手順があれば全く問題ないですが、現場によっては全く説明がない場合や、自身のユーザ名を入力するとか曖昧な説明だけの場合がありますのでメモっておきます。


## リモートデスクトップ接続の基本

Windows 11 に標準搭載されている **リモートデスクトップ接続（RDP）** は、対象のPCにログインするためのユーザー名とパスワードを要求します。このときのユーザー認証には、以下のような2種類の環境が考えられます：

---

### ① **ワークグループ環境**
（家庭用や小規模なネットワーク）

- 各PCが独立しており、**ローカルユーザーアカウント**でログインします。
- ユーザー名の形式：
  - `PC名\ユーザー名` 例: `MyPC\Administrator`
  - もしくは `.\ユーザー名` とすると「ローカルのユーザー」という意味になります（例: `.\Administrator`）

---

### ② **ドメイン環境（AD環境）**
（Active Directory：企業ネットワークなど）

- ユーザー管理はドメインコントローラ（サーバー）に集約されています。
- ユーザー名の形式：
  - `ドメイン名\ユーザー名` 例: `CORP\yamada`
  - または `yamada@corp.local` のようなUPN形式も使われます


**PC名\ユーザー名の場合は、ワークグループ環境で接続しています。**
以下はその記載をさせて頂きます。


## ユーザ名、パスワード
ユーザ名、パスワードは当たり前ですが接続先の情報です！

| 書き方 | 実際の意味 |
|--------|-------------|
| `PC123\BatchRunner` | 接続先PC（PC123）のローカルユーザー BatchRunner |
| `.\BatchRunner` | 同じく「接続先PCの BatchRunner」ユーザー |



 `.\ユーザー名` は「**そのPC（接続先）のローカルユーザー**」を意味します。
- なので、以下の2つは完全に同じ意味です（接続先が PC123 の場合）：

`PC名\ユーザー名` で入力する場合、  
`.\ユーザー名` と書けば、**接続先のPC名が補完されて、`PC名\ユーザー名` と同じ意味になります**。


#### ■ `.\Administrator` の意味
- `.`（ドット）は「**現在接続しようとしているコンピュータ自身**」を意味します。
- つまり、**接続先（IP指定したサーバー）側のローカルアカウント**という指定です。

たとえば：

| 項目 | 意味 |
|------|------|
| 接続先IP | `192.168.1.100` |
| ユーザー名 | `.\Administrator` |
| 実際に接続されるユーザー | `192.168.1.100` 上の `Administrator` アカウント |



 **`.\Administrator` は自分のPCのアカウントではなく、接続先サーバーのアカウントです。**



### 状況別のユーザー名指定

| 入力形式 | 意味 |
|----------|------|
| `ドメイン名\ユーザー名` | ドメイン（Active Directory）のユーザーを指定（例：`CORP\yamada`） |
| `PC名\ユーザー名` | 接続先PCのローカルユーザーを明示的に指定（例：`PC001\BatchRunner`） |
| `.\ユーザー名` | **接続先PCのローカルユーザーを省略形式で指定**（例：`.\BatchRunner`） |



- リモート接続時、接続先IPが例えば `192.168.10.5` だとすると、
  - `.\BatchRunner` → `192.168.10.5\BatchRunner` と同義になります
- **接続元PCとは一切関係なく、あくまで接続先（指定したIPアドレスのPC）に存在するユーザーアカウントを指定している** という点がポイントです。

## おわりに
.\で接続先のPC名が保管されます。
ユーザ名は接続先の情報です。
以下の情報があり、この機能は終了するのかと考えましたが、このサポート終了の記事は、Microsoft Store 版の「Microsoft リモート デスクトップ」アプリに限定されたものであり、​一般的なリモート デスクトップ接続機能自体が終了するわけではないようです。

https://news.yahoo.co.jp/articles/31600b59036d17ec5ad38666250e35e51b928235

## 補足 
ユーザ名について
Windows 11 で「**現在使用中のユーザー名**」を確認する方法のメモ。

###  ユーザー名の確認方法

### 方法1：`whoami` コマンド（最も簡単）
コマンドプロンプトや PowerShell で以下を入力：

```cmd
whoami
```

出力例：
```
PC-NAME\user-name
```

この `user-name` が **現在ログイン中のユーザー名**です。

---

### 方法2：環境変数で確認（コマンドプロンプト）

```cmd
echo %USERNAME%
```

または PowerShell で：

```powershell
$env:USERNAME
```

---

### 方法3：GUIから確認（設定画面）

1. **「スタート」メニューをクリック**
2. 上部に表示されている **自分のアカウント名をクリック**
3. **「アカウント設定」** をクリック
4. 「あなたの情報」画面で、**表示名**やアカウントの種類（ローカル or Microsoft アカウント）などが確認できます

###  補足：レジストリから確認

レジストリエディターで以下にアクセスすると、ユーザーに関する情報があります：

```
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
```

この中にある各SID（S-1-5-21-...のような値）を選ぶと、`ProfileImagePath` にユーザーのパス（例：`C:\Users\user-name`）があり、そこからユーザー名が分かります。



パソコン名とユーザー名をまとめて確認したいときは、以下のようにすると便利です：

```cmd
echo Computer Name: %COMPUTERNAME%
echo User Name: %USERNAME%
```
周期性特徴量の作り方 ～Sin/Cos変換で季節性をモデルに組み込む～

# はじめに
時系列データには、季節性や周期性といったパターンが隠れていることがよくあります．
たとえば、天候データでは一年を通じた季節変動が顕著に現れますが、単純に日付を数値としてモデルに入力しても、実際の季節の「近さ」は正しく表現されません．そこで、本記事では sin/cos変換 を利用して周期性を捉える特徴量の作り方を解説します．

# なぜ周期性を考慮するのか
時系列データで「日付」をそのまま数値（例：1,2,3,…）で扱うと、線形的な変化しか捉えられない．
たとえば、1月1日（day=1）と12月31日（day=365）は遠く離れているように扱われ、実際の季節的な近さが表現できません．．．

これに対して、周期変換を行うと、1年という周期性をうまく反映させることができます．
具体的には、sinとcosに変換することで、1月1日と12月31日が平面上で近い位置にマッピングされ、季節ごとのパターンをより適切に学習させることができます．

# Sin/Cos変換の基本
周期変換の基本的な考え方は、周期𝑇の関数として与えられた値𝑥をという2つの値に変換することです．

たとえば、1年を365日と仮定して、日付（day）列を周期変換するコードは以下のようになります．
$$
\sin\left(\frac{2\pi x}{T}\right), \quad \cos\left(\frac{2\pi x}{T}\right)
$$


~~~サンプル
#サンプルデータ（1～365日）
df = pd.DataFrame({'day': range(1, 366)})
#1年周期 (365日) での周期変換
df['day_sin'] = np.sin(2 * np.pi * df['day'] / 365)
df['day_cos'] = np.cos(2 * np.pi * df['day'] / 365)
df.head()
df.tail(5)
~~~
結果
|   | day| day_sin  | day_cos  |
|:-:| :-:|    :-:   |    :-:   |
| 0 |  1 | 0.017213 | 0.999852 |
| 1 |  2 | 0.034422 | 0.999407 |
| 2 |  3 | 0.051620 | 0.998667 |
| 3 |  4 | 0.068802 | 0.997630 |
| 4 |  5 | 0.085965 | 0.996298 |
|...|... |   ...    |   ...    |
|360| 361|-0.071815 | 0.997428 |
|361| 362|-0.054624 | 0.998514 |
|362| 363|-0.037431 | 0.999204 |
|363| 364|-0.020237 | 0.999597 |
|364| 365|-0.003041 | 0.999692 |

この変換により、
1月1日と12月31日が平面上で近くなり、季節の連続性が反映されます．
特徴量として加えることで、モデルは非線形な周期パターンを学習できるようになります．

# まとめ
周期変換による特徴量エンジニアリングは、時系列データの持つ周期性を効果的にモデルに反映させる強力な手法です．

この記事で紹介したsin/cos変換を利用した手法をデータセットに試し、モデルの精度向上に役立ててみてください！！！
証明写真加工するアプリ！！

# 証明写真加工アプリを Python と Tkinter で作ってみた

最近、証明写真の加工やトリミングの手間を感じたことはありませんか？  
今回は、Python の標準ライブラリ Tkinter と、画像処理ライブラリ Pillow を用いて、証明写真加工アプリを作成しました。

## プロジェクトの背景

証明写真は、用途によって必要なサイズやフォーマットが異なります。  
また、スキャンした写真やスマートフォンで撮影した写真は、必ずしも対象が中央にあるとは限らず、余白が多かったりします。  
そこで、ユーザーが自由にトリミングできる手動トリミング機能を搭載することにしました。

## 主な機能

- **画像読み込み**  
  JPEG、PNG、BMP、GIF などの画像ファイルを読み込みます。

- **手動トリミング**  
  キャンバス上でマウスドラッグにより任意の領域を選択できます。  
  デフォルトのアスペクト比は「横3、縦4」に設定してありますが、ユーザーが自由に変更可能です。

- **プレビュー更新**  
  トリミング後の画像を、全体が潰れない形でプレビュー表示します。

- **画像保存**  
  加工後の画像を JPEG または PNG 形式で保存できます。

## 実装のポイント

1. **縮小表示と座標補正**  
   大きな画像は最大800×600に縮小して表示し、トリミング時の選択座標を元画像に合わせて補正しています。

2. **アスペクト比の個別入力**  
   ユーザーは「アスペクト比（横）」と「アスペクト比（縦）」を別々に入力可能。  
   デフォルトは 3:4（0.75） に設定しています。

3. **シンプルで使いやすいUI**  
   全体の配色は白背景、文字は黒で統一し、視認性と操作性を重視しました。

## Github で公開

このプロジェクトは Github 上で公開中です。  
[証明写真加工アプリ](https://github.com/KRFH/photo-resizer-app)
Github では、README や公開手順、さらにはライセンス情報も記載しています。  
ぜひ、クローンやフォークして使ってみてください！

## まとめ

Python と Tkinter で GUI アプリケーションを作成するのは、初心者にも取り組みやすいテーマです。  
今回のアプリを通して、画像処理やユーザーインターフェースの基本を学ぶことができました。  
今後、顔検出や自動トリミング機能など、さらなる機能拡張にも挑戦していきたいと思います。
CISSPに１ヶ月で合格したので体験記を書いてみた

### はじめに
本日、ITほぼ未経験者が１ヶ月でCISSP認定試験に合格したのでその記録を残します。
あまり参考にならないかもしれませんが..

### 筆者のスペックなど
・高卒
・30代
・ITほぼ未経験。ほぼというのは以下が理由。
・社内でTCP/IPのL1~3の教育を担当していた。（実務経験なし）
・現在はセキュリティ部署で勤務２ヶ月目（調整業務ばかりでセキュリティやってない...）
・保有資格は情報処理安全確保支援士（未登録）、基本情報技術者、電気通信主任技術者、公認ネットワーク脆弱性診断士

### 受験のきっかけ
セキュリティ部署に異動したら情報処理安全確保支援士持ってるからって、会社がCISSP公式トレーニングを受けさせてくれ、その公式トレーニングにバウチャー１回分が付いていたのが受験に至った経緯です。
公式トレーニングを受けられることが決まってからネットでググると、最近話題の「のみぞう」さんが２週間でCISSPを取得した記事を見つけたので１ヶ月あればいけるやろ！という軽いノリで試験を申し込みました。
公式トレーニングで「情報処理安全確保支援士に合格するレベルであれば３ヶ月ほどみっちり対策すれば合格できます」と言われ絶望したのを覚えています。

### 合格するために何をしたか
まず試験日までに何をするか計画を立てました。自分の戦略は以下。
1. 最初の２週間でCISSP公式問題集の８ドメインを２週する
2. １週間で模擬試験４回分を解く
3. 最後の１週間で８ドメインを１週する（総仕上げ） 
あとは実行するのみ！

### 計画と現実
計画は最初の１週目で破壌しました。
以下の写真は本日撮ったものです。
![Screenshot 2025-03-27 at 21.06.20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3667133/4f16bb9d-49f7-4dab-a101-7db5adfd7c24.png)
見ての通り１週間でドメイン４つ分しかできていない...
この頃はまだ余裕がありました。だってのみぞうさんは１週半しかしてなかったから。
まだ大丈夫...
結局、全８ドメインをやるのに２週間かかりました。
模擬試験を１回やって合格基準ギリギリを取れたことで微かな希望が見え始めます。
とは言え、数日前からレッドチーム講習が始まり（自分の業務には全く関係ないが、手を挙げたら参加させてもらえた）、日中は死にそうになりながら講習を受け、集中力を使い果たす日々。しかも講習は２週間あり後半になるにつれハードになるということを聞いたので、計画を大幅変更。
間違えた問題にマークをつけ、通勤時間を利用して復習することにしました。
**勉強＝正解できない問題を正解できるようにすること**
さらに２週目は正答率の低いドメインからやることで全体の底上げ
最後の１週間は暗記カードを作り通勤時間で暗記。夜は間違えた問題の振り返りとpiedpinというサイトで模擬問題を解きました。ちなみに前日piedpinの総合問題をしたところ84点でした。
そうして試験当日を迎えました。
### 試験当日
感覚としては受かるかどうかは五分五分で最終的に勘のあたり具合！所詮４択だし考え方は多分大丈夫なはず。むしろ知識が足りてなさすぎるが、範囲広すぎて手をつけたところで時間の無駄って思ってました。
試験は午後２時から東京の試験センターで申し込んでいました。
前日は早めに寝て当日は朝９時起き！普段より４時間ほど長く睡眠をとりました。初めていく場所だったので早く出発しましたが、電車に乗り間違えたり迷子になったりで予定より遅い到着に。試験センターの場所を確認し、近くのドトールで昼食をとりながらpiedpinのサイトで合格体験記や試験回答のコツなどを読んで過ごし、午後１時過ぎに試験会場に行きました。
事前に読んだ記事では鍵がかかっており入口で呼び出しを行なって入館（しかも30分前だと早すぎて入れない）すると記憶してましたが、平日の昼間だからか普通に入って受付ができました。（試験センターはビルの８階でした）
受付で注意書きを渡され読み終わると「準備できましたか？」と聞かれ試験の流れになりました。試験センターで時間まで軽く昼寝と最後の暗記カード確認をしようと考えていたのですが、そんな時間はありませんでした。注意書きにも試験センターで勉強はできませんという記載がありました。ここはリサーチ不足でした。
### 試験
内容は書けません（覚えてない）が、違和感とか理解できないといった問題は英文を確認した方が良いです。１問だけですが、この単語をそんな訳し方するなってのがあったので。
私は英語ができないのですが、日本語を読んでから英語を読むとヒントがある状態なので何とかなるものもありました。全然わからないものが多数でしたが...
正解をたぐりよせるために英文を読んだ方がいいのは間違いないですが、その分時間がかかるので全てを読むのは現実的ではありません。
あと、最初はテンポよく解けたのですが、だんだん悩む問題が増えました。そうすると、確実に当てたい欲が出てきて、考えれば考えるほどどの選択肢も正解に見える。悩む、時間を浪費してしまうという悪巡回に陥りました。なので２時間経ったぐらいで一度休憩を入れました。
その時点で80問程度しか解けておらず最長の150問解くことを考えると時間が足りなかったのですが、あえて気持ちと体をリセットするために休憩を挟みました。また、休憩を挟んでからは悩みすぎないようにテンポよく解くことを意識しました。結果、この判断が正解だったようで、残り20分ほどを残し130問程度で終了しました。

### 結果
試験後に渡されたプリントで合格を確認しました。
嬉しさもありましたが、やりたいことを犠牲にして勉強しなければならない生活からの解放が嬉しかったです笑

### 活用資料
・CISSP公式問題集・・・これがないと無理
・piedpin・・・各ドメインの模擬試験が分量的にちょうどよく学習しやすかった
・[CISSP勉強ノート](https://tex2e.github.io/blog/security/cissp-notes)・・・「晴耕雨読」さんのサイト。公式トレーニングの章とリンクしていて使いやすかった（公式トレーニングは９章構成で公式問題集やCBKと微妙に記載ドメインが違うのがネックだった）

### 最後に
１ヶ月で合格できたのは公式トレーニングの力もありますが、割と効率的に学習できたからだと思っています。その中でも絶大な効果を感じたのが**暗記カード**です！昔からあるやり方で今更って思うかもしれませんが、この暗記カードがなければ多分合格できなかったと思います。なぜかKindleで問題を繰り返しても記憶に残らないのに暗記カードだと残るんですよね。
多分余計な情報が削ぎ落とされて核となる情報だけがインプットされるからだと思いますが。
そういや以前自分の書いた字の方が記憶の定着には有利というのをどこかでみましたが実際そう感じました。
**おすすめなのでぜひ暗記カードの活用を検討していただければと思います。**
GTC2025 現地参加レポート（その他編）

# GTC参加レポート：番外編（GTC Park・NVIDIA本社・Santana Rowなど）

ここでは、GTC本編以外の「その他」のスポット、体験したことをまとめていきます。

---

## 🌳 GTC Park

会期初日から、**San Jose McEnery Convention Centerすぐ近くの公園**が「**GTC Park**」として装飾され、以下のような内容で盛り上がっていました。

- ライブ会場で音楽が流れる🎶  
- 各社ブースがいくつか出展  
- 昼食の配布（サンドイッチ、ブリトー的なもの＋チョコレートブラウニー的なものなど冷たい食事）  
- ベンチやテーブルが配置されていて休憩も可能  

### 😅 お昼時は大混雑…

全体的に良い雰囲気でしたが、**昼食時は行列必至**。  
冷たいランチ配布がこのGTC Parkのみだったため、**混雑緩和など、もう一歩運営に工夫が欲しい**と感じました。

![IMG_8721.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2561874/ed6fca0d-606c-4ea6-9525-56430c02aaaa.jpeg)
![IMG_8716.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2561874/b71da210-4f9d-4799-b912-614bb7a95127.jpeg)


---

## 🏢 NVIDIA本社（HQ）

帰りの途中、サンフランシスコ空港に向かう間に**NVIDIAの本社**に立ち寄りました。  
滞在時間は約3分！  
写真だけパッと撮って、サクッと移動しました。  
本社ビルがそこに「ある」という事実が、なぜかテンション上がります 😄

![IMG_8759.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2561874/f9ec6280-602e-400c-8711-54ff9e01ed6f.jpeg)

---

## 🍏 Apple Visitor Center

Appleの聖地、「**Apple Visitor Center**」にも立ち寄りました。

- ここでしか買えないTシャツやマグカップあり  
- Apple本社も **とおーくから見える**  
- デザイン性の高い空間で、Appleらしさ全開  

Appleファンならちょっと寄ってみる価値ありです。

![IMG_8655.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2561874/72f7942f-ecc8-495a-8cad-dceedeaa0a2b.jpeg)
![IMG_8659.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2561874/b528ad01-f3e6-4ddf-b4d4-2722054d8ae4.jpeg)


---

## 🏙️ Santana Row（宿泊エリア）

今回滞在したのは**Santana Row**という地区。  
どこを切り取っても絵になる美しいエリアで、まるでヨーロッパの街並みのようでした。

### 📸 Santana Rowで見かけたものたち：

- ギフトカードのデザインにもなっている**象徴的な場所**
![IMG_8651.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2561874/0e542902-96fa-4908-9da7-20df2af93c2a.jpeg)

- ただの通りもいい感じ
![IMG_8654.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2561874/a6d3f40d-f525-4a18-964b-1238df3c3dfc.jpeg)

- **NetApp** のオフィス
![IMG_8652.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2561874/ad55ada7-34c7-412d-b729-49f214d656bd.jpeg)

- **CISCO** のオフィス
![IMG_8736.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2561874/15cf7d3a-1e37-462c-88d4-39a044b2a374.jpeg)

- 雰囲気の良いバー🍸
![IMG_8740.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2561874/e1c6717d-6f1a-44fa-8750-add4c168fcd8.jpeg)
![IMG_8757.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2561874/23397903-7aea-422e-8fc3-3b0a725fd6e9.jpeg)


- 夜になると屋外の炎（ファイヤーピット）が灯り、さらにロマンチックな雰囲気に🔥
![IMG_8756.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2561874/a04b153a-6cdd-4824-b5ea-67a26056b633.jpeg)


---

## 📝 まとめ

GTCはカンファレンスそのものだけでなく、**その街の空気や場所の体験も含めて一つの旅**。  
現地の雰囲気を肌で感じられるからこそ、印象にも強く残ります。

次回参加する方の参考になれば嬉しいです 🙌
#0083（2024/03/27）仮想メモリとは

# 仮想メモリとは？

パソコンやサーバーで広く用いられている「仮想メモリ（Virtual Memory）」という概念について詳しく解説します。仮想メモリの役割、仕組み、そしてOSがどのようにメモリ管理を行っているのかを専門的な観点で掘り下げていきます。

---

## 🔹 仮想メモリの基本概念

仮想メモリとは、物理的なメモリ容量（RAM）を超えた領域を、ハードディスクなどのストレージを使って仮想的に作り出す仕組みのことです。OSが管理し、アプリケーションに対して物理メモリよりも広い連続したメモリ空間を提供します。

---

## 🔹 仮想メモリが必要な理由

- 複数のプログラムを同時に実行する場合、物理メモリが不足しやすくなります。
- 仮想メモリがあることで、物理メモリ不足時にも安定してプログラムが実行可能になります。
- OSがプログラムごとに分離されたメモリ空間を提供するため、セキュリティや安定性も向上します。

---

## 🔹 仮想メモリの仕組み（専門的視点）

### ① ページング方式（Paging）

仮想メモリは主にページングという技術を用いて実装されます。

- メモリを固定サイズの小さなブロック（ページ）に分割します（例えば4KB単位）。
- OSは、仮想アドレス空間を物理メモリ上のページフレームにマッピングします。
- 物理メモリが不足すると、使用頻度の低いページをディスク（ページファイル）に書き出します（ページアウト）。
- 必要なページが再び参照されると、ディスクから物理メモリへ再読み込みされます（ページイン）。

### ② ページテーブル（Page Table）

- OSは仮想アドレスから物理アドレスへの変換を管理するため、ページテーブルというデータ構造を使用します。
- CPUが仮想アドレスを参照する際、メモリ管理ユニット（MMU）がページテーブルを参照し、物理アドレスへと変換します。
- ページテーブルは階層化されることが多く（マルチレベルページテーブル）、メモリ効率と性能を両立させています。

---

## 🔹 ページフォールト（Page Fault）と性能への影響

- 参照したページが物理メモリ上にない場合、ページフォールトが発生します。
- OSは該当ページをディスクから読み込み、ページテーブルを更新し処理を再開します。
- 頻繁にページフォールトが発生するとパフォーマンス低下（スラッシング）を招くため、適切な物理メモリ量の確保が重要です。

---

## 🔹 仮想メモリ管理の改善方法

- **物理メモリの増設**: 最も直接的かつ効果的な改善方法。
- **ページファイルの最適化**: ページファイルを高速なSSDに置くことで、ページイン／ページアウト性能が改善します。
- **プログラムのメモリ使用量削減**: 不必要なリソース消費を抑えます。

---

## 🔹 まとめ

仮想メモリは、OSが物理的なメモリ不足を補い、安定した実行環境を提供するために欠かせない仕組みです。ページング技術やページテーブル管理など、複雑な仕組みを用いてOSは効率的にメモリ管理を行っています。仮想メモリを正しく理解することで、パフォーマンス向上やトラブルシューティングの手助けとなるでしょう。
#0082（2024/03/27）Windowsのタスクマネージャーのメモリ

# Windowsのタスクマネージャー「メモリ」タブの詳しい解説

Windowsのタスクマネージャーに表示されるメモリ関連の各項目について、原理やハードウェアを交えつつ詳しく解説します。

---

## 🔹 PCのメモリ（RAM）とは？

PCのメモリ（RAM: Random Access Memory）は、高速でCPUが直接アクセス可能な一時的な記憶領域です。現在実行中のプログラムやファイルを保存し、迅速な読み書きを行います。

物理メモリ不足時は、ディスクを使った「仮想メモリ（ページファイル）」で補完しますが、パフォーマンスが低下します。

---

## 🔹 タスクマネージャー各項目の意味

### ① 使用中（圧縮）
- 実際にアプリやシステムが使っている物理メモリ量。
- Windows 10以降、メモリ不足時にデータを圧縮し高速化を図ります。

### ② 利用可能（Available）
- すぐに使用可能なメモリ領域。
- 数値が大きいほど動作に余裕があります。

### ③ コミット済み（Commit）
- OSが使える仮想メモリ総量（物理メモリ＋ページファイル）に対する予約済み容量。
- 例えば「6.5/63.8GB」なら、現在6.5GB使用中で、物理メモリ＋ページファイル合計が約63.8GB。

### ④ キャッシュ済み（Cached）
- 最近使ったデータを再利用するために一時保存したメモリ容量。
- 必要時には即座に解放されます。

### ⑤ ページプール（Paged Pool）
- システムやドライバが使うメモリで、必要に応じてディスクにスワップ可能な領域。

### ⑥ 非ページプール（Non-Paged Pool）
- 常に物理メモリに保持され、ディスクにスワップされない重要なデータ領域。
- システムの重要データが格納されます。

---

## 🔹 各項目とハードウェアの関係

| 項目 | 物理メモリ(RAM) | 仮想メモリ(ページファイル) | 用途・特性 |
|------|-----------------|----------------------------|------------|
| 使用中（圧縮） | 利用 | 不使用（圧縮で対応） | 圧縮による高速化 |
| 利用可能 | 利用 | 不使用 | 即座に使える |
| コミット済み | 利用 | 利用 | メモリ予約量 |
| キャッシュ済み | 利用 | 不使用 | 高速アクセス用キャッシュ |
| ページプール | 利用 | 状況により利用 | スワップ可能 |
| 非ページプール | 常時利用 | 不使用 | スワップ不可・重要 |

---

## 🔹 メモリ管理の判断基準

- **使用中やコミット済みが高い場合**
  - メモリ増設を検討。

- **キャッシュ済みが多く、利用可能が少ない場合**
  - 通常は問題なし（自動調整）。

- **非ページプールが異常に高い場合**
  - ドライバ異常の可能性あり。再起動や更新を推奨。

---

## 🔹 まとめ

タスクマネージャーの各メモリ項目は、PCの物理メモリと仮想メモリの管理状態を示します。各項目を理解し、メモリ管理やパフォーマンスの最適化に役立てましょう。
atcoder_水色精進記録16＿ABC328f

# Atcoder水色精進記録
ABC328
F - Good Set Query
https://atcoder.jp/contests/abc328/tasks/abc328_f

# アルゴリズム・データ構造
重みつきUnionFind

# 考察
Xa - Xb = d → Xa = d + Xb
単一の式だけで考えれば、Xaが決まればXbが決まる
関連するa,bに辺が貼られたグラフとして考えれば閉路がなければ条件は成立している
閉路ができる場合、それまでの値と整合性を保てた状態で、繋ぐことができれば条件は成立

UnionFindで閉路検出はできる
UnionFindに重みを追加して、自分のルートとのdiffを保持しておけばOK

# 提出
https://atcoder.jp/contests/abc328/submissions/64229301

# 感想
重みの更新が手癖で書けないので、書けるまで慣れたい
union時にfindせずにrootを使ってしまう癖があるので直す必要があり
JavaScript（ES6〜）ループと反復処理

## while文
while文は、指定した条件`true` の間、繰り返し処理を実行する制御構文
極力使わない方がよいです。理由は、条件式がfalseになるように処理を書かないと無限ループするからです
```javascript
let i = 1;

while (i <= 5) { //  iが5以下の間ループ
  console.log(i);
  i++; //  iを1ずつ増やす　もしi++がなかった場合、無限ループします
}

// 出力
// 1
// 2
// 3
// 4
// 5
```

## do-while文
少なくとも1回は処理を実行し、その後条件をチェックしてループを続けるか決めるループ処理の構文
こちらも極力使わない方がよいです。理由は無限ループになる可能性があるからです
```javascript
let i = 1;

do {
  console.log(i);
  i++;
} while (i <= 5);

// 出力
// 1
// 2
// 3
// 4
// 5
```

## for文
回数が決まっているループ処理を実行するための制御構文
for文よりforEachの方が可読性に優れており、よく使われています
```javascript
for (let i = 1; i <= 5; i++) {
  console.log(i);
}

// 出力
// 1
// 2
// 3
// 4
// 5
```

## 配列のforEachメソッド
高階関数で、配列の各要素に対して1回ずつ処理を実行するメソッド
for文よりも可読性に優れており、使われています
```javascript
const fruits = ["りんご", "バナナ", "ぶどう"];

fruits.forEach((fruit) => {
  console.log(fruit);
});

// 出力
// りんご
// バナナ
// ぶどう
```

```javascript
// 高階関数とコールバック関数
const fruits = ["りんご", "バナナ", "ぶどう"];

// コールバック関数
const printFruit = (fruit) => {
  console.log(fruit);
};

// forEach(高階関数)にコールバック関数を渡す
fruits.forEach(printFruit);

// 出力
// りんご
// バナナ
// ぶどう
```

## break文
ループやswitch文を途中で強制終了するための制御文
```javascript
for (let i = 0; i < 5; i++) {
  if (i === 3) {
    break; // i が 3 のときにループを抜けます
  }
  console.log(i);
}

// 出力
// 0
// 1
// 2
```

## 配列のsomeメソッド
配列内の要素が「条件を満たすかどうか」を判定するメソッド
条件を満たす要素が1つでもあれば`true`を返し、なければ`false`を返します
```javascript
const numbers = [1, 2, 3, 4, 5];

// 配列に3以上の数があるか？
const hasLargeNumber = numbers.some((num) => num >= 3);

console.log(hasLargeNumber); // true
```

## continue文
ループ内で現在の反復（繰り返し）をスキップして、次の反復を開始するための制御文
```javascript
// i === 3 のとき、continueによって残りの処理がスキップされ、次の繰り返しに進みます
for (let i = 0; i < 5; i++) {
  if (i === 3) {
    continue; //  iが3のとき、次のループに進みます
  }
  console.log(i);
}

// 出力
// 0
// 1
// 2
// 4
```

## 配列のfilterメソッド
配列の各要素に対して指定した条件を満たす要素だけを抽出して、新しい配列を作成するメソッド
配列の要素を抽出して新しい配列を作りたいときやTodoリストなどに使われます
```javascript
const numbers = [1, 2, 3, 4, 5, 6];

// 偶数だけを抽出
const evenNumbers = numbers.filter((num) => num % 2 === 0);

console.log(evenNumbers); //  [2, 4, 6]
```

## for...in文
オブジェクトのプロパティ（キー）や配列のインデックスを反復処理するためのループ構文
極力使わない方がよいです。理由は親オブジェクトまで遡って反復処理可能なプロパティがないか探索するなどの問題があるからです。
```javascript
const person = {
  name: "Alice",
  age: 25,
  job: "Engineer"
};

// オブジェクトのプロパティを反復処理
for (const key in person) {
  console.log(key, person[key]);
}

// 出力
// name Alice
// age 25
// job Engineer
```

### 安全にオブジェクトのプロパティを反復処理する方法
- Object.keysメソッド
- Object.valuesメソッド
- Object.entriesメソッド
```javascript
const person = {
  name: "Alice",
  age: 25,
  job: "Engineer"
};

const keys = Object.keys(person);

// 各プロパティ名にアクセスして値を表示
keys.forEach((key) => {
  console.log(key, person[key]);
});

// 出力
// name Alice
// age 25
// job Engineer
```

## for...of文
反復可能なオブジェクト（配列、文字列、マップ、セットなど）の値を反復処理するための構文
```javascript
const fruits = ["りんご", "バナナ", "ぶどう"];

for (const fruit of fruits) {
  console.log(fruit);
}

// 出力
// りんご
// バナナ
// ぶどう
```
```javascript
const text = "こんにちは";

for (const char of text) {
  console.log(char);
}

// 出力
// こ
// ん
// に
// ち
// は
```

## まとめ
上記の中でよく使われるものは、forEach、some、filterです。
whileやdo-whileは無限ループの危険性があるため、使うことを極力避けた方が良いです