I started using a hyper key on macOS. A hyper key is a single key mapped to Shift + Ctrl + Opt + Cmd. Since this isn’t exactly practical to pull off with your fingers, apps don’t use this combination for built-in shortcuts. This means you have a layer for custom shortcuts without worrying about clashes.

My hyper key is mapped to Caps Lock. I actually already use caps lock as an escape key. Less travel than reaching for Esc with your pinky! Thanks to Karabiner Elements and Brett Terpstra’s guide I was able to remap it as Esc and a hyper key.

When I give Caps Lock a short tap, it functions as Esc. If I hold it and press another key, it functions as a hyper key, Shift + Ctrl + Opt + Cmd.

I still have a lot of room to map to, but for now I’m using my hyper key for a few global application shortcuts like Quick Entry in Things. In the future, I’m planning to map more Raycast commands too.

As I roam deeper into Svelte territory, I came across this talk from 2019 by Rich Harris, creator of Svelte.

Rich explains how he arrived at Svelte’s reactivity from first principles, swimming against the virtual-DOM stream other frameworks follow.

Despite being from 2019, it’s still relevant. Even if you’re not into Svelte, it’s worth watching as a great standalone talk.

Timeless advice from Derrick Reimer:

Not all projects are inherently small, but you can always break them down into smaller chunks. […]

Each incremental task brought us one step closer to a functioning v1. By shipping these tiny branches to production as we go, we became increasingly confident in the “bones” of the feature. As soon as a slice of the project was ready to test, the whole team hammered on it in production – an effective way to tease out bugs and rough spots in the user experience.

Set Studio—founded by Andy Bell—has a new website.

Aside from the good looks, it’s refreshing to see a page of that size to load and feel so fast.

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.

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

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

If you want to double check your changes before comitting, you can use the same command with git diff HEAD.

git --no-pager diff HEAD | grep -i "^\+[^$]*@todo"

Pouring this in a bash function

Here’s a quick bash function to scan for todos:

function todos() {
  git --no-pager diff ${1:"HEAD"} | grep -i "^\+[^$]*@todo"
}

Use it without an argument to look for todos you haven’t committed yet, or pass the revisions you want to compare between.

# Look at current changes
todos

# Look for todos added between main and feature-branch
todos main..feature-branch

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.

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.

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.

Static methods tend to have a bad reputation in PHP, but I believe (stateless) static methods are underused. In static functions, there’s no internal state to take into account. Calculator::sum(1, 2) only depends on its input, and will always return 3.

While researching for another post, I came across an article from Mathias Verraes that already says everything I wanted to say.

It is stateless, it is free of side effects, and as such, it is entirely predictable. You can call the exact same function with the exact same argument as often as you like, and you will always get the exact same result back.