So, what are the advantages of an ACL model? The first advantage is security. Using this model will make your application more secure and less vulnerable to exploits. When securing any program, it is good to give to the user only the privileges he/she needs. That means that, for example, you should not give super administrator privileges to someone who will only manage website content. The ACL security model allows you to do just that. The second advantage is the easiness of user management. You can divide users into groups, while each group has certain access permissions. Also, you can easily add new user groups, delete the old ones or change group permissions.

They include the database structure you'll need to make the backend work (four tables) and the code to create an "Acl" class with methods to check a user+group for a permission, get the permissions for a user and get the permissions for a group. It's a pretty simple system and has a lot more that could be added to it to make it more robust, but it's a good start.

Continuing with Access Control Lists, we will read about the two Access Control Lists and their mapping. The Access Request Objects (AROs) are a list of the things that seek permissions and the Access Control Objects (ACOs) are the resources on which permissions are required. Both the lists are maintained in the tow tables, namely aros and acos respectively.

Included in the post is the SQL you'll need to create the tables for the system to use as well as some basic code to use the AclComponent with the ACOs/AROs. They also show how to use the parentNode method to create parent/child relationships between the objects.

[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).

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.

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.

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".

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.

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.

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.

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.