- Sphere Engine overview
- Compilers
- Overview
- API
- Widgets
- Resources
- Problems
- Overview
- API
- Widgets
- Handbook
- Resources
- Containers
- Overview
- Glossary
- API
- Workspaces
- Handbook
- Resources
- RESOURCES
- Programming languages
- Modules comparison
- Webhooks
- Infrastructure management
- API changelog
- FAQ
This document aims to elucidate the terminology associated with the Sphere Engine Containers module. The included glossary serves as a comprehensive reference for all related documentation. Should any concepts remain unclear, we encourage consulting the glossary for further clarification.
Project
A project is a fundamental component of the Sphere Engine Containers module. It provides the context in which all the operations are performed.
From a technical point of view, a project is a Docker image based on a Debian Linux operating system. Usually, it is equipped with:
- application files,
- application dependencies (e.g., libraries, frameworks),
- extra modules for programming languages,
- auxiliary tools.
Here is how one could describe a sample project:
- Debian 12 operating system,
- with
python
andpip
installed, - with a Django framework web application in
/home/user/workspace
directory, - with all dependencies from
/var/app/requirements.txt
already installed withpip
.
Project template
A project template is a special type of project. It is a starting point from which target projects always originate.
Content manager
The Sphere Engine Containers module delivers easy and secure methods for managing and executing complex, multi-component software projects. Such projects are initially empty templates that need to be pre-configured to be later used in the target business scenarios. A Content Manager is a person responsible for creating and configuring such environments. Content managers work on behalf of the Customer and usually are a part of their team.
In a typical scenario, the Content Manager uses Workspace Editor for content creation. At first, the Content Manager
starts with a project template (for example, the one that offers Python with the Django web application framework).
Then, they upload or create custom project files and install all dependencies (sticking to our example: they create a
Django web application and then fetch all the required libraries with the pip
tool). Finally, the project can be
saved. After that, it is ready for the intended use.
End-user
The end-user is a person who uses the Containers module through the Customer's product. Naturally, the Customer needs to integrate the Sphere Engine Containers module with their product first.
Depending on the context, the end-user may also be:
- computer science student (in education or e-learning),
- software engineer candidate (in recruitment),
- employee (in internal training or onboarding),
- contestant (in competitive programming),
- test taker in general, if there is a programming puzzle to be solved,
- any software engineer coding and interacting with the Sphere Engine Containers module.
Workspace
The workspace is a full-fledged environment for developing a programming project. This is an online IDE platform equipped with a code editor, project tree, and interactive terminal, all connected to the underlying machine, hosting the project in real-time.
Scenario
The scenario defines how the project should be run. It is composed by five stages:
- Initialization (
init
) - for preparation steps, - Build (
build
) - for building the application, - Execution (
run
) - for launching the application, - Evaluation (
test
) - for verifying the correctness, if your project is designed to be an assignment, - Finalization (
post
) - for summarizing and cleaning.
Submission
The submission is a package with files sent to the Sphere Engine Containers module for execution. Usually, most of the files contain source code, but this is not a precondition. Submissions are always associated with the project, which is a context for running the code. A code of submission is executed withing a defined scenario.
A typical submission consists of a couple of files with source code, which are only a part of a bigger application. As an example, consider a Django web application. Such apps are usually relatively big and full of dependencies like libraries and framework files. It wouldn't be very efficient to send all of these files as a submission. Luckily, this is not necessary. In the recommended approach, most of the application files and dependencies are a part of the project. The submission contains only the files that should be added or overwritten before the execution.