TopPodcast.com
Menu
  • Home
  • Top Charts
  • Top Networks
  • Top Apps
  • Top Independents
  • Top Podfluencers
  • Top Picks
    • Top Business Podcasts
    • Top True Crime Podcasts
    • Top Finance Podcasts
    • Top Comedy Podcasts
    • Top Music Podcasts
    • Top Womens Podcasts
    • Top Kids Podcasts
    • Top Sports Podcasts
    • Top News Podcasts
    • Top Tech Podcasts
    • Top Crypto Podcasts
    • Top Entrepreneurial Podcasts
    • Top Fantasy Sports Podcasts
    • Top Political Podcasts
    • Top Science Podcasts
    • Top Self Help Podcasts
    • Top Sports Betting Podcasts
    • Top Stocks Podcasts
  • Podcast News
  • About Us
  • Podcast Advertising
  • Contact
Not in our directory?
Add Show Here
Podcast Equipment
Center

toppodcastlogoOur TOPPODCAST Picks

  • Comedy
  • Crypto
  • Sports
  • News
  • Politics
  • True Crime
  • Business
  • Finance

Follow Us

toppodcastlogoStay Connected

    View Top 200 Chart
    Back to Rankings Page
    Technology

    Notes On Work – by Caleb Porzio

    Brief thoughts and insights from Caleb. Mostly on work. Mostly while drinking tea.

    Advertise

    Copyright: © 2024 Caleb Porzio

    • Apple Podcasts
    • Google Play
    • Spotify

    Latest Episodes:
    The Evolution Of The Make Command Sep 20, 2019
    Show notes

    [00:00:00] Caleb: Okay today I have this is a really fun one for me. It's pretty light on on the actual programming. So you shouldn't have to wrap too much around your head. But yeah, so Artisan, it's all about artisan. Make Live Wire that's what we're going to talk about artist and make live. Where is the first command you run when you're working on a live where component it creates your class and your view for the component and it should feel pretty natural.

    You say artisan, make: Livewire counter and it creates a counter class and it creates a counter blade View and it's a simple as that. And this is an invisible feature this to you should feel natural and you should never think to yourself. Oh my gosh Livewire. It's so magnificent. This is so clever.
    You would think this is the obvious command for creating a component. Unfortunately. This is kind of the nature of these problems is that I almost never arrive at the obvious solution right away. It takes time. So I'm [00:01:00] going to tell you A Tale of the evolution of the Live Wire make Command and how it got to become an invisible featured like it.

    So my knee-jerk reaction for a command will first I didn't even have commands to make to make live where components but I thought you know, wouldn't it be really nice if there was just a built-in, you know, make live where right. So at first it was Artisan Livewire: make because all my Live Wire commands were artists in Livewire colon, and then the command which makes sense you would sort of namespace that under Live Wire that makes sense.
    So I had Artisan live where: make then you would pass in the class kind of like you. Taking a test in live in laravel. So if you wanted counter you would do capital c. If you wanted a subdirectory, you would say components. Let's say it was components directory components backslash backslash counter just the way you would when you're Artisan making a tester or anything.

    So that's what I initially had because that's sort of what felt natural in the moment [00:02:00] a couple Hang-Ups with this. One of them is that I would have to create the view manually. So every component has a class and a view and my first error was sort of thinking was just naturally I was. Of Livewire components as the classes and that the view section the template section was sort of secondary to it.

    And that's my first mistake. I've slowly changed that thinking well, I guess I've if I thought about it, I never agreed with that way of thinking but that's just how I naturally approached problems like this because I had that in my mind. So that was the original incarnation of of Livewire make it was Artisan Livewire make and then the class name and then you had to create the view separately.

    I had thought about create adding some sort of option or tag that you could do - - view to create a view as well kind of like adding a migration and a factory when you're making a model. The reason I resisted this is because I know in Lawton laravel, there's no artisan make View and that's something that I've looked for in a lot of people look for there's no artisan, make View [00:03:00] and I've read.

    There's been pull requests for it. There's been comments and GitHub issues about it, but it's always been rejected. And I think there's even a third party package. I want to say by Yaz. I don't know maybe not but there's a third party package. I believe that offers this functionality for creating a layer of Bellevue.
    And I think one of the things is that unlike like a view, you know, and it's not as opinionated in laravel. You can customize the views directory and it's an array so you can add multiple directories for views so for reading that's fine, but for writing you have the decision of which director do you write to so that's probably one hang up the Taylor has I don't actually know the full story behind all this but I'm guessing that's sort of a.
    So and maybe it's also like when you're creating a view there's really no like boilerplate. It's just a file, but I know that I would like the ability to create a view in the command line because it just saves me having to right click new file in the right folder and type in the name. [00:04:00] So anyhow with Livewire I just immediately just thought that that was a bad idea because I guess Taylor thought it was a bad idea.
    So I just shouldn't do it. So then I was actually just going over some of my user testing notes. This is great because. I did a bunch of user tests with live where that's a story for another time how important user testing is, but I did a bunch of user tests for Livewire and I wrote them all down.

    I wrote notes for all of them inside bear. So I just kind of searched user tests inside my bear Notes app and found all my live where user tests so I'm sort of flipping through and I find David hem pills. He's one of the first user tests. I. And I read through the notes and one of the notes says this is really funny because I totally forgot about this.

    It says create view by default. No need to add - - view so maybe I had - - view available at this point in time, but he probably was like, oh like you should just create the view by default. I'm like, really you think that's okay and he's like, yeah, man, I would want it then he gave me permission.

    Basically, I needed permission. [00:05:00] And once he gave that permission me, I was like, all right, let's do it. Never looked back never look back completely forgot that it didn't create the view by default automatically, then there's no other way. It just creates the class and the view for you right now.

    So that was the first obvious Improvement was like well, yeah create the view and then that became invisible. Nobody cares. Nobody goes. Oh how cool it creates the view for you. They just go that's that makes sense. Okay, so the second thing is Artisan Live Wire make. And then the class name, I would accidentally type artisan make Livewire and then I'd have to you know, backspace backspace backspace and then correct myself and when I was doing these user tests and I did it, but I never noticed it.

    It's just kind of my knee-jerk reaction. I didn't really think much of it. So I'm doing these user tests and I'm finding most people are doing the same thing. Most people forget. If it's Live Wire maker make Live Wire and they default to make: Livewire because every other artist in make Command is that way make: test make: model whatever.

    So that [00:06:00] was one of those things that just came out of me really putting live wire through the fire as far as user testing and seeing that that's the way people's brains worked. So I thought well. I should change it to Artisan make live where because that's the natural thing. That's what people just reach for so I changed it and it became artisan make live.

    Okay. So the next Improvement is it was you're still were specifying the class and that felt weird because it somehow felt like the class was a priority. Also when you're referencing a live wire component you would do at Livewire. Oh my gosh, I'm remembering things at the time when you included a live where component so right now with the counter component you do at Livewire and you pass in a string lowercase.

    And if you have multiple words, it's Kebab case hyphenated. Like some counter would be some - counter right kind of like blade views same kind of casing so in the make Command. Well, sorry before in that in that blade directive. I didn't have that [00:07:00] ability. Mostly it was actually offered both out of the box.
    You can reference the class directly the component class. You could say at Livewire a. Backslash HTTP backslash Livewire backslash counter colon colon class or you could register an alias like you would in laravel component so you could say like Livewire. Counter and then pass in the component class.

    ...

    The Name Sep 20, 2019
    Show notes

    [00:00:00] Caleb: Okay. Today. We're going to talk about Livewire the name. Where did it come from? How did how did we get here? What what changed along the way and what are some of the problems that I'm still coming across? So Livewire as you know, it was inspired by a package called Phoenix live. So Phoenix is a framework like laravel for the language Elixir like laravel is to PHP and Chris McCord the author of Phoenix.
    He demoed this new tool these working on called live view Phoenix live view and I saw the blog post for this my mind blew up and I spent the next eight months building live where and it started out being really similar to the live view and now it's become something different but similar in some ways and definitely took inspiration from so.

    So the first name that Livewire had was Phoenix light was a phoenix live view laravel proof-of-concept not an official name, but that was the first thing I called. [00:01:00] It was just a proof of concept for Phoenix live view inside laravel and I thought that I might just call it laravel live view but I wasn't sure like I thought that might be kind of lame to just steal someone's name for another for a package in another Community.
    Like if it was like, I don't know view redox or something instead of view acts like kind of. On spin on it. So that's what it was out of the gate. The first the first name I came up with kind of off the cuff. I think was lightwire so light wire and basically the my goal was I wanted to convey something like electroluminescence electroluminescence.

    I don't know like luminescent electric but not I don't know. So I like what I wanted wire. I don't know why I came up with wire. But I wanted wire and because it connects things and it's you know, I want to basically I wanted live where it's funny because I can't think of why I wouldn't pick a live wire but I definitely struggled with it for a while.

    I [00:02:00] had tons and tons of names written down on envelopes and paper and whatever like what am I going to call this thing? I just didn't love light. And I think maybe part of why I didn't love it as people kept like Miss stating it. I think they were saying I think maybe they were saying Livewire by accident.
    Maybe that was my cue. I forgot the process. Basically it was this process of me like sitting with an idea and brainstorming a bunch and then after a while the right the right name sort of emerges because it's the one with the fewest surprises. It's like the principle of least surprise. It's one of the few surprises.
    It meets all the criteria. Is best is anyone else would and probably more so that's kind of how I made the decision. It wasn't an obvious like oh, this is Livewire. It was like it took some tumbling, you know to get there to that point. So I called it live where then the next step is. So live view is capital L and capital V.
    And so the question is is it live wire with a capital? W? Or is it just live where one word [00:03:00] and so this is something I struggled with and still do struggle with because people do write it as live where with a capital W from time to time because I think that and that's just kind of tells me like that's what at least some people assume.

    It's how you would spell it and I would probably assume that too but here's the reason why I'm sort of sticking with Livewire lowercase. W this is kind of crazy, but it's one of those things that actually matters to me. I'm trying to think of an example. There's other examples of packages sort of named like this like maybe sigh shell the thing under Artisan Tinker.

    There's definitely other packages that have how man I can't think of a good one. There are definitely good ones though. Shoot. Anyway when you are if you live where is going to have a classes? It's going to be a namespace in PHP, right and when you import that namespace, is it going to be live?
    Capital W wire like if it's if it's live wire in the same way, like if you have HTML a class called literally you want [00:04:00] to call it HTML. Is it going to be all capitals for your acronyms or is going to be Capital H lowercase T. Ml I would do Capital H lowercase T. Ml I think there's some standard somewhere that says that's what you should do.

    I don't know but I treat acronyms as word. When I'm studly casing them for classes, so kind of naturally I think I would do live wire with all lowercase and not do the the capital W and a class name space because then it's sort of like when you make a like a hashing, you know how like encryption if you encrypt something.
    You can decrypt it. It's like to way if you hash it's one way you have something and you can never you can never make it back to its original form. I felt like the Livewire capital W name for class importing was a similar idea that if you just saw a used statement in PHP that said use capital L IV E capital W IR e you wouldn't know if it's two words or if it's [00:05:00] one word with that capital W.

    It's ambiguous. It doesn't work the other way around and something about that just hurts my brain. It adds a little bit of friction. That's like oh this if you do this weird thing where you have. Word that has multiple capitals You Now enter the world of confusion. So I thought I would make it not confusing and live.
    Where is one word one word, and I think I really sort of came to this when I was writing the. My composure dot Json file where I'm autoloading the root Source namespace. What am I going to Auto load that route class and it's and it's live wire with one word and that's kind of what I suck with. So that's that that's part one of the naming story.

    Oh man. We're already at five minutes and forty. I'll have to rush part 2, so I need to make a so GitHub. What am I going to make GitHub? So GitHub live where / live wires. Sorry the live just get up / live wires taken. What am I going to do? There is a live where well, I don't know because I don't want [00:06:00] it to necessarily just be like laravel this I wanted to be its own thing and Taylor has publicly stated that people should not prefix their packages with laravel because people get confused and think their official and Taylor like LLC laravel like it's trademarked.

    You can't just use it. So I tried to avoid that. So I was like, all right. Well forget whole organization. Maybe I'll have live boy or PHP Live Wire PHP is also it's actually mostly JavaScript like it's written mostly in JavaScript and it's a kind of like a JavaScript framework. So would it be live where JS know, it would be you know, well, okay be live where laravel yeah, but that's kind of weird so you can see the weirdness in the domain name.
    Live where framework.com is what I landed on for the domain name because the suffix to something like well, I'm not going to do live where PHP and I'm not going to do live or JSL do live where framework.com that felt. Okay, but I don't even know what I was thinking when I made the Twitter handle live where it was taken, of course, so I did live wire laravel reads horribly.

    It always bugged [00:07:00] me every time I saw it. I needed a different name. It couldn't just be Live Wire. And I liked the laravel context. It was later live where Larry Bell and I didn't feel as bad about using laravel my name if it was a weird suffix, you know, but that's really annoying. And every time I saw her wrote it, I just felt gross about it.

    So all of this was just sort of culminating into just this kind of bad feeling about the name that it just wasn't settled yet. So I was on an airplane to go fly fishing recently. And and on the way there I started writing down. Basically, I'd like mine dumped everything in my brain about the direction of live where and one of the area's is naming.

    I really wanted to settle on a name and get it off of Caleb or zo / Live Wire because that just feels like k...


    But Does It Scale? Sep 20, 2019
    Show notes

    [00:00:00] Caleb: Okay. This is a big one. This is one that deserves more than the amount of time. I'm giving it but and more planning but I'm kind of on a roll and I want to just get the conversation started but does it scale this is the question that has haunted me since day one of Livewire and my journey. I live where Journey has been a massive lesson in overcoming doubts really pushing through them and just doing it consistently over a long period of time.

    so live? Where was a proof of concept in PHP for tool that exists in elixir in Phoenix Elixir is. Great at concurrency and by concurrency. I mean like a process running on the server that's continuing and that a user is connecting to over websockets on the front end and has a consistent connection to a concurrent connection and the user can.

    Make a request on the front end to the back end to change a [00:01:00] real runtime object and it will change in real runtime metal, you know, so that's what I started out building live wire as the proof of concept was that and I'm like there was some video I post on Twitter at one point that I'm like laughing to myself like this is crazy.

    There's a counter that exists in PHP like a count variable that exists. And when you hit plus you tell the server to change that variable in real-time. Okay, so that at first it was this like toy project that was just super attractive to me, but it wasn't attractive to me because of the Cool Tech behind it.

    What was attractive to me was the concept? Of not having to deal with all the glue code of Ajax and everything because basically in my mind Live Wire is just taking care of all of the all of that glue code nonsense you're dealing with when you're dealing with UJS because you're doing a lot of the same things you're listening to events.

    You're reacting to them. You're sending Ajax requests and updating data or fetching data and changing the page, but you're doing it all [00:02:00] yourself. So what if there was something that did it all for you and you could not have to deal with specific with separate endpoints that return Json. In a standard format that's restful and tested and all that stuff.

    What if you could just access PHP from JavaScript wouldn't that just be freaking magical and that's that's the whole concept that just drove me. Everything else is just an implementation implementation detail even websockets as a core concept. Which was you know sort of came a bit later anyway, so does it scale first?
    It was just a pet project. So it didn't really matter if it's scaled or not. I didn't really care. I was just having fun. Then I start, you know, I got into the project maybe about a month into it and I'd like put a lot into it. I've been blogging and doing screencasts and this thing lingered in the back of my mind.

    That's like. Oh boy. I looked at every possible websocket implementation for PHP and I always had this scared feeling of like man, if people can't just use Pusher for this like this is going to be this is going to [00:03:00] be potentially not viable for a lot of people what I want to deal with websocket infrastructure for PHP know I definitely wouldn't what I want to do that in production.
    No, I would not have to I would not want to have to make sure that a websocket process is running. Doesn't fail and can handle unlimited or a ton of connections that get thrown at it. That's a hard task. The default with PHP fpm is like a thousand something concurrent connections or I don't know whatever I was using ratchet.
    There's all these different tools. None of them are like first class citizens like Phoenix channels, which is Phoenix's answer to websockets. So honestly, it just kind of was this thing that laid low, but like I said, I believe in live where I believe in the. Or in the you know in the use case of it.
    So I just kept moving forward with it, which is kind of insane and I remember having some real low points. There were a bunch of really low points. I'm literally in Disneyworld having a bad day. We moved to basically Disney World for two months. It's like snowboarding and I quit my job and I [00:04:00] worked on live for and that's kind of where all where a lot of these early things happened and I'm in Disney World and like having a bum day because I feel like live wires over my brain up.

    It's over like this isn't viable as a legit awesome solution for like real production apps like for everybody so why am I wasting my time like this is you know, when I would always tell people like oh, you know, I'm just kind of working over now, but who knows he has probably not gonna you know, but it's like deep down.
    I just like something in me refused to stop working on it because it's just so. I don't know. It's so enticing this prospect that it offers us. So anyway, I'm at Epcot and I'm walking out of Epcot and well, I guess I'll fill in I'll fill in a gap here. I created a Ajax driver. For live where for my little local Livewire toy playground at the time because I was like if the websocket connection if I change to file I had to restart the websocket server, [00:05:00] so I would have to do that every time and I'm like, oh, that's really annoying.
    Well, what if I just create a little Ajax driver that does this. So that I don't have to deal with websockets that it rehydrates and everything. It's funny that I put all this work into make an Ajax driver the time. I don't remember being a lot of work but like I did it even though I didn't need it and turns out that was like the best decision I ever made so I started using the Ajax driver locally.

    I thought like oh, this is one of those things like the inline script tag like oh, this is just like bad. This is just to to janky like I'm not going to actually ship with this with people aren't going to use that because Ajax all it's so slow. You know, that's just be crazy. But I used it myself then I was at Epcot and I basically realized I had this Moment of clarity.

    I was like, the only way forward is the Ajax driver. Like that's the only way forward the web sockets thing. I'll keep it around but I need to own a Jack's like I need to make it because if I owned a Jack's then the [00:06:00] tech I'm requiring people to have to use Live Wire is Ajax, which. Every browser has and everybody uses.
    It's just like saying you need PHP to run might you know, it's like zero infrastructure to use this tool that's insane like this that I could make the setup like cake like nothing like everybody could include it in their apps instantly and how could that not be like incredibly easy to onboard and become popular and Powerful, you know, So it just was sort of clear to me.

    There's this Moment of clarity and I felt amazing. I was on like top of the world. I was like I fixed it in my brain. I fixed it. I fixed the thing the answer the question I had that was like Livewire has a timeline on it and it has like a death an expiration date. The date where I figure out that this websockets things not going to work.
    I remove that was like I could really own this then I got into like researching all the other people who do sorts of things like this like GitHub does this and basically solidified my position [00:07:00] is feeling like this is ok. And now I have a hundred percent confident that like, this is totally the right way and it's great.
    And this is where it's diverge from live view like Livewire uses Ajax and because and because of that we're not doing animations. We're not making games like live view is like weird. Submitting forms and validating and showing data in tables and real-time search stuff that like, we're actually doing a new eyes like not like games and stuff.

    So. I find it to actually be a more practical approach and and it affords us all sorts of cool things and there's lots of creativity to be smart with resources. Anyway, d...


    Intro Sep 20, 2019
    Show notes

    [00:00:00] Caleb: Hey there, friends Caleb Porzio here with a new podcast called building Livewire and my goal with this podcast is to share a little bite-size Snippets of problems that I'm solving just building Livewire and that could be. Deep Tech like coding problems. It could be business problems branding problems writing anything.
    Anything I'm coming across, I want a platform to talk about because honestly there would just be too many blog posts and that would be too much work so and yeah, so this is just I guess easier for me and I can throw a little tiny bite-size size things at you. So I'm pretty excited about it because Livewire is definitely like produced the most interesting problems of my entire career.
    And I think it'd be really cool to talk about some of those things. So thanks for tuning in. I'm going to try to keep these episodes under 10 minutes and keep them interesting. I hope you like it.


    Previous 1 61 62 63

    Related Podcasts

    Reply All

    1

    Reply All Games & Hobbies
    Inside VR & AR

    2

    Inside VR & AR Gadgets
    Note to Self

    3

    Note to Self News
    BrainStuff

    4

    BrainStuff Natural Sciences
    This Week in Tech (Audio)

    5

    This Week in Tech (Audio) News
    Hands-On Tech (Audio)

    6

    Hands-On Tech (Audio) Technology
    footer-logo

    Contact Us

    Toll Free: 844-670-7747

    Links

    • Home
    • Top Charts
    • Networks
    • Apps
    • Independents Podcasts
    • Podcast Advertising
    • Podcast News
    • Contact Us
    • About Us
    • Analytics & Insights

    Stay Connected

      Privacy, Terms of Use & Our Code of Ethics Protecting Content Creators Copyrights