Building Web Apps with Rails 2 - Plugins and Conventions I Use

Peter Marklund

marklunds.com

Motivation and Background

• Rails best practice is a moving target
• Following best practice vs leading it - following conventions vs innovating
• Rails is opinionated but leaves many decisions open
• With plugins we can raise the level of reuse. How high should we raise it?
• Let's discuss alternative solutions to common problems

Documentation

• Use the RAILS_ROOT/README file as the documentation entry point
• Describe how to bootstrap and install the app including gem dependencies
• Include notes about how to deploy the application

Rails Source Code Version

• Specify RAILS_GEM_VERSION in environment.rb
• Alternative: invoke rake rails:freeze:gems to put the code under vendor/rails

Avoid external dependencies

Unpack gems that don't require c compilation under vendor/gems

Patches and Hacks

• Put all monkey patches of Ruby and Rails in config/initializers/ruby-patches.rb and config/initializers/rails-patches.rb
• If you want to patch the plugin foobar, create the file vendor/plugins/foobar_hacked/init.rb, see Chris Wanstraths evil twin plugin post

JavaScript Performance

Use javascript_include_tag(:all, :cache => true) in your application.html.erb so that JavaScript files are bundled in production for performance

Sessions and Authentication

• With Rails 1.X - use active_record_store with a cronjob for deleting old sessions
• With Rails 2.X - use the default cookie based sessions
• Use restful_authentication for authentication and registration. Change login to be with email instead of a username.

Configuration

• Try to keep config/environment.rb clean and use files under config/initializers instead.
• Use the app_config plugin for configuring your application

Make models implement the to_s method

• Makes interpolation into strings easier
• Makes creating links to objects easier, you can just say <%= link(article) %>
• I keep helper methods for formating dates and DRYing up show pages in my view_utils plugin

Internationalization

• Use the Gibberish, Gibberish Translate, and Simple Localization plugins
• Alternative: use the Globalize plugin

Timezones

• Traditional approach: keep UI in local timezone and everything else in UTC, see Rails Recipe: A Timezone Aware Datetime Picker and the timezone_attributes plugin
• New approach: keep database in UTC and everything else in local timezone, see Timezone awareness in Rails and What's New in Edge Rails

Routes, REST, actions and controllers

• Use scaffolding (REST) for your models
• Remove the default Rails routes
• Use a home controller for the homepage, static pages, and top level pages
• Create custom controllers as needed, i.e. for wizards

Skinny Controllers and Fat Models

• Avoid business logic slipping into views and controllers
• Keep actions short (i.e. under 10 lines)
• Use many small methods in your models with names that are intention revealing
• Use the presenter pattern to simplify actions
• Break overly fat models up into modules (see Henrik Nyhs post)

MySQL Configuration / Failing Early

• Use the mysql_requirement plugin to make sure MySQL is properly configured (encoding, version, c driver, and SQL mode) when the server starts up
• Another example of failing early: check that the db is migrated to the latest version in production

Use a Custom Environment for Staging

Create the file config/environments/staging.rb and add the db connection in config/database.yml

File Uploads

Use the attachment_fu plugin by Rick Olson. See Mike Clarks instructions.

HTML Validation and Link Checking

Use the HTML Test plugin to validate all the HTML your app produces and check for broken links, redirects, and forms.

Capistrano Tasks

• Use an update_dev_db task to update your development db with the latest production data
• Run a deploy:backup_db task before deployment (before_symlink callback)
• Run the tests on the production machine before deployment (before_symlink callback)
• Run a ping_servers task after deployment to see that all servers are up (after_deploy callback)

Use RSpec with Less Mocking

• Drive your development with specifications
• Write pending specs if you don't have time to implement them right now
• Use RCov to make sure you have 100% code coverage
• Skip the view specifications. Use integrate_views and don't stub out the database in your controller tests.
• Alternative: use Ryan Bates approach to mocking in controller tests.

Resources

• Rails 2.0 Announcement
• PeepCode Rails 2 PDF
• Advanced Rails Recipes
• PeepCode Rails Code Review PDF
• The Rails Way:
  • RailsConf 2007 Video
  • MountainWest 2007 Video