DjangoCon Europe 2019 - Lightning Talks Day 1
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Anderson, Craig
Alexan, Nader
Patrick, Arminio
Hammershoj, Andreas
Keith-Magee, Russell
et al.
Anderson, Craig - Introducing Black Alexan, Nader - The use of feature toggles in migrating models in order to prevent maintenance downtime in production Arminio, Patrick - Strawberry Hammershoy, Andreas - Cycling in Copemnhagen et al.
 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 Zecklins. 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. See if maybe it's next year around when the call for papers comes up if you want to get involved. The key thing about lightning talks though is we say it's five minutes, there is a five minute limit. There will be a five minute timer down the bottom here. When that timer runs out, the time is out. Maybe 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. Thank you very much. So people who do not know what black is in the Python package, can you raise your hand? Okay. So there are some people here. Okay. And hopefully if you work with teams, this will make your life a bit better. Yeah. So I am Craig. There is like Twitter and a website. You can find out more about me if you want to get in touch. Please do. So yes, black is a Python auto-format. It will help you kind of basically avoid the situation. Yeah, this phone thing is not going to work for me. Yeah. It will avoid the situation of bike shedding. Now if you're unfamiliar with what bike shedding is, it's basically the tendency for a technical team to just get bogged down in a lot of unnecessary technical, 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 color that it's painted. So yeah, why is this important? So you can use Pepe8 and Pepe8 is great. Of course, hopefully we're all using that. But it doesn't kind of go to the kind of minutia details of exactly how a lot of your code should be formatted. So you might end up with lots of pull requests that look like this, which is the exact same functional code, but just somebody is preferring one style over another. So yeah, that's one way you can go. You can also kind of go to the and come up with your own formatting guidelines. That can be difficult to come up with. It 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 this line length or my colleague prefers a longer line length. So Black kind of 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, massive code. 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. Yeah, and Pepe8 compliant. Except whenever I've shown this to developers 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, so the time's actually turned off. Oh, and it stopped. Cool. I can go forever. Yeah, but like, you know, 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, I prefer single quotes over double quotes. Basically, like, you know, what Black is saying to you is that, yeah, you know, you give up that control and the advantage that you get is all of a sudden that you're just kind of you're freed from all of this, 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're looking to read me, 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 funny was actually a better idea than what I thought. And yeah, and there's me again, and thank you very much for your time. Which robs me of my opportunity, I usually fill the space in between here with a little bit of a story. I do have an interesting piece of history about Denmark that I've discovered just having arrived here in the first time. But I will now invite to the stage our next speaker, Raul Tavares, who is going to speak without slides. So, second thing you can know about Lightning Talk, you don't have to use slides. Hello, fellow Django Naut. Thank you for being here. Before I begin, 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 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. Users 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, fictional character that is Sheldon Cooper from Big Bang Theory. What a very real one that is Steve Jobs that is almost diagnosed with autism. Last year in a European head in Borough, I had the opportunity to see a very wonderful presentation from a person with a very appropriated name called Ed Singleton that presented the 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 feel some kind of a shaming. It's wonderful. And he said that some of the characteristics that comply with this set of behaviors are incidentally the same characteristics that build an excellent programmer like pattern recognition, extramability to focus, attention to detail. OCD can be obsessive-compulsive disorder. Okay, disorder is a awful name, forget about it. OCD can see very upsetting for the people around us, but it's excellent when we have to fit a bit in that exact place and not somewhere else. So next time someone talk about your personal characteristics like a strange creator 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 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 a strength from what others can call a weakness. Now perhaps some of us 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 application to the light talk. Thank you very much. Thank you very much Raul. Okay, so while we get our next speaker set up, a little back in Danish history about a thousand years ago there was a big tournament between the Knights of three neighbouring kingdoms. They all came together in this big field, sort of they all came equidistant, sort of this big triangular field, they all met in to have this big competition. And a big tournament competition. And one of the series of Knights, his castle was very, very rich and he came with a huge posse of squires, like 20 different squires and wagons full of food and supplies and what have you. And the second camp came in, they didn't have quite as many squires but they still had a fair few, like 10 squires came along with horses full of all their foods and supplies. We'll find out about the rest of the story in just a moment, just after Nader Alexander speaks to us. Thank you very much. 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. 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. You can do a sanity check after a while. Everything is fine. At this point, you can remove the old models, remove the switch and deploy again. Again, zero downtime. 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 make use of the synchronization script. Let's talk about what are the different types of model migration. 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. So that is a quick example of one model going to another. That is a quick example of one to many. That is a quick example of many to one. And some more examples. But, but, but, but, there is 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 one step match. 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? What's a body 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? I'll wait to describe how a model is translated. Obviously you can read all of this code. But anyways, it's quite fine because we will post all of this on GitHub and I have one minute and 50 seconds. 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, 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. Yeah. So I'm not going to go through the code. It's impossible to go through the code now. Okay. But, ah, I give you a quick, 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. Then, ah, the other interesting part is the synchronizer. That might seem big, but it's not big. It's just simply running three main things. One is explaining if there are any field mappings, so a field that is 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 in 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 that say multiple fields being translated into one field. I have 20 seconds. I can do this. And, sorry, um, yeah, field functions basically give you 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. Thank you very much, Nader. Okay. Well, we're next week to get set up. 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 group that turned out there was a single night on a single squire. And when he set up his, when they came in he came with a single beaten up pot that he had all his food in and a noose that he was used 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 scare away any of the raiders and bandits that might come and steal the food overnight. The story will continue right after Patrick Aminio. Thank you. So, everyone, I'm going to be really quick because this talk is like six slides and I don't have much time. So, yeah, I'm a backend engineer, I live in London and I'm originally from Sicily and this doesn't really matter. So, I've been working on a library called Strawberry but first of all who's been using Graphical and Production or is familiar with it? So, not many. So, I'm going to 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 requirements changed. So we start having single project application, mobile applications and so on. So we start creating APIs to communicate between backend and clients and we use REST, not this one, this one. It's basically a way to exchange between a backend and a server using HTTP and normally JSON but you can change the data format, I guess. So yeah, you would do get, patch, pause and delete to basically do operation server. As we start to build like more complex application, REST in really scale. So we start looking for something better and this is something better could be GraphQL which is a specification invented by Facebook in 2013 and REST open source in 2015, I think. And 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. You can use HTTP or WebSockets. There's only one single endpoint where you can request the data that you want and looks like this. So you do a post request to GraphQL and then you get data back. So what does it look like? This is a simple query where I'm basically requesting a list of films with a title and the language is 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 JSON, this case, with the data that you've been requested. But you can change all the data and request different data if you need something else. What is it better? It's the clarity. So basically you are only asking for the data you want. There's no under fetching. It's typed, so basically all the schemas that you have are API type. So it's self-documenting. You get ideas where you can get data and also you can get documentation. And there are some options with Python. I'm going to talk about the one I'm working on because I don't have much time. It's called Strawberry. And I'm working on it because I just want to have some side project for fun and learning like new Python features. And 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 altogether. And then generate any application method, equality method and so on. And 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 director using the decorator as a very type and then define the name. And this is the same for all the other types. And we grow all together like this. I should have a demo. I don't have time. So I'm going to define a type called color. And I'm going to define a simple query. Then a mutation. A mutation is basically a way to do any operation with side effects. So this one is going to basically publish an update into the PubSub thing you have and then return okay. Then I have a subscription, which is basically a way to register an event. And this one is basically going to listen. It's going to subscribe to the PubSub that we have and then it's going to listen to all the updates. It's going to fetch the colors and then it's going to return for every message the color. And yeah, basically the demo is like this. If you want to change its colors, basically it's front end is react and back end is Python. It's using WebSock and to communicate with the GraphQL API. But yeah, it's basically done in 59 so called. It's quite nice actually with this API. And if you want to know more about this, so too many desktops can go on, survey the rock. So talk to me in person at the conference under the screen. Thank you. Thank you, Patrick. Okay. And so the three sets of nights have all turned up 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 do at the end of the first day of tournament. And at the end of the first day of feasts, the two large sets of nights and squires, they just kind of go to bed basically. And the third night, the one with the single squire, he goes and hangs all the supplies left over up in the pot with the noose next to it. 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 camp with 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. And so everyone was kind of wondering, well, what is this teacher's about the squires? And after Andreas Hammershoeg talks to us about bicycling, you'll be able to find out. So we need a Mac expert to fix the screen sharing of that. All right. Why do we do that? 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 your encycling in Copenhagen. Now, like most cities, Copenhagen has bicycle subcultures. We have bike polo players. We have cargo bike racers. We have bike warriors. We have even a wall of death riders. But what sets Copenhagen apart is these guys, ordinary people going from A to B every day. In fact, the bicycle is overtaking the car as a primary mode of transportation in Copenhagen. And along with that, it has also taken over much of the traffic culture usually associated 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 the 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 put 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 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 with a curve between the sidewalk 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 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 shark teeth. They mean that you should stop even if it doesn't say stop, so you have to yield for traffic coming from both sides. At intersections, first of all, in Danish traffic culture, traffic lights are not suggestions. Everybody will expect you to actually follow them. In many cases, there are even these really cute little bike lights for bikes. 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 in that we don't do the left hook as you do in many other countries, mainly because there are so many bicycles in the street that it just won't work. What we're doing instead is that we go to the opposite corner. We wait there. When the light turns green, we go. Looks something like this. Lots of people waiting to turn and there I go. When it comes to safety, I have three points. First point is that statistically the most dangerous situation in 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-11, so it's easier 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 4 million kilometers cycle between every serious accident, so you're very likely to be safe. My point is get on the bike, explore Copenhagen. It's the best way to see the city. That's my talk. Thank you very much. Historians are looking back on history and they've heard the story about these nights 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 where one of them had their pot in the tree with the news next to it. The lesson really, if you think about it, is quite simple. The squire of the high pot and noose is equal to the sum of the squires on the other two sides. I'm back tomorrow and you're going to get another one of those. Thank you very much to our Lightning Talks speakers today. Craig, Raul, Nader, Patrick and Andreas. We will have another round of two Lightning Talks tomorrow. If you wish to be up and here, present your wares, talk about what you're interested in, tell us about cycling or psychology or whatever Django projects you're involved in. Please go and submit a Lightning Talk. We'd like to have a lot more talks that people would like to share around with us. We have one last speaker here to talk about what's coming after this 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 DjangoCon Europe. Thank you.
 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 Zecklins.  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.  See if maybe it's next year around when the call for papers comes up if you want to get  involved.  The key thing about lightning talks though is we say it's five minutes, there is a five  minute limit.  There will be a five minute timer down the bottom here.  When that timer runs out, the time is out.  Maybe 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.  Thank you very much.  So people who do not know what black is in the Python package, can you raise your hand?  Okay.  So there are some people here.  Okay.  And hopefully if you work with teams, this will make your life a bit better.  Yeah.  So I am Craig.  There is like Twitter and a website.  You can find out more about me if you want to get in touch.  Please do.  So yes, black is a Python auto-format.  It will help you kind of basically avoid the situation.  Yeah, this phone thing is not going to work for me.  Yeah.  It will avoid the situation of bike shedding.  Now if you're unfamiliar with what bike shedding is, it's basically the tendency for a technical  team to just get bogged down in a lot of unnecessary technical, 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 color that it's painted.  So yeah, why is this important?  So you can use Pepe8 and Pepe8 is great.  Of course, hopefully we're all using that.  But it doesn't kind of go to the kind of minutia details of exactly how a lot of your code should  be formatted.  So you might end up with lots of pull requests that look like this, which is the exact same  functional code, but just somebody is preferring one style over another.  So yeah, that's one way you can go.  You can also kind of go to the and come up with your own formatting guidelines.  That can be difficult to come up with.  It 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 this line length or my colleague prefers a longer  line length.  So Black kind of 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, massive code.  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.  Yeah, and Pepe8 compliant.  Except whenever I've shown this to developers 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, so the time's actually turned off.  Oh, and it stopped.  Cool.  I can go forever.  Yeah, but like, you know, 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, I prefer single quotes over double  quotes.  Basically, like, you know, what Black is saying to you is that, yeah, you know, you give up  that control and the advantage that you get is all of a sudden that you're just kind of  you're freed from all of this, 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're looking to read me, 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 funny was actually a better  idea than what I thought.  And yeah, and there's me again, and thank you very much for your time.  Which robs me of my opportunity, I usually fill the space in between here with a little  bit of a story.  I do have an interesting piece of history about Denmark that I've discovered just having  arrived here in the first time.  But I will now invite to the stage our next speaker, Raul Tavares, who is going to speak  without slides.  So, second thing you can know about Lightning Talk, you don't have to use slides.  Hello, fellow Django Naut.  Thank you for being here.  Before I begin, 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 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.  Users 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, fictional character that is Sheldon Cooper from Big Bang Theory.  What a very real one that is Steve Jobs that is almost diagnosed with autism.  Last year in a European head in Borough, I had the opportunity to see a very wonderful  presentation from a person with a very appropriated name called Ed Singleton that presented the  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 feel some kind of a shaming.  It's wonderful.  And he said that some of the characteristics that comply with this set of behaviors are  incidentally the same characteristics that build an excellent programmer like pattern  recognition, extramability to focus, attention to detail.  OCD can be obsessive-compulsive disorder.  Okay, disorder is a awful name, forget about it.  OCD can see very upsetting for the people around us, but it's excellent when we have  to fit a bit in that exact place and not somewhere else.  So next time someone talk about your personal characteristics like a strange creator 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 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 a strength from what others can call a weakness.  Now perhaps some of us 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 application to the light talk.  Thank you very much.  Thank you very much Raul.  Okay, so while we get our next speaker set up, a little back in Danish history about  a thousand years ago there was a big tournament between the Knights of three neighbouring  kingdoms.  They all came together in this big field, sort of they all came equidistant, sort of  this big triangular field, they all met in to have this big competition.  And a big tournament competition.  And one of the series of Knights, his castle was very, very rich and he came with a huge  posse of squires, like 20 different squires and wagons full of food and supplies and  what have you.  And the second camp came in, they didn't have quite as many squires but they still had  a fair few, like 10 squires came along with horses full of all their foods and supplies.  We'll find out about the rest of the story in just a moment, just after Nader Alexander  speaks to us.  Thank you very much.  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.  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.  You can do a sanity check after a while.  Everything is fine.  At this point, you can remove the old models, remove the switch and deploy again.  Again, zero downtime.  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 make use of the synchronization script.  Let's talk about what are the different types of model migration.  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.  So that is a quick example of one model going to another.  That is a quick example of one to many.  That is a quick example of many to one.  And some more examples.  But, but, but, but, there is 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 one step match.  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?  What's a body 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?  I'll wait to describe how a model is translated.  Obviously you can read all of this code.  But anyways, it's quite fine because we will post all of this on GitHub and I have one  minute and 50 seconds.  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, 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.  Yeah.  So I'm not going to go through the code.  It's impossible to go through the code now.  Okay.  But, ah, I give you a quick, 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.  Then, ah, the other interesting part is the synchronizer.  That might seem big, but it's not big.  It's just simply running three main things.  One is explaining if there are any field mappings, so a field that is 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 in 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 that say multiple fields being translated into one field.  I have 20 seconds.  I can do this.  And, sorry, um, yeah, field functions basically give you 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.  Thank you very much, Nader.  Okay.  Well, we're next week to get set up.  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 group that turned out there was a single night on a single squire.  And when he set up his, when they came in he came with a single beaten up pot that he  had all his food in and a noose that he was used 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 scare away any  of the raiders and bandits that might come and steal the food overnight.  The story will continue right after Patrick Aminio.  Thank you.  So, everyone, I'm going to be really quick because this talk is like six slides and I  don't have much time.  So, yeah, I'm a backend engineer, I live in London and I'm originally from Sicily and  this doesn't really matter.  So, I've been working on a library called Strawberry but first of all who's been using  Graphical and Production or is familiar with it?  So, not many.  So, I'm going to 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 requirements changed.  So we start having single project application, mobile applications and so on.  So we start creating APIs to communicate between backend and clients and we use REST, not this  one, this one.  It's basically a way to exchange between a backend and a server using HTTP and normally  JSON but you can change the data format, I guess.  So yeah, you would do get, patch, pause and delete to basically do operation server.  As we start to build like more complex application, REST in really scale.  So we start looking for something better and this is something better could be GraphQL  which is a specification invented by Facebook in 2013 and REST open source in 2015, I think.  And 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.  You can use HTTP or WebSockets.  There's only one single endpoint where you can request the data that you want and looks  like this.  So you do a post request to GraphQL and then you get data back.  So what does it look like?  This is a simple query where I'm basically requesting a list of films with a title and  the language is 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 JSON, this case, with the data that you've been requested.  But you can change all the data and request different data if you need something else.  What is it better?  It's the clarity.  So basically you are only asking for the data you want.  There's no under fetching.  It's typed, so basically all the schemas that you have are API type.  So it's self-documenting.  You get ideas where you can get data and also you can get documentation.  And there are some options with Python.  I'm going to talk about the one I'm working on because I don't have much time.  It's called Strawberry.  And I'm working on it because I just want to have some side project for fun and learning  like new Python features.  And 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 altogether.  And then generate any application method, equality method and so on.  And 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 director using the decorator as a very type and then define the  name.  And this is the same for all the other types.  And we grow all together like this.  I should have a demo.  I don't have time.  So I'm going to define a type called color.  And I'm going to define a simple query.  Then a mutation.  A mutation is basically a way to do any operation with side effects.  So this one is going to basically publish an update into the PubSub thing you have and  then return okay.  Then I have a subscription, which is basically a way to register an event.  And this one is basically going to listen.  It's going to subscribe to the PubSub that we have and then it's going to listen to all  the updates.  It's going to fetch the colors and then it's going to return for every message the color.  And yeah, basically the demo is like this.  If you want to change its colors, basically it's front end is react and back end is Python.  It's using WebSock and to communicate with the GraphQL API.  But yeah, it's basically done in 59 so called.  It's quite nice actually with this API.  And if you want to know more about this, so too many desktops can go on, survey the rock.  So talk to me in person at the conference under the screen.  Thank you.  Thank you, Patrick.  Okay.  And so the three sets of nights have all turned up 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 do at the end  of the first day of tournament.  And at the end of the first day of feasts, the two large sets of nights and squires, they  just kind of go to bed basically.  And the third night, the one with the single squire, he goes and hangs all the supplies  left over up in the pot with the noose next to it.  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 camp with 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.  And so everyone was kind of wondering, well, what is this teacher's about the squires?  And after Andreas Hammershoeg talks to us about bicycling, you'll be able to find out.  So we need a Mac expert to fix the screen sharing of that.  All right.  Why do we do that?  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 your encycling in Copenhagen.  Now, like most cities, Copenhagen has bicycle subcultures.  We have bike polo players.  We have cargo bike racers.  We have bike warriors.  We have even a wall of death riders.  But what sets Copenhagen apart is these guys, ordinary people going from A to B every day.  In fact, the bicycle is overtaking the car as a primary mode of transportation in Copenhagen.  And along with that, it has also taken over much of the traffic culture usually associated  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 the 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 put 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 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 with a curve between the sidewalk  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 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 shark teeth.  They mean that you should stop even if it doesn't say stop, so you have to yield for  traffic coming from both sides.  At intersections, first of all, in Danish traffic culture, traffic lights are not suggestions.  Everybody will expect you to actually follow them.  In many cases, there are even these really cute little bike lights for bikes.  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 in that we don't do the left hook as you  do in many other countries, mainly because there are so many bicycles in the street that  it just won't work.  What we're doing instead is that we go to the opposite corner.  We wait there.  When the light turns green, we go.  Looks something like this.  Lots of people waiting to turn and there I go.  When it comes to safety, I have three points.  First point is that statistically the most dangerous situation in 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-11, so it's easier 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 4 million kilometers cycle between every serious accident,  so you're very likely to be safe.  My point is get on the bike, explore Copenhagen.  It's the best way to see the city.  That's my talk.  Thank you very much.  Historians are looking back on history and they've heard the story about these nights  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 where  one of them had their pot in the tree with the news next to it.  The lesson really, if you think about it, is quite simple.  The squire of the high pot and noose is equal to the sum of the squires on the other two  sides.  I'm back tomorrow and you're going to get another one of those.  Thank you very much to our Lightning Talks speakers today.  Craig, Raul, Nader, Patrick and Andreas.  We will have another round of two Lightning Talks tomorrow.  If you wish to be up and here, present your wares, talk about what you're interested in,  tell us about cycling or psychology or whatever Django projects you're involved in.  Please go and submit a Lightning Talk.  We'd like to have a lot more talks that people would like to share around with us.  We have one last speaker here to talk about what's coming after this 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 DjangoCon Europe.  Thank you.
DjangoCon_2019_-_Day_1_Lightning_Talks_0_2051.png DjangoCon_2019_-_Day_1_Lightning_Talks_2052_9239.png DjangoCon_2019_-_Day_1_Lightning_Talks_9240_9719.png DjangoCon_2019_-_Day_1_Lightning_Talks_9720_9899.png DjangoCon_2019_-_Day_1_Lightning_Talks_9900_11879.png DjangoCon_2019_-_Day_1_Lightning_Talks_11880_12095.png DjangoCon_2019_-_Day_1_Lightning_Talks_12096_13139.png DjangoCon_2019_-_Day_1_Lightning_Talks_13140_13427.png DjangoCon_2019_-_Day_1_Lightning_Talks_13428_14159.png DjangoCon_2019_-_Day_1_Lightning_Talks_14160_14339.png DjangoCon_2019_-_Day_1_Lightning_Talks_14340_15539.png DjangoCon_2019_-_Day_1_Lightning_Talks_15540_23879.png DjangoCon_2019_-_Day_1_Lightning_Talks_23880_31295.png DjangoCon_2019_-_Day_1_Lightning_Talks_31296_31619.png DjangoCon_2019_-_Day_1_Lightning_Talks_31620_32495.png DjangoCon_2019_-_Day_1_Lightning_Talks_32496_32867.png DjangoCon_2019_-_Day_1_Lightning_Talks_32868_33059.png DjangoCon_2019_-_Day_1_Lightning_Talks_33060_36539.png DjangoCon_2019_-_Day_1_Lightning_Talks_36540_37799.png DjangoCon_2019_-_Day_1_Lightning_Talks_37800_39899.png DjangoCon_2019_-_Day_1_Lightning_Talks_39900_43223.png DjangoCon_2019_-_Day_1_Lightning_Talks_43224_43276.png