phpied.com

So I'll be publishing 5 books this year. Isn't that incredible? Is it even possible? And good quality books at that? It's a nice challenge (my last year's challenge failed, I didn't even bother to count how bad it failed). I think it's possible, especially if you bend a little bit the meaning of "5", "year", "publishing" and "me"

Book #1 - High-Performance JavaScript

Let's start bending - this is a book where I wrote just one chapter. It's a book by Nicholas Zakas with contributions from:

• Ross Harmes - Ajax
• Julien Lecomte - deployment
• Steven Levithan - regular expressions
• Matt Sweeney - tools
• me

And I wrote my chapter mainly the last year. My chapter is about the DOM. But the book became available just now, few days ago, so it's published this year (bending, bending...)

Book #2 - JavaScript Patterns

I am hard at work on this one currently (explains the low activity on this blog). I started last year but only finished two chapters in '09. The bending part here is that I've already given presentations on the topic and have been writing a "patterns" column for JSMag for a while, so I can recycle quite a bit of content.

You can see the tentative cover, I hope it stays tentative and we can replace the hen with a nice cute little zebra (a.k.a. donkey with patterns). Between you and me, I think there's a new designer in O'Reilly with a bird fetish.

I expect the first draft for this one to complete within weeks. And no, it's not about implementing the Gang of Four patterns in JavaScript (has been done already by Ross, see above), although there's one chapter on a selected few - Singleton, Factory, Observer, Proxy, Decorator...

Book #3 - Speed Matters

I've contracted with Peachpit Press to write a book about performance targeted mainly at designers. It will be about the business (why go fast), technology (how) and psychology (perception of speed) of web performance. I'm excited about this one for a number of reasons:

• there's a lot of misconceptions being spread around in designer blogs and books, especially sad when one of the books in question is a sort of a bible for web designers. I mean things like PNG vs. GIF, gzipping and others. I hope I can present a readable, concise and, above all, technically correct text for designers who may find Steve Souders' HPWS, a.k.a. "The Bible" a little too dry because it's from O'Reilly and has no colors
• the publisher is considering a sort of novel approach to writing the book, fingers crossed, because I believe it's the right way to write technical books.
• at the very least, the book will be available as early drafts while it's being written, which is new to me, but always wanted to do.
• the book will be full color - again, new experience to me

The bending here comes from the fact that I'll try to reuse from the perf advent calendar if I can. So some content may be pre-written.

Book #4 - Object-Oriented JavaScript (2nd edition)

The bending here is obvious - it's just a second edition, not a completely new book from scratch. My goal here is:

• address errata
• address some excellent critiques (of this otherwise bestselling book!), such as this one by @kangax, which is the article that actually prompted me to pitch a second edition to the publisher. So many thanks to Yuri! Also thanks to Asen who's been sending me invaluable and detailed feedback on the first edition. And now thanks to Asen and Kangax (and also Dmitry) I'm spending some time lurking on comp.lang.javascript mailing list, which is full of great discussions.
• ECMAScript5 update
• some concepts such as hoisting, NFE, property attributes, etc
• one completely new chapter on testing and docs
• answers to the end-of-chapter exercises - an often-requested update

Hoping this title will not take a lot of time.

And since these 4 books should be finished by the end of August or thereabouts, this will give me whole 4 months (1/3 of an year) to dive into something I've been thinking about, two things actually - CSS and self-publishing.

Book #5 - CSS for web devs

CSS is widely misunderstood by many people, me including. I'm convinced we only use a portion of all that CSS is, and use it badly. I'm not saying it will be CSS: The Good Parts, but I plan to address what I consider bad habits in CSS (mis)use and write a book as a learning experience. This is the best way to learn IMO. It will be self-published and probably available online for free too. And by self-publish I don't mean lulu.com or some of the other resellers, but working with the printer and distributor directly.

Too ambitious? April Fool's?

Probably, but with all the pre-written stuff and other cheating, it may very well be doable. Then I guess I'll take a 5 year break

In the spirit of tooting one's own horn....

Top 3

This morning I noticed my OOJS book is #3 in Amazon's JavaScript category, wo-hoo! Then it dropped down but in the evening it's up again. Nice company - OOJS, Doug Crockford's book and David Flanagan's giant Rhino JS book.

Not that I'm obsessed with my Amazon ranking, of course not (yeah, right), but I'm happy when the book sells in the top 25 (first page in the JavaScript bestsellers list). In the good days it's around 10, in exceptionally bad days, drops out of first page. But top 3 - nice!

Nettus.com promo

You can enter to win one of the three free copies of the book over at nettuts.com. Very kind words in the nettuts article and over 500 comments so far! Nettuts is a very cool site, I'd love to be able to contribute an article or two at some point in the future.

Vote for me

My publisher, Packt Publishing, has established an "Author of the Year" award. So help me win that weapon baby and vote for me.

There's a book promotion event this week at the JavaRanch's HTML and JavaScript forum, ranchers are asking all kinds of interesting questions about my OOJS book. There will be a free book giveaway at the end of the week, so come in and join the fun.

Yesterday my post count got from 0 to 15 and today I see that there are even more interesting questions, so it will be a busy night. I'm all armed with a big cup of coffee, Pepsi MAX (twice the caffeine, zero callories, contains aspartame which causes cancer and should be outlawed, but let's live on the edge for now), so off I go!

BTW, I noticed today that my book was #17 in the JavaScript category on Amazon, watch out Doug Crockford and Dave Flanagan!

Finally! The wait is over! After people have already managed to read the book, the chef d'oeuvre that is my Object-Oriented Javascript and some have published 5 star reviews on Amazon, the author finally gets his copies. Oh, happy day! 15 copies, yeey. I don't get to keep them all, because 10 are for my reviewers (since 9 of them are either here in LA of in SF bay area, I wanted to give them their copies and my thanks personally) and one, of course, goes to my parents (my parents are so careful with their copies of my books, they put them in protective transparent covers and so on )

As you probably know, kids often have more fun with the wrapping than the gift itself. My kids are not an exception:

Whew, after a whole year of writing, preparation, edits, blood, sweat, tears, I finished all the latest edits and reviews for my new book, Beginning Object-Oriented JavaScript. It should be out any day now. I can't be happier!

You can pre-order with 10% off from the publisher's site.

When you write something: a book, an article, an email... cut out needless words. The copy after editing should be shorter. Writing is not speaking, it must be tighter. (And, if you find an email is getting longer, just phone the person, he'll never read the email anyway)

I've read somewhere Mark Twain was saying that "very" should always be cut out. I started paying attention to my use of "very" and found that a sentence only wins after I un-very it.

Today I came across this article listing 5 more words to cut out. So here's the list of no-no words, should make any editing process much easier:

• very
• really
• just
• quite
• perhaps/maybe
• that

Check the comments too, there was an interesting insight about words we use to "temper" our speech which we should probably omit when writing, words such as "slightly", "a bit", "somewhat".

And here's another excellent piece on editing I just found:

there is no good writing, only good re-writing

A collection of writing tips here, includes advise from Stephen King, Paul Graham, Scott Adams and others.

In the end, if you want to write well I believe it all boils down to:

1. write - daily
2. edit - cut out needless words
3. read - everything you can lay your hands on

It's so simple and yet we keep looking for the "secret". Same with dieting: all boils down to a/don't eat junk and optionally b/exercise. But we keep looking for the shortcut, the miracle diet that will allow us to "take it off and keep it off" while lying on couch on front of the TV.

A quick function to replace the selected text (in Firefox). Accepts:

• string to replace the selection, or
• callback function that takes the selected text and returns a string to replace the selection

function replaceSelection(t) {
  if (typeof t === 'function') {
    t = t(window.getSelection().toString());
  }
  var range = window.getSelection().getRangeAt(0);
  range.deleteContents();
  range.insertNode(document.createTextNode(t));
}

Usage:

1. Replace selected text with "dude"
replaceSelection('dude');
2. Uppercase the selected text
replaceSelection(function(s){return s.toUpperCase()});
3. Lowercase the selected text
replaceSelection(function(s){return s.toLowerCase()});

Luckily I'm so close (and yet so far) to finishing this book, otherwise I won't be able to help myself but create a whole toolbar of bookmarklets for "power" Google doc users...

Tip #1 for writing better code - edit. With this book I write, I find I'm spending more time editing than writing. The first draft is usually bad. The first draft "works" in the sense that it covers the material, but not necessarily in the best possible way.

Same thing with writing code, it's one thing to have the code working and it's a separate thing to have the code easy to understand, efficient, maintainable, expandable. When you're working on a problem, sometimes you just try different things. One of them works. It's your job not to stop there but to edit this first draft. Don't commit first drafts.

There will be junk. It's up to you to make sure that junk doesn't find its way to the final product, only because "it works". It may work now, but how about tomorrow. Is your code fit for print?

Something has been annoying me for some time as I write this book in Google Docs: I want to be able to format text as code (Courier New) only using the keyboard. So I came up with this bookmarklet. It's one of those "works for me" so if it doesn't work for you feel free to modify and post here your version.

Code

Basically I attach an event (FF way, so won't work in IE) that listens to the keyboard combination ALT+x and then calls the appropriate editor command:

javascript:(
function(){
  window.frames[1].document.addEventListener(
    'keypress',
    function(e){
      if (e.altKey && e.charCode === 120){
        EditorCommand('fontname', 'Courier New'); 
        return false;
      }
    },
    false);
}
)()

Download

Right-click, bookmark:

Alt+X

So close to being finished with 5 chapters and 1 appendix of the new book (hey, that's 50%+) and just after the n-th edit of chapter 3, I thought I might share this picture I have on my desk. It's an self-portrait of my 4yrs old daughter Zlatina, in front of a window. Once this book is out of the way, she's so getting her own blog

David Barnes, who works for my publisher Packt Publishing, has started a blog: "How to write computer books". Great stuff in there. If you write or intend to write a book, a blog or anything technical, it's a great addition to your RSS reader.

Inspired by this quote from Mark Twain, yesterday I went through the draft of chapter 3 of my new book and searched for all instances of the word "very". Then deleted most of them. Probably should've deleted 'em all, but I couldn't help myself. It's tough. Very.

Anyway, especially since "creating passionate users" is no longer updated, David's new blog is good news.

On a similar note, here are the slides from a presentation called "Writing engaging tutorials" by my fellow Yahoo, Christian Heilmann.

I've never been into crime fiction. I mean I've read The Hound of the Baskervilles, but that's about it. I like Douglas Adams, Terry Pratchett, looove Kurt Vonnegut, enjoyed On the Road, Catch-22... So it came as a surprise even to me when I started reading Raymond Chandler and actually enjoying it. The thing is I love to learn about the places I visit - culture, people, history, geography. Living and curious about LA now, I came across an article saying that Chandler wrote quite a few things about LA and California that stuck around. Anyway, I picked up a volume, read The Long Goodbye and loved it.

Just read an article about Chandler's writing process. Since I just started working on my new book, I found the article pretty interesting. The "normal" editing process I think is: you write a draft, you review it and scratch some parts, maybe replacing them with others, adding, removing. Chandler did the opposite - he underlined only the words that will stay in the next draft, everything else is to be rewritten or simply gone. This way he could tighten his sentences if not cut them in half. I like that a lot. Short is good, short is often clearer. It's so easy to be verbose, hoping this will clarify whatever you want to say. But often it isn't. I believe Mark Twain said something like "I would have written you a shorter letter, but I don't have the time"

That makes me think - it's so bad that most computer books today don't aim for brevity, but for volume instead. I've heard authors saying that their publishers love to ship big ass books on the market, because supposedly readers want big books. If it's big, there must be good stuff in there. Luckily my publisher is not like this, of course Although they would probably also agree that the overhead of publishing a 100 pages book is pretty much the same as a 1000 pages book. A tiny book still needs to go through the same process as the big one. So why not ship a bigger volume that will look more impressive. Imagine the dialog:

- Honey, how do you want to decorate this room?
- Hmm, I'd love to have a shelf of Java books right there, about four feet long. Yes, and right below it, gimme some design patterns and some .NET, half and half. Fabulous!