Controllers aren’t meant to override the __construct() method in ZF – sure you can do it, but there are meant to be better ways. That leads to the question: how? Well, if you do have a look at the __construct() method of Zend_Controller_Action, you’ll notice that it takes three parameters. The last one is the interesting one here: it’s an array called invokeArgs. This should immediately set you off testing what gets passed in – a bunch of goodies, it turns out. Among other things, you’ll be getting a copy of the Bootstrap object.

ZF Controller Dependency Injection, #1

The above leads to the first, not too good way of injecting things. Just stick whatever you want injected into the bootstrap object – your controller has access to that through the invokeArgs parameter. That’s not a very good solution though, as you’ll be breaking the Law of Demeter: your controller needs to know that your injected param sits inside the bootstrap element, so you’ll be accessing the injected elemented indirectly. Not nice.

ZF Controller Dependency Injection, #2

I googled a bit and came across Dependency Injection and Zend Framework Controllers, which has a nice solution to the problem. As the param name suggests, invokeArgs can be modified – you can add to the args to your heart’s content. You need to use the setParam() method of Zend_Controller_Front – so, in the bootstrap object for instance, you can do the following:

$front = Zend_Controller_Front::getInstance();
$front->setParam('factory', new MyFactory);

Your object will then get passed to the controller in the invokeArgs array. You can access this either through $this->_invokeArgs['factory'] or the getInvokeArg() method of Zend_Controller_Action – the latter being preferable.

Series: Sorting Algorithms

1. Sorting algorithms: bubblesort
2. Sorting algorithms: quick update
3. Sorting algorithms: Insertion Sort
4. Sorting algorithms: Shell sort
5. Sorting algorithms: Selection sort
6. Sorting algorithms: Merge sort
7. Sorting algorithms: Heap sort

It’s been a while since I did the last post (merge sort) in my sorting algorithms in PHP series (new readers start with Sorting algorithms: bubblesort) so I thought it about time that I add the next part. This time I’m going for heap sort. This algorithm has some similarities with merge sort, mainly the recursive nature, the divide and conquer idea: heap sort treats an array like a tree of elements instead of just one big pool of elements. Other than that, like some of the other sort algorithms presented it can be sorted in place, leading to less memory use – however it is not a stable sort, as the elements can quite easily change order.

In details, heap sort works by imposing a hierarchical tree structure on the set of elements and that the structure satisfies the heap requirement: that any given node be of equal to or less value than it’s parent. This is actually only a requirement for one type of heaps, the max-heaps – the other type, min-heaps, work in the opposite way, namely by having a parent node be always equal to or less than a child node. The reason this is significant is that you will always know which element is the largest: it’s the root node (in a max-heap, still). Hence, if we have a heap in proper order, we can then take the root node out of the heap and put it at the end of the array to sort. After bringing the heap in order again, we can repeat this, popping off the next largest element and putting it at the second to last position in the array.

Laying it out in steps, it looks like:

1. heapify array
2. pop root element off and store at end of array
3. heapify remaining heap
4. repeat step 2-3 while constantly moving one step back when storing popped element

And that’s it! Well, it obviously gets a bit harder once you get into the details – and without those, no sorting :) As with merge sort, it’s the recursive function that’s most important to the algorithm: the heapify thing. This is where the time will be spent so this is where it’s most important that things are optimized and that the algorithm works out.

So how does the heapify function work? It’s rather simple: it compares a node with it’s two leaves and if one of the is (or both are) larger than the root a swap is made – the largest leaf takes the place of the root node and vice versa. Because of the hierarchical structure of the heap, every node can have at most two leaves. If a swap is made, the heapify function recursively calls itself with the index of the swapped out leaf (the previous root, now a leaf) because this may now be a new root node in another local heap which then has to be checked. If on the other hand a swap is not made the heapify function simply returns: the heap is in order.

In terms of sorting, this means that you first heapify the array once and then of course once per element you pop off the array. As the algorithm swaps out the root node (the one to be popped off the heap) with the last leaf in the array the heapify function then has to be called to get the heap back into shape. Because the last element of the heap is smaller than any of it’s ancestors, the heapify function will recursively call itself a maximum of log₂(n)-1 times. As the heap grows smaller, the number of recursions drops but this obviously happens on a log₂ scale as well so this is not a major factor in the speed – the biggest speed factor lies in a combination of the fact that sorting a heap when a new root is introduced, given that the heap has previously been heapified, only takes log₂(n) moves and that the first heapification of an array is quite fast too.

Enough talk, now code.

The Code

<?php
class HeapSort extends BaseSort
{
    public function sortFunction()
    {
        $array = $this->store;
        $heap_length = count($array);
        $this->buildHeap($array, $heap_length);
        while ($heap_length)
        {
            $temp = $array[0];
            $array[0] = $array[$heap_length - 1];
            $array[$heap_length - 1] = $temp;
            $heap_length--;
            $this->heapify($array, 1, $heap_length);
        }
        $this->store = $array;
    }
    private function buildHeap(&$array, $heap_length)
    {
        for ($i = floor($heap_length / 2); $i > 0; $i--)
        {
            $this->heapify($array, $i, $heap_length);
        }
    }
    private function heapify(&$array, $index, $heap_length)
    {
        $largest = $index;
        $comp = $array[$largest-1];
        $r = $index << 1;
        $l = $r++;
        if (($l <= $heap_length) && ($array[$l-1] > $comp))
        {
            $largest = $l;
            $comp = $array[$l-1];
        }
        if (($r <= $heap_length) && ($array[$r-1] > $comp))
        {
            $largest = $r;
            $comp = $array[$r-1];
        }
        if ($largest != $index)
        {
            $temp = $array[$index-1];
            $array[$index-1] = $comp;
            $array[$largest-1] = $temp;
            $this->heapify($array, $largest, $heap_length);
        }
    }
}

Quick walkthrough: first, the heap is built (or rather, the array is treated like a heap that’s out of order) after which the main loop is entered. Here, with each iteration, the root node is popped of the array (shifted, in PHP terms) and the heap is heapified again. The main action takes part in the heapify() method: it’s called with the heap, the index of the node to heapify and the length of the heap. The method checks the indexed node against it’s leaves and if any of them are larger than it a swap is made and the method is called recursively.

I’ve experimented a bit with optimizing the code and the version above is the fastest I’ve got it to. The biggest payoffs came from passing the array by reference instead of using a property of the class as well as passing the array length into functions – I hadn’t expected either to be a speed improvement but going that way shaved off 5 (five) seconds of the running time when sorting 100,000 elements. Which, I guess, leads me to the results.

Results

1000 elements to sort.
Sanity check. PHP native sort() algorithm took: 0.000878 seconds. Memory used: 64360 bytes
Running Heapsort sort. Algorithm took: 0.089941 seconds. Memory used: 64360 bytes

At 1,000 elements the algorithm it’s running in about 1.25 times the time of the merge sort implementation I made.

10000 elements to sort.
Sanity check. PHP native sort() algorithm took: 0.012138 seconds. Memory used: 665804 bytes
Running Heapsort sort. Algorithm took: 1.208370 seconds. Memory used: 665800 bytes

At 10,000 elements it’s running in 1.5 times the merge sort – pretty good but not quite the same.

100000 elements to sort.
Sanity check. PHP native sort() algorithm took: 0.222491 seconds. Memory used: 6524576 bytes
Running Heapsort sort. Algorithm took: 14.997653 seconds. Memory used: 6524560 bytes

With 100,000 elements the pattern is fairly clear in terms of how the algorithm is doing – a bit less than a straight O(n log n). Final test is 1,000,000 elements.

1000000 elements to sort.
Sanity check. PHP native sort() algorithm took: 3.602368 seconds. Memory used: 64194572 bytes
Running Heapsort sort. Algorithm took: 188.843620 seconds. Memory used: 64194576 bytes

Increasing the number of elements to sort by an order of magnitude increases the run time by 12.5 – which is pretty good (compare to the internal PHP algorithm which increases by a factor 15).

The solution was URL rewriting using .htaccess. However, it wasn’t straight forward URL rewriting – the serialized search was encoded in the query string, and that was the only part that needed a rewrite. How does the Apache Rewrite module handle this? Very well, it turns out.

Solution – part 1

The first thing to realise is that RewriteRules by themselves won’t do any good – they only work on the base part of the URL, ignoring the query string. This means you have to turn to the second part of the rewrite: the RewriteCond. Now, this presented the first part of my eye-opening experience: RewriteCond allows for using regexes. This means you can do the following:

RewriteCond %{QUERY_STRING} ^id=([0-9]+)

And you’ll match on query strings that start with id = some number of digits. You can use pretty much any extended regular expression you desire … which makes it very powerful!

Solution – part 2

As you can probably guess from the above code bit, you can also use capturing groups in the RewriteCond regexes. Not only that, though: you can reference these captured groups in a RewriteRule. It’s done slightly different from capture reference in RewriteRule regexes (these are done using $) in that a reference to a captured group from a RewriteCond uses a % as prefix. Hence, you can do:

RewriteCond %{QUERY_STRING} ^id=([0-9]+)
RewriteRule ^product.php /product/%1? [R=301,L]

And you’ll be redirecting product.php?id=123 to product/123 using a 301. Notice the ? at the end of the rewritten URL – it’s there to make sure ModRewrite doesn’t append the original query string.

At this point, my woes were almost over – there was just one obstacle left.

Solution – part 3

When the Rewrite module does redirects, it normally also escapes characters in the URL, that could otherwise turn out problematic. One such character is %. However, this escaping is itself very problematic upon redirects, because any url_encode()d URL will contain lots of % characters followed by a character code. When ModRewrite is done with the URL, it’ll have substituted all %2F with %252F, for instance … not what you want.

There’s a very simple solution to this, though: you can set a flag to stop the Rewrite module from doing any escaping. What you do is:

RewriteCond %{QUERY_STRING} ^id=([0-9]+)
RewriteRule ^product.php /product/%1? [R=301,L,NE]

This stops ModRewrite from escaping the URL, leaving you with whatever was in the original.

Using the above bits and pieces you can rewrite a URL like

/search?blah=hum%20dinger%20and%what%20not%3Aliteral

to

/search?q=hum%20dinger%20and%what%20not%3Aliteral&rewritten=true

It’s voodoo for sure, but damned cool.

swap: waiting for UUID=xxxxxxxx-xxxx-xxxx

without anything else happening, then don’t panic! At least not yet. Before you start pulling hair out of your head, try the following:

• boot into recovery mode, using grub, a live-cd or the excellent system rescue cd
• check which UUIDs your disks actually use (and by now, you should have an idea of where this is going)
  • easiest is: ls /dev/disk/by-uuid/ – however, if you have many disks then the output will be unwieldy
  • easy as well: sudo blkid – this will list all disks with extra info
• mount your linux boot partition, then check the fstab file on it
  • if you mounted it on /mnt/disk then do vim /mnt/disk/etc/fstab or nano /mnt/disk/etc/fstab
• check the partition that’s marked as swap – compare the UUID it’s loading by against the list obtained above
• if the UUID matches, go ahead, panic. If the UUID in the fstab file doesn’t match then change the fstab file (either to load the partition by /dev/sda-something or the proper UUID) and then try rebooting.

As I didn’t have access to the above list when this happened, I panicked (after the third or fourth reboot with the same result). Luckily I had access to another computer and could google for solutions – and came across this in a forum which I figured needed to be spread some more.

Why did the UUID of the swap partition suddenly change? I have no idea. Perhaps it wasn’t even the UUID changing, it was something else in the system that suddenly started caring about the mismatch (that’s rather farfetched, but so is the whole situation). My best bet is that it was down to a bootup to Windows and some work there – perhaps trusty old WinXP decided to play nasty and change stuff at random. No matter what, though … the relief when I finally got the thing working was massive (among other things, I have some webdev work to hand in soon).

Before moving stuff I thought it might take a bit of effort getting things working without problems but it turned out I had no reason to worry. A combination of git and gitosis made the basic transfer easy and the rest was handled with a database dump + import and a new virtualhost for Apache. Replicating the install looked like this:

Step 1 – setup local repo

Make sure the site you’re moving is in a git working repo. Skip this if you’re in a working git repo, otherwise just do something like

git init
git add --all
git commit -am "setting up git repo for myproject"

Your repo is now ready to move – need a place to move it to, though.

Step 2 – add group to gitosis

If you’ve not already setup gitosis on your server (local or remote) have a read on the scie.nti.st blog. When gitosis is running, you need to modify your gitosis.conf to add a new group for the site you want to move (unless you’ve got one group for everything, which I wouldn’t recommend though). In your gitosis.conf, add

[group mygroup]
writable = myprojectname
members = user1 user2 user3@host

Save and move on.

Step 3 – add remote repo to your local working directory

If like me your gitosis daemon is running on a remote server, you need to do something like

git remote add remote_repo_name ssh://git@host/myproject.git

If gitosis is running locally, you can do away with the ssh protocol bit

Step 4 – push

Time to do the actual copy. Do

git push remote_repo_name master

Your repo is now copied to gitosis.

Step 5 – clone

Check out a working copy by cloning the site to where you need it – i.e. do

cd /var/www
git clone /path/to/gitosis/repos mysite

If your new site is on the same server as the gitosis server, that is. Otherwise, use the ssh protocol for the path.

Step 6 – dump database

PL PHP is running on MySQL – hence, dumping the database and copying it across to the new site can be done by

mysqldump -u user -p database > dump.sql && scp dump.sql user@host:~/

Step 7 – setup proper user

Setup a user with access to the database using the same details as on the current site – a create ‘user’@'localhost’ will probably suffice.

Step 8 – import database

Create the database, then import using your sql

mysql> create database mydb default charset utf8;

and

bash:~/$ mysql -u user -p -D mydb < dump.sql

And done

Step 9 – create new virtualhost

Get Apache to serve up the site by creating a new virtualhost file. Then check your Apache config with apache2ctl configtest – if it’s working fine, then restart apache.

Step 10 – change DNS records

Last thing is to switch DNS records so your domain points to the new IP.

That’s it – 10 steps and PL PHP was migrated to a different server with the added benefit of having a repo copy added to my gitosis daemon. If you skip the gitosis bit then you can truncate step 1-5 – just clone the repo straight away.

On the other hand, if your site is bigger than PL PHP, you probably want to add some extra steps, such as having your current site proxy the new site, so that no traffic will hit the current site (and thus the current database). An alternative to this would be to setup the new site to use the current database and only migrate the database when you’re sure DNS records have been changed (i.e. when you no longer see hits on the old IP).

With this out of my mind, I can focus on other interesting stuff, such as the Typo3 book review I’ll be doing (expect that in a little over a week) and an interesting project focusing on the craft community which I’m doing with my fiancee :)