Freek Van der Herten has posted about a new package that's essentially a stand-alone version of Laravel's own "macros" functionality available via a package: macroable.

We recently released our newest package called macroable. It contains a trait that, when applied to class, can dynamically add methods to that class. This trait is basically a stand alone version of the macroable trait in Laravel. In this post I’d like to show you how you can use it, how it works behind the scenes and explain why we created it.

He then gives examples of how it can be used to add a new simple method (essentially a "named closure") and using the "mixin" functionality to add multiple at once. He wraps up the post with a look at how it works behind the scenes, adding the items to a "macros" list and then looking them up if they're not defined on the class.

Rob Allen has written up a brief tutorial showing you how to use the Zend/Filter component independently from a Zend Framework application. In his example he integrates it into a simple API endpoint.

Any data that you receive needs to be checked and validated. There are number of ways to do this including PHP's filter_var, but I prefer Zend-InputFilter. This is how to use it as a stand-alone component.

He shows you how to get the component installed (along with the Zend ServiceManager) and the creation of a basic validation/filtering on "author" data. He explains the different parts that make up the instance: required, filters and validators. He then shows how to use it in your request and the resulting output if something fails.

Rob Allen has posted a tutorial to his site making some updates to his previous work with the Doctrine migrations handling as a standalone component. In this new tutorial he talks about the newer way to use it in your projects.

Since, I last wrote about using the Doctrine project's Migrations tool independently of Doctrine's ORM, it's now stable and much easier to get going with.

He starts with the basic installation and configuration of the migrations tool, making use of a SQLite database as an example. He then shows the use of the basics of using it to make database changes:

• creating a new migration
• running the migrations

Each step comes with code, the commands you'll need to execute and an example of the resulting console output.

For those wanting to check out the latest preview of the Zend Z-Ray stand-alone version, Rob Allen has posted a full Ansible script to help building the environment much easier.

Recently, Zend made available a Z-Ray Technology Preview which takes the Z-Ray feature of Zend Server and makes it stand-alone. This is very interesting as it means that I can run it with the PHP 5.6 on Ubuntu 14.04 LTS Vagrant set up that I prefer. I decided to create an Ansible playbook to install Z-Ray into my VM. The Z-Ray instructions are clear enough, so it was simply a case of converting them to a set of YAML steps as who wants to do manual installation nowadays?!

The configuration is set up to run on a Ubuntu machine with PHP 5.6 installed. It will download the Z-Ray plugin, extract it and copy over all necessary configuration files to get it up and running. This stand-alone version can help to make debugging your applications simpler with real-time information right in your browser.

Rob Allen has a recent post to his site showing you how you can use Doctrine migrations as a standalone tool for its migrations functionality. Migrations allow you to script the setup of your database, replacing the need to manually create and configure the system by hand.

My current project has reached the point where a good migrations system is required. As I'm targeting two different database engines (MySQL and MS SQL Server) and we're already using DBAL, it made sense to use Migrations from the Doctrine project.

He walks you through the installation (via Composer and a command-line script to bootstrap the Doctrine environment outside of the usual framework context. He includes an example yaml configuration file and PHP-based connection information config. He finishes off the post by showing how to build a simple migration that creates an "artists" table (with "name" and "id" columns) and run the command to do the work.

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 this new post to his site Paul Jones talks a bit more about coupling in frameworks (see some of his recent Aura posts for more), this time looking at how the Symfony framework defines "decoupled" based on its object structure.

Previously, on decoupling and dependencies, I said: “Some [Symfony] commenters were dissatsifed with my use of unit testing requirements to discover what a package really depends on, as opposed to what its composer.json file states.” I’m willing to allow that the Symfony commenters here might be right. Let’s try looking at Symfony’s claims and see how they stack up.

Based on a list of components Symfony says don't have mandatory dependencies, he finds that - out of the fifteen given - four of them do have dependencies.

Does having mandatory dependencies make it a bad project? Not at all. It just means their statement of “no mandatory dependencies” (and related statements) is not true for all the components listed. Now, it may be that the Symfony folk have a different idea of what “decoupled” and “standalone” mean.

Noting the lack of a good, independent library for creating Mock Objects for unit testing PHP scripts, Padraic Brady (with assistance from Travis Swicegood) has come up with a standalone Mock Object and Stub framework - Mockery.

It's not tailored specifically to any one testing framework, rather it's an entirely separate framework with a discrete API. The idea is that you can use this framework within PHPUnit, or SimpleTest, or anything else really, without being forced to rely on the built-in support (if any) that test framework provides. Mockery was designed specifically to implement a form of Domain Specific Language (DSL). It makes extensive use of a fluent interface mixed with methods to approximate plain English.

He includes an overview of what Mock Objects and Stubs are and how to set them up with the Mockery tool. He finishes things off with a look at the Mockery and Mock Object Expectation APIs. You can grab this first release either as a PEAR package or from its github page.

On his blog today, Vinu Thomas looks briefly at one of the compiler options for PHP developers - the Roadsend Compiler.

Finally an open source PHP compiler ! Roadsend was perviously available as a commerical compiler for PHP with prices starting from $129. They seem to have shifted to the OSS model recently, giving free professional licence to their older compiler while they're working on releasing the precompiled versions of their open source code base.

He also links to a community site that offers the latest news about the project, some good places to start if you're just picking it up, and the timeline/roadmap for how things will progress.

On his blog today, Vinu Thomas looks briefly at one of the compiler options for PHP developers - the Roadsend Compiler.

Finally an open source PHP compiler ! Roadsend was perviously available as a commerical compiler for PHP with prices starting from $129. They seem to have shifted to the OSS model recently, giving free professional licence to their older compiler while they're working on releasing the precompiled versions of their open source code base.

He also links to a community site that offers the latest news about the project, some good places to start if you're just picking it up, and the timeline/roadmap for how things will progress.