OmniAICreator/Qiita-1.07M huggingface dataset:
DB設計について③

## 正規化
### DBをマスターしたい
前回に引き続き、DBの基本知識を学習している
今回は正規化についてまとめる

#### 参考文献
[達人に学ぶDB設計徹底指南書](https://www.amazon.co.jp/%E9%81%94%E4%BA%BA%E3%81%AB%E5%AD%A6%E3%81%B6DB%E8%A8%AD%E8%A8%88-%E5%BE%B9%E5%BA%95%E6%8C%87%E5%8D%97%E6%9B%B8-%E5%88%9D%E7%B4%9A%E8%80%85%E3%81%A7%E7%B5%82%E3%82%8F%E3%82%8A%E3%81%9F%E3%81%8F%E3%81%AA%E3%81%84%E3%81%82%E3%81%AA%E3%81%9F%E3%81%B8-%E3%83%9F%E3%83%83%E3%82%AF/dp/4798124702)

---
### 目次
1. 基礎用語
1. 正規化とは
1. ストレージの冗長構成
1. バックアップ設計
---

### 1.基礎用語
#### テーブルの構成要素

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659965/a8f52862-644e-4f56-f629-68fe40872e65.png)

参考サイト：[株式会社システムインテグレーター](https://products.sint.co.jp/siob/blog/dbtable)

1. テーブル
　共通点を持ったレコードの集合体
　「テーブル名は複数形または複数名詞で書ける」
　→そうでなければテーブルにはどこか間違いがある
1. カラム
　「列」のこと、属性ともいう
1. レコード
 「行」のこと
1. フィールド
　「セル」のこと

#### キー
1. 主キー
　別名は「プライマリキー」と呼ぶ
　テーブルに必ず1つ存在しなければならず、かつ1つしか存在しない
 一意に識別する＝値を指定すれば必ず1行のレコードを特定できる
1. 外部キー
　テーブルに対して一種の「制約」を課すこと（参照整合性制約）

#### 制約
1. NOT NULL制約
　データを入力せず空欄の状態をNULLという
　しかし、SQL上では問題を引き起こす厄介者
　＝可能な限りデータはNULLにしない（データベース設計における大方針）
1. 一意制約
　列の組について一意性を求める制約
1. CHECK制約
　列の取りうる値の範囲を制限するための制約

#### 命名規則
* 名前に使える文字集合
　半角のアルファベット、半角数字、アンダーバー
　日本語は原則、使わない
* 最初はアルファベット
　先頭は必ずアルファベットを使う
* 名前は重複してはならない

---
### 2.正規化とは
#### 正規化の定義
　正規化されたデータ形式を正規形という
　正規形はデータの冗長性を排除し、一貫性と効率性を保持するための形を指す
* 冗長性
　一つの情報が複数テーブルに存在して無駄な領域と面倒な更新処理が発生する状態
* 非一貫性
　データの不整合が発生したり、そもそもデータを登録することのできない状態

### 3.第一正規形
　一つのセルの中には一つの値しか含まない

（Before)

|社員ID|社員名|子|
|:-:|:-:|:-:|
|000A|加藤|達夫<br>信二|
|000B|藤本|   |
|001F|三島|敦<br>飛鳥<br>洋子|

(After)

|社員ID|社員名|子|
|:-:|:-:|:-:|
|000A|加藤|達夫|
|000A|加藤|信二|
|000B|藤本|   |
|001F|三島|敦|
|001F|三島|飛鳥|
|001F|三島|洋子|

これだとまだ問題がある
1つ目は主キーが決められないこと
　→決めるなら「社員ID＋社員名＋子」だが子にはNULLがある
2つ目は2つのエンティティ情報を持っていること
　→社員と子供の情報があり、テーブルの意味やレコードの単位をすぐに理解できない<br><br>

(After ver2.0)テーブルを分割する
　→社員テーブルと子供テーブルに分ける

|社員ID|社員名|
|:-:|:-:|
|000A|加藤|
|000B|藤本|
|001F|三島|

|社員ID|子|
|:-:|:-:|
|000A|達夫|
|000A|信二|
|001F|敦|
|001F|飛鳥|
|001F|洋子|

### 4.第二正規形
#### 部分関数従属とは
主キーの一部の列に対して従属する列がある場合＝部分関数従属
ex)「会社コード」から「会社名」がわかる

主キーを構成する全ての列に従属性がある場合＝完全関数従属
→第２正規形はテーブル内の部分関数従属を解消し、完全関数従属のみのテーブルを作ること

(Before)
|会社コード|会社名|社員ID|社員名|年齢|部署コード|部署名|
|:-:|:-:|:-:|:-:|:-:|:-:|:-:|
|C0001|A商事|000A|山下|40|D01|開発|
|C0001|A商事|000B|高橋|32|D02|人事|
|C0001|A商事|001F|小山|50|D03|営業|
|C0002|B工業|000A|斎藤|21|D03|営業|
|C0002|B工業|009F|田崎|33|D01|開発| 
|C0002|B工業|010A|柳田|46|D04|総務| 

(After)
|会社コード|社員ID|社員名|年齢|部署コード|部署名|
|:-:|:-:|:-:|:-:|:-:|:-:|
|C0001|000A|山下|40|D01|開発|
|C0001|000B|高橋|32|D02|人事|
|C0001|001F|小山|50|D03|営業|
|C0002|000A|斎藤|21|D03|営業|
|C0002|009F|田崎|33|D01|開発| 
|C0002|010A|柳田|46|D04|総務| 

|会社コード|会社名|
|:-:|:-:|
|C0001|A商事|
|C0002|B工業|

異なるレベルの実体（エンティティ）をきちんと分離させるイメージ

### 4.第三正規形
#### 推移的関数従属
テーブル内部に存在する段階的な従属関係のこと
ex)「会社コード、社員ID」→「部署コード」→「部署名」
　会社コードがあって初めて部署名のリストができる
　→まだ所属している人がいない部署の登録ができない

（After)
|会社コード|社員ID|社員名|年齢|部署コード|
|:-:|:-:|:-:|:-:|:-:|
|C0001|000A|山下|40|D01|
|C0001|000B|高橋|32|D02|
|C0001|001F|小山|50|D03|
|C0002|000A|斎藤|21|D03|
|C0002|009F|田崎|33|D01| 
|C0002|010A|柳田|46|D04|
<br>

|会社コード|会社名|
|:-:|:-:|
|C0001|A商事|
|C0002|B工業|
|C0003|C建設|

|部署コード|部署名|
|:-:|:-:|
|D0001|開発|
|D0002|人事|
|D0003|営業|
|D0004|総務|
デザイントークンをどのレイヤーまで定義すべきかの判断基準

## この記事の概要

デザインシステムの中でも、デザイントークンの設定の仕方を迷う声を聞きます。
いわゆるGlobal, Alias, Component-specificとどこまで定義すべきなのか分からないとか、定義したは良いものの使いこなせている自信がないとか、よく相談を受けます。

というわけで、私がいくつかのプロダクトに関わった中で、個人的に考えるレイヤー分けの基準を記事にしました。

:::note warn
著名な本や有名なデザインシステムの記事とは反する部分もあるかもしれません。
あくまで私が個人的な経験をもとに見えてきた閾値や基準をまとめた記事です。
この記事の通りにするのが正しいという訳はなく、何か1つの参考になれば幸いという内容です。
:::

## Component-specificまで定義する

私が思うに、大抵のプロダクトではComponent-specificレイヤーまで定義する必要はありません。

非常に大規模で、1つのデザインシステムの中でプロダクトごとに複数のバリエーションがあるとか、ほぼ同一のコンポーネントなのにスタイルを変えないといけないとか、そういう複雑さでない限りComponent-specificレイヤーは不要だと思います。

ただ、例外的に「**Global, Aliasともに継承しないものの、いきなりComponent-specificを定義する必要がある**」ようなものは設定してもいいかもしれません。

例えば以下のようなものが挙げられます。

- モーダルウィンドウ背景のScrimのカラー
- SNSのロゴや共有リンクのコンポーネントでの、外部サービスのカラー
- 「画面いっぱいに表示する」といった要件が重要なグラフィック系コンポーネントでのサイズや余白

ただしお察しのようにとても「例外的」なものばかりで、常々定義するものではないはずです。

まだ小さなプロダクトで、成熟しきってもないうちからいきなりComponent-specificレイヤーを定義するのは、大抵の場合時期尚早かと思います。

## Aliasまで定義する

私自身としては一番おすすめです。

背景や前景のカラー、役割ごとの文字サイズ、重要度別の線幅や影などを定義し、名前と使用箇所が1:1対応になるよう定義します。

同じトークンであっても役割が違うのであれば何度定義しても構いません。
例えば、背景色の`#fff`と、メインカラーの上に乗せる文字色としての`#fff`は、色こそ同じですが役割が違います。
そういう場合は、単に`#fff`（あるいは`gray-0`などのGlobalトークン）を使用するより、個別にAliasトークンを設定して使用する方が好ましいです。

例えば「**背景色は`#fff`のままだけど、文字色は不透明度90%の`#fff`に変更したい**」といった調整が生まれる場合もあります。
こういった場合の変更可用性を上げるという意味で、値が同じであっても、役割が違う場合には別のAliasトークンとして設定した方が良いです。

一方で、同じ値を使うならGlobalレイヤーだけの設定でも良いのではないか？と思われるかもしれません。
しかし、例えば`red-500`と`red-600`という名前の、濃さの違う赤色を見たとき、人間のファジーな評価ではどちらも「**中くらいの明度の赤**」と判断してしまいかねません。
ですが`red-500`に`main-surfave`、`red-600`に`main-outline`という名前がついていれば、両者には「**メイン系の色のうち、サーフェス用とアウトライン用**」という区分が生まれます。
これにより「背景色なら`red-500`だと思う」「いやいや`red-600`だよ」といった、難しい感覚のすり合わせに時間を使わず、組織で同一の基準を持てます。

:::note alert
人間それぞれの感性や知覚のセンサーは異なりますから「どうしても背景色が`red-500`なのはおかしい、絶対`red-600`であるべき」といった意見が生まれる可能性はあります。
それも、組織規模が多くなればなるほど多様なべき論が飛び交います。
デザインシステムやトークンを定義するのとは別に「我々の組織ではこの基準で判断する」というガバナンスを効かせる必要があります。
:::

## Globalまで定義する

Globalまでの定義でも十分に機能するシーンは多いと思います。

例えば、ページ数が少ないとか、繰り返し登場する要素が少ないとかの場合です。
大まかに言えば「**成熟していない、生まれて日が浅いプロダクト**」でしょうか。

こういったプロダクトで無理にAliasやComponent-specificを定義しても、後から上手く再利用できなかったり、苦労して定義した割にまったく使われなかったり、といったことが起きがちです。

最初のうちはルールが混沌とするのは仕方のないことです。
ただ、そんな中でもある程度長く運用していると「この表現には毎回この色を使っている」「この構成のとき、見出しと本文は毎回この比率だ」といった法則が生まれてきます。

その段になってはじめて名前をつけてAliasとして管理し始めるのでも全然問題ないと思います。
逆に言えば、それくらい繰り返し使用するまではあくまでGlobalな名前としてトークンを扱っているのでも良い、ということです。

Globalトークンのままだと人によっていつどのトークンを使うか揺れてしまいがちではありますが、それでも無数の色・サイズの中から10種類程度には絞れているわけです。
最初から完璧なトークンでなくても「現状ですら、無数の中から1つを選ぶよりはよっぽど効率的」と自信を持って良いと思います。

## まとめ

- 1つのデザインシステム内で複数ブランドを成立させる必要があるなど、非常に大規模で複雑：Component-specificまでの定義もあり得る
- 生まれて間も無い / まだローンチしていない：Globalまでで十分かもしれない
- それ以外（ほどほどの成熟度、ほどほどの規模の組織）：Aliasまであると便利
Arch LinuxにVirtualBoxを導入しよう

Arch LinuxにVirtualBoxを導入する方法を解説します。

# VirtualBoxのインストール
```
sudo pacman -S virtualbox virtualbox-host-modules-arch virtualbox-guest-iso
```
VirtualBoxと必要なカーネルモジュールをインストールします。
（上記はlinuxカーネルを使用している場合）

Guest Additions用のisoも入れておきます。

# カーネルモジュールのロード
```
sudo modprobe vboxdrv
```
カーネルモジュールを手動でロードします。

# ユーザーをvboxusersグループに追加
```
sudo usermod -aG vboxusers $USER
```
実行後、変更を適用するためにログアウトして再ログインします。

# Extention Pack
以下からExtention Packをダウンロードしてインストールします。
https://www.virtualbox.org/wiki/Downloads
【競技プログラミング】AtCoder Beginner Contest 340_D問題

# 問題
https://atcoder.jp/contests/abc340/tasks/abc340_d

## 要約

1. ゲームには1からNまでの番号がついたN個のステージがある。
2. 最初はステージ1のみが遊べる。
3. 各ステージi (1 ≤ i ≤ N-1) では2つの選択肢がある：
   a. Ai秒かけてクリアし、ステージi+1を解放する。
   b. Bi秒かけてクリアし、ステージXiを解放する。
4. ステージNを遊べるようになるまでの最短時間を求める。

変数情報：
- N: 全ステージ数
- Ai: ステージiをクリアしてi+1を解放するのにかかる時間
- Bi: ステージiをクリアしてXiを解放するのにかかる時間
- Xi: ステージiをBiの方法でクリアした場合に解放されるステージ番号


# 既存投稿一覧ページへのリンク
[一覧ページ](https://qiita.com/o_chan_t/items/fc759695acfaef8df2cc)


# アプローチ

グラフ探索問題として捉える。
各ステージをノードとし、ステージ間の移動を重み付きエッジとして表現する。
ステージ1（始点）からステージN（終点）までの最短経路を求めることで、最短時間を算出する。


# 解法手順

1. 入力からステージ数Nを読み取る。

2. グラフを表現するためのデータ構造を初期化する。各ステージ（ノード）から移動可能な次のステージ（ノード）へのエッジとその重み（時間）を格納する。

3. N-1回のループで各ステージの情報を読み取り、グラフを構築する：
   - Ai秒でステージi+1に移動するエッジを追加する。
   - Bi秒でステージXiに移動するエッジを追加する（ただし、Xi ≤ Nの場合のみ）。

4. ダイクストラのアルゴリズムを実装し、ステージ1からの最短経路を求める：
   - 優先度付きキューを使用して、現在の最短距離が最小のノードを効率的に選択する。
   - 各ノードまでの最短距離を更新しながら、グラフを探索する。

5. ダイクストラのアルゴリズムによって得られた、ステージNまでの最短距離（時間）を出力する。



# ACコード
```python:ac.py

import heapq  # 優先度付きキューを使用するためにheapqをインポート

# ダイクストラのアルゴリズムを実装する関数
def dijkstra(graph, start):
    # スタート地点から各ノードまでの距離を無限大で初期化
    distance = [float('inf')] * len(graph)
    distance[start] = 0  # スタート地点の距離は0
    queue = [(0, start)]  # (距離, ノード)のタプルをキューに入れる

    while queue:
        # 最短距離のノードを取り出す
        dist, current = heapq.heappop(queue)
        if distance[current] < dist:
            continue

        # 現在のノードから到達可能なノードについて距離を更新
        for next_node, weight in graph[current]:
            new_dist = dist + weight
            if new_dist < distance[next_node]:
                distance[next_node] = new_dist
                heapq.heappush(queue, (new_dist, next_node))

    return distance

# メイン処理
def solve(graph):
    # 4. ダイクストラのアルゴリズムを実行し、ステージ1からの最短経路を求める
    start = 0  # スタート地点（ステージ1）
    distance = dijkstra(graph, start)

    # 5. ステージNまでの最短距離（時間）を出力する
    print(distance[N-1])

if __name__=="__main__":
    # 1. 入力からステージ数Nを読み取る
    N = int(input())  # ステージの数

    # 2. グラフを表現するためのデータ構造を初期化する
    graph = [[] for _ in range(N)]

    # 3. N-1回のループで各ステージの情報を読み取り、グラフを構築する
    for i in range(N-1):
        A, B, X = map(int, input().split())
        graph[i].append((i+1, A))  # 行動Aによるエッジを追加
        if X-1 < N:
            graph[i].append((X-1, B))  # 行動Bによるエッジを追加（Xi ≤ Nの場合のみ）
    
    solve(graph)


```


# 机上トレース
入社前に学んだ効率的な業務の進め方

こんにちは！
不動産会社様にシステムを提供するITベンチャーでインターンをしている学生です！
現在は、主に顧客情報周りのシステム開発に携わっています！

半年間程インターンをさせていただいた中で一番勉強になった！と感じたことを共有させていただきます！
それは「**効率的な業務の進め方**」です！

便利なシステムを提供し、世の中の業務を効率化するIT企業にいるのに自身の業務を効率的に進められておらず、よくメンターの方にFBをいただいていました。

結論、私が業務を効率的に進められていなかった原因は、
**「最初から100%の成果物を提出しようとしてしまっていた」**
ことです。

プログラミングがほとんど未経験の状態で始めたエンジニアインターンで、最初から完璧な成果物をもっていくことは不可能に近く、時間をかけて自分の中で100%と思っていても、実際は目標物とはかけ離れているということがよくありました。



この失敗経験を経て、下記2点を業務を進める上で意識するようにしました。

:::note info
最初は60%~70%の成果物をもっていく
:::
:::note info
コードの書き方が分からなかったら、紙芝居を作る
:::

## ① 最初は60%~70%の成果物をもっていく

冒頭でお伝えした通り、新人のピヨピヨエンジニアが最初から100%の成果物をもっていくことは不可能に近いのです。
そこに時間をかけても非効率です！
最初は、60%〜70%のものを先輩・上長の方に見せてFBをいただきましょう！
そうすることで、多くの修正箇所が生まれます。

**ここに時間を注ぐのです！！**

考えてもわからないことにいつまでも時間をかけるよりも、ベテランのエンジニアの方からいただいたFBを元に修正していくほうがよっぽど効率的です。
早めの段階からFBをいただくことは、成果物の完成への近道になるだけでなく、見やすいソースコードを書くための一つの術にもなります。


## ② コードの書き方が分からなかったら、紙芝居を作る

とは言っても、60％～70％にもっていくまでも最初は難しいことがあります。
そんな時は「紙芝居」を作ることで自分が作るもののイメージが俄然湧きます！
（ラフを細かくしたみたいなものです）

この画面にボタンをつけて、このボタンを押したらこのページに遷移して・・・
みたいなものを紙芝居形式で作り、先輩・上長の方に確認してもらい認識の齟齬がなかったら
その設計書通りに作成していけばいいのです！

「来週までに何かしらの成果持ってきて！」と言われたら、この紙芝居形式のラフも一つの成果です。むやみにコードを書いて、エラーばかりでてしまっては何の成果にもなりません。

これは新人エンジニアだけでなく、少し年次の経ったエンジニアの方でも使える技ではないかと思います！
開発をしていく上で、全く手が動かなくなってしまった時にこのラフを見るだけで自分がなにを作っているのかを再確認することができます！


## まとめ

最初から完璧に作る必要はないということをインターン生時代から学ぶことができ大変勉強になりました。
大事なのはブラッシュアップ！
成果物の精度も自身の技術力もこれからどんどんブラッシュアップしていきます
Azure Cosmos DB partition と一致する全アイテムを削除する delete_all_items_by_partition_key()

# 背景

partition_key で関連アイテム全部消せるようになってたけど、
ちょっと躓くよねって話の備忘録  

しかも、以前は、GUI から削除が出来なかったけど、それも解決してましたわ

https://qiita.com/baku2san/items/5209afe13ad86778f5c7

# 使う為の設定が必要だったという話

## Cosmos DB で、[delete_all_items_by_partition_key](https://learn.microsoft.com/en-us/python/api/azure-cosmos/azure.cosmos.aio.containerproxy?view=azure-python#azure-cosmos-aio-containerproxy-delete-all-items-by-partition-key) を使うには？

CLIで設定が必要。
<font color=red>但し、この <code>capabilities</code> は、上書き定義なので、 <code>$capabilities += "{adding}"</code> のようにして定義する必要があるので注意 </font>

```powershell
az cosmosdb update --capabilities $capabilities -n $accountName -g $resourceGroupName
```

> az cosmosdb update --capabilities "DeleteAllItemsByPartitionKey" -n cosmos-name -g rg-name


今回の場合

> $capabilities += "DeleteAllItemsByPartitionKey" 

- capability の現状の確認は
   > (az cosmosdb show --resource-group rg-ai-base --name cosmos-aldu4ll5etr7a | ConvertFrom-Json).capabilities    

<font color=green>設定後、少し時間を置いたら使える </font>


- bicep への設定は以下を、databaseAccount に追加すれば OK

```bicep
    capabilities: [
      {
        name: 'DeleteAllItemsByPartitionKey'
      }
    ]
```  

https://learn.microsoft.com/en-us/python/api/azure-cosmos/azure.cosmos.aio.containerproxy?view=azure-python#azure-cosmos-aio-containerproxy-delete-all-items-by-partition-key

## Azure プレビュー機能を、サブスクリプションで確認して有効化する

変更直後に反応しなかったので、
このプレビュー機能が必要かと思ったけど、
単に更新反映時間が必要ってだけだった

- [Azure サブスクリプションでプレビュー機能を設定する](https://learn.microsoft.com/ja-jp/azure/azure-resource-manager/management/preview-features?tabs=azure-portal#register-preview-feature)  

# あとがき
【初心者の覚書】APUとは　〜要はAMD社が作った「GPU内蔵CPU」!!!!〜

新しいPCが欲しくて彷徨っていたところ、CPUにはIntel以外にAMDやその他の種類があることを知り、CPUとは別に画像処理担当の「GPU」の存在を知り、GPUにはCPU内蔵型のものと外付けのものがあると知り、それとは別個に「APU」という存在があることを知り、今回は「APU」について覚書したい。

ぜひCPUについて迷走した拙記事もお目にしていただけたら幸いだ。

https://qiita.com/dameNingen_ganbaru/items/e1954af90599ba36487d

![スライド1.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2867756/1f2b93be-de62-4f88-0356-98de61128193.jpeg)



# APUとは〜Accelerated Processing Unit〜
> APU(Accelerated Processing Unit)とは、CPUとGPUを統合したプロセッサーのことで、AMD製のグラフィック機能を内蔵したCPUに使用されます。
[高性能な内蔵グラフィックに注目！AMDから最新APU「Ryzen 8000G」シリーズが登場](https://www.sycom.co.jp/media/archives/3284/#:~:text=APU(Accelerated%20Processing%20Unit)%E3%81%A8,CPU%E3%81%AB%E4%BD%BF%E7%94%A8%E3%81%95%E3%82%8C%E3%81%BE%E3%81%99%E3%80%82)

最近できたものだと思っていたのだが、2006年から開発されてきているとのことだ。
人類、凄い。

"APU"とは、AMDが2006年から開発を行なっている、CPUとGPUとを合成・統合させた新しい製品の名称とのことである。
「CPU」、「APU」と2文字を同じくしているため一般名詞のように聞こえるが、固有名詞とのことだ。
「ポテト」や「ハンバーガー」はジャンクフードの一般名詞だが、「ハッピーセット」はマクドナルドの最強な固有名詞なので、「APU」とはハッピーセットのようなものだと捉えて良いだろう。()
難しく考えすぎていたが、一言で表すとAMDが作った「GPU内蔵CPU」のことだった。

# Acceleratedとは
> 加速する、早くなる　の意
[「acceleratedとは 意味・読み方・使い方」、weblio](https://ejje.weblio.jp/content/accelerated)

Acceleratedには「加速する」という意味があるため、和訳的には「加速処理装置」のようになるのだろうが、あくまでもAMD社の開発製品であるため、Intelや他社が同様の製品を指す場合には「GPU内蔵CPU」や「統合グラフィックス」などと表現している。

また、内蔵GPU、統合GPU以外の表現に「iGPU(internal GPU)」というものがあるようだ。（気づかずにまた記事を量産するところであった）

> iGPU（internal GPU）とは、グラフィック処理に特化したGPU(Graphics Processing Unit)のうち、CPUやチップセットなどの一部として実装されたもの。
[「iGPU 【internal GPU】 内蔵GPU / 統合GPU」、IT用語辞典 e-words](https://e-words.jp/w/iGPU.html#:~:text=iGPU%20%E3%80%90internal%20GPU%E3%80%91%20%E5%86%85%E8%94%B5GPU%20%2F%20%E7%B5%B1%E5%90%88GPU&text=iGPU%EF%BC%88internal%20GPU%EF%BC%89%E3%81%A8%E3%81%AF,%E3%81%A8%E3%81%97%E3%81%A6%E5%AE%9F%E8%A3%85%E3%81%95%E3%82%8C%E3%81%9F%E3%82%82%E3%81%AE%E3%80%82)




# APUの特徴
「APU」がGPU内蔵CPUということがわかったが、外付けGPUを利用した場合と何が違うのか、むしろ外付けGPUを使う方がサクサク画像処理加速できるのではないかとイメージをしていたが、下記の画像を見て、考えを改めさせられた。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2867756/7fe15c76-6346-f492-30cd-b05827ff08d8.png)
画像参照：[Hybrid CPU/GPU/APU accelerated query, insert, update and erase operations in hash tables with string keys](https://link.springer.com/article/10.1007/s10115-023-01891-w)


画像を見ると、「GPU」と「CPU」のメモリが同期されていることが読み取れる。
つまり、仲を遮る天の川がなくなり毎日七夕状態の織姫と彦星で笹の葉に吊り下げられたお願い事をうまいこと叶いまくり状態、のように、いい感じに画像処理と汎用処理のメモリが共有されいい感じになっていることがわかる。

# まとめ

「APU」とはCPUを開発しているAMD社が作ったGPU統合型CPUである。


# 参考にした記事

https://ja.wikipedia.org/wiki/AMD_Accelerated_Processing_Unit

https://link.springer.com/article/10.1007/s10115-023-01891-w
液晶モニタが壊れた悲しみを綴ります

## 液晶モニタが壊れた。

かなり長く使っていたんだけど、壊れるときは必ずやってくるものだ。

ちなみに、どれほど古い液晶モニタかというと**青色LEDが出来たのでバックライトが液晶になった**時のモニターだったりする。
え？と最近の人は思うかもしれないが、液晶モニタのバックライトは、昔は蛍光灯だったりした。世の中、地味に進歩しているのだ。蛍光灯の前は何だったっけなぁ…昔過ぎて思い出せないや。

壊れたモニタは、何せ初期のモニタだったので、バックライトの輝度を上げると色のバランスが崩れてしまうというかなり残念なものだった。輝度を上げると画面が青くなっちゃうのよね。だから、輝度最低で使うしかなかった。輝度最低で使っていても十分に明るかったけど。そして、HDMIで接続できるけど当然スピーカーなんてものは付いていない。しかも、物理スイッチではなくタッチに反応するスイッチで操作するのだが、その反応がいまいちで本当に使いにくかった。でも、買っちまったものは仕方がない。というわけで、頑張って使っていた。

ちなみに、壊れた順番はこんな感じ。

1. 最初に壊れたのは、HDMI ポートだった。
映らなくなったのだ。でも、HDMI は二つある。だから、HDMIの切り替え機を使ってしのいでいた。
1. 次に壊れたのは、電源周辺の何か。
たまに電源が入らないという症状が出てきた。でもまぁ、何回かやれば電源が入るので、何とかだましだまし使えていた。

最初に壊れたのが入力が二系統ある HDMI だったのはラッキーだったかもしれない。おかげで寿命はちょっと延びた。

## そして、今日。

電源を入れると操作系のLEDが見たこともない変な反応をした。んで、怪しいと思って電源を抜いて刺したら、LEDも光らなくなった。そう、ご臨終です。
というわけで、泣く泣く amazon で注文しましたよ。システムメンテナンス用の小型モニターを。まぁ、既に常用モニタではなく、システムトラブル時に出動するモニターとして使っていたので、それ専用のモニターにしてしまいました。もう、アナログRGBと HDMI があれば良いやと割り切って。DVI-D がたまに欲しくなるけど、それはまた別の時に考えよう。

しかし、いつまでたってもアナログRGBはなくならないよね。古い機械が残っている限り、アナログRGBも生き残る。うちも、NASのモニターがアナログRGBだから、どうしようもない。
そろそろ、古いNASを捨てるべき時が来たのかもしれない。そもそもOSをUSBメモリにインストールしているという時点で運用に無理がある。
でも、システムを戻すにしても、やっぱりアナログRGBモニターが必要なんだよなぁ。モニターが届くまでに1週間かかるらしいので、しばらくはそのNASのデータはみえない。
こういうときは、シリアルコンソールの方が便利だよな、やっぱり。

## そして我に返る

そして、ここまで書いてふと思った。**全然からあげ帝国と関係がない**。まて、次に投稿予約している奴もからあげ帝国とは全く関係がない。これはマズいんじゃないのか？ChatGPTにやらせ隊のアドベントカレンダーに書いたネタの方がよっぽどからあげだ。
いや、そもそもからあげ帝国らしいアドベンドカレンダーネタって何だ？ChatGPT か、なにかモノを作らないといけないような気がしてきた。今回、壊れましたってことしか書いていない。何も作っていない。いや、**壊れた液晶モニタ**というゴミを作ったぐらいか？そもそもこの記事だってゴミと言えばゴミだ。

ゆゆしき問題である。

電子工作も出来ない凡人である私が、からあげ帝国で存在感を出す方法として思いつくのは、**いるだけでウザい**人ぐらいだ。そして、既にそうなっているような気もする。

ま、いっか。ダメだったら突っ込み入れてください。それを読んで一人静かに落ち込みたいと思います。

## ところで

Qiita にふさわしい記事なのかどうかちょっと不安になりますが、一応エンジニアが昔語りをしているのでギリギリセーフかなと思うことにしました。技術的に誰かの役に立つ記事ではないけど…
ぷよぷよプログラミングで遊んでみる

# 変遷
今まで社内の取り組みで何をやってもいいとのことなので、ノベルゲームを作っていた。
はじめにRen’pyを使ってローカル環境で動くゲームを作り、WEBサーバに乗せてネット経由で遊べるように発展させて、去年は自社のマスコットキャラが増えたのでゲームのお話の内容をバージョンアップさせたりしていた。
qiitaに記事を書くことが毎年恒例にになっているので去年書いた記事のリンクも乗せておく↓
[自社のマスコットキャラクターをゲームに追加実装](https://qiita.com/masuiP/items/d4fb95f405d17def7fe9)

今年はどうしようかと思っていた。流石に4年連続でノベルゲームのバージョンアップというのも飽きが来ていた。そんなとき社内の本棚に気になる文言を見つけた。それはぷよぷよプログラミングだった。ぷよぷよは好きだし今年はこれにしようと独断で決めた。

# ぷよぷよプログラミングに挑戦
最初は本の通りにプログラミングを進めていくのかなと思ったら、ネットでも無料で公開されていた。
https://puyo.sega.jp/program_2020/

準備としてはPCとネット環境さえあればOK。誰でも簡単に始められる。
プログラミングの内容としては、歯抜けになって正常に動作しないコードに対して、正しいコードがあるからそれを書き写して正しく動作させようといったものだった。プログラミング初心者の私には都合が良い内容だった。
まずは手を動かすのが大事な第一歩。

最初はぷよがただ落下してくるだけで、消えないし、回転させられないし、動かせないし、といった具合のものを徐々に修正していく方式だった。
一通り写経を済ますとゲームとして遊べるちゃんとしたぷよぷよが出来上がった。ここまでは公式の教本通りに実施していけば問題なく行える。

# 写経後にあれこれ
今まで作ったノベルゲームのときもそうだが、この取り組みをする自分のチームには、弊社のマスコットキャラの絵を描いてくれる人を多く擁するのでゲームの"絵"の部分を諸々差し替えてみた(本記事では伝えられないがBGMも流れるようにしてある)。
ゲーム開始前のスタート画面を入れたり
![start.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/525892/c615034c-95ab-8a41-0482-02b5bc293125.png)

背景を変えたり
![キャプチャ.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/525892/9f450c86-5656-21b1-04fb-eeb1228c700b.png)

ぷよを変えたり
![キャプチャ.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/525892/ea38c5f1-5775-2eb1-2afc-7138e767f6a5.png)

ゲームオーバーや全消しの演出を変えたりしてみた
![キャプチャ.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/525892/27c6bc72-7086-f0cd-523b-0fbf81e503a0.png)

![キャプチャ.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/525892/a735a6ba-89df-bb8a-4687-cf73d1b55cdb.png)

# 終わりに
自分はプログラミングの完全な初心者であるため、実際にコードを触ってちゃんと動作することが確認できるぷよぷよプログラミングは楽しく進めることができた。また何かしらやってみたくある。
画面上のQRコードが読み込めるChrome拡張がQRコードのテストに使えて便利すぎる

[ソフトウェアテストの小ネタ - Qiita Advent Calendar 2024 - Qiita。](https://qiita.com/advent-calendar/2024/software-testing-koneta) 7日目の記事です。

こんにちは、uechanです。
**ソフトウェアテストの小ネタアドカレなのでショートショートな小ネタ記事になります**

みなさんこちらのChrome拡張をご存じでしょうか？

[なぞってQRコードリーダー](https://chromewebstore.google.com/detail/%E3%81%AA%E3%81%9E%E3%81%A3%E3%81%A6qr%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%80%E3%83%BC/lnhgdalhhjkfmmdjbkhilkinoomigdkc)
![{9B1CE31F-FBCC-499A-8D5B-65A146CF68F7}.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/705249/fe155682-9947-9fcb-c32f-4a24573097a4.png)

なんとこのQRコードリーダー
PCの画面上のQRコードを範囲しているだけで読み込めるんです！

![Timeline 1.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/705249/dfd71d70-277b-9e54-00f1-41f8c8ee2a52.gif)
使い方も簡単です！
1. 拡張のアイコンを押す
1. 読み込みたい範囲をドラックアンドドロップする
1. 読み込んだURLが表示される
1. OKを押すとそのURLに遷移する

Webカメラ経由でQRコードを読む拡張はありましたが **画面上のQRコードをなぞって読めるのが便利です**

QRコードを生成する機能をテストしたいときにぜひお使いください！！
Arch LinuxにPolybarを導入する

Polybarの導入についての備忘録です

![スクリーンショット_2024-12-06_12-43-30.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3931772/f5825776-1069-27bc-f1fb-b957d31ea321.png)

# インストール
```
sudo pacman -S polybar
```

# 各種設定（dotfiles）を「.config/polybar」に配置
私はこれを参考にしました。↓
https://github.com/gh0stzk/dotfiles
かっこいいですね

（注：環境によってconfigの System Variables を変更しなければならない、かもしれません。）

# フォントを導入
Polybarで表示できるのは基本的に文字だけです。
つまり、アイコンなどを表示するためにはそれ用の特殊なフォントが必要です。

以下は個人的に必要なフォントです↓
```
yay -S ttf-jetbrains-mono ttf-font-awesome ttf-material-design-icons-desktop-git ttf-meslo-nerd-font-powerlevel10k
```

# i3wmの設定
i3のconfigに以下を追加します
```
# settings for polybar
gaps top 38
exec_always --no-startup-id $HOME/.config/polybar/launch.sh
```
gaps topを設定することで、デスクトップの上側にPolybar用のスペースを確保することができます。

# Xfce + i3wm環境にしてる場合に必要な設定
Xfce設定の セッションと起動→現在のセッションからxfce4-panelの再起動スタイルを「しない」に変更して、「セッションを保存する」を押します。

この設定を変えると、私の環境ではキーボードの音量キーが動作しなくなったのでi3wmの方で設定します
以下をi3のconfigに追加します
```
bindsym XF86AudioRaiseVolume exec --no-startup-id pactl set-sink-volume 0 +5%
bindsym XF86AudioLowerVolume exec --no-startup-id pactl set-sink-volume 0 -5%
bindsym XF86AudioMute exec --no-startup-id pactl set-sink-mute 0 toggle
```
【AWS】API Gateway + Lambda + RDS Proxyの構築手順（Proxy経由だと性能は劣化するのか？）

# 概要
API Gateway + Lambda + RDS Proxyの構築方法を紹介します。
RDSの構築までは以下の記事で紹介しましたので、この記事ではそこからRDS Proxy経由に変更する手順を紹介します。

https://qiita.com/Ryo-0131/items/f1a771570b7dc610a14d

### 経緯
AWS LambdaからRDSにアクセスするたびにDB接続が確立すると、接続数の急増によりリソースが逼迫することがあります。最大接続数を超えた場合は`Too many connections`になり、アプリがエラーを返すこともあります。

RDS Proxyを使うとコネクションプーリングを利用できるのでDBコネクションの使い回し＆メモリ負荷の軽減が可能！と言うことで、設定を実施しました。

> Amazon RDS Proxy を使用すると、アプリケーションでデータベース接続をプールおよび共有して、アプリケーションのスケーリング能力を向上させることができます。
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/rds-proxy.html

# 手順
- ①Secrets Managerのシークレット作成
- ②SecurityGroup設定
- ③RDS Proxy作成
- ④LambdaからRDSへのエンドポイントを変更

## ①Secrets Managerのシークレット作成
（RDS Proxy作成時にシークレットが必要なので作成します）
- Secrets Manager -> 「新しいシークレットを保存する」を選択
    - シークレットのタイプ：「Amazon RDS データベースの認証情報」を選択
    - 認証情報：ユーザー名とパスワードに、それぞれRDSの情報を入力
    - データベース：該当のDBを選択
    - シークレットの名前：任意に命名

## ②SecurityGroup設定
- RDS Proxy用のセキュリティグループを作成
    - インバウンドルールに、Lambda用のセキュリティグループを指定
- RDS用のセキュリティグループのインバウンドルールに上記で作成したものを追加
    - インバウンドルールにLambda用のセキュリティグループが残っていれば削除します

※RDS用とRDS Proxy用のセキュリティグループは別々にしてください。疎通エラーになることがあります。詳細は以下の記事で紹介

https://qiita.com/Ryo-0131/items/ae8458a394208c68683d


## ③RDS Proxy作成
- RDS -> プロキシ -> 「プロキシの作成」を選択
    - エンジンファミリー：RDSのエンジンを指定
    - プロキシ識別子：任意に命名（プロキシ間で一意である必要あり）
    - データベース：該当のDBを選択
    - Secrets Managerのシークレット：①で作成したシークレットを選択
    - サブネット：該当VPC内のサブネットを二つ指定（最低二つです）
    - 「追加の接続設定」の「セキュリティグループ」：上記②で作成したRDS Proxy用のセキュリティグループを選択
- プロキシが作成されたら「プロキシエンドポイント」からエンドポイントをコピー

## ④LambdaからRDSへのエンドポイントを変更
- Lambda関数の「環境変数」のDBホスト名をコピーしたもので置き換える

以上で構築は完了です。
これでAPI GatewayのURLを叩けば、RDS Proxy経由になっているはずです。

CloudwatchlogsでRDS Proxy用のロググループが作成されるので、そこから確認も可能です。

## RDS Proxyにすると処理性能が劣化する？
いざRDS Proxy経由にしてしばらくリクエストを投げっぱなしにすると、Proxy経由前よりもメモリ消費は確実に抑えられることがわかりました。

ただ、（私が使用したアプリの場合は）代わりに単発のリクエスト性能が悪化することもわかりました。

調べると同じような現象の記事が多く見られます。
※全ての記事でそのように言われているわけではありませんので、100%該当する、と言うわけではない？

> RDS Proxy無しの時より少しパフォーマンスが悪化しています。
https://dev.classmethod.jp/articles/rds-proxy-connect-benchmark/

> 代わりに若干平均応答時間が遅くなっているようです。
https://spirits.appirits.com/role/engineer/17388

> RDS Proxyを挟むと平均で約2.6ms、90パーセンタイルで約2.5ms程度のオーバーヘッドが発生していることが分かります。
https://dev.classmethod.jp/articles/calc-rds-proxy-latency/

これは、コネクションプーリングの初期化で時間が要するため、単発リクエストの性能が劣化するのでは？と思っています。私が使用したプログラムの場合、以下のような結果となりました。

- RDS Proxy経由では無い場合：単発1.5 - 2.5秒以内
- RDS Proxy経由の場合：単発4.0 - 4.5秒以内

VPCにあるとENI作成のため遅くなる？とも思いましたが、RDS直接の時もLambdaをVPCに置いていたので、今回の劣化には関係なさそうです。また、RDSのスペックを2段階あげて実施してみましたが、それでもやはりProxy経由ではない場合より、遅い結果となりました。

と言うことで、以下が私なりの検証結果です。

- RDS Proxy経由だとコネクションプーリングがあるので、連続したリクエストが続く場合は、DB接続数が減り、メモリ消費量も抑えられる。また、最大接続数を超えた場合の`Too many connections`エラーを回避できる
- ただし、RDS Proxy経由だと（コネクションプーリングのオーバーヘッドのため？）単発リクエストの性能は劣化する

単発性能を劣化させずにRDS Proxy経由を実現できるよ！と言う方法をご存知の方がいましたら、ぜひ教えてください。
DifyとFirecrawlをDocker Composeでローカル環境で連携する

Difyは生成AIを対象とした開発プラットフォームで、AIを搭載したアプリケーションをローコードで作成できます。

https://dify.ai/jp

Difyには様々な機能がありますが、その中でも[オープンソースのクローラーFirecrawl連携する機能](https://docs.dify.ai/ja-jp/guides/knowledge-base/sync-from-website)があります。Firecrawlと連携させると、WebをクローリングしてRAGを構築できるようになります。

本稿では、DifyとFirecrawlを両方ローカル環境にDocker Composeで立ち上げて、連携させます。Docker Composeのoverrideの設定を使うことで、同じネットワークに所属させます。

## 環境
- Docker version 27.3.1, build ce12230
- Docker Compose version v2.29.7
- Dify 0.12.1
- Firecrawl 2024年12月4日時点のコミット `41d85920` を利用

## Difyの構築
まず[DifyをGitHubからclone](https://github.com/langgenius/dify)して適切な断面にチェックアウトしておきます。

ネットワークの設定を変更します。dify側のDocker Composeのサービスのうち`api`を、firecrawl_backendというネットワークに所属させます。

```yaml:docker/docker-compose.override.yaml
services:
  api:
    networks:
      - firecrawl_backend
      - ssrf_proxy_network
      - default

networks:
  firecrawl_backend:
    external: true
```

あわせて、ローカル環境でwell-known ポートを使われるのが好きではないので、適当な値に変更しておきます。

```.env:docker/.env
EXPOSE_NGINX_PORT=9999
EXPOSE_NGINX_SSL_PORT=9998
```

## Firecrawlの構築
[FirecrawlをGitHubからclone](https://github.com/mendableai/firecrawl)して、.envを以下のように設定します。

```apps/api/.env
USE_DB_AUTHENTICATION=false
```
[FirecrawlにはメモリとCPUの使用量を見て動作を止める設定](https://github.com/mendableai/firecrawl/blob/35d9d8e822b7b8c05cd87df3f53828785fd8676c/apps/api/src/services/system-monitor.ts#L208-L213)があるので、必要に応じて緩和します。特にDifyとFirecrawlの両方を同時起動するとメモリを結構使用するため、この設定がないと安定して動かない場合があります。
筆者の環境（16GB RAM Chromebook）では必要で、`Cant accept connection`というエラーが表示されました。

```docker-compose.override.yaml
services:
  worker:
    environment:
      MAX_CPU: 1
      MAX_RAM: 1
```

## DifyとFirecrawlの連携
準備ができたら、DifyとFirecrawlを起動します。

- http://localhost:9999 でDifyが起動していること
- http://localhost:3002/admin//queues でfirecrawlが起動していること

を確認します。
必要に応じて以下な感じで、DifyのAPIがFirecrawlと同じネットワークに入れているかを確認します。

```
$ docker network inspect firecrawl_backend | grep -C 5 firecrawl-api
$ docker compose exec api curl firecrawl-api-1:3002
```

正常に起動できていることを確認できたら、Difyの画面で「データソース」からFirecrawlの設定をします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/50391/b8309ac7-db33-a424-678c-2f7c26dc9f85.png)

Base URL `http://firecrawl-api-1:3002` を設定するのがポイントです。Difyのコンテナ側から見てFirecrawlのAPIサービスに接続できるホストを指定します。
API Keyの入力は必須ですが、今回Firecrawl側でキーは設定していないので、適当な文字列でOKです。

あとは、必要なURLを入力してクロールを実行します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/50391/1787d8e4-bd30-d5c7-25d5-712998aaf363.png)

これで、ローカル環境にDocker Composeで立ち上げたDifyとFirecrawlを連携させることができました。

あとは、Difyを利用した通常のRAGと同様の手順で、クローリングした結果をもとにベクトルデータベースへ格納し、検索ができるようになります。

DifyはRAG関連機能のGUIが充実しているのが特徴だと思っています。Firecrawl連携のようにRAG周辺の機能をうまく使うことで、さまざまな場面でRAGを導入しやすくなると思っています。
【TypeScript】配列同士を結合する型の実装（type-challenges 初級編 533・Concat）

## お題
配列同士を結合する型`Concat`を実装する（JavaScriptの`Array.concat` 関数を型システムに実装する）。

## やりたいこと
```typescript
const tuple = [1] as const

type Result1 = Concat<[1], [2, 3]> // => [1, 2, 3]
type Result2 = Concat<typeof tuple, typeof tuple> // => [1, 1]
type Result3 = Concat<[1, "a"], [true, 2]> // => [1, "a", true, 2]
```

## 解答
```typescript
type Concat<T extends readonly any[], U extends readonly any[]> = [...T, ...U];
```

## 解説
### 処理の流れ
- ```<T extends readonly any[], U extends readonly any[]>```
`T`と`U`が読み取り専用の配列のみ受け取るように制限する。
- `[...T, ...U]`
それぞれの要素をスプレッド構文によって展開し、配列を結合する。

### そもそも`Array.concat`関数とは...
`Array.`インスタンスのメソッドで、2つ以上の配列を結合する際に使用する。既存の配列を変更せず、新しい配列を返す。
```typescript
const array1 = ['a', 'b', 'c'];
const array2 = ['d', 'e', 'f'];
const array3 = array1.concat(array2);

console.log(array3); // => ["a", "b", "c", "d", "e", "f"]
```

### スプレッド構文とは...
- 配列に`...`を使用することで、要素を展開できる。
- 好きな位置に記述できるので、要素と要素の間に挿入することも可能。
```typescript
const arr = [1, 2, 3];

const newArr1 = [...arr, 4]; // => [1, 2, 3, 4]
const newArr2 = [0, ...arr, 4]; // => [0, 1, 2, 3, 4]
```

### typeof演算子とは...
https://qiita.com/yuto99999/items/44161921ff23a149cba5#typeof%E6%BC%94%E7%AE%97%E5%AD%90%E3%81%A8%E3%81%AF


## 参考記事
### Array.prototype.concat()
- [Array.prototype.concat() - JavaScript | MDN](https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array/concat)
### スプレッド構文
- [配列のスプレッド構文「...」 | TypeScript入門『サバイバルTypeScript』](https://typescriptbook.jp/reference/values-types-variables/array/spread-syntax-for-array)


## 今回の問題
https://github.com/type-challenges/type-challenges/blob/main/questions/00533-easy-concat/README.ja.md
ワイの今までの失敗談を徒然なるままに語る

## はじめに

[レバウェル開発部アドベントカレンダー](https://qiita.com/advent-calendar/2024/levwell)7日目担当です。

こんにちは！2024年現在、今年に入ってからレバウェル開発部で働いていますが、これまで多くのプロジェクトを経験し、そして多くの失敗もしてきました。今回は、前職までに私が体験したしくじりやヒヤリハット事例をご紹介し、それを通じて得た教訓をお伝えします。同じような状況に直面している方々の参考になれば幸いです！

## 顧客対応①　〜日和って要望丸呑みして客にナメられた🥺〜
### お客さんからお金たくさんいただくの、怖いですよね！

お客さん😡）
なんでそんなにかかるんですか！！
こんなにお金かけてるのに、おたくのシステム、ショボイね！！
こんなにお金かけてるんだから、あれもできるよね！これもできるよね！

私😇）
あわわわわ！や、やりまひゅう😭

#### こんなかんじで無理して対応すると・・・

お客さん😡）
前回は追加料金なしで要望対応してくれたのに！なんで今回はお金取るの！！

といったかんじで、感謝されるのではなく、「やって当たり前」になることもしばしば
まさに地獄！！

### このしくじりで得るべき教訓は・・・
お金もらってるからといって日和らずに毅然とした態度で対応しましょう
- この費用の根拠は、⚪︎⚪︎です！
- 弊社はこの金額でやらせてもらってます！

あんまり無理言ってくるお客さんの仕事はお断りさせていただく！
無理な追加要望は次フェーズにまわして、次フェーズの見積もりの提案
体感的な話ですが、お客さんは金額が安いとそのプロジェクトを軽くみられる傾向があり、金額が高いと逆に一生懸命取り組んでくださる不思議🤣
日和らずちゃんと費用請求しましょう！

## 顧客対応②　〜お客さんのミス、こっちになすりつけ😡〜

### いつ終わりますか！！納期過ぎてますけど！！

納品後、顧客の担当者が社内で「まだ納品されてない」と報告し、怒りの矛先がこちらに向いたことがありました。
納品期限守ったのに、顧客の会社の担当者じゃない方から
「いつ終わりますか！！納期過ぎてますけど！！」と怒りの連絡が来たことがありました😭

担当者は「まだ納品の連絡ないんですよ〜」と社内で答えていたらしい😡
空返事したのち、納品したシステムを検品せず、ふところで温めてた模様😡
しかし、幸運にも納品時にメールをCCで他の社員にも送っていたため、その社員が「それは情シス側のミス」と指摘してくれ、私の無実が証明されました。

### このしくじりで得るべき教訓は・・・
世の中にはいろんな会社があります。。。
担当者と１対１の連絡は避け、証人となってくれる人を巻き込みましょう！
落ち度がないことが証明できるよう、証拠を残しましょう！
証明できないと泣き寝入りになってしまう可能性があります！！

## システム開発①　〜本番リリース！超常現象に気をつけろ😭〜

### 大規模な本番リリース、本当に怖いですよね・・・
しっかりテストした！もう大丈夫だ！用意周到に計画していても
画面が真っ白！
メールが飛ばない！
etc…
なんでだー！なんでなんだー！！😱
画面真っ白！ワイの頭も真っ白！！😇
まさに地獄！！
私はこの現象を個人的に「超常現象」とよんでいます😚

### このしくじりで得るべき教訓は・・・
本番リリースのメンテナンス時間に、超常現象に対応するゆとりを持たせると良いかもしれません！
素早く対処できるよう、経験した超常現象のパターンを蓄積していきましょう！
超常現象が起きるかも！と心の準備をしておくと少しはテンパらずに対処できるでしょう！
当時の構築していた本番環境がレガシーめだったからかもしれません・・・
ただ、本番環境だけ上手くいかない！ということを他所でも耳にします🥺
そのため、超常現象に備えたほうが良いと個人的には思います！

## システム開発②　〜対岸の火事だと思うなよ🔪〜

### 自分はメンバーだから！！責任者じゃないし！！俺シラネ！！

こんな考え持ってると地獄をみるかもしれませんよ〜😇

数年前、3年かけて製作する比較的大規模なプロジェクトがありました。
プロジェクト開始から約2年たってもPMの上司からは音沙汰がありません。
大丈夫なんですか？！と聞いても、上司「ああ大丈夫だ！炎上しないよう俺がなんとかする！！」なんだか匂う台詞ですね。。。
あれほんとに終わんの？俺シラネ！別の仕事忙しいから、まだ実装始まらないといいなあ😚

#### その後しばらくして・・・
ある日フロントエンジニアの後輩が画面のモック作ってくれと依頼をもらったようです。
その依頼をもらった後輩は、「これ全然話進んでないですよ！絶対終わらないですよ！」とアラートを投げてきました...！
すったもんだあった後、そのPMやっていた上司は退職し、代わりにPMの役割が私にまわってきてしまいました😭
納期に間に合わなければ顧客のお偉いさんの顔に泥を塗ることになるかもしれない！損害賠償で会社が潰れてしまうかも...？！
まさに地獄！！

#### うおおおおお😭
残り1年ちょっとで要件定義から納品まで終わらせなければならい状況🔥
エンジニアが足りないので業務委託のエンジニア６人追加参画、
それでも足りない分は私とサブリーダー2名のハードワークでなんとか間に合わせました😂
リプレース案件だったのですが、データ移行のバッチがリリース2週間前まで上手くいっておらず、朝起きたらプレッシャーで胃液が逆流する毎日でした🤮

本番リリース時は案の定、超常現象が起き、画面が真っ白になりました😭
これはApache再起動で解決・・・

### このしくじりで得るべき教訓は・・・
自分が参画するプロジェクト、メンバークラスだとしても自分ごととして考え、様子どうなってるのかちゃんと確認したほうがいいかもしれませんよ！
俺シラネ！してたら、なんか気づいたら自分が責任負うことになってるかもしれませんよ👀
怖いですよ〜

## おわりに

エンジニアリングはトライ＆エラーの連続です。今回紹介した私の失敗談が、ご覧くださったの皆さんの参考や励みになれば幸いです。次回からは、さらにスムーズにプロジェクトを進められるように一緒に成長していきましょう！
VB.Net基本的な型

### VB.Netにおける「型」の重要性と柔軟性を理解しよう
## はじめに: 型を明示する意義とは？
プログラミングにおいて「型」は、データの性質を定義し、プログラムの動作を正確に制御するためのルールです。型を明示することで、次のような利点が得られます。

エラーの防止: コンパイラが型をチェックし、不正な操作を未然に防ぎます。
コードの可読性向上: データの意図が明確になるため、他の開発者が理解しやすくなります。
パフォーマンス向上: 適切な型を選択することで、メモリ使用量を最適化できます。
保守性の向上: 型情報があることで、コードの修正や拡張が容易になります。
COBOLのPIC句のように、VB.Netでも「このデータは何か」を明確にすることは、信頼できるプログラムを作る基盤です。

## VB.Netの柔軟性: 型に関する制約が緩い
VB.Netは他の言語と比較して型に関する制約が緩く、初心者や柔軟性を重視する場面で便利に使える特徴を持っています。
具体的には、Option StrictとOption Explicitの設定により、以下のように動作を調整できます。
→どちらもプログラムの最初で設定を行います。

Option Strict Off: 型変換を暗黙的に許可し、異なる型のデータを柔軟に扱えます。

メリット: 初学者にとって敷居が低い。
デメリット: 意図しない型変換やパフォーマンス低下のリスクがある。
```

Dim value As Object = "123"
Dim result As Integer = value ' 暗黙的な型変換が許可される
```
Option Explicit Off: 未宣言の変数を自動で扱えますが、タイポによるエラーが発生しやすくなります。

メリット: テストや一時的なコードで便利。
デメリット: バグを埋め込みやすい。
```

Dim number As Integer = 10
num = 20 ' 未宣言でも動作するがエラーの原因になりやすい
```
これらの柔軟性は強力ですが、意図しない動作を避けるために、Option Strict OnとOption Explicit Onを使用することが推奨されます。これにより、VB.Netの型安全性を保ちながら、効率的なコーディングが可能になります。

VB.Netの代表的なデータ型
以下は、VB.Netでよく使うデータ型の一覧とその特徴です。

## Integer

概要: 32ビットの整数型。整数値を扱います。
使用ループのカウンタや計算。
```
Dim num As Integer = 100
```
## Double

概要: 倍精度浮動小数点型。小数を含む数値を扱います。
使用数学的計算や測定値。
```
Dim pi As Double = 3.14
```
## String

概要: テキストを扱う型。
使用名前やメッセージの保存。
```
Dim name As String = "Alice"
```
## Boolean

概要: 真(True)または偽(False)を扱います。
使用条件分岐やフラグ管理。
```
Dim isActive As Boolean = True
```
## DateTime

概要: 日付と時刻を管理する型。
使用日付計算やログ記録。
```
Dim today As DateTime = DateTime.Now
```
実務で役立つ設定: Option Explicit と Option Strict
VB.Netの柔軟性を活かしつつ、安全にコーディングするために、以下の設定が役立ちます。



Option Explicit On: すべての変数を明示的に宣言する必要があります。これにより、タイポや未定義の変数の使用を防ぎます。

```
Dim count As Integer = 0
cnt = 5 ' エラー: cntは未定義
```
Option Strict On: 暗黙的な型変換を禁止します。これにより、型のミスマッチを防ぎ、意図しない動作を防ぎます。


```
Dim number As Integer = 10
Dim text As String = "5"
number = text ' エラー: 型が一致しない
```

## まとめ
VB.Netでは「型」を正しく活用することで、信頼性の高いプログラムを効率的に作成できます。一方で、柔軟性が高いため、設定次第でプログラムの挙動が大きく変わる点に注意が必要です。

初心者はOption Explicit OnとOption Strict Onを有効にして、堅牢なプログラムを書く習慣をつけましょう。
型に関する理解を深めることで、パフォーマンスや保守性が向上し、実務でも即戦力となります。
「型」はプログラムの「土台」です。しっかりと理解し、正しく活用することで、信頼できるコードを書けるエンジニアを目指しましょう！

## 注意書き
この記事は、生成AI（Chat Gpt）を基に作成しています。
Javaを基礎から学ぶその7　オブジェクト指向とは　

この記事は[JavaとPythonを基礎から学びたい私のための Advent Calendar 2024](https://qiita.com/advent-calendar/2024/aruhitonocalendar)の7日目の記事です。
まったく知識がないので今更ですが学習します。
# オブジェクト指向とは
<b>明確な答えは無いようです。</b>自分なりの答えにはなりますが、おそらく下に書いた感じのやつです⇩
"順番にひとつひとつ処理を書いていくのとは違い、処理を分割してあたかも人間の動きのように処理をすること"
のようです。
動きは変わらないけど、処理ごとにまとめることで書きやすく、見やすくするといった感じでしょうか。
## 手続き型プログラミング
先ほど述べた、 "順番に一つ一つ処理を書いていく" 処理は手続き型と呼ばれるようです。
例）　一日の流れ

目を開ける→時計のほうを向く→時間を確認する→上半身を起こす→立つ→布団を整える→朝ご飯を準備する→繰り返し（ご飯を食べる→味噌汁を飲む→おかずを食べる）→もし・・・

とこんな感じで延々と続く考え方が手続き型プログラミングの特徴のようです。処理を一つ一つまとめて書いていくので、延々とかかります。しかも、朝食・昼食・夕食で処理はほとんど変わらないのに同じことを繰り返し書くことになります。
見にくいし、すぐに理解することもできません。
## オブジェクト指向
これに対してオブジェクト指向ではこんな感じになるようです。
例）　一日の流れ

#### ①　処理をまとめる
A 起きる
```
目を開ける→時計のほうを向く→時間を確認する→上半身を起こす→立つ→布団を整える
```
B ご飯
```
朝ご飯を準備する→繰り返し（ご飯を食べる→味噌汁を飲む→おかずを食べる）→もし食べ終わったら片す
```
C 身支度
```
歯を磨く→着替える→荷物を準備する
```
とこんな感じでまとめられます。これらひとつひとつは<b>部品</b>というそうです
#### ②　まとめたものを並べる
A 起きる→B ご飯→C 身支度
こんな感じで並べることができます。さっきよりも見やすくなったのがわかると思います。
まとめると、こんな感じです。
![IMG_20241206_150318.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2961125/e93d2fca-668d-4a00-65fb-d43d04eb8c43.jpeg)


## 三大機能
三大要素とか三大機能とか言われるものが存在しているようです。
#### 継承
部品を流用し、似た部品を作ることができる機能です。
#### 多態性
別物の部品でも、大体同じなら同じようなものだとする考え方です。
#### カプセル化
特定のクラスからしかアクセスできないようなクラスを作る、制約を設けるものです。意図しない挙動を防ぐために使われているみたいです。
# まとめ
手続き型とオブジェクト指向の2種類が存在する。手続き型は処理を並べたもので、見にくい。これに対してオブジェクト指向では処理をまとめて、それぞれのまとまりをつなげる方法。処理がどのように行われているかわかりやすい。また、オブジェクト指向には継承・多態性・カプセル化の３つの機能が含まれていた。
# 参考文献

https://type.jp/et/feature/25261/

https://robo-done.com/blog/2023/04/doneship_object_oriented/

https://www.sejuku.net/blog/9598

https://codezine.jp/article/detail/3709

https://jitera.com/ja/insights/44788#:~:text=%E6%8C%87%E5%90%91%E3%81%AE%E3%81%BE%E3%81%A8%E3%82%81-,%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96%E3%81%A8%E3%81%AF%EF%BC%9F,%E3%81%99%E3%82%8B%E3%81%93%E3%81%A8%E3%81%8C%E3%81%A7%E3%81%8D%E3%81%BE%E3%81%99%E3%80%82
Gitの基本的な操作の内部動作を理解しよう

# はじめに
gitのコマンドの動作について内部動作まで理解しよう！って記事です。

はじめに以下の記事を読んでいただくと理解が深まると思います。

https://qiita.com/zono0013/items/434fdeeba56c4e11bc29


# 今回のコマンド
- add
- commit
- push
- pull
- fetch
- branch

# git add


## 内部動作
### 1. ファイルの内容からハッシュ値を計算
- ファイルの内容やヘッダー情報に基づいて、SHA-1ハッシュ値を生成

### 2. `.git/objects/ディレクトリ`に`blobオブジェクト`を作成
- 計算されたハッシュ値を基にファイルを作成しオブジェクトを保存

### 3. インデックスファイル（.git/index）を更新
- ステージングエリアの状態を記録
- ファイルのパス、モード、blobオブジェクトへの参照を保存

:::note info
### 図解
```mermaid
sequenceDiagram
    participant WD as ワーキングディレクトリ
    participant SA as ステージングエリア
    participant Repo as Gitリポジトリ

    WD->>SA: ファイル追加
    SA->>Repo: Blobオブジェクト作成
    Repo-->>SA: インデックス更新
```
:::

# git commit
## 内部動作
### 1. ツリーオブジェクトの作成

- コミット時、Gitはステージングエリア（インデックス）の内容から、ディレクトリ構造を表現するtreeオブジェクトを作成

### 2. コミットオブジェクトの生成

- コミットメッセージ、作成者情報、タイムスタンプ、親コミットへの参照を含むcommitオブジェクトを作成
- 最新のコミットのハッシュ値を.git/HEADに保存


### 3. ブランチポインターの更新
- 現在のブランチ（例：main）のポインターを、新しいコミットオブジェクトに更新

:::note info
### 図解
```mermaid
sequenceDiagram
    participant SA as ステージングエリア
    participant Repo as Gitリポジトリ
    
    SA->>Repo: treeオブジェクト作成
    Repo->>Repo: commitオブジェクト生成
    Repo-->>Repo: ブランチポインター更新
```
:::

# git push
## 内部動作
### 1. ローカルブランチの変更を検出

- ローカルリポジトリの最新のコミットを特定
- リモートリポジトリとの差分を確認

### 2. オブジェクトの転送

- ローカルにある未送信のコミット、ツリー、blobオブジェクトをリモートリポジトリに転送
- パックファイル（圧縮されたオブジェクト群）を作成して効率的に転送

### 3. 参照の更新

- リモートブランチの参照（ref）を更新
- .git/refs/remotes/配下のファイルを更新

:::note info
### 図解
```mermaid
sequenceDiagram
    participant Local as ローカルリポジトリ
    participant Remote as リモートリポジトリ
    
    Local->>Remote: オブジェクト転送
    Local->>Remote: 参照更新
```
:::

# git pull
## 内部動作
### 1. リモートリポジトリの変更をフェッチ

- リモートリポジトリの最新の変更を取得
- git fetch相当の処理を実行

### 2. マージの実行

- ローカルブランチとリモートブランチの差分を自動的にマージ
- 競合がある場合は手動での解決が必要

### 3. ワーキングディレクトリの更新

- マージ結果をワーキングディレクトリに適用
- インデックスファイルを更新

:::note info
### 図解
```mermaid
sequenceDiagram
    participant Remote as リモートリポジトリ
    participant Local as ローカルリポジトリ
    participant WD as ワーキングディレクトリ
    
    Remote->>Local: 変更の取得
    Local->>Local: マージ処理
    Local->>WD: ディレクトリ更新
```
:::

# git fetch
## 内部動作
### 1. リモートリポジトリの変更をダウンロード

- リモートリポジトリの最新のオブジェクトとref情報を取得
- ローカルリポジトリのオブジェクトデータベースを更新

### 2. リモート追跡ブランチの更新

- origin/mainのような追跡ブランチを更新
- ローカルブランチは変更しない

### 3. パックファイルの処理

- 効率的なデータ転送のためパックファイルをダウンロード
- オブジェクトを展開し、ローカルリポジトリに保存

:::note info
### 図解
```mermaid
sequenceDiagram
    participant Remote as リモートリポジトリ
    participant Local as ローカルリポジトリ
    
    Remote->>Local: オブジェクト取得
    Remote->>Local: 参照情報更新
```
:::


# git branch
## 内部動作
### 1. ブランチ情報の管理

- .git/refs/heads/ディレクトリ配下にブランチ情報を保存
- 各ブランチファイルには、そのブランチの最新コミットのハッシュ値が記録される

### 2. ブランチ作成

- 現在のHEADが指すコミットを参照点としてブランチを作成
- 新しいブランチファイルを作成し、同じコミットハッシュ値を設定

### 3. ブランチリスト表示

- .git/refs/heads/配下のファイルを読み取り、ブランチ一覧を表示

:::note info
### 図解
```mermaid
sequenceDiagram
    participant Repo as Gitリポジトリ
    
    Repo->>Repo: ブランチファイル作成
    Repo->>Repo: コミットハッシュ参照
```
:::


# まとめ
今回はGitの基本的なコマンドがどのようになっているかをまとめてみました。今後も他のコマンドについてまとめる予定です。
Gitの理解に少しでも貢献できると幸いです。
車輪を付け替える

### 背景
カプセルがすでになかったので、ガチャのカプセルを何種類か試してみましたが、寸法が1mmくらい違っていたり、内側の形が球になっていなかったり、使うことができませんでした。
3Dプリンタで作ることも考えましたが、LEDマトリクスの様子が見えにくくなるので、それも断念しました。
結果的に大きめのタイヤをつなげることにしました。

### 無線給電のアンテナとおもりを外す
車輪を外すためにも、無線給電のアンテナとおもりをいったん外しました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/103446/3465ac6b-eda1-7de4-9278-e78b0f65d7a8.png)


### 元の車輪のゴムを外す
青色のゴムを外し、タイヤをつなげやすくしました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/103446/aa3c9f71-4dd6-7d5d-978a-07b8d654612d.png)

### タイヤをつける
たまたま見つけたタミヤのスリックタイヤを使いました。

https://www.yodobashi.com/product/100000001001258567/

内側の穴をドリルで大きくしてはめ込みました。
また、歯車が抜けないように、シャーシの内側にユニバーサル基板の端切れを接着しました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/103446/ddbc67a3-4c89-97de-6072-37c597a5f433.png)


### アンテナを取り付け
後ろ側面にアンテナを接着しました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/103446/cc1347cf-4ac1-c0fd-a3e9-0ec68d62a56c.png)

### まとめ
タイヤで移動できるようにするために車輪を付け替えました。
今回はできる限りできなりで工作しました。
これで本体を移動させて遊べるようになりました。
【基本情報】独学マラソン 正規化の段階 Day 30

:::note info
この記事は自分用の備忘録です。 
:::

昨日のつづき

### 正規化とは？  

https://qiita.com/weeding_test_5/items/49521fb78fbcc42bff41

---

正規化には3つの形があるそうな。

## 第1正規形（1NF）：データの「原子性」を保証する  
データを「最小単位」に分解し、繰り返しデータ（重複するカラム）を排除。

### 例：冗長なデータ  
#### ポケモン情報  
| ID  | 名前    | タイプ1 | タイプ2 | トレーナー名  |  
|-----|---------|---------|---------|--------------|  
| 1   | ピカチュウ | でんき   | NULL    | サトシ       |  
| 2   | フシギダネ | くさ     | どく     | サトシ       |  
| 3   | ニャース   | ノーマル | あく     | ロケット団   |  


### 正規化後（1NF）  
| ID  | 名前    | タイプ  | トレーナー名  |  
|-----|---------|--------|--------------|  
| 1   | ピカチュウ | でんき | サトシ       |  
| 2   | フシギダネ | くさ   | サトシ       |  
| 3   | フシギダネ | どく   | サトシ       |  
| 4   | ニャース   | ノーマル | ロケット団   |  
| 5   | ニャース   | あく   | ロケット団   |  

## 第2正規形（2NF）：部分従属の排除  
主キー（PK）に対して、すべての非キー属性を「完全従属」させる。

### 例：冗長なデータ  
#### ポケモン情報  
| ポケモンID | トレーナーID | 名前    | 重さ   | 高さ   | トレーナー名  |  
|------------|--------------|---------|--------|--------|--------------|  
| 1          | 1            | ピカチュウ | 6.0kg | 0.4m  | サトシ       |  
| 2          | 1            | フシギダネ | 6.9kg | 0.7m  | サトシ       |  
| 3          | 2            | ニャース   | 4.2kg | 0.5m  | ロケット団   |  

### 正規化後（2NF）  
#### トレーナーテーブル  
| トレーナーID | トレーナー名  |  
|--------------|--------------|  
| 1            | サトシ       |  
| 2            | ロケット団   |  

#### ポケモンテーブル  
| ポケモンID | トレーナーID | 名前    | 重さ   | 高さ   |  
|------------|--------------|---------|--------|--------|  
| 1          | 1            | ピカチュウ | 6.0kg | 0.4m  |  
| 2          | 1            | フシギダネ | 6.9kg | 0.7m  |  
| 3          | 2            | ニャース   | 4.2kg | 0.5m  |  

## 第3正規形（3NF）：推移従属の排除  
主キーに直接関係しない列（非キー属性）を別テーブルに分ける。

### 例：冗長なデータ  
#### ポケモン情報  
| ポケモンID | トレーナーID | 名前    | 重さ   | 高さ   | トレーナー町 |  
|------------|--------------|---------|--------|--------|-------------|  
| 1          | 1            | ピカチュウ | 6.0kg | 0.4m  | マサラタウン |  
| 2          | 1            | フシギダネ | 6.9kg | 0.7m  | マサラタウン |  
| 3          | 2            | ニャース   | 4.2kg | 0.5m  | ハナダタウン |  

### 正規化後（3NF）  
#### トレーナーテーブル  
| トレーナーID | トレーナー名  | トレーナー町 |  
|--------------|--------------|-------------|  
| 1            | サトシ       | マサラタウン |  
| 2            | ロケット団   | ハナダタウン |  

#### ポケモンテーブル  
| ポケモンID | トレーナーID | 名前    | 重さ   | 高さ   |  
|------------|--------------|---------|--------|--------|  
| 1          | 1            | ピカチュウ | 6.0kg | 0.4m  |  
| 2          | 1            | フシギダネ | 6.9kg | 0.7m  |  
| 3          | 2            | ニャース   | 4.2kg | 0.5m  |  

## 感想  
まだ理解が浅いので、もう少し後で深ぼって編集する。
数学嫌い向け？工場内AI勉強会の運営奮闘記

## 背景
昨年のアドベントカレンダーの記事で触れた「生成AI社内普及コミュニティ」の影響もあったのか、今年は工場内でのAI勉強会の運営を担当することになりました。
この勉強会では、普段数学に馴染みのない人でも興味を持てるように、極力専門的な話題を排除するよう求められました。その条件の中で、試行錯誤を繰り返しながら運営を進めました。（正直、私自身は話す内容の多くを実践したことがなく、不安も大きかったです。）

## 目的
- 工場内でAIに興味を持つ人を増やすこと
- 勉強会の参加者がAI活用方法について理解を深めること

## 行なったこと
1. 準備段階
    - セミナーやワークショップ運営のセミナーに参加してみた
    - 勉強会で話すコンテンツに関するセミナーに参加してみた
2. 生成AI（ChatGPT）に助けてもらった内容
    - カリキュラム案の作成（数学の要素を極力排除）
        - AIの歴史
        - AIに関する法律
        - 精度指標の見方
        - データの扱い方
        - 生成AI（ChatGPTとCopilot）に触れてみよう（ハンズオン形式）
        - 業務フロー図（ハンズオン形式）
        - ステークホルダー分析（ワークショップ形式）
        - 要求定義（ワークショップ形式）
        - デザイン思考（ハンズオン形式）
        - ADFI（無料ソフト）を用いた画像の異常検知体験（ハンズオン形式）
    - ハンズオン・ワークショップ用の演題・解答例を作成、ダミーデータなども全て
3. 実施内容
    - パワーポイントで発表資料を作成
    - 月2回、1時間ずつファシリテーションを担当
4. 成果測定（予定）
    - 勉強会の成果を測るための参加者満足度調査アンケートの実施
    - 理解度を把握するためのテストの実施

## 感想
業務でモデルを作成したり、AIを活用するプロジェクトに関与した経験が全くない「ど素人」の私ですが、様々な内容について話をしました。
不安も多かったですが、参加者からの満足度は高いようなので、一旦「良し」とします。

生成AIのありがたみを凄く実感しました！これ無くしては時間が圧倒的に足りなかったです。
また、要求定義やアンケートの取り方などは、データラーニングギルドの質疑応答の掲示板で
色々情報が交換及び紹介されている中で、参考になりそうな本があったのでひっそり購入して参考にさせていただきました。
わかりにくい人見知りがイベント参加するにあたって気を付けたこと

お疲れさまです、みやもとです。

アドベントカレンダーの最初３日間、今年１年の参加イベント振り返りを書きました。
その際にちらっとイベントの探し方・選び方について書いたのですが、選ぶ基準について個人的にかなり大事なことを書いてなかったので今回は改めて記事にしたいと思います。

それは「人見知りが楽しめるイベント」という点。

## 一見してわかりにくい人見知り
「そんなわけないでしょ」と言われることが増えましたが、私はちょっとした人見知りです。
初対面の人が相手だと何を話したらいいのかわからなくてあいまいな表情でただその場に佇むことしかできない程度には人見知りです。
「そんなわけない」と思われるのは
* 挨拶もできないほど極端ではない
* 話しかけられればそれなりに愛想よく返せる
* 一度話し始めるとそのままあれこれ話し続ける

というあたりが大きいかと思います。

要するに、自分から積極的にコミュニケーションを取りに行けない受け身の人見知りなわけです。

## コミュニティイベントもいろいろある
ひとまとめにコミュニティイベントと言っても、形態は結構いろいろあります。
形態を分類していくと結構切り分けがややこしいのでやりませんが、人見知り的に大きいのは<b>参加者同士の交流の有無</b>でしょう。
LTや講演、ハンズオン等とセットになっている場合が多いですが、ものによっては交流自体がメインなこともあります。
交流メインのイベントは顔見知りが少しでも居ればまだなんとかなりますが、誰も居ないとなんかいたたまれない気分になりますね。

せっかく参加してそんな気分を味わうのもつらいので、ある程度イベント慣れしてきた頃からは参加段階である程度対策を取るようになりました。

### 1:交流以外のコンテンツが大きいイベント
たいていのイベントには当日スケジュールが書かれています。
スケジュールで単に「交流」とか「ネットワーキング」だけ書かれている時間が大半を占めるイベントはよほど興味を惹かれない限りは諦めることにしました。
LTや講演、ハンズオン等ほかのコンテンツが占める時間が長ければ、仮に交流時間にぼっちになっても「この話を聞きたいから来た」という名目で自分を慰められます。
また、それらのコンテンツについてX等にタグをつけて投稿するだけでもイベントに参加した満足感が増します。

### 2:交流時間がグループトークかフリートークかを見極める
交流の時間が長めに取られている場合でも、グループに分かれてそれぞれのテーブルで話す場合と好きに動き回って話し相手を見つける場合とでは難易度がかなり違います。
前者なら席が決まっている分なんとなく話を聞いているだけでも多少気楽ですし、テーブルごとに進行役が居るようなプログラムなら話を振ってもらって会話に参加しやすくなります。

### 3:軽食等があるイベント
一歩間違うと食事目当てと見なされてペナルティになる可能性があるので、交流以外のコンテンツでまじめに話を聞いたり作業をしたりすることが大前提です。
ぼっちで突っ立っていても、飲み物があるだけでかなり手持無沙汰感がなくなります。
また、食べ物を取りに行くタイミングで行き会った人とちょっと挨拶をしてみたり、軽いコミュニケーションから会話につながる可能性はわずかながらあります。

## 交流メインのイベントに参加するなら
人見知りだけどどうしても交流メインのイベントに参加したい！というのであれば、それ以外のイベントに片っ端から参加した後が良いと思います。
イベントに参加する顔ぶれというのは結構かぶっていることが多いので、いろんなところに顔を出しているうちに「なんかいろんなところで見かけますね」と話しかけてくださる方が出てきたりします。

めちゃくちゃ他人任せの対策ではありますが、参加しまくっているうちに慣れて自分から話しかけることができる可能性もそれなりにあります。
データマネジメントGと業務を行うということ

## はじめに
私のチームでは社員が業務で利用する帳票・BIの作成を行っています。
その中では当然個人情報や給料に関わるような情報も含まれています。

そのため「データマネジメントG」というチームがあり、データの品質やルールが守られているか日々監視を行っています。
今回の記事では実際に運用していく中で自チームが「データマネジメントG」とどういった関わり方をしているのかを説明していきます。

## 業務フロー
社員はまずやりたいことに対して「データマネジメントG」へ相談します。
その後「データマネジメントG」は社員からもらった内容を元に業務的に問題ないか、他の帳票・BIとかぶっていないかなど様々な面から判断を下します。

ただし、「データマネジメントG」では把握しきれないデータの仕様も存在するため帳票・BIを作成してきた私たちの知見を利用し最終的な判断を行っています。

その後承認された帳票・BIを私たちのチームで作成して社員に提供するという流れとなります。

■以下作業フローの可視化
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3950392/808d1141-6ec3-8192-ca73-d5303d50068c.png)


## これから実施していくこと
今後はさらなる業務の改善をしていくために
「自分が望んだものを自由にデータを正しく利用できる状態」
といった未来を考えています。

そのため今までは「データマネジメントG」に依頼されたデータに対してだけ対応していく運用だったものを帳票・BI作成チームからもデータの管理・サポートを意識した運用を行っていく。といったものに変化させていくための動きを行っています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3950392/0c070ecd-de0b-5b6c-17c2-5ea43450446a.png)

## 運用を変えていくにあたり
データの管理・サポートを意識した運用(データガバナンス)を行っていくためには知識として身に着けていかなければならないため、データマネジメントについて毎週勉強会を開催しています。

今は以下資料を利用した勉強会を実施しています。

データマネジメント知識体系ガイド 第二版
https://www.amazon.co.jp/%E3%83%87%E3%83%BC%E3%82%BF%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88%E7%9F%A5%E8%AD%98%E4%BD%93%E7%B3%BB%E3%82%AC%E3%82%A4%E3%83%89-%E7%AC%AC%E4%BA%8C%E7%89%88-DAMA-International/dp/4296100491

## さいごに
まだ運用が開始されたばかりで一部の社員でのみ行っている状態となっています。
そのため今は既存の業務フローと平行稼働して運用されている状態ではありますが、最終的には会社全体で正しくデータが利用される未来を目指してこれからも頑張っていく所存です。
【Swift】世間のアプリから学ぼう

# エンジニアブログ (Swiftについて記載のあるもの)

随時追記！

[TECH PLAY 技術ブログまとめ#Swift](https://techplay.jp/blog/tag/swift)

各ブログサイトの`#Swift`のリンク

- [メルカリ](https://engineering.mercari.com/blog/tag/swift/)
- [ZoZo](https://techblog.zozo.com/archive/category/Swift)
- [タイミー](https://tech.timee.co.jp/archive/category/iOS)
- [ローソン](https://techblog.ldi.co.jp/archive/category/Swift)
- [LINEヤフー](https://techblog.lycorp.co.jp/ja)　※フィルタリングなし
名物社員みたいな存在って大事かも、と思った話

お疲れさまです、みやもとです。

アドベントカレンダー9日目になりました。
4日目あたりからコード書いたりツールの話したりしてたので、このへんでちょっと別の話題に入ろうかなと思います。

## 個性的な社員さん
現在所属している会社には個性的な社員さんがちょこちょこ見受けられます。
社長とか役職持ちの方、あとは営業や採用人事等の社外の方との交流が多いポジションで個性の強い方が居らっしゃるのはけっこうあるかと思うのですが、社内Slackとかでの発言を見ているとそういう方に限らずふと目に留まる方というのがいらっしゃいます。

そういう「この人おもしろいな」という方の存在から社内交流につながっているのでは、と思ったのです。

## 楽しそうなところには近づきたくなる
みやもとが現在使っているX（当時はTwitter）のアカウントは2023年3月に登録したものです。
きっかけは自社のみなさま、基本的には本社業務の方々なのですが、彼ら彼女らのTwitterでのやりとりがなんとなく楽しそうだったから。

わかりにくいコミュ障といいますか、「おしゃべりは嫌いじゃないし慣れればめちゃくちゃ絡みに行くけど付き合いの浅いうちに自分から話しかけるのは躊躇する」という感じのコミュニケーション能力なので、とりあえず私でも知っている人、目立つ人のフォローをしてそのやりとりを眺めるところからスタートしました。

そうしてひと様の投稿を眺めたりひとり言みたいな投稿をしているうちに「この人同じ会社だな」と気づいた方がフォローを返してくれたりリプライをくれたりして、少しずつやりとりにまざったりするようになりました。

そうしてつながった方の中にはコミュニティ活動に参加されている方や勉強会に参加されている方も居て、「そういうものがあるのか」と気づいたところから怒涛のイベント参加の日々が始まりました。
私が今さまざまなコミュニティイベントに参加してめちゃくちゃ楽しんでいるのはそういう社員さんの存在のおかげです。ありがとうございます。

そうしてつながった社員さんのひとりが[かっつさん](https://twitter.com/kattsu_sql_ag)です。
この人は個性的な社員さんたちの中でもかなり強いインパクトがあったので、ちょっとだけ思い出語りを入れます。

### めちゃくちゃ資格取ってる人
Xでつながる前からかっつさんの存在自体は知っていました。
というのも、この人<b>めちゃくちゃ資格取ってた</b>からです。
2024年12月現在、[会社ブログで「資格試験」のタグを引っ張ってくるとかっつさんが記事全部書いてます。](https://www.agent-grow.com/self20percent/tag/%e8%b3%87%e6%a0%bc%e8%a9%a6%e9%a8%93/)
1か月に1つ、下手したら2つぐらい資格試験を受験していると聞いた当時の印象は「なんかすげー人居る」でした。
過去の現場にもそういう資格ゲッターの方はちょこちょこいらっしゃいましたが、私が見かけた範囲だけで言えばそういう方は資格の取得自体が楽しくなっている受験ハイだったり、志高いつよつよエンジニアだったりしました。
業務時間外は基本的に楽しいことでしか動けない私にとって、前者はともかく後者はあまりにも高潔に見えてしまい、結果遠巻きにしてしまいました。
今にして思えばもったいないことです。面白い人だったかもしれないというに。

そんな感じでかっつさんに対しても「この人めちゃくちゃ意識高いタイプだったりしないか」と案じてしまい、Ｘでつながった時も私からのアクションは薄めだったと思います。

### なんか面白い人だった
見ようによっては失礼な印象をよそに、かっつさんは大変精力的に活動されていました。
いつのまにか[YouTuberになって](https://www.youtube.com/@kattsu_sql_ag)前職のご経験とか資格に関していっぱい動画を上げているかと思えば社内勉強会を開催されていたり、他社さんの交流会に参加されていたりとそりゃもういろんなことをされてました。

そういう「楽し気にいろんなことをしている人」を見ているとどうなるか。
私もなんかやりたくなるわけです。

### 私もなんかやりたい
とはいえ先述の通りコミュニケーションに若干の難あり、人見知りあがり症でしゃべるのも下手なのでYouTuberはもってのほかです。
じゃあなんか勉強するか、でも試験とかめちゃくちゃ勉強！って感じのは嫌だな…と考えた結果、私が始めたのはLINEBOTの作成でした。
ちょうどPython勉強したかったしちょうどいいや、ぐらいの感覚で簡単なBOTを作って動かして、ついでにコミュニティ活動の一環で作ったQiitaのアカウントで記事にしよう、と。
私が今アドベントカレンダーとかやってるのもある意味かっつさんがきっかけのひとつになってるわけですね。
今気が付きました。

## 存在が共通の話題になる
私のように触発されてなんかやりたい、とまではならなくても、目立つ社員さんというのは共通話題になります。
実際、採用面接で応募者がかっつさんの動画を話題に出したりすることもあるそうです。
かっつさん以外にも、社員総会やウェビナーで司会を担当する方、Xで自分の会社や業務に対する考えを広く発信されている方、社内勉強会でノウハウを教えてくれる方など、露出の多い方が居ると「ちょっと話しかけてみたいな」「あの話を詳しく聞いてみたいな」というところから社員、ひいては会社自体に対する興味が生まれます。
直接話しかけることはなくても、現場が違う等で普段接点が薄い社員同士でもその人を共通の話題にして社内交流が生まれます。
そう考えると名物社員というのは社外へのアピール以外にも結構いろんな役割を担っているのかもしれないな、と思ったのでした。
Office 365のリージョン確認方法

企業のコンプライアンスによってはクラウド上のデータ所在地について気を付けないといけない場合があります。
Office 365関連のリージョン確認方法は次の通りです。

# 確認方法

1. [Microsoft 365 管理センター](https://admin.microsoft.com)にログインします。
1. 設定 ＞ 組織設定 ＞ データの場所　をクリック
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2511911/934897fd-bbe2-311d-f1e3-874127b1528b.png)

データの保管場所に関する情報はこちらに公開されています。
[Microsoft 365 顧客データの保存場所](https://learn.microsoft.com/ja-jp/microsoft-365/enterprise/o365-data-locations?view=o365-worldwide&WT.mc_id=365AdminCSH_inproduct)