Composable seeders in Laravel with callOnce
Laravel 9 is fresh out the door, and it contains a small contribution of mine: a new callOnce method for database seeders.
Laravel 9 is fresh out the door, and it contains a small contribution of mine: a new callOnce method for database seeders.
An overview on view models in Laravel
The other day I needed to sort a dataset in MySQL and ensure one value was always at the end. I never fully understood how order by works, so I did some research on how to solve my problem and how order by behaves.
I use Model::findOrFail a lot in Laravel. Recently, I realized it’s not always the best option.
I want to talk about something I’ve been chewing on for a while: the monetization trap.
I’ve been thinking a lot about work-life balance lately. I used to see it as a balancing scale that should remain on the same position at all times. However, I believe a better mental model is to see it as ebb and flow.
Our Blink package is marketed as a caching solution to memoize data for the duration of a web request. Recently, we came upon another use case for the package: to execute something once and only once.
Backlinks, or bi-directional liks, are becoming table-stakes for productivity apps since they’ve been popularized by Roam. It’s a simple concept: when you create a link from page A to page B, page B will also reference page A. With traditional hyperlinks, page B wouldn’t know about page A unless you explicitly link it back.
Backlinks allow a graph of knowledge to grow organically. When you create a doc for Orders, and mention Products, a Products page will be created or updated with a backlink. Even when not actively documenting Products, readers can get an idea of what they entail because of the linked references.
Sometimes you want to spin up a process, but the port it wants to bind to is already in use. Or a port isn’t listening to a process as you expected. lsof is a debugging life saver in these situations.
In most projects, we use git flow to some extent — depending on the project and team size. This includes feature branches.
Feature branches (or sometimes called topic branches) are used to develop new features for the upcoming or a distant future release. When starting development of a feature, the target release in which this feature will be incorporated may well be unknown at that point. The essence of a feature branch is that it exists as long as the feature is in development, but will eventually be merged back into develop (to definitely add the new feature to the upcoming release) or discarded (in case of a disappointing experiment).
Working on a project with a lot of interdependencies between features with a bigger team comes with a new set of challenges dealing with git.
We’ve recently set up a new guideline: if it’s not directly tied to your feature, don’t put it in your feature branch.