Mulligan!

Customer Support Rule #1 - Don't be a Robot

2011-11-11T12:50:00.001-08:00

A recent user support interaction, pictured below, is one of many examples I've experienced where being honest and human goes a long way in winning over users, and humor doesn't hurt. You don't have to be 'nice', don't have to follow a strict template or be formal. You just have to communicate with your user like a real human being.

Users love it when they realize there's a human on the other end, and not a robot that's spewing stock replies crafted by corporate types. That is, often, the start of a loyal relationship.

Don't Let Apple's Latency Mess With Your iOS App

2011-08-22T10:58:00.000-07:00

Last week, I released an update for the iOS Audiogalaxy app which featured its first in-app purchase that allows users to 'pin' songs to their devices. Users can try the feature by pinning a limited number of songs for free, and are then prompted to purchase if they wished to continue pinning more songs. As suggested in Apple's SDK documentation, I built and tested the in-app purchase against the sandbox. After everything checked out as I expected, I submitted both the app update and the in-app purchase for approval by Apple.

The application and the in-app purchase were concurrently approved. After verifying that the status of in-app purchase product in iTunes Connect was "Ready for Sale", I released the updated application. It usually takes about an hour for app updates to start propagating to users, so I anxiously waited to get the update on my iPhone and verify that in-app purchasing worked fine. Once I got the update, I tried to purchase the in-app product but it failed. I had written code to handle potential errors, and looking at the error message I realized that the StoreKit API wasn't able to identify the in-app product I was requesting.

I went back and verified that the product identifier was correct, and everything still worked fine in the sandbox. Users had started hitting the same problem - not good! It's definitely not the best first impression for users to upgrade, try new features and immediately see an error. I scoured the web for clues and found a StackOverflow question which suggested that it can take up to 24-36 hours for in-app products to 'go live'. Uh-oh!

There is no mention of such a delay anywhere in Apple's documentation, and neither is it reflected in the status of the in-app purchase product. If I had known, I obviously would have waited to release the update. Apple doesn't provide the ability to roll back to previous versions, so basically I was SOL. If indeed it took ~24 hours for the in-app product to show up, it could be disastrous. The fallout could include:

Disappointed users. There is nothing more disappointing that looking at the "What's New" section of an app before upgrading, getting excited and then watching the feature just not work as expected.
Negative reviews/ratings. App Store ratings/reviews provide a medium for users to vent their frustrations or to shower praise. For developers, it's really a matter of making sure that the people with exceedingly pleasurable experiences with your application exceed the number of people with even remotely dissatisfying experiences. Audiogalaxy was a 5-star rated app, but this snafu could potentially affect that negatively, really fast.
Personal disappointment. I take a lot of pride in making sure that I deliver delightful experiences to users, and this would be the exact opposite of delightful. The hurt would be tempered by the fact that this was beyond my control, but it would hurt nonetheless.
Lost revenue. From my experience with in-app purchases on Android (and now also on iOS) it was abundantly clear to me that purchase volume is very high in the first few days of a new in-app purchase being available. Users upgrade, try what's new and buy it if they like it. If they're unable to, they might never come back to buy it.

I was really hoping that the problem was the delay-to-propagate issue and not anything more serious. Damage would be limited if the in-app purchase went live before too many users upgraded and started using the new feature, and I was secretly hoping that this was a matter of a few hours instead of 24-36 as suggested in the SO question.

I started monitoring how many users were pulling down the update and trying this new feature (yay for building simple monitoring tools that are fully in your control) and also dumping these userIDs into a table so I could keep track - a subset of these users were (hopefully) trying to purchase the add-on, but were failing to do so. The number started growing rapidly, and I began to panic. 5-6 hours later, the in-app product still wasn't live, negative reviews had started showing up and folks had started emailing us to let us know.

Watching user behavior, I knew something needed to be done. We decided that the best option was to make it impossible to even attempt to purchase the add-on. I updated the server to make it believe that all iOS users had already purchased the add-on - the app would then automatically hide all purchase related options. The plan was to just let everyone use the feature for free until the in-app purchase showed up for real. I wrote the code, tested it and pushed it to production. I watched it work for a bit, and then went to sleep.

The next morning, 14 hours after the status was "Ready for Sale", I was finally able to purchase the in-app product from the app. Thankfully, the server tweaks had helped and there were no new negative reviews or support emails. I rolled back the code from the previous night and waited for purchases to start showing up. Within minutes, I could see folks buying so I knew things were working fine now.

The last thing that needed to be done was informing users who might have previously had trouble and might potentially never try buying again. I wrote a script to run through the list of all users who had tried the feature and to send them a personal note thanking them for their support, explaining what had happened and letting them know that the in-app purchase was now available if they wished to purchase it. A surprisingly large percentage of users went ahead and purchased it, and a few also went back and updated their reviews.

I took away three lessons from this experience -

Design your apps/clients to be as dumb as possible and the server as much in control as possible. We've always tried to do that with Audiogalaxy, and it certainly helped in this situation (as it has on a few previous occasions).
Spamming all your users isn't a good idea, but it's perfectly OK to email a subset of users directly impacted by specific issues. Users are receptive to personally addressed emails with honest dialogue, and don't consider it spam.
Wait for 24 hours before releasing iOS app updates if you have added new in-app purchases.

All in all, this didn't turn out as badly for us as it could have - but it shouldn't have happened. I still believe Apple is at fault for not communicating this information to developers, but that's not a rare occurrence for Apple - it's best to anticipate and prepare for the unexpected. I hope this blog post helps other who might be planning to add in-app purchases to their apps. In addition to better documenting such gotchas, it would also be awesome if Apple added the ability for developers to roll back to previous versions (or at least 1 previous version) like Google's Android Market recently did.

A Capitalistic Fix for America's Broken Immigration System?

2011-06-22T15:01:00.000-07:00

Immigration in America is broken. There is no way to sugarcoat it, unfortunately. Failure of the administration to separate legal and illegal immigration concerns and to treat the politics of both as distinct from each other is jeopardizing the future of America.

There are several articles, memos and blog posts which articulate what is wrong in a lot of detail, so I won't repeat those. To illustrate the problem though, here is a short blurb about my own situation.

I have been a legal immigrant in America since I arrived to study Computer Science at the University of Texas at Austin in 2000. I graduated with a BS in Computer Science, interned at National Instruments for many months and went on to work at Microsoft for several years. I now work at a software startup. I'm a legal resident alien, but I'm still awaiting my permanent resident card ("green card"). I've been in the US for over 11 years now. I pay my taxes (TurboTax computes that ~16% of all income I've earned over the last 10 years has gone towards taxes, and this doesn't include local sales taxes), I occasionally speed on freeways and get pulled over, I spend money to stimulate the local economy (Mint.com says I spend ~2.5x what the average American my age spends), I eat junk food, I save money for retirement and invest it in American companies, I volunteer at a local high school, I support the Texas Longhorns and the Seattle Seahawks, I drink a lot of coffee, I donate to local and international causes, I whine about the weather... basically, I do what most average Americans do. I have a decent life here in America, and I'm thankful for it. But, barring any change in legislation, the estimated date for my green card being issued is 2024. Yep, that's not a typo. If nothing changes, I will get my green card 24 years after I legally entered the United States of America. Not citizenship, just permanent residence!

I assume I don't need to explain to any reasonable person how ridiculous and ironic this situation is, given that American was built by immigrants. I won't get into how my personal and professional life are impacted by this silly situation. Instead, I want to propose a possible solution, one that I haven't heard mentioned previously.

What if one of the criteria for issuing a green card was - if your stay in America has been legal and you have paid more in federal+local taxes than the average American pays over his/her entire lifetime then your green card application should be fast-tracked.

If this sounds too simple, it's because it is -a simple, capitalist, pragmatic approach to immigration. This rule ensures that prospective immigrants enter America using legal means and remain legal, that they are employable and have documented income that is in line with or exceeds that of average Americans, that they will not be a burden to society but an asset and that they have an incentive to contribute to the success of their adopted nation.

Thoughts?

Unfortunately, immigration reform is a political issue instead of a practical one, and a solution to legal immigration doesn't seem possible without a solution to illegal immigration (which just baffles me - anyone know why the two are joined at the hip?). America and Americans will eventually have to suffer the consequences of such nearsightedness, I fear. Illegal immigration is a political minefield though, so I don't have much hope for any real reform anytime soon, but then again... "hope and change", right?

Some Notes on Implementing In-App Billing on Android

2011-06-20T22:42:00.000-07:00

About a year ago, I implemented in-app payments for iOS, and it was painful. Technically, it wasn't too hard but there were a number of hoops to jump though to get everything working. Lack of clear documentation and undocumented error responses seemed to be the primary problem - I think a hold up with verifying tax information on the developer account resulted in strange, undocumented failure codes in my case. There were several dozen blog posts complaining about many such "magic" issues back then. It was almost comical, to be honest.

This last weekend, I decided to add in-app billing to an app that's already shipping for Android, and I ran into a couple of hiccups that I think are worth documenting here to save others some time/pain. Overall, I think the Android folks learnt from some of the pitfalls that early developers hit with in-app payments on iOS and worked to fix those. The documentation is a lot clearer and precise compared to where iOS was a year ago. Android Market also has a nifty static test/response facility which makes it easy to test code without worrying about external influences. iOS was desperately lacking something of this sort (not sure if it's better now) - I even wrote a dummy implementation of the iOS in-app payment API and the different response conditions to let me test my code in an emulator, which was really helpful. I'm glad Android got this right (still no testing in an emulator though, which is a bummer because of the inability to test with different Android OS versions).

At a high level, the in-app billing protocol on Android is extremely chatty (see the diagrams on this page). It seems particularly so when compared to PayPal's rival offering. PayPal's in-app billing module handles payment using startActivityForResult and onActivityResult methods which can be used for communicating between child/parent activities. This is very similar to how Facebook's Android SDK handles single sign on. That model is extremely simple to understand and implement for developers - you could probably have it coded up and tested faster than you can finish reading this blog post. I think part of this chattiness is to ensure a higher level of security and also to handle managed purchases, which are both likely harder to do using PayPal's approach. I assume they had good reason to make it as chatty as it is now, but my gut says that Google loses out on a lot of developers because of this apparent complexity. Having said that, the sample application Google provides does a really good job of illustrating the various communications that need to occur, so studying that code makes the chattiness easier to understand (for some reason, code registers more easily in my brain than verbose documentation - good code and good documentation together are very rare, and Android seems to have gotten this right - kudos!)

One of the biggest red flags with using Android's in-app billing, however, is the development teams non-responsiveness to critical bugs. This issue, marked critical and accepted, talks about transactions failing 4-6% of the time, and has been active for over two months without an owner being assigned. An equally disturbing issue with unacceptably long latency when handling authorization has been open for almost two months without any comment from Google or even an owner being assigned. In fact, browsing the issues list certainly doesn't inspire confidence in the platform. It would be a big mistake by Google to not take these issues seriously. In my case, I'm certainly debating the merit of jumping into this as an early adopter.

Some other notes about implementing in-app billing on Android:

It sounds obvious in hindsight, but you need to make sure that your application is signed with the release key before testing in-app billing, even the static response stuff. Developer's aren't used to doing this while debugging, so it's worth calling out in the documentation.

If you want valid signatures for the JSON responses as suggested by the table here, the "debuggable" attribute in the app manifest should be set to false, even if you're using a release-key-signed APK and static responses. I was a little annoyed by this un-documented restriction because it basically meant that I had to resort to using logging as the only real means of debugging my code. If there is indeed some way to debug this using a debugger (and yet receive valid signatures), it’s definitely not obvious to me. Again, not a terribly big deal once you realize that this attribute actually seems to affect signatures, but that isn't documented anywhere.

If you're using a server to validate signatures (as you should), be aware that the public key you obtain from the Android Market profile page is a base-64 encoded string. You will almost certainly need to convert it to PEM/DER format or use the x509 certificate for it to be usable with most server openssl implementations. For instance, this command can be used to convert the base-64 encoded key into a key usable by PHP:
```
openssl enc -base64 -d -in publickey.base64 -A | openssl rsa -inform DER -pubin > publickey.pem
```
Also, if you're using the PHP function openssl_verify, remember that $signature needs to be the binary signature, not the base-64 encoded signature string that the Android Market app sends (I found out the long way).

Unavailability of subscriptions/auto-billing is a big gap in the offering currently, but I assume support for it is coming soon, since iOS already supports it.

I hit an issue when testing payments using carrier billing, where accepting the carrier ToS basically causes the transaction to get lost somewhere between the carrier and Android Market. I logged this bug to track the issue.

Well, I hope that the web-search spiders do their job and this post helps others out there looking at implementing in-app billing on Android. And making Google get a move on those bugs.

Discuss this post on Hacker News

The India-Trip Penalty

2011-03-03T21:42:00.000-08:00

Vacations to India from America have a pretty high fixed-cost that significantly eats into the time that can 'actually' count as vacation. Here's the composition of this 'penalty':

Average flying time to get to India, if you don't need a connecting flight at the destination, is 18-22 hours each way depending on where you fly from, the route and layovers. Assuming the actual flight time is an optimistic 20 hours, let's add the 3 hours that it takes to head out to the airport/check-in/security/etc each way, and another 2 hours to clear immigration/customs/etc each way. So, the time to get to and from the vacation is 50 hours.

When you fly half way around the world, it's hard not to get jet-lagged. Optimistically, you've got to account for at least a half day (a very optimistic assumption) wasted on both ends of the trip. So you have another 24 hours spent jet-lagged.

A special perk of visiting India is the high probability that you'll fall ill. Over the years, I've noticed my immunity to the Indian environment (food, water, air, etc) fade. This is true for most people I know who have lived outside of India for > 5 years. During each trip, it's very likely that you'll catch a stomach flu, get food poisoning, a fever, or generally fall sick. If you're lucky, it takes a day of complete rest and another half day of extreme caution to get back on track. So that's another 36 hours of lost vacation right there.

Packing for a trip back from India isn't like packing for a quick flight to San Diego. A good deal of your last day is usually spent planning to pack, and then packing, and then re-packing to make sure your bags are all within weight limits. For those who don't live in metro areas, there's the additional time of travelling to metro areas. So let's throw in another 6 hours for all this.

So the total penalty of a trip to India is, roughly, 116 hours (a little under 5 days). Regardless of how long your vacation is, you're likely to incur this penalty, give-or-take a few hours. Heck, I would consider a 5-day trip within the US, or even a quick 5-day trip to Mexico, to be a decent vacation in itself.

It's pretty amazing to think that for many, the penalty of a vacation to visit friends and family is a whole other vacation. It's no wonder that most people who go to India need/want at least 3 weeks for the vacation to be worth it, and even then they feel gypped (rightly so?).

This also puts into perspective things that you otherwise might not think about. How much would you pay to avoid a 6-hour layover in Amsterdam en-route to India? Would a business-class ticket be worth the time it helps you shave off with airport formalities, jet-lag and worrying about luggage limits?

Hey Bing, iOS isn't Windows Phone 7

2011-01-26T10:46:00.000-08:00

The Bing app for iOS was decent, until recent updates. It looks like someone at Microsoft decided they needed to make the Bing app for iOS look and feel more like a Windows Phone 7 app. So they did, and the result is an ugly, unusable disaster.

On Windows Phone 7, buttons look like traditional 'labels', but in lower-case font. Clickable elements are very subtly different from text, but yet it's obvious what is clickable and what isn't. The hardware 'back' button, standard on all phones, is used to dismiss modal dialogs. That's how the native interface of the phone (called 'Metro', I believe) is, and it all comes together quite beautifully. Here's what a menu on a native Windows Phone 7 app looks like:

On iOS, buttons looks like, well, buttons. Clickable elements have depth and curves and are strikingly different from text/labels. There is no hardware back button, so Apple has provided built-in buttons with system fonts and colors which are placed on the top right corner to dismiss modal dialogs. Just like Windows Phone 7, it's well thought out, coherent and comes together beautifully. Here's how menus, buttons and dialogs look on iOS.

Good apps follow Human Interface Guidelines of the platform they're built for, which gives them consistency with the rest of the system and makes interactions with the application intuitive. For some reason, the developers/designers of the Bing iOS app decided to follow the Human Interface Guidelines for Windows Phone 7 for their iOS app, instead of following the iOS HIG guidelines, and the result is just awful.

Below is what a modal menu on the Bing app looks like on my iPhone (the rest of the app looks similar, and has the same flaws). I have been using apps on my iPhone for two years and yet it took me several minutes to figure out what I needed to do on that dialog. It wasn't obvious how to toggle options on the menu, nor was it obvious how I could dismiss the dialogs. It took me a good two minutes to realize that the 'done' label was infact a button, and that almost everything on that screen was clickable, except the tiny header that reads "MENU". The font size on that label (page header) is smaller than that on the label-buttons, which sounds inverted, and makes the page look ugly.

Compare this with the image below and notice how obvious and beautiful some of those same options are on the native iPhone mapping application. (This isn't a modal dialog on the native app - if it was, I can guarantee that there would be a blue 'Done' button in the top right corner).

In fact, the entire experience of using the Bing app is so jarring that I refuse to use it at all, in spite of some of its nifty features. And I would be very surprised if I'm the only one who feels that way. It literally feels like Microsoft ported an app that is likely beautiful and usable on Windows Phone 7 to iOS without putting any thought into iOS usability. In fact, my guess is that the developers spent more time trying to make those buttons and table-views looks like Windows Phone 7 than they would have if they just used what the system provided with minor tweaks.

I cannot come up any reasonable explanation for why the designers of Bing chose to do this. If they want their application to be used, I sincerely hope they fix it soon.

On Mediocre Software - Where is the Love?

2011-01-21T15:30:00.000-08:00

A recurring theme in some of the feedback we've seen for Audiogalaxy in reviews and direct feedback from users is how surprised they are when everything just works. A lot of the praise that the product has received goes something like this:

"Having tried and failed with several similar products I was shocked that when I used Audiogalaxy, it worked! No long delays, no dropping back to the initial screen, no anything wrong, just the music playing for as many hours as I needed."

"It does exactly what it's supposed to do. How often do you see that?"

"I never write reviews because most apps usually suck, but this is... different."

I won't feign modesty - we've worked pretty hard to make sure that Audiogalaxy works well. But that's not the point of this post. What statements like the ones above imply is that users are accustomed to underwhelming software. Most people, it seems, approach new software products with skepticism and wariness. Having been bitten by bad software several times in the past, they have become conditioned to assume the worst, and to be surprised when software works as it's expected to. While this might be true of other things too, in this case it points to a collective failure of the software development community. Commoditization of software developers/development and easy software distribution channels seem, on the surface, a boon to the software industry but are also a root cause for this mediocrity that people seem to now expect.

A telling sign of how extensive this perception is the following email I received from a friend after he used Audiogalaxy:

"Frankly speaking, my expectations were not very high. I was like, 'it's gonna be yet another process sucking the life out of my machine'. I was expecting to spend at least 30 minutes configuring everything, but was pretty much done in a couple of clicks and listening to music in a couple of minutes. It blew away my expectations in terms of how light weight it was (like 5 MB of memory and close to 0-1% cpu) and also super responsive in the browser to!!!"

On the surface, this comment seems to fall into the same bucket at the others above. However, this friend is actually a really good software developer himself. So this default notion of 'crappy software' isn't just users' perception. It is a dirty insider secret - we know about it, we expect it and yet we just suck it up and deal with it.

It's time to fix this, my fellow software geeks. You may say that people will vote with their money, and that bad software will fall by the wayside, and that the wheat will separate from the chaff, yada yada... All that may be true. But by producing crappy software, we're diluting the value of software as a whole, which eventually trickles down and affects each one of us.

Now this is the part of the post where I really should offer a silver bullet that will 'fix it all' and permanently change users' perceptions. Alas, I'll leave that to folks who are smarter than I. The one thing that I've learnt in my short career, and the only advise I can offer is this:

Build software with love, nurture it with care, take pride in its successes and share blame in its failures.

This mantra won't make you write bug free code or automatically make your software user friendly overnight - that's what experience, skills, iteration and good engineering practices are for. Heck, no software developer is anywhere close to writing 100% bug-free code. However, it will guide you in making decisions that lead to good, solid software which does what it says and says what it does. After all, software isn't just code - it is the culmination of every decision made in its journey from its inception to its current state.

A world where bad software/technology is an anomaly, not the norm, would be a good world - and it starts with us.

Off the Grid - Food, Diving, Love and Cholera in Paradise

2010-12-25T23:25:00.000-08:00

Bula! We recently took a trip to the Fiji Islands, and I took this opportunity to go completely off the grid - no cellphone, no computer, no TV, no newspapers. I was afraid I wouldn't last the week and succumb to withdrawal symptoms, but I decided I would give it my best shot. Not happy with just being off the grid, I decided to bring a book with me. If I read it, it would be the first book I would read in almost 4 years. I had heard great things about Love in the Time of Cholera and it was a genre of books I hadn't ever attempted to read before, so I figured it would be ideal. As luck would have it, the King Country public library in Bellevue (a most excellent library, by the way) had the book available to check out.

Well, turns out that the world does continue to turn even if I don't read the news, write some code, catch up on blogs and scan Facebook.

It was a great week full of excellent scuba diving, phenomenal tropical foods and magnificent living in resorts bathed in luxury and relaxation. We spent a few days at Outrigger on the Lagoon near Sigatoka on the main island, Viti Levu. It was larger than I would've preferred, but our plan here was to primarily relax and explore some of the surrounding villages/towns and interact with local Fijians and experience Fijian culture. We did 2 dives at Beqa Lagoon, but saved the majority of our diving for the latter half of our trip, which was near the more renowned dive sites. Instead, we spent a day relaxing at the resort and enjoying a local bar and another exploring some not-so-touristed surrounding. We got invited to dinner at a local family's house (our taxi driver, who happened to be a 4th generation Fijian Indian), and it was a humbling experience. Our hosts were a warm-hearted family who lived in a modest home in a tiny village who served us lovingly prepared Fijian dishes. The fish lovo, made with a snapper that was caught the previous night, and vegetable curry made with Taro root and star fruit, were delicious.

At the end of this part of the trip, I was done reading about a third of my book, and I hadn't felt the urge to get wired in at all, although internet access was readily available. I read by the pool, on the beach and in the lounge - the book was more interesting than I had imagined, and written in a style that was very refreshing.

Our next stop was the Namale Resort & Spa, home to the Sexiest Villas in the South Pacific. I knew the resort was good and I had lofty expectations for the price I had paid, but it exceeded my every expectation. From the warm welcome to the teary send-off, I could not have imagined a better way celebrate love. We spent the mornings diving, after having devoured a scrumptious breakfast. We were lucky enough to dive Chimneys and Grand Central at the Namena Barrier Reef on our last day of diving. I cannot imagine a better dive site than Chimneys anywhere in the world. It was magical - I think I could dive Chimneys every day for a year and still be amazed after every dive. After diving, we would partake of the phenomenal 3-course lunch served at a location of our choice (beach, deck, bure... anywhere we felt like eating) and spend the afternoon lazing on the beach, in the spa or indulging in more water activites (snorkel, water ski, etc). After that, some more R&R and drinks to whet the appetite for the gastronomical extravaganza that was dinner, accompanied by island cocktails or wine pairings and the Kava Boys. Every day, we were made to feel special with several personal touches by the staff at the resort - they really treated us like family. If there is paradise, Namale was pretty darn close to what I'd like it to be.

My reading progressed surprisingly well, and I found myself carrying my book to the beach, to the spa and to the outdoor jacuzzi. Save for about a 100 pages in the middle, I was enthralled by the story and the writing. I completed the book at the airport lounge prior to departure, and it had lived up to it's hype. It was Gabriel Marquez' ode to the myriad forms of love - spurned love, unrequited love, illicit love, love at first sight, true love, love that grows and fades over time and love that cannot really be classified. I got lucky with this book - I couldn't have picked a more appropriate book for the occasion. The fact it was a literary masterpiece didn't hurt either.

Anyways, all good things end, and so did our week in paradise. I hope one day to return to this lap of luxury in the midst of the friendliest people in the world. Until then, it's back to regularly scheduled programming.

Fun facts about Pilots

2010-09-28T18:14:00.000-07:00

On a recent flight, I sat alongside a pilot who was returning home to the Seattle area. A lot of interesting things came up in my chat with the pilot, stuff I didn't really know about:

Pilots fly free on all domestic routes, regardless of airlines. All airlines have an agreement to lets each others' pilots occupy empty seats.
If no seats are available, the travelling pilot can also occupy an extra seat in the cockpit that is usually empty.
Pilots retire at 65(!).
The pilot I spoke with had been flying for 30 years. His pay/benefits today are half what they were 20 years ago (adjusted for inflation).
Until ~10 years ago, most commercial pilots came from the military (air force/navy). Now, it's about 50% military and 50% from pilot schools.
For pilots, career all about seniority. If this guy (a captain currently) were to leave his airline and join another airline he would start as a flight engineer. That's one level below first officer, who is below captain. This is a result of unionization.
Flights longer than 8 hours require 3 pilots (1 captain and 2 first officers) to rotate flying duties. Flights longer than 12 hours require 4 pilots (1 captain and 3 first officers). They usually fly 3-4 hour shifts.
Pilots at traditional airlines (American, Continental) make more than pilots at startup airlines (Virgin America, Jet Blue).
Airlines like Horizon Air/American Eagle/etc serve as training grounds for pilots, who then move to the more lucrative airlines.
On average, pilots fly between 9 and 14 days a month.
Pilots train on simulators every 9 months, and typically work on hard scenarios like dual engine failures once every couple of years.
Boeing and MD planes have "steering wheel" type controls. Airbus has fly-by-wire joystick like controls.
A 737 needs about 6000 feet to land comfortably. Headwind makes a huge difference in amount of runway needed.
Airbus planes felt more "robust" to this pilot.
Bird hits are more common than passengers realize.
Tegucigalpa, Honduras, is the hardest airport that he's landed in. Overshooting the 5000 foot runway drops you off a cliff and on to a strip mall. There have been 2 crashes in the last few years, with one dead pilot.

Google Instant's biggest win? Teaching users to search better

2010-09-09T10:29:00.000-07:00

The biggest impact of Google Instant is that it teaches users how to search more effectively. Based on these dynamic results, users can tweak their query such that it helps them find the exact answer they were looking for, even if they started with a bad query. Teaching users how to improve their search query is huge. The immediate impact is that it improves users' perception of Google's search results. Same with speed - users will perceive Google as being much faster than anything else out there because of the instant results.

Perception is reality. Speed and relevance are a search engines bread & butter. I think Google just upped the ante by a lot.

Credit to Microsoft though - this probably wouldn't have happened if it weren't for Bing's recent gains. Proof that competition provides the best kick-in-the-pants needed to innovate.

Integrating Core Data into your Three20 App

2010-09-03T12:30:00.000-07:00

The Three20 library for iPhone app development is pretty cool - it take care of a lot of the 'mundane' code that you might need to write to accomplish basic tasks. Apple really should include some of the functionality of Three20 in the iPhone SDK itself, specially the Network stack.

As I built a more advanced app using Three20, I realized that it would be great to be able to persist to a database to make loading quicker when state on the server is unchanged. I needed some pretty basic Core Data integration in my app, and it was a little annoying that Three20 didn't have a Core Data-backed implementation of TTModel built into it. It seems like a lot of people want this, but there isn't any good post about it I could find. Jeff Verkoey, who currently maintains Three20, started writing a Core Data based tutorial but didn't get around to actually doing much with it. And there are a few threads in the Three20 Google group but nothing too comprehensive.

Having built this for my app, I figured I would post some more concrete information here for others who might find it helpful. I really want to just contribute a clean cut of this code as a TTCoreDataModel with unit tests to the Three20 source, but I don't have the luxury to spend time on it currently.

So here's a quick step-by-step on how to modify your existing Three20 based app to add basic Core Data support. The specific example I use fetches data from a server using TTURLRequestModel and writes it out to SQLite using Core Data entities. When displaying data to the user, it fetches data from Core Data using a NSFetchedResultsController, which efficiently interacts with Core Data.

Step 1:
Add CoreData.framework to your list of dependencies. Then, add the Core Data stack. Usually, you would do this in the AppDelegate. Jeff's AppDelegate files have this implemented, if you want an example. In my case, I wanted different databases for different Models, so I had these in my TTModel implementations.

Step 2:

Create your model. Add a new file of type "Data Model" in XCode (available in the 'Resource' section). Make sure the .xcdatamodel file gets added to your Target so that it's compiled into your binary. Look here for information on using the modeling tool. Once you've created your model, import the code for the Entity objects into your project. Now you're ready to start using Core Data.

Step 3:

Update your TTURLRequestModel implementation. Let's assume you're simply downloading some JSON and want to write it out to Core Data as an Entity you created in Step 2. Update your (void)requestDidFinishLoad:(TTURLRequest*)request implementation of TTURLRequestDelegate as follows:

A few notes about the code above:

DBResource is my simple entity containing an "id" and a "name".
The NSAutoreleasePool helps clean up memory allocated in this tight loop here
-reseting the context makes sure that the data faults in as needed instead of staying in memory when you read it using the NSFetchedResultsController

Step 4:

In your TTTableViewDataSource implementation, create a NSFetchedResultsController and configure it to fetch your Entities as needed. Then, override the (id)tableView:(UITableView*)tableView objectForRowAtIndexPath:(NSIndexPath*)indexPath method to return a TTTableItem built using the Entity you fetched from Core Data

Now, your TTTableViewDataSource is configured to read results from the DB you created and display them in your view. Remember that tableViewDidLoadModel can be called multiple times, so clean up any previously allocated NSFetchedResultsController if you need to.

Step 5:

Implement your logic to delete/update your Core Data entities. Depending on how your app uses data persistence, you want to ensure that you update/delete your entities from Core Data. For instance, if you always want to fetch data from the server and load them into Core Data on first run, then update Step 3 to first delete all entities. If you wish to show local data when available but fetch when not, then update Step 3 to not hit the server before checking locally. When deleting entities, remember that Core Data only lets you delete a single entity at a time (so you must fetch all and loop through each to delete it). If you want DROP TABLE ... semantics you're going to need to maintain different NSManagedObjectContent and NSPersistentStoreCoordinator for each such table, and then simply delete the database file.

So, this isn't too hard really. Assuming you're familiar enough with building your Three20 app, my notes above should help you get started with integrating Core Data into your app. My app uses a TTSectionedDataSource, and with a few tweaks to NSFetchedResultsController it's simple to do that too.

An Apple A Day Keeps the Bugs Away

2010-08-07T08:31:00.000-07:00

I've been working from home for the last year or so, and it has tremendously increased my productivity as a developer. Besides the obvious reasons (lack of distractions, no meetings, etc) there is one other advantage that I haven't often heard people mention before.

I have been able to find solutions to some really hard technical problems much quicker, and I attribute it to the fact that I work from home instead of in a more office-like environment.

Most software engineers will tell you that some of their best ideas have come to them when doing the most mundane of things - taking a shower, strolling across lawns, eating a snack and so on. I don't know the psychology behind this, but I know it's true for me. Something about being alone and thinking about your problem subconsciously, and yet being physically distracted with an unrelated task seems to work wonders. I have solved more tough problems while in the shower, when sitting down to eat an apple, when watering the plants or simply doing the dishes than I have sitting at a desk and just thinking. So obviously, being at home makes it much easier for me to find one of these mundane tasks that let me 'detach' and yet perform an activity that is beneficial to me both personally and professionally.

It's become a pretty important weapon in my software development arsenal - if I'm stuck on something for more than 30 minutes, I get out of my workspace and go do something mundane around the house or eat a quick snack. More often than not a solution magically appears in my head.

Back when I worked in an office, if I was stuck trying to solve a hard problem my best option was to find someone familiar enough with the problem space and bounce ideas off of them. This worked pretty well initially but didn't scale too well with problems that became narrower and deeper in scope - I often found myself spending a lot of time trying to catch others up to where it would be valuable to bounce ideas off them. And heading off into the office kitchen to reorganize stuff or watering random plants around the office would just make me look weird.

So, the next time you're having a hard time finding a solution to a problem in the office think about taking the next day off and working from home. Oh, and make sure the dishes aren't done. ;)

Slow onclick Javascript handling in Google Chrome 5.0.375.55

2010-06-02T00:50:00.000-07:00

Google's Chrome has been a pretty slick browser, and it's speed was the primary reason it became my default browser. The V8 Javascript engine supposedly blows other engines out of the water, and it did feel noticeably faster than others - until this latest version.

Sometime last week, my version of Chrome was auto updated to 5.0.375.55, and I noticed that the website I've been developing became terribly slow. Because of a previous Chrome bug, I hadn't migrated my site from jQuery 1.3 to 1.4, so one of the first things I did was verify the fix and then update my site to use the newer, faster jQuery. As I began testing, I noticed a significant reduction in performance of some features on my site.

Initially I suspected it had something to do with jQuery upgrade. After a few hours of changing things around, I was pretty convinced the problem wasn't jQuery 1.4. I noticed that Firefox and even IE 8 didn't exhibit this latency, so now I started to suspect the new version of Chrome. I hacked up a couple of test pages, and I think I found the culprit. It looks like the onclick handler's performance degrades with the size of the HTML page, resulting in a very noticeable (1-2 second) lag once you have a table with 3000/4000 rows. Firefox and IE 8 don't seem to have any trouble handling this.

I've logged Issues 45620 in the Chromium project with details and a repro to track this problem. This definitely isn't good news for me - with growing adoption of Chrome and general perception that Chrome is the fastest browser, problems like these make website look faulty even when they might not be.

As an aside, I have noticed that Chrome feels like it has regressions more often than other browsers (perhaps a function of shipping more often?) I've run into several issues developing for Chrome - the silver lining is that bug fixes are quicker than rival browsers, but better QA before release would certainly help developers.

Other Chromium issues that I've had trouble with and have had to work around are Issue 7771, Issue 30693, Issue 33411 and Issue 36559.

Update: An comment on Issue 45620 identifies one of the reasons for the slowdown and a workaround.

Showing the Cancel button in UIActionSheets on iPad

2010-05-19T01:26:00.000-07:00

In it's iPad Human Interface Guidelines Apple provides several guidelines about how user experience should differ between iPhones and iPads. One such element that should behave differently is the UIActionSheet.

Apple recommends that cancel buttons not be shown for action sheets on iPad:

Because taps outside the popover dismiss the action sheet without selecting an item, this results in a default way to cancel the sheet. Including a cancel button would therefore only cause confusion.

But the guidelines do allow exceptions to this rule:

However, if you have an existing popover and are displaying an action sheet on top of other content using an animation, a cancel button is still appropriate.

So you would think following this guideline is as simple as not specifying a cancel button in most cases, and only specifying a cancel button when you have carefully considered the exception case, right? Wrong. Even when you do specify a cancel button, it looks like the iPad runtime automatically always hides it.

So how do you provide a cancel button in the exception case? You could just provide another normal button that has cancel behavior, but that's not ideal because you really want the difference in appearance that UIActionSheets on iPhone provide by default. After some tinkering, the best solution I could find was to set the actionSheetStyle property of the UIActionSheet to UIActionSheetStyleBlackOpaque.

I can speculate why this works, but I don't know for certain so I'd rather not. If you know of a better/more correct way to do this, please do leave a comment.

I am surprised that Apple was mindful enough to list the exception case, and yet careless enough to not provide documentation on how to handle this case - they even seem to have forgotten to document that the iPad automatically overrides user-provided cancel buttons by default.

Notes from a Week in Paris

2010-05-08T18:21:00.000-07:00

I just got back from a lovely week in Paris with my wife - it was a rejuvenating and much required holiday for both of us. Work has been crazy, for her especially. Paris was wonderful and more than lived up to my expectations. We rented a tiny little studio in Le Marais (~120 sq ft, fully equipped including a washer - extremely efficient use of space!) Spending the entire week gave us enough time to explore sights, sounds and tastes of Paris without too much of a rush.

There are lots of books and blogs about visiting Paris and things to do/see. We used a bunch of resources - advice from friends, Lonely Planet's excellent iPhone app, the very insightful Secrets of Paris website with lots of tips on what to see and do and Paris By Train for everything related to using Paris' excellent rail network. However, there were some things I hadn't read about or was surprised by:

Cafés, brasseries and boulangeries/patisseries often have different prices for take away (emporter), eating inside (sallé) and terrace dining. Most cafés/brasseries offer set menus (Formulae) and chef's recommendations which change daily (menu and price). They are almost always much more cost effective than ordering a-la-carté.
The French are very proper. You greet business owners when you enter their store/café and thank/greet them before you leave. Sprawling across lush, green lawns in the several Parisian parks (Jardins) or putting your feet up on empty train seats is frowned upon. You sit in chairs provided in the Jardins and sit up straight in trains.
Freshly squeezed orange juice (jus d'orange pressé) is extremely popular. You'll find orange juice machines pretty much everywhere (including Starbucks), but it's best to find a green-grocer/fruit vendor and get a half-litre jar of fresh squeezed juice each morning. Fruit vendors are everywhere.
By default, coffee means espresso. A cappuccino/café-au-lait at most Cafés is expensive (between 4-8 EUR) and isn't that great (for a Seattlelite, at least). A mocha at Starbucks is EUR 4.50. Little créperies or street cafés have better deals for coffee that tastes identical (1-2 EUR). Or, hit up a McCafé. A 'mocha' is called a 'chocochino' and isn't commonly available.
Sit-down créperies are totally not worth the price/experience. Get a crépe from a street vendor/corner shop and sit in a park or a street bench. The more exotic crépes (savory & sweet) are only available in nicer establishments, obviously.
Wine/liquor is available in grocery stores (supermachés). Supermachés open around 8:30am and shut around 8:30pm. You are expected to bag your own groceries. For late-night grocery runs, there's usually a little-store-that-sells-most-things every few blocks which stays open late (2am)
Bars have later Happy Hours than in the US. Happy Hour generally runs from 6pm to 9-10pm. Folks eat dinner late (most restaurants stay open until 11pm).
Time is specified using 24 hour notation. "What time do you shut?" is answered with "23 hours". Most people don't understand am/pm.
Take binoculars to fully appreciate the amazing art/architecture details.
Use the 'Vélib' shared bike service. Vélib stations are everywhere, the roads and drivers are biker-friendly and it is the cheapest and most convenient way to get between locations in the city. Buy a map-book that has streets sorted by districts (arrondissements) and also has metro/Vélib stations marked.
It is not common for crémeries/gelaterias to offer tastes.
On the metro, or just walking around, you'll see a significant number of people going home (presumably) with one or more fresh baguettes from the bakery. For some reason almost all of these people are men. Join the crowd - fresh baguettes are the only way to go. Bread is baked fresh twice a day (if not continuously).
When you pay cash, check the change you get back. Parisians are either terrible at math or prone to short-changing customers. I routinely got back incorrect change, on average twice a day.
Before you go to a specific place (café, boulangerie, museum, grocery store, monument) on a Saturday/Sunday/Monday check before you head out. Almost every establishment is closed on at least one or more of these days.
Strange, English speaking 'beggar women' holding hand-written post cards will randomly approach you at monuments/museums and ask "Speak English?". I didn't quite figure out what the scam was (I never answered "Yes") but this is most certainly some sort of scam.
Comté tastes awesome, and is the most popular cheese. Camembert is a close second. Get cheese fresh from your neighborhood fromagerie.
If you decide to cook at home, chances are good that you'll find an Italian store nearby selling freshly prepared pastas and raviolis that you can cook at home, in addition to a large number of other Italian foods (including freshly prepared Tiramisu).

Why I use Google Voice for SMS

2010-04-19T06:40:00.000-07:00

I have an iPhone with AT&T service, but I recently started using Google Voice for most of my SMS needs. SMSes sent to my Google Voice number are forwarded to my email. It works great for me:

I don't want to pay AT&T any more than I have to. I use AT&T out of necessity, not choice.
GMail has support for Exchange ActiveSync, and is the default Exchange account on my iPhone. So I get notified of the SMS in email on the phone as soon as it is received (assuming I have data coverage, which is pretty much all of the time) giving me the equivalent of the native SMS experience.
The Google Voice extension for Chrome. Chrome is my default browser, I'm in front of a computer for a large part of the day, and my browser is usually open. I can read, send and reply to SMSes using a full keyboard and without exiting the browser, instead of pulling out my iPhone and fiddling with the tiny keyboard to type out a message. So much more convenient!
All my SMSes are archived and made searchable not only by Google Voice, but also by GMail. Win.

Living Every Developer's Wet Dream

2010-04-18T11:07:00.000-07:00

Back in June I wrote about new technologies I had started working with and my experiences learning those technologies. Having continued working with most of those since then, I've become incredibly comfortable and proficient with them. It's pretty normal to have a week where I write a bunch of PHP, a few SQL queries, some fancy Javascript, learn new CSS tricks, hack up features in client software using Win32/Cocoa, debug some corner-case issue using logs and a mini-dump and also write some straight up C/C++ server side code with unit tests. Initially, jumping languages and client/server boundaries came with large context-switch penalties but it's become almost second nature now, which feels very empowering and has had a dramatic impact on productivity.

Then, there are the one-offs - new technologies that need to be learnt, integrated into the product/service (in a way that's easy to understand/change in the future) and then 'forgotten' before moving on to the next one. These tend to be client-side technologies usually - server side stuff is much more on-going and stable. Some of the 'bigger' things I've done in the last 6-9 months that would fall into this one-off category are:

Fiddling around with HTML5 <audio> and <video> before giving up
For all the promise of new HTML5 multimedia standards, the sad reality is that we are far from any consensus. Different stakeholders have different motivations, which leaves the issue of a single standard codec up in the air. The proprietary nature of Flash, licensing issues surrounding H.264, Apple's opposition to including Ogg Theora in Quicktime and Microsoft's silence have resulted in the current stalemate. And this shows when you experiment with the different browsers. Development for web/mobile-web is poised to become radically easier once/if this is sorted out, but there is a lot of pain to be endured before then - pain that wasn't worth it to me presently.
Flash audio support
Having decided to not want to build a flash media plugin myself, I first played around with this MP3 Player and later switched to the much more powerful SoundManager2. With a few tweaks, I was able to make it do exactly what I wanted.
Facebook Connect
For single sign-on and any sort of social media integration, Facebook Connect is a must have. Having implemented Facebook Connect for my website and for iPhone, I must say that I am very pleased with the facilities offered by the platform and the consistency across client/server applications. XFBML and FQL are nice touches. My only gripe is that, for a mature and widely adopted platform, documentation seems disproportionately poor as compared to the richness of the Platform APIs.
Online Payments
There's a lot you learn about how safe online transactions really are (they're not) when you dive into how payments really work. I developed a quick payment portal using Payflow Pro by PayPal. Can't really vouch for Payflow Pro yet, though. A few weeks after I finished working with Payflow Pro, PayPal X was announced. I'll eventually get around to migrating to it, I guess.
Identicons
Simple, cute, pretty. I use the ones provided by Gravatar.
Javascript Craziness
One of the crazier things I've done, among others, with Javascript is to try and emulate a desktop-software like user experience in a website. Dragging, dropping, keyboard navigation, sorting, multi-select with Ctrl/Shift/Meta... oh boy! It look a while, but with some help from jQuery UI (the different components work great individually, but try to also make a sortable a draggable and a selectable, and you're in a world of hurt) and a lot of long nights, I finally got a lot of this done. For Forefox. Then I spent some time making it work for Chrome. And then a whole bunch of more time making it work for IE8. It sorta works in IE7, and not at all in IE6, but honestly if you're still using those browsers you should be chastised. Someday, I want to wrap all this into my own little plugin that others can use. If you told me a year ago that I would be some kind of JS nut, I would have laughed. Ha!
iPhone web-app (before I ditched it for a full blown iPhone app)
Not wanting to deal with Apple and their strange AppStore practices, I decided to try and be really creative with native Quicktime support built into Safari on the iPhone. I almost got all the way to hacking up really neat functionality, complete with callback from Quicktime into my website, background playback and an rich interactive experience. With Flash coming soon to other mobile platforms, this would have been ideal for providing mobile experiences without needing multiple platform-specific applications. However, the iPhone web app felt clumsy and not polished, so I ditched it and went the iPhone app route. I reserve comment on my experiences with development for the iPhone - my app hasn't been submitted/approved yet. ;)
I also foresee myself playing with other mobile development platforms in the very near future. I think a blog post comparing my experiences with the different platforms might make for good reading.

In addition to these one-offs, there are the perpetual how-will-it-scale and how-will-it-perform issues that need to be considered for every little feature. One of the harder lessons for me was to change my default mindset about how I approached design. While I wouldn't say I optimized prematurely, my design was heavily influenced by potential for optimization. (segue: This, I now realize, is a result of my years at Microsoft. At companies like Microsoft, you do things once and you do them right - rapid iteration is often not possible or not practical. So, while this approach has its merits it's not ideal for agility in startup environments). The new approach that's imbued into me now is to build it quick and make it simple first. Simplicity is the bedrock of agility. Simpler code is easier to revisit and to scale. Complexity is technical debt that you don't really need or want.

What's the biggest thing I've learnt in the last year? I learnt how to learn efficiently.

You can spend hours studying/learning about something and barely scratch the surface. Or you can study to retain information for very short periods of time. Exceptional developers are able to identify when they need to deep-dive vs when they need to simply skim the surface. They can instinctively answer the "How do you learn enough to make well informed decisions and yet don't spend a disproportionate amount of time learning without producing?" question. Transient learning is only good when you never need to revisit a decision - such cases are rare. Otherwise, learning to execute quickly and leaving a trail behind you is a crucial skill. I believe I'm well on my way down this path.

So yes, in many ways I am living a developer's wet-dream. And fortunately, I am able to do a little more than just development stuff. But I know this probably won't last forever. This series of blog posts is my attempt to capture my memories for when I'm not doing this everyday anymore.

SecureCRT and Windows 7 - The Case of the Magically Disappearing Window

2010-03-05T09:06:00.000-08:00

Ever since I upgraded my copy of SecureCRT to 6.5.1 on Windows 7 x64, I started noticing really strange behavior. Occasionally, my SecureCRT window would just 'disappear'. What do I mean by 'disappear'? The SecureCRT icon on the Windows 7 taskbar, which appears like this when a window is open:

would suddenly change to this, which is what an icon looks like when the process has no windows open:

I could still see SecureCRT.exe running, but didn't find any windows for it, even in the Alt+Tab menu. Nothing appeared in my system tray either except for the network connection, volume and system time information.

Once this happened even after a system restart (isn't that the usual fix for everything?! ;)) I got curious. Eventually, I realized that this happened each time I minimized the window. Somehow, minimizing the window is muscle memory for me now and I don't really notice I'm doing it until I consciously try.

Minimizing a windows shouldn't ever cause the window to just 'disappear' so I started looking at the different SecureCRT settings and noticed a curious "Minimize to Activator" setting that was checked, and seemed suspicious. Unchecking it was all it took to restore sanity.

What is this 'Activator'? It's an icon that sits in your system tray. But Windows 7, by default, hides away all my system tray icons so I had no idea this even existed until I started investigation this issue. This is the 'Activator':

SecureCRT removes the window and sticks it into this Activator. Without any sort of visual cue or notification bubble. By default. Ugh! To restore it, you need right click the icon and select the "Restore" option. Umm... isn't that the whole point of Windows' built-in minimize implementation?

This seems like a poorly designed feature, especially given how Windows 7 treats tray icons (and I know SecureCRT v6.5.1 has some Windows 7 specific features so this isn't accidental). Making the process 'appear' like it's not running and sticking into into the 'Activator' (why isn't it called 'system tray icon'?) instead seems like bad design. If anything, this should definitely not be on by default.

Ed: Title inspired by Mark Russinovich's blog posts

Update: Just got an email response back from SecureCRT's support staff to a query about I this I had sent last night. She clarified "... the global option is **not** enabled by default. The session option by default is a "tri-state" option, meaning it uses the setting found in the global option."

Discouraging Tardiness in Social Circles

2010-03-03T17:55:00.001-08:00

What's the best way, if any, to incentivize punctuality in a social setting i.e. among friends and family? Alternately, is there any way to dis-incentivize/discourage impunctuality?

In professional environments this isn't usually a problem. There is generally one party which has some form of authority (the boss running a meeting, the doctor who is so booked up that you got an appointment only after months, the VP who can only meet for 20 minutes before he has to run to another meeting, the senior engineer whose time really is more precious than yours) who sets an example that is expected to be followed, and can dangle a carrot or wield a stick to manage tardiness. There is also a personal incentive to be on time - you want to make a good first impression, not appear to be the one holding the team behind, or not miss out on something important if you're late.

The social dynamics that exist among friends and family are vastly different though. Often times, no one person holds a position of authority over another, the 'meetings' aren't usually that important and outcasting the offenders as a group isn't really an option either. Hence the repercussions of tardiness are pretty mild, if any. In many ways, the punctual folk have more to lose.

The ideal solution wouldn't make any individual or sub-group appear to be 'jerks' and yet make each member of the group want to be punctual. Poking fun at the offenders or just generally being prudish isn't going to help, I think.

So, any ideas? I'm drawing blanks...

Coupon etiquette?

2010-02-19T09:26:00.000-08:00

What's the 'correct' social etiquette about using restaurant coupons purchased online (such as those from restaurant.com or groupon.com) when you go out in a group and split the check?

For coupons you get in the mail, or basically free stuff, I assume common etiquette is to offer the coupon to the group to use and split the remainder. Does it work the same way when you've bought, say, a $50 coupon for $25 (i.e. you use the coupon to cover $25 off your tab and offer the discount value to the group)? Do you use the entire $50 to cover just your tab? Or maybe simply not using the coupon when dining as a group is the right way to go?

Hey Google Buzz, I don't email my friends anymore

2010-02-09T10:27:00.000-08:00

I just saw the presentation from Google about Google Buzz. The quick summary of the announcements - creating a social network using my email contacts and emailing history as the source of my social graph, and using rich geo-tagged status messages (buzz-es) to keep it updated. It comes with rich mobile apps to help this take off. They also promised enterprise versions of Buzz.

Buzz sounds pretty exciting. Some of the geo-tagged updates sounds really slick. My first reaction - this is going to be 'public follow' thing more than a 'follow my friends' things. Because emailing my friends is like, so 2007!

Fact is, I don't email my closest friends/family anymore. I either IM them, post on their Facebook page, send them SMS or call them. Email is more for work type, non-personal stuff. Having said that, it's important to note that Google does have GTalk and Google Voice so I hope they weigh activity from GTalk and Google Voice higher than GMail activity when figuring out who I must 'auto-follow'.

Time for someone to write a Buzz-to-Facebook cross poster. :)

Test cases for basic Facebook Connect integration

2010-01-25T15:26:00.000-08:00

I recently spent a couple of days adding some basic Facebook Connect functionality to an existing site with it's own Login/Auth system. The process isn't too hard and there are several examples and even a nice tutorial which shows you exactly how to hook this up.

The tutorials and the Facebook developer wiki to a good job of getting you on the right path and putting up a quick working implementation. However, there are several subtleties that need to be addressed, depending on the requirements of the existing site. I didn't really find a good compilation of these 'test cases' anywhere. Facebook's own documentation probably references several of these but they're scattered all over their wiki page and are very easy to miss if your primary focus is getting this stuff up and running quickly.

This blog post is my attempt to compile of list of things you need to think about when adding Facebook Connect support for sign up/login or linked accounts on an existing site with its own authorization system. Here are a few characteristics (pretty standard) of the existing site:

Authentication using a username/email address and password
Cookies to help keep users logged in
Accounts keyed by email address (i.e. 1:1 mapping between accounts and email address)
Ability to reset accounts by having a temp password send to user's email address
Fully ajax navigation (which complicates matter a little bit)
Logout functionality which clears up cookies

The goals for the Facebook Connect integration are pretty simple:

New User Sign Up without needing to create a site-specific password (email address needed)
Ability for existing users to link with their Facebook account
1:1 mapping between accounts on your site and Facebook accounts
Single sign-on experience

Let's call the existing site YouFace. I won't go into how to get stuff hooked up or explaining how to implement this - it's not too complicated and there's a bunch of information online for it. Instead, treat this as a list of a few things you probably want to test when you're done. There shouldn't really be anything ground breaking here - this was just a convenient way for me to build a list of things to test on my own site. Some of these are handled by the Facebook Connect client library, while some need your application to do the right thing. Please comment if I've missed any cases or if some just appear wrong - I would love to fix my site!

Since we need access to an email address, Sign Up should fail if the user provides publish permission but denies email permission (category: sign up)

If the user provides an email address that already exists in your system, fail Sign Up. Make sure no YouFace backend tables are modified (category: sign up, 1:1 mapping) PS - when this happens, I didn't find a way for you to de-authorize YouFace on the Facebook user's behalf. The user must manually do this if they wish you use the same account but provide a different email address.

Accounts created using Facebook Connect should not be able to login using YouFace's default email/password login system (category: sign in, account security). PS: Since YouFace accounts require a password and those created using Facebook Connect don't, make sure to insert a random password hash into your table to avoid silly errors

Accounts created using YouFace should be able to sign in without requiring to be signed into Facebook, even if when a link to a Facebook accounts exists (category: sign in)

Attempting to Sign Up with a Facebook account that's already linked and authorized should result in the Sign In experience (category: sign up, sign in)

Attempting to Sign In with a Facebook account that YouFace hasn't seen before should lead to the Sign Up experience, i.e. create a new account (category: sign up, sign in)

Linking a Facebook account with an existing YouFace account should add the email address from Facebook to the list of 'used addresses' in the YouFace system (category: linking, 1:1 mapping)

When a Facebook linked account de-authorizes YouFace, your system should record this action and change state as needed (category: authorization)

Linking a YouFace account with a Facebook account that's already been linked to some other account in your system should be denied (category: linking, 1:1 mapping, authorization)

Users with linked accounts can continue to sign in using their YouFace credentials even after they de-authorize YouFace from their Facebook account (category: linking, authorization)

Linking a Facebook account different from one you originally linked to an existing YouFace account should be denied. This can happen when an existing user links a YouFace account to Foo@FB, de-authorizes the app and then tries to link Bar@FB to that account (category: linking, 1:1 mapping, authorization)

A user who Signed Up using Facebook Connect should not be allowed to link their account to another Facebook account (category: sign up, 1:1 mapping)

Attempting to Sign In or Sign Up with a Facebook account that YouFace has seen, but one that has currently not authorized the YouFace app (maybe the user revoked authorization) should ask to re-authorize before proceeding. It must log the user into the original YouFace account linked with that Facebook account, i.e. no new account should be created. If that account was originally created using Facebook Connect, the primary email address should be updated to reflect the user's current Facebook contact email address else the primary email address should not be changed from what the user provided YouFace when they signed up (category: sign in, 1:1 mapping, reauthorization)

If a user with a linked account is logged into Facebook, they should be signed into YouFace directly (category: single sign in)

Users who signed into YouFace with Facebook Connect should be logged out of Facebook if they log out of YouFace (category: single sign out)

Users who signed into YouFace with Facebook Connect should be logged out of YouFace if they log out of Facebook (category: single sign out)

Users with linked accounts who signed into YouFace directly (not using Facebook Connect) should continue to remain signed in, regardless of whether they're were originally signed into Facebook, when they sign out of Facebook (category: sign in, sign out)

Users who created their account using Facebook Connect should not be allowed to reset passwords or have temporary passwords sent to their email addresses (category: account security)

This is a kinda convoluted. Users Foo and Bar both have YouFace accounts linked to Facebook. Bar is logged into YouFace with his YouFace account, and Foo is logged into Facebook, in the same instance of the browser (Bar logged in first). When Bar logs out of YouFace, Foo should not get logged out of Facebook (category: single sign out, multiple accounts ). PS: YouFace's Connect library is going to pick up a valid Facebook ID but it's that of Foo, not Bar. So you need to do more than just client-side detection of whether someone's logged into Facebook.

Browser history navigation bug in Chrome and Safari

2009-12-23T12:41:00.000-08:00

I've been seeing some odd behavior in Chrome - occasionally browser history would get hosed pretty badly. When I noticed the same issue navigating the website I'm working on, I ended up spending a bunch of time trying to get to the bottom of the issue. Initially I suspected it was something wrong with the site, but I was eventually able to create a stand-alone repro for Chrome (v3 and v4) as well as for Safari (v4). I suspect this might be a WebKit thing, which both browsers share, but I don't know enough to be certain.

The problem seems to occur when you spend time moving around fully ajax sites that contain one or more iframes (I've seen this on GMail as well). In my case I worked around this issue by not using iframes but I imagine that's not always possible. Anyways, this is now Chromium bug 30693.

XSRF/CSRF Vulnerability Explained in Non-Geek Speak

2009-10-09T11:08:00.000-07:00

I recently explained what cross-site request forgery (CSRF/XSRF) is to a friend who isn't a programmer/CS person and I was pretty amazed at how quickly he understood the implications of not protecting against such attacks. With the proliferation of social interactions on the web now, such attacks can be pretty damaging to consumers of new media and e-commerce sites.

The Wikipedia article about CSRF does a pretty good job of explaining the issue - most people familiar with web development should be able to understand it easily. Basically, this attack lets legitimate unsuspecting users submit changes to a site they routinely interact with, but without their knowledge. CSRF attacks leverage your own browser and the trust you associate with it to perform potentially damaging actions on your behalf.

Here's an example of what such an attack might look like. Let's assume that Facebook wasn't protected against such attacks, for the purpose of this illustration. In reality, I'm sure Facebook engineers have done a good job of making sure this can't really ever happen. That's not true of every site out there, though.

When you sign into Facebook, you have the option of remaining signed in. To do this, sites like Facebook set a browser cookie which identifies you to their servers. This is great because it lets you visit the site frequently and navigate the site without needing to enter your password every time. Browsers are good about securing your cookie - they make sure that no other site besides Facebook can see this cookie, so it's not possible for the author of www.hacker.com to steal your cookie and present it to Facebook and then impersonate you. However, each time you go to any URL that contains www.facebook.com, the browser diligently sends over all cookies associated with Facebook, because the receiver of those cookies is www.facebook.com.

Once on Facebook, you do things like update your status or write on a friend's wall. When you do that, the browser sends your new status update to Facebook along with the cookies. By inspecting the cookie, Facebook is able to validate that it is indeed you trying to update your own status, so it proceeds to allow the action. Under the covers, your browser is sending over two pieces of information - some data (your status update text, in this case) and the cookies. The browser was triggered to do this by you clicking the "Submit" button. This sounds pretty straightforward so far.

Now imagine you're browsing the web and land on this page that talks about world hunger and how you can help the cause by simply clicking a "Help the Children" button. With only altruistic intentions, you click on the button. Nothing visible happens, or maybe a "Thank you!" label replaces that button. Then you simply move on to the next thing you were going to do. Suddenly, you start receiving email notifications about friends responding to your latest status update on Facebook, except you never posted any update. You visit Facebook and sure enough your status now says "I am a loser!", updated 2 minutes ago. Huh?! You didn't set that status. You panic - maybe someone hacked your account? Or someone guessed your password? What's going on?

What really happened was that the world hunger website you were on was written by a malicious attacker, and when you clicked the "Help the Children" button that website didn't really contribute 10 cents to UNICEF, but instead told your browser to send a new status update with the text "I am a loser!" to www.facebook.com. This site couldn't access your cookies directly, so the browser didn't do anything bad and stuck to its promise of not letting anyone else see cookies that shouldn't be visible to them. Remember, the attacker never looked at your cookie at all while any of this happened. However, when the attacker asked the browser to send data to www.facebook.com, the browser added the Facebook cookies to the request. So now Facebook looks at the cookies and the data, thinks that it is indeed you and goes on to update your status. Boom!

So what went wrong here? The browser didn't do anything bad - it did exactly what it's supposed to. It hid your Facebook cookies from everyone except Facebook and it sent data that submitting the "Help the Children" button asked it to send. You didn't do anything bad - you simply clicked on a link that was meant to help needy kids. You did have cookies enabled (default for most browsers) and decided to check that "Log in automatically" option, but those seem like reasonable actions.

The flaw here is with the website you trusted - Facebook, in this example. Sites like Facebook that rely on cookies to identify and authorize user actions need to do more things than just validate your cookie when data is presented to the site on your behalf. They need to make sure that place from which the data was sent was 'good', or that a malicious author cannot create data the same way that www.facebook.com can. They need to make sure that when you update your status, the data contain more than just your new status text - there must be some kind of secret information in there that can only be generated by Facebook, and this secret must be different for each Facebook user. They can even control how long cookies and secrets remain valid, and have ways to periodically require users to sign in and generate new unique secrets for users.

Of course, this is just a silly example. I'm sure Facebook is perfectly adept and handling such attacks. However, a vulnerability like this could impact everything from online review sites to banking and e-commerce sites. It's always good to be aware of things that could go wrong online - the Internet is definitely not as safe as you might think it is.

So, how was your date?

2009-09-30T17:59:00.000-07:00

A funny exchange at work today...

I designed this piece of UI putting together all my newly-acquired Javascript and Paint.NET (a free Photoshop-like tool) skills, and it looked pretty fancy for what I thought I was going to end up with. After playing with it for a bit my co-worker responded: "Thanks for putting that together Viraj - I really like the concept. I can't wait to see what a designer can do with it".

Lol... this sounds a lot like the "She's got a great personality..." line of the dating scene.

Like I said previously, UI design is so much harder than I thought it was!

Fix for slow Firefox/Chrome connects to localhost

2009-09-18T11:43:00.000-07:00

While doing some recent testing I noticed that Chrome(v3) and Firefox(v3.5) are both very slow to connect to http://localhost on Windows 7 - both take ~1 second just to connect.

I initially suspected something was wrong with the webserver on localhost, but once I validated that wasn't it, I found some blog posts about others who had noticed this in Vista and XP. Essentially, disabling ipv6 takes care of the slowness.

However, to fix the issue, have the client use http://127.0.0.1 instead of http://localhost - it bypasses ipv6 without you needing to mess with browser configuration.

Know What you Inherit

2009-08-29T11:55:00.000-07:00

I ran into a couple of bugs recently that took longer than they should have to fix. Like all bugs, it seems obvious now that I know what was wrong but I think I spent a total of 5-6 hours investigating and fixing this across multiple platforms (hey, this is what makes developing software fun!). Here's hoping that those fancy search engines will help someone else find this post and save them time incase they have a similar problem.

I was working on some code that launched another process. This is a fairly mundane task. Interestingly though, the process launched went on to kill its parent and re-launch another copy of the parent. So, process A is running and launches process B, which then kills A and launches A'. Sounds kinda simple, right?

Well, everything seemed to work until I noticed that some resources needed by A' weren't available (ports/files). That seemed odd, given that A had been using those same resources successfully, and those should now be available since A was gone. The title of the post gives it away, but the problem is that a fork causes child processes to inherit the file descriptors/handles of the parent, so the files/ports opened by A were inherited by B and subsequently by A'. This meant that they weren't really cleaned up by the OS when A exited. Hence A' could not re-open those resources (some were locked for exclusive use).

The really interesting aspect of this bug was how it manifest itself on different OSes and the different fixes.

On Windows, TCPView showed the ports in use by a "<non-existent>" process. The PID of this process was that of A, which was already gone by now and didn't show up in the list of running processes.

After some analytical debugging, I guessed that the handles were being inherited by the children resulting in these strange 'orphaned' ports. The solution on Windows was to use the CreateProcess API with the 'bInheritHandles' flag to FALSE. Problem solved. By the way, the not existent process IDs attached to those ports seem to imply that the OS tracks ownership by processID, and hence cannot validate that the new owner of these is the child process now that the parent is dead - the child obviously has a different process ID. This might not be really how it's done, but seems logical.

The Mac was much more interesting. The manifestation of the problem was simply unavailability of the resources. There isn't an equivalent of the bInheritHandles flag for the fork command on UNIX. To cut to the chase, the solution was to fork the process, close all open file descriptors that it inherits and then call exec.

Now, the Mac guys have added a nifty 'open' command to the system which helps launch processes as a child of the launchd process, which doesn't inherit the callers file descriptors (it's parent is the launchd process). However, this open command has a couple of pretty severe limitations. It can only open app bundles, not native binaries. And you can't pass in command line arguments to the application you open. FAIL on both counts! Mac purists will claim that command line arguments aren't the 'right thing' on the Mac, and that Apple Events should be used instead. That's BS, really. For anyone writing platform independent C++ code, it's just not practical. People don't realize that not every app on the Mac is a Cocoa/Carbon app. Anyways, so on OS X I needed to be a little creative and have A launch B, but before doing anything useful in B enumerate all open file descriptors and close them (readdir() /dev/fd on FreeBSD and Darwin enumerates all open file descriptors). Oh and by the way, you might not want to close FDs 0, 1 and 2 - they're stdin, stdout and stderr respectively. This post on StackOverflow has some good related information incase you're curious.

To Every Web/UI Developer I've Scoffed At - Apologies!

2009-08-07T06:01:00.000-07:00

I am/was a cocky programmer. Having only worked on system and application level programming thus far, I really didn't appreciate how hard building a good, usable website or application is. I knew that an application or a system is only as good as how usable it is, but I really considered usability to be a 'simple' problem and by inference I assumed that writing the code behind what you see on a website or an application is also 'simple'. As my career matured I suspected I might be wrong, and now I know I was!

Over the last few weeks, I've been messing quite a bit with Html and CSS to make stuff look non-ugly and Javascript/Ajax to make stuff feel non-sluggish. And the combination of these together to make non-ugly things appear non-sluggish. Of course, this also means dealing with everything that goes on in the middle/backend to support non-sluggish, non-ugly things. Oh, and once you have something that's not ugly and not sluggish, you have to worry about the bad guys. Cross-site Scripting, Cross-site Request Forgery, cookie theft and poisoning, etc are things I didn't think much about previously. What cans of worm those are... !

And then a couple of months ago I spent some time making an mac application non-ugly and non-sluggish. Same deal, pretty much.

Working on these new technologies sure feels like being a kid in a candy store, but I have to confess my new found respect for good UI/Web developers (and I am not one, by a long shot). I may have snickered behind your backs previously, but it sure won't happen again!

What's your time worth?

2009-08-06T21:32:00.000-07:00

One of the hardest questions I often find myself needing to answer is what my time is worth. Simple everyday decisions are influenced by what the answer to this question is - Should I get groceries from the store myself, or order online? Should I clean my own apartment or hire a professional? Should I contest the parking ticket by mail, in person or simply pay it? Should I go out an enjoy the weather instead of working overtime?

Of course, the right answer in most cases depends on more than just how you value your time. Tangible (I might pick better produce in person than online, or a professional could do a better job cleaning my apartment than I can) and non-tangible (I get to experience the judicial process at the municipal court myself if I contest a ticket in person) factors can sometimes influence these decision more than the absolute value of your time, and generally it's a combination of these factors + the value of your time which leads to the right answer.

What factors influence how you derive the value of your time? Here's a quick list of things I could think of:

Your age relative to life expectancy. Generally, the older you get the more valuable your time is. Time does run out eventually, afterall.
Real dollar value of gains from alternate activities you could be engaged in versus the intended activity. If you're paid by the minute on your job, the dollar value of every minute your spend in the break room outside of the allowed times better be worth more than your per-minute salary.
The intangible value of alternate activities you could be engaged in versus the intended activity. Heh - good luck figuring this out!
The tangible and intangible deferred value/costs of making a decision. Not feeding the parking meter in favor of enjoying your cup of coffee by the lake will cost you $25 next week.
Risk associated with the decision you make. You're quite likely to hurt yourself sawing wood, and depending on how badly you're injured you could easily outspend in medical bills what you would have paid a professional instead. Again, look luck quantifying risk.

What else do you consider when deciding one way or another?

New Technology (for me) Roundup

2009-06-30T16:20:00.000-07:00

Over the last almost 2 months, I've messed with several new technologies - some extensively, some briefly - that I hadn't used previously. This post is primarily a journal entry documenting my impressions of and experience with these, so far:

PHP - Exposure : Medium
I think I really like PHP. It seems like it's a good blend of a traditional programming language and a scripting language. I like that it allows for well designed software with OO constructs being first class citizens. I also like the flexibility that the scripting language aspect of PHP provides. I wish there were some kind of PHP compiler which helped catch silly typo-like issues before runtime, but I guess that's the price you pay for having the conveniences of PHP. I also think I would like having a good PHP debugger - currently I use code review and tracing as debugging aids. They've worked so far but I hope I never have to chase down something really nasty or subtle using these techniques.

Objective-C/Carbon/Cocoa - Exposure: Medium High
I previously wrote about my experience with programming for the Mac. For someone familiar with C and working with a runtime framework, this shouldn't be hard to grasp. I think I'm pretty comfortable with these technologies, but in many ways these are forced down your throat if you want to write software that runs on a Mac, and looks half decent. I dove deep into a few things related to these technologies (debugging crashes, file system events, application run loops, network support, deployment) and it was kinda fun and fulfilling to accomplish complex tasks with these technologies.

Bash Scripting - Exposure: Medium Low
To be productive in a Linux development environment, mastery of scripting is key. I know just enough to get me by, and I'm sure there's so much more I could do to improve. The rule of three seems to work well... if you do the same task three times, script it. And most times, you'll discover it's already been scripted by someone else or simpler still, exists as a built in set of commands. This seems like one of those endless holes of expertise that never ends. My goal is to deal with this as needed instead of being overly enthusiastic about becoming a crazy script monkey.

Javascript - Exposure: Low
I'm actually not too bummed about not having had to mess with more Javascript. I know people who just do the craziest things with Javascript and AJAX, but I'm not creative enough (or perhaps not motivated enough) to do anything more than the minimal. Unfortunately, a minimal website only works if you're Google or Craigslist. I haven't messed with Javascript for more than just a few hours, so I don't really have any strong opinions except that for someone who isn't familiar with scripting it takes some getting used to. Something like Script# might be an ideal transitionary tool though (I haven't played with it at all).

MySQL - Exposure: Medium Low
MySQL seems really slick. It feels great for simple database functionality (haven't really done anything too fancy with it) and supports some SQL syntax that comes in handy versus Microsoft SQL Server (insert ... on duplicate key update, create table if not exists, etc). PHP support for MySQL seems like a great integration win for both technologies. I haven't really dealt too much with administration and performance issues though, two areas which are super important to a great database solution, so I can't comment on those.

Python - Exposure: Low
I wrote a couple of python scripts to get some pretty powerful tasks done. I like that it has a bunch of libraries that enable you to write pretty fancy applications if you're so inclined (I'm not, and likely never will be). Like most scripting languages I'm amazed at how much can be accomplished in a few lines of code. Generally though, I don't like too much magic being done for me when I don't really understand what's happening and my experience with Python certainly made it seem very magical. Which is great for getting small tasks done, I guess.

Vim - Exposure: Medium High
This is a big once - even after almost two months of using this daily, I'm not nearly as comfortable with it as I was with the Visual Studio IDE, which makes me feel like I'm not being as productive as I can be. I think I learn one or two new tricks every day that make me wonder if there's anything Vim can't do. It's another one of those 'rabbit hole' technologies where experts can tune it to crazy levels. My approach is more along the lines of 'fix it when it annoys you' which seems to be working (slower than I would like, I admit). It certainly has the potentially to make me super productive once I get better with it, and that's making me stick with it.

Others - Exposure: Low to High
Technologies that aren't really 'new' for me but I was out of touch with for the last few years and have reconneced with recently:
- C
- Linux
- Win32
- Batch file scripting
- Makefiles
- gdb

So yea, as you might be able to tell, the last couple months have been insanely fun. I feel like an intern again (in more than one way ;-) )!

f.lux - I Like!

2009-05-22T21:02:00.000-07:00

Staring at multiple computer monitors late into the night isn't as pleasant as it should be. I've noticed that the constant bright glare from the monitors causes a lot of fatigue. f.lux is a very simple and yet highly effective tool that has made coding so much more pleasant. I very highly recommend this to anyone who spends long hours working at a computer. Available for Mac, PC and Linux. (PS: MacBooks already have similar functionality built-in that uses the integrated camera to detect ambient light and adjust brightness accordingly).

Cocoa: What is "File's Owner" in a nib?

2009-05-17T18:15:00.000-07:00

One of the things I had most trouble with while writing my first Cocoa application was understanding what a File's Owner in a nib file was and what role it fulfilled.

Apple's documentation seems to imply that understanding File's Owner is important (it is) but doesn't really do a good job of explaining the concept. And I'm not alone - this email thread contains a pretty good summary of what Apple's documentation says and the confusion it might create. That same thread has several peoples' attempts to explain what it is. I really didn't get too much from those explanations and ended up explaining it to myself by piecing together data from a few experiments. Now that I think I understand what it's for, I figured I should try and put my take out there as well in case it ends up helping someone else in the future.

The File's Owner of your primary nib file is, by default, the NSApplication class and this comes ready-made for you when you create your Cocoa application. If your application has just the one nib file, you really don't need to worry about File's Owner. But if that's true, your application is probably really trivial or not well written.

Generally, each new window/sheet your application creates should be contained in it's own nib for faster loading of your app and smaller runtime footprint. When adding a nib to your application in XCode, you'll noticed that the File's Owner is set to NSObject by default (select the File's Owner object in the nib and launch Tools -> Identity Inspector). I recommend setting this to a derived type for two reasons:

So that you're forced to think about who the File's Owner of the nib is.
So that you don't make a silly error while defining the owner of the nib - everything is an NSObject, after all.

A nib file is loaded dynamically at runtime usually in response to some user action (clicking a button, selecting a menu option, etc). Loading the nib is done, usually, using the NSDocumentController or the NSWindowController classes. Just because these classes help load the nib doesn't mean they must 'own' the nib. The File's Owner of the nib is the object that makes communication possible between this new nib and other parts of the application. Let's explore this further.

The document/window loaded in the nib can have one of the following purposes:

an informative view that isn't interactive (About box, for example)
get some more user input to feed into other parts of the application

#1 is the simple case - by my definition, since there is no communication to be enabled, the File's Owner for this nib is not important. But based on my previous recommendation of not using NSObject as the File's Owner, what class should be set as the File's Owner? The object (NSDocumentController/NSWindowController) which loaded the nib can be made owner of the nib, and the nib loaded using the method overload that doesn't need an owner specified.

#2 is the interesting case - if this is a form that takes in some user input it is required that this information be communicated back to another part of the application. But no one on the outside really has access to controls in this form. No one, except the File's Owner. In this case, the File's Owner should be an instance of a class that you've previously created, and the type of that instance is what you set to be the File's Owner's class in the Identity Inspector. It's important here to understand that the File's Owner isn't a 'new instance' of the class you specified. In fact, the File's Owner is set to an instance provided when the nib was loaded (see the last parameter of initWithWindowsNibName).

So your application likely had an instance of an object created previously, which is what you would pass in as the owner of the file. That instance can now expose IBOutlets linked to fields of the form, which can then be used by other parts of your application that already have a reference to this instance. This is what Apple documentation means when it refers to the File's Owner as a proxy.

Hopefully, this will help someone else who's learning to work with Cocoa and needs to get some clarity around the File's Owner.

Developing for the Mac - How does it compare?

2009-05-15T19:46:00.001-07:00

I spent most of this week developing some Mac OS X software. Having never before written a single line of Objective-C or any Mac software, I was pretty excited. Here are a few observations of developing for the Mac compared to the Windows platform (primarily .NET) from a week's worth of writing an application using Cocoa. Of course this isn't exhaustive and only includes things I had to deal with (disclaimer - opinions subject to change as time passes):

Overall, developer reference documentation on Apple's Developer site seems more current and easy to understand than that on MSDN. A nice touch is the reference to examples which use a particular method inline with the documentation of the method <example> (MSDN does it using inline code, so it's not too different). My favorite feature about documentation though is the logical grouping of methods and properties arranged by tasks - that makes it very easy to get stuff done. I think this is the result of being the underdog in this space.

Mac OS X applications' uniform usability and consistent aesthetic isn't a fluke. Apple's documentation regarding recommended usage is precise down to individual visual controls and yet comprehensive as far as Human Interface Guidelines go.

XCode doesn't have anything on Visual Studio. Visual Studio seems, hands down, a better integrated development environment and debugging application. VS 2008 is really pretty awesome.

Cocoa is nice, but still has some catching up to do with .NET. Cocoa libraries provide just enough abstractions to get stuff done, but they don't seem to be nearly as comprehensive and well thought out as the .NET libraries are. I found myself cursing some abstractions/APIs in Cocoa for their primitiveness compared to Windows pretty often. Generics give .NET an edge that Cocoa still doesn't have. Microsoft has done a great job of handling little things, such as boxing, which make development easier than it is for Cocoa.

XCode and Interface Builder are unfortunate crutches required for Mac OS X development - I would claim that it's impossible to write any decent application without using both. This sounds great until you realize that IB, which really is a designer, does so much magic for you that you just cannot with code. Linking up IBOutlets, for instance, is something I cannot imagine can be done outside of Interface Builder and has way too much magic associated with it. As a developer I often felt at the mercy of these tools, instead of being the master of it. It's fortunate that this is not true of developing for Windows - there is a lot of helpful magic that Visual Studio builds in but it's certainly not required to develop a decent application.

Overall, the Mac platform (Cocoa) seems more closed than it should be. This sounds weird, considering that it's all basically Unix and standard Unix libraries are provided or can be added relatively easily. My comment here related to how accessible and complete Cocoa/Carbon libraries are. Getting access to weird parts of the system is easier on Windows that on the Mac platform, I believe.

Deploying Mac applications is a snap, better than Windows. However, I think this is related to how developers are accustomed to (ab)using resources in Windows (registry, etc). Not having a lot of Windows' 'legacy' facilities on the Mac makes developers think hard about what their app really should be doing. I claim that good developers should be able to create x-copy deployable apps even for Windows, though, so it's unfair to blame the platform here.

The fact that it's built on Unix makes the mac support a lot more languages, especially scripting languages, out of the box. Windows is catching up fast though - integration of interpreted languages with .NET and PowerShell bring it at par with the Mac (I hear it might be better, but I don't have much experience).

Testing on the Mac seems easier. The fact that there are a very finite set of configurations compared to the Windows platform makes life less complicated for developers. It's almost true that if it works on your Mac it's probably doing to work on most Macs (modulo a few exceptions). History says this has traditionally been an advantage of the Windows platform, but I'm not so sure it's a good thing anymore. This one's probably the most controversial of my observations above and likely to change as I do more Mac work.

So, who wins? I would say Windows for the overall developer friendliness. Apple has some catching up to do in several areas. That said, the Windows platform could learn more than just a few things from what Apple seems to be doing right.

It's a fun time to be a software developer.

A Run on the Bank of Microsoft?

2009-01-16T13:41:00.000-08:00

Wow... did I just predict this? Yesterday, in my Problems at Facebook? post I referenced (somewhat jokingly) how I was kinda surprised that in the current economic conditions, the EU hadn't tapped into the Microsoft cash machine using some anti-trust excuse. Lo and behold, a few minutes ago Microsoft issued a press release in response to a 'Statement of Objections' it received from the EU about - you guessed it - European anti-trust law. Obviously, I had no knowledge of this when I posted yesterday - I'm just a foot soldier. The timing is a little spooky though... maybe I should muse of some good things happening. ;)

I wonder if this is the beginning of another run on the Bank of Microsoft by the EU...

Update: More coverage in the Wall Street Journal. This thing is probably going to go on for a while. Sigh!

Win 7's glowing reviews - a case of lowered expectations?

2009-01-15T13:19:00.000-08:00

Windows 7 was publicly released as a beta last week, and has been getting some pretty glowing reviews. I haven't yet seen a single negative review - everything I've seen compares Windows 7 much favourably over Vista and in many cases even over XP. ZDNet's review is pretty typical of most reviews I've read. Even traditional Microsoft haters (who shall go un-named) seem to be reacting favorably to Windows 7. Of course there are some brand new features, but I'm more concerned with the stability and snappiness of the OS.

While a lot of the praise is well deserved and a lot of people have worked hard on making Windows 7 what it is, I can't help but wonder how much of it is a result of peoples' lowered expectations from Microsoft with regards to Windows. Vista wasn't nearly as good as it should have been when it released (SP1 seems to have fixed a lot of stability issues, though it is still a resource hog) and the generally negative buzz about Vista has probably reduced expectations to the point where anything that's not sluggish, bloated and resource hungry would've received good feedback.

Anyways, nothing wrong with good reviews... here's hoping that Windows 7 will exceed all expectations when it's publicly released.

Problems at Facebook?

2009-01-15T12:41:00.000-08:00

I was thinking about the whole recession thing and how it impacts Microsoft. As I worked through my train of thought, I remembered the huge 899 million Euro fine that the EU slapped Microsoft with in Feb 2008. I remember thinking then that the EU was almost treating Microsoft like an ATM (probably inspired by this post).

I wondered why in this time of recession the EU hasn't yet again tapped its ATM and thought I'd update my Facebook status to say "Viraj wonders why, with this recession n all, the EU hasn't tapped its ATM (Microsoft) again using the same anti-trust excuse...". To my surprise, I got a little popup that said "Validation Error - A validation error occured" and nothing more informative.

Interesting. What exactly is Facebook validating, and did I have some red-herring text in there? I would expect filters for expletives, racial slurs, geo-political issues... but my status message didn't seem to violate any of those. I tried the following variants, which all failed:

"Viraj wonders why, with this recession n all, the EU hasn't tapped its ATM (MSFT) again using the same anti-trust excuse..."

"Viraj wonders why, with this recession n all, the EU hasn't tapped its ATM again using the same anti-trust excuse..."

"Viraj wonders why, with this recession n all, the EU hasn't tapped its ATM again..."

"Viraj wonders why, with this recession n all, the EU"

"wonders..."

Ok, so it's certainly not the text of my status message that's causing this. I started poking around, and my 'Home' page seemed OK - I had news items, status updates from friends, etc. However, when I jumped to my own profile, I was suprised to find that all data I had published was blank. No wall posts, no posted items, no recent history. However, my photo albums seemed to fine, as did my profile information.

My guess is there's been some kind of data loss-ish issue at FB (a lot of their data is simply held in caches so maybe a cache and replicas blew away - perhaps Wall posts are not persisted?). Anyways, I'll try to update status again and see if stuff comes back... meanwhile, I'm locked out of changing my Facebook status...

Any guesses about what might be going on?

Update: I can't seem to be able to clear my previous status message either... the status is cleared in the webpage (local javascript clearing it, I would assume) but on refresh I see my old status again...

Update2: And we're back... that didn't last too long. Cool!

Post on The Live Mesh Blog, PDC 2008

2008-10-08T20:46:00.000-07:00

I wrote a post on the Live Mesh Blog earlier today that talks about what I primarily work on - the Pub-Sub backend of Live Mesh. I briefly referenced that I worked in this space in a previous post where I commented on Apple's Push Notification announcements.

I've written tons of design documents, specs and tech summaries on the job but writing this post was an interesting exercise - I tried to make it readable for both the geeks and the regular folks in the audience (hence the references to the postal system). I'm not sure how well this will work... I guess feedback from the blog comments will be a good indicator of how effective the attempt was.

In addition to my awesomely smart teammates on the Live Mesh team, who I enjoy working with greatly, I wanted to send a shoutout to Tom who originally helped design a lot of the stuff described in the blog post.

For those who want more details about how stuff works behind the scenes, there are some Live Mesh related deep-dive sessions scheduled at PDC 2008. Sessions related to the Live Mesh backend architecture ("Live Services: Mesh Services Architecture and Concepts" by Abolade Gbadegesin) and backend communications services ("Live Services: Notifications, Awareness, and Communications" by John Macintyre) might be most interesting to those who were intrigued by my post on the Live Mesh Blog and are curious to know more.

Unfortunately, I won't be attending PDC - I'll probably be busy chugging caffeine and fanning servers while thousands of new users give our new Live Mesh offerings a spin. :)

More Food For Thought About Google And Exit Polls

2008-10-08T10:53:00.000-07:00

A couple of months ago I conjectured that Google might be able to produce a very accurate exit poll for the '08 Election. Today's post on the Official Google Blog shows some information that's very close to what I suspected they could generate - very cool. Particularly interesting is analysis of traffic from swing states. I'm sure they could do much more here - trending by counties, for instance.

In that previous post of mine, I guessed that they won't publicly release a prediction, but bits and pieces of information and trends like these are a good stand-in for a full blown exit poll.

Regret - Not Reading Enough Books!

2008-10-07T21:31:00.000-07:00

A very regretful personal trend I've noticed over the last few years is that I've been reading a lot fewer books than I used to, and I didn't used to read too many earlier either. This applies to works of fiction, self-help books, biographies, etc - the more 'traditional' books. I'm often reminded of this personal shortcoming of mine when I'm around friends and family who read a lot - I usually have much to contribute to conversations, until the topic turns to recent/popular books and I just draw blanks.

This regret hits home even more on the rare occasions that I do pick up a book recommended by my wife or my friends (on average, once in 2 months) - I tend to enjoy these books more often than not. The last works of fiction I read were Jhumpa Lahiri's Unaccustomed Earth and Neal Stephenson's Snow Crash - both recommendations which I enjoyed, and took about 1+ months each to read. I read much slower than most 'good' readers (my wife, who can chow down books orders of magnitude faster than I can), which means I have more breaks and more opportunities for distractions.

When it comes to non-book reading though, it's a whole different story. I'm a voracious reader of blogs, news, current events, technology, opinions and trivia. I can read a newspaper cover-to-cover as fast as anyone I know, browse through several blogs a day without realizing it and read editorials/articles online pretty regularly. Maybe reality is just more entertaining than stories, or lessons from current events are more exciting than lessons in self-help books, or maybe I just do well with 'shorter' reading.

Or maybe I'm just not comfortable with the form factor of traditional books, which is why I've been eyeing Amazon's phenomenally successful Kindle - I wonder if that's my panacea. It's not cheap though. It would be super-awesome to be able to rent a Kindle at local libraries to check it out. I would totally buy one if it let's me get back into reading more 'traditional' books.

Hmm, I'm really tempted now. Maybe I'll just cough up the dough and give this a shot. Anyone have good/bad experiences to share about their Kindle?

Surprised by Live Search

2008-09-30T19:14:00.000-07:00

I use Live Search as my web search engine of choice, but every so often I need to use Google to find the information I'm really looking for. I was really looking for a site that gave me good side-by-side results from both engines - kind of like how dogpile.com used to work in the old days (I was surprised to find dogpile.com still alive and doing search compilation, but I really wanted a side-by-side view from only my two preferred engines).

Recently, as part of an internal Microsoft initiative, I found exactly what I was looking for - a site that runs the searches in parallel and presents them side-by-side. As a bonus, you get to vote on which engine performed better. I've been using this as my default search engine on all my machines for the last few days and I'm already pretty surprised at how often Live Search comes up with far superior answers. I guess I never paid to attention to comparative relevance and quality until it was presented to me in such an 'in-your-face' manner. Of course, there are still many searches where Google trumps Live Search. Anecdotally, I'd say I prefer Live Search about 60-70% of the time, but maybe that's just me (and it could well be my inherent bias for Microsoft products).

One aspect that simply blew me away was Live Search's ability to fetch answers for very specific things I was looking for. A lot of these are powered by something Live Search calls 'Instant Answers'. A few samples from queries I performed over the last week where I was really impressed by Live Search:

- MSFT GOOG AMZN AAPL quote vs MSFT GOOG AMZN AAPL
- seahawks schedule vs seahawks schedule
- highest peak in the US vs highest peak in the US
- calories in beer vs calories in beer
- president of somalia vs president of somalia
- Colt McCoy vs Colt McCoy

These were just some of the searches I ran last week - the Instant Answers site has other query formats you can try (incidentally, I didn't know about Instant Answers or the formats until just two days ago). One place where Google still beats Live Search hands down is showing inline maps and directions. I use this fact to give a lot of sh*t to a friend of mine who works on Live Maps - maybe one of these days I'll annoy him enough to make him go fix this stuff! ;)

Bill & Jerry, and A Lame Blog Post

2008-09-12T13:48:00.000-07:00

You've probably seen the new Microsoft Windows TV ads featuring Jerry Seinfeld and Bill Gates. The second in the series showed up last night.

When I first heard that Jerry Seinfeld was signed for the ad campaign, I wasn't really sure if he would appeal to the current generation (and I'm not sure he does). I'm a Seinfeld fan though, so I was curious what the campaign would be like. I have to be honest - the ads were completely not what I was expecting. FWIW, not many in the company had seen the ads before they were shown publicly - at least, I hadn't.

Anyways, it seems like the ads have people talking. From what I've read, the reaction seems to be neutral to leaning negative - I think people were expecting a more direct retort to Apple's Mac vs PC ads. Personally, I found the ads pretty amusing. Subtle humor, no direct attacks and entertaining. I think Bill easily outshines Jerry in both ads so far. I had seen Bill Gates act in silly videos at company meetings before, plus in his last day at Microsoft video, so I knew he can do a decent job but I didn't think he could out-do Seinfeld. There are subtle references to Microsoft products and technologies throughout the ads - pretty funny for someone close to Microsoft but I can see how pretty much everyone else might miss it. From the coverage the campaign has gotten and the pervasiveness of the ad spots, I'm pretty impressed with how much buzz the campaign has already generated. A lot of critics have complained that the ad hardly mentioned Microsoft or Windows... does it really need to, though? Bill Gates == Microsoft == Windows. No more logos/information needed.

Knowing nothing other than what I've seen on TV so far, I think this will definitely be a long-remembered ad campaign. It looks like its going to be one of those hugely successful or hugely miserable ad campaigns. Of course, given that work @ Microsoft I hope it's successful.

I wonder how many CEOs have featured in ads. I can remember a few in recent times - Chrysler, Sprint, Ford. None of those had the CEO doing comedy, though. CEOs, especially founder-CEOs, have huge brand appeal and brand recognition so they seem to be a natural fit for come-back type ads. I hope Microsoft has better success than Ford, Chrysler and Sprint are having currently, though.

Given the buzz around the ads, I was kinda annoyed when David Webster from Microsoft, who's apparently running this campaign, posted an entry on his blog trying to justify the ads - the text of the post just reeks of defensiveness. If you're ballsy enough to sanction $300 million for an ad campaign, there's no need to put up a blog post trying to justify it even before the entire campaign has run its course. His tone sounds like he's trying to save his job already - where's the confidence, man? Super lame, Mr David Webster. I think you should've just kept quiet and let the campaign do the talking (or not, if they don't succeed).

Can Google Predict Election '08 Results?

2008-08-28T17:50:00.000-07:00

Today's post on TechCrunch about possibly predicting election results using web traffic analysis reminded me of my thoughts from a few months ago.

Over the course of election season, starting with the presidential primaries through Super Tuesday and going into the national conventions, Google began releasing increasing amounts of election-related content and services. Reading the blog posts linked above and noticing the trend from Google leads to me the conclusion that the most relevant exit-poll for November's presidential election this year might actually come from Google.

Google likely already tracks user searches and email data from GMail. Combine that with some pretty basic data mining around traffic analysis, comments on their targetted election sites and popularity of their election related content/services and you could now get a pretty good 'pulse-of-the-nation' with respect to red state-vs-blue state. My guess is that the big push around election related content and services is an attempt to not only increase pageviews, but also harness large amounts of interesting data that can be mined for various interesting purposes. Additionally, this gives them a large data set to use to refine their own data mining technologies. I strongly suspect that Google will hold on to the raw data past election time and used it as test-data to track progresses in their mining technologies. Good data to test your technologies is *very* hard to to come by, and it would be foolish to let such rich data simply fall by the wayside.

Whether they publicly release their 'exit-poll' is another story altogether. I don't think Google really has much to gain by releasing the data even if they do manage to mine it. I know I wouldn't - I would mine the data, distribute predictions among team members for entertainment purposes only, see how close I got to the result, refine my algorithms and run it over the same data again to see how much closer I am now, and repeat. Releasing the data publicly, even if it turned out to be dead-on accurate, wouldn't buy me much. If it wasn't dead-on accurate, there is some amount of geek-cred that would be lost.

I guess November will prove if my theory above is correct.

P.S. I hope you picked up on the paradox in that last sentence above... :)

$10,000,000,000 == $1

2008-07-30T12:04:00.000-07:00

I'm no economist, but it's hard to not have seen this coming. From the article:

Zimbabwe will drop 10 zeros from its hyper-inflated currency -- turning 10 billion dollars into one -- the country's reserve bank said Wednesday. President Robert Mugabe threatened a state of emergency if businesses profiteer from the country's economic and political unraveling.

Just a couple of weeks ago, Zimbabwe introduced a 100-billion dollar bill, and it didn't buy nearly enough. People are suffering in Zimbabwe while a corrupt government mismanages the economy. I truly hope their economy recovers soon...

Doing Something "Just Because We Can!"

2008-07-28T15:05:00.000-07:00

Working on a distributed system like Live Mesh is a lot of fun, but finding certain types of bugs can be interesting, to say the least. Going from writing code that executes locally on a workstation to writing code that is executed across several hundred machines is an extremely refreshing experience - you quickly learn to spend a good amount of your time and energy building a good logging infrastructure and leveraging it to diagnose problems. There are several other things you learn too, but that's worth a series of its own posts.

With a large amount of logs comes a large amount of interesting data, and an even larger amount of potentially interesting data. Good logs can go a long way in helping infer information about the scale, health, bottlenecks, usage etc of the system. Much time is spent automating such tasks so that useful reports can be generated from logs. Every so often, someone (usually a non-tecnnical person) asks for additional interesting data that would take time, effort and money (in terms of resource utilization) to extract. However, almost all such requests are missing information about what the requester hopes to conclude based on the retrieved data. My instinct is to always push back on such requests, forcing the requester to justify what questions the data will help answer or what conclusions it'll help lead to. If the data gathered does indeed help answer a crucial question, it's worth spending time and money mining the logs for it.

Very often, the reason for the request is "just because we can", in which case I believe the time/money/effort spent is unwarranted unless you have people/machines sitting around doing nothing, in which case you arguably have other problems.

Moral of the story - try not to ask someone else to do work (or spend your own valuable time doing work) without knowing what you intend to get out of it.

Blown Away by IMAX (Again)

2008-07-23T09:47:00.001-07:00

I caught The Dark Knight at IMAX, and it was so worth the wait (waited in line for an hour, on a weeknight!). I've watched a few movie at the Boeing IMAX Theater at the Pacific Science Center a few times now, and each time I come back amazed at the infinitely better movie-watching experience that the theatre provides. Select scenes of The Dark Knight were shot for IMAX (pretty much all cityscape scenes in Gotham City and Hong Kong) and they were just stunning. Too bad there were no real 3D scenes, like there were in Harry Potter and The Order of the Phoenix. I really need to catch more movies at IMAX - its likely the long lines that put me off, but I need to keep reminding myself that they're totally worth it.

If you have a choice to watch a movie @ IMAX or at your neighborhood multiplex, do yourself a favor and pick the IMAX experience.

What Live Messenger, AIM and Y! Messenger Need to Remain Popular

2008-07-17T09:59:00.000-07:00

Two things - broadcasting and aggregation.

Windows Live Messenger, AOL Instant Messenger, Y! Messenger and Google Talk and several others are hugely popular Instant Messaging applications. Almost all offer rich client experiences as well as web-based versions. I remember reading somehwere that IM apps are the most used apps on computers, and I am pretty sure they will continue to be for the near future. Demand for IM applications on the web is pretty strong too, with sites such as Meebo growing in popularity.

IM clients have been very innovative over the years, starting from simple 2-person chat to having multi-party conversations, voice support, application sharing, file transfers, etc. Innovation in this space seems to be slowing down though - I haven't seen any new game changing features in any of these IM applications. They all seem to have missed the move to a more social web. In many ways, these apps should have been the ones driving the social web, with their knowledge of social networks via friend-lists. However, websites like Facebook, MySpace and Orkut have firmly established themselves as the drivers of innovation in the social space.

Consumer interactions are evolving from being specifically directed to an individual or small group to being widely broadcast. Blogs, tweets and public profiles are visible to anyone and often are used as a broadcast medium. Increasingly, status messages on social websites and, more importantly, micro-blogging are encroaching on the IM space. Twitter clients such as Twhirl are a great example of this encroachment - users interact with it if it was an IM client but it's really just an app that allows broadcasting messages. YouTube is another hugely successful broadcast medium.

Ofcourse, users also want the ability to have personal, directed conversations along with the ability to broadcast - both to a select group (their network) as well as broadly to the world. For IM application to remain relevant and to fulfill this need, they need to include broadcasting features in addition to preserving the existing communication & collaboration experiences. There are multiple potential approaches to do this - use existing APIs of popular social platforms to allow users to broadcast to a specific network or to farm out to multiple social networks

With the desire to broadcast comes the desire to learn about what others are boadcasting. Most (all?) social websites have news feeds and services can aggregate several such feeds to present a unified view of a users online broadcasts/activity like how FriendFeed does. An IM application would be an ideal home for such an aggregated feed.

In many ways, Facebook is almost there with regards to being an ideal IM application. It has the advantage of being a really popular social platform, which certainly helps. Facebook recently complemented their broadcast communication feature (status messages) with IM-like functionality to enable personal communications. And of course, Facebook pioneered the news feed. Now if only they could go broadcast to and aggregate from competitor sites too... ;)

The arguments above apply even to corporate IM applications - this is not just a consumer need.
Unless traditional IM applications evolve to fill this need and compete with the Facebooks of the world, I see them dying a long, slow death.

Netflix on XBox 360 == Silverlight on XBox 360?

2008-07-14T18:20:00.001-07:00

I'm really excited about today's announcement regarding Netflix streaming on XBox 360. I have an XBox 360 but I wasn't really impressed with the selection of movies and shows on XBox Marketplace - I'll definitely be signing up for Netflix once the XBox update rolls out. I don't care much about the content sharing part of the announcement though - why watch a movie together with friends when you aren't really together?

I'm not sure if you remember, but Netflix showed off a very slick Silverlight based streaming video player at Mix 07, that also included sharing. I wonder if this announcement means that Silverlight is coming to XBox 360. If it is, that would be very cool indeed. Can you imagine the kinds of applications that would now be possible to run on the XBox? The power of XNA and Silverlight could make XBox 360 a killer platform. It could also enable your XBox 360 to become part of your Live Mesh!

Losing Objective Reporting Would Suck!

2008-07-11T16:50:00.001-07:00

Earlier today, CNN and NY Times had perfectly contradicting headlines for what was supposed to be the same news report:

Times: F.C.C. Chief Backs Sanctions Against Comcast Over Blocking
CNN: FCC Chairman Recommends No Fine for Comcast

It's interesting how opinion and interpretation can affect perception.

With increasing globalization and the Internet becoming the primary source of news, I often notice news stories take a life of their own as they spread through different media channels. It's harder today than it was a few years ago to find objective reports - reporters/bloggers increasingly tend to state facts that are inter-twined with opinion. In many ways, blogs need to be this way in order to allow conversations to continue (blog post + comments = conversation) but it is unfortunate that traditional media outlets also increasingly feel the need to add opinion and personal biases to news reports.

Traditional media is still very far behind the blogosphere when it comes to mixing opinion with facts, but I think it would be unfortunate if the current converging trend here holds for long. Without objective reporting, there would only ever be a bunch of opinions floating around, and people would lose their ability to form personal opinions which today derive from facts.

Favorites vs Underdogs

2008-07-08T07:48:00.000-07:00

The 2008 Wimbledon final from a couple of days ago was epic. Perhaps the greatest tennis player ever against a potential future legend. Sport sites were all over the actual game coverage, but I was fascinated by the psychology of those audience watching the game.

As I watched the game with friends and family, I found myself to be the sole supporter of defending champ, RFed. Everyone else was rooting for Nadal.

This seems to be a theme with me - I was rooting for the Pats in Super Bowl XLII, for Tiger Woods at the US Open last month, for Australia in the 2007 Cricket World Cup, etc. I seem to want the favorites to triumph. Most friends of mine and most others out these seem to always favor underdogs.

I wonder what makes an individual go one way or the other when it comes to supporting the favorite vs supporting the underdog.

Leaving aside the betting aspects of it all, my naive guess is that who one supports has something to do with projecting one's own life experiences. If you've struggled and played the role of underdog more often than not, you empathize with another in the same situation. If you've been on the other side more often, where you've always needed to 'defend your turf' in some way, you probably ed up rooting for the champ.

Someone somewhere has probably written up a study that goes into the exact psychology of it all, but I stand by my extremely un-scientific claims above while I procrastinate trying to find said study.

Virgin America FTW!

2008-07-08T00:12:00.000-07:00

Over the 4th of July weekend, I flew Virgin America and was blown away. It's amazing how they've used technology to out-perform their competition in almost every aspect.

Well, their fares were unbelievably great - $170 for a round trip ticket from SEA to LAX two weeks before the 4th of July. Their website is simple and slick, and they have a great model where you're charged a base price and 'frills' come extra (for instance, an exit row seats adds $15 to your ticket cost - I would totally pay for the extra leg room on a long flight). Their check-in and gate counters are Apple-slick and their brand spanking new planes are fitted with pleasant neon lighting and comfortable leather seats. Their in flight entertainment system, called Red (hip with the 'Beta' tag), is superior to any other I've seen in the US. It seemed to have just the right amount of free and for-pay options. Free lineup - live TV, music, games, soda/juice. Paid lineup - movies, food and alcohol (that's right - you order food and drink using the snazzy touchscreen and pay using your credit card). It even has this cheezy-yet-fun chat app which lets you join a chatroom (haven't seen one of those in years!) or send IM to a specific seat. Oh yea - each seat gets its own power outlet, even in economy. Their use of technology on the ground and in-flight seems to have allowed them to reduce staff and yet enhance the flying experience.

By tailoring their service and catering to today's generation, they're focusing on the right things. and the primarily west-coast service seems to be a great fit for their 'attitude'. Oh, and having really pretty air-hostesses helps too. Co-incidence, or perhaps a signature Virgin move ;)

Anyway, I would never fly another airline if a Virgin America route was available and reasonably priced. My guess is that they're losing money like every other airline (but less than others, probably). However, if they're in it for the long haul, I think they're making all the right moves.

Viraj's Guide to Interviews - Conducting an Interview

2008-07-02T12:29:00.000-07:00

Over the last few years, I've done a bunch of interviewing - both as the interviewer and the interviewee. However, things had slowed down on the interviewing front for the last year while I was primarily focused on getting the Live Mesh Tech Preview out the door. I conducted an interview yesterday after a long while, and thought of posting about my own list of interviewing best practices. Interviewing ranks as one of the more critical functions for the success of a team/company, so I work hard at giving it my best.

I am not, by any means, an expert here but I have been interviewed by some excellent interviewers (primarily at Microsoft, but in quite a few other companies too) and I made it a point to keep mental notes of things they did well so I could apply them to interviews I conduct. While all my experiences have been in computer science related interviews, the list below likely applies to other fields too.

1. Spend at least 10+ minutes before an interview to plan what set of specific skills you intend to assess. It's naive to think that you can cover more than 2 skills in any sort of detail for each hour of interview time. Use part of this prep time to read the candidate's resume and understand his/her previous experience.

2. Make sure the candidate is comfortable, and the environment is conducive to conversation. Conduct the interview and manage interactions the way you would want them to be if roles were reversed. There are times when you want to simulate high pressure situations, but this should be rare and I recommend avoiding it if possible.

3. Ask questions that will help you assess skills needed for the job, and keep conversations relevant. Puzzles and teasers are fun to ask and often even to answer, but that don't tell you much about the candidate's skills. Problem solving, on the other hand, is a great exercise to assess the candidate's analytical skills.

4. Don't let the candidate drive the meeting. Often, candidates get into a safe zone (talking about resume items, for instance) and tend to not let you proceed with your agenda. Respectfully driving the conversation back on track, even if it means cutting off the candidate, is the right thing to do.

5. Don't try to prove you're smarter than the candidate. Remember that the goal is to gauge the candidate's skills and not to prove that you deserve to be interviewing them or are smarter than them. Many times you actually might not be, and that's OK!

6. Pay attention when the candidate is talking. Checking email or generally being distracted shows lack of respect.

7. If the candidate is struggling with something for over 4/5 minutes, help steer the candidate to a solution. Assess how the candidate reacts to hints and whether they're able to regain their composure.

8. Gauge the candidate for team fit and other non technical skills. Is he/she someone you would enjoy working and interacting with? How can he/she help you grow your own certain skills? How organized and methodical is his/her approach to problems?

9. Leave the last 5/7 minutes of the interview to answer the candidate's questions, and be as honest as possible. False sales pitches are often easy to detect and say a lot about your character (and that of the company). Try to determine whether the questions asked are genuine, or mundane and uninteresting. Often, what they ask says a lot about them.

10. End an interview with concrete information about what the next steps are for the candidate. If you don't know, make sure you refer the candidate to someone who does.

Any other interviewing best practices you've experienced that aren't covered above?

Some thoughts on Apple's Push Notification Service

2008-07-01T19:40:00.000-07:00

Last month, at WWDC Steve Jobs announced iPhone 3G. Very cool. I think the iPhone is a game changer. Enough people have dissected the iPhone 3G that I'll skip re-stating what everyone knows already.

One of the more interesting announcements Jobs made at the WWDC Keynote was the iPhone Push Notification Service. In short, it's a single channel from the cloud to each iPhone, and can be used by software publishers (in addition to Apple) to send signals to apps on the iPhone without having to worry about creating their own custom channel to the cloud or using polling schemes. This sounds like a win-win for both publishers of iPhone apps and for Apple.

Given that I work in a similar space, this was interesting to me. We had been thinking along similar lines and have in some ways even taken the concept even beyond what Apple announced. I'll save the details/designs of what I'm working on for another post.

The technology Apple touted sounds a lot like Exchange Direct Push/Always-Up-To-Date, except that it opens up the channel from cloud->phone to third parties instead of the exchange model where the only publisher is Exchange and the only consumer is the Outlook Mobile client.

The design challenges of opening up a channel of this sort to third parties are:
1) Delegated authentication to allow third parties to use their notification channel
2) Routing notifications to the correct iPhone
3) Introduction of a single point of failure for most apps on all iPhones (kinda similar to AT&T going down - if Apple's service goes down all cloud-dependent apps are 'bricked' unless they have some form of background polling, which would defeat the purpose of the single notification channel since Apple touted battery life as their primary motivation. BTW, I don’t believe that is their primary motivation – more below).

One interesting feature they did not talk about, and I believe that they won’t add anytime soon, is a 2-way communication channel to allow for messages from the phone to the publisher. The notification channel is likely 2 way inherently, but communication from the phone is only ever seen by Apple.

Here are my guesses on how they deal with the above three:

There is only one way to get apps on the iPhone (assume non jail-broken iPhones) – the Apple App Store. To publish to the store, publishers share revenue with Apple. I’m certain there is some kind of certification that happens at this stage to ensure that apps are well behaved. Once certified, the publisher probably gets a ‘security token’ to communicate with Apple’s Notification Service if they want to use it. Further, my guess is that each app published by each publisher might have a unique security token. I presume that the content of Notification that publishers push through the channel would be encrypted and opaque to Apple – it would be very bad if that’s not the case. However, at least 2 pieces of information must be known to Apple – who is publishing and whom is the Notification going to.

My guess is that Apple is told what phone to send a notification to by publishers, versus figuring out itself where to route the Notification. In other words, the subscription is held by the publisher and not by Apple. The reasons I think this is how it must be is:
- Apple would not like to be responsible for tracking subscriptions of each app on each iPhone. It would mean they have a ton of subscriptions to manage, plus they need to perform lookups in their cloud for routing notifications to the right phone. By letting publishers deal with this, they are no longer responsible for the costs incurred of maintaining these subscriptions. Apps that create several hundred subscriptions cost the publisher, and the cost of performing lookups are also incurred by the publisher. This makes Apple's SLA much simpler.
- Publishers (I hope) would not want Apple knowing data about their customers.

#3 is interesting – the service needs to be robust again badly behaved publishers. Their first line of defense here is probably their certification program. Apps must not do wild-card broadcasting, must not poll, must have an upper limit on Notification payload sizes, etc. Note that the announcement yesterday was only to allow 3rd parties to support 3 types of Notifications – ‘badges’, ‘audio alerts’ and ‘text alerts’. By nature, the first two should be tiny in size, the third probably has an upper limit on size of text. Their second line of defense is probably real time metering and throttling. Apps must be self metered or will be throttled by Apple. Publishers are motivated to adhere by these guidelines because Apple controls publishing their app and could impose restrictions on downloads of the app in the App Store.

Regarding Apple’s stated motivation for the Notification Service – I suspect they have more interests than just “preserving battery life”. By controlling the App Store and this Notification channel, Apple now has direct insight into a ton of data that can be mined – what apps are most popular, what apps are most chatty, what app is the ‘flavor of the month’ by usage and not just by download metrics, most active users, etc. They can use this data both ways – to make special licensing deals with specific app makers they detect are 'hot' and create popular apps (popular download is different from popular usage) and also to directly target ads/other apps to consumers.

Other's have posted on how Apple might be building something similar for the Mac. They probably are, but the motivation for publishers to use such a channel is greatly lesser in case of Macs. There is no single channel of publishing apps for the Mac, although they do make it easier. As a publisher, the primary attraction of using something like this would be to not have to build something yourself, but I think the need to share revenue with Apple, get certified and distributed via official Apple channels only and use Apple as the middle-man for what essentially shouldn't be any of their business might act as deterrents.

Why am I blogging?

2008-07-01T18:18:00.000-07:00

It's kinda funny how I feel the need to justify why I'm blogging, as if every blogger must blog to serve some purpose. I think such justification is warranted, but doesn't really need to be expressed. As long as you know why you're blogging, you're good.

I am a voracious reader of blogs, but never really got into blogging myself. I've tried this a couple of times before, but those were more academic exercises than real attempts to start blogging.

As I read blogs, observe people and their behaviors and basically live each day I form opinions, like most other human beings, that I keep to myself and sometimes (very rarely) express them to people I interact with personally. However, I think it's time to unleash my opinions to the Intertubes - everyone else is doing it, so why shouldn't I? ;)

Seriously though, there are a couple of reasons why I feel the need to blog -

As an engineer, I've found myself making observations and critiquing things that others benefit from. I've been told that my opinions are often 'interesting' (whatever that means), and while I may not always be right, I seem to have built a decent track record that gives me the confidence to risk embarrassing myself in public. I'm hoping that my blog posts about Technology will be even mildly interesting to others out there. There's the personal growth angle here too - in many ways, articulating thoughts into words takes some effort and makes you reason with your opinions. Blogging seems to be a great way to cultivate this skill.

The other big reason to blog is to be a participant in this new world of open communication, instead of being just a spectator. Reading interesting blogs but not blogging myself made me feel like I'm cheating, in some ways. I know I'm late to the party, but better late than never! I hope to use this platform to comment on society, trends, human behaviors and anything else that I wish to express.

Lastly - and I'm ambivalent about this one - I believe blogging will somehow help my professional career. It's almost as if nowadays, the fact that you have something to say is as important (if not more) than what you have to say. I don't want this to be an explicit goal of blogging (which is why I intend to blog about more than just Technology) but as the saying goes "If you built it, they will come". Notice how nondescript 'it' and 'they' are - by design!

Oh, as far as the title of my blog goes - I was looking for something witty (I envy all the bloggers-with-cool-blog-names out there) but I ended up with something more aligned with the reason I'm blogging - "Mulligan!", my chance to re-do.

Argh - who am I kidding - the truth is, I just played a crappy round of golf today (shot 118, lost 4 balls and broke a club) and I couldn't come up with anything better.