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@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 -~----------~----~----~----~------~----~------~--~---
