Sean Coates has posted a reminder for PHP developers (and really anyone executing command-line scripts) to use "env" instead of hard-coding the path to the PHP interpreter.

These [support] scripts often run PHP in Gimme Bar land, and we make extensive use of the shebang syntax that uses common Unix practice of putting #!/path/to/interpreter at the beginning of our command-line code. Clearly, this is nothing special -lots of people do exactly this same thing with PHP scripts. One thing I have noticed, though, is that many developers of PHP scripts are not aware of the common Unix(y) environment helper, env.

The "env" alias makes use of your currently defined include path to track down a PHP binary to use to execute the script. Since there's only a "best practices" approach to places to put PHP on a server, the "env" usage makes your script more portable and it's one less thing to remember to change.

If you distribute a PHP application that has command-line scripts and shebang lines, I encourage you to adopt the practice of making your shebang line "#!/usr/bin/env php". Note that this doesn't just apply to PHP of course, but I've seen a definite lack of env in the PHP world.

On DZone.com there's a new post from Giorgio Sironi about using Composer to install packages/libraries:

The main package source used by Composer seems more similar to the usage of git submodules at a first glance: a list of dependencies on other projects is specified and stored under version control, and upon a checkout these projects are grabbed directly from their repositories.

He talks about what problem the project solves, what issues he's found with it so far (the amount of stuff downloaded for each dependency, the single point of failure of the one Packagist repository) and shows how to get it installed and creating a sample "composer.json" file for an example project.

In this new post Gonzalo Ayuso talks about "using eval without using eval" in PHP applications - executing PHP code without having to use the eval function to do it.

Yes I know. Eval() is evil. If our answer is to use eval() function, we are probably asking the wrong question. When we see an eval() function all our coding smell's red lights start flashing inside our mind. Definitely it's a bad practice. But last week I was thinking about it. How can I eval raw PHP code without using the eval function, and I will show you my outcomes.

He includes some sample code showing a basic script with a class and a loop executing normally, then an "eval version" that puts it all in a string and executes it. He offers a different method - not an ideal one since it requires being able to write to the local file system, but prevents the need for eval - writing the PHP code to a temporary file and using a "fake eval" to pull it in.

Stuart Herbert has his latest post in his "PHP Components" series on his blog today - a recommendation to include unit tests along with the release of you component.

I'm now going under the bonnet of our components, and looking at the different file roles that the PEAR installer expects to find when we distribute our component as a PEAR-compatible package. One of the most important file roles allows you to ship your tests with your package - and it's vital that this is something that you get in the habit of doing routinely.

He recommends "testing your code and shipping your tests" along with the component(s) you're releasing. Not only does it help you create a better quality end result but also makes it simpler for other developers to make changes and know they're not breaking things. He describes unit tests for those not familiar and includes a specific example of the CommandLineLibrary and its related tests.

On the PHP on Windows blog from DZone.com Krzysztof Kotowicz has a new post - part one in a series on securing your PHP application - a look at securely including remote code from a source outside of your application.

First post of the series discussing various methods of including remote PHP code in your application - from security standpoint. In this post we discuss the history of remote code execution vulnerabilities in PHP apps and ways to prevent them. We finish off by presenting an unsecure method of including a remote code and describe what is the problem with that method.

He looks at the insecurity of a standard include/require, the allow_url_include php.ini setting and the issues with using hardcoded locations (like incorrect DNS records pointing to the wrong host).

Paul Jones has a new post to his blog looking at two approaches to building applications in PHP - either using an include-based of class-based architecture, briefly looking at the advantages and disadvantages of each.

This is a topic I describe at length in my Organizing [Your PHP Projects] talk, but I would like to give the idea a home on my blog for easy reference.

He talks about the typical structure of a PHP application - at least where most start out - being the "include" method. He talks about the progression it usually makes into functions and classes and then, eventually, a jump in concept to the "class" method similar to what several popular frameworks have gone with.

The difference is that no program logic is executed at loading time with a class file. Loading the class file makes it available for use, but the programmer has to instantiate it and then call methods on it for anything else to happen.

From the SeeIT.org blog today there's a new post rehashing an old topic that pops up from time to time in the PHP community - the include vs include_once performance debate.

The conventional wisdom always said that PHP's include()/require() was quicker than include_once()/require_once(), but recently I came across an interesting post by Arin Sarkissian which suggests otherwise. [...] So in keeping with the spirit of quick and dirty experimentation I hacked up some code and ran some tests on include()/require() against include_once()/require_once() and on the relative/absolute path issue. The results are pretty surprising and I love to hear some views.

He includes the testing methodology consisted of creating 10,000 files with a simple variable assignment in them and a loop to run through all of them to record the time (as reported by microtime) switching out the different times of inclusion each time - include, include_once, require, require_once. You'll have to visit the post yourself to see the results of the tests. There's charts and tables showing the differences in results based on things like using APC and PHP4 versus PHP5.

DevShed continues their "loaders in applications" series with this fourth part, a look at including files recursively.

This series uses a variety of code samples to teach you how to create modular programs. These programs are capable of recursively including files required by a given application, without having to explicitly call any "include()/include_once()" or "require()/require_once()" PHP function.

In their example they show how to use their loader class (built up from previous parts of the series) and modify it slightly to allow the script to set the file path, set the files to include and pull them in.

In this first part of a new series in application development, DevShed looks at building a loader for various resources inside your app.

Loading sources on the fly is one of the most common tasks that PHP programmers have to tackle during the development of web applications. This typical situation must be faced independently of the scale of the programs being created. This means a loader mechanism must be developed.

Their basic loader class uses a call to a load() method to do two things - check to ensure that a file exists and, if it does, include it (technically a require_once). They also put a bit of exception handling around it to help catch any errors thrown on the include.

Debugging resources being used by your script has always been a pain, and many developers have come up with their own libraries to handle the process. Ryan Campbell has his own entry in the category - the PHP Quick Profiler.

In our company, code reviews play an integral part in the development process for making quality software. We opt for a mentor style approach with Wufoo, where a developer works on a segment for a period of time and then passes it up to a more experienced developer for review.

[...] To reduce this repetition of checking the same requirements over and over], we invested some time creating something we've called the PHP Quick Profiler-we call it PQP for short. It's a small tool (think Firebug for PHP) to provide profiling and debugging related information to developers without needing them to add a lot of programmatic overhead to their code.

The post gives several screenshots of the tool in action and code to get you up and running quickly. The Profiler can keep track of memory usage, "runaway" includes, execution time and database activity. There's also an online demo so you can try it out yourself.

Here's the link to the latest version's download.