A mobile interface to the Registry of Standard Biological Parts

Recently I developed a simple mobile interface to the Registry of Standard Biological Parts – the database that is currently the focal point for parts-based synthetic biology. I’ve called this mobile interface mPartsRegistry and I thought it would be worth outlining it’s features and sharing some notes about the project, in case someone else finds it useful.

mPartsRegistry is a simple interface to the Registry of Standard Biological Parts aimed at mobile smartphone browsers. It’s powered by the Parts Registry API, which provides a simple RESTful interface to key metadata about parts in the database. It features:

  • A simple interface tailored for mobile WebKit browsers (Android browser, mobile Safari, probably others). Web-based, zero-installation required.
  • Basic search of the Registry by part name.
  • “Favorite parts” to locally bookmark parts on your device.
  • Provides basic metadata associated with parts, including size, description, authors, DNA sequence, categories and availability.
  • Freely available and recyclable source code, released under the MIT License (fork it on GitHub).

The idea for a mobile interface to the Registry came out of a moment in the wet lab, where I was supervising the Monash iGEM team, and someone asked “How many basepairs is that part again ?”. I’ve found most ideas for smartphone apps in the lab a little contrived; nothing more than an excuse to jump on the Android or iOS app bandwagon, with limited practical utility. This was a situation where I could genuinely see a use for a simple mobile interface to look up some reference information, so I thought I’d create it.

The goal is not to completely replicate the functionality of the Registry (at this stage the API would not allow that anyhow), but to provide simple mobile-friendly interface to quickly look up important data about a Biobrick(tm) parts in a laboratory setting, where accessing a desktop computer is often less convenient. In this context, you generally know the part name (eg B0034) that is written on a tube, but would like to quickly lookup some details.

The project consists of two main parts: the web frontend, build using jQTouch and Django templates hosted on Google App Engine, and the parser backend (partsregistry.py) that deals with directly querying the Registry API.

The application uses BeautifulSoup on the server side to parse the XML served by the Registry’s API. This parser may be useful as a generic Python interface to the Registry API for other projects, although it is not yet feature complete. Why parse the XML on the server rather than the client ? The Registry API does not offer JSONP callbacks, making direct client-to-API queries by a web app served from another domain tricky (Same Origin Policy, yadda yadda). While this probably could have been done in straight clientside Javascript if I’d used some type of cross-domain AJAX hack, parsing on the server side also opens the possibility in the future to ‘value-add’ to the data in some way, potentially incorporating extra data not served directly by the Registry API, before it’s sent to the client.

Google App Engine works as a cheap hosting solution for a low traffic app like this, which is likely to stay within the free quotas. Also, GAE supports Python, and I like Python. jQTouch makes for a reasonable cross-platform mobile web interface, since it is optimized for WebKit-based browsers. While officially jQTouch supports iPhone/iPod Touch and doesn’t have official Android support, in my hands it works well enough on Android (and in fact displayed some minor bugs on Mobile Safari that were not evident on Android). Typically when using jQTouch you are expected to load multiple ‘pages’ all into several div-sections, lumped into a single HTML document. jQTouch then does the Javascript+CSS magic to render fast page switching, which actually working within a single HTML document. Since the main action of this app is to ‘search’, we don’t yet know what the results page will be, so this nice feature of jQTouch is barely used.

Searching for the same part all the time can get annoying, so mPartsRegistry provides a simple ‘bookmarking’ feature where a list of favorite parts can be managed and stored on the device. This is implemented via HTML5 localStorage – if there was demand then this could easily be turned into server side storage, but I doubt it’s necessary. In the future, it might make sense to pre-cache the metadata for any of these “favorite parts” so that the fast page switching features in jQTouch can be used to full advantage.

Currently, the interface does not show information about sequence features, subparts and twins, however I plan to implement these at some point. The Registry API currently does not provide information about samples, literature references or lab groups, but once these are enabled I plan to support this metadata within mPartsRegistry too.

Okay, that’s all kids .. and remember .. take off your gloves before using your smartphone in the lab !

Occyd : tagging for locations

Occyd Map View (search results)

Those who have been watching may have noticed I quietly started developing an Android application in the last month or so. It’s still super-buggy and far from feature complete, but I thought it was time to announce it here (“release early, release often”). It’s not ready for real users yet, but developers may like to take a little look.

Continue reading

Mako templates in Google App Engine: seems to work for me

For some reason which I can’t really articulate, I’m not a huge fan of Django templating. I’d actually prefer to use Genshi with Google App Engine, but I need to wait until all the kinks are ironed out, since as far as I can tell it’s not quite working painlessly yet. Another templating option is Mako, which I’ve barely used, but I still prefer to Django templates. One nice thing about Mako: it’s faster than most Python templating engines out there. So, here’s a quickie on how I got Mako working with Google App Engine. It wasn’t tricky at all, but I thought I’d document it anyway.

Checkout Mako from SVN and copy the directory mako/lib/mako to the path of your application, eg, on Linux:

$ cp -r mako/lib/mako myapp

(where myapp is the directory that your GAE app lives in).

In your app, obviously you’ll need to import some parts of mako:

from mako.template import Template

Then, whenever you want to render a template as output (say, at the end of a ‘get’ or ‘post’ method .. see the GAE templating example for some context), call something like:

# a dictionary of variables to send to the template namespace
foo, bar = "some", "enthralling text"
template_values = {
  ‘some_foo’: foo,
  ‘some_bar’: bar

# index.mako is the template file in our GAE app directory
path = os.path.join(os.path.dirname(__file__), ‘index.mako’)
# make a new template instance
templ = Template(filename=path)
# unpack the dictionary to become keyword arguments and render

An example of some template text that could go into index.mako could be:

<html><body>${some_foo} likes the ${some_bar}<br/></body></html>

One possible modification: I need to look into it, but defining your Template class (eg templ in the example above) in the main() function (maybe as a global) rather than instantiating it every time it is rendered would probably give better performance.

ResolveRef updated : now with auto-suggest and source code

I updated ResolveRef last night and checked in the most current sourcecode to svn at Google Code.

New features include:

ResolveRef, now prettier, with comments box by disqus.

  • Suggest/autocomplete for journal title field, using the journal title lists provided by PubMed.
  • A “Verify” button. Allows a ResolveRef URL to be constructed with the web form and verified as working and valid without actually forwarding the user to the article.
  • Some bugfixes (handled the case where there is no DOI in the PubMed record, handled network timeouts to PubMed)
  • Refreshed visuals
  • Disqus comments box for feedback

In the interest of just getting something working quickly, I implemented the suggest feature in the laziest, possibly most RAM and CPU hungry way possible (the “JQuery Suggest” code queries the web app with substrings as you type each character. At the server side, the app uses a regex to scan a ~1.5 Mb list of journal titles held in RAM). I’ve already noticed a few “This request used a high amount of CPU” warnings in the logs, with the threat “High CPU requests have a small quota, and if you exceed this quota, your app will be temporarily disabled“. If my nasty hack starts heating up Google’s datacentre too much, I might have to disable the ‘suggest’ feature until I can implement it “properly”.

Continue reading

ResolveRef : looking at the logs

One of the nice features of Google App Engine is you can easily view logs for your application to quickly see requests generating errors. Browsing the logs of ResolveRef, I’ve been able to identify an few classes of query which for one reason or another, weren’t working.

Continue reading