- Sphere Engine overview
- API integration
- API integration
- E-learning platforms
- Programming languages
- Modules comparison
- API Changelog
Let's start with explaining the terms used in this Handbook. The glossary provides references for all Handbook chapters, so please consult it if anything is unclear.
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 (libraries, frameworks),
- extra modules for programming languages,
- auxiliary tools.
Here is how one could describe a sample project:
- Debian 10 operating system,
- with a Django framework web application in
- with all dependencies from
/var/app/requirements.txtalready installed with
A project template is a special type of project. It is a starting point from which target projects always originate.
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.
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.
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.
The role of the Workspaces is currently limited to usage by Content Managers. In the upcoming releases, the scope will be extended. Precisely, the Workspace will be an interchangeable integration method with the RESTful API.
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.
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.