Gennady Feldman has posted two comments/suggestions about things he thinks could be done to improve the PEAR and PECL websites:

So I attended the PEAR2 presentation and had a chance to bug the guys behind PEAR/PECL. There's definitely exciting stuff happening and they are pushing forward with many exciting ideas.

His suggestions include updates to documentation, crrection broken parts of the API and a "Package News" feature with the ability to leave comments on them.

He's also posted another suggestion - the ability of the authors of the project to provide other links besides the ones just for the project (external documentation, tutorials, etc)

Lukas Smith got a chance to catch up with Rasmus Lerdorf (and others in #php.pecl) and "talk shop" about topics including handling large libraries and maxclients settings.

In this first post I will provide a link and some commentary on Rasmus's points regarding Doctrine (note I left independent chatter in the log in order to not have any chance of me filtering the content, but there is very little of that so I hope the discussion is still easy enough to follow).

Following up on this article from Akash Mehta, Bryan has posted five more suggestions he has to help make you a better PHP developer.

I thought all of Akash's suggestions were good but a little broad and seemed to involve a lot of reading. And while any budding developer will jump at the chance to expand their burgeoning technical library, I thought there were a couple of items we could add to his list.

The recommendations that made his list are

• Start a project that other people (developers and end users) will use.
• Learn another language.
• Teach someone PHP.
• Ask for suggestions not solutions.
• Use what you read.

I'm particularly a fan of the third one (teaching) - not only does it spread PHP out even more through the masses, but it can really test you on your knowledge (some of those "how do I.." questions can get a bit complex, even from beginners).

For a lot of developers, just finding good resources to look for a job is half the challenge. Sure, there's the big guys, but what if you need something a little more focused? The Developer Tutorials blog has a few suggestions you can try.

Many position-based boards are full of employers who don't understand the value of quality code. [...] There are really only two ways to find a decent PHP job, then: find freelance projects from clients that will pay for your expertise, or get a full time job. Here are some good destinations for each.

Their suggestions are broken up into two different categories - freelance or waged. The freelance list includes Elance and PHP-Freelancers while their waged list includes the Zend Job Board and the PHPJobs.com website.

Richard Thomas has shared some suggestions on improving the performance and use of PHP's built-in sessions in your site:

If your developing a new website and want to ensure its scalable sessions can be a sticking point. [...] There are a couple problems you may run into with this approach and most database driven examples you may use to base your session code off.

These problems can pretty much be summarized into a single sentence: Every single page load your database is going to be hit at least 2 times, first to read the session data and then session to rewrite all that data.

He includes three suggestions:

• Hash your data when pulled from the DB, if your data hasn't changed don't bother updating
• Figure out what your margin of error is for how long a session has been inactive (don't update if you don't need to)
• Use memcache in conjunction with your database, Check memcache first if its there, if it is use memcache, if its not pull from DB and shove into memcache when you DO update your data update memcache at the same time.

A bit fed up with some of the developers out there, Pierre has posted some symptoms and suggestions for those who don't "do their homework" before opening their mouth (or keyboards).

It becomes more than annoying to read slides or blog posts from some prominent member of the PHP Community about things they do not know. It is for a warning. It is not aimed to be diplomatic or to target any particular person or group of persons (even if some are obvious ;-). But one thing is sure, we have to worry about what we say about other projects or other developers work.

He asks questions of these sorts of people (like "why do you talk about something but has little/no clue about it?" or "why do you wait the day of the release to talk about possible issues?") and some solutions to these sorts of problems:

• learn what you are talking about and keep your knowledge up to date (especially for new features, they change a lot during the first year)
• Your talks or blogs are no bug report, mail php-internal, report a bug or ping the devs on IRC (idle is also not productive)
• Don't wait the release day to make your own promotion on our backs. All PHP releases may introduce new issues, that's why we have RC.