Das eez kaput! Sometime around 2002 I spaced the entire database table that mapped individual entries to categories. Such is life. What follows is a random sampling of entries that were associated with the category. Over time, the entries will be updated and then it will be even more confusing. Wander around, though, it's still a fun way to find stuff.
Exceptionally curvy. Designed without a ruler. First official usage in Boyett's TREKS NOT TAKEN (Harper Collins).
ex. It's hard to say which is more schwoopy, Betty Page or a '69 Corvette. If you pour water on something schwoopy, it'll all run off.
Better not, should not do something
ex. Bednaw make me come over there.
A chair with uneven legs. When you sit in one, you rock from side to side
ex. "I really hate this schwaked chair!"
rsync -v -v -a -r -e -p -g --delete -e ssh $cfg->{mt_home}
$cfg->{remote_login}:$cfg->{remote_path}
While not exactly "upstreaming", the effect is the same and has the
added advantage of not sending your password in cleartext. In fairness,
this scenario breaks if you don't have a shell login. I thought that
there were hooks for doing uploads via Net::(FTP|SCP) but apparently
not. Okay, so instead of executing rsync, the next best thing would be
modify the publish hooks to publish to a copy of MT running on the
remote server via the XML-RPC interface. An interesting project for the
stack. An off-shoot of that would be to set up an interface to
automagically slurp any changes from the remote server when you log in
from your home/private machine. Which would allow you to continue to
update your weblog from the laundromat; you know, if you're into that
kind of thing. Meanwhile, MT 2.1 has been released and supports the
metaWeblog API
. I will update
Blogger.pm
accordingly. Here's me, digressing...
Expatiate \Ex*pa"ti*ate\, v. t. To expand; to spread; to extend; to diffuse; to broaden. Afford art an ample field in which to expatiate itself. --Dryden. web1913
expatiate v : elaborate or expatiate upon; give details; "She elaborated on her plans" [syn: {elaborate}, {enlarge}, {flesh out}, {expand}, {expound}, {dilate}] wn
The act of placing ones fork into the toaster in an attempt to get your now charcoalled toast out.
ex. "Xavier! How many times have I told you not to forkster? You could get electrocuted!"
volte-face n : a reversal in attitude or principle or point of view: "an about-face on foreign policy" [syn: {about-face}, {reversal}, {policy change}] wn
<xsl:select value-of = "document($uri)/more/xpath/to/*[@id=$id]" > <!-- do stuff here --> </xsl:select>...so that all you'd need to do an otlml-blog are two stylesheets. The first slurps all the nodes -- note that
$uri
could just as easily live on a local fileshare as on the network -- and
builds a new document. The second transforms it into whatever format is
being requested. The problem with this scenario is that it's not very
smart about caching changes and will trot out across the network to
slurp each embedded document, regardless of changes, for every single
request. Thinking out loud now: you could enable the necessary feeping
creaturitis on the user end to send a
Hey, I've changed
notice, akin to the UserLand <cloud> thingy. Those changes
could be written to the server and read by the XSLT processor which
could be taught to return a cache file... but that still has problems
since you're can't cache the individual nodes themselves from inside
the first stylesheet. Anyway, you get the idea. Meanwhile, Dries
writes:
See http://www.drop.org/node.php?id=752 . We had this thread/discussion (see link above) about template systems, and the use of XSL/XSTL when generating dynamic pages. Most of the others tend to favor Smarty, FastTemplate and similar template systems, yet I think XSL/XSTL (or after reading your blog maybe OTLML) might be the way to go.The issue, ultimately, revolves around the place where your security, performance and logic requirements meet. I have never been a fan of embedding code in markup. Partly for maintainability, partly for security. But XSLT, like HTML and RSS before it, is a funny beast being used "out of context", as some people in the thread have pointed out. While the built-in logic can be maddenly insufficient, XSLT also has enough power that a malicious or stupid programming error can bring your machine to its knees. So, if you're working in an environment where there are designers and developers and never the two shall meet (they should, but that's another story) you shouldn't fob off the writing of the stylesheets on the designers any more than you would the writing of embedded/evaluated Perl code. For a long time, I was a purist about templates, arguing that the only artificial construct they should contain are substitution variables. Which meant a lot of fucking templates, especially if you were doing tables. Lately, I've been coming around a bit. The ability to pass a data structure other than a scalar and have the tools to read them (minimal conditionals and looping) in place is nice. I'm still not convinced, though. Speaking of emebedded Perl code, I wonder how difficult it would be to write a Template::Toolkit module to build a "smart" OTLML guest/group blog rendering tool...
116 ->perl -I/home/asc/lib/perl -e '
use WWW::Dictionarydotcom;
use Data::Dumper;
print &Dumper(WWW::Dictionarydotcom->new()->wotd());'
$VAR1 = {
'etymology' => SCALAR,
'definition' => SCALAR,
'permalink' => SCALAR,
'word' => SCALAR,
'usage' => ARRAY REFERENCE
};
note : the example, above, displays result
types
only because of annoying formatting issues I don't feel like dealing
with right now. Must learn to use
Text::Autoformat
...
dude, where's my car
This document uses CSS kung-fu and a small amount of JavaScript for rendering its contents. Efforts have been made to separate the form from the content so if you are viewing this in a text-based browser it shouldn't be an issue.
On the other hand it may look funny if you are viewing it in a browser with incomplete CSS and/or JavaScript implementations. Internet Explorer 6 comes to mind.
It's not that I don't love you. However, my time is limited and I no longer feel very good about spending it working around any one browser's inconsistencies with little, or no, confidence that they will ever be fixed or otherwise made more inconsistent at some later date.
On the other hand, if something is down-right unreadable please let me know and I will endeavour to fix it.
yes, we have no bananas
This page may not validate. It's not that I don't care, it's just that I'm not aware of it yet. Part of the reason that I rewrote the entire back-end for managing this site is that the old stuff made it too easy for these kinds of mistakes to slip through the cracks.
See also : W3C::LogValidator.pm
it's the software, stupid