The Rants, Raves, Gripes, and Prophecies of Paul R. Potts
Contents by Category
Contents by Date
Wow, I just did a Google search on my weblog's base URL and found out that, as far as Google knows, not a single web page links to my blog! That's inspiring, it really is. On teh intarweb, no one knows I'm not a dog. Bark, bark.
For some reasons the Wiki is not getting crawled by Google: for example, I can't get any hits from keywords on my page of reviews of Terry Pratchett's Discworld novels. The blog is, though; Google probably found it through our main home page, which appears as a link on various sites that archive mail and Usenet postings.
I have reconfigured my bloxsom script so that it now shows only seven stories on the default page. This prevents the default page from getting huge. This setting is unfortunately global, though, and even applies to more specific searches: so, for example, if you select the topic "geeky," you won't see my article on the Dylan programming language; you'll only see 7 of 12, with no "more..." link and no indication that there are more articles, unless you happen to notice that the number of articles on the page doesn't match the displayed count.
Strangely, in by-month view, all the articles for that month are shown, even if there are more than seven. So the limit doesn't apply here. I've got to dig into Bloxom again. I'll probably have to find another plug-in, one that will provide a "more articles..." link when browsing by subject. I've got five plug-ins already, including two which together are needed in order to allow me to update entries after posting them, without screwing up the sort order. Does everyone who uses Blosxom have to mess with it this much? If so, what does that say about its usability?
I appreciate Blosxom's simplicity and support for plug-ins, but sn't there a saying about making things as simple as possible, but no simpler? Or, in this case, as simple as it can be while still handling the most common use cases? Being able to always reach even the oldest posts when browsing by subject seems like a desirable use case to me... but what do I know? I'm just a dog.
P.S.: I installed the "moreentries" plugin. You have to modify templates to get it working. It also disables some of the other plugins, like "archives," unless you carefully reorder them. The author of the plugin has a few choice comments about the Blosxom experience here.
In the release notes for the plugin, the author writes: author writes "This is a big ugly hack. The only entrypoint that worked for this is the filter() hook; the problem is that when filter() is called, the sort() routine hasn't run (isn't even decided on yet!), and %files contains all posts, not just the ones matching the request. Even running as filter, it has to be the last plugin to run, so that any other filtering happens before we decide the 'numbering' of the posts."
P.P.S.: OK, so "morentries" was working. But then I found out that Blosxom doesn't support conditionals in the template: that means it is difficult to customize the text that shows up when there are more entries available using a previous or next control. So I tried the "interpolate fancy" plugin. It basically worked, but I ran into problems when trying to nest conditionals. So I tried Rael's own "interpolate conditional" plugin, which is simpler. It worked, but I had to give up on nested conditionals, and also limit my conditional so they didn't extend past a single line in length (this breaks Rael's plugin). So it is all working, but the solution to "how do I do that?" is in part "change what you want to do."
It seems that perhaps the chain-of-filters model simply can't always do everything one might need. I've found arbitrary dependencies, bugs and undocumented limitations at every turn: and these are very small pieces of code. It's a bit like Linux in the early days: Linux is free only if your time doesn't cost anything. And after you add rather simple functionality, it isn't such a simple little application any more.Tue, 23 Mar 2004 Blosxom and the "entriescache" Plugin
The "entriescache" plugin seems to have a problem. When I add a new entry, and then delete it, Blosxom displays two copies of the first weblog entry. It seems to have something to do with the meta time stamp: if I don't include hours/minutes/seconds, two day time stamps on the same post match. The cache gets confused. It seems to use only the timestamp, rather than a combination of timestamp and filename, to distinguish the entry.
Additionally, deleting an entry, or moving it, seems to totally baffle Blosxom. I wind up with the new entry skipped and the old one displayed with no title or content.
Updating a story is also broken; Blosxom will not notice the new file modification date, but rather goes entirely by creation date.
Finally, adding older stories (files with old creation_date metadata, but with new time stamps, migrated from my old web site) results in these stories not showing up in the weblog until I forcibly delete the state files for the plugin. Even adding brand-new stories results in those stories not showing up until I delete the state files.
Given that I'm using this plugin to try to solve the problems caused by lack of creation date metadata, it is especially frustrating that it seems to create several more. The situation I wanted to avoid is perhaps coming to pass: I'll have to start hacking Perl again. Grr...Sun, 21 Mar 2004 Under Construction
The weblog is back online in a reasonable way. Thanks to my friend Art Delano for helping me come up with a draft style sheet, which I've since modified.
The blog was destroyed by a series of accidents involving the Interarchy FTP client. Two-way synchronization can be dangerous; one error wiped out the content on the server, and a second error wiped out the content on the client. I claim there are some problems with the client program and the way it references directories, but I have not proven that yet. I bought it because the other FTP clients were all so bad, and this one seemed to offer a nice bookmark interface. Yet the interface has proven to be quite painful to use for certain basic tasks.
Anyway, after losing my files, I was very fortunate to find out that the entire contents of my weblog were available via Google. Google literally saved the day. I was very unhappy about having lost most of my incidental writing for the past year. I was able to rescue the text from the cached pages and extract the original content. Since then I've gotten an external hard drive for backup and am also keeping my weblog in a local CVS repository.
I'm using Blosxom 2.0 with a number of plugins. I've had no end of minor problems getting everything to work. It seems that some of them may be traceable to some kind of caching of scripts going on at my ISP; changing the code, as opposed to the templates, did not always result in different behavior when reloading the page. At least, I hope that is the explanation; if it isn't, my weblog has an evil poltergeist hell-bent on giving me a headache, where executing the same script different times on the same text would produce different results. There are also a bunch of minor bugs and a seemingly endless number of inconsistencies, which I'll write about later.
One thing I dislike about Blosxom is fine-grained control over the number of postings displayed and the depth of the tree traversal. There is one setting for the number of posts displayed on a page, and one setting for the depth of traversal. What I'd like is to limit the number of posts on my "front door" -- the page when generated with the default URL -- to five, so that the default page is quite short and quick to generate. I want the "front door" page also to only descend one level: that is, it should only display posts at the root of my blog. Over time I will organize postings into subfolders, so this will have the effect of hiding less immediate material.
When a user chooses a subset of posts, either by year, or by topic, I want the resulting generated page to display all the relevant posts; for example, if someone clicks on the year 02003, he or she should see the whole result. A delay incurred by asking for a particular action is acceptable; the indexing plugins provide a kind of warning that there will be a lot of content (31 posts in 02003, 14 posts under Iraq).
Note that if the recursion depth parameter was applied relative to the current point in the hierarchy, this would work OK. I could set the number of posts per page to something large, say, 99, and then when the user loaded the root, with the default URL, only unfiled posts would appear. The default would then become small and quick. Clicking on topics would not include entries in subtopics, though; the hierarchies would not "roll up" subfolders. More useful would just be separate settings for the default page. I guess I'll have to dust off my Perl, which was never that good. I'm also considering either finding a similar tool written in Ruby, or porting Blosxom myself.
Anyway... the plugin I'm most excited about is Markdown. It lets me use formatting similar to Twiki; the author's goal was to allow content to be formatted as easily as we format e-mail messages. Given how easily I was able to migrate my content to Markdown, I think he succeeded. I have long been frustrated by the tedious process of marking up blog entries with HTML tags just to get paragraph breaks; by the time I get it to look right, I've forgotten what I wanted to write. I've used Twiki a lot more, but Wikis have inconsistent markup syntax.
My hope is that Markdown, as a Blosxom plugin, could become a de facto standard for basic markup, to be used by Wikis and blogs alike. I'm uninterested in running my blog as a part of my programming hobby. I've got much more interesting coding to do. Markdown and Twiki let me write content as easily as I write e-mail messages, letting me worry about formatting only if I want to.
Enough with the gory details... time to get to bed. Here's hoping one day this is easier.Tue, 16 Dec 2003 WebDAV to the rescue?
So I'm trying to use WebDAV to publish blog entries more easily. I can mount the WebDAV-ified directory on my MacOS X 10.3 desktop and read and write to it. This should be a natural for letting me save blog entries directly to the server, right?
Except that when my ISP's server "WebDAV-ifies" a directory, it gets chown'ed and chgrp'ed to a special Apache user. Permissions are drastically reduced, and I no longer have the ability to change anything from the command line. If I put a symbolic link from my weblog data directory to a "WebDAV-ified" directory, blosxom doesn't have permission to follow the link, because as a CGI it is run by suexec as if it were "thepotts," that is, my login, which doesn't have any privileges on the "WebDAV-ified" directory.
Gag. If anyone knows of a way around this, please drop me a note. I'm also asking my ISP. Why can't we all just get along? Panther will mount the appropriate volume on my desktop as an FTP server, and that's wonderful, but the Finder won't write to FTP servers. I'm fed up with crappy, slow FTP client applications with poor user interfaces and strange bugs and freeze-ups.. I could do it all with command-line tools, and maybe automate it, but it just seems to me that there must be better ways to spend my time!State of the Blog
I've finally been able to do a little cleanup on the weblog. The situation was this: after a bunch of edits, a large number of individual files now had the same modification date; they all appeared as brand new. This is Blosxom's default behavior. I have now installed a plug-in which will allow me to edit files after posting them without changing the display order. It will work, of course, but like most tools of this type it is a hack upon a hack upon a hack, all to make up for the lack of true metadata. I've forced the modification dates on various files using touch -t. I don't know the exact creation dates of many of these files; it came as a bit of a shock to me that UNIX variants do not preserve a separate timestamp for the creation date. I guess I've never noticed that before, and never had need for a separate creation date when working on a generic Linux or Solaris box, while MacOS systems and Windows systems preseve that extra bit of metadata.
Anyway, the upshot is that the mess is mostly cleaned up. I'm a bit frustrated that I can't reconstruct the original dates (and thus the order) of a number of my posts. From now on I will try to remember to include the date in the file. There is a plug-in that will read the date from the entry metadata, if I supply it, but that requires a number of Perl modules which I'm not sure I can install given that I'm running hosted... and I just don't want to wrestle with debugging the whole mess via web server logs at the moment.
A bigger question is "How can I make it easier to write entries?" I was using a demo license for TextWrangler, and liked it for the nice built-in FTP support, but I don't have the extra cash to purchase a copy. I also hate having to write pseudo-HTML, writing tags even to force a paragraph break. There should be automatic capture of metadata; there should be automatic archiving and aging of posts. Versioning would be lovely; Twiki uses RCS files quite transparently; something like that is in order. I grew to like the Twiki inline formatting, and there is a Wiki formatting plug-in for Blosxom, but all Wikis are different. I used to enjoy messing with all this, but for once I would just like to use the tools, not configure and hack them. By the time I get everything formatted, links fixed, tags corrected, saved, FTP'ed, and checked, I've used up my free time and lost interest in what I was writing anyway. Maybe after Christmas vacation (which will be all too brief and not very relaxing, as usual) I'll see if I can make use of WebDAV to simplify the posting process and get the weblog back on track. My devoted readers (both of them) can't wait, I'm sure!