The last thing I would ever want to do is add any more noise to the impossibly over-hyped AJAX, but there is one aspect of it that I’m looking forward to gaining popularity. I mean, aside from it completely re-inventing the web 2.0 and destroying microsoft and all that. I’ve been playing around a bit with the Google Maps API, and think it is clever how they use JavaScript to define their API. It shields the caller from all of the details of how they use AJAX to get the map data or do event handling within the map. The Google Map “Hello World” is trivial. Even those who think JavaScript is a hella cool programming language can grab a snippet from their friend’s livejournal and get something working. Want to put a map on your blog of all the places you’ve traveled? Or where you buried all those hitchhikers?

Now compare that with the backend python code I wrote that uses XML-RPC to do some geocoding of addresses into latitude and longitude. First, you need to be comfortable enough to write real code, not just copy-n-paste in some Javascript. And let’s remember that XML-RPC is on the simpler end of the web services spectrum. Second, it lets the provider more easily upgrade the service when they transparently add in new features like their hybrid view. Third, it raises the level of abstraction. Instead of getting back a hashtable of key/value pairs, they draw the whole map and you just supply some locations and data. (In the simple case, it could get more complex.) While I have some reservations about making the client-side the integration point or ever wanting to write more JavaScript than is absolutely necessary, it could now be very easy to wire up several different web services for your own nefarious purposes. Feels like simple web services for the dirty, unwashed masses.

I think there is a problem in the way CVS diffs Java source. I’ve seen this issue many times where CVS thinks I’ve inserted a method within an existing method’s Javadoc starting comment. When, in fact, what happened was that an entirely new method was added above the existing method. The screenshot below (which comes from Fisheye) shows the resulting diff. It isn’t a big deal for diff’ing, but it shows up during merges making it appear as though the original method was edited, when it really wasn’t. In this example, isNotEmptyString is entirely new and should not appear intertwined with the existing method. (And I’ve seen this enough to know that it is not a case where I accidently start typing in the middle of the other method.)

If I understand it correctly, it seems like the /** of the original Javadoc comment leads CVS to believe that that line didn’t change, since it exists in the same spot in the ancestor and contributor. So it assumes that the rest of the new method is really an addition in between lines in the original method. I suppose one workaround would be to favor putting new methods at the bottom of the class.