MedWorm.com provides a medical RSS filtering service. Over 5000 RSS medical sources are combined and output via different filters. This feed contains the latest items from the 'Inforbiomatica' source. Sat, 16 Aug 2008 14:43:05 +0100 http://www.moseshohman.com/blog/2008/07/09/pair-microarrays/ Yesterday I met with folks at Lawrence Berkeley labs. The PI entered the room, full of energy and clearly ducking briefly out of the fray to speak with us. Part of the discussion revolved around microarray experiments. We’ve all heard about how notoriously difficult it is to reproduce microarray experiments. People have proposed minimum information standards (really they’re guidelines) to combat this problem, and we’ve also all heard that often these standards aren’t enough. Even if people are following the guidelines, inevitably a crucial piece of information isn’t obviously critical and therefore isn’t communicated. The PI noted that he has seen it to be helpful when more than one lab conducts an experiment, so that each can help the other avoid finicky and/or tacit experimental conditions that would prevent others from reproducing their results. I have wondered for some time (and for the case of microarrays in particular) whether the practice of “pair programming” that we use in software development would be more helpful than minimum information standards to increase the reproducibility of complex experiments. The problem with this, as the PI pointed out, is that duplicating every experiment can get expensive, and in the world of soft money (especially today’s world), people are always looking for ways to make the research dollar go farther. The possible long term efficiency of duplicating some efforts to increase data value and reduce a tendency to go down blind alleys might not be easy to quantify, and thus not easy to weigh quantitatively against the immediate penalty of “getting half as much work done”. (That’s certainly true in software.) The PI pointed out that even if direct duplication was too expensive, he still advocated some kind of collaboration on experiments. In particular he advocated getting people together in the same room to look at the experiment together as it was being performed, so that the collaborator might catch important things that weren’t immediately apparent to the person performing the experiment. This, at most, only costs a small amount of travel funds. I asked the PI if others shared his views, and he said that most of the larger microarray efforts had some sort of distributed work going on, but he wasn’t sure that this idea had been formalized anywhere. I’m interested in this not only because of its parallel with software work, but also because I work for a company focused on facilitating collaborative science. I’m very interested in the different forms that scientific collaboration can take, and how best to help them along. (Source: Inforbiomatica) Inforbiomatica blogs http://www.medworm.com/rss/comments.php?id=1596485 Wed, 09 Jul 2008 09:46:13 +0100 1596485 http://www.moseshohman.com/blog/2008/07/06/dtrace-predicate-hack/ One of the things I keep wanting in DTrace’s D language but isn’t there (right?) is a richer set of string comparison functions. Ideally I want full regular expression functionality, so that I can predicate actions on, say, regex matches of a class and/or method name. For instance, a while back, while profiling some Java, I wanted to only count time spent in methods of classes that belonged to a particular package (org/apache/solr) or to its subpackages. There is no “starts with” string operator in D. However, the following did the trick: hotspot$target:::method-entry /(self->class = copyinstr(arg1)) != NULL && self->class >= "org/apache/solr/" && self->class < "org/apache/sols"/ { /* action goes here */ } A little ugly, but it worked. The choice of “org/apache/sols” as the upper bound was somewhat arbitrary. (Source: Inforbiomatica) Inforbiomatica blogs http://www.medworm.com/rss/comments.php?id=1593894 Mon, 07 Jul 2008 00:23:15 +0100 1593894 http://feeds.feedburner.com/~r/inforbiomatica/~3/328427037/ One of the things I keep wanting in DTrace’s D language but isn’t there (right?) is a richer set of string comparison functions. Ideally I want full regular expression functionality, so that I can predicate actions on, say, regex matches of a class and/or method name. For instance, a while back, while profiling some Java, I wanted to only count time spent in methods of classes that belonged to a particular package (org/apache/solr) or to its subpackages. There is no “starts with” string operator in D. However, the following did the trick: hotspot$target:::method-entry /(self->class = copyinstr(arg1)) != NULL && self->class >= "org/apache/solr/" && self->class < "org/apache/sols"/ { /* action goes here */ } A little ugly, but it worked. The choice of “org/apache/sols” as the upper bound was somewhat arbitrary. (Source: Inforbiomatica) Inforbiomatica blogs http://www.medworm.com/rss/comments.php?id=1582979 Mon, 07 Jul 2008 00:23:15 +0100 1582979 http://feeds.feedburner.com/~r/inforbiomatica/~3/328420670/ It’s a question we face as test-driven ruby programmers: Should we use mock objects or real objects in our tests? Both approaches have trade-offs, and their biggest downsides both have to do with wasting programmer time. If you test with real objects, then your tests run slowly (especially if you use an ORM that binds your domain objects tightly to the database like ActiveRecord). Your tests hit the database, and this is slow. There are other sources of slowness, but nothing has anywhere near as great an effect as hitting the DB. If you test with mock objects, once your app has any kind of complexity, your refactoring and test writing processes become slow. This is not immediately apparent when you start using mock objects. But as you start writing more and more code, eventually you start having to come up with a crazy number of mock expectations just to test some of your methods. It is true that this is good feedback that the class you’re testing presents too complex an interface to other collaborating objects, or that it collaborates with too many objects, etc. What starts simple will eventually become too complex, and at some point you’re going to need to refactor. More insidious than this, however, is the effect this web of mocks you’ve wrapped yourself in has on refactoring. You don’t notice how thoroughly you’ve painted yourself into a corner until you want to refactor some ugly aspect of a core class that collaborates with many objects in your system. Suddenly all of those collaborating objects’ tests break because they expect certain method calls from this core object. These tests break because you’ve changed a method signature, a method name, or even worse just an implementation, because no matter what those BDDers tell you, if you test with mocks, to too great a degree that means you’re testing implementation, not behavior (or is that behaviour). So, now you have to go through all of those mock-based tests and “correct” them, i.e. change their expectations so that they fit the new method name/signature/implementation. This is horrible. The whole point of tests during refactoring is to verify that your refactoring hasn’t changed the behavior of the system (that being half of the definition of refactoring). The tests should pass before you refactor, and they should pass after you refactor. Not only does this break the fundamental refactoring process, it also can take a lot of time, because you have to remember the context of each of those test cases that you have to fix. You can do something about slow running tests that hit a database (in extreme cases you can use a faster in-memory database, or even parallelize your tests). Of course they won’t run as fast as they would if they didn’t hit a database, but in my opinion it’s something you can live with. Dav Yaginuma has a good suggestion for what to do with this time: Go write that email you need to write, go take the bathroom break, go walk around the office and stretch your legs. It’s not like that’s really wasted time. It is wasted time, however, if you’re sitting there squinting at the screen fixing all of your mock expectations. You can’t do anything else with that time. I’m kind of half-convinced now that people who advocate the heavy use of mocking either have really nice IDEs that make fixing the expectations a breeze, or they don’t refactor. And if they’re using Ruby that means they don’t refactor. Ok, tongue out of cheek. Seriously, I’d love to hear from folks who have used and continue to use mocks heavily on long running projects, to hear how they handle the refactoring issue. I have pretty much sworn off mocks except in old-school traditional cases (”mocking out an external dependency too expensive to call directly”) because of it. (Source: Inforbiomatica) Inforbiomatica blogs http://www.medworm.com/rss/comments.php?id=1582980 Mon, 07 Jul 2008 00:22:36 +0100 1582980 http://feeds.feedburner.com/~r/inforbiomatica/~3/240057021/ We are gearing up to do some profiling/performance improvement at work, and we use MacPorts (mostly at my stubborn insistence) to install Ruby on our OS X dev boxes. Unfortunately, the MacPorts version of Ruby is not DTrace-enabled, so we were faced with the decision to either go with the Apple-installed Ruby or not use DTrace. Fortunately, there was a third option. I spent some time massaging Joyent’s Ruby DTrace patch so that it would compile with Apple’s version of DTrace (subtly different from Solaris’s), and so it would play nice with the other patches in the official Ruby MacPort distribution. Anyway, long story short: you can get it via my newest RubyForge project, rubyport-dtrace. You can install either from the tarfile or by checking out from Subversion, see the instructions in the distribution. Why I like MacPorts: I like being able to cleanly remove software I install. I also like that I can compile Ruby with DTrace and other patches that I might want (such as the Railsbench GC patch, which I’m also working in to the rubyport-dtrace (dare I call it) code, it might already work but I haven’t tested it). (Source: Inforbiomatica) Inforbiomatica blogs http://www.medworm.com/rss/comments.php?id=1251788 Thu, 21 Feb 2008 07:38:11 +0100 1251788 http://www.moseshohman.com/blog/2007/11/11/51 I recently reread the original Z factor paper (Zhang et al). The Z factor is a measure of assay reliability and comes in two flavors: the Z’ factor, based entirely based on controls (those with and without the desired effect); and the Z factor, based on experimental data compared with the controls that should have the desired effect. Rereading a paper months later often makes you wonder whether you read the paper at all the first time. This reading really clarified for me what the Z factor is, that it is not just for high-throughput screening, and raised a number of questions (especially after discussion with colleagues) not addressed in the paper. The Z factor is ratio of the “separation band” of the data to the assay dynamic range. A picture helps: where μ+ is the mean of the positive controls (in this case the controls with desired effect), μs is the mean of the data, σ+ is the standard deviation of the positive controls, etc. The assay dynamic range in this diagram is μ+ - μs. The screening window is then (μ+ - μs) - (3σ+ + 3σs), and the ratio of this to the dynamic range is the Z factor = 1 - (3σ+ + 3σs)/(μ+ - μs). (more…) (Source: Inforbiomatica) Inforbiomatica blogs http://www.medworm.com/rss/comments.php?id=1019390 Sun, 11 Nov 2007 23:54:44 +0100 1019390 http://www.moseshohman.com/blog/2007/08/08/50 From the RSpec documentation: It is very tempting to use before(:all) and after(:all) for situations in which it is not appropriate. before(:all) shares some (not all) state across multiple examples. This means that the examples become bound together, which is an absolute no-no in testing. You should really only ever use before(:all) to set up things that are global collaborators but not the things that you are describing in the examples. Well-known conventional wisdom says that different test cases (in spec-speak, “examples”) should not depend on one another for state, should be runnable in any order, etc. I certainly agree with this wisdom in general, but I think there’s one case where this rule should be broken. We’ve been writing a fair number of Selenium RC tests lately for our app, using RSpec to drive Selenium RC. When writing integration tests like this, each example (in test speak, “test method”) is often a very long script with lots of shoulds/asserts in it. We lose the nice descriptive power of small examples with specific, descriptive text, and instead are faced with a choice between vague and high-level example descriptions and really long example descriptions using ugly here documents that can easily fall out of synch with the example code. Instead, we want to be able to do something like this: describe "A user customizing a car" do use_chained_examples before(:all) do @model = models(:spiffy) log_in go_to_car_customization_start_page end it "should first be required to select car model" do page_title.should == "Select a model" droplist("model_id").should be_present droplist("model_id").options.should == [ "(Please select a model)", models(:spiffy).name, models(:sporty).name ] droplist("model_id").selected_value.should == "" droplist("model_id").select(@model.id) click_next_button end it "should then be required to select paint color" do page_title.should == "Select #{@model.name} color" droplist("color_id").should be_present # etc. end end A before(:each) block can be used to reset the page between each example, which we’ve found useful when testing a bunch of validations or something similar. Note too that using chained examples is not the default behavior, and must be explicitly specified by the developer, who should “know what they are doing” if they do this. Anyway, obviously we did figure out how to make this happen, and after we’ve refined it a bit if people are interested we’ll open source our selenium rspec stuff as a plugin. Note that our selenium specs use a different spec_helper.rb than the rest of our normal specs, so we’re keeping the ability to chain examples out of our standard specs, as conventional wisdom would recommend. Let me know what you think. (Source: Inforbiomatica) Inforbiomatica blogs http://www.medworm.com/rss/comments.php?id=1018926 Sun, 11 Nov 2007 02:15:22 +0100 1018926 http://feeds.feedburner.com/~r/inforbiomatica/~3/142205595/50 From the RSpec documentation: It is very tempting to use before(:all) and after(:all) for situations in which it is not appropriate. before(:all) shares some (not all) state across multiple examples. This means that the examples become bound together, which is an absolute no-no in testing. You should really only ever use before(:all) to set up things that are global collaborators but not the things that you are describing in the examples. Well-known conventional wisdom says that different test cases (in RSPec-speak, “examples”) should not depend on one another for state, should be runnable in any order, etc. I certainly agree with this wisdom in general, but I think there’s one case where this rule should be broken. We’ve been writing a fair number of Selenium RC tests lately for our app, using RSpec to drive Selenium RC. When writing integration tests like this, each example (in test speak, “test method”) is often a very long script with lots of shoulds/asserts in it. We lose the nice descriptive power of small examples with specific, descriptive text, and instead are faced with a choice between vague and high-level example descriptions and really long example descriptions using ugly here documents that can easily fall out of synch with the example code. Instead, we want to be able to do something like this: describe "A user customizing a car" do use_chained_examples before(:all) do @model = models(:spiffy) log_in go_to_car_customization_start_page end it "should first be required to select car model" do page_title.should == "Select a model" droplist("model_id").should be_present droplist("model_id").options.should == [ "(Please select a model"), models(:spiffy).name, models(:sporty).name ] droplist("model_id").selected_value.should == "" droplist("model_id").select(@model.id) click_next_button end it "should then be required to select paint color" do page_title.should == "Select #{@model.name} color" droplist("color_id").should be_present # etc. end end A before(:each) block can be used to reset the page between each example, which we’ve found useful when testing a bunch of validations or something similar. Note too that using chained examples is not the default behavior, and must be explicitly specified by the developer, who should “know what they are doing” if they do this. Anyway, obviously we did figure out how to make this happen, and after we’ve refined it a bit if people are interested we’ll open source our selenium rspec stuff as a plugin. Note that our selenium specs use a different spec_helper.rb than the rest of our normal specs, so we’re keeping the ability to chain examples out of our standard specs, as conventional wisdom would recommend. Let me know what you think. (Source: Inforbiomatica) Inforbiomatica blogs http://www.medworm.com/rss/comments.php?id=789226 Thu, 09 Aug 2007 02:21:42 +0100 789226 http://feeds.feedburner.com/~r/inforbiomatica/~3/137878201/48 With the advent a few years ago of test-driven development (TDD, a.k.a. “test-first” development), people started parroting the phrase “TDD isn’t about testing, it’s about design” like a mantra. As is often the case when a phrase is repeated too many times, eventually (for some people anyway) this seems to have come to mean “(developer) testing isn’t about testing, it’s about design”, i.e. the testing part of developer testing isn’t that important. This is wrong. One of the key practices that enables agile software development is the production and maintenance of a robust, thorough set of automated tests written and run often by developers. This set of tests allows developers to make frequent and significant code changes without causing unintended bugs in related code. This practice fundamentally enables software teams to “embrace change”. It is true that writing code test-first adds another dimension to the benefits of the practice of automated testing, by focusing the developer on the design/interface of their code before they write the actual code. Thus, it is true that TDD, considered as an enhancement to plain old automated testing, is primarily an enhancement that addresses the issue of design. Nevertheless, the automated testing part of TDD is still very much about testing, testing that is a very important part of an agile team’s toolbox. Corollary: The primary criterion for evaluation of any approach to automated developer testing should be its ability to provide this robust, thorough test harness that protects against regression. (Source: Inforbiomatica) Inforbiomatica blogs http://www.medworm.com/rss/comments.php?id=761534 Fri, 27 Jul 2007 08:08:24 +0100 761534 http://feeds.feedburner.com/~r/inforbiomatica/~3/115396028/47 Two quick things we’ve learned about migrations at CDD: Avoid using your model objects in your migrations, e.g. stuff like Group.create!(:name => "Watson Lab"). The problem with this is that later you might add a required field to your model, and then this migration will throw an exception. Occasionally you need some logic from a model in a migration, but if at all possible I’d suggest exposing that logic in a way that doesn’t require creating or loading model objects in your migration itself. The migration should just know about SQL, nothing else. Say you branch your code base for a release, and you anticipate needing to support that branch for any length of time. Sometimes you’ll need to address an issue in the production code that requires another migration. What we’ve found works best with ActiveRecord migrations is: In the trunk, delete all existing migrations when you branch. Dump a version of the branch schema, and make that migration #1 (001_production_branch_schema.rb) in your trunk. Start your next trunk migration several numbers higher than your last migration on the production release branch. So, if your last migration on the branch was 40, start 40+N, where N gives you enough cushion to accommodate any additional migrations needed for the branch until your next release. Any time you add another migration to the branch, in the trunk replace 001_production_branch_schema.rb with a new dump of your branch schema. Kind of a hack, but it works better than anything else we’ve come up with. My former colleague, Rhett Sutphin, took a different approach to this problem when he wrote a Java/Groovy port of migrations called bering (to which I minimally contributed in its early stages). In bering, migrations are specific to a particular release. Each release is numbered and gets its own separate migration directory, and migrations start at one again for each new release. (Source: Inforbiomatica) Inforbiomatica blogs http://www.medworm.com/rss/comments.php?id=620196 Wed, 09 May 2007 18:01:02 +0100 620196 http://feeds.feedburner.com/~r/inforbiomatica/~3/114946432/45 Thinking more about the issue mentioned in my previous post, I’ve come up with a possible set of forces that push you in one direction or another, that is toward organizing your specifications around method behavior vs. organizing around object state behavior or vice versa): Clearly, if you’re specifying procedural code (Rails helpers, many class-level methods), there’s no state, and you should organize your specifications around methods. If your object has more attributes/more states and fewer methods/less business logic, then it’s probably clearer to organize your specifications around the behavior of the methods. If, however, the object has fewer attributes and more methods/business logic, then it is clearer to organize around the various object states, each with a number of specifications of the behavior of each method in that state. This is probably somewhat debatable, but it might be true. Perhaps there’s a better characterization of this force. Definitely less code if you follow this approach, and less code (expressing the same meaning) is usually clearer. It also seems to me that fewer contexts are usually easier to understand, because there is less information to parse. If your objects have states that are expensive to set up (i.e. lots of mock expectations), then it’s better to organize specifications around those states. However, this might also be a code smell that your classes should be more loosely coupled. Another way to think about this is in terms of how each spec reads. Dan North in his Introducing BDD article talks about formulating specifications using the language pattern: “Given X, when Y, then Z”, so for example, “Given an assay criterion with nothing specified, when asked for its corresponding SQL conditions, it should return nil.” There are several ways you could express this in RSpec (leaving out the before block and the body of the spec). Organized around the object state, it would be: describe "Given an assay criterion with nothing specified" do it "should return nil when asked for its corresponding SQL conditions (:to_conditions)" do ... end end or, organized around the method: describe "When an AssayCriterion is asked for the corresponding SQL conditions (:to_conditions)" do it "should return nil if nothing was specified" do ... end end or Dustin’s hybrid approach: describe "Given an assay criterion with nothing specified, when asked for the corresponding SQL conditions (:to_conditions)" do it "should return nil" do ... end end I’m not sure that tells you which one is better, but there it is. Also, I found a couple more good links about BDD. I’ll list them and other useful stuff on general BDD I’ve found here, please let me know about any others: Separating setup from specify What’s in a story Introducing BDD Spec organization The rspec-devel mailing list archives The rspec-users mailing list archives (Source: Inforbiomatica) Inforbiomatica blogs http://www.medworm.com/rss/comments.php?id=596890 Mon, 07 May 2007 18:28:30 +0100 596890 http://www.moseshohman.com/blog/2007/05/06/38 Last August I moved out to San Francisco to join a great cheminformatics startup, Collaborative Drug Discovery, as director of software development. Two months ago (March 5th) we had our first user community meeting on open R&D for developing world disease drug discovery. It was an inspiring event, both because of the evident energy of the community and because it made it so much clearer to me how important our customers’ work is. Prof. Jim McKerrow at UCSF gave a nice overview of the scope of the work our customers face, and how collaboration (through CDD and otherwise) helps them arrive at cures sooner and more efficiently (the slides are blurry, so download them separately). We put up several other talks from the meeting on Google Video, available along with PDF slides from our website, including one by the famous medicinal chemist, Chris Lipinski, who is a member of our customer advisory board. Cool stuff. (Source: Inforbiomatica) Inforbiomatica blogs http://www.medworm.com/rss/comments.php?id=592729 Mon, 07 May 2007 02:44:35 +0100 592729 http://www.moseshohman.com/blog/2007/05/06/43 The vanilla example used in most blog posts for BDD is some incarnation of de novo domain object specification, that is, specifying the behavior of a simple domain object from scratch. David Chelimsky’s stack example is a decent online example of this sort of situation (the comments are interesting to read as well). Stack is an independent class without any collaborators, and its behavior is not extensive. This results in a state-oriented set of contexts with specifications that are very readable and give you a good idea of what Stacks do. Recently my colleague Kurt Schrader posted something in reaction to a discussion he and I had about a specification I had written. In his post he gives a simple example of de novo domain object specification, and asks (here I paraphrase) whether the example should be the method or the object in a particular state, i.e. should we describe the behavior of an object in a particular state (in his example, “A new sword”) or describe the behavior of the method Sword#sharp?. I would agree with him that in this case describing new and old swords is better than describing sharp?. However, the original specification that provoked the most recent iteration of this discussion was a bit more complex, so I’ll present it here. (more…) (Source: Inforbiomatica) Inforbiomatica blogs http://www.medworm.com/rss/comments.php?id=592730 Sun, 06 May 2007 22:24:35 +0100 592730 http://www.moseshohman.com/blog/2007/05/06/41 About two months ago at CDD we decided to start using the RSpec Behavior-driven development (BDD) framework instead of the standard Test::Unit unit-testing library. My initial interest in using RSpec was that it provided “contexts” for a bundle of tests/specifications (hereafter, “specs”), and that seemed a cleaner way to group specifications/tests than throwing everything in one big test class. Our existing Test::Unit test classes were getting very long (some with 60+ test methods if I remember correctly), and related tests were grouped just by placing them next to each other in the file, which wasn’t always maintainable/maintained. And of course, when you have sixty tests in one class, the setup method has to be too general to be used properly. So we needed to do something, and RSpec seemed like it would help. In addition, I liked how specs in RSpec read better than how a Test::Unit assertion reads, i.e. I liked assigns[:assay].should have(4).runs more than assert_equal(4, assigns(:assay).runs.size) and the like. I have to admit at the time I only vaguely knew what BDD was supposed to be about. The main thing I knew was that BDD was an attempt to change the words we use to talk about automated developer testing/specification/test-driven development (TDD), to make clearer an under-appreciated purpose of such activity, to help developers write code intentionally using better design (loose coupling, etc.). As such, BDD is less a change of practice from TDD (if TDD is practiced correctly) than a clarification of the practice. After two months using a BDD framework, I have found that while BDD does clarify high-level principles, it still leaves plenty unclear. I have been unit testing for many years now, and I’ve always felt that automated developer testing is a rich subject that takes a long time to fully appreciate, and is not a discipline that can be covered adequately by a few high-level principles. The details matter, because in most realistic testing situations there are always tradeoffs and context-specific considerations that should lead a developer to take one approach over another. That said, BDD is a significant step in the right direction. Over the next week or so I plan to write a series of blog posts examining some of these detailed contexts we’ve encountered at CDD in the context of the principles and tradeoff considerations, with the hope both that these details will be useful to others and that some more experienced BDDers out there will give us some feedback to help us make better choices about how we specify our code. Before ending this post, I’ll list some of the high-level principles, so I can refer to them over the next week: Specs should be valuable. Specs should be acceptable. Corollary of #2: Some code duplication in specs is ok; the focus should be on clarity/readability/acceptability. Specs should specify behavior not implementation (the classic interface vs. implementation distinction). Unfortunately, we’ve discovered that “behavior” is still a fairly vague term (leading to some intense discussions within our team), and what “the interface” is varies according to context. Contexts/examples should set up a particular state (of an object, etc.), and specifications should then describe the behavior that state. This is typically accomplished by setting up state in the setup method or before(:each) block, and then writing many short descriptions of behavior in separate test methods/specs. Specs should be loosely coupled to application code, so that refactoring app code doesn’t cause lots of tests to break. There is at least a hope here that by specifying behavior/interfaces you’re likely to get loose coupling as well. Specs should encourage developers to think about interface-centric, just-in-time design of their code. This is TDD/BDD’s major benefit #1. Finally, I still believe (and here I perhaps depart from some BDDers) that the other major benefit of TDD/BDD is that specs help you verify that your application code works. This is particularly true for small development teams that don’t have a ruthless army of QA people keeping a lid on bugs. Stay tuned for a specific example later today. (Source: Inforbiomatica) Inforbiomatica blogs http://www.medworm.com/rss/comments.php?id=592731 Sun, 06 May 2007 08:38:44 +0100 592731 http://www.moseshohman.com/blog/2007/04/30/39 Those of you familiar with bioinformatics might know about the Life Sciences Identifier (LSID) specification, which describes a URN-based identifier (think “primary key”) for life sciences data objects (genes, proteins, microarray experiments, radiology images, clinical trial study calendars, etc.). I learned a lot about these over my last year and a half at Northwestern during my work with caBIG, because I was heavily involved with developing the first draft proposal for the use of data object identifiers within the caBIG grid. The intended benefits of LSIDs primarily include the following: location independence — an LSID identifies a resource, not a particular data record on a particular server on the network global uniqueness — the same LSID should never be used to refer to two distinct objects local assignment — there must be some easy mechanism for data object creators to assign globally unique LSIDs to their data without the need for onerous bureaucracy permanence — once assigned, an LSID cannot be reassigned to a different object semantic opacity — data clients who use LSIDs to refer to data are not supposed to read into the substructure of the LSID and make any conclusions about what the LSID means, other than being a key for a particular data object, e.g. urn:lsid:frank:dog:38922 should not be assumed to have anything to do with Frank or his dog. data and metadata — in addition to the bytes representing the data object identified, there is a separate “channel” of information, the metadata, which can contain information about relationships between the given data object and other data objects. and…, some other stuff, see the official spec. LSIDs look like this: urn:lsid:ncbi.nlm.nih.gov:pubmed:9486653. One of the key steps in employing LSIDs on a grid (or in any network accessible way) is the deployment of some kind of resolution service, a server or set of servers that delivers the data for a given LSID to a requesting data client. Also, as a corollary of the “global uniqueness” requirement above, it is important that requesting resolution of a given LSID should always return the same set of bytes, regardless of when the resolution occurs. That is, if you assign an LSID to an object, you assign it to a specific set of bytes representing that object, and that association can never change (although the data provider might stop providing the data). This allows you to cache these objects without worrying about cache invalidation (since the bytes will never change) and more importantly enables reproducible research: a computational researcher can publish results based on a dataset identified by a bunch of LSIDs, and another researcher later can run the same computations on those same LSIDs and expect to arrive at exactly the same results. Importantly, the metadata referred to by an LSID is not required to be byte-identical, so it has a bit more flexibility to cover some important use cases, as we will see in my next post on the subject. (Source: Inforbiomatica) Inforbiomatica blogs http://www.medworm.com/rss/comments.php?id=580176 Mon, 30 Apr 2007 06:57:24 +0100 580176 http://www.moseshohman.com/blog/2007/01/05/37 At my new job we recently had to use a Rails migration to convert millions of rows of data. Unfortunately the conversion could not be done with SQL, we had to load each row and use Ruby to massage the columns. When we started testing the data conversion on a replica of the real database and measured how long the migration was going to take to complete, we realized it would take almost a week. Looking deeper, the problem proved to be the Ruby garbage collector, which according to posts I’ve read elsewhere, is optimized for short-running scripts and works hard to try to keep the Ruby interpreter’s memory footprint small by running the garbage collector very often when there are lots of objects in memory. By my own measurements it was running after converting approximately every tenth table row, i.e. hundreds of thousands of times during our migration. Stefan Kaes, the author of railsbench and the RailsExpress blog, has a patch for Ruby that affords you more control over the garbage collector via a few environment variables (essentially allowing Ruby to consume more memory on your machine in exchange for running the GC less often). I didn’t want to apply this patch to my machine (MacBook Pro) without being able to uninstall it, so I wrote a MacPorts portfile based on the one for Ruby 1.8.5. It installs Ruby 1.8.5-p2 and applies Stefan’s GC patch. Since 1.8.5-p2 includes the CGI denial of service fix that is applied as a patch in the 1.8.5 portfile, I removed that patch (ruby-1.8.5-cgi-dos-1.patch). I installed the portfile, and this turned a week of running time into a little less than a day. So, thanks, Stefan. If you’d like to try out the portfile yourself, you can download it here. The gzipped tarfile includes the portfile, required patch files distributed with the original portfile plus the railsbench patch renamed (to patch-gc.c) so that MacPorts can use it properly. If you try it out, please let me know how it works for you. Note: Just as I was about to publish this, I noticed that about two hours ago MacPorts has released an official 1.8.5-p12 portfile (what happened to p3 through p11?), however it of course does not contain the GC patch. I’ve updated my Portfile based on this new one. Also, instead of installing the gc patch by default, I’ve included it as a variant called railsbench. So, once you’ve unpacked the tar into your local port repository, added that repository to /opt/local/etc/ports/sources.conf, and “portindex”ed the local repository, all you have to do is sudo port install ruby @1.8.5-p12 +railsbench, that last part being the variant. See the INSTALL file in the tarball for more detailed instructions. (Source: Inforbiomatica) Inforbiomatica blogs http://www.medworm.com/rss/comments.php?id=487083 Fri, 05 Jan 2007 08:24:41 +0100 487083 http://www.moseshohman.com/blog/2006/10/03/36 I’ve been pretty busy over the last several months, which has left little time for blogging. Since June I have moved to San Francisco with my fiancee, found an apartment (no small affair) and started a new job with a small cheminformatics startup as director of software development. So far so good. Probably more about that later. The two posts below I wrote a long time ago but for some reason never published. (Source: Inforbiomatica) Inforbiomatica blogs http://www.medworm.com/rss/comments.php?id=487084 Tue, 03 Oct 2006 22:33:55 +0100 487084 http://www.moseshohman.com/blog/2006/10/03/33 A wonderful passage from page 56 of Lab Dynamics, a book recommended to me by a biologist colleague: If you are a technical professional, it would probably not come as a big surprise to learn that some people in your organization think you are hard to manage or are a poor manager. In the private sector, scientists are often sent to management training seminars. These typically teach participants to set goals and objectives, give feedback, do evaluations, and manage projects. These are all important skills and worth learning. However, your success at applying these skills is not determined by how well you know them or even how long you use them. It is determined by how well you understand yourself, and how well you relate to and respond to the people to whom you need to apply them. If you are oblivious to your own motivations and feelings, you probably do not pay attention to or understand the motivations and feelings of those you manage. If you interpret silence as agreement, repeated absences as laziness, and failure to follow instructions as forgetfulness, you cannot be an effective manager. (Source: Inforbiomatica) Inforbiomatica blogs http://www.medworm.com/rss/comments.php?id=487085 Tue, 03 Oct 2006 22:28:19 +0100 487085 http://www.moseshohman.com/blog/2006/10/02/24 More random foreign language trivia, this time of an etymological nature: the Italian word, sicario, means “hired assassin”. The Latin root is sicarius, which means “wielder of the knife”. By contrast, the Italian word assassino just means murderer. The Korean word for “meteorite” is 별똥 (roughly, pyeol-ddong), which literally means “star droppings”, as in feces. A quick Google search confirms this word is commonly used. Other words containing the word for “droppings” indicate that I am being gentle in my translation here. I wonder if it’s similar to the German word, Dreck, which means “animal droppings” but is also used for “crap” and “dirt” in the nasty sense of that word. Let me also mention where I learned these fun facts. I subscribe to Acquerello Italiano, an Italian langauge audio magazine that sends you a CD and transcript of the recording, filled with interesting facts about the vocabulary of the program. They also offer German, French and Spanish versions (all with different, country-specific content). The “meteorite” derivation came from the Handbook of Korean Vocabulary, another great Korean language book by Miho Choo and Wiliam O’Grady. The book contains two sections, one on Chinese roots and the other on Korean roots common in Korean words. I have found the book very useful when learning vocabulary, because otherwise Korean words are just a bunch of meaningless syllables to me and are therefore difficult to remember. (Source: Inforbiomatica) Inforbiomatica blogs http://www.medworm.com/rss/comments.php?id=487086 Tue, 03 Oct 2006 04:58:52 +0100 487086 http://www.moseshohman.com/blog/2006/06/18/35 I don’t know why I didn’t post this before, but at the end of last month BMC Bioinformatics posted a provisional version of our paper on agile software methods in bioinformatics. The good news is people seem to be reading it. It is the journal’s #3 most viewed paper in the last thirty days! Give it a read and let me know what you think. (Source: Inforbiomatica) Inforbiomatica blogs http://www.medworm.com/rss/comments.php?id=487087 Mon, 19 Jun 2006 03:22:01 +0100 487087 http://www.moseshohman.com/blog/2006/05/23/34 We finally got around to open sourcing schemamule, a utility we wrote in the bioinformatics core at Northwestern. Schemamule copies the schema from one database to another (right now we support copying from Oracle to HSQLDB). We have used this tool for over two years now to set up an in-memory HSQDLB database to use for unit testing. This has at least a couple nice benefits: Database-dependent tests (e.g. DAO tests) run much faster than when they are run against a database accessible only over the network, especially when working from home Database-dependent unit tests can be run even if you aren’t on the network at all, very nice if you’re working on a plane, in an airport, or at the beach We use schemamule primarily via its schemacopy Ant task, which has some nice configuration options if you just want to copy a subset of the table definitions from the schema, if you want to copy views, sequences, etc. Note that table records are never copied. One of our apps does a number of funky custom-SQL queries for reporting (we have not yet taken the plunge and created a reporting data warehouse DB), and this meant that we had to fake a number of Oracle-specific features in HSQLDB. For example, in HSQLDB there is no DUAL table. We fake it by creating a table called DUAL that has one (and only one) row (the column names and record content being irrelevant). We also provide an HsqldbLibrary class to define other functions (e.g. TRUNC) not available in HSQLDB. Anyway, if you do a lot of automated unit testing in Java, use Ant to automate your builds, and have slow database-dependent tests, try out schemamule, see if it helps, and let us know. Usage examples are available on the project website. (Source: Inforbiomatica) Inforbiomatica blogs http://www.medworm.com/rss/comments.php?id=487088 Tue, 23 May 2006 20:15:14 +0100 487088 http://www.moseshohman.com/blog/2006/04/21/23 A while back I was talking with a colleague about domain object validation for an application built using the Spring framework. My bioinformatics team at the CFG has always put the validation logic into the business object itself. In the case of command objects (the objects that hold form state), this means we create a custom interface, Validatable, that declares a single method, void validate(Errors errors) (the Errors interface is part the Spring validation machinery, representing a smart hash of errors by object property). Calling this method records any validation issues into the Errors object passed to validate(). We also need a simple Validator called ValidatableValidator that takes a Validatable and calls validate(errors) on it. This always seemed the right approach to me, because after all in object-oriented design you should always move operations that act on data close to the data themselves, i.e. put the validate method that checks for valid data state in the object that encapsulates that data, i.e. tell, don’t ask. My colleague was of the opposite opinion. He felt that command objects should just be dumb objects (”objects” with only data and accessor methods, no business logic), and all validation logic should be kept in separate validator objects. When I protested that dumb objects were an anathema in object-oriented code, he asked me why Spring provided a Validator interface and not a Validatable interface. I had to admit I was a little dumbfounded. I generally think Spring is well-written, but it did seem they were explicitly recommending splitting validation behavior out of the object being validated. Thinking about it some more, I’ve decided that while I still generally think that validation logic should stay in the object being validated, there are cases when you’d want to split it out. when the validated object’s class already has lots of behavior, is getting too big and needs to be split up into a few collaborating classes, closely coupled to one another but not to other classes when the same validation logic occurs in multiple business objects (e.g. this string is not null, empty or whitespace) and you’d like to simplify maintenance and keep that logic in only one place, though this can just as easily be done using a static method, e.g. StringUtils.isBlank(text) when validation depends on capabilities foreign to the object itself (e.g. checking uniqueness of a username via a data access object (DAO) — it often makes good sense to split the responsibility for data access out of domain objects and into DAOs) Another example of the last case is anything that has to interact with the network. You don’t want your domain objects depending on a network, especially if you want unit tests to run rapidly and reliably without access to a network (e.g. when you’re sitting in an airport that charges $10/hour for wireless internet access). In the neuromice.org code, when we validate mouse data pulled in from one of the member sites, we check all links provided to make sure they work and refer to the expected content, and we do this using an external validator class. However, we avoid violating the “tell, don’t ask” principle by using something similar to the visitor pattern. The object being validated has an accept(ValidationVisitor validator) method. The validator passed in has methods like validateLink(String url), etc. In our unit tests we pass in either a mock or a stub ValidationVisitor that does not actually hit the network. This allows us to separate out responsibilities nicely without requiring brittle procedural code sitting in an unrelated class like class SomeFormValidator implements Validator { public void validate(Object object, Errors errors) { // oddly the cast is still necessary in Spring 2.0 M3 MutantLine line = (MutantLine) object; if (!LinkValidator.isValidLink(line.getGeneLink()) { errors.addError("etc. etc. etc."); } ... } } Instead the code is something like class MutantLine { ... public void accept(ValidationVisitor validator) { validator.validateLink(this.geneLink, "gene link"); associatedObject.accept(validator); ... } } Note that the ValidationVisitor encapsulates the Errors object. As an interesting aside, in Ruby on Rails, validation is baked into domain objects, including validation that depends on data access. This is because Rails’ ActiveRecord, unsurprisingly, follows the Active Record pattern, in which the object is both a domain object and a DAO. (Source: Inforbiomatica) Inforbiomatica blogs http://www.medworm.com/rss/comments.php?id=487089 Fri, 21 Apr 2006 15:10:03 +0100 487089 http://www.moseshohman.com/blog/2006/04/20/32 Some friends of mine have been working on an interesting new startup called SciLnk. Essentially, the site is LinkedIn for life scientists. It will also allow you to browse pubmed abstracts via the network of authors. Often when you’re researching a subject you want to read all the papers published by a particular person and his or her collaborators on the topic, and it’s not as easy as it should be to collect everything via PubMed. SciLnk hopes to leverage the people network to improve the literature browsing experience and vice versa. There are lots of other interesting directions to take such a resource: improving the conference-going experience, grant searching/suggestions, job searching, etc. They recently posted screenshots (and, more recently, these) of the product under development, and you can sign up to get in on internal beta testing at scilnk.com. Full disclosure: I was personally working with the SciLnk team in its early days, but quickly realized I had bitten off more than I could chew, what with having a full-time day job and not living in Boston with the rest of the crew. I no longer have any financial interest in the company, I just think it’s a cool idea. (Source: Inforbiomatica) Inforbiomatica blogs http://www.medworm.com/rss/comments.php?id=487090 Fri, 21 Apr 2006 04:51:40 +0100 487090 http://www.moseshohman.com/blog/2006/03/21/30 While reading through another team’s Java codebase recently, I came across a disturbing proclivity for code like this public SomeType aMethod() { SomeType result = null; try { anObject.thatDoesSomething(); result = anObject.getSomethingElse(); } catch (SomeTypeOfException e) { e.printStackTrace(); // or, sometimes, log.error(e); } return result; } This is called swallowing the exception. The only way to know that an exception occurred is to have access to the stderr stream of the process (or, if logging was used, the logs). Since the software product referred to above runs inside an application server, clients never get to see this information. The method just returns null. Sometimes it’s obvious that null indicates a problem. Other times, however, the client may wrongly interpret null as absence of information. This brings me to what I think should be a rule for Java code: almost always, printStackTrace() is not for us to use. Its only utility is for toy programs and logging libraries. When presented with exceptions that your code cannot handle itself, you should rethrow those exceptions up the call stack, so that the server container can report problems to any client and to the application logs. Sometimes you have to wrap exceptions in another type of exception (e.g. a ServletException) or a custom runtime exception (we usually create a class SystemException for this), because the callbacks your server gives you do not declare that they throw the right exception type. This is one of the reasons I like using Spring MVC; the controller callbacks all declare that they throw Exception (although I’m sure most other modern Java web frameworks share this property these days). So, remember (if you didn’t already know, which most of you probably do): if you see e.printStackTrace() in your code, it likely means your code has a problem you need to fix. Even throwing new RuntimeException(e) is better than swallowing the exception. Update: Reading this later, I realized I left out an important point. The above assumes you actually need the try/catch block. If SomeTypeOfException were an unchecked (i.e. runtime) exception, you could just let it bubble up the call stack. If it’s a checked exception, in order to let it bubble up, you have to declare the exception in the method signature. This is unadvisable if the exception makes no sense for the method (e.g. declaring that an Employee’s getPhoneNumber() method throws SQLException). In this case it’s preferable either to wrap the exception in a checked exception that makes sense in the method signature or in an unchecked exception that does not need to be declared. (Source: Inforbiomatica) Inforbiomatica blogs http://www.medworm.com/rss/comments.php?id=487091 Tue, 21 Mar 2006 23:48:51 +0100 487091 http://www.moseshohman.com/blog/2006/03/21/29 I discovered recently on postgenomic.com that mine is one of the wordiest life science blogs around, so I’m going to try to be a little pithier. We’ll see if I can constrain myself. In my last post I argued for the central importance of effective collaboration and communication in biomedical informatics. I wanted to list a few things that have worked for my teams in those areas. At Northwestern we worked on two projects. Neuromice.org is a phenotype database and virtual storefront for the mutant lines produced by three neurologically-focused whole genome mutagenesis efforts at Northwestern, the Jackson Laboratory and the Tennessee Mouse Genome Consortium. The other application, MouseDB, is an intranet (i.e. you can’t see it) colony and phenotyping management system for the mice under study at Northwestern (10,000 mice/year when we were in full swing). Each project had different challenges, but here are a few things I learned from those experiences. Some are pretty standard agile ideas, others less so. Each distinct customer/user subgroup should appoint a representative who speaks for that subgroup in all discussions of feature definition and priority. Keep the number of subgroups as small as possible (ideally, one). This greatly reduces the uncertainty and difficulty of scope decisions. Some users in the group might have no reason to use your software. Make this fact explicit, and don’t factor their interests into the product. Be completely open with your user community. Give them the opportunity to know everything you’re working on, and the reasons for (and the opportunity to contribute to) any decisions made about features going into the product. A development team should avoid making any decisions about scope or feature priority. Emphasize to users that it is in their power to steer the software toward the greatest possible utility. Technical improvements are a sticking point here, but we’ve found if you make a good argument for them, users understand their value and will prioritize them appropriately. If you let academics’ busy schedules eat away at your face time with them, you will eventually suffer for it. Be creative. I think I’ve reached my word limit. Over the next couple weeks I’m going to let loose a flurry of technical posts on various topics that have been on my mind lately. (Source: Inforbiomatica) Inforbiomatica blogs http://www.medworm.com/rss/comments.php?id=487092 Tue, 21 Mar 2006 23:17:07 +0100 487092