A common question that new Ruby developers ask is how to pick a Ruby gem for certain functionality that they want in their application. And here is how we typically answer that question:

First you want to ask if you really need a gem. Ruby is a succinct and low ceremony language, and it could take just a few lines of code to implement the functionality you need. Then you know exactly where it is and what it does. You have full control of the code and future maintenance will be easy.

For non-trivial solutions, you want to look at the nature of the problem. Typically "infrastructure" type of concerns, such as adding a queuing mechanism or managing file uploads, are better candidates for gems; while application specific concerns are better for hand rolled solutions. Take authentication as an example - if your application's authentication work flow is the simple "register -> email confirmation -> login -> logout", then it is more of an infrastructure concern, therefore picking a gem is appropriate. However if your authentication work flow is, for example, "apply for an account -> someone approves it -> process payment -> login -> challenge with a random question -> gain access", there is a lot of application specific logic and you will be better off rolling your own, or at the very least, pick a really light weight authentication solution that you can easily mold with your own will.

When you decide to use a gem, you want to pick one carefully. Make sure you know your options. Subscribe to publications such as Ruby Weekly, the Ruby5 Podcast and Ruby Flow to keep up with the development in the community to know the current "best of breed" solutions. Check out the Ruby Toolbox to see gem options by functionality.

When you evaluate a gem, know that you are injecting someone's code in your application, and you should treat it as seriously as your own. you want to check the following:

• Does the gem have good test coverage? Just like you want to test your own production code, you want to have confidence that the gem's code is thoroughly tested.

• Is the gem still at its infancy or matured and ready for production? You can tell that by looking at the gem's Github repository - most Ruby gems are hosted on Github nowadays - how long ago was it created? Look at the issues list, is there a long list of concerns to be addressed or lots of bugs to be fixed? More matured projects tend to have been around for some time, with more "maintenance / bug fix" issues than features to be completed.

• Is the gem actively maintained? Are bugs fixed quickly? Is there a community around the gem? Check when the last commit was and how many commits there are for the last 3 months. See how many people have starred the project, and how many have forked and submitted pull requests.

• Is the gem well documented? Does it tell you how to install, configure and use it? Is there a project wiki? Is there sample code or even better, a sample project? Is there a RailsCast for it?

• Google to see people's opinions about it. Do developers recommend it on their blogs? Is it consistently recommended as solutions on sites like Stack Overflow?

Finally, after you pick your favorite gem, please don't fall in love... In the fast evolving community of Ruby, new and better solutions constantly come up. If it starts to give you more headache than happiness, do not hesitate to dump it for a new one.

Comments are welcome.