Teaching

Announcing ipythonblocks.org

jiffyclub, , Leave a comment

Way back…

About a year ago, inspired by Greg Wilson, I wrote ipythonblocks as a fun way for students (and anyone else!) to practice writing Python with immediate, step-by-step, visual feedback about what their code is doing. When I’ve taught using ipythonblocks it has always been a hit—people love making things they can see. And after making things people love to share them.

Sometime last year Tracy Teal suggested I make a site where students could post their work from ipythonblocks, share it, and even grab the work of others to remix. Today I’m happy to announce that that site is live: ipythonblocks.org.

How it works

With the latest release of ipythonblocks students can use post_to_web and from_web methods to interact with ipythonblocks.org. post_to_web can include code cells from the notebook so the creation process can be shared, not just the final result. from_web can pull a grid from ipythonblocks.org for a student to remix locally. See this notebook for a demonstration.

Thank you

There are many people to thank for helping to make ipythonblocks.org possible. Thanks to Tracy Teal for the original idea, thanks to Rackspace and Jesse Noller for providing hosting, and thanks to Kyle Kelley for helping with ops and deployment.  Most of all, thanks to my family for putting up with me working at a startup and taking on projects.

Announcing ipythonblocks.org

Broadcasting IPython Notebooks

jiffyclub, , 2 Comments

A useful feature of the IPython Notebook is that you can set the server to broadcast so that others on your local network can see the server and your notebooks. This is especially nice as a teacher so that students can load your notebooks as you work, copy text out of them, and see them in their entirety instead of just what you have on screen. Here’s the outline of what to do, with detailed instructions below:

  1. Create an IPython profile with a password for the Notebook server.
  2. Figure out your IP address on the local network.
  3. Launch IPython in broadcast + read-only mode using your new profile.
  4. Have your students navigate to your Notebook server.

Continue reading “Broadcasting IPython Notebooks” →

Broadcasting IPython Notebooks

Teaching with ipythonblocks at UW

jiffyclubLeave a comment

I’ve got a blog post up over on the Software Carpentry blog about trying out ipythonblocks in the classroom for the first time. Summary: it was a hit! The students really got a lot out of being able to immediately see the result of their code. We also did a lot of “what do you think this will do?”, which I think helped get the students thinking a bit more computationally. Some of the more advanced students even struck off on their own making their own designs instead of just sitting there bored.

I’m really looking forward to using ipythonblocks again at my next boot camps in May, and I hope others get some use out of it in the meantime!

Teaching with ipythonblocks at UW

Approaching git from svn

jiffyclub, , 1 Comment

“Yield and overcome” – Lao Tsu, Tao Te Ching

Over the past year or so I have on a few occasions taught git to people
accustomed to using Subversion. These are experienced software developers so it
seems like it should be easy, but it is almost always a difficult process
filled with acrimony, resistance, and gasps. (And this from people who seem
to use Emacs, vim, and Linux without complaint.)

And yet when I teach git to people who don’t already have a preferred
version control system it seems to go pretty well. It takes time, and there
may be confusion, but we demo and practice and learn as with any topic.
There is no hate. I think I’m beginning to understand the situation:

  1. Git and svn are different.
  2. People do not like their workflow changed.

Git isn’t just a little different, it’s completely different. But, dear
svn users, git is not different because it doesn’t like you. Git is different
because it’s optimized to facilitate the collaboration of a number of
developers working on a rapidly changing code base. Some examples:

  • Branching is easy in git so that you can work in peace isolated from
    upstream changes until you are ready to send your work back.
  • When it’s time to merge back git provides rebase to facilitate cleanly
    integrating upstream changes.
  • Git is distributed so that you and everyone else can make all manner of
    branches and experiments without dirtying up the master repo.

Git is different from svn, but it does well what it is designed to do.
This brings me back to the Lao Tsu quote from the top and a simple message
to svn users learning git: You will have to drop your svn workflow to make
the most of git, but it’s not because git is bad, it’s just different. Yield,
use git in the way it was meant to be used, and be happy.

Approaching git from svn

ipythonblocks – A Visual Tool for Practicing Python

jiffyclub, , , 3 Comments

Learning to program and learning the basics of control flow can be tricky business for novices. I wanted to make something that provided immediate, visual feedback to students as they practice things like for loops and if statements so they can see precisely what their code is (or isn’t) doing. So I wrote ipythonblocks.

The IPython Notebook makes it possible to display rich representations of Python objects using HTML (among other things). That allowed me to make a Python object whose representation in the Notebook is a colored table. Students can index into the table to change the color properties of individual table cells and then immediately display their changes.

With ipythonblocks instructors can give coding problems like ‘turn every block in the third column red’ or ‘turn every blue block green’ and by displaying their blocks students can see right away whether their code is having the desired effect.

Check out the demo notebook to see ipythonblocks in action.

ipythonblocks – A Visual Tool for Practicing Python

Wanted: Testing Frameworks in the IPython Notebook

jiffyclub, , Leave a comment

As a tool when teaching unit testing it would be great to have a way to run nose or pytest in an IPython Notebook. For example, a %nosetests magic would do test collection in the Notebook namespace and do its usual run and reporting. Of course it’s always possible to write test functions and then just call them, but having a report that compiles everything in one place is nice. Plus it could look just like nosetests called from the command line.

Unfortunately for this idea these testing frameworks have for the most part been engineered for doing their test collection using the file system as the starting point. In a couple hours of fiddling I couldn’t figure out how to use either nose or pytest to do test collection in a notebook. I’m sure it could be done with enough hacking.

Just for kicks, though, I threw together a little IPython line magic that does its own limited test collection, running, and reporting. You can see it via nbviewer and grab it on GitHub. This magic only grabs functions that begin with “test” and the reporting doesn’t include tracebacks when there are failures or errors. But you do get the exceptions themselves.

(This whole experiment was inspired by a conversation on Twitter.)

Update: On the advice of @stefanvdwalt I put the %runtests magic into a .py file so it can be installed via %install_ext:

%install_ext https://raw.github.com/gist/4013594/runtests.py

Once that’s done you can run

%load_ext runtests
%runtests

to have it do its limited collection, running, and reporting as in this demo notebook.

Update 2: Someone has made this work with nose: https://github.com/taavi/ipython_nose!

Wanted: Testing Frameworks in the IPython Notebook

Teaching with the IPython Notebook

jiffyclub, , 2 Comments

For a few months now I’ve been using the IPython Notebook as my primary teaching tool for Python topics. Within Software Carpentry we’re also switching over to using the Notebook for both in-person bootcamps and our online repository of material. Ethan White and I put together a post on this topic on the Software Carpentry blog and now Titus Brown has blogged with his own thoughts. We’ve put in a PyCon proposal for a panel on this topic in 2013.

The IPython developers have to be given a huge amount of credit for putting together the Notebook and the rest of IPython. The Notebook especially is quite a feat: a top notch research/engineering/teaching tool all in one. And they aren’t resting on their laurels, they have a ton of ideas in mind for the Notebook in the future, including a slide-show mode. I’m definitely looking forward to seeing what they’ve got!

As with many open source projects, the IPython developers struggle to find the time and funding to write their software. If any open source project is helping with your job or your research you can easily help by citing the software in your papers and in public on social media or blogs. This gives the developers more ammunition the next time they’re writing grants, so please make your support known!

Teaching with the IPython Notebook

Software Carpentry at Johns Hopkins

jiffyclub2 Comments

This week Joshua Smith and I hosted a Software Carpentry boot camp at Johns Hopkins University in Baltimore. We also had awesome teaching help from Sasha Wood and Mike Droettboom.

We opted for a small class since this was our first time hosting a boot camp and because of space limitations. Based on the rate at which people signed up for the class it didn’t seem like there was massive local demand anyway, but we were pleasantly surprised when we had a student from Brooklyn, NY and a student commuting from Virginia. There is definitely some existing demand for the skills Software Carpentry offers and I’m glad we could put on an accessible boot camp for those people.  Most of the rest of the students were physics and astronomy grad students or post-docs from JHU and STScI.

The boot camp was broken into four half-day courses: shell, Python, version control, and software engineering. Mike and I co-taught the Python and software engineering sessions.

The overall feedback from the students was quite positive and I’m looking forward to doing this again. (Here is the requisite good/bad Software Carpentry feedback post: http://software-carpentry.org/2012/06/feedback-from-johns-hopkins/.) Below I have some notes on the sections I taught, plus some overall thoughts. Continue reading “Software Carpentry at Johns Hopkins” →

Software Carpentry at Johns Hopkins

Teaching Python at Software Carpentry – Toronto, February 2012

jiffyclub3 Comments

Last week I had the privilege of teaching Python (and generally helping out) at a Software Carpentry bootcamp at the University of Toronto. Mike Fletcher and I worked together to make a lesson plan targeted at students completely new to Python. Overall it was a great experience and I had a lot of fun meeting some other Pythonistas. Here I’d like to talk about some lessons learned from our teaching. (Update: Mike has written up his thoughts as well.)

The overall narrative of our lessons was that they were trying to read a CSV data file. We built up the very basics (data types, if, for) up through functions and modules in a total time of about 5 hours. We tried to alternate between a few minutes of lecturing and a few minutes of exercises that students typed and ran on their own computers using template files we had given them. I think we built a good narrative and I particularly liked how we segued into writing functions, writing modules, and re-using code. However, for the time available and the students we had I think we could make improvements.

Our students were mostly science graduate students. They were largely not experienced programmers and none of them (as far as I know) had experience with Python. We had just a few hours with them, though they will be continuing with online lessons. Our particular failing in this situation was that the complexity of our exercises quickly outpaced the experience of our students, making them confused and slowing everything down. When I do this again I will probably iterate on the same content but update the exercise templates to be much more filled in, requiring the students to fill in only a couple of key lines. This will hopefully allow us to move through more content in less time without sacrificing much in terms of what the students practice.

Teaching in such a short amount of time is a challenge. How much time do you spend selling Python, all the great modules in the standard library, and the great third-party packages that make Python an excellent choice for scientific computing? If you do some really compelling demos maybe the students will be more inspired to continue using Python on their own and it won’t matter that you’ve sacrificed time you could have spent teaching them the basics. How much time do you spend teaching them about installing and managing Python and third-party packages? It’s hard to make a case that you should teach this at all in the first class but it’s bound to come up for everyone when they stumble across cool-package-X.

I definitely feel some initial demos are in order, just enough to say, “Look, you can do all this great stuff with Python!” Then you’ve got to start teaching something and keep it moving as you do.

The Udacity Teaching Model

I’m currently taking CS373 at Udacity (they also offer CS101). They have a pretty cool teaching model with a few minutes of instruction followed by short quizzes so that you get immediate feedback on how you’re doing. The quizzes even involve programming: you’re given a nice text editor (implemented in JavaScript, I believe) that does nice syntax highlighting and automatic indenting. It’s usually pre-populated with some starting code and test variables. You write your code and click “Run” to see the output. When it’s satisfactory you click “Submit” to have your output scored against what is expected. If you like you can write your code in your own editor/environment and copy it back when you’re ready to submit.

The Udacity classes are not live but I can imagine a similar tool being useful in a live classroom setting because it gives the teacher the chance to see what students are writing and what output they’re getting. The code is run on the server side so it can be consistent for everyone. And though it’s not an ideal development environment, it does help for students who might not have Python installed on their computers. One drawback is that I don’t know how it would work when it comes to teaching students to read and write files.

Teaching Python at Software Carpentry – Toronto, February 2012