Posted by editor
on April 7, 2005 at 6:12 AM PDT
A round-up of things learned from having just finished my second book, "Swing Hacks"
Joshy and I have just sent the final copy for Swing Hacks to the editor, along with over 200 screenshots to the production department (yeah, they're going to love us). After a reasonable but non-trivial amount of time, it'll be available at your favorite bookstore or online bookshelf .
This was my second book (the first is about QuickTime for Java ), and my first with a co-author. Important lessons learned from both experiences:
- Subversion rocks -Granted, Joshy covered this earlier . For sharing and revisioning code, it's truly awesome. We used subversion both for the code examples and for the book contents (the write-ups and screenshots). This was an easy way to share and manage stuff between the two of us, far more practical than e-mail could ever have been (imagine juggling source, images, write-ups, etc. for each of 100 hacks). When two contributors (hi Jonathan; hi Romain) came on the project part-way through, it was easy to get them caught up by having them do a
svn checkout. In fact, when I dropped into VirtualPC to test my hacks on Windows and make any adjustments, I would just use a separately checked-out repository there, committing back any changes coded on that side. The only thing I can truly say I dislike about subversion is that setting a property to ignore class files is nowhere near as easy or as memorable as just doing
cvs ignore *.class
- I should have made an ant build file sooner - On the QTJ book, I set up an ant build file early in the process, and every example in the book can be compiled and run with a single ant call like
ant run-ch03-undoableqteditor. It's a hassle up front, but it pays off. We didn't do that work up front on Swing Hacks, so I have to go back and do it now so the downloadable code will be ready for everyone to use when the book's ready.
- Find just the right amount of experimentation to do, and budget accordingly - Generally, inventors of a technology don't write the defining book on it, though there are exceptions (such as O'Reilly's perl , Ruby , and Subversion books). So, the author usually has some amount of learning to do in the writing process, and even a little experimentation. You want to get some things in that nobody's done before (or at least nobody's posted in a place where Google can find it). Thing is, if your whole book is like this, it will take 10 years to write. And if you never do this, the book can have a "nothing new" feel to it. So on Swing Hacks, Joshy and I did put some stuff in the proposal where we said "we haven't done this before, but we really think it's doable". And those were good to figure out and get in there. But they can't all be like that.
- Read your co-authors work early - Joshy and I have different code-quoting styles, and we only realized late in the game that they looked strange when they were in the same chapter. I ended up changing a lot of my long listings to a more broken-into-pieces style to match. By the way, do people still type in programs from books by hand? We've really tried hard to make sure this is still possible, though it is obviously far preferable to download a book's code from its supporting website.
Hopefully, you'll like the book. We learned a lot from each other and from our contributors as we were writing it.