Final release date will be some time in the spring. Until then we'll be doing regular electronic releases. I'd love to get your feedback so I can work it into those releases and the final book.
Is there a way to be updated on the progress of the book?
On a related note - I am really loving OReilly's approach to this book. I have found that I usually end up buying the book despite it being freely available on the web. Great work, looking forward to more.
People told me the same thing about my Catalyst book. "Things are changing too quickly, don't write a book."
If you don't write a book now, though, people are just going to use some other technology, and then you'll never have a chance to build a community of library-writers. The solution is to write a book now, then write another book when things are more stable! Early adopters shouldn't have to dive through the source code and ask questions on IRC; they should be able to read, learn, and begin contributing. Most people don't like being confused and scared when evaluating a new technology or programming technique; they need someone to hold their hand.
Incidentally, I was also told my book would not sell, but it sold thousands of copies despite various typographical (and technical, arguably) errors.
Don't not write a book because someone on the Internet told you it wouldn't sell or it would be outdated too quickly.
If you actually looked at the book you'd see that the significant part of it is looking concepts. For example: why event driven programming is interesting, the architectural decisions that make Node the way it is, programming style for server-side JavaScript with the event loop, etc.
For the APIs I'm taking two approaches, one is looking at the more stable APIs (e.g. http) and showing how to use them at a high level, with a lot of examples and breakdown of best practice. The other is an API listing which will be taken from the core API docs which I'll be helping to improve. That second direct API reference is the one most at risk.
To mitigate that I'm using a build script which builds from the current documentation in markdown on Github. That means the ebook releases and updates will use the very latest version of the book. It's possible we might consider using a print on demand model for the physical book which means that the copies on shelves will be as far from out of date as possible.
More than that, I'm pretty connected to the Node community, so I'll be aware of any huge changes coming up and be able to work around those for the final print version of the book. Ebooks are easier to update in time to take into account changes.
"... Bad idea. NodeJS is too young to take a hardcopy picture of the APIs. It'll be outdated before its release. ..."
I don't think printing a book is a bad idea. After having a quick scan of the download & when I see "all I/O activities should be non-blocking" in Ch3 I already see value (think about the consequences in trying to use mysql drivers).
While the book might be out of date it's the concepts & ideas behind that might be valuable to "old" n00bs who might have dabbled in JavaScript and heard about Nodejs from their hacker mates. Youngsters would probably turn their nose at books & simply head to the web as you suggest :)
There is still a place for offline hardcopies to exist parallel to the online docs.
13 comments
[ 3.9 ms ] story [ 38.9 ms ] threadOn a related note - I am really loving OReilly's approach to this book. I have found that I usually end up buying the book despite it being freely available on the web. Great work, looking forward to more.
I'll throw up a site soon dedicated to this. Thanks for the suggestion. I'll announce that on my Twitter feed ;)
http://visionmedia.github.com/masteringnode/
Edit: oh! good points below me!
If you don't write a book now, though, people are just going to use some other technology, and then you'll never have a chance to build a community of library-writers. The solution is to write a book now, then write another book when things are more stable! Early adopters shouldn't have to dive through the source code and ask questions on IRC; they should be able to read, learn, and begin contributing. Most people don't like being confused and scared when evaluating a new technology or programming technique; they need someone to hold their hand.
Incidentally, I was also told my book would not sell, but it sold thousands of copies despite various typographical (and technical, arguably) errors.
Don't not write a book because someone on the Internet told you it wouldn't sell or it would be outdated too quickly.
For the APIs I'm taking two approaches, one is looking at the more stable APIs (e.g. http) and showing how to use them at a high level, with a lot of examples and breakdown of best practice. The other is an API listing which will be taken from the core API docs which I'll be helping to improve. That second direct API reference is the one most at risk.
To mitigate that I'm using a build script which builds from the current documentation in markdown on Github. That means the ebook releases and updates will use the very latest version of the book. It's possible we might consider using a print on demand model for the physical book which means that the copies on shelves will be as far from out of date as possible.
More than that, I'm pretty connected to the Node community, so I'll be aware of any huge changes coming up and be able to work around those for the final print version of the book. Ebooks are easier to update in time to take into account changes.
I don't think printing a book is a bad idea. After having a quick scan of the download & when I see "all I/O activities should be non-blocking" in Ch3 I already see value (think about the consequences in trying to use mysql drivers).
While the book might be out of date it's the concepts & ideas behind that might be valuable to "old" n00bs who might have dabbled in JavaScript and heard about Nodejs from their hacker mates. Youngsters would probably turn their nose at books & simply head to the web as you suggest :)
There is still a place for offline hardcopies to exist parallel to the online docs.