Weird Javascript and AJAX errors

I recently implemented some JavaScript logging on one of the web sites that I work on. Something like this: Using XMLHttpRequest to log JavaScript errors. It is working well and helping me uncover errors in my code, but many of the remaining errors that I see make little or no sense. Here is a list of some of the oddities that I have seen, that have been unable to reproduce in my development environment since that are so rare and sporadic:

1. There are times that certain JavaScript functions and variables cannot be found. Many of these are defined in external JavaScript files. In the case of Firefox I see errors when an external file fails to load for some reason. Internet Explorer give no such indication, but I have to assume that the same thing is happening. The Firefox errors do not give any details as to why the file failed to download.
   
2. Sometimes the server side logging gets blank errors. So somehow my logging page gets hit with no data, this shouldn't be happening.
3. The most frequent AJAX error is when making an AJAX call, the data returned is incomplete. I know that the readyState property is set to 4 and the status is 200, but looking at the actual length of the data (from the Content-length in the header) and comparing it to the length of the data in responseText, some data is missing. Sometimes it is almost the right size but many times it is only a fraction of the expected size. This is even after taking into account the fact that the data is UTF-8 encoded. The data size can be anywhere from 20 to 30KB, so I have wondered if the amount of data may be a contributing factor.
   
4. The other AJAX error is non-standard status codes. With FireFox I see responses of 0, and Internet Explorer I see the infamous 12000 error codes like 12019 12029 12030 and others.

So far here is what I have done to reasearch and or resolve these issues:

1. I haven't found anything definitive to help when files fail to load, but I am going to enable gzip compression for javascript files on IIS 7 to see if it might be to due to slow connections timing out. Hopefully the smaller file size will help these requests succeed more often, but this is not a complete solution. I expect to continue to see this problem.
   
2. This one has me stumped. The JavaScript logging code should always be passing an error message, with the error data, even the JavaScript error handling has no content. I have no idea why these would come back blank. Maybe the request is timing out, or I have an issue with the server side logging code not waiting until all of the data is ready.
   
3. I haven't had much luck with this one either. So far I have added some retry code, so if I get a failure, I just try again. This appears to work about 75% of the time, but I currently limit it to 1 retry, so I still see some failures. This also seems like a less than ideal solution, but maybe it is the best I can do.
   
4. Same as number 3, I just try the request again, and is succeeds about 75% of the time. The requests are over HTTPS and some information I've found indicate that this might be a problem with Internet Explorer trying to reuse connections and failing, but I have not tried adding the Connection: Close header yet.
   

These all seem very odd to me. Most of them occur on both Firefox and Internet Explorer 6, 7, and 8, but very infrequently in almost all cases, but each case still represents someone that will probably have a poor customer experience on the web site. I have to assume that errors like this are pretty common on other sites, but how many people have JavaScript logging set up that would even notice them.

C# vs. C programming

For quite a few years now I've been working primarily with C# and Microsoft .NET, and I have to admit that even with it's shortcomings I would list them as my preferred programming language and development framework. I will admit that there are still cases where C and C++ are better/faster/etc., but overall I find that when I use C# I'm more productive, my code has fewer errors, and it is easier to maintain.

At my current job I get to work in both worlds. Most of the newer software we write is in C#, but we still have a pretty expansive set of libraries and applications that are in C++, we even have one that is in managed C++ (which has it's own set of problems). I always prefer working on the C# side of things, and even dread working with some of our C++ applications.

I know that for most people this is an almost religious topic, and I don't want to come across as a zealot, I just have my preferences. I've used C++ quite extensively and it is a great language, but C# builds on the long history of C and C++ and adds more than a few nice features. And since it is built on a decent framework (.NET) there is a greater consistency to code. When you change jobs in a c++ environment, you probably have to learn a new set of frameworks. Some companies use in house libraries, some use boost, and others use something else. With C# most of the basic framework pieces come built in. There will always be a need for other frameworks beyond that, but .NET comes with most of the necessities.

There are many other features and helpful things that come with C# and .NET, but my overall view is that when I use them, I am more productive overall, and that is money in the bank to me.

Agile Software Development

There are many different software development methodologies that are practiced today. One of the popular choices today is Agile Software Development. When I do software development I generally use agile techniques, but I wouldn't consider myself an agile purist. Where I work, we use scrum meetings, and very quick development cycles, and a few other agile ideas. But we don't use every agile technique.

I assume most people and businesses do this, but I try to be familiar with many different methodologies and practices as possible. I try to use the ideas and techniques that best fit the situation at hand. If I'm doing a large scale project, I try to do more work gathering requirements upfront, but if the project is much smaller I may just sit down with the project owner for a quick discussion and start designing and implementing from that.

I know some people are much more religious about this, and the idea of mixing and matching between different methodologies would be heresy, but it really does work. There are times that it is good to be strict and keep with consistent policies and procedures, but there seem to be many more occasions where flexibility is king. Within certain constraints and with a good understanding of software development, it can be very advantageous to be flexible. In days with tight schedules, limited resources, and never ending requirements we must do what we can to thrive and create great software.

Death to Internet Explorer 6

I personally think that Internet Explorer 6 should be outlawed. Web development can be difficult enough to make things look good and work right, that throwing Internet Explorer 6.0 into the mix just makes things that much harder. Even when I'm doing ASP .NET development, you would think that everything would work well with IE 6, but that is not the case.

I spend most of my time using Firefox to test my sites, then do some quick checks in either IE 7 or IE 8, depending on what is installed on the computer, and in most cases things look and work pretty well. Sometimes there may be a few tweaks necessary to get things just right. After that I have to spin up a virtual machine, or find an old computer with IE 6 on it. And that is where the fun begins.

Web page layouts never quite look right, IE 6 never really seems to do what you've told it to. It selectively ignores CSS and re-sizes things how it wants. The internet is abound with IE 6 CSS hacks. Functionality seems to have just as many problems. Basic JavaScript is hit or miss, it might work just fine, or it might decide to be your worst enemy. Anything more complex like AJAX is almost a lost cause. You might as well develop and maintain two separate websites: one for real web browsers and another for IE 6.

Maybe I'm being a little hard on the browser, but it really is a web developers worst nightmare. If there were only a few computers out there that still had IE 6, that would be one thing. But there is still a large portion of computers that run IE 6 as their primary browser. I defintely favor Firefox, but I don't mind if people want to use IE 7 or IE 8, just not IE 6. We should all wish it a fond farewell, and retire the old chap already.

.NET Code Coverage

I've been looking for a good, free code coverage tool for .NET for quite a while. I know that years ago NCover used to be pretty good, but the open source version appears to be dead, replaced by a commercial version. The old version still exists and works, but it's pretty outdated. Recently I've found PartCover but haven't had a chance to thoroughly try it out. Beyond that, I haven't been able able to find anything else that is open source or even free. But neither of these two solutions appear to have lots of active development going on, which I consider a pretty important metric when looking at adopting an open source tool or framework.

It seems surprising that their isn't more activity in the open source world in this area. There seems to be many other active communities in the open source world about C# and .NET. There are many projects like NUnit and NHibernate that are actively developed and extremely helpful. But there doesn't seem to be much open source activity about code coverage. Is this because people find that the commercial options available work well at a reasonable price? Or do people just not put much importance on code coverage?

I think that code coverage receives less attention than many other software development practices like unit testing, but it still seems like it would get more focus that it currently does. I hope that there is a code coverage tool out there that I just can't find, but I'm not holding my breath.