4 ms·

"Starting a test or server on my dev machine takes 20-30 seconds. Particularly with tests, this is a huge problem for doing proper TDD" Long startup times or n

by carbon8 15y ago

"Starting a test or server on my dev machine takes 20-30 seconds. Particularly with tests, this is a huge problem for doing proper TDD" 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 very large amount of code and dependencies, that sounds like an environment issue. "while most "Rubyists" would rather pollute the namespace" That's unfair, and I say that as someone who is very adamant about clarity, explicitness and simplicity in my apps. In my experience, most (not all, but most) of the libraries where people are doing weird things are libraries that are far from necessary, so avoiding that is trivial. For instance, you cite metawhere. First, I haven't investigated the implementation in depth, but, FYI, it doesn't appear to use method_missing at all. Secondly, I'd be very hesitant to include a library like this in an app, regardless of the implementation, since it's too invasive of a dependency.

joevandyk 15y ago
autotest or watchr doesn't help startup times -- I'm not sure why you mentioned that here. I don't think the performance problems are affecting ALL applications - some people don't see any problems. I do think there is something wrong in Ruby or Rails that doesn't happen in all code paths.
- aneth 15y ago
  Autotest doesn't help startup times, but it can help mitigate the problem somewhat since the tests will start almost instantly when you change a file, saving a few seconds. It's a good suggestion, but doesn't solve the problem.
- carbon8 15y ago
  "autotest or watchr doesn't help startup times -- I'm not sure why you mentioned that here." If you use autotest or watchr you aren't starting up the environment very frequently.
  - joevandyk 15y ago
    I'm not sure why you think that. Unless you use spork or something that preloads the rails environment then forks it on every test run, autotest/watchr will boot the whole rails environment from scratch on each run.
    - carbon8 15y ago
      You're right. I'm distracted by the reported 20-30 second environment load time for each test when it only takes about 7 seconds for my tests to start with autotest in my current pretty large app on an older MBP.
aneth 15y ago
"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).
- carbon8 15y ago
  "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.
  - aneth 15y ago
    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.

by carbon8 15y ago

joevandyk 15y ago

autotest or watchr doesn't help startup times -- I'm not sure why you mentioned that here. I don't think the performance problems are affecting ALL applications - some people don't see any problems. I do think there is something wrong in Ruby or Rails that doesn't happen in all code paths.

aneth 15y ago
Autotest doesn't help startup times, but it can help mitigate the problem somewhat since the tests will start almost instantly when you change a file, saving a few seconds. It's a good suggestion, but doesn't solve the problem.
carbon8 15y ago
"autotest or watchr doesn't help startup times -- I'm not sure why you mentioned that here." If you use autotest or watchr you aren't starting up the environment very frequently.
- joevandyk 15y ago
  I'm not sure why you think that. Unless you use spork or something that preloads the rails environment then forks it on every test run, autotest/watchr will boot the whole rails environment from scratch on each run.
  - carbon8 15y ago
    You're right. I'm distracted by the reported 20-30 second environment load time for each test when it only takes about 7 seconds for my tests to start with autotest in my current pretty large app on an older MBP.

aneth 15y ago

"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).

carbon8 15y ago
"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.
- aneth 15y ago
  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.