|
RonaldMcDonald posted:Running random eval()s from the Interweb is a good idea c/d? Confirming because it's why the lucky stiff.
|
#
¿
Aug 9, 2007 14:26
|
|
|
|
| # ¿ Apr 25, 2024 17:30 |
|
|
Mr. Wynand posted:Run away! Run as fast you can! It looks great but in practice the tests are a massive pain to write and maintain. The other problem is that it's often buggy, inconsistent across browsers and just plain not an accurate simulation of true user interaction. Have you tried looking at Selenium and Watir to do the type of testing your talking about? I'm personally not a big fan of that type of testing because the breakdowns usually occur on the model or controller level anyway, and like you said, it changes way too often to be of much value. Regarding testing not being worth the investment -- I have to say, I've seen some stupid things said about Rails, but that's the first time I've heard that one. I will admit it takes discipline and experience to do it correctly but it does pay off eventually and sometimes in spades. Mr. Wynand posted:Except a lot of code depends on "development", "test" and "production" explicitly. It shouldn't, but it very often does (plugins are especially bad at this - and face it - sooner or later an if RAILS_ENV=="development" is going to slip in your code somewhere...). So even though you can make your own enviornments in theory, in practice, it's a lot more headache then just swapping out prod/dev/test through some lovely hack for different deployment targets. This is crazy. Mr. Wynand posted:migrations You do know you can use ActiveRecord inside your migrations to do data manipulation/sanizations between migrations?
|
|
#
¿
Aug 10, 2007 21:19
|
|
|
vg8000 posted:Yeah but when you try to re-migrate from scratch, you're using [latest model] versus [older database migration] that may not be compatible anymore. He said this himself in his post. Ah oops. I misread what he was saying.
|
|
#
¿
Aug 10, 2007 21:25
|
|
|
I don't like incremental migrations during development beyond setting up the base tables. Everything evolves too quickly and a db:reset with a sql file to load isn't too painful (or load fixture data into your development database). My team is much smaller so we don't run into big problems with database clashes and just tell eachother when we've made a database change. I start using them the 'right' way when the application is in production. I figure I can live with a little inconvenience during development.
|
|
#
¿
Aug 10, 2007 21:45
|
|
|
@author.books.sum(&:price) (Although I think it's functionally identical to the above example)
|
|
#
¿
Aug 23, 2007 15:33
|
|
|
|
| # ¿ Apr 25, 2024 17:30 |
|
|
Grob posted:One of the great features of Subversion (which I assume you're using because you mentioned capistrano) is the ability to have externals. An external is the ability to point part of your source tree at another source tree altogether. SVN externals can sometimes be a royal pain in the rear end. An excellent alternative is Piston (http://piston.rubyforge.org/). You can even use this to maintain your own specific changes to a plugin while also maintaining updates upstream.
|
|
#
¿
Sep 8, 2007 19:21
|
|