Postpostmodern » Rails

A Body with Class

Jason Johnson — Fri, 20 Feb 2009 23:07:12 +0000

This Short Version

Add a class attribute to your tag for each part of the page’s path in the URL. E.g.: The page http://example.com/about/history should have a body tag that looks like . It makes styling those sections of your site nice and simple.

The Explanation

Often times, specific styling/formatting is shared between similar pages. The traditional way to deal with this is to include additional CSS files when special formatting is needed. I’ve found body classing to be more useful and more efficient.¹

Since the pages that share styling often also share a path in the url, it’s really simple to add the path parts as classes to the body tag. For example, say the about section of a web site needs special formatting because it has an extra sidebar or maybe some sort of widget. I would add the class ‘about’ to the body tag of all of the about pages. This method continues down the hierarchy. The page at /about/history would have a body class of ‘about history’, and so on. It’s very simple and very handy.

It’s also very simple to add this functionality to your layouts whether you’re using Rails or any other framework. My PHP framework, Phooey, does it for you automatically.

For Rails, you can include this in your layout:

…or, if you’re using Haml (which I highly recommend):

%body{:class => "#{controller_name} #{action_name}"}

Agree? Disagree? Confused? Let me know down there in the comments.

I am of the opinion that you should only include one CSS file per media type in any page of your site (except for the IE stylesheets). I usually include only the following stylesheets in every page of every site: all.css, screen.css, print.css. And each one of those is minified. More on this in my forthcoming article on Sass. ↑ back up there

Rails Tip: Default Scope

Jason Johnson — Tue, 04 Nov 2008 16:27:30 +0000

I’ve started using the all method instead of find(:all) for fetching records – mainly because it’s shorter to type, but it’s also easy to override with a named scope. Just create a named_scope called all to set whatever default conditions and order you want. You can always use find(:all) if you want the non-scoped records.

named_scope :all, { 
  :order => 'last_name',
  :conditions => 'activated_at IS NOT NULL'
}

Thoughts, corrections and objections welcome in the comments.

Capistrano on Media Temple

Jason Johnson — Thu, 30 Nov 2006 00:25:58 +0000

[UPDATE 1/6/07]

I had originally left out the step where you create the ‘rails’ directory inside the container directory. I thought that the mtr add utility might do that automatically, but it doesn’t look it. So, make sure you do #8 of Step 1 if you’re starting from scratch.

[UPDATE 12/1/06]

When I first wrote this article, WordPress was converting my double hyphens to en dashes (like a hyphen/dash but longer). Consequently, copy/pasting the command line input didn’t work. Now, it should be fixed and copy/pasting the commands should work. When in doubt, re-type it.

…easy as pie! You could even call it a recipe for pie!

I had the pleasure of deploying a Rails site on Media Temple’s new Grid Server recently. I have to say, it’s probably the easiest set up I’ve used for Rails.

There are basically three simple steps to setting up and deploying once you have the account set up: installing the container and rails; configuring your Capistrano recipe; and deploying.

I have created my own deploy.rb recipe which makes things even easier than the default MT recipe.

Step 1: Rails and the Container

The following is mostly taken straight from MT’s Server Guide. The part that differs is in Step 2 and 3.

The first thing you need to do is enable ssh access for your server admin on your Grid Server account. That’s done via the Account Center control panel.
Next, you need to activate the container. That’s also done via the control panel (under Ruby on Rails).
SSH into your acocunt and set up your gems: mtr setup_rubygems -u serveradmin@domain.com -p
Load your newly created environment variables: source ~/.bash_profile
Install Rails and dependencies: gem install rails -y
Install MySQL driver (postgres is also available): gem install mysql --source=http://gems.mediatemple.net/
Install Mongrel: gem install daemons gem_plugin -y gem install mongrel --source=http://gems.mediatemple.net/
Create a rails directory: mkdir ~/../../containers/rails

Rails is pretty much ready for an app now.

Step 2: Configuring your Application

This is standard Capistrano procedure except for the specialized gem and deploy recipe.

[UPDATE] I should mention that the rest of this procedure takes place on your local (development) machine.

If you don’t have Capistrano installed, do it: sudo gem install capistrano
Install MT’s special Capistrano tasks (all one line): sudo gem install mt-capistrano --source=http://gems.mediatemple.net/
“Capistranize” your application by cd-ing into your rails root and running: cap --apply-to ./ YourApplicationName
Download my Grid Server deployment recipe, unzip it and use it to replace your default config/deploy.rb file.
Open up the new deploy.rb in your favorite text editor and fill in the config info at the top.
Check your app in to your svn repository.

Now, your app is properly set up.

Step 3: Deploy (the fun part)

Set up the directory structure: cap setup
Do a “cold deploy”: cap cold_deploy
Visit your site, and revel in your overwhelming sense of accomplishment.

Disclaimer

The above worked for me. Unless I’ve mis-documented something, it should work for you, but I can’t guarantee it. Please don’t blame me for any damage, and let me know if you find errors. I’ll do my best to address questions in the comments.

Dog Days of an Indian Summer

Jason Johnson — Tue, 08 Aug 2006 02:18:44 +0000

“The future of Rails deployment belongs to Mongrel,” they said.

So, about a month ago, not long after Lighty had settled into its little corner of the new server and was happily churning out web sites, I decided to shut it down. Lightttpd is a great web server, but my new CRAM setup feels so much better.

I’m talking about Capistrano, Rails, Apache, Mongrel. Coda Hale wrote a great article on setting it up. I used his basic procedure, tailored it to my specific needs/personality, and voila! CRAM!

See, Apache + FastCGI was sketchy at best, but Apache + Mongrel seems to be delightful. Now that Apache’s back in the mix, it’s a lot easier to run my PHP-based sites (and sites that rely on .htaccess files) alongside my Rails apps. And, even though Apache 2.2 wasn’t my favorite thing to install (nor was it my least favorite), I’m feeling darn good about my decision. Not only have I had much success with CRAM so far, there’s plenty of evidence that the Mongrel will be around for a bit. Edge Rails now uses Mongrel by default, and it’ll even be a part of Leopard’s Rails setup.

Speaking of Rails in Leopard. Nothing surprised me more that that news. I’m still a bit dumbfounded.

So, if you are developing in Rails and are trying to decide what sort of server stack/deployment you want to use, try CRAM.