August 2007 Archives

I recently had the pleasure of deploying a few Rails applications to the FCGI funhouse that is Dreamhost, and just to make matters more interesting, I decided to do the deploys using Capistrano 2.0, rather than its better documented predecessor. After fumbling around a bit trying to translate various Capistrano 1.* recipes, as well as reading a number of postings about some incredibly descriptive FCGI error messages (“FastCGI: incomplete headers (0 bytes) received from server “/home/…./public/dispatch.fcgi”), I finally came upon a couple of postings that, when combined, provided the magic formula:

Getting Started With Capistrano On Dreamhost was an extremely valuable resource. The only deviations I made from this entry were the fact that we already have SVN up, asking Dreamhost whereis ruby, rather than taking the shebang suggestion at face value and running the chmod suggestions contained in the following post: Application Error – Rails application failed to start properly. For whatever reason, FCGi required our tmp and log directories to have 755 permissions.

Thanks very much to those two authors for their helpful posts!!

Recently, when working on a DHTML slideshow based on Prototype and script.aculo.us, I ran into a problem with JavaScript and updates to the page UI. I intended the portfolio code to do the following:

1. hide the current image
2. replace the current image with a new image
3. fade in the new image

However, in my first implementation, I saw the following behavior:

1. the current image would disappear
2. the new image would flash immediately in its place
3. the new image would disappaer
4. the new image would fade in

Effectively, the portfolio code performs the following steps (simplified for example):

1. Element.hide( id );
2. $( id ).src = source of new image
3. $( id ).onload = function() { new Effect.Appear( id ) }

The problem was that in some browsers I tested (Firefox 2.0.0.6 on Windows and Mac, IE 6/7 on Windows), line 1 of the portfolio code would not appear to execute until after line 2. It turns out that for these two sets of browsers, UI rendering occurs in the same thread as JavaScript execution. The browser “queues” DOM manipulations until after the JavaScript yields. In my example, the Element.hide does not take effect until after the src attribute of the image has been changed. So, the new image suddenly replaces the old image, the new image is hidden, and then it slowly fades in.

The trick I used to solve this was to use setTimeout to effectively “yield” control so that the browser could update the page UI (again code simplified for example):

1. Element.hide( id );
2. setTimeout( function() { $( id ).src = source of new image }, 0 );
3. $( id ).onload = function() { new Effect.Appear( id ) }

Here’s a complete, yet simple example. Refresh your browser to reset the state of the page. You can also play with the example here.

    


        
    

    

            ready
        

            
                click me (without setTimeout)!
            
        

            
                click me (with setTimeout)!
            
        

    

If you click on the first link, nothing will appear to happen for 3 seconds or so, then the message will change to "go!" However, if you click on the second link, the message will immediate change from "ready" to "set..." and after 3 seconds, to "go!"

Be careful with this setTimeout trick. It is easy to abuse it. I have implemented a queue where setTimeout is used to yield control to the browser UI between commands previously enqueued commands. The code became unmanageably complex. Yielding control in this fashion does not make JavaScript threaded, but does introduce asynchronous behavior which may cause your code to execute in an unexpected order.

Below are two screen shots. One is of the Bust Out Solutions website circa January 2007 when we were undergoing a website re-alignment to bring it to the state in which you see it now. The next screen shot is of advanceddigitalstudios.com (circa August 2007), a domain owned by Robert Clark for a company in East Hartford, Connecticut. I have never met Robert nor do I know anything about his company, but through the power of integrated website analytics I found this ripoff. Let’s wait to see what the site looks like when it launches.

bustoutsolutions.com (January 2007)

advanceddigitalstudios.com (August 2007)

A colleague of mine forward this site to me today: brainmind.com. We both agreed that it potentially wins the award for worst website. Obviously, the webmaster is not too concerned with information architecture, design, web standards, usability, or code optimization. The site was so bad I couldn’t stop looking at it, which maybe works in his favor for driving traffic. It’s the William Hung of the web world.

I think I need to lie down for a while now…

We’re pleased to announce the launch of rubinsteinphoto.com. Sara Rubinstein is a commercial photographer based in Minneapolis who now has a kickin’ website. The site has some sick and crazy JavaScript thanks to Bust Out partner Ted Chen, who used the Scriptaculous and Prototype libraries to create the image transition effect. Check out the site, enjoy some sweet photos, and if you’re feeling particularly nerdy, take a long look at portfolio.js.