I chose three groups of related languages, partly for reasons of familiarity and interest, and partly to allow me to compare words within and across groups:

• English and German (Germanic)
• French and Spanish (Romance)
• Arabic and Hebrew (Semitic)

Interestingly, the origins of the words for days of the week can almost all be placed into the categories Planetary, Pagan Gods, Religious and Numeric.  The following table lists the words for days of the week in each language together with their meaning / origin:

The origins of words for days of the week

What struck me immediately is that this table is strongly reminiscent of the Periodic Table.  This probably isn’t surprising considering that related languages have been placed adjacent to each other.

Head over to this Wikipedia page for a more complete study of the origins of the words for days of the week (but without the colourful table).

Python is a very readable language (a fact which contributes to its popularity) and has been termed “executable pseudocode” on account of its readability.  An aspect of Python which makes it readable is its avoidance of syntactic fluff, extraneous words and symbols which add nothing to the code’s meaning but serve to detract from it.

In the past I’ve felt somewhat negative about Python’s terminal colon “:”, the symbol used to terminate if, while, def and class statements and to signify the start of a new block of indented code.  For example:

if a == 1:
    b = do_something_cool()

def do_something_cool():
    return 'Doing something cool'

Even without the colon, it’s quite clear that we’re starting a new block of indented code because (a) the statement starts with the keyword if, while, def or class and (b) the next line of code is indented. For comparison, Ruby gets on just fine without the colon after its def statement. So why the need for a colon in Python? Is it syntactic fluff?

The Python FAQ explains that the colon enhances readability and helps editors with syntax highlighting and code indentation. Lets face it, any self respecting editor should be capable of parsing a line beginning with an if, while, def or class, so the “helps editors” argument is bogus. I do however buy the argument that the code is visibly more readable. But how does it enhance readability?

I’ve already mentioned that a programmer spends more time reading than writing code. What I haven’t yet suggested is that a programmer will often reread and scan the same code repeatedly to form a mental picture of a larger codebase. It’s what the eyes do when they’re scanning code that’s key to the importance of the colon. There is some evidence to suggest that the eyes linger at the beginning and at the end of a sentence when reading text and draw especially from visual cues at those locations. Let’s assume for the moment that this holds true for a line of code. So the visual cue heralding an indented block of code is clear at the beginning of a line of code, namely an if, while, def or class followed by an indented line. The only visual cue at the end of a line of Python code is the colon, and without the colon there would be no cue. So even though the colon is not strictly necessary, there is an argument that its existence is there for human consumption and aids readability.

When all’s said and done, the advantage of the colon is probably slight at best, and then probably only for a newcomer to the language. (This sort of advantage possibly completely vanishes for experienced users of any language). Never-the-less, on balance, I’m now happy it’s there!

There’s a wealth of both online and dead-tree texts covering Django and jQuery, however by comparison, there’s far less information covering the integration of both technologies so the arrival of this book is timely.  I’m also always happy to see new books aimed at the more experienced Python programmer in a time when the rapid (and very welcome) growth in the adoption of Python has led to the recent publication of a large number of beginners’ books.

To get the most out of this book, a knowledge of Python is expected and a working knowledge of Javascript and Django highly recommended.  The author also makes occasional (and perhaps inevitable) comparisons between Javascript and the Java language in the first couple of chapters, however a working knowledge of Java is definitely not needed.

The first chapter covers Python and Javascript.  As a Django/jQuery developer you’ll be using both languages and the author provides some interesting comparisons between the two.  The author is also quite candid and realistic about the weaknesses of Javascript and its cross-browser incompatibilities whilst carefully highlighting its strengths:  “If you can figure out why Python is a good language, you can figure out why JavaScript is a good language.”

The second chapter gets stuck into the basics of jQuery and the constructs which simplify the implementation of Ajax.  The third chapter then dives into Django with a tour of Django validation and a detailed discussion of validation in general.  The remainder of the book builds a reasonably large web application with each chapter pulling together a good number of disparate features you’d want to provide in any self-respecting Web 2.0 application.  Autocompletion, form validation, server-side validation, client-side and server-side search and login handling are all described and integrated into the application.  Even the creation of a “favicon.ico” is mentioned to put a company logo on your users’ web browser tabs and make them look distinctive.

It quickly became apparent that this book  is not a regurgitation of “the same old stuff”, rather it makes the effort not only to show you what to do, but also to discuss why you do something in a particular way and how you can improve on it, leaving the reader with a deeper understanding.  For example, the book is quite happy to extend the provided Django classes where they fall short, and show validation of more unusual types such as GPS coordinates not natively supported by Django.  Another example is the book’s excellent treatment of validation discussing cultural awareness and the suggestion that a “less is more” approach to validation can sometimes make sense.

Apart from a couple of typos here and there (which are possibly restricted to my electronic copy), a minor annoyance is what I felt to be a rather unorthodox Javascript formatting style.  For example:

set: function(newValue)
   {
   var value = parseInt(newValue.toString());
   if (isNaN(value))
       {
       return false;
       }
   else
       {
       field = value;
       return true;
       }
   }

It’s quite possible again that this is a formatting issue restricted to my electronic copy (and I’ll investigate and update this review accordingly).  I also acknowledge that you can never please everyone with your coding style and layout!

The book stops short of helping you organise the inevitable growing mass of Javascript code, a difficult but increasingly important topic.  A little information around the modularisation of Javascript files or strategies and libraries for implementing MVC in client side code would have gone a long way.  Another aspect of the book which is notably glossed over is the topic of testing.  Testing can be hard, and testing web applications can be very hard, particularly those which rely on a lot of Javascript.  Admittedly this isn’t a book about testing, but implementing tests is a very important part of a developer’s life and a section or chapter setting the reader on the right path would have been welcome.

There are several parts of the book which deserve a special mention, however Chapter 11 particularly stands out.  The topic of usability is one often brushed over in technical books in favour of delivering more how-to’s and code examples.  The author devoted an entire chapter to usability, a chapter which I can only hope the authors of many web applications I’ve used might one day read.

I find it hard to characterise the author’s style of writing but I’d probably describe it as intellectual bordering on philosophical with a colourful vocabulary, a style which I enjoy but might not be to everyone’s taste.  An amusing example of the intellectual nature of the book can be found in Chapter 2: “Prototypal inheritance is more like the evolutionary picture of single-celled organisms that can mutate, reproduce asexually by cell division, and pass on (accumulated) mutations when they divide.”  I actually found this an interesting and useful analogy however it’s probably a little hard to relate to unless you remember your school biology!

In summary, I like this book.  I like the the fact that it’s filled with gems of information you won’t easily find online.  I like the colourful language and the interesting discussion around the concepts the author is conveying.  Most importantly, this book is written by someone who has clearly developed real web applications.  If you’re someone merely looking to get cracking on a project using Django and jQuery in the shortest time possible, then this book might disappoint.  But then again, the online tutorials and references are there to get you started and this book can take over where they leave off.

Finally, the author strikes me as someone both interesting and accomplished and I look forward to reading other books he might have in the works.

I’ve owned Marty Alchin’s first book, Pro Django, for some time and was very happy with that purchase.  Based on that, I decided to buy his Pro Python book last year.  Pro Python is targeted at readers who are proficient with basic Python but are looking to push their skills further.  Quite naturally there’s a large number of beginners’ Python books out there but a shortage of more advanced books so it was nice to see this published.

Marty Alchin starts his book with a refreshing approach.  Rather than regurgitating Python facts to the reader, he takes a step by step tour of The Zen of Python discussing how it’s philosophy can be practically applied to make your programming more Pythonic.  He then delves into traditional topics such as classes, objects and strings as well as development topics such as packaging and testing.

I like Marty Alchin’s style of writing and find it to be clear and concise.  Even if you’re reasonably knowledgeable about the advanced topics he covers such as metaclasses, descriptors, introspection and multiple inheritance, I think the book benefits from the fact that these topics are backed up with good examples of how they work, and just as importantly, how they might usefully be used in ways you might not have seen before.  In fact, Chapter 11 walks through the building of a real world Python library which can be found on PyPI (try pip install Sheets) using the principles outlined in the previous chapters.

The other aspect of the book I find very useful is the fact that it is based on Python 3, however all examples are annotated and compared with the “legacy” Python 2 equivalent where relevant.  I’ve gotten a lot more comfortable with Python 3 by reading this book and better understand the improvements in the language from Python 2 to Python 3.

This isn’t a book aimed at newcomers to Python, even if you have a lot of programming experience, as it expects a reasonable amount of basic Python proficiency.  It’s also a “thin” book in the sense that it gives each topic a light treatment rather than aiming to be a complete reference.  This may or may not suit your needs, however there’s plenty of reference material elsewhere both online (e.g. the official Python documentation) and in print.

By comparison, the other advanced Python book I’ve read (and reread!) is Python In a Nutshell by Alex Martelli.  It’s based on Python 2.5 and getting a bit out of date, but much of it is still very relevant for all Python 2.x versions.  (I think a Python 3 version might be in the works).  It’s a much heftier and more detailed book and acts as much a reference text as well as being a book you’d enjoy reading from cover to cover.

In summary, I’d recommend Pro Python to any intermediate level Python programmer who’d like to advance their Python skills with a clear and concise text.

N.B. I am in no way associated with Pro Python, Apress or Marty Alchin … except of course for owning the book!

I’ve been thinking for some time about the factors that contribute to job satisfaction.  More specifically, I’m interested in why people stay in their jobs and at what point they decide to move on.  There are seemingly countless factors to consider, including money earned, working hours, length and ease of commute, boss, colleagues, being challenged etc. etc.  Each of these factors contributes variably to whether you stay or go.

In an attempt to better understand these factors and their influence on decision making, I’ve found that they can generally be placed into one of three categories:

The Circles of Satisfaction. How satisfied are you in your job?

The formula is simple.  Add up the number of circles that apply to you:

If you’re an employer, try applying this formula to each of your staff.  You might be in for a surprise.

Now try this formula on yourself.  Are you in the right job?

So does it now make more sense to use JSON / REST? One of the advantages of JSON / REST includes the inherent decoupling of client and server. The client fires a JSON string to the server at the correct URL using an HTTP POST and the server parses what it needs from that string and happily replies. This process is platform agnostic as HTTP and JSON libraries are available for many programming languages and platforms, not least including Javascript in the web browser. This model is widely used by service providers such as Google and Amazon whereby they can provide and update REST interfaces to their services without having to deliver and maintain multiple API client libraries. A drawback of this model is the need to hand code the marshalling and unmarshalling of JSON data by both client and server, though this can also be seen as an advantage as it decouples an application’s internal representation of data from the wire format.

Hessian compares well with the JSON / REST model. Hessian is also designed around HTTP POST whereby a client connects to a URL on the server and sends data, however Hessian goes one step further and encodes an RPC call i.e. a function name and arguments. In fact the Hessian library makes this process transparent by proxying the server i.e. it provides an object on which the client makes function calls without knowing that the call will be sent to a server. Note that there is no “contract” or abstract interface which you are forced to code to – client and server ensure they’re sending and receiving the correct function arguments by “unwritten agreement” much like the JSON / REST model. Unlike JSON, Hessian is a binary protocol meaning that the data exchanged between client and server is very compact. It also encodes type information, in fact, entire object structures are maintained when unmarshalled on either client or server. Hessian is also cross platform and libraries exist for many programming languages including Javascript.

So what’s not to like?  Well binary communication and the concept of RPC function calls in general seems to have gained a bad reputation, possibly due to the extra complexity and library support needed over simple JSON / REST and possibly because of the increased coupling an RPC call implies.  Experience at my previous company taught us that the communication can be little brittle if the definitions of objects sent over the wire are not kept in step on both client and server. If an object sent from the client to the server has an extra unknown field, there will be an error when the Hessian library on the server tries to unmarshall that data to create an object.  (The reverse, however, is not true – any fields missing from data over the wire will simply end up unset on the unmarshalled object).

Passing JSON over HTTP is much more forgiving in that the client or server will blissfully ignore any field it doesn’t know how to handle, though of course if a field that is expected is not found, the server must know handle that.  Ordinarily, keeping the client and server in step shouldn’t be a problem, however we had many clients in the field with different versions of our software all connecting to the same server.

It has only recently occurred to me that the brittleness described above is peculiar to statically typed languages such as Java where an Exception is thrown at any attempt to apply a value to a field where that field not been defined in an object’s class. The same is not true of dynamically typed languages such as Python which is forgiving when applying values to arbitrary fields on an object. For many years, hessianlib.py has been the standard Python implementation of Hessian. It has been little unmaintained over that time and includes a Hessian client implementation but no Hessian server implementation. The code is also a little impenetrable. Happily, earlier this year a fork of hessianlib.py called Mustaine has appeared. It doesn’t (yet) contain a server implementation, but the code is more penetrable so I submitted a patch with an implementation of a Hessian WSGI server.

Let’s see some code based on the proposed mustaine.server module. (Please note that Mustaine server support is in flux so this example is subject to change). An object can be served via WSGI by wrapping it with mustaine.server.WsgiApp. An object’s methods are only exposed if decorated with the mustaine.server.exposed decorator. For example:

from mustaine.server import exposed

class Calculator(object):
    @exposed
    def add(self, a, b):
        return a + b

    @exposed
    def subtract(self, a, b):
        return a - b

The following code will serve a Calculator() object on port 8080 using the Python reference WSGI server:

from wsgiref import simple_server
from mustaine.server import WsgiApp
s = simple_server.make_server('', 8080, WsgiApp(Calculator()))
s.serve_forever()

This object can now be accessed over the network using the Hessian client:

>>> from mustaine.client import HessianProxy
>>> h = HessianProxy('http://localhost:8080/')
>>> h.add(2, 3)
5

As a result of providing server support to Mustaine, I’ve started developing django-hessian, a library which serves Hessian objects in Django. Objects can be served using djangohessian.Dispatcher at a given URL with an entry in urls.py. The Calculator() object described above can be served at the URL http://localhost:8000/rpc/calculator/ in the Django development server as follows:

# mysite/urls.py:

from django.conf.urls.defaults import *

urlpatterns = patterns('',
    (r'^rpc/', include('mysite.myapp.urls')),
)

# mysite/myapp/urls.py:

from django.conf.urls.defaults import *
from djangohessian import Dispatcher
from server import Calculator

urlpatterns = patterns('',
    url(r'^calculator/', Dispatcher(Calculator())),
)

Full source can be found at http://bitbucket.com/safehammad/django-hessian/.

I can’t help wondering whether the Hessian protocol is getting attention it deserves, particularly in environments where both client and server are delivered and maintained by a single provider. Have you implemented JSON / REST systems which would have benefited from using Hessian? Do you have good arguments as to why the use of Hessian is to be discouraged?

Mortimer the Lepidopterist

Trident Escape: The Dungeon of Destiny

I made several interesting observations during the course of the contest.

Firstly, I’m no gamer, however that was clearly irrelevant to me as I thoroughly enjoyed the competition, the pressure of having to deliver a piece of software to a deadline (but not losing my job if I didn’t) and generally having free reign to hack with Python to produce a creative end product.  Not only that, but I was doing it in the knowledge that at least 39 teams of people would be playing with my creation.

Secondly, in telling my non-geek friends that I was entering this competition, I received all sorts of interest and support in what I was programming to a level I’d not experienced before.  It was both humbling and refreshing to be able to talk to my non-geek friends about what I was programming without a familiar glazed look descending on their faces.

Thirdly, I really enjoyed playing the other teams’ games and learnt a lot from doing so.  It was interesting to see the sheer variety of games and the creative thought that went into them.  It was also interesting to look at the code behind the games.  For me this was a real win and an affirmation that you learn most about coding from reading others’ code.

As mentioned previously, my entry was Voices Under Water and was written using the excellent pyglet and cocos2d libraries.  The game is based around a dolphin who has to catch life rings being thrown by a ship’s captain to save his crew from drowning.  It’s probably not the most exciting story, but I found myself writing the game then shoehorning the story onto it, and that was the best I could come up with!  Coming up with the name of the game was much easier.  My other half’s niece and her boyfriend are part of a band formerly called The Bacchae and more recently called Black Moth.  They kindly gave me permission to use one of their tracks which is fittingly called Voices Under Water as the backing music for the game.

Many thanks to the organisers and to the other teams for an enjoyable competition!

The PyWeek challenge:

1. Invites entrants to write a game in one week from scratch either as an individual or in a team,
2. Is intended to be challenging and fun,
3. Will hopefully increase the public body of game tools, code and expertise,
4. Will let a lot of people actually finish a game, and
5. May inspire new projects (with ready made teams!)

This is the eleventh iteration of PyWeek and the first one I’ve entered.  The theme for this iteration is the word ‘caught’.  My entry is called Superfly Funky Stuff though the game itself is really called Voices Under Water.  I’ll write more about what I’m coding in due course, but here’s a sneak preview:

Voices Under Water

And here’s a picture of my other half, Annie, recording splashing sounds in the bath for some DIY sound effects!

My nephew, Bob!

There was a brief period in the 1980′s as the home PC revolution was picking up speed when we thought we would all have to learn how to program a computer. Computers were taking over the workplace and without this skill we would all be unemployable. That brief period ended with the rise of the office suite and the advent of email. For many jobs we’re now expected to have familiarity with word processors, spreadsheets, email and web browsing. You only really have to know how to program if you’re a programmer, whether hobbyist or professional, but that goes without saying. One could argue that the evolution of our technological society where programming is mainly restricted to dedicated programmers is a natural division of labour. Why should a secretary or an advertiser or a salesperson need to program? Why would a 10 year old need to program?

Bob can often be found discussing the merits of the computer games he plays and how they might be altered or improved. For example, earlier this week he described how he’d like to play a game which was a first person shooter where the enemy stood still and only fired back several seconds after being discovered. The game description was accompanied with much hand waving and shooting noises. There were further descriptions of the types of guns that should be available and when they should be made available to the player.

Bob’s vision of a new computer game was born from a creative process. What Bob needs now is a medium of creative expression to bring that vision to life. In the same way a musical instrument can be used to create an infinite variety of music, or a word processor can be used to create an infinite variety of novels, it is through programming that you can create an infinite variety of games, and programming is the medium of creative expression.

Michael Sparks asked the question: If you were 7 again, what would you expect to find in a book on beginning programming? Apart from the usual conditionals and loops (I can hear the writer of the fictional Functional Programming for 7 Year Olds groaning) it would make sense to fulfil our junior members of society’s primal need to play, adapt and create games.

Armed with the knowledge that learning to program was the path to learning to create computer games, Bob was all too happy to sit down with me and walk through some basic Python programming. We started with a simple quiz game. The first decision was to whether to choose Python 2 or Python 3. I figured that extensive library support wasn’t necessary for writing a quiz so I plumped for Python 3.  With Python 3, you also get to avoid being asked sticky questions such as:

Why is it called raw_input() and not input()?

…  and …

Why does raw_input() have brackets and print doesn’t?

The quiz went down very well and we got to touch on several Python constructs. Here’s a cut down version of what we wrote together:

score = 0

fvcolour = input('What is my favourite colour? ')
if fvcolour == 'red' or fvcolour == 'blue':
    print('Correct!')
    score = score + 1
else:
    print('Incorrect!')

sport = input('What is my favourite sport to watch? ')
if sport == 'football' or sport == 'Football':
    print('Correct!')
    score = score + 1
else:
    print('Incorrect!')

print('You scored', score, 'out of 2')

Bob was very excited by this.  He was particularly excited about the fact that he could get the computer to ask any question and respond to any answer in any way he wanted it to.  After helping him install Python 3 on his own computer and showing him how to use IDLE, he sat about creating more intriguing and inventive quizzes.

I was conscious of the fact that I only see Bob once in a while so I set about looking for an online tutorial he could follow.  I was also conscious of the fact that he really wanted to write games, specifically first person shooters with advanced sound and graphics!  A few weeks ago I attended the informative and entertaining tutorial Introduction To Game Programming given by Richard Jones at Europython.  Richard pointed us to Invent With Python, an online (and dead tree) book “written to be understandable by kids as young as 10 to 12 years old” teaching them how to program games using PyGame.  And it has been updated to Python 3.  Perfect.  Bob is busy working his way through the book and I can’t wait to play Bob’s first person shooter!

How would you introduce your 10 year old nephew / niece / daughter / son to programming?