So being an overly curious bugger, I downloaded the deb pkg for Ubuntu32. Yeah, it looks pretty rough — but what the hey, it’s a PoC right? So, I thought maybe a little speed test is called for, so I googled “javascript test” and my cloud brain returned, “Sunspider JavaScript Benchmark“.

So I fired it up in the cxChromium port and then it the standard FF3 on Ubuntu. Here is what I saw for cxChromium. I then swing over with FF3 and get these results.   Javascript in FF3 is 2.44x slower than cxChromium.  Man oh Man, is the v8 javascript engine a hummer.

Using an auto-increment field is not the way to go.  It is viable when you only have 1 database but the datastore for your app is going to/can be replicated out to other machines.  This would mean that their exists times, when datastore’ != datastore” — over time datastore’ would be sync’d with datastore” so that datastore’ == datastore”   — this would lead one to believe that there will be times when the idea of an auto-increment field will not be synchronizable or that the result of the synchronization would be less than satisfactory.  My belief that auto-increment fields are the wrong idea in this environment is strengthened by the fact that they are not offered as an intrinsic datatype.

The way to go, in my opinion, is to use UUIDs. (see links below)
  http://docs.python.org/lib/module-uuid.html
  http://www.faqs.org/rfcs/rfc4122.html

Other Thoughts on the topic:

• data access is very expensive, using a UUID should be faster
• UUID1 or UUID4 would be the types to consider
• UUID1 is preferable as it would introduce some machine significance which should make the chances for a collision to be even more remote than for a UUID4 (random)

#!/usr/bin/env python
"""implement a greedy coin changer, returning the
fewest coins to make the change requested."""
#coin_list can be expanded to include silver dollars
# and 50 cent pieces by just expanding the coin list
# to [100,50,25,10,5,1] the reulting answer
#structure will modify itself to reflect 

coin_list = [25,10,5,1]
change_requested = .71
remaining = change_requested * 100
change_returned = []    #result structure

for coin in coin_list:
    num_coins,remaining =  divmod(remaining,coin)
    change_returned.append(int(num_coins))

print change_returned
print remaining

The benefits of this version, are no conditional logic is needed, the coin structure can be modified and the answer will modify itself accordingly.

I think it is a great opportunity on a smaller scale than anyone might imagine. Sure, this could serve as the platform for the next YouTube type social-2.x site, but what I think this really means, is that Google is rounding out the Google Apps for Domains by giving the ability to create something more than a brochure-ware style site offered by their current Sites for Google Apps.

Many are looking for Google to use this as an opportunity to expand advertising revenue, and that is certainly possible for widely popular webX.x sites but what they really needed is another tool/knife to hold to the competition’s throats. Looking at the tea leaves in the bottom of my glass, I see something more akin to a SharePoint attack; Going after the S in SMB market.

App Engine allows for authenticating users via Google system, how much longer until we can interact with other Google services in a similar fashion?? Calendaring, GTalk, etc — I’m not talking mashups, something much more refined.

Interesting things/thoughts happen when your programmers are sys-admins too.  This idea of translating the framework we use for testing code to testing systems has a number of interesting dimensions to it.  Just like Alton Brown, I insist that my tools multi-task too.

The gist of the article is that when developing APIs are never as complete as we want them when we are developing a new system and if you are using a static language you’ve got lots of ramifications to consider and code to rework when you have to expand an API.  However, dynamic languages have a real advantage here and they go on to give a very real example and how they dealt with it.

A project that I’m working on is going to require a plugin framework for a number of things: Logic, Data Storage, Reporting and I’ve been keeping my eyes open for papers/articles on plugin frameworks.  Do you know of any resources/articles?

Powered by ScribeFire.

There have been a bunch of announcements in the past couple of days about IronPython and SilverLight — will they beat firefox?
Personally, I’m giddy about the prospect of using Python instead of javascript.  John Udell’s blog entry tonight specifically mentions
that exact combination.
http://blog.jonudell.net/2007/05/01/watching-anders-hejlsberg-reinvent-the-relationship-between-programs-and-data/

Finally, things are starting to get exciting again.