#44 Project Jupyter and Interactive Computing (with Brian Granger)

In this episode of Data Framed, a Data Camp podcast, I'll be speaking with Brian Granger, co founder and co lead of Project Jupyter, physicist and co creator of the Altair package for statistical visualization in Python. We'll speak about data science, interactive computing, open source software and Project Jupyter. With over 2.5 million public Jupyter Notebooks on GitHub alone, Project Jupiter is a force to be reckoned with. What is interactive computing and why is it important for data science work? What are all the moving parts of the Jupyter ecosystem from notebooks to Jupyter Lab to JupyterHub and Binder? And why are they so relevant as more and more institutions adopt open source software for interactive computing and data science? From Netflix running around 100,000 Jupyter Notebook batch jobs a day, to Ligo's Nobel Prize winning discovery of gravitational waves and publishing all their results reproducibly using notebooks and Project Jupiter is everywhere. I'm Hugo Bown Andersen, a Data Scientist at DataCamp and this is Dataframed. Welcome to Data Framed, a weekly datacamp podcast exploring what data science looks like on the ground for working data scientists and what problems it can solve. I'm your host, Hugo Baun Anderson. You can follow me on Twitter Hugo Bowne and Data Camp At Data Camp, you can find all our episodes and show notes@data camp.com community podcast before we get started, I just wanted to let you all know that we have something new for our podcast listeners this week. A trial of Data Camp for Business. Now, what is Data Camp for Business? It's basically all the content you get as an individual subscriber, plus tons of amazing tools for you and your colleagues to learn data science skills together. All you need to do is email salesatacamp.com with the subject podcast and you can redeem A free two week trial of datacamp for you and up to 25 of your colleagues. That's salesatacamp.com with the subject podcast and you can Redeem A free two week trial of datacamp for you and up to 25 of your colleagues. We look forward to hearing from you. Hi there Brian, and welcome to Data Framed.

Hi.

Hi Hugo. Thanks so much for having me on today.

It's such a pleasure to have you on the show and we're here today to talk about Project Jupiter, about interactive computing. And in fact, you sent me a great slide deck today of yours that you've been giving recently. And something we're going to be focusing in on is actually a slide that you have there. And I'm just going to quote this before we get started. You wrote, we are entering an era where large complex organizations need to scale interactive computing with data to their entire organization in a a manner that is collaborative, secure and human centered. Now these are all touch points we're going to be speaking about during this conversation. But before we get into all of this and before we get into a conversation about Jupyter, Jupyter Notebooks, Jupyter Lab and all of these things, I'd like to know a bit about you. So first maybe you could tell me a bit about what you're known for in the data community.

Yeah, not a problem. So I'm a physics professor at Cal Poly. For the last close to 15 years I've been involved in a number of open source projects in the scientific computing and data science space. In the early years I was involved in Sympy, which is a symbolic computer algebra library for Python and then also IPython, de facto interactive shell for Python. And then in the more recent years was one of the co founders of Project Jupyter. And in the last few years I've also co founded Altair with Jake Vanderplaas, which is a statistical visualization library. So the big theme though is open source tools for humans working with code and data.

And speaking of Altair, you're actually currently working on an Altair course for Data Camp, right?

Yes. You're being a little bit optimistic about your verb tense there. It's been a little bit stalled with all the different activities we have going on in the Jupyter world. But yeah, I think I'm around maybe 2/3 to 3/4 done with the Data Camp course for Altair.

And so as a project lead for Project Jupiter, I'm wondering what type of skills come into play there because I know you have very strong background. You're a physicist, you have a lot of data analytics skills, a lot of design and engineering and entrepreneurial skills presumably come into this role as well. So I'm just wondering what type of things you need in order to do this job.

Yeah, it certainly has evolved over the years. In the sort of early days of Ipython and Jupyter, we were spending most of our time doing software engineering. There was a very small amount of design work, ui, UX design work. And when it's only a handful of people, in principle there's organizational work and community work to be done, but it's at a very small scale that is in the background relative to the software Engineering. As Jupyter has grown though, the, I would say the demand for more time and effort on the organizational and community side as well as the design aspects of the project have really increased. One of the challenges in working on open source is that projects like Jupyter or Altair tend to attract really top notch developers and software engineers. And so that aspect of the projects tends to be reasonably well staffed. That doesn't mean that we all have as much time to put into the projects on the software engineering side as we would like. However, as these projects get big, there's nothing in particular that attracts top notch UI UX designers, for example, to Jupyter. That continues to be a challenge for us and other open source projects in terms of how do we build design into the process and figure out how do we engage designers in the development of the projects.

So in terms of, I mean you're speaking about a number of things here that include, you know, design but also hiring, structuring an organization. I know that you think a lot about getting funding for the project. You're talking about community development, which, you know, these are all things we think about at Data Camp a lot as well. So it sounds somewhat similar in several ways to running a company.

It probably is. I've never run a company, but when I talk to other people who are in different roles leading companies, there's a lot of overlap there. And our business model doesn't involve selling things to people in the traditional sense. But most certainly we have customers and our interaction with those customers is very similar to that of a company who has paying customers. In terms of we exist in a very dynamic, fast paced part of the economy and it's the type of thing that if Jupiter were to sort of relax and begin to coast to, there's hundreds of other open source projects and for profit companies building products quickly put Jupyter in a position of becoming outdated. And so there's a lot of thinking we do and work that we do around looking ahead at our three to five year roadmap and where we see data science, machine learning and interactive computing going and figuring out how do we build the resources to tackle those ambitious things on those time frames, but also build a sustainable community along the way.

So how did you get interested in or involved in data science as opposed to being a physics professor and researcher? How did you get into data science initially?

Yeah, that's a great question. So we began working on interactive computing as part of IPython. I was a classmate of Fernando Perez back in grad school at The University of Colorado and Fernado created Ipython in the early 2000s. And at the time, the world of interactive computing was really something that was done in the scientific realm, in academic research, in education. I'm sure there were some companies at the time that were doing little bits of it here or there, but it wasn't something that was pervasive like it is today. And so as we started to build Ipython and Jupyter in the 2000s, initially we felt like we had what we imagined was a very grand vision that everyone in the world of academic research and scientific computing would be using Python and the tools that we and many other people were building. What we didn't see is that the whole world was about to discover data. And that really sort of opened up a whole new audience and set of users to open source data science tools and scientific computing tools that we never imagined. And so honestly, the way my own journey is more that we were doing what we had always done in terms of scientific computing, and then woke up to realize that we were sort of right in the middle of the data science community that was forming both in the academic research side, but also on the commercial industry side as well.

I want to delve into a bit more about the general nature of Project Jupiter in a minute, but before that I'd like to speak a bit more about interactive computing. So I'm going to quote Project Jupiter. Project Jupiter states that it exists to develop open source software, open standards and services for interactive computing across dozens of programming languages. And I'm wondering what a general working definition of interactive computing is and why. Why is it important?

Yeah, this is a great question. I think in the history of computer science, interactive computing has not even really been a thing that's acknowledged in terms of a topic worthy of study and something that is worth really thinking about carefully and clarifying. It's something that we've been doing over the years and really the Jupyter architecture is an expression of our thinking about interactive computing. I would say that the core idea of interactive computing is that there's a computer program that's running where there's a human in a loop. As the program runs, that human is both writing and running code on the fly, but then looking at the output or the result of running that code and making decisions about what code to write and run. Subsequently, there's this interactive mode of going back and forth between the human authorship of the code and then the computer running it, and the human then interacting with the result in an iterative manner.

And this is ideal for so many aspects of the scientific research process, right from exploratory data analysis to writing code embedded with inline results and images and text and that type of stuff.

Absolutely. And this is something that we really think a lot about, and that is that when humans are working with code and data, eventually at some point, for their work to be meaningful and impactful, the code and data need to be embedded into what we think of as a narrative or a story around the code and data that enables humans to interact with it, make decisions based on it, understand it. And it's really that human application towards decision making. It really makes a difference to have a human in the loop when you're working with data.

And for our listeners out there who may not know what IPython is and how it differs from Python, would you mind spelling that out for them?

Yeah. So Python is the programming language. Ipython stands for Interactive Python. And it originally was a terminal based interactive shell for working with Python interactively. It had a lot of, and continues to have a lot of nice features that you want when you're working interactively, such as nice tab completion, easy integration with the system shell, inline help features like rich interactive shell. And the interaction between IPython and Jupyter today is that originally when we built the notebook, we called it the IPython Notebook because it only worked with Python. And then over the years we realized that the same user interface and architecture would also work with other programming languages. The core developers of IPython then sort of spawned another project, namely Project Jupyter. That's the home for the language, independent aspects of the architecture. And IPython continues to exist today as the main way that people are using Python within Project Jupyter. And so it continues to be a project that we're still working on.

So could you give us a high level overview of what Project Jupiter is and what it entails?

Yeah. So you read the sort of a good summary of Project Jupiter and that it's focused around open source software, open standards and services for interactive computing and the. I think a lot of people are familiar with some of the software projects that we have created, namely the Jupyter notebook. And I'm sure we'll get to talk more about that here in this conversation. But underneath the Jupyter notebook is a set of open standards for interactive computing. And I think when we think about Jupiter and its impact, it's really those open standards that are at the core of that. And one way to think about it is it's A similar situation as to the modern Internet, where yes, there's individual web browsers and websites, but underneath all of that there's a set of open standards, namely HTTP, tcpip, HTML, that enable all of those things to work together. The open standards that Jupyter has built for interactive computing serve a similar role as those other protocols do in the context of the broader Internet.

So I want to find out a bit about the scale and reach of Project Jupyter, but I want to preface this by saying it's a story both you and I know, but for our listeners. Recently I attended a talk you gave at JupiterCon here in New York City, and before you started speaking, you asked people to put up their hand if 10 or less people in their organization used some aspect of Project Jupiter, then asked people to put their hand up if 50 or less, 100 or less, 500 or less, a thousand or less, and so on, and people put their hands up at every point. And then you asked anybody in an organization which has over 10,000 people using some aspect of Project Jupyter, and a number of people put their hands up. And that was a really large aha moment for me thinking about the scale and reach of the project as a whole. So with that as a kind of intro, I'm wondering what you can tell us about the scale and reach of the project.

Yeah, so this is something that's been really fun to be a part of over the last few years, to see the usage of Jupyter literally explode and take off in ways that we never imagined. And there's a number of different ways of thinking about this being an open source project. We don't have an accurate, precise way of tracking how many users we have. Our users obtain and install Jupyter through a number of different means and that does make it a challenge. One nice thing that we're watching is the number of notebooks on GitHub. And this can be obtained by querying the GitHub APIs. We have a project, an open source project, where we're tracking that over time. And as of this summer, the total number of public notebooks is on the order of two and a half million. And from talking with the GitHub folks that we know, it looks like there's roughly another similar amount of private Jupyter notebooks that are not visible to the world. And so the interesting thing there, obviously the absolute number currently is interesting. I think what's more telling is that over time we're seeing an exponential increase in the number of notebooks and the doubling period right now is around nine or 10 months. And so that really points to very strong current numbers as well as growth. And, you know, it's difficult to put a number on the total number of people that are using Jupiter worldwide. Some of what makes it challenging is that most of our staff is in the US and Europe. And yet we know from our Google Analytics traffic that Asia right now is one of the most popular continents that's using Jupiter. And so we don't have many contacts with people there. We don't know how Jupiter is being used, but we see a very strong signal that it's being used heavily.

And how about in terms of contributions and amount of developers working on the project?

Yeah, so along with the usage, there's definitely been an increase in the number of contributors. I think that the total number of contributors is somewhere over 500. And it's a fairly large scale open source project. We have over 100 different repositories on GitHub, spread across a number of different orgs. And the core team right now that are core maintainers of the project, many of whom work mostly full time on the project, is there's around 25 people. The Jupiter Steering Council is a key part of the leadership of the project. And I think there's currently 15 steering council members. There's a number of new people who joined the Steering Council this summer. So I don't remember the precise number. And one thing that I want to emphasize with this is that sort of what is the right narrative to have about the different contributions of people to Project Jupiter? And I want to sort of make an analogy to Hollywood in terms of if Jupiter were a movie, what type of movie would it be? And I think it's important to note that it would not be a movie where there's a single superhero who comes and saves the day. So sort of like a Superman narrative really doesn't fit the reality of how Jupiter has been built. A movie, I think that would be a better analogy to how Jupiter is built, would be something like Infinity wars, where you have a bunch of different superheroes, all with very diverse skills and strengths contributing to the overall project. And I think it's really important to note that in that, yes, I'm the one that's here talking to you today, but I am one among many people who've done absolutely amazing work on this project.

And for our listeners out there who would like to get involved in perhaps contributing to the project, what are good ways to get involved and what are, I hesitate to say Bad ways to get involved, but what are less good ways to get involved?

Yeah, so this is one thing that I Talked about at JupiterCon in terms of. And in that context it was more thinking about what are healthy and productive ways for large companies to engage with open source. So for individuals, I would say one of the best ways would be to find a part of the project that you're interested in and then come on GitHub and begin to interact with us. A lot of our popular GitHub repos have issues that are tagged for first time contributors and so we're working hard to try to make the project a welcoming place for new contributors. And so we welcome people to come and talk to us there. We also have chat rooms that are public on Gitter im. So this is a online web based chat platform that is integrated with GitHub. And so for example, the Jupyter Notebook, Jupyter Lab, Jupyter Hub, Jupyter Widgets all have chat rooms on gitter. And both the core contributors as well as the broader community hangs out in those contexts. So that's a great way for people to get involved.

And how about organizations that want to contribute to the project? Brian?

I think in this case it's really helpful to have a good mental model of how open source projects work and how contributions function. And my favorite mental model is actually from Brett Cannon, who's one of the core Python devs and works at Microsoft. In a tweet he said something like submitting a pull request to an open source project is like giving someone a puppy. And that is you have to understand that the person accepting the pull request is essentially agreeing to care for that puppy for the rest of its life. And one of the patterns that we see in organizations, companies that want to contribute to open source, is that they're interested in particular features and so they have their employees contribute to open source in a way that generates a lot of large new pull requests for those new features. And I think this is where the puppy mental model really helps. And that is oftentimes the core maintainers of open source projects are completely overwhelmed with just the maintenance of the project. And that could include bug fixes, releasing issue triage and managing issues, but also reviewing other contributors pull requests. And so one of the most helpful things that we're trying to cultivate is basically a balanced perspective of contributions that includes not just submitting pull requests that have new features, but also includes reviewing other people's pull requests, involves helping other users with particular issues and even fixing bugs. And one really nice thing that GitHub has done recently is in their contributor user interface, they have a new user interface for sort of expressing someone's contributions to a particular GitHub repository. And there's sort of a XY coordinate system and four directions around that. And it shows someone's contributions to. I think it's code review, pull requests issues. And there's one other from that you can get a perspective on how balanced someone's contributions are to an open source project. And so a simple way of putting it is encouraging people to have a balanced way of contributing to open source. Now we also want to specifically address first time or new contributors. And there I think the idea again is balance, but in a way where the core contributors and existing people working on the project can help new contributors to come along and begin to contribute in different ways. And so even for new contributors, those contributions don't necessarily have to be pull requests. Even checking out existing pull requests and just testing them locally is really, really helpful for open source projects. And so that balanced perspective is something that we're trying to.

And it's incredible that, you know, GitHub now has the feature you discussed which kind of facilitates just figuring out this balance, right?

Oh, absolutely. I was thrilled to see them release that and I think it's happened in the last month.

We'll jump right back into our interview with Brian Granger after a short segment.

Foreign.

It's well known that humans can't multitask, but apparently machines can. I'm here today with Frederica Schur, research engineer at Cloudera Fast Forward Labs, and we're going to talk about machines that multitask or multitask learning. Frederica, what is multitask learning?

Hi Hugo, it's nice to be back on the Data Frame podcast. Thanks for having me. We humans may not excel at doing too many things at once, the definition of multitasking, but we do benefit from learning or having learned many related tasks. That's multitask learning. For example, several years ago I moved from Germany to the Netherlands as a native German speaker. It was relatively easy for me to pick up Dutch as Germanic languages. German and Dutch share semantic and syntactic properties that a German speaking Dutch language learner like me can benefit from. I was multitask learning. Learning Dutch was easier for me because I had learned German before.

And how about machines?

Well, machines struggle to learn multiple tasks. Today's supervised machine learning algorithms, algorithms that learn from labeled data tend to learn one and only one task. They achieve mastery through laser like focus. Since they only learn one task. They cannot benefit from the relations between tasks. Multitask learning allows machines to learn multiple tasks at once so that they can benefit from the relationships between tasks.

Great. Would you mind giving us an example?

Of course. Let's get into the nitty gritty within natural language processing, or nlp. Part of speech tagging, syntactic parsing, and textual entailment are all tasks that assign labels to parts of sentences. Part of speech tagging assigns labels such as noun, verb, adjectives, etc. Syntactic parsing identifies the syntactic relations between the parts of a sentence. Textual entailment identifies whether one sentence is the consequence of another or contradicts another, or whether there is no such sentence relationship. Part of speech tags improves syntactic parsing. Part of speech tags and the parse tree improve textual attainment. Now, multitask learning enables us to train one model to master all three tasks so that textual attainment, for example, can benefit from the part of speech tags. Importantly, a model trained to master all three tasks is likely to outperform models trained to master one and only one task. That is one of the benefits of multitask learning. It allows machines to benefit from related tasks for better performance. It's no surprise that the natural language processing library, Spacy, I'm a huge fan. Uses multitask learning for some of their models.

That sounds great. So when would you use multitask learning?

Multitask learning is an approach to training supervised machine learning algorithms. It is not an algorithm. So in principle, there is a multitask version of every supervised algorithm. You could use multitask learning all the time, but you really want to use multitask learning if you're looking to solve complex problems. Single task learning does a fine job when you're looking to solve simpler problems, which is why it's been so popular until now. Complex problems benefit from the power of the multitask learning approach. They benefit from learning the relations between tasks.

And can you give us some examples?

Absolutely. Image segmentation algorithms, for example, identify object boundaries in images, the boundaries of tissue types in medical images, or building types in satellite images. Image segmentation is hard. Results are plagued by blurry edges because algorithms struggle to really delineate objects. They assign different labels to pixels at object boundaries. Image segmentation benefits from joint training with boundary detection or shape identification. Most buildings are composed of rectangles. Their edges are straight lines. Using multitask learning, we can exploit these regularities to sharply delineate object boundaries during image segmentation.

So what about Natural language processing.

Yeah, that's a pretty sensible choice too. A couple months ago, Salesforce released one model that it mastered many NLP tasks, from sentiment analysis, semantic role labeling, machine translation, summarization, to common sense reasoning and question answering. Multitask learning is only effective, of course, if the model is asked to learn tasks that are actually related. In this case, it's clear intuitively how common sense reasoning and question answering support each other. Common sense reasoning may help us get the answer we need.

Thanks Frederica, for this enlightening introduction to multitask learning. After that interlude, it's time to jump back into our chat with Brian as we've been discussing that the scale and reach of Project Jupyter is massive. So I'm sure there are so many different uses of notebooks in the project in general, but I'm wondering to your mind what the main uses of Jupyter notebooks for data science and related work are.

Yeah, in terms of numbers of people using Jupyter for a particular purpose, I would say interactive computing with data. And so data science, machine learning, AI is one of the most popular ways that Jupyter is being used, both by practitioners, so people who are working in industry on data science and machine learning teams, but also in educational contexts. So within universities with online programs, with boot camps, you have instructors and students doing those activities around data science and machine learning, but in an educational context. And I think that really captures the bigger picture of Jupyter Jupyter's usage.

Yeah. And in fact we use them at datacamp for our projects infrastructure which as you know we teach a lot of skills in our courses in our projects we teach kind of end to end data science workflows using Jupyter notebooks.

That project style workflow is something that I've seen when I've taught data science at Cal Poly, my university, in that oftentimes it's helpful to start with students in a very highly scripted manner where the exercises are very small scale and focus on a particular aspect or a particular concept and then eventually transition to more open ended project based work. And I know in those courses the towards the end of the quarter when the students have an opportunity to do sort of end to end data science that's a little more open ended. The learning really increases a lot and the students get a lot out of it. So I'm thrilled to see that Data Camp has that type of experience as well now.

And of course we see notebooks pop up everywhere. From in the slide deck that we discussed earlier you have a Great slide on the Large Synoptic Survey Telescope. On top of that, of course, the gravitational waves were discovered by the LIGO project and they've actually published all of their Jupiter notebooks. So this is in basic scientific research, right to what's happening now. I mean, there's a lot of stuff happening at Netflix with notebooks now. So it's across the board, right?

Yeah. And this is really a pattern that we've seen emerge in the last two years, and that is a transition from ad hoc usage by individuals in organizations to official organization wide deployments at scale. And so you were starting to see a lot more organizations adopt Jupyter in a similar way to LIGO or LSST or Netflix, where it is officially deployed and maintained by the organization and many, many users are using Jupyter on a regular basis. And some of the larger deployments that we're aware of are many of many thousands or even on the order of 10,000 or more people. And so it's. The scale is definitely getting large in these organizations.

I'm going to state two things that I think are facts and correct me if I'm wrong, Netflix runs over 100,000 automated notebook jobs a day. And at least two either contributors or quality core contributors to Project Jupiter work full time at Netflix as well.

Yes, absolutely. So Kyle Kelly and M. Pacer are on the Notebook team. I don't know if that's exactly the name of their team, but they're one of the tools teams at Netflix and they work both with us on some of the core Project Jupiter projects, but also they have a number of other open source projects that work with the different Jupyter protocols. One of those is Interact, which is another user interface for working with Jupyter notebooks that has a focus on simplicity and Personas where individuals do want to work, some with code, but they're not living and breathing in code all the time. So business analysts would be a great example of the type of Persona that Interact is targeting. And then as you mentioned, Netflix has really innovated in the area of using notebooks in a programmatic way, running them as batch jobs every day. And I think your number of around 100,000 batch jobs that are notebooks a day sounds about right from what I remember. And they have a number of open source projects out to help with those type of workflows. One of those is paper mill, the other is commuter. And I think one of the things that I love about what's going on at Netflix, and I think this really comes from the leadership of Kyle Kelly there. And that is a deep understanding of the value of Jupyter's open protocols. And that is sort of a recognition that the different software projects that we've built on top of those protocols are sort of like a Lego set that you get, you bring it home from the store and there's a default instruction set to build something out of the box, but then realizing that the same pieces can be reassembled in different ways to build whatever your organization needs. And I love how that thinking has really sort of seeped into all the different ways that Netflix is working with data. And I think they're doing really interesting things as a result.

And the Notebook team at Netflix actually published a really interesting blog post article recently, which we'll link to in the show Notes, along with a lot of other things that we're talking about.

Yeah. And they also gave a number of talks at JupiterCon and those talks will be posted on the JupiterCon YouTube channel here in the coming month, I think.

Okay, fantastic. So when we have 2.5 million public notebooks on GitHub, I'm sure there's a lot of surprising stuff happening out there. And this may be a bit of a curveball, but I'm wondering if you've seen any uses of a Jupyter notebook that have surprised you? Have you been like, oh, wow, that's interesting. So like, what is the most surprising use of a notebook you've seen?

Yeah, I mean, one of the fun things about working on project Jupyter is to follow all the amazing things that our users are doing. And you know, I think seeing the impact that Jupiter's having in the world of scientific research is something that we're really proud of. And so to see large scale science such as LIGO and Virgo winning a Nobel Prize in physics and as part of that, publishing Jupyter notebooks that anyone in the world can use to completely reproduce their analysis all the way from the raw data to the final publication ready visualizations. That makes us really proud. I don't know that surprise is the right word to use there. Some of that is that that's the community that we came out of. And so we've always worked really hard to make sure that Jupyter was useful for those usage cases. In terms of surprise, the most surprising or shocking usage of Jupyter was by Cambridge Analytica and SCL Elections to build machine learning models to manipulate the 2016 elections. Right.

And I do think, you know, surprising is one word there. Shocking is another word. And I actually remember the first I saw a tweet and I think it was Wes, it was Wes McKinney who tweeted words to that effect. And we saw a screenshot of a Jupyter notebook with Pandas data Frame with some scikit Learn Fit and predicts or something like that. And that was a moment where I also stepped back and really thought, you know, all these tools can be used for all types of purposes, right?

So Cambridge Analytica, all of their Web presence and GitHub presence is gone. SCL Elections, which worked with them, hasn't taken their stuff down or hasn't taken all of their stuff down from GitHub. And so there's a project called Jupyter Stream. And you can tell that the people working at SCL Elections were typical data scientists who were excited to use these tools to do data science. And the thing that's scary is if you look in the demo subdirectory in notebooks, there's a notebook there and it's very clear the type of things they were doing. Now, in this particular case, it's nothing particularly sensitive. It looks like they were tracking voter registration counts by calendar week and, and working with a Pandas data frame with that. But we were certainly. Again, I'm not quite sure what the right word is. Surprise doesn't quite capture it. I think it was really a moment of waking up for us and realizing that it's similar having an open source project with a very free and liberal open source license is very similar to free speech, and that that a liberally licensed open source project can and will be used by just about anyone. And that includes people doing really good things, but also people doing really evil things.

Is creepy how this repo also says Jupiter to the rescue. Exclamation point.

Yeah, no, it is, it's really a trip. Like it's. I mean, and that was the original interview that Christopher Wiley did. So he was one of the data scientists at Cambridge Analytica. And in that first interview that came out, I think it was in the Guardian, he used the phrase build models. And immediately I thought, wait, hold on a second, this is a data scientist, they're talking about building models. What they're really saying there is import scikit Learn in a Jupyter notebook. And initially it was sort of like, yeah, they might have used it, or maybe they used RStudio. But then over time it's become very clear that they certainly were using Jupyter at some point.

So this is a nice segue into my next question. Which may seem like that's an answer to, but I suppose it isn't necessarily. My next question is adoption of notebooks, as we've discussed, have been huge and I'm wondering if there are places you see notebooks used where they shouldn't be used.

Yeah, I'm not quite sure I would phrase it where they shouldn't be used, but certainly I think there's a little bit of an effect where the notebook is a hammer and so everything starts to look like a nail. And in particular the type of workflow where notebooks begin to be rather painful is when exploratory data science and machine learning becomes more software engineering and more about data engineering. And in those usage cases, it's not a fantastic software engineering environment. It's really, it's not designed for that purpose. And now this is something we're hearing from our users that right now there's sort of a very steep incline between working interactively in a notebook and, and software engineering. And as someone moves across that transition at some point today, they get to the point where really the right thing for them to do is stop using Jupyter and open up their favorite IDE and start to do traditional software engineering. And that can be rather painful in the sense that Most of the IDEs that people love are not web based. And so, you know, if, if anyone is working with significant amounts of data and running in the cloud, those IDEs may not even really be a great option. And so we are working a lot to improve the experience at that boundary between interactive data science and software engineering. We don't envision that Jupyter's ever going to break, replace full blown ides. But it's really at that boundary where we're seeing a lot of user pain currently and where notebooks themselves start to be not the best tool.

Yeah, and that dovetails nicely into my, my next question, which is around the fact that there are several common criticisms of notebooks, such as they may encourage bad software engineering practices and I suppose Most famously recently JupiterCon is accepted. Joel Grus talk I don't like notebooks to be presented at JupiterCon and I'm just wondering what you consider the most important or relevant or valuable or insightful criticisms that can help moving the project forward.

Yeah, so I think there's, I really appreciate the talk that Joel gave at JupiterCon. It was a really well received talk and we want to hear things like this. It's really important for us. Some of the criticisms that he had about Project Jupyter are in the category of things that we could fix. So existing user experiences or features that we offer or don't offer or could improve and most of the things he brought up in that category, I think the whole core Jupiter team is more or less on the same page. The other aspect that he was bringing up gets more to the heart of interactive computing with Jupyter notebooks, and I think it's helpful to bring those things up as it really forces us to clarify the value proposition of that type of workflow in a notebook compared to traditional software engineering. And so that I think the discussion that's emerged out of that has been really helpful and something that that is helping us to clarify. When should you use Jupyter notebooks, or why would you use them, and why should you not use them?

We'll jump right back into our interview with Brian Granger after a short segment. I'm back here with Frederica to talk about machines that multitask. Frederica, you said that multitask learning is only effective if the model is asked to learn tasks that are related. What if they're not?

Well, if tasks aren't related but you're asking a single model to learn them all, then multitask learning may actually lead to worse performance. We call this negative transfer.

Okay, so how do I know if tasks are related?

Yes, so mathematicians have tried and failed to develop a formal measure of task relatedness, and in the absence of such a formal measure, you just give it a try to see if multitask learning leads to improved model performance. If so, it's likely that tasks are related. As a rule of thumb, if tasks are drawn from the same domain, say natural language processing, then they're likely related. Use your intuition. Even in the age of machines, it's still extremely valuable.

So can you give us an intuition for why multitask learning works?

Well, if you're providing a model with two instead of one set of labels, you're giving it more information that it can learn from. That is one of the reasons. Also, while single task algorithms struggle with noisy labels, multitask algorithms are more robust to noise. Usually, measurement errors are independent, so algorithms using multitask learning can average out noise during training. Finally, multitask learning acts as a regularizer. Since the model has to learn multiple tasks at once, it is less likely to overfit to one task and more likely to generalize to previously unseen data. The reasons for this remarkable effectiveness of multitask learning are rooted in machine learning fundamentals. It benefits you to know how and why algorithms work, not just how to use them.

Besides accuracy improvements, are there other benefits of multitask learning?

Yes. Multitask learning allows you to use not just one but multiple data sets to train one single model. Researchers have gone as far as training one model to master 259 tasks based on 259 data sets. Here, multitask learning was used to predict the likely interaction between medical targets and promising compounds, a part of so called virtual drug screening. Data on target compound interaction is produced in medical laboratories that investigate related but distinct questions under circumstances that vary from lab to lab. Multitask learning allows you to take all this data to train one single model whilst respecting likely differences between datasets by treating each one as a distinct task. To be clear, these tasks are related. Because the data is related, it is drawn from the same domain to answer same or similar research questions. Furthermore, multitask models also tend to be more efficient in production. A multitask model can give you multiple predictions while it needs to process the input data only once. And finally, multitask models can give you insight into task relations, which is pretty neat.

Got it. So what did you do with multitask learning?

We built a prototype, we call it newsi that puts current news in place perspective. We trained one multitask neural network on a body of news articles to predict news article category politics, sports, entertainment, you name it. News articles were taken from sensationalist tabloids. Think the New York Daily Post and the more buttoned up broadsheets. Think the New York Times Newsy was trained to predict the news category of broadsheet articles. That's task one. And tabloid ones that's task two.

So what does the prototype look look like in its final form?

It's quite interactive. Users can take any article they're interested in and analyze it as a broadsheet or tabloid article. Our multitask neural network reads the article like a human would from left to right and incrementally predicts the article's news category. Predictions are overlaid the article word by word. You gain insight into words associated with news categories given their unique context. The article you decided to look at the user can switch between a tabloid and broadsheet lens to study differences in language use and style across publication types. Crucially, this model, since it's been trained on 1.6 million articles, surfaces large scale reporting tendencies and other biases that a human reader may not or may only unconsciously pick up on. We found, for example, that reporting on the daily news tabloid newspapers are more likely to use language that signals factual statements such as reported or said. This isn't true for broadsheet articles. Tabloids also tend to report in politics and world news as opinion, which is an interesting choice since this may affect how we consume the news. It's good to surface these tendencies, and newsi does exactly that using the Power of Multitask learning thanks Frederica, for that.

Informative dive into the benefits of multitask learning. Time to get straight back into our chat with Brian so we've discussed notebooks, of course, but something I'm really excited about I noticed something you're incredibly excited about is the next generation user interface for Project Jupyter, which is JupyterLab. So maybe you can tell us what JupyterLab is and why working data scientists would find it useful.

Yeah, JupyterLab is definitely something that I and many other people in the core team are excited about. And Jupyter Lab is a next generation user interface for Project Jupyter, and we've been working on JupyterLab for around four years now, and just in the last month it left beta, so it is ready for production.

And congratulations.

Yeah, thank you very much. We're really pleased to get through that hurdle. It's still not at a 1.0 release because some of the developer oriented extension APIs are still stabilizing. And so it's one of the big things we heard of users of the classic notebook is that people wanted the ability to customize and extend and embed aspects of the notebook with other applications. And the original code base of the classic notebook just wasn't designed in a way that made that easy. So one of the core design ideas in jupyterlab is that everything in Jupyter Lab is an extension and all those extensions are NPM packages. And the idea there is that the core jupyter team can't build everything for everyone, and a lot of different individuals and organizations want to come along and add new things to JupyterLab and those extension APIs, which are the public developer oriented APIs of JupyterLab, enable those extensions to be built. And we're still in the process of stabilizing some of those APIs. But I want to emphasize that from a user's perspective, for people who are using jupyter on a daily basis, jupyter Lab is fully stable and production ready. And in many ways at this point I would say it's a better user experience and more stable than the classic.

Great. And what type of features do you have in jupyter Lab that You don't get in the classic notebook.

One of them is the ability to work with multiple different activities or building blocks for interactive computing at the same time. So the classic notebook, each notebook or terminal or text editor was a separate browser tab. And that made it very difficult for us to integrate those different activities with each other. So an example of how that integration would work in jupyterlab is if you have multiple notebooks open side by side, you can just drag cells between those two notebooks. Another example would be if you have a markdown file open, you can right click on the markdown file and open Live Markdown Preview and then also open a code console attached to that markdown file and start running code in any of the different languages that jupyter supports in a manner that's more similar to an experience like RStudio. And so having the different building blocks of places to type code outputs terminals, notebooks integrated in different ways to support some of these other workflows that come up around.

And also a CSV viewer, right?

Yes. So we have. So the other. Another big idea design idea in jupyterlab is the idea of more direct manipulation user interfaces. And so in many cases, writing code is the most effective way of interacting with data. However, there's many situations where writing code is a bit painful. And a great example of that is if you have a new CSV file, you don't know what's in it and you simply want to look at it. Of course, you can open up a notebook and import Pandas and start to look at the CSV file. But in many cases, more direct modes of interaction are are highly productive and useful. And so Jupyter Lab's file system access is based around the idea of the possibility of multiple viewers and editors for a given file type. And so, for example, for a CSV file, you can open it in a text editor and edit it as a plain text CSV file, or you can open it in this new grid or sort of tabular viewer that we have. And that viewer is the default for CSV files. So you can just double click on a CSV file in jupyterlab and it will immediately open in a form that looks like a table. We try to detect the delimiters in the CSV file and even allow you a dropdown to select those.

And I recall from one demonstration that it supports wildly large CSV files as well. Right?

Yeah. So one of our core contributors, Chris Colbert, spent a lot of time building a well designed data model and a viewer on top of that. So the, the data model for this grid viewer does not assume that all of the data is loaded into memory. So it has an API that allows you to request data from the model on an as needed basis. And where that's used is in the view that sits on top of that. If you have a really large CSV or tabular data model, the view is only going to request the portions of the data that are visible to the user at a given time. And so, for example, right now, like some of the demos that we're doing, you can just double click on a CSV file. It has over a million rows, and it's big enough those, those files are big enough that they don't open successfully in Microsoft Excel on the same laptop, and they open just fine in jupyterlab. And the viewer or the renderer that Chris wrote uses Canvas. So it's a very high performance tabular data viewer. And to keep ourselves honest, we've tested it with synthetic data sets. So these are not concrete data sets, they're generated on the fly, but that have a trillion rows and a trillion columns. And the tabular data set viewer works really well, and you can scroll through the data set just fine. And I think the, another side effect of direct interaction with data is that when you make it easy for users to interact with data in those ways, they're going to do that. Right? So if you can double click on a CSV file, a user is going to find, wow, that's useful. And they're going to do that. And you have to spend a lot of time making sure the underlying architecture doesn't let them do things that are going to have adverse side effects. We're trying to build an architecture that has both good user experience, but also can deal with the realities of large data.

And there are, you know, several other features that we could discuss, but I'm just going to pick one which I think is very attractive and fantastic, which is the ability to collaboratively work on jupyter notebooks with colleagues and collaborators.

Yes. So this is something that we've been working on for a while now. And our first take on this was a jupyter Lab extension that a postdoc at UC Berkeley wrote Ian Rose. And this provided integration with Google Drive and the Google Realtime APIs to enable multiple people to open a single notebook and collaborate in real time on that notebook and see the other people working and editing the notebook at the same time. And then in the last year and a half, we've started a new effort to build a real time data model and data store for Jupyter Lab for two reasons. One is that the Google Realtime API has been discontinued. And then the other is that we've heard very clearly from our users that there's many organizations for whom sending all of their Data to Google APIs is a no go. And so it's become really important for us to have a high performance, really well designed real time data store. So we've been working on that for the last 18 months. And again, Chris Colbert, who did the data grid, is the person working on that.

Great. And listeners out there. This has been kind of a whirlwind introduction to a bunch of features in JupyterLab and I'd urge you to go and play with it yourself and check out some of the demos online as well if you haven't yet.

And I want to clarify, the version of Jupyter Lab that's out today does not yet have the real time collaboration.

Okay, that's right.

Still not quite released yet.

So we've discussed IPython, we've discussed Jupyter Notebooks, we've discussed JupYterLab. What else exists in the Jupyter ecosystem? Could you give us just a brief rundown of a couple of the other things?

Yeah, absolutely. Probably the biggest other constellation of projects is the Jupyter Hub project. Jupyter Hub is its own organization on GitHub, and there's a number of different separate repos and projects there. And Jupyter Hub provides basically the ability for organizations to deploy Jupyter at scale to many users. And you know, with the sort of patterns of adoption that we're seeing right now, that usage case is really, really important. And as a result of that, Jupyter Hub is seeing both a lot of interest from people contributing and also organizations using it.

We discussed earlier the talk you recently gave at JupiterCon in which you stated that Project Jupyter is undergoing a phase transition from having individual users in organizations to having large scale institutional adoption. And I'm wondering what the unique challenges the project is now facing due to this transition.

Yeah, so there's both organizational and tactical challenges we're facing. On the organizational side, I would say the big challenge is that we're seeing an increasing number of organizations coming to us and wanting to interact with us rather than just individuals in those organizations. And that really changes the type of people you're talking to in the organizations. In many cases in the past it may have been data scientists or machine learning researchers, and increasingly it's Managers, project managers and other decision makers who are thinking about the broader data strategy at the organizations from a technical perspective. It brings out a lot of new usage cases, in particular in Jupyter Hub, to address the needs of large organizations. And some examples of those are security. Security is a really important thing for large organizations, in particular when there's sensitive data in the mix. Another aspect of that is that in these large organizations there are typically a wide range of different skill sets, responsibilities, roles, access, permissions and priorities of the people working with Jupyter. And so it's not necessarily just people who are living and breathing code all day long, but a lot of other people in the organization working with data that don't necessarily want to look at code all the time or even most of the time. And so there's a lot of work we're doing thinking about how will Jupyter need to evolve to address those usage cases.

Absolutely. So Brian, as my last question, I'm wondering if you have a final call to action for all our listeners out there who may have used Jupyter notebooks, may not have, but maybe may be interested in doing so.

Yeah, so I think there's a couple different calls of action. One is for people to engage with open source individuals. So if you're a data scientist or someone doing machine learning at a company or a student learning about these tools and techniques, engage with the open source projects, find an open source project you're interested in, understand more about the project, maybe help with documentation. And a lot of what we've found is that innovation happens when diverse groups of people come together and talk to each other and work towards common goals. And so the more people we have joining the projects and contributing and helping us think about these things, the better off and more healthy the open source projects will be. But also the users of those projects will be better served.

Agreed.

So, and a second call to action would be for people working in larger organizations that are using open source tools in this space. I think it's important to note that many of the open source projects, in particular those that are community driven, like Jupyter and many of the other GNUM focus projects, we continue to struggle with the long term sustainability and there are many core contributors to these projects that continue to lack long term funding and the ability to focus on working on the projects. And so if you're in an organization using these tools, I would really encourage you to talk to the people in the organization to think about and understand how you can support the core contributors and the broader sustainability both in the sense of community, but also in particular the financial sustainability of these efforts. That would be really, really helpful.

And I'll add one other final call to action there, which is I started using jupyterlab all the time instead of notebooks mid last year. I think I would urge anyone out there who still uses the classic notebook to jump into jupyterlab. I think you have no reason reason not to these days. It's such a wonderful place to use notebooks among many, many other things.

Yes, that's a great, a great point, Hugo. And even for the the part of my job where I get to use the Jupyter notebook, I transitioned in particular in teaching and some research to using Jupyter Lab back in January and it's worked really, really well in those contexts. And at this point I'm using Jupyter Lab basically all the time. And so I just echo what you said and appreciate the kind work.

Brian, thank you so much for coming on the show as I always love our conversations and it's been an absolute pleasure formalizing this and putting it out there.

Yes, and thank you so much Hugo for working on this podcast. I know a lot of people really appreciate it and thanks for having me on.

Thanks for joining our conversation with Brian we saw how much necessarily goes into open source projects, the scale of Jupyter, such as software engineering, UX and UI design, large scale organizational considerations and community building to name a few. We also saw the unique challenges faced by open source data tooling platforms in general due to the fact that we're now at a phase transition from having individual users in organizations to having large scale institutional adoption. Netflix is one example of many, as is the LIGO project's Nobel Prize winning discovery of gravitational waves. And lastly, don't forget to go give Jupiter Lab a test drive. You've got everything to win and nothing to lose. Also, make sure to check out our next episode a conversation with Cassie Kozikov, Chief Decision Scientist at Google Cloud. Cassie and I will be talking about data science, decision making and decision intelligence, which Cassie likes to think of as data science augmented with the social and managerial sciences. We'll talk about the different and evolving models for how the fruits of data science work can be used to inform robust decision making, along with pros and cons of all the models for embedding data scientists in organizations relative to the decision function. We'll tackle head on why so many organizations fail at using data to robustly inform decision making, along with best practices for working with data such as not verifying your results on the data that inspired your models. As Cassie says, split your damn data. I'm your host, Hugo Baun Anderson. You can follow me on Twitter @hugobown and data camp@datacamp. You can find all our episodes and show notes@datacamp.com community podcast.