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. What I really needed was a way to find out how much memory a server was using, how many Apache requests were being made, what the average load of the server was, and also some way of letting me know when things were under strain.
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.
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 would also like to thank Drupal Association, who very generously financed the creation and production of these videos.
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. The problem here was that if a term the ID of the term was different (because one had been added) then this had a knock-on effect of changing the default value of the field.
To get around this I needed a way of setting the default value of the field based on a given taxonomy term. After some research and reading of the Drupal source code I found a way to programatically set the default value of a taxonomy field.
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.
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.
Alternative PHP Cache (APC) is an opcode and variable cache for PHP. When you run a PHP script it is first compiled into a series of opcodes which are then used by the Zend engine to run the program before being discarded. APC sits between the source files and the Zend engine and will stop the opcodes generated during the PHP script execution being thrown away. This means that when you run a PHP script a second time the work done in generating the opcodes has already been done and the script will execute faster. In fact, the opcode cache alone can substantially increase the speed of PHP execution and provides an 'easy win' when improving the speed of a PHP website. Having APC for a complex system like Drupal means that you will see a substantial increase in performance, so it is well worth having.
There are several methods to install APC, but the easiest is to use apt-get (or similar package manager).
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.
Ever sat there and pondered which browsers support what css styles? If so I’d like to quickly introduce http://www.caniuse.com. This is a great tool and sometimes the quickest way to find answers to your questions. But what about W3Schools; I hear you say. W3Schools does have a comprehensive list of styles, complete with examples of how to use them and a list of properties that you can use. However, what I find W3Schools fails on is a comprehensive outline of browser support.
caniuse.com provides you with a fool-proof table of browser support. It also outlines support for mobile browsers. Possibly one of the quieter features of caniuse.com is the ‘Known Issues’ tab underneath the table. So, ever tried to get rounded corners to work on a table with a background colour on the table header cells? These known issues can help you quickly debug your css.