OmniAICreator/Qiita-1.07M huggingface dataset:
Trends in Marketplace App Development to Keep an Eye on in 2024


The development of marketplace apps has completely changed how we purchase by providing a smooth and practical experience for both customers and companies. It's critical for businesses to keep ahead of the curve because the worldwide market is predicted to reach a valuation of over $1 trillion by 2025.

What Makes Marketplace Apps So Well-liked?

The popularity of marketplace apps can be attributed to a number of factors. They provide:

* Convenience: Use a single app to access a large selection of goods from several suppliers.

* Broad Selection: Products from many vendors are integrated, facilitating price comparison for customers.

* Inexpensive for Sellers: Without the overhead expenses of a physical store, independent sellers and small enterprises can access a larger market.

* Exposure: A chance for vendors to expand their clientele and visibility

* Simplified Logistics: Connected shipping and logistics solutions

* Community Building: Establishing groups for buyers and sellers that share similar interests

**2024 Trends to Keep an Eye on**

The following patterns will influence how marketplace apps develop in the future:

* More Tailored: Using AI and machine learning to create experiences that are tailored to each individual

* Social Commerce Integration: Enhancing the shopping experience through integration with social media platforms

* Sustainability Focus: Apps for marketplaces that prioritize sustainability will draw a devoted user base.

* Features of Augmented Reality (AR): AR-enabled interactive online purchasing

* Subscription Models: Providing subscription services for curated product boxes, premium content, or special prices

* Blockchain Technology Integration: Using blockchain technology to improve security and transparency

* Improved Payment Solution: Contactless and digital wallets are two safe and easy ways to make payments.

* Data-driven Insights: Making use of data analytics to enhance customer interaction and inform business choices

**Finally,**

The retail industry is changing due to the popularity of marketplace apps, which promise increased convenience, variety, and creativity for both customers and companies. Marketplace platforms may survive in an increasingly digital era by embracing difficulties, new technologies, and customisation.
IAMロールの信頼関係ポリシーに変なPrincipalが設定されています！

AWS上で稼働するITサービスの運用業務のなかで学んだこと。
本当にちょっとしたことですが。。。

# Question

IAMロールの信頼関係ポリシーを確認したところ、`Principal`のところに変なエンティティが設定されていた！！ ARN形式ではない、`AIDAY...`から始まる謎の文字列。 これは何？！

```json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
			"Principal": {
			    "AWS": [
			        "arn:aws:iam::000000000000:user/iamuser1",
			        "arn:aws:iam::000000000000:user/iamuser2",
			        "AIDAYJU7RR6ZO7TWXH4U2",
			        "AIDAYJU7RR6ZDEM2UHQIS"
			    ]
			},
            "Action": "sts:AssumeRole"
        }
    ]
}
```

# Answer

IAMエンティティ（IAMユーザー等）のID。

IAMロールの信頼関係ポリシーのJSONは管理画面上でこそ`Principal`をARN形式で表示しているが、内部的にはこのIAMエンティティのIDでもって管理している。
IAMエンティティが有効なうちはこのARN形式ーエンティティIDの間の相互変換が行われるため、画面上はARN形式で参照できる。
IAMエンティティが無効になるとこの相互変換ができなくなるのでエンティティIDがそのまま表示される。

:::note
IAMエンティティは過去に無効化（削除）されたものと同じ名称で作成することができる。このためもし信頼関係エンティティをIDではなくARNで管理していると、本来意図したユーザーと異なるユーザーがリソースにアクセスできてしまうリスクが生じる。このためIAMエンティティのID（≠ARN）による管理が行われている。
:::

公式リファレンスでこの問題が解説されている箇所は[こちら](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#principal-users)。
emとremの違いについて

Railsにて、拡大縮小機能をもつ表を作成している際に、一部文字サイズが変わらなかったときの備忘録です。

# 結論
| |  |
|---|---|
|em  | 親要素のサイズが基準となる |
|rem  | 最上位の親要素のサイズが基準となる |

# 内容

RailsのViewファイルにて、`<table>`を使用して次の表を作成していました。

![スクリーンショット 2024-12-12 145240.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3690695/b820adb2-ebde-bf38-2f1d-be2ed8d97521.png)


下記はそのコードの抜粋で、月の合計時間を最下行に表示します。


```rails:sample.html.erb
<style>
.total {
  font-size: 1.2rem; 
}
</style>

<table class="sample1">
    <tbody>
    <tr>#日にちと時間の表示
      <td>date</td>
      <td><%= @sample_time%></td>
    </tr>

    <tr class="total">#月の合計の表示
      <td>合計</td>
      <td><%= @month_total%></td>
    </tr>
    </tbody>
</table>
```

ここで問題となったのが、表の拡大縮小機能です。拡大すると当然文字も大きくなりますが、月の合計表示部分だけ文字サイズが変わりませんでした。

原因は、`class="total"`にて定義している`font-size: 1.2rem`の「rem」部分。rem(root em)だと、一番上の親要素、つまりhtmlのfont-sizeを基準にしているようで、tableのfont-sizeが変わろうとhtmlのfont-sizeに変更はないためここでの拡大縮小には影響されなったようです。ここで、remではなく「em」の場合、一つ上の親要素、つまり`<table class="sample1">`のfont-sizeが基準となるようです。

以下のように、rem→emに変更することで、拡大縮小時に、tableのfont-sizeに追随して文字サイズが変更されるようになりました。

```rails:sample.html.erb
<style>
.total {
  font-size: 1.2em; 
}
</style>
```
Linux rsyncコマンドの使い方

## rsyncコマンドとは
UNIX系システムでファイルやディレクトリを効率的に同期・転送するためのツールである。
ローカル間やリモート間でのデータ転送をサポートし、差分コピーを行うことで転送量を最小限に抑える。

## 使用例：VM間でデータを移行する場合
### rsyncコマンドリファレンス
<table>
  <thead>
    <tr>
      <th>オプション</th><th>説明</th>
    </tr>
  </thead>
  <tr>
    <td> -a </td> <td>アーカイブモード。転送元ディレクトリの内容(パーミッションや所有者)を維持したままコピーする。
</td>
  </tr>
  <tr>
    <td> -z </td> <td>ファイルを圧縮して転送する。ネットワーク越しの転送に便利である。</td>
  </tr>
  <tr>
    <td> -vv </td> <td>通常よりも詳細な情報を表示する。</td>
  </tr>
  <tr>
    <td> -P </td> <td>転送を中断したファイルを保持する。</td>
  </tr>
</table>

### 移行の流れ
#### 1. 準備
<summary>移行元と移行先のVMのリソース（CPU、メモリ、ストレージなど）を確認する。</summary><summary>
移行元VMのデータのバックアップを取る。</summary>

#### 2. データのエクスポート
<summary>データベースのデータをエクスポートする（例：MySQLデータベースの場合、mysqldumpコマンドを使用）。</summary>
<summary>必要なファイルやディレクトリをアーカイブする（例：tarコマンドを使用）。</summary>

#### 3. データの転送
<summary>エクスポートしたデータとアーカイブしたファイルを移行先のVMに転送する（例：scpやrsyncコマンドを使用）。</summary>

#### 4. データのインポート
<summary>移行先のVMでデータベースをインポートする（例：MySQLデータベースの場合、mysqlコマンドを使用）。</summary>
<summary>転送したファイルやディレクトリを解凍し、適切な場所に配置する。</summary>

#### 5. 設定の確認
<summary>移行先のVMで必要な設定（例：環境変数、設定ファイルなど）を確認し、必要に応じて調整する。</summary>

#### 6. テスト
<summary>データ移行が正しく行われたかどうかをテストする。特に、アプリケーションやサービスが正常に動作するかを確認する。</summary>

#### 7. 運用開始
<summary>問題がなければ、移行先のVMで本番環境として運用を開始する。</summary>


## 上記の「3. データの転送」でrsyncコマンドを使用する

### 実行コマンド
```ruby:bash
rsync -オプション 移行元 移行先
```
### 実行結果
```rb
zorf@mayeoijegh:/ghouse/su-data$ rsync -azvvP n073819@n073819-migratipn:/tmp/35621345_backup2.tar.gz .
opening connection using: ssh -l n073819 n073819-migratipn rsync --server --sender -vvlogDtprze.iLsfxC . /tmp/35621345_backup2.tar.gz  (10 args)
n073819@n073819-migratipn's password:
receiving incremental file list
delta-transmission enabled
35621345_backup2.tar.gz
  3,661,772,114 100%   51.05MB/s    0:01:08 (total: 100%) (xfr#1, to-chk=0/1)
total: matches=0  hash_hits=0  false_alarms=0 data=3661772114

sent 43 bytes  received 3,662,927,634 bytes  47,881,407.54 bytes/sec
total size is 3,661,772,114  speedup is 1.00
```
shared contextを含めて処理する

### shared contextを宣言、それをinclude_contextで含め、それを追加したブロック処理で拡張する
>### Declare a shared context, include it with include_context and extend it with an additional block
>Given a file named “sharedcontextexample.rb” with:
```rb
require "./shared_stuff.rb"

RSpec.describe "including shared context using 'include_context' and a block" do
  include_context "shared stuff" do
    let(:shared_let) { {'in_a' => 'block'} }
  end

  it "evaluates the block in the shared context" do
    expect(shared_let['in_a']).to eq('block')
  end
end
```
>When I run rspec shared_context_example.rb
>
>Then the examples should all pass.

* shared contextを含めて変数の書き換えを行なっている
* オーバーライドのようだ

### shared contextを宣言し、メタデータ(:shared_context => :metadata)でそれを含める
>### Declare a shared context and include it with metadata
>Given a file named “sharedcontextexample.rb” with:
```rb
require "./shared_stuff.rb"

RSpec.describe "group that includes a shared context using metadata", :include_shared => true do
  it "has access to methods defined in shared context" do
    expect(shared_method).to eq("it works")
  end

  it "has access to methods defined with let in shared context" do
    expect(shared_let['arbitrary']).to eq('object')
  end

  it "runs the before hooks defined in the shared context" do
    expect(@some_var).to be(:some_value)
  end

  it "accesses the subject defined in the shared context" do
    expect(subject).to eq('this is the subject')
  end

  group = self

  it "inherits metadata from the included context" do |ex|
    expect(group.metadata).to include(:shared_context => :metadata)
    expect(ex.metadata).to include(:shared_context => :metadata)
  end
end
```
>When I run rspec shared_context_example.rb
>
>Then the examples should all pass.

* :shared_context => :metadataを使ってshared contextを含めて使う

https://rspec.info/features/3-13/rspec-core/example-groups/shared-context/#:~:text=Then%20the%20examples%20should%20all%20pass.-,Declare%20a%20shared%20context%2C%20include%20it%20with%20include_context%20and%20extend%20it,Then%20the%20examples%20should%20all%20pass.,-Declare%20a%20shared%20context%20and%20include%20it%20with%20metadata%20of

# 感想
変数の書き換えはどういう時に使うのだろうか？
メタデータの使い方が理解できていない。
レガシーシステムから学べ！！

## はじめに
10年以上前から稼働しているレガシーシステムを通じて得られた実践的な教訓をまとめました。新規システムの設計時や、既存システム改善時の参考になれば幸いです。

## 設計・アーキテクチャ面での教訓

### 1. シンプルな設計は長く生きる
「かっこいい」アーキテクチャよりも「シンプル」な設計のほうが、長期的には保守性が高くなります。当時最新だった複雑なデザインパターンを採用したコードよりも、素直なCRUD処理のほうが10年後も問題なく動いているケースが多いです。

### 2. モジュール間の依存関係は最小に
密結合なモジュールは、小さな変更が思わぬ箇所に影響を及ぼします。特に、古いシステムでは依存関係を完全に把握できている人がいないことも。疎結合を心がけることで、変更の影響範囲を制御しやすくなります。

### 3. データ構造の変更は慎重に
テーブル設計やデータ構造の変更は、システムの寿命が長くなるほど大きな影響を及ぼします。特にマスターデータの構造は、開発初期の段階で十分な検討が必要です。

## 運用面での教訓

### 4. 運用手順の自動化は優先度高め
手作業による運用は、必ずヒューマンエラーを引き起こします。特に定期的なバッチ処理やデータメンテナンス作業は、可能な限り自動化することでリスクを低減できます。

### 5. ログ設計は運用を見据えて
「とりあえずログを出力しておけば大丈夫」は危険です。エラー発生時に原因特定できるログ、パフォーマンス分析に使えるログなど、運用フェーズでの使用目的を考慮したログ設計が重要です。

### 6. 定期的なメンテナンス時間の確保
システムが安定稼働していても、定期的なメンテナンス時間は必要です。パッチ適用、データクリーンアップ、パフォーマンスチューニングなど、システムの健全性を保つための作業時間を確保しましょう。

## 技術的負債への向き合い方

### 7. 小さな改善を継続的に
大規模なリファクタリングは、リスクとコストが高くなります。日々の保守開発の中で、少しずつ技術的負債を返していく方針のほうが現実的です。

### 8. テストコードは資産
テストコードがないレガシーシステムでは、ちょっとした修正も危険を伴います。新規開発時のテストコード整備は、将来の保守性を大きく左右します。

## ドキュメント管理の教訓

### 9. システムの全体像を示す図は更新必須
システム構成図、ER図、処理フロー図など、システム全体を示す重要な図は、変更の都度更新する習慣をつけましょう。数年後の保守開発で大きな価値を発揮します。

### 10. トラブルシューティングガイドの整備
過去に発生した重要な障害事例は、原因と対策を文書化しておきましょう。似たような障害が発生した際に、解決時間を大幅に短縮できます。

## まとめ
レガシーシステムは「負の遺産」ではなく「学びの宝庫」です。過去の意思決定から学び、より良いシステム作りに活かしていきましょう。

---
この記事へのコメント・指摘・追加事例などお待ちしております。
Scratch ライブラリ（BGM 管理）

# Scratch ライブラリ（BGM 管理）

## はじめに

Hi, there! 先日公開した [Attractive Drivers](https://scratch.mit.edu/projects/1092360558/) [(→記事)](https://qiita.com/Kray-G/items/2184362a8b85e06b7f8e) ですが、公開 1 か月で参照数 700 を突破し、800 に達する勢いです。ありがたいものです。最初に公開した [G14 Jerrydog](https://scratch.mit.edu/projects/1042567369/) [(→記事1)](https://qiita.com/Kray-G/items/9308c72311d642628509)/[(→記事2)](https://qiita.com/Kray-G/items/1ae34f9182d1736b7acf) は公開 1 週間程度で参照数が 100 にはなったものの、600 を超えたあたりから鈍り始め、先日ようやく 700 に達した形です。あっさり追い抜いていきました。

Attractive Drivers は SEGA の名作 OutRun へのオマージュとなっております。ぜひプレイしてみてください。

* **Attractive Drivers**

https://scratch.mit.edu/projects/1092360558/

> ドライブ中に聞ける曲数も 5 曲に増えたので、ぜひ聞いてみてください。完全オリジナル。割と全部気に入ってます。

# BGM 管理

さて、私の作っているプロジェクトでは常に使っている BGM 管理システムです。毎回同じなので、以前よりライブラリっぽくはなっていたのですが、今回改めてライブラリとしてシェアしました。

## プロジェクト

ここにあります。

https://scratch.mit.edu/projects/1098510080/

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/579271/92a51197-8d42-ec51-f5ab-75ab385581d1.png)

## ライブラリ概要

BGM を流すためのスプライトです。以下のような特徴があります。

* 曲をイントロとメインに分けて登録し、メインをループさせることも可能
* 各種メッセージを送ることで停止や再生が可能
* 曲を変える際、自動的に現在の曲をフェードアウトして次の曲に進む

## 使い方

### 基本

ほぼ全てのプロジェクトで使っているので、詳細は「中身を見る」で参照してみてください。

**① 使用したいBGMを用意します**

- 以下の命名規則に従ってサウンドに音楽を追加する
  - 曲名が「Name」の場合、曲名は「Name (Intro)」と「Name (Main)」にする必要があります。 「Name (Intro)」は、ドラムフィルインなどのイントロフレーズがある楽曲の場合のみ必要となります
  - 「Name (Main)」は曲のメインループです。ループさせる必要がある場合は、滑らかに曲の終わりと始まりがつながるようにしておきましょう

**② いくつかのリストに情報を設定します**

- 上記の「Name」のような曲名を「BGM Title」リストに追加します
- イントロフレーズが必要な場合は、「BGM Intro」リストに「1」を追加して「Name (Intro)」データを用意します。必要ない場合は、そのリストに 0 を追加します
- その音楽をループさせたい場合は、「BGM Loop」リストに 1 を追加します。不要な場合は 0 を付加してください
- リストのインデックス番号は音楽のトラック番号になります

**③ ゲーム内で音楽を再生します**

- イベント名「Track」+トラック番号を送信するだけで、曲が再生されます。最初の音楽の場合は「Track1」のようになります
  - 別のBGMの再生中にイベントを送信すると、現在のBGMがフェードアウトし、前のBGMが停止してから新しいBGMが始まります

## 各種情報

### 変数・リスト
> In: 他スプライト管理の値を参照／Out: 本スプライトで設定

| 変数名 | In/Out |        概要        |
| ------ | :----: | ------------------ |
| `BGM Auto Disk Repeat` | Out | 1: 最後の曲終了後、最初に戻る |
| `BGM Auto Track Repeat` | Out | 1: 現在のトラックをループさせる |
| `BGM Current Track` | Out | 現在のトラック番号 |
| `BGM Sound Volume` | In | 現在の音量 |

### イベント

|イベント名|操作|
|---|---|
|`BGM - Volume Up`|ボリュームを 1 上げる |
|`BGM - Volume Down`|ボリュームを 1 下げる|
|`BGM - Volume Set`|音量を `BGM Sound Volume` にする |
|`BGM - Track Infinite Loop On`|トラックのループを有効にする|
|`BGM - Track Infinite Loop Off`|トラックのループを無効にする|
|`BGM - Disk Repeat On`|ディスクのループを有効にする|
|`BGM - Disk Repeat Off`|ディスクのループを無効にする|
|`BGM - Prev Track`|前のトラックへ戻る|
|`BGM - Next Track`|次のトラックへ進む|
|`BGM - Pause`|ポーズ※|
|`BGM - Play`|ポーズの場合は再開させる、or 現在のトラックで曲を開始する|
|`BGM - Replay`|現在のトラックで曲を開始する|
|`BGM - Stop`|現在の曲を終了させる|

※ Scratch の仕様上、正確なポーズはできないため疑似的に再現。厳密には超ゆっくり進む状態となっている。

### コスチューム

特になし

---

ということで、BGM をならす時にはいつもこれを使ってます。もう少しシンプルにできそうなので、バージョン2を作るかもしれない。

---

> [Scratch ライブラリと Scratch Tips 目次へ戻る](https://qiita.com/Kray-G/items/e1900d5b6c6dcfbe5321/)
Power Apps での月初日 / 月末日の取得方法

ごきげんよう、百合宮桜です。
このブログは「RPA Advent Calendar 2024」の 14日目 の記事です。
業務改善だったらなんでも良いみたいなので、空気はスルーして、Power Apps の記事を書きます(≧▽≦)

他の皆さんの記事はこちら↓からよめますので、ぜひどうぞ！

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

皆さん、Power Apps の関数（Power Fx）って実は徐々に増えているのはご存じですか？
そして新しい関数がリリースされたことにより、より短く簡単な式で目的の値を取り出すことができるようになってきています(≧▽≦)
今回はその代表例である月初日 / 月末日の取得方法をお伝えします。


# 月初日の取得方法
2024年の初め頃に追加された EOMonth 関数を利用した方法です。
EOMonth 関数は指定した日時に、指定した月数を加算し、日にちを月末に移動します。
詳細は以下のドキュメントページをご覧ください。

https://learn.microsoft.com/ja-jp/power-platform/power-fx/reference/function-edate-eomonth

この EOMonth 関数と DateAdd 関数を利用すると、簡単に月初日が取得できます。

```
DateAdd(EOMonth(Today(),-1),1,TimeUnit.Days)
```

1. Today 関数で今日の日付を取得
2. EOMonth 関数で先月末（EX: 今日が12月13日なら、先月末は11月30日）の日にちを取得
3. DateAdd 関数で 2 で取得した日付に＋1日追加（EX: 11月30日を取得したら、1日追加で12月1日になる）

ちなみに EOMonth 関数が出る以前はどうやっていたかというと、こんな感じでした↓

```
DateAdd(
    DateAdd(
        Today(),
        -Day(Today())
    ),
    1,
    TimeUnit.Days
)
```

先月末の日付を出して、その翌日が今月1日という算出ロジックは今と同じですが、今よりもややこしく長い式でした💦

# 月末の取得方法

月末の取得方法はとてもシンプルです。

```
EOMonth(Today(), 0 )
```
今日の日付に0か月足して、月末の日にちに移動させるだけ！
EOMonth 関数ではデフォルトで月末の日にちに移動するので、引数による指定は不要です。


ちなみにこれも以前の方法はかなり複雑です。

```
//来月の初日の1日前（つまり今月末日）を取得
DateAdd(
    //来月の初日を取得
    DateAdd(
        //今月の初日を取得
        DateAdd(DateAdd(Today(),-Day(Today())),1,TimeUnit.Days),
        1,
        TimeUnit.Months
    ),
    -1,
    TimeUnit.Days
)
```

まあ、めんどうですこと！

# 終わりに
Power Platform はアップデートが速く、追うのは大変かもしれません。
ただ、このように徐々に誰にでも使いやすい方向にアップデートされています。
関数の式が短く簡単になれば、Power Apps を使おうと思う人も増えるかもしれません。
使う人が増えれば、自分が作らなくても誰かが作ってくれる、あるいは分担して作ることができる……かもしれません。
所属組織やご自身のより良い未来のために、ぜひ定期的にアップデート情報の取得やアプリメンテナンスに取り組んでみてくださいね('ω')ノ
Julia集合を描画するpython script

Julia集合でも見て、ちょっと休憩。

```julia.py
import numpy as np
import matplotlib.pyplot as plt

def julia_set(h, w, max_iter):
    y, x = np.ogrid[-1.4:1.4:h*1j, -2:2:w*1j]
    c = -0.7 + 0.27j
    z = x + y*1j
    divtime = max_iter + np.zeros(z.shape, dtype=int)

    for i in range(max_iter):
        z = z**2 + c
        diverge = z*np.conj(z) > 2**2
        div_now = diverge & (divtime == max_iter)
        divtime[div_now] = i
        z[diverge] = 2

    return divtime

h, w = 1000, 1500
max_iter = 100

plt.figure(figsize=(12, 8))
plt.imshow(julia_set(h, w, max_iter), cmap='gist_earth', extent=[-2, 2, -1.4, 1.4])
plt.colorbar()
plt.title('Julia Set')
plt.xlabel('Re(z)')
plt.ylabel('Im(z)')
plt.tight_layout()
plt.show()

```

![Screenshot from 2024-12-22 02-54-17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/315399/c37bdd6c-38a4-79d8-a78a-cf78f41a1df0.png)
企業の成長フェーズと並走するUIライブラリとの付き合い方

:::note
この記事は [Wano Group Advent Calendar 2024](https://qiita.com/advent-calendar/2024/wano-group) 12日目の記事です
:::

# アドカレ12日目です！
こんにちは！TuneCore Japanでフロントエンドをやっている [@rom1000_onigiri](https://qiita.com/rom1000_onigiri) です :qiitan:
みなさん、アドカレ期間楽しんでいますか？
様々な学びを様々な角度から得られる良い期間ですよね。

本日の記事は、私が従事しているフロントエンドと密接な関係にある **UIライブラリ** を、企業の成長フェーズと並走させる上でどう扱っていくか、その付き合い方について弊社のフロントエンド史と照らし合わせつつ私個人の考えをまとめてみました :xmas-tree:

# 企業の成長フェーズとそれぞれのステージに対するUIライブラリの扱い
企業の成長フェーズは一般的に **創業期**、**成長期**、**安定期**、**拡大期** の4ステージに分けられるようです。
それぞれのステージに対して、UIライブラリの扱いがどう変わっていくか、私は下記のように考えています。
## 創業期
認知度や売り上げがあまり高くない段階で、実績を作ることが重要視される
そのため、いち早くサービスを提供する必要がある
### 「創業期」のフロントエンド
プロダクトを一刻も早くローンチさせる必要があるので、構築やキャッチアップに時間のかからないマークアップ言語を用いて実装
フロントエンドに割く時間をできるだけ省略し、ビジネスロジックの設計や実装に時間を使えるように配慮する
## 成長期
創業期で形にした事業が実を結んで、事業が急成長する段階
また、成長を促すために多くの投資がなされる傾向にある
### 「成長期」のフロントエンド
成長期では初期と後期で扱いが変わると考えます
#### 「成長期初期」のフロントエンド
創業期で散らばったコーディングルールなどの整備
プロダクトのメンテナンス性向上のため、再利用を前提としたコンポーネントの概念の導入

時間的コストをかけないために、基本的なUIコンポーネントが用意されているUIライブラリを導入する :tada:
（ここからUIライブラリの扱いや付き合い方を考える必要が出てくる）
#### 「成長期後期」のフロントエンド
コンシューマーやカスタマーチームからプロダクトのUIに対する要望が増える
必要に応じて、導入したUIライブラリのコンポーネントを拡張する
（例：UIライブラリのコンポーネントをラップする、ドメイン知識を含んだコンポーネントの新規作成など）
## 安定期
経営が安定する一方で、提供するサービスの質や追加機能の量が求められる
会社の名前が広まり、ブランディングにもフォーカスしていく
### 「安定期」のフロントエンド
成長期後期からの重なるUIコンポーネントの拡張で、UIライブラリの仕様に合わせつつ要求が満たせるコードなどが増え肥大化する傾向がある
また、UIライブラリの仕様でサポートされていない拡張がしたくなる
上記解消のため、UIライブラリを剥がし、よりプロダクトや企業・組織の方針に沿った基本コンポーネントを新規で作成する

加えてブランディング戦略をフロントエンドに落とし込んでいくため、インハウスのデザイナーと独自のデザインシステムを確立していく
そのデザインシステムを新規で作る基本コンポーネントに適用していく

## 拡大期
さらなる企業成長を見込んで事業拡張をしていく段階
### 「拡大期」のフロントエンド
剥がし終わったUIライブラリの扱いや付き合い方を考えるのは終わり、会社の資産になった独自コンポーネント群の拡張を行っていく
新しい技術でしかできないUX向上（共同編集の仕組みなど）にフォーカスし、独自コンポーネント群に落とし込む

...into the future :rocket:

# 実際に剥がしているなう
今まさに弊フロントエンドチームでは、導入されているUIライブラリを剥がしている最中です。
インハウスのデザイナーさんと組んで、TuneCore Japanブランドを落とし込んだ基本コンポーネントを鋭意製作中です :muscle:

実際に剥がしながら思うことは...

## 単純にコンポーネント作成楽しい
「このコンポーネントってこれとこれが組み合わさっているのか」
「意外と単純な作りで要求満たせるな」
と車輪の再開発も悪くないケースがあるんだなと楽しみ学びながら剥がしています。
## 意外とドメイン知識がつく
「プロダクトの要求に沿うにはこのpropsを渡す必要があるな」
「今後こういう要求がされることを加味してpropsや処理だけ用意しておくか」
と意外にもドメイン知識につながるケースもありました。
## 会社の資産になるの嬉しい
ブランディングを落とし込んだ独自コンポーネントが、100％会社のもの（資産）になるのはとても嬉しいですし、「世界中どこを探しても、このイケてるUIコンポーネントはうちのプロダクトにしかないんだぞ〜！」と誇りに思えます。

# 最後に
あくまでも上記は個人の考えなので、UIライブラリの扱いの参考になったら幸いなのですが、扱いの方針は会社の数だけ、組織の数だけあると思っています。
創業初期からUIライブラリを用いてサービスのUIを整えるのもよいと思いますし、拡大期でもUIライブラリのコンポーネントを拡張し続けるのもよいと思います。

大切なのは、今の会社（やプロダクト）の成長ステージに親和性の高いUIライブラリの扱いを選択することですね。
この記事が、導入されているUIライブラリの扱いと向き合うきっかけになれば嬉しいです :four_leaf_clover:

<br>

:::note
~~明日は [@kotobuki5991](https://qiita.com/kotobuki5991) さんのURLヒストリー周りで頑張ったお話が公開されるようです！
お楽しみに :qiitan:~~
公開されました！:clap:
[URLをヒストリーとして保持しつつ、1ページで複数の検索を別々に走らせるために頑張った話](https://qiita.com/kotobuki5991/items/006a33909bc1264b9958#_reference-e8978d3cbc52705fa549)
:::

# PR
現在、Wanoグループ / TuneCore Japan では人材を募集しています。興味のある方は下記をご参照ください:information_desk_person:

Wano | [Wano Group JOBS](https://group.wano.co.jp/jobs/)
TuneCore Japan | [TuneCore Japan JOBS](https://www.tunecore.co.jp/jobs)
Mac環境のそれから Ver.2024-12

## 始めに
これまでBeeX AdventcalendarでMacBook Airの環境設定について書いてきました
それの2024年版となります

### 過去のもの
* [Mac環境のそれから Ver.2023-12](https://qiita.com/atakig/items/842c37dba59065755e1c)
* [Mac環境のそれから Ver.2022-12](https://qiita.com/atakig/items/61da94d77e8b9ea6eba9)
* [MacBook Airの環境設定について](https://qiita.com/atakig/items/16c191199b2d3fd159df)

## 継続して使用中
* [neovim](https://neovim.io/)
* [fish](https://fishshell.com/)
* [CodeWhisperer for command line](https://aws.amazon.com/jp/q/developer/)
* [Taskfile](https://taskfile.dev/)
* [Toggl](https://toggl.com/)
* [ロジクール M575S](https://www.logicool.co.jp/ja-jp/products/mice/m575s-ergo-wireless-trackball.910-005877.html)

neovimについては、今年のBeeX Adventcalendarで記事を書いています
[何故(neo)vimを使うのか](https://qiita.com/atakig/items/9da2a8c68cf6af22c58e)

## 変わったもの

### ブラウザ
BraveからChromeに変更しました
* NewRelicのブラウザ機能で、Braveがカウントされないこと
* Chromeの拡張機能が必要となったこと
が理由です

### Outlook
ブラウザのタブに固定表示していましたが、結構メモリを食うのでアプリに変えました

### ターミナル
昨年12月の時点では、[iTerm2](https://iterm2.com/)を使っていたようですが、[kitty](https://sw.kovidgoyal.net/kitty/)や[tabby](https://tabby.sh/)を経て、今は
[WezTerm](https://wezfurlong.org/wezterm/index.html)を使っています

軽さ、見た目の美しさ、設定内容の豊富さ、アイコンのデザイン等々を考えると、一番バランスが良いように思えます
~~[tmux](https://github.com/tmux/tmux/wiki)を自動起動するようにしました~~

![スクリーンショット 2024-12-11 14.38.39モザイク.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/6748/0dd1f373-e372-dc57-6753-892babd25991.png)

#### バージョンマネージャー
昨年12月は[asdf](https://asdf-vm.com/)を使っていたようです
Pythonについては [mise](https://mise.jdx.dev/)を使っていましたが、途中からバージョン管理もプロジェクト管理も出来る[uv](https://docs.astral.sh/uv/#uv)に変更していっています
uv addやuv runと言った統一感のあるコマンドインターフェイスが良いですね
![スクリーンショット 2024-12-10 14.34.20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/6748/7cbaeab2-a7a4-bfdf-29f3-8d9dce9d29e5.png)
上記uvさんサイトより拝借

### 日本語変換
昨年12月はMacOSのデフォルト日本語変換を使っていましたが、[SKK](https://note.com/jigjp_engineer/n/nc2c6ff076389)に戻ってきました
* OS側は[MacSKK](https://github.com/mtgto/macSKK)、
* neovimでは[Skkeleton](https://github.com/vim-skk/skkeleton)
を使っています

以前は[AquaSKK](https://github.com/codefirst/aquaskk)を使っていましたが、作者がvim-jp slackにいらっしゃるのと、今一つ更新がなされていないのでMacSKKにしました
なお、SKKだとバックスラッシュの入力が出来ず、それを入力する時はOSデフォルトの日本語変換を使うようにしています

### キーボード
昨年12月は、HHKBの日本語レイアウトを使っていましたが、今は、[MS Keys for mac KX700M 日本語配列](https://www.logicool.co.jp/ja-jp/products/keyboards/mx-keys-mini-for-mac.920-011219.html)に変更しました
(リンクは英語配列)
仕事用のMBAとプライベート用のMac Miniとの切り替えが容易な事、テンキーレスで薄く軽く小さい事、キーの重さと音でメカニカルキーがNGな事からこのキーボードとなりました

なお、Mac用の日本語配列は欠品していて、Amazonから中古の未使用品を購入しました
新品同様のものが届き、満足しています
![スクリーンショット 2024-12-10 14.44.12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/6748/c02ec285-ff8e-600f-2ffc-cb6c32db3388.png)
上記logicoolさんサイトより拝借

HHKBはキーボード自体の高さと持ち運びの困難さで使うのを止めました


## 終わりに
今回の内容がどなたかの快適な環境構築の1助になれば嬉しく思います
Error: Could not parse schema engine response: SyntaxError: Unexpected token E in JSON at position 0

## 表題のエラーがいきなり発生
ECRにpushする為にNEXT.jsのプロジェクトをbuildしようとしたらいきなり表題のエラーが発生。
いやいや数日前まで普通にできてたよ！

なんか一行追加したら治った！
```Dockerfile
# ベースイメージの設定
FROM --platform=linux/amd64 node:18-alpine AS base

# 作業ディレクトリの設定
WORKDIR /web

# package.jsonとyarn.lockをコピー
COPY package.json ./

# ~~ 省略　~~

# アプリケーションを起動
CMD ["npm", "start"]

```

```Dockerfile
# ベースイメージの設定
FROM --platform=linux/amd64 node:18-alpine AS base
# 以下を追加
RUN apk add --no-cache openssl

# 作業ディレクトリの設定
WORKDIR /web

# package.jsonとyarn.lockをコピー
COPY package.json ./

# ~~ 省略　~~

# アプリケーションを起動
CMD ["npm", "start"]

```

## エラーの前に出てた警告
```bash
prisma:warn Prisma failed to detect the libssl/openssl version to use, and may not work as expected. Defaulting to "openssl-1.1.x".
19.19 Please manually install OpenSSL and try installing Prisma again.
20.67 prisma:warn Prisma failed to detect the libssl/openssl version to use, and may not work as expected. Defaulting to "openssl-1.1.x".
20.67 Please manually install OpenSSL and try installing Prisma again.
20.68 Environment variables loaded from .env
20.68 Prisma schema loaded from prisma/schema.prisma

```

openssl をインストールすることで、SSL/TLS 関連の問題が解決された可能性が高いです。コンテナ内で暗号化通信を行うために必須のライブラリであるため、これを追加することで安全な接続を確立し、エラーを回避できるようになったと思われます。
【Dockerエラー】docker.errors.DockerException: Error while fetching server API version: Not supported URL scheme http+docker


## docker-compose up -d をした時にエラーが出た
1週間前くらいまでは問題なく動いていた`docker-compose`が急に動かなくなった。
```
docker.errors.DockerException: Error while fetching server API version: Not supported URL scheme http+docker
```

## まず初めに確認すること
```
sudo systemctl status docker
```
Dockerが起動していることを確認。
起動していても動かないようなら、リスタートしてみる。
```
sudo systemctl restart docker
```


## それでもダメなら
```
pip list | grep requests
```
requests のバージョンが 2.32.0 であれば、互換性の問題が起きている場合がある。

参考：https://forums.docker.com/t/error-while-fetching-server-api-version-not-supported-url-scheme-http-docker/141942/4

私の場合はバージョンを 2.31.0 にすることで解決。


\
これでも解決しない場合、`docker-compose` のバージョンアップを検討するといいかも？
ライフワークバランスを確認するツールを作った話 - 4

:::note info
この記事は[LITALICO Engineers Advent Calendar 2024](https://qiita.com/advent-calendar/2024/litalico) カレンダー3 の 14日目の記事です
:::

# はじめに

[前日の記事](https://qiita.com/nonikeno/private/d97ab7afed63da19fe92)の続きとなります

良い感じのツールができたところで、見える化について考えていきます
見える化を行うことで、最適なライフワークバランスをどう作っていくのか
妻とより仲良くなるためにはどうしたら良いかを考えていきます

# 見える化するゾ

改めて、見える化について考えてみると、業務上では、見える化を行うことで客観的な判断を行うことができたり、課題に気づきやすく、また、対応しやすくなるなど、見える化の目的を考えて実践することが大事ですよね

このツールで必要な見える化に関して、目的から考えていきましょう

## 見える化の目的を考える

このツールを作る上での課題はなんだったかを考えると、最初の記事に書かせていただいた通り、

- 家事を予定通りこなすことができない
- ライフワークバランスが最適化できているか不明

の2つでした

前者に関しては、ツールを作ったことで解消したのではないかと思いつつ、後者に関しては、手付かずです

では、後者のために見える化するかでいうと、ちょっと勿体無い気がします

なぜならば、課題を解決した後のその先を掘り下げられていないからです

家事を予定通りこなすことができるようになったの先は何か、ライフワークバランスが最適化した後の先は何かを掘り下げていくと、個人的には、一緒に暮らす妻が快適に過ごせるようにしたいが目指すゴールだと思いました

```
- 家事を予定通りこなすことができる
    - 家事の負担が片方によらないことで、安定的な生活ができる
    - 安定したPDCAサイクルを回せることで、家事の改善をし、家事の質を向上させる
    - 先々の予定を計画的に立てられるようになり、余暇の過ごし方を提案しやすくなる
- ライフワークバランスが最適化されている
    - 仕事や家庭、または、他の何かを犠牲にすることなく、先々のライフプランを立てられる
    - 将来に対するリスクを低減することができ、リスクに対する備えも最適化できる

→ 一緒に暮らす妻が快適に過ごせるようにしたい
```

## 目的からどういう見える化をすれば良いか考える

- PDCAサイクルを回す中で、確認のために見える化する
    - 確認すべきは
        - お互いの負担感
            - ワーク、余暇とのバランスが適切か
        - 家事の質の評価
            - 想定している家事の時間は適切か
            - 担当は適切か
            - 家事の得意・不得意、好き・嫌い

この辺りは、PDCAサイクルを回す中で、そもそも、確認項目が適切かも振り返りすべきですが、一旦、上記で考えております

- お互いの負担感の見える化
    - 家事時間、業務時間、余暇時間を積み上げ棒グラフで、PDCAサイクルのターム毎に表示
    - Germinが提供しているHealth APIから、バイオグラフの平均をPDCAサイクルのターム毎に表示

- 家事の質の評価
    - PDCAサイクルのターム毎に、家事毎の評価を、定量、定性で相互評価
    - 家事の得意・不得意、好き・嫌いをそれぞれ自己評価
    - 相互評価、自己評価を受けて話し合い
        - 担当、分担が適切か
        - 解決策が他にあるか
            - 家事代行の導入
            - 目指す質の再設定
            - 家事タスクの分割化、再定義

## 見える化の実装に関して

良いツールを組み込むことが簡単でしたら、そうしたかったのですが、
なかなか良いライブラリーが見つからなかったので、グラフ部分はpythonで実装、PDCAサイクルに関しては、課題管理ツールを別で用い、[Matplotlib](https://matplotlib.org/)を使用して作成したグラフを手動で取り込んでCheckの際に確認する形です

この辺り、Github Actionsを用いて、自動化したかったのですが、残念ながら手が回らず。

# ツール導入成果

- お互いの負荷状況は見えるようになった
    - ただし、単純に時間で見るだけだと、その時間家事をすることで減っていくHPまでは比較できない
        - それを補うために、GerminのHealth APIで取得できる値に期待していたが、家事以外の要員によっても変動するため、単純に数字だけを見るのは危険、あくまで参考程度として考えた方が良さそう
- 運用のコストは当初想定よりかかった
    - 家のことで、PDCAサイクルを回すのは、少し仰々しい
        - PDCAではなくて、年次など、長いスパンの振り返りで確認するくらいで良いかも、この辺りも運用を話し合いかな
    - 実験的な試みに付き合ってくれた妻には感謝、今後も継続するかは要相談かな
        - 自分の担当家事をカレンダーに登録する、初期の構想は継続できそう
- 改めて、話し合いをするきっかけになったのが一番の成果
    - 家事1つとっても、価値観の違いはある
        - 例えば、何を優先したいのか、私は食に関することにコストを使いたい人とわかり、妻は住、特に掃除にコストを使いたい人とわかった
            - ここから気になる方がやれば良いだと、本来の趣旨から外れてしまうので、お互いの優先したいことを加味した上で、どういう家事分担にするか、話し合いを継続

# 終わりに

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

当初は、成果が大きければ、業務でも使えるんじゃないかと思ってましたが、業務で活用するには、見える化と振り返りのツール化部分に関してブラッシュアップしていく必要があると感じました、サービス化したいっていう方いれば真剣に考えます

ただ、取り組みとしては、面白かったです
業務でシステム開発するのも楽しいですが、個人開発するのは、自由度が高くて、また、別の面白さがありますね

エンジニアとして、インプットとアウトプットのバランスが大事とはよく言われますが、インプットした内容に対し満遍なくアウトプットを行うためには、業務だけでは難しいケースもあり、個人開発も改めて重要だなと感じております
kaggle tutorial statsmodels 日本語訳後半

kaggle に出てくるstatsmodelsの日本語訳です。後半は

https://www.statsmodels.org/dev/generated/statsmodels.tsa.deterministic.DeterministicProcess.html

を訳していきます。
```
class statsmodels.tsa.deterministic.DeterministicProcess
    (index, *,
    period=None,
    constant=False,
    order=0,
    seasonal=False,
    fourier=0,
    additional_terms=(),
    drop=False)
```

決定論的項を管理するためのコンテナクラスです。

このクラスは、定数項、時間トレンド、そして単一周期に対する季節ダミーまたはフーリエ項のいずれかを直接扱うことができます。コンストラクタで初期化できるものに加えて、追加の決定論的項を追加することも可能です。

引数
----------
index : {Sequence[Hashable], pd.Index}
    対象となるデータのインデックス。予測モデルを構築する際には、通常は学習用データのインデックス (サンプル内インデックス) を指定します。

period : {float, int}, デフォルトは None
    季節性またはフーリエ項の周期。季節ダミーを使用する場合は整数で指定する必要があります。指定されない場合、インデックスから周期 (freq) が読み取られます (可能な場合)。

constant : bool, デフォルトは False
    定数項を含めるかどうかを指定します。

order : int, デフォルトは 0
    時間トレンドの次数を指定します。例えば、2 を指定すると、線形トレンド (1次) と二次トレンド (2次) の両方が含まれます。0 を指定すると時間トレンド項は除外されます。

seasonal : bool, デフォルトは False
    季節ダミーを含めるかどうかを指定します。

fourier : int, デフォルトは 0
    使用するフーリエ項の次数を指定します。

additional_terms : Sequence[DeterministicTerm]
    追加で使用する決定論的項を `DeterministicTerm` オブジェクトのリストとして指定します。

drop : bool, デフォルトは False
    項同士に完全な共線性がないかを確認し、線形従属な項を削除するかどうかを指定します。

属性
-------
index
    データのインデックス

terms
    使用されている決定論的項のリスト

# 難しい表現の解説:

- 決定論的項 (deterministic terms): CalendarFourier の解説で説明した通り、確率的な要素を含まず、値が確定している項を指します。
コンテナクラス (container class): 他のオブジェクトをまとめて管理するためのクラスです。DeterministicProcess は、複数の決定論的項を terms 属性に保持し、それらをまとめて操作する機能を提供します。
- 共線性 (collinearity): 複数の変数間に強い相関関係がある状態を指します。特に、完全な共線性 (perfect collinearity) は、ある変数が他の変数の線形結合で完全に表される状態を指します。これは、回帰分析を行う際に問題を引き起こします (多重共線性)。
- 線形従属 (linearly dependent): ある変数が他の変数の線形結合で表される関係にあることを意味します。

# まとめ
DeterministicProcess は、時系列データの決定論的な変動をモデル化するための強力かつ柔軟なツールです。様々な決定論的項を組み合わせて使用することで、複雑なパターンのある時系列データにも対応することができます。
The Myosotis Method「ミオソテスの方法と重ね合わせの原理の違いを教えて下さい。」AI先生に聞きました。

```
ミオソテスの方法と重ね合わせの原理の違いを教えて下さい。
```
・私の質問の仕方が悪いようです。
・ChatGPT先生の回答がそれらしい？かも
# ChatGPT先生へ
```
(抜粋　主な違いが項目別に、比較表がでます。)
それぞれ異なる状況で用いられる方法や考え方です。
```

# Gemini先生へ
```
(抜粋　両者の違いが項目別に、比較表がでます。)
そのアプローチが異なります。
```

# Copilot先生へ
未


# 参考

https://qiita.com/mrrclb48z/items/edb6a20fb52cc6f1cbcb
Elixir 1.18 の JSON エンコード/デコードを試してみる

## はじめに

Elixir 1.18 のリリース候補（RC版）が出ました

https://github.com/elixir-lang/elixir/blob/v1.18/CHANGELOG.md

JSON を扱う際、今までは Jason などのパッケージをインストールする必要がありました

今回の更新でパッケージなしに JSON をエンコード/デコードできるようになったということです

早速試してみました

## Elixir 1.18.0-rc.0 のインストール

asdf で 1.18.0-rc.0 をインストールしました

```bash
asdf install elixir 1.18.0-rc.0
```

カレントディレクトリー配下で 1.18.0-rc.0 を使うように指定します

```bash
asdf local elixir 1.18.0-rc.0
```

## JSON エンコード

Elixir の対話シェルである iex を起動します

```bash
iex
```

マップを JSON にエンコードしてみます

```elixir
JSON.encode!(%{hello: "Elixir"})
```

実行結果

```elixir
"{\"hello\":\"Elixir\"}"
```

たしかに JSON 文字列に変換されています

配列も当然扱えます

```elixir
JSON.encode!(%{hello: [1, 2, 3]})
```

実行結果

```elixir
"{\"hello\":[1,2,3]}"
```

## JSON デコード

逆にデコードも可能です

```elixir
JSON.decode!("{\"hello\":\"Elixir\"}")
```

実行結果

```elixir
%{"hello" => "Elixir"}
```

## まとめ

標準のモジュールだけで JSON が扱えるようになったのは嬉しいですね
SQL Serverのラッチ競合について調べてみた

## はじめに

 以下[Microsoftのドキュメント](https://learn.microsoft.com/ja-jp/sql/relational-databases/diagnose-resolve-latch-contention?view=sql-server-ver15)　から引用
<details><summary> SQL Server のラッチの競合とは </summary>
SQL Server のラッチの競合とは
ラッチとは、インデックス、データ ページ、および B ツリー内の非リーフ ページのような内部構造など、メモリ内の構造の整合性を保証するために SQL Server エンジンによって使用される、軽量の同期プリミティブです。 SQL Server では、バッファー プール内のページを保護するためにはバッファー ラッチが使用され、バッファー プールにまだ読み込まれていないページを保護するためには I/O ラッチが使用されます。 SQL Server バッファー プール内のページのデータの書き込みまたは読み取りが行われるときは常に、ワーカー スレッドにおいて最初にそのページのバッファー ラッチを取得する必要があります。 バッファー プール内のページにアクセスするために使用できるバッファー ラッチには、排他的ラッチ (PAGELATCH_EX) や共有ラッチ (PAGELATCH_SH) など、さまざまな種類があります。 SQL Server によってバッファー プールにまだ存在しないページへのアクセスが試みられると、そのページをバッファー プールに読み込むための非同期 I/O がポストされます。 SQL Server で I/O サブシステムの応答を待機する必要がある場合は、要求の種類に応じて、排他 (PAGEIOLATCH_EX) または共有 (PAGEIOLATCH_SH) の I/O ラッチで待機が行われます。これは、別のワーカー スレッドにより互換性のないラッチを使用して同じページがバッファー プールに読み込まれるのを防ぐために行われます。 ラッチは、バッファー プール ページ以外の内部メモリ構造へのアクセスを保護するためにも使用されます。これらは、非バッファー ラッチと呼ばれます。

ページ ラッチでの競合は、マルチ CPU システムで発生する最も一般的なシナリオであるため、この記事の大部分でこれらに焦点を当てています。

ラッチの競合は、複数のスレッドが同じメモリ内構造に対して互換性のないラッチを同時に取得しようとすると発生します。 ラッチは内部的な制御メカニズムであるため、それらを使用するタイミングは SQL エンジンによって自動的に決定されます。 ラッチの動作は決定論的であるため、スキーマの設計を含むアプリケーションの決定が、この動作に影響することがあります。 

</details>

ドキュメントの内容だと長いので、これを調べて少し噛み砕いていこうと思います。
きっと最後までついて来れた方は↑がサラッと読めるようになるかも？

まずはじめにページとラッチについて整理していきたいと思います。

## ページとは

SQL Serverがデータをアクセスする際の基本単位

![スクリーンショット 2024-12-11 21.35.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2970759/373d8392-f3bc-1878-c3ad-8b54fd5d11ce.png)

## ラッチとは
- ラッチはリソースの保護方法の一つ
- ラッチはSQL Server以外でも使われる用語
  - C#とかでも出てくる
  - https://docs.microsoft.com/ja-jp/dotnet/standard/threading/how-to-use-spinwait-to-implement-a-two-phase-wait-operation

## ページラッチとは
メモリにロードされた（バッファ上にキャッシュされた）ページ（データ領域）保護するための機構です。
ページラッチにはいくつかのモードがあります。

### SQL Server のラッチモード
- KP -- 保持ラッチ (Keep Latch)
  - 参照されている構造を破棄できないようにする
  - スレッドでバッファーの構造を確認する必要がある場合に使用される
- SH -- 共有ラッチ
  - データ ページの読み取りなど
- UP -- 更新ラッチ (Update Latch)
  - 更新時に
- EX -- 排他ラッチ (Exclusive Latch)
- DT -- 破棄ラッチ (Destroy Latch)


このラッチのモードごとに同時取得できるものと、できないものがあります。
それが以下の表になります。

![スクリーンショット 2024-12-11 21.37.45.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2970759/92946cb6-80a0-4d37-a417-3a1646f58582.png)

- 互換性がある場合は同じページに対して複数のラッチを同時に取得できる
- 互換性のないモードで保持されるラッチの取得を試みるとキューに配置される

## ラッチ競合について

ここまでの説明のページラッチのモードの互換性によりラッチ競合が発生します。

例えば、同一のページに対してEXのラッチを取っているときに、SHのラッチの取得はできません。
このときにSHラッチが取得できないことをラッチ競合と言います。

EXやDTのページラッチでは他のラッチモードとの互換性が少ないので、長時間このラッチを取得しているとラッチ競合が起きやすくなります。
なのでラッチ競合が発生した場合は、EXやDTの占有時間を少なくできると良いでしょう。
もしくは、ページ単位なので異なるページへのアクセスになるようにデータの持ち方を検討するのも一案だと思います。

## 参考
- [Microsoft SQL Server でラッチの競合を診断および解決する](https://learn.microsoft.com/ja-jp/sql/relational-databases/diagnose-resolve-latch-contention?view=sql-server-ver15)
kaggle tutorial 解説 statsmodels 公式ドキュメントより

time series tutorial では、statsmodelsについてあまり解説がありません。英語圏の方は直接公式ドキュメントをよむと良いのですが、日本語での資料が不足しています。tutorial 解説からは少し離れていますが、tutorial で使用した関数については日本語の訳を載せます。私のつたない日本語訳ですので、プルリクをいただけたら幸いです。

https://www.statsmodels.org/dev/generated/statsmodels.tsa.deterministic.CalendarFourier.html



クラス statsmodels.tsa.deterministic.CalendarFourier(freq, order)

カレンダー時刻に基づいたフーリエ級数による決定論的項を生成するクラスです。

引数
----------
freq : str
    pandas の頻度に変換可能な文字列 (例: "D" (日次), "M" (月次))。

order : int
    使用するフーリエ成分の数。周期の2倍以下である必要があります。

属性
-------
freq
    決定論的項の周期。

is_dummy
    生成される値がダミー変数 (0 または 1) かどうかを示すフラグ。

order
    使用するフーリエ項の次数。

関連項目
--------

DeterministicProcess: 決定論的過程を扱うための一般的なクラス
CalendarTimeTrend: カレンダー時刻に基づいたトレンド項を生成
CalendarSeasonality: カレンダー時刻に基づいた季節性項を生成
Fourier: フーリエ級数による決定論的項を生成 (CalendarFourier はこれをカレンダー時刻に特化したもの)

注釈
-----

次数 `order` に対して、各次数 `i` (1 から `order` まで) について、サイン項とコサイン項の両方が生成されます。

数式は以下の通りです。

 
ここで、`m` は周期の長さ、
`t_norm` は正規化された時刻です。例えば、`freq` が "D" (日次) で、タイムスタンプが 12:00:00 の場合、`t_norm` は 0.5 となります (12時間 / 24時間 = 0.5)。

使用例
----

ここでは、不規則な間隔で取得された時間単位のデータをシミュレートし、そのデータに対するカレンダーフーリエ項を作成します。
```
import numpy as np
import pandas as pd
base = pd.Timestamp("2020-1-1")
gen = np.random.default_rng()
gaps = np.cumsum(gen.integers(0, 1800, size=1000))  # 0から1800秒のランダムな間隔を生成
times = [base + pd.Timedelta(gap, unit="s") for gap in gaps]  # 基準時刻に間隔を加算してタイムスタンプを生成
index = pd.DatetimeIndex(pd.to_datetime(times))  # タイムスタンプをインデックスに変換

from statsmodels.tsa.deterministic import CalendarFourier
cal_fourier_gen = CalendarFourier("D", 2)  # 日次周期で次数2のフーリエ項を生成cal_fourier_gen.in_sample(index)  # インデックスに基づいたサンプル内データに対するフーリエ項を生成
```
メソッド
-------

- in_sample(index)

与えられた `index` (DatetimeIndex) に対して、サンプル内データ用の決定論的トレンドを生成します。

- out_of_sample(steps, index[, forecast_index])

    サンプル外データ用の決定論的トレンドを `steps` 分だけ生成します。`index` は既存のデータ、`forecast_index` は予測対象期間のインデックス (省略可能)。

プロパティ
-------

- freq

    決定論的項の周期。

- is_dummy

    生成される値がダミー変数 (0 または 1) かどうかを示すフラグ。

- order

    使用するフーリエ項の次数。


# 細かい解説、用語の確認
- 決定論的項 (deterministic terms): 
確率的な変動を含まない、確定的な値を持つ項。CalendarFourier で生成されるフーリエ項は、時刻が決まれば一意に値が決まるため、決定論的項です。
フーリエ級数 (Fourier series): 周期関数を、サイン波とコサイン波の和で表現する方法。次数を増やすことで、任意の周期関数を近似できます。


- カレンダー情報に基づく周期性: 一般的なフーリエ級数とは異なり、CalendarFourier は「日次」「月次」といったカレンダー情報に基づいて周期を定義します。これにより、例えば「毎週月曜日に特定のパターンが見られる」といった、現実世界の周期性をより正確に捉えることができます。
- freq パラメータ: freq パラメータで周期の単位を指定します。これは pandas の frequencies (例: "D" (日次), "W" (週次), "M" (月次) など) に準拠しています。
order パラメータ: order パラメータでフーリエ級数の次数を指定します。次数が高いほど、より複雑な周期パターンを表現できますが、過学習のリスクも高まります。
正規化された時刻 (t_norm): 時刻は周期の長さで正規化されます。これにより、周期の異なるデータに対しても、フーリエ項を統一的に扱うことができます。
in_sample と out_of_sample メソッド: in_sample は既存のデータに対するフーリエ項を生成し、out_of_sample は未来の予測期間に対するフーリエ項を生成します。

- サンプル内 (in-sample) / サンプル外 (out-of-sample):
モデルの学習に使用されるデータを「サンプル内データ」、学習に使用されず、モデルの予測性能を評価するために使用されるデータを「サンプル外データ」と呼びます。
レガシーな職場で、業務を刷新した話

本記事は下記アドベントカレンダーに参加しています。
なお、本記事に関する内容は個人の意見になります。

https://qiita.com/advent-calendar/2024/works-hi-2

----------------------------------------------------------------------------------------
レガシーを刷新するために、実施したことを述べる前に、どういったレガシー環境だったか前提を述べておきます！

## 前提：以前働いていたレガシーな職場環境
場所：工場
状態：
全くデジタル化が進んでいない
レベル感としては、
- ピボットテーブルが使えたら神。
- Win+Lで画面ロックしてる人が全くいない
- 出張申請は紙。
その他の詳細はこちらの記事を参照ください
[メーカー、工場やレガシーな職場での今思うとヒヤリハットだったこと](https://qiita.com/nozawanatsu/items/41c87d72aa497208a875)

なので、業務改善の一環でレガシーな会社を少しでもレガシーから遠ざける活動をしました！

## 刷新したこと
#### kintoneの導入
ワークフローの作成（出張申請、備品申請、有給取得）
マニュアル整備化
クレーム内容の集計
不良品の傾向まとめ
取引先ごとの情報整理(今までは各担当が保管していたので見える化)
帳票プラグイン購入→今まで使ってたライセンス費用削減
不良品トラブル共有  

#### 見積もり書をマクロで一括作成
※勝手にいじられないよう読み取り専用で実施してもらう。かつ元のデータは別保存。

- 取引先ごとの価格表を商品登録ツールに連携
- 展示会問題：はがきで案内を送る
→Sansanで読み取って、データ化
→筆まめで住所、名前を読み込んで送る
今までは、手作業で入力していた。

#### エンジニアになった今、振り返るとしたかったこと
- 棚卸の集計、内製化、在庫管理
- 受注関連の作業の改善

まだまだ探せば他にももっとあるなぁと思います。
例えばPowerAutomateとか伝えたかも。

---
簡単な記事でしたが、レガシーな会社であればあるほど、改善はしやすいかもと思いました。
今の会社でも改善していくぞー。
WordPressでjQueryを読み込むとエラーが出たのでまとめます

## はじめに
WordPressの独自テーマを作成した際、jQueryの読み込みでエラーが出たのでまとめます。

## 問題
functions.phpファイル内で「wp_enqueue_script」を使用して読み込むと、下記エラー文がコンソールに表示されました。

```ruby:console
Uncaught TypeError: $ is not a function
```

エラー文を要約すると、「jQueryファイルに記述した$は関数ではない」というものです。

## 解決方法
解決方法は、読み込んだjQueryファイルに記述した「$」を「jQuery」と書き換えるだけでした。

```ruby:jsファイル
/* エラー時のコード */
$(function() {
    $('.selector').addClass('active');
});

/* 解決時のコード */
jQuery(function() {
    jQuery('.selector').addClass('active');
});
```

ただし、これだと$(function() 内の「\\$」も書き換える必要があります。
もっと簡単にすると下記のコードとなります。

```ruby:jsファイル
jQuery(function($) {
    $('.selector').addClass('active');
});
```

function()引数に\\$を渡すことで、function内の\\$は変更せずに済みます。

## なぜ$を使用できないのか
WordPressはデフォルトでjQueryが読み込まれており、jQueryファイル内で「noConflict()」メソッドが実行されているようです。

noConflict()メソッドは、複数のライブラリで競合を起こさないよう「\\$」の使用を禁止するためのものです。
そのため、「$」を使用していたことからエラーが発生してしまいました。

## まとめ
wp_enqueue_script()内のどこかの記述を間違えたのかと思いずっと調べていたので、すごく時間が取られてしまいました。

## 参考
[https://tcd-theme.com/2024/01/wp-jquery.html](https://tcd-theme.com/2024/01/wp-jquery.html)
mindの研究 その91

# 概要
mindが、謎なので調べてみた。
練習問題やってみた。

# 練習問題
win32apiでPostMessageを叩け。

# 参考にしたページ

https://qiita.com/nxted_sapporo/items/c28140ea0efee8a6f2b3


# 環境
windows11

# サンプルコード

```

メインとは
　ターゲットは　変数
　プロラは　変数
　結果は　変数
　文字1は　文字列実体
　「CabinetWClass」を　文字1に　入れ　０を　文字１に　一文字追加し　文字１の　アドレスを得て
　０をつみ
　"user32"と　"FindWindowA"で　ＡＰＩ呼出し２　結果に　入れ
　エラー？
　ならば
　　エラー文字列を　一行表示し　終り
　つぎに
　結果を　プロラに　入れ
　一秒待つ
　プロラをつみ
　"user32"と　"SetForegroundWindow"で　ＡＰＩ呼出し１　結果に　入れ
　エラー？
　ならば
　　エラー文字列を　一行表示し　終り
　つぎに
　結果を　ターゲットに　入れ
　ターゲットを　数値表示し　改行する
　一秒待つ
　プロラをつみ　
　0111hをつみ
　0A21Bhをつみ
　0をつみ
　"user32"と　"PostMessageA"で　ＡＰＩ呼出し４　結果に　入れ
　エラー？
　ならば
　　エラー文字列を　一行表示し　終り
　つぎに
　。

```

以上。
Elixir 1.18 の mix format --migrate を試してみる

## はじめに

Elixir 1.18 のリリース候補（RC版）が出ました

https://github.com/elixir-lang/elixir/blob/v1.18/CHANGELOG.md

`mix format --migrate` で非推奨コードの自動修正ができるようになったとのことで試してみます

## Elixir 1.18.0-rc.0 のインストール

asdf で 1.18.0-rc.0 をインストールしました

```bash
asdf install elixir 1.18.0-rc.0
```

カレントディレクトリー配下で 1.18.0-rc.0 を使うように指定します

```bash
asdf local elixir 1.18.0-rc.0
```

## プロジェクトの作成

新しいプロジェクトを作成します

```bash
mix new old
```

Elixir プロジェクトに必要な最低限のディレクトリー構造とファイルが作成されます

ディレクトリー内に移動します

```bash
cd old
```

## 非推奨コードの実装

`lib/old.ex` を以下のように変更します

```elixir
defmodule Old do
  def hello do
    <<foo::binary()>> = "hello"

    IO.puts(foo)

    unless true do
      IO.puts('hello')
    end
  end
end
```

- `<<foo::binary()>>` の `()` は不要になりました
- `unless` は非推奨になりました
- `''` は c シギルで書くのを推奨しています

## 非推奨コードの自動修正

以下のコマンドを実行します

```bash
mix format --migrate
```

`lib/old.ex` が以下の内容に修正されています

```elixir
defmodule Old do
  def hello do
    <<foo::binary>> = "hello"

    IO.puts(foo)

    if !true do
      IO.puts(~c"hello")
    end
  end
end
```

## まとめ

これで古いコードを修正するとき、かなり手間が減りそうです
無線に関する問題

>無線ネットワーク層では、輻輳とは関係なくパケットロスが生じる点にある。無線ネットワークは有線ネットワークほど信頼性は高くないからである。

# 無線、有線でフレームのロス率が違う
>高速TCPコネクションは、パケットのロス率が例えば1%などのように小さい時に達成できることを意味する。1%は有線ネットワークでは中程度のロス率である。もしロス率が10％に達すると、ネットワークが実質的に停止する。
 一方で、802.11LANなどの無線ネットワークでは、10%のフレーム・ロス率は、一般的である。このことにより、パケット・ロスを輻輳シグナルとする輻輳制御プロトコルは、無線リンクを含むコネクションのレートを非常に低く絞って通信を行うことになるのである。

### フレームロスの原因で区別して効率を改善させる
>　効率を改善するためには、輻輳制御アルゴリズムは、帯域不足のためパケット・ロスだけをパケット・ロスとし、伝送誤りによるパケット・ロスはそうでないとすべきである。この一つの方法は、無線リンクでの再送を利用して無線パケット・ロスを区別するマスキング戦略という

### 経路で無線か有線どちらのリンクを通っているかわからない。
>インターネットの経路は不均質であり、送信側は経路がどのようなリンクで構成されているのかの情報を知る手立てがない。これが輻輳制御の問題を複雑にしており、一つのプロトコルで、無線リンクと有線リンクの両方を最適に制御することは簡単ではない。

# 輻輳か伝送誤りの制御が２つ同時に動くとフレームの再送と送信レートの低下で遅くなる
>パケットロスによって駆動される２つのメカニズムを示している。つまり、データ・リンク層でのフレーム再送とトランスポート層での輻輳制御である。謎とは２つのメカニズムが混乱しないようにいかに混在できるのか、ということである。なぜなら、その原因は、伝造誤りか輻輳かのいずれであるからである。もし、両者が同時に動作すると（フレームの再送と送信レートの低下）、無線リンクを含む場合には必要以上に遅くなってしまう。すなわち、トランスポート層の最初の問題に戻る。

### マスキング戦略は最適な策ではない　往復が遅い場合があるから
>マスキング戦略は、たいていのトランスポート層プロトコルをほとんどの無線リンクでうまく動作させる。しかし、それは必ずしも最適な解決策ではない。衛生などの一部の無線リンクの往復は非常に長い。この場合は、例えば、FECなどの他の方法を用いるか、あるいは、パケット・ロスではない別の輻輳制御シグナルを使わなければならない。

### 無線は容量が時間と共に変動する
>無線リンクの容量は時間ともに変動する。時には、ノードの移動に伴って急激に変動する。またチャネルの状況によって、信号対雑音比が変動する。このことは、容量が固定の有瀬とは全く異なる。したがって、トランスポート層プロトコルは、無線リンクの容量変化に対応しなければならない。そうでなければ、ネットワークの輻輳か、利用可能な容量を無駄にするかのいずれかの結果を招く。

### 解決策はフレームロスを気にしないことにする
>この問題の一つの解決策は、単純に、気にしないことである。この戦略は、現実的である。
>なぜならば輻輳制御アルゴリズムは、ユーザーが新たにネットワークに加入したり、存在するユーザーの送信レートの変動に対処可能なように既に構成されているからである。
...
無線リンクを含む場合であっても単にTCPを動作させてそれなりに性能を達成することもできる。

https://bookplus.nikkei.com/atcl/catalog/23/03/16/00728/
LaTeX にPowerPointの図形を挿入する方法

# 要約
Windowsにて，PowerPointで作成したベクタファイルの図形をLaTeXに貼り付けるための手順

# 画像ファイルの種類
画像ファイルには「ラスタファイル」と「ベクタファイル」がある．
- **ラスタファイル**  
  ピクセル単位で管理されるデータ 例: png, jpeg
- **ベクタファイル**  
  オブジェクト（各図形や文字）単位で管理されるデータ  例: pdf, svg, eps, emf, bmp

LaTeXに（Wordでも）ラスタファイルを貼り付けると画質が悪くなる（図1参照）．
一方で，ベクタファイルは，拡大・縮小しても滑らかに表示される．
➡ **ベクタファイルを貼り付けましょう。**
 !<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3959520/6153addd-c726-7b60-ae86-d8f4569f2c47.png" width="300">
*図1: ラスタファイル ".png" を貼り付けた場合の画像劣化*

## パワーポイント図のLatex貼り付け手順
- パワーポイントで作成した図を、「図として保存」からベクタファイルとして保存
- LaTeXに貼り付け
    - **Macの場合:** ベクタ形式 ".pdf" で保存可能  
    - **Windowsの場合:** ベクタ形式 ".svg", ".emf", ".bmp", ".wmf" で保存可能  
  ⚠️ただし、これらはすべてLaTeX貼り付け不可．

➡ 本記事：PowerPointで図形を".svg" 形式で保存し、ツールを用いて ".pdf" に変換  

# 変換方法
以下は変換操作を簡素化するバッチファイルとその使用方法
### 1. svgからpdf変換するためのソフト "inkscape" をインストール
以下のURLからインストール:  
[https://inkscape.org/ja/](https://inkscape.org/ja/)
### 2. 変換作業を行うフォルダを作成
任意の場所に作業フォルダを作成
ファイルエクスプローラのクイックアクセスに追加すると便利
### 3. 変換を簡易化するスクリプト（バッチファイル）の準備
バッチファイルとは，Windowsでコマンドを自動実行するスクリプト
2で作成したフォルダに以下のファイルを配置します．
ファイル名 `svg2pdf.bat` 
```svg2pdf.bat
cd /d %~dp0
"C:\Program Files\Inkscape\bin\inkscape.com" --export-type="pdf" %1
```
※ 作り方詳細：メモ帳からsvg2pdf.txtを作成・保存し，上をコピーした後に.txtの部分を.batに変更する．
### 4. 変換したい .svg ファイルを `svg2pdf.bat` にドラッグする
1. `.svg` ファイルをマウスで選択し、作成した `svg2pdf.bat` ファイルにドラッグ＆ドロップ
2. 同じ名前の `.pdf` ファイルが作業フォルダ内に生成されます．
 
**注意事項**:
- ダブルクォーテーションのエンコードミス（文字化け）に注意してください．
- PDFテキストをコピーすると、スペースが挿入される場合があります．

**変換に失敗した場合**:
変換に失敗した場合は、以下の`svg2pdf_debug.bat`を作成し，
同様にドラッグ＆ドロップすることでエラーメッセージを確認できます．
```svg2pdf_debug.bat
cd /d %~dp0
echo "Check path of the dragged file bellow"
echo %1
echo "Check the following command"
"C:\Program Files\Inkscape\bin\inkscape.com" --export-type="pdf" %1
pause
```
Laravel Sail での Tinker 使用時、日本語文字化け解消手順

# Laravel Sail で Tinker時の文字化け解消

## 課題

- Laravel Sail環境で`php artisan tinker`を使った際の文字化けを解消したい

## 環境
- Laravel11 (Sail)
- Mysql8.0


## なぜ文字化けするのか

Laravel Sailを使うと、Docker環境内でPHP・MySQLなどが動作します。  
その際、デフォルトのMySQLやターミナルのロケール設定がUTF-8ではない場合、特に日本語などのマルチバイト文字を扱う時に文字化けが発生します。  
Tinkerは、アプリケーション内部のテストやモデルファクトリで日本語を出力すると、MySQLのデフォルトエンコーディングやクライアントの文字コード設定が不十分な場合、ターミナル上で正常に表示されません。  

## 解決

### 1. **Sail の Dockerfileを編集する準備**

 Laravel Sailでカスタム設定を反映するには、デフォルトのSail構成ファイルをパブリッシュします。  

 ```zsh
 sail artisan sail:publish
 ```

これでdocker/ディレクトリ以下にDocker用の設定ファイル群が生成され、自由にカスタマイズできます。

### 2. MySQL 設定ファイル(my.cnf)の追加

docker/使用中のdockerのversion/ ディレクトリ（例：docker/8.4/）内に my.cnf ファイルを作成し、以下の内容を記述します。

```zsh
[mysqld]
character-set-server=utf8mb4
collation-server=utf8mb4_general_ci
explicit-defaults-for-timestamp=1
general-log=1
general-log-file=/var/log/mysql/mysqld.log

[client]
default-character-set=utf8mb4

```

この設定により、MySQLサーバーとクライアントとのやり取りに常にutf8mb4が使用され、文字化けが防止できます。

### 3. docker-compose.yml の volumes に追記

docker-compose.yml のMySQLサービス定義部分にmy.cnfをマウントする設定を追加します。
例として、MySQLサービスが mysql という名前の場合：

```zsh
services:
  mysql:
    # ...その他設定...
    volumes:
      - './docker/8.4/my.cnf:/etc/my.cnf'

```

これでコンテナ起動時にMySQLが上記設定を反映するようになります。

### 4. 再ビルド・再起動

設定を反映させるため、Dockerイメージの再ビルドとコンテナの再起動を行います。
```zsh
sail build --no-cache
sail up -d
```

### 5. mysqlの確認
`sail mysql` でmysqlにログインし確認

**結果**  
```zsh
mysql> SHOW VARIABLES LIKE 'character%';
+--------------------------+--------------------------------+
| Variable_name            | Value                          |
+--------------------------+--------------------------------+
| character_set_client     | utf8mb4                        |
| character_set_connection | utf8mb4                        |
| character_set_database   | utf8mb4                        |
| character_set_filesystem | binary                         |
| character_set_results    | utf8mb4                        |
| character_set_server     | utf8mb4                        |
| character_set_system     | utf8mb3                        |
| character_sets_dir       | /usr/share/mysql-8.0/charsets/ |
+--------------------------+--------------------------------+
8 rows in set (0.01 sec)
```


再度、`php artisan tinker`を実行し、日本語文字列が正しく表示されるか確認してください。

### まとめ
MySQLとクライアント間の文字コード設定がUTF-8でなかったため、Tinker上での日本語が文字化けしていました。 
my.cnfでutf8mb4を指定し、Docker Composeで適切なマウント設定を行うことで、文字化けを解消できます。  
これらの手順を踏むことで、Laravel Sail環境でのTinker実行時に日本語が正常に表示され、開発効率やデバッグの快適さが向上します。
入社2年目(エンジニア1年目)にはレガシーシステムはキツすぎた

# はじめに
初めまして。
駆け出しデータエンジニアのotoyaです。
タイトルにもある通り新卒で入社して2年目(開発部門配属されて1年目)です。

# 当時のインフラ
下記画像のようになってました。

![スクリーンショット 2024-12-12 8.42.51.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3680837/79dd5b8c-3613-293d-db7c-5b6fb3eac9f2.png)

ただこれにはいくつも問題があり・・

**元データの問題**
- 似たようなDBが存在するが、使い分けがわからない
- PostgresやMySQLやClickhouseなどがEC2上に乗っているのですが、versionが古すぎる
どのDBか忘れましたが、explain(実行計画)がサポートされてないとエラーが出た時は痺れました笑

**ETLの問題**
- digdagサーバーが会社にあるmac miniの上に乗っているが、UPSなどがなく停電するとサーバーが落ちる
- 何故かgithubに書いてあるコードとmac mini上にあるコードが違う
- ci/cdに対応していない

**DWHの問題**
- データレイクもBigQuery上においてあり無駄なコストが発生している
- scheduled queryも使わないのに動いているものがある → 無駄なコスト発生
- ここもテーブル定義がまとめられていないから手探り状態
- 誰が何のために作ったデータかがわからず消せない

こうした問題があるだけでなく解決するための壁も多く
- データの社内活用のPJがほぼ動いていないため重要性も薄れている
- データ基盤を見ている人が私だけで頼れる人がいない
- 別会社のDBとの関連もありコミュニケーションに時間がかかる
- 新卒の私だけで決められない問題が多い

と当時は絶望していました笑笑

# 解決策
問題については①重要度の高さ②リスクの大きさ③変更や処理の容易さをベースに優先順位群を作成しました。

1st phase(兎に角"やばい"を排除するphase)
1. サーバーをmacmini環境から脱却する(リスクが大きい)
2. Bigqueryに溜まっている無駄なデータやscheduled Queryを削除(ビジネスインパクトが大きい)

2nd phase(理想状態に近づけるphase)
1. DWHやDLを再構築
    データソースがAWS上にあるため、DLやDWHをAWS上に置いておきたい(転送コストの減少)
2. データテーブルなどのルールを設定
3. ETLの再検討
4. データ活用アクションの設定
5. テーブル定義書の作成

3rd phase(最適状態を作り出すphase)
1. 元データ格納DBのリプレイス
2. CI/CDの構築

# 得た知見
このPJ(まだ終わってませんが笑)を通して沢山のことを学びました。
ここでは皆さんにお伝えしたい部分だけ紹介します。

- 誰が何のために使う基盤なのかは絶対に考えるべき
    DWHやDLの選定をする際にそれぞれの特徴はあるものの、結局どれにする？が分からずじまいでした。使うのは営業の人も含めるのか、アジリティはどれくらい求めた方がいいのか等は、考えておくと今後本当に楽になります。
- レガシーシステムは短期的な視野を想定しない方がいい
    解読に時間がかかります。
    私の場合ドキュメントがない + 担当者もいない状況だったので、"誰に聞けばいいの？", "これってどういうこと？"がたくさん詰まっているレガシーシステムでした。
    刷新前の解読の時間が異常にかかるのでこの時間を最初にたっぷり取った方がいいと思います。
- IaCの偉大さ
    AWS Cloud Development Kit(CDK)を使っているのですが、IaCを最初にしておくと環境のリプレイスが異常に簡単でした。
    初学者でもわかったのでCDKおすすめです！
- 兎に角いろんな人を巻き込むことが大事
    自分一人だと出来ることが制限されていたので上司や他部書のインフラ関連の有識者を巻き込むというのを続けました
- 説得のための会議かブレストのための会議かをはっきり分ける
    最初にはっきりしておかないと、下記のような事象が発生するので決めておいた方がいいと思います。
    ・会議中に説得できず次回に持ち越し
    ・意見がまとまらず次回に持ち越し
- 外部コミュニティに積極的に参加
    理想状態がどうなのかを考えるには視野が狭いと感じたので積極的に外部コミュニティに参加しました。自社を知らない第三者の意見が貰えるのは自分の考えを整理するためにも非常に重要でした。

# 今の状態と今後の展望
今は1st phaseが終わって2nd phaseでまだ苦労しているところになっています。
ちなみに2nd phaseではこのような構成にしようと思っています。
![スクリーンショット 2024-12-12 9.49.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3680837/4b86a67d-df56-2a70-6bb9-62d36a5895b6.png)

ここ最近は頼れる先輩方も入社してきて進めやすくはなっていますが、
まだまだ途中なので頑張ります！

# 最後に
新卒で同じような状況にいた方の励みや学びに繋がれば幸いです！

まだまだ時間がかかる作業なので、また新しい苦労や発見が出てきたら適宜発信していこうと思います。
これからよろしくお願いしますー！