Wayne Pan

We launched our AdMob iPhone ad units, developer contest, and publisher network. Shortly, if I can figure out if the webkit portion of the SDK is under NDA or not, I’ll be posting a postmortem on. If you watch the video below, you can see we did some amazing javascript and css stuff.

Until we launch…… Update soon.

I just downloaded the Wordpress iPhone app and I’m tapping out a post on it right now. I mean if some of the best selling literature in japan is tapped out on mobile phones surely I can post to my blog on an iPhone!

Actually to be painfully honest it’s horrible. Apple seriously needs to open up the bluetooth and data ports on this thing. Bluetooth keyboard would simply kill all other devices put there. TechCrunch wants to build a cheap tablet pc? Why bother? And I would post a link to the rumor that Apple will release a Mac Touch but, yup, that’s right, no cut and paste.

Imagine also a joystick/pad peripheral… The iphone instantly becomes a killer gaming machine that out matches Nintendo DS and Sony PSP combined.

Besides the obvious physical keyboard and cut and paste, here’s a list of annoyances…

1. Easy Email Mass Delete - with my Pearl it was easy as [shift+scroll] [delete]. With my iPhone I have to tap each email… if I have 50 emails in a row I want to delete tap tap tap tap….
2. Mark all Emails Read - not possible on the iPhone
3. Blinky Light Notice - It was nice just glance at my Pearl and see that there was a new email or txt. On the iPhone you have to actually unlock the phone and hit the home key (if you’re not already there) to see how many emails you have. They should really put an indicator on the top bar.
   
4. One Touch Bluetooth on/off - Being able to turn on/off bluetooth from the home screen of the Pearl was handy when I wanted to save battery. I don’t use a headset much so I usually keep bluetooth off. On the iPhone it’s at least 4 ‘clicks’ away to toggle bluetooth. (Yes, turning off bluetooth does save battery.)
5. Scroll to the end/home - one key on the Pearl to get to the top of my email list, web page, email, etc… Not possible (except scrolling to the top in Mobile Safari) on the iPhone.

I finally converted to an iPhone (even lack of a physical keyboard, cut and paste, easy mass delete, mms .. but that’s another topic). I went for the 8GB because I don’t watch video and like the fact that less storage means I’m forced to be picky on what music I travel with.

However, I still think 8GB is too much thanks to Pandora. This morning I drove to work with my iPhone plugged into my car adapter listening to Pandora all the way. In fact a co-worker of mine said he has yet to listen to his MP3s on his iPhone, instead opting for the unpredictability of Pandora. Genius. Looking at the stats and such I’m not alone.

What does this have to do with Sirius and satellite radio? Well the connection is not hard, Sirius should stop R&D efforts on radios/handhelds and run Sirius over next gen cell phones. Making streaming equipment is far less cheaper than making car stereos and investing in satellites.

I just realized why Apple is willing to sell the iPhone for $199. No it’s not the kickback from AT&T. It’s the apps! They’re undoubtedly losing money on the device and banking on the fact that people will purchase so many apps over the life of the device. Sound familiar? Yup, it’s the same business model as the video game console market.

Maybe I’m the last one to realize this…

I just installed the ShareThis button on this blog so I cracked open the javascript payload. You can view it here. In short, it’s horrific! It pains me to see this because this is a widget which means this code is running a million times a day!

First, let’s get some basics out of the way.

• Comments and white-spaces are left in the code, increasing the payload size. I suggest using YUI Compressor before posting the code.
• Lines 1-3 - MooTools is included at the top of the script, PACKED. Thanks to PB Wiki’s Tests, we now know this is bad for client side performance. Stop doing this, see above!
• Lines 3-12 - They’ve included the FireBug Lite code to account for the 5 occurrences where they use console. Remove the 5 debug statements that don’t do squat and you can shave off ~350 bytes

Doing the above netted a 6940 bytes savings or a script 65% the size of the original (not to mention the client side cycles shaved off by removing the packed mootools). Click the link below to view it.

13048 Apr 21 00:17 sharethis_widget_better.js
19988 Apr 21 00:18 sharethis_widget_original.js

Digging into the code further I found a lot of various space saving things that could be done in the code (using radix in parseInt, avoiding at least one try catch block 83-89, etc). Also a few oddities like lines 329 - 332 (which looks like a bug), just asking for trouble by using _s in the global space, and wtf is going on with lines 460-464? Declaring _query to be [] then passing it to the ShareThis object, which from what I can tell doesn’t do anything, then setting the query property again to _query (which is really []) and then pointlessly setting a variable st to the newly created ShareThis.

I know I’m guilty of writing bad javascript also, but if you’re a company distributing a widget you should at least clean up the code a tad… ironically the ShareThis widget appears immediately after this line. =|

I had the pleasure of attending the first Javascript SF meetup at the Hi5 offices a couple days ago. It was a rather large turn out with some great demos. The main themes of the night were Canvas and Javascript frameworks to develop desktop apps. A few thoughts on the talks:

First up was SproutCore presented by Charles Jolley which is what I would imagine if Javascript and Ruby on Rails had a love child together. The basic premise is to allow you to develop desktop type apps with javascript and ruby. The best part of the app is the build system which merges all your javascript and css, even spriting your images.

After SproutCore, Douglas Crockford came to pimp his new book JavaScript: The Good Parts. Ajaxian joked that it would be a 2-pager at most but Crockford said it would easily the densest book about javascript (weighing in 120 pages). A quote from the book:

Most programming languages contain good and bad parts, but JavaScript has more than its share of the bad, having been developed and released in a hurry before it could be refined. This authoritative book scrapes away these bad features to reveal a subset of JavaScript that’s more reliable, readable, and maintainable than the language as a whole-a subset you can use to create truly extensible and efficient code.

I’ll definitely be picking this one up.

Somebody (I don’t recall who) mentioned flotr, a javascript charting library. It’s been around for a while but this is the first I’ve looked at it. There are definite benefits in doing charting in canvas versus flash but my worry is IE6 and 7 support. Even though IE 6/7 are supported through ExCanvas, I still don’t feel comfortable with the landscape.

Easily the best presso of the night was from the 280 North founders showing off not only their upcoming app 280 Slides but the framework that it is built on. Ross Boucher and crew asked the folks to keep the wraps on what was shown at the meetup so I won’t delve into it much more. All I can say is the app is far superior to any of the current online slideshow offerings out there right now. It basically looked and functioned (very speedily too!) like a normal desktop application. The framework which has been in development for over 2 years is unlike anything out right now. I’m not sold on it yet but they stated that their plan is to open source it so I’m looking forward to getting my hands on it when they do.

By far the funniest moment of the night was when Yehuda Katz was demoing ruby-spidermonkey. Right before he showed an example using ‘with’, he turns to Crockford and says “Sorry Doug”. The entire room started laughing which meant everybody in attendance was a bonafide javascript geek. Awesome.

I’ve been developing a small app using Google’s AppEngine. My first impression is that developing in the sandboxed python environment forces you to KISS. The SDK makes things dead simple in terms of templating, data access, and controlling which scripts map to which urls.

The side affect of abstracting the data access layer is that I no longer have to spend much time with database schema. That’s because AppEngine doesn’t run a traditional relational database and doesn’t allow you to run traditional SQL against the data store. I end up writing horribly un-optimized ‘queries’ because I’m not able to write highly optimized SQL queries. The SDK is obviously geared to take full advantage of the instant look up and high throughput that BigTable excels at.

For example, for these 2 objects:

class Attribute(db.Model):
  author = db.UserProperty()
  content = db.StringProperty(multiline=True)
  date = db.DateTimeProperty(auto_now_add=True)

class UserAttribute(db.Model):
  attribute_key = db.ReferenceProperty(Attribute)
  user = db.UserProperty()
  date = db.DateTimeProperty(auto_now_add=True)

I can access all the Attributes that belong to the User with the following code:

    query = db.Query(UserAttribute)
    user_attributes = query.filter('user =', \
      users.get_current_user())
    attributes = [ua.attribute_key for ua in user_attributes]

I’ll keep updating as I dig into the SDK.

Russell Beattie’s Mowser is shutting down and boy is he bitter.

… the general answer is that I don’t actually believe in the “Mobile Web” anymore, and therefore am less inclined to spend time and effort in a market I think is limited at best, and dying at worst.
…
In other words, I think anyone currently developing sites using XHTML-MP markup, no Javascript, geared towards cellular connections and two inch screens are simply wasting their time, and I’m tired of wasting my time.

According to AdMob metrics mobile web usage is far from dying. A trend you do see is that people who have internet enabled devices and all you can eat data plans are using the mobile web more and more. The main issue with current carriers is the confusing pricing for data plans. Do you know how much it would cost you browse the web?

I know for a fact that users with two inch screens regularly get online with their cell phones. There is a certain carrier, who we’ll call Carrier M, who bundles unlimited data with their plans but only offers very basic phones (no smartphones/iPhones). Customers of Carrier M make up a large amount of traffic on AdMob’s network disproportional to Carrier M’s market share.

I also believe that better browsers will eventually become the standard for mobile browsing. iPhone, Android, LiMo are all going to offer phones with WebKit. But at the same time there will still be mobile specific sites (see all the iPhone specific versions of webpages out there).

As for Russell’s rant, I just think he’s blowing off steam. I applaud anybody who takes the huge risk of trying to start their own company. I wish him the best of luck and hope he doesn’t give up on mobile.