On the Laravel News site Tim MacDonald has written up a post sharing some tips on how you can speed up your PHPUnit tests, making them easier to run and more useful during the development process.

Having a fast test suite can be just as important as having a fast application. As a developer, getting feedback quickly about the state of your code allows for a much quicker development turnaround. Here we are going to run through some tips you can implement today to make your tests run faster.

The example test suites have been made intentionally slow to simulate a broader set of tests and also to emphasize the improvements possible. Your real-world mileage may vary.

He makes recommendations around the use of ParaTest to run the tests in parallel, re-running only failed tests, grouping slow tests, lowering the password hash "rounds" count and disabling XDebug. Each item in the list includes instructions on what changes need to be made and screenshots of the results of the change.

The Laravel News site has a new tutorial posted showing how to speed up your PHP execution when developing with Docker by making use of the OPCache functionality.

If you’re on Docker for Mac or Docker for Windows, you might see some noticeable slowness and time to the first byte (TTFB) depending on your application’s setup. One of the most important things you can do to improve performance is enabling the OPCache module (regardless of the development environment). There are other things like volume caching (if possible), but OPcache is a win that you want in any environment you’re running PHP applications.

The tutorial starts by sharing a basic Opcache configuration, setting values for timestamp validation, memory consumption, and fast shutdown. These values are static and not very flexible so they change things up by making them able to be set as a part of the Docker build process. The post includes the changes you'll need to make to your Docker configuration to make this setup work in two ways: either copying the file in on build or making use of environment variables to set the configuration options at runtime.

In a recent post to the Hackernoon site, Sergii Shanin shares his take on the "PHP is dead" conversations and posts out there with the expected "Viva le PHP!" (long live PHP!) following it.

The fracas over Gutenberg and WordPress is the latest installment in the death of PHP. Take a deep breath everybody. Let’s ignore the trolls and take a look at what Mark Twain, Fidel Castro and PHP have in common?—?and more to the point, why PHP is still a reasonable choice for startups and small businesses.

t looks like ‘PHP is dead’ blog posts started cropping up in 2011 (let me know if you find older ones). If you search around Medium and the coding bootcamps that are popping up like mushrooms, the only common denominator is that everyone hates on PHP or simply ignores it. Apparently, it’s impossible to code in PHP with an oiled beard and ironic t-shirt while drinking overpriced coffee.

He shares two of the most wide-spread myths about PHP - that it's slow and that it can't scale - and dispels them. He then goes through some types projects where PHP "shines" including content driven websites and e-commerce sites. He shares some the "business sense" around choosing PHP, the perspective senior PHP developers bring to teams and projects, and the seeming "nine lives" of PHP.

On the Symfony blog there's a post covering some of the recent improvements in the framework that can help to make creating and updating Symfony projects faster via some recent changes speeding up the Composer installation.

A few years ago, we introduced the Symfony Installer as the fastest way to create new Symfony projects. While Composer took up to several minutes to create a new project, Symfony Installer did the same in less than ten seconds.

The trick was that the installer downloaded a ZIP archive with all the dependencies required by the specific Symfony version you were installing, so it was not necessary that Composer resolved the project dependencies.

However, with the release of Symfony 4 we deprecated the Symfony Installer in favor of Composer, because we wanted to use standard development tools as much as possible. Sadly this made creating new Symfony projects slower and, in some cases, it triggered "out of memory" exceptions while Composer was resolving the dependencies.

The post talks about the changes they made to the Composer installation process, mentioning the two major changes: including a composer.lock to prevent version resolution and removal of all legacy Composer tags. They also share some benchmarks for the installation both before and after the changes showing a jump of at least ten seconds post-changes.

In a new post to his site Tomas Votruba covers a recent release of the "symplify/package-builder" package for Symfony, detailing each of the updates and including examples of the change in action.

Symplify 4 was released and with it also one package, that contains all the Symfony tweaks that Symplify packages use.

Throwable render? Test services without public violation? Load parameters with glob? We got you covered!

The four new features are:

• Console-Like -vvv-Aware Renders for Exceptions and Errors
• Drop Manual public: true for Every Service You Test
• Autowire Singly-Implemented Interfaces
• How to Decouple Parameters to multiple files in Safe Way

Each section also comes with some explanation of the change, the code related to it and configuration changes if they're required. You can find out more about the package on its GitHub repository.

On his Code Diesel site Sameer Borate has a quick post sharing a helpful tool that can make profiling the SQL queries your application makes simpler. In this post he shows how to use the Neor Profile SQL profiler desktop application (compatible with Windows, OSX and Linux) to hook into your SQL flow and evaluate the queries in real time.

Most MySQL applications need profiling for speed enhancements at one time or other. I’ve developed several web applications in the past wherein MySQL queries were a major bottleneck in the application performance. In the past however there were no easy tools to analyse SQL queries in a running application and we programmers had to depend on some makeshift solutions to debug SQL queries. Now, however there are some nice free tools which can help you profile MySQL application queries easily.

My favorite among them is Neor Profile SQL profiler. This is a desktop tool which allows you to easily profile your application SQL queries and also lets you query the same in a live application.

He starts with the changes to make to your configuration to point to the profiler for interception. This is then hooked into the MySQL database and queries will be profiled in real-time. The tool provides information like time of execution, number of rows returned, a graph showing the queries by type and includes the ability to run (or re-run) custom queries.

On the Symfony blog they have a post covering the result of some changes to how the framework handles incoming requests in Symfony 4: a performance and speed increase in the router making it even better than before.

Symfony 4 is the fastest PHP framework according to independent benchmarks, but we are continuously working on making it faster. In Symfony 4.1, we improved the Routing component to make it much faster when matching incoming URLs.

The post starts with a look at the two functional pieces of route handling: the generation of a URL to match and the matching the framework performs. Symfony 4 has sped things up by creating a "matcher" class during the compilation phase using some of these suggestions. The biggest change was to modify the regular expression URL matching to combine all patterns into one, reducing the number of calls to preg_match and locate the correlating route. The new routing requires no changes in your current Symfony 4 application, it just makes all of the updates it needs behind the scenes during compilation.

php[architect] magazine has posted their latest issue, the July 2017 edition of the magazine - Safe at Speed:

“Safe at Speed” includes articles on:

• Setting up infrastructure from Zero to Cloud in One Hour With the Google Cloud by Robert Aboukhalil.
• Geogriana Gligor writes on Smart, Scalable Content Distribution.
• Brush up your front end skills with Modern JavaScript: Moving Beyond jQuery by Derek Binkley.
• Learn how and why we must of safety first when writing code in The Train Wreck: When Safety Is Discretionary by Ed Barnard .

The regular columns are all returning too including Community Corner and a new column from Chris Tankersley called "The Dev Lead Trenches". You can get more information about this latest issue, pick up a free article and get a copy of your own from the php|architect site.

If you've heard about the release of PHP 7 but aren't quite sure what it has to offer, check out this quick post on the StartTutorial site giving you a "top five" list of things this new version of the language has to offer.

But you must be wondering why PHP named its latest release PHP 7 and not PHP 6. Reason behind it is that, many of the PHP 6 releases were already implemented in PHP 5.3 and later, there was not really a proper reason just to change the name. What I am trying to say here is that we haven’t missed anything. Just to avoid the confusion with a dead project, PHP's latest release was named to PHP 7.

Is This Hype Valid for PHP 7? What It Actually Brings Forth for the Developers? Hop on and let’s take a deeper dive. Let's check out what new features PHP 7 has to offer. And what improvements those features will bring forth.

Their top five list covers some of the major improvements in the language:

• Speed Improvement
• Implementation of Type Declarations
• Implementation of Error Handling
• New Operators
• CSPRNG Functions

There's a bit of explanation of each item on the list but you'll definitely want to refer to the PHP manual for more details and specifics on what changed in PHP 7.

In this recent post to his site Dries Vints shares two quick tips you can use to help speed up the execution of the tests for your Laravel application.

I've seen two different tips for speeding up your tests in Laravel in the past week and thought I'd share them with you. For me, they made a significant impact on the speed of my tests.

His two tips involve lowering the "cost" factor on the number of "rounds" the user password is hashed and the use of a pre-computed hash in your testing factories. These both help reduce the overhead needed, especially when working with tests that need to create the user every time. He includes code and reference links for more information about these two tips and applying them in your testing.