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

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/

Kevin Schroeder:
Magento 2 Performance on Docker (a preliminary test)
Aug 14, 2017 @ 09:58:17

Kevin Schroeder has a post to his site sharing some of the results from his initial testing with Magento in a Docker-built environment.

I can’t speak to the cost of Docker experts (I’m not one, but my experience is that once you get through the annoyance of the Dockerfile it doesn’t require much more advanced knowledge than a regular sysadmin), but I found the response interesting because my experience with Docker in production has been so good that I’ve Dockerized practically everything, including this blog. But this guy knows his stuff, and I give a lot of weight to his perspective. But my experience has been different.

Except in one place. Magento 2 on Docker on Mac is a horrible experience and it is specifically because of file system performance. But on Linux I’ve had good experiences. However, those experiences were with Magento 1 and not Magento 2. Magento 2 relies on the file system more than Magento 1 so it is quite plausible that Magento 2 is slow as molasses on Docker.

He decided that he'd try a different platform and see if the results were similar to those on an OSX system. He includes a list of four caveats and the setup including the fact that it is a "smoke test" (prelimary results) and that the rest was being done on a bit older machine. He shares the testing setup and what he used to test and compares the results to it running on "bare metal" (a normal custom setup server). His findings show that the "bare metal" instance ran only slightly better than the Dockerized version. He includes graphs for the requests handled, CPU usage and throughput from each of the tests executed.

tagged: magento docker performance testing results

Link: http://www.eschrade.com/page/magento-2-performance-on-docker

Jordi Boggiano:
PHP Versions Stats - 2017.1 Edition
May 09, 2017 @ 09:16:21

Jordi Boggiano, author and lead developer on the Composer project has posted his latest updates sharing the PHP version statistics for the first part of 2017.

It's stats o'clock! See 2014, 2015, 2016.1 and 2016.2 for previous similar posts.

A quick note on methodology, because all these stats are imperfect as they just sample some subset of the PHP user base. I look in the packagist.org logs of the last month for Composer installs done by someone. Composer sends the PHP version it is running with in its User-Agent header, so I can use that to see which PHP versions people are using Composer with.

He starts with the differences between now and the last time he ran the stats with a nice trends towards the PHP 7.x releases, especially PHP 7.1. He shares some graphs of the overall version distribution and a time-related graph showing changes in usage over time. Finally, he ends the post the same way as the others showing requirements of packages and how they've changed since the last update (what version a package requires).

tagged: version statistics results graph time php7 2017

Link: https://seld.be/notes/php-versions-stats-2017-1-edition

StackOverflow:
Developer Survey Results 2017
Mar 28, 2017 @ 09:46:14

Each year the StackOverflow site posts a survey for developers to record their current feelings, thoughts and background. They've posted the results for this year's survey with the results from over 64,000 developers worldwide.

Each year since 2011, Stack Overflow has asked developers about their favorite technologies, coding habits, and work preferences, as well as how they learn, share, and level up. This year represents the largest group of respondents in our history: 64,000 developers took our annual survey in January.

As the world’s largest and most trusted community of software developers, we run this survey and share these results to improve developers’ lives: We want to empower developers by providing them with rich information about themselves, their industry, and their peers. And we want to use this information to educate employers about who developers are and what they need.

They start by share some high level points they learned from this year's results. The remainder of the post is the results presented in a more easily consumable graph/chart form. You can, of course, download the data yourself if you're interested in running reports of your own.

tagged: stackoverflow developer survey results 2017

Link: https://stackoverflow.com/insights/survey/2017/

Laravel News:
2016 Laravel Survey Results
Jan 05, 2017 @ 13:13:27

The Laravel News site has published the results from their latest survey of the Laravel ecosystem and feedback directly from developers using it (and other) technologies.

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 1,600 submissions and some interesting insights.

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

Questions answered in the survey results include:

  • What's the one reason why you selected Laravel over other frameworks?
  • How many production applications do you have using Laravel?
  • How many users does your largest Laravel based SaaS have?
  • Are you able to find the quantity and quality of Laravel developers you need?

For each question they've shared the results (bar charts) and provided a brief commentary along with a list of things people suggested as additions to the Laravel framework.

tagged: laravelnews laravel survey 2016 results

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

Symfony Finland:
PHP 7.1 vs. 7.0 performance benchmarks with Symfony
Dec 12, 2016 @ 10:04:09

On the Symfony Finland site they've post together a post sharing some benchmark results of Symfony on PHP 7.0 versus 7.1, the most recent major release of the PHP language with some improvements of its own.

PHP 7.1 was launched on December 1st 2016. This was the first minor release after the release of 7.0 a year ago. PHP 7.0 was a revolutionary product, especially when it comes to memory usage and performance. PHP 7.1 is a more modest upgrade that brings new features and improved performance. But how much has performance improved from a year back?

The benchmarking uses the eZ Platform demo running a full CMS similar to the previous benchmarking done in 2015. The checks were run using:

  • a "clean" environment (no caching, PHP-FPM just restarted and no APC cache)
  • standard requests running in development mode
  • more requests but this time in production mode

The post shares the results with a few graphs showing them in terms of response time for both sequential and concurrent page requests.

tagged: php70 php71 benchmark symfony ezplatform cms results

Link: https://www.symfony.fi/entry/php-7-1-vs-7-0-benchmarks-symfony

Jordi Boggiano:
PHP Versions Stats - 2016.2 Edition
Nov 18, 2016 @ 11:17:40

In his latest post Jordi Boggiano (of the Composer project) has released his PHP usage statistics for the second half of 2016 based on the information gathered during Composer installations.

It's stats o'clock! See 2014, 2015 and 2016.1 for previous similar posts.

A quick note on methodology, because all these stats are imperfect as they just sample some subset of the PHP user base. I look in the packagist.org logs of the last 28 days for Composer installs done by someone. Composer sends the PHP version it is running with in its User-Agent header, so I can use that to see which PHP versions people are using Composer with.

He compares them to the statistics from May 2016 showing some interesting but not unexpected changes, mostly in the growth of PHP 7+ versions. He shares a few of his own observations of the results and encourages library authors to start focusing on PHP 7 functionality rather than 5.5/5.6 compatibility. He also shares a secondary data set - the PHP versions that libraries require that, surprisingly, is moving a lot slower than the actual PHP version adoption.

tagged: version language statistics 2016 requirement composer install results

Link: https://seld.be/notes/php-versions-stats-2016-2-edition

Mark Baker:
PHP Generators – Sending “Gotchas”
Oct 11, 2016 @ 11:54:52

In this post to his site Mark Baker has shared some "sending gotchas" when generators are used in you PHP code. The focus of the article is on the "sending" part, pushing data into the generator for evaluation and use.

If you’re reading this, you’re probably already aware of just how useful PHP’s Generators are for improving performance and/or reducing memory overheads while keeping your code clean and easy to read.

Unlike their equivalent in some programming languages, PHP’s Generators allow you to send data into the Generator itself; not simply at initialisation (the arguments that we pass to the Generator when instantiating it); but also between iterations. This has its own uses, and again, allows us to move code from our main blocks and methods into the Generator itself. [...] However, there are a few “gotchas” when we combine Generators that both return and accept data in this way, and it really helps to be aware of them when we’re developing, otherwise it can create problems.

He starts simple, showing a generator that uses integers passed in as the starting number and addition interval for each loop. He gets a bit more complex in his next example, having a method called inside the loop. While the first instance of this behaves as expected, the second (after minor modification) yields unexpected results. He walks you through what's happening to produce those results and one possibility on how to get it corrected.

tagged: generator gotcha issue unexpected results debugging workaround

Link: https://markbakeruk.net/2016/10/08/php-generators-sending-gotchas/

Medium.com:
Generating Code Coverage with PHPUnit and phpdbg
Sep 06, 2016 @ 12:36:23

In this post on his Medium page Elton Minetto shows how to generate the code coverage of your PHPunit tests with better performance using phpdbg.

In a previous post (in portuguese) I explained how to identify tests that are taking too long to execute. In this post, I’ll show you how to increase the performance of code coverage report generation using PHPUnit.

In the phpunit.xml file it’s possible to add configurations to generate reports related to the tests that are being executed. [...] In addition to changing the phpunit.xml file, to generate this information we also need to install the extension XDebug. However, by installing it we get a substantial decrease in performance.

He shows an example of the time difference in running the tests (about 1 minute without versus 22 with XDebug). He went looking for a better way and found this post talking about using phpdbg instead. He includes the "brew" commands to get everything you'll need installed and how to use phpdbg with your coverage calls rather than XDebug. However, as is pointed out at the end of the post, the results are slightly different but they're close enough to help you know what code to target next.

tagged: codecoverage phpunit phpdbg results performance tutorial

Link: https://medium.com/@eminetto/generating-code-coverage-with-phpunite-and-phpdbg-4d20347ffb45#.we2bst8uk