Battling the Facebook API

One of the things I've been trying to do with Google App Engine is get my app to talk to Facebook. As it turns out, this is a reasonably straightforward task made incredibly complicated by the appalling Facebook Developers documentation. Just trying to work out what it is you need to do (never mind how you actually go about doing it) is a real trial.

Undeterred (I was getting paid for this, after all) I persevered and eventually worked out that before my app could talk to Facebook, users would have to add it to their profile and grant it permission to do stuff - for this I would need a 'Callback URL'. Unfortunately, all the examples in the docs are PHP, but here's what I came up with in Google App Engine:

class FacebookPage(webapp.RequestHandler):

  def get(self):
    self.post()

  def post(self):
    self.response.out.write("<fb:prompt-permission perms=\"status_update\">\
Grant permission for status updates\
</fb:prompt-permission>")

Yes, it's not pretty and yes, I've got markup in the source code, but it works. Those three lines of FBML (Facebook Markup Language) request that the user gives my app the necessary permissions. Once added, my app can then use the PyFacebook utility to make calls to the API:

fb = facebook.Facebook(FACEBOOK_API_KEY, FACEBOOK_SECRET_KEY)
result = fb.users.setStatus(new_status, False, uid=facebook_user_id)

Easy when you know how!

More Google ...

Seems like I'm going Google crazy these days, but as part of my day job I've been looking at Google App Engine this week. It's certainly a very rapid development tool and I wouldn't hesitate to use it for personal projects ... but at the same time it feels a bit lashed together to me. It uses Python 2.5.2, so no complaints there, but why use Django 0.96.1 when Django 1.0 was released in September last year? Anyway, I'm just nit-picking to be honest - it's another great tool from Google and the benefits far outweigh the drawbacks.

Google Code

I've written a fair amount of code now and I've been looking for somewhere to store it for a while. Up until now this has meant a combination of a friend's SVN repo, a couple of laptops and an external hard drive. However, I recently decided to take the plunge and try Google Code.

For some reason, I'd previously thought that Google Code was only used for Google App Engine. However, this turned out to be totally wrong (you can put pretty much anything on there as far as I can tell) and I now have a high availability SVN repo at my disposal. Once I'd created my top-level project I quickly added two sub-projects - one for the level editor (Java) and one for the game itself (Python).

First impressions are extremely good. Integration with Eclipse (via the Subversive plugin) was seamless and so far, the repo has been available every time I've used it. It's occasionally a little sluggish, but that's a small price to pay as far as I'm concerned.

Lessons Learned

In contrast to my day-job as an Enterprise Java Developer, working on my level editor was generally pleasant experience. It was nice to do some proper OO on a self-contained project with no external dependencies for a change!

I didn't do any up-front design for it and developed each component in isolation, providing functional mocks for inter-component dependencies. Somewhat surprisingly, a domain model ended up simply 'falling out' of this approach as the code evolved - I guess that's what's supposed to happen with Agile methodologies.

That said, I'm not sure how well this would translate to a large project / team environment. This was a small project where I was able to mentally keep everything in the air at once, ie. whenever I changed something I had a very clear idea of how it would affect everything else. If I'd been working on a vertical slice of a much larger application, would this approach still work?

Level Editors

As we all know, every good game needs a level editor and mine is no exception. Here's what it looks like:


I knocked this up in Java / SWT in a few weeks and it already covers all the basic use cases. In fact, drawing the tiles was more time-consuming.

I was quite impressed by SWT. It's about a million times easier/quicker than Swing and I like the way it just looks like a native app. I did give the Eclipse Rich Client Platform a try to start with but that seemed to be one of the most impenetrably hard things I've ever looked at so I settled on SWT in the end. I also toyed with the idea of doing it in Python, but the sheer range of Windows Toolkits that are available for it put me off slightly.