PHP

Providing a Phing build file along with a project is a good way of allowing automation of certain aspects of the project. The only trouble is that users won't know what's in the build file unless they open it or just run it. You could provide documentation along with the build file so that users know what to use the file for, but a better approach is to list out the targets available in a project. This can be done easily by using the -l (lower case L) or list flag, which will just list the available targets in the supplied build file.

Running this on a build file will produce this sort of output from a build file with two targets, one of which is run as a default.

Phing has a few different tasks and elements that allow you to select paths of code execution depending on what you need to happen in a build file. These are limited to loops and if statements, but a lot of functionality can be covered with just a couple of lines of XML.

The other day I was experimenting with Git hooks. These are scripts that you can execute before certain actions are run in Git. For example, you might want to ensure that forced updates are not run, ensuring respository files have the correct permissions after merging, or that the files have ASCII standard names before being committed.

To use a hook in Git you just need to add them to the .git/hooks directory in your respository and to change the mode of the file so that it is executable. A new Git repository will create several sample hook files that can be used by removing the '.sample' from the end and making them executable. For more information on Git hooks and how to use them see the Git hooks manual page in the Git documentation.

I use Phing for a lot of different tasks, it helps me to automate things that I would otherwise mess up if left to my own devices. Prime candidates for Phing scripts are things that I don't do that much and forget how to do them, or that have a number of complex steps. The only problem I have found is that because many of the Phing scripts I create rely on system changes (eg, configuring an Apache server) they therefore require system changing privileges. Normally I would just prefix the Phing command with sudo, but every now and then I forget all about that step and the build fails. This can be dangerous as I am then left with a build that failed, which might leave a system partly configured or even take a server offline.

Getting the first or last item from an array in PHP is usually quite easy. If you create an array and then add a bunch of values to it then the array index will increment by 1 for every element you add. This means that in order to get the first element from an array you just reference the default starting position (0). To get the last item in the array the index key will be the length of the array, minus 1. Here is some example code showing this.

<?php
$array = array();
$array[] = 1;
$array[] = 2;

// get the first item in the array
print $array[0]; // prints 1

// get the last item in the array
print $array[count($array) - 1]; // prints 2

Things become slightly more complicated when the array has non standard key values. Take the following array for example in which the array count it started at 1.

I recently have started looking into making myself a PHP Zend Certified Engineer and after doing a bit of research I found that the standard PHP string and array functions appear to be a large part of the exam material. So as a starting point (and for future revision) I decided it might be a good idea to create a revision sheet for those functions.

The DateTime classes in PHP have been available since version 5.2, but I have largely ignored them until recently. This was partly due to the fact that I was working in PHP 5.1 environments a lot (don't ask) but mostly because I was just used to using the standard date functions that have always been a part of PHP (well, since version 4). I wanted to explain why I will be using the new DateTime classes more from now on and why you shouldn't be hesitant to use them.

Using a combination of strtotime() and date() can handle most things and is a good method to quickly grab a date.

XDebug is a great PHP debugging tool, but it also comes with a very useful profiler that can tell you all sorts of information about your PHP application. This includes things like memory footprint and CPU load but will also have detailed information about the entire callstack of the code that was run. To enable the profiler part of XDebug you just need to set up a few rules in your xdebug.ini file.

I have started to use virtual machines to develop sites rather than installing a local web server. This allows me to replicate the exact setup of the server I will be deploying to with ease. For each virtual machine I set up a shared folder which allows me to store the files locally whilst being able to run the code on the virtual machine. One thing I missed was the ability to use xdebug to debug the sites through Netbeans, so I set about trying to set up the virtual hosts to allow me to use xdebug remotely.

All that is needed was to add a xdebug.remote_connect_back clause to the xdebug.ini file found in the PHP configuration. Set this value to 1 to automatically connect back to any xdebug session that is created on the server.

I have talked before about running Selenium tests in PHPUnit but I have only recently come to properly automate things. Getting a Selenium server to start and stop in a script is relatively easy and can be done in a simple script. My original script for running a directory of PHPUnit tests was as follows. I will explain more about how this all works later on in this post.