Forum: Ruby Forthcoming 2nd ed. of _The Ruby Way_

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
unknown (Guest)
on 2005-12-15 01:05
(Received via mailing list)
Hello, all.

Thought I might as well announce this "officially" as many people
know it already.

The ink is dry on the contract, and I am working on a second edition
of _The Ruby Way_. Expect to see it second quarter of 2006.

To summarize: About 100 pages deleted, about 250 pages added.
Updated from 1.6.8 to 1.8.4 (or thereabout).

If you have comments or suggestions, feel free to make them.

I can't cover everything, but I want to cover the important and
interesting
stuff (as time and space permit). If you see it in the "keyword soup"
below, it's under consideration. If you think I've forgotten something
important, please tell me in email.


Thanks,
Hal F.


Keyword soup:
Rockit racc rbison io/nonblock readpartial StringIO csv Oniguruma
Madeleine Oracle DBI LDAP ORMs (AR, Og, etc.) define_method
const_missing
JTTUI Qt One-click installer EXERB imap pop3 SSL ssh tunnelling OpenURI
NNTP WEBrick Redcloth Bluecloth etc.  fastcgi Ruby on Rails Nitro
amrita
borges cgi-kit narf cerise SOAP REST WebDAV XML-RPC Okay (YAML)
Rinda and Ring CORBA REXML irb Test::Unit xmp pp rcov generator
enumerator
OSX KirbyBase Cocoa YAML iCal etc. vCard RSS RDF RMagick Flash (Alph)
PDF Rake mkmf extconf.rb SWIG Ruby/DL CVS Subversion gnuplot Mozilla
Java .NET RDoc RubyGems setup.rb RAA RubyForge ri vim emacs Scite
FreeRIDE RDE ArachnoRuby Komodo Eclipse Blog tools Wiki tools RCRs
Jim F. (Guest)
on 2005-12-15 01:15
(Received via mailing list)
On 12/14/05, removed_email_address@domain.invalid 
<removed_email_address@domain.invalid> wrote:
> Hello, all.
>
> The ink is dry on the contract, and I am working on a second edition
> of _The Ruby Way_. Expect to see it second quarter of 2006.

Congrats

> I can't cover everything, but I want to cover the important and
> interesting
> stuff (as time and space permit). If you see it in the "keyword soup"
> below, it's under consideration. If you think I've forgotten something
> important, please tell me in email.

CommandLine and its children: Application, Option, OptionParser and
OptionData.
James G. (Guest)
on 2005-12-15 02:24
(Received via mailing list)
On Dec 14, 2005, at 5:03 PM, removed_email_address@domain.invalid wrote:

> Hello, all.
>
> Thought I might as well announce this "officially" as many people
> know it already.
>
> The ink is dry on the contract, and I am working on a second edition
> of _The Ruby Way_. Expect to see it second quarter of 2006.

This is just fantastic news.  The old version is quite out of date
and yet still my second favorite Ruby book!

> Keyword soup:
> ...csv...

I realize this is tooting my own horn, but it would be great if
FasterCSV[1] made it in there if only as a footnote.  I know it's not
a standard library, but it reads and writes just fine and is almost 9
times faster than the standard library.  This might be important
since I've seen multiple complaints about CSV speed here and on Ruby
Core.

I'm also hard at work adding cool new features to it that should be
in long before the book is ready.  Features not yet is CSV.  :)

End advertisement.  We now return you to your regular programming.

James Edward G. II

1:  http://rubyforge.org/projects/fastercsv/
Jeff W. (Guest)
on 2005-12-15 02:36
(Received via mailing list)
... Please be sure to provide it in PDF form... That's how I have my
current edition and I really appreciate it.

j.

On 12/14/05, James Edward G. II <removed_email_address@domain.invalid> wrote:
> This is just fantastic news.  The old version is quite out of date
> Core.
>
>


--
"Remember. Understand. Believe. Yield! -> http://ruby-lang.org"

Jeff W.
Tanner B. (Guest)
on 2005-12-15 03:09
(Received via mailing list)
On 12/14/05, removed_email_address@domain.invalid 
<removed_email_address@domain.invalid> wrote:
>
> Hal F.
> Rinda and Ring CORBA REXML irb Test::Unit xmp pp rcov generator
> enumerator
> OSX KirbyBase Cocoa YAML iCal etc. vCard RSS RDF RMagick Flash (Alph)
> PDF Rake mkmf extconf.rb SWIG Ruby/DL CVS Subversion gnuplot Mozilla
> Java .NET RDoc RubyGems setup.rb RAA RubyForge ri vim emacs Scite
> FreeRIDE RDE ArachnoRuby Komodo Eclipse Blog tools Wiki tools RCRs
>
>
At least a small section on Rake would be excellent.
Joe Van D. (Guest)
on 2005-12-15 03:15
(Received via mailing list)
On 12/14/05, Tanner B. <removed_email_address@domain.invalid> wrote:
> > Updated from 1.6.8 to 1.8.4 (or thereabout).
> > Thanks,
> > borges cgi-kit narf cerise SOAP REST WebDAV XML-RPC Okay (YAML)
> > Rinda and Ring CORBA REXML irb Test::Unit xmp pp rcov generator
> > enumerator
> > OSX KirbyBase Cocoa YAML iCal etc. vCard RSS RDF RMagick Flash (Alph)
> > PDF Rake mkmf extconf.rb SWIG Ruby/DL CVS Subversion gnuplot Mozilla
> > Java .NET RDoc RubyGems setup.rb RAA RubyForge ri vim emacs Scite
> > FreeRIDE RDE ArachnoRuby Komodo Eclipse Blog tools Wiki tools RCRs
> >
> >
> At least a small section on Rake would be excellent.

I think it's under consideration, considering that Rake is in that
'keyword soup'.
Hal F. (Guest)
on 2005-12-15 05:25
(Received via mailing list)
Joe Van D. wrote:
> On 12/14/05, Tanner B. <removed_email_address@domain.invalid> wrote:
>>At least a small section on Rake would be excellent.
>
> I think it's under consideration, considering that Rake is in that
> 'keyword soup'.

Yep, should have alphabetized it. But then it wouldn't be soup,
would it? :)

Hal


"There's a message in my AlphaBits! It says, 'OOOOOO'!"
"Those are CheeriOs."
             -- _Family Guy_
Bill G. (Guest)
on 2005-12-15 06:04
(Received via mailing list)
On 12/14/05, Hal F. <removed_email_address@domain.invalid> wrote:
> Joe Van D. wrote:
> > On 12/14/05, Tanner B. <removed_email_address@domain.invalid> wrote:
> >>At least a small section on Rake would be excellent.
> >
> > I think it's under consideration, considering that Rake is in that
> > 'keyword soup'.
>
> Yep, should have alphabetized it. But then it wouldn't be soup,
> would it? :)

Sure it would.  It would be alphabet soup ;)

Any chance of it following the prag prog's beta book release method?

Either way, looking forward to it.
Eero S. (Guest)
on 2005-12-15 06:27
Hal F. wrote:
> Joe Van D. wrote:
>> On 12/14/05, Tanner B. <removed_email_address@domain.invalid> wrote:
>>>At least a small section on Rake would be excellent.
>>
>> I think it's under consideration, considering that Rake is in that
>> 'keyword soup'.
>
> Yep, should have alphabetized it. But then it wouldn't be soup,
> would it? :)

First, one more congratulatory note: congrats! :)

The few exciting and very soupy technologies I could
think of off-hand are SCGI, RubyScript2Exe and the
whole ParseTree/Ruby2C cadre.

A footnote of such alternatives as Rant and Wee might
be well-received, too!

> Hal
>
>
> "There's a message in my AlphaBits! It says, 'OOOOOO'!"
> "Those are CheeriOs."
>              -- _Family Guy_

*Dashes off to purchase season 3*


E
Ezra Z. (Guest)
on 2005-12-15 06:46
(Received via mailing list)
On Dec 14, 2005, at 3:03 PM, removed_email_address@domain.invalid wrote:

>
> Hal F.
> borges cgi-kit narf cerise SOAP REST WebDAV XML-RPC Okay (YAML)
> Rinda and Ring CORBA REXML irb Test::Unit xmp pp rcov generator
> enumerator
> OSX KirbyBase Cocoa YAML iCal etc. vCard RSS RDF RMagick Flash (Alph)
> PDF Rake mkmf extconf.rb SWIG Ruby/DL CVS Subversion gnuplot Mozilla
> Java .NET RDoc RubyGems setup.rb RAA RubyForge ri vim emacs Scite
> FreeRIDE RDE ArachnoRuby Komodo Eclipse Blog tools Wiki tools RCRs

Impressive list of topics! i will buy this book in a heart beat!

Cheers-

-Ezra Z.
WebMaster
Yakima Herald-Republic Newspaper
removed_email_address@domain.invalid
509-577-7732
Hal F. (Guest)
on 2005-12-15 07:01
(Received via mailing list)
Ezra Z. wrote:
>> Rinda and Ring CORBA REXML irb Test::Unit xmp pp rcov generator
>> enumerator
>> OSX KirbyBase Cocoa YAML iCal etc. vCard RSS RDF RMagick Flash (Alph)
>> PDF Rake mkmf extconf.rb SWIG Ruby/DL CVS Subversion gnuplot Mozilla
>> Java .NET RDoc RubyGems setup.rb RAA RubyForge ri vim emacs Scite
>> FreeRIDE RDE ArachnoRuby Komodo Eclipse Blog tools Wiki tools RCRs
>
>
> Impressive list of topics! i will buy this book in a heart beat!
>

Thank you.

Let me clarify, though, lest anyone misunderstand -- not all of these
topics will be covered in depth. Depending on time and pages and so on,
some may barely be mentioned.

That's one reason I want assistance in prioritizing things. In addition,
some of these I know little about, and will have to learn within the
next ninety days or so, or just skip them.


Hal
unknown (Guest)
on 2005-12-15 10:10
(Received via mailing list)
In article <removed_email_address@domain.invalid>,
 <removed_email_address@domain.invalid> wrote:
>
>Hal F.
>Rinda and Ring CORBA REXML irb Test::Unit xmp pp rcov generator
>enumerator
>OSX KirbyBase Cocoa YAML iCal etc. vCard RSS RDF RMagick Flash (Alph)
>PDF Rake mkmf extconf.rb SWIG Ruby/DL CVS Subversion gnuplot Mozilla
>Java .NET RDoc RubyGems setup.rb RAA RubyForge ri vim emacs Scite
>FreeRIDE RDE ArachnoRuby Komodo Eclipse Blog tools Wiki tools RCRs
>


That's good news!
My own 2cents:

I especially like chapter 5 (OOP and Dynamicity in Ruby) in the current
edition of TRW.  I hope that perhaps a similar chapter on
metaprogramming can
be added.

Also: I would like to see the second edition stick to advanced Ruby
programming topics/philosophy and mostly stay away from specific
libraries (so
basically staying away from a lot of the things you list above ;-)  Why
do I
say this: because the title 'The Ruby Way' implies that you're going to
impart
the philosophy of Ruby programming.  Your introduction leads to this as
well.
But if you start loading up with too many specific libraries/etc. then
it
starts looking less and less like 'The Ruby Way' and more like a tour of
Ruby libraries.  A lot of items in the "keyword soup" are ephemeral -
is Rockit really being maintained and used at this point, for example?
(and
what about Grammar?)  I think you should focus on things that are not
ephemeral in Ruby.

Gems and Rake would be two 'externals' that should be included though,
as they
are either becoming central to or exemplify The Ruby Way (Rake could be
covered as an example of metaprogramming, for example).  Onigurma
deserves
coverage because it will be the new regex engine.   I'd like to see more
advanced coverage of things like using the various callbacks (included,
inherited, etc.), metaprogramming, functional Ruby (stuff like what's in
the
"Higher order Perl" book).

Leave specific GUI toolkits like Tk, or Qt to another book...

I really like "The Ruby Way"; I would like to see it move more in the
direction of "The Ruby Way: Advanced Ruby P.ming Techniques" or
something
like that... as opposed to "The Ruby Way: A brief look at lots of
libraries(many of which will be obsolete by this time next year)".


Phil
Kev J. (Guest)
on 2005-12-15 10:25
(Received via mailing list)
>I really like "The Ruby Way"; I would like to see it move more in the
>direction of "The Ruby Way: Advanced Ruby P.ming Techniques" or something
>like that... as opposed to "The Ruby Way: A brief look at lots of
>libraries(many of which will be obsolete by this time next year)".
>
>
Although I haven't read the ruby way, I'd prefer to see a coverage of
more advanced programming techniques in Ruby, instead of a brief
overview of Library X,Y,Z, but then again how do you define advanced?
My idea of advanced is Dwemthy's Array (which I actually just got my
head around this week).

my 2 vitenamese dong (roughly 2/15000 c)
Kev
Leslie V. (Guest)
on 2005-12-15 12:29
(Received via mailing list)
I know it's a long shot but the only thing I have found missing
from "the Ruby way" so far has been something on graphics -
ie. Ruby SDL etc. I'd love to see some pointers on that.

Leslie
George M. (Guest)
on 2005-12-15 12:41
(Received via mailing list)
Great  to hear :)

I really loved the original book. If you need any help with Nitro/Og
don't hesitate to contact me ;-)

-g.
Luc H. (Guest)
on 2005-12-15 12:53
(Received via mailing list)
On 15 déc. 05, at 01:34, Jeff W. wrote:

> ... Please be sure to provide it in PDF form... That's how I have my
> current edition and I really appreciate it.

Make that a Pickaxe-2-style-beta-book and I'm signing up right away :)
Chris G. (Guest)
on 2005-12-15 14:17
(Received via mailing list)
Hal F. wrote:

> Let me clarify, though, lest anyone misunderstand -- not all of
> these topics will be covered in depth. Depending on time and
> pages and so on, some may barely be mentioned.

There's more to a book than a list of topics. What about depth,
starting point, assumptions of reader ability, reference vs learning
model (see Kathy Sierra's blog), inclusion of tutorials, examples,
exercises...


(Thanks as ever to the random sig generator for an entirely
appropriate one...)
--
Chris G.

"Imagination is more important than knowledge."
		-- Albert Einstein
Jack C. (Guest)
on 2005-12-15 14:45
(Received via mailing list)
Phil T. wrote:

>say this: because the title 'The Ruby Way' implies that you're going to impart
>covered as an example of metaprogramming, for example).  Onigurma deserves
>libraries(many of which will be obsolete by this time next year)".
>
>
>Phil
>
>
>
>
+1. I'd also be much more interested in pure, advanced Ruby rather than
specifics of this or that library.

Jack
Brian B. (Guest)
on 2005-12-15 15:33
(Received via mailing list)
I bought your first book.  Loved it.

I'm anxious to see the 100 pages you plan on deleting.  Always good to
know
the things to unlearn too.

Brian
James G. (Guest)
on 2005-12-15 16:03
(Received via mailing list)
On Dec 14, 2005, at 10:59 PM, Hal F. wrote:

> That's one reason I want assistance in prioritizing things. In
> addition,
> some of these I know little about, and will have to learn within the
> next ninety days or so, or just skip them.

Can you use the community?  Together we know a fair amount.  ;)

James Edward G. II
Takashi Sano (Guest)
on 2005-12-15 16:09
(Received via mailing list)
Hi,

2005/12/15, Phil T. <removed_email_address@domain.invalid>:
> starts looking less and less like 'The Ruby Way' and more like a tour of
> inherited, etc.), metaprogramming, functional Ruby (stuff like what's in the
> "Higher order Perl" book).
>
> Leave specific GUI toolkits like Tk, or Qt to another book...
>
> I really like "The Ruby Way"; I would like to see it move more in the
> direction of "The Ruby Way: Advanced Ruby P.ming Techniques" or something
> like that... as opposed to "The Ruby Way: A brief look at lots of
> libraries(many of which will be obsolete by this time next year)".

My 2 yen for all the above.

To add the list, I would like to see a chapter or section on interface
- what is and how to create clean API in ruby.

Takashi Sano
Doug H (Guest)
on 2005-12-15 16:18
(Received via mailing list)
I'd recommend the exact opposite.  If you ignore the libraries and GUI
toolkits, the book is virtually useless.  Most people are using ruby to
develop _applications_, not to learn programming for programming's
sake.
Xavier N. (Guest)
on 2005-12-15 16:48
(Received via mailing list)
On Dec 15, 2005, at 15:17, Doug H wrote:

> I'd recommend the exact opposite.  If you ignore the libraries and GUI
> toolkits, the book is virtually useless.  Most people are using
> ruby to
> develop _applications_, not to learn programming for programming's
> sake.

I agree with the other poster about the expectations the title
creates. I readed the book and was useful for me because i was
learning, practical issues are addressed, and you are exposed to
idiomatic Ruby. But I would expect it to evolve to explain "The Ruby
Way" of programming, so my vote goes there.

Explaining libraries and toolkits is certainly useful, but a topic
for a different book in my opinion.

-- fxn
Gene T. (Guest)
on 2005-12-15 17:00
(Received via mailing list)
removed_email_address@domain.invalid wrote:
>
"100 pages deleted": does this mean Rb vs. perl/python sections are
expendable? I can understand, these entail a *lot* of research, &
recently there's been an explosion of R vs. p/p/java/smalltalk/lisp
blogs which can be collected on 'Ruby eye for python guy' or some
wiki.

The part of Way r.1 that's most valuable to me today is the "Things to
remember" list on pages 45+
GJB (Guest)
on 2005-12-15 17:45
(Received via mailing list)
Phil T. wrote:
> I especially like chapter 5 (OOP and Dynamicity in Ruby) in the current
> edition of TRW.  I hope that perhaps a similar chapter on metaprogramming can
> be added.

I also especially like chapter 5.   Definitely a chapter on
metaprogramming!  I like the idea of advanced topics especially those
things are easily done in a dynamically typed language and difficult in
staticly typed languages.   But I like the library coverage as well.
Write both and I'll buy both :  )  If it's available in early access,
I'll buy that too!

Willing to put my money where my mouth is,

Gary Blomquist
James B. (Guest)
on 2005-12-15 18:00
(Received via mailing list)
Doug H wrote:
> I'd recommend the exact opposite.  If you ignore the libraries and GUI
> toolkits, the book is virtually useless.  Most people are using ruby to
> develop _applications_, not to learn programming for programming's
> sake.

Coding applications in Ruby without taking full advantage of what makes
Ruby R. is like walking up a hill backwards.  You'll get where you
want to go, but it could be so much nicer.

A guide to libraries would be handy, but indeed many are ephemeral or in
flux, and learning a set of distinct APIs for one thing or another is no
substitute for a proper understanding of Ruby itself.

It's the difference between being a [application|library] scripter and a
Ruby programmer.


James



--

http://www.ruby-doc.org       - Ruby Help & Documentation
http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted
http://www.rubystuff.com      - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com     - Playing with Better Toys
http://www.30secondrule.com   - Building Better Tools
Raphael B. (Guest)
on 2005-12-15 18:21
(Received via mailing list)
<snip>

> I can't cover everything, but I want to cover the important and
> interesting
> stuff (as time and space permit). If you see it in the "keyword soup"
> below, it's under consideration. If you think I've forgotten something
> important, please tell me in email.
>

One suggestion;

ncurses or equivalent  (I hope I didn't miss it in the soup or the
thread :-)

Raph
Greg D. (Guest)
on 2005-12-15 19:00
(Received via mailing list)
On 12/15/05, GJB <removed_email_address@domain.invalid> wrote:
> If it's available in early access,
> I'll buy that too!

Is that the plan?  Seemed to work well for the Rails book.  I'd
definitely buy a beta copy in PDF form (now) for a hard copy final
edition later.


--
Greg D.
Zend Certified Engineer
MySQL Core Certification
http://destiney.com/
Laurent J. (Guest)
on 2005-12-15 19:27
(Received via mailing list)
That's good news! On my wish list are: soap, xml/rpc, wsdl

Laurent
Gavri F. (Guest)
on 2005-12-15 20:55
(Received via mailing list)
On 12/15/05, James B. <removed_email_address@domain.invalid> wrote:

> Coding applications in Ruby without taking full advantage of what makes
> Ruby R. is like walking up a hill backwards.  You'll get where you
> want to go, but it could be so much nicer.
>
> A guide to libraries would be handy, but indeed many are ephemeral or in
> flux, and learning a set of distinct APIs for one thing or another is no
> substitute for a proper understanding of Ruby itself.
>
> It's the difference between being a [application|library] scripter and a
> Ruby programmer.

'The Ruby Way' handles metaprogramming and other advanced topics in a
very cursory manner. More than half of The Ruby Way was concerned with
Ruby's libraries. But many of you seem to expect the second edition to
completely shift it's focus. I don't know how that's going to happen
just by ripping out 100 pages and adding 250 pages considering all the
new stuff from that keyword soup is going in.

Aren't there "Advanced Ruby" books in japanese that could be
translated? I've been hoping for a long time someone would translate
that "Ruby Internals" book and others like it. But all I see is
another cookbook from O'Reilly and a bunch of Rails books. There's a
huge market here. I, for example, would buy any book that says
"Advanced Ruby" on the cover (without even bothering to open the book
and check out the contents) :-)
Wilson B. (Guest)
on 2005-12-15 21:22
(Received via mailing list)
On 12/15/05, Gavri F. <removed_email_address@domain.invalid> wrote:
> On 12/15/05, James B. <removed_email_address@domain.invalid> wrote:
>
> Aren't there "Advanced Ruby" books in japanese that could be
> translated? I've been hoping for a long time someone would translate
> that "Ruby Internals" book and others like it. But all I see is
> another cookbook from O'Reilly and a bunch of Rails books. There's a
> huge market here. I, for example, would buy any book that says
> "Advanced Ruby" on the cover (without even bothering to open the book
> and check out the contents) :-)
>
Yep. 100% agreement.

Speaking of which, does anyone know where to get a copy of this
shipped to the U.S.?
Ruby Source Code Complete Explanation:
http://www.amazon.co.jp/exec/obidos/ASIN/4844317210/
Amazon.co.jp won't ship it, because it's only sold via Amazon Shops.

--Wilson.
unknown (Guest)
on 2005-12-15 22:59
(Received via mailing list)
In article <removed_email_address@domain.invalid>,
Takashi Sano  <removed_email_address@domain.invalid> wrote:
>
>
>My 2 yen for all the above.
>
>To add the list, I would like to see a chapter or section on interface
>- what is and how to create clean API in ruby.
>

that's a great idea.  And perhaps a section in that chapter on creating
plug-in  architectures.

Phil
unknown (Guest)
on 2005-12-15 22:59
(Received via mailing list)
In article <removed_email_address@domain.invalid>,
Doug H <removed_email_address@domain.invalid> wrote:
>I'd recommend the exact opposite.  If you ignore the libraries and GUI
>toolkits, the book is virtually useless.  Most people are using ruby to
>develop _applications_, not to learn programming for programming's
>sake.
>

I'm not necessarily talking about 'learning programming for
programming's
sake' (though, personally I see nothing wrong with that and I hope to
see a
good bit of that in there :).  I'm talking about
learning advanced Ruby programming techniques that will help you develop
those
applications/APIs/Frameworks that you want to develop.

Phil
unknown (Guest)
on 2005-12-15 23:05
(Received via mailing list)
In article <removed_email_address@domain.invalid>,
Xavier N.  <removed_email_address@domain.invalid> wrote:
>learning, practical issues are addressed, and you are exposed to
>idiomatic Ruby. But I would expect it to evolve to explain "The Ruby
>Way" of programming, so my vote goes there.
>
>Explaining libraries and toolkits is certainly useful, but a topic
>for a different book in my opinion.

Exactly, or different little books like the Pragmatic folks are doing.
GUI
toolkits, for example, should be covered in those kinds of little books
(50 to
100 pages).  "The Pocket Book of Ruby/(Tk|Qt|gtk|...)"


Phil
unknown (Guest)
on 2005-12-15 23:08
(Received via mailing list)
In article
<removed_email_address@domain.invalid>,
Gavri F.  <removed_email_address@domain.invalid> wrote:
>> It's the difference between being a [application|library] scripter and a
>translated? I've been hoping for a long time someone would translate
>that "Ruby Internals" book and others like it. But all I see is
>another cookbook from O'Reilly and a bunch of Rails books. There's a
>huge market here. I, for example, would buy any book that says
>"Advanced Ruby" on the cover (without even bothering to open the book
>and check out the contents) :-)

 I guess I'm pushing for this shift of focus in The Ruby Way because
it's
already about 1/2 way there.  Again, I would suggest that any chapters
dealing
with specific libraries, GUI toolkits should be eliminated from the 2nd
ed.
and other chapters on advanced Ruby programming topics should be added.
I
think this will help TRW become an enduring classic.

We really need an advanced Ruby book now.  There are cookbooks on the
horizon
and there are other Rails related titles as well as some introductory
texts,
but I haven't heard about plans for an advanced book.  I think The Ruby
Way
could be that book.

Phil
unknown (Guest)
on 2005-12-15 23:17
(Received via mailing list)
In article
<removed_email_address@domain.invalid>,
Gavri F.  <removed_email_address@domain.invalid> wrote:
>
>Aren't there "Advanced Ruby" books in japanese that could be
>translated? I've been hoping for a long time someone would translate
>that "Ruby Internals" book and others like it. But all I see is
>another cookbook from O'Reilly and a bunch of Rails books. There's a
>huge market here. I, for example, would buy any book that says
>"Advanced Ruby" on the cover (without even bothering to open the book
>and check out the contents) :-)

Sorry for replying twice, but I wanted to get to this idea of
translating
Japanese books.  In Japan they have lots of smaller books that cover the
libraries.  They basically have a similar form factor to O'Reilly pocket
guides.  I think that's the way to cover libraries.  One person may be
very
interested in GUI programming but has absolutely no interest in network
programming (and vice verse).  Plus, as a library changes, the smaller
single-focus book will be able to keep up with the changes much more
easily.

Also, up till now there has been no Japanese Ruby book translated into
English (except for perahaps Ruby in a Nutshell). I suspect that there
are
good reasons for this.

Phil
Patrick H. (Guest)
on 2005-12-15 23:32
(Received via mailing list)
On 12/15/05, Phil T. <removed_email_address@domain.invalid> wrote:
> We really need an advanced Ruby book now.

Shifting the focus of the thread a little bit, but what would your
idea table of contents look like in an Advanced Ruby book?

Off the top of my head randomly ordered:

* Variable Scope
* Regular Expressions
* Unit Testing
* Module
* Class
* Metaprogramming
* Domain Specific Languages
* Continuations
* Threads and Processes
* Extensions
* Embedding Ruby

pth
Gavri F. (Guest)
on 2005-12-15 23:38
(Received via mailing list)
On 12/16/05, Phil T. <removed_email_address@domain.invalid> wrote:
> Sorry for replying twice, but I wanted to get to this idea of translating
> Japanese books.  In Japan they have lots of smaller books that cover the
> libraries.  They basically have a similar form factor to O'Reilly pocket
> guides.  I think that's the way to cover libraries.  One person may be very
> interested in GUI programming but has absolutely no interest in network
> programming (and vice verse).  Plus, as a library changes, the smaller
> single-focus book will be able to keep up with the changes much more easily.

The Pragmatic Programmers are doing it
http://pragmaticprogrammer.com/shopsite_sc/store/h...

> Also, up till now there has been no Japanese Ruby book translated into
> English (except for perahaps Ruby in a Nutshell). I suspect that there are
> good reasons for this.

I guess the good hackers can't get interested in a translating job and
the not-so-good ones aren't approached by publishers.
Please. Could somebody make the sacrifice and translate a few books for
us? :)
Bill G. (Guest)
on 2005-12-15 23:41
(Received via mailing list)
On 12/15/05, Patrick H. <removed_email_address@domain.invalid> wrote:
> * Unit Testing
> * Module
> * Class
> * Metaprogramming
> * Domain Specific Languages
> * Continuations
> * Threads and Processes
> * Extensions
> * Embedding Ruby

I _really_ like that list.
James B. (Guest)
on 2005-12-16 00:58
(Received via mailing list)
Gavri F. wrote:
> completely shift it's focus. I don't know how that's going to happen
> just by ripping out 100 pages and adding 250 pages considering all the
> new stuff from that keyword soup is going in.
>

I'm not arguing for Hal to change the direction of the book, just
suggesting that focusing on library usage for the sake of those looking
only to ship code is short-sighted.

I thought of The Ruby Way, 1st ed., as a better Ruby cookbook.  It
showed how to do oft-needed tasks, but explained the hows and whys.  If
certain of these tasks are best handled by an existing library, then so
be it.  But the book helped me become a better Ruby programmer, not
merely better-versed in various tool APIs.



> Aren't there "Advanced Ruby" books in japanese that could be
> translated? I've been hoping for a long time someone would translate
> that "Ruby Internals" book and others like it. But all I see is
> another cookbook from O'Reilly and a bunch of Rails books. There's a
> huge market here. I, for example, would buy any book that says
> "Advanced Ruby" on the cover (without even bothering to open the book
> and check out the contents) :-)

I have high expectations for David Black's forthcoming book.  I'd be
hard pressed to name another person I'd like to see a Ruby book from.


James B.

--

http://www.ruby-doc.org       - Ruby Help & Documentation
http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted
http://www.rubystuff.com      - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com     - Playing with Better Toys
http://www.30secondrule.com   - Building Better Tools
James B. (Guest)
on 2005-12-16 01:01
(Received via mailing list)
Phil T. wrote:
>
> that's a great idea.  And perhaps a section in that chapter on creating
> plug-in  architectures.

You know this book will end up longer than TAOCP.

Then we'll all be pestering Hal for volume 4.

James

--

http://www.ruby-doc.org       - Ruby Help & Documentation
http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted
http://www.rubystuff.com      - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com     - Playing with Better Toys
http://www.30secondrule.com   - Building Better Tools
Gavri F. (Guest)
on 2005-12-16 01:16
(Received via mailing list)
On 12/16/05, James B. <removed_email_address@domain.invalid> wrote:
> I have high expectations for David Black's forthcoming book.  I'd be
> hard pressed to name another person I'd like to see a Ruby book from.

The book is called "Ruby for Rails" and the subtitle is "The Ruby you
need to master Rails". David Black is a great candidate to write that
Advanced Ruby book I wish existed, but I don't think it's this one. I
hope I'm wrong though.
unknown (Guest)
on 2005-12-16 04:05
(Received via mailing list)
Hi --

On Fri, 16 Dec 2005, Gavri F. wrote:

> On 12/16/05, James B. <removed_email_address@domain.invalid> wrote:
>> I have high expectations for David Black's forthcoming book.  I'd be
>> hard pressed to name another person I'd like to see a Ruby book from.
>
> The book is called "Ruby for Rails" and the subtitle is "The Ruby you
> need to master Rails". David Black is a great candidate to write that
> Advanced Ruby book I wish existed, but I don't think it's this one. I
> hope I'm wrong though.

Hmmm... that subtitle is actually a bit off: it's "Ruby techniques for
Rails developers" (as per the cover), though I see that it's listed
the way you've got it on at least one website.  I'll put the official
version in my sig :-)

In any case, the book is basically written for the "coming to Ruby
through Rails" constituency, broadly speaking.  It covers some (not
all) of the topics that are coming up on people's table of contents
ideas for advanced Ruby.  I think that's partly because of my belief
that some in things in Ruby, while certainly in a sense advanced, are
more accessible and learnable than their reputations sometimes
suggest.  So, while working from the basics, I don't hesitate to aim
fairly high.


David

--
David A. Black
removed_email_address@domain.invalid

"Ruby for Rails: Ruby techniques for Rails developers",
forthcoming from Manning Publications, April 2006!
Hal F. (Guest)
on 2005-12-16 04:08
(Received via mailing list)
James Edward G. II wrote:
> On Dec 14, 2005, at 10:59 PM, Hal F. wrote:
>
>> That's one reason I want assistance in prioritizing things. In  addition,
>> some of these I know little about, and will have to learn within the
>> next ninety days or so, or just skip them.
>
>
> Can you use the community?  Together we know a fair amount.  ;)

:) That's an understatement.

I'm using the community already. I knew that the announcement itself
would be followed by opinions expressed.

And I'll have questions as I go along. Believe me.

My experience is:
   - Study, and you think you know something.
   - Study harder, and you think are good at it.
   - Use your knowledge, and you learn even more.
   - Teach it, and you will learn still more.
   - Write a book, and you will realize how little
     you really know.


Hal
Hal F. (Guest)
on 2005-12-16 04:14
(Received via mailing list)
Jack C. wrote:
>>
> +1. I'd also be much more interested in pure, advanced Ruby rather than
> specifics of this or that library.

I answered Phil in email, but I'll answer briefly here also.

What you say is compelling, but the fundamental style of the book
isn't going to change that much. There will be some coverage of
advanced techniques (as well as elementary techniques).

There will definitely be material added in the "more advanced"
sections. Some material will be deleted, but mostly because it is
boring, not because it is too elementary.

Coverage of specific libraries will be incomplete, and will occupy
the minority of the book. But this material will still be there.

Sorry if this disappoints. It's a design decision.


Hal
Hal F. (Guest)
on 2005-12-16 04:17
(Received via mailing list)
Gene T. wrote:
>
> "100 pages deleted": does this mean Rb vs. perl/python sections are
> expendable? I can understand, these entail a *lot* of research, &
> recently there's been an explosion of R vs. p/p/java/smalltalk/lisp
> blogs which can be collected on 'Ruby eye for python guy' or some
> wiki.

Probably so. Those were longer than I intended in the first place.
To rewrite them would require time and effort (and help, since my
Perl is weak and my Python weaker).

> The part of Way r.1 that's most valuable to me today is the "Things to
> remember" list on pages 45+

I'm glad it was useful, but <sigh> I dread having to update it.


Hal
Hal F. (Guest)
on 2005-12-16 04:17
(Received via mailing list)
Brian B. wrote:
> I bought your first book.  Loved it.
>
> I'm anxious to see the 100 pages you plan on deleting.  Always good to know
> the things to unlearn too.

;) There's not terribly much to unlearn. Some things that I showed how
to
do are now part of the core (such as hyperbolic trig, base conversions,
etc.).
Other things are just silly or irrelevant. Sometimes there is now a
"better
way" to do things.

To find all the changes, you'd need the old TOC, the new TOC, and a long
rainy Saturday. :)



Hal
Hal F. (Guest)
on 2005-12-16 05:00
(Received via mailing list)
Chris G. wrote:
> model (see Kathy Sierra's blog), inclusion of tutorials, examples,
> exercises...

If you're familiar with the first edition, the basic style and
philosophy will not change.

If you wish, I'll discuss that in more detail later. Or someone
else can offer an opinion as to what "kind" of book it is.


Hal
Hal F. (Guest)
on 2005-12-16 05:03
(Received via mailing list)
Greg D. wrote:
> On 12/15/05, GJB <removed_email_address@domain.invalid> wrote:
>
>>If it's available in early access,
>>I'll buy that too!
>
>
> Is that the plan?  Seemed to work well for the Rails book.  I'd
> definitely buy a beta copy in PDF form (now) for a hard copy final
> edition later.

I don't think the publisher has any plan of such. In fact,
they might hate the very idea. But I will mention it.


Hal
Hal F. (Guest)
on 2005-12-16 05:24
(Received via mailing list)
Luc H. wrote:
> On 15 déc. 05, at 01:34, Jeff W. wrote:
>
>> ... Please be sure to provide it in PDF form... That's how I have my
>> current edition and I really appreciate it.
>
>
> Make that a Pickaxe-2-style-beta-book and I'm signing up right away :)
>

Well, my publisher is not as cool as Dave. :) There won't be a
beta program as such, and the only way you'll get a PDF (that I
know of) is through something like Safari.


Hal
Eero S. (Guest)
on 2005-12-16 05:30
(Received via mailing list)
On 2005.12.16 01:00, James B. <removed_email_address@domain.invalid> wrote:
> A guide to libraries would be handy, but indeed many are ephemeral or in
> flux, and learning a set of distinct APIs for one thing or another is no
> substitute for a proper understanding of Ruby itself.
>
> It's the difference between being a [application|library] scripter and a
> Ruby programmer.

I would say the best approach would be to introduce ruby idioms
using existing libraries as code examples. This would likely
contrast nicely with readers' previous experience.

But Hal knows best, so we shall see what he comes up with :)

> James


E
Hal F. (Guest)
on 2005-12-16 05:54
(Received via mailing list)
James B. wrote:
>
> I have high expectations for David Black's forthcoming book.  I'd be
> hard pressed to name another person I'd like to see a Ruby book from.
>

Agreed! I am eager to get my hands on that. I think it will be a
tremendous asset to the community.


Hal
Chris G. (Guest)
on 2005-12-16 13:28
(Received via mailing list)
Hal F. wrote:

>> There's more to a book than a list of topics. What about depth,
>> starting point, assumptions of reader ability, reference vs
>> learning model (see Kathy Sierra's blog), inclusion of
>> tutorials, examples, exercises...
>
> If you're familiar with the first edition, the basic style and
> philosophy will not change.

So, do you think you got it right? No use going by the feedback
here, limited range of opinion...

--
Chris G.

Bug?  That's not a bug, that's a feature.  -T. John Wendel
Hal F. (Guest)
on 2005-12-16 13:55
(Received via mailing list)
Eero S. wrote:
>
> But Hal knows best, so we shall see what he comes up with :)
>

Haha... thanks for the vote of confidence, but I don't necessarily
know best in this case. I only make informed decisions based on
my own opinions, and keep my fingers crossed...


Hal
Hal F. (Guest)
on 2005-12-16 14:01
(Received via mailing list)
Chris G. wrote:
> Hal F. wrote:
>
>>
>>If you're familiar with the first edition, the basic style and
>>philosophy will not change.
>
> So, do you think you got it right? No use going by the feedback
> here, limited range of opinion...
>

It's a matter of opinion. I mostly achieved my objective, and I
stayed within the parameters I set for the project.

But the ultimate test of whether I got it right is whether people
like the result. And I think that will always be mixed. A book is
a tool, and different people are looking for different tools.


Hal
Hugh S. (Guest)
on 2005-12-16 14:38
(Received via mailing list)
On Fri, 16 Dec 2005, Patrick H. wrote:

> Shifting the focus of the thread a little bit, but what would your
> idea table of contents look like in an Advanced Ruby book?
>
> Off the top of my head randomly ordered:
>
> * Variable Scope
> * Regular Expressions
> * Unit Testing
  * Integration Testing
  * User Interface testing (Web, GUI)
  {
> * Module
> * Class
  }  Probably rolled together =>
  * OO design practices in Ruby (Design pattern 'thumbnails', etc)
> * Metaprogramming
> * Domain Specific Languages
    * including Parsers, XML, YAML, etc
  * Functional, logic, and Aspect oriented programming in Ruby
> * Continuations
    * including Continuation Passing style
> * Threads and Processes
    * Can you pass some of the work to Unix (an OS really geared up
      for threads and procs)? And what to do if you are on VMS,
      Windows, or others.
> * Extensions
> * Embedding Ruby
  * Security, $SAFE in depth, [cryptography, hashing].intro
  * Performance, benchmarking, profiling, and data structure
    selection advice
  * Ruby as a tool to aid ruby development:
     Project automation, version control, ruby within and
     around your favourite editor, documentation (RD, RDoc,
     PDFs, and LaTeX) tools, and what scripting
     might help in the developent process.

Packaged as an electronic book because the paper version would
be too big!
>
> pth
>
        Hugh
Devin M. (Guest)
on 2005-12-16 16:08
(Received via mailing list)
removed_email_address@domain.invalid wrote:

>Hello, all.
>
>
Hi, Hal.

>Keyword soup:
>Java
>
Definitely. And maybe a few words on why it's *Java's* fault, not
Ruby's, that Java's so hard to interop with. :) I get this question a
lot from coworkers.

If I think of anything, I'll send a note. Good luck!

Devin
Sorry if I duped something someone else said... quite a few replies!
Rob . (Guest)
on 2005-12-16 18:54
(Received via mailing list)
removed_email_address@domain.invalid wrote:
> Keyword soup:
> FreeRIDE RDE ArachnoRuby Komodo Eclipse

Hal, we meet last year at RubyConf 2004. You signed my copy of the
Ruby Way book and we talked about Tycho and delicious amongst other
things.

Just wondering what it would take to get the jEdit Ruby Editor Plugin
into your keyword tagsoup? It's currently number one for the search
"ruby editor". ;)

http://jedit.org/ruby/

cheers,
Rob
Bill G. (Guest)
on 2005-12-17 14:42
(Received via mailing list)
On 12/15/05, Hal F. <removed_email_address@domain.invalid> wrote:
>
> I don't think the publisher has any plan of such. In fact,
> they might hate the very idea. But I will mention it.

I'm sure you know all of this, but just the same...

You should point them to the success of AWDWROR [1].  It certainly is
a new/controversial idea, but it seems to be win/win.

Publishers:
They get cash in early, followed by errata submissions before going to
press, so they're final product has a higher quality.  They also get
to market a product at 3 levels, the PDF buyer who can't afford the
book, the average book buyer, and those of us who want both.

Readers:
They get a chance to read it before it goes to press (and many of them
can't afford to wait).  When they finally get their print copy, it's
far more likely to be error free.  On top of that, they get the same
buying options mentioned above -- which gives them the chance to have
a book they can read at the beach, and/or a PDF they can quickly
search while coding.

I know the PragProg guys say there's no such thing as a 'magic bullet'
for programming, but they sure seem to have found one for publishing.

[1] http://www.loudthinking.com/arc/000487.html
pat eyler (Guest)
on 2005-12-17 14:42
(Received via mailing list)
On 12/15/05, Bill G. <removed_email_address@domain.invalid> wrote:
> I'm sure you know all of this, but just the same...
>
> You should point them to the success of AWDWROR [1].  It certainly is
> a new/controversial idea, but it seems to be win/win.
>

It might also be worth pointing out that other programmers are doing
same kind of thing -- Manning for example:
      http://www.manning.com/about/meap


[elided]
James B. (Guest)
on 2005-12-17 14:42
(Received via mailing list)
Bill G. wrote:
..

> I'm sure you know all of this, but just the same...
>
> You should point them to the success of AWDWROR [1].  It certainly is
> a new/controversial idea, but it seems to be win/win.

Some counterpoints for consideration:

* In contrast to offering a free online version (if even only prior to
publication) the pay-to-preview approach means you get fewer eyeballs
and have fewer bug reports & suggestions prior to publication.
Open-to-all improves quality.

* It is indeed great for publishers, because they get consumers to
commit cash early, where waiting for the book to be finished risks
potential buyers opting to spend  their money elsewhere.  First to
market has a big advantage.  But how does the buyer "return" and get a
refund for a PDF download?



James

--

http://www.ruby-doc.org       - Ruby Help & Documentation
http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted
http://www.rubystuff.com      - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com     - Playing with Better Toys
http://www.30secondrule.com   - Building Better Tools
Kev J. (Guest)
on 2005-12-17 14:42
(Received via mailing list)
>
>
> * It is indeed great for publishers, because they get consumers to
> commit cash early, where waiting for the book to be finished risks
> potential buyers opting to spend  their money elsewhere.  First to
> market has a big advantage.  But how does the buyer "return" and get a
> refund for a PDF download?

I think that the problem here is that with digital content of any kind,
the protections that you enjoy as a consumer are usually obsoleted by
the goods being digital.  <totally off topic here>

I can go into a shop and buy a packaged application (for me it'd most
likely be a game, lets say Civ IV as it's new and happening), then a
week later I take it back.  Suddenly the store won't accept it and my
consumer protections that are valid for say a lawnmower or a washing
machine are no longer valid for a computer game.  Obviously I understand
the reasoning as games can (and often are) pirated, so essentially the
shops don't trust their consumers when it comes to digital goods, but
with physical products it's ok

My favourite quote (to finish with this off-topic-ness) comes from Bruce
Schneier -"Making digital files not copyable is like making *water not
wet*"

</totally off topic here>
Bill G. (Guest)
on 2005-12-17 14:42
(Received via mailing list)
On 12/15/05, James B. <removed_email_address@domain.invalid> wrote:
> * In contrast to offering a free online version (if even only prior to
> publication) the pay-to-preview approach means you get fewer eyeballs
> and have fewer bug reports & suggestions prior to publication.
> Open-to-all improves quality.

Without a doubt, it would, but I think it would be a tough sell to
publishers who seem to be convinced that it would reduce future sales.
 Pay-to-preview may mean fewer eyeballs than a free preview, but it's
more eyeballs than no preview (the traditional approach).

> * It is indeed great for publishers, because they get consumers to
> commit cash early, where waiting for the book to be finished risks
> potential buyers opting to spend  their money elsewhere.  First to
> market has a big advantage.  But how does the buyer "return" and get a
> refund for a PDF download?

I don't pretend to have the answer to that one.  Others far smarter
than me have been stumped by it for decades.

Currently, return policies are up to the producer of the content.  As
long as they make that policy known, I can make an informed choice
when I decide whether or not to buy a digital version.

Over the years, I've bought many books, but only a few PDFs.  I
haven't wanted to return any of them.  For now, I'm really not all
that concerned about return policies -- but that's just me.
James B. (Guest)
on 2005-12-17 14:42
(Received via mailing list)
Bill G. wrote:
>>
>  Pay-to-preview may mean fewer eyeballs than a free preview, but it's
> more eyeballs than no preview (the traditional approach).

I've had authors tell me they would never again offer a book for free
online.  Yet others swear by it.  It is not uncommon for O'Reily to
offer current books online for free (as part of their Open Books
project), and Bruce Eckel seems pleased with is results.  APress offers
Practical Common Lisp for free, too.  (Good book!)  And Mark W. is
currently working on a Ruby book that he says will be available as a
free PDF.

It's not that unusual; it is perhaps something of a tradition of its own
in geek publishing.  But, yes, if you are tying to lock down every
dollar, it may be too much of a risk.  It's a business, and people have
to find the model that gets them the results they want.


James


--

http://www.ruby-doc.org       - Ruby Help & Documentation
http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted
http://www.rubystuff.com      - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com     - Playing with Better Toys
http://www.30secondrule.com   - Building Better Tools
Adam S. (Guest)
on 2005-12-17 14:42
(Received via mailing list)
James B. wrote:
>>>> a new/controversial idea, but it seems to be win/win.
>> publishers who seem to be convinced that it would reduce future sales.
>
> It's not that unusual; it is perhaps something of a tradition of its
> own in geek publishing.  But, yes, if you are tying to lock down every
> dollar, it may be too much of a risk.  It's a business, and people
> have to find the model that gets them the results they want.
>
>
> James
>
>
I find that having a print book does several things for me: It lets me
get my eyes away from the screen for a while; it gives me something
productive to do in planes, trains, and automobiles (Passenger seats
only ;-) and it is a nice distraction at times such as during TV
commercials or while sitting on the can (Preferable to staring at the
wall.)

Because of these many advantages I will usually buy a print book if it
is of interest to me even if the same material is available online for
free or reduced cost. Having the material online is an added value,
though, because I can search it more easily when I need a quick answer
at work. Generally, however, I will not pay for an online version,
because I would rather have the print version (And I'm certainly not
going to pay twice for the same content.)
Chad P. (Guest)
on 2005-12-17 14:42
(Received via mailing list)
On Fri, Dec 16, 2005 at 11:12:32PM +0900, Bill G. wrote:
>
> Without a doubt, it would, but I think it would be a tough sell to
> publishers who seem to be convinced that it would reduce future sales.
>  Pay-to-preview may mean fewer eyeballs than a free preview, but it's
> more eyeballs than no preview (the traditional approach).

I tend to think that a reduction in future sales isn't so much what
they're worried about, even if publishers say it is.  Most people with
that kind of decision-making authority at a successful publishing house
are smart enough to see the advertising potential and product
improvement potential in pre-releasing an incomplete or unpolished work,
if you point it out to them and make a halfway decent case for it.  Yes,
there's some risk of reduced sales, but it's miniscule in comparison
with the potential return in increased sales, especially if there is
secific material that will only be available in the paid-for version
still to come.

What it really boils down to, I think, is the common desire to get
dollars from everyone who would be willing to part with them.  The "lost
sales" they worry about likely aren't really any reduction in total
number of sales: handled even semi-competently, you can gain more sales
than you'd lose by doing an electronic pre-release, even for free.  With
current intellectual property laws and expectations in the US, however,
people in IP-related industries just have a problem tolerating the
thought that anyone got to "experience" what they're selling without
paying for it, regardless of whether that actually hurts revenue
streams.

Obviously, there are exceptions, and thank goodness O'Reilly is one of
them.  A personal example of an exception working out in the publisher's
favor is the Pragmatic Programmers' Ruby books: I used wget to download
a copy of the Pickaxe book so that I'd always have it handy whether
online or not.  After reading it, I was inspired to pick up a copy of
their Rails book, for which I shelled out cover price (minus my member
discount at the bookstore).  I'm now planning to pick up the Pickaxe2,
again for cover price (minus the member's discount at the bookstore).

This may not work as well for fiction (for instance), but I'm not really
interested in electronic copies of novels anyway.  It sure as heck works
for technical references, though.

--
Chad P. [ CCD CopyWrite | http://ccd.apotheon.org ]

unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.
This topic is locked and can not be replied to.