Check out this link: http://www.rubyinside.com/ruby-style-guides-and-tools-how-to-write-good-looking-ruby-1272.html

It highlights two useful posts about Ruby style (here and here) and includes a link to reek, a popular tool for sniffing out code smells.

UPDATE: also, check out towelie: http://gilesbowkett.blogspot.com/search?q=towelie

Really helpful screencast. You can view it here:

http://railscasts.com/episodes/133-capistrano-tasks

Check out the new features here http://guides.rubyonrails.org/2_2_release_notes.html

Two words: thread safety

Check out the Release Notes here: http://weblog.rubyonrails.com/2008/10/23/rails-2-1-2-security-other-fixes

Version 3.1.1 has been released. There a few cool improvements such as auto-reloading when .autotest is updated and git support, as well as a whole mess of stuff that I have to assume are improvements. Full text of the update here:

http://blog.zenspider.com/2008/10/zentest-version-3110-has-been.html

We'll be implementing some of these features in Fan Profiles to make Flash messages more useful and to further split logic out of views and into the model layer.

Here's the episode

We spent most of the day getting a few new apps on out multi-app server in AWS.

It's very cool but why should this take a full day?

Rails has come a long way quickly, but one of the biggest problems with our favorite MVC framework is support for multiple databases.

Sure you can use self.table_name and/or establish_connection to force a model to point to a table in a different db, but try running a freaking test with fixtures for the offshoot models, and you'll see what I'm talking about.

Even more depressing is SQLite3's lack of cross-database query join support, making this statement impossible:

has_and_belongs_to_many :blocked_users,
:class_name => 'User', :join_table => :blocked_users,
:foreign_key => "user_id", :association_foreign_key => "blocked_user_id"

Here's the kicker: All of our apps are multi-database apps, so that means no more SQLite allowed for us, and I really loved it until now.

If I'm wrong, let me know. I'd love to go back to using SQLite for local development. Same for an easy way to load fixtures.

Just checked out this video (links directly to m4v file) that someone forwarded to me earlier today.

Basically when trying to scale a rails app (or really any web based app) there are three core rules to live by.

1) Spindles = Bad. Talking to databases and/or file systems are slow.

2) Dynamic to static. Dynamic content is your enemy.

3) Push to the edge. Push everything as close to the client as you can.

"Rails scales exactly like any other web application... You need to take into account all the components, from the moment the request is received into the load balancer, all the way down, and all the way back again."

We're constantly working on improving performance on Fan Profiles as it continues to grow and have learned that these core rules are indeed the way to live by when working on scaling issues. Our work is far from done and likely will never be, but it's cool to see another sucessful rails team discuss these issues and how they tackled them.

Sunday provided a wonderful conclusion to RailsConf 2008. Here are some brief notes for the sessions I attended to whet your appetite with links to their RailsConf pages (where you can grab slides).

Waxing Ballroom Floors on the Titanic (and Other Less Seaworthy Vessels) - Rick Bradley, Yossef Mendelssohn, Kevin Barnes (OG Consulting) (RailsConf page)
Plugins:
object_daddy
timely
shmemeter
autochronic
freshtrack
nihilist_bot
flame

Genomes on Rails - Matt Wood (Wellcome Trust Sanger Institute) (RailsConf page)
Frequently and rapidly changing data

• Don’t have fields – store data as Descriptor/DescriptorValue objects (key/value pairs)
• With careful indexing it’s not that slow
• If one field is consistent across versions, that can be added to the db
• Can map Descriptors between different versions

They specify task the same way and allow users to create pipelines for various projects
Throughput: Data → 320tb/450 cpu cluster → Archive (2 Petabytes of data)

• Multiple instances of multiple applications (loosely coupled)
• Deployment is difficult because you need to push to all your instances
• reverse proxying with fairnginx in front of mongrels, deploying with cap

The Profitable Programmer: Creating Successful Side Projects - Geoffrey Grosenbach (Topfunky Corporation), Tom Preston-Werner (Powerset, Inc.), Chris Wanstrath (Err Free), PJ Hyett (Err Free), Ben Curtis (Catch the Best) (RailsConf page)
Project Ideas:

• Build something simple
• Build something you want to use
• Take something that’s already popular in one area and move it to one where it doesn’t exist

Implementation:

• Build it yourself
• Sub-contract

Promotion:

• Allow free accounts with limited, but useful functionality
• Piggyback on already established people and sites
• Form symbiotic relationships with existing sites
• Drive traffic to their sites
• Promote their product through yours

Success:

• Don’t listen to critics as you go through issues while expanding
• Try to build apps that are a source of constant income and require little effort to maintain
• Avoid VC → basically just getting a boss

Notes:

• Donationware? Ads?
• Ads are tricky because you have to become a marketer
• Market Research
• Track how people interact with the app and not how they say they interact or are going to interact with it
• Try to do something where its easy to get to people you want to sell to
• Think about how often people will use it (including you)
• Keep in mind who’s actually going to be paying for it

That's it. What an amazing conference. Can't wait until next year!