Adamac Attack!

Websocket Client for Java

2010-01-08T08:19:00.001-08:00

A few weeks ago I published an implementation of a Websocket client written in Java here. If you're not already familiar with it, I'll point you to Mark's post, which is a great explanation of the practical benefits of this protocol. The main reason I wrote this in Java was for compatibility with Android, so if you have trouble using it in other situations, it would be great to get feedback or patches.

PartyCamera for Android

2009-12-17T15:44:00.000-08:00

I just released a new application on the Android Market called PartyCamera. If you're on Android, you can follow this link to get it. Here's the description on the Market:

Ever wanted to pass your phone around at a party, but were worried about people looking at private information on your phone? PartyCamera locks your phone into camera mode - preventing other uses!

Once activated, press the HOME button to enter your password and exit PartyCamera.

I'm eager to get feedback from users, especially with regards to how it works across different devices.

Android Doesn't

2009-11-25T07:52:00.000-08:00

Android has been promoted as exposing many more phone features to user-installable applications than the typical "open" mobile OS. Here is the "All applications are created equal" bullet from the Android About page:

Android does not differentiate between the phone's core applications and third-party applications. They can all be built to have equal access to a phone's capabilities providing users with a broad spectrum of applications and services. With devices built on the Android Platform, users are able to fully tailor the phone to their interests. They can swap out the phone's homescreen, the style of the dialer, or any of the applications.

This may be Google's goal, but at present this statement is patently false. Yes, you can swap out the homescreen, but it's impossible to build a suite of applications that can achieve the same level of functionality as the core applications.

Most of Android is open source so it's easy to look at how the system works. The core applications have special permissions or access internal APIs which are not exposed in the SDK used by third-party applications. This means it is not possible to recreate the full experience of the core applications entirely using user-installed applications.

Getting the same level of access as the core applications entails modifying the Android source, which means you should really be building your own device or have a very technically savvy audience who is willing to replace their system software with your own (and that assumes they have a device with root access). Downloadable applications available through the Android Market or other channels cannot perform these functions.

Many developers had expected Android to provide a new level of accessibility not previously found on platforms like J2ME or even Windows Mobile and Symbian, but it appears there are still many things that just aren't possible. Here are some of the features I have found missing from application capabilities:

- Replace the in-call screen.

- Dial numbers in the background (without an in-call screen; useful for call forwarding, etc.)

- Dial emergency numbers (Ok, not really necessary :).

- Access call audio streams (e.g. for call recording)

- Suppress notifications from other applications (toasts)

- Incoming call control (filter/block/redirect)

These are the features that I've personally been stymied on; I'm sure there are other common scenarios that aren't supported. What have you found?

The Revenue Singularity (Google Drinks Your Milkshake)

2009-11-19T13:13:00.000-08:00

I've heard a number of people recently say something like "Google is a one-trick pony. They've never made a dime off anything but search." While this is mostly true on its face, it ignores the bigger picture of what Google is doing: converting all tech revenue into advertising revenue, where Google owns the majority of market share.

As I've stated before, Google's endgame, explicit or not, is to commoditize all software to the point that no one can make money directly off software. This means no more software royalty streams, no more software subscriptions, no more software IP sales. By open-sourcing so many types of software (and this software is mostly at the top of its class, if not the very best), Google is making all types of advanced software free. Of course, Google's core infrastructure and advertising software is NOT open source. In this world, Google's operational efficiency and huge search advertising market share are their competitive advantage.

By making software free (or less than free), Google is knee-capping any company that tries to sell software. Android is destroying revenues for mobile OS vendors. ChromeOS will have the same effect on PC OS vendors. Shares of navigation software makers dropped by nearly 20% after it was announced that Google would give a revenue share to OEMs installing its Google Navigation product. The list goes on.

This has two effects: to cripple its competition and to establish a baseline price which drives software developers into Google's arms. By building best in class web applications, Google has established that no sane person would pay for any web application. With free now the de facto price for software, the only way for anyone to make money is through advertising, where Google will reap the majority share.

It may be true that Google does not make money DIRECTLY off many of its non-search products. But the conversion of software to a "less than free" commodity means Google is destroying value in many other areas and siphoning some of that off as search revenue.

wmaloader for Windows

2009-11-09T10:28:00.000-08:00

I'm still using an ancient Linksys WMA11B Media Adapter to stream audio to my stereo. The original UPnP-based software it came with was really buggy, so I use some alternative firmware to connect it to my Squeezebox Server (nee SlimServer).

The firmware is downloaded by the device everytime it boots up, so it's easy to send it a new brain. The Linksys server software was also a pig though and only worked on windows, so someone was kind enough to put together an open source package called wmaloader as an alternative that runs on most OSes.

I've been using the wmaloader on Windows for a while, but it was a pain to setup and didn't work out of the box as a service. I've built an installer that bundles up the necessary binaries, installs the service, and opens up the firewall as needed.

The installer binary is here, and the source is on github.

PubSubHubbub Subscriber for Python

2009-09-28T13:27:00.000-07:00

I built a little PubSubHubbub subscriber library in Python that I just put on Github here. I'm using it for real-time sharing from Google Reader to Twitter, but there are a lot of other interesting applications coming along.

10 Startup Red Flags

2009-04-07T13:50:00.000-07:00

I've worked on a number of startups: from seed-stage through IPO, as a founder, employee, advisor, and consultant, as well as evaluating a bunch from the outside, so I've seen my share of screw-ups. There are some obvious warning signs, but sometimes these are hard to recognize except in hindsight or without prior startup experience. If you're considering working for a startup, hopefully this will give you some tips on what to look out for.

Of course, everyone should trust their gut, so if you feel something's not right, it's probably not a good fit. I'm not going to go over everything you should be looking for in an employer or even in a startup, just some warning signs that might make you think twice about what might otherwise sound like a good opportunity. On the other hand, if you're running a startup maybe these are some things to avoid. If anyone has any strong objections to these or good stories, I'd love to hear them.

1. Wacky Titles

Startups that have too many VP and C-level titles floating around are just asking for the smack-down. Who's going to do the work if everyone thinks they're an executive? Titles like SVP and EVP are silly at a startup, and a giveaway that there's been some serious shuffling or some really big egos are involved.

It's generally wrong for people to have multiple titles too. Ever met a CTO/VP Engineering or CEO/CTO? Yeah me neither. At least, I've never met someone who needed to have both of these titles. This is generally a sign of some wildly narcissitic personalities.

If you're the CEO, just be the CEO! If you're highly technical and drive the technology vision of the company, people will get it without you tacking on the CTO title.

2. A Billion Outstanding Shares

Most startups should have fewer than 50 million shares outstanding. If you get an option grant for a million shares and you're employee 25, something is funky. Maybe the CEO got his cousin from Omaha to be their lawyer or there's been some serious messing around with the cap table. Either way, it's a sign that something is amiss.

3. Lack of Technical Leadership

In my definition, to call a company a tech startup, there must be some significant technology that gives you an advantage. Just using technology isn't enough (who doesn't have a website these days?) This means there MUST be a technical founder in a startup. If you're outsourcing the all the technical work, your company probably isn't a tech startup.

It follows that an "idea guy" who "just needs to hire a few engineers" probably isn't running a tech startup. If you're the first technical employee at a startup, you're either a founder or you're a sucker.

4. A Large Number of Ex-Employees

With social networks like LinkedIn, it's easy to get a rough idea of how many people work at a given company. Of course, not everyone in the company is going to be on LinkedIn, but if a large number of people are former employees this is a really bad sign for a startup as there probably aren't that many employees to begin with. Maybe there were layoffs, which isn't a great sign, but it probably indicates a serious retention (i.e. leadership) problem.

5. An HR Department

After a certain point, all companies need someone in charge of hiring just to deal with screening, scheduling, and general process, but most startups don't fall into this bag. If the company in question is a 5 person shop and they have someone outside the core team calling you, there's something wrong. The founders or at least the hiring manager should be doing the bulk of the hiring early on - including phone screens. I think this applies up to about 50 people.

Recruiters are generally non-technical and aside from process-pushing offer little aside from their network of contacts. If you're just looking to have resumes keyword-scanned then maybe you should consider a basic mail filter. When budgets are tight this is one area you shouldn't feel bad about skimping on. Hiring is one of the main things a startup must get right, but contract recruiters aren't the way.

I actually once had a very non-technical recruiter try to give me a technical interview (including coding) over the phone. That's a REALLY bad sign.

6. Too Much Big Company Blood

There's an old joke about General Managers from a certain very large software company who think they've "built" a billion-dollar business who then fail spectacularly at starting a company when they no longer have that big company business card. Well, it's not a joke.

Startups require resourcefulness and a rolodex of enterprise customers isn't enough. People who are too far removed from doing actual work and haven't worn more than one hat are unlikely to be successful in an environment where this is a serious prerequisite.

I'm not saying that no one at a big company can succeed in a small company, but in my experience success is rarely transferrable between the two.

7. Zero Transparency

The interview is a try-out. It sets the stage for how things might work on a day-to-day basis. If your questions about funding, outstanding shares (save this for after the interview), and the general details about the company's plan go unanswered ("It's not our policy to disclose that" is the usual response), is there going to be any openness when you work there?

This one is pretty generally applicable to all hiring, but given the small size of a startup there can't be a lot of secrets and if the atmosphere is secretive to start with, how much worse will it be when the company is bigger?

If it's your company, bear this strongly in mind. "Stealth-mode" is generally unecessary and more likely harmful to your startup (and calling it stealth-mode calls you out as a noob). You may not be ready to go as far as some in how open your startup is, but consider what radical transparency can do for you.

8. Marketing Stunts

Startups need to be cash conscious. The ones that are spending money on large booths at conferences, television ads, or huge launch parties might be fun to work at, but they likely won't be around in 6 months too.

9. Too Much Money

One of the biggest threats to a startup is running out of money. But too much money can kill just as easily. VC-backed startups can find themselves in a position where there investors are trying to drive growth by pumping money into the company. Unfortunately this usually backfires.

The first thing that happens with too much money is too much hiring. You start hiring a lot of people in sales and marketing to drive revenue, and while you may still be hiring people to do real work, the weight from the top starts to push down on everything else. The focus on hiring can take away from the drive to get actual work done which means your company is going nowhere fast.

It's easy to start losing discipline when the money is flowing around, so while that $50 million looked like a lot of money when you were 20 people, when you're 100 it's nothing. Consultants, free lunches, massages, and junkets expand to use it up.

10. Lack of Focus

When the CEO says "We're going to be bigger than Google!" and you can tell he really believes it, you should:

1. Kindly thank him for taking the time to speak with you.

2. Leave the building.

3. Never speak of this again.

It's great to have a big vision and try to get others excited about it, but a startup really needs focus (What's the minimum viable product?). You can't take over the world without building a few forts first. If company management won't even engage you in a realistic discussion of the challenges the company will face, it's going to be an uphill battle.

Building Android from Source on a Mac

2009-03-03T18:32:00.001-08:00

I found this whole process to be pretty straightforward just following the instructions on the Android source page.

The one problem I ran into was that I had installed a newer version of bison (2.4.1) using the MacPorts port command. This version of bison has known problems building webkit, which is part of Android.

To work around this, I removed this version of bison (port uninstall bison) and re-installed version 2.3 from source by downloading from the bison ftp site (MacPorts doesn't support anything but the latest version of a port).

With this change, everything worked just fine.

Configuration Management Best Practices

2009-02-18T17:40:00.000-08:00

I've recently read a number of pieces (including this blog) that have reminded me how strongly I believe in the power of the right configuration management process to improve the efficiency and effectiveness of a software development team. I thought I would summarize some best practices that I think every development team should have in place.

Configuration management is a pretty nebulous term and conjures up visions of gargantuan "enterprise-class" systems with their own team of administrators (ClearCase, anyone?). In my mind, configuration management is simply those tools and processes you use to build, distribute, and manage your code, including version control and continuous integration.

What follows is my list of top best practices in this space. I'll leave further discussion for another time. These pretty much assume you already adhere to The Joel Test, so this list can be seen as a more rigorous set of standards (a one-step build is a definite prerequisite). Some of these seem really obvious when written down, but I'm amazed how many teams don't do these things.

1. Use an IDE-independent build tool (e.g. SCons, swtoolkit, but please not make), unless you will never build on more than one platform.
2. Consider building on more than one platform (compiler, architecture, OS) to improve code quality.
3. Run continuous integration (build and test) on every commit.
4. Keep build products and test results for every commit and make them easily accessible (indexed by revision number).
5. Commit early, commit often.
6. Limit commits to one functional change. (Don't fix multiple bugs unless they have the same fix.)
7. Make it easy for developers to run cross-platform tests in advance of committing.
8. Never commit untested code. (Shoot users of "git add --p" in the head.)
9. Make fixing build breaks your second highest priority (behind fixing production breaks).
10. For consistent builds across machines, keep all tools in your source repository (or at least make fetching them part of your build).

What other practices do you stick to?

Evolution Revolution

2009-02-03T15:18:00.000-08:00

The iPhone is a revolutionary mobile device - not because of the features it provides (other smartphones provided these many years earlier), but because of the level of seamless integration of these features into the first truly personal mobile computer. The experience provided by the iPhone is causing a revolution in user behavior, allowing them to consume information in new ways in new places.

When the Palm Pre was announced at CES, there was some excitement, but on its face, the Pre is really just another company's take on the iPhone. Physical differences aside, the biggest difference between the Pre and the iPhone is the programming model. While the iPhone sticks to the Mac's native application roots, the Pre's webOS will be programmed entirely using Javascript and CSS. The webOS SDK has not been released to the public yet, but a few features that will be exposed are HTML5 local storage and a JSON-based message bus.

Javascript has been gaining more and more momentum across a wide range of application tiers from the web browser to the server-side and now to the mobile device. This probably isn't because it's the best language in the world, but it is flexible and the existing platforms support easy interaction with webservices and the DOM. Though it's not clear that there are more Javascript developers than Objective-C developers, the barrier is lower for developing on this type of platform. The tools are readily available and concepts like pointers and memory management are nowhere to be found.

Given the increasing number of platforms supporting Javascript + HTTP + HTML5, it's not inconceivable that "write-once, run anywhere" might come closer to fruition with this combo than Java ever achieved.

Here's how this architecture plays out in my mind. Javascript is the core programming language. Using a HTTP transport and JSON data format, components in different processes can perform RPCs to one another. HTML5 features like local storage and the application cache allow for an offline story (the latest build of Safari on iPhone supports this). And of course, HTML + CSS allows for a common UI platform.

HTTP as a universal calling convention is pretty interesting. We already have tons of web services in the cloud using HTTP to communicate with one another - why not extend this to include local code talking with other components. The iPhone already supports a form of this IPC using the URL handlers, basically turning your application into a web server. BugLabs exposes interfaces to its various embedded device modules through web services. It has even been suggested in the literature that every object could embed a web server. Why not use this mechanism for calling that object's methods?

The benefits for such a system are great in terms of portability, dynamism, and interoperability. While there is certainly an overhead to it (a web server in every object???), performance is looking far less important than connectedness in today's web ecosystem. Sure, people aren't writing device drivers and high-performance games in Javascript, but most everything else is being attempted with good success.

Javascript (count HTML and CSS if you like) is the only mobile code platform that has succeeded on a large scale. The ubiquity of such a de facto software platform could lead to the true component software revolution that has been talked about for years. It's already evolving on the web, but the next stop is the desktop and your mobile device.

Learning Objective-C

2009-01-17T22:50:00.001-08:00

Over the past year I've been working with the iPhone SDK on and off. It's a nice SDK which I won't get into the details of here, but for a good summary, check out this post. The APIs and iPhone runtime are pretty straightforward, so one of the biggest hurdles for an experienced (non-Mac) programmer is learning Objective-C.

When you first look at the language it appears to be some sort of "human-animal hybrid" formed from the mating of C++, Ruby and Perl. If you're a C++ programmer all of your experience applies, but the syntax is annoying and unnecessary (like Perl) and there's a sprinkling of Ruby-like dynamism. Once you get past these fundamental differences, it's a pretty enjoyable language to use.

Here are the resources I've found most useful for learning Objective-C.

Cocoa Dev Central Tutorial. This is a good way to get started quickly and hits the important parts of Objective-C without burying you in detail.

From C++ to Objective-C. As the title suggests, this is great for real C++ programmers who want to understand Objective-C constructs in more depth with comparisons to C++.

Introduction to The Objective-C Programming Language. Apple's Objective-C reference is more detailed and useful for understanding language arcana.

Chrome Goodies: SCons, Buildbot, and Skia

2008-09-08T21:15:00.000-07:00

With a quick look I noticed that Google's new Chrome browser uses SCons as its build tool. This is great news! I've been a fan of SCons for quite a while and have used it on a number of projects. In my experience it's especially good for building native code in multiple configurations. I won't go into all of the benefits of SCons, but the fact that it's written in Python means scripting your build system is a breeze.

While SCons has been used by a number of open source projects out there and is supposedly used by some large software companies (VMWare, id Software) this is the most significant open source project using it. I've seen some Google engineers been lightly involved in the project in the past, so hopefully this will push further adoption. SCons is not without its issues, but it's head and shoulders above any other build tool I've used. Will this be one of the last nails in GNU make's coffin? I hope so.

Chrome also uses Buildbot (also written in Python) for its continuous integration system. Buildbot is another open source tool that I've used in the past and loved its easy configurability and extensibility.

Also interesting to note is that Chrome's source code includes the Skia graphics engine. Skia was a company acquired by Google in 2005 and its SGL (Scalable Graphics Library, nee Skia Graphics Library) engine serves as the core of Android's rendering system. This is pretty exciting given that there isn't a great vector graphics toolkit out there that is open source and is suitable for embedded. Mike Reed, the founder of Skia, has built something like 4 graphics toolkit companies and sold them, so the code should be quality. At present, the Skia code looks to be built only for use in Chrome, but I imagine it will be released standalone at some point. Look for Skia to appear in more Google products such as Google TV in the near future.

AtomDB - Oracle's response to Gears Mobile

2008-07-23T12:57:00.000-07:00

I just read about AtomDB. This really sounds a lot like my GearSync proposal, but using Atom instead of Microsoft's FeedSync protocol (which I still haven't seen anyone using). The big difference from Gears appears to be the transparent model of data access.

There's a detailed paper here.

The MobileMe Lockdown

2008-07-21T08:11:00.001-07:00

I love my new iPhone 3G. As far as I'm concerned, it's the best mobile device that's ever been built. But like many people, I'm torn - the iPhone isn't an open device and there a few things that are difficult or impossible to do as a result.

With my BlackBerry I simply installed the free Google Sync program in order to keep my calendar up to date over-the-air. Now with the iPhone, Exchange support works great, but if I want to do OTA sync thing without an Exchange server, I need to pay Apple $99/year for their MobileMe service. This feels like extortion, especially given that there can't be any alternative given Apple's prohibition against background apps. Not only are other companies disallowed from building an app like MobileMe, Apple IS building such an app and charging users for it.

For companies that provide seamless, real-time sync and upload like Ontela and Dashwire, this is a non-starter - they will probably never build apps to run on the iPhone. Sync providers such as Funambol have built manual-sync apps, but it's a stretch to say this is sync.

The only real-time messaging on the iPhone is Apple's push mail and SMS, so IM apps are pretty much out of the question (though if you don't care about incoming messages, there are a number of options such as browser-based Google Talk.)

More important than the companies being locked out are the users who can't get access to their data. With MobileMe, for my $99, I get web-mobile-PC sync with a whole new set of applications to use, plus 20 GB of free online storage. The only problem is that I don't want new applications. I use Flickr, GMail, Facebook, Google Calendar, and other services whose data I want to access on my iPhone. With web access and SDK-based apps I can access this data through site-specific portals, but this isn't the same as syncing this data into the core apps on the phone. I can always fall back to cable-sync, but that's truly a step backwards.

Apple has never used "compatible" or "open" rhetoric like Microsoft or Google, choosing instead to provide the end-to-end solution that "works". In this case, it's hard to see how MobileMe works for most people when it's not open enough to pull in data from my existing sources. In the PC era, MobileMe might have been good enough, but today it just feels like an anachronism.

Is Android the Next OS/2?

2008-07-15T20:45:00.001-07:00

Amid news that Apple sold over 1 million iPhone 3G over the weekend I just read that Android developers are miffed about the lack of an SDK update. Not only that, but it's not clear at this point when a device will actually ship with Android software. I've mentioned in the past how the SDK was initially unpolished but I really thought it would improve pretty quickly with frequent updates.

Aside from a demo at Google I/O, there's little indication of when the first Android device will ship. Unlike the iPhone which had firm ship dates announced and developers (web and SDK) clamoring to build apps before the hardware came out, Android is in a very different situation. I don't know any mobile application companies that are building Android apps at this point, and I don't think they will until there are some firm announcements on real hardware. The Android Developer Challenge is full of hobbyists and desperate startups, not real companies looking to deploy their apps on an innovative platform.

Don't get me wrong, I would much rather program to Android's Java APIs and use some of its great features than have to deal programming Objective-C to get my app on the iPhone, but hey, the iPhone is rad and shipping now. Without shipping hardware Android is starting to look like the next OS/2 - a lot of hype and little to show for it.

Facebook Will Never Delete Your Photos

2008-06-30T19:45:00.001-07:00

...even if you tell them to. Really. This presentation about Facebook's photo storage architecture details how deletes are performed by only deleting the metadata. James Hamilton has a good summary of the details here.

None of this should be too surprising if you know anything about consistency issues in distributed systems, but it's kinda funny to think about. For Facebook, it's way more trouble than it's worth in terms of protocol complexity to recover that space, and few people delete photos, so there's not much to gain anyway. No one should be able to access these files anymore, because without the metadata, there's no way to find the photos. But the data is still there. Those incriminating pictures that you thought you'd deleted could still be subpoenaed, though it would probably take Facebook a long time to find your deleted photos in those 500+ TB without an index...

Upcoming Gears Features

2008-06-15T10:18:00.001-07:00

Chris Prince discusses some of the upcoming features in Gears in this Google I/O video. As I discussed previously, Gears and BrowserPlus are both adding new features to the browser. The newest set of features discussed for Gears includes desktop notifications, a file chooser API, geolocation, resumable HTTP upload, and data blob support.

Of these APIs, I'm most excited about notifications and geolocation (especially for mobile), but there's a lot to like here. At this point these features are in the prototype phase, so the source code may already be available in svn, but you won't be able to use them in your app quite yet. You can follow the Gears engineering efforts on the Gears Engineering Group.

If you're especially interested in Gears, there are a few other Google I/O videos here, including one on standards and mobile.

Aggregation and Annotation in the Social Web

2008-05-30T15:30:00.000-07:00

A big theme on the web over the last year or so has been aggregation. RSS readers (aggregators) have been around for a while, but the latest theme is aggregating your digital life. FriendFeed is getting a similar level of buzz as Twitter, but socialthing, profilactic, Plaxo, iminta, and of course Facebook all have some similar vibes. I co-founded a company last year called MergeLab that ended up working in a similar space. These so-called "digital lifestyle aggregators" have been around in some form or another for a while, but none of them really seemed to catch on until now.

The core idea here is that given the large number of web sites and services that people use, it's getting harder to keep track of all of this information, whether it's your personal information or that of your friends. At MergeLab, we called this "Open Facebook", since we allowed you to add data from Flickr, Twitter, Facebook, Amazon, etc. and view it in one location, though we were really referring to just the newsfeed part of Facebook. Facebook itself is moving in this direction with the ability to connect with other sites that publish information about your friends into your newsfeed.

Unlike FriendFeed, MergeLab didn't require people to approve you as a friend - if you had access to some publicly available feeds, you could just subscribe to them. This meant that it didn't have the same viral characteristic as FriendFeed, but it did allow you to pay attention to, say, your mom's feed without having to convince her to subscribe to some new-fangled aggregation service.

Some people claim that FriendFeed isn't about aggregation, but is about the conversations you can have about all of these activities from your people. Facebook has had some similar features for a while, though I think if you're into following the whole conversation, FriendFeed has a much cleaner model (ever tried following a thread of Facebook by jumping back and forth between wall posts?). Interestingly, Facebook's "new" layout puts the profile view front and center, but right now it appears to just include your personal feed items.

Now, you might ask why we don't just use RSS here, after all, this is essentially the problem it was designed to solve. I think there are are few reasons.

Many sites don't want you to take your data with you to other sites as they see this as their crown jewels. Certainly this is true with Facebook as we've seen in their tizzy with Google over Friend Connect, though there's also Facebook Connect, which purportedly is all about data portablility.
A lot of these services don't expose RSS, either because their data is too "complicated" to be expressed in RSS, or they're just interested in trying to build a dependence on their API.
RSS is essentially one-way. Sure, you can use Atom or POST RSS in some cases, but it's not a widely deployed use like simple syndication is.

So is it possible to have neutral parties implement aggregation services? It seems that the natural tendency for these services is to add value through annotation, sharing, and the like to increase stickiness and hopefully make money. Google Reader is doing this, for quite a large user benefit I believe. However, once the point of aggregation becomes a point of stickiness it also becomes a point of control and thus another potential constriction of the free flow of a user's data. So far very few companies have made any money on aggregation (RSS or social) so it will be interesting to see how this plays out. FriendFeed and Twitter don't appear to have any revenue yet and Facebook is making money, but very little in proportion to its valuation.

Yahoo's BrowserPlus versus Google Gears

2008-05-28T19:08:00.000-07:00

Yahoo today unveiled a "Sneak Peek" of its core browser functionality extension called BrowserPlus. Meanwhile a similar effort, Google Gears, was renamed to just "Gears".

BrowserPlus is described as "desktop capabilities" for web apps, all of which are exposed through Javascript APIs. The core services in BrowserPlus include some things that are really essential for bringing web apps to the desktop and a few that don't make much sense.

DragAndDrop adds support for drag and drop between the browser and the desktop. Pretty cool. Notify displays notifications (toasts) using native window controls. This is very useful and relies on the Snarl (Windows) or Growl (Mac) notifiers being installed already. Snarl is a funny choice here since theoretically it's Growl's counterpart on Windows, but doesn't really have any applications using it as far as I can tell.

RubyInterpreter allows you to write services in Ruby. Haven't tried this out, but it sounds like something you'll be able to do soon with Microsoft's Silverlight + DLR + IronRuby. TextToSpeech is novel but inessential. Look for more desktop-only features like this to be added in the future. There's also a FlickrUploader and IRCClient which don't seem like core services as much as one-offs. A number of other utilities are included such as Log, ImageAlter, and FileBrowser.

JSONRequest is the one piece of functionality that doesn't really have much to do with the desktop, but is useful for writing browser-based applications. I'm sure Douglas Crockford is to thank for this. JSONRequest allows to you avoid the problems of the Same Origin Policy without exposing you to the security issues of workarounds such as JSONP.

I tried out some of the BrowserPlus demos and they seemed to work. I did see my browser (Firefox 3 RC1) crash a few times in random contexts, so watch out.

On the Google side of the fence, Gears was originally focused on offline (Database + LocalServer) support, but has recently added some desktop functionality - the ability for a browser application to add icons to the desktop. Surprisingly, there is very little overlap between BrowserPlus and Gears with the exception of local storage where Gears offers a more complete solution than BrowserPlus' PStore.

The one feature I haven't mentioned so far is Gears' WorkerPool which allows Javascript code to run in the background. This really just means there's now a thread pool in the browser that allows you to queue up tasks. This isn't the same sort of "background" that comes to mind for me, like Apple's lack of background support in the iPhone SDK, but it still seems pretty useful. There are a lot of security implications to having true Javascript background applications in the sense I'm talking about, but I'm sure we'll see this in Gears or BrowserPlus sometime soon. With this feature enabled, there's little reason to use any other desktop app model - combined with the Notify feature described above, you can build a traditional IM application (one of the few desktop apps I still use).

Overall this space is looking pretty exciting. Adobe AIR is taking web applications onto the desktop, while Gears and BrowserPlus are melding the browser and the desktop and generally making the browser a better development environment. I don't think it will be long before all application code (for the desktop, anyway) is written in Javascript!

Android's Multicast Support is Broken

2008-05-14T21:04:00.000-07:00

I discovered this for myself when attempting to do some home networking-related programming (UPnP/DLNA, mDNS/Bonjour all rely on multicast). Multicast sockets in Android simply don't work. You can read the full description of the issue here.

I was pretty surprised to see this, especially given that the underlying OS (Linux) definitely supports it. I guess it's understandable that the primary focus is on cellular networking at this point, but if Android devices have Wi-Fi, this is a huge omission. Given the iPhone's strong connection to the digital home, you can bet Apple isn't making it a low priority - in fact a number of applications have been built using Bonjour for the iPhone already, even before it was officially supported in the SDK.

So yeah, this is my excuse for not submitting anything to the Android Developer Challenge...

Don't You Dare Ask for My Mobile Password More Than Once!

2008-04-27T16:52:00.000-07:00

As more apps go mobile, the potential for the abuse of those apps' users grows. One of my biggest pet peeves in this regard is mobile apps that assume it's just as easy to enter your credentials on your phone as it is on your PC. This is a huge error in judgement as the mobile user experience is already fragile and throwing up barriers risks alienating some very tenuous connections. I'm probably more patient and savvy than your average mobile user and this just kills me.

With the current de facto web standard of email/password, there's quite a bit of typing to do (even if you're on an iPhone!). This doesn't bother me that much, but I'm grateful to those apps that pre-populate the user/phone field or otherwise are considerate of the fact that I am on a mobile device. What does really burn me is apps that are frequently asking me to re-enter my password or don't save text that I've typed in the past.

An early version of the J2ME GMail Mobile app would ask for my password whenever communication with the server failed. (No this isn't an authentication failure, it's a network failure!). Another problem was that the entered password wasn't persisted until I explicitly exited the app, which I never did. This meant I had to re-enter my password whenever I powered my phone off and on. I don't think either of these were bugs as much as they were design issues that neglected to focus on the users' intentions. At this point, it seems like GMail Mobile is content to have you just enter your password once.

Last time I used it, GMail's mobile web interface had the same policy as the regular web interface - a successful login drops a cookie on your browser that expires in 2 weeks. This means that every 2 weeks I have to type in my full password on my tiny little mobile keypad. Multiply this by the number of mobile apps you use and you have a recipe for a very frustrated user.

On the other side of this, because mobile phones are arguable more personal and less secure than PCs, maybe app designers should be forcing more frequent authentication. How many times have you or a friend lost a phone on the bus, had it drop out of a pocket, or otherwise enabled the possibility that it falls into the hands of someone who decides to use it to access your personal information?

Maybe the best solution here is just to add a password lock to your phone and make sure it works out of the box. Sooner or later, people will get the message that your mobile phone is the best vehicle yet for identity theft and will put up with typing in a 4-digit unlock code. (Better yet, the next version of the iPhone should add a fingerprint scanner for use with the existing slide-to-unlock feature.)

In the meantime, please be considerate of your mobile users and design with these issues in mind!

The iPhone SDK is BREW Part Deux

2008-04-26T13:10:00.000-07:00

There should be little doubt in anyone's mind that the iPhone Store is a walled garden, albeit a very shiny and new walled garden. The SDK has been out for a while now, and people have figured out that there a lot of things you just can't do with it. The most obvious limitation is that Apple forbids applications that run in the background.

While there are obvious reasons for prohibiting these applications (security, battery life, performance, user experience), none of these reasons are very good. Fring actually resorted to releasing an app for Jailbroken iPhones, but you can bet this won't be available through the iPhone Store anytime soon. My own opinion is that Apple is not only protecting the iPhone's user experience, but also plans to add a lot of these interesting features in the future (VoIP, MMS, IM, etc.), and doesn't want third-parties to get in the way (unless Apple has a deal with them).

I stand by my first-blush statement that the iPhone SDK is more polished and professional than the Android SDK. If you're looking to build a game or a way to access your interactive web app, you'll be very happy. However, if you want to build an innovative new category of application that relies on background processing, you're out of luck - you should go with Android, Windows Mobile, Symbian, or maybe (gasp!) even BREW.

Background applications are easy to build in BREW, which might make you think that BREW is more open than the iPhone. As long as you get the permission of Qualcomm and the carrier you want to deploy on, these applications are allowed. On the other hand, the BREW APIs are clunky and feel like they were designed by hardware engineers, while Apple's APIs are well reasoned, aside from being tied to Objective-C. (I don't have anything against hardware engineers, I just don't think they should be writing software.)

The irony here is that of the current distribution models, the iPhone Store most closely resembles the BREW model, though BREW is much more closed. BREW has more, higher fees (registration, testing, etc.), while Apple has just a $99 or $299 developer fee. Apple gives the developer 70% of the retail price, while with BREW the revenue share is a complicated dance. Overall, the iPhone store should be a boon for developers compared to previous distribution models. While it's not as open as pure web-based deployment it does have the benefit of handling billing and putting your application in a common catalog where it should be easy to find.

Will New E-Ink Controller Lead to Less Sucky Kindles?

2008-04-23T21:19:00.000-07:00

E-Ink is a unique display technology that relies on reflectivity rather than backlighting like LCDs. While the technology has been in development for more than a decade, its adoption has been slow due to production issues and its Achilles' heel: slow refresh rate (500-1000 milliseconds).

Refresh rate and flashing has hindered E-Ink's use in highly interactive applications to date. In my opinion, Amazon's Kindle is unusable due to the interface kludges perpetrated on the design in an attempt to work around these issues (though there are a lot of unrelated design flaws as well).

A new version of the E-Ink display controller is claimed to have refresh rates similar to those of an LCD (15 milliseconds or 66 frames per second). If these claims hold true we should see new versions of the Kindle and other reading devices with vastly improved usability. Add color and E-Ink might be able to compete with LCDs someday.

The New Mobile Fragmentation

2008-03-06T20:46:00.000-08:00

The past few days have seen some pretty big announcements in the mobile platform space.

Nokia is putting Microsoft's Silverlight on S60 and S40 phones.

Google announced its first mobile port of Gears - to Windows Mobile.

Steve Jobs rejected Adobe Flash as being too slow for the iPhone.

Today Apple released the iPhone SDK. (My first impression is that it has a much higher degree of quality and completeness than the Android SDK, but I'll withhold a full judgment to another day.)

Then of course there's Yahoo Go 3.0, Google Android, and some other lesser comers as well. What all this points to is even greater fragmentation than the mobile space has seen in the past. Of course there will be a shakeout eventually, but over the next few years there will be a lot of options for mobile developers. Choosing which platform to develop for will be even tougher than in the past since these new platforms offer a broader variety of approaches - web-based + offline, declarative + script-based, Java-based. On the upside, this should make it much easier to get apps deployed onto some phone. On the downside, with all of these options, J2ME fragmentation is nothing compared to what's coming.

Modu Unveiled

2008-02-11T12:51:00.000-08:00

After an interesting teaser video a few weeks ago, Modu Mobile has unveiled itself. The basic idea here is that a Modu device forms the core of a mobile phone and can thus be swapped into new devices as the user desires. This is somewhat reminiscent of the Wildseed SmartSkins platform except that it slims down the core to a tiny credit-card sized device that can fit inside many different form factors.

I think Modu has a chance at gaining some acceptance by phone OEMs/ODMs as a way to reduce development times and certifications costs. It also neatly solves the phone upgrade data-migration problem which so many people have now. Of course, there's probably a limit to how many times you can upgrade the carrying device before the Modu core becomes functionally outdated.

The teaser video intimated that you would be able to slide Modu into other devices like cameras, cars, and media players, thus personalizing that device with your data and wireless connections. I think this is a neat idea, but an impractical one. The first problem is usability as it implies that a user will be swapping the Modu core in and out among a number of devices. This seems awkward and neglects those scenarios in which two devices are active at once. The second problem is getting device manufacturers to commit to building this hardware interface into their products. Unless you're a brand like Apple (and are able to convince these OEMs to ignore the fact that you're competing with them), this is a tough sell.

There are two core ideas at work in Modu, both focused on personalizing devices that you use. Data personalization makes your personal data available on any device. Companies such as Realm Systems have built personal server devices with this core idea in mind. Network personalization is at the core of the personal router - a great idea whose time has yet to arrive, though if you've ever tethered your laptop to your mobile phone using Bluetooth you've got the basic idea.

I believe personalization is incredibly important for the coming age of consumer computing which is moving away from the PC and towards the mobile device. People will use a full-featured mobile device for most of their daily communication and information retrieval operations. Other devices will become task- or location-specific adjuncts throughout the course of the day. If you need to compose a document, sit at a workstation "PC". If you want to enjoy viewing friends' movies and photos, lounge in front of the home theater system. When you're in the car, your content should be available at your fingertips without thinking too much about it.

A lot of this personalization is already being delivered today through the web, but as the range of devices and interactions becomes broader today's web looks less viable in this world (How do you present an HTML page on a device that has no display?)

I have some strong opinions about how such a (software-based) personalization system will operate. If you're an investor or entrepreneur that thinks this space is as compelling as I do, ping me and let's chat.