I'm a 19-year-old who has recently hit a bit of a rough spot in life, and the only real skill I have other than tending the cash register is programming. I've been programming for quite a while, although I've never taken more than small web design work in terms of paid jobs. I'm interested to know if with some touch-up and extra learning PHP is something that's realistic for a young person to be looking at for a career, or at least an interim step in life.

There's several different kinds of suggestions including:

• They may consider relocation as a viable option
• Learn MVC and related technologies
• Find a local meetup and network
• Learn about the most up to date techniques (namespacing, wriitng secure code, etc)
• Make a publicly available code repository with samples of your work
• Look for an open source project to contribute to

The reason why I'm here is that, on occasion, a person decides that it's time write Yet Another PHP Bashing Post. Typically, this is followed by a bunch of Posts Defending PHP. [...] Saying that PHP is horrible or great is no more useful than saying that a hammer is horrible or great (regardless of the number of claws it comes with). [...] The real question is whether PHP - or any other technology - is good for you.

He goes on to mention current successful projects that use PHP, but focuses on the people and the ideas that made them happen, not the language "behind the scenes". He also comments on what he thinks makes a good programmer (and one that has matured past the "X language is the best!" stance):

And this brings me to the crux of the matter: The trick to being a great programmer is to learn as much as you can about as many programming languages and techniques as you can. Eventually, you'll learn that any language is excellent at some things, good at others, and a poor choice for many others. It's all about the context, and finding the right tool for the job.

Every day I come across code that is insecure. Sometimes the code is so hilariously insecure that any 10 year old could break it. I've also gotten into discussions with people who should know better about their practices. It's very, how to put this, disheartening. It's sad that the average developer knows (and cares) so little about proper security practices. So, I've put together a simple pledge (or manifesto, if you'd like).

The pledge includes the ideas of data storage techniques, taking responsibility for user data, reusing existing/tested libraries instead of writing your own and being open to constantly learning. He elaborates on each point, giving a little context for each.

Are you a secure programmer? Do you want to be? Then take the pledge, and fight for the security of your applications. It's all of our responsibility, so do your part!

In this edition I talked with Chris Hartjes (@grmpyprogrammer), the co-organizer of the GTA PHP User Group (@gtaphp). Chris is a real Grumpy PHP Programmer! But grumpy in a very positive sense though. He focuses his effort in applying and transcending his best practice ideals with the codes he write. I would tag him as the "perfectionist programmer"; he will not hesitate to scrap his piece of work if he finds a fault or a room for improvement and start all over again with that "eye for perfection". In this interview, he will talk a bit about those coding best practices fortunately.

Chris answers questions about:

• His history with PHP
• His favorite PHP book
• What tools he uses (IDE)
• His description of the PHP community
• His favorite conference

You can read the answers to these and more in the full interview.

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.