chem-bla-ics: May 2010

My OpenTox Workshop contribution: Linking explicit and implicit knowledge

Please find below the views I have expressed at the OpenTox Workshop in the nice Potsdam area near Berlin:

Linking explicit and implicit knowledgeView more presentations from egonw.

More on the meeting later.

May

CDK 1.3.5

A lot of changes in this release: the SMSD code (see doi:10.1186/1758-2946-1-12), removed outdated code (force field, R-CDK bridge), SMILES @ and @@ chiralities reading, a new IChemObjectBuilder interfaces, and several new features in the MDL IO classes.

May

PMD code checking: checking for programming against CDK interfaces

I wrote recently about programming against interfaces, which led to some discussion. Rajarshi commented:patch 2 seems to replace usage of Molecule with Molecule, rather than IMoleculeNow, this particularly problem was Eclipse being overly active cleaning up the imports, but we reached the point that it is actually interesting to have PMD warn about these issues. PMD is a cool piece of software used by the CDK project for a long time one.

May

Cleaner CDK Code #6: set the CDKException's cause Exception

For about two weeks now, I am working on fixing a bug in the nonotify module: they classes were still sending around change events. I decided to finally do it the proper way: sending around change events is extra functionality, so the data module should extend the nonotify module and not the other way around, as in CDK 1.2 and CDK 1.3 up to now. There was a dirty hack in place, introducing a boolean indicating it should send events or not, but that turned out to be insufficient.

May

CKAN 1.0: A major contribution to Open Knowledge

Peter informed about the CKAN 1.0 release. I browsed the 27 chemistry packages, and saw for example BODR show up:

The database of packages is community based, and you can simply log in with an OpenID. This allows me to updated some outdated and add missing information.

As mentioned, the list contains 27 packages, out of a total of almost 1000. So, not so much chemistry there yet, but that's something we are getting used to. Worse even, is that of these 27, only a small subset is Open.

May

Cleaner CDK Code #5: develop against interfaces

Rajarshi is at the EBI (or at least was yesterday), talking about his rcdk package (his excellent slides). One slide is about how to create a new atom; he mentions not to use new Atom() but the DefaultChemObjectBuilder instead (slide 73). I do not entire agree with the message given.

Develop against interfaces

The slide seems to favour the DefaultChemObjectBuilder, but there like are more suitable builders for a particular application.

May

Three ACS-RDF sessions

It has been a while since I gave an update on the ACS-RDF session in Boston. Things are settling in, and it seems there will be three sessions, each with an approximate theme. Each session will have five talks, of which one will be extended, where the speaker will be invited to set the context of the theme.

May

My favourite chemistry things

Yeah, it's my turn. Standing on the shoulders of ChemJobber, Azmanam, and ScienceBase, here's list of things I like about chemistry. To put things into perspective first, a bit, I note that ChemJobber and Azmanam focused on wet-lab chemistry, and David on fancy molecules. Now, I am a theoretical chemist, and was thinking on what to orient the things I like, and on how general to make them. This meme is not easy, you now. But here goes:

1.

May

How to use GitHub for [CDK|Bioclipse] code review

Triggered by posts in the past three days, I though about writing up a short tutorial on how to perform code review for existing code on GitHub. Therefore, this applied to CDK and Bioclipse source code, many but will work for any project hosted in GitHub. Even if it is not, you could consider putting up a copy there yourself. This example will demonstrate the procedure on CDK functionality in Bioclipse in the bioclipse.cheminformatics repository.

May

GitHub simplifies code review and leaving comments

Posted via email from Egon's posterous

The workflow here is that the proposed patch gets uploaded to a GitHub branch or fork; the code reviewer is made aware of the patch, and goes to the commit page on GitHub, and hovers over the line numbers and clicks the 'Add comment' button and leaves a comment; the reviewer informs the author, and the author updates his patch.