Anita Kuno writes "I suggested Head First Rails to a friend before I even finished it. He was asking me questions that I didn't have time to answer, and I knew the book could explain better than I. My friend is impatient, and I was uncertain what his experience would be. At first he was frustrated, but I assured him the answers were in the book. The incremental style of Head First Rails includes some exercises that are designed to fail to reinforce the learning process. I was confident that his answer would be found in the pages and he trusted me enough to go back and continue the exercises. He later told me he is very happy with the book and grateful that I suggested it." Read on for the rest of Anita's review.
Rails is a framework for creating web applications. It is written in Ruby. It uses a structure called MVC which stands for model view controller. Rails separates tasks so that operations are modularized. Once a development team understands Rails, its use can increase the speed of creating web applications. Head First Rails explains the beginning steps needed to create Ruby on Rails applications. It introduces vocabulary; teaches the basic relationships that comprise Rails: the model, the view, and the controller; and demonstrates code creation that controls the MVC interaction. The title 'Head First Rails: A Learner's Companion to Ruby on Rails' describes the approach of the book. The author acknowledges that this book is one of many that will assist the active learner to begin Ruby on Rails. Proficiency in the Rails framework requires accumulating information from a number of sources and the book mentions quite a few and encourages consultation of those resources.
While previous Rails experience is not required (nor is previous Ruby experience) it is expected that the reader have a working understanding of HTML & CSS as well as a basic understanding of a scripting language. Java, C# or PHP are mentioned as scripting examples. I had tried several beginning Rails books previously and Head First Rails was the first I could complete. I feel it is a reflection of the speed of development of the framework and the fact that most of the people that I know involved with Rails are so busy creating apps, they don't have time to teach the n00bs.
Head First Rails assumes that you already have Rails installed on your system. The home page for Head First Rails provides a link to the download page at rubyonrails.org by way of providing installation instructions. I didn't see a reference in the book's index to Rails installation, which I find rather odd. It would be a simple matter to include a short paragraph explaining why detailed instructions aren't included with the book (as is explained on the home page for the book) with a URL to the book's homepage. Ruby and Rails are both opensource software so they are freely available for all systems.
Head First Rails has images, illustrations and graphics that are used to introduce and underscore one concept at at time. The book is designed so that each page and its facing page comprise an experience of one concept. As you turn each page you are introduced to a concept, given details and challenged in some form. When you turn the page you are on to the next piece of information which builds upon what you have already learned. The format of the book is designed to promote information retention and some of the exercises may prove frustrating at certain points. The frustration promotes original thinking and information retention. I feel it is a valuable part of learning. Since I rarely have the time to focus on a book exclusive to the rest of my life, I find the format helpful. I can attend to other things and pick up the book after two weeks and continue from where I left off. It is helpful to have access to information that I can pick up and put down and still accumulate knowledge.
Head First Rails is conversational and encourages original thought. The exercises, which are the foundation of the book, are accompanied by code samples for download to encourage comparison. The first time we dive into an app and edit the specific files, I felt that the identification of which file we were editing and how to locate the file in the Rails application directory tree needed to be clarified a little better. Soon the examples fell into a rhythm and I knew where to find the information I needed.
One thing that did get my attention was the use of whitespace or lack thereof in code. I have been taught to use 2 spaces to indent Ruby code (which affects Rails code as well) and while the code samples did use the convention, I didn't see the indent by 2 spaces rule explicitly stated. I'm not confident that a n00b would just pick that up. They would probably have to be informed. My other whitespace comment concerns hashes. I have been taught to have one space between the key and hash delimiter and another single space between the hash delimiter and the value. I did not see this in the code samples. I frequently saw no space whatsoever separating the key, delimiter and value. I have come to understand that developers rate another developer's worth based upon code samples, and lack of whitespace when it is expected is viewed as a bad habit. The composer of said code might be either chastised or dismissed due to poor technique. Perhaps my understanding of the situation is extreme but again in a book for n00bs, the reader will copy exactly what they see. So if there isn't whitespace on either side of the hash delimiter in the book, how will the reader know to compose code using that convention?
A few of the author's terms were confusing. He uses the term 'scriptlets' to refer to ERB output tags, and 'expressions' to refer to ERB expression tags. The Rails developers I questioned about this were able to figure out what he meant by 'expressions' but none of them had ever heard of ERB output tags being called 'scriptlets'. Also, the author uses 'finder' to refer to dynamic finders and I think it would have been useful to use the term 'dynamic finder'. It is more specific and the keyword 'dynamic' is useful when employing a search engine to research the functionality of dynamic finders. A search for 'finders' doesn't return one Rails related hit on the first page, while a search for 'dynamic finders' gives me a Rails related hit as the first return.
These are small points and perhaps this is more reflective of the culture of Rails developers that informs me, but in a n00b book it is important to provide clear vocabulary and conventions. These small points may be the techniques that have the longest shelf life to the reader.
I have been waiting for this book to be written and available for at least a year and a half. This was the first beginning Rails book that I found that didn't assume I was transitioning from a background in PHP. I have been spending time with the Ruby and the Rails community for close to 2 years now and am grateful that I finally have an explanation of the topic that is accessible for me.
Rails is changing very quickly and even now is about to merge with Merb to create Rails 3.0. It is tough to say how long the information in Head First Rails will be relevant. If you are interested in this book because you think Rails is fashionable, you might be distracted by a new trend before you finish the book. If you are interested in Rails because you have seen what it can do, you recognize its power and you want to learn how to get that for yourself, you will recognize the value in these pages.
You can purchase Head First Rails from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.