window.pointsAround = function(centerLat, centerLng, radius, numInterpolations) {
    var result = [];

    //do annoying trig maths to work out the delta in latitude between our start and end points
    var targetD = radius;          //km
    var fractionalDistance = (targetD / radiusOfEarth) / 2;
    var sqrtA = Math.sin(fractionalDistance);
    var a = sqrtA * sqrtA;
    var sinHalfDLat = Math.sqrt(a);
    var dLat = Math.asin(sinHalfDLat) * 2;
    var dLatDegrees = degrees(dLat);
    
    var minLat = centerLat - dLatDegrees;              //furthest valid latitude above the origin
    var maxLat = centerLat + dLatDegrees;            //furthest valid latitude below the origin
    
    var centerLatRadians = radians(centerLat); 
    
    //topmost and bottommost points in the circle
    result.push({lat: minLat, lng: centerLng});
    result.push({lat: maxLat, lng: centerLng});
    
    //step from minLat to maxLat, interpolating coordinates that lie upon the circle
    numInterpolations = numInterpolations ? numInterpolations : 360;
    var step = (maxLat - minLat) / (numInterpolations / 2.0);
    for (var count = 0; count < (numInterpolations / 2) - 1; count++) {
        minLat += step;
        var minLatRadians = radians(minLat);
        dLat = radians(centerLat - minLat);
        
        //more annoying trig to work out the delta in longitude for our interpolated coordinate
        var dLon = 2 * Math.asin(Math.sqrt((a - (Math.sin(dLat/2) * Math.sin(dLat/2))) / (Math.cos(minLatRadians) * Math.cos(centerLatRadians))));
        var dLonDegrees = degrees(dLon);
        
        var newLng = centerLng + dLonDegrees;
        var deltaLng = newLng - centerLng;
        result.push({lat: minLat, lng: newLng});
        result.push({lat: minLat, lng: centerLng - deltaLng});
    }
    
    return result;
};

This code works out the northernmost and southernmost points that are the specified distance away from the given centerpoint. It then steps between the minimum and maximum latitude of these two points, interpolating the appropriate longitudinal value(s) to satisfy the equidistant constraint. The total number of coordinates returned can be controlled using the optional ‘numInterpolations‘ parameter. When not specified a total of 360 points will be returned by default, because that is a nice, round number.

If you use something like the following code to plot some points on a map:

window.map = new GMap2(document.getElementById("mapDiv"));
    var centerPoint = new GLatLng(37.4419, -122.1419);
    map.setCenter(centerPoint, 8);
    map.addControl(new GLargeMapControl3D());
    map.addControl(new GMapTypeControl());
    
    var marker = new GMarker(centerPoint);
    var markerText = "Center @ 37.4419, -122.1419";
    GEvent.addListener(marker, "click", markerClickHandler(marker, markerText));
    map.addOverlay(marker);
    
    var points = pointsAround(37.4419, -122.1419, 50);
    for (var index = 0; index < points.length; index++) {
        var point = points[index];
        var latlng = new GLatLng(point.lat, point.lng);
        marker = new GMarker(latlng);
        markerText = "Marker @ " + point.lat + ", " + point.lng;
        GEvent.addListener(marker, "click", markerClickHandler(marker, markerText));
        map.addOverlay(marker);
    }

…you will get a nice circle of points around the hard-coded centerpoint. You can see a working example of this here: http://jsfiddle.net/HmchC/27/.

Well Wikipedia doesn’t provide this information directly, but interestingly enough Wikipedia does in fact keep all the historical data necessary to answer this question. Thanks to Chrome’s awesome JavaScript console (and the fact that Wikipedia uses jQuery on all of its pages) it is a very simple matter to extract this historical information in a format that is easy to work with later. The following code will do the trick:

var result = []; 
jQuery.each($(".filehistory a[href$=5day.gif]"), function(){
    result.push(this.href)
}); 
result;

This simply constructs an array containing the URL’s of every historical forecast/storm track graphic (ordered by date from newest to oldest) and outputs it to the console. We can then copy/paste the console output to wherever we like, such as jsFiddle for instance. Combine this with some basic HTML structure:

<div class="title">
    Hurricane Irene Animated Forecast Map
</div>
<img id="display" src="http://fcf.teambeachbody.com/fcf/images/spinner5.gif" />
<div id="status">
    (<span id="numLoaded"></span> of <span id="total"></span> frames loaded)
</div>

…and some simple JavaScript to handle the actual rendering:

document.getElementById("numLoaded").innerHTML = "0";
document.getElementById("total").innerHTML = data.length;

//preload all the images so that they are cached for the animation
window.imagesLoaded = 0;
for (var index = data.length - 1; index >= 0; index--) {
    var node = document.createElement("img");
    node.style.display = "none";
    document.body.appendChild(node);
    $(node).bind('load', function() {  
        window.imagesLoaded++;  
    });
    $(node).attr('src', data[index]);
    //node.src = data[index];
}

//run the animation
window.currentImage = data.length - 1;
window.updateAnimation = function() {
    if (window.imagesLoaded < data.length) {
        //keep waiting
        document.getElementById("numLoaded").innerHTML = window.imagesLoaded;
        return;
    }
    $("#status").hide();
    document.getElementById("display").src = data[currentImage];
    currentImage--;
    if (currentImage < 0) {
        currentImage = data.length - 1;
    }
};

setInterval(updateAnimation, 200);

…and you get an animated map of the entire forecast history, including the actual storm track. The result looks something like this:

Not too bad for a few dozen lines of code and about 30 minutes worth of effort. You can also access a full-scale, editable version of this animated storm history here.

So what does this say about the accuracy of the hurricane forecasting for Irene? Personally I think it shows that the forecasts are pretty damn accurate. In fact, if you focus just on the solid white portion of the predicted storm track it appears that the storm never deviates from its forecast path. It’s only when looking at the dashed white portion of the forecast that any significant deviation can be noted. And the dashed white portion indicates forecasts that are more than 72 hours in the future.

Of course we should always be working to improve our ability to predict and forecast these things, but I have to think that being able to accurately predict a storm’s movement for up to 72 hours into the future is adequate for most purposes.

But sadly, Prototype decided to use ‘$()‘ as the name of their alias. And even worse, other frameworks have followed in this pattern, adding their own dollar functions that have semantics that can be completely different from the original ‘$()‘ introduced by Prototype. Consider jQuery, which introduces its own version of ‘$()‘ which can be used to find (and wrap and clone) elements in the DOM by a number of different criteria, but which sadly fails miserably when given a string containing a literal element id. This creates a lovely situation where now the developer cannot even guess at what ‘$()‘ is actually doing without first checking to see which framework is being used by the code. It also means that any code that was written using Prototype’s ‘$()‘ will be broken by including jQuery (and vice-versa).

“But that’s what ‘jQuery.noConflict()‘ is for”, you say. But you miss the point. It shouldn’t be necessary for ‘jQuery.noConflict()‘ to exist in the first place. If the jQuery developers hadn’t decided that it would be cute to define their own version of ‘$()‘, then jQuery would never conflict with anything except possibly an older version of jQuery. The thing that really baffles me is how so many developers (obviously talented developers, at that, considering the work that goes into something like Prototype or jQuery) can all decide that it is a good idea to try to lay claim to a name that exists in the global scope. Granted JavaScript does not have any concept of a proper namespace, but if jQuery limited itself to only setting properties on an object named “jQuery” and Prototype did the same on an object named “Prototype” and so on, the current JavaScript landscape would look ever so much more sane.

And of course, this says nothing of the ‘$$()‘ and ‘$F()‘ functions that were also introduced by Prototype (and the ‘$E()’ and ‘$ES()’ functions inexplicibly introduced by MooTools) and whose names are so semantically worthless that a developer has no hope of inferring their function without consulting the reference documentation. Which again can only be accomplished after checking the entire codebase to determine which framework it is that is defining these functions with its woefully awful naming convention.

If the developers of Prototype, jQuery, Mootools, and the like wanted to turn JavaScript into an unreadable and unmaintainable mess of a language like Perl, then I applaud them for their efforts. But if not then I call them all out on their atrocious naming convention and design decisions. There is no excuse for this nonsense. If you’re building a JavaScript library or framework, then pick a reasonable “namespace” to use for it. This namespace should be the only thing that you bind in the global scope. Everything else that is part of your library should be bound as a property inside of this namespace. And there should be no automatic creation of shorthand aliases in the global scope.

I don’t think this is too much to ask. And of course, any developer that wants to use a global shorthand alias can always do:

window.$J = jQuery;
window.$P = Prototype.$;  //or:  window.$P = document.getElementById;

It takes all of one line of code to set up an alias. But when you start doing this automatically for everyone that uses your framework you create nothing but problems. Especially when you jump on the bandwagon and choose the same crappy shorthand alias names that other frameworks are already using.

There is absolutely no reason why multiple JavaScript frameworks should all be competing over the same terrible function names. This isn’t a contest to see who can break the most legacy code, or who can come up with the most obtuse API. They do have such contests if you are interested in such a thing, but this is not one of them. The only thing accomplished by parading the dollar sign around as an example of a well-chosen function name is an increased brittleness in the code that glues together the majority of our modern websites. It muddies semantics, and creates cases where completely unrelated libraries are not easily compatible with each other, and where simply importing a new library can cause existing code to break. Even worse, some novice developers get the wrong idea from all those dollar signs flying around think that they need to (or should) prefix all of their function names with “$”. So let’s put this bad practice to bed before it’s too late.

So please, can well all stop writing frameworks that give people the impression that calling a function “$”, “$$”, “$ES”, or “$anything” is a good idea? Is it so difficult to choose a reasonable namespace, minimize the number of things that you declare in the global scope, and allow the developer to define a global shorthand alias for this-or-that utility function if they decide they want to? I think not.

Each comic in Webcomix is periodically checked for updates, so if like me you keep tabs on several different web-comics that all update at different intervals then Webcomix will save you from having to remember to refresh half a dozen different websites at various times just to keep up to date. Simply visit your Webcomix dashboard and you’re set!

Underneath the covers there’s a fair bit that I’m proud of with this app. First off the entire system is designed to be as lightweight and efficient (in terms of server compute-time and bandwidth) as reasonably possible. Virtually all of the actual work is handled by the client-side JavaScript. The handful of tasks that must be performed server-side are optimized with the help of a custom caching layer which ensures that any given computation (or fetch of an external resource) only needs to be performed once. There is also an additional caching layer in the client used to prevent it from making any given request to the server more than once per session.

The server itself is client-agnostic and provides a simple JSON-based API, meaning that while the initial incarnation of Webcomix is in the form of a web-app it should be just as easy to package the same functionality in a mobile, desktop, or other flavor of application. But that’s a project for another day.

Anyhow, please note that Webcomix should be considered to be beta software at the moment. So if you find any bugs or have any suggestions for new features or improved functionality then please don’t hesitate to say so in the comments section.

Also, the list of comics currently available in Webcomix is not set in stone and is only based upon my personal preferences at the moment. Webcomix is designed in a way that makes adding additional comics a trivial task, so if your favorite comic is currently not in the list then I encourage you to post a request in the comments section so that I can add it.

Lastly, if anyone has any good ideas for how to extend the comic selection UI to handle a large number of comics that they’d like to share, then please do. The current interface with its basic rows of checkboxes is obviously not sufficient for handling hundreds (or even dozens) of comics. It needs to be replaced with something better (or at least, collapsible) soon.

First, let’s say that for whatever reason you need to remove the “Powered by Google” logo and the other copyright and similar boilerplate that normally appears along the bottom of the map. Why would you want to do this? Perhaps because you are displaying your map inside of a small area of the page where space is constrained to the point that the logo and other things are adding too much noise. Or perhaps because you feel (quite justifiably) that Google Maps have become iconic to the point that nobody needs to see a “Powered by Google” logo in the corner to know that the map is being powered by Google.

Whatever your reason for wanting to unclutter the map’s footer section, the task can be accomplished using a smidgen of CSS:

		.terms-of-use-link {
		    display: none;
		}

		#myMapContainerId div span {
			display: none;
		}

…and a handful of JavaScript:

			//call this after setting up your GMap2 instance
			window.unclutter = function() {
				var executed = false;
				var images = document.getElementsByTagName('img');
				for (var index = 0; index < images.length; index++) {
					var node = images[index];
					if (node.src && node.src.indexOf("mapfiles/poweredby.png") > 0) {
						node.style.display = 'none';
						executed = true;
					}
				}

				if (! executed) {
					setTimeout(window.unclutter, 250);
				}
			};

It’s pretty straightforward, really. The CSS gets rid of the “Terms of Use” link, as well as the spans that are used to display copyright text (note that you should replace the ‘myMapContainerId‘ with whatever your actual map div-id is). The JavaScript is used to get rid of the “Powered by Google” logo, which is added to the map after it loads. To use this code, you just need to call ‘unclutter()‘ after setting up your Google Map instance.

Of course, doing this is a blatant violation of the Google Maps Terms of Service. You know, the terms Google made you agree to when you generated your API key. Whether or not there is any merit in having Terms of Service mandate things which do nothing whatsoever to benefit end users such as the display of logos and copyright gibberish is a topic for another day. The topic for today is, if Google Maps can be used without an API key, and hence without agreeing to the Terms of Service, what does it matter what the terms are anyways?

That’s right, the Google Maps API can be used, at least for basic tasks, completely without an API key. It’s quite simple really, just a tiny bit more JavaScript:

			//be sure to do this *before* you source in the Google Maps javascript
			window._alert = window.alert;
			window.alert = function() {return;};

…and then you can include the Google Maps JavaScript without specifying an API key, like so:

<script src="http://maps.google.com/maps?file=api&amp;v=2&amp;sensor=true" type="text/javascript"></script>

The added JavaScript simply moves the browser’s built-in ‘alert()‘ function to ‘_alert()‘ so that the map can’t use it to display a message complaining about the missing API key. For whatever reason, apart from this alert message Google does nothing to prevent their API from being used without a valid key. So by simply suppressing the error message you can get a fully functional Google map without registering for a key or agreeing to the Terms of Service.

Put all of this together and you can get an anonymous, unbranded, uncluttered map the works just as well as the original version. The source code (verified in current versions of IE, Firefox, and Chrome) might look something like this:

<html>
	<head>
		<title>Google Maps API Example Hack</title>
		<style>
			.terms-of-use-link {
		    		display: none;
			}

			#myMapContainerId div span {
			     display: none;
			}
		</style>
		<script type="text/javascript">
			window._alert = window.alert;
			window.alert = function() {return;};

			window.setupMap = function() {
				window.map = new GMap2(document.getElementById("myMapContainerId"));
				map.setCenter(new GLatLng(37.4419, -122.1419), 13);
				map.addControl(new GLargeMapControl3D());
				map.addControl(new GMapTypeControl());
			};

			window.unclutter = function() {
				var executed = false;
				var images = document.getElementsByTagName('img');
				for (var index = 0; index < images.length; index++) {
					var node = images[index];
					if (node.src && node.src.indexOf("mapfiles/poweredby.png") > 0) {
						node.style.display = 'none';
						executed = true;
					}
				}

				if (! executed) {
					setTimeout(window.unclutter, 250);
				}
			};

			window.onload = function() {setupMap(); unclutter();};
		</script>
		<script src="http://maps.google.com/maps?file=api&amp;v=2&amp;sensor=true&amp;" type="text/javascript"></script>
	</head>
	<body>
		Note the lack of branding/logos, terms of use links, and copyright footer text in the map below.<br />
		Also note the lack of any Google Maps API key in the document source.<br />
		And the lack of any annoying <a href="#" onclick="_alert('I can still create alerts, but the Google Map can\'t.'); return false;">alert</a> popups complaining about the API key.<br /><br />
		<div id="myMapContainerId" style="width: 600px; height: 400px;"></div>
	</body>
</html>

…which gives you a page like this one. It’s enough to make one wonder why anyone would bother signing up for a Google Maps API key the proper way, when the entire thing can be subverted so easily.

setTimeout("alert('test')", 5000);

…will display an alert box containing the text “test” after a 5-second delay. Simple enough. But what you may not know is that ‘setTimeout()‘ also supports an alternate and much more useful usage mode where instead of literal javascript text you can pass a function reference/closure and a variable number of parameters, like so:

setTimeout(alert, 5000, "test");

This will produce the same results as the first call, but the syntax is much more readable and much less prone to errors when coding. Why this variant is barely even mentioned in the documentation I cannot say, but anyone who has worked with Flash/ActionScript is probably familiar with this syntax.

There is one major limitation to this approach, however; it does not work correctly in Internet Explorer. That’s a pretty serious drawback, considering Internet Explorer’s market share. But we can fix it by overriding the default ‘setTimeout()‘ implementation as follows:

window._oldSetTimeout = window.setTimeout;
window.setTimeout = function(closureOrText, delay) {
    if (arguments.length <= 2 || typeof closureOrText != "function") {
        _oldSetTimeout(closureOrText, delay);
    }
    else {
        var funcArgs = new Array(); 
        for (var index = 2; index < arguments.length; index++) {
            funcArgs.push(arguments[index]);
        }
        _oldSetTimeout(_timeoutCallback(closureOrText, funcArgs), delay);
    }
};
window._timeoutCallback = function(closure, argArray) {
    return function() {
        closure.apply(this, argArray);
    };
};

Now the behavior will be consistent between Internet Explorer and other browsers. Note that although the default implementation only needs to be overridden in Internet Explorer, the above code will work correctly in other browsers as well. Also note that there is one more caveat to be aware of here as well. In Internet Explorer, functions provided by the system (such as ‘alert()‘, ‘escape()‘, ‘parseInt()‘, etc.) are of a different type than user-defined functions. Now this wouldn’t be a huge problem, except that whatever type Internet Explorer uses for its system functions does not support the ‘apply()‘ method (thanks, Microsoft).

So even with the above code, if you use ‘setTimeout()‘ with a system function in Internet Explorer, you will still get incorrect behavior. We can fix this by revising the code as follows:

window._oldSetTimeout = window.setTimeout;
window.setTimeout = function(closureOrText, delay) {
    var funcArgs = new Array(); 
    for (var index = 2; index < arguments.length; index++) {
        funcArgs.push(arguments[index]);
    }
    if (arguments.length <= 2 || typeof closureOrText != "function") {
        if (arguments.length <= 2 || typeof closureOrText == "string") {
            _oldSetTimeout(closureOrText, delay);
        }
        else {
            //hack for IE system functions
            _oldSetTimeout(_timeoutCallbackForSystemFunction (closureOrText, funcArgs), delay);
        }
    }
    else {
        _oldSetTimeout(_timeoutCallback(closureOrText, funcArgs), delay);
    }
};
window._timeoutCallback = function(closure, argArray) {
    return function() {
        closure.apply(this, argArray);
    };
};
window._timeoutCallbackForSystemFunction = function(closure, argArray) {
    return function() {
        if (argArray.length == 1) {
            closure(argArray[0]);
        }
        else if (argArray.length == 2) {
            closure(argArray[0], argArray[1]);
        }
        else {
            alert("WARN:  Too many arguments passed to system function; timeout callback not executed!");
        }
    };
};

This code will produce the correct behavior in Internet Explorer, and is still compatible with all other major browsers. In Internet Explorer it is limited to supporting system functions with a maximum of 2 parameters, but I’m not aware of any that require more than that anyways. An alternate workaround is to define your own function that wraps the system function, and then use the wrapper function in the ‘setTimeout()‘ call, like so:

var myAlert = function(text) {
    alert(text);
};
setTimeout(myAlert, "5000", "test");

It’s a bit less convenient to do it this way if you will be working with several different system functions, but this approach will also yield correct behavior in Internet Explorer (and is compatible with other browsers as well).

In any case, either approach can be used to get the closure-based ‘setTimeout()‘ syntax working consistently across all major browsers. And once you have that, there is very little reason to ever prefer the text-based version.

parseInt("07");

…will return 7, as expected, but:

parseInt("08");

…will return 0, because 8 is not a valid digit in a base-8 number system. Technically the ‘parseInt()‘ function is behaving to spec in each instance, but this can lead to some very confusing errors if you’re not expecting this behavior. A simple fix exists, however:

parseInt("08", 10);

…will return 8, as expected. Explicitly specifying a radix of 10 overrides the function’s quirky default behavior (which as near as I can tell is a relic carried over from C and Java, which both use a leading zero to specify octal literals…why they didn’t opt for something more clear, like suffixing the value with ‘o’, I cannot say). Here is a quick example comparing the two.

An alternate fix to this issue is to simply override the parseInt() function, like so:

			window._oldParseInt = window.parseInt;
			window.parseInt = function(str, rad) {
				if (! rad) {
					return _oldParseInt(str, 10);
				}
				return _oldParseInt(str, rad);
			};

This will change the behavior of ‘parseInt()‘ to match that of Java’s ‘Integer.parseInt()‘ function (the radix used is always 10 unless the developer explicitly overrides it), which provides for a much more consistent and predictable experience.

Note, however, that this quirky behavior is a documented (albeit deprecated) feature of the ‘parseInt()‘ function; though it is certainly not something that one intuitively expects. Interestingly enough, its deprecation means that browser implementors are free to drop support for this confusing default at any time. However, complete removal of this feature seems unlikely to happen, as doing so would break existing websites that rely upon it.

Perhaps a reasonable middle ground would be to preserve the default behavior when the string being parsed includes only valid base-8 numbers, and default to base-10 if any other numbers are present in the string. That would help in simple cases like the ones shown above, but still may generate confusing output for inputs like “0107” and the like.

Really the problem here is one of a poorly designed spec. Instead of picking the most common usage mode and making that the default, like Java does in its ‘Integer.parseInt()‘ function, someone decided to try to infer the desired usage mode based upon the input parameter. And that may be fine when there are no ambiguous mappings from input parameters to usage modes, but that is not the case here. Whenever such ambiguous mappings exist, it is always better to just make the most common usage mode the default, and let the developer override it if they want something different.

Otherwise you produce code that can yield confusing and unexpected behavior, and you dig everyone else into a hole where they must continue both supporting and working around your poor design decision.