So we are coming to the next session. Our next speaker is Joel Christiansen. Hi Joel. So where are you streaming from? I am streaming from the Optiverer office in Amsterdam. Okay. Nice. You will talk about dependencies, so packaging in Python. Yeah. I'm talking about dependencies and build tools and kind of an open source ideology. Okay. Great. So let's start. Yeah. Hello everyone. Yeah. Huge thanks to the organizers of EuroPython for making this happen. I've had a great time the last few days. I've already seen a bunch of awesome talks and I'm really looking forward to more. So thank you for joining me today. My name is Joel Christiansen. I'm an application engineer at Optiverer. Optiverer is a trading firm and we use Python just about everywhere, from monitoring to data analysis to operational tooling to risk controls.  And as a consequence of that, we care a lot about Python packaging. Before we jump in, you should join us in the sponsor Optiverer channel in Matrix. I'll be hanging out there after the talk and I'd love to answer any questions you might have or just a chat about Python, build tooling, type systems or anything else. So today we'll be talking about a wide variety of topics around build tooling. The idea that spawned the conversation for me was this idea of transitive dependencies and how to deal with them. Transitive dependencies are dependencies of dependencies. So for example, if you have a direct requirement on requests, then you will have a transitive dependency on URL lib3. This is just a small aspect of the larger build tooling discussion I want to have, but it's a good focal point and it's a good jumping off point. We'll talk more about these in a bit, but just for a second I'd like to talk to you about a really nice tool which is called SHIV. This is a bit off topic. I won't be talking about SHIV after this point, but I did want to give a shout out for something we use quite extensively and absolutely love. SHIV is an awesome tool developed by LinkedIn for creating single file executable binaries for Python applications. The idea is you give it something that can be pip installed, so that can be a wheel, that can be a source directory, or a source distribution, a local directory, anything like that plus a entry point that will be called. It then produces a Python zip app that calls some bootstrapping code and extracts not only your application, but all of the dependencies that were bundled with it. Then it executes the entry point you gave it in that virtual and it just extracted. Awesome tool makes deploying Python applications a joy. SHIV is actually a really good example of a lot of the principles that I'll be talking about in a second. It exists on a bit of a different level of abstraction than what I'm going to be focusing on, but it's a really great tool and I highly recommend it. There's a huge range of build tooling in Python at all different levels and I think that's really, really cool. So that out of the way, let's talk for a second about what we care about in a build tool. There are a lot of different aspects to consider when it comes to building and this list is not comprehensive and reasonable people can disagree on the ordering. This is part of my list of things that are important to me. So what do we care about first? Reproducibility. If you build an application and you make no changes and a year later you build the exact same package with the same commands, I would expect the output of those commands to be identical to the first time or failing that for the build to fail. This is to me the most important aspect because it's the one that can potentially impact production. If you get this one wrong, then there's no point in worrying about anything else. Compatibility. We want people to actually use the tools we make. This means that those tools have to be able to integrate with the outside world. In a few minutes I'll talk about a number of PEPs that relate to build processes and this is the reason why. How good a tool is doesn't really matter if nobody wants to use it. Flexibility. Both in Optiver and in the wider Python ecosystem we have applications that are built in a lot of different ways. Some repositories output SHIV applications, some are libraries, some have C++ or C or Rust or other compiled bindings, some have data files, et cetera. So long as a repo is standards compliant and has the requisite configurations, a given tool should be able to build it. Ease of use. This is kind of in the same world as compatibility which is the idea that if people don't want to use our tooling it doesn't really matter how technically good it is. This depends on a lot of factors, kind of fuzzy factors and specific ones and it depends also a lot on the domain the tool is in and who the target audience is and it's difficult to narrow this one down. And then the last thing that I wanna consider today is modularity and the idea of this is basically does this tool fit into other workflows as a part of a cohesive whole. So for example, if I switch my IDE from VIM to PyCharm or VS Code, will this application still work? So given these goals, how do we achieve them? For reproducibility, we need a very specific concept and this is the concept of a lock file. Most languages have some implementation of this idea typically tied to the common build tool of that language. In Python we are blessed for choice in this area with more than enough tools that implement the idea of a lock file. Compatibility is a broader but just as explicit area. The how here can be easily summed up as be standards compliant. Compatibility is after all one of the major goals of standardization. What standards are applicable to a given process or application is a more difficult question and that depends heavily on the specific area you're working on. Again, I'll cover a few relevant peps in just a moment that are part of what make a standard build process in Python. For flexibility we need to be capable of converting most current projects without any significant changes. Luckily this is mostly pretty easy at a high level though more complex builds get increasingly hard to convert. Wheels at least standardize this by solving the distribution problem. So all you need to do is output a wheel and then everything else is handled. Ease of use, keep it simple. We evaluated a few different external tools to try and achieve the results that we needed. And in my opinion this is the most difficult bit to get right. There aren't really any peps to help here. There aren't a ton of standards to tell you when simplicity has been achieved. There's not even an objective way to decide if something is more or less the same as something else in terms of complexity. And ease of use doesn't necessarily have a one to one relationship with complexity anyway, although they are correlated. So it's important to get other people who are not writing your tool to try it and experiment and beta test it and make sure that they can use it too. And then the last point is modularity. Again, keep your tools small and single purpose. This is essentially kind of the bash philosophy of do one thing and do it well. And that lets you chain and combine a series of single purpose tools to achieve very complex and variable goals. We're not necessarily working with pipes and standard out standard in here, but the same ideas are generally applicable. The last thing I wanna talk about before I start talking about practical things is the possible outcomes to a build process. This is a little bit out of the way, but hang with me. There are generally speaking three possible outcomes to a build. Actually four, this is a table of two variables with two values each. But the last of these, the case where the build fails but the output works, we don't really care about because it's annoying but harmless from a production standpoint. The first and second outcomes are the ones where the build results and the output health match. So that means either the build fails and the output also fails or the build passes and the output works. Either of these are totally fine from the perspective of the build itself. The third outcome is the one that is really a problem and that outcome is that the build itself passes but the output product is defective in some way. And there are a lot of ways this can be divided up but they all point to the build itself being incorrect in some way. Just a few examples of how this can look. Maybe the build is misconfigured and fails to run the test for the project. So the build passes even though the tests do not. Maybe the requirements are missing something. So the output doesn't have or doesn't specify all the dependencies it actually needs. Maybe you have a manifest.in that is accidentally excluding some mandatory data files that are present when testing but not when distributed as a wheel. The point is that a build passing is good. A build failing is good. A build passing while outputting a bad distributable is a problem. And the reason I bring this up is to kind of underscore the value of simplicity and ease of use. The problem tends to come from people misunderstanding how a build works. Maybe they have the wrong intuition for how talks test ends relate to the envelope so their pie build job is not getting run. Maybe they're missing some flag on some tool. Ideally the most correct way to call something is also the easiest. And I put a lot of emphasis on the idea that for a given project I should be able to just run pie test with no arguments, no parameters and just have it automatically run with all the right flags and against the right path to run all my tests and pass. And that can be done through a config file. And then that configuration gets put in the pieproject.toml or the pie test.ini or equivalent and committed as part of the project. Basically the easier a tool is to use correctly the less likely it is to be used incorrectly. So with all that said let's take a look at some of the new building blocks available to us to make a composable tool. These are PEPs 517, 518 and 621. So kind of the key insight here is that when you are building a Python package or an application sometimes the build itself has external dependencies. The prototypical example of this is set up tools itself. The way this is currently handled is that when you create a new virtual environment set up tools and wheel are automatically installed into that new environment for you. And this works for things that only depend on set up tools and wheel but leaves everything else out in the cold. If you wanna build something with a lock file you can do that because setup.py is just a Python script but it's not very nice to have to do that by hand in every project. So we have three parts of the solution here. The last part which is PEP 621 is the quickest to explain. PEP 621 defines a standard set of metadata keys in the pyproject.toml and that's it. That's the project section that you see in the picture here. The other two allow us to move away from set up tools if you want set up tools is also compatible with these. PEP 517 allows us to define some import path along with some hook that PIP can call to build a source distribution or a wheel. This allows us to swap out set up tools for for example, poetry or flit. That's the build back end line in the picture. PEP 518 then allows us to define some set of third party libraries that PIP will install into an isolated environment and use to build the package. And this neatly solves the chicken and egg problem of how do you define the dependencies required to build a package without also needing to import those dependencies at the same time. And that's the requires line in the picture. So these three together give us a powerful combination. We now have the ability to have build time dependencies on any library, have the build call any code that's compliant with the PEP. And we have a way to specify metadata in a way that is in theory acceptable to any build tool. Now in practice PEP 621 was finalized in November and very little supports it yet, but that will almost certainly change over time. And with these with these in mind, I wanna give some examples of kind of the values that I was talking about and how they interact with the PEPs I just described. I wanted to give some varied examples. So if I mentioned a library for one thing, I don't mean to imply that that library is bad at the rest or anything. If I don't mention your favorite library, it similarly does not mean that I'm implying that that's bad. I'll also not be looking into any of these tools in anywhere near the level of depth they deserve. Yeah, so disclaimer is given, let's take a look at FLIT. And the one other thing I wanna say is, unless I explicitly say otherwise, these are all compatible with PEPs 517 and 518, and none of them are compatible with 621 yet. So FLIT is a pretty small build tool, especially compared to, for example, poetry or PIPMF. It specializes in publishing artifacts to PIPI and not a ton else. And in my estimation, that's a good thing. It keeps the CLI small and the complexity low. FLIT has a really good command line interface, in my opinion. All of the commands are simple and there are only four commands in total. If you just look at the slide, you can already get a pretty good idea of everything FLIT does and how to make it do those things. Keeping such a tool simple is a difficult task in and of itself. And I'm sure quite some work has gone into making and keeping this tool as simple as it can be. Kind of the other side of having a small interface is that it does have less functionality. As I've said, my personal taste in build tools leads me in that direction. So I don't see that as a downside, but it is there. But for example, FLIT does not handle lock files. I don't, again, I can't emphasize this enough. I don't see this as a bad thing. Different tools excel in different situations and that is as true for build tools as it is, for example, in woodworking. You don't use the screwdriver to cut a piece of wood in half. The next one I want to look at is poetry. Poetry is kind of the other side of that coin. Poetry is a tool that aims to take care of the whole stack of dependency and packaging management, including development and publishing. And it does this quite well. Personally, I like tools that I can mix and match and put together and take apart at will.  And you can do that with poetry too, but it's a little bit clunky. But one aspect of poetry is absolutely to my taste and that's the lock file. Like I said earlier, the key to reproducibility in an application is generally tied to a lock file. Poetry translates a set of top-level dependencies in the pyproject.toml into a lock file that specifies not only the exact version, but also the expected pypy repository and the requisite Python version and all that kind of metadata you expect to specify the exact version of a library. I wanted to put a picture of the lock file in the picture here. Unfortunately, there's only so much vertical space available and the lock files tend to grow extremely quickly. So we get the pyproject.toml here as well. PipTools is a bit of an odd case actually in that it exists kind of next to the other tools that I'm talking about. PipTools does not create build artifacts like wheels or source distributions. What it does is just the locking bits. So if you give it a requirements.in file, which is kind of the high-level dependencies, it will compile for you a requirements.text file which has the very specific locked dependencies. And the upside of this is that a repo that uses PipTools does not need to change any other aspect of itself. It can use whatever metadata format, whatever other build tools whatever process the author or maintainers are comfortable with and it just slots into that locking role naturally. The downside is that it is a bit of a leak. It is less of a cohesive whole than say poetry. But if that's a downside at all or an upside will vary from person to person. Like I've said a few times, I do prefer smaller tools but I think there's a bit of a sweet spot between PipTools and poetry that can kind of fit my purposes. This is the only tool I'll mention that does not support PEP 517. Though I think that's planned for the future. The last, the second to last tool I want to mention is SetupTools. SetupTools gets special mention as kind of the basis of Python packaging. Obviously the true holder of that title is DisuTills but SetupTools takes DisuTills and makes it nice to use for just normal people. So yeah, yay SetupTools. Setup.py as I mentioned before is just a Python script. This has some surface level implications which I mentioned earlier which is that you can basically do whatever you want with the Setup.py and have that be a part of the build. This does have more extensive implications. A lot of other build tools use SetupTools as well. It does have some downsides which is that you can do anything as part of the build and that's potentially a very large security issue because if you're distributing source distributions then the install procedure involves running a arbitrary Python script as whoever's installing the package. And this is kind of, this is addressed with wheels which can also be built with SetupTools. So I'm by no means saying to abandon SetupTools or anything but just stop distributing source distributions, move to wheels. And all of these features, each tool has lessons that we can take and learn from but no tool quite made us happy. So we decided to create our own. We looked at this plethora of options and took inspiration from what we consider to be the best aspects of each of them. And we also took advantage of some of the newer standards and features and we came up with Vulkan. I've tried to broadly characterize the goals of the other tools I've looked at so far and I'll do the same here. The intention of Vulkan is to make doing the right thing the easiest thing. You should never need some obscure combination of flags or commands to get the output you want and it should be difficult to do the wrong thing. That's the goal. We've just finished open sourcing this so you can use it too if you like. It's designed to be small and simple. It only has a handful of commands with a max one or two options each. It allows everything you can want to configure to be configured in the pyproject.toml. It allows you to build wheels with dependencies either from the lock file or not as you desire and it's dead easy to use. Vulkan can do basically three things. It can generate a lock file, it can build wheels and it can do editable installs for pyproject.toml projects. Because it's PEP 517 compatible, Vulkan works with PIP install on a directory Python build or any other build front-end tool. Because it's PEP 621 compatible, it's quite future resistant. I won't say future proof to avoid tempting fate, but I doubt PEP 621 will be overthrown in the near future. A Vulkan project should just slot into whatever other stack of development and deployment tooling you prefer. And because it outputs wheels and artifact created by Vulkan, whether that's Vulkan build, Poetry-M build, PIP wheel or any other command is fully compatible with the rest of the modern Python world in a completely transparent way. And if it doesn't do everything you want it to, it does support also a very basic plugin mechanism for build time plugins if you want to, for example, generate some build info. In theory, you could even use that to do things like compile C++ extensions if you want, though I've not tried that. I do hope you'll go and take a look after this talk and maybe install it and play around with it a bit. It comes with conversion script to make that easy too. If you take anything away from this talk, I do wanna emphasize that making this kind of tool is something you can do. I want people to try out Vulkan and I hope you all take a look, but if it's not for you, if it doesn't do what you want, you can make one yourself that does. That's the freedom that having these standard building blocks can offer. I can imagine a future where there's a build tool that specializes in building projects with compiled C++ extensions, for example. So for my taste in build tools and for somebody that shares that preference, Vulkan will be a good tool. For others, I hope that this can still provide you some inspiration to make your own tool that makes you happy. So yeah, go forth, make new tools. I say this in a slightly self-serving position in that I want to experiment with all the cool stuff y'all will create. Find a niche, fill it and make your tooling available for everyone else to experiment with. And remember to be standards compliant so that everyone else can use it too. So that being said, I'm open for questions or comments. I'll hang around a bit in the sponsor Optiva Room and Matrix as well, if anyone wants to chat. Thanks, everyone. Nope, nope. We do have many, many questions. Let me choose some, why the first question are actually three questions. It starts with your firm probably needs to support a wide range of applications that require different pricing dependencies. But yes, no question, I guess. Yes. And then the first part of the question is, do you let your users choose versions of key packages, pandas, tasks, or do you mandate them, they use firm approved versions only? It depends on where in the stack we're deploying this. So for example, for data analysis tools, we pretty much let people use whatever they prefer. So pandas, definitely, I've not heard of desk, but we might use it. If a application is in a bit of a more key position, if it's a bit further inside our infrastructure, then we do keep a close eye on what people are using and what versions they use. So it depends. Okay, next part of the question, how often do you upgrade package versions with the new multiple environments and why? I'm not sure, I understand the question. We tend to upgrade stuff when we want new features or if there's a security release, we upgrade things as we come to them. Okay, and how do you manage multiple pricing environments? So like I said, we use SHIV to kind of isolate these different Python applications and their dependencies. If we're talking about Python versions, then we try not to. We try to keep the number of Python versions that we have going at once, as small as possible. So one or two if we're migrating. But we try to stay consistent there. Okay, and the next question is, given that log files are luxury, not everyone has, for many reasons, does anyone have any recipe for making sure the minimum versions are correct? And then it continues with run unit tests with the minimum versions rather than latest compatible and then it even continues to be tried to use pip constraint for that, pretty much a special log file, but it's tedious hard to update and easy to do incorrectly. Yeah, so I mentioned a tool which was pip tools, which was part of my talk and that is exactly a tool for kind of automating the use of pip constraint files. Basically what pip tool just does is it takes your requirements.in, which is the constraint file and then gives you back a requirements.text, which has the specific pinned versions and then that can just integrate with whatever other process you're currently using. Okay, next question, when you say editable installs, does it mean pip 660? And I added this one, this pip 660 is one for the pip project thermal-based builds, wheel-based. Yeah, so that's the idea. So previously with setup.piprojects, you can do pip install-e. And that will install the project as an editable install, which means that if you make code changes locally, then those will be reflected automatically. We lost that when we moved to piproject.toml for some pretty good reasons, but obviously this is a really popular feature that everyone really likes. So there's this pip 660 to bring it back. I don't know if that's approved or implemented yet, but in the meantime, Vulkan kind of hacks around this and generates a setup.pip and then calls pip install-e on that and then removes it again. So it's a bit messy, but it brings the feature back, which is nice. Okay, we'll get rid of that once the pip 660 is fully done. Okay, we have time for one more question. The description of pipa seems to not use pip 621, but it's own namespace, is that just not done yet? So we released, we've initially released this tool internally before pip 621 is done. So we had a specific tool.vulkan namespace for it. The migration over to fully pip 621 is done. It's possible that we missed some of the documentation in terms of updating it to reflect that. I'll take a look at that. Since we have a shorter session and we lost a little bit of time at the beginning, I can ask more questions. One other one that popped up was when multiple people in a firm working on a common library, in the same time, how do you manage the version between different branches, Office and Dev, in different environments, Prod and UAT? So what we generally try to do is we try to keep Prod and UAT environments in sync as close as we possibly can. So if there is a major divergence there, then that's gonna take some effort to kind of bring those back into alignment. But we usually try to avoid that problem as much as possible by just keeping everything as in sync with what's possible on a consistent basis. Okay, so thank you very much again for your talk and see you around at the conference virtually. Yeah, thanks for having me. I'm really enjoying the conference so far. Thank you so much. Thanks.


Thank you so much for the introduction. Thank you so much for having me. This conference has been so awesome.  This is actually the first time I've ever spoken at a conference, too. So thanks for having me. Last talk. Here we go. All right. So designing virtual reality data visualizations. What's VR? Cool. Some people know. Some people don't. Some people have some big ideas. Here's a 2D line chart. Here's a 3D line chart. Here's VR or what you would see if you are wearing a VR headset. So it's 3D in stereoscopic. So you get a different image in each eye. And you get sort of an added dimension to play with, which is time or motion if you choose to use it, and you have a thing on your head that looks like maybe one of these things, the Oculus or Google Cardboard, or Samsung Gear, or there's a lot of them coming out now. If you don't have a Google Cardboard, you can go get it. I would really suggest it. It's really easy to get. I just looked it up before this talk. It's $5. Boom. Just go get it. That's like sears.com or something. Yeah, so if you've got $5, I would highly recommend getting a Google Cardboard. All right, so why is everyone so into VR? What's the big deal? It hacks your brain. It's really nuts. If you haven't tried it before, try it out. Your mind is really tricked into believing that you are present in the world that's rendered in VR, not necessarily not in the world that you're currently in, but you really just get the sense. If here's just a couple of images that are examples, this is one where you put your arms out in front of you, and you've got this thing on your head, and there's a spider on the table, and man, it really feels like that spider is about to crawl on your arm. You get chills up your arm. It's crazy.  So it hacks your brain in a way that I've never experienced before. It really creates a depth of emotion that I think people are really excited about. Cool, so there's two kinds of VR content being made right now, and there's AR, which is augmented reality, which is a whole other ballgame that I'm not even going to get into. But right now, the two kinds of VR content are 360 degree video and rendered 3D graphics. So 360 degree video, there's been a lot of journalism done, and I come from a journalism background, so I'm going to be focusing on journalistic applications. Harvest of Change was one of the first groundbreaking ones that displaced an amazing piece by New York Times Magazine. The Wall Street Journal put out a really cool piece that follows with Ballerina as she's preparing behind the scenes at Lincoln Center, and all these are really rad. And then there's 3D rendered. How do you make it happen?  And for the rendered stuff, which I'm going to be talking more about, there's 3D rendering software, people use Unity, and there's 3JS, which is really cool. It's a JavaScript library. It's open source. It's a really new medium. In January 2012, Nani de la Pena debuted Hungren Los Angeles, which was I think actually a rendered rather than live action or 360 video one. The Google Cardboard only came out in July 2014. And now it's now. It really hasn't been that long since July 2014. That was really a turning point in accessibility for VR content. If you make something, now people can actually see it. So it really hasn't been that long since that happened. So this is a data-vis conference, right? There's been a lot of VR journalism made that's 360 video-based. More and more is coming out. It's really cool. What I want to see more of is taking advantage of the experiential quality of VR to tell data-driven stories. That sounds hard. Someone that has been doing it is this guy, Brian. He works at POV, or had worked at POV. Now he's got his own company data-vised. Let me see if I can make this video thing happen. Can I do it? No. Was it? Sick. OK. Let's try it again. All right, cool. So I'll let this play through. He created this visualization. And you're walking through a city. This is census data, I think. And this goes for a while. And then the next part of this video that you see, I don't know if Kino will let me fast forward. So I'm just going to keep talking. The next part of this video that you'll see is, here we go, crime rates. So the areas in red have a higher crime rate than the surrounding area. And that, I think, really takes advantage of your sort of visceral experience moving through this space. It's primal. We understand that red is like bad, or danger, or poison, or don't eat that frog, whatever. So as you're sort of walking through it, flying through it, and you go into a red zone, you really feel it's dangerous. So I think that's a really successful use of it. So here at the Wall Street Journal, not here in New York, we made this thing, the VR NASDAQ, that was pegged to when the NASDAQ broke its previous record, its previous high from the year 2000, which was just about one year ago, almost one year exactly ago. And I'll show you a demo of that. We made it in WebGL. So I'm not going to show the stereoscopic version, because you guys are, you can do that in your Google Cardboards, which I'm assuming you're all going to go and get from sears.com for $5, and look at it that way. But right now, I'm just going to show it to you in the sort of 3D mode in IMAX. So you start pre-2000, boom. You can see sort of elements going by on the left hand side, like a timeline. And the path that you're walking on is mapped to the inverse of the price-to-earnings ratio. So as you are approaching the top, that path is getting really, really skinny. And you can look down and see, man, that is a skinny path. That is dangerous. And that happened really fast. This is really steep. And we're about to go down. And here we go. Oh, oh, no. Oh, no. I've never had to narrate this in real time before. Utilized a sort of color understanding as well with the areas of red being times of recession. So now we'll just sort of climb slowly back to the present day or one year ago when the NASDAQ broke. It's previous high. And as you're sort of coming back up, you really get the sense that it's a pretty steady climb. That path that you're walking on is nice and wide, looks pretty stable. It feels very different than it felt when you were at the part of the visualization from the year 2000 in that giant bubble. And that feeling, that different feeling, was, I think we utilized that to communicate. Although the numbers were the same, the price of the NASDAQ index was the same. Oh, and there's rocket sip mode. The price was the same, but the feeling is different. And that's it. Plus rocket chips, because why not? Cool. So like I said, we used D3 and 3JS, their open source libraries. Roger Kenny, my partner in creating this interactive, is the man. I was involved very much in conceptual and design. And our art director, Jessica Yu, was very involved in art direction. The majority of the code base was written by Roger. And he rules. And you can rule too, because he wrote a tutorial, a brief tutorial for a setup that you can go find here. And I have a resources slide at the end that I'll just leave up. And I'm happy to share with whoever. It's actually pretty easy. There's a lot of open source tools to making sort of basic VR environments. Yeah, depending on time, I was going to do a demo of that. Yeah, maybe after, after. OK. So why do we do it? I already talked about that part. Why do we do it in the browser? So anybody can look at it in your Google Cardboards that you're getting for $5. We wouldn't need to go through a third party player for a 360 degree video.  And it's really tedious. So browser-based, 3JS, VR, awesome. So much fun. Some challenges. I have a lot of challenges. I'll start with user interaction. How do you design an interface when your user has no hands? They're like over here. The hands are over here holding the thing on their head. How are you supposed to navigate an interface like that? There are really two inputs that we can take advantage of, which is a focal point in the very center. And there's one button on the side of most headsets. So we use that to do stop and go and the focal point to look at a button. But of course, you can't just have people pressing buttons willy-nilly, like whatever they look at.  We had this sort of stoplight metaphor of red, yellow, green. And then Google and a lot of stuff they make. They have this concentric circle thing that grows and lets you know that you've selected a button or action item. There might be more possibilities that open up when people start using controllers in conjunction with the headsets. But right now I work at Wall Street Journal. I'm thinking about making stuff that's kind of as accessible as possible to the most number of people. So I'm not thinking about the problem too much of how to make the most complicated intricate to navigate visualization interactive NVR because it's not my problem to solve right now. But maybe it's yours. That sounded so corny. First talk ever. Here we go. Here we go. Information density has to be kind of low because it's hard to read NVR. And that's a real thing. The paragraphs we had on those sort of bulletin things were kind of about as much as we could get in there. And there was a timeline element, but it was still kind of really hard to focus on all the stuff that was going by. It's hard to read text in VR. Ice Drain and Nazia are real things. And in the VR NASDAQ, we kind of had to find this balance between. We had weekly data for the NASDAQ prices, but we didn't want users, like the camera, to bounce along each of those data points because then you'd get really nauseous. So we had to find something in between, like staying accurate to the data and making something that wouldn't make people feel sick. So Roger worked really hard on this algorithm that sort of followed the curve of it without being too bumpy. But I'm still not sure if we got that quite right or not. And it was difficult. There's also perception difficulties with 3D charts. As Kennedy mentioned, I definitely made this slide today. We're not that good at reading 3D charts. So it might not be an ideal medium for a lot of data visualizations.  And then you're gonna be like, stop, I'm sad, don't make fun of me, I'm like in second grade in my head or something, okay. Yeah, people don't generally have the cardboards yet either and that's a thing, or they don't have headsets yet. So designing for the lowest common VR denominator is a thing and then having a fallback, like what I showed you, which you can just look at in the browser if you go to wsda.com slash 3D NASDAQ, that's what you see in your browser. Yeah, one more difficult thing is cross-device compatibility and different viewing options and I'm gonna show you a flow chart, ready?   So what is it good for? Like why do that? Because that seems like a whole lot of bad things. It's good for potentially multi-dimensional data that you wouldn't be able to explore otherwise and it's good for using people's feelings about space to communicate stuff about data sets. What does that mean, but how? I don't know is the answer. Here's some things that I thought of that people have feelings about that have to do with space. Fear of heights. It's hard to walk on small things. Red maybe means danger. Moving quickly feels different than moving slowly. Flying is cool, pointy things might hurt, large things might be heavy, et cetera, et cetera, forever. Why use this stuff to visualize data? How best to use it? I don't know. We made VR NASDAQ like a year ago and I haven't thought of another great reason to do it again yet, which is why I haven't. So you guys think of something, think of something awesome.  Is VR a fad is something people are thinking but I think hell nah or at least I've had the Kool-Aid. One of the reasons being kids dig it. Kids really like VR and in 10 years, people who are kids now are gonna be like the main consumer of tech content. So kids dig it, so we all kinda gotta get on board I think.  Ready? Maybe it's easier to do this in the browser. How do I do that? Let's see.  Is that working? This is called the machine to be another. So these two people are wearing that and they are seeing the other person's body in their eyeballs and that is crazy. People talk a lot about empathy and empathy being the most important thing for journalism right now or being able to harvest empathy, make people feel something, make people understand the point of view of another person in the world or another group of people. That's why we tell stories, right? That's kind of it. So I think this is an incredible tool. Just an incredible tool to be able to do that. I'm so stoked, you can tell, I'm sure. This is Tilt Brush, which is for the HTC Vive, which I haven't gotten to try yet but I'm so looking forward to it. Homeboy is drawing in 3D and that is nuts. And then you can like go walk in the middle of your drawing, that's crazy.  This is Oculus Toy Box. That guy is like playing with another human being who's not in the physical space he's in but is in the virtual space that he's in and they're waving at each other. See, thumbs up, cool.  I mean, man, this is a Tribeca Film Institute interactive section website and they have a lot more really awesome stuff.  I think I might be ready to go back. And we're back, I said that. Oh, I'm done, cool. Thank you, here's a bunch of resources and if you feel like watching my grandparents try VR for the first time, I can show y'all that. Okay, let's just bring that up here. This is DataVite, whoa, where's my mouse? Okay, here are my grandparents. Oh, I don't know if I have any sound, I don't know. That's all right, I'll just skip to the good part. That's Roger. That's okay, you don't really need the sound. How about I just leave this up and let you guys ask questions? Does that sound good? Too mesmerized, bye, bye. I haven't mentioned to them that I was gonna show you guys this, so I hope they're not mad. For the video later, Mima, Vipa, I'm sorry. Okay, I'm gonna skip to the part where it's actually on their face. Look at that, look at my grandma. Okay, we need the sound. They are watching the VR Nasdaq. What, can I just put this mic over there? Yeah, let's do that. Okay. To review, and after three seconds, it'll bring you to the beginning of the chart to walk on it. I see, can you see a little, like a little circle on top of the start button? No. So look down a little bit, so that it's right in the center of your vision. Yeah, physically move the whole phone down a little bit. I see it kind of double. 34, 36, 37. Okay, now shall I start to move? Are you at the beginning? I have no idea. Here, let me, oh yeah, we're still at start ride. See, if you hold it in the center, you see that little bubble that turned green? Did you see it? No, maybe I need my glasses. I'm seeing it double. Oh, maybe you do need your glasses. Should it be double? Oh, we got to face this way. Oh, you started the ride. Maybe it was an accident. Oh, oh, that's marvelous. Oh. Thank you. We probably have time for one or two questions. Yeah, for sure. Totally. We'll also get everybody's slides and link to them. Well, there's two parts to that, I guess. Why the NASDAQ? Because the NASDAQ was looming close to breaking its record of its previous high from the 2000 bubble. Why in 3D? I was like, Roger started working on this in VR and was like super stoked on it. And I was away and I came back and I went to a meeting with him and it hadn't taken its roller coaster form yet. It was like a floating pipe in space. And I don't know why, but I was like, I just want to climb on that thing. And then I was like, oh, well, if we make it like you're walking on it, then there's a reason to do it in VR. So we should totally do it that way. And then everyone else was like, oh yeah, cool. Let's do it that way. So that's kind of how that went. Is that funny? That's dope. Good to know. I have not messed around with that. Yeah, cool. It's Photosphere, you said? Photo, Street View. Oh, cool. That's really cool. Kennedy. Mima and Bipa. What do you call your grandparents? Mimi. Cool. That's a good note to add on. Thank you so much. Thank you.


I look at me using my flip camera. I haven't used this thing in probably over a year. This is just a random video. Just some thoughts on something I've experienced today. So, someone I know, I don't know if I say any names, calls me up today because they were having computer issues. They just brought their Windows 7 or 8 machine into the shop and they paid someone 200 bucks to fix it and they upgraded them to Windows 10. They get home and within a day the machine is locking up. Okay, I would get my money back number one there but that's just me. So, what's happening and I'm not there, this is just them telling me over the phone is that they can't get it past the screen, a window keeps popping up telling them there's some sort of error and it gave them an 800 number to call, which they called. Now, this is someone who I've had confrontation with before trying to help them with their computers and they argue with me at everything I say. They call me for help but then don't want to listen to what I have to say. So, I'm trying to be as polite as possible but first off I just want to say any software on a computer pops up a screen saying to call a phone number. Don't call that phone number. It's just a screaming scam. Anyway, they've already called this number. It's some geek company. I don't remember the name of the company but it was Geek Something and it wasn't Geek Squad. It was something else, at least what they said the name was. So, while they're talking to me on the phone, they've already called this company and they've given them remote access to their computer. It's just... And they're calling me to see if what these people are saying...  Everything they say. So, they tell this person I know that the problem, the reason their computer is getting these error messages on their screen is because their network is dirty. They need to encrypt their network and remove computers from the network that are on the network that shouldn't be on the network. So, first of all, these people, their computer, their network is already encrypted which I told them because I've been there. I know they're using WPA. And they were told that they have somewhere around 12 devices on their system and I don't know if that's 12 devices, network devices on their network currently or if they're looking at, if these people have now accessed their router and looking at recently connected devices. I'm assuming they're talking about at that time, which makes sense because these people, they have at least one or two desktops, at least two laptops, a tablet, a couple of phones, a network printer, at least two webcams, network cams on their system that I know of. So, the fact that they have 12 devices and they have two routers too, a router and a repeater which should be showing up if you do a network scan. So, the 12 devices make sense. Again, these people are telling them that the network is not encrypted that at least once a year, if not every month, they need to have professionals come in and clean their network. Whatever the heck that means.  Having someone come in to clean your network, what does that even mean? So, now they're asking me, okay, they're worried because they run a business. They ask me, are these people that they've now given access to their computers and they're currently on their systems as far as I know while we're talking. Could they screw things up? Which is a hard to answer question. I'm like, I said, can they screw up your computers beyond repair? No, no, I mean they could screw up the software, but that can always easily be fixed. Well, you're running Windows, so it's a little more difficult. But in general, it's easy to fix. And they said, well, no, no, you know, I run a business. I have everything backed up on a server. I've disconnected that hard drive. I've turned off the computer, another computer, and disconnected the hard drive that most of the business stuff is on, although this is also a business computer. He wants to know if these people can later on get in and then access not only that computer, but another computer and delete files. I'm trying to politely tell them that yes, they can. Because once you've given some remote access, you have no clue what they're doing. You have no clue what they're installing. And I'm trying to tell them this politely, but bluntly, you should have never given anyone access. Someone you don't know remote access to your machine to begin with. And I know for a fact the way their network's set up, because I've told them time and again over the years, is basically their two computers that they do all their office stuff on, all their business stuff on. They have pretty much the whole hard drive shared between the two computers, the entire C drive basically. So if these people do log back in on one computer, they're going to have access to the other computer and be able to delete those files. And he's like, well, can you make sure that once they're out, they're out? And the answer is no. And I tried to give him an example and I gave a bad analogy, which has kind of brought me to bring this view, because I thought of a better analogy and I wanted to share it with somebody. I said, it's like you gave someone the keys to your house and now you're asking if they can get into your house when you're not around, of course they can. And he's like, well, can't I just change my locks? He wants to change his password. And really the key analogy is not a good analogy, because really what you've done when you've installed software from somebody else to give them road access is that you've put in a new door that they only can change the lock on. Now you can try to remove that door, but now that you've given them access to your system, they could have made as many doors as they want. Now, can you look for doors that are currently open, ports on your system, active running software? Yeah, but they could have installed something that will activate later on, whether it be on a time delay or something that constantly checks a website for some sort of update. And that's something you can't really monitor unless you're really carefully, because your computer has so much internet traffic that one more link to a page somewhere randomly running, for updates to activate something is impossible. Once a system is compromised, the system is compromised, the only thing you can really do is wipe the whole system and start from scratch. Some people may disagree with me that. Those are probably also people who believe that antivirus actually helps, which I have a video coming up. Let me talk about that. Antivirus is a complete BS, short version of the video I have coming up. He seemed kind of disappointed and he's like, well, I've given at least 20 different companies access to my computers over the years because I can never get anyone to come out twice, which is interesting because most of these companies, what they do is they come in temporarily fiction machine but screw something else up so that you call them back later. So I'm surprised he hasn't been able to get anyone to come back out more than once. But I basically told him, and he was kind of mad and you give people bad news and they always shoot the messenger. I'm like, no, you shouldn't have done that. You shouldn't have given someone you don't know, someone that you don't completely trust, remote access to your machine. And once you've done it, you've done it. There's no real undoing it. Of course, again, there'll be people who say that you can't. No, you can't. I mean, if they really knew what they were doing or even half knew what they were doing, there's no way you can find every little thing that they've left behind. So my point is there's always going to be a level of trust.  If you're adding in extra repositories or PPAs or whatever they're called onto your system, you really trust who you're getting that stuff from. And you have to trust somebody. But when you're just calling up random numbers, companies you don't even know, and you're giving them access to your machine and you're installing software they're telling you to install and you don't really even know what it is, that is the bad thing. And as I told them, it's easy to keep people out of your system. But as soon as you let somebody in, you either give them access or you install any piece of software that they've given you, you've now basically given your system over to those people. And once you do that, there's very little you can do to undo it to truly know that it's undone besides wipe your system and start from scratch. Which if you're running your system properly really shouldn't be that hard to do, but at the same time you shouldn't have to do that for this particular situation. Anyway, this is just me ranting and raving and I was trying to be very polite to the person I was talking to because they do this regularly, they ask me for my advice and then basically yell at me when I give my advice and then I usually end up yelling back. This time I didn't do that, I kept my cool. They still seemed upset with me. People just don't like to hear that they've done something they shouldn't have. But anyway, this is just a random video. Hope I didn't bore you too much. Comment below, let me know what you think. But I think we can all agree that giving random people, you don't know, remote access to your machine, especially from a phone number that just randomly popped up on your machine when it was malfunctioning, is probably a bad idea. So anyway, thanks for watching. Have a great day.


I'm straightening out to Oshun State, where the governor, Ademola Diliq, has restated his commitment to transform the state with a promise to administer the affairs of the state with the fear of God and in a transparent manner. The governor who has been using his campaign office located at the Ogoluwa in Oshubu, the state capitol sends his inauguration on the 27th of November last year, says he will officially resume his office in government secretariat in two weeks. Governor Ademola made the statement while speaking during an interreligious prayers and thanksgiving service held by the government secretary to herald a new year. The governor has restated his pledge to carry all traditional rulers in the state along in his government. Go and look at the history. Go and look at when I was in the Senate. I said so many things. All my campaign promises were kept. Today again, slowly but surely, you can see the sign. The next one or two weeks, I'll be coming over here so that I'll be in the office so that we can enjoy together. I want you to join hands together in civil service and help beyond that to move Oshun State forward. It's an age-long tradition in Oshun State to do this prayer in the first working day of the year but he has taken it even the step further to ensure that it is all encompassing and it is deeper than it used to be. And I assure you that this is a governor that is committed to the covenant he has with God and with the people of Oshun State. We must be prudent in our spending. And of course that has always been my charge to the government. The government of the state needs to be prudent and those who are leading us. They need to manage the little resources, the little funds that come into the state and that we generate in the state. The committee under my leadership have done justice to the shift and seat also within Oshun State especially with the terms of reference, shift and seat, the installation of kings between July 17 and November 26.