What a funny bugger writing is, eh? Each series of books we at ORA have has a different vibe--a Learning book is different from a Programming book is different from a Nutshell. In dealing with "Programming PHP", I learned how a Programming book works--I know the rhythms and explanatory techniques that make it tick. That's already helping me as I edit the LWP book, which is a lot like a Programming book.
I've been hassling Tim, trying to work out how the Power Tools books work. Unix Power Tools was fabulously and unbelievably successful and popular, and when a book resonates like that you're stupid not to try to figure out why and duplicate the good points in future books.
It's particularly important to me because I'm the de facto Cookbook King at ORA. Having created the format and cowritten the first Cookbook with that format, I know how it works and why. I've even written "Cookbooks in a Nutshell", a couple of pages on how to do a Cookbook that works.
The Power Tools format is similar to a Cookbook format. Both break a topic into little chunks, but the Cookbook's chunks are very ordered and structured while the Power Tools chunks are very scattered and free-form. My first reaction to reading UPT was to recoil in horror at the chaos of it all! Learning more about Power Tools, though, I'm slowly growing to respect it. Slowly :-)
I think the lesson I'm taking away is that the Power Tools format works for userland stuff (shell management and so on) whereas Cookbooks work for programming stuff (hashes, regexps, etc.). I wouldn't want to write "LWP Power Tools", but nor would I want to write a "Windows 2000 Cookbook".
When I started editing, I didn't realize that there was this great variety in formats. I figured that if I could edit an article for TPJ, I could edit a book--the only difference is that the book is longer. Nope! The tone and style of an article often becomes condescending or frustratingly slow when maintained for the course of a book. The problems of a book, even when they're the same problems as an article, are often harder to solve. For example: when to describe a topic the reader needs to know about, and when simply to refer them to an external source. In one book I'm editing, I still don't know yet whether we should be giving an introduction to XSLT or just assuming the reader has eyes and can buy a book on XSLT if they don't know.
But while there's been a learning curve, I love it. I enjoy learning the hidden patterns and rhythms of things, whether it's a conference, a musical solo, or a book. The learning is often hard, but the results are rewarding. When I was young, I had a diary with motivational quotes, and one of the two that stuck with me was "experience is a hard teacher, but fools will have no other." Experience has kicked my ass, but I've been learning from it.
The other quote from that diary was "he knew not what to say, so he swore", but I hope that's not very relevant to my editing career!
--Nat
I'm increasingly starting to love the "Essentials" style books (especially as someone that will probably have to be doing some C# soon). They work much better for my brain patterns.
But I guess you can't use the Essentials approach for any topic. And if one of the books you're working on touches on something that requires XSLT knowledge, then XSLT should probably be explained (at least in a long appendix) because it is not a technique which many people are yet used to.
Just my €0.02...
Re:Essentials
gnat on 2002-03-03T01:33:54
I haven't done an Essentials book yet, so I haven't had an excuse to work out what makes one tick. What do you like about them in particular? Short? Doesn't go into excruciating detail? Autostereogram covers that look like giant dongs when you stare at them cross-eyed?--Nat
Re:Essentials
darobin on 2002-03-03T14:31:23
I think that what I like about them is that they are halfways between a tutorial (explaining everything step by step) and a reference. Tutorials pretty much never worked for me as it would seem I never want to learn things in the provided order (the Learning books never worked on me). References are more my style (eg I found it easier to learn XSLT using the spec and after that XML in a nutshell than by using Mike Kay's book) but it's harder to find a good place to start and the first steps are steep.
The Essentials seem to make a good mix of both. Say I wanted to learn SVG, I could easily start with the section on text, then jump to filters, then paths, and then only basic shapes if that's the order I felt comfortable learning them in. This wouldn't work in a longer book, and would be a lot harder in a reference.
Of course, the only thing I ever edited were plays so a lot of this is hand waiving
:) But I hope I get the idea accross.
Re:"Advanced" books?
gnat on 2002-03-03T19:34:40
There isn't really a formula for the "Advanced" books. I agree that APP is a mixed bag--it was good when it was released, but data structures and minimal matching are no longer considered advanced topics. We've been tossing around ideas for a second edition, but finding the right combination of topics and authors is tricky. If anyone has topic suggestions, feel free to post them here or email me <gnat@oreilly.com>--Nat
Re:"Advanced" books?
djberg96 on 2002-03-03T20:55:30
2nd EditionThings I would remove:
1) Tk (Chapters 14,15,16). Not really an "advanced" topic IMO, simply a different topic, mainly because it has more to do with Tk than with Perl. Besides, ORA has two books out on it now.
2) Data structures (Chapter 2). Like you said, not really advanced any more.
3) Modules (Chapter 6). I think it's covered well enough in the 3rd edition Camel now.
Things I would update
1) RPC (Chapter 13). This one was probably hard for the author, given that there doesn't appear to be any truly tested RPC modules out there (though I plan on writing a hard core RPC module soon). He also violates one of my golden rules of computer books in this chapter - using something in sample code before explaining it. In his case, it was the home-grown RPC.pm he writes.
Things I would add
1) XML processing. Times have changed since that book first came out, and I think this is one of the more modern topics that should be covered.
2) Inline. I think this would complement chapter 18 well.
3) Signal handling. Especially focus on __WARN__ and __DIE__, as well as problems using them in conjunction with "eval". Perhaps this should come immediately after Chapter 5. Also consider talking about *CORE::GLOBAL::die (and 'warn').
Well, there's my 2 cents. I'm curious to know what you (and others) think of my suggestions.
Re:"Advanced" books?
darobin on 2002-03-04T13:14:19
On the whole I agree with your suggestions. The chapter on modules could stay but it would need to be more advanced (ie addressed to people that already have a good working knowledge of modules), and I'd say the same about the next chapter (7) on OO which could be merged with chapter 8 (also on OO) and be on the whole more advanced (especially since we have Damian's OO Perl).
The chapter on RPC could indeed use some updating, and should have parts on XML-RPC and SOAP.
Strangely enough, I'm a bit more reserved (not on the fact that it should be in, but on the actual content) on XML processing. Is the community/Perl market ready for truly advanced XML stuff? If not one might wind up throwing in one or two chapters that might seem advanced to most today (because of the relative newness, not because of the complexity), but that will be outdated next year when most people are up to speed with XML (similar to the Tk chapters). I guess that taking the risk of making some parts of the book a touch too hard for today's audience might provide it with longer-lasting usefulness though.
