Name: Enterprise Rails
ISBN: 9780596515201

Enterprise Rails

What does it take to develop an enterprise application with Rails? Enterprise Rails introduces several time-tested software engineering principles to prepare you for the challenge of building a high-performance, scalable website with global reach. You'll learn how to design a solid architecture that ties the many parts of an enterprise website together, including the database, your servers and clients, and other services as well. Many Rails developers think that planning for scale is unnecessary. But there's nothing worse than an application that fails because it can't handle sudden success. Throughout this book, you'll work on an example enterprise project to learn first-hand what's involved in architecting serious web applications. With this book, you will: Tour an ideal enterprise systems layout: how Rails fits in, and which elements don't rely on Rails Learn to structure a Rails 2.0 application for complex websites Discover how plugins can support reusable code and improve application clarity Build a solid data model -- a fortress -- that protects your data from corruption Base an ActiveRecord model on a database view, and build support for multiple table inheritance Explore service-oriented architecture and web services with XML-RPC and REST See how caching can be a dependable way to improve performance Building for scale requires more work up front, but you'll have a flexible website that can be extended easily when your needs change.

What Hacker News says

tmalyJun 2022

the Enterprise Rails book has a great section on databases that I think takes things to the next level.

thread

tmalyMay 2022

There is the book Enterprise Rails that has a section on data modeling. Even if you don't use Rails, that section of the book is worth it.

thread

vogan42Jan 2016

I don't disagree that oracle has excellent materialized view support, but triggers and other strategies can go a long way also, I think Dan Chak did a really nice chapter on this in his book enterprise rails, that is also available online for free at http://dan.chak.org/enterprise-rails/chapter-12-materialized...

thread

fubarredJan 2015

Standardization is, generally, good for maintenance, learning curve and security, not always for retention (fun) though. Too much standardization is like the flip-side of too many one-offs: an extreme that can lead to unintended consequences. It's much easier to accrue technical debt and organizational bifurcation by having too many languages, with a big, painful shake out (technical debt repayment) into just a 2-3 (say Ruby|Python|Node & Go|Scala|Haskell|Erlang|C)... (I've seen this happen at a number of shops go through growing pains at scale).

Overall though, services should expose either a well/self-documented RESTful, zmq or similar API such that they can be rewritten in (your favorite whatever here). Being able to discover the API meta information automagically can be helpful for autogenerating clients.

The other aspect is that services have a risk budget: if the service is conventional and not as crucial, increase the experimentation. If the business/process model is risky/uncertain, use common, stable technologies.

(Gist: Pick from the toolbox, carefully... apply common-sense... Don't get stuck on perfect now or perfect waay later... Anticipate a little now to avoid pain of changing later.)

PS: Enterprise Rails is a great read. It's safe to ignore the Rails bits, because the architecture bits are universal and excellent.

Update: RESTful API metadata formats http://apiux.com/2013/04/09/rest-metadata-formats/ (and also https://en.wikipedia.org/wiki/HATEOAS )

thread

chanksJun 2012

I love Rails, but I strongly disagree with its philosophy of the DB as being just a dumb data store. Two things I would recommend.

One, the book Enterprise Rails. It's a few years old, so all the examples are from Rails 2, but the meat of it is about proper database design, including the stuff that Rails doesn't believe in (composite primary keys, foreign key constraints, check constraints, triggers). Chapter 4, about the importance of data integrity, was probably the single most useful thing I've read about web development in the past few years.

Most of it is on Google Books (although sadly, chunks of chapter 4 are missing): http://books.google.com/books?id=thTju-4duY4C&printsec=f...

Second, the best thing I did was replace ActiveRecord with Sequel. Sequel has built-in support for all of those things that ActiveRecord doesn't (I couldn't live without its composite primary key support), and is in general a much more robust library than ActiveRecord. It also supports more exotic SQL features like CTEs and CASE statements without forcing you to drop down to writing raw SQL (though you can certainly do that if you want).

It's not a necessary upgrade for everyone. If your app has fairly simple models and relationships, ActiveRecord will probably be just fine for you. But if you want to get better with SQL and get closer to your DB, I think Sequel is a much better choice.

More info on Sequel: http://sequel.rubyforge.org/

It also integrates very well with Postgres - there's a C extension for the Sequel postgres adapter (https://github.com/jeremyevans/sequel_pg) and support for adding common triggers in migrations, counter columns and whatnot (https://github.com/jeremyevans/sequel_postgresql_triggers). It also supports the more exotic datatypes - hstore, arrays, even the json and range types that are coming in PG 9.2.

thread

faroutApr 2011

here are the three that within in a month you should be able to write some sweet apps quickly.

1. Head First Rails I first poohed this book but I had read 7-8 other books adn still was confused so I thought what the hell. I did each project several times and started making changes. Totally awesome especially the ajax integration parts. This is when I could actually make my own simple apps in less than a week.

2. I loved Agile Programming book - totally awesome. Not enough apps though. Great explanations. Gentle exposure to Ruby.

3. beginning novice to professional for ruby. I love this book. It is just plain fun. Good examples. I totally had fun with this. Peter is totally totally awesome - I wish he would write every tech book!!

Now you have the grounding, start making and asking questions.

What killed me was the UX/UI stuff. Then a friend suggested CSS Mastery book and using blueprint this got me clued in. Now I was not paralyzed. It was so awesome to see an app created in literally minutes.

I loved RoR - I miss it terribly. I disliked the community. Fanboyish. It was like being in all male high school with everyone thumping their chests and no help.

I still miss it very much. Whenever I code I first think in RoR then do it in php. My background was coldfusion, c#asp.net, java, etc. I need something dumb simple and php does the trick. And the people are nice and there are tons and tons of example to do anything. Also I needed something that is simple to deploy and maintain. Yeah yeah -RoR is easy to deploy - my first deployment took me several hours. Whereas php was minutes. In terms of sys admin and performance and optimization, I rather deal with php. As DBA, I do not really want an ORM. BTW when you feel good with RoR - check out Enterprise Rails - wow - good stuff on performance and optimization.

thread