Do Repeat Yourself

Okay, so it's time to present Donatas. Uh, as always, happy to see that this room is always almost full. So yes, uh, welcome Donatus. Uh, in his talk, do repeat yourself. He will explore why uh, following the rule don't repeat yourself isn't always the best idea and he will use some examples of using Python. So the stage is yours and uh good luck. Thank you. Everything audible? All right. Uh good afternoon everyone. I hope you've had an interesting conference so far. Um the talk today that I'm going to give is not technical. So you can just relax. You don't have to pay attention super hard. Um and the presentation is going to be about repetition. I engineered this presentation with the intent for it to be a bit different from a typical conference talk. In the next 20 or so minutes, you will learn nothing. I will give you no advice and there will be no best practices or worst practices or tips or tricks or anything like that. My goal here today is hopefully to entertain, possibly to inspire, and I hope you enjoy. So, to make an inspiring tale about repetition, I first need to clarify what repetition means to me. What I'm not talking about is repetition of code. I think in recent years collectively we've come to appreciate the idea that maybe sometimes it is better to have duplicated lines of code. You're allowed to be wet and write everything thrice. Whatever you feel like in this aspect, I don't judge and I won't talk about it further. You're all familiar with the mean to rewrite in Rust. I take it that actually is something that will be a relatively big part of this talk. But to me, rewrite in Rust often focuses on the wrong thing. An app is not great because it is rewritten in Rust, but rather because it is rewritten. It doesn't matter in what language or what dialect you rewrite in. The process of doing it is the thing that I care about, but it still doesn't fully cover the definition of repetition. For me, my definition of repetition is closer to what you might think of as a repetition in sports. So, when you, for instance, lift heavy weights and repeat that to get stronger. Now, dig into your memories and think of the last time that someone willingly rewrote the exact same API 15 times in a row to get better at it. How often have any of you rewritten the entire codebase from scratch? Who would even allow that, right? And how much do you enjoy working on features that you've already built in the past? Repetition is kind of frowned upon in our field. We are technologists after all. And so there is a tendency in us to be relatively future oriented. Repetition is something that happens kind of in the past. So we don't really like it. At this point, you may say, "Well, maybe I don't like doing the same work, but I do it whether I want to or not. It's just part of the job." Which is fair, but remember when I spoke of repetition in the context of sports. Think of a squat. Is every squat repetition the same? If it were, would you enjoy working on it? Or would it maybe feel like writing the same API over and over again? Every time you do a repetition, you do something new. You can go from A to B many times and get nothing from it. You can squat in the exact same way a thousand times and still have poor form. You can write the same APIs using the same ideas and your APIs will still run into bugs on production. You could remark that what I'm saying is describing iteration. That also does not satisfy my definition. iteration builds on the previous thing. Whereas with repetition, the goal is very much to start at A and go to B and not start somewhere in between. So when I say repetition, that is roughly what I mean. It is an ambitious undertaking and it is rarely the same as the previous attempt. All that translates to a deeper understanding of the matter and it kind of improves our form. But what does form mean in the context of programming? For that, I will go on one final tangent that is not directly related to programming. Ask yourself, what do you get from learning a spoken language? Straightforward answer here is that you're able to communicate with more people. If you speak Spanish, you can communicate in Spain. I believe there's another big benefit that we don't often think about. Language gives you a different lens for life. Some language lacks translations for words. In Germans, in German, you can construct your words very freely and it can still be grammatically correct. This is a legit German word and it is perfectly correct. It means it doesn't even fit on the screen, but it means something like beef labeling, supervision, duties, delegation law. As you can imagine, this is not something you can do in every language. Languages have different strengths. I have lived in the Netherlands for a very long time, so I'm pretty good in Dutch. Uh, and the Dutch language is quite on its own, which sounds negative, but it makes it really good for deadband delivery of jokes and sarcasm. Lithuanian, on the other hand, is far more animated, and it makes for a great way to tell stories. These qualities are very much in the vibe of the language. Care to guess what the strength of programming languages is? I'm of the opinion that programming languages are fantastic in efficiency. And when that's the realm that you live in, then it makes sense that repetition is going to feel like a bad thing. Think back to natural language. There are many ways to order words to convey the exact same meaning, but there's one that you as a person choose. The one that most expresses who you are, the one that feels most like you. When we write articles, posts, and books, we keep going back to ways we construct sentences to to find that specific phrasing. But when is the last time that you went to code and found a way to code that really expresses yourself? So, that is something that I've experienced resolutively recently. I made a karaoke app with a bit of a twist and I'd like to take you along in the experience of rewriting a part of this. I hope that by the end you will see what I mean when I say that repetition can be lots of fun. And let's see if you can figure out the twist. Let me walk you through what sort of technology I'm working with here. Application is a fast API web app. Don't worry though, I will not show you how to set up a fast API app. That is the kind of repetition that even I find boring. The front end is powered by raw HTML and CSS. New JavaScript frameworks pop up every 5 minutes or so. And I guess there's like a thousand of them by now and I just couldn't pick. Additionally, I use a meme library that I made at a lightning talk at Django some years back. The module we were writing deals specifically with them. It is moderately important to be aware of service events. Can I get a quick show of hands of people who have heard of them or know how they work? That's very few. Um, so I will explain it with the risk that you know you're hearing it a second time. Server sent events are a way for a server to send updates to a client. They are similar to websockets but are not birectional. Uh I like them because the API is somewhat easier to me. You can send structured messages to a client. Structure is pretty arbitrary, but typically you send an event name and some event data and the client handles that. With that, let's get into some code. This is a Python conference after all. Here is what the module looked like in its previous version. I think we can all agree that this does not spark joy. For one, I did not manage to implement some pretty important features. It is undergone and it does not capture the complexity of what I'm trying to do. The worst part is actually the API. Sure, technically this worked, but using it to actually make karaoke was horrible. So, I went ahead trashed the code and started over. I'll keep it visible on the side so you can see the difference. For my karaoke app, I have three major requirements. First, it needs to look good. Then, it needs to play music. And finally, it needs to show the accompanying lyrics. With that in mind, let's rewrite. When you do a full rewrite, you're not bound by past mistakes. You can try something radically different. The direction you're heading in is no longer completely unfamiliar. You dare to be more ambitious. Since it's not really about the result, you can just play around. You start seeing patterns and seemingly better abstractions. You rethink ideas you had. Some you keep, some you discard. The more you return to the same problem, the more it starts to make sense. Sometimes things only make sense when you see them a second time. can fully commit to an idea and explore it. You get the feeling you're being really clever and feels good and you end up with something that in the moment seems amazing. Sorry, all of this is getting me a bit of a dry throat, so I'm going to have some water. You can admire the code. So, let's run it. And I bet you did not see that coming. Repetition always has a way of surprising you. Sometimes it is an astounding success. Other times it ends in utter failure. And all of this kind of reminds me of something. I've experienced this rewrite relatively recently. I met a karaoke app with a bit of a twist. I'd like to take you along in the experience of rewriting a part of this. Hopefully, you'll see what I mean when I say repetition can be lots of fun. Let's see if you can find the twist. Let me walk you through what I'm working with here. Sorry, the timings are a bit off. The application is a fast API web app. Don't worry though, I will not show you how to set up a fast API app. I will not put you through that kind of repetition. That would be very boring. The front end is powered by raw HTML and CSS. New JavaScript frameworks pop up every 5 minutes or so and probably there's like a thousand and one of them by now. Additionally, I use a meme library that I made at a lighting talk at a Django some time back. It started out as a joke, but by now I'm committed to making it the next big JavaScript framework. I also make extensive use of server sent events. The module we're rewriting deals specifically with them. It is moderately important to be aware of service events. Quick show of hands. Who knows how they work? Not all hands are raised, so I'm just going to explain again. Server sent events are a way for a server to send updates to a client. Uh they are similar to websockets, but are not birectional and you don't have to maintain a connection. I like them because the API is somewhat easier to me. You can send structured messages to the client. The structure is pretty arbitrary, but typically you send an event and some data. This can be JSON or anything. With that, let's get into some code. This is a Python conference after all. Here's what the app looked like in its previous version. I think we can all agree this does not spark joy. For one, I did not manage to implement some pretty important features. It is underengineered and does not capture the complexity. The worst part is actually using the API. Sure, technically it worked, but using it was horrible. So, I went ahead trashed the code and started over. I'll keep it visible on the side so you can see the diff. The karaoke app that I want has three major requirements. It absolutely needs music. I want the visuals to move in accordance to music. I'm not content with them just being static. And of course, it has to display lyrics. When you do a full rewrite, you are not bound by past mistakes. You can try something radically different. The direction you're heading in is no longer completely unfamiliar. You dare to be more ambitious. Since it's not about result, you can just play around. You start seeing patterns and seemingly better abstractions. You rethink ideas that you had. Some you keep, some you discard. The more you return to the same problem, the more it starts to make sense. Sometimes things only make sense when you see them a second time. You can fully commit to the idea and explore it. You get a feeling you're being really clever and it feels good. And so you end up with something that is the that in that moment seems amazing. Sorry, all this inspirational nonsense is giving me a dry throat. Going to have some water while you admire my cup. [Music] [Music] As I said, the timings are not great. [Music] But we have to wait. [Music] So, let's run it again. This time, I'm going to be really safe about it. I will use all the guard rails that I can think of. Going to drag it out for just a little more suspense. I think you know what comes next. [Music] I've experienced this rewrite relatively recently. I made a karaoke app with a bit of a twist. I'd like to take you along in the experience of rewriting a part of this. Hopefully, you'll see what I mean when I say repetition can be lots of fun. Twist is I've been doing karaoke all along. Let me walk you through what I'm working with here. The application is a fast API web app. It's the very app you're looking at right now. I guess by now you're not surprised by that. The front end is powered by raw HTML and CSS. New frameworks pop up every 5 minutes. There's like a thousand2 of them now. I also use HTMXX, but I think I've plugged my JavaScript framework enough for the day. I do also make extensive use of server sentent events. Everything you've seen here is served by them. In the process of this presentation, I've emitted roughly 15,000 of them. Quick show of hands. Who knows how server sent events work? I'm not explaining it again. So, I went ahead trashed the code and start over. No, that's not actually it. Um, at this point, I'm going to deviate from the script a bit. And we're going to let this play out. Have some nice animations in the background. Um, but I'm going to get a bit meta with you. When I said I engineered this presentation, I meant that very, very literally. This entire presentation is written in Python. The slow slides are Python code. It is an absolute mess, but I'm convinced there's an API that I will at some point find that works for me. I generally started out with the idea to make a karaoke app, but as I revised it more and more, it seemed like such a fun way to give presentations. All the code snippets that you saw, I pulled straight from previous commits. I have rewritten this app over 10 times in the past few weeks. I've had a thousand tabs open to research how to pull this off. In the process, I learned an incredible amount about unexpected things. I learned about audio streaming and CSS animations in ways that I had not thought of them before. I dove deep into serverent events and explored every nook and cranny. And until the very last minute, literally up to 30 minutes ago, I was fixing bugs in this presentation because believe it or not, it had them. It was really stressful, but in a good way. The same way it is stressful to do a dangerous climb or run a long marathon, there is this thrill of massive failure. With each iteration, my ambition for this presentation grew. There are many ideas I did not get to implement in time. I wanted SVG animations time to the beat of music. I wanted to have this reverse effect that I could go back through slides. I wanted the slides to look nicer. I wanted the timing of my lines to be more in time with the music. I wanted to have very exact timings for everything. I had so many more jokes that would work in this context. I ran into incredibly annoying Python behavior with objects. I spent most of yesterday trying to figure out when an object is copied and when it is not. In the end, I feel passionate to return to this again and again because while it is not productive in the traditional sense, it is a lot of fun. This is the first time I'm giving this presentation, but it certainly isn't the last. In retrospect, it is crazy to think that I can manage to live up to my ambition on the first try. So, in some time, maybe some weeks or some months, I will rewrite this again. And then probably I'll rewrite it some more after. And next year, I will submit another CFP for this exact presentation for this exact conference. Maybe on my second rep, I will have better form and technique and I can deliver on the idea that is in my head. Or maybe I will return the year after that. One way or another, I will continue repeating myself. Thank you. [Applause] Big thanks to our Python DJ. Um, we still have a couple of minutes. Maybe from the audience, we have uh a question or two. One more maybe in private. Yes. Any questions? Oh, I see the hand. Uh, actually, it did crash. Uh, I can I wait. There's an internal Oh, no. It's not showing up. One second. As you see, there's an internal server error. There was one final slide, but unfortunately it did not come. Oh man, have I iterated. Um, the thing is when I say I repeated it, like I really mean every time that I started over, I just completely trashed the project because initially the idea that I had for what I wanted to make was very different from what I end up making. Like I did not intend to have uh slides in Python code, but I can show you what that looks like because it's wild. Uh, let's see. This is basically the presentation or at least one part of it because as you see there's an introduction, a first iteration, a second iteration, a third iteration. no library. It's literally HTML, CSS, and fast API and lots of hacking. Yes. Have you ever heard of revealjs? uh I have but it does not do what I want it to do because one of the ambitions that I have is to stream this presentation to everyone's phones. At a previous conference what I did at some point using servicecent events is to kind of make an orchestra out of phones and my idea was that I would have the time to implement something like that as well here. Okay, we see you. Yeah. Uh none of it, believe it or not. Uh I I tried like I feel I'm doing AI wrong. Uh because mostly I get very annoyed and I delete whatever it suggests. Okay, one more question. No, you have such a chance. Okay, so then thank you so much for the presenter.