Looking back at HR software design

Self reflection is good. It can bring about fresh ideas and remind you of what works and what doesn’t. Documenting that reflection stops you from duplicating thoughts and effort. This post is meant to get some of those thoughts about HonestRepair software design out into the open. It is my hope that by solidifying these thoughts into words that I can continue to build upon them and advance my design process and skill-set.

Most HonestRepair web applications share a common codebase, or as many common functions as possible to reduce development leadtime. Several times throughout it’s history, the HonestRepair codebase has been completely re-written to bolster capabilities and improve quality and performance. The different generations of codebase have been dubbed “engines” and have been categorized as follows…..


NYX ENGINE

Nyx is a God of ancient Italian mythology who was believed to have given rise to all other Italian gods.

The Nyx engine is based off a one-off “Static Runtime Assembly” method of Application design.

The Nyx engine starts by initiating a session the same way in all instances, but depending on the inputs that are supplied different runtimes are generated and executed. This method puts most of the code into a small number of files which are run on every operation.

Nyx code is defined by it’s age between 2014 and 2016. Nyx code mixes functions and conditional logic,oftentimes within the same files. Usually a Nyx application will comprise of one or more files containing the logical code and another one or more files containing the front-end UI code. Nyx code had relaxed formatting
and no system for logging or error reporting that was well-defined. That doesn’t mean Nyx applications didn’t create log files or report errors, it simply means that the platform itself made no accommodations for such things.

Nyx application examples: HRToolkit, HRToolkitTools


VALKYRIE ENGINE

A Valkyrie is a fictional being who decides who gets to live and who must die.

The Valkyrie engine is based off a one-off “Dynamic Runtime Assembly” method of Application design.

The Valkyrie engine starts by initiating a session the same way in all instances, but depending on the inputs that are supplied different runtimes are created and executed so as to consume the minimum amount of resources required to accomplish the given task. This method keeps code that will never be used out of memory and completely out of the path of the PHP interpreter.

The Valkyrie engine uses no-SQL design philosophy, but requires WordPress for initial setup and user-maintenance operations.

Valkyrie code is defined by it’s age between 2016 to present. It displays an overall emphasis on reduction of functions and classes in favor of in-line conditional statements that execute logic directly. It can be identified by elaborate yet highly condensed conditional statements. The commonCore of HRCloud2 is a prime example
of a Valkyrie generation project. The Valkyrie engine is expected to be in active development for several more years, with development running concurrently to the next-generation Diablo engine currently in Alpha stages.

Valkyrie application examples: HRCloud2, HRConvert2


DIABLO ENGINE

“Diablo” is Spanish for “Devil.” While “Devil” is a Greek word, it has a lot of meanings in a lot of different cultures. HonestRepair takes a more dualistic approach to the meaning of “Diablo” in the Diablo Engine. In our eyes the “Diablo” is the creation of (and absolute opponent to) the most powerful deity. In our case, the Diablo engine was created as a result of Google to specifically oppose Google. In Google’s own words they “do no evil.” Assuming that’s true, HonestRepair must be “el Diablo.”

The Diablo engine is based off a one-off “Dynamic Runtime Assembly” method of Application design like the Valkyrie engine, but extends the method through the entire stack, replacing WordPress as a dependency.

The Diablo engine starts in the same fashion as the Valkyrie engine and inherits all of the same benefits of the original “Dynamic Runtime Assembly.” It is different from Valkyrie in that instead of using WordPress as one big module in the runtime Diablo includes it’s own functions that can replace WordPress functions in a much more homogeneous and modular way. This dramatically reduces resource usage and improves performance while reducing latency.

By removing WordPress as a dependency, Diablo is completely no-SQL. It includes user-authentication, administrative, plugin, backup, and analytic mechanisms lower in the stack than WordPress+Valkyrie. As a result, Diablo eliminates mySQL as a dependency as well to achieve a pure, true no-SQL CMS that is fast, reliable, and scalable.

Diablo code is defined by it’s age between June of 2018 to present. It displays an overall emphasis on minimalist
design and extensive use of functions and arrays with minimal use of classes. It has a more strict and structured
formatting and all-inclusive design than the Valkyrie engine.

At the time of this writing all Diablo related code is still in alpha stages and not mature enough for source-code release.

Leave a Reply

Your email address will not be published. Required fields are marked *

* Consent To Store Information (GDPR Requirement)

*