Cal's questions center around the Standards group and what kinds of discussions they have about the language and the progress the group has made so far (like PSR-0):

• What's the purpose of the group?
• Is the purpose of this group to take PHP from everyone's hands and enforce the "one true grace" on everyone?
• Is the group fulfilling its purpose or is it wandering off the path?

You can listen to this latest episode either via the in-page player, by downloading the mp3 or subscribing to their feed.

Guests for this episode were Elizabeth Naramore, Laura Thompson, Anna Filina and Elizabeth Tucker Long. Cal and the panel discuss a few questions including:

• Given the tech in a male dominated industry [...] why are women entitled to change a culture that doesn't want to be changed?
• Does it make it okay if the material in question is generated by a woman if it objectifies women?
• Does the Forbes article [on sexism in tech] carry more weight because it was written by a woman and do you agree?

You can listen to this latest episode either via the in-page player, by downloading the mp3 or subscribing to their feed.

The good news was that Rasmus and Nikolay couldn't see any reasons why PHP was particularly challenging. What we saw were general challenges in scaling applications to large traffic volumes - and that's pretty much where the panel discussion went. Here's a few key points from the discussion.

Highlighted points included: removing bottlenecks to help performance (simple in theory, hard in practice), the fact that PHP should never be the bottleneck, the "odd direction" of HipHop, challenges/growing pains in moving from startup to a large web property. There was also a less technical discussion about "scaling teams" and finding the right (motivated) people to do the job.

Today I will be discussing a feature that at this moment is called "Property Accessor". It is a method of defining getters and setters. Originally an RFC was defined as early as september 2009, but recently new discussion took place and an actual patch was created. There is no certainty this feature will ever make a PHP version but discussion seems to target implementation details and not the feature itself, so things are looking bright for this feature.

There's two RFCs posted about the topic - the original proposal (from Dennis Robinson) and a patch for implementing them (from Clint Priest). The proposal replaces the common magic getters/setters (__get & __set) with the optional "get" and "set" keywords inside of custom-defined properties.

In this panel discussion, we tackle topics including the direction PEAR and Pyrus will be going in the next few years, obstacles that may be on the horizon, and more.

PEAR is the package library of standardized packages for a variety of common development tasks. Pyrus is a new package manager to make installing and maintaining PEAR packages simpler. Engine Yard's next webcast will cover the Lithium framework with core contributors Nate Abele, Garrett Woodworth, and John Anderson on December 1st.

Every PHP framework has it's own unique set of interfaces for common operations such as logging, caching, http clients, filtering, validation, etc. This creates a situation where a framework tends to be loosely coupled but only within the scope of its own interfaces. [...] Loose coupling is therefore a bad joke. It is a narrowly defined concept usually described within the scope of one particular application. We never really apply the concept across multiple applications written with different frameworks because, at that point, the disparate interfaces of both frameworks would immediately make loose coupling unobtainable.

He goes on to talk about a simple example, ZendFeedReader, and how it's very difficult to swap something as simple as the HTTP client out for one from another framework. He mentions the common scapegoat for over-interfacing - Java - and how PHP's is a bit more "practical and flexible" in that department (a good and bad thing).

So yes, common interfaces would benefit PHP and would make framework libraries more interoperable and thus usable within competing frameworks. Hey, if you can't beat them at least make sure you can inject your classes into them. Hmm, still sounds dirty.

Since about 4 weeks I have really started using Symfony2, in development for a work project no less. Kinda crazy seeing its still in pre-alpha phase, but I think its a great platform today and I know its going to be the best soon aka once we have a stable release. But in these 4 weeks quite a few things have popped up that I like to see addressed. Most things aren't really about writing code, but figuring out how things should be. The kind of stuff that is hard to fix on your own.

He mentions six different things (one or two with code examples) that are new to the framework or are being newly discussed:

• Making 3rd party controllers truly reusable
• Flash message handling
• Easy DIC customization of 3rd party Bundles
• Issues with setting GET parameters in functional tests as well as forward() calls
• Form validation issues
• Aligning the handling for Bundle configuration

A true PHP developer is a programmer who knows PHP. A false PHP developer is someone who doesn't know PHP. That's the closest correct answer I can think of. I think, Jamie wants to ask, "what's your definition of a good PHP developer?". There is no correct answer to the question. All, you can do is highlight some of the good things a PHP developer does. Let's seize this opportunity to talk about the traits of a good PHP developer. Most of the things that apply for a discussion about good PHP programmer also applies to a good web developer and good programmer in general.

He lists some of the criteria he thinks personifies good PHP developers including:

• A good PHP programmer writes PHP code everyday
• A good PHP programmer always keeps security in mind
• A good PHP programmer knows a bit of JavaScript
• A good PHP programmer keeps an eye open for trending technologies
• A good PHP programmer knows at least one popular framework very well
• A good PHP programmer embraces industry best practices
• A good PHP programmer is comfortable working with version control systems
• A good PHP programmer keeps a tab on PEAR and PECL
• A good PHP programmer writes articles

There's quite a few more than just those listed, so be sure to check out the full list for more good suggestions.

Although PHP boasts of being the most widely used environment for web application development, it has been traditionally considered as not suitable for the enterprise. InfoQ has conducted a virtual panel regarding the evolution of the language/platform and its suitability in enterprise environments.

The three members of the panel (Zeev Suraski, Rob Nicholson and Derick Rethans) are asked about PHP's interoperability with other platforms, the trend of scripts moving into a JVM, the transitions from the major versions of the language (ex. PHP4 to PHP5), the role more advanced features might play in PHP and if PHP might be considering a move into more functional programming.

Microsoft has been recently engaging in a number of open source projects. They have been working on enhancing performance, security and stability of PHP applications on Windows Server platforms. [...] In cooperation with Microsoft, [we] invite you to trial a Windows based web stack consisting of IIS 7, PHP 5 and SQL Server. Via the PHP on WS 2008 website you will be able to request a 30-day trial with a Microsoft hosting partner

By signing up, you can request a trial of the IIS 7 software. They also provide a Q&A discussion board for those participating in the program that might need any help.