Empty Thoughts

There’s been some buzz lately about Hobo, a plugin extension to the Rails framework that makes it easy to do rapid prototyping of web applications. You can find out about all of the features at the HoboCentral website. One exciting feature is the implementation of DRYML, a way of drying up your views and providing extendable tag libraries.

Check out the screencasts. They’re very well done. I haven’t been this stunned by a screencast since I saw the original DHH Rails screencast. It’s exciting times.

The fine folks developing Slate, a content management system for Rails, have just released a Textile Editor plugin. This works well in conjunction with Err the Blog’s acts_as_textiled plugin.

About a week or two ago I emailed Benjamin Curtis, creator of the Agile Web Development plugin repository. I asked him if he would add the ability for users to be able to save a list of favorite plugins that they use all the time. I wanted a place to keep track of all the plugins I am interested in so I don’t have to keep going back and searching for them every time. I was pleasantly surprised when he emailed me back about a week later and said that he had implemented it. It works perfectly.

If you’re not familiar with Benjamin’s repository, I recommend that you head on over there as soon as you have a few spare hours. It’s easy to get lost in all the great plugins that are being developed. Thanks Benjamin and keep up the good work.

I’m a bit of a plugin hound. I really like the approach of Rails plugins because they force the implementor to offer up small ideas in a concise package. Also, plugins are easy to grok. Generally you can spend a small amount of time investigating what’s in the lib directory and get the essesense of the implementation. Often you can learn alot by looking at the plugin code. There’s some pretty impressive code out there. That said, not all plugins are created equal.

Some come without documentation. Many come without tests. You have to be aware of the code that you’re injecting into your Rails application. Does it play nicely with what else is going on in your app, or does it take more of a brute force approach? All of these things become important in the decision to use a plugin or not. Do you recognize and trust the author? What level of dependency will your application have on the plugin. In other words, if you need to upgrade Rails and the plugin is not longer supported, what impact will that have on your application?

Plugins are a great tool and there’s a tremendous number of plugins in the wild. But not all plugins are the same. Be smart about what you choose to use. Figure out a good list of criteria that works for you, and evaluate accordingly.

I recently started using Topfunky’s Power Tools Plugin to clean up some of my testing routines. It’s a nice little package that brings together lots of different asserts that have been out there in the wild in one form or another.

I really enjoy the assert_required_fields method. I used to implement my model checking like so:

def test_should_require_login
  assert_no_difference User, :count do
    u = create_user(:login => nil)
    assert u.errors.on(:login)
  end
end

...and now with the Topfunky Power Tools Plugin I end up with the following:

def test_should_require_login_password
  assert_required_fields :create_user, :login, :password
end

Notice how it allows you to check multiple fields at once. There’s a lot more available in the plugin, but sometimes all it takes is one or two little things to make your day.