Accessing Picasa's atom feed API from Spring's REST and XPath templates

Been swearing at my screen and Google's choice of atom based API for their Picasa web albums. Flickr's REST API took 10 seconds to work out. Picasa: days...


My problem:

Trying to parse album ids from Picasa's API: code.google.com/apis/picasaweb/docs/2.0/developers_guide_protocol.html#ListAlbum.


Source picasaResponse = restTemplate.getForObject( albumsURL, Source.class, parameters );

Jaxp13XPathTemplate xpathTemplate = new Jaxp13XPathTemplate();

Collection albumIds = xpathTemplate.evaluate("//entry",

      picasaResponse, new NodeMapper(){

   public Object mapNode(Node node, int i) throws DOMException {

      Element album = (Element) node;

      log.debug("IN NODE ALBUM");

      return null;

   }

}


This never worked. It should have I thought. Trying different combinations of "/entry", "/feed/entry", "//atom:entry", "/atom:feed/atom:entry", swapping with Jaxen, etc made no impact.


Then after some googlebashing and soulsearching I solved the problem.

The Xpath template needs a namespace to resolve the atom xml. So adding this solved the problem:


Source picasaResponse = restTemplate.getForObject( albumsURL, Source.class, parameters );

Jaxp13XPathTemplate xpathTemplate = new Jaxp13XPathTemplate();

Properties namespaces = new Properties();

namespaces.setProperty("atom",

   "http://www.w3.org/2005/Atom");

xpathTemplate.setNamespaces(namespaces);

Collection albumIds = xpathTemplate.evaluate("//atom:entry",

      picasaResponse, new NodeMapper(){

   public Object mapNode(Node node, int i) throws DOMException {

      Element album = (Element) node;

      log.debug("IN NODE ALBUM");

      return null;

   }

}



Ps. code simplified and not using bean injection etc for clarity.

Why IRC is essential for distributed teams

Realising more every day that IRC is essential for distributed teams.

IMs (MSN, Google Talk, Communicator, etc), Skype & Live Meeting works well but is too sheltered, it is invitational only and time constrained.

Email is recorded, too formal, noisy and too asynchronous/slow.

Yammer or Twitter is nice for distributing comments and discussions, but is too slow for actual problem solving.

To keep teams up to date or solve problems together; a group chat is essential.

For culture build and low barrier of interaction of an informal and not archived discussions; a group chat is essential.

For rubber duck statements or help in minor but blocking issues that would be less likely to ask people directly; a group chat is helpful.

For less direct interruptions than IMs or phone; a group chat message which people can respond to when suitable will improve productivity.

Even for non distributed teams, IRC is an important productivity and culture tool. Continuous inconsiderate interruptions will kill productivity, while quick but asynchronous discussions smooth over the time requirements of the person asking and the person responding.

Unfortunately IRC is just too ugly, too much unix/hacker impression, too old; for an enterprise / self important company to consider.

Alternatives like the now discontinued Google Wave, 37signals's CampFire and others exist, but an internal IRC server does solve all these issues.