Links

pmuellr is Patrick Mueller

other pmuellr thangs: home page, twitter, flickr, github

Monday, September 25, 2006

my evil twin rick

I just happened upon the blog of my old colleague and friend Rick DeNatale. I was quite fortunate in the early nineties to have Rick in my department when I was really learning Smalltalk. He's a great teacher. And he has a lot of funny stories from the old days. Ask him about rainbow colored punch card decks, or changing the value of 2 in fortran some day.

He's now off playing with Ruby, and I plan on soaking up everything he says about it ... especially since I come to it, like him, with a Smalltalk background.

BTW, I refer to him as my evil twin since we are physically similar in appearance; many people used to confuse us back in the day, and I still run into people at IBM who refer to me as "Rick".

creative commons fears

Like Mark Pilgrim and Tim Bray, I've had my share of qualms regarding Creative Commons licensing. Alex Bosworth posted on this a while back also.

Yeah, I wouldn't be happy if someone used some of my CC-licensed 'art' (quoted, due to the dubious-ness of calling what I do 'art') in a way I wasn't happy about. But I could deal with it. My biggest issue is if someone used some art which identified me, or even worse, other folks, in a way I, or the person identified, wasn't happy about. For me, that means photos.

For a while I dealt with this by only making photos that didn't include people 'public' on my flickr site. Photos with people were marked 'friends' and 'family', meaning only people I identified as friends and family could look at. Which, for those folks, means, getting a flickr id. That's not a huge hurdle for the folks likely to be reading this blog entry. It is a hurdle for a large percentage of my friends and family. After dealing with the 3rd or 4th person that couldn't see the pictures because they: 1) couldn't figure out how to create an id (even if I invited them), 2) didn't want another id to manage (who can blame them), or 3) couldn't remember their id they previously created, and wanted me to help them get it back; I finally said "screw it", and started making some of those photos public also.

That was a line for me to cross.

And then I got a note the other day, from a commercial outfit, wanting to use a picture of mine from flickr in some kind of product they were producing. A chill went up my spine. Ut oh, which picture might that be? On the other hand, I immediately thought "hey, that was nice that they bothered to ask." (Note they are supposed to, since the photo is licensed as by-nc-sa.)

Here's the picture they want to use:

I had to laugh. My wife told me to keep the day job.

In the end, at least for me, I think the CC fears are largely exaggerated. It's highly unlikely many people will want to re-use my art. And those that do will probably do the right thing.

To that end, I've also been trying to be a good citizen. I enjoy including art work in my blog posts to make it slightly more entertaining. You can see from some of my previous posts that I've included CC-licensed photos; I've used photos that aren't licensed as "non-commercial" (is my blog commercial? it's primary home is at an ibm.com site, so I'll say "yes" to that); and I've linked to the original photo site. If someone asks me to remove a picture, I surely will, despite the fact that given the license, I think it's fair for me to use it. And it's fun to just push the envelope on the issue in general anyway.

Sunday, September 24, 2006

Just Say No to XML - more often

In Just Say No to XML, Allen Holub writes "XML is perhaps the worst programming language ever conceived." What's he's talking about here are all the tools which use XML as a programming language. My only direct experience with this is with Ant. Within Eclipse. Because it's the easiest easy way to do 'scripting' with Eclipse. You know it's there, it's shipped with the base Eclipse. And I'll just say that, in general, I'm in agreement with Allen; I've written a shed-load of Ant scripts over the years, and I'd rather not have to be dealing with XML here.

Titanic cake

But I'd like to go even further! Allen follows up his 'worst' sentence (quoted above), with this: "I'm not talking about XML as a data-description language, which was its original design." If we're going to start thinking about not using XML for programming languages, let's also consider not using it for data-description as well. Why? Because XML isn't designed for data. XML is designed for documents.

And there's the problem. Documents. Programmers know how to design data. They don't know how to design documents. I think this is probably one of the biggest problems with the ws-* flavored web services; you need to design documents. To design an XML document, you need to know XML Schema. I know exactly one human who claims to be able to write XML schema off the top of their head, with no multi-hundred page reference document open. That's not good.

Sure, there are ways around having to learn schema, kind of. There's RELAX NG. But it's not widely supported in a least the places I program, and look at that last updated date on the page I just linked to. Kinda scary.

There's design tools, like UML-based stuff, but that adds layers of cake; now I have additional tooling I have to learn, there's code-gen in play so I have to watch for getting things synchronized, etc.

But let's pretend for a minute like there was an easy and standard way to design documents, and that programmers actually knew how to design documents.

Now you got the problem that there isn't really a simple way to go from documents to data. You might want to design your documents to be 'easy to parse' (eg self-descriptive), but that's likely going to violate some of the things you want in your document design, like readability. You'll probably end up using some coolio XML-to-data framework in your own code. However, some folks aren't going to have access to whatever coolio document-parsing-to-data system you're using, since most of these frameworks are single language stories, and your XML may be read by nearly any programming language known to man. In the end, some folks are going to have to use a DOM-based parser, or *gulp* SAX-based parser, to read your data. And that's simply no fun.

What's the alternative? Whatever is appropriate.

Java .properties files / windows .ini files are a really simple format for storing really simple data; too simple in most cases, but not all. Use these wherever you can get away with them.

YAML is kinda like .properties files on steroids.

JSON is the latest contender here, and is an appropriate format to use if you're expecting some JavaScript code to be handling your data, since you can use eval() to deserialize a JSON string into objects. IFF you can trust the source that gave you the JSON, anyway (that's a pretty big If, BTW; there are JSON parsers in JavaScript you can use if you can't trust your source).

Upon first really looking into JSON, I was struck by the similiarity in function that SDO provides. SDO provides a lot more than what what JSON provides, but at it's core, there's some definite similiarities. That seems good.

The point is, XML is unavoidable to programmers these days. It's everywhere. Just don't assume it's the best answer to your problem, just because everyone else is using it. There might be a better answer.


Photo "Titanic cake", with a nice CC license, by psb_minimal. Found using the Create Commons Search Site.