Once again, I’ve decided to switch email clients; this time from The Bat to Gmail, or more specifically, to Google Apps. After some recent issues with The Bat (mostly relating to a recent update), I decided to make another go at switching to Gmail; but this time trying the Google Apps version.

After my last attempt, I was informed that the Google Apps edition of Gmail doesn’t suffer the Sender issue that so plagued me before. After almost a full day of work, the transition is complete. And I couldn’t be happier.

The only downside is the expense - all in all, it cost $78.95 to go through this process. This was spent on two tools that made the process possible:

• Aid4Mail - A key application used for converting the various mail-storage file formats.
• gMOVE - Used for importing PST files into Gmail.

The process itself was simple, once I had found the software I needed, which took some doing. Here’s an overview, and some notes if you happen to try something like this (this assumes that you have Outlook installed).

• Export messages to mailbox format. (If you are moving from Thunderbird this isn’t necessary as it already is stored in that format.)
• Use Aid4Mail to convert the mbox files to PSTs
• Load PSTs into Outlook and cleanup as necessary (remove duplicates, cleanup directory structure)
• Launch gMOVE and use it to import the messages from Outlook to Gmail

There are a couple major differences in this attempt, compared to the last. A few things annoyed me about the way things worked after the last time, not the least of which is that by using Gmail Loader you loose all meaningful timestamps. So you don’t know when a message was sent or received.

gMOVE eliminated that problem. It sends the messages to a special POP3 server, and automatically configures your Gmail account to use it. That way, they can control the timestamps, and set them to what they originally were ¹.

So after all is said and done; I think I’m happy with this system; much better than last time. I simply can’t justify using a desktop based email client anymore. It just leaves you too out of touch.

1). There is a security issue here, so I wouldn’t do this with anything containing sensitive information.

I recently heard about JungleDrive (hat tip: Ryan), and decided that might be the backup solution I’ve been looking for.

I’ve got thousands of pictures, hundreds of megabytes of source code, and documents dating back several years, all of which I’d like to ensure I never loose. So far I’ve shied away from all of the online backup solutions due to the expense. But JungleDrive uses Amazon’s S3 service for storage, complete with its rather inexpensive pricing model.

With that pricing model, JungleDrive has the potential to provide most of what I need, and some extras that are quite nice; all at a better price. So far, I’ve looked at two options:

1. Use an online service. Much lower startup cost, but comes with a recurring fee.
2. Build a backup server. This will require at least 1TB of fully redundant storage. I’ll also have to identify software that will meet my needs. Much higher startup cost, but only minimal maintenance costs after that.

JungleDrive has a few upsides, the biggest for me is that I can access it from anywhere that I can install the client, not just when I’m connected to my home network. With a low price, simple, but flexible interface, and a great storage system on the back end - it certainly sounds like a winner.

Though, there are some features I’d like to see, that it doesn’t offer:

• Access to files without installing software.
• Incremental backups. This would make backing up PST and similar files far more reasonable.
• Store multiple versions of a file.
• Compress data before uploading. This would save a fair bit of bandwidth for me, as I backup things such as conversation and chat logs.

Will these missing features be enough to not use the service? I don’t know yet, I’ll give the service a couple weeks to see how it goes. So far I’m fairly impressed, though wish it offered more features.

Once I hit the two week-mark, I’ll post a status update; and my final decision as to whether I’ll continue to use it.

Later this week I’ll start the process of closing my start-up, aDeVIX Software. After months of planning and development, the decision has finally been made to call it a day. It was a great idea, but time and money conspired against us, with great effect.

We had a great product in mind, just not the resources to make it happen. I do believe that it would have been quite a success, but it takes a fair bit of time, and even more money to launch a commercial product aimed at mid-size businesses. It’s not a simple thing to sell software costing more than $10,000 per install; and being a company with no reputation, it’s almost impossible.

We planned the design, the marketing, the budget (even allowing for snacks & drinks), covered every detail, but when you don’t have the time to write code, or the money to pay people to write it for you; no amount of planning will help. We then delayed, then came up with smaller, simpler products, then scrapped all that and went back to the original idea.

Months of work, thousands of dollars in various expenses, and not a single dime as income; much effort, no reward. Many thousand lines of code, a few websites, countless meetings, and enough notes to account for the clearing of a small forest; but no money, no assets of value, nothing. It’s a bit painful to think about all the effort, and see that it was all for not.

It’s certainly possible to make an ISV work, it’s just a matter of being honest with yourself. Can you afford the expenses? Do you have the time? Will you be able to support the product yourself until it brings in enough money to hire people?

In some ways though, I’m happy that this is done, as it now leaves me free of any potential conflict of interest when it comes to pursuing future opportunities.

For those that missed it (like me), the Windows Vista User Experience Guidelines has been updated with some additional content. This update add content in the following areas:

• Software Branding
• Confirmations
• Warnings
• Toolbars
• Sound
• Icons

These guidelines are crucial to ensure the most consistent user experience possible. Though many don’t, this is a document that all developers should read. I firmly believe that consistency is the most important single factor in design, and following an established style such as this is a great way to ensure that a UI is as consistent as possible.

If you’d like some background reading, the XP version is still available.

The latest and greatest version of WordPress (the software that powers this site) has been released. This release looks to be mainly small fixes; nothing earth shattering this time around. As always, painless upgrade, and all seems to be working well.

As I didn’t see a package for just the changed files, I went ahead and zipped them up. These are just the changed files from 2.1, so this should make the upgrade process much quicker if you’ve already got 2.1 up and running.

The great Lutz Roeder has released a new version of the .NET Reflector. From what I’ve seen; this version is extremely nice. This has long been an required tool of any serious developer. With this update Reflector has reinforced its position in the list of tools you just can’t live without.

Scott Hanselman provides a great review; check it out for the details on what’s new.

Using Vista? Then I highly recommend getting a decent 1GB+ thumb drive, and use it for ReadyBoost; while the FAQ says 256MB is enough, for best performance I’d shoot for more. There is little difference under normal operation, it’s under high loads that ReadyBoost really shines.

On my main PC (with 1GB RAM), I would see fairly frequent freezes when several applications were open (primarily when memory utilization passed 80%). With a minor upgrade to 1.5GB RAM, and a 1GB thumb-drive* for ReadyBoost, the system became much more stable. This may be among the best new features in Vista.

I’ve frequently blasted Vista for the poor performance compared to XP, but with a few tweaks, it runs quite well.

* These drives (SanDisk Cruzer Mirco U3) work well, once to get the drivers working properly. If possible, pick a different drive; these are a pain at times.

I love what I do, and I work with a great team. While it’s still far from perfect; I can say that I do love my job. For the last couple weeks though, I’ve had to remind myself of this several times. I’m sure we’ve all done it, in this industry it’s hard to avoid. You read an email or receive a phone call and repeat the mantra “I love my job, I love my job, I love my job.”

Unreasonable clients, managers that just don’t understand; there are so many reasons, so many triggers. While reciting this mantra often invokes laughter from those nearby, some thought should be given anytime it’s used. More often than not, used as a joke, but a joke masking true problems.

Some issues are unavoidable, some no amount a planning or preparation will help with; for those I can offer no advice. For those, even a perfect environment won’t help. It’s the others I care about, those issues that shouldn’t be, the deadlines that should never have been set, and those whose sole cause is lack of planning or forethought. Those are the ones that tire me; those are the ones I hate.

When I run into one of these situations, it makes me wish this was closer to reality than a dream of how we want things to be. However, why shouldn’t it be reality? Why do we allow this to happen time and time again?

Wait, read that last sentence again. Why do we allow, why do we allow? Yes, as developers we allow this to happen, and often encourage it. Late nights, working weekends, 90-hour weeks. Those could all be prevented, and could be reduced significantly should we stand up. If we do not take a stand, we encourage those that push us too far by doing just what they ask. Why should they stop if they can get a single developer to do the work of two?

A Solution?

So, what are we to do? Taking a page from Rob, here is my modest proposal. A few simple rules for both developers and managers to keep in mind. While rules such as these can never be enforced, keeping these things in mind could make life more pleasant for everybody.

Managers…

• shall keep requests for after hours work to a minimum. While there are “crunch times” on occasion, these should be minimal.
• shall seek input from at least one developer before estimating a project. An estimate should not be created without consulting those that will be working on it, as they should have the most realistic idea of how long it will take to implement.
• shall not ask developers to implement a hack or kludgey solution to meet an unreasonable deadline or request; especially if it will compromise stability or maintainability.
• shall understand that developers are often passionate about their work, and the quality of the software they produce. Asking a professional to implement a solution based on a bad design, or inferior technologies will often be viewed as an insult, especially when this is done to meet an unreasonable goal.
• shall shield developers from unnecessary distractions and meetings. Distractions can destroy productivity.
• shall not ask developers to do the job of a Support technician. Tasks such as installing or configuring third-party software should not be given to a developer.
• shall filter all requests and put policies in place to ensure that requests do not go directly to a developer.
• shall give developers the freedom and opportunity to test different development methodologies when the schedule allows.

Developers…

• shall make every reasonable effort to complete a task, including working long hours (so long as the hours and frequency are reasonable).
• shall not complain about boring or undesirable tasks.
• shall alert management when an issue arises that may impact a deadline, as soon as possible.
• shall build the best software they are able to.
• shall provide accurate estimates when asked.
• shall be available as much as possible should an emergency arise.
• shall not over-build, or over architect just for the sake of doing so.
• shall try to understand the pressures and forces at play when communicating with management.
• shall make an effort to improve development methods and processes.

If you agree with this last, take it to your manager and talk about it; if not, build your own and talk about it. Either way, the idea is to talk about the issues and try to find ways to get everybody on the same page. If we make no effort to improve things, then we are just as much a part of the problem as anyone else.

If you don’t like things, complain; but complaining to a friend or co-worker won’t help, you need to let management know that there are problems and that you have some ideas to fix them.

Looking for a bit of a speed boost? OpenDNS might just help. Using the OpenDNS network, instead of your ISP’s DNS servers seems to really boost the speed of the name resolution process (which is often the slowest part of connecting to another computer).

From what I’ve seen so far, there’s been a fairly significant speed boost on some sites, primarily those that include content from several domains. The boost isn’t that great when you look at the overall loading process, but it does reduce the annoying lag when the browser starts loading. So far, I’ve been happy with the service (which is free), and I really like that the offer various customizations and statistics (if want want to open an account, also free).

On top of the various options and statistics, they also offer spelling correction and anti-phishing features. It may just be DNS, but this is DNS the way it should be done. And if that’s not good enough, even Matt likes them.

You mileage will obviously vary, but I think this is pretty cool.

For those that have been looking forward to seeing the final result of Microsoft’s attempt at AJAX, your wait is over. ASP.NET AJAX 1.0 has been released.

I’ve not had time to test this yet, but it sure looks like it has promise. I’ll be playing with this one soon, I’ve got a couple new projects this might be perfect for.