Lightning Talks Day One with Kojo Idrissa

Speaker 1: Hello everyone. So good to be here and so great to meet many of you already uh at the at the Colo booth. Um yeah, excited to tell you about Colo, which has been a uh a passion project uh of mine for the past two years. So Colo is essentially a novel Django debugger. The idea is that we show you um you know every variable, every function call, every SQL query in your requests, in your scripts, and in your tests. Um so this is actually the only slide I have, and it's not really even a slide, it's a PNG. Um so let me let me go over to the live demo next. So I have a Fibonacci script here. And the first thing I'm going to do is I'm actually going to uh run that with colo. So I can do, actually, can you see this? Let me get really So I'm going to do color runpython fib. py and that will run. And then inside VS Code, we can see a visualization of Fibonacci.

Speaker 1: For uh you know up to Fibonacci 10. So you can see on the on the leaf nodes here you will see zeros and ones, uh as you might expect And then as we get closer to the middle, we can see these summed up all the way to return 55, which is the last in in Fibonacci 10. So if you've never come across Fibonacci before, you can see how you know, Colo and its visualization can kind of help you build a mental model of what's actually going on with with Fibonacci. We have another thing here, which is the Ackerman algorithm, which I learned about a few weeks ago, and I'm actually still not sure what it does besides make a really pretty visualization. Wow, look at that. Isn't that nice? Um all right, now stepping away slightly from the pretty things, um Colo actually started as a middleware for your um for your Django app. So I am going to make a request in my l to my locally running um

Speaker 1: uh simple poll. Uh so I'm gonna cast a vote And if the demo gods are with us, and they are, a new trace will show up here, and likewise we can see a visualization. So this is every single function call that was called um in my Django code base during that request. So uh you can kind of see there's a lot going on here, but there's this vote function in the middle that seems to be doing a lot of the work. So I can click on that and then I can see every single local variable that was defined during that request. So you can see user ID was, you know, z U0 G and whatever. And I can also see all of the input arguments, all of the locals, all of the return value, or the one return value. So the idea with Colo is you know you make your request once and then you can kind of see all this information. Uh you might see that there's a few other colors, uh colored nodes in here as well.

Speaker 1: So we have the purple ones, those are the SQL queries, we have the green, which are accelerated background tasks, and then we have blue, which are outbound uh HTTP requests. Uh so I can click on any of these uh SQL queries and I can see exactly what SQL Django send to the database, and I can also jump to the place where in my code that request actually happened. So that is Django that is Colo um instrumenting a Django request. Now let's see if we have time for one more thing. Um so by default, uh colo only shows you uh the function calls in your own code. The idea is that most of the time you're working with your own code. And you're kind of curious about what you've written, what your co-workers have written, and that's where you're going to make your changes. So we don't show you what Django does for you, because Django actually does a lot for you and it might be a little bit overwhelming.

Speaker 1: But you can actually turn this on. So I've prepared a little snippet here where you can use the colo. enabled context manager to actually include all Django frames. And we're going to make just a single um select query here and we'll see what we get back. All right, and that showed up right at the top here again. So there's 700 uh and let me make this a little bit bigger. So this is Every single function that Django is calling for us for when we make a single select query. You can see there's a lot of things going on. So if you've ever been uh curious about uh you know contribute contributing to the Django RM, this might be a useful starting point. Uh lots of quoting different things and and lots of fun things going on. And then also uh let me see if I can show this. Yeah, there's actually quite a big block of code which is um setting up this connection uh

Speaker 1: to uh to um to the database So we can actually run this again, and now Django will already have the connection. Uh and we get another visualization. You can see this one only has 486 frames instead of 737. So it's another visualization. I can put these two side by side, and you might see that they look quite similar, but there's a bunch of things that are different. All of this stuff is kind of missing from here. That's because we already have a connection. And you can see we no longer have this uh connect and at 38 milliseconds over here and this is about uh twice as fast. So this is a quick demo of colo. Um if you you know like to learn more come to our booth we can get uh colo set up on your code base. Colo is completely free, pip install colo and you're off to the races

Speaker 2: Okay. My name is Sam Atkins. I'm a software engineer. Um I've been working remotely since uh before it was cool, which is uh 2011. Um and I'm gonna talk about uh working from uh the road, specifically in my case, working from a van. Uh so why would you want to work from the road? Um I do it to see new places and meet new people. Um and I want to do it before I'm retired. I want to do it while I'm relatively young. Um so that's why I do it. The next question is how do you do it? To work from the road, you need a job, you need a vehicle, and you need internet. So let's talk about those three things.

Speaker 2: First the job, you're gonna need them to allow you to work remotely at least some of the time. Otherwise we're kind of done with this talk here My opinion is finding a place where there aren't too many meetings is advantageous. Meetings are completely doable from the road, but They're a little extra work. I also prefer to have fewer meetings. I think as fellow engineers you might agree, regardless of whether you're working from the road. And then just having understanding coworkers because inevitably things will go wrong. That happens from when you even when you're working remotely from home. So having some understanding coworkers is super helpful. Uh in terms of the vehicle, uh there's a ton of different options. These happen to all be uh RVs uh that I've owned over the years.

Speaker 2: Uh but In in essence, uh the smaller the vehicle that you have, the more flexibility that you have, the less attention you're probably going to draw to yourself, but the less space and comfort you're likely to have. Bigger ones, uh you you're gonna be limited on the destinations you can go. Uh they stand out a bit more, but you're gonna have more of the comforts of home. Okay, now the big one. Uh internet. There's there's a million options here. Um if you're starting off Your phone hotspot will work great. That's a a great place to start. Um pick a day where you don't have meetings at all. Drive to a a park and work off your hotspot. You know, that can be your your your your demo. Um the more money that you spend

Speaker 2: on your internet setup, the less stress you're going to have working from the road. However, nothing is going to be as good as your fiber connection at home. But there's options like your phone hotspots, standalone hotspots, mobile router with multiple sims that are bonded together into a single connection, Starlink. So uh there's tons of options there. Could do a whole talk about that, obviously. Please come find me if you're interested in talking about this. Uh what are the pitfalls? Not everything is an Instagram photo. There's a bunch of unglamorous things about uh working from the road or living in a van or uh whatever your specific setup may be. It can also

Speaker 2: be a lot of driving, depending on how you plan it out. Obviously you have control over that, but uh depending on how far you want to go. you know, and and how quickly you'd like to get there, you might find yourself driving for you know the majority of a day. And then it also takes some amount of discipline. So It it can be difficult, depending on your personality, to be in uh, you know, on a beach in San Diego and concentrating on work. So I guess know yourself and what your limits are and probably you know will get better at it over time as well. All right. But with that, yeah, I would say it's worth it.

Speaker 2: If you're interested in it, please do it. Get out there and have some fun. Explore the world. Thank you. Bottom right, the gray van in the bottom right. It's actually parked out front uh on street parking. You may see it, so feel free to knock. Thank you. Thank you.

Speaker 3: Okay, I'm beginning. Um so I did the end-to-end testing with Playwright workshop on Sunday, which was really great. Um I recommend it. We ran into an issue when we were running that. Some of you I think were here, where sometimes the tests would fail. Again, we don't have time. So here's a good example of me doing this that other people were doing in the session. Sometimes the pass is fine. Sometimes it would fail. We didn't really know why, partially because we were had never used Playwright before. But it was just kind of an interesting thing. We thought, oh, maybe extend the timeout, maybe it's just too slow. Whatever. The person Danny was sitting next to me was much more curious about debugging it. So that's at least one other person besides myself who was we were temporarily distracted almost from the workshop because we wanted to know why this was actually happening

Speaker 3: And I can uh tell you with pretty good confidence I think we figured out what's going on. So this uh end-to-end testing, of course, is going to a page with We don't have time to look at it. But it was uh you know text input and then a save button. And then we had a test that said go to the update test would be like, you know, update the information, click save again. And that's the test that was failing. And we couldn't figure out why. Um I would love to ask people for guesses, but we don't have time for that either. Um the first hunch that we came up with that started to seem promising was This end-to-end test is looking for the word save so it can click on the button and we are also randomly generating text data for these fields. And so we thought Perhaps sometimes the word save is in that field and it finds that and then can't click on the button.

Speaker 3: But like any good debugger, you want to first see if you can verify and replicate that. So I use the this is using Factory Boy. And I said, well, first of all, what if all of the words said save? And uh you can see That it will fail every time. So that was a good way to figure out what the problem was. Uh which I was pretty proud of. And then to fix the problem, as you see, it just times out. And in this case, it's It's waiting. It's it's waiting for something that's never gonna happen. Um so to fix this test, part of this was a playwright-specific thing, but one of the things that it does which is pretty nice is it has a pretty nice API for

Speaker 3: uh finding stuff. In this case, this line was page. click. And so what this will do is it'll just look for text anywhere on a page and then try to click on it and it by default will just grab the first thing it finds. Um so it's a good example of how it may seem like the library is being flaky or end-to-end tests are not worth doing and it's like, oh well actually it's a problem once again up here. And so one way to fix that is just a more specific selector, so it actually looks for a text input that says save. And if you do that, it solves the problem every single time Except it's probably I think there's one other place I may need to change it. But then it works every single time and it's kind of nice, you know, you might want to then redo

Speaker 3: this test so that it isn't saying save all the time or perhaps you want to leave that in as a regression because sometimes you do stupid stuff. Anyways, I just thought that was kind of fun and interesting and uh I'm sure I'm probably at time. Unless anyone has any questions.

Speaker 4: Still got a minute thirty.

Speaker 3: Still got a minute. Anyone have a question? Yes, sir. Playwright is an end-to-end testing library that is written in a language that I am not sure of, but has bindings for like Node and Python and uh The gentleman uh uh a little bit to your side right there is the one who did the workshop himself. And so he's a great person to talk to about it. Uh we had a lot of fun on Sunday.

Speaker 4: Any other questions? If not, thank you very much.

Speaker 3: All right, thanks.

Speaker 5: Begin? Okay, cool. I don't have my speakers notes, so we're just gonna speedrun this. So first, why do you want to look at space? Trick question. This is just for fun. There's not really even any Django in here. It's just cool Alright, old school. If you want to look at space, use a thing called an orery. Uh these were cool clockwork devices that you got to like figure out where the relative motion of the the planets and sometimes even moons on the really fancy ones were. But if we fast forward, uh NASA Eyes has a thing called the NASA Eyes Orary. So this is a WebGL tool. Um It gives you the real time uh or if you want past or future relative positions of everything in the solar system, including, you know. Planets, uh asteroids, moons, uh active interplanetary missions, everything. Super fun. Um I'm gonna kind of blow past the URLs as I go through this because

Speaker 5: we're going real fast for this. But this is how you get to all of these things. Orri also has a an app you can download which has walking tours of the solar system. Super fun. Alright, also from the eyes team. This is the Deep Space Network Now view. DSN is super cool, and I'm not really going to go into detail on it, but it gives you real-time information on everything we are communicating with in deep space. Um this is just fun. If you go into the advanced information, you can get the data rate to things. My phone often can't get that much uh information, but apparently we can get it from uh Jupyter. All right, but if you want to look at bigger things, uh this is Mast. Um so Mast is an archive that has basically all space telescopes that have ever existed um across the whole world. All of them get fed into Mast. Um One thing I will mention about MAST, if you want to figure out what you're looking at, you need to give it usually either

Speaker 5: coordinates in the sky or you need to look up the keywords are Messier catalog or NGC catalog ID. You'll need to like figure out what you want to look at, look up its ID number, and then feed that into Mast, because Mast doesn't speak human things. It doesn't know what like the horse head nebula is. When you download things from Mass, they're going to be in this file. I don't have my speaker notes, so I don't even remember what the acronym is. This is called a FITS file. I think flexible something, something. Anyway. Um but anyway, it's not a normal like JPEG or PNG. They're these science data files, so you're going to need readers for them. Um this is a screenshot from a thing called Fitz Liberator, which was originally from the ESA and is now managed by the US NSF. Um but this is not going to be the last custom image format we see here.

Speaker 5: Alright. Uh the only Python in this whole talk Mast does have a binding in AstroQuery. So if you want to scrape stuff off of Mast, there's a Python library for that Moving on. So that's faraway stars. What about close-up stars? This is a tool called HelioViewer. So the only uh spacecraft that this is looking at that's real fancy that's still operational is the Solar Dynamics Observatory, which is awesome. But it also has historical data from everything that we've ever put up that's been staring at the stun. You can also get stuff from Stereo A still from this, even though it's only got like I think two instruments left online. This is real fun. You can make time-lapse movies out of this in like four clicks. It's really nice during any kind of geomagnetic storm. You can make a little time-lapse of the flare that kicked out the plasma. And speaking of storms, Noah operates a thing called the Space Weather Prediction Centers.

Speaker 5: This is where you go if you want to see like what things are on their way, not me, uh the other NOAA. This is if you want to see what's speeding towards the Earth. Unless some of you happen to like run a power company that I'm not aware of, this probably isn't actually super useful, but the Aurora forecast Is fun just if you want to see how far south the aurora goes, especially if you're traveling somewhere north, and you want to see maybe if you can see the aurora, it's cute Alright, that's stars near and far. Uh let's talk about Mars. So the best source that I found for m uh Martian imagery in general are the uh raw image pages on each of the NASA Mars uh rover Mission pages. This gives you JPEGs in order. Unfortunately, it is separate

Speaker 5: pages for each mission, so you have to go to them separately, but you can get JPEGs and they're fun to play with. This is uh Perseverance Front NavCam from yesterday. This is Curiosity Rear HasCam from yesterday There's no real story there. It's just cool that I can show you what Mars looked like a couple hours ago. If you want science quality data, you're gonna have to go to something like Mars Viewer. So this is a Java applet that interfaces with PDS. PDS is the planetary data system. It's an office of uh NASA as well as a custom image format and a database file format. Um if you want non-MARS stuff from PDS, you have to go to the PDS image atlas. Um This is kind of a pain in the ass to use, but you can get lots of information from it, uh notably including MRO, Mars Reconnaissance Orbiter,

Speaker 5: which is real fun to play with. Um the equivalent for ESA is the Planetary Science Archive. What do we have? 15 seconds? Alright. And then finally Cellus track. There's a fun story of this, which you're not gonna hear because I'm out of time and you're not getting the bonus round.

Speaker 6: Hello everybody. My name is Maxim Danilov and today my lightning talk about how we can rethink about service rendering. At first I want to say I work with Django since 2013 and since 2021 we use Vue. js version 2. 7 right now. Uh special thanks for my team who provide me uh this lightning talk. Anastasia Senn created design of his presentation. Pavel Pelikin checked all my uh crazy idea in code and Martin I Okay. Is our is our intern he um uh tested uh

Speaker 6: this all. We have standard um headless schema uh on client we have a view. js application after that this application speaks with um Web server and web server send requests to Node. js or to Django. Node speaks with Django truth Django Rest framework. But it works really slowly. What we can to do? We can uh improve browser cache, we can use image cache, we can use a sync fetch in uh Node. js, uh and we can uh cache API, but it works really slowly. We uh start to uh refactor components. We made magic settings for a web server and uh settings for Node. js. We start to refactor, we start to use FastAPI

Speaker 6: uh we start to improve uh uh or m in Django but it running slowly. What we can to do? Something say us static site rendering uh it made it faster. How? Well for first request somebody sent request to web server, web server sent request to Node. js which works in server-side uh mode uh they um rented for us templates uh with data which provide uh jungle rest framework and after that Answer is sended to client and after that uh view application uh speaks with uh Django truth uh Django Rest framework. But how we can work with Vue. js without Node?

Speaker 6: Of course we cannot. But we can avoid use Node. js for production completely. How? Somebody sent a request to web server and web server asked Janga uh to uh for render a template. And this template, truth template manager, is received from uh get generated before templates from Vue. js and other requests uh after the thirst request works normally. What I want to achieve, I have a big team there , I have many developers on Vue and they can create all on View perfectly. But after that, uh

Speaker 6: template from UJS developer, we uh works with these templates uh on the node, we create static side generation and we generate Django templates in this moment. And the Django after that works with these templates. How? In Vue. js component we have uh places for some for example product description or for a product title and for service um static site generation I send instead of product data Uh text, uh jungle template text. For example, like description it comes mr. Mustachos project ref, for example. And after that, uh static site generation

Speaker 6: in uh on node generate for us templates which Django can use like normal templates for first uh answer. What we can achieve? We can achieve Django server side rendering fast and furious, and uh of course these templates was created with view before. On the background, some jungle template stacks is omitted, but it's really brilliant for our performance. Some Django template filters is uh are omitted. But it's really pr uh brilliant for our performance. Inclusion inclusion tax are no longer used at and it it's also brilliant for my performance.

Speaker 6: Result we achieve a perfect result this these changes. Uh average uh thirst time uh to first byte uh lower than one hundred milliseconds around uh around uh 40 sec uh milliseconds and this is hard work for UJS developers. Thank you for your attention. Maxim Danilov you can ask me how it works. Thank you