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 construction.

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.

Project Organization

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.

 

Schema Examples

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 table-based data.

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.

 

Code Examples

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 ease.

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.

1. What is the component?
2. What is the component's information?
3. 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 so.

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 server.

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.

 

Documentation Examples

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.