
明けましておめでとうございます。振り返りをしておこうと思います。

## 2022年

### プライベート
- ブログを作り直り直した
- 32 posts 書いた (今までに比べれば驚異的に多い)
- 子供が無事に3歳になった
- 8キロ痩せた

### 仕事
- Tech Lead & Engineering Manager という役割で何とか1年過ごせた
- php → node.js の移行案件を無事に乗り越えられた
- 負荷対策用のアーキテクチャ変更を無事に終わらせられた

### 買ってよかったもの

#### ヤマハ YAMAHA ゲーム/配信用オーディオミキサー ZG01

[https://www.amazon.co.jp/dp/B09WQN5QP2](https://www.amazon.co.jp/dp/B09WQN5QP2)

#### Elgato Wave Mic Arm LP 薄型デザインマイクアーム

[https://www.amazon.co.jp/dp/B097376LKF/](https://www.amazon.co.jp/dp/B097376LKF/)

## 2023年やりたいこと

### プライベート
- キッチンをリフォームする
- Rustをもう少し書けるようになる
	- 自分用に動かしてるツールをRustで書き直す

### 仕事
- Tech Lead & Engineering Manager を何とかこなしているだけの状態を脱出して何か成果を出す
- チームの成果 / マネージャーの成果 をどう測るのか自分の中で納得できる答えを出す

2022年の振り返り & 2023年の抱負


## 概要

ある程度大きなロジックを作る時、DDD(っぽい)ディレクトリ構成にすることが多いのだが、これまでよくやっていたパターンは DDD観点からみるとよくない気がしてきたので見直す。
試しているだけの雑多なメモかつポエム的なものなので、結論はない。

## これまでよくやっていたパターン

```text
domain
|---- models
|      |---- hoge
|      `---- fuga
|
|---- services
|      |---- hoge
|      `---- fuga
|
`---- repositories
       |---- hoge
       `---- fuga
```

このように model / services / repositories というプログラム的な役割で一階層切って、その下にドメインに該当するファイルを作っていた。ただこれだと、同一ドメインに関連するロジックが散逸してしまい見通しが悪くなっている気がする

## こうすればよかったのでは？

```text
domain
|---- hoge
|      |---- model
|      |---- service
|      `---- repository
`---- fuga
       |---- model
       |---- service
       `---- repository
```

プログラム的な役割で最初に階層を切るのをやめて、プログラム的な役割は末節の方に置いた方が収まりが良い気がしてきた。
Rust の `mod.rs` や TypeScript の `index.ts` 的なものをディレクトリごとに作れば、外部公開用のI/Fだけそこに定義するなどもできるので、依存関係の整理としても良い気がする

DDDのディレクトリ構成に関して最近考えていること


## TL;DR

* 正直者が馬鹿を見るルールを作ると誰も得をしない（当たり前）
* 囚人のジレンマは開発プロジェクトの運営にも関係がある

## 前提

チーム全体にコストが発生するような問題があるとする
それを解消するために、チーム全体に負担をかけるルールを新たに設定するとする。
（ルールを尊守するためのコストは問題発生時のコストよりは低いものとする）

新たなルールを尊守した場合と無視した場合をチームメンバーが2人だったと仮定してシミュレーションしてみる

## シミュレーション1：正直者が馬鹿を見るルールの場合

新たに設定するルールが正直者が馬鹿を見るようなルールの場合を考える。
正直者が馬鹿を見るルールとは具体的には以下の条件である

1. 2人ともルールを無視すれば、2人とも問題発生時のコストから逃げられない（コスト +3 とする）
2. 2人ともルールを尊守すれば、2人ともルール尊守のためのコストを負う（コスト +1 とする）
3. 片方がルールを無視した場合、ルールを **尊守した方** が2人分の問題発生時のコストを負わなければならない

|        |    A:尊守    |    A:無視    |
|--------|--------------|--------------|
| B:尊守 | (A:+1, B:+1) | (A:+0, B:+6) |
| B:無視 | (A:+6, B:+0) | (A:+3, B:+3) |

この場合、お互いにルールを尊守するほうがチーム全体のコストとしては低くなる。
しかしメンバー個人が自分の利益のみを追求している限り、ルールを無視するほうがコストが低くなりチーム全体のコストは下がらないという結果に陥る。
まさに [囚人のジレンマ](https://ja.wikipedia.org/wiki/囚人のジレンマ) と同じ状況になる。

## シミュレーション2：正直者が馬鹿を見ないルールの場合

新たに設定するルールが先程とは逆で、正直者が馬鹿を見ないルールの場合を考える。
直者が馬鹿を見ないルールとは具体的には以下の条件である

1. 2人ともルールを無視すれば、2人とも問題発生時のコストから逃げられない（コスト +3 とする）
2. 2人ともルールを尊守すれば、2人ともルール尊守のためのコストを負う（コスト +1 とする）
3. 片方がルールを無視した場合、ルールを **無視した方** が2人分の問題発生時のコストを負わなければならない

|        |    A:尊守    |    A:無視    |
|--------|--------------|--------------|
| B:尊守 | (A:+1, B:+1) | (A:+6, B:+0) |
| B:無視 | (A:+0, B:+6) | (A:+3, B:+3) |

この場合も先程と同じで、お互いにルールを尊守するほうがチーム全体のコストとしては低くなるという状況は変わらない。
メンバー個人が自分の利益のみを追求したとしても、ルールを無視するより尊守するがコストが低いためチーム全体のコストを下げることが出来る。


## 結論

* 正直者が馬鹿を見るルールを作ると、メンバー遠しの足の引っ張りあいが始まる
* ルールを作るは良いがよく考えて、正直者が馬鹿を見ないようにする必要がある


正直者が馬鹿を見るルールを作ることに対する弊害を囚人のジレンマで考える


http://letitcrash.com/post/30165507578/shutdown-patterns-in-akka-2  
を読んでのメモ
☆が付いてるのは所感
それ以外は記事の適当に訳してまとめたもの

# Shutdown Patterns in Akka 2

「すべての処理が終了したらActorSystemをシャットダウンするにはAkkaにどう命令したらいい？」

以下を議論する

* 「適切なタイミング」でシャットダウンするための簡単な方法
* 同じことをやるためのそれほど簡単ではない方法

## What the Heck Does “Finished” Mean?

* まず “Finished” をどう定義するか
* 「メールボックスが空になった時」（正確に言えば間違ってるけど）
    - まだメッセージを送信してないアクターがいる可能性があるから
    - 図のようにメースボックスの中身を全部飲み込んで処理中のやつがいたりするしね
* 一気のみするアクターが数百発生する確率は低い
    - ただ確率が上がるごとにそのアプリは終わりに近づくけどね
    - それが0.004%だったとしてもアルゴリズムをデザインするプラットフォームとしては疑わしい
* 「アクターが機能しているか知ることができるので、メールボックスがからじゃない時と機能しているときは停止しないで！」
    - そうはいうけどこういう時↓は停止したくないでしょ？
        + もしアクターが未来の作業を生成していたら？
        + 別のマシンの要求を待っていたら？
    - 逆にアプリを動作実態とは逆に"ビジー"に保つ単純な何かがいるとしたら永遠にアプリを実行し続ける？
        + ふつうやらないよね

## The DABOWoTeD Pattern（Do A Bunch Of Work Then Die pattern）

* 「房ごとに死んでいくパータン」
    - ☆DABOWoTeDの発音になんか意味があるらしいけど分からなかった
* 24/365で動いてるアプリはシャットダウン時の動きをそんなに気にしてないんじゃない
    - ハードウェア障害に対応するほうが頻繁だと思うし
* 仕事をさせるために幾つかのアクターを房にする
    - その仕事が「完了」している時がシャットダウンするとき

### Futures

* Futures はすべてが完了したのを知る簡単な方法
    - シーケンシャルに処理できる
* 基本的に大きなfork-joinをやってるだけ
    - すべてがjoin upした時にそのシステムをシャットダウンする

### Acotr

* “Finished”が明確じゃない
    - アルゴリズムにアクターが高いレベルで入り込んでいるから

### The Reaper

* 死神
    - アクターの死を監視するアクター
    - 監視しているアクター（図では緑）がすべて死んだ時システムを終了させる
    - 死んだアクターの通知をすべて集めた時、死神がシステムを終了に向かわせる


### Reaper Code

* Reaper自体は簡単、ActorRefを監視してそれらが死んだ時にキックするメソッドを作るだけ

### A “Production” Reaper

* 死神の簡単さから考えて、Production Reaperを作ることができる
    - すべての魂を集め終わったらActorSystemをシャットダウンするような

### Testing the Reaper

* Akka の テストキットを使ってReaperをテストする



## Application with PoisonPill

* Reaper はとても柔軟
    - あるゴールがメールボックスから排出される場合
* メッセージの束をアクターに送り、他のアクターにもメッセージが送られるシステムが有るとする
    - メールボックスからあるキーが排出された時にシャットダウンしたい
        + そういう時は PoisonPill メッセージを利用する
        + PoisonPill はActorのメールボックスに入り、やがてActorを殺す
            * 重要なのはPoisonPillより前に受け取ったメッセージはすべて処理されるということ
            * system.stpoを使ってActorを殺した場合にはそうならない
    - 最後のPoisonPillが処理されるとReaperがキックされActorSystemがシャットダウンされる
* ☆PoisonPillを受け取ったら自殺するようにActorを作ればいいのか

## Conclusion

* Akkaはあなたが何をやってるか知らない
    - しってるのはあなた自身だけ
* Reaperパターンはシステムに抽象レベルを設定するために使用された
    - Actorの基本的な機能を使用してアプリケーションに「システムレベル」の振る舞いを追加するための



ポエム

2022年の振り返り & 2023年の抱負

DDDのディレクトリ構成に関して最近考えていること

正直者が馬鹿を見るルールを作ることに対する弊害を囚人のジレンマで考える

Shutdown Patterns in Akka 2 を読んでのメモ