 Well, thank you very much. I appreciate the opportunity to be able to present. I did give a very closely related talk earlier for those of you who were at Strata, although now I think let's go into a bit more of the engineering on this and a bit more of the transformation of how we got here and what we're trying to do. I had been involved with Spark, I'd been the evangelist for Spark before, and prior to that for Mesos, and before that I'd led data teams and industry for about 10 years or so. Along the way one of my teams was doing some natural language processing and we got approached by friends up in Seattle to try out a new thing, and we became one of the first teams to be using something that's now called AWS. So I had the privilege of being one of the first few people outside of Amazon to do 100% cloud architecture. And then while we were working on that project we ran into some bottlenecks, and one of our young engineers who's now CEO of Mesosphere, he brought up this new open source project that we should try to use in the cloud. It was something called Hadoop. So this was late in 2006 and then we ended up having some problems with that and we wanted to run it more efficiently on EC2 so we pulled down a Jira ticket and ended up creating something that was later a case study for Elastic MapReduce. I got to see a lot of interesting things in industry in terms of big data. I got to work on a lot of those projects and then an opportunity came to join O'Reilly. And O'Reilly is not a technology company. We've been around communities of technology since day one. I don't know if you know the origin story for O'Reilly, but Tim and Dale were hanging around Unix user groups background Harvard in the 80s and they thought the documentation was pretty bad for Unix. So they started writing better. We've done a lot with technology conferences and technology publishing, but we're not a technology firm. So about two years ago, Andrew Otawan, who's a CTO for O'Reilly, he was looking at Docker. He was looking at Spark. He was looking at Hadoop and Mesos, a lot of these kinds of technologies and realizing that we're going to have to get busy to transform ourselves to become a technology company, to become much more specialized in big data, in analytics and data science and so that's about the time when I jumped in. And so part of the glue for all this is, since we're a publisher, something called Project Jupiter. How many people have used Jupiter? Okay, good. So 25% or so. And if you haven't heard of it before, this is an evolution of what had previously been called ipython notebooks. Fernando Perez had created this. Fernando jokes around and says that he used this to be able to delay getting his dissertation done. He's a physicist. He's now at Lawrence Berkeley. There's a lot more than ipython. Notwithstanding the name, if you look at this here, let me see if we're, am I? Yeah, I'm on. Okay. If you haven't used this, there's 50 plus different environments, different kinds of programming environments that you could use with Jupiter. So it's not just Python. It has support for Python 2.3 by default. And then JavaScript, Ruby, Haskell, Clojure, Scala, pretty much anything that has a REPL can be wrapped up into the protocols as a Jupiter kernel and then subsequently have some kind of Jupiter notebook. I've got some notes here. If you want to install it, there's a little bit of an example that I can go through. I'll probably dig more into the engineering as opposed to this part here, but I'll have the slides up if you want to try it. I definitely recommend using Anaconda is one good way. You can use pip or other ways as well, but Anaconda has the distribution on this very nicely. And so here's a sample application, a little bit of NLP. I've got a couple of paragraphs of text, and then I've got a really great Python project called Text Blob. It has a very high performance statistical parsers in it, as well as named recognition and noun phrase chunking, a lot of good things that you would want from NLP. So I showed how to do a couple of these here. Basically convert the text, parse it, you get a blob object out and then we'll print some of the part of speech tags, print the noun phrases, typical things when you're doing NLP. Now to represent that as a Jupyter Notebook here we've got you can see it's broken into a few different cells. So we start out, we've got some text, some hypertext, that's a markdown cell. So you've got some kind of data in there that's being rendered as hypertext. And then next you've got text equals and then a couple of paragraphs. So you've got some data. And then next we call in a library, we call in some code. So that's a code block. And then next we've got another cell that executes and prints out some kind of result. So that's the notion of a notebook is this linear arrangement of cells that can be marked down, they can be code, they can be output, and you can build a narrative out of that. Now the thing about Jupyter, what I'm getting toward is we treat it as middleware. That was the original idea when you talked to Fernando about it. The idea is that HTTP is really capturing the remote semantics of file share. You can get, you can put, you can delete, but you're sharing files over a network. And HTTP is a network protocol for capturing those semantics. Jupyter is the network protocol, the semantics for a REPL, a read, develop, print loop. And so the idea is that you can do remote execution on some type of REPL. So for instance, when I was at Databricks, Databricks Cloud using notebooks, the idea is that Scala, Scala, Python, R, etc., these languages that are interfacing Apache Spark, these are effectively REPLs. And even though there's a cluster behind it, you know, you're interacting with a REPL and then you can have a notebook as something capturing your application. So there's a great team behind it. There's a lot of great projects. Jupyter Lab is the new thing that's coming up. It's more of an IDE. There's Jupyter Hub that's more distributed, used in universities a lot. And there's an event coming up. There's a worldwide conference called JupyterCon that O'Reilly is helping to put together. But the reason we're doing this is because we're a publisher and we recognize that publishing changed. So when we talk about data science, you probably hear the term data visualization, data storytelling. You hear these terms used a lot to describe how to interpret the insights that are produced out of analyzing data. But yet when we talk about storytelling in general, we could talk about books, we could talk about movies, a lot of different applications of media that are much richer than just the sort of plots that we tend to get when we do data analytics. And that was something that we were very concerned about at O'Reilly is how do we get to something that's richer. So when you think about publishing online, it's usually HTML or video. Most of what you publish online is that. And we were interested in how can we push this further, how can we publish something more interactive. So there's a few different articles here that go into this in more detail. In particular, Andrew Otawan and Tim O'Reilly joined in on some of this here. It's examining what we're trying to do with Jupyter, Docker, and along with that, Mesaus and others. And the longest short of it is this. When you come to a conference like Strata and you go to a tutorial on whatever topic, it might be a three hour tutorial. You might get a vagrant file on a USB stick as a way to put together the code that you need for the tutorial. Or you might spend 20, 30, 40 minutes installing software just before the tutorial gets going. How many people have had that? It usually goes for 30 or 40 minutes into the tutorial. Yeah, exactly. You lose that part. So that's our core business. And we were like, this is messed up. How can we fix this? Because the Wi-Fi is pretty bad. We thought about bringing in a big box full of processors and just setting up our own little cloud right there on the stage. And we actually built cabinets for that. But what we realized was we could do better. And right about that time is when Docker started getting popular. So we wanted to figure out how to put together Docker and with it, the infrastructure behind that for a new kind of media. And so it's probably better to show than to tell. Here is Peter Norvig, who's head of research at Google. He did the first one of these. And it was a real pleasure working with Peter because he also knows a lot about education. Definitely internally in Google. He's led search and AI there. But also with Udacity and others. He has a thing or two about education. So I'll bring up a tutorial that he did. And this is in a service that we have called Safari. Almost all of the content for O'Reilly is moving into a membership platform called Safari. So here are some tutorials. Here's Peter Norvig. I don't know if I'll get sound out of this, but you can try it. So Peter had a Jupiter notebook called Regex Golf. Because anybody here ever read a comment called XKCD? So Peter was introducing Randall who does XKCD. He was introducing Randall Monroe at a conference. And Randall got up there and started talking about this kind of programming context. How to optimize Regex to get the smallest possible one for a given data set. And Peter listened to this and he was like, no, that's wrong. You didn't do this right. So he wanted to go and fix it. And he created this notebook to describe basically a programming contest of how to get the smallest Regex that would give you coverage across a particular data problem. So what we've got here is Peter on camera for about 20 minutes talking about this and really giving you the big picture of what he's trying to do with this programming challenge. And alongside that though, you've got the hypertext, if you will, the rich media with links that dive deeper. But you've also got the code. And so we can run the code and basically the way this is set up the text and the code can sync to the video and the video can sync to the text and the code. You can use one to drive the other. So here I'm just going to click a few of these and you can see that as I'm running the code I get some output from that. But the whole time I could just be running Peter or I could scoot through to a different part and say skip to here and have Peter pick up from there. The other thing about this is that I can come in and change the code. So instead of printing out that, I could come in and say print gosh, I think Peter was doing Python 2.7 on this. So let's see if I get an error or not. If not, I'll fix it. I did. Okay. I converted this to Python 3. Run it again. I can change the code and rerun it. So the idea with this kind of media is it's purely HTML but everybody who sets up a web page, a session also we spin up a Docker container in the cloud and that's your private sandbox. And that Docker container has all the Jupyter resources, the kernel, as well as the code, the library that you need to run, any data that you need. It's all containerized there. So everybody has their own private instance of this running in the cloud. And so, okay, that speaks to the problem of walking into a tutorial and instead of spending 40 minutes setting things up, boom, you just go to a web page and you're going. But it also means that you can follow along with somebody like Peter and look at the code that he's saying and you can go in and change the code, play what ifs, see if you can beat him. And that's actually the point of this tutorial is Peter is basically throwing down the gauntlet and saying, look, this is the best I could get out of these regex definitions but see if you can beat me. So it's very much a hands-on way of working with code at the same time hearing the thoughts of the expert who put it together. And that's the idea of computable code in a nutshell is how can we bring together these components of code, data, text, video all into a kind of narrated experience that you get to have hands-on and try it. And what we found when we started launching this, we're still experimenting and trying different forms, but we found that number one, our engagement metrics jumped by an order of magnitude. And as a publisher, that's very important. That's what you're trying to go for. What we also found when we started talking is that if you're in academia, if you're a university professor and you have to publish or perish, we're finding that the economics of publishing books is just falling out. Books really don't bring in money unless you're a bestseller. And so if you're an assistant professor that's tenure-tracked and you're trying to make money by doing a textbook, good luck. It doesn't really work that well these days. But what we do find is that these same people are taking and building up materials, learning materials in Jupyter notebooks. And if you go to GitHub, there's over 300,000 of these that are published, are public Jupyter notebooks. Of course, they're not all by professors, but a lot of more. A lot of what's out there right now is coming from the sciences. And so for instance, when the LIGO work was published, when the Gravity Waves work was published, it was published as a Jupyter notebook. So the reason why we did this was again about big data. And we saw a challenge that we had to try to solve. Part of it was from the audience and part of it was from the authors. The audience needs to be able to get hands-on very quickly with materials and be able to run code as opposed to having code in a GitHub repo and a book over here. Now you have it all together. The other part of it is that we really do practice peer teaching. That's been O'Reilly since day one. And we have a lot of great authors, a lot of great instructors who are out in industry who are practicing or leading open source projects, their tech leads, etc. They're busy people. So when we create a book it's usually about a six to nine month project. At some other publishers I've been at it's more like a two year project. When we create a video video also takes months. And in particular a six hour video probably takes about eight times that amount of time to prepare it. You probably take some time off work to fly to the studio. You spend a week in the studio, you fly back, and then you spend another couple weeks doing post processing. You're taking three weeks off work to create a video. And we find that people just don't have that much time anymore. And also we find that the rate of change for technology is increasing so we can't wait six months to cover a new topic. We wanted to decrease the time to market. And by using Jupyter, by using Docker, by using Mesos, we're able to cut that time down from six months to about three weeks. So now we can get a new substantial tutorial out again within weeks. And so the architecture is this. At the base level it's cloud. We started out building this on two different clouds and now we're building on two others. And the part where our software comes together is that we built an architecture at the cluster layer, which is primarily Mesos but then Marathon on top of that. How many people have worked with Mesos? Okay. How many people have worked with Marathon? A couple. Okay, good. So basically Mesos is your resources for your cluster. And then Marathon would be like in it D. It's basically how are you starting your services? How are you having your services running? And for us the services we needed to have were guarantees that some number of these Docker instances were running. So for each different product there might be a different Docker instance. And Marathon does that kind of service scheduling, service provisioning. We also had to have statefulness. So we built an application gateway, also a security gateway, based off of Redis and IngenX. So that provided the other parts of it are Docker and Marathon are relatively talking about a mutable infrastructure whereas IngenX and Redis are more the statefulness. And that's all on the server back in. In the middleware we have Jupyter. So again, Jupyter is a suite of network protocols that give you the remote semantics of Rappel. And so we use it as middleware. And then we put something on top of that called Thieb. It's an open source project. It's on GitHub if you want to check it out. Basically you can take what is published in Jupyter and project it out as HTML. So it's like an HTML player for YouTube where you have a little fraction of HTML that you embed somewhere. A very similar thing with Thieb. And then the last mile is where people interact with this. And that's, you know, it's Web Component. Well, it's moving to Web Components. We started doing this before really we were going to take a bet on Web Components quite yet. But it's HTML CSS JavaScript. And now we're moving in more to Web Components. We also use an open source video player called Kaltura. Most of our work is done with Kaltura. And that fits very nicely with our content delivery network. And then Keen.io for instrumentation. The thing that I'm not showing here is that by virtue of having this kind of cluster architecture, we can bring in a lot of other services. Optimization services, data services, whatever is needed for the tutorials to be integrated and that Docker containers can consume from those. So alongside of this, we have a Kubernetes cluster. And then we also have our log capture log management in Kibana where, for instance, we're instrumenting as people are running code, we're watching if there's exceptions. And we're gathering that out of our logs. Ostensibly we could use that for real time services eventually to give feedback to people if they are running problems with the code that they're writing, we might suggest some other material that they go study. So that's kind of like actually a four layer architecture then for where O'Reilly jumped into big data. And the big data part of this is that we have millions of people interacting through Safari and we're capturing a lot of log files of their interactions. And so one of the things that we built up on top of this is an API for, based on React actually, an API for formative assessment. So you can do live coding but we can watch how you're doing the coding. And we have the log files and now we're starting to build out with Kafka some more real time streams to take advantage of that. Hopefully integrate that into our content recommendations. What this strikes to, I want to give a little bit of history, how many people have run across literate programming by Don Knuth? Okay, great. So Don, I was at a particular university where Don was teaching and I was a grad student and Doug Cutting was an undergrad all in the same department. Way, way back when, many years ago. And Don and I used to fight over the laser printers which were new. But he came out with this idea of literate programming. The paper that I first saw about it was in 1983. And go back and check this paper because he described something in 1983 that he called Web, W-E-B. And if you read it, it sounds suspiciously like HTML. So that was years before we saw anything like World Wide Web. But definitely check out some of the early origins of literate programming. But he did publish a book about this and the idea is instead of telling computers what to do, instead of going into intricate detail of our programs and writing more and more complicated programs, instead we should focus on telling other people what we want the computers to do. Such that the programs are a byproduct. But we have the social context, getting back to what Doug was talking about earlier and also what Ted was talking about, we have the social context of other people understanding what we're trying to accomplish. And it's really that side by get Apache that is so important. And so this is more than just having documentation in your code. This is where you actually have a narrative, a document that's executable. And some people picked up on that. Wolfram Research did notebooks for Mathematica. They really set the bar. And arguably, Jupiter descends from this. I think in many ways, Jupiter used some of these ideas. And it's still probably the best notebooks that are out there. But more recently I would point you toward a keynote this year at PyCon from Lorena Barba. She's at GW. And I've got the video and the slides. She went back to talking about really some of the social theory of open source projects. And for this she's invoking something called Speech Acts. And that goes back to Terry Winograd and Fernando Flores. Fernando Flores had been one of our instructors a long time ago. And it's interesting, Winograd and Flores were back at Stanford in that time period I was mentioning back in the 80s. They came up with something called Groupware back then. And if you don't know the background on this, it actually ties into Google. Some of the early ideas of Groupware kind of seeped into the early parts of Google. If you look back on it, Terry Winograd was also Larry Page's graduate advisor. So back when Google was still at Stanford. There was a lot of overlap here. Lorena is digging into open-source culture and structured collaboration as Speech Acts. And this really goes back to a lot of the early work from Fernando Flores. He was in a project called CyberSyn back in the 70s. Anybody ever heard of CyberSyn? It was Chile back before the U.S. invaded Chile. It was Chile's efforts to have a cybernetic economy. Have a very planned data-driven economy back in the early 70s. They had one small mainframe they could use. And Flores was really the architect for that. He was later, as a result, became a political prisoner. He was in prison for a number of years. And then Stanford and Berkeley got him out of prison and brought him up to Stanford. There's some theory behind it. I want to talk a little bit about a couple of things here. If you are working with Jupiter, we've been working with a lot of authors and we've found some dos and don'ts. The main thing is you don't want to have a notebook be too large. You want it to be a unit of thought, kind of like a unit of work. And you definitely don't want to have a page of text and a line of code and then a page of text. You want to chunk the text and the code. You also don't want to have a page of code. It's better to break it down, have a few lines of code that accomplish something that has some kind of result that people can try and see, execute. And that helps to build a kind of narrative flow. So we've been working with people like Lorena Barba, who's an expert in using Jupiter in education. And the point of this is repeatable science. So here we are working with big data tools and enabling data science teams to gather really amazing insights out of data. We want to have repeatable science and more particularly we want to have repeatable data science. Notebooks are a great way to get people out of the IDEs and instead producing narratives, producing documents that encapsulate the code, the data, and really the rationale of what they're doing as well as explaining and showing the insights. So it's through, we believe that by using Jupiter in some new and interesting ways, that this is leading towards much more repeatable data science in a team context. Now, as far as building things, this gets interesting with Mesos. We have a tool that's publicly available now, it's called Launchbot.io is where it's at. And the idea is if you have Docker on your laptop and you bring in Launchbot, then it's a bridge between GitHub and Docker Hub. It's a place where you can take and build containers and also build notebook resources fitting in those containers and then be able to do your commits, your check-ins respectively in Git and in Docker. So it's a way of, if you haven't built Docker containers before, that can be a very time-consuming and memory-consuming activity and a lot of command-line use. And it's not something that we want to have our authors worrying about. So we have this tool, this is also done by Andrew Otawan, who's our CTO. Once you have material in a container, then you can slide that over to DCOS, run it on Mesos, that's our view. So effectively we're containerizing content, publishing containers now in lieu of publishing books. That's what we think that things are headed, or at least one major direction for things to be headed. But it's a great way of being able to balance working on your laptop and then achieving scale. And so that's about what I've got there, but I can talk more if you have any questions about what our transformation is. I will add one anecdote. I was in an engineering meeting when we were first rolling out some of these ideas. And we had a lot of engineers who, you know, they have this history of having been involved with one of the first e-commerce sites. O'Reilly was very, very early in e-commerce. And so they've had this tradition of e-commerce for many, many years. And we were trying to talk about bringing in Kafka and bringing in Spark to do the analytics, bring in Docker, bring in Mesos, these different big data technologies. And the engineers were pushing back and saying, we don't know, and it would be too costly. How can we learn about these new technologies? And there was literally a book about Mesos on the shelf in the meeting room. And I pulled it off the shelf. I was like, I think I know a publisher. And that just shows you that we are really talented engineers, but they're not used to big data. And they felt relatively threatened even circa 2015 by introducing these new technologies. But it's been a challenge, but we've been bringing them into it. And so that's part of the transformation with Safari. And moving all the O'Reilly content in Safari is retooling all of that as one large machine learning project in some ways. But certainly one heavily instrumented big data project. And so I find that somewhat ironic that we're hosting these technology conferences, but we're also having to do our own...be humbled and do our own dog footing. Anyway, with that, thank you very much. I appreciate it. And I'd love to answer any questions. That's great. So I'm thinking of creating architectural landscapes. Okay. You know, definitely, I mean, there's nothing terribly secret about the Jupiter aspect of it, other than the fact that it's plumbing. There are Jupiter notebooks, but our audience doesn't see them. We don't show them. We show the HTML. So similarly, we've looked at things like JSBAN. Like if you were teaching a course, for instance, on web development, you wouldn't probably use a notebook. You wouldn't probably use a notebook. You'd use something like, gosh, I'm blanking on it. But JSBAN is one of the options. There's several of these where you could show, for instance, your HTML and your CSS and your JavaScript side-by-side, and then show them being rendered. So that's an example of where this whole architectural pattern of mesos and Docker and the middleware and then the last mile in HTML, we can just plug in something else. So you were talking about architectural landscape. Okay. Perfect. Was that Mark Medson's talk? Great. Excellent. Really great talk. I love that. The second and last slide, if you all didn't see it, the second to the last slide was the one that just really got me about the adaptive patterns in lieu of static data warehouses. I thought that was a gem. So yes, nothing's particularly sacred. This is the first toe in the water for us, but we do feel that this kind of, again, having a mesos cluster, we can do a lot of multi-tenancy and deploy a number of things on the same cluster. We feel that that's important. Having the Docker containers basically provide a sandbox, but also provide everything you need for that use case. We feel that that's very important. What gets stuck in there, whether it's Jupiter or something else like it that allows you to interact, it could be a VR plugin. We've looked at that as well. It could be a hardware simulator. That's another thing we've been talking about. So yes, being able to work with some kind of architectural scenarios, like Mark Richards does the Kata's for system architecture, I could see that they're a similar kind of thing. In fact, Mark and I were talking about Richard about that kind of use case. So we're trying to experiment and also see if there are ways to just publish Docker through Safari or publish Jupiter through Safari or other things like it. It's interesting when you get into other domains, when you're not programming because we also publish about business, we publish about design and in these other domains the editors are just hammering us saying, well, why don't you make Jupiter fit this? Maybe it needs some other open source technology. Maybe something else would be closer to it. My brother works in Hollywood and does animation and films. What transformative in terms of how we can deliver education in the future and its remote parts of the world, suddenly you're going to get a big problem. Something that's not here is the chat side of it. When we're teaching online, we make heavy use of the social aspects and the interaction. People do group projects with other people they have never met. So putting a Slack plug in here, for instance, would be interesting. Have you seen Mural that Microsoft and IBM are working with? But basically having shared whiteboards across the Internet. Being able to have basically a plug in here, you can have the literal whiteboard, you can have your mobile devices or you can have the laptop. We've actually talked with Mural about doing some integration. So that would be more what you're talking about there. One thing that struck me looking at this is you've got an interface and you've got Compute on the back end and you're using programming which is just talking to the native Compute on the back end. Why is it just limited to programming? You could have simulations. Anything could be simulated. Economics, airframe design, whatever. You could have that interface on the front and Compute on the back end. Between Unity and AutoCAD and the rest, there's all kinds of simulation engines. Universe now with deep learning on it. One thing I didn't bring up, just to give you a perspective, 20 years ago this guy was doing chatbots. And now you guys are just catching up to him. So in 20 years he's going to be going, holy shit. I should have taken it when he said a lot more seriously. Question. Yeah. So one of the things I like about bookstore is it's more reflective. So it kind of takes time to kind of develop the people understanding of what's going on. What do you think about this in terms of trying to keep speeding it up? So this doesn't completely replace books. I owned a bookstore for seven years and I had performance art inside the bookstore and I love that experience. As an author, the thing that I miss the most with online is that I don't get to do the book signings like Ellen and Ted were doing today. That's the thing I love the most is meeting people and having the line. So yeah, it begs a different experience. So the thing about this was to really capture a unit of thought. So human attention span is approximately 18 minutes. And we're guiding people to do video segments that are very short for us traditionally. We do 6-hour videos or 10-hour videos. These are typically 15 to 20 minutes. And so the idea is to capture somebody who really understands a topic like Ted talking about streaming or Doug talking about Apache Hadoop. Can we get them for the length of human attention span in one nugget to talk out loud about what they really think? Or for instance Peter Norvig talking about AI. Can we get them for 20 minutes to share that with us? And oh by the way, here's something we can interact with ourselves because that's a kind of trick of the mind to be able to learn. When you get that expert perspective but then you also have the hands on then we find that people absorb the material much more. So this is just a nugget. Now in terms of more substantial media I think what the answer there ultimately is pedagogically we see pathing. So one of the teams that I lead, I hired a small number of people who had a shared experience. They had all been professors teaching in academia myself included. They'd all been industry trainers and they'd all been authors for some popular book or video. So they knew a range of how we were working but they understood it in terms of pedagogy and instructional design and curriculum whereas editors don't know that. And one of the first things we've done is what we call pathing. We'll take a chapter of a book here and a section of a video there and show a narrative through it and then bundle that, present that as almost like an online course. And we find that the stats on that are just through the roof. People really understand paths because it goes from a need to a goal. You progress. So I think that that's kind of the evolution and that will involve books. I don't think books will go away. I really, really hope they don't. And I would never want to try to help push that. So this is just kind of a nugget whereas I see the evolution of media for education is more the pathing. Does that... The other thing about pathing getting back to big data is that we have it instrumented. So the new paths that are coming out, I think this will probably be January, they have what we call formative assessment where you sort of learn while you're taking a test and you get feedback and so as you go through the path at different stages, here's a little quiz with randomly selected five questions about that topic and it'll get feedback right away, but that goes into log files. So by the time that you're done with the path we have a pretty good idea where you stand in this and the content recommenders can then jump in through the real-time streams and say, oh we think maybe you should try these other books first before you move ahead. I think that kind of real-time scenario of people interacting with media, I think that's more likely. More questions? Yeah. How do you see the future for content better? Is this possible content better? Well, I see Jupiter as like it displaces word docs. I see it as a better way of doing word docs or it displaces a Python script. It's something that's richer. But as far as delivery a lot of this has been very much web based, very much laptop or desktop based. The thing that we haven't cracked yet is something that's really good for mobile. And part of that is how are you going to go in and change a code cell and let me get back to this. How are you going to go back in and change a cell of code on a mobile device? What's the UX problem? I mean maybe we can zoom out, but are we able to do code editors on a mobile device or even on a tablet? We don't really have a good answer on that. What we did though was we went to a school where people learned to be designers and developers at the same time. And so everybody getting a degree, they get a dual degree in software engineering and interactive design. And it's out of Columbia. It's called ITP. And we worked with them and really posed this problem to them. And they were really the main developers on this project. But they're still thinking about it. They're still trying to figure out where that goes. And maybe it means that mobile devices change over time too. Maybe AR becomes part of this. I have a lot of hopes that some type of augmented reality solves some of that form factor of very small devices. You should be pitching this to the Singapore government. Actually some of the folks from one of the universities came up, so we may be talking. Students, they can learn everything, everywhere, all the time. I'm down with that. Do it on mobile. I'm sorry. Question. I thought for this audience it wouldn't be quite as... Quite as much. Let me dig back up here. Let me play and then I can go backwards. Do you know about Zenodo? Right here. It's down at the bottom. In academia, typically when you publish a paper to make it sightable, there's something called a DOI, a digital object identifier. It's an academic work, or URI. But a DOI is what you need to have assigned before you can really call it an academic citation. So Zenodo is a service that will allow you to, or they provide the way where you can get a DOI assigned to a GitHub repo. So you can check in a notebook on a GitHub repo and then assign a DOI, and from that point it's sightable. And this is used in practice. Again, if you're familiar with... I'm not as familiar as I should be. I was with Fernanda Perez right after the Gravity Waves part got published. I was there a couple days afterwards. He's a physicist by training. He's at Lawrence Berkeley. And they were just beside themselves because these other physicists had published about Gravity Waves using Jupiter notebooks. And that's definitely sightable. Does that help? Thank you for coming. One more thing to wind it up for some of you that came in a little bit later. Thanks. Some of you that came in a little bit later. Shrivas, the chief data architect for Uber couldn't make it tonight. Again, apologies. But I did see his talk today at Strata. And let me summarize it for you. You think writing your test cases are hard? Try writing a test case.