Sat 30 May 2015
| tags: teaching swc software
This week I taught my first Software Carpentry workshop at Oklahoma State
University. The workshop had been in such demand that we had a total of four
instructors, including Jonah Duckles , Kate Hertweck , Thomas Guignard ,
and myself. I arrived at the hotel close to 2am the first day of the workshop,
and was running on nespresso during most of the morning session.
Though originally Thomas and I were set to teach one room together, due to
flight troubles Jonah took over the session on the Unix shell that kicked
things off. I spent most of the time fixing issues with GitBash (usually
fixed by reinstalling it) and helping people connect to the network (curse
those certificates!), but these issues didn’t affect most of our learners. I
was able to spend at least a little time watching Jonah teach, too, and
I can say I learned a few things myself (e.g. that tr is a thing!).
I taught the session on Python , which was split into two parts over the
two days. This decision was made at the cost of omitting SQL for Day 2. It
worked out well because even though I went too fast the first day (this was
the dominant complaint from feedback), we still only barely touched on
functions by the end of it. The second day’s session was entirely filled
by the second half of material, which built on that of the first.
This was my first time teaching the SWC Python lesson, and since it’s become an
indispensable tool for doing my own research, I made use of the iPython Notebook .
To help combat the problem of learners getting behind and needing to see content
that I’ve since scrolled past, I did all my work out of a Dropbox folder
and shared a link to my notebook file on the etherpad. Although a good idea, the
biggest problem was that most learners couldn’t figure out how to view the file,
since downloading and clicking on it usually results in it being opened in a
text editor (they’re JSON files), leading to more confusion than answers.
What’s more, it’s hard for many learners to find their working directory (where
they’re working in a GitBash / terminal shell session) in the graphical file
manager, so telling them to download the file and move it to the directory
their notebook session is running from results mostly in blank stares.
Fortunately one of our helpers added the notebook link to NBViewer , which
renders the notebook directly in the browser so the students didn’t need to
bother with the file at all. This required some fiddling to ensure that
NBViewer actually picked up the updates whenever I saved my working notebook,
but otherwise it worked extremely well . The students very much appreciated
being able to click the nbviewer link in the etherpad and view my entire
running notebook, hitting refresh to see it as it updates. I should note,
however, that the time between me saving and the updated notebook showing up on
refresh was at least a couple minutes; Thomas did some troubleshooting on this
front to try and fix this, but I don’t think we managed much better than this.
But I’ll take that over nothing! :D
I’ve since removed the Dropbox share, but the final notebook can be viewed
here .
After the session on Day 1, I cleaned up the working notebook. I didn’t
add anything that wasn’t discussed in the session, but instead recorded more
of my commentary in the notebook itself since there wasn’t time to record
it live. The learners appreciated this the next morning, especially with
the NBViewer updates, since they could refer back to what we had done
in case their notebooks were missing things we would need that day.
I made a conscious effort on Day 2 to slooooow doooowwn, and I think I succeeded.
We ended up making it to the goal, which is how to write Python scripts that
behave like shell commands (showing that shell commands are not magic, and
you, YES YOU !, can write your own!). The feedback was generally more positive
on this day, and the discussions that followed indicate that people were happy
with what they had spent the time learning.
Thomas closed out the day with a lesson on Git. Despite it being his first
time teaching that particular lesson (it didn’t show!), he went at a good pace
and we were able to get through pair-wise collaboration on a publicly hosted
git repository (using GitHub ). Among the teaching tools
I plan to steal from him is his analogy of commits as group photos. That is,
putting things in the staging area can be thought of as bringing people into
the frame of the photo (and perhaps excluding others), while the commit is
taking the photo itself and then clearing the frame.
It was great to meet and learn from the learners, helpers, and my fellow
instructors. I got the full Oklahoma experience , too little sleep,
and plenty of ideas for next time. Looking forward to many more!
Thanks especially to our host Dana Brunson for putting this together!
— david