Alec’s geek blog

I attended the Google I/O conference last week, and like everyone else there, was given a free Android Phone. I guess this thing is called a “Google Ion” but it is made by HTC and runs Google’s new mobile platform, Android.

This is an incredibly smart move by Google – we each paid like $400 to attend the conference and each got what appears to be a $200-300 phone. Conference attendance alone is an auto-selecting function – the fact that we even attended the conference means we’re already buying into Google’s story at least at some level. I’m sure most people will play with it, let the 30 days of free service run out, and then either put it in a drawer or sell it on eBay. But even if 1% of the attendees go and try to write an app for it, that’s a huge win on google’s part.

(And I sure hope that people don’t really put this in a drawer – it really would be better to have these things flood eBay and get redistributed to people who want them rather than slowly depreciating)

As for my review: I already have an iPhone so I wasn’t exactly in the market for a new phone, and I’ve also been fairly content in Apple’s walled garden of iTunes and iPhone Apps. I use my iPhone easilyi 2-3 hours a day for music, podcasts, twitter, games, and of course as a phone.

The last bit has been the biggest surprise – this phone, like so many smartphones before it, is really focused on being a phone above all else. Yes, it has an html5-compliant web browser, and yes it reads my e-mail, but I still don’t know how to sync this with my mac, which has all my contacts, calendar, etc.

As one example of how this phone is just missing the basic point of being a multifunction device, the Ion has just a single mini-USB plug, and no headphone jack. This means I have yet to try to use it for music or podcasts, which is probably the biggest reason I carry my iPhone around. I mean I’m sure this has an amazing application for getting podcasts, but I don’t even have a way to listen to them on this yet! The phone did come with some goofy headphone + headset that plugs into the mini-USB jack, but I have my own set of Skullcandy headphones that I’m not really interested in replacing.

All of this said, the user interface is nice. I can see that there is some support for running multiple applications, and I’ve heard its somewhat stack-based (so that one running application sits “on top” of another running application) but sometimes I’m not sure if I’ve got a few applications running, or not. I don’t know what happens when I hit the Home button (or the back button a few times) – am I leaving potentially battery-draining applications running? Am I overthinking this?

Overall I think this thing has promise but still feels a little clunky after using the iPhone. It lacks some of the simple effects/transitions that give the phone a more polished feel. These are the kind of effects that have absolutely no practical function but do make the phone feel modern. Even switching orientation feels like something from 2005 – it blurs slightly, fades out, and then fades back in with the orientation swapped.

I absolutely love the idea of running linux on the phone, but as a developer I have zero interest in writing Java, so I hope the Python support is good.

I’m going to keep playing with this but so far it hasn’t one me over.

At Google I/O today, I got to watch an hour-long demo of the new Google Wave. From everything I can tell, it is exactly what Chandler was supposed to be (well, minus a calendar, but I’m sure that’s basically just a plugin yet to be written)

I worked on Chandler at OSAF. Chandler is/was a sort of Personal Information Manager, or at least was inspired by the classic PIMs from the 80s, but juiced up for social collaboration. Honestly, Chandler meant many things to many people, which was part of its problem, but from my perspective, Google Wave encompasses many of those PIM/collaboration ideas that we worked on at OSAF. At chandler we were focused on the idea of an “Item”, which is very similar to Wave’s notion of, well, a Wave. The idea was that e-mail is old news – really it was all about updating the Item. Want to start working on a design document? Create an item. Let people collaborate in an object that got updated as people worked on it. Want to add coments as you go? Attach them to the item. In e-mail terms, it’s like a persistent, shared, dynamic attachment for an entire thread of messages, except even that doesn’t quite capture it.

Sitting through the first 30 minutes of the Wave demo, I thought “wow, been there, done that.” All of the examples they gave – from brainstorming about an activity to picking a movie to see to collaboratively editing a document, were all things that we hashed out over and over (and over and over and over) at OSAF. Hours of design meetings.

But I’m not writing this to say that Wave somehow stole these ideas or anything – I mean honestly once you throw SMTP, POP and IMAP out the door and invent your own protocol (yes, something we also tried to do at OSAF but using WebDAV, ugh) a lot of these ideas come naturally.

Ultimately, I really have to hand it to the Wave team because what they did, which is drastically different than what was happening at OSAF, was actually finish. One of Chandler’s biggest problems was that we spent way too much time designing, and not enough time making working, polished features that could be tested in the real world. To paraphrase, best was the enemy of completion. Chalk this up to 20-20 hindsight but even when I left OSAF, one of the reasons I found Metaweb so appealing was that the implementation of what was to become freebase.com was so complete, at least for an early-stage startup.

What I do know about Wave is that what they have accomplished is really, really hard, on a number of levels. Designing collaborative user interfaces is hard. Synchronizing fine-grained data streams is hard. I attended the “Google Wave: Under the Hood” and realized that at some level, Chandler had another problem beyond failure to launch: the problems were harder than we ever realized. We designed, and redesigned, and reimplemented, and redesigned again, synchronization protocols and data stream formats, and all sorts of craziness without any knowledge of whats out there. Sure, we could have had a few geniuses who pulled this stuff out of their hat but really there has been a lot of academic and non-academic research into these problems, and we didn’t even have the facilities to draw on them.

So kudos to the Wave team, I am truly impressed. At some level I’m probably more impressed than all the people doing the clapping and cheering during the demo, while I sat there with my sour grapes going “been there, done that.”

I’m on a quest: I want to learn iPhone development because I’ve got too many fun ideas for little apps. Nothing amazing, but I want to beef up my skills enough that I can whip out an app in a few days, if I’m so inspired.

So I’ve started learning Objective C. And man, it has its ups and downs.

I come from a C, and then C++ background – years of hacking on the Mozilla / Firefox codebase. Since then I’ve spent 4 1/2 years writing a lot of Python. I fell in love with Python within the first few weeks of learning it, probably because everything is just so much easier than it was with C++. I could throw together a very powerful little script in a matter of minutes.  I won’t go more into my love of Python because this is more about Objective-C.

My impression so far is that Objective-C is a unique hybrid of dynamic and non-dynamic languages. Yes, it is C at its core, so of course all the usual compile-time C issues and benefits are there, blah blah blah. But, the core language itself is fairly dynamic, including dynamic method dispatch and a healthy amount of introspection. Yes, you can look at an object and see if specific methods exist or not, and if so call them. You can call methods dynamically, meaning you can look up an arbitrary method name by string, and call it.

But in all of this I’ve only mentioned methods and not attributes. Objective-C does seem to suffer from the getter/setter disease that plagues Java, though it disguises them with the name property. This kills me. getters and setters drive me crazy because 99% of the time you want direct access to a object’s instance variable (an “ivar” in Objective-C), and the other 1% of the time the object wants to interfere with that access. Adding a wrapper around every attribute access adds an extra level of abstraction and frankly, code, that seems totally unnecessary.

Thankfully Objective-C 2.0 has some nice @property and @synthesize shortcuts that mean you’re not typing the getter/setter code, which honestly is half the issue.

I’ll post more on these issues later.