# 2022/04/16 メンター相談

###### tags: `メンター相談`

## 「冗長化されたWebアプリケーションを作ってみよう」の課題で、target groupに設定するのはパブリックサブネット/プライベートサブネットどちらのEC2インスタンスにするべきでしょうか？

- 踏み台の役割
- PrivateサブネットのEC2インスタンスの設定を変更したい
- 　一方で、sshはシェルを実行できてしまうため、危険
- 　そのために、ある一定の場所からしかsshできないようにするために踏み台サーバがある
- bastion（踏み台）
- 中世ヨーロッパに実際にあった概念
- ジャンプサーバーともいうらしい

## 「冗長化されたWebアプリケーションを作ってみよう」の課題で >アクセスするたびに表示されるサンプルページがランダムで変わるはずです とありますが、シンプルにALBを作成してtarget groupに2つのEC2インスタンスを登録すると、ランダムではなく交互にページが表示されました。これは期待する動作ではないでしょうか？

- 交互に表示されるのが期待した動作なので問題ない
- デフォルトのアルゴリズムはラウンドロビン
- https://aws.amazon.com/jp/about-aws/whats-new/2019/11/application-load-balancer-now-supports-least-outstanding-requests-algorithm-for-load-balancing-requests/

## テーブルのカラムの「デフォルト値」はどのような場合に設定しているでしょうか？

- 松原さんはDBに設定しない派
- DBは見つけづらいから
- デフォルト値はドメイン知識である場合が多いのではないか
- なのでアプリケーションに持たせたほうが良い
- デフォルト値を入れるメリットがあまり見つからない
- 未選択の人は99のようなクエリを書くとき（case文）、その値が色んなところに散らばる。grepも使えない。
- デフォルト値があるとエラーに気付けない
- 空だといけないのに間違えたときに気づけない
- バッチを誰かが作ってて、不正データなら失敗するだろうという前提で作られているときに、デフォルト値があると失敗しなくなってしまう
- DBに設定したい派の意見
- 慣例、、、
- DBのデフォルト値はSQLアンチパターンの「恐怖のunknown」に近い

## 「チーム名は重複不可」のようなユニーク制約をアプリケーションに設定した方がいい場合、しないほうがいい場合はあるでしょうか？

- トレードオフになるから、観点次第
- 呼び出す頻度
- 頻度が低いなら、アプリケーションでやってもいいのではないか
- 重複確認したあとのプロセス
- 3つくらいAPIを叩くと非同期で並列で叩いても時間がかかると思う
- 副作用があるAPIなら、ロールバックもあると思う
- それなら1回アプリケーションで重複確認を外すのもありかも
- 無駄にならないように事前にチェックしておく
- DBのUNIQUE制約は好きなときに確認できない
- 保存したい時にチェックしたいときは、アプリケーションでチェックする
- アプリケーションでもDBでも設定することはある？
- 両方やることが多いと思う
- DBにUNIQUE制約をつけないメリットは何かあるか？
- ドメインロジック上重複してはいけないなら、DBに貼ると思う
- アプリケーションはマナーで、DBはルール
- アプリケーションで書いたルールはいつでも破られる可能性がある
- DBのUNIQUEは絶対破れない
- 一時的に重複を許せる場合、UNIQUE制約はいらないときもあるかも
- 後でバッチで一気に重複を削除する場合など
- UNIQUE制約があると、エラーは発生する
- アプリケーションとDBで、同期を取るのが大変だけど、、
- ヒューマンエラーを防ぎたいから、DBは必須だと思う
- その上で、アプリケーション側で特定の処理を実施したい場合に、アプリケーション側でも制約をつけるべき
- 重複する確率
- これが高いなら、アプリケーションで確認することもある
- 低いなら、アプリケーションではみないと思う
- 例えば、チームの追加
- DBに全てのルールを書いてある場合、アプリケーション側のデメリット
- DBからの例外コードを読み解くロジックが増える
- 「xxxコードは重複エラーだから、yする」
- レポジトリからの重複例外をキャッチするロジックの中で、save
- catch節に正常系が紛れる
- アプリケーションで重複チェックする場合、どこにロジックを書くか
- リポジトリ？
- 基本リポジトリはシンプルにしたい
- リポジトリのテストは時間がかかるから (統合テストになる)
- 複雑なロジックのテストはさらに長くなる
- リポジトリはlistを操作するような処理にとどめる（By松岡さん）
- add,removeくらい
- ここで重複チェックまでやるのはドメイン知識が漏れている
- エンティティをORMに渡して保存するだけのものになる
- ユースケース？
- 他のユースケースを実装している人が、重複チェックを忘れてしまう可能性がある
- ユースケースはドメインサービス、ドメインのロジックを呼び出すだけのシンプルになる事が多い
- ドメインサービス ← ここでやる
- 保存までやってしまうことが多い
- 重複チェックだけだと呼び忘れのリスクがあるため
- 特定のドメインサービスからのみリポジトリのメソッドを呼び出せるようにする、という松岡さんの実装をよく使う
- ドメインサービスの存在を知らない人がリポジトリのメソッドを呼び出そうとしても呼び出せない
- https://little-hands.hatenablog.com/entry/2021/03/08/aggregation#%E3%83%A1%E3%83%AA%E3%83%83%E3%83%88%E3%83%87%E3%83%A1%E3%83%AA%E3%83%83%E3%83%88
- DBのUNIQUE制約だけで表現できるとは限らないから、アプリケーション側でチェックすることはある
- アクティブユーザーとノンアクティブユーザーのテーブルがあって、そのテーブル間での重複を許さない場合
- joinしないと重複有無を確認できない

## その他

- 朝すぐに起きる方法
- ラジオ体操をする
- 陽の光を浴びる (手のひらにも)
- カーテン自動で開けるやつ
- モーター音がうるさい
- カーテンの重さによっては動かない
- 目薬をさす
- 目が乾いているから眠く感じている
- 天窓
- https://www2.panasonic.biz/jp/lighting/shop/effect-projector/skylight-vision/
- アレクサに自動で電気をつけてもらう
- 眩しい
- 睡眠アプリを使う
- Sleep CycleとPhilips Hueを連携すると徐々に明るくしてくれる
- 夕方にサウナに入る
- 夜眠くなれる
- スマホ依存症をやめたい
- PCで何でも出来ちゃうからPCを見る
- ニュースアプリ, SNS, Zennなど
- 不便なスマホを買う
- 目を閉じる
- 音だけで楽しむようにする
- 目はアイマスクで隠す
- ネットを遮断する