Entries classified under weblog

Bill de hÓra describes the integrator's dilemma (also known as, WS-* vs. REST).

If dirt simple equates to good growth and better profits, then the missed opportunity arises when simple and simplistic are conflated. When the WS contingent are looking at the REST and syndication crowd and saying more or less, 'here's a nickel kid', they may want to stop and take a second look at what the kid is doing with that nickel.

I thought that was great. I suggest reading the whole piece. Bill's super smart.

The WS-* vs. REST thing is starting to heat up again due largely to James Governer's SOAP is boring, wake up Big Vendors or get niched piece last week. This led to the discussion at the beginning of Bill's post on whether Microsoft is ignoring developer demand for REST tools. I have a sinister theory on this (but not MS in particular) that I've been hanging on to for a while so let's just have at it. Bill has provided the voice of reason and I don't have anything to add so I'll just follow up with some good old fashioned religious rambling.

These are blogs, right? The last time I read the blogger's handbook, we were encouraged to make unsubstantiated claims about the intentions of others (especially big companies and industry cartels) without any real evidence, so here we go...

Dan Gillmor points to an excellent example of distributed journalism in action over at Daily Kos. I was completely blown away by what I saw when I got there. I'm still trying to soak in all the background around the Plame Leak / Jeff Gannon thing but, to be honest, the specifics of this event are not as important to me as the general phenomenon occurring there. This seems an obvious glimpse into a future where involvement by the general population in issues of import to the general population is increased substantially. Herewith some rant and analysis of our present toolset and humble suggestion for improvement...

Simon points to Raghda zaid's blog, which has invoked a weird sort of uncontrollable sad rage I can't shake.

Kid 0.5 is available and I think I finally like it enough to start dumping out some example templates and API usage...

Video on the web is complete shit. Here's an email I sent to my mom today:

Okay, go here:

http://www.ifilm.com/ifilmdetail/2663486

Look for something in the middle of the screen that says "200k" and hit that. They'll ask you for a format preference or something. Pick "Windows Media" if it's an option. If not, pick "Real Media". A bunch of other crap will pop up - just close those. But try not to close the video window because it will look like an advert when you first see it.

She will never, ever see that video.

Web Antipatterns strikes again!

This is the second article following up Phillip J. Eby's Python Is Not Java. In the first article, The Static Method Thing, we took a look at how Java static methods differ from Python class/static methods. This time we're going to dive deep into the evils of getters and setters.

I have a theory that I believe proves it is impossible to travel backward in time. The theory is based purely in practicality and requires no mathematical or physical calculation whatsoever (although I throw a bit of bullshit math in for good measure).

It should be noted that I have no understanding of formal time travel theory or even basic physics so this is surely full of holes. Still, it has been fun to ponder and so I feel an urge to record it here.

If you've heard of this particular theory, please let me know as I've done some research (okay, only a little googling) and have come up with nothing.

Joshua has been toying with a new posting interface for del.icio.us. It is based on nutr.itio.us, the nice third party posting interface that has been MIA for a while. The new interface provides your tag list, a list of popular tags for the page you're bookmarking, your full tag list, and some popular tags in general. It isn't finished yet but it's an improvement over the current no-frills posting interface.

UPDATE: Make sure you understand that this is not finished yet and could flake out on you at any time as Joshua is enhancing it. Also, you have to scroll down a bit to see the new bits of functionality.

ANOTHER UPDATE: By popular request, a Big Thing has been added that makes more of the new posting interface visible without scrolling.

You can get a Thing for the new interface by entering your username below. After generating the Thing, drag it to your bookmarks bar. I've tested this on Firefox 1.0 and Safari.

I had a very small number of complaints related to basing Kid on ElementTree. This came in two forms:

1. SAX and DOM are “standard” and while ElementTree is a drastically improved system for processing XML in Python, it doesn't matter because everyone already knows SAX/DOM.

2. “libxml2 is teh rawk!”

First, if Python's W3C DOM standard based xml.dom package were a movie, it would be called Elf, staring xml.dom. It's the episode of Little House on the Prairie where Alien asks Michael Landon for permission to marry his daughter. It does not belong here!

Next, in terms of pythonicness, libxml2 is almost worse than xml.dom but you at least get something for it: they don't even have a word to describe this level of “fast” and it comes along with XPath, RelaxNG, XSD, XML-Base, XInclude, and XSLT. My issue with libxml2 is just that it's a bad dependency for a project like Kid that wants to be able to run on cheap web space with bare-bones Python support. There are a lot of hosting providers that aren't going to have libxml2 or the option of compiling from source.

I went with ElementTree because it's simple, pythonic, and fast enough. I also had a feeling we'd be seeing more development around ElementTree, which brings us nicely to why I'm posting.

I completely forgot to mention what is quite possibly the most important event to date in Kid history: the first real application to incorporate Kid templating is Ross Burton's sexy Tate (I said, “sexy Tate,” not “sexy Taint!”). It's an elegant, RDF / XHTML photo gallery that I'm dying to get my hands on. If you're into nice semantic usage of (X)HTML, make sure to peep the page source and check out the correct usage of <ul>’s and whatnot.

Ross has reported a few issues and even mentioned plans for packaging Kid for Debian. He's the proprietor of the excellent Sound Juicer CD ripper for GNOME 2, Debian contributor, and takes some kick-ass photos to boot.

Heard today on lwn.net:

... knowledge is exactly like power - something to be distributed as widely as humanly possible, for the betterment of all. -- jd

Word!

Neal Stephenson's In The Beginning was the Command Line was recently put online (legally and with permission from Stephenson, of course). I've always heard this was a must read for anyone with even a mild interest in the history of the computer industry. My vertical scrollbar is at about 37% and already I have to agree.

This alone will be worth the read (and it doesn't even have anything to do with computing):

I was in Disney World recently, specifically the part of it called the Magic Kingdom, walking up Main Street USA. This is a perfect gingerbready Victorian small town that culminates in a Disney castle. It was very crowded; we shuffled rather than walked. Directly in front of me was a man with a camcorder. It was one of the new breed of camcorders where instead of peering through a viewfinder you gaze at a flat-panel color screen about the size of a playing card, which televises live coverage of whatever the camcorder is seeing. He was holding the appliance close to his face, so that it obstructed his view. Rather than go see a real small town for free, he had paid money to see a pretend one, and rather than see it with the naked eye he was watching it on television.

And rather than stay home and read a book, I was watching him.

I fell in love with Stephenson's writing style with Snowcrash. The day after I finished Snowcrash, I purchased Cryptonomicon - in hardcover. I have not yet found the time to take on the Baroque trilogy.

Oh yea. There are some mixed feelings about the copy of Command Line linked to. The guy who got Stephenson's okay to put it online felt it necessary to annotate some bits that were slightly out of date. I read the first couple of annotations, couldn't really follow, and skipped the rest. They aren't overly intrusive and might even make sense to a different monkey.

Phillip J. Eby has a recent weblog entry, Python is not Java, wherein he points out a few aspects of Python that are notably different from Java but that are similar enough that Java coders working in Python mistake them for their Java counterparts.

He touches on a few of the characteristics that led me to make Python my general purpose language of choice, a title that had belonged to Java as recently as a year ago. I thought it might be useful to explain these characteristics without assuming the reader has a whole lot of Python experience but that they do have significant Java experience. This would have helped me immensely in determining whether Python was right for me much sooner and I hope it can be of use to someone else.

I'm planning on covering each of the items Phillip points out in his article over the next month and if that works out, I may extend the series to a few other things that may be useful.

This is not a Python is better than Java thing. Instead of bashing aspects of Java's language and library that are obviously valued by the Java community, or insulting the intelligence of Java coders, or using any number of other techniques you might find in Every Language War Ever, Phillip is simply asking Java programmers who may be dabbling in Python to take a closer look at some of the features that make Python unique and attractive instead of attempting to force-fit concepts from Java. If you base your expectations of Python on Java concepts, you are likely going to have a bad experience with Python.

Continue on for the first part of the series, which talks about some of the differences between Python class methods / class variables and Java static methods / static variables.

I've had a few conversations recently where someone expressed interest in GNU/Linux and asked about getting involved. I really wanted to suggest that they consider joining the Fedora project but I couldn't do that comfortably because, well, there are some pretty massive issues.

So I'm really excited to see that Redhat is finally getting around to really supporting the excellent volunteer community that has dedicated themselves to making Fedora, and by extension Redhat's commercial offerings, excellent distributions. Herewith some recent news that led to this post...

Some days the Powerbook gets more attention than the wife and so she snoops over my shoulder and starts asking a bunch of questions about whatever is on the screen. She doesn't really care, this is just the cue to shift my attention over to her. I usually do just that and say something like, Oh, this is some interesting stuff but nothing you would care about.

But on this day I decided that I would play along a bit and see how far I could take her into my world before she ran away screaming in terror.

I was searching for a specific piece of Dive into Python when I ran into this classic from diveintomark.org:

Tom: "This is really good. You could probably make some money off this someday."
Mark: "Maybe, but I'm not going to. I'm giving it away for free."
Tom: "Why would you do that?"
Mark: "Because this is the way I want the world to work."
Tom: "But the world doesn't work that way."
Mark: "Mine does."

I had to pour out a little liquor for my homies.

This is the second post in response to cross-breading ZPT and XSLT. I'd like to dig into how I'd like templating to work in Kid and Leslie opens the door for me:

... maybe this is the sort of thing Ryan's thinking about-- I wonder how hard it would be to hack this into Kid? It would give only a subset of XSLT's capabilities in trade for simplicity, and would only offer the pull approach, but it would give XML-pipelining to a ZPT-ish technology.

Leslie de 0xDECAFBAD talks a bit about cross-breading ZPT and XSLT and mentions Kid along the way. This is the first in a series of response posts.

In Weapons and Coding, I made a prediction:

The first environment [Java / .NET] to successful mesh static and dynamic languages into a coherent platform will win the interpreted byte-code market.

Tim Bray must have come to a similar conclusion because he recently organized a meeting of the minds at Sun to talk about Dynamic Java. Here's a great pic of the BDFL and Larry Wall Tim shot right before they pulled out their katana's to settle the Python vs. Perl debate like gentlemen.

In my mind, Tim is moving into this small classification of people labeled, Hero. His past work on XML (as in, his name is on the Recommendation), recent work on Atom, declaration of The Loyal WS-Opposition, contributions through W3C TAG on the excellent Architecture of the World Wide Web, and now this seemingly unrelated initiative to get Sun to wake up about dynamic languages puts Tim on the right side of almost every major area of innovation I'm interested in. Go Tim, go!

I really hope this leads to some serious discussion on how we can bring static and dynamic languages together into a single cohesive platform. Drop the MFL is better than YFL talk found in Every Language War Ever. We need to start having these types conversations: MFL is a compliment to YFL. This is happening only in very small pockets right now and until today, they were pockets without a lot of potential for real impact.

So this is pretty crazy. I'm messing around with ElementTree (which has been nothing less than perfect) and trying to get it to act like a xml.dom.pulldom/XmlTextReader style pull-parser. But I'd like to be able to assemble a chain of generator producing/consuming functions (or other callable) so that the file can be read, parsed, filtered/mutated, encoded, and written all incrementally.

Check it out:

import sys
import pulltree    # that's what I'm working on :)

def upper_filter(source):
    for (ev, item) in source:
        if ev == pulltree.CHARACTERS:
            item = item.upper()
        yield (ev, item)

reader = pulltree.reader(sys.stdin)
filter = upper_filter(reader)
writer = pulltree.writer(filter, sys.stdout)

for (ev, item) in writer:
    pass

C-z

$ echo "<hello>world</hello>" | python test_filter.py 
<hello>WORLD</hello>

That felt good. More functional than a chain of SAX XMLFilters, almost as efficient, and muuuuch perdier.

Something like this might work someday soon:

import urllib2
from pulltree

XINCLUDE = '{http://www.w3.org/2001/XInclude}include'

def xinclude_filter(source):
    events = iter(source)
    for (event, item) in events:
        if event == pulltree.START_ELEMENT and elm.tag == XINCLUDE:
           href = item.attrib['href']
           for woot in pulltree.reader(urllib2.urlopen(href))
               yield woot
           pulltree.eat(elm, events) # eat events to the end of the element
        yield (ev, elm)

Granted, that's as basic an XInclude processor could be and still be useful but you get the point.

I've been searching for the perfect Python based XML template language. I was happy to find TAL (and specifically, SimpleTAL) a while back but, although neither of us wants to admit it, we've been growing apart for some time now. I spent last week looking for options and, after careful consideration and planning (read: beer and a nap), decided to just build the XML template language I really wanted.

There's at least four billion and nine text based template languages for Python but there aren't a lot of options that fit nicely into the XML tool-chain. Or, if they do fit nicely into the XML tool-chain, they don't fit nicely with Python.

My dreamboat XML template language would combine the pythonicness and simplicity of PTL, the templating features and pipeline-ability of XSLT, and the terseness of Zope's TAL. I'm building it, it's called Kid, and I'm making good progress to be honest.

But I have this overwhelming NIH feeling so I've decided the best thing to do is to run through the current set of tools and take a professional, objective look at why each isn't getting it done for me (i.e. make fun of minor flaws and limitations until I feel better about myself). Herewith, a look at the good and the bad in the Python XML templating space...