Seb De Deyne
For the past few months, I’ve been experimenting with Svelte & SvelteKit. Svelte peaked my interest because it’s a tool molded by the web. A lot of Svelte APIs piggyback on existing web affordances like plain HTML and CSS variables.
Shorthex is a small app to transform 6-digit hex color codes to 3-digit codes. Here’s a quick overview of the features of Svelte I enjoyed using.
Read more
Crypto, AI, JavaScript frameworks,… are interesting tech, but that doesn’t mean they need to be shoehorned into every product.
Set a direction, and choose the tools you’ll need to get there. Don’t choose a direction based on the tools in your disposal.
… by chasing trends we would never be the ones to set them.
Putting this in a blog post because I always forget.
To view PHP logs from Laravel Valet:
open ~/.config/valet/Log/php-fpm.log
To view NGINX logs from Laravel Valet:
open ~/.config/valet/Log/nginx-error.log
When I’m working on a feature or refactor, I often leave @todo
comments to remain in flow and deal with other points later.
I don’t mind committing them to my feature branch, as long as I work them away before merging in.
On large branches, it can be easy to forget about that todo I left in there a few days ago.
class PodcastController
{
public function process(Podcast $podcast): void
{
$podcast->process();
// @todo Broadcast event to trigger webhooks
return $podcast;
}
Before I merge, I pipe git diff
into a grep
call to scan for changes that include @todo
.
git --no-pager diff main..feature-branch | grep -i "^\+[^$]*@todo"
+ // @todo Broadcast event to trigger webhooks
This one’s permanently stored in my Pinboard — a conversation I had this morning triggered a re-read.
“A user is only part of one team”. Until we decide to add multi-team support, and the $user->team
BelongsTo
relation suddenly needs to be replaced in 50 places.
Golden advice from swyx:
It is a LOT easier to scale code from a cardinality of 2 to 3 than it is to refactor from a cardinality of 1 to 2.
In Laravel, you can register a class as a singleton to always resolve the same object.
However, you might want to build another instance of the class. You could manually construct the class without Laravel’s container, but if it has a bunch of dependencies it can be tedious.
With the build
method, Laravel won’t resolve a registered instance of the class, but build a new one with the container.
// AppServiceProvider::register()
$this->app->singleton(MastodonClient::class);
// Resolve the singleton instance from the container
$mastodon = resolve(MastodonClient::class);
// Build a new instance
$anotherMastodon = app()->build(MastodonClient::class);
This can be useful when a Laravel package registers a class as a singleton but you need another instance.
Freek shares a few patterns we employ to let developers override behaviour in our packages.
One of the ways we keep maintenance burden low is by making our packages customizable. In this blog post, I’d like to cover some of our best tips to make a Laravel package easy to customize. Some of these tips will apply to regular projects as well.
Rauno Freiberg (designer at Vercel) shares his web guidelines for web interfaces. A few that stood out for me:
- Inputs should be wrapped with a
<form>
to submit by pressing Enter - Interactive elements should disable
user-select
for inner content - Actions that are frequent and low in novelty should avoid extraneous animations
Read them all on Rauno’s (beautiful) website, and check out the Craft section while you’re there.
Is it weird to have a favorite operator? Well, the pipe operator |>
is mine. Not only does it look cool, it opens a world of possibilities for better code.
Unfortunately, it’s not available in any of the languages I use on a daily basis. There are proposals to add it to PHP and JavaScript, but we’re not there yet. I’d like to expand on why I think the pipe operator would be a valuable addition to the language from a PHP developer’s perspective.
Read more
I like to browsing through past work when I’m in need of inspiration, trying to reflect on the present, or in a nostalgic mood. Not just finished work, the things that didn’t make it can be even more inspiring to look back at.
With modern software, artifacts of work in progress are becoming more and more rare. Gone are the days of essay_final_v2
, a project’s history is often contained in a single file (which isn’t even a file anymore with tools like Figma,…).
Per Alex Chan, taking screenshots while you work is a great way to build a journal of sorts.
I have dozens and dozens of screenshots of things I’ve made (and a handful of screen recordings, too). They’re a sort of “visual journal” of fun, silly and interesting things I’ve done on my computer.
The best time to take these screenshots is as I’m doing the work – when I have all the required context. And unlike the raw files, images are a stable format that I’ll be able to read for a very long time. I don’t need any context to look at an image; I just look at it in an image viewer.
I reconfigured CleanShot to store screenshots I save to a folder on iCloud Drive instead of my desktop. Out of sight, out of mind. Until I want to take a stroll through my visual record.