OpenID: don’t provide if you won’t accept

Once again, an interesting FriendFeed discussion has morphed into a thread on a wider issue: OpenID.

OpenID is one of those brilliantly simple ideas that you’d imagine most people would applaud. A single “digital identity”, used for any website that requires a login, rather than creating multiple accounts, usernames and passwords for each site. Here’s the problem: many services allow you to use your account details as an OpenID at other sites, but they won’t accept credentials other than their own. For example, both my WordPress and GMail accounts are OpenIDs, but I can’t login to Google using

You might ask – why? Is it some sort of “brand loyalty” issue? When I sign up to Service X, is there a contract between us such that Service X provides me with tools so long as I declare myself to be “Neil @ Service X”, as opposed to “Neil @ Service Y”? I’m still logged into Service X, I must be “registered” in some sense as a user and I’m more likely to return if Service X makes my life easier. Where’s the problem?

There must be strategists who make these recommendations to companies. I’d really like to hear their reasoning.

Spreading the message, a few minds at a time

Given my passion for online science networking, it’s surprising that I’ve never given a talk on the subject [1]. So a big thank you to William who invited me over to his institute for an informal chat about the topic with a small group of staff.

I learned that:

  • A good quote from an internet guru goes down well
  • Everyone loves an xkcd cartoon
  • Many biologists still don’t know what an RSS feed is

My slides are embedded, below or visit Slideshare – best viewed full screen.

1. Oh wait, I work in a university
See the slides

Poor reproducibility: understandable, if not desirable

Greg Wilson once told me a statistic concerning the mean lifetime of research software reproducibility. That is, the time that elapses on average after which you cannot reproduce your own results using your own code, never mind anyone else’s. I forget the exact number but it was not high – a few months at best.

Why does this happen, aside from obvious bad practices? Well, here’s a typical exchange in an academic research setting:
Read the rest…

Good software, data and your brain

I recently asked the FriendFeed community about wiki usage and was struck by a comment from Allyson:

I think we’re on our third incarnation of various bits of wiki software, and we’ve finally hit on the right software for both our wet lab and bioinformaticians

By “the right software”, she means software that makes sense to the people who use it. When faced with several software alternatives, we often find there is one which for some reason, “makes sense” – it meshes naturally with the way our brains work. When you find a program that you like, it’s not only a joy to use but can enable understanding of data and processes that previously eluded you. In other words, good software doesn’t shield you from the fundamentals – it illuminates them.
Here are three examples of software that made me say: “Oh right! Now I get it.” These are not recommendations and opinions expressed are highly subjective: the point is, I like them because they work for me.
Read the rest…

DokuWiki, PubMed and Ruby

I recently built a wiki for a research group using DokuWiki, one of my favourite wiki packages. As with many other wikis, developers have extended its functionality by writing plugins. Some of these are excellent, allowing users to generate lots of content with a minimum of syntax. For example, using the PubMed plugin, you type this:


and the result is this:

Which got me thinking. Assuming that you’ve searched PubMed and retrieved a bunch of references in XML format, how might you generate text in DokuWiki syntax, to paste into your wiki? Here’s the small parser that I wrote in ruby:

require 'rubygems'
require 'hpricot'

h = {}
d = Hpricot.XML(open('pubmed_result.xml'))

(d/:PubmedArticle).each do |a|
  (h["=== #{'DateCreated/Year').inner_html} ==="] ||= []) << "{{pubmed>long:#{'PMID').inner_html}}}"

puts h.sort {|a,b| b<=>a}

Nine lines – how cool is that? It uses Hpricot to parse the XML and creates a hash of arrays. Hash key is the year, formatted to show a level 4 headline in DokuWiki; hash value is an array of PMIDs, formatted with PubMed plugin syntax. At the end we just print it all out, sorting by year from newest – oldest.

As Pierre would say – that’s it.