A reader wrote me regarding a performance issue they were having with PostgreSQL, and I thought the case study would make an interesting follow-up note on the whole SQL/NoSQL debate.

The scenario was that they needed to look up batches of geo-locations by postal code, passing in sets of 100 postal codes and retrieving the corresponding set(s) of latitudes and longitudes.

It is a real-world scenario, whether for mail processing system, census analysis, sales tracking, or many other common data processing needs.

You could simulate such a scenario with data like this. I did just that with the Canada Postal Code data.

In the reader's situation they were finding that batches of 100 postal code lookups took over a second.

That’s suboptimal, and not ideal for any system that needs to perform a large number of rapid lookups.

It is not the sort of task that I would normally do in a database. Hard to believe, perhaps, after the prior entries, but this is a process that I consider highly specialized – a unique snowflake, if you will.

The data is extremely static, and the usage is very specialized. Performance, rather than generalization, is paramount.

To validate the performance assumption I built a simple .NET test app that populated a Dictionary<string, List<Location>> with all 765,344 Canadian postal codes (there are, in some cases, multiple entries for a single postal code, so each dictionary element contains a list that contains 1..n results), and then looked up random sets of 4000 postal codes (hint: Create randomly sorted recordsets in SQL Server by ordering the results by NewId()).

It could lookup results at a rate of some 3,000,000+ lookups per second, with no parallelization running on a single mid-range core. Adding parallelization (extremely easy in .NET 4.0 using Parallel.ForEach) was of limited benefit as the reduce stage and thread safety efforts ate up any savings for all but the most unrealistically large test set.

That was an ultra simple solution with very few lines of code, specialized for the purpose. It did consume some 140MB of memory, but memory is bountiful and cheap.

Doing the same lookups in SQL Server, with optimized fill factors and a perfectly covering index — even after priming the cache (by doing a full select of the covering index) — yielding a return rate of approximately 5000 lookups per second on the same hardware, per core. The generalized execution engine simply isn't optimized for such a trivial lookup usage, and imposes significant overhead that isn't beneficial in this case.

3,000,000 versus 5,000 (per core) = an incredible reason to use a specialized solution, especially given that it’s the long solved problem of KV pairs.

The reader, after some correspondence, mentioned that they had settled on Redis, which is a solution that is midway between the custom in-application hashing solution and a generalized SQL solution (leaning much further to the former than the latter). The performance with such a solution will almost certainly be incredibly high, albeit bound by the overhead of IPC. Redis is a highly optimized solution for that task, and is quickly proving itself to be a viable part of most solutions.

It is the right solution for that problem. In no way is it a “new world order of social media and intraconnected graphs realigning the stars to herald the new way of using data”, but instead is a very appropriate use of the right tool. Redis, like Memcache, has a lot of metrics on its side, much unlike many of the other NoSQL solutions.

Using the right tool is what we should all strive to do.

Android 2.2

Android 2.2 was announced at Google I/O just over a week ago. It is the highly anticipated update to the Android platform that brings a slew of very important improvements and refinements, including a reduced memory footprint, the addition of a JIT compiler to both the Dalvik Java-esque virtual machine and the V8 Javascript engine in the browser, push-messaging for any 2.2 or above targeting apps (with the reliable and powerful Google ecosystem to back it), streaming media, comprehensive ActiveSync support, among many other new features and functions.

Lots of refinements have taken place. It levels the ground with the iPhone, and provides some ammo against the soon-to-be-announced iPhone 4.

The Android platform is a very exciting place to be. Competition is excellent. Hopefully the iPhone 4 is a stunner as well.

A Terrible Roll Out

The (non-)roll-out of 2.2 could have been done better.

A pre-release of 2.2 got pushed to a subset of devices — those given to press or as handouts at Google I/O — shortly after I/O concluded, with no one seemingly knowing that it wasn’t the real deal, or that it was only going to a subset of devices.

The tech sites proclaimed that the roll out was underway. Purportedly there was a confirmation by a Google rep that the new version was being pushed.

Google had indicated, at the conclusion of I/O, that they planned on getting 2.2 out for the Nexus One in a “couple of weeks”, so this seemed like a case of setting expectations low and then wowing them. Everyone was eagerly checking their phones, suddenly convinced that it wasn’t worth using until Froyo was installed. Soon they could impress their friends with Linpack results.

But it wasn’t a real roll out. Nor was it the actual release version. Google didn’t seem to correct anyone until days later, after lots of people had downloaded and installed a covertly discovered pre-release version of it.

Android already suffers enough criticism for the purported need for “task management” (you don’t need to manage tasks! It is often simply a placebo), it doesn’t need people thinking that you need to root your phone, rollback to a prior version, and then roll forward, all to avoid being picked last for the team.

The pre-release clearly has some issues. There are observations about apps crashing, with commentators opining that those app devs need to “update their app for 2.2”, providing more misinformation to add to the talking points of Android detractors

Communicate better, Google. And stop treating the press (or even people sent to I/O by their employers) as your closest allies. They aren’t.

Android has succeeded despite sites like Gizmodo and Engadget and their brethren, a strong community and grassroots effort keeping it aloft in the face of a lot of effluence and misinformation.

This tarnished what should have been a stunning release of a stellar upgrade.

The Android Platform Today

It still is a bit rough for mainstream consumers. I own an HTC Dream, an HTC Magic+, and most recently added a Google (née HTC) Nexus One, and I love all three of them (and it is far and away the best platform for me and my needs), but there are still warts and issues.

Scrolling on the Nexus One, for instance, is often rough, like the device is over-extended. This includes scrolling down pages, between home screens, and so on. It seems like a trivial thing, and it doesn’t impede actual functionality at all, but it is one of those minor things that really favor the iPhone, where scrolling and transitions are brilliantly smooth.

The Sense UI added by HTC offers a much more iPhone-like smoothness, but the base OS shouldn’t falter on such powerful hardware (and Sense UI is why HTC lags behind the Google release cycle at such a distance).

If you add animations to interactions, they must be smooth or they become a detriment. I’d rather pages just instantly flipped rather than being poorly animated. Android does it well compared to devices that came before, but it’s the unparalleled smooth elegance of the iPhone that makes it pale in comparison.

The Android Market

The Android market is a mess. There are 50,000 apps, around 49,000 of them being horrendous make-money-fast junk apps (thousands of compasses, levels, and after a “success story” led to a gold rush, parked-car-finder apps).

The “Just In” section is simply depressing.

This is very similar to the Apple market, for those who might be gloating, where there are companies spamming the directory full of thousands of repackaged web pages and regurgitated filler. Apple might have strong opinions about what Adobe’s Flash-to-native compiler would do to quality, but they certainly have no qualms letting low quality junk saturate the app market.

Of the remaining 1,000 apps, many still have a pretty big “need work” sign hanging on them. As a contemporary example, Epicurious just pushed out an Android app to join their existing iPhone app, and while the iPhone app is lauded, the Android version is seriously deficient, almost to the point of being unusable.

Make it easier for us to separate the wheat from the chaff. The current rating system is broken, and seems to be primarily used by spammers trying to earn gems in garbage games.

Allow me to pick my own trusted rating authority to browse and sort the app market. This should be similar to looking at a movie listing and choosing whether you want to rate based upon Metacritic, IMDB, Rotten Tomatoes, Flixster, the community at large or just personally trusted reviewers and their network of trusts.

I don’t care what a million spammers have rated an app at, nor do I care to waste my time with apps that people whose opinion I value have given the thumbs-down.

The market is improving (the new system that will be coming after 2.2 is apparently going to be very similar to Xbox Live, where I can pick movies and games on their web interface from a desktop and they’ll instantly start pushing down to my powered on Xbox 360), but people need appropriate expectations going in.

It doesn’t matter how many apps there are in the Android market. Or the iPhone market, for that matter. It only matters how many satisfy your needs.

Taking on the Snaptic Challenge and Then Making it Personal

Snaptic launched an interesting challenge recently – the Move Your App! Developer Challenge – and it inspired me to get serious about Android development. More so than the cursory surface skimming I did previously.

It was mostly a nice external motivation and a bit of a deadline to get me taking the initial steps. Yet in the end I decided against submitting for the contest.

I didn’t submit for two reasons.

Firstly because I started two weeks before the contest started, and the odd evening or weekend just isn’t enough time to polish something in that amount of time. I don’t want to contribute to the pollution of the market.

Secondly because I couldn’t reasonably fulfill a basic requirement of the contest, which is that you have to integrate with their note/photo cloud service (the contest isn’t entirely selfless on their part). It didn’t lend itself to my app without seeming like a completely superficial tacked on requirement-filler.

I hugely applaud them for creating the contest, encouraging Android development and getting people to get on the move. Their prizes are incredibly generous and unique as well.

Alas, I’m going to keep on plugging away and will have a version 1.0 in the market in the coming weeks, and I will openly say that it was inspired by the Snaptic challenge.

Google and the Nexus One Channel “Failure”

A lot has been written about Google purportedly abandoning the Nexus One. In reality the market simply isn’t ready for unsubsidized phones, people much more willing to pay $199 for an iPhone, and then thousands in service fees, than to pay $500+ for an unsubsidized device.

It’s similar to bandwidth where people are more accepting of “unlimited” data plans, with onerous throttling and usage restrictions, vendors trying to game it to ensure that you use as little as possible, than to pay for actual consumption. It’s destructive for everyone, but it’s the Big Lie that we all live with.

It’s also true that Google is a terrible retailer.

When my Nexus One was ordered I quickly realized I should have joined two orders (the phone and the car dock) to pay a single shipping charge, but more importantly a single customs brokerage charge. Despite contacting them almost immediately I instantly got a stock reply saying that it couldn’t be done due to their ultra-expedient fulfillment process. The fulfillment wasn’t ultra-quick, and strangely I can make such changes to trivial, low-margin computer orders with no issues at all, but that’s the operation of Google where the earnings per employee is maximized, and saying no is easier (and cheaper) than being accommodating.

I also ordered an engraving (see below) on my phone and the phone came sans engraving. I filled out their support form to say “What happened with the engraving I asked for?” to instantly get an obviously mechanical Bayesian response that I needed to contact HTC for any order problems.

Google isn’t great at retailing directly to the public. I love the phone, but the experience was far from pleasant.

On Engraving One’s Phone

Several times prior I had almost completed an order but backed out once presented with the engraving options.

It seemed like something I should take advantage of.

But what to engrave? My name? My email address?

What if I transferred the phone to someone else once the next killer Android device came along? Surely they wouldn’t like having my name permanently engraved on a non-removable part of the phone.

What if I dropped the phone on a covert mission and wanted deniability?

At the same time I’d like for someone to be able to contact me if they find the phone, and maybe edge someone who is on the fence about whether to keep the found goods to doing the right thing.

So I went and registered a domain – mylost.mobi – and set my engraving to be yyz@mylost.mobi.

I “think bigger” in almost all that I do, and the idea was that such a site would offer a control panel and the ability to transfer the forwarding address, so if I transferred the phone I would simply transfer the email address.

Alas, my phone didn’t come engraved so I didn’t bother building it out. Neat idea, I think.

Videos showing young children using the iPad have been making the rounds, cited as proof of the intuitive nature of the product. They’ve been referenced in articles with titles like “Apple iPad easy enough for a child to use”.

Similar videos made the rounds for kids and the iPhone, kids and the iPod, all the ways back to kids and the original Mac.

If you want to show that something is easy to use, the thinking goes, record a child exploring it and post the results on YouTube.

It’s entirely backwards.

Children Are Uninhibited Explorers

Kids engage in active, uninhibited exploration to discover the functionality of a system, often through trial and error. They do this without self-doubt, prejudice or assumption.

Deviations from behaviours and interfaces that they already know don’t make them doubt their intelligence, or make them feel angry that their existing knowledge is obsolete.

While parents love to show off their children doing clever things, bragging about the superior essence of their DNA or parenting, the reality is that most children are shockingly clever.

I have three young children. They’ve had computers since each was a toddler. They have often seen me using computers. They watch each other using computers.

My youngest has, since well before his second birthday, gone to the office, turned on his computer, and logged into his account.

He launches Firefox and decides which site amongst his bookmarks that he wants to visit. There he explores the site-specific UI, picks the activity he wants to play, and masters its nuances.

There is little consistency among the sites or individual games, and they frequently change it up and add and remove content, yet that never discourages him or throws him off, but instead offers more opportunity for exploration. It plays a part in the enjoyment.

When he gets bored he goes to the next game or site.

If I’m at the office and I see him appear online through Skype, I can make a call to him and he’ll answer. He often exclaims “DADDY!”, then abruptly (how rude!) hanging up to get back to his game.

He figured out most of this on his own. There was no computer training course or bootcamp learning series.

The same technology aptitude certainly holds true for my other two. My daughter was beta testing a page when she was two. She had no problem quickly discovering how the elements interacted.

My children play videos from the network-attached storage. They take pictures of themselves with superimposed hats using the webcam. They scan their drawings for digital enhancements.

A year back I discovered my middle son, then a preschooler, on YouTube doing searches for Star Wars videos. I was sitting behind him on another PC and got curious when he asked how to spell Darth Vader.

Now that I’m onto my third Android phone – having gone through the HTC Dream, to the HTC Magic+, now onto the Nexus One, all over the course of less than six months – the Dream has been relegated as a portable media and internet access device for them, and again they figured out how to do almost everything it is capable of doing on their own, even on stodgy old Android 1.5.

Taking pictures, playing videos, navigating the market and installing and running applications (no pay account is associated, so thankfully they aren’t running up charges).

And it isn’t even an Apple product.

Children are brilliant. Of course I think my kids are especially awesome (as every parent does about their own sprogs), but most kids are capable of these feats if given the freedom to explore with the confidence that there are few negative ramifications of their actions.

Adults Are Dumb In Comparison

Adults, in contrast, usually approach anything new with self-doubt, biases, and prejudices. They have preconceived notions of how something should behave, and deviations from that leads them to grow angry and irritated that the subject is, essentially, making them feel stupid, while making their previously acquired knowledge obsolete.

If Facebook moves a button, there is mass outrage.

Linux desktops are generally considered deficient unless they closely mirror the behaviour of the Windows desktop that people are accustomed to. Individualizing, even where it is demonstrably superior, is almost always a negative return activity.

Just copy what people are accustomed to. Most adults actively avoid learning anything new, so the less “new” the better, generally.

Humanity suffered a decade of jokes about programming the VCR.

We’re seeing the same behaviour now in the smartphone ecosystem where Apple is held as the benchmark, and the way things should be done. While many bemoan everyone “copying” Apple, they need to keep in mind this people-are-dumb effect.

Of course this leads to a chicken-egg debate: how does Apple get away with doing things “Different”? How do they manage to get away with, and be heralded for, creating entirely new and different experiences? How do they manage to “make” markets?

Apple Treats Users like Children

Many users approach Apple devices as if they are children, just as the products are delivered as if to Children.

Watch Steve Jobs unveiling the iPad and seriously question whether that sort of presentation would have been tolerable from, say, Steve Ballmer or Eric Schmidt.

Listen as he soothingly delivers the goods like he’s a children’s author giving a reading from “Why Goombas Go Bananas”.

While that sounds like a negative statement about Apple, it is actually incredibly positive.

Given that there is a widespread expectation that there is a reward that will come from acclimation – they have been told that Steve Jobs has the Midas touch and Apple designers are the world’s best – people often approach Apple products with a wonderful child-like open-mindedness, willing to accept differences. There is knowledge that it will be a rewarding experience.

The same thing happened with the Nintendo Wii: Given positive press and a friendly impression of the company, many had an unexpectedly child-like response to it, and were willing to give it a chance.

This is seldom the case. Whether it’s a simple change of a web page, the use of the Ribbon bar in Office, a switch to Firefox – people have a strong gravity to things that they already know, and a powerful aversion to change.

It takes a lot of hype to overcome that friction.

Whether Apple products are really as intuitive and brilliant as claimed is debateable, but the belief that they are is enough to get them over that hump, yielding the same benefits.

On Acting like a Child and Letting a Child (or Adult) Act like a Child

One important note about children (or adults acting like a child) and exploration: To work there has to be an environment where there are few negatives to simple actions.

In the case above my kids use PCs running Windows 7 and limited user accounts, coupled with reasonable (but not overbearing) supervision, so there is little to no damage they could cause with a mouse and a keyboard.

Worst case I’d just wipe and reinstall.

They can’t accidentally order things on a credit card. They can’t install root kits. They can’t delete system files.

Having that freedom to try things risk free is critical to exploration.

It’s just important for adults who are learning a system, and perhaps a part of how we got to where we are was an ecosystem where simple exploration could be a destructive, damaging experience. Where an accidental keystroke launches a complete changed interface, for instance, with no obvious way to get back.

It destroys the user’s sense of adventure, probably forever.

“Fragmentation? What Fragmentation?”

The Android Developer’s Blog ignited a firestorm recently by publishing an entry on the purported fragmentation of the Android ecosystem.

It’s worth a read. Too bad the same can’t be said to most of the responses to it.

When the topic concerns either Android or the iPhone, and the arguable failings of each platform, it’s seldom debated by people genuinely interested in seeing the target of their criticisms improve in any meaningful way. Instead it’s pundits (less generously called fanboys) hoisting their flag, pushing in for their chance to line drive some talking points.

Rabble rabble rabble, Steve Jobs will eat your firstborn

Rabble rabble rabble, Android is fragmented and anarchist.

It is noise that seldom inspires or enlightens.

On Android Fragmentation

We have a problem, Mountain View.

Some handset vendors are lagging on upgrading their devices, if they do at all. There is a wide disparity in performance and functionality among devices, leading to unpredictable user experiences.

It parallels the dark days of Windows Mobile, when unloved devices were shat onto the market and promptly forgotten, the vendors more interested in prepping you for the next iteration that, they assure you, will fix all of the problems of the last.

For those writing application targeting Android, such as myself, there is a need to carefully consider the current version breakdown, choosing the target that offers the minimum functionality you need without restricting your market too much. You need to perform the same analysis on the target hardware capabilities, as the simple reality is that a rich graphical 3D application won’t run acceptably on a wide range of deployed Android devices. A high-end game might run well on a Samsung Galaxy S, for instance, while being unusable on every other Android device.

Do you target 2.1 and take advantage of Quick Contacts, for instance, and limit yourself to 45% of the potential customer base, maybe preparing yourself for the future? Or do you target 1.6 and simply go without those refinements? Do you build a 3D rendering interface that will choke on all but the latest handset, or do you cater to the lower common denominator?

It’s a serious concern. There are brand new Android devices that are hitting shelves today with Android 1.5 on them. There are new devices with mediocre processors, limited memory, and barely functional GPUs.

Isn’t that weird? It isn’t optimal.

Add that there are all of the various skins that the vendors put on their devices to differentiate: HTC’s SenseUI, Motorola’s MotoBlur, Sony’s Rachael, among others.

Android devices come in all sizes and capabilities: There are big screens and little screens; devices with keyboards and those without; cutting-edge super phones and feature phones on steroids; tablets and netbooks; processors with NEON instruction sets and without; with SSE or without.

An Android device is not a homogenous experience for either users or developers.

Crazy isn’t it? Anarchy reigns! Contrast this to the land of iPhone where there is a very strong uniformity and development consistency among experiences and development and devices.

Shouldn’t Android be more like the iPhone? Shouldn’t Google lay the hammer down and demand that vendors refrain from customizing, they upgrade in lockstep, they build a consistent, uniform platform, and nothing deviates from the reference implementation? Everyone building a Nexus One with a vendor label on it?

No way.

Fragmentation is the Reason the Android Platform Has Succeeded

The progress of Android over the past year, or even just the past 6 months, has been nothing short of extraordinary.

From being a marginal wannabe, largely adopted by those ideological few willing to turn a blind eye to its many, many faults, Android is now a very serious competitor among mainstream consumers.

It’s an accomplishment that Google could never have pulled off alone. They needed a lot of help from a lot of very capable partners, and their strategy with the Android platform and the Open Handset Alliance is entirely the reason we got to where we are today.

HTC, Motorola, LG, Samsung, Sony, nVidia, Intel, ARM, among a slew of others…a lot of very smart, very capable companies working to make their own success story, pulling up the Android platform at the same time.

Motorola wants to sell you a Droid, yet by investing so much into making their devices a success they’ve build an ecosystem where you benefit from their success even if you choose another vendor’s phone.

Fragmentation is progress.

Instead of releasing a single iteration yearly, a single lockstep uniform device and experience, a Darwinist battle is taking place, the best choices and experiences triumphing. The Evo 4G is hitting shelves today, yet already we’re hearing about the next superstar, a purported HTC Scorpion device with a 1.5Ghz processor coming soon.

When people argue that Android should be more like the iPhone, they lose sight of this very beneficial side effect of the so-called fragmentation.

If Google ran the Android platform like Apple, it would have been a Buzzesque flop. It would have failed miserably.

But they didn’t, and it wasn’t. We are where we are.

So where are we?

Well firstly, most of what you’ve read about Android fragmentation is bunk. Horror stories about incompatible apps and terrifying development processes are largely exaggerated.

But there are some issues.

Google Earth, Google Goggles and the official Android Twitter application (an excellent application that was built with Google’s help) all require Android 2.1 or above. It’s fairly obvious that Google intentionally limits the best to a recent version in efforts to motivate vendors to hasten their upgrades, and to showcase the most recent platform additions, such as the animated backgrounds in the Twitter applications.

Those are the reason that customers demand that vendors update their phone, and it helps keep them motivated to push out upgrades. Motorola just released the Backflip on 1.5, and Sony released the X10 on 1.6. Both of them have gotten a lot of criticisms in reviews for this choice, and they both will pay for lagging behind. Their motivation to get upgrades to the market quickly is very strong.

As a developer, when you develop an application you need to target a given version knowing that you’re cutting out anyone running something older (thus cutting out some prospective customers). In a subset of cases you can target an old version and optionally target newer features using runtime reflection and feature sniffing.

And there are compatibility quirks. In developing an app that integrates the camera I’ve encountered a number of issues, including devices that invert the preview output, some that only return greatly scaled down pictures when a picture is taken, among a variety of other little variations and surprises, and that’s just among the devices I’ve tested with.

There are known issues when dealing with OpenGL where some devices demand a certain magic quadrant of environment conditions to operate at their peak.

All in all, though, it is an absolute walk in the park compared to most other development efforts I have pursued. The Android SDK abstracts most everything to a shockingly effective degree, and the very clever, HTML-like (and thus XAML-like) layout manager allows you to very effectively run your application on a huge variety of displays.

You can build high-performance code in the NDK, including hand-crafted ARM assembly, but you can do it in a way that will only optionally be used if the right conditions are available (e.g. an ARM processor with NEON instructions), otherwise falling backed to a managed version.

In many ways writing to Android is a bit like writing an HTML5 application. There are quirks that you have to deal with on some clients, but they’re mostly known and documented and fade away as the clients move closer to the specification, without restricting the innovation and uniqueness of the individual clients.

Everything about Android is built to abstract from the device, from the virtual machine runtime to the density-independent pixels to the layout manager’s multi-dot-pitch resource utilization (I would have preferred that they used vector graphics, such as SVG, but it’s better than nothing).

If Android is HTML5, then the iPhone is ActiveX

When you develop for the iPhone, you develop for the iPhone. With the iPad there’s one additional form factor, but the universe of clients is extremely limited and of little variance. With the new iPhone there are rumors that it will see a simple doubling of each axis’ pixel count, allowing the system to simply pixel double previous applications.

It’s a bit like developing for Internet Explorer back in the early 90s: Everything was grand and entirely consistent and uniform, and in many cases you could just target an ActiveX control because you could make so many assumptions about your target.

There is limited variability build into the iPhone SDK or development process, and those hurdles are crossed when they are encountered. When the iPad came out, they updated the SDK to deal with the second screen size. The new iPhone SDK added the ability to deal with the new pixel density.

It makes a developer’s life simple. But it also seriously hobbles the rate of innovation and the ability to adapt to change.

It’s a Long Term Strategy

In the short run the single-target approach – the ActiveX approach – wins. In the longer run those early gains disappear, especially when you’re moving uniformly (“non-fragmented”) against many speedy opponents.

Just take a gander at the comments on any Android market share story. Just a few months ago it was gloating damnation as the iPhone ecosystem dominated the Android platform. Now it has subtly shifted, and the argument has moved from "iPhone dominates!" to “You can’t compare the many Android makers against just Apple! Apple still beats HTC!” It’s quite a shocking adaptation, and of dubious merit: As a developer I completely care about the platform saturation, not whether a phone is a Motorola or an LG.

And of course Apple does as well. There are millions of iTouch and iPad devices that don’t get counted in smartphone surveys, and they give iPhone targeting developers a staggering lead still, but we’ll see for how long.

The latest Mac Mini is a slick little device. What really makes it stand apart – in the world of PCs, where it’s a very competent entrant – is the shocking power efficiency of the device.

Viewing a static web page, one reviewer found the device used a miniscule 6W of power.

The PC that I’m typing this entry on – a very typical example of ordinary PCs – is wasting some 40W of power in power supply inefficiency alone at idle. Yet the Mac Mini is managing to provide a good computing experience with 1/6^th that, under a load using 1/6^th the power a typical PC consumes under a load.

Amazing.

The Mac Mini isn’t the first to move us in the right environmental direction, after years of escalating power demands (just look at the power consumption of current generation consoles to see how gluttonous devices have become. Watching a movie on an Xbox 360 could literally cost you $0.20 in electricity alone, not to mention the environmental impact).

The more powerful my smartphones have become, for instance, the more often my PCs are frozen in S3 Sleep. The effect is amplified as people move to very low power devices like the iPad, doing many of the tasks that they would have powered up the home PC for (or worse, kept it running around the clock to have it available) instead on that ultra-low power device.

The impact is measurable. The financial impact is significant (leaving a PC on around the clock costs some $20 a month). The environmental impact – or reduced impact – is invaluable.

While a number of beta releases of Android 2.2 (AKA Froyo) have made the rounds since the Google I/O public unveiling over a month ago, all of the prior releases targeted the T-Mobile variants, leaving my EPE54b-based "AT&T" model on the outside longingly looking in.

Sure, there are methods of rooting and rolling back and then forward to get it working, but I wasn't interested in them simply because this phone is too useful for me to bother: It is already a very decent phone, and I was willing to bide my time until Google refined the final bits and pushed it officially, at least when the alternative started with rooting.

Alas, a version has finally been unviled for my version of Android. I downloaded it, did the manual update, and initial impressions are incredibly positive.

I've complained numerous times before about the stuttering, seemingly overwhelmed feel of the platform, at least relative to the buttery smoothness of an iPhone, and I can happily say that most of those complaints are no longer true.

One possible facet of the Froyo update that has been debated back and forth as myth has been support for 802.11n. I can gladly say that FRF85b does indeed enable 802.11n on my handset.

Taken after switching the WAP to 802.11n only, though it establishes the same connection in mixed g/n. Yes, I named my WAP "dlink", even though it isn't a dlink.

While much has been made about 802.11n's higher theoretical speed, how often is greater than 54Mbps really needed on a smartphone? Is the max 54Mbps of 802.11g just too constrained?

Hardly. The increased max theoretical throughput is a non-issue for this usage.

Instead the real benefit of 802.11n is that it maintains a decent throughput at the edges of the connection, where 802.11g would stutter and disconnect. I can already say that testing this throughout the house and the yard has demonstrated a more consistent, more usable experience. With the WAP in the basement, connectivity in the bedroom was often more hit and miss, whereas now it appears to be rock solid and ever so speedy.

No, not really.

What a thoroughly boring discussion that has distracted the entire tech industry. So many incredible innovations happening, yet everyone's talking this minor bit of errata. Move on!

It is further evidence that smartphones dominate the technology discussion now, with desktop technology fading into the noise. Intel is quickly preparing their very competent assault on the field with the Moorestown processor. It promises some exciting times ahead.

Backtracking on 802.11n with the N1

On the topics of product issues, in a prior entry I noted that I had been enjoying the fruits of 802.11n with the Froyo update on the Nexus One. Shortly after that entry, another update was pushed, FRF91, and my connectivity has become almost unusable unless I disable 802.11n on my wireless router (which was actually the case when I first got the phone, but FRF85 had provided salvation). So now I run two WAPs, with one to serve the 802.11n devices so I needn't cripple it for the N1, and a 802.11g one just to service the smartphone.

On High Density Smartphone Screens

With all of the talk about very high pixel density phones, and the downside of larger-screen phones, the focus of most discussions seems to be purely on the visual clarity of the screen. The actual usability of the on-screen content seems to be ignored.

On the Nexus One I'm dealing with a 252dpi (there is some fakery with the pentile pixel arrangement, but ignoring that), 3.7" screen. A site like the New York Times looks fantastic in landscape mode, with a fully readable presentation of the entire real-web contents. Yet the downside of that high-density, small screen becomes evident when I actually want to interact with the content on the screen. Something as simple as clicking on the category links down the left hand side is an exercise of extreme precision: Each link is approximately the size of a single fingerprint ridge, and they're so densely packed that a mm this way or that way yields the annoyance of a wrongly followed link. Zooming and unzooming just to interact with the screen isn't very enjoyable, and it erases many of the advantages of the pixel density.

Screensize is important, and smaller isn't better when you're talking about a device that doubles as a mini-web appliance. There is a balance to be achieved or the experience is compromised.