As the Rails application scales to more Heroku dynos, a lack of concurrency can result in [poor performance](1) and an over-provisioning of resources. Modifying the app to handle requests more efficiently is a simple process with immediate benefits. Unicorn is a [concurrent web server](2) that spawns several processes within a single dyno without requiring concurrency or threading awareness in your app. Applications that migrate to Unicorn often require fewer dynos and see increased performance. The [config/unicorn.rb file](3) specifies the number of concurrent web processes to run on each dyno as well as the proper forking and termination behavior.  https://blog.heroku.com/archives/2013/2/16/routing_performance_update  https://blog.heroku.com/archives/2013/2/27/unicorn_rails  https://devcenter.heroku.com/articles/rails-unicorn#adding-unicorn-to-your-application
Including FactoryGirl in the development environment ensures that factories get created when default generators are used. Adding FactoryGirl to development also provides factory functionality when in the development console.
* Use recipient_interceptor gem. * Use the Mail gem's interceptor feature. * Separate SMTP from intercepting responsibilities. * Set up SMTP for production and staging. http://robots.thoughtbot.com/post/40822987615/delivering-all-email-from-staging-to-a-group-email
Use Zeus, Commands, or Spring instead: https://github.com/burke/zeus https://github.com/rails/commands https://github.com/jonleighton/spring They are superior to Spork for the following reasons: * You don't have to commit anything into your Gemfile, spec/spec_helper, or version control. * They improve the Rails bootup speed of rails server, runner, generate, console, and rake tasks... not just tests.
* We use `body_class` and `page_title` view helpers in the application layout, which come from Flutie. * We had previously removed Flutie because Flutie 1.x included lots of styles which have been superceded by Bourbon/Neat/Smash. * Flutie 2.x is just the view helpers and we think `body_class` and `page_title` are valuable.
* Web requests should be typically processed in no more than 500ms, and ideally under 200ms. * Even though an error page will be issued to the client, and the connection terminated, when a timeout occurs the web process is still left to process the request. Subsequent requests may then be routed to the same process which will be unable to respond, causing further degradation. * rack-timeout ensures processes don’t remain tied up after 5 seconds of inactivity. * This also makes it less likely that a user sees a timeout page and the change they were trying to make actually went through (ie, their credit card is charged but they see a generic error page). https://devcenter.heroku.com/articles/request-timeout
Provide fewer options and more opinions: * Add assets group to Gemfile. * Add jQuery to Gemfile. * Add Postgres to Gemfile. * Add Rails to Gemfile. * Add Strong Parameters to Gemfile. * Alphabetize existing gems. * Make Capybara Webkit a default. * Remove Clearance. * Remove Flutie. * Remove Paperclip. * Replace Formtastic with Simple Form. * Specify minimum version of Capybara Webkit. * Specify minimum version of Rails.
This will be the Rails 4 recommendation: rails/rails@009873a * Include `-e $RACK_ENV` in `Procfile` per Heroku docs. * Make bin/setup idempotent by only copying `.sample.env` to `.env` if `.env` file does not exist yet. Prevent users from accidentally overwriting the file, which is not kept in version control. * Change `sample.env` to a `.sample.env` so it shows less often.
This forces us to use [RSpec's expectation syntax](http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectation-syntax) with the `config.syntax = :expect` setting. The reasons to do so include: * Style: it highlights the verification phase of the Four-Phase Test well by starting each line with `expect`, wrapping the outcome in the parentheses. * Consistency across RSpec specs. * Consistency with Jasmine. * Avoids weird, confusing errors when testing delegate/proxy objects. * Avoids Ruby warning with `should ==`.