BLAST+ should keep its BL_ORD_ID identifiers to itself

This is in a sense a continuation of my previous BLAST blog post, My IDs not good enough for NCBI BLAST+. My core complaint is that makeblastdb currently ignores the user's own identifiers and automatically assigns its own identifiers (gnl|BL_ORD_ID|0, gnl|BL_ORD_ID|1, gnl|BL_ORD_ID|2, etc), and that the BLAST+ suite as a whole is inconsistent about hiding these in its output.

Note that one side-effect of BLAST+ ignoring the user identifiers and creating its own is that it can tolerate databases made from FASTA files with accidentally duplicated identifiers, but this only causes great confusion and ambiguity in the downstream analysis. One of the ways I've seen FASTA files be created with accidentally duplicated identifiers is pooling of assemblies where generic names like contig1 (or even the more complex Trinity naming scheme) naturally cause clashes. In situations like this, I think makeblastdb should give an error when attempting to build a BLAST database.

Trouble with chimeras - getting all complete viral genomes from the NCBI

Back in 2009, I wrote some Python scripts to use the NCBI Entrez Utilities to search for and download all known complete virus genomes in GenBank format, which I then processed to make FASTA files and BLAST databases. Recently I updated them and ran into some problems... false positives like entire bacterial genomes! This turns out to be due to a few bacteria with integrated phage being annotated as chimeras - genomes combined from multiple organisms.

UTF8 encoded Japanese in LaTeX

Slightly off topic, but anyway... notes on getting Japanese text working in LaTeX under Mac OS X using TeX Live. Once I finally got it to work it is quite easy, but first I explored a lot of dead ends and distractions (in the end I could ignore LaTeX Omega, XeLaTeX, etc). I'm just using pdflatex with the LaTeX Chinese, Japanese, Korean (CJK) package, here's an example from the PDF output:

Interview with a PeerJ author (me)

This summer I submitted a paper to the innovative new open access journal PeerJ, where it was published this week (Cock et al. 2013). I decided to write up the experience in the style of the PeerJ's Interview with an Author blog posts. I've copied the questions they normally ask, and written up my own replies - other than some rough edges in their current submission system it was all good.

Update: This has been reposted on the official PeerJ blog, with responses which I have inserted below.

Using Travis-CI for testing Galaxy Tools

Travis CI is one of the best things to happen to GitHub in some time - it adds automated testing capabilities to your source code repository as changes are committed, and even on pull requests to help ensure new work doesn't break existing functionality.

We've been using this for Biopython for over a year, but this month I've started using TravisCI for testing my add-ons for the Galaxy Project as well. My Galaxy tools (see also Cock et al. 2013) were already being tested every night once uploaded to the Galaxy Tool Shed, and I always stage releases via the Galaxy Test Tool Shed before posting them on the main Galaxy Tool Shed. However this fixed nightly schedule isn't very flexible for debugging failures.

Galaxy BLAST tools:

Galaxy sequence analysis tools:

I've currently got TravisCI working for my two Galaxy tool repositories on GitHub. Both configurations follow the same basic approach, which I have tried to explain in this post, and run the tests as soon as I update GitHub.