One thing most web applications need is a static page template. Now, whilst the page content might be static, the template itself might need to be dynamic – either because it’s going to change in future, or because you’ve got dynamic user information that appears in the tempalte.

So the most obvious way around this is the static controller. Dead easy, this: generate a new controller called static (or whatever you want). Then just write views for it named after pages you want. For instance: your about.rhtml file can contain all your “about” information. Then, when you hit up /static/about (to use the default routing), you get your static content, without having to make a whole page from scratch in public_html. You could even write a new 404 page on this controller.

All that remains, once it’s working, is to write some dedicated routes, and then the “static” controller can be hidden from existence – just route /about to :controller => "static", :action => "about" and you’re done. No need to write any controller logic at all!

Going on from there: one view I’ll always add to that template is the “foo” action.

So: when you’re mocking up a page, you’ll probably use lots of dummy links. Everyone expects this, because it’s obviously just a flat mock. But when you mock up an application, and show it to stakeholders in a working state, they click on things, and wonder why they get ActionController exceptions when it breaks. Also, they wonder why the link that breaks stuff is always /foo.

Obviously, it’s because I’ve left link_to "/foo" all over the shop. Have no fear: the easy way around this is to route /foo to :controller => "static", :action => "foo", and then write a static page called foo.

When you do this, the page should explain that it represents functionality that hasn’t been added yet, but will be added soon, and that the developers haven’t forgotten it.

This (from experience) reassures stakeholders that the thing that is not working will be working soon. It also means that when they do find “grey screen” errors, it either means that something’s genuinely broken, or it means that the developers really have forgotten something. Time to update that link to point to foo.

It sounds trivial, but it turned out to be an effective communication of diligence on the developer’s part, and saved much time in meetings explaining that “yes, we’re working on that”. Consider it, next time you’re developing for external stakeholders.

Sometimes, when you’re building a Rails application, you want to generate different relationships to the same model – or, rather, multiple relationships to multiple perspectives on a model. You can tell ActiveRecord to override the expected class name, but you can also use this technique to create “subsets” of classes for relationships, too. It’s worth remembering that ActiveRecord can generate these for you. By doing the query in the database, rather than filtering afterwards, your application will run faster.

As you can see from that explanation, I’m not exactly the greatest developer, so this is probably best explained with an example from life.

I’m currently working on a CMS – yawn yawn, I know. Anyhow, in this CMS, we have articles, and an Article has_many :comments. Obvious one-to-many relationship, fine. However, comments may or may not be spam, marked by the attribute is_spam. So whilst article.comments will return all the comments on a particular article, it’d be nice to have a class method that returns all the clean comments; article.clean_comments, for instance.

My first stab at this was to add the following method to the Article class:

def clean_comments
  output = []
  self.comments.each do |c|
    output << c unless c.is_spam
  end
  output
end

which is, I suppose, passable idiomatic Ruby, and which does the job; we build an output hash of objects unless the comment is spam. The problem is that if you have, say, an article with a thousand comments - of which 990 are spam, we end up having to generate 1000 objects from the database, and then filter them with Ruby. It'd be faster to select only 10 from the database in the first place, right?

We can do that by defining a new relationship. In our Article model, under has_many :comments, we can add this:

has_many :clean_comments,
         :class_name => 'Comment',
         :conditions => 'is_spam is null',
         :order => 'created_at'

Bingo. That extra has_many allows us to refer to article.clean_comments, and it'll do so directly from the database via SQL. This is a fairly simple example, and I do recommend looking up has_many and has_one (which has similar capabilities) in the Rails API documentation. There always seems to be more depth with Rails than you initially expect, so it's worth digging a little deeper - and you'll make your code leaner, quicker, and better as a result.

So I’ve been fiddling with Rio recently. I’m trying to write a little script to find and replace throughout a directory – and all its subdirectories, recursively. Given the end result of this might end up being an application based upon Rails, it seemed best to write this in Ruby. And I remembered someone (Tiest, I think) mentioning Rio at one of the LRUG meetings. So I gave it a shot.

Rio is, in short, lovely. It acts as a convenience wrapper around a whole host of modules – including Kernel, File, Dir, and others – and basically makes reading and writing files a doddle. It’s also quite powerful, and makes batch operations across directories really easy, once you’ve figured it out.

So my global find/replace script comes down to this:

rio('dirname').all.files.skip(/^\./).do |eachfile|
   eachfile < eachfile.contents.gsub("search", "replace") end

And that's it. Obviously, this being gsub, "search" can be replaced with any regular expression of your choosing. I'm sure I could do it faster in sed/awk/grep, but I'm not as familiar with them as many - and this way around, I can patch this snippet into a larger Ruby application. The skip clause forces Rio to ignore files beginning with a dot, as .DS_Store and friends cause it problems (it seems).

Anyhow, I'm very impressed with Rio - saves a lot of faffing with read and write modes - and can highly recommend it if you need to faff with the file system in Ruby.

Gavin mentions the idea that Ruby on Rails might just be the new Hypercard – something I may or may not have discussed with him.

I think he’s right. After one of the London Ruby User Group meets, someone commented that all Rails really needs now is a killer easy-front-end for page layout, or an IDE for apps of some form, and it could really hit the jackpot. I immediately thought of Hypercard; it had the requisite simplicity, grace, and convention, and would be nicely suited to Ruby (just as it was to Applescript).

I’ve mentioned Hypercard before on this site. It was pretty formative in me finding a way I could program computers that wasn’t necessarily reams of code, of first making me aware of UI design, and of making programming fun. Rails has had a similar effect, properly kick-starting me into OO programming, and finally making me understanding and appreciate scripting languages.

The speed of gettings things working, that’s what matters. Not finished – finished might be a long way off – but you’ve always got something to show for your labours. That’s why I like it.