PSR-3 is a proposed standard (voting has finished, it should appear as an accepted standard when the PSR folks recover from too much Christmas turkey) describing a common logging interface for PHP frameworks. It's based on a small subsection of RFC 5424, which describes the Syslog standard, which is a very sensible choice. Sysadmins think in terms of Syslog levels, and they utterly hate dealing with loggers that don't map cleanly onto Syslog.

He briefly introduces the PSR and the format of the logger with some of the main methods it should implement and what they do. He talk gets into some of his critiques about the proposal, namely the method naming, the exception handling parameter and the proposed LogLevel constants.

When it comes to IDEs for working on PHP projects, I've been a relatively happy user of phpEclipse for several years. (Tried Zend Studio, but never managed to convince Zeev about how much it sucks). But when the guys in the office started switching over to Netbeans, I thought it would be interesting to take a look for myself.

He lists some of the positives including its good performance, code completion, code refactoring and some of the weaker points like the fact that it's a memory hog, it doesn't fit in with the OS X interface style, there's too many dialog boxes, etc. Overall, he likes it and found it pretty solid but may not make the switch just yet.

You'll be happy to know that were already working on many of your suggestions, Greg's post on the subject has some more details. I'll be sharing everyones comments with the rest of the PEAR group at our meeting on the 13th, so if anyone has a suggestion they haven't submitted yet thats your deadline.

The thing he's most excited about is the new mentoring program that will introduce new developers to the PEAR-ality of it all and get them involved with both the coding and the community.

One of the reasons was I wanted to upgrade Wordpress to 2.1 and I knew that it could take a while. I wanted to make sure there were no problems with plugins etc. But I've upgraded, and I would say that I haven't run into any troubles. Everything appears to work as it should.

He follows this up with some initial impressions of the new version, including the image upload system and the auto-save functionality (to ensure the least amount of data loss, just in case).

I've found that using the framework has significantly decreased my development time and really just given me cleaner, easier to maintain code. Of course, these are the goals of any framework. I do have a couple of issues I've come across and it is those I'd like to talk about.

The two issues he mentions were problems with the Zend_Db component (not everyone has just one primary key in their table) and caching problems with Zend_Cache (no unique lifetimes included).

Basically, what he [Ben Ramsey] conveyed to me (and his blog entry supports this) was not to use ext/filter or Zend_Filter at all. Nearly every second slide regarding functions of the ZF component or the extension contained remarks like "This doesn't work yet, it's a TODO", "this won't validate XY properly".

Of course, other community members (Pierre-Alain Joye and Ilia Alshanetsky) come back in the comments to refute Christopher's claims. They note that it's not the filter extension that has the problems, rather that some of the features are missing outside of the core filtering functionality.

The first day of the Zend/PHP Conference and Expo (the day of tutorials) was great. I sat in on Robert Richards's Advanced XML and Web Services and Marcus's and Sara's Extending PHP tutorials. I multi-tasked as best I could, catching up on some work while finishing my slides and listening to the presentations.

He comments on the talks he's attended (like Robert Richards' XML/Web services talk and the contents of the keynote - including the announcements of the collaborations with Microsoft, IBM, and the new advancements that Zend has made with their products.

Included in his thoughts are things like:

• "We're worth just as much as Java Programmers - but we get no respect - and we'll never get it"
• "You get what you pay for and, a little bit, clients are starting to understand this."
• "The difference between great PHP programmers and people who say they can do PHP is vastly more dramatic than you'd expect."

He agrees with Ben on just about everything, throwing in a comment there at the end about doing things for free:

Never, ever do anything for free*. I'd rather be paid $100 for $1,000 of work then take "options" or "stock" in lieu of cash. Clients never value what they get for free so you always have to charge them something. The "something" might not be large but it needs to be something. (ammended with an exception for charitable organizations/good causes)

The goal of the channel is to foster talks about topics such as design patterns, emerging PHP concepts, working on the bleeding edge, and new ways of doing old things. The channel is already set up and running smooth with users constantly around (though they might be just lurking), so come on over and join in.

It's been a long while since I worked on my PEAR package Services_Trackback, mainly because I was much too busy with work and university. Nevertheless I made up my mind about how to solve the problem of the so-called trackback spam.

Taking for granted, that the idea should work, there are 2 main questions to answer: "How can a sender of a trackback be identified?" and "If and how must the trackback standard be changed to support the identification?" For question #1 there is a simple answer (IMHO): PGP/GPG (further on referred to as GPG, for simplicity).

He suggests that since there is already a "trust relationship" inherent in the system, a PGP/GPG setup might be the most flexible, easy-to-use, constantly adapting method for preventing one of the banes of bloggers' existences...]]> Tue, 07 Feb 2006 06:53:10 -0600