Frustrated by the trouble he's having finding a really good PHP developer to fill a few positions, has posted about this process he's been going through - the good, the bad and the downright ugly - of trying to find those right, qualified folks.

During the last six month or so, I've been looking to hire a PHP programmer for at least three companies. I have spoken to quite a few people on the phone, reviewed a bunch of resumes, and even interviewed a few. Out of all those candidates I recommended to hire exactly zero.

Some of the "roadbumps" he experienced along the way include the interviewees inability to write down code without a computer and them giving either the wrong or no answers to simple, common knowledge computing questions. So, he came up with a list of what he calls the "roots of the problem". Included in the list are things like:

• PHP is an ugly language
• PHP is rich with secondary reasons
• PHP is getting mature
• PHP avoidance

Also be sure to check out this response from Nick Jenkins to Leonid's post.

UPDATE: Leonid has also posted a follow-up post with a few corrections and clarifications of the original post.

The CodeUtopia blog asks the online community for their opinion - what do you think of PHP as a first language?

Sometimes I've seen people say PHP is a bad first language, because it teaches bad programming habits. But is this actually true at all? Often those who say that don't really like PHP themselves either, many times because of equally untrue reasons.

They argue both sides of the situation, mentioning what could make for a good first language, why PHP is a "nearly perfect" fit for it and some arguing points for the other side as to why PHP isn't the best option.

A little while back, Alan Knowles wondered something that I'm sure has crosses the mind of every PHP developer out there, especially when they came across a particularly bad chunk of code - some people should need to apply for a license before releasing their PHP code out into the wild.

Unlike most of the reviews you get, I was specifically looking at code quality [of the CMSs]. not fuzzy does it look nice!

He looks at a whole list of them including: Tanslucis, Siteman, Pivot, jaf-cms, Guppy, Doop and CutePHP. Unfortunately, most of the news is bad - between badly structured code and mixes of HTML and PHP, there was almost nothing good in any of them.

As Cal Evans and others in the PHP community have pointed out, there's a post on Tim Bray's blog (of Sun Microsystems) with his prediction for PHP for the upcoming year:

The short version: PHP will remain popular but its growth will slow, as people get nervous about its maintainability and security stories.

He does mention the two different stances of this statement - the good side (with low entry level, good applications and speed) and the stance he seems to believe in more - that there are just things about PHP and how its handled that could cause major issues down the line.

Be sure to check out the comments for community views on both sides of the story too.

Rich Zygler asks in one of his recent blog posts, if Microsoft purchasing a 240 million dollar chunk of Facebook is a good thing for the language it's written in - PHP.

Microsoft is buying a piece of Facebook. What do we all think this means for PHP since Facebook is one of the "web 2.0" leaders built on PHP? The way I see it, [there] are [six] options.

Among the possible outcomes he lists are things like Microsoft rewriting the site, Facebook continues as it is or (next to impossible) Microsoft sees the error of its ways and fully embraces open source.

In light of the massive amounts of PHP frameworks out there, Laura Thomson has posed the question "Do all frameworks suck?"

Choosing a framework to implement your web app is a trade off like any other design decision. Let's focus in on specifics and talk about what the trade off is that you make when you choose a framework. Specifically, I'm talking about MVC frameworks in PHP.

She looks at both sides mentioning the good (code organization, encourages secure coding) and the bad (MVC is defined differently by different people, "More Than One Way to Do It", code bloat). In the end, her recommendation is to look at what you're trying to accomplish and decide first if a framework is for you and your app and, of it is, select the right one for the job.

On his blog today, Stoyan points out a topic he's started over on the OpenSourceCommunity.org site - What do you think makes a good CMS?.

This year's Packt Publishing awards for the best Open Source CMS are on their way, starting middle of July. I've been selected as a judge in the PHP CMS category. [...] How can one judge something as diverse and liquid as a CMS? Content management comes in all different shapes, some systems focus on solving some problems and they do a better job than another CMS that mainly tackles different types of problems.

He shares the experiences he's had with CMS and companies that have rolled their own in the past as well as a small list of things that he's thinking about making "the standard" for the CMSes to be judged by. Also included is a lengthy list of requirements that he sees that need to be included for any decent CMS to move to the next level.

On the SitePoint PHP blog today, Kevin Yank shares his thoughts in the form of a list for what makes for "good" and "bad" PHP code.

When interviewing a PHP developer candidate for a job at SitePoint, there is one question that I almost always ask, because their answer tells me so much about the kind of programmer they are. Here's the question: "In your mind, what are the differences between good PHP code and bad PHP code?"

Among the items on the list for the good side are things like: structure, consistency, security, and portability. He gives a bit of example code that shows the three levels of "goodness" in a script (using $_GET variables).

In a note submitted by the folks over at PHPClasses.org, there's details on a change in their book review section. It's no longer just limited to the reviewers the site picks out. Instead, anyone can submit a book review to the site on their choice of PHP book.

Writing books often does not pay enough to compensate the time and skill it takes. Many authors write one book and then move on working on paid consulting as it often pays much better. But writing good books also gets authors good reputation.

The general idea of this effort is to promote more good PHP books thus encouraging more authors out there to get up and get out and write their own quality resources.

In her new blog post today, Ligaya Turmelle has a mini-review/listing of her look into the editor offered by NuSphere - PHPed.

I am normally a vim user when I code but I decided to pop my head out of my cubicle and try something new on the editor front. So I decided to check out NuSphere.

She breaks it out into the two lists - what she likes and what she doesn't like. Included in the positives list were things like an easy learning curve, built in CVS support, and its many customizable features. On the bad list, there were things like inconsistent syntax highlighting, irritation with "code insight" feature, and not having the option to use Firefox as the embedded browser.