Posts RSS Comments RSSTwitter 8 Posts and 4 Comments till now
This wordpress theme is downloaded from wordpress themes website.

PyWeek

I’m currently involved in PyWeek, a game writing competition where entrants are given exactly one week to write a game from scratch in Python.  To be honest I’m not much of a gamer, but I couldn’t resist the creative challenge of writing a playable game in one week and I’m loving every minute of it.  As the front page of http://www.pyweek.org states:

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 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!

Why should kids be interested in programming?

My 10 year old nephew, Bob, loves computer games. In fact, I think it would be fair to say that most self respecting 10 year olds love computer games and wonder what else a computer is for apart from computer games, Facebook, Bebo, and the occasional use of that legacy communications medium called email.

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?

Python Northwest Returns

Just under a year ago a group of like-minded people in the Northwest of England with excellent taste in programming language got together for Python Northwest.  The plan is get together again this month.  Whether you’re a beginner Pythoneer or a seasoned Pythonista, or if you just want an excuse to go to the pub, then this meeting is for you!

Details are as follows:

  • When: Thursday 19th August 2010, 6pm
  • Where: Rain Bar, Manchester:
  • What: A social meet to chat about stuff we’ve found interesting / useful / fun with Python recently.  Topics likely to include games, robots, web programming, GUIs, parallel processing, audio generation, tips and tricks, and just about anything heard, said or done at the recent Europython conference.
  • Contact:

Building on the well attended and fun meetup organised by Michael Sparks last year, the hope is that Python Northwest will continue to meet every third Thursday of the month starting with social meets then alternating between social meets, technical meets and perhaps coding sessions.

Please forward, tweet and dent this to anyone or anylist you think might be interested, then email python-north-west@googlegroups.com to say you’re coming along!

See you there …

Python And Unicode

For many a novice Python programmer, particularly in the English-speaking world, their first brush with Unicode is with this error:

UnicodeDecodeError: 'ascii' codec can't decode
   byte 0xc5 in position 0: ordinal not in range(128)

Now I realise that much has been written about Unicode already, but for me it has always been one of those topics that goes in one ear, sticks around while I’m using it, then gradually makes its way out of the other ear when I’m least expecting it.  Last year I read the excellent “Natural Language Processing with Python – Analyzing Text with the Natural Language Toolkit” (http://www.nltk.org/book) by Steven Bird, Ewan Klein, and Edward Loper.  An interlude in Chapter 3 discusses Unicode in a refreshingly clear and brief way and I now feel that the topic is well and truly understood.

I thought I’d write a quick cookbook as an aide-memoire, not about Unicode per se as there are many good articles already (see http://www.joelonsoftware.com/articles/Unicode.html for a thorough intro and history), but specifically about Unicode and Python, and to showcase the differences between Python 2 and Python 3.

1. Unicode is a representation of characters where each character is uniquely represented by a number called a code point.  Unicode literals are represented in Python as follows:

Python 2:

>>> print u'This is Unicode'
This is Unicode

Python 3:

>>> print('This is Unicode')    # Strings are unicode in Python 3
This is Unicode

2. Non-ASCII literals can also be represented in a Python file if the encoding permits.  The default encoding for Python 2 is ASCII whereas the default encoding for Python 3 is UTF-8.  The file encoding can be changed with the appropriate stanza at the top of the file.

Python 2:

# -*- coding: utf-8 -*-
# The following string is Unicode represented in UTF-8 characters.
print u'This is also Unicode. Mañana!'

Python 3:

# The following string is Unicode represented in UTF-8 characters.
print ('This is also Unicode. Mañana!')

3. All Unicode characters can be represented with an escape sequence regardless of the file encoding:

Python 2:

# 1, 2, and 4 byte unicode chars are represented in hex with
# \xnn, \unnnn and \Unnnnnnnn respectively
>>> print u'This is also Unicode. Ma\xf1ana! Ma\u00f1ana! Ma\U000000f1ana!'
This is also Unicode. Mañana! Mañana! Mañana!

Python 3:

# You can do the same in Python 3
print('This is also Unicode. Ma\xf1ana! Ma\u00f1ana! Ma\U000000f1ana!')
This is also Unicode. Mañana! Mañana! Mañana!

4. The Unicode standard does not cover how text is represented in a file.  When it comes to writing text to a file, a particular encoding will be used.  The UTF-8 encoding can efficiently represent all Unicode characters.  Write to a file with a particular encoding as follows:

Python 2:

>>> txt = u'Ma\xf1ana!'
>>> with open('file.txt', 'w') as f:
...     f.write(txt.encode('utf-8'))

Python 3:

>>> txt = 'Ma\xf1ana!'
>>> with open('file.txt', 'w', encoding='utf-8') as f:
...     f.write(txt)

5. A file of text is just a file of binary data unless the encoding is known.  A text file with a given encoding is read as follows:

Python 2:

>>> import codecs
>>> with codecs.open('file.txt', encoding='utf-8') as f:
...     print f.read()
Mañana!

Python 3:

>>> with open('file.txt', encoding='utf-8') as f:
...     print(f.read())
Mañana!

6. A special encoding peculiar to Python is “unicode_escape” which encodes a Unicode string into a Python 2 string or a Python 3 bytes object with the appropriate escape sequences.  For example:

Python 2:

>>> tomorrow = u'Ma\xf1ana'
>>> print tomorrow.encode('unicode_escape')
Ma\xf1ana

Python 3:

>>> tomorrow = 'Ma\xf1ana'
>>> print(tomorrow.encode('unicode_escape'))
b'Ma\\xf1ana'

7. To get the code point for a Unicode character:

Python 2:

>>> print ord(u'\xf1')
241

Python 3:

print(ord('\xf1'))
241

8. To get the unicode character for a given code point:

Python 2:

>>> print unichr(0xf1)
ñ

Python 3:

>>> print(chr(0xf1))
ñ

9. And finally, the unicodedata module has some useful functions worth knowing about.  For example, to get the name of a given Unicode character:

Python 2:

>>> import unicodedata
>>> print unicodedata.name(u'\xf1')
LATIN SMALL LETTER N WITH TILDE

Python 3:

>>> import unicodedata
print(unicodedata.name('\xf1'))
LATIN SMALL LETTER N WITH TILDE

References:

[1] Natural Language Processing with Python – Analyzing Text with the Natural Language Toolkit – Text Processing with Unicode
[2] Unicode HOWTO (Python 2)
[3] The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) by Joel Spolsky

Python 2.7 Released

The production version Python 2.7 is now available. Several features from Python 3.1 have been backported including language features such as the syntax for set literals, dictionary and set comprehensions, and multiple context managers in a single with statement.

These are great features of Python 3 and I’m sure I’ll use them in my Python 2.7 code, but I can’t help wondering if they also reduce the motivation for developers to move to Python 3. Are there enough compelling Python 3-only features to help promote the “upsell”?

MongoUK

MongoUK has been and gone and the day went very well. Many thanks to the 10gen guys who sponsor MongoDB for putting on a great meeting. My head is spinning with thoughts and ideas about MongoDB and the host of possibilities it clearly opens up for many classes of application.

It was interesting to learn that MongoDB was born primarily out of a desire for high performance and horizontal scalability i.e. the ability to scale out to multiple nodes as needed. Other properties such as its non-relational and schema-free nature are happy side effects as joins and the maintenance of referential integrity are difficult in a highly parallel environment. It also explains why there is no strong drive to implement transactions, a feature completely absent from MongoDB which is not only hard to implement in a highly parallel environment but would also be detrimental to performance.

Some stand-out features of MongoDB discussed at the meeting include the following:

  • MongoDB is schema free and far more capable than simply storing arbitrary key / value pairs. MongoDB stores BSON documents, a binary JSON format meaning that data of any complexity and nesting can be represented.
  • Through the use of BSON, MongoDB understands several basic data types including integers, strings, floating point and datetime. Many similar databases only support strings and perhaps numeric data types usually leaving the developer to do some parsing in their application.
  • Indexes can be created at any level of nesting in a document, and significantly, an index can be created on an array. Imagine a database full of objects with nested attributes one of which is an array of tags then rapidly searching for all objects with a given tag.
  • A large number of drivers are already developed and well supported.
  • MongoDB has extremely rich query support. Apparently the developers considered using SQL as the query language but settled on a JSON query format. The result is an expressive query language which is satisfyingly symmetrical to the nature of the data being queried upon.

In my previous post I hoped to learn whether MongoDB would be a good solution to storing and querying our arbitrary key value data. MongoDB would clearly solve some of our issues and I look forward to putting MongoDB though its paces over the coming days and to assess it with respect to other document-oriented databases.

Will MongoDB Save The Day?

I’m greatly looking forward to attending tomorrow’s MongoUK, the UK meeting for MongoDB, one of a new breed of so called document-oriented databases.  I thought I’d pen a few thoughts about MongoDB and document-oriented databases in general before the meeting so I could compare them to my thoughts after the meeting.

MongoDB is “a scalable, high-performance, open source, document-oriented database”.  The terms scalable, high-performance, document-oriented, object-oriented, non-relational, schema-free, key/value store, and NoSQL are all used interchangeably for this class of database.  All serve to describe the qualities of this class of database whilst at the same time muddying the water a little by providing multiple and sometimes conflicting reasons for choosing them, or more commonly, for switching over from the commonplace relational database.

I’ve followed the rise and rise of document-oriented databases with interest over the last few years and I often sense that the reason for making the switch is to latch onto one of the qualities mentioned above then try hard to make the other qualities work.  For example, to make the switch to gain massive scalability then work around the loss of SQL and rich query functionality.  The other reason to make the switch is that these databases are new, cool, often a joy to work with, and a refreshing change from the confines of the relational database.  I’ll be the first to put my hand up and favour these reasons for considering the switch for certain applications.  More specifically, I’m investigating the use of a schema-free database whilst contemplating what this might mean with regard to database transactions, referential integrity, and the ability to query your data.

For several years I’ve worked on an application called Asset DB which records the location and attributes of company assets.  There’s no end to the different attributes that might belong to an asset, for example, Serial No, Colour, IP Address, Installation Date, and this list very much depends on the type of asset, for example, a piece of artwork will have an Artist but a PC will have a MAC Address.  Added to this, there’s no end to the different types of asset which might be recorded from artwork to waste-bins to paper-clips.  Asset DB uses a relational database and we were faced with the conundrum of how to structure and store this mish-mash of data.  The problem is not unlike the question of how to store tag data in a relational database (see http://forge.mysql.com/wiki/TagSchema for opinions on how this might be done).  As it happens, we completely side-stepped the issue and simply lumped the attributes into a single string field structured in our own format, in effect, turning the field into a flat file.  The following gives you a rough representation of the schema we used:

 +----+------------+------------+-------------------------------------------------+
 | id | date_added | asset_type | attributes                                      |
 +====+============+============+=================================================+
 | 1  | 2010-06-16 | PC         | assetno=ABC010,colour=blue,mac=00:11:2:33:44:55 |
 | 2  | 2010-06-17 | Artwork    | assetno=ABC020,artist=Picasso,value=$20000      |
 +----+------------+------------+-------------------------------------------------+

The clear advantage is that we can store any key / value data for any asset.  The disadvantages are numerous:

  • There’s no possibility of using standard database constructs for maintaining structural integrity of the data.
  • Over time, our needs have changed and we’ve had to devise way of storing more complex data structures such as lists, maps, time-series data etc.
  • To read even a small part of the data requires reading in the entire string of attributes then parsing it.  Also, any change to a small part of that data, for example, to amend the artist on a piece of artwork, requires reading, parsing, changing then writing back the entire string to the database.
  • The ability to query the data is severely limited, for example, to find all artwork by Picasso, we can’t use the database to do the query for us.  Instead every reference to artwork in the database has to be read and parsed, or some sort of full-text search is needed.  Additionally, opening the database to third parties isn’t as simple as saying “here’s the database, now run some SQL as you please”.

To be fair, we could have formatted our data in something like XML or JSON (although the decision was made prior to to standardisation of JSON), and perhaps we could have used an XML or object database rather than a relational database, but our needs were very simple at the time.  I’d be interested to learn how others have implemented the above in their applications. Meanwhile, I’m hoping to learn whether document-oriented databases might be a good solution.

Why MongoDB?  I was first introduced to MongoDB about a year ago and I’ve played with it a few times since then.  It appears to provide a good balance between providing a schema free database whilst retaining the ability to richly query your data.  As the front page of the MongoDB web site says:

The Best Features of Document Databases, Key-Value Stores, and RDBMSes.

MongoDB bridges the gap between key-value stores (which are fast and highly scalable) and traditional RDBMS systems (which provide rich queries and deep functionality).

Perhaps this is exactly what our application needs and I’m looking forward to learning more tomorrow.

The Collective

Yesterday evening I took a visit with my other half and her mother to see the Manchester Beekeepers Association at work in the beautiful Heaton Park.  The setup is truly amazing with countless hives, a honey extraction room, a specialist library and a fascinating glass fronted observation hive where you can clearly watch the bees go about their business, and presumably they can watch you too.  Apparently there are an estimated 2 million bees in residence there.

Beekeeping in Heaton Park

It’s no secret that, like many self respecting techies, I like to watch the odd episode of Star Trek now and again.  Having watched far too many episodes of Star Trek Voyager recently, I was interested to note that whenever the word “hive” was mentioned, I’d instantly think of The Borg, a fictional lethal enemy with a collective conscience often referred to as The Collective or The Hive Mind.  Words (particularly English words) can have many different meanings depending on the context.  Even after a sentence with the word “hive” was understood, my mind still jumped to the primary context, or at least the most recently used context in a given time period, in this case, The Borg.

Funnily enough, our route home took us down Singleton Road.  Although the word “singleton” generally means something occurring singly, I have only every used this term in programming to mean the only object of a given class.  This made me think of other “borged” words, i.e. words whose primary contexts have been hijacked because I spend much of my time programming:

  • Program: a computer program rather than a TV program.
  • Class: the definition or template for an object rather than a group of children at school.
  • Java: a programming language rather than a cup of coffee.
  • Cloud: a network of servers hosting an application or service rather than those fluffy things in the sky.

Add to that memory, mouse, disk and the list goes on …

The Manchester Beekeepers Association holds regular courses which we’re looking forward to attending with a view to doing a spot of beekeeping after that.  I wonder if I’ll think of the bees in Heaton Park the next time I watch an episode of Star Trek!