On NetTuts.com today they've posted a good primer for those that may have heard about the PSR standards that have been introduced to PHP but aren't quire sure what they are (or what they mean to you as a developer).

If you're an avid PHP developer, it's quite likely that you've come across the abbreviation, PSR, which stands for "PHP Standards Recommendation." At the time of this writing, there are four of them: PSR-0 to PSR-3. Let's take a look at what these are, and why you should care (and participate).

They start with a brief history of the standards, the PHP-FIG (Framework Interoperability Group) and where the idea for the PSRs came from. Then the article gets into the details of each:

• PSR-0: Autoloader Standard
• PSR-1: Basic Coding Standard
• PSR-2: Coding Style Guide
• PSR-3: Logger Interface

They also do a good job mentioning some of the criticism that's come with the standards and what sort of future there is including the creation of a standard for a HTTP messaging package.

Matt Frost has posted a few of this thoughts about effective code commenting and how it can help make your application easier to follow and maintain in the long run.

Code comments are strange things; they can be invaluable or they can make the code they're describing more confusing. They can be necessary, unnecessary, explanatory or muddled and some times they're neither; they just are. [...] Code comments have their place, don't get me wrong; but I don't usually come across good comments.

He talks some about the two cases for comments - when to use them (and do it effectively) and when not to use them (yes, there's a time for this too). He notes that, sometimes, if you feel like you need to comment excessively on your code, you might be doing it wrong - that there's a simpler, more understandable way.

The goal should always be to add value to a codebase, whether than be in the form of code, comments or documentation. Bad comments are just as bad as poorly written code and good comments can take poorly written code and make it more easily understandable.

Lorna Mitchell has a recent post to her blog with some handy tips for building an API for a smartphone app and some key points to focus on.

Yesterday, I saw this tweet: "@lornajane @nabeels tips on starting to write an API to interact with Smartphone App?" I have lots of advice for Olly (whom I know personally) but there's no way it will fit into a tweet! So here it is, in rather longer form :)

She touches on five different things to help you on the road to success:

• Be consistent
• Fail really really excellently
• Keep it tidy
• Recommendations for using JSON, a RPC format and understanding HTTP
• Some tools to help you in your development (debugging)

Brandon Savage has a new post to his blog with a few tips about doing well ("rocking") in your next job interview.

One of the things about the PHP field is that developers are highly sought after, and good developers are prized. While anyone can slap "PHP Developer" on their resume, most companies have gotten good at weeding out the pretenders from the real deal. This means that for a highly qualified developer, interviewing should be an easy step towards receiving an offer.

He's broken it up into a few different main points:

• Know your technical details thoroughly.
• Know the role of the person interviewing you.
• Be able to turn technical answers into non-technical answers, and vice versa.
• Learn how to be personable.
• Ask thought-provoking questions.

Each point comes with some thoughts on how to accomplish it and even points to two resources to help you on your way.

Volker Dusch has a new post reminding us about what the "unit" part of "unit testing" means - small chunks of testable parts in an application.

What does the word UNIT in unit testing stand for? Think of an answer and read on! So? Did you say "A method! Because we test methods!"? If so let me offer another perspective.

He suggests that, rather than about just the methods in the class, it's more about testing the "observable behaviors" of the class. That is, anything that you could publicly use the class for and have something happen. He gives examples of this shift in focus - calling setValue and evaluating the result versus just calling the class property itself (then calling the method). He also includes a bit about testing behaviors - what happens when my script does [this] and how does that effect the overall class.

When your tests fail but the class "still works" and you need to "fix the tests" the your tests are worth a lot less as they don't really give you that cozy safety net that they should provide you with.

In a quick new post today Kevin Schroeder asks his readers for feedback on what programming rules you should always follow in your development practices.

Earlier today, more for my own interest, I asked the question on Twitter "What programming rules should you ALWAYS follow, regardless of the scenario you're working in?" In other words, are there programming rules that you ALWAYS should follow. It doesn't matter if it's a script to copy a bunch of files for a one time migration or if you're building the next Facebook (DON'T try to build the next Facebook. You will fail miserably. Build something else). In other words, what was the purist of programming rules.

Responses he received ranged from the simple to slightly more complex including:

• Always comment your code
• Test your code
• Use source control
• "Think. Think again. Then write code"
• Use a good debugger to help track down problems
• Make effective use of logging/output

If you're currently looking for developers to fit the needs of your company but just can't seem to find a good fit, Stefan Koopmanschap has a good suggestion you might want to follow to be more effective in your search.

The PHP job market is booming. Lots of companies are looking for (good) developers, but these are hard to find. Lots of developers are looking for a (good) job, but these are equally hard to find. Wait, that sounds strange... but it's true.

He points out that he's seen several companies put other technologies besides their core technology in their ads (shame on them). He suggests that companies think about what tech you really work with and stick with that on the resume - don't try to pull in people with hype and buzzwords.

In this recent post to Reddit, a question is asked that's an issue for many developers testing the email sending abilities of their applications - how can it be tested effectively without outside services flagging you as a possible spammer.

So how do you guys do it? My current solution is to just output the email template HTML straight to the browser, but this doesn't always work. [...] I have considered sending emails through to my GMail, but I run my tests quite often and I'm not sure Google would be too happy with the amount I send. [...] I'm sure there's a better way I can handle this without modifying my code too much. Suggestions appreciated.

Suggestions from the comments include:

• a local SMTP/IMAP server configured to catch all emails being sent
• Changing the address based on an environment flag
• Using "@example.com"
• Saving the email as a .msg file for later review

There's also suggestions of other Mac or Windows software to mimic the mail server like smtp4dev and MockStmp

Greg Wilson has an interesting new post with some of the recommendations he made to a friend about recommended reading for a software engineering teacher so they could be one step ahead of their students.

I got mail yesterday from a former student of a friend of mine who has just been told that he has to teach an "Intro to Software Engineering" class this fall to a bunch of third-year undergraduates. He's not an SE guy-his background is operating systems-so he asked me what he should read to get one step ahead of his future students. As regular readers will know, I don't think much of most traditional software engineering books: I've never seen most of what's in them in the real world, and most of what I've needed to know hasn't been in them.

Included in his books of recommended reading are things like:

• Making Software (of which he's an author)
• Karl Fogel's Producing Open Source Software
• Working Effectively with Legacy Code (from Michael Feathers)
• The Architecture of Open Source Applications

Take a look at the full post for the rest of his list and a bit about why he chose each.

On the Zend Developer Zone today Cal Evans points out a podcast he thinks the software developers out there should give a listen to - SitePoint's latest "Six Pixels of Seperation" episode, How to Get Serious About Your Creativity.

The interview with Steven was Episode #251 of Six Pixels, "How to Get Serious About Your Creativity". I really enjoyed the episode and since creativity is a big part of software development, I think you will too.

As with most podcasts, you can either listen to the episode via an in-page player or you can download the mp3 to listen at your convenience.