PHP & NGINX logs with Laravel Valet
Putting this in a blog post because I always forget.
To view PHP logs from Laravel Valet:
open ~/.config/valet/Log/php-fpm.logTo view NGINX logs from Laravel Valet:
open ~/.config/valet/Log/nginx-error.logPutting this in a blog post because I always forget.
To view PHP logs from Laravel Valet:
open ~/.config/valet/Log/php-fpm.logTo view NGINX logs from Laravel Valet:
open ~/.config/valet/Log/nginx-error.logFreek 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.
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.
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.
I shiver at the sight of a function packed with too-many-to-read-at-a-glance arguments without a description.
A few weeks ago a spec change for an application we’re working on forced us to refactor part of the codebase. It was food for thought about the flexibility granular interfaces provide, and choosing the right abstraction at the right time. This is a short writeup on the thought process we went through as we updated our logic to support a new feature now and allow more options in the future.
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.
#spatie #laravel #php #javascript
I created the original Spatie guidelines site three years ago. Last month, we consolidated a few of our subsites to our main spatie.be site, including the guidelines.
Since the first iteration of my blog—some time around 2016—I’ve used highlight.js to highlight code blocks. With highlight.js being so popular, I never really second guessed the idea. It was a given to use JavaScript.
A few weeks ago, TJ Miller introduced me to highlight.php by writing a Parsedown extension for it. Highlight.php does the exact same thing as highlight.js: they both add tags and classes to your code blocks, which enables them to be highlighted with CSS. The difference is, highlight.php does this on the server.
Server side rendering is a hot topic when it comes to client side applications. Unfortunately, it’s not an easy thing to do, especially if you’re not building things in a Node.js environment.
I published two libraries to enable server side rendering JavaScript from PHP: spatie/server-side-rendering and spatie/laravel-server-side-rendering for Laravel apps.
Let’s review some server side rendering concepts, benefits and tradeoffs, and build a server renderer in PHP from first principles.