I hate your smartphone

When people talk about smartphones, they often mean iPhones and Android phones. Sure there are still Blackberries out there, I think I once saw a guy using a webOS phone, and Microsoft has 89,000 employees who have to use Windows Phone 7, but it's mostly an Android and iPhone world right now. If you have a phone running Android or iOS, life is pretty good. You've probably got a really powerful phone, with a huge number of apps and games to choose from. You've also got a web browser that's more advanced than the one used by most desktop computer users. So given all of those things to be happy about, why is that smartphone owners are so hostile to each other?

iPhones user love to look down their noses and make derisive comments about Android users. Not to be outdone, Android users never miss an opportunity to mock iPhone users. There is an obvious parallel here to Mac vs. Windows, but I think it's actually much nastier than Mac vs. Windows ever was. Here's a list of my theories (in no particular order) on why there is such animosity.

1. It's so easy to do. The truth is that both iOS and Android are deeply flawed. Going back to the Mac vs. Windows comparison, think about how much less mature these smartphone OS's are compared to Windows and OSX. So if you have any inclination to make fun of either OS, it's embarrassingly easy to do. This is where things really differ from Mac vs. Windows. There's not much to debate there. If you wanted to say "Mac sucks", there is a short list of things that you can point to. Not true for iOS or Android.
2. Social networking. In this day and age of social networks, your "friends" shove what they are doing in your face constantly. Smartphone apps make heavy use of this, as a way to spread virally. But what happens when there is an impedance mismatch caused by apps available on one OS but not the other? The folks with the unsupported OS get a little annoyed, and the other folks get an artificial feeling of 133tness
3. It starts at the top. Apple and Google both frequently take shots at each other. They do it at developer conferences. They do it when reporting quarterly earnings. It doesn't stop there. Motorola, Verizon, T-Mobile and others have all taken shots at Apple in commercials seen by millions.
4. Big decisions. You only have one smartphone (unless you are weird like me) and in the US, you usually buy it on a two-year contract. So you have to pick just one, and then you are stuck with it for two years. Thus if anybody is gonna suggest that you made a bad decision, most people will defend their decisions vehemently.
5. The Apple effect. So this really is straight out of Mac vs. Windows. Apple wants their products to seem elite and luxurious. They want the owners to feel like they have purchased far superior products, and feel that they (the user) is superior because of this. It's brilliant marketing, and it totally works. The air of superiority hangs over any Apple product owners, but especially iPhone users. So naturally any non-iPhone users are going to react negatively to the haute attitudes of iPhone users.

We All Love Music

Last week at Google I/O, big G finally delivered on Google Music. Well sort of. As many have pointed out, it's taken a long time to get Music out the door, despite it being announced a year ago. What is most interesting is that it comes after Amazon made a similar offering with its Cloud Drive/Player service. I have no used both services along with their Android apps quite a bit. So I thought I'd share my experiences, in no particular order...

• Uploading 4000 songs takes a long time. That's about how many songs I have on my MBP, and it comes out to a little more than 50 GB. I was one of the lucky attendees of I/O, so not only do I have access to Google Music, but it is currently free. Amazon gives you 5 GB, and 20 GB free if you buy an MP3 album. I did the latter. However 20 GB is not enough space for me, so I have not uploaded a lot of music to Amazon. I have done this with Google Music. It took many days, and it tends to wreck havoc on WiFi networks (which should be the subject a future blog post/rant.) 
• The Android players are good, but both have room for improvement. Google Music has a an instant mix feature, similar to the Genius feature in iTunes. I would say that it is better than Genius for several reasons. First, it seems to do fine with "non-standard" sings. I mean stuff like Girl Talk, or remixes and live versions of popular (or not) songs. Genius fails on this consistently, maybe because these are songs (or in the case of Girl Talk, artists) that are not in iTunes? Genius also fails for newer music. Google Music seems to do fine in this situation too. The Cloud Player does not have this feature, and that is a shame. However it does have an equalizer. This is something that Google Music lacks, and that is a shame. I generally find that mobile devices (and mobile headphones, if you will) especially need equalization. The Amazon EQ is not that great though, as it only has a list of presets (Jazz,  Rock, etc.) 
• I don't like listening to music in the browser. For desktop computers, both of these services have you open a browser and listen to music that way. I'd say that Google's is a little better, but they both seem clunky. The Amazon one does not have the equalizer that their Android app has. The sound on the Google one also seems a little better, which is counter-intuitive. It is my impression that Google may downsample your music during playback, based on bandwidth, whereas Amazon plays your music back as-is. Anyways, neither sounds as good as iTunes. Of course they aren't the ginormous mess that iTunes is either.
• Google Music works better over crappier networks. It seems to do fine over edge, even though I *think* I can hear a difference in sound quality. This could be psychosomatic. On the other hand Amazon has a lot more noticeable pauses. 
• Google Music seems to manage metadata better, both metadata about songs and about collections (albums, playlists, etc.) However, I have heard other users complain about this.

I am generally pleased with both services. Since I was able to upload all of my music to Google for free, I have used it more. However it has convinced to upload more of my music to Amazon, and consider paying for it. However, that would cost me $100, since I have more than 50 GB of music. 

So far I have only uploaded music from my laptop. I have about 80 GB of music on my desktop computer, though this is pretty much a superset of what is on my laptop. I am going to start the Google Music uploader on it too. Hopefully it will not do two copies of songs that are in common, and only upload the 30 GB of music that is not already present. If it does that well, and I have all of my music on their servers, it will be very tempting to pay for this service once the beta holiday ends.

These cloud based services have made me wish that I could have similar access in my car. I have an old iPod Touch (8 GB) hooked up in my glove box currently. It would be nice to have 10x capacity, but at what cost? Not to mention that the car interface (I have a large Sony head unit with a touchscreen interface) leaves a lot to be desired. That only gets worse with 10x data to deal with.

Mobile Zealotry

"You're either with me or against me!"
Does this feel like the rhetoric coming out of Google and Apple lately? Sometimes I wonder if Russell from Survivor is working for these guys. I was at Google I/O last week, and I have to admit that Vic Gundotra delivered a great keynote. It really got the troops excited.

"One man, one company, one device, one carrier would be our only choice ... Not the Future We Want"
Indeed. But before you go out and get an Android tattoo, and toss your iPhone off of the Golden Gate Bridge, take a deep breath and remember: You don't work for Google (unless you do, in which case I assume you've already got said tattoo.) You should not care who wins this jihad -- but make sure that you aren't collateral damage.

If you are a mobile developer, what you should most care about is delivering the best and most useful experience to your users. So first and foremost, you need to care about what kind of devices your users are using. If they are all iPhone users and you really want to build Android apps, well sorry. Further, if they are all Blackberry users, then you can just ignore the drama going on here in the Valley.

Of course the device of choice for your users today is quite possibly not what they will be using tomorrow. Former Android engineer Cedric Beust makes the point that the iPhone may well have peaked. Things look great when you're at your peak, especially if you don't realize that the descent has begun. So you might build a killer iPhone app this year, only to find that your users have moved on next year. Nobody ever said that this was an easy game.

Hedging your bets and investing in multiple platforms seems like the safe thing to do, if it's practical. But don't forget the other factor: delivering a great app. If you can't deliver a great app on Android, then don't bother. If you can't deliver on the iPhone, then don't bother. Both Apple and Google have gone out of their way to provide developers with fantastic tools and platforms for creating great apps, so this may be a moot point. There are definitely types of apps that are better suited for one platform than the other. For example, the iPhone seems to be superior for games. If you look at the success of consoles, you can see why that kind of environment where hardware and software are highly standardized, translates well to the iPhone. Similarly, the lack of background processing on the iPhone (and don't believe any hype about iPhone OS 4 changing this, it does not except in a few special cases) cripples the capabilities of many iPhone apps.

The most important thing to keep in mind in all of this is that it is in Apple and Google's best interests to be as divisive as possible. If they can convince you that they are "right" and that you should only develop for their platform, this is a huge win for them. So expect the rhetoric to only get worse. How many days until WWDC?

Android Wish List

This Wednesday is the first day of Google I/O. Google has a lot of very interesting technologies and many of those will have some new features announced this week. However, it doesn't seem too presumptuous to say that I/O is going to be Android-centric this year -- maybe every year for awhile. Google has pitted itself firmly against Apple and its iPhone/iPad platform. So I/O is Google's WWDC, and in case you missed it WWDC 2010 is all about mobile. And so it is with I/O.

There is a lot of chatter about Froyo, or Android 2.2. It's browser will have an integrated Flash plugin. It's supposed to be insanely fast (courtesy of a JIT and lower RAM usage by the kernel). It will support USB tethering and it can turn any Android phone into a mobile hotspot. That's all great, but none of that really does much for us Android developers, except for the speed increase of course -- especially important for game developers. Speaking of game artistes, Froyo is supposed to bring a lot more OpenGL ES goodness into their hands. So maybe we'll start seeing killer games on Android. Anyways, back to developers. What's Froyo got for us? More importantly, what do you want out of the platform? Here's my list.

1. Push Notifications. The iPhone has it. Blackberry has had it for what, a decade? The Windows Phone thing that's coming out at the end of the year is supposed to have them too. But what about Android? Background services and polling? Stop F'ing with me.
2. Apps on SD Card. Yeah we've been asking for this for a long time, and Google has always shot it down. Why is it important? It removes the pressure to keep apps super small, a pressure that has some chilling side effects. On the iPhone, I wouldn't hesitate to use a 3rd party library in an app, even if it added an extra 500KB to the app size. Not so on Android. For me this is particularly acute when it comes to using other languages like Scala on Android. The runtime library size is prohibitive -- because the app can't be saved on to the SD card.
3. More JDK. Wouldn't it be nice to have JAXB on Android? What about JAI? Yeah I know that sometimes they just wouldn't work because of performance reasons, but sometimes they would. Shouldn't be up to the developer to figure out when to use it or not?
4. Android for pads/slates/tablets. Yeah I want the Android equivalent of iPhone OS 3.2. I want to see Android on these form factors. As a corollary, I want an end to ChromeOS and that potential distraction. Let's just have one tablet OS from Google, ok? Android: Tablet Edition will have the Mobile Chrome browser in Android, anyways right? Bonus points: A sexy device with the new OS running out given to all of the developers at I/O (I know they gave us Droids already, but I'm greedy.)

So there's my list. What's yours?

Update: I remembered one more thing for my wish list, though this is not directly part of Android. I want Android 2.1 (or 2.2) to be available on all Android devices. I want it running on the G1, for example. There are definitely some SDK features I'd like to take more advantage of, and that's hard to do with 1.5 and 1.6 still on the majority of devices. The Mobile Chrome browser in 2.0+ is infinitely better than what's in 1.6 and lower because it uses HTML5 standards for storage, offline, geolocation, etc. instead of the now defunct Google Gears. So I really want those 1.5 and 1.6 browsers to go away, it's like having to support an ActiveX control for Ajax...

Nexus One vs. iPhone

I recently purchased a Nexus One, primarily for Android development. I needed a device for developing Android 2.0+ on. The 2.0 SDK has been out for almost three months now, and yet it is still not available for my old developer phone, the Android Dev Phone One. I had gotten pessimistic about HTC making Android 2.1 (since apparently 2.0 is being skipped) for the ADP1, which is essentially the G1, so it was time to buy a new phone for development. I decided to spend some quality time with the phone, i.e. as a user, not a developer, and share my thoughts.

First, a caveat... I plopped in my AT&T SIM card into the N1 before turning it on. That worked just fine -- with some known limitations. By working just fine, I mean that the N1 recognized the SIM card and configured itself for AT&T's APN without me doing anything. This was not the case with the ADP1, which was actually a pain to get working initially. You see, every Android phone that I have used wants you to sign in to Google before doing anything else. This can be a real problem if it cannot use the SIM card to access a data network. Anyways, it was no problem at all for the N1. However, as Google has pointed out, the N1 is not able to access AT&T's 3G network. It does not have the right radio for this. I have no idea why this is the case, but I will say this. Let's just imagine that I loved the N1 so much, that I decided that I wanted it to be my everyday phone instead of my iPhone. Even if that was the case, there is no way I would do this, since I would have to switch service to T-Mobile in order to access a 3G network on the G1, and for me (as well as most iPhone users) that would meaning breaking my contract with AT&T. On the other hand, if Google/HTC had only put the right radio in the N1, so that it could access AT&T's 3G network, then that would not be an issue. I bring all of this up now, because it does make it more difficult to compare the two phones. If you have one phone that is on 3G and another on Edge, you will prefer the 3G one unless the Edge phone is just way better in every other way.

Ok, so the good news is that the N1 is definitely a phone that I could live with. It is fast, I mean really fast. Navigating between applications, applications execution, startup, etc. are all very fast on this phone. I would say it is noticeably faster than my iPhone 3GS. In fact, I did some mini-benchmarking between the eBay Mobile app for the iPhone and our new eBay Mobile app for Android, running on the 3GS and N1 respectively. I put both phones on the same Wi-Fi network for this test. The N1 app was definitely faster than the 3GS app. Now the code is different, as our Android app takes advantage of some the Android features to speed up some common things in the app. Still, the Android app is running in an interpreted environment, the Dalvik VM, not as native code like the iPhone app. So even though it was definitely an apples to oranges comparison, I still found it relevant. Our app on the ADP1 (Android 1.6) was much slower.

The phone is also aesthetically pleasing. It is a pleasure to use. It looks nice. It is incredibly thin. In fact, the iPhone feels very chunky in my hand, after using the N1. Using the phone was very intuitive, but of course I have been using Android phones for over a year now, so I am certainly used to the OS. As a phone, it is on par with the 3GS, which is to say it is ok, nothing to brag about. The soft keyboard is easy to use for me, probably because I am used to using an iPhone. The word suggestions on Android are really nice, and it took me no time to start using them aggressively, thus saving myself a lot of typing.

My favorite part about the phone is the email. We use MS Exchange at work, and I am a long time GMail user for my personal email. With the N1, I could setup both to be in a push mode. On my iPhone, I can only setup one or the other to be in push. So on my iPhone, I have to check my mail to know if I have new GMail, but I immediately know about it on the N1. Also, I think email for both of my accounts looks better on the N1.

However, this brings me to a negative for the N1. It will connect to our MS Exchange server with no problems and can sync both email and contacts from Exchange, but not calendar. I have been told that this should be possible, but all solutions I have seen involved either 3rd party software, or using a workaround like syncing my Exchange calendar to a Google calendar first, and then syncing the Google calendar to the N1. I don't want workarounds, I just want something that works easily, so this is a huge negative for me. When I am at work, I often go from one meeting to another, and it is invaluable for me to be able to look at my phone to know when/where my next meeting is.

Speaking of apps, the Android Market is growing rapidly. The Facebook app for Android is very nice, and its use of the OS to allow you to integrate your friends list with your address book on the N1 is excellent. There are a lot of Twitter apps for the N1, I personally liked Swift. There are a lot of other quality apps out there as well. Here is a handy equivalency table of apps between iPhone/Android from Alex Payne. Still, this is definitely an area where the iPhone has a huge advantage. For me, the advantage is most pronounced for games. There are so many more games on the iPhone, with more well known titles (often backed by big companies like EA.) Also, the games seem to be much higher quality. The number/quality of titles will likely improve over time. Hopefully the quality of the games will too. Perhaps this is an area where the Dalvik VM gets in the way, though you can certainly go native for games, potentially reusing code developed for the iPhone.

A couple of more things, both good and bad... The browser on the N1 is excellent, definitely on par with the iPhone's. That is both from a user perspective and a developer perspective. Having multi-touch in the browser makes a huge difference for users. Adopting HTML 5 standards makes a big difference for developers. I never saw any pages that rendered noticeably differently on the N1 than they did on my 3GS. Usually it was the same only faster. Overall the browser, like most other things, tend to look better on the N1 than the 3GS simply because the screen is so much better... On the downside, the camera was a little more inconsistent for me on the N1. There have been times where I took pictures on it that came out completely out of focus. They certainly did not look out of focus when I took the picture. Maybe this is bad luck. The N1 has a 5MP camera, but I would not say that rates it above the 3GS. Don't get fooled the megapixel myth. I think pictures on both cameras were of similar quality -- except when the N1 would get things out of focus. The flash on the N1 seems useful however.

So there it is. If I lost both of my phones and AT&T cancelled my contract, it would actually be a tough decision between the 3GS and the N1. I would go with the 3GS because of the calendar issue and its big advantage in number of apps/games available for it. The calendar issue seems like an easy issue to address, and the apps/games discrepancy is become less pronounced. It's not like the Android Market needs to have parity with the App Store, at least not in terms of quantity. Also my issues are far from universal. So I could definitely see a lot of people picking the N1 over the 3GS.

Mobile OS Wars: Upgrades

Right now Apple and Google are in the midst of major upgrades to the OS on their devices, the iPhone OS and Android. If you develop for these platforms, you need to make sure your applications have no issues on the new versions. The simplest first step is to upgrade your SDK and development tools, and re-compile. Neither OS updates remove (any?) APIs, they mostly add to them. So it is unlikely your application does not compile under the new SDK. You can also launch your application in the emulator provided with each SDK. Now there is a little more chance of a bug popping up.

Still, a lot of upgrades are only found when you run your app on the new OS on a device. Why is this? A lot of the bugs that come from these upgrades are memory management issues, multi-threaded issues, or networking issues. When you run on an emulator, many of these issues just never happen (memory/networking) or behave differently because of the difference in processor seed (multi-threading.) So you need to upgrade the OS on your test devices (you do have dedicated testing devices, not just your personal phone, right?)

Upgrading your iPhone OS is really quite easy. You download the new OS. You right-click on the "restore" button in iTunes, or you can use the Organizer in XCode. Either way, device is wiped, the new OS is installed, and then your data is reloaded from a backup (iTunes backs everything up automatically.) The only gotcha is that apps that weren't installed via iTunes, i.e. apps you developed and are testing, do not get backed up, so they disappear. This should not be a problem since you have the source code for such apps. However, in order to re-install from source code via XCode, your SDK must also be upgraded to the same version as the OS. Again, you probably upgraded the SDK first anyways, so no big deal.

Upgrading your Android device is not quite as straightforward. There are a lot of steps, so I won't repeat them all here. The upgrade is fundamentally different in that you replace parts of the system in place. Your device is not wiped. This is necessary because there is no automatic backup process on Android phones. On the iPhone, this is handled by iTunes. There is no analogous desktop software companion to Android. This is viewed by many as a pro, but in this case I consider it a con. Anyways, there are a lot of steps, but it is very smooth and very fast. In fact, it is much faster than the iPhone process because there is no delete/restore going on.

All of this points to some of the core differences between these platforms. Others have pointed to the Mac vs. PC scenario of the 80's as being similar to the iPhone vs. Android scenario of today. Apple went with a closed platform where they controlled everything, vs. the "open" combination of Windows plus Intel. Any manufacturer could slap an Intel chip in their machine and install Windows on there, with full freedom on what else went in to the machine. Same thing is going on here. Apple controls the OS and hardware of the iPhone. Android can go on many different types of hardware. Right now this is not making a big difference, since there are not yet a lot of Android phones. However, it seems likely that at some point you will see Android phones that are free with a contract or maybe $100 from Metro PCS or even pay-as-you-go carriers.

Ok so that was a tangent, what does it have to do with this issue? Well, by having a closed system, Apple can provide a lot of advantages. Upgrading is simple. For consumers, you get the upgrade from Apple directly. You might notice the Android link above is from HTC, the maker of the first Android phone. Most consumers will get the upgrade from T-Mobile. Notice that Google is not even in this conversation, even though not only do they make the OS, but it is open source. In addition, many developers I know are dreading the proliferation of Android. Currently development for Android is nice, in fact a lot nicer than for iPhone. The development/emulator scenarios are equivalent, but debugging on devices is much simpler. However, when more variants of Android appear, and those variants are more specific to the devices they run on, then right once / run anywhere fades away. Again, notice that the OS upgrade came from the handset manufacturer already. That is very significant.

All Your Pages Are Belong To Us

Remember back when people realized that the Internet was a valuable way to reach customers and potential customers? You would see all of these television or print ads where they would print the URL of a website, or even radio ads would have somebody read the URL of a website. Oh wait, I guess this is still done a lot. Whatever, a while back this really became unnecessary. Whatever the name of your brand or product, you could just search for it in the search engine of your choice and find the same link that was being advertised. Who wants to try to remember a URL anyways?

Well the days of remembering a URL may be coming back, sort of. Earlier tonight I was watching UNC beat down Villanova. During a TV timeout, there was an ad for a movie. I honestly do not remember the name of the movie. At the end of the commercial, they put up a URL. Only this time the URL was something like http://www.facebook.com/name_of_movie. That's right, if you wanted to know more about this product, you needed to go inside the proverbial walled garden that is Facebook.

Now if you just searched for the name of this movie, would you get the link to the Facebook page? Maybe, but maybe not, or maybe it would depend on the search engine. Of course, if you were already on the Facebook site, and searched there, then you surely would find this page. So what does this mean? Do we need to start remember and typing in URLs? Or do we just need to do all of your search inside Facebook?

How Google Makes The Net Suck

Some people like to compare developers to artists. When it comes to web development, some people say there's always a man behind the curtain. Whether you agree or not, there are definitely certain freedoms that web developers enjoy. As a web developer, what are the greatest limitations and obstacles in your way? Once it may have been browser quirks. Now maybe it's all those annoying users who still use IE6. However, I think the greatest obstacle to progress is Google.

Now Google would have you believe just the opposite. I do not think they are disingenuous. In a large organization, it's all too easy for different groups to have different motivations. But ask yourself this, how much money does Google from Chrome? What does Google make money from? That's easy: advertising on search. And that is what is hold us all back.

If you have endured my purple prose to this point, I will finally cut to the chase. One of the most important aspects of any web page is how its PageRank. If your web page is all about deep sea diving, where does it surface when somebody searches Google for deep sea diving? The black art of making your page get a higher PageRank has given birth to an entire cottage industry known as Search Engine Optimization (SEO.)

As a developer I have never given much thought to SEO. I always thought that SEO was about the content of the page, and web developers are not responsible for the content. We are responsible for retrieving/generating that content from all kinds of sources, as well as creating applications that are easy and intuitive for the user to interact with a meaningful way. But, if we go back to the deep sea diving example, we're not responsible for providing information about deep sea diving. Heck you are lucky if most developers even known how to swim, but I digress.

But I was wrong. SEO is not just about content. It is about structure. If you want a good PageRank, then quality content about deep sea diving will lead to other people linking to your page and that will increase your PageRank. But there are much more instantly gratifying things you can do. For example, your page should a title and it better contain the term deep sea diving. No big deal, right? The title is really just part of the template outside of the main contents of the page. Its value has little effect on anything, besides PageRank that is. However, it gets worse.

To maximize your PageRank, then immediately after your page's body tag you should have an H1 tag whose contents should contain the term deep sea diving. Oh maybe you put the phrase on the page, but you put it in a div that styled quite nicely? Not good enough. It needs to be in an H1 tag. Maybe you used some JavaScript to create the H1 tag? That is no good at all. Why? Because The All-Mighty Googlebot does not understand how the page looks to a user. It only understand basic HTML constructs. That's right, it's time to party like it's 1999.

Oh, maybe your organization hired an artist who created a killer deep sea diving logo and you load it on to the page as an image? Not good enough. If you put deep sea diving as the alt text, that will win you some bonus points from the Googlebot, but it is still dwarfed by the rewards you could receive by busting out the H1. Nothing compares to the mighty H1 tag. And don't just put that H1 tag anywhere on the page. Heck you might even get penalized for having more than one! Nope only one, and it better appear (in the HTML source code) as close to the body tag as possible.

Ok, so maybe you give in and put the catch phrase in an H1 tag. That wasn't too bad, right? Now back to your regularly scheduled hacking? Not so fast. Do you have some hierarchical information on the page? Sections, headings, menus, etc? How are you going to do those? Again you better not even think about using things like JavaScript to create them dynamically. Nope, they have got to be static on the page. Back to divs, spans (maybe a table or two), along with some oh-so-clever CSS? Forget about it. Let me introduce you to H1's other friends: H2, H3, H4, H5, H6. That's right, if you want that damn Googlebot to "understand" the hierarchy of concepts on your page, then you better put away your divs and spans.

Maybe you think that's going overboard, but it's not. Do you have a section on your deep sea diving page called "Gear" ? Then if you want to show up on a search for deep sea diving gear, you better have the term Gear wrapped in an H2 or an H3 tag.

What about RIA technologies? Again, if you dynamically create things with JavaScript, it will get picked up, but it is non-optimal. You have to do things the way that the Googlebot wants it done to get best results. What about Flash or Silverlight or JavaFX? Flash will get you screwed on about the same level as JavaScript. Silverlight or Java might as well be black holes. Whatever is in there, is never getting out.

There are tricks you can employ like progressive enhancement. There you do things the way that the Googlebot wants them, then dynamically obliterate that garbage and replace it with rich content that your users actually want. This can backfire. If the Googlebot figures out that you are tricking it, then it will banish you to purgatory.

What if you just make a great web application that users will love and don't bother to worry about the Googlebot? That's fine of course, it just means that people will not find your application by searching for it. Is your business model and marketing efforts robust enough to not need SEO? Yeah, I didn't think so.

So now do you understand? The Googlebot ties your hands, or at the very least makes you jump through all kinds of hoops. There are all these great technologies you could use to make your site as interactive as any desktop application, but The Googlebot does not like this. You've got to play his game whether you like it or not.

JavaScript Benchmarks, now with Chrome

As promised yesterday, I did the JS benchmarks again on a Windows machine so I could include Google Chrome. I tried to be pretty inclusive, adding in IE7, IE8 beta 2, Firefox 3.0.1 (current release), Firefox 3.1 with and without JIT, Safari 3.1 (current release), Safari 4 beta, Opera 9.5 and Chrome. This was all run on my workstation, a 4-core, 3.2 GHz box with 8 GB of RAM. Any add-ons, extensions were disabled. Here is the pretty picture.


Once again Safari is the kind. Safari 3.1 beats everything except for Safari 4 beta, which crushes even Safari 3.1. Opera was a little slower than Safari. Chrome was generally comparable to the various Firefox browsers, but overall slightly slower. Like Firefox 3.1+JIT, it was very on error handling! Of course IE was the slowest by far, but at least IE8 is faster than IE7. Maybe IE8 is shipping with debug symbols included (as Microsoft has often done in the past) and the release candidates will be much faster than the betas. Or not.

Anyways, Chrome, and its V8 engine, does well, but does not seem to be ahead of Firefox and is certainly behind Safari and Opera. Maybe they can do better on the Mac!

More JavaScript Benchmarking

My old boss sent me this link about Google Chrome performance. It's a good read. It includes a link to an interesting JavaScript micro-benchmark. It included some interesting findings on Chrome vs. Firefox 3, Safari 3.1, and the new IE 8 beta 2. I was curious about some other browsers, namely Firefox 3.1 beta with and without JIT, Safari 4 beta, and Opera 9.5. Of course I made a nice picture of my results.

Interesting results. First off, FF 3.1 with JIT did not crash. It crashed so many times on me yesterday, that I was sure it would crash on this. Even though it did not crash, it was barely faster than FF 3.1 no JIT or FF 3.0.1. In fact, it was really only faster at error handling and the same on everything else. Apparently errors are easy to JIT for TraceMonkey!

Next, Safari 4 beta is fast. If you look at the link above, Safari 3.1 was already the fastest thing out there, so I guess this should not be a surprise. It crushed everything and it did it on the kind of tasks that real developers do a lot: array and string manipulation, regular expressions, and DOM manipulation (technically not part of your JS engine, but practically the most important test.) I am not used to seeing Opera lose when it comes to any kind of benchmark. If you throw out the array manipulation, it and Safari are pretty close.

I will have to boot up Parallels and try out Chrome vs. Safari 4 beta vs. FF 3.1 beta on Windows.

Eclipse Day 2008

Congratulations to the Eclipse Foundation for releasing Ganymede today. As part of the festivities, Eclipse and Google collaborated on Eclipse Day yesterday. I was fortunate enough to be asked to speak at the event, and it was a great experience. I spoke about how we use Eclipse at eBay. The response was very enthusiastic with lots of folks amazed at how many tools we had built for our developers and how we had standardized tools across such a large development organization. I totally agree that our tools developers are amazing. For me, I don't know how we could survive without having all of the tools we have built! Here are the slides from my presentation, courtesy of SlideShare:

| View | Upload your own

I wanted to really thank Ian Skerrett from Eclipse for organizing everything. The folks at Google were excellent hosts, so I must also thank Robert Konigsberg from Google.

Googling MTOM

I use MyBlogLog to see the traffic stats to my blog. I noticed a lot of the referrers each day were from a Google search for MTOM. The search has one of my blog entries about an article I wrote on MTOM. I found it funny that my very short blog entry about the article shows up higher in Google than the actual article itself. The article has a lot more about MTOM and is linked to by my blog. Shouldn't that make it rank higher? The cynic in me thinks that my blog ranks higher because it is on the Google owned Blogger...

Flock 1.0

In case you missed the news, Flock finally went 1.0 late last month. I've been playing around with Flock for over a year. They're integration with social services has gotten better and better. I did a clean install of it and setup my Flickr, YouTube, and Blogger accounts very easily. I've given up on using it for RSS, as having a server-based solution (Google Reader) is too valuable to me. They've also added Facebook and Twitter integration, two favorite services of mine. Both are well done. And of course it's based off Firefox 2.0 now, which is great. Most Firefox plugins work great with it. I'm using its blog writer right now, as I'm planning on using it as my primary for a week or so and then figure out if I should go back to Firefox or not.

Blogged with Flock

Bad Writing

I like reading Marc Andreessen's blog. He has good insight. Today I saw the news about Google's Open Social initiative. I noticed that Ning was a participant, so I figured Marc would have something interesting to say about it. Reading his entry reminded me of many other entries by him and how incredibly annoying his writing style is. Let me give some qualification to this statement.

My 10th grade English teacher, Dr. Deluzain, was really tough. He made all of his students write a lot, and he absolutely tore up everything you wrote. I give him tons of credit for making me into a decent writer. In college, the biggest advantage I had over other Caltech students was not my mathematical abilities, it was my writing skill. Math bailed me out in many situations, and led to my only A+ (in quantum chemistry if you can believe that,) but I was always the best writer in every "soft" (literature, history, political science, etc.) class I took. Thanks Dr. D.

One of the lessons I learned from Dr. Deluzain was that you should never use styling in writing. This was 1991, so word processing had become popular. Of course people wanted to use bold and italics, or large fonts, to drive home points. Dr. D. taught me this was obnoxious and unnecessary. It showed poor skill. If you had to resort to such tactics to emphasize your point, then obviously you were doing so to make up for a lack of writing skill.

Fast forward back to the pmarca blog. Andreessen has to be the worst person I've ever seen at using italics and bold all over the place. Normally I just ignore it. College taught me that most technical people never need to hone their writing skills, so why should Andreessen be any different. The first full paragraph (most of his first few paragraphs are actually just sentences, but I digress) has 102 words in. Of those, 27 words are either bold or italics. Of the other 75 words, 21 are in quotations, which is a similar sign of poor writing (one I'm guilty of too, though it's not quite as bad.) It just makes my head hurt. I hate being a writing snob, but I needed to vent and that's part of what my blog is for.

I dislike writers who can only bring up negatives and never offer solutions to problems. So I decided to re-write his paragraph. I tried to keep his words as much as possible.

"Technically, Open Social is implemented as what I call a plugin API, or a Level 2 platform. In other words, it's not a web services API -- rather, it's a way for external applications to plug into a host environment (container). The external app literally shows up insides the pages of the container, and can make Javascript calls to retrieve information from the container and perform functions within the container. For example you can make a Javascript call to get a list of all of the user's friends, or to inject an event into the user's activity feed."

Isn't actually a lot less work to write it like this? Or has the web redefined good writing style? Maybe my way is antiquated and Marc's is exemplary...

GWT 1.4

I recently finished writing a series of four articles for IBM on GWT. You might recall that earlier this year I wrote a two-part tutorial on GWT. The new articles for IBM aren't as introductory, though they don't require a lot of prior GWT knowledge. They're definitely more advanced though. I wrote the articles using the 1.4 release candidates, and then last week 1.4 went final. So I figured it was time to look at how GWT has progressed since the last time I wrote about it.

• Cross Platform Problems -- Hard for me to say how much things progressed. I did almost everything on my MacBook, and things had always worked well on OSX. I did do a little on Windows. I had to do a little more configuration to get it to correctly run in hosted mode than I did on OSX.
• Obfuscation -- Still a problem. Of course you can turn it off, which is good. Still, I pity the fool trying to debug GWT JS in Firebug.
• No Java 5 -- Still a problem. GWT will choke on a List, but String[] is ok. Also, any annotations will choke it as well. So no returning @Entity classes from your RPC services.
• Lots of boilerplate code to write -- Still a problem. You still have to write two interfaces and one class to create an RPC service. Inserting GWT into an existing page is easier, with just a single JS file to include.
• Better build support needed -- This has a improved a little. The ant script that is generated is slightly more useful than the previous version. Still frustrating that there's no build script generated for creating a WAR file. You don't have to use GWT with a Java application server, but obviously a lot of people are. The RPC services require it as well.
• RPC is bad -- Of course that can't change! RPC is still bad. I like how in the documentation, the GWT team mentions two different design philosophies for RPC services. One is to create RPC's specifically for the web application. The other is to have general purpose ones that can be re-used by many clients. Good luck on that last one. That would mean your general purpose services can only accept and return classes from the subset of Java 1.4 that GWT supports.

So that addresses my old pain points. Not much progress has been made. There are some new good points.

• Performance improvements -- Ok, they've really done a good job here. Things are snappy even on a page where you use lots of generated JS to create your UI.
• More Widgets -- Steady progress has been made here. You can get pretty far just using their widgets. I haven't tried out any of the commercial WYSIWYGs built for GWT, but these seem more viable and useful with more widgets. Of course, their widgets are very limited. They definitely aren't components. Compare a GWT widget to a Flex component, for example, and it's not even funny. GWT's widgets are pretty lightweight, but are low in functionality compared to similar abstractions found in similar frameworks.
• Image Bundles -- Very cool new feature. I like how they use CSS to get nice layout of the images from the bundle. It seems like a great way to optimize the static assets in your app. Seems like it might play tricks with a user who wants to right-click on one of your images and do save-as, but oh well.
• Localization -- This has always been there, but it seems better documented and exposed now. Plus there is a command line tool for it. It's pretty nice, though I question the logic behind doing your localization in code that is going to be converted to JavaScript and executed on the client.
  

So all in all, GWT has made some nice improvements and added some new features. They have not addressed the things that are their most blaring weaknesses (IMO), but then again those are probably the hardest things to address. I was surprised though. From my last big write up, I got a lot of feedback from people talking about how these exact issues were being addressed, i.e. that the work was already in progress. Was that really the case?

Google Docs To The Rescue

I was reading this post by Jeremy Zawodny, and it reminded me of my recent Mac Office 2004 meltdown. I went down a similar path. I had an Important Doc(!) that I needed to make some edits on for work. I had planned on doing the edits that morning, before I went in to the office. So I had some serious time pressures. I didn't know how long it would take me to solve the riddle dropped on to me by Apple Software Update. I actually tried loading the document into Pages, but it barfed on it (maybe because the doc had a table of contents?)

So like Jeremy, I fired up Google Docs. I uploaded the Important Doc there (hope nobody from Security is reading this, though the doc was intended for folks outside of my company.) It came through just fine. I made the edits I needed to make and saved it on Google Docs.

Then I went back to fixing Office, which I eventually did. I went in to work, opened the Google Docs version of my document, and manually merged in changes to the original. I would've just exported it as a Word Doc, but I was afraid of how it would handle the table of contents. So I manually merged and then updated the table of contents.

Ron Paul and YouTube

There's been a lot written about the Ron Paul phenomenon. One thing I will have to do at some point is just talk about what I like about Ron Paul. I've been very apolitical this year though, so that will have to wait. One very interesting thing about Ron Paul though is his influence on YouTube.

My friend Chris wrote an interesting program to calculate the "influence" of political candidates via YouTube. Most of the major candidates have accounts (ok so it's surely their staffers, but whatever) on YouTube, and you can be their "friend." Chris looked at each candidate's friends and at what YouTube videos they had marked as favorites. He looked at the common favorites among friends of candidates. Here's a chart showing this data for Barack Obama:

The big red bar is the most common favorite among friends of Barack Obama. Why did I pick Obama here? Well he is the most popular candidate on YouTube (and on Facebook) as measured by how many friends he has. Anyways, back to the red bar. The most popular video among his Obama's friends is a favorite of 12 of his friends. #2 on the list is a favorite of 8 of his friends. Now let's take a look at the same chart for Ron Paul.



The #1 video among Ron Paul is a favorite of 34 friends, while #2 is a favorite of 17 friends. The video in question is a video of Ron Paul speaking at Google.

I guess none of this should come as a surprise. Ron Paul supporters are ... very passionate about Paul. It's that passion that infuriates many people. He is very much a fringe candidate right now, but the passion of his supporters may well push Paul into the mainstream. Is YouTube a place for that to happen? Probably not, but it's a start. To do my part, here's the video in question. Enjoy.

Hacking my 8830

Ok, so not really. I've had my Blackberry for a little over a week, and I continue to be more impressed with it. Here are some useful things.

1. Enable mass storage. You get a cryptic message for this, but totally want to do to this. It let's you access your Blackberry's file system. On my Macbook it makes the Blackberry look like a mounted drive, a la a DMG file or something, only its read/write not read-only. This is the easiest way to put pics or MP3s on there.
2. MP3 Ringtones. Forget buying ringtones. Just load some MP3s on there. Go to your song by going to Media -> Music. Pick your favorite song and the pick Menu -> Set as Phone Tone. Now that MP3 is your default ring tone. Want a special ring tone for different people? Go to the person in your address book. Click Menu -> Edit. Then click Menu -> Add Custom Phone Tune. Click enter. This will bring up a list of pre-set ringtones. You don't want any of this garbage. But scroll to the top of the list and click Browse. Then click Menu -> Explore. I went to Media Card/MY_MP3S. That gave me all of my MP3s. I just picked whatever I wanted from there.
3. Google Apps. Google obviously loves Blackberry users. GMail and Google Maps both rock for the Blackberry. Google Talk from RIM also rocks. If you open up Google Maps and pick a location, you can get directions. You'll notice that the "from here" is disabled. That's because GPS is not enabled for Google Maps by default, which brings me to my next tip.
4. Enable GPS. A former co-worker of got an 8850 and thought that Verizon had disabled the GPS. That would be a very Verizon thing to do, but it turns it's not the case. Go to Options -> Advanced -> GPS -> GPS Services and switch it to Location On. It's set to "911 Only" by default. Open Google Maps and you'll have to grant Google Maps permission to use the GPS. Now you've got the full GPS enabled Google Maps functionality. I found that I needed to be outside to get a good signal on it.

These tips are for Mac users only.

1. PocketMac. The Blackberry version is free and is very good.
2. Google Calendar. I sync iCal to my Google Calendars, and then sync iCal to my Blackberry via PocketMac.
3. Plaxo. I use Plaxo as a central repository for my contacts. I then installed the Plaxo plugin for Address Book. It becomes a cool read/write system. I update contacts in Address Book. That syncs things to Plaxo where they are persisted and available to me at work, etc. They are also copied to my Blackberry via PocketMac.

Other stuff...

1. I downloaded Opera Mini. It works ok. There are some web pages I can view in it that I cannot view in the Blackberry browser, such as ESPN Fantasy Baseball. Entering text into Opera is a pain though. It has its own interface for this that seems awkward. I still think it will come in handy in the long run.
2. I haven't tried syncing my Safari bookmarks to the Blackberry. That's a cool feature offered by PocketMac. I would need to clean up my Safari bookmarks first though.
3. Facebook Mobile is really well done. You can do most things that you'd want to do on a mobile device there. A lot of folks prescribe to the iPod/iTunes model when it comes to mobile apps, i.e. read-only on the device, do all your writes from your computer. Facebook does a good job of giving the right "writes" on their mobile version.

Update: An old co-worker of mine and an anonymous commenter both pointed out that even though you can supposedly enable GPS, Google Maps and other similar programs are not able to use it. My friend claims that Verizon has disabled the GPS in some way. My experience has been the same, so maybe this is true. I don't know why Verizon would do this...

Update #2: Ah ha, now I know why Verizon has disabled the GPS on the 8830. There's got to be a hack though...

Google Gears

This is actually the second time I've written about Gears. The other time, Flock ate my post. I wasn't too upset, since I was using a daily build of "Sulfur". It's much better (in terms of feature set) than the current 0.7 version of Flock, at least when it comes to blogging on Blogger because it supports Blogger labels. Anyways, back to Google Gears.

I gave it a try (via Google Reader of course), and was not too impressed for one simple reason. I have to tell it to "go offline." So I guess the idea is that I know I'll be offline later, so I will "go offline" now, thus downloading content to read later. Ok, that's fine, but not very useful. It requires too much planning, in my opinion.

It's really not that big of a deal for Google Reader. But clearly Gears has the most potential for other Google Apps that have more direct "offline" analogies: GMail and Google Docs. The choosing to go offline thing would be silly for either of these.

With a Gears enhanced GMail, I would expect to always have a copy of (at least) my most recent email. I'd expect to be able to search it, too, but that's another story for another day. For Google Docs, I would at least expect to have an offline version of all my "active" docs. For both of these apps, I would expect to have these things all the time, seamlessly. Anything else is of very limited value in my opinion.

So I am left to assume that Google will enable this kind of seamless enhancement via Gears, but they just haven't figured it out, yet. I think that makes the most sense. If they had figured it out, I'm sure they would have enabled it with Reader, even though it's not quite as essential for Reader. In fact I'll wager the reason they launched with Reader was exactly because they didn't have the above use cases solved, yet.

One other Gear related thing. I was fascinated that Adobe seemed to be hanging around for the launch of Gears. It's interesting in a lot of ways. First, Adobe already has something similar, but far less powerful than Gears: Flash Shared Objects. Gears and its database make SO's look silly. Second, doesn't a Gears enabled Flex application provide everything that an Apollo application could promise? Sure, an Apollo app could be "heavier", have a fancier UI maybe, do more with local files, etc. Finally, I got the feeling that there was a Adobe+Gears announcement that didn't happen. That something that was supposed to be ready for Google Developer Day, wasn't ready. That's why Adobe was there.

Guice, Spring, and Arid

I was reading this article on Arid POJOs on TSS today. Chris Richardson, the author of Arid, has a nice introduction to it. One thing I found amusing was the statement at the beginning

...an important benefit of using XML is that it completely decouples the components that are being assembled from the mechanism that is assembling them This is not true when using annotation-based dependency injection such as that provided by the Guice framework. Components that use those kinds of annotations are tightly coupled to the framework and are definitely not POJOs!

I've been known to make my own digs on Google frameworks, but sometimes you have to call out FUD when you see it. The POJO argument usually comes from the requirements of writing EJBs prior to EJB3. You had a lot of interfaces to implement, and some of these interfaces required a lot of methods (typically lifecycle callback methods) to implement. To be an EJB you had to look like an EJB to the container, hence all those interfaces and methods to implement. The term POJO came about because POJOs don't look like EJBs.

So it is ridiculous to somehow say that a class that uses a com.google.inject (or javax.ejb for that matter) Annotation is not a POJO. Can a POJO not have any Annotations? Can a POJO not reference third party packages? Better remove all your Jakarta commons import statements...

As for tightly coupling to a framework, I will concede that it is nice to be able to switch out your DI provider without having to change code. I guess that is one drawback of using Guice. The Guice solution of writing a Module class for doing all the wiring and thus isolate the dependency doesn't seem realistic. You could do the same thing in Spring: programmatically create your configuration and thus wire together your classes. Nobody does that though, they all use XML files or maybe auto-wiring.

So maybe Chris Richardson has a valid point here. Bob Lee and the Guice gang at Google make some strong arguments for switching to Guice from Spring. You have to change code to make that switch, and you'd have to change code again to switch back.

I think in many cases, it is worth the "pollution" of your code. The thing I like about EJB3 and Guice annotations is the explicit dependencies. I have to worry about not only writing code, but also about writing code that other developers can understand. I have to worry about the learning curve I create for new developers I hire. There is a lot of clarity in something like:

@ImplementedBy(MyClassImpl.class)
public interface MyClass { ... }

There is also a lot of clarity in seeing a unit test that creates a module to override the bindings to allow for mock versions of certain classes.

At Ludi Labs, we used Spring in just about every way it can be used. Sometimes we got a little carried away and patted ourselves on the back about how clever we were. Then we would bring on a new developer and they would struggle to figure what the heck was going on with our application. We would have to patiently walk them through some things until things started to click. I have a feeling that Guice would have made this less painful for new developers, though there were definitely things we did with Spring (especially using its AOP support in conjunction with DI) that I'm not sure you could do with Guice.