Monthly Archives: April 2011
Oikos has a blog? [Blogrolling]
Thanks to an email from Jeremy Fox I just found out that Oikos has started a blog. It clearly isn’t on most folks radars (I represent 50% of its Google Reader subscribers), and Jeremy has been putting up some really interesting posts over there so I thought it was worth a mention. According to Jeremy:
I view the Oikos blog as a place where the Oikos editors can try to do the sort of wonderful armchair ecology that John [Lawton] used to do in his ‘View From the Park’ column. I say ‘try’ because I doubt any of us could live up to John’s high standard (I’m sure I don’t!). I’m going to try to do posts that will be thought-provoking for students in particular. Oikos used to be the place to go with interesting, provocative ideas that were well worth publishing even if they were a bit off the wall or not totally correct. It’s our hope (well, my hope anyway) that this blog will become one way for Oikos to reclaim that niche.
I think they’re doing a pretty good job of accomplishing their goal, so go check out recent posts on the importance of hand waving and synthesizing ecology, and then think about subscribing to keep up on the new provocative things they’re up to.
A GitHub of Science? [Things you should read]
There is an excellent post on open science, prestige economies, and the social web over at Marciovm’s posterous*. For those of you who aren’t insanely nerdy** GitHub is… well… let’s just call it a very impressive collaborative tool for developing and sharing software***. But don’t worry, you don’t need to spend your days tied to a computer or have any interest in writing your own software to enjoy gems like:
Evangelists for Open Science should focus on promoting new, post-publication prestige metrics that will properly incentivize scientists to focus on the utility of their work, which will allow them to start worrying less about publishing in the right journals.
Thanks to Carl Boettiger for pointing me to the post. It’s definitely worth reading in its entirety.
_______________________________________________________
*A blog I’d never heard of before, but I subscribed to it’s RSS feed before I’d even finished the entire post.
**As far as biologists go. And, yes, when I say “insanely nerdy” I do mean it as a complement.
***For those interested in slightly more detail it’s a social application wrapped around the popular distributed version control system named Git. Kind of like Sourceforge on steroids.
Postdocs Galore [Jobs]
Advertisements for three exciting postdoctoral positions came out in the last week.
Interface between ecology, evolution and mathematics
The first is with Hélène Morlon’s group in Paris. Hélène and I were postdocs in Jessica Green’s lab at the same time. She is both very smart and extremely nice, oh, and did I mention, her lab is in PARIS. Here’s the ad. If it’s a good fit then you couldn’t go wrong with this postdoc.
A postdoctoral position is available in my new lab at the Ecole Polytechnique and/or at the Museum of Natural History in Paris to work at the interface between ecology-evolution and mathematics. Candidates with a background in biology and a strong interest in modeling, or with a theoretical background and a strong interest in biology, are encouraged to apply. More information is available here. Potential candidates should feel free to contact me. The deadline for application is May 8th.
The other two postdocs are associated with Tim Keitt’s lab (which I consider to be one of the top quantitative ecology groups out there).
Mechanistic niche modeling and climate change impacts
A postdoctoral position is anticipated as part of a collaborative project to develop and evaluate mechanistic niche models that incorporate geographic variation in physiological traits. The post doc will be based in Michael Angilletta’s laboratory at Arizona State University, but will interact with members of Lauren Buckley’s lab at the University of North Carolina in Chapel Hill and Tim Keitt’s lab at the University of Texas in Austin. The post doc will be expected to engage in modeling activities and coordinate lab studies of thermal physiology. Experience with mathematical modeling in C++, MATLAB, Python or R is beneficial and familiarity with environmental data and biophysical ecology is beneficial. More here.
Ecological forecasting or statistical landscape genetics
The Keitt Lab at the University of Texas at Austin seeks a postdoctoral investigator to join an interdisciplinary NSF-funded project linking ecophysiology, genomics and climate change. The position requires excellent modeling skills and the ability to engage in multidisciplinary research. Research areas of interest include either ecological forecasting or statistical landscape genomics. More here.
So, if you’re looking for a job go check out these great opportunities.
Learning to program like a professional using Software Carpentry
An increasingly large number of folks doing research in ecology and other biological disciplines spend a substantial portion of their time writing computer programs to analyze data and simulate the outcomes of biological models. However, most ecologists have little formal training in software development¹. A recent survey suggests that we are not only; with 96% of scientists reporting that they are mostly self-taught when it comes to writing code. This makes sense because there are only so many hours in the day, and scientists are typically more interested in answering important questions in their field than in sitting through a bachelors degree worth of computer science classes. But, it also means that we spend longer than necessary writing our software, it contains more bugs, and it is less useful to other scientists than it could be².
Software Carpentry to the Rescue
Fortunately you don’t need to go back college and get another degree to substantially improve your knowledge and abilities when it comes to scientific programming, because with a few weeks of hard work Software Carpentry will whip you into shape. Software Carpentry was started back in 1997 to teach scientists “the concepts, skills, and tools they need to use and build software more productively” and it does a great job. The newest version of the course is composed of a combination of video lectures and exercises, and provides quick and to the point information on such critical things as:
along with lots of treatment of best practices for writing code that is clear and easy to read both for other people and for yourself a year from now when you sit down and try to figure out exactly what you did³.
The great thing about Software Carpentry is that it skips over all of the theory and detail that you’d get when taking the relevant courses in computer science and gets straight to crux - how to use the available tools most effectively to conduct scientific research. This means that in about 40 hours of lecture and 100-200 hours of practice you can be a much, much, better programmer who rights code more quickly, with fewer bugs, that be easily reused. I think of it as boot camp for scientific software development. You won’t be an expert marksman or a black belt in Jiu-Jitsu when you’re finished, but you will know how to fire a gun and throw a punch.
I can say without hesitation that taking this course is one of the most important things I’ve done in terms of tool development in my entire scientific career. If you are going to write more than 100 lines of code per year for your research then you need to either take this course or find someone to offer something equivalent at your university. Watch the lectures, do the exercises, and it will save you time and energy on programming; giving you more of both to dedicate to asking and answering important scientific questions.
______________________________________________________
¹I took 3 computer science courses in college and I get the impression that that is about 2-3 more courses than most ecologists have taken.
²I don’t know of any data on this, but my impression is that over 90% of code written by ecologists is written by a single individual and never read or used by anyone else. This is in part because we have no culture of writing code in such a way that other people can understand what we’ve done and therefore modify it for their own use.
³I know that I’ve decided that it was easier to “just start from scratch” rather than reusing my own code on more than one occasion. That won’t be happening to me again thanks to Software Carpentry
