Happy Birthday Sherri!
Have a great day hon. I love you.
XML Blogging
As I mentioned previously, I use XML, XPath, XSLT, and W3C XML Schemas extensively at work. Recent activity on other blogs has put me to thinking about how XML can be used to run a blog. I’m working on getting Syncato working locally for experimentation, although I doubt I’ll be converting this blog- I don’t think it’s currently compatible with my hosting provider. Instead, I want to use it to experiment with XML blogging possibilities. I’ve created this new category, /WebDev/XML, to document ideas, progress, questions, etc.
OS X Trivia
While installing Syncato via Syncatomatic on my Powerbook, I was idly watching make messages scroll by when I something caught my eye. I’ve always enjoyed watching makefiles talk to themselves, e.g. ‘Checking for xyz… found’. Today I saw ‘checking the maximum length of command line arguments…’
The maximum length of a command line argument under tcsh on OS X 10.2.6 is 16384 characters. Now you know.
Now with HTML!
A few weeks ago, when ironing out my RSS feed, I decided to render permalinks as .html instead of .dev. At the time, I implemented a .html ‘flavour’ by hacking .htaccess with some mod_rewrite slyness, converting *.html to *.dev on the way in. It worked, but links on the displayed page pointing to other pages on this site were messed up for some reason.
This has been bugging me. As well, writings on other blogs and in the Blosxom newsgroup regarding URI cruft have had me rethinking my .dev flavour name.
So, I’ve made a copy of the .dev flavour named .html, and made it the default. The old flavour is still around, in case anyone has bookmarks; but moving forward .html will be the standard (well, unless I get rid of extentions entirely… but that’s a subject for another post).
XPath Rocks
I’ve been using XPath extensively for a couple of years now. The Excel templating engine I wrote for work accepts only XML as source data. XPath is used within the templates to select the elements to insert into the worksheet. The second version of the engine, which I wrote a year ago, uses even more XML - templates are now completely described in an XML schema designed for the purpose, and requests from the web server to the reporting servers for report creation are formatted in another XML schema. Inside the engine, most all manipulation of the various XML bits is done via XPath instead of DOM accessor methods like getElementByName().
Sam Ruby is currently working with a new weblog system known as Syncato, which stores entries in an XML DB (among other cool XML features). Sam has now enabled XPath searches of his archives, using the Atom and xhtml namespaces. Hover the example search links and checkout the search urls.
This is almost reason enough to switch to Syncato immediately. Add the fact that all presentation is done via XSLT (another XML technology I love), and the case is quite compelling.
Need to know
This blog doesn’t have an ISSN number now, although one it it might. If it still can. Compatibility of Weblogs and ISSN is required reading. Via Zeldman.
Instant Gratification
I was sitting at my desk today at work, trying desparately not to lose my mind. My task for the last several days has been to redo some work I did about a year and a half ago. I was tired and uninspired. Coffee was losing its magic, and I’d been through most of my music collection. Good music is my magic pill when grinding out code (or templates, what have you), but I couldn’t find what I wanted.
So I reached into my briefcase, grabbed the Powerbook, and hopped on the iTunes Music Store. A few minutes of browsing later, I saw something by Eric Clapton. I suddenly remembered I’ve been meaning to replace my lost copy of Eric Clapton Unplugged for a couple of years now. Minutes later I was listening to track 1 as the rest of the album was downloading.
Instant gratification is so… gratifying.
Prior Art
I’ve been working on an idea for a new plugin for Blosxom. Along the way I’ve learned a few things about prior art and code re-use. The idea for the plugin is simple. Next to the date banner above each day’s set of posts (generated by the ‘date’ flavour component), I’d like to add text denoting if the day is a holiday, observance, etc.
Of course, following that age-old Programmer’s virtue of Lazyness, I don’t want to have to maintain the list of dates and observances if I don’t want to. This just screams of the need for prior art… I need to find an existing format for calendar-type data, preferably a format with lots of existing data already, well, formatted and ready for consumption. I’m ashamed to say it took a bit of digging around the web before I came upon the perfect thing… which was sitting in my Mac’s dock the whole time.
Apple’s iCal, a free download for OS X 10.2+ users, features the ability to subscribe to calendars other people publish. There are calendars of movie releases, professional sports schedules, holidays and religious observances from around the globe; you name it. iCalShare has hundreds of calendars freely available. Stands to reason the spec is open, right?
Is it ever. Much to my glee, I find that iCal uses iCalendar, also known as RFC2442, the Internet Calendaring and Scheduling Core Object Specification (catchy, n’est pas?) Not only that, but other clients exist, such as Mozilla Calendar. Life is good.
However, things are about to veer off course a bit. In looking for a Perl module to read the iCal format (mime type text/calendar, or *.ics), I found a few options. Date::iCal seemed perfect at first, until I found that it only handles iCal’s date/time format (e.g. 20030921T235900) and duration format (e.g. P2D1H30M). It doesn’t actually parse the files, extract events, etc. Net::iCal, and a host of related files, seem to fit that purpose. However, there are some issues here as well:
- Version is 0.15
- Listed as ‘PRE-ALPHA’
- No activity in about 2 years.
- More prerequisites modules than I can count
Brief side note: I tried to make my life easy by using the CPAN module to grab the modules I wanted. It’s supposed to make life easy by handling build process, prerequisites, etc. However, every time I tried to configure and run it, it would beg for files. “Please install Net::FTP quickly!” it would shout. I tried to give it what it wanted, but every time I’d start installing a module, the prerequisite processing would end up trying to build and install perl5.8. Say What?? I’m running 5.6; that’s the latest for OS X from Apple, and Fink doesn’t offer 5.8 either. I’m happy with 5.6 for now. And yet, no matter what I tried, CPAN kept trying to build perl5.8. I followed the prompts for a bit before aborting, it was really going to build it from scratch.
The moral of the side note? I ended up installing each module I needed manually, i.e. perl Makefile.pl, (go get a bunch of prerequisites and install ‘em) make, make test, make install. The whole prerequisite experience made for a very recursive exercise. I eventually came to the conclusion that even if the code worked perfectly, the raft of prerequisite modules made it inappropriate for use in a Blosxom plugin.
The Net::iCal family of modules was the product of a project called Reefknot. The list archive was dead for about 6 months, but I took a shot and mailed the dev list, looking for some info on the project’s status and future. I did get a reply, pointing me to datetime.perl.org for current work on Date/Time handling in perl (including iCal formats), and to Net::vFile and related modules for handling ‘vFile’, the meta-format of iCalendar, vCard, etc.
I spent some time playing with Net::vFile. I didn’t do too poorly; admitedly my week OO perl skills slowed me down. I eventually got some simple test code almost-working; it appears that iCalendar uses nesting within the vFile format in a way which is not yet fully implemented by vFile.
At this point, I decided to roll my own simple ics file parser. My needs are simple, I just want the start and end dates for ‘events’ as they are called in iCalendar, and the summary (description). Other calendar objects, like todo’s, I can ignore; other event properties, like UID and DATESTAMP I can likewise ignore. It didn’t take to long to come up with some code to extract a list of holidays from a US Holiday file published by Apple. Well, it did take a while, but only because I’m a numbskull, see the prior post for details. I even tossed back in use of Date::ICal, to parse the date format for me.
Once I could extract the events I wanted from an ics file, I ran into (yet) another snag: RRULEs. An RRULE is a Recurrence Rule. Most of the Holidays in my file were listed with 2002 dates, and with RRULEs describing how to calculate dates in successive years. Date::iCal doesn’t do RRULEs. A couple sample RRULES (paired with the SUMMARY of the event):
SUMMARY:Daylight Saving Time Ends
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
SUMMARY:Halloween
RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTH=10
These things aren’t rocket science, but there’s enough variation that I’d prefer to use a library (read: code I don’t have to write). I poked around datetime.perl.org, and found that DateTime::iCal will not only read ical-formatted date strings, it will also handle RRULEs, creating a DateTime::Set. Of course, I’ll also need the original DateTime module. Each of these has a few sub-modules. I’m nervous now; again, this is for a Blosxom plugin and so should have minimal dependancies. Throwing caution to the wind, I grab all three downloads and begin to install. My first try, DateTime, stops me with no less than 4 dependancies that I don’t have. Two of these are part of the DateTime family, but there is no bundle available yet.
So now I’m back on familiar turf. There are modules to do what I need, but the amount of prerequisite modules is becoming prohibitive. But what are prerequisite modules? The use of prior art.
I’m all for code reuse. Really I am. But it seems that in Perl these days, deciding to use just one module that doesn’t ship with Perl can mean a landslide of prerequisites. For use in a hosted environment such as many of us use for Blosxom, this can be a real problem.
For now, I’m undecided. I hate to keep reinventing wheels; but on the other hand I hate to keep installing high-performance racing wheels with custom rims on a Yugo. The DateTime family of modules looks very well thought out, and very well implemented, especially given its youth. Hopefully, an install bundle will come along soon. But, just as with the Net::iCal family of modules (and all of it’s prerequisites), there’s a whole lot of functionality I just don’t need. I feel like I’ve gone through alot of options just to implement a small bit of functionality. Maybe this is the curse of prior art… specs tend to be big, even when what you need is only a small part of one.
Abort
I’ve categorized this as Programming::Perl but I could just as easily have put it under Mistakes::Beginner::Really Stupid.
I was experimenting with a bit of Perl code to process a text file. The whole thing was only maybe 25 lines or so. Every time I’d run the code, the only output I’d get was a single line:
Abort.
I scratched my head and perused my code for quite a while. I didn’t see any place I was explicitly causing this, and it seemed like the most cryptic error I’d seen. A cursory search of perldoc.com and Perl Monks failed to shed any light. I assumed I must be abusing my I/O in some fashion (I am still a rookie in Perldom).
My perl debugging knowledge is even more limited than my Perl knowledge. At work I’ve used a TK-based debugger (something like ptkdbg, can’t remember), which is GUI-fied and fairly straightforward, but which I don’t seem to have on my Powerbook (note to self: find out what that is, and find a copy for home). Falling back on that most time-honored of debugging methods, the manual trace (read: liberal (ab)use of print statements), I found that my I/O was fine. The abort occured at the very end, when I tried to output (via Data::Dumper) the data structure I’d built from the file. Those of you with more perl-fu than I will see the problem immediately:
dump(\%ev);
I didn’t see it, so I searched perldoc.com for dump(). And then I learned. What I should have done was this:
print Dumper(\%ev);
This would have pretty-printed my hash full of hashes in all its nested glory. The call to dump(), on the other hand, asks Perl to immediately dump core and abort. Perl obliged.
At least now I know what “Abort.” in my perl output means.
Time, Time, Time
Been doing a little looking for prior art for handling dates, and calendar events. Link dumpage follows.