27 gems for every project. While the list has a lot of interesting features and things that I agree are necessary, how many additional dependencies get pulled in total, and how the heck do you keep the versions and releases in check for each one?
The major releases of Ruby itself have had fairly minor changes and are well-telegraphed, so breakage is low there. And Ruby has a rich, stable standard library so each of these gems rarely needs to depend on too many other gems. When there are version requirements, they tend to be broad and optimistic (“at least version 2.3” rather than “at least 2.3 but not greater than 2.x”). I’ve touched a couple dozen projects as a consultant and I think I’ve seen the problem of two gems needing incompatible versions of a shared dependency maybe twice since 2006.
As a practical matter you list the gem in your Gemfile and install with bundle install, which checks requirements and lists specific versions of all gems (including dependencies) so that your whole team is running the exact same version of everything. If you need to resolve an issue, you can list a range or specific version in your Gemfile.
And if worse comes to worst, nearly everything is open source. If you’re in a hurry to deal with an incompatibility, you can fork a gem, make your two line tweak, point your Gemfile requirement to that repo, and leave yourself a comment saying “this has a patch for [frustrating thing here], hopefully Foo 2.4 will fix it, here’s how to test”.
I really really dislike the aasm gem. The stack traces on state transition failures due to :guard clauses are super not obvious and very hard to debug unless you’ve run into it before.
I’ve seen a lot of use of aasm and similar gems, and I’ve yet to see a use that wasn’t improved by modeling separate objects. They seem like the perfect thing when there’s a handful of states and transitions, and then suddenly there’s an object with no invariants because it plays a dozen roles.
I always liked the workflow-gem a lot better than aasm. In terms of definition of states and events. I never had a problem with their stack traces. But unfortunately it is also sort of abandoned.
Another project used the state_machines-gem. I really, really dislike the syntax of defining the state machine itself. But imho it is the most actively developed and I think this is the one I’d look at first when starting a new project.
I don’t code Ruby much these days, but I actually really enjoyed looking through this list. It’s really interesting to see what the equivalents of a lot of Django libraries are these days (and it’s interesting to see the different approaches Ruby uses for a lot of these things).
Nice list. I’ve used a few of these, and a few others sound worth checking out. I can vouch for devise, devise_invitable, bootstrap-sass, kaminari. I’ve also come to prefer rspec-rails and factory_girl_rails over the stock Rails testing and fixture code. Setting up YAML fixtures gets ugly fast once you have more than one or two models that depend on each other. Using factory_girl instead lets each test have exactly the DB data that it needs and nothing else. And the rspec assertion and mocking is great, plus I think it gives you much better options for how to organize tests.
I will say that I prefer delayed_job and regular DB jobs over sidekiq and redis. I’ve also gotten to prefer sending all logs to a third-party aggregator rather than doing something with just exceptions like whatever rollbar apparently does.
I might try moving one of my projects which uses cancan to cancancan, as the former is apparently abandoned at the Rails 4.2 compatibility level.
Its always wonderful when you find a gem that does just what you needed and saves you a week of programming. Unfortunately a lot of the smaller gems are unmaintained and your pull requests wont be seen.