No, CherryPal Will Not be the First (or any) Mass-Market Cloud Computer

Notwithstanding this predictable VentureBeat article about a thin-client device with a somewhat anatomically suggestive logo.

I've previously written about why thin-client is a not-now and not-soon solution.

The $249 "CherryPal" box reminded me of another twist on the problem ... one that comes into play when the thin client isn't just software (like Skyfire's screen-scraping browser) but a new hardware device.

See, here's the thing about building your own new hardware in smallish quantities: it's really expensive on a per-unit basis. Or, another way, you can't offer a fraction of the capability per dollar that a Dell or Sony can. Your $249 thingamabob is going up against other $249 devices that have way more stuff (e.g., entire laptops) because they are produced in high-volume orders of established designs/modules/parts.

To be more precise, there is a spreadsheet you can put together that maps your bill of materials, plus any special physical design issues into a cost per fabricated unit. It includes multipliers that will make you sad, like your $2 can't-live-without-it chip might end up adding $20 to the finished product cost... depending on where it fits in, affects other parts, quantities, and other stuff.

It's tempting though, especially since the last 5-10 years have brought the ability to fabricate in China for lower cost and in much smaller quantities than would have been practical before. (Of course the costs aren't really lower, they're just externalized into a bunch of other areas ... but those are politics/economics/policy areas more than tech, so I'll leave them be for now.)

So, whereas before you might have needed to sell 700,000 units to break even on something, now 20,000 units will do it: increased temptation.

But if you're CherryPal, you still need to convince someone that a $249 thin-client is more useful than a $299 laptop with 10x the horsepower, a screen, storage, and all the rest.

Free Idea: AJAX Desktop Publishing App

If you're hankering to join the web startup circus and have everything but an idea, here's one for you: a full-on desktop publishing app ... online. The ready acquisition market for decent online productivity apps can serve as inspiration, even as the insane complexity of the undertaking urges you on toward greater heights of caffeination and maybe some anti-depressants.

Seriously, apps that can deal with complex page layouts and can produce a variety of press-ready output (InDesign, QuarkXPress) are expensive and hard to learn, and the average person rarely needs them. It would be nice to be able to hop on a web page and do a quick design. Wizards or integrated help could go a long way. All the usual business models (adds, freemium, pay-per-storage, etc.) apply.

Now, if you build this in Flash/Flex or in Silverlight (2.0), you merely have a ton of work ahead of you. While challenging, you may feel like you're not ... well ... proving just how wicked you really are, since those two platforms give you all of the technical infrastructure you need.

So why not go all the way? Do it in JavaScript, in the browser. Yep, WYSIWYG, arbitrary page sizes and layouts, in the browser. Advanced typography too. Fun times.

Here's a hint: one of the tricky bits is measuring text line layouts, since you'll need to make sure that the view matches the backing data (from which you will be generating other "views" or output formats).

JavaScript (the browser APIs really) don't give you everything you'd like. For example, one standard thing you need is to find out how many characters will lay out into a column of a particular width. Or simply what size a run of text will turn out to be.

While you can't ask these things directly, the clientHeight DOM element property can be useful: it shows the actual height that a DIV's content will lay out at ... so it will also signal when content has flowed from one line into a second line. By hiding the DIV, rigging up a while loop, and monkeying with the content (string), you can build a routine that measures text, so that you know exactly which characters are going to appear on a line.

Completing the application is left as a (possibly lucrative) exercise for the reader.

Packaging Outlook Scripts in Word Documents

Microsoft Office includes (unless you exclude it at install time) a flavor of ye olde Visual Basic (i.e. VB-COM not VB.Net) that is designed to facilitate Office automation.

If you're willing to put up with the VB syntax and conventions, you can put together mini-programs (including GUIs, menu options, toolbar buttons, etc. if you like) in even less time than it would take to boot up Visual Studio and run the Office add-in wizard or add some Office .Net assembly references.

Interestingly, distributing the resultant "macros" can be tricky... especially for Outlook. There are all sorts of suggestions depending on how widely you want to deploy your script, and how many "Are you really really sure you want to run this script?" dialogs you expect your end users to click through. Some of the approaches are quite hokey... for example copying over a client script file that will delete any other macros your user has. Eeesh.

It's possible that .vbs files and Windows Scripting Host are actually the "right" answer ... but here's another I used:

1. Write and debug your Outlook scripts in Outlook using the built-in VBS IDE.
2. Copy the bits you need into the dev environment in Word (this assumes your user has Word, and I'm guessing if they run Outlook they probably run Word as well).
3. Save the word document as a word-doc-with-executable-content (*.docm). Even if you haven't defined any GUI elements, any quick and dirty VB procedures you've written will show up as macros in the View->Macro dialog.
4. Bonus: write any instructions you'd like to pass along right in the word doc.
5. Give the file to your users.
6. COM-based scripting is COM-based scripting, so even though a user runs the macro in a Word doc, it can find and manipulate their Outlook items.

Not to worry, Word (and Outlook) prompt the heck out of the users when they open and try to run the code. And saying yes to your file will not require the user to grant access to any other script-bearing files.

It's not the slickest procedure in the world, but it's wicked fast and it serves the basic scripting purpose: Here's a doc with a script I wrote to convert Outlook notes into a single Task item for syncing with my Windows Mobile notes app.

Pardon the Glare: I Think My Tinfoil Hat is Catching the Sun

Last week, it became clear that Kevin Martin and the FCC are getting closer to laying the smackdown on Comcast for the ISP's BitTorrent "management" policies (or was it because Comcast keeps lying about it? or because Comcast has tried to game the hearings about it? so hard to keep track of now).

And now all of a sudden I'm getting 4x more BitTorrent throughput on my Comcast cable line than I ever did before.

I'm tempted to imagine a connection.

But I also suspect that positing a connection is tinfoilhattery on my part ... in particular because the bandwidth/connection patterns I see don't look like the TCP reset packet approach that Comcast had been using, and which gave them away.

I'm getting more throughput in the middle of transfers, where there had never been any resets.

So maybe I should just be happy.

Or maybe that's just how Comcast wants me to feel.

On the Other Hand...

Yesterday I wrote about the potential of the iPhone to break the longstanding wireless app logjam in the U.S.

Today the Free Software Foundation blogs about the other logjam we might be getting into with the device, namely that the app development and publishing community is just as locked down and controlled as the DRM on iTunes tracks. Wait, actually the app side is even more locked down (since there's a low-tech path to extract songs by way of audio CDs, whereas the app infrastructure requires jailbreak).

I'm curious whether this passage from the FSF post will have the fanboys plugging their ears and whining "I can't hear you" or just shrugging their shoulders and saying "who cares":

"Apple, through its marketing and visual design techniques, is manufacturing an illusion that merely buying an Apple makes you part of an alternative community. But the technology they use is explicitly chosen to divide people into separate digital cells, and to position Apple as sole warden. When your business depends on people paying for the privilege of being locked up, the prison better look and feel luxurious, and the bars better not be too visible."

If not a prison, it's still a walled garden. Like Verizon's mobile app vending machine (odd are you've never even hard of that one) or the old America Online. Maybe it can work, but there are better alternatives.

iPhone App Store: Let's Hope It's Not All Fun and Games

The iPhone phenomenon seems to be a kind of Rorschach test, where you can find whatever you're looking for ...

There are all sorts of posts on data from the App store, looking at, for example, pricepoints in the app catalog, or the kinds of apps available.

These data are far from perfect (though worth a look), and in any case I hope that VentureBeat's post on the prevalence of Game and Entertainment apps turns out to be wrong.

Why? Mobile apps and mobile net usage have been waiting to "break out" in the U.S. for nearly 10 years. It's tempting to agree with the sentiment that mobile net use is reaching critical mass thanks to iPhone, but everyone in the industry has made that mistake many times before.

Successful off-deck software on phones in the U.S. has been more or less limited to games. So when I read the headline "Fun! Nearly half of all the iPhone App Store apps are games or entertainment," all I could think was "let's hope that it doesn't stay that way!"

I have no problem with Super Monkey Ball per se. It's just that if all the top app activity is in games and entertainment, then the mass psychology around the iPhone / App Store ecosystem is in danger of slipping irretrievably in the direction of "diversion" and not the enormous opportunity it really is.

Before you say I should just chill out about the Monkey Ball, consider:

Blackberry, because of its email device pedigree, was pigeonholed as a "corporate email/organizer device" years ago, even though it could do many other things. Despite RIM's attempt to sex up the brand, boost the hardware, cut prices and improve the design, it looks now like the window is closing for RIM to make any big gains. The enormous deployed base of Blackberries never translated into a general platform for mobile net-based computing.

At the moment, all of the top 10 -- and 18 of the top 20 -- paid App Store apps (over the last 24 hours) are Game/Entertainment apps. So right now, when the frenzy is at a peak, with mass media coverage of sold-out stores and consumers showing acquaintances their hot new gadget, the eyeballs are on the Super Monkey Balls.

To a lot of people, who have never seen a 3rd-party app on a phone, and who don't totally get what this is all about, the demonstration is going to look more like a Nintendo DS than a handheld computer.

Which raises a possibility: perhaps Apple was wise to restrict iPhone 1.0 to Safari-based apps, thus forcing consumers to view the device as a mini-web-tablet, rather than as a portable entertainment device.

Refactoring: Bittersweet if it Could Easily Have Been Avoided

I've been doing some refactoring on a decent sized app lately. Since there are lots of other people doing stuff and the app is close to a supported 1.0 release, it's like working on the engine of a car while it's cruising down the freeway. Not just tightening the cap on the coolant reservoir, more like converting the engine to run on hemp seed oil and corn cobs instead of gasoline.

On one hand, it's fun: mundane tasks that might feel academic become a lot more interesting when the task is part of the Rubik's cube of after-the-fact architectural change.

On the other hand, a lot of the refactor is an attempt to deal with unnecessary complexity in less complex way. The underlying complexity -- not mediocre code or an initial pass at red-green development -- is really the enemy.

And here's the rub: this app has some network protocol requirements that are (1) outrageously baroque; (2) opaque and undocumented; and (3) completely unnecessary for the app to function for its users.

As a result, it's already eaten over 120 man-months (and a staggering amount of money, let's just say over 8x what you're probably thinking the labor cost was).

At least 2/3 of that time and money (maybe 75%) went to nothing the user will ever see or care about, and nothing that offers any inherent business value or competitive advantage for the owner. That 2/3 is all expended in dealing with the bizarro protocol requirements ... and the issues and complexity it spawns: the design compromises, the testing, the bug analysis and remediation, the refactoring. I'm not even counting the actual delays and feature cuts in this cost.

Where did I get the 2/3 number? Well, the project was initially scoped without this network protocol issue. The estimates were written down. And, in the initial iteration -- about 30 man-months of work over 5 calendar months -- we tracked resource usage and found that core functionality and QA was reliably 1/3 and closely matched the estimates, while accommodating these "other" issues was 2/3. Week in, week out. No surprises. Things haven't changed since.

It's ironic because this pattern is something that often comes up when developing against a true legacy system -- the formats, protocols, and systems in place simply cannot be changed right away for the convenience (or productivity) of a new team. And yet this initiative was green-field, not legacy. It could have used any protocol in the world. There was 0 (zero) install base that needed compatibility with this particular system.

I almost wish I didn't know this information ... It's the one thing that puts a real damper on the refactoring fun: knowing that with even a tiny bit of management planning and the willingness to deal with team issues, it would be unnecessary.

Yet Another Microblogging App ... With a Twist

Fun as it is to argue about whether the latest Twitter outage will be the death of it, or whether identi.ca has legs, there's a whole other world of RSS/Microblogging possibilities that hasn't been exploited. Unfortunately, as I'll describe in a bit, there's a reason for that ... and an implicit call to action to fix it.

Microblogging -- or, really, the feed-oriented delivery mechanism -- could be huge for all kinds of private-domain problems that are stuck in Web 1.0 mode of e-mail updates and web-page dashboards.

Whether it's a group trip; a job search (that my good friends but not my coworkers know about); the latest status on project, issue, or change request; whether my cat is in or out (neighbor cats beware!); what my son is up to; a surprise party ... and on and on ... there are microblogging feeds I'd like to publish and consume, that are not public. They are not 1-1 either. They are published to a group. I trust members of that group, and they can bring in others. Perhaps many people can update or write to the feed as well.

Seems awfully useful in personal and professional contexts. But there's no app that exactly does this right now. The closest things are Tumblr's "groups" -- which are cool, but don't offer feeds -- and FriendFeed's "rooms" -- which are also cool, but don't offer authenticated feeds.

So I hacked together an app during a few spare hours one weekend to do what I wanted.

You can try it if you like at http://www.statusmonster.com or its real location, http://stat.heroku.com (have I mentioned how totally freaking awesome heroku is? well, that's a post for another day, but take me word for it, they are ninja rockstars those guys).

This app makes it super easy to create a multitude of private RSS (atom, really) status feeds, and share them with people. It has a mini-dashboard to watch the latest on a bunch of feeds. But I'm thinking folks don't need Yet Another Web Page to visit all the time. They need authenticated feeds, which statusmonster offers.

Wow, I'm gonna get rich and famous.

No, I'm not.

Here's the problem:

If a feed is not authenticated (like the basic feeds from statusmonster, or the "room" feeds at FriendFeed) then midstream aggregators like Bloglines or NewsGator may index these feeds for search, and/or offer them to others for subscription. This is the essential difference between syndication and publication -- a.k.a. the answer to, "Hey, how is a blog different from a homepage?" This is great for my blog, but really bad for my candid job search notes.

Ok, so we'll offer authenticated feeds. According the Bloglines FAQ, for example, authenticated feeds are not indexed for search or exposed to other users.

I did that, and started trying it out with NewsGator's desktop and mobile products, Outlook's RSS reader, Bloglines, Google Reader, etc.

The power of feeds lies in the fact that the end user gets to decide how to consume and/or process the content. That is, to get the full power/potential of feeds, they need to work with pretty much every major reader/aggregator service.

And that's where the trouble starts. Reading authenticated feeds with readers is a completely hit-and-miss affair.

The best behavior I found actually came from Outlook 2007, which not surprisingly treats the feed almost as an email account. It takes your credentials one time, and then when it polls -- or when you click "send/receive" -- it supplies them behind the scenes and updates the view of read/unread items. Pretty much exactly what you want.

But it was all downhill from there.

Bloglines processed my authenticated feed, but seemed to take forever to reflect updates (much longer than other feeds), and it eventually lost sync with the backing feed. The feed still exists, same location, same credentials, but eventually Bloglines started showing its little "[!]" marker meaning "problem with feed" and never updated again.

NewsGator kind of half worked. Google reader doesn't do authenticated feeds. And so on down the line.

So doing all this cool stuff on the existing infrastructure is not gonna happen. Big bummer because I'm convinced there's major value in these use cases, so we need to figure out how to make them a reality in a way people can actually use (and will want to use).

What are the constraints?

We don't need super end-to-end crypto any more than email does. Most folks do their email in the clear, figuring the content is not top secret, but also assuming that their employer/ISP/email provider is not gonna go and publish the email in a Google-able way.

I think that's the standard we're aiming for -- basically a better way to do stuff that nowadays might be handled by a whole lot of one-to-many emails.

A set of standards around handling authenticated feeds might be all we need. But how to enforce that, since anyone can cook up their own aggregator and ignore the standards?

Force the user agent (browser or client app) to supply some kind of secret to decode the feed? Maybe, but this is only strong in proportion to the strength of the key material, and having lots of high-entropy key material per feed makes this cumbersome and hard to use.

Something about confidential and syndication don't really mix. But we don't need another walled garden email/messaging system, and we don't need more web pages to visit (like Tumblr's groups).

I'm working on it. Meantime, what do you think?

When Corner Cases Attack

Notwithstanding the credit given to MTV's Real World, I think reality TV took off with that Fox special that featured a deer knocking a hunter on his rear. That guy just never saw it coming.

Same thing seems to happen too often when we start making architectural adjustments around a corner case in a software application.

The real problem is how to tell when an exception to the initial model -- the corner case or edge case -- is truly a strange bird, versus when it is a big piece of the model that was missed the last time through.

Sounds like something that should be easy to resolve with proper analysis, whether of the thick-stack-of-paper variety, OO variety, or an agile story-based style.

But it's not.

I've recently been doing some work on a project where this mistake was made. At some point in the past, this team looked at an odd duck, thought hard, and realized it was a big piece of their world. Big enough that the underlying infrastructure -- database, network services, etc. -- should be designed with sufficient generality that this corner case would become a mainstream case.

I understand how the analysis went, and why it made sense.

Only problem is, with 20/20 hindsight we can now see it was wrong. Bringing this edge case into the tent made the system an order of magnitude more complex, and it should have been left as an odd hack in a dozen places ... but as development happened over time, on several different module teams, the problem of the added complexity wasn't clear until it was too late.

To be a little more specific, I'll offer an analogy: you're writing a driving game or simulation. A big part of the fun is the spots where the players catch air, jumping their vehicles over obstacles to get ahead. But how to model the behavior of the cars as they fly through the air? A quick hack? or ... integrating elements of flight simulation or 3-D physics simulation?

Well, this team went the equivalent of the flight simulator route, and their hard-enough-to-code 2-D driving game has become a brutal 3-D simulation. All for a few jumps that in retrospect should have been hacked.

My point is not to complain about a historical decision that probably didn't seem bad given the info available at the time. It's to ask about how to avoid these problems in the future.

If you grant my assertion that, in some cases, no straightforward analysis reveals the problem at the moment the "how do we handle this case?" question is asked, then it seems like we need a set of milestones for a posteriori analysis.

We make a design call when we need to make a call, and then we need some specific questions -- and times or situations to ask them -- that will tell us if we're on the right track.

Specifically: What is the best and earliest way to ascertain if we're

1. monkeyhacking in an edge case that really demands a proper refactor
   OR
2. doing a refactor that way overengineers a solution that really just needs a monkeyhack

What do you think?

Does LLVM Mean An Alternative to Objective-C is in the Works?

The LLVM project has popped up on the radar a bunch of times lately. There's a variety of speculation about why the sudden interest.

I'll throw my hat in and suggest that Apple is thinking seriously about a full-service alternative to Objective-C for programming against the native OS X (Cocoa) API.

Objective-C hasn't spread as a general use language on other platforms, and Apple is showing a higher level of interest in expanding its ISV/developer base.

While other language bindings have been promised or offered over the years, none have been developed or maintained to the point that they are a realistic equivalent/alternative to ObjC. For example, according to an Apple insider I spoke with, it turned out that, under the hood -- at the level of linking, marshaling, etc. -- the cost of the incompatibilities with Java just got to be too great to try and keep it as a first-class environment next to ObjC.

It would seem that LLVM could open up a lot of doors here.

If, as reported, the Xcode environment hooks in with LLVM/GCC, then there is a natural integration point introduced at the intermediate representation (IR) level.

It may not be trivial -- LLVM is designed to be lower-level than, say Microsoft's CLR. The CLR, together with the CTS (common type system) and various other infrastructure and requirements, created a level of guaranteed interoperability between any two .Net languages ... somewhat different from the purpose of LLVM, which appears to be more about the ability to rigorously transform and optimize code in a hardware independent manner.

In this sense it may be about helping with Apple's parallelization work as well as cross-compilation for GPUs or PowerPC. Still, at the end of the day, there are libraries to be called into and data to be passed. And having a big multi-language abstraction in the middle would seem to make it a lot easier to massage the call patterns of other languages so that they play nice with ObjC system libraries.

Oh, and check this out: it's fun and interactive: you can try it in your browser and see the IR right now!

Want to Read Your Parents' / Boss' / Coworkers' Files? Mozy Client Circumvents Windows File Access Permissions

Last fall I wrote about Mozy, a cloud-backup company (now owned by EMC), which had a severe bug: it didn't back up all the files it was scheduled to. What was most disturbing was not that they hadn't caught the bug ... it's that when I tried to work with them to resolve it, they blew me off. Apparently I wasn't the only one to have this problem either, as people from all over found my blog post and emailed me, saying they saw the same behavior and asking if I had a fix.

I still think that not backing up files is the biggest possible bug for a backup program.

But now there's competition: their latest client allows a non-privileged user on a Windows XP system (haven't tried it on Vista yet) to restore private files belonging to any other user ... including Administrators, and place the "restored" files into the non-privileged user's folders, with full access, and fully decrypted.

How does this work? Say Jim, the Admin on the box, installs Mozy in a default configuration. Mozy is backing up Jim's "My Documents" folder and subfolders, among various other things. Jim's son Lenny, who is a non-privileged XP user and who is not supposed to have access to Jim's private files logs on.

Lenny notices that "My Computer" contains a virtual drive corresponding to the Mozy backup set. In that virtual drive is ... a "C:" drive ... and a "Documents and Settings" folder ... and a "Jim" folder. Now in XP, "C:\Documents and Settings\Jim" is another name for Jim's "My Documents" folder. This particular instance though is not the actual "C:\Documents and Settings\Jim", which Lenny doesn't have any access rights to, but the backup image of the folder.

So Lenny browses through, finds something interesting, right clicks and chooses "Restore To," which lets him "restore" his dad's file to somewhere of his choosing. He browses to his Desktop, clicks ok, waits a few seconds, and now he has the file.

(Even if Jim has chosen to manage his own crypto key -- one of Mozy's coolest features -- the Mozy client keeps that key accessible so that it can perform automated backups. Unfortunately, it also uses the key for restore operations no matter who performs the restore ... so files restored in this way are decrypted.)

Ok, so there are no secrets on the family computer. Not the biggest surprise, since if junior really wants the data, there are tons of other ways to get it, from booting a Live CD and mounting the hard disk, to yanking the hard drive right out of the box.

But here's where it gets more interesting: In many (most? ... all that I've worked at anyway) corporate, Active Directory- / Domain Controller- managed XP Pro deployments, folks can log on to each others' workstations at will, provided they use their own credentials in the Domain. Their Domain profile updates to the local machine as necessary, and they can then work there. They may even be able to log in remotely via Remote Desktop.

So at work, I walk up to my co-worker's machine (or maybe RDP in) and log in as myself. I open the Mozy tray icon, and proceed to restore their files from the backup set to my own directory, or to an unprotected area like C:\Temp. From there I can open/read/copy these files however I like. Incidentally, if my boss' files weren't already scheduled to back up, I can add them to the backup set. Next time the backup runs, they'll show up in my view of the "Virtual/Restore Drive."

I haven't tested the Mozy "Pro" business client, but since the docs [PDF] look identical to the Home client (apart from a color accent) I suspect it behaves exactly the same way (see in particular sections 7.3 "Using the MozyPro Virtual Drive" and 7.4 "Right-Click Restores") Not to mention that if Mozy fixed this in the Pro edition I can't think of any reason they'd intentionally keep a broken code fork for the Home edition.

I think there are some other fun tricks one could play with this client too, but it all boils down to two things:

1. The underlying process is a privileged process, but it takes orders from a client run by any user.(I'm no security guru, but this sounds like a Confused Deputy problem to me.)
2. The full fidelity of the local file (including a way to associate ownership and permissions) is not being preserved through the backup round trip.

I'd have reported it to Mozy before writing about it here, but they made their lack of interest clear last time around.

Update: I forgot to mention, MozyPro offers "Network share and mapped drive support" ... combined with the bug described here, that's some serious potential risk to add to the mix.

Please, Tell Me Another Cool Story About Your AAPL Stock

A comment I read today claimed that Research in Motion (maker of the Blackberry mobiles) stock (RIMM) has outperformed Apple's over any conceivable period you might want to look at. (Yes, I checked it out, it's true, and I have some numbers for you later if you don't want to go try it yourself.)

Here's what I find really interesting: Apple doesn't just have product fanboys, it has stock fanboys too. I've personally met dozens of people who -- entirely unprompted -- insisted on telling me about their AAPL stock adventures, successes, questions about timing and the future ... I haven't met a single RIMM investor who has spontaneously felt the need to chat me up about the stock.

Now there's no mystery about RIMM: Anyone who understands fundamentals could analyze RIMM as easily as AAPL. Or if they want to really get into it, RIMM's products, plans, sales channels, and management are arguably more transparent, simpler, and easier to crack than AAPL's. (Most investors love leaks and hate surprises.) So it's not like these AAPL investors stuck with the company they could understand and analyze.

Instead, I'd venture the opposite: I bet they know little to nothing about either company under the hood, but they love the drama and the theater of an Apple product announcement, whether it's really good or bad for the stock. They think that press coverage somehow equals investing success.

As for the numbers, I checked Google Finance and observed that ... yes ... in all the time that these two companies have been public, RIMM has outperformed AAPL over all reasonable intervals. In fact, even if you had, say, sold your AAPL to buy RIMM at the worst conceivable moment, when RIMM peaked relative to AAPL, within a few years your RIMM holdings would already be worth much more than the AAPL shares.

I'm not bringing this up to recommend one stock over the other. They have actually trended together, and if this sector is your thing (I count them together today, because of the iPod/iPhone contribution to Apple's success), then you might want to invest in both of them ... and some of their other competitors too ... to diversify, at the expense of trying to make the most money on a single horse.

But what cracks me up is how people so often want to believe a story they know over a story they don't know; a simple story over a complex story; and a story (narrative construct in general) over the tricky realities that motivate and underlie all of our constructs.

And if you're one of those people so in love with a romanticized Apple story that you don't mind having half the returns (in the last 5 years), 40% of the returns (last 2 years), or even just 30% of the returns (1 year) of a RIMM investor ... I'm not saying sell Apple, but diversify, diversify, diversify!

If Developers Love Speed, Why Is a Slow Laptop More Popular than a Fast Desktop?

When I was in college, there was an anthropology meme about how childbirth became riskier when the human pelvis adjusted for walking upright. So the ability to walk and run -- or the brain developments that caused humans to deal with problems by walking and running instead of some other way -- must have offered some massive evolutionary advantage that outweighed increased risk to mother and offspring in childbirth.

I'm not sure where this belief stands now -- whether it's established dogma or the anthro equivalent of an urban legend -- but there seems to be a funky analogy among developers and their dev machines.

I'm amazed by how many devs want to be mobile so bad that they use a laptop as a principal (or only!) development machine. I'm more amazed when these same people then get into a silly debate about "the best tools for the job," whether that's an OS debate, or IDEs, or something else.

Because, like walking upright in the story, a laptop offers mobility at a very heavy price.

I work machines pretty hard -- running server software, virtual machines, development environments / debuggers, lots of browsers, random other tools, some of which even use CPU cycles and not just memory. I appreciate the productivity and uninterrupted "flow" that a really fast machine offers.

Laptop performance is awful compared to desktop machines, and with every passing month a laptop (due to its limited ability for upgrade) falls farther and farther behind its well-maintained desktop counterpart. And a plain ol' $100 motherboard and $250 processor in a desktop will do things that make most laptops implode into a singularity, whether it's the 1333 MHz FSB, the 3+ GHz quad-core CPU, or a graphics card whose cooling pipe alone can't fit inside a laptop.

Even the top end, like the fastest Alienware gear, has some fundamental limitations that sound like desktops from a few years back: 2.8 GHz CPU / 800 FSB / 667 Memory ... and a price tag (with the best options) near $5,000!

It's not an OS thing either: the hyper-popular MacBook Pro, while one of the fastest "conventional/mass-availability/non-gaming" laptops, is a complete lightweight compared to the base 8-core Mac Pro tower (that runs the same $2,800 as a the top-end MacBook Pro).

Don't even get me started on the garbage laptops that most companies give their employees, machines which are optimized for durability, enterprise management, and running Office. Sporting things like 4200 rpm hard drives.

And for the occasional but real necessity of mobility, a $250 cheeseball laptop does a fine job for giving presentations, working with Office, and even a quick hack here or there, so it's not as though there's a huge sunk cost just in being able to bring a slide deck to a client.

Yet ... the ability to move around instead of sitting in one place offers -- or at least appears to offer -- some kind of power that compensates for all of these issues.

Can anyone clue me in on exactly what it is?

I Say "Ôpen" - You Say "Õpen": It's Not iPhone vs. Android, It's Software vs. Telcos

I couldn't find the first article I had read spreading the Android vs. iPhone competition meme. No matter, it has taken root and grown like ivy. iPhone doesn't compete with feature phones or smartphones, but with Android, yada yada. Where's Microsoft and RIM, yada yada. iPhone is closed, Android is open...

Hold that last part just a sec.

It is true that by the standards of the software world, iPhone is less "open" than Android -- Android will run on lots of hardware, it is open to programming at more layers of the stack, doesn't involve an App Store or a pseudo-proprietary language. iPhone is more constrained.

It's shaping up to be an epic battle if you accept that framing of the story... But:

By the standards of the wireless telco world, both iPhone and Android are "open" (as are Symbian and Windows Mobile) because they let you choose what you want to run, and by exposing services like GPS location and push messaging to ISVs, they allow a freeform relationship between the device owner and the software vendors offering real, fast-paced innovation. Such a relationship is a huge change from tradition, where the telco mediates the relationship to the detriment of everyone involved.

Never mind if the data access costs a bit more than some folks might like (Gizmodo shows that there isn't really any change here from existing smartphone plans). The carrier has to make money somehow, and building wireless infrastructure and selling access to it is what they're good at. Controlling the user experience is not what they're good at (one reason they rank slightly below used car salesmen and vampires in terms of customer satisfaction).

Looked at this way, iPhone and Android have a whole lot in common: they're trying to push the evolution of consumer use of mobile devices while trying to wrest control of the narrative from telcos who have stifled the industry for almost a decade.

The hype and success of iPhone and Android is a boon for consumers and for the entire industry, a chance for America to move from a cellular Minitel world to an Internet world.

In Blue Trunks, Skyfire and ISPs; In Red Trunks, Multi-Core CPUs, GPUs, Smartphones, iPhone and Laptops

Skyfire is a mobile browser that has been exhibited at DEMO and has just closed a $13 million B-series funding round (they had received $4.8 million total prior funding). The elevator pitch is that Skyfire brings any web content to the mobile phone, including Flash applications, YouTube videos, Ajax, etc.

I've been trying the Skyfire beta, and I have to say that it's a neat piece of engineering, even if it's just a stripped down VNC-style screen/audio scraping client for a server-side browser session.

But I'm stunned that it has received this level of venture backing.

My surprise isn't because the software is buggy, slow, and has a bad interface on my Samsung Blackjack. Since I'm running a beta in the 0.6 or 0.7 version range, I feel I should be charitable and I'll pretend that all the bugs will be fixed by 1.0, the interface will be great, and it'll run 10x as fast as it does today.

Instead, my surprise is because Skyfire is really about a great periodic function known as "thin client, no, fat client, no, thin client, no, fat client ..." and Skyfire is the epitome of the thin-client position.

Instead of running a browser (which ironically was once considered the thin client, but is now just the universal fat client, consuming hundreds of MB of memory on a desktop to run several Flash or Ajax apps) on a small device, they punted. They'd run the browser in a data center with memory, CPU, and bandwidth, and hand the phone a 2008 equivalent of a green-screen terminal.

This is a losing proposition. For a long time now, all signs have pointed to the fact that fat clients win. And not just because they happen to offer a better user experience (thin-client proponents insist that will change 'someday' although I doubt it).

The economics and technology lean toward the fat client: Although bandwidth has gotten cheaper on an absolute dollars-per-megabit basis,

• Bandwidth has gotten more expensive relative to the speed of "local" hardware buses: USB 2.0, eSATA, PCI-X, 1333MHz memory, gigabit Ethernet etc.
• Bandwidth has gotten more expensive relative to the cost of local computation: a midgrade Intel proc costs the equivalent of a few months of home DSL or cable ISP service, and this equivalent has been stable for a number of years ... and the computational power of that midgrade CPU has gone up severalfold, while the DSL/cable bandwidth has stagnated ... and now is threatened by both metered-pricing and traffic-shaping schemes. On the GPU side, the differential has changed by orders of magnitude to the advantage of the fat client.
• A given "bandwidth experience" has gotten more expensive as users expect to be connected in multiple contexts: To have the same "experience" I have to buy the same bandwidth several times, once for when I'm home, again for when I'm on my cell phone, again when I need to use WiFi somewhere, and maybe a fourth time for a 3G laptop card.
• Cheap powerful computation has innovators, while bandwidth has innovation obstructers.

Sure, raw dollars-per-CPU-cycle and per-kWh can be optimized in a data center somewhere.

But as long as the cost to connect me and that computation dwarfs the inefficiencies of just carrying the computer with me, Skyfire and its investors have bet on the wrong horse.

Microsoft Should Trumpet, not Downplay, iPhone's Real Accomplishment (Hint: It's not about Sales Volume)

In this article, Philip Elmer-DeWitt deconstructs a Microsoft partner mass email to discuss how a heap of chest thumping is presumably hiding real insecurities about how the Windows Mobile ecosystem stacks up to that of the iPhone.

Coming before the new iPhone launch, I agree this is not a coincidence. And although I've penned defenses of Microsoft in this blog, this post isn't one them. Instead of chest thumping, Microsoft should be talking to its partners about what Apple has accomplished with the iPhone that Microsoft has not in the 6-odd years since the first Windows Mobile phone shipped... and how that accomplishment has created new opportunities and liberated new value for the entire wireless space including the WinMo world.

In a nutshell, one of the enduring problems with wireless is that no matter how good the phones got (first WAP, then Java apps -- with networking, then color and multimedia and .Net and push data and QWERTY keyboards etc.), U.S. customers just never seemed to get that this was a real computing device, that would powerfully complement their PC(s) and could be just as general in use.

No matter how much analysis showed that the phones people already had could save weeks out of their lives through increased convenience and productivity (with the right software), almost no one used productivity apps, or mobile websites, on their phone. Some conceptual chasm just stopped people in the U.S.

So Apple comes along with the iPhone. And feature-for-feature, the original iPhone OS (not the OSX core, but as it was exposed developers/users) couldn't hope to keep up with Windows Mobile 2003, let alone '07 (WinMo 6.0).

But Apple was hunting different game. By combining a beautiful interface, ridiculously fast processor (to the point that battery life suffered), and an all-in-one experience featuring massive "On Ramp" signage to apps and the web, Apple got people to understand the phone was a computer that normally, natively runs apps and accesses the network, something no one else had accomplished on a mass scale in America.

I've written before about stuff Apple does poorly. This iPhone-as-computer play isn't one of those things. It was a big gamble, but arguably Apple has pulled off another early-Macintosh-type accomplishment in terms of changing how the public understands what a device can/should do.

And, as with the Macintosh, there is no reason that this "enlightenment" should only put dollars on Apple's bottom line. It boosts Windows Mobile, Symbian, Blackberry, Palm ... by focusing free mindshare on the phone as computer.

Now the other players need to follow through. Microsoft and RIM have the lead in the U.S. -- the first thing they ought to do is stop everything and get a browser on their phones that doesn't totally stink (that's the sanitized version of how both those guys' browsers deal with the modern web).

I won't detail requirements; I think Safari on the iPhone is a clear enough target. And while the wide variety of OEM hardware that runs Windows Mobile won't all have the CPU muscle for a Safari, Microsoft should make a credible effort to replace notepad, er, I mean Pocket IE. Meanwhile, why not send out a partner mass email confessing that PIE alone is costing everyone in the WinMo value chain bigtime.

If I were Ballmer, I'd dig up half a dozen hackers from inside or outside who have worked on the Mozilla codebase. I'd get them porting whatever they could to WinMo, and I'd have an internal team building a new Pocket IE product as well. At the end of Q3 '08, whichever browser works better on the most Windows Mobile devices, becomes part of WinMo, the other guys get a mediocre line for their resume (unshipped product), a vacation, and a reassignment to the next Microsoft Bob.

Maybe a Reason to Learn some Scheme, not a Reason to Avoid Anonymous Functions

A team member with one of my consulting projects sent an email yesterday, describing his counterintuitive run-in with the this keyword in an ActionScript 3 anonymous function. He found a fellow traveler looking at the same issue here... and concluded this might by 'yet another reason to avoid anonymous functions.'

I have a different view, which I thought might be worth reproducing here:

I'm not sure this is a reason to avoid anonymous functions. Looking at the issue and the blog post, the following points may be helpful for the newbies to ActionScript. AS3, and the Flex/Eclipse (FlexBuilder) environment especially, make ActionScript seem like a strange flavor of Java (or C#). But it's not.
ActionScript 3 is an implementation of EcmaScript 4. It has much more to do with JavaScript than with Java, although Adobe intentionally created an environment that would be familiar and comfy for Java devs.

EcmaScript (aka JavaScript) is a Lisp/Scheme family language not a C/C++/Java family language.

Unfortunately, for historical reasons, it shares some syntax constructs with the C-derivative languages, and ES4/AS3/JS2 adds more of those -- but many of them have different meanings, as the aforementioned blogger discovers the hard way.

If you're interested in how this came about, and how to think about it, I can't say enough to praise Douglas Crockford's lectures on "The JavaScript Programming Language", which you can watch from YUI theater. Brendan Eich takes issue with some of the "politics" stories in Crockford's account. But confirms that engineers were recruited to Netscape with the promise of implementing [some flavor of] Scheme in the browser.

If you expect to spend any amount of time in the future doing JS or AS, a couple hours watching Doug Crockford speak are unbelievably worth it. JavaScript (and AS) are extremely powerful languages and can work really well ... only they definitely don't work like they appear they should, if you see the syntax and come from a C/Java background...

Once we realize that we're basically running Scheme in the browser (Brendan says Self), lambda -- anonymous functions and their closures -- become first-class objects as fundamental to us as stack vars in a C language.

As a bonus, if you're new to this and have some time, MIT has published one of the classic textbooks, "Structure and Interpretation of Computer Programs" online for free under a Creative Commons License, along with instructors' manual, exercises, etc.

Actually, I'm gonna go out on a limb here and say if your company or team has a C/stack/register kind of background (Assembly/C/C++/C#/Java/Pascal/Delphi/VB.net/etc) and you're looking at getting involved in JavaScript/ActionScript/Ruby projects, make a team workshop out of doing as much of the Abelson/Sussman book as you can get away with. As a practical side effect, it'll also make your SQL code easier (core SQL is more like Scheme than C) and give you another way to look at problems.

Higher Energy Prices == More Value in Software, Bandwidth

I got to see Arthur Rosenfeld speak at UC Berkeley's Physics Dept. graduation last week, when my younger brother finished up there as an undergrad. Dr. Rosenfeld's lab and LBNL worked in both research and policy, producing technical advancements in energy efficiency focusing on physical buildings.

His talk got me thinking that not only can information processing produce efficiencies ... but actually that higher energy costs may also be a boon to all manner of information processing and software applications, because it increases the general (relative) value both of processing and of bandwidth (and associated infrastructure).

The gains apply not only to applications directly focused on saving fuel (e.g. logistics systems), but also all of the productivity apps that allow more (or the same) industrial capability with less effort, time, and raw materials. This productivity argument is a standard ROI type argument about information systems. It just takes on a new urgency as forecasts for the energy component in these industrial processes show a bigger number.

Also worth re-examining are the applications which are meant not to make moving physical stuff more efficient -- but to obviate the need completely. The U.S. Mail's logistics capability may make Netflix much more efficient than driving an SUV to Blockbuster ... but BitTorrent makes Netflix look like the stone age. It's no surprise that the easiest thing to move as data is a data-like-object.

The other category is meat-like-objects. Telecommuting and satellite work sites are vastly more usable and useful now than they were even 6 years ago when companies (famously Sun) ditched office space after the dot-com crash.

While issues remain with 100%-offsite work, I believe the era of traveling to the office five days a week for 'info-worker' jobs is pretty much over. Already, I see many companies allowing or encouraging people to work somewhere else part of the week, coming in only 2 or 3 days. That movement can become broader based as the support software and bandwidth improves. In the verticals, the telemedicine model will become more prevalent.

We can also create improvements in industries where the physical world is the point, like grocery stores -- and no, I'm not thinking about stuff like WebVan even if Safeway.com does pretty well, and amazon.com can ship you a year's worth of pasta. I'm thinking that sharing and augmenting data from a store (and its upstream supply chain) can reduce the number of trips people take to the store ... you won't go when they don't have what you're looking for; you'll look at the produce or the microbrews remotely and decide whether to bother; you'll spend less time in the store, which means a smaller (both in business hours and space) site can service the same volume of sales.

But I'm getting too specific: my point is not to envision kooky Internet schemes for avoiding bruised apples. It's that all of the software we have (operating systems, applications), hardware (GPUs, quad-core procs), and bandwidth becomes measurably more valuable as they becomes a viable substitute good for energy. And where we always measured productivity by looking at time-replacement, that time becomes doubly valuable when we are also paying more to heat, cool, light, or motorize the environment where people need to spend that time.

My Brain on Web 3.0: a Killer App for the Semantic Web?

Here's a semantic app I'd really like and which could make the Internet -- and data stores in general -- more valuable. If anyone sees this and thinks it's a great startup idea, you're welcome to develop it.

Right now, a number of semantic analysis engines are being developed, and many are running well in production. Examples include ClearForest, which is related to Reuters Calais.

There are also a bunch of up-and-coming semantic-web apps, like Twine, that add semantic analysis to the extant web 2.0 experience. But while the RDF-enabled-del.icio.us-on-steroids-with-autotagging may be nice -- heck, I'm sure I'll be using one of those systems -- I want something that can carry out the kind of mental associations that I normally would have to do myself.

In order to make that a reality, I'll need several things:

1. The Model: it works by association, and associations have direction, degree, and kind, among other things. So we need more than just a network. We need a model that implements a metric space or vector space, allowing distances to be computed between any two points with sensible behavior, and where measures (length, volume) can easily and intuitively work.
2. Concepts (e.g., "politics"), and the places concepts are referenced (say, a political blog page), both live inside this space as subspaces, just like in my brain. Some of these spaces may consist of just one element.
   
3. The formulae that support metric need to be fine tuned so that abstract tags ("politics", "justice" as opposed to "Davis, CA" or "bananas") don't suck a million other things to within epsilon of themselves. We can't have everything that linguistically has to do with politics cluster tightly in the space to a politics node, or else the system isn't terribly helpful.
4. I want the system to start out thinking like me ... and then I can experiment later with "social thinking." What does this mean? My semantic tagging is different from everyone else's. Each group or culture I'm in sees the content differently from other groups and cultures; there is no universal invariant conceptual structure. One persons sees a news story and thinks "economics" while someone else thinks "environment" and another thinks "social justice." If we mush all these tags together we get nothing terribly useful. So: let's start out with my view of the world, we'll compare and integrate others' later.
5. How to do #4? Start with every web page I visit (not just those I actively tag) -- read my history file or my network traffic (obviously, keep raw data local for now). Read my email and my calendar and my notes and phone (PIM) and my to-do list. And weight accordingly: associations in a web page I write (like this blog post) count more than stuff I browse through; notes I make in my phone or Outlook count for even more; the metadata in my calendar and the titles of my contacts mean a heck of a lot for the model. Walk my social graph and look at what my friends know and are interested in! These are all straightforward algorithmic steps. Leaving aside any self-tuning in the metrics engine, there is no AI or black box here.
   
6. The data from #5 is part of the metric function ... that's how the system shapes itself to my view of the world, or at least my "attention waveform" as I transmit that through keystrokes and mouse clicks. Concretely, nodes "move" in the space based on whether I actually key them, whether they appear in meetings in my calendar, whether they are tightly clustered to my personal contacts etc. Even my contacts are arranged based on how long I've known them, what I talk to them about, how often, etc.
7. The system will make mistakes. So all the more reason for (1) privacy around my core data and (2) a dashboard where I can "juice" certain things or move them around. (This is where interesting goal-oriented self-retuning can come inThere is plenty of other data that can be shared and deduced for network-effect-dependent revenue streams.
   
8. A UI into the model. What I'd really like is something brilliant and minimalist (that I can't myself invent!) I know there are lots of desktop-based visualization methods that would be fascinating and could dazzle a crowd at a presentation, but I want something day-to-day useful ... and ideally something that fits on a mobile phone (or at least iPhone) screen. So that in a perfect world, if I'm out and about, I can poke this system with one piece of data and have it return the associations my brain makes -- and the ones it would make if I were jacked up on caffeine and had the whole internet in my frontal lobe somewhere. I'd like maps, charts, and pictures in there too.

I hope this outline makes some sort of sense. Like I said, it's really not as tricky or complex as it sounds. Fine tuning the metrics will take real work, as will optimizing the data structures so that the relevant queries are fast, and so that the system can work in "tinfoil-hat-private-mode" as well as "publish-whatever-you-deduce-from-my-friendfeed-and-private-chats-mode."

Incidentally, this app could also help solve the augmented reality dilemma of "how do you narrow down all the possible info about the input objects and coordinates, so that the user sees something interesting and/or actionable," so that's another angle.

Have some capital or time you want to throw in this direction? Feel free to email me -- adbreind@gmail.com ... or if you want to loot this idea and think you can build a killer app for the semantic web era? That's fine too -- send me a link when I can sign up for the beta.

Great Article on the True Nature of LINQ in C#

In the early days of C# 3.0, Microsoft distributed a whitepaper which walked through the rationale behind the additions to language, how the language changes related to the syntax options, and what it could be used for.

Among the key applications ... perhaps a co-evolved objective ... for the new constructs was LINQ ... of the to-SQL, to-XML, and over-Objects varieties.

As Visual Studio 2008 and C# 3.0 has moved out into wide use, though, that background has faded away and instead one sees a ton of quick examples and how-tos about LINQ and database operations that give the impression it's all some kind of fancy SQL trick.

Which is why I really liked this article on 7 Tricks to Simplify Your Programs with LINQ.

The only thing I didn't love was the name, because it's not really LINQ that Igor is talking about, it's the awesome functional programming features under the hood ... which happen to enable LINQ.

Igor shows how the underlying extension method and lamba constructs let you do the cool Lisp (ok, Ruby) tricks with C#, and he does it without getting into explaining what all the machinery is or even what it's called. Those explanations are important to be sure, but having these quick (2-3 lines!), powerful examples communicates a lot at first glance to readers who may not want to read about all the CS issues right away.

Furthermore, Igor avoids examples featuring the slightly misleading SQLesque syntactic sugar that can cloud what's really happening... until his last example.

Which is very useful, because the busy developer-on-the-run seeing a LINQ example doesn't realize that the select/from/where stuff are not magic language keywords. They're just an alternate way of saying Foo.Where or Foo.Select. They're just extension methods that happen to be fairly fundamental to working with lists and sets.

Maybe Igor even gets some folks who thought C# had somehow sucked in SQL to realize that, instead, all the time they've been writing complex SQL queries, they've actually been doing that functional programming stuff they've been hearing so much about. And now they can "think the same way" in C#.