個人的メモ:Rails AntiPatterns(21):最後
CHAPTER10 Building for Failure
- 発生した障害は素早く復旧される事と、黙って失敗しない事が大事
AntiPattern: Continual Catastrophe
- 前段の処理が失敗しているのにも関わらず、それをキャッチ出来ずに後続処理が動いてしまうのはよくない。
Solution: Fail Fast
- 複数の要素の変更を途中まで処理したが何かしらのエラーが発生したので中途半端な状態で処理が止まってしまう形にしてはいけない
- 処理前にすべての要素の変更が行えるかを確認する事。
- 一貫したユーザエクスペリエンスを心懸ける事。
AntiPattern: Inaudible Failure
- あるエラーを補足する為に他のエラーを丸め込んでしまっている状態はよくない。
Solution: Never Fail Quietly
- 明らかにシステムエラーにするべき物については静かに失敗しないように明示的に例外が出るようにする。
- システムエラーが発生した場合は、ユーザにそれを通知するとともに、内部的な監視システムへもそれを通知するようにする。
- ログ監視ツールとしてはHoptoadがメジャーだが、exception_notification,Exceptional,NewRelicRPMと言った物もある。
- ★あとで詳しく調べる。
- ログ監視ツールとしてはHoptoadがメジャーだが、exception_notification,Exceptional,NewRelicRPMと言った物もある。
- 例外と負の戻り値は無視しては行けない。エンドユーザと監視システムの両方に通知すること。
おしまい
感想
Rails Anti意外と時間かかったが、夜(たまに朝)の通勤時間のみで2ヶ月位で読みきれた。Rails3の頃の情報なので色々と情報が古い面もあるが、参考になる面も多かった。
ブログにメモ書き残したのは一部だったけど、今度何か読むときはちゃんと記録したい。
あとで調べるになっている所はなるべくキャッチアップして置こうと思う。