A few weeks ago I attended the Advanced Rails Studio, taught by Mike Clark and Chad Fowler. (Dave Thomas would normally be there as well, but he broke his arm and was unable to attend.) Mike and Chad are deeply knowledgeable and are natural teachers, making for an enjoyable and productive three days. I highly recommend this course to anyone who has been building Rails sites for a little while and wants to take their skills to the next level. It will be offered again in spring 2008; you can sign up on their site to be notified.

Inevitably, some of the material was review of things I already knew, but there were still plenty of things I didn’t know, or didn’t understand well, before the seminar. Perhaps the most valuable part was getting opinions and perspective from experienced Rails developers—not just the instructors, but other attendees as well.

Here’s a random selection of tips I wrote in my notes. These are probably not all intelligible from these brief descriptions, but they provide a flavor of the kinds of information I gleaned.

• Use a “test rig” file to generate standard CRUD tests.
• Use helper methods in tests and in views to keep your code at a consistent level of abstraction.
• Consider test/spec, which provides a BDD (behavior-driven development) layer on top of test/unit. Mike and Chad prefer this to rspec.
• Consider using simple Ruby hashes instead of fixtures. Mike has abandoned fixtures almost entirely.
• If you’re using the default resource scaffold, which allows xml access to models, override to_xml in the model so you can use the :except option to keep sensitive fields from getting included.
• Don’t bother with small RJS files; just put the RJS code in the controller.
• All the respond_to code and XML handling in the scaffold resource controller is not necessarily a good thing. Mike doesn’t use respond_to unless he knows he’ll be providing API access. It adds noise to your code, can be a security hole, and just isn’t needed if you aren’t supporting an API.
• If you accept credit cards, be sure not to store them in your database. VISA’s rules are hard to comply with, and penalties for non-conformance are high. Use a solution that allows you to immediately pass the credit card to the gateway, or even better, post the form with the credit card info directly to the gateway. Braintree Payment Solutions allows you to do recurring payments without storing credit cards by returning a token that you can use for future charges.
• make_resourceful plugin automates creation of CRUD actions for a resource.
• In most cases, has_many :through is a better solution than has_and_belongs_to_many. One time the habtm approach makes sense is for tagging.
• You can define methods on an association proxy. In the model, e.g., has_many :visits do <define custom find here> end.
• ferret is a port of the lucene search engine, whereas solr uses the original Java source, so it is more current—but it does require that you run a Java app server for the engine.
• If almost all of a page can be cached, but a little part like the login name cannot, cache the entire page and then use JavaScript to replace that section of the page after it loads.
• Disable sessions for controllers or actions within a controller where they aren’t needed.
• To decode the contents of a session: Marshal.load(File.read(“tmp/sessions/filename”)).
• use pp (pretty print) to print out an object in more readable form (much nicer than p(object) or object.inspect).
• simply_helpful is rolled into Rails 2.0. The plugin is now in the legacy folder. If you use this in your 1.2.x apps they’ll have a smooth path to 2.0.

And there’s more, but that gives you the idea…

I’ll be writing up many of these items in detail for www.BuildingWebApps.com once we get that launched.