small medium large xlarge

04 Jun 2010, 07:36
L H (4 posts)

I love the idea of teaching through example. The depot sample app is a fantastic way to cover a lot of ground. But it is getting progressively less useful. I think it’s an excellent idea to cover as much as possible in the sample app. Heck, you could base the entire book around it (I’d love it - take the depot app to about double it’s current length and really explain every line you add). But now it just jumps around too much, assumes too much, leaves out too much, and sends users to online references too much. It’s not that I don’t enjoy the references, it’s just that we buy this book so that the concepts get explained too us, not so that we can look up API references and try to comprehend them dryly. Heck, if that were so quick and easy for people trying to learn, we wouldn’t have needed to buy the book anyway.

The author very often puts unexplained lines in the code in the samples. I type them in, and yep, they work. But sometimes I’m left thinking “Why? What did we just do?” I have a strong commercial programming background, but rails is new to me, so yes I’d like more hand-holding. It’s easy to skim over something if we already get it, but if it’s never explained, then when we don’t get it we’re left on our own (which negates the purpose of buying the book).

“To fix this test, change it like this.” But why? How does that fix it? Here we have cart, ‘cart’, “cart”, @cart, :cart… I realize the general differences in terms of ruby syntax, but it would be great to have more explicit explanations at times of what is referencing what in what way and why that way. This is particularly important because we’re often taking advantage of Rail’s “convention over configuration”, and Rails itself is taking advantage of the interesting variety of Ruby syntax available, so at times it’s not at all clear.

Don’t get me wrong, I’m not completely disappointed in the purchase, and I understand that it’s still early on.

04 Jun 2010, 16:54
Prashant Shah (4 posts)

below are my personal opinions :

I find a single different app for each chapter to be more understandable. The app should be designed for the particular concept. I am also new to rails, after first few chapter it kind of gets complicate to link all the concepts together :) Also it gets boring to deal with the same depot application :)

“Head first rails” follows the different application for each chapter method which I found more suitable :)

04 Jun 2010, 18:27
Sam Ruby (634 posts)

L H: please say more! This is exactly the type of input I am looking for. Don’t be afraid to use errata to point out specific pages where additional explanation would be helpful. There are links on the bottom right of every page to the errata. Don’t be shy… feel free to report each and every time you see something that could stand with more of an explanation.

On the subject of online references: I have a number of thoughts. On one hand, I definitely agree that, in general, they are not terribly approachable. Certainly not to people new to the framework, and often not to people experienced with the framework. On the other hand, they are more comprehensive (Rails 3.0 is a big framework) and certainly by the time this becomes a printed book, will be more up to date.

So, I see as one of the goals of the book to be to get the reader to the point where they can find what they need online when they need to.

That being said, it is not the intent that readers will need to go to the online reference in order to understand the Depot application. That might be slightly less true for concepts rooted in Ruby (another topic which deserves a big book) than for Rails, but in either case if you find something in the Depot code that you don’t understand, that’s a bug. And a bug I want to fix.

You’ve given me some general areas for me to look at: in particular the coverage of testing was radically refactored in this edition.

What I am about to say needs to go into the book, but you heard it first here :-)

In many places in Rails, the use of ‘cart’, “cart” or even :cart doesn’t make a bit of difference. They are all synonyms, and will all be converted to strings or symbols as it makes sense prior to being as a treated as a parameter or a hash key or whatever. While all three can be used interchangeably in such contexts, when identifying something implemented in Ruby, such as a record (as opposed to an HTML concept), there is a preference to using the Ruby symbol notation, namely :cart.

Now for an inside scoop that is quite likely to not go into the book. In Rails 1.0 and much of Rails 2.x, DHH intentionally tried to consistently use ‘cart’ instead of “cart” for strings in every case except where interpolation ("#{expression}") is used. As Rails has gotten more contributors, this consistency has become diluted. This is not only true from Rails 2.x to Rails 3.x, it can change from one beta of Rails to the next beta, particularly in terms of generated configuration files and scaffolding.

Much of this will get cleaned up over time. Some of it will undoubtedly make to the second or third printing. Some of it is unfixable in the context of the book as it is code that is generated by scaffolding.

Returning back to the general comment: if you see something that caused you to slow down, please report it in the errata and it will be fixed. If it did more than cause you to slow down in that it is puzzling, report it here and I will try to provide an explanation and fix it in the book.

04 Jun 2010, 18:50
Sam Ruby (634 posts)

Prashant: personal opinions are welcome here. :-)

And glad to see it Works !.

There are advantages to building a single application, and there are disadvantages. Additionally, different people learn differently, hence the value in personal options. I will say that I learned Rails from the first edition of this book, and it worked well for me.

My intent at the moment is to leverage the advantages of building on the work so far (who wants to create an entirely new application just to internationalize it? I think that that it is an important point that one can “Ajaxify” an application with only relatively minor changes. And there is the whole “Agile Web Development” theme that the book intends to convey). That being said, I realize that choosing that approach requires me to mitigate the disadvantages.

Like I said to L H: don’t be shy. If you see something that isn’t explained clearly, report it. If it isn’t obvious to you, it probably isn’t obvious to somebody else. As a concrete example, the problem you had in installing I was able to identify the fix by finding this page. I did so by using this query, going to this page (missing!), and trying to reproduce your symptoms by adding and then removing the source.

Knowing what to query for and knowing how to interpret the results are the types of things that are second nature only after having developed a solid understanding of what the pieces are and how they fit together.

This is a long winded way of saying that I know I can do better (and if there is something I don’t know, certainly one of my co-authors will know), and if you can identify points in the book that you found not to be as clear or (dare I say it) as exciting as you would have expected, please point those areas out.

05 Jun 2010, 06:30
Ken Foust (5 posts)

I think a complete project is the only way to properly learn. I got really tired of the little tutorial because they assume you know stuff that you may not. With the Agile Rails books you can build a complete working application which is the ONLY way to learn. For those that get bored go do some of the short tutorials and then come back. That is what I do. I am trying to get Devise to work so I play around with that and then I take what I am learning and try it out on my own project that I want to build.

Thanks my take

13 Jun 2010, 09:17
L H (4 posts)

Sam, I’m going to try to reread the beta again and point out try to point out more specific examples this time through. Sometimes it’s just a matter of hours in the day, as I’m sure you can understand ;-)

In general I remember a lot of times in the testing sections where it felt like code was thrown in and quickly adjusted to work, but there wasn’t much explanation at all as to why it was adjusted as such, or how that adjustment affected the outcome. It just took me out of the “zone” when that happened.

Regarding the :foo vs. “foo” vs. ‘foo’ vs. foo vs. @foo, I played around with the code while going through some of the samples, and there are times when it makes a difference (if I remember correctly, it made a difference when dealing with variables that were accessible from other contexts “by convention”, like accessing variables in views or partials perhaps; I would use :foo instead of “foo” as a personal preference and it would work at one point, but then as we progressed in the code it would stop working unless I went back and made it exactly “foo”).

Again, I know you need more specifics for this to be helpful, so hopefully I’ll get a chance to point some out soon. But basically, I really like it when every (really - every) line of code is addressed. It’s easy to scan over what we already understand. But it also causes authors to drop great little nuggets about new languages and frameworks without even realizing it. Like your comment above about the way “” and ‘’ has been changing. Combining that with a “Notice here that you must use XXX syntax in this case because YYY” would have just really brought so many things into clear perspective at the time.

13 Jun 2010, 11:18
Seth Arnold (22 posts)

Incidentally, while I have a certain fondness for the depot application, having followed its birth four times now, I hope the fifth edition of the book will create a new application. :)

19 Jun 2010, 12:05
Aston J (18 posts)

I agree with the OP to an extent - I would prefer if everything that is referred to, has an explanation in the book somewhere. I’m just starting chapter 10 and the last time I felt that way was when we dealt with sessions - we use them but there’s little explanation about them, how they work or even why they work. (A paragraph or two would suffice.)

I do like the playtime bits tho, making you go out and ‘do it’ is an excellent way to learn imo, but the only drawback is because Rails 3 is brand new, you don’t know if the material you find on the web is relevant or not. So a lot of the time we will just be left scratching our heads - asking our selves if it’s changed in Rails 3 or not. If it doesn’t work we might wrongly assume it’s not Rails 3 compatible (something I did!). So I would prefer if there was a reference at the end of the book with enough info so we can complete the playtime questions without having to search the web.

In saying that - I am enjoying the book, esp the playtime stuff :D

04 Jan 2011, 20:49
Susan McM. Tucker (1 post)

I have to say that L H is spot on. There are numerous spots in this book that we, the learners, have to take a leap of faith and just type in the code. I wish that I had make a notation everywhere that I was unclear on what I was doing, and why. However, there have been numerous moments when I wish that there was a ‘companion’ online document to investigate further.

A good example is on page 190 of the (B11.0 printing, November 24, 2010) version. <%= sprintf(“%2d x %s”, line_item.quantity, truncate(line_item.product.title, :length => 50)) %>

What is sprintf? What do %2d and %s represent? Where in the Rails API is this documented?

Just a small thought.

05 Jan 2011, 15:50
radhames brito (1 post)

@susan McM Tucker

The thing is sprintf is a ruby function, how will the authors know where to draw the line between teaching rails or teaching ruby?, i havent seen the beta book but if that same case repeats along the book maybe is expected that the reader has some ruby knowledge, but if it only happens a couple of times, then the authors must add some side notes to clarify, specially when the explanation is as simple as “ sprintf is used to format strings in ruby”.

07 Jan 2011, 14:34
Sam Ruby (634 posts)

The first occurrence of the term sprintf in the book is “Ruby provides a sprintf function which can be used to format prices”. Perhaps the simple addition of a footnote to the sprintf function would suffice?

You must be logged in to comment