Add Feed Discovery Links Easily

I'm working on discussion forums for NearbyGamers and I'm building the first feeds into the site. I worked up a clean way to add them from my controllers similar to my tidy stylesheets code. Here's how to do it.

In the <head> of your app/views/layouts/application.rhtml call the auto_discovery_link_tag to print the tags:

  <%- @feeds.each do |feed| -%>
    <%= auto_discovery_link_tag(:atom, *feed) %>
  <%- end -%>

In app/controllers/application.rb:

  def initialize
    @feeds = []

  def add_feed title, options={}
    @feeds << [ { 
      :controller => self.controller_name, 
      :action => self.action_name, 
      :format => 'atom' 
    }.update(options), { :title => title } ] 

And you're all set up. Where you want an action to present feeds, call add_feed. After title, it takes options for url construction.

Rails 1.2.1 Impression

I'm updating NearbyGamers to Rails 1.2.1. Nothing broke except my use of assert_tag in my tests; it's been long-regarded as squicky and has been replaced with assert_select. As I'm tidying up some deprecated code, it occurs to me that this makes for an interesting example of how I feel Rails is changing.

Rails is growing inwards and upwards, not just outwards. They're finding better, terser, more Rails-ish ways to express things. They're not piling on features, they're condensing. I've mentioned that this is what coding in Rails continually feels like: sometimes it just feels off even though it works and is nicer than other languages, and soon I realize a beautiful Right Way to do it.

Where Rails gained new features, the developers have redesigned functionality to make me think, "Wow, of course, that's obviously much nicer" and it does more because it's better-designed. Let me give you an example using assert_tag.

GET and POST variable hashes in Ruby on Rails

In Rails, you access GET, POST, and routing variables through the params hash. This works almost all the time, except when you duplicate a variable name: routing overwrites GET overwrites POST.

For an app I'm working on I actually had to care where a variable comes from, so I dug for a while to find out how to access the raw hashes. It ain't pretty, but here it is in case anyone else ends up needing it:

get = CGIMethods.parse_query_paremeters(@request.query_string)
post = CGIMethods.parse_query_parameters(@request.raw_post) 
# you'd think you could use @request.query_parameters and
# @request.request_parameters, but they're update()d by route vars
route = @request.path_parameters

(Also, don't ask about this in #rubyonrails -- you'll just get lectured on how you don't really want to access the hashes, how you should rename all your variables and URLs, and how it simply isn't possible. This will be very frustrating and totally unproductive.)

Rails Makes Valid XHTML Easier

I'm working on a Rails site in my Copious Free Time and I wanted to share a little way that Ruby made my life easier. I'm making my pages valid XHTML 1.0 Transitional because it makes life easier to find bugs and it just feels good to know I'm meeting the spec.

The W3C Validator complained that I didn't have the rows and cols attributes on my <textarea> tags. My code for them looked like:

<%= text_area_tag :message, params[:message] %>

And I don't want to add the :size option because I use CSS to style all of them, it'd be confusing to see an unused size there. So I extended the text_area_tag method in my app/helpers/application_helper.rb to fill in a default:

module ApplicationHelper
  def text_area_tag(name, content=nil, options={})
    super(name, content, { :size => "40x10" }.update(options))

What does Ruby on Rails Have to Offer a "Java Guy"?


I have been working as a "Java Guy" for roughly five years now. The majority of my work has been component / library development, and it has been enjoyable on the whole. However, I have also had a few unfortunate “Java web” development projects. These experiences have not been something I hope to repeat often. I am not going to re-describe the Java / J2EE deficiencies in the Web UI layer, but I will go over a few examples of how messy it can get and why Ruby on Rails makes me smile. :)

Tidy Stylesheets in Rails

It's very easy for a site's CSS to grow a single giant, brittle stylesheet. It becomes impossible to change anything because of bizarre interactions between elements, unexpected interactions, and simply because it's just too big for anyone to understand. Much of programming is managing complexity, and I'll share a nice technique in that vein.

I like to break down stylesheets so there's a site-wide stylesheet with global stylings like fonts, the site's template, and common elements. This is the file that metastasizes on you.

My solution is to break down stylesheets by controller and action, and Rails makes this quite easy:

# app/views/layout/application.rb
<%= stylesheet_link_tag *(['global'] + @stylesheets) %>
# app/controllers/application.rb
class ApplicationController < ActionController::Base
  before_filter :add_stylesheets

  def initialize
    @stylesheets = []

  def add_stylesheets
    ["#{controller_name}/_controller", "#{controller_name}/#{action_name}"].each do |stylesheet|

This Week in Rails

Here's the second edition of this week in Rails. This week I'm keeping things short and sweet.

This Week in Rails

Welcome to the first post in a new series which focuses on Ruby and more specifically, Ruby on Rails. My goal is to provide links and a little bit of commentary on interesting blog posts and discussions from the previous week. I have my rss reader pointed to a bunch of Ruby focused blogs, but I'm sure there are things of interest that will slip past me. If you notice something that you think is worth sharing or a blog I seem to be ignoring, please don't hesitate to contact me directly or post in the previous week's discussion.

There are a number of ways I can go with the week in review. I could provide links to a bunch of stuff in the blogosphere or provide just a few links with my own thoughts. Right now I'm leaning towards around five links per week. I could certainly provide more, but I'm worried about inundating people with too much material (a problem I have with my own growing list of rss subscriptions).

While I won't be doing it this week, I would also like to talk about anything I think is noteworthy from the Rails Google Group and possibly write about any interesting commits from the Rails core team. As always, feedback is greatly appreciated.

Without further delay, here's a little roundup of Ruby and Rails related posts from the last seven days.

Ruby on Rails - Code Generator as a member of your Team

One of the most interesting features of Ruby on Rails that increase its popularity is undoubtedly built-in source code generator. This only feature saves a lot of typing, allows developers to add features to the framework, encourages creating new generators for repetitive tasks. In the end it saves a lot of time and effort.

Most of Ruby on Rails projects start from code generation. And code generation is used throughout the project to add new controllers, views and models. For example:

script/generate controller Product list new edit

creates stubs for your product controller and three views to list, to create new, or to update products. You can remove controllers and views with 'script/destroy' command. You can also ask Ruby on Rails generator to automatically add newly created files to a subversion repository. Sweet! But keep reading...

I Spec, You Spec, We RSpec!

I love testing, I could hardly wait for this meeting of the Chicago Ruby Group. I was not disappointed. Unit tests are cool, but specs are awesome. Whats the difference you say? I think its a more natural way to write your tests, it makes you think of the behaviour of your object and not "oh gosh, I have to write 3 tests for each of my methods."