On the Zend Framework blog there's an update from Gary Hockin about some GitHub project-level changes that will be happening soon. He'll be doing some housekeeping on the current list of open issues in the main zf2 repository.

I want to make you aware of some upcoming changes to the issues that are currently logged in GitHub. We currently have 426 open issues that are logged against the (now) meta zf2 repository. The vast majority of these are now in the wrong place, as we've split our once monolithic single repository into the many single component repositories. These issues should be moved from the zf2 repository to the correct component that the issue relates to.

He's closed some issues in preparation and tagged others with a "To Be Closed" tag for later handling. By early May all issues tagged "To Be Closed" will be finished out and/or moved to the correct locations. This will leave the project with around 100 issues to manage and to move to the right locations.

Keith Casey has a new post to his blog today sharing some thoughts similar to those he gave in the closing remarks at this year's php|tek conference that recently happened in Chicago.

A few weeks ago at php|tek, I was lucky enough to deliver the Closing Remarks. Well.. it was less "lucky" and more of a "wait.. you haven't done anything this week, make yourself useful." So after a week of sessions, midnight hackathons, midnight unconference, tornados, power outages, a red carpet entrance, a family reunion, I got the final word.. Of course, this recap is not verbatim. I did the original presentation from a basic outline and have since had a few weeks to ponder it.

He mentions a few of the points that were highlights of the remarks including a few things developers should consider and act on when wanting to push them and their skills to the next level - showing up to conferences and events, listen and learn while there and do more than just sit in your chair - get involved. Once you've hit that point you can then be a mentor to those following the same path and try to "not be an ass" to those in the community around you.

Brian Moon points out a (sometimes annoying) habit of PHP when it comes to newlines - it drops them after the closing tag.

Have you ever noticed that PHP eats the newlines after a closing PHP tag? Not sure what I mean? There is lots on Google about it. [...] So, why does PHP do this? Well, you have to go back 11 years. PHP 3 was emerging. I was just starting to use it for Phorum at the time. There were two reasons.

The first reason was the it, at least in the minds of the developers of the language, "removed all traces of PHP" from the script without any training newlines to show for it. The second case was a bit more valid - because lots of editors at the time required newlines at the end of every line of code. This caused loads of trouble tracking down things like the infamous "Headers already sent" issues (pre-output buffering).