classical geek

My one day at QCon on Friday was interesting, plenty of good ideas and discussion. I kept to time in my own talk, and had some good questions. The highlights for me, though, were in hearing what everyone else had to say.

Bruce Johnson gave a good overview of Google Web Toolkit, something I’ve been following from a distance up to now with a certain amount of reservation. Generating a client-side UI on the server has always struck me as over-engineering, and up to the first third of his talk, my prejudices survived pretty much intact. By the end of the talk, though, I was seriously interested in giving GWT a try. What made me change my mind?

- because the entire codebase is written in a strictly-typed language (Java), global optimisations can be made with much more ferocity than in trying to infer intent from a loosely-typed language. As a human writing code by hand, I still prefer scripting languages, but I can see that all the safety harnesses help out when generating the code automatically.

- GWT doesn’t take as command ‘n’ conquer approach, but plays well with hand-written web UI. You can break out into Javascript in your code (overloading the native keyord - too cute!), and/or target GWT at specific elemnts in a hand-written page

- network performance, caching, and all that important-but-tedious plumbing detail benefit from the global optimisation approach.

On top of which, Bruce seemed like a down-to-earth guy, and very up-front about what it could and couldn’t do. He was also able to back up several performance assertions with real numbers and graphs.

So, I’m convinced enough to take it out for a drive, at least, and see if it’s for real. Compiling Java into Javascript still seems like a crazy idea, but it looks like they might have made it work!

I’ll be in London on Friday at QCon, talking about whether we need to think of the Javascript code in the browser as a separate tier in our n-tier applications. The short answer is ‘yes’, for those not able to attend, but along the way I’ll be visiting some common design patterns, and looking at the differences in coding style between Java and Javascript.

Today, I have been mostly cussing at XML deployment files…

Ant’s copy task has proved to be at the root of my problems, and the solution was quite an interesting one.

The app I’m working on runs in several configurations, all of which are deployed to a single JBoss server. To configure the various instances correctly, we make heavy use of the copy task, with the filtering attribute, which allows for substitution of pre-defined tokens with property values in the copied file, while leaving the original untouched.

The copy task is also smart enough to only make a copy if the target file doesn’t exist, or is older than the original. Unfortunately, it will do this even if filtering is switched on. The original template version of a small config file in my setup hadn’t been modified for two months, and so the most recent copy of it in the deployment folder was newer than the original template, but had the wrong substituted value in it. As a consequence, some versions of my app were trying to authenticate against the wrong database.

The solution is simple - whenever you set filtering=’true’, also set overwrite=’true’, to switch off the otherwise very useful date-checking. Beats banging your head against a brick wall for half a day, at any rate.

Having signed up for the pre-release versions of Vista some time back, I finally got as far as loading the OS onto a machine the other day. (The crunch was needing to have an IE7 to test with. I’m not yet ready to upgrade to IE7 on my main Windows machine.) Lacking a spare physical machine, I thought I’d run Vista on VMWare. Bottom line - it is possible, and it runs well enough, but some tweaking and messing around is required to get it working. Most of this is documented elsewhere, but in case it should prove useful, here are the steps that I went through…

First issue is size. Vista reckons it needs a minimum of 512MB and 20GB RAM. I allocated 768MB to the VM to be on the safe side. As I didn’t have a spare 20GB on my laptop, I decided to create the VM on a USB drive, which is complicating matters, but has worked in the past for Linux VMs. VMWare Workstation 5.0 offers a ‘Longhorn (experimental)’ profile, which I used to create the VM. I installed from a CD containing the RC1 build (build number 5600).

First gotcha is that VMWare will only run correctly at a low resolution prior to installing the VMWare tools. The Vista installer requests a higher resolution initially, and so it doesn’t show on screen. This can be solved by editing the VM’s main config file (the little text file with a .vmx extension). Add the following two lines:

svga.maxWidth = “640″
svga.maxHeight = “480″

Thanks to Joel Spoelsky’s blog post for highlighting this.

The installer will now run, and be visible, although it looks pretty grim. The rest of the install proceeded without a hitch, and dumped me into a 640×480, 16-colour Vista desktop at the end of it.

To get back to a decent screen resolution from here, first install VMWare tools in the usual way, and then shut down the VM, and remove the two lines that you’ve added to the config file.

When it comes back up again, the resolution and colours are much improved (or, at least, the display settings offer a selection of higher resolutions). Under VMWare, it’ll only present a dummy graphics card, so you won’t get the Aero glass effects. Same goes for running Linux with Beryl or Compiz in a VM - no wobbly windows and related fun and games, but there we are.

Second gotcha is that there’s no network connection to the outside world, and no NIC registered with the system (i.e. ipconfig lists nothing). Getting that running took a bit more fiddling around than I had thought.

The VMWare tools virtual CD includes a driver for the VMWare virtual network cards, which can be found in D:\Program Files\VMWare tools\Drivers\vmxnet\win2k once you’ve mounted the installer CD again. There are several ways of installing a driver in Vista, including Add/Remove hardware from the Control Panel, and right-clicking on the driver and selecting Install from the menu. Neither of these work.

The trick that worked for me was to enter the Device Manager from the Control Panel, and select the network adapter from the tree of items. A NIC is listed under ‘network adapters’, and it can be right-clicked. From the Properties dialog, select the Driver tab, and install the driver, pointing it at the driver on the D:\ drive containing the VMWare tools. Vista accepted the driver this time, and all went well, giving me a network connection between my VM and host OS.

Some further tweaking was needed, this time in the Control Panel’s ‘Network and Sharing Center’ to switch to a less draconian profile that alloqwed the host OS to ping the VM and make sure the connection really was there.

Vista still has difficulty shutting down, which I think is due to it disconnecting from the USB drive before it’s finished with it, but that’s a peculiarity of my setup.

Disclaimer: I am not a VMWare expert. I figureed this out the hard way, and it may be a suboptimal solution. If so, please let me know via the comments section. I’m offering up a log of my experiences in the hope that it helps someone else have an easier time getting Vista RC1 onto a VM.