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
  18   scratch\footnotemark{}.
  19 }\footnotetext{
  20   \ldots says the person who threw out the existing implementation and
  21   rewrote the control stack from scratch ;).  I'm ok with starting
  22   over if the existing project is not maintainable, but realize that
  23   you're probably biting off a lot of work.
  24 }.
  25
  26 Before discovering \Hooke in 2010, I had been using a series of fairly
  27 site-specific scripts to post-process my unfolding data.  Excited by
  28 the existence of a published, open source post-processing framework, I
  29 dropped my scripts and started working on \Hooke.  Other open-source
  30 tools for post-processing SMFS data exist, but they are based on
  31 closed sorce tools\citep{kuhn05,aioanei11} and some are no longer
  32 being developed\citep{kuhn05}.  There are also some completely closed
  33 source tools such as \citetalias{punias}\citep{carl08} and JPK's
  34 \citetalias{force-robot}\citep{struckmeier08}.  Other work along this
  35 line exists, but source code is unavailable\citep{andreopoulos11}.
  36
  37 \Hooke\ supports a wide range of input file formats via \emph{drivers}
  38 (\cref{sec:hooke:drivers}), but when I began working on the project,
  39 there wasn't a clear interface between the drivers and processing
  40 \emph{plugins} (\cref{sec:hooke:plugins}).  I cleaned up this
  41 interface as part of a general refactoring, fixing a number of plugins
  42 that relied on obscure internals in particular driver code.  My
  43 refactoring removed these leaky abstractions, and now every analysis
  44 plugin works with every data driver.
  45
  46 \Hooke\ has been designed with an eye to modular flexibility, with a
  47 command line interface (CLI) and graphical user interface (GUI).
  48 However, as with drivers and plugins, the initial abstractions were
  49 leaky.  I added a generic argument interface for analysis plugins, and
  50 taught the interfaces how to handle the generic argument types
  51 (\cref{sec:hooke:ui}).  With this framework, new analysis plugins are
  52 automatically supported by both the CLI and the GUI.  As a side effect
  53 of this reorganization, the GUI (which had previously been a display
  54 for the CLI) became truly interactive.  The interactive portions of
  55 the GUI owe a large debt to earlier work by Rolf Schmidt et al.~from
  56 the Centre for NanoScience Research at Concordia University.
  57 %
  58 \nomenclature{CLI}{Command line interface.  A textual computing
  59   environtment, where the user controls execution by typing commands
  60   at a prompt (\cf~GUI).}
  61 \nomenclature{GUI}{Graphical user interface.  A graphical computing
  62   environment, where the user controls execution through primarily
  63   through mouse clicks and interactive menus and widgets (\cf~CLI).}