Infrequently Noted

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

Including Dojo, The Really Easy Way

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.

Viva La Sloth!

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 Virtual Life: IE At Arms Length

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:

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.

The Platform Strategy

Every software entrepreneur I know dreams of building a platform business. Not just wistful "wouldn't it be nice" stuff, no, I mean an all-consuming lust to become that which others build on. Led down the garden path by the example of Microsoft's dominance in the desktop market, believers in the platform strategy view ubiquity and control as the backstop against comoditization and a foothold for launching new attacks against the competition. The part that's not so obvious is that becoming a platform means that you first have to come close to winning the market on non-platform merits at which point, voila!, you're a platform...so long as you haven't made it impossible to build on your stuff.

I got to thinking about this because the tiny sliver of time that Java occupies in my mind these days is generally dedicated to dissecting it's rise and fall. The more time I spend on it, the more I realize that what's happened to Java in the last couple of years is a failure to recognize a couple of things:

  1. that Java won, despite it's myriad warts
  2. that winning is not a god-given right
  3. that you can't expect to win on your own terms

In fact, Java never won on its own terms. It won by having enough pluck and backing to build up a real, honest-to-god platform. The platform became a platform because it got used for enough good things that it came close (enough) to winning the market for a certain class of apps. Java the language is a pitiful mess. Java the platform? Now that's a thing of fucking beauty. Not only did Sun build the alliances necessary to ensure that Java would be available to whoever wanted it, the "Pure Java" marketing actually worked.

The result is a system that won because it created an environment where, no matter what the OS, developers could plug in a set of Java libraries (I'm ignoring the JAR cluster-fsck for now) and know that it would all "just work" thanks to a common bytecode interpreter. Now, other languages have used a similar form of platform aikido to catapult themselves into utility. Python, PHP, Perl, and Ruby spring to mind as languages that don't really mind their C dependency chains. Quite the contrary! The communities around these languages (rightly) consider being able to "swig up" some C or C++ hairball as something they can script as a core feature. It allows them to turn one platform win into another. Which is exactly where Sun continues to self-destruct.

Instead of understanding that they won the platform war and will inevitably lose the language skirmishes, the Java camp seems hell-bent on trying to shoehorn Java (the language) into ever more places that it doesn't belong. JSR 290? Gimmie a freaking break.

All of this points to a bright future that Sun, currently, seems too limp-willed to exploit. There's an amazing amount of good code that people have churned out in Java. The "Pure Java" thing actually played! Instead of allowing the partisans to throw stones at folks who want to run other, more productive, languages on top of the JVM (aka: the platform), Sun should follow through on it's baby steps and start giving real respect to the dynamic languages folks who want to help them continue to win on a platform (not language) basis. Hiring the JRuby guys and shipping jrunscript (aka: Rhino) in Java 6 are good first steps, but they don't go far enough. The atmosphere has to change. Acrimony needs to be turned into understanding, and real investment needs to be made in making the platform successful, even if it comes at the cost of one particular language.

It's not too late. I hope.

"Mobile Ajax" Slides

Here are the slides from my talk on Mobile Ajax development. I've got a longer-ish blog post in the works about getting a working emulation environment set up, but it's taking much longer than I'd anticipated to try to track down some of these things (if you know anyone at SonyErickson or Obigo, drop me a line). Hopefully next time I give this talk I'll be able to include a demo of the "foldable interface" thing I keep muttering on and on about.

There's some fun data in the slides that the carriers would really rather not have disseminated, not that their collective folly hasn't been laid bare qualitatively already.

Older Posts

Newer Posts