Tuesday, December 8, 2009

Me on the TV

It's actually harder to do well in TV interviews than I had expected - definitely harder than newspaper or magazine interviews. The thing is... the reporter would interview you for 2 hours and only take 1 to 3 minutes of it for broadcast. So, if you want to do well, you would have to make sure every single word you utter out in that 2 hours has some impact - and that's really difficult. And on top of that, you need to pronounce every word really clearly - more clear than what you do in everyday conversations - to get a good effect. It's really not easy. Now I'm having a lot more respect for those people who need to appear on TV regularly.

So this is 9th month since Puri! was out - I'm not filthy stinking rich yet, but I've made a good impact already. At least I've transformed myself from a nobody to a very minor somebody :-)

A lot of Hong Kongers still hold a very pessimistic or even a condescending attitude on the tech industry on the whole. So I fully expect a lot of Financial Report/Money Report viewers are looking down on this Martin Kou character as some kind of high tech beggar. Public opinion on the tech industry won't be changing significantly for a while - but, we'll see.

Saturday, September 26, 2009

The really interesting part of Google Wave - Operational Transform

Many people wowed at how Google Wave could display changes by multiple clients in real time. Displaying changes alone, however, is rather trivial - you just need to learn DOM ranges, find some way to make a DOM range adapter on IE (IE sucks, in 2009 it doesn't support DOM ranges you need to write an adapter to emulate that out of TextRange), and off you go.

The real juicy part of Google Wave is how it manages to synchronize multiple simultaneous edits correctly, without using any sort of locking mechanisms. When multiple users are editing the same document on Google Wave at the same time, and users updates and commits come at different times due to network latency - users don't get the SVN-like "you've got a conflict here" message or a Trac-like "the document has been modified since the last update" message. Google Wave doesn't tell its users off to resolve the edit conflicts themselves, while still maintaining correct synchronization between edits. That's the impressive part of Google Wave.

Note that, however, by saying "correct synchronization", I'm only meaning that the users' documents on screen would converge to the same thing in a steady state. It doesn't mean it would always converge to a document that makes sense. What OT means to a lay person is that instead of requiring the human to resolve edit conflicts, the computer would try its best to do it.

So, the really impressive part of Google Wave is actually its conflict resolution mechanism. If we draw out a "time line" of conflict resolution mechanisms used in collaborative software, we can have something like this:
  1. Simple locking - if someone is editing a document, you can't edit it. One example is vim on a multi-user UNIX computer.

    This is not even feasible on the web when you take network latency into account.

  2. Optimistic locking - you can always edit a document. But if there's any conflict, the system will tell you to resolve it yourself.

    The is the most common way of handling edit conflicts on the Internet. MediaWiki, Trac, Bugzilla, SVN, etc. use it. It's usually a good enough solution and is really simple to implement - the simplest way is attaching a revision number.

  3. Operational transformation - you can always edit a document. If there's any conflict, the system resolves it for you and updates you automatically on what it has done.

    This is what Google Wave and Etherpad are doing. Google Wave's version should be much more difficult (or, tedious) because its transform algorithm is running on a tree (i.e. XML) with semantics attached to nodes (because the XML is to be rendered to a human readable document). I'm not sure if Google's engineers have come up with some ingenious idea to make the "semantics attached to nodes" part immaterial to their transform algorithms.. but my personal guess is that the tree + semantics part is making their transform algorithms quite a few times more tedious than simply transforming linear text.
So what has Google done in their magical operational transformation whizzbang? Google has a white paper about it, but as Google always do - they only give you a glancing overview of it. The details are in their code.


Sunday, August 23, 2009

CKEditor 3.0 released!


Me on the newspaper

If you've not seen me, I'm the guy in the white T-shirt.

"Cookies need love... like everything else does"