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).

<CR>~.

The CR in there is a carriage return, i.e. pressing the enter key to create a new line. One caveat though: the ~ is the default escape character for SSH but it can be changed (or removed) so you need to make sure you’re using the proper escape character when issuing escape sequences – otherwise, no fun/profit.

Closing an SSH connection is not the only thing you can do: you can also suspend an SSH connection by doing

<CR>~^Z

where ^Z is <ctrl>+z. But wait, there’s more! You can also change the SSH connection you’re in to add or remove port forwards, by opening a command line:

<CR>~C

And a personal favourite: if you’re using several SSH connections in serial, you can forward an escape sequence by adding another ~ after the first. Closing connection #2 then becomes:

<CR>~~.

And in the same fashion, suspending the second connection becomes:

<CR>~~^Z

This, dear reader, is awesome! There’s just no end to the fun :)

The moral: read your man pages (so much good stuff hidden away in there)!

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.

After about 2 hours of coding, I had some very basic classes that provide the most useful functionality of Geonames (useful for BeWelcome anyway): doing a fulltext wildcard search, fetching details for one specific location, and fetching hierarchies of locations. The library provides some static functions for generating location objects, and these location objects can then in turn be worked with using some of the same methods that the library provides (such as getting child locations or parent locations).

The usage is currently extremely simple – some examples:

// searching for a location
$results = GeoNamesService::search($searchterm, $rowcount /* optional, defaults to 100 */);

// fetching parent hierarchy for a location
$hierarchy = GeoNamesService::hierarchy($id);

// getting the parent of an existing GeoNamesObject
$parent = $geo_object->getParent();

As you can probably guess, the main reasoning was taking out the boilerplate code and removing the stuff we just didn’t use. As a consequence, this library doesn’t currently offer that much extra functionality. This will be built in later though, so you’re able to use some of the options when searching, for instance. Also, a number of the other ways of interacting with Geonames are worth looking at, like finding a location by postcode.

After I had spent a bit of time on the project and got it to a working basic (including some unit-tests), I figured I’d breathe some life into it and so I put it on GitHub – so anyone can take it and use it if they have a need for it. It’s available here: PHP Geonames Library and the license is a GPL v.3 so you can just grab and use in any OS project as you see fit.