Your thoughts on "Enterprise Rails"

rubyonrails-talk
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

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

3

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! (-:

4

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

Martin

5

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.

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

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,