Google Trends a useful tool

Quick post today about google trends. For those of you that don’t know google offers a really useful tool that allows you to see search trend data from all the way back to 2004 (or earlier?). trends.google.com This really has a broad range of useful applications. For example, take the current economic situation. How does it compare to years past? Just an exaggeration? Lets do a search for ‘jobs’:
Jobs
So based on searches, jobs are in fact a little higher in demand this year. However it is interesting to note the drastic increase in news coverage. Another very useful and obvious observation is the seasonal nature of job searches.

Another interesting search is ‘hho’. HHO is a term coined by the alternative energy community for basically splitting water into hydrogen through electrolysis and piping the dihydrogen oxgen directly into the engine. So at the peak of the gas price madness this summer, this movement to equip hho systems to cars was really gaining ground. I have to admit I have been intrigued by this idea. It appears to produce real gains in mileage and well documented on videos all over the net. The merits of HHO are for another post however. Interestingly gas prices started to inch back down in late summer. Coincidentally so did the interest in hho. What does this say to the alternative engery movement in general if gas prices remain low? As prices rise again in summer will HHO interest rise again?
hho

Finally, I will lead into my upcoming post with the term ‘Web 2.0’. The media coined name for the next logical evolution of what the internet is and does. The term means a lot from design aspects to social networking. So as you can see the Web 2.0 searches peaked out in Q1 of 2007 and is in a steady decline. What does this mean for web 2.0. While I honestly don’t believe we are witnessing the demise of web 2.0. I think what are seeing is the movement to the next evolution of the web. Web 2.0 is here to stay I believe and the internet is permanently changed for the better because of it. What is next you ask? I honestly don’t know. I think in 2009 it will show itself.

Web 2.0

Slow javascript performance in IE (string concatenation)

I’ve come to realize while IE 7 is no less than a landslide improvement over IE 6, it is still IE. While IE alone in the market appeared to be a superior product, compared to the likes of firefox it is simply inferior. Firefox script interpreter is all around faster, in my experience it is not just 2-5x faster, it can be 100x for some operations. Crazy right? I’ve been pushing the envelope with an ajax/dojo based site I’ve spent a large amount of time on. To be blunt there is more than one occasion during the development process I have had to rewrite code to accomadate the script execution of IE 7. Looking back most of the time the script was poorly thought out set of operations that needed to be rewritten anyway.

My last road block however was a particular chunk of JSON data that was packaged up base64 encoded then sent off to the server via the dojo xhrpost method. I really was scratching my head whenever I was in IE and got up to a 3-10 second delay while sending this data to the server. While in Firefox and Safari there was none. After a period of a few hours I narrowed the delay to my base64 encoding script running on the client side causing the delay. It didn’t take long start finding that IE is incredibly inefficient as string concatenation. The solution is simple.  Implement a string buffer.  I have provided some snippets along with the corrected JS file for viewing.

// addresses some speed issues with IE 
function StringBuffer()
{
this.buffer = [];
}
 
StringBuffer.prototype.append = function append(string) {
this.buffer.push(string);
return this;
};
 
StringBuffer.prototype.toString = function toString() {
return this.buffer.join("");
};
 
// end buffer
 
function encodeBase64(str){
 
...
 
var buf = new StringBuffer(); // new buffer code
 
...
 
//result += (base64Chars [(( inBuffer[0] << 4 ) & 0x30) | (inBuffer[1] >> 4) ]);
 
buf.append(base64Chars [(( inBuffer[0] << 4 ) & 0x30) | (inBuffer[1] >> 4) ]);
 
...
 
}

Source for the entire base64 file here:
base64.js

Diagnose ‘File does not exist’ error in ASP.net

I have ventured deep into the land of asp.net the past few months.  Luckily the the blogsphere keeps me on track.  Every day or so I run into a nagging issue with asp.net or something I can’t quite accomplish.  I have been nearing the end of my project and have simply had a bug which I could not fix.  It seems asp.net will fire an error when ANY file is missing on an asp.net webpage.  This is incredibly difficult to diagnose since the error does not contain the file that is missing!  See below for an example

MESSAGE: File does not exist.
SOURCE: System.Web
FORM:
QUERYSTRING: 695777780
TARGETSITE: Void ProcessRequestInternal(System.Web.HttpContext)
STACKTRACE: at System.Web.StaticFileHandler.ProcessRequestInternal(HttpContext context)…

Catching the error is accomplished by hooking into the Application_Error event typically in the global.asax

void application_Error(object sender, EventArgs e)
{

}

K# offered a great post on just how he went about solving this issue. Basically setting a breakpoint at the above section of code to see the error when it happens. That isn’t quite enough, you’ll notice visually studio even in the watched variables has nothing that leads to the missing file. If you add a watch to ((HttpApplication)sender).Context.Request you will quickly see the exact file causing the error message.

My ultimate solution was to add the ((HttpApplication)sender).Context.Request.FilePath in all my global error logging so the file that is missing is always included in the error message.