Amy’s guide to choosing and using rails plugins (With Bonus Checklist!)

Posted by amy on November 19, 2007

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.

Further Resources

Geoffrey Grossenbach’s Nuby On Rails offers an excellent two-part tutorial on plugins: Part 1, and Part 2.

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: 23% [?]

Theoretically Related Posts
  • “Release It!” and corporate computing fun
  • 12 Steps to Testing in Rails
  • Our First Blog Post
  • Rails Pagination: Top Resources
  • Trackbacks

    Use this link to trackback from your own site.

    Comments

    Leave a response

    1. Lori Mon, 19 Nov 2007 16:24:33 UTC

      I think Robert is nuts. But one thing is for certain… he’s never used Capistrano, or he wouldn’t be spouting FUD like “Do you really want anyone who has the source to be able to deploy your app? That’s dangerous!”, which is totally untrue.

      As for the rest of your post, I agree in general “pluginitis” is a bad thing, but I don’t think plugins are only for noobs. There are many good, general-use plugins that you SHOULD be using, instead of re-inventing the wheel. It’s just that you should be using ALL of them in every Rails application you write ;-)

    2. topfunky Mon, 19 Nov 2007 20:04:27 UTC

      You can also put my vote in the ‘nuts’ column.

      * You can store your deploy.rb in a completely different repository than the code. I do this for several apps.
      * Anyone can deploy your application if they have the code and…the SSH password to your server! That’s the whole point of passwords. If you don’t want someone to deploy your application, don’t give them the password, and don’t put their public key on the server.

      As for plugins, I take the middle road. I’m not opposed to starting with a plugin, then modifying it’s source for my use. I did this for the OpenID plugin and it works the way I want it to. That’s the beauty of open source!

    3. topfunky Mon, 19 Nov 2007 20:07:17 UTC

      Actually, that should be “its”, not “it’s.”

    4. Robert Mon, 19 Nov 2007 20:55:47 UTC

      I’ve used Capistrano on several things, but prefer my own scripts for deployment.

      When I say “just anyone can deploy your app”, I obviously don’t mean everyone! What I mean is that in my experience, its best if just one person actually does the deploying. If anyone can do it that knows the password, you might step on each others toes.

    5. Robert Mon, 19 Nov 2007 22:52:39 UTC

      I also want to make a comment about plugins, which was what the article was about. One thing I didn’t tell Amy about but has been my experience is the problem of poorly optimized code in plugins for massive deployments.

      I’ve helped deploy and manage some of the biggest Rails sites out there, and when you’re scrutinizing every SQL statement and dealing with issues like partitioning data over several databases and such, plugins start to make less and less sense. Sure the code is handy to have, but in all likelihood, unless the plug-in was built with scalability in mind, you’ll pay for the use of it later down the road.

      Which brings me to Capistrano. Sure it’s great for small deployments, and I do use it on some projects. But for the big ones, you end up trying to find workarounds for things that it can’t do, or things you need to do that it isn’t well suited for.

      So my methods may seem a bit nuts sometimes, but they are born out of experience of problems we’ve faced and challenges we’ve overcome, not because I’m spreading FUD or just trying to be different.

    6. Lori Tue, 20 Nov 2007 00:02:41 UTC

      And this is an other interesting post today, showing a really good way to customize plugins.

      http://errtheblog.com/post/19679

    7. amy Tue, 20 Nov 2007 08:45:24 UTC

      Thanks, everyone for the interesting comments! I love comments! Lori: I don’t know how I missed that errtheblog post yesterday, but thanks for the link, it’s great.

    Comments