An important part of working with jQuery is to create plugins to simplify repetitive tasks. I write jQuery plugins all the time for internal consumption of my applications.

Most of them are not of enough general purpose to be shared publicly. Recently I created one that could stand on its own and I chose to make it available if anyone is interested.

Multiple Element Ajax Updates

jQuery SuperLoad came out of the necessity to update more than one element in a page without needing to do everything with JavaScript (and you know I'm not the one that avoids JavaScript).

All of the page elements I needed to update with Ajax came from page segments (partials, user controls, etc) that I had available on my server side. It seemed appropriate to go back to the server to get updated versions of that same HTML. But I didn't want to issue a separate $.ajax() or $(elem).load for each one of them.

Using SuperLoad I can now return something like the following from my server application and have more than one element updated.

<div class="ajax-content">
	<div title="!appendTo #content .shoppingList">
		<li>
			<img src="/images/prod12345.png" class="product-image">
			<div class="prodSummary">
				<div class="prodTitle">ACME Product</div>
				<div class="prodPrice">$12.34</div>
			</div>
		</li>
	</div>
	<div title="!update #orderTotal">
		Total: <span class="totalPrice">$47.22</span>
		<div class="specialOffer">Eligible for free shipping!</div>
	</div>
	<script>
		$('#orderTotal specialOffer').effect('highlight');
	</script>
</div>

All that is needed for this to be correctly applied to the right elements (selected by "#content .shoppingList" and "#orderTotal" is a line of code similar to this example.

$.superLoad({ 
	url: '/shopping/addItem', 
	type: 'POST', 
	data: {product: 12345} 
});

Check the plugin source code comments or the github repository page for more details.

One of these days I was chatting with Derik and we were talking about refactoring and when to stop refactoring. We thought it was funny (and embarrassing) how sometimes, after a few consecutive refactorings, we are back at the starting point.

This type of Circular Refactoring is a real productivity enemy. In our genuine desire to improve the code, and wishing to dive into an interesting task, we sometimes lose sight of the code history and the real need for this change. It reminds me a lot of this funny comment (second part).

How do you tell when you're being a victim of this variation of the premature optimization monster? Well, here's a start:

Top 10 signs you've fallen into circular refactoring

It was my turn to be interviewed by Dave and Larry for The Thirsty Developer podcast.

We talked a lot about all things JavaScript, its status, how people learn it (or avoid it), etc. I hope it's an entertaining interview

You can download the interview from the podcast page

In the spirit of helping the next guy, here's some explanation for a problem that was surprising to me.

We have recently upgraded our product to 64-bits and all developer workstations to Windows 2008 x64. The transition was easy and most things worked with minor or no tweak at all. We're still battling a TFS issue but that will be the subject for another day, once we figure it out.

I noticed that a bunch of my unit test cases were failing when I ran them using Resharper's test runner. I traced the problem down to missing registry values that were needed by the tests. The intriguing part was that I could see the registry settings there (see image below) and the tests were working fine using NUnit's GUI runner.

After a little poking around, I saw this in Process Explorer:

Hmmm. Visual Studio and Resharper run as 32-bit processes and NUnit's (and my application itself) as 64-bit ones. Could there be a difference between Registry access for 32-bit vs. 64-bit processes? Yessir. It turns out that my settings were in the right place but Windows was redirecting the 32-bit Registry accesses to the path shown below, which is obviously empty.

I don't know of any elegant work-around for this issue but for now I'm simply duplicating the values in both places for the sake of testing. I'm not happy with this duplication but it's got me back on track until someone bright chimes in with a better alternative.

I finally got around to properly record and publish one of those JavaScript presentations that I have been doing at local users groups. The video and the slide deck are available below.

The video

And the slide deck.

If you prefer, you can download the slide deck.