Amidst all the great comments on the book here at TPC, I was alerted that someone bashed the book here.
So, of course, I had to look and respond :) Not only because that is my personality but because
I tend to find bad reviews (about many books, not just mine since there have only
been two, and this is one) based from people who basically the book isn't for. Anyways, on with the show...
It looks like a nice thick book, but it's very padded; this verges on dishonesty, IMHO. The font is
huge (12 to 14 points), there's a lot of padding (most code samples listed twice, 40 pages of
appendix material that could have been 8 URLs), the margins are huge, and there's an awful lot of
repetition (the 10 lines justifying -wT are repeated nearly every time it's used in a program).
Well, I can't comment on your taste of fonts, that is too subjective.
When code samples are listed twice (which you didn't give any example of this, and I
can't think of any which were) it would have been done for clarity. Sure,
the appendix could be a list of 8 URLs, but then again, almost any book on
Perl (c, Python, etc..) could be one page saying RTFM. Appendicies are meant for
reference mateials. So, while reading (or whenever) you can quickly look some things
up instead of needing to get on the web to look at a URL, and maybe have to print it. As well,
it shows what was current when the book was written. Things on URLs may not be the same as
you find in a book. So, you need the context. The bits repeated on using -wT are repeated
a lot, why? Because it is important. If someone learns nothing from the book but to
use -wT in CGI, then the book served a purpose. Sometimes, people need to see things
many times before they remember and understand it.
Some chapters belong better in a Perl book ("Tied Variables").
Um... it is a Perl book. Refer to the title. Of course,
if we didn't cover tied variables, and just used them, then people would complain
that we didn't cover this topic (which many people don't know about).
Some inclusions/exclusions and focus choices are very odd. There's a very detailed chapter for
Mason, but no mention of templates (literally - not even in the index).
Because it covered Mason, not templates. There are too many templating systems and, IMO, if you
cover one, you need to cover them all. If there is a 2nd Ed. I do want to cover TT.
Their style is very choppy. They'll present a couple lines of code, then a paragraph talking about it,
repeat. It's very difficult to get a cohesive view of the program this way - it's spoon-fed to you
rather than presented whole.
When you have a 100+ line program, it is quite hard (and ugly) to list all the code
then explain it. An explination of code which was shown 5 pages before isn't very
friendly, or helpful. If you want to see the full code, you look at the end of the
chapter in the section titled Listings. One of the points of the book was to explain what
was happening in digestable chunks. So, you have to spoon feed large scripts if you
want to actually encourage learning.
The cover's odd. What are we supposed to call it, "The Spiky Ball book?" ;)
Actually, some people call it that. It has no name, and is mostly refered to as 'the book
with that cover', or the M&M book.
rest of comments not quoted
Actually, I think you have it backwards. I think the Mouse book and this book
are good compliments of one another. I (and most I speak with) find the book to be
educational, then vocational. It teaches many concepts (of CGI, DBI, graphics,
Perl, etc...) Then, once you learn, you can refer to it.
I bet that the Mouse book squeezes twice
as much content into 450 pages as Spiky Ball does in 525.
If you are to blurt something like this out, please back it up, or remove it.
As a (new) author, I find that when people simply spew out comments like this, it doesn't
help anyone. What does the Mouse cover that we don't? What do they cover in more depth?
What do we cover they don't? What do we cover in more depth? Do the books seem
to go after different audiences? Do they compliment eachother?
You say you wouldn't recommend this to anyone, but really haven't given any good (IMO),
reason as to why. Because you don't like the font? Because we repeat important concepts like
tainting and warnings? Because we cover Mason and not templates? Because we give code
in digestable amounts, and then give detailed explinations of that code?
Because you don't know what is one the cover? These really aren't good reasons. Good reasons would be:
we got things wrong, the code is bad, it is unsafe, we don't cover important and
interesting topics (which we do, DBI, XML, POP, graphic manipulation, cookies,
embedded Perl, security, etc...) Maybe the book simply isn't for you, but that doesn't mean
it isn't good for someone else and you should really consider if your reasoning to not recommend (especially
in a public arena like this) is valid. If you have some valid gripes, send email to us so we can
take them into account for future printing/editions. If you do not, and you simply didn't enjoy
or 'get' the book, keep in mind that others may.
Cheers,
KM