Device experiment view

<p><img alt="" src="device_experiment_view.png" /></p> <p>When working with <a class="wikilink" href="/instrumentation_software/">instrumentation software</a>, it is important to identify patterns that repeat in order to abstract them and ease the introduction of new people to the world of <a class="wikilink" href="/hardware_control/">Hardware Control</a>. For a very long time, I have been proposing the use of the <a class="wikilink" href="/model_view_controller/">model view controller</a> as a pattern for the programs I was designing. </p> <p>However, two things became apparent: I was hardly ever programming the <em>controller</em>. Since more and more companies start providing drivers compatible with Python, I started relying on it rather than developing it myself. </p> <p>The second, is that I always had two types of models: the <em>experiment</em> and the <em>device</em> model. And the use case became clear: One experiment uses many devices to achieve the expected goal. </p> <p>Therefore, I think representing software in a new pattern is very useful: </p> <p>Devices represent the interface with the real world. They acquire data, but they are also in charge of storing, processing, etc. </p> <p>The experiment is responsible for executing the measurement. Checking the devices, triggering them, etc. The experiment is where the procedural approach to performing an experiment is expressed. </p> <p>Finally, the view is the interface that gets presented to the user. In this case, there are many different use-cases: A GUI can be useful for <em>some</em> contexts, while for others a command-line-interface will be enough. Another interesting pattern to explore is the use of Jupyter Notebooks, where code can be dynamically altered (for instance, it is possible to subclass a device and change one of its methods, etc.)</p> <p>I believe the <strong>device-experiment-view</strong> better represents the flow in which I have been developing software for the past few years, especially since I stopped caring so much about building my own drivers in Python.</p>