ZORALab's Hestia Specifications

The entire technical specifications of the ZORALab's Hestia Project.

Purpose

This page is the engineering specifications for the entire ZORALab's Hestia Project. It is meant for developers to reference to and from while developing new project.

There are primarily 3 goals:

  1. FROM THE PAST
    To archive legacy algorithms for the purposes of continuous improvements and future learning use.

  2. AT PRESENT
    To provide engineering details for development and utilizing the libaries offered by ZORALab's Hestia.

  3. INTO THE FUTURE
    To serve as an industrial education tool and research and development baseline.

Technical Values

There are some engineering values that ZORALab's Hestia maintains in order to offer stable services to anyone, everyone. These were formed based on cumulated experiences in the past and using their insights to prevent it from happening again.

Assimilate Dependencies

DO NOT, as in STRICTLY DON'T INTEGRATE EXTERNAL DEPENDENCIES. Read (and audit) them codes; Understand or procure algorithm; then assimilate it into ZORALab's Hestia.

The problems with integrations are always related to supply chain and geopolitical nuisance; unnecessary and resources wasting dramas, and etc.

Regressively Improvable

ALWAYS DEVELOP TECHNOLOGIES THAT ARE RECURSIVELY IMPROVABLE. Improve the existing; not keep rolling new product just for each iterations. Make sure the product is improvable, measurable, testable, documentable, and presentable.

Provide Integration Services

DO OFFER THE BEST INTEGRATION SERVICES TO CUSTOMER. Allow customers to integrate ZORALab's Hestia easily; or have the freedom to assimilate directly from us.

Appreciates and Recognizes

ALWAYS APPRECIATES AND RECOGNIZES ALL CONTRIBUTORS, BIG OR SMALL. No being left behind. Resources are scarce; Compliment, not compete with the existing teams.

Steadly Push Towards Extreme

ALWAYS PUSH AND OPTIMIZE TO THE EXTREME POSSIBLE IN A STABLE AND CONFIDENT MANNER. Choose the best of the best for everyone to benefits from and trusted with.

Stays Open For Distruption

ALWAYS KEEP OPEN END FOR ANY FUTURE DISTRUPTIVE TECHNOLOGIES. Leave room for possible metamorphosis improvements.

Common Convetions

To ensures we have common understanding for contributions, we established some conventions that are being used across all divisions. This does not limits each division to impose its additional conventions specific to itself.

X_ Prefix for Experimentals

X_ or x_ prefix on an identifier (e.g. name) stands for experimental and things may break. Examples: X_S16_TrimWhitespace (Go), x_s16_trim_whitespace (Rust), or X_core_designer.html (Hugo). When in doubt, always do this to let customer knows something is experimental.

Unique Tracking Identifier

Ensures all features, products, artists, developers, etc are uniquely identified in the project. This is inter-transatable Project so common name conflicts can be disasterous. Example: for core_hestiaUI Hugo component; it is translated to hestiaUI/Core in Go and hestia_ui::Core in Rust.

Always Semi-Automatic

Keep things semi-automatic - scripting, semi-automation tool, etc. These libraries are eventually for human to main at scale beyond reach. We need the best of both worlds to complement one another.


Available Libraries

With the above general specifications, ZORALab's Hestia offers the following libraries for your needs: