Too Clever By Half – In Support Of Paired Programming
If you’re like me – a developer who is sometimes too clever by half – you’ll relate to this story.
I just made some changes to a Javascript file in a static resource and when I deployed this from dev to our QA environment, I couldn’t see the fix. After confirming the file did in fact update by checking its metadata I did a hard cache refresh and…I still couldn’t see my changes.
This went on for a while, and I deliberately explained every step to my rubber ducky. Each time, I could see the static resource was updating in the Salesforce environment but I wasn’t able to see my changes when I accessed the page.
This drove me nuts. I hadn’t seen this issue before, and before long I started requesting sanity checks from my coworkers.
“Am I going crazy and missing something, or do we have gremlins in here?”
They were as confused as I was, and none of this really made much sense until I pulled up Chrome Developer Tools and started poking around. I found the static resource embed url to be /resource/1489145680000/mfc_PageSupport/prod/js/mfc-prod.js. That number is significant as a Unix Timestamp, with an extra three 0’s on the end. By using an online tool (and removing the three extra 0’s), I was able to convert the Unix timestamp to a human date.
As it turns out, the static resource the webpage is embedding was last modified on: Fri, 10 Mar 2017 11:34:40 GMT.
This demonstrated we’ve got a caching issue with the static resource (and a secondary benefit is that my sanity was confirmed!)
Now to see what’s going on with the caching issue I dove into the code and found something kinda peculiar:
public static String getResourceURL(String resourceName) {
// Fetching the resource
List<StaticResource> resourceList= [SELECT Name, NamespacePrefix, SystemModStamp FROM StaticResource WHERE Name = :resourceName];
// Checking if the result is returned or not
if(resourceList.size() == 1){
String namespace = resourceList[0].NamespacePrefix;
return Site.getPathPrefix() + '/resource/' + resourceList[0].SystemModStamp.getTime() + '/' + (namespace != null && namespace != '' ? namespace + '__' : '') + resourceName;
}
return '';
}
I’m sure you’re familiar with the expression “too clever by half” – this is a perfect example of the need for such a phrase. I had to laugh when I saw this is how static resources were being embedded in numerous places throughout the project as I’ve done numerous things like this throughout my career when a much simpler solution exists.
I’m aware of all the arguments both for and against Paired Programming, but his example is why I’m a firm supporter of the practice. As developers, we take big problems and break them down into a series of small problems and tackle them one at a time. However, it’s easy to get carried away by breaking things down too far and ultimately reinventing the wheel. It’s common for one developer to write something a little too verbose, but between a pair of developers there’s a much greater chance the team will create better code.
As I refactor an entire project to call a much simple URLFOR($Resource.ResourceName) method to embed static resources, I’m wondering about how prevalent Paired Programming is in the industry. Share your thoughts in the comments below, and if you have similar stories I’d love to hear those too!