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 a new post to the test.icial.ly blog today Christian looks at interfaces in PHP and why they seem to be ignored in a lot of the development work being done.

Every once in a while I stumble upon interfaces or somebody mentions them to me. Whenever this happens I realise that the use of Interfaces as an OOP key feature in PHP is next to none at all. But why is that?

They note that, while interfaces are used all over projects in other languages, it seems like PHP development has steered away from their use. They define normal interfaces and abstract interfaces for those that don't know and talk about the differences between them. He also includes a brief code sample with description of its use and a bit about interfaces and frameworks.

Marco Tabini has posted his list of what he considers five features of PHP5 that you "can't afford to ignore" when doing your development work:

Despite the fact that you may not have a choice in the matter, upgrading comes with a number of bonus new features that can help you write better code and gain access to new functionality that required a fair amount of hacking in previous version. Here's a quick list of 5 personal favourites.

The feature to make his list are SimpleXML, JSON/SOAP, PDO, the Standard PHP Library and SQLite. Each has their own bonus feature(s) included too for a little extra incentive to check them out.

On the SpinDrop blog, Dave Dash has a few hints on using the combination of Symfony and Subversion to make working with a project easier.

He breaks it into four different sections:

• Ignoring files in cache/ and log/
• Ignore other auto-generated files
• Linking the symfony Library
• Linking to symfony Plugins

Each comes with its own snippet of code/configuration directives to help you set it up. Check out the comments for a slightly different example from another reader.

On the SpinDrop blog, Dave Dash has a few hints on using the combination of Symfony and Subversion to make working with a project easier.

He breaks it into four different sections:

• Ignoring files in cache/ and log/
• Ignore other auto-generated files
• Linking the symfony Library
• Linking to symfony Plugins

Each comes with its own snippet of code/configuration directives to help you set it up. Check out the comments for a slightly different example from another reader.

In an effort to keep track of some of the lesser seen patches to the core of PHP, the Zend Developer Zone has started a weekly summary that talks about the PAT directory:

The PAT directory contains patches (fixes and improvements for the C source code behind PHP) that have been sent to the internal developers' mailing list by members of the wider PHP community. The mailing list is fairly busy - as are the developers - and patches aren't always noticed by someone able to review and perhaps apply them; this can lead to people repeatedly mailing the same patch to the list in the belief that they're being ignored!

The idea behind the posts is to provide a listing of those patches for those looking for them (including the PHP dev team) until they've been evaluated and moved out of the PAT directory purgatory.

In an effort to keep track of some of the lesser seen patches to the core of PHP, the Zend Developer Zone has started a weekly summary that talks about the PAT directory:

The PAT directory contains patches (fixes and improvements for the C source code behind PHP) that have been sent to the internal developers' mailing list by members of the wider PHP community. The mailing list is fairly busy - as are the developers - and patches aren't always noticed by someone able to review and perhaps apply them; this can lead to people repeatedly mailing the same patch to the list in the belief that they're being ignored!

The idea behind the posts is to provide a listing of those patches for those looking for them (including the PHP dev team) until they've been evaluated and moved out of the PAT directory purgatory.

Lukas Smith, following up on a previous post on his perspectives on the openess of the Zend/Eclipse IDE development process. It seems that he's not the only one that's wondering - there've been other posts to the Eclipse boards that have been either ignored or treated with no respect.

After publishing my initial post where I question if the proposal process meets my definition of the open source process I had several people on IRC querying me and saying that they very much agree. However when I indicated that Zend needs to know about this too, so that they can better understand the importance to the community people did not seem to follow through. What exactly are people scared about?

While I may not agree with Zend on this, they have been receptive when people brought issues to their attention. Although it sometimes took a blog post (scroll down to "I'm Spartacus") with a number of comments to make them realize that they need to fix their priorities (scroll to "A Change in Policy").

It's a shame to see the people at Zend not taking notice of something like this until there's already a large amount of community involvement behind it. Sure, it's worked alright so far, ususally with the wanted changes being made, but if they keep that up, it's going to come back around and get them in the end.

Lukas Smith, following up on a previous post on his perspectives on the openess of the Zend/Eclipse IDE development process. It seems that he's not the only one that's wondering - there've been other posts to the Eclipse boards that have been either ignored or treated with no respect.

After publishing my initial post where I question if the proposal process meets my definition of the open source process I had several people on IRC querying me and saying that they very much agree. However when I indicated that Zend needs to know about this too, so that they can better understand the importance to the community people did not seem to follow through. What exactly are people scared about?

While I may not agree with Zend on this, they have been receptive when people brought issues to their attention. Although it sometimes took a blog post (scroll down to "I'm Spartacus") with a number of comments to make them realize that they need to fix their priorities (scroll to "A Change in Policy").

It's a shame to see the people at Zend not taking notice of something like this until there's already a large amount of community involvement behind it. Sure, it's worked alright so far, ususally with the wanted changes being made, but if they keep that up, it's going to come back around and get them in the end.