I've ended up a bit discouraged about my Sugar involvement (there's probably a blog post about lessons learnt in there, after I finish processing events in a useful way) so I decided it'd be best to step back for a while and digest things in the background before trying again. In the meantime I thought it'd be cool to remove the dust from my old, old, old Moodle plug-in back from college.

Various things learnt, re-learnt and discovered over the past couple of days:

• Remembered my old tip of appending a version number to the Moodle folders in /var/www/ and /var/wwwdata/ so I can install multiple versions of Moodle in parallel without having to remember which version is in "moodle"
• Could not install nor find a threaded mod_php5 Apache module in my Debian repos, had to remove apache and install apache2 prefork instead. To be investigated still, I want to understand why the repos are set up this way.
• Learnt to check http.conf for port conflicts before installing a new module. Django and mod_wsgi trying to read my PHP files on port 80 did not work well.
• After updating the mod_wsgi port in httpd.conf, without having to add or configure anything the php files were running with no issues -- surprising and cool!
• New Moodle point version, woohoo! Go 1.9.8, as smooth to install as usual.
• Happy surprise: my plugin, DVReport, installed and worked properly! Guess there was no major architectural change between 1.9 and 1.9.8... ;)
• Nasty surprise: visualisations (the core of the plugin) were not working
• Realisation #1: using double-quotes (") to delimit text in not proper SQL. This is pretty sad considering how much effort and agony I spent worrying about creating database neutral queries at the time.
• Realisation #2: MySQL is way too kind with horrible, broken, standardless SQL. I must have been tight on a deadline (or on crack) when I wrote one particularly crazy GROUP BY statement. I'm guessing MySQL just ignored the bits that didn't make sense, but since working on this plugin last I've fallen in love with PostgreSQL, who isn't so kind (sloppy?) in parsing queries. I'll keep using Postgres as my main backend (<3), but will be testing with MySQL as well for this plugin considering I'm apparently unable to write db neutral SQL the first time around :)

The project had remained untouched since October 2008, according to GitHub. Since then GitHub has acquired an issue tracker (major YAY!) and a download tab so I cleaned up the wiki (who'd been upgraded and wasn't parsing all the old syntax anymore either) and set those up. Now the only horrible thing that's left, is all that dreadful code... ;)

I attended for a couple of hours the Synchronous Hackathon in Tog today. I had vague plans on making progress with the Moodle plug-in, probably related to the unit testing / refactoring of the data crunching methods... Didn't happen, but I did find a new bug, which I managed to fix 10 minutes before my battery went down. Wince-worthy, a couple of global variables (ouch) not being cleared properly in various places, but still -- progress! I'm happy with the day, it was good fun. Now, to see if I can hook Geany saving function to a shell script I have to execute manually each time...

Over the week-end I rediscovered Moodle's DEVELOPER debug setting which surfaced many unpleasant warnings. The first kind was removed by following proper programming practices (ahem), the second kind involved a couple of deprecation warnings that reminded me that Moodle is slowly and surely making its way toward 2.0. I filed a bug about this against DVReport, I should be looking into that one over the summer (Moodle 2.0 release date is July 20th! It's so strange to see an actual date, after years of reading about the preparations. Sounds awesome :))

The old navigation bar, pre-1.9.8 I assume though I'm not sure when it was deprecated, used to look like this:

$navigation = '<a href="$url">$block_name</a> -> $action_name';

The "->" would indicate a separation between 2 links, and automatically generate a nice triangle picture in the breadcrumb.

With the new navigation style, you get to split up the different sections into different arrays. It might seem more cumbersome but I think in the end it's neater, because you get to make a distinction between every element of the navigation, as opposed to one long messy string where you can easily miss the arrows when reading. The visual output is the same.

$navigation = build_navigation(array(
        array('name' => $block_name,
            'link' => $url,
            'type' => 'title'),
        array('name' => $action_name,
            'link' => '',
            'type' => 'title')
        )
    );

The only meh thing about this is that "type" isn't really documented. The phpdoc comment reads "this really needs to be documented better" and lists a few values. As usual, there isn't one that quite fits what DVReport does, because DVReport is a block, not an activity or course module. So I picked 'title', which seems innocent enough -- we'll see what future updates to the core navigation bar code make out of that!

Feeling a bit anxious about ash clouds, but looking forward to the conference!

Initially I followed the Django documentation and the mod_wsgi documentation to run Django on my local Apache server, but after installing mod_php5 the 2 modules began conflicting with each other when I wanted both to run peacefully in parallel.

PHP was to keep the default port 80 and Django was to run on port 9000. Here's how I triumphed over the slew of Error 500:

1. <VirtualHost *:9000> for WSGI

2. Add the following statement before the <VirtualHost *:9000> line (that's the bit not mentioned in the documentation I was following, and that I want to document here for $future_self...)

Listen 127.0.0.1:9000

3. Update the MEDIA_URL in settings.py to reference port 9000 as well.

And they all lived on their respective port happily ever after.

While trying to make the archive pages of this site more useful, I had a bit of trouble working with Django's annotation feature to give me the numbers I was looking for. I wanted to show on the index page how many posts were published in a given month. This ticket was very helpful to figure out how to do it, and as a bonus it means it will work more simply in future-Django :)

At the moment, the workaround is unfortunately database specific. The ticket contains an example using SQLite, here's how I did it using PostgreSQL. I think with MySQL you'd need to play with YEAR() and MONTH() to get the same.

bymonth_select = {"month": """DATE_TRUNC('month', creation_date)"""} # Postgres specific
months = Article.objects.exclude(draft=True).extra(select=bymonth_select).values('month').annotate(num_posts=Count('id')).order_by('-month')

I removed a couple of filters for readability, but this is basically a normal QuerySet with a couple of Django caveats:

1. Write your filters before the annotate call, as the Count() processes only what comes before it
2. .values('blah') for a GROUP BY effect, without it you'll get '1' for every record fetched back
3. .order_by(), with or without an argument otherwise things will likely get messed up by the order_by of your Meta class if any -- inspired by comment #8 of the ticket linked above, thanks!