Learning things the hard way

These are some things I learned the hard way over the past few weeks. Ignore at your peril!

  • When your setup requires a different database layout (meaning differently named and/or organized databases and/or servers) for development than for live deployment, you would do well to try to mimick the live layout in your development environment before beginning. (This one hurt, bad.) In fact, when you find a need for your application to test for current environment (development vs production), you may want to be extra certain that you really need to set up your development structure that differently.
  • When your test & deployment environment calls for a server external to the existing systems and database servers, make sure that you:
    1. Have a clear understanding of what packages/versions that server will need.
    2. Have a clear understanding of how long it will take to get the hardware in place.
    3. Have a working copy in a VM on the same OS that the server will be deployed on before you say ok to anything.
    4. Ask, beg, plead, whatever, for a copy of that server (even on desktop hardware) to be set up for the testing. If you cannot test against real machines in a real environment for any kind of multi-server deployment, all bets are off. (Um, yeah, again, ouch.)
  • While the occasional 12+ hour day for developers is inevitable, too many of them in a row will result in more mistakes and coding errors of the most simplistic sort.
  • When you discover that you need to add functionality to an integral part of the software (like, say, the primary db connection class) do everything within your power to ensure that it still “works the same” – that is, add any modifications in such a way that they do not break existing code. This is not always easy to tell, but usually a simple trip around the application will tell you quickly if you have broken something as basic as this. (No, I didn’t break it, at least not anywhere other than locally. I actually took this step, many times and saved myself great embarrassment.)
  • Finally, when switching between languages (PHP, Java, Bash, Javascript, etc etc) you may find yourself looking at code that should work, but doesn’t. Chaining calls in PHP seems to be iffy at best. For example:
    • This does not work, although it seems it should. The $db is an instance of a legacy database connection class used for the project, do_query returns an array of results, and do_query with a second argument sets the value of the field named as the key for each row:list($account) = array_keys($db->do_query(“SELECT account_id FROM reports WHERE store_db=’$store’ LIMIT 1”, ‘account_id’));
    • while this does, using the same class and method:$data = $db->do_query(“SELECT account_id FROM reports WHERE store_db=’$store’ LIMIT 1”, ‘account_id’);
      list($account) = array_keys($data);
      // this also works:
      // $account = $data[0][‘account_id’];
    • Really, sometimes an extra line is worth not having the headache.

One Response so far

  1. 1

    Aaron Saray said,

    August 28, 2008 @ 4:59 pm

    I completely agree with your note there on the chaining of php statements. I would also add on to that – that chaining items like that disallows the checking of the return types before putting them into the next function. For example, if your $db->do_query() were to return NULL, you will generate E_NOTICE errors throughout the rest of that line of code. In your second example, you could check to make sure that $data was at least an array (Now a REALLY cool class would always return an empty array and not NULL – heh.)

    Keep up the good summations.

Comment RSS