# 2022/05/21 メンター相談

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

## 「ログの取り方を学ぼう」の課題で、"パースしやすいメッセージを作ることも大切"とありますが、webアプリフレームワークやロギングライブラリに任せておけば、それなりにパースしやすいログメッセージになるような気がします。実際の開発において、パースしやすいログメッセージになるように気を遣うべき場面はあるでしょうか？

- あえてパースしやすいように気を使う場面あまりない。基本的にライブラリに任せればよい。
- (松原さん) ログレベル多すぎると思っている
- 多すぎて混乱する
- debug, error, infoくらいしか使ってない
- SLA(Service Level Agreement)を決めるときの判断で使いづらくなるので、多すぎないようにしている
- (気をつけていること) 処理の中でconsole.logを書かない
- 消し忘れが怖い
- useLogなどの中にログライブラリへの依存を閉じ込めて、それ経由でlogを使用する
- Lintの設定で[no-console](https://eslint.org/docs/rules/no-console)を使う
- ライブラリ使う時に気をつけること
- 一部のプロパティをマスクする
- bunyan
- passwordというフィールドは必ずマスクするとか
- 第一引数と第二引数を間違って渡しても、それっぽいエラーメッセージができてしまう
- https://medium.com/swlh/bunyan-logging-with-production-troubleshooting-in-mind-f91235f00bc3
- 使うログライブラリの使い方を間違えないように
- ログするときに間違って秘匿性の高い情報を出さないようにあらかじめ設定しておく
- セキュアバイデザイン
- read once object
- getterを通して値を取得したら、元の値をnullにする
- 認証に関わる情報など、機密性の高い情報がlogなどに紛れ込まれないようにする
- getしただけで、中の値が変わるというのは、自然ではないので、そういう挙動は他の人が予測しづらいという副作用あり
- ログメッセージ
- elm
- エラーメッセージがていねい
- もしかしてこれやりたかったのでは？を教えてくれる
- https://elm-lang.org/news/compiler-errors-for-humans
- 松原さんも、丁寧にログメッセージを書くように気をつけている
- 同じログを何度も出す
- オニオンアーキテクチャなどの各層でエラーをcatch->再throwする場合
- 何度も同じエラーがログに出てしまう可能性がある
- 同じエラーを何度も出すことで、何度もエラーが起きているように見える
- ログをとる層を決めた方がいいのかも？
- 質問
- パースするならJSONがいいよというのを見るが、本当？
- JSONのほうがfilter細かくできるので、便利
- ログメッセージは英語？日本語？
- 文字化けが怖いので英語にしている
- ログメッセージの多言語対応したことない
- read once object
- 言語の機能とかではなく、自分で作る
- https://github.com/azu/read-once

## expand and contract patternで元のスキーマから新しいスキーマにデータをコピーするとき、どのような手段でやるのが良いでしょうか？

- migrationの時
- migrationファイルの中に、コピーするスクリプトを用意して、testまで実施する
- 怖いので、直接sqlを実行したことはない
- このパターンでいいのはすぐに戻せること
- feature toggleがあった方が安心
- expand and contract patternで注意したほうが良いこと
- 古いデータ・スキーマをすぐに消さない (何かあったときに戻せるように)
- 目安として、1ヶ月くらいは両方のスキーマに書き込む方が安心
- 手順書を作っておく
- 実行することを1つ1つ細かく書く
- 他のエンジニアに手順書をレビューしてもらうとより安心
- 金曜の夜にやらない
- prismaのドキュメントが丁寧だったので参考になるかも
- https://www.prisma.io/dataguide/types/relational/expand-and-contract-pattern
- 質問
- どれくらいの期間をかけてやる？
- 切り替えてから1ヶ月様子見した
- 手順書作成+マイグレーションでトータルでは1ヶ月半くらいかけた
- すぐにもとに戻せるなら、もっと短くても問題なさそう
- feature flagはアプリケーション側のenvファイルで保持してる？それとも別の場所？
- （kubota）「システム運用アンチパターン」という書籍では、DBに保持する方法が紹介されていました。flag名のカラムとtrue/falseのカラムのセット
- (furukawa)アプリケーション側で保持すると、いちいちデプロイが必要で、
- (matsubara)redisなどのDBで保持する

## 収集しているメトリクスは、どのタイミングで確認しますか？特に、エラー発生時以外に、チームとして「いつ」メトリクスを確認しているのかが気になります。
- 毎朝の朝会で確認
- ビジネスKPI
- 月1回くらいの頻度
- 開発者側
- 毎日
- 昨日のエラーがどれだけ来てたか、などをみる
- エラーとしては出てこないけど、会員登録したのにいいねが一個もないとか。
- リリース直後は頻度高いと思う

## プラハさんに全ての決定権がある場合、モニタリングのツールは何を選定しますか？選定基準も併せて教えていただきたいです！
- バックエンド
- AWSならCloudWatch一択
- セットアップがいらないので楽
- フロントエンド
- Sentry
- エラーの時のログが丁寧
- エラーにたどり着くまでのユーザーの行動も細かく教えてくれる
- Slackへの連携もやりやすかった
- Logrocket
- ユーザーの操作が動画でわかる (らしい)
- プラハでも入ってる
- テックブログがめちゃくちゃいいので読んでて勉強になる
- https://blog.logrocket.com/
- セキュリティ面。マスキングなど勝手にしてくれる？
- data privateというattributeを加えるとlogrocketには送らないように設定できる
- 開発者がマスキングの設定をする必要がある
- ログのツールあるある
- 流行の移り変わりが激しいから、松原さんとしてはこだわりがない
- ドキュメントが充実しているか、価格
- コストは運用するお客さんが負担するので
- 選定基準
- セットアップが楽かどうか
- Hook系のセットアップが楽かどうか
- コスト

## feature flagの分岐がアプリケーション側に残ったままになる事象はどのような対応をしている？
- feature flagを消すDraft PRを作っておく
- feature flagを消すチケットを作っておく
- 「Engineers in VOYAGE」
- いらないコードを消すリファクタリング

## IME何使っていますか？
- Google日本語入力
- たまにおかしくなる
- mac標準の変換がおかしい
- 全然違う単語に変換される
- リセットすると治るらしい