src/hooke/history.tex

   1 \section{History}
   2 \label{sec:hooke:history}
   3
   4 \Hooke\ was originally developed by \citet{sandal09} working at the
   5 University of Bologna.  It was actively developed until the paper came
   6 out, after which development became more sporadic.  This was partly
   7 because \Hooke\ worked well enough for the original authors and partly
   8 because some of the developers had graduated and moved on to other
   9 fields\footnote{
  10   Developer turnover may seem like a good reason to avoid open source
  11   software.  Why use something when its developers may not stay around
  12   to support it?  This argument may make sense if you're comparing
  13   open source and commercial packages, but it makes less sense if
  14   you're comparing existing open source packages to hypothetical
  15   in-house software.  Why \emph{not} use something, if it's free and
  16   already exists?  Figuring out someone else's software is often much
  17   more efficient than writing your own tool from scratch.
  18 }.
  19
  20 Before discovering \Hooke in 2010, I had been using a series of fairly
  21 site-specific scripts to post-process my unfolding data.  Excited by
  22 the existence of a published, open source post-processing framework, I
  23 dropped my scripts and started working on \Hooke.  Other open-source
  24 tools for post-processing SMFS data exist, but they are based on
  25 closed sorce tools\citep{kuhn05,aioanei11} and some are no longer
  26 being developed\citep{kuhn05}.  There are also some completely closed
  27 source tools such as \citetalias{punias}\citep{carl08} and JPK's
  28 \citetalias{force-robot}\citep{struckmeier08}.  Other work along this
  29 line exists, but source code is unavailable\citep{andreopoulos11}.
  30
  31 \Hooke\ supports a wide range of input file formats via \emph{drivers}
  32 (\cref{sec:hooke:drivers}, but when I began working on the project,
  33 there wasn't a clear interface between the drivers and processing
  34 \emph{plugins} (\cref{sec:hooke:plugins}).  I cleaned up this
  35 interface as part of a general refactoring, fixing a number of plugins
  36 that relied on obscure internals in particular driver code.  My
  37 refactoring removed these leaky abstractions, and now every analysis
  38 plugin works with every data driver.
  39
  40 \Hooke\ has been designed with an eye to modular flexibility, with a
  41 command line interface (CLI) and graphical user interface (GUI).
  42 However, as with drivers and plugins, the initial abstractions were
  43 leaky.  I added a generic argument interface for analysis plugins, and
  44 taught the interfaces how to handle the generic argument types
  45 (\cref{sec:hooke:ui}).  With this framework, new analysis plugins are
  46 automatically supported by both the CLI and the GUI.  As a side effect
  47 of this reorganization, the GUI (which had previously been a display
  48 for the CLI) became truly interactive.  The interactive portions of
  49 the GUI owe a large debt to earlier work by Rolf Schmidt et al.~from
  50 the Centre for NanoScience Research at Concordia University.
  51 %
  52 \nomenclature{CLI}{Command line interface.  A textual computing
  53   environtment, where the user controls execution by typing commands
  54   at a prompt (\cf~GUI).}
  55 \nomenclature{GUI}{Graphical user interface.  A graphical computing
  56   environment, where the user controls execution through primarily
  57   through mouse clicks and interactive menus and widgets (\cf~CLI).}