Freek.dev

Matthias Noback makes the case for writting your own service containers.

Dependency injection is very important. Dependency injection containers are too. The trouble is with the tools, that let us define services in a meta-language, and rely on conventions to work well. This extra layer requires the "ambient information" Paul speaks about in his tweet, and easily lets us make mistakes that we wouldn't make if we'd just write out the code for instantiating our services.

Read more [matthiasnoback.nl]

Refactoring is an excellent book written by Martin Fowler. He recently released a second edition. I'm reading it now and can recommend it to anyone interested in writing better code. Here's an interview with the author on the second edition of the book.

InfoQ interviewed Fowler about the major changes in the 2nd edition of Refactoring, how to recognize code smells and refactor code, how code reviews and refactoring support each other, what tech leads can do to encourage refactoring, the benefits refactoring brings, using tools for refactoring, and mob programming.

Read more [www.infoq.com]

?️ Use "declarative" (the state of the thing) names for your data attributes in Vue over "imperative" (an action to take on the thing) pic.twitter.com/LJk2MRT0Bw

— Caleb Porzio (@calebporzio) November 19, 2018

Read more [twitter.com]

Some solid advice from Adel Faiz: do not use a package for authorization unless you really need its functionalities. Laravel's default authorization capabilities are good enough for most use cases.

I don't want to say these packages are useless. They can be useful for projects which needs complicated authorization system, which should be customizable by customer later. Also some projects need dynamic permissions. For all other projects it's too heavy solution. Better to use simple code-based authorization.

Read more [adelf.pro]

Last week Adam Wathan's excellent Laracon US talk was published. Highly recommened to check it out even if you don't use Laravel.

Read more

Misconceptions about HTTP caching for APIs abound. Here is a little thread that covers a bunch of them.
1. "Caching API responses is WRONG, using caching for performance is a crutch and the endpoint should just be fast.

— Crashy McCiderface (@philsturgeon) October 10, 2018

Read more [twitter.com]

It's perfectly fine if your controller doesn't extend anything#php #laravel pic.twitter.com/GVLYNDhvWE

— Freek Van der Herten (@freekmurze) 27 september 2018

Read more [twitter.com]

Developers can now instruct browsers to control whether cookies are sent along with the request initiated by third party websites - by using the SameSite cookie attribute, which is a more practical solution than denying the sending of cookies.

Read more [www.netsparker.com]

In a new blogpost Troy Hunt explains why you shouldn't bother buying an EV certificate anymore.

That's it - I'm calling it - extended validation certificates are dead. Sure, you can still buy them (and there are companies out there that would just love to sell them to you!), but their usefulness has now descended from "barely there" to "as good as non-existent". This change has come via a combination of factors including increasing use of mobile devices, removal of the EV visual indicator by browser vendors and as of today, removal from Safari on iOS

Read more [www.troyhunt.com]

In an older but still relevant article on the Clean Coder Blog, Uncle Bob argues that the structure of your tests should not necessarly reflect the structure of your code.

The structure of the tests must not reflect the structure of the production code, because that much coupling makes the system fragile and obstructs refactoring. Rather, the structure of the tests must be independently designed so as to minimize the coupling to the production code.

Read more [blog.cleancoder.com]

? Reviewing your code for symmetry is a great way to improve readability.

To get started, check for paired naming, consistent tone, and relative complexity. From there any remaining asymmetric bits will be easy to spot.

Here's a before and after snippet from the @OhDearApp. ? pic.twitter.com/KAhzYBxzSd

— Jason McCreary (@gonedark) September 17, 2018

Read more [twitter.com]

Whenever you find yourself using || or && in an if statement, consider extracting the conditions of that if statement to a dedicated method with early returns. It's more readable and it makes debugging much easier.

Example: https://t.co/hUcq29uP54

— Freek Van der Herten (@freekmurze) September 12, 2018

Read more [twitter.com]

Daniel Gomes, a developer at Teamleader, explains a potential problem when cloning object in PHP.

As you know, PHP has a well-known clone keyword that shallow copy all of the object’s properties. So under the hood what it does is to create a new Object with the exact same values of that object properties – unless you change its behavior by implementing the clone() function in your class.

Read more [dcsg.me]

Here's another excellent post by Matthias Noback.

Reuse-in-the-small is definitely possible. Reuse-in-the-large is deemed to be impossible, because no two problems/projects are alike, but practice proves otherwise. There are reusable components covering entire subdomains, which are nonetheless quite successful. The chance of success is bigger if such a reusable component is used to cover for a generic subdomain. Using an off-the-shelf solution in such a case helps you save development effort which can instead be redirected to the core domain.

Read more [matthiasnoback.nl]

Here's another awesome blogpost by my collegue Seb. In this one he explains why you should and how you can create an explicit Vue component API.

When refactoring your UI to components, always keep in mind that props and events are your components public API. Just like when you're modelling your application's domain, try to keep things explicit. Props and events should be enough to tell the outside world everything it needs to know about a component's behavior.

Read more [sebastiandedeyne.com]

Here are some good reasons why you shouldn't use a first name and last name field.

The structure of a name is not the same across cultures. Users who visit your site will consist of a broad range of people from different countries. Your name field should be culturally inclusive so that no one struggles to fill out your form. With most things in life two is better than one. But when it comes to name fields one is better than two.

Read more [uxmovement.com]

Ross Tuck makes the case that not all code is equal.

Most teams follow the Broken Window Theory, fearing even a single tradeoff starts the slide down a slippery slope. This can reduce discussion (read: dissension) in the short term but leads to arbitrary compliance or worse. ... Deciding on a level of quality isn’t like deciding on a coding standard, you can’t have an off-the-shelf-always-okay answer. Quality is the place to have nuanced discussions.

Read more [rosstuck.com]

In another cool blogpost, Matthias Noback explains a few best practices around newing up objects, illustrated with some great examples.

Consider the following rule: "When you create an object, it should be complete, consistent and valid in one go." It is derived from the more general principle that it should not be possible for an object to exist in an inconsistent state. I think this is a very important rule, one that will gradually lead everyone from the swamps of those dreaded "anemic" domain models. However, the question still remains: what does all of this mean?

Read more [matthiasnoback.nl]

Frederick Vanbrabant recorded a new cool video, this time on EditorConfig.

EditorConfig helps developers define and maintain consistent coding styles between different editors and IDEs. The EditorConfig project consists of a file format for defining coding styles and a collection of text editor plugins that enable editors to read the file format and adhere to defined styles. EditorConfig files are easily readable and they work nicely with version control systems.

Read more