Array.indexOf in Internet Explorer

According to this document at Mozilla Developer Center, Javascript 1.5 has been implemented in a browser since at least the first releases of Mozilla as open source browser, which means, in other words, since around 1998. Let's assume it was 2002 which is marked as the release of the 1.0 version.
And I was doing some interface programming lately and I needed to check if an element was in an array. Went to Gecko's documentation (that's the one I normally use, since it's less overbloated with crappy ads) and checked that Array objects had an indexOf function. Cool! I used that function on my code. Then once I finished with all the development, went to The Horror (i.e. Internet Explorer) and tested it.
Surprise! It was broken! What had I done? (You know the debugger for Internet Explorer is not specially helpful)
I suspected of the indexOf function, and recalled vague memories about doing a custom search function in the past for looking into arrays and not having to write a for(i=0; i<ar.length;i++) thing each time…
Mmmm… did a alert('Array.indexO') in ie and what did I get?: undefined
So they have been spent five years for releasing ie7 and still they didn't implement Array.indexOf!
No worries, though. Javascript is flexible! Look, IE, I don't care if you choke on the mere seeing of indexOf, you're going to run it whether you like it or not!

and voila! my script wasn't broken anymore!

Javascript Timeout Hacks

Our first user script simply displays an alert saying “Hello world!” when it is executed.

Example: Display the “Hello world!” alert

Although this code looks obvious enough, and does exactly what you would expect, Greasemonkey is actually doing a number of things behind the scenes to ensure that user scripts do not interact badly with other scripts defined by the original page. Specifically, it automatically wraps your user script in an anonymous function wrapper. Ordinarily you can ignore this, but it will eventually creep up and bite you in the ass, so you may as well learn about it now.
One of the most common ways this can bite you is that variables and functions that you define in a user script are not available to other scripts. In fact, they are not available at all once the user script has finished running. This means that you will run into problems if you are expecting to be able to call your own functions later by using the window.setTimeout function, or by setting string-based onclick attributes on links and expecting Javascript to evaluate your function names later.
For example, this user script defines a function helloworld, then attempts to set a timer to call it one second later.

Example: Bad way to delay calling a function

This will not work; no alert will be displayed. If you open JavaScript Console, you will see an exception displayed: Error: helloworld is not defined. This is because, by the time the timeout expires and the call to helloworld() is evaluated, the helloworld function no longer exists.

If you need to reference your user script's variables or functions later, you will need to explicitly define them as properties of the window object, which is always available.

Example: Better way to delay calling a function

This works as expected: one second after the page loads, an alert pops up proudly displaying “Hello world!

However, setting properties on window is still not ideal; it's a bit like using a global variable when a local one will do. (Actually, it's exactly like that, since window is global and available to all scripts on the page.) More practically, you could end up interfering with other scripts that were defined on the page, or even other user scripts.
The best solution is to define an anonymous function yourself and pass it as the first argument to window.setTimeout.

Example: Best way to delay calling a function

What I'm doing here is creating a function without a name (an “anonymous function”), then immediately passing the function itself to window.setTimeout. This accomplishes the same thing as the previous example, but it leaves no trace, i.e. it's undetectable to other scripts.
I find that I use anonymous functions regularly while writing user scripts. They are ideal for creating “one-off” functions and passing them as arguments to things like window.setTimeout, document.addEventListener, or assigning to event handlers like click or submit.

.NET Making Gains Against Java, Survey Says

by Stephen Swoyer
30 September 2008
Who's ahead: Microsoft Corp.'s .NET or Sun Microsystems Inc.'s Java Platform Enterprise Edition (Java EE)?
Five years in and counting, the battle still rages with no clear victor. However, according to a new survey, .NET appears to be widening its lead over Java EE, as the latest revision of the erstwhile Java 2 Enterprise Edition (J2EE) specification is now called. Given the volatility of the .NET/Java EE match-up, that could easily change.
Last year, for example, a survey from development consultancy Evans Data Corp. identified a clear trend in favor of Java development, even though .NET still retained a narrow lead. Thirty-one percent of developers said they planned to tap .NET as their platform of choice for SOA development; 28 percent cited Java.
Evans Data flagged a steep decline in the percentage of developers who expressed a preference for using .NET as a platform for their SOA activities, citing a 20 percent drop in just a six-month period.
This year, the reverse seems to be the case.
According to a new survey from Evans Data, .NET is once again outpacing Java. The survey, which polled 350 developers at enterprise shops with 1,000 or more employees, found that three-fifths (60 percent) of respondents indicated that their .NET investments were growing; fully half said they planned to add additional .NET development personnel.
"These survey results confirm that .NET applications are pervasive in large enterprises and their acceptance and dependability is continuing to increase," said Mike Allen, director of product management for CA Wily Technology, in a statement. CA Inc. -- which markets application performance management (APM) tooling (and which claims that the Evans Data results underscore the importance of effective APM programs) -- is a sponsor of the survey.
There might be something to CA's claims. What's surprising is how much enterprise IT organizations are spending on their next-gen application architecture investments -- particularly for .NET products. More than half of respondents said they're spending about a quarter of their IT application budgets on .NET development or support, while a staggering one-fifth of respondents say they're spending between 75 and 100 percent this way.
Also surprising is the non-partisan heterogeneity of today's enterprise application architectures. Many shops are supporting mixed .NET and Java EE deployments, Evans Data said. A clear majority of respondents said their organizations maintain both .NET and Java groups, for example.
It's a sign of the times, according to industry veteran Jasmine Noel, a principal with consultancy Ptak, Noel & Associates.
"An increasing number of enterprises are realizing the benefits of deploying applications built on both .NET and Java. However, with those benefits come the challenges of managing a heterogeneous environment coupled with the unique issues of both development architectures," Noel said in a prepared statement.
Elsewhere, .NET developers are far more likely than Java coders to blame changes -- at both the application level and in the back-end -- for slowdowns. Java users, on the other hand, disproportionately cite memory leaks and out-of-memory conditions as triggers for application failure.
.NET users were also more likely to cite issues with connectivity to back-end transaction systems, including mainframe systems. Java users, conversely, seem to generate or encounter more bugs. They're also more likely to find fault with JVM or architecture issues than are .NET users (with the .NET CLR, that is).
You can contact the editors about .NET Making Gains Against Java, Survey Says at [email protected].