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

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.

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

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.

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.

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.

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.

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.

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.

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