Day 1 Lightning Talks

Speaker 1: Okay, so a lightning talk. Let's set the rules so everybody knows who they are, especially the people down the front here who are going to have to abide by the rules. A lightning talk is a five-minute talk. about any topic you want. And when I say any topic, it can be any topic at all. I have seen fantastic lightning talks from Simon Willison, one of the original people in the Django project, all about zeppelins. Uh and we do actually have a talk on our list today about something that I know is not Django or code related. Lightning talks are an amazing way to get experience. speaking. If you have never spoken in front of a large audience before, a lightning talk is a perfect opportunity for you to learn how to speak in public, to get experience speaking in public. And see if maybe it's next year around when the when the call for papers comes up if you want to uh want to get involved. The key thing about lightning talks though is it we say it's five minutes.

Speaker 1: There is a five-minute limit. There is a f there will be a five-minute timer down the bottom here Uh when that timer runs out, the time is out. We we we will sweep you off the stage and make sure that you are off the stage so the next speaker can come up on stage. But your talk can be shorter than five minutes if you so choose. You do not have to use the full five minutes. If you just need to get up and announce something, you can do that too. So, with that, I now wish to introduce our first lightning speaker for today, Craig Anderson. I have no idea what they're speaking about, so everyone, please welcome Craig to the stage. Uh

Speaker 2: thank you very much. Um So, people who don't know what black is, that's in the Python package, can you raise your hand Okay, so there's some people here. Okay, and hopefully if you work with teams, this will make your life a bit better Yeah, so I'm I'm Craig. Uh there's my Twitter and uh website. You can find out more about me if you want to get in touch, uh please do. Uh so yes, uh Black is a Python auto formatter. Um it will help you kind of basically avoid the situation um yeah this This phone thing is not going to work for me. Yeah, it

Speaker 2: 'll avoid the situation of bike shedding. Now if you're unfamiliar with what uh bike shedding is. Uh it's basically the tendency for a technical team to just get bogged down in a lot of unnecessary technical de well unimportant technical detail, I suppose. In a similar way that if you are building a bike shed One of the least important things is the colour that it's painted. So yeah, why is this important? So Like you you can use PEP 8 and PEP 8 is great. Um of course, hopefully we're all using that. Um but it doesn't kind of go to the kind of minutiae details of uh like exactly how a lot of your code should be formatted.

Speaker 2: So you might end up with lots of pull requests that look like this, which is the exact same functional code, but just somebody's preferring one style over another. So yeah, that's one way you can go. You can also kind of go to the uh and come up with your own uh formatting guidelines. That can be difficult to come up with, that can be even more difficult to enforce. And it can become maybe it says more about me, but it can become a bit emotional when you're kind of debating, oh, I prefer, you know, this line length or you know, my colleague prefers a longer line length. Um so black kind of makes makes a decision and it just okay this is the way it's going to be. So what it looks like, you get a really messy mass of code.

Speaker 2: Hopefully you can see that. That's from an example that they have online. And it takes you to this. Which is quite nice, reasonably formatted. Um yeah, and PEPA compliant. Except um Whenever I've shown this to developers, uh and whenever when I saw it for the first time myself, I thought, yeah, that's great, but I prefer things to be done in this way. Like I prefer um The time's actually turned off. Yeah. Oh, and it stopped. Cool. I can go forever. Yeah, but like you know, for for example, I don't necessarily like the fact that there's all of these white space and these lists, or I don't like

Speaker 2: I I prefer single quotes over double quotes. Um Basically, like you know, what Black is saying to you is that um yeah, you know, you give up that control um and the advantage that you get is all of a sudden that you're just kind of you're freed from all of this um Yeah, all of this extra stuff that you need to worry about, all of this extra cognitive load anytime you write code. And yeah, it saves you from having to decide which color your bike shed is supposed to be. It's on GitHub, if you look in the README, there is lots of kind of really detailed kind of discussion as to why the decisions have been made that have been made. They pretty much convinced me that everything I thought was a bit

Speaker 2: uh funny uh was actually a better idea than what I thought. Um Yeah, and there's me again, and thank you very much for your time

Speaker 1: Which rip robs me of my opportunity. I usually fill the space in between here with a little bit of a story. Um I do have an interesting piece of history about about uh Denmark that I've discovered just having arrived here in the first time. But I will now uh invite to the stage our next speaker, Raul Tavares, who uh is going to Speak without slides. So uh second thing you can know about lightning talks, you don't have to use slides.

Speaker 3: Fellow Djangouts, thank you for being here. Before I begin, uh let me share with you that I have been having two loves in my life. One is programming, another one is psychology. So far, programming is winning. However, I found some knowledge about psychology quite useful in programming. Even some people can look at it in some kind of completely unrelated stuff. Psychology, principally the psychology of perception, can be very useful when we are building user interfaces. behaviorism

Speaker 3: can be very useful when we want our users to look more to one of other characteristics. And psychology about people also it's very useful to know ourselves. Programmers have been called a lot of strange things: nerds, geeks, antisocials , lacking of social abilities. There is some kind of good examples about that. For example, a fictional character that is Sheldon Cooper from Big Bang Theory, or a very real one that is. Is

Speaker 3: Steve Jobs that is almost diagnosed with autism. Last year in EuroPython in Edinburgh I have the opportunity to see a very wonderful presentation from a person with a very appropriate name called Ed Singleton. That presented himself as a diagnosed with autism and Asperger. And I found very brave for a person to step ahead with that. presentation that some of the people could f feel some kind of shaming.

Speaker 3: It's it's wonderful And he said that some of the characteristics that uh comply with this Set of behaviors are incidentally the same characteristics that build an excellent programmer Like pattern recognition, extreme ability to focus, attention to detail OCD can be an obsessive compulsive disorder. Okay, disorder is a woeful name, forget it about it. O CD can see very upsetting for the people around us, but it's excellent when we have

Speaker 3: to fit a bit in their exact place and not somewhere else. So next time someone talks about your personal characteristics, like oh, strange creature, don't like people. It's normal from the psychological point of view that people with extreme capability of focus feel Suddenly overwhelmed by being in the middle of lots of people or by extreme noise around us. So next time someone makes a comment about

Speaker 3: some of the peculiarities of any one of us Think about that probably it would exactly be the same that makes you an excellent programmer. And step ahead and just make strengths from what others can call a weakness. Now perhaps some of us can be can be thinking, okay, it's easy for him because he's a tall guy, mature, a senior, it's easy to be there. Let me share a little secret with you. Standing here, I'm perfectly terrified. And I have to fight myself several times to withdraw my

Speaker 3: application to the light talk. Thank you very much.

Speaker 1: Thank you very much, Raul. Okay, so uh while we get our next speaker set up. Um little back in uh Danish history about a thousand years ago there was a a big tournament between the knights of three uh neighboring kingdoms and they all came together in this big field, sort of they all came equidistant. There's sort of this big triangular field they all met in to have this uh this big competition. And um uh a big tournament competition. And one of the one of the series of nights, the the his his castle was very, very rich. And they he came with a huge posse of uh squires, like twenty different squires and wagons full of food and and supplies and what have you. And the second uh camp came in, they didn't have quite as many squires, but they still had fair few. They had like ten squires came along with horses full of all full of all their foods and supplies. We'll find out about the rest of the story in just a moment, just after Nada Alexand speaks to us.

Speaker 4: Hello. So I'll try to do this in five minutes and I will definitely fail. So we will be posting all of the code on our GitHub page very soon. And I will not go through the code, just will try to quickly go through a high-level overview. What I want to talk about is how we were able to use feature toggles in migrating models in production with zero downtime. If you already attended the workshop this morning, sorry for the repetition, but this is just a five-minute overview. Okay, so quickly, let's take a very high-level view. You start out by creating your new schema. You need an initial Synchronization script and an auto-synchronization script. The difference between the two is that one will migrate the data that already exists in the database and the other will continuously migrate data as you use both the new models and the old models at the same time.

Speaker 4: This is done so that we have zero downtime. We don't pause the production application. Then the next point is you will start adding your feature toggle switch and you will make it always use the old models at the beginning This way, again, zero downtime. Once you're done with that, you leave it up for a while while it synchronizes, and you check again after a while to make sure that nothing went wrong and they are in fact synchronized correctly. Then once you are okay with it, everything is fine, you checked it, you can switch the toggle to the new models. This way you are again in production, no downtime, using the new models. If something goes wrong, you can immediately switch back. So you can do a sanity check after a while, everything is fine.

Speaker 4: At this point you can remove the old models, remove the switch, and deploy again. Again, zero downtime. So What did we do? We made a very generic version of the initial synchronization and the auto-synchronization script. Then we created a way of basically describing the models and how they translate into each other. so that every time we want to migrate with zero downtime, all you do is just create the way that the models are described and no longer have to create any type of synchronization. Well not any type, some, but you use you make use of the synchronization script. Alright, so let's talk about what are the different types of migration, of model migration one-to-one. So one model is being translated into another new model. Another type is one model is being translated into multiple new models, and the last is the opposite.

Speaker 4: So that is a quick example of one model going to another. That is a quick example of one too many. That is a quick example of main to one. And some more examples. But but but but There's a big problem here. When I'm doing one-to-one, it's completely fine because I can use the primary key to check that the old model and the new model are the ones that match together. I mean the new instance and the old instance. But when I'm doing many to one or one-to-many, it's a big problem because I cannot use the primary key. It will duplicate. So what do I do? I create a body model. What's a body model? Just a simple model that connects the old model with the new model. What does it look like? Like this. But Okay, we go into model descriptors. So what's a model descriptor? A way to describe how a model is translated. Obviously you can read all of this code. It's quite fine because we will post all of this on GitHub and I have one minute and fifty seconds.

Speaker 4: So base class for mixins. What do we do? That is the part that is actually interesting. We create these base classes that do the synchronization for us. Okay, so I'll zoom in a little bit and ah I okay, yeah, there we go. Basically I override the leap methods and the save methods. And I add some pre and post-delete functions in case I need to run some pre or post-delete functions. Okay, uh yeah. So I'm not gonna go through the code. It's impossible to go through the code now. Okay, but uh I give you a quick uh basically a quick point is You will, whenever you're saving, you check whether you're the source model or the target model and accordingly decide to call the other instance of the new model or the old model, depending on where your toggle switch is.

Speaker 4: Then um the other interesting part is the synchronizer that might seem big but is not big. It's just simply running Three main things. One is explaining if there are any field mappings, so a field that is beating map being mapped to a new field, just the same way from the old model to the new model. But let's use source model and target model because we can be synchronizing them both ways. Then the other part is checking which fields are optional so that we do not get any errors because of something being null while we don't expect it to be null. And finally we have some field functions. Basically, when I want to translate something that is a bit more complex, let's say multiple fields being translated into one field. I have 20 seconds. I can do this. And Sorry. Um yeah, uh field functions basically give you a lot of um

Speaker 4: a lot of freedom because you got the source instance and according to it you return the value of the field that should be translated. Am I out of time? Please say no. Okay, thank you so much guys.

Speaker 1: We've got our two sets of squires, one with a very large group of squires and lots of supplies, some with not so many squires, but still a lot of supplies. The third part the third group that turned up there was a single knight and a single squire. And when he set up his uh when they came in, he came with a single beaten up pot that he had all his food in and a noose that was that he was used to tie to tie up and hang up next to the pot. The pot would be hung from a tree, the noose would be hung from a tree to to scare away any of the the raiders and bandits that might come and uh steal the food overnight Uh the story will continue right after Patrick Arminio. Thank you.

Speaker 5: 60 slides and I don't have much time. Uh so yeah, I'm a backend engineer. I live in London and originally Italian, but this doesn't really matter the talk. So I've been working on a library called Strawberry, but first of all, who's been using uh GraphQL in production or is familiar with it? So not many. So I'm gonna do like a quick introduction what it is. So let's go back for a moment and we used to have like simple web page composed by HTML documents. And we used to navigate between them using links, and then the old page will refresh. But then we start building apps and the requirement changed. So we start having single page application, mobile applications, and so on. So we start creating uh APIs to communicate between backend and clients. And we use REST, not this one, this one.

Speaker 5: Um which is basically a way to exchange data between a backend and a server using HTTP and normally JSON, but you can change the data format, I guess. Uh so yeah you would do get patch post and delete to basically do operation server. As we start to build like more complicated complex application rest didn't really scale so we started looking for something better and this something better could be GraphQL which is a specification invented by Facebook in twenty thirteen and release that was open source in twenty fifteen I think. And is a basically it's a query language allows you to Specify the data that you want, do a query on your backend and then get just the data that you want. It can be used with HTTP or WebSockets. There's only one single endpoint which uh where you can request the data that you want and looks like this.

Speaker 5: So you do a post request to slash GraphQL and And then you get the data back. So how does it look like? This is a simple query where I'm basically requesting a list of films with the title and the languages in English and then the name of the director. And then the response will be something like this. So it's basically the same. It's like a it's a JSON case with the data that you've been requested. But you can change all the data and request different data if you need something. something else. Uh why is it better? It's the clarity. So basically you are only asking for the data you want. There's no underfetching or fetching. It is typed. So basically all the schemas that you have or API they have types. So it's self-documenting, you get like IDs where you can get data and also you can get documentation. And there are some options with Python.

Speaker 5: It's gonna talk about the one I'm working on because I don't have much time. It's called Strawberry. And I'm working on because I just want to have some side project for fun and learning like new Python features and also experiment with new GraphQL features and improving the ecosystem because it's quite like GraphQL in Python is quite new, I guess So how does it work? It's based on data classes, which is if you're familiar with it, it's basically a class where you define the fields and the types all together, and then they generate init replication method equality method and so on. And we can same we can use the same approach for GraphQL. So let's see an example. So this is the schema that we have before. So we can define a type uh director uh using the decorator subari type and then define the name and this is

Speaker 5: it's the same for all the other basically all all the other uh types. Uh and we grew all together like this. I should have a demo, don't know if I have time. Uh yeah. So Yes, I'm gonna So I'm gonna define a type uh called color, then I'm gonna define a simple query, then a mutation. A mutation is basically a way to do any operation with side effects. So this one is gonna basically publish an update in into the pub sub thing you have and then return okay. And then I have a subscription which is basically a way to register an event And this one is basically gonna listen. It's gonna subscribe to the PubSub

Speaker 5: that we have, and then it's gonna listen to all the updates. It's gonna fetch the the colors and then it's gonna return for every message the the color. And Yeah, uh yeah, basically the demo is like this. Uh if you wanna uh yeah changes colors basically it's Front end is React, then backend is Python is using uh WebSocket to communicate with the GraphQL API. But yeah, it's basically done in 50 lines of code is quite nice actually with this API. Um yeah if you want to know more about this sorry too many desktops can go on survey the rocks or talk to me in person in at the conference and the sprint thank

Speaker 1: Thank you, Patrick. Uh okay, and uh so uh the the the the three sets of knights have all turned up uh and they've all come to this field and they have their first day of tournament. The end of the first day of tournament they have a great big feast as you as you do at the end of a first day of a tournament Um and uh at the end of the first uh the the that first day of feasts, uh the the first the two large sets of knights and squires, they just kind of go to bed basically. And the third the third night, the one with a single squire, he goes and hangs all the supplies left over up in the uh up in the pot with the noose next to it. Uh and the next day All the rats have gotten into the food for the other two camps, but the rats haven't gotten into the the the camp with the the the pot up in the tree. And the bandits have come and stolen what food was left over from the other two camps, but because there's a noose there they didn't go anywhere near that pot

Speaker 1: And so everyone was kind of wondering, well, uh, what does what does this teach us about uh about the squires? And uh after uh Andreas Hamershoy uh talks to us about bicycling, you'll be able to find out.

Speaker 6: But we need a Mac expert to uh fix the screen sharing to uh up there.

Speaker 7: Alright, while we do that, um I don't know anything about Django. Yeah, I don't know anything about coding actually. I'm a bike nerd and I'm here to prime you on cycling in uh Copenhagen. Now like most cities, Copenhagen has bicycle subcultures. We have We have bike polo players, we have cargo bike racers, we have uh bike warriors, we have even uh wall of death riders. But what sets Copenhagen apart is these guys, ordinary people going from A to B every day Uh in fact the bicycle has overtaken the car as a primary mode of transportation uh in Copenhagen. Uh and along with that it has also taken over uh much of the ca traffic culture usually associated with

Speaker 7: uh with cars and that means that the shortest way of explaining how to ride a bike in Copenhagen is that you should ride your bike like you're driving a car That means you stick to the right, you keep in your lane, whether you're on a street or on a bike path, stick to the right. You don't ever go in the wrong direction. Just don't do it. Completely unacceptable in Copenhagen. Also do not ride on sidewalks, pedestrian streets, or in parks It's also important to look around as you would in a car. Orient yourself. It's also important to use your indicators, but you don't have any indicators. It's a bike, so you use your arms. This is a stop sign, turn left sign, surprisingly, turn right

Speaker 7: sign. You'll see it on the streets as well. Yeah, we have those. Then once you're on the street you'll see that we have really nice bicycle infrastructure. Most of the bike lanes are like this, separated bike lanes. uh with a uh a curb between the uh the sidewalk and the and the bicycle lane and also between the street and the bicycle lane You'll also see these signs. That means you're doing it right. It indicates you're on a bicep on a bike lane. If you see it upside down, you're doing it wrong because you're in the wrong direction. These are nice to know these triangles, they're called Ushjakti. They mean that you should stop even if it doesn't say stop. So you have to yield for traffic coming from both sides.

Speaker 7: At intersections, first of all, in Danish traffic culture, traffic lights are not suggestions. Everybody will expect you to actually follow them. uh in many cases there are even these really cute little uh bike lights uh for for bikes. Um when it comes to turns Right turns are pretty straightforward as long as there are no pedestrians here you can turn right if the light is green. Left turns are a bit more complicated here um in that we don't do the left hook as you do in many other countries, mainly because there's so many bicycles in the street that it just won't work. What we do instead is that we go to the opposite corner, we wait there, when the light turns uh green, we go. Looks something like this. Lots of people waiting to turn.

Speaker 7: And there I go. When it comes to safety, I have uh three points. First point Is that statistically the most dangerous situation in Danish uh Danish and Copenhagen traffic is right-turning trucks because the drivers can't necessarily see you, so you should really have a close look at those guys If possible, try to get eye contact. Second point is use lights after dark. You can buy them all over the place, including in 7 and 11, so it's easy to get some lights. Third and final point is that cycling is super safe in Copenhagen. There's a lot of safety in numbers. Drivers are used to cyclists. In fact, we have something like four million kilometers cycle between every serious accident, so you're very likely to be safe.

Speaker 7: So my point is get on the bike, explore Copenhagen, is the best way to see the city. And that's my talk.

Speaker 1: Thank you very much. Okay, so historians are looking back on history and there's they've heard the story about these knights coming together in this triangular field with their squires. And they're wondering what can they learn from the lesson of these squires and the way they treated their food and whether where one of them had their pot in the tree with the with the noose next to it. And the lesson, really, if you think about it, it's quite simple. The squire of the high pot and noose is equal to the sum of the squares on the other two sides. I'm back tomorrow and you're gonna get another one of those. Thank you very much to our lightning talk speakers tonight uh today, Craig, Raul, Nader, Patrick, and Andreas. We will have another round of lightning talks tomorrow. If you wish to be up on here, uh

Speaker 1: present your wars, talk about what you're interested in, tell us about cycling or psychology or whatever Django project you're involved in, please go and submit a lightning talk. We'd like to have A lot more talks to pivot people don't to ch share around with us. We have one last uh uh uh speaker here to to talk about what's coming after the uh after This uh and the procedure for the rest of this evening. I will see you all tomorrow, and I hope I see everybody here bright and early tomorrow morning for day two of Django Con Europe.