Jay Levitt wrote:
> On Sun, 07 Oct 2007 23:33:21 -0400, Eric H. wrote:
> 
>> Sadly, I'd rather buy your book if I needed it than to pay for the info
>> to be included in the other books where I do not. ;)
> 
> Sure.  The problem is the use case of someone who's been wanted to play
> with Rails all week.  Finally has a long weekend, stops by Barnes & Noble
> or CompUSA to find the appropriate books.  They have a few, some are even
> the latest version.  He grabs them, takes them home, and starts reading:
> 
> "First, enter the console app, where you'll be able to execute ruby
> statements with real-time feedabck.  From console..."
> 
> and the reader goes "What?  What conosle? What directory is it in?"

My first question would be "why the hell can't the idiot just look
online and figure this out in the first place like any of the rest of
us?!!??!" but since I know that's too simple...

I understand and yet you also mention the problem with this: the number
of different platforms it is on and the vast differences that each
provide. The install for Fedora Core is different from OSX, or Windows,
and probably Debian and BSD, etc.

A list of links to pages that have up-to-date information on installing
for each platform and the idiosyncrasies for each is a better solution
than attempting to claim to be all-knowledgeable for all platforms when
in reality the author is really only experienced in a very few of the
platforms mentioned. Those pages could then deal with the console and
the directories that everything can be found in, etc. and could be
changed according to new releases. This would make Ruby/Rails books less
likely to become obsolete to those same readers you discussed if the
installation procedures were to change; it wouldn't leave them high and
dry and with a $40 paperweight.

Think about it, we live in an age where the Internet rules, and we're
learning about a programming language that is used mostly for web
development but we're supposed to rely on a few pieces of paper to tell
us the most recent news about installer quirks, etc. Since those
installer quirks are more likely to change than the basic language(etc.)
is, I don't see the point in including such a chapter.