Anyway, since I'm neither all-knowing nor all-seeing (shocking, right?) I figured I'd put the list of resources up here so others could chime in.
A constant stream of new users is how Perl gets smarter and continues to thrive. If you know of other good beginning Perl introductions, please drop them in a comment and I'll add 'em to this list. (note: If you link to a good intro that also focuses on bioinfo for its code examples, I'll buy you a beer at the next YAPC::NA. :-)
Update 10/18/1011
Dr. Louise Johnson, the aforementioned biology prof whose tweet prompted this post, has graciously provided a a list of resources that other perlgeeks have suggested for her students:
- O'Reilly's Learning Perl (the classic Llama Book) was recommended several times. That's what I used, and I still refer back to it. I found the end-of-chapter practice exercises particularly useful.
- Keith Bradnam (@kbradnam on twitter) runs a perl course for biologists at UC Davis and is currently writing a book which sounds excellent. Some course materials are available here: http://korflab.ucdavis.edu/Unix_and_Perl/ and Keith also pointed us toward this http://www.perl.com/pub/2000/06/27/perlbook.html which is among the many helpful resources available at the Perl site itself.
- Casey Bergman (@bergmanlab), computational biologist at the University of Manchester and all-round fab person, recommended this book chapter: http://onlinelibrary.wiley.com/doi/10.1002/0471223921.ch17/summary
- Wiley were kind enough to send me a copy of 'Perl Programming for Biologists' by Curtis Jamison, which is now in the hands of one of the students. I will ask him to report back! From a brief flick-through, it is clearly written and has exercises at the end of each chapter. The focus is on sequence analysis.
- Stephen Henstridge (@HenstridgeSJ) thought 'Perl By Example' by Ellie Quigley would be suitable as it has a focus on learning by doing, which sounds very appropriate for someone who isn't all that interested in the theory. I'm pestering the library to get hold of a copy.
Thanks for the update, Doc!
]]>I'm kidding, of course. Thanks for the link.
]]>First, debugging is a process of elimination. If something isn't working as expected, you factor out the things that it couldn't be as a way of narrowing your search for what's actually wrong. By rigorously testing even the things that *seem* like they could never go wrong you are unambiguously removing those cases from your bug hunts.
Secondly, it's often a matter of iterative development. Let's say I want to add an attribute that contains an object, for example. First, I might test if the current object can() do the accessor methods for that attribute. It can't so I add the attributes and set up the appropriate accessors. Now that test passes. I used a builder to create that object instance if I didn't explicitly pass one during construction so I test that the object returned at least belongs to the right class. It does, and I know that for certain because there's an explicit test for it. And so on and so on.
]]>Basically, it just runs Test::More's use_ok()
on every file in the package's blib/lib directory to ensure that everything is building okay.
file: 000use.t
use Test::More; use File::Find;
my @classes = ();
my $root = 'blib/lib';
File::Find::find(
sub {
return unless $_ =~ /.pm$/;
my $path = $File::Find::name;
$path =~ s|^$root/||;
$path =~ s|.pm$||;
$path =~ s|/|::|g;
push @classes, $path;
},
$root
);ok( scalar( @classes ) > 0 );
foreach my $class ( @classes ) {
use_ok( $class );
}done_testing( scalar( @classes ) + 1 );
What's the first test you always write?
]]>As many of you may already know, a group of us got together a couple of years ago to form Tamarou, an Enlightened Perl/OSS-friendly consulting and development firm. We decided to work the business using an incremental approach-- basically everyone involved had their own things going and each of us committed X number of hours per month to make it grow. The reasoning went: "If we succeed, great; if we don't, we all stay friends and no one loses their house/life savings/etc."
Contrary to conventional wisdom (which states that every business needs some sort of aggressive, hard-charging Executive type to will the business into existence with the magic of their Executive-type executing) we've actually done quite well for ourselves-- well enough that, even in this economy, two of us now work fulltime for Tamarou clients, billing exclusively under our little banner. Nothing is perfect, but, by and large, our plan has worked and we've beaten the odds.
Then last month happened.
It began simply enough: a bit of minor dental surgery that'd I'd been putting off that needed to be finally taken care of. A few office visits, some pain pills and antibiotics, maybe a missed day of work here or there-- no big deal. Except that I had a massively adverse reaction to the pain meds that essentially rendered me completely useless, work-wise, for weeks. Male pride and 10+ years of Hero Coderism made the situation worse. Promises made and broken, and then made broken again; deadlines whizzing by with alarming speed; have-to deliverables that were not delivered. In short, I totally screwed the pooch.
I'm not here to bend your ear with my sorry tale of woe, however. Reality is that the events of the last month has exposed some pretty heavy organizational and administrative weaknesses in our little company, I think. I shouldn't have been able to fall in a hole for weeks at a time without someone inside Tamarou noticing that something was wrong. Our communications systems are entirely ad-hoc and half-assed. Shit happens-- it always does-- you can't change that. But you can plan ahead, and put systems in place to weather the storms when they inevitably come.
So, I'm asking for your advice. If you've been in our same spot-- small company, limited resources-- what structures, plans, etc. did you put in place to ensure that unforeseen events didn't screw your own little entrepreneurial pooch?
]]>