I.NFECTIO.US

The auto loading path which make models in subdirectories of app/models load in Rails has been removed from the lastest trunk. If you are using models in subdirectories of the app/models path, you will now need to add this in your environment.rb:

config.autoload_paths += Dir[RAILS_ROOT + '/app/models/*/']

This won't affect most users, but if you've organized your models into subdirectories similar to the convention used for namespaces controllers, then you will want to update your applications before you move to 1.2.

Specifically, the following path was removed:

#{root_path}/app/models/[_a-z]*"]

Twenty years ago, I learned about sex for the first time. All my friends said they were doing it, although I think most of them were full of it and just wanted to look cool. I didn't know much about sex back then but I'd read about it in The Joy of Sex and watched it on TV. There's something about actually doing it that you don't understand through those other mediums.

Learning about testing has been a very similar experience for me. I've known about it for awhile, all my programmer friends say they're doing it, and I've even read Test Driven Development By Example by Kent Beck. But doing it for the first time is a completely different experience. At first, I didn't know exactly what I was doing, I was aimlessly exploring the inputs and outputs, and before I knew it, I'd had my first testing orgasm. The tests I was writing discovered a serious bug in my code. That's when it clicked for me, really understanding what test driven development is about. If I had written the tests first, the specific bug they revealed wouldn't have existed in the first place.

Now that I've popped my testing cherry, I want to keep doing it, and much like my first sexual partner, Rails makes it easy. And when you get comfortable with your new partner, you can introduce great toys like ZenTest that will improve your experience.

The Rails Developers are rushing to get a 1.2 release out the door before RailsConf Europe. I'll try to list a quick run down of changes you'll may not be aware of in 1.2:

• Access nested attributes in RJS templates. Now you can use syntax like this: page[:foo][:style][:color] which will generate javascript like: $('foo').style.color


• Michael Koziarski is my hero for this change. If you've ever tried to use a 'quote' column in your model, you quickly found out that it conflicted with AR's quote column method. No longer is this an issue. def quote has been changed to def quote_value


• Calling image_tag without the file extension now raises a Deprecation warning. In 2.0, it will no longer append .png to the file name. This is welcome change, unneeded magic is well...unneeded.


• UPDATE: This change has been reverted for the time being. Now you can access the locals hash directly. In your partials, you can check if a local varialbe was passed in by doing:
  if locals[:local_var] then ...


• In 2.0, the default for foreign_keys will be the association name, rather than the class name. So if you specify a :class_name with no :foreign_key on your belongs_to associations, it will throw a Deprecation warning. The tests explain this pretty well:
  
  

  def test_deprecated_inferred_foreign_key  
    assert_not_deprecated { Company.belongs_to :firm }  
    assert_not_deprecated { Company.belongs_to :client, :foreign_key => "firm_id" }  
    assert_not_deprecated { Company.belongs_to :firm, :class_name => "Firm", :foreign_key => "client_of" }  
    assert_deprecated("inferred foreign_key name") { Company.belongs_to :client, :class_name => "Firm" }  
  end 



• The Ruby/MySQL driver that ships with Rails has been updated to work with the new authentication in MySQL 4.1+. Of course, everyone uses the Ruby C bindings to MySQL right?


• My own patch to distance_of_time_in_words was applied. What does this mean to you? Nothing at all, I just wanted to tell you about it.


• Some nice additions to Prototype Element Handling. You can now traverse the DOM using the new Element.up, Element.down, Element.previous and Element.next methods. To make debugging easier, you can use Element.inspect. Check out the changeset for more useful changes.
  
  

  Examples:  
    <div id="sidebar">                   -> $('nav').up() or $('menu').up('div')   
      <ul id="nav">                     -> $('sidebar').down()  or $('sidebar').down('ul') or $('menu').previous()  
        <li>...</li>                    -> $('sidebar').down(1) or $('sidebar').down('li')  
        <li>...</li>                    -> $('sidebar').down(2) or $('sidebar').down('li', 2) or $('sidebar').down('li').next('li')  
         <li class="selected">...</li>    -> $('sidebar').down('li.selected')  
       </ul>                               
       <ul id="menu">                    -> $('sidebar').down('ul').next()  
  
  



• Rails will actually use the 500.html thats been sitting in public for awhile when your application fails to catch an exception not related to routing.


• In the testing department, assert_tag has been deprecated in favor of the new assert_select family of assertions.


• Another one of my patches got applied. radio_button_tag now generates a unique id attribute based on the name_value pattern.


• And plenty of other deprecation warnings throughout Rails...those you can figure out for yourself.

LiteSpeed Web Server is a commercial product being marketed as "the world's best performing Ruby SAPI and easiest Ruby on Rails application setup". Having used LiteSpeed for over 6 months now and after running my own tests, I agree with that statement whole-heartedly. Being a recent Apple convert, to me LiteSpeed is the OS X of the web server world. Not open source, but it looks and works great and the developers actually listen to what the users need.

LiteSpeed offers a Standard Edition which is free for private and commercial use, the only restriction being that your site can't serve content related to pornography, warez or illegal activities. This is an odd restriction, but I guess it's cool that they stand by their principles.

To keep things DRY, I won't repeat LiteSpeeds feature set here. Instead, I'll "show" you why I choose LiteSpeed and why I think you should give it a test drive as well. I've put together two screencasts for your viewing pleasure. The first will demonstrate just how easy it is to get up and running with LiteSpeed. From installing the server to a fully deployed Rails application in under 4 minutes. Live and uncut. It moves along pretty fast, but I felt it was a good demonstration of the effort the LiteSpeed developers have put into supporting Ruby on Rails. In the second screencast, we'll take a more in-depth look at some of the cool features of LiteSpeed Web Server. Hope you enjoy them, I had fun making them.

Up and Running with Rails in Under 4 Minutes - 3:25 runtime - Flash

LiteSpeed In-Depth - 21:35 runtime - Flash

UPDATE: The screencasts show that you have to copy dispatch.lsapi into your public directory, with the 2.2 release, this requirement is lifted. The ruby-lsapi gem still needs to be installed, but LiteSpeed will handle the dispatching to Rails through their LSAPI automatically.

UPDATE: When running the script to restart LiteSpeed, make sure you run it as a user with root priviledges. So for Mac users: sudo lswsctrl restart

Kevin Clark, a fellow #cabooser, and great programmer posted an article on his blog today that for one reason or another sparked some contraversy. He wrote about Rails coding practices that he believes (either through experience or following the core mailing list) should not be used anymore. The pros and cons of scaffolding in production, engines, components, protected instance variables and help vampires are all things that have been discussed openly in various venues and Kevin advocated against them with his reasons why.


What happened next is hard to describe but it's like a pack of wolves came out and shredded him apart. Not sure where these "Rails" programmers came from but I hope they don't stick around. Besides, how can you get upset at a guy that looks like a cute little chia pet?

The guys over at LiteSpeed really stepped it up this time with their support for Ruby on Rails in their newest release of LiteSpeed 2.2. The ability to configure and deploy a Rails site now has its own configuration page in the administration GUI.



Once you define the defaults for RoR applications on your webserver, you can setup and deploy a site in just a few clicks. Prior to the 2.2 release you had several options for getting LiteSpeed to redirect requests to dispatch.lsapi, you could use rewrites or 404 redirects. Now in 2.2 you can just use the new Rails context feature. LiteSpeed will handle the connections to dispatch.lsapi.



Speed plus agility, what a great combination. Check out their Wiki for some quick start instructions on getting up and running with Ruby on Rails on their platform. I'm interested in seeing what performance benefits I will receive with their Enterprise Version running Rails on the new SMP server, hope they offer educational discounts.

Just a quick little slideshow to show the new setup.

7MB Quicktime Movie

I've had my MacBook Pro for a couple months now and I've really enjoyed using it. I keep finding out that "things just work", like the time I was rebuiling my PC and Mac laptops and my Linux server had an emergency. I was working on the PC at the time, and...well crap, wheres my ssh program?!? Okay, swivel on over to the Mac, load up Terminal and fix the problem. Or the time I wanted to burn a DVD, gosh darn it, which Burning software do I want to download? Swivel over to the Mac, stick the disc in and click a few times and I have my DVD burned.

Now the MBP hasn't been without problems. I ran into the (now admitted) battery problem during Rails Conf. Couldn't use my MBP unless I had a plug to give it some juice. Also, when it's hooked to the 30" cinema, occasionally, the output gets corrupted and I see little aquagreen dots all over my desktop, a reboot usually clears it up thankfully. Back to my story, I haven't totally swapped to the Mac because I still have a (rather new) desktop PC at home. AMD 64-bit X2 3800+ with a couple terabytes of disk space, 4 gigs of ram and 3 21" CRT's hooked to it. I really enjoy this setup with three monitors and didn't really want to give it up just to use the MBP at home.

Out with the new, in with the newer. I figure I wouldn't ever move to Mac all the way if I wasn't forced to use it both at home and at work, so I bit the bullet and ordered a shiny new MacPro for home. I had a limited budget so I had to scale back for now but I got the essentials. I went with the 2.66 duos, left memory at 1G, cut the hard drive to 160GB (I'll pull the 4 Hitachis out of my current desktop), added the extra SuperDrive and Bluetooth (got my free 2GB iPod Nano after rebate) and best of all, 3 20" cinemas. I'll post some pics when I get it all setup. It's gonna be sweet!! I hope they don't wait too long to get PC drivers out for the new hardware just in case I need the occasional native PC app. (I use Parrallels at work already and it's OK, but not for gaming.)

The trade off? Gotta sell my '90 GMC 3/4 ton pickup to pay for it. That's the only way I could get the wife to reluctantly agree to it. That and a few dinners followed up by **censored** should smooth things over pretty well. A new Mac *and* more sex? I think you know who's getting the better deal here! Update

The monitors arrived today, MacPro still hasn't shipped so I can only drool over this picture.

Choosing a Rails Deployment Platform is a well-documented but still confusing activity. You have so many choices you need to make, FCGI, Mongrel, Apache, Lighttpd, LiteSpeed, LSAPI, Rewrite Engine, 404 Handler, mod_proxy ... and the list goes on.

The Plan

I just ordered a new webserver to replace my aging Dual 850mhz box and I thought I had a plan worked out. Since I still have legacy PHP applications, I chose to use LiteSpeed to power them. LiteSpeed outperforms Apache/mod_php by quite a bit of margin when serving PHP generated content. LiteSpeeds UI for administration also makes it much simpler to manage all the VIrtual Host setups as well.

All the cool kids are using mongrel nowadays for Rails Deployment. Always wanting to hang with the cool kids, I decided that Apache2 would proxy balance to a mongrel cluster for my applications. I planned on running Apache2 on a separate interface anyways to host my projects with SVN.

Testing It

Ok, we have LiteSpeed and Apache2 running on different interfaces on the server. I run ab2 against the LiteSpeed/PHP first using a static html file, then using a Hello World PHP page. The static page registered in at 20K+ rps. Wow, looking good so far. The PHP clocked in at 5K+ rps. Pretty good numbers so far. +1 for choosing LiteSpeed to run the PHP applications.

Moving on to Apache2. I created a Hello World Rails application, lit up a 6-pack of mongrels (using a concurrency of 10 in ab2), ran ab2 and WTH????. 60rps. What a let down. I rerun the test just hitting the index.html of the Rails app, and the numbers come back up to 15K+. Doesn't sound right to me so I tweaked Apache for awhile but to no avail.

Just for SAG, I decided to setup a Hello World Rails application in LiteSpeed. For this configuration, I chose the LSAPI and used a 404 Redirect. Since I didn't want my hopes dashed right away, I decided to just hit the index.html of the Rails app. 10K rps. Hmmmm. That's lower than the Apache2 marks. Maybe this wasn't a good idea. So I'm thinking the Hello World will cash in around 45-50 rps. Let's run it. WTH????. Averaging 400 rps in this configuration. I tinkered around with Apache2 some more to try to get the numbers up, but it just didn't happen.

The Result

With the simple benchmarks I did, they gave me enough information to make a better choice for a deployment platform for Rails. I didn't test lighttpd at all and don't plan to. I don't really care that LiteSpeed is a commercial offering, the developers listen to their customers (even the freeloaders like me) and incorporate changes or fixes quickly. They've been extremely supportive of the Rails community and continue to make changes tailored to running Rails applications.

There is an effort underway to raise $5000 to fund the update and expansion of the Rails API documentation. This should be a worthy cause if they find the right person. Give whatever you can give, in the end we all benefit.

Rails Documentation Fund