Programming as if performance mattered

I thought this article

It's very often that I'll be working on a project and focusing on behavior issues when someone will come along and tell me it's not optimized fully. They're right in a sense, but I'm not sure that's important until I get the behavior right. It's not as if the code I'm writing is wildly terrible... it's just a bit unoptimized.

Time to step down

I've passed off Lyntin maintainership to Eugene a few days ago but made the official announcement today on both the mailing list and the web-site.

It's sort of bitter-sweet for me. Sweet in that I needed to drop a project or two because I've got too many. Bitter in that I've spent a lot of time working on Lyntin and I'm leaving with a few things I had wanted to do, but never got around to doing. Even so, it was time to hand it off. So ends a chapter of my development life.

More more static rendering....

I checked in some fixes to the static rendering code and it's working nicely. I fixed my flavour files, made some adjustments to my plugins and then re-rendered everything. My statically rendered site is at /~willkg/test/.

Things the static renderer is not good at:

  • figuring out if an entry has moved from one category to another (you'll probably end up with two versions)

  • comments (if someone adds a comment, that doesn't adjust the mtime on the entry file, so we won't re-render)

  • figuring out if material has changed on other pages (if you add an entry to april on the 4th, the other april pages won't reflect this in the calendar--they would need to be re-rendered but pyblosxom can't figure that out nicely in a general fashion)

Those are somewhat complex problems. One way to fix them is to store a record of which pages belong to which categories and dates. So then if an entry is updated in April, we'd figure out that we really need to update all April entries. That fixes the immediate problem of pycalendar, but doesn't provide a generic fix and I'd prefer not to have to store records of things if I don't have to.

Robert suggested I add a callback for plugins to tell me what urls need to be rendered. If you extrapolate on that, the plugins could also take a look at what's changed since the last time we rendered and figure out the related pages that also need to be re-rendered. For example, pycalendar could implement the callback, get a list of entries that are going to be re-rendered, notice that one of them is in april, and then tell Pyblosxom all the April entries need to be re-rendered as well as the entries in May (because of the "next month" link) and March (because of the "previous month" link). Not sure that's a really wildly good idea. And the effort involved is pretty high. I think it'd be easier on everyone if the suggested fix is to build a cron script that does this:

#!/bin/bash
cd /home/willkg/public_html/cgi-bin/
./pyblosxom.cgi --static
find /home/willkg/public_html/test -mmin +30 -exec 'rm' '{}' ';'

That'll run the static renderer and then remove any file that was modified over 30 minutes ago (i.e. it didn't get touched by the static renderer).

Game economies

I'm totally fascinated by game economies as they generally approximate real economies but usually have "faked" aspects because game economies usually lack feedback loops that real world economies have. Blah blah blah I am not an economist so I'm kind of fudging my English here blah blah blah. Regardless, I still find it really fascinating. I also find game weather systems really fascinating.

Anyhow, there's an entry on issues in the Star Wars Galaxies economic system that led them to discover cheating. It's detailed here. There's some more information on it here.

Added comments to my site

I added comments to my site for two reasons:

  1. I needed to test out the instructions for installing comments in PyBlosxom.

  2. I needed to become more familiar with the comments system since people ask a lot of questions about it.

Anyhow, they seem to be installed and working well. Hoorah.

Fewer plugins

I've decided I don't really need to be running all the plugins I had running. So I've removed a bunch. The good news is that removing a plugin requires the following extremely difficult steps:

  • remove the plugin from load_plugins in my config.py file

If I want to completely eradicate the plugin:

  • delete the plugin file from the file system

  • delete all entries in config.py that have to do with the plugin

  • delete any data files the plugin used from the file system

Anyhow, I'm probably going to install comments, pingbacks, trackbacks, quarter-backs, double-decaf-half-backs, atom, madam, and all the other possible ways for blogs to intertwine with one-another over the next week so that I will finally have an inkling of what all the hubbub is about. [1]

Solving circular import problems with Python code

I keep bumping into circular import problems. While some say it's a symptom of bad design, I'm not wholly sure I agree. Some systems are just really complex. Not everything can be refactored into a pretty little UML diagram.

Anyhow, there's a link on daily python url to Victor Ng's blog entry on his experience with circular import problems with Python. The comments of that blog entry are wonderfully enlightening.

Testing static rendering....

I'm going to write this entry, see if it gets picked up by the static renderer, then I'm going to edit it and see if it gets picked up again.

Ok... editing it.

Neato--works super.