Customer Reviews

Enterprise Rails

5 star:		(14)
4 star:		(6)
3 star:		(0)
2 star:		(0)
1 star:		(0)

 

 

Dan Chak has written a really excellent introduction to enterprise web application architecture, and a worthy candidate for your technical bookshelf.

Calling it "Enterprise Rails" is a bit misleading, though. Rails only makes fleeting appearances. There's a great introduction to Rails plugin writing, which rightfully urges developers to move any decorator code to plugin modules. He talks a little about segmenting class files along Physical, Logical and Service boundaries, the point of which I have yet to understand completely. And there's a chapter on pushing Rails' application-layer polymorphism down to the data layer, which is good advice, but more on that later.

The bulk of Enterprise Rails is devoted to building a solid data layer. Again, good advice. The Rails team decided that referential integrity and validation belongs in the application layer, which Chak contends is dangerous (and I believe him). However, this is where things start to get a little hairy - enforcing referential integrity and validation in the data layer requires an early and continued adherence to SQL, and Chak makes it clear that any old SQL won't do: it's PostgreSQL or nothing.

This makes fully half of the book a dissertation on SQL domain description language from the Postgre perspective, domain data, third normal form and other data layer topics. I have greatly enjoyed the introduction to Postgres DDL, but it wasn't exactly what I expected from a Rails book.

The last few chapters are mostly about Service Oriented Architecture (which I suspect is why most people buy this book) and caching. Chak shows why he's an expert in enterprise software architecture here. But again, he takes a decidedly anti-Rails approach, emphasizing ActionWebService and XML-RPC. This is not without reason - nearly every language has an XML-RPC library. But ActionWebService, as Chak notes, isn't part of core Rails any longer.

REST is quickly reviewed, then mostly dismissed. There's a cursory example of a RESTful service. ActiveResource, Rails' useful core module for REST-oriented SOA, is never mentioned.

Pretty much every time Rails comes up in Enterprise Rails (which, as we've seen, isn't often), it's an opportunity for Chak to take it down a peg. Well, Rails deserves it. But I think that slapping the word "Rails" on the book cover is has more to do with marketing than anything else. This is really a tale about data modeling for the enterprise, with an emphasis on Postgre, told by an expert.

I'd say that this is required reading for enterprise developers, but don't take the "Rails" part of the title too seriously.

Dan Chak is obviously one smart guy, and I agree with the other reviewers in that this book provides a lot of information not found in any other Rails books.

I have neither the advantage nor experience of working on a large, complex site like Amazon (where Dan worked), so for all I know maybe all of his ideas border on necessity for a site of that complexity. But there does seem to be a lot of straying from the normal philosophies espoused in virtually every other Rails book.

For example, he eschews migrations and instead does all schema manipulation via SQL DDL statements. And choosing PostgreSQL over MySQL means that on more than one occasion MySQL users are left trying to figure out how to accomplish what he has just covered.

None of which is bad; heck, Rails is Latin for "opinionated", right? But if you're in a fairly small shop working on non-Amazon-size websites (which most of them are), I question how many of these fairly complex strategies will be implemented given the perpetual "behind schedule" state we all seem to be in most of the time, not to mention the pressures of "getting something out the door" as soon as possible.

Regarding this issue, I think he himself put it best during his discussion of REST vs. XML-RPC vs. SOAP: "... we must remind ourselves that in the enterprise practicality is at least as important as purity." (Ada, anyone?)

While we all know that "pay me now or pay me later" and "an ounce of prevention is worth a pound of cure" are absolute truths, the real world often dictates we ditch these proverbs.

Regardless, I think this book is a must-read for serious Rails developers. Dan raises a heckuva lot of good points that you won't find anywhere else.

The author provides an important perspective that can easily be forgotten in the rails community. You may not put into practice everything you find in the book but it is an invaluable, intelligent description of design strategies that need to be re-aquired in the rails community if it wants to survive beyond "this is a really cool language!" ;)

With the possible exception of Obie's, every Rails book I've ever seen reads like it was written to impress marginally literate teenagers more so than provide any semblance of real education, thereby catapulting their authors toward some perverse notion of IRC fame. Nobody dares point out any of the framework's flaws for fear of angering the infallible DHH and being ostracized from the internet clique his ego has built up over the years, so instead of practical information we have a giant sludgy pool of homogenized evangelism to wade through as we figure the ugly bits out for ourselves.

This title is different in that it openly rails on Rails' shortcomings, and suggests some tried-and-true tactics for working around them in real applications that do something besides update videogame scores and try to recreate YouTube. There aren't any lame attempts at being clever or terrible drawings by "Why," either, which is always a plus.

Unfortunately, it seems like it was rushed out the door as I found dozens of pretty bad typos in my first reading. It also predates Rack, Metal and Engines, but still, it's the first Rails book I've come across that hasn't annoyed the tar out of me with simpering sycophantry and I'd highly recommend it to anyone who has real work to do.

I just finished Enterprise Rails and want to tell you what a capital, outstanding, helpful book it is. I was sad when I finished it!

I've been building a startup site of moderate size, not even something you'd call enterprise yet, for the last 3 years. When I started I was just the sort of naive and overconfident Rails guy this book is aimed at. The author has been through all the scaling issues involved with running a popular website and the book is chock full of useful advice and examples. I wish I had read it way back when I started as I have made many of the mistakes he warns about and had to learn the hard way. Dan shows you how to avoid painting yourself in a corner with overly optimistic/naive design choices up front. He shows you how to design things properly from the start, with a special emphasis on using the native features of a relational database instead of doing things at the application level, and how to keep things organized. I love love LOVED this book.

It addressed the real world problems of Rails. It's emphasized the organization and code sharing when you put the Plugin chapter at the very beginning of the book. I got very frustrated on most of the Rails book since they seem to threat database as annoyance and just focus on quick demo app w/o thought of real world apps. If you finish the book Agile Web Development with Rails book, this is the 2nd one to read. It will saves you a lot of trail and error when you go through the large scale application.

You are going to see a lot of advance database stuff here (Postgres) and it will convince you why you should take advantage of those features.

I wish the book has more chapters for "View", authentication and authorization.

Also, having examples with MySQL5 trigger and store proedure would not hurt either.

Dan Chak offers incredible wisdom and experience in this book. I have been trying to get to the next step in Rails development for a long time, and now with his book, I have the know-how to do so. This book is a must own for anyone who wants to use Rails to develop serious applications.

My edition was written in 2008, and lots of things in Rails have moved on since then. However, this book is still a great read for the many other aspects that are rarely addressed in rails tutorials. Dan has a good writing style and clear experience in a real business.

I smiled, learned and even laughed as I read his comments on the data layer and the need to use protection wherever possible. His way of testing data exceptions and validations seemed neater than anything else I have ever seen. Of course, many people may think that it is overkill, but you could say the same about seat belts and crash helmets too. The problem is never the driver, it is the other drivers :-)

It is still worth buying, but also worth updating.

Hi, I enjoyed this book. Didn't understand when the sledding got rough, but it certainly helped me understand what the noise about n-tier is all about. I'm going to study Rails more closely, and then come back for a second read. It was refreshing to see someone treat the state of the art as a transitory thing and not as the last word in software technology.

Regardless that the technology is Rails and Postgres -centric, the text is solid about proper enterprise architecture. Specifically, presenting services as layers of small, loosely coupled plugins. For example, this is very similar to how NetFlix said it had refactored.