Overall, a good summary.

> Since there is no more will_paginate in Rails 3, the only option is kaminari.

This version of will_paginate seems to be fine in Rails 3:

https://github.com/mislav/will_paginate/tree/v3.0.pre2

While I'm on the Rails 3 things you can find on Github topic, ActiveScaffold has a nice Rails 3 port here:

https://github.com/vhochstein/active_scaffold

while will_paginate works fine on rails 3 it pollutes Array which kaminari doesn't. it's an easy switch as well (unless your doing some really custom stuff)

Be careful-- kaminari is much, much slower than will_paginate: https://github.com/amatsuda/kaminari/issues/37

will_paginate may pollute Array, but it's been a great solution, that has worked for a long time. Be wary of upgrading for the sake of upgrading, especially with that kind of performance degradation.

I always get so much out of these kinds of roundups. It would be great if somebody smart did them on a regular schedule.

Ruby Toolbox is great too: http://ruby-toolbox.com/

I'd be surprised if anyone that has built a few significant rails applications with devise would continue to use it. Unless you're going to have the most vanilla session/user/authentication management ever, fighting against devise gets downright nasty.

Have had moderate success with https://github.com/NoamB/sorcery lately, however I'm not yet confident in calling this a solved problem.

edit: Devise is great for getting up and running quickly. For that matter though, so is Joomla.

I recently started a rather large Rails project and am using Devise. Currently with authentication being pretty low on the list of things to do, it has helped get something in place rather quickly. Can you expand on the disadvantages of using Devise over time (and maybe compare it to your experiences woth Sorcery)?

I haven't used sorcery, but I have just finished quite a large rails project in which I decided on Devise right at the start. It was great in the beginning, but as soon as I needed custom behavior, it became more of a liability than a help. Doing simple things like changing a redirect on sign up or sign in, and a few other customizations were chores, some of which required overriding core devise classes, and I am still not really happy with the fixes.

If I were doing an app with standard model authentication, a Forum for example, I would use devise again in a heart-beat, but for any other project where I expect to have any slightly customized behavior at all, Ill be rolling my own.

Devise is brilliant if you want something straight-forward, but it is big, complicated (internally), and not very flexible.

> I'd be surprised if anyone that has built a few significant rails applications with devise would continue to use it. Unless you're going to have the most vanilla session/user/authentication management ever, fighting against devise gets downright nasty.

Authentication can get downright nasty no matter which solution you use, but Devise does a lot of things well, is actively maintained, and well documented. In fact all of the gems from Jose Valim, including inherited_resources and simple_forms are such first rate plugins, it's difficult to imagine anyone throwing any of his work under the bus.

I've been using AuthLogic (https://github.com/binarylogic/authlogic) for a long time now and appreciate how it does what I need from the beginning but also grows with the application. There was a period where the author was not working on it but now he has committed to continue developing it.

It's true, if you want to modify anything important in devise you pretty much have to know it inside and out. There's no baby steps with devise. I use it anyway and just do things its way. I'm lazy, and if I have to write my own forgotten password again code I'll go crazy.

Sorcery looks cool. Thanks for the heads up.

Is there any reason not to just roll your own auth, with something like http://railscasts.com/episodes/250-authentication-from-scrat... and add omniauth if you want to use OAuth? It's not much more work than getting devise running, and it gives you the flexibility to do pretty much whatever you want in terms of fitting auth into your app.

(Also, it works fine with CanCan, which is brilliant and does a good job at staying out of your way.)

The best resource in my opinion is http://www.ruby-toolbox.com/.

For Geocoding, here's another nice gem that uses Google/Yahoo/Freegeoip: https://github.com/alexreisner/geocoder.

Do you know how it compares to Geokit?

I just switched from geokit to geocoder in the app I'm building. I found geocoder to be significantly better for my purposes.

Can you expound upon that? What limits did you hit, how has geocoder fixed those, etc?

No technical limits were hit. They have nearly the same feature set.

Geocoder's api feels a little bit more modern Geokit (rails3 vs 2). Having read the code for both, Geocoder was cleaner and would be easier to tweak if necessary.

So really it's just a preference: they do the same thing.

This is an awesome resource, there is an overwhelming amount of choice for people that are new to Rails development (I am encountering this myself at the moment).

While I hope to eventually be able to pick which gems I like to use best, for a beginner this kind of guidance is really valuable.

Beginner or not, every time I stand up a new Rails application I find picking my head up and seeing what gems others are using is well worth the investment. References like this, along with recent Railscasts etc., are invaluable.

Agreed. Unfortunately I think it's becoming more difficult for beginners to get up and running with Rails. Perhaps that's how a community evolves... or perhaps I'm no longer the target audience ;)

I agree, what he doesn't say is how much effort is often needed to get all of the moving parts working together. For example, integrating Devise with RSpec and Cucumber. And then switching to an ORM such as Mongoid. A good tutorial like Michael Hartl's teaches the basics of Rails but putting together your basic starter app can get complicated. Sometimes it takes combing through a dozen (mostly outdated) blog posts to find how things are supposed to be done "Time.now".

I recently put together several detailed tutorials along with application templates that generate Rails starter apps using Devise, OmniAuth, RSpec, Cucumber, plus options for jQuery, Haml, etc. I loaded them up to my GitHub account and initially I was surprised at how many people were expressing appreciation and encouraging me to do more. Now I think I realize, it's not easy for many people to keep up with the ever-evolving Rails habitat. There's really a need for guidance that goes beyond the good intro tutorials and shows the steps need to assemble the pieces for real-world projects.

edit:

Here's a link to my GitHub account with the various example apps and tutorials:

https://github.com/fortuity

I've used your rails3_devise_wizard to get-up-and-running on a recent project, and to experiment with difference stacks and it is really useful. Projects like yours and http://railswizard.org are really useful for customizing the default Rails3 stack and customizing a customization of a given stack. Thank you.

Thanks so much for this. There are so many rails tutorials for absolute beginners, and lots of stuff that assumes expert knowledge, but not much, besides practice, to span the gap.

I found most of the official resources to be good, the issue I often run into is that if you google for anything you will end up on a blog post from 2007 about Rails 2 that doesn't really apply anymore.

Select a time range in Google search. For Rails stuffs I usually do 6 months (custom range).

Or maybe it will be the death of Rails.

The alure once was how quickly developers can build web apps. It seems to be becoming more limited to how quickly experienced Rails developers can build web apps.

We used active_scaffold for an internal project. Its awesome to get a basic CRUD app going. https://github.com/vhochstein/active_scaffold

I'm a long time AS fan. While there are many rails crud/scaffold/admin plugins, and I have analysed them all, none beats the power, customisability and featurefullness of AS.

The only thing that holds it back is the learning curve, wich is strange, because behind it is just plain rails philosophy: controller methods + views with a tasty DSL to plug them together.

A big thanks to Volker for his huge work on pushing it to rails3 compatibility.

The current rails3 branch (Volker's) it very stable.

What remains to be done to make it even more awesome is:

* use nested_attributes_for and clean the custom nested attrs logic

* clean security layer witch at the moment uses gobals (and can only be used in shared nothing deploy)

* request local configuration copy to make it more runtimeasible, at the moment it uses a class var (global-ish) that, for some customisations, needs to be altered per request, and that again leads to only-shared-nothing-deploy

* ActiveModel API so Mongoid can join the fun too

* a child gem that bundles AS to make a fully featured admin interface, competing with rails_admin & friends.

We recently published a similar list of gem preferences at http://renderedtext.com/toolbox.

I think is worth to mention http://railswizard.org/ if beginners are in focus.

Great list. It confirms a lot of my findings over the last few months.

Side note: I wish the Rails team would take more of the Django approach and build some of these features into the core.

Great summary - it's hard to know what gems to use for a given problem and a curated summary from someone in the know is extremely valuable. Thanks!