Lightning Talks Day 2

Speaker 1: Thank you everyone. I I'm John and I'm going to talk to you very quickly about Django Social. You may have seen on some of the uh the boards and things about Django Social being associated with the parties and the boat cruises and maybe have wondered a little bit actually what is this thing. Up until last night you may have checked the actual website, it wasn't working. We fixed it in the pub last night, so it's now there. Um Essentially Django Social is uh a really easy to run low admin social event for the Django community. Um It came came about a little bit because of the the lack of in-person interaction at the end end of the pandemic and as coming out of all COVID restrictions, the

Speaker 1: Just wanting to be around people where teams have now distributed away from maybe the cities you're in and friendship groups have also moved away and trying to use Django as the common interest, the conversation started to bring people back together The idea for it came, I went like uh earlier this year to Copenhagen to the Django Day event there. Brilliant event and on the way home just reflecting it was like how nice it was to be back in and around people. Um We a month later decided as she would meet up for a walk in the park. This is how simple Django Social can be. We went met for a walk. We did a a lap of Regents Park in in London

Speaker 1: and then went to the pub for some drinks. You might see a few faces in the middle photo there. You recognise we have also been um for a we had a summer party, the only night in the whole English summer that it rained. And we also have met for a picnic. Now these aren't very glamorous things, but we've had a good group of people every time, chatted Django, renewed some old friendships, made some new ones, which is just the most important thing. Why do I want to keep it simple? Actually I suppose a couple of reasons. London's already got some great meetups, the Dojos, the Django meetup , and lots going on. Um I think Kojo said yesterday in the keynote actually organising uh events which I've done for ten

Speaker 1: years previously it's it's quite it is a hell of a lot of effort and it's it's time consuming and it's uh hard work and so yeah testament to anyone who does a proper meetup with speakers and venues and everything every time it's yeah hat off to you. Um and actually a lot of people go for or attend meetups for the socializing part, the bit before the talks, the bit after the talks. So yeah, essentially the story of it. I uh was talking to the organizer about sponsoring uh DjangoCon and They we had a conversation about Django Social, but they were like we can't find anything else about it. You tell us about it. So I've had a a simple, as I said, website that only started working yesterday built.

Speaker 1: And part of the the process we built some test groups on meetup. com for different regions other than London we test tested out with actually a group in Porto uh a group in Berlin and more recently New York just to see that the the API was working and organically without any publicizing of this people have been joining those groups in Porto in Berlin in New York almost expectant of a social event. Just hands up very quickly. Who here actually lives in Berlin? Excellent. I'm gonna try and find one or two of you tonight and maybe talk about actually taking over the reins of this small meetup that we started. Um I will ask the same question for Porto but it's quite busy so I'm assuming there's a lot of you

Speaker 1: Kojo 's talk yesterday, again I'm going to keep reflecting back to it because it it was I really enjoyed it and there's a lot of poignant things he said Equally it's like asking like how you can help organisers of meetups. I suppose it's a little bit about from me now saying look to the room, to the community. If you live in a city or a town or a region where you don't have a meetup yet, but you don't want all the admin of having to find venues and speakers and sponsors to pay for food and drink. Come and chat to me or message online. But the Django social is essentially it's there for the community now to just meet and do something with Django being your common your common conversation starter. Some of the ideas we've had, as

Speaker 1: as well as the walk, the picnic, everything else. is to have a board games night to do a co-working day, these sort of things and I'm happy to share those. This is me and this is how you can get in touch with me. That might might have gone five over, but

Speaker 2: my name is Jab Joris Fens. I'm from the Netherlands. But even in the Netherlands people just call me JJ And I work for a company called LegalSense and we built a law practice management system that is used by really hundreds of law firms in the Netherlands. But when working on this pretty huge Django application , I encounter Really it's a minor annoyance, but uh I bet most of you has uh had the same annoyance and this is what my talk's actually about. And my question is what is wrong with the following code It's a template and um I work at a team and everybody uses different editors in this team in our team and every editor indents

Speaker 2: the code just a little differently and I have just a personal preference that you indent the content in the blocks further to the right than it's currently right now, right? So I think this is currently incorrectly indented. Who agrees with me? Wow, great. So um I'm not alone I'm not alone. So uh if you have the same problem, I have a very easy solution for you, and it's called DJ HTML. And the abbreviation is actually uh was once considered the official extension for uh Django templates, but I guess that never went through and everybody just calls calls it HTML. DJ HTML is now a tool that fixes your templates and it's actually easiest to be used via pre-commit.

Speaker 2: There's only Django developers in the room here. Who of you uses pre-commit already? Okay, pretty popular. And if you didn't raise your hand, you really should because pre-commit allows you to easily run hooks on every commit you make. And this hook called DJ HTML will just automatically fix that template Uh after you run it it will look like this problem solved Some implementation details if I still have time left. I have implemented DJ HML using uh regular expressions. Which is always a good idea, right? But I have a little background in the parsing and tokenization, so I think I implemented it somewhat correctly Um if you Google for um

Speaker 2: HTML parsing using regular expressions, you will get the top answer on Stack Overflow, which is this one. And this is actually great advice for parsing HTML using regular expressions, so please all follow this advice here. And um uh yeah well uh have a look at the source code to see uh to judge whether I did this correctly. But uh the take-home message really of this small lightning talk is that you all visit GitHub slash RTTS slash DJ HTML add it to your pre-commit hooks and have never to worry anymore about wrongly indented templates.

Speaker 3: I'm Martin and I'm from Hacksoft, which is a software company based in Sofia, which is in Bulgaria. I'm here to talk about this, which is not really visible Fuck. Okay. Sorry about that. So first we all love jung. I believe all folk here that are in this huge hole. with a lot of people that make me nervous. Love Django. And we've been using it in on our projects. For many years. Um also Django is a complicated framework, and we can all agree about that. We all know that it has an awesome documentation, but it

Speaker 3: 's really easy to Get lost in it. So that's why we decided to create the Django style guide. It's a set of guidelines and patterns that we follow. I don't can't I can't use my mouse, but whatever. It's uh it's a set of guidelines and patterns that we follow in all our projects And we actually decided to put it live in the open source world a couple of years ago. And since then we've been receiving uh nice feedback and been developing it. It's not visible because I can't use my mouse, but it has like 2K stars which I found awesome.

Speaker 3: So this style guide is um opinionated, which is a word I can pronounce. This is definitely not the only way you can build your Django apps. Our only idea is to share with you what works for us. And of course you can always just pick whatever works for you and adapt it in a way that makes sense. Um Where is my mouse? Can you uh here it is. This is how it looks. It's almost like referred to it as a documentation Um and as Daniele said earlier, um the idea of the documentation is to

Speaker 3: sorry It's to trigger discussions. So we will be really happy if you write an issue and ask some questions either on GitHub, on Twitter, or here in personal. Um and share your thoughts about it. Um, what else I think that's it actually. I've just created the QR codes so you can oops

Speaker 3: Yeah we also have this project where we show in code what we had in the style guide. Um which is better than my whitening talk, believe me. So you can check it out as well. And if you want the links from before two seconds, we'll share them on Twitter. So thanks.

Speaker 4: Let's go Okay, so today I wanted to tell you a bit about um adventure into HTTP3, so you may be aware that this um new a revision of HTTP which was finalized over the summer eventually. Given the fact that it's a lightning talk, it's just I'm not going to go into the details of the protocol. The idea is more to start a bit of a discussion with you. I'm Jeremy, I've been using Django and Python for quite a while. My day job is the CTO for Spassivox, which provides contact center solutions. And I'm also the author of a couple of free software libraries. One is a WebRTC implementation in Python, and the other one is an implementation of QUIC and HTTP3, and that's what's going to be

Speaker 4: of interest today. So if we just take a step back and look where HTTP fits in our in our ecosystem as Python and more specifically Django developers, okay, when we're running a Django app, uh we're nicely uh isolated from the from the actual HTTP transport uh via an HTT server with a very Convenient with convenient and standardized interfaces between our Django app and the HTTP server We may also encounter HTTP from a client perspective if we're calling out to some external external APIs. And so usually we're not going to uh make the HTTP calls ourselves but use a library such as requests or

Speaker 4: httpx. So what a quick overview of some of the motivations and some of the the characteristics of HTP three. One of the one of the main goals was to to be able to multiplex multiple uh streams of data without encountering a phenomenon known as head-of-line blocking, let's say where Loss of data is not going to affect just one stream but all the streams. Some subsidiary goals are also reducing initial connection establishment times and the route round trips, it has built-in and mandatory support for encryption. And it also introduces some new APIs

Speaker 4: which have really no equivalent in previous HTTP versions. So if you look up web transport, you're going to find that there are new APIs within the browser which interact in quite a deep way with the actual transport layer. One thing that HTTP3 does is that it blurs some boundaries which we're used to. So on the left we have the the traditional let's say um network stack as we know it for HTTP 1 or HTTP two where each layer plays its uh very distinct roles. Uh we're going to be building upon TCP, which is given for free to us by the OS and gives us reliable ordered streams. We'll have encryption on top and then finally the the the the top layer let's say of the protocol stack is going to be the actual http

Speaker 4: things look a bit different with http3 where we have this sort of thing in the middle of the sandwich which is quick and which does encryption but also kind of reinvents uh or re-implements let's say some of the traditional functions of TCP on top of UDP so an unreliable, let's say, protocol, um, but which still solves some some of the uh some of the design goals of HTTP3. Why should you why should you care? I think the the first point I'd like to highlight is that a very large and complex protocol stack has been introduced in user space, meaning it's no longer a commodity which you can rely on at the operating system level.

Speaker 4: This is part of the stack that you potentially need to ship If you're using HTTP as a client, it's probably going to have to be vendored with possible problems of ecosystem fragmentation or dependencies. Currently the state of the Python ecosystem is that we do have a quick and HTTP implementation, so AIO quick. but currently it is not fully integrated with the libraries which you might use. On the client side we have nothing. On the server side we do have one uh server which allows you to run your Django apps straight on HTTP3 and that's uh hypercorn. And there's also a discussion we need to have about how we see this fitting in with web apps

Speaker 4: because we have something called web transport which um supports something very close to web sockets but also something entirely new uh say in the web ecosystem which is the fact that we can uh do packet um packet or message based uh message based exchanges and so how does this fit in within the our protocol stack and a and protocols like ASGI, this is something we need I mean we need to think about. So there we go.

Speaker 5: Hello everyone. As you know by Pietro, my name is Joan. So I'm gonna talk about some utilities uh I made for our company. We deal a lot with forms and uh We have a lot of uh stuff like back office uh forms, wizards, so we had to implement something that allowed us to use a lot of forms in uh uh custom uh interface so sometimes we have lots of forms and we need to display them but uh if We have a lot of forms on a single page, it's not gonna look good. So what is the solution? The solution is to turn it into a wizard where you can

Speaker 5: switch between points or do it in a single uh single line There are some implementations. There is the Django Farm Tools package, as you can see. It has a Wizard View implementation, but there is a small problem for us. It uses cookies or session and we don't want to store anything on the browser, just on the models. So what did we do? We did the wizard view interface In this case it's a general class view that allows you to put a form and a form set, or just a form set, or just a form. It connects to a main model. As you can see there, there is the wizard group.

Speaker 5: The wizard group makes a group of all the steps and joins them, makes the URL routing very easy. So it just uh the next button will always go to the next step the previous button to the previous it's all very very automated You can provide a label and uh a lot of other parameters uh to have to help the making the templates. So as you can see, another feature is it supports multiple routes. If you need to make the if a user user has a special selection and changes routes, you can have multiple routes depending on the the value. Value of fields on the model, uh

Speaker 5: configuration as I said of URLs, and allows you to store the state of the module, uh of the the wizard uh on a JSON. So if you want to display like a completion state, if the user has already passed on a step or not, you can do it directly inside the JSON field on the model. And I'll present some utility methods. Here we have uh some formset uh methods to allow you to customize the quarks, uh the form quarks inside the form set and the initial. Because uh form view and create view, update view don't have a lot of customization uh in the in these areas, only for forms, not form sets.

Speaker 5: And uh even for forms we split the form valid and form invalid methods into inside methods like form save, form set save that call form save inside and you can customize it if you wanna do like uh commit false You can customize these methods to change uh variables in uh inside the models or uh stop uh if uh For example, if a user doesn't have permission, you can stop uh raising HTTP four uh four or four before he saves, uh stuff like that. This is a demo. As you can see in the top we have the navigation bar, the steps, the uh the navigation buttons, and the

Speaker 5: regular form But we have other utilities and other views too. Like the one of the most important aspects is if the user has uh submitted all the steps and uh the data is valid So we have a solution for that. Press a button and the user can see what he has already submitted and what he hasn't. We call it a validate view We have a group of forms you can uh in trans validation uh as I'll show it Yes. So with a group of forms, in this case it's a wizard group because we are using the uh the wizard view you saw.

Speaker 5: Uh and uh uses a custom from renderer and respond as a JSON.

Speaker 6: It's a good, it's good. Cool, hello. So it's uh it's me again. Um but this time I'm going to talk to you about getting good data for your development environment or CI or your test suite or whatever. So first of all Why do we even need good development data? There are many reasons. One, to reduce the time you spend setting up use cases to test your changes. Two, to mimic real-life bugs that exist in production. Three, to get new developers going with the software as swiftly as possible. Four, to aid in load testing. You can't test uh how a list view performs if you've only got like three items. And the last one, the stand up purple request environments for reviewing changes. These are absolutely no good without a good

Speaker 6: development data set. And so how do we get that? Unless you're manually creating the data you need to test your software every time you need to do so, there are essentially uh two routes for getting decent data during development. One of them is seeding, which is the act of building up a test database from scratch either by importing a set of static fixtures or programmatically generating a set of data And the other one is snapshotting, which is the idea behind taking data from another environment, usually production, as it by definition has the most real data and therefore the most helpful. So if we look at seeding, uh it works really well for simple data models and is relatively easy to set up. Anybody can go away and create a script that dumps the data uh in the database and they can be really quick it can be a really quick solution

Speaker 6: for some projects. But if like us you run a complex piece of software with many models that need to be in certain states in tandem and at the right time, then generating the right data becomes a surprisingly tricky problem. Another issue is the data is synthetic by design. It only covers the happy cases the author thought about when they first wrote it. And not all the bad data cases that production will endlessly throw at you And over time, on larger projects, maintaining this setup can be a full-time job in its own right. As for snapshotting production data and reusing it The upsides are they will get real data to work with, including all that weird legacy data hiding uh the back of the production database. And you'll generally get more out of it too because your actual users are generating data for you.

Speaker 6: Snapshotting undoubtedly gets you a better data set than seeding, but it comes with a whole bunch of downsides. One, using production data anywhere outside of production itself is a massive no-no if it's relatable back to the person thanks to GDPR And that's a genuine thanks. It's also a security nightmare. You don't want to uh you don't want a development leaving a machine on a bus. Sorry, you don't want a developer leaving a machine on a bus and accidentally taking your uh entire production data set with it if you haven't encrypted it. It also requires more upfront work to set up a snapshotting pipeline that will work for your entire team and allow easy installation of the data across all environments. And finally Not everyone's production database can fit on your laptop, and neither should you want it to. Taking it row for row with no edits is not realistic in most scenarios.

Speaker 6: So we've had uh various incarnations of development data pipelines over the years. Our first attempt was using uh Factory Boy, which is quite relevant given the last talk, to build up a series of U cases which successfully got applied to the database. This worked for a while but fell apart as people added strange one-off use cases or made use cases which relied on other use cases which got removed and it just became a total pain to maintain. Another huge mistake we made with this was to reuse the same factory board classes as our test suite. Don't do that. It's a terrible idea and it will result in a huge impact on your test speeds. Our second attempt was to mirror our production data set to a temporary database and then apply a series of uh quite frankly mad uh SQL scripts to delete data we didn't need and anonymize the remaining set.

Speaker 6: Because we took the approach of cutting down an actual database, an actual live database, our various constraints got in the way and made this a very annoying thing to maintain. It's also detached from reality and that someone can add a new field without anonymizing it and we'd have a data leak on our hands. So it's not good. Don't do that. So what does the future hold? Luckily for us, there are many people working on solving this problem and the one I'm going to talk about today is a small company called Snaplit. Snaplit are a Berlin-based but remote startup aiming to solve all the problems I mentioned with snapshotting. So Snaplit is a command line tool that gives developers a coders configuration way to transform uh subset and generate data. Uh the config is committed to your repeat uh repository much like you set up GitHub Actions

Speaker 6: uh or any other CI product The data is stored wherever you like as snapshots once captured and those can be restored to any developer environment. At its simplest it can be broken down to two commands, snaplit capture and snaplit snapshot restore. They're pretty obvious Let's see what the config looks like. So this is the the subsetting config. What this basically is

Speaker 7: This is the voice.

Speaker 6: No

Speaker 7: talk is over.

Speaker 6: Amazing. All right. Two more facts. Thank you.