Matthew Weier O'Phinney has posted the third article in his "Deploying Zend Server Tips" series today. In this tip he talks about file permissions and execution of shell commands.

In the first tip, I detailed writing deployment scripts. One of the snippets I shared was a chmod routine. [...] The code is fine; what I did not share is where in the deployment script you should invoke it. As I discovered from experience, this is key.

He points out that the deployment is run under a different user than the web server user. Future writes to those files by the web server could fail because of it, so he recommends running the permission change as the last step of the deployment script. If this ti was interesting and you'd like to check out more, you can find them in the first and second parts of the series.

On PHPBuilder.com today they have a new post showing different configuration patterns for getting localized settings into your applications. They show the use of INI files, PHP scripts, text files, XML data and a database call.

PHP is a cross platform language. It is a server based application so we must think about the configuration settings of the PHP software. There are various ways of creating configurable PHP applications. The configuration flexibility comes as a built in feature in PHP. But we must understand the requirement clearly before making an application configurable. This article explores different PHP configuration patterns and their implementation.

For each of the options mentioned, there's a brief description of what the method is, some of the common uses and a code example showing a basic implementation. The database pattern is the only one without a code example as the database interface varies widely from application to application.

Joshua Thijssen has a new post to his site sharing an interesting tool for those using PHPUnit for testing. It's a real-time plugin that executes your tests as soon as something in your files change.

Not all IDEs (actually, i haven’t seen even one IDE that does this), can run your unit-tests as soon as something changes. Inspired by Greg Young’s Mighty Moose system, the following script runs inside a shell, will wait for changes in your PHP-files, and runs the corresponding unit-test as soon as something changes. It doesn’t run the WHOLE unit-tests suite, but merely the test that matches up the source file.

His tool, found here on Github and uses a simple bash script that uses the file name being saved to locate the matching test and execute it, reporting back any errors that might have popped up. This could easily be hooked into most IDEs out there and keep the developer in one place.

My current project does periodic releases, we build a few things, then we work on getting a bunch of user feedback and changing/fixing things before we actually release. [...] When a branch merges in to the main line, we use the "fixes #42" notation to simultaneously close off the issue that it relates to. This has been working pretty well, and today I got the question "what's new since I last saw this project?" - so I created a changelog. It's rather rough-and-ready but I had fun so I thought I'd share.

The script operates off of a local git cloned version of the repository and grabs all commit messages with the tern "fixes" in it. The script then takes the log file, matches the issue ID and then makes a cur call out to the GitHub API to get that issue's description. This is then taken, formatted and dropped into the output.

Kevin van Zonneveld has a new post that, while not PHP specific, does have a handy script that will help you stop committing broken code.

Whatever the reason, it's almost 2014 and we are still committing broken code. This needs to stop because best case: Travis or Jenkins prevent those errors from hitting production and it's frustrating to go back and revert/redo that stuff. A waste of your time and state of mind, you were already working on other things. Worst case: your error goes unnoticed and hits production.

To help resolve the problem, he suggests using the "hook" system common to most version control software. In his specific example, he shows the use of a pre-commit hook that fires off a bash script on the files being committed. He includes the full code for this bash script that includes a check for PHP scripts using the built in PHP linter (the "-l" option on the command line). He also includes the commands and updates you'll need to make to get it installed on git.

Rob Aley pointed me towards a new ebook he's created that wants to help you understand what kinds of things PHP can do "beyond the web" and the usual web-based applications - PHP Beyond the Web.

Leverage your existing web based PHP skills to write all types of software. CLI scripts, desktop software, network servers and more - this book will give you the tools, techniques and background necessary to write just about any type of software you can think of, using the PHP you know.

The book covers topics like interactive shell scripts, system daemons and desktop software. It also looks at some more general development topics like licensing, deployment and system interactions. If this sounds interesting and you want a sample of the content, check out the table of contents or the sample chapter.

On Reddit.com there's a new post from someone relatively new to PHP wondering what the relevance of benchmarks is in a time when most performant sites use caching (full page or data) to increase their speed.

I was speaking to another PHP developer today who is a lot smarter than me. I was curious about Static Site Generators taking over the future of the web. [He] told me that most of the time, big sites have a cache that people hit. So people don't even have to wait for PHP to be interpreted. This begs the question . . . How are performance metrics relevant for different frameworks, when these sites are being cached anyway?

"Most of the benchmarks you'll see are dishonest and/or skewed as they don't paint an accurate picture of what's going on, or how they would be used in the real world."

"As soon as you start taking too much time to return a page to a user you have a knock-on effect where you develop a queue of other users waiting for their page to be returned as well."

"So far as performance benchmarks go, the framework and language used in your application becomes redundant once you add a caching layer as the page performance is then limited by what caching layer you use."

"as a rule of thumb "logged out users see cached content" "logged in users see uncached content""

On the Etsy "Code as Craft" blog there's a recent post about their move to using the GeoNames service internally rather than the external, third-party API previously in use.

People are passionate about where they live. At Etsy we need to keep track of lots of different locations, such as buyers’ billing and shipping addresses and sellers’ shop locations. As Etsy continues to expand internationally we wanted to provide better localization and translations for our location place names. We determined that the best way to effect this change was to move from using a closed location API provider to internal services backed by the open GeoNames data set.

The post details some of the steps in the process including the mapping of the current data to the new structure (the script is available on github). They talk about how they mapped their old data over (trial and error sometimes) and the creation of a database of "GeoNameIDs" for each customer in their records. They've also implemented a Lucene/Solr search for improved searching and auto-suggestion based on the user's location.

If you're a PHP developer and have been looking for a good way to manage 3rd party dependencies in your applications, look no further than Composer. If you're already using it, you know how useful it can be, but you might not know about some of the extra features that come with it. In this new tutorial on PHPMaster.com, they describe the automation that is also possible as a part of Composer's management process.

Following Alexander Cogneau’s introduction to dependency management with Composer, you now know that Composer is a resolver for managing external project dependencies and versioning constraints. But is that all it does? In this article I’ll show you how Composer can also be used as a basic build automation tool.

Thanks to some handy configuration settings available in the "composer.json" file, you can execute scripts for events like "pre-install", "post-update" and "pre-uninstall". They include an example "Installer" class with methods for a few of the actions, showing some of the special methods you can use to get metadata about the current operation and environment.

Derick Rethans has a new post today looking at a method for setting up multiple PHP versions on the same machine and switch between them with a little help from some simple bash scripts.

For many of my projects (both hobby and commercial) I need to support many different PHP configurations. Not only just different PHP versions, but also debug builds, ZTS builds and 32-bit builds. In order to be able to test and build extensions against all those different PHP configurations I have adopted a simple method that I'm sharing with you here.

Using this script he can tell his system to pull the latest version of any release from SVN and try to compile it. The trick is putting each of them into a different directory under /usr/local. He uses another small shell function (with a function called "pe()") that sets up the pathing to the right release, complete with its own locations for PEAR/PECL and a php.ini.