…if it hasn’t solved your problem yet, you’re not using enough. Curiously, I always thought of that little quip as a subtle indictment of the problems with XML, but it seems to almost be a rallying cry for proponents of the standard (I refuse to recognize XML as a “language”).  And when I say proponents, I actually mean “fanatics.”

The problem I have with XML, my “beef” if you will, is certainly not XML’s fault; it’s the fault of the overzealous developer who wants to use XML as a way to transmit pixel data over the network.  If you look at that post and your first thought is something like:

Well, duh, of course that’s the wrong way to do it, I’d use something like:

<signature>
	<pixel x="127" y="90" />
	<pixel x="128" y="91" />
	<!-- ... -->
</signature>

Well, you’re probably already too far gone; this post isn’t for you.

Of course, you still have to send your data somehow, and since raw bytestreams are out this fall, why not look into an alternative format? May I recommend some JSON?  Let’s take a look at a simple and realistic (ish) case of JSON -vs- XML: representing an order in a format that a person and a computer can read.

For this experiment, I will be placing order number 233 on behalf of customer number 971.  Said customer would like 2 each of item number 2751 and item number 1765, “beef brats” and “brat buns” respectively.  Said customer would also like the buns warmed but not toasted, and the brats to be of the “Beer Basted” variety, but not filled with cheese.  Here we go.

JSON:

var order = {
	orderId: 233,
	customerId: 971,
	items: [
		{
			itemId: 2751,
			name: "Beef Brats",
			quantity: 2,
			options: [
				{
					name: "beerbasted",
					value: true
				},
				{
					name: "cheesefilled",
					value: false
				}
			]
		},
		{
			itemId: 1765,
			name: "Brat Buns",
			quanity: 2,
			options: [
				{
					name: "warmed",
					value: true
				},
				{
					name: "toasted",
					value: false
				}
			]
		}
	]
};

EDIT: I noticed the objects weren’t exactly semantically similar; I fixed this because fair’s fair (and it only increases the size of the JSON by about 20 bytes, whereas the equivalent XML correction might have taken triple that

Versus the contender, XML:

<?xml version="1.0" encoding="UTF-8"?>
<order>
	<id>233</id>
	<customerId>971</customerId>
	<item>
		<id>2751</id>
		<name>beef brats</name>
		<quantity>2</quantity>
		<option>
			<name>beer basted</name>
			<value>true</value>
		</option>
		<option>
			<name>cheese filled</name>
			<value>false</value>
		</option>
	</item>
	<item>
		<id>1765</id>
		<name>brat buns</name>
		<quantity>2</quantity>
		<option>
			<name>warmed</name>
			<value>true</value>
		</option>
		<option>
			<name>toasted</name>
			<value>false</value>
		</option>
	</item>
</order>

Now, XML proponents likely will not take this one lying down. They’ll look at that document and accuse me of being the worst, most evil, vile, baby-eating slanderer ever to take a crack at their beloved XML. After all, one could just as easily use documents with more concise structure, something that doesn’t just look so gigantic, like one of these:

<?xml version="1.0" encoding="UTF-8"?>
<order id="233">
	<customer id="971" />
	<item id="2751">
		<name>beef brats</name>
		<quantity>2</quantity>
		<option name="beerbasted">true</option>
		<option name="cheesefilled">false</option>
	</item>
	<item id="1765">
		<name>brat buns</name>
		<quantity>2</quantity>
		<option name="warmed">true</option>
		<option name="toasted">false</option>
	</item>
</order>

<?xml version="1.0" encoding="UTF-8"?>
<order id="233" customerid="971">
	<item id="2751" name="beef brats" quantity="2">
		<option name="beerbasted" value="true" />
		<option name="cheesefilled" value="false" />
	</item>
	<item id="1765" name="brat buns" quantity="2">
		<option name="warmed" value="true" />
		<option name="toasted" value="false" />
	</item>
</order>

<?xml version="1.0" encoding="UTF-8"?>
<order id="233" customerid="971">
	<item id="2751" name="beef brats" quantity="2" beerbasted="true" cheesefilled="false" />
	<item id="1765" name="brat buns" quantity="2" warmed="true" toasted="false" />
</order>

The reason I don’t list these as the primary contention against JSON, even though that’s what the advocates would probably have written? Simple. Those representations don’t match, when treated as a representation of an object, the order I started out with. They are close, yes, and they convey the same information, but the syntax is entirely different, and therefore the parsing is not only more complex, especially when it comes to converting the XML back into an objectm, not to mention that you start to lose the “human readable”-ness of the document by trying to cram it into less and less space.

Furthermore, with JSON, exporting objects, arrays, or both, is extremely easy to do — in PHP, for instance, it’s actually native since version 5.2, and json.org has plenty of easy-to-use implementations in most languages in common use.

In order to arrive at the XML I chose as a contender, I did a google search for “array to XML PHP” and checked the top result, which was a function (for some unknown reason static-inside-a-class-as-the-only-member, maybe written by a namespace-nazi?) that seemed to do a more-or-less standardized conversion. Now, again, we could argue all day about whether or not that is even a worthy implementation, but before that argument starts let me squash it by saying this: whether or not any of those syntaxes is correct or not is less important than the simple point that any and all of them are technically correct.

Semantics aside, all of those XML versions of the same “object” are valid and well-formed XML documents, and they, depending on your method of “serialization” into and out of XML, all describe the same order. And that, ladies and gentlemen, is a problem I consider to be worst of all. Which one of those is right? Is it the smallest, the one that’s most clear, the one that is most loyal to the original order object?

Because of XML’s loose specification, which is a good thing in cases where XML is appropriate, there isn’t really a consistent way to represent these objects as XML that everyone agrees on. Some people, as in the last example, would put everything into an attribute=value pair, while many automated methods for de/serialization would use almost no attributes, instead favoring raw tags.

Before this gets too far away from me, let me draw it to a close. Because of the standard’s, if you’ll pardon the sub-pun, lack of standardization, I propose we stop, for the love of all that is good and pure, using XML to represent every single object and data-fragment we come across. It’s time to let go. There are just too many ways to do it, and we’re running out of patience…

Another quick rant/post about the wonderful world of abusing javascript. Consider the following code:

function moveScreen() {
    var myWidth = 0,
    myHeight = 0;
    if (typeof(window.innerWidth) == 'number') {
        //Non-IE
        myWidth = window.innerWidth;
        myHeight = window.innerHeight;
    } else if (document.documentElement &&
		(document.documentElement.clientWidth || document.documentElement.clientHeight)) {
        //IE 6+ in 'standards compliant mode'
        myWidth = document.documentElement.clientWidth;
        myHeight = document.documentElement.clientHeight;
    } else if (document.body && (document.body.clientWidth || document.body.clientHeight)) {
        //IE 4 compatible
        myWidth = document.body.clientWidth;
        myHeight = document.body.clientHeight;
    }
 
    var marginLeft = Math.max(0, Math.floor((myWidth - 995) / 2));
    $("screen").style.marginLeft = marginLeft;
    $("sidebarElements").style.left = marginLeft + 10;
}
 
Event.observe(window, "resize",
    function() {
        moveScreen()
    });

For the love of all that is good and pure, if you ever find yourself writing something like this just calm down, take a deep breath, and remind yourself that you can accomplish the same thing by:

1. Create for your content a parent all-encompassing container div, with an id like “parentContainer”
2. In your stylesheet,

   #parentContainer {
   	width: 955px;
   	margin: 0 auto;
   }

That is all, keep on truckin’.

Two little snippets, some simple things that seem to be forgotten when writing code.  First, a general example using PHP; have you ever found yourself writing a loop that looks something like this?

$i = 0;
while ($row = mysql_fetch_assoc($result) {
	// ...
	// maybe something about $i % 2 to determine even-from-odd rows
	++$i;
}

If so, remember this: you are (effectively) building a complicated, difficult to read and easy-to-break for-loop. There is no magic law that says that all three arguments of a for-loop must be related to the same variable (heck, you may have even used a few of them with no arguments in one or more positions). Consider the following:

for ($i = 1; $row = mysql_fetch_assoc($result); ++$i) {
	// ...
	// the same code can go here
}

While the differences may seem semantic-bordering-on-syntactic-sugar at first (there is no real execution difference between for-loops and while-loops, of course), consider what differences they offer to you as a developer:

1. When looking at the for loop, you know immediately what is involved, instead of hunting for the declaration and incrementation of $i, or whatever your preferred increment-variable flavor is.
2. It saves code real-estate
3. You can easily edit the contents of the loop, as well as what contains the loop, and not worry about destroying an important variable declaration, iteration, etc.

Of course, this isn’t a serious gripe, just a nudge towards thinking outside of “traditional” declarations and using something that will be easily maintainable.

Second, remember that everything in JavaScript can be treated like an object-reference.  Of course, you’ve probably been told this before, but I want to bring up one instance in particular: functions.  If something returns a function reference, you can execute it directly, without cluttering the parser/code with unnecessary calls to things like setTimeout(). Consider the following code I have been running into a lot recently (using Prototype 1.6):

setTimeout(someFunction.bind(window),10);

While this will certainly do what you want, the call to setTimeout() is superfluous, and serves only to confound the matter. Since it is an object reference, you may use function notation to execute it like any other function object, such as:

someFunction.bind(window)();

Not only is it more concise, but when you look at it you know exactly what you’re doing with it.

Remember, while avoiding cleverness for cleverness’ sake, it is important to use your brain while programming. Strive for elegance and keep on truckin’.

Hey there kids! Put your walk-mans down and listen up! Let’s “rap” for a second about nerds. Nerds, the social stragglers that make your stuff go just so you won’t beat them. Nerds, the… Actually, I’m sick of this already. I was browsing Graphjam today, and I ran across this:

I, like many, thought it was cute.  I even posted it on a certain social networking site that sounds like “Chase Crook.”  Then, I made the mistake of reading the comments, causing me to run across this gem:

“Nerds do not exist. Nerdisms are a threat to the success of society, and perpetuated by popular culture. Because of nerdisms, people subconsciously associate science, math and engineering with being ‘socially inept’ thus avoiding such unpopular fields. We are running out of scientists in the US and soon China, because of their immense quantity of engineers and scientists will become the world superpower.”

Now, without addressing the inherent Jingoism this quote, the rest of it is pretty spot-on. Maybe it’s the that’s-for-nerds factor, or maybe it’s the waah-it’s-hard factor (maybe even both), but I do tend to hear more kids my age talking about majoring in communications, business or English (to name a few) than I do in science-related fields (considering Math as the purest science, for the sake of grouping).

Of course, college major isn’t everything.  In fact, attacking a major would, by and large, be completely the wrong avenue, since there’s no accounting for (a) what you will actually do with your degree and (b) quite honestly, science isn’t for everyone.  Business, Politics, Education, and others can all be worthwhile pursuits — even entertainment is necessary to the vast bulk of society, nerd or otherwise.  This isn’t an attack on these fields, so much as question: why is it that science is almost treated with disdain?

I, for one, have no college degree, and I know there are plenty of us doing just fine without a fancy degree from a major institution saying that we can be, well, nerds.  Those of us who bear that title generally do so with pride; many of us took up the nerd banner at a young age, suffered social ostracism as children, and tinkered, and played, and stayed in figuring out just that one last problem (which of course led to the next thousand-or-so) that prepared us to move on, as adults, to bigger and better things.

I know that I can’t change society’s mind; it’s just not hip to be smart.  At this point, it’s almost a vicious cycle – in a society that engenders a distrust, or downright hatred, of smarter people when they’re children, doesn’t it stand to reason that the same children will lose out on the formation of critical social skills at a young age?  Oh, there are exceptions to this (and every) social rule, but popular culture makes sure that it stays firmly rooted as a mainstay of growing up: there’s cool kids, average kids, slime moulds, and nerds – in that order.

What’s the solution?  wish I knew.  How do you take a society like ours, with values and culture in the state they are in, and try to get it to really believe that maybe they don’t need to hate everything they don’t understand?  Well, now I am reaching too far…