For a PHP developer, asynchronicity is the most puzzling aspect of the Node.js runtime. It's simply a new way to write programs. And once you pass the first learning steps, event-driven programming opens a world of possibilities PHP programmers would never dream of. I'll try to explain you how it works, but first, let's talk about pasta.

In his "pasta" example, he shows how a typical PHP application would make a "Pan" object, call a "warm" action, "add olive oil", etc. All of this happens in sequence, though and takes 29 "minutes" to complete. To help things along, he implements an "EventLoop" class that handles tracking the timing and includes two methods to execute callbacks and delayed methods. He expands on this example with asynchronous objects and method calls to handle multiple things at once. He relates this to what Node.js offers - a built in event handling system, an included EventLoop object and native blocking I/O operations.

On a previous post I had someone comment that they did not agree that the code implementation that was presented in the article was advanced (which was described in the title). They also claimed that I was not an advanced PHP programmer. This made me think. Not because my programming skill or knowledge was challenged. But because I'm not sure what makes code or a programmer "advanced".

He asks a few questions about the criteria for considering someone an "advanced programmer" including things like how fast or efficient they are, how much they make or the conference(s) they've been to. He points out that, because "advanced" is such a relative term, it's hard to put a finger on it. Being this hard to define (and mostly worthless even if it is) he suggests an alternative to trying to figure it out:

Instead of throwing around general terms in labeling code or other programmers, let's come together and figure out ways in improving code together. Practical applications.

Over the last few years I've become more familiar with multiple systems. I go over a few things that I've learned and the areas that I hope to improve upon over the next year.

His list of technology (including SVN, Drupal, WordPress and things like mailing list software and linux) serve as a good example to the wider world of developers out there to not become complacent in your skills and to be constantly learning. It doesn't have to be amazing, high level topics to be important - some of the best tools are the little things that help you work smarter and faster.

We all have our bad habits. In this article, we'll go over a list of bad practices that are worth examining, reevaluating, and correcting immediately.

In his list of things to avoid are suggestions like:

• not planning before coding
• opting for brevity over clarity
• no coding standards
• code duplication
• practicing "Not Invented Here" (NIH)
• not working on side projects to introduce yourself to new technology

In this podcast Mike talks a little bit about where he's come from, the history of PHP on the i and, what I think is most interesting, what it is that PHP developers can learn from the "old-school" RPG developers and vice versa.

Mike also talks about one of his favorite parts of his job - being able to go out and give talks and just being out in the communities (user groups, conferences, etc). You can listen to this interview via the in-page player for the post.

The Passionate Programmer contains a really insightful mix of advice, it manages to tell developers how to "be", without being preachy or patronising. There are some great stories in there, but mostly it talks about how to frame your thinking such that you can't help succeeding.

She notes that the pieces of advice in the book make for a good, engaging read and that can give the reader some directions to move to better themselves and their career. Her personal favorite section dealt with mentors/mentoring and how we as developers should constantly be both - always providing the "younger" generations the input they need while looking to the leaders of our communities to grow even more.

PHP is a very versatile programming language that can achieve the same objective in multiple ways. You can read more about that in my 'The Art of Programming' post. Below are a few tips I've picked up from past projects that can improve your code readability and maintainability and make you a neater, more organized PHP programmer.

There's lots of useful hints included - most of them are relatively basic, but they can even be helpful as reminders for those seasoned developers:

• Separate Configuration Files
• Use Indentation and Spacing
• Give your Variables Meaningful Names
• Use Ternary Operators
• Use Assignment Operators
• Use Objects instead of Functions
• Aim for Loose Coupling, Strong Cohesion

Today I've passed the Zend Framework Certification exam and with that I can finally close my new years resolution for 2010: doing 12 (tech related) exams in 2010. So I've seen a lot of exams, good ones and bad ones and I want to share with you my experience by creating a top-5 of must-have certifications for PHP programmers...

He suggests that certifications are a good way to prove your knowledge to others like customers or colleagues. He talks about the exams and certifications he's taken this year (20 of them) and some of the things he's learned along the way:

• Like unit-testing, mocking is everything.
• Failing is not a shame
• Don't do what I do, unless you know what you are doing.
• The top-5 of certifications that every PHP should have (according to me)

I have no "findings", no "conclusions", but I have some thoughts on my continuing goal to help bad/nominal PHP programmers become better PHP programmers.

He talks about the questions he asked in his previous post (like "is there a shortage of good programmers" and the requirements on memorizing) and some of the responses both for and against them. He stands by several of them, noting that, which a developer may not know the whole story, they should at least know enough.

One of the things I've also found a little interesting is that there is some resistance to standards. The argument goes; developers get better by different means and so having something set in stone to evaluate them is difficult, nigh impossible, to do

I can interview for certain (but by no means all) PHP positions because I know a fair about PHP and I believe that being smart but being an asshole does not make you a good PHPer. But not everyone who interviews knows that. And not only that, it is getting difficult to find good PHP developers. A lot of the good ones are being taken up by top companies, but even they are having trouble finding all the good developers they need.

He suggests coming up with something a bit more concrete than just this vague picture of what a "good PHP developer" is and how, even once that's defined, the quality of all developers should be raised to that level. He asks for some feedback on a few related questions like: is there really a shortage of good PHP developers or what are the significant topic areas that PHP developers should know well? Lease him some feedback on the post.