How Not to Use XML

One aspect of my job is to work with 3rd parties to include commerce links to buy stuff from our site(s). This involves the 3rd party giving us a data feed of products which we take and try to match up with products in our own database. Sometimes the feeds will be a delimited text file. Sometimes they're be XML. Here's a small sample of some XML I recently had the pleasure of working with. The actual element names and data have been changed to protect the guilty party.

<Thing>
 <stuff name="product_id">0926INGBS10075810</stuff>
 <stuff name="company">Curabitur Fringilla Corp.</stuff>
 <stuff name="title">Nullam Enim Justo (PC/Mac)</stuff>
 <stuff name="Price">24.99</stuff>
 <stuff name="Availability">See Site</stuff>
 <stuff name="upc">0600100098554</stuff>
 <stuff name="description">Lorem ipsum dolor sit amet</stuff>
 <stuff name="boxshot">http://www.blah.com/product.gif</stuff>
 <stuff name="purchase_url">http://www.blah.com/buy.asp?id=0123456789</stuff>
</Thing>

At this point why not just provide the data in a delimited text format? Everything having the same element name and using attributes to identify different fields actually makes the parsing of the feed *more* difficult and error prone.

It seems to me someone at this company said, "XML is what all the cool kids use. Our feed needs to be in XML. Then we'll be one of the cool kids too." Then someone who doesn't really understand what XML was intended to accomplish put this together.

Would it have been so hard to do this instead?

<thing>
 <product_id>0926INGBS10075810</product_id>
 <company>Curabitur Fringilla Corp.</company>
 <title>Nullam Enim Justo (PC/Mac)</title>
 <price>24.99</price>
 <availability>See Site</availability>
 <upc>0600100098554</upc>
 <description>Lorem ipsum dolor sit amet.</description>
 <boxshot>http://www.blah.com/product.gif</boxshot>
 <purchase_url>http://www.blah.com/buy.asp?id=0123456789</purchase_url>
</thing>

What "Coding Tank" Means To Me

I've been wanting to write about my chosen profession of software development for a long time and have been patiently for the right context to present itself to me. I think I've finally found it. I should probably explain the title of the blog though.

I play World of Warcraft in my free time and one of the roles you can take on is that of the "tank". The tank is responsible to facing off against the big bad monster and taking any punishment it has to dish out. If you're doing your job well as a tank you're the sole object of the monster's aggression leaving your other party members free to do their thing. You're the one who is first to engage with the scariest bosses. If you're fighting multiple enemies then you may have to frequently switch targets to ensure you're taking all the aggression and no monsters are beating on any of your squishier group members.

My programming life has felt a bit like this recently. The analogy breaks down at some point but essentially I have been a coding tank for a while. I'm the guy people first come to with the toughest problems. I'm first to dive into the least understood parts of our code to figure out why a particular behavior occurs. When emergencies happen I'm the first responder. It doesn't matter if there's three or four fires all going on at once. I'm battling all four of them. I take care of all the annoying and undesirable crap so others can work relatively unhindered.

This is not to boast. Far from it. I'd rather not be the tank. I'd much rather be one of those who can just sit down and work on something and not get interrupted every 15 minutes with a fresh crisis. I suppose something in my personality and work ethic has led me to this role even though I have mixed feelings about it.

Anyway, we're slightly off-topic now and I think that's about enough for a first post.