OmniAICreator/Qiita-1.07M huggingface dataset:
【TCP通信】アプリ間のソケット通信をデバッグするためのSocketDebuggerを5分で導入する方法

# 1. はじめに
https://qiita.com/umezawa_udom/items/9515884a187f06427364

この記事を見て**SocketDebugger**を使ってみたい、でも導入方法がよくわからない…。
本記事では、そんな方向けに**SocketDebugger**の導入方法をご説明します。

まずは**無料**で試せる**試用版**をインストールしてお試し導入してみてください！

# 2. 試用版ライセンス準備
2-1. 以下のリンクから、製品ページの試用版キー取得のページにアクセスします。
https://www.udom.co.jp/sdg/buy/trial/form.html
<br>
2-2. 試用版キー取得ページで「お客様情報」を入力します。

::: note info
SocketDebuggerシリーズは様々なタイプの製品があり、それぞれ機能が異なりますが、今回はSocketDebugger Proを選択します。
:::

「個人情報の利用に関する規約」を一読し、「上記、個人情報の利用に関する規約に同意する」にチェックします。最後に「確認画面へ」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4093303/461515a7-78ed-42cf-819f-c7fb7e5ba017.png)

2-3. 入力内容を確認し、「送信」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4093303/500a99bf-8e1c-4a99-b540-eb296db36ce7.png)

2-4. 送信が完了すると、登録したメールアドレス宛に、以下のようなSocketDebugger試用版プロダクトキー発行完了メールが届きます。
これで試用版ライセンスの準備ができました！
>ユードム 太郎 様
>
>この度はSocketDebuggerシリーズの試用版プロダクトキーをお申込み頂き、誠に有難うございます。
>SocketDebuggerからライセンス認証を行ってください。
>
>なお、製品版と異なり一度試用したプロダクトキーは期間内であったとしても再利用することは出来ません。
>
>【入力情報】
>■製品：SerialDebugger Pro Version:2.04
>■お名前（漢字）：ユードム 太郎
>■お名前（フリガナ）：ユードム タロウ
>■会社・部署名（団体名）：株式会社ユードム
>■メールアドレス：example@example.co.jp
>
>【試用版用プロダクトキー】
> **ここにプロダクトキーが記載されます。** 


# 3. SocketDebuggerダウンロード
3-1. 以下のリンクから、製品ページの製品版／試用版のページにアクセスします。
https://www.udom.co.jp/sdg/download/product-trial.html
<br>
3-2. 製品版／試用版ページのSocketDebugger Proの「ダウンロード」をクリックします。

:::note info
準備したライセンスと同じタイプをダウンロードします。
:::

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4093303/3e557b41-7009-4377-8034-d29926e99283.png)

3-4. SocketDebuggerPro-vXXX.zipがダウンロードされるので、展開します。

:::note info
XXXはバージョンが入ります
:::

# 4. 起動とライセンス認証
4-1. 展開されたフォルダ内の「SocketDebugger.exe」を右クリックし「**管理者として実行**」します。

:::note warn
Microsoft Defender SmartScreen等による警告が出た場合は、気にせず実行してください！
:::

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4093303/824e5e94-db4c-4bb5-9aca-1746195134e2.png)

4-2. SocketDebuggerが起動します。ここでプロダクトキーを入力するために、「認証」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4093303/5e197cb0-70f9-4905-9f32-0698f3159e2e.png)

4-3. 試用版または製品版のプロダクトキーを入力し、「認証」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4093303/98da9cb9-609e-4ba7-bf59-7c60af411713.png)

4-4. 認証成功のダイアログとバージョン情報画面を終了するとSocketDebugger
を使用することができます！😄
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4093303/e978ce55-2839-4ebd-8405-c1a33b4b6f35.png)

# 5. まとめ
アプリケーション開発における通信確認の手間を大幅に削減できる**SocketDebugger**。
試用版なら**わずか5分で無料導入**できます！まずは一度試してみてください！

# 記事リンク
https://qiita.com/umezawa_udom/items/9515884a187f06427364

https://qiita.com/umezawa_udom/items/88afd06acb4cb4f1fb5a

# 株式会社ユードム
株式会社ユードムはITと人間力で社会に貢献します。

https://www.udom.co.jp/

SocketDebuggerのご購入はこちら（期間限定の試用版もあります）

https://www.udom.co.jp/sdg/index.html
【大嶋淑之・新潟県】映像制作で見つけた本質

最近、仕事中にふと気づいた大切なこと。それは、「映像制作は人の共感を形にする仕事だ」という本質でした。

映像制作の現場では、技術やスキルが優先される場面が多いです。カメラワーク、編集ソフトの使い方、音楽や効果音の選び方――どれも重要な要素です。しかし、それらがどれだけ完璧でも、映像を通じて伝えたい「心」が欠けていると、視聴者の心には響きません。この発見は、あるプロジェクトでの体験から来ています。

クライアント様からご依頼いただいた映像では、商品をただ紹介するだけではなく、その背景にある「ストーリー」を伝えることが求められました。当初、視覚的なインパクトを重視した編集を提案しましたが、何かが欠けていると感じました。そこで、商品の開発に携わった人々の思いや、そこに込められた願いを聞き出し、それを映像に盛り込みました。その結果、クライアント様はもちろん、視聴者からも感動の声が寄せられました。

この経験を通じて、映像制作の本質は「技術」だけではなく、「共感」だと再認識しました。人の思いや感情をしっかりと受け止め、それを映像として具現化すること。それが、私が映像制作をする上での原点であり、これからも大切にしていきたいことです。

これまで以上に、制作の過程でクライアント様や視聴者との「心の接点」を見つけ、その繋がりを大切にしたいと思っています。この気づきが、新しいチャレンジへの扉を開いてくれた気がしています。
【Bash】テキストデータやコマンドの標準出力を配列に格納する。

## 改行ごとに配列に格納する場合

```array.txt
aaa
bbb
ccc

```

```bash:array.sh
#!/bin/bash

function arrayEcho() {
    echo "aaa"
    echo "bbb"
    echo "ccc"
}

readarray -t array < array.txt
echo "${array[@]}"

readarray -t array < <(arrayEcho)
echo "${array[@]}"

```

`readarray`(mapfileの別名)は標準入力を改行コードを含んだ文字列に分割し、配列に格納するコマンドである。  
`-t`オプションで改行コードを削除するので普通の使い方では入れる。  
`<(arrayEcho)`でコマンドの標準出力を仮想デバイスに変換してファイルとして扱ってくれるものである。  

## スペース区切りの1行テキストや出力を配列に格納する場合

```array2.txt
aaa bbb ccc

```

```bash:array2.sh
#!/bin/bash

function arrayEcho() {
    echo aaa bbb ccc
}

read -ra array < array2.txt
echo "${array[@]}"

read -ra array < <(arrayEcho)
echo "${array[@]}"

```

`read`は標準入力から変数に代入するコマンドです。デフォルトでは改行まで格納します。  
`-a`オプションで標準入力を区切り文字IFSで分割して配列として変数に格納します。  
`-r`オプションでエスケープ文字を無効にします。  
`readarray`コマンドでもオプションを加えればできなくはないですが、スペースの区切り文字は１文字でないと難しいなどあつかいに注意が必要なので`read`にしました。
純粋関数って何？

## 定義
以下の2つの条件を満たす関数

１.同じ入力→「必ず」同じ出力を返す
２.副作用がない

## 純粋関数の例
```ts
function add(a, b) {
  return a + b;
}
```

## １.同じ入力→「必ず」同じ出力を返す
ここで言う、入力とは引数のことである。
下記のように、引数として2,3を渡せば「必ず」5が返ってくる。
これで１の条件はクリアだ。
```ts
const result = add(2,3)
console.log(result);
// 5
```


## ２.副作用がない
副作用とは、関数の外の状態を変更したり、外の状態に依存したりすることである。
では、純粋関数ではない例を見ながら以下の２つの意味について考えてみよう。
①関数の外の状態を変更する
②外の状態に依存する


## 純粋関数ではない例
```ts
let count = 0;

function increment() {
  count++;
  return count;
}
```

関数incrementは変数countをインクリメントしているが、countはincrementに渡ってきたものではなくて、incrementの外で定義されたものだ。
よって関数の外の状態を変更している。

また、countの値が、5であればincrementは6を返すし、9であれば10を返す。
つまり、関数の「外の状態」に依存している。
よって副作用があると言える。
【城間勝行】AIでコードレビューを劇的進化

コードレビューの時間が足りない、細かいミスが見落とされる…。こんな課題を抱えるエンジニアが多いのではないでしょうか。そこで、私が独自に実践しているのが「AIと人間がコラボするコードレビュー術」です。

具体的には、まずAIにコードをチェックさせます。ここで便利なのが、構文ミスや冗長な記述、スタイルガイドに沿っていない部分などを瞬時に洗い出してくれるAIツール。これで、いわゆる「表面的な問題」を効率的に処理できます。

しかし、AIだけに頼るのはNGです。なぜなら、コードの意図やビジネスロジックの整合性は、まだまだ人間の洞察が必要だからです。私はAIが作成したレビュー結果をもとに、コードの背景やプロジェクト全体の流れを考慮しながら、深い部分に踏み込んだレビューを行います。

さらに、AIの出力をチームで共有し、議論のスタートポイントとして活用します。こうすることで、全員がレビューの質を向上させ、時間短縮にもつながります。

この方法のメリットは、AIが単なる「便利な道具」ではなく、チームの一員として活躍できる点です。結果、プロジェクト全体がスムーズに進み、コードの品質も高まるという実感があります。

コードレビューに悩んでいる方、AIとのコラボをぜひ試してみてください。この新しいアプローチで、レビューが劇的に進化するかもしれません！
位置情報を扱うために利用する、AWS Location Serviceとは？？？～AWS100本ノック～31/100

# はじめに
みなさん、GoogleMap使ってますか？
自分の現在地をMapで見たり、目的値までの経路を確認したり、カーナビ代わりに使ったり、とても便利で生活にかかせないツールですよね:smile:

AWSでもMapや経路表示などを行うサービスがないかと思ったのですが、2021年に**AWS Location Service**というサービスがGAされていたようなので、こちらについて調べながら紹介していきます。

# AWS Location Serviceとは？
> 動的および静的マップ、場所検索とジオコード、ルートプランニング、デバイスの追跡とジオフェンシング機能など、地理空間データと位置機能をアプリケーションに追加できるマッピングサービスです。Amazon Location Service を使用すると、顧客データを保護し、コストを削減し、他の AWS サービスと簡単に統合できます。

一言で言うと、`マップと位置情報データをアプリケーションに簡単かつ安全に追加できるサービス`でしょうか？ :thinking: 

AWS Location Serviceは以下の5機能から構成されます。
- **Maps**
  - 静的/動的マップの提供できる
  - マップ上に位置情報を視覚化してインタラクティブマップをアプリケーションに追加できる
- **Places**
  - 検索機能をアプリケーションに追加できる
  - ジオコーディング/リバースジオコーディング機能をアプリケーションに追加できる
  - サジェスト機能をアプリケーションに追加できる
- **Routing**
  - 道路やライブトラフィック情報に基づいて、距離と移動時間を推定できる
  - 任意の2地点の移動時間、距離、ルートをアプリケーションに提供する機能を構築できる
  - 複数の目的地に移動する最も効率的なルートを計算できる
- **Geofencing**
  - ジオフェンスと呼ばれる定義された地理的境界を作成できる
  - ジオフェンスへ出入りした際に、検出・アクションを行う機能を、アプリケーションに提供できる
- **Trackers**
  - 追跡が有効なアプリケーションを実行しているデバイスの過去/現在の位置を取得できる
  - ジオフェンスとリンクさせて、デバイスから送信される位置情報をジオフェンスと照合して自動的に評価できる
  - 位置情報をジオフェンスへ保存/評価する前にフィルタリングすることで、コスト削減できる


# 料金
各機能それぞれの利用量に応じて料金が発生します。
詳細は[公式サイト](https://aws.amazon.com/jp/location/pricing/)をご確認ください。

- **Maps**：動的マップのマップタイル、静的マップ画像のリクエスト数
- **Places**：サジェスト、ジオコーディング、逆ジオコーディング、付近検索などのリクエスト数
- **Routing**：ルートの計算、ルートマトリックスの計算、位置補正などのリクエスト数
- **Geofencing**：ジオフェンスの作成/表示、ジオフェンスでの位置評価などのリクエスト数
- **Trackers**：位置情報の書き込みなどのりくえすｔ

# おわりに

今回は、AWSで位置情報を扱うために利用する`AWS Location Service`について簡単に紹介しました。
次回から、MapsやPlacesなどの機能について、実際に触りながら理解を深めていきたいと思います。
【保存版】エンジニアでも"それっぽくなる"モダンUIは余白で決まる【悪い例つき】

## はじめに

前回の記事「エンジニア向けデザイン入門」の第二弾を書きます。
(前回の記事はこちら)

https://qiita.com/mukai3/items/2f5379e783d6266119f8

今回のテーマは **余白（スペーシング）** です。
配色やフォントよりも、余白の取り方ひとつで "素人感" と "プロ感" が分かれます。

この記事では、エンジニアでも即実践できる「余白設計の型」をまとめます。
**さらに今回は「悪い例 → 良い例」で比較しながら具体化します。**

今回もコード例とデザインあるので、見てみてください。

https://codepen.io/mukai3/pen/raVmYeK

---

## 結論：迷ったら倍、迷ったら固定値

エンジニアは数値が好きです。なので原則化すると：

* パディング：16px or 24px
* セクション間：32px or 48px
* ヘッダー-本文間：64px
* カード内余白：24px
* フォーム項目間：16px

**"倍数原則" で揃えると破綻しません。**

---

## UIサンプル比較：悪い例 vs 良い例

### 【悪い例：素人感が出る余白】

* 全体に詰めすぎ
* 各セクションの間隔がバラバラ
* ボタンも内側ギチギチで余裕がない
* 文字とカードの枠が近すぎる

結果：**なんとなく窮屈でチープ感が出る**

### 【良い例：モダン感が出る余白】

* セクション間は常に32px以上
* カード内パディングは24px
* ボタンは上下16px・左右24pxのパディング
* フォーム項目は16px間隔で揃える

結果：**一気に整って見える。落ち着き・読みやすさ・安心感が出る。**

---

## よく使う"余白テンプレート"一覧

| UI要素      | 推奨余白            |
| --------- | --------------- |
| ボタン内パディング | 16px上下 / 24px左右 |
| カード内パディング | 24px            |
| セクション間隔   | 32px or 48px    |
| ヘッダーと本文の間 | 64px            |
| 入力フォーム項目間 | 16px            |

---

## 余白の裏技：CSS変数化しておく

```css
:root {
  --space-xs: 8px;
  --space-sm: 16px;
  --space-md: 24px;
  --space-lg: 32px;
  --space-xl: 48px;
}
```

この型で書き始めると、**プロっぽいUI設計が驚くほど楽になります。**

---

## 余白は「余白→中身の順」で設計せよ

初心者：まず中身を置く → 空いた隙間に余白を調整する

プロ：先に余白の骨格を決める → 中身をそのブロックに入れる

**設計順序が逆転すると一気にUIが整います。**

---

## おわりに

デザインは余白で8割決まる。
配色・フォントをいじる前に、まずは "間" を整える癖をつけるだけで、UIが一気に見違える。

そして今回紹介したように、余白設計では **「固定値（px or rem）」** が基本。

「%指定じゃダメなの？」って思う人もいるけど、実は **%指定の余白はブレやすくて不安定**。
親要素のサイズによって余白が変わるから、画面幅によって「急に窮屈」「妙にスカスカ」になりがち。

特にボタンやカード、フォーム周りでは**一貫性がある見た目**が重要で、そこに%を使うと破綻しやすい。
だからこそ、「16px / 24px / 32px / 48px…」のように**倍数ルールで固定しておくと崩れないUI**になる。

次回は「カードUI設計のコツ編」を書く予定です。
よければLGTM・ブックマークしてもらえると嬉しいです！
71歳の... ちょっと待って、時間（loop）よ止まれ！イベントドリブンにしたいんだ。

　**Arduino**スケッチで必須の「 **loop()** 」って、目的によっては使いづらいと感じたことないですか？　**VisualBasic**でプログラミングを始めた私は、最初結構戸惑いました。マイコンでもイベントドリブン的な作りをずっと考えてましたが、今回それらしくなってきたので投稿します。（すでにWEBからの操作ではそれが実質上出来てました。）

 ![tone_led.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3189926/1f498b8b-f039-4d4a-83f4-766ef4622fb8.jpeg)
（余計なものを一杯くっつけたままの写真で醜くて申し訳ありません。外すの面倒で...）
　カギは以前の投稿でも載せていることで、loop()内に

    while (Serial.available() == 0) { ; } 
    // 見かけ上、シリアルからの入力があるまで停止
    // 入力があったら、文字列を「line」で受け取る
    String line = Serial.readString();
を挿入することです。そして、受け取った「**line**」を分割しコマンドを取り出します。あとはそれに応じた動作を定義しておけば良いわけです。文字列分割には次のサイト記事を参考にさせていただきました。有難うございます。

 https://qiita.com/Kurogara/items/0e64588b3897de63350c
 
    例１．ある周波数の音を２秒間鳴らす -> "tone 440 4"
    例２．LEDを指定した明るさで１秒間光らせる -> "led 50 5"

　回路としては、使用する`Pin4`からの出力を、圧電ブザーやLEDと、必要な抵抗を接続して`GND`に落とします。

 `ArduinoIDE2.3.6`でのスケッチです。普通の`ESP32`で動作するはずです。
```c:

const int PWM_PIN = 4;

void setup() {
  Serial.begin(115200);
  Serial.println("\n\rSerial Console start...");

  ledcAttach(PWM_PIN, 24000, 8);
}

void loop() {
  Serial.println(">");
  while (Serial.available() == 0) { ; }
  String line = Serial.readString();
  line.trim();
  if (line.length() > 5 && line.substring(0, 4) == "tone") {
    int n = 2;  // "tone freq duration"
    String zs[n];
    int zi[n];
    bool flag = true;
    if (split(line.substring(5), ' ', zs, n) != n) flag = false;
    for (int i = 0; i < n; i++) {
      if (!(zi[i] = zs[i].toInt())) {
        flag = false;
        break;
      }
    }
    if (flag) {
      ledcWriteTone(PWM_PIN, zi[0]);  // freq
      delay(zi[1] * 500);             // duration
      ledcWriteTone(PWM_PIN, 0);
    }
  } else if (line.length() > 4 && line.substring(0, 3) == "led") {
    int n = 2;  // "led brightness duration"
    String zs[n];
    int zi[n];
    bool flag = true;
    if (split(line.substring(4), ' ', zs, n) != n) flag = false;
    for (int i = 0; i < n; i++) {
      if (!(zi[i] = zs[i].toInt())) {
        flag = false;
        break;
      }
    }
    if (flag) {
      analogWrite(PWM_PIN, zi[0]);
      delay(zi[1] * 200);
      analogWrite(PWM_PIN, 0);
    }
  } else {
    Serial.println("?");
  }
}

int split(String data, char delimiter, String* dst, int num) {
  int index = 0;
  int len = data.length();
  for (int i = 0; i < len; i++) {
    char tmp = data.charAt(i);
    if (tmp == delimiter) {
      index++;
      if (index > num - 1) return -1;
    } else {
      dst[index] += tmp;
    }
  }
  return index + 1;
}
```
　最後までご覧いただきありがとうございました。
廃止されたトレイルヘッドなど



# 2025/06

+ [Test with and Without Authentication Unit](https://trailhead.salesforce.com/trailblazer-community/feed/0D5KX00000TkEt2)



# 2025/05　Superbadges

+ Advanced Billing Specialist
+ Billing Specialist
+ Business Administration Specialist
+ CRM Analytics and Einstein Discovery Insights Specialist
+ Financial Services Cloud Specialist
+ Health Cloud Specialist
+ Lightning Experience Reports & Dashboards Specialist
+ Lightning Implementation Specialist
+ Service Cloud Specialist

https://trailhead.salesforce.com/en/help?article=The-Next-Evolution-of-Superbadges-FAQ
"API key not valid"との長い戦いの記録【英語学習アプリ開発#3】

# はじめに
こんにちは、とむです。個人開発中の英語学習アプリ『（仮）Re-Learn English』の開発進捗、第3回目です。
（前回の記事はこちら → [Gemini APIで英作文のAI添削機能を実装！しかしサーバーエラーが...【英語学習アプリ開発#2】](https://qiita.com/tama0931/items/402129a68dbdb6de67a0)）
前回、Gemini APIを呼び出す際に発生した 500 Internal Server Error との戦いを報告しましたが、本日、ついにこのエラーを解決し、AIによる英作文添削機能が完全に動作しました！
今回は、エラーの原因特定から解決に至るまでの、泥臭いデバッグの全記録です。同じようなAPI連携でハマっている方の助けになれば幸いです。
# エラーとの戦いの記録
まず、Next.jsを動かしているターミナルのログを確認しました。すると、ブラウザに表示されていた 500 Internal Server Error の裏で、もっと具体的なエラーが出ていました。
```
[400 Bad Request] API key not valid. Please pass a valid API key.
```

**「APIキーが無効です」**
という、これ以上なく明確なエラーメッセージです。原因はAPIキーそのものか、その渡し方にあると確信しました。
次に、「Next.jsのプログラムを通さずに、APIキー単体で通信が成功するのか？」を切り分けるために、cURLコマンドを使いました。
Google AI Studioでコードスニペットを取得し、それを参考にターミナルで以下を直接実行したところ...
```
curl -X POST -H "Content-Type: application/json" -d '{"contents":[{"role":"user","parts":[{"text":"日本の首都はどこですか？"}]}]}' "https://generativelanguage.googleapis.com/v1beta/models/gemini-1.5-flash:generateContent?key=YOUR-API-KEY"
```

なんと、成功しました。
この結果から、以下の2点が確定しました。
- APIキーは有効である。
- Google Cloudプロジェクトの設定（請求情報など）も問題ない。

つまり、エラーの原因は**「Next.jsの環境で、APIキーがバックエンドのコードに正しく渡っていない」**ことにある、と断定できました。
# 解決策：環境変数の扱い方を見直す
原因がNext.jsの環境変数の読み込みにあると分かったので、以下の修正を行いました。
環境変数名の変更: .env.local ファイルで、GOOGLE_API_KEY という名前を AUTH_GOOGLE_API_KEY に変更しました。これは、Next.jsの予約語などとの衝突を避けるためのおまじないのようなものです。
関数内でのキーのチェック: APIを呼び出す POST 関数の内部で、process.env.AUTH_GOOGLE_API_KEY を読み込むように修正しました。（当初、関数の外で読み込もうとして、returnが使えないという別のエラーに遭遇したのはご愛嬌です...）
```
export async function POST(req: NextRequest) {
// 関数の内部でAPIキーを読み込む！
const apiKey = process.env.AUTH_GOOGLE_API_KEY;
if (!apiKey) {
// もしキーが読み込めていなければ、ここでエラーを返す
return NextResponse.json({ error: "API key is not configured." }, { status: 500 });
}
const genAI = new GoogleGenerativeAI(apiKey);
// ...以降の処理
}
```

サーバーの再起動: 最後に、.env.local とコードの変更を反映させるため、開発サーバーを再起動。
この結果、ついに...！
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4109907/c2ec6fbb-c9cc-4f49-a6ba-2d47baff8104.png)

無事にAI先生からのフィードバックが返ってくるようになりました！
# 今回の学びと今後の展望
API連携のデバッグは、エラーの原因がどこにあるのか（フロントエンド、バックエンド、API提供側...）を一つずつ切り分けていく地道な作業なのだと痛感しました。特に、外部からの疎通確認は、問題の切り分けに非常に有効でした。
これでアプリのコア機能が動くようになったので、次回からは
より自然な添削を返すためのプロンプトチューニング
他の学習機能（文法クイズやスピーキング練習）の実装
学習成果を可視化するダッシュボードの作成
など、アプリをより魅力的にする機能開発に集中していきたいと思います。
# 終わりに
2回にわたるエラー報告にお付き合いいただき、ありがとうございました。エラーが解決した瞬間の達成感は、個人開発の醍醐味の一つですね。
この記事が、誰かのデバッグのヒントになれば嬉しいです。
それでは、また次回の進捗報告でお会いしましょう！
システム開発とSECIモデル──野中郁次郎の知識創造理論から考える開発プロセスの本質

## はじめに

システム開発において、「知識」の扱い方は非常に重要です。技術的なノウハウやプロジェクト運営の経験則、そして属人的な判断力、こうした知が、チームやプロジェクトを成功に導く鍵となります。

この「知識」を理論的に扱ったモデルとして有名なのが野中郁次郎氏の提唱する「SECIモデル」です。本記事では、SECIモデルをシステム開発プロセスに適用し、どのように知識が共有・拡張・形式化されていくかを、実際の現場視点で読み解いていきます。

## SECIモデルとは何か？

SECIモデルは、知識の創造プロセスを以下の4つのステップで説明します。

S	共同化（Socialization）	暗黙知 → 暗黙知（例：OJT、ペアプロ）
E	表出化（Externalization）	暗黙知 → 形式知（例：設計書、ドキュメント化）
C	連結化（Combination）	形式知 → 形式知（例：Wiki、設計標準、API設計）
I	内面化（Internalization）	形式知 → 暗黙知（例：経験学習、TDDの反復）

これらのステップがスパイラル的に循環することで、組織内の知識が拡張・深化していくとされています。

## システム開発現場におけるSECIモデルの具体例

## 1. 共同化：ペアプロ、コードレビューによる「経験の共有」
	•	新人エンジニアが先輩とペアプログラミングをする。
	•	Slackでの「なぜそう実装したのか」の口頭ベースのやり取り。
	•	言語化されていない設計判断の背景を観察・吸収。

これらは暗黙知同士の交換です。仕様書には書ききれない「開発の呼吸」がここで受け継がれます。

## 2. 表出化：設計意図の言語化とドキュメント化
	•	コードに込められた設計意図をConfluenceにまとめる。
	•	「なぜこうしたのか」の議論をNotionに記録。
	•	ペアプロ中に出たベストプラクティスをWiki化。

このステップは、暗黙知を明文化するフェーズ。個人の判断基準が、チームで再利用可能な知識に変わっていきます。

## 3. 連結化：形式知の整理と体系化
	•	各ドキュメントや標準仕様をAPIガイドラインに統合。
	•	CI/CDのベストプラクティスをリポジトリにまとめる。
	•	JIRAのタスクとNotionの知識をリンクし、横断的に再利用。

形式知同士を組み合わせて、新しいルールや知識体系を生み出す段階です。プロジェクト横断のベースラインを作るのに重要な工程です。

## 4. 内面化：実践を通じた「腑に落ちる」知識化
	•	コーディング規約を実際にプロジェクトで使い、「体で覚える」。
	•	TDDの手法を日常的に実践し、判断軸として根付かせる。
	•	勉強会でのインプットを、実装で試すことで自分の引き出しに。

最終的に、形式知が再び暗黙知として個人に内在化され、次の「共同化」につながっていきます。

## SECIモデルで開発文化を育てる

SECIモデルの本質は、「知識の循環による組織学習」です。開発チームもまた、単なる技術集団ではなく、学習する組織であるべきです。

たとえば：
	•	スクラムでのふりかえり → 表出化と連結化
	•	設計レビュー → 表出化と共同化
	•	モブプロ → 共同化と内面化
	•	テックブログ執筆 → 表出化と連結化

これらの活動が、知のスパイラルを加速させ、チームの開発力を底上げします。

## おわりに：SECIモデルでプロジェクトを「学びの場」に変える

SECIモデルを開発現場に取り入れることで、単なる「仕事」が、知を創り、育て、共有する場になります。

システム開発は、仕様書を書いて、コードを書いて、終わりではありません。常に「なぜ？」を問い、知を循環させていくことが、組織としての持続的成長につながるのです。
奇跡でSAP-C02に合格したお話

2025年6月11日にSAP-C02を奇跡的に合格できました。
元々、2ヶ月くらい勉強をするつもりでしたがピアソンVUEさんの再受験無料キャンペーンが丁度あったためお試しとして受験しましたが奇跡的に受かった形になります。

# 当時のクラウド知識について
・5月頃からやっとAWS案件に参画でき始めてだんだんとAWSサービスに業務として触れる機会が増えてきました。
・資格としては以下を持っている状態でした。
CLF(2年前に取得)
SAA(今年の3月に取得)
DVA(今年の4月に取得)
SOA(今年の5月に取得)

# 勉強方法について
勉強期間：3週間ほど
勉強時間：2時間/日

教材は以下を使用しました。
・Udemy

# Udemy
以下を使用して、勉強しました。
1.[AWS Solution Architect Professional (AWS-SAP-C02) 演習テスト](https://www.udemy.com/share/10bBe73@O5xE3Sk0M3GQu_u3ZnypuN3B2mi2GKRu_8Iw8yMlWrhd0hKdkubl_ABojyp0jxZq/)
時間がまったく足らなかったため、以下の順で周回学習をしました。
①全演習テスト(375問)を一度挑戦し、各問題の解説を吟味
②試験までに演習問題①(Practice Test No.1)を3回連続で9割取れる状態まで周回

2.[【SAP-C02版】AWS 認定ソリューションアーキテクト – プロフェッショナル試験対策問題集](https://www.udemy.com/course/sap-c02aws/?couponCode=24T2MT120625G2)
こちらは全演習テスト(300問)を一周だけ行い、解説を吟味しておりました。

# 試験について
・試験時間：180 分
・問題数：75 個の問題 (複数選択または複数応答)

# 試験結果
752点で合格しました！(750/1000点が合格ライン)

# 次の目標
次は、AWS Certified AI Practitioner (AIF-C01)を狙っていきたいと思ってます。
リーダブルコードはもう古い！？エディタブルコードのすすめ

# はじめに

ソースコードの品質をどう測るか――この問いは、言語やトレンドが変わってもエンジニアリングの核心に居座り続けます。2010 年代前半は『リーダブルコード』に代表される **“読みやすさ”** が金科玉条でした。しかし 2020 年代、プロジェクト規模は桁違いに大きくなり、GitHub Copilot や ChatGPT などの LLM がコードを書き散らす時代になりました。formatterやlinterが行儀を整え、AI が人間以上のスピードで雛形を量産する――そんな世界で、**「読みやすいかどうか」だけを品質の物差しにするのはもはや不十分** です。

そこで本稿が掲げる新キーワードが **“エディタブルコード (Editable Code)”**。言い換えれば、**「あとから何度でも安全に手を入れられるコード」** です。目新しい設計手法ではありません。関数型プログラミング (FP) や Clean Architecture で語られてきた *純粋関数と副作用の分離*――その古典的アイデアに、ひとつの短いラベルを貼り直しただけです。それでも名前を付け直す価値があると信じています。なぜなら、**議論は“言葉”から始まる** からです。

# リーダブルコード再考

『リーダブルコード』(2012) の核はこうでした。

> 1. 名前は正確かつ簡潔に。
> 2. 重複を排し、意図を明確に。
> 3. 理解コストを減らすためのコメントと構造化。

10 年あまりが経ち、開発環境は激変しました。

* **整形の自動化** ―― Prettier や gofmt のおかげでフォーマット戦争は終結。
* **静的解析の常態化** ―― ESLint も RuboCop も、もはや導入しない理由がありません。
* **AI による雛形生成** ―― Copilot が if 文もテストも “それっぽく” 書いてくれます。

こうなると「読みやすさ」は *最低限クリアして当たり前* の衛生要件に落ち着きます。残された課題は **「いかに早く・安全に直せるか」**――すなわち *変更コスト* です。

# エディタブルコードとは何か

**エディタブルコード** を一行で定義しましょう。

> **純粋ロジック (Pure)** と **副作用 (Effect)** の境界が明示されており、変更容易性が最大化されたコード。

キーワードを整理します。

| 用語                    | ざっくり説明                              |
| --------------------- | ----------------------------------- |
| **純粋性 (Purity)**      | 入力が同じなら出力も同じ。外部状態を一切参照しない。          |
| **副作用 (Side‑Effect)** | IO、DB、ネットワーク、ログなど、プログラム外部とやり取りする処理。 |
| **境界 (Boundary)**     | 純粋ロジックと副作用を隔てるインターフェース層。            |
| **依存性注入 (DI)**        | 具体的な IO 実装を後から差し替えられるように渡す仕組み。      |

**ポイントはただ一つ**――“純粋” と “副作用” を **同じ関数内に混在させない** こと。これだけでテスト容易性・可読性・保守性が一気に跳ね上がります。実装言語が Java でも Rust でも Python でも、この原理は普遍です。

# エディタブルコードの四原則

| 原則                     | 何が嬉しいか                      |
| ---------------------- | --------------------------- |
| 純粋ロジックを最優先で書く          | バグ調査と差分確認が局所的になる            |
| 副作用は境界 (IO ポート) に閉じ込める | 複数環境 (本番 / テスト / ベンチ) 切替が容易 |
| 依存を注入し逆参照を断つ           | 実装交換の自由度が最大化                |
| 境界を意識したレビュー基準を設ける      | 「何を見ればいいか」が明確になりレビュー効率向上    |

どれも FP や SOLID 原則で聞き覚えのある話でしょう。**それでいいのです。** 大事なのは「変更容易性」というレンズで再解釈し、*議論の土俵* を用意することにあります。

# 現場適用と落とし穴

エディタブルコードを導入すれば、障害調査や機能追加で **“触るべき場所” がすぐ分かる** ようになります。境界を越えなければ副作用は起こらないので、「とりあえず純粋層をいじってテスト→IO 層は後で考える」という安全な開発フローが取れるのです。

とはいえ万能薬ではありません。

* **過剰抽象化** ―― 「境界を切るぞ！」と意気込むあまり、レイヤがマトリョーシカ化する危険。
* **ドメインの複雑さ** ―― ビジネスロジック自体が外部状態に強く依存するケースでは、純粋性の恩恵が薄れることも。
* **宗教化の罠** ―― *“全部 FP で書け”* という極端な主張は結局メンテ不能な理想論に陥りがち。

# まとめ

読みやすさを担保するツールは出そろいました。**次に問われるのは「どれだけ気軽に壊し、どれだけ素早く直せるか」** です。純粋ロジックと副作用を分離し、変更容易性でコードを語る――これが **エディタブルコード** という提案の核心。賛否はあるでしょう。むしろ異論・反論、大歓迎です。この記事が議論の火種になれば本望。さて、あなたのコードは **“編集し続けられる”** でしょうか？
みんな、生成AI使ってるけど「恐ろしさ」に気付いてるよね

初めまして。
表題のとおり、生成AIの恐ろしさを言語化する試みをします。

# 結論

本当の恐ろしさは「プログラマの仕事を奪われること」では無い。我々の「考える力」つまり「悩む、というある意味で幸福な時間」を奪われることだと思う。

# 言語化の試み

## 衝撃
私は未経験エンジニアとしてとあるIT企業に入社した。数値解析の経験はあるが、web開発の経験はない。そんな私が、研修としてwebアプリケーションのチーム開発に挑戦することとなった。

新人研修の中でGitHub Copilotが解禁され、使ってみた。するとどうだろう。

私自身は「React？Typescript？何が違うの？」という状態にも関わらず、Agentモードを頼るととんでもない勢いでコードが生成される。しかもほぼ指示通りのフロントデザイになっている…もうその時点で、私は全能感に満ち溢れていた。神になったような感覚があった。もうなんだって作れるぜ！…とね。
私はただのCopilot Copilot（Copilotとは「副操縦士」であるにも関わらず）になっていた。
文法も何も分からない。無名関数？オブジェクト？props？そんなものは知らん。見た目が整っていたら良い。
動けば良い。


## 惨劇

デザインをこうしたい！ここの動きはこうした方が良い！という考えはあり、その通り指示を出し、実装をした。しかし致命的なミスがあった。出力されたコードを何一つ説明できない。もはやconstが定数を表していることくらいしか分からない。でも動く。動くからOK。

そしてある日、悲劇は起きる。
当然ながら、何も「OK」ではなかったのである。

「バックと繋ぎたいんだけど、型がめちゃくちゃじゃない？」

と、チームメンバーにいわれた。Typescriptの"Type"はその名の通り、型を意味する。めちゃくちゃざっくり言うと、

TS=JS+型

ですよね。書き手は型を常に意識することでバックとの結合が容易になる。しかし生成AIは型のことなど全く知らないし、考えていない。私のプロンプトに従って、ただただ「動くフロント」「それなりに整ったUI」を生成し続けるだけだ。

その結果、バックとの結合で大炎上。私はTypescriptのコードを何も理解していないので、「○○ってどうなってる？」と聞かれても答えられない。結果的にスーパープログラマーのおかげで鎮火はしたが、あれは惨劇と呼ぶに相応しい状況だった。

# 総括

このエピソードから得られる反省点や意見。

1. 初学者はAIに頼りすぎないこと（頼らないのは良くない）。華々しいスタートダッシュをきれたとしても、それは開発フェーズ残り30%で爆死リスクが跳ね上がっているだけです。そして初学者なので、何がダメか分からない。動いているのに何故かエラーが出ている…みたいなことに。数値計算をしていた時は、元々の使用言語Juliaをある程度知っており、そこから生成AIが興隆してきたのでこのような悲劇は起きなかったのである…。少なくとも書いたコードは全て責任をもって説明をできる状態になろう。（これはネットに落ちているコードをこぴぺしてきたときもおな）
2. 時にはAIに頼らず、着実に勉強をすることが大事。手を動かし、頭を使いましょう。何も考えずコードをタイピングするだけなら人間不要です。しかし働く上で、AIには創出出来ない価値を提供するタイミングが必ず来るはずです。良くも悪くもAIは一般論しか吐き出しません。必ず我々の頭を使うタイミングは来ます。常にAI頼りのコーディング=頭を使わないコーディングをしていたら、いざと言う時に爆死すると思います。

AIに頼らず、AIデトックスをしながら着実に勉強を積み重ねましょう。きっとその先に、本当の意味でAIを使い倒せる「AI人材」になることが出来るので無いでしょうか。
自分だけの【特別】を作れる世界 再投稿

メタバース空間に動いて喋る自分だけのカスタム可能なAIが居てくれたら最高じゃないですか？という企画です。
具体的には、例えば髪の毛をいじってあげられたり、人工無能とchatGPTの掛け合わせのように、特定のアクションで反応が帰ってきたり、その場でキャラクリができたりなど……
詳細はこちらのnoteにてご覧下さい。
https://note.com/planetchan/n/n0c28d76e8d8a
様々な技術者を募集しています、まだまだ発足段階ですが、お気軽にご連絡いただければ幸いです。
WSLのgitはいまだにデフォルトのブランチ名にmasterを使っている気がする　→衝撃の結果

タイトル通り。vscodeでpushしたときにびびり散らかしました。

## そもそも

![image-1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/569616/ba405ba6-e9ed-4d48-af41-96d61221b4fb.png)

なんでだ

## WSLでgitの設定をする

設定していないからですね。
こちらの記事が参考になります。

[Git ことはじめ (for Ubuntu)](https://zenn.dev/kusaremkn/articles/1262af3dea93a3)

以下は重要です。デフォルトがmasterっぽいので。

```bash
git config --global init.defaultbranch 'main'
```

## 結果

やったね

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/569616/9837571e-3112-4c6d-a220-95119f2c3b68.png)

## と思ったら

もしかしてwindowsの設定に引っ張られてるっぽい？
そういえばwindowsのgitのほうが昔から使ってる。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/569616/47e0dae0-7252-466d-b187-e4f575b8d073.png)

masterだー！！！

```powershell
git config --global init.defaultbranch 'main'
```

### 直らない。

再設定にはまず取り消してからの模様。
設定の取り消しには `--unset` を使う．

```powershell
git config --global --unset init.defaultbranch
```

そして改めて

```powershell
git config --global init.defaultbranch 'main'
```

やっぱ直んねえ。
学習8日目

# 今日やったこと
①railsの複数形の誤認識問題解消
②form_withでのプルダウン表示

# ①railsの複数形の誤認識問題解消
railsでモデルを作成する時、テーブル名はsを付けて複数形にしてくれるのだが、それでは複数形にならない(英語的におかしい)場合があるので、その対応方法。
config/initializers/inflections.rb で設定できる。
```
ActiveSupport::Inflector.inflections(:en) do |inflect|
   inflect.irregular "person", "people"
end
```
上記を記述した後、personモデルを作成すると、テーブル名は自動的にpeopleになる。


# ②form_withでのプルダウン表示
基本形は下記。
```
<%= form.collection_select :カラム名, 候補として表示したいもの(配列), :実際に保存するキー, :表示するキー, include_blank: "空の場合表示させる文字" %>
```
分かりづらいので、少し具体的な例は下記。
```
<%= form.collection_select :hoge, Hoge.all, :id, :name, include_blank: "選択してください" %>
```

# 感想
 inflections.rbの追加は裏技的な方法だと認識したので、railsが正しく認識できるクラス名を使うのが原則だと感じました。
form.collection_selectの引数は紛らわしいので、使っていくうちに慣れるしかないのかなと思います。
VIMチャレンジその2(全5回)：VIMの真骨頂「コマンド組み合わせ」

## コマンドの組み合わせ

- 基本的なコマンドでもかなりの効率化になる
- 基本的なコマンドの組み合わせで複雑な操作が可能になる

（関数型PG言語みたい、と思った方は何かにかなり毒されています！素晴らしい）

----

## コマンドの前に数値(1/2)

- 基本的には次のコマンドを繰り返す
- 2行コピー　→ `2y`
- 2回ペースト　→ `2p`
- 10行下に移動　→　`10j`

----

## コマンドの前に数値(2/2)

- 10単語後ろに移動　→ `10w`
- 10単語前に移動　→ `$ 10b`
  行末から移動した方が早いときに便利
大雑把に移動するときに使う

----

## 特定行にジャンプ

- 33行目にジャンプ　→ `33gg`

## 選択モードとの組み合わせ

- 3行選択　→ `Shift+V 3j`
- 全体を選択してコピー　→ `gg Shift+V G y`
  こう書くと複雑だがすぐ手癖になります

----

## PGのエラー箇所に移動

VS Codeと組み合わせると・・・

```
backend/src/Texts.hs:7:22: error: [GHC-76037]
```

- `7gg 22l`

----

## 番外

- 単語単位の操作
   - 移動：`w`
   - 単語の削除：`dw`
- カッコの対応を確認
   - `%`
k3sで 502 Bad Gateway エラー

## はじめに
`k3s`を使った検証環境の構築中に、`Traefik`や`Ingress`を設定しても外部からアクセスできない（502 Bad Gateway） という問題に直面しました。結論から言うと、原因は`firewalld`による通信遮断でした。

## 事象
- k3s をインストールし、HelmChart により Traefik（Ingress Controller）をインストール
- Ingress / Service / Pod の設定を完了
- kubectl get ingress, kubectl get svc, kubectl get pods など、全て正常
- しかし、外部端末から http://<ホストIP> にアクセスすると 502 Bad Gateway

## 原因
`firewalld` が、k3s の仮想NIC（例：cni0, flannel.1）からの通信をブロックしていたため。
その結果、Traefik が Pod へルーティングしようとしても通信が遮断され、外部からのリクエストに対して 502 が返されていた。

## 対策
firewalldのゾーン設定を見直しました。
内部通信を許可するために、以下のようにゾーンを設定しました。

```bash
# デフォルトゾーンを trusted に変更（内部通信をすべて許可）
sudo firewall-cmd --set-default-zone=trusted

# 外部NIC（例：enp0s3）を public に設定（外部からの制限は継続）
sudo firewall-cmd --zone=public --change-interface=enp0s3 --permanent

# 設定を反映
sudo firewall-cmd --reload
```
:::note warn
※本番では適切なゾーン・ポート設定を。
:::
## 補足：ルーティングの流れとfirewalldの影響
今回の構成は以下です。

```
外部クライアント
  ↓
ホストマシン (publicゾーンのNIC)
  ↓
Traefik (Ingress Controller)
  ↓
Service → Pod
```
このうち、「Traefik → Pod」や「Service → Pod」の通信が firewalld により遮断されていました。その結果、Traefik は「バックエンドに接続できない」と判断し、502 Bad Gateway を返しました。

## 振り返り
今回の`502 Bad Gateway`は、ゲートウェイ（ここでは Traefik）がバックエンドから有効な応答を受け取れなかった」ことを示します。
エラー内容から、リクエスト自体はTraefikに届いていると判断できたため、当初はアプリケーション寄りの設定ミスを疑い、上位レイヤから調査を進めてしまいました。

- TraefikのHelmChart設定（entryPoints、servicePorts）
- Ingressのルーティング設定
- Serviceのselectorやportの不整合
- Railsアプリのlistenポートやhost設定
- TLS証明書のミスやSSL終端の誤設定

結果としてこれらは問題なく、原因は、 **ネットワーク層での通信制御（firewalld）** でした。

## 教訓
「分からない技術＝怪しい」と思い込み、いきなり上位レイヤー（アプリ層）から調べ始めてしまったことが遠回りの原因でした。

特に Kubernetes のような多層構造のある技術では、下位レイヤー（OS、ネットワーク）から順に切り分ける意識が非常に重要だと感じました。

以上です！

# 参考にした記事
https://qiita.com/DAMDAM/items/310d04e35f35b8f69f3d
プロジェクトマネージャー（PM）を育てるには

# １：近年高まるプロジェクトマネジメントの重要性
近年、ビジネス環境の変化が加速する中で、プロジェクトマネジメントの重要性がますます高まっています。技術の進化、グローバル化、リモートワークの普及などにより、従来の管理手法では対応しきれない複雑な課題が増えているからです。

特に、短期間で成果を求められるプロジェクトや、多国籍チームが関わる案件では、明確な目標設定、リソース管理、リスクマネジメントが不可欠です。適切なプロジェクトマネジメントがなければ、スケジュールの遅延や予算超過、品質の低下といった問題が発生し、組織の競争力にも影響を及ぼしかねません。

また、近年はアジャイルやスクラムといった柔軟なマネジメント手法が注目されており、変化に迅速に対応できる能力が求められています。こうした手法を活用することで、プロジェクトの成功率を高めると同時に、チームの生産性やモチベーション向上にもつながります。

企業や組織が持続的な成長を遂げるためには、プロジェクトマネジメントのスキルを磨き、時代の変化に適応することが不可欠です。これからのビジネス環境において、優れたプロジェクトマネジメントこそが成功への鍵となるでしょう。

# ２：プロジェクトマネジャーに必要な知識・スキル
では、優れたプロジェクトマネジメントを行うには、どのような知識・スキルが必要になるのでしょうか。
知識とスキルに分けてご紹介します。

1. 知識編（理論・概念）
① プロジェクト管理の基礎

PMBOK（Project Management Body of Knowledge）の知識体系

プロジェクトライフサイクル（立ち上げ → 計画 → 実行 → 監視・コントロール → 終結）

アジャイル開発手法（Scrum、Kanban など）

リスク管理、スコープ管理、コスト管理、品質管理

② ビジネス・業務理解

事業戦略やマーケット分析

業界特有のプロジェクト特性

財務知識（ROI、予算管理、コストコントロール）

③ IT・デジタルリテラシー（IT関連PM向け）

システム開発の基礎（ウォーターフォール・アジャイル）

クラウド・SaaSの知識

データ分析・BIツールの活用

2. スキル編（実践・応用）
① コミュニケーション・ファシリテーション

ステークホルダーとの調整・交渉力

メンバーのモチベーション管理

会議のファシリテーションスキル（議論の可視化、意思決定）

② リーダーシップ・マネジメント

チームビルディング

コーチング・メンタリング

問題解決力（ロジカルシンキング、クリティカルシンキング）

③ タスク・進捗管理

WBS（Work Breakdown Structure）作成

ガントチャート・タスク管理ツール（Jira, Trello, Asana など）の活用

スプリント計画（アジャイル開発）

④ リスク・トラブル対応

トラブルシューティング

クライシスマネジメント

想定外のリスク対応（バックアッププラン策定）

# ３：プロジェクトマネジャーを育てるには
では、優れたプロジェクトマネジャーを育てるには、どうしたらよいでしょうか。
プロジェクトマネジャーには、プロジェクト管理の知識だけでなく、コミュニケーション力やリーダーシップ、問題解決力など幅広いスキルが求められます。OJTと体系的な研修を組み合わせて、実践的に育成するのが効果的です。

具体的には、下記のような要素を組み合わせるとよいでしょう。

・PM向け研修・資格取得
→ PMP（Project Management Professional）、スクラムマスター資格

・ケーススタディ・ロールプレイ
→ 実際のプロジェクト事例を用いた学習
・OJT（実際のプロジェクト経験）
→ 小規模プロジェクトを任せ、段階的にスキルアップさせる

・メンター制度
→ 経験豊富なPMが指導しながら育成

# ４：プロジェクトマネジメントのスキルと知識を評価するワールドワイドの認定資格「CompTIA Project+」
プロジェクトマネジメントのスキルと知識を評価するワールドワイドの認定資格として、「CompTIA Project+」があります。


CompTIA Project+は、小規模から中規模のプロジェクトを管理するプロフェッショナルを対象とし、プロジェクトライフサイクルの管理、適切なコミュニケーションの実施と管理、ステークホルダーとリソースの管理、プロジェクト文書の管理に必要なスキルと知識を評価します。

プロジェクトマネジメントの12カ月程度の実務経験で得られる知識やスキルを目安に設計されています。
CompTIA Project+を取得することで、大規模なプロジェクト管理に向けたスキルのベースを育成することも可能です。

「CompTIA Project+」詳細はこちら
https://www.comptia.jp/certif/additional_professional/comptia_project/

# 5：まとめ
①近年、ビジネス環境の変化が加速する中で、プロジェクトマネジメントの重要性がますます高まっている。

②優れたプロジェクトマネジメントを行うには、プロジェクト管理の基礎、ビジネス・業務理解、IT・デジタルリテラシーといった知識に加え、コミュニケーション・ファシリテーション、リーダーシップ・マネジメント、タスク・進捗管理、リスク・トラブル対応といったスキルが必要とされる。

③優れたプロジェクトマネジャーを育てるには、OJTと体系的な研修を組み合わせて、実践的に育成するのが効果的である。

④プロジェクトマネジメントのスキルと知識を評価するワールドワイドの認定資格として、「CompTIA Project+」がある。
プロデル、調査 その38

# 概要
プロデルが、CLRらしいので、調べて見た。
アナログ時計、見つけたのでやってみた。

# 参考にしたページ

https://produ.irelang.jp/bbs/progbbs/forump.php?mode=view&id=67

# 写真

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/18104/d15c5dc8-8723-4334-be65-5d3a45bcf61a.png)

# サンプルコード

```
メイン画面を表示する
待機する

メイン画面とは
　　	ウィンドウを継承する
　　	はじめの手順
　　　　	初期化する
　　　　	キャンバス1に子キャンバスを作って子キャンバス4とする
　　　　　　		その位置と大きさは、{10, 10, 100, 100}
　　　　　　		その太さは、0
　　　　	子キャンバス4へ円を描く
　　　　　　		その位置と大きさは、｛0, 3, 200, 200｝
　　　　　　		その線色を紺色に変える
　　　　　　		その太さを3に変える
　　　　　　		その背景色をレモンに変える
　　　　	子キャンバス4に子キャンバスを作って子キャンバス1とする
　　　　　　		その位置と大きさは、｛103, 103, 0, 0｝
　　　　　　		その背景色を白に変える
　　　　	子キャンバス1へ線を描いて秒針図形とする
　　　　　　		その位置と大きさは、｛0, -85, 0, 85｝
　　　　　　		その線色を黒に変える
　　　　　　		その太さを1に変える
　　　　	子キャンバス4に子キャンバスを作って子キャンバス2とする
　　　　　　		その位置と大きさは、｛103, 103, 0, 0｝
　　　　　　		その背景色を白に変える
　　　　	子キャンバス2へ線を描いて分針図形とする
　　　　　　		その位置と大きさは、｛0, -90, 0, 90｝
　　　　　　		その線色を青に変える
　　　　　　		その太さを3に変える
　　　　	子キャンバス4に子キャンバスを作って子キャンバス3とする
　　　　　　		その位置と大きさは、｛103, 103, 0, 0｝
　　　　　　		その背景色を白に変える
　　　　	子キャンバス3へ線を描いて時針図形とする
　　　　　　		その位置と大きさは、｛0, -70, 0, 70｝
　　　　　　		その線色を赤に変える
　　　　　　		その太さを4に変える
　　　　	描画する
　　　　	タイマー１というタイマーを作る
　　　　	タイマー１の時間になった時の手順は、描画する
　　　　	タイマー１の間隔を1000に変える
　　　　	タイマー１を開始する
　　	終わり
　　	初期化する手順
　　		この設計スケール比率を｛144, 144｝に変える
　　		この内部領域大きさを｛493, 402｝に変える
　　		この内容を「アナログ時計」に変える
　　		キャンバス1というキャンバスを作る
　　　　		その位置と大きさを｛0, 0, 493, 402｝に変える
　　　　		その倍率を1.5に変える
　　　　		その移動順を1に変える
　　　　		そのドッキング方向を「全体」に変える
　　	終わり
　　	描画する手順
　　　　	子キャンバス1の角度は、今の秒 * 360 / 60
　　　　	子キャンバス2の角度は、今の分 * 360 / 60
　　　　	子キャンバス3の角度は、(今の時 % 12) * 360 / 12 + 今の分 * 360 / 12 / 60　
　　　　	キャンバス1を更新する
　　	終わり
終わり
	

```

以上。
ChatGPTを使用したアプリ開発記【株価シグナル判定ロジックの拡張】

## 複数の条件を統合して「シグナルの強さ」や「根拠の数」を明示
```AppleStock.js
//data（株価・SMA・RSIなどの情報を含むリスト）を入力として受け取る関数です。
//各データ点ごとに「売買シグナル（BUY/SELL）」を判定して返します。
function generateSignals(data) {
  
  	//.map() を使って data の各要素に対して処理を行います。
	//item は現在のデータ点（例: 特定時刻の株価など）
	//index は現在の位置（0, 1, 2, …）
	//arr は data 全体（後で参照するために渡されている）
  return data.map((item, index, arr) => {

  	//最初のデータ点（index === 0）や、SMA・RSIがまだ計算されていない点はスキップ（シグナルを出さない）。
	//元の item に signal: null を付けてそのまま返す。

    if (index === 0 || !item.sma || item.rsi == null) return { ...item, signal: null };

	//1つ前のデータ点（時系列で直前の状態）を取得します。
	//SMAクロスなどの前後比較で使用します。
    const prev = arr[index - 1];

    //スコア（BUY/SELL を判定するための加点方式）を初期化。
	//どの条件が当てはまったかを記録する reasons 配列も初期化。
    let score = 0;
    let reasons = [];

    //RSIが30未満 → 買われ過ぎで反発を期待 → +1
	//RSIが70超 → 売られ過ぎで下落を警戒 → -1
	//判定理由も reasons に保存します。
    if (item.rsi < 30) {
      score += 1;
      reasons.push('RSI < 30');
    } else if (item.rsi > 70) {
      score -= 1;
      reasons.push('RSI > 70');
    }

   	//前回は終値がSMAを下回っていて、今回は上回った → ゴールデンクロス → 上昇の兆し → +1
	//逆に 前回は上回っていて、今回は下回った → デッドクロス → 下落の兆し → -1
    if (prev.close < prev.sma && item.close > item.sma) {
      score += 1;
      reasons.push('ゴールデンクロス');
    } else if (prev.close > prev.sma && item.close < item.sma) {
      score -= 1;
      reasons.push('デッドクロス');
    }

    //3本前のローソク足と比較して現在の終値が上 → 短期上昇トレンド → +1
	//3本分のデータがないときはスキップされます（index >= 3）
    if (index >= 3 && item.close > arr[index - 3].close) {
      score += 1;
      reasons.push('上昇トレンド');
    }

    //スコアが +2 以上なら「BUY」
	//スコアが -2 以下なら「SELL」
	//中間（-1, 0, 1）はシグナルなし（null）
    let signal = null;
    if (score >= 2) signal = 'BUY';
    else if (score <= -2) signal = 'SELL';

	//元のデータに signal（BUY / SELL / null）、reasons（条件の説明）、score を追加して返す。
	//シグナルがない場合は reasons は空配列。
    return {
      ...item,
      signal,
      reasons: signal ? reasons : [], // 理由も追加
      score
    };
  });
}
```

## チャート上で理由を表示
```AppleStock.js
//ReferenceDot は、グラフ内の特定の (x, y) 座標に丸印を表示するコンポーネントです。
//通常、イベントやシグナルなどの特別な点を目立たせるために使います。
<ReferenceDot
  
  //Reactが描画の際に要素を一意に識別するための key。
 //配列 .map() 内で使われているので index を一意識別子にしています。
  key={index}

  //x 座標を指定。
  //この場合、横軸（X軸）は時間であり、データ点の時刻 item.datetime にドットを表示します。
  x={item.datetime}

  //y 座標を指定。
  //縦軸（Y軸）は株価（終値）なので、item.close の価格位置にドットが表示されます。
  y={item.close}
  
  r={5}
  fill={item.signal === 'BUY' ? 'green' : 'red'}
  stroke="black"
  strokeWidth={1}

  //ドットの上に表示される**ラベル（注釈）**のスタイルを定義します。
  label={{

  //BUY (RSI < 30, ゴールデンクロス) のような形式で表示されます。
//item.reasons は generateSignals 関数で追加した理由の配列です。
    value: `${item.signal} (${item.reasons.join(', ')})`,
    position: 'top',
    fontSize: 10,

    //ラベルの文字色もシグナルに合わせて
	//BUY なら 緑
	//SELL なら 赤
    fill: item.signal === 'BUY' ? 'green' : 'red',
  }}
/>
```
## UI

![スクリーンショット 2025-05-26 10.29.26.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1058366/e0faceb2-3c0f-4be7-85f9-c8defbccbae9.png)
M4 Macに移行後、pnpmやDockerで「Bad CPU type in executable」が出た話と解決法

# 問題点
Intel MacからM4 Macに開発環境を移したところ、`pnpm install` や `docker compose` 実行時に以下のようなエラーが出るようになりました。

```bash
env: node: Bad CPU type in executable
```

また、`brew` を実行しても、
```bash
/usr/local/.../ruby: Bad CPU type in executable
```
と同様のエラーが出て、まともに何も動かせない状態に。


## 原因

結論から言うと、**Intel Macで使っていたツール類がAppleシリコン（ARM）に対応していないバイナリのまま残っていた**のが原因です。M4 Mac上では当然これらの実行ファイルは動きません。

Rosetta2を入れてIntel向けバイナリを動かす選択肢もありましたが、開発環境の序盤ということもあり、**完全にApple Siliconネイティブな環境に作り直すことにしました**。

---

## 対応したこと

### 1. Homebrew を削除して再インストール

```bash
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/uninstall.sh)"
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
```

.zprofile に以下を追記してパスを通します：
```bash
echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zprofile
source ~/.zprofile
```

### 2. Node.jsの再インストール（Intel版の削除 → ARM版のインストール）
```bash
brew install node
```
### 3. pnpm の再インストール
```bash
npm install -g pnpm
```
### 4. Docker Desktopの再インストール（Apple Silicon向け）
Intel時代に使っていた /Applications/Docker.app を削除し、
以下の公式から「Apple Chip」版を再インストール：

https://www.docker.com/products/docker-desktop/

※Docker Compose は Docker Desktop に同梱されているので、個別に入れる必要なし。

# まとめ

Intel MacからAppleシリコンMacに移行する場合に
```bash
Bad CPU type in executable
```
のようなエラーが出ると検索した場合、Rosettaをインストールする記事が出てくるが、環境構築し直す方法もすぐに見つかって欲しかったので微力ながら記事を投稿します。
Homebrew・Node.js・Dockerなどのツール類を再度インストールすることになるため、開発規模が大きい場合はかなり手間かも。
ただ早めに対応しておくとRosettaを挟まなくていいので、将来的な安定性を加味すると再度インストールする方が良さそうに思いました。
Geminiでアシカと遊ぶ魔法少女を描いてみた。

# 概要

Geminiでアシカと遊ぶ魔法少女を描いてみました。

# 実装

プロンプトと実行結果は以下の通りでした。

```
電撃のアシカと遊ぶ魔法少女を描いてください。
```

![電撃のアシカと遊ぶ魔法少女_20250612.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3192024/c977a024-b3ee-4526-a77b-f7caffc92e6c.png)

# まとめ

何かの役に立てばと。
プロデル、調査 その37

# 概要
プロデルが、CLRらしいので、調べて見た。
webserver見つけたのでやってみた。

# 参考にしたページ

https://produ.irelang.jp/bbs/progbbs/forump.php?mode=view&id=31

# 写真

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/18104/877e627a-4e69-472e-9633-25415a136155.png)

# サンプルコード

```

待機画面を表示する
待機する

待機画面とは
　　	ウィンドウを継承する
　　	サンプルサーバである試験サーバを持つ
　　	はじめの手順
　　　　	初期化する
　　　　	［自分］の試験サーバは、サンプルサーバを作ったもの
　　　　	［自分］のボタン１の有効を○へ変える
　　　　	［自分］のボタン２の有効を×へ変える
　　	終わり
　　	初期化する手順
　　　　	この内部領域大きさを｛388、 248｝に変える
　　　　	この種類を「固定」に変える
　　　　	この内容を「待機画面」に変える
　　　　	このドラッグドロップを○に変える
　　　　	ボタン1というボタンを作る
　　　　　　		その位置と大きさを｛54、 57、 281、 52｝に変える
　　　　　　		その内容を「サーバ起動」に変える
　　　　　　		その移動順を2に変える
　　　　　　		そのフォントを「MS UI Gothic,14.25」に変える
　　　　	ラベル1というラベルを作る
　　　　　　		その位置と大きさを｛12、 9、 290、 14｝に変える
　　　　　　		その内容を「試験用Webサーバを8089ポートで実行します」に変える
　　　　　　		その移動順を1に変える
　　　　	ボタン2というボタンを作る
　　　　　　		その位置と大きさを｛54、 142、 281、 52｝に変える
　　　　　　		その内容を「サーバ停止」に変える
	　　　　　　	その移動順を3に変える
　　　　　　		そのフォントを「MS UI Gothic,14.25」に変える
　　	終わり
　　	ボタン１がクリックされた時の手順
　　　　	［自分］の試験サーバを起動する
　　　　	［自分］のボタン１の有効を×へ変える
　　　　	［自分］のボタン２の有効を○へ変える
　　	終わり
　　	ボタン２がクリックされた時の手順
　　　　	［自分］の試験サーバを停止する
　　　　	［自分］のボタン１の有効を○へ変える
　　　　	［自分］のボタン２の有効を×へ変える
　　	終わり
　　	閉じる時の手順
　　　　	［自分］の試験サーバを停止する
　　　　	終了する
　　	終わり
終わり

サンプルサーバとは
　　	TCPIPサーバを継承する
　　	TCPIPクライアントである接続クライアントを持つ
　　	はじめの手順
　　　　	［自分］のポート番号を8089へ変える
　　	終わり
　　	受信した時の手順
　　　		　//「受信した時の手順開始」を表示
　　　　	［自分］の接続クライアントは、イベントのクライアント
　　　　	［自分］の接続クライアントの文字コードを「UTF-8」へ変える
　　　　	［自分］の接続クライアントの受信した時の手順は、クライアント通信する
　　　　	［自分］の接続クライアントを受信開始する
　　	終わり
　　	クライアント通信する手順
　　　　	リクエスト内容は、文字列である
　　　　	リクエスト内容は、イベントの受信テキスト
　　　　	応答内容は、文字列である
　　　　	応答内容は、「HTTP/1.1 200 OK
Date: Sun, 11 Jan 2004 16:06:23 GMT
Server: Apache/1.3.22 (Unix) (Red-Hat/Linux)
Last-Modified: Sun, 07 Dec 2003 12:34:18 GMT
ETag: "1dba6-131b-3fd31e4a"
Accept-Ranges: bytes
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

<HTML>
　　<HEAD>
　　　　<TITLE>試験ページ</TITLE>
　　　　
　　　　<META HTTP-EQUIV="Content-type" CONTENT="text/html; charset=UTF-8">
　　</HEAD>
　　<BODY>
　　　　<B>試験サーバとブラウザの通信に成功しました。</B>(［今日の内容］)<BR>
　　　　<BR>
　　　　<B>ブラウザから送信されたリクエスト</B><BR>
　　　　［リクエスト内容から改行を「<BR>［改行］　　　　」へ置換したもの］
　　</BODY>
</HTML>」
　　　　	［自分］の接続クライアントから応答内容を送信する
　　　　	//「応答送信完了［改行］切断します」を表示
　　　　	［自分］の接続クライアントを切断する
　　	終わり
終わり
	



```

以上。
WEBサービスを提供するならVPSより自宅サーバーが良い

自宅サーバーに行き着くまでには紆余曲折が必ず発生します。<!--以下のような葛藤や失敗もせず、今この記事を読んでいるのであれば過去の自分の失敗談を心に刻んでください。自宅サーバーを作りたいということは-->
レンサバでは不都合な何かがあったのでは？！
* 80 443 以外のポートを使いたい
* 広告を出したくない
* 当日のログを見たい

次に考えたのは <strong>VPSサービス</strong> ではありませんか？
* 高価な専用線を自宅に敷設したくない
* レンサバ料金より少々高い程度なら

<table>
<tr>
<th></th><th>VPS</th><th>自宅サーバー</th>
</tr>
<tr>
<td>サーバー</td><td>貸借</td><td>自前</td>
</tr>
<tr>
<td rowspan=2>ISP契約</td><td rowspan=2>動的IP</td><td>固定IP：ほぼ専用線</td>
</tr>
<tr>
<td>動的IP：ルーター製造会社のDDNS</td>
</tr>
<tr>
<td>費用</td><td>数百円/月</td><td>数千円～数百円/月</td>
</tr>
</table>

日本で言う <strong>VPSサービス</strong> は「ネットからログインして使える仮想サーバーを貸すサービス」です。一見、これでいいように思うかもしれませんがあなたに質問、あなたは１人でも多くの人にアクセスして貰いたいと思っているはず。<strong>VPS</strong> を借りるのが目的ではない！いかがですか。ここからが重要です、あなたが借りるサーバーはWANに設置されているわけではありません。ルーターを経由してインターネットに繋がるサーバーを借りるだけです、ルーターのWANポートがもし希望通り開かなければ！と危惧しませんか。

必ず次のことが発生します。
* ルーターのWANポートを自分で開けられない！もちろん要求はできますと言うかします <strong>5060/UDPを開けてください</strong> とか
<!--
* すぐに解約できない！事前に口頭説明しないことが多い
* 最低利用月数 `3ヶ月` とかあったりする
-->

参考までに <strong>5060/UDP</strong> を開け…自宅サーバーで運用中のサイトを載せときます。

https://web3.anecdotz.com/

自分の技術力のなさで、とんでもないことを自分が言っていたら！との心配から、当初は只確認の為に自宅サーバーを用意しました。確認はすぐに済み…やはり相手側の問題と明確になりました。

ちなみに <strong>8080/TCP</strong> をお願いした時は、開けてもらえたし通りました。ポートを空けてくれるかは会社にも寄りますが、支払った後だと期待薄。権威DNSを建てる！と言ったときは「アクセス制限かける」とも言われました。

レンサバと同じなら、誰が <strong>VPSサービス</strong> を使いますか？

自分で <strong>サーバーのポートを開ける</strong> の何て当たり前ですが、ルーターを通過できないこと！外から貸借サーバーに繋がらないことが一番の問題になります。だからVPSは怖い。

不思議なのは <strong>5060/UDP</strong> を開けたい！なんて当たり前の要求じゃないですか？米国の話をしますが、向こうに <strong>日本型VPS提供会社</strong> は存在しません。ルーターとサーバーと言った切り分けではなく「？番ポートを開放する」が幾つものサービスの中にポツンと存在し、開放すれば、外からアクセスできます。日本のように、気が付いたとたん「全部失敗」とはなりません。

こういう確認は契約して使ってみないと分からない！ゆえに経験が大事だと言っています。他の会社も同じと思ったのはメールで「ルーターのポートは自由に開けられますか」と問い合わせたとき。それまでは長文でしっかり回答をいただけたものが急に音沙汰なしに。

必然的に <strong>自宅サーバーしかない</strong> となりました。

ミニPCを用意するのが最善かと思います。テレビの待機電力よりよほど少ない電力量でした。ワットチェッカーで計測すると実感できます。消費電力量を気にして選んだPCでは決してありません。
【Python初心者】カスタムデコレーターの基本をわかりやすく学ぶ


Pythonの「デコレーター」は、関数の前後に共通の処理を追加できる便利な機能です。  
ただし最初は、関数の中に関数がある構造や `@記法` などに戸惑うことがあり、自分も最初は混乱しました。

この記事では、Pythonのカスタムデコレーターについて、基本の形から引数ありの応用までをまとめています。  
学習の記録として残しますが、同じように学んでいる方にも参考になれば幸いです。

## デコレーターとは？

Pythonでは、ある関数に「処理の追加」をしたいとき、**関数を別の関数で包む**ことで対応できます。  
この「包む」仕組みが**デコレーター（decorator）**です。

関数に `@デコレーター名` と書くことで、処理を差し替えるようなことができます。

## 最小構成のカスタムデコレーター

まずはデコレーターの最小構成の例を見てみます。

```python
def my_decorator(func):
    def wrapper():
        print("前処理")
        func()
        print("後処理")
    return wrapper

@my_decorator
def say_hello():
    print("こんにちは！")

say_hello()
```

実行結果：

```
前処理
こんにちは！
後処理
```

### ポイント解説

- `@my_decorator` は、 `say_hello = my_decorator(say_hello)` と同じ意味です。
- `wrapper()` はデコレーターの中で定義した **自作の関数** です。
- `func()` が元の `say_hello()` を呼び出しており、呼び出しの前後に追加処理が書かれています。

## 関数に引数がある場合

元の関数が引数を取る場合、そのままでは動きません。  
どんな関数にも対応できるようにするために、`*args` と `**kwargs` を使います。

```python
def my_decorator(func):
    def wrapper(*args, **kwargs):
        print("前処理")
        result = func(*args, **kwargs)
        print("後処理")
        return result
    return wrapper

@my_decorator
def add(a, b):
    return a + b

print(add(3, 5))
```

実行結果：

```
前処理
後処理
8
```

### ポイント

- `*args` は位置引数（a, bなど）をすべて受け取ります。
- `**kwargs` はキーワード引数（例：`key=value` 形式）をすべて受け取ります。
- 戻り値がある場合も `result` に一度受けて、それを返せば対応できます。

## 名前は wrapper でないといけないの？

結論：**いいえ、好きな名前でOKです。**

Pythonに「`wrapper` という特別な関数」が用意されているわけではありません。  
ただし「関数を包む（wrap）」という意味で、多くの人が `wrapper` という名前を使っているだけです。

たとえば、次のように `inner` という名前にしても動作は変わりません。

```python
def my_decorator(func):
    def inner():
        print("処理前")
        func()
        print("処理後")
    return inner

@my_decorator
def greet():
    print("こんにちは！")

greet()
```

実行結果：

```
処理前
こんにちは！
処理後
```

このように、**関数の名前は慣例であって制限はありません**。  
重要なのは「元の関数を包む構造になっていること」です。

## よくある応用：処理時間を測るデコレーター

デコレーターの応用として、処理時間を測るタイマーを作ることもできます。

```python
import time

def timer(func):
    def wrapper(*args, **kwargs):
        start = time.time()
        result = func(*args, **kwargs)
        end = time.time()
        print(f"実行時間: {end - start:.2f}秒")
        return result
    return wrapper

@timer
def slow_function():
    time.sleep(1)

slow_function()
```

実行結果：

```
実行時間: 1.00秒
```

## おわりに

今回は、Pythonのカスタムデコレーターの基本について学んだ内容をまとめました。

- 関数の中に関数を定義し、それを返すことで処理を差し替える
- `@デコレーター名` を使うと見た目も簡潔
- `*args, **kwargs` を使えばどんな関数にも対応できる
- `wrapper` という名前はよく使われているけど、強制ではない
推測可能な初期パスワードからはもう卒業しよう

推測可能な初期パスワードが許されたのは平成まで。令和のイケてる御社はそんなことしない、よね？

# 初期パスワード

- 初期パスワードを推測可能なものにするのはやめましょう
- 誕生日とかユーザーIDとかを法則性のあるアルゴリズムで初期パスワード生成しないようにしましょう
- なぜなら、他の人が推測可能な初期パスワードで新入りのユーザー権限でログインできてしまって、不正アクセスできてしまうから。それは犯罪です
- しかも大抵の場合、そういうところに限って、初回ログイン時にパスワード変更強制していない
- だからしばらく初期パスワードのままになってしまい、他の人が不正アクセスできてしまう環境がそこにはあるのです
- 本来善良な人が、脆弱なシステムのせいで、ちょっとした出来心で不正アクセスして逮捕されてしまうのも不幸ですよね
- だから、初期パスワードは推測不可能なランダムなもので、かつ管理者も知らないようにしましょう

# 参考

[piyolog:誕生日から生成した初期パスワードを悪用した内部不正事案についてまとめてみた](https://piyolog.hatenadiary.jp/entry/2022/07/07/004422)

## 終わり

## 仲間を募集しています！

ARIではエンジニア・ITコンサルタント・PM職全方位で仲間を募集しております。
カジュアル面談、随時受付中です！
ご興味ある方はこちらをご覧ください。

https://note.com/ari_hr/n/n4aed9ba75421
競プロ日記#25/06/11

# AtCoder
## AtCoder Beginner Contest 380
[C - Move Segment](https://atcoder.jp/contests/abc380/tasks/abc380_c)
- C++にはSplit関数がないので自前で用意しなければならない
- 0,1の切り替わりのタイミングの添え字を管理していく、その添え字を使って数列S全体のスワップを実行。その際の基準を先頭の0,1で場合分け。
- 余裕で解説AC

## AtCoder Beginner Contest 377
[C - Avoid Knight Attack](https://atcoder.jp/contests/abc377/tasks/abc377_c)
- このくらいは流石に解けるようになりたい
- setやそのベクトルで管理するという発想が出てこないのはまずい気がする




# 余談だん
今まではアルゴ式やB問題程度しかやっていなかったが茶diffくらいの問題になると平日の仕事終わりに勉強するのが体力的に苦しい。
もっとレベルの高い人たちはさらに高難易度の問題を勉強していると考えると脳にかかる負担が大きそうで恐ろしい...。
DATA+AI SUMMIT 2025 KeyNote Day1 メモ


[DATA+AI SUMMIT 2025](https://www.databricks.com/dataaisummit)にバーチャル参加しています。
キーノートで発表があった、主にプラットフォームの新機能に関するメモの共有記事となります。

日本企業の事例やAnthropic CEOとの対話など、興味深い内容もありましたのでキーノート動画の視聴をお勧めします。**Super Excited here!**

:::note warn
速報的記載のため、内容に誤りがある可能性があります。
できるだけ1次ソースを合わせて参照ください。

Databricks 公式Blogで公開されている情報はそのリンクも付けています。

:::

キーノートDay1動画はこちら。

<iframe width="560" height="315" src="https://www.youtube.com/embed/ul8cRLIP_Vk?si=T7ji6CgYN6zrPM3Y" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

# Databricks Free Edition

クレジットカード登録不要、永久無料で利用可能なDatabricks Platform。
超高性能なComputeまで使えるわけではないが、ほとんどのプラットフォーム機能が利用可能。
教育用途が主なターゲットぽいけど、誰でも利用可能。

生成AIの登場といい、このレベルのプラットフォームが無料利用できるといい、時代の変化を実感する。

https://www.databricks.com/blog/introducing-databricks-free-edition

# Postgres互換のOLTP Database: Lakebase

Databricksの(OLTP)Database。
Postgres互換オープンソースDBであり、ストレージとコンピューティングを分離したアーキテクチャ採用。
AIへの組み込みを想定。
データのブランチングや、Lakehouseとの同期など多様な機能を提供。

https://www.databricks.com/blog/what-is-a-lakebase

# Databricks AppsのGA

AppsはPublic Previewが始まって既に2000以上の顧客から利用。20000以上のアプリが作られている。
今回、正式リリース（Generally Available)。

https://www.databricks.com/blog/announcing-general-availability-databricks-apps

また、様々なパートナーのサービスと連携して、いわゆるVibe-codingでのApps開発も可能な機能、App Builderエコシステムを発表。
キーノートではSuperbrocksを使ったデモが示された。

# Agent Bricksの発表

より容易にプロダクションレベルのAIエージェントを構築できるようにするための仕組としてAgent Bricksを提供。
高品質な最適化を自動で実施。

https://www.databricks.com/blog/introducing-agent-bricks

デモが実施されていたが、容易にマルチエージェントシステム構築も可能であり、最適化手段も提供されている。

# Mlflow 3.0発表など

MLflowの最新バージョンである3.0がリリース。

他に、Serverless GPU Compute(Beta)やMCP on Databricksも発表された。
MCP on DatabricksはMCP serverをDatabricks Appsのインスタンスとして構築可能な模様。

https://www.databricks.com/blog/mosaic-ai-announcements-data-ai-summit-2025

# 所感

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">でかい発表をつぎつぎにさらっと流すの密度高すぎるんよ笑<a href="https://twitter.com/hashtag/DataAISummit?src=hash&amp;ref_src=twsrc%5Etfw">#DataAISummit</a> <a href="https://twitter.com/hashtag/DAISJapanTeam?src=hash&amp;ref_src=twsrc%5Etfw">#DAISJapanTeam</a></p>&mdash; Tyam (@isanakamishiro2) <a href="https://twitter.com/isanakamishiro2/status/1932847767782895916?ref_src=twsrc%5Etfw">June 11, 2025</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

Day2も楽しみです。果たして明日も深夜に起きていられるのか。

# DATA+AI SUMMIT 2025の公式サイトはこちら

https://www.databricks.com/dataaisummit
Liquid Glassを無効化して一時的に非対応にする方法

:::note info
一般公開されているWWDCの動画、公開Session/Documentationページを参照しています
:::

:::note warn
WWDC25にて発表された情報で今後変わる可能性があります
:::

![liquidglass.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/171702/f95b1a5a-2ea5-4ecd-b574-af45e57a5f94.png)

WWDC25でLiquid Glassが登場し、デザインが一新されました。

この変更の影響は大きく、レイアウト崩れだけでなくボタンが反応しない、クラッシュするなどのトラブルに見舞われる可能性があります。

そこで、Appleは一時的にLiquid Glassを一時的に無効化し、従来の見た目を保つことができる互換性モードを用意してくれました。

`Info.plist`に以下のKeyを追記することで互換性モードを有効化できます。
```Info.plist
	<key>UIDesignRequiresCompatibility</key>
	<true/>
```

なおXcode26 Betaでデフォルトは falseで互換性モードはOFFになっています。

:::note alert
この互換モードは次のメジャーリリースで終了予定です。それまでに新デザインの導入を検討しましょう。
:::

![スクリーンショット 2025-06-12 0.31.59.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/171702/b625996a-9083-4d67-9d6a-98072ea9f87f.png)


https://developer.apple.com/videos/play/wwdc2025/102/?time=1153

## 参考
https://developer.apple.com/documentation/BundleResources/Information-Property-List/UIDesignRequiresCompatibility

State of the Union
https://developer.apple.com/videos/play/wwdc2025/102