In this discussion on Reddit, there's talk about the user comments feature on the PHP.net site and the value they provide to the language and community.

The question, however, has always been "how useful is this feature really and does it bring more harm than good?". It's not that easy to answer since there are so many notes submitted by a wide range of users and some will likely go unnoticed while others seem to get undue attention due to their positioning near the top of the user-notes section of a particularly trafficked page.

The poster proposes a few things that could help make them a bit more effective (and useful overall) including voting on the note contents, flagging potential issues and sorting the notes based on popularity/age. He's put together a proof of concept as seen here with some of the new features.

Brandon Savage has a reminder for both those familiar with PHP and a warning for those new to the language - take the examples in the comments of the PHP.net with a grain of salt.

This morning, I was reviewing the weekly list of topics with the most comments throughout the PHP manual, and I stumbled upon the following code in the documentation for the date() function. This code is designed to tell you the day of the week for any valid date you give it. [...] I'm sure that this user put a lot of work and effort into this function. I'm sure they were excited to share it with the PHP community. I'm sure they thought they had stumbled on a solution to a problem that everyone needed to solve. I'm sure they had no idea that this code is a great example of using PHP precisely the wrong way.

His example, one that uses around 30 lines of code to do something that date could accomplish in one, is a perfect example of why blindly following the advice of others without thinking things through can be disastrous for your code. Do a bit of research before you cut and paste and remember that with someone else's code could come someone else's problems - think before you implement.

In this new post to his blog Adam Harvey shares his opinion on unmoderated notes dropped directly into the PHP manual - "they're bad, mkay?"

I've had a couple of whinges on IRC lately about why I'm not thrilled with having user notes in their current form in the PHP manual; we get entirely too many questions in ##php from people who've copied code out of a note and are then annoyed when it turns out the code is wrong, broken, horrible, or all of the above.

His gives an example (one of many currently in the manual) that shows a round-about way of getting a date string that could be done better in a single "format()" function call on a DateTime object.

I don't know what the answer is - moderation has its own problems to do with workload, as PEAR can attest - but a system that's letting that go up as recommended practice (and stay up for a month) has to be looked at.

As Andrei Zmievski points out, the notes from the PHP Developers Meeting have been posted to the php.net wiki.

Taking advantage of php|tek bringing a lot of people together, we had a PHP developers meeting over 2 days before the conference. Day 1 was dedicated to technical issues in PHP 5 and 6, and day 2 was spent discussing potential features, migration issues, current roadblocks, etc.

The notes cover PHP versions 5.3, a possible 5.4 and looks forward to 6.0. There's some interesting stuff in there, so read over it if you get a chance.

Jamie Hemmett has a few suggestions for local user groups out there on what to do and not to do to help make their group successful. Some of it was gathered from personal experience, other tips from the recent user group panel discussion from this year's ZendCon.

I just listened to the PHP User group Panel discussion from the Unconference session at ZendCon. While I listened I took some notes to try and help our Irish PHP Users Group be awesome like some of the other groups out there. I reckon the podcast and great tips it contains will help other User Groups out there too (not just PHP).

Some of the observations/comments she mentions include:

• Freelancing PHP developers may not feel like attending a group with "the competition"
• Several factors dissuade developers from attending (distance, confusing schedules, timing)
• Some ideas that groups out there could use to attract and keep more members
• Why the groups can make you a better developer
• and some sponsorship/promotion ideas to help grow and better the group

This is a great post packed with some good suggestions and observations. If you're involved at all in your local group (or would like to be) be sure to read it.

In a new post today, Ben Ramsey continues on from some previous thoughts on a different sort of method for using the Views in the Zend Framework. This time, he focuses on a more automated way implement them in the same way.

Just as views can be automated'"that is, you don't have to instantiate a Zend_View object; the controller does it all for you when you call $this->render() from any controller action'"you do not have to explicitly tell Zend_View where your helpers reside, as the manual suggests. Instead, place your helpers in a special "helpers" folder where the Zend_Controller_Action's initView() can find them.

He includes how the directory structure would be altered (the addition of the helpers folder) and how to name the helpers so they can be used in an application (Zend_View_Helper_*). Also, check out the post for some of his interesting thoughts on a recent visit of his to New York City.

Matthew Weier O'Phinney & Mike Naberezny, did a great job on this session. The talk went very smoothly, each of the speakers traded off on presenting the various sections.

The session also dealt with other collaboration topics (commincation using IM, wiki etc) however I with the PHP/Development issues.

Source Documentation

• PHPDoc is the defacto documentation standard, it can be parsed by PHPDocumentor and Doxygen
  
• Use @category and @package to manage your documentation
• Using PHPDoc allows all developers to immediately understand your code

Unit Testing

• Focusing on PHPUnit
• Test religiously
• Without tests, code is fragile and will regress - there is nothing to tell you when you break your code.
• You are not wasting time by creating tests, you're wasting time by peppering your code with var_dump() and trying to debug code manually.
• Learning to write good object oriented code that is testable takes practice and discipline. Learn to design for usability.
• Test-First methodology allows the tests to become the specification of code you are writing.
• Using Classes is not Object Oriented Design

Source Control

• Source control was on the benefits of using SVN to manage your code.
• Learn to use tagging and branching instead of committing everything to HEAD
  
• Trac is cool (I caught up on emails during this section - great wifi)
  

Deployment

• Never edit code on the server
• Check out tagged branches from your svc software
• Deploy to a staging server on your production server, test first then modify the symlink.
• Write acceptance and integration tests: http://manuals.rubyonrails.com/read/book/17)
• Monitor Health of Servers: http://www.plope.com/software/supervisor/
• Store schema of your database by committing the schema into your svc server - suggestion: http://www.mysqldiff.org/ and pre-commit hooks

Aaron Wormus has posted some great historical notes from back in 2002 looking at the state of PHP content management systems, most of which forked off of PHPNuke.

I was just browsing through my OLD advogato profile and thought I would link to these two posts (from mid 2002) which talk about one of the many CMSs which forked off the original PHPNuke code base.

Part one talks about the split between Postnuke and PHPNuke as well as what some of the differences are. Zope is also mentioned.

In part two, he notes a bit of a change in his thoughts on Postnuke (related to a change in the code for a templaing engine).

It's interesting to look back and see how far some projects have come...

Tiffany Brown, an attendee of this year's New York PHP Conference, took some notes during Ilia Alshanetsky's "Introduction to PDO" talk and is sharing them here.

It's a good summary of what the talk was about, and provides a few bits that weren't covered in the slides. If you're looking for a good place to start with researching PDO and its associated technologies, her list is a good place to start.

Each heading is accompanied by at least three points, clearly written as to include the most information. Some examples of the topics covered include: "Why PDO?", "Persistent Connections", "Prepared Statements", and "Retrieving information using PDO".

Andrei Zmievski has posted this new blog item today with links to his talks from the (just passed) php|Teck conference.

I was in Orlando this past week at the php|tek conference, put on by php|architect. I gave two presentations there: PHP 6 and Unicode and Regex Clinic. The slides for both of them are available on my Talks page.

He also mentions a great "impromptu event" the Thursday night of the conference - a dinner that ended with a speed beed drinking contest. And yes, ther's documented proof - check out these movies of it over on Sare Goleman's blog.