In a recent post to his site Piotr Pasich shares an article about using a rabbit behind the scenes - making use of the RabbitMQ queuing system for behind the scenes work in your PHP applications.

In PHP business logic is usually put right in action’s method or just behind it. Hence, every little piece of delaying and long-running code will be processed with a request. The problem is almost undetectable if a user sends an e-mail but with more complex actions it may take a little bit longer than preferred. [...] In this article I would like to make an attempt to present a solution to the very annoying everyday problem that probably many programmers came across in their organisations – deadlocks in databases caused by a vast number of requests in relatively short time. The main aim of this text is to introduce RabbitMQ, which I value as a very functional and practical message broker, to help you solve the queuing problems and decrease the amount of work you would otherwise have to spend on it.

He talks about why message brokers are even needed and how to pick the right one for your project. Then he gets into the "in practice" part of the article, showing the use of RabbitMQ through PHP to save various data to a database when a user is presented with an advertisement. He shows how to create both the producer and consumer objects, making interaction with the queue simpler. His examples are all using the php-amqplib by Alvaro Videla.

Matthew Weier O'Phinney has a new post to his blog today looking at a feature that'll be included in the upcoming Zend Framework 2 release - a plugin broker that changes the way plugins are loaded.

In Zend Framework 2.0, we're refactoring in a number of areas in order to increase the consistency of the framework. One area we identified early is how plugins are loaded. The word "plugins" in Zend Framework applies to a number of items: Helpers, Application resources, Filters and validators and Adapters.

In practically every case, we use a "short name" to name the plugin, in order to allow loading it dynamically. This allows more concise code, as well as the ability to configure the code in order to allow specifying alternate implementations.

The current versions of the framework use a "PluginLoader" class that handles the resolving and loading of the plugins as they're called. With this new PluginBroker, the process is optimized and split out into some namespaces for ease of use. He gets into more detail about the class resolution, instantiation, registration and touches briefly on the PluginSpecBroker, a special-case handler that's a concrete example of the LazyLoadingBroker.

Arnold Daniels has a new post to his blog today dealing with something (usually companies) are looking towards to help deal with the infamous "too many passwords for too many places" issue - a simple single sign-on tool that can be dropped in an used anywhere.

Associated websites often share user information, so a visitor only has to register once and can use that username and password for all sites. A good example for this is Google. [...] There are many single sign-on applications and protocols. Most of these are fairly complex. [...] I've written a simple single sign-on solution (400 lines of code), which works by linking sessions. This solutions works for normal websites as well as AJAX sites.

He compares the flow on a non-single sign-on site (lots of fetching between the client/server) and the first/following visits with his tool in place. You can download the source here (as well as the Ajax broker).

In his latest post, Alexander Netkachev digs a little deeper into the Zend Framework and looks at the Zend_Controller class and its plugin support.

Zend_Controller_Plugin is not covered yet in the documentation but it is a powerful way of extending a controller. Briefly, Zend_Controller_Plugin is used for extending controller functionality by attaching listeners to events, which are fired (or trigged) by the controller classes.

He talks about the plugin interface, how it hooks into the controller and defines the relationship with some pseudo-code (showing implements versus extends). There's talk of the Zend_Controller_Plugin_Broker class and the Zend_Controller_Front. He looks in detail at this last class, showing how it helps to handle incoming requests for the plugin functionality and veen includes working code you demonstrate how.

In his latest post, Alexander Netkachev digs a little deeper into the Zend Framework and looks at the Zend_Controller class and its plugin support.

Zend_Controller_Plugin is not covered yet in the documentation but it is a powerful way of extending a controller. Briefly, Zend_Controller_Plugin is used for extending controller functionality by attaching listeners to events, which are fired (or trigged) by the controller classes.

He talks about the plugin interface, how it hooks into the controller and defines the relationship with some pseudo-code (showing implements versus extends). There's talk of the Zend_Controller_Plugin_Broker class and the Zend_Controller_Front. He looks in detail at this last class, showing how it helps to handle incoming requests for the plugin functionality and veen includes working code you demonstrate how.