Blocks rock and I couldn’t agree more. The functional programming aspect of ruby has started to interest me more and more. Blocks are used all over the place, with respond_to, collect, returning, and ActionView::Helpers::FormHelper#form_for.

Sometimes, a design requires a little extra markup, perhaps something to get that rounded corner to work or whathave you. Now let’s say this piece of code requires certain classes, a certain kind of structure, including a tile, and has to be used in many places, something like a sidebar piece. Instead of copying and pasting this structure over and over, you can use a helper to make you life easier, and if you combine it with a block, it will just feel even more painless.

Read the rest of this entry »

4

DRYing Up respond_to

Posted in Ruby on Rails at November 26th, 2006 / 4 Comments »

Now that that release candidate for rails 1.2 is out, people are going to have even more reasons to use the respond_to method in their controller methods. With that, there may come some unsettling feeling that you’re just repeating yourself over and over again.

def index
  @articles = Article.find(:all)
  respond_to do |format|
    format.html
    format.xml { render :xml => @articles.to_xml }
  end
end

def show
  @article = Article.find(params[:id])
  respond_to do |format|
    format.html
    format.xml { render :xml => @article.to_xml }
  end
end

If we want to use the respond_to, we have to make sure it’s in all of our methods. Wouldn’t it be easier to just do something like this?

def index
  @articles = Article.find(:all)
  format.html
  format.xml { render :xml => @articles.to_xml }
end

Doing it this way, we don’t have to write 2 extra lines per method, and we don’t increase our indentation. While that’s not a huge thing, I still just don’t like to constantly write out those lines when I don’t have to when I think we can build something a little trickier.

Read the rest of this entry »

This is a fairly simple little tidbit, but still useful. Sometimes I want to have a script for my rails application, like running some reports on the data. There are two basic ways to do this: write a task(rake), or create a new ruby script file, like in the scripts directory.

If you want to do the latter, then there are two lines you my want to put at the top of your script.

ENV['RAILS_ENV'] = ARGV.first || ENV['RAILS_ENV'] || ‘development’
require File.expand_path(File.dirname(__FILE__) + "/../config/environment")

The first line allows us to supply which environment we would like to run the script in. Say the script is called process.rb, we could call the script like ./process.rb production and now the environment is set to production.

The second line loads the environment file. Now all of rails, your models, libraries, and plugins are available to you.

5

Loading Fixtures in a Migration

Posted in Ruby on Rails at September 28th, 2006 / 5 Comments »

I love migrations. I think they are one of the best things about rails. I love that I can count on any changes I’ve done in the database to be consistent across all other databases that I use. Love it.

Sometimes I find that I want pre-load my database with some data, like categories that I have. For testing purposes, I have already created this data in my fixture; now I just want to load that fixture into my database from a migration call.

I know that there is a rake task for this, so I looked into that code and came up with a little something.

Read the rest of this entry »

0

Sleeping Easier with Migrations

Posted in Ruby on Rails at September 28th, 2006 / No Comments »

As a rails user who loves migrations, I have noticed that all of the migrations are prefixed with three decimal places, like 001_create_sessions.rb or something of that nature. That got me thinking, what would happen after I had 999 migrations?

That sets of the paranoia level up because who knows, I may need 1001 migrations! So to settle this once and for all, I wrote a script that would generate 999 migrations for me. I ran the 1000 migration and then it created 1001_test1001.rb.

Good news! Rails doesn’t constrain its migrations to a 3 decimal place prefix. So pointless…

Beast is a nice, light-weight forum written in Rails. From what I can gather, the overall goal is to make something work with only 500 lines of code, and I think that could happen with this. It is open source, and can easily be checked out.

I did check it out and I have to say that I’m impressed. It is using the rails edge and is trying out some of the RESTful stuff all the while adhering to the philosophies of CRUD. I have wanted to look into a good example of a rails project using REST, and this code base is great for that. What’s more is that it’s not very difficult to wrap your head around all of the code of the site, due to the small code base and nice abstraction of the code.

Read the rest of this entry »

A couple of months ago, I was shown the article that DHH wrote after he gave his presentation at RailsConf 2006. I looked at it then and kind of shrugged it off, mainly because I really didn’t know what the presentation was really about.

Tonight I found video of that presentation and I got excited about CRUD. It pointed out that I’ve been making some controllers a little bloated. I have coupled much functionality into one controller; when looking back, I clearly could have separated out some functionality.

Read the rest of this entry »