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 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)
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.
I'm prepping for my Laracon Online talk tomorrow (and launching 1.0), and just wanted to stop for a minute and express how great I feel about the framework.
I'm pretty pumped about a lot of things, let me tell you about them...
Livewire just got a pretty major update. I made some tough decisions on this one, but ultimately, think we'll be better off.
Let's get up to speed on the current state of Livewire.
Today we talk about decisions where I choose the "invisible" option (the option that feels invisible to the user). Along the way, I discover a trade-off between "invisibility" and "transparency". It's good times.
Today we talk about getting past some hard validation problems. I'm really happy with the result!
Sometimes, trying to work on a codebase feels like trying to wrap your arms all the way around a big tree. Today I talk about this experience and push the analogy to it's limits.
After being away for the Livewire codebase for a while, coming back to it was kind of painstaking. Instead of slogging through it, I decided to "make the change easy". Here's the story of a fun refactor I just made.
The hardest thing about being a developer for me might surprise you to hear, but it's a message we all should be reminded of.
I've recently hit a BIG milestone in my life: I'm currently not afraid to speak in front of large groups of people. It's been a long road, but here's how I got there.
Today I talk about my long, hard relationship with speaking in front of people.
Today, I reflect on the value of having a good developer reputation, and how at times I lose sight of that. If Livewire never makes a penny, it won't be at all a loss.
A long long time ago, I decided Livewire needed to work well with Vue. This episode describes the journey I made to get there and my current thoughts and questions about the future. Will Livewire continue to support Vue? I'm less and less confident!
Let's get a little more concrete. Here is the actual, tangible reason I believe Livewire is extremely useful and "good" for most projects.
To me, Livewire is much more than the package on GitHub. It represents a change in my thinking and a prescription for the overwhelmed developer.
There is a file in the Livewire codebase FULL of duplication. There certainly is an abstraction just begging to be made. Why can't I find it? What do I do about that?
Today I talk to my past self. Telling him to submit more pull-requests, and not fear being "seen" as a bad developer.
Today, I talk about a significant change I made to my life: unfollow everyone on Twitter.
Sometimes, you just have to do the hard thing, put your thinking cap on, and open the black box. In my case, I had to really sit down and understand how Livewire's DOM-diffing algorithm works, and THEN I was able to clear my head and move forward.
Let's chat about a super practical pattern I use in everyday life. Often when I'm adding a feature or a "concern" I try to isolate the entire changeset to one file. It's surprisingly effective.
Now that you understand DOM diffing, you can commiserate with me, and help brainstorm a fork in the road I'm dealing with. Do I keep improving an existing package? Or REWRITE!!!
Words like "virtual dom", "dom diffing and patching", "vDom", and "render functions" are all intimidating (spoiler: they're not actually). However, they are a HUGE part of any front-end framework, and Livewire is no exception. Therefore, we will be diving into what they mean, and how Livewire uses them, so we can lay a foundation for future episodes.
I'm sitting in my office, about to make a decent size refactor to Livewire's core, and thought I'd tell you about it!
Livewire aims to be thrifty when it comes to resource usage (ajax requests being the biggest). Here is an example of a little feature I recently implemented with a really clever extra bit thrown in there.
I want Livewire to require as little configuration as possible. The fewer things the user has to do to get up and running and productive, the better. Here is an example of a cross-roads I came to, and then how the direction I picked is telling of the framework.
Often times, the obvious interface for a feature is not-so-obvious when you're writing it. The process of not settling for less is invigorating to me, and this episode is a perfect example of that.
The "make:livewire" command is one of the first things a new Livewire user types. It feels natural, and lacking in surprise. Surprisingly, it was quite a long road that led me here. Let's walk down that road.
Naming things is really hard. Livewire is no exception. Today we'll talk about where the name came from, how it's evolved, and how it is still evolving.
The question that has haunted me since the beginning, and how I overcame the fear of it.
Welcome to the new podcast. This episode is a quick intro to the project.