On the Symfony blog they've made a post about a change in all Symfony versions around how .env files are handled and what prompted the change.

When Symfony 4.0 was released, the .env file was introduced as a way to set environment variables. The core of the system has not changed. But, thanks to recent updates to some core Symfony recipes, .env loading has some new features that can be enjoyed on any Symfony Flex project!

If you have an existing Symfony app (started before today), your app does not require any changes to keep working. But, if/when you are ready to take advantage of these improvements, you will need to make a few small updates.

The post outlines what changed exactly including the removal of the .env.dist, allowing a .env.local to override the settings and that the .env file is now pulled in for testing. The final point is the main reasoning for the changes to make testing much easier when it relies on these environment variable values. It doesn't require any changes to your current application but can be optionally implemented to take advantage of these updates.

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.

Tomas Votruba has a post to his site that (sort of) continues his look at the parsing of PHP code into an AST and the use of the nikic/php-parser library. In this new post however, he covers several of the things that can be changed in PHP code using the library.

Today we can do amazing things with PHP. Thanks to AST and nikic/php-parser we can create very narrow artificial intelligence, which can work for us.

Let's create first its synapse!

He starts with a clarification about the difference between "php-ast" (an extension) and "PHP AST" (the actual abstract syntax tree). It then gets into some of the functionality that the php-parser library provides for modifying the PHP code being parsed. This includes changing method names, renaming properties, splitting classes and even potentially upgrading an application to a newer version. As an example he shows how to change the name of a method and write the result out to a file (all code is included).

On the QaFoo site they've shared a post with a helpful refactoring matrix that can help you determine the best approach to handling changes to your legacy code.

When you are beginning to consider refactoring your big legacy codebase towards a new software design, then it is not uncommon to feel helpless after estimating this to be a huge terrifying 2-5 years project.

To help solve the problem of not knowing where and how to begin, we have had great success using a decision matrix to decide how each part of the legacy code should be changed in such a refactoring project.

They start with the two main factors that should influence your decisions: the rate of code change and business value of the code. This builds out the matrix and the best way forward for each option. They go through the four approaches, what they would involve and how it relates back to the rate of change/business value factors. The post ends with links to a few other articles pointing you in the right direction for starting the refactoring process.

The folks behind php[architect] magazine have posted the second episode of their podcast - Episde #2: Embracing Change.

Welcome to the second episode of the php[podcast]. In this episode, we take a look at the September 2017 issue and the topic of managing changes both in your application and career.

Topics mentioned include using version control and testing as tools when projects change, an interview with Ben Ramsey about PHP TestFest and the keynotes at the upcoming php[world] conference. You can listen to this latest episode either using the in-page audio player or by downloading the mp3 of the show for listening at your leisure.

php[architect] magazine has released their latest issue for September 2017: Embracing Change

Articles included in this issue include:

• How I Git Along by Jason McCreary.
• Karl Hughes shares True Tales of Building PHP Microservices.
• Learn about Learning Machine Learning, Part One: Begin with What You Know by Edward Barnard.
• How to evaluate a job offer in Jumping Ship: A Holistic Approach to Changing Jobs - Part Two by Andrew Koebbe.

...as well as many of the usual columns you know and love. You can check out the full list of articles on the php[architect] site and check out the free article for a sample of the issue's content.

Jason McCreary has a post with an interesting perspective about code refactoring and what it means to refactor. He suggests that just changing code isn't refactoring and that it's more about changes in the observable behavior.

There was a good discussion on Twitter yesterday regarding a code contribution to the Laravel framework. It ended with some good questions about the distinctions between “refactoring” vs “changing” code.

While I want to focus on these distinctions, let’s first focus on the code change.

He gives an example of some code from the suggested change that reduced the number of lines in a before function call that still satisfied the requirements defined by the unit tests. He suggests that, while this change allowed the method to work as expected, it was more of a "change" than a "refactor". He suggests that because the code internal to the method changed that the "observable behavior" changed because of a special case with the return value. Existing tests didn't catch the change so it was assumed the refactor was successful even when it wasn't. Adding this test and fixing the issue then resulted in a true refactor and not just a change.

Given the symbiotic relationship between refactoring and testing, some consider the tests to be the requirements. So if all tests pass, you met the requirements. I think that’s a slippery slope. For me, the definition of “refactoring” again provides the answer through its own question - did we change the observable behavior?

On the Hackernoon site today Sebastian De Deyne has written up a tutorial showing you how to use Watchman to automatically run PHPUnit tests for your application when things change. Watchman is a tool from Facebook that watches files and directories for updates and execute actions based on the changes.

Watchman watches files and triggers actions when they change. The reasoning behing choosing Watchman: it’s easy to install, simple to configure, and reliable.

The watchman-make command - which ships with Watchman - is a specialised interface for Watchman to invoke build tools in response to file changes - exactly what we need!

In the setup he creates, Watchman is used to look for changes on files in either the project's src/ or tests/ directories and execute a bash script (code provided) that runs the tests and outputs the results. He walks through each line of the script and Watchman command, explaining how it works and what the option points to. You can see the results here of an edit to a test and the output in a Terminal window once it's saved.

On the SitePoint PHP blog Thomas Punt has returned with more pthreads knowledge and shows you a few things to watch out for when upgrading from pthreads v2 to v3. pthreads is a PHP extension that allows for better process handling directly from PHP than just the built in proc_* functions.

A fair amount has changed for the pthreads extension with the release of pthreads v3. This article aims to cover the necessary information for those who are looking to upgrade their applications from pthreads v2 to v3.

If you’re unfamiliar with pthreads, check out my introduction to pthreads instead!

He starts with some of the more generic changes in this latest version with the most major being that it can now only be used in the command-line environment. Other changes were made to workers, method modifiers and the removal of some classes and methods. He also mentions some of the methods that were changed and some new classes/methods that were added. Overall he's of the opinion that, while some of the changes could make for headaches in the transition, v3 of the extension has "received a nice cleanup and is looking ever better."

The TutsPlus.com site has continued their "Building Your Startup" series with this new article enhancing the application they've already created to send requests for scheduling changes.

As the Meeting Planner alpha testing phase began, the clearest feature gap was the inability to change a meeting after it had been scheduled. It's not an easy problem. Is it okay to just change a meeting without a participant's permission? Or should you ask? Or do either, depending on your role in organizing the meeting? What if you just want to ask if it's okay to meet 15 minutes later—that should be easy, right?

Solving all this required some reflecting on the social aspects of adjusting a meeting. Over time, I realized that the ability to adjust meetings easily after they've been scheduled could make or break the Meeting Planner brand.

He then starts out by describing the "tall mountain to climb" in the number of changes to backend, frontend and UX/UI functionality required to add the feature. He includes all of the code changes and additions that need to be made including:

• migrations to add new tables
• UI updates to add options for rescheduling requests
• form changes
• handling request submissions

Each point on the list includes code, screenshots and anything else that was required to make the update.