Writing Resilient Code w/ Zuzana Kunckova

Hi everyone. We should be live now. Hi. Happy Thursday. I keep forgetting what day it is. [laughter] That's a really good beginning. Yeah. So, tomorrow is Friday the 13th. So, Oh, man. I'm moving too. So, I feel like I'm hurt myself. Yeah. Oh, no. Why would you do that? [laughter] Did you plan it this way? Oh, no. My husband did. I we well he didn't know it was the 13th I guess in my head the numbers didn't connect that it was Friday the 13th. Yeah. Oh yeah. Dave's yelling at us. Hi Dave. Hi Dave. So we've got one one listener viewer. I don't know. What do you call people that join the stream? I don't know. You can say listener. Some people might like listen to a stream and not like watch it because you can have it playing and not like watch. I do that sometimes. But they wouldn't see your boxes. So they lock the screen. They're like, I don't want to see that. They don't want to see all my boxes. The wall of boxes. Wall of boxes. Wow. Okay. Well, good luck tomorrow. But today Thursday. Yeah, today is Thursday. Hi. Um, Idev, welcome in. How are you doing? Hi Krishna. Okay, we have multiple viewers now. [laughter] Okay. Oh, I forgot you said don't tell you the number. Well, no. Yeah, don't tell me who's watching cuz it's just going to freak me out. So, it's just you and me chatting. That's that's how I do these things. I Yeah. Same when I'm on stage. I don't know about you, but when you're giving a talk on stage, do you actually see the people? And I don't mean like see as in physically see, but do you think of the people or I make eye contact. So, it's really weird because I always thought I had social anxiety and I I think I do still and I like never would have like done public speaking but now whenever I speak at conferences and when I was teaching too I like to make eye contact with people and like see how they are taking in my information like how they feel about my talk like I feel kind of like unmed if I can't see anyone cuz you know some stages the lighting you can't see people that freaks me out. I really like to be able to see people and if I can see people are like laughing or smiling, I will like latch on to that person and I'll keep looking at them. Like I'll look around, but I'll keep going to them and I'll try to ignore the people in their phones cuz then when I see people on their phone That's the thing. Yeah. I'm like, "Oh no, my talk must suck if they're like on their phones." Yeah. I mean, I think when I was in Nashville, that's where the lights were really bright and I didn't see anything and it was kind of It was weird. It was weird because you don't know like you don't know are they even out there and you know they are but it's yeah I prefer when I can kind of see them but not too much because I don't want to see when they're on their phones or I don't want to see people yawning or something like that. So, it's worse when it's a small conference or like a meetup, too. Like, I've talked in some rooms where it's only like 60 people or something like because it's multi a multi-track conference and that stresses me out especially when you know most of the people in the room and you're like, "Oh no." Um, and same with like small like Laravel lives are really really great, but when it's a smaller crowd and you can see everyone and see them all on their phones, it like stressed me out more than even Laron US. Yeah. Yeah. I think having more people like more anonymous audience like that probably works for me cuz when there are people I know and I don't want to look at them because when I do I know they'll be like nodding like trying to support me which is great but it throws me off a little bit. So it's a it's a weird space like being on stage it's kind of like a different reality but so that's why I don't want to know who's watching because I'm just focus on you and you're not enthusiastically just know you're doing well you're doing well [laughter] thumbs up but hi Leah develop happy Thursday hi we have hi Muhammad hi you didn't read that was really long like a handle and you skipped over Go on. I don't know. I I can't. Okay. Love Dave Richmond 7743. Maybe I feel like I butchered that. Sometimes I skip names if I think I'm going to butcher it because I feel bad. Hi Pushpack. Welcome in. A push back said you should try speaking at Lacon India. Very huge crowd. I think I'm going to apply to speak at Laracon India next year. I don't know about Zuzana, but I think I'm I'm going to. No, we should go together. We should. we should probably go again. Yeah, [laughter] maybe get an old crowd together again. Yeah, that would be lovely. Have fun. Yeah, I think I've seen videos and I've seen pictures and I don't know how many people are at Larkon India. Do you know the numbers? But it looks over a thousand, right? I think it's massive. It's definitely over a thousand. Hi, Cyro. Welcome in. Yeah. And we have a question. What is resilient code? I think that's a sign like stop talking rubbish and get on with it. No, that is a great uh great point to segue into the topic of what we're here to talk about today. So, let's go ahead and jump into I know [laughter] I'm like okay get the show on the road. Um so, hi everyone. We're here today to talk about writing resilient code and we will answer questions of what even is resilient code. But first, let's do some quick intros. So, hi, my name is Leah Thompson. I am a devro engineer at Laraveo. I do a lot with our online communities and then streams and stuff such as this. And I'm here today with Susanna. Susanna, would you like to introduce yourself? Hi, I [laughter] haven't worked on my elevator pitch yet, but I am Susanna. I am Laravel and PHP developer. I'm also the founder of Laravels, a community for PHP and Laravel developers who are under reppresented due to their gender and I I do a lot of other things. So yeah, public speaking I have done some courses in the past. Um yeah, wear a lot of hats. So but everything is kind of in the tech industry. So we are women in tech. That's who we are. Yes. Yes. [laughter] Which Yeah. Reminds me there was a great blog post about Larabels published. Yeah. To yesterday. Yesterday. Yeah. Let me share it in chat. If you'd like to learn more about Larabells and what they do. I think this is a great blog post to learn more about it. Um, and I'm not just saying that because I'm in the blog post [laughter] either. Yeah, you are. I didn't realize there was an excerpt and I was reading. I was like, "Hey, that's me." Yeah, it's it's very well written. And although I mean I knew it was happening and I I've seen the blog post before, but when it was published it it it lands differently. It feels it's actually quite emotional when you read it. When you read about Larabos from someone else's perspective, it just it's something else. So it was very it was nice to read. I agree. I got emotional reading it too. I was like I don't know. It's like this was only like a year and a half ago them here now. were going to a bunch of the same conferences and like hanging out and just thinking of like seeing the pictures too of when Larbell started. Um I think it was at Laracon EU 2023. Yes. Seeing like there was still a good amount of people but was like smaller and then compared to like us at Laracon US this year or last year and then Laracon AU and we kind of took up the stage almost like took up a good amount of the stage. Yeah. And I remember in Lisbon when I when we all were on the stage taking a photo, I was like, "So many, look how many." To me, it was incredible. And now looking back on that picture, I was like, "Wow." Okay. Was amazing. Yeah. So today we're here to talk about writing resilient code. So Zuzanna did a great talk at Laracon Australia, so Laron AU last year, so 2025, talking about writing resilient code. and we're here today to basically just go over what she covered in her talk but in a discussion format. And the talk is about writing resilient code. So I think to jump into it, let's talk about what does it take to build resilient Laravel applications which we will all find out here today. Well, [laughter] that's a big task. I think there could be a whole course a whole book about this. So let's like let's dial it down a little bit. [laughter] Let's dial it down a little bit. Uh but I'm going to so I'm going to start with how I came up with the idea for the talk because that might help people who would might want to talk at conferences. But I always start with the title like a title comes to me somehow out of nowhere. I might be reading something or thinking about something and it will come to me. So my talks always start from the title an excerpt and then I take it forward. So it's never the other way around. It's never about like what do I want to talk about? No, it has to come to me really. And yeah, it's really unpredictable. Yeah, for me it's very unpredictable. I can't plan for it. Either I have a good talk or have a talk in my head or I don't. Mhm. But all my talks, everything, all my ideas were just kind of spur of a moment thing. And I don't know what I was watching, but it was about human resilience. It was some talk online, YouTube, I don't know. It was about human resilience and like what it what it means to be resilient as a person and what's the difference difference between being resilient and confident and it came down to being resilient is that you have the ability to bounce back from setbacks and it's acknowledging that life it's not going to be great there will be tests and tribulations and being resilient is about being able to overcome these trials tribulations and like like I said jump back from setbacks and continue in some way and that that got thinking about how if we could apply this to code as well and I went down a rabbit hole and it was lovely. So the idea that so I did some research and it turns out that me and people on the internet kind of decided that the definition of resilient code is code that is able to withstand any stress and anything that uh either developers or users throw at it and it can continue in some way and it can handle error as well. So that's resilient code. So it's not code that is expected to always work well or run well. It's about um knowing that there will be issues and we can't avoid them because at the end of the day we are humans and we will make mistakes and some mistakes will be out of our hands. So acknowledging that this is the this is the state of things and then working with what we've got. So that is resilient code code that we write code and we write applications expecting them to have issues and then dealing with those issues proactively. No, I think that's great. And I pinned this comment again because what you said just directly answered the I thought that he he asked again. I was like am I not saying it clear? [laughter] I rephrase it. He like answered like but what is resilient good? I'm trying to say I'm [laughter] trying. No, I went back. That was me. Okay. Okay. Sorry. I'm not trying to troll you. Hold on. You've muted yourself. Come back. The uh There you go. Uh okay. I think it's using the right mic. It muted me randomly. Okay. Technical issue. [laughter] [gasps] So yeah, so that's Brazilian code. Um and yeah I built a whole talk about it and I then I tried to look at things from practical perspective as a developer things that happened to me happened to people I know happened to me as a user of applications and that's I that I put it into a talk. So that talk was never meant to be like all in like there's so many more things we could do. It was just a snippet of things that I could come up with and things that fit within the half an hour or so that I had for the talk. So yes, whatever we discussed today, it's not uh overwhelming like it's not everything there is to say. Like I said, Brazilian code, it could be a book. It could be of course it could take so much more. But these were just some examples. Yeah, it's more of a high overview of things you can do to write resilient code. It's not like a deep technical dive into implementing those things, which I definitely think could be a course like you said. Yeah, each of the the points we're going to discuss could be a talk on its own. And I think also writing resilient code it's a lot about mindset not as much about I mean definitely there will be technical things you can and should do but it's a lot about mindset like thinking about your application slightly differently because that that's the step number one you can do to start writing resilient code because you need to start thinking about it in that way. Someone already has a question which I think some of this is covered in the talk but I generally try to develop my projects in accordance with the solid dry kiss yagni yeah [laughter] principles what do you think about this that's a lot of acronyms I mean how [laughter] do you even manage uh first of all well done because I don't think I could do all that uh I think each of them have their own uses yes but I thing we have to be careful as in not to over complicate things and not to overengineer things. So for example, Yagy I know that well because so it stands for you ain't going to need it and I know this term thanks to my friend and mentor Sarah Bine which she talked to me about it a lot as my mentor and every time I came with a question but what if I should what if I do this and should I do this and she's like you're not going to need it just just leave it until you need it. So that's that kind of principle. Uh but yeah, all of these are great. All of them together. I mean, if you can go for it, but that does doesn't necessarily mean you're going to be writing resilient code by using these uh principles because the principles are a lot of them are about how you structure your code, how you, you know, write your code. Yes. But are they addressing how you handle errors? Are they addressing validation and sanitizations? I don't know. So these are important things, good things, but by you you using them doesn't mean your code is going to be resilient. Possibly not. I don't know. [snorts] Because resilient code also has to do or more has to do with like how you're thinking about your code, right? Like how you thinking about like how your users are going to use yeah the code how you structure the code. the way you structure code will be great for developers but for resilient codes when you think about it uh the definition I gave at the beginning it's about code that can withstand and uh like any issues that will come its way but some of the issues the way you structure your code have they doesn't matter but if your API fails it doesn't matters how well your code is structured if you can't handle failures or if you can't handle user uh being I think the way you put it I call. I'm not going to say how I called the users in in my call, but you said the users were h What did you call the users? I'm trying to look through our notes. Cur curious, not mean. Let's be nice. Oh, [laughter] no. I said me. You're saying I said not mean like user side, they will often not use your application the way you intended them to. They like to break things. Oh, yeah. They never use it the way you intend. It's like they It's like funny because when you're building it, you're like, "This is going to be intuitive. they're going to understand how to use it and then you like open it up to the public and you get all these like error reports and you're like why are you even using it this way? It's like are like our brains just completely wired differently. Like it's really interesting to see you know and I guess when you write it you're in your own little bubble and you're like everything makes sense to you because you get you into it. Yeah. you're like, "This is this makes so much sense." And then you open it up and they're like, "This makes no sense at all." And you're like, "Oh, okay." And you like step back and have to rebuild. I think we'll talk about users in a bit, but yeah. So, again, using all those principles, it's great. It's great for the your codes and your structure and how you work with other developers, but it might not necessarily make your code more resilient. Mhm. And I think you already mentioned it some, but I think like it makes sense to go into talking about ways you can do that like you mentioned input validation and sanitization. Yeah. So that was I think the first slide because I think we should start with that. That's such a ba basic principle but it's it's like testing. Everyone knows they should we should test our code. Does everyone do it? Eh, not necessarily. Same with input validation. We all know it's important why they are input. Sanitize it. Does everyone do it? Eh, I don't know. I don't want to judge, but you know, I know that it's just [laughter] one of these things that potentially there is a room for improvement. Let's put it that way. And yes, the reason you need to validate your inputs is because you so there's a saying that that goes like uh never trust a user, network connection or device. So never use never trust a user device or network connection because you can you can control what they do. You have no idea. And even if we forget the the mean people that try to break into your application, even genuine users, you can't control what they do. So don't trust them. Not because they are malicious sometimes, but also because they might not know any better. And if you don't validate your code, they will try maybe just being curious. Try to let's let's say put a form. And if you don't validate your form inputs, they will try to put any sorts of thing. They can try to especially users that are armed with a little technical knowledge. They are I think the most dangerous because you know beginners lack. They might know a little bit about JavaScript and they will try to paste stuff in you know JavaScript snippet into your form fields and if you don't validate it you might regret it. So validate your inputs every single one. Sanitize it. So sanitizing means removing any unwanted characters and I think one of the potential problems might be that people will sanitize their input therefore like remove make sure that it's you know HTML is not rendered everything will be stripped but they will not validate it. So these are two different things and you should do both of them. Um so yeah so this is something because every website pretty much will have some sort of form as long as it's in any way dynamic or like you expect users to interact with your website. So validate your inputs and use because we we are in the laral world and Laravel has a massive list of validation rules you can use. So it's really quite easy to implement and even if there is a you've got a use case that any of those rules work for you, you can make your own custom ones. So there is really no excuse not to validate your data because Laravel does make it super easy. And I think when it comes to writing resilient code, this is the, you know, the easy one to implement, one of the easier ones to implement. I would agree with that. It's like funny cuz I'm thinking of like some of my side projects I built like when getting into web development and I did not like sanitize [laughter] my but like you don't think I think you don't think about it often because um like if you wouldn't try to break into other websites why would you expect other people to but now especially now you've got a lot of bots that can just do things on behalf of actual people. It's just it's a wild wild west out there and be careful when you share it with like other developers. I think it's like fun to see what you can break sometimes too. Yeah. So mean. No, no, no. Like it's like being curious, right? So it's like I mean it is like stressing. [laughter] You're the person they're coming to. They're like, "Hey, I did this." And you're like, "Why are you doing that?" But it is like fun to see what you can do. And I find myself testing people's applications now, too. Um and my first few like projects, I would live stream them on Twitch. Yeah. And so I would share them on Twitch with people and then they're like inputting random stuff in the fields and I'm like, "Oh no." Having to like delete it out of my database. Yeah. I mean, and I went when I was when was in Australia, there was a course about website security. I don't know what it was called exactly. Anyway, so I took it there was a workshop and part of the workshop was breaking into a website and trying to, you know, find things and it was so much fun. And I think that was me, a beginner armed with a very little knowledge, but enough knowledge to be dangerous because once I kind of when I once I was shown how to break into a system for learning purposes, but still it made me feel so powerful and I have to say I did not use it. I don't try to break into anything since but that's why I'm saying like people learn something and especially these days online you can learn anything you want and yeah so forms are just they can do so much damage or like unvalidated data can do so much damage especially if you yeah if you don't validate data if you don't restrict which form fields you will accept data from people can try to submit any sorts of things so they can if they can get all the way through to your database you can be in a lot of trouble. So yeah, validate your data people. If you do nothing else, do this please. [laughter] Which this is unrelated, but someone was asking Raphael asked which IDE have you been using. Anything I I don't know like I'm I I'm not I don't have a preference. So when I was working for a company and they were using PHP Storm, I use PHP Storm. Now I'm using VS Code because I just um I'm yeah I don't really have preference. I use like three different IDE. So I have PHP Storm, I have Cursor, and then I use VS Code on my personal laptop. So it depends on what computer I'm on or like what I'm testing too because if people tell me they like found a bug with one certain IDE, I like switch to that one to test. Yeah, that's interesting. I think the reason I find it easy because I always do the same key bindings on all of them. So there are certain things that I will always use and then I'll do the key bindings on any whatever I'm using so that I know I can't think of anything now but like command T opens the terminal in VS code the integrated terminal and I think I I think that's the one see I have it in my fingers I don't have it in my head so like my hand knows what wants to do. I'm trying to think like yeah I think it's command command T that opens the integrated terminal on cursor I don't know if I did anything but on cursor it's command J for me. Oh I would have to change that. Interesting. I never change any of mine and so I just like learn them over like two years like I won't know any and I'll be clicking around and then finally I'll learn a keybind. I'm awful about that stuff. I'm always like in awe of people and they get really good with the keyboard management. They get all these shortcuts. Mhm. And I'm like, I wish I could do that, but it's just so much work. So, I don't Do you memorize the shortcuts for my actual keyboard? I don't know if I can hold it up, but I have a split keyboard. Oh, wow. Okay. And so, I have it like different mappings and stuff like there's three different layers for it. Um, so I finally got that memorized after a year. Well done. Don't move don't move on from this. Just never change. Too much work went into it. I can't. Someone said Bruno said Laravel helped me write resilient code partly because pest PHP is amazing which I think testing is part yes of this talk too right I mean we can talk about testing well because we can go to error handling first yeah okay let's do error handling because it's like kind of we are building up to testing testing will be like the grand finale [laughter] confetti will go off and then we'll talk about PHP yeah Uh so error handling um sorry a lot of people I've heard say confidently that my code is fine like you know my I know what my code is doing it will be great so that is case for testing but let's leave it for later but also it doesn't matter how confident you are errors will happen because we are people and people make mistakes and errors and I don't just mean errors that were done because the code didn't work the way you expected but also errors coming from external packages from third party packages so AP API and file storage or whatever any sort of error. uh the way you handle the errors is again how you can make your code or your application more resilient because one thing you don't want to do is let's say from a user's perspective suddenly your website will throw an error and I'm saying [clears throat] from users perspective it's funny because my own website has been doing that a lot lately and I didn't even plan it and uh I host my website on digital ocean because I want to do everything the hard way because why not why not Yeah, but then like every now and then it just it goes down and I've got like 502 error and it hap every time it happens I just reboot the server and it goes back up and I'm happy that I fixed it. Yay. And yesterday again it went down. I got an email by some from somebody saying, "Oh, did you know your website's down?" I was like, "Oh, no. So, let me just reboot it again." But I was like, "Let me update the packages. Why not?" Because I'm already SSH into the server. So, I did that and now I've got 500 error everywhere. [laughter] I was like, "Okay, 500 is laral error. What is going on?" Anyway, so that it shouldn't happen. Do as I say, not as I do. However, I did now put a maintenance page up saying I'm just dealing with it because I don't know what's going on. But instead of anyone who looks at my So don't look at my website now because if you do, you will see the maintenance page. Or actually, do look at the website because I did that page all by myself. Anyway, what is the website? I'm going to zand-ashk.com. Um, yeah. I want to see your reaction to my beautiful maintenance page. Man, this is beautiful. Hold on. Uh, this is good. Oh, the little heart. Okay, hold on. We're going to Are you going to share it? No. Yep. [laughter] It's like do as I say, not as I do. But like, no, actually do as I do because I did put like I got rid of the ugly error and now at least it's a pretty error. Beautiful. Got a gradient here. I know. It tells us what's going on. So, we don't worry. We don't just see a 500 error page. Exactly. There's a personal [laughter] there's a personal touch to it and then you have a heart. Exactly. So that's how you should handle all your errors. Not [laughter] really know but like avoid I think one of the biggest thing is with errors don't let users see the ugly errors that your application displays by default or your server whatever. uh because for couple of reasons. First of all, normal users, not technormal users, it's not that not normal, but non-technical users, they will not know what 500 error is or like what they seeing. It might put them off. It might scare them, you know. You don't want that. Second of all, they don't know what's going on. So, they like you need to give them some information. So, like I did and I promise I did not plan for this actually just came up with it. But you tell them what's going on. tell them like come back later or something like give them more information. The other reason if you just show uh standard errors for example let's say you will forget to turn the debug off on your Laravel website. So instead of debac false you'll have it as true and then they'll see the whole error stack and that is that can be dangerous because that can give away so much information that a user should never see and again depending on the level of technical knowledge of the user it can be sort of information that's dangerous in their hands. So not only it looks scary and it will be like oh no what's going on and then it can be dangerous for you. So yeah, one thing is then if you do display errors, which you will because things happen, make sure that the errors are like more user friendly and don't don't show any sensitive information. Even just having like a designed error page I think like even that just having like the personal touch there, you know. Um I think the maintenance one the page you had was really nice too. Thank you. Bruno even said I think it is nice maintenance. Thank you. [laughter] And [gasps] then they said, "At least you have at least you are honest. Some people just have the default EngineX error page." Well, I have to say it was my case for a while. [laughter] So, I want to say I'm like I'm better than anyone else because that that was my case for I don't even know what's breaking it. So, I don't even know how long it was down for. Oh, well, it's it it's better now. I'm learning, you know. [gasps] No, and you changed it once you found out, you know. So it is like showing like I I think it's showing too that writing resilient code and doing these things is an iterative process, right? You're not always going to be perfect but it's knowing these things so that like when it is brought to your attention you implement it. Yeah. And having like processes in place that make it easy for you to implement so you don't have to uh uh like do it everything over every time something goes wrong. So having knowing what happen when something happens this is what happens and if you can automate it great. If you can't at least have documentations in place to tell you what to do next time. We have some Yeah, go on. Oh, I'm sorry. There's completely unrelated questions. [laughter] It's fine. Let's just roll with it. It's okay. So, someone asked which hosting is best for hosting Laravel applications, which I know you were saying you hosted this uh or your site on Digital Ocean and did it all yourself. I Yeah, because two reasons. It's cheap and I I actually genuinely want to know what's going on because one thing that like how to do things because one thing that kind of worries me is when everything is hidden behind a beautiful UI and you don't actually know what's going on. And I'm not saying that you everyone should know everything about everything. It's not possible. But when it comes to hosting, I think as a developer, we should at least have an idea. Doesn't mean we all going to be DevOps. I don't want to be that. But I at the same time, I want to know at least a little bit what's going on. I want to be able to fix things if if something goes wrong. So yeah, we're like two sides of a spectrum. I'm like Laravel cloud for everything, which I am like diving more into that and like I want to dive more into kind of I guess like DevOps stuff in general to understand it, but I also just really like how easy cloud makes it to ship things and deploy things. cuz I think it's really great for like people who are starters too as well as just like people who don't want to have to think too much about like autoscaling and stuff like that. Like I do still think you can like deep dive into it but I just really really like cloud. Yeah. [laughter] I mean if if my website was popular, if it had a lot of traffic, I would if I if I had to scale it, I would probably use a tool. But for what I'm doing right now, I don't need it. And it's and like you said like you could deep dive into what is happening on Laravel cloud but will you ever like yes I will I'm claiming it for 2026 I'm doing it because I've always too I' I've said it for a long time. Oh I want to know more about Deops one day one day. And it wasn't until actually started using digital ocean and I had to because there was no other way. That's when I started learning. So sometimes you just have to throw yourself in if this is this is what you want to learn about and I'm not saying everyone has to. I do think everyone should have an idea but so that's hosting. What were we talking? We were talking about error handling. Uh so we so I mentioned errors looking pretty basically but the other type of errors is that you need to be able to handle them in code. So expect failures and as I said errors will happen but then some of them uh preventable yes but also you can for example if a third party API goes down you can then use your code to retry the API or you know the database connection whatever so don't just let it die and do nothing about it. So this is where writing resilient code comes in place where you will anticipate errors, you will anticipate failures and then you write code that will respond to them as as fast as possible because as I said you can't really always prevent them but at least you will you will be able to react to those errors in a way that you want to rather than being driven by circumstances. You will have a little bit of power in your hands. Mhm. I agree with that. And I think it also ties into monitoring and logging. Yes. As well. Oh yes. Yeah. Because if you have errors but you don't know about them, what's the point? [laughter] You know, you can just pretend they don't exist if you Yeah. Well, you that that is very true. And ignorance is a bliss and a lot of time like in my case, I didn't know my website was done. I was perfectly happy, you know, I had no problem with anything. Uh but if you don't have friends like I do that tell you when things are down, you can use software packages or you know applications that will help you with that. So there's a lot of error monitoring. So Laravel Nightwatch is one of them. Uh there is Flare by Spy. There is Sentry. Oh my there's so many. Who else? Can't think of any. I'm blanking. Yeah. Well, I said three, so it's fine. Yeah, three and more. uh what they do they will monitor your application and if there is an issue if there is an error you should be monitored or you should be informed because like if you've got the monitoring setup right you will then be told that there is a problem somewhere and that again you want to ideally if there are issues if there are errors you want to be proactive you want to know before your users tell you because if the user has to come to you and tell you like my friend see I'm basically talking [laughter] about myself hello will by the way if you're listening It is. Um, you shouldn't wait for users. That's such a bad I should have never said anything about my website. Anyway, you shouldn't wait for your users to tell you that your website is down. It's good. I mean, it's showing like you're giving this talk based on like things that you've experienced as a developer, right? Because I've definitely done that, too. [laughter] Yeah, I've done that, too. I've had my my site have issues and I didn't know and then someone's like, "Hey, this is broken." And then you have to go fix it. And then at that point you're thinking like how many people have seen this who haven't say I know I don't even know. So I know it was down few times over the last few months and does it mean that people just told me but it was down for much longer. I have no idea. But if I had [laughter] monitoring set up I would have known. I don't because it's just a little website that I assume nobody goes to you know. So, why would I [laughter] have So, what I'm hearing is that we're going to have another stream where Zuzana integrates Nightw Watch into her [laughter] website. I Oh, I could actually Oh, I could actually do that. You should do that. Not a bad idea. Yeah. So, anyway, if I did [laughter] if I didn't have something set up, I would have and most of these, if not all of these uh software applications will have a functionality to send you alerts when something goes down. And those alerts, I don't know when send to your WhatsApp or do it. Yeah. Yeah. It's easier said than done. [laughter] Um, so you can send like Slack messages or I don't know any sort of messages or emails, whatever. Emails. Yeah. When things go down. So use that because as I said, what's the point of having error monitoring application when you don't receive notifications and the aim is for you to be able to handle errors before your users tell you to. Again, won't be always possible. And often the feedback loop will be really sure that something goes down and somebody will tell you immediately because they just happen to be there. But try to be proactive or at least like if you know something's down like me, you put down you put up a maintenance page so people know instead of people a beautiful one. Yes, I'm thank you very much. So that's Yeah. So monitoring uh and logging. So the other thing is you should log some stuff. So when things go down, when things go wrong, ideally you will have uh some logs in place that will give you a little bit more information about what happened. H and the reason is that for example, again, I'll go to my website. If I saw like 502 error, I don't know why. I still don't know at this right now, I don't know what caused it. If I had [laughter] error monitoring and logging in place, I believe I would know a little bit more. So now that I have 500 errors because I moved on by the I don't know if I said it I moved on from 502 now my website was showing 500 errors but in that case at least I can check the lar log and there are a little bit more I can look into but still those messages the the default log messages are quite not always easy to understand and they're not always the clearest. So when it comes to logging log the important things that you kind of expect might have go wrong at some point. So when you do have an error you will have a clear message this happened there because this something and don't log things like hello or test as we all do during development [laughter] right because that will help that will tell you that your logging is working but it will not tell you anything useful about the error you are experiencing or your application is having. Uh and one thing do not log sensitive data because uh as far as I know logs are mainly just text files and if you log anything sensitive you are basically asking for trouble and don't log too much because lo errors are long and it can eat up your space your me your capacity your storage capacity really quickly. So be careful with that. So lock things, but don't log sensitive stuff and don't log too much extensively. Like be quite careful about what you're logging in and where and why. But do log and do monitor and do do track your errors. Don't be like me. Let's see. Is the next slide an example of that? Like an example of logging, right? Uh yeah, but I was just um because again Laravel comes with a lot of help helpful helpers and Laravel comes with the log uh class and you can log dash error and then it will show the message the stack trace and all that. So use whatever Laravel gives you. A lot of these things that we talking about are already uh can be easily implemented in Oh, there you go. Very good. This is asking too. Oh, go away. Oh, slide only. There we go. Yeah. So here's an example. I figured it'd be helpful to show like the code examples too that were in the slides. And uh so this is yeah from my slide when I was trying to show that let's say you've got a product. So you've got a website with products and for some reason your featured products fail to load. What do you do then? You have to have a backup. So instead of uh showing on the page nothing. So let's say you've got a website, you've got like a banner on the upper hub that will show feature products. And if these feature products don't load from database for whatever reason, it could be the DO feature products. It could be that something else is wrong. I don't know. But you don't really want to just have empty space there. You either want to show and this will actually come we'll come back to this strategy later on in in the slides, but you will either want to load something else. So instead of featured, you will want popular or the latest products or something. But as this is this is taking care of the user side of stuff, so the users don't see empty spot. But for you as a developer, you want to then see log the error and see what happened. So in this case, I was using uh logging like with the message felt load products and then the exception and the stack trace. That will hopefully help you to figure out what went wrong. We'd love it. Let me stop sharing the code. So that's logging and yeah I was saying that Laravel gives us a lot of helpers and often it's not knowing that it exists but I think it's safe to say by default just assume that it does exist in Laravel and look for it because it's it would have to be a very unique case if something if a solution for your problem didn't already exist. Yeah. Yeah, always default to thinking it exists. I just need to find it. I need to find a solution that already comes with Laravel and if not then you build your own thing. But most probably it will already exist. Someone said in my opinion and I can be wrong database failures could be handled in the global exception. Try catch is more for specialized. Yes. So that's uh what you saw is I couldn't so that was for the talk purposes. uh there are ways different ways to write things and where you put the code and I I would put it on one slide simply when I was standing and giving the talk so people didn't have to keep looking at different slides. So even uh I think there was was it in the I don't know which code example it was I think few examples down it was about oh weather service I remember that much weather service weather service or was about the graceful degradation degragation which we're going to talk about in a minute where I put a long if else statement inside the controller it doesn't mean it should be there I just put it there because it was easier to have it on one slide rather than on multiple slides. So yes, DB failures could be in a global exception. In general, code can be written differently. This is the one she's talking about. Yeah, but if we're going to get to it, we'll get back. But yeah, this is just to say that these code snippets are that this is not the best way to write code. It was just the most convenient that would work for the talk. Doesn't mean do it this way. That's a disclaimer. do I not as I do. Yes, it's hard to like show proper formatting with like the files and different things when you're like doing it for the purpose of like a talk or even like here like on a stream or something, but you just wanted to get like the concept across of how you would do it in Exactly. Let's see. Okay, we talked about monitoring and logging. Next, we have error recovery. Uh yes, as I said, errors will happen. Uh that's nothing we can do about it, but we need to recover well from them. And I think the examples for that I said uh so API goes down try to retry the API and if it still hangs uh show uh a message saying we trying like come back in a minute something you know don't just show nothing or outdated data but that will be the error recovery or especially this like retrying API connection will also fall under the graceful aggregation which we keep me mentioning maybe we should talk about that next. Yeah, but the other thing is [laughter] error recovery. For example, imagine you are a user and you are filling out a form and suddenly your internet connection goes down or something. You submit the form and then nothing and imagine it was a long form with a lot of fields and then when you refresh the page everything is gone and you have to start over. So that's a recovery like you would like your application you should really write application so that it stores the data in local storage quite often. So if this happens, if uh there is a issue with internet connection or something happens that the data is not lost forever because I think there is not many things that are worse from a user's perspective as having filled up a form and then you submit and it doesn't submit or something goes wrong and you have to do it again and you forgot to copy a whole lot of text that you had to write into that form, you know. So I think from user perspective this is one of the things that should be really implemented on all forms if possible. Uh what else? I'm just thinking yeah retry connection JavaScript safe forms. Um yeah and again see and implement some type of graceful aggregation. Let's go to graceful graceful aggregation because that answers a lot of things. So graceful aggregation for people who don't know it's um goes by the promise that if something breaks don't break everything which means if something on your website doesn't work it doesn't mean all of your website shouldn't work just make it work as much as possible with limited resources or with limited data whatever it is so for example if uh like I said if an API let's say you've got a I think the example I used in the talk was a website with a weather information for your your city and if the API fails for some reason you don't want there to be just nothing you want you don't want so first of all that's overreacting over ex of over exaggerating but you don't want the website to just display nothing you want everything else to work maybe that one part with the with the where the weather would have been not work but even when that doesn't work because the API is not working you still want to have some sort of information either cache data to say like this was the weather that was fetched I don't know two hours ago try laser something or just even inform the user the API is currently not working come back later but don't just you know show nothing so that comes back to having backup data but also if something doesn't work that it doesn't mean that nothing will work some users might have JavaScript disabled for whatever reason I brought up the code example this is the first one or you're sending a message of we're having trouble loading featured products right now. Here are our newest products instead. Yeah, show something. It doesn't like don't don't let there be an empty space and leave the user wondering what's going on. [gasps] Um, so what was I talking about? Oh yeah, the JavaScript. Some people might have JavaScript disabled in a browser for whatever reason and which I admit will be an issue if you're using a front-end framework like React. I don't know how much would work if you put JavaScript disabled, but generally you still make make it possible for people to view your website or for example if they're on a bad internet connection. I think that's one thing that we don't think about enough because as developers first of all we mainly work locally so we don't have an issue with internet connection a lot of the time but even so most of us I think okay I don't want to generalize a lot of us probably live in cities with good internet connection but there are people that don't and often all you have to do is just venture out into the countryside and you'll find out that your phone is struggling and you don't have data and things happen so or you will have like a 3G which means none of your pictures will load, probably not even styles. So, you should still make sure that your website is legible in some way. You will still it will still display the information that it needs to. Even if it's not as pretty, even if it doesn't have all the fancy animations, it doesn't matter. It should still make sense. So, make sure your HTML is structured properly so that if you remove all the stars and if you remove all the pictures, it will still make sense. It will be a plain text, but it will make sense. So, this is what graceful aggregation is. It means that if something doesn't work, it doesn't mean that everything will stop working. You still the basic what you start with HTML will still be well structured and will be accessible and then you build on top of it. So, uh yeah, polite. There was another examples, but yeah, it all comes back to Yeah. So, uh do you want me to go to the other example or No, I [clears throat] think we've we've covered it. Basically don't don't leave there don't display errors don't display empty empty empty blocks if there is no data always have some sort of backup message or cached data something and inform the user the other thing is I think users are very forgiving if they know what's going on and if you do say on your website I'm sorry like this function is currently not working come back later or try this or something they'll be much more forgiven that forgiving than if they come back to your website and it's just not working and they don't know why and they don't know what's going on. Is it them? Is it you? And users, they will not know that like they they could open a console and have a look at the error. They won't even know what console is, you know. So try to just assume, okay, now I kind have to be careful about how I say it, but think you're building your website and your product for people with no technical knowledge. And it's hard because we have that knowledge. So it's hard to put ourselves into the user's shoes. So maybe find somebody in your family or around you that is not technical and they will be the best tester for you because then you will realize the little things that we take for granted that we don't even think about. I think even like think of it as like if you're building it for a baby or like a todd like some in like someone in like second grade someone very very young you Yeah. Of course, they might be more like technologically advanced [laughter] than probably more advanced. I'm just thinking I think about my kids. Um maybe not anymore, but I used to volunteer for a charity for people with brain damage. And one of the things that we help those people that would come to like it was like a daily thing was help them fill out forms because a lot of them still had like daily things they had to do and pay bills and everything. And it was it was me watching them trying to fill out a simple form and I realized that it's hard. It's hard. So for example, dexterity if they couldn't operate mouse or keyboard. So accessibility is a massive thing. Yes. But also trying to explain to the users this is what you have to do. So one thing that I should have mentioned with the input validation is or inputs in general is to be clear about what you expect the user to put there and on the side of caution maybe be over the top clear in your mind but the people that don't need it they will just skip it they will not read the small text but then the people that will need it will be there for them. So if you have inputs for example for name or no actually website often when you have like a website do you know do you add the https as well or just ww do you even put a www do I don't know sometimes when you add the form it will reject it it will fail because it's not a valid URL but they don't know what the valid URL is so make sure that the information is there and if it's not there then at least programmatically add that at the at the back end so they will just put the website link whichever way they want and you will validate it on the back end and if it doesn't look the way it should the way the database expect then you fix it but be clear with the users because that was a lesson that I didn't know I needed looking at these people really struggling understanding things and operating computer so no definitely especially like putting the placeholders for your different input fields like putting the placeholder that is accurate to how you expect the data to be entered because you might think it's intuitive and you have to like remember like also due to accessibility and stuff but also like our brains work in different ways. So what might be intuitive to you isn't intuitive to me or another user. Yeah. So putting that there is kind of like a fail safe and also like a form of writing resilient code. You know you're writing Yes. Definitely to help catch user errors before Yeah. before it even happens. And I I I worked on a project for a charity for blind people in the UK. And that again I learned so much because there was a lot of forms on that website and one of the things I never realized is that even in the tab you should really so let's say you've got a form and it fails validation when you try to submit it even in the tab in the title of the website you should then display the number of error like write the text so form let's say websitek.com five validation errors it should be in the title or the website dynamically populates it and the Reason I was told is because let's say you've got multiple tabs and as a visually impaired person you will use your keyboard to go between tabs and if you don't know like you won't know let's say you tabbing between browser windows and if it is doesn't say in the title the screen reader will not announce it. So things like that that to us to people that don't need it they're not going to care about it being there but the people that need it for them it's actually very important. So yeah, it's a lot of about accessibility now that I think about it. I don't think I mentioned it in the talk initially but uh yeah having uh like writing the code it's yeah we have to think about developers yes but think about the users a lot more and like a wide variety of users like for everyone. See so we did great graceful de Oh man now I can't I know say it five times in a row it stops making sense. Um then next we have handling third party downtime. Yes. So that was mainly about APIs. So we tried the API connection uh storage. What else? Because we use a lot of APIs. We don't even realize these days. I think we rely on them more than we realize. And APIs can go down because what are APIs? They are built by people like you and me. People that make mistakes. So even if we remove like big things from the equation, it still comes down to all developers are just people and they makes mistakes and we need to kind of understand that and accept it. So if API goes down, it could be a simple error. You don't know. So retry the API have fallback content, cached content. Um what else did I say in the example? Hold on. You had this one. This is it, right? Oh, that's that's Oh, that's the weather. That's what I meant when I said earlier that this this if statement shouldn't necessarily be in a controller. It can be it should probably in the weather service class, but I put it in that slide so it kind of all in one place. But yeah, so if uh the weather API doesn't work, first check the cache content, display a message saying, "Oh, this is a cached content. This is like I don't know two hours old." or just say it's unavailable, but still give the user the message that this is what's happened. Don't don't leave them wondering. So, yeah, they have no clue the weather and then they walk outside and it's like a hurricane. [laughter] No, because it was done. Let's see. Okay, I think now we got to testing finally. Yes, testing. So, how many of us test our code hands [laughter] up? No hands. Um, testing is another thing I need to do more of. I have done testing and like I've used pest for testing and stuff like that. I want to do more with testing, especially like front-end testing, but like whenever I'm spending a lot of time on front end, I don't always write like I don't always default to write writing tests for the front end or doing like test driven development or anything. Yeah. Um, I do think testing is very very important and something I need to do more of. And I think also like I think Kristoff's talked about this in his YouTube videos, but in the age of kind of more AI development now, I feel like tests are even more important. Yes. And it's kind of more important even for like the humans like us to write the test, especially if we're letting like AI write more of more of the code because then it can use that as a guideline to create the code too. Yeah, I I am still kind of on the fence when it comes to AI and I know it's use and it's going to get only worse, but if you ask AI to write your code and then you write AI to test your code, it will test the code it wrote, how do you how can you trust it? Like how it it's kind of testing itself and it's not necessarily wrong as long as it can learn from it. But what if it doesn't? What if it writes an error into your code, something that shouldn't work the way it does? And then it will write the test to it's like a confirmation bias isn't it? It will write test to confirm that the code it wrote is correct not necessarily that the code to test the functionality. So I like you said I would be careful in this age of AI at least read the code because it's so tempting to just ask AI is ask the agent to write it all for you and then you open in the browser it works job done amazing do you have any idea what just happened like do you understand or it's probably not the most efficient way to do it which like I think the way I like using AI is treating it as kind of like [snorts] you're pair programming together so you're not just taking what it gives you, but then you're like questioning it about it and you're checking it and you're like, can we do it this way? Like, wouldn't it make sense to do it this way? And we're using less code and it's like, oh, you're you're so smart. That's right. It always like it's happened so many times to me when I would ask something and then I would know this is wrong. I think I was trying to write something. I don't know what it was, but it kept insisting that there was this class in Laravel that it doesn't exist. And I kept trying and I could getting errors and it wouldn't work. And I went into documentation. I couldn't find it anywhere. So I went back I think it was chpt and I said this doesn't exist and it was like oh yes you're right. I was like you just spent like all block wall of text telling me do it this way because use this class. I was like it's not working. No use this class. And I'm like it doesn't exist. Oh yes you're right. [laughter] I think boost helps with that a lot. Um, which is like why boost exists is to feed in more content into uh or context into the LLMs into the agents that you're using because they have like the contextual gap between when they're developed and then like of course Laravel is always doing updates and things are changing feeding in that context. So it's not just always looking for classes that don't exist but yeah it's definitely something yeah it's train. I don't know about now, but I think last year I asked uh Chad GPT again. I don't use it as much anymore. I use more clothes. Not that it's any better. I have no idea. But at least I asked Chad GPT the uh which Laravel version it was working with and it was like two versions old. It didn't even have the latest version. I was like okay. So that's one thing I have to be careful about. Like you don't know your agent, which lar version it's using, which PHP version it's using. And I know the agents are getting better and better, so it's probably not going to be an issue in the future. But it's just something to be aware of. So I wouldn't use AI to test your code because I'm afraid you would be just introducing confirmation bias and it's just going to tell you everything's great because I wrote it. Of course, it's great. But yeah, I think you could [laughter] use it, but you'd have to like check with it. We also got a question which is more so I think to do with like um the handling third party downtime and the kind of examples we showed but it says when a feature completely fails is it better to show an error message or serve a cached limited version for the user cached version but to the developer error message so the developer can fix it while the user is happy [laughter] you know so I think that showing error to a user has no point whatsoever what are they going to do with the error other than knowing oh this doesn't work and move on. Would this be a thing where you'd have like two different ways of doing it then? Like for your dev environment you would show the error and then for production you would show the cache but also even in production you will still show the cache on the front end but in the same class you will also log the error. So you can do it both at the same time. It's just like the error is not going to show to the user because I don't really I can't that probably is a instance where showing error to the user might be useful but I think overall errors are good that does lead into the like what criteria do you use to make this decision I think it's about uh what are you trying to display or what is or isn't working so if the function that isn't working is crucial in some way and if you need to the user to just stop using I don't know I can't think of let's say [sighs] example example I can't like weather is a stupid example because nobody really real although let's say there's an extreme weather you know okay let's use the weather example let's say there's an extreme weather coming and if your API isn't working and for this there's let's say there's a hurricane coming and if your data is two hours old it's no it's probably dangerous to show to the user this is two hours old come back later No, in that case you would tell them okay error go and check a different website go and check elsewhere because that could be dangerous but for non-crucial or for example if your payment API fails you don't really want like when it comes to money financial stuff like you if something doesn't work you probably don't want the user to continue with their transaction if something failed because could it leads to them losing money I don't know like what could happen but so when it comes to crucial things important things health life matter of life and death money be careful but when it comes to things whether you're showing feature products or not I think you can be a little bit more lenient so overall I think don't display errors to the users unless it's really important but always display like send the errors and logging to the developers so they can deal with it I think that's really good criteria to have because if it's like something critical like that you don't want to just be like oh it's nice and sunny outside and a tornado or something, you know. And then back kind of to test cases, someone said, "Writing test cases for your code is doubting your own coding abilities." No, it's exposing your own coding abilities. Like I think if you can't question your code confidently, how confident can you be about your code? Like, and also I keep saying it, we are all humans and we will make mistakes. uh coding is hard regardless what people try to tell you. It's not easy. It's a totally like a it's a shift mindset shift and shift and the way you think about problems. It's not easy. So and writing application building application it's hard. But you need to be able to question it. You need to be open to the possibility that you've made mistakes because you probably have. So testing is crucial and not just testing like because I think testing is hard but to make it better for ourselves. Okay, I'm going to talk about myself. I don't want to offend anyone [laughter] else but I will write happy path test something that I know will pass because I know it will pass and that in my mind testing done check and I can move on. [clears throat] But have I really tested the application? I don't think so. if I just test the happy path without really looking deep or not. So for example, I think we should test the the failures. So what happens if your API returns either doesn't return anything, what happens or what if it returns something but the data is unexpected. So the API returns 200 but some fields are missing or something. How does your application react? So write test as if you were the user experiencing something going wrong rather than writing test as a developer confirming that your code works as expected because or like trying to break it like trying to do the edge cases, you know, like making sure it only accepts the input um like the data in the format you would expect it to be in or you want it to be in. Um, and I think also like it's important to write test cases not even just for like right now before you like merge it in, but because if people change things later on, like say you bring on bring in more developers or you're no longer on that project, someone else is maintaining it, you don't want them to not be able to make any changes and not know if they broke something because you don't have tests. Uh so having those test cases you could be fully confident in your code now but having the test cases will save people stress later on as well and also you update your application and things will change things you don't even you might not expect and might break um and yeah you should write for yourself but also I find tests to be a nice type of documentation in a way like functionality how things should work because if you have a massive application with files upon files and thousands of lines of code then if you look at tests you will have a better idea like it's good to start with I start I don't know somebody told me oh they always start looking at the routes file when they look at the new application because the routes will tell them the end points and then you have an idea okay these are the endpoints so that's one approach but I always then like to look at the test because the test will then give you more of the functionality not just like what endpoints there are but then will tell you okay if there is a test that will test this that means This is what it has. And often tests are easy to read, especially when using things like packages like pest. It reads as a text. It reads nicely. Like you can read it and you can understand it. It's not abstract. It's not like something you have to look hard long and hard to understand what's going on. No, makes it so nice and easy to read. So use that and use good formatting for your like testing files and stuff to I've got something set up in VS Code. I don't even know what it is. I just save it and it all pops in place. [laughter] So this is one of the things that I have automated. I don't even know which of my extensions does it. But but yeah, it makes sense to have not indented. Well, someone has said, "How often do you use feature flags?" I on my little website. I don't really I don't for like my side projects or anything either. So I not very often. I'm sorry. That's the answer to the question. [gasps] Someone from earlier asks which I feel like we've covered this too and during the talk going over this but it could be a good recap. What are common sources of failure in Laravel apps that resilience should address? So it's not necessarily laral apps. I think it's applications in general and always start so start with user. I think we should think about the user more as developers not just user testing but even when you think of building the application think about who's going to be using it uh the people that don't know how you intended it to be used. So put yourself in the users shoes more. So from that comes the forms because users will interact with forms from that will come error messages. So everything if you start thinking about users and if you think of yourself as the user I'm sure that when you are using internet there will be times when you go on a website and something doesn't work think about it remember it write it down and then make sure that your own application or something that you found frustrating it doesn't work something you found frustrating and that frustration is you being a user not a developer so as a developer use that frustration use that knowledge your experience and try to build your application so that other users don't have to experience the same thing with your application. So I think over like all the points that we mentioned it all comes down to users. Think about users more and put yourself in their shoes and think of yourself as a user as well. And a lot like I know we covered uh what like third party failures and stuff like that too. So thinking about how you're handling stuff like that, like stuff that is out of your control really, but like how you're handling showing the errors for that and like your user's experience if something like that happens that you can't really control as well as like the validation and stuff for like input fields. Um I'd say like that's kind of the failure of like not handling things like that. Correctly in a sense. Yeah. Because resilience isn't about how you structure go. So it comes down to the question right at the beginning using all those principles does it make the code resilient? Mhm. Now that we've spoken about all these other things, I don't really think it does because resilient code is not necessarily it it is about code how code handles whatever is thrown at it, right? And who who does the throwing it's the user or it's like the internet the API. So thing yeah try to be prepared for the unexpected and you can't. So just try to be proactive and have some certain like fail saves in place. And if like an unexpected case happens, right, and you find out about it because someone reports it, then obviously you're going to fix it, but also add in a test case for that because now you know to expect it, so to like add in a test case to make sure any changes you make later doesn't cause that to happen again. Yeah. Or you'll be you'll be prepared. You will know what happened. So Yeah. But as I said, these are so many other things that should could be done. These were just a thing from my opinion the important things. And I think they cover a lot of the user experience. No, I think they're really good, too. We're a little over an hour. [gasps] So, and then we were worried about not, you know, [laughter] are we going to have enough? Yeah. Yeah, we're good. And now we start talking and it's just like, yeah, I think it's a good time to start wrapping up. So there's a question. What's the most common mistake when writing resilient code? Well, not writing resilient code because like when you start writing resilient code, it's not a mistake. It's a good thing. So start I think the most common mistake is not starting there. That's like a that's like a philosophical answer to mic drop. [laughter] It's like okay bye. It's interesting. Yeah. Um no maybe no like thinking about code I think maybe not I think we should always uh take whatever the framework we're using offers first instead of reinventing the wheel. So try to stick uh what's the word like how it's supposed to be done within the framework conventions. Yes stick to the conventions and only move away if you are really positive that your use case is just so special it doesn't work with conventions. So stick with conventions, learn your framework, learn your language. And yeah, I think it could also be Yeah, I was going to say I think it could also be not thinking, not like using your application and thinking from the mind of a user, you know, like not trying to like just think from a user's experience or perspective of like I have no clue how this works. Is this intuitive enough? Like do I have enough um fail say as for like the input fields and stuff? Do I have enough like direction? Do I have like my placeholders? Stuff like that. Also, Zayn did mic drop for you. Thank you. Yeah. So, if you had to do a recap of what you talked about, right, and like what resilient code is, what would be your recap? I think we've just recapped it now. Um, recap. So, okay. Well, let's look at the list. I had I think I had the list on this slide. So to wrap up, yes. So improvisation sanitization, error handling, monitoring, logging, error recovery, graceful degregation, handling third party downtime, and testing edge cases. So these I would say are the things you should do if you can or at least be aware of them. Everyone has to start somewhere. You're not going to implement everything from day one. But and I think overall it all comes back to always think of the users more. I'm going to share this in case it's helpful to like have the list or if anyone wants to screenshot it or anything, but here's kind of the list summary of everything we covered for resilient code and the things you should consider when writing resilient code, which we should all be doing after this lovely talk. Cool. I think any more questions? Have we I think we've covered I mean I don't know. It's it's me being very confident like we've covered it all. [laughter] I guess you I feel like you answered this earlier on too because I think you answered it with the maybe the input validation and sanitization, but if someone was going to make only one improvement tomorrow like to start writing resilient code, what should that be? I would start with the forms. I mean, as long as your website has forms, start with the forms because that's often the first place, if not the only place a user will interact with your website. Mh. So yeah, of course like displaying uh cache content for API failures, that's also but like when it comes to interacting with your website, even like signing up to your newsletter or sending you um an email or message if the form isn't working, if it's not validated, if the errors are not handled well, then they will not get in touch with you and you might lose your potential CL customers or followers before they even get a chance. So start with the forms. I think that's a really good place to start validation. Yeah, someone asked this too. They asked earlier so I want to hit this one too before we end. Should defensive checks be done at multiple layers like controllers, services and models? What's your opinion? I don't know. That's very generic question. I think it depends on your use case, what it is you're building, what it is you're writing. I think also don't get stuck on one thing. Mhm. I think it's better to implement more things even if not fully but have like a wider coverage. So do like the horizontal rather than vertical. Do one thing like properly but then forget all the other things. So maybe start with I don't know doing one thing well doing everything with the across your code base and then go down the multiple layers but it's difficult to say without knowing the use case and you know how things are built. Yeah, I would agree with that because I think sometimes it also matters of like convention for the project you're on if you're in a bigger project and stuff like that as well and who you work and we all work within our within certain constraints like we all might want to do tests but if you work for a company that doesn't really give you much time like nothing is perfect and in a perfect world we would do everything all the time immediately but really we don't live in a perfect world and it never works this way so just pick your battles. But I think as long as you are all aware of all the things it starts with that that's where it starts. Doesn't mean we're going to implement everything immediately but start with thinking about these things being aware and take it from there. And I think that's a great place to leave it too going to wrapping up. Uh so thank you so much Zana for coming on today and going over how to write resilient code. I think this was a great talk and kind of recap like discussion of the talk as well. There's a lot of things like I want to do after talking about this. Also like dive into the hosting which [laughter] we didn't even really cover but also doing more testing. I really want to like go my side projects and like add in tests and stuff after talking about this. Um I think my forms are good but I will start there double checking everything. Don't people will go and check your forms and they'll try to break in. You know what you Jeff you should have said that they're not well they are hosted but I think the URLs are hidden hopefully. Okay. [laughter] Yeah. Thank you so much for being here today. Is there anything any closing words you'd like to say about either writing resilient code or where people can find you? Um stuff about Larabell. Oh I know you'll be at Lari you too. Yes. Yes. Would be lovely to see people if you are coming to Amsterdan. And for so Larabels we have merch. I'm bringing t-shirts. I'm bringing like 24 t-shirts with me. I'm just the one person [laughter] bringing a lot of t-shirts in my I want a t-shirt. Save one for me. Yeah. Okay. So, we will have finally some t-shirts are coming. So, if you are in Amsterdam, come and say hello. Uh even if we don't know each other, just come say hello. And yeah, so to find me, don't find you can't find me on my website right now because it's I can't even say find me on my website, but you can find me on larabels.com or social media, which I don't really use very much, but I'm there. Um, but yeah, eventually you will be able to find me on my website when I figure out what's wrong. [laughter] There's lar.com. Yeah. Thank you everyone for being here. Thank you. We appreciate it. Um, and yeah, if you're at Laranu, please go say hi to Jazanna. I'll also be hi to Oh, yes. Yes. Say hi to me as well. And Marca will be there as well. I mean, the band is back together. We're back together and you come talk to us about Resilient Code. We'd love to chat. [laughter] Okay. Or just in general. But thank you all for being here. Bye. See you. Bye.