Over Engineered

We all use our personal websites as an excuse for trying something new or over engineering what's usually a simple, low traffic site. In today's episode, Chris and Aaron talk about how to build a great personal website with "just Laravel" and imagine ways that static site generation, markdown editing, open graph, caching, SEO, and more could be improved in the Laravel ecosystem.

In today's episode, Chris and Caleb sit down and try to imagine what the perfect "hook" implementation might look like. Laravel, Livewire, and the upcoming Verbs package, all have to allow for hooking into logic at specific points, and each package has to handle this in its own unique way. What if there was a canonical way to hook into the lifecycle of a package that worked across the whole Larave...

And now for something completely different… In this episode, Chris and Daniel sit down to talk about a new event sourcing package they're working on called Verbs.

Most teams have encountered this basic scenario: Your application sends out a periodic report to a specific person in the company. Then, at some later point, either another team member wants to start receiving a copy of the report, or you need to remove the original recipient and add a new one. With a standard Laravel app, you're probably going to need to make this change by deploying a change—eit...

In this episode we indulge in the purest form of Over Engineering—a 90 minute discussion of a completely different application paradigm/architecture. Our team has used event sourcing to some degree, and we're considering using it more heavily in the future. But before we do, we're going to step back and ask ourselves if it's worth it… Some useful links: Event Sourcery YouTube Series Spatie Event S...

Over Engineered is all about those things that bug you but you never get a chance to "solve." Today's episode is about the dreaded "status" column. This is another topic that most developers will hit over and over. You have a model. You need to track the status. You add a status column, and then later a status timestamp "accepted_at", and then later an "accepted_by" column—and each time you cringe...

Season 1 continues with a discussion of how to deal with special database records that need to be referenced directly in code. We've all been there before: you've got a specific vendor that you need to write a custom command for, or a certain category that needs special handling, so you either hard-code the ID or slug and shudder slightly before moving on with your life. In this episode, we imagin...

In the second episode of the podcast we talk with Tim MacDonald about a few other approaches to how you might manage other operations that happen before/during/after a database migration (or really any deploy step). Tim pitches a lower-level approach that spawns a whole new line of thinking. We also touch on some of the responses to episode one, including: Ed Grosvenor's "run once" command Lukas H...

In the first episode of the podcast we explore the boundary between database migrations and other operations that need to happen when the database is being migrated. How do you seed or manipulate data after new tables or columns have been added? In migrations? In one-off commands that you have to run manually? Running seeders in production? In tinker, Nova, or TablesPlus? We spend a whole hour tal...