On the SitePoint PHP blog editor Bruno Skvorc has written up a post that talks about why a string is called a "string" going back through the history of the term and discovering its origins.

Why is a string called a string? Have you ever given this some thought? We never use such a word in contexts other than programming for a set of letters sticking together, and yet – in programming it’s as pervasive as the word “variable”. Why is that, and where does it come from?

To find out, we have to tackle some related terms first. History lesson time!

He starts with these related terms including "font", "uppercase" and "lowercase". He talks about the printing process and how the "stringing together" of the series of characters might have been how customers using the press were charged. He then shifts over to the academic world for background there relating to a series of numbers and letters used in decision problems. The term caught on and showed up in several other academic papers over the years ending up eventually in programming language definitions and examples.

If you were ever interested in the early days of PHP (back in the PHP/FI days, pre-3.0 even) Rasmus Lerdorf has a post sharing an old Changelog he created for some of the first PHP version releases.

Ran across this Changelog from a long long time ago. Read from the bottom up. I added the PHP Tools lines at the bottom for context. So many early decisions made on a whim still affecting us today. And then there are things like "Removed **, // and %% operators" which did a vector dot-product and its inverse, I think. I seem to recall deleting it when I tried to document it.

No years on most of the entries, but version 1.90 was on Sept.18, 1995.

It's an interesting read to see some of the thoughts and additions to the language early on. You can see which functions were added way back then and which ones have been dropped since including an entry for October 17th - "First public release of the code".

On the SitePoint PHP blog paul Jones has written up some of his own perspective on the PHP-FIG and the work that's currently being done by the group on restructuring to make the group more effective, learning from past issues.

In his article The Past, Present and Future of the PHP-FIG, Larry Garfield gives a whirlwind tour of his impressions of the FIG, from its founding to one of its possible futures. I encourage you to read it in its entirety before continuing.

Herein, I will attempt to address some of the errors and omissions in Larry’s article, and offer two other possible futures for the FIG.

He starts by talking about the largest change the group is working on - the PHP-FIG 3.0 proposal. He compares the vision of this effort to some of the founding goals and principles of the group as documented in various emails and posts from current (and past) members of the group. Paul also talks about the FIG 2.0 workflow, what PSRs were before/after it was introduced and some of the overall impact that these and other PSRs from the group have had on the wider community.

He wraps up the post with a look at two alternatives he's proposing for the group's consideration as a way forward and an alternative to the PHP-FIG v3: independent interop groups and disbanding the PHP-FIG all together.

On the SitePoint PHP blog Deji Akala has written up a post talking about the PHP-FIG - some if its history and its current role in the community.

The Polish writer, Henryk Sienkiewicz, was awarded the 1905 Nobel prize for Literature for his epic novel Quo Vadis, which is a Latin phrase meaning “Where are you going?”. In the face of any dilemma, a brief pause and redefinition of one’s goals may be therapeutic.

The PHP Framework Interoperability Group (PHP-FIG) has come of age. With the acceptance of more PHP Standards Recommendations (PSRs), PHP has attracted further positive attention and admiration of the programming community. PSRs governing coding standards, coding style guides, autoloading, logging, caching and HTTP messages have been accepted.

[...] However, the future isn’t as bright as painted, as a recent ruckus within the organization has thrown its continuing existence under doubt.

The post starts out with some of the origins of the group and how its organized and communicates (with a large part of it being the main mailing list). There's some mention of the successes that the group has had (like PSR-0/PSR-4 that allowed for easier creation of the Composer package manager) as well as some disputes that have risen recently about the goals of the group. the post wraps up with a look at other open source communities, the fact that people don't always "see eye-to-eye" and some of the author's own thoughts about the state of PHP-FIG and its future.

One note here: be sure to read the comments on the post - they help clear up a few misunderstandings in the article's contents and give a wider context to the group and its current state.

As Freek Van der Herten mentions in this post to his site the latest release of the Laravel backup package has been released - version 3 - with some major improvements over previous releases.

Today our team released a new major version of laravel-backup. It can backup the files and databases of your application to one or more external filesystems. It uses Laravel’s native cloud filesystem to do this. The package can also notify you via Slack and/or email when something goes wrong with your backups. We’ve also created a dedicated site with full documentation. In this blogpost we want to give you some background of why and how the package was created.

They start out with a bit of history about the package, talking about how they created it to fill their own needs and how its risen in popularity since its release. Following this the post talks about new features in version 3 including:

• Taking backups
• Cleaning up old backups
• Monitoring the health of all backups
• Sending notifications

There's also some brief mentions of other new features around event hooks and adding additional information to the backup file. There's a bit of code shared to show the quality/readbility of the code and links over to various resources on the documentation site as well. Finally they mention some information about the use of the package in PHP 5 (it has become PHP 7 focused with this release) and some of the alternatives that are out there.

In this post to his site Derick Rethans talks about some major updates that have been made to the MongoDB drivers for both PHP and HHVM users.

We recently released a new version of the MongoDB driver for PHP. This release is the result of nearly a year and a half work to re-engineer and rewrite the MongoDB driver. In this blog post, I will cover the back story of the how and why we undertook this effort.

He starts back with the original driver (in 2009), the features it offered and how it was structured. He talks about the evolution of the functionality to more of a C PHP extension and when it reached the v1.0.0 milestone. From there he talks about updates made to the JSON handling, features added in 1.3 and some of the larger design issues they ran up against making future development much more difficult. He ends the post with an overview of their goals for this new driver version and a promise for a following post with more details on this structure.

On the Liip blog they've taken a look back at the impact that the Symfony project (and related projects) have had on the PHP community and ecosystem.

As we were preparing the news about becoming a [Sensiolabs Silver Partner](https://www.liip.ch/en/news/archive/2015/10/15/liip-now-a-sensiolabs-silver-partner.html), I brought back a bit to the history of Symfony here at Liip. We did do a few symfony v1 projects at Liip but things only really took off with Symfony2. Back in 2009 Fabien came to Zurich to discuss some of the Symfony2 components (still PHP 5.2 compatible at the time) he had just released as well as a few he hadn’t yet released. Jordi, who was working at Liip at the time, and I integrated all of them into our company internal framework over the following months which we later presented at the Symfony Live. This means Liip in fact build the [first Symfony2 framework](http://www.slideshare.net/lsmith77/okapi-meet-symfony-symfony-meet-okapi), even before there was the official Symfony framework.

He goes on to talk about the early days of the Symfony community and the work that was done on several bundles outside of the framework itself. He touches on the Symfony ecosystem and its growth during this time and the influence it has had on the PHP community.

All and all I believe that Symfony has really commoditized the concept of a framework for PHP applications. Reusing an existing framework is now the standard when building new PHP applications. Any project that wants to stay alive will in the long run have to refactor on top of a framework.

The HHVM blog has a new post that talks about covariance, contravariance, and super type constraints - enhancements to the previous generics handling in the Hack language.

Hack has recently enhanced its generics with two features: variance annotations and super type constraints. In this post, I’ll explain how they work and why they were added.

They start with variance and how the idea of covariance (consistent type variance in class parameters) fits in. They include a code example showing how this typing works and some of the issues with following this covariance flow. Following this they talk about contravariance, the opposite of covariance, where the typing can be used as a parameter type but not a return type. They go on to talk about the idea of "super type constraints" and how they augment the current type constraint handling to provide improved type resolution. They end the post with a bit about how "super" relates to "as" constraints and a historical note about some hard-coded class names that are always resolved as either co- or contravariant by the typechecker.

As Matthew Weier O'Phinney mentions in his latest post, the PSR-7 standard (HTTP) has passed and is officially accepted as a standard by the PHP-FIG group.

The road to PSR-7 was a long and winding one. It started in summer of 2012 as a draft proposal on HTTP clients by Benjamin Eberlei, during which others proposed that perhaps a smaller standard on the HTTP message interfaces themselves — which would also allow targeting server-side applications, as those rely on the messages.

He follows the proposal's flow through the PHP-FIG process, pointing out several others who contributed along the way and what changed along the way. He also includes a section of thanks for some of the other developers and PHP-FIG members that made contributions along the way.

Derick Rethans has posted the first in a series focusing on the Xdebug tool and the code coverage functionality it can provide via PHPUnit's testing. In this first post he catches the reader up on the current state of things and what all the Xdebug tool can do.

Since ages Xdebug has provided code coverage support for PHPUnit, a way to show which lines are covered by your test cases. But I never really wrote about how it works. A recently filed bug prompted me to write this post, as well as a follow up post on Code Coverage's future.

He starts off with the early days of Xdebug, how it hooked into the Zend Engine (that powers a lot of PHP behind the scenes) and when it was triggered. This came with its own set of problems so Xdebug was updated to overload some opcodes. He talks about how it can calculate the unused lines and determines which lines can be covered in the code coverage results. He provides some example code showing the execution of the coverage report on a simple function and try/catch handler, complete with the HTML output of the results.