In a new post to thePHP.cc blog Sebastian Bergmann talks about Death Star Version constraint and how it could cause issues in your application if your version definitions are too loose.

PHPUnit 6, a new major version of the de-facto standard for testing PHP-based software, was recently released. Soon after, the test suites of developers who did not yet want to upgrade to the new version stopped working. What had happened?

In a nutshell, these PHP developers were caught off guard by the consequences of using the "Death Star" version constraint in their composer.json file, the * operator.

He gives an example where a user may have specified "*" in their composer.json file, leaving it wide open to get whatever the latest version is. He then talks some about semantic versioning and how it should be used in Composer configurations to ensure you're always working with the versions you're expecting. Locking down versions is good, but he also makes a recommendation to "keep dependencies fresh", providing bug fixes, new features and functionality as well as security updates.

On the MyBuilder.com Tech blog they've posted a tutorial from Edd Mann looking at the use of constraint-based ordering in PHP applications.

An interesting problem arose last week when we wished to generate a listing of recently completed jobs (along with their shortlist fees). Upon review of some earlier attempts, we did not like the aesthetics present when many of a particular shortlist fee were clustered together (i.e. two or more adjacent jobs with the same shortlist fee). What we were instead looking for was to create a constraint-based ordering that when applied to the recently completed jobs, would give an even distribution of shortlist fees (data-set permitting).

Initially he tried a "low-high" ordering method based on their "fee" value. Instead, to make the solution more "random" he reframed the need and broke it down into three separate actions: sort, partition and interleave. As PHP only has one of those, he came up with his own solutions for the other two (code included). He explains briefly how it all works together and what kind of benefits it has over the low-high solution originally created.

The Made With Love blog has posted a great introduction to version handling in Composer today. They focus in on two characters that can be confusing if you're not exactly sure what they mean - the carat (^) and tilde (~).

A dependency that uses semantic versioning allows you to predict wether it is still going to work or not when you upgrade it to a new version. Basically when the x in a x.y.z version number changes, you might need to do some changes to be able to work with this new version without problems. [...] Depending on your dependency manager you can define version constraints using wildcards (*), comparators like <=, logical operators (, often means AND and | means OR), etc. [...] There are also some syntactic sugar operators like ~ (tilde) and ^ (caret)

They include some examples of both characters in use defining the required install versions, showing how one allows for approximate matches and the version ranges they apply to.

On the Ibuildings techPortal today they've posted the latest webcast in their "DPCRadio" series as recorded at last year's Dutch PHP Conference. In this latest episode they share David Zuelke's talk Embracing Constraints with CouchDB.

There has been a lot of buzz lately about the NoSQL movement in general and CouchDB in particular. For people who are used to relational databases, a lot of CouchDB's limitations look like severe disadvantages; these constraints however can also be great opportunities. This talk will give an overview of CouchDB and then focus on embracing the system's constraints to build better products.

You can either listen in-page or download the mp3 to get this latest episode. If you'd like to follow along with his slides, you can find them on SlideShare.

New on the ServerGrove blog today is a quick post talking about how you can enforce key constraints on a MongoDb with Doctrine in Symfony.

Of course you can define unique indexes to prevent duplicate values and there are a couple of different syntax options to do so, which are clearly defined in the official documentation. But defining and creating the indexes is not enough. You must specify when you want to enforce the constrain, this is due to the fact that the PHP driver needs to tell MongoDB to throw an error when a duplicate key is found.

The fix is as simple as adding a "safe" option to the "flush()" call on your database object. If you give it a value of "true", the ORM is smart enough to handle things on its own.

In a new post to his blog, Sebastian Bergmann mentions a new effort he's undertaken - the porting of the Hamcrest library of matcher objects to PHP.

I have begun to port Hamcrest, which provides a library of matcher objects (also known as constraints or predicates) allowing "match" rules to be defined declaratively, to be used in other frameworks. Typical scenarios include testing frameworks, mocking libraries and UI validation rules, to PHP.

The hamcrest-php project compliments other current hamcrest-related projects and his ultimate goal is to make it available to the PHPUnit testing community (as well as with the PHPMock effort).

In a new post to his blog, Sebastian Bergmann mentions a new effort he's undertaken - the porting of the Hamcrest library of matcher objects to PHP.

I have begun to port Hamcrest, which provides a library of matcher objects (also known as constraints or predicates) allowing "match" rules to be defined declaratively, to be used in other frameworks. Typical scenarios include testing frameworks, mocking libraries and UI validation rules, to PHP.

The hamcrest-php project compliments other current hamcrest-related projects and his ultimate goal is to make it available to the PHPUnit testing community (as well as with the PHPMock effort).

While attending a code camp for Xenerix, Ivo Jansch decided to challenge himself to create a way to implement Object Constraint Language functionality in PHP objects.

To give a practical example: if you have a class 'Creditcard', you could define the constraints 'self.limit > 0' when withdrawing an amount. While the goal of the code camp was to do some nifty things with OCL and Ruby, I wanted to see if I could create a method to easily implement OCL constraints in arbitrary PHP objects.

He structures his example similar to the one provided, making CreditCard and Person classes with constraints on the person's name, withdrawing past the expire date of the card and the keeping the limit of the card above zero. He created a OCL wrapper class to handle most of the hard work, but he provides the code examples you'll need to see it in action, complete with constraints.

While attending a code camp for Xenerix, Ivo Jansch decided to challenge himself to create a way to implement Object Constraint Language functionality in PHP objects.

To give a practical example: if you have a class 'Creditcard', you could define the constraints 'self.limit > 0' when withdrawing an amount. While the goal of the code camp was to do some nifty things with OCL and Ruby, I wanted to see if I could create a method to easily implement OCL constraints in arbitrary PHP objects.

He structures his example similar to the one provided, making CreditCard and Person classes with constraints on the person's name, withdrawing past the expire date of the card and the keeping the limit of the card above zero. He created a OCL wrapper class to handle most of the hard work, but he provides the code examples you'll need to see it in action, complete with constraints.