While Composer has been around for a while now, many packages are still in their infancy (< 1.0) or sometimes are just not as feature filled as they could be. To be fair there is always more to be done. It can always do more, or do the same thing more efficiently. Whatever the case, pull requests are going to be a common thing for the PHP community to be doing to these packages and this needs to be done safely, with unit-testing. So, how do you run their test suite and add your own tests?

He includes a step-by-step guide to getting the environment set up to run the package's tests and how to add some of your own. He includes the commands to send the pull request back up to Github (on your own fork, of course) and how to use that same fork as your package resource until the main project is updated.

When it comes to multi-tasking and interacting with the operating system, PHP is no lightweight. In this December 6, 2012 presentation Jonathon Hill (@compwright) explores PHP's little-known POSIX, Process Control, and Semaphore extensions and shows you how to introduce a parallel dimension to your applications.

His presentation covers the use of multi-tasking to accomplish some common tasks in PHP (like batch processing or creating daemons). He talks about multi-processing vs multi-threading, forking, race conditions and semaphores.

You can watch the video of the presentation over on Vimeo and check out the software and links to other resources mentioned in the talk in this link bundle.

Often I find absolutely competent programmers, who aren't involved in open source, either because they don't know how to approach a project, or because they just aren't sure how the process even works. In this article we'll look at one example, the conference feedback site joind.in, and how you can use GitHub to start contributing code to this project. Since so many projects are hosted on github, this will help you get started with other projects, too.

She covers all you'll need to know to get in and get going with Github - forking a current repo (she uses Joind.in as an example), cloning your fork, making updates and submitting them as a pull request back to the main project. There's also some things about general git topics like branching, merging from the upstream source and using "git log" to view the changes.

At some point, many php developers turn to the pcntl functions in php to write a daemon, or server, or simulate threading. But how do you unit test this with complete code coverage? [...] We need to engage some black arts php extensions to make this happen. An installation guide follows, and the post ends with a complete listing of the unit test.

He uses the test_helpers extension (as provided by Sebastian Bergmann) and Runkit to allow the test to define new methods copying the current pcntl methods and mocks up the responses. Tests are included to check the parent of a process, checking the children of a process and testing that a fork could be made. Hes's even included visual proof of this working.

It's amazing that we are even having this type of discussion. We opted to use Symfony back in 0.x for some high traffic projects. [...] And now here we are on 1.4. Content and happy with the throughput the dev team is able to maintain. But now Symonfy says that 2.0 will be released and is completely different than 1.x? How is that fair to the companies, individuals, and hobbyists who have sunk time over the last four years ramping up to a point where we can take advantage of RAD (rapid app development) approach that Symfony provides?

He wonders if this same discussion will be being had years down the line when Symfony3 decides to come up on the horizon. Will there be such a major change in the architecture that developers, only a few years earlier making the major change to to Symfony2, will get burnt again?

On the Lately in PHP podcast episode 13, Manuel Lemos and Ernani Joppert interview Lucas Carlson, founder and CEO of PHPFog, to tell us about the advantages of using a Cloud Hosting service that is optimized to address needs that are specific to PHP Web sites and applications. They also comment on the PHP 5.3.6 forked version released by Robert Eisele and the PHP features being voted for inclusion in version 5.4.

You can listen to this latest episode in a few different ways - either via the in-page player, by downloading the mp3 or by subscribing to their feed.

The idea of forking came up. But is this really going to happen? And does it make any sense at all? What would be the benefit of forking symfony 1.4 and continuing development of the 1.x branch?

He suggests that it might be worth it because the branch is currently stable, it has a proven track record, there's already several plugins available and there's a comfort level among developers using it. He still asks the "why?" question, though:

Not switching to Symfony2 would essentially mean that you accept these flaws [in 1.x]. Now even if I don't agree I can not see a reason to argue against this. Being pragmatic is not a bad thing as such.

A fork is a new version of a project that a separate group of developers that want to give the project a different route. A new PHP forked version was created by Robert Eisele to address needs that he felt were important.

He mentions the forked version as updated with the changes Robert wanted to see made and a few other concerns that have come from it. One issue is the PHP name and licensing problems and another is whether or not you should use this fork (and what its future might be).

It took me a while but here's a new toy. Today I publish my own PHP fork based on the PHP 5.3.6 code base with a few changes that make the everydays developer life more bearable. It includes some of the patches I've already published about 3 years ago, my defcon extension and also my infusion extension plus a good bunch of extra gimmickries.

Updates in his release available on github) include:

• Hardcoded constants
• Turn off $_REQUEST variable if it's not needed
• new methods like str_random, ob_fwrite, sigfig and strcal
• changes in foreach, strstr and binary number handling
• updates to MySQLi/mysqlnd to return matched rows and mysqi_return

The community reaction to this fork has been divided - some think the work put into these changes should have been submitted to the main PHP project instead and others see it as a good step forward for the language. Share your thoughts by commenting on the post.

As Dries says in his blog:

It seems that we have arrived at a point in which there is a symbiotic relationship between PHP and the most popular PHP applications. A relationship that did not exist when PHP was created. Symbiotic relationships are obligatory: we depend entirely on each other for survival. And yet, I feel like we've been living apart. It makes sense for us (i.e, application developers) to contribute to the development of PHP, and for the PHP core developers to work more closely with the developers of the most popular PHP applications.

He points out that, in Acquia's case, there's just not enough time for the group to contribute back to the PHP project. Other posts surrounding this same discussion have also noted that there's not a good mechanism for people to "give back" to the PHP project and that getting involved requires a certain skillset that lots of developers don't have.