45 lines
2.7 KiB
Plaintext
45 lines
2.7 KiB
Plaintext
---
|
|
description: Overview of the Tech Career Kickstarter / Optivex project structure, purpose, and conventions
|
|
alwaysApply: true
|
|
---
|
|
|
|
# Tech Career Kickstarter — Optivex
|
|
|
|
This repository supports Optiver's **Tech Career Kickstarter** program: a one-week, on-premise training and assessment program for STEM students. Participants build a simulated financial exchange called **Optivex**.
|
|
|
|
## Repository Structure
|
|
|
|
The repo has three top-level areas with different audiences:
|
|
|
|
| Directory | Audience | Purpose |
|
|
|---|---|---|
|
|
| `setup_utils/` | Program staff only | Shell scripts for provisioning EC2 dev machines and the UAT machine. |
|
|
| `solution/` | Program staff only | Reference system tests and the UAT continuous deployment daemon. |
|
|
| `x_template/` | **Participants** | Submodule for the starter project cloned per team. This is the only part participants see. |
|
|
|
|
## The Exchange System (x_template/)
|
|
|
|
Participants implement **N interconnected components** that communicate over TCP using Protobuf 3, where N is defined by each team according to how they want to design their system. In the end, all protocols defined in `x_template/proto/` must be implemented by these components in order to pass all system tests. The protocol may be extended with new messages and services, but they must remain compatible with the original protocols for the automated system tests to pass.
|
|
|
|
## Key Patterns
|
|
|
|
### BaseApplication
|
|
All components inherit from `src/application/application.py::BaseApplication` (ABC). It handles:
|
|
- CLI arg `-c/--config` pointing to a JSON config file validated against a JSON Schema
|
|
- File + stream logging setup
|
|
- SIGINT/SIGTERM → clean `SystemExit(0)`
|
|
|
|
Subclasses implement `_start()`.
|
|
|
|
### Deployment & Testing
|
|
|
|
- `deploy.sh` (in `setup_utils/`) builds a wheel via `uv build` and SCPs it to the UAT machine.
|
|
- The UAT daemon (`solution/tests/continuous_deployment/test_finder.py`) polls for new wheels, installs each in an isolated venv, and runs the system tests from `solution/tests/`.
|
|
- System tests use `ComponentOrchestrator` and `ProcessManager` to spawn component binaries by console-script name and connect to them over TCP. The component dependencies are defined in `solution/tests/continuous_deployment/testing_dependencies.json`.
|
|
- Only protocol messages that are explicitly defined in `x_template/proto/` are allowed to be used in the system tests.
|
|
- Test results are written to `/tmp/<timestamp>/test_results.xml` and SCPed back to the dev machine.
|
|
|
|
### Component Configuration
|
|
|
|
Runtime config for each component follows `src/application/config_schema.json`. The full deployment is described in `deployment_config.json` (validated against `deployment_config_schema.json`), which lists components, their implemented protocols, ports, and which system tests to run.
|