PHPDeveloper.orghttp://www.phpdeveloper.org
Up-to-the Minute PHP News, views and communityen-usTue, 03 Mar 2015 14:34:08 -060030http://www.phpdeveloper.org/news/21981http://www.phpdeveloper.org/news/21981
In a new post to his site Mattias Nobackmakes 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.

Link: http://php-and-symfony.matthiasnoback.nl/2014/11/packages-the-case-for-clones/]]>Mon, 17 Nov 2014 11:55:21 -0600http://www.phpdeveloper.org/news/20724http://www.phpdeveloper.org/news/20724
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.

Link: http://www.jblotus.com/2014/01/29/use-dataprovider-to-reduce-duplication-and-improve-the-maintainability-of-your-tests/]]>Fri, 31 Jan 2014 12:50:39 -0600http://www.phpdeveloper.org/news/18019http://www.phpdeveloper.org/news/18019
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.