"Responsive" Applications

One of the first development projects I’m doing with OpenGeo is putting together a GUI for data loading/dumping in PostGIS. The command-line tools have served the project well for a long time, but with such good GUI tools like PgAdmin available for all the other interaction with the database, it is a shame to have to head to the command-line to load a shape-file.

[PostGIS Loader GUI](http://www.flickr.com/photos/92995391@N00/3176884653/" title="PostGIS Loader GUI by pwramsey3, on Flickr)
Shape File Loader GUI

I’ve had a grand time learning GTK+ to build the GUI window, got it all laid out, and then spent some time re-working the output portions of the existing loader code so I could write into a database handle rather than to STDOUT.

I got everything hooked up, ran small small test cases (victory!) then got a big file, and hit the “Import” button and … everything froze for 20 seconds, then whoooosh all the logging information updated. What gives? Oh, right, I took control away from the GUI thread for 20 seconds while I was loading the data, then handed it back.

Mono uses GTK for their Linux widgets, and they have some good advice on how to build responsive applications – applications that stay usable and informative, even while doing computationally demanding tasks.

I thought I already knew the answer – I was going to have to put my loading process into its own thread and figure out all the joys of thread programming. I still may do that, but in the meantime I’ve implemented one of the other options the Mono project suggested. There is an “idle” event in GTK, which is thrown whenever the application has “time on its hands”. By breaking a large process into small chunks, and executing them during idle moments, the application remains responsive, and the work still gets done.

Is the application now “responsive”? I would argue, not really, it just seems responsive. But in this modern world, the appearance of a thing is usually just as good as the thing itself.

The code now looks a bit uglier though… instead of simply running the translation, the GUI moves through little stages: create the tables, load the first 100 features, the second, etc, finish the process. However, it’s now possible to stop an import mid-stream, and the logging information hits the window in real time.

Data For Decision

I have to blog this so the links are somewhere I can find them again! From Anselm Hook on Geowankers, links to the National Film Board of Canada 1968 short on GIS, “Data For Decision “, parts [1], [2] and [3].

Beep, beep, boop, boop, boop!

Another Change of Scene

Starting in the new year, I am going to be working full-time (well, slightly less due to child care needs) for OpenGeo, as the staff PostGIS expert. OpenGeo is best known as the home of GeoServer, but in the past year they’ve also built up a skilled team of OpenLayers user interface experts. So, architecturally, they’ve got a user interface layer, an application server layer, but what about database? To provide support for open source geo-applications, from database to interface, they want a database expert, and that’s where I come in.

I will still be available for PostGIS and Mapserver development projects, but the contracting agency will be OpenGeo now, instead of Clever Elephant. And in my gaps, I’ll be splitting my time between doing PostGIS development and marketing support for OpenGeo. (What’s “marketing support” mean? Material development, speaking, and blogging.)

I’m looking forward to having a bit more focus time for PostGIS, and also helping OpenGeo hone their vision of a pure open source geospatial company. As a “social enterprise”, OpenGeo has some financial flexibility in pursuing the audacious goal of a pure-play open source geo company, and some interesting productization opportunities that will be fun to work on.

Clarification (?): OpenGeo is a subproject of The Open Planning Project, which is in turn a part of the Lime Group, which is an umbrella for the many entrepreneurial pursuits of Mark Gorton (LimeWire is one of other members of the group). This Bloomberg article gives a good overview.

The Grey Lady gets her PostGIS on

The tech team at the New York Times has rolled out a geo-enabled application called “Represent “, and under the covers is a regular murderer’s row of open source technology. PostGIS, GeoDjango, GEOS, GDAL, and on an on.

What’s wrong with these guys, why aren’t they deploying using the market leading proprietary tools? My guess is, they just don’t know any better.

The real action these days is web application development, and the action there is in frameworks like Rails, Django, Drupal, Plone, and the like. What tools integrate better with those environments? What tools are developers using those environments likely to find and try on their own? Open source blooms in green fields. Looking at ESRI-dependent government agencies and wondering “where is the open source?” is like looking at the Bronx and wondering “where are all the flowers? “

From All Points Blog

Supportosaurus

This link to a 9m Clay Skirky talk showed up in the comments of my last post from the always-connected Allan Doyle.

</param></param></param></embed>

I really like the anecdote about trying to explain Perl support to C++ programmers. The idea that “support comes from companies, exclusively” seems imported from an earlier time, when the statement was literally true. Before the internet, the only reasonable place to get expert support (or quality software, for that matter) would be a largish company. Folks whose professional expertise was forged during that time seem, except for some freakish exceptions, to find it hard to mentally transition to the new order of things.