On the Laravel News site there's an article posted from Sharon Steed covering some habits of highly productive tech teams including topics like trust, meetings and understanding roles.

There’s always a lot of talk about “culture” on tech teams. And that makes sense: managers generally hire people that will fit in well with the group they’ve assembled because they know there’s more to work than just doing the job. Being able to get along with your coworkers, being reliable, and looking the part are also important. A big part of building a solid company culture is about creating an environment which helps your employees be productive. Unfortunately, a lot of what we do in tech has the opposite effect.

She talks about the role of perks in an effective workforce and how, despite some seeming very nice on the outside, can cause burnout as it encourages longer work hours than normal. From there she moves into some suggestions about "meeting culture" and some of the major drawbacks to meetings (including how they can distract from "real, paying work"). There's a nice flow chart included in the post too that can help you determine if a meeting is really necessary or not. From there she goes on to talk about the other two topics mentioned above - employees knowing and understanding their roles and fostering trust between them through things like delegation and effective listening.

The Loosely Coupled podcast, hosted by PHP community members Jeff Carouth and Matt Frost, has posted their latest episode - Episode 18: Best Practices. In it they talk about "best practices" as it relates to teams and working with other developers.

In this episode Jeff and Matt will talk about their experiences of getting teams moving on good practices. They will cover times when it has been challenging to convince higher-ups the value of doing certain things, all the way to how to go about changing teams by example. This episode is sponsored by our friend, Coderabbi, who is currently on the Wisdom as a Service World Tour 2015.

You can listen to this latest episode either through the in-page audio player or by downloading the mp3. If you enjoy the show, be sure to check out previous episodes and subscribe to their feed.

The Zend Developer Zone has republished the latest roadmap for the Zend Framework as posted by Andi Gutmans of Zend.

Although not always visible due to the infrequent release of new framework packages, there has been a lot of progress in the past few months. More than 100 community members(!) have joined the effort by singing the CLA, and are contributing via proposals, comments, patches, code contributions or documentation improvements.

Now the Summer is over and everyone is back at work, we feel it's the right time to finish planning the 1.0 release. We believe that in order to make a successfull release and get closure on the various aspects, it makes most sense to break up the framework into a limited number of subject areas and form project teams around these areas instead of components.

The following is a list of such areas and the components we believe we should focus on for 1.0. As you can see, a large amount of the work has already been done, but we now have to focus on getting closure on them and tying up loose ends.

Some of the components they've listed fall under the categories of:

• Web & Web Services
• MVC & related
• Authentication & authorization
• Databases
• Documentation & translation

There is also a high-level look at what version 0.2 of the framework will contain and a return to the "post often" methodology they had before.

The Zend Developer Zone has republished the latest roadmap for the Zend Framework as posted by Andi Gutmans of Zend.

Although not always visible due to the infrequent release of new framework packages, there has been a lot of progress in the past few months. More than 100 community members(!) have joined the effort by singing the CLA, and are contributing via proposals, comments, patches, code contributions or documentation improvements.

Now the Summer is over and everyone is back at work, we feel it's the right time to finish planning the 1.0 release. We believe that in order to make a successfull release and get closure on the various aspects, it makes most sense to break up the framework into a limited number of subject areas and form project teams around these areas instead of components.

The following is a list of such areas and the components we believe we should focus on for 1.0. As you can see, a large amount of the work has already been done, but we now have to focus on getting closure on them and tying up loose ends.

Some of the components they've listed fall under the categories of:

• Web & Web Services
• MVC & related
• Authentication & authorization
• Databases
• Documentation & translation

There is also a high-level look at what version 0.2 of the framework will contain and a return to the "post often" methodology they had before.

Vidyut Luther has posted a new item on his blog today that presents a situation he's been given concerning namespaces.

I've run into an issue, or rather a friend of mine has. He asked me for advice, I gave it to him, but I'm curious how others would do this. The problem is this:

Team A, has been working on some code for a few months, Team A has a class called "SomeClass". Team B, is an "outsourced" team, who is writing a SOAP interface to Team A's code. Somehow, due to whatever reasons, Team A and Team B developers didn't talk.

Team B also created a class and called it "SomeClass". These classes are in files called "Aclass.class.php" and "Bclass.class.php" . There are some files, that include both files.. obviously, you end up with a "cannot redeclare class" fatal error.

Vidyut's suggestion was to just to change the class names. Unfortunately, this might not work if there is no communication between the two parties - they cannot come to a compromise on the naming.

He question to the community is "How do you handle an issue of single namespace, or rather no namespace ?"

Vidyut Luther has posted a new item on his blog today that presents a situation he's been given concerning namespaces.

I've run into an issue, or rather a friend of mine has. He asked me for advice, I gave it to him, but I'm curious how others would do this. The problem is this:

Team A, has been working on some code for a few months, Team A has a class called "SomeClass". Team B, is an "outsourced" team, who is writing a SOAP interface to Team A's code. Somehow, due to whatever reasons, Team A and Team B developers didn't talk.

Team B also created a class and called it "SomeClass". These classes are in files called "Aclass.class.php" and "Bclass.class.php" . There are some files, that include both files.. obviously, you end up with a "cannot redeclare class" fatal error.

Vidyut's suggestion was to just to change the class names. Unfortunately, this might not work if there is no communication between the two parties - they cannot come to a compromise on the naming.

He question to the community is "How do you handle an issue of single namespace, or rather no namespace ?"