When I say a book is ready to be published, there are, as far as I know, no errors in it. Actually, that's not true. I'm sure there are errors in it, but I don't know what they are. (If I knew, I'd fix them.) Shortly after publication, the situation changes, because readers tell me about mistakes I didn't know about. The problems might be factual, they might be grammatical, they might be expository (e.g., I might have written something that can be interpreted differently from what I intended). I collect the problems I know about in errata lists, and when my publisher tells me that a new printing is planned, I modify the book to eliminate as many errors as I can. I then deliver fresh camera-ready copy to my publisher.
I write my books with a goal of their remaining useful for at least five years, and there are generally at least one or two reprints each year, so camera-ready copy for one of my books should have to be produced at least 10 times. It's often more than that. More Effective C++, which I wrote in 1996, is now in its 26th printing.
Until the recent release of the PDF versions of my books, my books had been laid out for only a single output device: ink on paper. One book thus yielded one PDF. The ebook PDFs double that to two PDFs per book. For Fastware!, I hope to produce not just an ink-on-paper version, but also multiple electronic versions. To keep these varous versions consistent when I make updates, it's crucial that I have a single master source for each book, and it's also crucial that the various target versions of the book can be automatically built from the single master source. If this sounds like the usual requirement for cross-platform software development, it should, because that's exactly how I think of it.
Subscribe to:
Post Comments (Atom)
2 comments:
Just as a point of reference: For O'Reilly authors writing in DocBook & using our Subversion server, they get a print-quality PDF built every time they invoke a post-commit hook (with a magic string in the commit message). The response from authors (used to writing in Word and not seeing a print-quality, properly typeset version of their manuscript for months) has been outstanding. I think you're right that automatic builds are critical.
Take a look at what Bruce Eckel is doing in Python 3 Patterns & Idioms [1] and Bryan O'Sullivan is doing in the Mercurial book [2]. Both have automated build infrastructure around their books.
[1] http://www.bitbucket.org/BruceEckel/python-3-patterns-idioms/
[2] http://hg.serpentine.com/mercurial/book/
Post a Comment