Programming Tip: Assume Your Users are Idiots

Posted by Nessa | Posted in uncategorized | Posted on 30-05-2010


Any programmer knows the golden rule of programming – no matter how well you’ve coded an application, there’s always going to be something wrong with it. I’ve done enough development work to have a lasting suspicion that if there’s a bug or hole to be found, someone will stumble upon it and rub it in your face.

Here’s an interesting fact:

There’s no such thing as a bug-free application.

No amount of poking, prodding, testing, slurping, or caressing is going to find every possible fault that can exist in an application. Somewhere along the line, one of your users is going to trigger a problem and cause you to spend a few hours patching code.  It’s like idiot-proofing a microwave – you can’t reasonably predict every possible thing that a user can do, you just do what you can and hope for the best.

The good thing about these idiots is that they make us better programmers.  To be a better programmer, you have to think like an idiot and apply some basic principles:

1. Validation

Check and maybe even double-check all types of input and assume the worst. Sure, maybe that user didn’t know that Sex referred to gender, but you should have thought of that.  Always take into account blank, malformed, incorrect, malicious, and duplicate data.

2. Default Actions

Any time you use conditionals, always combine validation with a default action, in case something unexpected happens. Do you know what your application is going to do if a specified condition isn’t met?

3. User behavior

Some people do things you don’t want them to, but you have to be ready for it anyways.  Does your application work correctly if people hit the “back” or “refresh” buttons? Is it going to cause a problem if someone bypasses your lightbox and opens a link in a new tab instead? Or bookmarks a page that was meant to be accessed from a login screen?

4. Acceptance

Accept the fact that no matter what advice I give, you’re still never going to make it perfect.

And don’t forget – testing, testing, testing. While some people I deal with like to believe that I don’t actually test anything, I do – I just also know the golden rule of programming and that there’s no way around it.  Testing is an ongoing process and requires both automated and manual work. Don’t knowingly leave a bug or security flaw in place and assume it will go unnoticed – trust me, it won’t.  If there’s one thing idiots are good at, it’s making you look like an idiot.

ReviewMe Had an Oopsie

Posted by Nessa | Posted in uncategorized | Posted on 29-05-2010


There’s a common understanding in the developer community that when you’re testing code, don’t do it on a live site. And if you do, make sure it’s transparent to the user.  This faux pas tends to be unforgivable when you’re a major review site getting thousands of hits per day.

I hope I don’t get sued for this.

The other night I was logged into my ReviewMe account to add one of my sites, and upon addition some code popped up that probably shouldn’t have:

It looks like someone was doing some testing and was echoing out some post variables as an array, and forgot to remove it.  This goes to show: don’t test this kind of stuff on a live site where your users will be able to see it.

PHP 5.3: Why We’re All Late to the Party

Posted by Nessa | Posted in uncategorized | Posted on 27-05-2010


It’s been almost a year since the PHP 5.3 branch was released to the PHP community, and yet we’re all still in the shadow of PHP 5.2.  If you’re just a faithful customer wondering why your host isn’t getting with the times, I’ll tell you exactly why: We don’t stock enough diapers to keep up with that ish.

Let me talk about you, the common website owner, that runs a simple Drupal or WordPress site.  You didn’t sign up with your host to go around in circles over compatibility problems that could have been avoided by your host doing a little research. As a programmer, I would hold it to any site owner to check their site’s requirements and the offerings of their host before they unnecessarily waste a lot of time and money, but as a system administrator I frown upon shared hosting providers offering software with known compatibility issues just to be able to advertise as the “latest and greatest”. The latest isn’t always the greatest, and it won’t be until the community catches up with what the greatest has to offer.

I’ve had numerous discussions with my superiors about whether to upgrade to PHP 5.3, and the end result is pretty much the same – we’re just not ready. And neither are our customers, or the developers of the applications they use.  And trust me – this is normal. We all went through the same thing when PHP 4.2 came out, and again with PHP 5, and again with PHP 5.2.  That being said, this is why all the good hosts are now also holding off jumping on the PHP 5.3 bandwagon:

  • Lack of compatibility:  Many open source applications and frameworks (such as Drupal, Joomla, Magento, and even parts of WordPress) are not fully compatible with PHP 5.3 yet
  • No Zend Optimizer or Zend Guard support
  • It’s not required for PCI compliance yet, which is one of the main reasons why hosts upgrade PHP on their servers

PHP 5.3 does have a lot of new features and functions to offer, and it will eventually wiggle its way into mainstream hosting –  it’s just not ready for the shared hosting population yet until everyone else catches up.  Most hosts (including IMH) will still offer PHP 5.3 as an optional upgrade for customers on VPS or Dedicated servers, or as an optional move to a server that has that version. In the meantime, start upgrading your applications and keep tabs on your softwares’ developers to find out when php 5.3 support will be available.  PHP 5.2 will likely become obscure near the end of 2010 or early 2011 in favor of 5.3, and you should be ready when it is.

Command Line PHP: Part 3

Posted by Nessa | Posted in uncategorized | Posted on 25-05-2010


This is part third and final part in my PHP command line tutorial series. If you didn’t see parts 1 and 2:

Command Line PHP: Part 1

Command Line PHP: Part 2

Command Line PHP: Part 2

Posted by Nessa | Posted in uncategorized | Posted on 21-05-2010


This post is continuing on my three-part series on command line PHP programming. Missed part one? It’s right behind you. This part will go over command execution and processes.

Command Line PHP – Part 1

Posted by Nessa | Posted in uncategorized | Posted on 18-05-2010


PHP isn’t just for websites anymore. In fact, almost every script I’ve written to perform server-side functions is either written in bash or PHP, rather than Perl or Python as preferred by my colleagues. It’s a common belief that PHP isn’t suited for CLI programming since it’s mainly used in web applications, but PHP has over a hundred functions specifically intended for system management.

These kinds of posts can be rather lengthy, so I’m making this into a series with three parts.  Part 1 will go over the basic filesystem functions. You can find a complete listing here, but I’ll just go over a few of the more important and common ones.

You do not have sufficient permissions to access this page

Posted by Nessa | Posted in uncategorized | Posted on 16-05-2010


This was a particularly annoying error message that was occurring for one of my legacy plugins that I refuse to get rid of. There are a lot of sites that indicate the problem is with a failed upgrade or misnamed database tables,but for me it was simply an issue with an old plugin and wasn’t happening anywhere else.

My fix was to edit the plugin file and change instances of admin_head to admin_menu . It’s apparently just a compatibility issue with newer WP versions.