TDG Update

Screen shot of my PDF viewer with TDG’s titlebar

I just hit 300 pages! (O’Reilly has a nice system where it automatically compiles my XML into a PDF, so I can obsessively check page count). The last edition topped out at just over 200 pages, which was nice: you could actually sit down and read the thing in a reasonable amount of time and not have your lap fall asleep.

I don’t think this edition is going to be small enough to do that because MongoDB itself has gotten bigger. I couldn’t cover all of the things a developer needs to know in less than, well, 300 pages (and I’m not even close to done). I feel like Mike and I did a good job covering MongoDB two years ago (I’ve had to change almost nothing in the first few chapters), but it’s just a larger product now.

Finally, thank you to everyone that sent me schemas! I got a lot bigger response than I expected and I’m running way behind on getting back to people, so I’m sorry if I haven’t emailed you back yet! However, I really appreciate all of your contributions.

Scaling, scaling everywhere

Interested in learning more about scaling MongoDB? Pick up September’s issue of PHP|Architect magazine, the database issue! I wrote an article on scaling your MongoDB database: how to choose good indexes, help handle load using replication, and set up sharding correctly (it’s not PHP-specific).

If you prefer multimedia, I also did an O’Reilly webcast on scaling MongoDB, which you can watch below:

Unfortunately, I had some weird lag problems throughout and at the end it totally cut my audio, so I didn’t get to all of the questions. I asked the O’Reilly people to send me the unanswered questions, so I’ll post the answers as soon as they do (or you can post it again in the comments below).

Writing MongoDB: The Definitive Guide

Me, with the finished product
MongoDB: The Definitive Guide is now available in bookstores everywhere! (Or at least on Amazon.) Please pick up a copy!

Some interesting things I learned about the process of publishing:

There are professional indexers who write the index.
This amazes me, because we had to proofread our index and I’ve never been so bored in my life. These people must have the exact opposite personality I do. And, in our case, they spelled “Ruby gems” as “Ruby germs.”
Blog posts are a better length
In 500 words, I can edit and polish something until it’s a shimmering jewel of a, uh, blog post. It’s really hard to make a hundred thousand words even have a reasonable flow, never mind be “perfect.”
Illustrations will be assimilated.
When we submitted the manuscript, I had (the night before) whipped up the illustrations in Photoshop that looked like this:

Every document is a beautiful snowflake (because they're all unique)

At the final stage of the editing process, these all got replaced by O’Reilly illustrations, which looked a lot more professional.

Well la-dee-da.

I’m pretty impressed by how well they matched what I was going for, but wish I hadn’t spent so long making those damn snowflakes.

An advance is an advance on sales.

In retrospect, I should have realized this, but I never really thought about it before. If O’Reilly advanced us $100,000 (they didn’t), that just means we wouldn’t get any royalty checks until people bought enough books to give us $100k in royalties. So, essentially, authors write books for free. This kind of amazes me.

All and all, it was really fun and I’d do it again in a heartbeat. In the future, I wouldn’t stick to the schedule quite as rigorously. At the beginning, O’Reilly gave us the following timeline:

  • 3 months = 2 chapters
  • 6 months = first half
  • 9 months = whole book

I write best when I splorch down everything that comes to me as fast as possible and then edit it fifty times. So next time I’d do:

  • 3 months = book of crap
  • 6 months = semi-literate book
  • 9 months = great American (technical) novel.

Andrew suggested we do the National Novel Writing Month, so now I’m trying to think of another thing to write about. I’ll probably do a MongoDB book, but not sure what yet…