Django Posts

I was debugging an issue with our Django app at work today; an admin.py file wasn't being picked up, and nothing was appearing in the admin pages. It turned that an ImportError was being thrown in the admin.py and Django was interpreting this as the file not existing.

I'm assuming that the reason for this is that Django uses __import__ to import the module, and catches ImportError's if the admin.py doesn't exist. The trouble with this is that if admin.py does exist, and throws an ImportError of its own, Django will also interpret that as a missing admin.py – which can be misleading. continue reading…

I figured I would write-up some of the features of Django Techblog, the blogging application I wrote to power this site. It does most of what you would expect from a blogging app, but there are a few features that it does differently. The main difference is extended markup, but there are a couple of other features that worthy of note:

The code for Django-techblog is licensed under my politeware license, which means you can use it for any purpose you see fit, but I would appreciate a thank you! It shouldn't be too difficult to set-up if you have worked with Django, but I'd be happy to help if you experience any problems with it. See the Google Code page for the SVN url:

http://code.google.com/p/djangotechblog/

I've been toying with optimizing the caching on my blog recently – for my own interest (this humble blog doesn't get all that much traffic). All the same, any speed improvements will only mean snappier page-loads and greater capacity to handle a slashdotting, or similar.

I discovered that Nginx has a memcached module that can serve pages directly from memcached without touching the file-system, or a downstream web-app. Which makes for very fast response times. To get it working, you need to set a cache key named with the url of the page, and the value to the HTML. Alas, this means that it would not work with Django's caching mechanism due to the way Django caches unique pages based on the contents of the request header. continue reading…

Django Tech Blog is now running my blog. It is only fitting that my first post on the new system is about the technology behind it.

I never intended to compete with Wordpress on number of features, and Techblog was never intended to be an all-things-to-everyone type of web application, but I can boast a few features that set it apart. I'll cover some of those features in future posts, for now I would like to go over the light-weight markup language I use for posts. continue reading…

The new Django blog system I have been working on is virtually finished, I'm just testing it at the moment. Now I know that by writing my own blog system I will miss out on all the capabilities of a full featured and mature system, such as Wordpress; but my new system -- which I call Django Techblog -- has a few features that Wordpress doesn't, but more importantly, it works just the way I want it to.

One of those new features is the ability to insert syntax highlighted code in to comments, which is very useful for a techy blog! I've created a post on the beta site, and I'd like to invite you to pop over and test the commenting system. I'll delete the comments when I'm satisfied it is working nicely and I can replace www.willmcgugan.com. So feel free to play about with it...

Django has pretty good support for caching, which is one of the easiest ways of speeding up a web application. The default is to cache for ten minutes, which means that if you get multiple requests for a page within a ten minute window then Django can serve up a stored copy of the page without hitting the database or rendering the HTML. The caching period can be set per-page and fragments of pages can be cached rather than the whole, but the system rests on the fact that it doesn't matter if the content doesn't change for a period of time. continue reading…

Since Net Communities have their new developer, I can post the coder test I wrote to find a replacement. The test was not meant to be particularly challenging, and we only requested that developers do one out of the three problems. Most developers did all three--presumably in an effort to impress--but nobody got all three correct, first time around. That was probably my fault, because the third problem had a subtle issue that is easy to overlook.

I'll quote the problems here, including typos. Occasionally the way I phrased things was slightly ambiguous, but I didn't penalize if the candidate misunderstood a requirement due to my use of language.

Example input:

microsoft

apple

microsoft.

Apple?

security

microsoft

internet

Example output:

microsoft 3

apple 2 continue reading…

My current employer, Net Communities, is looking for a Python / Django developer to replace me -- I'm moving to Oxford to work on a very interesting Django site. I can honestly say that Net Communities has been a fun place to work, and if it wasn't for the fact that I'd prefer to live in a smaller place than London, I would still be there. Net Communities is based in Farringdon, London. See the job ad for more details.

To filter out the developers who are bluffing, I have devised a series of programming tests, each more fiendish and difficult than the next. Actually, they aren't difficult at all. The tests are just some of the typical tasks that you might need to do for a Django site. You will be sent a link to the test if you apply.