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.

http://www.waveprotocol.org/whitepapers/operational-transform

CKEditor 3.0 released!

http://www.ckeditor.com/

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"

FCKeditor is looking for 2 experienced JavaScript developers in Hong Kong and China

I've posted this to quite a few places so far, but got no responses. Most probably due to the rather specific and high requirements. So, here's the job, we have two vacancies for people in Hong Kong or greater China:

Company	FCKeditor
Job Title	Advanced JavaScript Developer
Type	Full Time, Remote Work
Requirements	Basic requirements: Experience in JavaScript programming (e.g. knowledge of object oriented and functional programming styles in JavaScript); In-depth knowledge of basic web standards, like XHTML, CSS and DOM, including their intrinsic implementation differences among browsers; Fluent in spoken and written English. Good to have (but not strictly required): Server side programming experience with Java and Ruby on Rails; Experience with FCKeditor; A Bachelor's or Master's degree in Computer Science (or related subjects); Knowledge of open source, and eventually love it :)
Benefits	Work at home - no need to spend time commuting each day; 5-day work week and paid annual leaves; Can enjoy Hong Kong (or China) general public holidays; Excellent exposure to the international information technology industry.
Salary	Depends on ability and experience. 20k+ HKD per month for experienced JavaScript programmers.

So there you have it. It's a really good opportunity for the enterprising geeks to break out of the local tech job market.

If you're interested in the job, please send an email with your CV to jobs@fckeditor.net and cc a copy to martin@fckeditor.net. If you'd like to talk with me before applying, my Skype id is martin_kou. If you're currently studying in or working in HKUST, I can even come to meet you in person.

The irony of it all

Not only do computers screw up trying to understand human language - whoever wrote this transcript to the lecture also screwed up a little bit... or maybe he's too much into graph theory.

Yet another boost to JavaScript execution performance - Squirrelfish Extreme

In the past month we've had Mozilla's Tracemonkey and Google Chrome's V8. Today the WebKit team joined the fight with Squirrelfish Extreme, and this fish packs quite a punch.

According to the benchmarks done by Charles Ying, Squirrelfish Extreme is currently the fastest JavaScript engine out there - 54% faster than Tracemonkey and 36% faster than V8 in the SunSpider benchmark.

Not a single word about fast JavaScript engines was mentioned on IEBlog. It seems IE8 is going to hold back the world of web applications for another few years, unfortunately.

BarCampHK 2008

Images from laihiu's Flickr

Amazing.

It was my second time to a tech conference and the first time I spoke in a session, and quite a few people actually came in and listened to me. Seeing how well the others were doing in other sessions, my presentation skills could definitely use some improvement. Still, I was really happy to see a few audience members have already tried FCKeditor in Drupal and found it to be stable.

I also met quite a few old friends in the conference - my former FYP advisor Dr. Dekai Wu; Yusuf from Outblaze (I had a really hard time telling he was talking about Tracemonkey/Firefox3.1 and FCKeditor to me though, apparently I had a buzzword overflow problem in my brain); Edwin Chu (from secondary school) who's founding a startup right now; Eric Tang (also from my secondary school) who founded HKSUA. It seems my secondary school, QES has been making quite a few tech entrepreneurs in these years, and one of them (Dr. Alan Tam) is already quite successful. Did that entrepreneurship spirit form because... we didn't hand in our homeworks? :P

The other sessions I attended were:

1. Design UI from Anobii
   Anobii's speaker advocated that UI design should be started from hand-coding the HTML, and discouraged the audience from starting web UI design from Photoshop or Dreamweaver's WYSIWYG interface. Dreamweaver's WYSIWYG part sucks of course. But Photoshop? His reason was... not everything you can realize in Photoshop can be realized in HTML/JS/CSS as well. So, if you have a graphics designer working the UI from Photoshop first and then hand it to the web developers, you'll inevitably need a lot of "reconciling" between the web developers and the graphics designers in the form of meetings, arguments, infightings, smashed keyboards... and thus, wasted time.
   
   I have a counter argument to his point, though. No matter how you put it, it is still much easier to create and visualize a beautiful UI layout in Photoshop than in HTML/CSS. e.g. it is much easier to create and adjust a drop shadow, or a border around a round button, in Photoshop. So, I'd wager that there's good possibility that someone who started from hand coded HTML/CSS would need extra time to fine tune his layout after he coded his initial revision. A Photoshopper who already has experience in HTML/JS/CSS, however, would be able to draw and fine tune his layout easily, while making sure that it can be implemented.
   
   The difficulty in my scenario, would be finding the Photoshopper who's skilled in HTML/JS/CSS (or, just HTML/CSS) as well. But you don't really need a Photoshop expert to draw up a good looking UI.
   
   
2. Technology Yesterday "Relevance"
   
   Images from 黛's Flickr
   
   A surprisingly good presentation from a psychologist. The speaker didn't spend much time talking about old technology actually. The whole session was more like a discussion forum on information technology's effect on the society, and its effects to the younger generations (i.e. Gen-Y-ers and the generation after Gen-Y-ers) who grew up with computers.
   
   I can imagine the recent victory of LSD (League of Social Democrats) would be a hot topic in such a forum - had it been hosted two days later - seeing the LSD is currently being supported by a lot of young Internet users. The victory of the LSD is a formal announcement to the importance of the Internet in Hong Kong's political arena - most of the promotions for the LSD were done on the Internet, via Yuk Man's YouTube videos or MyRadio.com.hk. Most of the time Yuk Man didn't even have to take part in such promotions - he spoke something interesting somewhere, one of his audience members recorded down a video of him and uploaded that to YouTube. And, bang! A lot of people saw Yuk Man's speech and rebuttals and were blown away by his impressive oratory skills. A textbook example of how viral marketing works.
   
   A lot of interesting Internet-based promotions in the next Legco election (2012) can be expected, I think. Those who refuse to face reality and adapt, will lose the election game, sooner or later.
   
   
3. Converging Desktop and Web Application
   This is again, a discussion forum. Topics included the usual suspects - Google Chrome, WorkerPool API in Google Gears, JIT JavaScript engines, client side storage via DOM Storage API or SQLite, Flash and Silverlight, etc. I was quite surprised by the technical know-how of the audience there. But other than that, no surprises.
   
   
4. Open Source + Microsoft
   
   The topic sounded interesting but I sat so far back in the conference room I couldn't tell what Microsoft's speaker was talking about most of the time. I could hear his point about why Microsoft is entering the open source scene though - there's money to be earned in open source software, entering the scene is just good business practice. There's no conspiracy, and thus open sourcers shouldn't be suspicious of Microsoft's motives.
   
   Well, but that's not gonna change my attitude towards Microsoft. How about fixing IE's standards support to begin with - not just XHTML and CSS, but also ECMAScript (aka JavaScript, e.g. where is Array::lastIndexOf() in IE?!), DOM Selection, DOM Range, XPath, DOM Parser, <canvas>, SVG, MathML, etc. Client side programming in IE sucks so much right now it's like programming with one hand tied to the back of your chair while your other hand has two fingers chopped off. I don't really hate everything that is closed source you know... I don't hate Opera for example. The thing that ticks me off with Microsoft isn't closed source, but incompetence.
   
   
5. Drupal
   I didn't attend the whole session because I spent some time talking to Dekai about MathML and FCKeditor after my session. The presenter is a really friendly guy though, and they founded a local Drupal user group right after the session.

Need to sleep now. I'll talk about my session tomorrow or this weekend.