reifying.post

   1 ;;;;;
   2 title: Reifying Hidden Code
   3 date: 2015-04-09 13:17:46
   4 format: md
   5 ;;;;;
   6
   7 The title sounds a bit too majestic too be true.  However the though just
   8 occured to me, that much of what I've been doing over the last months often
   9 involved taking "dev ops" code, e.g. configuration code that lives in the
  10 deployment scripts, and putting it into a reusable format, i.e. an actual
  11 (Python) module.
  12
  13 That usually happens because what was once a depencency for an application (or
  14 service if you like), is now needed to be accessible from (Python) code for
  15 testing purposes, or because the setup routine isn't actually just setup any
  16 more, but happens more regularly as part of the application cycle.
  17
  18 Of course doing this has some major downsides, as the way scripts are written,
  19 using a specific library to access remote hosts, without much error handling,
  20 is fundamentally different from how a application code works, that is usually
  21 with a more powerful database interface, without any shell scripting underlying
  22 the commands (which will instead be replaced by "native" file manipulation
  23 commands) and with more proper data structures.
  24
  25 That leaves me with some real annoying busy work just to transform code from
  26 one way of writing it to another.  Maybe the thing to take away here is that
  27 configuration code isn't and application code will sooner or later become
  28 library code as well -- aka. build everything as reusable modules.  This of
  29 course means that using certain configuration (dev ops) frameworks is
  30 prohibited, as they work from the outside in, e.g. by providing a wrapper
  31 application (for Fabric that would be `fab`) that invokes "tasks" written in a
  32 certain way.
  33
  34 Properly done, that would mean that configuration code would be a wrapper so
  35 thin that the actual code could still be reused from application code and
  36 different projects later on.  The difference between configuration and business
  37 logic would then be more of a distinction between where code is used, not how
  38 and which framework it was written against.