How do you choose the right Ruby gem for your next project? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago.

Suppose you spent the last six months on a legacy system project, large corp obsolete web platform, integrating alien data structures.

Now you are finally off and you can go with a brand new startup project in Ruby.

The application will be built from scratch and is up to you to decide which gem you are going to use.

The question can be extended to the various aspects of building a brand new web application, but 开发者_C百科for semplicity, just suppose you need an authentication system.

Now, the last time you put in place that in Rails, was "authlogic" and it was so cool compared whith "authentication_fu", but while you where "in the cave" you just heard about several other way to authenticate, something like clearance, device, omniauth, warden, sorcery, twitter-auth, open_id_authentication and may others.

Even worst, suppose you can "just imagine" Ruby community is not sleeping and in six months, she was blowing up new ideas and paradigms about "authentication pattern" but you didn't find the time to be updated.

You just want to go outside there, having a look at what's going on, finding all the new gem arising and deciding what fill better your next project.

How do you do it ?

Thanks in advance Luca G. Soave

UPDATE Sep 18 10:36

Ruby toolbox compares gems in the same category by the metrics described - by Andrew Grimm

UPDATE Sep 17 02:09 

Several people tried to clarify the process to discover and choose the right Ruby gem for "the next brand new Ruby project". I'd like to summarize what I learned from everyone by listing what in my comprension are the main steps :

About the process of deciding between gems in the same field:

1. try a few of them yourself - by semperos

2. give them each a test drive, make sure there is heavy activity on github, watching last commits - by ealdent

3. choose the the Loosely Coupled Gems vs Monolitic Frameworks, giving priority to agile and fast implementation and continuous refactoring - by Craig Stuntz

4. getting expert of a gem/domain field, in order to be able to decide between gems - by james_schorr

5. don’t choose “WOW-things and Cool Fresh releases” for your production client projects, but test it daily on minor and private testing projets - by mikhailov

About the process to discover & choose the right gem, the last one by jeremiahd, is a deep, clear and very useful description of the process :

• search around for what seem like the most commonly installed libraries that cover my use case

• take a look at their documentation, to see how complete and readable it seems

• look at the activity in their community : updates - mailing lists - wiki - IRC - commits - mood

• look at their code : test suites - clean code - documents - useful comments -

• use their code

• quality of the community and code

• do it as a learning process, get a better programmer and give back to your community

  END UPDATE Sep 17 02:09

Feel free to add more, ... share your point of view.

---

What I do (when this problem rears it's head in any language) is I search around for what seem like the most commonly installed libraries that cover my use case. I then take a look at their documentation, to see how complete and readable it seems.

Next I look at the activity in their community -- are projects actively updated? Are there easily accessible mailing lists / a wiki/ IRC? How active are they? What's the general tone?

Next I look at their code. Are there test suites? Are they test suites that help me understand the library? Is the code clean? Documented? Commented usefully? Does it look like a ridiculous mess, or like it's had thought put into it at every point?

Next I use their code in a simplified, but similar, manner to how I actually need to use it. Did I run into any major stumbling blocks?

Screw flipping a coin and sticking with it. Sooner or later, whatever lib you're using isn't going to serve your needs, and you'll want to modify it's behavior. When that time comes, the quality of the community and the quality of the code are what make libraries stand out from one another.

This is, of course, a bit fuzzy. And it can be a challenging thing to do, but you'll be a better programmer for it, and assuming you do it enough, you'll probably be contributing back upstream to the libraries you use at some point, which is pretty awesome.

---

Pick one and run with it. The important point is not what you choose right now, but how hard it will be to change your mind six months down the road. In short, your efforts should not go into making one, permanent decision which will bind you for the lifetime of the project, but on isolating the dependencies on the authorization system to a single (as much as possible) small and easily swapped bit of code.

---

In my opinion, you should try a few of them yourself.

It seems that Devise has become somewhat of a de facto choice, with mechanisms to support a variety of authentication styles. That might be a nice place to start, but you should obviously try to make it do what you want, and if it doesn't work, try others of the gems you mention.

Rails does not have a "default" authentication mechanism pre-built because authentication tends to be specific to each project. Try several out, see which one fits your needs and programming style best.

---

I mostly agree with Craig Stuntz, you should just pick one and run with it (and build your app so that it can be swapped out, if possible).

I will suggest, however, that doing that means you give them each a test drive. Perhaps you don't do that in your main project, but really, until you actually use the thing, you will never know just how messed up it is. And no matter how much love the community is throwing at a gem today, you can be sure there are serious issues with it.

For relatively new gems, you also need to make sure there is heavy activity on github or whatever, so that the gem isn't going to stagnate any time soon. If I don't see a commit in the past few weeks, it makes me really uneasy about using a gem that isn't already mature.

---

I spent a lot of time looking at authentication gems and landed on Devise. It's been great. All of the above tips are great.

---

I wrote a blog post on this very question - How to pick the right Ruby Gem?

http://www.railstutors.com/blog/how-to-pick-the-right-ruby-gem

The main idea - First check if really need a gem to do what you want; Then some consideration on how to evaluate a Ruby gem. I also happened to use an Authentication as use case so you may find that interesting.

---

It is my daily choice, what is the way we go tomorrow to satisfy our clients needs. How to be on the edge and keep users happy with stable and reliable system?

First off, we do not accept WOW-things and Cool Fresh releases. We will use new things in 0.5 year, as a tesing period. Yes, we still on Rails 2.3.10. Upgrade to Rails 3 will be next month for us. We have codebase with Core covered by tests, Rspec do great job for us, there is about 94 tests.

But, we try modern gems during daily development and do small projects to see how they work. It's easy and free, take the time only. Railscasts satisfy interest in cool stuff too, it's important to see each of them.