I have been searching for a good server monitoring solution for a while so that I can keep an eye on some of the servers that I run. Tools like Smokeping, Cacti and Nagios seemed promising at the outset, but they are more concerned with bandwidth and server status, not how the server is running.

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.

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.

During DrupalCampNW 2012 last November the company we hired to record the sessions also spent some time interviewing the people who attended. From these interviews we were able to create three videos, two from the main event and one about what Drupal means to different people. These videos are now complete so I'm posting them here so everyone can see. I think they came out really well.

I was recently working on a module that contained a content type as a feature. When the module was enabled the hook_install() hook set up a collection of taxonomy terms which were used within the content type as a field. Whilst testing this out I realised that although the terms were installed correctly the default value of the field changed depending on which system the module was installed on. The reason for this was that the term ID was being used to pull out the default term from the database, which is the normal behaviour in Drupal.

I'm just letting all my neurons cool down after a fantastic Drupal Camp at City University, London. These Drupal camps are getting bigger, better, and much more frequent in a really, feely, organic way. They never feel like there is a sponsor driven sales push to use this service or that, moreover, it genuinely does feel like a community of like minded people, groups of people, willingly sharing their knowledge, ideas, and enthusiasm in what it is they are doing, using, or believe in.