OmniAICreator/Qiita-1.07M huggingface dataset:
【TypeScript&Nuxt.js】占いアプリを作ってみる

# はじめに

最近ChatGPTで占いができるらしいと聞いたので、タロット占いを試してみた🔮
すると、どのように占ったかが「分析」というタブでPythonコードを見ることができた！

![IMG_3022.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3524465/70a8a307-cabd-4e10-9b6d-b4349c2c8ba2.jpeg)

確かにカードをランダムに引くことで占いができるのか、と気付き。。🧐（神聖さはない気がするけど）
これ、もしかしてTSとNuxtでもできるかもと思ったので勉強がてらやってみる🐣
配列や型定義など、基本的なところは勉強した程度。

占いについての知識は全くないので検索したり、GPTに聞きながら調べた。

※応用として占いAPIを利用できたらと考えている💭

:::note info
今回はChatGPTにはコードを出力させず、自分が詰まったときにアドバイスをもらう補助的な役割で使った。
:::


# 学べそうなこと
| 機能 | 学べそうなこと |
|:-:|:-:|
| カード一覧の配列を作る  |  TypeScriptでの配列・型の書き方 |
|  ランダムにカードを引く | JavaScriptのロジック（Math.randomなど）  |
| 結果を表示する画面を作る  |  コンポーネントの作成・分割 |
|  NuxtLinkで遷移させる | ルーティングやページ遷移の理解 |
|  引いたカードに応じて画像を表示 | 条件分岐と画像の扱い  |

# 進め方
（イメージをGPTに伝えて補足してもらった）

1.	**タロットカードのデータをTypeScriptで配列にする**
    型の作り方、配列の書き方
2.	**その中からランダムに1枚選ぶロジックを書く**
    JavaScriptの基本的な処理
3.	**結果を表示する画面を作る（1ページ）**
    Nuxtのページ、表示の基礎
4.	**カードごとに画像を表示してみる**	
    条件分岐、画像の表示
5.	**NuxtLinkでページ遷移（トップ→結果ページ）**
    ルーティングの基本
6.	**デザインを整える**
    CSSの利用
7.	**応用：今日の運勢APIを取り入れてみる**
    APIの呼び出しとデータ表示
8.	**データの組み合わせで文章を作る**

# セットアップ

プロジェクト作成。
```
✔ TypeScript
✔ Vue Router
✔ Pinia
✔ ESLint + Prettier
```
` Install Oxlint for faster linting? (experimental) `はNoにした。

# ステップ1.タロットカードのデータをTypeScriptで配列にする
` src/store/tarotCards.ts ` を作成した。

 ### ⭐️カードの情報
- 番号
- カードの名前
- 内容（タロットカードには正位置と逆位置があるから２パターン？）

```ts 
const tarotCards = [
  {
    id: 0,
    name: '愚者（The Fool）',
    normalMeaning: '自由、冒険、無限の可能性',
    reverseMeaning: '無計画、不安定、軽率',
  },
  {
    id: 1,
    name: '魔術師（The Magician）',
    normalMeaning: '創造力、チャンス、行動力',
    reverseMeaning: '詐欺、自己中心、実力不足',
  },
  // 以下略
]
```

ここまででGPTに確認したら２つ修正点が出た✅

### 📝①`store`じゃなくて`data`みたいなディレクトリにtsファイルを作るといい！

** 🗂️ storeとdataの違いをちゃんと理解する**
| フォルダ | 使い道 |例|備考|
|:-:|:-:|:-:|:-:|
| store  | アプリ全体で使う状態（state）管理  |「今引いたカードはこれ！」など動的なデータ|Piniaで使う（defineStore()を書く場所）|
|  data（自作） |  ただの静的なデータ置き場 |「全部のタロットカード一覧」など最初から決まってるデータ|TypeScriptの配列を置くのにピッタリ|

### 📝②型定義をした方が良い！
TypeScriptは勝手に型を推論してくれるため、明示的に書かなくても動くことが多い。
でも型を定義すると再利用・保守性がUPするのでtypeを作ってexportしよう。

```ts
// 型（type）定義
export type TarotCard = {
  id: number
  name: string
  normalMeaning: string
  reverseMeaning: string
}

// 配列に型をつける
export const tarotCards: TarotCard[] = [
  {
    id: 0,
    name: '愚者（The Fool）',
    normalMeaning: '自由、冒険、無限の可能性',
    reverseMeaning: '無計画、不安定、軽率',
  },
  {
    id: 1,
    name: '魔術師（The Magician）',
    normalMeaning: '創造力、チャンス、行動力',
    reverseMeaning: '詐欺、自己中心、実力不足',
  },
]
```

# 次やること
2 .	**その中からランダムに1枚選ぶロジックを書く**


# 参考

https://terupro.net/typescript-types-object-array/

https://zired.net/category/%E5%8D%A0%E8%A1%93/%E3%82%BF%E3%83%AD%E3%83%83%E3%83%88%E5%8D%A0%E3%81%84/tarot-cards/
【Rails】FactoryBot(Gem)について

# 記事概要
Ruby on RailsのFactoryBot(Gem)について、まとめる

# 前提
- Ruby on Railsでアプリケーションを作成している

# FactoryBotとは
インスタンスをまとめることができるGem

他のファイルであらかじめ各クラスのインスタンスに定める値を設定しておき、各テストコードで使用する

# Gemのインストール手順
https://qiita.com/likapantrip/items/d7317b9ece36b58dffd6#手順

# Gemfileの記述
https://qiita.com/likapantrip/items/c8718db9a4e72b7c6ad0#factorybot

# 手順(設定)
1. インスタンスの生成を切り出すファイルを作成する
    - FactoryBot導入前に、テストコードを記述するファイルを生成
        1. `spec`配下に、`factories`フォルダを手動作成
        1. `factories`フォルダに、`[モデル名の複数形].rb`を手動作成
    - FactoryBot導入後に、テストコードを記述するファイルを生成
        - `spec/factories/[モデル名の複数形].rb`が自動生成される
1. 上記で作成したファイルを編集
    - [Faker](https://qiita.com/likapantrip/items/d258599656ba4a248423)を使い、ランダム値を入力
        ```spec/factories/users.rb
        FactoryBot.define do
          factory :user do
            nickname              {Faker::Name.initials(number: 2)}
            email                 {Faker::Internet.email}
            password              {Faker::Internet.password(min_length: 6)}
            # password_confirmationはpasswordと同じ値なので、「password」を指定
            password_confirmation {password}
          end
        end
        ```
    - 固定値を入力
        ```spec/factories/users.rb
        FactoryBot.define do
          factory :user do
            nickname              {'test'}
            email                 {'test@example'}
            password              {'000000'}
            # password_confirmationはpasswordと同じ値なので、「password」を指定
            password_confirmation {password}
          end
        end
        ```

# まとめ
## ダミーデータに画像を添付
テスト用ダミー画像`public/images/test_image.png`をインスタンスに付与する

```messages.rb
FactoryBot.define do
  factory :message do
    content {Faker::Lorem.sentence}

    after(:build) do |message|
      # io: File.openで設定したパスのファイル(public/images/test_image.png)を、test_image.pngというファイル名で保存
      message.image.attach(io: File.open('public/images/test_image.png'), filename: 'test_image.png')
    end
  end
end
```

### インスタンスに画像が添付できているかを確認する方法
1. コンソールを起動する
    ```
    % rails c
    ```
1. 画像が保存できているか確認する
    ```ruby
    [1] pry(main)> message = FactoryBot.create(:message)
    #=> 省略
    [2] pry(main)> message.image.attached?
    => true
    ```

# Ruby on Railsまとめ
https://qiita.com/likapantrip/items/46b43c9d1309b6633f0a
【NocoBase 小ネタ】クレデンシャルを保存する方法と使う方法

## はじめに
NocoBaseを使っていると、**クレデンシャルを使いたい** と思うことはありませんか？  

そこで今回は、**クレデンシャルを保存する方法と使う方法**を紹介します！  

## 設定手順

### 1. クレデンシャルの保存
1. `設定` > `Variables and secrets` へ移動
2. `追加` > `Add variable`
3. クレデンシャルを保存
    - **名称**: 概要など
    - **タイプ**: `Plain text` or `Encrypted`
        - Plain text: DBに平文で保存
        - Encrypted: DBに暗号化されて保存
    - **値**: クレデンシャル

こんな感じで保存されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1160967/434bb7a8-53f6-4ad8-aba3-c9fc9e46dec6.png)
👇DB
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1160967/487bdca0-cc9e-4feb-87b6-52d089ef5ff7.png)


### 2. 使用方法
ワークフローなどでAPIを呼び出す際に平文を打たなくても変数として呼び出すことが可能です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1160967/35fe395c-eb86-4895-b19b-b93aeeec2401.png)


**NocoBaseを使った業務アプリでは、この方法でクレデンシャルの安全な利用が実現できます！**  


## まとめ
今回は、**クレデンシャルを保存する方法と使う方法** を紹介しました。  

良いNocoBaseライフを！ 🚀
Bicep Tips - Bicep事始め3（App Serviceの環境変数）

# 概要
[前回](https://qiita.com/yossihard/items/29ada69d293ac45fd8c5)の続き。
前回、Bicepでリソースグループの作成と、リソースグループの中にApp Serviceを作成するところまでできました。
今回は、App Serviceの環境変数の設定についてチャレンジしてみたいと思います。

# 環境
・MacBook Air
・Power Shell
・Azure PowerShell
・Visual Studio Code

# やりたいこと
①App Serviceを常時接続ONにしておきたいと思います。

②App ServiceでホストするWebアプリは、基本的に日本国内の事業者向けSaaSが多いので、
あらかじめタイムゾーン設定をしておきたいと思います。

App Serviceのタイムゾーンの設定は、環境変数にWEBSITE_TIME_ZONEを設定します。
変数に設定する値は、下記の記事を参照。
[App Service Tips - タイムゾーンの設定](https://qiita.com/yossihard/items/67c80489457967c28db7)
→自分が書いた記事、もう5年も前なのね・・・

# 手順
どちらも、App Serviceの項目の「SiteConfig」の中に、プロパティ値を追加する必要があります。

### 常時接続ONの設定
alwaysOnプロパティをtrueで設定します。
```
alwaysOn: true
```

### 環境変数の設定（今回はタイムゾーン設定）
appSettingsプロパティを設定します。
このプロパティの値は、nameとvalueの組み合わせを配列のように記述するようです。

```
      appSettings: [
        {
          name: 'WEBSITE_TIME_ZONE'
          value: 'Asia/Tokyo'
        }
      ]
```

前回作成したappservice.bicepは、最終的に以下のようになります。

```
param webAppName string // Generate unique String for web app name
param sku string = 'B1' // The SKU of App Service Plan
param linuxFxVersion string = 'DOTNETCORE|8.0' // The runtime stack of web app
param location string = resourceGroup().location // Location for all resources
var appServicePlanName = toLower('AppServicePlan-${webAppName}')
var webSiteName = toLower('${webAppName}')

resource appServicePlan 'Microsoft.Web/serverfarms@2020-06-01' = {
  name: appServicePlanName
  location: location
  properties: {
    reserved: true
  }
  sku: {
    name: sku
  }
  kind: 'linux'
}

resource appService 'Microsoft.Web/sites@2020-06-01' = {
  name: webSiteName
  location: location
  properties: {
    serverFarmId: appServicePlan.id
    siteConfig: {
      linuxFxVersion: linuxFxVersion
      alwaysOn: true
      appSettings: [
        {
          name: 'WEBSITE_TIME_ZONE'
          value: 'Asia/Tokyo'
        }
      ]
    }
  }
}
```

# 実行結果
前回と同じように、Azure PowerShellで以下のコマンドを実行します。
※カレントディレクトリの移動およびAzureとの接続が完了している前提。

```
New-AzSubscriptionDeployment -location japanwest -TemplateFile main.bicep -resourceGroupName demoResourceGroup -resourceGroupLocation japanwest -webAppName HapikuroTestWebApp
```

生成されたApp Serviceの構成と環境変数をポータル上で確認します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/146789/f326ab7b-ab0b-446e-ab6d-abc36a1efb05.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/146789/6a8d5043-495b-4e8a-8c3f-369585757c14.png)

ちゃんと設定されることが確認できました。
GitHub Copilot を VSCode で使い始める即効ガイド Java／JavaScript

## 1. セットアップ（所要 5 分）

1. **VS Code を最新版に更新**  
2. サイドバー **拡張機能ビュー** → `GitHub Copilot` を検索→ **インストール**  
3. 右下の ✈ アイコン → **「Copilot を設定」** → GitHub でサインイン  
4. ステータスバーに **`Copilot: Enabled`** が出れば準備完了  
   - *設定 → `Editor › Inline Suggest: Enabled` を **オン** にすると提案が常時表示されます。*

---
## 2. インライン補完の基本操作

| アクション             | キー／操作                   | 覚え方                 |
|------------------------|-----------------------------|------------------------|
| 提案を挿入             | **Tab**                     | 受け入れる             |
| 提案を無視             | **Esc**                     | 取り消す               |
| 次／前の候補           | **Alt + ］ / Alt + ［**     | 別案をめくる           |
| 手動で提案を呼び出す   | **Alt + \\**<br>(JP 配列は **Alt + ¥**) | Copilot にお願い       |

> **手動トリガーとは？**  
> 自動でゴーストテキストが出ないときに **Alt + \\** を押すと、その行の文脈を送信して *即座に* 提案を生成します。  
> 「今すぐアイデアちょうだい！」という場面で便利です。

---



コメントを書いてから関数名だけ入力

Copilot が本体を灰色のゴースト文字で表示

Tab で受け入れ → 完成！

---

## 3. コメント駆動のコード生成
やりたいことを日本語コメントで宣言
```
// ユーザーIDからプロフィールを取得し、存在しなければ例外を投げるメソッドを書いて
```
**Enter** で改行 → 1 秒待つと提案が出現

**Tab** で受け入れ／Alt + ］ で別案を選択

細かい条件を足すほど精度アップ。アルゴリズム名（例：二分探索）、性能制約（例：O(n) 以下）なども一緒に書くと効果的です。

## 4. Copilot Chat（質問窓口）

**開き方**

`Ctrl + I`（macOS は ⌘I）

もしくはサイドバーの吹き出しアイコン

**質問例**

「このクラスの責務を 1 行でまとめて」

「選択範囲に Javadoc を付けて」

「NullPointerException の原因と修正案を教えて」

チャット回答にある `💡Apply`ボタンは「提案コードをエディタに挿入（同意）」の意味。クリック前にプレビューで差分を確認できます。

## 5. 具体的ベストプラクティス

| コツ              | そのまま使える具体例                              |
| --------------- | --------------------------------------- |
| **1 文で目的を宣言**   | `// CSV を読み込み、ヘッダーをスキップして合計を求める`        |
| **制約を明示**       | `// 10 MB 超のファイルでもメモリ使用量を最小化する`         |
| **戻り値／例外を指定**   | `// 見つからなければ Optional.empty() を返す`      |
| **テストを自動生成**    | Chat: `このメソッドの JUnit5 パラメータライズドテストを作って` |
| **コンテキストを渡す**   | ① クラス全体を選択 → ② Chat: `リファクタしやすい形に整理して`  |
| **段階生成** | 大枠の実装 → TODO コメント → 手動トリガー              |
| **必ず検証**        | 生成後は **テスト実行 & 差分レビュー**                 |
【GitHub】dependabot.ymlのreviewersをCODEOWNERSに変更する


## `reviewers`の廃止

`dependabot.yml`の`reviewers`は2025年5月20日火曜日に廃止されます。

https://github.blog/changelog/2025-04-29-dependabot-reviewers-configuration-option-being-replaced-by-code-owners/

そのため、代わりに`CODEOWNERS`ファイルを作成する必要があります。

## `CODEOWNERS`ファイルの作成方法

`.github`フォルダ内に`CODEOWNERS`ファイルを作成します。
`CODEOWNERS`ファイルにパスと`@ユーザー名`を記述するとコードオーナーを設定でき、プルリクエストをオープンすると、自動的にレビューがリクエストされるようになります。

```:CODEOWNERS
*       @owner-name
```

https://docs.github.com/ja/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners#about-code-owners
続:プリザンターのパンくずリストにちょっと機能追加

## はじめに
[前回紹介したパンくずリストの拡張](https://qiita.com/pmc-ko/items/073b74c851d9ce0cce6a)ですが、編集画面から前回開いていた表示モードにそのまま戻りたいケースもあるかもという声をいただきましたので、ちょっと拡張してみました。

## 実装してみた
前回の拡張サーバスクリプトをちょっと拡張します。設定のJSONや拡張スタイルには変更はありません。

```js
(function() {
    var navItems = [{
        action: "Index",
        icon: "view_list"
    }, {
        action: "Calendar",
        icon: "calendar_month"
    }, {
        action: "Crosstab",
        icon: "table"
    }, {
        action: "Gantt",
        icon: "view_timeline"
    }, {
        action: "BurnDown",
        icon: "timeline"
    }, {
        action: "TimeSeries",
        icon: "area_chart"
    }, {
        action: "Analy",
        icon: "clock_loader_40"
    }, {
        action: "Kamban",
        icon: "pivot_table_chart"
    }, {
        action: "ImageLib",
        icon: "photo_library"
    }];
    
    if (context.Action === "edit" && context.UrlReferrer) {
        var protocol = "https";//実環境に合わせた情報を入力
        var host = "<Host Name or IP Address>";//実環境に合わせた情報を入力
        var rootPath = `${protocol}://${host}${context.ApplicationPath}`;
        if (context.UrlReferrer.startsWith(rootPath)) {
            var path = context.UrlReferrer.replace(rootPath, "").split("?")[0].split("/");
            if (path.length === 3) {
                if (path[0] === "items" && path[1] === `${context.SiteId}` && navItems.map((x) => x.action.toLowerCase()).includes(path[2])) {
                    var content = `<a href="${context.ApplicationPath}items/${context.SiteId}/${path[2]}" id="BreadcrumbMenu_HistoryBack"><span class="material-symbols-outlined">arrow_back</span></a>`;
                    var target = `:root:has(#Action[value="edit"]) #Breadcrumb:not(:has(#BreadcrumbMenu_HistoryBack)) .item:last-child`;
                    context.AddResponse('Append', target, content);
                }
            }
        }
    }

    navItems.forEach(navItem => {
        var content = `<a href="${context.ApplicationPath}items/${context.SiteId}/${navItem.action.toLowerCase()}" id="BreadcrumbMenu_${navItem.action}"><span class="material-symbols-outlined">${navItem.icon}</span></a>`;
        var target = `:root:not(:has(#Action[value="${navItem.action.toLowerCase()}"])):has(#ViewModelMenu_${navItem.action}) #Breadcrumb:not(:has(#BreadcrumbMenu_${navItem.action})) .item:last-child`;
        context.AddResponse('Append', target, content);
    });
}());
```

編集画面の場合は、`context.UrlReferrer`から前回表示していたページのURLを取得し、それがプリザンターのURLでなおかつ編集画面でない時はURLを組み立ててリンクを生成します。

これを実際に表示してみるとこうなります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3555395/ff958cc1-026e-4d62-a462-7b68d3eb7b5e.png)

一番左の右矢印が同じ表示モードに戻るアイコンになります。
外部サイトからの遷移や編集画面などの表示モードを持たないページからの遷移の場合は、このように矢印は表示されません。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3555395/1064be95-a569-4824-a230-816cc8fe66ed.png)

## まとめ
今回は、パンくずリストをさらに拡張する方法を紹介しました。前回表示モードにそのまま戻りたいときには便利に使えるモードなので是非試してみてください。
[AWS #42] AWS Snow ファミリー

<!--
 <font color="c00000"></font> 赤
-->
## はじめに
皆様お疲れ様です。:computer:
今回はAWSの移行分野にある<font color="c00000">**「AWS Snow 〇〇」**</font>について見ていきたいと思います。


## AWS Snow ファミリーメンバー
AWS Snow ファミリーとは、 <font color="c00000">**物理デバイスの集まり**</font>を指します。これは、エクサバイトまでのデータを**AWSの内外に物理的に転送するのに役立ちます。**

:rolling_eyes: ファミリーということは1人、１つではなさそうですね。
:upside_down: AWS Snow ファミリーには **「AWS Snowcone」「AWS Snowball」「AWS Snowmobile」** が含まれます。どんなものか見ていきましょう。

### AWS Snowcone
小型かつ頑丈で安全性に優れたエッジコンピューティング、データ転送デバイスです。
2つのCPU、4GBメモリ、**最大14TBの使用可能なストレージが搭載**されています。
![AWS_Snowcone.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3806875/150e902c-7dcd-4553-a80e-1e475e44d7f8.jpeg)

### AWS Snowball
**使用可能なストレージ量 ➡ 80TB**
Snowballには以下2種類のデバイスが搭載されています。

**・Snowball Edge Storage Optimized**
このデバイスは、**大規模なデータ移行と定期的な転送のワークフロー**や、大容量を必要とするローカルコンピューティングに適しています。

**・Snowball Edge Compute Optimized**
このデバイスでは、機械学習、フルモーション動画分析、分析、ローカルコンピューティングスタックなどの**ユースケースに強力なコンピューティングリソースを提供**します。
![SnowballEdgeAppliance.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3806875/13711a37-d043-4f1c-b0ad-f2a62e218d99.png)

### AWS Snowmobile
Snowmobileでは、**大容量のデータをAWSに移行するために使用できるエクサバイト規模のデータ転送サービス**になります。以下の画像のようにセミトレーラートラックが牽引する長さ約14mの丈夫なコンテナです。Snowmobile1台あたり最大100PB（ペタバイト）のデータを転送できます。
![l_yu_aws5.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3806875/de5e9e01-d20f-4495-8e5e-4bb8e7bdade0.jpeg)

## おわりに
今回のちょっとしたまとめになります。

:::note info
AWS Snow ファミリーは<font color="c00000">**物理的にデータを輸送します**</font>
:::

最後までお読みいただきありがとうございました！
>>**日頃より活用している参考書です。**
>> **「参考書」**
[**AWS認定クラウドプラクティショナー改定第3版（AWS Snow ファミリーは363ページ）**](https://x.gd/19i6N)
>

> **「AWS公式サイト」**
[**AWS Snowball**](https://aws.amazon.com/jp/snowball/)

> **「Youtube」**
[**【期間限定公開：AWSクラウドプラクティショナー】第24回 ストレージサービス(EFS・Storage Gateway・Snowball) (クラウドテクノロジーとサービス分野)**](https://www.youtube.com/watch?v=J52ZUvqDEYo)
>
Windowsが起動しなくなった話

# Windows修復記＃１

## あらすじ
>いつも通り起きてPCを起動したところ、なにやらHTTP(s)Bootに飛ばされるではないか、おなじみのGRUB君は何処へ...
Wi-Fiにつないだ後IPアドレスを取得しますとかなんとか
failの後にめっちゃでかいピープ音鳴らしてきてびっくり。怖いのでやめてください。
生きてそうなubuntuを起動したら、同じくHTTP(s)Bootに飛び...

ノートPCの**Windowsが起動できなくなった**(起動時の選択肢から消えた)ので、備忘録として書く。
情報系の大学生(笑)のためPCには全く詳しくない。必死に調べつつ解決を目指した。
## 原因考察
原因はおそらくubuntuをデュアルブートしていることが関わっている。最近ubuntuがぶっ壊れたりして、直すためにパーティションを弄ったりしていたのだが、ubuntuが毎回起動しなくなっていた(よくわかんない画面に飛ばされる)。直して起動->使い終わって切る->次の起動時また壊れ...のループ。
他に関係がありそうなのは、最近ファンがすぐにでかい音を立てるようになったことだろうか。ほこりはたまっていなかったので、何か負荷がかかっていたのだろう（？）

## 対応録
### 原因調査
とりあえずBIOSを眺めると、Windows boot managerがバッバイしていた。さようなら、Windows___。

ー閑話休題ー

SSDがnan。SSD自体が壊れたの？それとも接続が悪い？
どうしましょう。
                    　・
                    　・
                    　・
SSDがなぜか復活し、ubuntuが起動可能に。
これは激アツ(もちろんWindowsはない)。

### Windows発見
ターミナルで調べる調べる。
どうやらSSD関連の致命的なエラーはないようだ(`dmeseg`で調べた)。

`lsblk`で何かないか探す。ここで希望が見えた。
830GBほどのパーティションが...！！！**これはWindowsのCドライブでは？？？？**

...つまりboot managerが死んだだけで、**Windowsのデータは生きている！**...はず。

さて確認まうんと。
```
sudo mount -o ro (Cドライブらしきディレクトリ名) /mnt/win
```
なんかfailした。`umount`してもっかい。まうんと成功。
~~金欠なので~~どのくらいの量か見てバックアップ用のUSBメモリを買いたい。
```
du -sh /mnt/win/Users
```
あ、フリーズした。重かったみたい。

諦めて128GB(一部バックアップ用)と32GB(Windows修復用)の2本を買いに走った。8~16GBでいいのに何で32GB？~~近所の家電量販店の品揃えが悪くて~~安い16GBがなかった。

USBメモリを使ったことがない人間なので使い方がよくわからない。
調べる(ChatGPT)
```
sudo mkdir /mnt/usb
sudo mount (USBの) /mnt/usb
```
本当にこれですか...？
あ、なんかUSBメモリは自動的にmountされてたぽい。無駄な行為。

いったんcpする前に中身を見ていこう。128Gに入るかわからんからね。容量確認せずにcpするようじゃダメか。容量はね、確認しとかないと。
...さて
```
ls /mnt/win/
```
あらたくさん。program filesやら何やらと、見覚えのあるフォルダが。もう少しkwsk
```
ls /mnt/win/Users/(ユーザー名)
```
を見ますわよ。
Onedriveあった。見れるかな？unsupportedだって。どういう意味かわからんけど、クラウドにしかなくて、ubuntuからはなんか見られないのだと勝手に解釈。

忘れてたけどサブノートpc同じOnedriveにしてたから、生きてるか確認できるわ。

...見れた。どのファイル共有切ってたか忘れたな。そいつらは元気でやってるかな。
~~某ゲームのデータが生きててよかった~~
とにかく、だいたいの大学関連は生きてる。安心。

### バックアップをとろう
はやいらしいので`cp`ではなく`rsync`を使用。`-av`オプションをつけることで、アーカイブモードでコピーしつつ、詳細表示をしてくれる。Onedriveは大丈夫だし、(ユーザー名)以下のそれ以外を移す。
```
rsync -av --exclude='OneDrive' /mnt/win/Users/(ユーザー名)/ /(USBの)
```
他のデータはあとで考える。
>###### Windows修復用USBメモリの作成
>...さて、この間にWindows修復用のUSBメモリを用意しよう。
[公式サイト](https://www.microsoft.com/ja-jp/software-download/windows11)でWindows11をダウンロード。USBメモリに突っ込む。これだけ。

バックアップは終わりが見えない。
...遅すぎね？`df -h`で確認
```
117G  9.7G  107G   9% /(USBメモリの)
831G  297G  535G  36% /mnt/win
```
1h以上やってるけど、いま終わってるの9.7GB分だけらしい。詳しくないので基準がわからない。
ちなみに数時間後の自分から一言　「今もっと進みが遅い。」
>バックアップ用の外付けSSDを買おうと思う。

（閑話休題）なぜかわからんがバックアップ作成中のターミナルのタブが消えた。まうんと云々で怒られ、とりあえず`cp`に変えてみる。
```
cp -anv /mnt/win/Users/(ユーザー名)/. /(USBの)
```
これでおわってくれ（切実）。

しばらく1GB進むのも牛歩のようにおそかったが、ついに一気に進み始めた。
おそらく、細かいファイルが多かったため、時間はかかるのに量は少なかったのだと考察。ubuntu環境でWindowsのデータを移しているのもでかそう（データ形式的に）。

### 終わらないバックアップ
終わらない。もう10hほどUSBに書き込んでいる気がする。ついに修復作業2日目に突入した。

vscodeの拡張機能とかgradleとか、あとはAndroid studioのSDKがファイルめっちゃ細かくて時間を食っていたので、`exclude`して再開。
除外していいかわからなかったが、最悪なくなっても構わないので速度を優先。
>ちなみにここまでで70GBほどしか書きこめていない。`df -h`や`du -sh`を何度使ったことか。その進捗のなさに涙していた。

AppDataがガチで細かいファイルが多すぎて時間を奪う。キャッシュとかが多いのかな。

進展があったら＃２を書く。
完全イベント駆動型セキュリティトリガー（C# + .NET + ETW）

今回は個人開発で遊んだプロジェクト「SilentGuard」の紹介です。  
**完全イベント駆動型の軽量セキュリティトリガーモジュール**で、ファイル操作の瞬間だけ反応します。

---

## 🔹 開発のきっかけ

きっかけはとても単純で、

> 「2種類のスキャンエンジンでダブルチェックできたら、面白くない？」

という思いつきからスタートしました。  
セキュリティの専門教育を受けたことはありませんが、構造として可能では？と思って試作を始めました。

---

## 🔹 SilentGuardとは？

**SilentGuardは「ファイル生成・変更・削除」などのシステムイベントをトリガーとしてのみ動作するモジュール**です。  
常時監視はせず、「必要な瞬間だけ」反応するため、非常に軽量かつ高速です。

### 🔧 使用技術・特徴

| 項目 | 内容 |
|------|------|
| 言語 | C#  
| ライブラリ | .NET標準 + ETW（外部OSSゼロ）  
| CPU使用率 | 0%〜0.1%  
| メモリ使用量 | アイドル時：5MB台  
| ファイルサイズ | `.cs`単体：約13KB ／ ビルド後 `.exe`：約144KB  
| コード量 | 約350行（改行含む）  

---

## 🔹 仕組みと構造

SilentGuardは、**WindowsのETW（Event Tracing for Windows）** を利用してファイルイベントをフックし、以下のように動作します。

### ⚙️ 処理の流れ

1. ファイルの作成・変更・削除をリアルタイムで検知  
2. 検知時のみ、指定されたスキャンエンジン（例：`MpCmdRun.exe`）を強制実行  
3. スキャン終了後、即アイドル状態に戻る  
4. 「脅威あり」の場合：  
  - 該当プロセスを終了  
  - ファイルを隔離  
  - **別エンジンで再スキャン**  
  - 必要であれば削除 → ログ保存まで自動処理  

> 設定ファイル（`Config.json`）にスキャンエンジンのパスを2つ指定するだけで、任意の組み合わせが利用可能です。

---

## 🔹 スキャンエンジンについて

本モジュール自体は**スキャンエンジンを自作しておらず、外部の既存エンジンを呼び出す設計**です。  
今回はテスト用として **Windows Defender** を使用しましたが、ClamAVやESET、任意のCLIベースのスキャナにも適用可能です。

---

## 🔹 おわりに

このモジュールは構造的にはほぼ完成しており、今後はスケーラブルな形で**引き継ぎ・譲渡**を検討しています。  
これからｈ、教育AIなどに注力していく予定です。

### 🔄 今後の展開可能性

- OEM提供向けモジュール化  
- SaaS型の法人向け軽量EDR  
- 既存AVソフトとのバンドル構成  

---

ご興味のある方は、ぜひコメント欄や[LinkedIn](https://www.linkedin.com/in/yusuke-utsumi-08b7a6322/)からご連絡ください。  
デモ動画や技術構成の詳細も共有可能です！
WebDecode Easy Web picoCTF

# 問題文からわかること
- Web Inspectorなるものを利用すること
    - Web InspectorはF12ブラウザ開発者ツールのこと

# サイトからわかること
- トップページには何もなさそう。Keep Navigatingとあるからナビゲーション部から他のページを見てみよう
- Aboutページに'Try inspecting the page!! You might find it there'とあり、このページにフラグがありそう
- HTMLソースにpicoCTF{で検索をかけるもヒットしない。
- notify_true属性のcGljb0NURnt3ZWJfc3VjYzNzc2Z1bGx5X2QzYzBkZWRfMWY4MzI2MTV9が不自然で怪しそう

# 解答
CyberChefで定番のBASE64デコードしてみる
```
cGljb0NURnt3ZWJfc3VjYzNzc2Z1bGx5X2QzYzBkZWRfMWY4MzI2MTV9
```
```
picoCTF{web_succ3ssfully_d3c0ded_1f832615}
```

F12開発者ツール使ってみようということが言いたいのでしょうか？
この問題の作者は。意図が読めない。
LangMemで製造現場をスマート化する  


---


### ― 作業者や工程の傾向を記憶し、最適化と再発防止を実現 ―  

---

## 【はじめに】

製造業の現場では、作業者のミス傾向や工程条件のばらつきにより、生産性と品質に大きな差が生まれます。  
これらを**「記憶」**し、経験を再利用できれば、最適化と再発防止が可能になると考えました。

LangChainが開発した長期記憶ライブラリ **LangMem** を用いることで、製造業の知見を「人」や「工程」単位で構造化し、現場の個別支援やインシデント対応を行う「SmartMem Factory」システムを提案しました。

---

## 【SmartMem Factoryの主要機能】

### 作業者支援
- LangMemで「ミスが多い作業項目」「頻出エラー」を記憶  
- LLMが実行前に注意点をプロンプト生成

### 工程最適化
- 機械設定、環境条件と一緒に、不良率や給付ラベルを記録  
- 「低不良率」の記録と「高不良率」の記録から、LLMが最適条件を推定

### クレーム対応・再発防止
- 「ロット番号」「不良現象」「対応内容」を「エピソード記憶」としてLangMemに保存  
- 類似現象発生時に、「過去の対応チェック」を表示

---

## 【コード例】

### 1. 作業者支援

```python
from langmem import create_memory_manager
from pydantic import BaseModel

class WorkerProfile(BaseModel):
    worker_id: str
    error_prone_tasks: list[str]

manager = create_memory_manager(model="openai:gpt-4o-mini", schemas=[WorkerProfile])

# ミス記録
log = {"role": "user", "content": "Aさん、部品Xでネジ編続を忘れた"}
manager.invoke({"messages": [log]})

# 次回、引き出し
next_task = {"role": "user", "content": "Aさん、部品Xの組立開始"}
print(manager.invoke({"messages": [next_task]}))
```

---

2. 工程最適化
```python
from langmem import create_memory_store_manager

manager = create_memory_store_manager(model="openai:gpt-4o-mini", namespace=("process",))

# 成功ロットを記憶
manager.invoke({"messages": [{"role": "user", "content": "温度200℃ 圧力50kPa 不良率0.5%"}]})

# 現在の情報を先に依る設定推定
print("推奨: 200℃、50kPa に設定変更")
```

---

3. クレーム再発防止
```python
# 過去のクレーム記憶
claim = "2025/4/12 ロット#992 ひび割れ: 原因は冷却不足"
manager.invoke({"messages": [{"role": "user", "content": claim}], "namespace": ("claim",)})

# 類似発生時
print("提案: 同様事例あり。冷却時間延長で解決済")
```

---

【実用プロセス】

1. PoC: タブレットのミニアプリで記憶系を実装


2. MES/SCADA統合: 製造結果やセンサー情報をアクティブに記録


3. LLM分析: 過去記録と現在値を比較して推定


4. UI返信: 作業者UI/MESに推奨指示




---

【おわりに】

SmartMem Factoryは、LangMemの構造化記憶とLLM推論力を駆使して「人」や「工程」の知見を再利用可能にする新しい現場最適化プラットフォームです。

「記憶」する現場、「忘れない知見」をベースに、生産性や品質を自動的に向上させるシステムいかがでしょうか？現実味ありますかね？


---

## 参考リンク
- [LangMem公式ドキュメント](https://langchain-ai.github.io/langmem/)
- [LangGraph公式リポジトリ](https://github.com/langchain-ai/langgraph)


---
Create React App 非推奨に伴う、Vite + React + TypeScript + TailwindCSS + Zustand + React Router 開発環境構築ガイド

ViteでReact + TypeScriptのプロジェクトを新規作成し、Tailwind CSS、状態管理（例：Zustand）、ルーティング（React Router）を導入して、開発できる状態にするまでの手順を**具体的なコマンドと説明付き**でまとめます。

---

## 🔧 前提条件

* Node.js（v16以上）インストール済み
* パッケージマネージャー（npm または yarn または pnpm）

---

pnpm を使う場合：

```bash
pnpm create vite my-app -- --template react-ts
```

✅ `my-app` は任意のプロジェクト名です。

---

## 2. プロジェクトに移動

```bash
cd my-app
```

---

## 3. 依存関係インストール

```bash
npm install
```

---

## 4. Tailwind CSS セットアップ

### Tailwind の依存関係を追加

```bash
npm install -D tailwindcss postcss autoprefixer
npx tailwindcss init -p
```

### `tailwind.config.js` を編集

```js
// tailwind.config.js
export default {
  content: [
    "./index.html",
    "./src/**/*.{js,ts,jsx,tsx}",
  ],
  theme: {
    extend: {},
  },
  plugins: [],
}
```

### `src/index.css` に以下を追加（既存ファイルに追加する）

```css
@tailwind base;
@tailwind components;
@tailwind utilities;
```

### `main.tsx` で CSS をインポート

```tsx
import './index.css'
```

---

## 5. React Router（ルーティング）を導入

```bash
npm install react-router-dom
```

#### 使用例（`App.tsx` にて）:

```tsx
import { BrowserRouter, Routes, Route } from "react-router-dom";
import Home from "./pages/Home";
import About from "./pages/About";

function App() {
  return (
    <BrowserRouter>
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/about" element={<About />} />
      </Routes>
    </BrowserRouter>
  );
}

export default App;
```

---

## 6. Zustand（状態管理）を導入

```bash
npm install zustand
```

#### 使用例（`store.ts`）

```ts
import { create } from 'zustand'

interface CounterState {
  count: number
  increment: () => void
}

export const useCounterStore = create<CounterState>((set) => ({
  count: 0,
  increment: () => set((state) => ({ count: state.count + 1 })),
}))
```

---

## 7. 開発サーバー起動

```bash
npm run dev
```

---

## ✅ ディレクトリ構成（例）

```
my-app/
├─ src/
│  ├─ components/
│  ├─ pages/
│  ├─ store/
│  ├─ App.tsx
│  ├─ main.tsx
│  └─ index.css
├─ tailwind.config.js
├─ vite.config.ts
```

---

これで、**Vite + React + TypeScript + TailwindCSS + Zustand + React Router** の開発環境が整います。
どの状態管理ライブラリを使うかは好みによりますが、Zustand は軽量かつ直感的で初心者にも扱いやすいです。
【Rails】📝 本日のRails学習まとめ

# 📝 本日のRails学習まとめ
本日もRailsについて学習を行いました。
昨日のアプリ再実装を経てRailsの基本理念やMVCについてさらに細かく学習しました。

## ✅ RailsにおけるDRY（Don't Repeat Yourself）
DRY原則とは？
同じコード・処理を繰り返さず、一か所にまとめて再利用性を高める設計原則です。Railsではこの考え方が強く反映されています。
| 活用例         | 使うもの                | 目的                   |
| ----------- | ------------------- | -------------------- |
| ビューの共通化     | `partial`（部分テンプレート） | 同じHTMLを複数ページで使いまわす   |
| コントローラの共通処理 | `before_action`     | 重複した処理を1か所にまとめる      |
| 複雑な処理の切り出し  | サービスクラス・ヘルパー・モジュール  | 処理を分離して見通しよく再利用可能にする |

## 📦 クラスとモジュールの使い分け
| 目的            | 使うもの            | なぜ？                |
| ------------- | --------------- | ------------------ |
| 「もの・実体」を作りたい  | クラス（`class`）    | インスタンスを作れるから       |
| 「機能・処理」をまとめたい | モジュール（`module`） | 他のクラスに機能として使い回せるから |
| 名前の衝突を避けたい    | モジュールの中にクラス     | グループ名で名前を整理できるから   |

### 💬 たとえ話で理解する：

クラス = たこ焼き器（たこ焼き＝実体を焼く）

モジュール = たこ焼きソース（あとから追加できる便利な味付け）

## 🧰 Helper・モジュール・サービスクラスの使い分け
| 用途      | 特徴                                      |
| ------- | --------------------------------------- |
| ヘルパー    | ビュー専用。テンプレート内で使う簡単なメソッド（例：日付の整形など）      |
| モジュール   | 複数クラス間で共通の処理をまとめる。`include`や`extend`で導入 |
| サービスクラス | ビジネスロジック（複雑な処理）をモデルやコントローラから分離          |

## 🖼️ JSONとレンダリング
render json: @user のように、Railsでは簡単にJSON形式のデータ出力が可能。

非同期通信でよく使われる。

JSONはデータの受け渡しに最適な軽量フォーマット。

## 🔐 セッションとクッキー
| 用語             | 説明                               |
| -------------- | -------------------------------- |
| セッション（session） | 一時的なデータ保存（サーバーサイド管理）。ログイン情報など    |
| クッキー（cookie）   | ブラウザ側に保存される小さなデータ。次回アクセス時にも利用できる |

セッションの例としてはショッピングサイトならどこでも実装している「買い物かご」がこれにあたる。
クッキーには行動履歴などが含まれていて、クッキーの情報からウェブサイトの広告を表示したりすることもある。

## 🧠 ORMとSQLの違い
| 用語                | 説明                                                  |
| ----------------- | --------------------------------------------------- |
| ORM（ActiveRecord） | RubyコードでDB操作ができる。SQLを直接書かなくてもOK。例：`User.find(1)`    |
| SQL               | データベースと直接やり取りする言語。Railsでも必要に応じて書ける（`find_by_sql`など） |

🗂️ SQLの3種類（+1）
| 分類 | 略語  | 目的             | 例                            |
| -- | --- | -------------- | ---------------------------- |
| 定義 | DDL | テーブルやカラムを作成・削除 | `CREATE`, `DROP`, `ALTER`    |
| 操作 | DML | データの挿入・更新・削除   | `INSERT`, `UPDATE`, `DELETE` |
| 制御 | DCL | アクセス権の制御       | `GRANT`, `REVOKE`            |
| 取得 | DQL | データの検索         | `SELECT`（厳密にはDMLに含めないことも）    |

## 🔍 find_by_sqlとは？

ActiveRecordのメソッドで、生のSQLを実行できる。

例：
```
Tweet.find_by_sql("SELECT * FROM tweets WHERE text LIKE '%Rails%'")
```
## 🔚 まとめ
RailsはDRY原則に基づいた構造化を目指すフレームワーク。

ヘルパー、モジュール、サービスクラスなどを適切に使い分けることで、見通しが良く保守しやすいコードになる。

ORMを使えばSQLを直接書かなくても基本操作ができるが、SQLの基礎知識も重要！
データアナリストからジェネレーティブAIエンジニアまで｜5つのキャリアパス比較


近年、データとAIの活用があらゆる業界で加速しています。これに伴い、データ分析や機械学習関連の職種への関心も高まっています。しかし、「データアナリスト」と「データサイエンティスト」や、「MLエンジニア」と「GenAIエンジニア」の違いは意外と分かりにくいもの。

この記事では、以下の5つの職種について、それぞれの役割、必要なスキル、主なツールを比較・解説します。

* データアナリスト
* データサイエンティスト
* ビジネスアナリスト
* ML（機械学習）エンジニア
* GenAI（生成AI）エンジニア

---

## 1. データアナリスト：既存データから意思決定を支援

**役割：**
組織が保有する既存のデータをもとに、傾向やパターンを可視化し、意思決定をサポートする職種です。

**主なスキル：**

* SQL
* Excel
* 統計基礎
* データ可視化
* Python（補助的に使用）

**使用ツール例：**
SQL, Excel, Tableau

---

## 2. データサイエンティスト：予測・分析モデルを構築

**役割：**
統計モデルや機械学習を用いて、将来の予測や高度なデータ分析を行います。

**主なスキル：**

* Python / R
* 機械学習アルゴリズム
* 統計・確率
* データ前処理（ワンリング）
* 特徴量エンジニアリング
* データ可視化

**使用ツール例：**
Python, Excel, Tableau

---

## 3. ビジネスアナリスト：業務改善と要件定義のプロ

**役割：**
ビジネス課題を特定し、改善のための要件定義や提案を行う橋渡し的な存在です。エンジニアとの連携も多い職種です。

**主なスキル：**

* ビジネスプロセスモデリング
* コミュニケーション力
* 要件定義スキル
* データ分析
* 問題解決スキル
* 基本的なSQLとExcel

**使用ツール例：**
Microsoft Office（Excel, PowerPoint など）

---

## 4. MLエンジニア：機械学習システムの設計と運用

**役割：**
スケーラブルかつ信頼性の高い機械学習システムを構築・運用するエンジニアリング寄りの職種です。

**主なスキル：**

* 機械学習の実装と最適化
* データエンジニアリング（ETL、パイプライン構築）
* Python / Java / SQL
* ビッグデータ処理
* ソフトウェアエンジニアリング

**使用ツール例：**
Spark, Hadoop, Airflowなど

---

## 5. GenAIエンジニア：生成AIを活用したアプリケーション開発

**役割：**
ChatGPTや画像生成モデルのような生成AIを活用し、アプリケーションや業務支援ツールを開発する最新の職種です。

**主なスキル：**

* Python（Transformers, PyTorch, TensorFlow など）
* HuggingFace、LangChainなどの生成AIフレームワーク
* プロンプト設計
* LLM（大規模言語モデル）への理解

**使用ツール例：**
LangChain, HuggingFace, LLAMAs など

---

## まとめ：キャリア設計のヒント

| 職種          | 分析寄り | 開発寄り | ビジネス寄り |
| ----------- | ---- | ---- | ------ |
| データアナリスト    | ◎    | △    | △      |
| データサイエンティスト | ◎    | ◯    | △      |
| ビジネスアナリスト   | △    | △    | ◎      |
| MLエンジニア     | ◯    | ◎    | △      |
| GenAIエンジニア  | △    | ◎    | △      |

自分の興味や得意分野、将来のキャリア目標に応じて、どの職種がフィットするかを検討してみましょう。
Cookie Monster Secret Recipe Easy Web

# 問題文からわかること
- Cookie見たらわかる

# F12ブラウザ開発者ツールからわかること
適当にログインフォームに入力し、ログイン試行するとCookieがいくつか格納される
`secret_recipe`がキーのCookieが怪しそう。
CyberChefで定番のBASE64デコードしてフラグ獲得

# 解答
```base64.デコード前
cGljb0NURntjMDBrMWVfbTBuc3Rlcl9sMHZlc19jMDBraWVzX0FDOEZDRDc1fQ%3D%3D
```
```base64.デコード後
picoCTF{c00k1e_m0nster_l0ves_c00kies_AC8FCD75}
ÃÜ
```

ログイン後、Cookieの情報でユーザ認証を行うので、Cookieが漏洩するのは非常にマズい。
そのため、属性をCookieのKeyごとに設定できる。
JavaScriptからアクセスできないようにするHttpOnly属性や、TLS通信のときだけCookieを送信するSecure属性などが設定できます。
しかし、今回のサイトでは何れも属性が付いていないので、怪しいブラウザ拡張機能からセッション情報を抜き取られたり、XSS攻撃をしやすくなるみたいです。
ブレッドボードのジャンパーワイヤー差込口が小さくて電圧・電流測定が出来ない場合の対処法

下記画像の通り、ブレッドボードのジャンパーワイヤー差込口が小さく、テストリードが奥の金属部分まで刺さり切らずに下記画像の通り電圧・電流測定が出来ない場合があると思います。

![PXL_20250506_132528830.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3827595/9e2903d9-48a6-457c-b0f1-7a28edc6de89.jpeg)

![PXL_20250506_132532541.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3827595/b2bea78c-7991-4028-a76e-ab1ec37e3e24.jpeg)


その際はジャンパーワイヤーをブレッドボードの差込口に刺して、ジャンパーワイヤー経由で電圧・電流測定を実施することが出来ます。
今回は参考としてオスメスのジャンパーワイヤーを使います。

![PXL_20250506_133819252.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3827595/ed24c16d-9151-4e66-ac95-ea21c1677955.jpeg)

その場合、下記の通り問題なく電圧・電流測定を実施することが出来ます。

![PXL_20250506_135028984.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3827595/5df2546c-f3e8-4e14-82da-ecb79a07220a.jpeg)


![PXL_20250506_132805145.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3827595/d785b0dc-f467-47b0-bbde-485cafbb923f.jpeg)

ジャンパーワイヤ(オス-メス)はより線が曲がってブレッドボードに刺さらない際の対処としても活用することが出来ます。


![PXL_20250506_140146203.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3827595/19899156-30e5-4d57-ae1b-b0a2a730cbf2.jpeg)
@Previewで使えるプロパティ一覧

# `@Preview` で使えるプロパティ一覧（Jetpack Compose）

Jetpack Compose の UI を Android Studio のプレビューで確認するための `@Preview` アノテーションに指定できるパラメータ一覧です。

## 基本設定

| プロパティ | 説明 | 使用例 |
|------------|------|--------|
| `name` | プレビューの名前 | `@Preview(name = "My Preview")` |
| `group` | プレビューのグループ名 | `@Preview(group = "MyGroup")` |
| `showBackground` | 背景を表示するか | `@Preview(showBackground = true)` |
| `backgroundColor` | 背景色（ARGB） | `@Preview(backgroundColor = 0xFF00FF00)` |
| `widthDp` | 幅（dp） | `@Preview(widthDp = 320)` |
| `heightDp` | 高さ（dp）| `@Preview(heightDp = 480)` |

## 表示モード・UI関連

| プロパティ | 説明 | 使用例 |
|------------|------|--------|
| `showSystemUi` | ステータスバーやナビゲーションバーを表示 | `@Preview(showSystemUi = true)` |
| `showDecoration` | システムUIや背景などの装飾を表示 | `@Preview(showDecoration = true)` |
| `wallpaper` | 壁紙を表示 | `@Preview(wallpaper = "red")` |
| `fontScale` | フォントスケール（倍率） | `@Preview(fontScale = 1.5f)` |

## デバイス・環境設定

| プロパティ | 説明 | 使用例 |
|------------|------|--------|
| `device` | 使用するデバイス | `@Preview(device = Devices.PIXEL_4)` |
| `hardware` | ハードウェア構成  | `@Preview(hardware = "pixel_4")` |
| `apiLevel` | Android API レベル | `@Preview(apiLevel = 30)` |
| `uiMode` | UIモード（ライト/ダーク）| `@Preview(uiMode = Configuration.UI_MODE_NIGHT_YES)` |
| `locale` | ロケール（言語・地域） | `@Preview(locale = "ja")` |

### よく使う定数

#### `device` の例
- `Devices.DEFAULT`
- `Devices.PHONE`
- `Devices.TABLET`
- `Devices.PIXEL_4`
- `Devices.PIXEL_C`
- `Devices.WEAR_OS_SMALL_ROUND`
- `Devices.WEAR_OS_LARGE_ROUND`

#### `uiMode` の例
- `Configuration.UI_MODE_NIGHT_NO`（ライトモード）
- `Configuration.UI_MODE_NIGHT_YES`（ダークモード）


## 使用例（複数設定）

```kotlin
@Preview(
    name = "Dark Mode - Pixel 4 - Japanese",
    showBackground = true,
    backgroundColor = 0xFF121212,
    uiMode = Configuration.UI_MODE_NIGHT_YES,
    device = Devices.PIXEL_4,
    locale = "ja",
    fontScale = 1.2f
)
@Composable
fun MyPreview() {
    MyComposable()
}
```
Copilotと一緒にChrome拡張を作ってみた！

## 成果物
[super-simple-video-speed-controller](https://github.com/litswd0211/super-simple-video-speed-controller)

## プロジェクト概要
動画の再生速度を簡単に調整できるChrome拡張を作ってみました！名前は「Video Pace Master Lite」。YouTubeやAmazon Prime Videoで動作するシンプルな拡張機能です。開発にはGitHub Copilotをフル活用して、効率的かつ楽しく進めました。

## Copilotを活用した開発の流れ
開発の初期段階では、Copilotに頼りっぱなしでした（笑）。例えば、`D` キーと `S` キーで動画の再生速度を調整するロジックは、Copilotが提案してくれたものをそのまま使いました。トースト通知のデザインや位置調整も、Copilotのサポートでサクッと実現。

## 動画速度調整機能の実装
動画の再生速度を調整するために、`content.js` にキーボードイベントリスナーを追加しました。この部分のコードはCopilotが提案してくれたもので、ほぼそのまま採用。さらに、現在の速度をトースト通知で表示する機能も、Copilotの提案を基に実装しました。

## Amazon Prime Video対応
Amazon Prime Videoのような動的に生成される動画要素に対応するため、`MutationObserver` を導入しました。このアイデアもCopilotが提案してくれたもので、シャドウDOM内の動画要素を検出するロジックを簡単に実装できました。

## トースト通知の改善
トースト通知の位置変更やタイムアウト設定の調整も、Copilotの提案を活用しました。特に、スクリーンショット撮影時に通知が消えないようにする一時的な変更は、Copilotが迅速に対応してくれました。

## Chromeウェブストア対応
Chromeウェブストアのポリシーに準拠するため、`manifest.json` の権限を最適化しました。Copilotは、`<all_urls>` を削除して `host_permissions` を使用する提案をしてくれたため、スムーズに修正を進めることができました。

## リリース準備
リリースに向けて、アイコンやスクリーンショットの生成、ZIPファイルの作成手順を整備しました。Copilotは、`sips` コマンドを使った画像リサイズのスクリプトを提案してくれたため、効率的に作業を進めることができました。

## Copilotと開発する楽しさ
今回のプロジェクトを通じて、Copilotと一緒に開発する楽しさを実感しました。コードの提案だけでなく、修正や最適化のアドバイスも的確で、まるでペアプログラミングをしているような感覚でした。特に、反復的な作業や複雑なロジックの実装で大いに助けられました。

## まとめ
シンプルで軽量なChrome拡張を作るのは、思った以上に楽しい体験でした！Copilotのおかげで、開発のスピードも上がり、学びも多かったです。これからもCopilotを活用して、いろんなプロジェクトに挑戦していきたいと思います。

---

*この記事はAI（GitHub Copilot）を活用して作成されました。内容の正確性には注意を払っていますが、必要に応じてご自身で確認をお願いします。*
Cephやるためにネットワーク環境の見直し

前回デス

https://qiita.com/shimeji_k/items/33a551f1b7da209e844f

## Cephの検証をしたけど
ネットワーク環境をしっかりと見つめ直さないといけない事象が発生。

問題ないと思っていたのに
高負荷かけまくっていたら
corosync？がコケてクラスターのいくつがにアクセスできなくなる！！！
という事象が発生。

Proxmox/Cephをやるにはどのくらいのネットワークポートが必要なのかとか
速度が必要なのかがおぼろげながら見えてきた。


各サーバーでポート分けておいたほうがいいもがみえたもの
- Proxmox管理画面/SSH（1Gbpsで十分？）
    - いわずもがな管理画面とProxmox本体にアクセスするネットワーク
- ProxmoxVM用（1Gbpsで十分？）
    - ProxmoxのVMと外でアクセスできるネットワーク（セキュリティ的にも大事そう）
- ProxmoxCluster用（corosync）（1Gbpsで十分？できれば10Gbpsほしい）
    - Proxmoxでクラスタを組む場合クラスタはやっぱり独立したネットワークにしたほうが良さげ
- CephPublic（10Gbpsほしい）
    - Cephへのアクセスはちゃんとネットワークわけないと他にも影響がでる。ので別ネットワークに
- CephCluster（10Gbpsほしい）
    - クラスタを組む場合は絶対別ネットワークにしたほうがよさげ？な印象

ということは、最低でも1サーバーで5本のネットワークポートが無いと厳しい？
L3で区切っても帯域がたりなくなりそうということ。

## 個人だと機材に限りがあるのでなんとか考案をしないと
今足りないもの
ネットワークカード
ハブ（L3まではいらないけどポートVLANできると嬉しい）
後スピードを重視しないといけないポートを限定するしかない

買ったもの
中古だけど
DELL S4048-on
https://www.delltechnologies.com/asset/en-us/products/networking/technical-support/dell-networking-s4048-on-spec-sheet.pdf

Mellanox ConnectX-3 Pro
参考リンクがみつからぬぃ

DACケーブル2本
あとLCケーブルOM3 16本くらい

最低限の帯域でいけるところは妥協して

| デバイス        | ネットワーク |  コメント                     |
| ----------- | ------- | ------- | 
| HP DL360 Gen9 | 1Gbps-T 4ポート SFP+ 4ポート       | 何も追加しなくてOK  |
| HP DL380 Gen10 | 1Gbps-T 4ポート SFP+ 2ポート       | DL360から拝借したSFP+を追加したけど足りないのでもう2ポートSFP+追加します |
| 2028TP-DC1R Node1 | 1Gbps-T 2ポート | 拡張スロット足りない！のでMellanox ConnectX-3 Pro追加予定        |
| 2028TP-DC1R Node2 | 1Gbps-T 2ポート | 拡張スロット足りない！のでMellanox ConnectX-3 Pro追加予定        |

個人でCeph勉強したり構築してみたりはお金かかりますね

そして家庭内ネットワークの見直し
===============

これだったのを
![第一弾-第二弾のProxmox化.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4067323/8e72b631-5365-4bc0-8a3d-615f5bd10fb2.png)

こうしてみたい！！！とある機材だけを並べて検討
![ceph_proxmox_Network.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4067323/953958a0-c9ec-4f18-b82b-4330a26f242a.jpeg)

どうしても夢がでてきてしまって今ない機材のノードまで入ってしまっているのは御愛嬌
L3スイッチ無いからYAMAHAのRTX1200が活躍しそうです

GW中で注文した機材が全く届かないから
構想の妄想が捗る捗る

できるんかな？？？

続いたらしい

https://qiita.com/shimeji_k/items/f373baa926ac904b681f
Unityのタイトルバーにプロジェクトのディレクトリを表示する


# Unityの設定
Edit <sub>(Mac版 Settings)</sub> > Preferences を開く。
__Use Project Path in Window Title__　のチェックボックスにチェックを入れる。


![スクショ1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3116386/da4702d0-c035-4a75-b06f-7b6776b87ae7.png)

__Bofore__
![{D5C60A16-C5EC-46B4-869B-878B99A7E60D}.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3116386/4fc160ce-dfc7-4d43-bcfb-e2b88fbd4287.png)

__After__
![{AEC2DBF2-5EA6-4CE3-B3C5-D1D88D91F4B2}.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3116386/1319eb36-1b22-43e4-8db9-fad7352be4c2.png)
なんでViteを使うの？Webpackと何が違うのか調べてみた

# Viteとは？
Vite(ヴィート)とは2020年にリリースされた割と新しいビルドツールで、フロントエンドのために作られたというだけあって幅広いフレームワークをサポートしています。

Viteはリリースされて以降年々シェアを広げており、[State of JavaScript 2024](https://2024.stateofjs.com/ja-JP)におけるビルドツール部門ではViteの利用率がWebpackに差し迫っています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3518485/3086762b-b3e2-40e1-97a8-8c0ebc24b579.png)

今回はなぜViteが使われるのか、今まで覇権を握っていたWebpackと比較してみました。
## WebpackにはないViteのメリット
### 開発が速い
これがViteを使う一番の理由だと思います。
開発が速いというのが具体的にどういうことかというと、
* 開発サーバー起動時のコールドスタートにかかる時間が短い
* 変更の反映にリロードが必要ない
* 変更反映時に変更ファイル以外の状態を保持する HMR (Hot Module Replacement) 機能がある
* ビルドに必要な環境がデフォルトで揃っているため、Webpackに比べて設定が簡単

などが挙げられます。

## なんで速いの？
### バンドル処理の違い
Viteの開発環境では、```node_modules/```内の静的なモジュールに対して事前にバンドル処理を行い、単一のファイルとして出力します。

この点まではWebpackと同じです。

しかし、```src/```内など動的なモジュールに対しては ESM (ECMA Script Modules) を使いトランスパイルのみ行うことでバンドル処理を不要にしています。

この**動的モジュールに対するバンドル処理の有無**がWebpackとの最大の違いです。
Webpackはファイルの変更に対して再度バンドル処理が必要なため、処理速度に大きな違いが出ます。

静的モジュールにもESM使えばいいんじゃねと思う方もいるかもしれませんが(自分は思いました)、HTTPリクエストを削減するために変更が少ないファイルはまとめておこうという考えみたいです。

また、動的モジュールに変更があった際にはファイル単位でブラウザに読み込ませることでHMRを実現しています。

### デフォルトのバンドラ(トランスパイラ)の違い
Viteはデフォルトでバンドラにesbuildを採用しています。

Go言語で開発されたesbuildはネイティブコードとしてコンパイルされマルチスレッドにも対応しているため、JavaScriptで開発されたBabelに比べて10 ~ 100倍ほどの速度を誇ります。
(Rustで書かれたswcはさらに速く、Viteがこれに対応したためプロジェクト作成時にswcを選択することが可能です)

WebpackはデフォルトでバンドラにBabelを使用していますが、プラグインでesbuildやswcに変更することも可能です。
しかし、設定が複雑になったり置き換えが完全ではなかったりするためViteに比べると劣る印象です。

### 設定が簡単
TypeScriptのトランスパイルなど、Webpackのリリース後に登場した現在では必須級の機能がViteには組み込まれているため、開発までのステップが短くなるという点では速いと言えるのではないでしょうか。

## それでもWebpackを使うメリット
* 拡張性が高く、長く使われているためプラグインも豊富(ViteはRollupベースのプラグインをサポートしているので、Viteのプラグインが少ないわけではない)
* 古いブラウザで開発できる(ESMが2015年に実装されたため、デフォルトの設定だとViteはそれ以前のブラウザで開発ができない)

## 最後に
今回はViteについてWebpackと比較しながら調査してみました。

総合的な所感としてはWebpackじゃないとこれが実現できない！ってことがなさそう(自分が調べた限りは)だったので、悩んだ場合はとりあえずVite使っておけばいいかなと思いました。
head-dump picoCTF Easy Web

# 問題文からわかること
- サーバーのメモリを保持するファイルを生成するエンドポイントを見つけること
    - これにフラグが存在
- APIドキュメントに関する記事がブログ内に存在

# ブログ記事見てみる
右上の記事の#API DocumentationのリンクからAPIドキュメントに飛べる。
パスは`/api-docs/`

このドキュメントの/heapdumpからアヤシさプンプンです。
Try it outボタンを押すと、curlコマンドを表示してくれるので、実行して`picoCTF{`でgrepしてフラグ獲得です。

# 解答
```bash
curl -X 'GET' 'http://verbal-sleep.picoctf.net:XXXXX/heapdump' -H 'accept: */*' | grep picoCTF{
```
picoCTF{Pat!3nt_15_Th3_K3y_439bb394}

実際は、このようなAPIを公開するときは認証機能が必要でしょう。
PC起動時に自動でVSCode + WSLを立ち上げる方法（スタートアップ登録）

# はじめに

最近、プログラミングの機会が増えてきて、PCを起動するたびに

- VSCodeを開く  
- WSLに接続する

という操作を繰り返すのが面倒になってきました。

そこで、**PCを起動したら自動で VSCode + WSL を立ち上げる**ように設定したので、その方法を共有します。  
今回は **Ubuntu（WSL）を使っている場合**の例です。

## 手順

### 1. スタートアップフォルダを開く

1. `Win + R` を押して、「ファイル名を指定して実行」ダイアログを開きます。
2. 以下を入力して「OK」を押します：

```
shell:startup
```

> スタートアップフォルダが開きます。特に設定していなければ空のはずです。

---

### 2. VSCodeをWSL（Ubuntu）で起動するショートカットを作成

1. スタートアップフォルダ内で**右クリック → 新規作成 → ショートカット**を選びます。
2. 表示されたウィンドウに、以下のように入力します：

```
code --folder-uri "vscode-remote://wsl+Ubuntu/home/yourname"
```

※ `yourname` の部分は自分のユーザー名に置き換えてください。

3. 「次へ」を押し、ショートカットに任意の名前を付けて「完了」を押します。

---

### 3. 完了！

これで設定完了です。  
PCを再起動すると、VSCodeが自動的に立ち上がり、その時点でWSL（Ubuntu）にも接続された状態になっているはずです。
Terraformで意図しないAWSアカウントへのデプロイを防ぐ！自己チェックコードの紹介

## 問題点
Terraformを使っていると、どの認証情報（クレデンシャル）で操作しているか不安になることありませんか？
私はもれなくあります。膝が震えちゃいますね。

特に複数のAWSアカウントを扱っていると、**意図しない環境に `plan` や `apply` してしまう**リスクが常に付きまといます。

そんな「うっかり事故」を防ぐために、Terraformコードに**自己チェックの仕組み**を組み込んでみましょう。

## 対策
次のコードを用意してみてください。

```terraform:check.tf

# 現在AWSにログインしているアカウントIDとリージョンを取得しています
data "aws_caller_identity" "check_deploy_account" {}

data "aws_region" "check_deploy_region" {}

# 利用したいAWSアカウントを設定
variable "deploy_account_id" {
  description = "The AWS account ID where the resources will be deployed."
  type        = string
  default = "123456789999"
}

locals {
  is_allowed_account = data.aws_caller_identity.check_deploy_account.account_id == var.deploy_account_id
}

# テストコードの代わりにnull_resource
resource "null_resource" "check_deploy_account" {
  lifecycle {
    precondition {
      condition = local.is_allowed_account
      error_message = "このTerraformコードは指定されたアカウント(${var.deploy_account_id})でのみ実行可能です。現在のアカウントは: ${data.aws_caller_identity.check_deploy_account.account_id}です。"
    }
  }
}
```

## 効果確認
これを指定外の認証情報がセットされた状態で`terraform plan`, `apply`すると、以下のエラーが発生します。

```terminal:terraform plan出力結果
│ Error: Resource precondition failed
│ 
│   on modules/network/check.tf line XX, in resource "null_resource" "check_deploy_account":
│   xx:       condition = local.is_allowed_account
│     ├────────────────
│     │ local.is_allowed_account is false
│ 
│ このTerraformコードは指定されたアカウント(123456789999)でのみ実行可能です。現在のアカウントは: XXXXXXXXXXXXです。
```

これでデプロイの向き先を確認することができますね。
都度確認するのも良いですが、仕組みで防ぐ方法も取り入れてみてはいかがでしょうか。

この記事がみなさんのエンジニアリングに貢献できれば幸いです。
最後までお読みいただき、ありがとうございました。
spring。java。utilクラスを作る場合

Springで java.util 的なユーティリティクラスを自作し、他のクラスで `@Inject`（または `@Autowired`）して使う場合、そのクラスに付けるべきアノテーションは主に以下の2つのどちらかです

## ① `@Component`

```java
@Component
public class MyUtil {
    // ユーティリティメソッドなど
}
```

一般的なSpring管理Beanとして登録。

他クラスで `@Inject`（または `@Autowired`） によりDI可能。

このクラスは明示的にSpringに管理させるので、DIの対象にできます。

### `@Service`（ビジネスロジック寄りの場合）

```java
@Service
public class MyUtil {
    // 複雑なロジックなど
}
```

実際には `@Component` と同じくBean登録されますが、意図の明確化として使われます。

ユーティリティクラスが何らかのビジネス処理を支えるものであれば `@Service` の方が読み手に分かりやすくなります。

DI（依存性注入）を使うと、テストコードを書くときに非常に有利

#### 例：Mockitoを使ったテスト
```java
@ExtendWith(MockitoExtension.class)
class SomeServiceTest {

    @InjectMocks
    SomeService someService;

    @Mock
    MyUtil myUtil; // DI対象のユーティリティクラス

    @Test
    void testSomething() {
        when(myUtil.someMethod()).thenReturn("mockedValue");

        String result = someService.doSomething();

        assertEquals("expected", result);
    }
}
```

### 補足

もしstaticメソッドのみを使う純粋なユーティリティクラスで、DIも不要であれば、アノテーションは不要で、Spring Beanとして管理する必要もありません。

ただし、staticメソッドだけだと、テストコードで以下のことが必要です。

- Mockito.mockStatic() のような少し特殊な書き方が必要になります。
- 依存関係を差し替えるのが難しいため、テストが面倒になりがちです。

### まとめ

- DIして使う → `@Component` または `@Service`

- staticメソッドだけ → アノテーション不要、DIしない

- ユーティリティクラスが何らかの外部依存（他のBeanや設定など）を持つ、または将来的にモック化してテストしたくなる可能性があるなら、DIを使ってSpring管理Beanにするのがおすすめです。

### interface（インタフェース）が必要なケース

- 実装を切り替えたい可能性がある
- ユーティリティが複雑で、契約（interface）を明確にしたい場合
- DIしてモックに差し替えやすくしたいとき

### interface（インタフェース）が不要なケース

- ユーティリティが完全にstaticなメソッドだけの場合
- 実装を切り替える可能性がない単純なユーティリティ
私が考える職人像と「リーダブルコード」の考え方

## 私が描く職人像について
私はシステムエンジニアが建築家と同じように商品を実際に形にしていく職業であるという点から職人であると考えています。
私自身が描く職人像とは
**「外見だけでなくお客様から見えない部分まで意識を向けることができる人」**
であると考えています。
最近の話となりますが、Youtubeにてある建築家の方の投稿で、フローリングの敷き詰め作業後の床と壁の接合部の軋みチェックを行う作業の様子を載せた動画を目にしました。具体的な作業としては、異音がする部分を切り離して音が鳴らないように微調整を行うといった内容ですが、家の住人がほとんど踏みしめることのなさそうな住居の角の柱とフローリングの間の接合部まで意識を向けてチェックをしているシーンがあげられていました。その時に、こういったぱっと見では気づかないような細かい配慮の積み重ねが住み心地のいい何年も住みたくなる家へと変わっていくのだと感じました。
それは、システム開発を行うエンジニアにおいても同じであると考えています。
## 見えない部分は意識を向ける必要性について
システムの開発における見えない部分とは＝ソースコードとなります。
ソースコードは見えない部分であることから「動けばいいや」といった気持ちになりやすいと感じています。
特に、納期に追われてくるとそういった感情になりやすく、私自身もそういった感情になることがありました。
エンドユーザの商品への評価は導入時よりも導入後数か月以上使用することで分かれてくる部分だと考えていますが、特に障害の発生数や障害からの回復までの時間が増大するほどエンジニアへ厳しい目線が向けられるようになりますし、評価も落ちていくことを２年間で経験しました。
今思えば、初めからソースコードを理解しやすくきれいなものに仕上げられていればテスト漏れによる障害の発生や、障害が発生した場合にもすぐ原因の究明へとつなげることができたと考えています。
これらの経験を受けて、**「見えない部分まで意識を向ける職人を目指すことが自分自身を救うことにもつながり、結果としてエンドユーザが長く愛用したくなるいいアプリケーションを生み出すことができるのではないか」** と気付くことができました。
## 「リーダブルコード」のすすめ
「コードは理解しやすくしなければならない」
この言葉が「リーダブルコード」の根幹となる考え方です。
その考え方に沿って、意識すべきポイントがわかりやすく紹介されている一冊となります。
特に、本記事の内容で述べたような見えない部分への意識をする上で、確認すべきポイントについて変数名などの細かい部分からコードの構造まで幅広くまとめられているため一度のみならず何度も読み返して確認したくなる内容となっています。
この記事では、本の詳細を載せることはしませんが、私自身のシステム開発への意識を変えるきっかけを与えてくれましたし、中身が伴ったいいモノづくりをするための指針となる本だと感じています。
ぜひ、手に取ってご確認いただけますといい刺激を受けることができると思います。
私自身、これからもコードを書く上で「リーダブルコード」を何度も見返しながらいいモノづくりができる職人に近づけるように日々精進してまいります。
ご覧いただきありがとうございました。

## 参考文献
* [「リーダブルコード」](https://www.amazon.co.jp/%E3%83%AA%E3%83%BC%E3%83%80%E3%83%96%E3%83%AB%E3%82%B3%E3%83%BC%E3%83%89-%E2%80%95%E3%82%88%E3%82%8A%E8%89%AF%E3%81%84%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E6%9B%B8%E3%81%8F%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B7%E3%83%B3%E3%83%97%E3%83%AB%E3%81%A7%E5%AE%9F%E8%B7%B5%E7%9A%84%E3%81%AA%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF-Theory-practice-Boswell/dp/4873115655/ref=sr_1_1?adgrpid=109464583422&dib=eyJ2IjoiMSJ9.keiD6zn06Yn-URBgWNEGc-Z4d4nKZaSedDCEUZXlM80x4XpOtzt_n9_GxfDdHhbO3IGmitwj2CF2QbDLc9y7Mtxw6l0e20JDAaoi9zQ9K3DeQoBOIS0vjNE--9jxUhzEVMGGkWlrP1ePuml2PdS4p68FSmTK8k2GeC4ll03H4DKcGl-c-Q7Xbzy0stJgv8bH6g8Xtsf6zrBsdNiSZyXwJokfwIde0uRH8uy3BQbCbYgFZGGiDBrGUCNKmLC9idiGTLPJRGJLfuAeZcMvZYuaeXgcblfD8KVsWEr23CztVE4.kBdgts2NwLOM_a26Nr4Dk5z0MlpZNY9GWWSoaqM9UK8&dib_tag=se&hvadid=651850192226&hvdev=c&hvlocphy=1009050&hvnetw=g&hvqmt=e&hvrand=17516137645941099697&hvtargid=kwd-1015891532593&hydadcr=22883_13622374&jp-ad-ap=0&keywords=%E3%83%AA%E3%83%BC%E3%83%80%E3%83%96%E3%83%AB%E3%82%B3%E3%83%BC%E3%83%89&mcid=ca7d3935b7e5334fadd2a1f0d1097541&qid=1746536791&sr=8-1)
The Art of Readable Code by Dusitin Boswell and Trevor foucher.
Copyright 2012 Dustin Boswell and Trevor Foucher, 978-0-596-80229-5
【読書感想文】次の会議までに読んでおくように! ~モダンミーティング7つの原則を読んで

# はじめに

定例や会議などのファシリテーターを任されることが最近増えてきたのですが、ファシリや会議に向けての準備段取りがヘタクソすぎて何とか出来ねえかなと思い本書にたどり着きました。
本書の中で自分が特に覚えておきたいと思った部分について、記録に残します。

# 今回読んだ本

https://www.amazon.co.jp/dp/4799102095?ref=ppx_yo2ov_dt_b_fed_asin_title

# どんな本なの？

「モダンミーティング」という形式をもって会議を執り行い、
意思決定のスピードを加速させるための準備などについて書かれていました。

> 妥協しない、止まらない、先送りしない。
たかが会議とあなどってはいけません。
会議は、戦争が最終手段であるように、ビジネスにおける最終兵器なのです。

# 読んでみてどうだった？

冗長な部分もありましたが、得られた知見も多くありました。
冗長である分、必要最小限の部分、あるいはすぐ取り入れたり学べる部分を取捨選択して自分の中に落とし込むことで、より自身が主催する会議を「モダンミーティング」に近づけることができるのではないかと感じました。

具体的に学んだ部分については次の章で引用していきます。

# 自分が業務に役立てたいと思った言葉

> ## モダンミーティングは、書類を読まない組織では機能しない
>ミーティングは意思決定のために行われる。
一旦決まった意思決定は実行されるべきものだ。実行するための唯一の方法は、情報シェアのためのミーティングを一切行わないことだ。

> ブレインストーミングの目的は、恐れを断ち切り、想像力の目を自由にさまさせっることだ。
専門家も認めていることだが、ブレインストーミングを成功させる最大のポイントっは楽しく行うことで、評価したり批判したりすることが一切ない時間を作り出すことだ。
設定や、雰囲気、実施ルールなどが通常のミーティングとは違うことで、メンバーにはこの集まりが気の置けないもので、リスクのあるものではないことが分かる。

>実のところ、最初にやらなければならないことは。どのようにして意思決定するかを決めることです。まずは以下の質問を自問自答してみてください。

>* この事項に関して、一人で意思決定できるか？
>* グループで意思決定することが必要だとして、どのようにして、そしていつ、グループのメンバーにそれを知らせるか？
>* この意思決定は、直感的にできるか？あるいはしっかりとした分析が必要か？
>* ほかのメンバーの意見を聴くことが重要か、あるいはすでに十分に事実関係を知っているか？
>* ミーティングではなく、誰かと対話するだけで済まないか？
>* 意思決定するまでにどれくらいの時間が必要か？
>* 次のアクションプランはどうあるべきか？

# おわりに

会議において重要なのは会議を始める前のステークホルダー選定や意思決定するための段取り根回しをどれほど迅速にできるかが勝負であると感じました。
子の学びをぜひとも生かしていきたいと思います

# 参考文献

参考になるアジェンダのサンプル等が記載されているサイトです。

https://modernmeetingstandard.com/