Phil Sturgeon has a new post today that looks at the relationship between the PSR-0 standard (autoloading structure) and Composer - noting that they're friends, not relatives.

As a huge proponent of Composer, a happy user of PSR-0 and a voting member on the PHP-FIG I get into plenty of conversations about all of them and it worries me how much confusion there is in the community about these things not actually being related. [...] It seems that a lot of folks discover Composer and PSR-0 at the same time and seem to assume they are the same thing - especially since both Composer and PSR-0 have the idea of a "vendor" and a "package", but those two things are not related to each other either. These are a few points that I have wanted to clarify during some strange conversations over the last few weeks.

He goes on, trying to clear up some of the confusion around the idea of "vendors" and vendor names. He talks about naming schemes and how they may or may not be related to the vendor name on the package. He looks at the PSR-0 loading methods and how the structure of the library/repository effects that (noting that Composer can be made to accommodate something not PSR-0 by default). He suggests that PSR-0 needs to remain "implementation agnostic" and that Composer, at the same time, should remain "specification agnostic" .

Phil Sturgeon has posted a guide to his site about running tests and contributing back to packages that live in Composer.

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.

Composer has changed how PHP developers work with external libraries and packages in even just the small amount of time its been around. One of the keys to its use, though, is getting your code listed on the Packagist site for easy requesting. In this new tutorial on PHPMaster.com, they walk you through doing just that.

You've created an awesome library, and now you're ready to open source it and share it with the world. Hopefully someone else can benefit from your work, and maybe you'll even receive a bug report or patch to make the library even better. But none of that can happen unless people can find it… and the modern way is increasingly becoming through Composer and Packagist. In this article I'll show you what information is needed in your composer.json file and how to list your library on Packagist so others can easily find it.

He talks some about the "composer.json" file for your project and talks some about the content that has to be there for Packagist to be able to pick it up correctly. He then shows you how to go over to the Packagist website, log in and add a package to their repository. It then shows you where on Github you'll need to go to set up a Service Hook to talk back to Packagist when a new version is deployed.

In a response to this previous post about the PSR-0 standard and why it might be "shortsighted", Phil Sturgeon has posted some of his own thoughts on the matter as a participant (and supporter) in the PHP-FIG group.

One of the fun things about trying to support the PHP-FIG and all the good its doing, is seeing blog posts written complaining about it by people that just don't know what they're talking about. I get involved in conversations on Reddit (dangerous I know) on a mission to understand the problems with its perception throughout the community, and try to make more knowledge readily available to avoid confusion. I put together the PHP-FIG FAQ and the rest of the group voted it in, which I believe helped a lot. Sadly some blog posts are sent out by people with a whole bunch of odd opinions that you just can't do anything about, so instead I'm going to respond with a play-by-play approach.

He goes through several of the points Tom made in his original post, pointing out places where the information was either misconceptions or just completely incorrect. He relates some of the autoloading suggestions Tom made back to things Composer can do and how this is different from "magic" on the part of the library user.

PSR-0 has its problems, but they are the two that I have pointed out and they are rather trivial. [...] If you'd like to add custom autoloaders to your Composer packages then go ahead. If you'd like to build your own custom autoloaders for all of your packages then you can do that too, but it ruins the entire purpose of what PSR-0 is meant to do. That's fine, because you don't need to use it, but I am happy as hell that PSR-0 exists and I wouldn't make drastic changes to it for anything.

For those that might have heard about the Composer package management system for PHP but haven't had the time to get into it, you should definitely check out this great primer from Dayle Rees.

Composer is something special in the world of PHP. It has changed the way we handle application dependencies, and quelled the tears of many PHP developers. You see, in the olden days, when you wanted to build an application that relied on third party dependencies you would have to install them with PEAR or PECL. These two dependency managers both have a very limited set of outdated dependencies and have been a thorn in the side of PHP developers for a long time. [...] Enter composer, king of the package managers.

He jumps right in and gets into the configuration (the composer.json file) and using it to describe the package. He shows how to set up "required" resources complete with version number information. There's a bit about setting up autoloading and classmaps too. He then moves on to getting the tool installed and using the composer.json definition to load in needed packages (and development ones if needed).

In this recent post to his site Phil Sturgeon has a reminder that you should select the dependencies for your packages wisely, and not just because they're "cool."

When I say "make sure it is worth it" I mean, don't just switch your arrays from array() to [] just because it looks cool. That was the extent of my original tweet, because I've seen a few packages doing that and it annoyed me immensely. [...] Suffice it to say, if you require a user to upgrade their version of PHP simply so you can use some syntactical sugar inside a package that nobody else is even going to be looking at, then you're an idiot. Beyond that, you're actually hurting the community.

He notes that, by requiring users that are currently only at 3.1% of PHP installs to upgrade to 5.4 just to use your library is a quick way to not have your library used. He points out that PHP 5.4 is "more than just []" for arrays and includes a reminder that several projects are still in PHP 5.3-compatibility mode just because that's the widest audience. He also briefly touches on the "push it forward" comments that people have used to justify 5.4-only packages, but notes that it's still not as much up to the developer as it is the web host.

In a new post to his site Justin Carmony shares some of his experiences with doing test-driven development (TDD) for a new project he was working on interfacing with the Omniture API. In it he shares six lessons he learned during the work.

At work we use Omniture for our web analytics, and for a long time I've wanted query our Omniture Data to run some internal reports. I discovered that Omniture has a restful reporting api, and after using it for a little bit I decided it would be nice to write a wrapper library for it. Since I had recently taken the PHP Testing Bootcamp from Chris Hartjes, I decided I wanted write it using Test Driven Development and really get my feet wet. I also decided I wanted to make the library compatible with Composer. After the weekend was over, I had an almost finished library that just requires some more work to be done, but I learned a great deal that I thought I'd share.

He's broken the post up into sections, each with their own summary:

• TDD is 90% changing the way to write code, and 10% writing tests
• Understanding Mock Objects is the real key.
• It takes almost twice as long to write code and tests then just code
• Its extremely easy to get out of the habit of writing tests.
• You'll refactor quicker and more often when writing tests
• Having testable code made me feel much better about sharing the code.

Jordi Boggiano has a new post to his site about a recent update to the Composer tool that can help make managing development-only dependencies a bit easier.

Using require-dev in Composer you can declare the dependencies you need for development/testing. It works in most simple cases, but when the dev dependencies overlap with the regular ones, it can get tricky to handle. In too many cases it also tends to just fail at resolving dependencies with quite strange error messages. Since this was quite unreliable, I set out to rework the whole feature this week-end. The patch has been merged, and it fixes six open issues which is great.

Additionally, to make it easier to work with the development dependencies, they'll by default be installed when you run an "update" in your repository. If you don't want them, you can still use "--no-dev". Also, Composer will manage them in a seperate section from the normal "require" packages. If you're not using Composer to manage your application's dependencies, look over on getcomposer.org for more details.

In this new post Patrick Allaert offers a solution that can help speed up the inclusion of files via the Composer autoloader (in addition to the already present "optimize-autoloader" option).

The problem with the classmap strategy and the nature of PHP is that there is no (easy) way to have a persistent variable across requests containing the classmap. [...] This [large returned array of mappings] can even take a big portion of your request's response time when you have hundreds or thousands of classes like it is the case with eZ Publish 5 being based on Symfony, where about 2 600 classes are involved.

He suggests something that could be included into the Composer functionality itself - creating symbolic links in the PSR-0 standard to the location of the files to make it easier for Composer to resolve their location (based on namespace, not having to find them). Some sample code is included showing an additional autoloader that then uses the vendor names to match the path directly.

On NetTuts.com there's a new screencast posted showing you a good way to create a better workflow in your PHP development using Composer and PHPUnit.

In this video tutorial, we'll again focus on workflow. Specifically, we'll use Composer's built-in autoloading capabilities, along with namespacing, to make for an elegant testing experience. We'll also review a handful of PHPUnit best practices, as we get setup with these tools.

He shows you how to use Composer to load in the packages from other projects (as well as your own) and using PHPUnit to execute unit tests for your application. He uses test-driven development, but it's not a required part of the workflow. He helps you create a simple "Calculator" test. He also shows how to manually modify the Composer classmap to load in your own classes.