アプリケーションを設計するときに注意しないといけないことをまとめておきます。
- APIの戻り値としてjsonを渡すことが多いけど、jsonはダブルじゃないといけない。
- JavaScriptの文字列はシングルでもダブルでもどっちでもいい。統一さえしておけばいい。
- HTMLタグの属性はシングルでもダブルでもどっちでもいいが、ダブルが推奨。jsonでHTMLタグを渡すときは、ダブルだとエスケープできないのでシングルで書く（tword-frontend）
- ちなみにScalaではStringはダブルで、Charがシングル。
DB設計はモデルやパフォーマンスと直結するので、開発の初期段階に綿密に設計しないといけない。 リリース前にDBの設計変更とか泣けるので。。 なお、DB設計時には、運用後に想定される状況を明確に想定しておかないといけない。
製品リリース後にデータベース構造を変更すると、DBをALTERしなければいけないので辛い。 やったことなんですけど、この話はよく聞く。
アンチパターンのトップバッターとして取り上げられるほど有名な命題だけども、 実際のところはシンプルな設計をしていることが多いようですね。
要件を満たせるうちは、シンプルな設計を採用する方が良いと考えています。必要になったら閉包テーブルや入れ子集合に移行すれば良いですよね。
正規化しちゃうと結合に時間かかるじゃん。
バッチ処理中にDBがロックされてアクセスできないケースが発生しないように、 バッチ処理で頻繁にアクセスするDBはテーブルを分けておくとよろし。
スペック的に必要なの？そこまで求めないの？ Play Frameworkだと、hikariPCとか使えばいい。
開発段階ではオンメモリー。本番環境ではファイルに保存かサーバー建てるか。
ConfigをDBで登録しているような場合、開発時に必要な設定、本番環境では初回起動時に一回しか使わないであろう処理（DBはマイグレーションするから）はどう扱うか問題。
失敗するときは、可能な限り早い段階で表示させる。 「AやってBやってCまっでやって失敗」とか泣ける。
ユーザに見せるエラーメッセージは、「ユーザが次に何をすればいいのか」を書いておくこと。 エラーが起きてる現象について説明されてもユーザーにはno infomation。
エラーメッセージのリソースは大抵一箇所で集中管理しているので、 共通化したりして状況にあわない雑なものになる傾向がある。 また、編集者によって表現のばらつきが大きくなる傾向がある。
i18n等を使う。 できるだけ、英語から書き始めること。 リリース直前でテンパってるときに、日本語なら工数よめるけど、英語だとよめないから。
圧縮問題。
小さく作っておいた方が、互換性がなくなったときに対応しやすい。 規模が大きくなると、あるところのバージョンをあげると、他のところのバージョンが合わなくなったりして辛い。
http://mtdew2.com/2015/10/04/compress-html/
圧縮問題