Test post

If you can see this post, then the migration from publishing via FTP to hosting at Blogger has worked.

Update: I can see this post myself now. I didn't actually use the migration assistant, just created a new subdomain for the old images and told my ISP to direct this subdomain to Google.

How to find non-GPCR targets for neuroactive drugs

In a follow-up to their Science paper, Hillenmeyer et al. recently published an extended analysis in Genome Biology. While the first paper was more focussed on the genes, this paper examines the chemicals in more detail. In particular, I am intrigued by this finding:

Because their neurological targets do not exist in yeast, the sensitivity we observe is likely a result of these compounds affecting additional cellular targets in yeast [44] these “secondary” targets, if conserved, may correspond to additional targets of these compounds in human cells.

The cited paper is by Ericson et al. (PLoS Genetics) that seems to be rather underappreciated with just 6 citations in Web of Science (as of this writing). Both studies point to numerous non-GPCR off-targets of many drugs. I think the next step should be to indeed test the predicted drug targets, and I'm actually not quite sure why Hillenmeyer et al. didn't do this. Determining the affinities will be the only way to find out if the target found in yeast are relevant to human.

While we predict drug targets, pharma already knows them

All the excitement about predicting drug targets from remote chemical structure similarities (Nature) and drug side effects (Science) suddenly seems strangely unfounded when you realize that "they" already have the answer:
This figure is a tiny section of the data used for Preclinical Safety Profiling at the Novartis Institutes for BioMedical Research. They are not alone: BioPrint from Cerep is a repository of 2500 compounds assayed against 159 targets. Paolini et al. mention 600,000 binding data points at Pfizer.

Things are begining to change, thanks to academic curation efforts like BindingDB, PDSP Ki database, DrugBank etc. and not least to EMBL-EBI's acquisition of ChEMBL. Still, one can only imaging how different current academic research questions would be if the all-against-all drug–target assay information would be public. In essence, academia is working on predicting additional data points from a sparse matrix, while pharma companies already have the full matrix in hand, but want to add more rows/columns to the matrix in silico.

Update: As always, good discussion on FriendFeed.

Human Protein Atlas data for download

As I just learned in our lab's journal club, the data from the Human Protein Atlas is available for download, thanks to their recent paper in MSB. Curiosly enough, the HPA help page still states that they do not make data available as a matter of "general policy."

A Newick parser for Python, supporting internal node labels

I just pushed a fork of Thomas Mailund's nice Newick parser for Python to bitbucket. I added support for labeled internal nodes, but probably partially broke support for bootstrap values.

>>> from newick import parse_tree
>>> t = parse_tree("((Human,Chimp)Primate,(Mouse,Rat)Rodent)Supraprimates;")
>>> print t
(('Human', 'Chimp')Primate, ('Mouse', 'Rat')Rodent)Supraprimates
>>> print t.identifier
Supraprimates

Public Service Announcment: Evolution of the centrosome

Information on the evolution of the centrosome can be found on Wikipedia and in the scientific literature. Not elsewhere.

(I just incorporated part of a grant proposal I sent in last week on Wikipedia. I hope this doesn't lead to any plagiarism charges. ;-) )

Rebasing in Mercurial

After I used git for my own projects for a while, we switched the development of the STRING and STITCH databases from svn to mercurial (on bitbucket). Coming from git, I found two essential things lacking: (1) automatic coloring and paging of diffs and (2) rebasing.

Problem 1 is solved by enabling the pager and using the "attend" option to specify which command should go to less. You'll also have to globally set the options "SR" for less (e.g. "setenv LESS SR").

To rebase means to take code changes that were developed in parallel and make it look like they were developed sequentially, effectively avoiding commits which have the only purpose of merging independent changes. Rebasing before pushing also avoids the problem that you can silently drop previous changes by pushing without pulling beforehand:

That is, the branch name is stored in the changeset. The flaw is that it's quite easy to have more than one branch with the same name, and it's difficult to tell when this has happened. This can cause confusion in a team where one is left wondering what changes, exactly, have made it into the "stable" branch when multiple people have reopened and merged the branch on different timelines.

The problem of the "pointless" merges is solved beautifully by the rebase extension, which is included by default in current versions of hg. I think this extension is under-advertised.

To briefly compare mercurial and git: I think git's approach is a more radical break from subversion etc. and therefore more consistent. However, it's also harder to wrap your head around, which is why we chose mercurial in the end.

For reference, here's my .hgrc.