How do you choose the right Ruby stone for your next project?

Question

Suppose you spent the last six months on an outdated system project, a large, outdated enterprise web platform that integrates foreign data structures.

Now you're finally off, and you can go with a brand new Ruby startup project.

The application will be created from scratch and it is up to you to decide which stone you are going to use.

The question can be extended to various aspects of building a completely new web application, but for semplicity, just assume that you need an authentication system.

Now the last time you entered this place in Rails, it was "authlogic", and it was so great to compare whith "authentication_fu", but while you were in the "cave", you just heard about several other authentication methods that something like a gap, a device, omniauth, a warden, witchcraft, twitter-auth, open_id_authentication and others.

Even the worst, suppose you can “just imagine” that the Ruby community is awake, and six months later it blew up new ideas and paradigms for the “authentication pattern”, but you did not find the time to update.

You just want to go outside, looking at what is happening, finding all new gems and deciding that it is better to fill your next project.

How do you do this?

Thanks in advance Luca G. Soave

UPDATE Sep 18 10:36 

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

 UPDATE Sep 17 02:09 

Several people have tried to clarify the process in order to discover and select the right Ruby stone for the "next brand new Ruby project." I would like to summarize what I learned from everyone, indicating that there are basic steps in my composition:

About the decision-making process between gems in one field:

• try a few of them yourself - by semperos
• give them every test drive, make sure that there is a lot of activity on github, watching the latter commit - by ealdent

• choose Loosely Coupled Gems vs Monolitic Frameworks, giving priority to flexible and fast implementation and continuous refactoring - Craig Stuntz

• Getting an expert on the gem / domain field to be able to choose between gems - by james_schorr

• Do not select “WOW-things and Cool Fresh releases” for your client project projects, but check them daily on small and private test projects - by mikhailov

On the process of discovering and choosing the right gem, the last of which is jeremiahd, is a deep, clear and very useful description of the process:

• find around what looks like the most commonly used libraries that cover my use case.
• Take a look at your documentation to see how complete and understandable it is.
• Look at the activity in your community: updates - mailing lists - wiki - IRC - fixes - mood
• Look at your code: test suites - clean code - documents - useful comments -
• use your code
• community and code quality

• Do it as an educational process, get a better programmer and give it back to your community

  END UPDATE Sep 17 02:09

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

Answer 1

What I do (when this problem occurs in any language), I am looking around what looks like the most commonly used libraries that cover my use case. Then I will review their documentation to see how complete and understandable it is.

Next, I look at the activity in my community - are projects actively being updated? Are there easily accessible mailing lists / wiki / IRC? How active are they? What is the general tone?

Next I will look at their code . Are there any test kits? Are they test suites that help me understand the library? Is the code clean? Documented? Commented on? Does this sound like a ridiculous mess, or did he think it fits in at any moment?

Next, I use my code in a simplified, but similar way, how I really need to use it. Have I encountered any major stumbling blocks?

The screw flips the coin and sticks to it. Sooner or later, no matter what you use, it will not satisfy your needs, and you will want to change its behavior. When it comes time, community quality and code quality is what makes libraries stand out from each other.

This, of course, is a bit fuzzy. And this can be a daunting task, but you will be the best programmer for this, and if you do it enough, you will probably contribute to a return upstream to the libraries that you are using at some point, which is pretty surprising.

Answer 2

Choose one and run it. The important point is not what you are choosing now, but how hard it will be to change your mind in six months. In short, your efforts should not include one permanent solution that will bind you for the whole life of the project, but when you turn off the dependencies on the authorization system, to one (as much as possible) small and easily replaceable code bit.

Answer 3

In my opinion, you should try several of them yourself .

It seems that Devise has become some de facto choice, with mechanisms to support multiple authentication styles. This may be a good place to start, but you should obviously try to get it to do what you want, and if that doesn't work, try the other stones mentioned.

Rails does not have a built-in default authentication mechanism, since authentication tends to be specific to each project. Try a few options, see which one best suits your needs and programming style.

Answer 4

I basically agree with Craig Stuntz, you just have to select one and run with it (and create an application so that it can be changed if possible).

I suggest, however, that this means that you give them every test drive. You may not be doing this in your main project, but in fact, until you actually use this thing, you will never know how much this messed up. And no matter how much love the community throws into a gem now, you can be sure that it is a serious problem.

For relatively new gems, you also need to make sure there is something heavy on github, or something else, so that the stone will not stagnate anytime soon. If in the past few weeks I have not seen fixation, it is very difficult for me to use a gem that has not yet matured.

Answer 5

I spent a lot of time authenticating the gemstones and landed on Devise. That was great. All of the tips above are great.

Answer 6

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

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

The basic idea is to first check if you really need a stone to do what you want; Then consider how to value the Ruby gem. I also had to use authentication as a precedent so you could find this interesting.

Answer 7

This is my daily choice, as we will go tomorrow to meet the needs of our customers. How to be on the edge and keep users satisfied with a stable and reliable system?

First, we do not accept WOW stuff and Cool Fresh. We will use new things for 0.5 year, as the tesing period. Yes, we are still on Rails 2.3.10. The transition to Rails 3 will be next month for us. We have a code base with Core covered in tests, Rspec does an excellent job for us, there are about 94 tests.

But we try to use modern gems in everyday life and make small projects to see how they work. It is easy and free, take your time. Railscasts are also interested in interesting materials, it is important to see each of them.