OmniAICreator/Qiita-1.07M huggingface dataset:
深さ制限ミニマックスと評価関数：AIにおける知識推論の進化


以下の動画の、内容を要約しました。
https://youtu.be/5NgNicANyqM?si=Qc3Dzaw6gf3x5qmd

# 深さ制限ミニマックスと評価関数：AIにおける知識推論の進化

人工知能（AI）の分野では、ゲームや問題解決の際に効率的な探索アルゴリズムが重要です。本記事では、ミニマックスアルゴリズムの制限を克服する方法として、**深さ制限ミニマックス（Depth-Limited Minimax）**と、ゲームの進行途中で評価を行うための**評価関数（Evaluation Function）**について解説します。

---

## 深さ制限ミニマックスとは？

通常のミニマックスアルゴリズムは、ゲームの終局状態まで全ての可能な手を探索します。しかし、チェスや囲碁のような複雑なゲームでは、全ての状態を探索することは計算的に不可能です。例えば、チェスでは4手ずつの後に2880億以上の可能な状態が生まれます。このような状況では、従来のミニマックスは非現実的です。

### 解決策：深さ制限ミニマックス
深さ制限ミニマックスは、探索の深さを事前に制限することで、計算負荷を軽減します。
- **制限の設定**: 例えば「10手先まで」や「12手先まで」の状態を探索。
- **中途評価**: 深さ制限に達した時点でゲームが終了していない場合、その状態を評価関数を使ってスコア付けします。

---

## 評価関数の役割

### 評価関数とは？
評価関数は、ゲームが終局に至っていない状態で、その時点の盤面や状況をスコア化する関数です。このスコアは、ゲームの進行を推測し、どれだけ有利かを数値で表します。

例：
- **チェスのスコア**:
  - \(1.0\): 白が勝つ可能性が非常に高い。
  - \(-1.0\): 黒が勝つ可能性が非常に高い。
  - \(0.0\): 引き分け。

### 評価関数の精度とAIの性能
評価関数が正確であればあるほど、AIは優れた判断を下すことができます。逆に、評価関数が不正確であると、AIは誤った手を選ぶ可能性が高まります。

---

## 評価関数の具体例

### チェスの例
評価関数は、以下のような要素を考慮することが一般的です：
1. **駒の価値**:
   - ポーン: 1点
   - ナイト・ビショップ: 3点
   - ルーク: 5点
   - クイーン: 9点
2. **盤面のコントロール**:
   - 中央を支配している駒の数。
3. **その他の要素**:
   - キングの安全性、進行中の攻撃の有効性。

これらを総合的に評価し、現在の状態がどれだけ有利かをスコア化します。

---

## 深さ制限ミニマックスのアルゴリズム

1. **探索開始**:
   - 現在のゲーム状態から、最大深さ（例：10手）までの状態を探索します。
2. **評価関数を適用**:
   - 深さ制限に達した時点で、評価関数を使ってスコアを算出。
3. **スコアの伝播**:
   - 終局状態の場合は勝敗のスコアを使用。
   - 終局でない場合、評価関数のスコアを使用。

---

## 深さ制限ミニマックスのメリットと課題

### メリット
1. **計算負荷の軽減**:
   - 終局まで探索しないため、現実的な時間内で動作可能。
2. **柔軟性**:
   - 深さ制限や評価関数を調整してパフォーマンスを最適化。

### 課題
1. **評価関数の質**:
   - 不正確な評価関数は誤った決定につながる。
2. **深さの選択**:
   - 深すぎると計算時間が長くなり、浅すぎると正確な判断ができない。

---

## AIと知識推論

AIの探索アルゴリズムはゲーム以外にも応用されています。例えば：
- **道順探索**:
  - 出発地から目的地までの最短経路を見つける。
- **意思決定**:
  - どの行動を取るべきかを判断する。

これらの問題にも、評価関数や深さ制限を取り入れたアルゴリズムが有効です。

---

## 結論

深さ制限ミニマックスと評価関数は、複雑なゲームや問題解決におけるAIの基盤技術です。これらを適切に設計することで、計算負荷を軽減しながら、優れた性能を発揮できます。初心者の方は、まず単純なゲーム（例：〇×ゲーム）でこれらのアルゴリズムを実装し、評価関数の重要性を体感することをお勧めします。
入力: 明るさセンサ

### 背景
メイン基板にはFrontのRGB-LEDの傍に明るさセンサーが搭載されています。

![241204.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/103446/304d45d9-7c0d-2126-c419-a27434dbe134.png)

明るさセンサを入力として扱うプログラミングを行いました。
### Scratch
明るさセンサは取得した値を変数として扱いになっているので、値を取得する命令をするブロックがあるわけではないようです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/103446/95032d2d-1e8d-c507-27aa-29dd63dbf816.png)

「起動後にBackのLEDが緑色に点灯しているときに、もし明るさセンサを指で隠していたらFrontのLEDが青色に点灯する」

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/103446/93a22926-760d-8588-30cb-056daf7bf55f.png)

ifの前のディレイを入れないと動作が不安定でした。
明るさセンサの取得タイミングとif文の判定の順番に癖があるのかもしれません。

### spheroV2
testにあったBoltTest.pyのコメントアウトを参考に同様な動作をするスクリプトを作成しました。
この場合は、明るさセンサの取得タイミングとif文の判定の順番が分かりやすいです。
（厳密にget_luminosity()の先を調べたほうがよさそうです）

```
import time

from spherov2 import scanner
from spherov2.sphero_edu import EventType, SpheroEduAPI
from spherov2.types import Color

print("Testing Starting...")
print("Connecting to Bolt...")
toy = scanner.find_BOLT()

if toy is not None:
    print("Connected.")
    with SpheroEduAPI(toy) as droid:
        print("Testing Start...")
       
        droid.reset_aim()

        droid.set_back_led(Color(r=0, g=255, b=0))

        time.sleep(1)

        ambient_light_data = droid.get_luminosity()
        ambientLight = ambient_light_data['ambient_light']  # 辞書から値を取得
        print(f"Luminosity: {ambientLight:.1f}")

        if ambientLight < 10 :
            print("it is dark")
            droid.set_front_led(Color(r=0, g=0, b=255)) 
       
        time.sleep(1)

        print("Testing End...")
  
  #droid.register_event(EventType.on_sensor_streaming_data, droid.SensorStreamingInfo) #how you would register to data (function name is custom)
  
```

指で明るさセンサを隠していた時の実行結果はこちらのようになりました。
```
git\spherov2.py\spherov2\test>python BoltTest_ambientLight0.py
Testing Starting...
Connecting to Bolt...
Connected.
Testing Start...
Luminosity: 3.0
it is dark
Testing End...
```

### まとめ
明るさセンサを入力に使ったプログラミングを実験しました。
spheroV2は明るさセンサの値自体を表示する機能があるので、遊ぶ幅が広がりそうです。
neo-tree.nvimのsymbolがバグる

今まで
```vim
vim.fn.sign_define("DiagnosticSignError", { text = "", texthl = "DiagnosticSignError" })
vim.fn.sign_define("DiagnosticSignWarn", { text = "", texthl = "DiagnosticSignWarn" })
vim.fn.sign_define("DiagnosticSignInfo", { text = "", texthl = "DiagnosticSignInfo" })
vim.fn.sign_define("DiagnosticSignHint", { text = "", texthl = "DiagnosticSignHint" })
```

としていましたが，neovim 0.10から `vim.fn.sign_define`は非推奨となったようです．

これからは
```vim
vim.diagnostic.config({
  signs = {
    text = {
      [vim.diagnostic.severity.ERROR] = "",
      [vim.diagnostic.severity.WARN] = "",
      [vim.diagnostic.severity.INFO] = "",
      [vim.diagnostic.severity.HINT] = "",
    },
  },
})
```
としましょう．

参考 https://eiji.page/blog/neovim-diagnostic-config/
まず正確に高速にキーボードを打つことが大切な理由と方法

## 正確にキーボードを打てないと生まれそうな弊害

- キーボードと画面を交互に見ながら作業するので疲れる
- タイポが多く、修正時間が余分にかかる
- ホームポジションができていないので、ショートカットの配置が押しづらくなる
- ペアプロの際に入力に時間がかかり時間効率が下がり経験値を得る機会が減る
- 議事録を書くことに手一杯で要点をまとめきれない
 
## 正確にキーボードを打てると良くなること

- キーボードを打つために脳内メモリを使わないで済む
- タイポが減ることで、思考スピードに近い速さで入力できる
- 運指が良くなり、ショートカットも使いやすくなり作業効率がさらにアップする
- ペアプロにおいて入力スピードのギャップが減ってシニアプログラマとの作業がしやすくなる
- 議事録でいったん頭のなかで整理してアウトプットする余裕ができる


## ホームポジションの確認
これは対面で手元を見ないと気づきません。フルリモート環境で新人研修を行っている場合は意外な落とし穴かもしれません。
雑談のなかで、スペースやエンターをどこで押しているか、そもそもホームポジションを知ってる？と聞いてみるのがシンプルに近道です。


## タイピング速度、精度の向上の方法
[monkey type](https://monkeytype.com/) にアカウントを作って、就業前に5分やってもらいます。

5分でいいのか、少なくない？と思うかも知れませんが、 [やる気を出す方法を考えるのはムダでとりあえず動け](https://studyhacker.net/study-motivation)とのことなので、調子が悪くても乗り気じゃなくてもやれる時間をベースに考えています。
まずは5分。をファーストミッションにするといいです。

monkey typeの良いところは、
- ブラウザだけでできる
- 正誤率、速度がグラフで見やすい
- 難易度カスタマイズが豊富で飽きない。（秒数 `second`、単語数 `words`) 
- 無料


![CleanShot 2024-12-01 at 20.36.29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2883/bb03ba09-e95f-9032-5aee-232963899194.png)

## 修了レベルの目安
一定以上の速度と精度を身につけるための取り組みなので、ずっとやる必要はないです。

**`english 5k` `100 words` を 5回くらいやった時点で `avg accuracy 95%`以上、かつ、`45 wpm`以上が平均で出せてる** 

のであれば、あとは自己判断でやってねとするのでよいかと。

なんでも助走期間がいちばん難しいので、はじめのうちは1週間ごとにふりかえって、実施時間とグラフを見ながら状況を確認していくとよいです。

:::note info
ちなみにこのときの会話のなかで「スピードがなかなか伸びない」という相談を聞いてホームポジションがズレていることに気づいた。という経験があります（笑）
:::
深さ制限ミニマックスと評価関数：AIにおける知識推論の進化

# 深さ制限ミニマックスと評価関数：AIにおける知識推論の進化

以下の動画の、内容を要約しました。
https://youtu.be/5NgNicANyqM?si=Qc3Dzaw6gf3x5qmd

人工知能（AI）の分野では、ゲームや問題解決の際に効率的な探索アルゴリズムが重要です。本記事では、ミニマックスアルゴリズムの制限を克服する方法として、**深さ制限ミニマックス（Depth-Limited Minimax）**と、ゲームの進行途中で評価を行うための**評価関数（Evaluation Function）**について解説します。

---

## 深さ制限ミニマックスとは？

通常のミニマックスアルゴリズムは、ゲームの終局状態まで全ての可能な手を探索します。しかし、チェスや囲碁のような複雑なゲームでは、全ての状態を探索することは計算的に不可能です。例えば、チェスでは4手ずつの後に2880億以上の可能な状態が生まれます。このような状況では、従来のミニマックスは非現実的です。

### 解決策：深さ制限ミニマックス
深さ制限ミニマックスは、探索の深さを事前に制限することで、計算負荷を軽減します。
- **制限の設定**: 例えば「10手先まで」や「12手先まで」の状態を探索。
- **中途評価**: 深さ制限に達した時点でゲームが終了していない場合、その状態を評価関数を使ってスコア付けします。

---

## 評価関数の役割

### 評価関数とは？
評価関数は、ゲームが終局に至っていない状態で、その時点の盤面や状況をスコア化する関数です。このスコアは、ゲームの進行を推測し、どれだけ有利かを数値で表します。

例：
- **チェスのスコア**:
  - \(1.0\): 白が勝つ可能性が非常に高い。
  - \(-1.0\): 黒が勝つ可能性が非常に高い。
  - \(0.0\): 引き分け。

### 評価関数の精度とAIの性能
評価関数が正確であればあるほど、AIは優れた判断を下すことができます。逆に、評価関数が不正確であると、AIは誤った手を選ぶ可能性が高まります。

---

## 評価関数の具体例

### チェスの例
評価関数は、以下のような要素を考慮することが一般的です：
1. **駒の価値**:
   - ポーン: 1点
   - ナイト・ビショップ: 3点
   - ルーク: 5点
   - クイーン: 9点
2. **盤面のコントロール**:
   - 中央を支配している駒の数。
3. **その他の要素**:
   - キングの安全性、進行中の攻撃の有効性。

これらを総合的に評価し、現在の状態がどれだけ有利かをスコア化します。

---

## 深さ制限ミニマックスのアルゴリズム

1. **探索開始**:
   - 現在のゲーム状態から、最大深さ（例：10手）までの状態を探索します。
2. **評価関数を適用**:
   - 深さ制限に達した時点で、評価関数を使ってスコアを算出。
3. **スコアの伝播**:
   - 終局状態の場合は勝敗のスコアを使用。
   - 終局でない場合、評価関数のスコアを使用。

---

## 深さ制限ミニマックスのメリットと課題

### メリット
1. **計算負荷の軽減**:
   - 終局まで探索しないため、現実的な時間内で動作可能。
2. **柔軟性**:
   - 深さ制限や評価関数を調整してパフォーマンスを最適化。

### 課題
1. **評価関数の質**:
   - 不正確な評価関数は誤った決定につながる。
2. **深さの選択**:
   - 深すぎると計算時間が長くなり、浅すぎると正確な判断ができない。

---

## AIと知識推論

AIの探索アルゴリズムはゲーム以外にも応用されています。例えば：
- **道順探索**:
  - 出発地から目的地までの最短経路を見つける。
- **意思決定**:
  - どの行動を取るべきかを判断する。

これらの問題にも、評価関数や深さ制限を取り入れたアルゴリズムが有効です。

---

## 結論

深さ制限ミニマックスと評価関数は、複雑なゲームや問題解決におけるAIの基盤技術です。これらを適切に設計することで、計算負荷を軽減しながら、優れた性能を発揮できます。初心者の方は、まず単純なゲーム（例：〇×ゲーム）でこれらのアルゴリズムを実装し、評価関数の重要性を体感することをお勧めします。
なぜ、技術合宿をしたいのか

# はじめに
弊社は福岡の中小企業になります。
社員規模は20名に届かず、採用も中途がメインです。
そのような会社で、技術合宿を毎年、企画・提案しています。
今回は、なぜ技術合宿をしたいのか、を書きたいと思います。

# 技術合宿とは
一言でいうと、24時間耐久ハッカソンになります。

冒頭で「お題」を決めて、そこからは自由行動。
24時間後に再び集合し、各自が発表、評価しあう。
とてもシンプルなイベントです。

評価の観点は、
- 技術力(かっこいい、あたらしい、クール)
- アイデア
- ビジネス(もうけることができるか)
- デザイン、ユーザビリティ
- 完成度(どこまで実用化できているか。即リリース可能か)
となっています。


24時間以上時間を要するため、宿泊施設で行う必要があり、
結果として合宿のような形になっています。
→直近は、リモートでの開催です

# なぜ技術合宿なのか
弊社固有の理由もあるのかもしれません。

## 仕事ではなく、自分の好きなものを作りたい
私だけかもしれませんが、
仕事ではない時間で、仕事ではない好きなものを作る、というのは楽しいです。

ただし、
休日は平日の疲れを癒したり(夜更かしからの寝坊)、家族と過ごしたりと、
なかなかそういう時間は作れないですし、
仕事の後とか休みの日に、自発的に「今日はこれを作ろう！」ってなりにくいですよね。

会社での合宿というイベントにすることで、
参加しなきゃという何かしらの力(義務感ではないんですが、何なんでしょうね？)が、
最初の一歩を後押ししてくれます。
あくまで自由参加ですし、会社は環境を提供するだけなんですがね。

## 多様なメンバーゆえにシナジーが生じやすい
エンジニアといっても、いろんなエンジニアがいますよね。

弊社では30代未経験で中途採用されるケースもあります。
その場合、その後のキャリアは、技術をとことん極める方もいれば、
ひととおり技術を習得後、新しいサービスを企画、提案するような仕事をしたい、
という方もいます。

進む方向が違うメンバーでも、この合宿では、
同じテーマをもらって、それをどう実現するのか、というスタートとゴールは同じです。
ただし、ゴールに至る過程は全然異なると思います。

アイデアで魅せるのか、
技術力で魅せるのか、
プレゼンで魅せるのか。

お互いに発表し、お互いに評価することにより、
自分の不足部分を感じることもできますし、
自分の強みを再度理解することもできます。

様々なメンバーがいるからこそ、このイベントに意味があると考えています。

なお、直近開催時のテーマは「犬島(岡山県)」でした。
無茶ぶりすぎましたが、各自でしっかり解釈して、テーマに沿った成果物を出してくれたのはさすがでした。


## 合宿ならではの楽しさ
先にも書きましたが、合宿は宿泊施設で行います。
いうなれば、プチ旅行になります。
旅行という非日常の中で、考えながら好きなモノをつくる、
っていうのは、やはりわくわくしてしまいます。

メンバーはそれぞれ自由行動ですので、
食事をとるタイミングや、入浴、睡眠のタイミングもバラバラです。
ただ、タイミングが合えば、一緒にご飯を食べることもあります。
そのまま軽くお酒を飲んだり、がっつり飲んだりも自由なのです。

個人的には夕方までに集中してある程度作りきってしまい、
夕方から入浴(サウナ)を満喫して、しこたま飲んで、ぐっすり寝る。
翌朝早起きして、テストとプレゼン資料を作るという流れにしています。


# 最後に
今年は合宿の企画ができなかったので、
来年は必ず企画提案を行いたいです！
ミニマックスアルゴリズムと最適化：初心者向け解説

# ミニマックスアルゴリズムと最適化：初心者向け解説

以下の動画の、内容を要約しました。
https://youtu.be/5NgNicANyqM?si=Qc3Dzaw6gf3x5qmd
ミニマックスアルゴリズムは、二人プレイのゼロサムゲーム（例：〇×ゲームやチェス）で、最適な手を決定するために使用されます。このアルゴリズムは、対戦相手の動きを考慮しながら、最善の戦略を見つけるための重要な考え方です。本記事では、ミニマックスアルゴリズムの基本から効率的な計算方法（アルファベータ枝刈り）まで、初心者でも理解できるように解説します。

---

## ミニマックスアルゴリズムとは？

### 基本概念
ミニマックスアルゴリズムでは、以下の原則に基づいてゲームの手を選びます：
1. **最大化プレイヤー（Max Player）**:
   - 自分のスコアを最大化することを目指します。
2. **最小化プレイヤー（Min Player）**:
   - 相手のスコアを最小化することを目指します。

これにより、両プレイヤーは互いに最適な手を選択しようとし、最終的に最善の結果が得られると仮定します。

---

## アルゴリズムの流れ

### 1. **終了状態の確認**
まず、現在の状態がゲーム終了状態（勝敗が決まった状態）かどうかをチェックします。終了状態であれば、その状態の「ユーティリティ値（勝敗を示す数値）」を返します。

### 2. **再帰的な探索**
ゲームが終了していない場合、次に取れるすべての手を調べ、それぞれの手に対して結果を計算します：
- **最大化プレイヤー（Max Player）**:
  - 現在の状態から得られるスコアの中で最大値を選択します。
- **最小化プレイヤー（Min Player）**:
  - 現在の状態から得られるスコアの中で最小値を選択します。

### 3. **値の更新**
最大化プレイヤーの場合：
- 最初にスコア \( v \) を \(-\infty\) に設定し、可能な手すべてをループします。
- 各手の結果を計算し、現在の \( v \) と比較してより大きい値を選択します。

最小化プレイヤーの場合：
- スコア \( v \) を \(+\infty\) に設定し、可能な手すべてをループします。
- 各手の結果を計算し、現在の \( v \) と比較してより小さい値を選択します。

---

## アルゴリズムの課題

ミニマックスは全ての可能な手を探索するため、計算コストが非常に高くなります。特に、以下の場合に問題が発生します：
1. **ゲームが複雑な場合**:
   - 例：チェスでは、わずか4手で2880億通り以上の可能性が生じます。
2. **ゲームの深さ**:
   - 手数が増えるごとに探索の木が指数的に増大します。

---

## アルファベータ枝刈り（Alpha-Beta Pruning）による最適化

### アルファベータ枝刈りとは？
アルファベータ枝刈りは、ミニマックスアルゴリズムの探索範囲を効率的に減らす手法です。**「計算する必要のない部分を早めに省く」** ことで、計算時間を大幅に短縮します。

### 基本的な考え方
1. **アルファ値（α）**:
   - 最大化プレイヤーが保証できる現在の最大値。
2. **ベータ値（β）**:
   - 最小化プレイヤーが保証できる現在の最小値。

これらの値を使い、以下のように探索範囲を制限します：
- **最大化プレイヤー**:
  - 現在の値がベータ値を超えた場合、それ以上の探索は無意味です。
- **最小化プレイヤー**:
  - 現在の値がアルファ値を下回った場合、それ以上の探索は無意味です。

### 具体例
次のような状況を考えてみましょう：
- **最大化プレイヤー**（緑矢印）:
  - 3つの手（左、中、右）から選択します。
- **最小化プレイヤー**（赤矢印）:
  - 各手に対してさらに3つの選択肢があります。

#### ステップ1: 左の手を計算
- 最小化プレイヤーは、\(4, 8, 5\) のうち最小値 \(4\) を選びます。
- 最大化プレイヤーにとって、この手のスコアは \(4\) です。

#### ステップ2: 中央の手を途中で省略
- 最小化プレイヤーの選択肢が \(9, 3, 7\) の場合、\(3\) が見つかった時点で計算を省略できます。
- なぜなら、最大化プレイヤーにとって \(4 > 3\) なので、この手を選ぶ理由がありません。

#### ステップ3: 右の手も省略
- 同様に、右の手のスコアが最大でも \(2\) である場合、最大化プレイヤーはこの手を選びません。

---

## アルファベータ枝刈りの効果

### 時間効率の向上
アルファベータ枝刈りを使うことで、探索するノードの数を大幅に削減できます。これにより、複雑なゲームでも現実的な時間内で解を見つけやすくなります。

### 限界
それでも、ゲームが非常に複雑な場合（例：チェスや囲碁）、全ての状況を探索するのは難しいため、さらなる最適化や問題の簡略化が必要です。

---

## まとめ

ミニマックスアルゴリズムは、ゲームAIの基礎となる強力な手法ですが、計算コストが高いという課題があります。そのため、アルファベータ枝刈りのような最適化手法を組み合わせることで、効率的に動作させることが可能です。初心者の方は、まず〇×ゲームのような単純なゲームでこれらのアルゴリズムを試してみると良いでしょう。その後、チェスやその他の複雑なゲームへの応用に挑戦してみてください。
ハッカソンで開発するときに気を付けること（短期開発編）

## はじめに

### 🎄JPHACKS Advent Calendar 2024🎄

本記事は，[JPHACKS Advent Calendar 2024](https://qiita.com/advent-calendar/2024/jphacks) の１日目の記事です．是非，他のカレンダーもご覧ください．

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

### JPHACKSとは？

[JPHACKS](https://jphacks.com/) は，「日本最大級の学生向けハックイベント」です．

https://jphacks.com/

全国８会場で Hack Day (予選) が行われ，選ばれた15チームが Award Day (本戦) に進出することができます．
2024年は，10/26 ~ 10/27 に Hack Day, 11/17 に Award Day が開催され，延べ約100チーム，400名以上の学生が参加したそうです．

筆者は「Eventpix」チームとして出場し，以下の賞を受賞しました．

* Hack Day
    * Best Hackday Award (大阪会場での最優秀賞)
    * Sponsor Award (株式会社江崎グリコ様)
    * Finalist Award (本戦への出場権)
* Award Day
    * Innovator認定 (上位数チームが得られる賞)
    * Sponsor Award (株式会社Galirage様)

作成したプロダクトは，[こちら](https://github.com/jphacks/os_2407) の GitHub リポジトリをご覧ください．

https://github.com/jphacks/os_2407

### 本記事について

本記事では，充実したJPHACKSの中でも 2日のみでプロトタイプを実装するハッカソン「Hack Day」に限定し，
**短期間でどのように良いプロダクトを作り上げるのか** について個人的な感想を書こうと思います．（あくまでハッカソン初心者の意見です）

## 短期間でどのように良いプロダクトを作り上げるのか

### ChatGPTを頼りまくる

正直これに尽きると思っています．10時間ほどしかない開発時間で実装をいちいち調べている暇はありませんでした．開発時間の密度を濃くするためにも，コーディングで迷ったらとりあえずChatGPTに聞くということを意識すると，時間をフル活用できました．特に，調べたいことをうまく言語化できない，検索する単語がわからないというときはChatGPTが大活躍しました．

ただし，**「ChatGPTが出力したコードは必ず読んで最低限理解する」** ということを意識しました．ChatGPTに頼り切ってしまうと，そのコードを改変するときに理解するフェーズが必要で追加で時間がかかってしまいます．個人的に理解したうえで実装したいこともあり，ChatGPTはあくまで「超高速な検索ツール」として使用していました．

### 環境構築を事前に完了させる

環境構築が最も時間がかかりました．特にインストール系は事前に完了させておくべきだと感じました．会場のネットワークが最強とは限らないので，思い通りにインターネットを利用できないこともありました．特にモバイル開発は，エミュレータのインストールで数GBのダウンロードが必要なことも...

開発期間は新規開発に注力するためにも，環境構築までは事前に完了させるべきです．

### 「プロダクトが何を解決するのか」を全力でアピールする

ハッカソンに参加する人はやはり開発が好きな人が多いので，発表で「何を実装したか」という機能説明に時間を割きがちです．自分も正直そのタイプの人間でした．ただしハッカソンで求められているのは実装力の強さだけではなく，そのプロダクトがもつ価値が大きいと考えています．特にJPHACKSの場合，Hack Day の発表時間は90秒しかなく，事前まで開発を全力で行っていたので，機能の説明だけして時間切れということもかなりありました．

著者のチームで開発した「Eventpix」は予定入力の手間を削減することをテーマにしているのですが，著者が発表するときは，機能説明もそこそこに **「たった５タップでいい！！」** ということを猛プッシュしていました．賭けの部分はありましたが，プロダクトの価値や魅力が伝わったことで素晴らしい賞がいただけたと考察しています．

### スポンサーに合わせたプロダクトを作る

やはりイベントに出場する以上，何らかの賞品は持って帰りたいものです．JPHACKSではスポンサー毎に賞とその審査基準を用意しています．ハードウェアや自社APIなど，何らかの制限を付けているところもかなりありました．それらから着想を得てプロダクトのコンセプトを練り，スポンサーに ~~媚びる~~ 全力アピールしていくことで，賞を得られやすくなると思います．

著者らのプロダクトはスポンサー向けに調整はしていませんでしたが，魅力を全力でアピールしたこともあり，Hack Day と Award Day でそれぞれ１社ずつ Sponsor Award をいただくことができました．やっぱり形に残る賞や景品を頂けることは，大きなモチベーションになります．次回ハッカソンに参加するときは，欲しい景品に合わせてプロダクトを作成してみようと思います．

## 最後に

記事を読んでいただきありがとうございました．

とりあえず思いつくものを書いてみました．新たな案が出てきたら，再度まとめなおすかもしれません．
１回参加しただけの初心者が生意気な口きいてすみません...
誰かの参考に少しでもなれば幸いです．

これらの知見はやはり参加してみないとわからないことばかりでしたし，不安ながらもとりあえず参加したことで，多くの経験やつながりを得ることができました．

この記事を読んでいただいた方で，ハッカソンにチャレンジしてみたい方は，**とりあえず参加ボタンを押してみましょう！**
そこからどうするか悩めばいいと思います．
初心者向け：アルゴリズムとヒューリスティック探索の最適化

# 初心者向け：アルゴリズムとヒューリスティック探索の最適化

以下の動画の、内容を要約しました。
https://youtu.be/5NgNicANyqM?si=Qc3Dzaw6gf3x5qmd

この記事では、特にプログラミング初心者に向けて、探索アルゴリズムの進化についてわかりやすく解説します。今回は、「グリーディ最良優先探索」から「A*（エースター）探索」への改良について取り上げます。これらは、問題を効率的に解決するための重要な手法です。

---

## グリーディ最良優先探索とは？

### 概要
グリーディ最良優先探索（Greedy Best-First Search）は、**「ゴールまでの推定距離が最も短いノードを優先的に探索する」** アルゴリズムです。この「推定距離」は「ヒューリスティック関数（heuristic）」を使って計算されます。

### 特徴
- **長所**: 探索範囲を狭め、効率よくゴールに近づく。
- **短所**: 最適解（最短経路）を保証しない。

### 問題点の例
グリーディ最良優先探索は、局所的には最良の選択をするものの、**全体的に最適でない解**を導く場合があります。

例として、以下のような迷路を考えてみましょう：
- **現在地 A** から **ゴール B** へ進むときに、ヒューリスティックに基づいて「ゴールまでの距離が短い」と見えるルートを選びます。
- しかし、実際には、遠回りのように見えるルートのほうが少ないステップでゴールに到達できる場合があります。

---

## A*（エースター）探索の登場

グリーディ最良優先探索の課題を解決するために、「A*探索」という改良版アルゴリズムが登場します。A*探索では、ゴールまでの推定距離（ヒューリスティック）だけでなく、**現在の位置に到達するまでのコスト（実際にかかった距離）**も考慮します。

### A*探索の基本原理

- **評価関数**: A*探索では、次の式を使います：
  \[
  f(n) = g(n) + h(n)
  \]
  - \( g(n) \): 現在の位置に到達するまでのコスト（過去のコスト）。
  - \( h(n) \): ゴールまでの推定距離（ヒューリスティック値）。

### 例
迷路の各ノードに以下のような値が付与されているとします：
- 現在の位置 \( A \) までのコスト \( g(A) = 5 \)。
- ゴールまでの推定距離 \( h(A) = 10 \)。
- この場合、評価値 \( f(A) = g(A) + h(A) = 15 \)。

---

## A*探索の利点

1. **最適性**
   - A*探索は「ヒューリスティック関数」が正しく設計されていれば、最適解（最短経路）を保証します。
   - これを実現するには、ヒューリスティックが以下の条件を満たす必要があります：
     - **許容性（Admissibility）**: ヒューリスティック値が常に「実際のコスト」を過大評価しない。
     - **一貫性（Consistency）**: ヒューリスティック値が状態間で矛盾しない。

2. **効率性**
   - 不要な探索を減らし、ゴールに向かう最適なルートに集中します。

---

## プログラムの実装概要

以下は、PythonでのA*探索アルゴリズムの基本的な流れです：

1. **初期化**
   - \( g \): 各ノードのコストを無限大に設定。
   - \( f \): 評価値を計算するための辞書を用意。
   - 開始地点の \( g \) 値を 0 に設定し、\( f \) を計算。

2. **探索ループ**
   - 開始地点からスタート。
   - 未探索のノードから評価値 \( f \) が最小のノードを選択。
   - ゴールに到達したら終了。

3. **ノードの更新**
   - 隣接ノードを調べ、\( g \) 値と \( f \) 値を更新。
   - 必要に応じて優先度付きキューに追加。

---

## A*探索の課題と改良の可能性

- **ヒューリスティックの設計**
  - 問題に適したヒューリスティックを作ることが鍵となります。例えば、迷路の場合、「マンハッタン距離」や「ユークリッド距離」がよく使われます。
  - より複雑な問題では、問題の特性を深く理解する必要があります。

- **メモリ使用量**
  - A*探索は多数のノードを記録するため、メモリ消費が大きくなることがあります。
  - この課題に対処するため、メモリ効率を改善したバリエーション（例：IDA*探索）が提案されています。

---

## まとめ

A*探索は、グリーディ最良優先探索を改良したアルゴリズムであり、ゴールまでの最短経路を見つける能力に優れています。しかし、その性能はヒューリスティック関数の質に大きく依存します。初心者の方も、まずは迷路の問題など簡単なシナリオでA*探索を試してみると、その効果を体感できるでしょう。
Rustで多態性を表現する（静的ディスパッチ）

Rustでプログラミングをしているとオブジェクト指向のように多態性を表現したくなります
よくある動物が鳴くやつを`trait`で実現してみます

```diff_rust
/// 鳴くトレイト
trait Bark {
    fn bark(&self) -> ();
}

/// 犬
struct Dog;
impl Bark for Dog {
    fn bark(&self) -> () {
        println!("わんわん!");
    }
}

/// 猫
struct Cat;
impl Bark for Cat {
    fn bark(&self) -> () {
        println!("にゃーにゃー!");
    }
}
```

これをオブジェクト指向よろしく扱ってみます
``` diff_rust
fn main() {
    let mut animal: Box<dyn Bark> = Box::new(Dog);

    animal.bark(); // "わんわん！"

    animal = Box::new(Cat);

    animal.bark(); // "にゃーにゃー！"
}
```

ここで気になるのが動的ディスパッチになっていることです
`Box<dyn Bark>`のところですね
トレイトオブジェクトを呼び出す際にメソッドを解決するのに実行コストがかかるというのが定説です(静的ディスパッチ比)

そういわれるとなんとなく避けたいなぁとなってしまうのが人情でしょう（？）
動的ディスパッチを避けるためには`dyn Bark`を使用しないようにしないといけません

そこで最近覚えたのがenumによるラップです
以下のようにenumを宣言します
``` diff_rust
enum Animal {
    Dog(Dog),
    Cat(Cat)
}
impl Bark for Animal {
    fn bark(&self) -> () {
        match self {
            Animal::Dog(inner) => inner.bark(),
            Animal::Cat(inner) => inner.bark(),
        }
    }
}
```

`enum Animal`を定義して`Dog`や`Cat`と同様に`Bark`トレイトを実装し、
それぞれのパターンごとに`bark()`を実行するわけです
これにより動的解決が回避され、静的ディスパッチになります

あとは以下のように呼び出せばよいですね
```diff_rust
    let mut animal: Animal = Animal::Dog(Dog);

    animal.bark(); // "わんわん！"

    animal = Animal::Cat(Cat);

    animal.bark(); // "にゃーにゃー！"
```

これで静的ディスパッチが行えるようになりました
やはり動的ディスパッチと比べると一手間かかってしまうのが難点ですが、
パフォーマンスが大事なシステムなどでやっておくに越したことはないでしょう（？）

上記のやり方であればオブジェクト指向らしくデータと処理をまとめておけるので、
処理の見通しもよく、メンテもしやすいんじゃないでしょうか
ほかのやり方もあるかもしれないのでもっと探究していきたいですね🚀

[今日のplayground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f4107b7df6461e96a51463c49516eb0e)
宇宙探索アルゴリズムの解説：深さ優先探索（DFS）と幅優先探索（BFS）の比較、そして改良案


以下の動画の、内容を要約しました。
https://youtu.be/5NgNicANyqM?si=Qc3Dzaw6gf3x5qmd

# 宇宙探索アルゴリズムの解説：深さ優先探索（DFS）と幅優先探索（BFS）の比較、そして改良案

宇宙探索や迷路解決のアルゴリズムとしてよく用いられる **深さ優先探索（DFS）** と **幅優先探索（BFS）** は、それぞれ異なる特性とトレードオフを持っています。本記事ではこれら2つのアルゴリズムを比較し、さらに効率的な探索方法について検討します。

---

## 深さ優先探索（DFS）とは？

DFSは、初期状態から最も深い状態まで一つのパスを辿り、行き止まりに到達すると元に戻って別のパスを探索する方法です。このアルゴリズムは「スタック」をデータ構造として使用し、最後に追加されたノードを優先的に探索します。

### 特徴

- **長所**: メモリ消費が少ない（探索時に記録するノードが少なくて済む）。
- **短所**: 最適解が見つからない場合がある（回り道を選択する可能性がある）。

### 例

迷路内でゴールを目指す場合、DFSは一つの方向に突き進み、行き止まりに到達すると別の道を探索します。このため、効率的な経路を見つけるのではなく、遠回りをする可能性があります。

---

## 幅優先探索（BFS）とは？

BFSは、初期状態から近い順にすべてのノードを探索する方法です。「キュー」をデータ構造として使用し、最初に追加されたノードを優先的に探索します。

### 特徴

- **長所**: 最短経路（最小コストの解）を見つけやすい。
- **短所**: メモリ消費が大きい（探索範囲が広がるため、記録するノード数が増える）。

### 例

迷路内でゴールを目指す場合、BFSは初期位置から近いノードを順に探索し、効率的な経路を見つけることができます。ただし、探索範囲が広がると多くの無関係なノードも調べるため、メモリを多く使用します。

---

## DFSとBFSのトレードオフ

DFSは少ないメモリで実行可能ですが、最短経路を保証しません。一方、BFSは最短経路を見つける可能性が高いですが、探索範囲が広がるとメモリを大量に消費します。この違いにより、用途や問題の特性に応じて適切なアルゴリズムを選択する必要があります。

---

## 改良案：ヒューリスティックを用いた探索

DFSやBFSの課題を解決するために、問題特有の知識を活用した「ヒューリスティック探索」が有効です。この方法では、探索するノードを選ぶ際に「ゴールへの推定距離」を利用します。

### 1. **グリーディ最良優先探索（Greedy Best-First Search）**

このアルゴリズムでは、ゴールに最も近いと思われるノードを優先して探索します。距離の推定には、以下のような方法を使います：

- **マンハッタン距離**: ゴールまでの垂直・水平距離を合計した値。
- **ヒューリスティック関数**: \( h(n) \) という数値で、ノード \( n \) がゴールにどれだけ近いかを評価。

#### 特徴

- **長所**: 探索範囲を絞り込み、効率的な経路を見つける。
- **短所**: 最適解を保証しない場合がある（推定が間違っていると回り道を選択する）。

#### 例

迷路内でゴールを目指す際、右方向に進む方がゴールに近いと推定できる場合、右のノードを優先して探索します。この方法により、不要な探索を減らし効率化が図れます。

---

## プログラムの実装

### 基本構造

以下はPythonでの迷路解決プログラムの概要です：

1. **ノードの定義**:
   - 状態、親ノード、アクションを記録。
   - パスコストは後から計算。

2. **データ構造**:
   - スタック（DFS）またはキュー（BFS）を使用。
   - グリーディ探索ではヒューリスティック関数を追加。

3. **探索アルゴリズム**:
   - 初期ノードをフロンティアに追加。
   - ループ内でノードを取り出し、ゴールテストを実行。
   - ゴールに到達しない場合、隣接ノードを追加。

---

## 結論

DFSとBFSは、それぞれ異なる状況に適した探索アルゴリズムです。さらに効率を追求する場合、ヒューリスティックを活用したグリーディ探索のような手法を検討すべきです。特に迷路のような問題では、問題特有の知識を反映したアルゴリズムが有用であり、探索効率を大幅に向上させる可能性があります。
宇宙探索の基礎を学ぶ：CS50のPythonによるAI入門


以下の動画の、内容を要約しました。
https://youtu.be/5NgNicANyqM?si=Qc3Dzaw6gf3x5qmd


# 宇宙探索の基礎を学ぶ：CS50のPythonによるAI入門

ハーバード大学が提供する「PythonによるAI入門（CS50’s Introduction to Artificial Intelligence with Python）」は、現代の人工知能（AI）の基礎となる概念やアルゴリズムを学ぶことができる革新的なコースです。このコースでは、ゲームプレイエンジン、手書き認識、機械翻訳などの技術を支える理論を掘り下げて学びます。

## コースの概要

このコースは、CS50（ハーバード大学のコンピュータサイエンス入門）の次のステップとして設計されています。Brian Yu講師の指導のもと、AIの基礎を形成する重要なアイデアや技術を学びます。主な内容は以下の通りです：

1. **問題解決のための探索アルゴリズム**  
   AIがどのように問題を解決するかを探索アルゴリズムを通じて学びます。たとえば、ゲームの最適な手を見つける方法や、地図アプリが最短ルートを計算する仕組みについて解説します。

2. **情報の表現と推論**  
   AIが確実な情報と不確実な情報をどのように表現し、そこから新しい結論を導き出すかを学びます。

3. **最適化の問題**  
   コスト削減や利益最大化といった目標を達成するために、AIが複雑な最適化問題をどのように解決するかを学びます。

4. **機械学習とニューラルネットワーク**  
   データや経験を基に学習するAIの仕組みを学びます。特に人間の脳の構造をモデルにしたニューラルネットワークの仕組みを掘り下げます。

5. **自然言語処理（NLP）**  
   AIが人間の言語を理解し、解釈する方法を学びます。これは、AIが人間と自然な形で対話できるようになるための重要な分野です。

---

## 探索アルゴリズムの詳細

コースの冒頭では、「探索」の概念に焦点を当て、AIが問題解決にどのようにアプローチするかを学びます。以下の用語が登場します：

- **エージェント**: 環境を認識し、それに基づいて行動を起こす存在。たとえば、迷路を解くAIや、タイルパズルを解くプログラムが該当します。
- **状態**: エージェントとその環境の特定の構成を指します。
- **行動**: ある状態から別の状態へ移動する選択肢。
- **遷移モデル**: 状態と行動の関係を定義するモデル。これにより、ある状態で特定の行動をとった際にどの状態に移るかが決まります。
- **目標テスト**: 目標状態に到達したかを確認する基準。
- **パスコスト**: 各経路のコストを数値で表したもの。たとえば、移動時間やエネルギー消費量が該当します。

---

### 例：スライドパズルと探索

スライドパズルを例にとり、AIが初期状態から目標状態へ到達する方法を探る過程を学びます。この問題を解決するために、以下のようなアプローチを使用します：

1. **探索アルゴリズムの設計**:
   - フロンティア（探索候補）に初期状態を追加。
   - 現在の状態から可能な行動を評価。
   - 目標状態に到達するまで、このプロセスを繰り返す。

2. **効率性の向上**:
   - すでに探索済みの状態を記録する「探索セット」を活用。
   - 同じ状態を再探索する無駄を防止。

3. **深さ優先探索と幅優先探索**:
   - 深さ優先探索（DFS）は探索の深い部分を優先して進めるアルゴリズム。
   - 幅優先探索（BFS）は浅い部分を優先し、目標に近い解を見つけやすいアルゴリズム。

---

## 機械学習とAIの応用

探索アルゴリズムを理解した後、コースは機械学習の基本に進みます。たとえば、メールのスパムフィルタリングや、ニューラルネットワークを使用したパターン認識など、データに基づいてAIが学習する方法を学びます。また、AIが自然言語をどのように処理し、解釈するかについても深く掘り下げます。

---

## このコースの魅力

このコースでは、理論的な知識を学ぶだけでなく、実際にAIプログラムを構築する機会も提供されます。探索アルゴリズムから機械学習、自然言語処理まで、AIのさまざまな側面を包括的に学ぶことができる内容です。

Brian Yu講師の指導のもと、人工知能の世界を深く探求する準備を整えましょう。このコースは、AIの基礎を学び、将来の技術革新に貢献するための第一歩となるでしょう。
ReactのuseEffectについて

## インターフェース説明
- useEffectはReactのHook関数であり、Reactコンポーネント内でイベントによるものではなく、レンダリングそのものによって引き起こされる操作（副作用）を作成するために使用されます。たとえば、AJAXリクエストの送信やDOMの変更などが含まれます。

- ページのレンダリング後、またはページ内のコンポーネントに変化があった際に実行される操作として理解できます。

- 第1引数は関数で、副作用関数と呼ぶことができます。この関数内に実行したい操作を記述します。  
- 第2引数は配列（省略可能）で、この配列に依存項を指定します。異なる依存項が第1引数の関数の実行に影響を与えます。配列が空の場合、副作用関数はコンポーネントのレンダリング後に一度だけ実行されます。

## 使用方法


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3916068/f58f7a36-3b4d-9b68-d877-e6d065148967.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3916068/98bb078f-6886-d815-b5ab-4257a478f0a0.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3916068/1d5f230a-a3d5-2737-0d9e-aa23a1137df0.png)


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3916068/195072ff-3f6d-bd6a-7724-19229d0fcf28.png)


## 依存項

- useEffectの副作用関数が実行されるタイミングは、指定された依存項によって異なります。
- 依存項	副作用関数の実行タイミング
- 依存項なし	コンポーネント初期レンダリング＋更新時
- 空の配列	初期レンダリング時に1回のみ実行
- 特定の依存項あり	初期レンダリング＋依存項が変化した時
地方のノンIT界隈サラリーマンがマナビDXで異世界転生並みにスキルチェンジした話

# 昨日の今日で今度はマナビDXクエストで人生変わった話である。

だって待ってても誰も2日目書かないから全然需要のなさそうなお話でお茶濁すけど勘弁してね。

# お前だれよ？
46歳非ＩＴ系製造業に努める会社員です。

# 何書くの？
マナビDXクエストに参加したら3年目で人生変わった話よ。

中年の危機に悩む同世代のみんな、生きる道は自分で探そうよ。

エクセルの関数からでもいいよ、今、これを読んでるスマホでもいい、何でもいいから今からでも1歩ずつ階段上がってスキルを手に入れようよ。

# マナビDXクエストに参加して、例えばこんなコードが書けるようになったよ。

```js

function getRSSitems(){
  const ss = SpreadsheetApp.getActiveSpreadsheet();
  const sheets = ss.getSheets();

  const itemList = [];
  for (let i=0;i<5;i++){
    const values = sheets[i].getDataRange().getValues();
    itemList.push(values);
  }
  const flat = itemList.flat()
  flat.filter(x => x[0] != "");
  console.log(flat);
  return flat
}

function setValues(){

  const ss = SpreadsheetApp.getActiveSpreadsheet();
  const sh = ss.getSheetByName("conclusion");
  const clearrow = sh.getLastRow();
  sh.getRange(1,5,clearrow,7).clear();
  const setValues = getRSSitems()
  setValues.map(x => x[3].toString().replace(/\r?\n/g, ''))

  const rows = setValues.length;
  const columns = setValues[0].length;

  //セットする座標を取得する。
  const lastRows = sh.getDataRange().getLastRow();
  
  sh.getRange(lastRows+1,1,rows,columns).setValues(setValues);
  sh.getDataRange().removeDuplicates();

  //arrayformulaセットのために、E:K列をクリアする。
  //lastrowを改めて取得する。
  const lastRows_add = sh.getLastRow();
  
  sh.getRange(1,5).setValue('=iferror(arrayformula(split(C1:C,", ")),"")')
  sh.getRange(1,11).setValue('=iferror(arrayformula(date(H1:H,VLOOKUP(G1:G,$N$1:$O$12,2,false),F1:F)),"")')
  
  const allRecords = sh.getDataRange().getValues();
  const setRecors = allRecords.filter(x => x[0] != '');
  sh.getDataRange().setValues(allRecords);
  const row = setRecors.length;
  const sortRange = sh.getRange(1,1,row,11);
  sortRange.sort({column: 11,ascending: false});
  
  
}
```

スプレッドシートに標準装備されているimportfeed関数で入手したニュース記事をGASでスプレッドシートにテキスト貼り付けして毎日トリガー実行すると、何もしなくても自分のスプレッドシートにニュースがたまっていく仕組みです。
こんな感じ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1167883/e9c01564-97c7-2f1d-ee85-8b6429ff654b.png)

なんんちゃってスクレイピングで、それほどコード量も多くなく、可能な限り初心者にわかりやすいように標準関数に仕事をさせるコードも書いてます。

この辺とか。
```js
sh.getRange(1,5).setValue('=iferror(arrayformula(split(C1:C,", ")),"")')
  sh.getRange(1,11).setValue('=iferror(arrayformula(date(H1:H,VLOOKUP(G1:G,$N$1:$O$12,2,false),F1:F)),"")')
```

こうしたコードはある程度の要望を伝えると生成AIが書いてくれるかもしれません。

ですが、自分はこれを自分で書けるようになりたかった。

# 最高の学習効果はアウトプットって本に書いてあるよ。

マナビDXクエストに参加すると自主的にスキルを共有する宣言をするとすぐに人が集まったくれます。
自分自身、周囲にICT界隈の集まりに参加できる物理的環境が無いためこれはとてもありがたい。

書いたコードを開陳して、動作を見せて、人から感想をもらう。
何これ超楽しい。

人に教える、伝えるためにはそれそのものを自分のものにしなければなりません。
だから真剣味が違う。

おかげで、標準的な教本には載ってない、受けの良い実務に即したGASコードのアイデアをいろいろと思いつくことができました。

例えば、本記事で紹介したimportfeed関数、記事タイトルだけでも取得してその都度GoogleCalendarの終日イベントとして登録しておけば、カレンダー表示で記事のヘッドラインを集積することができます。

トレンドを追うものの、なかなか俯瞰できない忙しい人には振り返りもかねて使い勝手の良いツールとして重宝するんじゃないでしょうか。

こうした細かいTipsを積み重ねて職場の半径5mで改善活動を続けていた結果、今はこうした改善をもう少し大きなスケールで実行できそうな位置にポジションチェンジすることになりました。

エクセルのIF関数すら覚束なかったころからすると、ちょっと考えられない状況ですが、やりがいと手ごたえを感じる毎日です。

昼は会社員、夜はマナビのメンツと丁々発止。

ワイガヤで生まれた素人コードが仕事のベクトルを変えてくれる、そんな日があなたにも訪れますように。

いつでも待ってるよ！
起業するならElixirシリーズSTEP5. コンテンツを作れ

## コンセプト設計
前回はコンセプトを作れという事でターゲットを決めて、仮説を作り検証するためのアンケートをお願いしました。これは実際にどれくらい集まるかは読んでくださっている皆さんのご協力次第です。

もし、ある程度集まってきたらこのシリーズは、本格的に起業したい人むけの教材としては、リアルなデータと共に、そして皆さんと共に作り上げていくシリーズとして筆者も楽しみです。

と同時に集まらなかったら、とても寂しいです。笑（恥ずかしくても、リアルをお見せしていきたいと思います）

という事で、コンセプト作りはアンケートの結果が集まるまでもう少し、おいておき
仮に順調に コンセプトが決まったら次に何をするのかについてお伝えしていきます。

ちなみに、コンセプト作成は「起業」の中で一番大事で一番大変なところです。結構時間をかけて良い所です。

## コンテンツ作成

さて、コンセプトが決まったらコンテンツを作りましょう。ここで言うコンテンツの作成とは、設計に当たります。あくまで設計なので中身を全部作成するわけではありません。

基本的に、お客様を集めて、販売し、継続的に購入してもらう状態が望ましいです。コンセプトがしっかりしていると、お客様を集める事ができます。次に継続してもらう為には購入してもらったサービスや製品がお客様にありがとうと言われるから継続に繋がるベースが作れるわけです。

そこで、ありがとうと言われる為の設計をする必要があります。

無事に購入してもらったら、どのような提供方法をするのが「ありがとう」と言われるのか？
何を提供すると「ありがとう」と言われるのか？
商品を知ってもらい、購入してもらい、提供して、支払ってもらい、最後にアンケートをしてもらい。すべてのプロセスに至るまで「ありがとう」と言ってもらう為の設計を行います。

この「ありがとう」を各フェーズでもらう為に、ジャーニーマップを作成すると良いです。

## Elixirの課金実装

さて、ようやくElixirを推す理由についても少しづつ触れていこうかと思います。
ちなみに、コンセプト設計でアンケート待ちなので先に課金部分を実装については、本日別のアドベントカレンダーでPAY.JPに参加してる話しへ繋がります。

https://qiita.com/Yoosuke/private/0e66683bb90fed80e6d5

ここでは、まずPAY.JPを実装する為のライブラリを作る事をしておきます。どんなサービスにしても、サクッと導入できる形を目指したい為です。

### コラム：スタートアップの最強の味方、Elixir - 少人数でも高効率な開発を実現する技術選定

**WEBサービスを活用した起業をする上で、Elixirが良い理由**

Elixirは、Rubyに似た読みやすい文法と、フロントエンド開発を大幅に簡略化できるPhoenix LiveView、そして充実した標準テスト機能という特徴から、少人数での開発がしやすく、フロントエンド開発を簡素化でき保守性の高いコード管理がしやすい為、開発リソースの最適化でき、立ち上げ当初の少ないメンバーで高い開発効率を出せる為です。


他にも良い点がありますが、一気に書いても響かないので、少しづつ伝えていきます。
Next.jsはMPA？SPA？

こんにちはNaotoです。

Next.jsを学んでいると、RSC, SSR, CSR, ISR, SSG, SPA, MPAなど、いろんなワードが出てきます。

そして、考えれば考えるほど、何がどう繋がっているのか訳が分からなくなり、頭がおかしくなりそうだったため、一つずつ理解して潰していこうと思い、今回はMPA、SPAについて勉強してみました。

MPA、SPAについての理解はできているのですが、

「Next.jsはサーバーサイドでレンダリングするから、MPA?」

「でも、クライアントコンポーネントはSPAのように動くよな？」

となっていたため、

"Next.jsはMPAとSPAどっちなのか"

という部分に焦点を当てて勉強してみました。

※この記事は、Next.js App Routerについて記載しています。

## 結論
結論から述べると、

「Next.jsは、MPAでもSPAでもない、PESPA（両者のハイブリッド）である！」

です。

そもそもSPAやMPAという概念に当てはめることができない領域にきているという感じです。

では、上記結論に至った詳細を説明します。

まずは、MPA、SPAについて復習しました。

## MPAとは？

- Multi Page Application
- ユーザーがインタラクティブな操作をするたびに、サーバーに通信し、サーバーから完成されたHTMLファイルを受け取って、ブラウザに表示する。
→操作の度に通信時間が発生するため、インタラクティブな操作が多いWebアプリケーション（SNS, Todoアプリ, チャットアプリなど）に向いていない。
    
- 従来のWebサイト（コーポレートサイトなど）によく見られる。

## SPAとは？

- Single Page Application
- クライアントとサーバー間の通信は初回アクセス時のみ。
- 初回アクセス時に、ほぼ空のHTML、CSS、大量のJavaScriptバンドルファイルをダウンロードし、クライアント側でJavaScriptを動かして、画面遷移やUIの更新を行っていく。
- 全ての処理がクライアント側で行われるため、動作が早く、ネイティブアプリのような体験を得られる。
→インタラクティブな操作が多いWebアプリケーション（SNS, Todoアプリ, チャットアプリなど）に向いている。
    
- 初回アクセス時のJSバンドルファイルが重いため、初回アクセスに時間がかかる。
→SEOに向いてない。
    

## Next.jsはどっち？

上記を踏まえて、Next.jsはMPAとSPAのどちらになるのか調べてみました。

答えは、「どちらにも当てはまらない。」です。

### MPAでない理由

Next.jsでは、Linkコンポーネントを使用した画面遷移はSPAとして動作するからです。

SPAとして動作する根拠は以下２つです。

**①Route Cache**

Next.jsには、Route Cacheというキャッシュ機能があります。

Route Cahceとは、一度訪問したページの情報をクライアント側にキャッシュとして残し、再度同じページを訪問した際にそのキャッシュの情報を使って素早く画面遷移を行う仕組みです。

この機能により、ページへの再訪の際は、サーバーとの通信なしに、画面遷移を行うことができます。

例） /a/sub1 にアクセスした後、/a/sub2 にアクセスした場合

/aまでの部分は、/a/sub1 にアクセスした際にキャッシュされた情報が使用され瞬時に画面に表示されます。
</br>
②Linkコンポーネントによるプリフェッチ

上記①の機能だけでは、初めてアクセスするページの時には、サーバとの通信が必要になるためMPAになります。

そこを補うのがLinkコンポーネントのプリフェッチ機能です。

Linkコンポーネントには、リンクが画面上に現れた際に、あらかじめ静的部分をバックグラウンドにてプリフェッチしてくれる機能があります。

そして、ユーザが実際にリンクをクリックした時には、プリフェッチされた画面を瞬時に表示し、その後に動的部分を取得します。（動的部分の取得中は、loading.jsやSuspenseのfallback UIが表示される）

よって従来のMPAのようなリンククリック後のページ更新はなく、SPAとして画面遷移を行うことができます。

上記の理由からNext.jsはMPAではないことが分かりました。

## SPAではない理由

 Next.jsは、完全SPAのReactアプリケーションとは違い、RSC等、サーバー上でレンダリングを含む多くの処理を行うため、もちろんSPAではありません。

（そもそもSPAの欠点を補うために生まれたのがNext.jsであるため、当たり前ですが。。）

## では何なのか。

Next.jsはMPAではないが、SPAでもない。

では何なのか。

上記の通り、Next.jsでは、

ルート間の画面遷移は、SPAで行われるが、瞬時に表示されるのは静的部分のみ（＋loading.jsやSuspenseのfallback UI）で、動的部分は、SSRならサーバ上、CSRならクライアント上にてデータ取得された後に表示されます。

このようなアプローチを、PESPA（Progressive Enhanced Single Page Application）というそうです。

株式会社一創様の記事には、以下のように記載されていました。

```
PESPA（Progressive Enhanced Single Page Application）は、
Webアプリケーションの開発において、ユーザー体験を向上させるための新しいアプローチです。

PESPAは、まず最小限のHTMLとCSSをサーバーから送信し、
ユーザーがコンテンツを迅速に表示できるようにします。

次に、必要に応じてJavaScriptを追加してインタラクティブな機能を提供します。

この段階的なロードプロセスにより、PESPAはSEOの問題を解決し
、初期ロード時間を短縮し、ユーザーに優れたエクスペリエンスを提供します。

PESPAの基本概念は、まず静的なコンテンツを提供し、
次に動的なコンテンツをロードすることで、
ユーザーがページを読み込みながらも操作を続けられるようにすることです。

これにより、従来のSPAのように全てのリソースを一度にロードする必要がなくなり、
パフォーマンスの向上が図れます。
```

まさにNext.jsのことだと思いました。

以上のことから、
Next.jsは

"SPAやMPAには当てはまらない、PESPAという新しいアプローチになる。"

ということが分かりました！

## 最後に
今回は、Next.jsとMPA,SPAについて調べてみました。
ご指摘等ありましたら、ぜひコメントいただけると幸いです。

次回は、SSR, ISR, SSG等を理解するために、Next.jsのキャッシュについて学んでみようと思います。

最後までお読みいただきありがとうございました。
ブロックチェーン社会実装のための基礎知識概論〜はじめに〜

### はじめに

本書「ブロックチェーン社会実装のための基礎知識概論」は、ブロックチェーン技術を理解し、その社会実装に向けてどのように応用できるかを学ぶためのガイドブックです。本書では、まず既存のシステムが抱える制約に焦点を当て、それを理解した上で、ブロックチェーン技術がどのようにその制約を克服し、実社会で役立つかを段階的に解説していきます。

ブロックチェーンは、単なる技術的なイノベーションにとどまらず、金融分野を超えた広範な分野で応用されています。これを理解するためには、まず従来のシステムが抱える問題点や課題を整理し、その後、ブロックチェーン技術の基本要素であるP2Pネットワークや電子署名、そしてブロックチェーンの基本機能を学びます。最終的に、ブロックチェーンが非金融分野でどのように社会実装されているかを知ることで、ブロックチェーンの社会的なインパクトを把握することができます。

---

本書は以下のように構成されています：

#### 第1章: 既存システムの仕組みと制約
最初に、従来のサーバ型システムやデータベースがどのように構成されているのかを解説し、それらが抱える制約を明らかにします。単一障害点や冗長性、データの所有権問題など、ブロックチェーン技術が克服しようとする課題を理解することから始めます。

#### 第2章: P2Pネットワークと電子署名
次に、ブロックチェーンの技術基盤となるP2Pネットワークと電子署名について学びます。P2Pネットワークは、中央集権型のシステムとは異なり、分散型のネットワークによる高い可用性を実現する技術です。また、電子署名は、ブロックチェーンのセキュリティの基礎となる重要な技術であり、信頼性の高い取引の実現に欠かせません。

#### 第3章: ブロックチェーンの基本機能
本章では、ブロックチェーンの基本的な機能について取り上げます。スマートコントラクト、トークン、マルチシグ、スワップなど、ブロックチェーン上で実行される機能がどのように構成され、どのような利点を持つかを詳細に説明します。これにより、ブロックチェーンが単なる取引記録の技術にとどまらず、複雑な契約や資産管理に応用されることを理解できます。

#### 第4章: 非金融分野での社会実装
最後に、ブロックチェーン技術が非金融分野でどのように実装され、活用されているかを紹介します。アポスティーユやトレーサビリティ、分散型アイデンティティなどの具体例を通じて、ブロックチェーンが社会的な信頼をどのように構築し、さまざまな分野での課題解決に寄与しているかを学びます。

---

本書は、各章ごとにブロックチェーンの構成要素やその応用を段階的に学ぶ構成となっており、まずは既存のシステムの限界を理解し、次にブロックチェーンの技術的基盤を学び、最終的に社会実装に至るまでのプロセスを体系的に把握できるようになっています。

順を追って読み進めることで、ブロックチェーン技術の基礎から応用までを網羅的に理解し、実社会における具体的な応用例まで学ぶことができます。本書が、ブロックチェーン技術の全貌を掴み、さらなる学びと実践の手助けとなることを願っています。

---

### 第１章　既存システムの仕組みと制約

#### 1-1.データと所有権
https://qiita.com/kicnft/items/6badc48ca775d9d2e8c3
決定係数について

## はじめに
こんにちは。みなさんは、データにモデルを当てはめたとき、その良し悪しをどのように評価していますか？とりあえずMSEや尤度などを使うことがほとんどでしょうか。最近、非線形モデルを用いた分析に決定係数が使われていた例を見かけたのですが、そもそも非線形モデルで決定係数を用いるのは適切なのでしょうか？このことが気になったので整理してみました。すでに同様の問題を指摘している記事がありますので、そちらも併せて参照してください。

## 決定係数とは
決定係数は分析ソフトなどでいわゆる$R^2$と示され、推定された回帰式のデータに対するあてはまりの良さを表します。誤差やAICなどと並べて回帰分析の結果などに表示されます（Rでは`lm()`で回帰分析した結果を`summary()`で表示すると、Pythonでは`statsmodels`ライブラリを使って回帰分析を行い`.summary()`メソッドで$R^2$が表示されます）。0から1の間の値をとり、モデルがどのくらいデータの変動を説明できているかを表す指標などとよく説明されます。データを$(x_i, y_i)$、$i$番目の$y$の予測値を$\hat{y_i}$、$y$の平均値を$\bar{y}$としたとき決定係数は

```math
R^2=1-\frac{\sum_{i=1}^n(y_i - \hat{y_i})^2}{\sum_{i=1}^n(y_i - \bar{y})^2}
```

によって計算されます。

## 導出
決定係数を理解するためには次の3つの項が重要となります。

- 全変動：データの平均値からの偏差
- 回帰変動：回帰予測値のデータ平均からの偏差
- 残差変動；データの回帰予測値からの偏差

これら3つの量の関係を図示したのが、以下の図です（この図は[こちらの記事](https://bellcurve.jp/statistics/course/9706.html?srsltid=AfmBOop-kVZE9jL-2d2G4Ui5c32UAohpodW_RI9hXCoCRdGO8prjEfsd)を参考に作成しました）。二つの波線の交点がデータの平均値、グレーの太線が回帰直線を表し、それらをもとに全変動、回帰変動、残差変動に対応する部分が示されています。

![決定係数 (1).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/176360/d4832421-2339-abc1-f9fb-81f2e74a0c5d.png)

まず、全変動を以下のように式変形していきます（※以下、総和は適宜データ数で和をとります）。

```math
\begin{align}
\begin{split}
\sum(y_i-\bar{y})^2 &=\sum((\hat{y_i}-\bar{y})+(y_i-\hat{y_i}))^2 \\
&=\sum((\hat{y_i}-\bar{y})^2+(y_i-\hat{y_i})^2 + 2(\hat{y_i}-\bar{y})(y_i-\hat{y_i})) \\
\end{split}
\end{align}
```

ここで、$2\sum(\hat{y_i}-\bar{y})(y_i-\hat{y_i})$について$\hat{y_i}=\bar{y}+\beta_1(x_i-\bar{x})$と$\beta_1=\frac{\sum(y_i-\bar{y})(x_i-\bar{x})}{(x_i-\bar{x})^2}$表されることから

```math
\begin{align}
\begin{split}
2\sum(\hat{y_i}-\bar{y})(y_i-\hat{y_i})&=2\sum(\bar{y}+\beta_1(x_i-\bar{x})-\bar{y})(y_i-\bar{y}-\beta_1(x_i-\bar{x})) \\
&=2\sum(\beta_1(x_i-\bar{x}))(y_i-\bar{y}-\beta_1(x_i-\bar{x})) \\
&=2\beta_1\sum(x_i-\bar{x})(y_i-\bar{y}) -2\beta_1^2\sum(x_i-\bar{x})^2 \\
&=0
\end{split}
\end{align}
```

となります。このことより、式（1）は

```math
\begin{align}
\begin{split}
\sum(y_i-\bar{y})^2 
&=\sum(\hat{y_i}-\bar{y})^2+\sum(y_i-\hat{y_i})^2
\end{split}
\end{align}
```

となり、全変動が回帰変動と残差変動の和で表わされることがわかります。ここで、回帰式の当てはまりの良さとして全変動に対する回帰変動の割合という量を考えてみると式（3）より

```math
\begin{align}
\begin{split}
\frac{\sum(\hat{y_i}-\bar{y})^2}{\sum(y_i-\bar{y})^2}
= 1 - \frac{\sum(y_i-\hat{y_i})^2}{\sum(y_i-\bar{y})^2}
\end{split}
=R^2
\end{align}
```

となり、冒頭で示した決定係数の計算式が得られます。さて、ここまで述べてきた導出について振り返ってみると、式（2）の変形の過程でモデルが線形であることを用いています。つまり、決定係数が線形モデルを前提としていることがわかります（非線形モデルでも決定係数の値自体は計算できてしまいます）。

## 決定係数と相関係数
決定係数は相関係数の二乗と説明されることがあります。ついでに、こちらも確認してみましょう。モデルが直線であるとき、$\hat{y_i}=\beta_1 x_i + \beta_0$と$\beta_1=\frac{Cov(X, Y)}{\sigma_X^2}$がなりたつので

```math
\begin{align}\begin{split}
R^2&=\frac{\sum(\hat{y_i}-\bar{y})^2}{\sum(y_i-\bar{y})^2}\\
&=\frac{\sum((\beta_1x_i+\beta_0)-(\beta_1\bar{x}+\beta_0))^2}{n\sigma_Y^2}\\
&=\beta_1^2\frac{\sum(x_i-\bar{x})^2}{n\sigma_Y^2}\\
&=\frac{Cov(X,Y)^2}{n\sigma_Y^2 \sigma_X^4}n\sigma_X^2\\
&=\frac{Cov(X,Y)^2}{\sigma_X^2 \sigma_Y^2}
\end{split}\end{align}
```

と相関係数の二乗になります。

## 最後に
本稿では、使用しているモデルが線形モデルである場合に、決定係数がどのように意味を持つのかを確認しました。分析ツールによっては、特に深い意図なく表示されていることが多いのかもしれません。決定係数の背後にある仮定を理解した上で使いつつも、MSEなど他の指標を併せて提示する方が無難だと思います。
Firefox拡張機能でbackgroundスクリプトを使うときの手順とサンプル

# 概要

この記事は[初心者のブラウザ拡張機能 Advent Calendar 2024](https://qiita.com/advent-calendar/2024/browser-extension)の3日目の記事です。

`Background`スクリプトを使うときの手順とサンプルを記載します。

# Backgroundスクリプトについて

Contentスクリプトと異なりWebページの要素を直接操作するのではなく、ブラウザ自体の機能を拡張するものだといえます。

たとえば右クリックして出てくるメニューに自分のボタンを追加したり、拡張機能用にWebページを作ったりできます。

[Background scripts](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Background_scripts)

# 作り方

`Background`スクリプトも`Content`スクリプトと同様にJavascriptで記述します。ここではサンプルとして右クリックしたときのメニューを追加してみます。

```javascript:background.js
browser.menus.create(
  {
    id: "sample",
    title: "sample menu",
    contexts: ["page"],
  }
);
```

マニフェストファイルは以下のように作ります。
重要なのは`permissions`です。ブラウザ自体にアクセスして機能を追加するため適切な権限を割り当てます。今回はメニューを追加するため`menus`と`activeTab`を割り当てます。

詳しくは下記ページを参照ください。
[permissions](https://developer.mozilla.org/ja/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions)

また作成した`background.js`を`background.scripts`で追加します。


```json:manifest.json
{
    "browser_specific_settings": {
        "gecko": {
          "id": "the-town-sample-qiita@example.com"
        }
    },
    "manifest_version": 3,
    "name": "init-extention",
    "version": "0.1",
  
    "description": "これは初めてのブラウザ拡張機能です。Qiitaの記事内のタグの背景色を変えます。",
  
    "icons": {
      "48": "icons/icon-48.png"
    },
    
    "background": {
        "scripts": ["background.js"]
      },
  
      "permissions": [
        "menus",
        "activeTab"
      ]
}
```

:::note info
使っているアイコン画像や拡張機能の読み込み方法は以下を参照ください。

[はじめてブラウザ拡張機能を作るときの流れ（Firefox）](https://qiita.com/The-town/items/555f890608f8de4f5a62)
[Firefox拡張機能を開発者センターに限定公開する手順](https://qiita.com/The-town/private/c30d58ee4103abd1b978)
:::


この状態で読み込むと一番下にメニューが追加されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/302006/66a78984-e312-a128-c033-34fe3605cda8.png)
MUI 自動的にダークモードとライトモードを切り替える

MUIを使ってライトモードとダークモードを切り替える方法の備忘録。

## 追記
普通にこれで良かった
```tsx: App.tsx
import Card from '@mui/material/Card'; // なぜかBoxだけサポートされていない
import { ThemeProvider, createTheme } from '@mui/material/styles';

const theme = createTheme({
  // いい感じの色を生成してくれるっぽい
  colorScheme: {
    light: true,
    dark: true,
  },
  // デフォルトのスタイルをオーバーライド
  components: {
    MuiCard: {
      defaultProps: {
        sx: {
          bgcolor: 'white', // 'red'とかだと流石に無理
        },
      },
    },
  },
});

export function App() {
  return (
    <ThemeProvider theme={theme}>
      <Card>
        Hello, World!
      </Card>
    </ThemeProvider>
  );
}
```

## コード
```tsx: App.tsx
import Box from '@mui/material/Box';
import { ThemeProvider, createTheme } from '@mui/material/styles';

/* Paletteの型宣言ににカスタムの色を追加 */
declare module '@mui/material/styles' {
  interface Palette {
    myBlack: string,
    myGray: string,
  }
  interface PaletteOptions {
    myBlack?: string,
    myGray?: string,
  }
}

const theme = createTheme({
  /* 自動で色を切り替えてくれる */
  colorSchemes: {
    light: {
      palette: {
        /* ライトモードの時のみ採用 */
        myBlack: 'white',
        myGray: '#888888',
      },
    },
    dark: {
      palette: {
        myBlack: 'black',
        myGray: '#DDDDDD',
      },
    },
  },
});

function Content() {
  return (
    <Box
      sx={
        theme => ({
            /* Themeオブジェクトを使って色を指定する */
          color: theme.palette.myBlack,
          bgcolor: theme.palette.myGray,
        })
      }
    >
      <p>Hello, World!</p>
    </Box>
  );
}

export default function App() {
  return (
    <ThemeProvider theme={theme}>
      <Content />
    </ThemeProvider>
  );
}
```


## ポイント
- `colorSchemes`を使ってモードに応じた色を自動指定する
- Themeオブジェクトから色を拾う

## 課題
- `palette`が簡単に肥大化する（一度しか使わない色でも指定が必要）
- `palette`で色を指定し忘れるとスタイルが消える
- `declare module`が面倒

#### 余談：Next.js対応
Next.jsで上記のアプローチを取ろうとする際、`createTheme()`を使ったコンポーネントを`layout.tsx`に含めるとエラーが発生する。コンポーネントを`app.tsx`の`App()`で使うようにすると解決する。
エンジニアのための報連相ガイド

# はじめに
エンジニアにとって、報連相は仕事を円滑に進めるための重要なスキルです。
特に、報連相が上手にできるかどうかで、その人の評価や信頼感が大きく変わると感じています。

この記事では、どうすれば効果的なコミュニケーションが取れるのか、自分の経験をもとに良い例と悪い例を交えながら解説しました。
これを読んでいただき、日々の仕事の参考にしていただければ幸いです。

# 上手な報連相の仕方
上手な報連相とは、相手に伝わりやすい形で情報を共有できること を指します。
これができると、「仕事がしやすい人」 として評価され、よりスムーズに業務が進むようになります。

以下に、具体的な場面を通して良い例と悪い例を紹介します。

## 相談編その1

#### 良い例 (Aさん)
1. タスク開始前の確認
タスクの内容で不明点があったため、着手前にリーダーに質問し、不安を解消。
2. 詰まりの早期相談
作業中に詰まったが、15分ほど試行錯誤した後、リーダーに相談し解決。
3. 成果物の提出
作業中に都度確認を得たため、大きな修正なく期限内にタスクを完了。

#### 悪い例 (Bさん)
1. 独断で進行
不明点を確認せず、とりあえず作業を開始。
2. 長時間の試行錯誤
作業中に詰まったが、1時間以上自力で調べ続け、正確性に不安を抱えたまま進行。
3. 成果物の遅延修正
提出後、認識のズレが発覚し、大幅な修正が必要に。期限にも間に合わず。

### 両者の違い
Aさんは早期相談を通じて効率よく進め、リーダーに安心感を与えています。
一方で、Bさんは独断で進めた結果、時間の無駄や信頼の低下 を招いてしまいました。

## 相談編その2
前提、出社して仕事しているものとします。

私は、口頭での確認とチャットでの確認は使い分けています。

- 口頭で確認する
    - 急ぎのもの
    - 軽めの内容
    - 認識をすり合わせたいとき（細かなニュアンスが重要な場合）
    - 画面を見せて実際に教えてもらいたいとき
        - 「〇〇のやり方を教えてください」など
- チャットで確認する
    - 作業に詰まったとき
    - 優先度が低めの確認事項
    - 記録として残したい内容

また、質問は整理して送ることで、受け手が理解しやすくなります。

```
- 現在のタスク
- わからないこと
- 現状わかっていること
```

## 報告編
#### 良い例(Aさん)
朝会での進捗確認MTGにて、
上司：Aさん、進捗はいかがでしょうか？
Aさん：〇〇まで終わっていて、これから〇〇を進めようと思います。
上司：わかりました。ちなみに〇〇の確認はされましたでしょうか？
Aさん：すみません。まだ確認していませんでしたので、これから確認します。

#### 悪い例(Bさん)
上司：Bさん、進捗はいかがでしょうか？
Bさん：〇〇を確認していて、〇〇が〇〇で、〇〇だと思っているんですけど、...
上司：あ〜、つまり〇〇ということですね？
Bさん：はい、〇〇がわかってない状況です。
上司：〇〇は確認しましたか？
Bさん：え〜っと、〇〇がこうなっていて、〇〇がこうなっていたので...

### 両者の違い
Aさんの報告は簡潔で、進捗状況が一目でわかります。
一方でBさんの報告は、結論が不明瞭でわかりにくいです。
これは、進捗報告が作業報告になっている のが原因と考えられます。

# 最後に
報連相は、相手にとって伝わりやすい形で行うことが大切です。
良い報連相を実践することで、チーム全体の信頼感が向上し、業務がスムーズに進みます。

今回の記事で紹介した例やフォーマットを参考にして、日々の業務で実践してみてください。報連相を意識するだけで、あなたの評価が大きく変わるかもしれません！
Fiddler でローカルホストのパケットをキャプチャする

ローカルホストで動かしているアプリケーション(PowerShellの`Invoke-WebRequest`)のCookieをヘッダに設定した場合の挙動が納得いかなかったため、Fiddlerを、使ったのだが、ちょっと設定に苦労したので、メモをしておく。

# ローカルホストのキャプチャを有効化する

昔は8888だった気がするが、今は違う様子。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3470/20f271f8-f277-334e-f412-4108d07eef4b.png)

ローカルで動くアプリのIPAddress/PortをProxyとして設定しておく。ちなみに、このポートは、私のアプリの場合、毎回変わる

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3470/3db04d54-c7f9-1b22-628b-60fd04feafcf.png)

ポイントは、リクエストはその端末のIPAddressで実行するのと、プロキシをFiddlerのポートに指定すること。

```powershell
$result = curl -v http://192.168.xxx.xxx:54269/api/Conversation -WebSession $session -Proxy 'http://127.0.0.1:8866'
```

Works

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3470/2c8cab59-9570-e716-8793-f7ffd2efc39d.png)

ちなみに、私が調べたかったことは、上記の `-WebSession` を使う場合は、うまくいくのですが、自分で Cookie を指定すると無視されます。`Set-Cookie` から値を取得して、セットします。

```POWERSHELL
$headers = @{
  Cookie = $cookie
}
$responseWithCookie = Invoke-WebRequest -Uri "http://192.168.xxx.xxx:54269/api/Conversation" -Headers $headers -Proxy 'http://127.0.0.1:8866'
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3470/981c7d6b-12b6-2477-8006-9d06eac975c7.png)

ううむ。自分でセットした場合、何故か Cookie ヘッダが無視されるようです。これがクライアントレベルで起こっているので、おそらくInvoke-WebRequest 側できっとなにかやってるのだと思いますが、めんどくさいのでここまでわかればまずは良いか。
状態を保持するモジュール

# 唯一、一つだけの状態の物を作る
```rb
irb(main):001* module AwesomeApi
irb(main):002*   @base_url = ''
irb(main):003*   @debug_mode = false
irb(main):004*
irb(main):005*   class << self
irb(main):006*     def base_url=(value)
irb(main):007*       @base_url = value
irb(main):008*     end
irb(main):009*
irb(main):010*     def base_url
irb(main):011*       @base_url
irb(main):012*     end
irb(main):013*
irb(main):014*     def debug_mode=(value)
irb(main):015*       @debug_mode = value
irb(main):016*     end
irb(main):017*
irb(main):018*     def debug_mode
irb(main):019*       @debug_mode
irb(main):020*     end
irb(main):021*
irb(main):022*   end
irb(main):023> end
=> :debug_mode
irb(main):024> AwesomeApi.base_url
=> ""
irb(main):025> AwesomeApi.base_url = 'http://example.com'
=> "http://example.com"
irb(main):026> AwesomeApi.debug_mode = true
=> true
irb(main):027> AwesomeApi.base_url
=> "http://example.com"
irb(main):028> AwesomeApi.debug_mode
=> true
```

# 共通の値を設定するモジュールを作成する
>クラスインスタンス変数を使って、クラス自身にデータを保持しました。この方法はモジュールでも使うことができます。

>ライブラリの実行に必要な設置地などは`アプリケーション全体で共通の値になることが多い`です。そのため、アプリケーション内ではいつでもどこでも同じ設定値を設定したり、取得したりする必要があります。そのため`設定値の情報はアプリケーション内で「唯一、一つだけ」の状態`になっていることが望ましいです。このように`「唯一、一つだけ」のオブジェクトを作る手法のことを、シングルトンパターン`と呼びます。

https://gihyo.jp/book/2017/978-4-7741-9397-7
【Render】RenderでRailsのシード値を適用する方法

# 記事概要
RenderでDBにシード値を適用する方法について説明する。

# 言語やフレームワーク
|| 使用技術 |
| ---- | ---- |
| フロントエンド | HTML |
| バックエンド | Ruby 3.2.0 <br> Ruby on Rails 7.0.8.6 |
| データベース | PostgreSQL |
| インフラ | Render |
| API | - |
| その他 | - |

# 前提
- db/seeds.rbにシード値を作成するように記述されている
- [Render](https://render.com/)にアカウント登録している

# 手順①(事前準備)
1. ローカルPCにPostgreSQLを登録する
    1. ターミナルで下記を実行する
        ```
        % brew install postgresql@14
        ```
    1. PostgreSQLを正常にインストールできたことを確認する
        ```
        % psql --version
        # => psql (PostgreSQL) 14.5 (Homebrew) のように、バージョンが表示されれば正常
        ```
1. アプリケーションにライブラリを追加する
    1. GemfileにGemを追記
        ```ruby
        # 最終行に、下記(group ~ end)を記述する　
        group :production do
          gem 'pg'
        end
        ```
    1. ターミナルで下記を実行し、Gemをインストール
        ```
        % bundle install
        ```
1. Render用の設定ファイルを追加する
    1. `bin`フォルダに`render-build.sh`ファイルを手動作成
    1. 下記を記述
        ```ruby
        #!/usr/bin/env bash
        # exit on error
        set -o errexit
        
        bundle install
        bundle exec rake assets:precompile
        bundle exec rake assets:clean
        bundle exec rake db:migrate
        bundle exec rails db:seed
        ```
1. DB設定を変更する
    1. config/database.ymlのDB名を変更する
        ```ruby
         development:
          # 中略
          database: [アプリ名]_development
        
        test:
          # 中略
          database: [アプリ名]_test
        ```
1. Gemfile.lockの設定を変更するために、ターミナルで実行
    ```
    % bundle lock --add-platform x86_64-linux
    ```
1. アプリをクローンした場合、秘密情報管理用のファイルを作成する
1. GitHubにコードをプッシュする

# 手順②(DB作成)
1. [Render](https://render.com/)にログイン
1. ＋ New ＞ PostgreSQL を選択
1. 下記を入力 or 選択する

    | 項目名 | 入力値 |
    | ---- | ---- |
    | Name | <任意のDB名> |
    | Region | Ohio |
    | Instance Type | Free |
1. 「Create DataBase」をクリック
1. 「Status」が`Available`に変更されると、DB作成が完了
1. `Internal Database URL`の値をコピーし、メモなどに保管する

# 手順③(アプリケーション作成)
1. Renderでアプリを作成
1. ＋ New ＞ Web Service を選択
1. GitHubのリポジトリを選択
1. 「Connect」をクリック
1. 下記を入力 or 選択する

    | 項目名 | 入力値 |
    | ---- | ---- |
    | Name | <任意のアプリ名 ※'_'は使用しないこと> |
    | Region | Ohio |
    | Build Command | ./bin/render-build.sh |
    | Start Command | bundle exec puma -C config/puma.rb |
    | Instance Type | Free |
1. 環境変数を設定する

    | 環境変数名 | 入力値 |
    | ---- | ---- |
    | RAILS_MASTER_KEY | < config/master.keyの値> |
    | DATABASE_URL | <「Internal Database URL」の値> |
1. 「Deploy Web Service」をクリック
1. 「Status」が`Deployed`に変更されると、アプリ作成が完了

# 備考
- `render-build.sh`ファイルの`bundle exec rails db:seed`を記述を削除すると、シード値適用が実行されない
- [TablePlus](https://tableplus.com/)を使用すると、DBの内容を確認できる
県のリスキリング講座のローコード開発基礎（Power Apps)を受けてみて

# 最初に
　この記事は、Power Apps Advent Calendar 2024の12日目の記事です。

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

# 自己紹介・内容
　佐賀県の小売業で情シスをしています。　
　社内ではPower Platformを活用したDX的な取り組みを合間に行っています。

 https://kn.itmedia.co.jp/kn/articles/2409/27/news070.html
 
# 佐賀大学DXリスキルプログラムとは
　佐賀県内に居住又は勤務されている方で、就業されている方対象に 10月～12月の土日に行われる短期集中型の講座で座学・グループワーク・ハンズオン等の様々な学習を受講できるプログラムとなっています。
 
また技術の勉強よりも経営戦略・ビジネス企画等がメインとなっており、技術については組織内で展開する上での基礎知識を取得する受講する程度になっています。

 https://www.sagallege-dx.admin.saga-u.ac.jp/course/considering-new-business/


## Microsoft製品の講座ついて　  
　
 Microsoft365・Power Platformの講座は、Power Appsの他にCopilot、Power Queryが講座に含まれており、専門講師による座学・ハンズオンが行われました。
 

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2277732/e5838789-ca32-a949-3189-0b80ebb8be27.png)



Power Queryの講座受講兼アシスタントの記事については、Power BIのAdvent Calenderをご覧ください。

https://qiita.com/tsukapon/items/83751f8055933cae1a24


## Power Appsの講座内容・教材

　講座受講用の環境が用意されており、Microsoft LearnのPower Appsのトレーニングに従って、キャンバスアプリ作成のハンズオン形式での勉強会になりました。
 

  https://learn.microsoft.com/ja-jp/training/powerplatform/power-apps

## 感想
受講しての簡単な感想を書きたいと思います。


#### 作業感が多い
4.5時間の間、Microsoft Learnを見ながらのほとんど説明がない状態でのハンズオンだったため、マニュアルに従ってアプリを作成しているように感じてしまい途中で諦めるひともいました。
最初に何のアプリを作成しているのかを説明しつつハンズオンしたほうがよかったかもしれない。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2277732/0c066eed-59ec-6b7b-cc91-d8ce4882fc4c.png)


#### Learnの日本語表記が分かりにくく混乱する人が
ほとんどの受講者がMicrosoft Learnを見たことがなく、日本語表記の部分でつまずき挫折していた人が多かった。
またノートPCでLearnを見つつ、タブ切り替えでPower Appsを操作する方法が初心者には大変だったかもしれません。


#### 簡単なアプリを作成し、その後はグループディスカッションがよかったかも
開発の育成講座ではなく、組織に適用・展開する人材を育てる講座だったので、Leanを使っての手順に従ったアプリ作成ではなく、案外Learnを使わず簡単な業務アプリを3時間程度作成したのち残りの時間は組織内での利用についてグループディスカッションしたほうがよかったかもしれません。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2277732/76ec48db-6d9e-6a07-9d7c-431be45a17d3.png)


## ローコードであっても学習は必要
ローコードであれば誰でも簡単に開発出来るのではなく、他のPower PlatformのメンバーであるPower AutomateやPower BIも勉強・学び続けないとツールを正しく使用することは出来ません。

社内では「学習・勉強し続ければ誰でも利用できます」と上層部に伝えているつもりが、DXセミナーで何故か「誰でも簡単にアプリ開発・データ分析が出来る」と話してるのを聞き、人に教えたり伝えたりすることの難しさを改めて実感した講座でした。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2277732/3ca03869-a191-5ce6-53e7-333b1ebe8fec.png)