In Re:

InRe: Jason Chen on why the netbook market is dead in three years | T3 magazine

Jason’s reasons for netbook’s demise, underpowered for Windows and underoutfitted for Windows, while true to a degree, are not going to be the reasons for any so called demise of the netbook market.  What he is really talking about is a failure of Windows, both XP and Vista.  Netbooks are not small laptops just as miniature golf is not golf in miniature.  They are a different class of device, bigger than a phone but smaller than a laptop.  Trying to run windows on a netbook is as frustrating as a phone with windows mobile.  Microsoft is becoming less relevant in the fastest growing market segment.

While I agree that what we now call netbooks (screen < 10 inches) may dissappear in three years it won’t be because of consumer apathy but because the device platform will become wildly popular and manufacturers will struggle to differentiate themselves.  Jason goes on to compare netbooks with tablet PCs but that analogy is false.  There have only been a handful of tablet PC platforms, where as the market is exploding with netbook devices.

His closing statement about price and weight is exactly what will sustain the market.  At a price of 1/3 to 1/4 of a full featured light weight laptop, more people can afford to have both a laptop and a netbook.  If they were to buy the MacBook Air or X360 they would have to live with the tradeoffs they bring.  A netbook/laptop combo comes in 1/4 less the cost.

An interesting thing happened on my way to the web today. While reading through my RSS feeds, I came across a story about CrossOver doing a Proof of Concept port of Chromium to CX. Interesting since the mighty “g” can’t seem to get it together for Linux. I’ve already downloaded and played with Chromium at work on my XP box and was impressed with the speed. It seemed much snappier than FF3.

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.

App Engine is a pretty dramatic thought departure for lots of programmers who are used to writing an app that runs on a single server and access a single database.  Case in point, there has been a recurring topic of auto-increment fields on the  App Engine list — people trying to implement their own version of it since it is not a native datastore type.

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)

Noah Gift over on O’Reilly OnLamp Blog has an article on building a greedy coin changer. That is, given a value, say 71 cents, calculate the fewest coins needed to make the amount. He had listed a number of solutions, but I felt I could do it a bit more pythonic.

#!/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.