revjim.net

December 17th, 2002:

rapture letters

I signed myself up for a Rapture Letter just so I’ll know when it happens. [via The Gentle News] For those of you who don’t know, the rapture, in a quick summary, is the supposed second coming of Jesus Christ at which time all believers will be led into heaven, whilst the non-believers will be left here on Earth to perish, fight, suffer, die, and generally have a horrible time.

What I think is the most interesting is the assumptions these people make in order to implement a system like this. One can only assume that the system works because the administrators have some method of informing it, on some pre-determined interval, that the rapture has not come. Therefore, when the system doesn’t get the message, it assumes the rapture has come and sends out the email messages. Let’s assume, just for one second, that Jesus will be coming to Earth again, and that the rapture will occur exactly as these people believe it wil. In order for this system to work the creators must assume that they, themselves, will not be left behind. Additionally, they assume that persons who are going to heaven after the rapture are capable of knowing those who aren’t in order to provide their email addresses.

What is also interesting is this: why do they care? Let’s assume they are right: the rapture is coming and they’ll be saved and I’ll be left here unless I believe. Why are they even willing to pay money that they could be donating to GOD for a web server, and waste time and energy that they could use to do GOD‘s work programming and maintaining the website, merely to inform the non-believers when it is too late for it to do any good?

even when you’ve thought of everything, you haven’t

For quite some time now, I’ve been attempting to devise an easy method to allow me to use the template engine of my choice for MovableType, as opposed to using theirs. The biggest reason for this is to save the time required to “Rebuild” for an insignificant cosmetic change. The secondary reason is to allow other pages (not managed by MovableType) to use the same layout templates so that, a change in one template file would change the look and feel for the entire site.

I’ve considered so many options. Of all of those, the following seemed the most promising:

  • Access the Database directly from PHP
  • I’ll write PHP scripts that access the MovableType database directly. I’ll drop my scripts into place and turn off all of MovableType’s archiving so that, essentially, it doesn’t output any files. In other words, I’ll use MovableType as an interface to the database, but my readers will actually never be using it.

    This idea went out the door because I figured, if I’m going to do that much work, I may as well write the admin interface as well and rid myself of MovableType all together.

  • Have MovableType output XML

    I’ll make MovableType output the entries in XML. Then I’ll use xmlParser to read them in and make them available to me. I’ll decide which entry to read in by looking at $_SERVER['PATH_INFO'] an no one will be able to tell otherwise.

    Admittedly, this was my best idea yet. The storage method makes sense. The access method makes sense. The URLs stay clean. If data is needed to be represented a different way (perhaps I desire to have a “most recent comments page” some day), I merely add a quick template to provide the data somewhere accessible, and make methods to retrieve it. The only real reason I haven’t done this is because it’s quite a bit of work.

    In order to get the advantages I seek I need to make certain that, at the very least, my “Individual Archives” provide all the data I require. Otherwise, when I learn that I didn’t include something that I wanted, I have to rebuild again anyway. This concept, however, does start to get a bit thick when one starts to think about “Master Archives”, “Category Archives”, and “Date-Based Archives”. All in all, it can be done, it’s just a lot of work. Probably less work to simply write my own software.

What is funny to me is that, in all of the thought I put into this, there was one option that I just never considered. Brad Choate writes tons of MovableType plugins and interesting hacks and tips for getting MovableType to do things it wasn’t written to do. Last October, he wrote about yet another way to do exactly what I’ve been trying to do: have MovableType output small PHP scripts that merely set native PHP variables equal to the data representing each post, and then calling a function that executes Smarty to render the page.

I don’t particularly like his idea any more than I like any of the others that I had. His solution still doesn’t address MovableType’s comment system and the templates embedded within that portion of it. MovableType uses baked content (pages that are generated and stored on disk) for the weblog, but fried content (pages that are built dynamically everytime they are requested) for comments and TrackBack listings. Additionally, the whole idea still becomes overly complex once you dig into “Category Archives”, “Date-Based Archives” and “Master Archives”.

My point is simply this: even when you think you’ve exhausted all possibilities, you haven’t. There is always one more option. There is always one more possibility.

windows

[ cityportraits ]


(click to enlarge)

windows

American Beauty Mill
Dallas, TX

Minolta dImage 7
handheld
1/90s @ f/5.7

CheckRDF

CheckRDF was announced on Freshmeat yesterday:

CheckRDF is a tool, consisting of a shell script and a Haskell program, for downloading RDF site summaries and showing news in a text file and in an HTML file. It is highly configurable.

It can show new items via tail on the console, or in HTML. It appears to poll all the news sources at a defined interval and shows the new items for each feed group together by polling interval. I haven’t actually used it, but it looks decent.

California here I come…

Having been born in California, and a resident of that state for 13 years I can tell you this: if California secedes from these United States of America, I’m moving back right before it does.

MT to LJ

I’ve written a PHP script that posts an entry to a LiveJournal account using the TrackBack API for input and XML-RPC to speak to LiveJournal. It was intended for use with MovableType, however, it can be used with any TrackBack enabled software. It currently supports most of the LiveJournal functionality, including posting to communities and turning off comments. In fact, if you’re reading this post on LiveJournal right now, it is because of this script.

Even though the script isn’t that complicated, is there enough interest in it to warrant me packaging it up and writing a small tutorial? As it stands now, all of the functionality of the script is activated by modifying the TrackBack URL that is used within MovableType, which isn’t a big deal for me, but makes it pretty clumsy for most novices.

Is there significant interest in seeing this script hosted remotely with a more attractive wrapper placed around it’s features? I’m thinking that it would work like this: someone would login, enter all the LiveJournal related information, and then it would give them a nice, clean, memorable URL to use for TrackBack.

Comments, questions, and display of interest appreciated.