OmniAICreator/Qiita-1.07M huggingface dataset:
Power Automateを利用してoffice365グループメールで受信したメールをSlackに投稿する

本記事ではPower Automateを利用して、Office365グループメールに来たメールをSlackチャンネルに投稿する機能を作成してみます。

Power Automateを利用すると簡単に実装できます。

## 全体像

全体像としてはこんな感じ

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1670622/ec263ea1-9841-534b-c223-ed8fb5bfe0ff.png)

上から順に説明していきます。

## グループに新しいメールが届いたとき（When a new email arrives to a group）

[When a new email arrives to a group](https://learn.microsoft.com/en-us/connectors/office365groupsmail/#when-a-new-email-arrives-to-a-group)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1670622/eaf6990e-c43c-669a-d2d0-5348337679a9.png)

その名前の通り、グループに新しいメールが届いたときにトリガーされます。

こちらにグループIDを入力しておきます。

ドキュメントを見ると、戻り値がConversationTriggerResponseなArrayになっているようです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1670622/c3fdf25a-12a2-e5a5-21cb-5fedbcc7d9ae.png)

ConversationTriggerResponse

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1670622/6fc5e832-26bc-461c-0929-3640cf015cbe.png)

## スレッド投稿を取得する(Get a thread post)

[Get a thread post](https://learn.microsoft.com/en-us/connectors/office365groupsmail/#get-a-thread-post)

`グループに新しいメールが届いたとき（When a new email arrives to a group）`の戻り値がArrayとなっているため、`スレッド投稿を取得する`を追加すると勝手にそれぞれに適用する（Apply to each）が追加されていい感じに処理を追加してくれます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1670622/66323d89-63ae-0987-1d93-63dd259ff093.png)

上記の状態からスレッドIDと投稿IDを入力するとそれぞれに適用するがいい感じに設定されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1670622/9027c5e8-af66-c1a2-f53c-e10f2219e50b.png)

なおこの時、スレッドID、投稿IDの順番にパラメーターを入力すると3重ループ
投稿ID、スレッドIDの順番で入力すると2重ループ

となりました。

3重ループの場合はそのままでも動きますが、2番目のループが余計なので今回は手で削除しています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1670622/79956e57-ca05-97d6-7274-d01f44aca6e0.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1670622/f5d25dec-45aa-a181-7684-fc1f9bd809cc.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1670622/899715a4-2d39-5182-0e73-77e695ee2a2e.png)

## Html からテキスト

[Post](https://learn.microsoft.com/en-us/connectors/office365groupsmail/#post)

スレッド投稿を取得する(Get a thread post)の戻り値はPostとなっておりBodyの中にhtmlで格納されいます。

ここで`htmlからテキスト`でテキストに変換してあげます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1670622/d67eafb0-1a06-3e77-c722-eead3b58c143.png)

## メッセージの投稿

あとはメッセージの投稿からSlackに投稿してあげて完成。

プレーンテキストコンテンツを選択

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1670622/c7fd8cd1-5522-ebaa-6e94-9362c7a2a8bf.png)

画像のケースではhereで通知が欲しかったので`<!here>`としています。

## 総評

グループメールの場合は、自分のメールボックスとは異なるところから始まりますが。
今現在、トリガーが多すぎて一覧からそれっぽいトリガー（Office 365 Groups Mail）を探すのが一番大変でしたが、それを見つけた後はさっくりと実装できます。
Janssonコード例（メモリリークなし）

# 例
```json:config.json
{
  "name1":"tanaka",
  "name2":"suzuki",
  "param": {
    "name3":"sato"
  }
}
```
* 参照：参照カウントをインクリメントして参照すること
* 借用：参照カウントを変化させずに参照すること

```c:main.c
#include <jansson.h>

void deserialize(void)
{
    json_error_t err;
    
    // ★jsonオブジェクト作成。参照カウント:1
    json_t *pJson = json_load_file("config.json", 0, &err);
    
    // ★pJsonの一部を借用。json_decref(pObj)不要
    json_t *pObj = json_object_get(pJson, "name1");
    
    const char *name1 = json_string_value(pObj);
    
    // ★pJsonの一部を借用。json_decref(pObj)不要
    pObj = json_object_get(pJson, "name2");
    
    const char *name2 = json_string_value(pObj);
    
    // ★pJsonの一部を借用。json_decref(pObj)不要
    pObj = json_object_get(pJson, "param");
    
    // ★pObjの一部(pJsonの一部)を借用。json_decref(pObj)不要
    pObj = json_object_get(pObj, "name3");
    
    const char *name3 = json_string_value(pObj);

    // ★pJsonを借用。json_decref(*ppObj)不要
    json_t **ppObj = &pJson;

    // ★jsonオブジェクトの参照カウント:0。メモリ解放
    json_decref(pJson);

    // ★メモリ解放後に、取得したvalueを参照するのはNG
    // printf("%s\n", name1);
    // printf("%s\n", name2);
    // printf("%s\n", name3);
}

void serialize(void)
{
    // ★jsonオブジェクト作成。参照カウント:1
    json_t *pJson = json_object();

    // ★参照カウンタインクリメントせず、jsonオブジェクトにキー/バリューを追加
    json_object_set_new(pJson, "filename", json_string("abcdefg.txt"));

    // ★jsonオブジェクト作成。参照カウント:1
    json_t *pName = json_object();

    // ★参照カウンタインクリメントせず、jsonオブジェクトにキー/バリューを追加
    json_object_set_new(pName, "name", json_string("tanaka"));

    // ★参照カウンタインクリメントせず、pJsonにpNameを追加
    json_object_set_new(pJson, "object", pName);

    // ★文字列を作成。メモリ解放が必要
    char *output = json_dumps(pJson, json_object_size(pJson));
    printf("%s\n",output);
    free(output);

    // ★恐らく傘下のpNameの参照カウントもデクリメントされてる。pNameの参照カウント:0？
    json_decref(pJson);
}
void test(void)
{
    json_t *pJson = NULL;
    // ★NULLをjson_decrefに突っ込んでも問題なし
    json_decref(pJson);
}

int main(void)
{
    test();
    deserialize();
    serialize();
    return 0;
}
```

# 結果
```
root@5c10fbf8cac1:~# ls
config.json  main.c
root@5c10fbf8cac1:~# gcc -ljansson main.c 
root@5c10fbf8cac1:~# ls
a.out  config.json  main.c
root@5c10fbf8cac1:~# valgrind --leak-check=full ./a.out
==12387== Memcheck, a memory error detector
==12387== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==12387== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==12387== Command: ./a.out
==12387== 
{
  "filename": "abcdefg.txt",
  "object": {
    "name": "tanaka"
  }
}
==12387== 
==12387== HEAP SUMMARY:
==12387==     in use at exit: 0 bytes in 0 blocks
==12387==   total heap usage: 41 allocs, 41 frees, 7,653 bytes allocated
==12387== 
==12387== All heap blocks were freed -- no leaks are possible
==12387== 
==12387== For lists of detected and suppressed errors, rerun with: -s
==12387== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
root@5c10fbf8cac1:~# 
```
UbuntuとWindowsのデュアルブート環境でOSを入れ替え（SSD増設）

## 入れ替え内容
### 過去構成
SSD 1T(Ubuntu)
HDD 2T(Windows)

### 新構成
新SSD 2T(Ubuntu)
旧SSD 1T(Windows)

## やったこと

1. [ここ](https://jp.ubuntu.com/download)から最新のUbuntuイメージをダウンロード
    ※最新のものでないと、セキュアブートで引っかかる。
2. ISOイメージをUSBメモリ(８G以上)に書き込む
    ※Ubuntuのディスクアプリを使うと便利
3. USBを指して再起動し、USBドライブからUbuntuデスクトップ環境を起動
4. GPartedを起動し、新しい新SSDをパーティションタイプを「msdos」で「⁠Create Partition Table」する
5. 旧SSDのパーティションをすべて新SSDにコピー＆ペーストし、「Apply」する
6. データ移行作業が終わり次第、リブートし、UEFI(BIOS)を起動し、新SSDのブートの優先順位を上にする
7. Ubuntuが起動＆メインディスクの容量が2Tになっていることを確認
8. ディスクアプリから旧SSDをフォーマット
9. 新SSDにWindowsをクリーンインストール
　※大したデータを入れていなかった為。普通は移設ツールやバックアップイメージを作成して下さい
10. ブートの優先順位がWindows優先になっている為、UEFIからUbuntuの入ったディスクの優先順位を上げる
11. Ubuntuを起動し、ターミナルで`update-grub`を実行し、ブート先の情報を更新する
Docker Desktop for WindowsでGo(Air)のホットリロードできないからwatchexecにした


# はじめに
Docker Desktop for Windowsでホットリローディング用ライブラリ「Air」を使ってGo言語の開発を行っていたところ、コードの変更がコンテナ内で自動的に反映されない問題に遭遇しました。WebやXで検索をかけても同様の問題で躓いている方が多いようだったので解決策の一つを共有したいと思い執筆しました。
(Mac用DockerDesktopではAirによるホットリロード可能)

# 結論

Airの代わりに`watchexec`を使うことで解決できました。

↓↓↓こちらのツールです。
https://github.com/watchexec/watchexec

ざっくり説明すると、「ファイルが更新されたときに任意のコマンドを実行するRust製のファイル監視ツール」らしい。


# 既存のコードと問題点

従来のセットアップでは以下の構成でした。(多少省略しています)

フォルダ構成

```
current_directory
|
├── docker/ 
|   └── app/
|       └── Dockerfile
├── src/
|   └── main.go  
|
└── docker-compose.yml

```

Dockerfile

```Dockerfile
FROM golang:1.18.3-alpine

WORKDIR /app
COPY ./src .

RUN apk upgrade --update && \
    apk --no-cache add git && \
    apk upgrade git

RUN go install github.com/cosmtrek/air@latest

RUN go mod download

CMD ["air", "-c", ".air.toml"]
```
docker-compose.yml

```docker-compose.yml
version: '3.9'

services:
  app:
    container_name: go_app
    build:
      context: .
      dockerfile: ./docker/app/Dockerfile
    ports:
      - "8080:8080"
    volumes:
      - ./src/:/app
    tty: true
    environment:
      # 環境変数の設定
```
起動コマンドは以下の通りです。

```docker compose build```
```docker compose run --rm app go mod tidy```
```docker compose up -d```

しかし、このセットアップではDocker Desktop for Windows環境においてホットリローディングが機能しませんでした。

# 解決策: watchexec の使用
問題を解決するために、watchexec を用いた新しい Dockerfile に変更しました。

dockerfile

```Dockerfile
FROM golang:1.18.3-alpine

WORKDIR /app
COPY ./src .

RUN apk upgrade --update && \
    apk --no-cache add git && \
    apk upgrade git

RUN go mod download

# watchexec のインストール
RUN apk add --no-cache -X http://dl-cdn.alpinelinux.org/alpine/edge/community watchexec

# ホットリロード用のコマンドを設定
CMD ["watchexec", "-w", ".", "--force-poll", "100", "-r", "go", "run", "main.go"]
```

### 動作原理

watchexec はファイルシステムの変更を監視し、変更が検出されると指定されたコマンド（この場合は go run main.go）を実行します。
`--force-poll` オプションにより、定期的にファイルシステムをポーリングすることで、Docker Desktop for Windows上のファイルシステム通知の遅延や不具合を解決しています。

### ホットリローディングの確認
この変更を適用した後、以下コマンドを使用してコンテナをビルド、起動します。

`docker compose build`
`docker compose run --rm app go mod tidy`
`docker compose up -d --force-recreate`


これで、ローカルのソースコードに変更を加えるとwatchexec が検知し、Golangアプリケーションを自動的に再起動します。これにより、変更がすぐに反映され、DockerDesktop for Windowsでの開発プロセスがスムーズになります。

# まとめ

Docker Desktop for WindowsでGo言語の開発を行う際にホットリローディングを実現するためには、watchexec のようなツールの使用が効果的です。

watchexec により、Golangアプリケーションの開発効率が向上し、コードの変更が即座に反映されるため、より迅速な開発サイクルを実現できます。
同じような問題に直面している他の開発者にも、この方法を試してみることをお勧めします。ついでに❤くれると大変励みになります笑

また、当初DockerDesktop for Mac のみでGolangアプリの開発をしていたので気づかなかったのですが、DockerDesktop for Windowsだと、ファイルシステムの違いによりツールによってはうまく動作しないことがあると知ることができ、調べていて大変勉強になりました。
【プレゼン・発表】発表前緊張した時に意識すること

# 背景
報告会や成果発表会など会社で発表の場が意外と多いことを知り、あがり症と発表嫌いを克服するために「あがり症克服!ロジカルスピーチ術セミナー」という無料セミナーに参加をしてみた。

その中で、気持ちを落ち着かせるため発表前に意識したいと思ったことが幾つかあったので、自分用のメモとして残しておくことにした。




# 発表前に意識したいこと

### ① 95%が緊張する
あがり症克服協会（こんな協会があるらしい）のアンケートによると、約300人のうち95%が人前で話す時に緊張すると答えたらしい。

ほぼ全員緊張してる。自分だけじゃない。
しかも緊張って自分が思ってるほど見えない（らしい）。




### ②人間の本能的に緊張するのは当たり前
- 大勢に注目されていると思うと一気に緊張する


この緊張の正体は闘争or逃走反応（fight or flight effect)。

人間（動物）の本能的に、「沢山の目がこちらを見ている＝戦いの場」だと脳が勝手に判断するように作られている。
脳が戦いの場だと判断すると、生存のために戦うか逃げるかの準備を整えようとして鼓動や脈拍を速くしたり冷や汗をかいたりする。

これはもうそうやって判断するようにプラグラムされているから抵抗のしようがない。

緊張した時は「今闘争or逃走反応が働いてるな！ここは戦いの場じゃないよ〜」と自分に言い聞かせて教えてあげる。自分の話を聞きに来てくれた聞き手は寧ろ味方なはず。



### ③想定外が想定内！
- 言葉に詰まったらどうしよう
- 難しい質問が来たら答えられないかも

当たり前だけど全てにおいて準備することなんてまず不可能。
トラブルが当たり前。それが発表。想定外が想定内！

想定外が起きたら一休さんの名言「慌てない慌てない、ひと休みひと休み」を思い出す。
あとは考えながら話す。なかなかまとまらなくてもとりあえず

「ちょっと待ってくださいね」
「緊張でド忘れしちゃったので少し思い出す時間をください」

とか話しながら考える。

人間が1番考える時は話してる時らしい。
緊張で頭が真っ白になるとよく言うが、普段無意識的に考えながら話しているのと同じように話せばいいだけ（それが難しいんだけど）。




### ④自分をよく見せようとしない
- 上司や先輩が聞いているとより一層緊張する

こういう緊張の正体はこいつ。

「この発表が自分の評価に繋がるかもしれない」と無意識的に思ってしまい、自分を本来の姿よりも良く見せようとして緊張するらしい。

プレゼンは自分を良く見せるためにするのではなく相手にプレゼントしてあげるものだと考えるようにする🎁





# まとめ
人前で話す前に具合が悪くなるくらい緊張した時は、

- 95%が緊張する
- 人間は本能的に緊張するように作られている
- 想定外が想定内！
- 自分を良く見せようとしない

の4点を意識して心を落ち着かせる。

エンジニアという職種柄、人前で話す機会はほとんどないと勝手に思っていたので意外と発表の場が多くて驚いているが、あがり症を克服して自分の頑張りや成果を自信を持って人に伝えられるようになるために新人研修期間の発表の場を有効活用しようと思う。

<img width="300" alt="23585757.jpg" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3631741/7d92bcb9-9b1e-ee77-c64c-1097eefff125.jpeg">
【2日目】フロントエンジニアがRailsを習得するまで

# Railsチュートリアルを開始

# 1周目

1周目は読むだけで流れを掴んでいく。
また、Gitやデプロイ周りなどはスルーしていく。

---

# 1章 ゼロからデプロイまで

https://railstutorial.jp/chapters/beginning?version=7.0#cha-beginning

以下の流れで学習を進めるらしい。
1. 始めは最小限のhelloアプリで各種セットアップを整える
1. 少しだけ機能が増えたtoyアプリを体験
1. 最後に本格的なWebアプリケーション『Sample App』を作成

--- 

# 2章 Toyアプリケーション

## Model-View-Controller（MVC）

railsは大まかに以下のような構成で出来ている。
- app
    - model : データベースとの通信を担当
    - view: 見た目の部分を担当
    - controller: リクエストを処理する担当

> こんな感じ（railsチュートリアルより抜粋）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3629706/7f17e979-133b-564c-41c8-c1773a4cfece.png)

---

## validates

modelsのファイルにある`validates`はcolumnのバリデーションを書けるみたい。
以下の例だと`content`は140以下のtextみたいな感じ。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3629706/7464d5b1-01ba-eb4c-3bcf-5f3add18f274.png)

---

## Model同士の関連づけ

Userモデルは複数のMicropostsモデルと関連づけられる。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3629706/08089456-a348-1f97-185d-dce3b04a9995.png)

Micropostsモデルは単一のUserモデルに所有される。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3629706/bd699907-1d9b-e23e-676d-2fdb06b8f500.png)
OSSにコントリビューションする魅力と方法

# はじめに

この記事は OSSAdvent Calendar 2023　1 日目の投稿になります。

先日、GitHub が公開している [Open Source Guides](https://opensource.guide/)　にコントリビューション ( 貢献 ) してきました。

https://github.com/github/opensource.guide/pull/3150

そこで、Open Source Guides にコントリビューションしたので、OSS にコントリビューションしたことがない人向けに OSS へコントリビューションする魅力と方法を紹介していきます。

# OSS とは

OSS とは「Open Source Sftweare」の略です。
利用者の目的を問わず、誰でも自由にソースコードを入手でき、自由に改変でき、自由に再配布できるソフトウェアのことです。

有名な OSS としては、[Linux](https://github.com/torvalds/linux) やプログラミング言語の [Python](https://github.com/python) などがあります。

# なぜ OSS に参加するのか

OSS に参加するメリットは以下の 3 つが挙げられます。

- 持っているスキルを磨く
- 日頃使っているライブラリをより深く理解する
- さまざまな人とつながる

## 持っているスキルを磨く

日頃、会社や学校などの閉鎖的な空間でプログラミングをしていると、その中の固定観念に囚われてしまいます。
しかし、OSS では様々な人にコードを見てもらうことができます。
しかも、日本だけでなく世界中の人に見てもらえるので、様々な意見をもらうことができます。

## 日頃使っているライブラリをより深く理解する

OSS に参加することで、日頃使っているライブラリをより深く理解できます。
新しいバージョンのリリース情報や、バグの修正情報などを読むことで、ライブラリの仕組みや機能を追加した理由などを知ることができます。

## さまざまな人とつながる

チャットベースとはいえ、世界中の人と国境を超えて協力できます。
これはとても凄いことです。
実際に旅行をしなくても、多くの人と繋がることができるのですから。
また、英語に自信がなくても、Google 翻訳や DeepL、ChatGPT などを使うことで、コミュニケーションを取ることができます。良い時代になりました。

# いつコントリビューションするの？

これは主に 2 つのタイミングがあります。

- バグを見つけたとき
- 興味のある技術と出会った時

## バグを見つけたとき

バグや手順通りにやってもエラーが出る場合は、Issue を作成して報告・相談を試みてみましょう。
もし、修正が必要で自分で修正できそうな場合は、Pull Request を作成して修正してみましょう。

## 興味のある技術と出会った時

運命的な出会いですね！

実際にコードを読んだり、Issue から解決できそうな問題を探してみましょう。


# どのような OSS にコントリビューションするか

さて、OSS にコントリリューションするには、リポジトリを見つけないと始まりません。

リポジトリを探す方法としては以下の 3 つが挙げられます。

- いつも使っているツールのリポジトリ
- 好きな言語のリポジトリ
- 話題になっているリポジトリ

特にいつも使っているツールのリポジトリは、自分がいつも使っているツールのバグを見つけた場合に、そのバグを直したり、報告したりできます。

## どうやってコントリビューションするか

OSS にコントリビューションすると言っても、コードを書くことだけがコントリビューションではありません。
以下のようにさまざまな方法でコントリビューションできます。

### デザイン

デザインに精通しているのであれば、OSS のデザインにコントリビューションするのが良いでしょう。
プロジェクトの UI/UX を改善したり、新しいロゴを作成したりなどができます。

### ドキュメント

ドキュメントを書くこともコントリビューションの 1 つです。
コードは新しいのにドキュメントは古いままということもよくあります。
また、多くの人に使ってもらえるようにチュートリアルやプロジェクトのドキュメント翻訳を提案するもの良いでしょう。

プロジェクトによっては、英語以外の言語に翻訳してくれる人を探しているプロジェクトも存在します。

私がコントリビューションした [Open Source Guides](https://opensource.guide/) は、その 1 つです。

### 質問に答える

その OSS に精通しているのであれば、質問に答えることもコントリビューションの 1 つです。
この方法は GitHub の　Issues に答える以外にも、Stack Overflow や Qiita などの Q&A サイトに答えることも含まれます。

### コードを書く

勿論、コードを書くこともコントリビューションの 1 つです。
Issue から解決できそうな問題を探し、修正することや、出会ったバグを修正するなどが挙げられます。

初めて OSS にコントリビューションする場合や、初めてコントリビューションするリポジトリの場合は、Issue のラベルが `good first issue` となっているものを探すと良いでしょう。

## 結論：コードを書くだけがコントリビューションではない

以上のように、さまざまな形で OSS にコントリビューションできます。
自分にあった、自分の好きな方法でそのプロジェクトにコントリビューションしていきましょう。

# どうやってコントリビューションするか

有名どころだと、GitHub 上にある OSS へコントリビューションするのが良いでしょう。
理由は、GitHub は世界中の多くの人が使っており、ドキュメントも豊富だからです。

また、GitHub 以外にも OSS にコントリビューションする方法はあります。
例えば、デスクトップ版の Firefox は GitHub ではなく、[hg.mozilla.org](https://hg.mozilla.org/) で公開されています。
勿論、ここでもコントリビューションできます。

# コントリビューションするのに自信がない場合

ここまで、OSS にコントリビューションする魅力と方法を紹介してきましたが、自分には自信がないという人もいると思います。

そんな方は OSS Gate のワークショップに参加すると良いでしょう。

https://oss-gate.github.io/

「OSS Gate」は、OSS 開発に参加する「入り口」を提供する取り組みです。 OSS 開発の入り口を実際に体験するワークショップを開催しています。 

↓こちらも合わせて読むことをおすすめします。

https://github.com/oss-gate/first-feedback-guidebook



# まとめ

以上のように、OSS には国境を超えて様々な人が様々な方法で活動しています。
あなたも、自分の方法で良いので OSS に参加してみてはいかがでしょうか。
Unity チュートリアル「玉転がし」をやってみた

この記事は、[Qiita株式会社のカレンダー | Advent Calendar 2023 - Qiita](https://qiita.com/advent-calendar/2023/qiita-inc)の２日目の記事です。

https://qiita.com/advent-calendar/2023/qiita-inc

---

# これは何？

Unityを使ったアプリ開発をはじめたくて、まずは慣れるためにチュートリアルを取り組みました

Google検索で「Unity チュートリアル」と検索すると「Bolt版」が上位に表示されます

https://learn.unity.com/project/bolt-roll-a-ball-tutorial

Bolt版は、Unityのバージョンが結構古く、今ダウンロードできるUnityと勝手が違ったので
再度検索しなおして以下のチュートリアルを見つけました

https://learn.unity.com/project/roll-a-ball-visual-scripting-jp

入門チュートリアルの「玉転がし」を愚直にやってみました:runner:

■環境

- Windows11
- Unity 2022.3.12f1

# チュートリアルをやってみた:thumbsup:

自分がチュートリアルをやっていて、つまったところをまとめていきたいと思います

## ビジュアルスクリプティングを書く

https://learn.unity.com/tutorial/add-player-visual-scripting-jp?projectId=62c7ff31edbc2a0dd74d11ce#62de3bfaedbc2a15861a6054

- 検索窓で、検索しないと探せなかった **「Script machine」** に少し手間取りました
- インスペクタビューの **「Add Component」** ボタンで一覧表示される「Scripts」にありそうですがなくて「Visual Scripting」の中にありますが、最初は出てこなかったので、最初は検索窓で検索が一番です

https://learn.unity.com/tutorial/move-camera-visual-scripting-jp?uv=2021.2&projectId=62c7ff31edbc2a0dd74d11ce#62de4957edbc2a1a1c5a732c

- カメラを動かすのステップは初見では詰まるところが多かったです
- 文章量と専門用語が多いため、内容があまり入ってこない感じですが、何度か見返してなんとかなりました
- **Vector3** っていうのが肝なのですが、追加するノードの並び順が「～Vector2」「～Vector3」となっているのでクリックミスに気づかない事がありました

https://learn.unity.com/tutorial/show-item-count-visual-scripting-jp?uv=2021.2&projectId=62c7ff31edbc2a0dd74d11ce#62de5300edbc2a19a113bf43

- ここも情報量が多いです。これまでやってきたステップは覚えているでしょ？みたいな感じで説明してきます
- ビジュアルスクリプティングのノードの方も検索して探すのですが、ノード名が長いのと似たようなのがいっぱいあり間違えそうになりました

# 完成

https://github.com/acronhub/unity-roll-a-ball

# 公開

WebGLで公開しようと思い調べてたところ、Github Pagesで公開できそうだったので選択しましたが、結構道のりは長かったです

1. Github リポジトリを`Public`で作成(無料アカウントの場合は`Private`リポジトリでPagesが利用できないため)
1. Unityプロジェクトに`.gitignore`ファイルを追加
    - https://github.com/github/gitignore/blob/main/Unity.gitignore
1. WebGLの保存先フォルダ`docs`を作成
1. UnityからWebGLでビルドする際の設定を変更
    - Publishing Settingsの`Compression Format`を`Disabled`に変更
        - Github Pages では`gzip`圧縮だとエラーになるため
1. UnityからWebGLで`docs`フォルダにビルド  
1. Githubのリポジトリにプッシュ
1. Githubの設定からPagesの設定をする
    - 参考にさせていただいたページ

http://negi-lab.blog.jp/GameAtGitHubPages

GithubActionsが動作してPagesにデプロイされました:rocket:

https://acronhub.github.io/unity-roll-a-ball/

# 最後に

ビジュアルスクリプティング（昔でいうBolt）が、すごい敷居を下げてくれていると思います
コードらしいコードは書かずに、ノードとノードを線でつなぐ作業だけしていました:grin:

思っていたよりも作りたいものが作れるかもしれないと思えたので、チュートリアルをやってよかったです:relaxed:
IT企業の業態について

## 記事投稿の背景
- IT企業を業態で分類すると、自社開発、受託開発、SIer、SES、派遣などがある。
- 各業態の特徴の違いについて、なんとなく理解しているつもりではいたものの、言語化して備忘録として残すことにした。
- 役割・業務範囲・キャリア・売上に影響する要素の観点から簡潔に整理をしてみた。

## 自社開発

- 自社の製品やサービスを開発している企業。
- 従業員は自社の製品開発に携わり、製品の企画から開発、運用まで広い範囲の役割を担う。
- 正社員採用が基本で、長期的なキャリア形成がしやすい。裁量権が高く、製品に対する愛着も生まれやすい。（業務委託や派遣社員はスポット的に活用している）
- 自社製品の売れ行きが会社の業績や働きやすさに大きく関係する。

## 受託開発

- 他社から依頼を受けてシステム開発を行う企業。
- 従業員は受託先の要件に基づき開発を進めることが主な役割。
- 正社員、派遣社員など多様な雇用形態の人がいることが多い。受託契約はプロジェクトごとの契約が一般的で、スキルアップを目的に加入する人もいる。
- 幅広い案件を幅広い顧客から受注している一方で、業績や社内体制が受注プロジェクトの影響を受けやすい。

## SIer

- 複数のシステムを連携・構築することが主業務。
- 従業員はシステム基盤の構築から運用・保守まで幅広い開発を担当。
- 大手企業が中心で新卒入社の正社員が多く、大規模案件を経験できる点が魅力。社内の異動によって多様な経験を積めることも多い。
- 社内政治の影響を受けやすい。

## SES

- 要件定義や設計、コーディングなど、プロジェクトの一部に関与。
- 従業員は要件定義や設計など開発前段階の役割が中心で、高度な技術・知識を獲得できる。
- SIerから再委託を受けて開発を行うため、比較的大規模なシステム開発案件に関われることが多い。
- SIerから一部を委託されるため、プロジェクト全体を俯瞰できる機会は少なくなる一方、高度な領域を深掘りして開発することが多い。
- 業績はプロジェクト獲得状況に左右される。

## 派遣

- 客先に社員を派遣し、人件費とマージンを取るビジネスモデル。
- 従業員は客先での開発業務に従事する。雇用形態は契約社員がほとんどだが、自社で正社員として雇用してから派遣する会社もある。
- 案件切替を比較的柔軟に行うことができ、多様なプロジェクトで経験を積無ことができる一方、労働環境は客先に依存することになる。
リビルドしたのにブレークポイントで止まらないときのVisual Studioのデバッグ設定

# 背景
visual Studio上で、「The breakpoint will not currently be hit. No symbols have been loaded for this document.」というメッセージが出てブレークポイントで止まらなくなった。
以下のサイトの回答をもとにデバッグ設定を行ったところ解決できたのだが、実際にどういう設定をしたのか理解するために調べてみた。

[c# - How do I remedy "The breakpoint will not currently be hit. No symbols have been loaded for this document." warning? - Stack Overflow](https://stackoverflow.com/questions/2155930/how-do-i-remedy-the-breakpoint-will-not-currently-be-hit-no-symbols-have-been)

# 実施したデバッグ設定
- プロジェクトの Properties > Build から、「Define DEBUG constant」と「Define TRACE constant」にチェックが入れる
- 「Optimize Code」のチェックをはずす
- 「Advanced」をクリックし、「Debug Info」を「full」にする

# Define DEBUG constant と Define TRACE constant
「Define DEBUG constant」 をチェックすると、コード上に記載された Debugクラスのメソッドやプロパティが実行がされる。逆に、チェックを外すとDebugクラスの処理は無視される。「Define TRACE constant」も同様である。

参考サイト：
- [C#、VB で推奨されるデバッガー プロパティ設定 - Visual Studio (Windows) | Microsoft Learn](https://learn.microsoft.com/ja-jp/visualstudio/debugger/managed-debugging-recommended-property-settings?view=vs-2022)
- [MCP 70-483 Programming in C# のお勉強 「3-4 アプリケーションをデバッグする」 #C# - Qiita](https://qiita.com/takutoy/items/817a9f82a430c1096ff4)

# Optimize Code
[C#、VB で推奨されるデバッガー プロパティ設定 - Visual Studio (Windows) | Microsoft Learn](https://learn.microsoft.com/ja-jp/visualstudio/debugger/managed-debugging-recommended-property-settings?view=vs-2022) によると
>最適化されたコードは、生成された命令がソース コードと直接対応していないため、デバッグが困難です。 

とのこと。そのためチェックを外す必要があるらしい。

# Debug Info
「Debug Info」では、デバッグ情報の出力形式を指定するっぽい。
[C# コンパイラ オプション - コード生成オプション - C# | Microsoft Learn](https://learn.microsoft.com/ja-jp/dotnet/csharp/language-reference/compiler-options/code-generation) によると、それぞれ以下の通りらしい。

- full
  - 現在のプラットフォームの既定の形式を使用して、 .pdb ファイルにデバッグ情報を出力する
- pdb-only
  - full と同じ(C# 6.0 以降)
- portable
  - クロスプラットフォームの移植可能な PDB形式を使用して、デバッグ情報を .pdb ファイルに出力する
- embedded
  - 移植可能な PDB形式を使用して、 .dll/.exe 自体  にデバッグ情報を出力する( .pdb ファイルは生成されない )

# まとめ
振り返ってみると、3つのデバッグ設定の内、「Optimize Code」の設定だけが効果があったと思う。
元々、DebugクラスやTraceクラスは使ってなかったし、「Debug Info」のもともとの設定はpdb-onlyだったし...
【Systemwalker Operation Manager】で使いやすかった点と分かりずらかった点

# Systemwalker Operation Managerを使ってみた話

今の現場で使用している、「Systemwalker Operation Manager」（以降OMGR）を５か月間使ってみて、もともとジョブを触ってこなかった新入社員が、使いやすかった点と、分かりずらかった点を書いていきます。


## 使いやすかった点
### 1.カレンダ設定のしやすさ
CUIを使いholファイルを読み込むことでカレンダが設定できる。
余計な設定などはしなくていいためいっぺんに設定できるので簡単にできました。


### 2.無効化にするとき親ジョブネットをすべて無効化できること
ジョブネット無効化しといてねと言われ、一つずつ無効化しないといけないのかと思っていたのですが、GUIで押下することによって無効化でき、使いやすいなと思った点


### 3.ジョブネットインポート・エクスポートをすぐできること
最初ジョブネットをリリースするときは、いちいちGUIでポチポチしていかないといけないのかと思っていたのですが、シェルで一発でインポートできることを知りすごく簡単でした。



## 分かりずらかった点(使いずらかった点)
### 1.GUIの使いずらさ
最初GUIで作業行っていたのですが、csvをインポートする際、親ジョブネットからではなくてその下の階層のジョブネットから入れないといけないため、いちいち最初に分けないといけませんでした。分けるにしてもジョブネット設計書を見ながらcsvを仕分けしないといけないので時間がかかりすぎます。


### 2.プロジェクトの名前に半角括弧が使用できない
知ってたら普通に使わなければいいじゃんと考えますが、私が作業していた時はその情報がなかったためエラーが出て何のエラーかさっぱりわからず、結局２～３日かかった後に半角括弧が悪いことが判明しました。
なぜプロジェクトの名前に半角括弧がダメなのか...

<br>

## まとめ
以上、OMGRを５か月間使ってみて、もともとジョブを触ってこなかった新入社員が、使いやすかった点と、分かりずらかった点でした。

私が感じたことしか書いてないので当たり前なことばっかりだと思いますが、初めてジョブというものを触った人間の素直な感想なので許してほしいです...

ジョブは設定方法などがわかれば簡単に作成できるので、これからもOMGRとジョブの勉強を行い１人前のジョブ職人になろうと思います。
ローリングハッシュの加法性

道具として使っていると忘れがちですが、ローリングハッシュには線形性があります。

# ローリングハッシュ
$n$ 要素の配列 $\lbrace a_1, a_2, a_3, \cdots, a_{n}\rbrace$ のローリングハッシュ $f(\lbrace a_n\rbrace)$ を次のように定めます。

```math
f(\lbrace a_n\rbrace)=a_1b^{n-1}+a_2b^{n-2}+\cdots+a_n \mod{M}
```
ただし、$b$ はローリングハッシュの基数、$M$ は見ての通り割る数です。

# 配列の和
$n$ 要素の 2 つの配列の和を次のように定めます。
```math
\lbrace a_n\rbrace + \lbrace b_n\rbrace=\lbrace a_1+b_1, a_2+b_2, \cdots, a_n+b_n\rbrace
```

$n$ 次元ベクトルの和と同じです。

# ハッシュ値の和
```math
f(\lbrace a_n\rbrace)=a_1b^{n-1}+a_2b^{n-2}+\cdots+a_n \mod{M}
```
```math
f(\lbrace b_n\rbrace)=b_1b^{n-1}+b_2b^{n-2}+\cdots+b_n \mod{M}
```
ですので、辺々足し合わせると次のようになります。
```math
f(\lbrace a_n\rbrace)+f(\lbrace b_n\rbrace)=(a_1+b_1)b^{n-1}+(a_2+b_2)b^{n-2}+\cdots+a_n+b_n \mod{M}

```
したがって、
```math
f(\lbrace a_n\rbrace)+f(\lbrace b_n\rbrace)=f(\lbrace a_n\rbrace +\lbrace b_n\rbrace)

```
このように加法性があると言えます。

# 応用
ローリングハッシュを再計算することなく、配列の全要素に定数を加算したときのハッシュ値を得ることができます。

# おわり
斉次性はまたこんど。Mac の Safari で見ると数式がかなり歪んで見えて辛いです。
勉強時間6時間でAWS DVA-C02合格した話（ただの日記）

こんにちは

AWS　DVA-C02を受けてきました。
結果から言うと合格でした。
```
それではれっつごーの、時系列順にて
```
### 試験予約
確か9月末に予約したと思います。そして試験日は10月末（←予約ページ見直しなさい）
### 試験リスケ
ああ、忙しいと思い、１週間前に11月末にリスケしました。
### 試験までの気持ち
実は、試験予約していましたがこの冬の寒さでやる気がなくただだらだらすごしていました。
仕事終わっても疲れたなあと、勉強も身に入らず特にそのまま
### 試験日3日前
ちょうど木曜日が勤労感謝の日で休日をエンジョイ
### 試験日2日前
金曜日平日ですが、
有給取得奨励日ですが、
仕事続行、今日も疲れました。
### 試験日1日前
あぁ、今回もリスケかなと思い休みをエンジョイ。
夜中にリスケのためにサイトへ
> 予約時間の24時間以内は予定の変更ができません。

あ。勉強しよう。というか勉強しないといけないよ！できるよ！
重たいお尻を・・・
以前買ってあったUdemyのDVA対策コースを確認っと・・・ん？コースがない！
>返金の問い合わせはこちらへ

勉強教材がなくなりましたね。とりあえず再購入！ブラックフライデーの兼ね合いなのかサイバーセール中で1200円でした。
夜中の12時こえてから、もはや当日ですが、、、50問×2のコース2週して、AM3に就寝。
### 試験当日
AM10に起床し再復習。
試験時間はPM2、自分を信じるしかないのでいざテストセンターへ

（　＾ω＾）・・・もくもく

終わった！試験結果はすぐでないので街中ぶらぶら。
帰宅、メールチェック・・・合格:raised_hands_tone1:
意外でした。実際AWS開発やっているからかな。以上、勉強時間6時間でDVA受かった話でした。

うれしいのはうれしい:relaxed:

SAAはちゃんと計画的に勉強しようと思いました。（DVAだから受かったんだよ、、、トホホ:sweat:）
ログ調査等で便利なLinuxコマンド組合せ例(grep,less,wc)

# はじめに
メールサーバー等でログ調査をする際、
自身が頻繁に使用するコマンド概要の覚書を残します。
(正規表現等もっと細かい使用方法を知りたい方向けではありません)

コマンドに登場する以下の箇所は任意に置き換えてください。
・「search_word1」
　┗ 検索したい文字列1：例/warning xx 等 を指定してください。
 
・「search_word2」
　┗ 検索したい文字列2：例/Status = xx 等 を指定してください。

・「dir1/dir2」異なるディレクトリからパスでファイルを指定する場合に使用します。
　┗ ※cdで移動したカレントディレクトリにファイルが存在する場合は不要です。

・「test.log」ファイルを指定します。
　┗ 拡張子は ```.txt``` 等テキストで内容を確認できる拡張子であれば問題ありません。

## コマンド
```bash
# 複数条件(AND)で検索し、結果を画面表示する(.txtでも使用可能)
grep "search_word1" /dir1/dir2/test.log | grep "search_word2" | less

# 複数条件(AND)で検索し、該当行数を出力する(.txtでも使用可能)
grep "search_word1" /dir1/dir2/test.log | grep "search_word2" | wc -l

# 複数条件(OR)で検索し、結果を画面表示する(.txtでも使用可能)
grep -e "search_word1" -e "search_word2" /dir1/dir2/test.log | less

```
Jsでグラフの動的にX軸の変更

HighChartでZoomをした際に、y,x軸の範囲が動的にそれっぽい範囲をとるようにする
のがわからなかったので、

zoom後にデフォルトでResetボタンが出てくるが、それだけだとリセットした後の範囲が初期状態に戻らないので、別で関数が必要

```
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Highcharts Zoom Example</title>
    <!-- Highcharts CDN -->
    <script src="https://code.highcharts.com/highcharts.js"></script>
</head>
<body>

<div id="container" style="height: 400px;"></div>

<script>
document.addEventListener('DOMContentLoaded', function () {
    // サンプルデータ
    var data = [];
    for (var i = 0; i < 100; i++) {
        data.push(Math.sin(i * 0.1));
    }

    // 初期の横軸範囲
    var initialXAxisRange = {
        min: 0,
        max: 100
    };

    // Highcharts チャートの設定
    var chart = Highcharts.chart('container', {
        chart: {
            type: 'line',
            zoomType: 'x'
        },
        xAxis: {
            events: {
                afterSetExtremes: function (e) {
                    // ズーム後の最小と最大の横軸値
                    var min = e.min;
                    var max = e.max;

                    // ここに横軸範囲を動的に変更するための処理を追加します
                    // 例: 最小値と最大値の間を特定の範囲に制限する
                    if (max - min > 100) {
                        chart.xAxis[0].setExtremes(min, min + 100);
                    }
                }
            }
        },
        series: [{
            data: data
        }],
        // Reset Zoom ボタンの設定
        navigation: {
            buttonOptions: {
                theme: {
                    style: {
                        visibility: 'visible' // ボタンを最初は表示にする
                    }
                }
            }
        },
        // 初期の横軸範囲を設定
        xAxis: {
            min: initialXAxisRange.min,
            max: initialXAxisRange.max
        }
    });

    // リセットボタンが押されたときの処理
    document.getElementById('resetButton').addEventListener('click', function () {
        // 初期の横軸範囲に戻す
        chart.xAxis[0].setExtremes(initialXAxisRange.min, initialXAxisRange.max);
    });
});
</script>

<!-- リセットボタン -->
<button id="resetButton">Reset Zoom</button>

</body>
</html>
```

TickIntervalとかで一生懸命処理作ってしようとしたのに、minとmaxでなるんかーい
```
xAxis: {
            events: {
                afterSetExtremes: function (e) {
                    // ズーム後の最小と最大の横軸値
                    var min = e.min;
                    var max = e.max;

                    // ここに横軸範囲を動的に変更するための処理を追加します
                    // 例: 最小値と最大値の間を特定の範囲に制限する
                    if (max - min > 100) {
                        chart.xAxis[0].setExtremes(min, min + 100);
                    }
                }
            }
        },
```

https://api.highcharts.com/highcharts/xAxis.events.afterSetExtremes


リセットボタンの処理
デフォルトでzoomの後にリセットボタンが出てくるが、そのままだと、初期状態の範囲に変更できないのでminとmaxを設定しておく
```
// リセットボタンが押されたときの処理
    document.getElementById('resetButton').addEventListener('click', function () {
        // 初期の横軸範囲に戻す
        chart.xAxis[0].setExtremes(initialXAxisRange.min, initialXAxisRange.max);
    });
});

<!-- リセットボタン -->
<button id="resetButton">Reset Zoom</button>
```
転職して１年経ったので振り返りとこれから


:::note info
本記事は、2023 LTS グループアドベントカレンダー 1 日目の記事です。🎉
初日ということで、本カレンダー「LTSグループカレンダー」言い出しっぺである
私、オーガが担当させていただきます。
:::

~~埋まらんやろなとか考えていたのは内緒~~

# 🎄 はじめに

そういえば、転職しての振り返りとか書いてなかったなと思い、この機会に書こうと思います。

エンジニア４年目のソフトウェアエンジニアである私の転職して１年経った振り返りを書いていこうと思います。
参考になるわかりませんが、読んでいただけると幸いです。

# ❗️ 経歴

- コンピュータサイエンスの学部 20 卒
- プログラミングは大学から

# 🌈 転職理由

- 開発がしたい
- SES 以外もやりたい
- ゼロイチな部分も関わってみたい
- <font color="red">**ワクワク**</font>しながら働きたい

# ⛄️ 転職活動の軸

**外せない3つの軸**

- バックエンド開発ができること
- SES／受託であれば顧客の業界が広いこと
- 社内イベント／勉強会が盛んなこと

<br>

:::note warn
自社開発企業は、大小さまざまありますが、そこまで数は見ていないのでご了承ください。
:::

# 💯 転職活動の結果どうだったか？

**結果は、**<font color="green">**成功**</font>と言っていいと思っています。

<br>

なぜなら、

<br>

- 多様な業界の開発できる案件が豊富
- イベントは超豪華　(後述)
- 勉強会やUdemyビジネスなどキャッチアップできる環境がある

# 🤔 だけど、転職活動時に悩んだ点

<br>

- 受託オンリーで知名度もそこそこある会社の内定が出ていた点
- 転職後もまた、SESでいいのかという点

<br>


:::note info
悩んだ末、以下のような制度やイベントがあったので、ワクトを選んでよかったなと思います。
後ほど「ワクトに入社してみて」の項目にて良かった点を挙げていきます。
:::

# ✅ この１年を振り返って

- **業務的なこと**

  - 入社直後は、C、C++な組み込み系の案件に参画
  - 2023 年 10 月から AWS、Typescript なバックエンドの案件に参画

<br>

- **キャッチアップ的なこと**

  - 社内勉強会も開催されるたび大体参加
  - LTS 側の勉強会も機会があれば大体参加

# ⭐️ ワクトに入社してみて

- **社内イベント的なこと**

  - 月一帰社日で自社サービスの元になるビジネスモデルを作成するグループワーク
  - 忘年会のビンゴ大会の景品がすごい
  - 屋形船とか色々特別イベントもある

:::note message
特に、忘年会のビンゴは今までビンゴ当たったことない人でしたが、
初めての参加で<font color="red">当てる</font>ことができました。

<font color="red">**【賞品例】**</font>
**家電**、**自転車**、**Apple 製品**等
:::

<br>

- **制度的なところ**

  - 懇親会月 3 回、 3000円/1回の補助
  - Qiita 記事等の発信やリファラルで手当もらえるかも！？
  - 資格手当ももちろんある

:::note message
制度は、一通り揃っているかなとは思います。
少なくとも、前職よりはエンジニアにとって環境は<font color="red">良い</font>ので、転職してよかったなと思いました。
:::

<br>

:::note warn
もし、私からのアドバイスがあるとすれば、ここに記載した制度＋αがある会社というのは会社選びの必要条件になると考えています。（実際に入った今でも、よかったと思いますし、成長意欲の糧になっています）
:::



# 🎉 これからやりたいこと

- **サービスを作る**
  - SES でお客様のシステムを作るための技術の提供ではなく、システムやサービスで価値を届けたい
  - 個人開発ではいけないような社会にインパクトを与えるサービスを作りたい

<br>

- **勉強会の開催**
  - 今までが、受動的だったので、これからは能動的に発信もしていきたい
  - LTS グループ内でゆるく勉強会でつながれるようにしていきたい
  - 勉強会に対する敷居を下げたい

<br>

- **LT 会登壇**
  - LT 会は、今までなかったので、初開催を目指してやっていきたい
  - こちらも敷居を下げて、ゆるく集まれるようにしていきたい
  - 私自身の登壇力も向上していきたい

<br>

- **ワクト内、LTS グループ内、社外のいろんな人と関わる**
  - 今まではイベントも初めてで色々わからないことだらけで<font color="red">積極的でない</font>部分があった
  - せっかく、LTS グループには、コンサル、営業、エンジニアといろんな職種の人がいるからもっと関わって<font color="red">シナジー</font>を生み出していきたい
  - もっとゆるくいろんな人と交流したい

あとは、<font color="red">**技術力**</font> 欲しい

# 😃 まとめ

<br>

- 転職してよかったなと思います
- ここに書いたやりたいことは実現できるように頑張りたい
- エンジニアとしてもっと成長して貢献したい

<br>

**伝えたいこと**

:::note warn
- SESは悪じゃないし、あくまでビジネスの手段。自分の<font color="red">**やりたい**</font>ことや<font color="red">**キャリア**</font>を最優先に。
- <font color="red">**勉強会の頻度**</font>や<font color="red">**イベントの豪華さ**</font>は絶対聞いた方が良い。
- 会社のバリューやマインドに共感できるか。
- 資格手当などの制度はあるか。
:::

# ✏️ さいごに

弊社では、**エンジニア積極採用中です**！！！
SES、請負、受託、Saleforce やりたい方はご興味を持っていただけたら幸いです。

<br>

よろしければ、<font color="red">**いいね**</font>、<font color="red">**フォロー**</font>いただけるとうれしいです！

<br>

また、本記事の内容は個人の考えであり、会社を代表するものではございません。
積極的アウトプットのすすめ

## はじめに
皆様は積極的にアウトプットをできているでしょうか？
 私は、出来ているとは言えません！！
 ということで、いろいろな記事を書いていこうと考えました。
 
　まずは記事を書く意義について改めて理解を深めるために、アウトプット大切さについて深めていこうと思います。


**【  この記事の目的 】** 
- アウトプットの利点を考える
- アウトプットで思考を整理する
- アウトプットの効果を高める


## アウトプットの目的を挙げる
 まずは、アウトプットをする目的から考えてみましょう。

- 知識や思考を整理する
- 情報を共有する
- 知識を定着させる
- 自身を表現する


## アウトプットの効果を高めるために
　アウトプットにおいて何よりも重要なのは、まず行動に移すことです。最初は量を優先し、とりあえず試してみる姿勢が大切です。実際に、何事も繰り返し行うことで質が向上します。アウトプットを行う際には、より効果を高めることも重要です。次に、その方法をいくつか紹介します。
 
### アウトプットを意識してインプットする
　日頃の読書、勉強などのインプットの場面でも、アウトプットを意識するとより意義のある学びにつながります。たとえば、得た知識をどのように活用するか、どのように人に伝えるか、自分なりにまとめるかを考えることで興味と理解が深まり、インプットの姿勢を変えてより良い効果を生みましょう。
 
 
### 継続する
　何事も続けることは大事ですが、アウトプットも例外ではありません、自分なりのアウトプットを見つけることは、なかなかに苦痛と感じられるかもしれません。しかし、定期的に何度も繰り返すことにより、最初は苦痛に感じられたことも、やがては何でもないことと感じられるようになります。そうなれば、アウトプットが楽しくなり、習慣化することができます。

 
 ### フィードバックをもらう
　継続的なアウトプットは、自己成長のみならず、周囲を巻き込むことも重要です。他人からの意見や改善点、感想を得ることで、自分だけでは気づかなかった視点を知ることができます。ぜひ、私の今後の記事作成において、リアクションやコメントを頂けると幸いです。
　


 ## 参考
 人生が変わる! 最強のアウトプット術  　　　塚本 亮 (著)
アウトプットの精度を爆発的に高める「思考の整理」全技術　　　　生方 正也 (著)
遊び心✖️生成AI = ∞！コミュニケーションツールとしての生成AIについて(Generative AI on cluster)

![スクリーンショット 2023-11-30 23.57.01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2241831/01ff8560-e7f4-6c7a-f24b-c37313e99602.png)
## ※イベント準備を優先で記事は途中までにさせていただきます…！気軽にイベント来てください〜
https://cluster.mu/e/c06680ba-b94b-47d7-b9d8-83cbbec11e3e
![スクリーンショット 2023-11-28 21.35.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2241831/2cf730a4-07d9-8b10-9152-2d757128a5da.png)
時間は長めにとっているので出たり入ったり自由にお越しください〜



## はじめに
こんにちは。はじめまして。hattoriです。現在ゲーム会社の新卒2年目エンジニアをしています。
AI技術中心に学んでいて、「本当にそこはAIが良いのか」「AIだからこその新しい体験」を日々考えています。
中でも「生きているキャラクター」に一番関心があります。

今回の記事は、「遊び心✖️生成AI = ∞！コミュニケーションツールとしての生成AIについて」がテーマです。
このテーマのきっかけが、今年のSIGGRAPH2023のReal-Time Live！
(日本語の記事)
https://morikatron.ai/2023/08/door_to_cg53/

でNVIDIAとRobloxが同じマテリアル生成のライブデモをやられていました。
NVIDIAの方は画質が高画質で審査員特別賞もいただいていましたが、個人的にはRobloxの若い年代も多い「子供の想像力✖️生成AI」や「人と人とのコミュニケーションの間に生成AI介入すること」の可能性を感じました。
そのが印象が残り続けており、その可能性をcluster上でより感じています。

今後cluster生成AIが試せるようになるとは思うのですが、最新のAIツールをPC、Unityで利用することで今も試すことができます。
なので今回は生成AIを手軽に生成AI試せる記事をと思ったんですが、イベントでコメントにプロンプトを投げると生成されるのをやろうと思いイベントを開催します！
https://cluster.mu/e/c06680ba-b94b-47d7-b9d8-83cbbec11e3e
![スクリーンショット 2023-11-28 21.35.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2241831/2cf730a4-07d9-8b10-9152-2d757128a5da.png)
時間は長めにとっているので出たり入ったり自由にお越しください〜

また、今回の記事は私個人による見解だけではなく、ネットで調べて得た情報や勉強会・イベントで教えて頂いた情報も含んでいます。ご了承ください。

### 目次
- 生成AIの気づき
    - コミュニケーションツールとしての生成AI
    - 正確ではなく間違った出力が場を盛り上げる
    - となりの芝生は青い。は生成AIにもあてはまる
    - 出力の凄さではなく、出力の速さで生まれる新しい体験

- cluster上で活用できそうな生成AIツール一覧ジャンル別
    - 画像
    - 3D
    - 音楽
    - モーション


## （↓は今の妄想を大項目で羅列しました。）
## コミュニケーションツールとしての生成AI
## 正確ではなく間違った出力が場を盛り上げる
## となりの芝生は青い。は生成AIにもあてはまる
## 出力の凄さではなく、出力の速さで生まれる新しい体験



## おわりに

ここまで記事を読んでくださりありがとうございます。
是非イベントにお越しください！
【②技術選定】Vite+React+TypeScript+GitHubPagesで爆速サイト公開

## はじめに
業務ではVue.js+JavaScriptを使用しています。
が、もう少しモダンなフレームワークと言語に挑戦したい...ということでReactとTypeScriptをチョイスし、簡単なWEBアプリをつくることに:v:

...と思い立ったのが10月末。
「そういえば12月はQiitaアドベントカレンダーがあるな...そこまでに公開できたらいいな:sunglasses:」と思い、1ヶ月半程度で設計~公開まで行けると踏んで開発開始。

折角なので、制作の過程も含めて記事化してみました。

ということで、本記事は下記連載の第2弾となります。
他記事も併せてご覧ください。
[【①アイデア選定】](https://qiita.com/YutaManaka/items/f5db1d86239203db8ade)
[【②技術選定】](https://qiita.com/YutaManaka/items/b1397c0624010b693a12)←イマココ
[【③設計(ロジック)】](https://qiita.com/YutaManaka/items/6d412971574c4ca9fb1b)
[【④設計(デザイン)】](https://qiita.com/YutaManaka/items/5bb6b193149e68c9b742)
[【⑤環境構築】](https://qiita.com/YutaManaka/items/60bed57196386ccce931)
[【⑥進捗管理】](https://qiita.com/YutaManaka/items/beeba2bcba64d1d1c6bd)

ちなみに、公開サイトはこちら↓
https://yutamanaka.github.io/FragranceFinder/

リポジトリはこちら↓
https://github.com/YutaManaka/FragranceFinder

本記事では、技術選定の経緯についてまとめました:writing_hand:

## 対象者
この記事は下記のような人を対象にしています。

- 駆け出しエンジニア
- プログラミング初学者
- 技術選定のやり方がわからない人

## 結論
技術選定においても「目的と優先順位」を最初に決めましょう。

## 目的と優先順位
アイデア選定同様、技術選定の際にも目的と優先順位付けは大事なので先にやりましょう。

:::note info
1. ReactとTypeScriptの技術力UP
1. 無料でサービス公開
1. CSSの修行もちょっとしたい(レスポンシブとか)
1. あとは適当
:::

とかく、今回はReactとTypeScriptの勉強をしたいので、そこはMUST。
他は特に目新しいものを求めず、慣れ親しんだもので良い、と判断しました。

## なぜフロントエンド？
現在私は業務では「フロント：JavaScript+Vue.js / バックエンド：PHP+Laravel」を使用しています。
上記スキルセットで2年半経ち、人に教えられるレベルになってきました。
技術者としてスキルアップするにあたり、フロントorバックエンド領域で未経験の言語orフレームワークに挑戦しようと決意。

元々、論理的思考が得意・好きということもあり、バックエンド領域には自信があります。
しかし、フロント領域に対しては苦手意識があり、克服するためにも今回はフロント領域にチャレンジすることにしました。

## なぜReactとTypeScript？
普段からIT系企業の求人を見たり、どのサービスがどんな技術を使用しているのか調べるのが趣味です。
そこで色々リサーチしてみると、興味のある企業・サービスでは下記のスキルセットが多かったです。

:::note
バックエンド領域：Java, Python, Go
フロント領域：TypeScript, React
:::

バックエンド領域は候補が多く、絞り込みが困難。
また、現状のPHP+Laravelでもう少しスキルアップしたい気持ちもありました。

それに対してフロントエンドは候補が1本に絞れました。
特にTypeScriptはJavaScriptと共存/漸進的導入が可能らしいので、現在のプロジェクトにも活用できそうな気がする...。
ということで今回はTypeScriptとReactに絞ってWEBアプリ作成することにしました。

## 言語・フレームワーク
ここは必須なので、下記をチョイス。
- JavaScript
- typescript@5.2.2
- react@18.2.0

## ライブラリ
基本的には、業務で使用経験があるものをそのまま使っています。
開発効率を上げるためにほぼ必須、と考えています。
- gh-pages@6.0.0 (後述のGitHub Pagesの公開のため導入)
- husky@8.0.3
- lint-staged@15.0.2
- eslint@8.53.0
- prettier@3.0.3

## 開発ツール
- vite@4.5.0(環境構築がめちゃ楽と聞いて。)
- GitHub Pages(無料のホスティングサービスとして)
- GitHub

## その他ツール
- ClickUp(進捗管理やアイデア出しに活用)
- Notion(ロジック設計やその他ドキュメント管理に活用)
- diagrams.net(旧draw.io。デザイン設計に活用)

## おわりに
個人開発の技術選定についてまとめました。
MDN Web Doc 翻訳のご紹介

# はじめに
この記事は 2023 年の [MDN 翻訳 Advent Calendar](https://qiita.com/advent-calendar/2023/mdn-translation-community-japan) 向けに作成したものです。

## MDN Web Docs とは？
- MDN Web Docsは、ウェブ標準 及び Mozilla プロジェクトの開発文書のための Mozilla の公式ウェブサイトです。
- 2017年 に MDN Web DocsはGoogle、サムスン電子、 Microsoft 及び Mozilla のウェブ技術の統一文書となった Microsoft は MSDN から MDN へのページのリダイレクトを開始しました。
- [MDN Web Docs](https://ja.wikipedia.org/wiki/MDN_Web_Docs) from wiki

## MDN Web Doc のあゆみ
以下翻訳エンジンのコードネームでの変遷になります。

- Netscape DevEdge
    - MediaWiki 最初の Wiki エンジン
- DekiWiki
    - 2 つ目の Wiki エンジン
- Kuma
    - 3 つ目の Wiki エンジン
- Yari
    - 現在のMDN Webドキュメントプラットフォーム
    - **Wiki ベース**の編集から **Github, MarkDown 形式** 編集へ変更

#### 現在の Yari になり、格段に作業効率が向上しました。

## MDN Web Doc 翻訳を始めるには？
- 2023.04.09 に「[MDN 月例ミートアップ - 翻訳ガイド](https://mozilla-japan.github.io/mdn-translation-guide/)」が公開されました。
- 基本的には上記翻訳ガイドの沿って、翻訳を行います。

## MDN Web Doc 翻訳の流れ
1. [準備するもの](https://mozilla-japan.github.io/mdn-translation-guide/translation/0_preparation.html)
    - GitHub アカウントの用意
    - Node.js / Yarn のインストール
1. [記事を選定する](https://mozilla-japan.github.io/mdn-translation-guide/translation/1_choose-article.html)
1. [作業を宣言する](https://mozilla-japan.github.io/mdn-translation-guide/translation/2_declare-task.html)
1. [fork リポジトリを用意する](https://mozilla-japan.github.io/mdn-translation-guide/translation/3_fork-repository.html)
1. [fork リポジトリを clone する](https://mozilla-japan.github.io/mdn-translation-guide/translation/4_clone-repository.html)
1. [日本語記事ページを新規作成する](https://mozilla-japan.github.io/mdn-translation-guide/translation/5_new-ja-file.html)
1. [日本語記事ページを編集する](https://mozilla-japan.github.io/mdn-translation-guide/translation/6_edit-ja-file.html)
1. [Pull Request を作成する](https://mozilla-japan.github.io/mdn-translation-guide/translation/7_create-pull-request.html)
1. レビューで、修正事項があったら対応
1. レビューが approve(承認) されたら、翻訳記事がマージされます。
1. `全世界に翻訳記事が公開されます。`

箇条書きで、翻訳するプロセスを紹介しました。
上記に記載されているリポジトリについては、以下をご覧下さい。

## リポジトリ

上記 MDN Web Doc 翻訳の流れで、見る・使うリポジトリは下記の通りです。
1. 日本語の翻訳状況を管理・把握するリポジトリ 
    - https://github.com/mozilla-japan/translation
1. 原文（英語）リポジトリ
    - https://github.com/mdn/content 
1. 各言語翻訳リポジトリ
    - https://github.com/mdn/translated-content 

### L10N ガイドライン
翻訳するにあたり、様々なルールがあります。

- [表記ガイドライン](https://github.com/mozilla-japan/translation/wiki/Editorial-Guideline)
- [L10N ガイドライン](https://github.com/mozilla-japan/translation/wiki/L10N-Guideline)
- [Mozilla 用語集](https://github.com/mozilla-japan/translation/wiki/Mozilla-L10N-Glossary)
- [日本語の文体](https://docs.google.com/spreadsheets/d/1y-hC-xMXawCgcYZwJDnvuSlAOTgMRLLyqXurpYkJbYE/edit#gid=0)

最初から上記`ガイドラインを網羅して、完璧にこなせる方はいません`
まずは気軽に参加してみて、翻訳の流れを一緒にやってみませんか？

### Mozilla Japan コミュニティ 参加希望の方は、下記のいずれからご参加下さい
※MDN Web Docs 翻訳コミュニティは、`Mozilla Japan コミュニティのグループ`です。

- slack: https://mozillajp.slack.com
    - slack 参加後に #translation チャンネルにご参加下さい
- Door Keeper: https://mozilla.doorkeeper.jp/
    - 直近ミートアップイベント
        - https://mozilla.doorkeeper.jp/events/166059



MDN Web Doc 翻訳コミュニティは、英語に興味のある方、翻訳に興味のある方大歓迎です。
よろしくお願い申し上げます。
人生初のOSSコントリビュートでポケモン界隈にちょっと貢献してきた

# はじめに
どうも、ポケモン廃人です:zap::mouse:

最近 `PokeAPI`という、ポケモンに関するデータを様々取得できるAPIで遊んでいたのですが、APIの返却データに不備がある事に気がつきました。

`PokeAPI`はOSSとして公開されているので、自分で直してしまおうということで、**人生初のOSSコントリビュート**をしてきました。

今回はその体験談を記します。「OSSにコントリビュートするのってこんな流れなんだ〜」くらいを感じていただければと思います。

技術的に踏み込んだ内容はありませんので、どうぞ気軽に読んでくださいませ。

# PokeAPIとは
ポケモンのゲームに関するありとあらゆるデータを取得できる**神API**です。
マニアックな話は避けますが、ポケモンの身長や体重、技、アイテムなど、基本的に何でも取ってこれます。
OSSとしてリポジトリ公開されており、star数は 3800超（2023/12現在）というAPIになっております。

・PokeAPI - Github

https://github.com/PokeAPI/pokeapi

・公式ドキュメント

https://pokeapi.co/docs/v2

# コントリビュート達成まで
では、自分のプルリクエストがAPI開発者にマージされるまでに体験した、一連の流れを書いていきます。

## 0. 不具合発見
技データのAPIを叩いていたところ、技「からをやぶる」の返却データにミスがある事に気がつきました。
調べたところ、リポジトリが公開されていることを知り、プルリクエストを出そうと考えます。


## 1. READMEを読む
まずはREADMEを読み、本APIの開発環境の構築方法や、プルリクエストの作成ルール等を把握しました。

## 2. 既存のissueを確認
プルリク送信やissueの新規作成前に、既存のissueを確認するよう、READMEに記載がありました。
> Please see the issues on GitHub before you submit a pull request or raise an issue, someone else might have beat you to it.

自分が気づいた問題がすでにissueに上がっていないか確認してみたところ、少し前に同様の問題を指摘している方がおりました。
どうやら、私が見つけた技データの他にも、同じように返却ミスのある技がいくつか存在するとのこと。

issueが上がってから日が空いていたので、issueの作成者とAPIの開発者に、私の方でまとめて修正してしまって良いか尋ねました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/267522/aa27a8aa-7440-5054-c0ac-66bbc1165435.png)

次の日、返信がありました。

API開発者：「頑張れ」
issue作成者：「少なくとも数日以内には直せないので、お願い」
自分（心の声）：（頑張ります。）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/267522/eb7332d5-43de-beba-3ab5-e7b442c02e87.png)

## 3. リポジトリをfork
ここから開発の準備です。`PokeAPI`のリポジトリをforkします。

![FireShot Capture 008 - PokeAPI_pokeapi_ The Pokémon API - github.com.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/267522/ea64632b-f369-2e8d-7192-d70e1932b87b.png)

GUI上でforkボタンを押し、完了。

![スクリーンショット 2023-11-09 1.01.31.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/267522/b220c3e4-e612-7c8e-717f-ec616f243f5b.png)

## 4. clone→ブランチ作成→ローカル開発
forkしたリポジトリを`git clone`し、ブランチを切って開発していきます。

まずはREADMEの説明を参考に、ローカル環境でAPIの動作検証をするための環境構築を行いました。

あとはコードを読んで修正箇所を特定し、実際に直します。
自分のプロダクトではないので、リポジトリの構造を理解するのは少し大変。

修正自体は、結局小さな変更で済みました。


## 5. プルリクエスト作成
ローカル環境で動作検証も終わったので、変更をpushし、プルリクエストを出します。
コミットメッセージやプルリクの文章はなるべく丁寧に書きました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/267522/1da8bd6b-3494-e0a3-3a6b-0dbbee005dea.png)


## 6. マージ完了
数時間後、無事マージされました。
OSSコントリビュート達成です:clap:
その後、本番環境のAPIでも正しくデータが返ってくることを確認できました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/267522/d262120e-1ea2-b096-abe0-5018d88e85e3.png)

# 感想
第一に、大勢の人が利用しているOSSに貢献できて嬉しい気持ちがあります。`PokeAPI`に少し愛着も湧きました。

一方で、修正前にリポジトリの環境構築を行ったり、リポジトリの中身（構造、ソースコード）を理解する必要があったりと、難しさも感じました。
OSS活動に慣れるとこの辺の感覚は変わってくるのかもしれませんね。

今後も機会があればOSSコントリビュートに取り組んでみようと思います。

# 最後に
最後まで読んでいただきありがとうございました。

ポケモンSVの追加コンテンツ配信まであと2週間。界隈も盛り上がってきましたね。
**配信当日は、私もしれっと有休とって遊びます。**

それではまた！
【ReactHookForm】CSSの:valid, :invalidを使用する方法 

以下のように`shouldUseNativeValidation`を`true`にすることでブラウザのバリデーションが有効になり、`:valid`, `:invalid`が使用可能になります。

```jsx
import { useForm } from "react-hook-form"


export default function App() {
  const { register, handleSubmit } = useForm({
    shouldUseNativeValidation: true,
  })
  const onSubmit = async (data) => {
    console.log(data)
  }


  return (
    <form onSubmit={handleSubmit(onSubmit)}>
      
    </form>
  )
}
```
[Java]staticとは何なのか

初投稿です。

牛尾剛氏著の『世界一流エンジニアの思考法』を読んで光の速さで感化され、とりあえず今のプロジェクトで使っているJavaとSpring bootを徹底的に基礎から勉強しなおそうと思い立ちました。
※エンジニアとしては6年目とかですが、これまでJavaは表層をさらっと理解した程度でググりながらor他のプログラマの見よう見まねで現場を乗り越えてきたド三流エンジニアです。

まずはJava、ということで定番書でもあるEffective Java 第3版を読み始める。
読み始めてすぐ、
staticファクトリメソッドとは？という疑問にぶちあたりました。
というか、そもそもstaticって何？ちゃんと理解しているか？していない。

じゃあまずはstaticについてちゃんと理解しよう。

### staticなメンバとは
結論から言うと、「インスタンスではなくクラスに紐づくメンバ」である。

ちょうど業務でいい例があったのでそれを使って整理してみます。

この日のタスクで解消したい課題は以下の通り。
「CSVから取り込んだ値に対して、数値項目を最終的なデータ連携先のDBの桁数に合わせてバリデーションかけたい」
（むしろ、やってなかったんかーい、とも思ったが）

まずはダダダっとこんな感じの処理を作ってみました。
```java
String strNum = "1234.5678" // ほんとはcsvから読み取った値

try {
	BigDecimal bigDecimalNum = new BigDecimal(strNum);
	if (bigDecimalNum.precision() - bigDecimalNum.scale() > 30 || bigDecimalNum.scale() > 5) {
		// 桁数チェックエラーの処理
	}
} catch e {
	// 数値以外が入ってきた場合の例外処理
}
```

が、桁数のべた書き気になるー
ってことでアーキテクトに相談。
（余談だが、このアーキテクト、かなり優秀なエンジニアである。エディタは秀丸を使用ｗ）

そして以下のように改善してみました。

元々データ連携するための数値項目クラスが以下のような感じで実装されていた。
```java
public class numValue {
	private BigDecimal value;

	// コンストラクタ
	public numValue(BigDecimal value) {
		this.value = value;
	}

	public BigDecimal getValue() {
		return value;
	}

}
```

そこに、こんな感じで追加。
```java
public class numValue {
	private BigDecimal value;

	static final int INTEGER_LENGTH_LIMIT = 30;  // staticなメンバ
	static final int DECIMAL_LENGTH_LIMIT = 5;  // staticなメンバ

	// コンストラクタ
	public numValue(BigDecimal value) {
		this.value = value;
	}

	public BigDecimal getValue() {
		return value;
	}

	public static boolean isValidLength(BigDecimal value) {
		if (value.precision() - value.scale() > INTEGER_LENGTH_LIMIT
			|| value.scale() > DECIMAL_LENGTH_LIMIT
		) {
			return false;
		}
		return true;
	}
}
```

はい、出てきましたstaticなメンバ。

まずはstaticでないメンバ `value` 。
これは `new numValue(value)` で生成されたインスタンスに紐づくメンバです。

```java
numValue num1 = new numValue(new BigDecimal(123.45));
numValue num2 = new numValue(new BigDecimal(67.89));
```
それぞれのインスタンスで異なる値を持ちますね。

一方でstaticなメンバはというと、num1 でも num2でも同じ値を持ちます。
何ならインスタンス化しなくても値を参照できます。
```java
System.out.println(num1.INTEGER_LENGTH_LIMIT);  // 30
System.out.println(num2.INTEGER_LENGTH_LIMIT);  // 30
System.out.println(numValue.INTEGER_LENGTH_LIMIT);  // 30
```

これはこのメンバがクラスに紐づくメンバだからです。

最後にもう一度まとめ

:::note info
* 非staticなメンバ：インスタンスに紐づく
* staticなメンバ：クラスに紐づく
:::

以上がstaticについて私が理解したことのまとめです。
（でもまだstaticなクラスって？と聞かれたら説明できないのでまた勉強して書きます。）

### 余談：staticファクトリメソッド
余談ですが、ここで実装している `isValidLength` メソッドは疑問の出発点だったstaticファクトリメソッドです。
staticファクトリメソッドの長所の１つである「メソッドの戻り値型の任意のサブタイプのオブジェクトを返せること」をしっかり享受しています。
（他にも長所はあるので、ちゃんと理解してそのうち書きます。）

このメソッドを利用して最初のコードを直してみます。
```java
String strNum = "1234.5678" // ほんとはcsvから読み取った値

try {
	BigDecimal bigDecimalNum = new BigDecimal(strNum);
	if (!bigDecimalNum.isValidLength) {
		// 桁数チェックエラーの処理
	}
} catch e {
	// 数値以外が入ってきた場合の例外処理
}
```

ビジネスロジックの中に定数をべた書きする必要もなくなってすっきりしました。（ここはstaticはあんまり関係ないかもしれないけど）


以上。
<br>
追伸
誤りなどありましたら是非ご指摘ください！
2次元空間内での2次関数のあてはめ（峰型）

*クイックハック。なんか動きが残念なので後で要チェック*

2次元格子上にデータが与えられていて次の関数形にあてはめたい。
```math
f(x,y) = a(x\cos\theta + y\sin\theta)^2 + b(x\sin\theta - y\cos\theta)^2
```
今やっている問題では峰型の極大域 $a<0, b<0, |a|>>|b|$ を考えている。角度 $\theta$ は未知数。

まずデータから極大値をみつけて、その周辺でテイラー展開あてはめをすればよさそうである。

展開すると次のように２次の項３つになる。
```math
f(x,y) = (a+b)x^2\cos^2\theta + 2(a-b)xy\cos\theta\sin\theta + (a+b)y^2\sin^2\theta
```

具体のデータの分析では、2次元配列内のデータに $x^2$, $y^2$, $xy$ を掛けて積算することで上記係数を得ることができる。
```math
X = \frac{\Sigma_{面内} x^2 f(x,y)}{\Sigma_{面内} x^2} = (a+b)\cos^2\theta
```
```math
Y = \frac{\Sigma_{面内} y^2 f(x,y)}{\Sigma_{面内} y^2} = (a+b)\sin^2\theta
```
```math
Z = \frac{\Sigma_{面内} xy f(x,y)}{\Sigma_{面内} xy} = 2(a-b)\cos\theta\sin\theta
```

となるはずなわけですね。すると $\cos^2\theta+\sin^2\theta = 1$ であるから
```math
a+b = X + Y
```
```math
\cos^2\theta = \frac{X}{X+Y}
```
```math
\sin^2\theta = \frac{Y}{X+Y}
```
までは簡単。
あとは、$a+b$ と $a-b$ が同符号と仮定すれば、というか、ここまでの段階で $a$ と $b$ の絶対値の大小は使っていないので、同符号となるように、つまり絶対値の大なるほうを $a$ と定義すれば、
$a$ と $b$ を算出するまでもなく、$X+Y$ と $Z$ の符号が一致するかどうかで $\cos\theta\sin\theta$ の符号を知り得ることになります。

まあそうはいっても病的な場合もあるので計算しましょう。
```math
|Z| = 2|a-b| \cdot |\cos\theta\sin\theta|
```
```math
|a-b| = \frac{|Z|}{2|\cos\theta\sin\theta|}
```

一応こうなるのですが、危険なのは $Z$ で除算しているところで、実データではほぼゼロになることもあるわけです。どういう場合かというと、$|a|$ と $|b|$ がほぼ同じということで、$\theta$の決定精度に疑問がでてきます。閾値はよくわかりませんが
```math
|a-b| < 0.1\cdot|a+b|
```
ならば排除といったところでしょうか。
【①アイデア選定】Vite+React+TypeScript+GitHubPagesで爆速サイト公開

## はじめに
業務ではVue.js+JavaScriptを使用しています。
が、もう少しモダンなフレームワークと言語に挑戦したい...ということでReactとTypeScriptをチョイスし、簡単なWEBアプリをつくることに:v:

...と思い立ったのが10月末。
「そういえば12月はQiitaアドベントカレンダーがあるな...そこまでに公開できたらいいな:sunglasses:」と思い、1ヶ月半程度で設計~公開まで行けると踏んで開発開始。

折角なので、制作の過程も含めて記事化してみました。

ということで、本記事は下記連載の第1弾となります。
他記事も併せてご覧ください。
[【①アイデア選定】](https://qiita.com/YutaManaka/items/f5db1d86239203db8ade)←イマココ
[【②技術選定】](https://qiita.com/YutaManaka/items/b1397c0624010b693a12)
[【③設計(ロジック)】](https://qiita.com/YutaManaka/items/6d412971574c4ca9fb1b)
[【④設計(デザイン)】](https://qiita.com/YutaManaka/items/5bb6b193149e68c9b742)
[【⑤環境構築】](https://qiita.com/YutaManaka/items/60bed57196386ccce931)
[【⑥進捗管理】](https://qiita.com/YutaManaka/items/beeba2bcba64d1d1c6bd)

ちなみに、公開サイトはこちら↓
https://yutamanaka.github.io/FragranceFinder/

リポジトリはこちら↓
https://github.com/YutaManaka/FragranceFinder

本記事では、アイデア選定の経緯についてまとめました:writing_hand:

## 対象者
この記事は下記のような人を対象にしています。

- 駆け出しエンジニア
- プログラミング初学者
- ポートフォリオのアイデア出しに悩んでいる方

## 結論
「目的と優先順位→アイデア出し→絞り込み→スケジュール決定」の流れでやれば間違いなし！

## アイデア選定までの基本の流れ
これは個人プロジェクトでも会社の仕事でも同じだと思いますが、下記のような流れで進めました。

:::note info
1. 目的と優先順位を決める
1. アイデア出し
1. アイデアの絞り込み
1. スケジュール決定
:::

## 目的と優先順位を決める
Qiitaアドベントカレンダーに間に合わせるため、1ヶ月半で完成することを前提に、本開発の目的と優先順位を下記に定めました。
上から順に優先順位が高いです。

:::note info
1. 設計~公開まで1ヶ月半で終わりそうなもの
1. 作っていて新しい知識が増えそうなもの
1. 作っていてワクワクしそうなもの
1. 他人に見せて自慢できそうなもの
1. 今まで自分が作ってきたものと関連がありそうなもの
1. (ちょっとだけ)世の中に役立ちそうなもの
:::

ものづくりの基本ですが、いきなりアイデア出しをせず、**目的を先に決める**ということが大事です。

また、優先順位をつけるのも大事。
アイデアを絞り込む際にぶれ流ことが少なくなります。

さて、基本方針が定まったので、続けてアイデア出しをしました。

## アイデア出し
今回はフロントエンドのみの開発になるので、複雑なDB構造が必要なアイデアは省きました。
その上で面白そうなもの、作りたいものをリストアップしました。
私の趣味の「料理、旅行」や前職の香水関連のアイデアなどなど...

:::note info
- 料理アイデアジェネレーター(食材×調理法×〇〇風)
- 香水クイズ
- 香水診断
- 香水ガチャ
- 香水豆知識ガチャ
- 今日の元素ガチャ
- 香水ジェネレーター(トップ/ミドル/ラスト)
- 今日の朝食卵料理ガチャ
- 旅行行き先ガチャ(ダーツの旅的な)
:::

## アイデア絞り込み
そこそアイデアが出たので、絞り込みます。
方針で定めた優先順位1,2のを基準に絞り込み。
|アイデア |納期        |技術力UP    |
|-------|------------|------------|
| ガチャ |◎(簡単)      |×(簡単すぎる)|
| ジェネレータ |◎(簡単)      |×(簡単すぎる)|
| クイズ |◎(簡単)      |△(複数ページ作成+ロジックはほぼ不要)|
| 診断  |△(ちょっと大変)|○(複数ページ作成+ロジック構築も必要)|

あまり簡単すぎても技術力UPできないので、**診断系のアイデアを採用**することにしました:sunny:

また、下記の基準を参考に**香水の診断コンテンツ**を制作することに決定！

:::note info
 4.他人に見せて自慢できそうなもの
 5.今まで自分が作ってきたものと関連がありそうなもの
 6.(ちょっとだけ)世の中に役立ちそうなもの
:::

ちなみに、過去に下記の香水ブログをwordpressにて作成したことがありました。
このブログと関連した診断コンテンツを目指しました！

https://yutaka-perfume.com/

## スケジュール策定
アイデアが決まったので、ざっくりとスケジュールを引きます。
6週間で公開したいので、下記の通り。

:::note info
1週目：技術選定+設計(ロジック)
2週目：設計(デザイン)+素材集め
3週目：環境構築
4週目：実装
6週目：実装+公開
:::

進捗管理はClickUp、ドキュメントはnotionで作成しました。

## おわりに
個人プロジェクトのアイデア選定方法についてまとめました。