Jayson Maynard (recently taking over as the Editor-in-Chief of the Zend Developer Zone) has resolved to make the resource into a better place for PHP developers to find both the introductory content and information on more advanced topics. He talks about it in a recent post:

We will be rebuilding ZDZ from the ground up and in full public view of the community -- to act as a learning experience and a showcase for PHP best practices. [...] And the best way for it to be a showcase is for us to make all of the process of working on the infrastructure completely transparent; to make the artifacts (code, scripts, configuration, machine images) readily available and to allow contributions from the community.

There's some more specific topics he mentions that the site will cover including new features on articles and community interaction, a new infrastructure and new processes including things like Agile development, testing and deployment. In one of his first steps to better the site, however, he learned a lesson the hard way when he tried to upgrade a package and it brought the site to a grinding halt.

On NETTUTS.com today Burak Guzel has written up some good tips on how to make your code much more readable (and easier to maintain in the future. Not all of them are directly PHP related, but they are general enough to be applied in other places in your development.

Code readability is a universal subject in the world of computer programming. It's one of the first things we learn as developers. Readable and maintainable code is something to be proud of in a finished product. We can share it with others, contribute to other projects, and reuse code from applications we wrote months or even years ago.

Tips included in the list cover topics like:

• comments & documentation
• code grouping
• avoiding deep nesting
• using consistent temporary names
• using object-oriented code versus procedural
• effective refactoring

On the Zend Developer Zone the latest episode of the ZendCon Sessions has been posted - a recording of Matthew Weier O'Phinney and Mike Naberenzy's talk on best practices.

In this series we will be releasing regular sessions from ZendCon 2008 as we lead up to this year's ZendCon. This episode of The ZendCon Sessions was recorded live at ZendCon 2008 in Santa Clara, CA and features Mike Naberezny & Matthew Weier O'Phinney giving their tutorial: "Best Practices of PHP Development".

You can grab this latest episode in one of three ways - download the mp3 directly, listen via the in-page player or subscribe to the feed to get this and other great episodes delivered right to your desktop.

NETTUTS.com has posted thirty tips and best practices they believe every PHP developer should learn to make their applications (and development process) better.

PHP is the most widely-used language for programming on the web. Here are thirty best practices for beginners wanting to gain a firmer grasp of the fundamentals.

Items in the list include:

• Turn on Error Reporting
• Learn the DRY Approach
• Comment, Comment, Comment
• Never, Ever Trust Your Users
• Use Output Buffering
• Cache Database-Driven Pages
• Use Static File Caching Systems
• Keep Functions Outside of Loops

You can check out the full list here.

Following some of the "backlash" of Google posting their "performance tips" for PHP developers, Marco Tabini has written up a post with a suggestion of his own - stop teaching developers how to optimize their code and teach them how to code it better from the start.

In principle, I have nothing against micro-optimizations; I just think they're a waste of time - perhaps even more so because they take the focus away from the simple fact that it's a rare performance problem that is cause by the language: the problem, almost inevitably, resides either with the developer, or with an external system.

He explains that it's no so much about dropping them all together as it is starting from the beginning and teaching best practices and good use of standards and proper development practices. That's what we should be promoting, not things that might shave milliseconds off the total execution time.

On the SitePoint PHP blog today Troels Knak-Nielsen has posted some of his own thoughts about the performance tips that Google recently published for PHP.

The project includes an article on "PHP performance tips", which is bordering on being ridiculous. There are of course lots of blog posts with similar nonsense around the web, but since this is being endorsed by Google, it's fair to assume that people might take it at face value. That's unfortunate, as almost none of it is true. The PHP Team responded back with this message, wherein they refute the unfounded nonsense.

He notes that these practices aren't the best road to optimization and, depending on when they might be used, could be harmful to the development of the application. He also recommends XDebug if you really want to get to know where your application is struggling.

On the Ibuildings blog today there's a new article that looks at some best practices when it comes to estimating the time you can tell the customer a "more correct" timeline for when things will be ready.

Our estimating team spent two months thinking and discussing how software companies create estimates; we discussed what works and what doesn't. While the final document itself, along with the accompanying workbook, are available internally only, some of what was learned about the meta process of estimating may be interesting to others. Here are four Best Practices that came out of the process that we want to share with everyone.

He looks at "rightsizing" your estimations to fit the project, using only qualified people and constantly monitor your estimates and those doing the estimates (to ensure things are progressing as they should).

The estimate is what it is; if the amount is too high for the customer to accept then the price per hour can be adjusted or the feature set can be reduced. The number of hours that the project will take, however, should never be arbitrarily adjusted simply to meet a client's budget.

Thanks to an initial article from Brandon Savage the topic of code commenting has been floating around the PHP community and several members have taken the opportunity to express a few thoughts of their own:

• Brandon Savage's blog entry kicking off the discussion by noting that not commenting the code is the "accrual of technical debt".
• In his blog post Marco Tabini mostly agrees with Brandon's comments with one difference - he suggests that correct code doesn't need comments.
• Dagfinn Reiersol takes a more pragmatic approach to the issue and wants to see the code before making a decision on whether the comments are needed or not.
• Benjamin Eberlei reinforces this refactoring idea and suggests staying away from ambiguous names and unclear code practices.
• Richard Thomas notes that comments have their place but they don't need to be taken to either extreme.
• Rob Allen's opinions on Benjamin Eberlei's thoughts
• Brandon Savage's reply to all of the criticism he's recieved over his initial post

Posted any thoughts or comments of your own on the subject and do see them here? Let us know!

Jayson Minard has a new post to the Zend Developer Zone talking about scaling your PHP applications - some of the best practices to follow that can make it easier on you.

As a consultant, I deal with companies of all sizes. From new startups all the way up to large conglomerates. And I am constantly amazed at the old-world view to application scalability and performance. [...] They seem unaware that scalability has many facets, and some haunt them from the first draft of an architecture all the way through each milestone of coding. And many can be resolved without spending money on hardware or expensive software, or even without derailing the project schedule. Here are some of my scalability tips that should be applied at all times of a project's life.

His suggestions include:

• Build Your Technical Team From The Top Down
• Develop With Realistically Sized Data
• Design For A Single-Slice Cluster
• Your Transaction Database Is Not Your Reporting Database

and several more - check out the full post for explanations of these and the other great tips.

As a reminder, if you haven't gotten your entry in for the PHP Women article competition you only have a few days left - the contest ends on the evening of July 31st.

Not sure what the contest is about? Here's the rundown - to enter all you need to do is write up a best practices type of article and post it to the forum. That's it! You'll be entered to win fabulous prizes. The best two entries (as judged by the PHP Women themselves) will be awarded licenses for their very own copies of Zend Studio for Eclipse as well as one year subscriptions to Linux Pro Magazine. One of these two winners will also get a bonus prize - to have their submission featured on the Linux Pro Magazine's website.

So what are you waiting for? Write up your article and submit it - time is running out!