Division of Labor
So we are moving toward the next coding laboratory and our objective here is to get you familiar with broad concepts.
DIY Constructionist Versus Practitioner
If you have a computer science background these labs will help you produce software in smaller, reusable quantities (components). If you follow the concepts and stick with the plan of producing software this way you will become a DIY practitioner. The lab code is MIT licensed so you can just incorporate it in your own projects.
If you come from some other background the idea is to help you become a more proficient laboratory informatics constructionist -- a DIY user that can take a set of components built according to a particular specification (this term will be explained later in this document) and put them together to build a working system. As a constructionist you are a bit more limited than the practitioner. Your best bet is to stick with the existing specification the components were released under and work mainly at the component level to build new functionality. This is different from a practitioner who could go further and delve deeper producing his/her own components, deviate from the specification in productive ways, and even go ahead and build brand new specifications altogether.
Future LIMSExpert.com posts may have have blocks of content that specifically target these groups and they will be prefaced and/or color-coded accordingly.
Where are the requirements?
So one question that practitioners and constructionists alike ask is, 'where are the requirements?' For the Series A labs the requirements look like this:
Build a software system that,
- 1) Allows for access to the system and its data in a secure and configurable way that differentiates between consumer needs (HTML versus JSON).
- 2) Permits for a core system that is almost entirely composed of registered components that could be produced by third parties.
- 3) Is itself released as a component that can be added to other projects.
Who and What Drives These Things
DIY components are typically sourced from some cross-section of existing solutions. The drivers behind them involve requests from a manufacturer/equipment-vendor or from other sources like system architects at various companies that utilize LIMS. In short, someone says, 'this is costing us too darn much...don't just tell us that there is a better way, show us.' A viable solution is then garnered from a wide-band search using computing principles and cost-based metrics. Oddly enough, the drivers of some of these projects run from professional curiosity to genuine need and they do come from organizations already in possession of a commercial LIMS for various reasons. Before now this process was done almost entirely using in-house developed solutions for prototyping/testing and results culminated into designs that targeted a particular company's standard LIMS solution. Releasing these practices here on LIMSExpert.com to the general public is a bit new and a learning process for everyone involved.
After perusing the architecture (and source code if available) of several representative examples the best among them is chosen for re-packaging. For example, the Series A lab is heavily influenced by the Open-LIMS architecture -- particularly its ability to map all requests to registered components and its separation between standard and Ajax-type requests.
Good parts of a chosen architecture are reorganized, tested, and packaged into definable/reusable parts and are released under a particular specification. The specification determines when and under what circumstances the component is known to, and therefore should, work. An easy way to understand this is to take a look at something we already know. Take this description of the function of the pancreas: "The pancreas is an important component of the digestive system. It manufactures and secretes digestive enzymes such as amylase, which digests starch. It also produces lipase, which breaks down fats, and trypsin, a protein processor." Requirements for DIY components are going to read a bit like this -- which would constitute the description of its operation -- but are accompanied by a specification. So for the given pancreas component description the specification would be in humans. Armed with that specification you immediately know that you are in for trouble if you try to use that component in some other species. (It might be possible but only at a practitioner level -- it should not be attempted by constructionists if you expect a high degree of success.) For our Series A component the specification involves an environment that, at a minimum, allows for communication over TCP/IP using HTTP and a data representation standard called JSON with some architectural constraints that are yet to be published.
The pace of labs will increase after Series A. These Series A labs are meant to introduce concepts and best practices (teach modular code formation/licensing/testing/release strategies). Once we are done with those we can refer back to Series A for the fundamentals and thereby skip them.
Before going too much further we have to clarify static data representation and do something to standardize its modification across releases. In our next lab we are going to employ a rather simple strategy for database creation and modification that allows a consumer of the system to add their own data definitions without tripping over the core system's definitions. Commercial LIMS have utilities for this but we will employ a simpler technique using only SQL commands.Go Back
Citation: Prep: LAB-A1-002. (2015). Retrieved Sun Apr 30 05:00:43 2017, from http://www.limsexpert.com/cgi-bin/bixchange/bixchange.cgi?pom=limsexpert3;iid=readMore;go=1441388077