It's come to "that time of year" again and Jordi Boggiano has posted the latest update in his series of PHP usage statistics. In this summary he looks at the PHP versions installed based on the packagist.org logs for developers using Composer.

It's that time of the year again, where I figure it's time to update my yearly data on PHP version usage. Last year's post showed 5.5 as the main winner and 5.3 declining rapidly. Let's see what 2015 brought.

[...] A quick note on methodology, because all these stats are imperfect as they just sample some subset of the PHP user base. [...] 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. Of course this data set is probably biased towards development machines and CI servers and as such it should also be taken with a grain of salt.

He first compares the statics for his 2015 searches against the 2014 stats and shows the differences in usage for PHP versions 5.3.3 up to 5.6.0. Fortunately, the results show a rise in the usage of PHP 5.5 and a decline in all others...but it's not too much of a difference (2-3% range). Pie graphs are also included to help visualize these differences. He also includes some statistics on what PHP versions are required by certain packages for the ones listed on Packagist with increases starting with 5.4 and the largest advance for 5.5.

Rob Allen has a post to his site to help clear up some confusion with how the ZendInput component handles "empty" between the required, allow_empty and continue_if_empty logic.

These settings define what happens when you try to validate an empty value for a given input. For ZendInput, empty means exactly equal to null, an empty string or an empty array.

He starts by outlining each of the three settings including both their default settings and its intent. He gets into a bit more detail on continue_if_empty as it has additional logic that depends on the results of the other two settings. He includes a small test application that cycles through a set of values and evaluates them through a ZendInput instance. The output is also included in the post so you can verify your system is seeing the same evaluation results.

On the Ibuildings blog there's a new post that looks at the "evils" of a crucial part of many web applications - caching.

Recently a colleague stated that in theory, caching could be considered 'evil'. Now 'evil' is a very broad term which is used a lot in the IT community, but what does it really mean when we're talking about technical solutions? I asked around, but couldn't find a clear cut definition, so I went searching...

In his search he came across a wide range of definitions, including one mentioning bad design or implying a lack of goals with a summarized meaning of "does harm to your aesthetic and engineering judgment". He applies this to caching and, because of it being a sort of counter-intuitive way to handle content (not just the pull and push), it could be considered slightly evil. Interesting interpretation...

However, as anyone will tell you caching is a very necessary evil. [...] So while it does some minor harm to aesthetic and engineering judgment, the user gets a fast experience, which is really all that matters in the end.

In the continuing series on RSS files, DevShed has posted this new part with a focus on the "theoretical aspects" of developing an RSS file.

These aspects include things like examples of the elements it can contain, elements that are required for it to be a compliant RSS document, a look at the enhanced RSS functionality and structure (more information about the creator of the RSS embedded in the data), and even a look at what an aggregator is and what they would do with your RSS file.

Keep an eye out for the last installment in the series - a look at actually creating the RSS file from your data (probably from a database) and displaying it for the world to see.

In the continuing series on RSS files, DevShed has posted this new part with a focus on the "theoretical aspects" of developing an RSS file.

These aspects include things like examples of the elements it can contain, elements that are required for it to be a compliant RSS document, a look at the enhanced RSS functionality and structure (more information about the creator of the RSS embedded in the data), and even a look at what an aggregator is and what they would do with your RSS file.

Keep an eye out for the last installment in the series - a look at actually creating the RSS file from your data (probably from a database) and displaying it for the world to see.