Infrequently Noted

This past week I had the good luck to be invited to speak at JavaPolis and while there, even for only 2 days of the weeklong event, amazing stuff seemed to be dropping out of the sky like rain.

My talk was in the first slot of the first day of training (before the official conference start), but despite the hour and the day, folks still came to hear about Dojo. Following me were Jonas Jacobi and John Fallows' talk on JSF+Dojo, but little did I know (until a half hour before they gave the talk) that they'd written a new Comet server from scratch for the talk, and it implements Bayeux! Their demo hooked a Dojo table and chart widget up to a set of Bayeux channels for updating stock prices. It's always fun to see everything on the screen update in unison.

The next day, some of the folks working on Phobos cornered me to show some of the server-side Dojo integration they've been working on. It's amazing to see JavaScript finally "getting there" on the server side, and I'm glad we can be a part of it.

Lastly, there was some spirited debate in the never-ending static vs. dynamic languages debate over dinner. Not sure I swayed anyone at the table, but there was a pretty strong dynamic languages contingent at the conference in general, which I wasn't expecting.

I was happy to hear that the Swing team at Sun is starting to really get that startup time and complexity really are significant limiting factors. To that end I started to throw together a very small dojo.widget.SwingWidget namespace and I was surprised at how simple it was to get things dynamically updating compared to earlier experiments with SWT. Desktop access and portable desktop UIs have always been the one place where dynamic languages fall down, so perhaps we really can make a difference with JavaScript + Dojo + Java in liberating desktop programmers. Swing programmers who are interested in seeing how deep this particular rabbit hole goes should get in contact with me...might make for some sexy demos of Java 6 if we can show that there's no external dependency chain and it's faster to develop in than Java.

I just fired up Firefox to do a bit of writing over in the project wiki, and as sometimes happens, I was presented with an extension update notification screen. The UI is mostly a farce of user control in that there's not nearly enough information to judge whether or not going to the next version of Me.dium is a good idea or not. I blithely click "OK" to let it do it's installation dance in the hopes that it'll get out of the way. I've got stuff to do. It dutifully proceeds.

A couple of seconds later, it's done, and instead of getting an unobtrusive notification of success while the browser starts to load whatever it is that I actually care about, the update window simply shows a nearly identical UI, but the button that had previously allowed me to proceed with the upgrade now reads "Continue". Do I have a choice at this point? What would closing the browser at this point ever buy me over hitting "Continue"?

Given the massive number of Firefox users and their use of extensions, it boggles the mind to think how much time is wasted by this one button alone. Unless there is an affordance for recoverability (roll back the upgrade) or discoverability (what just happened?), this button needs to die.

AOL has been generously hosting builds of the toolkit in their CDN for some time, but using these builds has always seemed scary. Configuring local and remote copies of the same thing hardly seems like fun. Also, lots of people ask us for a way to "just include one file to get Dojo". It's an obvious thing to do, and it turns out the cross-domain infrastructure that AOL donated is the perfect solution to both problems!

In response to Amit Green's excellent suggestion, I've constructed a couple of very small "wrapper" files that will let you include the "Ajax" build of Dojo from various versions through the cross-domain loader. Including the latest stable Dojo couldn't be simpler:

<script src="http://download.dojotoolkit.org/dojo_0.3.1.js"></script>

It's also trivial to test out the latest 0.4.1 Release Candidate:

<script src="http://download.dojotoolkit.org/dojo_0.4.1rc2.js"></script>

That's all there is to it!

From here on in, your pages can use the dojo.require() system to pull in anything that's part of the "stock" distribution, and by following James' detailed documentation and test page, you can also load your own custom packages while still loading the main system from a separate domain.

So for a little while I've been giving this talk on the current state of mobile web app development and why Ajax (as we know it) isn't gonna be the next big thing on phones. Last week, to my tremendous embarrassment, I was asked to give a summarized version of the same talk in front of a lot of folks who actually work on the phone browsers I've been slagging. Of course, me being embarrassed didn't make the state of play on phones any better, but in discussions afterward it became clear that a lot of the people working on these browsers really do get what users want. Not surprisingly, the ones with the best understanding of how to improve the experience were the same people that don't have their bills paid by the OpCos. And then there was J2ME.

Long story short, between XML, XHTML, J2ME, WAP, and BREW it seems the mobile content industry has been so preoccupied trying to stuff useful data into sausages for delivery that they totally forgot why the web won: it lets you be lazy.

The web lets Moore's Law play out to the advantage of people who don't want to understand XML, XHTML, what a "mobile variant" or "compact profile" is, or why they should really think about entering into some sort of totally lame legal agreement with Evil OpCo X. That is to say, HTML and "tag soup" let every Joe and Srinivas put something into the commons for everyone else to see. Even if it's was "broken", you still get best-effort results, and that implies that every successive hardware generation can work harder to do the "right thing". Why is this totally awesome? 'Cause I get to be lazier as a result.

So here's a quick note to the folks who are holding on to the J2ME or XML pipe dreams: you're infrastructure. Cope. Yes, you'll still be "ubiquitous", but you'll never be loved, and don't imagine that you're hard to replace. The really creative stuff isn't going to get done on top of you until you learn to start applying those cycles to letting people be lazy. And I don't mean "here, have a gig of tools that you can use to produce a 'hello world' once you learn this programming language". I mean "so what can I do with Notepad?"

Actually, maybe that's what we should call it: The Law of Notepad: if creative people can't make something awesome using the lamest of production tools, your platform is gonna loose.

The IE team was kind enough to invite me to a small launch party last night, and while there I ran into someone who was asking how you do "real work" on IE. It's a strange enough thing for a webdev to say, but the setting made it that much more interesting. I guess there's a whole generation of webdevs who would like to put their heads in the sand and pretend that IE doesn't exist. Getting to a productive point when debugging hard problems on IE requires a good toolchain. Here's my setup.

The basic pieces are:

1. A high-end mac laptop, stuffed to the gills with RAM and a fast HD. Sadly the MBPs max out at 2GB of RAM today. It's a significant limiting factor when trying to work with multiple VMs
2. A fast external storage device of some sort. In my case, that's a samba server with a half terabyte of soft-RAID'd disk on switched gigabit ethernet
3. Windows licenses. I use both Win2K and XP. I recommend older if you can get it, just because the older the Windows version, the less RAM the OS will soak up. Configure your VMs for the minimum operating memory you can get away with, you can always bump it up later.
4. Virtualization software. These days I'm using Parallels, but previously I've used both VirtualPC and VMWare. They'll all get you where you want to go so long as you can quickly make VM clones.

Before I get into the process, it helps to know that I'm not just making VM clones for the hell of it. Yes, there are things floating around that purport to let you run IE 5.5 alongside IE 6.0, etc. The fact of the matter is, though, that these aren't what your users are running. IE isn't built like Mozilla or any other browser. It really is down into the core of the OS because many of its behaviors are determined by the available versions of other components. Take, for example, the networking and javascript stacks. These are the cause of some very critical deployment-time bugs, but their behavior is determined by the versions of winsock and the Windows Scripting Host that are installed in the host OS, not the "IE version". This means that if you're not running the same version and patch-level of Windows, you're not running the same browser that your users are, and if you're not running the same browser, you can't debug the problem or come up with a workaround. To accurately debug issues, you need to be able to step through OS revs, not just rendering engine+browser chrome updates. And as if that's not enough, major Microsoft partners maintain their own IE builds. Getting reports of a problem that only shows up on Dells? There's a reason for that. In cases like this, there's really not much to be done short of buying a POS dell, but we can at least cover most of the rest of the strangeness we see in the wild with virtualization.

As for the choice of Mac, you can try to get away with something else, but if you support Safari or Mac users in general, it pays to have something that can run not just Safari, but all of the other mac versions of the various browsers your organization might care about. That, and OS X is the best desktop Unix available on the market today (sorry Ubuntu, you're not quite there yet).

Here's how I set up my environment:

• Create a new VM. In it, install/register/jump-through-MS-hoops for the baseline version of the OS(es) you're going to be using. Don't even think of running windows update or installing a service pack yet.
• Configure the VM to use the right local networking setup
• In this new VM, install the Microsoft Script Editor, Ethereal, Drip, the MS web developer toolbar and whatever other debugging tools you use universally when debugging for IE
• Shut down this VM and copy it off to your mass storage device. Give it a name like "XP_baseline"
• For each OS Service Pack, do much the same thing. Install the service pack (avoiding browser upgrades if possible), shut the VM down, and pickle it off to cold storage
• Once you've got a VM with a pristine version of the last OS service pack, start doing the same thing, but with major browser revs. If you can't find an installer for a particular IE rev, try the Evolt Browser Archive.
• At the end of the last step, you should have a "mostly" up-to-date version of both OS and browser. Once you've got a copy of that in cold storage, only then should you run Windows Update. Mmmm...watch that VM reboot!
• This is now your "working VM". Keep it on the local disk for on-the-go development and debugging. Also, keep this VM patched as MS releases updates.
• For each new major browser rev, do NOT use your "working VM" as your baseline. Instead, pull your last major browser/OS rev snapshot out of cold storage, copy it, upgrade the copy, and put that back in the drawer

At this point, you're going to have ton of space eaten up on your external drive with VMs that you might only use very occasionally, and that's OK. Disk is cheap and if you've done stuff the way I recommend, your vms are probably going to be less than 3GB in size each. Should you make the mistake of installing, say, VisualStudio then at least disk is still cheap. At this point, you're set up to respond to the thorniest bugs, and do it faster and more accurately than your co-workers/competition.

Need to test something on IE 5.5? No sweat, just thaw out that VM and give it a whirl. Clients reporting a problem on IE 6 that you can't reproduce? Try the "naked" version of IE 6. Odds are you'll be able to reproduce it there, and with some binary-search style patch application, you can pinpoint down to the individual hotfix when things got fixed.

At this point I should probably disclaim any and all liability you might incur with regards to your Windows EULAs. I'm not advocating that you violate your licensing terms with Microsoft, and depending on your agreement with them, you might be required to do something in addition to these instructions in order to stay in compliance, despite this really being a workaround for Microsoft's design-time failures. Follow this recipe at your own risk.