On Tuesday 27 December 2005 12:11 am, Gregory B. wrote:
On 12/26/05, basi [email protected] wrote:
Hi,
Ruby for Rails looks like the book that will satisfy my current
craving. Any chance an electronic copy is available for purchase?
Thanks,
basi
Yes.
http://pragmaticprogrammer.com/titles/rails/index.html
I have a big problem with a few sentences in the preceding URL. Or at
least as
I understand them. They seem to be advocating getting rid of config
files and
putting all logic in code, at least my reading of the following quotes:
============================================
“A full Rails application probably has less total code than the XML
you’d need
to configure the same application in other frameworks.”
"Rails strives to honor the Pragmatic Programmer’s DRY Principle by
avoiding
the extra work of configuration files and code annotations. You can
develop
in real-time: make a change, and watch it work immediately.
Forget XML. Everything in Rails, from templates to control flow to
business
logic, is written in Ruby, the language of choice for programmers who
like to
get the job done well (and leave work on time for a change)."
Putting all your logic in code is nothing new. That’s how it was done in
the
60’s. By the 80’s programmers created configuration files so that a
customer
request for increasing the customer number field from 5 to 6 digits
wouldn’t
require recoding – the user could change the config file. It requires a
lot
more coding, but it makes for a much more resiliant application.
Anyone can write a “simple” app if he or she puts all the logic in code,
and
that programmer will be called every time a change is needed in that
code,
even if the change is trivial.
To me, the art of programming is anticipating likely changes and needs,
and
putting facilities for those changes and needs in config files, so that
the
change can be made with a simple tech support call instead of a code
change.
I believe in data centered programming.
Once again, perhaps I misunderstood the intent of the web page, but if
they’re
advocating moving logic from data to code, that’s some advice I will not
follow.
SteveT
Steve L.
[email protected]