Is Rails DRY?

I note that every time a new rails app is made, there is a huge bunch of
directories and files generated. As this is the same thing every time,
is it really DRY? It just seems that there would be a way to have a
standard set of directories and the classes could be extended when
required.

Am I just being naive?

Lloyd L. wrote:

I note that every time a new rails app is made, there is a huge bunch of
directories and files generated. As this is the same thing every time,
is it really DRY? It just seems that there would be a way to have a
standard set of directories and the classes could be extended when
required.

DRY refers to code that you - the end-developer - must maintain.

For example, if you generate two projects, most of the boilerplate code
is
indeed duplicated, but you don’t need to maintain it.

You will indeed need to deploy it! That’s where it goes to work.

But if, for example, your two projects share a common Member model - you
should
use some extra-Rails facility to merge them together, such as a library
folder
at RAILS_ROOT + ‘/…/lib’.

(Remember to pass all tests in both projects each time you integrate!)

So DRY at the level of Rails source is really “meta-DRY”. Its excesses
allow
your own code to remain DRY.


Phlip

There are not that many files. Most of them are for configuration
and a few defaults like application_helper.rb or application.rb
They’re necessary anyway.
Then there are lots of directories. Most of them empty to start with,
but nearly all of them necessary, too.

Sorry, but I can’t see your point. Maybe give us some example,
which directories or files you think are unneeded?

Phlip wrote:

But if, for example, your two projects share a common Member model - you
should
use some extra-Rails facility to merge them together, such as a library
folder
at RAILS_ROOT + ‘/…/lib’.

(Remember to pass all tests in both projects each time you integrate!)

So DRY at the level of Rails source is really “meta-DRY”. Its excesses
allow
your own code to remain DRY.

Thanks, Phlip! I will look into how to join common members.

Lloyd L. wrote:

But if, for example, your two projects share a common Member model - you
should
use some extra-Rails facility to merge them together, such as a library
folder
at RAILS_ROOT + ‘/…/lib’.

Thanks, Phlip! I will look into how to join common members.

Ask a new question here on how to. I’m sure my first few attempts would
be
“wrong”. Not irreversibly wrong, but sub-level compared to the state of
the art
here.