http://www.slideshare.net/tricknotes/rails-possiblestory
ここに記載されているのはRailsどうのでなく設計の問題なので、これを「Railsのあるある」という人は、他の言語やwebアプリのFWでもまた同じ間違いを犯ちゃうのでは疑惑。
1.社員レコードは論路削除で…
問題の原因は、モデルの状態遷移・各状態で機能がどう振る舞うかを検討せず（設計をせず）に実装にとりかかってることでは。
やるべきだった手順
- 現実世界での対象モデルの状態を整理する
- 内定、有効、休職傷病、産休、退職、一時退職（役員とかになる場合の）とか？
- アプリケーション内で定義すべき状態を整理する
- （社員だと、権限に関わるのでそれに関係しそうな状態を整理する）
- {準備, 有効, 休職, 退職, 無効, ロック}とか？
- 最適な実装方法を考える
- 状態を管理する属性をモデルに持たせる。
- AASMみたいな状態管理用プラグインもある
- 実装する
2.ブログ記事にタグをつけたい。
これはマジで検索できない上にタグのデータが正規化されないので普通にテーブルつくるべき
3.一時保存のときは入力チェックをしたくない
「会員」というモデルが
- 仮登録状態ではメアドがあればvalid
- 本登録状態ではメアド+名前+etc,があればvalid
と考えると状態でvalidationをわけるのが妥当というか第三者がコードをみたときにわかりやすいのかもしれない。モデルをわけるのもあるかも知れないけど、めんどくさそう
「他のシステムと連携するためのJSONのAPIを提供したい」
連携の要件がわからんので割愛（発表の場にいたわけではないので）