Rails - Dec 2008 - Your thoughts on "Enterprise Rails"

Hello and happy holidays, everyone!

I received the book "Enterprise Rails" by Dan Chak as a Christmas gift
and started reading it; I wanted to gauge the community''s thoughts on  
this.  Basically, Mr. Chak advocates a totally different approach to  
how every other Rails book/tutorial explains how to develop Rails  
applications.

Firstly, he advocates you organize your application deeper than the  
default Rails skeleton; for example he says to put all of your models  
under a "physical" directory (e.g. app/models/physical) and to  
separate them by module (e.g. Physical::Projects::Project).

He also evangelizes Postgresql instead of MySQL, and suggests not  
using migrations at all but using raw SQL to  create the tables,  
because he recommends that you NOT treat the database like a dumb data  
store (something the rest of the Rails community seems to do and be  
okay with) and make good use of check constraints, triggers,  
referential integrity and the like at both the database level AND the  
application level.  He is against migrations because of the extremely  
limited subset of SQL they allow for (i.e. no real constraints).

Now, I come from a C# background so this stuff makes sense to me, but  
at the same time I want to follow the best practices from the Rails  
world where I''m looking to redefine myself.  I agree with a lot of  
what Mr. Chak says about organization, since the one major fault I  
find with Rails is that it doesn''t lend itself to organizing your  
application like other frameworks (e.g. Django); for example if my  
application contains 2 major parts (say a Blog application and a  
Network application), Rails just smushes them both together under the  
app directory, and their models/views/controllers are all kept  
together instead of being separated (e.g. app/models/blog/, app/models/ 
social).  The problem with using the approach from Enterprise Rails is  
that it pretty much means I cannot use the generators, unless I were  
to redefine them to follow the "enterprise" structure.  While
that''s
not a big deal, I can''t help but think that I would be going
"against
the grain" as far as my application is concerned - call me a bandwagon  
jumper, but I always prefer to follow the community when it comes to  
programming, instead of going off on my own.

 From reading the book, though, I can''t seem to understand why the  
Rails community has never done this from the start.  Rails  
applications are meant to be scalable, no?  And the big ones have got  
to scale if they get successful, right?  The Rails app that Dan Chak  
worked on, according to what he says in the book, ballooned to some  
188 classes; if other large Rails apps are like that, how do they  
manage?

Basically - I''m wondering if I should be following the advice in the  
book from the get-go when I design my application, or if I should  
follow the best practices of the Rails community and not worry about  
the "enterprise" stuff until I need to (at which point it may or may  
not be too late).  Also remember that I am fairly new to Rails but I  
still want to do things the "right" way.

Any insight from experienced Rails developers would be appreciated -  
when I started reading the book I couldn''t believe that these things  
are NOT done in the Rails world, because they seem like common sense  
to me that any professional developer would do, and yet almost all of  
the Rails people I''ve read about and talked to consider them to be  
inconsequential.  Maybe my vision is just skewed, coming from the  
Microsoft world.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On 28 Dec 2008, at 16:46, Wayne Molina wrote:
>
> Hello and happy holidays, everyone!
>
> I received the book "Enterprise Rails" by Dan Chak as a Christmas
gift
> and started reading it; I wanted to gauge the community''s thoughts
on
> this.  Basically, Mr. Chak advocates a totally different approach to
> how every other Rails book/tutorial explains how to develop Rails
> applications.
>
> Firstly, he advocates you organize your application deeper than the
> default Rails skeleton; for example he says to put all of your models
> under a "physical" directory (e.g. app/models/physical) and to
> separate them by module (e.g. Physical::Projects::Project).
>
That seems rather overkill to me.
> He also evangelizes Postgresql instead of MySQL, and suggests not
> using migrations at all but using raw SQL to  create the tables,
> because he recommends that you NOT treat the database like a dumb data
> store (something the rest of the Rails community seems to do and be
> okay with) and make good use of check constraints, triggers,
> referential integrity and the like at both the database level AND the
> application level.  He is against migrations because of the extremely
> limited subset of SQL they allow for (i.e. no real constraints).
>
It''s not an either or situation, since you can very easily do

class FooMigration
   def self.up
     create_table do
       ..
     end
     execute "add a foreign key"
   end
end

I do that all the time
> Now, I come from a C# background so this stuff makes sense to me, but
> at the same time I want to follow the best practices from the Rails
> world where I''m looking to redefine myself.  I agree with a lot of
> what Mr. Chak says about organization, since the one major fault I
> find with Rails is that it doesn''t lend itself to organizing your
> application like other frameworks (e.g. Django); for example if my
> application contains 2 major parts (say a Blog application and a
> Network application), Rails just smushes them both together under the
> app directory, and their models/views/controllers are all kept
> together instead of being separated (e.g. app/models/blog/, app/ 
> models/
> social).  The problem with using the approach from Enterprise Rails is
> that it pretty much means I cannot use the generators, unless I were
> to redefine them to follow the "enterprise" structure.  While
that''s
> not a big deal, I can''t help but think that I would be going
"against
> the grain" as far as my application is concerned - call me a bandwagon
> jumper, but I always prefer to follow the community when it comes to
> programming, instead of going off on my own.
Rails 3 will have better support for slices of functionality like  
that. Personally I''d rather write two separate single-minded  
applications than one huge honking one.
>
>
> From reading the book, though, I can''t seem to understand why the
> Rails community has never done this from the start.  Rails
> applications are meant to be scalable, no?  And the big ones have got
> to scale if they get successful, right?  The Rails app that Dan Chak
> worked on, according to what he says in the book, ballooned to some
> 188 classes; if other large Rails apps are like that, how do they
> manage?
I think you''re mixing different concepts there - Scaling to handle  
large volumes seems unrelated to how many models you have (The biggest  
app I work on has way more that 188 classes and I can''t say I feel the
need for namespaceing them).

Fred
>
>
> Basically - I''m wondering if I should be following the advice in
the
> book from the get-go when I design my application, or if I should
> follow the best practices of the Rails community and not worry about
> the "enterprise" stuff until I need to (at which point it may or
may
> not be too late).  Also remember that I am fairly new to Rails but I
> still want to do things the "right" way.
>
> Any insight from experienced Rails developers would be appreciated -
> when I started reading the book I couldn''t believe that these
things
> are NOT done in the Rails world, because they seem like common sense
> to me that any professional developer would do, and yet almost all of
> the Rails people I''ve read about and talked to consider them to be
> inconsequential.  Maybe my vision is just skewed, coming from the
> Microsoft world.
>
> >

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Wayne Molina wrote:
> Firstly, he advocates you organize your application deeper than the  
> default Rails skeleton; for example he says to put all of your models  
> under a "physical" directory (e.g. app/models/physical) and to  
> separate them by module (e.g. Physical::Projects::Project).
Why?
> He also evangelizes Postgresql instead of MySQL, and suggests not  
> using migrations at all but using raw SQL to  create the tables,
The fundamental tension here is between Agile (Lean, DRY, 
You-Ain''t-Gonna-Need-It) on one side, and Enterprise (pre-designed, 
inter-operable, layered, & accountable) on the other side.

You may have noticed that Rails tends veeerry slightly to the Agile side. (-:

Specifically, the /modus operandi/ for a Rails practitioner is to belt out a 
website in 2 hours, then maintain it as long as it runs. That''s why we 
specialize in flat object models, migrations to tweak live databases, and 
(>cough<) wall-to-wall unit tests.
> The problem with using the approach from Enterprise Rails is  
> that it pretty much means I cannot use the generators, unless I were  
> to redefine them to follow the "enterprise" structure.
Use them to generate new, then Refactor (under test!) the resulting code to 
match those patterns. /If/ you need those patterns - keep reading.
>  From reading the book, though, I can''t seem to understand why the
> Rails community has never done this from the start.  Rails  
> applications are meant to be scalable, no?
Yes. And scalability does not (/not/ NOT!) mean predefined schemas and designs. 
It means you start as lean and efficient as possible, where programmer 
efficiency usually translates into code efficiency.

Then you upgrade your site the way a live customer tells you to, responding to 
feature requests in real-time. If they ask you to make it faster, you make it 
faster, using all the evidence from your running site to make sure you 
concentrate only on the bottlenecks. Google for "premature optimization is
the
root of all evil".

BTW my current gig runs Rails on >20 high-bandwidth servers. The scaling
comes
in caching pages and caching database hits. Those are _very_ easy to add to a 
simple Rails app. _That_ is scalability. The internal code remains very easy to 
work with.
>  And the big ones have got  
> to scale if they get successful, right?  The Rails app that Dan Chak  
> worked on, according to what he says in the book, ballooned to some  
> 188 classes; if other large Rails apps are like that, how do they  
> manage?
188 classes is a problem, not a scalability. I''m sure cutting them up
into a
tree of application classes made sense, but...

How many unit tests did Dan''s app have? If none, I would dismiss most
of the
rationales in his book. I personally would treat 188 classes as a grandiose 
opportunity for Refactoring, to fold them all back together into the fewest 
possible classes.
> Basically - I''m wondering if I should be following the advice in
the
> book from the get-go when I design my application, or if I should  
> follow the best practices of the Rails community and not worry about  
> the "enterprise" stuff until I need to (at which point it may or
may
> not be too late).  Also remember that I am fairly new to Rails but I  
> still want to do things the "right" way.
You are now asking how to grow a project, and you are afraid that its early 
design gets set in stone. Look up "Test Driven Development", and write
unit
tests for everything you do. Write your code as simple, and as close to the 
Rails community standards as possible.

If and only if you then detect a need for one of the techniques in the book 
(such as a customer with a /pre-existing/ Postgresql database that /cannot/ be 
migrated), only /then/ do you apply one of the book''s techniques. You
add the
technique under test, and all your pre-existing unit tests will help pin down 
your application and prevent it from changing behaviors if you make any
mistakes.
> Any insight from experienced Rails developers would be appreciated -  
> when I started reading the book I couldn''t believe that these
things
> are NOT done in the Rails world, because they seem like common sense  
> to me that any professional developer would do, and yet almost all of  
> the Rails people I''ve read about and talked to consider them to be
> inconsequential.  Maybe my vision is just skewed, coming from the  
> Microsoft world.
My app is bigger than Dan''s app! (-:

-- 
   Phlip


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Hello Wayne,

Wayne Molina schrieb:
> for example if my
> application contains 2 major parts (say a Blog application and a  
> Network application), Rails just smushes them both together under the  
> app directory, and their models/views/controllers are all kept  
> together instead of being separated (e.g. app/models/blog/, app/models/ 
> social).  
that''s the same question I asked a few days ago 
(http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/8734eb42b922efec/)
Unfortunately I haven''t got an answer. But reading the answers here in 
this thread let me think that splitting the apps isn''t the "rails
way".
But I''m still uncertain whether the rails way makes sense to me or not
;-)
Maybe I''ll have to read  Dan''s book.

Martin

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Basically from reading the book, Dan doesn''t believe in the "Rails
Way" because he hints that it lends itself to quick and dirty code;
not dirty in the sense of old PHP/ASP code, but dirty in that it
doesn''t care about scalability from the start but as an afterthought.
Although his book does seem more geared towards using Rails in an
enterprise environment, as opposed to the usual new startup.  He does
mention that, as a developer of an original "big Rails site"
he''s
speaking from hindsight in his own projects and that he would
architect them properly to scale from the start.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

> Firstly, he advocates you organize your application deeper than the  
> default Rails skeleton; for example he says to put all of your models  
> under a "physical" directory (e.g. app/models/physical) and to  
> separate them by module (e.g. Physical::Projects::Project).
I would agree that organizing deeper can be useful.  But if so, the
groups should be meaningful to your application, not arbitrary (which
from your account "physical" seems to be).

Smaller Rails applications don''t do it, not because of any bias
against it, but because they don''t have 188 models to organize.  10 to
30 models is not hard to manage.

And while generally it makes sense to keep everything in one
application, keep in mind that it is possible to have more than one
application and still share a table, a model or pass data between
them.  Depending on the schema and requirements, a 188 model
application might be happier as three 60 model applications that share
a User model/table.  To give a non-Rails example: Google needs to keep
track of my login, but that doesn''t mean Google Maps and Gmail have to
be one application.
> He also evangelizes Postgresql instead of MySQL
I would say that''s his personal preference and not gospel.  MySQL,
Oracle, SQLite and other flavors have their fans too.  Do your own
research as to which one is right for you.
> He is against migrations because of the extremely  
> limited subset of SQL they allow for (i.e. no real constraints).
Whatever your opinion about database constraints vs. application
constraints, he obviously does not realize that migrations allow you
to execute any SQL.
> The problem with using the approach from Enterprise Rails is  
> that it pretty much means I cannot use the generators, unless I were  
> to redefine them to follow the "enterprise" structure.
Generators are there to help 90% of the time.  The other 10% you''ll
have to do by hand, modify what they give you or roll your own.  Once
you get the hang of it, you''ll see that it will only take a minute or
two longer to do it without generators.  Don''t let this be a major
concern.
> Basically - I''m wondering if I should be following the advice in
the  
> book from the get-go when I design my application, or if I should  
> follow the best practices of the Rails community and not worry about  
> the "enterprise" stuff until I need to (at which point it may or
may  
> not be too late).  Also remember that I am fairly new to Rails but I  
> still want to do things the "right" way.
I think a good rule of thumb in programming is not to build it until
you need it.  Otherwise you will spend a considerable amount of time
maintaining code and keeping options open for the future that you may
never use.  It is not hard to implement the "enterprise
recommendations" you mentioned (grouping controllers and models,
upgrading databases, etc.) when you find you need them.  Don''t burden
yourself with them until you do.

Ideally a framework will allow you to build your application fast, not
burden you with features you may never use, but still keep your
options for feature modifications and application scalability open for
the future.  I think Rails does that well.

Kevin
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

While I don''t agree with much of what the book seems to be saying ...
I''m an opinionated b@$tard ... there are always things you can learn
even from books that don''t seem to be the best. I have some really
crappy programming/technology books at home, but I could still learn a
lot from them because the background allowed me to sift out the stuff.

On Dec 28, 10:46 am, Wayne Molina
<wayne.mol...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Hello and happy holidays, everyone!
>
> I received the book "Enterprise Rails" by Dan Chak as a Christmas
gift  
> and started reading it; I wanted to gauge the community''s thoughts
on  
> this.  Basically, Mr. Chak advocates a totally different approach to  
> how every other Rails book/tutorial explains how to develop Rails  
> applications.
>
> Firstly, he advocates you organize your application deeper than the  
> default Rails skeleton; for example he says to put all of your models  
> under a "physical" directory (e.g. app/models/physical) and to  
> separate them by module (e.g. Physical::Projects::Project).
>
> He also evangelizes Postgresql instead of MySQL, and suggests not  
> using migrations at all but using raw SQL to  create the tables,  
> because he recommends that you NOT treat the database like a dumb data  
> store (something the rest of the Rails community seems to do and be  
> okay with) and make good use of check constraints, triggers,  
> referential integrity and the like at both the database level AND the  
> application level.  He is against migrations because of the extremely  
> limited subset of SQL they allow for (i.e. no real constraints).
>
> Now, I come from a C# background so this stuff makes sense to me, but  
> at the same time I want to follow the best practices from the Rails  
> world where I''m looking to redefine myself.  I agree with a lot of
 
> what Mr. Chak says about organization, since the one major fault I  
> find with Rails is that it doesn''t lend itself to organizing your
 
> application like other frameworks (e.g. Django); for example if my  
> application contains 2 major parts (say a Blog application and a  
> Network application), Rails just smushes them both together under the  
> app directory, and their models/views/controllers are all kept  
> together instead of being separated (e.g. app/models/blog/, app/models/
> social).  The problem with using the approach from Enterprise Rails is  
> that it pretty much means I cannot use the generators, unless I were  
> to redefine them to follow the "enterprise" structure.  While
that''s  
> not a big deal, I can''t help but think that I would be going
"against  
> the grain" as far as my application is concerned - call me a bandwagon
 
> jumper, but I always prefer to follow the community when it comes to  
> programming, instead of going off on my own.
>
>  From reading the book, though, I can''t seem to understand why the
 
> Rails community has never done this from the start.  Rails  
> applications are meant to be scalable, no?  And the big ones have got  
> to scale if they get successful, right?  The Rails app that Dan Chak  
> worked on, according to what he says in the book, ballooned to some  
> 188 classes; if other large Rails apps are like that, how do they  
> manage?
>
> Basically - I''m wondering if I should be following the advice in
the  
> book from the get-go when I design my application, or if I should  
> follow the best practices of the Rails community and not worry about  
> the "enterprise" stuff until I need to (at which point it may or
may  
> not be too late).  Also remember that I am fairly new to Rails but I  
> still want to do things the "right" way.
>
> Any insight from experienced Rails developers would be appreciated -  
> when I started reading the book I couldn''t believe that these
things  
> are NOT done in the Rails world, because they seem like common sense  
> to me that any professional developer would do, and yet almost all of  
> the Rails people I''ve read about and talked to consider them to be
 
> inconsequential.  Maybe my vision is just skewed, coming from the  
> Microsoft world.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Dec 28, 11:46 am, Wayne Molina
<wayne.mol...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Hello and happy holidays, everyone!
>
> I received the book "Enterprise Rails" by Dan Chak as a Christmas
gift  
> and started reading it; I wanted to gauge the community''s thoughts
on  
> this.  
I was just looking at the book (© 2009!) in the local Barnes & Noble.
That means that I haven''t really had a chance to read it in depth, but
it looked very interesting.  I apparently did not get to any of the
sections that you did, because what you describe below is news to me.
One of the things I *did* notice, however, is that this book gives one
of the few good explanations I''ve seen of how to write Rails plugins,
and why you''d want to.
> Basically, Mr. Chak advocates a totally different approach to  
> how every other Rails book/tutorial explains how to develop Rails  
> applications.
>
> Firstly, he advocates you organize your application deeper than the  
> default Rails skeleton; for example he says to put all of your models  
> under a "physical" directory (e.g. app/models/physical) and to  
> separate them by module (e.g. Physical::Projects::Project).
I suppose there could be some benefit in this on very large projects,
but I tend to think it''s overkill if you don''t have lots of
models.
>
> He also evangelizes Postgresql instead of MySQL,
Good for him!  PostgreSQL is certainly the best choice for *any*
project, not just big ones.  (I gave up on mySQL about 2 years ago,
and I''ve been a lot happier since.)  For some reason, it
doesn''t get
enough love in the open-source Web development community.  Basically,
anything mySQL can do, PostgreSQL can do better, and it''s really the
only open-source choice if you''re doing anything spatial or using non-
trivial stored procedures.  (I''ve heard that PostgreSQL clusters less
well than mySQL, but I''ve never worked with clustered DB servers in
either case.)
> and suggests not  
> using migrations at all but using raw SQL to  create the tables,  
> because he recommends that you NOT treat the database like a dumb data  
> store (something the rest of the Rails community seems to do and be  
> okay with) and make good use of check constraints, triggers,  
> referential integrity and the like at both the database level AND the  
> application level.  He is against migrations because of the extremely  
> limited subset of SQL they allow for (i.e. no real constraints).
Hmm.  If this is what Chak really wrote, I wonder if he actually
understands migrations.  As Kevin and others have said, if that''s an
accurate description of what he wrote, he apparently doesn''t realize
that migrations allow the use of raw SQL, and he would also appear to
be unaware of the excellent plugins from RedHill Consulting (
http://www.redhillonrails.org/ ), which address these very issues by
adding constraints, transactions, and referential integrity to Rails
migration syntax.

[...]
> The problem with using the approach from Enterprise Rails is  
> that it pretty much means I cannot use the generators, unless I were  
> to redefine them to follow the "enterprise" structure.  While
that''s  
> not a big deal, I can''t help but think that I would be going
"against  
> the grain" as far as my application is concerned - call me a bandwagon
 
> jumper, but I always prefer to follow the community when it comes to  
> programming, instead of going off on my own.
Sure.  Without having read the book, I don''t know what I think of
Chak''s organizational suggestions, but it wouldn''t be too hard
to
write new generator scripts for them if they''re worth adopting.
>
>  From reading the book, though, I can''t seem to understand why the
 
> Rails community has never done this from the start.  Rails  
> applications are meant to be scalable, no?  And the big ones have got  
> to scale if they get successful, right?  
You would think.  But scalability and YAGNI are often perceived to be
in conflict in early stages of development.
> The Rails app that Dan Chak  
> worked on, according to what he says in the book, ballooned to some  
> 188 classes; if other large Rails apps are like that, how do they  
> manage?
I would think that 188 classes in a Rails app would be a design smell,
not something to brag about.  Surely in most cases, an app with that
many classes should be segmented into several related apps, perhaps
following some of the ideas at
http://revolutiononrails.blogspot.com/2007/01/plugems-rails-as-first-class-citizens.html
(note: I haven''t tried these ideas, but they seem reasonable).
>
> Basically - I''m wondering if I should be following the advice in
the  
> book from the get-go when I design my application, or if I should  
> follow the best practices of the Rails community and not worry about  
> the "enterprise" stuff until I need to (at which point it may or
may  
> not be too late).  
I would vote for the latter approach.  If you have good test coverage,
refactoring for scalability when necessary shouldn''t be a big deal.
> Also remember that I am fairly new to Rails but I  
> still want to do things the "right" way.
I would say the same thing about myself.
>
> Any insight from experienced Rails developers would be appreciated -  
> when I started reading the book I couldn''t believe that these
things  
> are NOT done in the Rails world, because they seem like common sense  
> to me that any professional developer would do,
It sounds like some of Chak''s ideas are indeed common sense, and some
may be off the wall, or at least not suitable for smaller projects.
> and yet almost all of  
> the Rails people I''ve read about and talked to consider them to be
 
> inconsequential.  Maybe my vision is just skewed, coming from the  
> Microsoft world.
I don''t think that *competent* Rails programmers consider the issues
of scalability and good architecture to be inconsequential, but Rails
does make it easy to refactor as needed, so you may not need to
*start* with as much Big Design.  YMMV.

Best,
--
Marnen Laibow-Koser
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
http://www.marnen.org
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---