Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

Whoa.

Via Dion, Palm's new Mojo framework for the Pre is based on Dojo!

As far as I know, it was a total surprise to the Dojo community (myself included). I can't wait to get started writing apps for this thing and see what device APIs Palm has surfaced.

OSCON 2009 Call For Papers Is Open!

I'm a bit tardy on this, but the OSCON 2009 Call For Papers is now open.

In the past couple of years the shift from desktop-centric to a more web-centric OSCON has continued to make the conference useful and engaging, and great work on topics like JavaScript/Ajax performance, Dojo, Comet, and many of the emerging back-end bits of infrastructure that make it all go have made my yearly trip to Portland worthwhile.

Great talks have gotten lost from the JavaScript/web track in years past because they've missed the submission deadline, so if you're hacking on something fascinating, now's the time to get that proposal in. Make sure you flag it with the right track when you submit (javascript, ajax, web, or whatever they're calling it this year), and don't hesitate to ping me if you're unsure about whether or not your talk got slotted correctly for the review process.

Census 2: More Than Just A Pretty Graph

Benchmarks are hard, particularly for complex systems. As a result, the most hotly contested benchmarks tend not to be representative of what makes systems faster for real users. Does another 10% on TPC really matter to most web developers? And should we really pay any attention to how any JS VM does on synthetic language benchmarks?

Maybe.

These things matter only in regards to how well they represent end-user workloads and how trustworthy their findings are. The first is much harder than the second, and end-to-end benchmarking is pretty much the only way to get there. As a result, sites like Tom's Hardware focus on application-level benchmarks while still publishing "low level" numbers. Venerable test suites like SPECint have even moved toward running "full stack" style benchmarks which may emphasize a particular workload but are broad enough to capture the wider system effects which matter in the real world.

Marketing departments also like small, easily digestible, whole numbers. Saying something like "200% Faster!" sure sounds a lot better than "on a particular test which is part of a larger suite of tests, our system ran in X time vs. Y time for the competitor". Both may be true, but the second statement gives you some context. Preferably even that statement would occur above an actual table of numbers or graphs. Numbers without context are lies waiting to be repeated.

With all of this said, James Ward's Census benchmark makes a valiant stab at a full-stack test of data loading and rendering performance for RIA technologies. Last month Jared dug further into the numbers and found the methodology wanting, but given some IP issues couldn't patch the sources himself. Since I wasn't encumbered in the same way I thought I might as well try my hand at it, but after hours of attempting to get the sources to build, I finally gave up and decided to re-write the tests. The result is Census 2.

There are several goals of this re-write:

The results so far have been instructive. On smaller data sets HTML wins hands-down for time-to-render, even despite its disadvantage in over-the-wire size. For massive data sets, pagination saves even the most feature-packed of RIA Grids, allowing the Dojo Grid to best even XSLT and a more compact JSON syntax. Of similar interest is the delta between page cycle times on modern browsers vs their predecessors. Flex can have a relatively even performance curve over host browsers, but the difference between browsers today is simply stunning.

Given the lack of an out-of-the-box paginating data store for Flex, RIAs built on that stack seem beholden to either Adobe's LCDS licensing or are left to build ad-hoc pagination into apps by hand to get reasonable performance for data-rich business applications. James Ward has already exchanged some mail with me on this topic and it's my hope that we can show how to do pagination in Flex without needing LCDS in the near future.

The tests aren't complete. There's still work to do to get some of the SOAP and AMF tests working again. If you have ideas about how to get this done w/o introducing a gigantic harball of a Java toolchain, I'm all ears. Also on the TODO list is an AppEngine app for recording and analyzing test runs so that we can say something interesting about performance on various browsers.

Census 2 is very much an open source project and so if you'd like to get your library or technology tested, please don't hesitate to send me mail or, better yet, attach patches to the Bug Tracker.

Update: I failed to mention earlier that one of the largest changes in C2 vs. Census is that we report full page cycle times. Instead of reporting just the "internal" timings of an RIA which has been fully boostrapped, the full page times report the full time from page loading to when the output is responsive to user action. This keeps JavaScript frameworks (or even Flex) from omitting from the reports the price that users pay to download their (often sizable) infrastructure. There's more work to do in reporting overall sizes and times ("bandwidth" numbers don't report gzipped sizes, e.g.), but if you want the skinny on real performance, scroll down to the red bars. That's where the action is.

Notes To A Future Self: Getting Productive On WinXP

Windows XP is truly a horrid desktop OS, particularly if you're a programmer. The default install contains roughly nothing useful, and even getting a development environment going requires grabbing the likes of cygwin, Visual Studio, and a zillion patches from Microsoft.

The truly dispiriting thing, though, is how badly cmd.exe still sucks. I fully admit that my personal programming proclivities are not normal, but to be reasonably productive I need a Unix-like shell, a terminal that works (can be resized, has reasonable VT100 emulation, etc.), and the ability to fix the "Caps Lock" key to do the right thing – namely, have it fire the "Ctrl" key instead. This is all relatively straightforward to do on Linux and OS X. Here's how I got it done with Windows:

Do the MSFT Patch Dance

Make coffee?

Install Cygwin

We've all done it a thousand times. This'll make 1001. It's kind of comforting that the Cygwin home page hasn't changed perceptibly in nearly a decade.

Get SharpKeys

Instead of fugly registry hacks, SharpKeys allows you to map the dreaded and useless "Caps Lock" key to something actually useful. If your key-mapping preferences swing some other way, SharpKeys can likely handle that too. Not sure why it's not built into Windows, frankly.

Set Up Puttycyg

Having cygwin is nice, but having a terrible shell with Cygwin? Not so nice. Enter Puttycyg, a small hack on the venerable Putty SSH client for windows that provides an option to launch a local Cygwin session in lieu of connecting to another system.

Once I extracted it and ensured the Puttycyg directory was in my windows PATH, I created a desktop shortcut to the putty.exe included in the distribution and configured the shortcut (right-click) to read:

"C:\Documents and Settings\slightlyoff\Desktop\puttycyg\putty.exe" -cygterm -

And then set the "Shortcut key:" to be:

Ctrl + Alt + T

Now, whenever I want a fully functional shell from my desktop, I just hit that key combination and it All Works (TM).

Joining Google

Starting next month, I'll be a Googler.

To my great surprise, I've been at SitePen two and a half years. It has been nothing short of wonderful which may explain why it doesn't feel like it has been that long. When I look back at what we've accomplished it's also surprising that we've been able to do all if it in such a short timeframe. Between the huge client projects and re-building Dojo from the ground up, it has been busy bordering on nutty.

It already makes me sad to leave behind working with the SitePen crew, many of whom I helped to hire in and who I count among my closest friends. But I won't be entirely gone. I'll still be contributing to Dojo in my new role, if less frequently. Not that it'll slow the project down any. Pete, Bill, Adam, and Tom have Dojo well in hand and have been driving things forward at a furious rate. Dojo has always been a team effort, and I'm excited about the improvements coming in 1.3. I've gotten a dis-proportionate amount of the credit over the years (and not enough of the blame), and as Dojo evolves from here it will continue to be because companies like SitePen, Uxebu, AOL, and IBM have all been able to contribute to make it happen and that leaders like Pete Higgins have stepped up to lead and teach and learn with the community. My deepest thanks go to Dylan and SitePen for having let me be a part of that process on a daily basis for the last couple of years.

So what could possibly pry me away from such a sweet, sweet gig at SitePen?

In a word, Chrome.

Three years after many of my friends joined Google, the appeal of getting to fix the "web as platform" problem from the inside has finally proven irresistible. There's much to do, and the WebKit platform seems like the best shot that we have (collectively) at forging a future that's not just open, but also markedly better. At SitePen I've had the chance to make the web a better place through Dojo. At Google I'll have a chance to do it from the browser itself.

To the friends I'm leaving, it was a privilege to work with you. To the friends I'm joining, thanks for your trust and faith.

Older Posts

Newer Posts