Google App Engine lightning talk notes

Thursday, May 8th, 2008

I’ve attached a tar.gz of my lightning talk notes. AppEngine lightning talk

There is a copy of the presentation, which is probably not worth the time it takes to open.  then there are three copies of the blog application.

Blog_step1 is just the basic django application, that does nothing.

Blog_step2 is where I’ve added a basic model of a blog post, I’ve added a basic view so you could see a post if any existed.  Creating a post is difficult at this point, you could do it with the Google App Engine dataviewer if you could manage it.

Blog_step3 is where I’ve added the facility to create a post.  Of note is that to create the form we only have to create an object that has a Meta class referencing the model.

I’ve also included diff’s of step1 to step2, and step2 to step3, so you don’t ahve to manually see what changed between versions.

Hope you like it.

I think that went well

Tuesday, May 6th, 2008

I went to the London Python meeting tonight, and listened to Jacob Kaplan-Moss of Django talk about where django came from and why it’s so damn cool.

I also gave a lightning talk about Google App Engine, for which I was very nervous.  For some reason I assumed that everyone in the room would have already downloaded and tried it, and would know more about it than me.  Actually It loked like most people knew of it but hadn’t played with it yet.

I’ll upload the slides and source code from the lightning talk tomorrow.

Things to remember next time:

  • 5 minutes isn’t very long, only 300 seconds in fact…
  • Google App Engine is big!
  • Showing people code in diff files in Vim is probably not the best demonstration!

There was a suggestion that I should put together a talk for Pycon UK about AppEngine, which I feel very underqualified to do, but would be a lot of fun so I’ll think about it.

WebMMO - Some critters added

Wednesday, April 16th, 2008

Just a couple of updates to WebMMO

  • I’ve made the map bigger.  Not for any good reason, just it just suddenly felt too small.
  • I’ve added a Hunt facility on the left.  It simply looks up in the database an appropriate monster to fight you.  In zone 1, there is a big dog, and a yappy dog that are found in sand and grass.  But the sand lizard and grass lizard are only found on their respective tiles.
  • I’ve added some admin pages to allow the initialisation of the creature database.

My todo list is longer than ever.  I’m thinking combat or action points is definately the next thing to attempt. Code is uploaded as always, please feel free to criticise, I’d love to get some opinions of a better way of defining the monsters / items and stuff rather than the dictionary in data.py and then turning that into actual dbObjects and putting them.

I’ve tried using the data import tool, but it’s quite complicated as to how you do so, and the documentation sucks, so for the moment I’ve given up.  Maybe I’ll create an admin view that lets you upload a CSV or something and then it wont be hard coded in the application.

Efficiency is not the primary target right now, just getting to having something working is target number 1, but I think the model I’ve got seems to work.

Google AppEngine, BigTable and why RDBMS mentality is harmful

Tuesday, April 15th, 2008

“or How do I write the correct GQL to join these tables together to give me the correct output”

Yet again people are asking on the AppEngine mailing list how to write the correct sorts of joins to join some tables together.

Looking at the design, it was clearly a great database design, a product table, a customer table, and a many to many join table with an attribute to qualify the join. Exactly the sort of tables that you were taught to write in your CompSci degree or courses, or learnt from experience over years of working with databases.

The problem is that BigTable is not a relational database. The Google team has tried as hard as possible to emphasise this, but they didn’t really provide enough examples that people really got it clear.

BigTable is not a relational database, now go write that out a hundred times, and when your done come back and finish reading.

When it comes to BigTable you want to design your database not around “What bits of data should be grouped together”, but around the principle, “What bits of data will I need to read concurrently”.
In this case, what you want to get out is
Purchase information (Order, Date), Customer information (Name, Country, …), Product information (Name, Code, …).

Therefore your table should be.
Purchase:
Customer Name
Customer Country
Product Code
Product Name
Purchase Order Number
Date Of Order

Now your query becomes

Purchase.all().filter("customer_name =",customer).filter("product_name =", product).fetch(100)

Easy huh? It’s all one big table.
Say you want to show a customer what items they ordered for a given purchase order…

Purchase.all().filter("purchase_order =",order_num).fetch(100)

Updating becomes a little harder, but is still pretty easy.
The question then comes, how do I update a product name, if I change my widgets from Acme Widget to “Acme Superwidget”?
Well firstly, really, how often do you do that? I bet it’s a number of orders of magnitude less often than you execute the queries above.

If you must, it is something like:

items = Purchase.all().filter("product_name =",product).fetch(1000)
for item in items:
item.product_name = new_name
item.put()

Yes that last part is a bit nasty, if GQL supported updates it would be nice, but writing the updates in python is hardly taxing.

I hope that helps someone

PyCon UK 2008

Tuesday, April 15th, 2008

One of the guys I work with a lot has been bugging me to go to PyConUK this year, and given that he has just been outed as a sponser as well this year, I am thinking of trying to go.

If you’re into python, games programming and going, let me know.