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.

Chris Jones has a new post to his OTN blog today pointing to two new articles by Eli White about managing malicious website use:

The techniques Eli covers will always be applicable in one form or another. They should be a fundamental part of any website architect's bag of tricks.

The first article focuses more on methods for preventing and dealing with the inevitable spamming that comes with running a larger site. Eli's experience at Digg has provided him with recommendations like creating hurdles for spammers to get past and evaluating the content (services like Defensio or Akismet are useful for this).

The second article talks about something a bit harder to deal with - when users "game the system" and find the loopholes. His recommendations to combat this sort of abuse include rate limiting, pattern matching and leaving "traps" by tracking user usage.

In this recent post to his blog John Congdon looks at some of his local user groups - Orlando and Daytona Beach in Florida - and how they handle their meetings and groups differently.

I am a member of two PHP user groups. Each one runs a little bit differently. I am looking for feedback from other people in other PHP user groups to find ways we may be able to make these better. he East Central Florida PHP User Group (Daytona Beach area) is new/restarting. [...] They seem to be more geared towards teaching new PHP developers. [...] The Orlando PHP User Group is quite different. They lean towards more presentation style meetings. Someone proposes a topic, and then someone volunteers to be the presenter.

He asks for comments from the community as a whole, wondering what he can do and what other groups in similar situations have done to help grow and improve their group. Comments on the post include suggestions of a more traditional approach over the mentoring aspect, a possible mixing of the styles and using tools likee Google Moderator to pick out the topics people are most interested in.

On the Web Development Blog Olaf helps to answer the question "why should you cache your PHP website?" with a few helpful tips, bits of code and pointers to other tools.

Most web servers are able to handle "normal" traffic and there are plenty of websites which doesn't have so much traffic. So maybe you ask yourself: Why should you cache your PHP powered website? The apache web server is able to serve many, many files at the same time, but all these files need to be static. A PHP script is parsed by the web server and next the generated HTML data is send to the client (web browser). While this happens the server need to use much more memory than by sending a file to a web client. Imagine what happens if you run/parse a page which is build with WordPress...

He points out the WordPress Super Cache plugin and mentions that there's lots of other tools out there in the form of plugins or things like eAccelerator. He even includes a simple custom caching script that grabs the contents of a remote file and caches it locally for twenty-four hours.

In you've been looking for a good, inspirational book to get you motivated as a programmer, Lorna Mitchell has a suggestion for you - The Passionate Programmer.

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.

On the SitePoint PHP blog today there's a new post from Craig Buckler looking at his top ten MySQL mistakes he as a PHP developer has made over time (and suggests a few things so they can keep from making them again).

database is a fundamental component for most web applications. If you're using PHP, you're probably using MySQL - an integral part of the LAMP stack. PHP is relatively easy and most new developers can write functional code within a few hours. However, building a solid, dependable database takes time and expertise. Here are 10 of the worst MySQL mistakes I've made (some apply to any language/database).

Some of the infamous mistakes that made the list include:

• Using PHP's mysql functions (instead of mysqli)
• Not sanitizing user input
• Not using UTF-8
• Not optimizing your queries
• Using * in SELECT queries