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...
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.
... 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.
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 Ruby 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.
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
···
On 2005.12.16 01:00, James Britt <james_b@neurogami.com> wrote:
Speaking of which, does anyone know where to get a copy of this
shipped to the U.S.?
Ruby Source Code Complete Explanation:
Amazon.co.jp won't ship it, because it's only sold via Amazon Shops.
--Wilson.
···
On 12/15/05, Gavri Fernandez <gavri.fernandez@gmail.com> wrote:
On 12/15/05, James Britt <james_b@neurogami.com> 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)
In article <e3ecfac70512151053y523c7364ha47b2b79b8985f8d@mail.gmail.com>,
Coding applications in Ruby without taking full advantage of what makes
Ruby Ruby 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)
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.
In article <e3ecfac70512151053y523c7364ha47b2b79b8985f8d@mail.gmail.com>,
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.
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.
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 Britt
···
On 12/15/05, James Britt <james_b@neurogami.com> wrote:
Greg Donald 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.
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.
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 Game
Bug? That's not a bug, that's a feature. -T. John Wendel
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...
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.
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?
···
On 12/16/05, Phil Tomson <ptkwt@aracnet.com> wrote:
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.
···
On 12/16/05, James Britt <james_b@neurogami.com> 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.
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.
I am very appreciative of your comments, but this isn't going to be that book.
I'd be willing to work on that next, though. Collect a list of topics (and I
will too) and I'll submit a proposal for the next book before this one is
even finished.
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?
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.