• Categories

  • Wayback Machine

  • My Defunct Podcast

    The Bungee Line was an audio podcast for web developers, covering web API's, software development, and the creation of richly interactive web applications.

    podcast feed  Main Feed

The Truth about Innovation Patterns


In “The Truth about Mobile Application Stores,” ReadWriteWeb’s Sarah Perez calls out several slides from Distimo’s MWC presentation about app stores. The short of it: Apple/iPhone leads by far; Google Android comes in a distant second (but growing fast); Blackberry and the others lag at the edge of irrelevancy.

It’s fascinating to compare and contrast Apple and Google in this context. Their approaches are both so different.

Apple has a first-up innovator’s edge over all the other players. They are vehemently proprietary, fanatical about UX, and notorious about privacy. Re-order the adverbs however you see fit, people still love what they produce.

Google pushes an open, webby agenda. It’s chock full of good will, freedom of information, and the gift economy ethos. Real or ruse, people still love what they produce.

In the post-Microsoft reality, only the absolute best of the proprietary can lead, as Apple demonstrates. The “the wisdom of crowds” crowd follows, quickly gobbling up the Good Enough gap so that everyone else scrambles to stay in place.

So, aspiring tech companies, what fits you best? Do you have the guts to be radically open? Or, do you have the intensity to be fanatically dedicated to quality of user experience to the point that your CEO lives outside of the boardroom and executive bathroom? Or, would you prefer the third option, mediocrity?

Add USGS Geologic Units to Google Earth on your iPhone


Google Earth example screenshot from iPhoneThe United States Geological Survey’s website provides map downloads of geologic unit data. You can download and view these files in Google Earth. This makes Google Earth a “killer app” for geologists, paleontologists, and other earth sciences explorers. What an amazing resource for understanding and exploring the surface rocks of a given area!

My partner Heidi and I love to camp and explore areas in which the terrain may have fossil bearing rocks. So, we use Google Earth on my Mac to do a lot of our planning. Once out in the field, I like to have the same data on my iPhone, too. But that’s a bit tricky.

Here are some tips and tricks that I have learned about using USGS data.

USGS data, KML files, and Google Earth

KML files

The USGS digitizes geologic units in Keyhole Markup Language (KML). KML is a text format that uses an XML schema originally created by Keyhole, Inc, the original creator of Google Earth. (Google acquired Keyhole in 2004.) Google Earth is free–meaning there is no financial cost to download and use it–and can open and render KML files. (An alternative to Google Earth is the Free Software project called Marble.)

KML file extensions: .kml or .kmz

screenshot exampleKML files can get quite large, especially when it comes to mapping a whole state’s geologic terrain. For that reason, KML data is frequently found in a compressed (zipped) version with a .kmz file extension instead of .kml. Both are referred to as KML files. Google Earth can use .kmz files directly, without being first unzipped.

Getting the USGS KML File for Your State’s Geologic Unit

The USGS provides geologic unit data for each state on their website as KML files. Open one in Google Earth, and each geologic unit’s regions display as opaque colors layered atop the terrain. Zoom into an area and click one of these colored units open a balloon showing the info contained in the KML for that unit. The data is pretty lean, but the Detailed Information link in it will take you to the USGS web page containing more information.

Using USGS Data on the iPhone

Can you put USGS data on your iPhone? Yes.

I have found a couple ways to do this, each with its pros and cons.

There’s an App for That

The App Store has a series of applications from Integrity Logic called “Geology,” plus the state two-letter code. For example, Geology UT is the app for Utah.

This is essentially one of those apps that just re-packages public domain data. What makes Geology UT any different from Geology CA? Essentially, it’s the data (USGS, mainly) bundled with the app. At $7.99, it’s not too steep for the functionality it provides. Unfortunately, Integrity Logic has yet to update it (despite having graciously thanked me for providing several ideas for enhancement).

To be sure, this app is not nearly as slick as Google Earth. The main advantage of using this app is that it works offline (unlike Google Earth), and includes descriptive data from the USGS website that is not in the USGS KML files. If you work in the field, far from a cellular signal, I definitely recommend this app.

Using KML Data on the iPhone in Google Earth

To be sure, Google Earth on the iPhone presents a challenge when it comes to using KML files, but by no means an insurmountable challenge. Here’s how to make KML data usable through the iPhone edition of Google Earth.

Requirements

* A Google account
* Google Maps (maps.google.com)
* A Computer with Google Earth
* An iPhone with Google Earth on it
* USGS KML file

Overview

You’re going to use the Google Maps feature called “My Maps” to import the KML file. Then, you can use Google Earth’s My Maps feature on the iPhone to see the data.

There are a couple inconvenient issues to get around. First is the 10MB maximum file size that you can import. This restriction applies to the uncompressed file size, which may prevent you from importing. The .kmz for Utah is 6.9MB, but it contains 25MB of data when uncompressed. Second is the default opacity of the data layers. These big, opaque shapes mask the underlying terrain, which is inconvenient. I’ll show you how to get around both of these obstacles.

Steps

  1. Download the USGS KML file that contains the data that you need.
  2. Open the file with Google Earth.
    • All of the geology data will display on the landscape in numerous opaque layers. It will also display in the left-side Places navigation.
  3. Right-click the unit that you want to add to your phone, and select Get Info from the menu.
  4. Now, go to the Style/Color tab and set the opacity to 50%. (Also, you may want to change the color to something that will show up well in Google Maps, given the iPhone’s small display.)
  5. Once you have set the color and opacity to your liking, you can export that unit as its own, self-contained KML file for that unit. Right click the unit again and choose Save Place As… and give your file a name. This should yield a file that is well below the 10MB import restriction imposed by Google Maps.
  6. Now open a browser and go to Google Maps. (Make sure that you have logged in with your Google Account.)
  7. Click the My Maps link (on left, near Get Directions).
  8. Click the Create new map link.
  9. Create the Import link, and upload the file that you saved from Google Earth.
  10. Before clicking Done, consider whether you want this map shared. (Google Maps will default to Public.)
  11. After clicking Done, you will see the geologic unit in Google Maps. (If it appears to be incomplete, scroll down through the list of elements at left, and you’ll see why: Google splits the list into multiple pages. Google Maps is not very good for viewing numerous polygons that often comprise a geologic formation.)
  12. At last, it’s now time to get your iPhone and open Google Earth.
  13. Click the Options button (i) in Google Earth.
  14. If you have not already done so, log in with your Google account. Once you have, you can use My Maps to enable the map you just imported into Google Maps.

And with that, you have brought USGS geologic units onto your iPhone.

On API Replication and Web App Compatability


Commandeering Applications by Replicating APIs

I recently met with Jesse Stay to discuss some plans and ideas I have been working on at Mozy. As expected, Jesse’s insights and feedback were tremendously valuable. (Thanks, Jesse!)

Tweetie API endpoint config on iPhoneOne of the items Jesse directed my attention toward was the recent implementations of the Twitter API by three different sites: WordPress.com (the host of this blog), Tumblr (another popular blog hosting service), and identi.ca (a prominent Twitter alternative which has supported the Twitter API since 2008). By providing 100% API compatibility with Twitter, people can use any application built for Twitter with these other services (as long as the app allows you to modify the service URI/endpoint it uses). Because services survive or wither based on use, supporting a popular and relevant API can instantly yield a slew of applications to support users better. As a result of their work, WordPress.com has gained applications like the iPhone application Tweetie. Although many of the applications for Twitter currently do not allow you to modify the API endpoint (Tweetdeck, for example), most developers want more users, and API-level compatibility makes it short work for developers to support your service. I suspect that soon, nearly all applications created for Twitter will let you modify or add to the default API endpoint.

This got me to thinking about GroupWise, Novell’s strong alternative to Microsoft Exchange.

Novell: Align with Google for Developers

Novell GroupWise has a complete web API, and has for quite some time. Unfortunately, Novell seems to neglect developers these days–especially in their legacy products (as evidenced by GroupWise having only a SOAP API). Aside from their list of close partners, few developers use the GroupWise API.

Google Code logoMeanwhile, with Google’s enormous cachet with developers, numerous applications support Google’s collaboration-related APIs (such as Contacts). Perhaps even more importantly, developers can easily integrate Google’s API into new and existing apps through the numerous source code libraries available for Google’s various API’s (again, see Contacts, this time for the list of libs). Google’s Atom-based REST API’s are popular, well-understood, and widely used.

Consequently, Novell has an opportunity to serve their dwindling fan base better: replicate the Google API’s that are most relevant to GroupWise. Make it so that developers can easily adapt their apps to serve GroupWise, and so that end users can select from a wider assortment of 3rd party apps. This would give nothing over to Google that they don’t already have. It can only increase the relevance and extend the life of Novell’s venerable old product.

It also makes it possible for Novell to get on board with the biggest technology trend of the latter half of the last decade…

GroupWise in the Cloud

Since my time at Bungee Labs, I have been considering how Novell could offer GroupWise as a hosted SaaS offering as a way of acquiring aspiring new companies. As Salesforce has shown well, small is beautiful, and there is big business in the “No Software” proposition. This is where GroupWise competes (entirely ineffectively) with Gmail (“Google Mail,” actually) and its related collaboration components. It’s very easy to set up a Gmail account that uses your own company’s mail@domain. You can’t do that with GroupWise today.

But GroupWise does have something that Google lacks: a rich client. With all the apps that Google enjoys, none do a complete enough job of unifying all the typical collaboration features of an enterprise collaboration suite. With legacy collaboration being such an unsexy subject in the age of the social web, it seems unlikely that Google will re-solve some of these relatively mundane features. Finally, although there is a de facto rule about “everything through the web,” that does not mean “everything in the browser.” GroupWise has browser-based access, but it also has a full client that works online as well as offline, giving Novell a complete end-to-end advantage.

So put it all together–SaaS + Google API compatibility–and Novell has a viable technical path for GroupWise. All that remains is to figure out a  freemium model that can viably compete with Google. (This is where I clock out.)

Note I realize that it’s kind of cheap to sit back and throw out directives for how some other company should manage its API strategy while sparing any mention of the company over which I may have actual influence. Some of the above thinking applies to our planning at Mozy. However, we do not offer a public API (yet), so it’s a challenge to directly discuss this subject without getting mired in caveats and cautionary or indefinite statements. If you have any more than a casual interest in where Mozy is heading with our API, please contact me by commenting on this post.

Google Chrome Bluescreened My Windows XP VM!


Google Chrome

…and in a sick way, it was really kind of cool.

I’ve been playing with Google Chrome for a couple days.

But because Chrome is only available (natively) for Windows right now, I have to run a Windows XP virtual machine on my Linux machine (which still runs openSUSE).

And since I hardly ever need to use Windows anymore, the VM needed several updates, see?

So, I’m a-browsin’ and a-updatin’, and really enjoying how well the browser performs–especially with AJAX–while wondering how much the snappiness will decrease when Chrome is laden with more full set of browser features…

…and then Windows Update completes its work and tells me to reboot.

So, I click the “Close” option and skip the “Restart” so that I can do a Shutdown-and-Apply-Updates instead, because that’s how I want to do it, see?

But Chrome doesn’t want to close down. In fact, it stops responding altogether. Now Google Chrome is in a stare down with Windows shutdown.

Well, you know what Windows does to programs that don’t stop. That’s right, it puts up dialog messages. This one essentially says, “He don’t wanna go, boss. Can I kill’im?”

But before I can even respond, Chrome frickin’ blue screens Windows. As the kids say these days, >Snap!<

Next thing I know, I’m watching the VMware POST process emulation, and hoping that my VM is not hopelessly corrupted.

Good old nostalgia…I haven’t seen a Blue Screen of Death on my own machine in ages.

Heading to FOSScamp!


FOSSCamp is coming up on December 5 & 6 at the GooglePlex, and I just got cleared to attend.

FOSSCamp is an un-conference designed to get different Open Source projects together to discuss how to work together in different ways.

Several of my friends and fellow followers of Free Software will be attending the event. I hope to have a lot of discussions regarding some ideas I have been working on around choices for Free Software licenses.

If you’re planning to attend FOSScamp, too, please leave a comment.

FOSScamp Facebook Event

Google Chrome’s Evil User License Agreement


Google’s first EULA for Chrome:

Then, they back off:

Perhaps heard in the hallowed halls of the Googleplex:

  • “You mean, somebody actually reads those things? Dang.”

Most interesting will be Chris DiBona‘s response. I suspect that it was a dumbshit in Google’s legal department rather than actual evil intent, but as I write this, I’m suspect that a million paranoid trolls are pecking out the complete works of Shakespeare in blogcomment pentameter.