Who needs standards?

I've matured enough in my career that I don't generally spout off against Microsoft unless there's a really good reason.

I have a really good reason.

The company I work for uses Exchange server to handle their mail. I don't use Windows, so I don't use Outlook. I use Thunderbird, which is an excellent mail client. The problem is that Thunderbird doesn't directly support any of Microsoft's not-quite-standard ways of accessing Exchange server directly. So my company IT department, bowing to the inevitability of Linix and Mac OS users, has turned on IMAPS and smtp with ttl to support us non-Outlook users.

The problem is that the IMAPS implementation is horribly slow. I keep my email inbox trimmed to less than 100 messages. In order to do this, though, I have an Archive folder that has thousands of messages. Moving 50 messages from Inbox to Archive can take 3 minutes--an unacceptably long time. Moreover, opening the Archive folder can take more than 5 minutes, despite the fact that the folder index is locally cached.

These issues aside, though, it's the sheer inconsitency of the performance that drives me truly insane. Usually, mail flows into the Inbox just as you would expect--a new message arrives, you click it and you read it in the preview pane. Sometimes, though, you click it and the preview pane doesn't get updated. You have to click 'Get Mail' and have the message fetched again before it will really show up.

Because I manage people, our Oracle system sends me emails about their timecards. At the very bottom of these emails are handy links so that I can approve or reject a timecard without having to log on to the Oracle web interface. 75% of the time, the entire message cannot be retrieved from the server, and I can't see these buttons. Not 100% of the time, mind you--75% of the time. It's not like the message is significantly different from one time to the next--in fact, they're invariably exactly the same expect for dates (salaried employees).

There are numerous other headaches, all related to IMAPS and all truly annoying. I've never encountered this many annoyances when working with a bog standard (as defined by the IETF) IMAP or IMAPS server.

Virtually weird...

We're using virtual machines, created and managed by Virtual Box, to create a test environment. Rather than have multiple machines that mirror the multiple deployed machines, we're creating three machines on one hardware platform. It's a common model and an excellent example of how Virtual Box and tools like it can be used.

There's a lot of parading about with regards to virtual machines. There's a common belief that virtual machines are a panacea--a way to consolidate multiple pieces of hardware onto a single hardware platform. The battle cry is raised because this is seen as a way to save money by reducing the amount of hardware. Organizations are jumping on the bandwagon and joining the parade in droves. But does it all make sense?

There are certainly situations in which having virtual machines not only makes sense but saves money. The situation we're involved, for example, is a classic case: rather than replicate a bunch of deployed hardware, we're using virtual machines to replicate a deployed environment for experimenting and testing. Before jumping into virtual machines with both feet, though, you need to ask yourself a few questions:

1) What problem am I trying to solve? If it's money, realize that virtual machines may only give you the appearance of saving money. We'll get to the reason in a moment.

2) What am I expecting? If you're expecting multiple virtual machines to have bare metal performance, you're going to be disappointed. Set your expectations up front.

3) Do I have a battle plan? It's nice to think that installing Virtual Box or VMWare is the answer to all your problems, but you'd best be prepared for the eventuality that things aren't going to work out the way you think.

Saving money shouldn't be anywhere near the top of your list for implementing virtual machines. You need to have a hardware base that's highly available and extremely reliable, otherwise, you've just created a huge, single point of failure. You also need hardware that's powerful--more powerful than if you used a single machine. A single platform that will handle, for example, a web server vm and an SQL server vm would probably cost you more than two pieces of hardware capable of running each function at the required level. Furthermore, if you're going for reliability, you may want separate machines anyway--multiple web servers, for example, add a level of robustness that you simply won't get from multiple virtual machines.

Don't just join the parade cause it looks good and is going by. Think first, then join in. It is really a lot of fun.

Tuff as nuts? Really?

I'm on my third Nutshell case. The case I ordered for my new Nokia E65 just arrived and it is exactly as I expected it would be: perfect.

Here's the thing. I got my first Nutshell case years ago for my Palm TX. I researched long and hard before I got that case, and I loved it. My second case was for my now-retired Blackberry. I also researched that case long and hard. You'd think I'd have learned, but when I got my E65, I researched long and hard again. Next time, I'm just going to order the appropriate Nutshell case at the same time I order my next phone.

Why? These cases are darn near perfect. Each case is individually hand stitched from a single piece of high grade leather. The interior is softly lined--no scratches on your gear. The belt clip is firmly embedded in the case and is heavy steel. Anything that gets the case off your belt is probably going to take the belt and part of your hip, too. I've never worried about the case falling off. I like the D ring on the belt clip--it's handy for clipping the phone to the strap on my laptop bag.

Really, these cases are bombproof. I've used the belt clip on my last two cases, but my first case had the belt loop. I liked it, but it was a bit of a pain because the belt has to be threaded through the loop. The clips just attach and go--you don't have to take your belt off to put the case on.

If you're protecting an expensive piece of kit, these cases cannot be beat. They are a little pricey, but if you Google around you can sometimes find discount codes. I'd publish the one I've used, but I don't know if Nutshell would like that.

Highly recommended.

Communication is key...

When teams are geographically dispersed, communication is key to a successful operation. When we talk about communication, we don't mean email. Email is an interrupt and a time-waster. You have to learn to manage email, and one of the keys is to be prepared to ignore it for long periods. That's a topic for another post, though.

Real time communications are key. Your team members need to have access to each other whenever tasks are being performed. It may be early in the morning or late at night. The reality, though, is that having at least two people on a task makes the task go easier, so communication is key.

Here, we use OpenFire, a Jabber based server, to facilitate instant messaging. OpenFire allows both individual and group based chats. Getting instant feedback on questions is invaluable, and using OpenFire gives you just that.

If you don't want to go to all the trouble of putting up your own Jabber server, Google Talk is a great alternative. It's free, works from a web client, does voice, and has Google-level reliability. It also works great with Pidgin, a cross platform, open source client.

If it's not documented, it didn't happen...

Fortunately, I didn't have to make much of an argument for documentation in Project Recover. I told the company owner that we'd need a couple of hours up front to document the existing system. At first, he grudgingly agreed to the hours, saying "Well, if you need it". I told him that I didn't need it--he did! I pointed out that the reason he brought me in was to get things set up so that the people he hires to maintain his systems can do it with minimal ramp up. Documentation is the way to make that happen. Every system and process needs to be documented. Without documentation, there's no way to ensure that you're being consistent in how you care for your systems.

The tool we use for documentation is MediaWiki, the same wiki software that powers Wikipedia. It's a drop in wiki that's incredibly easy to install and, for our purposes, incredibly light weight. We found a machine that's underutilized and installed MediaWiki. We then began the process of documenting all of the systems.

Project Recover Underway

I've been hired by a small company to help them recover from a SysAdmin termination. That is to say, their SysAdmin left them and left behind a poorly documented setup that's incredibly hard to figure out and, as a result, even harder to maintain. I'll be blogging some of the steps I'm taking to get them back on track. In the course of all this, I'll be talking about some of the tools and techniques I use in my daily work.