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:
- 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
- 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
- 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.
- 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.
Older Posts
Newer Posts