Blog - MapMyGlobe

A massive amount of refactoring is currently going on throughout the MapMyGlobe application’s code. As for any project that’s evolving along the way as it’s being developed, some pieces of code end up replicated, or not in the place they should be. I thought I would write a few words about why I find refactoring hard, but why I do it and why a project sometimes really needs it.

I personally find refactoring intrinsically, and almost metaphysically, difficult. At some point in my projects I know I’m going to have to do some, but then my mind is really tormented and I’m really stressed out, and I’m sure this feeling is shared by a fair number of my fellow programmers. First, we’re afraid that refactoring might break a feature that’s currently working, and that’s indeed often the case, but Version control alleviates this problem (assuming you use it, but I think you should, even when you develop solo) because you can always go back and rectify what’s been broken.

But even with Version control, there’s a feeling, conscious or sub-conscious, of non-reversibility of what we’re doing: in most cases, what has been refactored won’t ever retrieve its past form, so we feel like we’re throwing away some stuff, and this thought really scares us. I don’t want to sound squeamish or anything, but our mind can get really tormented. What happens is that both sides of our mind have something to say: while our rational side pleads for some rewriting and reorganization of our past work to increase future productivity, our creative side is scared, because doing so and looking back at what we’ve done before might stop our creative flow. So in the end, it is the same feeling as an artist who’s in a creative phase and who doesn’t want to stop by fear of losing it. And by the way, what’s a programmer, if not an artist?

One year ago, the Google Maps API development team released a small but pretty neat improvement to their Geocoding API: the ability to get the response’s accuracy level for a given address.

This feature enables applications to modify their zoom level according to the precision of the address that’s being geocoded, for example, “Paris” at the city zoom level, but “1 rue Royale, 75008 Paris” at the much more precise street address zoom level.

What the Google geocoder actually outputs (see reference) is a value between 1 and 8. And the GMaps zoom level is an integer between 1 and 19. So the question is: given a geocoding accuracy, which zoom level should I use to display the place? I didn’t find any answer to that question on the web so I decided to make up my own correspondence between the two scales. Any such correspondence is bound to be imperfect since two different cities can have very different sizes, however the method usually outputs a decent result.

var tabAccuracy = new Array(2,4,6,10,12,13,16,16,17);

function showAddress(address) {
  if (geocoder) {
    geocoder.getLocations(address,
    function(response) {
      if(response.Status.code!=200){
        alert('"' + address + '" not found');
      } else {
        place = response.Placemark[0];
        accuracy = place.AddressDetails.Accuracy;
        map.setCenter(new GLatLng(place.Point.coordinates[1],
             place.Point.coordinates[0]), tabAccuracy[accuracy]);
      }
    }
    );
  }
}

I calibrated the association on a few cities such as Paris, NYC and San Francisco, and I was a bit conservative to ensure that people with small screens still get the picture. Let me know if you find this scale useful.

Just a short post today to introduce the blog’s new header design. The Google Maps screenshots are a reference to the importance of the GMaps API in my web application, mapmyglobe.com. Right now the banner rotates between 4 different locations, which are important to me, because they are the places where this web app will have been conceived and built

But then I found out that the blog’s title and catchphrase were very difficult to read. Unfortunately CSS implementation still lacks text-stroke (text displayed on a white surrounding that makes it easier to read, like the text on the GMaps layers). So I’ve put together a quick javascript-and-CSS hack to have any text element that I want being displayed with a stroke. In my case I am stroking the blog’s title and tagline. This hack perfectly exemplifies DOM manipulation’s power, which is what I wrote about last time, so I thought I would write something about it. I’ve made it available right here: Text Stroke effect with Javascript and CSS.

Other than that, the project is moving along nicely, with some major refactoring going on right now… More on that later on.

Today I figured I would write about how I feel about the whole AJAX-y techniques set.

AJAX stuff is great and I use it a lot throughout the application I’m building right now, mapmyglobe.com. A lot has been written about it and I won’t repeat it all. The ability to asynchronously (first A) exchange small pieces of data between client and server without the need for reloading the whole page is great, and so is the seamless integration of XML (X) in lots of scripting languages, calling for spending time on the data processing rather than on the data transport and parsing, and thus providing an abstraction layer for data management (actually in web apps XML is often replaced by smaller-overhead syntaxes like JSON, but the concept is the same). And the whole Javascript (J) function stack provides a powerful framework for client-side, in-browser, interaction and processing.

But what I really feel strongly about, and which does not come to mind first when you talk about AJAX, is the DOM scripting. DOM (Document Object Model) scripting is the ability to dynamically modify the page’s html code, through Javascript functions. As such, DOM scripting is the root of the paradigm shift in web development: from the web being a set of documents being dynamically produced and served to the user, it’s now become a place where you can find real applications that react to the user’s actions, not the browser’s.

My main point is that DOM modification calls for bridging the gap between Flash, desktop widget applications or other multimedia formats that are visually impressive but poor for actual Internet-centered stuff such as user-generated content or search engine integration, and semantic, text-based media that’s great for machine readability but often lack the design assets and appeal. “AJAX”-y javascript effects tend to bridge both worlds and bring together semantic content and animation. We could just integrate user-generated text with fancy javascript effects, but that’s not what I aim at. What I want to do is enable user-generated animation. That’s what’s going to be really innovative. Stay tuned for it.