Notes On Work - by Caleb Porzio

Isolate variables, speed up feedback loops. This is the way.

Get off youtube, put your feet on the ground.

I've been doing a lot of fly fishing. Let's talk about it.

If I had to re-write everything, i'd be tempted to double down on a technique that feels icky and some people would hate me for.

Wanna hear a fun story about a bug I fixed this week?

Just tagged 2.3.0. Let's talk about it.

You guessed it!

Livewire is death to boilerplate, but when is it too far?

I have an idea that I want your opinion on. Feedback here: https://laravel-livewire.com/consult

Wanna hear how ridiculous Safari is with it's autofilling system? Life is hard.

...

...

Come at me bro.

Maybe THE most identifiable pattern of the internal experience as a web developer

I just gave a talk at Laracon Online. Let's talk about what went into it.

I created an inner circle for both projects. I'm dismantling it. Here's why.

I know, I know. Refactor incrementally with a test wall at your back. To that I say "pssshhhhhhaaaaa".

I'm making a refactor I've wanted to make for a loooooong time right now in Livewire's JavaScript: De-object-orientifying it

I just launched a course on VS Code. Let's talk about the money.

I accidentally killed controllers.

The title says it all

I'm building a landing page for my upcoming course. It's hard.

The music that shaped me

What's the future of Livewire? Well, here it is.

Slots. The people have spoken. They want them. Here's why it's hard.

I've been struggling to do the work that matters most. Here's why.

Let's talk Dusk (The Laravel browser testing framework)

No

I know you probably read "Lunch", but unfortunately, this episode is about treating everything you do like a product launch. Even if it makes you no money, if for no other reason than it's way more fun that way.

I used to build things in the exact opposite order that I should have: Build thing, then market thing. It's a huge mistake lots of people make. Today I'll tell you a story about how I'm validating an idea I have before putting any effort into actually building it.

This is a question I encounter in every single codebase I've ever worked in. Do we group things by "Function" or by "Feature"? The Livewire codebase is no exception. Let's talk about it.

Let's talk about the current refactoring I'm in the middle of.

"Always Be Tweeting" - that title is gross. I'm sorry you had to read that, but maybe listen to the episode and see if it sounds less gross afterward.

I'm working on a much-requested feature for Livewire and I want to tell you all about it: File Uploads

This episode we talk about 2 new features I'm stoked about: The back button (moving from replaceState to pushState) and lazy script tag evaluation.

Today we talk self-forgiveness. I do stupid things and receive criticism all the time. Dealing with that is a necessary part of the creator's journey. Let's talk about it.

This episode is a lil' different. I'm joined by my good buddy and (other) podcast co-host Daniel Colbourne. He's using Livewire for the first time and has some things to say... particularly about the docs. It's a good time.

As I fight "the war of art", I'm learning more and more about myself and the way I work every day. This episode I talk about my weekly workflow and how I leverage meetings and commitments to do my best work.

A new superpower I've been discovering is writing drafts religiously. Any thought or idea I have, I throw up a draft. What can hurt? It has lots of benefits and I'll talk all about them.

Writing code and solving problems is fun. Writing emails, blog posts, podcasts, screencasts is NOT FUN (most of the time). I repeat: NOT. It takes serious effort and discipline. That is why it's worthwhile. In this episode I talk about my journey from programming to communicating and the struggles and wins along the way. Dig it.

Hello friends. I am back with another episode after a little break. Ah, episode 31 I finally feel great about Livewire. It is very true. Uh, so tomorrow I'm going on virtual stage at Laracon online to release live where 1.0 and demo sort of the state of Livewire, how I am building things with live wire these days to everybody. And also Alpine. And I've got to say, I feel fricking great. I really do. Um, I don't know if I've ever felt this way about Livewire. So Livewire is one of those things that, it's controversial, it's radical. It's very different than any other way of building apps. And it all started with that little seed of that Phoenix live view post where I just saw this, this basic concept of like. Making a click handler in the front end, run a method in the backend, rerender some HTML and swap it into the page. That was the seed. And then basically fast forward one year on this journey of me pushing this paradigm as far as I can and seeing if I, if seeing if it's a good pattern, if it's something that that is beneficial, is better. There's obviously some clear advantages, but, but is it workable that that question always lingered for me. It's like, is it a, is it too much magic? Is there too much magic going on? Is this like not going to be, I don't know, future-proof or whatever? I don't know. All the things that you've, you feel when, when something is, is really magical. Is it too much magic? Is it, is it too slow? That was the biggest one. That is by far the biggest one. All right, so we're using WebSockets pretty fast. I type into the browser, sends a WebSocket request to the backend, comes back, it's pretty darn fast. Um, you know, I click a button and a modal shows fairly fast, feels pretty much instant. Can't use WebSockets PHP suck. Sorry. Use Ajax now. Clicking a button to show modal could be anywhere from instant to laggy, like 250 milliseconds or something. Oh, maybe Livewire is not. Is not the tool, but I kept pushing and I kept pushing and the thing that I would always come back to that I for myself is like, all right, if I throw live wire out the window, I'm basically going to end up rebuilding it myself. I never threw it out the window. The way that I love to build apps is really, really simple. Plain blade, and if I need some complex interaction, I try to push this server fetched partials pattern as far as I can where you're sending an Ajax request to get HTML and swapping it into the page. And so basically, I've gone to this thought process a hundred times where I doubt myself so much that I throw it out mentally. Like really go there. Like, like a stoic, like, like a really like put yourself in the place of the worst possible outcome in your mind. Put yourself in that place. Livewire is not good. Um, the, you know, inertia or whatever, other ways to build apps are much better. And then honestly, uh, you know, once I shed that, that I don't know if it's fear, uh, defensiveness. When I shed those emotions, I end up recreating Livewire anyway for myself. That's what's kind of kept me going. And honestly, at the end of the day when it's dark and it's quiet, I love writing things with Lifewire. It's a really fun tool. I have so much fun doing it. It removes a lot of the pain and annoyances, um, of any other paradigm that I've used. Okay. So is it slow? Yeah, yeah, yeah. It might be too slow, but here's, so here's the big revelation that that started to really hit me. The last episode that I published called building, I think I published it. It's at least sitting in the app I'm using to record these things. Episode 30 building, building Trello. I can't even see the rest of the title. Something about building Trello with Livewire and that realization, I had that like, Whoa, you if live wire works well enough with JavaScript. Then it you can use it. It doesn't have to be any less efficient than any other paradigm. It doesn't have to be any less efficient than using pure view because a lot of your view components are sending requests to the server to do stuff and it gets stuff. So the same can be done with your Livewire components and then the parts that you wouldn't want to make a whole request. That's fine. You know, use, use JavaScript for that. So I made that Trello thing where I had sortable and draggable and I was basically building an optimistic UI with live wire in. It kind of blew my mind. It was like, Whoa. So Livewire is more of an API interface for me mentally than like a full on front end framework. Or at least you can think of it that way. Anyway, this is a lot of high level talk, but, uh, Alpine was born out of Livewire because I had this need for like, all right, but what about drop-downs and modals and tabs? Those are like the three things that bootstrap always gave you out of the box. And they got, you know, they, they got you pretty far and now we're using tailwind and BOMA and those things don't exist. So what do we do? And Alpine JS is my answer to that. And it star

Hey friends, lots of new things are going on in my life and I don't have time to tell you about all of them, so I'm just going to pick one. You know what, I'll preview all of them and then I'll tell you specifically about one Alpine is popping off. Um, I think it's hilarious how I put a year of my life, like full time weeks into Livewire. And worked so hard on this thing. And then Alpine, I just kind of like farted out and it's probably going to be way more popular than live where it's like the universe is cruel joke on me. Um. But it's not, it's not entirely accurate because a, I basically wrote Alpine for Livewire. You know, like I, I had already learned how to write a front end framework, so it was really easy for me to write. And it came out of months and months and months and months of just kind of like chipping away at a problem. And then, I don't know, the solution just kinda hit me all at once. Um, and Alpine is in the JavaScript community and who doesn't love a new JavaScript framework? Like, Oh, it's crazy. You want to be rich and famous. Just build a JavaScript framework and everybody will think it's the hotness for awhile. We'll see if it stands the test of time. I mean, I think it will, um, because it is different than it's been. It's the stimulus killer. Like if you've used stimulus, I hate stimulus stimulus sucks. Um, I'm sorry that that was rash of me. Stimulus is great in its, uh, ethos and philosophy, but if you ever wrote it, it was LA, LA, LA, LA, LA LA. I do not like it. So Alpine in my mind is the stimulus killer. Um, so I've been refactoring people's stimulus code to Alpine and haven't really run across any shortcomings yet. I mean, stimulus is so simple and dumb anyway. Like it's, it does even more than it. So. Anyway, enough trashing stimulus and hyping my own thing. If you're interested in Alpine, go check it out. It's pretty exciting. Okay. That's Alpine. Um, Oh. Which by the way, is the new name for project decks. If you didn't follow that at some point, cause I realized I didn't record any episodes since I talked about project ducks, but that's that. So live wire onto Livewire. Um, I am very excited about live where I'm going to be launching 1.0 at Laracon us in fee or lyric on online in February, and that's going to be pretty great. And, uh, but basically, so what I want is to get it, I want to build an app with it personally and get it to where I want it to be. Um. And then launch 1.0 so now I'm in that phase where like, okay, I have to start building things myself with it and putting them out there. So I'm going to create like inertia has pink CRM. It's like a little sample app you can download. It's written with inertia. Livewire needs, something like that for sure. And I've wanted to do it for a long time, but I've just, you know, kicked the can down the road. Well, I'm, I'm now, I'm drinking from the can. Is that the proper metaphor? So that's what we're going to do. I'm going to create an application. And it's going to be open sourced and it's going to be my idea of what a perfect application written or what perfect live way or whatever. How I would write an application with live where it, my goal is to make it your everyday average layer of El app with tables and forms and modals and dropdowns and slide outs and. Date pickers and blah, blah, blah. Maybe some comments, maybe some real time chat, maybe some infinite scrolling, maybe some deferred loading. There are tons of opportunities there, and I may a record screencasts about the whole process and put them into a course or a paid subscription thing like Livewire casts. Because, uh, your homeboy has to make some loot on Livewire pretty soon before he goes broke, or his wife kicks him out of the house and makes him get a real job at a local Costco. Um, so barring that event, uh. We'll see what I'm going to do with that. So keep your eye out for that. It's actually been really fun already. Um, I haven't the master branch open in one tab of Livewire and then I have the app. I'm building, I'm calling it project L, by the way, because I punted on the name again. Um, and I have project L open in another tab. And as I work on it, basically my, my goal is like, I want it to be perfect. So anytime I encounter anything that's imperfect, whether it's Livewire or Leora, Vel I will attack the problem. So that's what I've been doing. So if I already like made a ton of changes to my local Livewire installed to make the whole experience just better and to, you know, hone it, um, because now I'm using it. And I want it to be perfect. So, uh, also Laravel I encountered something I wanted and Caravel I hit up Taylor and he liked the idea. So I PRT it to the framework. It's a tiny, tiny thing. But, um, he's totally on board with, with, uh, terraforming of Vela. That's a big word. I'll just say with making changes to layer Velda support live wire and make it better. So that is huge that I have his support. Oh, I haven't even got to the trai

Hey there. So let's talk about project X. Maybe you've heard of it, maybe you haven't. So I had mentioned that that last big problem and its solution came out of a conversation with my buddy Mitch Mitch Jameson. He's the best layer of El programmer. You've never heard of. Um, best friend slash brother. Of mine. Um, he not actual brother, but pretty freaking close. Um, yeah, he's a smart guy and I sat down with him and we have some stuff out and after we figured out this, this problem, this big, uh, w I actually want to record an entire episode on him. Um, there are, but I'll, I'll just say this like, it's super important to have people that understand the work you do. And for me, there's not too many of them in real life. My family is not technical. Um, I have technical friends, but not a lot of them live in the area. So I have just a couple. And they're my friends who I see in person often, and they understand what I do because they do it too, or they do something adjacent to it. And it's super duper valuable to have people in your life who you can talk to about your work, you know? Um, in, in my case, my work slash passion and Mitch is largely that person. And I say that under, I want to say understand the work that you do, like, understand your app. Like if you don't have somebody who you talk to a lot. About code. Like if you do have somebody who, you know, I'm talking about, like you get to know each other's projects because you hash things out together and you end up kind of knowing actually a surprising amount about their projects. So I know a decent amount about the project he's working on in his job, the architecture decisions he makes, where they're at in the process, the things he sort of struggling with. And he understands live wire on a pretty deep level because every time I come across something. We sit down and he and I walk them through it and he'll close his eyes and try to wrap his head around it. And neither of us settle for not understanding something. So we, we pretty much never say, okay, unless we actually understand it. And we forced the other person to explain it to us, um, more simply or concretely. So anyway, great guy. Great to have him in my life. Thank you, Mitch. We're sitting down, we've conquered this big problem sort of, and I feel like I have a moment of clarity and I've kept that clarity. Um. On on that problem. And then afterwards I said, all right, now let's, uh, let's tell of all of Livewire. And I'm like, we're on a roll. Here's the last piece. So I did these rounds of little interviews or. Video calls with people to kind of check in and see the heavy Livewire users in the community and check in and see, Hey, how do you like it? You know, what have you, what issues have you come across? What things do you like, dislike? And one of the things that came up multiple times is, well, I don't, I love it, but, uh, you know, when I need simple JavaScript functionality, like honestly, like a lot of it's like drop-downs and noodles and stuff. I don't really know what to use. I use view components because, you know, they work with live wire, but they seem a little heavy handed. And you know, my recommendation has been, yeah, I mean, just right. Vanilla JS, but that kind of sucks. Like. It. It just does. Um, yeah. I guess I don't have to explain myself there. There, there needs to be some middle space between writing vanilla Java script by hand, which makes you feel like you're using jQuery or something and you know, loading all of the world of view in the virtual Dom and all this stuff, like having a view component and a whole build process and Laravel mix and the whole world that kind of draws you into it. What's in the middle. So stimulus is in the middle. Stimulus is a humble JavaScript framework. I think that's how they market it. Like humble JavaScript framework that for the HTML you already have or something like that, which is great. There's no virtual Dom. They don't destroy your Dom. They, they, um, they give a lot of power to you. And the idea is that you can use it with traditional server rendered apps and not have to buy into the whole thing. And I have to give away your entire front end. So it's pretty great and that, you know, in that way. So I've always agreed with the philosophy of stimulus, but stimulus itself is really painful to me. Like I think it's really gross. I don't like it. I don't like the way it looks. You add all these data attributes everywhere and you kind of create your own framework and then you have a JavaScript file that. Kind of maps to your, your controllers, as they call them, which are kind of like components. Um, and you end up doing a lot of native JavaScript in there. And I always feel like, I dunno, I feel like you're kind of reinventing the wheel. Um, from what I've seen from it, I haven't actually used in a production project, so I should say that we're in a real project even. But anyway, Adam way hasn't showed me around his stimulus.

Hey friends, it has been a tiny bit. Uh, I'll have, you know that I actually did record a bunch of episodes, but. I wouldn't publish them right away and then I would delete them when I went back to record another one because I don't know, that's just kind of how I am. If I don't get something out right away, I end up second guessing it or looking at it and thinking, Oh, that wasn't well done or it wasn't clear enough, and I'll delete it and then just start something else. So, um, that's a bad habit of mine. And I've, uh, done that for the past, like month, almost a month on this podcast. I swear I've deleted. Probably over six or seven. Um, but that's over. So the big update, um, there's been a lot going on with Livewire and that's partially why they been so many videos and partially why I haven't published them, because it's confusing and it's hard to explain and it's frustrating. And I don't know. I don't want to drag you down with me, but I think, uh, or I'm at a point of clarity. I'm at a point of decisiveness, so let me catch you up a little bit. Um. I've, I believe I've done an episode at some point about protected properties, but here's, here's kind of the gist of this. This is the biggest problem in Livewire, quote, unquote. That's what I titled the, this forum posts that I made. Oh, by the way, there's a form. You should check it out. There's a forum post called help me solve the biggest problem Livewire, and this is, this is, this is a problem that has sort of, I don't want to say haunted me, but it's been around since almost the beginning. So here's the problem statement. Live foyer. Livewire, Livewire Livewire PHP is a one shot deal. When you make a layer of all requests, the whole thing just runs and then spits the HTML out to the server and then the user triggers some update, like a URL change, and it does that. Again, their browser, however, has a long running process, so that's why VJs and these other Java Java script is a, there's a runtime in the browser and it's continuously running and waiting for user interaction and whatnot. So in Phoenix live view, a Phoenix or elixir on the backend is a continuous process. So they can create a parody between the backend process and the front end process. So the user's browser session with their JavaScript, and then the servers backend session. Um, and there can be a one-to-one, so there can be a process for user on the page. So they can do all sorts of nice things. Well, I chose really, really early on to not go that route because PHP just isn't there yet. And our PHP WebSockets and an asynchronous PHP, um, there's, there's stuff about it and there's stuff out there, but they're either require extensions or fancy things that just nobody wants to fanangle with finagle, finagle with. Um, so I chose early on, let's just do Ajax. Let's make Livewire. Let's make it's network transfer protocol, Ajax, and so Ajax is stateless. This is a fancy word, but what it means is so a long running incident, instances, state full, it has a state, you can change it, you can mutate it. It lives in one place. Stateless is something that gets passed around, so live where actually lives in the request and response data that goes to and fro a server. I guess Livewire on the front end is stateful, but on the backend it's stateless. So Livewire keeps, keeps track of what the current state of a component is. Then when you make an update, say a click on something that has wire colon click, it sends an Ajax request with the payload back to the server. It hydrates up the component, um, and then it does a taction and then a dehydrates it back to the new data in HTML, puts it back on the front end and rinse and repeat. So I've probably said that a thousand times. I hope you understand that by now. I think that's something that, that's one of those big key pieces of knowledge to understand. And if you didn't build Livewire, I can imagine it's frustrating to wrap your head around and seems odd. It's like hearing a Ave talk about the virtual Dom and how it just means nothing to you. But if, if you had built it, you would understand. And it's not rocket science. Um, but it's just one of those things that, that, uh, you have to kind of open, open it up a little bit to understand or inspect your dev tools, or, I dunno, hear me spew it enough. Times to understand it. So that's the nature of this problem. Um, the problem comes from, we don't have a long running back end PHP instance. So how does this problem manifest itself? So basically all of the data of live wire gets transferred back and forth, like I said. So if you set a, um, you can pass data into a Livewire component right. So you could presumably pass in an eloquent model. And the first thing people tried to do when I launched live wire was save eloquent models to properties. So they would have a property called post, and they would, you know, set post to an eloquent model out of the database. And then they would get an error that

All right. So I started recording another episode and basically ended up just talking about where Livewire is headed and thought, well, why don't I name this properly? So calling this current roadmap, I cut the episode off early and I'm just going to rerecord it. So the. A current roadmap of live wire, so live where I'm just wanting to give you an idea of where things are at in my brain and with the project and whatnot. So I've talked about it at two conferences now, a bunch of meetups. There's a good solid amount of people in the repository submitting issues and some submitting pull requests and moving the project forward. I'm pairing with people. I've had. Uh, I'm going to basically have like five pair programming sessions this week, total one last week where I talk with people about the project, about their issues with it, things. And these are people who are using it and who are in the repository every day. Um. So that the original episode was called keeping my finger on the pulse, and maybe I'll record another episode talking about that, but for now, I just want to give you the roadmap. So the project's getting more solid. When I released it at lexicon con, I felt like it was cool. I felt, I felt like the API was there. I felt like I knew, I felt like it was good enough to tag a 1.0 in terms of API. But I didn't feel like it was there under the hood. Um, pretty much the main reason being that it's, it's like 60% JavaScript or 50%. I don't know it, it waivers between 40 and 60% of Javas JavaScript, JavaScript core. So the Java script part, that's the tricky part. That's the part that I have to deal with. Browser support, Dom diffing woes. Hear me. Yeah. Um, that's the big one. That's honestly the big one. Um, a lot of that stuff. So making the, making it, you know, it's a pretty ambitious project in terms of implementation. Like I'm just solving whackadoo problems all the time, and I want to make sure that a lot of people have used it and tried it with different things and it works seamlessly. And I'm just now feeling like we're getting to that point. I'm just now feeling like I'm starting to see that it seems like there's a lot of issues in the repository, but a lot of them are related and now I can start kind of closing them in bulk. And a lot of them are related to dumb diffing. And as I, as I hardened that core, um, those things, you know, just get addressed as we go. So I'm feeling good about the project. I'm feeling like it's much more dependable that I'm having these conversations with people and they're going, you know, I'm asking you what are the issues you're experiencing. They named one or two that's known or that I already fixed, and then they say, but honestly, that's about it. It really kind of works for me. It just works well. I don't know, and that's really good to hear and I'm hearing that more. More and more. Um, so that's good. Alright. So, and that's the thing I kept telling people and they're like, well, when are you going to tag a release when it and I S or what are your plans? And I, you know, when I'm standing at the press releases and everybody's, you know, shoving a mic in my face, like, what are your plans with live layer and wait, okay. Um. Yeah. So what am I plans at that time? I said, well, I'm just focused on getting the core heart. And at the moment I'm not gonna do educational materials. I'm not gonna do pro subscriptions or anything like that. I'm going to make the core, you know, ma, you probably have heard different things along the way, cause I often do have ambitions, but I've, every time I settle them back and go, no, no, no, just make the core hard, get people using it in production, get a wide user base that's dedicated. Make a tool that's very useful and very good, and then all these things will be added unto you. So that has been, that has been my thinking, and I feel like I'm reaching the end of that point. I feel like I'm, I'm not gonna give a timeline, but I feel like we're headed in that direction of me feeling like this is a good tool. It's pretty solid. Now let's start building stuff with it. Let's start teaching people how to build stuff with it. Let's tag a 1.0. Well, let's offer, you know, enterprise support. Let's, let's really make this thing happen. Which is funny because it's, you know, this is like, we're going on 10 months here. I'm, this is, I'm in it for the long haul. Like I'm in the long game. And that's something I think about more and more these days is like, that's a lesson I'm sure I've talked about before. Huge lesson I've learned with this tool is like, okay. Um, be in it for the long haul. Like, don't, don't play the short game, play the long game. And, and, uh, I dunno, I'm calmer about it now. I'm not as worried about another tool coming up that's bigger and better or something. Like I'm just kind of focused on this and making it good over time. Um, and eventually. With enough effort and with enough a heart, I think it will, um, get,

Hello again. Uh, this is a serial episode, so I'm recording this one second after I just recorded the last one. So the last episode, we talked about these hard validation problems, and hopefully I illustrated to you some of the issues that really STEM from a difference that I wasn't aware of that I wasn't really, that I hadn't formalized, but I cleared up the difference that there's two types of valid two types of things people are trying to do in an app. Then I was able to solve it. When I separated out into two separate methods, validate and validate only, and I think it's going to be intuitive. I'm going to document it up and I think everybody is just going to think it. Uh, it works the way it should work and I'm, I'm so happy with it. Half. So happy with it. Like I finally, this has been. Something nagging in the back of my mind that's not perfect. And now in my mind, it's perfect in my mind. Maybe it's not in reality, but I think it's perfect. So I'm putting it to bed, um, and I can move on with my life. Uh, but this brings me to a bit of a bigger discussion. Um. This problem I, there's two ways I could have approached this. So, you know, the way I did approach it, um, I also could have approached it a different way, which is actually how I started approaching it. I. You get an a get hub issue where somebody says, Hey, it would be cool if the validation persisted from request to request, you know? Oh, yeah, yeah. Okay. We should make that available. Well, how do we do that? Maybe we'll add a config option. Maybe we'll add someone. How would we configure that ability? Okay, well, what if we have a trait called persists validation that maybe you just add used, persists validation. We document it. Okay. Right, right. So that's fine. And I actually started that way. I actually have a trait in a sample app called persist validation that I was messing with, and then, okay, that real time validation, they want maybe have a thing called persist validation and only validates specific fields or whatever. Okay. Maybe we have used real time validation, whatever. You just keep adding in these options. That describe the functionality, but they don't describe the use case. Um, and this was the road I was starting down, but it felt fuzzy to me, and I just hate adding more documentation for specific functionality that you have to now understand and know you have to understand everything that I understand and, and it's hard for me to understand this stuff. So why would I burden every user with that? So basically I had a choice. And I've had this choice a hundred times in Livewire, and every time I come across this choice, I don't realize it. It is that choice right away. But when I do realize that it's a choice between an invisible feature and a visible feature, and by that I mean an invisible feature is something that user will never notice. A visible feature is like them looking up how to do a specific thing and adding a trait and whatever. Once I realized that it's, that, that, that, uh, that fork in the road, I just. Choose the invisible, the invisibility route. I just go with the invisible. Um, and that, that's been my path with this whole Livewire thing is like, find the way that people expect it should work, which is so hard. And it takes like, user testing is super value. Interviewing people, using it yourself, dogfooding it, thinking about it a lot. Um, those are all the things I employ to anticipate how a user. Would expect it to work and then make it work the way they expect it to work. So basically I picture, like I picture a cartoon character, like walking in space and the road is like filling in as they walk, you know, like, it's like. The road is maybe it's like a brick road and the bricks are floating up from the abyss and just kind of assembling in front of them and maybe their eyes are closed in, they're whistling a happy tune, and they have no idea that if the road stops building itself, they'll fall to their death. But it's just magically happening as they go. I think that's the, the, and now I literally just came up with that right now. Um, it's pretty off the wall, but, uh, I think it's actually kind of. I think it's kind of accurate. That's what I want Livewire to be. I want it to be a road that assembles in front of you and you have no idea. You think you're just walking and whistling and happy tune. But underneath the hood there's like crazy stuff happening, you know, to make this happen. Um, and from an implementation perspective, I tend towards the simple implementation. I tend towards wanting it to be a simple tool with a bare set of, that's another balance. I'm, everything in life is balances, but that's another balance that competes with this value of invisibility. The value of a simple implementation, a simple set of tools that the user understands and can manipulate. I think of it kind of like the react versus view dichotomy where VJs has a lot of, um, it has a wider API because it caters