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 <[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. 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
