Bryan Van de Ven on Bokeh

Hello, and welcome to podcast.init,

the podcast about Python and the people who make it great.

You can subscribe to our show on Itunes, Stitcher, or TuneIn Radio.

You can also subscribe to our RSS feed with details on our site. Please follow us on Twitter. We're podcast under init. Or you can find us on Google Plus where we're at plus.google.com/pluspodcast

init the Python podcast with dashes in between.

Please give us feedback. You can leave a review on iTunes,

send us a tweet, send us an email, or leave us a message on Google plus.

I would like to thank everyone who has donated to the show. Your contributions help us make the show sustainable.

For details on how to support the show, you can visit our site at pythonpodcast.com.

And there's a new Python podcast that just started up recently. It's called the Python Test Podcast and covers the world of testing in Python. So go ahead and give it a listen. You can find it at python testing.net.

We're recording today on August 18, 2015, and your host, as usual, are Tobias Macy and Chris Patti.

Today, we are interviewing Brian Van de Vind about the Bokeh project. Brian, could you please introduce yourself?

Hi. Yeah. So my name is Brian Van de Ven. I work for Continuum Analytics down here in Austin, Texas for just about 3 and a half years.

I'm right now the, the project lead, directing the the Bokeh visualization

project, but I've also done quite a bit of training and teaching for Continuum as well. We do a lot of, you know, professional services and training, and so I've had a good time doing that. And, in the past, I've I've worked with Python, a bunch of different, context, so I'm excited to talk with you guys today. That's great. It seems like Austin is the hip hop in place for for start ups and companies to be these days.

Yeah. Absolutely. So, you know, there's a lot of start up activity here. We have, you know, a new WeWork office for CoSpaces, and it's packed to the gills pretty much constantly.

General assemblies here teaching classes for people to get into coding all over the place. There's pretty much meetups any given night of the week. There's just no shortage of sort of tech,

happenings in Austin. Certainly, there's a lot of startups here as well going back to Austin Ventures and now new sort of funding initiatives as well. So, yeah. You're right. It's absolutely a great place to be for for working in tech, and I love it. So how did you get introduced to Python?

That's a great question. So I've actually been using Python, sort of on and off. I've had sort of an on and off history with Python, but it goes back, really a long time. I actually had to think about it. I think the first time I used Python was

just about another lifetime ago. I was a sysadmin at a Motorola,

wafer fab here in Austin in 1997, so I think it was Python 1.4.

And so at the time, really was just doing some basic shell scripting and, you know, web scripting. I think we're using, you know, mod Python with Apache, and, it was interestingly enough, my first sort of

exposure to graphics and plotting on the web was back then too. There was some package. I have no idea what it was at the time or what it was now rather, but, you know, it used pill, I think, to generate images, bar charts, and and pie charts. It was very simple static, images that it could display, you know, on your on your website based on some data. And so I thought that was really neat, and so that sort of goes back a long time. But that was my first exposure to Python, and then I used it in various other places as well. I used it at a research lab I worked at working

on sonar systems. I worked, you know, on on other plotting systems as well. And then, of course, here at Continuum, we're a big

big investment in Python, of course.

So for our listeners who aren't familiar with what Bokeh is, can you describe it?

Yeah. Absolutely. So Bokeh is a a library for creating interactive visualizations that maybe have novel,

types of graphics or that can handle streaming or large datasets or that can have widgets and interactions and all of these sorts of things together, that you can have these sorts of, interactive visualizations,

in the browser, sort of as a first class concern. It's 2015. That's the right target to be in, I think, is in the browser, but without having to write really JavaScript. Right? So so we're, like I said, as I mentioned, a big Python shop. So we've invested heavily in in, what I'll call Python bindings for Bokeh, but, the architecture of Bokeh is actually such that you can create bindings for it in a lot of languages. And so other people have come along and and created bindings for Bokeh and R and Scala and Lua and, you know, it's just exciting time. I'd love to to see, bindings for for Bokeh anywhere and everywhere. But,

you know, the main idea is to enable people to to create these visualizations that can handle all kinds of interesting things with a minimum of code, but a lot of expressivity

and a lot of power.

So what inspired you to create bokeh? Yeah. Absolutely. So, you know, first credit where credit is due. So the, you know, the initial, I said vision of bokeh, really, I think, goes down to,

1 of the cofounders of Continuum, Peter Wang. He's a friend of mine for a long time. We worked together previously at a different job, and and he had been working on a library called Chaco for interactive visualizations,

a rich client environment. And so we worked together on that. I think I added some features like, you know, image plots and contour plots and some and some widgets, and the focus there was really interactivity. And so Bokeh is sort of an evolution,

I think, of both of our ideas about that. You know, obviously, again, making the the web and the browser a first class concern because it is it is 2015,

but also just being able to handle newer sort of challenges, again, sort of larger datasets that you might wanna put

into the, you know, into a client, or streaming datasets and and all of those things. And the other side of that coin is, of course, that it's not solely my creation. Right? I mean, I I'm very privileged to work with just an amazing team of people, and Bokeh has grown into a quite large project.

And I'm, you know, I'm very grateful, to to be able to work with everyone, on this team and to be able to work with so many talented people who are contributing in all kinds of different ways. You know, I wouldn't be able to do all this together. We have people who are working on, you know, build automation.

Damien Avila is a core IPython committer. He gave a talk at SciPy recently.

There was a talk right before him about build automation, how a project reduced their release cycle to sort of a a matter of months, and, you know, they got their releases down to a few days. And he gave a talk, and he showed off the automation he'd done for Bokeh, and he actually, you know, fired off our release, you know, did a Git tag, and released a a dev build during the talk, and it was done at the end. And so, you know, things like that. I worked with really just amazing people who who really make, okay, possible. But, you know, the reason we wanna do it ultimately is to be able to connect people to allow them to connect to data and to be able to do that in a very easy way. We wanna build a bridge so we can let data scientists, data experts, domain experts really get to their data and get a look into their data with sort of a minimum of, hassle and fuss. And and, again, sort of not having to write JavaScript is a big, part of lowering that barrier.

Yeah. I know that d 3 is a really popular library for visualization, and pretty much every time I've heard someone speak about it, it's generally in the context of trying to figure out how it actually works so that they can actually

use it effectively. So it's definitely nice to have projects like Bokeh around to make it easier to produce data visualizations.

I know that there's

a project called Vincent for being able to use Python to generate d 3 d 3 visualizations

that goes through a couple of transpilation steps before it gets up to the browser. So having a tighter integration with Python

is definitely a good, good advantage for the Bokeh project. And it's great to hear that it's got such a large and supportive community, and it's always nice to have a company

behind it to make sure that core maintainers

don't get totally burned out on trying to work on the project in their free time because that's definitely something that has been an issue in open source for a long time and has been getting increasing

visibility

with a lot of people sort of quitting open source as a result of getting burned out from having too many people place demands on them.

For sure. It's a big, consideration. I consider myself very lucky to be in the position to be able to work on an open source project that I am really, invested in and I really, you know,

interested in and believe in. And I'm I'm very grateful that, you know, Continuum, I think we've managed to do a great job of aligning, you know, the incentives correctly such that we can develop, you know, really cutting edge open source tools, but also make them, you know, monetizable so we can keep the lights on. Right? You know, as sort of a going concern. Mhmm. But I'm definitely, you know, happy to be in that position and and grateful to be in that position, and, hopefully, we'll keep moving it forward. You know, you mentioned things like Vincent and Vega integration from, you know, Python. That's definitely,

a lot of people interested in that space. We're certainly not the only player in that space, and so there's a lot of activity. And it's really exciting to see what other people are doing. There's, you know, a bunch of different projects, and, so we're happy with to integrate with all kinds of things as well. So, you know, we we work on things like matplotlib integrations and, ggplot.py

and seaborne integrations as well, all sorts of things. So I think the more the more the merrier. It's my own my own personal thinking on all of that.

Leading off of your mention of the integration with those other plotting libraries, I can see how those would be useful for

visualizations on the web easily? And are there other use cases for those integrations? And also, does the Bokeh integration add interactivity to the plots, or does it just provide a way to publish,

PNG, for instance?

Yeah. Absolutely. So, I mean, Yeah. So the idea is that you take your Matplotlib code, and, you know, we all have a lot of Matplotlib code. I have a lot of Matplotlib code that we all have laying around, and we wanna be able to, like, now be able to put up a plot on on the web that maybe has interactive tools just out of the box. And so that's absolutely what you get, is a tool that has, you know, panning and zooming and selections, and you can, you know, treat it just like a bokeh plot once you sort of make a single function call on it. So to make it a bokeh plot, and now you can add more tools to it or more interactions as well or embedded in larger documents. And so I think there's a lot of use cases there. 1, again, is people have code. There's a lot of, existing code that makes use of it. I'll say it right now that our Matplotlib

compatibility is not complete yet. I'm really excited. The Matplotlib team is actually working on,

their own,

JSON serialization scheme, basically, for for sort of ingest and and serialization of matplotlib plots, and that'll allow a lot of different projects like Bokeh or MPLD 3 or plotly. All of us integrate better with matplotlib. And so that opens the doors again to things like ggplot.py

and Seaborn, Axie Pandas, of course, plotting. So there's just, NetworkX too as well. So there's just a lot of different doors that that opens, and so I'm interested in pushing that as far as, as far as we

can. Yeah. Definitely.

Because

data visualization or visualization in general is, as we've said, a growing space,

and it's not confined to the realm of data science where it is sort of gets the most visibility and discussion because there are, you know, any number of other areas where having a interactive chart can provide a lot of extra context to something that you're looking at. You know, 1 of the more popular areas is, for instance, gathering system metrics for monitoring purposes. And I know that there are a number of dash boards that use d 3 for that purpose. And

so having something like Bokeh where you can manage the visualization on the server side. Can see it making it easier to produce even more tools that have functionality that we haven't even dreamed of yet.

It's amazing what users,

think of. I mean, you know, I'm really familiar with, you know, sort of deep in the in the weeds most of the time and thinking about the code. And, you know, at heart, I'm a tinkerer. Right? I'm a toolmaker. I'm not actually data scientist myself, and,

and it's I'm not the question guy. Right? But everyone else out there has these amazing questions that they're trying to answer, and so, you know, I've never ceased to be amazed at that. I was at a Piedido conference, I think, in Berlin last year, and someone came up to me and and they had this idea for using Voci to create basically like a mechanical turk system. So you could hover you know, some user could hover over a system and and get an image in, like, a hover tooltip. But I hadn't thought about putting images in hover tooltips at all, but this is the sort of thing that, you know, when you start to get users, they have ideas and really great ideas, and it sort of pushes the project forward. They have bug requests too. Don't get me wrong. Sometimes I look at the GitHub tracker and I feel like I'm, you know, I'm just a disappointment factor, Amy. You know, the the list of issues goes up so fast. But, but, no, users have really tremendous ideas, so there's that. You know, I I I just recently did a sprint at another Pydata conference. It was Pydata Seattle, and,

an astronomer

postdoc came, and and he'd been working on this really cool galaxy data. And, again, he was doing cool stuff with hover tooltips, and he wanted to have all these interactions using the new sort of JS callbacks that we just added. And it's just exciting to see, you know, when people come with real real problems, real interesting problems, and and what they try to do, with Bokeh, things that I, you know, hadn't necessarily thought of at all.

You know, I just wanna quickly address, an earlier,

point that you made with regards to MAPlotlib

extending their interface to allow all these other tools to take better advantage of it. That's 1 thing that has really struck me. I won't be able to say this for much longer, but I still consider myself to be somewhat of a Python noob. And, you know, I've I've had a lot of years working with Ruby and some other open source communities,

and I realized there's some cross pollination and some sort of, you know, coordination work, you know, in pretty much all of them. But it really strikes me how

deep this goes in the Python community. It seems like the Python universe

is populated by

projects that seem intensely interested

in working with each other and leveraging each other's strengths and building bridges to each other wherever possible. And that just seems amazing to me.

I definitely think that's true. I mean, that I think that is sort of the core ethos of the Python sort community going back a long way. I mentioned, you know, I started using Python in the late nineties, and at the time that's when people like Dave Beasley were creating Swig, you know, the the the wrapper generator so you could call, you know, Fortran and c and c plus plus code from Python. Really wanna be able to sort of make Python this amazing blue language and extend its reach, into scientific computing by being able to do that. And then, you know, people like Jim Huguenen and Travis Oliphant come along and make, you know, NumPy

and start the beginning of sort of the, you know, the scientific stack in Python,

you know, with numarray and NumPy, and then, you know, Pandas comes along with McKinney, and then this just grows and builds steam. We have all of this huge interdependent scientific stack in Python, which is truly enormous. And just in the last few years, it's just exploded, and it's been really gratifying to see it. And, again, it's really great to see all of these projects work together. And so I, you know, I agree with that a 100%. I think it's a fantastic community, and it's good to see all the people, every year at, you know, SciPy and PyData conferences and at Pycom, and I can go and and, and see what people are up to.

Yeah. There's a definite lack of ego in the community at large where it definitely

leads to a much more welcoming

and collaborative

environment.

So you mentioned earlier that Bokeh has bindings for languages other than Python.

I know that r and Julia are some pretty obvious candidates due to their strong focus on analytics work. And I'm I'm curious what made Scala and Lua candidates for creating bindings above any other language that you might have targeted.

Well, so we didn't target those. Right? So that's that's sort of the beauty of those is that, you know, the architecture of Bokeh is such that, and it's just I would say this is somewhat novel. Other people sort of reached the same place, I think, around the same time that we did,

in the instead of sending scripts, you know, actual scripts to the to the client to to render a bar chart or a, you know, a pie chart or a, you know, whatever scatter plot, we actually create a, you know, sort of declarative

scene graph, right, an object model, of what we wanna render, and we ship that over as a pile of JSON to the client. And the client is almost like a compiler or an interpreter that takes this big pile of JSON,

reconstitutes this object model, and renders the scene with the tools and all of the the, you know, visual guides and and whatever you wanna see. But the the takeaway from that, of course, is that any language that can generate the right pile of JSON can drive Bokeh plots, you know, Bokeh JS plots in the client. Mhmm. And so, other people have come along. So, our Bokeh was created by Ryan Hafen, who's 1 of our ex data collaborators.

The Julia bindings were Samuel Colvin, you know, who's 1 of the main Julia guys. The Scala bindings was created by Continuum dev, but that's because he's a big Scala fan. Honestly, I think he's a bigger sk he's really into strong typing. I think he's a big Scala, bigger Scala fan maybe, secretly than Python even. But, you know, that was initially his initiative.

And, obviously, we realized that that's actually really cool, and there is use of Scala, for instance, finances. So we definitely now encourage the continued development of bokeh.scala particularly because a lot of our, you know, some some of our services work may intersect with that. But, you know, initially, we didn't we didn't think about that to push it explicitly. The Lua thing happened. Actually, Facebook released a series of IPython Notebooks or Jupyter Notebooks now for their Itorch machine learning libraries, and that's in Lua. And so they wrote a very primitive bokeh bind. They didn't even come to us to talk about it. They just sort of announced it on Twitter, and we took a look. We're like, woah, there's bokeh here. How did that happen? You know? And so that's that's actually really fantastic is that, you know, I wanna get to the point where bokeh becomes a platform where people can contribute to it without, you know, really needing to involve us. Right? And it can grow sort of in an organic way and and in whatever direction people wanna take it.

Is the correct pronunciation

bouquet, as in of flowers, or bokeh, or, like, how does 1 pronounce this appropriately?

I've heard a few different pronunciations, and I I don't think I think there's kind of a range that's acceptable. I say bokeh,

but I've heard, you know, bokeh and and bokeh and, you know, the only 1 that I heard that I know was wrong for sure was there was actually a there was someone just reading off sort of the names of the different projects that were involved. And at 1 point, they said, you know, and also this visualization

database broke. So that I know I know that's wrong. Apart from that, I think it's pretty, it's pretty, fair game and pretty, lenient on the pronunciations that are that'll work. Yeah. I do know that the name comes from a style of Japanese photography.

Yeah. So there's there's a really technical meaning having to do with sort of the the shape of the aperture, and you get these sort of hexagonal flares. And then and then there's sort of a more artistic meaning concerning,

in a sort of the the depth of field and pulling different things in and out of focus. And so that was sort of the idea we're trying to capture is that we wanted to create a tool that, you know, maybe you have a lot of data, and the best way to sort of view it is to try to pick what is actually important about that. And we wanted to give people tools to sort of pick out, you know, amongst maybe a larger set of data, what's the really important piece and and draw the focus to that.

Bringing this on a little further, you mentioned the ability to sort of change the focus

of the data as it's being rendered in the visualization. And I know that 1 of the things that Bokeh supports is downsampling of the data, and I'm just curious what the mechanism behind that might be if you can describe some of the, some of the underpinnings.

Yeah. Sure. There's a couple of different ways to get to that, actually. I mean, that's sort of 1 of the the nice things about Bokeh is there's a lot of flexibility.

I would say some of that's built in and some of that's an evolving sort of work in progress. So,

in general, you know,

1 way to interact with Vokeh is to create documents that have, like, age they call they call them Ajax data sources. They're basically date data sources that can pull data into the client directly. And so if, you know, you have a REST API that can provide you data at whatever resolution you sort of can ask for, you can use this h x data source to to get whatever downsampled data you want. So that could be an existing REST API that you have, or maybe you write a little server that does that kind of downsampling. I showed off a recent,

demo at,

SciPy, actually, sort of ocean, data. It was a 5 gig data cube, I think, and it was over the, you know, over the network. Even Wi Fi conference Wi Fi still work. It just hit this REST API with sort of, you know, the screen dimensions and the and the data dimensions, and then the the server did a downsampling that was appropriate for those dimensions and returned an image that was that was, that was shown. And so we could sort of zoom in and out and pan and and to get progressive refinement as we went.

And so that's sort of 1 way. There's other things that we do wanna support more

directly sort of, alongside bokeh. I will say, I think, originally, we had a conception that

some of these features should be part of Bokeh. We're we're sort of moving to

a a server architecture that's a little bit more simpler such that it's more of a platform and allows people to, again, develop a lot of things without necessarily having to involve us. And so some of those things would be like these interactive sort of intelligent downsampling,

ideas. But the main thing is that the server is a place where something interesting happens. So the the way Bokeh is architected is such that, if you push this model, this, this object graph to the server, it gets mirrored into the client. So we have these set of Python models in the server, they get mirrored into backbone models in the client, and there's a 2 way communication that's set up so that if you change something on the server, the the client updates. If you change something on the client, on the browser, the the server updates. And so that gives you a chance to have callbacks and do, you know, inform further computations or to do whatever you want, things like down sampling. It's a place where interesting things can happen, I guess, is

maybe the way of putting it. And so we have some interesting, ideas. We have some academic collaborators, Joseph Kottam and Jim Bednar, some people who've been working on these ideas that we call data shading. We just call them abstract abstract rendering. We're we're sort of calling them data shading now. If you're familiar with sort of HDR photography, sort of the idea of extending your dynamic range

by, you know, looking at the distribution of colors and of of sort of the data in front of you and changing maybe, like, an alpha overcompositing

based on that distribution in a smart way, that's the kind of thing we wanna do.

And so we're some of those things, I would say, are still very sort of early days, and we have some demonstrations of capability, but I think we'll have a lot more progress on those in in the next coming months and towards the end of this year. But the the the main idea is that, yeah, the server is just a place where any of these kind of interesting things can happen. You could actually imagine even further sort of interesting things. Like, you know, here with the the downsampling, you might imagine

because you can communicate things like just the the data balance, but also the, you know, the screen pixel density or screen resolution of the server, The server could decide at some point, hey. You know, the the data density and the pixel density are are commensurate. I'm actually not gonna do this downsampling where I'm just gonna show the real data. Or at least maybe it might decide to start showing things like outliers on top of the downsampled data in a in a sort of intelligent way. So it's again, it's just a place where additional decisions can be made in in hopefully an intelligent way, to update the plot and then aid the visualization of your data.

Yeah. I can definitely see how just that right there would provide a huge advantage over something like d 3 because of the fact that it's already built into the architecture of the project. Whereas in d 3, you would have

to create all of that extra framework around it to be able to get something approaching what Bokeh can do.

Well, Well, so don't get me wrong. D 3 is a fantastic tool. I mean, I think the best description I've heard of it as it's sort of artisanal tool. As you mentioned, if you want to make an amazing, just incredible visualization,

you can probably do certainly things that you can't do with Bokeh, or certainly not easily with Bokeh. But Bokeh, again, you're brought a lot of JavaScript to do that. And we're trying to reach people who may not be familiar with JavaScript, who may not be familiar with web deployments, who may not be familiar with, you know, all these JS libraries or,

CSS even. And so we wanna reach people to create a fairly high level of sophistication visualizations, but without necessarily having to write JavaScript.

And that's the that's the main target and the sweet spot that we're trying to find. So, you know, I think we sacrificed a little bit of flexibility for that, is a is a fair assessment, but,

hopefully

that, is a is a fair assessment, but,

hopefully, we gain, in in audience as well.

So this leads into another question that I had.

Do you lose any capabilities using the JavaScript library by itself without the Python bindings?

No. Quite the contrary. I mean, the the JavaScript library almost I would treat it as sort of a VM or a compiler. It's it's strictly the the superset of any binding that you could create. I mean, anything that you can do, you can only do because you can do it with Vokehjs. And so I will say that 1 thing, you know, that the Vokehjs library lacks right now is sort of a good, functional API. So, you know, if you if you, again, if you create the right pile of JSON,

Bokeh. Js will render everything and you'll you'll get a great plot. But now putting that JSON together is is kind of a pain to do by hand, and so that's, again, a large part of the the Python binding is to create higher level APIs that can create this serialized object graph for you in, you know, correct

ways.

But in on the JavaScript side, there's sort of a minimal API that can help do that, but I would love to get new contributors that are much more familiar. So I'm actually not a very experienced JavaScript dev. Forcing to have a few new people coming on that are more experienced, JavaScript devs.

I sort of stumbled through writing a lot of Vokeh JS on the on the strength of my my previous experience writing similar plotting libraries. And so for that reason, I think Vokeh JS is probably it looks a little bit different than a lot of JavaScript libraries, but I would love to get a real bona fide API for Bokeh. Js that JavaScript devs would use, sort of as a as a first class thing. And so, you know, it has things like, you know, really nice integrations with React or Angular,

you know, jQuery, all of these things. And so if anyone's interested in that, I definitely, you know, come contact us. I would love to to talk about what what a way forward on that would be because,

right now, you can certainly use Bokeh. Js, but it's a little bit hard to use Bokeh. Js. And taking that in the other direction, is there any utility in using the Python bindings with something other than the JavaScript library of Bokeh?

And as a corollary to that, do you think that it would make sense to even attempt to create any sort of standardized

data format for describing visualization,

you know, perhaps something based off of the grammar of graphics?

Yeah. Yeah. So those are great questions. So, I mean, there are, sort of,

you know, I think,

overtures in that directions are already. So, you know, 1 of the things is if, you know, whenever the the Matplotlib

sort of JSON serialization comes in, we'll have a means to convert the Python,

you know, Bokeh object model into sort of matplotlib format and get out matplotlib graphs. People have also asked us for static images, and this is 1 area where sort of Bokeh has actually had a difficult time. It's sort of a a thorny technical problem to get images out of the browser,

and that's just for PNGs. He really want SVGs, and so Canvas is raster based. And so that's even harder. And so 1 of the ideas we've batted around is to create actually basically just a second back end for Bokeh that might be some Cairo based back end or something like that that could,

just ingest a subset of, you know, the the Bokeh JS JSON format enough to to render static images as SVGs, and, and then it would be able to to do that. So definitely, I think there's utility in that.

In terms of having a a centralized grammar, that's definitely a very attractive idea. I mean,

the problem there is that it's a people problem. Right? I mean, that's a matter of getting coordination. Everyone's got their idea about what what is important to them, and different projects have different focuses. And so, you know, in principle, I guess, it's an amazing idea, in terms of actually making it happen. I think it's a very difficult prospect, but maybe someday we'll get there. We do certainly have some things like that. You know, there's the sort of the Vega standard is out there. And, actually, we're working to, hopefully have Bokeh integrate with Vega. PDA will be able to ingest Vega at some point. You know, then we can get some nice, you know, there's a really nice sort of cross filter tool called Polaris, which emits Vega. Right? And so we could use that. You know, if we get our our Vega sort of bindings or Vega ingests working, we can sort of have nice front ends. It's really nice slick JS, you know, cross filter front ends like Polaris drive, you know, Bokeh plots. And so that would be really cool as well. So I think there's a lot of opportunity there. You know, will there someday be a a JSON format to rule them all? Maybe. I don't know. I don't know.

I won't speculate.

Certainly.

It's funny, actually, that you you came around to a more native

rendering solution because 1 of the things that that I was kinda

musing about as I was thinking about tonight's

interview

was,

gee, I wonder if they've ever thought of hooking this up to something like Kivi, you know, and doing, like, a native rendering as opposed to a web rendering and getting some of that amazing real time visualization

goodness

in a platform that can sort of, you know, even perhaps

more in a in a even richer way than JavaScript and the web canvas can

render some really nifty visualizations.

Yeah. Absolutely. There there's definitely a possibility for doing that, and I and I may have to even look at Kavi. I I take an initial stab looking at the Cairo, and and Cairo was more difficult to build than I remember on OSX especially. And so,

I sort of put that effort down. But, I'll go make someone go make some, binary packages for me to install maybe and, make my life easier. But Mhmm. But, you know, it's it's interesting that you mentioned performance, though. I'll I'll say coming into to Bokeh, when I first started working, you know, about 2 years ago, in earnest on the the Bokeh project, you know, I had done previous experience on a c plus plus library. I worked on Chaco a long time ago with Peter Wang. It's sort of how we both got into this. And and but after that, I worked on a c plus plus library, at this research lab that I worked on, and I sort of built it with some of the ideas of Chaco in mind,

sort of making each sort of interactive tools a first class concern. And at the time, it used sort of Kyro as as a rendering back end. Then it was you know, I felt it was okay, but it was occasionally, you know, laggier,

not so performant. And so I came into Bokeh with this perception and this expectation that it was just, you know, this is never gonna work. Right? I mean, how is it possibly gonna be efficient enough? I mean, it's not even the c plus plus Cairo library, which is surely gonna be fast. Right? But,

you know, the the JS,

engines in all the modern browsers and the Canvas implementations are truly astounding, and I never cease to be amazed at, just what can be done, you know, on the regular HTML Canvas. And we're actually in the process of adding WebGL support as well. We some of that's gonna land in our 0 10 release in September. We have all our client, some VisPY.

VisPY has done some work to to work on WebGL for us. So now we can extend our range sort of even further. You know, if you really do wanna ship a 100 k points into a bouquet plot, you can do that, and that'll be great. But, it's it's just incredible to me that the that's possible in the browser. I mean, I guess 1 day we really are gonna have

sort of browser OSes, you know, and that's gonna be our our ultimate VM that everyone targets, and we're just gonna

compile everything to JavaScript. It's kind of a it's a crazy, heady, heady world that we live in these days. At Wood's Law, anything that can be written in JavaScript will eventually be written in JavaScript.

Right. Talking about WebGL support, it made me think. You know? So is the next step fly through book of visualizations,

you know?

Yeah. So, the initial stab of the WebGL is really about, well so the the first step is just to get any integration with WebGL and really just to to make our existing 2 d visualizations,

give them further reach into sort of larger datasets than you'd be able to do now. But, you know, basically, there are a couple of kinds of, like, 3 d plots that I think are interesting and useful and people have asked for. And so, know, I don't think that we're gonna retool the entire sort of pipeline or architecture of Bokeh to be able to handle sort of, you know, generic 3 d visualization. Like, we're not gonna write VTK, you know, in in JavaScript. I'm not gonna do that. But, you know, I think we might have some canned, like, sort of schematic 3 d plots. Well, you know, I got a 3 d scatterplot or 3 d surface plots or ribbon plots. And so I have, like, a limited selection of 3 d plots that you can sort of include in a in a bouquet visualization

in in a fairly prescribed way is is what I would imagine that leading to,

you know, later this year or early next year.

I think that's very smart, and it kinda it goes back to your previous point when you talked about losing some flexibility the way you had designed. I believe it was the Bokeh JavaScript side. I think there's a lot to be said for

making this simple case simple, and it's okay if you give up a little bit of flexibility for that because the people who want total control are probably building their own

visualization

rendering system on JavaScript anyway. And and so, you know, it's it's a good thing to make it make

make to allow the 90% of your users to get the job done quickly, efficiently, and and be really surprised by how easy it is. I think that's definitely there's a lot to be said for that.

Yeah. Definitely. No. I think that's mirrored in the approach we've taken. I mean, I I will say there are a lot of knobs and and switches and dials you can turn at the lowest level of bokeh, and you can really figure just a ton of things. But the lowest level at bokeh is really, again, these these objects. We call them models. You know, there's a model for, you know, plot and axes and grids and, you know, all the different tools and all the different glyphs can throw up on a plot. And so you can control all the visual aspects of that and attach those to data. You know, give them single values or or attach them to columns of data or however you want. There's a lot of flexibility, but, again, putting this object graph together by hand at that level is kind of a pain. And so we have a very layered approach to our API. We have sort of a bucket dot plotting API that gives you a basic single plot, you know, that you can throw glyphs at, very easily. And it has sort of standard set of tools you can add more or less, but, you know, it's it's very easy to get up and running. And then a higher level even, we're still working in it. This is maybe the newest and most work in progress level is bokeh dot charts where we have sort of statistical, you know, canned statistical charts, sort of schematic charts that are very common, that might involve some data transformation as well as part of the process. But, you know, it lets you get a lot done with very little code. And so we're trying to really

provide a range of options for people. So if you really need access those lower level bits, you can certainly get to them and and tweak whatever you want. But, you know, if you don't need that, then you have a a very high level, or higher level options to address those, you know, those kind of visualizations.

Other than the sample datasets that come with Bokeh, can you suggest a good publicly available dataset with accompanying tutorial

for people who wanna get started with data visualization using Bokeh?

Yeah. I I wish I had some really good suggestions. This goes back to what I mentioned before is I'm I'm really a tinker. I'm a a sort of a craftsman. I like making things, and and I'm not a data scientist. I mean, that it'll sound corny, but it even goes back to, like, you know, my elementary school days. I was petrified of science fair time of the year because I could never think of a question. Right? I I just I'm not a question person. So so I'm not that guy, but, you know, I certainly am aware of a few things. So 1 of the things that that, the data is not actually in Bokeh, but there is a tutorial that that gets the data and uses it. It's, it comes from Gapminder.

So Gapminder, first of all, is a really great source, I think, of some datasets with a lot of interesting data about world health and economics and population. But,

1 of our other contributors, the amazing Sarah Bird, who gave an incredible talk at PyCon on Bokeh, recreated,

Hans Rosling's, you know, sort of the first sort of, I don't know, famous TED Talk. You remember it was the sort of stats, you know, he showed, you know, population

growth versus,

you know, fertility rate. And so,

you know, she recreated this chart in Bokeh in just in an IPython notebook. Right? And it's just right there, and it's a static document. There's no server required or anything. And and so I thought that was really cool. So there is a tutorial that includes her work to show that, and that's up on the nb viewer bokeh. You know, if you go to nbviewer.org,

you can see there's a a a link to the bokeh

nbviewer page, and and, we have some tutorial,

notebooks there, and that's 1 of the tutorials. I think that's really good. And just in general, I would say that Gapminder is a great source of data as well. World Bank actually makes a lot of data available. You know, there's certainly a lot of sports fans. I you know, a lot of my Twitter feed seems to be people doing a lot of stats on, you know, baseball and,

and basketball. I'm not a big sports fan, so I don't know much about that. But I know a lot of those datasets are at least available, and you can sort of see what people have done. So I wish I had better things to suggest there, but, that's sort of things I can toss out, off the top of my head.

No. I think that's actually very good. So Gapminder, World Bank, and I'm sorry. There was a sports

Yeah. I don't have a good source for that. I just know those datasets are available. So,

I was okay. I will defer, defer to, to Google or or Alphabet or whatever they're called

now, to search for that. So I'm trying to think of other things too. I I guess Kaggle, you know, there's the the Kaggle competition. I'm sure they have some datasets associated with, you know, their competitions, and be interesting to see if someone, you know, tries to do some work or compete on Kaggle, maybe using a Bokeh plot as as part of the the project. So I mean, that'd be kinda cool. But, oh, I'm sorry. The 1,000,000 song dataset, that's kind of interesting too. It's kind of a different dataset, but I remember I using that in a previous sort of project, and I haven't looked at it since. But I it occurs to me that there must be a lot of interesting things you could you could, do by, you know, taking a look at the million million song dataset.

Very cool. Thank you. And there's also data.gov

for open government data. Of course. Yeah. Absolutely.

So can you provide some comparisons between d 3 JS and the Bokeh JavaScript library in terms of capabilities and performance?

Sure. I'll say what I know. So I actually have not done a lot of d 3 programming. I mean, it just hasn't again, I'm not I was not, at least before starting this, much of a JavaScript

programmer at all. I was, you know, familiar with the existence of d 3. So, you know, I think the standard usage of d 3 involves creating a bunch of DOM elements, you know, SVG DOM elements, and that's sort of how it typically works. Although there may be some,

ways to render d 3 under the canvas these days as well. But I think that's 1 of the distinctions is that, you know, Bokeh was written from the ground up, you know, to work on HTML 5 Canvas and now WebGL Canvas. And so I think that gives us the ability to reach into some, you know, and I won't say big datasets, but, you know, medium datasets. If you really wanna have tens of thousands of points and you have the pixels to spare to show those points, you can do that with bokeh and you can still maintain interactivity,

you know, things like hover tools or, you know, panning and zooming or selections on all of those points. And, so I think that's sort of 1 of the distinctions as well. You know, obviously

and we talk about integrating the Bokeh server. We're really trying to let people

create not just the the plot of the visualization, but really sort of a maybe a data application might have other other widgets that you can use to to, again, inform further computations. You know, maybe you select the drop down and you fire off something in a a Pyspark cluster or something, and then you come back and update your plot. But, there's all kinds of things we wanna enable. And so I think the architecture of the server is is getting to a place where it will enable those sorts of things

as well. And, actually, another thing that we're working on now is to make the the model system extensible. So right now, all the models are sort of baked in.

You know, people can't really extend Bokeh, very well, and we'd like to make it so that anyone can really create their own Python model with a corresponding JavaScript

implementation and then integrate that directly with any Bokeh plot. I think that that allows people to experiment and play around and do whatever they want through some amazing new JavaScript library, you know, of next you know, this week that someone wants to wrap and include in in a bouquet plot, they can do it really easily. And that's that's the place where we wanna get to, so we're not quite there yet. It may be a bit easier right now to sort of extend, and I know there's a lot of plug ins for d 3. So that may be an area where we're playing a little bit of catch up. But, so, you know, I I in terms of, like, performance, I I think,

definitely, you know, I certainly with the server, you get to the area being able to downsample data sort of much more easily, and I think you you extend the reach into sort of larger datasets very easily. And that's maybe the biggest difference I would draw between d 3 and Vokeh.

And what about browser compatibility?

Really good question. So this is a a hard thing to do. I was I was listening actually to the, podcast a bit earlier about, Pytest because we've just started sort of migrating to Pytest in a very ad hoc sort of slow, you know, piecemeal fashion from our unit test test. And, and I noticed at the beginning you mentioned another podcast about testing I may have to start listening to because,

especially with browsers. I mean, the the matrix just explodes. Right? I mean, you think about, well, I wanna you know, we wanna maintain compatibility with, you know, Python

27 and and at 1 point maybe even 26 or, you know, 33 and 34 and then 35 is coming out, and then we wanna test all these platforms. And each platform has 3 browsers and but not just 3 browsers, you know, 3 versions of each kind of browser. I mean, just you can imagine sort of your test matrix just exploding. And and so, you know, right now, we do continuous integration testing with, like, sort of Phantom JS, and we're looking at now integrating Selenium with actual sort of browser

you know, better browser testing in there. So I I can't give anything hard and fast on that. I mean, I I test typically on we test on Safari and Chrome and Firefox, Internet Explorer.

Off the top of my head, I couldn't give you sort of versions. Obviously, you're gonna need a fairly recent version of Internet Explorer

to run, but I've been using it on

Safari, for instance, for 2 years. So I would imagine if you have OS X from 2 years ago, it should probably work without too much problems. And,

you know, it's but it does become definitely a burden because occasionally there's a problem. It's like, oh, this is a problem on this 1 specific version of Chrome.

And then if you bump, you know, 1 more, you know, point version, it's not anymore. I'm like, well, I don't think we have we just don't have the resources to go back and fix, you know, something on every every point version of every browser, but it's, it's interesting to just to

see the the dimensions and the scale of that, you know, of that testing problem. And so if if there are folks that have a lot of experience doing, you know, again, testing for different browsers and different platforms and wanna contribute, by all means, come chat with us because we can use all the help we can get.

So you've, alluded to a server component a couple of times, and I was reading through the documentation and seeing that it allows for streaming data to clients. Can you describe the architecture of that and some example uses for it?

For sure. I'm gonna describe the coming architecture because we're actually taking the lessons that we've learned from the previous year and, and sort of retooling the server in the at present, and and I am hoping that's gonna again land in 0.10. It may be a little bit after that. But the main idea, sort of what I mentioned earlier, is that the the there's basically a mirror. There's a there's a sort of declarative object graph that describes the the whole visualization, the widgets, the tools, the the the plots, the the glyphs on the plots, all sorts of things, and those are that exists in Python on the server as a series of, you know, Python objects, this object graph, but there's also now a mirror of that as backbone models in the client. And they're linked such that if you, you know, if if 1 of them updates, it communicates back to the other. And so,

if you push data updates to the server, the plot updates, and you'll see the plot update. And so that's 1 way you can get streaming data. That AJAX data source I mentioned is another way. And so I I've shown off at a couple of different conferences a spectrogram example that uses that AJAX data source to get a, you know, like a a nice spectrogram,

rolling from from my microphone. And but in terms of the server, it's all about, you know, pushing data. So that's sort of a pull model, but the the server is more of a push model. If you push data up to the server, the plot will react. But the new architecture,

we're trying to pair down and make the server actually much simpler. And so, you know, that's probably the 1 area where the documentation has faulted a bit, and I think it it's really goes back to the fact that we weren't sure we had something we wanted to commit to. And and the fact that we're changing it now is probably indicative of that. But the the main thing the server needs to do is to be this reflective

sort of RPC mechanism, right, where if you have a model in 1 place, in 1 language, and it updates, then it'll update in the clients and and vice versa. And so we're gonna make it do that in a spectacular fashion. We're actually gonna move to a WebSocket,

wire protocol for everything that's gonna simplify

a lot of things for us. It's gonna be a little bit more like the IPython sort of server if you wanna think of or Jupyter server rather if you wanna think about it in those terms. But, you know, when you pair that with the idea of being able to extend the Bokeh model system, which is sort of some other ongoing work at the moment, then again, it becomes really very powerful and sort of a platform

people to do a lot of experimentation and not and then they don't have to be tied to our schedule or or tied to, you know, to to our work. They can they can integrate their own contributions directly

in a very natural way. And so that's where we wanna get to, and I'm I think we're a few months away from that. But, definitely, in terms of applications for that, I mean, you could imagine, you know, we live in a world where there's lots of sensors everywhere,

and so there's there's sort of streaming data from all directions, you know, whether that's sort of social media and sentiment channels, whether that's, you know, physical sensors and satellites and and climate sensing or or any kind of, you know, data that's just coming in in a stream. This would allow, you know, visualization of that data in a very sort of a easy way. So that's where we're going. Again, the the new servers you know, I I say 1 of the things is, I think, initially, we we sort of confused some of the things we wanted to be able to do by virtue of having a server with the server. Right? So we sort of tried to build in some of this abstract rendering and downsampling into the server and some of these other capabilities. And instead, if we make the server more of this platform, we can build those things on top and that other people can build things on top too. And I think that's a much better place to be in. So I'm excited I'm excited we have a much more sort of coherent and clearer vision of where to head to, and we just we have to get there. We're we're a little ways away.

And I noticed that the server is written as a Flask blueprint,

And I'm curious what drove that decision as opposed to making it a component of another framework such as Django or Pyramid and how difficult it would be to port that that

question

that question very, very short order. I've I've started down that road. The reason is actually just boils down to, at least to continue, and we have a lot of institutional knowledge around Flask, and that was sort of first natural thing to, to reach to. Definitely, Django is certainly a great,

platform for web apps, and and certainly Pyramid seems pretty interesting too from the little experience that I have with it. But the the new server is actually gonna be a pure Tornado app. Again, I mentioned we're gonna go to a, you know, WebSocket wire protocol, and so we want, the asynchronous capability. And actually, Tornado just seemed like it's easier to deploy. If we have sessions attached to WebSockets, we don't have to you know, we can have local in memory caches that don't have to sort of communicate between different instances of the server that might be running, and so we can just run more of them. And it's, you know, was attached to some Redis back end, and it's a much more simpler sort of diagram when you start drawing out the components than what we had. And so that's just there's not gonna be any more Flask. It's just gonna be a tornado, app again, very much like the Jupyter or IPython,

server.

So what's the most interesting use of Voca you've seen?

Also, really great question. So, as I mentioned, you know, 1 of the challenges with an open source project is that, you know, people come to you when there's problems, which is great, or when there's features that they, you know, aren't that aren't there yet that they want. And so we see a lot of that. And and when things are working, you know, they don't necessarily come and and knock on your door and tell you about it. They just they just use it. And so it's it's definitely been my experience that at conferences now,

quite a few times that where people have been like, oh, yeah. Of course, I use Boca. I do this really, you know, cool thing. And I'm like, oh, that's awesome. I'd love to know what it is, or can you show it to me? Like, no. I can't show it to you. You know? It's it's our corporate network. I I can't show it to you. It's sort of this proprietary thing. And and so I I haven't gotten to see as much of that as I'd want to. I actually really am interested in building up, like, a a user, you know, user success stories or, you know,

you know, user gallery of of things that people have built. But that said, things do come across our attention from time to time on Twitter,

you know, or talking to people at conferences we've seen. So certainly there was someone recently on Twitter who I think was analyzing phylogenetic data, and they made this really interesting sort of radial visualization with, again, a hover tool that could drill down into, the different details depending on where you are hovering around this sort of phylogenetic, tree. Recently, I mentioned the the sprint that I did at, PyData Seattle. This This astronomer, I mean, again, was doing really cool things, with, you know, the I think it was, like, 4 or 5000

galaxy data points, and was a sort of very dense visualization, but he was doing some interesting smoothing over it, but then you could drill down again. And as you hovered over, you got the sidebar with all kinds of interesting detail about things. More interestingly, I've I've heard of people again putting actual images in the hover tool. I hadn't even thought about that, but, of course, it it seems perfectly reasonable thing to do once someone says, hey. I've done this. I've hovered over a data point, and I fetched some image from my database, and I'm actually displaying, like, a microscopy it was like it was a microscopy image associated with whatever data point they were hovering over. So, again, I'm always amazed by all the cool things that users come up with to do, and I would love to hear more of those things. So if people are working on things and it's something they can share publicly, please, by all means, you know, tweet at us or come to the mailing list. And, we just opened up a new Bokeh dash demos repo on GitHub under the Bokeh Organization. I'd love to start adding, you know, if anyone wants to contribute anything there, we'll we'll take just about anything to put in there to show off Bokeh. And, really, again, I'd love to have sort of a a success stories or, you know, case studies kind of a a site that we can stand up in the next few months or 6 months, that really shows, you know, real world sort of usage of Bokeh. And so but that some of the ones that come off come at the top of my head are the ones, I guess, that I said that I mentioned. We we see a lot of interesting folks from academia,

using Bokeh, but, certainly a lot of data scientists as well.

And are you aware of any projects in other languages that are comparable to Bokeh?

Yeah. There's there's a ton of interest in this space. You know, there's no shortage of of all kinds of projects, really, you could rattle off. I mean, there's certainly other projects in Python to begin with. I mean, there's, you know, there's, where's my plot my plotlib and all the tools that are, you know, based around that. There's,

was was it was Pix Pixley, I think, was just announced. Another project for sort of Python based sort of dashboards and interactive tools. Of course, Plotly is another,

you know, commercial endeavor, and they're sort of similar to Vokeh, and they have multiple language bindings. And they have, they actually got to a MATLAB binding. I always joke that I was gonna make a MATLAB binding for Voci because I used to do MATLAB programming in a in a former lifetime. But they got to that, first for for Plotly. And then, you know, but that's in sort of the Python space, you know, but there's lots of other things as well. Obviously, in the r world, there's ggplot and and, you know, upcoming ggviz and, of course, d 3 and JavaScript, and there's other JavaScript libraries for things like GIS, like, you know, I think Leaflet dotjs is a really great library. And, you know, if you need to do tiling, there's open layers. We're gonna try to do an open layers integration into into Bokeh as well. You know, there's a lot of different specialties and subdomains. Thinking, broader,

you know, I actually used to use Mathematica a lot. I always thought Mathematica's sort of plotting and biz capabilities were pretty pretty interesting and compelling, you know, even back when I was doing it a lot. And I don't do it so much anymore, but I've I've seen it lately. And I'm like, yeah. It's pretty impressive. They've got a really nice system for sort of interactive,

you know, being able to attach sort of widgets to data and and plot elements to data. And and, you know, they've got some impressive stuff going on as well. So there's a lot of interest, and, of course, MATLAB

is is certainly still in in heavy use itself. So, there's just a ton of tools. I think they're actually getting into the game of of doing some web enabled plots for MATLABify. I think I remember reading something about that recently. So,

a lot of interest in this space. I think a lot of people realize that, you know, it's, again, 2015, and and really publishing things means putting them into the clients and the browser and

and, making them accessible and and easily sort of viewable and and,

easy people to play around with. And so I we're not the only people to realize that, I guess, is what I would say. But, you know, those are some other projects that come to mind, and I'm sure I've forgotten quite a few as well. C plus plus. Right? I mean, there's people still use Root. You know, if you go to the physics community, I was

I went to grad school for physics, and and, so, you know, I saw people using Root for for plotting all the time, and, you know, it's kind of obscure. But on the other hand, there are all these things that exist in these niches. You know, I mentioned astronomers earlier. Astronomers still use IDL quite extensively for data analysis and visualization. I think there's sort of a younger vanguard of astronomers coming up that are trying to to carry the flag of Python, and I'm happy to see that. But, yeah, there's all these different domains, and so it really depends on what you're trying to do. But,

anyway, that's a quick summary from from my memory.

So before we move to the picks, are there any questions that we didn't ask that you think we should have or anything that you wanted to bring up? Oh, that's a that's a great question. I wish I had seen that 1 coming.

No. Not off the top of my head. I mean, I'm just I'm really excited, because I had to be a a part of this, this team, and I'm really grateful that, you know, Continuum

has the ability to support this effort. But, Bokeh is, you know, an open source project, and we have gotten contributors from outside, and we're always looking for more. So if you're interested in data visualization, if you're interested,

in helping out with Bokeh or rbokeh or or Bokeh.scala

or any of these these projects or the JavaScript, you know, bindings.

You know, it's a big project with a basically semi unbounded to do list, and so we would we'll take help anywhere we can get. So, you know, definitely, I would appeal to anyone who's has interest in helping us show off Bouquet to to come, you know, show us what you're doing or or even just come pitch in with actual development, that'd be great as well too. So Well, with that, we'll move to the picks. So for my first pick, I'm going to choose The Graveyard Book by Neil Gaiman.

It's a young adult novel about

a young boy who gets raised in a graveyard by all of its inhabitants.

And it's a quick read. It's a fun read. So I definitely recommend checking that out, particularly if you have

kids who are in the 8 to 14 range. I think they would really get a kick out of it, and even any adult.

My next pick is

a Chrome plugin called Wappilyzer,

and what it is is it just

will show an icon in the URL bar whenever you visit a page that will, if you click on it, it will give you a drop down of all the different

tech stack that it detects as it's loading the page. So it's an interesting way of seeing

what different sites are using under the covers

and maybe learning about a couple new libraries that you haven't heard of before.

And for my last pick, I'm going to choose

a project called Magirina.

It's a

Magic the Gathering

open source

1 player game where you can play Magic against an AI, and it has all the cards from inception

from its creation all the way up to

modern day. And it's just a fun way to

you know, play around with that without necessarily having to go out and spend a fortune on the cards. And I'll leave it at that for this time around. So, Chris, what have you got? So my first pick is an article that just went by my feed today, actually.

I guess, this year, just not too long ago, there was a meeting of the IETF

in Portugal

where they screened the Edward Snowden movie, Citizen 4.

And after that, you know, that movie, they actually managed to get Edward Snowden on the line on Skype for an hour so they could do a question and answer period.

So,

essentially, you had all the people who drive all the tech working groups that, you know, basically make the Internet go

having an opportunity to grill Edward Snowden on his thoughts on, you know, the security of the Internet and how protocol should evolve. It's really, really a fascinating read.

Definitely,

whatever you may say about him, he's he you cannot say that he is not a thoughtful person. It's definitely worth taking a look at. My next pick is a lot less obscure. This book has gotten a lot of press lately, but I don't care. I'm gonna pick it anyway because it's absolutely phenomenal. It's called Between the World and Me,

and I should have the full name of the author. I believe it's Tenille Coats.

It's it is a,

basically, a letter,

written by this man to his 15 year old son

trying to

help

him better make his way through the world as a person growing up black in America.

And I

I read this book on the recommendation of a relative whose opinion I respect,

and I kinda was half expecting to see a kind of a diatribe on racial justice or injustice in America,

and that's not what I saw at all. It is a

beautifully written,

compassionate,

relatively subjective

analysis

of

some of the

really sort of like aspects of our society that we, you know, especially those of us who are white, you know, middle class,

happy Americans

would much rather brush under the rug and and forget and never have to see. It's it's well worth a read, you know, and it's it's more than you think it will be. I will just say that. You will get more out of it than you think you might based on my description. So definitely check it out. And my last pick is a service with accompanying smartphone app that many people have heard of,

but I still think it's worth giving them a,

some some kudos.

Untapped,

untappapastrophe

d.

And so basically, this thing, it their their tagline is drink socially, but it actually ties into this episode in the sense that

so, you know, you're you're out somewhere and you get a beer that you like and you can check it in with this app,

and that's great. And so, you know, there's all the usual things like you can broadcast it to social media and the like and, you know, earn badges for

unlocking different combinations of things. But what's really great is now they've added an option that for, like, $20 a year or something like that,

you can become a supporting member, which gives you the opportunity to export all of your data in a number of different formats.

And so what has been really cool about this for me is

I essentially have an effortless catalog

of all the beers that I've liked and disliked

over the course of the year.

You can export it in XML or JSON or and there's a couple of other for Excel, I think.

And so I've just kind of been playing with that. I have not succeeded yet in in generating

a readable bokeh graph with with that data, but it's definitely I can definitely see a blog post in my future,

playing with that kind of stuff. It's just a it's a it's a actually, a really great well designed service that actually provides a lot of utility more than just, you know, sort of doing the usual

pointless social media stuff.

So that's it for me. Brian, what do you have for us? Yeah. Sure. Plus, that's awesome. I look forward to the tweet at bokuplast to see the, the wonderful visualization of that.

But, so for my first,

pick, I am gonna stick with the sort of an abstract concept, of audiobooks. So I just recently had a friend introduce me to audiobooks. I've been meaning to try to get more reading and more fiction into my life, and I never knew where to start because there's just an ocean of it and and what do you start with. And so she's giving me a lot of great recommendations, and and audiobooks are a great way to consume things. So I've really enjoyed that, and there's a lot of different services I'm sure you can use to to get those. And they've just been a real, addition to, to my life that I've enjoyed. But switching gears, I would recommend now, also something that's a little bit more concrete and also of the dead tree variety perhaps.

A really nice book, that I just got,

sort of pointed in my direction, recently, which is called cartographies of time, history of the timeline. And so I'm interested in general about, you know, books about visualization

and, you know, Playfair and and Bertan and and the grammar of graphics, by by Wilkinson. But this is a book really all about sort of time, you know, time series data and what's how has that been presented sort of, you know, from its earliest inceptions and,

up through, through, you know, sort of modern ideas of of presenting time series data. And so it's really beautifully visually illustrated, and so definitely recommend that to

to anyone. And then the last pick is,

musical group. I recently had the the the force in someone, got me tickets to go see. It was, the postmodern jukebox. So this is sort of rotating group of musicians out of New York and and Brooklyn, and they do, sort of genre bending covers of, modern pop songs, but in all kinds of old genres. And the the concert was,

Pure Joy. It was a really great concert, but they have a lot of videos on YouTube. You can catch all their stuff,

and so I definitely would recommend anyone to check that out as well. Very cool. Cartographies of Time definitely sounds like a good sort of, like,

definitely buy it in paper even even for those of us who are addicted to the ebook format kinda thing.

Well, that's great. We really appreciate you taking the time to join us and tell us all about Bokeh and all the various things that are being done around it. So for anybody who wants to keep in touch with you and follow what you're up to and what Continuum is doing with Bokeh, what would be the best way for them to do that?

Yeah. Great. No. So first, thank you guys for having me. I I love to to sort of talk about and and tell people about Bouquet. It's, you know, I think it's, it's really cool, and and so I love telling people about it and talking about it and hope they think it's cool too. But, you know, we have a mailing list,

Google Groups. It's recently been mirrored,

on the oh, that other news aggregator. I can't remember.

But, yeah, Google group mailing list is a great way for technical questions. All of this information is on on boke.pydata.org,

by the way, is the main, documentation,

and and site for bokeh. So you can get to the Bokeh GitHub. You can get to the Bokeh mailing list.

Our Twitter is at Bokehplots,

b o k e h p l o t s.

It's another great way to sort of get a hold of us, and, of course, we try to monitor Stack Overflow and things like that for questions. But all those other places are really good places to to sort of, know, come holler at us and and come get engaged in a conversation.

Well, I'm sure our audience is going to enjoy listening to this. There's a lot of really good information, and, again, we appreciate you taking the time to join us. Great. Thank you, guys. Thank you, and good night.

The Python Podcast.init

Summary

Brief Introduction

Interview with Bryan Van de Ven

Picks

Keep In Touch

Links

The Python Podcast.__init__