"Long startup times or not, sounds like you should probably be using autotest or watchr. 20-30 seconds is not normal. Unless the app has a massive amount of code and dependencies, that sounds like an environment issue."
Autotest helps some, but 20-30 seconds is pretty standard fare. Maybe I use too many gems, but I don't think I should forgo reusing community code to reduce start times.
Maybe it's unfair to make a generalization about "rubyists," but it seems people in the community get overly excited about something that saves 5 characters in their codebase or makes something readable to non-devs (for all those non-devs who will read your code.
Another example - the ubiquity of DelayedJob. The standard usage is to insert delay into your call chain, so foo.delay.send_emails instead of foo.send_emails. This pollutes the ENTIRE object space with the method delay, in addition to the fact that it doesn't work well on many objects. I complained about this practice and the response was that it was clearly better to write foo.delay.send_emails instead of Delayed.add_job(foo, :send_emails) or something. For me, I find any pollution of namespace where conflict is possible highly questionable, although sometimes it's ok.
Metawhere adds methods like .eq and .lt to Symbol (symbol is something like an intern string, e.g. :foo or 'foo in Python).
Polluting the namespace like metawhere does is a significant problem.
We use datamapper on our app, and were looking at doing some of our analytics on mongo at one point, but since both mongomapper and datamapper both define 'helper' methods on Symbols, they can't both be in use at the same time.
If we _really_ wanted to use mongo it would need to be from a completely separate codebase either talking to the db via Sequel or something, or talk to our main app via REST calls - neither being a particularly pleasant solution.
"I don't think I should forgo reusing community code to reduce start times."
Using too many gems is an problem for a lot of reasons, though. You are introducing dependencies that you then need to manage and update, they often do more than you need to while being harder to maintain (you might end up with a bunch of forks in your gemfile as things get outdated), they are sometimes invasive and will require big rewrites to switch from.
"it seems people in the community get overly excited about something that saves 5 characters"
I agree (though I'd modify to to say "some people in the community"), I just find that I don't encounter it much when I'm following best practices myself.
True that gems often do more than I need, but should I?
1) Write my own authentication code
2) Write my own ical feed code (just added this in about 2 hours using ri_cal, which has way more features than I need)
3) Write my own code to inline css in email
4) Write my own Facebook API library
5) Write my own admin interface
6) Write my own SCSS and HAML processors
7) Write my own file attachment and processing code
8) Write my own background processing library
9) Write my own CSS/JS compression library
You get the point.
I use gems that save me tons of time. If not for gems, I would not be using Rails.
That's only 9 libraries, and that shouldn't be enough to cause your load times to reach 20-30 seconds.
Also, since you asked :-) I would question #5. Auto admin libraries (and this applies to multiple languages and frameworks) are generally heavy, too general and have code hidden away in the library. In contrast, banging out crud views and controllers in a locked-down namespace is easy, only relies on same dependencies as the rest of the app, can be customized for the specific business needs and all the code is in one obvious place.
It would take me many days to create and test an admin with multiple objects, even a simple one, and then I have to maintain it. I install rails_admin and I've got what I need. This is for internal testing and maintenance. I don't care if it's heavy.
I suppose your logic makes sense if you're gainfully employed, but I bang this stuff out for myself and clients. A 90% solution with one line of code sure beats weeks of work.
Autotest helps some, but 20-30 seconds is pretty standard fare. Maybe I use too many gems, but I don't think I should forgo reusing community code to reduce start times.
Maybe it's unfair to make a generalization about "rubyists," but it seems people in the community get overly excited about something that saves 5 characters in their codebase or makes something readable to non-devs (for all those non-devs who will read your code.
Another example - the ubiquity of DelayedJob. The standard usage is to insert delay into your call chain, so foo.delay.send_emails instead of foo.send_emails. This pollutes the ENTIRE object space with the method delay, in addition to the fact that it doesn't work well on many objects. I complained about this practice and the response was that it was clearly better to write foo.delay.send_emails instead of Delayed.add_job(foo, :send_emails) or something. For me, I find any pollution of namespace where conflict is possible highly questionable, although sometimes it's ok.
Metawhere adds methods like .eq and .lt to Symbol (symbol is something like an intern string, e.g. :foo or 'foo in Python).