In a new post to his blog, Leonid Mamchenkov has linked to a resource that aims to help developers refactor their code to use best practices and design patterns: Refactoring.Guru.

Refactoring.Guru is a great resource for learning about refactoring best practices and design patterns. A lot of the website’s content is also available as Dive into Design Patterns ebook.

Today I came across this GitHub repository, which makes this resource even better specifically for PHP developers. Yup, that’s right, the GitHub repository features all code examples written in PHP 7.3, making it super easy to jump into coding.

The repository includes a Composer configuration to pull in some analysis tools and includes examples of about twenty different design patterns in use.

In a recent post to his site Eduards Sizvos shares an opinion that's believed by many in the development world: stop learning frameworks.

We are developers. We need to stay up to date with technology. Every day, we learn programming languages, frameworks, and libraries. The more modern tools we know?—?the better.

Keeping up to date with Angular, React, Vue, Riot, Ember, Knockout is fun.

But we are wasting our time.

He goes on to talk about time, how important it is to spend on the right things and offers a story of his own where learning specific technologies didn't help in the long run. He then shares some resources (books) to help you learn good concepts instead of specific tools.

Remember – frameworks, libraries and tools come and go. Time is precious. Invest your golden time in transferable skills. Skills that will always be relevant.

Brandon Savage has a tutorial posted to his site covering the use of setter injection, some of the issues that can come with using it and how to avoid it.

PHP more or less has two kinds of dependency injection available: constructor injection, and setter injection. Constructor injection is the process of injecting dependencies through the constructor arguments. The dependencies are injected via the constructor, on object creation, and the object has them from the very beginning.

Setter injection is different; instead of providing the dependencies at construction time, the dependencies are provided via setter methods, once the object has been constructed. This allows the flexibility to configure the object during the runtime, rather than at construction.

He goes on to point out two flaws with setter injection: "half-baked" objects and the injection of potentially unused objects/resources. He spends the remainder of the post covering each of these topics more specifically and wraps it up with a recommendation to avoid it if possible and opt for useful, "fully baked" objects injected via the constructor instead.

On the Laravel News site there's a new post sharing some of the changes to the "resources" directory that are coming in Laravel v5.7.

Taylor Otwell announced that in Laravel 5.7 the resources directory will be flattened instead of having an assets folder.

The post includes "before" and "after" examples of the directory structure change and shares some Laravel Mix configuration changes that can be used to move the assets pre-release of v5.7.

On the Laravel News site they've posted a quick tutorial showing you how to change the path to views in a Laravel-based application.

In response to our post yesterday about Laravel 5.7 Resources Directory Changes, a reader mentioned that they would prefer to have their application views outside of the resources folder.

I thought I’d write up how you can customize the view path; it’s effortless with Laravel!

The change is made in the views.php configuration file, updating the value for the paths setting. You can point it to a single location (like the application path or resource path) or you can set multiple to tell the framework to search for the view in either. The post ends with a mention one thing to keep in mind about generating views and their location (and moving them around).

On his blog today Freek Van der Herten has a post introducing a new Laravel package designed to help make CORS implementation simpler in your application. CORS headers are, essentially, what allows clients (like browsers) to talk across domains in a configurable and enforceable fashion.

Recently we released laravel-cors. This package can add the necessary CORS headers of your Laravel app. In this post I'd like to give a quick explanation of what CORS is and how you can use the package.

The post starts by explaining a bit about CORS (Cross-Origin Resource Sharing) headers, what they're used for and simple examples of when they might be most useful. It then covers the package, showing how to pull it into your packages and adding it to the middleware configuration for loading on each request. There's also a more detailed configuration you can use to defined allowed and denied domains as well as the idea of "profiles" for different user levels.

On the Laravel News site there's a new post sharing a list of Laravel testing resources and package that you can use for your Laravel-based applications to make testing easier and less work overall.

Testing code is one of the more challenging parts of programming, but luckily Laravel and some other tools are making it easier than ever. Research has even shown implementing a Test-Driven Development (TDD) approach can significantly reduce the number of bugs that make it to production. Testing provides many other benefits, like the freedom to refactor large parts of a system without (as much) fear of breaking things.

With all of the benefits of testing, it’s still challenging to continually test applications. If you are looking to start learning how to test Laravel applications or you want to expand your skills here is a list of great resources to help you.

Included in their list are resources like the official documentation, Laravel Dusk, the Laracasts Laravel Behat extension, the phpspec Laravel extension and Spatie Laravel packages. Each item on the list includes a screenshot, a brief description of the resource/tool and links to get more information about it.

On the Laravel News site there's a post about a new resource for learning more about Laravel and how the framework really works: Diving Laravel.

Mohamed Said, creator of the Laravel Forge SDK, Laravel Language Manager, and more has launched a new learning resource called Diving Laravel. [...] The site currently has the following topics, and more will be added in the future: The Exception Handler, The Task Scheduler, Package Auto Discovery, The Notifications System, and Diving Redis.

The site breaks each of the components down into "dives" with smaller tutorials covering different aspects in each. All of the content is free for anyone that wishes to get a more in-depth look at what happens under the covers when Laravel handles your code.

To start off the new year the Laravel News site has posted a list of 80 tutorials, packages and resources they've shared with the community over the past year.

As 2016 is coming to a close it’s a great time to look back on the year and see just how much progress has been made. Laravel had a busy year with 5.3 being released, Laracon, updates to all the components, and now gearing up for the Laravel 5.4 release.

To look back on the year I’ve put together a list of some of the hits of 2016 and arranged them by month so you can get a quick overview of all the highlights.

There's lots of good content posted here and it's interesting to see all of the developments in not only the Laravel community but also the wider PHP community (including the fifth birthday of Laravel in June). Check out the full post for the complete list and links to each post.

In a post to his site Frank de Jonge looks at a few different topics around the idea of "cleaning up after yourself" when it comes to the use of finally, file streams and deferred execution.

Cleaning up after yourself can be a tedious task. For example, closing file handlers after using them needs to be done. A programmer's life isn't all about the happy path. When things go pear-shaped you might end up duplicating cleanup code throughout your code. This is horrible, let's explore an alternative.

He starts by looking at the use of resources for file handling instead of something like file_get_contents. Along with this, however, comes "less happy" things to do around cleanup of the resource in case of error or when complete. He suggests that it can be better handled and, after comparing a PHP function version to a Go function doing the same, refactors to make use of finally to close the resource in one place (and it is always called exception on exception). He refactors it even more by splitting it out into a "cleanup" function that can be reused in other places where resources are accessed.