Day: August 28, 2008

Development

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.
PHP

MVCFDH: One way to do MVC in PHP

Aaron Saray, over at 102Degrees, put up an interesting article today on MVCFDH, what he calls his way of building MVC architecture in PHP.

The short version is Model-View-Controller (which we are all familiar with) and adding the ‘Front Controller,’ ‘Dataobject’ and ‘Helper’ pieces. I won’t go into details here about what all this means, you can read it over there. The interesting thing is, without really having given it that kind of thought, that is pretty much the way I have always pieced together any kind of MVC work I have done, regardless of the language.

I think there might be a minor difference, though, at least in what we call things. I tend to think of them as ‘Dispatcher’ (don’t jump my case for calling it that, it works in my head!) rather than ‘Front Controller’, ‘Libs’ rather than ‘Helpers’ and ‘Dataobjects?’ I call them ‘Data Objects.’ :P