Will's blog

PyBlosxom 1.5 rc1 was released a month or so ago. Since then I haven't had much time to finish things up.

Spaetz kindly did the work to move PyBlosxom source code from svn on SourceForge to git on Gitorious. The plan is to move development to Gitorious and the web-site, documentation, bug-tracking, and things like that to a site on my server bluesock.org.

This enables people to fork PyBlosxom trivially and make the changes they need to make to get PyBlosxom working for them. This will result in more experimentation and work being done and reduce the problem of me and my decision making being a bottle neck in future PyBlosxom development.

The other big change that's happening partially in the PyBlosxom 1.5 timeframe and partially in future versions is the ecology for plugins. Previously, I ignored them and spent my time on PyBlosxom core stuff. Ryan was maintaining the plugins, but the infrastructure we had for plugin maintenance sucked. Going forward, plugins will fall into two categories:

• Maintained plugins will be in the plugins/ directory of the pyblosxom tarball. These plugins will have unit tests and will be versioned alongside PyBlosxom.
• Plugins maintained by other people will be indexed on the website in a registry, but one that will suck less than the current plugin registry.

The plugins that are currently in the contributed plugins pack will be split into those two groups.

PyBlosxom 1.5 is waiting on some more documentation changes, some more plugins work, and now some project infrastructure changes. I'll probably do another release candidate soon and suggest people start using that.

If you're interested in helping out, come hang out on IRC on freenode.net in the #pyblosxom channel. The conversations have been interesting over the last couple of months and have been instrumental in work getting done.

Someone spammed my blog with 400+ comments for some shoes site. Took me less than 2 minutes to skim the emails, see the pattern, and then remove all the spam from my comments moderator queue. This sort of thing is the big strength of PyBlosxom.

I have my blog set up to store comments as individual text files in a comments/ directory. All comments have to be approved before they make it to the site. Approved comments end in .cmt and comments in the moderator queue end in .cmt-. Additionally, comments that contain one of a series of blacklisted words are rejected automatically. Any time someone posts a comment, I get an email.

It took me a minute to skim my 400+ emails and notice they're all kind of the same, 10 seconds to update the blacklist so that I won't get any additional comments like this in the future, and 10 seconds to remove all the spam from the queue with:

   for mem in `grep -rl spamwordhere *`; do rm $mem; done

That was it--spam gone in less than 2 minutes. Took longer to write the blog post about it.

I spent a few hours throwing together a new tags plugin that makes use of the new commandline features of code in PyBlosxom trunk (which will be PyBlosxom 1.5). Then I spent a while adding tags to all my entries.

I'm still mulling over my choice of tags, but I imagine I'll hone it into a set I'm happy with over time.

Also, I used :: as a tag separator, but I think I'd recommend something that doesn't require a shift key to enter. Perhaps ;; or //.

Tag information is stored in two dicts that are pickled and thrown in a file. It seems to be pretty fast to load for my blog (~500 entries). I picked pickle because it was easy, but if it turns out to be a problem, I'd be game for other storage formats.

I've been waiting for tags support before I did more blogging. Now that I've got tags support, I plan to move my work blog here. That'll make things easier and get me off WordPress.

I finished up some additional work and I'm at a testing stage for PyBlosxom. I want to do some more testing and some documentation then it'll be ready for testing releases.

Also, I spent a couple of minutes upgrading my blog to use 1.5 in trunk. Bumped into bunch of weird issues with the comments plugin, but otherwise it was really smooth.

It's been a long time since the last status. PyBlosxom 2.0 had been stagnating for a year and I decided to move it out of the way, put it out of its misery, and start new progress with the PyBlosxom 1.4.3 tag. I scaled back the vision and now I'm working on PyBlosxom 1.5.

I've pulled in some of the changes that were destined for 2.0 and added some new ones:

• lots of code cleanup
• pyblosxom-cmd script that automates a whole bunch of things and gives plugins command-line abilities
• re-working the documentation using Sphinx
• doubling the number of unit tests
• fixing a lot of bugs

In the very near future, I plan to overhaul the website and fix project infrastructure issues.

That's where things are. Hoping to have an April release of PyBlosxom 1.5.

I was at OSCON last week and met many people some of whom I've known for several years (Ted, Steve, ...). I also met a bunch of people who I've followed for many years and some people I've worked with when doing the Firefox 3 work I did. It was really exciting to be there. I didn't attend any keynotes or sessions, but the conversations I had were well worth trekking all the way to Portland, OR and back. I also got to spend a week with my sister who lives in Portland.

On the flight there and back, I worked on PyBlosxom. I mostly concentrated getting better acquainted with nose and using nose and coverage to help guide my testing efforts. The results were phenomenal. I increased the test count from 53 or so to 207, I increased coverage from some low number to 57% and I discovered and fixed a bunch of bugs. Because I switched to git over svn, I was able to commit locally and manage the work I was doing. All very exciting.

Miro is coming along very nicely. We took the plunge to ditch the previous frontend for a new one that has fewer layers of indirection. The results so far are encouraging--I think it was absolutely the right thing to do. Incidentally, I blogged about OSCON on my Miro devblog.

In the last few months, I've thrown together several web-sites using werkzeug, sqlalchemy, and mako. I really like this stack since it doesn't involve a lot of infrastructure and the number of files and "things" involved is pretty small. I think this is going to be my preferred stack for webapps going forward.

Just before OSCON, I signed up with identi.ca. It's my first micro-blogging account. Mostly I wanted to see what micro-blogging was like and follow other OSCON attendees. OSCON had a _lot_ of back-channel conversations going on.

Just before signing up for an identi.ca account, I met Jack, who lives around the corner from where I live. I wish I had made the effort to contact him years ago.

I think that's about it. It's been an interesting few months.

I'm heading to Portland, OR for OSCON 2008 to help man the Mozilla booth at the Expo. I registered as an Expo attendee, but I'll be there (or near there) from the 19th through the 26th.

My primary purpose there is as a representative for Miro and talking to people about it. However, I'm also interested in meeting up with people working on:

• PyBlosxom things
• Miro and video podcasting things
• Python 2.6/3.0 testing, documentation, bug-fixing, ... things

If you're interested, too, ping me. I'm hanging out on the #oscon channel on irc.freenode.net and you can always get me by email or comments below.

I overhauled the PyBlosxom web-site so that it's now being statically "compiled" using PyBlosxom's static renderer. The whole thing is checked into SVN, too. That's a huge improvement from the previous situation, but the web-site could use user-interface and navigational work.

In doing that, I did a lot of futzing with static rendering using the code in trunk and fixed some issues. I also thought through the filelist implementation and re-worked it so that it handles sorting and truncating better. The results are really nice and I think it fixes all the major problems previous versions had.

GHOP was a big help. PyBlosxom had several tasks that were worked on and the results speak for themselves:

• Testing plugins #1 - testing comments, comment-openid, nospam or spamquestion: completed by klossalex
• Testing plugins #2 - testing pyguest, weblog-add, tags: completed by CanadaBear
• Testing plugins #3 - testing filter, latest, autoping: darkmessenger88
• Testing plugins #4 - testing pycategories, pygallery, contact: completed by CanadaBear
• Memory footprint - investigate memory footprint of PyBlosxom: completed by josiahw
• Writing plugin #1 - write a new entry cache plugin using pickle for PyBlosxom 2.0: completed by jdzolonga
• Writing plugin #2 - write a new entry cache plugin using shelve for PyBlosxom 2.0: completed by jdzolonga
• Writing plugin #3 - write a new rst formatter plugin for PyBlosxom 2.0: completed by cracka80

It was a huge help that these people did for PyBlosxom. I haven't fully absorbed their work yet, but it should happen before PyBlosxom 2.0 is released. Many thanks to those of you who helped out and many many thanks to Google and the GHOP, PSF, Titus, Doug, Georg, Leslie and all the others who helped make this possible. Thank you!

There are a few big things that still need to be done for PyBlosxom 2.0. I'm moving through it slowly and methodically. I was hoping to have it done by the end of December, but I'm thinking now it's going to be the end of March or thereabouts.

I mothered the Miro 1.1 release earlier today. Then I decided to push out PyBlosxom 1.4.3 which I have been sitting on for a month. Then after talking with "paulproteus", I decided to go for the hat-trick and released Lyntin 4.2 as well.

w00t for releasing three software thingies in one day! Boo for sitting on two of them for extended periods of time.

I released PyBlosxom 1.4.3 with better support for WSGI and Paste and support for template variables of the form $(foo). More information on the PyBlosxom web-site.

It was a pretty wild year for me. I had a massive health crisis at the beginning of the year, wrote an almost-working compiler for a functional language using SML targetting SPIM, finished up grad school, got married, landed a job at Participatory Culture Foundation, made a lot of new friends, mentored a GSoC project, helped out with GHOP, started the big push for PyBlosxom 2.0, released a new version of Bee Careful, Marvin under a CC BY-NC-SA 3.0 license and submitted my first patch for Firefox 3.0.

I started the Nomadic Telecommuting Herd which has regular meetings, but hasn't extended beyond Chris and I, yet. I'll push this more at some point in the spring when it's more fun to go outside.

I also joined a few projects that I haven't been able to get to yet like the Python docs project and Geyser. I'm interested in helping out both of them, but haven't found the time yet.

This year I want to tame the firehose, get some good work done, participate more in other projects, possibly learn C++ and reach out to other people in the area (Somerville, MA, USA) to get together and hack more. I'd also like to get a new laptop, but the longer I wait, the better the possibilities become.

Went out to lunch with Chris, John and Dean (who I don't think has a blog). That was pretty cool. We talked about a bunch of stuff and the hamburgers at Christopher's in Porter Square (Cambridge, MA, USA) are really good.

I continued working on adding enclosure viewing support to the subscribe preview page in Firefox 3.0. I've almost got Yahoo MRSS support in. Mental note: one wastes less time if one double-checks the tests to make sure they're testing correctly. Oops.

I'm doing some minor mentoring for GHOP mostly on PyBlosxom related tasks. I'm on both of the mailing lists for GHOP-PSF and it's hard to keep in mind that the people working on these tasks are students in high school and early undergrad. It's like an army of really able, but not very experienced, bodies hungrily munching large bites out of project todo items. PyBlosxom had 4 tasks in last week and 4 in this week. It's great because the help is fantastic and it's forcing me to get around to work on organizing the project and development for PyBlosxom 2.0.

If you're in high school or college and want to do some Python-related work, definitely take a look at GHOP! If you're a Pythonista or Pythoneer and have some spare cycles, definitely come help us mentor. If you have a Python project and need help with screencasts, documentation, testing and other small tasks, take a look at GHOP. Titus has more on his blog.

PyBlosxom 2.0 is going to be a huge overhaul from PyBlosxom 1.4. I'm getting lots of help from the people who hang out on #pyblosxom on IRC, Ryan, Michael and various other people who pop on, ask questions and help identify issues. Progress is excellent so far.

In PCF land, I have a blog focused on PCF work and Miro development. It's at http://pculture.org/devblogs/wguaraldi. I figured I'd keep it separate. It runs on WordPress so that's giving me some WordPress experience.

Whoever fixed NetworkManager for Ubuntu Gutsy should get a gold star. I did an update on 12/4 and picked up a new set of packages and my perpetual wireless networking problems all went away. Bless you!

Also, if you've got young children in your life, definitely take a look at Bee Careful Marvin. It's geared towards children up to around 6 or so. You can get a professionally printed version at Lulu, but you can also download a PDF for free. It's released under a Creative Commons BY-NC-SA 3.0 license and "the source" is all at that link. Print it out, copy it, give it to your young friends, translate it, rewrite it with Star Wars dialogue, ....

Work has been pretty busy. I've been doing release manager stuff, working on Gutsy packaging issues, puzzling over an intermittent problem between the sun-java6-plugin and Miro, working on a Firefox extension, and working on a patch for Firefox 3.0.

I went to some of the after-hours activities for the GNOME Summit Boston. I'm going to PodCamp Boston this weekend.

I was writing my todo list management application in Django, but then decided to switch it to Pylons. Now I'm thinking I may just go a much easier route and implement it in web.py. A year ago, I wrote a wiki system that was code-friendly using web.py in three hours which included the amount of time it took to learn how web.py worked.

PyBlosxom work for version 2.0 has slowed considerably. I just haven't had much time to spend on it. A bunch of us are hanging out in #pyblosxom on irc.freenode.net and we're talking about things more often. I met paulproteus in real life during the GNOME Summit Boston. I'm trying to figure out how to create multi-page output using docutils. There was some development in that arena over the summer, some of it due to a GSoC project. I need to spend some more time to figure out what's available now in SVN, how to use it, and whether it'll fix my problem.

I've upgraded all my machines to Gutsy. It's nice--the fonts seem to be much easier to read on both my laptop and my desktop with an LCD.

That about covers it. It's been a low-Python high-JavaScript month.

I'm hanging out on #pyblosxom on irc.freenode.net more often now that I'm hanging out on irc.freenode.net for work during the day. Zeth was on today and pointed out that if you're running PyBlosxom with Paste, then the default configuration doesn't allow for css and image files to be served.

This weekend, I wrote a media serving plugin for PyBlosxom which solves this issue, but I decided to spend some time to write a WSGI application to do the same thing and use Paste's urlmap to handle the routing. It took 10 minutes to throw together and it works nicely. I'll clean it up and throw it in the Trac instance tomorrow. Over time, I'm liking WSGI more and more.

I ordered a Seagate Barracuda Ultra ATA/100 drive from Amazon.com the other day and it arrived today. I opened it up to discover it's a PATA drive. However, I thought I ordered an ATA drive and not a PATA drive.... Long story short after an hour of researching and finally calling up a friend who does hardware work, I discovered that "they" renamed ATA to PATA so that it won't be confused with SATA. No one sent me the memo.

I was at Tag's Hardware in Porter Square (Cambridge, MA, USA) to buy Poly-acrylic for some shelves I'm putting up and they're selling decent bookshelves for $20.00. We bought one--it's pretty sturdy and it folds up for moving/storage/whatever. They probably have more left if you're in the area and interested.

I've been working through PyBlosxom stuff. I updated the web-site to use PyBlosxom 2.0-dev (in trunk). We worked through entry caching plans on the mailing list and implemented most of them. We've also been discussing and working through template variable syntax and semantics. I've been adding new unit tests and using tests to help work out the design issues. The testing framework has made it so much easier to do development work.

I've been writing a todo-list-tracking application in Django. I'm hitting a point where it's half-implemented, but I'm thinking I may switch back to Pylons because it's Paste-friendly and easier to deal with.

Bunch more stuff, but it'll be in separate entries.

I mentored Z who was working on pyblosxom-webfront which is a web-based interface to your PyBlosxom blog.

Overall I'm pretty happy with the project. I had a pretty crazy May and June that definitely affected the first half of the project, but Z and I had a few chats just before the second half and ironed most of the issues out.

While he was working on webfront, I rolled out PyBlosxom 1.4 (and 1.4.1 and 1.4.2) which have support for Paste. Paste makes writing plugins and testing them _so_ much easier. Z also worked out some problems with making complex plugins. We should look into refactoring the comments plugin accordingly.

From here Z says he'd like to continue working on webfront and maintaining it. There are a bunch of things that it's missing, but it's a good platform to build on and it was a good experience to work with him to get there.

Thank you Google!

It occurred to me that adding a link to category feeds was pretty trivial, so I figured I'd give it a try. It's a bit cluttered to look at (I'm talking about the Categories section on the right hand side there), but ... it's functional.

In case anyone was wondering what my category properties looked like, they're like this:

# category plugin properties
py["category_start"] = ""
py["category_begin"] = ""
py["category_item"] = r'%(indent)s<a href="%(base_url)s/' + \
   r'%(fullcategory_urlencoded)sindex.%(flavour)s">%(category)s</a>' + \
   r' [<a href="%(base_url)s/%(fullcategory_urlencoded)sindex.xml">atom</a>]' + \
   r' (%(count)d)<br />'
py["category_end"] = ""
py["category_finish"] = ""

It's been 17 months or so since the last PyBlosxom release which for a small project is probably too long a period of time. Real life is a harsh mistress sometimes.

Changes:

• bunch of bug-fixes
• converted the documentation from docbook to restructured text
• updates to the documentation
• code overhaul
• added the beginnings of unit/functional testing using nose
• better WSGI support
• Paste support

w00t!

I quietly released an RC2 for PyBlosxom 1.4 today after merging in Yury's patch for Paste support and merging in Steven's work for WSGI support. It's really awesome to be able to do paster serve blog.ini and have things work. At a minimum, it'll be a lot easier to test PyBlosxom--no mucking about with web-server configurations needed anymore.

We've finished moving all the documentation from docbook to reST format. It still needs a lot of work, but we're making measurable progress which is really cool. Also, the documentation is easier to work with and maybe that reduces the amount of energy it takes for people to help out.

PyBlosxom 1.4 should be released soon. Very soon. Will it be perfect? No, but it's a huge milestone for the project. That's pretty exciting in the grand scheme of things.

Blake poked me via email and suggested I put together some ideas for a PyBlosxom GSoC project under the PSF umbrella a couple of months ago. It was a hectic time, but I threw some ideas together based on items we had in the TODO list (many of which are pretty stale at this point). I'm happy to say that we had a great proposal for building a web front end for PyBlosxom--a tool that I think a good portion of PyBlosxom users would be happy to have.

I'll be mentoring this project over the course of the summer. Z has already started working on things and I think this will turn out nicely.

As a side note, this is a huge motivator towards finishing up a release and getting out a new version of the PyBlosxom manual. On the flip side, I'm getting married in a week so I'm finding it difficult to allocate time to get the work done. Wedding planning is intense. They should use wedding planning to teach project management courses--talk about shifting requirements and general project insanity. ;)

Someone posted my article Cleaning Up PyBlosxom Using Cheesecake onto programming.reddit which was a bit of a surprise to me.

I'll keep track of the entry and the comments that it generates in case there's any feedback that would be useful for making the article better.

I saw Titus' Strangling your code and growing your test harness: ... entry and that's the process we've been using for adding a test system to PyBlosxom. We're still on step 2 or 3, though. We have unit tests for a portion of the tools module in and working but that's it. We need a setup/teardown code for testing a request on a basic blog for n variations of "basic blog". Getting there....

Life: I had a really rough January, but I'm not going to get into the details. The kitchen sink drain is working again, the pipes are unfrozen, and our cell phones work [1].

School: My compilers class is going really well. My research project needs a lot more attention.

PyBlosxom: I've been doing some PyBlosxom work again as Ryan gets ready to do a contributed plugins pack release that has all the changes to the comments plugin and all its friends. He's done some really great work pulling things together.

I started hanging out on freenode on #pyblosxom after Asheesh mentioned it on the pyblosxom-users mailing list. That's been pretty cool, but the channel has been pretty quiet most of the time.

Wedding planning is ... coming along. I figure a wedding has 10,000 decisions to make of which maybe 5% of them are "big decisions" (venue, church?, food, ...) and the rest don't really affect the big picture, but they need to be made and it's way harder to make them and there are thousands (silverwear, colors, flowers, flower arrangements, music, favors, text for the invitations, the border on the invitations, the pictures on the stamps for the invitation envelopes, color of the envelopes...). It's been interesting. S has taken on most of the planning lately since I've been sick and working on school work.

Things are moving along pretty quickly. In a few months I'll be graduated, married, and (hopefully) employed!

[1] - S and I get our cell phone service from Working Assets and they have the best customer support of any cell phone company I've been with. You call, you talk to someone immediately, they ask you questions trying to isolate the nuances of your problem, and then they work with you to fix the problem. No hold music, no tedious chit-chat, no scripts, no wasted time, ... And they call you back later to make sure the problem is resolved and that you're satisfied. It's just awesome.

My semester break is drawing short and I didn't get much of what I wanted to get done done. I merged Lance's documentation fixes in, I'm fiddling with a new pyblcmd script, and I'm cleaning up things I started, but never finished.

Ryan is going hog-wild with getting the comments plugin to a better place.

I was thinking of switching the web-site to use MediaWiki and in doing so solve a bunch of issues we have, but I think I'm going to wait on that for a while. In the meantime, I do plan on doing a web-site update and make it look more like some other Python-project web-sites. In the process of doing that, I think I may move it over to be statically rendered.

That's it for this status report--trying to keep it short and sweet while getting across that some things are happening, but it's slow going.

Many thanks to Lance and Ryan and all the other folks who have been putting time and energy into PyBlosxom over the last few months. You guys rock!

I got a few comments from people who were interested in how I used Cheesecake to clean up PyBlosxom. I tossed around making it a series of blog entries but then decided to write it up as a technical article: Cleaning Up PyBlosxom Using Cheesecake.

I think it came out nicely, though parts of it are too "wordy". I really liked writing the article using Trac's wiki system. My only problem with Trac's wiki system is that the documentation for writing wiki macros needs a lot of help.

I'm going to update some of the PyBlosxom plugin writing tutorials I wrote a couple of years ago and put them in my trac instance, too. I still have work to do with PyBlosxom, but it's coming along very nicely. I'm working on unit tests and functional tests now.

I've been following Cheesecake development with the hope that it'd be a tool that would help me fix PyBlosxom's shortcomings, make it easier for people to use, and make it easier for people to develop. It has certainly been all that and more.

I've been going through the various kwalitee measures that Cheesecake does to understand them and I've been making adjustments to PyBlosxom's source code and project infrastructure. I've made a lot of changes so far, discovered some latent bugs and code problems, documented undocumented code, fixed existing documentation, and started writing tests.

It's a huge effort, but it's a lot easier with tools like Cheesecake, nose, pylint, and coverage. Additionally, the blog entries at AgileTesting and articles at Living in an Ivory Basement have been helpful. Also, I've been shamelessly copying the infrastructure of the Cheesecake project. That's made it a lot easier to get my head around various bits.

At the moment, everything is local. I'd start checking things in but SVN at SF is really flakey (though the SF site status page doesn't mention any SVN issues).

I see the next version of PyBlosxom having some bug fixes and new features, but generally it's going to be a release focusing on cleaning up the codebase and the infrastructure.

Out of curiosity, while I'm in the process of cleaning up the codebase is it interesting to anyone for me to write up more detailed blog entries covering up how and what I'm doing? It might help by giving outlining a gameplan for cleaning up other Python-based projects. If that's something you're interested in, toss a comment on the blog or email me at willg at bluesock dot org.

I finally released the contributed plugins pack for PyBlosxom 1.3. To be honest, I really wanted to get around to testing everything more, but it's a big project and I never made the time to do it. Rather than sitting on it forever, I decided to release it now. It's vaguely possible that someone out there will download it, discover that the plugins they're interested in are terribly tested, and help fixing the real problem which is that the only testing we do on the PyBlosxom project is anecdotal testing ("well, it works for me...") by setting up some kind of magical testing framework.

More details on the PyBlosxom site.

I applied a few patches that I've received over the last month or so. I'll hopefully release the contributed plugins pack--there have been a lot of updates since I last released it (ages and ages ago).

Next step is to fold some more documentation into the manual and figure out to handle contributed plugins better. Need to figure out how to fix the problem that the ones I don't use on my blog are of unknown quality and different versions of the different plugins work with different version of PyBlosxom. I'd also like to re-organize the plugins into categories that make more sense.

At one point I was planning on building a page on the web-site tracking things that need to be done for PyBlosxom. Now I think I'll just put the list in a TODO.txt file in Subversion along with everything else. It occurs to me we probably had one at one point, but I probably deleted it.

SourceForge ¹ now has Subversion access to project stuff so I migrated the CVS repository of all PyBlosxom things over to Subversion. Then I tested it out to make sure it works. So far it seems much easier to deal with in the grand scheme of things. I'll probably write more when I find something to kvetch about. :)

[1] For some reason, I keep typing "SourceForget"--not sure why.

Bunch of bug-fixes for things I didn't catch the first time around.

Changes:

• fixed num_entries behavior
• fixed RSS 0.9.1, RSS 2.0, and Atom 1.0 feed templates
• fixed $body_escaped variable
• fixed problem with static rendering where it'd render "/index.html" and "//index.html" if you had entries in your root category
• merged ReadMeForPlugins documentation into the manual and added/fixed some more content

It's a good release. Many thanks to Norbert (current Debian packager), Joey, Joerg, and the many people who upgraded to PyBlosxom 1.3 despite the fact we have no regression or unit testing system ^[1]--they are brave people.

[1] - This is a bad thing--we should fix this.

Norbert took over Debian packaging and has sent me a plethora of fixes, questions, and errata most of which I've applied, replied to, or at least thought about. Martin has also sent in several issues that will be fixed for PyBlosxom 1.3.1. Additionally, I went through all the bug reports on the SourceForge bugtracker and dealt with them.

In the process of doing all that, there were a bunch of bugs with 1.3 that got fixed. I also fixed Joey's problem regarding num_entries behavior. I'm re-thinking how some of PyBlosxom works (or doesn't work) and I've gotten all excited about making some changes.

I've done another huge push on the manual fixing a bunch of minor issues and folding documentation that existed in other places into the manual in the proper places. The manual is in docbook format and when I compile it (or whatever the verb should be) into a PDF, it clocks in at 76 pages. It's definitely the longest manual I've ever written. As time goes on, it gets more and more comprehensive. I hope people use it if only because I've spent days writing, honing, editing, and cursing it.

Next week some time (time-willing), I'll do another pass at overhauling the web-site and fixing the massive problem with plugins that we have. The issue is that I don't want to be doing contributed plugin packs--it's a pain in the ass and none of them are tested except the ones I use. On top of that, over the years people stop hosting their plugins which has caused some of the entries in the registry to become obsolete. I'm going to switch how I do things, ditch the registry plugin, and change the system so that the site hosts all the plugins that are offered. I'm also going to enforce some rules regarding things plugins need to have in order to be added to the registry.

Many apologies for the length of time that this has taken me to complete.

Changes:

• Overhauled the flavour template finding system allowing people to more easily build, trade, and install "flavour packs"
• Added a built-in Atom 1.0 flavour and an RSS 2.0 flavour
• New logging system making it easier to track down PyBlosxom issues and plugin issues
• Documentation comes in the .tar.gz file, though it's in docbook format
• Some other bug fixes here and there

Plugins that work for PyBlosxom 1.2 should continue to work with 1.3.

Overall, I'm pretty happy with it. It's not everything I originally set out to do, but it's a good amount of work for a release. Many many thanks to everyone who helped out.

You can download it from the PyBlosxom website.

I'm releasing PyBlosxom 1.3 release candidate 1. w00t! A lot of work has gone into this and it's taken way way way too long to finally get it out. My apologies to everyone who's been waiting and such.

Changes between 1.2 and 1.3

Pertinent to users:

1. We added a "blog_rights" property. This holds a textual description of the rights you give to others who read your blog. Leaving this blank or not filling it in will affect the RSS 2.0 and ATOM 1.0 feeds.

2. If you set "flavourdir" in your config.py file, you have to put your flavour files in that directory tree. If you don't set "flavourdir", then PyBlosxom expects to find your flavour files in your "datadir".

   The flavour overhaul is backwards compatible with previous PyBlosxom versions. So if you want to upgrade your blog, but don't want to move your flavour files to a new directory, DON'T set your "flavourdir" property.

3. Moved the content that was in README to CHANGELOG.

4. You can now organize the directory hierarchy of your blog by date. For example, you could create a category for each year and put posts for that year in that year (2003, 2004, 2005, ...). Previously URLs requesting "2003", "2004", ... would get parsed as dates and would pull blog entries by mtime and not by category.

5. Logging works now. The following configuration properties are useful for determining whether events in PyBlosxom are logged and what will get logged:

   • "log_file" - the file that PyBlosxom events will be logged to--the web-server MUST be able to write to this file.
   • "log_level" - the level of events to write to the log. options are "critical", "error", "warning", "info", and "debug"
   • "log_filter" - the list of channels that should have messages logged. if you set the log_filter and omit "root", then app-level messages are not logged.

   It's likely you'll want to set log_file and log_level and that's it. Omit log_file and logging will fall back to stderr which usually gets logged to your web-server's error log.

Pertinent to developers and plugin developers:

Nothing that I know of. Everything should work pretty much the same.

Download, comments, et al

Download it at http://www.bluesock.org/~willg/download/.

It's been locally tested (my blog has been running the version in CVS for over a month now), but not globally tested. While I'm pretty confident that it should be ok for most people, I'm sure there are some issues that have fallen through the cracks of our total lack of regression testing and unit testing environment.

As such, I heartily encourage anyone still using PyBlosxom to set it up locally and run it through the steps that your blog entails and let me know this week whether there are any issues.

If I don't hear from anyone by Saturday, I'll just release it at my leisure.

The future

This is it for me. This release fixes a bunch of flavour issues that needed fixing. It also includes a much better version of the manual and some work has gone into making it more Python-standards compliant.

Over the last 9 months, the world of web-application development and Python web-application development has changed radically. I'm a little tempted to re-write PyBlosxom using Paste, but I don't think it really helps our "typical user" much and I'm not sure it makes sense given that there are a variety of other weblog applications out there that are well-established and have more momentum.

As such, I'll be helping with minor bug fixes and that's it.

Happy new year!

My blog has been going up and down a lot over the last few days as I'm getting the kinks out of some code I re-wrote in PyBlosxom and searching for other issues. I've successfully transitioned to the new included RSS 2.0 feed without disturbing any of the planets that I'm on. Things are looking good so far. Release soon!

I re-wrote blosxom_path_info_handler and cleaned it up a lot. The adjustments also allow people to create categories that look like dates (and previously would get interpreted as dates and screw things up).

I'm going through the documentation, the bug list, and a couple of other changes I want to make. I'll also tackle any low-hanging fruit that's on my todo list. Otherwise, I consider PyBlosxom 1.3 pretty complete. If all goes as I plan, it'll be out before Christmas in some form.

I've been running my blog on the latest code and keeping track of all exceptions that get thrown and any other odd issues and things seem to be going well. As such, I'll be preparing to do a release candidate soon and then start the mildly painful process of re-writing the appropriate sections of the PyBlosxom manual.

I'm also taking some time to run Cheesecake against the codebase. The results so far are somewhat of a bummer:

[cheesecake:console] Detailed info available in log file /tmp/cheesecake_sandbox 
/pyblosxom-1.3.tar.gz.log
[cheesecake:console] A given package can currently reach a MAXIMUM number of 560 points
[cheesecake:console] Starting computation of Cheesecake index for package 
'pyblosxom-1.3.tar.gz'
index_unpack ..................  25 (package untar-ed successfully)
index_unpack_dir ..............  15 (unpack directory is pyblosxom-1.3 as expected)
index_install .................   0 (could not install package in 
/tmp/cheesecake_sandbox/tmp_install_pyblosxom-1.3)
index_file_announce ...........   0 (file not found)
index_file_changelog ..........  10 (file found)
index_file_ez_setup.py ........   0 (file not found)
index_file_faq ................   0 (file not found)
index_file_install ............  10 (file found)
index_file_license ............  10 (file found)
index_file_news ...............   0 (file not found)
index_file_pkg-info ...........  10 (file found)
index_file_readme .............  15 (critical file found)
index_file_setup.py ...........  15 (critical file found)
index_file_thanks .............   0 (file not found)
index_file_todo ...............   0 (file not found)
index_dir_demo ................   0 (directory not found)
index_dir_doc .................  25 (critical directory found)
index_dir_example .............   0 (directory not found)
index_dir_test ................   0 (directory not found)
index_docstrings ..............  70 (found 264/382=69.11% modules/classes/methods/functions 
with docstrings)
index_pylint ..................  68 (average score is 6.77 out of 10)
===================================
ABSOLUTE CHEESECAKE INDEX ..... 273
RELATIVE CHEESECAKE INDEX .....  48 (273 out of a maximum of 560 points is 48%)

So, 273 out of 560... Could be worse, but should be a lot better.

The code seems to be working nicely so far. There's one piece I still want to code before a PyBlosxom 1.3 rc release. I still have to go through the manual, update the content, and do some more work on organization. It's likely I won't get to work on it until the end of the semester, so that puts the next release some time at the end of December.

I re-re-wrote the flavour template code for the upcoming PyBlosxom 1.3 release. It works like this now:

1. Pulls flavour templates from taste.flav that comes with PyBlosxom if that flavour exists.
2. In either $datadir OR $flavourdir:
   1. If there is a directory named taste.flav, then it will take the template files from there and override the ones it got from step 1.
   2. OTHERWISE, it will look for files ending in .taste and override the ones it got from step 1.
3. If the request is for a non-root path, it'll look in all the directories between $datadir (OR $flavourdir) and $datadir/path_info/ (OR $flavourdir/path_info/) looking for taste.flav directories OR files ending in .taste.

This allows you to put all your flavour files in a flavour directory that you specify in your config.py file.

This allows you to override individual template files from the default flavours. For example, if you wanted to add RSS enclosures, you can put a story.rss file in your $datadir/, $flavourdir/, $datadir/rss.flav/, or $flavourdir/rss.flav/ directory (depending on how you set things up) with the enclosure markup in it and PyBlosxom will pull the default rss templates and use your story.rss template.

This allows you to override individual template files depending on what category the user is looking at.

This makes it easier to package and distribute flavour packs because they can all sit in a single directory all by themselves.

There should be no backwards-compatibility issues with the new code between PyBlosxom 1.2 and 1.3.

NOTE: The code needs to bake a bit. I tested a lot of combinations of things, but I'm still finding occasional issues. This blog is using the latest code, so if you find any issues, write a comment below (assuming that's not broken) and I'll fix the issue.

I have one more big thing on my list of things to do for PyBlosxom 1.3. After that I'll probably release an RC1. Depending on school work, that could happen in the next few weeks. If you want to see the code now, get it from CVS (instructions for CVS access here).

I was talking with Josh the other day and he told me that I should take the time to learn Subversion and switch over rather than investing more time to tame my projects with CVS and CVSTrac. So I spent a good portion of today moving my PyBlosxom plugins (the ones that I wrote and/or maintain on my own) to a Subversion repository and Trac.

There are a couple of things that will take getting used to, but overall I've been able to replicate everything I did with CVS in Subversion.

I'm still making modifications to the setup, but I'll be hosting all my PyBlosxom plugins work at http://www.bluesock.org/~willg/cgi-bin/pybltrac.cgi/. I've allowed anonymous ticket creation for feature requests, bug reports, and the like. If you're sitting on issues, patches, and things of that nature, feel free to submit them.

I've been following (very loosely) Ian Bicking's (ianbicking.org) paste progress and it's really amazing stuff. Today, I bumped into his screencast on Ajaxy exception catching. That was really cool and I could see how it could be immensely helpful with debugging/fixing PyBlosxom plugins.

I'm adding "investigate porting PyBlosxom to paste" to my todo list for winter break; paste looks seriously awesome.

I'm going to release the PyBlosxom contributed plugins pack 1.2.3 for PyBlosxom 1.2 in the next couple of days. So if anyone is sitting on any fixes that need to go on, let me know soon.

This has a few fixes here and there--some of which are cosmetic. It also has a behavior fix for the comments plugin so that comments are shown if you have ?showcomments=yes in the querystring as well as when the specific story is viewed.

Prior to today, I was maintaining all my PyBlosxom plugins by hand... which was kind of stupid, but I hadn't really gotten around to investigating better solutions.

However, that day has come! I've pulled them all into a CVS repository and set up CVSTrac to manage documentation, bugs, features, and allow people to see version history for all of them. I'm in the process of going through all the plugins, adding CVS tags, updating copyright dates, fixing documentation, adding notes in regards to where the plugin is maintained and all that.

I aim to make the end result more organized for me and users looking for plugins and also require less effort to maintain.

I got an email from Carol Spears (http://carol.gimp.org/) that caused me to take a day off to re-organize and relax a bit.

Anyhow, so no work for me today. I'm just going to clean out my email inbox, clean off my desk, figure out where I am with bills, do the dishes, and stuff like that. Maybe if I get really excited, I'll go grocery shopping.

I did spend a couple of minutes to update my blog to the most recent PyBlosxom in CVS. Thus I now have an ATOM 1.0 feed which seems to be working nicely. I'll look into the RSS 2.0 feed next, but that requires some planning because I don't want to hose any of the Planet feeds I'm on when I switch from the rss2renderer plugin to the native RSS 2.0 feed.

It's been a month since my last blog entry. I haven't done any blog updates since I haven't really made any progress with anything. Nonetheless, here's an update of where things are.

My algorithms course is just killing me. I'm doing some 40 hours of homework and studying for it each week and ... there are still some topics that I haven't really wrapped my head around. My computer systems course, however, is pretty easy--for some bizarre reason I'm very familiar with much of the material we've covered so far.

I've been very slowly working through PyBlosxom 1.3. It's going to contains a series of bug fixes (I have to re-organize everything so I know which ones have gone in so far) and also an overhaul of the flavour code allowing for flavour directories, subdirectory handling in the flavourdir, shipped flavours (better ones), ATOM 1.0, RSS 2.0, and hopefully with the changes it'll be much easier for people to build new flavours, package them up, and ship them around in a way that's trivial to install. That's the theory.

I think the ATOM 1.0 flavour is done--I need to do some more testing with it. I think I'll do this by upgrading my blog to the code in CVS and working with it there.

I don't think I've finished with the RSS 2.0 code yet. I don't remember where I am with that.

I'm trying to figure out how to pull images, css files, and other flavour-helper content in a flavour directory and source it through PyBlosxom. I think I may build a handler for it and have the handler kick off before the default blosxom_handler. It would then figure out which flavour is being displayed by looking at the referer and various other things available, check to see if the image/css file is there, and serve it if it is. I'm pretty sure there are corner cases here. It'd be nice if people could turn on and turn off this feature, too, since it could cause issues with other plugins. Though since it's a handler that runs if none of the other handlers ran, maybe it's not a big deal. It still needs thought. (Also, this isn't a comprehensive description.)

Also, I need to put together (or at least start putting together) a TODO list for the web-site. I'm having huge problems wrapping my head around this, though. I'd love to do this as a plugin, but... I think I may end up doing it all by hand. The other possibility is to enter in all the items into the SF bug and feature trackers--but I really dislike them. Tempting thoughts would be to move all development to my server, installing subversion and Trac, and doing the whole thing with those. But... that's a lot of work and it puts me in a position where I can't just throw my hands in the air and walk away.

I started grad school last week. The last few weeks have been pretty work-intensive as I squared away a lot of stuff so I didn't have to worry about it while I'm studying.

Also, bluesock suffered a hard drive failure and that took a few days to sort out.

I haven't finished the things I wanted to finish with PyBlosxom. I have been doing some research on Leonardo to see what sorts of things we can do to make installation, configuration, and extending PyBlosxom easier.

One thing I've been thinking about a lot is the current state of PyBlosxom plugins. I'm not as psyched about splitting plugins off into a separate project anymore. Lyntin had a core set of plugins that came with Lyntin and formed most of the functionality. Then users could add additional plugins if they so desired on a user-by-user basis. I think it's prudent to do the same thing with PyBlosxom. I think this will help the typical PyBlosxom installation. I'm not sure why I didn't think of this 8 months ago or so. I'd like to do this work for PyBlosxom 1.3.

I merged all the changes I've made in the PYBLOSXOM_1_2 branch back into HEAD. Now I'm in HEAD and I'm going to do PyBlosxom 1.3 work until I'm ready to release. At that point, I'll make another branch for PyBlosxom 1.3 fixes and such.

I've got the following items in my todo list for PyBlosxom 1.3:

• figure out what additional variables are needed to produce RSS 2 and Atom 0.3 feeds without the rss2renderer and without additional plugins ^[1]
• add a timezone variable to the data dict
• fix bugs 1239484 and 1202107. and 1252678.
• possibly add new sample flavours: rss 0.9, rss 2.0, atom 0.3, and several html flavours ^[2]
• minor clean-up and documentation work

Why make this PyBlosxom 1.3 and not another minor 1.2 revision? Well, it has to do with the adjustments needed to fix bug 1202107. PyBlosxom checks the content-type to see if it's xml and if it is, then it escapes the $title and $body variables which drives everyone trying to do an xhtml or other xml output crazy. The only ways to fix the issue is to do a hack on the hack or introduce a backwards-incompatible change. Given that I'm more interested in the latter, I figured it's better to bump the version so that it's clearer that the user will need to make some adjustments to their PyBlosxom configuration when they upgrade.

^[1] $title_encoded, $body_encoded, rfc822 date, iso8601 date, and possibly other stuff
^[2] If you want to help with building flavours, let me know.

I implemented Matt Weber's idea to show comments when bl_type = "file" instead of depending on a "showcomments=yes" in the querystring. I didn't remove the checking for "showcomments=yes", however--I figure having both covers all our bases. This fixes the ramifications of a poor decision on my part.

I made some changes to the debug renderer to make it easier to use. It now sorts the keys for mappings and prints the keys in blue. It's much easier to read now.

I submitted a bug report on the PyBlosxom package based on an email I got from Ted from Dave from Zack. I posted a security issue on the PyBlosxom web-site to notify users. I also forwarded the issue to the pyblosxom-users mailing list. Hopefully the news will filter down to all the people that need it.

I'm going to do some more PyBlosxom work over the next week. I want to merge some functionality in from plugins into the core. I first need to merge all the changes I've done on 1.2 back into main branch. Then I'll do the work in main and create a 1.3 branch when I release 1.3. If there are any features people are itching for, now's the time to let me know. Anything I don't plan on working on, I'll toss on a web-page on the web-site so everyone can see the wishlist and the status of where things are. It's interesting to note that the wishlist and a todo list are themselves in the wishlist and todo lists.

Wow! Martin wrote up a howto for installing PyBlosxom on Debian for multiple people.

There's a series of things here I don't really know about (e.g. what kinds of things should go in /srv?). At some point, I'd like to fix PyBlosxom so it's more "standard" in terms of installation and configuration for web applications.

Here's the link for configs/pyblosxom which walks through installing a single software installation on Debian for multiple people.

I had the brakes replaced on my car yesterday--that was interesting. The guy said he had to replace the rear brakes because they were pretty dead, but he could try to lube up the front brakes so they wouldn't make the "I'm dying please replace me" scream of mortal anguish they've been making for a week or so. Given that they're brakes and that they were on their last legs, I had the guy replace them all. Curious that he suggested the lube solution, though.

I received a whole bunch of information from NEU--so I'm off to deal with that and get all the things I need to do done today.

Then tonight I'm going to pick up some wood from Home Depot and build a coffee table.

I think next week, I'll start working on PyBlosxom again. I've been following Ian Bicking's blog entries on WSGI and Paste and it's very intriguing.

I'm heading off to Florida for a week for some vacation. When I get back, I start the long process of re-learning all the things I knew in college and figuring out the other things I need to do before grad school.

Somewhere in there, I'll finish up some of the things I started in PyBlosxom-land like the manual and fixing issues with the web-site.

Anyhow, if you're looking for me, I won't be around until July 6th.

Joseph pointed out a problem where IE 6 won't display a cached page when it gets a 304 from the conditionalhttp plugin. (The issue is at the bottom of the email.)

I did some poking around and discovered on Wednesday that this happens on his blog as well as on my blog with IE 6 on Windows XP. On Thursday, I was no longer able to reproduce the problem on my site, but Joseph's was still broken. I don't know off hand what changed with my site, though I did do an apt-get update Wednesday night.

Anyhow, the 304 response from my site (which seems to work fine now) is (note the server line is wrapped):

HTTP/1.1 304 Not Modified
Date: Thu, 23 Jun 2005 14:32:26 GMT
Server: Apache/1.3.33 (Debian GNU/Linux) mod_python/2.7.10 Python/2.3.4  \
        PHP/4.3.10-15 mod_ssl/2.8.22 OpenSSL/0.9.7d DAV/1.0.3
ETag: "1119536230.43"
Last-Modified: Thu, 23 Jun 2005 14:17:10 GMT
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

And from Joseph's site (which is still not working):

HTTP/1.1 304 Not Modified
Date: Thu, 23 Jun 2005 14:37:15 GMT
Server: Apache/2.0.46 (Red Hat)
Connection: Keep-Alive
Keep-Alive: timeout=5, max=100
ETag: "1118428239.0"
Vary: Accept-Encoding,User-Agent

=bunch of funky non-printable characters here=

Looking at responses from other requests to Joseph's server leads me to believe that pages are gzipped. I'm not sure if that's part of the issue or not.

My site: http://www.bluesock.org/~willg/blog/

Joseph's site: http://reagle.org/joseph/blog/

I'm running PyBlosxom 1.2.1 with the contributed plugins pack 1.2.2 with conditionalhttp. I think Joseph is as well. I have no idea if this is affecting anyone else--no one else has complained on the mailing lists or anywhere else that I've checked.

Anyone have any ideas as to what might be happening?

This is the third release of the contributed plugins pack for PyBlosxom 1.2.

Here's the list of changes between contributed pack 1.2.1 and 1.2.2:

• New CHANGELOG.txt file which describes the changes between this version and the last as well as compatability and behavior issues.
• New README.txt file which describes what's in the contributed plugins pack, where you can find it, and various other things about the contributed plugins pack.

• Matej updated genericwiki so that it works as an entryparser as well as a preformatter. Will fixed up the documentation. genericwiki was moved from the preformatter directory to the entryparser directory. Thanks Matej!

• Now has two new properites "category_start" which gets printed once before printing the category list and "category_finish" which gets printed once after printing the category list. Additionally, the default values for "category_begin" and "category_end" were fixed. This makes the default output for pycategories (x)html compliant. Thanks Joseph!

• comments no longer shows comments by default! In order to view comments for a given entry, you must append "showcomments=yes" to the querystring. THIS IS NOT A BACKWARDS-COMPATIBLE CHANGE! Thanks David!
• comments no longer has documentation for the unused comments-rejected-words property.
• comments no longer requires the email field.
• all the flavour templates for the comments plugin have been updated.
• We cleaned up the comment error messages so they're useful to the user. Thanks Nathaniel!

• w3cdate plugin now provides $w3cdate in head and foot templates. It no longer requires PyXML. Thanks to Steven and Matej!

Thanks to Steven, David, Joseph, Matej, and Nathaniel for their contributions and help.

If you find problems with contributed plugins, visit this page on how to contact us. "Problems" could be bugs, feature-requests, or setup issues.

Find the contributed plugin pack here (contrib.1.2.2.tar.gz).

This is a minor bugfix for PyBlosxom 1.2. If you use the conditionalhttp plugin, you'll want to upgrade. Otherwise, it's not crucial.

Changes:

• Fixed a problem where the blosxom renderer never c hecked to see if it had already rendered the page. This affects the conditionalhttp plugin, but not much else.
• Removed an extra filestat.
• Added a setTimeLazy method to the FileEntry class.

Doug was going to do a unit testing or a regression testing or some kind of testing system in PyBlosxom so that we'd have testing and wouldn't have to do the manual testing and the "well, gee, it must work because I don't think I did anything wrong" ^[1] type testing. But then he ran out of time or interest or something. That time period of PyBlosxom development was a little rough for all of us.

Anyhow, I bumped into this blog entry on Functional testing in Paste which at first blush looks fantastically awesome for testing PyBlosxom stuff. It's based on testing applications with Paste (Paste).

I'm tossing this in the blog in case anyone is interested in working on fleshing this possibility out or in case I discover some free time with nothing to do.

[1] I'm a huge offender of this in regards to side projects.

I'm going to try to fix a couple of issues before releasing PyBlosxom 1.2.1 and contributed plugins pack 1.2.2. The issues are as follows:

• w3cdate plugin doesn't expand "w3cdate" variable in head or foot templates (details here)
• comments plugin borks in unusual circumstances (details here)
• comments plugin requires the email field (details here)

I'm working on PyBlosxom Manual changes as well. I think it's good to add a chapter on comments and I need to flesh out the chapter on syndication, too. If anyone wants to help with the PyBlosxom Manual, let me know--I'm happy to pass off some of the writing/collection/verification work to other people.

If you find any problems with PyBlosxom 1.2 or the contributed plugins pack--let me know those issues as well.

I figured I'd take some time to share my PyBlosxom setup. As of this writing, I'm running PyBlosxom under Python 2.3.4 on Debian with Apache 1.3.33. I'm running PyBlosxom 1.2 (with some minor adjustments). I have the following plugins:

• booklist - displays a list of books that I'm reading
• comments
• wbgcomment_blacklist - rejects comments that have certain blacklisted terms in them (which has the minor nuissance that no one can talk about Texas Hold'em on here)
• conditionalhttp - returns a 304 if the content hasn't been modified
• filter - filters out CVS and other directories from my blog
• gecko - tells people to use Firefox at the top if they aren't already doing so
• plugininfo - lists the plugins that I'm using
• pycategories - lists the categories in a hierarchy
• pyfilenamemtime - allows me to set the mtime of the blog entry in the file name
• pyinclude - allows me to include files with python scriptlets in the head and foot templates
• pystaticfile - (poorly named) allows "static" content on my site but renders it in the existing template structure
• readmore - allows me to break up my entries into a summary and extended section (I don't think I ever use this)
• rss2renderer - builds the RSS 2.0 feed
• tipsparser - parses tips files
• title - urlencodes the title of a blog entry and tosses it in $urlencodedtitle (which is better for Google Links)
• wbgamazon - builds Amazon links
• wbgarchives - builds archive pages for entire years
• wbgdebug - allows me to look at the debug output of my blog by tossing debug=yes in the querystring
• wbggrep - my incredibly hacked "search" engine
• wbgpager - builds paging navigation when there are more entries to display than I want to display at one time
• wbgrecent - summarizes recent activity on my blog

I write most of my entries using vi or emacs and for the most part I write them in HTML.

There was a time where I wrote blog entries on whatever was in my head to build content and thus test PyBlosxom. Recently, I've been doing development summaries and writing about life changes. I think a good portion of my blog entries talk about how I don't have much free time.

I have no idea who my audience is or what they look for here.

The last couple of weeks have been really crazy. S went off to New Jersey for the weekend, so I've had a few days to work through the things in the bottomless queue of things to do. I've been making a lot of progress, but the queue is still daunting.

There were a few bugs found in the contributed plugins pack 1.2.1, so I'm going through, fixing the ones mentioned on the mailing lists and fixing some additional issues as well. I think I'll be done with the things by Monday.

In tracking down problems with conditionalhttp, I found a bug in the PyBlosxom blosxom renderer. I think it only affects conditionalhttp, but it does so in a way that makes conditionalhttp totally useless. If conditionalhttp looks at the If-Modified stuff and decides that the content has not been modified, it issues an HTTP 304... but then the renderer goes and renders all the content and sends it down the stream just as it would with an HTTP 200. Needless to say, this doesn't do much to curb bandwidth usage.

I'm hoping to fix the problem where we fetch and filestat all the blog entries multiple times in a given PyBlosxom request. It won't be the amazingly elegant fix I was hoping to do a couple of months ago--but that requires a whole lot more work and rewriting a bunch of things in a non-backwards-compatible way and thus disrupting plugins and such.

That brings me to the PyBlosxom manual work I'm doing. The manual is already 46 pages long (that include the GDFL text). I haven't covered developer topics yet--mostly I've spent my time writing and re-writing content dealing with installation, setup, configuration, flavours, plugins, static rendering, and writing entries. I'm still getting my feet wet with docbook, so that's causing it to take longer.

Manuals take a stupendous amount of time to write. Anyone who tells you otherwise is an armchair developer.

Incidentally, if you've even looked at the manual, let me know. I have no way of knowing whether I'm doing a lot of work for nothing. I'm also very interested with problems people have, portions that are vague, and any other comments. Additionally, if you want to help out, let me know.

This is the second release of the contributed plugins pack for PyBlosxom 1.2. In terms of functionality, there were a bunch of fixes to the comments and trackbacks components and I overhauled pycategories. Beyond that, there were a lot of license changes (or in most cases license applications) and some documentation changes. In general, this release is a huge milestone for sorting out the big mess that was the contributed plugins.

Bravo to Wari, Ted, Steven, Blake, Bill, and everyone else that was involved in pulling this together.

If you find problems with contributed plugins, visit this page on how to contact us. "Problems" could be bugs, feature-requests, or setup issues.

Find the contributed plugin pack here (contrib.1.2.1.tar.gz).

I plain ran out of time and energy to work on PyBlosxom, so I stepped down as maintainer. I'll stay on the project as an occasional developer.

I went through my plugins and discovered wbgpager had a bug in it that prevented it from working with PyBlosxom 1.2. So I fixed it and released wbgpager 1.2. You can find it here with all the other plugins I've done. I also made some fixes to some of the other plugins. So if you're using anything I wrote, you might want to check to see if there are new versions.

It's shaping up to be a long, but productive week.

PyBlosxom

We're working through the problems a bunch of problems with the contributed plugins that have been sitting around for some time. This includes assigning licenses to all the plugins, adding version/author information, making sure they have some modicum of documentation, and at some point (hopefully) testing them all out in PyBlosxom 1.2. Hopefully this will put the contributed plugin pack in a much better state of being.

Steven, Bill, Wari, and Doug decided that it was high time we started using various features of CVS to make development better. I've had some growing pains with this and kind of wished people had figured things out and written up a process before making the changes. Even though I'm grumbling about the way it's happened, it is a good thing it is happening and it will make it a lot easier to do some of the things we've been doing for a while now. It'll also help a huge amount now that we've got more than one or two active developers.

I have a lot of plans for the PyBlosxom manual, but haven't had time to execute on any of them yet. The wiki we were storing documentation in was taken down since the jackass ISP that Wari had got all befuddled and confused and terminated his account with them. The problem here is that I had documentation in the wiki I hadn't had time to port to the manual yet. Fortunately, Wari sent me the contents of the wiki. I had documentation in there that I hadn't had time to port to the manual yet.

I'm 90% sure I know how to restructure what we've got right now to allow for Bill's index caching and also other storage systems. Depending on how things go with everyone else's PyBlosxom projects, I'll prototype this, write up a specification, send it round, and then implement the resulting modifications all before the next version of PyBlosxom.

Since Ted's PyBlosxom presentation at PyCon 2005, we've had 10-20x as much PyBlosxom development activity. That's been really exciting but also really daunting. Definitely a lot of growing pains mostly between my style of running things and peoples' vision for how things should be run.

Steven is still working on fixing the PyBlosxom registry to be a bit more user-friendly. We're short on flavour templates and some people really dislike this so I want to spend a week building new flavours at some point in the near future. Maybe I'll toss all the flavours in the contributed plugin pack to replace the existing flavour examples that come with it (I highly doubt anyone uses any of them).

Getting there....

grad school

I was accepted into the masters program at Northeastern University CCS. Starting in September, I'll be a full time grad student. My advisor is Mitch Wand (which is very exciting) and I was awarded a Dean's List Scholarship which reduces the costs assuming I maintain a 3.0 GPA and miscellaneous other things in fine print. All very exciting.

Need to learn Lisp, review all the stuff I learned in college, and attempt to get ahead of the game by covering as many of the things I'm going to be learning as possible.

DarkRifts

I've adjusted the way I'm working on DarkRifts such that I'm limiting myself to one coding goal every week. This will reduce the amount of stuff I'm doing there, but more importantly, it makes it easier to schedule things and gives me time to work on all the other non-DarkRifts stuff out there.

My book(s)

I'm in the process of looking at Lulu to do some self-publishing. S and I wrote a children's book last year which might be a good candidate for Lulu. The problem being that we'd need to redo the layout.

On top of that, I'm novel-izing the D&D campaign that I've been in for a year and a half. That's been going really well so far. I'm done the first couple of chapters. If anyone else plans to do something like this, it helps to take really good session notes and maintain a public set of summaries that other people in the campaign can fix.

On top of that, S and I have some ideas on the next children's book, but we still need to sit down and flesh them out a bit.

Other

Work has been super busy the last couple of weeks on top of everything else.

Seems like it's ok so far. So I released it rather than continuing to sit on it. I've done a lot of work on the manual to cover the areas that were covered poorly or not covered at all. There's still a lot of material to cover, but we're definitely making measurable progress in that direction.

Steven Armstrong did a lot of work to get mod_python, WSGI, and Twisted supported. I'm not sure why anyone would use WSGI or Twisted, though, since they don't appear to make much difference in how fast PyBlosxom works. mod_python definitely helps, though. Steven has some runtime statistics here.

This feels like a good release. We met some goals, we didn't sit on it forever, the documentation is an order of magnitude better than it was for the previous version (though it has a long way to go, still), and we fixed a bunch of bugs.

Having said that, it's definitely not necessary for people to upgrade. I think if your blog works and you don't need to futz with it to get additional functionality, leave well enough alone.

I'm almost done the next version of the PyBlosxom manual. At the suggestion of Steven, I converted the manual thus far from html to docbook. I still need to do a lot of work in terms of indexing and adding warnings and notes and various other indicators like that. I'm busy re-writing chapters to reflect issues people are having on the pyblosxom-users list.

I think I've worked between 20 and 30 hours on it over the last week and a half--it's almost like another part time job.

We're going to try to push out PyBlosxom 1.2 in the next week or two. Steven did a lot of work fixing up static rendering and also fixing the architecture pieces that caused PyBlosxom to kind of suck when used in various frameworks like WSGI, Twisted and mod_python. I'm also going to do another round of documentation content.

We're going to push fixing the file handling to the next version. We want to allow for index caching and also reduce the number of times PyBlosxom walks your blogdir for entries. Both of these new abilities will significantly reduce the time it takes for large blogs to render. Getting there....

The plan is to have these changes in before Ted's talk at PyCon.

Got the notice from Network Solutions today stating that unless I renew right this second, the domain name is free again for anyone's taking.

I had worked with George to get Planet PyBlosxom up and running, but he seems to have paged out and hasn't responded to the last few emails I've sent.

It was an interesting thing to run for a year.

In lieu of other solutions, I'm going to start releasing contributed plugins plugin packs. This one should work with PyBlosxom 1.1.

If you find problems with contributed plugins, visit this page on how to contact us. "Problems" could be bugs, feature-requests, or setup issues.

If this works out, then I'll continue releasing contributed plugin packs that match up to PyBlosxom.

Find the contributed plugin pack here (contrib.1.1.tar.gz).

Steven's been doing development on PyBlosxom to allow for other frameworks than plain CGI. The architecture changes he's making solves some other issues as well. The problem we've bumped into is that one of the things he wants to do requires us to change the minimum Python version from 2.1 to 2.2.

Details here.

Bill noted that it's likely that PyBlosxom won't work in 2.1 as it is now anyhow. I'm not sure--I don't have Python 2.1 anymore.

So the question is would it be ok to change the minimum requirements. Some folks who cannot change the version of Python they have will have issues with this (obviously), but is it a good idea anyhow? Is the world at a place where it's common to require at least Python 2.2 a for projects?

A while back, I adjusted the comments plugin locally so that it would allow me to have plugins that change the template type they use from "story" to other things. A couple of months ago, I sent Ted an email with which pieces go in which templates. Figured I'd stick that here in case someone is looking for it.

This is only for the "story" section. The head template goes before and the foot template goes after this example. This also only works with the latest version of the comments plugin that has the template stomping code removed.

<div class="news">           <- story.html
<h2>$title</h2>               |
<div class="content">         |
...                           |
</div>                        |
links                         |
</div>                       <-
<div class="comments">       <- comment-story.html
<div class="comment">        <- comment.html
Posted by $blah at $blah      |
$blah                         |
</div>                       <-
<div class="comment">        <- comment.html
Posted by $blah at $blah      |
$blah                         |
</div>                       <-
<div class="commentform">    <- comment-form.html
form stuff here.              |
</div>                        |
</div>                       <-

I finally got around to releasing PyBlosxom 1.1. The big change is that I'm only planning to work on and maintain the core--I'm hoping someone will come along and pick up maintenance for all the contributed plugins. I haven't figured out what the contingency plan will be. I might maintain that too, but whine about it very loudly until someone gets tired of me whining. I'm also slowly getting through working on the documentation. I noticed that the wiki that I'm basing a portion of my documentation on disappears every now and then. So... I'm thinking that's a good sign that I should finish up quickly.

George called me up and offered to take Planet PyBlosxom off my hands. I want to pass off all the little things to other people in the PyBlosxom community so that:

1. I have more time to focus on PyBlosxom core
2. Other people are involved in the community--more people -> more ideas -> better community
3. Minimize the significance of me in the PyBlosxom world

In the meantime, I'm working on finishing reading Dive Into Python. It's one of those books I wished I had read years ago. I got a hard-copy from my parents for Christmas. I've put a halt on coding until I'm done.

I was checking my apache logs and noticed there are dozens of feed readers pulling my RSS data. They're not pulling index.xml--which is the RSS 2.0 nicely-rendered data, but rather the RSS 0.9.1 flavour that comes by default with PyBlosxom.

The problems with this are two-fold. First, I don't have num_entries set in config.py. So every time someone requests the RSS 0.9.1 feed, they get all of my entries. It's around 340K or so. I'm amazed no one ever complained about this. If they had, I would have told them to get the other feed--the one I advertise--instead.

The second problem is that I didn't have the conditionalhttp plugin running. So every time someone requested the RSS 0.9.1 feed, they get all my entries--even if I haven't added any new ones since the last time they requested it.

I couldn't adjust the num_entries property in my config.py file, though, because it would mess up my paging plugin. So I tossed things around a bit and decided to add this code to my config.py file:

import os
query_string = os.environ.get("QUERY_STRING", "")
if query_string.find("flav=rss") != -1:
   py['num_entries'] = 20

This code checks to see if someone is grabbing the RSS flavour of my blog which is my unadvertised-I-wish-no-one-would-request-it RSS 0.9.1 feed and set the num_entries property to 20. Otherwise, it doesn't get set.

Then I tossed in the conditionalhttp plugin which does the whole last-modified thing further reducing the amount of bandwidth I'm burning away pointlessly.

1. switching to emacs and getting my configuration issues worked out
2. discovering screen
3. subscribing to the mudos mailing list where the folks are really awesome
4. building the new pyblosxom web-site (not open yet)
5. the amazing amount of activity on the pyblosxom mailing list which has given me a lot of confidence that there are other people who want to help out so I can go work on the things I'm interested in

I gave Bill Mill CVS checkin permissions the other day. He's interested in working on the static rendering and the problems of storing metadata. The former (static rendering), I'm psyched to pass off to someone who will work on it and fix the various issues it has. At a bare minimum, I'm psyched to pass it off to someone who wants to think about it.

The latter (metadata) is something we need to figure out how to deal with and soonish. The pyblosxom-users and pyblosxom-devel mailing lists have had several people pop up with their own ideas about what constitutes metadata, where it should be stored, how it should be stored, and how to access it. But few, if any, of the proposals seem to be in-line with the PyBlosxom mission. Though maybe it's not clear what the mission is. That's a topic for another entry.

Bottom line is that I'm going to hold off on releasing pyblosxom 1.1 for a few days in case Bill wants to change things.

Bill Mill's weblog is here. He talks a bit about metadata in entries and del.icio.us-style keywords.

Also, SourceForge is finally getting around to updating their web-servers and are planning to install a version of Python greater than 1.5.2. When that happens, I'm going to re-do and move the PlanetPyBlosxom web-site. I'm hoping Wari will approve moving the PyBlosxom main site as well. If he does that, then I want to merge the two sites, fix our problems with documentation, and centralize everything under one big project web-site that's agnostic of the people involved. That's a bit project. It may be that I'll wait to do pyblosxom 1.1 release until after the "big move".

A while back, several people offered to help out but I severely lacked the resources to sort everything out to take that offer. I'm hoping to make development much easier for people who want to hop in, implement a feature they need, and hop back out again and also make room for growing PyBlosxom beyond its blosxom roots.

So that's the update. Any thoughts or comments, leave them below.

I think I've removed over 100 spam comments from my blog in the last 48 hours. I'm a little tired of it, so I added a few obvious words to my word blacklist and then I went and modified the comments plugin to allow for "draft" status.

Then I wrote a small script that goes through the directory, finds all the comments in draft status, prints each comment to the screen and asks me what I want to do with it. That'll prevent comments from getting published without my manual approval.

It's interesting to note that many/most of the comment spam are comments on my entries on comment spam. Amusing....

I finished taking the GRE so now I'm going to start the long process of moving everything in /contrib to the registry, moving the flavours to the registry, and then going through the steps to release PyBlosxom 1.1.

We'll do an RC and wait a week for people to speak up about issues. That puts a PyBlosxom 1.1 release around the end of October. Things that will be in the release:

• a bunch of important performance enhancements
• some bug fixes
• some other minor changes

We're also removing the contrib directory and all the flavour examples. This is probably going to be controversial, but I don't think we have enough polish to continue distributing them with PyBlosxom and it'll be easier to distribute fixes and such if they're separate from the PyBlosxom release.

It's getting to be a drag when the nicest comments I get from my blog are comment spam for a casino site. "Thanks for the great work!" "That entry was really helpful!" "It's really nice to have people like you around!"

If I were a less self-confident person, I'd filter out the actual spam part (usually the web address) and leave the rest of the comment be. I'm sure these spam folk mean everything they say.

I had a splendid weekend with S's parents and then bumping around Harvard Square on Sunday. I did some studying for the GRE, but mostly took a couple of days off from doing work.

I also finished up overhauling all the code on DarkRifts to work with the MudOS v.22.2b14 driver. There's a huge amount of code and there were a lot of problems most of which are sorted out now. There are still a few problems, but no one seems to be logging in, so I don't really feel any urgency to work through the last bits.

I'm planning on pushing pyblosxom through to a 1.1 release soon. First, I'm going to package up the flavour files into flavour packs for the registry. Second, I'm going to add documentation to all the contributed plugins and move them all to the registry. Accomplishing those two tasks should give the code in CVS enough time to bake. Then we'll do a 1.1 release and start thinking about 1.2 which will likely involve a minor overhaul to how we pull files from the file system.

The next two weeks will be pretty busy. Already I'm way behind in replying to email.

I'm going to spruce up the comments plugin that comes with PyBlosxom. I'm going to merge the changes I've made locally with the contributed version:

• Support for "blacklisted words" which, if they're in the comment, will cause the comment to be rejected
• Fix for the comment plugin so that instead of stomping on the template it now just appends the comment template to the story template. This makes it play nice with other plugins.
• Change the behavior so that neither the comments nor the comment form show for an entry unless "showcomments=1" shows up in the querystring.
• Fixes to the logging.

I may incorporate the changes that Jesus did or at least figure out how to make that a plugin kind of thing.

Also, there should be a way to kick back messages to the user who just did stuff with the comment form. Then we can kick back messages when comments are rejected and accepted for better usability.

Brett discovered some issues with booklist as it interacts with comments. So this fixes those issues.

You should note that if you're using booklist and comments, you should have at least 2 books in your list. Otherwise comments sees it as a single entry, decides to show comments for it, and then stomps on the property in the entry that dictates which template to use. That's a bug in comments that needs to get fixed.

Get it on my pyblosxom plugins listing

Fixed encoding issues and some other things. Thanks Aslak!

Get it on my pyblosxom plugins listing

There are a few people doing analysis on the tools.Walk chain with the hope of slimming it down because it's one of the corner issues with PyBlosxom scaling up to thousands of entries. I don't really have time today to look at them (I'm at work right now), but I will (hopefully) soon and hopefully this spawns a discussion that results in better PyBlosxom code.

• cursory performance analysis of tools.walk (www.le-quoc.com)
• pyblosxom performance analysis (robwall.com)
• minor discussion in the pyblosxom todo wiki page

There's been a flurry of email on the PyBlosxom mailing lists over the last month. I'm totally buried at the moment, so I haven't had time to go through them and figure out what it all means in the grand scheme of things.

I updated the todo list with everything in my head right now (though I'm sure there's other things floating around that aren't on that page).

Robert Wall is working on doing analysis on PyBlosxom and coming up with some code to fix issues he's uncovering.

Hopefully, his work and the work of others will result in some big fixes to PyBlosxom that will (hopefully) simplify the architecture, reduce the number of performance issues, and open up more possibilities.

I also finished up work on Planet PyBlosxom which I had been threatening to do for a while now.

Lots of progress, though. I wish I had more free time to help grease the skids a bit.

Fixed a bug where categories with four letter names were getting picked up even if the name wasn't all digits. Thanks Ludvig Omholt!

Pick up the new plugin here: my pyblosxom plugins.

I decided to release my old set of flavour templates on the flavour registry and in so doing totally foobarred all the times on all the files of my blog. I recovered most of them (because I have a mirror that's usually off by a few days), but then I had to guess on the times for the latest four entries.

So that sucked. Given what I just went through, I'm beginning to think it's a terrible idea to use the timestamp on the file as the mtime. Blech.

I didn't expect either of these entries to drum up the response they did. I've gotten emails and comments from both entries that were way cool.

As a result, I've finally gotten around to building the flavour registry, I decided I'm going to see what's up and whether I'll work through a 1.1 release for PyBlosxom. We're working through what to do in regards to the filestat callback and possibly moving caching. I started investigating what would be involved in building a regression testing framework (which would double as a performance testing framework as well).

It's been a good couple of days. I really appreciate the advice and encouragement I've gotten. Thanks!

David Ascher started using PyBlosxom and there are a couple of other users who look like they're just starting to use it as well. I think that's fantastic--especially given that the project is on life support right now.

Life support? What makes me say that? Well, I've been threatening to do a 1.0.1 release for months but never did it. Development has all but stopped because there aren't any active developers. Back when I released 1.0, I told people I wasn't going to touch it for 6 months because I was really burned out on this project and I had too many other things going on. So then nothing happened except a mild trickle on the mailing lists.

I'm not sure what to do. I can't really take on another project and push it through the motions. PyBlosxom has documentation, but it's mediocre and has large gaps and it's spread across two sites one of which I don't think most people get to. The debian maintainer for the PyBlosxom package needs help updating the package, but I don't know enough about packages to help and haven't had the time to work on it. There has been some interest in a flavour registry, but it seems that there's only interest from a "we want a flavour registry" perspective and very very little to no interest from a "I'd like to contribute to a flavour registry" perspective. Blah blah blah.

There are a bunch of issues and no one to solve them. I'm really hesitant to throw my energy at this project again. Part of me wonders if I should just start solving some of the smaller problems that need to get solved (lack of testing infrastructure, lack of centralized documentation, ...) and then go from ther step by step. Seems so overwhelming.

Not to mention that my life is a mess right now--I'm still moving and I've got a list of promises I haven't fulfilled dating back to two or three years ago. Then I got bitched out on one of the projects I work on for being an elitist egomaniac. I just want to help identify and fix problems to make things better/easier/faster/more useful! Is that so wrong? I'm just one man! Gah!

I got a comment from David Ascher on this entry which pointed out some issues with the wbgamazon plugin. After a few minutes, I fixed the problems listed and released a new version.

my pyblosxom plugins

I've blogged for so many months now that the Archives listing on the side was getting pretty long. I don't really want a long list of months and years there, so I was looking for options.

Ned Batchelder lists his archives by year. For each year, there's a summary page by month which lists the dates and titles of all blog entries for that month. I really liked this idea, so I wrote my own archives plugin to use it. It's not exactly the same--the output is slightly different. It's good enough for me, though.

my pyblosxom plugins

I've been super busy over the last few weeks. Between work and moving and weddings and trying to catch up with things, I haven't had much time to ruminate on anything or work on any of my projects.

There's one exception to that... I'm a coder on DarkRifts and I've been doing some minor refactoring and overhauls of some of the pieces of their mudlib. That's coming along nicely. The other coders have been really kicking in and getting things done lately. Watching the codebase flourish has been wonderful.

I'm not entirely sure what I should do with PyBlosxom. Development has pretty much stopped--Ted, Wari, Blake and I have all moved on to other things (babies, other projects, ...). No one else has stepped up to the plate. Though we keep getting emails on the dev lists and elsewhere about how no one will use PyBlosxom unless it does feature x and feature y and how there's lots of bad code and so on so forth. I wish more people would take the responsibility to help out.

I'm going to take some time to slim down my site and make bits of it easier to use. Then I'll package up the templates I use and make them available for other PyBlosxom users. I'm curious to see how long that takes and how much effort is involved.

I noticed that almost all the comment spam I get has the word "casino" in it. I added some code to the comment plugin to check the comment for the word casino and if the word is there, I ditch the comment. That seems to work very nicely (in the last 24 hours, it's ditched 7 bad comments and no good ones) though it's a short-term fix.

Long-term, I have a few thoughts. I may re-write portions of the comments plugin so that it saves comments originally in an "approval" stage. Then I'll write a command-line program that allows me to approve or reject all the comments in the "approval" stage one by one. That'll be pretty easy to deal with though it introduces a time-delay between when a comment is created and when it is posted.

Alternatively, I could just write a command-line program that goes through all the comments since the last one I "approved" and allows me to go through them one by one and weed out the bad ones.

Still, given that my blogs aren't related to casinos in any way, using "casino" seems to be a good filter.

Turns out it was creating garbled yucky stuff that hosed my RSS 0.91 feed. I fixed it so that if it thinks it's outputting to an RSS feed, it just returns rather than doing the transformation.

I should look into making this a postformatter--that would be better.

my pyblosxom plugins

I look at Anil Dash's links log daily now and decided to kick up one of my own partially to give people a glimpse of what I'm looking at day to day, but mostly because I need a way to keep track of all these links.

Anyhow, I implemented my links "blog" as a category under my current blog. In that category directory, I tossed a different set of templates so that it's more "minimal" (inspired by what Anil does with his link blog). Then I used the filter plugin from the Pyblosxom registry so that I could "hide" the links blog entries from my main site (I figure it'd be too spammy).

Took me maybe 10 minutes to implement the whole thing--5 of which were used to update the filter plugin from the one at the link to something that works with Pyblosxom 1.0.1 (soon to be released).

Link to my links blog.

Ahhh--just got hit with my first comment-spam experience. That kind of sucked but was pretty easy to deal with since Ted organized comments as separate files.

If it happens again, I'll have to think about how to deal with it. Maybe switch to a comment approval process or something.

I think I may release 1.0.1 this weekend depending on what else is going on life-wise. I tossed a feeler email out to the dev list in regards to what else should be fixed for 1.0.1, but didn't get anything back--which isn't surprising as people are pretty busy these days.

So... to do a release or not--that is the question. Is there anyone reading this blog who has things that they'd like to see for a very minor fix-it point release that's doable by one man who only has a bit of free time (unless they're interested in sending in a patch)?

Last night I did a lot of work on my registry plugin. I'm completely re-writing it from scratch--how it works, what it does, so on and so forth.

One of the things I never bothered to do was separate my blog (what you're looking at now) from my development. So whenever I make a mistake and create a bug, my whole blog goes down. Sometimes, in the case of last night, interesting things happen. I was playing with FileEntry and the generation of the absolute_path which had the effect of mucking up all the categories and permalinks on my site.

Anyhow, so things go up and come down pretty often on this blog since it's very very bleeding edge in terms of the source code and I'm often editing things live.

Having said that, I'm almost done the new registry plugin. I'll install it on Planet PyBlosxom soon and overhaul all the existing registry entries. This version of the registry plugin will make it easier to do a flavour registry as well. It's also a heck of a lot easier to set up and maintain.

I've been asked a couple of times for the templates for the HTML flavour of my blog. So here is a tar.gz file of them and the stylesheet.

A warning to folks who download that file: the templates and stylesheet aren't wildly pretty. I'm not a web-designer--I just pretend to be one.

I've noticed while working on PyBlosxom that bugs can literally be reported anywhere. Not only that, but people get annoyed (really annoyed) when you don't respond to their bug report which was reported using a method that I never would have dreamed of. We've had reports in all the following places:

• on the pyblosxom-users mailing list (I prefer this one)
• on the pyblosxom-devel mailing list (this one is great too)
• in a comment on the PyBlosxom main site for an article that has to do with a release
• in a comment on the PyBlosxom main site for an article that has nothing to do with a release
• in a comment on some other site (mine, Planet PyBlosxom, ...) in an article that has nothing to do with a release
• in a blog entry on someone else's site--someone I've never previously had contact with and whose blog isn't connected to anyone else's blog
• in the PyBlosxom documentation wiki
• in some other wiki that I've never previously seen
• on IRC in the #pybloscom channel (these are cool, but I'll never hear about the bug unless I'm specifically online which is not usually the case)
• sent in email to me or someone else
• added to the bug tracker on our SourceForge site

It takes a huge amount of time to check all these places--many of which come and go. It really puzzles me why people don't try to be more social and send bug reports via channels that other projects typically use (bug trackers, mailing lists, and IRC). I've been trying to coerce people into a few standard channels, but it's really hard on a project like this and there's a lot of resistance.

Bottom line is that this kind of thing really affects the project's quality. There are bugs out there that I will never trip over that someone else did but because they chose to whisper it into their pillow at night rather than tell someone about it, the bug won't get fixed and will trip someone else up.

I thought blogs were supposed to be social tools to enhance communities and promote discussion.

Anyhow, we can only do the best that we can do.

We've cleaned up a lot code and documentation and fixed a lot of bugs. We've stabilized the API and added static rendering. In short, this should be a pretty solid 1.0 milestone for PyBlosxom.

I encourage people to upgrade. When you untar the distribution tarball, read through INSTALL and README. These files will walk you through installation and upgrading from 0.9.

Download it at https://sourceforge.net/project/showfiles.php?group_id=67445.

Personally, I'm glad we finally pushed out 1.0. I'm not sure it's a perfect release, but it's good enough for a 1.0 milestone and I feel good about releasing it at this point. It's hard to push a project through to a release when there's not much feedback from testing and usage of previous alphas and release candidates. I think at some point you just have to bite the bullet and push it out and see how it does.

Cheers to the PyBlosxom development crew!

I'm releasing pyblosxom 1.0 RC1 right now. I overhauled the callback documentation in the ReadMeForPlugins file and read through other documentation and I think we're good enough for a 1.0 release now.

The RC1 is at http://bluesock.org/~willg/dev/pyblosxom/pyblosxom-1.0-RC1.tar.gz.

Feel free to download it and test it out--it's very much like alpha1 with a few differences:

• I threw in a logdir property into config.py and adjusted plugins that use logfiles to use it
• Documentation fixes

That's about it, I think.

In the tar.gz file is an INSTALL file which details installing PyBlosxom. There is also a README which talks about differences between 0.9 and 1.0 (which will help you upgrade an existing PyBlosxom installation).

Let me know what you think. I plan on doing a 1.0 release in the next few days. Probably Thursday.

We're working to put out PyBlosxom 1.0 which should be coming out very soon now. I'm in the process of overhauling all the documentation and doing some minor tweaks.

If you have comments/feedback/problems, toss me a comment and express them here.

I'm testing out gnome-blog.... Not entirely sure what all these things do....

I'll post this entry and see if it does what I'm hoping it'll do.

Update: it sort of did what I expected. Gnome-blog seems to wrap everything in <p> stuff. It seems it handles the html for you which is nice, I guess. I had to go in manually and edit the resulting blog entry, though.

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 http://bluesock.org/~willg/test/.

Things the static renderer is not good at:

1. figuring out if an entry has moved from one category to another (you'll probably end up with two versions)
2. comments (if someone adds a comment, that doesn't adjust the mtime on the entry file, so we won't re-render)
3. 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/willg/public_html/cgi-bin/
   ./pyblosxom.cgi --static
   find /home/willg/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).

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.

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:

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

If I want to completely eradicate the plugin:

1. delete the plugin file from the file system
2. delete all entries in config.py that have to do with the plugin
3. 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]

[1] I also want to fix the comments documentation, test all the code, and get everything ready for a 1.0 release some time in my lifetime.

I have a statically rendered version of my site at http://www.bluesock.org/~willg/test/. The links on the right side are a bit off--but that's a problem with my flavour templates and not the static rendering code.

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.

I hacked for 3 or 4 hours on static rendering today. Almost have it complete where "complete" is defined as "statically renders your basic blog into html and other flavour forms" and is not defined as "handles dynamic content, comments, and other neat things seamlessly".

I think that'll all be in version 2.

In the process of implementing what I implemented, I moved some stuff around, cleaned up the common_start stuff, re-tested xmlrpc, removed some old files in the CVS repository, and fixed some bugs that had been lying around undiscovered.

Assuming I get some time tomorrow to work on it, I'll have static rendering finished before the end of the weekend.

I just made a bunch of changes to PyBlosxom and figured I'd test to make sure xmlrpc still works...

I added the Request object to the locals for eval_python_block. I also did away with the "printout" kluge I had--you can use print now.

If you used an old version and are upgrading to this version, you'll need to convert all your "printout" function calls to regular print statements.

Find it in my plugin index.

Yay--it's released! Now I can sleep at night again and dream of iplementing static rendering.

A couple of weeks ago, I checked in code to help out PyBlosxom installation and configuration. I made changes to pyblosxom.cgi so that you could run it from the prompt:

   ./pyblosxom.cgi

It tells you your Python version, OS name, and then proceeds to verify your config properties (did you specify a valid datadir? does it exist?...) and then initializes all your plugins and executes verify_installation(request) on every plugin you have installed that has the function.

As a plugin developer, you should add a verify_installation function to your plugin module. Something like this (taken from pycategories):

   def verify_installation(request):
       config = request.getConfiguration()

       if not config.has_key("category_flavour"):
           print "missing optional config property 'category_flavour' which allows "
           print "you to specify the flavour for the category link.  refer to "
           print "pycategory plugin documentation for more details."
       return 1

Basically this gives you (the plugin developer) the opportunity to walk the user through configuring your highly complex, quantum-charged, turbo plugin in small baby steps without having to hunt for where their logs might be.

So check the things you need to check, print out error messages (informative ones), and then return a 1 if the plugin is configured correctly or a 0 if it's not configured correctly.

This is not a substitute for reading the installation instructions. But it should be a really easy way to catch a lot of potential problems without involving the web server's error logs and debugging information being sent to a web-browser and things of that nature.

I decided the registry plugin needed to allow users to see all the pending submissions and details therein. So I made some changes:

• added handling of /registry_queue which shows all the pending submissions.
• added some code to displaying of the entry so that the "edit" link doesn't appear if there's already a pending change.

Get it on my pyblosxom page.

We're almost done with 0.9 and the code is baking in CVS and Ted is doing all kinds of crazy stuff with metaweblog, comments, and his Lucene search plugins. When that all gets sorted out, then we'll do a release which has been a long time coming.

In the meantime, if you want to try out what's in CVS, here is a snapshot as of February 24, 2004. Setup is just like PyBlosxom 0.8.1. Features for users are pretty much the same. Biggest changes are architectural which will enable plugins to solve a very wide variety of problems and do all kinds of exciting stuff.

Official announcements and all that on the PyBlosxom site soon. Additionally, I've been working on Planet PyBlosxom, which will provide a centralized newsfeed of PyBlosxom stuff from PyBlosxom users' web-sites via their RSS feeds.

I know I'm not the only one who's getting referral spam from John Kerry's blog and blogs of other Democratic candidates. How totally lame and obnoxious.

Anyhow, with the PyBlosxom logstats plugin, I can just hide them all from showing up. POOF!

I just finished making a bunch of code changes. So if you go this route, you may encounter problems. Having said that, feel free to email me or the pyblosxom-users mailing list with questions. It should be noted I'm posting this entry with w.bloggar right now.

1. Make sure you have the latest CVS codebase
2. Add the xmlrpc and xmlrpc_blogger plugins
3. Read the top of xmlrpc.py and set up the right config.py parameters

The w.bloggar account settings should be as follows:

In the Content Management System section:

• Blog Tool: "Custom"

In the API Server tab:

• Host: the name of your server
• Page: the url of your blog with /RPC at the end (mine is /~willg/blog/RPC)

In the Custom tab:

• Posts: "Blogger API"
• Categories: "Not supported"
• Templates: "Not Supported"
• Title Tags: (make both fields blank)
• Category Tags: (make both fields blank)

When you go to write a new entry, leave the title field blank and do your entire post in the data section with the first line being the title (just like blosxom entries).

One thing you should note is that pyblosxom will take the first line and use that to generate the file name of the entry. So if the title of the entry is "How to use w.bloggar with pyblosxom", the file name ends up being "How_to_use_w_bloggar_with_pyblosxom.txt" which is a little annoying but whatever.

That seems to work for me. Poke me if you have questions and I can update this entry with the adjustments.

This is a test post from w.bloggar testing out my new xmlrpc and xmlrpc_blogger plugins.

Theoretically, I just got w.bloggar working with my blog. There were some minor fixes I had to do to the xmlrpc lib we have in PyBlosxom. I'll be checking these changes in.

Beyond that, I wanted to see what the tool actually did. Where does it put the file? What does the file look like? What's the name of the file? So on so forth.... Enquiring (or is it Inquiring) minds want to know!

On Friday, I sat down at my desk at work, put my coffee mug down, and went to scratch my eyebrow when suddenly the lens fell out of my glasses and the tiniest screw in the universe dropped almost unnoticeably to the desk in a beautiful swan dive. This surprised me greatly and led to three different epiphanies:

1. It's hard to fix your glasses when you can't use your glasses because they need fixing.
2. When a jewelers screwdriver isn't handy, a paperclip can do--but poorly. For some reason no one has a jewelers screwdriver handy which is a shame. All mine were at home and I was at the office. I was able to screw the tiniest screw ever using the edge of a paperclip while squinting so much I was in that funky limbo between where I couldn't see because I wasn't wearing my glasses and I couldn't see because I was squinting so much trying to adjust for not wearing my glasses because that's what I was trying to fix. Anyhow, I fixed it enough that I was able to get home.
3. When you ask someone for a jewelers screwdriver (which they don't have) they show you all the stuff they do have which might (but really doesn't) suffice. People have a lot of weird stuff at work.

Anyhow, I was amused to discover that Ted also had vision problems. We're like TWINS!!!

I got home today and totally forgot to fix my glasses until I had been sitting here for 10 minutes staring at this weird bug I found (or thought I found) in PyBlosxom that was happening in one of my blogs but not the other. The PATH_INFO for the url http://blog/george/sophia showed up (incorrectly) as "/blog/george/sophia.txt" and for the other showed up (correctly) as "/blog/george/sophia" Both blogs were configured almost identically, so I was perplexed. Then I realized that it was just me doing something totally stupid. That's when I remembered that I had to fix my glasses. So I pulled out one of my jewelers screwdriver kit (I have several--one of which I should bring to the office) and pulled out a perfect screwdriver, fixed my glasses and marvelled at how a screwdriver of the right size can make all the difference in the world.

To summarize, my glasses are fixed, I fixed my configuration, PyBlosxom doesn't have a bizarre PATH_INFO bug, and I learned that a paperclip can be used as a quick fix.

There are some minor tweaks, but more importantly, I added the ability to evaluate python code blocks in the static page. Find it in my plugin index.

I whipped up a plugin that changes the renderer to the debug renderer if there's a "debug=yes" in the querystring. It's not wildly exciting, but it works nicely and I can debug things without necessarily taking my entire blog down.

Get it at my plugin index.

I just added locking to Pyblosxom to allow separate Pyblosxom requests to synchronize on centralized data. In my case, the data is a file of how many views each of my blog entries has gotten. It seems to be pretty functional. It's something I had coded in my viewcounts plugin, but I've moved the code (and added to it) into the tools module so we can all use the same base.

An example of usage is this:

   from Pyblosxom import tools

   LOCKNAME = "viewcounts.dat"

   ...
      lockret = tools.get_lock(request, LOCKNAME)
      if lockret:
         # yay -- we have the lcok
      else:
         # foo -- we don't have the lock


   ...
      if tools.has_lock(request, LOCKNAME)
         # yay -- we have the lock
      else:
         # foo -- we don't have the lock

   ...

   tools.return_lock(request, LOCKNAME)

The code is in CVS. It'll go into the next version. Also, I added a unittest module to the code base.

I've been in some kind of neat motivational kick the last few days to update my plugins. This time, I've overhauled the registry plugin that Wari uses for the Pyblosxom web-site.

Changes:

• added ability to submit new entries
• added ability to edit existing entries
• fixed sorting so that you can sort by any input name
• added the ability to do option inputs
• moved declaration of what items were involved to the config.py file (along with other things)
• added documentation to the top
• refactoring of item specification stuff

Anyhow, if you were one of the one or two people that were using it, this is definitely worth updating to. If you need help reconfiguring it or if you have problems, let me know.

It can be downloaded at my pyblosxom page.

(snuck it in just before the end of the year--yay!)

I was poking through other peoples' blogs and bumped into one that mentioned a bunch of things I should do to my booklist plugin to fix it. One of which involved switching it from hard-coded html to use pyblosxom flavours. So I did that work and some other neatening up and released it. Get it on my pyblosxom page.

I went through and added the MIT/X License text to all my plugins and updated them with some minor bug fixes and additional features.

My pyblosxom stuff is here.

A couple of friends pointed out to me my META tag to refresh from /~willg/ to /~willg/blog/ was borked and while it worked fine in Mozilla and derivatives (which are the only browsers I use), it didn't work at all in Internet Explorer. All fixed now though.

For future reference, the "good code" is like this:

   <meta http-equiv="refresh" content="0; URL=http://bluesock.org/~willg/blog/">

First off, it's now "http://www.bluesock.org/~willg/blog/". I followed Rael's directions and implemented the mod_rewrite adjustments. That worked super. Then it created some mild issues that I'm sorting out now. Namely, I have all kinds of content in different formats: html, shtml, php, and now pyblosxom entries. So I'm going to do a massive normalization of all the content and get rid of the stuff I don't update ever. Getting there.

Anyhow, so my point is that my entire site is now in a state of flux as it gets re-absorbed into more of a blog with a slight amount of static content.

Wari has been noticing some scaling issues with entries. Of course, I don't notice anything like that since I only have like 73 entries (as of the time of this writing). So I hereby commence my effort to create oodles of useless chatter in order to better test out PyBlosxom. I will call this Project Content. All such chatter will go into the content category.

I highly suggest using the categories on the right side thing there to help in discerning the silly filler from the real content. You know. Important things like Lyntin status (3.3--working on 4.0).

The title of this entry comes from this funny story in college. This dude was in the DEClab with us and we're all quietly typing away working on whatever it is we were working on. Then he stands up all of a sudden and slams his hand on the desk (WHACK!) and says in this thick Eastern Bloc accent, "NEEEDS MORRRE MEMOREEE!"

It doesn't look so funny written down but my friend Chris does this imitation of it that's got to be criminal. Hilarity ensues.

This plugin handles registry kinds of things. I use it (now) for the Lyntin code registry. It's soooo much easier to deal with than the one I wrote in PHP.

Code here.

I checked in some changes I made last night which affect how variables get expanded and what kinds of things we can do with metadata variables. Now, we can expand the following variable things:

So now the following examples are all valid variables:

• $foo
• $foo::bar
• $foo::bar(1, 2, 3)
• $foo::bar::bar2({"arg1": 1, "arg2": 2})
• $foo("arg1", 1, {"foo": "bar"})
• ...

In typical fashion (and at Wari's behest), I wrote a quick plugin which uses this. It allows you to include files in your head and foot templates. I use this to include my .project file so people can see it on my web-site as well as finger me on my server and I only have to update it in one place.

Code is here.

This plugin registers with the prepareChain and injects an entry to the beginning of the entry_list that holds personal information from $datadir/personalinfo.dat which is a pickled dict. I have mine updated via cron at the moment.

I don't really have a wild need to have this information, but it occurred to me that our system allows for this without any problems. I mentioned this to the pyblosxom-devel list and Ted replied that we need more examples. I thought about it during lunch and then whipped together this example (it took 10 minutes again--I'm into these 10 minute plugins at the moment).

This one counts the number of views for a given entry. It only counts the entry if the renderer asks for the $viewcount value. At that point, the viewcount module will figure out how many views this entry has had (using the id on the entry), add one to it, save the new value, and then return the new value to be displayed.

This plugin registers with the prepareChain and for each entry it adds a $wc metadata variable. The wordcount is sort of an expensive process since it requires the data of the entry to be populated and we only populate that on-demand. Thus we need to populate the $wc variable on-demand as well.

...

The effects of this is that I can add a $wc variable to my story.html template file and you see a wc: thing on all of my entries.

This plugin and the entry that describes this plugin were written, tested, and documented in 15 minutes.

I just finished the last bit of the overhaul that Blake started which involved separating retrieval of content from content rendering. It's super cool because now content can come from anywhere--it's no longer tied to a single datasource (sql, file system, ...).

I also just promised to name my first born child the be-yoo-tiful name of "xmlrpc_username". I think the way it rolls off the tongue ... it ... it just brings a tear to my eye--it's so beautiful.

I also wrote a plugin that looks at the url to see if it's "/plugin_info" and if it is, then it will build a series of entries based on the installed plugins:

...

You can see it's output here. How do you like them apples?

I'm going to be doing some pretty dicey pyblosxom changes over the next day. This web-site is liable to go up and down faster than a pogo stick!

You might be greeted with bugs! Stack traces smeared in pink and colors repugnant to the human eye! Strange hexidecimal incantations that look more like inscriptions to a mystical Egyptian pyramid of Ra than meaningful web-site error data! Be wary! BE VERY WARY!

Don't fret--it'll all be over in a few days. And definitely don't email me because I already know.

Read more about it here.

I've been using PyBlosxom for 3 months now and it just keeps getting better. On top of that, the development and user communities have grown significantly in the last month--definitely a testament to the project and its maintainer.

Originally I thought blogging would be an easy way to provide an up-to-date status (and log) of the various projects I've got going on. It becomes very easy for an outsider to look at my blog and click a few links and realize how often I work on a particular project and what other projects are taking all my valuable time by distracting me.

After a few blog-like applications, I finally settled on pyblosxom which didn't have everything I wanted, but it had the bonus of being written in Python and that makes it super easy for me to fix and add functionality.

Then I found myself working on the pyblosxom code-base and talking to Wari at length about various pyblosxom things.

Now I blog for two reasons. First to provide status on my projects and second, to provide more data with which to test pyblosxom functionality.

That's why I blog. On top of that, I'm fascinated by the decentralized collaborative forum that blogs provide. It's not unlike editorials in the newspaper.

So, I was looking around in the wide wide world of blogging and saw a bunch of sites that list the categories they have on the side along with their archives and calendars and all kinds of fancy things... And I wanted one too!

I took a gander at the pyarchives.py plugin and then cannabalized it into pycategories.py which returns that fancy list of category links you see on the far right under the calendar.

Then like a good boy, I added it to the CVS repository figuring it's probably going to be a must-have feature rather than an eclectic feature that only a few of us real blogging odd-balls would want.

Yesterday I slam-dunked some code to form some infrastructure for plugin modules--I figured I've done this for Lyntin and Stringbean, might as well go for the hat trick! The code allows us to build a set of callback chains and such to let people extend the functionality of pyblosxom without having to re-write pyblosxom internals. Blah blah standard plugin stuff.

At some point, I'll write a tutorial to use it beyond the brief documentation I left in the api module. Until then, I leave the following excerpt for how it all ties together using the pycalendar module as an example.

01: """
02: This is my fancy pyfortune module.  Basically what it's going to do
03: is call /usr/local/bin/fortune and populate the fortune variable
04: with the resulting string.
05: """
06: import commands
07: from libs import api, tools
08: 
09: class PyFortune:
10:   def __init__(self):
11:     self._fortune = None
12: 
13:   def getFortune(self, args):
14:     entry_dict = args[0]
15:     text_string = args[1]
16:     if self._fortune == None:
17:       self._fortune = commands.getoutput("/usr/games/fortune")
18: 
19:     return (entry_dict, tools.parse({"fortune": self._fortune}, text_string))
20: 
21: def initialize():
22:   api.parseitem.register(PyFortune().getFortune)

Figure 1: libs/plugins/pyfortune.py

Mmm... It occurs to me that this doesn't use the api module at all. On the other hand, it's pretty neat looking, so I'll leave it for now. At some point someone is going to have to remind me to write an api usage example.

Have a dynamically generated fortune:

...

This fortune has been removed because it turns out that dynamically generated text causes RSS feeds to think this is a new entry every time. Thus, no fortune for you!

I re-wrote my calendar utility (which tells me what my schedule looks like when I log in) in Python. This is good because I haven't touched Perl in some time and I wanted to add some other formats to it (like handling "second thursday" and "*/15") and I wasn't looking forward to figuring out what I wrote many years ago.

I also re-wrote my logger at work. It's not really a logger--it's more of a log extrapolator. It takes all these fun bits and puts them in places where I can glance over them quickly and guess at what happened rather than reading all the gory details and know enough to write a thesis.

Then I wanted to add a calendar to pyblosxom. So I adjusted the code to handle drop-in plugins and threw together a pycalendar thingy. It's not great but it works and it's not half-bad for an hour of coding.

So this is my first post with my new blogger. I switched from a partly hacked version of Steve Gutenberg's weblog thing to pyblosxom which allows me to do blog entries with standard text files and a bunch of other stuff.

Unfortunately, it's going to take a bit to get things converted over and settled. We shall see....