Code is Mandatory

One of my must have tools when developing software is VMWare. This great product lets you run a PC within another PC. It gives you an emulated PC on which you can do almost anything that you can do on a normal PC. You can boot it, install software on it, configure it to have network access, and when you have finished, you can shut it down.

However there are a few advantages that it has over a real PC. With a real PC, if you botch a software install, it is often a case of starting again by re-installing the operating system. However with a virtual PC, there are other options. When you shutdown a virtual PC, VMWare gives you the option of committing or discarding changes that have happened since you booted the virtual PC. So if you botched a software install and want to revert the system to the state that it was at before you started the install, just discard the changes.

Another advantage is that the virtual PC is persisted as a normal operating system file. This means that you can do normal file operations on it. Actions such as zipping it up, burning it to CD, moving it to a faster host machine or even sending it by email - only kidding - these persisted files can be hundreds of megabytes even when zipped.

Okay, so let me list the ways that I have used this animal over the last couple of years.

The first use was when we had to develop for and configure a Websphere Application Server to talk to an Apache Web Server. Because we needed separate servers to evaluate the configuration options and because there was a shortage of hardware, we used one PC running two instances of VMWare - one for the Apache Web Server and the other for the Websphere Application Server. With enough RAM, the performance was adequate.

The project also required us to support a variety of Browser and Operating system combinations. Rather than have a battery of PC’s lined up taking up desk space, we opted to use VMWare. We configured a clean VM for each required operating system browser combination. When we needed to test a particular combination, all we had to do was boot a particular VM. Once testing was done, we could shutdown the VM, discarding any changes. We could always start with a known clean configuration.

More recently, I was investigating Active Directory. Rather than interfering with the existing site configuration or stuff around trying to set up a separate physical LAN and PCs, I used VMWare. By creating two VMWare instances, one with Windows 2003 Server, the other with Windows XP and setting them up so that they were on the same private host only network, did the trick.

One place that it shines is with training. We had to do a half day course on the Microsoft Sharepoint Portal Server. Rather than going through the hassle of trying to get the software installed and configured beforehand on our PCs, the instructor waltzed in on the day, pulled out a couple of DVDs with preconfigured VMWare saved files and we were ready to go. The added benefit was that we did not have to worry about installing and removing the software from our PCs.

On Mac OS X, Virtual PC provides a similar facility. The main purpose here seems to be to provide access to Windows only applications. I have used it, but don’t find it as snappy as VMWare. Possibly because I was running it on a iMac 800 with 768MB.

Microsoft also provides a version of Virtual PC for Windows, which I haven’t tried yet.

Moving between different screens of a small 12" iBook (1024×768), a 17" iMac (1440×900) and a 19" Windows 2000 (1280×1024) Desktop PC got me thinking about how I use screen real estate. My initial reaction was that the larger the screen size and the higher the resolution, the better I work.

I mean, with a large screen and high resolution, I can show more columns and rows in an Excel spreadsheet, fit more lines in a terminal window or see more of the code when editing a file. Or sometimes I have my program editor open on one half of the screen and the running version of the program on the other half.

However, I am starting to think that maybe bigger is not always better. I think I am using the 12" iBook reasonably effectively and for some tasks, I actually prefer using it instead of the 17" iMac. And that is what started me thinking.

Basically, there is a part of the screen that I am comfortable focusing on. Whatever I am currently doing, has to be done in this sweet spot. For me this is about 600×600 in the centre of the screen. Whatever application I am currently working on has to be positioned there. And whatever bit of text or thing I am working on has to be near to the centre of this sweet spot.

For example, Vim provides a way of showing multiple documents in separate windows within the main application window. However, I find that there is always one area of the window that I prefer working with. If there is something in the top right window, then I feel more comfortable moving that window into the sweet spot rather than looking at and typing into the window in the top right corner.

I prefer only focusing on one task at a time. If I am coding, then the entire screen should be devoted to coding. However, It doesn't mean that the whole screen should be one code editor. I am comfortable with supporting information panels surrounding a central working area. For example in Photoshop and Photoshop Elements, the information palette is very useful for showing, in real time, the size of objects when they are being resized and/or the RGB values of the pixel under the mouse pointer.

But I still like the area I am working on to be in the centre of the screen. And I don't like these additional information panels encroaching on the sweet spot.

There is an excellent article on code generation at Frans Bouma’s blog

One potential disadvantage he mentions is that the generated code is not up to par with the functionality requirements you have.

I have a similar concern. That is, they can get big, complicated and become the centre of attention. This can detract from the application being built. At the end of the day, we are building a system or application for a client. It is those requirements and that application which should have our primary focus.

Finally, for me the ultimate code generator is a powerful scripting language such as Perl, Python or Ruby. Using these, you can build and maintain custom code generators quickly.

Interesting discussions about all sorts of coding issues. Current thoughts are about pair programming. I have always wondered what it would be like to pair up a touch typist with a pecker.

Good thoughts on choosing a programming language from someone in Wellington!!