Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

gnat (29)

gnat
  (email not shown publicly)

Journal of gnat (29)

Saturday March 02, 2002
04:46 AM

Litrachur

[ #3241 ]
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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...

    --

    -- Robin Berjon [berjon.com]

    • 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

      • 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.

        --

        -- Robin Berjon [berjon.com]

  • How do you feel about "Advanced" programming books? I have the "Advanced Perl Programming" book and I have to say I have mixed feelings about it - it really depends on the chapter.
    • 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

      • 2nd Edition

        Things 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 app

        • 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 bi

          --

          -- Robin Berjon [berjon.com]