OmniAICreator/Qiita-1.07M huggingface dataset:
ソフトウェアエンジニアのための6つの効果的な時間管理戦略

## 1. タスクを優先順位付けする
- アイゼンハワー マトリックスを使い、緊急度と重要度に基づいてタスクを分類
  - **「今すぐ実行」**: 重要かつ緊急なタスク
  - **「計画する」**: 重要だが緊急ではないタスク
  - **「委任する」**: 緊急だが重要ではないタスク
  - **「削除する」**: 重要でも緊急でもないタスクを削除

https://asana.com/ja/resources/eisenhower-matrix

## 2. 現実的な目標を設定する
- 目標を **具体的、測定可能、達成可能、関連性のある、期限付き（SMART）** に設定する。
- Markdownファイルを活用して毎日の目標を明確にし、タスク完了時に記録することでモチベーションを維持。

https://asana.com/ja/resources/smart-goals

## 3. マルチタスクを避ける
:::note warn
タスクを切り替えるたびにコストが発生します。疲労が溜まり、同じことをするのに必要な時間が増えます。
:::
人間の脳は同時並行作業には向いていないのでシングルタスクに集中して片付けていきましょう。

https://asana.com/ja/resources/multitasking

## 4. 定期的に休憩を取る
- **ポモドーロ・テクニック**を活用し、25分作業 + 5分休憩のサイクルを実践
- 定期的な休憩は集中力を維持し、燃え尽き症候群を防ぐ
- パワーナップ（積極的仮眠）は眼精疲労の回復、脳のリフレッシュになります

https://apps.apple.com/jp/app/time-timer/id332520417

https://asana.com/ja/resources/pomodoro-technique

https://www.starbucks-kenpo.or.jp/my_wellness/mindset/list23.php


## 5. 「ノー」と言うことを学ぶ
- 必要以上のタスクを引き受けないようにする。
- 優先順位が低いものや不要なものは**削除**または**断る**ことが重要。

https://www.lifehacker.jp/article/222503-3-reasons-why-saying-no-more-often-might-be-good-for-you/

## 6. 整理整頓を徹底する
- **Trello**や**Asana**のようなツール、またはMarkdownファイルを使い、タスク管理を行う。
- 自分に合った方法で進捗を追跡し、締め切りを守る。

https://www.leadmind.jp/news/clear-your-thoughts-with-action/2024/06/19/


## まとめ
時間管理は、ソフトウェアエンジニアにとって重要なスキルです。
作業負荷を効率的にこなし、目標達成に近づきましょう。
時間管理の本質は　**「量をこなす」ことではなく、「適切なことを適切なタイミングで行う」**　ことにあると考えます。
Jacobi法による固有値分解の解説とプログラミングの実装

## <span style="color:purple;">はじめに</span>
固有値問題は、数値計算や機械学習の分野で頻繁に登場する。本記事では、行列の固有値と固有ベクトルを求めるための数値計算手法である **Jacobi法** を解説する。Pythonのコードと数式を組み合わせながら、アルゴリズムの動作を詳しく説明する。

---

## <span style="color:purple;">Jacobi法とは？</span>
Jacobi法は、**回転行列** を使って対象の行列を対角化し、その結果として固有値と固有ベクトルを得る方法である。対象となる行列 $A$ に対して、以下のように行列の対角化を繰り返し行う。：

$$
A' = Q^T A Q
$$

ここで、$Q$ は回転行列である。回転を繰り返すことで、非対角要素が十分小さくなるまで処理を行う。

---

## <span style="color:purple;">Jacobi法のアルゴリズム</span>
Jacobi法は以下の手順で進行する：

1. 行列 $A$ の最大非対角要素 $(i, j)$ を特定する。
2. 回転行列 $Q$ を次の式に基づいて構築する：
   - 回転角度 $\phi$ は次式で決定：
     $$
     \phi = \frac{1}{2} \arctan\left(\frac{2A_{ij}}{A_{ii} - A_{jj}}\right)
     $$
   - 回転行列 $Q$ の成分：
   ```math
     \displaylines{
         Q_{ii} = \cos{\phi} \\
         Q_{ij} = - \sin{\phi} \\
         Q_{ji} = \sin{\phi} \\
         Q_{jj} = \cos{\phi}
     }
    ```
3. 行列の更新：
   $$
   A' = Q^T A Q
   $$
4. 非対角要素が収束条件を満たすまで繰り返し。

---

## <span style="color:purple;">Pythonコードの解説</span>
以下は、PythonによるJacobi法の実装である。

```python
import numpy as np
import numpy.linalg as LA

def jacobi(A, eps=1e-10):
    n = len(A)
    A = A.astype(np.float64)
    eigenvectors = np.eye(n)
    while True:
        max_idx = None
        max_val = 0
        for i in range(n):
            for j in range(i+1, n):
                if abs(A[i, j]) > max_val:
                    max_val = abs(A[i, j])
                    max_idx = (i, j)
        if max_val < eps:
            break
        i, j = max_idx
        if A[i, i] != A[j, j]:
            phi = 0.5 * np.arctan2(2 * A[i, j], A[i, i] - A[j, j])
        else:
            phi = np.pi / 4

        Q = np.eye(n)
        Q[i, i] = np.cos(phi)
        Q[j, j] = np.cos(phi)
        Q[i, j] = -np.sin(phi)
        Q[j, i] = np.sin(phi)
        
        A = Q.T @ A @ Q
        eigenvectors = eigenvectors @ Q
        
    return np.diag(A), eigenvectors
```

---

## <span style="color:purple;">テストケース</span>
以下の行列を使って、Jacobi法の動作を確認する。

```python
A = np.array([[2, 1], [1, 3]])
```

#### <span style="color:blue;">jacobi関数の実行</span>

```python
eigvals, eigvecs = jacobi(A)
print('Eigenvalues:\n', eigvals)
print('Eigenvectors:\n', eigvecs)
```

#### <span style="color:blue;">numpy.linalgを使った検証</span>

```python
import numpy.linalg as LA
print('Check with Numpy:')
print('Eigenvalues:\n', LA.eig(A)[0])
print('Eigenvectors:\n', LA.eig(A)[1])
```

### <span style="color:red;font-weight:bold;">実行結果</span>

```python
Eigenvalues:
 [3.61803399 1.38196601]
Eigenvectors:
 [[ 0.52573111 -0.85065081]
 [ 0.85065081  0.52573111]]

Check with NumPy:
Eigenvalues:
 [1.38196601 3.61803399]
Eigenvectors:
 [[-0.85065081 -0.52573111]
 [ 0.52573111 -0.85065081]]
```

---

### <span style="color:red;font-weight:bold">検証結果</span>

- Jacobi法で求めた固有値と固有ベクトルは、NumPyの関数を使って求めた結果と一致していることが確認できる
- 一見すると、固有ベクトルの符号が異なるように見えるが、固有ベクトルは定数倍されても同じベクトルとして扱われるため、正しい結果である。また、固有値の順番が逆になっているが、これは固有値の順番を定める規則を持たないためである

---

## <span style="color:purple;">まとめ</span>
Jacobi法は、行列の対角化を行うための数値計算手法で、回転行列を用いて非対角要素を小さくしていく方法である。本記事では、Pythonコードを通じてその仕組みを説明した。さらに深掘りしたい場合は、QR法やパワー法など他の固有値問題のアルゴリズムも調べてみると良いだろう。

---
Next.js+TailWindCssでInvalid or unexpected tokenが発生

## はじめに

Typescript + React + Next.jsの勉強中です。

少しずつコードを書き始めました。

ですが、初回ロードのみ、なぜか下記のエラーが発生していました。

リロードすると消えます。

```
Uncaught SyntaxError: Invalid or unexpected token (at layout.js:287:29)
```

## 原因

tailwind.config.ts のcontentに、存在しないディレクトリを設定していた。


```
export default {
  content: [
    "./pages/**/*.{js,ts,jsx,tsx,mdx}",
    "./components/**/*.{js,ts,jsx,tsx,mdx}",
    "./app/**/*.{js,ts,jsx,tsx,mdx}",
  ],
```

## どうしてこうなったか
私が使用しているNext.jsのverが15のため、pagesディレクトリを使用していませんでした。

ですが、公式サイトに記載されていた設定をそのまま書いてしまっていたため
pagesディレクトリの記述も残ってしまったのです。

とりあえずやってみよう。
と理解せずに進めたのが悪かったです。

## おわりに
pagesディレクトリの記述を削除するとエラーは消えました。
しかし、なぜ初回ロード時にのみエラーが発生するのかがまだ理解できていません。
レンダリングのタイミングなのでしょうか。。
まだまだ道のりは遠いですね。
リンクアンドモチベーションにおけるDify民主化への取り組み

## 背景
弊社、株式会社リンクアンドモチベーションでは生成AIを活用した生産性向上プロジェクトを2024年から本格的に行なっています。

これまでは、事業部がエンジニアに依頼しエンジニアがツールを開発する、という開発フローでしたが、多様化する社内ニーズに対応するための開発速度が課題となっていました。
この課題を解決し、生産性向上を加速する手段として、事業部のコンサルタントをDifyエンジニアへと育成する取り組みが始まりました。

## 事業部のDifyエンジニア育成の目標と実績
### 目標
2025年末までに、
「**コンサルタント全員、Difyエンジニア**」を目標としています。

それにより、
・コンサルタントが自業務で効率化したいツールを自分で作る
・コンサルタントがプロトタイプを作成し、部分的なコーディングのみ開発部門へ依頼を出す
上記の開発フローへと変化を遂げ、開発生産性の向上を目指しています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3928191/7d09f805-3819-cbe5-1098-a254fbbe4a3a.png)

### 現在の実績
2024年9月から1部署にて取り組みを開始し、2か月で以下の成果を創出しています。

#### 開発実績
・コンサルタント6名がDifyエンジニアとしてツール開発に従事。
・2か月で12個のツールを開発。

#### 具体的な開発物
| ツール名 | 概要 |
|:-:|:-:|
| 組織サマリくん　  | 顧客名を入力すると、統合報告書などから業界や企業の現状と今後の展望を要約する。  |
| 資料分析bot  | 顧客に関するPDF資料を入れると、特定の項目で情報を整理する。  |
| PM相談bot  | 過去の事例や業界データをもとに、コンサルタントがプロジェクトを推進する上での質問や相談に回答する。 |

#### 効果
・Difyツールで年間100時間/人の業務削減を実現。
・要求整理や要件定義の時間が短縮され、ツール開発までのリードタイムが約50%短縮。（15日 → 8日）
・自案件のコンサル業務をその場でDifyによって効率化し、1案件あたり30時間の時間短縮。

## 育成における課題と打ち手
Difyエンジニア育成において、起こった課題に対して、打ち手を講じました。

　
- **ツールの概念を理解できず、開発が進まない**
<課題>
・「変数」「RAG」などの概念が理解できず、Difyを上手く使うことができない。
<打ち手>
・座学はほとんどせず、とりあえず楽しく使ってみるところから始める。
・サンプルをいくつか用意し、ノードをコピー&ペーストするところから始める。
・週1回のペアプログラミングにより、即座に疑問点が解消できる体制を整える。

サンプル例
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3928191/93c09c75-6019-2018-1285-15dc5b627545.png)

　　
- **プロンプト設計の難しさ**
<課題>
・プロンプト設計ができず、アウトプットの精度を高められない。
<打ち手>
・AI人材要件を策定し、Dify開発に必要なプロンプトスキルを事前に習得した状態で開始する。

| AI人材要件　 | 概要 |
|:-:|:-:|
| レベル4  | ノーコードツールや基本的なコーディングを用い、外部サービスとの連携処理ができる  |
| レベル3  | Difyを用いて、簡易的なAIツールの開発を行うことができる  |
| レベル2  | プロンプトエンジニアリングを駆使し、自業務の効率化ができる  |
| レベル1  | AIツールを業務で日常的に使う習慣がある  |


- **時間が捻出できず作れない**
<課題>
・通常業務を優先し、Difyを触る時間が取れない。
<打ち手>
・コンサルタントの期初の目標設計にDifyツール開発に関する目標を置く。
・目標設計に応じた稼働割合の計画を事前に実施する。

## まとめ
Difyをコンサルタントが活用し始めてから、以下のメリットを感じています。

- 事業部での自立的に生産性向上ができる
・課題発見～開発までコンサルタントが行い、自部署の業務の効率化が自分自身で実行できる

- エンジニアの一部民主化
・簡易的なツールをコンサルタントが作ることで、開発部門のエンジニアはより高度で中長期的な課題解決に専念できる

個人的には、Difyエンジニアの方から、「出来ることの広がりを感じて仕事が楽しい」との声をもらっているので、一人ひとりのキャリア形成にも好影響を及ぼしていけたらと思っています。
camelCaseとは?

この記事は東京海洋大学NePPの Advent Calendar 2024の12日目です。

## はじめに
以前の記事において初心者なりに「**変数には規則がある**」ということが分かりました。
この変数の規則には、もうひとつ私が疑問に思っていたことが解決しました。
それは、**なぜ変数の途中で大文字が出てくるのか**についてです。

この事柄についても**キャメルケース**という規則があるそうです。

## キャメルケースについて
<img width="300" alt="スクリーンショット 2024-12-11 183030.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3946215/76c76e5a-8618-96e1-401b-1a8364ea7513.png">

上記の写真から与えた関数はすべて小文字になっています。
これだとかえって分かりやすい単語でまとめたというのに、見づらくなってしまいます。
</br>
しかし見やすいように空欄を作ることもできない。
![スクリーンショット 2024-12-12 194912.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3946215/78bc9513-6934-cb9f-6aea-8d7d5ce950fe.png)
</br>
そのために単語の区切りにあるアルファベットを**大文字**にすることで分かりやすくしているということです。
<img width="300" alt="スクリーンショット 2024-12-12 194645.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3946215/179eadc8-555c-7353-ec83-5be9d1cee70f.png">

心なしか見やすくなった気がします。

どうしてラクダのケースなのかは、
途中に大文字があることで出来た凸凹間がラクダに似ているからだそうです。

## パスカルケースもある
キャメルケースに続いて**パスカルケース**もあるそうです。

「アルファベットの区切りを大文字にすることで分かりやすくしているのか、、フムフム」と変数の最初の文字も大文字にしていました。
<img width="300" alt="スクリーンショット 2024-12-11 185809.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3946215/ef22e5b7-e190-ce09-7c54-dffc26a5392c.png">

これだとパスカルケースという規則になるそうです。
ほぼ似ているのに異なっているというのは難しい、、

**変数の頭文字も大文字になっているのはキャメルケースではなく、パスカルケース**

## まとめ
参考するコードを見ているとなぜ変数の途中が大文字なのか疑問に思っていました。予期せぬところでこういった疑問が解決できたのは嬉しかったです。

### 参考
- [命名規則についてまとめてみた](https://wa3.i-3-i.info/word1179.html)
- [キャメルケースとは](https://wa3.i-3-i.info/word1179.html)
UDPとは

# ネットワーク層は２つのプロトコルがある
>トランスポート層にコネクション指向とコネクションレスの２つの主要なプロトコルを持つ。２つのプロトコルはお互いを補っている。コネクションレスのプロトコルはUDPである。UDPはアプリケーション間でのパケット送信以上に何もせず、アプリケーションが必要に応じて上位に独自のプロトコルを築き上げてさせる。

### UDPはOSで動作する
>UDPは一般的にオペレーション・システムで動作するトランスポート層プロトコルであり、一般的にUDPを使うプロトコルはユーザー空間で実行されるため、UDPを使うプロトコルはアプリケーションにとって有効なものと考えられるかもしれない。

# UDP(User Datagram Protocol:ユーザー・データグラム・プロトコル)
>コネクションレスのトランスポート・プロトコルであるUDP(User Daatagram Protocol:ユーザー・データグラム・プロトコル)をサポートしている。UDPは、コネクションの確立を必要とせず、カプセル化されたIPデータグラムの送信手段を提供する。

### セグメントの構成 ポートが大事
>UDPが転送するセグメントは`8バイトのヘッダー`とそれに続く`ペイロード`から構成される。図6−27に示すヘッダーの中で、`二つのポート(port)番号は送信元と宛先のマシン間のエンド・ポイント`を識別する役割を果たしている。UDPパケットが到着すると、そのペイロードは宛先ポートに結び付けられたプロセスにわたさえれる。
..
UDPを生のIP上で利用する意義は主に、送信元ポートと宛先ポートが加えられるところにある。ポートフィールドがないと、トランスポート層は、パケットをどのように扱えば良いのかわからない。`ポート番号があってこそセグメントを正しく配送`される。

### 送信元ポート　送り返すために必要
>送信元ポートは主に、`応答を送信元に送り返す際に必要`とされる。応答を送信するプロセスは、`入力セグメントの送信元ポートを出力セグメントの宛先ポートにコピー`することで、（応答の）宛先マシン上のどのプロセスがそれを受け取るべきかを指定できる。

### チェックサム
>`オプションのチェックサムはさらに信頼性を高める`。
...
データの品質が問題隣らない場合を除き（デジタル音声など）、このオプションをオフにすべきではない。

### UDPの仕事　最低限のことをするポートを利用する複数プロセスをネットワーク層へ送り出す
>UDPは`フロー制御や誤り制御、誤ったセグメントを受け取った際の送信は行わない`。これらはすべてユーザー・プロセスの仕事である。UDPの仕事は、`ポートを利用する複数プロセスを逆多重化する機能やオプションのエンド・ツー・エンドの誤り検出を付け加えた形で、IPプロトコルへのインタフェースを提供`すること、これがすべてのである

### クライアントサーバーはUDPに有用な領域
>クライアントはタイムアウトしてリトライできる。TCPのような初期設定を必要とするプロトコルに比べて、`プログラムが単純化されるだけでなく必要なメッセージ数を減らすことができる`。

https://bookplus.nikkei.com/atcl/catalog/23/03/16/00728/
プロジェクト終了後のレトロスペクティブの重要性

# はじめに

プロジェクトが終わるとよかったよかったで終わらせてしまいがちではないでしょうか?
いわゆる振り返りですが、重要とはわかっていつつそもそも何を振り返ればいいのか?などからわかりません。
そこで私も整理しつつ、重要性を確認したいと思います。
尚、この記事ではプロジェクト終了後にフォーカスしたいと思います。

# 何を話すか?

こういったミーティングを行うとどうしても反省会になりがちです。
確かに反省点は話し合うべきものの内の一つですが、トピックとしては以下3点でしょう。

* 成長できた点
* 成功体験として次回も継続したいこと
* 反省点について次回どうすればよいか?

# どのように開催するか?

オープンに話すことができる状態が好ましいです。
ので、上司やリーダーはあまり否定的な言葉は発しないようにした方がよいでしょう。
また、事前に振り返りの為のフレームワーク (何を話すか?のもの)を作成しておきましょう。

# 振り返りの例

* 成長できた点
データベース設計において概念設計に携わることができたため、構築するシステムに対しデータ中心アプローチを意識しての設計を学ぶことができた。
パフォーマンスの問題を解消したことにより、DBのチューニングについて学ぶことができたため、 次回設計時には最初から取り入れることができそうである。
* 成功体験として次回も継続したいこと
共通となるコンポーネントをGitに配置、submodule化することによって、他プロジェクトにおいても 活用可能な状態にできた。
以後継続して共通コンポーネント化を進めることで開発コストの低減につなげられると考える。
スタンドアップミーティングを毎日行うことにより自身の進捗を振り返ることができるほか、他メンバーからのフォロー、もしくは他メンバーへのフォローを積極的に実施できていた。
* 反省点について次回どうすればよいか?
設計局面において事前の相談があまりできておらず、大きく手戻りが発生した。
要件定義書などから不明な点、認識合わせが必要な点はリーダーに逐次相談することで 手戻りのない開発を行いたい。
> リーダーより
> リーダとしてフォローアップが適切ではなかった点もある。
> 次回プロジェクトにおいては要件定義書の読み合わせなど、設計の前提となる知識を共有する場を設け あやふやな点がなるべく発生しないよう努めたい。

いかがでしょうか?
こういった例を最初にしめしてあげることも重要で、何を書けばいいのだろう・・・という担当者の疑問も 解消できそうです。

# 終わりに

私自身ちゃんとできているか?というところは怪しげなところです。
今回どのような振り返りをすべきか？についてはAIの助力を受けたところですが
確かに過去在籍していた組織では同じようなアプローチをとっていたなと思い出しました。
自分で整理していても、メンバーがどのようなところを成長できたか、是正したいのか?という点を吸い上げることができるため、やはり重要であるなと考えます。
PL/PMの経験の吐き出し

# はじめに

エンジニア歴がずいぶん長くなってきました。
望んだわけではないですが、PL/PM的なポジション(というかグループか・・・?)をもう5年以上続けており 作っているときの苦悩とは別のものが降りかかってくるものです。
昨今PL·PM・PMOを募集します! という求人も多く見られ、経験してみたい!と思う方もいるでしょう。
その反面、そもそも何するの?というのがわからない・・・と思われるでしょう。
少しでもそのもやもやの解消になればなと思い記事にしてみました。

# お仕事の内容

組織によってまちまちだとは思いますが、私の経験談として。

* 要件定義
* コスト試算および見積の作成
* 基本設計
* 関係部署に対する依頼 (インフラなど)
* プロジェクト開始に向けたプランニング、アサインの検討
* 各種レビュー対応
* 進捗確認及び遅滞の解消の検討
* デリバリ方法の検討
* プロジェクトクローズに向けたドキュメントのとりまとめ
* 各種社内書類等対応

こんなところでしょうか。
わたしも他の組織でリーダー・マネジメントを行ったことがないので、多いのか少ないのかよくわかりませんが、幅広く対応が必要です。

# 社内ルールの理解が必要

開発者である内もある程度自分の作業範囲では理解が必要ではありますが、基本的には指示に従うものでしょう。
指示を出すためにルールがどのようになっているのか?という理解が必要となります。

例えば、
* 設計書は何を残すのか?様式はなにか?
* レビューの承認は誰が行うことができるのか?
* レビューの観点などはどのようになっているか?
* それぞれ成果物のインプットなどはどのように追跡させるのか?
* 各種決裁は誰が行うのか?

などルール・規定を理解しないとお仕事を進められません。

# コスト試算はメンバーを意識して行う

ここでは人とどのくらいの期間の開発となるか?についてとなります。
まず定量的な基準を私は作ります。
データ数・画面数・コントロールの難易度などそれぞれ基準を設けて積み上げていきます。 
人によって得手不得手もあり、同じことをさせても同じ日数では終わりません。 
基準となる値に対してどのくらいで完成させたか?を前もって確認しておきます。 
基準の1.5倍かかる人なら1.5倍の期間を見積もるなどすることで、おおむね予実が一致してきました。 
同じメンバーで開発をしていたことがある場合にのみ使えますが、人毎の生産性は記録が取っておいた方が良いです。
問題はこの基準をなににするか?です。
場合によっては、3倍も4倍もかかる場合もあります。
その為、前はどうであったか?を参考としています。

# 進捗確認

何か静的に見ることができるプロジェクト管理ツールがあるとよいです。 
進捗率などを必ず入れるよう周知徹底しないと、いつまでも進んでいないな・・・などということに陥ります。 
また、経験が浅い場合、そもそも今どのくらいの進捗なのかがわかっていない人もいます。 
そのような場合は、一度全体の作業を細かく分け、それぞれどのくらいのエネルギーがかかってくるか? など考えてあげましょう。

# レビュー対応

規模が大きければ大きいほど大変ですが、一つ一つ必ず実施します。 
意識しなければならないのは、通してあげるところと、絶対に通さないところはメリハリつけた方が良いです。 
わたしも最初は細かく全て指摘・差し戻ししていましたが、いつまでたっても終わりません笑 
絶対に通しちゃいけないところ(ルールを守っていない、現実的にバグにつながる) ところは差し戻して、それ以外は認識を共有するにとどめることにしています。

# プロジェクトクローズに向けたドキュメントのとりまとめ

プロジェクト管理ツールで何とかなりそうではありますが、ここも社内ルールに従うところです。
* 各自で行った設計書やテスト仕様書など取りまとめ
* 設計書根拠となっているのは何なのか?
* デリバリ方法はどのようにすることになったのか?
* 運用監視体制はどのようになったのか?
* 本番稼働時の手順はどうすればよいのか?
* データの移行が必要な場合などその手段はどうするのか?

など取りまとめます。

決裁方法などはそれぞれの組織によりますが、承認者がこのシステムはルールに沿って作られたものなのか?
今後どのように運用・監視されていくのか?など安心して承認してもらえるようにまとめる必要があります。
上司にここに全部入ってますから〜！というわけにはいきませんよね笑？

# 終わりに

開発だけをやっていたころは、納期に追われてヒィヒィ言っていましたが、PL/PMとなるとルールとメンバー・対外との均衡にヒィヒィ言うようになります。
正直開発だけやっていたころが楽だったなぁ〜と思いますが(これもPL/PM次第でしょう)、 歳をとると致し方ないところでしょう。
(心象は別として) 実は相談はできなくても仕事ができる世の中なのでは?とPMおじさんが思ってしまった

# はじめに

報連相は大事である。

それは私も変わりません。
コミュニケーションを積極的に行うことで相互に補助しあう関係で仕事を進めることにより、お互い高めあうような仕事の進め方が正しいと今でも思っています。(古いかもしれませんが) 
そのような中、生成AIが登場し、相談についてはもしかしたら自分で完結できてしまうかもしれない・・・と思ってしまったことについてご紹介したいと思います。

# 技術的な質問

技術的な質問について、自分で調べろ派は多いかもしれませんが、私の場合は開ける人がいるなら開け派 なのですが賛否両村でしょう。
もちろん調べたけどたどり着けなかった・・・とか、調べ方を教えてほしいとか聞き方には気を付けるべきですが、生成AIを活用することで気にしなくなりました。
なにせ、嫌な顔一つせず何を聞いてももちろんです!と言ってくれるのです。
ちゃんと自分の状況、聞きたいこと、期待値と違っていることなど伝えるとある程度答えにたどり着きます。
ChatGPTなど初期のころは全然嘘ばかり教えられた気がしますが、昨今Copilotなど使うと相当精度が高くなって 来たなと思います。
技術的な助けについては相談というものは不要になったのかもしれません。
ただ気を付けてほしいのは、承認者はどう考えるか?です。
正論だけをつき通しても相手に不快感を与えるだけですし、承認者の意見もうかがうというのは円滑に仕事をする上で大事なことだというのはおじさんの意見です。

調べものだけではなく、コーディングにも長けてきています。
一番使いやすいのはユーティリティな関数を作ってもらうなどですね。
この手のは調べればいくつも出てきますが、自分の用途とちょっと違ったり、要求がニッチすぎてあまり出てこないなどもあります。

こういった場合、生成AIはここはこうしてほしいなどとお願いすると聞いてくれます。
調べ物の中に含まれるかもしれませんが、要件定義時の技術要件を整理する際にも使えます。
これまでやってきたことのあるような内容であればこれはできますと即答できますが、やったことないようなものについては技術検証もしくは調査によって可否を判定する必要があります。 
そこで生成AIでは「できます。」「できません。」と即答してくれますので圧倒的に時間短縮になります。
ただ、どこまで信じてよいものか?というのは自己責任になります笑

# その他 お悩み相談

大人としての悩み事(愚痴)に関しても親身になって聞いてくれます。
ただ、良くも悪くも論理的にアドバイスを返してくるため、「そうゆうことじゃないんだよ・・・」 と聞いてほしい的な相談をするとちょっとがっかりすると思います。
逆に論理的アプローチが欲しい時などは重宝しますが、職場全体を巻き込むなど少しスケール大き目ですので 個人的に効くには向いていないかもしれません。

# 終わりに

新人の頃は同期や先輩がいて色々相談ばかりしていたものですが、今となっては私も歳をとり、相談先が少なくなってきました。 
最初に書いた通りコミュニケーションを大事にするというのは変わりませんが、人とコミュニケーションを取らなくても仕事が進められてしまう世の中が進んで来たんだなと 少し寂しく思います。
そのような中、私の技術的相談、愚痴に付き合ってくれる生成AIには非常に助けられるばかりです。
【Salesforce】非同期のFutureメソッドとQueueableクラスって何が違うの？

**Futureメソッド**と**Queueableクラス**は、Salesforceで非同期処理を行うための仕組みです。

それぞれの特徴と使い方について説明します。

---

## **1. Futureメソッド**
Futureメソッドは、**非同期で軽量な処理**を実行する際に使用します。

### **特徴**
- **軽量**: 簡単に非同期処理を設定できる。
- **単一のトランザクション**: 実行される処理は完全に独立している。
- **コールアウト対応**: `@future(callout=true)` を指定すると、外部API呼び出しが可能。
- **制限事項**:
  - メソッドの引数は**プリミティブ型**（例: `String`, `Integer`）か**コレクション型**（例: `List<String>`）のみ。
  - メソッドから戻り値を取得できない。
  - コンテキスト情報（ジョブIDなど）を追跡するのが難しい。

### **例**
#### **Futureメソッドの宣言**
```apex
public class FutureExample {
    @future(callout=true)
    public static void executeFuture(String accountId) {
        // 外部APIコールアウトなどの処理
        System.debug('Executing future method for Account ID: ' + accountId);
    }
}
```

#### **トリガやクラスからの呼び出し**
```apex
trigger AccountTrigger on Account (after insert) {
    for (Account acc : Trigger.new) {
        FutureExample.executeFuture(acc.Id);
    }
}
```

---

## **2. Queueableクラス**
Queueableクラスは、**非同期で複雑な処理**や、**状態管理が必要な処理**を行う場合に使用します。

### **特徴**
- **状態管理**: 非同期ジョブの処理状況を追跡可能（ジョブIDを取得できる）。
- **柔軟な引数**: クラスのコンストラクタで任意の型を引数に受け取れる。
- **コールアウト対応**: `Database.AllowsCallouts` インターフェースを実装すれば外部API呼び出し可能。
- **連鎖処理**: `System.enqueueJob()` を使って、別のQueueableジョブをキューに追加可能。
- **制限事項**:
  - 同じQueueableクラスの連鎖呼び出しは50回まで。
  - 扱えるレコード数は1回の実行で50,000件まで。

### **例**
#### **Queueableクラスの作成**
```apex
public class QueueableExample implements Queueable, Database.AllowsCallouts {
    private String accountId;

    // コンストラクタ
    public QueueableExample(String accountId) {
        this.accountId = accountId;
    }

    // executeメソッド
    public void execute(QueueableContext context) {
        System.debug('Executing queueable job for Account ID: ' + accountId);
        // 外部API呼び出しや複雑な処理を実行
    }
}
```

#### **ジョブの登録**
```apex
trigger AccountTrigger on Account (after insert) {
    for (Account acc : Trigger.new) {
        System.enqueueJob(new QueueableExample(acc.Id));
    }
}
```

#### **ジョブIDの取得**
```apex
Id jobId = System.enqueueJob(new QueueableExample('0015g00000xxxxx'));
System.debug('Queueable Job ID: ' + jobId);
```

---

## **Futureメソッド vs Queueableクラス**
| **項目**                 | **Futureメソッド**           | **Queueableクラス**          |
|--------------------------|-----------------------------|-----------------------------|
| **柔軟性**               | 少ない                     | 高い                       |
| **引数**                 | プリミティブ型、コレクション | 任意の型（カスタムクラス含む）|
| **戻り値**               | なし                       | ジョブIDで追跡可能          |
| **ジョブ連鎖**            | 不可能                     | 可能                       |
| **コールアウト**          | 可能（`@future(callout=true)`）| 可能（`Database.AllowsCallouts`）|
| **追跡可能性**            | 低い                       | 高い                       |
| **主な用途**              | 軽量でシンプルな処理         | 複雑で連鎖的な処理          |

---

## **どちらを使うべきか？**
- **シンプルで軽量な非同期処理**が必要 → **Futureメソッド**
- **複雑な処理や状態管理が必要** → **Queueableクラス**

### **例: 外部API呼び出しの場合**
- **簡単な外部APIコールアウト**: Futureメソッド
- **複数のステップを伴うAPIコールアウト**: Queueableクラス

用途に応じて使い分けましょう！
オブジェクト指向Cコンパイラ comelangでpicoのosがビルドできました。

https://github.com/garyexplains/piccolo_os_v1

piccolo_os_v1です。comlangでもコンパイルできました。
comelangのpiccolo_osでsh all_build.shしてください。
できたcp build/piccolo_os_demo.uf2をPICOのドライブにcpしてください。

オンボードのLEDとscreen /dev/PICOのttyで同時にUSBの出力とオンボードのLED
が点灯しているのがわかると思います。

僕的には自分でOSを作ったと思ってます。とりあえず、20年くらい思っていたOSを作るという夢が叶ったと。

OSの定義は難しいと思いますが、結局並列処理がOSだと思います。あとはデバイスドライバの動的ロードあたりですかね。

まあ、comelangでPICCOLOはコンパイルできたので、comelangでPICCOLOをどんどん開発していくことは可能だと思います。デバイスドライバのロードやUNIXのシステムコールの実装など。
そのあたり、また暇になればやっていきたいと思います。

あとはUEFIでのOSの開発などです。UEFIはSDKでOS開発できるようなので、まあ、気が向けばやりたいともいます。UEFIのSDKもcomelangが簡単な例は通ってます。　
Rustもベアメタルができると言いますが、comelangもベアメタルができます。

ああ、あと気づきましたが、ヘアドキュメントはcppを通すため使い物になりません。廃止はしませんが、マニュアルに明記したいと思います。
他の機能は大体いい感じで動いてます。マシーンネイティブな環境の開発もcomelangは守備範囲です。

これほど抽象度が高い言語で、バリバリネイティブな処理も書けるcomelang。あなたも使いませんか。
RとRStudioで始める分析入門

# はじめに
こんにちは。
[ CYBIRD Advent Calendar 2024 ](https://qiita.com/advent-calendar/2024/cybird) 17日目担当の @kazurasaka です。
16日目は @alexa さんの「[TyranoScriptのWKWebViewメモリー最適化とクラッシュ対策](https://qiita.com/alexk/items/962cd61dfc1b4b6f007d)」でした。

TyranoScriptのメモリー消費増加によるクラッシュ問題に対しての解法、試行錯誤が見て取れます。
WKWebViewとCSSアニメーションの相性はいかんともしがたいですね。

それでは本日の内容と参りましょう。
肩肘張らずにさらっと読んでいただけるものをご用意いたしました。

# 概要
自分の知らない技術や新しい技術に触れておもろ、ってなるのが趣味です。
対戦よろしくお願いします。
それはさておき、ここ1〜2年新しいことやってないなーなんかしたいなーと思って、
今回は **R言語** に触れてみました。

## R言語とは？
統計解析に強みを持つインタプリタ型のプログラミング言語です。
インタプリタ型には PHP や Ruby や JavaScript なんかがありますね。
（余談ですが、名前が似ていたので R は Ruby のスーパーセットかと思ってました。全くの別物でした謹んでお詫び申し上げます）

### 統計分析仲間の Python くん
同じく統計分析によく使われるのに Python がありますが、これと R の大きな違いは **汎用性** です。
Webアプリなどは R では作れません。Python では作れます。
R は統計解析全振り。潔いね。

## 事前準備
R（言語）と RStudio（統合開発環境）を入れます。
入れ方は山のように転がってるので調べてください。
遊ぶためのデータはなんと R に100以上同梱されてます。親切。
もちろん自分で作っても構いません。

## ヒストグラム図を描いてみる
```r:sample.R
df <- read.csv("sample.csv")
x = df$mike
hist(x, breaks=100)
```
これは自分で適当なデータを作ったバージョン。
dfは data frame の略です。分析でよく見るやーつ。

`df$mike` で列指定してます。よく解らんけど他の列には `kijitora` とか `kuro` とかあるんじゃないですかね。

`hist()` がヒストグラム図を描画する関数ですね。
基本これにデータ打ち込めば図が出来る。お手軽。なお動作も軽い。すばらしい。

## 事前データ整理
kaggleのときから思ってたけど、実際にコード書く前の分析データ整理のほうが何倍も何倍も時間かかるしだいたい8割ここに時間吸われるって言っても過言じゃない。
ここがきちんとできたらもう全部終わったくらいの気持ち。

分析手法が〜解析方法が〜とかそんなことより先にやることがある。
コード書くなんて最後の最後よ。
あと普通に統計学いるなって思いました。単位修めたの遥か彼方。勉強しよ。

## ところで……
お気付きだろうか。
「解析」と「分析」の2単語が出ていることに。
表記揺れとか誤字ではないです。

### 分析
「物事を分類して細かな要素に分け、その性質や構造を明らかにすること」（広辞苑より）

### 解析
「ある事象を研究（探求）するのに理論的なアプローチがある場合」（広辞苑より）

#### データ分析によって収集したデータを分類し、データ解析によってそのデータ結果の原因を論理的に明らかにする
……という流れなんですねー。改めて調べたらそんな違いがあることにびっくりだよ。

# 最後に
分析入門とはタイトル詐欺の内容ですが、そもそもここ突っ込んで書いてる方が少ないので基礎の基礎の基礎というつもりで書きました。
ちゃんとした入門は他の記事や本を調べてね！！

明日の[ CYBIRD Advent Calendar 2024 ](https://qiita.com/advent-calendar/2024/cybird) 18日目は、 @CR_ さんの記事です。
お楽しみに！
VBAデバック方法（最強）

## なぜデバック方法の記録を残すのか。
・しばらくVBAを触らないかもしれないので。
・みなさんのVBA開発画面を見ていて自分のデバック画面と違ったので。

## 説明
まず写真。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3882753/e4ce2c3e-f34f-bae3-98d2-14f862c97784.png)

### ローカルウィンドウ
変数・配列の中身がまるわかりです。
絶対いる。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3882753/ea4db33a-fe85-4447-2a82-bc73c2928163.png)




ここから出します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3882753/9dd51565-b1f7-a99a-4a68-aed946297671.png)


## ステップ実行
絶対いる。変数・配列の中身を一行ずつチェックするため。
プログラムの中にカーソルをおいて、F8キーで実行。
F8を押すたびに一行ずつ実行されていきます。
ローカルウィンドウと併用することで最強になる。


## 選択範囲をすべてコメントアウトするやつ
絶対いる。プログラムをコメントアウトして停止させるため必須

https://vba-labo.rs-techdev.com/archives/64

## 選択範囲のインデントを一度にズラするやつ
絶対いる。後からFor文など足すときに必須

https://club-vba.tokyo/vba-indent/
LightGBMとXGBoostの違いを徹底解説！どちらを選ぶべきか？

機械学習における勾配ブースティングアルゴリズムの代表的なライブラリである**LightGBM**と**XGBoost**。どちらも多くのタスクで使われていますが、それぞれに特徴や得意分野があります。本記事では、両者の違いを分かりやすく解説し、どちらを選べば良いかについて考察します。
※この記事は、ChatGPTの出力を基に作成しています。

---

### **1. 基本的なアルゴリズムの違い**

#### **XGBoost**
XGBoostは、勾配ブースティング決定木（GBDT）を効率的に実装したライブラリです。ツリー構築の際、**「レベルごとの分割（Depth-wise Growth）」**を採用しており、ツリー全体の深さを均一に保ちながら成長します。このアプローチは**過剰適合を抑える**という利点がありますが、計算量が多くなる場合もあります。

#### **LightGBM**
LightGBMは、同じくGBDTをベースにしていますが、ツリー構築では**「葉ごとの分割（Leaf-wise Growth）」**を採用しています。この方法では、勾配が大きい（重要な）葉を優先的に分割するため、計算効率が非常に高くなり、大規模データにも適しています。しかし、このアプローチは**過剰適合のリスク**があるため、正則化やハイパーパラメータ調整が必要です。

---

### **2. パフォーマンスの違い**

#### **速度とメモリ効率**
- **XGBoost**: 効率的な計算を行うため高速ですが、LightGBMほどの計算速度やメモリ効率はありません。
- **LightGBM**: ヒストグラムベースの学習を採用しており、データをバケットに分割することで高速化とメモリ消費の削減を実現しています。特に大規模データや高次元データにおいて優位性を発揮します。

#### **大規模データ対応**
- **XGBoost**: 分散計算に対応しており、大規模データにも使用可能です。ただし、LightGBMほど高速ではありません。
- **LightGBM**: 計算効率の良さから、大規模データでの学習や推論で優れた性能を発揮します。

---

### **3. データの前処理**

- **XGBoost**: 欠損値を自動処理しますが、カテゴリ変数を直接扱うことはできません。そのため、カテゴリ変数を利用する場合は、事前にOne-Hot Encodingなどのエンコーディングが必要です。
- **LightGBM**: カテゴリ変数を直接処理できるため、エンコーディングの手間を省けます。これにより、前処理の簡略化が可能です。

---

### **4. ハイパーパラメータ調整のしやすさ**

- **XGBoost**: パラメータが多いため、チューニングには時間がかかることがあります。ただし、デフォルト設定でも比較的安定した性能を発揮します。
- **LightGBM**: チューニングすべきパラメータが比較的少なく、初期設定でも高い精度を発揮しやすいです。

---

### **5. 過剰適合のリスク**

- **XGBoost**: レベルごとの成長を採用しているため、過剰適合しにくい構造になっています。
- **LightGBM**: 葉ごとの成長は効率的ですが、重要な分岐を優先的に学習するため、過剰適合しやすい側面があります。このため、正則化パラメータ（例: `max_depth`や`min_child_samples`）を慎重に設定する必要があります。

---

### **LightGBMとXGBoostの違いをまとめた比較表**

| **特徴**             | **XGBoost**                   | **LightGBM**                  |
|----------------------|-------------------------------|--------------------------------|
| **アルゴリズム**       | レベルごとの分割（深さ均一）     | 葉ごとの分割（重要な葉を優先） |
| **速度**              | 高速                          | 非常に高速                     |
| **メモリ効率**         | 良い                          | 非常に良い                     |
| **データ前処理**       | カテゴリ変数のエンコーディング必要 | カテゴリ変数を直接処理可能       |
| **大規模データ対応**   | 対応可能                      | 非常に優れている               |
| **過剰適合**           | 起こりにくい                  | 起こりやすい（正則化が必要）    |

---

### **どちらを選ぶべきか？**

選択肢は、タスクやデータセットの特性に応じて決まります。

- **LightGBMを選ぶべき場合**
  - データが非常に大規模である（数百万行やそれ以上）。
  - 高次元データを扱う。
  - カテゴリ変数を多く含むデータを効率よく処理したい。
  - 学習速度を最優先に考える。

- **XGBoostを選ぶべき場合**
  - 過剰適合を防ぎたい。
  - データサイズが中規模で、計算効率よりもモデルの安定性を重視する。
  - パラメータチューニングに十分な時間が取れる。

---

### **まとめ**

LightGBMとXGBoostはいずれも非常に優れたライブラリであり、どちらを選ぶかはケースバイケースです。一般的には、大規模データセットで効率性が求められる場合はLightGBM、安定性や過剰適合のリスクが懸念される場合はXGBoostを使用するのが適しています。

適切なライブラリを選び、パラメータチューニングを行うことで、どちらを使っても高いパフォーマンスを発揮できるでしょう！
メタデータをカスタムできる

>## Aliasing エイリアスを定義できたり、内蔵のエイリアスを定義できます
### describeとcontextはexample_groupのための初期エイリアスです。
>describe and context are the default aliases for example_group. 

>### あなたはexample_groupのエイリアスを定義でき、それらカスタムエイリアスに初期メタデータを与える
>You can define your own aliases for example_group and give those custom aliases default metadata.

>### Rspecは少ない内蔵のエイリアスを供給します
>RSpec provides a few built-in aliases:

```
#### xdescribeとxcontextはexampleを不可にするためにskipメタデータをexample groupに加える
>* `xdescribe` and `xcontext` add `:skip` metadata to the example group in
  order to temporarily disable the examples.

#### fdescribeとfcontextは一時的にexample groupに焦点を合わせやすくさせるために:focusメタデータをexample groupに加える(`config.filter_run :focus`と繋げる時）
* `fdescribe` and `fcontext` add `:focus` metadata to the example group in
  order to make it easy to temporarily focus the example group (when
  combined with `config.filter_run :focus`.)
````
## メタデータでexample groupエイリアスをカスタムする
>### Custom example group aliases with metadata

>Given a file named “nestedexamplegroupaliasesspec.rb” with:
```rb
RSpec.configure do |c|
  c.alias_example_group_to :detail, :detailed => true
end

RSpec.detail "a detail" do
  it "can do some less important stuff" do
  end
end

RSpec.describe "a thing" do
  describe "in broad strokes" do
    it "can do things" do
    end
  end

  detail "something less important" do
    it "can do an unimportant thing" do
    end
  end
end
```
>When I run rspec nested_example_group_aliases_spec.rb --tag detailed -fdoc
>
>Then the output should contain:

```
a detail
  can do some less important stuff

a thing
  something less important
```  

https://rspec.info/features/3-13/rspec-core/example-groups/aliasing/
 
>### alias_example_group_to(new_name, *args)

>#### expose_dsl_globallyがtrueに設定されているならば定義されたエイリアスはトップレベルにも追加される
>Note: The defined aliased will also be added to the top level (e.g. main and from within modules) if expose_dsl_globally is set to true.

>#### 供給されたメタデータを使ってexample groupを定義するメソッドを作成できる。exampleのグループ/メタデータショートカットを定義することが可能
>Creates a method that defines an example group with the provided metadata. Can be used to define example group/metadata shortcuts.

Examples:
```rb
RSpec.configure do |config|
  config.alias_example_group_to :describe_model, :type => :model
end
```
https://rspec.info/documentation/3.2/rspec-core/RSpec/Core/Configuration.html#alias_example_group_to-instance_method:~:text=%5B%5D-,%2D%20(void)%20alias_example_group_to(new_name%2C%20*args),.alias_example_group_to%20%3Adescribe_model%2C%20%3Atype%20%3D%3E%20%3Amodel%0Aend,-shared_context_for%20%22model
フロントエンドのビルドっていったいなんぞ？？

## はじめに

フロントエンドの開発では、`npm run dev` を実行すると、開発環境としてブラウザに表示されますよね。

でもpackage.jsonを見ると、`npm run build` っていうスクリプトも定義されてますよね。

これは一体なんでしょうか？

本記事ではビルドとはなんぞやという話から、ビルドして作られた成果物たちはどう使われているのかまとめていきます。

## ビルド is 何？

ビルドとは、開発中のコード（例: .vueファイル）を、ブラウザが理解できる形式（HTML, CSS, JavaScript）に変換するプロセスを指します。

ちょっと難しく聞こえるかもしれませんが、簡単に言えば「ブラウザで動くJavaScriptやCSSファイルに変換してくれる作業」です。

web開発にてビルドという言葉はよく使われますが、フロントエンドの領域においては先のような意味合いになります。

### ブラウザが読み込めるのはHTML、CSS、JavaScript
では、なぜビルドは必要なのでしょうか？
そもそもですが、vueファイルはそのままブラウザで読み込まれているわけではありません。

ブラウザは基本的にHTML、CSS、JavaScriptという形式のファイルしか読み込めないため、これらに変換が必要になります。

.vueファイルにはテンプレートやスタイル、スクリプトといったさまざまな情報がまとまっていますが、これらをJavaScriptやCSSに変換するのが「ビルドツール」と呼ばれるツールの役割です。

![スクリーンショット 2024-12-12 18.23.56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/697823/4eb223f4-1a11-5c50-0267-43af70df95d2.png)



vueファイルをJavaScript, cssに変換する以外にも、例えば以下のような処理もビルドで行っています↓

- **コードの変換**: .vue や .ts ファイルを、ブラウザで動作する .js や .css に変換

- **コードの最適化**: ファイルサイズを削減し、読み込み速度を向上
- **ブラウザ互換性の確保**: 古いブラウザでも動作するよう、コードを変換（例: ES6 を ES5 に）

そしてビルド時に作成された成果物は最終的には、本番環境へとデプロイされ、実際にユーザーが操作することになります。


## デベロッパーツールで違いを見てみる

npm run devを実行した時、buildを実行した時では、ブラウザに表示している違いは何か見てみます。

まずは開発環境を立ち上げてみます。

ブラウザのデベロッパーツールを見てみると、bodyタグ内にscriptタグがあり、そこからmain.tsを読みこんでいることがわかります。

![Screenshot 2024-12-11 at 23.42.22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/697823/b0c2aaf5-fc6b-04c9-ff5c-eb510e9cd286.png)


それではビルドしてみましょう。
ビルドを実行すると、特に指定がなければ dist ディレクトリが出来上がっています。

![Screenshot 2024-12-11 at 23.43.13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/697823/9501bd51-226d-7bf4-5678-ef2b8022080c.png)

viteのpreviewモードで表示してみると、
先程と同じような見た目でブラウザに表示されていることがわかります。

![Screenshot 2024-12-11 at 23.45.31.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/697823/fabf1298-0cbd-68d6-6fbc-b1a0526db153.png)

しかし、先ほどまでは main.ts を読み込んでいましたが、
`assets/index-aNVf...js` というファイルを読み込むようになっています。

先ほどのdistフォルダを見てみると、同様のjsファイルが入っていることがわかります。

![Screenshot 2024-12-11 at 23.43.13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/697823/9501bd51-226d-7bf4-5678-ef2b8022080c.png)

今回は `vite preview` で表示しましたが、
例えばvercelのserveのような、httpサーバーを立てられるライブラリを使ってビルドしたファイルを公開してみても同じように表示することができます。

https://github.com/vercel/serve

# 最後に

ビルドは、開発中のコードをブラウザが理解できる形式に変換し、最適化する重要なプロセスです。本記事では、npm run dev と npm run build の違い、そしてビルドによって生成された成果物がどのように利用されるのか、ブラウザに表示されているhtmlを例に解説しました。

ビルドしたファイルは本番環境へのデプロイに限らず、CI環境でのテストにも応用できます。
例えばPlaywrightとmswを組み合わせれば、APIのレスポンスがエラーコードだった場合にどのように表示されるかなど、より本番環境に近い状態でテストすることもできます。

開発環境で動作するVue3のようなフレームワークが、本番環境でユーザーに提供されるまでの流れを理解する参考になれば幸いです！

# 参考

https://medium.com/@trevorpoppen/modern-front-end-the-tools-and-build-process-explained-36641b5c1a53
ローカルでAWS SDKを使用してMinioの操作するときに気をつけること

AWS SDKをローカル開発環境で使用する際に、本番のAWSサービスの代わりにMinioを使用するケースについての説明です。

Minioは、S3互換のオブジェクトストレージを提供するオープンソースソフトウェアで、開発やテスト目的で使用されます。

# :seedling:環境

**Docker-Compose内に、同一ネットワーク上で以下のコンテナーを構築しています：**

**• minioコンテナー（http://minio:9999 - アップロード時のエンドポイント）
• nodejsコンテナー（http://nodejs:3000）**

**目標：nodejsコンテナーからminioコンテナーへのファイルアップロード**


上記の時、ローカル開発環境で連携時に設定パラメータの誤りによって頻繁に生じるエラーとその対処方法の記録。

# 本題
通常のS3操作では、以下の基本パラメータでS3Clientを生成するだけで十分です：

```jsx
import {S3Client,PutObjectCommand} from '@aws-sdk/client-s3';

new S3Client({
    credentials:{
      accessKeyId: process.env.AWS_ACCESS_KEY_ID,
      secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY
    },
    region: process.env.AWS_REGION,
    version: process.env.AWS_S3_VERSION
})
```

しかし、ローカル環境のMinioに接続する場合は、カスタムエンドポイントの指定が必要です。

```jsx
return new S3Client({
    endpoint: 'http://minio:9999',//ここ
    forcePathStyle: true,//ここ
    credentials:{
        accessKeyId: process.env.AWS_ACCESS_KEY_ID,
        secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY
    },
    region: process.env.AWS_REGION,
    version: process.env.AWS_S3_VERSION
})
```

# 大事なパラメータ
endpointの指定を忘れると、「AWSにそのアクセスキーは存在しない」というエラーが表示されます（ローカル環境で実行しているため、当然AWSに記録されているはずがなく、アクセスキーが間違っていると思い込んで何度も修正してしまいがちです）

```jsx
InvalidAccessKeyId: The AWS Access Key Id you provided does not exist in our records.
```

なお、forcePathStyleの指定を忘れると、URLの形式がS3の仕様に従ってしまい、「見つからない」というエラーが発生します。MinioではURLのホスト名にバケット名を含める形式で指定する必要があります。

```jsx
Error: getaddrinfo ENOTFOUND my-bucket.minio
```

**endpoint**:`string | Endpoint | Provider<Endpoint> | EndpointV2 | Provider<EndpointV2>`

カスタムエンドポイントは、S3のローカルバージョンを使用する場合などの特別な場合にのみ使用します。

S3のホスト名へのバケット名適用などのエンドポイント変換機能は、このカスタムエンドポイントでも利用可能です。

**forcePathStyle**:`boolean`

S3 オブジェクトのURLパス形式を強制的に変更するかどうかを指定するオプションです。

`https://s3.amazonaws.com/<bucketName>/<key>` 

↓

`https://<bucketName>.s3.amazonaws.com/<key>`

trueに設定すると、URLのホスト名部分にバケット名が含まれる形式となります。

# おまけ

以前にPHPでも同様のエラーが発生しました（~~学習していない~~）ので、参考として記録しています。

```php
use Aws\S3\S3Client;

return new S3Client([
    'endpoint' => "http://minio:9999",
    'use_path_style_endpoint' => true,
    'credentials' => [
        'key' => config('filesystems.disks.s3.key'),
        'secret' => config('filesystems.disks.s3.secret'),
    ],
    'region' => config('filesystems.disks.s3.region'),
    'version' => 'latest'
]);
```

# 参考

AWS SDK for JavaScript v3 https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/Package/-aws-sdk-client-s3/Interface/S3ClientConfig/
MongoDB Community Edition を Ubuntu にインストール

# 環境
- Ubuntu24.04
- MongoDB 8.0 Community Edition

# 手順
MongoDB Community Edition を Ubuntu にインストール
https://www.mongodb.com/ja-jp/docs/manual/tutorial/install-mongodb-on-ubuntu/

上記の手順を参照して、インストール

# その他

起動
```console
sudo systemctl start mongod
```

起動確認
```console
sudo systemctl status mongod
```

停止
```console
sudo systemctl stop mongod
```

バージョン確認
```console
$ mongosh -version
2.3.4
```
ログ確認
```console
$ less /var/log/mongodb/mongod.log
```
MongoDBに接続
```console
$ mongosh
```
総括と補足

# 第25回：総括と展望

## 総括

### フレームワーク構成の全体像

1. **基盤レイヤー**
   - ohama: 横断的関心事の実装基盤
   - cusinart: 分散環境ランタイム
   - gennethleia-core: コアフレームワーク
   - gennethleia-app: アプリケーションフレームワーク

2. **機能レイヤー**
   - loquat: シェル環境
   - minerua: AIスキル環境
   - reale: GUI/OS環境

3. **横断的な機能**
   - モナドベースの関心事分離
   - Erlang型のホットリロード
   - BDDスタイルのテスティング

### 設計思想の要点

1. **分散処理の透過性**
   - cusinartによる分散環境の隠蔽
   - 利用者は分散環境を意識しない設計
   - スケーラブルな処理の実現

2. **横断的関心事の管理**
   - ohamaによるパターン化された実装
   - デザインパターンのフレームワーク化
   - 関心事の明確な分離

3. **環境抽象化**
   - gennethleia-coreによるno_std/std環境の抽象化
   - プラットフォーム非依存のコア機能
   - 再利用可能なロジックの集約

4. **アプリケーション構造化**
   - gennethleia-appによるアプリケーション層の抽象化
   - ビジネスロジックの分離
   - プラグインベースの拡張性

### 主要な実装パターン

1. **デザインパターン**
   ```rust
   // ohamaによるパターン実装
   pub trait Pattern: Send + Sync {
       fn apply<T: ApplyPattern>(&self, target: T) -> Result<T>;
   }

   // パターンの自動適用
   #[pattern(log_trace)]
   fn process_data(data: &str) -> Result<String> {
       // ビジネスロジック
   }
   ```

2. **分散処理**
   ```rust
   // cusinartによる透過的な分散処理
   pub struct DistributedOperation<T> {
       operation: T,
       node_selector: NodeSelector,
   }

   impl<T: Operation> DistributedOperation<T> {
       async fn execute(&self) -> Result<T::Output> {
           let node = self.node_selector.select_node()?;
           node.execute_remote(self.operation).await
       }
   }
   ```

3. **環境抽象化**
   ```rust
   // gennethleia-coreによる環境抽象化
   pub trait PlatformService {
       fn allocate(&self, size: usize) -> Result<*mut u8>;
       fn get_system_time(&self) -> Result<u64>;
   }

   #[cfg(not(feature = "std"))]
   pub struct NoStdPlatform;
   #[cfg(feature = "std")]
   pub struct StdPlatform;
   ```

### 拡張機能の統合

1. **AIスキル統合（minerua）**
   - モデル実行環境の統合
   - スキルチェーンの実装
   - 分散学習の支援

2. **GUI/OS機能（reale）**
   - クロスプラットフォームGUI
   - ウィジェット体系
   - イベント処理システム

3. **シェル環境（loquat）**
   - インテリジェントなコマンド補完
   - スクリプティング機能
   - プラグインベースの拡張

## 改訂内容の概要

### 主な変更点

1. **cusinartの中心化**
   - すべてのコンポーネントがcusinartランタイム上で動作
   - 非同期処理の統一的な実装
   - ランタイムベースの機能統合

2. **WASIベースの実行環境**
   - WASI環境を標準的な実行環境として位置づけ
   - クロスプラットフォーム対応の簡素化
   - コンポーネントモデルの活用

3. **API抽象化の再構成**
   - gennethleia-apiの導入
   - プラットフォームAPIの統一的な抽象化
   - SDKの互換性レイヤーの提供

### アーキテクチャの変更

```rust
// 改訂後の基本構造
pub struct NextGenSystem {
    runtime: Arc<cusinart::Runtime>,  // 中心的なランタイム
    core: gennethleia_core::CoreRuntime,  // WASI対応の基盤
    api: gennethleia_api::ApiLayer,   // 新しいAPI抽象化
    // その他のコンポーネント
}
```
地図上にリアルタイムにデータを表示したい（HERE Maps API）

# はじめに

地図上にリアルタイムにデータを表示したい！！
この時にHERE Maps API for JavaScriptにて達成できそうなのかを調査した。

#### 完成像
![Animation5.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283248/523e0493-0c39-2ea5-3f2e-ac2506972218.gif)

[リアルタイム・ジオインフォマティクス（HERE Maps API と 時系列データCLOUDSHIP API を使って、地図上にリアルタイムデータ表示）](https://qiita.com/TAKI_RYU/items/d6af7916fe76af2a0861)


# 1章：調査 🔍
## Q1.地図上に吹き出しを出すことができるか

地図上に任意のオブジェクトを表示する方法は３つ。

1.SVG marker　ー　SVG画像を表示する。
2.DOM marker　ー　HTML要素を表示する。
3.情報吹き出し　ー　マーカーをクリックすると表示ウィンドウが開く。

- 1.2については、マーカーそのものの型を変えて表示をする方法である。
【公式】Developer Guide: Add markers
https://www.here.com/docs/bundle/maps-api-for-javascript-developer-guide/page/topics/marker-objects.html

- 3については、マーカーをクリックすると開く吹き出しである。
【公式】Opening an infobubble
https://www.here.com/docs/ja-JP/bundle/open-infobubble/page/README.html

今回は表示する情報量が多めの想定なので、閉じたり開いたりできる、
__3.情報吹き出し__ を採択した。

## Q2.地図上に変化するデータを動的に表示できるのか
カクカクしたりチラついたりはしないのか？

![q22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283248/c0ee9800-a461-bb18-1063-4e3805dbaa68.png)
時計を表示したところシームレスに動くように表示された。

## Q3.細かなレイアウト調整をできるのか
下記の「City」や「Liverpool」の吹き出し型のレイアウトが素のデザイン。
![q32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283248/83567fc3-53f2-dd6c-df50-869d46e3eed2.png)

自分でコントロールしたい場合CSSで強制的に上書き調整できることを確認した。
```css
/* HERE内のCSS定義を上書きする */
.H_ib_body {
  background: rgba(255, 255, 255, 0) !important;
  box-shadow: 0px 0 0px 0 rgba(255, 255, 255, 0) !important;
}
```

# ちょっと難しかったところ

## Q4.吹き出し（infoBubble）を最初から開きたい

Stateの概念があるため、
obj.Marker.setState("OPEN")のようなコードで解決できるかと思いきや効かない。
infobubbleオブジェクトもCLOSE後にはundefinedになってしまう。
マップ上の全てのマーカーを取得できたので、このようにforEach文でグループ全てに対しtapイベントを発行することで対応した。
```js
  group.forEach((obj, i) => {
    obj.dispatchEvent("tap");
  });
```

## Q5.吹き出し（infoBubble）を閉じて開いた後に、数値がHTMLに代入されなくなってしまう。

開発者ツールで覗いてみると閉じた後にinfobubbleのHTML要素が残留していることがわかった。
残留していることにより、新しく生成した要素の数値が書き換わらない。
なので、削除コードを入れておくことで解決した。
```js
        bubble.addEventListener("statechange", async (evt) => {
          // 閉じた時の動作
          if (evt.target.getState() === H.ui.InfoBubble.State.CLOSED) {
            // Interval CSAPI取得処理定期実行を停止する。
            clearTimeout(intervalId);
            ui.removeBubble(bubble);
          }
        });
```

# 完成
時間経過でセンサーから数値が入ってくれば自動で画面が更新されるようになりました。
![Animation5.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283248/523e0493-0c39-2ea5-3f2e-ac2506972218.gif)

余談
Altキーで地図をグリグリ３Ｄに動かせるのカッコ良い。


# お役立ちリンク集

【公式】Developer Guide: Add markers
https://www.here.com/docs/bundle/maps-api-for-javascript-developer-guide/page/topics/marker-objects.html
【公式】Maps API for JavaScript の例
https://www.here.com/docs/ja-JP/category/here-sdk-for-js-examples

完成しました
[リアルタイム・ジオインフォマティクス（HERE Maps API と 時系列データCLOUDSHIP API を使って、地図上にリアルタイムデータ表示）](https://qiita.com/TAKI_RYU/items/d6af7916fe76af2a0861)
NFSサーバーをdockerで構築する

DockerのVolumeとしてNFSをマウントすることもできますし、自サーバや外部サーバからアクセスすることも可能です。

https://docs.docker.com/storage/volumes/#create-a-service-which-creates-an-nfs-volume

NFSサーバーDockerで構築してみる。Intel, AMD, ARMチップでも対応可能なものは流石に少ない。

## GitHubを探索

**参考にしたページと同じく`Google Cloud Platform`のリポジトリ内に存在**することを確認

https://github.com/GoogleCloudPlatform/nfs-server-docker

## docker-composeの作成

上記リポジトリの`1/debian9/1.3/`ディレクトリに`Dockerfile`と`docker-entrypoint.sh`があります。
このまま使ってもいいですが、ベースイメージが古そうなのと、NFSのバージョンが固定だったので、`Dockerfile`を変更。`compose.yml`として、そのまま利用する。

```Dockerfile:Dockerfile
# Copyright 2016 The Kubernetes Authors.
# Copyright 2018 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

# FROM gcr.io/google-appengine/debian9
FROM debian:bullseye-slim

ENV NFS_VERSION 1:1.3.4-2.1

ENV C2D_RELEASE 1.3.4

RUN set -x && \
    apt-get update && apt-get install -qq -y nfs-kernel-server && \
    rm -rf /var/lib/apt/lists/* && \
    mkdir /exports

COPY docker-entrypoint.sh /usr/local/bin/
RUN chmod +rx /usr/local/bin/docker-entrypoint.sh

VOLUME /exports

EXPOSE 2049/tcp
EXPOSE 20048/tcp

ENTRYPOINT ["/usr/local/bin/docker-entrypoint.sh"]
CMD ["/exports"]
```

```yaml:compose.yml

services:
  nfs-server:
    build:
      context: .
      dockerfile: Dockerfile
    environment:
      TZ: '=JST-9'
      USERID: 1001
      GROUPID: 1001
    volumes:
      - ./exports:/exports
    privileged: true
    restart: always
    ports: 
      - "2049:2049"
      - "20048:20048"
```

## 起動

```shell
docker-compose up -d
```

これでNFSサーバーが起動します。

## 例１：NFSサーバーをマウントする

NFSサーバーを使う側は`volumes`をこのように指定。`device`の指定はNFSサーバーのルートから見たディレクトリの位置です。

```yaml
volumes:
  nfs-server:
    driver_opts:
      type: nfs
      o: "port=2049,addr=XX.XX.XX.XX,rw,nfsvers=4"
      device: ":/"
```

## 例２：NFSサーバーを外部サーバからマウントする

NFSサーバーを使うクライアント側は以下のように指定。ポート開放をお忘れなく。「XX.XX.XX.XX」はDockerサーバのIPアドレス

```file:/etc/fstab
XX.XX.XX.XX:/    /mnt/XXXXX  nfs   rw  0

```
[CAIレシピ] 終了ステップによるHTTPレスポンスコード/ヘッダーの設定

## はじめに

通常、終了ステップはHTTPレスポンスコードとしてHTTP 200を返して終了します。終了ステップのプロパティを変更することで、次の設定が可能です。

- 任意のHTTPレスポンスコードの指定
- 任意のHTTPレスポンスヘッダーの指定

これらの設定を行うことにより、出力フィールドによるHTTPレスポンスボディ以外での応答結果の表現が可能となり、より柔軟にCAIプロセスを実装できます。

なお、この記事は次の記事の内容を理解していることを前提としています。

- [はじめてCAIを使う際に](https://qiita.com/shunsuzu/private/12b8dbd08a30efa0003a)
- [プロセスの作成と実行(匿名認証と基本認証)](https://qiita.com/shunsuzu/private/01d91caedb92bd7781ea)

## 終了ステップによるHTTPレスポンスコード/ヘッダーの設定

### CAIプロセスの作成
次の手順では、任意のHTTPレスポンスコード/ヘッダーを返すCAIプロセスを作成しています。

1. CAIプロセスを次の設定で作成します。
    - 名前を __recipe-pca-stepEnd__ とする
    - __匿名アクセス__ を許可する
    - __クラウドサーバー__ にデプロイする

1. 終了ステップを選択して次のように設定します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074553/fd7efcda-66a1-96ce-d2fe-937bb790cd3e.png)

なお、今回は開始/終了ステップのみでCAIプロセスを実装していますが、実際のシステム開発では[ディシジョンステップ](https://qiita.com/shunsuzu/private/cf69000890ccdfd1d42f)を使って条件別にHTTP 200以外のレスポンスコードやヘッダーを返すように実装します。

### CAIプロセスの実行

以下、curlコマンドを例とした動作確認結果です。curlの __--head__ オプションを指定することで、HTTPリクエスト実行時のレスポンスヘッダーより指定したHTTPレスポンスコード/ヘッダーが確認できます。

```:curlコマンドと実行結果
// curl コマンド
curl --head https://<IICS・CAIサーバー>/active-bpel/public/rt/<Org ID>/recipe-pca-stepEnd

// 実行結果
HTTP/2 505 <--- ★★★指定したHTTPレスポンスコード★★★
date: Thu, 12 Dec 2024 22:04:59 GMT
content-type: application/json;charset=utf-8
cache-control: private
referrer-policy: strict-origin-when-cross-origin
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
strict-transport-security: max-age=31536000; includeSubDomains; preload
x-frame-options: SAMEORIGIN
xxx-header1: headerTest <--- ★★★指定したHTTPレスポンスヘッダー★★★
x-http-status: 505
x-instanceid: 1051983032577794048
vary: accept-encoding
x-envoy-upstream-service-time: 35
server: istio-envoy
```

## 参照

- [Qiita - IICS CAIの実装レシピ - マスターページ](https://qiita.com/shunsuzu/private/3d1971ef6e3b993516aa)
WinActor 10周年記念イベントで聴講した話

このブログは「RPA Advent Calendar 2024」の **10日目** の記事です。

[≫ 昨日の記事はこちら](https://qiita.com/advent-calendar/2024/rpa "公開されたらリンクします")

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

[≫ 明日の記事はこちら](https://qiita.com/advent-calendar/2024/rpa "公開されたらリンクします")
# 10周年記念イベントにお邪魔しました😁
2024年10月14日(木)に開催された
**WinActor 10th Anniversary Day 2024（東京）**
に行ってまいりました！

今回はRPACommunityのWinActor支部の主催としての参加でしたので、お休みをいただいての個人参加です✨<br>
▼ イベント詳細は以下のサイトをご覧いただければと思います。

https://winactor.biz/20241114_10thanniversaryday_tokyo.html

このブログでは、**講演会** の模様を主にお届けいたします。
# 講演内容について
講演内容はざっくりと以下の通りでした。

| 内容 | 登壇者 | タイトル |
|:---|:---|:---|
|開会挨拶|||
|著名人講演|茂木 健一郎 氏|AI時代に必要な脳力について|
|休憩|||
|ユーザー講演|株式会社池田理化|WinActorで進化する業務効率化：<br>3年間の成果と未来展望|
||パーソルテンプスタッフ株式会社|RPAを上手に進める秘訣は『人材配置』 "失敗を成功に変える" 新規開発・保守運用・人材育成のポイント|
||株式会社ビジネスブレイン太田昭和|PHOENIX 再起する力|
|閉会挨拶|||

ちなみに今回はWinActor開発のロードマップなどの情報はありませんでした。
しかし、10周年の歴史にしっかり向き合って、WinActorの活用について情報共有していく内容であったと思います。
## AI時代に必要な脳力について
最近のAI動向やご自身の著書に絡めて、有意義なお話が聞けました。<br>
まずはイーロン・マスクが政府効率化省の長官になる予定の件に絡めたお話。
政治にも流行があり、日本にも業務効率化の波が来るかもしれないのでは？という話は興味深かったです。
AIやRPAもですが、いろんなツールを使って**いかに業務効率化をしていくか**……これからの課題とチャンスが潜んでいることを、新たな視点で気付くことができました。<br>
また、注意力のお話も面白かったです。
AIと人間の共存のカギとなるのが、**何に注意を向けていくか**、が大切なのではというお話でした。定型作業がAIなどで自動化されてしまうと、作った自動化の処理をどう組み合わせるか？や新しいアイデアに気付くことにリソースを割いていくことが主流になっていくことが想像できます。
**今まで見てこなかった作業に注意を向けて選択していく**ことが、今後人間に必要となるスキルで、いかに選択の精度を鍛えていくかが課題になっていきそうです。<br>
最後に**生きがい**についてのお話も興味深かったです。
簡単に言うと、生きがいを指標化して自動化の可否を仕訳したほうがいいのではというお話でした。確かに、自動化できても人の生きがいを奪うような処理内容にしようとすると、担当者から反対にあうことがあるのはRPAでもよくあることです。
おそらく効率化は避けられないので、今後は自分の判断の物差しを変えていくことが大切なのかなと思います。ツールを自分の一部になるよう使いこなすことができれば、ツールとの関係性を向上させ、自己効力感や自律性を高めることができます。
それができれば**自身の生きがいをアップデート**させて、AIと人間の共存が可能になっていくのではないかと思いました。<br>
こちらの講演では、自分の考え方も新たに整理できて有意義なお話でした。
## WinActorで進化する業務効率化：3年間の成果と未来展望
株式会社池田理化 様の導入事例についてお話が聞けました。<br>
コロナ禍きっかけで業務見直しを行い、RPAを推進していったそうです。
体制としては、外部の会社に伴奏支援と研修を委託してユーザーを増やしたとのことでした。合わせて上層部への説明をしっかり行い、認知度の向上に努めたそうです。
RPAの作成は専任担当を作って一括集約で作っていき内製化に成功したそうです。ポイントは、① 専任担当者を置く、② 業務配分をする、③ 情シスとの連携、だそうです。
シナリオの実例紹介もありましたが、一番削減できたのはひたすらダウンロードする作業だそうです。確かに単純で大量にある作業は時間削減に効果があります！
各支店への展開は、当初の研修もそうですが、全社共通の処理でRPA化できたものを配布されたそうです。<br>
こちらの講演では、具体的な行動内容をお伺い出来て、非常に参考になりました。
## RPAを上手に進める秘訣は『人材配置』 "失敗を成功に変える" 新規開発・保守運用・人材育成のポイント
パーソルテンプスタッフ株式会社 様の事例についてお話が聞けました。<br>
RPAアソシエイツという、リスキリングで100時間/月で身につける研修で人材育成をしたお話が聞けました。
育成した後にどのように配置していくかが課題だったそうですが、① 現場目線でのヒアリング、② どんどん開発していく、③ RPAの認知を上げる、ことで内製化が進んだそうです。
また、メンテナンスが追いつかない場合や千人のメンバーが配置できない場合などもあったそうですが、人材を育成して適切に配置していくことで解決していったそうです。<br>
今後の人材不足が課題になる場面も出てくるので、適切な人材育成と配置は意識する必要が出てきそうです。
## PHOENIX 再起する力
株式会社ビジネスブレイン太田昭和 様の事例についてお話が聞けました。<br>
DXプロジェクト推進についてのお話がメインで、「再起する力」で定着するまで伴走する方法について聞くことができました。① 100人の１歩、② 1人の100歩、③ 魚の目、を心がけて推進していったそうです。<br>
やはり内製化が定着していくまでには時間がかかり、どうフォローして「再起」していくかで成功するかどうかが決まってくることが分かりました。
# まとめ
どなたのお話も勉強になる内容ばかりでした。<br>
あくまで一例なのでマネできそうなところは採用して、組織に合った施策を考えていきたいと感じました。<br>
また、さらにWinActorが活用されるシーンを増やせるよう、RPACommunityもイベントを継続していこうと思います！💪
qe,aenetのmake

まず、ohtakaのhomeにはいてください。windowsの場合は、Tera Termで登録してください。
```ruby:
cd ~
mkdir AENET
cd AENET
```
```ruby:
wget http://ann.atomistic.net/files/aenet-2.0.3.tar.bz2
```
```ruby:
tar jxvf aenet-2.0.3.tar.bz2
```
```ruby:
cd aenet-2.0.3
```
```ruby:
cd ..
cd lib
```
```ruby:
vi Makefile
```
Makefileの中身を変更
```ruby:
FC      = ifort -c
FCFLAGS = -O2

SHRLD    = gcc
SHRFLAGS = -fPIC
SHARED   = -shared
SHRLIB   = -lm -lgfortran

TAR       = tar
AR        = ar
ARFLAGS   = -crusv
```

```ruby:
:wq
```
保存する。コンパイルを実行します。
```ruby:
cd ../src
```
```ruby:
make -f makefiles/Makefile.ifort_intelmpi
```
```ruby:
cd ..
cd bin
ls
```
binファルダーにファイル（generate.x-2.0.3-ifort_intelmpi、predict.x-2.0.3-ifort_intelmpi、train.x-2.0.3-ifort_intelmpi）があるかを確認して
```ruby:
mv generate.x-2.0.3-ifort_intelmpi generate.x
```
```ruby:
mv predict.x-2.0.3-ifort_intelmpi predict.x
```
```ruby:
mv train.x-2.0.3-ifort_intelmpi train.x
```
aenetのmakeはokです。
次はqeのmake
```ruby:
cd ~
mkdir QE
cd QE
```
QE専用のファルダーを作成して、ダンロードする。
```ruby:
git clone https://github.com/QEF/q-e.git
```
```ruby:
cd q-e
```
```ruby:
module purge
```
```ruby:
module load intel_compiler/2020.4.304 intel_mpi/2020.4.304
```
```ruby:
./configure --enable-openmp --with-scalapack=intel
```
```ruby:
make all
```
```ruby:
cd bin
ls
```
pw.x pp.x neb.x といったファイルができたかを確認する。
これでソフトのインストールが全部完成。
「.S3key」と「asset:path」とは何か

## 今回起きたこと

cdkバージョンアップ対応のため「aws-cdk」と「aws-cdk-lib」を更新しました。
その後、cdk diffで差分を取ったところ下記のような差分が出ておりました。
初見の差分だったため、今回は「s3key」と「asset:path」について調べてみました。

```
Resources
[~] AWS::Lambda::Function Custom::ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
 ├─ [~] Code
 │   └─ [~] .S3Key:
 │       ├─ [-] XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.zip
 │       └─ [+] YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY.zip
 └─ [~] Metadata
     └─ [~] .aws:asset:path:
         ├─ [-] asset.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
         └─ [+] asset.YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
```

## 結論

CDKではビルド時にLambda のコード(アセット)のハッシュ値を計算して、差分の有無を判断している。
CDKのバージョンを変更すると、一部パッケージでアセットのハッシュ値計算方法が変わるため、差分が出てしまっていた。

## 調べてわかったこと

### .S3keyとは

Cloudformation(CDKも)からLambdaを作成する際にソースコードをテンプレート外に置く場合に使用。
zip形式であらかじめ、S3バケットに配置しておく。

- S3Bucket：S3のバケット名
- S3key：**S3バケット内でのオブジェクトのパス(暗号化鍵だと思っていた。。。)**

### asset:pathとは

assetとは、「本体のソースコードとは別にアプリで必要なもの」のこと。
assetpathとは、そのまま「アセットが格納されている場所のパス」のこと。

AWS CDK のアセットは以下の2種類がある

- ファイルアセット
  - JSONファイルやLambdaコード一式を含むディレクトリなど
- イメージアセット
  - DockerfileやDockerイメージのビルドに必要なファイル一式を含むディレクトリ

assetが格納される場所を「アセットストア」という。

- ファイルアセット
  - S3
- イメージアセット
  - ECR

## 参考

[[DevAx::connect番外編] CDK実践勉強会の資料およびQ&A公開](https://aws.amazon.com/jp/blogs/news/devaxconnect-cdk-study/)
[S3Key of bundled lambda asset changes on every run in Github Actions workflow](https://github.com/aws/aws-cdk/discussions/25410)
[CloudFormationでAWS Lambdaを作成・更新する際のベストプラクティス](https://qiita.com/kihoair/items/fe204fc8582946646d07)
[もっとじっくり AWS CDK のコンセプト](https://www.ogis-ri.co.jp/otc/hiroba/technical/cdk-concepts/part6.html)