Historical errata for Agile Web Development with Rails

At the bottom of page 9, you say “the good ideas of the past are frequently by the present.” Is this a typo, or just an idiom that I’ve never seen before?

On the “Beta Book” page:

“end up with a strange shaped farm implement”

should be “strangely shaped”

And thanks for implementing the beta program.

“a tutorial and a details guide” should probably be “a tutorial and a detailed guide”

“Eventually the action prepare information for the view which” should probably read “Eventually, the action prepares information for the view, which”…

“This that are easy to express” should read “Things that are easy…”

WORDLIST.find(:all) should be WORDLIST.find_all

In section 3.2, “Installing on Mac OS X”, item one reads: “OS X version 1.4 (Tiger)” but should probably read “OS X version 10.4 (Tiger)”

The section on the Cart could use more reminders that it is not an AR model. The @items instance var. looks very similar to one, leading to confusion when methods like find are called with totally different behavior (taking a block instead of id, conditions, etc.)

The David Says could give a couple of examples to make it clear why the _at and _on suffixes are a nice & natural convention. The referenced page 268 doesn’t cover it.

Transactional fixtures do not assume you preloaded your fixtures. Rather, the fixtures are only loaded once and transactions isolate each test, obviating the need for constant fixture reloads. If your database supports them, transactional fixtures are almost always a good idea.

The environment is used to look up a database connection, but database connections are not required to be named after an environment. Consider configuring an auxiliary_foobars_dev connection then doing Foobar.establish_connection :auxiliary_foobars_dev in environment.rb.

Supporting multiple database configurations is easier with aliases within database.yml.

development: development_mysql
development_mysql: …
development_sqlite: …

Then you can use the same environment and swap out the target database.

Breakpoints with script/server were so much nicer when DRb was not required, since they’d drop into irb in the same shell you started the server in. Having to juggle a bunch of shells really reduces its elegance. Likewise for unit tests — I turn off remote breakpoints in test/test_helper.rb with Breakpoint.deactivate_drb. You can do the same in script/server. (Well, we tried, but it no longer seems to work…)

In the David Says, s/boundries/boundaries

Nitpicking, but MySQL does not support bool directly: it’s sugar for tinyint(1).

Single-sentence footnote is oddly split between two pages.

Similar suggestion for the Customer.establish_connection(hash_of_options) call — you can pass a hash or set up a customer-dev, customer-test, etc in database.yml then do Customer.establish_connection “customer-#{RAILS_ENV}”

Mentions transactions as a solution to concurrency problems, but they are not. Row locking (SELECT … FOR UPDATE) within a transaction is. Introduce this approach as pessimistic locking. It doesn’t work with the web you can’t reasonably keep transactions open between page render and form submission. Thus, track version numbers or time stamps to ensure we have current data: optimistic locking.

The discussion of object transactions makes them sound great. The big disadvantage is that you usually want them in the bad state so you can present errors. In fact, you lose the objects’ validation errors entirely if you use object transactions!

composed_of implies that you use a Class for the :class_name option rather than the string ‘Class’

Callbacks were introduced earlier as “hooks.” It’d be nice to let the reader know they’re the same thing.

Now called callbacks throughout

Callback blocks take the model instance as a parameter: after_create do |order| logger.info “Order #{order.id} created.” end

ActiveRecord::Base.timestamps_gmt is deprecated. Use ActiveRecord::Base.default_timezone = :utc

First paragraph, second to last phrase, typo: “— in
ddevelopment mode.”

Paragraph that says:
If you use :include, you’ll need to disambiguate all column names used in other parameters to find( )—prefix each with the name of the table that contains it."

That paragraph is followed by this code, which introduces the “:conditions” limit on the query.

for post in Post.find(
:all,
:conditions => “post.title like ‘ruby’”,
:include => [:author, :comment])

1. …
   end

Probably the first line should read “If you use :conditions, you’ll need to…”

It’s actually right as it stands, but I’ve added a sentence to clarify

The render_* methods are deprecated; they have been consolidated into render.

The redirect_to_* methods are deprecated; they have been consolidated into redirect_to.

The cookie :expires option doesn’t mention that the expiry isn’t recalculated per-request. If the user is on the 29th day of their session and still active on the site, their cookie will still expire the next day. To keep expiry 30 days in the future a before_filter should be used to update the cookie or keep a :last_accessed key in session (better). Nitpicky, sorry..

Explain why the model declaration is needed (so the class is loaded when the session is rehydrated.) Also, stored object must be serializable for the default PStore session store and for DRbStore; for FileStore they must be strings; for MemoryStore they can be anything; and for ActiveRecordStore they must be YAMLizeable. The warning against volatile data is violated in the Depot app: it uses session[:user] instead of session[:user_id].

There is a nice way to set session options: passing them to the dispatcher. But the hacky way (DEFAULT_SESSION_OPTIONS) is easier to manage since it can live in your environment.rb.

This would open up a fairly big can of worms, in that I currently take the dispatcher for granted. I think I’ll punt on this one…

The David Says… box reads “The add_to_card() shows…”, it should be “The add_to_cart() shows…”

First paragraph, last phrase should be “The flash data is stored in the session…” and not “store”

This won’t work with a streaming send_file call since it sets response.body to a block that handles chunked file transfer.

The 3rd paragraph (right after the chunk of code) reads “In the handler we use use the Rails logger…”. Note the repetition of the word ‘use’.

The first bullet “the field’s title, description, …” should be “the fields title, description, …”.

s/business logic in there.SOmetimes/business logic in there. Sometimes

“Save the hello.rhtml and refresh the browser window.”

I think you may have forgotten the word ‘file’ in that sentence: “Save the hello.rhtml file and …”

XMLHttpRequest vs.