The Monty Hall problem is a counter intuitive problem in probability mathematics that deals with picking the right prize from a set of three doors. The problem is named after the television celebrity Monty Hall and is loosely based on the USA game show Let's Make a Deal.

This has become a popular problem in programming as it is a good exercise in thinking through a problem to prove what outcome actually occurs. Lots of examples have been posted online so I thought I would sit down and attempt to solve it myself. The problem is most commonly summarised as follows (this example was taken from Rosetta Code):

The WYSIWYG module in Drupal is a great way of integrating a client side HTML editor (better known as a WYSIWYG editor) into a Drupal site. It supports a variety of different editors, all of which can be configured depending on the input format being used by the user. The ability to incorporate many different content editors into a site using a single module means that the configuration interface for them all is pretty much the same. It also means that it isn't a disaster if a different editor is needed for an existing site. You just need to ensure that the correct configuration options are set to allow a similar user experience.

Running complex tasks in Phing can mean running out of memory, especially when altering or changing lots of files. I was recently working on a image sorting Phing project that sorted images based on EXIF information. The many thousands of files involved, along with the custom target used to extract the EXIF data caused the default avai

lable memory to run out quite quickly.

There is no direct way to alter the PHP memory limit setting through Phing, but it can easily be altered using a Phing php task. This evaluates the PHP function ini_set() and set the memory_limit value. The following Phing task sets this limit to be 1G, or 1 gigabyte.

Context is a Drupal module that allows you to set up reactions that fire when certain conditions are met. This might be when a certain path is loaded, or when a particular content type page is viewed, or even on every page on a site. When the conditions are met a number of reactions can be fired, which include placing blocks, setting breadcrumbs, or just adding a class to the page template.

When you first install a Munin node it will try to install as many plugins as it can so that it can report on different things. For example, if you have a Varnish server running then Munin will detect this and enable the plugins so that it can report on the activity of Varnish. Once you have started getting data through to your Munin server then you can turn on plugins on the nodes to get more data.

The data of any plugin is presented in a standard format and so is understood by the Munin server. Perhaps the most important plugin for my work is the Apache status plugin that shows what is going on inside Apache. This plugin isn't always installed with the Munin node and so you might have to do this yourself. This is a good way of getting familiar with Munin plugins.

When Munin does a data update it stores all of the data from the nodes as a set of rrd files. These files are then picked up by the munin-graph and munin-html programs and turned into the graph images and web pages that you are probably familiar with if you use Munin.

The default location for Munin to store these data files is within the directory /var/lib/munin. Each group you define in your config is given it's own sub directory and the rrd data files for all servers within each group are kept within that directory. If you kept the default Munin config file you will probably have a directory called localhost which will contain all of the rrd files for your Munin server.

The sieve of Eratosthenes is named after Eratosthenes of Cyrene who was a Greek mathematician who devised a mechanism to find a sequence of prime numbers using a simple algorithm.

Normally, looping through a list of numbers and finding the primes can be an expensive process. The seive of Eratosthenes is one of the most efficient way of working out all of the smaller prime numbers below (below 10 million or so).

The sieve works by looping through a list of consecutive numbers, starting at 2. For each number in the sequence the multiples of that number are marked to be removed from the list of numbers. When finished the numbers that are not marked are prime numbers.

This algorithm is pretty straightforward, but from that it is possible to create a simple PHP function that will generate all the prime numbers up to a given number.

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.