Удивительное рядом:

           db.delete(Score.all())

исполняется на полторы секунды ДОЛЬШЕ чем лобовой способ:

             for score in Score.all():
                 score.delete()

На датасете из 1000 элементов в локальном варианте GAE. Я бы подумал, что это флюктуация, но результат воспроизводится с завидным постоянством.

Нативный GAE дэйтастор не умеет фильтровать строки по префиксу, как это делает, например mysql

SELECT * FROM foo WHERE bar LIKE 'prefix%';

Взамен этого в мануале предлагается следущий трюк:

db.GqlQuery("SELECT * FROM foo WHERE bar >= :1 AND bar < :2",
 "prefix", u"prefix" + u"\ufffd")

То есть, выбрать все значения которые лежат между префиксом и префиксом + наибольший unicode символ. В отсортированом по этому полю дэйтасете это даст как раз выборку по префиксу.

Учитывая, что он создает индексы для подобных выборок автоматически, должно быть довольно быстро.

Трюк, конечно, из разряда удаления гланд через анус (кроме того, непонятно, как матчить строки по постфиксу, или просто по вхождению), с другой стороны, надо попробовать такое в MySQL, может побыстрее нэйтивного лайка будет. Хотя, не исключено, что он именно так и реализован внутренне .

Stay tuned, сегодня–завтра будет пост по расчетам медиан на крупных выборках с профайлингом и т.п.

Google AppEngine’s datastore supports a variety of simple Types and Property Classes by default. However if we want to store something like a dictionary, we typically have to serialize it and store it as a Blob. On fetching we will de-serialize it. While this approach works, it is repetitive and somewhat error-prone.

Wouldn’t it be great if there is a SerializableProperty class that can handle this automatically for us? It doesn’t exist but according to this article, it is easy to create our own customized Property classes. So here is a simple implementation of SerializableProperty that worked for me:

import cPickle as pickle
import zlib
from google.appengine.ext import db

class SerializableProperty(db.Property):
  """
  A SerializableProperty will be pickled and compressed before it is
  saved as a Blob in the datastore. On fetch, it would be decompressed
  and unpickled. It allows us to save serializable objects (e.g. dicts)
  in the datastore.

  The sequence of transformations applied can be customized by calling
  the set_transforms() method.
  """

  data_type = db.Blob
  _tfm = [lambda x: pickle.dumps(x,2), zlib.compress]
  _itfm = [zlib.decompress, pickle.loads]

  def set_transforms(self, tfm, itfm):
    self._tfm = tfm
    self._itfm = itfm

  def get_value_for_datastore(self, model_instance):
    value = super(SerializableProperty,
        self).get_value_for_datastore(model_instance)
    if value is not None:
      value = self.data_type(reduce(lambda x,f: f(x), self._tfm, value))
    return value

  def make_value_from_datastore(self, value):
    if value is not None:
      value = reduce(lambda x,f: f(x), self._itfm, value)
    return value

Usage is as simple as this:

class MyModel(db.Model):
  data = SerializableProperty()

entity = MyModel(data = {"key": "value"}, key_name="somekey")
entity.put()
entity = MyModel.get_by_key_name("somekey")
print entity.data

Hope that helps!

Update (20091126): I’ve changed db.Blob to self.data_type as suggested by Peritus in Comment. The same comment also suggested a JSONSerializableProperty subclass:

import simplejson as json
class JSONSerializableProperty(SerializableProperty):
  data_type = db.Text
  _tfm = [json.dumps]
  _itfm = [json.loads]

Thanks Peritus!

Gae: anche conosciuto come il Mito. Straordinario e stravagante…

The very first version of my site: http://your-day.appspot.com/home.jsp

It’s like a Twitter but pictorial.

You can log in there with your gmail account.

Current set of features is very basic now:

- search for users (search by “Alex” to find me)
- follow/unfollow a user
- simple statistics
- filling your timeline

I will work on it further on but it is really interesting to know your feedback.

It looks like this:

Ah, and please use FF browser for now since I have not yet tested it under anything else. Myabe it works under IE/Chrome/etc. as well, just don’t know

Any feedback in comments would be great to have.

Continuing on with our middleware series, we now cover authentication. There are a ton of authentication and authorization WSGI middleware, as well an basic authnetication example used in the WSGI documentation. Some are out of date, and a lot of others are tightly integrated with other parts of a particular frameworks request handling. It would have been easy enough to RollYO basic authentication, but I really hate reinventing a wheel I don’t have to.

I decided to investigate AuthKit, part of Pylons, to service my authentication needs, and struggled through a lack of documentation and fairly large code base, all for your pleasure.

Authentication with AuthKit

AuthKit assumes a lot of the setup for your middleware follows Pylons conventions. It was a struggle for me to make heads or tails of the examples, not being familiar with Pylons application configuration and how requests were routed. The secret sauce to actually make AuthKit work with bottle is to realize that there are actually multiple levels of AuthKit middleware that you have to invoke to get the authorization chain to even start up. Here is how you go about it in Bottle:

from authkit import authenticate, authorize
from authkit.permissions import RemoteUser

from bottle import *

# bottle exposed function
@default() # maps to root URL
def hello():
    return "hello"

# get the default bottle application
app = default_app()

# set up an authorization permission for
# basic authentication of a remote user
app = authorize.middleware(app, RemoteUser())

# A simple authentication function
def basic_auth(environ, username, password):
    return username ==  password

# now activate the authentication
auth_config = {
    'authkit.setup.method':'basic',
    'authkit.basic.realm':'Test Realm',
    'authkit.basic.authenticate.function':basic_auth,
    'authkit.setup.enable':'True'
}
app = authenticate.middleware(app,app_conf=auth_config)

# run the application
run(app=app)

To make this work for App Engine, you need to include the AuthKit sources and account for deploying Bottle applicatios on GAE, covered in the Bottle docs and other posts.

Bottle is a great little Web application framework, but in it’s quest for simplicity, it left out a couple of key components that are needed for cu3w0rx: HTTP method overriding and basic authentication. Luckily Python’s WSGI middleware can fulfill this role.

WSGI Middleware

WSGI middleware is a handy way to add functionality to an application by adding layers to the request/response chain in between the client request and your application. Incidently, Ruby’s Rack project took inspiration from WSGI middleware.

Method Overriding

A while back I bemoaned the fact that CherryPy’s RoutedDispatcher could not handle PUT and DELETE requests from forms submitted by your typical web browser, which most often only does GET and POST requests. I submitted a patch to the CherryPy project, but I now believe that this is the wrong approach, and that middleware can handle altering the REQUEST_METHOD header in response to a submitted form with a hidden “_method” parameter, as is the accepted convention. Here is some middleware for the server side application which will resige on GAE:

# method_overide.py
# WSGI middleware to set the HTTP REQUEST_METHOD header from a submitted form
# that contains a "_method" hidden variable.

class MethodOverride(object):
  def __init__(self, app):
    self.app = app

  def __call__(self, environ, start_response):
    method = webapp.Request(environ).get('_method')
    if method:
      environ['REQUEST_METHOD'] = method.upper()
    return self.app(environ, start_response)

And here is how you would insert it in between your bottle application:

from bottle import *
from google.appengine.ext.webapp import util
from method_override import MethodOverride

@route("/test_put",method="PUT")
def testput():
  return "PUT success"

@route("/test_delete",method="DELETE")
def testdelete():
  return "DELETE success"

# run in GAE
def main():
  app= default_app()
  # insert the method override middleware
  app = MethodOverride(default_app())

  util.run_wsgi_app(app)

if __name__ == '__main__':
  main()

Now forms that define the REQUEST_METHOD as a hidden param “_method” will be routed to the correct function.

Muy acertada la propuesta que hacen en Halón Disparado. Un canon como el de la $GA€ pero para los políticos:

Propongo, pues, la implantación del Canon Municipal, que supondrá que todos los alcaldes (y concejales de urbanismo) de España deben pasar X días en la cárcel, para compensar los posibles delitos de corrupción que hayan cometido o estén en disposición de cometer. El número de días podría calcularse en función del presupuesto del Ayuntamiento y de los metros cuadrados recalificados a urbano en su legislatura.

Seguro que Bartomeu Muñoz, alcalde socialista de Santa Coloma de Gramenet, entiende y comparte el espíritu de esta propuesta, no en vano fue premiado por la $GA€ por ser “el político más comprometido en la lucha contra la piratería”. Seguro que este individuo, imputado ahora por cargos de cohecho y malversación de fondos, habría pagado gustoso el “Canon Municipal” para evitarse los actuales problemillas con la justicia.

Y ahora que lo pienso, el premio que le concedió la $GA€ ¿sería merecido o un quid pro quo? Investigue Garzón, investigue…

One of the great aspects of CloudCrowd is that the code base is so small and readable. A big part of that comes by virtue of using the Sinatra Web application framework for the master and slave daemon processes. Sinatra is much closer to the GAE webapp framework than CherryPy (by default), in that you define methods that correspond to the HTTP verbs (GET, PUT, POST, DELETE and HEAD). Sinatra differs in that the method’s first argument is the route that the method services. The GAE webapp framework instead forces you to define a class that the defines the HTTP verbs, and later map those classes to some route. Let’s take a look at “Hello World!” to illustrate the difference. Here is the GAE webapp version

from google.appengine.ext import webapp
from google.appengine.ext.webapp.util import run_wsgi_app

class HelloWorld(webapp.RequestHandler):
	def get(self):
		self.response.out.write("Hello World!")

app = webapp.WSGIApplication([("/",HellowWorld)])

def main():
	run_wsgi_application(app)

if __name__ == "main":
	main()

Now here is the version in Sinatra:

require "rubygems" # RubyGems is optional, depending on your setup
require "sinatra"
get '/' do
  "Hello World!"
end

Much more readable and concise. Here is a version of HellWorld in CherryPy, using the default MethodDispatcher, for comparison:

import cherrypy

class HelloWorld:
    exposed = True
    def GET(self):
        return "Hello World!"

app = HelloWorld()

d = cherrypy.dispatch.MethodDispatcher()
conf = {'/': {'request.dispatch': d}}
cherrypy.tree.mount(root, "/", conf)

Better, but you are still separating the the mapping of the root URL “/” to the HelloWorld class outside of the class. I started digging around the interwebz for Python frameworks that would work closer to the lightweight Sinatra and found Bottle. Bottle is small, self-contained and uses python decorators to map a function to a route. Brilliant. Here is the example using Bottle:

from bottle import route, run

@route("/") # assumes GET method
def hello():
	return "Hello world!"

run() # This starts the HTTP server

Now that’s what I’m talking about! Deploying a Bottle application to GAE is covered in their documentation. We’ll be using Bottle for cu3w0rx to create the master and slave daemons in later posts.

cu3w0rx. Lovely name, eh? Moving on …

In this series we will be looking to implement a simple Map-Reduce framework that closely models the design and implementation of the CloudCrowd, which is written in Ruby. CloudCrowd  has some nice design choices. Specifically its small size (~1,800 LOC), use of JSON for message transport, and emphasis on HTTP as the protocol is quite nice. It is also pretty to look at, and the interface is entirely AJAX driven, so relies on the same service calls as the rest of the suite.  I think it is worth our while to set the stage for the project. Here are a list of things we will be taking directly from CloudCrowd:

1. The App Engine application will serve as the central master resource.
2. It will serve as the master work queue. All jobs will be submitted to it for processing.
3. All communication will be via JSON messages. As in CC, the web site will make use of the JSON returned from AJAX requests to the resource handlers.
4. There will be a clear specification for the top-level properties of a Job message, but handlers will be responsible for vetting the provided options to handle the request.
5. Operations on inputs are assumed to happen on local disk. E.g. jobs will be staged onto the worker nodes’ scratch space.
6. Jobs will have the option of a callback URL on success.
7. For simplicity’s sake, authentication to the master, and between master and slaves, will be the same basic HTTP authentication credentials.
8. A worker node will accept work item requests based on the machine’s load.

There will be several points that will stray from CloudCrowds implementation as well:

1. Nodes will publish their capabilities to the master. It will not be assumed that all nodes have all the same capabilities. In this respect cu3w0rx will more resemble the nanite project (Ruby + ERLang).
2. Worker nodes will not share the same code base as the master. The major reason for this is that worker nodes will not run on GAE, hence it makes no sense to hamstring them with the restrains that GAE imposes on python.
3. Workers will maintain their own state in a local database. This will server to keep track of capabilities, number of jobs processed, monitoring statistics, and results from previous jobs.
4. Map and reduce are implemented as two separate jobs, as far as the worker nodes are concerned.
5. Since this is a demonstration project, we will not implement a scheme to save result files to non-volitile storage. Instead we will provide a way to give authenticated access to result files from worker nodes. Result files from Reduce phases will live only at the final destination host (e.g. the hosts that have checked back into the master as having succeeded a particular job.
6. The queue is not necessarily FIFO. I am actually not sure if this is also true about CloudCrowd, but its worth mentioning here.

I would also like to implement a way to provision and configure cloud VMs using the excellent libcloud library, but I think that is outside the scope of a demonstration project. If you see anything missing (or think some stuff can be left out) leave a comment!

Book title: Using Google App Engine
Edition: First Edition ( May 2009 )
Author: Charles Severance
Publisher: O’Reilly | Google Press
Cover Price: $29.99 ( U.S. )

I’ve been interested to try out some of the free Cloud Computing offerings that are rising into vogue. The one that looked to have the lowest barrier-to-entry, was the Google App Engine (GAE).

I downloaded the local GAE development environment ( the Python flavor, not the Java edition ) and walked through the series of examples in Google’s tutorial. Through the tutorial, I received a little exposure to the Datastore service and the Django-compatible templating mechanism. It was a nice enough introduction, but I wanted to know more.

I searched for some GAE books and found some good reviews of this text. I ordered a copy.

What I Skimmed

The book is a nice enough introduction to web programming in general. It contains chapters covering the mechanics of web transactions, the history of HTML and CSS, and a 30-page introduction to programming in Python ( 2.5 ).

I skimmed through these chapters as I suspect a fair number of web developers would do. I did briefly go through the Python tutorial and found it to be concise and informative. Actually, it begins as an introduction to general programming using Python.

A guess-the-number game is provided which serves as a reference model for some of the concepts. If they haven’t already, they should snip this section out as a PDF and give it away.

The tutorial manages to introduce control-flow, strings, functions, lists, dictionaries and objects in a short span of pages.

I completely skipped the chapters that describe how to install the GAE development environment on various platforms. The author covers installation on Windows XP, Windows Vista, Mac OS, and Linux. No specific Linux distribution is cited. The installation instructions are probably similar for most distributions.

The Good Stuff

The book does a good job in leveraging the Django-compatible templating mechanism. I had seen some of these templates before, but was not overly impressed with the mechanism until I saw them use a convention that I wasn’t used to.

In normal templating systems that I’m used to, it’s common to leverage an include directive to pull in common snippets of HTML and/or other template code for common headers, footers, and such. The convention that the author used for the Django templates was different.

In the template scheme he used, a baseline template is defined with a “body” section. All other templates refer to this baseline template and override the content of the body section; they contain only the changes to that section.

In a way, this is kind of like an object-oriented document system that observes the inheritance property of OOP. If one wants to make look-and-feel changes, they would likely only have to change the baseline template.

Later examples illustrate how to override multiple blocks of text in the baseline template.

The author takes the reader through some pretty fair examples. He builds a web equivalent to the guess-the-number game to show the reader how a desktop console application and a web application differ in code and execution. He does a good job introducing the reader to CGI programming.

He then builds a real-time chat application leveraging JQuery for a smooth AJAX interface to the web app. He proceeds to build a functioning, multi-user web chat system.

We are introduced to the Datastore, the memory cache (memcached) interface, and the logging mechanism.

I enjoyed seeing some of the administrative console features. One can view the logs and can also invoke Python code interactively, which I find to be quite liberating. It’s nice to have a REPL ( read-evaluate-print-loop ) that will let you interact with the same back-end objects that your web code is using.

Please note that I have yet to actually try out any of this code. I assume that it works properly. I also assume that any errors in the code are corrected in an errata section somewhere on the web.

What I Didn’t Care For

The author spent some time building a session mechanism based on the memcached interface. This mechanism did not seem to be backed up by persistent writes to the Datastore as memcached is a volatile cache. The author admitted that the cache could end up removing the cached session info.

It’s my understanding that GAE provides a users class that provides a login mechanism and ( I would hope ) a persistent session object. I don’t know much about this, but it shows up in the Google helloworld.py application on the Google tutorial. It would have been nice to see how this works in the printed text.

The author mentions the HTTP form-file upload, but never mentions how the GAE framework can be made to process file uploads. It’s not really essential to the book, but I’m kind of curious as to why it was referenced in the first place, unless he wanted to describe the mechanics used to publish one’s Python code and supporting files to the GAE cloud.

Closing Thoughts

Overall, I would recommend ( and have recommended ) the book to friends. It’s a nice intro that has some diverse foundational information that would seem to make the book accessible to quite a broad audience.

Save to del.icio.us
Digg it
Save to Reddit
Share on Facebook
Share on Twitter
More bookmarks

Unless otherwise noted, all code and text entries are Copyright © 2009 by James K. Lawless

It’s more than 2 months ago since I blogged about the groovytweets status, but there have been numerous minor updates and improvements. The friends list (the Twitter users we collect tweets from) has been expanded to ~422 followers (and likely more when you read this), the regular expressions used to decide if a tweet is ‘groovy’ has been adapted to the changing groovy universe (like gparallelizer renamed to gpars or following vmware news now), and so it goes on.

But the real meat is a bit behind the scenes. The features you’re likely to see quite early are language detection (filtering by language) and a new link ranking. I still have to improve the quality of language detection as tweets often use English terms even if the tweet itself would be written in a different language. Larger texts submitted to the Google Translation API of course yield better results; tweets just having 140 characters makes this a bit harder.

The groovy link ranking feature can already be seen live in an early version. I am now collecting the links and tracking their usage in tweets the same as retweets for tweet. The nice thing is that I am tracking the final URL, so if someone used bit.ly to create a short version of a URL I am actually following the redirects to find the final destination. Next, I am prepared to limit the links shown in the UI to the last weeks (2 currently) and in addition the relevancy of the links degrades over time. This means a link from today having 5 mentions in the groovy community will eventually be higher ranked than a link from yesterday having 6 mentions, simply becuase time is an important factor for relevancy.

Links

The real real change for groovytweets is yet to come though. As you might have heard, the new Twitter Retweet API is on it’s way. It has been changed multiple times now, based on a lot of user input flowing to Twitter and hopefully even mine. It will fundamentally change how Twitter aggregators/relevancy tools can count retweets. For now a Retweet was a community-agreed syntax, like RT @originaluser text. In groovytweets code I was analyzing each incoming Tweet to decide if it fits in one of the many retweet syntaxes and tried to find the original tweet, then tried to look that tweet up and increase the relevancy.

Well, now Twitter is making the Retweet an official concept of Twitter. They even give you a new API method to look up the total retweets of a tweet, which sounds great. The downside is that each Twitter account may currently use 150 API calls per hour. If I wanted to update 50 tweets displayed on the groovytweets homepage every minute, this means 50 Tweets * 60 Calls per hour = 3000 calls per hour. Well, I got 150. An that is not including the minutely check on new tweets coming from groovytweets friends. So: we’re in trouble here. One solution would be to get whitelisted for more API calls, but there is a better one (or two).

The one solution I still got some hope for is that Twitter will simply include a retweet count with each Tweet. The problem here, I guess, is that I am interested in the retweets within a specific community only. And providing the count only for *my* friends instead of a global retweet count (which is way less relavant some might argue) might potentially be a pretty resource intensive task for them.

The next and more likely solution involves using the Twitter Streaming API. The good thing about the API is that it will show retweets. Although the API just changed again, making the Retweet now the top element instead of the Tweet (and including a retweet_details element), it is then very easy to detect a Retweet. The bad news: Groovytweets is hosted on Google Appengine, and Appengine kills each request after about 30 seconds. So I invested some time finding a cheap vServer on which I open a permanent streaming connection to Twitter. I will then call an API over on groovytweets to feed the retweet information into the app. This splits the system into two parts, which I wanted to avoid, but it looks like the best solution.

Follow me @hansamann to get the news as it happens.

At the Geek Night last night there was a lot of questions about how Heroku compared with Google App Engine (and I guess implicit in that how it compares to GAE/J with the JRuby gem). Since it came up several times I thought it would be interesting to capture some of the answers.

Firstly there are the similarities, both deal with the application as the base unit of cloud scaling. Heroku offers several services that are similar to GAE, e.g. mailing, scheduled and background jobs. Some aspects like Memcache are in beta with Heroku but fundamentally both services seem to concur.

They are both free to start developing and then the pricing for the system varies a bit between the two, GAE might be cheaper but also has a more complex set of variables that go into the pricing, Heroku prices on: data size, web processes required and then options, so it’s easier to project your costs.

Differences then: well a big one is that Heroku uses a standard SQL database and also has excellent import/export facilities. GAE uses Google BigTable which is great for scaling and availability but data export and interactions are very limited. Heroku has an amazing deployment mechanism that involves simply pushing to a remote branch. GAE is slightly more involved but it is still relatively easy compared with deploying your own applications.

GAE provides access to a variety of Google services that are handy such as Google Account integration and image manipulation. GAE also has XMPP integration which is pretty unique if you have the requirement. However these do tie you to the platform and if you wanted to migrate you’d have to avoid using the Google webapp framework and the API. If flexibility is an issue you are probably going to prefer Heroku’s use of standard Ruby libraries and frameworks.

Heroku has few restrictions on what can and can’t be done in a web process, you also have quite powerful access to the user space your application runs in. GAE and particularly GAE/J has a lot of restrictions which can be quite painful particularly as there can be a discrepency between development and deployment environments.

However running a JVM in the cloud provides a lot of flexibility in terms of languages that can be used and deployed. Heroku is focussing on Ruby for now.

From my point of view, choose Heroku if you need: uncomplicated Rails/Rack application deployment, a conventional datastore that you want to have good access to, a simple pricing model. Choose GAE if you want to have out of the box access to Google’s services and a complete scaling solution.

Our company had a hack day last week and I thought that I’d have a look at the Google App engine. I was getting used to the management reply of “do you have a budget code?” when asking for a server in the racks, so I thought that I’d experiment with some data in the cloud. I had taken in the story about the Guardian knocking up a quick python web app using Django to notate the MP’s expenses information. I heard tell it took a week so I thought I might get something simple done in a day.

What I hadn’t realised is that Simon Willison, who wrote the Guardian app, had been a major contributor to the Django framework and so knew it backwards. Sigh. I did have a look at the framework but in the midst of various problems with wifi, there was just too much for the first half day. In the end I just cut some simple python code together to see what response times were like and to get a flavour of the database side in the Google App engine. It was a good experience and convinced me to give it another go after learning more about Django. I’ve put some notes here about what I needed for development and a few demo screens about the app that I created.

I needed python on the laptop, so I went for the latest version, v3. That was my first mistake. Google doesn’t work too well with this version; it has some idiosyncracies that require 2.6. I had to uninstall the new version and set up the older version. I would advise over riding the default directories, as some parts of the operation (patchng for django?) seem to falter over spaces in directory names. In the end I installed to the C:/python26 directory and all seemed to work. I then installed the app-engine-patch that is needed to run Django on the Google App engine. I used version 1.1. It was interesting to start looking at Django, but I found that I needed serious learning time. In the end I decided just to set up some simple REST service to input some records and return some XML.

Once python is on your development machine, you need to add the Google app engine tools. These give a simple gui to allow you to control the loading and running of several services, each with their own socket. Write the app using any favourite editor (htmlkit is a simple, free one that I can recommend – although I’m normally on eclipse), then compile and run with this gui. It will run the app on a local server, which is booted automatically. Browse to the server with eg http://localhost:8080 and the app will be run. A few seconds delay the first time, as it is being compiled. You choose the port number when loading the app, so you can have several apps running at one time. Pause them, continue etc.

What happens in the app and what sub pages exist, are defined in the application. It effectively links a routine to a page url. When you’ve tested your application locally, just click the Deploy button and it will be sent up to Google’s cloud and it will then be available across the net. It really is simple.

Two main files are required, app.yaml and main.py

An example of app.yaml is,

application: data-form
version: 1
runtime: python
api_version: 1
handlers:
- url: .*
script: main.py


This names the application as data-form and defines the action for all the pages in the application as main.py. There are only a limited number of application names allowed per developer (10, I think).

Main.py is where the logic is stored and has the definitions of the processing, the classes and the urls.

First we have the normal includes for the libraries,

import cgi
from google.appengine.api import users
from google.appengine.ext import webapp
from google.appengine.ext.webapp.util import run_wsgi_app
from google.appengine.ext import db

The class definition for the objects in the database, in this case a football fixture,

class Fixture(db.Model):
user = db.UserProperty()
league = db.StringProperty()
status = db.StringProperty()
home = db.StringProperty()
hscore = db.StringProperty()
ascore = db.StringProperty()
away = db.StringProperty()
date = db.DateTimeProperty(auto_now_add=True)


The following class creates the display page. It reads from the fixtures database, using the gql querylanguage. Then it writes out the fixtures, followed by a form to input a new fixture.


class MainPage(webapp.RequestHandler):
def get(self):
self.response.out.write('')
fixtures = db.GqlQuery("SELECT * FROM Fixture ORDER BY home ASC LIMIT 10")
#
for fixture in fixtures:
if fixture.status:
self.response.out.write('%s ' % fixture.league )
self.response.out.write('%s ' % fixture.home )
self.response.out.write('%s-' % fixture.hscore )
self.response.out.write('%s ' % fixture.ascore )
self.response.out.write('%s ' % fixture.away )
self.response.out.write('
' )
else:
self.response.out.write('%s v
' % fixture.home)
#
# Write the submission form and the footer of the page
self.response.out.write("""
<div>
Fixture
Started
Finished
<br />
Prem
Championship
Second
<br />
Home
Away
<br />
</div>
<div></div>
""")


Which gives a screen like this,

The following class is used to add the fixture from the form data.

class AddFixture(webapp.RequestHandler):
def post(self):
fixture = Fixture()
#
if users.get_current_user():
fixture.author = users.get_current_user()
#
fixture.league = self.request.get('league')
fixture.status = self.request.get('status')
fixture.home = self.request.get('home')
fixture.hscore = self.request.get('hscore')
fixture.ascore = self.request.get('ascore')
fixture.away = self.request.get('away')
#
fixture.put()
self.redirect('/')


This class will simply list the matches,

class ListFixtures(webapp.RequestHandler):
def get(self):
self.response.out.write('List fixtures')
#
fixtures = db.GqlQuery("SELECT * FROM Fixture ORDER BY home ASC LIMIT 10")
#
for fixture in fixtures:
if fixture.status:
self.response.out.write('%s ' % fixture.home )
self.response.out.write('%s-' % fixture.hscore )
self.response.out.write('%s ' % fixture.ascore )
self.response.out.write('%s ' % fixture.away )
self.response.out.write('
' )
else:
self.response.out.write('%s v
' % fixture.home)
#
self.response.out.write("""
""")


This class lists the fixtures as XML.

class ListFixturesXML(webapp.RequestHandler):
def get(self):
self.response.out.write('')
#
fixtures = db.GqlQuery("SELECT * FROM Fixture ORDER BY league, home ASC LIMIT 10")
#
for fixture in fixtures:
self.response.out.write('%s' % fixture.league )
self.response.out.write('')
self.response.out.write('%s' % fixture.home )
self.response.out.write('%s' % fixture.hscore )
self.response.out.write('%s' % fixture.ascore )
self.response.out.write('%s' % fixture.away )
self.response.out.write('')


Finally a section that defines which page urls are associated with which procedure. If the address localhost:8080/xml is used, the ListFixturesXML routine will be called.

application = webapp.WSGIApplication(
[('/', MainPage),
('/sign', AddFixture),
('/xml', ListFixturesXML),
('/list', ListFixtures)],
debug=True)
def main():
run_wsgi_app(application)
if __name__ == "__main__":
main()


All relatively painless, once you get the overall idea of the layout. It becomes more complex as the operations require more processing, further classes and interaction, which is where having a framework like Django will bring benefits. I shall take the time to look more into Django, as the value of running this type of service on the cloud are that it is largely free for moderate usage and free of the overheads of setting up any hardware and web server software. Javascript could have been used in the same way; I just wanted to have a look at python, as I may need it in other systems.