Putting it off for forever, I have finally started writing about Design Patterns on the PHPFreaks.com site. Originally, I was planing on creating a single tutorial on all common patterns. The magnitude of task is why I kept putting it off.

Instead, I am now covering one or two patterns at the time, making for byte sized chucks for reader and writer.

One of the mods over at PHPFreaks.com pointed out a very good presentation about database design and usage.

This 220 slide long presentation covers many of the most common mistakes made, and their 'proper' solutions, mostly geared towards MySQL and PHP.

A definite must read.

I implemented Transform View (XSLT) for Zend Framework. It's a relatively basic class that allows layout templates and calling Zend Framework View Helpers from XSL templates. Read on to view the class and some basic explanation.

On my blog I assume the reader to be eloquent in OO PHP. Knowing very well this isn't the case for 70%+ of the PHP developers out there, I've started a series of tutorials on PHPFreaks.com that will give you the grand tour of OO in PHP.

Part 1 is an overview of what features PHP has to offer in respect to OOP.

http://www.phpfreaks.com/tutorial/oo-php-part-1-oop-in-full-effect

Part 2 is an introduction to some OO principles and practices.

http://www.phpfreaks.com/tutorial/oo-php-part-2-boring-oo-principles

Part 3 is an introduction to UML Class Diagrams and class relations

http://www.phpfreaks.com/tutorial/oo-php-part-3-uml-classes-and-relations

More parts to come.

My idea of fun is to combine existing patterns, producing a solution to more specialized problem than the original pattern specifications individually. I should probably get out more.

In this case, I was faced with the following problem: how to create a flexible, complex and multi-dimensional chain of Command Objects (a chain of commands and subcommands), that was executable top down over and over, without re-executing the same command twice for that chain. Operations should block the execution of their children on failure to complete. Children should be executed serial, and isolated from each others potential failure.

When faced with creating complex relations between objects of the same type, with operations to be executed on the underlying structure transparently, the Composite pattern can usually save the day. I created a mechanism to create a composite structure of any implementation of an abstract Command Object class.

Because I implemented Composite, I already had a mechanism to execute a Command and it's descendants in the order required.

Whether you're running your application as daemon or your using a caching server, homebrew (in that case you probably want to use the shmop extension, which will save you the trouble of creating a PHP script daemon) or third party such as Memcached, there is a limit to the amount of memory you can use.

You may want to cache some items practically indefinitely, like keeping a visitor's session for 6 months. Keeping the session in memory for that time is of course ludicrous. Also, should your daemon handling caching crash, or need a reboot, bye bye data. The solution to this is to implement multilevel caching strategy.

Take a look at the following sequence diagram, which illustrates getting an (old) item from cache.

If you know your Design Patterns, you'll recognize a tiny Chain of Responsibility pattern in this example. In essence, we compose a chain of two objects, breaking on the first object that can handle the request. If you look near the bottom of the diagram, you'll notice that after retrieving an item, it is moved to the top of the chain. This done under the assumption that the item will be used more often in this time frame. The item is placed at the top of the stack of the first cache, and will continue to placed there by the top level cache, each time it gets accessed. The stack has a fixed length, so adding new items to it will pop off the least frequently used. The handler will then put it in the next cache in the chain. This is a crude implementation of the LFU (Least Frequently Used) strategy, which doesn't work.

Hold on, did he say "which doesn't work"? Yes, I did. The problem with this approach is that once the top level is full, every new addition to it will cause both a get and a put operation. With a three level (or more) cache, you risk cascading put operations. There is no solution to this in a single-threaded environment (that I can think of), other than being lenient with the amount of space the top level cache can use, and let garbage collection 'enforce' the limit. That means we no longer have a hard limit, but it also means our caching mechanism is as fast as it possibly can be. It's still risky, especially running an application daemon. The following implementation should be regarded as 'food for thought', nothing more, nothing less.

Even in the best of applications, errors will occur. Zend Framework has a great feature to deal with uncaught exceptions: the error handler front controller plugin, or Zend_Controller_Plugin_ErrorHandler.

In this post a quick example (or maybe not so quick – if you're in a hurry, come back later) of how to implement a relatively simple 'error controller' using Zend Framework.

ExtJS is a pretty awesome JavaScript library, that allows you to build user interfaces that are as easy to use as the ones found in desktop applications. Some of it's implementation is fairly complicated, and the amount of options and classes can be a bit overwhelming. I've learned a lot of new tricks lately, one of which I'm going to share with you in this post: creating 'linked' remote comboboxes.

Once you know how, it turns out to be stunningly simple I'm not covering the very basics of using ExtJS (in this case, creating a form), check out the ExtJS site for plenty of examples and tutorials on ExtJS basics.

I decided to write a small C# application to facilitate stress testing of Web applications. The reason I didn't want to use csharp (with sockets or the cURL extension) is because I wanted to use threading. I could've gone with Java, but I fell for the ease of creating a GUI with Visual Studio.

I don't have much experience with C#, but with a little help from Google and MSDN, I was quickly able to create a simple application that makes requests and measures the time it takes to receive the response.

In my previous post about performance through the use of a socket server I did a lot of talking, and I can understand perfectly if it leaves you clueless as to how to implement this idea.

Today I'll lay some foundations for an example implementation. First lets set the scene with a sequence diagram. It's probably not going to match the end result a 100%, but its intent is to sketch what we're going to create eventually. Don't worry if not all of it makes sense right away.

What it doesn't show is the client requesting the socket client file. There's nothing really out of the ordinary about that though. Next up, the class (or object) diagram for the Socket package, which is mostly a wrapper around the socket functions.

A while ago, one of the moderators over at phpfreaks.com asked me to write a little about an idea I had: to run an entire PHP application as a daemon. This post is about that idea, how it works, why it works, and why it doesn't work.

The Zend engine is pretty smart when it comes to optimizing, and using PHP as an Apache or FastCGI module increases performance by reducing initialization time for the Zend engine and PHP environment, but it doesn't do much for your "userland" application. With large applications, this can become an issue. Some, like Wikipedia, try to solve this by utilizing memory caching, for example using Memcached. While this definitely increases performance, it leaves something to be desired. A Memchached server is in fact a caching daemon, transferring string data over TCP/IP. This means objects have to be serialized/unserialized, which takes both processing power and time. There is also some network overhead, since one request might entail several calls on the caching daemon.

In addition, parsing time can become an issue if you have a relatively large library.

There is something that is both a recipe for the perfect cake as the ultimate disaster: a PHP application socket server. The base ingredients:

1. An application designed for efficiency and modularity;
2. A socket server bootstrap file;
3. A socket client bootstrap file.

That's it. As you can see it is fact stunningly simple.

Just a quick post about Mock Objects.

If you're interested in learning about them, read these two docs, written by the guys from ThoughtWorks. I found them to provide some valuable insights.

http://www.mockobjects.com/files/endotesting.pdf

http://www.mockobjects.com/files/mockrolesnotobjects.pdf