It’s a typical story. Dan on a rescue mission, fixing a mess that some clown(s) left behind. PHP. No framework to speak of, riddled with SQL injection holes, a TABLE-based layout – and it doesn’t get any better from there.

For the love of all things holy, why do people have to do stuff like this:

$sql = "SELECT user_id,user_status FROM users WHERE user_name='$username' AND user_password='$p'";
$r = mysql_fetch_assoc(mysql_query($sql));

For the record, $username and $p were just grabbed right out of $_POST.

If you spent 30 seconds to write even a crappy inefficient function to actually do something intelligent, not only would you not have code that’s riddled with SQL injection vulnerabilities (did I mention that this snippet of joy came out of a 3112 line file without a SINGLE comment?), but it might actually make your life easier because your code won’t suck so much – and you can stop repeating yourself.

I’m no 1337 PHP h4×0r, but how about – oh, I don’t know – something like this:

function fetch_associative_array_safely( $array ){
  $sql = $array[0];
  foreach ($array as $index => $value) {
    $sql = str_replace( "?".$index, addslashes($value), $sql );
  }
  return mysql_fetch_assoc( mysql_query( $sql ) );
}

And just execute that bad boy like so:

$r = fetch_associative_array_safely( 
      array( "SELECT user_id, user_status FROM users WHERE user_name='?1' AND user_password='?2'", 
             $username, $p) );

It’s not overly elegant, beautiful or efficient. But I don’t think that really matters. It helps me to not repeat myself, and by golly – at least someone can’t drop tables from my database anymore. It’s a bit Rails-esque, at least as far the the conditions portion of ActiveRecord::Base.find(...).

What do you think? I haven’t done any significant PHP coding in years.

TOAD connected to Oracle Enterprise installed on Windows XP which is a Virtual Machine in Parallels running on my MacBook Pro. Cygwin for OpenSSH in order to access a remote Oracle database behind a firewall through a port-forwarded SSH tunnel.

Sheesh. Oracle. Pain.

In the process of setting up my new dev machine, I decided I was going to try using MacPorts to install all of the dev-type-software instead of installing into /usr/local.

James Duncan Davidson has a great overview article (that needs no further explaining from myself), titled Sandboxing Rails With MacPorts. Another similar article can be found here.

My problem is that I work on a lot of projects that use ImageMagick / RMagick, and that’s not discussed here.

No worries, I’ll install ‘em and give it a go:

sudo port intall ImageMagick
sudo gem install rmagick

CRAP! I don’t know what happens for you, but ImageMagick installs perfectly for me, and then RMagick craps out and dies something like this:

/opt/local/lib/ruby/gems/1.8/gems/rmagick-1.15.9/./lib/rvg/misc.rb:321:in `get_type_metrics': 
unable to read font `(null)' (Magick::ImageMagickError)
 from /opt/local/lib/ruby/gems/1.8/gems/rmagick-1.15.9/./lib/rvg/misc.rb:321:in `render'
 from /opt/local/lib/ruby/gems/1.8/gems/rmagick-1.15.9/./lib/rvg/misc.rb:696:in `text'

Now, for the solution I am going to give all credit to Jakob Skjerning, because I found the solution on his site after doing some Googling.

Do this instead:

sudo port install ImageMagick
sudo port install rb-rmagick

Done. Works. Thank goodness.

Right now, I’m finding it quite ironic that I’d been thinking about this all day yesterday, after trying to retroactively write some tests for a project that I came into rather late in the lifecycle.

Cedric just posted an entry with the exact same title, almost as if to taunt me with his infinite testing wisdom.

At about 200 times during the day yesterday, I came across a piece of code and thought to myself:

“How in the &$^%#@! am I going to write a test for this?!?”

So with any luck, Cedric will be able to get Hani to stop biling and whining about XML – and finish their testing book so I can go buy a copy.

In the meantime, it seems like the new question I am going to ask myself when designing a piece of code is something along the lines of:

“Sure, this design is elegant, but is it testable?”.

And as Cedric mentions, writing testable code is not necessarily writing code that is better designed.