Continuing the theme of posts related to using PHP on the OpenWhisk serverless platform, Rob Allen has posted a few notes for working with the PHP runtime.

These are some notes for working on the OpenWhisk PHP Runtime, but are probably applicable to the other runtimes too.

His notes cover:

• some basic setup
• building the two containers (PHP 7.1 and 7.2)
• running tests
• using the container interactively
• checking the format of Scala files

Commands are included for each item along with some of the output to expect.

Michelangelo van Dam has posted a "follow up" to his previous article about setting up a PHP installation on the recent versions of Mac OSX. In this new tutorial he makes some updates for the latest OS X release: Sierra.

Apple has released the latest version of their OS X operating system to the broad public and many have already upgraded their mac devices. But as it goes with each release, Apple likes to do things a bit different making it quite challenging for PHP developers to stay current with the latest PHP version (or other versions).

This version of mac OS (11.12) comes pre-installed with PHP 5.6.24. [...] Good for Apple, but this version reaches end-of-life support by the end of this year, so it would be great if you could upgrade to PHP 7.0 or even play with the latest PHP 7.1 release candidates.

While he points out that things like XAMPP and Homebrew can be used to set the installation up, he focuses more on compiling and installing it natively. He shares an issue he had with a missing runtime and how to get it installed and working happily so the PHP compile completes without issues.

In this new post to his site Leonid Mamchenkov talks about some of his "adventure with Composer private repositories" in some of his deployment work with CakePHP 3 applications.

As good as the Packagist is, there is often a need for a repository or a package elsewhere. Whether it’s a commercial library, or sensitive corporate code, having an ability to store it outside of public eye and handle with the same ease and the same tool as the rest of the dependencies is a very welcome feature.

[...] We are setting up similar development and deployment process, but now for CakePHP-based projects. Things are much easier, since CakePHP 3 natively supports composer for the application itself and for its plugins. But we still have the need for private repositories here and there, so we follow the same setup as we did for WordPress.

Unfortunately he was getting a RuntimeException when he was trying to pull in a plugin through the same private repository workflow. Not only had he not seen the error before but the autoloader was configured as defined and other plugins were working with the same structure. As it turns out, it was the composer.json of the main application repository that was the problem. He includes the fix he made to the configuration on a sample CakePHP 3 project, showing how to switch it to a "vcs" type for more correct handling.

On the Acquia blog they've posted another in their guest post series, this time from Richard Miller, a Senior Technical Consultant with SensioLabs (the people behind the Symfony framework). In this new post he talks about how the performance of PHP is getting better and why.

PHP is not the fastest language in which we could write web applications, yet we continue to do so for many other reasons. Pure speed of a language is rarely the main deciding factor for many projects. [...] So why worry about the speed of the language at all? Well, application architecture is improving and we are finding ways to avoid all those other bottlenecks. [...] Trying to gain speed through profiling and optimising code can be a long and tedious process. Thankfully, improvements in the speed of the language itself give us an improvement in these other areas for free.

He looks at "a brief history" of the language and the major milestones that have lead to the biggest performance gains over the years. He also talks about some of the alternatives out there to "normal PHP" for execution including the HHVM and HippyVM projects. He ends the post with a warning, though - be careful of fragmentation and separation of the community based on these different tools and embrace things like the language specification to keep things on an even keel.

On the Google Developers Blog (and lots of places across the web) there's a major update that Google has done for their AppEngine service - the introduction of a PHP runtime to their offerings.

App Engine 1.8.0 is now available and includes a Limited Preview of the PHP runtime - your top requested feature. We’re bringing one of the most popular web programming languages to App Engine so that you can run open source apps like Wordpress. It also offers deep integration with other parts of Cloud Platform including Google Cloud SQL and Cloud Storage.

You can get more information about how to use this new feature on Google App Engine site.

While admitting that micro-optimizations aren't usually worth the time that's taken to worry about them, Gonzalo Ayuso has thrown together some array read benchmarks to show the difference, if any, in where array values are fetched.

Normally our code is coded once and executed thousands of times, and we must keep in mind that CPU time many times means money. We need to balance it (as always). But, WTH. I like micro-optimizations, and here comes another one: Checking the access to arrays with PHP.

He sets up three different options and tests the memory consumption and run time for each:

• Referencing a value from a large array outside a for loop
• Referencing a value from a large array inside a for loop
• Echoing out the value from a large array inside a for loop

Not surprisingly, all three approaches yield just about the same results. It probably has more to do with the size of the large array than how it's accessed. The fetch outside the for loop did come in slightly under the others, but not enough to worry about it.

Gonzalo Ayuso has put together an experiment related to the current OOP structure of PHP - a test working with runtime classes, a structure generated entirely when the script is executed and not predefined in the file.

Last week I was thinking about creation of a new type of classes. PHP classes but created dynamically at run time. When this idea was running through my head I read the following article and I wanted to write something similar. Warning: Probably that it is something totally useless, but I wanted to create a working prototype (and it was fun to do it).

His class is pretty basic - a "Human" object that echoes a "hello world" sort of message via a "hello()" method. He creates the classes inside of different test methods to ensure that his assertions are true. The tests check basic output of the "hello()" method, calling undefined methods, testing inheritance and a test creating and evaluating a dynamic function.

For something more complex, he creates a dynamic class that solves the FizzBuzz kat, a popular programming puzzle. You can find the full code for this and his other examples on github.

During some of his development, Christian Weiske found the tests for a project he was working on too slow for comfort and figured there had to be a way to find the root cause:

Running the specific test cases for the part of the application you're working on is easy and fast, but that does not tell you when changes in part A of the app break part B - which happened several times, and all just because I didn't want to wait 45 seconds again and again. So a solution was badly needed; tests should be as fast as possible; preferably < 10 seconds. Before being able to make the slow tests faster, I had to find out which of the 80 tests were slow.

Tools like Jenkinks give more detail on test runs, but a normal PHPUnit install won't. So, he came up with a method that uses Phing's phpunitreport task to generate extra reporting easily. Here's some example screenshots: test results summary, test detail and single page views of the same sort of data.

Shay Ben Moshe has put together a quick post today where he benchmarks array handling performance differences between PHP's native array and the newer SplFixedArray data structure that's a part of the Standard PHP Library that comes with any recent version of the language.

In PHP, arrays are one of the most fundamental data structures. We use them everywhere. They are very flexible, because they are implemented as associative arrays, and therefore let us use both string and integer keys. They are also unlimited in size, in most languages arrays are fixed-sized, but this is not the case in PHP. With that in mind, there still is a drawback. It damages performance. The solution for this problem may be SplFixedArray. But, it is not a perfect solution.

He points out two major differences - the SplFixedArray is, well, a fixed size and the fact that it can only use integer keys (no associative arrays here). He created three tests to compare the performance of the two:

• Writing data to the array
• Reading data from the array
• Getting a random value from the array

Each of these are measured in terms of runtime and/or memory usage. If you'd like to try out the tests for yourself, you can download the files needed. I won't cover the results of the tests here, though - you'll need to visit the post for that!

Ralph Schindler has put together a new post for his blog about some of the best practices for using exceptions in PHP 5.3 - specifically dealing with some of the new functionality that comes with this latest PHP version.

Exception handling in PHP is not a new feature by any stretch. In this article, we’ll discuss two new features in PHP 5.3 based around exceptions. The first is nested exceptions and the second is a new set of exception types offered by the SPL extension (which is now a core extension of the PHP runtime). Both of these new features have found their way into the book of best best practices and deserve to be examined in detail.

Some of the features he talks about were pre-PHP 5.3, but the focus is largely on these new features. He gives a bit of a background on exception handling in PHP and how custom exceptions could be thrown. He then moves on to the new features - first nesting exceptions and then some about the new core exception types (found here). All that being said, he includes some code to show the dynamic/logic/runtime exceptions in action including a look at best practices in library exception handling.