Jordi Boggiano, lead developer on the Composer has posted about some of the new Composer patterns that have been introduced into the tool this year, including some you might not even have realized.

Here is a short update on some nice little features that have become available in the last year in Composer.

He includes five of these features in his list (but something tells me these are just some of the more user-facing improvements the project has introduced):

• Checking dependencies for bad patterns
• Referencing scripts to avoid duplication
• Defining your target production environment in composer.json
• Excluding paths from the optimized classmap
• Requiring packages easily and safely

For each item he includes the command (and sometimes optional arguments) that make it work and what kind of results you can expect. There's definitely some handy features in here and not just for the "power users" in the crowd.

In a new post to his site Mattias Noback makes a case for clones (in response to this post from Phil Sturgeon). In it he defends the creation of "clones" of tools, either slightly different version of pre-existing PHP packages or the functionality from a package in another language.

There is this ongoing discussion in the PHP community (and I guess in every software-related community) about reinventing wheels. A refreshing angle in this debate came from an article by Phil Sturgeon pointing to the high number of "duplicate" packages available on Packagist. I agree with Phil. [...] It doesn't make sense to do the same thing over and over again. At least I personally don't try to make this mistake. If I want to write code that "already exists", at least I don't publish it on Packagist. However, recently I got myself into the business of "recreating stuff" myself.

He talks some about one of his own projects (SumpleBus) and how, despite it possibly being a clone of other packages, it has slightly different goals than other tools, making it a different tool, not just a straight up clone. He also covers some of the package design principles he suggests in his book and how they can help to make an isolated package better. He also points out how recent PHP-FIG efforts to define common interfaces and structures can help reduce this kind of package duplication as well by reducing the possible implementations of any given process.

Code duplication is a common problem for developers. It's easy to copy and paste code around your application, but you're asking for trouble. Unfortunately, this kind of problem also extends to unit tests. In this new post to his site James Fuller looks at one way to help with this - using the @dataProvider to limit the repetitive data sets across tests.

PHPUnit offers a handy annotation called @dataProvider which can be used for all sorts of handy testing situations. Typically you will use this to feed in a wide variety of data into the same test to ensure that the system-under-test can handle a variety of inputs. Over time I have discovered a few other neat uses for dataProvider methods that I want to share with you today.

He provides some code samples showing how to use the dataProvider in a few tests, setting up an "allowed word" example. He gets a bit more complex with another test that takes in multiple parameters to "mix colors". In his last example he shows a data provider that converts names from camelCase to user_scores.

On his "Simple Programmer" blog John Sonmez has a new post looking at three kinds of "code duplication" that you should keep an eye out for when coding your applications:

One of the biggest reasons to refactor code is to eliminate duplication. It is pretty easy to introduce duplication in our code either unintentionally or because we don’t know how to prevent or get rid of it. [...] I’ve found that there are three basic types of duplication that we can eliminate from our code that successfully build on each other.

He describes the three types - data, type and algorithm - and gives some code snippets showing how they present themselves and simple solutions of how to resolve them. There's also a quick mention of a "combined attack" when more than one form of duplication shows up at once. He suggests a to help find the "edges" of the duplication:

I’ve also found the key to eliminating duplication is sometimes to first exaggerate it. Often I will purposely take two methods that I know have some duplication and make them look even more duplicated in order to be able to clearly see where the duplication lies.