I've just completed my Rails Rumble contest entry for this year. I took a very focused project, and built it as a single solo developer. I'm extremely pleased with the way it turned out.

The site was inspired by a recent post over at kottke.org about "The Steve Ward" diet (see Kottke's source article from Philip Greenspun, it's a good read... and not actually about dieting).

After reading about this simple diet strategy (it's nothing more than a graph paper of your daily weight), I decided to try it for myself; it works. I've lost 8 pounds in about 3 weeks. My success is mostly due to more frequent and longer trips to the gym--the motivation for that has come directly from the accurate daily feedback you get from this plan.

The web site is a slightly more sophisticated version of the paper-and-pen version Steve Ward describes.

Check it out:

Introductory Screencast
The site itself - The Line Diet
My Rails Rumble Team page

The Rails Rumble contest opens for public voting on August 27th.

Ruby on Rails is an excellent framework for building web applications. Perhaps the best. But it's not currently very well suited to what I call web sites.

The difference is simple. In a web site, the unique business value comes from the content creators (authors, bloggers, photographers, etc). In a web application, the business value comes directly from the programmers. Twitter, Google, Basecamp and eBay are web applications. CBSSports.com, KentuckyDerby.com, corporate brand sites and original news sources are all web sites.

For these projects where it's the content that matters, there's no reason to spend time hand-coding models, controllers, views and test code for things called Pages, Articles, BlogPosts, CalendarEntries, and all the other unique types of content. You're just re-inventing the wheel if you do, because there are numerous existing commercial and open source CMS tools that can do the job cheaper and better than you.

Unfortunately, I find that one of the most common scenarios is a hybrid web site that needs an attached web application. A corporate web site that needs an attached scheduling tool. A news site that needs an interactive, custom-searchable database. A sports site which aggregates content from an old NNTP-based data source.

Depending on the specifics, you usually have 3 different approaches to this problem:

1. Two side-by-side applications. - Pair an off-the-shelf CMS with a custom built application. Copy/paste the visual elements, and loosely wire the two together with a subdomain or some kind of web proxy to share the URL structure
2. Extend the CMS - Build a proprietary plugin or extension for the CMS to implement the application features.
3. Soup-to-nuts custom application. Build a complete CMS as part of the project.

If scenario #1 is truly possible, it's the best approach. Unfortunately, it's often the case that the two systems need to share user accounts, group permissions (or worse, business logic) and data. Once you link the code and data of the two applications, you actually have a particularly "smelly" case of scenario #2.

And scenario #2 is usually a bad idea, unless you are really committed to the CMS you've chosen. This approach tightly couples your value-adding intellectual property directly to a CMS that generally has nothing to do with your business. If your CMS vendor is out of business in 5 years, you'll probably need to completely rewrite that custom extension to work in some new system. Unfortunately, this seems to be the most commonly-used approach. Radiant's extensions have this problem, and so does the Block/Portlet system in BrowserCMS.

Finally, scenario #3 is just plain wasteful. If your CMS needs are anything but trivial, you're going to spend a lot of time and money building CMS features that have nothing to do with your business enterprise. Unless you accidentally build an exceptionally good CMS tool that you then sell to others, all that money is wasted.

The reason for this problem is that Ruby on Rails is a framework for applications, not systems. The error in all of the reasoning above is that the described CMS project is not a single application, but a system of two (or more) applications.

I've seen some very attractive developments that will help to address this issue in future Rails applications. First, the inclusion of Rails Engines in 2.3 is going to lower the level of coupling for cases where the CMS can be an "engine" within the application. There's some hope that an even more flexible solution may be forthcoming. These solutions help to flip scenario #2 on its head. Unfortunately, this still leaves your application largely dependent on the CMS vendor. You may have trouble customizing the CMS' features without hacking the engine (or "mounted app") code directly.

Over the past few months, I've been working to find better solutions to the issues I've raised here. I'm in the process of building an experimental engines-based CMS plugin, through which I hope to gain some active insight into what makes this problem so difficult. I'll be posting my analysis as it crystalizes. If the CMS turns out to be effective for my uses, I'll be releasing it to GitHub.

For now, I'll simply leave it at this: I believe the solution lies in finding a common "language" for an application to communicate with its plugins, and for those plugins to communicate with one another. In the case of authentication and authorization, this means a plugin needs to know how to ask about the identity and rights of the active user.

Django and Drupal, have made the framework itself answer that question (both Django and Drupal have admin interfaces and user management features somewhat baked in). I'm not convinced that's the best approach, but it seems worthwhile to consider that approach for Rails.

My CMS plugin is opting instead to look for API functions at the controller level to answer these questions (i.e. the plugin assumes you have a current_user() method in ApplicationController, but allows you to customize the name and behavior of that).

Update: Thank you for all the encouraging comments. There are sure some good people out there in the Rails community. I wanted to draw some attention to ferrisoxide's blog post: "Rails is a CMS". This thought is very much along the lines of the experimental development I'm doing. The goal for my approach is to leverage as much of the flexibility of Rails itself for it's feature set.... in that way I'm planning more of a CMS-enabler plugin than an actual out-of-the box CMS.

Update 2: I wanted to also draw attention to Aaron Bedra's comments about CAS, specifically Castronaut as an implementation pattern for scenario #1. It didn't even cross my mind when I was writing this post... and CAS seems to be one of the most under-hyped technologies out there. More on that later.

Rails' built-in Javascript view helpers are excellent in terms of convenience, but they make it difficult to follow Yahoo's wise advice that scripts at the bottom of the page make for faster loading pages than scripts at the top of the page (obviously, using inline Javascript like the Rails helpers do requires that your <%= javascript_include_tag :defaults %> be above the main yield in the template.

The solution to this problem is simple. Every time you need to call a Javascript helper method in a view, just wrap it in a <% content_for :footer do %> block, then put a <%= yield :footer > just before the </body> in your template.

I've been wanting to move a few of my low traffic client sites over to mod_rails/Phusion Passenger for several months now, but I worried about the hassles of switching platforms. I finally decided to go ahead with it earlier this week.

The process turned out to be far simpler than I had imagined. The Phusion guys have done an excellent job with packaging their code for developer usability. The Apache module installed automatically, without a hitch, and without damaging any configuration on my production machine. Even custom-compiling and installing Ruby Enterprise Edition was simple and quick.

I think the whole process of installing mod_rails, RubyEE, and migrating the DNS for the site took less than an hour. I fully expected to take a day or more for this transition.

I am simultaneously shocked and honored that Riverdex, my entry with Chris Tenbrink to the 2008 Rails Rumble competition, has taken 3rd Place!

Now I have absolutely no excuse not to finish the site. I procrastinated building it for almost 2 years, and it became a reality in less than 48 hours.

So, for those of you preparing entries for next years' competition already, I've got a few bits of advice for you:

First, image is everything. Spend plenty of time making sure the first impression of your site is a good one. Make sure an uninitiated stranger can understand the purpose of your site simply by looking at the home page for a few seconds. Don't build any features that require more than a few clicks to access.

Second, spend most of your planning time on logistics. Identify exactly which plugins you'll need to use for your site, and practice installing them. Practice setting up a VPS from scratch. Only plan the design of your application in a loose way. You'll likely mis-estimate which pieces will take the most time, so you need to stay flexible about which ideas to leave on the cutting room floor.

Third, take breaks. I've heard from many of the other top-ten folks that they used far less than 48 hours. In other words, they actually slept. I did too, about 6 hours a night. I also went to the park with my family, and went out to dinner too. Your brain needs rest, and you'll operate more effectively when you're not burned out.

I've just submitted the final copy of my repository for riverdex.com, my entry for Rails Rumble 2008. I'll be updating this post with some additional background info and explanation later, but for now... enjoy the site.

Here's a HUGE tip for those of you who are about to build a screen scraper with WWW::Mechanize and Hpricot. If you have any intention of parsing hundreds or thousands of pages (you probably do, right, otherwise you wouldn't be screen scraping), you better set max_history to a very low number (say, 1 for example).

If you don't, Mechanize will remember every page you visit... and that can add up quickly to megabytes of memory if you're scanning multiple pages.