zimki | all bloggers | admin login | recent entries for Steve Purkis
 
recent posts for Steve Purkis

GPX Parser for Zimki

Steve Purkis on Mon May 14 2007 17:51:21 GMT+0100 (GMT)

This is an edited version of a post I made earlier on my personal blog.

So, at the last Fotango hack day I finally managed to turn my JavaScript GPX Parser into a Zimki library - you'll find it in my new code repository: http://code.spurkis.org/. Yes, it's free to use & source is available under the LGPL.

It doesn't do much more than turn GPX files into GPX objects (with an option to set the minimum distance between track points so you don't inundate yourself with useless information), and I've only made the server-side JS available for the moment - if you want to see it in use on the client-side, see http://www.spurkis.org/maps, it should handle both GPX 1.0 & GPX 1.1. While it does have unit tests for both versions, I've only used it with the traces made available from my Garmin Venture Cx so far, which annoyingly only lets me get at traces, not waypoints et. al.

Using it is pretty simple (or so I think ;-). Once you've got a Zimki account, create a new JavaScript instance in your dev realm that does something like:

zimki.library.require('code.staging.spurkis.org', 'gpxutils.js');

function handleGpxUpload(args) {
  if (args.gpxfile) {
    // uploading a new gpx File
    zimki.log.debug( 'uploading ' + args.gpxfile.filename );
    var file = args.gpxfile.save(args.gpxfile.filename);

    // then parse & store it
    var gpxContainer = newGPXContainerForFile(file);
    return '<html><body>uploaded & parsed GPX File: ' + args.gpxfile.filename + '</body></html>';
  }

  return <html><body><form method="POST" enctype="multipart/form-data">
   <p>GPX File: <input type="file" name="gpxfile" size="30"/></p>
   <p><input type="submit" name="submit" value="upload"/></p></form>
   <p><a href="/json.listGPX">json.listGPX</a></p>
   <p><a href="/json.getGPX">json.getGPX</a><em>?name=uploaded-file-name</em></p>
   </body></html>;
}

zimki.publishPath('/', handleGpxUpload);
zimki.publishPath('json.getGPX', handleJsonGetGPX);
zimki.publishPath('json.listGPX', handleJsonListGPX);

You can then go to http://your.realm.zimki.com/ to try it out. If all goes well, that'll let you upload/parse your GPX files as-is and list/get them over a JSON API.

As implied above, the client-side hooks that tie the JSON returned by the GPX API together with the online mapping providers (ie: Yahoo!, Google, Multimap, Mapstraction, etc. etc.) are not yet available. They will be as & when I have time.

Note: originally, I contemplated using Notions' GPX File Viewer but I got bogged down by a few things - I had to rename the GPX files before the browser would deal with them, and all the processing was done client side (ie: it wouldn't store my pre-parsed GPX traces for me). Then I considered porting it, but it doesn't use E4X (b/c it's corss-browser compatible), and it's also tied to Google Maps. So I decided to write this. But it's a good library for client-side JS, so if that's all you need then check it out. Really, I just wanted to play with Zimki a bit more… ;-)

Also, Andy Armstrong's Geo::GPX Perl module proved quite handy while implementing this. I've even nicked some of his test data to save me some time. Thanks Andy!

Anyways, if you do try this library out, let me know what you think!

read more / 0 comments

Measuring participation

Steve Purkis on Mon Apr 30 2007 16:01:47 GMT+0100 (GMT)

During the gaps in the booth schedule at Web 2.0 Expo, I managed to see a few good talks. One of the ones I was most impressed by was a combined keynote presentation on measuring participation in websites by Bill Tancer of Hitwise, and Dave Sifry of Technorati. It's a shame the slides aren't up yet, but check out the notes Dave posted to his blog.

I found it cool to see how participation inequality (aka the 1:9:90 rule, which suggests that only 1% of users participate regularly, 9% rarely, and 90% never) was being measured for sites like YouTube, Wikipedia, and Flickr. The demographics of contributors was also neat to see.

I've often wondered if the same inequality exists for development communities as well - my gut feeling says yes, though I've difficulty quantifying it. The one thing I can say is my experience in the world of Perl supports that conclusion: while anyone can upload a module of code to CPAN, few actually do. I don't think it's down to ability, as some have suggested down at the pub, but rather time & motivation. I've certainly worked with more people that could contribute useful modules to CPAN that just plain didn't have time, or couldn't see the benefit of doing so. But even though my experience supports this, due to the way CPAN works - FTP mirrors - it's near impossible to measure.

For Zimki, we're planning to build a Source Marketplace at some point in the future - while you can already share your code with other people, there's currently no way of advertising what you've shared without doing it on your own site. While this may work, I still believe it's useful to have a central place to advertise 3rd party libraries. There's also space for another 3rd party to evaluate & verify the libraries, and establish some way of measuring quality, and providing a feedback loop from the consumers of a library to the developer of a library.

Hopefully when we build a source marketplace for Zimki we'll be able to learn a few lessons from the way CPAN is organized, and give the Zimki community the ability to understand the level of participation.

read more / 0 comments

On Interface & Documentation...

Steve Purkis on Tue Feb 06 2007 11:37:30 GMT+0000 (BST)

We recognize that Zimki needs improvement in a few key areas: interface and documentation.

We decided to tackle Documentation first… mainly because we already have an interface that hundreds of people are using. To get started, we've been designing a new structure for docs.zimki.com with a focus on the API: our goal is to produce a full API reference, and several knowledge-base articles that make it easier for Zimki developers to get started with the current interface. In the future, we'll be expanding the knowledge-base articles, and adding tutorials and quick-start guides written from various perspectves. The first round of documentation is coming along nicely – we're looking at releasing updates in v1.10, hopefully only a couple of weeks away.

Interface is a big one… As it stands, we realize that it's not so fun to edit code in a text box that doesn't even have syntax highlighting! What we'd really like to do is turn the current development portal into a development IDE. So over the coming months, we'll be spending a lot of time designing & building a new version of the Zimki interface… We're quite excited about this!

Still, we also recognize that a web-based IDE isn't the right tool for everyone. That's why we've been developing off-line editing & synchronization tools in our copious amounts of spare time ;-). Tom's Trawler editor is one such app; in the near future we'll have an alpha release of Zync, a realm synchronization tool which lets you make use of your favourite editor and version control system.

read more / 1 comments