An abject lesson in design

2009-01-04T20:24:28Z
Dave Pawson.  link
Home

An abject lesson in design

Some time back I wrote about Digitizing a photo album. Since then I've done one more set of photographs, and tweaked the process a little. Having done that I realised I'd broken it, so this last weekend I sat down and tried to figure out what was happening. The end to end processes uses bash scripting, some Python, a good mix of XSLT and ImageMagick for some graphics handling. It seemed to come together, but more along the lines of an experimental build. Bit by bit. Each task designed in isolation with scant regard for the rest of the chain. I'd made assumptions without realising it, taken some things for granted which I shouldn't have done. Simon St Laurence wrote recently about practicing for the trumpet and programming/coding. I'm beginning to think that this class of repetition is a good exercise in design. It's not until I had to dig into the code that:

  1. I realised some design weaknesses
  2. I realised what level of automation is possible (and what is not)
  3. I considered how best to integrate the parts into a whole
  4. I realised how weak (and inaccurate) the documentation was/is

Having the luxury of a total redesign, I didn't. What I did do is redefine what steps go where, removed a bad design decision, applied enough redirection to make it more generally applicable (yet to be proven). I'm left with an improperly documented process that is better but not yet optimised. I'm eyeing Xproc to see if I can take the lessons over there, but I'm unsure if some parts will fit as well as with a bash layer at the top.

As far as the documentation goes, that was quite revealing too. In searching for the problem, I sketched out the process steps a couple of times to get my head round it again. Only three major chunks, each carrying out about four steps, although with sufficient complexity to keep me scratching my head for the weekend. The problem is that between the three automated stages, there is sufficient manual editing required to stop it being a smooth run. I'm torn between having different shell scripts or simply suspending the shell script after launching emacs|Firefox whatever.

Either way, quite a good learning point. What lessons to take forward for the next glue job? Not thought out yet.

The initial problem was that I'm starting with family photographs, which vary in size from 3x4" up to A4. Scaling them caused the problems and I side stepped the real problem, generating an algorithm which would take in any image size (scanned that is) and return a scaling factor which would result in an image that would 'fill' to some extent, a normal screen. Suggested max? No idea in pixels, 1000x800? That would work with most screens, but leaves little room for titling and such like. Any suggestions for such an algorithm? My first approach looks something like

If x > y:
     mult=xmax
else:
     mult=y/ymax
resx=x*mult
resy=y*mult
if (resx > xmax):
   sf = xmax/resx
   resx=resx * sf
   resy=resy * sf
if (resy > ymax):
   sf = ymax/resy
   resx=resx * sf
   resy=resy * sf
return resx,resy

Where xmax and ymax are max allowed values in X and Y direction, sf is the scale factor to use. As yet untried.

Keywords: software

Comments (View)

Return to main index