バックエンド
設定関係
settingslogic使うのやめて、最近のRailsだと標準で使えるconfig.xを使う。
S3に画像アップロード
carrierwave + fogの構成だとawsのAPI叩くのをfog-awsで独自実装していて、carrierwave-awsだとaws本家が作ってるaws-sdkを使っているので、fog使うよりcarrierwave-awsを使うのがお薦め。
テスト
- rspec-rails
- factory_girl_rails
- capybara
- poltergeist
- database_rewinder
よく使うのはこの構成。
DBの不整合を防ぐのにやること
- 外部キー制約
- not null制約
- unique制約
アプリケーションレイヤーのバリデーションだけだと、正しくバリデーションされないケースがあってdbの機能も使ったほうがいい。
中間テーブルの命名規則
モデル名の複数形_モデル名の複数形
例
userとpostの中間テーブルの場合
bundle exec rails g model users_post
そうするとdbから見たテーブル名はusers_postsになる。
HMBTは使わない
モデルとしてマッピングされていたほうがrails consoleから操作しやすいので
フロントエンド
gem
- haml-rails
- scss-lint
- rails-assets-react.js
- rails-assets-flux
- sprockets-es6
RailsのView
hamlで書く。erbと比べて、hamlだと閉じタグ書かなくて良かったり短く書ける。
CSS
scssで書く。CIにscss-lintを組み込んでコーデングスタイルだったり重複などのチェックする。
規約はSUIT CSSを使う。
JavaScript
React + Fluxの構成でES6。
jsプレフィックス
JavaScriptから操作するjs-というプレフィックスを付けることでデザインのHTMLの構造が変わった時に壊れないで済む。
Reactを使った場合はstateのデーターを元にVirtual DOMが勝手にレンダリングするので自前でDOM操作をしないといけないケースはあまり無さそう。
Coffee Scriptを使い続けるべきか?
ES5の時代は言語的に足りない機能があってCoffee Scriptだとその機能があったので使ってた。
最近ES6が使えるようになってきて、その辺が改善されたのでCoffee Scriptの役目は終えたかなという印象。
ES6はJavaScriptの標準だけど、Coffee Scriptは標準じゃないのは大きいと思う。
サーバー
AWS OpsWorks
AWSで提供してるレシピが使えるのは良いところ。
CircleCI
自前でCIサーバー立てると管理が大変になるので。