Freek.dev

Laravel / PHP / AI

Posts tagged with best practices

Software Architecture is Overrated, Clear and Simple Design is Underrated

– blog.pragmaticengineer.com

Gergely Orosz argues that you should start with a simple design and try your best to keep it simple. I don't necessarily agree with everything in the post, but it's an interesting opinion nonetheless.

Software architecture best practices, enterprise architecture patterns, and formalized ways to describe systems are all tools that are useful to know of and might come in handy one day.

Read more [blog.pragmaticengineer.com]

Join 9,500+ smart developers

Get my monthly newsletter with what I learn from running Spatie, building Oh Dear, and maintaining 300+ open source packages. Practical takes on Laravel, PHP, and AI that you can actually use.

No spam. Unsubscribe anytime. You can also follow me on X.

An alternative way to organize the Laravel directory structure

– stefanbauer.me

I don't necessarly agree with every detail in this post, but it's very interesting to see how others structure larger projects.

In this article, I would like to show you an alternative way to organize your Laravel directory structure. I think the default structure is fine for the most projects. But when it comes down to larger projects I was looking for a different structure.

Read more [stefanbauer.me]

Reducing Complexity with Guard Clauses in PHP and JavaScript

– engineering.helpscout.com

In this old, but still relevant, blog post Craig Davis explains what guard clauses are and how they can be used to clean up your code.

We’ll first explore several versions of a sample method from a hypothetical billing system. For these purposes, we’ll assume this is code in an existing system and we’ll look at refactoring it to reduce complexity and make it easier for a programmer to understand. The first example will be trivial enough to easily understand, but we’ll build on it in the final examples.

Read more [engineering.helpscout.com]

10 rules to code like NASA (applied to interpreted languages)

– dev.to

Here a some great tips on how to write robust software.

NASA's JPL, which is responsible for some of the most awesomest science out there, is quite famous for its Power of 10 rules (see original paper). Indeed, if you are going to send a robot on Mars with a 40 minutes ping and no physical access to it then you pretty damn well should make sure that your code doesn't have bugs.

Read more [dev.to]

Laravel and Murphy’s Law

– medium.com

Patrick Brouwers, the creator of Laravel Excel, explains how to handle failing jobs in Laravel

When designing software, don’t only think about the happy path. Write down (preferably with (unit) tests) what all the things are that could go wrong. Then design your solution to be able to recover those situations. (Wether or not automatic.) There isn’t a single solution to rule them all, some processes might need to have specific failure handling while others are fine with the default approach.

Read more [medium.com]

Some Shifty Bits

– jasonmccreary.me

Laravel Shift creator JMac did a write up of the talk he gave at this year's Laracon US

I received a lot of valuable feedback from these talks. So I combined them by using analytics from Shift to identify underutilized features of Laravel and demonstrate them with code.

Read more [jasonmccreary.me]

Forget about component lifecycles and start thinking in effects

– sebastiandedeyne.com

In a new blogpost, my colleague Seb explains why you should and how you can use useEffect.

React recently introduced a new way to deal with side effects: the useEffect hook. Translating lifecycle methods to useEffect calls can be confusing at first. It’s confusing because we shouldn’t be translating imperative lifecycle methods to declarative useEffect calls in the first place.

Read more [sebastiandedeyne.com]

Learning Laravel - Observations, part 1: The service container

– matthiasnoback.nl

Matthias Noback wrote down some thoughts on the Laravel container

Laravel's service container looks great. I like the idea that it can figure things out mostly by itself. I like that it's PHP-based, and that its syntax is quite compact. I think that most of the convenience functions (e.g. resolve()) and exotic options (like $this->app->resolving()) should be ignored. The best thing you can do for your application in the long term is to let all your services use dependency injection, and to inject only constructor arguments. This keeps things simple, but also portable to other frameworks with other dependency injection containers, or other architectural styles, when the time is there.

Read more [matthiasnoback.nl]

Tests and types

– stitcher.io

My colleague Brent wrote another excellent blog post, this time on tests and types.

So while strong types can help us to ensure program correctness, some tests will always be a necessity to ensure business correctness. It's a matter of "both and", not "either or".

Read more [stitcher.io]

Internal classes in PHP

– nunomaduro.com

Nuno Maduro, engineer at Algolia, explains what is the value of the @internal tag

The PHP @internal tag can be used to denote that the associated class/method is internal to the library. It's supported by PHPStorm and it warns people that those classes/methods are not meant to be used

Read more [nunomaduro.com]

Sharing learning via code

– stakeholderwhisperer.com

Konstantin Kudryashov, one of the speakers at the upcoming Full Stack Europe conference, makes the case for sharing new insights early.

When you build new feature as a team, and it requires a lot of new learning, do not hoard new knowledge in your head. Instead, incrementally commit each unit of learning into working code. Hide that partial logic behind a feature flag. The feature would be incomplete, but work-in-progress outputs will expose meaningful and demonstrable progress. To increase team’s awareness of outputs, add links into the feature tracker or documentation.

Read more [stakeholderwhisperer.com]

Exceptional Exceptions

– engagor.github.io

At the Clarabridge Developers blog, Toon Daelman wrote a good post on how to improve your exceptions.

You've made it to this post thinking "Why do we still need to talk about Exceptions?". Well, they're used everywhere in OOP codebases, but sometimes they're used in a way that make debugging a bit difficult. Let's look at some ways to make debugging exceptions a bit more fun!

Read more [engagor.github.io]