Way back when, I used to take delight in following the creative tech output of Jon Udell, then at InfoWorld. One of the things I fondly remember is his Heavy Metal Umlaut screencast:
You can read about how he put it together via the archived link available from Heavy metal umlaut: the making of the movie.
At some point, I seem to remember a tool became available for replaying the history of a Wikipedia page that let you replay its edits in time (perhaps a Jon Udell production?) Or maybe that’s a false memory?
A bit later, the Memento project started providing tools to allow you to revisit the history of the web using archived pages from the Wayback Machine.Memento. You can find the latest incarnation here: Memento Demos.
(Around the time it first appeared, I think Chris Gutteridge built something related? As Time Goes By, It Makes a World of Diff?)
Anyway – the Heavy Metal Umlaut video came to mind this morning as I was pondering different ways of using Jupyter notebooks to write programmes.
Some of my notebooks have things of this form in them, with “finished” functions appearing in the code cells:
Other notebooks trace the history of the development of a function, from base elements, taking an extreme REPL approach to test each line of code, a line at a time, as I try to work out how to do something. Something a bit more like this:
This is a “very learning diary” approach, and one way of using a notebook that keeps the history of all the steps – and possibly trial and error within a single line of code or across several lines of code – as you work out what you want to do. The output of each state change is checked to make sure that the state is evolving as you expect it to.
I think this approach can be very powerful when you’re learning because you can check back on previous steps.
Another approach to using the notebooks is to work within a cell and build up a function there. Here’s an animated view of that approach:
This approach loses the history – loses your working – but gets to the same place, largely through the same process.
That said, in the notebook environment used in CoCalc, there is an option to relay a notebook’s history in much the same was as Memento lets you replay the history of a web page.
Yuvi Panda started sketching a similar tool for classic notebooks — https://github.com/yuvipanda/nbtimetravel — but it never get as far as the replay component and has long since been archived.
Another way of recreating history is to walk someone through a completed notebook using a screencast. The https://github.com/willkessler/jupytergraffiti classic notebook extension takes this idea a step further and lets you record actions and commentary over a notebook.
In JupyterLab, the https://github.com/jupyterlab-contrib/jupyterlab-tour extension gives a tour of the UI. If a workspace is predefined to present a particular open notebook, for example, could we use a tour to walk through the notebook, I wonder?
In practice, I tend to use both approaches: keeping a history of some of the working, whilst RPLing in particular cells to get things working.
I also dip out into other cells to try things out / check things, to incorporate in a cell, and then delete the scratchpad / working out cell.
I keep coming back to the idea that Jupyter notebooks are a really powerful environment for learning in, and think there’s still a lot we can do to explore the different ways we might be able to use them to support teaching as well as learning…:-)
PS via Simon Willison, who also recalled a way of replaying Wikipedia pages, this old Greasemonkey script.
PPS Sort of related, and also linking this post with [A] Note On Web References and Broken URLs, an inkdroid post by Ed Summers on Web Histories that reviews a method by Prof Richard Rogers for Doing Web history with the Internet Archive: screencast documentaries.
3 thoughts on “Programming in Jupyter Notebooks, via the Heavy Metal Umlaut”
I will often design a notebook for exploration. That is, the contents of each cell are carefully thought about in order to give the “reader” (not a good word… how about “computist”) hints that “these all go together” and “here is a place to stop and explore”. However, students will typically just run through the contents as-is. I have to explicitly teach them that “adding a cell here and here to interactively explore” is part of their job.
The exploration style differs from those notebooks created by Russell Norvig (https://github.com/norvig/pytudes#pytudes-index-of-jupyter-ipython-notebooks). These notebooks are wonderful, but don’t leave a lot of room for exploration. The code is tight, and much of the really interesting ideas that are only a step away are already in the notebook. They are great reading, but I find them less useful for the exploration style.
There is also another mode, but only made possible via extensions. I’m thinking of widgets that put an app in the middle of a notebook. With these, you need to interact with the widget without creating additional cells, and it doesn’t leave any history. Some of these widgets even have a command-line, so they are sorta like a notebook inside of a cell.
Thanks for those comments DOug – I need to write up how we did our notebooks for a third year database/data analysis course and on the Learn to Code for Data Analysis FutureLearn MOOC.
One thing I’m going to explore more in new year is “magics that unpack”, showing how to do a lot with a single line of magic, and then starting to explore how the magic is put together. This gives you a way in with a single line that does a lot to code you can start to explore and maybe extend. An example of a possible magic is here – https://blog.ouseful.info/2017/12/13/extending-the-folium-magic/ – but I also have ideas around magics that pull in data, generate charts from data etc; just not had time to even explore a proof of concept demo on that yet:-(
@Doug: re: “design a notebook” – yes, I think in terms of designing a notebook for use as a piece of educational material too…
Comments are closed.