Alvaro Videla has a new post today showing how he used RabbitMQ in his unit testing runs with a small, quickly installed version of the server that can be removed once the tests are complete.

In this blog post I want to show you a very simple technique for using RabbitMQ in our Unit or Functional Tests. Let's say you wrote a bunch of tests for your RabbitMQ consumers and then it's time to run them. To do that you probably need to setup a RabbitMQ server just for tests with their own users and passwords, or you need to set up a whole new virtual host for your tests. [...] With a future release of RabbitMQ that we can already test on the nightlies website, we can run RabbitMQ without the need to install Erlang. We created a package that ships a stripped down version of Erlang together with the broker bits, so running RabbitMQ now is as easy as downloading a tarball, uncompressing it and starting the server.

With a combination of this more self-contained package and some listener handling through PHPUnit, they uncompress the tarball with a PHP script and start the server with the defined configuration. Then, once the tests are done, it cleans itself up and removes the entire server directory to make for a clean run the next time.

In his previous post ("PHP was meant to die") the point was made that PHP isn't really designed as a language to handle long running processes very well. It's made to handle a few operations and then die at the end of the request. In this follow up post he talks more about using PHP for long running processes and a library that could help.

Yes, I already acknowledged that PHP has a garbage collection implementation starting 5.3.0 and up (opt-in or opt-out, that's not the problem). I also acknowledge that garbage collection works, and is able to take care of most circular references just fine. [...] Anyway, as previously stated too, garbage collection is a great thing, but not enough for PHP. It's a borrowed feature that does not play well with old fundamental decisions inherited from the original design. Garbage collection is not a magical solution for every problem, like many tried to argue about. Let's illustrate with another example.

His example uses the React PHP library (a non-blocking I/O platform) to handle a lot of incoming data to a port and report back some memory usage and limit settings. He explains a bit about what's happening and shares the results of the test, including the end result - a fatal error when the memory limit was hit. He still comes to the same conclusion, ultimately...PHP is just not the language to use for long-running processes that do any large amount of work.

In this new post to his site Rob Allen shows you how to implement a simple logging method for catching exceptions in your Zend Framework 2 application.

I recently had a problem with a ZF2 based website where users were reporting seeing the error page displayed, but I couldn't reproduce in testing. To find this problem I decided to log every exception to a file so I could then go back and work out what was happening. In a standard ZF2 application, the easiest way to do this is to add a listener to the 'dispatch.error' event and log using ZendLog.

He uses an event listener to attach a service that contains a "logException" method. This method uses the ZendLog component to write out the error message to a local log file including a backtrace of where the issue occurred.

The PHP Podcast (from Zend) has posted its second episode - Episode #2, an interview with Adam Culp who recently joined the team at Zend and is a organizer for the South Florida PHP User Group.

In this episode we talk to Adam Culp on his very first day as a Zend employee. We talk about PHP community and Adam's decision to move from the realm of independent consultant to Zender! Adam is the organizer of SunshinePHP, PHP Guru and joining the Zend Professional Services Team.

You can listen to this latest episode either through the in-page player or by downloading the mp3 directly. You can also subscribe to their feed of you want this and future episodes pulled automatically.

On 7PHP.com there's a new post that interviews a PHP community member, Eric Hogue, about his experience with the Zend Certified Engineer exam.

This is the 3rd set of Zend Certification Tips and Advice to help anyone taking either of the two Zend Exams powered by Zend Technologies: the Zend PHP Certification Exam and/or the Zend Framework Certification Exam. The aim being to help people who want to sit for those exams and inform them what it is all about & what to expect by hearing it from (pro) PHP Guys who have already been through it, that is => Hear It From Zend Certified Engineers!

He starts off with some general questions to Eric about the exam and its structure and how he prepared himself for it. He mentions some of the resources he used to study and what kind of topics to pay attention to. There's also a few quotes included at the end giving another perspective on the exam (specifically, some frustrations).

On Reddit's PHP section there's a discussion happening about dependency injection versus service locators in two popular PHP frameworks - Zend Framework 2 and Symfony 2 (and how they're not really DI at all).

Both ZF2 and Symfony 2 offer the same behavior: if I'm in a controller, and I want to use a service, I have to get it from the container with $this->get('my_service'). As such, the controller is not using DI, this is the service locator pattern. Controllers become more difficult to tests because of that, and they depend on the container now. I wonder why both frameworks didn't go further: why not treat controllers like services and use dependency injection on them. In other words: if a controller needs a service "A", then it should get it in the constructor, or through setter/property injection.

The comments talk some about the "controller from the DI container" idea, some other ways around the problem and some clarification as to what the frameworks are actually doing related to the container injection.

Gonzalo Ayuso has a new post today showing how he set up queuing with ZeroMQ and Symfony components and React.

Today I'd like to play with ZeroMQ. ZeroMQ is a great tool to work with sockets. I will show you the problem that I want to solve: One web application needs to execute background processes but I need to execute those processes in order. Two users cannot execute one process at the same time. OK, if we face to this problem we can use Gearman. I've written various posts about Gearman (here and here for example). But today I want to play with ZeroMQ.

He uses React and some ZeroMQ bindings and Symfony's Process component to make a simple client and server for working with the queue and processes. A screencast is included in the post showing them making the connection and adding the new process. The full code can be found on github (or installable via Composer)

Rob Allen previously posted about some of his practices around the different types of objects in the model layer of his Zend Framework 2 applications. In this latest post he follows up and shares some example code for the different types.

I previously talked about the terms I use for objects in the model layer and now it's time to put some code on those bones. Note that,as always, all code here is example code and not production-ready.

He includes sample classes related to his "books" examples - a "book" entity (with title, author, id and ISBN), a mapper object to load/save/delete the entity and a service object that provides an interface for the entity to the rest of the application.

The first episode of a new PHP-related podcast, the "PHP Podcast" produced by Zend, has been released. This first episode, hosted by Joe Stagner features a well-known PHPer, Cal Evans.

Cal Evans has been referred to as "The Ubiquitous Face of the PHP Community". That's made Cal an obvious choice for the first guest on the PHPPodcast. In this episode we chat about the evolving face of the PHP community.

You can listen to this latest episode either through the in-page player, by downloading the mp3 or by subscribing to their feed.

On PHPMaster.com there's a new tutorial that introduces you to React, the PHP-based event-driven non-blocking socket tool that's similar to some of the functionality Node.js provides. The article is a very basic introduction but can help get your feet wet with the tool.

For the past couple of years, Node.js has been drawing increasing amounts of attention as a promising web technology. While it has some strengths, like being event driven, some people just want to stick to PHP. For over a year now, however, there has been a similar project for PHP named React. React is mostly coded by Igor Wiedler, who is also a prominent contributor to the Silex framework. While reading through the React examples, it really does look similar to Node.js.

Included in the post are the instructions on how to get the latest version of React (via Composer) and the code to create a sample server that just writes out a string with a counter for the number of requests made. There's also an example of a "keystroke logger" for all data that's coming across the connection. The author (Igor) notes, however, that he wouldn't recommend using React in production, though, as its target is mostly those working with "cutting-edge technologies" rather than more stable applications.