The first step was to set up an XML-RPC server to serve remote calls to the pygeoip API. This was fairly easy to do using Python’s SimpleXMLRPCServer class:

from SimpleXMLRPCServer import SimpleXMLRPCServer
import pygeoip
...
# Create server
server = SimpleXMLRPCServer((ip, port), allow_none=True)

The location-lookup methods within the pygeoip library must be registered for use via the XML-RPC server. We first initialize a GeoIP object, passing it the filename of a valid binary GeoIP database. Then the GeoIP object is passed to the XML-RPC server’s register_instance method to expose its methods for remote execution:

# Initialize and register GeoIP object
gi = pygeoip.GeoIP(geoipdb_filename)
server.register_instance(gi)

# Run the server's main loop
server.serve_forever()

The lookup methods of pygeoip can now be called remotely. To demonstrate my project, I wrote a script that fetches the IPs of all nodes in the distributed computing network that you’ve allocated, looks up their lat/lang coordinates, and plots them on a Google map. For funsies I used the geolocation API built into Firefox 3.5+to include a pointer to the user’s current location.

Screenshot of project demo

Hopefully my little library will get some use. Moving into the new year, I’m hoping to increase my involvement in the Seattle project and become more familiar with networking and API design.

My initial implementation created a Javascript date object and compared the results of its getUTCDay, getUTCHours, and getUTCMinutes() functions to the developer-specified warning times. If the current time was greater than the set warning time, the banner was displayed. There’s some cookie-handling in there so that the user can close the warning banner and not have it show up until the next warning time, but no bother.

A potential problem arose in that Javascript uses the client’s local time to create date objects. Thus if the user’s computer had incorrect time, the warning banner wouldn’t display when it was supposed to. A better way to go about it would be to use the server’s time instead of the client’s.

Luckily I could make use of Mason’s preprocessor to insert the results of the Perl time() function into clientside Javascript to get the server time. I first calculate the client/server time difference and then use it to create an accurate date object inside the poll function.

// Determine delta between client and server times
var time_delta = (<% time %> * 1000) - Date.now();

function launchWarningPoll() {
    var d = new Date(Date.now() + time_delta);
    ...
}

As launchWarningPoll() gets called every 60 seconds, it will accurately portray the server time regardless of how much the user’s local time is off.

The app is built around a Markov processor assignment I had last quarter in a programming languages course. Essentially the program uses Markov chains and a binary tree of n-grams to generate random text based on word frequencies of whatever source text you feed it. In effect, the generated text is babble in the language of whatever source document you input.

I had a lot of fun playing with the program last quarter. I’d give it the history of America as a text file and get to read about English settlers crossing the Delaware under siege by the Confederate army. Or noticing how randomly-generated text in the language of the Bible wasn’t really any easier to read than the real thing.

After hearing about the Apps for America 2 challenge, I spent a few weeks scoping out datasets on Data.gov and thinking about ways to use them. I zeroed in on the XML files of US patent application bibliographic data and eventually connected the dots back to the Markov processor assignment.

The contest entry page for Eureka can be viewed here. All source code is available on GitHub. This includes some shell and Python scripts to validate and parse the XML, a Ruby port of my Markov processor (originally in ML), and the website frontend of the app.

“The people who are going to make money are the ones who are going to figure out how a guy who knows how to do something useful and doesn’t care about computer science can sit down and teach the damn machine to do something useful without having to spend four years learning to program.”
Jerry Pournelle

Good food for thought, to say the least. As a prospective computer science student, this both fascinates and worries me. On the one hand, the engineer in me is excited by the thought of creating this kind of uniformly-accessible development environment, but I also worry that if this were to come true, a degree in computer engineering would be worth that much less. I agree that programming and software development is currently somewhat of a walled garden. Anyone unwilling to spend countless hours learning the semantics and logic of seemingly meaningless code is left dependent on the output of those who are. However, it’s this specialization and difficulty of craft that leads to engineers’ high salaries. Cognitive dissonance FTL.

This week’s TWiT is definitely worth a listen, if this kind of thing interests you. They had some interesting things to say regarding natural language programming, too. It’s refreshing to FINALLY listen to an episode where they don’t spend 45 minutes talking about Twitter.

Imagine that you want to write a recipe for making peanut butter and jelly sandwiches. Imagine that the person you’re writing the recipe for has no idea what a peanut butter and jelly sandwich is, so you have to write explicitly what to do, step by step.

The resulting recipe would be very long and contain a lot of seemingly-trivial tasks that any idiot should take for granted like “find a jar in cupboard labeled ‘Crunchy Peanut Butter’” and “transfer a glob of peanut butter from the jar onto bread using a butter knife.”

To relate this example to programming, the person you’re writing the recipe for is a computer (compiler), the sandwich is a program, and the recipe itself is an algorithm. All a program is is a set of directions telling a computer what to do, step by step.

So, back to object-oriented programming… imagine now that you’re writing the same recipe for a person who knows a bit about the culinary arts. You won’t have to explicitly tell them every step. You’re recipe will be much shorter:

1. Get 2 pieces of bread, 1 jar of peanut butter, and 1 jar of raspberry jam
2. Spread peanut butter and jelly onto corresponding slices of bread.
3. Put two slices together.
4. Eat! (optional)

This is object-oriented recipe-making. You assume that the person knows what they’re doing and thus you can give higher-level instructions. In object-oriented programming, the program that you write takes advantage of already-written packages of code (called object classes), and allows you to tell the computer what to do without having to go into the nitty gritty details of every complex task.

In the sandwich example, the more complex steps of the second recipe can be abstracted as objects to be used in the sandwich-making algorithm.

Who said algorithms can’t be tasty?