Project, Code, Documentation, and Schema Examples
This page is dedicated to all guests considering purchasing the PracticeTrack
system in full. Following is a brief overview of its planning, design, and general
From the organization of object-related information to consistent naming and reuse of
controls, every effort has been made to keep this system pristine throughout.
Not only is there strict adherence to software industry standards and best practices,
but intercomponent dependencies have been shrunken to the bare minimum, and automated
code building techniques have been utilized in every case where redundant or repetitive
definitions or components are employed.
A delegation of development duties philosophy has also been imparted into the system
building and improvement workflow, allowing for multiple teams of multiple people to
perform simultaneous maintenance on the system, providing extremely rapid time to
market, even for major conceptual changes.
This combination of several modern techniques results in a highly modular system
that can grow and change over time without experiencing many of the problems typically
associated with a large or complex system.
The project is organized with a general architecture similar to that promoted by
Franwell for their Metrc system. In fact, you may have already seen an architecture
illustration similar to the following during one of your seminars. Note that in order
to provide the emulation and simulation capabilities in which PracticeTrack specializes,
some minor differences in perspective and purpose exist. For example, in the
PracticeTrack infrastructure, the entire cloud operation is the sandbox. On the consumer side
of the equation, the web browser interface is for both students and facility operators.
Additionally, the API is intended to be accessed by prototype software instead of
pre-certified software. In this testbed, a third-party software publisher can completely
perfect their components prior to submitting anything to Franwell for certification.
While the figure above illustrates that there is a cloud-based web server hosting
user web and special API accesses, the system might be more accurately summarized,
and possibly better communicated with a functional block diagram such as the following,
which uses common terms and concepts to highlight which things connect to which others on
the path from seed to sale.
PracticeTrack and its database data are built using a combination of the above functional
diagrams, and as many practical examples as could be found in the reference system.
The production database is hosted by Microsoft SQL Server 2017 or later, but the prototype
and testing versions of PracticeTrack support either Microsoft Access or SQL Server.
The schema (data structure) definition is created and maintained in Microsoft Excel,
an application perfectly suited for the definition and advanced handling of freeform
Whenever a schema is created or modified, custom VBA macros in the workbook can be
executed to update the SQL definitions at the database server.
The updated data definitions exported from Excel are pre-loaded with any data conversion
routines used to prepare the database for the update, as well as any roll-back capabilities
that might be needed in the case of an error in the updated schema, or in the case that
the database has to be brought back to an earlier version while reworking the next update.
This full in-file support results in a situation where any authorized SQL administrator
is able to perform the upgrade to the server by simple drag and drop.
The automatically generated SQL definitions are completely Microsoft compliant, and
every action or field in the database have been given descriptive remarks accessible from
documentation rendering software. The resulting data system supports fully automated
production of a PDF data definition and administration document at any time.
Proper attention has also been given to the construction of the data to be completely
supportive of running in server farms and other real-time massively distributed,
synchronized redundant environments out of the box, greatly reducing the odds of
profound system break down or eventual data loss to virtually zero.
As mentioned above, every effort has been made to keep all of the code in the system
as structured and consistent as possible. The system itself operates in multiple conceptual
layers, each of which are built upon multiple conceptual blocks. Within each block of each
operational layer, all of the components are nearly identical in their presentation,
differing only in the specific aspects that cause them to be unique.
The effect of this arrangement and adhesion to strict detail allows the entire
PracticeTrack system to treated something as a simple catalog of parts. Each item is
coherently named, serves a dedicated purpose, and is directly pluggable to any other
related components without modification to the larger system. As with the data structuring
techniques described above, even the most major overhaul can be completed with relative
As much of the code as possible has been dynamically rendered through custom mechanisms
specifically built for the PracticeTrack system that allow the human information worker to
make use of multiple declarative approaches that allow three separate groups of developers
to describe, in simple terms, the following aspects, which are then interpreted and converted
to source code by a disconnected automated process.
- What is the component?
- What is the component's information?
- What does the component do?
Granted, the above objectives have always been the work of software everywhere, in general.
The difference here is that the duties of defining those facets are separated into completely
different work realms where even non-programmers can easily define many of the parts. Only the
third objective has any sense of computer logic associated with it, and the person
handling that last goal need not know much about the underlying business logic when doing
Detail 1 above is the absolute base description and the key to the entire functionality
of the system. To get a firm grasp on the workings of detail 1, consider the following
example API function definition. Not only is that basic information a good functional
match for the API definition published for Metrc, but in PracticeTrack's current
configuration, is the only type of information needed to construct the actual controller
logic in the server.
The web browser side of the server uses a slightly different structure, but once again,
the declarative text file is all the information needed by that server to perform flawlessly
in all circumstances mapped out during the original design.
Detail 2 of construction typically falls into the hands of a worker with more training in
database queries. This definition takes into account all of the fields and parameters defined
in the base description and provides methods for information to be posted to the database
or returned back to the client, depending upon the purpose of each function or context.
Detail 3 of the foundation assures that any possible eventually is, or can be, covered by
keeping as much of the system logic completely abstract, as depicted in the following
excerpt of the template logic that writes the controller software source code on the
There are several benefits to keeping the base logic abstracted completely away from
knowing the identification of itself or its members.
- The same code can be used for any number of circumstances and/or different systems
where the same number and types of members are used. To expand upon this, the same
exact template can be used to write hundreds or even thousands of separate functions
within just a couple of minutes.
- When the descriptions of the system parts change, the template can remain unchanged,
but the generated target code can be updated to accommodate the new or changed members.
- When a base change is needed in the overall functionality, all of the components
can be updated and rolled out with a single change in a text file.
- As described in the template excerpt above, code written with this approach is finished
over 100 times faster than coding done with a conventional, traditional approach.
All of the parts described in the previous sections will be documented completely
by the time of version 1.0 completion, making it easy for any well-versed development team
to take over then continue the development and maintenance of the system.
Following are example categories where full PracticeTrack documentation will be available.
- ASP.NET project organization and asset map.
- C# function library with summary, parameters, call signature, and relations.
- SQL table and query library with summary, parameters, and relations for all elements.
- Template reference for API functions.
- Template reference for UI functions.
- Web server user documentation. Basically, how to use Metrc.
- Web server WebAPI2 functionality. Basically, how to use the Metrc API.