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
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.
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.
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:
- Create an IPython profile with a password for the Notebook server.
- Figure out your IP address on the local network.
- Launch IPython in broadcast + read-only mode using your new profile.
- Have your students navigate to your Notebook server.
Read More »
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!
“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:
- Git and svn are different.
- 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.
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.
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.
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
Once that’s done you can run
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!
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!