Day 1 Lightning Talks

Speaker 1: Hello everyone. Um I'm Miguel. I'm gonna be talking about a little plugin that I made Um I don't know how many of you uh are aware of Cadi or use it in production, but it's uh Modern and easy to use uh web server and reverse proxy. Um one of the coolest things it provides is automatic HTTPS. It has like a configuration file called Cadi file that is super easy to use and intuitive. Also has uh an admin API which lets you update the config at runtime without needing to like restart the process or anything. And it's open source and written in Go. Well, I have

Speaker 1: a plugin called Cadi Snake. This plugin embeds the Python interpreter inside Cadi. And why did I do that? This thing that sounds crazy. It's because I wanted to avoid another layer of indirection, like another server, like G unicorn, Ubicorn, HyperCorrent, whatever you're using And I wanted to just like go extra from Cadi to your Python application and yeah leverage like the performance of this uh proxy. Basically, how it works is that the request response handlers are in Go and uses the CPython API to implement uh WISGI and ASCII protocols. So basically this is a regular uh application nowadays.

Speaker 1: You have your user, your users, they make requests to your HTTP proxy Um that goes to G unicorn for example, and G Unicorn is the thing that actually calls your Django aplication. You get that response, then G unicorn gives that response back to the reverse proxy, and then that response gets to your user. And basically, why do we even need this? Like I feel like it's an extra layer that it's in there just to so that one thing can talk to the other. And I thought maybe we can just remove it and have something like this. Uh where the user talks to the reverse proxy and the reverse proxy goes directly to the Django app, and then we get a response. So basically an example app sorry I'm using Fast

Speaker 1: API here just so it fits i in uh in a single window. Um Um yeah, for example, this uh this is an example configuration. Uh you'll have your hello world fast API endpoint here. Um and then like a super simple cuty file saying oh serve this through this Django app called main app And that will be automatically routed. You don't have to set up any other uh uh process or anything in your server. And this will get Uh automatic HTTPS support for HTTP one, two and three uh out of the box without you having to do anything So that's it. Thank you, everyone.

Speaker 2: Can you hear me? Yes, I have some helper with me. So I start with a question. Do you know where Python meets past appearation and powerful codes? Where Italy. Italy? More specific? Good. You won upon him. So Bologna. We will have a pike on Italia from 28 to 31 of May this year. And We are invited to join us, of course. With me there's Danny, Fiorella, and Sorry Raffaella. That are some of the people that help us organizing. And if you don't know, Bologna is the city of Portugal, Tortellini

Speaker 2: and Tech, of course. And you can for the code and stay for the car, so of course. And uh Let's uh give you some information about Bologna. It's uh where the oldest university in the world has been created and is still running. It's capital of the Italian cuisine and there are a lot of Towers and a lot of hand-made pasta. We have also Pathway 5 and slow food. I'll thank Ernesto for this joke that he created for us. So we'll have uh of course a lot of inspiring talks uh more than one tracks uh eighty percent of the talk will be in English and we will have a lot of great keynoteers, some of them are sitting

Speaker 2: here. I'm just Looking. More than one. Okay, we also have more than one social event. We have Pie Drink Nights. Uh where you can drink whenever you want. We have pie dinner. Pie dinner, where we you can test local uh foods and we also have a party night. And okay, we are a lot of friendly communities uh also from the local uh meetups and we have real espresso for free during the Okay, you can still get your tickets. Uh we are reaching 900 at this moment. Uh last year we have forced to uh stop selling because we sold out

Speaker 2: so we you still have some weeks to buy something. Yeah, these are things. But additionally, we will have also another interesting thing for Django community. Because we have in the first day, the 28th of May, we will have a free day for a beginner workshop. We will have a session for Django. The name is Django Notes. And as you can see, we will have um a similar session we just had here in in Dublin about DSF, Django Girls, and Django Now to Space program with uh uh me, Sarah, Shina and Rafaela. And if

Speaker 2: you want to attend uh it's free. You don't need the ticket for the conference. So if you are around you can join us. you only have to compile this uh this form. And if you are very interested you can scan the QR code and um Uh it's working. And before you go away, we take of course the last uh selfie with all of you. And we hope that we'll Take this picture again in in Bologna maybe. She's taking a photo. Yeah, yeah. She's my I need to take herself in it. It's important And

Speaker 2: bye man. And thank you. We wait for you in Bologna Bye.

Speaker 3: Hey everyone, I'm Sage. I'm a Courtney member of White Tail, so today I want to talk about White Tail So RightTail is a content management system built on Django. We've been around for a while, around 11 years now, so we're quite established. And our approach is to have a CMS that's data oriented using Django models. So as a Django dev, you'll feel right at home as you would with any Django project. And we heavily focus on making our admin interface modern with a lot of useful features that you can use with any Django model. So you can start a new project with Wagtail or integrate an existing Django project. Um integrate Wagtail into your existing Django project

Speaker 3: because Wagetel is just like an external Django package, like any other. And just a quick disclaimer: I work for a company called Torchbox. We are based in the UK and they pay me to work on Whitetail and also to be here. So thank you, Torchbox. And now to show you what Whiteel looks like. So this is WhiteTel's dashboard that you would see after logging in. And this is the page editor. We have features like live preview. And also things like drafts and publishing. And we are also committed to accessibility, so you get an accessibility checker

Speaker 3: right out of the box And among other cool features. Right now we are looking at a white tail page model. So in this case we have a model field called stream field that lets you write your content with different building blocks that you can um pick and choose from. So for example, a block called hello. Yep. Yeah. But you can use these features with any Django model. So here I am editing a basic person model. And yeah, so I can also have uh things like previews and accessibility checker

Speaker 3: and so on with any Django model. So Let's go back to the slides. Yeah, so try out Wiktail today. You can use our starter kit that we just released recently. We can scan the QR code or you can also play around with our Bakery demo or create a new project and follow the tutorial in our docs. If you want to learn more about Whitetail, we're doing a meetup tomorrow, so please join us for a coffee break at 4:15 tomorrow in the workshops room. And here is where you can find us on social media. And that's it. Thank you.

Speaker 4: B. Uh, you may or may not already know, but Postgres Europe recently created a diversity task force. But why Who's behind it? What are we doing? And more importantly, what on earth does that have to do with you as a Django developer? First, briefly, what is diversity? In a nutshell, variety, in particular, having a variety of different people in any group or organization. And diversity is about more than gender or ethnicity, although of course those are important. It's also about things like your work experience, how um and where you grew up, the language you speak and much, much more. There are so many different attributes that make each of us unique and that bring variety to our communities.

Speaker 4: So, why do we have this diversity task force? It's no secret that there are challenges in terms of diversity across the entire tech industry, and the Postgres and Django projects are no exception. But diversity has been shown to be good for everybody. We know that diverse people bring unique skills and viewpoints which make our projects better for all of us. Just one example of the importance of diversity. When the team organizing an event looks like this, and this is a recent example. Uh and when the speaker lineup looks like this, it's easy to understand why not everyone feels represented or included. It's easy to see why we might unconsciously be giving more opportunities to people like us and constantly reinforcing our existing biases.

Speaker 4: So the idea of the Diversity Task Force isn't to criticize these organization teams, their volunteers who are generously giving up their time. but to help them provide them with resources, guidelines , and tools that they need. So it's about reaching out to and bringing in more people. uh creating more seats at the table and definitely absolutely not about pushing out the amazing people who are already there. It's really important to us that everybody feels welcome, represented, and valued within our community. And I know that the Django community has a lot to teach us Postgres folks. So who's working on this? This is the PGEU Diversity Committee, so we've been doing the initial work to put things in place.

Speaker 4: I'm chairing the committee. Stacy Hazler from Postgres US has joined us as an advisor. And we've got Flavio, Valeria, Flor, Jimmy, and Stephanie working with us. But diversity and inclusion obviously can't just be implemented by a committee or a task force. Everybody in the community has a role to play. And if you're a Postgres user, you are part of the Postgres community. So congratulations and welcome. We would love you to get involved. We'd love to hear what you're doing. And we're here to help you if there's anything we can do for you. What have we done so far and what are our plans? As with any project, we know we need SMART goals, specific, measurable. Attainable, relevant, and time-bound.

Speaker 4: And as data people, we know that we need stats to show where we're starting from and to measure our progress. So we're working on collecting the information that we need to do that A lot of the work we've done so far has been behind the scenes research, setting up infrastructure, planning, budgeting, creating a logo and shiny stickers. I do have a few of those with me. But we've also distributed entry tickets for various events. We've started to create a scholarship scheme. We set up the first diversity celebration board at PGConfiU last year. And we've updated and shared guidelines for CFP committees. We've got loads of ideas and plenty of things that we want to do, but detailed plans for the future are still being shaped by feedback from the community and requests from people.

Speaker 4: We're also joining forces with and learning from other groups both within the Postgres community and beyond. So hopefully that will include people from the Django community So how can you help us? This slide lists just some of the everyday things that we can all do to make people feel welcomed and valued in our communities. And I know that a lot of you already do a lot of those things. And these are a few suggestions of specific things that you can do to get involved and join us. You can email us your diversity-related ideas, questions, and comments, or join our Telegram group You can come to PGEU events as an attendee or better still as a speaker. You can become a PGEU member, so it's only 10 euros every two years. and maybe even volunteer to help us to maintain and improve our back-end

Speaker 4: system. We are database people, not Django developers and it shows. Find out more about the task force on the PGU website and follow us on social media to find out more. Thank you very much.

Speaker 5: Okay.

Speaker 6: So I'm Alyssa. I uh work at Unas and a Wolf. Um you can find us at jovo. de. I'm a DevOps engineer, and today I want to talk about review apps. So um we have a certain development process as a consultancy company and this basically means that for each feature branch that we are developing on. It first starts with a requirement analysis, then things get developed, and then there comes this whole process of testing the code, reviewing it. If that works then we need to do some internal quality assurance And afterwards, there needs to be an acceptance by our customer before we can actually match the changes. And I've highlighted here the steps that actually need running instances of the software we're developing on.

Speaker 6: So of course during development, the developer will have their own setup. Um then during testing there may or may not be an instance required for that, but um the quality assurance and the acceptance by the customer also need the application with the changes that are relevant here to be present and available. And this is an issue because like it's time sometimes really complex to deploy the software But um the quality assurance and the customer may not be the people who are able to deploy it. And this is why we use Reaver Apps. Which basically a review app is an instance of the application that is for a specific branch and running on a server that is available for ourselves and also for our customers.

Speaker 6: So this is usually available at some domain that is based on the branch name. And this automatically gets deployed whenever we change the code and uses basically the same Docker images we use anyways for production. And the special thing here is that we just built the images anyway, so we can also use them for this quality assurance process. So for this we have an internal tool called Stackbot that m currently mostly acts as a CI CD command Which um uses a special purpose GitLab runner in our CI CD pipeline that then calls the stackboard commands. And this can basically do things like deploy a new UV app for a certain branch or update it or Reset the database

Speaker 6: because after an error the database may be in a weird state or something, or also remove it when the development is done. And one also important thing is that it uses a special template database that will be imported whenever we start a new Ruby app. So the integration um into the process of this is that for each project we need to do some changes to StackBot. It's more like a framework. So we need to implement things like where to find the repositories and how they are connected to each other because we have maybe different back-end and front-end repositories. Uh it needs to fill in a template for Docker Compose or like config files and stuff and also It needs maybe to run some commands on initializ

Speaker 6: initialization, like create the default users that we want to use for the specific review app. And it then um has a workflow where it checks if the branch exists. If there's multiple repositories, it needs to check check on each repository and then select either the default or the specialized repository for each branch. It uh needs then to fetch a Docker Compose. yaml template and fill in some variables that are specific for the Weaver app. It needs to pull the Docker images and then it needs to control the Docker stack locally and start it and stop the Docker containers as needed. And to make this available then to the network, we use traffic as a reverse proxy, which comes in really handy here

Speaker 6: because we can configure traffic for like each branch Like um traffic just is configured via Docker c labels. And one thing that we noticed here is that uh it's maybe you have noticed that we're running all of this on a single server with about a hundred active feature branches at a time, which also means that we have a hundred instances of our application that we are developing, which is not like it's not that lightweight actually. But it just works with a server that has sixteen CPUs and sixty-four gigs of RAM. Um because if we disable the salary workers then most of these apps are not really used. Like they are available if someone comes in the process to use them, but most of the time they are just inactive.

Speaker 6: So almost all the memory footprint will be just um offloaded to the swap and not be touched for a week or two or something. And also they don't really consume any CPU unless they are actively accessed And yeah, this was it. Did you get that?

Speaker 5: Sure. So yeah, this side of the prototalk, uh, it will overlap a lot with the talk this morning around migrations, which is interesting. Uh but yeah, we'll talk about two ways we've run no ports to two and a half companies, um so safer and migration with Django. Um so specifically against something around avoiding what we called odd migration in in my company, which will migration that will break production, essentially, break live code. Uh which is not a problem, you know, when you start small, but every one of us got to some point where you got something like called business continuity, which means you can't take down production when you do schema changes. And so that's going to be things like I've been talking about this morning, you know, locks, uh, blocking your databases. But it could be simple things like deleting

Speaker 5: model. If your code is still using that model live, goes down. So how essentially the two methods I'm talking about. The first one is identifying what makes a hard migration. So one way to do that is just knowing it is reviews and you know seeing the migration and going, this is gonna take down production, you should do it differently. You can also do analysis about it. So I'll show an example with Django checks later. And the solution, as explained this morning in the talk, is essentially you decompose your migrations into kind of stage stages that you can run in multiple steps. So you know you do add add a new column, delete it later kind of things. With Django, so the true approach we can use. So

Speaker 5: Django checks are pretty good for this kind of thing. And I don't know who uses Django checks in production in the sense of what's written custom Django checks here. Maybe a quick show of hands Yeah. Not many. In general we should always use them more. They're pretty great and um they're actually built in. Um so as I said, they provide like access to fully initialized Django. So that gives you access to all the machinery around apps. I don't have the slides here as well, so it's not very prepared, sorry about that. And so for example, here is a check that we do for Yeah, it's not very readable. But this one essentially goes and tries to check all the migrations for the names and go you haven't named it properly. We're not going to know what to do with it

Speaker 5: You can do other things that once you've upnamed them as we do. So the way we do it is that we identify what we call pre-migration. So you deploy that before the code goes live and a post-migration, so after the code goes live. We put that in a name, very simple. And so once you know which one it is, you can essentially go, oh, there is a delete model thing in that pre-migration that is generally unsafe. It might be for your case, but generally we don't know. So don't do that. And that's a Django check, so it's going to run locally, it's going to run the CI. And IDDs come into production before you're on the megations. So once we've got this kind of things , So you've identified which migration is safe, unsafe. You've decomposed them in pre and post steps. You do need to update your release process. And again, Django gives you all the tool there, which is pretty useful.

Speaker 5: But show migrations plans essentially will give you the list of migrations are planning and the dependencies potentially. So rather than doing like she started a naive release process, looks like this Running migration, release, poof, we do some nose check. Not you know, at some point we'll start getting there. And then you start moving to something like this. Um so Iterate over the pre-migrations, run them, run your release code, hopefully at this point nothing broke, then do the post-migrations. Doesn't have to be this. This is a rough version for the presentation, but you can think I see that here. Like you can use all the jingle machinery to do like a much smarter migration runner if you need to. You can do the full plan as well, which will give you all the two

Speaker 5: tools to build the tree And that essentially solved that problem of if people are just working on features and focusing on the schema challenges, it's easy to make mistakes, it's easy to delete a model and not realize it's gonna break the code. This automates all of that uh away essentially. Um which means that's what I just talked about. It doesn't really touch the promo scale that was presented this morning. If it's gonna take hours to run your migration, you still don't want them like just running in CI anyway. This is just about how you structure them. For simple cases, works great. Complex cases, you're going to need a bit more. Again, talks this morning was pretty great about that. Uh yeah, that's it for the talk.

Speaker 7: Uh that's it for today. We've reached the end of day one or day zero you choose. So see you tomorrow at nine o'clock Yeah, bye.