So I drill down:
lib...
badger...
core...
Claws and teeth? WTF are these? How do they relate to each other?
When I start reading the code, I constantly have to maintain a mental map between the metaphorical basis of these claws and teeth. It strikes me as useless mental baggage when I'm trying to understand how something works.
I'm probably a little bit oversensitive to this because of an experience I had with a Ruby IRC bot library called Autumn [1]. It's a very neat little library, but I got stuck in a very frustrating pattern. I would get Autumn set up the way I like it, then not touch it for a long time. Every time I circled back to it, I had to re-learn what Seasons and Leaves were. They could just as easily have been named Contexts and Bots.
Sorry for the negativity, because I'm otherwise liking the project. I'm going to give it a shot on our test-build infrastructure!
We also have support for best practices with resque and multiple app servers baked in :)
i think the title of the post should be changed to avoid making reference to heroku, as badger-rails can and should stand on its own as a useful tool.
To be clear though, badger doesn't just replicate the deploy experience but also the best practices of setting up a rails server, including scaling an infrastructure to the same if not better levels then heroku can currently scale if you have the server power behind it.
We currently use it on one of our own applications that has multiple application servers and webservers, and use badger-rails to scale whenever we need to.