On Dec 28, 11:46 am, Wayne Molina <wayne.mol...@gmail.com> 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 mar...@marnen.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@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
