 Fantastic. Everyone, the lightning talks are often the best part of the whole day at the conference. Everything that I've seen so far has been of incredibly high quality. I've had a great time. And guess what? This next section is going to be even better. So, without any further ado, are you all ready for lightning talks? Please give a sort of general British mumble if you are. Oh, come on. That was way too enthusiastic. Thank you very much, everyone. Please give Nikita a big hand. Hello, everyone. I'm very excited to present to you today. I only got five minutes, so that'll be pretty quick. So, my name is Nikita Chepanov. I work in Bloomberg. I actually came here all the way from New York. Let's talk about virtual end. So, you have this unique chance for you to write your new project, and you just, of course, you chose Python to write your back end. And this time, you're definitely going to use all the best practices possible. You're going to use the requirements, TXT and the virtual environments and all that. Definitely use the frozen virtual environments. And to make it easy, probably the way you're going to install your requirements file is by writing pip install in virtual end in production. That makes sense. And, you know, it's going to work for a while. And then later, because of the new product you're working on is so, so amazing, you're going to get more users. With more users, you need more instances, more features, the huge requirements file takes forever to install. I think what's more important now you have to do pip install on all of your production machines that may or may not make sense and the PyPI may or may not be happy about it. And it takes forever. And you think to yourself, well, virtual end is, you know, self-contained. Is it? Well, I've heard it is. So how about we just try to pip install once, put it in the folder, then archive the folder, then move the folder to all of the production machines on archive the folder, and we got ourselves a deployment system. Makes sense? Let's try. Well, the first time you do it, you're going to find out something interesting. Not found. Why? Well, it turned out that the virtual end has a hard coded path to the place where it was built. You can probably try to fix it. You can make it, you know, relative. Let's do that. What now? Well, this time there's a hard coded path in every single setup.py entry point, such as the unicorn itself. And that, of course, can also be fixed because fortunately, virtual end has an unadvertised and unadvertised feature called dash dash relocatable. And this feature is by the developers themselves of virtual end is not loved. They actually say it's, you know, experimental and they're not happy they ever introduced it in the first place. All right. If you do that, then instead of having the hard coded path to the place where the virtual end was built for each and every one of the entry points, you're going to get the ENV-based Python lookup and a magic line of Python. It works. Trust me, I tried. Well, that actually is going to work. Now you can actually run your application by just, you know, packaging it and moving it to all the production machines. You no longer have to do pip install in hundreds of machines and seems like a done deal. However, did you know that virtual end makes a full copy of the Python executable inside the virtual end? It's not a sim link. It's a full copy of the executable and the executable depends on the SO. That is not part of the environment. So the SO is there in the system. So in theory, by upgrading Python, you can accidentally break your virtual end. However, reasonably certain that will not happen because Python is a mature project. But how about Python C extensions? What about, for example, MySQL client? If you pip install MySQL client, you're going to find out that inside the virtual end and inside the site packages, there will be a MySQL.so that has a dynamic runtime dependency on the LibMySQL client that is so which, in turn, is not inside the virtual end. So in theory, by upgrading the, you know, what's the problem with this, right? The problem is, if you have any mismatch between the build and production environment system packages, which you can introduce by upgrading your build or production environment, you can, in theory, break your virtual end and no amount of frozen requirements file will help you. What can you do? Well, there's a bunch of options. They are of various usefulness. So one of the, of course, you know, if you have access to virtualization or containerization, now you can probably appreciate why this is such a big deal. Now, let's say you don't. There's a pep that introduced the concept of the zip-zipped Python applications. And that would actually work because Python knows how to open the py files from inside of the zip archive, but that's not going to work with the SO because DL open doesn't know how to open SOs from the zip archive. There's multiple various things implemented. There's one from LinkedIn released just a couple of months ago, so apparently other companies are also concerned about this. There's multiple different other solutions such as DH virtual end from Spotify, one from Google that is just a way to integrate the virtual end inside a larger build system that would know how to define the dependencies for the outside world outside of the Python. And there's another few solutions that are essentially just a way to be a package management system itself. Thank you very much. Thank you, Nikita. Alex is up next. So lightning talks for anyone that doesn't know are talks that are limited in duration to five minutes. You don't have to take up the full five minutes, but five minutes is the maximum. And so the convention that we have for bringing lightning talks to an end is that once the speaker has more or less run out of time, I will stick up one hand. When I stick up one hand, I'd like you all to clap with one finger. Can you try that for me now? Like, that's a little sound like raindrops that just tell the speaker that basically their time is up and they've got the time now to finish the current sentence that they're working on. Depending on the speaker, that sentence may then drag on way too long, at which point I'm going to put up two hands and that's your cue to give them a massive round of applause as a way of silencing and thanking them for the five minutes and 13 seconds of your time that they've given to you. Does that all make sense? All right, Edie. So in a moment, Alex will be ready. In the meantime, it's my job to tell bad jokes in between each of the lightning talks. It's a job I relish. I apologize for inflicting it on you all. A joke I often tell is one I heard from one of the Olas of the Django Girls world. And that's a joke I really look forward to telling you. In the next break in between the talks, in the meantime, please give Alex a big hand. Good evening, everyone. My name's Alex Wilmer, and I would like to convince you that the library known as Pickle can be rehabilitated. For those who don't know already, Pickle is a module in the Python standard library. It is extremely convenient because with one function call, you can serialize almost arbitrary Python objects, including custom classes, send them over the wire, save them to disk, put them in a cache, send them by carrier pigeon, and what comes out the other side will deserialize almost exactly to the objects that you put into it. It is very, very tempting. Unfortunately, there is a caveat. Don't use Pickle. This is the standard advice, the time being this is my advice. Pickle is a very, very good way to shoot yourself in the foot and take it off at the hip. So why is this? Well, the standard counter example is that if you don't take very particular measures, then somebody sending you a malicious Pickle payload can cause arbitrary code execution. This is a fairly benign example. It's the standard example. In this case, unpickling something has resulted in running a command called echo. That command could equally and just as easily have been rm-rf. If your process is running as root and you do this, you will not be having a good day. So there is a standard mitigation for this particular attack and that is to overload a method of the unpickler class called find class. It has a slightly different name in Python 2, but it is a very similar technique. The trouble with this mitigation is that it's opt-in. Unless you take these very particular measures, you will shoot yourself in the foot and take it off at the hip. This is enlarge why I still don't recommend using Pickle because it is dangerous by default. Of course, I wouldn't be telling you all this if I didn't think there was a glimmer of hope and this is what I'm trying to do. In addition to the attacks with arbitrary code execution, there are a number of other attacks that Pickle might be subject to. We don't know them all. That is part of the reason that we still do not recommend that you use it, but they fall into broad categories of denial of service, exposing internal data. This is a very big problem in the Java world with a class of attacks that rely on a thing called gadgets. Pickle may be subject to these. I have not seen evidence that it is, but in this case, we need strong evidence that it isn't before we assume so. In terms of what I have done to try and advance this art, you're looking here at two graphs of the time to decode some fairly standard Pickle things. On the left, you will be seeing the basic Pickle protocol zero, which you get if you don't explicitly ask for anything else. The trouble with that is that the time to decode is going up to about 10,000 times what it would be otherwise, and you're taking 10 seconds to process about a megabyte of data, which is not a good rate in this day and age. There are ways to mitigate against this, but the problem is that if you are unpickling things from somebody who is a third party, they get to choose what protocol you are unpickling. There are mitigations we can do against this, which has been the library that is in a very prototypical state that I am starting to put together that I'm calling Pickleite. The first thing that Pickleite does is that it is safe by default. So if you do not tell it, if you do not put arbitrary classes that you want to Pickle or unpickle onto a whitelist, Pickleite will throw an error. It will not fail dangerous if I've done this right, damn it. Shut up. Okay, and so that's how you can get around that, that's how you can register things, and if you would like to know more, please visit github.com, Moriarty Pickle Plus. Thank you. Is that a conservative time there, Alex? I had to give him another two seconds. Thanks very much for that. I was reminded when that sort of rm-rf-slash thing of a post I saw the other day where someone goes, I just accidentally executed my whole history file. How's your day going? Which is one of those where, you know, it takes you a little while to go, oh, God, that really would be awful, wouldn't it? Yeah, yeah. Especially if you had pseudo kind of active in memory and going. All right, our next talk is by Mark Garcia. So this lady is walking down the road and she spots a horseshoe on the floor. So she bends over to pick it up and she looks at it and she turns it over and on the other side there's a horse. It's kind of a visual gag, that one. That's Ola's Polish grandmother's favorite joke. Please give Mark a big hand. Can you hear me with this mic? Yeah. Is it okay? Okay. Yeah, because it's a live demo so I cannot handle the mic. So, okay, I'm going to present the best Jupiter kernel. We've got a very cool talk about Jupiter this morning, really impressive widgets on that, I'm going to, I don't want to be arrogant, but I'm going to show something cooler, like the best Jupiter kernel and it's not the C++ that has just been released because there are some new people here. I will just introduce a bit what's Jupiter and where it comes from. So we all know Python, at least what it is. We've got a Python terminal where we can just run interactive code. This wasn't enough powerful at some point, so what we managed to have, Fernando Perez wrote this, Python, that it's a bit better, it's still in the terminal, but it has some features, some magic and it's a bit better to work with when you have multi-line and things like that. And colors. Oh, and colors. So then at some point what we've got is that this moved to the web, so the same exact concept of Python terminal, but into the web, so we can execute any Python coding here. At some point this was too cool, so the Jupiter, the application and the programming language get decoupled, so we could install different languages, so the interface is exactly the same, but the language can be different. So here, for example, you can see that this is our code. If you are not familiar with R, you don't come from the data science world and that the most relevant part of this that my variable is not an attribute of my, it's actually the name of the variable, it's my.variable. Some things are people like. At some point this was too cool, so what we've got is that we started to have markdowns, links, images and lots of stuff, so if you know about the three-body problem, basically talk to me because I just downloaded this randomly from the internet to show you, but you have code, you have like, you can have some plots and that, which is pretty cool. At some point Damian Avila, from Argentina, basically thought it was cool to build a plugin that you have a button in here and you can convert this to a presentation. I will come back to these slides later, but it's really, really useful. I use it for all my presentations, saves a lot of time. At some point someone thought that it was good to have PHP in here, so you can execute PHP in the terminal. There is a kernel for that. What's really interesting is that there is an echo kernel that basically is a hello world that all that it does is you just print whatever you send. It's not that useful, but it's really useful in terms of learning how to implement that because you just take this code and you start to implement those things. So with those things in mind, I thought, why don't you use deep learning, blockchain, and start to put together a kernel, really, really amazing kernel that can run any language. It detects everything, you can run everything and it always knows what you want. It's really simple. I decided that instead of executing the code, I would make it just give feedback about the code in a really positive and constructive way. Yeah, let's go to that. Let's start with R. That's the live coding session that's basically creating a list in R. R is mainly a running language. So yeah, you get some really nice feedback about that. Then why not why not why not use madlap? Madlap is a pretty cool language, kind of the same data science, data scientist. We use a lot of these things, so yeah, it also provides really interesting stuff. Let's write some PHP. I'm not sure. I still have time to show you, but I want to show. Yeah, PHP also works. And you're thinking, yeah, PHP is not that cool, because no Microsoft acquire a GitHub, so the next trending language probably would be basic, so let's try some basic here. Yeah, pretty cool. Now we're stating, yeah, let's try Java, but then I thought, like, do you know what the company that owns Java did with MySQL, OpenOffice, Solaris, it's like, no, let's better keep far from our projects, just in case. And yeah, let's try Python, of course, that's our favorite language. So what can we, oops, what can we do with this? So yeah, that's basically what I think too. I'm making core developers, maintaining this code is really something that we don't like. And yeah, finally, Python 3, let's see, it also works. Yeah, absolutely. So going back to my presentation, that's what I just explained. There's the architecture, there is the application, there is the kernel, they are independent, you can build your kernels, it's quite straightforward. Basically, I had this idea this morning and now I've got the kernel with the deep learning and the blockchain took a bit of time, but the Jupyter that much. Some useful information. If you are into open source contributions, basically if you want to contribute to a project like this or to Jupyter and to that, you can join us here in London for Spring, we've got this meetup group. If you're more into fun projects, for fun, I think the London Python coding dojo is a really great place to work on a project like this with other people and learn. And yeah, if you want to know more about me, that's where you can follow, find this slide, well, I don't have slides, but yeah, I wanted to put my Twitter here anyway. APPLAUSE Thanks very much, Mark. Up next is Dan Palmer. The name of the kernel is Grumpi. Should I say that earlier? Nope, you're off. Oh, I just got that, though. Yeah, Grumpi. Yeah, that's good, though. All right, you can have that. Fine. So the Pirate Programmer walks into a bar and she's got a parrot on her shoulder and the parrot is going, pieces of seven, pieces of seven, pieces of seven. The barman goes, oh, I think there's something wrong with your parrot, mate. And she goes, yeah, it's got a parroty error. And the barman goes, yeah, I thought it was a bit off. Thank you, I'm here all week. But more importantly, so is Dan. Please give him a big hand. Hi, I'm Dan Palmer. And like many of you, I'm sure we are hiring developers and it is always difficult to find more developers. So I want to talk to you about this one weird trip to double the size of your developer team overnight. So this is a picture of everyone who has contributed to Thread's main code base. Sorry, every developer at Thread who's contributed to Thread's main code base in its history. This is actually everyone who has contributed to it ever. There's a lot more people. In fact, we have 17 developers who've ever contributed and 19 people who are not developers day-to-day who have contributed. Not all of these other 19 came at it from scratch. Our head of operations, actually I wrote these slides a few months ago, these been promoted since, but yeah, our head operations, that's warehouse operations, not servers for us, used to compete in machine learning competitions when he was at university. One of our marketers used a lot of scripts to automate Facebook ads and things like that. And one of our PMs has a math degree where he did a bit coding. So they're not all coming at it from scratch, but seven of those at my last count had no previous programming at all before contributing to our main code base at Thread. And this is a large code base with 85,000 commits, a couple of 100,000 lines of code. So not trivial to get started in. What are they doing? They're not developing new features, mostly. A lot of what they're doing is editing configuration that's in code. They are editing copy, job pages, those sorts of things, particularly like our help pages for customers, our support team can edit that. They're creating reports. We've got a sort of stack of Python classes that let you kind of compose reports together quite easily without understanding too much about what's actually going on. So they're creating reports. And a couple of them have developed medium-sized features, you know, a couple of 100 lines of code, maybe some dashboards, changes to our warehouse tooling, marketing tooling, things like that. And I think this is really great. It means that as a developer I can focus on bigger tasks. I can focus on things that aren't just minor bits of maintenance around the code base or changing settings for people. It also means that we can focus on harder tasks. We're doing a lot less chop-in changing between different things. Context switching is expensive. It takes overhead, even if something might take two minutes to change. You've got to stash all your code, check out a different branch, make the change, put it up for code review, all those sorts of things. It's all sort of mental overhead. It also means we can actually build fewer internal management tools. We need to put fewer things in the database. They're just settings in code somewhere. We don't need to have a CMS for our help page. We can just have an HTML file. Because the team you need to edit it are able to go and edit it straight in the code. Which means less code overall, simpler stuff. It's also empowering for them. They're in more control over their areas of responsibility. They can own that process. So how do we do this? We ran an internal SQL course. I think about 10 people in a company of like 55-ish. Probably about 40 at the time we ran the course. About 10 people took this. We now have fashion stylists building dashboards to monitor the stuff that they're working on. We've helped people through the Python Coursera course. We do pairing even with non-developers, particularly around code review. We do hack days internally. We have tutorials on how to use GitHub. We're just generally being involved. Yeah, but I don't want to let non-developers near my code base, you might say. Well, most editing is done through the GitHub web interface. So there's very little required from developers to support. No getting sort of git and dependency setup. All code is still reviewed by an engineer. Continuous deployment allows other people to make quick changes. High priority changes quickly. Continuous integration and linting helps protect us a lot. We have had some minor issues. Nothing major has gone wrong so far. And we do five wise when things happen. So we find the root cause and solve those problems. We don't blame people for getting things wrong. So yeah, that's it. These are all our contributors who have helped us move our code base forward without any formal training. Yeah, thank you. Thank you very much, Dan. Next is Amu Kumar. Yep, Anil. Sorry. Yeah, you're up. So I've been working on this. It's a, are you lacking a laptop name? Okay. Does it say Anil Kumar? Yeah. All right. Let me give you a minute or two. So I've been working on a new joke and if it works, it should be a double. And it's about a person who's a joke enthusiast like myself. And there's like a word play competition in the newspaper and they enter it. They're just about to go on holiday and they enter this competition. They send in 10 different entries. But as well as being a joke enthusiast, they're also kind of enthusiastic gardener. And they've been growing their own fruit vegetables. And they've got a bunch of strawberries that are just about ready. And they've already sort of harvested them and put them in those little boxes, you know, that you get at the strawberry shop. But they're not quite ripe yet. And so while they're on holiday, they've asked their cleaning ladies to just come in every couple of days and just make sure that they're clean and they're not being eaten by any slugs and that they're just a light sprinkling of water and that they're just generally sort of tended to. But he knows his cleaning lady is a really, he's really hoping that one of the ten jokes is going to win the competition and he's really hoping that he's going to have like a little tray of strawberries that's been well taken care of. But unfortunately, when he gets home, he looks into it and no pun intended. No pun it tended. No pun intended win the competition. No pun at strawberries tend, okay. It's a difficult one. Yeah, let's let somebody else talk. Hi, everyone. This is... Hello. Hi, everyone. This is Amit and I'm talking about NumFocus. If you've been to Pyata London, then you might have seen this presentation. So this is the mission of Num... How many of you have heard of NumFocus? Pretty much not everyone. Okay. This is the mission of NumFocus to promote high-level programming languages like Python and Julia, and make projects sustainable. Sustainable. Better tools for the better world. So the projects sponsored by NumFocus are used by everyone, pretty much everyone, for example, from Netflix to NASA. So NumFocus has a fiscal sponsorship program which does these things for the projects. So open source projects are always lacking of resources and they don't want to do all these things by themselves and because... and these things are tricky bits. NumFocus is a part of, for example, Google Summer of Code, DIC and these things. Have you heard of Google Summer of Code? How many of you have heard of it? Any students in the room? So Google Summer of Code is a program by Google which sponsors students writing code for open source projects and NumFocus is an organization in that, so basically you can work in the summer for open source projects and get some good cash. So Pyata is one of the big initiatives of NumFocus. I think now you can see it has got like 101 groups right now. So if you want to start a new one, just come and talk to me. So raise your hand if you have used one of these projects. Keep it up if you have contributed to any of them. How many of you have committed at least one patch to it or maybe contributed anyway, money, time, I think? A big round of applause for these guys, please. So this is the biggest project with open source projects because they're used by millions of people, but there are very few contributors. So NumFocus is basically trying to bridge that gap by bringing the key players to bring funding for the open source projects. So if you use these projects at work every day, then you would like to be or come here to be here. So and you can contribute in all these three ways. It's not just code. You can also contribute your time. You can contribute money by membership. And anyway, you are helping NumFocus by any of the three means. Thank you. The final final talk is by Lillian Nandi. There we go. So what do you think? Am I on to a winner with that punnit-tended joke? Have you ever heard of a joke with two punchlines at the same time? I don't think so. I think it's better than you gave it credit for, to be honest. Yeah, just needs work, needs work. All right. Any other suggestions for jokes that could be made to work with a double punchline? I'll definitely be taking them after the end. Have you got any slides, Lillian? No. Off the cuff. All right, please give Lillian a big hand for the final likely talk of the day. Hi, the title of my talk is How to Teach Computer Programming Successfully to the Next Generation in a Way Fit for Purpose. Now, it's probably an undisputed fact that computer science is the leading discipline of the 21st century. And there's not an aspect of life that programming computer science is not at medicine, science, arts, etc. And such is the ubiquitous nature of technology. And the heart of it is the algorithm and computer programming. So it's actually quite imperative that we do teach our young people and children how to program, and it has been dubbed the fourth R, such as reading, writing and arithmetic. And there's been a recent worldwide initiative to teach this computer programming in schools. It's only a few years old. So this has posed a great deal of challenges in many respects. One being infrastructure, teachers teaching resources, textbooks, etc. Two being programming languages, three being the curriculum, and four maybe perception. So let's just look at a couple of these programming languages. Now, I had the privilege some months ago to be appointed a computer science teacher in a school. And I was the only person there teaching years 7 to 13. As such, I had a lot of freedom in what I did. And no one knowing anything about it, I could tell them anything. I could make them play robots and say this is computational thinking. And they wouldn't know the difference. And I think they were doing that before. So, you know, conventional wisdom or there is a, that they should learn scratch before they learn a textual language. I do question this, and I do have some reservations about it. Why should they have do drag and drop languages? You know, after all they can write essays, they can solve simultaneous equations at the age of 11, they can do many things. They have textbooks, they have exercise books to write in. So why should it be taught, drag and drop? So I introduced this Python programming languages right across the board because previously they hadn't been in anything really. And I thought, okay, programming language is like English. They treat it like an essay. It has grammar, it has structure, it has repetition, etc. So that's the way I approached it. And they were taught from the ground upwards, a bottom up approach rather than a top down approach. They had no projects to do. They were mastering the input statement, the output statement, the for loop, the while loop in very small programs. Now it was very boring. It was copying and it was very repetitive. But I think it was quite important that they had to master their basics. And about after eight weeks or so, they had actually mastered these basics. And they were able to write programs or some note after that point. And it also became their favourite subject as well. The other point is one of curriculum here. Governments worldwide, they have curriculums. They put some words on a piece of paper. And the educational establishments tend to follow these curriculums. Now I dispute this. I have some reservation with this as well. I don't think it should be actually government-led per se. It should actually be led by experts or teachers who actually have a lot of subjects rather than a bunch of civil service who have written some words on a piece of paper. I remember at school, when we studied English, grammar was taken out of the curriculum and our teacher said to us, it's very important so I will teach you. And our maths and our English teachers had the courage of their convictions to teach us things which were not in the curriculum. So really I think computer science people should have convictions to teach things which are important and insist and not in the curriculum per se. It's a guide and it's an important guide but it's not the be-end and end-all. And perception the students have to realise it's something quite desirable. Now luckily I was, I say luckily I was in a boys' school and they did perceive it as something desirable and we made it even more desirable by showing computer applications of computers generating classical music, making generating Rembrandts doing robotic surgery. And I showed these videos from age 11, 12, 13, 14, 15. Now guess who was most enthralled by it? It was the 11 year olds which loved the painting of the Rembrandt. We don't have to show them things that they already know as such. We can bring their level up if we want to do so and that's what education is about is to bring people's level up. And really I think that computer science should be commercially led and be fit for purpose and we should we shouldn't dumb down, we shouldn't make it simple we should make it harder and fit for purpose. Thank you. Thank you very much, Lillian. That was our final lightning talk for the day. Can I please get a round of applause for every single person who came up and gave a lightning talk here today? I'm handing over now to your conference chair. Please give them a big hand for all the work that the organizers have done for our wonderful day, a big round of applause scenario. Without this person there would be no conference. Okay, so I hope everyone had a good time and we are just going to close the day with some final remarks. So first of all please remember to leave the liners at the exit. You will be able to collect them tomorrow and go through the registration again. I'm sorry about that but it's a pretty procedure. Next, I forgot this morning but I have it here. So that's the link if you want to get into the Slack workspace you also have it in the email that we send to all the attendees. But in case you didn't receive the email it went to the spam you can just join the Slack via this invitation email. Next, we have social leaving now happening really across the corner the places called the Sugar Loft we invite you all to come. BRs are on you, of course, sorry about that and all the money just goes to the PSF which is probably a better use than just paying some BS. We invite you to come, have some time sharing together and continue the working which I think is one of the key things of these events. We were asked how can you deliver feedback to the organization so we are going to send an email after the event where if you have any suggestions for next year or anything you want to share with us we'll provide some links and some way to provide the structure of feedback for you. And last thing many people have asked and I know this is like probably the most codicious item of the whole conference if you want an amazing first t-shirt you have my here in the front it's not only an amazing developer but also that's impressive work on design that is going to prepare a way for you to be able to get the t-shirt. So, well, first of all can I have please a round of applause for May for this amazing logo and all the design for the project. So with that I hope to see you in Sugar Loft and to see you tomorrow as well. Thank you very much and that's the video we missed this morning. Thank you.