Recently my Eclipse started to misbehave. The ‘Display’ view (where snippets of code can be executed during debugging) wasn’t coming up; instead an exception was showing:

Error
Wed Jan 19 15:17:33 CET 2011
Unable to create view ID org.eclipse.jdt.debug.ui.DisplayView: An unexpected exception was thrown.

java.lang.NullPointerException
at org.eclipse.jdt.internal.ui.JavaPlugin.getTemplateContextRegistry(JavaPlugin.java:802)
at org.eclipse.jdt.internal.debug.ui.contentassist.JavaDebugContentAssistProcessor.(JavaDebugContentAssistProcessor.java:54)
at org.eclipse.jdt.internal.debug.ui.display.DisplayViewerConfiguration.getContentAssistantProcessor(DisplayViewerConfiguration.java:55)
at org.eclipse.jdt.internal.debug.ui.display.DisplayViewerConfiguration.getContentAssistant(DisplayViewerConfiguration.java:65)
at org.eclipse.jface.text.source.SourceViewer.configure(SourceViewer.java:452)
at org.eclipse.jdt.internal.debug.ui.JDISourceViewer.configure(JDISourceViewer.java:304)
at org.eclipse.jdt.internal.debug.ui.display.DisplayView.createPartControl(DisplayView.java:168)
at org.eclipse.ui.internal.ViewReference.createPartHelper(ViewReference.java:375)
at org.eclipse.ui.internal.ViewReference.createPart(ViewReference.java:229)
at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:595)
at org.eclipse.ui.internal.WorkbenchPage$ActivationList.setActive(WorkbenchPage.java:4218)
at org.eclipse.ui.internal.WorkbenchPage$18.runWithException(WorkbenchPage.java:3277)
at org.eclipse.ui.internal.StartupThreading$StartupRunnable.run(StartupThreading.java:31)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4041)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3660)
at org.eclipse.ui.application.WorkbenchAdvisor.openWindows(WorkbenchAdvisor.java:803)
at org.eclipse.ui.internal.Workbench$31.runWithException(Workbench.java:1566)
at org.eclipse.ui.internal.StartupThreading$StartupRunnable.run(StartupThreading.java:31)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4041)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3660)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2537)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2427)
at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:670)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:663)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574)
at org.eclipse.equinox.launcher.Main.run(Main.java:1407)

After some searching on the web, I found out that the recently installed PHPEclipse was the culprit. It seems PHPEclipse intereferes with starting AJDT which in turn prevents Display from working.

Since I rarely work with PHP anway, I just uninstalled PHPEclipse.

In many cases, the desire to adapt the codon usage of a given gene is the motivation to go for a synthetic gene. However, more often than not important principles of codon bias are ignored in the gene design process. This short article has been written to clarify some of the issues arising in codon optimization.

Most biologists take for granted that individual species have a more or less distinct codon bias, and that in order to express a gene efficiently, the gene should follow that same codon bias.

As a first approximation, this is true, and it works surprisingly well in many organisms. For instance, genes with a codon frequency matching that of Escherichia coli, usually show very good expression yields as compared to non-adapted genes from foreign organisms.

However, the relationship is not as direct as it may seem. First, the pool of tRNA molecules often correlates with the codon bias, but not perfectly. And while it can be assumed that diffusion of tRNAs to the ribosome is one important choke point for protein synthesis, sometimes other factors are much more important, in particular the folding of the nascent protein chain.

Speaking of which: In several instances, it could be shown that a protein domain will only fold correctly, if the remaining part of the protein is absent. Therefore, a brief translation arrest is required in order to allow for the folding of such a domain. One way of achieving such a delay is to incorporate rare codons. This shows that low frequency codons are sometimes not only desirable but essential for the production of a correct protein.

And second, some organisms don’t show much of a codon preference at all. It seems there are species which aren’t very picky about the codons they process in protein synthesis. In such cases, blindly optimizing against a more or less random average codon usage will not do much good. The difficulty is knowing whether a particular organism belongs to this group or not (but see below).

Now what does this mean for my protein? If such kinetic translation data is not available (and as Murphy has it, it never is for your protein), the best educated guess is still to go for high abundance codons. Which brings me to the next point: How can the optimal codon frequency be determined? Well, the answer isn’t as obvious as it seems. The very useful Kazusa codon usage database lists the codon frequencies of virtually all organisms found in Genbank. However, care must be taken to interpret the data correctly.

First, the codon usages of many organisms are based on very few coding sequences. If a codon usage is derived from, say, 7 CDS, it really isn’t very meaningful. In such cases, it is more reliable to move up the phylogenetic tree and look for cosely related organisms for which more data is available.

Second, keep in mind that the Kazusa database averages over all found CDS, treating all of them equal. Now, for many organisms the available CDS have a strong bias, due to preferences of the researchers annotating them. And even if that weren’t the case, clearly not all CDS are created equal: The codon bias of a rarely expressed regulatory gene cannot be compared to that of a constitutively produced housekeeping protein.

Upon closer inspection, it turns out that many weakly or unregularly expressed genes have in fact a codon usage that deviates considerably from the ‘consensus codon usage’ of their organism. It seems on top of a natural evolutionary drift of these genes which are under weak selection pressure for high expression yields, nature sometimes deliberately lowers the expression level of such genes by picking rare codons.

So it would be a good idea to go for abundant and strongly expressing genes only. However, even that strategy can fail, as some organisms seem to have two or more distinct codon usages for highly expressed genes. In other words: Their housekeeping genes segregate into two clusters, each with a distinct codon usage. Averaging over both clusters would yield an invalid codon usage table.

So what are the options if you need high expression yields for a synthetic gene? The good news is that Entelechon’s bioinformatics has strong tools to support a sound and solid codon optimization. First, if the expression yield of the gene is very important, we can perform an in-depth analysis of the genome of the target organism. This includes looking for CDS, analyzing their relevance, clustering them according to similar codon usage, and looking up expression data on the genes (where available). This results in a high quality ‘personal codon usage table’ which will usually lead to very good expression yields. We call this service Codon Census.

Second, a good correlate of the optimal codon usage is often the codon bias of ribosomal genes. Therefore, we can identify ribosomal genes for your target organism (if it has been sequenced and annotated to a reasonable degree) and build a codon usage table from these genes. Although their number is relatively small, the resulting codon usage table works quite well in most cases. Also, this will usually indicate whether the organism at question has a codon bias at all. Comparing the ribosomal genes against an average of the complete genome or random samples will provide this essential information.

Keep in mind that gene optimization isn’t just about codon usage. A number of other important factors, such as mRNA secondary structure, splice sites, mRNA destabilizing motifs, and repeats play a crucial role as well. Therefore, Entelechon uses an advanced multi-objective optimization algorithm to improve all relevant features of a given gene during optimization, thus helping you to get the best out of your custom gene synthesis.

Ok, so today one of us upgraded the dependency to log4j from 1.2.9 to 1.2.16. No big thing, right? Wrong. Wham – we ran the otherwise rather useful Maven Eclipse plugin (which adds references to Maven dependencies to an existing Eclipse project configuration), and lo and behold, no log4j was to be found in the project’s referenced libraries.

What gives? Well, it took us the better of a whole working day to get behind the problem: Turns out log4j became an OSGi plugin in version 1.2.16. Which by itself isn’t a big problem. However, we just so happen to work on an Eclipse PDE project, and Eclipse PDE projects – as most of you know – are based on OSGi. The Maven Eclipse plugin has a nice configuration switch, aptly called ‘PDE’, which – if turned on – tweaks the configuration of an Eclipse project so that it is a correct PDE project.

Turns out the plugin tries to be just a tad too smart: When it encounters a dependency which is an OSGi plugin (as announced by the MANIFEST.MF file in the JAR archive), it assumes that we have already added that dependency to our Eclipse target platform – after all, what’s the point of building on OSGi if you don’t manage your OSGi dependencies the intended way?

Well, you might reply, what’s the point of using a dependency resolution system like Maven if it fails halfway through just because it thinks someone else ought to handle *some* dependencies. Duh!

So, we gave it a try to teach the Maven Eclipse plugin a new trick: We downloaded the source from the Maven subversion repository into a new Eclipse project, ran the Maven Eclipse plugin on itself and had a working and error-free compiled project. Nice. Now we looked for the code that so cleverly omitted OSGi plugins from the classpath. It was quickly found: The classes EclipseClasspathWriter and EclipseProjectWriter create – who would have guessed – the files .classpath and .project respectively.

And indeed they contain if statements which check for OSGi compliance and skip creating a symbolic link and a classpath entry. The rest was smooth sailing: Add a parameter that turns off this behaviour, add the appropriate conditionals based on the parameter, install the new plugin into our local maven repository (mvn install), and we are good to go.

We of course renamed the group and artifact ID, and instead of

mvn eclipse:eclipse

we now have to do

mvn [groupId]:[artifactId]:[version]:eclipse

Wew!

Als Unternehmen, das u.a. Gensynthese anbietet, müssen wir sicherstellen, dass es sich bei eingehenden Bestellungen für Gene nicht um gefährliche Sequenzen handelt, etwa solche, die Toxine codieren. Das machen wir mit Hilfe einer selbst entwickelten Screening-Software. Gleichzeitig arbeiten wir seit längerem mit der Universität Berkeley zusammen bei der Entwicklung einer Datenbank für Virulenzfaktoren (das sind Gene, die die Virulenz oder Pathogenität von Krankheitserregern vermitteln) namens VIREP (“virulence factor information repository”).

Beides wollen wir nun zusammenführen, d.h. es soll möglich sein, beim Screening Treffer in der Virulenzfaktordatenbank automatisch angezeigt zu bekommen. Umgekehrt soll es möglich sein, Gensequenzen aus dem Screening in der Virulenzfaktor-Datenbank abzulegen. Das Ganze wird ‘etwas’ erschwert dadurch, dass unsere Screeninglösung eine Webanwendung auf Basis von Java und Tapestry ist, während es sich bei VIREP um eine Lösung handelt, die auf Plone und Zope aufsetzt. Damit sind wir in der Python-Welt.

Java und Python verstehen sich ja an und für sich ganz gut, aber zwei eigenständige Webanwendungen miteinander zu ‘verheiraten’ ist dann doch nicht so einfach. Es wird vmtl. auf ein Webservice-Interface hinauslaufen. Mal sehen.

…mit einem Interessenten für unsere Stelle in der Bioinformatik. Die Frage war, ob wir auch ‘normale’ Informatiker nehmen würden. Na klar tun wir das. Die Stelle hat ihren starken Schwerpunkt in der Client-Server Softwareentwicklung. Konkret geht es um das schon unten angesprochene Projekt auf der Basis von Eclipse RCP in Kombination mit JEE, also z.B. Glassfish oder Jboss (im Moment ist JBoss der Favorit – Glassfish hat offenbar noch ein paar Kinderkrankheiten, die die Integration in einen RCP-Client nicht ganz leicht machen).

Das ist natürlich genau passend für normaler Informatiker und Softwareentwickler. Allerdings haben wir natürlich diverse biologische Fragestellungen und Aspekte zu berücksichtigen, so dass Interesse und Affinität zur Biologie vorhanden sein sollten. Ist natürlich alles lernbar, aber die Erfahrung zeigt, dass man Biologie ganz schön unterschätzen kann und die Sachverhalte im Detail erstaunlich verwickelt sein können.

Habe mir neulich mal das API für Google Android angesehen. Nachdem wir ja bei Entelechon fast ausschließlich in Java entwickeln, war der Einstieg kein Problem. Im Gegenteil: Beeindruckend, wie ähnlich das Ganze zur ‘normalen’ Anwendungsentwicklung unter Java ist, und wieviel Features Google in das System gesteckt hat. Eine einfache GUI aufzubauen, ist überhaupt kein Problem, und das Konzept der Intents und Activities sorgt dafür, dass alles schön modular und gekapselt bleibt.

Auch nicht schlecht ist der Emulator, der für den Anfang mehr als ausreicht. Im Detail nervt dann aber, dass viele Hardware-Features nicht emuliert werden. Die Kamera-Emulation ist mehr als dürftig (es gibt nur eine Defaultanimation, viele Kamera-Features funktionieren überhaupt nicht, z.B. das Abfragen der verfügbaren Bild-Ausmaße), Beschleunigungsmesser oder Kompass gibts nicht, GPS zu simulieren ist sehr mühsam.

Naja, und richtige Android-Hardware zu kaufen, nur um die Sache mal auszuprobieren, ist doch ein wenig teuer. Vielleicht ergibt sich ja mal die Gelegenheit eines günstigen Gebrauchtkaufs. Dann hätte ich schon ein paar Ideen für bioinformatische Android-Anwendungen…

So, wir haben begonnen, uns im Rahmen eines Entwicklungsprojektes näher mit Eclipse RCP zu befassen. Im Prinzip ja eine feine Plattform, allerdings ist es offenbar gar nicht so leicht, RCP mit anderen Frameworks zu kombinieren. Zum Beispiel hat sich herausgestellt, dass eine Integration von Eclipse RCP mit Glassfish auf erhebliche Probleme stößt.

Konkret möchten wir einen RCP-Client verwenden, um per RMI auf einen JEE-Server zuzugreifen. Der JEE-Server soll in diesem Fall Glassfish sein. Nach einem erheblichen Setup-Aufwand hat sich dann herausgestellt, dass man zwar ein einzelnes EJB ansprechen kann, aber kein zweites. Sobald ein zweites (der gleichen oder einer anderen Klasse) nachgeschlagen wird, schlägt der Lookup fehl.

Keine Ahnung, warum. Offenbar scheint das Problem in einschlägigen Kreisen bekannt zu sein, da aber kaum jemand RCP mit Glassfish kombiniert (und nur dann tritt das Problem auf), ist auch noch niemand auf eine Lösung gekommen. Wir übrigens auch nicht.

Tja, nächster Schritt: Wir versuchen’s mal mit JBoss statt Glassfish…

So, nach langer Zeit war es mal wieder so weit – wir haben unsere Gentoo-Server auf den aktuellen Stand gebracht. Nachdem das letzte emerge world schon eine Weile her war, gab es jede Menge Updates. Im Großen und Ganzen hat das auch wunderbar funktioniert, nur bei den Konfigurationsdateien hat mich meine Schlampigkeit einige Nerven gekostet.

Wenn ein Paket-Update eine geänderte Konfigurationsdatei hervorbringt, ist Gentoo aus guten Gründen sehr vorsichtig und fügt die Änderungen nicht einfach in die vorhandenen Konfigurationsdateien ein. Stattdessen legt es eine neue Kopie der Konfigurationsdatei an, die man dann von Hand mit der vorhandenen abgleichen muss. Dabei macht einem das Tool etc-update das Leben deutlich leichter:

Mit etc-update läuft die Sache fast von alleine. Es listet alle geänderten Dateien und bietet an, automatisch die alte beizubehalten, die neue zu übernehmen, oder beide Zeile für Zeile zu mergen. So weit, so gut. Leider ist das Arbeiten damit so problemlos, das man gerne mal merged, ohne genau hinzuschauen. Vor allem, wenn man noch Dutzende von Konfigurationsdateien vor sich hat.

Hier rächt sich natürlich auch die Konfigurationsphilosophie von Linux: Selbst wenn man jahrelang mit dem System arbeitet, gibt es immer noch Konfigurationsdateien, vor denen man recht ratlos steht. Da ist die Versuchung natürlich groß, erstmal Änderungen zu übernehmen.

Im konkreten Fall hatte ich unser CVS, winbind und Apache gründlich aus dem Tritt gebracht. Nach ein paar Stunden war alles wieder so, wie es sein soll, aber die Sucherei hat Nerven gekostet. Moral: Ein sorgfältiges etc-update geht allemal schneller als die Fehlersuche danach…