For those Sculpin users out there Matthias Noback has posted a tip showing how to make the tool skip certain sources so it's not included in the build. This is useful for removing files that may not be needed in the final result. In his case, he wanted to slim down his Docker image and only include exactly what was needed for the site it hosts.

Whenever I run the Sculpin generate command to generate a new version of the static website that is this blog, I notice there are a lot of useless files that get copied from the project's source/ directory to the project's output/ directory. All the files in the output/ directory will eventually get copied into a Docker image based on nginx (see also my blog series on Containerizing a static website with Docker). And since I'm on a hotel wifi now, I realized that now was the time to shave off any unnecessary weight from this Docker image.

After some searching around he found the best solution for his needs - a custom hook into Sculpin's own events system with a "before run" event. He includes the code he used to create a SkipSources event that uses pattern matches to exclude the requested sources. Then, using the fnmatch function he generated a listing of files to pass in to be skipped. After working up this solution, a bit more research also lead to another possible, more built-in way: the ignore configuration key that also uses pattern matching.

In this post to his site Matt Stauffer walks you through how he created a custom @requires annotation to use in his PHPUnit testing. He needed a way to tell a test to only run if it wasn't being executed on the Travis CI service.

I was working on a project this weekend that required skipping certain tests in a particular environment (Travis CI). [...] I remembered that there was a @requires annotation in PHPUnit that works natively to allow you to skip a test under a certain version of PHP or with certain extensions disabled, so I set out to write my own custom @requires block.

He links to an article that helped him get most of the functionality in place but decided to restructure it a bit to make the override of the checkRequirements method a bit clearer. He ends up using the Laravel Collection functionality instead of a basic foreach reducing it down to a closure that looks for an environment variable called TRAVIS and automatically mark the test as skipped.

On the BitExpert blog there's a post that shows you how to use the pdepend tool on PHP7, an automated tool that shows you the "quality of your design in the terms of extensibility, reusability and maintainability".

Being a good citizen of the PHP community we do test out internal libs against the current PHP7 codebase. So far we had no issues but then at one day one of our Jenkins PHP7 jobs failed. After investigating a bit it turned out that the problem was not part of our codebase but part of of pdepend. The pdepend process died with the error message that "T_CHARACTER and T_BAD_CHARACTER are no longer defined" which is true. The error was already reported as an issue on Github.

Unfortunately, as the problem here is a change to the core PHP language itself, there's not much of a workaround other than to just not run those certain jobs. He outlines how they handle detecting the tests that have problems, but only when run on PHP7. This allows them to run all of the tests and allow the automated system do to its work. When/if the problem is fixed in pdepend, all that's needed is to remove this one check and they're good to go.

On the Codeception blog there's a new post that advocates getting on the testing ship even if the project you're currently on isn't using tests (or TDD).

In this blogpost we will try to figure out how to get faster into the testing. What tests to write at first? Let's say we already have a project and we didn't practice TDD/BDD developing it. Should we ignore testing at all? Definitely no. So where should we start then?

They suggest a three-tiered pyramid approach - UI at the top, Integration testing in the middle and Unit testing as the foundation. They talk about the times when testing doesn't make sense, like when your application is based on a third-party tool (like WordPress or Drupal). They recommend starting with functional testing and working your way back down, especially if your framework supports it. Obviously they encourage the use of Codeception for it, but also recommend even something like Selenium tests if nothing else.

In this new post to PHPMaster.com today Ahmed Shreef continues on from his previous introduction to MongoDB and gets into more detail on things like cursors, query operators, queries on embedded documents and the sort/skip methods.

In my previous article Introduction to MongoDB I discussed installing Mongo, its PHP extension, and how to perform simple insert and find operations. Of course there are many, many more features than what I mentioned so I wanted to write another article to show you some of them.

Other topics mentioned include queries on arrays of data and running queries with indexes to improve their performance. Code is also included for each example.