Virtual CloneDrive is a great, free utility for mouting ISO images as though they were their own CD/DVD drive. Check it out here.

Giving credit where credit is due: this little tool works as advertised, is free and the interface is better than some of the commercial software that does the same thing. Check it out at http://cdburnerxp.se/

I avoid using IE for a lot of different reasons but when I do use it (for testing, for example), I notice things here and there that bug me. Sometimes those things bother me because I’m used to the way Firefox or Chrome does it but sometimes, like today, it bugs me because I think it’s done wrong. Today’s gem is the location of the refresh and the stop buttons. I’m not sure why the IE team chose to move those buttons all the way on the other side of the address bar. I consider them an integral part of navigation and so would expect them to be near the back and forward buttons. Yes, this is partly because I’m used to them being there but mostly it just makes sense. And since, as far as I can tell, there’s no good reason not to put them there, I’m puzzled by this seemingly poorly thought out decision.

Once I started using FireFox, I never looked back. The reasons: 1) it’s support for standards was a breath of fresh air and 2) the extensions system seemed robust and easy to contribute to and 3) there are a huge number of extensions that had become “must-have” features in a browser.

Then along comes Google Chrome. The timing on this was good as I was really starting to hate that it took almost a minute to start Firefox and that Firefox would soon after starting consume upwards of 400MB of memory. This bothered me in practice and in principal. While Firefox 3 seemed to have improved things in that regard it was still a hog. I’m still seeing very long start times and memory growth that takes a little longer to reach the stratosphere.

Google Chrome seems to be a direct response to these problems. I mean, the thing starts up almost instantly and although memory growth is possible it is tied directly to the number of tabs open. That is, if you close tabs memory goes down. And don’t get me started on the Task Manager. I mean, this thing is a power users wish come true.

So Google Chrome solves those problems but leaves out extensions. That, to me, is a huge problem but because it is so fast, and I never thought I’d be saying this, I can do without extensions for the time being.

When doing development I have to use FireFox because of FireBug but that’s the only time I really feel the need. And having used Chrome now since it was first released FireFox feels like a behemoth.

All that said, I still feel like a FireFox loyalist. It has done so much for browsers - so, if they are able to clean things up and make it run leaner I’m pretty confident I would go back to it.

This is the source of much consternation among software developers, testers and users. The software developer feels that a user interface is fundamentally flawed but long-time users of this software care little about this and more about their ability to use the software once they get the new version. So what is a software developer to do?

Here are the options:

1. Completely ignore the user and do what you think is right
2. Completely ignore what you think is right and keep the long-time users happy
3. Add the new UI and make everything revertable
4. Find some middle-ground

So obviously the last one is the way to go but I mention the others for sake of argument.

Ignore the User
Well, this is just not a good idea. There’s little reason for writing software if you’re not going to heed user’s wishes - especially the loyal ones. While this does give you some freedom in decision making you need to listen to the user’s complaints because some of them might be rooted in something other than “it’s just different than it used to be”.

Ignore Yourself
The other extreme but an equally bad idea. After all, if your software doesn’t have some vision, some guiding principal, you will find that it will sooner or later turn into a user interface equivalent of a well-used dumpster - or as I like to call it: Lotus Notes. Each user has their own reasons for wanting things a certain way: personal preference, usage model, etc. Trying to bring everything to everyone without a design-scaffolding will get crappy fast.

Satisfy Yourself and the User With Options for Everything
This might seem the way to go in situations like these but I can tell you from experience that this is often a terrible option. Here’s why: unless its done just right the UI can get even more confusing and swamping useful options in a morass of stupid backward-compatibility options. And from a developer’s perspective, coding all these branches in user interface display is a good way to get yourself into a ruinous and fragile codebase.

Finding some Middleground
The truth is that there is no silver bullet here (like so many things in life) but there are some guidelines to follow.

• When considering whether or not change the UI ask yourself this: is the new way actually better or just different? Consider this carefully. We have a tendency to want to change things in part to do something interesting and in part because some of us just hate perceived stagnation.
• When folks suggest that users will be unhappy with the change, find out specifically what the problem is. And I mean very specifically. Don’t settle for “it’s just harder to use”. People say that when things are different than they used to be. There were those who complained that word processors were harder to use than typewriters and if we had all collectively capitulated this would be a very different world. In other words, find out if the only problem is that it’s different. If so, you can make better decisions. For example, if your revenue is very much dependant on existing users and *all* of them are adamant about this then your hands are tied. Maybe there’s something you can do to soften the blow.
• This kind of overlaps the other two but should be considered in its own right. Are the two ways functionally different? That is, does the new interface target folks who use the software in different ways? For example, CAD software might have mechanical engineers and architectural engineers using it. The interfaces for each might need to be different. This might be a case where you should allow the users options.

There you have it. There are a lot of things to consider but the most important thing to realize is that you should never just blindly accept the clients demands nor should you blindly ignore them. While that’s immediately obvious maybe some of the other considerations here will help folks figure out the best path to take.

Having recently begun evaluation of TeamCity in our continuous integration environment I can say with some certainty that it is a remarkably sound, stable and well-designed product. My previous experience with continuous integration has been to roll my own solution using a variety of technologies. On Windows, Visual Build Professional is very much like a much easier to use well-supported MSBuild. We’ve been using it for ages to handle automation of tasks that would otherwise take ages to script.

Where Visual Build falls short (and I’m pretty sure it was not designed for this anyway) is in managing multiple builds and exposing the progress of each to anyone interested. I’ve had to roll my own system of publishing emails when builds succeed and fail, intermittently checking for new commits with our VCS, etc. That’s fine, but as more and more projects are added, removed and changed this becomes a burden.

Enter TeamCity. TeamCity picks up where Visual Build leaves off. It is a fantastically scaleable and easy to use web-based solution that effectively manages multiple builds running on any number of machines. Using “Build Agents” installed on any machine, TeamCity can run multiple simultaneous builds triggered by time or by commits. It handles multiple source control solutions (I’ve only used Perforce) seamlessly and makes duplicating ‘Build Configurations’ incredibly easy.

Monitoring builds is as easy as navigating to a web page or, if running on Windows, installing a system tray notification utility that works really well.

The web interface is fantastic. It’s clean, user-friendly and makes excellent use of AJAX to find that perfect balance between web and desktop application that is so often elusive.

I highly recommend it in part because JetBrains (the maker) offers so much for so little (FREE!). It’s the perforce model of offering a free solution that you start to pay for as your project grows.

I saw an article today from C|NET from what must be not-too-technical writer who makes the claim:

Nor can I imagine Web developers getting excited about developing for yet another browser. It took years for anyone to start developing for Firefox, and no one got excited about developing for Flock or other spin-offs of Firefox

This is a misleading statement because it ignores the fact that Chrome uses Webkit for rendering, the very same renderer used by Safari. Only developers who ignored Safari as a target browser could be in trouble with Chrome. And as an aside, Flock uses Gecko as its renderer just as FireFox does. In fact, Flock uses probably 90% of the same code inside and out as Firefox so developers need not worry at all about coding to Flock.

Google Calendar has the capability of popping up reminders when as appointment times approach. This has never been particular useful to me as I don’t usually keep my calendar up in FireFox if I’m not actively looking at my agenda. With Stick, though, you can create a Navigator tab that points to your google calendar. In the background, it’s quietly checking for approaching appointments and will popup a dialog when it’s time to remind you of something. It has made Google Calendar’s popup reminders useful!

Note that Outlook’s reminders are still superior in that you can snooze them, but it’s one step closer to a web-based alternative.

I’m in the process of testing a new plugin for Stick that someone recently recommended creating: a tab that displays running applications much like Windows’ taskbar. I liked the idea because it’s one of the only things I keep the taskbar around for anymore (I’ve stopped using the Start menu lieu of Launchy and other utilities) and if I could replace it was something equally functional and even add some helpful additions it would a great add on for Stick.

When researching the best way to find out how to display the same items that are on the taskbar, I ran into an article on CodeProject which solved the problem by sending messages to the taskbar’s embedded toolbar to retrieve the list of buttons. There are a couple of problems with this: 1) a dependency on something that’s entirely undocumented and 2) no good way of being notified when the buttons change. The first one troubled me since your own software could break with any new release if microsoft decided to change the way the taskbar was implemented. That’s obvious and generally should be avoided whenever using a third party sdk. The second one is problematic also in that although I could hook that window in my own app, the MSDN documentation is riddled with warnings about maintaining hooks for any length of time and that hooks are meant to be setup and removed as quickly as possible. The whole thing seemed like a giant hack that was waiting to crumble into little pieces as soon as it was released. So I keep looking.

I stumbled on a comment on some blog somewhere (I wish I still had the link) where someone mentioned a little Win32 SDK function called RegisterShellHookWindow. This little beauty does the work of WH_SHELL system hook without having to setup a hook at all. This solved the two aforementioned problems and seems to work flawlessly.

The bad news is that the documentation reads (near the bottom): “It is recommended that you do not use it in new programs because it might be altered or unavailable in subsequent versions of Windows.” It just so happens I find this function too useful to ignore and take MSDN’s advice. I may pay the price later but I figure it’s worth it - and I can always fall back on the WH_SHELL hook instead if need be.

Stick is now part of my internal build process which means that it will be easy for me to push updates to everyone.  This is important because it means the time it takes me to fix a bug and push it out to everyone is dramatically reduced which, in turn, means that I’m more likely to do it (one of the prices to pay for freeware, I suppose).

Anyway, I just dropped a new Stick that includes some fixes for some pretty bad bugs in the 2.7 build.  Also, it includes an improved automatic update system that will automtically check for updates and, optionally, download and install them.

This version also has an anti-feature: I removed the Application Search feature which many did not know about anyway.  Two reasons: 1) It wasn’t as good  as some other solutions and 2) It was completely unrelated to the focus of Stick: tabs.   Though I have pulled it out of Stick and I have pushed it into a standalone application I’m calling AppGo.  In time, I will probably improve it and release it but only if it’s at least comparable  to applications like Launchy.