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.

This is a friendly reminder to keep leading slashes in mind in .gitignore files.

The other day, I pulled down a project and couldn’t get the CSS to build because files were missing. It turned out another developer created a new resources/css/vendor directory to override styles for third-party components. A fine name, but vendor was ignored so they were quietly missing from the repository. We updated .gitignore to use /vendor instead and all was well.

# Ignores all vendor files
vendor
# Only ignores vendor at the project root
/vendor

This is a friendly reminder to keep leading slashes in mind in .gitignore files.

The other day, I pulled down a project and couldn’t get the CSS to build because files were missing. It turned out another developer created a new resources/css/vendor directory to override styles for third-party components. A fine name, but vendor was ignored so they were quietly missing from the repository. We updated .gitignore to use /vendor instead and all was well.

# Ignores all vendor files
vendor
# Only ignores vendor at the project root
/vendor

This is a friendly reminder to keep leading slashes in mind in .gitignore files.

The other day, I pulled down a project and couldn’t get the CSS to build because files were missing. It turned out another developer created a new resources/css/vendor directory to override styles for third-party components. A fine name, but vendor was ignored so they were quietly missing from the repository. We updated .gitignore to use /vendor instead and all was well.

# Ignores all vendor files
vendor
# Only ignores vendor at the project root
/vendor