peepcode-code-review.pdf

Code

Review

Improve the quality of your code

by Geoffrey Grosenbach

Ruby on Rails

contents

Store Sessions in the Database

45 Don't Store Objects in the Session

Use Custom Configuration Files

49 Avoid Heavy Response Processing

Use Constants for Repeated Strings

54 Use ActiveRecord Mailing

Keep Time in UTC

60 Monitor Your Servers

Don't Loop Around ActiveRecord

67 Don't Cut Costs on Hardware

22 Beware of Binary Fields

Test-Drive

26 Cache Your Reports

78 The Rest of the List

Store Country Lists

80 Revisions

34 Avoid Bloated Controllers

38 Keep Your Controllers and Views Skinny

introduction

Writing better code starts with the basics. The tips in this book aren't

the kind that will help you win awards. They're the kind that will keep

you from being ired, or from inadvertently writing code that cuts

your site's performance in half.

I've read through the code of both proprietary Rails applications and

open source projects. All the concepts you see here came from real-

world examples (but variable names have been changed to protect

the innocent). Some of the examples, I'm afraid to admit, came from

my own code.

You won't be able to follow each chapter as a complete project from

start to inish. I've assumed that you already have a project in pro-

cess that needs to be tuned, so treat these as a collection of good

ideas that will need to be customized for your application.

The good news is that most of these tips are easy to implement.

You'll get into the habit of switching your timezone to UTC, setting

up database tables for sessions, and installing the exception_noti-

fier every time you write a new Rails application. Once you've been

developing an application for a while, you'll look forward to running it

against ruby-prof or setting up good monitoring tools.

Although it may be embarrassing to buy a book targeted at begin-

ners, it will save you from repeating the beginner's blunders. If you

run into a problem that isn't listed here, I'd be glad to include it in a

future edition of this book. I'll understand if you say that it was really

the developer in the cubicle next to yours who wrote that awful code!

Geoffrey Grosenbach, August 2007

Store Sessions in

the Database

chapter 1

the wrong way

By default, Rails stores user sessions on the ilesystem.

This is a quick, easy setup that requires no coniguration. In fact, you

could run a website with sessions even if you weren't connected to a

database.

Unfortunately, that party won't last long. Sites as prominent as A

List Apart ( http://alistapart.com) have nearly come to a crashing halt

because their hard drives illed up with thousands of session iles.

Disk-based sessions are also more dificult to maintain. You need to

write cryptic strings of shell commands to clear them out. You can't

easily use them with multiple application servers unless they can all

access the same hard drive.

the right way

There are several ways to store sessions, but database-backed Activ-

eRecord sessions are the most common. Memcached is also a good

way to go, but is better left for later stages of a site's growth when

many servers are being used. If your site runs on up to three servers,

ActiveRecord is the easiest and most eficient way to go.

It is often thought that Memcached is always

faster than ActiveRecord sessions. Not true! If

your database is on the same machine as your

application server, ActiveRecord will be as fast

or faster than Memcached would be.

First, generate the migration to build the sessions table in the data-

base.

ruby script/generate session_migration

Next, run the migration.

rake db:migrate

Finally, uncomment this line in config/environment.rb to instruct

Rails to use the active_record_store for sessions (you can put it all

on one line):

# Use the database for sessions instead of the file system

# (create the session table with 'rake db:sessions:create')

config.action_controller.session_store =

:active_record_store

The comments in environment.rb tell you to create the

sessions table with the db:sessions:create rake task. This

generates the same migration ile that the generator does, but

oddly does not run the db:migrate task to create the table.

For maintenance, the following tasks are useful. Create a ile in lib/

tasks/sessions.rake with these contents:

namespace :sessions do

desc " Count database sessions "

task :count => :environment do

count = CGI::Session::ActiveRecordStore::Session.count

puts " Sessions stored: #{count}"

end

desc " Clear database-stored sessions older than two weeks "

task :prune => :environment do

CGI::Session::ActiveRecordStore::Session.delete_all [

" updated_at < ? ", 2.weeks.ago

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: