Purple Metadata in Blosxom

PurpleWiki supports document metadata. The metadata is stored at the beginning of the document using the following syntax:    (6Y)

  {name value}    (6Z)

Currently, PurpleWiki supports the following metadata:    (70)

All of this metadata is available to blosxom via the purple plugin under the $purple namespace. However, I’d also like to override blosxom’s mechanism for determining an entry’s title and date.    (77)

Sadly, overriding the title mechanism is not possible via plugins, and overriding the date would be extremely inefficient. Blosxom assumes that the first line of a file is the title and the rest is the body. This parsing happens before story() is called. This works fine, but it means that the raw file itself can’t be a pure PurpleWiki document. If blosxom instead passed the raw file and delegated the responsibility for parsing title and body to story(), then anyone would be able to customize this behavior via plugins.    (78)

I also wanted to duplicate the behavior of the entries_index_tagged plugin using PurpleWiki‘s metadata. The way entries_index_tagged works is to compare the current directory tree with a cached tree. If there are discrepancies, entries_index_tagged scans the file for a meta-creation tag. If the tag exists, it uses that information; otherwise, it stats the file for its creation date.    (79)

I could easily pass the file to the PurpleWiki parser to scan for the creation date, but the PurpleWiki parser is expensive, and the parsed file would not be cached. If I opted to use an entries_cache approach instead, where the comparison only happens once an hour, then maybe it wouldn’t be too much of an issue. However, I don’t want this feature badly enough to do this, and frankly, the inefficiency of doing it this way gnaws at me.    (7A)

A Unit Test Success Story

I spent the past few days closing out PurpleWiki bugs in preparation for our impending v0.9 release. And once again, unit tests saved my butt.    (3I)

Automated unit tests are like programming with a net. You invest a little bit of time up-front writing the test, and then you save a ton of time later. Most importantly, unit tests give you confidence to experiment. You can dramatically refactor your code without worrying about unknowingly breaking something.    (3J)

I’ve used unit tests on a number of small projects, and have been pleased, but not overwhelmed with the results. However, my experiences with unit tests and PurpleWiki have been extremely gratifying. Our unit tests have consistently caught bugs that might otherwise have stayed hidden for months, even years.    (3K)

Extreme Programming (XP) advocates writing tests before writing code. I cheat a bit here. I usually write a few test cases, write the code, then write the automated unit test. Same goes for bug fixes. More importantly, we mandate a unit test for every bug fix. If changes to the source code revive an old bug, the corresponding test will catch it immediately.    (3L)

On a related note, I ran into Chris Sepulveda, an old college acquaintance, last week. He’s been an XP consultant for several years, and he recently moved from NYC to the Bay Area. We had an excellent discussion about XP patterns and adoption. In particular, he bemoaned how narrow thinking about the methodology prevented many people from incorporating it into their processes effectively. XP is as much about philosophy as it is about methodology.    (3M)

Chris is loaded with good thoughts, and is slowly but surely sharing them with the rest of the world on his blog.    (3N)