On Fri, Sep 26, 2008 at 4:16 PM, David Chelimsky <[EMAIL PROTECTED]>wrote:
> DataMapper, for example, offers auto-migrations. You just add a > property to your model file and it takes care of the migration for > you. The relationship between schema and models in Rails is weird. The basic source of truth for a model's attributes is the database. But the database is defined in Ruby. I don't know DataMapper, but it sounds as if it puts the responsibility in one place - the Ruby code. > If you don't need it now, or can't even justify the need for it in the > future, then it doesn't belong in the code OR in the data. So you would not collect fax numbers in this scenario. That's fine, but if you do need them later, you're completely, absolutely, 100% screwed. Kent's white book relied on the assumption that change is possible. But data collection is an area where change is not possible, so I don't think agile principles apply to it (necessarily). You might well ask, "how far do you go in collecting currently useless data?" And that would be a good question. :) I would answer that it would have to be decided by experience in dealing with business requirements, but not completely by whether there is a current need for it. If somebody > thinks "we might need it later" then it should be discussed as a > requirement and either introduced as one or dropped. If "we might need > it later" then probably somebody has a good argument why. Even with a good argument, "we might need it later" is unYAGNIsh. If nobody > can think of a good reason, then why add the extra weight to the db > AND to the examples. Again, because you've only got one chance to get that data. there should be a huge red flag and serious > discussion about why requirements are being imposed on a system for > which nobody can argue business value. > Agreed, absolutely. ///ark
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
