Amy’s guide to choosing and using rails plugins (With Bonus Checklist!)
Last week a student asked for advice about rails plugins: where to find them, how to evaluate them, and how to use them. I promised a blog entry on the subject, since it’s been on my topic list for three months and I’m behind on blog entries anyway. so here it is.
Where to find plugins
www.agilewebdevelopment.com is one of the main rails plugin directories. It has a stars and comment system for the listings, but given the number of rails developers out there in the world, there is surprisingly little community activity, so you have to take both the stars and the comments with a grain of salt. (And many of the comments are of the “I installed your plugin and it does not work. How do I fix it?” variety.) Nevertheless, it is the largest plugin directory I know of. And here’s the ruby-on-rails core plugin repository.
After that: google is your friend.
When should you look for a plugin?
Lots of people use acts_as_authenticated or restful_authentication as their starting points for user authentication, so it’s a good idea to become familiar with them yourself, even if you plan to roll your own auth code, because people frequently talk about general auth issues in the context of those plugins.
If you have to implement something that every single web 2.0 site out there has, it’s worth looking for a plugin. DHH wrote the quintessential web2.0 plugin, acts_as_taggable, although there’s also the popular acts_as_taggable_on_steroids. Rick Olsen aka technoweenie, who is a busy plugin bee, provides attachment_fu, which is an easy way to provide gravatars and other image upload/processing capability to your app. will_paginate is the current pagination code flavor of the week (You know not to use rails’ built-in pagination, right? It’s getting yanked out in rails2 anyway). There are a bunch of tutorials on adding star ratings to your app with one of the rateable plugins and some CSS.
Some plugins are more general-use and are meant to make your life as a rails developer easier and more fun. Sexy migrations, for example, DRY up migrations, and were such a popular plugin that they’ve been integrated into rails 2. Annotate-models is a plugin Dave Thomas wrote that adds some comments to your model objects telling you what precisely their database tables look like, so you don’t have to dig around in schema.rb. There are some plugins to improve active record finds, which are generally useful. There are helper plugins, builder plugins, markup plugins, and just plain silly plugins (acts_as_enterprisey).
When you first start using rails, you can go a little plugin-crazy. OMG, I never have to write any code again! you think, and get lost in an orgy of plugin downloads and installations.
Don’t get too excited yet.
I just had a discussion with Robert Oliver of OCS Solutions, rails fellow-traveler and current collaborator on a client project, about the value of plugins. He doesn’t use ‘em much. (“And I don’t use capistrano, either!” he says. “I am a rails heretic! Burn me at the stake!”* ) Anyway, so Robert says plugins are rarely exactly what you need, and it’s too much trouble to put them in and then rip them out when you discover they’re not precisely what you wanted. I say that if they save you time when you start out, and later you have to modify them to suit your purposes, it’s still saved you time, as you probably would have had to modify whatever you wrote yourself too. He says, yeah, but it’s easier to mod your own code than it is to mod other peoples’ code.
Robert has been developing in rails longer than I have, and the more I think about it, the more I think he’s probably right, and that I am only now coming out of the newb over-reliance on plugins phase. Some of the advantages of publicly available plugins fade as you get more familiar yourself with how to make things happen in rails. Rather like scaffolding, which seems awesome at the beginning, and then you realize that the generated code is not that useful. (Note that the advantages of the plugin format for your own code re-use remain after the first flush of newb plugin-love fades.)
For a rails newb, though, plugins do serve some important purposes. Their very lack of documentation and YMMV nature forces you to read the code. sometimes repeatedly. Not all plugin code is worth a damn, of course, but, especially for some of the plugins put out by rails-core members or other luminaries, a lot of it is good stuff. Complex good stuff, full of ruby idioms, metaprogramming, and other stuff the newbie rails developer thinks of as magic. After a while, when you’ve looked at similar magic sixty different times, it starts to become slightly less magic. Oh yes, you think, when you see something like
ActiveRecord::Base.send(:extend, Technoweenie::AttachmentFu::ActMethods), there they are mixing themselves into your models for you. And, of course, generous use of plugins is an excellent way to convince non-technical clients that you are a total rails ninja. Hey, look ma, I implemented full-text search in 20 minutes!
Bonus Checklist for choosing and using rails plugins
- Who wrote it? Are they a big name in the community?
- Or: do big names use it and talk about it?
- What kind of documentation, both original and blogged/forum’ed can you find about it?
- What do people say about it?
- What’s the code look like?
- Is it really worthwhile for you to use it, or should you just review it for a general approach to the problem you’re trying to solve and then write your own code?
- Does it have tests? Do the tests run?
- Do you really need what the plugin gives you, or are you just putting it into your app because you can? (does every single thing on the web really need to be friendable? )
- Any glaring security issues? SQL injection, passwords in the clear, unescaped html, etc.?
- Read the readme. It may be thin. But it should tell you at the very least the steps you need to take to get going with it, which might include generating some code, running a migration, adding a line or two to a model class, etc.
- You have to read the code. Did I mention that? Look at the code. Don’t use a plugin whose code you haven’t looked at! And also, read the code.
There’s a whole short cut (or whatever it’s called — you know, one of those mini-e-books) about Rails Plugins. It looks pretty good, but i’ve only skimmed it on Safari. If you plan to write your own, check it out.
On the Proliferation of Crappy Plugins
Dear readers: please think twice about releasing your own plugin into the wild just so you can check off the ‘wrote plugin’ item on Working With Rails. Please make a plugin you release generally useful, reasonably well-tested, secure (don’t leave your plugin finder methods vulnerable to sql injection, for example), and documented. If it’s similar to another plugin already out there, be sure to point out how yours is different in a way that helps people choose between them. Plugins are a fantastic way to re-use code on your own projects, but not all such code really wants to be free. Is this a heretical anti-Open-Source comment that I should not be making? I am not sure. Anyway, I am sure that someone will turn around and suggest that I quit littering the internets with my crappy blog posts.
robert says: “as for capistrano.. Do you really want anyone who has the source to be able to deploy your app? That’s dangerous! Use custom scripts.. They’re easier to write than capistrano tasks and you must have access to the servers to run them!”
Popularity: 24% [?]
Theoretically Related Posts
Use this link to trackback from your own site.