Homepage: www.whit537.org           Email: chad@zetaweb.com

Thursday, April 10, 2008

Simplates, biblical Greek on Google App Engine

I scored a preview account on Google App Engine (GAE). Before I say anything else, let me say congratulations to the team at Google that pulled this off. THIS IS UNQUESTIONABLY REALLY FREAKING AWESOME. The rest of us can now write programs for The Google. In Python. WOW. Nothing I say below should detract from that baseline awesomeness.

So after getting "Greetings, program!" to work, I looked at porting gheat from Aspen to GAE. Unfortunately, the Python library available doesn't include PIL, so that was a quick dead end. I'm sure they will add PIL and other common third-party C extensions eventually. And lest you think I'm disappointed, remember: I AM WRITING A PROGRAM TO BE RUN ON THE GOOGLE. AND I'VE GOT ALMOST THE ENTIRE FREAKING STANDARD LIBRARY.

So I decided instead to port a text-based project, which I'm calling "Bibligon" (it was previously called Textus but that name is taken on Google; the error message indicates that app engine apps actually share a namespace with Google accounts). Bibligon is a hack I did while taking a biblical Greek class last spring. It's a way to annotate a fixed text down to the character level. The original was written using Django simplates, served by Aspen. GAE bundles Django(!), and Bibligon is an app that would grow lots of data quickly if it were actually used, so it seems like a good fit.

Porting Bibligon to GAE makes me appreciate all over again why I wrote Aspen and Simplates in the first place. For example, GAE's filesystem layout is nasty. You've got scripts that depend on Python modules being in a certain location relative to them. You've got nested Python paths. You've got Python files and static files and template files and configuration files and framework files and user files all jumbled together willy-nilly. Why not use something like virtualenv to keep it all straight? (Caveat emptor: I AM PORTING MY APPLICATION TO THE GOOGLE. THIS IS UNREMITTINGLY AWESOME.)

I also found the development server annoying. A couple of issues were peculiar to my setup. I develop on FreeBSD from Windows via VMWare. Due to a bug in VMWare, the connection hangs every so often, and I have to restart the network interface on FreeBSD. With Aspen, I just refresh the page I am working on and it immediately clears the now-dead socket. GAE uses BaseHTTPServer, though, and I have to go kill and restart the server process before I can connect again. It's probably a socket timeout setting or something. Another quirk of this setup is that I can't just bind to localhost because I'm not hitting the server from localhost. I have to bind to the server's external address. Aspen does this by default if no address is specified, but not so BaseHTTPServer. Not a big deal, as there is a command-line switch. (AND DID I MENTION THAT I'M DEVELOPING APPS FOR THE GOOGLE? IN PYTHON?)

A few other dev server warts are more general. Even though GAE supports WSGI, requests are more or less wrapped in CGI. This means that anything you print shows up in the browser, before the response headers. You have to use the logging module to see things in the console. That's not so bad because you really do want to use logging anyway to take advantage of the GAE dashboard's log browsing interface. But this also breaks PDB; set_trace() just gives you BDBQuit in the browser. Moreover, they decided to use cgitb to display tracebacks, which means you have to scroll through tons of undifferentiated purple to see the actual error, which is at the bottom of the page. I also have to hit F5 twice to reload a page, but this could be related to my setup. I haven't yet done all the digging I could on these issues, and besides that, I HAVE A LOCAL COPY OF THE GOOGLE RUNNING ON MY LOCAL MACHINE, LOCALLY SERVING THE APPLICATION I AM LOCALLY DEVELOPING FOR DEPLOYMENT ON THE GOOGLE.

YAML was a good choice for configuration. It's not too dissimilar from the handlers syntax in Aspen, and it's a standard. I would like to see a published API for accessing this configuration from my programs, though. (NOTE: I AM CONFIGURING PROGRAMS TO RUN ON THE GOOGLE.)

So my first impression? Google App Engine is kind of ugly. BUT THIS UGLINESS IS VASTLY OVERSHADOWED BY THE INCREDIBLE COOLNESS OF WHAT YOU ARE DOING—RUNNING PYTHON APPS ON THE GOOGLE—AND THE SHEER IMPRESSIVENESS THAT THEY PULLED THIS THING OFF AT ALL.

As far as actual code goes, I did get Simplates working. Since GAE bundles Django, I just had to add a main() function to the Django simplates module in order for it to be usable as a GAE handler script. I also tweaked the subpackage so it can be used apart from the rest of Aspen. If you want to play with it, svn checkout the simplates subpackage into your GAE project directory, and use 'simplates/django_.py' as your script handler. You'll also have to wire up Django and use a couple names that are hardcoded for now. Use the source and let me know if you want some pointers. (NB: THE POINTERS WILL BE FOR LOADING AND RUNNING DJANGO SIMPLATES ON THE GOOGLE.)

So with Simplates working, I'm ready to start on actually porting Bibligon. The Django and GAE data models are similar, and in addition to getting static files and simplates working, I've got my first piece of data posted. I should be able to get the whole thing ported in about a day. But unfortunately today is not that day. April 15 is looming large over someone who hasn't entered anything into QuickBooks for over a year. :^(

P.S. A QUICKBOOKS KILLER COULD POTENTIALLY BE WRITTEN AS AN APPLICATION RUNNING ON THE GOOGLE. YOU OR I COULD WRITE THIS APPLICATION, THE APPLICATION RUNNING ON THE GOOGLE, KILLING QUICKBOOKS.

P.P.S. And of course, the corporate techno-beast tightens its stranglehold on civilization, but waddya want?

0 comments: