Inforbiomatica - Latest Comments

Re: Agile bioinformatics paper

alex_mass — Tue, 23 Aug 2011 18:57:24 -0000

This is not directly a comment on your paper, but although some views on the same topic: http://alexandre-masselot.blog...

Re: Too many mock objects == ruby refactoring death

Andho — Tue, 23 Aug 2011 12:03:56 -0000

I think that an Aggregate root should not mock the objects it contains within it. If there are too many related objects to mock outside of the Aggregate, than that Class needs refactoring.

Re: Pair programming and microarrays

Abhishek Tiwari — Tue, 17 Feb 2009 15:00:01 -0000

recently there was a publication about how it is difficult to reproduce microarray experiments, mostly because the experimental conditions are not annotated properly, but I guess when more eyes will work together it can be improved. between nice blog, one more in my list
http://www.abhishek-tiwari.com...

Re: Chained Selenium RSpec examples

Moses — Fri, 13 Feb 2009 21:36:07 -0000

Thanks for your comment. We chain in order of appearance, nothing special needs to be done for that to happen.

Also, we haven't looked a cucumber much yet. We have existing infrastructure that we'd like to restructure sometime, but for now it works pretty well, especially the code for the actual tests. For our team, I am not that excited about plain text tests. Developers write all of our selenium specs right now. If some day that changes, then we'll probably get more motivated to look into cucumber.

Re: Too many mock objects == ruby refactoring death

Moses — Fri, 13 Feb 2009 21:32:35 -0000

Test granularity: definitely not too coarse : )

When we first started testing, we were bitten by the "add a fixture and a bunch of random tests break" phenomenon a few times. That was one of our motivations to move heavily into using mock-based testing. After mock-based testing bit us also, we eventually converged on the following approach to test data: use fixtures for things that are really basic and fundamental, and therefore won't need to be added to often; use the ObjectMother pattern (which goes by many other names, basically a test data factory) for one-off objects with specific states needed by your tests; use mocks when test data setup is just too arduous, or if needed for performance or some kind of external dependency.

Thanks for your comment!

Re: Developer testing is not primarily about design

Wolfram Arnold — Fri, 13 Feb 2009 19:54:26 -0000

And there is one more effect I would add: By adopting a test-first process, you're frontloading all the questions and uncertainties and miscommunications. If the developer can't formulate a concise test, chances are they're not fully clear about the requirements. It's better to flush this out at the beginning when it's cheap to fix, than implement something that's off-spec and let QA (if you still have it) or, worst (because most expensive) the customer find it.

Re: Chained Selenium RSpec examples

Wolfram Arnold — Fri, 13 Feb 2009 19:49:44 -0000

This is an interesting idea, the chaining of examples. I've run into this before--the desire to walk through an entire workflow and it creates monster tests. Are you chaining in order of appearance, or do you have to name methods such that their alphabetical order is the order of execution you want?

A note on your last comment: Have you looked at Cucumber for integration testing? The rspec.info site now explicitly recommends it.

Re: Too many mock objects == ruby refactoring death

Wolfram Arnold — Fri, 13 Feb 2009 19:43:17 -0000

Hehe, it's a long running debate. Mocks vs. fixtures. Rspec brought many advantages that I like, such as being able to test views and helpers and controllers all independently of each other. Oftentimes with the right granularity you can make those tests pretty lean and mean.

Having said this, mocks are no end-all be-all as some of the fervent proponents have you believe. Mocking association proxies are a pain, for example. I've not yet heard a good answer to this.

Some projects out there are trying to centralize the mocks, these may be worth a look.

On a wider perspective, though, I've observed a very similar problem to what you're describing--you make one implementation or API change--and all hell breaks loose with your tests, even in a fixtures-based test environment, and this typically happened when new fixtures were added to add more variety to the demo data, so as to model a new case. The upshot conclusion from this for me has always been that data and tests were too tightly coupled. So, not knowing anything about your application, I wonder if your test granularity (and thus code granularity) is too coarse?

Re: Too many mock objects == ruby refactoring death

Kevin Olbrich — Thu, 13 Nov 2008 16:17:57 -0000

The most recent version of RSpec now supports 'stub_model's. These use real objects that created at the time of use and cannot be saved to the database. They have the advantage of allowing you to stub out attributes and still be able to call actual methods on the object. This way you end up only stubbing the data and not the behavior associated with an object.

Re: Too many mock objects == ruby refactoring death

Kevin Olbrich — Thu, 13 Nov 2008 16:17:57 -0000

Re: Slow Rails migrations, Ruby GC, and a MacPorts portfile

roger — Wed, 20 Aug 2008 17:00:51 -0000

I see this this port install the famous 'gcpatch' for the existing interpreter. Cool.

Re: Too many mock objects == ruby refactoring death

Steve — Tue, 05 Aug 2008 10:58:49 -0000

I totally agree with you. Mock objects have always seemed super awkward to me. I think that when you test your application, it should mimic how it's going to behave in the real world as much as possible. Otherwise, you're not really testing it fully. And I think in-memory databases are the way to go. If you use an ORM (though I haven't used one that I loved), then it should be seamless.

Re: Pair programming and microarrays

Jon — Tue, 29 Jul 2008 13:21:51 -0000

First, a few questions about microarray experiments:

What do people hope to gain from microarray experiments in 2008? What relevance does transcriptional profiling on a genome/transcriptome wide scale have when thousands of these experiments have already been done and made publicly available through GEO and MGED? And what about the more recent realizations that short, non-coding RNAs (that were thrown away during sample preparation) are orchestrating another level of regulation - you can't go back to the original samples to measure the microRNAs? What techniques could make microarray data more usable and meaningful? The GEO interface is god-awful for the occasional user, but look at what Atul Butte can do with these data. Is there still a meaningful discovery aspect of transcriptional profiling studies? How many of the people doing microarrays have the infrastructure to do the kind of followup studies that really demonstrate relevance of their discoveries? I'd wager not many.

Now, a few thoughts on collaboration:

Collaboration is certainly the key to moving knowledge forward in an increasingly interdisciplinary world, but the paradigm we have been brought up in (at least on the science side) is that to be successful academically you have to the one with the idea, the persistence and the ability to tell a story. It doesn't help to be the third guy from the left when you're getting credit. Unless everyone feels that their interests are protected, no one (except the young and foolish) will move forward with a collaboration.

So is there a unique role for a small company in this process? I think there are several. But that's a topic for a future post.

Re: Z factor refactored

Moses — Tue, 29 Apr 2008 17:20:52 -0000

Thanks for your comment, Neil. Could you expand more on your statement about time dependent cell counts? I'm interested.

Re: Z factor refactored

Neil — Tue, 29 Apr 2008 16:51:29 -0000

We agree and really appreciate your discussion of the Z-factor. It seems that using a time dependent cell count to determine a K value may be a better descriptor. But I guess this contradicts the HTS philosophy.

Re: Chained Selenium RSpec examples

Moses — Thu, 10 Apr 2008 10:42:36 -0000

Hi Jean-Michel,

Funny you should ask. I'm almost finished porting the chained examples stuff to a more recent RSpec version, because we were sick of being stuck at 1.0.8 or whatever it was at work. I should have something released in the next couple weeks, and I will be releasing it to spec/ui (which is part of rspecext). specselenium will probably be deprecated (although we'll see how it all goes in the next couple weeks).

Re: Chained Selenium RSpec examples

Jean-Michel Garnier — Wed, 09 Apr 2008 04:48:42 -0000

Hi Moses,

Cheers for the update! I only see it now though: I did not check you blog

http://rubyforge.org/projects/... is great! I am going to use it. I also use selenium-grid.

Any chance you update the chained example for RSpec >= 1.1.3 ?

it looks like it can work using before :all, I am a bit confused at this stage. What's up the spec/ui project?

Re: Chained Selenium RSpec examples

Moses — Mon, 26 Nov 2007 11:35:36 -0000

Hi Jean-Michel,

The use_chained_examples option is something we implemented locally at CDD, and is only available through the spec-selenium plugin right now (available via svn on rubyforge: http://rubyforge.org/projects/....

Recently I was added as a committer on RSpec to roll some of our work into spec:ui. I will keep you posted.

Interesting ideas in your blog post, I would like to see something similar, too. It's an especially interesting idea for clinical informatics, particularly in the case of validated systems, when you need to document everything your software does. This is traditionally done in Word, leading to unacceptable bureaucratic overhead.

Sorry it took a while to approve your comment, I was on vacation last week.

Re: Z factor refactored

Moses — Mon, 26 Nov 2007 11:26:39 -0000

Probably so, thanks for your comment. I'll play around with the idea. ROC curves are definitely an intuitive way to present sensitivity/specificity information.

Re: Chained Selenium RSpec examples

Jean-Michel Garnier — Thu, 22 Nov 2007 11:49:52 -0000

I have also been playing with selenium using spec_ui and I am going to submit some patches to spec_ui. You can find a summary in my blog at
http://21croissants.blogspot.c...

I did not know about the "use_chained_examples" option and I am going to give a try right now. Thank you for blogging about it. I have had been thinking to create a specific matcher to generate a description from all selenium actions but it would not have been very readable ...

Yes, if you could share your work through a plugin, it would be great!
Jean-Michel

Re: Z factor refactored

Pedro Beltrao — Tue, 13 Nov 2007 09:08:05 -0000

It looks like ROC curves would be useful for this.

Re: Developer testing is not primarily about design

Steven Ashley — Fri, 27 Jul 2007 14:25:05 -0000

I couldn't agree more, one more thing, care needs to be taken that the team isn't "too close" when developing the tests. Personally, I have found, I can be to close to the code to adequately create tests for it, missing the forest because all the trees kept getting in the way.

Re: The promise of bioinformatics

Moses — Thu, 06 Apr 2006 12:45:06 -0000

Thanks for your comments, Mark. it certainly helps to be able to speak the language of biology if you're writing biological software. There are many kinds of bioinformatics software projects, and in the scenario you describe above, a student writing a bioinformatics thesis, I think it's fair to expect the programmer to have a deeper understanding of the biology. However, for other projects this may not be realistic. You see this all the time in other application domains. For example, at ThoughtWorks our team wrote equipment leasing software. None of the programmers was a leasing expert (or really knew much about leasing at all). This situation was (and is often) mitigated by hiring "business analysts", people who understand the business and have some understanding (sometimes a deep understanding) of software. These people are in a position to notice when programmers don't ask the right questions, can act as proxies for the customer when the customer is not available to answer questions, and in general can translate between programmer-speak and business-speak.

Most bioinformatics projects have very small software development teams, so it is perhaps impossible for many of these projects to expect to have someone who could just play a "science analyst" role. However, I think it's perfectly reasonable to try to form a team composed of experts in software who don't understand the biology fully and bioinformaticists with less training in software but a good understanding of the science. This is in fact what my colleague Mike McCormick's group did at the Hutch, and he reports that it works quite well. The nice thing is that the more senior developers teach the bioinformaticists more about writing code, the bioinformaticists teach the developers more about biology, and everyone gets better at what they do in the end.

Re: The promise of bioinformatics

Mark — Thu, 06 Apr 2006 09:39:01 -0000

Lately I've been helping some students in my lab by reviewing their theses and dissertations and giving them feedback. One of the biggest shortcomings of the program is that they don't get enough biology throughout the course of the program, and their theses reflect that. Questions that should have been asked and answered over the course of their projects were never addressed. The biologists that they worked with, often didn't spend enough time on the project with them discussing the relevance and application of their work. This leaves gaping holes in what they could have discovered and places serious limitations on the scientific relevance and value of their work.

From an interaction standpoint, it's best to learn as much as you can about the problem space you're dealing with, in order to ask the right questions of your collaborators. That's often difficult to do, if you speak PERL/Python/Java and they speak Molecular Biology/Microbiology/Virology. You have to speak the same language to be on the same page. Even if you're not the one formulating the questions, you have to be able to understand the question and understand its implications.

Re: The promise of bioinformatics

Moses — Sat, 04 Mar 2006 11:27:19 -0000

Thanks, Deepak. You make a good point about the historical effects of past failures. I agree that having biologists get some exposure to informatics during their education would help. Ideally this would not just be a few weeks' crash course in Perl or one class on using NCBI's eUtils, but would involve working with actual developers to produce something together, perhaps a cross-discipline lab course between computer science and biology.

I also agree that poor communication is a wider problem that exists anywhere people build software for other people. I think the problem is more severe in any field like bioinformatics where the domain is very complex. The onus is on software and (in this case) biologist leaders to make improved communication a priority.