Just Say No: Home

Moving Google Mail, Calendar, Reader and Talk into Google Apps

Sam Phillips, February 17th, 2008 6:40 pm

For some months, a note has existed on my backpack to blog about moving to Google Apps - to provide what I needed when I moved; a definitive guide. Unfortunately, there have been one or two snags along the way, and I moved my email, my calendar and my google talk account, but with limited success. Here’s some of the tips I picked up along the way, and some of the frustrations for which I await a fix.

Email

My first problem was email. I was moving to Google Apps from a normal Gmail account. The migration was simple - I set up IMAP on the Gmail account and added it as a secondary account on the Google Apps account. This works just fine, although it is slow - very slow. It took nearly a week for all 239 mb of my email to be transferred over. So here’s a top tip - decide you’re going to move, set a date, and some time before that, lay the groundwork by starting this process.

Note: At work, we have used the Google migration tools which are available with more non-free versions. This process was significantly quicker at migrating our current IMAP mailboxes over.

I then switched my old Gmail account to bounce to my new Apps account, and all email bounces through happily while I gradually update the places where that address is stored. This also has the added advantage of filtering some spam out, which is nice, but not really a great concern as Google’s spam filtering is by far the best.

So it’s all going well; my Google toolbar is signed into the Apps account, and I hit the red mail button. Oh dear - it’s asking me to register the email address I’ve just created on Apps as a Google identity for a Gmail account - an account that could never receive email. Fair enough, I thought, and closed the window.

A couple of days later, I installed the Google notifier on my Mac - this worked fine with email being on Apps. The Mac dashboard widget, however, did not. I completed my account details and it complained the account didn’t exist. I clicked through to Google to find that it had set up a new Gmail account for the Apps email address, without even asking. And to add insult to injury, the new account was Gmail 2.0, which I still haven’t had rolled out on any of my Google accounts, at work, at home, anywhere. Wasn’t impressed.

So to summarise; Notifier on Mac works with Apps, Toolbar on Firefox Windows goes mad. And so does the dashboard widget. Clearly, Google is missing a link in some of its products which would allow them to identify and differentiate between Apps and non-Apps services.

Calendar

My migration from normal Google Calendar to Apps Calendar was simple enough - I shared the old calendars with the new account, and will use them for archive purposes. Again, Mac notifier works just fine, again the Firefox Google toolbar failed miserably. Click the calendar icon, and a page opens up:

Oops. A calendar already exists for xxx@xxx.com

(Email address censored by me)

Oops indeed. But don’t worry, Google will bounce you to the right page:

Go to your null calendar

New invitations sent to xxx@xxx.com will be added to this calendar. If you have an account at null, you can sign in at:

http://calendar.google.com/hosted/null

Maybe not. Apparently my null calendar is where it’s at - if I have an account at null, I can access it. Clicking that link (just for amusement, obviously it wasn’t going to work) brings up an error page - an error page that gives a 200 status code, no less. Win.

So it seems that in this instance, Google tried to help me out when I clicked into a calendar that shouldn’t exist, but the good intentions were let down by some buggy code. This is better than mail, which doesn’t realise that an Apps account exists for the domain, but still not perfect.

Reader

Google Apps doesn’t include Reader, so I ended up setting up a normal Google account with my main address on my new Apps domain. Perhaps this is what broke the calendar and mail. Migrating the subscriptions was easy - simply export as OPML on the old account, and import on the new. Done.

IM - GTalk and MSN

I didn’t bother migrating contacts with talk - I just added them again, both in Google talk itself and MSN (having set up my new main address as a M$ Passport). I like this exercise - it allows me to ditch contacts I never speak to. It also provides an interesting acid test - will people add me again? Fortunately, all did. IM was therefore back up and running straight away.

Imified/Twitter - Again, my Imified setup didn’t merit migration. I added the contact in MSN and had it going in a few minutes or so. I also added both Twitter and Imified to my new Apps GTalk account. No love. Not a jot - in fact, this opened up a world of pain.

I tackled the problem from the Twitter angle - basically, for the xmpp/jabber stuff to work with non-google talk services, you have to add some SRV records to your domain, and there’s a few very useful pages out there on sorting this out. To summarise them, at the moment my understanding is that the full SRV breakdown is as follows:

_xmpp-server._tcp.yourDomainName.com. IN SRV 5 0 5269 xmpp-server.l.google.com.
_xmpp-server._tcp.yourDomainName.com. IN SRV 20 0 5269 xmpp-server1.l.google.com.
_xmpp-server._tcp.yourDomainName.com. IN SRV 20 0 5269 xmpp-server2.l.google.com.
_xmpp-server._tcp.yourDomainName.com. IN SRV 20 0 5269 xmpp-server3.l.google.com.
_xmpp-server._tcp.yourDomainName.com. IN SRV 20 0 5269 xmpp-server4.l.google.com.

_xmpp-client._tcp.yourDomainName.com IN SRV 5 0 5222 talk.l.google.com.
_xmpp-client._tcp.yourDomainName.com IN SRV 20 0 5222 talk1.l.google.com.
_xmpp-client._tcp.yourDomainName.com IN SRV 20 0 5222 talk2.l.google.com.
_xmpp-client._tcp.yourDomainName.com IN SRV 20 0 5222 talk3.l.google.com.
_xmpp-client._tcp.yourDomainName.com IN SRV 20 0 5222 talk4.l.google.com.

_jabber._tcp.yourDomainName.com. IN SRV 5 0 5269 xmpp-server.l.google.com.
_jabber._tcp.yourDomainName.com. IN SRV 20 0 5269 xmpp-server1.l.google.com.
_jabber._tcp.yourDomainName.com. IN SRV 20 0 5269 xmpp-server2.l.google.com.
_jabber._tcp.yourDomainName.com. IN SRV 20 0 5269 xmpp-server3.l.google.com.
_jabber._tcp.yourDomainName.com. IN SRV 20 0 5269 xmpp-server4.l.google.com.

But still, it doesn’t work. Twitter has experienced a lot of technical issues recently, and it’s easy to use a broad brush and suggest this is their fault. But Imified doesn’t work either, and all the debugging suggestions are fruitless.

So that’s it! I can’t get federated services for GTalk to work, and Google seems to be unable to lookup the names of its own Apps domains, meaning you are bounced to strange error pages and Gmail accounts that will never receive mail! But generally, it’s a pretty easy process and for the sake of consolidation, it’s worth it.

Now I just have to get openID working…

I’m sure the makers of BBC iPlayer have been waiting for me to say this…

Sam Phillips, January 27th, 2008 6:57 pm

Obviously, the makers of BBC iPlayer were initially distraught when I suggested, a couple of months ago, that their terrible product was re-defining the low bar when it came to beta software. The availability of programs was poor, the website was strange and required a seemingly-endless stream of passwords and identity checks, and the iPlayer software (read: DRM-enforcement SS Unit) was 6.64 megabytes of pure fail.

Clearly, the gauntlet was thrown down. I can visualise the events now as I had been there. And as if they had actually happened. First, the iPlayer team was excited about the blog post. Finally, they thought, the internet is taking notice of our betamax*-level technology. Then they read the post, remaking at the quick wit and the ever-thoughtful user comments, and were beside themselves. For nights, they lay sleepless. After a few days, they picked themselves out of their pit of despair and came up with a stunning idea, a spark of originality which would change the internet.

Hold on, cos this is complicated: They realised that what they should do, rather than making people download software that looks like it came from Astalavista and didn’t work, is stream the content straight from the website. That’s right. I couldn’t believe it either. As Steve would say, this is man-on-the-moon level invention. I can’t believe nobody ever thought of this before.

In all seriousness, the product that iPlayer has become is better and is actually worthy of being released to the real world. And of course it’s right that they released something early and waited for feedback, rather than keeping the product in development for years without working out what people want. And yes, they have responded quickly to the fact that they had produced a pup.

But you just think that they should have guessed that streaming online was the only way forward from the outset. It’s not like the path hadn’t been paved already. But, dear iPlayer engineer, here’s what you’ve been waiting for. “Well done”. Now get back to work - start by taking those stupid red boxes off the BBC News Homepage.

* And yes: I know that in some ways, Betamax was superior technology. But it still got sent to Failsville, which is where it sat, waiting to be joined by the initial iPlayer platform.

MacBook Pro vs MacBook Air

Sam Phillips, January 17th, 2008 7:40 pm

The launch of the MacBook Air this week re-opened a can of worms for me; should my new laptop be a Mac, and now that Air is here, should I choose it over the MacBook Pro which I have previously considered my best choice?

The Mac vs Windows issue is still not solved for me. Ever since my G3, which was found in the lobby of our building with “free to a good owner” taped to it, I have been very impressed with the OSX interface. It is easy to use, and it is progressive. And it does what it does so much better than Windows. The appeal for me was clear.

Of course, Apple’s attack is part cool, part beauty and part ease of use - the latter is what mainly attracts me; but people tend to think of you as gullible if you even suggest that coolness and beauty are something to be attracted to. Yet the fact is that people like me spend a lot of time at computers, and having them be a nice play to be is no bad thing; in fact it’s a great thing. And the fact that they’re ideally suited to web development just adds to the allure.

So what to get? Well, the “same [old] lovable MacBook” isn’t going to cut it, so I’m stuck between Air and Pro. A friend told me I should “go pro, fo’ sho’” (he like me, is so totally ghetto it’s unbelievable), but it’s not that simple. Here’s the comparison in brief:

MacBook Air

  • Light and small.
  • Base processor is a 1.6 Core 2 Duo.
  • 2 gig mem
  • 80 gig hard drive
  • 5 hours batt
  • No SuperDrive
  • 13 inch screen
  • £1,199

Macbook Pro

  • Still pretty light and pretty small.
  • Base processor is a meaty 2.2 Core 2 Duo
  • Extensible 2 gig mem
  • 120 gig hard drive
  • 6 hours bat
  • 15 inch screen
  • SuperDrive
  • £1,299

Until I realised today that the prices were so similar, I was sold on Air. It’s a good deal compared to the pretty (but not as usable) Vaio TX, but it’s clear from the £100 difference that you’re paying for the portability both in terms of cost and in terms of technical specifications. And let’s not forget, when talking of tech specs, that the equivalent Dell laptops are fat, expensive beasts. The bigger Vaio models are nice, but not as nice as Mac. Then again, they are quite a bit cheaper. But they’ll have Vista on them - and the advances that Vista represents over XP are few, especially after you’ve had to turn off all the fancy graphics affects because they overload your system.

So anybody considering buying an Air has to ask themselves “really, how important is the ultra-portability to me”. I think for most people used to lugging around a Windows laptop, the answer will be “not very”, especially considering the improvement in portability that a Pro represents over these clunky machines. If the Air was £800, I would consider it. As it is, it’s MacBook Pro all the way.

Of course, I’ll change my mind again tomorrow. Fo’ sho’. Ho’.

The BBC’s rote teaching techniques

Sam Phillips, January 3rd, 2008 7:19 pm

It seems like almost every week there’s a story on the BBC news site about social networking being used by identity thieves to glean personal details.

Perhaps “every week” is a bit of an exaggeration (those are the only links I could find in one Google search. On its first page), but it really does feel like the media are all too delighted to jump on these tales of impending doom, hand-delivered to them by whichever security/censorship firm has issued a press-release.

This is not news; it’s pummelling the same story at people over and over again. I thought we moved away from Victorian schooling models and rote learning. Enough already.

Five reasons why you should use SVN for one-man projects

Sam Phillips, December 30th, 2007 8:36 pm

Often, when people are talking about version control systems, such as Subversion, an oft-quoted reason for its usage is the advantages it brings to collaborative working. This is with good reason - the system was written with the “many developers working on the same project” situation in mind, and this is why locking and merging et al is so important.

But version control is just as useful for smaller and/or personal projects - and as I’ve come to realise over the past week while getting to write more code than usual, using it can bring some major advantages to developing the “other” projects.

  1. Firstly, the no-brainer. Using version control means that you can roll files back. Large projects are planned and ideas are specified, and version control is often used for bug squashing and correcting mistakes. I find that it is less frequently used to “turn back the clock” on major portions of code (because they were just going in the wrong direction) because this situation is largely eliminated by planning. When I’m working on smaller projects at home, I’m often making it up as I go. It’s a good and productive way to code when you just feel like writing something, and are on your own time. Being able to roll back whole portions of the project (especially in Rails, using migrations) is a great way to allow yourself to experiment, knowing that even if you make some dodgy code decisions, they can always be rolled back.
  2. No need to trust yourself. I have always had a pretty good memory, not only for trivia, music/lyrics and names/faces, but also for code-related events - I can often recall when changes were made, at whose request and by whose hands. I’m a pretty good resource in the office in that way - but I am also very wary of reliance on memory. My mantra is to never trust yourself, and to use external systems to remember things wherever possible - à la GTD. Committing changes to projects via version control and always making sure I leave a long and descriptive comment means that I don’t have to rely on my memory when I come back to the project - perhaps days or weeks later. This means that coding at home can be what it should be - relaxing.
  3. Practice makes perfect. Using version control comes naturally after a while, especially in languages that are well-suited to it, but it’s still a skill that you need to work at. I like learning how to use some of the more advanced features at home so that, again, I’m on my own time, breaking my own projects. Using version control at home means that I’m continually getting better at it, rather than considering it a burden to be left at the office.
  4. Anyone who says version control doesn’t make life easier isn’t doing it right. Once you’ve moved into version control for some projects, everything else you work on feels rustic and lame. Developing under version control creates what appears to be overhead in the form of commits and maintaining working copies, but this is easily offset by the security it provides. Often I code late into the night (when it’s not a school night!) and by three or four o’clock, I can never be sure that the code that’s coming out is good. Under version control, this doesn’t matter. Wake up in the morning and revert the crap files, and keep the good stuff that only twilight hour inspiration can bring.
  5. Optimism. Under version control, you are taking every project seriously - this is a good thing, and it’s optimistic because you are telling yourself this is an important undertaking that may yet be something big, or at least something that helps some people out in some small way. And let’s not forget that version control works best when a project is born into the environment, rather than transplanted in later. Believe your work will be great, get it into version control from the beginning and let that experimentation that’s only possible with personal projects run free!

For big projects, I consider not using version control to be nothing short of negligent, because mistakes cost jobs and mortgages. For small projects, it is a great bonus feature, and allows experimentation and messing around to be easily coerced into something usable and maintainable.

Next Page »
Subscribe to this blog's RSS feed

On Twitter:

  1. Loading...

Follow me >

Previously Rejected:

  1. Moving Google Mail, Calendar, Reader and Talk into Google Apps
  2. I’m sure the makers of BBC iPlayer have been waiting for me to say this…
  3. MacBook Pro vs MacBook Air
  4. The BBC’s rote teaching techniques
  5. Five reasons why you should use SVN for one-man projects
  6. The only limit to identity theft is the thieves themselves
  7. BBC iPlayer: the return of ‘beta’
  8. I eat Wheetos for breakfast. Firefox prefers to gorge on RAM, all day.
  9. Images and subjective influence in online news
  10. Ten Comments on the A List Apart 2007 Web Design Survey
  11. Television is not real; keep it that way.
  12. Radiohead and In Rainbows: Not free, not new.
  13. Lover, not a fighter
  1. Bookmarks:

Valid XHTML 1.0 Transitional Valid CSS!