Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Exakat Blog:
Versions impact on PHP code bases
Aug 01, 2018 @ 10:03:27

On the Exakat blog there's a new post covering some of the impact that PHP versions have on codebases they've reviewed in the normal course of their product's analysis and the requirements of Open Source software.

With the upcoming PHP 7.3, the question of the next migration is back on our tables. We’ll hear a strange mix of begging to move to the new versions for features and security, mixed with a constant threatening that some old versions will soon be unmaintained or worse. Indeed, there is versions impact on PHP code bases.

Particular witnesses of that evolution are open source projects. They usually have to support a wide range of versions, and in the same time, are actively encouraged to use the newest features. It is a delicate work of balancing compatibility and progress.

To observe the way Open Source projects handle the evolution of PHP, we have audited 1977 Open source PHP projects, by linting them with PHP versions from 5.5 to 7.3. This taught us the impact of PHP on code, over a long period of coding. Let’s review them.

The post starts by talking about linting of PHP files (checking the syntax for issues but not executing the contents). It then shares some statistics about the number of Open Source projects that lint on every build and how it has trended over time. They also share some results on the age of packages that are in wide use, showing that the ration of "old code" to "young code" is surprisingly similar.

tagged: staticanalysis opensource package lint age results statistics

Link: https://www.exakat.io/versions-impact-on-php-code-bases/

Jason McCreary:
Laravel by the Numbers
Jul 30, 2018 @ 11:15:01

Jason McCreary, creator of the Laravel Shift service that makes it easier to upgrade your Laravel code to new versions, has a new post to his site where he shares Laravel "by the numbers", some statistics based on the use of the service.

I had the privilege to speak at Laracon again this year. The last Laracon talk I gave, Practicing YAGNI, is one I am most proud of. Initially, I wanted to do a continuation on this topic. But there were some other talks on related topics. So I thought, “what can I talk about that’s unique to me”.

The answer was Laravel Shift. As the creator of Shift I have a unique insight into Laravel apps.

I’m super sensitive about sounding salesy. I don’t want to talk about Shift itself. I want to talk about the data derived from Shift.

The statistics are based on around 8500 Laravel applications currently using the service. He shares the results for:

  • Most popular Laravel version
  • Most popular packages
  • Most changed file(s)
  • Custom namespacing

Along with these basic numbers, he also shares information about project structures, inheritance injection, facade "abuse", queries in views (using models) and many others. Check out the full post for details on these and other results.

tagged: laravel numbers statistics laravelshift results

Link: https://jason.pureconcepts.net/2018/07/laravel-numbers/

Larry Garfield:
PHP: Use associative arrays basically never
Jul 02, 2018 @ 10:50:59

In a new post Larry Garfield suggests and interesting approach to arrays in PHP: stop using associative arrays (or at least "basically never").

The other day I was working on some sample code to test out an idea that involved an object with an internal nested array. This is a pretty common pattern in PHP: You have some simple one-off internal data structure so you make an informal struct using PHP associative arrays. Maybe you document it in a docblock, or maybe you're a lazy jerk and you don't. (Fight me!) But really, who bothers with defining a class for something that simple?

But that got me wondering, is that common pattern really, you know, good? Are objects actually more expensive or harder to work with than arrays? Or, more to the point, is that true today on PHP 7 given all the optimizations that have happened over the years compared with the bad old days of PHP 4?

So like any good scientist I decided to test it: What I found will shock you!

He starts by describing his test environment (a local environment, not a cloud one) and the code for his baseline tests. The code generates an array of one million items where each item is an associative array of an integer/string combo. He wants to see what kind of memory consumption is involved in the creation and processing of this data set via sorting. His second test evaluated the serialization size (again, code provided) again checking the memory consumption. He shares the results of these tests and then moves on to similar tests on:

  • stdClass instances
  • objects with public properties
  • objects with private properties
  • anonymous classes

The post ends with a summary showing the results of all tests side-by-side with some interesting results (but you'll have to check out the post for yourself if you want to see those).

tagged: associative array never benchmark object class anonymous results statistics

Link: https://steemit.com/php/@crell/php-use-associative-arrays-basically-never

Exakat Blog:
How many parameters is too many?
May 01, 2018 @ 11:55:47

In a new post to the Exakat blog they try to answer the question "how many parameters is too many" when it comes to the structure of the methods and functions in your application.

Now, that is a classic question, that is often a minefield for anyone writing an increasing long list of argument in a method, or simply trying to set up auditing tools.

Obviously, the answer is not immediate. Parameters may be needed, but on the other hands, currying functions allows to reduce the amount of parameter to one for every function. In between, probably exists a reasonable level that is a golden rule, and also very elusive. So, we decided to check the current practice in PHP code.

They started the research with some of PHP's own native functions that took in specific arguments, ignoring those that took an arbitrary number. Next they made a survey of 1900 open source projects to determine the common practice for parameters by function. The results showed that methods without at least one parameter were "less useful" and that a seemingly reasonable amount of parameters is 5. The post finishes with a spotlight of two they found during their research that had the most parameters: a generated class for database interaction and a dependency injection class.

tagged: parameters count statistics userland native function method results

Link: https://www.exakat.io/how-many-parameters-is-too-many/

Forma-Pro.com Blog:
PHP AMQP clients. Benchmark them all!
Dec 21, 2017 @ 11:23:31

On the Forma-Pro.com blog there's a new post from Maskim (their Chief Architect) comparing PHP AMPQ libraries including some benchmarks of their performance of their handling of messages.

Increasing popularity of AMQP interop prompted a wave of questions regarding which adapter is the fastest. In this post, I am going to share my findings of message publishing performance. There will be a similar post about consumption side.

He compares three of the main libraries: php-amqplib, amqp-ext and bunny (as well as their adapters for interoperability). To get a good comparison he's also thrown in one written in Golang for external comparison. He start be outlining the system specs he used for testing and then various graphs of the benchmark results. The results of his benchmark script are interesting with only a few oddities here and there. The post finishes with a summation of the results but you'll have to head over there to see those results.

tagged: ampq clients benchmark messagespersecond graph script results

Link: https://blog.forma-pro.com/php-amqp-clients-benchmark-them-all-8a4e6adb1a6b

Laravel News:
2017 Laravel Survey Results
Nov 06, 2017 @ 10:21:30

The Laravel News site has a new post today sharing the results of the 2017 Laravel survey posted a while back. The survey asked the Laravel (and non-Laravel) community about the framework, what they like about it and what they'd like to see in the future.

Back in September, we partnered with LaraJobs to run a Laravel survey to see what types of projects people are taking on with Laravel as well as get some feedback on what the Laravel community could be doing better. The results ended up with over 2,700 submissions and some interesting insights.

You can see the complete results on this 2017 Laravel Survey Results page and thanks for everyone who took the time to fill it out.

The results include answers to questions like:

  • why Laravel was selected over others
  • what size projects it was being used for
  • if you were able to find the Laravel developers needed (and of the right quality)
  • size of the business using the framework

Check out the full results for answers to these and other questions from the survey.

tagged: laravel survey 2017 results questions

Link: https://laravel-news.com/2017-laravel-survey-results

Trivago Tech Blog:
Continuous Performance Monitoring for PHP - The tale of Blackfire at trivago
Oct 30, 2017 @ 11:48:38

On the Trivago Tech blog they've shared some of their experience in continuous performance improvements in PHP applications and how the Blackfire.io service helped them get their best performance.

Our mission is to provide the user with the ideal hotel at the lowest rate. Our backend consists of several services written in different languages. To succeed at this goal we do complex tasks in our main application developed in PHP. While doing this we need to keep the website as fast as possible.

We started to look for some tool that could help us identify performance issues in our code base. We evaluated Blackfire and decided that it was a good fit for our use case.

The article starts by answering the question of "why Blackfire?" and continues on, showing how they integrated it with their workflow. They use the SaltStack tooling to set up servers and configure them so it was just a matter of integrating the Blackfire agent and probe extension via that. They include an overall diagram of how it fits into the architecture and how they worked around the lack of Bitbucket server support. The post finishes with some examples of performance metrics from before and after the optimizations from their results stored in InfluxDB.

tagged: trivago continuous performance monitoring blackfire blackfireio metrics results architecture

Link: http://tech.trivago.com/2017/10/27/continuous-performance-monitoring-for-php---the-tale-of-blackfire-at-trivago/

Symfony Finland:
PHP 7.1 vs 7.2 Benchmarks (with Docker and Symfony Flex)
Oct 17, 2017 @ 11:17:25

On the Symfony Finland site there's a new post sharing the results of some recent benchmarks of the differences between running the framework on PHP 7.1 and PHP 7.2:

PHP 7.2 will be launching soon, in fact, it has already reached Release Candidate status. I was exploring Symfony Flex with Docker setup and thought I would do a quick round of tests to compare the differences in PHP 7.1 and 7.2 (RC4) regarding performance with a few benchmarks.

[...] The benchmarked application is the Symfony Flex port of the hybrid application I did back in January. The project now has the required configuration to run it with Docker, and you can find the full source on GitHub.

The post then shares some of the results and conclusions of the test runs, showing the differences between the two versions. In one set of tests, they're calling the front page controller with Twig rendering and in the other a backend controller without the display rendering. PHP 7.2 ends up performing slightly better than PHP 7.1 overall but not by very much in most cases. The more dramatic change is on the backend, though, with a good jump in performance for a Symfony Flex application.

tagged: symfony flex application benchmark php71 php72 compare results graph

Link: https://symfony.fi/entry/php-7-1-vs-7-2-benchmarks-with-docker-and-symfony-flex

Tomas Votruba:
EasyCodingStandard and PHPStan meet 3 Symfony E-Commerce Projects
Oct 09, 2017 @ 12:55:22

Tomas Votruba has a post to his site showing you how to combine EasyCodingStandard and PHPStan on a Symfony-based ecommerce project. This is the second part of a series comparing the code of three popular Symfony ecommerce packages (part one is here).

In the last post, we looked at the static analysis of 3 Symfony E-Commerce projects.

Lines of code, Duplicated code, Cyclomatic complexity or Method length. These metrics are very rarely used in practise (even though there is a sniff for that).

Today, I am going to show you how you can check them with tools that can help you keep your code better on daily basis - EasyCodingStandard and PHPStan.

He's provided the code he used to analyze the packages - ShopSys, Sylius and Spryker. He goes on to talk about some of the tool choices and the resulting code violations from the PSR-2 checks. He also covers some of the "cleaners" that helped to remove some dead code and the violations uncovered by PHPStan.

tagged: easycodingstandard phpstan ecommerce results series part2

Link: https://www.tomasvotruba.cz/blog/2017/10/02/easy-coding-standard-and-phpstan-meet-3-symfony-ecommerce-projects/

Exakat Blog:
Make everything private in your PHP classes
Oct 06, 2017 @ 09:25:25

In a new post to the Exakat blog they propose an interesting idea: making everything private in your PHP classes with the basic idea being that you can more easily move from a place with more control (private) to less control (protected/public).

It is a good recommendation to make everything private in a class : constants, methods, properties. With private, comes a tighter control on the element : no one from outside may use it, limiting the unwanted impact on the object. Of course, some of the class has to be accessible from the outside, or the object may only be manipulated as a token.

[...] Eventually, when the code matures, it becomes desirable to apply the above principle of encapsulation. This helps keeps the code clean and made of independent components. This is the beginning of a long hunt.

They show how the results look for an Exakat scan of a class and go through each of the results touching on class constants, methods and properties. It also catches when a class property is a "constant" and not modified - or able to be modified - by any means. The post ends with a recommendation to "update your code with your brain" based on the interpretation of the results.

tagged: private visibility class exakat scan results recommendation

Link: https://www.exakat.io/make-everything-private-php-classes/