Your thoughts on "Enterprise Rails"

Rails
1

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.

2

On 28 Dec 2008, at 16:46, Wayne M. wrote:

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

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

3

Wayne M. 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

4

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.

5

Hello Wayne,

Wayne M. 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
:wink:
Maybe I’ll have to read Dan’s book.

Martin

6

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

7

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.

8

On Dec 28, 11:46 am, Wayne M. [email protected] 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

(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
[email protected]
http://www.marnen.org