Good code is maintainable, reusable, and testable. The following tips address how you and/or your development team can handle various coding tasks and how to keep everything as neat as possible. I will introduce you to some "best practices" that will help you write better code and help make you and your team happy and efficient.

Among the suggestions on the list, there's things like:

• Use a Coding Standard
• Refactor
• Use Meaningful Names
• Use Automated Build Tools
• Use a Testing Framework

Links are provided in several of the tips to other resources/tools that can provide you with more information about how to use it in your development.

The three posts in the series include tips like:

• Maintain debugging environment in your application
• Collect all output at one place , and output at one shot to the browser
• Set the correct character encoding for a mysql connection
• Do not gzip output in your application , make apache do that
• Don't check submit button value to check form submission
• Process arrays quickly with array_map
• Avoid direct SQL query , abstract it
• Never set error_reporting to 0
• Make a portable function for executing shell commands

Obviously, not all of these will apply in all situations, but they're an interesting list. Most will come with good explanations and code samples when appropriate.

I have been asked a few times on Twitter for some advice on how to use testing tools in order to test APIs. It just so happens that I am writing a bunch of tests for an API at work so perhaps this is a very timely blog post. [...] When you are testing an API you main concern is your ability to reproduce the results of a specific API call. If your API is such that repeating a call several times will give you different results, you do have some challenges on your hands.

He talks about functional testing, the "moving parts" they involve, using only known data sources and the creation of integration tests. He also mentions the testing of your local application to ensure it's handling (or transforming) the results of the API calls into something useful.

In the end, it doesn't really matter what tools you are using to test either your own APIs or ones that your application depends on. Be clear in your mind about what it is you are actually trying to accomplish and don't get create tests that provide very little value to your application.

From time to time I see bugs in the code and I start thinking "really? is it possible that no one noticed that bug before? am i the first person to see this code?". I thought it might be worth writing a little post on what helps me to deal with bugs and software quality in general and what are the common pitfalls in developer's thought process. Although it is not a very extensive post i hope it may inspire some developers to try new approaches.

Other topics he offers for consideration involve the fact that bugs will never fix themselves (they might disappear in a refactor though), that the bug is almost never in the language/data source's code and how automated (unit) testing can help to find new bugs before they're released to the users.

I've been playing around with Sublime Text (because of the awesome vim bindings) and was thinking about why do I always have to be logged into the remote server to do my work. Normally I connect using SSH, then attach to my tmux session and then fire up vim. This is okay but it lacks a certain elegance in it's approach. [...] What I'm chafing against is having to deal with multiple environments all the time to get my work done.

His ultimate goal is to be able to update and commit code without having to be logged into the remote server - essentially to replicate the local development experience regardless of the underlying technology. Have a suggestion or a method that's currently working for you? Leave him a comment!

If you've read the PHP|Architect Magazine - March 2011 Edition, you have surely enjoyed the nice article by Jason Austin (a PHP developer from Raleigh, NC) titled "Good PHP help is hard to find". Jason talks about 'the why' and 'the how' to distinguish yourself as a qualified PHP Professional from the crowd. And the way to do that is: "You have to build your geek cred". I think he did a brilliant job with the article.

Some of Khayrattee's suggestions include (each rated with a number of "cred points"):

• Get certified with recognised certifications like the Zend Certified Engineer program
• Start a PHP meetup group near you
• Sign up to attend PHP conferences around the world
• Blog about PHP { have a blog dedicated to it }

If you develop web apps, I encourage you to check out The Twelve-Factor App. This is an excellent resource for anyone building and deploying software-as-a-service. PHP has great support for many of the twelve-factors. I want to take a look at specifically how each factor may be applied to a PHP application.

Some of the points the Twelve-Factor App makes aren't entirely relevant to PHP (like "Backing Services") but Bradley gets into details on others, providing technology that can be used to fill the need.

Every now and then, I get asked by developers who are just getting started in the trade if I have any suggestions to help them out - favourite language, tips and tricks, and the like. None of these things matter, really, but there are a few things I wish I had known when I started out that have nothing to do with the mechanics of software development.

His tips each come with a paragraph or so of explanation:

• Be humble
• There is no magic
• Programming is a craft, not an art
• Software solves problems
• Code doesn't leave sawdust

A framework provides you with many of the common components required to develop a website - for example, database access, templating systems and authorization systems. [...] These frameworks are all open source - which means that anyone can review and suggest improvements to the code. Using a framework provides you with many benefits.

He suggests that a framework should be:

• Time-saving
• Reliable
• Adherent to well-structured patterns
• Fostering a good community
• Not too difficult to learn
• Well-performing (and easy to extend with something like caching)

I want to make sure that his request gets in front of lots of eyes, so I'm re-posting his request here (below). Jonathan included some links in his post so you can learn more about what the team is considering for the next release of the driver, but he didn't elaborate on "Buffered Queries".

They suggest a few features and ask for choices on which would be the most important to you as a developer - Always On support, SQL Server Serverless Express support, Buffered queries and LOB streaming support in PDO_SQLSRV. To give feedback, send an email to the address mentioned in the post or on twitter/their forums.