Maybe I’m the last one to realize this…

ShareThis

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

ShareThis

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.

ShareThis

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.

ShareThis

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

ShareThis

Simply watch the video above.. This is the first iPhone app I’ve seen that takes advantage of it’s unique abilities. Imagine this game with OTA multiplayer built in! I’m a sucker for good puzzlers so I just might have to pick up the non-existent iPhone 3g.

ShareThis

The biggest news is that App Engine is free to use up to a certain amount, like all other Google developer services. (As I previously postulated.) Pricing after the free period has yet to be determined.

Applications cannot use more than 500 MB of total storage, 200 million megacycles/day CPU time, and 10 GB bandwidth (both ways) per day.  

The downside is that all the apps have to be written in Python. It’s a language that’s not as popular as PHP or as chic as Ruby but has been proven to scale and seems to be getting traction again as django matures.

I, for one, would love to be getting back into Python but Google App Engine won’t be a home run until they offer it in true services style. Any language and piecemeal. For example, as I read it, I can’t use BigTable and GFS for my self-hosted PHP application. Undoubtedly, this will eventually happen. I can also see Amazon firing back making portions of AWS free for small users.

Update: HighScalability.com has a good technical overview of GAE’s sandboxed python environment.

ShareThis

When doing my new mousemove test I found a bug in IE5-7 that I was previously unaware of. When the user moves the mouse over the element, the mousemove event fires many times, as it should. However, when the user stops moving the mouse, IE5-7 continues firing the event every once in a while. This stops only when the mouse leaves the target element entirely.This is obviously a bug: when the mouse does not move the mousemove event should not fire.  

On top of that he’s stating that the bug has been copied by the Safari and Opera team. I think it has less to do with the browser implementations with more with operating system oddities.

For example, OS X Firefox 2 mousemove events are triggered when Firefox is brought back into focus (using cmd-tab, no mouse movement). However, on Windows XP sp2 Firefox does not display the same behavior! You can say this is a bug for Firefox’s mousemove event implementation or you can push that on the operating system for sending a mousemove event to firefox itself. Six in one hand, half dozen in the other.

Also interestingly, Safari 3 on OS X, the mousemove events are fired every time a key is depressed and then released! On Windows XPsp2 IE6, the mousemove events are triggered anytime the screen is redrawn. You can all sorts of fun yourself with PPK’s test page.

The bottom line is that if you happen to attach logic to the mousemove event just make sure it’s safe to call multiple times.

ShareThis

The basic premise is that if GWS were free, Google could reap the benefits of having a whole heap of developers tied into their platform. After which acquiring a company would be much less cheaper if they’re already tied into the Google cloud. I can see Google making a move like this for the normal user but they would eventually have to charge for larger customers. After all they already provide 6.5 gb of storage space for gmail users but providing unlimited GWS usage is a hit not even the mighty Google can take.

ShareThis

In the world of broadband, limiting connections per host to 2 makes little sense. Us fronteers have been forced to do subdomain hacks, css sprites, etc to deal with this. I’m psyched.

Steve Souders also has a good wrap up along trying to answer the question of will this break the internet?

ShareThis