In a recent post to his blog Devis Lucato introduces the "Inversion of Control" design pattern and shares an implementation he's created as an illustration - a Service Locator called Select.

[In a Service Locator] all the dependencies are provided by a builder, which serves as a registry of dependencies and/or service definitions. The service locator knows how to instantiate each dependency. Such service exposes methods like 'getMailer()', 'getLogger()' etc. A service locator centralises the configuration detailing classes and parameters involved on objects instantiations.

He includes some sample code showing the structure of a Select implementation using a "Mailer" identifier and definitions of the classes to load for it. He also includes a bit of documentation of the (simple) API you can use to work with the tool - setting namespaces, replacing class definitions, creating definitions and finding the resource associated with a definition (to name a few).

A little while back, the PHP development group posted a survey of developers asking them which version control system they'd like to see the PHP project use. By an overwhelming margin, git has won and things are already in motion to move parts of the project away from subversion.

In his mailing list post, David Soria Parra explains:

After 2 weeks of voting and discussion, I closed the votes today. The results are fairly straightforward. Most of the users want to move to a decentralized version control system. [...] I don't want to make a difference of who voted for what. I think the results are overwhelming in favor of Git.

He'll be working on the spec to make the move for the PHP source over to git and is planning a cut over some time in December. Stay tuned to the php.internals mailing list for more details about the move as they come up.

The Ibuildings techPortal has posted their latest episode in their DPCRadio podcast series as recorded at the Dutch PHP Conference 2010. This latest episode is Harrie Verveer's talk about database version control.

We've all read the textbooks and are using version control systems for our code, but our databases are left out in the cold. Every team has their own workaround, ranging from patch files to SQL snippets in the bugtracker, but none is really robust. Unfortunately there is no silver bullet, but there are several tools and best practices that can help you to make your life easier. This talk shows several approaches that can help you to overcome this problem and to control database structure changes in a more sophisticated way.

You can either listen in-page on their player or you can download the mp3 and listen whenever you'd like. You can find his slides here and, as an extra bonus, an article on the same topic also on the techPortal.

On the Ibuildings techPortal today Harrie Verveer has a new post looking at database version control - one of the more difficult topics for development groups - and some of the technology that can be used to help make it a bit simpler.

Database version control is something that most developers have to deal with regularly, yet only a few have actually thought about what solution might be best for them. Most people have a solution that sort of works for them, but when you ask them about the subject they are pretty convinced that there must be some better way to manage database changes, they're just not entirely sure what that solution is - but the silver bullet must be out there somewhere, right?

He starts where most developers start - their own custom script. It usually will take in a series of patch files and apply them one by one. In this case a "patch level" is stored somewhere (file/database) and is checked when the deployment is done. He points out a few issues with this method including patch naming issues and branching. Taking a step up the technology tree, he looks at other solutions like Phing+DBDeploy, Liquibase, and Doctrine migrations to try to help you find your project's "silver bullet".

In this new post to his blog today Gonzalo Ayuso looks at how he's set up a system that uses PHP to synchronize their PostgreSQL databases' schemas when things changed.

We create source code at development server and push the changes to production. It's really easy to keep synchronized all our code. But with databases it's different. [...] It's a recurrent problem working with databases. We create database objects (tables, views, ..) in the development server and when our application is ready to go live we push the changes to production server. If we are smart developers we save all database scripts in a file and when we deploy them to production we execute the script.

He mentions tools like dbdeploy and phing to help make these migrations a bit more automatic. He needed something a little different though - a command-line script that would, based on an ini file, sync two or more databases. He's created the basic script that includes the actions to show the differences between the databases, a summary of the differences and an execution method to bring them into sync. He gives a basic example of how it would handle the sync between his example production and development databases.

On the PHP North West site they've posted a new video from this year's conference (back in October) of one of the sessions. In this new video Harrie Verveer presents his talk Database version control without pain.

We've all read the textbooks and are using version control systems for our code, but our databases are left out in the cold. Every team has their own workaround, ranging from patch files to SQL snippets in the bugtracker, but none is really robust. There isn't a silver bullet solution, but this talk will show you different approaches and solutions that you can use in different kinds of projects, helping you to handle the changes in your database structure in a more sophisticated way.

You can find the related slides here. There's also other great episodes on the PHP North West website.

On the Ibuildings techPortal today they've posted the latest episode of their DPCRadio series (recordings of the sessions at this year's Dutch PHP Conference) - David Soria Parra's talk "Advanced Git".

Besides OpenSource projects like the Linux Kernel, OpenJDK or Perl, companies increasingly use distributed version control systems like Git and Mercurial. Their unique features makes new and modern work-flows possible, which are particularly useful in agile development. The talk gives a introduction to the advanced features of Git and the fundamental concepts of modern distributed version control systems.

As usual, you can choose to either listen via the in-page player or you can download the mp3 and listen whenever. His slides are also available online so you can follow along.

Brian Swan has a new post to his blog today about consuming protected feeds of OData coming from SQL Azure in a PHP application.

I did write a post a few weeks ago that described how to enable anonymous access to SQL Azure OData feeds (Consuming SQL Azure Data with the OData SDK for PHP), but I had a few things to learn about AppFabric access control before I felt comfortable writing about authenticated access to these feeds.

He starts from the Azure side, creating a sample OData feed and adding permissions to only allow access to a specific (database) user for the feed. You'll use a set of data to connect to the feed - a username, a secret key, an issuer name and the OData endpoint address. Then, using the OData SDK he shows how to generate the needed classes with the automatic tool and use them to connect to the endpoint and retrieve data from the feed. He also includes a little snippet for those that might not want to use the SDK - an example using curl to connect and authorize the session.

Brian Swan has a follow-up post to his introductory look at access control in Azure AppFabric applications with a bit more in-depth look at some of the settings to help you refine your controls.

I will again build a barpatron.php client (i.e. a customer) that requests a token from the AppFabric access control service (ACS) (the bouncer). Upon receipt of a token, the client will present it to the bartender.php service (the bartender) to attempt to access a protected resource (drinks). If the service can successfully validate the token, the protected resource will be made available.

You'll need to have an Azure instance set up and have already set up the scripts from his previous post to follow along. He updates the scripts to enhance with token checking and allowing the "patron" to request a token. Complete code is available for download.

Brian Swan has a new post to his blog today that aims to help you understand how your scripts access the Windows Azure AppFabric and how to can control the levels with the Access Control Service.

In a post I wrote a couple of weeks ago, Consuming SQL Azure Data with the OData SDK for PHP, I didn't address how to protect SQL Azure OData feeds with the Windows Azure AppFabric access control service because, quite frankly, I didn't understand how to do it at the time. What I aim to do in this post is share with you some of what I've learned since then. I won't go directly into how to protect OData feeds with AppFabric access control service (ACS, for short), but I will use PHP to show you how ACS works.

He illustrates with an example from another blog about a night club with a bartender, bouncer and checking wristbands to make sure the patrons are allowed to drink. In this case, the "bouncer" is the Access Control Service, a built-in feature of your Azure instance. He shows how to set it up, configure policies and the PHP code for both sides of the equation - the "bouncer" to change the certification sent and the user with a "wristband" to send the credentials on connect.