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.

Sending emails programmatically is a common task that programmers must deal with often. Although you can use PHP's native functions, they can be too low-level, especially when you want to attach one or more files to your message. If you don't want to use the native functions, or if you want to send mail using an object-oriented approach, then this is the article for you. I'll introduce you to Swift Mailer, a powerful component-based library that let's you send emails easily. Started in 2005, Swift Mailer is a library that provides several classes that allow you to send emails from within your PHP scripts or web applications.

Included in the post are a basic example of sending a plain-text email, working with attachments and including a template into the body of the message (with spots to fill text in).

Sometimes I need to stop/start remote Windows services with PHP. It's quite easy to do it with net commnand. This command is a tool for administration of Samba and remote CIFS servers. [...] Today we are going to create a PHP wrapper for [net rpc service].

He uses Behat to create a feature (test) file, the code behind the features and a service class that handles the actual work of interacting with the service (with methods to do things like stop, start and list running services). Examples of its use are also included.

With OS X 10.8, Apple continues to ship PHP 5.3 with Xdebug, PEAR, GD and PDO_MYSQL. This is how to set it up from a clean install of 10.8.

He's broken it up into a few sections including the MySQL setup, Apache configuration , updating the main php.ini and setting up PHPUnit ("and friends") for your testing. He also includes setup instructions for the mcrypt and the PECL OAuth extensions.

As with most tools that work really well, I know very little about PEAR. I mean, I use it all the time, and I love it for getting all the extensions installed that I need for the work I do. [...] However I'm now in a situation where I might need to install PEAR packages with a connection that may or may not be working, and I'm not sure exactly which packages I might need, so I wanted to know whether I could use PEAR as my packaging tool even when I wasn't able to reach the usual channels. And guess what? I can!

The install is a pretty simple two-step process - just download the package(s) you'll need for your development and point the PEAR installer (you'll need this installed first, obviously) at the archive file. It's smart enough to take care of the rest.

So that I don't forget how to do this next time around. Worked for me, your mileage may vary. First step is to get a working install of PHP. [...] At this point, you should be able to open up a Command Prompt, and type 'php -v', and see the response 'PHP v5.4.latest …' appear as expected. Now for PEAR itself.

He gives step-by-step instructions on how to get PEAR up and running - downloading and configuring it with the correct Windows-based paths and using the PEAR_ENV.reg file to update your registry.

Don't let the definition freak you out, as if you've been using MVC for a while the chances are you've used a service already. Controllers are often called services, as they carry out application logic and additionally are capable of interfacing to several client layers, namely views. Of course in a more demanding environment, plain controllers fail short in handling several clients without the aforementioned duplicating, so that's why the construction of a standalone layer is more suitable in such cases.

He explains the process behind creating a simple domain model (image here) and shows how the Service layer wraps it up into a simpler interface, leaving the model to handle the business logic. He uses the example of an "EncoderInterface" that's implemented in a "JsonEncoder" and "Serializer" to both provide a "setData" method.

What is a package? A package is a piece of reusable code that can be dropped into any application and be used without any tinkering to add functionality to that code. [...] Most package systems also allow for something called dependencies. [...] This is how most modern programming languages work, but to make a generalisation: PHP developers hate packages. Why? Well while other languages have great systems like CPAN for Perl, Gems for Ruby, PIP, PHP has had a terrible history with package management going back years.

He talks about one of the main current packaging systems, PEAR, and how, despite its attempts, it just hasn't seen the adoption the package management of other languages has. Phil makes a recommendation that is slowly becoming more and more popular in the PHP community - building "unframeworks". These sets of reusable components (similar to the ideas behind Aura, Symfony and Zend Framework 2) are designed to be dropped in and used without the dependencies of the frameworks they live in. He points to the Composer/Packagist dynamic duo as a way through all of the current packaging issues - a simple way to make any project an installable package just by adding a configuration file.

This is something experimental I have been working on for our chef deployments. So the objective was/is to find a sane way to install PEAR packages and install dependencies with composer.

He shows how to set up the configuration script to discover a new PEAR channel, make the chef script not "fail hard" if a command returns a failed response code (as PEAR will do if the channel is already discovered). The "ignore_failure" configuration directive comes in handy for this. He also shows how to implement a LWRP in chef for both a PEAR and Composer resource.

You can find the code for this and other cookbook examples on his github account.

Building a graph is not enough; we also need the ability to search through it. To make it easier to build search algorithms, it is useful if we can represent the graph and its connections in a different way; adjacency matrix being one such representation. An adjacency matrix is a means of representing which vertices (or nodes) of a graph are adjacent to which other vertices.

He includes some sample code to extract the data from a graph (built with the PEAR Structures_Graph package) and create a basic "table" of information about each nodes' connections.