The SitePoint PHP blog has posted a tutorial from author Andrew Carter showing you how you can use the Raspberry Pi hardware to power a PHP-based application with a bit of simple setup.

A Raspberry Pi is a brilliant tiny computer that you can power off of a micro USB cable. The most recent model has WiFi, an ethernet port, 4 USB ports and an HDMI port. There’s also a micro SD card slot, which is where the “hard drive” goes.

It’s capable of running Raspbian Linux, which is a Debian based Linux distribution. This makes it familiar to Ubuntu users who can then just sudo apt-get install all the things. Like with any Linux machine, you can install PHP on it and make a website – but we can do so much more than that!

He starts with the equipment you'll need to follow along with the tutorial - a recent Raspberry Pi model with wifi and a bit of other electronics equipment (he also recommends a starter kit for those new to this hardware world). Once the Pi is set up, he then installs PHP via an apt-get package install along with the PiPHP: GPIO library that makes working with the input/output simpler via PHP. He then shows the wiring you'll need to do to get a LED and button connected. A simple script is included that sets up a watcher on the button input and, when the "push" event is fired, it blinks the LED five times.

He finishes the post with a look at some of his own testing and preparation for a talk on this same subject with some slightly humorous results.

Marc Moreram has posted a guide on his site to using event listeners as collectors in Symfony 2 based applications. He shows how to hook into the eventing system and both gather events fired (matching your criteria) and view the current collection.

Some of my concerns during the last couple of years have been how to collect data from all installed bundles using available tools in Symfony packages. I say concerns because I don’t really know if is there a tool for that. Some people have told me that the EventDispatcher component can do this work greatly, but then I have the same question once and again… is this component designed for such?

He uses an example of gathering mmoreram.wake_up events from his codebase, triggered when it "wakes up". He shows how to create a simple class for the event with a "rested" value. He modifies this to set up an array of "feelings" inside the event and a method to add new instances to the internal array. Finally he shows how to dispatch an event of the mmoreram.wake_up type and access the resulting set of "feelings" directly from the event.

Marc Morera has posted an interesting article to his site suggesting a re-thinking of how event listeners are used in applications and libraries.

Let’s talk about Event Listeners. Do you know what an Event Listener is? Well, if you are used to working with Symfony, then you should know what is intended for. If you don’t, don’t hesitate to take a look at the Symfony documentation. This post aims to start a small discussion about how an Event Listener should look like if we really want to keep things decoupled.

The starts with a brief summary of the post (tl;dr) for those in a hurry but goes on to explain things in a bit more detail too. He starts by laying a foundation, introducing what event listeners are. He also shows how they're commonly implemented and used (in Symfony2 specifically but it applies more generally too) to trigger actions in applications. He suggests decoupling things a bit more from the flow of the action and allowing, in this case, access to both the order and the customer (on a "order created" action). He takes it one step further and decouples the sending of an email into a service and then creates an instance of this when needed in the event and not before.

Joshua Thijssen has a new post today with a "neat trick" that the Symfony Security component allows - switching (impersonating) another user programatically.

This allows you to login as another user, without supplying their password. Suppose a client of your application has a problem at a certain page which you want to investigate. Sometimes this is not possible under your own account, as you don’t have the same data as the user, so the issue might not even occur in your account. Instead of asking the password from the user itself, which is cumbersome, and not a very safe thing to begin with, you can use the switch-user feature.

He talks about how to enable it, how to use it to switch to another user and, most important, how to restrict its use. He points out that there's no way to define who a user can switch to built-in, so he's come up with a custom "switch listener" to help add in this protection. His "SwitchUserListener" class replicates some of the code in the original handling (well, the whole class) and updates the "attemptSwitchUser" method to check the user they're trying to switch to and see if they have the right role. Finally he shows how to add it to the services configuration and how it overrides the default listener.

In his latest post Mathias Noback takes a look at the Symfony2 event subsystems and the answer to a common problem he's had with it in the past: circular references.

Recently I realized that some of the problems I encountered in the past could have been easily solved by what I'm about to explain in this post. [...] The problem is: having a complicated graph of service definitions and their dependencies, which causes a ServiceCircularReferenceException, saying 'Circular reference detected for service "...", path: "... -> ... -> ...".' Somewhere in the path of services that form the circle you then find the event_dispatcher service.

He shows the wrong way to solve the problem first by injecting a service container into the listener and using services directly from there. In his "entirely different and much better way" he shows a solution that removes dependencies on the main event dispatcher. He shows how to use the event subsystems to avoid this link and gives a more concrete example for domain-related events (with both code and config).

In the latest post to his site, Chris Hartjes offers some advice about unit testing with listeners to help teach PHP developers the right way to test.

I had an idea to put together some kind of “PHP Testing Koans” site as a way to help PHP developers get better at learning how to actually write tests. Most developers who are introduced to testing get blocked at the point of actually writing a test. [...] So I started to brainstorm ways to make it happen. With some help from Joel Clermont I stumbled upon using test listeners for this.

He uses the built-in test listeners for PHPUnit to write a system that checks to ensure a certain test exists in a "Koan1Listener" class. This class implements the PHPUnit_Framework_TestListener interface and has several methods to catch events and handle issues thrown during execution.

The approach is simple: for each test class that gets executed, add the names of all the methods to an internal list. When the entire test suite is finished, we then check to see if the test names that we were expecting are in our list of methods we found. I am sure there is a more efficient way to do it, so let me know in the comments of a different approach.

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.

Igor Wiedler has a recent post to his site about creating stateless services, specifically in the context of using a dependency injection container to manage the objects your application uses.

As more frameworks and libraries, particularly in the PHP world, move towards adopting the Dependency Injection pattern they are all faced with the problem of bootstrapping their application and constructing the object graph. In many cases this is solved by a Dependency Injection Container (DIC). Such a container manages the creation of all the things. The things it manages are services. Or are they?

He notes that, according to some of the principles of domain-driven design, "services" should be stateless - the results of calls to the service shouldn't alter it, it should only depend on the values passed in. He goes on to put this into the context of a DIC and gives an example of the "request service" (and how it violates the DDD principles of statelessness). He talks some about scopes (dependencies) and mutable services. He talks about methods to get around these issues with the "request" instance, ultimately coming to the conclusion that event listeners might be the way to go.

In this new tutorial on PHPMaster.com, Alejandro Gervasio looks at the Inversion of Control methodology and how it's more than just an abstract reference to dependency injection.

Traditionally, application components have been designed to operate on and control the execution environment, an approach that delivers well to some extent. [...] Instead of making the module completely responsible for logging data to multiple endpoints, we can transfer the responsibility straight to the external environment. [...] Not surprisingly, the process of inverting these responsibilities between components and the environment is formally known as Inversion of Control (or in a more relaxed jargon, The Hollywood Principle), and its implementation can be a real boost when it comes to developing extensible, highly-decoupled program modules.

He uses a set of domain objects (Posts and Comments in a typical blog structure) and the Observer pattern to show how mixed up things might get if the application isn't carefully coded. He takes this and updates it to include a "comment notification service" that implements the SplObserver and is attached to the post to be executed on an event (in this case, the setting of a new comment).

Robert Basic has a new post to his blog today with an use case for Zend Framework 2's event manager to solve a problem he has with "repetitive code" in some of his models.

Basically, this allows us to have one piece of code to trigger an event and to have one or more listeners listening to this event. When the event gets triggered, the listeners are called and then we can do *something*, like caching or logging. Logging or caching. [...] See, that’s my problem. All the event examples stop at logging and caching. Truly there must be some other example for which this event stuff can be used for.

In his example code, he's used the EventManager in one of his models to add listeners to validate the post and "slugify" the post's title for use on the URL. You can find his code on github if you're interested in the full implementation.