Archive for the ‘Python’ Category

New Postmarkup on the block

Tuesday, June 24th, 2008

I’ve released version 1.1.0 of Postmarkup. The main improvements are that it generates cleaner html, that doesn’t include invisible div sections, and that it should also generate XHTML that validates (previous versionsĀ  could put block tags inside inline tags for some bbcode).

The basic interface is the same, so it should be a drop in replacement for most people. TheĀ  base class for tags has changed (but not significantly), so if you have any custom tags, it will require a little work to get them functional again. See postmarkup.py for example tags.

I actually quite like bbcode as a light-weight markup. Possibly I’m rationalising, as I’ve spent a couple of days polishing it when I should be job-hunting! Its great for its original purpose, of letting forum users format text, but it could be used as a more friendly alternative to XML. It’s also higher level than (X)HTML in that a tag can generate intelligent content rather that simply applying a style.

Now I have to find some other project to keep me entertained before I re-join the rat race!

BBCode Ajax test server

Monday, June 23rd, 2008

Since I have some time on my hands, I’ve been doing a little work on Postmarkup - my BBCode module. I’ve made some significant improvements to the design which fixes a few issues and makes it easier to create new tags. To test it, I hacked together a simple web-app using CherryPy, which allows you to edit bbcode in the browser and see the resulting html update live — with a little Ajax magic.

Postmarkup test server

Please give it a try, and let me know if you can break it.

In building this, I’ve created a very rudimentary web service. I’m wondering if there is any practical use for such a thing…

My CV / Resume

Thursday, June 19th, 2008

It seems it is a good time to be a Python developer, after my last post I received a number of good leads. All before I had finished my CV.

Looking for a Python Role In London

Monday, June 16th, 2008

Its seems I’m on the job-market again.

I’m a software developer with over 10 years experience. I’m looking for a role working with Python, which has been the focus of my career for the last 18 months. Prior to that I worked with a mixture of C/C++ and Python. Ideally I’m looking for something in web development as I enjoy working with HTML / CSS and Javascript, but I’m open to other fields that may interest me. I have experience working with Turbogears and Django, as well as many other Python modules and technology.

I enjoy developing software outside of a work environment, and have created several games, applications, web sites, and open source Python modules. My blog is probably the best place to find out more about my spare time projects, see my Python articles for more information.

I’m also an author, having written a book about game development with Python. So I like to think I am a good communicator.

I’d like a full-time position, but I would consider contract work. I’m based in London, so anything in central London would be ideal. Please get in touch if you have a suitable role or would like to know more. I’m available for immediate start.

my email

Mobile: 07722 531972

No recruiters please. And by no recruiters, I mean no recruiters.

Update: I have updated my CV (willmcgugancv.pdf)

Practicality versus Purity for Python Templates

Thursday, February 28th, 2008

There are a number of very powerful template languages available in Python. Some template languages, such as Genshi, allow complex Python statements and even full Python code within the template file. Others, such as Django templates, prefer to restrict templates to presentation only and do not allow general Python expressions within the body of the template.

In the context of a web framework, is it better to have the full expressiveness of Python, or restrict templates to presentation only?

Degreelessness

Wednesday, February 20th, 2008

Occasionally when I am feeling nostalgic I dust of some off my old creations. Back in the day I used to create graphical demos for PC, which are difficult to run these days because they were designed to run under DOS and not Windows, and computer hardware has change so much since then. Fortunately I can use DOSBox to run them with Vista. DOSBox even has an option to record videos, so I recorded a demo I wrote way back in 1995 (it actualy got me my first job). ‘Degreelessness’ was built on a Pentium 75 PC and runs with glorious 256 colour graphics. Its a little embarrassing, especially the goatee, but bare in mind is is over 10 years old!

Here it is, courtesy of Google Video.

Sorry for the spam

Monday, February 18th, 2008

Sorry for the spam in my feeds. It was due to an old version of wordpress that somehow combined deleted spam with my posts. I meant to fix it a while ago but it escaped my mind. My humble apologies.

Writing a Facebook Application with Python Pt. III

Saturday, February 16th, 2008

This is the third part in a series of three posts about writing a Facebook application with Facebook. If you have not already ready done so, you should read the first and second parts first.

The technology behind Facebook applications is actually quite straight-forward. It is completely platform agnostic so you can build an app with any technology you might use to serve HTML content. My choice would be Python, but then I am a shameless Python fan-boy. Unfortunately there are still problems that any Facebook application developer will face, and most aren’t technology related.

Facebook have solved a number of challenging problems and for the most part it is an elegant solution to adding third party applications to their own site. But Facebook isn’t the grand free-for-all platform that the world wide web is — Facebook must tread a fine line between allowing the application developer to generate revenue and avoid annoying the user so much that they abandon their accounts. Its understandable — I wouldn’t want an application popping up adverts or sending mails on my behalf — but the rules they put in place tend to put the app developer at odds with Facebook admin.

For example, there is an API call that sends out notifications. When you receive a notification it displays a little text and link which you might use to inform a user that a friend has sent them something or done something else that is directly relevant to them. Facebook don’t want applications flooding other users with these notifications, so it places restrictions on the number that can be sent out. The documentation says the application can ’send up to 40 notifications to the notifications page per user per day’, which to to me is unclear whether an application can send 40 notifications per day on a user behalf or receive 40 notifications per day (apparently its the former). That used to be the case, but Facebook introduced a new system that restricts notifications even further. Applications receive a variable allowance of notifications that changes depending on how many users hide its notifications. The more users that hide your notifications, the less notifications an application may send out. The starting level seems to be 10 notification per day, a good bit under the original 40. This restriction strikes me as being excessively harsh on the application developer, and I’m not the only one who thinks so — the forums are full of application developers venting their annoyance at this and other restrictions. In my opinion it would be far more sensible to restrict the number of notifications that can be received from an application, even one per user per day would be fine! I don’t think anyone would be too annoyed by at most one notification per day send from a friend.

Facebook appear to be constantly tweaking and modifying their system to keep applications in check and make the content from applications as relevant as possible. And they prefer to do this by automated means, much to the chagrin of the application developers who feel they are being unfairly penalised by an flawed system. Unfortunately if you want a piece of Facebooks pie, you need to play by their rules. I suspect the gold-rush is over for Facebook applications, but as long as you keep on top the constantly shifting platform it could be a lucrative opportunity.

My own application doesn’t seem to be doing too well. Perhaps because of the reasons I am posting here, or because it is a waste of time and people don’t see the point. Whatever the reason, I am less inclined to create a Facebook app for becontrary.com, which was my original reason for looking in to it. It has started me thinking about how to make a better job of embedding an application inside a host web app, so writing a Facebook app may have been a good use of my time after all. Maybe I can do a better job, the poor schmucks at Facebook are lumbered with PHP. ;-)

Easy as Pie

Saturday, February 16th, 2008

To further my bid for the worlds dullest hobby award, I have been creating pie charts. I wanted to investigate generating Povray scene description files with Python. It turns out to be a winning combination; it didn’t take long to build a system where I can generate a scene containing pie segments of various colors and angles. I can also vary the height and explode individual pie segments. Povray can render very high quality scenes so this system could be used to make pie charts for television or print.

pie

I will experiment with other charts, bar charts etc. Maybe I’ll even generate an animation with it.

This isn’t entirely just for the heck of it. I plan to write an article about it for the Python magazine.

Writing a Facebook Application with Python Pt. II

Wednesday, February 13th, 2008

For the first part series of post, click here for Part I.

Writing a Facebook application is in essence the same as writing any web application, only with an additional step where the output from your web app is processed and inserted in to a Facebook page. Although PHP seems the most popular choice (and is what Facebook itself is written in) you can use any of the Python frameworks to write an app. You could even roll your own if you were so inclined. I used Turbogears, but you could easily adapt this to another Framework.

Serving FBML

You can generate FBML with any Python templating system. I used Genshi which was quite happy to generate FBML for me as long as it was instructed to produce xml and not html, which you can do by adding format=”xml” to the expose decorator. For example, here is the controller method for my stats page.

    @expose(template="genshi:microbes.templates.stats", format="xml")
    def stats(self, *args, **kwargs):
 
        num_users = User.select().count()
        num_added_users = User.select(User.q.added==True).count()
        num_infections = Infection.select().count()
 
        return dict(num_users=num_users,
                    num_added_users=num_added_users,
                    num_infections=num_infections)

To see what that renders, take a look at the source of http://microbes.willmcgugan.com, which is naked FBML (not processed by Facebook).

Adding and Removing Users

The first page that the user requests probably wont be FBML at all. When the user adds your application, then Facebook will redirect to a URL defined in your app settings. If your app needs to store users then this is where you would add the users id to your database. You could then display a welcome page, or simply redirect to one of the pages in your application. Similarly, when a user removes your application the Facebook server requests another. This ‘user removed’ URL is never actually seen by the user so you don’t need to return any meaningful content for it.

Using the Facebook API

For other pages within your application you need to do a little work to retrieve parameters from the page request that allow you to work with the API.

There are two Python modules to help with writing Facebook apps (that I know of). PyFacebook is a complete wrapper for the FB API and may be the obvious choice for writing a new application. However, the documentation was Django centric and I originally wanted to integrate an existing Turbogears application. So I decided to use minifb, which provides the necessary boiler-plate code for making calls to the Facebook API. If I write another application I would probably use PyFacebook to save a little time, but it turns out that doing it the hard way isn’t that hard at all.

Before you use any parameters from a Facebook request, they need to be validated with a call to minifb.validate which takes your secret key (supplied by Facebook when you create an application) and a dictionary containing the request parameters. In Turbogears you would simply pass the keyword arguments from the controller method to minifb.validate. When a user has added your app, every call has at least two parameters supplied by the Facebook server; ‘user’ is the user id of the current user and ’session_key’ is a string that identifies the current session which is needed for API calls. In the spirit of removing — even minimal — boilerplate I wrote a decorator to add to controller methods which does the validate step and optionally redirects to page if the user is not logged in.

_login_url = "http://apps.facebook.com/virtualmicrobes/"
 
def expose_fb(no_redirect=False):
 
    def decorate(f):
 
        def func(*args,  **kwargs):
            try:
                arguments = minifb.validate(FACEBOOK_SECRET_KEY, kwargs)
            except Exception, e:
                return str(e) 
 
            if not no_redirect and "session_key" not in arguments:
                return '<fb :redirect url="%s" />'%_login_url
 
            ret = f(*args, **arguments)                        
 
            return ret
 
        func.__dict__.update(f.__dict__)
        return func
 
    return decorate

To use this decorator, just add it before Turbogears @expose decorator, which will make the controller appear just like any other request.

The minifb.call function can be used to make calls to the Facebook API. It takes the name of the API method you want to call, followed by your API key, secret key, session key and any additional parameters required by the method. It sends a POST request to the Facebook server and parses the returned JSON. The return value from minifb.call is a collection of basic Python data types, so it is very easy to work with. Generally API calls will return a list of integers / strings, or possibly a list of dictionaries.

Facebook Gotchas

The Facebook server imposes a timeout restriction on pages within your application. From my experiments this seems to be about 7 seconds, if the Facebook server doesn’t receive a response from your web app within that time limit it will display ‘page not found’, or words to that affect. If your server is under strain and you are also making a lot of api calls then it is quite possible to go over the timeout. I initially had this problem, but it turned out to be due to a faulty DNS server which webfaction.com quickly fixed for me. So you may not experience this issue, but if you do I would suggest reducing the number of API calls you make if possible, and if you don’t care about the return value of your API calls it would be worthwhile running them in a separate thread. I wrote the following helper function to do just that.

def fire_and_forget(callable, *args, **kwargs):
 
    def do_callable():
        try:
            callable(*args, **kwargs)
        except:
            pass
 
    thread = Thread(target=do_callable)
    thread.start()

If you wrap an API call with fire_and_forget it will run asynchronously and reduce the time to handle the request.

Cliffhanger

Hopefully I have convinced you that technology wise, writing a Facebook application is fairly straight-forward. Unfortunately there are other hardships which you will have to face when writing your app. I’ll go over them in Part III.


Close
E-mail It
Socialized through Gregarious 42