Google Apps Migration

I'm midway through a migration of my GTD system to Google Apps. It's been a bit of a challenge. Here's what's been accomplished so far, Phase 1 was to migrate my electronic services:

• Migrate domains bwatkins.com and bnlventures.com to new registrars. My old registrar was the same as my hosting company, and it turned out I wasn't able to create custom DNS records with them if I also didn't host my email and website with them. This was more stressful than it needed to be, because I had taken the time to talk with their support staff and was assured I could still control my domain on the free parking account. They were wrong.  Or maybe they just didn't have the same definition of "control" that I had.
• Migrate email to Google Apps Mail.  Their free level of service now includes custom domain names, so I could keep "@bwatkins.com" for my email addresses. On the old service, I had actual mailboxes for various uses; on Google Apps Mail I just created aliases for all of these but my main email address. I only created all those boxes as an anti-spam measure; Google's spam filtering seems to be good enough that I don't need to do that any more.  I'm slowly working through the list and changing my address at various sites to use my primary again.
• Migrate blog from Typepad to Blogger. This, too, was a challenge, until I discovered a tool that let me convert my Typepad export file to Blogger format. I was able to import most of the content including comments.  I imported without publishing, then went through the posts to decide which ones I wanted to leave behind.

I'm currently in Phase 2, which is to convert my paper planner into Google Apps. Here's what I've done on that:

• Migrate my calendar to Google Apps Calendar.  I now have four calendars to maintain:  my paper planner, my work Outlook calendar, a scheduling system my employer uses (which doesn't sync with Outlook so I have to do that manually), and now Google Apps Calendar. I spent the better part of a day synchronizing all four. I also jotted down some process notes on what to do when changes happen. Four calendars is insane: but it will get better.  I'll eventually replace the paper planner with occasional printouts from Google Apps Calendar, and I've been told that the scheduling system will eventually be able to auto-update Outlook.  So I'll only have two.  I wish it could be one, but given my employer's policies, it's not gonna happen.
• Migrate my GTD review lists -- Projects, Someday/Maybe, and Waiting -- to Google Apps Docs. I typically only review these once a week, so it wasn't a big impact on my daily workstyle to move them. Bonus: I can now review and update them while on the road; before they were in Excel documents on my desktop at home.

The hardest part of Phase 2 is still ahead: migrating my Action Lists. Although some say that Google Apps Calendar's task list is not powerful enough for GTD, I like the minimalist approach of simple lists. I've created separate lists for each GTD context ("Calls", "Errands", etc.). My next step is to dump all the items in my paper Action Lists into this structure.  I don't know if I will feel constrained by having to be online to look at my action lists. I may have to do an occasional printout of them. I'm not sure how this will work, and it may be that I'll have to re-engineer this later.  But I want to try the simple way first.

Phase 3, and where this is all heading, is that I plan to upgrade my plain phone to a smartphone in a while. At that point, I'll have all this information sync'ed on a regular basis and be able to carry it with me. The work I'm doing now may seem odd from a paper planner viewpoint, but it is laying a foundation of moving all my planning information from PC to the cloud, so once I get the smartphone it will all be in place and ready to switch over.

Database Sharding

I discovered a new term today, via a useful post on Julian Dontcheff's Database Blog (which I also discovered today). His post, Do not go beyond this point: on the "obvious advantages" of Database Shards, succinctly describes what database sharding is, and even better, points to three resources for deeper study.  He writes:

Caution! Database Sharding is like the anti-consolidation of databases. It is splitting the database into many small databases. You spend years and years on trying to unify and gather together databases and all of a sudden you are told that there is an application managed scaling technique using hundreds of independent databases. Tricky, right?

Sometimes, when planning database solutions in terms of scalability and massiveness, going beyond a certain point might be risky. This is the case when database shards may be of huge help (big website used globally). The word shard may sometimes refer to a piece of glass, a sea glass that can be found almost everywhere, for example at the beaches near San Francisco.

I share his amazement that after years of listening to vendor sermons on the benefits of server consolidation, now there's talk about going the opposite direction. Whatever happened to "green" in the data center?

He also makes the excellent point that proponents of standing up many servers with small databases typically ignore database licensing fees, which are typically charged per server (sometimes per core).

Anyway, good read.

Always Learning - Rebooted

I've just spent a painful few weeks with my blog down as I changed hosting companies. But Always Learning is back, with only minor changes.

I dropped the Business Travel Tips category, and also removed some of the older announcements that are no longer relevant.

Another announcement is that my business, B. Watkins Database Training and Consulting, is no more. The domain name bwatkins.com has reverted to my personal use. Email addresses should all still work, and the blog will continue to be at this address.

I have plans for new articles on areas of personal interest, such as resiliency, change management, training, Getting Things Done (GTD), and of course, Oracle.  Please stay tuned!