Friday, May 28, 2010

Phone Number Fixer for Android

One of the curses of working with computers is that you often become The IT person for friends and family. In fact, I should get a commission from Apple for all of the business I've sent their way by getting family members to switch to Mac computers. Ditto for the Firefox browser. I can't make people switch to Mac, after all that's often an expensive proposition, but it's long been a condition of my help that you never even think about using IE. For some of my less computer savvy relatives, I've learned to make IE disappear. This just made my life a lot easier (less things to fix) especially back in the heady days of weekly IE6/ActiveX exploits. Anyways... These days most folks, including friends and family, mostly use web applications and since I've had them on Firefox for a long time now, there aren't too many problems. However, recently I got an unusual request for help from a high school friend Maria.

She had just switched to a Nexus One -- a phone that she seemed to be extremely happy with. She had imported several contacts from her SIM card that had been in her old phone. The only problem was that for these contacts, their phone number was classified as "Other." That would not be a big deal, but when she would try to send a text to a number, Android's auto-complete would not include these "Other" phone numbers as part of its search domain. So she would have to completely type out the number to send the text to -- which kind of defeats the purpose of having an address book on your phone. She could manually change each of these phone numbers to be of type "Mobile", and this would solve the problem for that number. However as you might guess, she had a lot of numbers and changing each manually would be painful to say the least. And that's where I come in...

This sounded like an easy enough problem to solve. Find all of the numbers that were of type "Other" and change them to "Mobile." That might not work for everyone -- there might be some people who really want to classify some phone numbers as "Other" -- but it certainly worked for Maria (and I would guess most people, too.) So I cooked up a quick little app. First, I wanted to display all of the numbers that this was going to affect:
ContentResolver resolver = getContentResolver();
String[] fields = new String[]{People._ID, People.NAME};
Cursor cursor = resolver.query(People.CONTENT_URI, fields, null, null, People.NAME);
LinkedHashMap<Integer, String> people = new LinkedHashMap<Integer,String>();
int id = cursor.getColumnIndex(People._ID);
int nameCol = cursor.getColumnIndex(People.NAME);
if (cursor.moveToFirst()){
 do{
  people.put(cursor.getInt(id), cursor.getString(nameCol));
 }while (cursor.moveToNext());
}
cursor.close();
This gives you a LinkedHashMap whose keys are the IDs of each contact, and whose values are the names of the contacts. Why did I bother with these two bits of info? Well, we need the contacts to query the phones, and I wanted something friendly to display to Maria so she knew which numbers were about to get "fixed". Anyways, now it was easy to query the phones:
ArrayList<String> data = new ArrayList&kt;String>();
StringBuilder sb = new StringBuilder();
String[] projection = new String[]{Phones.DISPLAY_NAME, Phones.NUMBER, Phones._ID};
Uri personUri = null;
Uri phonesUri = null;
int displayName = 0;
int number = 1;
int phoneIdCol = 2;
int phoneId = -1;
int cnt = 0;
for (int personId : people.keySet()){
 personUri = ContentUris.withAppendedId(People.CONTENT_URI, personId);
 phonesUri = Uri.withAppendedPath(personUri, 
            People.Phones.CONTENT_DIRECTORY);
 cursor = resolver.query(phonesUri, projection, 
            Phones.TYPE + "=" + Phones.TYPE_OTHER, null, null);
 displayName = cursor.getColumnIndex(Phones.DISPLAY_NAME);
 number = cursor.getColumnIndex(Phones.NUMBER);
 phoneIdCol = cursor.getColumnIndex(Phones._ID);
 if (cursor.moveToFirst()){
  do {
   sb.setLength(0);
   sb.append(people.get(personId));
   sb.append(": ");
   sb.append(cursor.getString(displayName));
   sb.append('|');
   sb.append(cursor.getString(number));
   data.add(sb.toString());
   phoneId = cursor.getInt(phoneIdCol);
   cnt += updateContact(phoneId);
  } while (cursor.moveToNext());
 }
 cursor.close();
}
ArrayAdapter<String> adapter = new ArrayAdapter<String>(this, R.layout.phone, data);
setListAdapter(adapter);
Toast.makeText(this, cnt + " phone numbers updated", Toast.LENGTH_LONG).show();
This code just loops over the contacts we got from the first query. For each of those contacts it queries to see if the contact has any phones that are of type "Other" (Phones.TYPE_OTHER). If it does, it creates a string that shows the contact's name, the phone's display name, and the phone number. This string is added to an ArrayList. Once all of the queries complete, an ArrayAdapter is created using the ArrayList of contact name/phone strings and used to populate a ListView.
You might have also noticed that a there is a counter variable being incremented, and an updateContact method. This is actually the method that fixes the phone number. I probably should have just kept track of the phoneIds and then gave the user a button to initiate the fixes, but I was lazy. Here is the code for updateContact.
private int updateContact(int phoneId){
 ContentValues values = new ContentValues();
 values.put(Phones.TYPE, Phones.TYPE_MOBILE);
 ContentResolver resolver = getContentResolver();
 Uri phoneUri = ContentUris.withAppendedId(Phones.CONTENT_URI, phoneId);
 return resolver.update(phoneUri, values, null, null);
}
Too easy. Contacts are an example of a Content Provider in Android. Many people (including my Android in Practice co-author and author of Unlocking Android, Charlie Collins) have criticized Android for exposing too much of the database backing of Content Providers. As you can see from the examples above, you have to deal with cursors (moving, closing), queries, updates, and very thinly abstracted select and where-clauses. Maybe it would have been better to drop down directly to the SQL, or provide a more object oriented API. Now you can create your own Content Provider, and you don't have to use SQL database to back it -- but then implementing the Content Provider contract can be quite awkward.
Anyways, I found that the easiest way to get this little app to Maria was to simply put it on the Market. It's still on there if you happen to have a similar problem (maybe many people switching to Android might experience this?) If you are on your Android phone you can just select this link. If you are on your computer you can scan this QR code.

Wednesday, May 26, 2010

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?

Saturday, May 15, 2010

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...

Friday, May 14, 2010

Awesome Android Presentation

... by my "Android in Practice" co-author, Charlie Collins:

Sunday, May 02, 2010

Apple, Flash, and The Truth

I'm sure by now you've read "Steve Jobs"'s Thoughts on Flash. Did it convince you? Do you think it was truthful? Not me. Sure it has some valid points, especially about Flash being buggy on OSX. As someone who has developed Flash applications using a Mac, I am especially aware of this bugginess, and part of me can't help but get a perverse sense of satisfaction that this bugginess is now coming back to haunt Adobe. However, this doesn't change the fact that Jobs's epistle is far from the truth. It is corporate slander, designed to make Adobe look as bad as possible. Why? So that when devices from competitor's ship with full support for Flash, this technological advantage can be discredited in the eyes of consumers. In other words, this well thought out post by Apple is not some intellectual/technical analysis, it is just marketing designed to boost Apple's profits.

The most dishonest thing about the post is what Apple says is "the most important reason" to ban Flash from their devices: that it will result in sub-standard apps and hurt their iPhone/iPad OS platform. This is complete bullshit. It's not like developers would suddenly only be able to create iPhone apps using Flash. It's not like they could no longer use all of the tools they use today. The difference is that they would have a choice. They could choose to use Flash. Or they could choose to use Objective-C/Cocoa/XCode.

But don't forget, that not only would developers have a choice, but so would consumers. If for some strange reason, some developers started choosing to use Flash,  it's not like consumers would be forced to buy those Flash-authored apps. No, they could still choose other, traditional apps. In fact, if, as Apple claims, Flash-authored apps would be of such low quality, then one would expect that few consumers would choose to purchase those apps.

So if Apple allowed developers to use whatever tools and technology they wanted to use, to create apps for the iPhone and iPad, what might happen? Well if Apple's claims are right, then there would be bad apps that nobody would buy (aren't there already a lot of such apps on the App Store?). Consumers aren't idiots, and they won't buy crappy apps when there will be better alternatives. So those Flash-authored apps will lose money. Developers aren't idiots, and they won't keep using technology that produces software that nobody wants. So they would abandon Flash and go back to Cocoa. So Apple's "concerns" would be unwarranted.

Or perhaps what would happen is that some developers would produce good apps using Flash that consumers bought for their iPhones. Certainly developers would continue to use Flash. However, in this scenario, Apple's "concerns" are proven to be false -- Flash produces some good apps. But wait, what about Flash holding back innovation on the platform? Apple would still be free to add new features to their OS, and make them available to developers through new APIs in the iPhone SDK. Who knows how long it would take Adobe to expose those features through the Flash authoring tools, but who cares? If those features greatly improve apps, and they aren't available in Flash authoring, then what happens? The power of choice wins again. Developers can still choose to use Cocoa, tap into these innovations, and user's can choose to purchase the apps that take advantage of these innovations. If these features are so great, one might expect that Adobe would try to bring them to Flash authoring as quickly as possible. Either way, the notion that the Flash platform would be held back makes no sense.

So Apple's self-described most important point is so false that it is laughable. Some of their other parts are equally false. For example, the notion of touch and Flash. Yes, many things in Flash are designed for users interacting with a mouse, not a finger. Such things don't work well on touch devices. However, this is not just true for Flash. It is equally true for HTML and JavaScript. If you've done a lot of surfing on your iPhone or iPad, you have surely experienced the "rollover" issues described in Apple's post. Want more examples? Check out this clever little video on HTML 5 and the iPad:


So why all the bullshit? As I said earlier, the reason for the post is to discredit any competitor that provides Flash support on their devices. First and foremost on that list is Android, which will support Flash in Android OS 2.2. That doesn't explain why Apple doesn't want to allow developers to use Flash to develop for the iPhone? The answer to that is simple. They want complete control of their platform. If you want to make money off of the iPhone, you have to be in bed with Apple. They saw how the web has hurt Microsoft, and they will not let this happen on the iPhone or iPad.

Now wait a minute, isn't Apple investing heavily in the web, namely HTML 5? Doesn't that demonstrate that they are willing to give up control of their platform? Yes, and no. Yes, Apple has invested into WebKit, a technology that in various forms implements a decent chunk of the HTML 5 standard. But you see, the key word here is "standard." This is how Apple fools you into thinking that they are providing an "open" alternative to their proprietary system.

It's easy to get fooled into thinking that any company that implements and open standard is innovative, but just the opposite is true. We think standards=innovation for browsers because of Microsoft IE 6. That browser dominated the world for a long while being completely stagnant. It was both non-standard and non-innovative, but this is an exceptional. It is rare that such technology can flourish. It took the unique nature of Windows, IE, and Microsoft's legal troubles to produce this situation.

Adopting a standard just means that you either change an existing feature of your technology to comply with the standard, or you copy a feature from others in the space. It is anti-innovation. When it comes to web standards, they are introduced post-hoc. XMLHttpRequest, the key technology behind Ajax, was proprietary Microsoft technology for many years before it became a standard. Many of the features of HTML 5 were introduced by various plugin technologies like Flash or Google Gears before they became part of the HTML 5 spec. You cannot innovate while waiting for some super slow moving corporate committee to vote on a new standard.

Going back to the iPhone/iPad, Apple is saying: pick either Cocoa and go through the App Store, or stick to the web, but only the "open standards" part of the web. They have given you a choice, but only the weakest, most impotent choice possible. You see this is where the other part of their Flash ban comes into affect. Not only have they recently banned compiling a Flash authored application into a native iPhone application, they have always banned Flash running in the browser. Why? Because with browser plugin technologies like Flash, Silverlight, and yes even Java, you can create user experience's on par with desktop applications. If they allowed Flash in the browser on the iPhone, then developers could create web applications that might rival the native iPhone applications. And we wouldn't want that, now would we? So Apple give you a single alternative to using Cocoa/XCode/AppStore, and then they horribly cripple it, by removing the most innovative parts and tying a design-by-committee-technology weight around its neck. Apple's endorsement of HTML 5 is one of the greatest marketing ruses ever. They stifle innovation, limit choice, and line their own pockets while getting everyone to believe they are being developer friendly and innovative.

After all of the above, you might think that I am very anti-Apple, anti-iPhone, anti-iPad. I'm not at all. I am anti-bullshit though. I don't like being lied to and treated like a lemming. Apple has every right to keep Flash off of their devices. It's their OS after all. They have very right to ban apps that were authored with Flash from their AppStore. It's their AppStore after all. Just don't lie to me about this stuff. Don't say it's better for developers or better for consumers, when it's actually worse for both. Just tell the truth: it's just better for Apple.

Friday, April 09, 2010

Thoughts on iPhone OS 4.0 and Section 3.3.1

I'm on vacation right now. Earlier in the week, I took my kids to the Kennedy Space Center:

Now I am in my hometown of Panama City, Florida visiting family and friends. However, yesterday Apple released the beta of iPhone OS 4.0. I read about it briefly on my iPhone while riding around town yesterday. Saw that it supported multi-tasking -- yay! Saw some nice features, like unified inbox, multiple Exchange accounts, geo-tagged pictures, etc. I was psyched, and planned on reading more about it later.

Later came, and I started reading more details on my laptop. Of course what everyone was talking about was Section 3.3.1. Soon I went from being psyched about OS 4.0, to being very annoyed about it. Now I know that some people do not think Apple is singling out Adobe, but it damn sure seems like a reaction to Flash CS5. Let's not forget that Apple also made several barely-disguised jabs at Google-owned AdMob while unveiling Apple's own iAd platform. OS 4.0 is all about Apple going after other big software companies that are making money or trying to make money off of the iPhone. However, in the process, Apple is going to take out other companies like Appcelerator. Not that Apple cares...

So yeah, Apple is screwing lots of other people who are trying to make a dime while at the same time enabling more developers to support the iPhone/iPad platform. Nothing to see here, move along. A number of people have pointed out that Microsoft in all of its monopolistic, evil ways never tried to pull anything like this. In fact, this is polar opposite of Microsoft. For all of their faults, Microsoft always supported developers. Sure they wanted to sell you Visual Studio, but if you wanted to use Java Swing or GTK or C++ using make, they did not care. Heck, they even weighed down Windows for years and years to maintain backwards compatibility APIs used by 3rd party developers.

Enough negativity... there are many good things about OS 4.0. The most obvious thing is its multi-tasking. To be honest though, it is fundamentally flawed. It is an "OS" feature that is purely designed around use cases. It's like Apple saw ads by Google/Verizon and Palm, that showed users listening to Pandora in the background, or using GPS, or receiving VOIP calls, and told their engineers "Can we do this without really enabling background processing?" Background apps are limited to these use cases: Pandora (music), Garmin/Magellan (GPS), and Skype (VOIP). That is lame. Background apps are also prohibited from networking (wait does this screw Pandora after all?) Better than nothing? Yes, but lame.

As part of this background processing stack, Objective-C blocks have finally come to the iPhone. Yep, that means closures. Of course, it's grafted on top of Cocoa, so that means you can't just take a button and set its event handler to a block of code. But again, better than nothing. Maybe we'll see some Cocoa evolution that will allow developers to take advantage of this.

Back to the meat of the background processing... One of the use cases mentioned above is geolocation. One of the new features added in OS 4.0 is advertising via iAd. As mentioned earlier, this is a clear attack on Google's AdMob platform. The impending explosion of advertising and constantly location-aware applications suggests that location based advertising could also see an explosion. Of course a background app that is location aware cannot make network calls, a prerequisite for fetching relevant ads. Ah, but they have iAd! Apple has positioned itself quite well to take advantage of mobile advertising.

Finally, I've probed the new version of Safari. It's version 532 of WebKit, up from build 528 in iPhone 3.1.3 and 531 in Safari 4.0.4. However, it still doesn't support Web Workers... Shortly after OS 4.0 was announced, Apple also announced WebKit2. This appears to be WebKit built on multi-processing, a la Chrome. No word on when it will come to the iPhone and iPad, but perhaps that is where Apple's efforts are these days.

Wednesday, March 31, 2010

iPad Web Applications

So you might have heard about this... This Saturday, April 3, there's a new computer coming out from Apple. You might have heard about it. Anyways, lots of iPhone developers have been scrambling to port their iPhone apps or write new iPad apps. A lot of folks have been predicting that developers would start to shun Apple after all of the controversies surrounding iPhone app submissions and the "walled garden" approach that Apple has taken. On the other hand, Microsoft has decided that a controversial walled gardens are once again the way to go, and is diligently copying Apple. Well if the iPad is any indicator, developers continue to agree with Apple and Microsoft. There is a lot of interest in developing native applications for the iPad.

Still, if you're like me and a big part of your job is to figure out how to build web applications for all kinds of devices, you have probably been spending a lot of time trying to figure out what to do about the iPad. On one hand, it's a big enough device that most websites will look just fine on it.

I think you must agree that the above looks a heck of a lot better than a "mobile optimized" site like this:

This seems great at first -- no work! Just make sure that if you are using any browser sniffing/redirecting code that it does not redirect for the iPad. However, there are some disadvantages to this. First, there are some issues with 'normal' sites that will not translate well to the iPad. There is the obvious thing with Flash... There are more subtle things like, "hovers", i.e. mouse-overs. That is when you toss up a UI layer when a user hovers their mouse over a link, or an image, or whatever. These are pretty popular, and they are not going to work on the iPad. Apple has quite figured out how to detect a finger hover... There are other events that are different on the iPad as well. There is also the question of how to best use the real-estate on the device, and the related question of dealing with landscape mode.
I think a lot of sites will look great in landscape mode, but that doesn't mean that they couldn't look better. It might be more optimal to go to a multi-column layout. That could let a site place useful content "above the fold", i.e. visible so the user does not have to scroll to get to it.

There's also the possibility of "embracing the native" on the web. There are a lot of iPhone-optimized websites that do a good job of making their website look and feel like a native iPhone application. Joe Hewitt's excellent iUi JS/CSS framework is an easy way to do this. The iPad has some of its own metaphors not found in the iPhone. Take a look at this native iPad app:


Notice all of those columns? We've kind of touched on that already. Did you notice the pop-over menus? These are likely to be ubiquitous on the iPad. Here is a picture of them from one of Apple's iPad apps, Numbers:
Obviously there is nothing in HTML-land that is quite like that. However, it is certainly possible to craft something similar. In a way, it's kind of like the mouse-over menus that are popular on the web, only the interaction model is slightly different and the UI is definitely more rich than the average mouse-over menu.

So what to do? Just stick with your "normal" site? Develop an iPad optimized site? Tweak your iPhone-optimized site to suck less on the iPad? Tweak your normal site to suck less on the iPad?

Friday, March 26, 2010

Programming and fallacies

Today I read a blog post by @joestump where he attempted to refute claims that Digg had been "doing it wrong" when they could not scale their database and went with a NoSQL attack instead. I'm not going to get into that flame war. I will say that folks at Digg should have expected exactly this kind of scrutiny when they decided to start bragging about their technology decisions. If a company has a technology blog, that is all they are trying to do -- brag. Anyways, back to the blog post... I was immediately disappointed to see that it was riddled with logical fallacies. I see logical fallacies all the time, and sometimes I forget that many folks are actually not very familiar with them. In particular, I would say that programmers are not very familiar with the "formal" concept, despite the fact that programmers tend to have very strong logical reasoning. Here is my attempt to do something about that.

First off, I am not going to answer what is a logical fallacy. You can follow that link, or find many other descriptions and enumerations of fallacies. Instead I want to talk about why programmers may not be aware of fallacies, and why it is important for them to learn about them. I think the reason that programmers may not know much about fallacies is that they are generally taught in classes on writing, public speaking, or debating. In other words, even though these are concepts tied to logical reasoning, including induction and deduction, they are not included in classes on mathematical logic. You cannot generally express a fallacy using symbols and computational expressions. This might lead some to believe that the fallacies are subjective, but this is not really true.

So why are fallacies important if they are not easily expressed mathematically, and thus difficult to represent programmatically? I suppose that if all you do is program on your own, then perhaps they are not relevant to you. If instead you work on a team with other programmers (or non-programmers for that matter,) then you will have ideas that are argued/debated. In this case, you need to understand fallacies -- so that you can express your arguments without committing a fallacy and so that you can recognize when people arguing against you are committing fallacies.

If you have an argument, and you find yourself committing a fallacy, then of course you will want to "fix" your argument to remove the error. This will inevitably draw out the assumptions in your argument, and strip out that which is not essential and true. Sometimes this will leave you with nothing, and you will be forced to question your own argument. Perhaps it was false or more likely mostly based on subjective statements, not fact. That can be a bummer, but wouldn't you rather realize that you are wrong than have somebody else point it out? Or worse, have nobody point it out...

You need to recognize when others are committing fallacies. At the very least you need to strike this from your own mental record of their argument. Does their argument make sense without the fallacy, or is it essential? Of course if you start noticing these kind of fallacies, then you may be tempted to point them out and use that to assert that their argument is false and thus your argument must be right. Oops, you just poisoned the well and committed a false dilemma.

Once you start noticing fallacies, you might notice that people commit them a lot. Sometimes this may seem to be true irrespective of the perceived intelligence of the committers. It is easy to make these mistakes when you are unaware of them. They are also much more common when people are "thinking on their feet." In fact, I had a professor who once joked that those who were good at thinking on their feet, were simply good at synthesizing fallacies. I'm not sure if that is a fair generalization, but you get the point. I think people are also much more likely to make these kind of errors when emotion has entered into the argument. I think that was the most likely case in the blog post that inspired this post.

Sunday, March 21, 2010

MIXation Sensation

This past week was Microsoft's MIX conference. I almost went to it, and I would have gone if it was not the same week as my oldest son's birthday. You gotta have priorities. Anyways, the reason I almost went was not because I have suddenly embraced ASP.NET development (even though I must admit my admiration for Scott Gu). No, my interest is all browser related and MIX was browser heavy this year.

On the browser front, the big news was the early preview of IE9. For web enthusiasts, it's fun to wax poetic about the mind blowing speed of V8 or the brilliance of TraceMonkey, but these technologies will always be secondary at best. If you are a web developer the most important browsers are the ones from Microsoft, because they dominate the market. They form the baseline that you develop against. If you want to do something that these browser do not support, you have got to get creative or be willing to live with your work simply being a toy. Simply put, IE9 news is more important than all of the Firefox, Safari, Chrome, and Opera news combined.

Luckily, Microsoft did not disappoint with IE9. It is obviously a far from finished product, and Microsoft was a little too dodgy on sharing its roadmap for my taste, but I can empathize with their position. Still they showed a browser with significant speed improvements and with support for a lot of standards based, visual eye candy. I'm talking about a lot of CSS3 features and most surprisingly, an amazing SVG implementation. They whipped out some classic Microsoft tricks, i.e. using their intimate relationship with their operating system to tap into GPU acceleration. You might think it's not a fair trick for them to do, but who cares? The boys at Mozilla, Apple, and Google have to accept this challenge, even if it will be super painful to pull of across platforms -- and Linux will surely suffer here once again.

I was a little disappointed in some of the other JavaScript features. In particular, I was really hoping that Web Workers would be included with IE9, and I was cautiously optimistic that geolocation would also be included. Neither is included in the IE9 preview that Microsoft made available to developers.

Of course that definitely does not mean that these features are out of IE9. I think there is a lot more to come. Microsoft has done some amazing work to give IE9 a lot of graphics features, but they have left out Canvas. Further intense graphics programming would benefit from the multi-threaded programming model supplied by Web Workers. So it would make a lot of sense for both of these to be added. I'm even optimistic that Microsoft will implement these standards directly, and not offer some proprietary alternative.

All of this makes you wonder about IE9 as a compelling graphics/gaming platform. I think that some serious tooling will be needed to make this viable. That's an area that Microsoft excels at. However, would this not put Microsoft in conflict with their own efforts around Silverlight? It's like the HTML 5 vs. Flash war could be played out in miniature within Microsoft's walls, only it would be IE9 vs. Silveright. Speaking of Silverlight...

The other big news, from my perspective at least, that came out of MIX was a lot more information about the Windows Phone platform. As a mobile developer, I have very mixed feelings about Windows Phone. On one hand, I really like the idea of using Silverlight as the application platform. This is a mature application platform, with fantastic tooling. You get to use a beautiful programming language -- C# (oh an maybe other .NET langs, like F#?) that has a decent runtime that includes garbage collection. However, Microsoft looks like they are copying Apple's approach. A lot of the restrictions being placed on non-Microsoft applications are very similar to the restrictions placed on iPhone applications.

Back to the browsers... Microsoft shipped a preview of tools for building Windows Phone applications. Again, major props to Microsoft for getting this software ready out at MIX, even if it is a little rough in places. I don't like companies using end users as a substitute for QA, but this is different. Getting tools into the hands of developers is critical. In this case, the tools include a Windows Phone emulator, which includes *drumroll please* the Windows Phone browser! As a mobile developer, this is the most important thing that can be included. I'll have to support your browser before I have to support your application platform.

However, the Windows Phone browser is not very promising. It seems to be based on IE7. It does not seem to support many HTML 5 features at all. No geolocation. No local storage. No application cache. No web workers.

Maybe some of these things will be added by this fall, but I'm not as optimistic about this. Even the documentation that is included emphasizes building web applications that are designed to work on legacy browsers. They seem to be saying, don't go looking for coolness in the browser!

Wednesday, March 03, 2010

Testing Geolocation for Mobile Web Apps

Using geolocation in a web application is really cool. The JavaScript API is quite simple. Testing it, can be a different story. Here are some useful tips:

If you only need to get the user's location once, testing is not too bad at all. First, you can actually use Firefox 3.5+. However, make sure that you are using wi-fi, or otherwise you will never get a location. Your app will just seem to hang. Anyways, being able to use Firefox for testing is great because it is a full desktop browser with awesome developers tools like Firebug. Often you will have some pretty complex JavaScript in a web application that uses geolocation, so being able to debug with Firefox/Firebug is invaluable.

Of course you will also want to test on mobile browsers. You can definitely use the iPhone simulator that is part of the iPhone SDK. Geolocation works great on this, but it gives you a bogus location -- the location of Apple's HQ in Cupertino, CA. If you actually live near Cupertino, this can be really misleading. Anyways, it will only give you this location, never anything else. So it is somewhat limited.

Testing on an Android emulator is another possibility. However, in my experience, it is currently broken. On an Android device, when a web page wants your location, the browser brings up a window to prompt you for permission. On the emulator's browser, I never see this permission window and the app just hangs and never returns a location. That's a bummer, since the Android SDK makes it possible to send mock GPS coordinates to an Android emulator. It would be great if web developers could take advantage of this.

Testing on an actual devices is of course a possibility. Your web application needs to be reachable by the device. This could mean using wi-fi on your device, so you are in the same intranet as your development sever, or it could mean deploying your app somewhere public. I like using the Google App Engine for the latter, and then test on the assortment of devices that I have laying around.

If you need to test location updates, i.e. when the user moves you want your web application to know about it and respond in some way, then things get trickier. The iPhone simulator is out of the question. An Android emulator still suffers from the same problems. So now you are down to devices. There is no way to send mock GPS to an iPhone, so to test on an iPhone, you need to actually change your physical location. Coding and driving FTW!

However, it should be possible to test on an Android device. The Android SDK theoretically allows you to send mock GPS to a real device. The command that should work is "adb -s XXX shell geo fix AAA BBB" where XXX is the serial number of your device (get it by doing "adb devices"), and AAA/BBB are the fake latitude/longitude. Sounds good, right? I tried this on my Nexus One, and got a big fat permission denied. Turns out you need to be root to do this on a real device. Ok, so I rooted my Nexus One. Then I tried it. Result? "gps: not found." Suddenly the gps command was not recognized. So ... coding and driving FTW!

Wednesday, February 24, 2010

The 0-Guard

Last week I was reading an excellent article by Bill Simmons on the "true" trade value of NBA players. While talking about likely rookie-of-the-year Tyreke Evans, Simmons dubbed him 0-guard. I thought that this was quite clever, and several other players immediately came to mind. Simmons went on to list three other players as 0-guards: Gilbert Arenas, Dwayne Wade, and Brandon Roy. I thought of some others. Here are what I would call the defining characteristics of the 0-guard:

1.) They must have the ball in their hands. These are players who generally useless on offense without the ball. They are not good spot-up shooters. They aren't going to move well without the ball to get open or get teammates open. They generally look lost in a half-court offense if the ball is not in their hands at all times.
2.) They are not good passers. Now many 0-guards rack up a lot of assists. However that is just because the ball is always in their hands. The only way they pass the ball is if the defense is all over them and teammates are wide open, hence the assists. However, they don't always do this very effectively. For example, in his best years Arenas averaged 6 assists/game, but also 3.5 turnovers/game while averaging 21 shots/game and 10 free throw attempts/game. Last year, Dwayne Wade averaged 7.5 assists/game, but that came with 5 turnovers/game, while taking 22 shots and 10 free throws per game.
3.) They can get their shot -- easily. This kind of goes without saying. All of these guys are effective at creating for themselves/getting open off the dribble, around screens, etc. If they couldn't do this, they would not be playing at all. Often they are spectacularly good at this -- Dwayne Wade for example.

These are the three obvious 0-guard characteristics. However, there are some other more subtle shared characteristics.

4.) They are poor rebounders. These guys want to get out in transition, so they do not hit the defensive glass and they make no attempts to box out anyone.
5.) They are defensive liabilities. Sort of a continuation from #4. All of their energy goes into scoring, not much is left for defense. Now some guys may average a lot of steals, but that is a notoriously misleading statistic when it comes to defense.
6.) Point guard size. Maybe this helps to explain #5 and #4, but these guys generally don't have the size to match up against shooting guards. This does not necessarily imply being short -- Wade is 6-4 and Evans is 6-6.

Given the above, I don't think Brandon Roy belongs on the list. For his career he has averaged 5 assists but only 2 turnovers per game, while taking 16 shots and 6 free throw attempts per game. That does not sound like a guy who has to have the ball in hand -- or maybe I'm wrong and he's just not a very good 0-guard. I think Simmons put him on the list because Roy demands the ball in his hands at the end of games.

There are some other obvious guys who belong on this list. Starting locally, Monta Ellis is definitely a 0-guard. This year he has averaged 5 assists / 4 turnovers per game, while taking 22 shots and 6 free throw attempts per game. This is definitely Arenas/Wade country. Brandon Jennings is borderline. So is Derrick Rose, but in both cases these guys are young enough to "grow out of it." Rodney Stuckey is a 0-guard, but not a very good one. Jason Terry also qualifies, but he doesn't realize it. He thinks he can spot-up and shoot, but he can't. 

Finally, I think Bill Simmons got it wrong when he said that Gilbert Arenas invented the 0-guard position. To me, the quintessential and original 0-guard was Allen Iverson. He had a season (01-02) where he averaged 5.5 assists / 4.0 turnovers to go with 28 shots and 10 free throw attempts per game! Now late in his career, he did become a better passer, but was still more of a 0-guard than a point guard.

Thursday, February 18, 2010

eBay Mobile for Android

I have been working on mobile at eBay since the fall of 2008. Almost immediately upon joining the team, I started running my mouth about how we needed to create an Android application. At the time, the G1 had just come out, and let's be honest. It was definitely a cut below the iPhone -- the standard that all phones are measured against whether they like it or not. The development environment was attractive, but we had to be pragmatic about things. eBay Mobile for iPhone was a big hit, and we had tons of ides for improving it. So Android had to wait. Yesterday, the wait was over and eBay Mobile for Android became available for download from the Android Market. It requires Android 1.6, and we have not rolled it out in all of the countries that our iPhone app is available in, so depending on your device and your location, it may not yet show up in the Market. If you're on 1.6, just be patient, hopefully we'll be in your country soon. If you're on 1.0/1.1/1.5... well your carrier needs to upgrade you to 1.6 :-)

The app was the result of a lot of hard work by some very talented engineers. If you have an Android phone, then of course I am hoping you will go try it out. One of the cool features of the Android platform that we took advantage of is integration with the system level QuickSearch. This makes it possible for popular search terms on eBay to be automatically suggested to you as type in the QuickSearch box on the home screen of your phone. However, this is one of those kind of curious features in Android. It is relatively easy to do (though making it fast, for something dynamic like popular search terms on eBay, can be tricky -- our engineers did an awesome job on this), but it is not something that you can "enable" by default. What I mean is that any application can become a provider for the QuickSearch box, but the applications cannot get their suggestions to automatically appear. Instead the user must manually enable add the provider, and this is not the most obvious thing to do. To give you an idea, I did a short video that shows you how to do this:

See what I mean? It's hard to expect that most users will figure this out on their own. Maybe we could put some kind of message in the app instructing them how to do this, but it is not something you can really describe succinctly. Anyways, as you see in the video, one you add eBay to your list of search providers, the results from eBay will only appear at the bottom of the list of suggestions. Once again, it would be very easy for a user to not even know that they are there. If they scroll down and find them, and do this a few times, then supposedly Android is smart and starts putting the eBay results closer to the top of the list...

I think this is something that Android could definitely improve on, since I think it is a great idea to allow other apps to hook into the "global" search if you will. I can definitely imagine the Facebook app and various Twitter apps doing this too. However, one could understand if apps did not do this, given how difficult it is for an apps' contributions to surface in the search suggestions.

Wednesday, February 17, 2010

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.

Sunday, February 14, 2010

The Anti-Netbook

For Christmas this year, I bought my kids (ages 4 and 5) their first computer: an Acer Revo. I call this the anti-netbook, but it actually shares a lot of things with a netbook. First is its processor, an Intel Atom clock in at 1.6 GHz. This helps to make for an incredibly small form factor, especially for a desktop computer. It has a 160 GB hard drive, but no optical drive.

When I bought the computer, I had exactly one reason for it. I wanted my kids to play educational games on it. That was all. The Revo came with Windows XP installed on it, and this was perfect. I needed Windows on there to get the largest number of potential games for it. Windows 7 seems to be much less of a resource hog than Vista, but I am still wagering that XP comes with less overhead.

I had another somewhat unusual plan for the Revo. It is completely isolated. No network access, not even local intranet. This is why I call it the anti-netbook. I want no Internet on it, I only want software that I personally installed to ever run on it. It is like a miniature Battlestar Galactica. Now I know there are a lot of websites with great games for kids, but I don't need them. I can find plenty of shrink-wrapped software to buy at incredibly cheap prices. However, this did lead me to some problems with the computer.

The first problem was how to install all of this software, since I had no optical drive. I was prepared for this. I simply copied the software to a flash drive and plugged that into one of the four USB ports on the Revo. This is where I encountered my first problem. Many of these titles require the original CD to be inserted into an optical drive in order to run the game. I suppose this is an anti-piracy tactic, but it really caused me problems. For a couple of the games, I could leave the flash drive plugged in and they were happy. This did not work for most of the games.

So I bought an external optical drive that could be connected via USB. This worked perfectly well, but it does mean that to change the games, one has to generally change discs in the external drive. This is not something that I trust my kids to do yet... I had one more nasty surprise in store for me. Many, actually most games published these days require the game to connect to the Internet, either to install or to play or both. There was a PBS Kids game we bought that was like this, and it was complete fail when we tried to install on the anti-netbook. So I had to make sure to only buy games that did not explicitly list an Internet connection as a hardware requirement, which generally meant buying a lot of older games. Still I found plenty of such games to choose from.

At some point I will want my kids to be able to do more with a computer. They will need a word processor. Of course I would like to teach them both to program. I would like to get them something like Mathematic/MatLab. And of course by then, they will need a computer that is connected to the Internet. When that day arrives, I will get them a Mac -- but probably not an iPad. I will teach them the old school ways!

Friday, February 12, 2010

The Truth About Europe

Earlier this week I read yet another fascinating post by Peter-Paul Koch. In this post, @ppk takes on developers who think that developing for mobile just means developing for the iPhone. He points out that the iPhone has a small market share, in terms of number of devices being bought or in use. He tackles the obvious counter-argument that the iPhone dominates in terms of mobile Internet usage in the US. In particular he points out that the US does not matter, since Asia and Europe account for a much higher percentage of mobile users worldwide. He is completely right, but if you are a mobile web developer, these facts are completely irrelevant.

It does not matter how many mobile web users there are in North America, Asia, or Europe. This has no bearing on how you design your site or what kind of technologies you choose to adopt. All that matters are the users of your site and what kind of devices they use. There can be 100x more smartphones in Japan than in Spain, but if all of your users are in Spain, then you should not care about Symbian's market share in Japan.

For a lot of sites, it is very easy to figure out where their users are because they are not localized. If your site is focussed on Brazil, then it's a good bet that most of your users are in Brazil. For sites that are international, things get trickier. This is a problem that I have had to deal with at eBay. Fortunately my job was easier because we already had a mobile site that was setup almost ten years ago. It is designed to support all devices, from old school WAP devices all the way up to iPhones and Droids. It has a presence in all of the countries where eBay has a presence. So there I had a lot of data to use where I could say "this % of our users are using iPhones, this % are using Blackberries" etc.

Most people do not have this luxury. If you do not have a specialized site for mobile, you can still look at your server logs and figure out what mobile devices are being used to access your site. However, you should be cautious with this data. If you do not have a specialized site, chances are your main site does not work properly on a lot of devices (especially true if you use a lot of JavaScript.) So chances are your users that use those devices will not use your site from their devices. However, chances are that your site does work properly on an iPhone, even if it is far from optimized for it. So iPhone users may be over-represented in your data.  You might want to fall back to using X% of users are from A, Y% from B, and the devices breakdowns in A and B are... Now if your site relies on Flash...

Let's get back to the @ppk's post and the iPhone for a moment. He makes a nice analogy to IE6 back in the day. When doing analysis on mobile eBay traffic and our strategy for the future, I actually made a similar analogy. There is one huge difference. The iPhone's browser, Mobile Safari, has been a front-runner in adopting HTML 5 standards. If you are optimizing for the iPhone, there is a good chance that you are in fact using HTML 5 standards. In other words, optimizing for the iPhone does not mean adopting a plethora of technologies that are proprietary to Mobile Safari. It's just the opposite in fact. This is the fundamental difference between Mobile Safari today and IE6 circa 2002. That is not to say that there aren't some technologies that are unique to Mobile Safari. There are. However, those are the exception, not the norm. Most of the code that you could write for Mobile Safari that would not work on other mobile browsers is actually standardized APIs that other browsers simply have not yet implemented. So yes, you could be excluding users -- this is where you need to figure out what devices your users are using -- but you are not putting up an iPhone-only wall. You are putting up a wall, but it is a "modern device that supports web standards" wall.

Wednesday, February 10, 2010

On Open Floor Plans

Way back in 2006, I was working for a startup, originally called Sharefare and later renamed to Ludi Labs. When I first joined Sharefare, we had an old office space in Los Altos. It was a "traditional" office space, divided up into offices, with only two large open areas. One was the front reception, and other was a break room area. While there, we had around ten engineers. We would put 2-3 engineers per office. It worked pretty well.

After I had been at Sharefare a few months, we received another round of funding, but it came with a catch. Our board wanted us to hire a "real" CEO, since our CEO/founder was a very technical guy, not an MBA type at all. Our CEO came from Under Armour, you know the sports apparel maker. He was an east coast guy, who I'm sure we paid a ton to relocate to the Bay Area. When he arrived, we were running out of space in our little old office in Los Altos. So he decided that one of his first priorities would be getting us a new office. He had a vision for the new office -- the floor of the Wall Street stock exchange. He wanted an open floor plan that would encourage collaboration and keep everyone energized. So we moved into a brand new office (we were the first tenants) with a completely wide open space.

Now I always attributed this hubris to our CEO being an east coast guy who had never really been around engineers. You see, engineers do not work well in hectic, loud environments like the floor of the Wall Street stock exchange. A very large part of their job is thinking, and people running around making noise does not help an engineer think. Lots of other folks have written about what kind of environment does work well for engineers, so I won't go too much into it. I'm just here to tell you what does not work.

The open floor plan is complete fail. The most obvious problem is the noise. First, most companies have some non-engineers who work for them. Some of these non-engineers really need to do a lot of talking to do their job. They need to be on the phone ordering office supplies, or talking to potential business partners, or screening new hires. These people constantly generate noise. Put that in an open floor plan, and there is always noise. This is a constant drain on other folks, like engineers and designers, whose work requires them to think a lot.

The next problem is that engineers and designers, do indeed need to talk sometime as well. Sometimes this is talking about work stuff, but there is also a lot of non-work stuff that engineers talk about. Maybe they are debating closures in Java or the merits of Python vs. Ruby. You want engineers who bullshit about stuff like that. Or maybe they are just talking about the Super Bowl or Lost. There is value in this too (y'know that whole "team building" thing.) Anyways, when you are in an open environment where noise is already problem, then it really discourages this kind of engineering conversations. If you are lucky enough to need to talk to your fellow engineer when it is relatively quiet in the office, you may be reluctant to engage him/her because you want to relish the peace. If instead it is during a typically noisy time, you will ask yourself if whatever topic is really worth talking about if it means shouting over the din. Instead of encouraging collaboration, the open floor plan does the opposite.

Back to Sharefare... It did not take long for everyone to realize that the open office was not working. First, we tried to put the engineers and non-engineers at opposite ends of the office. We had a handful of real offices that were intended for execs. Instead they were kept open, so that people could use them for longer phone conversations. I personally spent a lot of time in those rooms, doing phone interviews with potential new hires. Finally, the CEO came clean and admitted that the whole thing had been a bad decision on his part. He bought everyone Bose noise canceling headphones, supposedly out of his own pocket. This was his high point of popularity with engineering. Now when you walked into the office, everyone constantly had the Bose headphones on. I think this also hurt collaboration. I know I am personally less likely to try to start a conversation with somebody with headphones on.

Anyways, that was our failed experiment. It seems like the idea has been picked up more and more in the Valley. A lot of companies are opting for this configuration. I think some do it as a cost cutting measure. You can spend a lot less on furniture with an open floor plan, and you can pack in a lot more people in a given space. Others claim that it is all about encouraging collaboration. Again, my experience is that it will do the opposite. Still others do it because they want to break away from the traditional cubicle environment. To those folks I would say: "function over form." An ugly office full of productive engineers is better than a stylish office full of miserable engineers.

Friday, February 05, 2010

It's 2010, where's my HTML5?

This morning, one of my co-workers related to me that there had been mention of HTML 5 on an NPR broadcast that he heard. He joked that this morning there were probably lots of advertisers asking their designers about using HTML 5 for their next whiz-bang ad campaign. So obviously we are still in the early part of a hype cycle on HTML 5. So what's the state of the technology and where is it heading?

In terms of pure technology, there is a lot of notable progress. Google did the right thing recently and axed Gears. They had some nice innovations in Gears that have since been rolled up into the HTML 5 standard. Now it makes perfect sense to abandon their proprietary implementation, and embrace the standard. Gears is important because it is (or was) part of Chrome. Thus there are essentially five browsers that now implement a significant subset of HTML 5: IE8, Firefox 3.5, Safari 4, Chrome 4, Opera 10. According to the latest browser share numbers, that means that 53% of users out there are using a browser that supports a lot of cool features, like local storage and selectors. That's more than half! It's tempting to extrapolate from that, but don't get too carried away.

The #1 browser of the HTML 5 browsers, is IE8 -- which does not support a lot of the features that the other browsers support like canvas, video tag, and web workers. For those would be HTML 5 advertisers out there, you better scale back your expectations. For desktop browsers, a lot of the most compelling HTML 5 capabilities are far from being widely supported. How long until IE9 comes out? How much more of HTML 5 will it support? How long until there is high adoption of it? That's too many questions to be comfortable with. Ask me again this time next year.

However, it's fun to pretend sometimes. Let's pretend that IE 9 did come out soon and that it supported everything supported by Firefox and Chrome. Let's even pretend that Microsoft was able to awaken some of their old monopolist mojo and somehow force people to upgrade. So we have a world full of canvas. Will the next great annoying ad use this? If you read my last post on Flash hate, you probably realize the answer is no. As Terry pointed out in the comments there, the Flash authoring tools really empower designers over developers. So before we see an explosion of canvas magic, there will have to be huge strides made in tooling. Now what about video? Even in our dream world, there are issues known as codecs. There is no common video format that will run on both Firefox and Chrome right now, and who knows what Microsoft will do here (WMA FTW!) So we are going to need some technical consolidation here. Let's summarize all of the things that we need to see happen to open up the golden age of HTML 5.

1.) New version of Internet Explorer that supports much more of the HTML 5 specification.
2.) This new version of IE needs to become the dominant flavor of IE.
3.) Outstanding tooling developed to enable designers to leverage HTML 5 capabilities.
4.) Standardization on video codecs by browser vendors.

Don't get too bummed out about all of this. I actually think there is real progress happening on #1 and #3. #4 probably has to wait for #1 to happen. #2 is the most problematic. Since we're dreaming, maybe if IE 9 came out with H.264 support, Google could dramatically drop support for anything else on YouTube, and thus nudge all IE users to upgrade?

If you want to drink the HTML 5 Kool-Aid, and this is bumming you out, I'm sorry. You might feel better to know that the HTML 5 situation is significantly better on mobile devices. According to AdMob, 81% of internet usage in North America was either on iPhones or Android devices. Now, most of those Android devices are running Android 1.5 or 1.6, whose browsers (can we call it Mobile Chrome please?) still use Gears -- not HTML 5. Let's  hope that most of those are upgraded (by their carriers) to Android 2.1 soon, and then we're in business. We've got all kinds of HTML 5 goodness available to 80%+ of the users out there.

The bad news is that the mobile market is fundamentally different than the desktop (though, that may be changing.) Here mobile websites compete directly against native applications. Desktop users rarely face the question, should I use an app or a website to do XYZ? Normally XYZ dictates one or the other. So for a company, there may be a lot of cool stuff you can do with HTML 5 on a mobile browser, but there are even more cool things you can do in a native app. Not only are the native apps more powerful, they are generally easier to build because of superior tooling and cohesive architecture. Maybe JavaScript vs. Objective-C vs. Java is a matter of taste, but HTML 5 has nothing even resembling the application models presented by Cocoa and Android. Instead it has the DOM APIs in JavaScript. Now throw on the differences in tooling, and you can see why for many companies it is cheaper and easier to build an iPhone app and an Android app instead of building one HTML 5 app. That's not even considering the hypothesis that the "app store" model is more appealing to end users than the browser model.

Wednesday, February 03, 2010

The Flash Haters

The iPad announcement had lots of subtleties to it. One of them was that the iPad browser, presumably Safari, does not include a Flash plugin. This has lead to a lot of people from Adobe getting upset. What has amazed me through all of this, is that there is even more hate for Flash than ever before. As somebody who has done a fair amount of Flash development in my career, this has really struck me as odd. Why all of the hate for Flash?

In some ways, I can actually understand why Apple would hate Flash. The Flash plugin on OSX is nowhere near as good as the Flash plugin on Windows. Now Adobe will counter they spend a disproportionate amount of money on Flash for OSX, i.e. they spend more money per OSX user than they do per Windows user. So what? There are a lot of other technologies out there that work equally well on both Windows and OSX. Just focussing on web technologies, Firefox and Chrome on the Mac are very comparable to their Windows versions. So is the Java plugin. Some other products, like Opera and Skype, tend to trail in terms of features on OSX, but not in terms of quality. If these other companies can do this, why can't Adobe? It's obviously either lack of ability or prioritization. My guess is the latter, and hence you must expect hate from Mac users. And from Apple. So it should not be so surprising that Flash is left off the iPad, iPhone, etc. If Adobe really wanted to get Flash on those devices, an obvious first step would be to make Flash on OSX as good as Flash on Windows. That is something that Adobe can do all by themselves. Instead it seems like they would rather publicly bemoan their exclusion on the iPad. Now is there a guarantee that if they improved Flash on OSX, Apple would care? No, of course not. However, there is no way they will get on those devices without this first step, IMO.

Ok, so Mac user hate for Flash is understandable. Along the same lines, I would guess that Linux user hate is also understandable. That is, if there were actually any Linux users out there. I digress. I see a lot of hate from developers. What about that? That one is not so easy for me to understand. As a web developer, Flash has been opening doorways for me for a long time. Need to cache 30 KB of data on the client? For a long time this was impossible unless you used Flash (or maybe Java.) Need to make a cross-domain call? That is still generally impossible from the browser, unless you use Flash. Need to show 2D/3D graphs and visualizations? Again, this is still generally impossible, except through Flash. Oh and video... The only way to show a video that can be played on all of the top five web browsers (IE8, IE7, Firefox 3.5, IE6, Firefox 3.0) is to use Flash.

But, but, but, what about HTML 5? Many people think it will kill/replace/maim Flash. Apparently this list includes a certain Steve Jobs. As I have said before, I hate web standards. I mean, I love them, too. But I hate them mostly. Standards are the opposite of innovation, and perhaps its enemy. However, they are the engineer's best friend. Flash has provided a lot of innovation, that HTML 5 will simply copy and standardize. That is the best possible function of standards. However, the story is not so simple. Some things, like local storage,  are already supported by IE8, Firefox 3.5, and Safari 4. This is like Flash's SharedObjects, though slightly less powerful (but good enough.) Not everything is so rosy; canvas and video playback immediately come to mind. Canvas is particularly a hot topic. You can do some amazing things with it, but it requires payment in blood. I cannot imagine what it would be like to program Farmville in JavaScript using Canvas. Maybe somebody will come up with tools for that. In fact, I would be surprised if Adobe did not do this. Of course, we still need to hope and pray that canvas is supported in IE9...

So back to the original point. Why do developers hate Flash? It certainly enables them to do more stuff in web applications. Even if that list of extra features is being shrunk by the HTML 5 monster, it's still there. So shouldn't they love it? Well, you would think so, but they don't. Here are some guesses as to why:

1. Expensive tools -- Most of the tools used by a lot of developers are free. The Flash authoring tools are far from it. That can be annoying. You have to throw down a lot of money just learn something. That's not cool.
2. Bad tools -- At least from a developer perspective. The Flash authoring tools have historically been aimed at designers. That changed with Flex Builder/Flash Builder, but the damage was done. Also, those tools were aimed more at application development, which largely seemed like a waste of Flash.
3. Back to the Mac  -- A lot of developers use Macs, and we all know about Flash on OSX...
4. Accessibility -- Unfortunately this doesn't mean much to most developers. But it should. I must admit, that a year ago I probably wouldn't have listed this. However, as I have learned more, I have learned how Flash is such a huge problem for accessibility. This is actually one area where HTML 5 really shines, with the inclusion of the ARIA standards.
5. Design envy -- This kind of goes back to #2. Flash has had all the awesome capabilities for years, but they have largely gone untapped in web applications. Maybe by playing to designers all of those years, Flash has earned enemies. Imagine a developer being asked to scope some radical web feature. They give a typically large scope for it. His manager turns around and gets a designer, a freakin' designer, to do it in half the time.

What have I missed? Why do web developers hate Flash so much?

Friday, January 29, 2010

The iPad: A Brave New World

Has any piece of technology ever been more anticipated than the iPad? Has anything created as many extreme reactions? Has anything generated as much immediate ridicule?

Anyways, there are a lot of opinions out there, including some very good ones. I really like Alex Payne's take on the iPad. His post led me to Daniel Tenner's analysis, which is probably the closest thing I have seen to my own opinion. While we are at it, I think Timothy Blee's case against the iPad is definitely worth a read. Adobe's Mike Chambers has a very predictable reaction, but is still worth a read as well. But who cares about those guys, you're reading this because you want my brilliant insights, right?

I think the iPad is Apple's boldest move since the 80's. In the 80's, they liberally borrowed a lot of existing ideas and added some of their own twists to reinvent personal computing. It was no longer the command line driven process. There no need for Unix or DOS. The iPad is equally ambitious. 

Over the last two years, Apple has had a chance to experiment with a new kind of computing. The iPhone is accurately described as very capable personal computer that fits in your pocket. With it, Apple changed the way a user interacted with their computer. There was no more mouse, yet the keyboard was rarely needed. There was very little physical media to interact with, i.e. no floppy disks, CDs, or DVDs, only a very occasional physical linking to a desktop/laptop. Apple gave software developers a much more limited environment than they had ever had to deal with. Compared to desktop computer software, iPhone software is amazingly limited in how it can interact with the system (the iPhone). The distribution model was also controlled in a way rarely seen before. Apple had to approve your applications before they could be sold to users.

Yet even in this most restricted of environments, software developers have flourished. Why? As Joe Hewitt wisely points out, many of these restrictions really are for the best. I can install any app from the App Store, and I don't have to worry about it harming my iPhone. This is in stark contrast to desktop software, particularly the ubiquitous world of Windows. 

But wait, it's worse. At least if you're a software developer. The Draconian distribution machine that is the App Store and its approval process is a key part of this peace of mind given to iPhone users. It also makes their lives much easier. Just go to the App Store, and you can find whatever kind of software that you are looking for. Or just browse the games, or maybe lifestyle or social media apps, and you can find something interesting. Reviews are built right into the system. It could get better, and Apple is working on this with their Genius system, but it beats the heck out of anything else out there. 

The iPad takes this new model of personal computing and packages it into a personal computer. The iPad does not invent a new category. Just like the iPhone, it is going after an existing huge category, only this time it is the desktop/laptop category. Yes, this happens to be a category that Apple already plays in and is having a lot of success in. That is part of why this is so bold. The iPad is not going after the statistically insignificant category known as netbooks. Apple does not aim so low. Instead it is going after every person who owns a laptop.

Perhaps you think I am overstating, that Apple is not as bold as I claim. There were four new apps that Apple unveiled along with the iPad. One of those is iBooks, and I won't bother too much with that. The other three were Pages, Numbers, and Keynote. This is Apple's office suite. These are competitors of Microsoft's Word, Excel, and PowerPoint. Now you can read many Office documents on an iPhone, but it is largely a read-only experience. These are not read programs. These are content creation programs. If you think about the history of Apple, could there be anything more symbolic than them shipping a word processing application with their new computing platform? 

I bought my wife a laptop a couple of years ago. It was essential for her to have Office on it. Word processors and spreadsheets are the meat and potatoes of desktop software. Of course she uses photo management and media management software too. All of these things are available on the iPad. The truth is she could easily replace her laptop with an iPad. It would be easier for her to carry around, have better battery life, and the 3G would work even if she was visiting her mother (who does not have wi-fi.)

Think about all of the people whose job involves a computer. For most people, could they not do their job on an iPad? Wouldn't it even be easier in many cases? Of course it would be more convenient, again because of the size, battery life, and always being connected.

Now there will definitely be some people who cannot use an iPad for their job. I am one of those people. Maybe you could write code on it ok, but compile/debug? Don't think so. Designers who do intense things with Illustrator, Photoshop, etc. will need more than an iPad, too. Ditto for scientists, engineers, etc. There are more groups as well, but it's still probably a minority. For all of those people who have to do a lot of typing? Well there's a dock for that. You get the idea.

Apple is offering a new model for personal computing. They are attempting to disrupt an entire industry, once again. The iPad is not a big iPod Touch or a big iPhone. It is not Apple's attempt to go after Amazon's Kindle. It is an attempt to dominate in a way that even Microsoft never got close to. Apple is going to every person who owns a computer and saying "look there's another, better, easier way." I think it's an all-or-nothing bet. The iPad is either a world changer, or a total failure. Which one will it be? 

Wednesday, January 20, 2010

JVMOne

This morning, my co-worker Jason Swartz had the great idea of a conference focussing on JVM languages. This seemed like a particularly good idea, given the uncertainty surrounding JavaOne. Personally, I think the JavaOne powers-that-be have done a good job showcasing other languages, especially the last two years. Anyways, I joked that we could probably host it at our north campus, since it has proper facilities and regularly hosts medium sized conferences,  and that we just needed the support of folks from the Groovy, JRuby, Scala, and Clojure communities. A lot of folks seemed to like the idea, and had some great feedback/questions. So let me phrase some of these questions in the context of "a JavaOne-ish replacement, focussing on alternative languages on the JVM, but ultimately driven by the community". Ok here are some of the questions.

1.) What about Java?
2.) What about languages other than Groovy, JRuby, Scala, and Clojure?
3.) What about first class technologies with their roots in Java, like Hadoop, Cassandra, etc.?

Certainly I have opinions on some of these, but obviously any kind of effort like this requires huge participation from the developer community. So what do you think? What other questions need to be asked? If there is enough interest, I will definitely try to organize it. So please leave comments below!