In this new post to his site Andrew Podner looks at using the Stackato software from ActiveState to provide a Platform-as-a-Service environment on any cloud infrastructure.

So, now it is settled, I want to stay inside the corporate firewall, but I want each application isolated from the next, and by the way, there is no budget for any of this. I posted about three PaaS providers a while back, and started thinking that what I really needed was PaaS, but I needed to be able to host the PaaS environment inside a corporate LAN. Off to search the web. Surprisingly, there were not just a ton of viable results in that search. Even more surprising...hard to find one with a "download here" button. No matter how I searched though, one company & product kept popping up: Stackato by ActiveState. The words "Free Micro Cloud" were a very encouraging sign. So let's take this thing for a spin and see just how easy it is...

He walks you through the installation process - downloading the VMs, setting up the initial configuration and how to use the command line tool to deploy your own applications (several come preconfigured though). He also includes an example configuration (YAML) you can use to configure custom applications and some sample code showing a database connection.

There's been a few articles posted on various blogs in the PHP community recently about the "most correct" usage of the "private" scope in your PHP applications. As with any feature of just about any language out there, there's people on both sides of the fence. Here's the ones that have weighed in so far:

• Brandon Savage's initial post (an excerpt from his upcoming "Do This, Not That" book)
• A response to this from Anthony Ferrara
• Brandon's own response to comments on his previous article
• This new post from Larry Garfield and some of his experience from the Drupal world

Various topics come up during these posts including static coupling, using interfaces versus inheritance, wrapper classes and developer intent.

A while back Brandon Savage mentioned a book he was writing ("Do This, Not That") to help PHP developers learn some of the best practices associated with the language. Today he's posted an excerpt from the book for your enjoyment.

This great series of highly focused e-books will offer tips, tricks and best practices focused on core areas of PHP development, including databases, security, filtering, regular expressions, configuration and more. Since it will be a series of tightly targeted solutions, developers will be able to pick all, some or just one of the offerings that solves their specific problem(s).

This excerpt looks at private method use in your applications and why they could be considered "evil" if not used correctly.

In his previous post Sebastian Göttschkes introduced a set of classes you could use for different types of testing in your Symfony2 applications. In his most recent post he expands on these examples, giving the UnitTestClass an extra ability.

In one of my last articles on Testclasses for symfony2 I explained some of the classes I use for my tests. Since then I found a great article on metatesting and want to update my UnitTest class to show some practical examples.

His update allows the class to access private properties via a "getAttribute" method that, via PHP's Reflection, allows you to pull out the private property's value and a "setAttribute" that lets you inject a value back in. He includes a word of warning, though - if you're using something like this often., you're probably "doing it wrong" and might need to think through your application design a bit more.

You can find the source for his classes in his previous post.

From RubySource.com there's a new post from a confessed developer who moved from PHP to Ruby about PHP's private visibility rules and how they compare to Ruby's.

Alright class - today I'm here to talk about the differences and similarities that PHP and Ruby have when it comes to object properties, methods, and their visibility - how you create variables inside classes, and how you can interact with them.

He compares the private properties in PHP classes to the corresponding handling in Ruby, including the getters and setters to go with them. There's also a look at class visibility settings in Ruby.

Vance Lucas has tossed his hat into the ring in the debate about private versus protected scope in PHP projects with this new post to his blog.

The age old private vs protected debate has been re-ignited in the PHP community recently following the decision of Doctrine2 and Symfony2 to make all class methods private until there is a very clear and proven reason to change them to protected or public. The intention is a good one - to ensure they are providing a clear and stable API through intentional and known extension points that they can better test and support. [...] The problem is that this kind of thinking is a slippery slope that kills the spirit of programming.

He suggests that, by limiting the scoping down to private, you're taking away the very thing that gets most people excited about third-party tools - the extensibility. In his opinion, it sends a strong message to other developers that they're "not welcome" to make suggestions or updates to the application/tool.

From the Insidesigns blog there's a new tutorial showing how you can create a scalable messaging application that works similarly to the instant message platforms users are used to. Their method combines PHP and a MVC approach.

Most social networking sites support two types of messages: public and private messages. Private messages are generally sent in a similar fashion to e-mails, and public messages being posted on user's profiles for other users to see. In this article by Michael Peacock, author of the book PHP 5 Social Networking, we will learn how to allow users to post private messages to each other.

They start with the database structure (specifying things like sender, message and the message) and move into the models to connect the scripts to them. Then they progress into the controllers and views for listing messages, reading a message, viewing and deleting a message. Full code is provided in the post, ready for cut and paste.

Wojciech Sznapka has a new post to his blog showing an interesting OOP programming strick related to accessing private properties in one object from another if they're derived from the same class.

Last time I wrote about Weirdest PHP construction I've ever seen, now I found another unusual PHP solution. PHP offers 3 visibility modifiers: private, protected and public. Private properties and methods can't be accessed outside the object, as well as from inherited classes. With one exception... They can be accessed by other instances of the same class. You can read more about it in the PHP manual.

In his code example he shows how to create two objects of the Foo class and, using getters and setters change the value of a private property from the first object on the second object.

In response to a post from Leszek Stachowski about underscores in PHP class development, Paul Jones has shared his own thoughts on the matter - that he disagrees with Leszek and suggests keeping the underscore prefix for private methods.

I think the underscore-prefix for protected and private is a good convention to keep. As with many things about programming, this convention is not for the program, it is for for the programmer. For example, limiting your line length to about 80 characters is a good idea, not for reasons of "tradition", but because of cognitive limitations of human beings who have to read code. Likewise, using the underscore prefix is an immediate and continuous reminder that some portions of the code are not public. Its purpose is as an aid to the programmer.

He suggests that it offers something similar to the thought process behind the magic methods like __get or __set that both work on a private scope. Check some of the comments for opinions both for and against the idea from other community members.

In a new post to his blog Leszek Stachowski wonders about a coding convention that's still widely used when it comes to private methods in a class - the underscore prefix.

The question which comes instantly to my mind is: why? Is there any reason why this convention should be kept when PHP object oriented programming has gone a long way since PHP 4 (when there was no access modifiers and such underscore was the only fast way to distinguish public from, hmm, not public methods and properties) ? Are, for instance (as one of major OOP languages), Java coding standards pushing towards such naming convention? No!

He, like many other developers, are pushing to drop this kind of convention as an outdated reminder of the PHP4 days when "private" didn't exist in the language. Scope modifiers have done away with the need for that underscore completely.