OmniAICreator/Qiita-1.07M huggingface dataset:
クソコードの闇を断ち切れ！~条件式の最適化と可読性向上~

# はじめに
そこまでクソコードではないですが、避けられるのであれば避けたいクソコードを紹介します。

:::note warn
完全にタイトル負けです。
GPT君が考えてくれたので私は悪くありません。
:::

# クソコードを紹介するぜ！
バリデーションを行うコードです。
入力値に問題がなければ「入力OK」、問題があれば「入力NG」となります。

```js
if ((courseList.value && commentInput.value && isCommentRequired) || (courseList.value && !isCommentRequired)) {
    // 入力OK
} else {
    // 入力NG
}
```

# クソコードを浄化するぜ！
まず、適切に改行をして構造をわかりやすくしたいですね。

```js
if (
    (courseList.value && commentInput.value && isCommentRequired)
    || (courseList.value && !isCommentRequired)
) {
    // 入力OK
} else {
    // 入力NG
}
```

すると、条件が一部重複していることに気づくと思います。
こういうのは大体条件を言葉で整理できていないために発生します。

コードを追っていくと、下記のことがわかりました
- `courseList.value` は、セレクトボックスで選択したコースの値
- `commentInput.value` は、フォームで入力されたコメントの値
- `isCommentRequired` は、コメント入力が必須かどうかを判別するフラグ

これを元にコードを浄化すると

```js
if (
      courseList.value
      && (isCommentRequired ? commentInput.value : true)
) {
    // 入力OK
} else {
    // 入力NG
}
```

なんということでしょう！
とても簡潔なコードになりましたね！

条件式を読んでいくと、
- `courseList.value` は必須です
- コメント入力が必須であれば、`commentInput.value` も必須です

という内容であることがわかります。

# まとめ
今回は簡単な例を挙げたので、「これくらいならそのままで良い」と感じる人もいるかもしれません。自分も「これくらいならいいか」と思わないでもないです。

ですが、このような状態からいくつも条件を継ぎ足されて悪魔合体を繰り返し、恐ろしいバケモンに進化してしまうこともあります。

:::note
条件が一行に押し込まれていて、改行したら同じ条件がいくつか書いてあるのを見た時悲しい気持ちになりました。
:::

なので可能であれば、芽は早いうちに詰んだほうが良いと思います！
MCUXpressoでのヘッドレス・ビルド (macOSでの例)

# MCUXpressoでのヘッドレス・ビルド
前から調べていたのだけど，ようやくその方法が判明した．　　
MCUXpresso IDEは，macOSではそのOS用のアプリケーション「MCUXpressoIDE.app」として提供されている．実は「MCUXpressoIDE.app」はアプロケーションに必要なファイルを格納したパッケージのフォルダになっている．  
このアプリケーションをコマンドラインから開くには，その中の実体を指し示してやらなければならない．  
ちなみに，標準のインストーラでインストールしたものでは，次のような場所に置かれる(アプリケーション・パッケージの内容は，ファインダ上なら*.app上で右クリックして「パッケージの内容を表示」を選べば覗いてみることができる)

```
/Applications/MCUXpressoIDE_24.9.25/ide/MCUXpressoIDE.app/Contents/MacOS/mcuxpressoide
```

これを使って，次のような引数と一緒にコールしてやると動く．  
```
-nosplash 
--launcher.suppressErrors 
-application org.eclipse.cdt.managedbuilder.core.headlessbuild 
-data {ワークスペース名} 
-cleanBuild {プロジェクト名}
```

具体的な例として，たとえばデスクトップに置いたワークスペース:「nnn」内の「0_0_Hello_world_FRDM_MCXN236」プロジェクトのビルドはこんな感じになる．  

```
/Applications/MCUXpressoIDE_24.9.25/ide/MCUXpressoIDE.app/Contents/MacOS/mcuxpressoide -nosplash --launcher.suppressErrors -application org.eclipse.cdt.managedbuilder.core.headlessbuild -data '/Users/tedd/Desktop/nnn/' -cleanBuild 0_0_Hello_world_FRDM_MCXN236
```

ちなみにこのアプリケーションの場合，別プロジェクトにリンクされるライブラリが用意される．このためライブラリは先にビルドされてなければならない．なので次の2つのコマンドでエラーなくビルドできる．

```
/Applications/MCUXpressoIDE_24.9.25/ide/MCUXpressoIDE.app/Contents/MacOS/mcuxpressoide -nosplash --launcher.suppressErrors -application org.eclipse.cdt.managedbuilder.core.headlessbuild -data '/Users/tedd/Desktop/nnn/' -cleanBuild _r01lib_frdm_mcxn236
/Applications/MCUXpressoIDE_24.9.25/ide/MCUXpressoIDE.app/Contents/MacOS/mcuxpressoide -nosplash --launcher.suppressErrors -application org.eclipse.cdt.managedbuilder.core.headlessbuild -data '/Users/tedd/Desktop/nnn/' -cleanBuild 0_0_Hello_world_FRDM_MCXN236
```

# 参考情報
#### Windowsバッチファイルの例
https://github.com/ErichStyger/mcuoneclipse/blob/master/Examples/MCUXpresso/CmdLineBuild/build_from_command_line.bat  

#### オプション指定の詳細
https://qiita.com/oyan29/items/e04ffd50ef0a7d6d532f

#### .app上で右クリックして「パッケージの内容を表示」を選ぶ
![スクリーンショット 2024-12-16 10.34.23.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3288603/a772e95c-282f-eedf-1b60-df888b23af7c.png)
Microsoft Securityを大局的に見る、関連事項を読む

# はじめに
2024/12/13(金)夕方、日本マイクロソフトさんのリアルイベントとして開催された「行く年、来る年、年忘れセキュリティ2024」　に参加してきました。

https://connpass.com/event/337387/

Microsoftさん中の方(他)のトークやパネル・ディスカッションのほか、4人のLT（たまたま、様々な分野のMicorosoft MVPによる）のお話がありました。

## 一口にセキュリティといってもは様々

各トークの主要な軸となる話は以下のような感じです。

- 直近(2024年)を振り返る、Microsoft Securityの世界の全体像、攻撃と対処の動向
- 政府のセキュリティ基準(ISMAP他)の最新の動き
- 2024年の権威ドキュメントを幅広く紹介
- ネットワークやSASE
- SNS詐欺とフェイクニュースサイト、中小企業のセキュリティ
- パスワードレス認証

全てMicrosoft Securityやサイバーセキュリティに関してですし、どこが大事、どこのみを深く知っておいたほうがよい、というものでもないと感じました。どちらも参考になる観点が含まれるからです。

サイバー・セキュリティ関連は「何かをやればよい、ガイドラインを守ればよい、設定・構築を終わらせればよい」というものではなく、**大局的な観点を知り、関連事項を知り、具体的なSaaS等や、実装を手応えをもって知っていくことが大事だ** と認識しました。

## 大局を知る「Microsoft デジタル防衛レポート 2024」

Microsoftから毎年出ているレポート、通称 MDDRです。

レポートは100ページ越えになるのですが、紹介サイトもサマリとなるポイントがきちんと取り出され、日・英あり、読みやすいです。

https://www.microsoft.com/ja-jp/security/security-insider/intelligence-reports/microsoft-digital-defense-report-2024

https://www.microsoft.com/en-us/security/security-insider/intelligence-reports/microsoft-digital-defense-report-2024

いろいろなところにリンクやサブメニューがありますので、よく注意して確認するのがおすすめです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/419691/479d165b-7670-08a4-1412-4a5e9e42543a.png)

そして、同ページの下部には、以下のような抜粋版も用意されています。いいですね。
- [エグゼクティブ サマリー](https://go.microsoft.com/fwlink/?linkid=2291020&clcid=0x411&culture=ja-jp&country=jp)
- [CISO エグゼクティブ サマリー](https://go.microsoft.com/fwlink/?linkid=2291121&clcid=0x411&culture=ja-jp&country=jp)
- [政府および政策立案者向けエグゼクティブ サマリー](https://go.microsoft.com/fwlink/?linkid=2290931&clcid=0x411&culture=ja-jp&country=jp)

## 2024/10/4に発出された「金融分野におけるサイバーセキュリティに関するガイドライン」

今年金融庁さんからかなり[具体的なガイドラインがでました](https://www.fsa.go.jp/policy/cybersecurity/index.html#topics08)。対象は主要な金融機関の方向けです。
私の勤務先のような対象ではないその他金融機関や、一般の事業者の方も参考になります。

こちらのガイドラインのテキストを取り出し、改行等を変更し、Micorosoft Seucirity等とも関係しそうなところを取り出したメモを作成しはじめました（まだ更新中です）。

https://ishiayaya.notion.site/fsa-cybersecurity

短縮URL https://ishiayaya.net/fsa-cyber 

オリジナルにないところは、「👉 Notes」として折り畳んだトグルリストにしたいと考えています。

# おわりに
はじめにに書いたイベントは、コロナ禍による中止があったので、前回は2019年でした。

https://connpass.com/event/154957/

人数規模は肌感で、5倍程度の参加者だったように思います。2019年に続き、2024年もLT登壇させていただきました。
2025年も安全・安心な日本企業、IT社会になるため、引き続き私も活動していきたいと考えています。
Power Automateで問合せフォームからの通知を対応したら、bot攻撃された件

# 最初に
　この記事はPower Automate Advent Calender 2024　23日目の記事です。

 https://qiita.com/advent-calendar/2024/powerautomate
 

 # 自己紹介
　佐賀県の小売業（和服業）で情シスをしています。

　社内でPower Platformを活用した取り組みを行ってます。

 https://kn.itmedia.co.jp/kn/articles/2409/27/news070.html
 

 # ライティングページにある問合せフォームからの通知
 「着物　クリーニング」とGoogle検索を行うと検索した場所が店舗周対象エリアであれば、先頭ページにライティングページが表示されアクセスすることにより、下記３項目のいずれかの問合せ手段にてクリーニングの問合せを行う仕組みを行っています。

３つの問合せ手段
 ・LINE公式アカウントによる問合せ
 ・問い合わせフォームによるの問合せ
 ・フリーダイヤルによる問合せ

Power Automateを使用しているのは、問合せフォームから問合せした場合にフローが実行される仕組みを作っています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2277732/77be4c6e-45ba-8e15-a70e-a09e42401efc.png)


 


## クラウドフローの内容

 問合せフォームから送信するとメールが送信され、メール受信をトリガーにして問合せ内容はShare Point Online Listに問合せ内容が保存し、問合せ内容がチャットに通知が届くようにフローを作成してます。

 
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2277732/b3f5f97a-d2b7-6c54-f25b-9a5a7fe44753.png)




 ### フローを有効化して1週間後、問合せフォームから迷惑メール・チャット通知がたくさん届く
　問合せフォームからの通知を有効にして1週間近くは特に問題がなく動いていたが、ある日の夕方に一定間隔でチャットの大量通知が届くようになり、メールアドレス・問合せ内容からBot攻撃による迷惑メールの大量送付だと気付く。


平日の夕方に迷惑メールが送られてきたこともあり、すぐにPower Automateのフローを無効にすることができました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2277732/41e4bd36-f282-04bf-7cf3-3537951ed447.png)

 
 ## 対策しろと言われたが
  Power Automate上では問合せ窓口から正しく送られてきており「件名、送信元アドレス」共に正しいのでPower Automate側で正しい問合せの判断が難しいこと、Power Automate側ではなく問合せフォーム側が
  
2024年の現在問合せフォームにBot対策をしていない業者も問題ではあるが、問合せフォームを作成した業者にBot対策を早期に行ってもらうように広報部門から業者に依頼してもらう。
 
 ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2277732/3e45ef02-85e7-eff9-0ed5-47b3a0ae9097.png)

 
 

 ## 対策直後にフローを有効するのは危険
　Bot対策が行われたからと言ってすぐにフローを有効にしたら、残っているフローが実行される可能性があったので、問合せフォームの送信先メールアドレスを変更して、新規でフローを再作成しました。

 # まとめ
 Bot攻撃の対策していない問合せフォームを作った業者自体問題ではあるが、Power Automateで正しいフローを書いていても、大元が原因にて大変なことが起きることもあります。

 Power Automateに限らずPower BIでも言えますが、大元についての知見がないと大惨事になる可能性があるので注意しましょう。
LINE WORKS API メールの取得

# LINE WORKS メール取得 API の使用方法

LINE WORKS の API を活用して、特定のメールを取得する方法について解説します。本記事では、Google Colab を使用して、API を簡単に実行するためのスクリプトを提供します。

## 概要

LINE WORKS のメール取得 API を利用することで、以下のような情報を取得できます：

- 特定のメールの詳細情報（送信者、受信者、件名、本文など）
- 添付ファイルやインライン画像のデータ

## 必要な準備

### 1. アクセストークンの取得

メール取得 API を使用するには、**User Account 認証**によるアクセストークンが必要です。アクセストークンの取得方法については、以下の記事をご参照ください：

- [LINE WORKS User Account 認証でアクセストークンを生成 (Qiita)](https://qiita.com/iwaohig/items/a7392f2d09b6fc70d8bb)

**注意**：アクセストークンには `mail` または `mail.read` スコープが含まれている必要があります。

### 2. Google Colab の準備

以下のリンクから Google Colab ノートブックにアクセスして、サンプル コードをそのまま試すことができます：

[Google Colab: メール取得サンプル](https://colab.research.google.com/drive/1bM9Ndsj-bxDaYxjU1a8atCaSAkK7fxb3?usp=sharing)

## サンプル コード

以下は、Google Colab 上で動作する Python スクリプトのサンプルです。

```python
# 必要なライブラリをインストール
!pip install requests

# ライブラリのインポート
import requests
import json

# 設定変数
ACCESS_TOKEN = "your_access_token"  # @param {type:"string"}
USER_ID = "me"  # @param {type:"string"} "me" または LINE WORKS のユーザー ID
MAIL_ID = "12345"  # @param {type:"string"} 取得したいメールの ID

# API サーバー
API_SERVER = "https://www.worksapis.com"
API_ENDPOINT = f"{API_SERVER}/v1.0/users/{USER_ID}/mail/{MAIL_ID}"

# メール取得 API の呼び出し
def get_mail(access_token):
    headers = {
        "Authorization": f"Bearer {access_token}",
        "Content-Type": "application/json",
    }
    response = requests.get(API_ENDPOINT, headers=headers)

    # レスポンスに基づく出力
    if response.status_code == 200:
        print("✅ メールを取得しました！")
        result = response.json()
        print(json.dumps(result, indent=4, ensure_ascii=False))
    else:
        print(f"❌ メールの取得に失敗しました。ステータスコード: {response.status_code}")
        print(response.text)

# メール取得 API を実行
get_mail(ACCESS_TOKEN)
```

## 入力例

- **`ACCESS_TOKEN`**: **User Account 認証**によるアクセストークン
- **`USER_ID`**: `"me"` または LINE WORKS のユーザー ID
- **`MAIL_ID`**: メールの ID（フォルダ内のメール一覧 API で取得可能）

## 実行結果

### 成功時

```plaintext
✅ メールを取得しました！
{
    "attachments": [],
    "mail": {
        "mailId": 12345,
        "folderId": 0,
        "status": 2097157,
        "from": {
            "name": "送信者名",
            "email": "sender@example.com"
        },
        "to": [
            {
                "name": "受信者名",
                "email": "receiver@example.com"
            }
        ],
        "subject": "テストメール",
        "body": "これはメールの本文です。",
        "receivedTime": "2024-12-15T00:00:00+09:00"
    }
}
```

### 失敗時（例: スコープ不足）

```plaintext
❌ メールの取得に失敗しました。ステータスコード: 403
{"code": "ACCESS_DENIED", "description": "Access is denied for userId."}
```

## 注意事項

1. **アクセストークンのスコープ**
   - アクセストークンには `mail` または `mail.read` スコープが含まれている必要があります。

2. **メール ID の取得**
   - メール ID は、[メール フォルダ内のメール リスト取得 API](https://developers.worksmobile.com/jp/docs/mail-mailfolders-children) を使用して取得できます。

3. **インライン画像の処理**
   - メール本文内にインライン画像が含まれている場合、API のレスポンスに含まれる `attachments` フィールドを参照してください。

---

LINE WORKS メール取得 API を活用して、メール管理を効率化しましょう！
OpenAPI Client Generator で ApiPlatform の  Client を作る(1)

## API Platform

よしたにです。
信州の端っこで Symfony を使い続けて15年ぐらい経ちました。

最近では API Platform を、Next.js などのバックエンドとして使うことが増えてきました。ただし、現状では進化が早く、継続的にアップデートをしていく必要があります。

弊社では、クライアントとして OpenAPI Client Generator の TypeScript (Fetch) を用いております。
https://github.com/OpenAPITools/openapi-generator/tree/master

OpenAPI Client Generator は Type の生成に加え、各エンドポイント毎にクラスのメソッドを生成するため、使いやすいと考えていますが、JSON+LDに対応しておりません。そのため、json のフォーマットに切り替えて利用しております。


## サーバー側

json+ld を無効化するには、api_platform.yaml を修正します。
api_platform.yaml の formats の初期状態は未定義で、黙字的に jsonld が利用されるようです。
これを以下のようにjsonを有効にします。

https://api-platform.com/docs/core/configuration/

一行目にあるフォーマットがデフォルトとして扱われるとのことです。

```yaml
api_platform:
    formats:
#        jsonld: ['application/ld+json']
        json: ['application/json']
        html: ['text/html']
```

以下のコマンドで json ベースの openapi の定義が出力されます。

```
bin/console api:openapi:export
```

画面上で確認する場合は以下のURLで出力されたものと一致しました。

https://localhost/api/docs.jsonopenapi

正直、 formats と docs_formats の関係がいまいちわかっていません。

## クライアント側

ここでは、便宜上プロジェクトが backend と frontend というディレクトリに分かれているとして、 frontend 側に保存するとすれば以下のようになろうかと思います。

```
cd backend
bin/console api:openapi:export > ../frontend/config/openapi.json
```

次に、フロント側でパッケージをインストールしクライアントを生成していきます。

```
cd frontend
npm install --save-dev @openapitools/openapi-generator-cli
```

package.json の scripts にダウンロードと生成のスクリプトを追記します。

```json
{
  "scripts": {
    "openapi:validate": "openapi-generator-cli validate -i './config/openapi.json'",
    "openapi:generate": "openapi-generator-cli generate -g typescript-fetch -i './config/openapi.json' -o './src/openapi'"
  }
}
```

```
npm run openapi:validate
npm run openapi:generate
```

これでクライアントが生成されます。

------

問題は json を使うことにより、json+ldが持っていたコレクションを扱う処理が無くなってしまうことです。こちらは ApiPlatform の内部の ApiPlatform\JsonApi\Serializer\CollectionNormalizer のコードを流用して独自の Normalizer を作成して対応しました。この点は別途まとめたいと思います。
SSHにおける脆弱な暗号化方式・ハッシュアルゴリズムでRC4とCBCを無効化する

# はじめに
- プロダクトで某規格に準拠していると、**セキュリティについてやんややんや言われる**ことがあり、対応しないといけない羽目になったが、これはこれで勉強になったのでメモを兼ねて残しておきます
- 内容はタイトルの通り、Linuxサーバ(RedHat系)にSSHする際に使用される暗号化方式やハッシュアルゴリズムで脆弱なものを無効化する方法です

# 手順
- 対象OS：CentOS8(あくまでこの時の対象)
- sshd_configの修正
    - 以下を追記
    ```
    Ciphers  chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
    ```

    - config修正後、sshdサービスリスタート

  ```
  systemctl restart sshd
  ```
  
    - 既存のセッションは切断せず、新規にSSH接続ができることを確認する
    ```
    ssh -c aes128-cbc  hogehoge@127.0.0.1
    ```
　   →この時点ではまだ使用できる
　
- /etc/sysconfig/sshdの修正
    - #CRYPTO_POLICYのコメントアウトを外す
    - sshdサービスリスタート　
    ```
    systemctl restart sshd
    ```
   
    - 既存のセッションは切断せず、新規にSSH接続ができることを確認する
　  
    ```
    ssh -c aes128-cbc  hogehoge@127.0.0.1
    ```
    
　  →この時点でsshd_configで記述したCiphers設定が反映される。

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

https://shobon.hatenablog.com/entry/2020/09/07/192918
グレンジャー因果検定とは？初心者でも分かる解説と具体例

グレンジャー因果検定（Granger Causality Test）は、時系列データを使って、あるデータが別のデータに影響を与えている可能性があるかどうかを検証する統計手法です。この記事では、中学生でも理解できるようにシンプルな説明から、具体的な数式や検定方法まで丁寧に解説します。
※この記事は、ChatGPTの出力を基に作成しています。

---

## **1. グレンジャー因果検定の基本的な考え方**

### 因果関係とは？
「Aが起きたからBが起きた」という関係を「因果関係」といいます。例えば：
- 雨が降ると、地面が濡れる → **因果関係あり**
- 鳥が鳴くと太陽が昇る → **因果関係なし**

しかし、単にAとBが同じタイミングで起きているだけでは因果関係があるとは言えません。グレンジャー因果検定は、「A（原因）→B（結果）」という因果関係があるかを統計的に調べます。

### 時系列データとは？
時系列データとは、時間とともに変化するデータのことです。例として以下のものがあります：
- 毎日の気温
- 時間ごとの売上
- 分ごとの心拍数

グレンジャー因果検定は、こうしたデータの「時間の流れ」を利用します。

---

## **2. グレンジャー因果検定の仕組み**

### モデルの考え方
グレンジャー因果検定では、次の2つのモデルを比較します。

#### (a) \( Y_t \) を \( Y \) の過去のデータだけで説明するモデル
$\
Y_t = a_0 + \sum_{i=1}^p a_i Y_{t-i} + \epsilon_t
\$
- $\ Y_t \$：現在のデータ
- $\ Y_{t-i} \$：過去のデータ
- $\ \epsilon_t \$：予測誤差（残差）

このモデルは、**$\ Y \$ の変動が $\ Y \$ 自身の過去の値だけで説明される**と仮定しています。

#### (b) \( Y_t \) を \( Y \) と \( X \) の過去のデータで説明するモデル
$\
Y_t = b_0 + \sum_{i=1}^p b_i Y_{t-i} + \sum_{j=1}^q c_j X_{t-j} + \epsilon_t
\$
- $\ X_{t-j} \$：$\ X \$ の過去のデータ

このモデルでは、**$\ Y \$ の変動が $\ Y \$ の過去と $\( X \$ の過去の両方で説明される**と仮定します。

### 帰無仮説と対立仮説
- **帰無仮説 $\( H_0 \)$**：「$\ X \$ の過去のデータは $\ Y \$ に影響を与えない」
  - 数式で表すと、モデル (b) の $\ c_j = 0 \$（すべての $\ j \$ について）。
- **対立仮説 $\( H_1 \)$**：「$\ X \$ の過去のデータは \( Y \) に影響を与える」
  - 数式で表すと、少なくとも1つの $\( c_j \neq 0 \)$。

---

## **3. F検定による判定方法**

グレンジャー因果検定では、モデル (a) とモデル (b) を比較して、どちらがデータをよく説明できているかを調べます。その際に使うのが**F検定**です。

### F統計量の計算式
F統計量は次の式で計算されます：
$\
F = \frac{(RSS_a - RSS_b) / (k_b - k_a)}{RSS_b / (n - k_b)}
\$

#### 各項の説明
- $\ RSS_a \$：モデル (a) の残差平方和（予測誤差の大きさ）
- $\ RSS_b \$：モデル (b) の残差平方和
- $\ k_a \$, $\ k_b \$：モデル (a), (b) の自由度（パラメータの数）
- $\ n \$：データのサンプル数

### F値の意味
- $\ F \$ が大きいほど、「モデル (b) がモデル (a) よりもデータをよく説明している」と言えます。
- 臨界値（F分布の値）を超えると、帰無仮説 $\ H_0 \$ を棄却します。
  - 帰無仮説が棄却される場合、**$\ X \$ の過去のデータが $\ Y \$ に影響を与えている**と結論付けます。

---

## **4. 具体例で解説**

次の例でグレンジャー因果検定を計算してみます。

### データの例
- $\ Y_t \$：アイスクリームの売上
- $\ X_t \$：気温
- サンプル数：$\ n = 50 \$
- ラグ数：$\ p = q = 2 \$
- モデル (a) の残差平方和：$\ RSS_a = 100 \$
- モデル (b) の残差平方和：$\ RSS_b = 80 \$

### ステップ1：F統計量の計算
- モデル (a) の自由度：$\ k_a = 3 \$（切片 $\ a_0 \$ + 2つのラグ）
- モデル (b) の自由度：$\ k_b = 5 \$（切片 $\ b_0 \$ + 2つのラグ + 2つの $\ X \$ のラグ）

F統計量：
$\
F = \frac{(RSS_a - RSS_b) / (k_b - k_a)}{RSS_b / (n - k_b)}
\$
$\
F = \frac{(100 - 80) / (5 - 3)}{80 / (50 - 5)} = \frac{20 / 2}{80 / 45} = \frac{10}{1.78} \approx 5.62
\$

### ステップ2：判定
自由度 $\( 2, 45 \)$ のF分布に基づいて臨界値を求め、有意水準 $\ \alpha = 0.05 \$ で比較します。
- 仮に臨界値が $\ 3.2 \$ だとすると、$\ F = 5.62 > 3.2 \$ なので帰無仮説を棄却。
- 結論：気温$\( X \)$はアイスクリームの売上$\( Y \)$に影響を与えている可能性が高い。

---

## **5. 注意点**

- **因果関係を完全に証明するわけではない**  
  グレンジャー因果検定は「影響を与えている可能性」を示すだけで、真の因果関係があると断定することはできません。隠れた要因（例：季節など）が存在する可能性も考慮すべきです。

- **時系列データの前提条件**  
  検定を行う前にデータが「定常性」を満たしているか確認する必要があります。定常性がない場合は、差分を取るなどの処理が必要です。

---

## **6. まとめ**

グレンジャー因果検定は、時系列データを使って「あるデータが別のデータに影響を与えているか」を調べる強力な手法です。その計算にはF検定を用い、モデル間の説明力を比較します。手順は次の通りです：
1. $\ Y \$ のみのモデルと、$\ Y \$ と \$ X \$ のモデルを作成。
2. 残差平方和を計算。
3. F統計量を計算し、帰無仮説を検定。

正確な結論を得るには、データの性質や前提条件を十分に確認することが重要です。興味があれば、実際のデータを使って検定を行ってみてください！
ChatGPTとプロンプトエンジニアリングで勝負する

## はじめに
この記事は以下の記事の続きになります。

https://qiita.com/oba_atsushi/items/9be79cdb2dde8d153619

前回の記事では 『「あ」を 30 回繋げたものを出力する』というタスクのプロンプトエンジニアリングを ChatGPT 自身にやってもらいましたが、余分な出力を無くす工夫や細かな文言の調整は見られたもののこのタスクの難しさである「あ」の文字数が正確に30文字にならない問題は解決しませんでした。

そこで今回の記事では自分の沽券を守るべく、プロンプトエンジニアリングによる文字数の安定化を見事達成し ChatGPT にマウントを取ろうと思います。

## タスク
（前回記事の再掲です。）

今回も『「あ」を 30 回繋げたものを出力する』 というタスクのプロンプトエンジニアリングを行っていきます。

このタスクは ChatGPT に解かせると出力が安定せず、以下のような誤った回答が返ってきます。

> :man: :「あ」を 30 回繋げて出力して
> :robot: : あああああああああああああああああああああああああああああああ


長いのでわかりづらいですが「あ」が 31 文字出力されています。

## 工夫１：Few-shot prompting
まずはプロンプトエンジニアリングの代表的な手法である例示を与える Few-shot prompting を試してみます。

今回はシンプルなタスクで例示も何もないので、とりあえず欲しい出力をそのまま例示しまみます。本末転倒感はありますがまあ良いでしょう。

![スクリーンショット 2024-12-15 22.53.49.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/870220/c365fde6-7e8b-6b47-01b3-ed633d9f3873.png)

正確に「あ」を30文字得られました。

## 工夫２：中間言語として Python スクリプトを生成
次に文字列を直接出力させるのではなく、それを生成するプログラミング言語を中間言語として生成してもらう方法を試してみます。

中間言語として生成が安定している印象のある Python を指定しました。

![スクリーンショット 2024-12-16 9.52.29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/870220/84b28a34-13b3-f84a-2fde-d96cda301745.png)

所望の Python スクリプトが生成されました。

![スクリーンショット 2024-12-16 9.56.40.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/870220/d4dff058-5ee1-47fa-5952-bf93c2bd4a0a.png)

また ChatGPT には Python スクリプトを実行する機能もあるため、実行結果についても正確に30文字になっています。

## おわりに

とりあえずマウントをとっておきます。

![スクリーンショット 2024-12-15 22.39.23.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/870220/9065ed10-c296-7d0b-f44b-d26585a70e06.png)
【WindowsForm】RichTextBox のフォントを TextBox のフォントと同じにする

今回は WindowsForm で
RichTextBox のフォントを
TextBox のフォントと同じ物にする方法について
紹介してみたいと思います。

個人的に RichTextBox のフォントよりも
TextBox のフォントの方が見やすかったため
紹介する事にしました。

また、この手法を使う事で
コピー＆ペーストをすると
一部の文字だけフォントが変わる現象も
回避できます。

***

作業 1 コンストラクタで Font をセットする

まずはコンストラクタで Font をセットします。

```csharp:作業 1
private TextBox sampleTextBox; //フィールド
public Form1()
{
  InitializeComponent();
  sampleTextBox = new TextBox();
  richTextBox1.Font = new Font(sampleTextBox.Font.Name, 12, sampleTextBox.Font.Style);
}
```

TextBox を仮で生成して
RichTextBox のフォントをその内容にしています。

作業 2 で使うため
private TextBox sampleTextBox; の
フィールドを作成しています。

フォントサイズ 12 の部分は
良い感じに調整して下さい。
sampleTextBox.Font.Size でも OK です。

***

作業 2 keyUp と KeyDown を設定する。

次に richTextBox1_KeyUp と
richTextBox1_KeyDown を設定します。

KeyUP と KeyDown を設定して
内容を以下の内容にします。

sampleTextBox フィールドは
作業 1 で作成したものです。

```csharp:作業 2
        private void richTextBox1_KeyUp(object sender, KeyEventArgs e)
        {
            e.Handled = true;
            if (e.Modifiers != Keys.Control)
            {
                richTextBox1.Font = new Font(sampleTextBox.Font.Name, 12, sampleTextBox.Font.Style);
            }
        }

        private void richTextBox1_KeyDown(object sender, KeyEventArgs e)
        {
            if (e.KeyCode == Keys.Z && e.Modifiers == Keys.Control)
            {
                richTextBox1.Undo();
                richTextBox1.Undo();
            }
            else if (e.KeyCode == Keys.Y && e.Modifiers == Keys.Control)
            {
                richTextBox1.Redo();
                richTextBox1.Redo();
                richTextBox1.Redo();
            }
        }
```

フォントが途中で変わらないよう
強引に KeyUP で再代入しています。

こうすればコピ＆ペーストした際に
一部の文字だけフォントが変わる現象を
回避する事ができます。

フォントを再代入する事で
Redo と Undo が 1 度では機能しないため
複数回叩いています。

フォントサイズ 12 は
作業 1 のものと同じにして下さい。
フォントサイズ 12 でも
マウスのコロコロで文字サイズを変える機能は
問題無く使えます。

***

以上の作業で RichTextBox のフォントが
TextBox のフォントと同じになります。

RichTextBox のフォントを調整したい場合は
地味に時間がかかるため
この記事を真似して頂いて
作業時間が短縮できた人が現れたならば
非常に嬉しいです。

この記事が皆さんの役に立てますように。
閲覧ありがとうございました。

***

追記

この記事を反映した
RichTextBox の挙動を知りたい方は
下記の URL でダウンロードできる
ソフトをご利用頂くと簡単です。(無料です)

[GoogleDrive でダウンロードする](https://drive.google.com/file/d/1Bhi808uP8gvDUx80gjc6FuYF248tadH7/view?usp=sharing)
[BOOTH でダウンロードする](https://giftedstyle.booth.pm/items/6283145)
blender2週間ぐらいやってみた感想卍

## [１]近況
 クソ忙しかったり、だるかったりしてblenderやるの１日約1時間ぐらいしかできませんが、なんだかんだ楽しんでいます♪
 途中までの成果を書き記します。(^^)
 ### blender始めようとしたきっかけ
 もともと3dで何か作るのが好きだったので、自分これ大好きなんじゃね？と思い、blenderいじってみました。(実際楽しい。)
## [2]1~8日目。「🍩で世界を埋め尽くす編。」
プログラマが一番最初に"HalloWorld!"って書くように3dモデラーが一番最初にやるのはドーナツを作ることです！🍩
私はこの記事を参考にしてドーナツを作りました｡
https://note.com/litaruismart/n/nc503ff7179c5
（Blender初心者がYotubeみながら３Dドーナツ作ってみる。①～㉑）
英語がわかる人はこちらも参考になります｡（分からなくても画面死ぬ気で見たら何とか習得できます｡👀）
https://www.youtube.com/watch?v=4haAdmHqGOw&t=1889s
（Beginner Blender 4.0 Tutorial - Full Course）
## [3]9,10日目。「物理演算でシーツ被せる編。」
物理演算を利用してシーツを被せました｡
物理演算の操作方法はこの記事を参考にしました。
https://note.com/kitaniosam/n/n830327c3ed7b
（blender 4.2 クロスシミュレーションでベッドを作る）
最初は平面でやってみたのですが、、、
なんだこれ薄すぎるわ！寒さで死ぬ！！！😠
![こたつ様.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3929138/f236aac9-60b3-ff1a-deb8-86e4b5b7fe81.png)
という訳で厚さを変えて再チャレンジ!
しかし厚くした分、演算対象が増えたのでカクカクします。
もう重すぎ♡
そしてできたのがこんな感じ、いい感じにシーツが掛かっています。
![こたつ様2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3929138/7a819333-54a8-917e-d8c2-4da29880df26.png)
## [4]11日目。「🍵押し出ししまくった結果なぜか湯呑ができた編。」
辺もしくは、面を選択してEキーを押すと押し出しといって、図形を伸ばすことができます。私はトーラスを押し出しして湯呑の淵を作りました！！
記事を調べてもバージョンごとに操作方法が違うので、調べるのに苦労しました。
![YUNOMI.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3929138/1a6c5bee-32c0-67f4-b4f0-9b4fe89537f5.png)
## [5]14,15日目。🎲「テクスチャペイント編。」
今日は気軽にテクスチャペイントをしようかなと思ったが、UV展開｢無量空処｣🤞🏼
はい。UV展開って何すか？そして追い込むように「シーム」という単語が襲い掛かってくる！！
もうやめて、、、
下記の動画を見てなんとか理解しました、、、
https://www.youtube.com/watch?v=gV-E0XJUTWg
（【初心者向け】blenderのテクスチャペイントでサイコロを作ろう【最短で理解】）
![スクリーンショット 2024-12-03 233940.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3929138/f5fb8700-afc3-38f0-13c1-8b8c5583ed09.png)
## [6]16,17日目。「とりあえず障子をつくってみた。」
なんか作りたいなと思い、障子を作ってみました。上の部分は長方形を並べてコピーしていく感じで出来ました。下部分は円のくり抜いて、うまい感じに立方体を配置していけば完成できます。（うまい感じってなんだよ。）
![スクリーンショット 2024-12-05 011654.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3929138/b439c7a1-8b41-72e5-3653-c1cbeb565544.png)

![スクリーンショット 2024-12-06 011226.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3929138/600d809e-0178-69aa-9d1f-dae820f48e6a.png)
## 100日目に向けて、、、
これからもいろんなものを作っていきたいと思います！
が、100日連続は少々きつくなってきましたので、やれたらやる方式にします、、、
そろそろクリスマスなので、その日までには１つクリスマスに関する作品を整作したいです。
Chrome flagsに踊らされた

こんにちは。
この記事は、ラクス [Advent Calendar 2024](https://qiita.com/advent-calendar/2024/rakus) 18日目の記事です。

例年はオフショア開発について書いているのですが、今回は[Chrome flags](https://developer.chrome.com/docs/web-platform/chrome-flags?hl=ja)に踊らされた話をします。


# Chrome flagsとは
ブラウザ内で実験的な機能や設定を有効にするための隠しオプションです。
例えばPiPの検証やjava scriptの有効・無効を切り替えたりなど、通常の設定メニューには含まれない開発者が動作確認等で使うための機能です。

この機能を使ったことで、**インシデント発生未遂事件**は発生しました…。

# ことの経緯
弊社製品内ではjsイベントである[unload](https://developer.mozilla.org/ja/docs/Web/API/Window/unload_event)イベントを利用していました。
簡単に説明すると画面が閉じるときに発火するイベントです。

製品内には画面を閉じるときに親画面をリロードしたり、値を反映したりなどでかなりの量のunloadが仕込まれておりました。

さて、なぜこの話をしたかと言うと、Googleから「[chromeでunloadを使えなくするやで～](https://developer.chrome.com/docs/web-platform/deprecating-unload?hl=ja)」といつの間にか発表されていたのです。

たまたま別件で見ていた時に気づいたメンバーがいたことで事なきを得てなんとか修正はリリースできました。
(検知する仕組みないんかいというのは置いておいて)

<INS>こちらのテストをする際に、Chrome flagsにて、unloadを無効にする設定をしたのです。</INS>

![flags.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/858413/d15c6096-eda9-a518-d853-cdd05a7835d2.png)
「unloadの廃止を有効にする」って言いまわしなんなんでしょうね。
unloadを使えないようにするためにunloadの廃止を有効にしました。分かりにくい。
直感的には`disabled`にするのかなと思うんですが、`enabled`にするとunloadが発火しません。
ずっと同じことを言っているだけです。

ただ、この対応を巡って騒ぎが起きたのです。

# リリース前のとある日…
社内チャットにて、顔面蒼白の私が一人騒いでいました。

![インシデント未遂.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/858413/fa4ae250-a7de-799a-c311-4d489d83901f.png)


unloadが直されていないバージョンですでにunloadイベントが発火していない！
= インシデントだ…(死)(予想より早く無効にされた怒り)

騒ぐ前におかしな点がないかは十分確認したつもりでした。
* 発見したメンバーと自身のChrome flagsを確認
  * 設定値は`default`になっているため、chromeのデフォルト(unloadはまだ有効)に従っているはず
    * この二人は開発時のテストで一度unloadを`enabled`に変更した
* 修正を加えたバージョンで再現するか
  * 再現しない。なぜならもうunloadはないから
* どの設定値にしても発生した
  * これは嘘。よくよく見たら`disabled`では発生していなかった


まだ猶予があると思って修正の加わったバージョンはリリースしていない。
とんでもない事態かも…

ただ、顧客からの問い合わせは一切ない様子。

# あれ、インシデントじゃない…？
でも、defaultなのに発火しない(ユーザーは設定値変えてることもないだろうしdefaultのままのはず)
なんで…と思い、他の同僚数人に確認してもらいました。
なんと、他の同僚は設定値`default`なのに再現しません。
ついでに`enabled`にしてunloadが発火しなくなったのを確認して、`default`に戻してもらいました。
再現しません。
結論、全くインシデントじゃなかった。

本当になんで？？？？？？？

# 推測
**Chrome flagsの`default`の定義って、どっかのタイミングで書き換わってる…？**
もしかしてだけど、`enabled`のままchromeアプデされたとか何らかのトリガーで、`enabled`が`default`になってる…？

弊社のテックブログに書かずにアドカレで書いた理由がここに詰まっているのですが、結論として**明確な根拠は見つけられていません。**
なのでずっとふわふわした内容になっています。

![結末.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/858413/29c8059d-10c1-6ded-e473-c6472a523a4e.png)
チャットでもずっとふわふわしたまま連投してる。

# 教訓
Google公式ではないですが[tourbox](https://www.tourboxtech.com/jp/news/about-chrome-flag.html?srsltid=AfmBOooq23fe_ZK6TTmq5he9BpPhnKBuVQ1IwWB1eNMIXqLoWvCH_GAI)の記事で以下のように記載されていました。
> しかしこれらの機能は開発中であり、安定性が保証されていないため、注意が必要です。

インターネット数十年、エンジニア数年やっているのに「ベータ版とかって想定外の不具合とかはあるものの、リリースはしてるしなんだかんだ何不自由なく使えるでしょw保険でしょw」みたいな舐めたことを考えながら過ごしていた今までの自分に喝を入れます。安定性が保証されてないんよ。

あとは`default`という言葉、これに対する疑念の気持ちを強く持つこと、これ大事です。
有効・無効・初期設定みたいな選択肢あるなら明確に有効・無効を選ぶのが正しい。
とはいえ顧客は`default`になってるだろうしと思うとがんじがらめではある…

締めもふわふわしたまま終わります。
PromQLを用いた平日日中のみのメトリクスの抽出

# はじめに
:::note info
🎄 本記事は [ZOZO Advent Calendar 2024](https://qiita.com/advent-calendar/2024/zozo) シリーズ4の17日目です
:::

開発環境に構築するDBなどは、コスト抑えるために平日日中のみ起動する運用が多い。
PromQLを用いて、平日日中のみメトリクスを取得するようにしたい。

PrometheusはTimezoneの設定ができず、全てUTCベースで考える必要がある。

https://prometheus.io/docs/introduction/faq/#can-i-change-the-timezone-why-is-everything-in-utc

> **Can I change the timezone? Why is everything in UTC?**
To avoid any kind of timezone confusion, especially when the so-called daylight saving time is involved, we decided to exclusively use Unix time internally and UTC for display purposes in all components of Prometheus. A carefully done timezone selection could be introduced into the UI. Contributions are welcome. See issue #500 for the current state of this effort.

# 解決方法
JST において、**月〜金の12時〜18時** のメトリクスを抽出する。

```prometheus
(
  ((day_of_week() == 0 and hour() >= 15) or 
   (day_of_week() >= 1 and day_of_week() <= 4) or 
   (day_of_week() == 5 and hour() < 15))
  and 
  (hour() >= 3 and hour() < 9)
)
```

- day_of_week() による曜日のフィルタ:
    - `day_of_week() == 0 and hour() >= 15` UTCの日曜日の15時以降は、JSTでの月曜日の0時以降に対応
    - `day_of_week() >= 1 and day_of_week() <= 4` UTCの月曜日から木曜日は、そのままJSTの火曜日から金曜日と対応
    - `day_of_week() == 5 and hour() < 15` JSTの金曜日9時〜24時に対応

- hour() による時間帯のフィルタ:
    - `hour() >= 3 and hour() < 9` UTCの03:00〜09:00はJSTの12:00〜18:00に該当する

# 実際の使用例
下記はDatastreamのFreshnessメトリクスを基に、
平日日中のみを対象にしたアラートポリシーの例。

```terraform
resource "google_monitoring_alert_policy" "datastream_data_freshness_alert" {
  display_name = "Datastream Data Freshness Alert"
  combiner     = "OR"
  conditions {
    display_name = "Datastream Data Freshness condition."

    condition_prometheus_query_language {
      query               = <<EOT
        avg_over_time(
            datastream_googleapis_com:stream_freshness{
                monitored_resource="datastream.googleapis.com/Stream",
                stream_id="{ストリームID}"
            }[60s]
        )
        and on ()
        (
          ((day_of_week() == 0 and hour() >= 15) or 
           (day_of_week() >= 1 and day_of_week() <= 4) or 
           (day_of_week() == 5 and hour() < 15))
          and 
          (hour() >= 3 and hour() < 9)
        )
        > 1800
        EOT
      duration            = "300s"
      evaluation_interval = "300s"
    }
  }
}
```

# おわりに
時間によるフィルタが無い場合は、filter句に[Loggingのクエリ言語](https://cloud.google.com/logging/docs/view/logging-query-language?hl=ja)などを使用して、シンプルに書けるが、平日の日中のみのスコープだと上記を方法では実現できなかった。
今回は、PromQLを用いることで実現した。

[スヌーズ](https://cloud.google.com/monitoring/alerts/snooze?hl=ja)機能なども検討したが、柔軟な時間設定ができなかった。

# 参考
https://qiita.com/tatsurou313/items/64fcaae3567f24d13dd5

https://cloud.google.com/monitoring/promql?hl=ja

https://cloud.google.com/monitoring/promql/promql-in-alerting?hl=ja
WindowsServerOSを試用版から製品版にアップグレードするときのTips

# 一体いつから...
- 2016年に新卒でITインフラの世界に飛び込んでから、なぜか会社のとあるプロダクトはWindowsServer 2008 R2しか使用していなかったため、そのころの感覚で**Windows Server 2022の試用版を仮想マシンで構築し、その後プロダクトキーを適用すればいいやと思っていたら、それだけでは手順不足**でもう一手間加える必要があった。
- 直近の記憶ではWindows Server 2019も試用版から製品版にアップグレードしたが、その時もこういった手順ではなかったはず...

# もう一手間とは
参考

https://learn.microsoft.com/ja-jp/windows-server/get-started/upgrade-conversion-options

- 要は、**試用版のプロダクトを使用している状態で、製品版のプロダクトキーを適用することはできない**という単純な落ち。
    - なので、GUIの設定→更新とセキュリティ→ライセンス認証からプロダクトキーを入力してもNG(製品が試用版であるため)
- 製品をコマンドプロンプトで製品版に変換したのち、製品版のプロダクトキーを入力する

## 最後に
- これだけのことだけど、間違ったライセンスを購入したんじゃないかと焦りました。
    参考になれば幸いです。
Salesforce組織のメタデータを全部抜く

12月初旬の更新をすっかり忘れていて、無資格開発者となりました。ブラック〇ャックみたいな気持ちで頑張っています。

さて、Salesforceのバックアップって、運用者・開発者の大きな悩みの一つだと思いますが、今回はメタデータのバックアップについてです。
昔からできていたのかもしれませんが、Salesforce CLIにてそれなりに簡単にメタデータがごそっと抜けるようになっています。

手順としては、マニフェストを作った後に、そのマニフェストを使ってメタデータを読み取るだけの話です。
使用するsfコマンドは[sf project generate](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_project_commands_unified.htm#cli_reference_project_generate_unified) manifestでございます。
`--from-org`というオプションが、メタデータの目録である`package.xml`作ってくれるので、数分待ちましょう。

```
> sf project generate manifest --output-dir ./manifest --from-org <orgname/alias>`
successfully wrote package.xml to ./manifest
```
わぁ、全部抜けちゃうかもというワクワクを噛み締めながら、よーし全部読みこんじゃうぞ！と次のステップに進みましょう。
使用するsfコマンドはいつもお世話になっております[sf project retrieve start](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_project_commands_unified.htm#cli_reference_project_retrieve_start_unified) です。この`start`って冗長に感じるのは、僕の英語火力不足に違いない。
`--zip-file-name`オプションはお好みで…

```
> sf project:start:retrieve -o <orgname/alias> -x .\manifest\package.xml -t .\manifest --zip-file-name metadata.zip
Retrieving v62.0 metadata from <orgname/alias> using the v62.0 SOAP API
Preparing retrieve request... Succeeded
Wrote retrieve zip file to \manifest\metadata.zip.
```

これでメタデータのバックアップは完了です。全部抜けたはずのメタデータをスクラッチ組織になどにデプロイしてみて初めてバックアップができたことになりますが、一発でデプロイできることはないので、まごころを込めてデプロイを試してみましょう。その辺のTipsめいたものは（時間が足りないので）またの機会にします。

と、あんまり大きくないSalesforce組織の場合は、単純な話ではありますね…

## `sf project retrieve start`の読み込み件数は1万件未満にしないといけないらしい
試行した案件の対象組織では大量のレポートが存在したようで、`package.xml`内のメタデータは1万件を軽く超えていました。

```
> sf project:start:retrieve -o <orgname/alias> -x .\manifest\package.xml -t .\manifest --zip-file-name metadata.zip
Retrieving v62.0 metadata from <orgname/alias> using the v62.0 SOAP API
Preparing retrieve request... Failed
Error (LIMIT_EXCEEDED): LIMIT_EXCEEDED: Too many files in retrieve call, limit is: 10000
```
まごころを込めて`package.xml`を手動で分割、それぞれの読み込めば大丈夫です。

## `sf project retrieve start`は`sfdx-project.json`に定義したAPIバージョンで抜いてくる
オプションでも制御できるように思うのですが、`sfdx-project.json`を最新にしておくとよいように思います。Salesforce CLIにて抜いてくるメタデータの形式はAPIバージョン間で破壊的変更が結構見受けられると感じています。

## `ExperienceBundle`は組織側の設定で有効化することが必要
組織の設定で有効にしないと抜けなかったりです。ExperienceCloudサイトをお持ちの方はご注意くださいませ。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/53358/e0fb1f30-39b4-62b7-8000-22194feae591.png)

マニフェストを作くるのは凄い簡単でしたが、読み込みとデプロイはひとつづつ丁寧に解いていくしかないし、Stack Overflowには足を向けて寝れなくなります。

この記事は、[Salesforce Advent Calendar 2024](https://qiita.com/advent-calendar/2024/salesforce)の11日目に投稿するつもりだったものです。
Database：Optimistic LockとPessimistic Lock

データベースの利用の時、同期問題を解決することは非常に重要な課題です。
多くの人が **Optimistic Lock（楽観ロック）** と **Pessimistic Lock（悲観ロック）** について聞いたことがありますが、これら2つのロックの仕組みや適用シナリオについては明確でない場合があるかもしれません。
本記事では、2つロックを紹介し、それぞれの利点と欠点を分析することで、実際のプロジェクトでより良い選択ができるようにします。

<h2>Optimistic Lockとは？</h2>

Optimistic Lockは、「データを更新する前に、衝突が起こらない」と仮定し、
主に関連性の少なくてアクセス頻度が高いなデータ環境で使用されます

<h3>実現手順</h3>

- Optimistic Lockは通常、バージョン番号や更新回数のコラムを使用して同期問題を解決：
1. データを更新する前に、バージョン番号または更新回数を取得
2. レコードを更新する時に、現在のバージョン番号と取得時のバージョン番号を比較
3. バージョン番号が一致していない場合、データが他のユーザーに更新されたと判断され、更新失敗になります

<h3>実装例</h3>

- バージョン番号列を使用した Optimistic Lock の簡単な実装例
```sql
-- users テーブルには id, name, version=1 列が含まれているとします。

-- データを取得
SELECT id, name, version FROM users WHERE id = 1;

-- データを更新
UPDATE users
SET name = 'New Name', version = version + 1
WHERE id = 1 AND version = 1;

```

<h3>利点</h3>

- データベースのロックを使用しないため、効率が高いです

<h3>欠点</h3>

- 衝突頻度が高い場合、retry頻度が高くなってスループット低下の問題を起こします

<h2>Pessimistic Lockとは？</h2>

Pessimistic Lockは、「更新衝突の可能性があるため、他のユーザーがデータを使用しないようにロックする」と仮定します


<h3>実現手順</h3>

- Pessimistic Lockは通常、データベースのロック機能を使用して実現されます

1. データを読み取る時に、当該デーたをロックして他のユーザーが読み取ったり更新したりするのを防ぎます
2. 更新が完了した後、ロックを解除

<h3>実装例</h3>

- ロックを使用したPessimistic Lockの簡単な実装例
```sql
-- Transactionを開始
START TRANSACTION;

-- 対象データをロック
-- FOR UPDATE を使用してデータをロックし、他のTransactionが同時にデータを変更するのを防ぎます
SELECT * FROM users WHERE id = 1 FOR UPDATE;

-- データを更新
UPDATE users SET name = 'New Name' WHERE id = 1;

-- コミット
COMMIT;
```

<h3>利点</h3>

- データの整合性が確保できます
- よく衝突が多発する環境に使用されます

<h3>欠点</h3>

- ロックを使用するため、システム負荷が増加します
- ロックが長時間解除されない場合、デッドロックを引き起こす可能性があります

<h2>Isolation levelとの関係</h2>

データベースのisolation levelは、Optimistic LockとPessimistic Lockの選択や実現方法など直接に影響します

<h3>Optimistic LockとIsolation level</h3>

Optimistic Lock は、Read CommittedやRead Uncommittedなどの低Isolation levelで効率的に動けます。
これらのIsolation levelは、複数のTransactionが同時にデータを読み取ったり更新したりできて、バージョン管理によって衝突を回避します

- Read Uncommitted：
未コミットの変更を読み取ることがOKですので、潜在的な衝突を処理する必要があります

- Read Committed：
コミット済みの変更のみを読み取ることを保証し、衝突の発生可能性を減少させます

<h3>Pessimistic LockとIsolation level</h3>

Pessimistic Lockは、Repeatable ReadやSerializableなどの高Isolation levelの環境で使用されます

- Repeatable Read：
同一データを複数回読み取る場合に、他のTransactionで変更されたデータを読み取らないことを保証します

- Serializable：
Transactionを完全に隔離し、すべての可能な衝突が回避できます。厳密な整合性が必要な場合に使用されます

<h3>Isolation levelの選択ポイント</h3>

Optimistic Lockと Pessimistic Lockを選択する際は、下記の4つのポイントを考慮する必要があります：

1. 衝突率: 衝突率が低い場合はOptimistic Lockが優先、逆の場合はPessimistic Lockを利用します
2. 効率要件: 再試行が許容されない場合は、Pessimistic Lockを利用します
3. 整合性: 重要なデータの整合性要件が高い場合は、Pessimistic Lockが優先
4. 基盤能力: 最終的には、システムのサポート能力やデータベースの機能が選択に影響を与えることがあります

<h2>まとめ</h2>

Optimistic LockとPessimistic Lockはそれぞれに利点と欠点があり、その選択は実際のシナリオに基づいて考える必要があって、
ロックモデルについて理解を深めることで、実際のプロジェクトの効率や安定性など向上させることができます。
また、データベースのIsolation levelとの組み合わせにより、柔軟な同期戦略を設計し、多様なニーズに対応することが可能です。
今一度基礎からアウトプットしていこう。ビルド編

### コンパイル？ビルド？・・・てかそれって何の為にやって・・・？

分かんなくたって良いじゃない。人間だもの。機械語だもの。

#### ビルド
ソースコードをコンピュータが実行可能な形式（バイナリファイル）に変換するプロセスのこと。以下ビルドをさらに分解してみてみる。
## ビルドプロセスの流れまとめ
以下は、ビルドプロセス全体の流れを簡単に表したものです。

1. **ソースコード → プリプロセス**  
   ソースコードを展開・整理。

2. **プリプロセス済みコード → コンパイル**  
   中間コードまたはオブジェクトファイルに変換。

3. **オブジェクトファイル → アセンブル**  
   バイナリ形式のオブジェクトファイルを生成。

4. **オブジェクトファイル & ライブラリ → リンク**  
   実行可能ファイルを作成。

5. **最適化（必要に応じて）**  
   実行速度や効率を向上。

6. **パッケージング（必要に応じて）**  
   配布用の形式に変換。

### 所感
アプリインストール時の沢山のファイルは、必要なライブラリ・リソースファイルだったという事。また分離した方が拡張性に優れているとのこと。
リンクしてからコンパイラしなかったのは、それが理由だったのか。
今になって腑に落ちた。
React + MUI 信者が Nuxt + Vue3 を使ってみた

去年に続き、2回目のアドカレ参加です！
## 自己紹介
私はこれまで React + MUI という技術スタックで開発を行ってきました。
React を使い始めたのは、知り合いの勧めがきっかけです。
MUI は、UI を考えるのが苦手な私が、簡単に良い感じに UI を作れるという素晴らしさに惹かれて使い始めました。

🎉そんな私が最近、Nuxt + Vue3 をばりばり使うことになりました！🎉

AWS や Azure といったクラウドサービスも、似たような技術を知っていれば差分学習でスムーズに学習できることが多いですが、React と Vue も同様だと感じました。


そんな「差分学習」を経て、思ったことをポエムります。

## ポエム
### 必死に止めてた再レンダリングからの解放
Vue の公式ドキュメントもおっしゃる通り、Reactってレンダリングがとっっっても曲者だと思います。
予期せぬタイミングで再レンダリングが発生し、いつもそれを止めるためにフックを大量に書いていた記憶があります。
ですが、Vue だとほとんど意識せずに、うまくレンダリングしてくれるんです。

必要な部分だけ、自分で制御を実装すればいい

天才ですね！

🎉レンダリング地獄から解放されました🎉

### 子から親にイベントを渡すのがちょいややこしい
vue には emit という概念があり、普段（個人的に）意識している 親 → 子 の関係だけではなく、親 ↔︎ 子 が可能になります。この時点で頭がこんがらがってきました。。。

しかも！です

emit の 公式ドキュメント からコードを拝借して。。。
MyComponent というコンポーネントの some-event にcallback を渡します。
```
 <MyComponent @some-event="callback" />
 ```
MyComponent というコンポーネントではsomeEvent という名前でそれを扱います。
```
 <!-- MyComponent -->
 <button @click="$emit('someEvent')">Click Me</button>
 ```
えっっっ (´-ω-｀)
子コンポーネントではキャメルケース、親コンポーネントではケバブケースに変わるんです。

これにはかなり苦戦しました (°ㅂ°҂)


### Vue のいいなって思うところ（感想）
Vue は HTML に似た構文で、CSS も直感的に書けるので、とても書きやすいと感じました。
React を初めて勉強した時、再レンダリングの仕様や JSX に苦しんだことを思い出します。
HTML と、微妙に違うので、悩みながらコードを書いていると無限レンダリングに入りエラーが出てたり。。。
Vue の方が、学習曲線が緩やかで、初心者にも扱いやすい印象です。
### React のいいなって思うところ（感想）
React は好きなように作ってね！というスタンスなイメージです。
俺が考えた最強の。。。 みたいなことをよく見聞きしてました。
最初の方は選択肢が広く悩むことも多かったですが柔軟性があるのは良いことだと思います。
Vue はある程度推奨される方法があるため、外部ライブラリなどを取り入れることが少ない印象です。
## 最後に
React も Vue3 も流行り話題の技術でどちらも良し悪しがあります。
ここに書いていないこともたくさん感じて色々な知見を得ることができました。
今回は少しふわっとした内容になってしまいましたが、いつかもっと詳しくなった時にまた記事を書こうと思います！

多分こういうフレームワーク初めてだわって人は vue から入るのが学びやすいのではと思います
ただ、 React も良いところがたくさんあるので推しておきます！

みなさんクリスマスプレゼントはサンタさんにお願いしていますか？
忘年会のための胃袋と肝臓は用意できていますか？
おせちやお雑煮を食べすぎない心構えは大丈夫ですか？

良いお年をお過ごしください！
Gakken LEAP エンジニアリング部のご紹介

# はじめに

初めまして。</br>
Gakken LEAPのエンジニアリング部長の山下です。

アドベントカレンダー参加は私が言い出しっぺなのでエンジニアに「お前も書け」と言われ夜な夜な書いております。

しかし私は部長ということもあり全くコードを書いたりしません。</br>
今でも技術についてはいろいろ調べたりはしていますがコードは書かない！！！

そんな私がQiitaの！テックブログに！！何を書いたらいいんだ・・・という悩みがありましたが、
弊社エンジニアリング部での活動について書いてみたら少しは暇つぶしになるのかな・・・？と思いましたので書いてみます。

# Gakken LEAP エンジニアリング部とは

エンジニア全員が属する組織です。</br>
部長は私で、その下はメンバーという非常に簡素な階層構造となっております。

## 部としての方針

「**アウトプットの最大化**」

かっこいい言葉とかは何もつけずこの一点を日々追求しようとしています。</br>
ただ、KIAIや根性みたいなものは撤廃しています。ホワイトです。</br>
ここについて色々書くとそれだけで終わってしまうので書きませんが、少なくともアウトプットがないとアウトカムもインパクトも出せないと思っています。

## 部としての活動

アウトプットの最大化を行うための一助になればとか、ちょっと日常の業務とは違う刺激を与えられればということでやっています。

### テック会

名前がダサい！と言われたら何も言い返せませんが、エンジニアリング部全体の催事で月次開催しています。

内容としては色々あって、毎月企画メンバーが頭を捻って考えてくれています。

- 心理的安全性は大事だ！と言いながら**ゲーム**をしたり**ピザを食べたり**
- アルゴリズムの深淵を覗こう！と言いながら**AtCorderで競争**したり
- パフォーマンスは大切です！と言いながら**社内でISUCONを実施**したり
- ちなみに12/13にもやりましたが、そのときは「**年末だから遊ぼうぜ！マリオパーティだ！！！**」ということでみんなでマリパしました。

このTechBlogも色々手探りが多くて、このあたりの記事が作れてないのは今思うと悲しいですが、今後はこのあたりもどんどん発信できればと思います。

※「ISUCON」は、LINEヤフー株式会社の商標または登録商標です

### Tech Wednesday

別に水曜日にやらなきゃいけないってわけでもないのでもはや名前って・・・のレベルですが簡単に言うと部活みたいなものです。

条件は特定のテーマに2人以上人が集まれば業務時間内に実施していいよというもの。</br>
※業務時間内にやっていいけどメインのタスクはちゃんとやってね！は前提です。

具体的に今やっているのは

1. **アプリケーション開発**
   - みんな開発好きですね。今はオールスター感謝祭風ゲームを作っています。
2. **勉強会**
   - セキュリティとか色々やってましたが、今はTypeScriptについてやっていますね。
   - もっと数が増えないかなーと観察しています。

もう少し人数が増えたらこのあたりはもっと活発になるでしょうし、</br>
それでなくてもどんどん盛り上げていきたいところですね！

# さいごに

いかがでしたでしょうか。</br>
弊社のエンジニアリング部はこんなところです！</br>
もし興味を持たれた方はぜひカジュアルにお話できればと思いますので応募して下さい！

# エンジニア募集

Gakken LEAP ではエンジニア組織を盛り上げたい！とか教育をアップデートしていきたいエンジニアを絶賛大募集しています！！</br>
ぜひお気軽にカジュアル面談へお越しください！！

https://gakken-leap.co.jp/recruit/
API Best Practices ~サービス名を意識しユニークなものにする

## サービス名を意識しユニークなものにする

https://protobuf.dev/programming-guides/api/#service-name-globally-unique

.proto ファイル内の service キーワードの後の部分であるサービス名は、サービスのクラス名を生成するだけでなく、驚くほど多くの場所で使用されます。
そのため、この名前は思っている以上に重要です。

厄介なのは、サービス名がネットワーク全体で一意であるという暗黙の仮定をしていることです。
さらに悪いことに、それらが使用するサービス名は、修飾されていないサービス名（たとえば、MyService）であり、修飾されたサービス名（たとえば、my_package.MyService）ではありません。

このため、特定のパッケージ内に定義されている場合でも、サービス名の命名衝突を防ぐための措置を講じるのが理にかなっています。
たとえば、Watcher という名前のサービスは問題を引き起こす可能性が高いため、MyProjectWatcher のような名前の方が適しています。

---

メッセージには、パッケージ名が付けられるため、メッセージ名はパッケージ内で一意である必要はありません。
冗長性を避けるために、メッセージ名は短く保つことが一般的です。
新規事業おけるアジャイルやデザイン思考の落とし穴

　アジャイルやデザイン思考は、イノベーションに向いているように見えますが、実は向いておらず、実は改善に向いている…という話をしたいと思います。但し、抽象化された本質的な論理を展開するのではなく、様々なところを決め打ちで論じますので、あくまでも一つの考え方としてお読みいただけますと幸いです。

　「アジャイル×デザイン思考＝イノベーション」という式は、「新規事業はセンミツ（3/1000の成功率）であり、正解は誰にも分からないのだから、ユーザー起点でアイデアを思いついたら、さっさとMVPをプロトタイプして、ユーザーに聞きながら、改良を繰り返していくのが良い方法なのだ」というロジックで成立していると思います。本当にそうでしょうか？

　このロジックは「ユーザーは正解を知っている、もしくはユーザーは正しい判断ができる」ことを前提として成立します。確かにユーザーの想像力が及ぶ世界においてはその通りでしょう。しかしユーザーの想像力が及ばない世界においてはどうでしょうか？

　ウォーターフォール開発とアジャイル開発の違いを説明するとき、しばしば車のMVPの例が用いられます。ウォーターフォールでは、最初にタイヤを作るけど、アジャイルではスケートボードを作るという説明です。我々は車を知っているのでこの例は正しいように思えます。しかし車が無かった時代に、一般人にスケートボードを見せて何が得られるでしょうか？もしかすると機関車が存在していれば、スケートボードを見せてそれなりに説明すれば伝わったかもしれませんが、では蒸気機関すら無かった時代ならばどうでしょうか？

　アジャイル×デザイン思考は、ユーザーがイメージ出来る世界においてのみ有効であり、つまりは、既存事業や既存プロダクトの改善において非常に有効な手段と言えます。イノベーションは、ユーザーがイメージ出来ない世界を作り出すものですので、ここにおいては決して適切な手段ではない。

　故スティーブ・ジョブズ氏は「ユーザーは答えを知らない」という主旨の言葉を残されています。故松下幸之助氏も故盛田昭夫氏も、故イ・ゴンヒ氏も、稀代のイノベーター達は、同じ主旨の発言や逸話を残されています。

　ユーザー評価重視は、自分ではなく他人に判断をゆだねる行為とも言えます。

　失われた30年を40年にしないためにも、「ユーザーは正解を知っているや」「よいアイデアは現場から生まれる」などの前提を疑ってみることが、今の日本に一番必要なことだと思います。
API Best Practices ~冪等性を優先する

## 冪等性を優先する

https://protobuf.dev/programming-guides/api/#prefer-idempotency

クライアントで再試行する可能性があります。
再試行結果が変わる場合、ユーザーに驚かれるかもしれません。

重複する書き込みを回避する簡単な方法は、
サーバーで重複排除されるクライアント作成のリクエスト ID を指定できるようにすることです（たとえば、コンテンツのハッシュまたは UUID）。

```protobuf
// bad: 重複したitemが作成される可能性があります
message CreateItemRequest {
  string name  = 2;
  string price = 3;
}

// good: hash で重複を回避するサーバー側の処理を想定
message CreateItemRequest {
  string hash  = 1;
  string name  = 2;
  string price = 3;
}
```

---

ストレージのUK制約を使うことも考えられますが、このような手法でBFFなどのサーバー側のみで重複排除することもあります。

Request内容のhashをサーバで作成して、Redisなどで重複排除するケースなども出来そうですが、
冪等性を期待するかどうかはAPIの仕様によると思いますので、明示的にRequestに冪等性を担保する情報を持たせる手法は有用かもしれません。
アウトプットしないなんてもったいない！初めてのQiita投稿から得たこと

## はじめに
今回は下記アドベントカレンダーに参加したので「はじめてのアドベントカレンダー」の内容に沿った記事を書きたいと思います。

https://qiita.com/advent-calendar/2024/first-time

## アウトプットのきっかけと初めての不安
私が初めてQiitaに記事を投稿しようとしたとき、正直かなりのハードルを感じていました。他の人の記事をいくつも見て「こんなクオリティで書けるのかな？」と不安になるばかりで、結局最初は何も書けずに終わってしまいました。
しかし、Qiitaエンジニアフェスタという企画をきっかけに「思い切って挑戦してみよう！」と投稿を決意しました。（プレゼントほしさ:sweat_smile:

## 最初の記事：見よう見まねで挑戦
最初の記事は正直、技術的な内容ではありませんでした。
企画に便乗して、見よう見まねで「とりあえず投稿してみる」ことにしたのです。
また、各企業が開催しているプレゼント企画に参加したいという動機も背中を押してくれました。
イベント終了後は、バッジ機能のおかげもあり、少しずつ技術的な内容にも挑戦するようになりました。

👇最初の記事です💦

https://qiita.com/wa-chan222/items/6d9a9e754a563391759a



## アウトプットの効果と成長
記事を書くことにはじめは抵抗がありましたが、「誰かに見せる」という意識で書くことにより、自然と自分の考えが整理されました。
特にエラーでつまずいた内容を記録に残すと、振り返りや後で同じ問題に直面したときの解決がスムーズになります。
また、「次はこんな内容を書こう！」と考えるのも楽しくなり、アウトプットの楽しさを実感するようになりました。


## アウトプットを続けるコツ
最初から完璧を目指そうとすると、どうしても手が止まってしまいます。
私も最初は「とりあえず書いてみる」というスタンスでした。
続けていくうちに、記事を書くスピードが上がり、「次はこんな内容を書こう」と楽しく考えられるようになりました。
アウトプットの継続が、自分なりの楽しさを見つけるきっかけになったと感じています。

## さいごにまとめ
アウトプットは最初、少しハードルが高いかもしれませんが、続けることで必ず自分の成長を感じられるはずです。
Qiitaのようなプラットフォームは、記事を書く楽しさを見つけるのに最適な場所だと思います。
最初は小さな一歩でいいので、ぜひ勇気を出して投稿してみてください！
お客様とのやり取りで意識していること

この記事は、[Fusic Advent Calendar 2024](https://qiita.com/advent-calendar/2024/fusic) 15日目の記事です。
昨日は、 @pensuke628  さんの Storage Browser for Amazon S3 の記事でした。

https://qiita.com/pensuke628/items/e07fc669af233be3f6af

## 背景
こんにちは、10月に100キロウォーク完歩したことが今年一番の思い出になっている海老原です。（5月も歩く予定です）
私は今年の4月に新卒として入社し、研修後はLaravelを使ったバックエンド開発に取り組んでいます。
開発を行う中で、お客さまと文章でやり取りする機会が最近増えてきました。そこで今回は、自分が **「お客さまとやり取りを行う際に意識していること」** を紹介したいと思います。

:::note warn
以下に書いていることを完璧に実践できているわけではありません。
自戒の意味を込めてまとめているで、暖かい目で見ていただけると幸いです。
:::


## お客さまとのやり取りで気を付けていること

### ①相手が知りたい情報が何かを常に考える
（「こんなの当たり前だろ」と思っているかと思いますが、）自分はこれが一番重要だと思っています。たとえば以下のように、相手が求めている情報は状況や立場によって異なります。

- （経営者など）この開発で、できることが何なのか端的に知りたい
- （Web技術に詳しくない方）クラウドについて簡単を知りたい
- （Web技術に詳しい方）特定の処理について技術的な説明がほしい

相手がどんな情報を必要としているかを的確に把握することが重要です。
野球について何も知らない人に「野球について教えて」と言われた際に、いきなり「カーブ」と「スライダー」の曲がり方の違いを教えてもあまり意味はありません。（たとえが下手ですいません...）


#### ヒントを見つける
相手が知りたい情報の「粒度」は、お客さまが書いた文章やこれまでのやり取りにあると思います。その粒度を的確に把握し、適切な形で情報を伝えることが、エンジニアとしてコーディング以外に重要なスキルだと思います。

#### 情報を分かりやすく伝えるための工夫
- 結論をはじめに書く（起承転結ではなく、結論ファースト）
- 図や画像を使う

これらについて書かれている本や記事がいくつかありますが、その中でも自分が参考になったものをいくつか紹介します。

https://amzn.asia/d/bZ53ftg

https://mochikoastech.booth.pm/items/5703302


### ②他の人にレビューしてもらう
文章を書く際には、他の人にレビューしてもらうことをおすすめします。これは、ソフトウェア開発におけるPR（プルリクエスト）の考え方・目的と同じです。

#### 効果的なレビュー依頼方法
また、レビューを依頼する際は、以下のことを明記することをおすすめします。

- 相手が知りたいことは何なのか
- 自分の書いた文章で伝えたいことは何なのか

これにより、解釈のズレや余計な確認の手間を減らすことができると思います。

※もちろん、文章の推敲として、ChatGPTなどの生成AIを活用するのもいいかと思います。

:::note warn
この方法をやりすぎると、レビューをする側の負担になってしまうので、程々にお願いした方がいいと思います。（例：お客さまとのやり取りに慣れるまでお願いする etc.）
:::



## 最後に
お客さまとのやり取りは、エンジニアとして避けられない大切な業務のひとつだと思います。
今回は、私が気を付けていることを紹介しましたが、まだまだ学ぶべきことが多いと感じています。これからも成長を目指して取り組んでいきたいと思います。

ここまで読んでくださり、ありがとうございました！

---
明日のFusic Advent Calendar 2024 は、@kwashi さんが書きます。お楽しみに！
さくらのクラウドでトレーニング環境を提供する場合の接続方法

# はじめに
たまには会社のサービスの使い方を書いてみようと思った記事です。
さくらのクラウドを使うことでWindowsやLinuxの環境を簡単に作成することができます。用途は様々ですが、ここではトレーニング環境を提供するという想定をしてみます。
特にセキュリティベンダーの方はトレーニング環境を提供するにあたり、安全なトレーニング環境の構築に苦慮していることと思います。場合によってはマルウェアや攻撃ツール、実際の攻撃パケットを扱う可能性もあり、それらが外部に漏洩しないかという点においてかなり苦労しているのではないでしょうか。
また、受講者のレベルによってはSSHやリモートデスクトップで接続することも難しいという場合もあると思います。そんな場合にさくらのクラウドの機能が役に立つかもしれません。

# トレーニング環境の構築
環境そのものはIaaSですので簡単に構築できます。ここでは細かい点は以下のマニュアルを参照いただくことにします。

https://manual.sakura.ad.jp/cloud/server/create-delete.html

そして接続にSSHやRDPを使う（受講者がSSHやRDPのクライアントを難なく使える）ということであれば、もうこの記事を読む必要はありません。どうぞ他の有用な記事をご覧ください。

本記事では受講者の環境が人によって異なり、例えばmacからRDP接続の方法がわからないといった問題が発生しうる場合を想定します。
この場合の解決方法は2つあります。1つは利用者を頑張ってサポートすることですが、これはオフラインならともかく、オンラインで行う場合はかなり大変です。

# コンソールアクセス
そこでもう1つの方法である、マシンのコンソールに直接アクセスしてもらうという方法です。この方法にはいくつかのメリットがあります。
1. 利用者の環境に依存しない。
利用者はブラウザさえあればアクセス可能です。RDPやSSHのクライアントを用意する必要がなく、誰でも使っているであろうブラウザだけで受講することが可能になります。
1. SSHやRDPを許可しないことで、簡単なパスワードでも安全が確保できる（要パケットフィルタ）
さくらのクラウドでサーバを作ると、グローバルIPアドレスが割り当てられます。この場合外部からログインされる恐れがあるため、パスワードはそれなりに複雑もしくは長くする必要があります。コンソールアクセスを前提とするならば、RDPやSSHのポートはブロックできますので、パスワードが弱くても問題ありません。Windowsであればパスワードなしに設定しても良いでしょう。

もちろんデメリットもあります。コンソールアクセスはどうしてもレスポンスが遅くなります。操作に若干の遅れが出てしまうのはデメリットになります。これを許容できない場合はコンソールアクセスは使うべきではありません。

さくらのクラウドではシングルサーバコントロールパネルという機能を提供しています。これを使って受講者ごとに1台ずつサーバを割り当ててみます。

https://manual.sakura.ad.jp/cloud/controlpanel/singleserver.html

# 実際の手順
まず、受講者用のサーバを用意します。そしてパケットフィルタで全ポートへのアクセスを遮断します。

以下は設定可能なフィルタすべてで拒否する例です。許可が必要な場合は適宜許可する設定を追加してください。なお、**すべてのルールにマッチしなかったパケットは許可される**点に注意してください。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/549537/36100f85-68df-d8bf-3882-2bb2a5c1669d.png)

次にAPIキーを作成します。シングルサーバAPIキーを選択し、アクセスレベルは電源操作にする必要があります。紐づけサーバに受講者に割り当てたいサーバを選んでください。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/549537/3155c65b-2408-3e46-c350-919c17a4e510.png)

次の画面でアクセストークンとアクセストークンシークレットが表示されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/549537/ef152fac-b9bf-26bf-6045-52fb40bbfb83.png)



これを以下のページで入力します。

https://secure.sakura.ad.jp/cloud/single/

これでコンソールへのアクセスが可能になります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/549537/780010d2-2f41-33d8-baec-cf5807f07d30.png)

受講者の数だけこの操作を繰り返すことで、個人にサーバを割り当てることが可能になります。

# 後始末
トレーニングが終わったら、忘れずにAPIキーを削除するか、アクセスレベルを変更してください。
HTTPSとは

## はじめに
「このサイトHTTPS化してないしな〜信用できんな〜」みたいなことをよく耳にするようになりました？
改めてHTTPSについて調べてまとめてみました。

## HTTPSとは

### HTTPとの違い
HTTP (HyperText Transfer Protocol)はWebサーバとクライアントがHTMLなどのデータを統一のルールで伝送するためのプロトコルですが、変換や解説の中間で読み取られる危険性があります。

一方でHTTPS (HyperText Transfer Protocol Secure)は、SSL/TLSを使用してHTTP通信を暗号化したもので、相手方の識別とデータの暗号化を実現します。

### HTTPSの主要な機能
 - データの暗号化: 送信で使用されるデータを暗号化することで、中間攻撃を防ぐ
 - データの不正変更の防止: データが改ざんされていないことを確認
 - 相手方の認証: 相手が信頼できる機関であることを証明

## HTTPSが必要な理由

### セキュリティ向上
暗号化通信、改ざん防止、相手方の証明を実現します。

### ユーザーの信頼性向上
HTTPSで通信しているサイトはブラウザから信用されており、警告等は表示されません。
一方で、HTTPで通信しているサイトは、ブラウザ機能で警告が表示されることがあります。

### SEO利点

昨今の検索エンジンはHTTPSを使用しているサイトを優先して表示するため、SEOの向上にも繋がります。

## HTTPSの仕組み

HTTPSは**SSL/TLSというプロトコルで通信します。**
SSL (Secure Sockets Layer)は、暗号化通信を実現するために使用されるプロトコルです。
TLS（Transport Layer Security）はSSLの次世代規格になります。

SSL/TLSは、クライアントとサーバー間での通信を暗号化してくれます。

また、**SSL/TLSは公開鍵暗号方式と共通鍵暗号方式の両方を使っているのも特徴の一つです。**
下記の手順を踏んで通信を行なっています。

1. クライアント：SSL通信をリクエスト
2. サーバー：SSL証明書と公開鍵を送信
3. クライアント：SSL証明書の組織とリクエスト先が同一であることを確認
4. クライアント：共通鍵を作成。受け取った公開鍵で共通鍵を暗号化し、サーバーに送信
5. サーバー：公開鍵に対応する秘密鍵で復号化して共通鍵を取り出す
6. クライアント・サーバー：共通鍵を使って暗号化データをやり取り（暗号化通信）

SSL証明書は、SSL/TLSの技術を用いて「認証局(CA)」が発行する電子証明書のことです。SSL証明書を導入すると、通信データの暗号化や、サイトの運営者・通信相手が偽物ではなく正当に実在することの証明が可能です。

## HTTPSの実装方法
使うサービスによって手順は異なりますが、ざっくり下記の手順を踏む必要があります。

1. サーバーがhttps化に対応しているのか確認する
1. CSR（証明書署名要求）を作成する
1. SSLサーバー証明書を取得する
1. SSLサーバー証明書をインストールする
1. リンクをhttpsに置き換える
1. httpへのアクセスはhttpsへリダイレクトを行うよう設定する
1. Webサイトアクセスし、エラーが出ていないか確認する
 
※ SSL証明書には有効期限があるため、定期的に更新する必要がある

## まとめ
今やHTTPSは、すべてのサイトでの対応が求められるほど必須のプロトコルです。
今まで「なんとなくHTTPSだと安心」くらいの解像度だったのが仕組みを理解した上で設定方法などを学ぶとより頭に入ってきますね。
読んでいただきありがとうございました！


## 参考記事
https://office110.jp/security/knowledge/technology/secure-sockets-layer

https://www.gmo.jp/security/ciphersecurity/http-https/blog/always-on-ssl/
一人ハッカソン　11/16 Sp1-3

氷河期のマネジメント志向のふかのしんです。
(よく会社入れたねーと言われます。）

普段ドキュメントばかり書いているので、AI（Copilot）の力を借りながら、久しぶりに手を動かしてみようと
アドベントカレンダーの投稿のために奮闘する話です。

装備：
VisualStudioにCopilotはセット済。
Pythonもインストール済。

せっかくなので、15分スプリントを使用し、JIRAのカンバンボードで
管理していきたいと思います。

15分スプリントを2年間やったけど質問ある? #15min_sprint
https://speakerdeck.com/kyonmm/15fen-supurintowo2nian-jian-yatutakedozhi-wen-aru-number-15min-sprint

1スプリント　2024/11/16

JIRAカンバンボード作成
![スクリーンショット 2024-11-16 183348.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3936044/50fae45a-cdfc-9fc4-d66a-fe41f02caed9.png)

2スプリント　2024/11/16

ユーザーストーリーボード作成
![スクリーンショット 2024-11-16 190037.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3936044/362ea456-9c3e-440b-fde2-03b57c03cd2b.png)

3スプリント　2024/11/16

ログイン画面を作る
Copilot様に言われるがまま手を動かし、できた！
![スクリーンショット 2024-11-16 192308.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3936044/38b1cde4-2bca-c684-73d9-024fdf8ba0c7.png)

ただわからないことだらけ。
Flaskとは？仮想環境とは？
![スクリーンショット 2024-11-16 192232.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3936044/2aa26070-2f7e-fbbb-7eec-e7030271efef.png)