Freek.dev

Laravel / PHP / AI

best practices

All my posts about best practices.

php laravel code quality refactor design patterns

17 Tips for Using Composer Efficiently

Martin Hujer shares some pretty good tips for working with Composer.

Although most PHP developers know how to use Composer, not all of them are using it efficiently or in a best possible way. So I decided to summarize things which are important for my everyday workflow.

The philosophy of most of the tips is "Play it safe", which means that if there are more ways how to handle something, I would use the approach which is least error-prone.

https://blog.martinhujer.cz/17-tips-for-using-composer-efficiently/

Read more

Organizing code into domain modules

In a new post to his site Mathieu Napoli makes the case for organising your code based on it's function rather than it's type.

We recently discussed 2 topics seemingly unrelated with my colleagues at Wizaplace: how to organize code? How to organize teams? ... Organizing code into domain modules is not a silver bullet but it forces to better understand the problem we are solving and better structure our code.

http://mnapoli.fr/organizing-code-into-domain-modules/

Read more

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.

Atomic commits: telling stories with Git

Frederick Vanbrabant published another delirious rant on his blog. This time it's about atomic commits.

Atomic commits, sometimes also called micro commits, is the practice of explaining your thought process in the form of commit messages and code. It comes down to documenting the way to the solution.

https://frederickvanbrabant.com/2017/12/07/atomic-commits.html

Read more

The Cost Of JavaScript

Probably you know that that keeping the disk & transfer size of a JavaScript file low is pretty important. But have you considered the time needed to parse and compile the code? In this great post on Medium Addy Osmani, an engineer at Google, explains the complete cost of having JavaScript on your page.

As we build sites more heavily reliant on JavaScript, we sometimes pay for what we send down in ways that we can’t always easily see. In this post, I’ll cover why a little discipline can help if you’d like your site to load & be interactive quickly on mobile devices. tl;dr: less code = less parse/compile + less transfer + less to decompress

https://medium.com/dev-channel/the-cost-of-javascript-84009f51e99e

Read more

Airplanes and Ashtrays

Harry Roberts makes the case for making technical debt visible instead of trying to hide it.

This means that, although far from ideal, the impact of these hacks is well contained and signposted, meaning that they won’t slip through the cracks and remain hidden in the codebase for the next five years.

This pragmatism and lack of stubbornness can make your codebase much more malleable, resilient, and ultimately much more useful. Everything is a compromise.

https://csswizardry.com/2017/10/airplanes-and-ashtrays/

Read more

Writing clean code

Jason McCreary, creator of Laravel Shift, wrote a down a two part series on how to write cleaner code.

To measure our change, we should ask: Did we improve readability?

Admittedly a bit subjective, but you push yourself to stay objective. I've been pair programming for the last two years. Developers tend to agree on fundamental readability. Where we differ at the edges. These nuances can lead to some pretty great discussion.

...

The answer to did we improve code readability may vary from developer to developer and project to project. But always ask the question…

https://dev.to/gonedark/writing-clean-code https://dev.to/gonedark/writing-clean-code-part-2-9fn

Read more

Don't design your emails

You can spend a lot of time to make emails look pretty, but it might be better to just don't style them at all. Greg Kogan did some A/B testing an concluded that sending plain emails results in more opens, clicks, replies, ...

Why are the plain emails crushing the performance of designed emails?
  • They're less likely to be caught in spam filters. Having less HTML and fewer non-text elements such as images lowers the likelihood of triggering spam filters. You can use a free spam checker to validate this by testing plain and designed emails.
  • They're less likely to go into the "Promotions" tab in Gmail (used by ~16% of all email users), for the same reasons above. From my testing, the plain emails typically end up in the Updates tab and some times even in the primary tab. Of course, the text in the email also affects this.
  • They don't look like advertisements. The second the recipient interprets your email as an ad, promotion, or sales pitch—and it does take just a second—its chances of being read or acted upon plummet towards zero. A plain email leads people to start reading it before jumping to conclusions.
  • They feel more personal. It's no handwritten note, but it's much more personal than an over-designed email with the recipient's first name crammed somewhere inside.

https://www.gkogan.co/blog/dont-design-emails/

Read more

Write tests. Not too many. Mostly integration.

In a fantastic post on his blog, Kent C. Dodds makes the case for focusing on writing integration tests, and stop going for 100% code coverage. Amen to that!

You may also find yourself testing implementation details just so you can make sure you get that one line of code that’s hard to reproduce in a test environment. You really want to avoid testing implementation details because it doesn’t give you very much confidence that your application is working and it slows you down when refactoring. You should very rarely have to change tests when you refactor code.

https://blog.kentcdodds.com/write-tests-not-too-many-mostly-integration-5e8c7fff591c

Read more

The official Vue.js style guide

The maintainers of Vue.js have recently published their official style guide.

This is the official style guide for Vue-specific code. If you use Vue in a project, it’s a great reference to avoid errors, bikeshedding, and anti-patterns. However, we don’t believe that any style guide is ideal for all teams or projects, so mindful deviations are encouraged based on past experience, the surrounding tech stack, and personal values.

For the most part, we also avoid suggestions about JavaScript or HTML in general. We don’t mind whether you use semicolons or trailing commas. We don’t mind whether your HTML uses single-quotes or double-quotes for attribute values. Some exceptions will exist however, where we’ve found that a particular pattern is helpful in the context of Vue.

https://vuejs.org/v2/style-guide/

Want to see some more style guides? At Spatie we have a guidelines site containing styleguides for Laravel and JavaScript.

This site contains a set of guidelines we use to bring our projects to a good end. We decided to document our workflow because consistency is one of the most valuable traits of maintainable software.

The contents of this site exist for ourselves—more importantly, our future selves—and for giving future collegues a reference to our way of doing things and their quirks. The guidelines cover workflow, code style, and other little things we consider worth documenting.

https://guidelines.spatie.be

Read more

Goodbye controllers, hello request handlers

Jens Segers, developer at Teamleader and author of the popular Optimus and laravel-mongodb packages, wrote about an alternative to controllers.

Let me introduce you to request handlers. The concept is very simple, yet very unknown to a lot of PHP developers. A request handler is basically a controller, but limited to one single action. This concept is very similar to the Action-Domain-Responder pattern which was proposed by Paul M. Jones, an alternative for the MVC pattern that focuses on a more clear request to response flow for web applications.

https://jenssegers.com/85/goodbye-controllers-hello-request-handlers

Read more

Who uses PHP (and Laravel) anyway?

Colin DeCarlo, a developer at Vehikl, wrote some thoughts on why PHP has a bad reputation in some circles.

People shitting on PHP isn’t going to go away, it’s a symptom of a few things. PHP has a ridiculously flat learning curve so just about anyone can write code using it, this means a lot of amateurs and ‘get it done’ developers will choose php but won’t really ever level up their skills when it comes to software development.

https://medium.com/@colindecarlo/who-uses-php-anyway-672115ab81de

I agree with Colin on everything he writes in his post. I'm also thinking that the some of the reasons on why people don't like PHP apply to Laravel as well. In my mind Laravel is to PHP frameworks what PHP is to other programming languages. Both Laravel and PHP might not do everything by the "real programming rules", but it sure is easy to use. And when handled properly powerful and maintainable stuff can be built with it.

Because Laravel is an easy framework to get started with, it's a popular choice for newcomers. Even with almost no experience you can build an app. Some of those projects will go to production. If an experienced developer that uses another framework comes by and sees that Laravel app, it might be easy to conclude that the problem lies with Laravel, and not with the inexperience of the junior programmer who just begon his/her journey in coding.

Read more