Jupyter Blog - education

Positron Server available for academic use via JupyterHub

2026-07-29T18:19:00+00:00

Editor’s note: This is a guest blog post from Posit, a Jupyter Foundation member

Academic institutions can now offer Positron directly within their existing JupyterHub environments, giving students access to a modern, full-featured data science IDE without requiring local installation or additional infrastructure. Licensed under the permissive, source-available Elastic License 2.0, Positron as a desktop app is free for everyone to use, build on, and extend across personal, academic, and commercial projects. Through a free educational license, universities and other academic organizations can additionally make Positron Server available to currently enrolled students for coursework, helping create a consistent learning experience across classrooms, labs, and remote environments.

By integrating Positron into JupyterHub, educators can provide students with a powerful development environment alongside the tools they already use. Students simply launch Positron from the JupyterHub interface, just as they would open JupyterLab or a different environment, and can begin working immediately.

Bringing a Modern Data Science IDE to the Classroom

Positron combines the familiarity of notebook-based workflows with the capabilities of a professional integrated development environment (IDE). Once launched through JupyterHub, students have access to the complete Positron experience, including:

Comprehensive support for both Python and R
Access to the OpenVSX extension marketplace
Built-in data viewer and variables explorer
Integrated help pane, debugging tools, and version control
Advanced development features that help students grow their data science skills over time

This approach allows instructors to standardize course environments while reducing the technical barriers often associated with software installation and configuration.

Designed to Work with Existing JupyterHub Deployments

Positron Server is built to integrate directly into existing JupyterHub environments, making adoption straightforward for administrators already managing Jupyter-based infrastructure.

The solution is compatible with:

JupyterHub deployments running JupyterLab 4
Python 3.9 and later environments

Installation is provided through the jupyter-positron-server Python package, which is built on Jupyter Server Proxy. For administrators who have previously configured services within JupyterHub, the setup process will feel familiar.

Rather than functioning as a standalone desktop application, Positron Server extends existing JupyterHub deployments by making the Positron IDE available as another launch option within the environment.

Free Educational Licensing for Teaching

Academic institutions using Positron for instructional purposes are eligible for a free teaching license. Under this license, access can be provided to:

Currently enrolled students
Course participants
Faculty and staff involved in delivering educational programs

This licensing model enables institutions to incorporate Positron into coursework without additional software costs, helping educators provide professional-grade tools to learners.

Getting Started

Institutions interested in offering Positron through JupyterHub can get started in three simple steps:

Review the eligibility requirements outlined in the Positron Education License Rider.
Contact Posit to request a free teaching license.
Follow the jupyter-positron-server installation and configuration documentation to deploy Positron within your JupyterHub environment.

Supporting the Next Generation of Data Scientists

As data science and computational research continue to grow across disciplines, educational institutions are looking for ways to provide students with professional tools that are easy to access and manage. By bringing Positron directly into JupyterHub, universities can deliver a modern, scalable development environment that supports both teaching and learning while minimizing setup complexity.

Whether students are writing Python code, analyzing data in R, or exploring advanced development workflows, Positron Server helps create a seamless experience from the first day of class through more advanced coursework and research projects.

Navigating the Post-Workshop Fog: a Path to Myst

2026-07-09T15:15:00+00:00

From June 15th to 17th 2026 a Jupyter Workshop took place at Paris-Saclay University : “Demystifying MyST Markdown in education”. The workshop combined presentations in the mornings with collaborative sprints during the afternoons. It has been funded by the Jupyter Foundation and SaclAI-School.

Milestones

Improving documentation and tools for easier deployment even for non-specialists

Freek Pols from Delft University and Brigitta Sipočz form CalTech presented some examples and challenges in publishing courses and documentation at large scales. Angus Hollands, MyST maintainer, made an in depth presentation of Myst and JupyterBook2. Guided tutorials introduced participants to complete a Jupyter Book workflow. The participants learned how to create their first Jupyter Book, and how to publish it.

Text notebooks as first citizens

Marc Wouts and Yahya Heni discussed the path from jupytext to jupyter-plainb to open and execute plain markdown text notebooks directly in Jupyter Lab. Two Jupyter Enhancement Proposals (JEP) has been discussed together with Jupyter Lab and MyST maintainers:

One step at a time

Over 30 issues and pull requests have been opened in the whole Jupyter ecosystem:

documentation items: for example, about text notebooks in jupyterlite or publishing on different hosting solutions;
feature requests: for example, single document feature in JupyterBook2, non-default application to open files in Jupyter Lab;
adopt JupyterBook2 for software documentation: for instance itables and travo.

Sidewalks

The workshop provided the opportunity to continue previous discussions about AI in education: some participants attended the workshop “AI in Jupyter” and were able to pick up the conversation from there.

Relationships between Academia and Open Source Software communities were also topic of conversation: about Open Source Program Offices (OSPOs) and how their action can be connected to education strategies.

Wandering

Collaboration is a matter of trust. That’s why it is still important for people to meet in person and to know each other. It is about exchanging details, like keys to decrypt characters and aspirations. One might discover a shared passion for shoes. Another may finally enjoy long French-style lunch breaks.

When the time comes to resume the path, important steps have already been taken in the right direction.

A Jupyter Workshop: Demystifying MyST Markdown in Education

2026-04-30T15:05:00+00:00

A new Jupyter Workshop is happening June 15–17, 2026 in Orsay, France. Demystifying MyST Markdown in Education is a three-day workshop organized by the Jupyter community, focused on helping science educators adopt Jupyter Book and the MyST document engine for their teaching materials.

What’s it about?

The workshop aims to remove barriers for educators who want to use Jupyter Book and MyST to publish accessible, reproducible pedagogical content. Here are the broad topics of each day of the event:

Teaching use cases and needs : what educators actually need from tools like Jupyter Book.
Contributor tutorials and onboarding : how to get involved with the project.
MyST Markdown as a text representation for Jupyter notebooks : writing and sharing computational narratives.

Attendees will learn how to contribute to the Jupyter Book community, collaborate with maintainers, and advocate for the needs of their users.

Have a look to the workshop agenda and if you have ideas you would like to be discussed there, please share them in the related issue.

Where and how to join

The workshop is hosted by Laboratoire Interdisciplinaire des Sciences du Numérique (LISN) and supported by SaclAI-School at Université Paris-Saclay.
Travel funding is available, apply here for travel funding.

Registration and full details are on the event page.

Thanks

A huge thank you to the whole Jupyter community supporting the event and to the Jupyter Foundation for making it possible.

Better sharing UX with nbgitpuller and contextual error handling

2026-04-09T15:02:00+00:00

TL;DR

nbgitpuller now has improved UX context-aware error handling. Update to version 1.3.0 and let us know what you think by opening an issue 🚀

What is nbgitpuller?

nbgitpuller lets you distribute content to a Jupyter user via the click of a button! This allows your users to focus on the content without needing to understand git or other version control machinery.

nbgitpuller provides automatic, opinionated conflict resolution by using git under the hood. It is commonly used to distribute content to multiple users of a JupyterHub, though it works just fine on an individual person’s computer, if they have Jupyter installed.

Here’s an example of nbgitpuller in action:

The author uses the nbgitpuller link generator to create a link.
The consumer clicks the link, and the content is pulled into a live Jupyter session.

Example use cases for sharing with nbgitpuller include:

Interactive demos
Workshop and training scenarios
University exams

and many more!

How does nbgitpuller work?

The nbgitpuller package is installed in the compute environment. The compute environment now has a /git-pull endpoint URL that can understand where to pull content from using URL parameters. Syncing content critically depends on git operations to fetch, checkout, clone, merge, commit, etc.

When it goes wrong

Based on the data sent through by the kind folks running the Berkeley DataHub, there were 2163 logs available, of which:

983 (45%) were ‘merge’ conflicts
493 (23%) were ‘fetch’ errors
467 (22%) were ‘ls-remote’ errors

Bar chart showing the most common errors users faced.

The remaining errors (10%) were mostly ‘checkout’ errors. This represents the most frequent errors as seen by students.

Bar chart showing the most unique errors link authors made.

In the same set of logs, there were 172 unique errors: most ‘ls-remote’ errors come from mistakes in the content repo URL. This represents the most uniquely common errors made by instructors.

Merge conflicts

If the link author changes content after the consumer clicks a link, then nbgitpuller needs to sync updates for the consumer on subsequent link clicks. The nbgitpuller merging strategy makes opinionated choices so that the link consumer never has to interact with git, and will always preserve the consumer’s working changes.

Things can go wrong when

Consumers can diverge the git history if they perform a git commit
Authors can diverge the git history if they perform force push commits

Error UX (old)

Old UX for merge errors.

Problems with the old UX include:

a scary terminal
difficulty for the user to figure out what went wrong
no suggestion for the user to fix the problem or a signpost to continue to the compute platform

Error UX (new)

New UX for merge errors.

New improvements to the UX include:

The terminal is closed by default, but you can optionally toggle it open
There is a copy to clipboard button to easily share the error log from the terminal
A more user-friendly and context-aware helper message is displayed
A link to the general documentation for reference
A ‘Proceed without syncing’ button takes the user to the compute platform without making any changes
In the case of merge errors, an extra Backup and resync button option is presented

Learn more

nbgitpuller documentation

Acknowledgements

UC Berkeley and the CloudBank Classroom project
CAL ICOR for co-funding this development work
Eric Van Dusen and Sean Morris for championing this work
Balaji Alwar for providing the error data and sharing feedback
Nicolas M. Thiéry for feedback on the UX design
cmarmo for contributing the ‘Backup and resync button’

JupyterLite Officially Joins Project Jupyter!

2026-02-12T16:14:00+00:00

We are thrilled to announce that JupyterLite is now an official part of Project Jupyter. This milestone marks a significant step forward for interactive computing in the browser and strengthens JupyterLite’s role within the Jupyter ecosystem.

What is JupyterLite?

JupyterLite is a JupyterLab distribution that runs entirely in your web browser. Kernels execute directly in the browser using WebAssembly, eliminating the need for an application server. This means:

Instant access: Start computing with a single click: no prior Python setup, environment configuration, or server management required.
Scalability: Host thousands of concurrent users from a static website (e.g., GitHub Pages) with zero per-user server costs.
Privacy and portability: Code and data remain in the user’s browser, making it ideal for embedding in documentation, tutorials, and interactive demos.

JupyterLite greatly expands the options available in the Jupyter ecosystem for education, documentation, and demos, where reducing friction is critical.

As Brian Granger reminded us during his JupyterCon 2025 keynote, Jupyter’s mission is “to empower people of all backgrounds to think, collaborate, and share knowledge using computational storytelling.” From this perspective, JupyterLite is a logical and key next step to take, letting Jupyter take advantage of the impressive strides made in recent years by the WebAssembly/JavaScript ecosystem (in reach and capability) to advance this mission. JupyterLite is an excellent complement to other forms of accessing Jupyter (whether through a local Python installation or a hosted infrastructure service), that facilitates new use cases and lowers barriers in many others.

Interactive computing in the browser with JupyterLite

The Journey of JupyterLite

JupyterLite’s development began in 2021, led by Jeremy Tuloup at QuantStack. Over the past four years, it has benefited from the dedication of several other team members, Martin Renou, Trung Le, and Ian Thomas — as well as invaluable contributions from community members like Nick Bollweg and many others.

Beyond the JupyterLite repository, the project includes comprehensive tooling for creating in-browser language kernels based on xeus. These kernels support languages like Python, R, C++, GNU Octave, Lua, and SQLite, sharing the same codebase as their backend counterparts, developed by Thorsten Beier, Isabel Paredes, Johan Mabille, and Antoine Prouvost. These kernels are built upon the emscripten-forge software distribution for WebAssembly. The project also includes a Python kernel based on Pyodide, and kernels for JavaScript and p5.js. This architecture means that the same language-agnostic model for kernels that Jupyter pioneered over a decade ago, carries over to the WebAssembly world.

The JupyterLite GitHub organization also features the JupyterLite Terminal, a terminal and shell emulator that runs entirely in the browser and was developed by Ian Thomas. It enables the use of basic Unix commands like grep, sed, cat, touch, and even vim or nano, all built to WebAssembly.

The JupyterLite terminal emulator, with basic Unix commands

JupyterLite now powers the official Jupyter website and is used by projects like numpy.org, sympy.org. It also underlies services such as Jupyter Everywhere and notebook.link.

A Natural Fit with JupyterLab

JupyterLite has always been closely tied to JupyterLab. It is increasingly becoming a set of JupyterLab extensions that replace core plugins to manage kernels, settings, and content in the browser. With contributors overlapping significantly with the Jupyter Frontends group, this integration formalizes what many in the community already recognized: JupyterLite is a core part of the Jupyter ecosystem.

The proposal to transfer JupyterLite to the Jupyter governance received strong support from the Jupyter community and by the Jupyter Frontends council.

Better integration with the rest of Jupyter

With JupyterLite now being an official part of Jupyter, it will be easier to find areas for better integration with other aspects of our ecosystem: we can reduce duplication, smooth out the documentation and model for creating and using both “traditional” (server-hosted) and WebAssembly kernels, and make JupyterLite a natural instant-access component of MyST/JupyterBook-based sites, and more.

Mission-wise, JupyterLite is a natural next step for Jupyter, and having it be an official part of the project makes it much easier for the community to integrate its benefits throughout. We hope you’ll try it, use it and contribute to its growth!

Try it in your browser

If you would like to try JupyterLite in your browser, click on the following link:

Acknowledgments and team credits

JupyterLite’s success is thanks to the support of individuals and organizations who believed in its vision. This includes:

QuantStack, for their continued investment in the project since 2021 and the broader Jupyter ecosystem,
Bloomberg, for funding improvements to JupyterLite by QuantStack since 2023,
The Gates Foundation, for funding the development of the xeus-R kernel and its port to WebAssembly,
The Pyodide project, whose pioneering work on Python in the browser via WebAssembly made JupyterLite possible.

Key developers to this stack include:

Jeremy Tuloup (Director at QuantStack, creator of JupyterLite, and JupyterLab maintainer),
Nicholas Bollweg (JupyterLite maintainer and #2 all-time committer),
Martin Renou (Director at QuantStack, JupyterLite maintainer, responsible for integrating xeus with emscripten-forge, and creator of JupyterLite-Sphinx),
Thorsten Beier (Software developer at QuantStack, lead developer of emscripten-forge, and xeus-lite),
Isabel Paredes (Software developer at QuantStack, led the packaging of R and GNU Octave in Emscripten-forge),
Anutosh Bhat (Software developer at QuantStack, C++ kernel in the browser),
Ian Thomas (Software developer at QuantStack, creator of the JupyterLite terminal, and the cockle shell emulator),
Johan Mabille (Director at QuantStack, creator of xeus),
Agriya Khetarpal (Pyodide contributor, JupyterLite-Sphinx maintainer),
Albert Steppi (JupyterLite-Sphinx maintainer).

Thank you for being part of this journey, we cannot wait to see what you build with JupyterLite!

Desktop GIS software in the cloud with JupyterHub

2023-08-02T16:23:00+00:00

👋 We are Trey Stafford and Matt Fisher, co-authors of the QGreenland data package’s source code. This year, we had the pleasure of running a hands-on geospatial data and open science QGreenland Researcher Workshop. It was important for attendees to participate in the workshop in a hands-on way while minimizing the negative impacts of installing software, requiring expensive personal computers, and troubleshooting unique computer configurations. We felt a JupyterHub was a good fit for our workshop for this reason, if it could accommodate our need for running QGIS — a desktop application.

In this blog post, we will introduce QGreenland, describe our experience using JupyterHub in the cloud for our workshop’s computing environment, and discuss challenges we overcame to enable our attendees to use QGIS in a cloud graphical desktop environment. Finally, we will highlight some workshop outcomes and discuss opportunities for enhancement based on new developments in the Jupyter ecosystem.

In our workshop, 25–30 international learners (including from Germany, India, France, Canada, Poland, and the United States) used QGIS in a JupyterHub’s browser-based Linux desktop environment to collaboratively test, explore, visualize, and process Earth science data simultaneously with the same user experience they expect from using QGIS on their personal computers! Better yet, getting started was as simple as logging in. Our workshop was a success story not just in education, but also in open source and collaborative development, and we want to share what we learned.

Note the browser tabs at the top of this screenshot; this is a full desktop-based GIS environment running QGreenland in the cloud!

The JupyterHub used by the QGreenland 2023 Researcher Workshop was generously provided by the NASA CryoCloud team, whose mission is to help researchers transition to cloud-based collaboration.

About QGreenland

QGreenland is an open-source Greenland-focused geospatial data package for QGIS, a community-owned graphical Geographic Information System (GIS) platform. Researchers and members of the public leverage QGreenland’s ready-to-use interdisciplinary datasets to do field planning, teach about glaciers, and much more.

QGreenland’s MIT-licensed source code uses community-maintained open software like GDAL and PyQGIS to automate data normalization and populate the QGIS project with important information like data provenance and the order of layers in the QGIS Layers Panel. Check out our documentation to learn more! QGreenland also has a YouTube channel with tutorials produced by CIRES Education and Outreach.

Once QGIS is installed, opening QGreenland is as easy as double-clicking the included “.qgs” file. Here, a representative view of QGreenland v3 alpha in QGIS is displayed with newly updated layers: Arctic sea routes (National Geospatial Intelligence Agency), bathymetric depth (General Bathymetric Chart of the Oceans (GEBCO)), and ice thickness (IceBridge BedMachine Greenland v5) layers.

Based on user research, QGreenland has enabled:

the public to more easily access data gathered by researchers visiting Greenland: “In Greenland, people are often asking, ‘how can we find the data the foreign scientists bring back from Greenland?’ Now we can directly utilize much of it.”
researchers to plan field work: “Being able to use QGreenland at our field station was critical to our research process!”
educators to develop interactive lessons about Greenland and climate change: “…using QGreenland for presentations because it is presentation quality already.”

QGreenland’s 2023 researcher workshop

One of the QGreenland team’s most important forms of direct user interaction and support is facilitating workshops. Most recently, we hosted a 3-day (total of 9 hours) virtual workshop for researchers focused on working with geospatial data in an open science framework. All of the materials covered in the workshop were built using open-source tools and are MIT-licensed and published on GitHub.

A “personal computer” in the cloud

We decided early on that we wanted to use JupyterHub to solve the diverse problems that come with “bring your own device” workshops. We experimented with administering our own JupyterHub on Kubernetes, but the setup overhead was too high for our short workshop. CryoCloud’s JupyterHub enabled us to avoid this overhead and focus on serving our participants. Because the software that comprises CryoCloud is open-source and developed in collaboration with the communities CryoCloud serves, we could directly contribute to curating a computing environment ideal for our participants.

JupyterHub is known for providing access to Jupyter Notebooks via JupyterLab, but it turns out it can also be used to host pretty much any interactive web based application! The jupyter-server-proxy project enables this, and there are additional packages that make running specific applications easier. jupyter-rsession-proxy makes it easy to run RStudio inside JupyterHub, jupyter-vscode-proxy allows running code-server (fully open source self-hosted version of Visual Studio Code) inside a JupyterHub, etc. Pertinent to our use case is jupyter-remote-desktop-proxy, which lets you run a complete Linux desktop environment inside your JupyterHub! This was critical for our workshop, as it allowed us to use QGIS — purely desktop software, not adapted for the web — from inside a web browser. Workshop participants did not need to install anything. This enabled participants to focus on the content of our workshop rather than the logistics of setting up and debugging tools on their varied machines.

The CryoCloud JupyterHub enabled each of our workshop participants to provision their own compute environment (JupyterLab + Linux Desktop) with all of our workshop’s dependencies pre-installed. It also set everyone on equitable footing — someone accessing the workshop on a 10 year old laptop would get the same computing resources as someone on a brand new MacBook Pro.

Challenges scaling QGreenland

The CryoCloud JupyterHub already had jupyter-remote-desktop-proxy and QGIS installed, so we could validate this approach to our workshop quickly. However, to use QGreenland at this scale, we needed to solve a couple of usability problems. The first issue was a user experience problem: the operating system did not have appropriate file type associations for QGIS, so files like the QGreenland project file would not open in QGIS when double-clicked in the desktop file browser. We quickly discovered a solution and integrated it with a simple pull request to the Docker image we were using.

The second problem was a performance problem: QGIS would take several minutes to open QGreenland from the hub’s shared storage drive. After some investigation, it turned out this was due to us loading multiple GB of data from an NFS share! While a long term solution might involve getting QGIS to load data directly from cloud object storage (like S3), we instead decided to go a different route — provision each user a small, fast and temporary Elastic Block Store disk. At the start of the workshop, we provided all users a small script that would copy the dataset from NFS to this faster disk once, and this drastically reduced load times from about 5 minutes to under 3 seconds! You can follow our debugging process on this issue, and find the JupyterHub config used to provision these disks here.

By overcoming these challenges, we created a smooth, intuitive, and performant computing experience for all of our participants, most of whom had never been exposed to this sort of collaborative computing environment.

Outcomes

The workshop participants engaged in small group work to complete various exercises, group discussions, and data scenarios. Each group produced Jupyter Notebooks and GitHub Discussions posts as deliverables. We created an outcomes webpage to summarize our participants’ accomplishments. One highlight was participants’ insightful commentary on FAIR & CARE principles.

Based on these outcomes, we consider our workshop a success. While we put in a significant amount of time creating our materials, CryoCloud’s cloud costs and our time investment in preparing computing resources were relatively small. For approximately 25 people, our cloud costs break down to roughly $1/person/day!

Conclusion

The CryoCloud JupyterHub met our workshop needs and provided a delightful experience for administrators and participants alike, and we are excited for what’s next. JupyterLab 4 and jupyter_collaboration v1.0.0, a real-time collaboration extension, were just announced, and the CryoCloud team is currently working to integrate these new releases into their hub. Real-time collaboration will enable exciting cloud use cases, like small groups working together on the same notebook without a screen share, or organizers providing technical support in a live notebook. We anticipate running this workshop again. We are excited to use JupyterHub again and look forward to experimenting with these new features!

Acknowledgements

Reviewers

In alphabetical order, thanks to Twila Moon, Yuvi Panda, Tasha Snow, and Alyse Thurber for their time contributing to this post!

CryoCloud

Snow, Tasha, Millstein, Joanna, Scheick, Jessica, Sauthoff, Wilson, Leong, Wei Ji, Colliander, James, Pérez, Fernando, James Munroe, Felikson, Denis, Sutterley, Tyler, & Siegfried, Matthew. (2023). CryoCloud JupyterBook (2023.01.26). Zenodo.https://doi.org/10.5281/zenodo.7576602

2i2c

2i2c is a non-profit organization that runs open-source infrastructure for collaborative computing, and maintains the CryoCloud JupyterHub used in this workshop. You can see the complete configuration of this JupyterHub in this public repository.

Introducing “Learn Python with Jupyter”

2023-04-28T06:14:00+00:00

Learning a programming language is about learning a language. When learning a new language (such as French, Korean, etc.), we commonly learn two key components: a way of thinking–which is typically connected to a culture–and grammar–that is, how to arrange elements of speech (verbs, nouns, etc.) to create coherent sentences. Each aspect usually has a dedicated book. We study how to greet people, order a coffee, and ask for directions on the streets–that is, how to behave and think in that language–in course books. At the same time, we deepen and refine our grammar knowledge in grammar books, where chapters explain elements of speech providing detailed rules, list of exceptions, and short disjoint examples.

Books to learn programming languages typically follow a grammar book format. Each chapter covers a different aspect of coding grammar (such as data structures, loops, etc.) with brief examples that frequently use mathematics. Finding course books that gradually teach to think in a coding language is rare.

Learn Python with Jupyter is intended as a course book to help develop computational thinking while learning to code in Python. Similar to language course books, each chapter starts with a story (or a few long examples) to introduce a new topic, while providing context and favoring pattern memorization (Fig. 1A). In coding, stories are possible thanks to Jupyter notebooks, which allow seamless integration of narrative and code in the same file. Each story is accompanied by code pronunciation, as pronunciation affects thinking (e.g., = should be pronounced as “is assigned”, not as “equals”). Code and concepts presented in the story are then thoroughly described and definitions are highlighted in colored boxes (Fig. 1B). Learners have the possibility to elaborate on the presented topic with theoretical quizzes and exercises (True or false, Match the sentence halves, etc.) as well as coding exercises of increasing difficulty (Fig. 1C). Chapters finish with bullet-point recaps reformulating the latest concepts (Fig. 1D), and with a “More in depth session” addressing error management, good practice, and coding suggestions (Fig. 1E).

The order of topics presented in Learn Python with Jupyter supports development of computational thinking by progressing from spoken language to abstract symbols and constructs. The very first chapters (1–5) introduce strings as English words, followed by lists of strings, if/else conditions, and basic methods for list manipulation. The following chapters (6–12) explain slicing as an abstract alternative to list methods and the for loop as an automatic way to slice list elements. These chapters mark the transition from concrete to abstract thinking, after which more complex topics are explained. The remaining chapters (13–38) introduce numbers, more coding syntax and constructs (e.g., while loop, dictionaries, functions, etc.), and typical aspects of coding, such as “divide and conquer”, “debugging”, etc.

Figure 1. Chapter sections in Learn Python with Jupyter

Learn Python with Jupyter aims at enabling absolute beginners–who have never been exposed to any programming language–to learn coding. This aim is supported by the conviction that everybody, regardless of social circumstances or gender, has the right to become digitally literate and acquire awareness of the increasingly digitalized world we live in. The book is free and is currently halfway finished. A new chapter is released on learnpythonwithjupyter.com every 4–6 weeks along with the related Jupyter notebook.

Jupyter Community Workshop: Jupyter for Education

2022-12-05T23:37:00+00:00

We are excited to announce the next in-person Jupyter Community Workshop! It will focus on the use of Jupyter for Education.

The event will be held at the Conservatoire National des Arts et Métiers (CNAM) headquarters in Paris, France, from January 24th to January 26th, 2023. Funding for travel expenses is available for attendees from academia and those from groups which are not well-represented in the Jupyter and wider tech community!

Jupyter Community Workshop are a series of community-organized events to tackle challenging development and design projects, growing the community of contributors, and strengthening collaborations.

This workshop will focus on the use of Jupyter for education. The goal is to bring together contributors, and community members to further the development of Jupyter-based tools and practices for education. Given the broad variety of topics relevant to this workshop (pedagogical practices, automatic grading, deployment challenges), we will compose the program based on the attendance. We are also planning an installment of the PyData Paris meetup at CNAM on the 26th of January, with a focus on open-source tools for education.

The workshop will last three days, with hands-on discussions, hacking sessions, and technical presentations. The goal of this event is to foster collaboration and the sharing of knowledge between Jupyter maintainers and downstream library authors and power users.

Should you be interested in joining us for this workshop, please fill this form. A limited number of spots are available for this event.

We are grateful to CNAM for hosting us and to INRIA for supporting this event. We are also grateful to the sponsors of the Jupyter Community Workshop series, Bloomberg and Amazon AWS.

Avion III de Clément Ader, at the CNAM — photo by Roi Boshi for Wikimedia Commons

Upgrading Nbgrader

2022-09-15T07:51:00+00:00

Project Jupyter provides a broad collection of open-source tools for interactive computing that has become ubiquitous in data science and scientific computing, and is very popular in educational contexts.

Nbgrader, started by Jessica Hamrick in 2014, is an extension for creating notebook-based assignments, online courses, and for auto-grading these assignments. It is central to many Jupyter-based services used by teaching institutions.

As a large part of the Jupyter user base has adopted the JupyterLab frontend, most of the popular extensions to the classic notebook UI now have an equivalent in the JupyterLab world. Unfortunately, the nbgrader extension was still outstanding as it had not yet been ported to the JupyterLab extension system. Resolving this has become critical as it was recently decided in a Jupyter Enhancement Proposal (JEP) that the next major version of the Notebook package (v7) will be based on JupyterLab components, and will rely on the JupyterLab extension mechanism. As part of this JEP, it was decided that the release of Notebook 7 should be contingent on porting certain popular classic notebook extensions to JupyterLab, including nbgrader.

Upgrading nbgrader is an important step for the advancement of the Jupyter project!

Nbgrader 0.8

The port of nbgrader to JupyterLab is a longstanding request of the community. A lot of work had already been done on this front by contributors to the ngshare project (Kevin Rong, Abigail Almanza, Lawrence Lee, and Eric Li) who developed a large part of the JupyterLab-based UI, but did not finalize the migration due to lack of time. Fortunately, they made their work available to the community for others to complete the upgrade. This includes the development of the remaining elements of the UI, the adaptation of the server-side extension, and adding tests on the JupyterLab extensions to improve the CI. The nbgrader 0.8 release also includes other significant work items such as the upgrade to nbconvert 6, the switch from the notebook server to jupyter-server, and the adoption of the jupyter releaser.

Today, we are pleased to announce the release of nbgrader 0.8.0, the first release of the extension to support the JupyterLab frontend.

Creating an assignment

Teachers can create assignments directly in the notebook UI by setting the proper information for each cell, such as the cell type (whether it is a locked cell, a manually graded answer, or an automatically graded answer) and the number of points the answer is worth.

The UI for creating an assignment in the notebook (teachers).

Managing assignments on the teacher side

Formgrader is the part of the nbgrader UI for the teachers to manage the assignments.

From this UI, teachers will be able to:

generate assignments from a Notebook file
share assignments with students
fetch assignments after student submission
grade assignments
provide feedback to students

The Formgrader UI to manage assignments (teachers).

Managing assignments on the student side

The assignments list UI is used by students to fetch assignments released by the teacher, submit their answers, and benefit from the feedback after the evaluation by teachers.

The assignments list UI to fetch and submit assignments (students).

What about the future?

Creating and grading assignments in nbgrader uses the metadata of individual notebook cells. The current release of nbgrader provides a widget to interact with the corresponding metadata.

As other extensions need a similar functionality, we are expanding the generic cell metadata editor to address this requirement in a more generic and pluggable way. The new metadata editor allows any extension to create a specific form to interact with the relevant part of the metadata, specified with a JSON schema and rendered with react-jsonschema-form.

Nbgrader could take advantage of this improvement in a future release.

Try it online

Installation

You can install the latest version of nbgrader using pip:

pip install nbgrader

The GitHub repository can be found here.

Acknowledgements

This work at QuantStack was partly funded by Université Paris Cité in the context of the PlasmaBio project.

We are grateful to Jessica Hamrick, Jeremy Tuloup, and Ian Stuart for their help and code reviews during the upgrade to nbgrader 0.8.0.

About the Author

Nicolas Brichet is a scientific software developer at QuantStack active in the Jupyter ecosystem. In the past few months, he has been working on the Nbgrader extension, as well as other developments in core JupyterLab such as an improved notebook metadata editor. Before joining QuantStack, Nicolas was a software engineer at INRAE.

Visual programming in JupyterLab with Blockly

2022-07-29T13:12:00+00:00

Block-based programming has become ubiquitous in school curricula for early computer science education. It is an excellent means to teach basic programming concepts without having to deal with the specific syntax of a text-based programming language.

When moving from block-based programming to a more classical language like Python, students often have to switch to a completely new environment. In order to provide a smooth ramp of complexity for learners, we designed a JupyterLab extension for Blockly so that Jupyter can be used from the very first steps of their learning journey. We also used Blockly’s code generation feature to create a more integrated experience with Jupyter.

But what exactly is Blockly?

The JupyterLab-Blockly extension, running a simple loop, and the corresponding Python code in a cell.

Blockly is an open source library designed by Google to make coding easier and more accessible through block-based visual programming. It uses interlocking graphical blocks to represent coding concepts, while giving the user full creative freedom, it removes all language specific syntax requirements.

Getting started: installing the Blockly extension

To install the extension, you just need to execute the following command:

mamba install -c conda-forge jupyterlab-blockly

Once installed, you can easily open a Blockly editor directly from the launcher, and start experimenting!

Features

The UI is made primarily of the toolbox located on the left side and the canvas where you can drag and drop the blocks you want to use in your code. When you are ready, just click the run button and see how the syntactically correct converted code appears on the bottom part of your screen in the programming language of your choice along with the output!

Short demo for the JupyterLab-Blockly extension

The extension is also prepared to adapt to all your needs. The workspace is ready to generate the blocks using your selected JupyterLab kernel and modify its colors based on your individual theme, whether it’s dark, light or personalized.

JupyterLab-Blockly integrates smoothly with the rest of the Jupyter stack: by using Jupyter kernels to execute the generated code, by reusing the JupyterLab code cell component to display the generated code, etc.

In doing so, JupyterLab-Blockly remains consistent with the rest of the UI (consistent syntax highlighting, theming, and life cycle of Jupyter kernels).

Robotics education

On top of JupyterLab-Blockly, we also built another extension dedicated to operating robots with the help of visual programming — more specifically, we created a toolbox which includes the blocks necessary to control the Niryo One robot. Using ROS can be a time consuming task, but the pre-built visual blocks make it easier to experiment and faster to produce a prototype for any project you have in mind.

To install this extension you need to execute the following commands:

mamba install -c conda-forge jupyterlab-niryo-one

Then, all you need to do is switch from the ‘default’ toolbox to the ‘niryo’ one, and you will immediately gain access to forty-two new blocks, so if you have access to one of these robots, give it a try!

Short demo for the JupyterLab-NiryoOne extension

Both extensions can be found on GitHub. The JupyterLab-Blockly extension is ready to be used as a base for other projects; you can register new blocks, toolboxes and generators. Taking the JupyterLab-Niryo-One extension as an example, feel free to experiment on your own!

Controlling the Niryo-one robot with the JupyterLab-blockly extension.

You can also try out the JupyterLab-Blockly extension now, directly from your browser, using JupyterLite! Just click on the link below.

About the authors

Denisa Checiu is a Robotics working student at QuantStack. She is also currently pursuing her bachelor’s degree, majoring in Robotics and Intelligent Systems and minoring in Computer Science.

Carlos Herrero is a scientific software developer at QuantStack passionate about AI and its applications to robotics. His current work focuses on the JupyterLab stack and expanding the Jupyter ecosystem by developing new extensions to integrate ROS in JupyterLab and also contributing to Voilà.

Jupyter Games

2021-12-14T19:38:00+00:00

Motivation

Making their own tiny video games can be a great way for kids to learn programming in a playful matter. While Jupyter is widely used as a scientific and educational tool, Jupyter is seldom used as a platform for game development. In this blog post, we show how Jupyter can be used to develop tiny games based on Box2D. While Jupyter is language agnostic and kernels exist for many programming languages, we will focus on the Python programming language in this blog post.

Mini-Games

When talking about video-games one might think of games such as:

Games as the ones above are usually developed with an engine like:

Not only do these games require complex engines to be developed, but also a whole team developing them and a lot of time and money.
Obviously, these are not the kind of games we can and want to develop in Jupyter. We want tiny games (~ 1000 lines of code) which can be implemented by kids in a matter of a few hours rather than many days, i.e. games like Pong, Pinball, and AngryBirds. In fact, we will focus on a certain class of games: 2D physics-based games, since these can be implemented very easily with the use of a 2D physics simulation engine like Box2D or Chipmunk2D.

Box2D

Box2D is a 2D rigid body simulation library for games. Box2D is best explained by the demo below.

A demo of Box2D compiled to JavaScript with Emscripten. Try it out (only HTTP, no HTTPS 😢 )

Box2D makes it very easy to implement physics-based games like Angry Birds or World of Goo.

Box2D Debug Draw

DebugDraw

Box2D has an abstract class DebugDraw with a handful of methods to draw simple primitives. The API is given by the following:

Box2D DebugDraw API

The ipycanvas based Box2D debug draw in action

Implementing this abstract class allows you to draw the physics for your UI back-end. Box2D is shipped with a glfw based DebugDraw implementation. For Python one can implement a pygame or kivy based DebugDraw implementation. For a finished product, one wants to replace the debug-draw-based renderings with custom shiny rendering routines. But using only debug-draw-based renderings is more than enough to quickly test game ideas and play around with Box2D.

LiquidFun

LiquidFun is a 2D rigid-body and fluid simulation library for games written in C++ based upon Box2D. LiquidFun is best explained by the demo below:

A demo of LiquidFun compiled to JavaScript with Emscripten which runs in the browser. Try it out!

More than just Games

Even though Box2D is advertised as a 2D physics engine for games, Box2D can also be used for educational purposes:
The YouTube channel iforce2d has done some impressive things with Box2D like a Box2D-based combustion engine and a wind tunnel.

Box2D based combustion engine by the youtuber iforce2d

Box2D based wind tunnel by the youtuber iforce2d

Box2D Python

Box2D has bindings for many languages and can be compiled to Wasm. Several Box2D demos exist:

http://www.iforce2d.net/embox2d/testbed.html (only HTTP, no HTTPS 😢 )
https://birchlabs.co.uk/liquidfun-wasm/
https://google.github.io/liquidfun/

We are particularly interested in using Box2D / LiquidFun from Python.
Here we have the following possibilities:

pybox2d

With pybox2d, Box2D has matured and robust Python bindings with extensive documentation. Unfortunately, pybox2d has a few shortcomings:

It only works with an old version of Box2D.
There is no support for LiquidFun.
pybox2d is mostly unmaintained.
The Python bindings are generated with SIWG (not really a shortcoming, but I personally strongly prefer pybind11).

pyb2d

A disclaimer first, I am the author of the pyb2d Box2D Python bindings. The motivation for creating pyb2d was having Box2D / LiquidFun bindings created with pybind11. While pyb2d works with the brand-new 2.4.1 release of Box2D, has support for LiquidFun and pybind11 has been used for generating the Python bindings, there are also some downsides:

pyb2d has fewer examples compared to pybox2d
pyb2d is not as mature and robust as pybox2d
pyb2d is not yet as well documented as pybox2d

A particularly useful feature of pyb2d is its BatchDebugDraw implementation: While we could implement the above mentioned debug draw API directly in Python, this would have a few drawbacks:

There is a certain overhead when calling C++ from Python and vice versa. When our game contains a lot of shapes, for instance circles, we would have to call drawCircle very often and have a lot of calls from C++ to Python and vice versa.
Some back-ends provide batch-drawing capabilities such that we can draw multiple primitives at once. For instance, drawing 100 circles at different locations with a single function call where the function arguments are NumPy nd-arrays with the centers/radii of the circles. Using such a batch API can lead to tremendous speedups.

The python batch debug draw API of pyb2d

To address these issues pyb2d provides a BatchDebugDraw implementation where we first collect all the individual calls like drawCircle, drawSegment, drawPolygon etc. We store the arguments of these calls in NumPy arrays. After collecting all the shapes we call the Python API with functions like draw_circles, draw_segments, draw_polygons, etc. where all the shapes are passed to Python in a single function call. On the Python side, one can pass these batched draw instructions to a batch-drawing API of the UI backed. (Spoiler: We will use the batch drawing API of ipycanvas for the Jupyter pyb2d integration.)

Jupyter Box2D Integration: Requirements

To have a platform to develop tiny games from within Jupyter we need at least the following:

A Canvas: We need a surface/canvas on which we can draw the content of the games.
Input Devices: Games would be boring without any user input. We need access to input devices like the mouse, the keyboard or even game-pads.

Ipycanvas, Ipywidgets, Ipyevents

Jupyter has a huge ecosystem of extensions. For the Jupyter Box2D integration, we just need to pick the appropriate Jupyter extensions: Ipycanvas gives us access to the HTML Canvas from within Python kernels in Jupyter. This serves as the drawable surface for our games. Ipywidets and Ipyevents give us access to input devices like game-pads, the keyboard, and the mouse.

Ipycanvas

Ipycanvas is a lightweight library developed by Martin Renou exposing the browser’s Canvas API to Jupyter. It allows drawing simple primitives directly from Python like text, lines, polygons, arcs, images, etc. With a few tricks, ipycanvas is fast enough to draw smooth animations. This even works when the server and the client are not on the same machines (when we run ipycanvas on MyBinder for example).

Conways game of life in ipycanvas, try it out!

An Ipycanvas-based DebugDraw:

The first step of integrating pyb2d in Jupyter notebooks is implementing an ipycanvas based DebugDraw. We recently released a new version of ipycanvas which provides an extended batch API to draw things very fast. We utilize this batch API when implementing the above mention batch-debug-draw API.

Handling events in Jupyter:

We can use Ipyevents for the event handling in Jupyter. Obviously, we want to handle the events while our game is running. To achieve this within a Jupyter-notebook we need to run our game-loop in a dedicated thread and listen for events in the main thread.

Adding Buttons:

We want to have a few buttons to start, pause and reset the Box2D based games. We can add these with ipywidgets.

Putting it all together

With all the above we can put together a pyb2d based Python Box2D integration in Jupyter. As a proof of concept we implemented a few mini-games:

Billiard:

A very simple billiard game. Try it on binder!

Angry Shapes:

An Angry Birds-like game implemented with pyb2d. Try it on binder!

World of Goo homage:

A World of Goo homage implemented with pyb2d. Try it on binder!

Rocket:

Fly a rocket controlled with the keyboard, but avoid the black hole! Try it on binder!

Compatibility

All the pyb2d examples shown above can also be run in a pygame window or a kivy window since pyb2d also provides back-ends for these. But even when one prefers to experiment with pygame, the Jupyter back-end can still be interesting since one can put the testbed-examples on MyBinder and have them accessible in a convenient fashion.

Caveats

The Jupyter integration of pyb2d gives usable frame rates, even when run through MyBinder. But nevertheless, a pygame based back-end usually leads to a better frame rate and smoother gameplay.

Outlook / Sneak preview

We currently work on:

Adding more examples and better documentation to pyb2d.
Improve the performance of the Jupyter integration.
Add pyb2d to JupyterLite.
Implement remote multiplayer-based gaming via the collaborative mode of JupyterLab.

Sneak-preview: Via the collaborative mode of JupyterLab we can connect to the notebook from two machines and play billiard against each other.

Acknowledgments

I would like to thank Martin Renou for his help with ipycanvas.

About the author

Thorsten Beier is a Scientific Software Engineer at QuantStack. Before joining QuantStack, he graduated in computer science at the University of Heidelberg and worked at the EMBL. As an open-source developer, Thorsten worked on a variety of projects, from nifty and vigra in C++ to inferno, kipoi, and ilastik in Python.

Juan Klopper

2020-08-03T16:01:00+00:00

Juan Klopper and Lorena Barba in Delft, Holland, for the Global Open Education Conference, April 2018.

Juan Klopper is a medical doctor and surgeon at Groote Schuur Hospital, the academic hospital complex of the University of Cape Town, South Africa, and a senior lecturer in surgery. His specialty is emergency surgery, and he heads the hospital’s Acute Care Surgery unit. He is also the Head of Post-Graduate Surgical Research, the Head of Surgical Education, and the Faculty of Health Science representative on the University Senate Committee for Online Education.

An ardent open educator, Juan was recognized with the 2014 Educator Award of the Open Education Consortium, a global network for open education. His first collections of educational videos on YouTube focused on biomathematics, and acute care surgery, but he also created loads of teaching videos on physics and mathematics. At the time, he recorded a course on medical statistics using Excel, but he also ventured into a short set of Python lectures, and then a full-fledged course on Medical Statistics using IPython notebooks. He has since then developed courses on the Julia language, on R for medical statistics, and on Understanding Clinical Research using Google Colab — the latter also a Coursera MOOC that has enrolled more than 85,000 learners. Juan was the first educator from the African Continent to have a course on the Coursera platform.

Juan’s research focus is on improvements of healthcare through data science and mathematics. The unique blend of his decade-long career as an attending surgeon and years as an autodidact of mathematics and programming brings forth inventive projects applying technology to medicine. One uses convolutional neural networks to diagnose hemopneumothorax (air and blood in the chest cavity) in victims with gunshot or stab wounds. Another is looking into the diagnostic accuracy of magnetic resonance imaging for tuberculosis spondylitis in HIV-positive and HIV-negative patients. The surgical research unit that he heads at University of Cape Town has supported more than a hundred master’s and doctoral research projects.

In the resource-constrained environment of South Africa, such research efforts rely heavily on open source software tools. For both teaching and research, open source tools remove barriers to technology in the developing world. A number of initiatives involving and advocating open source software in Sub-Saharan Africa attest to the significant impact it can have in capacity building, public policy implementation, and economic growth.

Juan — not content with saving lives applying his surgical talents — has devoted himself to the open dissemination of knowledge. His motto is “Never stop learning,” and he shares his learning journeys openhandedly with his students and everyone else. I can’t wait to hear what he will share with the JupyterCon community.

Just like our previously announced JupyterCon keynotes — Anima Anandkumar and Jeremy Howard — this is an exciting chance to imagine how far our community can go impacting the world for the better. Oh, the anticipation!

— Lorena A Barba, JupyterCon 2020 General Chair

Proposals for tutorials, talks and posters are being selected this week!

Plasma: A learning platform powered by Jupyter

2020-05-11T07:55:00+00:00

Jupyter has been a great choice for education for many years. The Jupyter Notebook has become one of the most popular tools to conduct workshops, tutorials, and teach online classes.

Recently we have seen the emergence and adoption of JupyterHub distributions to facilitate the deployment of Jupyter-based platforms, both on private servers and in the cloud.

We would like to share with you an open-source learning platform called Plasma, built with Jupyter at its core.

JupyterHub Distributions

JupyterHub is a highly customizable and modular framework. To simplify its adoption, JupyterHub distributions target specific deployment scenarios with opinionated defaults. They make it easier to deploy JupyterHub on a single server and in the cloud.

There are currently two popular JupyterHub distributions:

The Littlest JupyterHub (TLJH): for running JupyterHub on a single machine, targeting between 1 and 100 users
Zero To JupyterHub on Kubernetes (ZTJH): for running JupyterHub on top of Kubernetes, to scale to a large number of users and machines

Although not an official distribution, jupyterhub-deploy-docker is also a good resource for a full Docker-based setup. It runs JupyterHub itself in a Docker container and orchestrates the stack with Docker Compose.

The Plasma Stack

Plasma stands for PLateforme d’e-Learning pour l’Analyse de données Scientifiques MAssives, which can be translated to “An e-learning platform for massive scientific data analysis”.

The platform is typically meant to be deployed on high-end machines with multiple cores and GB of RAM.

Some of the requirements for the Plasma project fall somewhere between the TLJH and ZTJH distributions:

The deployment should be on a single server, and reproducible on other machines too (running on Ubuntu 18.04+)
It should support multiple user environments with different sets of dependencies
Users should authenticate as system users and their data should be persisted in their home directories on the host machine

Although TLJH doesn’t officially support container technology, its plugin system opens the door to many other use cases.

Because of this and to foster the TLJH plugin ecosystem, we decided to develop the Plasma stack as a plugin for TLJH and consolidate the deployment story with Ansible playbooks.

Plasma is an opinionated JupyterHub stack powered by The Littlest JupyterHub, with the following defaults:

PAMAuthenticator to authenticate JupyterHub as users existing on the host machine
SystemUserSpawner to start single-user servers in Docker containers, using the system user home directories for data persistence

To enable extra functionalities, the Plasma stack relies on:

The tljh-repo2docker plugin to create multiple user environments
The tljh-plasma plugin to define the JupyterHub config
Ansible playbooks to automate the deployment and configuration of the server and add additional tools

The Plasma stack also contains tools to monitor the system, create and configure users, and add hub admins. It can be visualized with the diagram below:

The Plasma Overview Diagram

The stack is defined in the following repository: https://github.com/plasmabio/plasma

There is also extensive documentation with detailed explanations on how to deploy the stack on a new server: https://docs.plasmabio.org

A repo2docker plugin for The Littlest JupyterHub

The tljh-repo2docker plugin lets JupyterHub admins create new user environments using repo2docker. This plugin starts a JupyterHub service to manage user environments from the JupyterHub UI.

For those already using Binder, the idea will sound very familiar. Under the hood, the tljh-repo2docker plugin also uses repo2docker to build the Docker images. It follows the same patterns and naming conventions as Binder, which makes it easier and more natural to test the environments on Binder before adding them to JupyterHub.

New environments can be added by clicking on the Add New button and providing a URL to the repository. Optional names, memory, and CPU limits can also be set for the environment:

Adding a new environment

The Environments page shows the list of built environments, as well as the ones currently being built:

Building a new environment

The status of the environment changes once the underlying Docker image has been built:

The list of available user environments

Once ready, the environments can be selected from the JupyterHub spawn page:

Selecting an environment

Because it is separate from the Plasma stack, this plugin can also be used for other temporary TLJH deployments on a virtual machine. For example, the organizer of a workshop can prepare a list of environments before the event, just like they would with Binder.

Automating deployments with Ansible

To minimize the number of manual steps involved in the setup of the stack, Plasma also provides a list of Ansible playbooks.

Ansible is an open-source tool to automate the provisioning of servers, configuration management, and application deployment.

Playbooks define a list of tasks that should be executed and declare the desired state of the server.

The list of playbooks and instructions on how to use them are provided in the Installation section of the documentation.

Overall, the playbooks make it easier to perform upgrades, to automate the deployment process, and to replicate the setup at other institutions and universities.

Here is an example of what an upgrade looks like:

Upgrading the stack with an Ansible playbook

This playbook defines the tasks to:

download the TLJH installer
execute the TLJH installer to perform the upgrade
update the TLJH plugins
set the idle culler timeout
set the default memory and CPU limits
reload JupyterHub
pulls the latest jupyter/repo2docker Docker image

Acknowledgements

The development of the Plasma stack at QuantStack was funded as part of the Plasma project, led by Claire Vandiedonck, Pierre Poulain, and Sandrine Caburet, associate professors at Université de Paris.

Sponsors to the Plasma initiative include:

Région Île-de-France, via the “Trophées franciliens de l’innovation numérique dans le supérieur” (EdTech 2018) grant program,
Université de Paris, via the Initiative of Excellence (IdEx) Label and its “inovating teaching” grant program,
EUR G.E.N.E., the graduate school on Genetics and Epigenetics,
the university training “Création, analyse et valorisation de données biologiques omiques” (DU Omiques).

National Scale Interactive Computing

2019-08-22T19:06:00+00:00

This is an invited post from Jim Colliander, Professor of Mathematics at UBC and Director of the Pacific Institute for the Mathematical Sciences.^[1]

In 2017, the Pacific Institute for the Mathematical Sciences (PIMS), in partnership with Compute Canada and Cybera, launched Syzygy, a cloud-hosted interactive computing platform that delivers JupyterHub deployments for universities across Canada.

Syzygy has been used by over 16,000 students at 20 universities. The main results of the Syzygy experiment so far are:

Demand for interactive computing is ubiquitous^[2] and growing strongly at universities.
The Jupyter ecosystem is an effective way to deliver interactive computing.
A scalable, sustainable, and cost-effective interactive computing service for universities is needed as soon as possible.

Demand for interactive computing

Both research and teaching at universities are adapting to major societal changes driven by explosions in data and computational tools. New educational programs that prepare students to think computationally are emerging, while research strategies are changing in ways that are more open, reproducible, collaborative, and interdisciplinary. These transformations are inextricably linked and are accelerating demand for interactive computing. The Syzygy experiment has shown that using Jupyter in educational programs drives interest in using Jupyter for research (and vice versa). For example, students in mathematics, statistics, and computer science collaborated with a researcher from St. Paul’s Hospital in Vancouver using Syzygy to identify new pathways to prevent death from sepsis. Research communities typically need access to deeper computational resources and often span multiple universities, but the common thread is the need to expand access to interactive computing.

A map of JupyterHub deployments deployed by Syzygy.

Technical milestone achieved

The Syzygy project has demonstrated that it’s possible to deploy tools for interactive computation at a national scale rapidly and efficiently using an entirely open source technology stack. Students, faculty and staff across Canada use Syzygy to access Jupyter through their browsers with their university single-sign-on credentials. The JupyterHubs range from a “standard” configuration to bespoke environments with specially curated tools and data integrations. This richness is possible because of the architecture of the Syzygy and Jupyter projects and the flexibility of the underlying cloud resources. As a case-study, Syzygy demonstrates that the Jupyter community has achieved a significant technical milestone: interactive computing can be delivered at national scale using cloud technologies.

Service level requirements

The validation that interactive computing can be technically delivered at national scale prompts universities to ask a variety of questions. Can interactive computing service be delivered robustly? How will users be supported? What are the uptime expectations? What is the data security policy? How is privacy protected? Can the robustness of the service be clarified in a service level agreement? Syzygy, as an experimental service offered to universities at no charge and without a service level agreement, does not properly address these questions. To advance on their education-research-service mission and address growing demand, universities need a reliable interactive computing service with a service level agreement.

What’s next?

How should universities address their needs for interactive computing over the next five years? Right now, universities are following two primary approaches:

🙏 Ad hoc: faculty figure out how to meet their own needs for interactive computing; IT staff deploys JupyterHub on local or commercial cloud servers; this approach gives universities control over their deployments and hardware, though requires time and expertise that many may not have.
🎩 Use a cloud provider’s service: Google Colab, Amazon Sagemaker, Microsoft Azure Notebooks, IBM Watson Studio; this approach allows universities to quickly launch interactive computing services, with a loss of flexibility and some risks by becoming reliant upon a particular vendor’s closed-source and proprietary software.

These approaches are not sustainable over the long term. If universities all deploy their own JupyterHub services, many will need technical expertise they do not currently have and will involve a significant duplication of effort. If universities rely on hosted cloud notebook services, the reliance on proprietary technology will impair their ability to switch between different cloud vendors, change hardware, customize software, etc. Vendor lock-in will limit the ability of universities to respond to changes in price for the service. Universities will lose agility in responding to changes in faculty, staff, and student computing needs.

There is a third option that addresses the issues with these two approaches and generates other benefits for universities:

🤔 Form an interactive computing consortium: universities collaborate to build an interactive computing service provider aligned with their missions to better serve their students, facilitate research, and avoid risks associated with vendor lock-in.

To retain control over their interactive computing stacks, avoid dependence^[3] on cloud providers, and accelerate the emergence of new programs, universities should work together to deploy interactive computing environments in a vendor-agnostic manner. This might take the form of a consortium — an organization dedicated to serving the needs of universities through customized shared infrastructure for interactive computing. The consortium would also ensure that universities will continue to play a leadership role in the development of the interactive computing tools used for education and research.

The Syzygy experiment confirmed that growing demand for interactive computation within universities can be supplied with the available technologies advanced by the Jupyter open source community. In the coming year, we aim to build upon the success of the Syzygy experiment and seed an initial node of a consortium in Canada with the intention of fostering a global network of people invested in advanced interactive computing. If you are interesting in partnering, please get in touch! See this Jupyter Community Forum post to continue the discussion.

The author gratefully acknowledges feedback on this piece from Ian Allison, Lindsey Heagy, Chris Holdgraf, Fernando Perez, and Lindsay Sill. ↩︎
Interactive computing needs have been identified in agriculture, applied mathematics, astronomy, chemistry, climate science, computer science, data science, digital humanities, ecology, economics, engineering, genomics, geoscience, health sciences, K-12 education, neuroscience, political science, physics, pure mathematics, statistics, and sociology. ↩︎
Relying on commercial cloud vendors to provide the interactive computing service for universities risks recreating the problems associated with scientific publishing that emerged with the internet. ↩︎

University of Edinburgh Jupyter Community nbgrader Hackathon

2019-05-22T16:59:00+00:00

The University of Edinburgh is happy to announce our upcoming event as part of the Jupyter Community Workshop series funded by Bloomberg. The University will be hosting a three-day event, the core aspect of this event being a hackathon focused on adding improvements, fixes and extra documentation for the nbgrader extension. Alongside this we will also hold an afternoon of talks highlighting how Jupyter can be used in education at varying levels. The event will take place on 29 to 31 May at the University of Edinburgh, with the afternoon of talks taking place on 30 May.

The first and main part of the event will be the nb grader hackathon. nbgrader is a Jupyter extension that allows for the creation and marking of notebook-based assignments. Here at the University, we have adopted nbgrader and our developers have integrated the extension into our Jupyter service Noteable. The hackathon will focus on improving the core features and extending the abilities of nbgrader; by adding such features, it will be easier for institutions to adopt and embed both Jupyter and nbgrader into their teaching practice.

The second, equally important part of our event is a series of talks aimed at highlighting the uses of Jupyter within education. As part of developing our local Jupyter service, we have uncovered many use cases across the University of how Jupyter can be adopted in a variety of disciplines and scenarios that we are keen to share. We will also be able to showcase an institutional approach to adopting and supporting Jupyter at scale. On top of this, there is also the opportunity to hear from many of our hackathon attendees. This series of talks is aimed at academic colleagues, and teaching and support staff at any level of education and includes an evening networking event to allow attendees to further explore how they may introduce Jupyter to their institution.

What are we working on?

We have worked with our local developers and scoured the nbgrader Github repo to devise a plan of attack for the hackathon in terms of features and improvement. We’re keen to engage with the wider community regarding these goals and have created a post on the Jupyter Discourse to allow further discussion.

Support for Multiple course/Multiple classes. Instructors that teach multiple course using nbgrader or students enrolled on multiple course. Multiple Courses (ref: PR #1040) vs Support for multiple classes via Jupyterhub groups (PR #893)
Considerations for LTI use: Users/Courses not in the database at startup
Support for Multiple markers for one assignment (part of issue #1030, which extends #998)
API Tests have hard-coded file copy methods to pre-load the system to enable testing, and os.file_exists-type tests for release & submit tests
Generation of feedback copies for students within the formgrader UI (to mirror the existing terminal command). Also consider ability to disseminate this feedback back to students within nbgrader.

Want to get involved?

If you would like to be involved in the hackathon, we still have an amount of funding left for travel and accommodation. We are looking for participants who have a good understanding of Jupyter and nbgrader who would be able to attend all three days of the event. If you would be able to attend, please complete the following form: [https://edin.ac/2vP8bFS].

If you can’t attend but want to have a say on what is worked on during the hackathon then join the discussion on the Jupyter Discourse (if you’re new to Jupyter this is an excellent place to head to for community discussions)

If you’d like to come along to our Jupyter community afternoon on 30 May, book a place via Eventbrite.

Teaching and Learning with Jupyter

2019-01-07T12:57:00+00:00

The book-sprint participants on day 1, developing the content ideas for our open book. Credit: Richard West.

From the early days — even before the Jupyter name — many of us foresaw that the IPython Notebook and the ecosystem of tools growing around it would be a “killer app” for education. But how could we imagine that Jupyter would be at the epicenter of the data science shake-up of tech jobs, reskilling, and educational innovation?

#scipy2014 keynote @LorenaABarba says “IPython Notebooks are the Killer App for teaching (science and engineering).”

— katy huff (@katyhuff), July 8, 2014

Today, Jupyter is the technology behind the most innovative educational programs in data science, and is platform-of-choice for tutorials, workshops, online lessons, and even books. So I decided it’s a good time to collect the knowledge and experience of early adopters of Jupyter for teaching, combine it with reflections of scholars of education, and write an open book: a Handbook for Teaching and Learning with Jupyter.

On Nov. 28–29, 2018, I welcomed fifteen researchers, educators and STEM faculty at the George Washington University, in Washington, D.C., for a book sprint — in two and a half days, we collaboratively wrote the first draft of this handbook, and immediately published it online at jupyter4edu.github.io. The open book continues to be edited and added to via an open-development model on GitHub, with dozens of pull requests merged in its first month.

Ready to start writing today, post-it notes everywhere #Jupyter4Edu

— Lorena Barba @labarba@fosstodon.org (@LorenaABarba), November 29, 2018

The book covers the following topics:

Why we use Jupyter notebooks for teaching, the learning benefits and some anecdotes from our own experiences
What we do with Jupyter, with lots of examples and tips for incorporating notebooks into a lesson or course
A catalogue of pedagogical patterns with notebooks, drawn from our own experience and examples from others
The Jupyter Notebook ecosystem, focusing on the tools that are most useful for teaching and learning
Getting your class going with Jupyter: all you need to know about options for installing software, infrastructure options, distributing and collecting materials, assessing student work, and more
Usage case studies, including large-scale adoption, single courses, and notable teaching materials published as notebooks

Book link: jupyter4edu.github.io

Jupyter continues to grow in popularity for teaching data science and computation not only in STEM fields, but also data journalism, business and quantitative economics, data-based decision sciences and policy, quantitative health sciences, and digital humanities.

For educators newly adopting Jupyter, navigating the ecosystem of tools and content can be overwhelming. They could study many examples, and consume myriad blog posts and talk videos to distill the patterns of good practices and technical solutions to best serve their students. Our open book aims to be the entry point for educators who want to use Jupyter to empower their teaching. We hope it will grow to encompass all you need to know about Jupyter in teaching and learning.

The book sprint was supported by a grant from Bloomberg to Project Jupyter for holding Jupyter Community Workshops last year, which provided funding for the participants’ travel and event catering. The grant was managed by NumFOCUS (fiscal sponsor for Project Jupyter). Meeting space was provided free of charge by the George Washington University, and the group was fêted at a reception sponsored by Leidos.

Tweet with #jupyter4edu to let us know what you think!

Book-sprint participants, with their bios, at: https://osf.io/uqz4j/wiki/Participants/

Book link: jupyter4edu.github.io

Synopsis: JupyterCon 2018 Education Track

2018-08-22T01:02:00+00:00

Barba keynoting at JupyterCon 2017. Credit: O’Reilly Media.

I’m on the train to NY, giddy in anticipation of the Jupyter community celebrating together for the second year. It was a privilege for me to be invited to keynote last year, at the inaugural JupyterCon. This year, I am part of the Program Committee, co-chairing the education track with Robert Talbert. Let me tell you about the impressive and inspiring conference line-up for Jupyter in education!

The main conference lists 11 talks on the education track, listed below. In addition to these, we have a panel (2:40–3:20pm Thursday), and an unconference-style session on Thursday at 5 PM.

The panel is titled “The Future of Jupyter in Education,” and features the following panelists:

Carol Willing, @WillingCarol
Natalia Clementi, @ncclementi
James Colliander, @colliand
Allen Downey, @allendowney
Jason Moore, @moorepants
Danny Caballero, @physicistdanny

Each panelist will make a 2–3 min statement to get people thinking, and then it’s Q&A with the audience. We’ve asked the panelists to jot down some ideas to share with us, based on the following questions:

What do you see in the future of Jupyter if it is to fulfill its potential for teaching and learning?

What do you want from Jupyter as its adoption in education grows?

If you are interested in the future of Jupyter in education, please come join the conversation at the panel — it will be energizing!

One thing we don’t want for the discussion in this panel is to drift towards the DevOps challenges of adopting the tools (like JupyterHub and nbgrader). The Project Jupyter team is very aware that DevOps is a pain point for the educational uses of Jupyter. And they are working on it!

Let’s put our minds together to build a vision for the ecosystem, imagine how institutions might collaborate (e.g., federated solution in Canada), what could be the role of the private sector (i.e., paid options, freemium models), or the nonprofit sector (e.g., NumFOCUS) — but refrain from going into the weeds of concrete technical details (on this occasion).

We want to steer the conversation towards the learning concerns more than the edtech concerns. For example, now that many educators are using Jupyter, can we look into what works, and are we using research-based pedagogical strategies? What are these (e.g., chunking, scaffolding), and can we distill some “best practices”?

For the unconference-style session, the slate is clean. We’ll bring sharpies and big post-it notes, and be ready to live tweet!

Thursday: 5 sessions

11:05am–11:45am
Flipped learning with Jupyter: Experiences, best practices, and supporting research, Beekman/Sutton North | Lorena Barba (George Washington University), Robert Talbert (Grand Valley State University)

11:55am–12:35pm
JupyterHub for domain-focused integrated learning modules, Beekman/Sutton North | Mariah Rogers (UC Berkeley Division of Data Sciences), Ronald Walker (UC Berkeley Division of Data Sciences), Julian Kudszus (Yelp)

1:50pm–2:30pm
Jupyter for every high schooler, Beekman/Sutton North | Rob Newton (Trinity School)

2:40pm–3:20pm
Real-time collaboration with Jupyter notebooks using CoCalc, Murray Hill | William Stein (SageMath, Inc. | University of Washington)

4:10pm–4:50pm
Learn by doing: Using data-driven stories and visualizations in the (high school and college) classroom, Beekman/Sutton North | Carol Willing (Cal Poly San Luis Obispo), Jessica Forde (Jupyter), Erik Sundell (IT-Gymnasiet Uppsala)

Friday: 6 sessions

11:05am–11:45am
Data science in US and Canadian higher education, Beekman/Sutton North | Laura Noren (NYU Center for Data Science)

11:55am–12:35pm
I don’t like notebooks, Nassau | Joel Grus (Allen Institute for Artificial Intelligence)

11:55am–12:35pm
The Jupyter Notebook as a transparent way to document machine learning model development: A case study from a US defense agency, Concourse A: Business Summit | Catherine Ordun (Booz Allen Hamilton)

1:50pm–2:30pm
Jupyter graduates, Beekman/Sutton North | Douglas Blank (Bryn Mawr College), Nicole Petrozzo (Bryn Mawr College)

2:40pm–3:20pm
Reproducible education: What teaching can learn from open science practices, Beekman/Sutton North | Elizabeth Wickes (School of Information Sciences, University of Illinois at Urbana-Champaign)

5:00pm–5:40pm
Current RISE candies and its evolution into the future, Beekman/Sutton North | Damián Avila (Anaconda, Inc.)

If I missed an education-track session in my synopsis, let me know and I’ll add it!