Marker tooltip

I start with the marker, as it is the simplest implementation:

function attachMarkerInfoWindow(marker, html)
{
	marker.infoWindow = new google.maps.InfoWindow({
		content: html,
	});
	google.maps.event.addListener(marker, 'mouseover', function() {
		marker.infoWindow.open(map,marker);
	});
	google.maps.event.addListener(marker, 'mouseout', function() {
		marker.infoWindow.close();
	});
}

var marker = new google.maps.Marker({
	position: new google.maps.LatLng(56.183182,15.593239),
});

attachMarkerInfoWindow(marker, '<strong>Softhouse office</strong>');

Polygon tooltip

A polygon does not contain a single position, so where should the tooltip show? One option is to calculate the center of the polygon using getCenter() on google.maps.LatLngBounds, but I decided to use the position of the mouseover event as the position of the InfoWindow. Think about it; the center of the polygon may not actually be inside the polygon!

As a bonus I change the fill opacity while the mouse cursor is inside the polygon.

function attachPolygonInfoWindow(polygon, html)
{
	polygon.infoWindow = new google.maps.InfoWindow({
		content: html,
	});
	google.maps.event.addListener(polygon, 'mouseover', function(e) {
		var latLng = e.latLng;
		this.setOptions({fillOpacity:0.1});
		polygon.infoWindow.setPosition(latLng);
		polygon.infoWindow.open(map);
	});
	google.maps.event.addListener(polygon, 'mouseout', function() {
		this.setOptions({fillOpacity:0.35});
		polygon.infoWindow.close();
	});
}

var polygon = new google.maps.Polygon(/* omitted for brevity */);
attachPolygonInfoWindow(polygon, '<strong>Info about this area</strong>');

As painful as it is, we have deemed it necessary to cancel this years conference.

Scrum for team members is a workshop directed to the developers and testers in an agile team,, an obviously very important component in an agile project but maybe not so much the primary target for conferences and the like.

I liked Jim Coplien’s Agile Architecture session on Øresund Agile 2008 very much so I’m pretty sure I can recommend his workshops at Nordic Agile. (Btw, I saw him rushing by at Kastrup Airport the other week!) 

The agile team that I’m part of will most likely be delivering version 1.0 of our current project around those dates, so I won’t be going but I hope you will. Read more on the Nordic Agile web page!

I almost forgot, Clarion Hotel is really nice too! :-)

On a related note: I like the word the Norweigans use for agile: smidig.

After two days of workshops, Wednesday was the conference day. Two sessions specifically addressed distributed Scrum: having teams, or part of teams, in different geographic locations. The presentation by Scrum co-creator Jeff Sutherland was great but also a bit utopian while the other, by Arto Vihavainen and Muqeet Kahn from Qvantel, was not only interesting but also very down to earth. Tobias Fors from Citerus had a very the best presentation slides and Henrik Kniberg told a great tale of Scrum and XP adoption.

Next year’s conference, obviously Øresund Agile 2009, will be in Copenhagen on May 12-14. Add it to your calendar right now!

Update Photos and comments from BestBrains.

• Don’t use TDD, it destroys architecture because it makes the programmer focus on individual methods, losing the bigger picture on the way
• Don’t bother with unit tests, they make a bigger code base (equal amounts of application and unit test code is not unlikely), meaning more defects! The system tests should be enough
• A subset of system tests that run in less than ten minutes should be used as a smoke test.
• For interactive systems he was able to unify Agile software development, Model-View-Controller(-User) and Object Orientation.
• MVC inventor Trygve Reenskaug was referred to a few times, and Jim told us that Trygve’s Data-Collaboration-Algorithm (DCA) was going to be the next big thing in software development! (This will be the seventh hit or so on a Google search for "Data-Collaboration-Algorithm". Maybe I should make a dedicated blog post about it.)
• Domain Specific Languages (DSLs) are bad because they add new languages to learn when new people should work on a system, and it takes years to create a good language.
• UML could be used to visualize a system, but should be generated from source code. Quote: "No hand should ever touch a UML diagram."

Food for thought, isn’t it?

The list above is unfortunately a little short on things that Jim advocates but I need some good sleep before the Accelerated Agile workshop tomorrow and my writing would not be half as good as hearing him saying it.