Slashdot Mirror
Practical Rails Projects
Sean Cribbs writes "There are many beginning and advanced Ruby on Rails books available, from the authoritative Agile Web Development with Rails to the cookbook-style Rails Recipes. However, healthy guidance for intermediate-level developers is lacking at best. Ironically, this is the most crucial stage in the process of becoming proficient with Rails because one must begin to learn why, not just how. Eldon Alameda's Practical Rails Projects effectively fills that gap. I know Alameda from our local Ruby User Group and spoke with him frequently while he wrote this book. His expertise with Rails definitely shines through in the hefty 621-page volume." Keep reading for the rest of Sean's review.
Practical Rails Projects
author
Eldon Alameda
pages
621
publisher
Apress
rating
8/10
reviewer
Sean Cribbs
ISBN
978-1-59059-781-1
summary
A strong book for the intermediate Rails developer
Practical Rails Projects has a unique and effective approach. Instead of spoon-feeding contrived code snippets, Alameda teaches by example, leading the reader step-by-step through the design, creation, enhancement, and analysis of several full-fledged projects. Each project introduces new techniques to the intermediate Rails developer carefully and with plenty of explanation — from caching to generating graphs to RESTful application design and much more. Rather than regurgitating documentation that is occasionally unclear or misleading, each application begins with a clean Rails project and is built up step-by-step with detailed commentary on how and why each step is taken. Alameda's format reflects the reality that real-life projects never have a straight development path; at each step one must make tough decisions, watch for pitfalls and take risks. There are no leaps-of-faith or "just trust me" moments, everything is explained. In the final chapter of each project, Alameda also suggests ways that the project could be improved and how to apply the newly learned techniques to previous projects in the book.
The text is clear and uncomplicated with an approachable style. Projects even makes Rails' least fun framework, ActionWebService (which helps you create SOAP and XML-RPC services), easy to understand. While there are some glaring proofing mistakes, such as "Ruby" uncapitalized and some malformed URLs to external resources, the code snippets are practically error-free and all source and binary resources are available via the Apress website.
One controversial decision made by Alameda was to use the ExtJS Javascript library extensively in one project to build an administration interface for a legacy site. ExtJS is a powerful high-level library that simplifies the creation of desktop-like interfaces in the web browser. Instead of spending a lot of time hand-crafting HTML/ERb templates and CSS, Alameda quickly creates an interface in ExtJS and uses Rails to generate XML and JSON that drives the almost entirely client-side application. While some may find this outside the spectrum of what should be in a Rails book, many developers are now creating their interfaces in Flex, SilverLight, and other client-side technologies. With the recent official release of ActiveResource, I believe we will see more web-service-focused Rails applications as time goes on. Alameda's choice is also practical; with a small number of users having access to the interface, he can place greater requirements on them in order to deliver the application more quickly.
Overall, I believe Practical Rails Projects is a strong book for the intermediate Rails developer. It provides an introduction to more advanced concepts of the framework without being preachy or obtuse. It lacks any discussion of test- or behavior-driven development with Rails, but the breadth and depth of the topics it covers makes up for this weakness. Like any book that covers a rapidly-changing open-source project like Ruby on Rails, Projects will date quickly, but in the near-term it should be of great help to developers looking to gain constructive experience.
You can purchase Practical Rails Projects from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
The text is clear and uncomplicated with an approachable style. Projects even makes Rails' least fun framework, ActionWebService (which helps you create SOAP and XML-RPC services), easy to understand. While there are some glaring proofing mistakes, such as "Ruby" uncapitalized and some malformed URLs to external resources, the code snippets are practically error-free and all source and binary resources are available via the Apress website.
One controversial decision made by Alameda was to use the ExtJS Javascript library extensively in one project to build an administration interface for a legacy site. ExtJS is a powerful high-level library that simplifies the creation of desktop-like interfaces in the web browser. Instead of spending a lot of time hand-crafting HTML/ERb templates and CSS, Alameda quickly creates an interface in ExtJS and uses Rails to generate XML and JSON that drives the almost entirely client-side application. While some may find this outside the spectrum of what should be in a Rails book, many developers are now creating their interfaces in Flex, SilverLight, and other client-side technologies. With the recent official release of ActiveResource, I believe we will see more web-service-focused Rails applications as time goes on. Alameda's choice is also practical; with a small number of users having access to the interface, he can place greater requirements on them in order to deliver the application more quickly.
Overall, I believe Practical Rails Projects is a strong book for the intermediate Rails developer. It provides an introduction to more advanced concepts of the framework without being preachy or obtuse. It lacks any discussion of test- or behavior-driven development with Rails, but the breadth and depth of the topics it covers makes up for this weakness. Like any book that covers a rapidly-changing open-source project like Ruby on Rails, Projects will date quickly, but in the near-term it should be of great help to developers looking to gain constructive experience.
You can purchase Practical Rails Projects from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Bad scaling/'right for the right job' flames in: 3.. 2.. 1..
Does it come with its own set of rails and a freight train to transport the book around?
- constructing railroad tracks
- fencing material
- structural support for a building
and all I got was a pinkslip
"I know Alameda from our local Ruby User Group and spoke with him frequently while he wrote this book."
I would be a bit worried that this review might not totally objective or unbiased.
I was browsing someone's blog today, he was a rails developer I belive. Anyway, I clicked on submit comment with the fields empty. An animated gif appeared for 2 or 3 seconds, and then, it vanished, and an error message appeared: email can't be left blank, body can't be left blank. I smelled ajax. This is all very nice and well, but hell, how about encouraging people to learn javascript, you know the basics? rather than using a complex javasript library for any trivial task? Rails websites do feel heavy, but sometimes scaling has nothing to do with it.
This book was published in October, 2007, and Rails 2.0 was released December, 2007. According to the description on Amazon, only the last example deals with 2.0 at all.
Since there were some rather significant changes introduced in Rails 2.0, it is likely that many of the examples will no longer work as described. I know that is the case with current version Agile Web Development with Rails.
Life is like a web application. Sometime you need cookies just to get by.
I've found that Rails documentation falls into two categorys: (1) The annoyingly pedantic tutorial which falls apart if anything whatsoever goes wrong on your system, since the tutorial lacks any depth; and (2) Advanced docs that are moderately impenetrable to people not already very familiar with the relevant technologies.
I'm an experienced Perl and C guy who just wants to find a better way than CGI::Ajax to build slick web applications, but I found that I spent more time being annoyed with the documentation than actually learning. Intermediate indeed; Rails needs this.
Another practical Rails book that I can recommend is RailsSpace.
Shameless plug: my latest Rails project. To give you an idea how powerful Rails is, HowFlow has been developed in exaclty five days from scratch. It is currently in private beta, but I'm handing out invitations for those who send an email to flow at howflow.com.
The Art of Rails covers intermediate Rails topics quite nicely, and just came out so it had the chance to cover some of the Rails 2.0 developments (particularly related to nested routes and REST services). I've been reading through a copy and have found it really helpful so far -- especially the three chapters on advanced Ruby development patterns.
My second thought was, why is /. covering trains?
THEN I remembered that Ruby decided to name their framework with that term...
tm
Support TBI Research: http://www.raisinhope.org
..or else you'll end up like Twitter, and have a domain dedicated to telling you if the service is down or not.
I got out of Ruby on Rails shortly after using activescaffold's solutions. Their CMS was great, but trying to get help was a nightmare for any advanced functionality. Ruby on Rails needs an intermediate book, but it is too late for me, as my patience ran out.
I am no longer a Ruby on Rails fan as I have found more and more people complain about scalability. There have been numerous companies that have abandoned ship.
Ruby on Rails needs a corporation to take it and run with it. It needs an IBM, Microsoft, Oracle type of a company to give it the resources it needs.
I will second RailsSpace.
:symbol syntax for several chapters without having any idea what it actually was.).
I tried learning rails from Agile Web Development with Rails first, and I found that AWDwR has a huge deficiency: it frequently fails to explain the fundamental Ruby concepts and structures that it's using. (For example, I remember typing in the
RailsSpace, OTOH, does a really good job of stopping to explain each new concept, tool, or syntax in a sidebar; as a coder who didn't already know Ruby I found I was able to learn Rails much faster after I switched to RS.
I think RS suffers from a poorly-chosen name: because of the name, folks assume it is only about social networks. In fact it's a good basic tutorial to Rails that just happens to use a social networking site as the working example.
(Full disclosure; I know one of the authors of RailsSpace personally and have done contract work for him in the past.)
I stole this sig from someone cleverer than me.
You can buy this book for cheap in electronic format. Newegg has them, 100 copies on DVD for 24.99. and free three day shipping.
I keed, I keed. Relax! Hey you, RoR fans with the mod points! Put those back down!
After playing around with ruby on rails, I just didn't find that it was all that useful. Mostly I found it was just a painful exercise in learning exotic ways of doing things that I already knew how to do correctly. SQL, for example. Don't get me wrong, I see some merit in the rails way of doing things, but overall rails just seems like two steps back for anyone savvy enough to comprehend ruby in the first place.
Ruby, on the other hand, rocks out loud.
Drop me a line at:
Key ID: 0x54D1D809
Although I agree the MackFramework has the most potential of the 87 web frameworks that want to surplant Rails, it's not ready for Prime Time yet. In a couple of months, maybe, but for right now, I'd still use Rails for a professional project.
I'm sorry, what? Of course there's an objective view.
:)
I agree with you re: the biasing tendencies/constraints inherently present in human physiology, as well human (group) psychology.
But of _course_ there's an objective viewpoint.
It's the viewpoint which accurately reflects all things which can be accurately measured.
Most things which seem to be subjectively reported are mainly so because no metric exists or is being used which can measure the objectivity.
Math, most glaring of all, is objective. No one can have multiple correct opinions on what 2+2 equals... sure the symbols could be redefined, but semantically, there is but a single answer, unchanging.
But it doesn't stop there. Look up probabalistic primality tests on wikipedia:
http://en.wikipedia.org/wiki/Primality_test
Primality is an objective truth, which these tests are able to arrive at despite their innate bias & inaccuracy.
So what does that have to do with people? Most people's opinions and beliefs (and we've all got lots) deal with subjects which hard to measure, especially with regards to accuracy: Politics for one; but opinions on the worth of programming topics too, which is near and dear to everyone here.
It's not our neurological fallibility that does us in: some "objective" truths are _defined_ by human concensus: did I win the lottery this month? I can believe "yes" all I want, but unless my state's gaming commission believes as I do, it just isn't true.
But their belief defines the truth, and when looking for objective viewpoints, you have identify all the subjectively-defined truths.
Driving on the left vs the right is another...
there's no universal truth there, but certain groups of people have to agree, as a matter of protocol (Native language is yet another).
The other statements of fact are just objective truths we aren't able or willing to measure. Programming is one such... but because it's such a young branch of human knowledge (100 years worth of work and counting), it's one of the "known unknowns": like other types of engineering, we know there _is_ a best way to do things, we just haven't developed very good guiding principles to measure it yet.
But the only way to get there is to seek out objectivity, since it could be present anywhere.
So read the book over, and maybe this guy's wrong on a number of accounts, and you'll notice them.
So spread the word, blog/comment/whatever about _why_ he's wrong.
If your metric is accurate, it will be born out as it is applied to other situations, and by other people. We'll build up better and better guiding principles out of these meta-measurements. Eventually, we'll see more and more programming topics which _can_ be accurately and objectively measured, and in much the same way probabalistic primality tests wade through their biases to arrive at the correct answer.
Not believing in objective viewpoints is giving up the search for the truth, and that would be a shame, because that's one of the grandest of all of humanity's endeavours.
Regarding programming, we do have one great truth already:
Given the nature of the human mind, GOTO Considered Harmful. Great for processors to think in, but bad for us
I did not "get" Rails at first either. But now that I am familiar with it, I can do things in moments that it used to take half a day programming to do.
True, there is strong incentive to "go with the flow", and learn the "Rails Way" to do things... but most of the time that actually helps rather than hinders.
Do you find configuring Mongrel Clusters (usually just a command-line switch or two) difficult? Strange, nobody else seems to. And I am also curious: why do your "little toy apps" need init scripts in the first place?
They probably just don't need you anymore, now that it's in Rails. :O)
That was an old rumor, and Twitter is on record correcting these misapprehensions. Their problems were NOT due to Rails, and they have NO plans to switch away from Rails.
I was shooting for funny...
My other sig is extremely clever...
RoR is cute.
has "one size fits all" actually worked??
Sure, okay, it fits you just fine. But I doubt it would fit me, or a lot of others I know.
And you find this a difficult thing to do? Maybe you are in the wrong profession.
You don't know what you are talking about. Rails is not thread-safe. If you want to run multiple instances of Rails, you had BETTER run them in different processes, or you are going to blow yourself up. Which means: EVERY instance of Rails must run under its own web (not physical) server. If you are doing it differently, you are fucking up.
Now, allowing for the possibility that you meant something other than what I thought, I will state that Apache works best with multiple-threading applications. You can use it with Rails just fine... but on a host I was using recently, switching from an Apache front-end to a Mongrel-cluster with an nginx front-end, bypassing the Apache, the performance went up DRAMATICALLY. I am talking about a couple of orders of magnitude.
If you want to trade performance for less hassle, so be it. But don't claim that it will perform the same, because it will not.