After setting up a few different domains to use Google Apps (specifically Google Analytics and Gmail), I've found a few best practices and an order to make the process go a bit more smoothly.

Before we get started, I'm assuming that you have a domain name set up with the registrar of your choice.  If you don't have any preference, I'd suggest you use GoDaddy.  Their UI is horrific, but their prices are fantastic.  I've on occasion had to deal with their customer service, and they've been top notch.  I'm also assuming that you have the rights and the skills to edit DNS entries and add JavaScript to a website.  The latter isn't life-or-death, but you won't be able to use Analytics.

From here down, let's call your domain "mydomain.com".

1. Set up a new "root account" email  Even if you have an existing Gmail account, it's best to have an account dedicated to mydomain.com.  This is especially so if you have or maintain many domains, and are planning on moving them to Google Apps.  The big payoff for this is step #8 (below).  So,
   • Visit Google and sign up for a new Gmail account.
   • Hint!! Use [mydomain.com]@gmail.com as your Login Name.  This will keep things nice and tidy, and you'll never have to guess what your admin account name is.
   • Make sure to use a strong password and save it somewhere safe like VirtualKeyChain.com
2. Sign up for Google Apps  Creating your Google Apps account gives you access to all of the fun Google toys, like Gmail, shared calendar, and online spreadsheets among other features.
   • Visit Google Apps and pick the option that best fits your organization: small, enterprise, school, or family/group
   • Sign up using the "root account" email you created above, i.e. mydomain@gmail.com
   • For the Apps account, you'll need to create an administrator account login.  I suggest something very original, like admin@mydomain.com or administrator@mydomain.com.
   • Hint!!  It's easy to forget (or not notice) this, but you and all users can reach their shared domain Google page via http://partnerpage.google.com/mydomain.com
3. Verify your domain ownership  This step proves to Google that you are really who you say you are, and you do indeed have the rights to the domain.  Google has a good FAQ on what this is all about.  Follow the link at the top of your Google Apps dashboard that says "Verify your domain."
   • You can perform this verification by either creating an HTML file on your root website at mydomain.com, or by creating a CNAME record in your DNS entries.  Pick your poison, and follow the instructions.  Google will provide you with a unique CNAME or html page that you need to add to DNS or your website (respectively).  Hit 'Verify' once you're done.
   • The verification process may take 48 hours, especially if you use CNAME
4. Gather all existing email account information  This is important, as midway through the next step, you're likely going to lose access to your old mail server. 
   • If there is a way to export user names and passwords, do so.  If you can't do that, at least copy all of your email names to manually generate accounts in Gmail.
   • Send out a warning to all users to make sure to download/read all mail on their server
5. Activate Gmail  Before starting this step, make sure your client knows their email server is changing.  Once you set your DNS entries, the web will start propagating the change which will likely cause some confusion.  You'll notice that on your Google Apps dashboard, Email is the only application not activated by default.
   • Click on "Activate Email" and read the instructions for setting up your DNS entries for your MX records.  There should be around 7 MX records.
   • Go to your DNS manager and add those records as shown, making sure to delete any existing MX records you currently have.
     • You may not be able to set the priority exactly as Google suggests, but just get the order right, i.e. set ASPMX to the lowest (0, 1, 5, etc), then ALT1 & ALT2 to the next, and so on.
   • Click "I've completed these steps" and wait for Google to "see" your MX changes.
6. Add Email accounts
   • Using the information you collected in step 4 above, generate new users.  
   • Per RFC requirements, make sure to add postmaster@ and abuse@ addresses.  Because Gmail automatically (and quietly) listens to those accounts, you can only create these as "lists," but that's a preferable method.  When you create them, you'll see "Google Support" is already in the distribution list
7. Sanity Check: make sure you don't have any DNS issues  I'm a fan of the free DNS tools available on the web, my favorite being DNSStuff.com.  You can just type your domain in and get a report of all of the potential or real issues with your DNS records.  Since you just fooled with your DNS, it always helps to have a fresh check to make sure you didn't do anything "bad."
8. Sign up for Google Analytics  Outside of Gmail, Google Analytics is definitively the crown jewel in the set of domain applications.  What's very odd about this tool however, is a) Google does not include this application in it's set of applications for domains, and b) you cannot use a non-@gmail.com domain email address to sign up for Analytics!  This is why step #1 up above was so key.  You can now sign up for analytics using your mydomain.com@gmail.com account, and keep your stable of applications all together. 

Where are we now?  We now have a single Gmail account that serves as the home for all administrative communications on our Google Apps.  This isn't as simple as it sounds.  Although you could have used any old Gmail account, what happens if you want to give administrative rights to someone else you work with, or the client themselves?  You certainly wouldn't hand over your personal Gmail account login, but this is now an easily transferable object.

I sat up in bed this morning with a brilliant (read: retire-in-three-years) idea:

"A web site that allows you to exchange your unused gift cards for cash or another card!" I shouted out loud.

Quickly, I ran to my GoDaddy account and typed as if I was racing someone around the world for the same domain name...

"GiftCardTrader.com" I shouted.
"Taken.  Drats.  How about GiftCardExchange.com?!"
Uh oh.  0 for 2.

That last one sounded like a winner, but after visiting GiftCardTrader.com and finding nothing, I thought, just hoped, "maybe this hasn't been done!"  If GiftCardExchange.com wasn't taken, I might be on to something.

Whoops.  Damn.

Well, looks like in October of 2005, someone in the Midwest had the same idea and went live with what looks to be a great service, CardAvenue.com.  If you're like me and have a stack of cards that are to stores you have little interest in (really, who needs 3 gift cards to Red Lobster?), then give this service a whirl and let me know how it goes.

After all, it was my idea.

I'm running SQL 2005 client tools version 9.00.3042.00.  Every morning I connect to my dev server to run queries, analyze data, etc.  Despite checking "Remember Password," the MSSMS (horrible acronym, by the way) dialog refuses to remember the password.  This is by no means a show stopper, but it certainly is frustrating, especially if you use strong passwords.

If you're witnessing the same behavior, please tell Microsoft by voting "up" this bug, and they'll work the issue.

I do enjoy the NYTimes.  I also enjoy the NYTimes online site.  I don't however, enjoy having to logon, providing personal information just to get that content.  Two notes to online content creators:

1. if you think your content is very special, then make people pay for it and you'll see just how special your content is
2. if you think your content is kinda, sorta special, then don't make me provide you demographics just to get at your content

If you decide to lock down your content and make money, congratulations.  If you decide to collect demographics, you better make sure you test your users well, or at least check out BugMeNot.com to see if you're being gamed.

What's interesting is that the Times seemed to have a very special set of content, and I thought they would not stray from the pay-per-view model.  Interestingly, they decided to let their content go free tonight at midnight, realizing they will make more money from online advertising than pay-per-viewers**.

The best news is that they are also opening up their historical search tools.  Hooray!  I no longer have to keep the famous no-knead bread dough recipe in my safe deposit box.

**I wonder if the Times is going to start redirecting Firefox users who employ AdBlock extensions?

[Irony note: when I went to read the details about this article, the Times asked me to log on (see image).]

Now that the first software-only hack for unlocking the iPhone is in the wild, I have to wonder how Apple privately is  handling all of this.  Publicly, they have stated that they are neutral on the idea of 3rd-party applications, which basically applies to this software-only hack.  But I pose the question: if you could stop this hack from working, would you?

Arguments for blocking the hack

The money

The people at Apple most likely gnashing their teeth are the accountants, and Peter Oppenheimer most specifically.  Rumor has it that Apple has an agreement with ATT which earns Apple $3USD/mo for each iPhone subscriber, and $11USD/mo for each new (to ATT) iPhone subscriber.  Given that Apple just recently sold it's 1 millionth iPhone, and the ATT subscription agreement is for 2 years, simple and conservative math yields a 2 year income to Apple of $3MM/mo for the next two years, or $72M USD over the next two years.

$72MM is a fair amount of money, but more than just the end number, its a recurring revenue stream which is the holy grail for sustaining any business, large or small.  iTunes, for example, doesn't make a dime on the download of the client software, but rather earns money on each and every song purchased; every day; every month; for as long as iTunes is the dominant player in the legal online music download space.  Now that is a killer application.  And that is exactly why iTunes is constantly battling the likes of Hymn and SharpMusique. 

User experience

The phone I use is a 3 year old handset running an unbridled version of Windows Mobile 2003.  Behind closed doors, you could certainly get Microsoft to admit that WM2003 has significant flaws, the most glaring is that it doesn't tell how much battery life is available on the main screen.  For the first six months with this phone, I would gamble taking the handset on an overnight without having a charger available, as it's a bit of a battery hog to boot.  The only available option to this problem was to purchase a 3rd party tool that displays the battery information right on the screen. 

The solution is elegant and provides better feedback from the phone, but it also has it's issues.  At it's root, the solution significantly alters the UI and the experience I have with the phone.  For someone like Apple, who worked so hard to create a specific experience, this might just be the reason to extinguish the hack. 

For example, one of the iPhone's five main sales points was visual voicemail.  With the hack (and service with someone other than ATT), this feature is gone.  Additionally, Steve Jobs specifically mentioned his concern to having 3rd party applications on the iPhone in a NY Times article, for fear that you load "three apps on your phone and then you go to make a call and it doesn't work anymore." 

This hack should be driving the industrial designers in Cupertino completely batty.

Arguments for leaving the hack alone

Market share

I propose that a sexy piece of hardware, such as this, or the XBox 360 will have an inherent market regardless of the functionality or price.  If it can be hacked, I would suggest that you're going to get a perceptible bump in sales directly proportional to the ease of the hack implementation.  Engadget describes how a hackable system (XBox 360) can lead to tangential sales (DVD+/-R), but I would argue that Microsoft also saw a bump in sales.  Was it a 50% bump?  Not likely, but even a single percentage bump in sales would be welcome in such a competitive marketplace.

I hacked my original XBox.  I didn't do it to copy software, but rather to run all of the great 3rd party software developed for the hack, such as MAME.  As a matter of fact, that hack was the primary reason I purchased the XBox versus another game box.

The petri dish of 3rd party applications

One of the largest complaints leading up to the launch of the iPhone was that it lacked the ability to run 3rd party applications on the handset.  Although Jobs is worried about 3rd party apps, he's not entirely against the idea either.  In my opinion, he shouldn't be.  The Palm used to be the undisputed champion of the handset market not because it was sexy, but because it had the largest number of 3rd party developers writing software for the OS.  Heck, this was exactly how Microsoft beat Apple in the personal computer business of the '80s and '90s.

Although Jobs thinks Safari is an acceptable sandbox to write all of the applications to run on the iPhone, that idea is flawed in that it inherently allows application portability, which the Palm OS applications didn't.  In other words, if Microsoft can (finally??) get a handset and OS to the market that is stable and has a web client that doesn't suck, all of those web-based apps will suddenly and transparently work on that handset as well.  Facebook?  Check.  YouTube?  Check.  NYTimes?  Check.  How about a portable iTunes client? 

What this hack (more specifically, the underpinnings of the hack) allows is the ability for the millions of creative minds to do more in months with the iPhone than the thousands of Apple developers could do in years.  Specifically, all those disenfranchised Palm OS developers can now find a new OS to start porting their previously hot-selling application to.  It's a win-win solution for Apple.