Day 3 Lightning Talks

Speaker 1: I will introduce the next speaker. So the next speaker is Ellie Roselli. Five tips to make the slides more accessible. Can you kill me, please?

Speaker 2: Hello everyone, I'm Ellie. I'm a member of Django 's accessibility team, and I'll be presenting very five very quick tips for creating more accessible talks. Okay. Uh first and foremost, please check your color contrast. Uh you spent a lot of time working on those slides. You want people to be able to read them. So a couple different sides to this. Uh check that your color contrast meets required uh WACAG standards. You can check this using like any online color contrast checker. You just put in your background and foreground colors and it'll tell you like if you're good or not Some color combinations might meet color contrast standards, but they won't look as good in a projector screen. Like depending on the screen, the colors can get widely distorted.

Speaker 2: These ones are quite good, but like keep that in mind. And generally dark text on light background works best. White text or light text can get hard to read, so I don't know how many people can read like all of these, but the bottom one is the ideal one here. This also applies to code. Uh I know a lot of us like to code in dark rooms with no windows and dark mode turned on. Uh that's great. I do it too. However, in a white projector screen uh light mode will tend to d just be more readable, uh provided that you choose a syntax highlight theme that like has high contrast. So yeah, keep that in mind. This is an example. I don't know if everyone can read it, but hopefully the light mode one

Speaker 2: much better. Uh so yeah, turn on the light mode before using those code snippets. Uh This one seems obvious, but it's really not. Sometimes it can be hard to know like realize how small the text will actually look on a big screen. Like it might look huge on your laptop. It's not that huge Uh I have a meme here, people in the back squinting at slides. Uh quick show of hands, how many of you could like read comfortably an entire presentation that's like in the font size of either of the two button? Nice. So okay, like half without squinting, without straining your eyes. Okay, half the room. So if you want more than half the room to read your slides, like use larger font sizes, please.

Speaker 2: Uh some more general uh speaking tips, don't talk super fast. I'm nervous, I'm talking fast, but like we all do it. uh try to use simple English, like don't overcomplicate it to sound fancy or anything. A lot of people don't speak English as a first language. Um so yeah that's like helpful and this also helps the amazing people doing our live captions. Huge shout out to them because Uh yeah, describe the images in your slides. Uh just like if they're relevant, make sure to take a couple seconds, minutes uh to talk about them. As a general rule of thumb, your talk should lose nothing if the slides aren't

Speaker 2: the sorry if the images aren't visible. And the same goes for code samples. Just takes a couple minutes to explain what's going on Uh this one I understand it might be a bit controversial, but please submit your slides early. Uh for the first time ever, we did an accessibility review of slides that were submitted early. Um when I say we, I mean some members of the accessibility team. Uh me, Sarah and Rahmat. Thank you both for helping with this. Um yeah. I think we reviewed the slides that were submitted up until Tuesday, so the day before the conference. Um if like we sent emails uh that if we thought people had to like improve accessibility. If you didn't get any emails, let me know because maybe we messed up and some

Speaker 2: pro part of the process. Uh we plan to like continue doing this and are still sort of working on like how to best uh achieve this and for that we need your help. Uh we are committed to ensuring Django events are as accessible as possible, but we need time to review slides and you need time to make changes. Uh and they don't have to be final versions or anything. We just need the colors, the fonts, images, that kind of thing. Uh finally Uh if you're not sure if something is accessible, you can always ask uh Django Accessibility team. We are on the Discord server, we have a accessibility category in the forum. We're here in the conference today and at the sprints, so like come chat, reach out. We're always I think we're all happy to talk to talk about accessibility at any point.

Speaker 2: So yeah. And one last thing, we are super happy to announce our shiny new accessibility statement, which is now live in the Django website So yeah. So if you're interested in what like we do and what we sort of want for the Django ecosystem, uh it's up there. Give it a read. Thank you.

Speaker 1: The next talk is from Samuel Cell Bryan. Our approach to add linting rule at practical.

Speaker 3: Oh wonderful, and they're there. So hi, um I'm Sam, I work at Kraken, um I work with Tim, I work with a number of other people floating around. And I want to talk about a problem that we have quite a lot at Kraken and how we have chosen to solve it and what we've learned from doing that. The main problem is we want to enable new linting rules. That might be from from MyPi, Flake 8, Rough, SemGrep. The list is so long it goes off the bottom of the slide. There are millions of different ways of uh setting standards you want people to follow when they're checking in new code. And we want to introduce new ones sometimes. When there's already lots of violations of those rules in the code base, uh Kraken We just hit more than 10 million lines of code in one of our code bases. That's a lot of room for stuff to be breaking these rules. Uh

Speaker 3: but we still want to enable these rules anyway. We want to stop the problem from from happening. So one way of doing that is to go and fix all the problems first, and then go and introduce the rule, and then you're in a nice happy state, everything is grand. The problem is Uh you end up looking a bit like Gromit here, where you're frantically trying to fix these problems, but other people are introducing the same problem faster than you can fix them, and you're just chasing that forever. So there's a different way that we've we've taken to to doing this. First, we plug the leak, we stop the boat from sinking, and then we bale all of the water that's already come on board. We stop people introducing new problems and then we go and fix the ones that are already there. And it's a two-step process. It's quite easy. You introduce the new rule that that's being linted to Flakeate, Rough, MyPy, whatever it is

Speaker 3: But you take all of the existing violations and you just grandfather them in. You just say, Yeah, we know there's a problem there. We'll fix it later And you can do that in a whole load of ways. Most linters have a comment that you can put on a known violation on the same line or the line above to say just ignore this. Sometimes it's an allow list of known problems. There are all sorts of different ways for all sorts of different tools. And then you go around and you fix the existing violations and you do that in your own time without having to rush. This has a couple of couple of benefits. You can stop the problem getting worse immediately. If there is a problem that is something really serious that you want to stop happening in your code, you can stop it from being introduced And you can just live with the problems you've already got. It gives you time to figure out all the difficult fixes for stuff that's kind of awkward to fix.

Speaker 3: You're not kind of trying to rush ahead. And when you've got those comments on the code that's wrong, you've found you've you've labeled it. There's now an easy way to find those so you can fix them and an easy way to monitor them so you can see your progress. This is a graph of our progress uh fixing the rough012 violation in our code base. Um and you can see there's a nice steady trend down and to the right. Sort of. It's flattened out a little bit recently There's also the trend in the wrong direction on the left-hand side. And that's not because we were introducing new violations of this rule, but we were finding the violations we already had and labeling them so that we could add this to this graph The eagle-eyed among you might be able to see that the top of the graph is 7,000, which is almost the number that we had.

Speaker 3: I did not go and write 7,000 No QA comments by hand. I don't have that kind of time. And if I did, I wouldn't spend it writing no QA comments. Instead, we automated it. And we've made a tool called Silence Linterra. That silences lint errors. It's not the kind of thing I'd recommend using too aggressively. Uh but if you use fixit, flakeate, mypy, rough, semgrep, the lint is that we use or have used uh Kraken, um it will run the tool, find the violations of a particular rule, add the no QA or the ignore or whatever it is comments. And let you move on with them labeled. You run it once and then you try not to add any more.

Speaker 3: If anyone's interested in implementing this for more linters, that would be amazing. I don't use any other linters, so I haven't. Something more Django relevant, an example. We have in our test suite some tests that do too many database queries. You might ask Sam, what is too many database queries? I would say 35 ,386 is too many database queries for a single unit test Which is a problem. So we've decided to try and solve it. We uh we have a bit of code that wraps every test. It's an auto-use pie test fixture. That counts the number of database queries done during the test and will raise an error if it's more than some arbitrary ceiling. We set the ceiling very high and we've been slowly ratcheting it down.

Speaker 3: Every time we reduce it, we find a bunch of tests that are doing more than the new ceiling, and we have to mark them with a PyTest marker to temporarily allow them to do too many queries. This leads to one of my favorite things that's happened in a long time, called a test, that checks that we do not produce n plus one queries. It does sets up 20 accounts and checks that we only do 12 queries. 12 queries, 20 accounts, no n plus one problem. Excellent Only it does twenty-eight thousand and ninety queries. This wasn't a problem we knew we had until we started going through this exercise, and we found that this create portfolio factory is actually a bit of a problem. But now we can go and fix it because we've got these things marking and monitoring where that problem is. There's only one last thing to say, and that is it's very important, and we've learned this the hard way, uh, as Charlie will attest.

Speaker 3: You have to make sure that you tidy up after yourself. Something needs to be in place to make sure that when you don't need that label that says there's a problem here, the label goes away. MyPy and uh Ruff, I think, have this built in. A number of other tools do as well. If you're building your own things, you can you can add them to it. And that just keeps keeps your graph trending down and to the right. And you don't get stuck at a nice flat plateau. That's my message. Plug the leak, then bail out the boat, and there's a tool that can help. Thank you very much.

Speaker 1: The next talk is from Emma Geskolle. Generating static site with Django.

Speaker 4: Okay, so this is going to be really, really fast. So please scan this. So my name is Emma. I've already gone through my presentation, but I work for Levit and also for Squest. com and I am a member of the Steering Council. So why generate static sites? You can generate static sites so that you um don't have to update your Django. If you have a site that the content changes every five years, you don't want to do every LTS release of Django. Uh you also gain into security because it's harder to hack a static side than it is to hack a dynamic one and also privacy because you lose all the need for cookies. Um there are already a lot of tools that do that. They don't do the it the way that I want, so I made another tool.

Speaker 4: My mo my biggest gripe about it is that you cannot uh create a nice landing page with most of those tools. Um why do it with Django while doing it with Django? Because Django rocks. uh and uh we like flying ponies. Um but how can we do that? There are already a lot of libraries that let you do that in Django. There is uh Morgroom to HTML libraries Uh there is Django distal that lets you take any Django site and uh make a portion of it as a static website. Um but how to make that flexible? Well You can use Nano Django to uh reduce uh the footprint of your Django app to a single Python file that is only three lines. Uh you can use DJP, which is a wonderful plugin

Speaker 4: system, so that you can uh pip install Django apps without having to add them to your installed apps. You can use Click and you can use some templates um some component system like Django template YAC or Django bird You put all that together, you get calico. How does Calico work? You well, you pip installed Calico SSG. You then do Calico in it. And Calico run and you have your website running. And if you want to export it to static, you do a Calico build Most of your pages will fit in one single markdown file with a bit of front matter in front of them. But if you want to do something more complex, you can uh use a directory with a data. yaml file and uh

Speaker 4: stack as many markdown files uh to create one single page from ten markdown files if you want to. Um those mockdown files, they are Django templates, so you can use template tags inside of them and all template tags are preloaded for you. There are areas in the website like the header and the footer so that can be reused on many websites. And it all works with plugins. So when you want to add extra features, you just need to pip install them, nothing else. By default, it uses uh Pico S CSS, so this means that uh you are using semantic HTML, it's really easy to switch from a CSS to another Because you're not using a bunch of classes

Speaker 4: like some uh with some frameworks, and so you're really f you're forced also to use semantic HTML, which is good. Uh Calico is a single command line that has it's absolutely not readable. Um this is what the what what the thing was saying before. It's got uh a single comment line that uh lets you build uh uh things and install and do a lot of things. Uh and summarized uh by a single quote from the talk I gave earlier. Um It's amazing, it just works. Uh you've got links there to see a few examples of the source codes uh of websites that are made with uh Django HTML, uh with uh Calico SSG, and I think I made it in time.

Speaker 4: Yes. So

Speaker 1: the next one is from Fabian Braun, how to make your project not good but exceptional by attending Jangon conference and meetups.

Speaker 5: Hello. Um in the last three days we learned Django needs you. And I would like to give now a very concrete example why not only also need my Django, but why I also need the community and why that makes my projects better and therefore I'm really happy to give to Django for purely selfish reasons. My name is Fabian. I'm a uh Django CMS fellow at the Django CMS Association. The Django CMS Association is to Django CMS, like the Django Software Foundation is to Django. So So it's an open source project, I'm responsible for merging and uh releasing uh the the product. And um yeah I'm happy to be here for the third time.

Speaker 5: I've uh had the pleasure of um supporting the Django Node space program as a navigator. And also I enjoy going to the Jung meetup in Cologne, which is thankfully organized by Ronnie over there. And the concrete example I would like to give you just comes by coincidence from the last uh uh Django meetup at Cologne presentation and uh to give you some background why I think it's important to attend these type of meetings. is that I have a lot to do solving problems. We learned that also. Um today that's what we do a lot and then we have something we want to reach, a certain target state, we work towards it. If we find a good solution, we're happy.

Speaker 5: Maybe it's a beautiful solution, we're even more happy. But sometimes that's just not enough. In that specific meetup, we had a presentation And the speaker had a post -mortem analysis of how he created a app for a startup he was working for. and he needed some components and there's different Django tools you can use for that. He was evaluating what's better with Django components or the other one was Django. Now just forget Sorry, um cotton, right, Django cotton. Um I'm not gonna repeat that, but uh long story short. Components, that's something we have at JavaScript S2. And we've been working on that and have been trying to make that more simple.

Speaker 5: And uh what was important for me and new for me is uh the result of this startup journey. Two things stood out why The person chose one framework of one one project over the other. One was auto-discovery of component. The second one was Self-contained templates, so you would work for the front, just one in the template, not nowhere else, no Python clue code. And there was another thing which I don't touch now, the syntactic sugar. And I asked myself Well, do we have this? And I realized no and it was not on my list. So that was need for action and that's why we um

Speaker 5: So what wouldn't it be nice if if you had a CMS and you would need to design um some component? And I'm gonna show this right now in uh for two seconds. You would go Get your components somewhere. Let's say you just download in Simple 's case, you just download it somewhere from from a repository. Um this one might look nice and you want to have this in your CMS and want to offer that to your editors. What will you have to do? Will you have to get the HTML code, then you would have to write some Python glue code, you would have to link the template somehow so that it's reachable. Wouldn't it be easier if you just copied the HTML and then added some template tags which would do all the declarative work, would say, okay, this is going to be a component, it has a name.

Speaker 5: We're gonna have some contents which have different fields, so what why don't we declare them in the template? And then all I have to do is create one file and I create a new component. I can integrate it into my Django CMS and I'm fine So and that's what has happened three weeks after that. And I think um that's one of the examples where I would say without you people, without um Personally interacting with you, I would have never done this. So I would love to see you tomorrow or the day after tomorrow. at the sprints. I would love to discuss with you if now templates create migrations or not. That's an interesting part. But also

Speaker 5: please go visit meetups. Create a meetup if there's none in your area. Join the JuggleNote Space program. You will also have similar interactions there. And join Discord and stay in touch with us or with me. I'd be happy. Thank you

Speaker 1: The next one is from Daniele Prosiban and the title is Who is in this room?

Speaker 6: I have a question uh for you and um my question is What is your favorite film? And if you think, why is this idiot asking fatuous questions? Then I sympathize. Of course you don't have one favorite film. When there are so many different films to choose from. And they all have different characteristics and they're suitable for different needs and different situations. And you can like them for different reasons without having a favorite. Kodak color uh Kodak Color Plus. It's not one for delicate pastel tones. It gets muddy if you're careless with exposure, but it can render striking blocks of blocks of striking color and it can also do delicate, beautiful detail. or Ilford HP5. It's not smooth, it's quite gritty, but it's detailed and strong. It's got this amazing range of shadow and deep blacks.

Speaker 6: I used to love Agfa. Photo Vista Plus. It was stunningly cheap. It was also a bit unpredictable. You would never use it for portraits, but it loved light and um it did rich vibrant colours and it was my favorite uh travel film At the other end of the price range is Kodak Portra, which is a fine-grained structure and it's superbly balanced with metal well-modulated contrast and it produces these beautiful natural skin tone. So it's perfect for photographing people. And when I say people, I mean white people. This is what's known as a Shirley card, named after the model Shirley Page. From the nineteen fifties, Kodak would send negatives of this image to all of their labs,

Speaker 6: along with very carefully produced prints, so that the labs could uh test and calibrate their own setups against this ideal result. And it was a a quality system to produce the best results at scale for white people's skin. In fact, everything in photography, film formulations Lighting and darkroom practices, teaching in photography schools, image enhancement and facial recognition algorithms have all been premised on white people's skin. So What does it matter? Well, generations of black school children have brought home disappointing school photographs, especially those in which they were in a minority amongst their white classmates. And perhaps you've seen funny Videos of black people trying to use soap and paper towel dispensers that only work for people with white skin.

Speaker 6: A bit less funny is that Low oxygen levels may be harder to detect in darker skinned people using pulse oximetry, which is possibly why black children Are four times more likely to suffer post-operative complications for certain procedures. Maybe you think, this is funny. Here I am with my colleagues at a restaurant. Six people in this photograph and one of them is invisible. She's invisible because the expensive mobile phone with hassle blood lenses and packed with facial recognition software literally fails to recognize black people's faces Why does technology so often fail to account for the blackness of some people's skin? And I think one reason is because people with black skin are underrepresented in the design and manufacture of these technologies.

Speaker 6: While the effect of the failure is often only visible to those who were underrepresented in the first place. In fact, there's a general rule. Industries in which certain people are underrepresented tend to create products that disadvantage those people. Because it's easier to forget about people when they're not there. So crash test dummies have been based on the average male Caucasian. Whereas women are significantly more likely to be killed or suffer serious injuries in car crashes. It's not all bad news for underrepresented people. Left handed tennis players have an advantage over their more com uh more common right handed opponents. On the other hand, they are more likely to be killed or injured when using power tools, so I hope you enjoy playing tennis, it means a lot to you. In what

Speaker 6: ways invisible to us might the things we make, like Django itself perhaps Disadvantage underrepresented people. I don't know, which is the whole point. And I will not know, even if I care. And want to know. The risk is that it will remain hidden from me because I am not one of those people and because those people are not around me in the room where the products are being made. So how can we ensure that our products won't disadvantage or even harm some people? I think we will only succeed by ensuring that they're in the room, because I firmly believe that However clever we are, however good our intentions, however firm our commitment, we will not succeed in making products that don't make some people invisible

Speaker 6: unless those people are present where the products are being made. And that means in this room too.

Speaker 1: The next one is from Tim Bell. Fun with primary keys with in Django. Don't do this. Um

Speaker 7: hi everyone. Um Timbell here again with more fun with primary keys. Um many of you would have been uh seen my talk on Wednesday, and this is a quick addendum to that talk. I'd like to tell you a couple of things that you really shouldn't do if you can possibly avoid it. Here's a slide from Wednesday's talk. If you need to convert a primary key to big int, you'll need to make sure you do it before you run out of primary key values. And that's the red thing on the left. Remember, if you hit the two to the thirty-one minus one limit, every insert into the table will fail. But what if you're imminently going to hit that limit? When I showed this slide on on on Wednesday, I lied. I'm sorry about that.

Speaker 7: I said that a table with an integer primary key can have at most around 2. 1 billion rows. Um but that's not true. It turns out that you can reset the Postgres sequence that supplies the primary key default values to negative 2 to the 31. And that's the little negative sign down there at the bottom right. Django is fine with this. Your application code might have some issues if you ever order by the ideal ID field, but those issues should be relatively manageable compared with the alternative. Um and that means that the number of rows that you can have in a table is actually double what I said, or around 4. 2 billion.

Speaker 7: Warning. If you switch to negative primary key values, you should plan to convert the column to big int as soon as possible. On that point, let me tell you a story. In December last year, we noticed that we had a table that was running out of primary key values on one of our systems. We predicted it would run out sometime between Christmas and New Year's Day. And specifically it was running out of negative values. We'd already done the trick that I just mentioned. And the converting to big int ASAP hadn't been done. What was worse, we predicted that even if we started straight away, it would take until mid-January to finish backfilling the table, which is here on the on the graph.

Speaker 7: It seemed like we were out of options. To avoid an outage, we needed to be able to, for this particular table, insert new rows in the table and query the table in the particular ways that the application used that table. And we didn't need to update rows in the table because the application didn't. I'm mentioning this here because different tables are queried in different ways, and that's going to turn out to be important. Here's the three-phase procedure for converting a primary key column I showed in the talk. The problematic backfilling step happens in phase two Um what if we just didn't do phase two? What if we skipped backfilling, the thing that takes all the time

Speaker 7: specifically? That would let us swap the columns almost immediately. We'd need to create a unique index first, which I've added there in bold, but that's fine. And then we could do phase two afterwards. Uh but how could this possibly work? Aren't primary keys fairly important? Um Our model had some particular characteristics. It was a kind of audit model, and it had a generic foreign key to a number of other models. And really crucially, it was only ever queried by following the reverse generic foreign key relationship from those other models. And objects were created but never updated. Which means that the primary key index was never used.

Speaker 7: And it turns out that creating new instances without a primary key works just fine. So we concluded that operating without a primary key would be okay for this model. So here's a quick timeline. We discovered the problem on the 11th of December. On the 17th, we agreed to the plan after tossing around a few other ideas and testing out how long backfilling was going to take and that kind of thing. On the 18th, we validated this plan in the test environment. That same day we got consensus to proceed. In the 19th, we created the index on prod. On the 20th, we swapped the columns. On the 20th, we began validation on prod, that is checking that everything was still working without the primary key index on this table.

Speaker 7: On the 23rd, we decided everything was looking okay. We swapped the columns on prod. I said that twice didn't I? Um yeah, uh we basically 23rd it was it was in production. Um we resumed backfilling on the twenty-third and the twenty-fifth was Christmas and nobody got called in between Christmas and New Year's. So conclusions. Conclusions are convert your primary keys to Big It ASAP Don't use negative primary key values, but if you have to, convert your primary keys to big end ASAP. Thank you very much

Speaker 1: the next talk is from Andrew Leo, which is earlier. And fifty six thousand six hundred and eight world lakes were

Speaker 8: hi everyone. Uh I yeah I'm Andy. My work, just as a brief intro, I freelanced through software crafts. I'm winding that down. I'm soon to become Hamilton becoming CTO of Hamilton Rock. I'm going to be building a bank in Django. Online, I am NanoRepublica on Discord, Mastodon, GitHub. In the community, I am Online community working chair with just starting up, uh Discord moderator, and I run Django Social in Cambridge, UK. So first a quick question for the room. Which of these two sounds more easily, like easier to achieve in a year? Is it to write 25,000 words or to write a hundred words every weekday? Hands up for A. Hands up for B.

Speaker 8: Yeah, so we're gonna see how option B went for me last year So why did I do this? I wanted to consolidate my knowledge, demonstrate my knowledge through the as a freelancer and to clients that I'm I know my staff. In helping out on the Discord, a lot of people ask the same question again and again. And again, so I just wanted to share a link of like don't do this or here's how to do user types, that kind of thing. And then I like to send uh annual goals to myself. I've done it for about five years now, just to push myself forward in all areas of life So for this, I had two inspirations. One is an author called David Cadaby. He put out a book, A Hundred Word Writing Habit. And Jonathan Stark, who is a consultant, he was a software engineer, consults people on value-based pricing, he sends a daily newsletter.

Speaker 8: Um it can vary widely what he talks about, but it's all about pricing and that kind of thing. Um so What was the goal? Write 100 words every weekday. Um topics I covered, Django, business, personal. I even did it during my holidays, so it was before the kids got up, I would bash out a thing or in the evening. Um writing process at state, uh the the process itself. And then I started a little late. I had our second child boxing day, twenty thirteen, twenty twenty three. So I started a little late, but So how did I go about it? Um I created I used to do it so it was like a task every weekday to and it's all about creating habits to do this. Um and there was a calendar event and I started simple. So it was a markdown file. I didn't start publishing until day 10 and I ignore

Speaker 8: professions. So often there would be typos, people would comment on it, and it was sucked to begin with. It was just like ideas I'd accumulated, but it was just go and get it done. Um about 100 words is also very short. This whole slide is 97 words. So it's you can write it very quickly. And then I expanded over the year. I added an RSS feed. I started publishing to LinkedIn to Mastodon. I added a newsletter. I added features to my website. So images later that then posted to Instagram. It was it evolved. And then the results. So as of 9th of January 2025, I had written approximately 56,608 words. I used a script to count it and dropping links and that kind of thing. Um and it was an average of 217 words a day, maximum 482.

Speaker 8: One day I missed the mark basically by three words, 97. I got four inclusions to Django News, which was a highlight, and then I had lots of ideas for the community. I could have had probably, there's probably a hundred lightning talks in what I wrote. And then it just extended my reach. But it can be all consuming. Every day I when I finished that one blog post, I was already thinking about what to write the next day. It it consumed the whole of 2014. This is the link to the blog if you want to scan it. But for me, my encouragement is your turn. Could you do this? Could you do a similar goal? Set an ambitious goal. I think anyone in this room could. It's yeah, it's about setting the habits, like setting the the goal, but then having the habits that are daily to encourage you to do that.

Speaker 8: Um and then as a PS, um I really recommend you donate to the um DSF. Um I personally do five percent and I reckon a percentage because it's scales. Um if you earn I if you have a salary, it it scales to any salary and it's a consistent thing. So that's it.

Speaker 1: So the next one is I have to read because this is kind of weird but Chat GPT Denis Biaisoli. How to write a lightning talk with ChatGPT? Seems interesting. Or not?

Speaker 4: So this lightning talk will be about how to write a lightning talk with uh ChatGPT and of course everyone can

Speaker 6: Absolutely.

Speaker 4: Here's a snappy five-minute lightning talk script you can use tailored for a Python Django audience at a conference in Dublin. Feel free to tweak your tone if you want it more casual or formal. Sorry. So first rule, always check the output of your uh AI generator. And then yeah, I wrote this talk in less time that it takes uh to break your virtual M. And this is a talk about lightning

Speaker 6: talks, so it's kind of a recursion all of you know and love recursion for sure

Speaker 4: but with a little more of caffeine so

Speaker 6: why you should do uh a lightning talk well uh it's five minutes long, so it's a perfect plan. Long enough to fake expertise, but short enough to avoid uh questions from the audience.

Speaker 4: So you look productive but there's no need for tests. First step, you need to summon the AI, your favorite tool, and ask him ask it, uh write a lightning talk about writing lightning talks using Chat GPT And this idea came to my mind at 4 a. m. uh two days ago. Yep, sorry for this. And so you don't need Stack Overflow, no imports. Nothing else. It feels like cheating, but it's the same as selling to customers uh Django admin without having to write a single line of code. So it's perfect Then you need uh a little bit of structure, uh you need a hook, uh

Speaker 6: propose a problem and a solution. A little bit of demo and then a call to action, but make sure don't hit the production

Speaker 4: before looking at the output, of course. Then you need to add a little bit of uh personality because uh ChatGPT is like startup. It gives you the skeleton, but it's up to you to make it fun and safe If it's code.

Speaker 6: So you can add uh

Speaker 4: humor, local references, or a little bit of self-deprecation. Then you can propose a real example. This talk. So yeah, you ask ChatGPT, can you create a lightning talk about how to create a lightning talk using ChatGPT? and you give in context. I'm at a Django conference in Dublin and it delivered. And then I added some jokes and caffeine. So this talk is like make migrations for public speaking. A couple of tips. You should be specific in asking AI. So audience, tone, the time. And then you can it iterate, so make it shorter at

Speaker 4: jokes please, uh less cringe. Always be nice with AI because in the future maybe they will spare your life. And then you can remix it so it's like you are DJing with with your code and with the output Then you can also create images so you are not just a human reading output but just also a human generating images using AI. Final top, uh lightning talks uh are made for speed, not for perfection. Yeah And well, ChatGPT gets you from zero to hero in well faster than Django

Speaker 4: in creating MVP. And remember you don't have to be brilliant, just be brief

Speaker 6: Let me know if you want it styled into a proper slide deck format too.

Speaker 4: And thank you. And if this went badly, just blame AI. Thank you for the job for the help. Okay, so I'm Chris. I presented last year at DjangoCon in Vigo. Maybe m some of you remember. It was about uh Making an LLM place piece orders for you basically. Now this year I want to play a multiplayer game with you that I built with Django and HTMX. Do you guys want to join? Okay. I don't promise it will work. Actually I'm pretty sure it won't. But uh I'll

Speaker 6: so I'll start so first off please join uh the this network. Because you will be connecting directly to my MacBook. So Talbot Hotel Stillorgan, not Talbot Stillorgan Hotel, because apparently there are two. Okay, so after you join in the meanwhile I will present a game where I play by myself first you choose the can you see anything?

Speaker 8: Uh y yes.

Speaker 6: Actually no, this QR is something else, sorry. So first just connect to the network and then uh I will s I will show you a QR that you can use to actually join So first just be attentive just for a bit. You choose a name, you choose how bad you want to be roasted. I don't want t any mercy on me So then there's this QR code, don't join yet. You start the game, you use a photo, whatever. I'll place my workshop. Workshop I presented at DjangoCon You don't have to write anything, it's just if you want the LLM to know what we can joke about. Come on. Okay, after this

Speaker 6: chose mine, thankfully. And then what happens now is you'll get like 20 possible choices of roasts. You need to choose the one that you find funny and press on them. Basically, you vote. When you press on them. So at this step, everybody votes the ones that they find funny. Okay? I've seen more engagement at the funeral. Yes, that's how it was. Your presentation skills are so bad they make PowerPoint look exciting. I thought that Okay, that's a good one. Okay, so you have about thirty seconds to choose the funniest roast ideas. And uh then it will make a poem for you

Speaker 6: using those uh roasts about you. So let me check because I have changed this. Okay, so it shows the most voted ones. Okay, so that's the idea. I'll now do this and stop my server and just start it again. Okay. Now I'll create a game and you can finally use the QR code. Uh so use it from here. Oh wait, no, it's localhost. My bad. Wait You you have to use the one with the IP. Oh, I'm sorry. Ten point ninety-three point okay, this is one It would have created the wrong URL.

Speaker 6: Okay. So this one should work. And maybe things will break after like ten players. I've managed to do it with five, but I haven't tried with like a hundred. So we'll see what happens now. So basically It's WebSockets but is the most baboon style uh implementation of it. There's just an event from the server saying to refresh game for everyone. So that's basically

Speaker 8: that's So okay, I don't know if I should wait for everybody to join because th that is the higher chance that things won't work. So let's just let's just How much time do we have left? Okay, I'll press start now. I'm sorry if if somebody else can join. Okay, so you have twenty seconds, choose an image

Speaker 6: I'll use this

Speaker 8: which is uh an attempt at a logo that I made. Okay, so we have 61 players. If this works Now get another MacBook. Okay, so now okay, so it's mine apparently. I swear it's not pre

Speaker 6: -determined, so it's random. Although this is so unlikely, so I don't know what happened. Maybe I didn't okay. Okay, so I think it broke. No it didn't. Okay, so I don't know if everybody got to the next screen. Sometimes it seemed like it Not everybody gets it, so just vote what you find funny. Sony sorry if you can't see. Yeah. It's a work in progress. Actually I can't even see the the buttons to press oh yes I can.

Speaker 1: Tick tuck tick

Speaker 8: we was just in the roast Do I get a participation trophy? Okay, so I don't know how okay. Now we can see okay this is the fun most fun. The logo

Speaker 6: is so basic make people look at fine art So yeah, this is the step and then it will make a poem and I'm really surprised this actually worked because I like I said I only tried this with five players so it will be online. It's actually open source. That that was the other QR code. You guys can get the repo, you can use it, you can create a Kahoot clone from it. I don't care, it's open source. You can see the patterns that I've used with HTMX to make this work. And it's still in CSS. There's not a single line of JavaScript in the whole project. It's just Django HTMX until in CSS.

Speaker 1: So the last one is about PyCon P T

Speaker 6: Okay, thank you. I know you're tired. I'll I'll be brief. It's not really a lightning talk, it's more like an invitation. So um we really would love to welcome you to Portugal. this summer. It's our fourth edition of PyCon Portugal. I won't bother with with the details but we'll we are improving it each year. So um This year last year we were more up north, Porto, Braga, Coimbra. This year we we are going south. It's warmer in the summer. So we are we are going to Cascai, which is next to Lisbon, over here. by the beach. The Cascades is also known as the Portuguese Riviera, so it's very close to the looks of Cottazur.

Speaker 6: I chose the best pictures I could find in on the internet. So this is the beach in front of the venue and that's the venue. It's a university and there's a tunnel between the venue and the beach. So we don't have to cross the road So there are a few ways to go and win a free ticket. Unfortunately, call for proposals is already closed, but you can volunteer or you can apply for a grant And uh it's 24 to 26 of July. And um don't forget to bring your flip-flops, okay Hope to see you in Keskais.