Ubuntu and Mac OS X Living in Harmony

As web / Ruby on Rails developers, our computers become easily overwhelmed with all of the applications we may have up and running at any one time.  On a normal day, I will have the following running:

• Firefox with at least 10 tabs (a few tabs for our clients web sites in multiple environments, usually a tab or 2 with Google search results, our Redmine instance, GitHub, plus a couple other various sites that I peruse throughout the day)
• Several web apps using either Prism (Ubuntu) or Fluid (Mac) such as multiple Campfires, Google Reader, and Gmail.
• IM client
• Twitter client
• A Terminal window with several tabs to access multiple servers
• MySQL client
• PDF Reader
• Text editor / IDE (TextMate on a Mac or Geany on Ubuntu)
• Various other widgets such as a Remember The Milk widget, weather widget, system monitor, etc
• At least once a day I will have to open OpenOffice to open a document or spreadsheet

On top of these client apps, I will also have a Mongrel or Apache web server and a MySQL and/or SQLite3 database servers running.

Now that’s a lot of stuff!  If I did any design work (which I do not), I would have to add tools such as Adobe Photoshop and Illustrator to this list which are VERY resource intensive.

Even with today’s high powered machines, that is asking an awful lot to expect a single computer to run all of this day in and day out without issues.  My 2 year old MacBook starts revving its engine preparing for takeoff after kicking off a couple mongrels, mysql, and a few FireFox tabs. 

My solution?  Share the load! 

How?  Synergy!

A little over a year ago, I purchased my wife a new laptop.  I took her desktop, which was still relatively new, and installed Ubuntu.  So now I have an Ubuntu desktop connected to a monitor on the right side of my desk with a keyboard and mouse that extend to my MacBook (via Synergy) that is placed in the center of my desk that extends to another external monitor on the right side of my desk. 

To get this configuration to work, I installed QuickSynergy on my Ubuntu machine and set it up as my Synergy “host” that has a single “client” called MacBook.  On my MacBook, I installed SynergyKM that connects to my Ubuntu as its host via the Ubuntu machine’s IP address. 

This has worked out great for me.  My Ubuntu machine runs my web and database servers which is nice.  Since the majority of our actual physical servers use Ubuntu, I can test configurations out on my desktop before trying them out on our test and production platforms.  With my Ubuntu machine taking the bulk of the backend server processing, my Mac is free to run client apps such as IM, Twitter, Firefox / Safari, iTunes, etc with little hastle. 

As an added bonus, I found this nice article a few months back that gives a step-by-step process to access a Windows partition from Ubuntu via VirtualBox.    With this, I can readily access Windows, Ubuntu, and Mac OS X operating systems with a single keyboard and mouse.  (I do try to limit the amount of time VirtualBox is running as it is VERY resource intensive and brings my Ubuntu machine to a crawl after a while.)

Isn’t technology great!!

Redesign Your Site in Place Using Rails Custom Mime Types

After reading Ben Smith’s classic iPhone on Rails 2 article and implementing our own iPhone site after the jump to Rails 2, I was struck at how easy it is to create you own custom mime types to serve up different content to different devices.

When the time came to redesign the main MindBites site, I didn’t look forward to a lot of branching and merging, no matter how easy Git makes it. Then it hit me. Why not create a custom mime type and serve up a new layout and views for beta users? Let’s take a look at how we’re doing just that.

Step 1: Register your custom mime type

The first thing we need to do is tell Rails we’ve got a new format type to serve up:

<code class='ruby'># config/environment.rb

Mime::Type.register_alias "text/html", :iphone
Mime::Type.register_alias "text/html", :beta

We used beta, but you could use any value here not already in use.

Step 2: Detect a beta request

In order to let only the cool folks into our new beta site, we’ll need a big burly bouncer at the door keeping out the riff-raff:

<code class='ruby'># application.rb
before_filter :adjust_format_for_beta

...

def adjust_format_for_beta
  request.format = :beta if beta_request? 
end

def beta_request?
  return (request.subdomains.first == "beta" || params[:format] == "beta")
end

The before_filter executes before each request and if ‘beta’ is the first subdomain or passed in as a format param, Rails will set the format to :beta.

Step 3: We’re in da club, now what?

Once we’ve identified our beta users, we now need to give them the new eye candy. We do this simply by dropping in a new view named xxxxxx.beta.erb. The bulk of the changes for our redesign are in a new application layout which serves up a new basic layout and CSS.

application.html.erb → application.beta.rb

Other views (even partials) are swapped out in a similar manner:

show.html.erb → show.beta.erb

lesson.html.erb → lesson.beta.erb

And that’s it! You don’t have to do every view in the site because Rails will fall back to .html.erb for any views without a .beta.erb version. Most of our redesign is accomplished in CSS. Where we have massive markup changes, we simply swap out the view templates.

See update 2 below

A gotcha to watch out for

In a few cases, we had respond_to blocks in our controllers to handle differences between the iPhone and regular versions of the site. Anywhere that you have these, you’ll need to add the beta mime type as well:

<code class='ruby'>respond_to do |format|
  format.html
  format.beta # &lt;= You'll get a 406 Unprocessable entity error without this line
  format.iphone do 
    render :layout =&gt; false if request.xhr?
  end
end

If an action does not already have a respond_to block, you’re OK. No changes are required in your controller.

UPDATE

Thanks, Ryan Heneise, for reminding me about the last step:

Step 4: What is new is old again

When you’re ready to launch, you’ll want to fold all those beta views back into your project as the default .html.erb views. Simply rename them from .beta.erb to .html.erb. For us, it’s a bit easier since we don’t have to overwrite any .html.erb files. We’re still using .rhtml!

Thanks, Ryan!

UPDATE 2

Paul Canavese turns in some excellent QA work and informs me that Rails will not fall back to .html.erb. Our templates are still .rhtml. So it would appear you will have to touch each template or use .rhtml. Sorry!

jQuery Parallax Scrolling – Build Your Own 1980’s Video Game!

What is old is new again. Inspired by the recent crop of css parallax techniques. I thought it would be cool to take it one step further and introduce parallax scrolling. Thus the jQuery Parallax plugin was born.

What the heck is a parallax anyway?

Paul Annett of Clearleft does a far better job of explaining the css parallax technique than I could. If you’re unfamiliar with this layer-stacking technique, jog over to Vitamin and get the scoop.

That’s pretty cool, but why do I have to resize my browser to enjoy it?

For no practical reason whatsoever, I thought it would be cool to animate the layers in a CSS parallax and give the scene a depth of field that you can’t convey with static layers. As with all my jQuery endeavors so far, I found this surprisingly easier than I thought.

Step 1: Build the layered scene

Just in case you’re reading this and were served one of the other parallax scenes on the site, here’s a look at the finished product.

For our simple western landscape, we’ll construct the scene from four layers:

Step 2: Add the required Javascript references

To animate our parallax we’ll use my jQuery Parallax plugin which requires jQuery 1.2.x and the jQuery Easing plugin (for acceleration and deceleration).

<code class='html'>&lt;script src="/javascripts/theme/jquery-1.2.6.min.js" type="text/javascript"&gt;&lt;/script&gt;
&lt;script src="/javascripts/theme/jquery.easing.1.3.js" type="text/javascript"&gt;&lt;/script&gt;
&lt;script src="/javascripts/theme/jquery.parallax.js" type="text/javascript"&gt;&lt;/script&gt;

Step 3: Wire up the parallaxes (what a fun word to say!)

Now it’s time to attach our parallax behavior to the container and each slice in our scene.

<code class='html'>jQuery(document).ready(function() {

    jQuery("#header").parallax("create");
    jQuery(".scene-1 .slice-1").parallaxSlice("create", {speed: 5});
    jQuery(".scene-1 .slice-2").parallaxSlice("create", {speed: 3});
    jQuery(".scene-1 .slice-3").parallaxSlice("create", {speed: 1});

});

Step 4: Sit back and enjoy the show!

Again, this little demo has very little practical value. Maybe I should do something more constructive with it like, recreate the first level of Contra

Updating Comatose to Rails 2

We’re big fans of the Comatose CMS, so we were very disappointed to see Comatose throwing exceptions after we upgraded to Rails 2.1. Browsing through the Comatose Google Groups didn’t yield much information either. But we finally did manage to figure it out and since there isn’t a whole lot written about this, we decided to blog it and hopefully it’ll be useful to others as well.

Get the latest version of Comatose (uber-alpha)

• remove your existing Comatose plugin (just delete the “comatose” dir from your “vendor/plugins”)
• install the uber-alpha Comatose
  

  ./script/plugin install git://github.com/darthapo/comatose.git

Update Comatose tables

• the “page_versions” table has been renamed to “comatose_page_versions” and its “page_id” column has been renamed to “comatose_page_id”. Here are a couple of migrations you can add to your project to make these updates:
  

  class AlterComatosePageVersions < ActiveRecord::Migration
    def self.up
      rename_table :page_versions, :comatose_page_versions
    end
  
    def self.down
      rename_table :comatose_page_versions, :page_versions
    end
  end
  
  

  
  
  

  class AlterPageVersions < ActiveRecord::Migration
    def self.up
      rename_column :comatose_page_versions, :page_id, :comatose_page_id
    end
  
    def self.down
      rename_column :comatose_page_versions, :comatose_page_id, :page_id
    end
  end
  
  

Change Comatose::Page to ComatosePage

• the “page” is no longer namespaced, so all we had to do was update our config to “ComatosePage”

That’s it!