WSGI is the Web Server Gateway Interface. It is a specification for web servers and application servers to communicate with web applications (though it can also be used for more than that). It is a Python standard, described in detail in PEP 333.
For Ruby people WSGI is the Rack in Python. In fact it was one of the inspirations behind Rack. Rack descriptions itself as:
Rack provides an minimal interface between webservers supporting Ruby and Ruby frameworks.
Which I think is a clearer explanation, except in WSGI’s case we replace Ruby with Python.
As well as being able to write WSGI middleware for Django or Pylons we can also write WSGI middleware for App Engine applications - which is what I spent some time doing today. For the most part I found the examples and documentation interesting but overkill for what I needed to do. Specifically I wanted a piece of middleware which modified the response content, adding extra content into the response. Most of the examples I found didn’t focus on middleware, or where full blown examples making them hard to follow.
So for anyone looking for a simple example of WSGI middleware which adds content into the response here goes. I used the WebOb framework because it provides a nicer interface to the request and response objects and it’s included in the standard App Engine SDK. The following sample middleware simple adds Hello World to the end of every response.
pre. from webob import Request
class SimpleMiddleware(object):
“Example middleware that appends a message to all 200 html responses”
def init(self, app):
self.app = app
def call(self, environ, start_response):
# deal with webob request and response objects
# due to a nicer interface
req = Request(environ)
resp = req.get_response(self.app)
# add a string to the end of the body
body = resp.body + “Hello World”
# set the body to the new copy
resp.body = body
return resp(environ, start_response)
In reality you might want to append something to a specific place in the response, or introduce conditionals. This is easy enough to do by parsing the initial value of resp.body in the example above.
To use the middleware in your application you simple wrap your current WSGIApplication instance with the middleware class.
WSGI middleware is both a useful place for common functionality to live in your App Engine application as well as being a handy tool for anyone working across multiple Python frameworks to share code.
So JauikuEngine, the open source, App Engine based, version of Jaiku is now available for everyone to look at. I found the repo a couple of days ago but it was restricted to project members. The main reason I want to hunt through the code is to have a look at what I’m guessing will be API’s available in a soon to be released version of App Engine - with specific interest in anything to do with XMPP, queues and offline processing.
Well it looks like I’m out of luck for the moment at least. In the settings file I found the following two snippets though:
pre. #
XMPP / IM
#
Enabling IM will require a bit more than just making this True, please
TODO (termie): describe how to get IM working with Jaiku Engine
So termie, or anyone else on the inside, I’d love to know how to get this up and running?
I’ll be having a better look through the code when I get a chance. This was just the first thing I jumped on before heading out the door. I love Open Source.
Not sure how I missed this but apparently App Engine (as of 1.1.9) supports remote access to your live data store. This means you can create administration applications more easily by running them locally, rather than within the limitations of the live platform. You can even run a local python prompt with access to your live datastore which is pretty neat.
Building larger applications tends to mean splitting your codebase up some how into manageable chunks. I’m quite interested in what I see as different approaches in the Rails and Django communities:
Django tends to recommend building Reusable Apps and we have sites like Django Pluggables to catalog what’s available. You then grab a few of these applications from the web or write your own, add them run them all together as part of a single application. Pinax is probabaly the poster child for this approach. The 0.5.1 release for instance appears to have 41 individual reusable apps, many written by other people and projects.
RewiredState was awesome. 100 or so geeks plus a smattering of government types gathered in the shiny new Guardian offices in Kings Cross on Saturday to hack (the Government).
Some events like this are more productive than others, and the end of day demos included some realy impressive stuff. See for your self on the projects page
My own little project even won a prize (an invisible bottle of Champagne no less). My complain was that if you want to report an issue about the over 7000 government websites you have to do it per site. All of the sites do their own thing, which might be a nice contact form, maybe an email address or in some cases a postal address hidden on a page that’s not linked to from anywhere.
My solution was pretty simple - a centralised issue reporting and navigating tool. So you go along to the site you have an issue with and hit a bookmarklet (or a badge on the site if the site in question have been nice enough to add one). You fill in a very simple form which appears before your eyes and everything is tracked on a nice shiny website.
The advantage of all that is transparency. You can see which sites people have issue with, and also ideally which issues get addresses or at least acknowledged by the support staff for the site in question. The hack had comments so others could follow up on individual issues. It would be simple enough to have league tables and the like as well, or add tagging for a little bit of categorisation - I did only have a few hours though.
After a few nice comments I’m going to have to finish it off and get it up somewhere I think. All I really need to do is clean up the bookmarklet code (which was a hack in more ways than one) and add a bit of sanity checking to data entered into the system.
A massive well done to everyone involved is in order as well, especially James who I remember talking to the idea about ages ago. Congratulations all - and hopefully be back next year.
I find App Engine a great way of just writing (Python) code and putting it online quickly, and the presentation was aimed at being something of a fanboy ode. During questions afterwards we talked about some of the limitations and cases where App Engine isn’t as well suited, and at least a few people were heading off planning on having a play.
The event was good fun and I picked up a few Python related tips and tricks from the other presentations and general conversation. Thanks for everyone who organised and attended the event and to RealVNC for hosting the talks.
I’ve finally been getting round to doing a bit of work on dmigrations, the Python based database migration tool we developed at work.
dmigrations offers a simple but flexible way of managing changes to the database in your Django projects. It is a replacement for Django’s built in syncdb command.
I still have some work to do to merge in a number of modifications we’ve been running internally for a while but I’ve triaged the issues list that had been left alone for too long and merged in a fantastic collection of patches from a few people including Alexander Robbins and Chris Lamb. Thanks hugely to everyone for these.
Everything is available in trunk in SVN at the moment ahead of me cleaning a few thinks up and updating the download version. I’ve added a setup.py file as well ahead of hopefully adding it to the Python Package Index.
I obviously wasn’t the only one who had decided to do some work on the project in the last couple of days. msaelices has just submitted a patch which adds a PostgreSQL backend. I don’t tend to use PostgreSQL personally so if anyone does want to have a look at running dmigrations with the patch I’d love to hear about it.
I’ve been busy building and playing with various HTTP clients recently, mainly due to more playing with RESTful web services. I took a couple of hours out to build something to make my life easier - namely a very simple logging HTTP server in Django.
All the application does is accepts HTTP requests and log the results to a file. I’ve been using it to make sure the requests I’m sending from elsewhere are correct, before pointing the client at a web service that actually does something useful. It supports POST, GET, PUT, DELETE, etc. So far so simple.
I ended up using Django mainly because I did most of the work on the train, and I know my way around it pretty well by now. I did originally thing it might have been better to use something simpler but I did end up learning a few new tricks that I’ll use for future projects.
In theory Django doesn’t need a database. While this is true for the most part, the in-built test runner does require a database. One thing I’ve talked about before is the usefulness of creating your own custom test runner. If anyone else runs into this specific problem have a look at the nodatabase.py file.
The logging is handled via Python’s inbuilt logging module. It has some nifty features (like log rotation, maximum file sizes and different logging levels) but is a little fiddly to get working correctly. Tales abound of log messages appearing multiple times, or permission errors causing problems. At least for this project I think I have everything working. I’ll try using this module on a couple of other projects and maybe spin it off into a small reusable app.
For something that took only a few hours to write it was both good fun and a useful learning tool. And Django proved itself more useful that I though for smaller services like this.
I always enjoy reading things by Paul Graham, even if I’d like to be able to disagree with his conclusions on occasion. It’s not just that I love Hackers and Painters, but also he often says things like the following that make me smile:
hackers are much more constrained by gentlemen’s agreements than regulations. If they shake your hand on a promise, they’ll keep it. But show them a lock and their first thought is how to pick it.
His latest short essay concerns startup hubs again, something that I’m actually pretty interested in, end up talking to peopleabout, but hardly ever writing anything on. Mike over at Techcrunch Uk elicited some good comments last year with a post on the subject. As usual Graham focuses on the US, but what about translating his idea of buying a Startup Hub and applying it to the UK? He sets several criteria for success:
Do you have good weather?
Do people live downtown, or have they abandoned the center for the suburbs?
Would the city be described as “hip” and “tolerant,” or as reflecting “traditional values?”
Are there good universities nearby? Are there walkable neighborhoods?
Would nerds feel at home?
Lets assume for the moment that the idea would work. Take £15-20million and invest in 30 or so well chosen startups on the condition they move into town. The question is then: where in the UK would this be most likely to work? And are their any UK specific criteria that would increase the success rate?
Some people might be thinking “but no UK city is going to invest £20million in a scheme to encourage startups”. Leeds is doing just that. Or rather Yorkshire Forward are putting up £35million along with Leeds University putting up £31milion. What are they doing with all that money? They are going to build a big building with it - which is exactly what Graham says won’t work.
