Today I set out to get my own software running.  This included dependencies like:

1. Apache
2. Mod_python
3. Postgresql
4. Tsearch2
5. Psycopg2
6. elementtree
7. Simplejson
8. Matplotlib
9. Apple

I wasn't difficult to install and configure things, though it obviously felt different than it does on Gentoo.  Honestly things seemed less organized, though that's likely because I know Gentoo so much better.

I have not been successful in getting mail-notification to work.  Poking around it seems the imap ssl support is disabled, and people recommend installing from source.  This means that to date, the only two pieces that have given me grief have been Flash and mail-notification.  From a polish perspective Ubuntu continues to be excellent.  I have also been impressed with the functionality of apt, though it's no Portage.  For example when I installed flash, the installation failed though apt registered it as installed.  This meant subsequent attempts required the use of --reinstall.  This isn't a big deal, but Portage is much more ~acid.  The dependency lookups don't seem to be as reliable either.  For example installing eclipse-jdt should have pulled eclipse as a dependancy.  Installing psycopg2 should have pulled python-egenix-mxdatetime as a dependency.  I also found apt's presentation difficult to read.  Portage uses colors and indentation for a much nicer presentation.

From a performance perspective I'm not sure what to think.  I tend to not trust myself when judging the performance of a desktop machine (so many variables) but it does seem to be significantly more sluggish.  I've even noticed the processing time of my own code seems to be slower.  Consistently my pages process in ~0.05 seconds.  On Ubuntu they seem to be running  around ~0.2 seconds.  That's pretty rough though I'm not sure what's responsible (ext3 vs reiserfs, compiler flags, etc).

Today's outcome:  I'm very impressed with Ubuntu, though currently I'm probably 50/50 on whether I might switch.

Yesterday I rolled a new Apple release and moved some site changes to my prod server.  After doing this mod_python went nuts throwing assorted exceptions about the "recursion limit" being exceeded.  After some troubleshooting it seems that the python-json module bundled with Apple was returning an empty string when json.read() was called (regardless of whether the string in question was valid JSON or not).  Next I need to determine why my code became so angry when session wasn't completely available.

This isn't necessarily significant, but considering I had already deployed the exact same code base to a dev and stage server... I didn't expect to run into any problems.  In fact I think this is the first time I've ever had my code work so differently in prod as it did in dev/stage.  Eventually I gave up on trying to determine why python-json was returning empty strings and simply replaced it with another Python JSON implementation.  I chose to use demjson simplejson which is now running beautifully.

While troubleshooting my failed upgrade I also stumbled across two defects.  Apple was duplicating all session keys in the database because it wasn't resetting properly after the db commit.  I bundled this fix into the 0.2.4 release.  I also realized that I need to stop procrastinating and "eggify" the Apple build process.

All is finally well

Last night I added rss v2 and Atom support to my blog.  Both feeds seem to validate properly, though defects will probably surface until I get more familiar with how blogging actually works.  I also rolled Apple v0.2.5 mainly to include a fix in the calendar.  The calendar was using a by-reference copy of self.page.get and thus it was changing the object itself.  Using copy took care of that (I had been pulling my hair out trying to determine why self.page.get was loosing elements).

It seems to be that time of year again for Lucy to want a boyfriend.  Poor thing can't seem to relax.  She keeps panting and licking everything.

I've been working long and hard now for the past three months writing a brand new version of this website.  It's written from scratch, and uses all sorts of neat technologies.  There were a few different reasons why I took the time to rewrite everything.  The most important reason probably was that my codebase was getting really crazy and difficult to maintain.  It's much cleaner now, and far easier to extend and maintain.  Another reason was that I needed a proof of concept for Chula, the framework that has replaced what I was using Apple for.  Apple was my first Python project, and was pretty crappy.  Chula is much better I think, and might actually be something people might find useful  :)

I'll be watching for bugs over the next few days, but wee it's finished!

Recently a friend of mine pointed out that I had an error on one of my pages.  It took me almost 45 minutes to figure out what was happening.  I wasn't able to reproduce the defect in my development environment.  The version of Python installed was exactly the same.  I tried executing the problematic piece of code on the production server and it did not reproduce the problem.  All of my unit tests passed... I was at a loss as to the source of the problem.

It just so happend that a few months ago I had turned on a particular configuration option in Apache that influenced the way Python works.  The reason why I wasn't able to reproduce the problem in dev was because it does not use a production configuration.  The reason why I wasn't able to reproduce the problem using a Python interpreter is because it doesn't care about how mod_python works.  Once I figured out what was wrong the fix was very simple, in fact all I had to change were two letters.

The moral of the story is: Testing is good, unit testing is great, but don't forget to test your configuration  :)

When it comes to performance one of the most important considerations is caching of content.  There are all sorts of approaches to the caching.  Some protect the database from duplicate queries while others protect your application from having to perform an expensive algorithm over and over.  Today I am going to talk about the most aggressive form of content caching when it comes to the web - full page caching.

Recently I was in the process of moving my site to a much better hosting situation (more on that later).  During the move I decided to upgrade from PostgreSQL-8.0 to PostgreSQL-8.3 as I was pretty far behind and I prefer to stay current.  This sort of upgrade isn't a big deal, and I've done it many times.  So I did my usual process:

1. Install the desired version of PostgreSQL (in this case 8.3)
2. Scp my last backup (taken a few minutes after I lock down the site) to the new host
3. Run a script that essentially creates a new db, and restores the backup to it

That's when things went horribly wrong.  After a few searches I quickly learned that moving from 8.0 to 8.3 is a bit tricky when you have tsearch2 stuff in there.  It turned out to be really easy to upgrade, read on if you want to know how I did it.

Chula comes with a guid generator class who's implementation is a bit naive.  Considering Python already has (probably much better) functionality builtin, I figured I'd see how fast they are.

Ever had a situation where you want to send a file to a friend at work or something, and sending it over email makes you feel all dirty?  One way to solve the problem is to copy the file into /var/www/foo or something and send a link... we've all done it.  But there's a better way :)