Backtrac is a pretty old project, and one whose name I am likely to change once I'm working on it. It was started in my first semester of university last year, when I didn't have enough work to keep me busy. I didn't know enough about Django back then, though, so it was left unfinished and only half-working.

Now I think I know enough to pull this off, and it's a chance to do something I really enjoy - while getting marks for it in the process! If everything goes to plan I'll be supervised by Dr. Julie Greensmith, which I'm really looking forward to.

I'll be using an app called Celery to handle the background tasks, which will be simple "pings" to the client machines, telling them to start a backup. Celery uses AMQP, provided by a broker such as RabbitMQ (which is written in Erlang). It's usually used for processing intensive computational tasks, but can also be put to use for jobs that need executing on a periodic basis, like backups.

I can tell you're getting too excited, so I'll stop. Rest assured, though, I will be writing about the discoveries I make along the way to finishing this ambitious project.

The model needed to represent the notion of a university module, which can be taught over a number of semesters and/or years, by different people, and with different students each time round. Some information remained common to each of these modules however, such as the code, name, and type of the module (single semester or full-year).

One solution that crossed my mind was to use a sort of template, and copy the common information over each time the module was taught. This would mean duplicating the common fields over a template model and the module's model, and copying the data every time a new "Module" object gets created. This just didn't sit well with me though, as I really don't like denomalising data when it's not absolutely necessary.

The solution I have settled on (for now, anyway) works something like this: I use the model template idea, but with a foreign key from the Module to it's template. Then, to access the fields on the template directly from the Module model, I use a combination of the Python property and a smart lambda function.

Here's a simplified version of the model to illustrate what I'm talking about:

class ModuleDefinition(models.Model):
    code = models.CharField(max_length=6, unique=True)
    name = models.CharField(max_length=200)
    credits = models.IntegerField(max_length=4)
    level = models.IntegerField(max_length=2)
    type = models.CharField(max_length=30, choices=MODULE_TYPE_CHOICES)
 
class Module(models.Model):
    code = property(lambda s: s._get_definition_property('code'))
    name = property(lambda s: s._get_definition_property('name'))
    credits = property(lambda s: s._get_definition_property('credits'))
    level = property(lambda s: s._get_definition_property('level'))
 
    definition = models.ForeignKey('ModuleDefinition')
    semester = models.CharField(max_length=20, choices=SEMESTER_CHOICES)
    year = models.CharField(max_length=20, choices=YEAR_CHOICES)
    convener = models.ForeignKey('auth.User', related_name='modules_convened')
    students = models.ManyToManyField('auth.User', blank=True, related_name='modules_taken')
 
    def _get_definition_property(self, property):
        return self.definition.__getattribute__(property)

In this model I've called the template a "definition", but the idea is the same. The _get_definition_property() method allows me to get a property from the parent definition programmatically, which is used in the lambda functions to add the fields from the definition to the model itself, as read-only properties. This allows me to access them as if they were a field stored on the model itself (i.e. module.code, module.name, etc.) which is handy in the templates where module.definition.code would get very old, very fast.

I'd be really interested to hear how others have tackled the same issue, as I'm sure it's not just restricted to university modules. Maybe soon I'll be making a post about how I model a timetable in Django...after all, how hard can it be!?

Oh, and if you're wondering, this code is for the MyUni project that is occupying me recently. I'm restricting myself to just thinking about how the models could work (and maybe writing little bit of code) until Rob and Ben come back to university.

The project has gone through several iterations since then, never really reaching any form of completeness. This time round, we are using proper version control (thanks to Mercurial and BitBucket), and trying to adhere to Django best practices as much as possible.

Straight from the repository website:

MyUni is a portal-style web application for Universities, offering students a central location to access all the relevant information about their course, modules, assignments, and staff members.

The project came about because of a passionate hatred for the WebCT system that our university is using, and a general feeling that things could be (and should be) better.

Django 1.2 will bring some really exciting new features, which I am sure would make developing and using MyUni a better experience. One of the things I'm most looking forward to using is the messages framework. I plan to use it for a bunch of things, possibly including form error messages...maybe.

Now, if only the release date would stay in the same place for more than a week!

Recently though, I've been looking in to Mercurial as a more modern alternative. Some things about Subversion are really starting to annoy me, like the inability to ignore files on a repository-wide level easily (I work with Python all the time, so .pyc files can really get on my nerves!). Mercurial seems slicker, and I'm interested in the concept of DVCS, as opposed to the classic client-server way of thinking.

However, Mercurial is not installed on the (rather ancient, now) Solaris servers at university. I really admire the job that the sysadmins do, so I am in no way condemning them for it not being installed. Instead, I set out to get it compiled and working myself.

Installing it on the servers, it seemed, was the easy part. I followed the installation instructions (making sure to include the LD_LIBRARY_PATH variable) and all was well.

Cloning from the server, however, wasn't so easy. The problem lies in the fact that Mercurial is now installed for me, and me alone. The hg binary lives in my home directory, not on the server's main path (i.e. the /usr/bin/ directory). Therefore, I needed to tell the client exactly what command to run on the server. If anyone else is having the same trouble, the command that I finally came up with looks like this:

hg --config ui.remotecmd="LD_LIBRARY_PATH=/usr/sfw/lib PYTHONPATH=~/lib/python ~/bin/hg"

I then aliased this command to hgtuck to save my sanity (the server is named tuck, after Friar Tuck in the Robin Hood legends), and I now have a perfectly working Mercurial install!

If anyone else is looking to do something similar, then I hope this little tip saves you some time!

To answer the questions for the compilers coursework, I wanted my sections to be numbered (1, 2, 3), my subsections to be numbered (a, b, c), and my subsubsections to be numbered (i, ii, iii). This numbering pattern matches that which is given in the question paper, whereby a number of nested enumerates were used. The default LaTeX section numbering however is (1, 1.1, 1.1.1). I finally found a way to alter this default behaviour by using the following code in the preamble:

 \renewcommand{\thesubsection}{(\alph{subsection})}
 
\renewcommand{\thesubsubsection}{\roman{subsection}.}

This code modifies the way that the counters for subsections and subsubsections are printed (section counters are correct when left at the default).

I hope this saves someone even the few minutes it took me to work this out, once I'd applied some logic! It's very useful to know that LaTeX has a counter for everything. This particular post was very helpful in working out which ones to alter, and how.

I've been working with Django more and more lately, and I've written my first "commercial" application using my new favourite framework - a booking system for taught causes at the City Council. I'm really enjoying writing web applications with Django, and I'm sure this blog will start to resemble a web-developer's in the near future.

Also, I'm really looking forward to this year at university. As I understand it, there's a lot more work to be done, but the software engineering group project should be fun - as long as my "randomly chosen" team are happy with us using Python!

Something strange happens to me every time exams come around. I seem to pick up new projects, and just run with them. This time, I've become involved with a small group of people at university, writing a portal-style information system for universities. I suppose most people call this behavior procrastination, but I'm quite deeply in denial about that.

Ever since my post about the Backtrac Backup System, I've been really enjoying using Django. Something about it just makes developing for the web, well, exciting. That can only be good, right? I am the designated server administrator for this latest project, mostly due to the fact that I am the only one with a server to administer, and some of the things I've learned so far seem worthy of a mention here.  Firstly, we as developers were - how can I put it - stepping on each other toes somewhat. The project at this point had no version control, so we were just editing a bunch of files over SFTP. Obviously, some sort of Source Control Management was in order. I did some research, and decided that Git was a nice, modern alternative to the ever-popular SVN. It also meant that my server was constantly backed up by everyone on the team - but that's just a bonus!

So, I installed Git, and started a repository. A lot of effort went into learning how the system works, and more importantly, how to make it work for us. Directed Acyclic Graphs thankfully made some sense to me, so I could just about understance the documentation. I wrote some custom hooks, and a C Program to syncronise the web-server. I was happy, and absolutely certain that this was the solution to all our woes. I was mistaken. Git just didn't work the way I had hoped. The custom hooks were throwing permission errors all over the place, and my development team (read: my friend Rob Miles) was locked out of the repository. We made the decision yesterday to scrap Git, and go back to the previous system of editing the files over SFTP. We are always in constant communication when developing for the project, so it's not too big a deal, but I feel that I failed as an adminisrator. You see, as an admin your job isn't just to play with cool toys and loud servers - your primary purpose is to give the users what they need to work, and that is most certainly not what I achieved.

I'm glad I took the time to learn Git - and I'm sure it will help me later in life, in some way or another. It's just unfortunate that it didn't work out the way I had hoped for our project.

Network Proxy

First and foremost, Ubuntu has a setting in gnome for the Network Proxy, which should set gnome's proxy - but I can't see as it affects anything at all - still, better to be safe than sorry.

At Nottingham University, the recommended configuration is a proxy auto-configuration script (proxy.pac) which is downloaded by the client and parsed to configure the appropriate proxy server. In this case, it is located at http://wwwcache.nottingham.ac.uk/proxy.pac. This URL is entered into the correct field of the gnome Network Proxy settings dialogue.

Terminal Proxy

Secondly, the terminal has a proxy configuration option, so that programs that run inside the terminal making HTTP requests can access the internet - namely wget and aptitude. This is slightly more difficult to configure than the previous, and is achieved like so:

The terminal proxy is set using a variable called http_proxy, which is set using the export command, i.e.

export http_proxy="http://proxy_server_ip:port"

In this case, the proxy server's IP and port for the SNS (Student Network Service) is 128.243.253.119:8080.

This change can be made permanent by editing /etc/bash.bashrc, and adding the above line to the end of the file. Otherwise, the change is only effective in the terminal window currently open by the user, and disappears when it is closed.

Synaptic

Lastly, Synaptic Package Manager must have the proxy set, in order to update your installation using the in-built Update Manager or Synaptic GUI. This is done by opening Synaptic, and choosing Settings, Preferences, and setting the above proxy information using the Network tab. Unfortunately Synaptic cannot read auto-configuration scripts, so the IP and port must be manually entered here.

Obviously once all this is done, Firefox must be configured to use the correct proxy - but I trust you know how to do that! This turns out to be quite a pain, so I'll be looking at ways to do this in one fell swoop. If anyone has any suggestions, then please let me know.

Note: These changes can be made much less painful by adding an entry to the hosts file for each of the proxy IPs you need to configure - so you only need to type the word proxy for example, instead of the entire IP. I will document this process shortly in a separate post.