As I mentioned in a previous
post,
this weekend I participated in my first Software
Carpentrybootcamp. I had the
pleasure of meeting the instructors and all the other helpers involved
on Friday over pizza and beer, and in particular spent considerable time
nerding out with Naupaka over all things vim
and tidy data.
On Day 1, the topic of the morning was
R. From what I understand, it was only
recently that Software Carpentry decided to add R to their curriculum.
Though I certainly learned plenty myself as I rushed about helping
participants through small problems, there is a lot of good stuff (and
plenty of potential) here.
R is an analysis tool first and a programming language second. This
makes it a pragmatic choice for researchers but still a difficult one to
teach. We used RStudio as the
environment for introducing things, and this may have taken the edge off
for the command-line averse. I didn’t get a chance to follow along with
the exercises too much myself, but I’m particularly interested in
learning more about the use of factors. If anyone has any resources for
understanding what factors are, why they are useful, etc., I’d love to
hear about them.
That afternoon we switched topics to the shell, or more specifically
bash. The session started well
enough, but given a distribution of participants that ranged from zero
experience to intermediate, it proved difficult to please everyone.
Also, as a note to anyone that does a bootcamp on the shell (or even any
topic): give a motivation behind everything you demonstrate, both in
broad and immediate scope. Although it can be obvious why a given trick
is useful to an experienced user, the novice can often be left wondering
what benefit this has compared to what they already do to get work done.
This is especially true for the shell, since 90% of work done in the
shell is moving around a file system, which most scientists already
accomplish by clicking around a file browser. People have to see a clear
advantage to adopt new practices.
Day 2 (today) started off with git. The
instructors did well to put extensive focus on giving motivation for
git’s use, given the feedback from the previous day’s session on the
shell. This was especially important for git, since for many scientists
it is considered to be non-essential in the toolbox of software things.
Software Carpentry hopes to change this.
The gist: git is great for more than just code. Though originally
produced to address the needs of the software community, as a version
control system git works particularly well for paper writing, alone or
with collaborators. And even though git is optimal when working with
text-only files, it is perfectly happy to store away anything you
like and version control it. Further, pushing the materials used to
build a manuscript to a public repository host like
GitHub is a great way to address the
well-acknowledged problem of reproducibility in
science.
During the afternoon we turned our focus to
SQL, using
an SQLite database as our toy case for
running queries against. I was running out of steam by about this point,
and I mainly focused on helping the folks on Windows to get sqlite3
working under Git Bash (not hard, but
for beginners running around the filesystem is an expensive operation).
Overall, I’m happy I got to help put this on and I hope to be involved
in a growing SC community here at ASU in the very near future. Assuming
space is still available, I’m also hoping to attend Titus Brown’s
instructor training in Davis this coming
January.
Thanks to everyone involved! Looking forward to more!
— david