kingubu's Journal

R.I.P.

kingubu — 2005-02-21T07:05:47+00:00

Dr. Hunter Stockton Thompson 1937-2005

Rest in peace, doc.

god help us all

-ubu

9/11F

kingubu — 2004-06-28T19:42:45+00:00

I'll admit, I was worried.

Worried that, living as I do behind the Orange Curtain (where both Nixon and Reagan bootstrapped their power) that I would be the only one in the theater for the local opening of Michael Moore's Farenheit 9/11.

Worried that Moore had nipped a bit too much of his own Champion of the Common Folk flavored Kool-aid and had produced, not a telling witness of corruption, war profiteering, and neo-facist power grabs but a histrionic screed that would only further polarize an already divided country. Inflamatory but ultimately impotent and dismissable.

My worries were unfounded. In fact, nothing about my trip to see Moore's latest film matched up with my expectations. I didn't expect the theater to be packed to the last seat; it was. I didn't expect to be deeply effected emotionally; I was. Most of all, I wasn't expecting to experience a sense of community and catharsis that reinvigorated my belief in cinema as an artform-- I did.

Don't go to Farenheit 9/11 expecting a bloodlessly objective presentation of the facts-- you won't find it. Nor are you likely learn anything new. The nuts and bolts of the Bush administration's single-minded intent to invade and plunder Iraq long before 9/11 and its subsequent Orwellian bullying and sleight-of-hand to make that war happen at all costs are better and more thoroughly documented elsewhere. No, here, as in all of his films, Moore presents his portraits of the people involved. Names and dates matter, but only insofar as they reveal the moral and personal character of the players.

It is under this light of human conscience that the real heroes and villians of the war in Iraq are revealed: on the one side are the priveleged children of oil and their functionaries; on the other are the middle and lower classes with whose sweat and blood that Black Gold is actually purchased. Or, in short, the Bushes, bin Ladens, and House of Saud on one side, and you and I (and our counterparts in the streets of Iraq) on the other. It re-draws the lines between "us" and "them" and counts our current top-level leaders as clearly among the "thems".

So, given this rather volatile position, how can I explain the sense of catharsis and communal bonding that I felt in the theater yesterday? Surely, based on conversations overheard before the doors opened, we represented a broad mix of political views, ages, and social backgrounds, so it wasn't just a self-congratulatory cry of "hurray for us!". If not that, then what? I honestly don't know. Perhaps, again, it is the sense of conscience that Moore brings to his work. That moral subtext that allows us to forgive his occasionally adolescent jack-in-the-box interviewing tactics because it is apparent that dignity and truth are his eventual goals. I don't know, I'm just not sure. However, the same or similar reactions are being reported among audiences from all over the US, and that, in itself makes this an important movie to see.

Don't assume that you have this movie all figured out ahead of time. You don't. Go see it for yourself and check your preconceptions at the door.

-ubu

ps: I wouldn't feel right in recommending this movie without at least mentioning the fact that there are some very graphic sequences of war and other violence. I might gleefully line up with all the other popcorn munchers to see the latest F/X-driven splattery horror flick, but I feel deeply poisoned when I see real people actually die on camera. If you are same, come equipped with the knowlege that people really die in this film and be ready snap your eyes elsewhere for a few seconds a couple of times during its run.

Cry Freedom!

kingubu — 2004-02-28T01:11:05+00:00

Finally, after two years, one cross-country move, and innumerable sleepless nights, take-out dinners and blown-off social events the AxKit Book has gone to production.

... and there was much rejoicing.

XML::Yggdrasill and Other Reasons We Called It "PerlDOM"

kingubu — 2001-11-25T03:10:53+00:00

Couple of random thoughts about the PerlDOM project and what I hope it will be:

Swappable on the front end

Okay, you have a nice shiny DOM tree-- how do you access its contents? Every single DOM implementation out there to my knowledge (and not just in Perl, either) gets the damn thing backwards in my opinion. They start with the W3C DOM spec and then code the underlying data structures to make that interface work. Wrong, wrong, wrong!!!! (okay, maybe not "wrong" but certainly sub-optimal) The W3C DOM is only one possible interface. Tis a far, far better thing to have a more generic, document object model (probably based on the XML Infoset) and then make the interfaces work over that node structure to provide access to the document's contents.

It is my intention and strong desire that PerlDOM will, for prolly the first time anywhere, provide a generic tree-structure upon which developers can map their own interface classes to provide access. Not only that, I want users to be able to choose from within their application which installed interface to use, and be able to add extra extension methods without having to re-build the node tree.

Want XPath? Load the interface for it; the underlying tree stays the same.

Want W3C DOM Level 2 with methodNamesLikeThis? Load the interface for it; the underlying tree stays the same.

Want a simple lighter-weight Perlish DOM with method_names_like_this? Load the interface for it; the underlying tree stays the same.

Want extra features like getElementsByNameRegex (oooo!)? Write the interface for it and load it; the underlying tree stays the same.

I'm sure you get the idea...

The problem we are seeking to solve here is the sad state that we have now where everyone and his brother creates YA-incompatible-with-anything-else tree-shaped data structure every time they want a new DOM interface. Better that we have a stable, predictable tree that supports multiple interfaces that can be passed around by various modules, rather than the sucky toString->reparse Hell that we live in now.

Swappable on the backend

This is the other real challenge in my vision of PerlDOM; making the One Tree work over the myriad of possible data representation of the node tree. It has been suggested that a tree can be stored in many more ways than just an in-memory HoHes and it would be verra nice to allow for alternative storage. The implication here is that PerlDOM would "just work" with the data trees built by existing implementations (XML::DOM, LibXML, Sablotron, etc.) so you could just pass those trees in and have access to all the other PerlDOMy Goodness.

I'm not 100% sure that this is really feasible, but it would be damn nice and I'm open to suggestions. Note: this is the job of the, um, NodeFactory(?) classes?

Able to finally, concretely, differentiate in the minds of XML Geeks everywhere the difference between a document object model and an implementation of the W3C's Document Object Model

Okay, I kinda covered this in the "swappable interfaces" part, but I want to underscore the point. The W3C DOM is only one possible document object model. That is, given a tree of nodes, it describes one set of methods and conventions that describe the relationships between those nodes and how the nodes are accessed by an application. Part of the goal of PerlDOM in general is to provide a predictable tree structure upon which the W3C DOM and other, alternative DOM interfaces can be mapped. If when someone says "DOM" you immediately think they mean "W3C Recommended DOM", check yourself.

-ubu

XML::SAX::Base and Why You Should Care...

kingubu — 2001-11-22T08:46:18+00:00

Having pushed XML::SAX::Base out to CPAN yesterday morning, I feel compelled to fill in the detail promised in the last journal entry, and to mention why I think having a standalone version of XML::SAX::Base is important.

First, though, let me offer my sincerest thanks to both Robin Berjon and Matt Sergeant for their invaluable contributions to this module specifically, and for the XML::SAX dist in general. Gnat is right, XML::SAX is a major leap forward; and we have the combined talent, experience and commitment of these two exemplary uber-Camels to thank for it. You rock, guys!

If you don't know what SAX (Simple API for XML) is, you'll probably want to have a look at this column, first. Basically, though, SAX works on an event/handler-based model; which means that, as an XML parser makes its way through a given document, the contents of the various parts of the doc are passed by event callbacks to one or more handler classes that provide access to the data. Examples of those callbacks are start_document() to signal the beginning of the XML document, start_element() to signal the start of an XML element, characters() to pass text contents, and so on.

Now, here's the cool part: you don't need an XML parser to generate SAX events!. Using XML::SAX::Base as a base for your "driver" class, you just call the SAX event methods directly and viola-- a SAX event stream. You can think of XML::SAX::Base as the adapter layer between Perl's built-in data facilities and the myriad of data manipulation modules, parsers and all the other fun stuff on CPAN, and the XML World. All you do is figure out how the data you have in hand would be marked-up as XML, call the SAX events in that order (passing your data through, of course), and, as if by magick, you have translated your data to XML. (Okay, to be strict, you have to have a Handler class like XML::Handler::XMLWriter at the end of the processing chain to translate the event stream into an actual XML document on the filesystem, but you get the idea...)

Nice, huh? Wait, there's more...

XML::SAX:: Base is also a generic base class for SAX filters!

In a nutshell, a SAX filter is just an event handler that accepts the SAX events, does some cool thing, then forwards all or some of those events on to the next Handler in the chain. Your can add new events to the stream (create new elements), block certain events (remove elements), mangle the data contained by the characters() events, or anything else that you can imagine... What XML::SAX::Base provides in this case is that it lets you implement only the events that are relevant to the task at hand, without having to worry that a parser or other driver is going to forward an event to your filter that you didn't think of (or care about). All events not explicitly over-ridden in your filter class will be silently forwarded to the next handler-- no muss, no fuss, no embarrassing odor.

Hardcore XML Geeks will be delighted to find that XML::SAX::Base invisibly copes with the class->method mapping for drivers and filters using both SAX1 and SAX2 class names. Again, it "just works" so you don't have to. :-)

Performance wonks will be thrilled by the fact that all the filtery goodness provided by XML::SAX::Base comes at cost of very little extra processing time. My benchmarks reveal that filters implemented on Base add only 8-12% to the total processing time consumed over using just the given XML parser alone. When you consider every single event is being forwarded through the filter class, that's pretty damn impressive (even if i do say so myself :-)

Anyway, I'll pop back in and scribble some more when I have more time. If you are interested in the concepts mentioned here, have a peek here and here for more ideas.

One final note: the standalone distribution of XML::SAX::Base on CPAN is only really appropriate for those cases where you are using it as a driver for non-XML data. If you are (or are planning to) plug an XML parser into it, just install XML::SAX instead (an identical Base.pm to the one in the standalone dist also ships with the larger XML::SAX package, and you get all the other Good Things that go along with it).

-ubu

Unrepentant Immodesty

kingubu — 2001-11-17T07:26:36+00:00

I found a few stray tuits under the couch this evening and added the missing interface sanity tests (and fixed a bug that they revealed :-) to XML::SAX::Base-- finally bringing it to release worthiness.

Wheeeee!

It really is cause for celebration, actually. I've probably worked harder on ::Base than any other single piece of code I've ever written. Sure, I've had projects that required months and months of daily hacking, and others that were more mentally challenging, and blah, blah, blah, but my approach was different this time. Rather than rushing toward release, I chose to take a more careful way through; making sure that each aspect was thoroughly tested, and the larger whole benchmarked at every turn (what a concept, huh? ;-).

Well, the slow-and-steady approach really paid off.

As it exists now, XML::SAX::Base is the all-singing, all-dancing, lighting fast, Perlish-in-all-the-right-ways, generically useful, SAX event driver/filter base class that I'd hoped it would be-- and more.

I'll pop back in later to explain the details (and why you might consider giving a shit even if you think XML sux) but for now I'll leave you, Gentle Reader, with a hearty and heart-felt. . .

WOOT!

-ubu

What does this this button do?

kingubu — 2001-08-12T03:21:37+00:00

*bzzzzzzt*