Spire Trading Inc. - User contributions [en]

https://wiki.spiretrading.com/api.php?action=feedcontributions&feedformat=atom&user=Kamal Spire Trading Inc. - User contributions [en] 2026-05-28T22:00:59Z User contributions MediaWiki 1.34.1 https://wiki.spiretrading.com/index.php?title=TypeScript_Style_Guide&diff=145 TypeScript Style Guide 2026-05-27T20:28:39Z

<p>Kamal: </p> <hr /> <div>This article specifies the most general guidelines used for all Spire projects written using TypeScript as the primary programming language. Each individual project may extend or override the guidelines specified herein. The overall aim of this guideline is to provide consistency across the numerous projects developed by Spire in order to promote and benefit from modern web development practices as well as tailor them to our specific requirements.<br /> <br /> In general, the guidelines are very specific and opinionated. This is done intentionally to ensure that every detail has been given proper consideration and that every line of code is written with care and diligence. It is taken as a prerequisite that writing robust, clean and maintainable code requires paying close attention to even the smallest of details. As such, when there are two or more ways to write or express any given statement or expression, be it using spaces or tabs, number of characters per line, purple or violet, the guideline will often require that one particular approach be used to the exclusion of others.<br /> <br /> Finally, this document is constantly evolving and as such older projects may not be up-to-date with the guidelines found here. In those circumstances one must use their best judgment about how to integrate these guidelines into older codebases. As a general principle, consistency should favor the local over the global, that is it is more important to be consistent with a function definition than within a file, and more important to be consistent within a file than within a directory, project, etc...<br /> <br /> = Development Environment =<br /> <br /> The primary operating systems supported by Spire projects are Linux, Windows, and macOS. On all systems, nodejs is used as the build system and webpack is used as the bundler.<br /> <br /> For source control, git is used and projects are to be hosted on [https://github.com/spiretrading Spire Trading's Github page].<br /> <br /> Each developer is welcome to use an editor of their choice, however [https://code.visualstudio.com/ Visual Studio Code] is recommended.<br /> <br /> = File Names =<br /> <br /> Use [https://en.wikipedia.org/wiki/Snake_case snake case] using all lower case letters for files and directories. The name of a file should correspond to the primary class that it exports.<br /> <br /> The default extension for TypeScript files is ''ts''<br /> <br /> The extension used for TypeScript files containing JSX is ''tsx''<br /> <br /> All files end with a single new line character.<br /> <br /> = Directory Structure =<br /> <br /> A project is broken down into a library component, a test component, and one or more application components. These components are referred to as ''artifacts''. The applications go into their own ''applications'' directory and the libraries into the ''library'' directory. Within each artifact is a ''build'' directory containing the build scripts needed to build that artifact. Scripts for POSIX systems are found in the ''posix'' sub-directory and Windows build files are within the ''windows'' sub-directory. The build scripts specified are ''setup'' to download and install any dependencies needed to produce the artifact and the ''build'' script which produces the artifact. Typically the ''setup'' script is run only once or when a new dependency is introduced to the project, and the ''build'' script is run anytime a new build is needed.<br /> <br /> Finally there is a top-level ''build'' directory for the project as a whole which produces all artifacts by recursively calling each artifact's individual build scripts. Additionally the top-level build directory also includes a ''setup'' script which downloads all third party dependencies. Some projects may also opt to include an ''install'' script which sets up a suitable development environment, and other scripts for continuous builds, deployment and testing.<br /> <br /> Assuming a project named sudoku the following directory structure should be used:<br /> <br /> <pre><br /> sudoku # Root level directory.<br /> build.sh # Script used to build all projects on POSIX.<br /> build.bat # Script used to build all projects on Windows.<br /> configure.sh # Script used to configure all projects on POSIX.<br /> configure.bat # Script used to configure all projects on Windows.<br /> setup.sh # Script used to install all dependencies on POSIX.<br /> setup.bat # Script used to install all dependencies on Windows.<br /> \application # Contains source specific for the sudoku web app.<br /> build.sh # Script used to build the web app on POSIX.<br /> build.bat # Script used to build the web app on Windows.<br /> configure.sh # Script used to configure the web app on POSIX.<br /> configure.bat # Script used to configure the web app on Windows.<br /> package.json # The Node JS package description.<br /> tsconfig.json # The TypeScript compiler configuration.<br /> setup.sh # Script used the web app dependencies on POSIX.<br /> setup.bat # Script used the web app dependencies on Windows.<br /> webpack.config.js # The Webpack configuration.<br /> \source # Contains the web application source files.<br /> \index.html # The HTML file that loads the JavaScript application.<br /> \index.tsx # The TypeScript/JSX file containing the application.<br /> \library # Contains the common library code.<br /> build.sh # Script used to build the library on POSIX.<br /> build.bat # Script used to build the library on Windows.<br /> configure.sh # Script used to configure the library on POSIX.<br /> configure.bat # Script used to configure the library on Windows.<br /> package.json # The Node JS package description.<br /> setup.sh # Script used the library on POSIX.<br /> setup.bat # Script used the library on Windows.<br /> tsconfig.json # The TypeScript compiler configuration.<br /> \source # Contains the library source files.<br /> index.ts # Exports all definitions contained in this directory.<br /> \pages # Contains the source code for individual web pages.<br /> index.ts # Exports all definitions for every web page defined<br /> # in this directory.<br /> \landing_page # Contains the source code for the landing page.<br /> index.ts # Exports the landing page.<br /> landing_page.tsx # The TypeScript/JSX source code for the landing page.<br /> \page_2 # Contains the source for for another web page.<br /> ... # Structured in a similar manner as the landing page.<br /> \resources # Contains images, fonts, CSS files and all other web<br /> # assets.<br /> \index.css # Contains the main CSS file, typically this is the<br /> # only CSS file used.<br /> \fonts # A directory of fonts used.<br /> \tests # This directory contains tests for every page of the<br /> # web app.<br /> build.sh # Script used to build all tests on POSIX.<br /> build.bat # Script used to build all tests on Windows.<br /> configure.sh # Script used to configure all tests on POSIX.<br /> configure.bat # Script used to configure all tests on Windows.<br /> setup.sh # Script used to install all test dependencies on POSIX.<br /> setup.bat # Script used to install all test dependencies on<br /> # Windows.<br /> \scratch # Directory containing a test/demo for a single page.<br /> build.sh # Script used to build the test on POSIX.<br /> build.bat # Script used to build the test on Windows.<br /> configure.sh # Script used to configure the test on POSIX.<br /> configure.bat # Script used to configure the test on Windows.<br /> package.json # The Node JS package description.<br /> tsconfig.json # The TypeScript compiler configuration.<br /> setup.sh # Script used the test dependencies on POSIX.<br /> setup.bat # Script used the test dependencies on Windows.<br /> webpack.config.js # The Webpack configuration.<br /> \source # Contains the test source files.<br /> \index.html # The HTML file that loads the JavaScript application.<br /> \index.tsx # The TypeScript/JSX file containing the application.<br /> </pre><br /> <br /> An example of the above directory structure containing a basic skeletal implementation of all files can be found here: https://github.com/spiretrading/sudoku<br /> <br /> = Component Names =<br /> <br /> Naming components can be difficult. Names are usually prefixed with the context or domain. Most components will fall under one of the following categories.<br /> <br /> == Field ==<br /> <br /> The primary function of a field is to display data. The data can be edited. It can have a readonly property. It contains a onChange callback.<br /> <br /> Examples: DurationField, NumberField<br /> <br /> === Selection Field ===<br /> <br /> A specialized field. It requires a list of potential values to choose from.<br /> <br /> Example: CountrySelectionField<br /> <br /> == Input ==<br /> <br /> The primary function of a input is to get user input. Inputs usually do not have a initial value unlike fields. Inputs can have a readonly mode, but it is only to be used when the input should not accept input.<br /> <br /> Example: SecurityInput<br /> <br /> === Button ===<br /> <br /> Buttons are a specialized form of input. Only has a onClick callback.<br /> <br /> Examples: Button, BurgerButton<br /> <br /> == Box ==<br /> <br /> A component that displays data that cannot be directly edited.<br /> <br /> = Syntax =<br /> <br /> == Indentation ==<br /> <br /> Code is indented using 2 spaces per level, tabs are not permitted.<br /> <br /> <syntaxhighlight lang=typescript line=line><br /> function factorial(n: number): number {<br /> if(n == 0) {<br /> return 1;<br /> }<br /> return n * factorial(n - 1);<br /> }<br /> </syntaxhighlight><br /> <br /> == Line Structure ==<br /> <br /> Statements must end with a semi-colon ';' or a closing brace '}', even in cases where TypeScript allows them to be optional.<br /> <br /> Lines are limited to 80 characters. Exceptions to this rule are long imports and long string literals where breaking up the literal into multiple lines is not possible. In order to break up long statements into multiple lines, break the line after the earliest operator or punctuation mark (which includes commas, operators, and opening brackets).<br /> <br /> <syntaxhighlight lang=typescript line=line><br /> // Correct, line break at comma.<br /> f(a, ..., b,<br /> c, ..., d);<br /> <br /> // Incorrect, line break after expression.<br /> f(a, ..., b<br /> , c, ..., d);<br /> <br /> // Correct, line break after operator.<br /> a + ... + b +<br /> c + ... + d;<br /> <br /> // Incorrect, line break after expression.<br /> a + ... + b<br /> + c + ... + d;<br /> <br /> // Correct, line break after opening bracket.<br /> f(<br /> a, ..., b, c, ..., d);<br /> <br /> // Incorrect, line break after function name.<br /> f<br /> (a, ..., b, c, ..., d);<br /> </syntaxhighlight><br /> <br /> For statements that begin new blocks of code (such as if/while/class...), in order to avoid confusing the line continuation with the code block, the line continuation is indented two extra levels. For example consider the following snippet of code:<br /> <br /> <syntaxhighlight lang=typescript line=line><br /> // Incorrect.<br /> if(condition_a && condition_b && ... &&<br /> condition_c) {<br /> console.log('meow');<br /> }<br /> </syntaxhighlight><br /> <br /> The line continuation on line 2 clashes with the code block on line 3. To avoid this clash the above code is indented as follows:<br /> <br /> <syntaxhighlight lang=typescript line=line><br /> // Correct.<br /> if(condition_a && condition_b && ... &&<br /> condition_c) {<br /> console.log('meow');<br /> }<br /> </syntaxhighlight><br /> <br /> The extra level of indentation in the line continuation makes it clear where the condition ends and the code block begins.<br /> <br /> == Braces ==<br /> <br /> Braces are placed using a variant of the [http://wiki.c2.com/?OneTrueBraceStyle OTBS style]. The opening brace is placed on the same line as the declaring statement with one single space preceding it, and the closing brace is placed on a line of its own at the same level of indentation as the declaring statement. For if statements, the else/else if is placed on the same line as the closing brace. For do/while loops, the while is placed on the same line as the closing brace.<br /> <br /> Examples:<br /> <br /> <syntaxhighlight lang=typescript line=line><br /> // Correct.<br /> if(<cond>) {<br /> <body><br /> } else {<br /> <default><br /> }<br /> <br /> // Correct.<br /> do {<br /> <body><br /> } while(<cond>);<br /> <br /> // Incorrect.<br /> if(<cond>)<br /> {<br /> <body><br /> }<br /> else<br /> {<br /> <default><br /> }<br /> <br /> // Incorrect.<br /> do<br /> {<br /> <body><br /> }<br /> while(<cond>);<br /> </syntaxhighlight><br /> <br /> == Spacing ==<br /> <br /> The following are correct use cases for white spaces:<br /> <br /> * Used for indentation.<br /> * Used to surround binary operations.<br /> <br /> <syntaxhighlight lang=typescript line=line><br /> // Correct.<br /> const x = a + b;<br /> const y = 5;<br /> <br /> //! Incorrect<br /> const x = a+b;<br /> const y=5;<br /> const z= 5;<br /> </syntaxhighlight><br /> <br /> * One space is placed after a comma.<br /> <br /> <syntaxhighlight lang=typescript line=line><br /> // Correct.<br /> f(1, 2);<br /> function g(a: number, b: number): number;<br /> <br /> //! Incorrect<br /> f(1,2);<br /> function g(a:number,b:number);<br /> </syntaxhighlight><br /> <br /> == Naming ==<br /> <br /> [https://en.wikipedia.org/wiki/Camel_case Camel case] is used for naming whereas variables and functions use mixedCase and namespaces, modules, and types use CapWords. Names should be descriptive but should avoid being verbose.<br /> <br /> Classes and variables should be given the name of a noun and functions the name of a verb. Functions that return a boolean or boolean variables should be named in the form of a question starting with isX or hasX.<br /> <br /> == Imports ==<br /> <br /> Imports are listed in order of most global to local. Where dependencies have the same locality, then they are ordered alphabetically. For example, the first group of dependencies to be imported are third party packages which are listed in alphabetical order based on the package name. In the snippet below the third party dependencies are jquery, react and react-router-dom which are imported in alphabetical order. Then local dependencies are imported where directories further up the hierarchy are imported first. That is, the directory '../../..' which is three levels up is imported before the directory '..' which is only one level up.<br /> <br /> When multiple names are imported from a package, they must be listed in alphabetical order.<br /> <br /> <syntaxhighlight lang=typescript line=line><br /> import * as $ from 'jquery';<br /> import * as React from 'react';<br /> import * as Router from 'react-router-dom';<br /> import {HBoxLayout, Padding, VBoxLayout} from '../../..';<br /> import {Model} from '..';<br /> </syntaxhighlight><br /> <br /> == Declarations ==<br /> <br /> Any declaration (such as a function or class) that is intended to be imported by another file must be documented using [http://usejsdoc.org/ JSDoc style]. If the definition is local then that documentation should be omitted entirely.<br /> <br /> Any documentation should be preceded by a blank line. In the code snippet below, Properties is part of the public API so it is documented along with all of its fields, but the State is internal to the file so no aspect of it is documented.<br /> <br /> <syntaxhighlight lang=typescript line=line><br /> /** Stores the React properties used to render a Page. */<br /> export interface Properties {<br /> <br /> /** The model used to display the page. */<br /> model: Model;<br /> }<br /> <br /> export interface State {<br /> redirect: string;<br /> isLoading: boolean;<br /> }<br /> </syntaxhighlight><br /> <br /> == Variable Declarations ==<br /> <br /> Variables are declared so that only one variable is declared per line, prefer declaring variables using ''const'' when possible, and deferring to ''let'' otherwise, variables should always be initialized at the point of their declaration.<br /> <br /> For complex initialization of values, use an [https://en.wikipedia.org/wiki/Immediately-invoked_function_expression immediately invoked lambda expression] as follows:<br /> <br /> <syntaxhighlight lang=typescript line=line><br /> const value = (() => {<br /> if(condition) {<br /> return 123;<br /> }<br /> return 321;<br /> })();<br /> </syntaxhighlight><br /> <br /> = Example =<br /> <br /> Below is a full example combining numerous elements of the style guide to define a typical React component. It should be used as a general reference for how code is laid out, structured, and properly spaced.<br /> <br /> <syntaxhighlight lang=typescript line=line><br /> import * as $ from 'jquery';<br /> import * as React from 'react';<br /> import * as Router from 'react-router-dom';<br /> import {HBoxLayout, Padding, VBoxLayout} from '..';<br /> import {Model} from '.';<br /> <br /> /** Stores the React properties used to render a Page. */<br /> export interface Properties {<br /> <br /> /** The model used to display the page. */<br /> model: Model;<br /> }<br /> <br /> export interface State {<br /> redirect: string;<br /> isLoading: boolean;<br /> }<br /> <br /> /** Displays an HTML page. */<br /> export class Page extends React.Component<Properties, State> {<br /> constructor(props: Properties) {<br /> super(props);<br /> this.state = {<br /> redirect: '',<br /> isLoading: true<br /> };<br /> }<br /> <br /> public componentWillMount(): void {<br /> this.props.model.load().then(<br /> () => {<br /> this.setState({<br /> isLoading: false<br /> });<br /> });<br /> }<br /> <br /> public render(): JSX.Element {<br /> if(this.state.redirect) {<br /> return <Router.Redirect push to={this.state.redirect}/>;<br /> } else if(this.state.isLoading) {<br /> return <LoadingPage/>;<br /> }<br /> const style = {<br /> backgroundColor: '#FFFFFF',<br /> font: 'Roboto 14px'<br /> };<br /> return (<br /> <div style={style}><br /> <h1>Hello world!</h1><br /> <img src='cat.jpg'/><br /> </div>);<br /> }<br /> }<br /> </syntaxhighlight><br /> <br /> = Additional References =<br /> <br /> The bulk of this style guide focuses on syntax rather than good programming practices. The following list are reference materials for best practices on writing portable, efficient, and clean TypeScript:<br /> <br /> * [https://www.typescriptlang.org/docs/handbook/basic-types.html TypeScript Hand Book]</div>

Kamal https://wiki.spiretrading.com/index.php?title=C%2B%2B_Style_Guide&diff=144 C++ Style Guide 2026-05-27T20:26:07Z

<p>Kamal: </p> <hr /> <div>This article specifies the most general guidelines used for all Spire projects written using C++ as the primary programming language. Each individual project may extend or override the guidelines specified herein. The overall aim of this guideline is to provide consistency across the numerous projects developed by Spire in order to promote and benefit from modern C++ practices as well as tailor them to our specific requirements.<br /> <br /> In general, the guidelines are very specific and opinionated. This is done intentionally to ensure that every detail has been given proper consideration and that every line of code is written with care and diligence. It is taken as a prerequisite that writing robust, clean and maintainable code requires paying close attention to even the smallest of details. As such, when there are two or more ways to write or express any given statement or expression, be it using spaces or tabs, number of characters per line, purple or violet, the guideline will often require that one particular approach be used to the exclusion of others.<br /> <br /> Finally, this document is constantly evolving and as such older projects may not be up-to-date with the guidelines found here. In those circumstances one must use their best judgment about how to integrate these guidelines into older codebases. As a general principle, consistency should favor the local over the global, that is it is more important to be consistent with a function definition than within a file, and more important to be consistent within a file than within a directory, project, etc...<br /> <br /> = Relationship to the Cpp Core Guidelines =<br /> <br /> This document should be seen as an extension to the Cpp Core Guidelines authored and maintained by Herb Sutter and Bjarne Stroustrup. After reviewing these guidelines one should then become familiar with the Cpp Core Guidelines as documented here:<br /> <br /> * [https://github.com/isocpp/CppCoreGuidelines Cpp Core Guidelines]<br /> <br /> Those guidelines specify the best practices for writing modern C++ code. In situations where there is a conflict between the Cpp Core Guidelines and the guidelines set forth in this document, this document takes precedence. For all known situations where a conflict exists, this document should explicitly indicate that conflict to avoid confusion.<br /> <br /> = Development Environment =<br /> <br /> All projects target the C++23 standard. The two primary development environments supported by Spire projects are Linux and Windows. CMake is used to produce the appropriate project/make files for each platform.<br /> <br /> For source control, git is used and projects are to be hosted on [https://github.com/spiretrading Spire Trading's Github page].<br /> <br /> Each developer is welcome to use an editor of their choice.<br /> <br /> = File and Directory Naming =<br /> <br /> Use [https://en.wikipedia.org/wiki/CamelCase CamelCase] for header and source file names, matching the primary type or class defined within. The main exception is for CMake files which must use the name ''CMakeLists.txt''. Directory names use [https://en.wikipedia.org/wiki/Snake_case snake case] with all lower case letters.<br /> <br /> = Project Structure =<br /> <br /> A project is broken down into one library component and one or more application components. The library is written in a [https://en.wikipedia.org/wiki/Header-only header-only fashion], that is the implementation is provided directly in the header file rather than a separate .cpp source file. This allows for such libraries to easily be incorporated into other projects without the need for complex build configurations. Applications often use a mix of header only files and source files.<br /> <br /> At the root of a project are the build scripts: <code>build.bat</code>/<code>build.sh</code> to build the project, <code>configure.bat</code>/<code>configure.sh</code> to produce the platform specific build files (VS solutions for Windows, make files for POSIX), and <code>setup.bat</code>/<code>setup.sh</code> to download all third party dependencies. Some projects may also include ''install'' scripts, ''version'' scripts, and scripts for continuous builds or deployment.<br /> <br /> The library is organized into the following directories:<br /> <br /> * ''Include'' - Header files (.hpp), organized by component under a project-level namespace directory.<br /> * ''Source'' - Unit test source files (.cpp), organized into ''ComponentTests'' directories.<br /> * ''Config'' - CMake build configuration files, with a subdirectory per component.<br /> * ''Dependencies'' - Third party dependencies downloaded by the setup script.<br /> <br /> Applications go into a separate ''Applications'' directory at the project root. Each application follows the same structure with its own ''Include'', ''Source'', ''Config'', and ''Dependencies'' directories alongside its own build scripts.<br /> <br /> The following example shows the structure of a project named ''TicTacToe'' consisting of a library with two components (Board and Rules), and two applications (TicTacToeConsole and TicTacToeUi):<br /> <br /> <pre><br /> TicTacToe # Root level directory.<br /> build.bat # Builds all libraries and applications.<br /> configure.bat # Produces platform specific build files.<br /> setup.bat # Downloads all third party dependencies.<br /> \Applications # Contains all applications.<br /> \TicTacToeConsole # A console application.<br /> build.bat # Application build scripts.<br /> CMakeLists.txt # Top-level CMake config for the application.<br /> \Config # CMake build files per component.<br /> \TicTacToeConsole # CMake config for the main executable.<br /> \Include # Application header files.<br /> \TicTacToeConsole # Namespace directory.<br /> \Source # Application source files.<br /> \TicTacToeConsole # Source files for the application.<br /> \TicTacToeUi # A GUI application.<br /> \... # Same structure as TicTacToeConsole.<br /> \TicTacToe # The main library.<br /> build.bat # Library build scripts.<br /> setup.bat # Downloads library dependencies.<br /> CMakeLists.txt # Top-level CMake config for the library.<br /> \Config # CMake build files per component.<br /> \Board # CMake config for the Board component.<br /> \Rules # CMake config for the Rules component.<br /> \Include # Library header files.<br /> \TicTacToe # Namespace directory.<br /> \Board # Headers for the Board component.<br /> \BoardTests # Test utility headers.<br /> \Rules # Headers for the Rules component.<br /> \Source # Library source and test files.<br /> \BoardTests # Unit tests for the Board component.<br /> \RulesTests # Unit tests for the Rules component.<br /> \Dependencies # Third party dependencies.<br /> </pre><br /> <br /> = Header File Structure =<br /> <br /> == Include Guards ==<br /> <br /> Header files are structured first with an [https://en.wikipedia.org/wiki/Include_guard include guard] defined using SNAKE_CASE whose name consists of the project name appended to the directory name and finally the file name itself, ending with a ''_HPP'' suffix. As a note, all files end with a single new line character.<br /> <br /> <syntaxhighlight lang=c++ line=line><br /> #ifndef CPP_CHAT_SERVER_HPP<br /> #define CPP_CHAT_SERVER_HPP<br /> ...<br /> #endif<br /> </syntaxhighlight><br /> <br /> == Include Directives ==<br /> <br /> Next come the list of #include directives. Include files are ordered based on their category where the first category is standard C++ header files, the second category is external dependency header files, and finally the third category is project header files. Both standard and external dependency header files use angle brackets (<code>#include <...></code>) and local project header files use quotes (<code>#include "..."</code>). Within each category files are listed in alphabetical order.<br /> <br /> <syntaxhighlight lang=c++ line=line><br /> #include <tuple><br /> #include <vector><br /> #include <boost/noncopyable.hpp><br /> #include "cpp_chat/cpp_chat.hpp"<br /> #include "cpp_chat/definitions.hpp"<br /> </syntaxhighlight><br /> <br /> == Namespaces ==<br /> <br /> After include directives the project's namespace is defined. All declarations and definitions must be contained within a namespace so as to avoid polluting the global namespace. Namespace definitions should be preceded by one single new line except when immediately following a namespace definition. The top level namespace is named after the project, and sub-namespaces may be used (although they should be used very sparingly). When possible, use the nested namespace syntax (''A::B'') instead of separate nested declarations.<br /> <br /> <syntaxhighlight lang=c++ line=line><br /> namespace CppChat {<br /> namespace SubChatA {<br /> ...<br /> }<br /> <br /> namespace SubChatB::SubSubChatA {<br /> ...<br /> }<br /> }<br /> <br /> namespace CppChatExtra {<br /> ...<br /> }<br /> </syntaxhighlight><br /> <br /> One situation where nested namespaces are welcome and encouraged are for implementation details that do not form part of the namespace's public interface. These definitions are put in a nested namespace called ''Details'' and go into a file of their own whose name contains the suffix ''details''. For example if the ''cpp_chat_server.hpp'' contains implementation details, then they should be included in the file ''cpp_chat_server_details.hpp'' and the definitions should go into the namespace ''CppChat::Details''.<br /> <br /> = Layout =<br /> <br /> == Indentation ==<br /> <br /> Code is indented using 2 spaces per level, tabs are not permitted.<br /> <br /> <syntaxhighlight lang=c++ line=line><br /> int factorial(int n) {<br /> if(n == 0) {<br /> return 1;<br /> }<br /> return n * factorial(n - 1);<br /> }<br /> </syntaxhighlight><br /> <br /> == Line Structure ==<br /> <br /> Lines are limited to 80 characters. Exceptions to this rule are long include files and long string literals where breaking up the literal into multiple lines is not possible. In order to break up long statements into multiple lines, break the line after the earliest operator or punctuation mark (which includes commas, operators, and opening brackets).<br /> <br /> <syntaxhighlight lang=c++ line=line><br /> // Correct, line break at comma.<br /> f(a, ..., b,<br /> c, ..., d);<br /> <br /> // Incorrect, line break after expression.<br /> f(a, ..., b<br /> , c, ..., d);<br /> <br /> // Correct, line break after operator.<br /> a + ... + b +<br /> c + ... + d;<br /> <br /> // Incorrect, line break after expression.<br /> a + ... + b<br /> + c + ... + d;<br /> <br /> // Correct, line break after opening bracket.<br /> f(<br /> a, ..., b, c, ..., d);<br /> <br /> // Incorrect, line break after function name.<br /> f<br /> (a, ..., b, c, ..., d);<br /> </syntaxhighlight><br /> <br /> For statements that begin new blocks of code (such as if/while/class...), in order to avoid confusing the line continuation with the code block, the line continuation is indented two extra levels. For example consider the following snippet of code:<br /> <br /> <syntaxhighlight lang=c++ line=line><br /> // Incorrect.<br /> if(condition_a && condition_b && ... &&<br /> condition_c) {<br /> std::cout << "meow" << std::endl;<br /> }<br /> </syntaxhighlight><br /> <br /> The line continuation on line 2 clashes with the code block on line 3. To avoid this clash the above code is indented as follows:<br /> <br /> <syntaxhighlight lang=c++ line=line><br /> // Correct.<br /> if(condition_a && condition_b && ... &&<br /> condition_c) {<br /> std::cout << "meow" << std::endl;<br /> }<br /> </syntaxhighlight><br /> <br /> The extra level of indentation in the line continuation makes it clear where the condition ends and the code block begins.<br /> <br /> == Blank Lines ==<br /> <br /> Documented declarations shall be separated from the following declaration by a blank line. Any two non-documented declarations shall not have a blank line between them. In general, public declarations shall be documented. This rule applies to all declarations including class members, free functions, and free variables.<br /> <br /> <syntaxhighlight lang=c++ line=line><br /> class Connection {<br /> public:<br /> <br /> /** Constructs a Connection from a host and port. */<br /> Connection(std::string host, int port);<br /> <br /> Connection(Connection&& other) noexcept;<br /> ~Connection();<br /> <br /> /** Sends a message over the connection. */<br /> void send(const std::string& message);<br /> <br /> /** Returns true if the connection is open. */<br /> bool is_open() const;<br /> };<br /> </syntaxhighlight><br /> <br /> Function bodies shall not contain blank lines. All statements within a function body are written without vertical separation.<br /> <br /> == Braces ==<br /> <br /> Braces are placed using a variant of the [http://wiki.c2.com/?OneTrueBraceStyle OTBS style]. The opening brace is placed on the same line as the declaring statement with one single space preceding it, and the closing brace is placed on a line of its own at the same level of indentation as the declaring statement. For if statements, the else/else if is placed on the same line as the closing brace. For do/while loops, the while is placed on the same line as the closing brace.<br /> <br /> <syntaxhighlight lang=c++ line=line><br /> // Correct.<br /> if(<cond>) {<br /> <body><br /> } else {<br /> <default><br /> }<br /> <br /> // Correct.<br /> do {<br /> <body><br /> } while(<cond>);<br /> <br /> // Incorrect.<br /> if(<cond>)<br /> {<br /> <body><br /> }<br /> else<br /> {<br /> <default><br /> }<br /> <br /> // Incorrect.<br /> do<br /> {<br /> <body><br /> }<br /> while(<cond>);<br /> </syntaxhighlight><br /> <br /> == Spacing ==<br /> <br /> The following are correct use cases for white spaces:<br /> <br /> * Used for indentation.<br /> * Used to surround binary operations.<br /> <br /> <syntaxhighlight lang=c++ line=line><br /> // Correct.<br /> auto x = a + b;<br /> auto y = 5;<br /> <br /> //! Incorrect<br /> auto x = a+b;<br /> auto y=5;<br /> auto z= 5;<br /> </syntaxhighlight><br /> <br /> * One space is placed after a comma.<br /> <br /> <syntaxhighlight lang=c++ line=line><br /> // Correct.<br /> f(1, 2);<br /> int g(int a, int b);<br /> <br /> //! Incorrect<br /> f(1,2);<br /> int g(int a,int b);<br /> </syntaxhighlight><br /> <br /> = Syntax =<br /> <br /> == Function Definitions ==<br /> <br /> Functions declared and defined in header files are formatted as follows:<br /> <br /> <syntaxhighlight lang=c++ line=line><br /> inline int f() {<br /> ...<br /> return 123;<br /> }<br /> <br /> template<typename T><br /> bool g() {<br /> ...<br /> return false;<br /> }<br /> </syntaxhighlight><br /> <br /> That is they are declared as inline unless they are function templates in which case the inline specifier is omitted.<br /> <br /> == Variable Declarations ==<br /> <br /> Variables are declared so that only one variable is declared per line, the type of the variable should [https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/ almost always use auto], and variables should almost always be initialized.<br /> <br /> <syntaxhighlight lang=c++ line=line><br /> auto x = 5;<br /> auto y = a + b;<br /> </syntaxhighlight><br /> <br /> For complex initialization of values, use an [https://en.wikipedia.org/wiki/Immediately-invoked_function_expression immediately invoked lambda expression] as follows:<br /> <br /> <syntaxhighlight lang=c++ line=line><br /> auto value = [&] {<br /> if(condition) {<br /> return 123;<br /> }<br /> return 321;<br /> }();<br /> </syntaxhighlight><br /> <br /> == Class Member Declaration Order ==<br /> <br /> Within each access section (public, protected, private), declarations are ordered as follows:<br /> <br /> # Nested types (enums, nested classes, typedefs, type aliases)<br /> # Implicit constructors (compiler may call implicitly, e.g. non-explicit single parameter)<br /> # Multi-parameter constructors (non-copy, non-move)<br /> # Copy constructor, move constructor, destructor<br /> # Member functions<br /> # Operators (arithmetic, comparison, assignment)<br /> <br /> Within a class, there must always be a single blank line between the destructor and the following declaration in the same access section. If there is no destructor, then a single blank line between the last constructor and the following declaration.<br /> <br /> <syntaxhighlight lang=c++ line=line><br /> /** Base class for types that can be converted to a string. */<br /> class Stringable {<br /> public:<br /> <br /> /** Returns the string representation. */<br /> virtual std::string to_string() const = 0;<br /> };<br /> <br /> /** Represents a duration of time. */<br /> class Duration : public Stringable {<br /> public:<br /> <br /> /** The underlying type used to count time units. */<br /> using Count = std::int64_t;<br /> <br /> /** Returns a Duration from a count of milliseconds. */<br /> static Duration from_milliseconds(Count milliseconds);<br /> <br /> /** Implicitly converts a count of seconds. */<br /> Duration(Count seconds);<br /> <br /> /** Constructs a Duration from a string representation. */<br /> explicit Duration(std::string representation);<br /> <br /> /** Constructs a Duration from a count and unit. */<br /> Duration(Count count, std::string unit);<br /> <br /> Duration(const Duration& other);<br /> Duration(Duration&& other) noexcept;<br /> ~Duration() override;<br /> <br /> /** Returns the count of time units. */<br /> Count get_count() const;<br /> <br /> /** Returns true if this is a non-zero duration. */<br /> bool is_non_zero() const;<br /> <br /> std::string to_string() const override;<br /> <br /> Duration operator +(const Duration& rhs) const;<br /> Duration operator -(const Duration& rhs) const;<br /> <br /> bool operator ==(const Duration& rhs) const;<br /> bool operator <(const Duration& rhs) const;<br /> <br /> Duration& operator =(const Duration& rhs);<br /> Duration& operator =(Duration&& rhs) noexcept;<br /> };<br /> </syntaxhighlight><br /> <br /> Note how the copy constructor, move constructor, and destructor are undocumented and grouped without blank lines. The overridden ''to_string'' appears after the new method ''get_count''. Arithmetic, comparison, and assignment operators each form their own group at the end with no blank lines between them.<br /> <br /> == Naming Conventions ==<br /> <br /> * Use [https://en.wikipedia.org/wiki/CamelCase CamelCase] for all type names including classes, structs, enums, type aliases, typedefs, and concepts.<br /> * Use [https://en.wikipedia.org/wiki/Snake_case snake_case] for function and variable names.<br /> * Type traits use snake_case to be consistent with the standard library convention.<br /> * Do not use abbreviations for names. Variable names should be a single noun, dropping adjectives unless needed to disambiguate.<br /> * Functions returning bool shall use a prefix that reads as a question: ''is_'', ''has_'', or ''can_''.<br /> <br /> <syntaxhighlight lang=c++ line=line><br /> // Correct.<br /> class OrderBook {<br /> public:<br /> auto get_price() const -> Money;<br /> auto is_empty() const -> bool;<br /> auto has_bid() const -> bool;<br /> };<br /> <br /> template<typename T><br /> struct is_numeric;<br /> <br /> auto order_count = 0;<br /> <br /> // Incorrect: abbreviation, wrong case, missing question prefix.<br /> class OrdBk {<br /> public:<br /> Money getPrice() const;<br /> bool empty() const;<br /> };<br /> <br /> auto orderCnt = 0;<br /> </syntaxhighlight><br /> <br /> == Constructors and Operators ==<br /> <br /> Single parameter constructors shall be declared ''explicit'' to prevent implicit conversions.<br /> <br /> <syntaxhighlight lang=c++ line=line><br /> // Correct.<br /> class Distance {<br /> public:<br /> explicit Distance(int meters);<br /> };<br /> <br /> // Incorrect, allows implicit conversion from int.<br /> class Distance {<br /> public:<br /> Distance(int meters);<br /> };<br /> </syntaxhighlight><br /> <br /> Constructors and assignment operators shall be declared ''noexcept'' if their implementations are actually noexcept. There is no need for ''noexcept'' on other methods.<br /> <br /> <syntaxhighlight lang=c++ line=line><br /> class Connection {<br /> public:<br /> Connection(Connection&& other) noexcept;<br /> Connection& operator =(Connection&& other) noexcept;<br /> };<br /> </syntaxhighlight><br /> <br /> == Object Initialization ==<br /> <br /> Objects are always initialized using parentheses, never braces. The exception is when constructing a ''std::initializer_list''.<br /> <br /> <syntaxhighlight lang=c++ line=line><br /> // Correct.<br /> auto duration = Duration(5);<br /> auto values = std::vector<int>(10, 0);<br /> <br /> // Correct, std::initializer_list exception.<br /> auto primes = std::vector<int>{2, 3, 5, 7, 11};<br /> <br /> // Incorrect.<br /> auto duration = Duration{5};<br /> auto values = std::vector<int>{10, 0}; // Constructs {10, 0}, not 10 zeros.<br /> </syntaxhighlight><br /> <br /> == Templates ==<br /> <br /> Use compile time argument deduction (CTAD) as much as possible. Provide deduction guides for all class templates unless a compiler generated deduction guide is available.<br /> <br /> <syntaxhighlight lang=c++ line=line><br /> // Correct, CTAD with explicit deduction guide.<br /> template<typename T><br /> class Wrapper {<br /> public:<br /> Wrapper(T value);<br /> };<br /> <br /> template<typename T><br /> Wrapper(T) -> Wrapper<T>;<br /> <br /> auto w = Wrapper(5); // Deduces Wrapper<int>.<br /> <br /> // Incorrect, redundant template arguments.<br /> auto w = Wrapper<int>(5);<br /> </syntaxhighlight><br /> <br /> == Documentation ==<br /> <br /> Use modern jsdoc style comments. Do not use old Doxygen-style comments. Only document the interface, not the implementation.<br /> <br /> <syntaxhighlight lang=c++ line=line><br /> // Correct.<br /> /** Sends a message to all connected clients. */<br /> void broadcast(const std::string& message);<br /> <br /> /**<br /> * Connects to a server at the given host and port.<br /> * @param host The hostname to connect to.<br /> * @param port The port to connect on.<br /> * @return The established connection.<br /> */<br /> Connection connect(const std::string& host, int port);<br /> <br /> // Incorrect, old Doxygen style.<br /> /*! \brief Sends a message to all connected clients. */<br /> void broadcast(const std::string& message);<br /> </syntaxhighlight><br /> <br /> == Character Set ==<br /> <br /> Only basic ASCII characters are permitted in source code. Never use unicode characters.<br /> <br /> <syntaxhighlight lang=c++ line=line><br /> // Correct.<br /> auto pi = 3.14159;<br /> auto label = std::string("degrees");<br /> <br /> // Incorrect, unicode in source.<br /> auto pi = 3.14159; // π<br /> auto label = std::string("degrees °");<br /> </syntaxhighlight><br /> <br /> == Helper Functions ==<br /> <br /> When a helper function does not need access to class state, prefer placing it in the narrowest possible scope. In order of preference:<br /> <br /> # Anonymous namespace (for file-local helpers in .cpp files)<br /> # Free function in a Details namespace<br /> # Static class member (only when needed)<br /> <br /> <syntaxhighlight lang=c++ line=line><br /> // Preferred: anonymous namespace for file-local helpers.<br /> namespace {<br /> int compute_offset(int base) {<br /> return base * 2 + 1;<br /> }<br /> }<br /> <br /> // Acceptable: free function in Details namespace for header-only code.<br /> namespace CppChat::Details {<br /> inline int compute_offset(int base) {<br /> return base * 2 + 1;<br /> }<br /> }<br /> <br /> // Last resort: static class member.<br /> class Connection {<br /> public:<br /> static int compute_offset(int base);<br /> };<br /> </syntaxhighlight><br /> <br /> == Static Members ==<br /> <br /> Static class members shall always be accessed through the class name, never through an instance.<br /> <br /> <syntaxhighlight lang=c++ line=line><br /> class Counter {<br /> public:<br /> static int instance_count;<br /> };<br /> <br /> // Correct.<br /> auto count = Counter::instance_count;<br /> <br /> // Incorrect, accesses static member through an instance.<br /> auto counter = Counter();<br /> auto count = counter.instance_count;<br /> </syntaxhighlight><br /> <br /> = References =<br /> <br /> The bulk of this style guide focuses on syntax rather than good programming practices. The following list are reference materials (both online and published) for best practices on writing portable, efficient, and clean C++ code:<br /> <br /> * B. Stroustrup ''The C++ Programming Language (4th Edition)''. 2013<br /> * [https://github.com/isocpp/CppCoreGuidelines Cpp Core Guidelines]<br /> * [https://cppcon.org/ CppCon - The C++ Conference]</div>

Kamal https://wiki.spiretrading.com/index.php?title=NeoeMarketDataFeedClient&diff=143 NeoeMarketDataFeedClient 2026-05-27T20:18:37Z

<p>Kamal: Created page with "The NeoeMarketDataFeedClient disseminates real-time market data for the Aequitas NEO Exchange. It connects to the Service Locator for authentication and provides order boo..."</p> <hr /> <div>The NeoeMarketDataFeedClient disseminates real-time market data for the Aequitas NEO Exchange. It connects to the [[Service Locator]] for authentication and provides order book data, time and sales, and the consolidated best bid offer (CBBO) for the NEO Exchange.<br /> <br /> The feed is split into multiple channels for disseminating the CBBO, book, and trade data. Each channel resides in its own subdirectory whose name starts with the <code>neoe</code> prefix: <code>neoe_cbbo</code>, <code>neoe_cls</code>, and <code>neoe_book</code> for the CBBO, time and sales, and book feeds respectively.<br /> <br /> == Configuration ==<br /> <br /> Each channel is configured via a YAML file (<code>config.yml</code>) with the following structure:<br /> <br /> <pre><br /> service_locator:<br /> # The address of the Service Locator (host:port).<br /> address: "127.0.0.1:20000"<br /> # The account username used to authenticate with the Service Locator.<br /> username: market_data_feed<br /> # The password for the Service Locator account.<br /> password: [REQUIRED]<br /> <br /> # Rate at which market data snapshots are sampled and forwarded to the<br /> # Market Data Server.<br /> sampling: 100ms<br /> <br /> # Multicast group address and port for the feed.<br /> host: "239.0.0.1:30501"<br /> <br /> # Network interface to join the multicast group on.<br /> interface: "0.0.0.0:0"<br /> <br /> # UDP socket receive buffer size in bytes (default: 128 MB).<br /> receive_buffer: 134217728<br /> <br /> # Maximum datagram size (MTU) in bytes (optional; defaults to system MTU).<br /> mtu: 1500<br /> <br /> # Retransmission endpoints for recovering dropped packets.<br /> retransmission_request_address: "142.201.149.44:61030"<br /> retransmission_response_address: "142.201.149.44:61031"<br /> <br /> # Whether retransmission requests are enabled (default: false).<br /> enable_retransmission: false<br /> <br /> # Maximum number of retransmission requests before giving up (default: 10).<br /> max_retransmissions: 10<br /> <br /> # Maximum number of messages requested in a single retransmission block (default: 20000).<br /> retransmission_block_size: 20000<br /> <br /> # Time zone used to compute the feed's time offset (default: "America/Toronto").<br /> time_zone: "America/Toronto"<br /> <br /> # Enable logging of every received message (off by default; verbose when enabled).<br /> enable_logging: false<br /> <br /> # Whether this channel carries time and sales data.<br /> is_time_and_sale: false<br /> <br /> # Optional MPID rewriting: maps source IDs to canonical MPID names.<br /> mpid_mappings:<br /> - source: 1<br /> name: ANON<br /> <br /> # Path to the security master list (symbols.yml).<br /> symbol_list: "symbols.yml"<br /> </pre><br /> <br /> The <code>sampling</code>, <code>host</code>, <code>interface</code>, <code>retransmission_request_address</code>, <code>retransmission_response_address</code>, and <code>symbol_list</code> fields are required. All other fields have defaults.<br /> <br /> == Security Master ==<br /> <br /> A security master list of traded securities is typically stored in the <code>symbols.yml</code> file with the following format:<br /> <br /> <pre><br /> - symbol: AAPL # The ticker symbol.<br /> name: APPLE CDR (CAD HEDGED) # The name of the security.<br /> board_lot: 100 # The security's board lot.<br /> </pre><br /> <br /> Changes can be made in this security master list and reloaded by restarting the NEOE CBBO feed.<br /> <br /> == Setup ==<br /> <br /> The <code>setup.py</code> Python script configures all of the channels at once and can be called as follows:<br /> <br /> <pre><br /> --local 192.168.0.100 # Local interface (default: auto-detected IP)<br /> --address 127.0.0.1:20000 # Service Locator address<br /> --username market_data_feed # Service Locator username (default: market_data_feed)<br /> --password [REQUIRED] # Service Locator password<br /> </pre><br /> <br /> == Management ==<br /> <br /> Each channel is managed through three core scripts:<br /> <br /> * <code>start.sh</code> - Starts the channel. Does nothing if the channel is already running.<br /> * <code>stop.sh</code> - Stops the channel and waits for the channel to terminate.<br /> * <code>check.sh</code> - Verifies that the channel is running.<br /> <br /> == Logging ==<br /> <br /> Log files are generated as <code>srv_[YYYY][MM][DD]_[HH]_[MM]_[SS].log</code> in the runtime directory. Upon termination, non-empty log files are moved into the <code>log/</code> subfolder, while empty log files are deleted.</div>

Kamal https://wiki.spiretrading.com/index.php?title=AsxItchMarketDataFeedClient&diff=142 AsxItchMarketDataFeedClient 2026-05-27T20:14:03Z

<p>Kamal: Created page with "Support for ASX Trade ITCH market data is provided by the AsxItchMarketDataFeedClient. This market data feed can be used by Spire to populate the security database for ASX lis..."</p> <hr /> <div>Support for ASX Trade ITCH market data is provided by the AsxItchMarketDataFeedClient. This market data feed can be used by Spire to populate the security database for ASX listed securities, BBO quotes, time and sales, book quotes and order imbalances. In addition to real time market data, ASX Trade ITCH also provides a market data snapshot used for data recovery along with retransmission of dropped packets, both of which are fully supported.<br /> <br /> For more information about the ASX ITCH protocol and connectivity, refer to the [https://www.asxonline.com/public/documents/asx-trade-open-interface-manuals.html ASX Trade Open Interface manuals].<br /> <br /> == Feed Partitioning ==<br /> <br /> By default ASX ITCH is split into multiple feeds each handling a range of securities. Each feed is placed in its own directory and named <code>asxitch_partition[N]</code> with <code>N = 1</code> representing the first feed. Each feed also has its own configuration file.<br /> <br /> == Configuration ==<br /> <br /> Each feed is configured via a YAML file (<code>config.yml</code>) with the following structure:<br /> <br /> <pre><br /> service_locator:<br /> # The address of the Service Locator (host:port).<br /> address: "10.0.0.5:20000"<br /> # The account username used to authenticate with the Service Locator.<br /> username: market_data_feed<br /> # The password for the Service Locator account.<br /> password: [REQUIRED]<br /> <br /> # Rate at which market data snapshots are sampled and forwarded to the<br /> # Market Data Server. A higher rate reduces load at the cost of latency.<br /> sampling: 100ms<br /> <br /> # Multicast group address and port for the ITCH feed.<br /> host: "239.0.0.1:21801"<br /> <br /> # Network interface to join the multicast group on.<br /> interface: "0.0.0.0:0"<br /> <br /> # UDP socket receive buffer size in bytes (default: 128 MB).<br /> receive_buffer: 134217728<br /> <br /> # Maximum datagram size (MTU) in bytes (optional; defaults to system MTU).<br /> mtu: 1500<br /> <br /> # Enable logging of every received message (off by default; verbose when enabled).<br /> enable_logging: false<br /> <br /> # Whether this partition carries time and sales data.<br /> is_time_and_sale: false<br /> <br /> # Venue display name (e.g., "XASX") this feed services.<br /> venue: "XASX"<br /> <br /> # Default MPID assigned to messages that do not carry their own MPID.<br /> mpid: ""<br /> <br /> # Whether to consolidate multiple MPIDs into the default MPID.<br /> consolidate_mpids: false<br /> <br /> # GLIMPSE snapshot server address (SoupBinTCP).<br /> glimpse_host: "203.0.113.10:21803"<br /> <br /> # Timeout for the GLIMPSE login handshake.<br /> glimpse_timeout: "00:00:10"<br /> <br /> # GLIMPSE login credentials.<br /> username: glimpse_user<br /> password: [REQUIRED]<br /> </pre><br /> <br /> The <code>sampling</code>, <code>host</code>, <code>interface</code>, <code>glimpse_host</code>, <code>username</code>, and <code>password</code> fields are required. All other fields have defaults.<br /> <br /> == Management ==<br /> <br /> The AsxItchMarketDataFeedClient contains the standard suite of scripts used to manage each individual feed.<br /> <br /> * <code>start.sh</code> - Starts a feed. Accepts a single feed identifier <code>partition[N]</code> as a command line argument to start one feed, or <code>all</code> to start every configured feed.<br /> * <code>stop.sh</code> - Stops a currently running feed. Accepts the same arguments as <code>start.sh</code>.<br /> * <code>list_feeds.sh</code> - Outputs all currently running feeds.<br /> * <code>create_softlinks.sh</code> - Used when first setting up the feeds, or when a new feed is added, to create the necessary softlinks for each partition.<br /> <br /> == Logging ==<br /> <br /> On startup a log file is created with the name <code>srv_[YYYY][MM][DD]_[HH]_[MM]_[SS].log</code> and is used to record dropped packets, any error messages or warnings, and, if logging is enabled in the configuration file, a dump of every received message.</div>

Kamal https://wiki.spiretrading.com/index.php?title=Order_Execution_Server&diff=141 Order Execution Server 2026-05-27T20:10:32Z

<p>Kamal: Created page with "The Order Execution Server receives order submissions from clients, routes them to appropriate execution venues or brokers, and tracks the lifecycle of each order from submiss..."</p> <hr /> <div>The Order Execution Server receives order submissions from clients, routes them to appropriate execution venues or brokers, and tracks the lifecycle of each order from submission through completion. It publishes execution reports to subscribed clients, enforces compliance rules and risk parameters, and maintains a persistent record of all order activity. By centralizing order routing and monitoring, the server ensures consistent application of trading controls while providing real-time visibility into order status across the system.<br /> <br /> The Order Execution Server integrates with the [[Service Locator]] for authentication, the [[Compliance Server]] for rule validation, the [[Risk Server]] for position and loss monitoring, the [[Administration Server]] for risk parameters, the [[Market Data Server]] for pricing and board lot checks, the [[Uid Server]] for unique order identifiers, and a MySQL database (with optional replication) to persist order records and execution reports.<br /> <br /> == Configuration ==<br /> <br /> The Order Execution Server is configured via a YAML file with three top-level sections: <code>server</code>, <code>service_locator</code>, and <code>data_store</code>. An optional <code>session_start_time</code> field may also be specified. Below is the structure of the configuration file with example values:<br /> <br /> <pre><br /> server:<br /> # Primary network interface and port the Order Execution Server binds to.<br /> interface: "0.0.0.0:20700"<br /> # List of addresses the server is reachable at (for registration with Service Locator).<br /> # Typically includes both public-facing and local addresses.<br /> addresses: ["198.51.100.5:20700", "10.0.0.5:20700"]<br /> <br /> service_locator:<br /> # The address of the Service Locator (host:port).<br /> address: "10.0.0.5:20000"<br /> # The account username used by the Order Execution Server to authenticate with the Service Locator.<br /> username: order_execution_server<br /> # The password for the Order Execution Server's Service Locator account.<br /> password: [REQUIRED]<br /> <br /> # Data store supports replication: provide either a single MySQL endpoint<br /> # or a list of endpoints to replicate writes across.<br /> data_store:<br /> # The address of the MySQL server.<br /> address: "127.0.0.1:3306"<br /> # The username used to authenticate with MySQL.<br /> username: spireadmin<br /> # The password for the MySQL user.<br /> password: [REQUIRED]<br /> # The name of the database schema where data is stored.<br /> schema: spire<br /> <br /> # Optional start time of the trading session (default: +infinity, meaning no session boundary).<br /> session_start_time: "2026-01-01 09:30:00"<br /> </pre><br /> <br /> A <code>setup.py</code> script is provided to generate the final <code>config.yml</code> from the <code>config.default.yml</code> template. Usage:<br /> <br /> <pre><br /> --local 0.0.0.0 # Local interface (default: auto-detected IP)<br /> --world 198.51.100.5 # Global/public interface (optional)<br /> --address 10.0.0.5:20000 # Service Locator address (default: local_interface:20000)<br /> --password [REQUIRED] # Service password for authentication<br /> --mysql_address 127.0.0.1:3306 # MySQL server address<br /> --mysql_username spireadmin # MySQL username<br /> --mysql_password secretpw # MySQL password (default: --password if omitted)<br /> </pre><br /> <br /> == Order Submission ==<br /> <br /> Before routing, each order passes through a series of submission checks:<br /> <br /> * '''Board Lot Check''' - Validates that order quantities conform to the security's board lot size.<br /> * '''Buying Power Check''' - Ensures the account has sufficient buying power for the order, accounting for current positions and exchange rate conversions.<br /> * '''Risk State Check''' - Verifies the account is in a risk state that permits new orders.<br /> * '''Compliance Rule Check''' - Validates the order against all active compliance rules for the account or group.<br /> <br /> Orders that fail any check are immediately rejected with an appropriate error message.<br /> <br /> == Order Routing ==<br /> <br /> The server routes orders to their specified destinations based on:<br /> <br /> * Destination configuration (venue, broker, or internal order type like MOE)<br /> * Symbol resolution against the venue and trading session<br /> <br /> Orders that violate compliance rules or risk limits are rejected before routing.<br /> <br /> == Execution Reports ==<br /> <br /> Clients can subscribe to receive execution reports for:<br /> <br /> * Specific accounts<br /> * Groups of accounts<br /> * Their own orders<br /> <br /> Subscriptions enable real-time tracking of order activity across portfolios or trading desks.<br /> <br /> == Order Cancellation ==<br /> <br /> Clients can request order cancellation. The server:<br /> <br /> # Validates the cancellation request against permissions and order state<br /> # Forwards the cancellation to the destination<br /> # Updates order state based on destination response<br /> <br /> === Bulk Cancellation Utility ===<br /> <br /> A utility for bulk order cancellation supporting multiple use cases:<br /> <br /> <pre><br /> --config config.yml # Configuration file<br /> --region CA # Country code, venue, or security<br /> --connections 8 # Parallel connections for performance<br /> </pre><br /> <br /> The script supports parallel processing using multiple service connections to efficiently cancel large numbers of orders.<br /> <br /> == Data Store Replication ==<br /> <br /> The Order Execution Server supports a replicated data store, allowing order records to be written across multiple MySQL endpoints for redundancy. When multiple endpoints are configured in the <code>data_store</code> section, writes are replicated to all configured stores while reads can be served from any available replica.<br /> <br /> == Management ==<br /> <br /> The Order Execution Server is controlled using three operational scripts: <code>start.sh</code>, <code>stop.sh</code>, and <code>check.sh</code>.<br /> <br /> === start.sh ===<br /> <br /> * Exits immediately if the server is already running.<br /> * Creates a <code>logs/</code> directory if necessary.<br /> * Moves any existing <code>srv_*.log</code> files into <code>logs/</code>.<br /> * Starts the <code>OrderExecutionServer</code> process in the background.<br /> * Reads network interfaces from <code>config.yml</code> and waits until the server is listening on at least one configured address.<br /> <br /> This ensures the server is fully initialized before the script exits.<br /> <br /> === stop.sh ===<br /> <br /> * Sends <code>SIGINT</code> to request a graceful shutdown.<br /> * Waits for termination using exponential backoff (up to 300 seconds).<br /> * Sends <code>SIGKILL</code> if the server fails to stop cleanly.<br /> * Appends a forced-termination message to the most recent log file (if applicable).<br /> <br /> This guarantees consistent shutdown behavior across normal and exceptional conditions.<br /> <br /> === check.sh ===<br /> <br /> The <code>check.sh</code> script verifies whether the server is currently running by inspecting the PID recorded in <code>pid.lock</code> and testing whether the associated process exists.<br /> <br /> == Logging ==<br /> <br /> Upon startup, older log files are moved into the <code>logs/</code> directory.</div>

Kamal https://wiki.spiretrading.com/index.php?title=Risk_Server&diff=140 Risk Server 2026-05-27T20:07:49Z

<p>Kamal: Created page with "The Risk Server monitors account profit and loss, enforces risk limits, and manages account state transitions based on trading activity. It tracks each account's net position,..."</p> <hr /> <div>The Risk Server monitors account profit and loss, enforces risk limits, and manages account state transitions based on trading activity. It tracks each account's net position, buying power consumption, and realized/unrealized profit and loss. When an account exceeds its configured loss threshold, the server automatically transitions the account through risk states from active trading to closed orders mode, and ultimately to disabled or liquidation if losses continue. By centralizing risk monitoring and enforcement, the server protects both individual accounts and the overall system from excessive exposure.<br /> <br /> The Risk Server integrates with the [[Service Locator]] for authentication, the [[Order Execution Server]] to monitor trades, the [[Market Data Server]] for price discovery, the [[Administration Server]] for risk parameters, and a MySQL database to persist risk parameters and inventory snapshots.<br /> <br /> == Configuration ==<br /> <br /> The Risk Server is configured via a YAML file with three top-level sections: <code>server</code>, <code>service_locator</code>, and <code>data_store</code>. Below is the structure of the configuration file with example values:<br /> <br /> <pre><br /> server:<br /> # Primary network interface and port the Risk Server binds to.<br /> interface: "0.0.0.0:20600"<br /> # List of addresses the server is reachable at (for registration with Service Locator).<br /> # Typically includes both public-facing and local addresses.<br /> addresses: ["198.51.100.5:20600", "10.0.0.5:20600"]<br /> <br /> service_locator:<br /> # The address of the Service Locator (host:port).<br /> address: "10.0.0.5:20000"<br /> # The account username used by the Risk Server to authenticate with the Service Locator.<br /> username: risk_server<br /> # The password for the Risk Server's Service Locator account.<br /> password: [REQUIRED]<br /> <br /> data_store:<br /> # The address of the MySQL server.<br /> address: "127.0.0.1:3306"<br /> # The username used to authenticate with MySQL.<br /> username: spireadmin<br /> # The password for the MySQL user.<br /> password: [REQUIRED]<br /> # The name of the database schema where data is stored.<br /> schema: spire<br /> </pre><br /> <br /> A <code>setup.py</code> script is provided to generate the final <code>config.yml</code> from the <code>config.default.yml</code> template. Usage:<br /> <br /> <pre><br /> --local 0.0.0.0 # Local interface (default: auto-detected IP)<br /> --world 198.51.100.5 # Global/public interface (optional)<br /> --address 10.0.0.5:20000 # Service Locator address (default: local_interface:20000)<br /> --password [REQUIRED] # Service password for authentication<br /> --mysql_address 127.0.0.1:3306 # MySQL server address<br /> --mysql_username spireadmin # MySQL username<br /> --mysql_password secretpw # MySQL password (default: --password if omitted)<br /> </pre><br /> <br /> == Risk Parameters ==<br /> <br /> Each account is assigned risk parameters that govern its trading limits and risk enforcement behavior:<br /> <br /> * '''Currency''' - The currency used for risk calculations and loss limits<br /> * '''Buying Power''' - Maximum amount of capital available for trading<br /> * '''Allowed State''' - The risk state the account is permitted to operate in<br /> * '''Net Loss Threshold''' - Maximum net loss before transitioning to closed orders mode<br /> * '''Transition Time''' - Duration allowed in closed orders mode before automatic liquidation<br /> <br /> == Risk States ==<br /> <br /> Accounts progress through the following risk states based on their profit and loss:<br /> <br /> * '''Active''' - Normal trading with full permissions<br /> * '''Closed Orders''' - No new orders allowed; existing positions may be closed<br /> * '''Disabled''' - Trading prohibited; positions automatically liquidated<br /> <br /> When an account's net loss exceeds its configured threshold, the server automatically transitions the account to closed orders mode and starts a timer. If the account does reduce its loss above the threshold within the transition time, the account transitions to disabled.<br /> <br /> == Inventory Tracking ==<br /> <br /> The server maintains real-time inventory snapshots for each account, tracking:<br /> <br /> * Open positions by security<br /> * Cost basis and average entry price<br /> * Realized and unrealized profit and loss<br /> * Buying power consumption<br /> <br /> Inventory updates occur on every execution report, ensuring accurate position tracking across all trading venues.<br /> <br /> == Regional Scoping ==<br /> <br /> Risk parameters and state transitions can be scoped by region (country, venue, or security). This enables fine-grained control over risk exposure in specific markets or asset classes.<br /> <br /> == Utility Scripts ==<br /> <br /> === Position Report ===<br /> <br /> Reports current positions for accounts in CSV format:<br /> <br /> <pre><br /> --config config.yml # Configuration file<br /> --account trader1 # Specific account (optional; reports all if omitted)<br /> </pre><br /> <br /> Output format:<br /> <br /> <pre><br /> Account,Security,Currency,Side,Open Quantity,Cost Basis<br /> </pre><br /> <br /> === Manual Order Entry ===<br /> <br /> Manual Order Entry (MOE) utility for opening or closing positions without market execution. These orders are synthetic and do not interact with external venues:<br /> <br /> <pre><br /> --config config.yml # Configuration file<br /> --positions positions.csv # CSV file with positions to MOE<br /> --account trader1 # Specific account (optional)<br /> --region CA # Region filter (country/venue/security)<br /> </pre><br /> <br /> The positions CSV uses the following format:<br /> <br /> <pre><br /> Account,Security,Currency,Side,Open Quantity,Cost Basis<br /> </pre><br /> <br /> === Reset Risk States ===<br /> <br /> Resets risk state for a specific region, clearing accumulated profit/loss tracking:<br /> <br /> <pre><br /> --config config.yml # Configuration file<br /> --region CA # Region to reset (country code, venue, or security)<br /> </pre><br /> <br /> This utility is typically used at the start of a trading day or after maintenance periods to reset risk calculations.<br /> <br /> == Management ==<br /> <br /> The Risk Server is controlled using three operational scripts: <code>start.sh</code>, <code>stop.sh</code>, and <code>check.sh</code>.<br /> <br /> === start.sh ===<br /> <br /> * Exits immediately if the server is already running.<br /> * Creates a <code>logs/</code> directory if necessary.<br /> * Moves any existing <code>srv_*.log</code> files into <code>logs/</code>.<br /> * Starts the <code>RiskServer</code> process in the background.<br /> * Reads network interfaces from <code>config.yml</code> and waits until the server is listening on at least one configured address.<br /> <br /> This ensures the server is fully initialized before the script exits.<br /> <br /> === stop.sh ===<br /> <br /> * Sends <code>SIGINT</code> to request a graceful shutdown.<br /> * Waits for termination using exponential backoff (up to 300 seconds).<br /> * Sends <code>SIGKILL</code> if the server fails to stop cleanly.<br /> * Appends a forced-termination message to the most recent log file (if applicable).<br /> <br /> This guarantees consistent shutdown behavior across normal and exceptional conditions.<br /> <br /> === check.sh ===<br /> <br /> The <code>check.sh</code> script verifies whether the server is currently running by inspecting the PID recorded in <code>pid.lock</code> and testing whether the associated process exists.<br /> <br /> == Logging ==<br /> <br /> Upon startup, older log files are moved into the <code>logs/</code> directory.</div>

Kamal https://wiki.spiretrading.com/index.php?title=Compliance_Server&diff=139 Compliance Server 2026-05-27T20:03:40Z

<p>Kamal: Created page with "The Compliance Server manages compliance rules and monitors rule violations for trading accounts. It maintains a repository of compliance rule definitions organized by directo..."</p> <hr /> <div>The Compliance Server manages compliance rules and monitors rule violations for trading accounts. It maintains a repository of compliance rule definitions organized by directory entry, tracks rule states (active, passive, or deleted), and records violation events. By centralizing compliance rule administration and violation tracking, the server enforces consistent regulatory and risk management policies across the trading platform.<br /> <br /> The Compliance Server integrates with the [[Service Locator]] for authentication and permission verification, the [[Administration Server]] to validate administrator privileges, and a MySQL database to persist compliance rules and violation records.<br /> <br /> == Configuration ==<br /> <br /> The Compliance Server is configured via a YAML file with three top-level sections: <code>server</code>, <code>service_locator</code>, and <code>data_store</code>. Below is the structure of the configuration file with example values:<br /> <br /> <pre><br /> server:<br /> # Primary network interface and port the Compliance Server binds to.<br /> interface: "0.0.0.0:21900"<br /> # List of addresses the server is reachable at (for registration with Service Locator).<br /> # Typically includes both public-facing and local addresses.<br /> addresses: ["198.51.100.5:21900", "10.0.0.5:21900"]<br /> <br /> service_locator:<br /> # The address of the Service Locator (host:port).<br /> address: "10.0.0.5:20000"<br /> # The account username used by the Compliance Server to authenticate with the Service Locator.<br /> username: compliance_server<br /> # The password for the Compliance Server's Service Locator account.<br /> password: [REQUIRED]<br /> <br /> data_store:<br /> # The address of the MySQL server.<br /> address: "127.0.0.1:3306"<br /> # The username used to authenticate with MySQL.<br /> username: spireadmin<br /> # The password for the MySQL user.<br /> password: [REQUIRED]<br /> # The name of the database schema where data is stored.<br /> schema: spire<br /> </pre><br /> <br /> A <code>setup.py</code> script is provided to generate the final <code>config.yml</code> from the <code>config.default.yml</code> template. Usage:<br /> <br /> <pre><br /> --local 0.0.0.0 # Local interface (default: auto-detected IP)<br /> --world 198.51.100.5 # Global/public interface (optional)<br /> --address 10.0.0.5:20000 # Service Locator address (default: local_interface:20000)<br /> --password [REQUIRED] # Service password for authentication<br /> --mysql_address 127.0.0.1:3306 # MySQL server address<br /> --mysql_username spireadmin # MySQL username<br /> --mysql_password secretpw # MySQL password (default: --password if omitted)<br /> </pre><br /> <br /> == Capabilities ==<br /> <br /> The Compliance Server provides the following capabilities:<br /> <br /> === Rule Management ===<br /> <br /> Compliance rules are organized by directory entry (accounts or groups) and consist of:<br /> <br /> * A compliance rule schema defining the rule logic<br /> * Parameters configuring the rule's behavior<br /> * A state indicating whether the rule is active, passive, or deleted<br /> <br /> Administrators can create, update, and delete compliance rules. Rule changes are immediately propagated to subscribed clients for real-time enforcement.<br /> <br /> === Rule Loading and Subscription ===<br /> <br /> Clients can:<br /> <br /> * Load existing compliance rules for a specific directory entry<br /> * Subscribe to receive real-time updates when rules are added, modified, or deleted<br /> <br /> Subscriptions enable clients to maintain synchronized views of active compliance rules without polling.<br /> <br /> === Violation Reporting ===<br /> <br /> Administrators can report compliance rule violations, which are:<br /> <br /> * Persisted to the database for audit purposes<br /> * Associated with the specific account and rule involved<br /> * Timestamped using an NTP-synchronized time client<br /> <br /> == Management ==<br /> <br /> The Compliance Server is controlled using three operational scripts: <code>start.sh</code>, <code>stop.sh</code>, and <code>check.sh</code>.<br /> <br /> === start.sh ===<br /> <br /> * Exits immediately if the server is already running.<br /> * Creates a <code>logs/</code> directory if necessary.<br /> * Moves any existing <code>srv_*.log</code> files into <code>logs/</code>.<br /> * Starts the <code>ComplianceServer</code> process in the background.<br /> * Reads network interfaces from <code>config.yml</code> and waits until the server is listening on at least one configured address.<br /> <br /> This ensures the server is fully initialized before the script exits.<br /> <br /> === stop.sh ===<br /> <br /> * Sends <code>SIGINT</code> to request a graceful shutdown.<br /> * Waits for termination using exponential backoff (up to 300 seconds).<br /> * Sends <code>SIGKILL</code> if the server fails to stop cleanly.<br /> * Appends a forced-termination message to the most recent log file (if applicable).<br /> <br /> This guarantees consistent shutdown behavior across normal and exceptional conditions.<br /> <br /> === check.sh ===<br /> <br /> The <code>check.sh</code> script verifies whether the server is currently running by inspecting the PID recorded in <code>pid.lock</code> and testing whether the associated process exists.<br /> <br /> == Logging ==<br /> <br /> Upon startup, older log files are moved into the <code>logs/</code> directory.</div>

Kamal https://wiki.spiretrading.com/index.php?title=Charting_Server&diff=138 Charting Server 2026-05-27T20:02:09Z

<p>Kamal: Created page with "The Charting Server processes time series queries on market data and publishes ongoing updates to clients. It performs calculations such as candlestick aggregation, technical..."</p> <hr /> <div>The Charting Server processes time series queries on market data and publishes ongoing updates to clients. It performs calculations such as candlestick aggregation, technical indicators, and other analytical transformations over historical and real-time market data. By centralizing these computations, the server enables multiple clients to subscribe to identical chart data without redundant calculation overhead.<br /> <br /> The Charting Server integrates with the [[Service Locator]] for authentication and service registration. Multiple Charting Servers can be deployed concurrently to distribute query processing load across instances, with the Service Locator performing the load balancing among them.<br /> <br /> == Configuration ==<br /> <br /> The Charting Server is configured via a YAML file with two top-level sections: <code>server</code> and <code>service_locator</code>. Below is the structure of the configuration file with example values:<br /> <br /> <pre><br /> server:<br /> # Primary network interface and port the Charting Server binds to.<br /> interface: "0.0.0.0:21400"<br /> # List of addresses the server is reachable at (for registration with Service Locator).<br /> # Typically includes both public-facing and local addresses.<br /> addresses: ["198.51.100.5:21400", "10.0.0.5:21400"]<br /> <br /> service_locator:<br /> # The address of the Service Locator (host:port).<br /> address: "10.0.0.5:20000"<br /> # The account username used by the Charting Server to authenticate with the Service Locator.<br /> username: charting_server<br /> # The password for the Charting Server's Service Locator account.<br /> password: [REQUIRED]<br /> </pre><br /> <br /> A <code>setup.py</code> script is provided to generate the final <code>config.yml</code> from the <code>config.default.yml</code> template. Usage:<br /> <br /> <pre><br /> --local 0.0.0.0 # Local interface (default: auto-detected IP)<br /> --world 198.51.100.5 # Global/public interface (optional)<br /> --address 10.0.0.5:20000 # Service Locator address (default: local_interface:20000)<br /> --password [REQUIRED] # Service password for authentication<br /> </pre><br /> <br /> == Management ==<br /> <br /> The Charting Server is controlled using three operational scripts: <code>start.sh</code>, <code>stop.sh</code>, and <code>check.sh</code>.<br /> <br /> === start.sh ===<br /> <br /> * Exits immediately if the server is already running.<br /> * Creates a <code>logs/</code> directory if necessary.<br /> * Moves any existing <code>srv_*.log</code> files into <code>logs/</code>.<br /> * Starts the <code>ChartingServer</code> process in the background.<br /> * Reads network interfaces from <code>config.yml</code> and waits until the server is listening on at least one configured address.<br /> <br /> This ensures the server is fully initialized before the script exits.<br /> <br /> === stop.sh ===<br /> <br /> * Sends <code>SIGINT</code> to request a graceful shutdown.<br /> * Waits for termination using exponential backoff (up to 300 seconds).<br /> * Sends <code>SIGKILL</code> if the server fails to stop cleanly.<br /> * Appends a forced-termination message to the most recent log file (if applicable).<br /> <br /> This guarantees consistent shutdown behavior across normal and exceptional conditions.<br /> <br /> === check.sh ===<br /> <br /> The <code>check.sh</code> script verifies whether the server is currently running by inspecting the PID recorded in <code>pid.lock</code> and testing whether the associated process exists.<br /> <br /> == Logging ==<br /> <br /> Upon startup, older log files are moved into the <code>logs/</code> directory.</div>

Kamal https://wiki.spiretrading.com/index.php?title=Market_Data_Relay_Server&diff=137 Market Data Relay Server 2026-05-27T19:56:18Z

<p>Kamal: Created page with "The Market Data Relay Server provides load-balanced distribution of market data to end users. It acts as an intermediary layer between the Market Data Server and client ap..."</p> <hr /> <div>The Market Data Relay Server provides load-balanced distribution of market data to end users. It acts as an intermediary layer between the [[Market Data Server]] and client applications, receiving market data updates from the Market Data Server and relaying them to subscribed clients. By deploying multiple relay servers in parallel, the system can distribute client connections across instances, ensuring scalable and resilient market data delivery.<br /> <br /> The Market Data Relay Server integrates with the [[Service Locator]] for authentication and service registration. Multiple relay servers can operate concurrently to distribute load across the infrastructure.<br /> <br /> == Configuration ==<br /> <br /> The Market Data Relay Server is configured via a YAML file with two top-level sections (<code>server</code> and <code>service_locator</code>) plus optional tuning parameters. Below is the structure of the configuration file with example values:<br /> <br /> <pre><br /> server:<br /> # Primary network interface and port the Market Data Relay Server binds to.<br /> interface: "0.0.0.0:22300"<br /> # List of addresses the server is reachable at (for registration with Service Locator).<br /> # Typically includes both public-facing and local addresses.<br /> addresses: ["198.51.100.5:22300", "10.0.0.5:22300"]<br /> <br /> service_locator:<br /> # The address of the Service Locator (host:port).<br /> address: "10.0.0.5:20000"<br /> # The account username used by the Market Data Relay Server to authenticate with the Service Locator.<br /> username: market_data_relay_server<br /> # The password for the Market Data Relay Server's Service Locator account.<br /> password: [REQUIRED]<br /> <br /> # Optional timeout for upstream Market Data Server connections (default: 500 ms).<br /> connection_timeout: 500ms<br /> <br /> # Optional minimum pool size for upstream connections (default: hardware concurrency).<br /> min_connections: 8<br /> <br /> # Optional maximum pool size for upstream connections (default: 10 * min_connections).<br /> max_connections: 80<br /> </pre><br /> <br /> A <code>setup.py</code> script is provided to generate the final <code>config.yml</code> from the <code>config.default.yml</code> template. Usage:<br /> <br /> <pre><br /> --local 0.0.0.0 # Local interface (default: auto-detected IP)<br /> --world 198.51.100.5 # Global/public interface (optional)<br /> --address 10.0.0.5:20000 # Service Locator address (default: local_interface:20000)<br /> --password [REQUIRED] # Service password for authentication<br /> </pre><br /> <br /> == Architecture ==<br /> <br /> The market data distribution architecture consists of three tiers:<br /> <br /> # '''Feed Clients''' publish raw market data to the Market Data Server.<br /> # '''Market Data Server''' organizes, sequences, and persists market data.<br /> # '''Market Data Relay Servers''' distribute market data to end-user clients.<br /> <br /> This architecture separates data processing from distribution, allowing the Market Data Server to focus on sequencing and storage while relay servers handle the potentially large number of client connections. Multiple relay servers can be deployed to distribute client load geographically or by capacity requirements.<br /> <br /> When multiple Market Data Servers are registered with the Service Locator (each potentially serving different country scopes), the relay server connects to all of them and routes client subscriptions to the appropriate upstream based on the country associated with each security.<br /> <br /> == Management ==<br /> <br /> The Market Data Relay Server is controlled using three operational scripts: <code>start.sh</code>, <code>stop.sh</code>, and <code>check.sh</code>.<br /> <br /> === start.sh ===<br /> <br /> * Exits immediately if the server is already running.<br /> * Creates a <code>logs/</code> directory if necessary.<br /> * Moves any existing <code>srv_*.log</code> files into <code>logs/</code>.<br /> * Starts the <code>MarketDataRelayServer</code> process in the background.<br /> * Reads network interfaces from <code>config.yml</code> and waits until the server is listening on at least one configured address.<br /> <br /> This ensures the server is fully initialized before the script exits.<br /> <br /> === stop.sh ===<br /> <br /> * Sends <code>SIGINT</code> to request a graceful shutdown.<br /> * Waits for termination using exponential backoff (up to 300 seconds).<br /> * Sends <code>SIGKILL</code> if the server fails to stop cleanly.<br /> * Appends a forced-termination message to the most recent log file (if applicable).<br /> <br /> This guarantees consistent shutdown behavior across normal and exceptional conditions.<br /> <br /> === check.sh ===<br /> <br /> The <code>check.sh</code> script verifies whether the server is currently running by inspecting the PID recorded in <code>pid.lock</code> and testing whether the associated process exists.<br /> <br /> == Logging ==<br /> <br /> Upon startup, older log files are moved into the <code>logs/</code> directory.</div>

Kamal https://wiki.spiretrading.com/index.php?title=Market_Data_Server&diff=136 Market Data Server 2026-05-27T19:54:00Z

<p>Kamal: Created page with "The Market Data Server receives market data from feed clients, organizes and persists the data, and provides query and subscription services to clients. It maintains real-time..."</p> <hr /> <div>The Market Data Server receives market data from feed clients, organizes and persists the data, and provides query and subscription services to clients. It maintains real-time market data snapshots for each security, tracks security technicals (open, high, low, close, volume), and sequences all market data updates to ensure consistent ordering across the system. The server supports multiple market data types including best bid/offer quotes, book quotes, time and sales, and order imbalances.<br /> <br /> The Market Data Server integrates with the [[Service Locator]] for authentication and a MySQL database for historical data storage. It operates as two distinct services: a '''registry server''' for managing security metadata and subscriptions, and a '''feed server''' for receiving and distributing market data updates.<br /> <br /> == Configuration ==<br /> <br /> The Market Data Server is configured via a YAML file with five top-level sections: <code>service_locator</code>, <code>registry_server</code>, <code>feed_server</code>, <code>data_store</code>, and an optional <code>countries</code> filter. A <code>cache_block_size</code> may also be specified. Below is the structure of the configuration file with example values:<br /> <br /> <pre><br /> service_locator:<br /> # The address of the Service Locator (host:port).<br /> address: "10.0.0.5:20000"<br /> # The account username used by the Market Data Server to authenticate with the Service Locator.<br /> username: market_data_server<br /> # The password for the Market Data Server's Service Locator account.<br /> password: [REQUIRED]<br /> <br /> registry_server:<br /> # Primary network interface and port the Market Data Registry Server binds to.<br /> interface: "0.0.0.0:20300"<br /> # List of addresses the registry server is reachable at (for registration with Service Locator).<br /> addresses: ["198.51.100.5:20300", "10.0.0.5:20300"]<br /> <br /> feed_server:<br /> # Primary network interface and port the Market Data Feed Server binds to.<br /> interface: "0.0.0.0:20400"<br /> # List of addresses the feed server is reachable at (for registration with Service Locator).<br /> addresses: ["198.51.100.5:20400", "10.0.0.5:20400"]<br /> <br /> data_store:<br /> # The address of the MySQL server.<br /> address: "127.0.0.1:3306"<br /> # The username used to authenticate with MySQL.<br /> username: spireadmin<br /> # The password for the MySQL user.<br /> password: [REQUIRED]<br /> # The name of the database schema where data is stored.<br /> schema: spire<br /> <br /> # Optional restriction of market data to specified countries (by ISO code).<br /> countries: ["US", "CA"]<br /> <br /> # Number of records to buffer per write to the historical data store (default: 1000).<br /> cache_block_size: 1000<br /> </pre><br /> <br /> A <code>setup.py</code> script is provided to generate the final <code>config.yml</code> from the <code>config.default.yml</code> template. Usage:<br /> <br /> <pre><br /> --local 0.0.0.0 # Local interface (default: auto-detected IP)<br /> --world 198.51.100.5 # Global/public interface (optional)<br /> --address 10.0.0.5:20000 # Service Locator address (default: local_interface:20000)<br /> --password [REQUIRED] # Service password for authentication<br /> --mysql_address 127.0.0.1:3306 # MySQL server address<br /> --mysql_username spireadmin # MySQL username<br /> --mysql_password secretpw # MySQL password (default: --password if omitted)<br /> </pre><br /> <br /> == Market Data Types ==<br /> <br /> The server processes and distributes the following market data types:<br /> <br /> * '''BBO Quotes''' (Best Bid/Offer) - Top-of-book bid and ask prices with sizes<br /> * '''Book Quotes''' - Full order book depth with multiple price levels per side<br /> * '''Time and Sales''' - Executed trade prices, sizes, and timestamps<br /> * '''Order Imbalances''' - Pre-opening and closing auction imbalance data<br /> <br /> In addition to raw market data, the server publishes:<br /> <br /> * Real-time market data snapshots combining BBO, book depth, and last trade<br /> * Security technicals including open, high, low, close, and volume<br /> * Sequence numbers ensuring consistent ordering of market data updates<br /> * Source tracking to identify which feed client published each data point<br /> <br /> All market data updates are assigned monotonically increasing sequence numbers per security and data type. This ensures clients can detect gaps, maintain consistent ordering, and synchronize state reliably.<br /> <br /> == Storage ==<br /> <br /> Market data is persisted to MySQL with indexed queries supporting:<br /> <br /> * Efficient storage of high-frequency data streams<br /> * Time-bounded historical queries<br /> * Per-security and per-data-type lookups<br /> <br /> == Utility Scripts ==<br /> <br /> A utility script is provided to add or update security metadata in the system.<br /> <br /> A backup and restore utility supports bidirectional data transfer between MySQL and SQLite:<br /> <br /> <pre><br /> --config config.yml # Configuration file<br /> --start "2024-01-01 00:00:00" # Start time range<br /> --end "2024-12-31 23:59:59" # End time range<br /> --output backup.db # Export MySQL to SQLite<br /> --cores 8 # Number of parallel workers<br /> </pre><br /> <br /> The script uses multiprocessing to efficiently backup or restore large datasets across multiple securities and venues in parallel.<br /> <br /> == Management ==<br /> <br /> The Market Data Server is controlled using three operational scripts: <code>start.sh</code>, <code>stop.sh</code>, and <code>check.sh</code>.<br /> <br /> === start.sh ===<br /> <br /> * Exits immediately if the server is already running.<br /> * Creates a <code>logs/</code> directory if necessary.<br /> * Moves any existing <code>srv_*.log</code> files into <code>logs/</code>.<br /> * Starts the <code>MarketDataServer</code> process in the background.<br /> * Reads network interfaces from <code>config.yml</code> and waits until the server is listening on at least one configured address.<br /> <br /> This ensures the server is fully initialized before the script exits.<br /> <br /> === stop.sh ===<br /> <br /> * Sends <code>SIGINT</code> to request a graceful shutdown.<br /> * Waits for termination using exponential backoff (up to 300 seconds).<br /> * Sends <code>SIGKILL</code> if the server fails to stop cleanly.<br /> * Appends a forced-termination message to the most recent log file (if applicable).<br /> <br /> This guarantees consistent shutdown behavior across normal and exceptional conditions.<br /> <br /> === check.sh ===<br /> <br /> The <code>check.sh</code> script verifies whether the server is currently running by inspecting the PID recorded in <code>pid.lock</code> and testing whether the associated process exists.<br /> <br /> == Logging ==<br /> <br /> Upon startup, older log files are moved into the <code>logs/</code> directory.</div>

Kamal https://wiki.spiretrading.com/index.php?title=Definitions_Server&diff=135 Definitions Server 2026-05-27T19:51:39Z

<p>Kamal: Created page with "The Definitions Server provides centralized reference data for the trading platform. It disseminates system-wide definitions including country codes, currencies, trading venue..."</p> <hr /> <div>The Definitions Server provides centralized reference data for the trading platform. It disseminates system-wide definitions including country codes, currencies, trading venues, order routing destinations, time zones, exchange rates, compliance rule schemas, and trading schedules. By centralizing these definitions, the server ensures consistent metadata across all components of the system.<br /> <br /> The Definitions Server integrates with the [[Service Locator]] for authentication and service registration. All reference data is loaded from YAML and CSV configuration files at startup.<br /> <br /> == Configuration ==<br /> <br /> The Definitions Server is configured via a YAML file with two top-level sections (<code>server</code> and <code>service_locator</code>) plus several inline fields that specify reference data files and platform metadata. Below is the structure of the configuration file with example values:<br /> <br /> <pre><br /> server:<br /> # Primary network interface and port the Definitions Server binds to.<br /> interface: "0.0.0.0:20200"<br /> # List of addresses the server is reachable at (for registration with Service Locator).<br /> # Typically includes both public-facing and local addresses.<br /> addresses: ["198.51.100.5:20200", "10.0.0.5:20200"]<br /> <br /> service_locator:<br /> # The address of the Service Locator (host:port).<br /> address: "10.0.0.5:20000"<br /> # The account username used by the Definitions Server to authenticate with the Service Locator.<br /> username: definitions_server<br /> # The password for the Definitions Server's Service Locator account.<br /> password: [REQUIRED]<br /> <br /> # Minimum version of the Spire client required to connect.<br /> minimum_spire_version: "1234"<br /> <br /> # Name of the organization operating the platform.<br /> organization: "Spire Trading Inc."<br /> <br /> # Paths to reference data files.<br /> time_zones: "time_zones.csv"<br /> countries: "countries.yml"<br /> currencies: "currencies.yml"<br /> venues: "venues.yml"<br /> destinations: "destinations.yml"<br /> <br /> # Exchange rates between currency pairs.<br /> exchange_rates:<br /> - symbol: "USD/CAD"<br /> rate: "1.35"<br /> <br /> # NTP servers registered as time service endpoints.<br /> ntp_pool: ["pool.ntp.org:123"]<br /> </pre><br /> <br /> A <code>setup.py</code> script is provided to generate the final <code>config.yml</code> from the <code>config.default.yml</code> template. The script also copies default reference data files if they do not already exist. Usage:<br /> <br /> <pre><br /> --local 0.0.0.0 # Local interface (default: auto-detected IP)<br /> --world 198.51.100.5 # Global/public interface (optional)<br /> --address 10.0.0.5:20000 # Service Locator address (default: local_interface:20000)<br /> --password [REQUIRED] # Service password for authentication<br /> </pre><br /> <br /> == Reference Data Files ==<br /> <br /> The Definitions Server loads reference data from the following files:<br /> <br /> === countries.yml ===<br /> <br /> Defines country codes according to the ISO 3166 standard. A utility script (<code>update_countries.sh</code>) is provided to download and update country definitions from the official ISO 3166 data source. The script uses <code>country_code_parser.py</code> to parse the CSV data and generate the YAML file.<br /> <br /> === currencies.yml ===<br /> <br /> Defines currencies including their codes, names, and decimal places.<br /> <br /> === venues.yml ===<br /> <br /> Defines trading venues (exchanges and markets) including their country, time zone, and currency.<br /> <br /> === destinations.yml ===<br /> <br /> Defines order routing destinations and their applicable venues. Preferred destinations specify default routing per venue.<br /> <br /> === time_zones.csv ===<br /> <br /> Contains time zone database information in CSV format for accurate timestamp conversion across regions.<br /> <br /> === trading_schedule.yml ===<br /> <br /> Defines market hours, holidays, and trading events.<br /> <br /> == Management ==<br /> <br /> The Definitions Server is controlled using three operational scripts: <code>start.sh</code>, <code>stop.sh</code>, and <code>check.sh</code>.<br /> <br /> === start.sh ===<br /> <br /> * Exits immediately if the server is already running.<br /> * Creates a <code>logs/</code> directory if necessary.<br /> * Moves any existing <code>srv_*.log</code> files into <code>logs/</code>.<br /> * Starts the <code>DefinitionsServer</code> process in the background.<br /> * Reads network interfaces from <code>config.yml</code> and waits until the server is listening on at least one configured address.<br /> <br /> This ensures the server is fully initialized before the script exits.<br /> <br /> === stop.sh ===<br /> <br /> * Sends <code>SIGINT</code> to request a graceful shutdown.<br /> * Waits for termination using exponential backoff (up to 300 seconds).<br /> * Sends <code>SIGKILL</code> if the server fails to stop cleanly.<br /> * Appends a forced-termination message to the most recent log file (if applicable).<br /> <br /> This guarantees consistent shutdown behavior across normal and exceptional conditions.<br /> <br /> === check.sh ===<br /> <br /> The <code>check.sh</code> script verifies whether the server is currently running by inspecting the PID recorded in <code>pid.lock</code> and testing whether the associated process exists.<br /> <br /> == Logging ==<br /> <br /> Upon startup, older log files are moved into the <code>logs/</code> directory.</div>

Kamal https://wiki.spiretrading.com/index.php?title=Web_Portal&diff=134 Web Portal 2026-05-27T19:49:40Z

<p>Kamal: Created page with "The Web Portal provides web-based access to account management and administrative functions through both a web API and an interactive HTML interface. It serves as the primary..."</p> <hr /> <div>The Web Portal provides web-based access to account management and administrative functions through both a web API and an interactive HTML interface. It serves as the primary user interface for creating and managing trading accounts, configuring market data entitlements, defining compliance rules, setting risk parameters, and monitoring account activity. By aggregating functionality from multiple backend services, the Web Portal enables administrators and managers to perform operational tasks through a unified web application.<br /> <br /> The Web Portal integrates with the [[Service Locator]] for authentication and communicates with the [[Administration Server]], [[Compliance Server]], [[Risk Server]], and [[Order Execution Server]] to provide comprehensive account management capabilities.<br /> <br /> == Configuration ==<br /> <br /> The Web Portal is configured via a YAML file with two top-level sections: <code>server</code> and <code>service_locator</code>, plus an optional <code>url</code> field. Below is the structure of the configuration file with example values:<br /> <br /> <pre><br /> server:<br /> # Primary network interface and port the Web Portal binds to.<br /> interface: "0.0.0.0:8080"<br /> # List of addresses the server is reachable at (for registration with Service Locator).<br /> # Typically includes both public-facing and local addresses.<br /> addresses: ["198.51.100.5:8080", "10.0.0.5:8080"]<br /> <br /> service_locator:<br /> # The address of the Service Locator (host:port).<br /> address: "10.0.0.5:20000"<br /> # The account username used by the Web Portal to authenticate with the Service Locator.<br /> username: web_portal<br /> # The password for the Web Portal's Service Locator account.<br /> password: [REQUIRED]<br /> <br /> # Optional public URL registered with the Service Locator (defaults to http://<interface>).<br /> url: "https://portal.example.com"<br /> </pre><br /> <br /> A <code>setup.py</code> script is provided to generate the final <code>config.yml</code> from the <code>config.default.yml</code> template. Usage:<br /> <br /> <pre><br /> --local 0.0.0.0 # Local interface (default: auto-detected IP)<br /> --world 198.51.100.5 # Global/public interface (optional)<br /> --address 10.0.0.5:20000 # Service Locator address (default: local_interface:20000)<br /> --password [REQUIRED] # Service password for authentication<br /> </pre><br /> <br /> == Capabilities ==<br /> <br /> The Web Portal provides access to the following administrative and operational capabilities:<br /> <br /> * Configure account permissions and access controls<br /> * Set account roles (trader, manager, administrator, service)<br /> * Configure per-venue and per-message-type permissions<br /> * Assign rules to accounts, groups, or directories<br /> * Configure rule states (active, passive, disabled)<br /> <br /> == Permissions ==<br /> <br /> The Web Portal enforces permissions based on account roles:<br /> <br /> * '''Administrators''' have full access to all management functions<br /> * '''Managers''' can manage accounts within their assigned groups<br /> * '''Traders''' can view their own account details and activity<br /> * '''Service''' accounts have restricted programmatic access<br /> <br /> All operations are authenticated through the Service Locator and logged for audit purposes.<br /> <br /> == Management ==<br /> <br /> The Web Portal is controlled using three operational scripts: <code>start.sh</code>, <code>stop.sh</code>, and <code>check.sh</code>.<br /> <br /> === start.sh ===<br /> <br /> * Exits immediately if the server is already running.<br /> * Creates a <code>logs/</code> directory if necessary.<br /> * Moves any existing <code>srv_*.log</code> files into <code>logs/</code>.<br /> * Starts the <code>WebPortal</code> process in the background.<br /> * Reads network interfaces from <code>config.yml</code> and waits until the server is listening on at least one configured address.<br /> <br /> This ensures the server is fully initialized before the script exits.<br /> <br /> === stop.sh ===<br /> <br /> * Sends <code>SIGINT</code> to request a graceful shutdown.<br /> * Waits for termination using exponential backoff (up to 300 seconds).<br /> * Sends <code>SIGKILL</code> if the server fails to stop cleanly.<br /> * Appends a forced-termination message to the most recent log file (if applicable).<br /> <br /> This guarantees consistent shutdown behavior across normal and exceptional conditions.<br /> <br /> === check.sh ===<br /> <br /> The <code>check.sh</code> script verifies whether the server is currently running by inspecting the PID recorded in <code>pid.lock</code> and testing whether the associated process exists.<br /> <br /> == Logging ==<br /> <br /> Upon startup, older log files are moved into the <code>logs/</code> directory.</div>

Kamal https://wiki.spiretrading.com/index.php?title=Administration_Server&diff=133 Administration Server 2026-05-27T19:47:52Z

<p>Kamal: Created page with "The Administration Server manages account-level authorization and operational metadata for Spire. It maintains each account's role (trader, manager, administrator, or service)..."</p> <hr /> <div>The Administration Server manages account-level authorization and operational metadata for Spire. It maintains each account's role (trader, manager, administrator, or service), market-data entitlements, risk parameters, and trading permissions. By centralizing these attributes, it enforces access control, entitlement visibility, and trading eligibility across the system.<br /> <br /> The server integrates with the [[Service Locator]] to enumerate accounts and with a MySQL database to persist administrative data.<br /> <br /> == Configuration ==<br /> <br /> The Administration Server is configured via a YAML file with four top-level sections: <code>data_store</code>, <code>server</code>, <code>service_locator</code>, and <code>entitlements</code>. A <code>grant_interval</code> setting may also be specified. Below is the structure of the configuration file with example values:<br /> <br /> <pre><br /> data_store:<br /> # The address of the MySQL server.<br /> address: "127.0.0.1:3306"<br /> # The username used to authenticate with MySQL.<br /> username: spireadmin<br /> # The password for the MySQL user.<br /> password: [REQUIRED]<br /> # The name of the database schema where data is stored.<br /> schema: spire<br /> <br /> server:<br /> # Primary network interface and port the Administration Server binds to.<br /> interface: "0.0.0.0:20100"<br /> # List of addresses the server is reachable at (for registration with Service Locator).<br /> # Typically includes both public-facing and local addresses.<br /> addresses: ["198.51.100.5:20100", "10.0.0.5:20100"]<br /> <br /> service_locator:<br /> # The address of the Service Locator (host:port).<br /> address: "10.0.0.5:20000"<br /> # The account username used to authenticate with the Service Locator.<br /> username: administration_server<br /> # The password for the Service Locator account.<br /> password: [REQUIRED]<br /> <br /> # Each entitlement specifies pricing, applicable exchanges, and message types.<br /> entitlements:<br /> - name: "NYSE Basic"<br /> price: "10.00"<br /> currency: USD<br /> group: nyse_basic<br /> applicability:<br /> - venue: XNYS<br /> # source: the venue disseminating the market data<br /> source: XNYS<br /> messages: [BBO, TAS]<br /> <br /> # Interval at which entitlement grants are reapplied (default: 1 hour).<br /> grant_interval: 1h<br /> </pre><br /> <br /> A <code>setup.py</code> script is provided to generate the final <code>config.yml</code>. Usage:<br /> <br /> <pre><br /> --local 0.0.0.0 # Local interface (default: auto-detected IP)<br /> --world 198.51.100.5 # Global/public interface (optional)<br /> --address 10.0.0.5:20000 # Service Locator address (default: local_interface:20000)<br /> --password [REQUIRED] # Admin password for Service Locator<br /> --mysql_address 127.0.0.1:3306 # MySQL server address<br /> --mysql_password secretpw # MySQL password (default: --password if omitted)<br /> </pre><br /> <br /> A reset script (<code>reset_risk_states.py</code>) is provided to initialize or reset the risk state for all accounts and is typically run on a daily basis.<br /> <br /> == Management ==<br /> <br /> The Administration Server is controlled using three operational scripts: <code>start.sh</code>, <code>stop.sh</code>, and <code>check.sh</code>.<br /> <br /> === start.sh ===<br /> <br /> * Exits immediately if the server is already running.<br /> * Creates a <code>logs/</code> directory if necessary.<br /> * Moves any existing <code>srv_*.log</code> files into <code>logs/</code>.<br /> * Starts the <code>AdministrationServer</code> process in the background.<br /> * Reads network interfaces from <code>config.yml</code> and waits until the server is listening on at least one configured address.<br /> <br /> This ensures the server is fully initialized before the script exits.<br /> <br /> === stop.sh ===<br /> <br /> * Sends <code>SIGINT</code> to request a graceful shutdown.<br /> * Waits for termination using exponential backoff (up to 300 seconds).<br /> * Sends <code>SIGKILL</code> if the server fails to stop cleanly.<br /> * Appends a forced-termination message to the most recent log file (if applicable).<br /> <br /> This guarantees consistent shutdown behavior across normal and exceptional conditions.<br /> <br /> === check.sh ===<br /> <br /> The <code>check.sh</code> script verifies whether the server is currently running by inspecting the PID recorded in <code>pid.lock</code> and testing whether the associated process exists.<br /> <br /> == Logging ==<br /> <br /> Upon startup, older log files are moved into the <code>logs/</code> directory.</div>

Kamal https://wiki.spiretrading.com/index.php?title=Uid_Server&diff=132 Uid Server 2026-05-27T19:43:54Z

<p>Kamal: Created page with "The Uid Server is a centralized service responsible for generating batches of unique integers that can be used to identify items, such as database entries. The Uid Server regi..."</p> <hr /> <div>The Uid Server is a centralized service responsible for generating batches of unique integers that can be used to identify items, such as database entries. The Uid Server registers itself with the [[Service Locator]] as a <code>uid_server</code> and ensures uniqueness by tracking allocated identifiers in a MySQL database.<br /> <br /> == Configuration ==<br /> <br /> The Uid Server is configured via a YAML file with three top-level sections: <code>data_store</code>, <code>server</code>, and <code>service_locator</code>. Below is the structure of the configuration file with example values:<br /> <br /> <pre><br /> data_store:<br /> # The address of the MySQL server.<br /> address: "127.0.0.1:3306"<br /> # The username used to authenticate with MySQL.<br /> username: spireadmin<br /> # The password for the MySQL user.<br /> password: [REQUIRED]<br /> # The name of the database schema where data is stored.<br /> schema: spire<br /> <br /> server:<br /> # The network interface and port the Uid Server binds to.<br /> interface: "0.0.0.0:20900"<br /> # List of addresses the server advertises for client connections.<br /> addresses: ["192.168.1.100:20900", "0.0.0.0:20900"]<br /> <br /> service_locator:<br /> # The address of the Service Locator (host:port).<br /> address: "127.0.0.1:20000"<br /> # The account username used to authenticate with the Service Locator.<br /> username: uid_server<br /> # The password for the Service Locator account.<br /> password: [REQUIRED]<br /> </pre><br /> <br /> A Python script automates configuration file generation. Usage:<br /> <br /> <pre><br /> --local 0.0.0.0 # Local interface (default: auto-detected IP)<br /> --world 192.168.1.100 # Global interface (default: same as local)<br /> --address 127.0.0.1:20000 # Service Locator address<br /> --password [REQUIRED] # Admin password for Service Locator<br /> --mysql_address 127.0.0.1:3306 # MySQL server address<br /> --mysql_username admin # MySQL username (default: spireadmin)<br /> --mysql_password [OPTIONAL] # MySQL password (default: same as admin password)<br /> --mysql_schema uid_db # Database schema (default: spire)<br /> </pre><br /> <br /> The script:<br /> * Generates <code>config.yml</code> from <code>config.default.yml</code> template.<br /> * Requires only the <code>--password</code> argument by default.<br /> <br /> == Logging ==<br /> <br /> Log files are generated as <code>srv_[YYYY][MM][DD]_[HH]_[MM]_[SS].log</code> in the runtime directory. Upon termination, non-empty log files are moved into the <code>log/</code> subfolder, while empty log files are deleted.<br /> <br /> == Management ==<br /> <br /> The Uid Server is managed through three core scripts:<br /> <br /> * <code>start.sh</code> - Starts the Uid Server. Does nothing if the server is already running.<br /> * <code>stop.sh</code> - Stops an existing server instance and waits for the server to terminate.<br /> * <code>check.sh</code> - Verifies that the server is running and reports its status.</div>

Kamal https://wiki.spiretrading.com/index.php?title=Service_Locator&diff=131 Service Locator 2026-05-27T19:41:19Z

<p>Kamal: Created page with "The Service Locator is a centralized server responsible for authenticating account logins, creating and managing user accounts, organizing accounts into directories, controlli..."</p> <hr /> <div>The Service Locator is a centralized server responsible for authenticating account logins, creating and managing user accounts, organizing accounts into directories, controlling permissions, and registering available services. It acts as a critical component for coordinating access control and service discovery. The Service Locator integrates with a MySQL database to persistently store account details, directory structures, permissions, and service registration data.<br /> <br /> == Configuration ==<br /> <br /> The Service Locator is configured via a YAML file that defines its network interface and data store settings. Below is the structure of the configuration file with example values:<br /> <br /> <pre><br /> # The network interface and port the Service Locator binds to.<br /> interface: "0.0.0.0:20000"<br /> <br /> data_store:<br /> # The address of the MySQL server.<br /> address: "127.0.0.1:3306"<br /> # The username used to authenticate with MySQL.<br /> username: spireadmin<br /> # The password for the MySQL user.<br /> password: 1234<br /> # The name of the database schema where data is stored.<br /> schema: spire<br /> </pre><br /> <br /> A <code>setup.py</code> script is provided for convenience to configure the Service Locator and generate the <code>config.yml</code> file. The script supports the following arguments:<br /> <br /> <pre><br /> --local 0.0.0.0 # Local interface (default: auto-detected IP)<br /> --mysql_address 127.0.0.1:3306 # MySQL server address<br /> --mysql_username admin # MySQL username (default: spireadmin)<br /> --mysql_password [REQUIRED] # MySQL password (no default)<br /> --mysql_schema service_db # Database schema (default: spire)<br /> </pre><br /> <br /> == Logging ==<br /> <br /> Log files are generated as <code>srv_[YYYY][MM][DD]_[HH]_[MM]_[SS].log</code> in the runtime directory. Upon termination, non-empty log files are moved into the <code>log/</code> subfolder, while empty log files are deleted.<br /> <br /> == Management ==<br /> <br /> The Service Locator is managed through three core scripts:<br /> <br /> * <code>start.sh</code> - Starts the Service Locator server. Does nothing if the server is already running.<br /> * <code>stop.sh</code> - Stops an existing server instance and waits for the server to terminate.<br /> * <code>check.sh</code> - Verifies that the server is running and reports its status.</div>

Kamal https://wiki.spiretrading.com/index.php?title=Spire_Services&diff=130 Spire Services 2026-05-27T19:38:19Z

<p>Kamal: Created page with "Spire is a distributed trading platform composed of multiple specialized servers that work together to provide a complete trading infrastructure. Each server is independently..."</p> <hr /> <div>Spire is a distributed trading platform composed of multiple specialized servers that work together to provide a complete trading infrastructure. Each server is independently deployable, communicates through well-defined service interfaces, and authenticates through a central Service Locator.<br /> <br /> == Architecture Principles ==<br /> <br /> * '''Service-Oriented Design''' - Each server provides a focused set of functionality<br /> * '''Distributed Deployment''' - Services can be deployed across multiple machines for scalability<br /> * '''Centralized Authentication''' - All services authenticate through the Service Locator<br /> * '''Persistent Storage''' - Critical data persisted to MySQL for durability<br /> * '''Real-time Updates''' - Services publish updates to subscribed clients<br /> <br /> == Servers ==<br /> <br /> * '''[[Service Locator]]''' - Centralized authentication, account management, and service discovery<br /> * '''[[Uid Server]]''' - Generates unique identifiers for orders and other entities<br /> * '''[[Administration Server]]''' - Manages account roles, entitlements, risk parameters, and trading permissions<br /> * '''[[Web Portal]]''' - Web-based interface for account management and administrative tasks<br /> * '''[[Definitions Server]]''' - Provides reference data (countries, currencies, venues, trading schedules)<br /> * '''[[Market Data Server]]''' - Receives, sequences, and persists market data from feed clients<br /> * '''[[Market Data Relay Server]]''' - Load-balanced distribution of market data to end users<br /> * '''[[Charting Server]]''' - Processes time series queries for candlestick and technical analysis data<br /> * '''[[Compliance Server]]''' - Manages compliance rules and monitors violations<br /> * '''[[Risk Server]]''' - Monitors profit/loss, enforces risk limits, manages account state transitions<br /> * '''[[Order Execution Server]]''' - Routes orders to venues, tracks execution, enforces controls<br /> <br /> == Operations ==<br /> <br /> All servers follow consistent operational patterns. In addition to individual server management scripts, the platform provides aggregate scripts for managing all servers collectively.<br /> <br /> === Installation ===<br /> <br /> The <code>install.sh</code> script is designed for the latest Ubuntu Server LTS and performs a complete system installation including:<br /> <br /> * Installing system dependencies (build tools, MySQL, Node.js, Python packages)<br /> * Configuring MySQL database and creating the spire schema<br /> * Creating service accounts in the Service Locator<br /> * Setting up initial permissions and directory structure<br /> * Configuring all servers with appropriate network settings<br /> <br /> The installation script automatically creates service accounts for all servers and assigns them to the appropriate permission groups.<br /> <br /> === Configuration ===<br /> <br /> The <code>setup.py</code> script configures all servers by propagating common settings across individual server configurations. This script calls each server's individual setup script with appropriate parameters, ensuring consistent configuration across the platform.<br /> <br /> === Starting and Stopping ===<br /> <br /> The <code>start.sh</code> script starts all servers in dependency order. After starting all servers, the script automatically runs <code>reset_risk_states.py</code> to initialize risk state for the trading session.<br /> <br /> The <code>stop.sh</code> script gracefully stops all servers in reverse dependency order, ensuring that dependent services shut down before the services they depend on.<br /> <br /> The <code>check.sh</code> script verifies that all servers are running and reports the status of each service. It exits with a non-zero status if any server is not running, making it suitable for monitoring and health check automation.</div>

Kamal https://wiki.spiretrading.com/index.php?title=MediaWiki:Common.css&diff=103 MediaWiki:Common.css 2020-04-28T16:33:08Z

<p>Kamal: </p> <hr /> <div>/* CSS placed here will be applied to all skins */<br /> <br /> <br /> @import url('https://fonts.googleapis.com/css?family=Montserrat&display=swap');<br /> <br /> <br /> /*** SELECTORS ***/<br /> <br /> html, body {<br /> font-family: Roboto, sans-serif;<br /> line-height: 18pt;<br /> }<br /> <br /> <br /> body {<br /> background-color: #FFF;<br /> background-image: url('https://wiki.spiretrading.com/images/b/bd/Footer.pattern.png');<br /> background-repeat: repeat-x;<br /> background-position: bottom center;<br /> background-size: 20%;<br /> }<br /> <br /> a, #mw-panel .portal .body li a {<br /> color: #4B23A0;<br /> }<br /> <br /> h1, h2, h3, h4, h5, h6 {<br /> font-family: 'Montserrat', sans-serif;<br /> }<br /> <br /> #mw-page-base {<br /> background-image: none;<br /> background-color: #FFF;<br /> }<br /> <br /> <br /> /*** IDENTIFIERS ***/<br /> <br /> #pt-login-private a {<br /> color: #EC228F !important;<br /> }<br /> <br /> #p-logo {<br /> height: 70px !important;<br /> }<br /> <br /> <br /> /*** CLASSES ***/<br /> <br /> /* RESETTING GRADIENTS AND HEADINGD */<br /> .vectorTabs, .vectorTabs span, #mw-head .vectorMenu h3, .vectorTabs li {<br /> background-image: none !important;<br /> }<br /> <br /> /* LOGO */<br /> .mw-wiki-logo {<br /> background-position: left 20px top 20px !important;<br /> }<br /> <br /> .mw-body h1, .mw-body-content h1, .mw-body-content h2 {<br /> font-family: 'Montserrat', sans-serif;<br /> }<br /> <br /> <br /> .vectorTabs .selected {<br /> border-bottom: 2px solid #4B23A0;<br /> }<br /> <br /> .mw-body {<br /> border-color: #C8C8C8 !important;<br /> }<br /> <br /> .toc {<br /> background: #F8F9FA;<br /> border-color: #F2F2F2;<br /> margin: 15px 0;<br /> padding: 15px;<br /> }<br /> <br /> <br /> /*** SKIN: TWEEKI CUSTOMIZATIONS ***/<br /> <br /> .navbar-brand img {<br /> margin-top: -5px;<br /> width: 136.5px;<br /> height: 35px;<br /> }<br /> <br /> h1, .h1 {<br /> font-size: 30px;<br /> }<br /> h2, .h2 {<br /> font-size: 27px;<br /> }<br /> h3, .h3 {<br /> font-size: 24px;<br /> }<br /> h4, .h4 {<br /> font-size: 20px;<br /> }<br /> h5, .h5 {<br /> font-size: 18px;<br /> }<br /> h6, .h6 {<br /> font-size: 16px;<br /> }<br /> <br /> h1, .h1, h2, .h2, h3, .h3 {<br /> margin-top: 25px;<br /> margin-bottom: 15px;<br /> }<br /> <br /> .firstHeading, .tweekiFirstHeading {<br /> text-align: left;<br /> margin-bottom: 30px;<br /> }<br /> <br /> .navbar-default {<br /> background-image: none !important;<br /> background-color: #FFF !important;<br /> }<br /> <br /> .btn, #wpSave {<br /> border: 0px !important;<br /> }<br /> <br /> .btn-default, .btn-primary, .btn-success, .btn-info, .btn-warning, .btn-danger, #wpSave {<br /> text-shadow: none !important;<br /> -webkit-box-shadow: none !important;<br /> box-shadow: none !important;<br /> }<br /> <br /> .btn-primary, .mw-ui-button.mw-ui-progressive, #wpSave {<br /> background-image: none;<br /> background-color: #513392;<br /> }<br /> <br /> .btn-primary:hover, .btn-primary:focus, .mw-ui-button.mw-ui-progressive:hover, mw-ui-button.mw-ui-progressive:focus, #wpSave:hover, #wpSave:focus {<br /> background-color: #6556A4;<br /> }<br /> <br /> .btn-primary:active, .mw-ui-button.mw-ui-progressive:active, #wpSave:active {<br /> background-color: #453A70;<br /> }<br /> <br /> a:hover, a:focus {<br /> color: #6556A4;<br /> }<br /> <br /> .navbar-right {<br /> margin-top: 7px;<br /> }<br /> <br /> #searchInput {<br /> margin-top: 5px;<br /> }<br /> <br /> #searchInput:focus {<br /> border: 1px solid #4B23A0;<br /> background-image: none;<br /> outline: 0;<br /> -webkit-box-shadow: none;<br /> box-shadow: none;<br /> }<br /> <br /> #footer {<br /> background-color: #F8F8F8;<br /> padding: 15px;<br /> }<br /> <br /> #footer-icons li:last-child::before {<br /> content: " • ";<br /> }<br /> <br /> td.mw-label {<br /> padding-right: 10px;<br /> }<br /> <br /> @media only screen and (min-width: 1000px){<br /> #contentwrapper {<br /> margin-bottom: 190px !important;<br /> }<br /> }<br /> <br /> .oo-ui-panelLayout-framed {<br /> border: 0 none #FFF;<br /> }</div>

Kamal https://wiki.spiretrading.com/index.php?title=TypeScript_Style_Guide&diff=102 TypeScript Style Guide 2020-04-07T15:49:49Z

<p>Kamal: </p> <hr /> <div>This article specifies the most general guidelines used for all Spire projects written using TypeScript as the primary programming language. Each individual project may extend or override the guidelines specified herein. The overall aim of this guideline is to provide consistency across the numerous projects developed by Spire in order to promote and benefit from modern web development practices as well as tailor them to our specific requirements.<br /> <br /> In general, the guidelines are very specific and opinionated. This is done intentionally to ensure that every detail has been given proper consideration and that every line of code is written with care and diligence. It is taken as a prerequisite that writing robust, clean and maintainable code requires paying close attention to even the smallest of details. As such, when there are two or more ways to write or express any given statement or expression, be it using spaces or tabs, number of characters per line, purple or violet, the guideline will often require that one particular approach be used to the exclusion of others.<br /> <br /> Finally, this document is constantly evolving and as such older projects may not be up-to-date with the guidelines found here. In those circumstances one must use their best judgment about how to integrate these guidelines into older codebases. As a general principle, consistency should favor the local over the global, that is it is more important to be consistent with a function definition than within a file, and more important to be consistent within a file than within a directory, project, etc...<br /> <br /> =Development Environment=<br /> <br /> The primary operating systems supported by Spire projects are Ubuntu 18.02 LTS, Windows 10, and macOS. On all systems, nodejs is used as the build system and webpack is used as the bundler.<br /> <br /> For source control, git is used and projects are to be hosted on [https://github.com/spiretrading Spire Trading's Github page].<br /> <br /> Each developer is welcome to use an editor of their choice, however [https://code.visualstudio.com/ Visual Studio Code] is recommended.<br /> <br /> =File Names=<br /> <br /> Use [https://en.wikipedia.org/wiki/Snake_case snake case] using all lower case letters for files and directories. The name of a file should correspond to the primary class that it exports.<br /> <br /> The default extension for TypeScript files is ''ts''<br /> <br /> The extension used for TypeScript files containing JSX is ''tsx''<br /> <br /> All files end with a single new line character.<br /> <br /> =Directory Structure=<br /> <br /> A project is broken down into a library component, a test component, and one or more application components. These components are referred to as ''artifacts''. The applications go into their own ''applications'' directory and the libraries into the ''library'' directory. Within each artifact is a ''build'' directory containing the build scripts needed to build that artifact. Scripts for POSIX systems are found in the ''posix'' sub-directory and Windows build files are within the ''windows'' sub-directory. The build scripts specified are ''setup'' to download and install any dependencies needed to produce the artifact and the ''build'' script which produces the artifact. Typically the ''setup'' script is run only once or when a new dependency is introduced to the project, and the ''build'' script is run anytime a new build is needed.<br /> <br /> Finally there is a top-level ''build'' directory for the project as a whole which produces all artifacts by recursively calling each artifact's individual build scripts. Additionally the top-level build directory also includes a ''setup'' script which downloads all third party dependencies. Some projects may also opt to include an ''install'' script which sets up a suitable development environment, and other scripts for continuous builds, deployment and testing.<br /> <br /> Assuming a project named sudoku the following directory structure should be used:<br /> <br /> <pre><br /> sudoku # Root level directory.<br /> build.sh # Script used to build all projects on POSIX.<br /> build.bat # Script used to build all projects on Windows.<br /> configure.sh # Script used to configure all projects on POSIX.<br /> configure.bat # Script used to configure all projects on Windows.<br /> setup.sh # Script used to install all dependencies on POSIX.<br /> setup.bat # Script used to install all dependencies on Windows.<br /> \application # Contains source specific for the sudoku web app.<br /> build.sh # Script used to build the web app on POSIX.<br /> build.bat # Script used to build the web app on Windows.<br /> configure.sh # Script used to configure the web app on POSIX.<br /> configure.bat # Script used to configure the web app on Windows.<br /> package.json # The Node JS package description.<br /> tsconfig.json # The TypeScript compiler configuration.<br /> setup.sh # Script used the web app dependencies on POSIX.<br /> setup.bat # Script used the web app dependencies on Windows.<br /> webpack.config.js # The Webpack configuration.<br /> \source # Contains the web application source files.<br /> \index.html # The HTML file that loads the JavaScript application.<br /> \index.tsx # The TypeScript/JSX file containing the application.<br /> \library # Contains the common library code.<br /> build.sh # Script used to build the library on POSIX.<br /> build.bat # Script used to build the library on Windows.<br /> configure.sh # Script used to configure the library on POSIX.<br /> configure.bat # Script used to configure the library on Windows.<br /> package.json # The Node JS package description.<br /> setup.sh # Script used the library on POSIX.<br /> setup.bat # Script used the library on Windows.<br /> tsconfig.json # The TypeScript compiler configuration.<br /> \source # Contains the library source files.<br /> index.ts # Exports all definitions contained in this directory.<br /> \pages # Contains the source code for individual web pages.<br /> index.ts # Exports all definitions for every web page defined<br /> # in this directory.<br /> \landing_page # Contains the source code for the landing page.<br /> index.ts # Exports the landing page.<br /> landing_page.tsx # The TypeScript/JSX source code for the landing page.<br /> \page_2 # Contains the source for for another web page.<br /> ... # Structured in a similar manner as the landing page.<br /> \resources # Contains images, fonts, CSS files and all other web<br /> # assets.<br /> \index.css # Contains the main CSS file, typically this is the<br /> # only CSS file used.<br /> \fonts # A directory of fonts used.<br /> \tests # This directory contains tests for every page of the<br /> # web app.<br /> build.sh # Script used to build all tests on POSIX.<br /> build.bat # Script used to build all tests on Windows.<br /> configure.sh # Script used to configure all tests on POSIX.<br /> configure.bat # Script used to configure all tests on Windows.<br /> setup.sh # Script used to install all test dependencies on POSIX.<br /> setup.bat # Script used to install all test dependencies on<br /> # Windows.<br /> \scratch # Directory containing a test/demo for a single page.<br /> build.sh # Script used to build the test on POSIX.<br /> build.bat # Script used to build the test on Windows.<br /> configure.sh # Script used to configure the test on POSIX.<br /> configure.bat # Script used to configure the test on Windows.<br /> package.json # The Node JS package description.<br /> tsconfig.json # The TypeScript compiler configuration.<br /> setup.sh # Script used the test dependencies on POSIX.<br /> setup.bat # Script used the test dependencies on Windows.<br /> webpack.config.js # The Webpack configuration.<br /> \source # Contains the test source files.<br /> \index.html # The HTML file that loads the JavaScript application.<br /> \index.tsx # The TypeScript/JSX file containing the application.<br /> </pre><br /> <br /> An example of the above directory structure containing a basic skeletal implementation of all files can be found here: https://github.com/spiretrading/sudoku<br /> <br /> =Component Names=<br /> <br /> Naming components can be difficult. Names are usually prefixed with the context or domain. Most components will fall under one of the following categories.<br /> <br /> ==Field==<br /> The primary function of a field is to display data. The data can be edited. It can have a readonly property. It contains a onChange callback.<br /> <br /> Examples: DurationField, NumberField<br /> <br /> ===Selection Field===<br /> A specialized field. It requires a list of potential values to choose from.<br /> <br /> Example: CountrySelectionField<br /> <br /> ==Input==<br /> The primary function of a input is to get user input. Inputs usually do not have a initial value unlike fields. Inputs can have a readonly mode, but it is only to be used when the input should not accept input.<br /> <br /> Example: SecurityInput<br /> <br /> ===Button===<br /> Buttons are a specialized form of input. Only has a onClick callback.<br /> <br /> Examples: Button, BurgerButton<br /> <br /> ==Box==<br /> A component that displays data that cannot be directly edited.<br /> <br /> =Syntax=<br /> <br /> ==Indentation==<br /> Code is indented using 2 spaces per level, tabs are not permitted.<br /> <br /> <syntaxhighlight lang=typescript line=line><br /> function factorial(n: number): number {<br /> if(n == 0) {<br /> return 1;<br /> }<br /> return n * factorial(n - 1);<br /> }<br /> </syntaxhighlight><br /> <br /> ==Line Structure==<br /> <br /> Statements must end with a semi-colon ';' or a closing brace '}', even in cases where TypeScript allows them to be optional.<br /> <br /> Lines are limited to 80 characters. Exceptions to this rule are long imports and long string literals where breaking up the literal into multiple lines is not possible. In order to break up long statements into multiple lines the following rules are used:<br /> <br /> * Break the line at a comma, operator or opening bracket.<br /> <syntaxhighlight lang=typescript line=line><br /> <br /> // Correct, line break at comma.<br /> f(a, ..., b,<br /> c, ..., d);<br /> <br /> // Incorrect, line break after expression.<br /> f(a, ..., b<br /> , c, ..., d);<br /> <br /> // Correct, line break after operator.<br /> a + ... + b +<br /> c + ... + d;<br /> <br /> // Incorrect, line break after expression.<br /> a + ... + b<br /> + c + ... + d;<br /> <br /> // Correct, line break after opening bracket.<br /> f(<br /> a, ..., b, c, ..., d);<br /> <br /> // Incorrect, line break after function name.<br /> f<br /> (a, ..., b, c, ..., d);<br /> </syntaxhighlight><br /> <br /> * For statements that begin new blocks of code (such as if/while/class...), in order to avoid confusing the line continuation with the code block, the line continuation is indented two extra levels. For example consider the following snippet of code:<br /> <br /> <syntaxhighlight lang=typescript line=line><br /> // Incorrect.<br /> if(condition_a && condition_b && ... &&<br /> condition_c) {<br /> console.log('meow');<br /> }<br /> </syntaxhighlight><br /> <br /> The line continuation on line 2 clashes with the code block on line 3. To avoid this clash the above code is indented as follows:<br /> <br /> <syntaxhighlight lang=typescript line=line><br /> // Correct.<br /> if(condition_a && condition_b && ... &&<br /> condition_c) {<br /> console.log('meow');<br /> }<br /> </syntaxhighlight><br /> <br /> The extra level of indentation in the line continuation makes it clear where the condition ends and the code block begins.<br /> <br /> ==Braces==<br /> <br /> Braces are placed using a variant of the [http://wiki.c2.com/?OneTrueBraceStyle OTBS style]. The opening brace is placed on the same line as the declaring statement with one single space preceding it, and the closing brace is placed on a line of its own at the same level of indentation as the declaring statement. For if statements, the else/else if is placed on the same line as the closing brace. For do/while loops, the while is placed on the same line as the closing brace.<br /> <br /> Examples:<br /> <syntaxhighlight lang=typescript line=line><br /> // Correct.<br /> if(<cond>) {<br /> <body><br /> } else {<br /> <default><br /> }<br /> <br /> // Correct.<br /> do {<br /> <body><br /> } while(<cond>);<br /> <br /> // Incorrect.<br /> if(<cond>)<br /> {<br /> <body><br /> }<br /> else<br /> {<br /> <default><br /> }<br /> <br /> // Incorrect.<br /> do<br /> {<br /> <body><br /> }<br /> while(<cond>);<br /> </syntaxhighlight><br /> <br /> ==Spacing==<br /> <br /> The following are correct use cases for white spaces:<br /> <br /> * Used for indentation.<br /> * Used to surround binary operations.<br /> <syntaxhighlight lang=typescript line=line><br /> // Correct.<br /> const x = a + b;<br /> const y = 5;<br /> <br /> //! Incorrect<br /> const x = a+b;<br /> const y=5;<br /> const z= 5;<br /> </syntaxhighlight><br /> <br /> * One space is placed after a comma.<br /> <syntaxhighlight lang=typescript line=line><br /> // Correct.<br /> f(1, 2);<br /> function g(a: number, b: number): number;<br /> <br /> //! Incorrect<br /> f(1,2);<br /> function g(a:number,b:number);<br /> </syntaxhighlight><br /> <br /> ==Naming==<br /> <br /> [https://en.wikipedia.org/wiki/Camel_case Camel case] is used for naming whereas variables and functions use mixedCase and namespaces, modules, and types use CapWords. Names should be descriptive but should avoid being verbose.<br /> <br /> Classes and variables should be given the name of a noun and functions the name of a verb. Functions that return a boolean or boolean variables should be named in the form of a question starting with isX or hasX.<br /> <br /> ==Imports==<br /> Imports are listed in order of most global to local. Where dependencies have the same locality, then they are ordered alphabetically. For example, the first group of dependencies to be imported are third party packages which are listed in alphabetical order based on the package name. In the above snippet the third party dependencies are jquery, react and react-router-dom which are imported in alphabetical order. Then local dependencies are imported where directories further up the hierarchy are imported first. That is, the directory '../../..' which is three levels up is imported before the directory '..' which is only one level up.<br /> <br /> When multiple names are imported from a package, they must be listed in alphabetical order.<br /> <br /> <syntaxhighlight lang=typescript line=line><br /> import * as $ from 'jquery';<br /> import * as React from 'react';<br /> import * as Router from 'react-router-dom';<br /> import {HBoxLayout, Padding, VBoxLayout} from '../../..';<br /> import {Model} from '..';<br /> </syntaxhighlight><br /> <br /> ==Declarations==<br /> <br /> Any declaration (such as a function or class) that is intended to be imported by another file must be documented using [http://usejsdoc.org/ JSDoc style]. If the definition is local then that documentation should be omitted entirely.<br /> <br /> Any documentation should be preceded by a blank line. In the code snippet, Properties is part of the public API so it is documented along with all of its fields, but the State is internal to the file so no aspect of it is documented.<br /> <br /> <syntaxhighlight lang=typescript line=line><br /> <br /> /** Stores the React properties used to render a Page. */<br /> export interface Properties {<br /> <br /> /** The model used to display the page. */<br /> model: Model;<br /> }<br /> <br /> export interface State {<br /> redirect: string;<br /> isLoading: boolean;<br /> }<br /> </syntaxhighlight><br /> <br /> ==Variable Declarations==<br /> <br /> Variables are declared so that only one variable is declared per line, prefer declaring variables using ''const'' when possible, and deferring to ''let'' otherwise, variables should always be initialized at the point of their declaration.<br /> <br /> For complex initialization of values, use an [https://en.wikipedia.org/wiki/Immediately-invoked_function_expression immediately invoked lambda expression] as follows:<br /> <br /> <syntaxhighlight lang=typescript line=line><br /> const value = (() => {<br /> if(condition) {<br /> return 123;<br /> }<br /> return 321;<br /> })();<br /> </syntaxhighlight><br /> <br /> =Example=<br /> <br /> Below is a full example combining numerous elements of the style guide to define a typical React component. It should be used as a general reference for how code is laid out, structured, and properly spaced.<br /> <br /> <syntaxhighlight lang=typescript line=line><br /> import * as $ from 'jquery';<br /> import * as React from 'react';<br /> import * as Router from 'react-router-dom';<br /> import {HBoxLayout, Padding, VBoxLayout} from '..';<br /> import {Model} from '.';<br /> <br /> /** Stores the React properties used to render a Page. */<br /> export interface Properties {<br /> <br /> /** The model used to display the page. */<br /> model: Model;<br /> }<br /> <br /> export interface State {<br /> redirect: string;<br /> isLoading: boolean;<br /> }<br /> <br /> /** Displays an HTML page. */<br /> export class Page extends React.Component<Properties, State> {<br /> constructor(props: Properties) {<br /> super(props);<br /> this.state = {<br /> redirect: '',<br /> isLoading: true<br /> };<br /> }<br /> <br /> public componentWillMount(): void {<br /> this.props.model.load().then(<br /> () => {<br /> this.setState({<br /> isLoading: false<br /> });<br /> });<br /> }<br /> <br /> public render(): JSX.Element {<br /> if(this.state.redirect) {<br /> return <Router.Redirect push to={this.state.redirect}/>;<br /> } else if(this.state.isLoading) {<br /> return <LoadingPage/>;<br /> }<br /> const style = {<br /> backgroundColor: '#FFFFFF',<br /> font: 'Roboto 14px'<br /> };<br /> return (<br /> <div style={style}><br /> <h1>Hello world!</h1><br /> <img src='cat.jpg'/><br /> </div>);<br /> }<br /> }<br /> </syntaxhighlight><br /> <br /> =Additional References=<br /> <br /> The bulk of this style guide focuses on syntax rather than good programming practices. The following list are reference materials for best practices on writing portable, efficient, and clean TypeScript:<br /> <br /> * [https://www.typescriptlang.org/docs/handbook/basic-types.html TypeScript Hand Book]</div>

Kamal https://wiki.spiretrading.com/index.php?title=TypeScript_Style_Guide&diff=101 TypeScript Style Guide 2020-03-20T18:59:59Z

<p>Kamal: </p> <hr /> <div>This article specifies the most general guidelines used for all Spire projects written using TypeScript as the primary programming language. Each individual project may extend or override the guidelines specified herein. The overall aim of this guideline is to provide consistency across the numerous projects developed by Spire in order to promote and benefit from modern web development practices as well as tailor them to our specific requirements.<br /> <br /> In general, the guidelines are very specific and opinionated. This is done intentionally to ensure that every detail has been given proper consideration and that every line of code is written with care and diligence. It is taken as a prerequisite that writing robust, clean and maintainable code requires paying close attention to even the smallest of details. As such, when there are two or more ways to write or express any given statement or expression, be it using spaces or tabs, number of characters per line, purple or violet, the guideline will often require that one particular approach be used to the exclusion of others.<br /> <br /> Finally, this document is constantly evolving and as such older projects may not be up-to-date with the guidelines found here. In those circumstances one must use their best judgment about how to integrate these guidelines into older codebases. As a general principle, consistency should favor the local over the global, that is it is more important to be consistent with a function definition than within a file, and more important to be consistent within a file than within a directory, project, etc...<br /> <br /> =Development Environment=<br /> <br /> The primary operating systems supported by Spire projects are Ubuntu 18.02 LTS, Windows 10, and macOS. On all systems, nodejs is used as the build system and webpack is used as the bundler.<br /> <br /> For source control, git is used and projects are to be hosted on [https://github.com/spiretrading Spire Trading's Github page].<br /> <br /> Each developer is welcome to use an editor of their choice, however [https://code.visualstudio.com/ Visual Studio Code] is recommended.<br /> <br /> =File Names=<br /> <br /> Use [https://en.wikipedia.org/wiki/Snake_case snake case] using all lower case letters for files and directories. The name of a file should correspond to the primary class that it exports.<br /> <br /> The default extension for TypeScript files is ''ts''<br /> <br /> The extension used for TypeScript files containing JSX is ''tsx''<br /> <br /> All files end with a single new line character.<br /> <br /> =Directory Structure=<br /> <br /> A project is broken down into a library component, a test component, and one or more application components. These components are referred to as ''artifacts''. The applications go into their own ''applications'' directory and the libraries into the ''library'' directory. Within each artifact is a ''build'' directory containing the build scripts needed to build that artifact. Scripts for POSIX systems are found in the ''posix'' sub-directory and Windows build files are within the ''windows'' sub-directory. The build scripts specified are ''setup'' to download and install any dependencies needed to produce the artifact and the ''build'' script which produces the artifact. Typically the ''setup'' script is run only once or when a new dependency is introduced to the project, and the ''build'' script is run anytime a new build is needed.<br /> <br /> Finally there is a top-level ''build'' directory for the project as a whole which produces all artifacts by recursively calling each artifact's individual build scripts. Additionally the top-level build directory also includes a ''setup'' script which downloads all third party dependencies. Some projects may also opt to include an ''install'' script which sets up a suitable development environment, and other scripts for continuous builds, deployment and testing.<br /> <br /> Assuming a project named sudoku the following directory structure should be used:<br /> <br /> <pre><br /> sudoku # Root level directory.<br /> build.sh # Script used to build all projects on POSIX.<br /> build.bat # Script used to build all projects on Windows.<br /> \applications # Contains all applications.<br /> \sudoku # Contains the source for the sudoku web application.<br /> package.json # The Node JS package description.<br /> tsconfig.json # The TypeScript compiler configuration.<br /> webpack.config.js # The Webpack configuration.<br /> build.sh # Script used to build application on POSIX.<br /> build.bat # Script used to build application Windows.<br /> \source # Contains the web application source files.<br /> \index.html # The HTML file that loads the JavaScript application.<br /> \index.tsx # The TypeScript/JSX file containing the application.<br /> \library # Contains the common library code.<br /> package.json # The Node JS package description.<br /> tsconfig.json # The TypeScript compiler configuration.<br /> webpack.config.js # The Webpack configuration.<br /> build.sh # Script used to build library on POSIX.<br /> build.bat # Script used to build library on Windows.<br /> \source # Contains the library source files.<br /> index.ts # Exports all definitions contained in this directory.<br /> \pages # Contains the source code for individual web pages.<br /> index.ts # Exports all definitions for every web page defined<br /> # in this directory.<br /> \landing_page # Contains the source code for the landing page.<br /> index.ts # Exports the landing page.<br /> landing_page.tsx # The TypeScript/JSX source code for the landing page.<br /> \page_2 # Contains the source for for another web page.<br /> ... # Structured in a similar manner as the landing page.<br /> </pre><br /> <br /> An example of the above directory structure containing a basic skeletal implementation of all files can be found here: https://github.com/spiretrading/sudoku<br /> <br /> =Component Names=<br /> <br /> Naming components can be difficult. Names are usually prefixed with the context or domain. Most components will fall under one of the following categories.<br /> <br /> ==Field==<br /> The primary function of a field is to display data. The data can be edited. It can have a readonly property. It contains a onChange callback.<br /> <br /> Examples: DurationField, NumberField<br /> <br /> ===Selection Field===<br /> A specialized field. It requires a list of potential values to choose from.<br /> <br /> Example: CountrySelectionField<br /> <br /> ==Input==<br /> The primary function of a input is to get user input. Inputs usually do not have a initial value unlike fields. Inputs can have a readonly mode, but it is only to be used when the input should not accept input.<br /> <br /> Example: SecurityInput<br /> <br /> ===Button===<br /> Buttons are a specialized form of input. Only has a onClick callback.<br /> <br /> Examples: Button, BurgerButton<br /> <br /> ==Box==<br /> A component that displays data that cannot be directly edited.<br /> <br /> =Syntax=<br /> <br /> ==Indentation==<br /> Code is indented using 2 spaces per level, tabs are not permitted.<br /> <br /> <syntaxhighlight lang=typescript line=line><br /> function factorial(n: number): number {<br /> if(n == 0) {<br /> return 1;<br /> }<br /> return n * factorial(n - 1);<br /> }<br /> </syntaxhighlight><br /> <br /> ==Line Structure==<br /> <br /> Statements must end with a semi-colon ';' or a closing brace '}', even in cases where TypeScript allows them to be optional.<br /> <br /> Lines are limited to 80 characters. Exceptions to this rule are long imports and long string literals where breaking up the literal into multiple lines is not possible. In order to break up long statements into multiple lines the following rules are used:<br /> <br /> * Break the line at a comma, operator or opening bracket.<br /> <syntaxhighlight lang=typescript line=line><br /> <br /> // Correct, line break at comma.<br /> f(a, ..., b,<br /> c, ..., d);<br /> <br /> // Incorrect, line break after expression.<br /> f(a, ..., b<br /> , c, ..., d);<br /> <br /> // Correct, line break after operator.<br /> a + ... + b +<br /> c + ... + d;<br /> <br /> // Incorrect, line break after expression.<br /> a + ... + b<br /> + c + ... + d;<br /> <br /> // Correct, line break after opening bracket.<br /> f(<br /> a, ..., b, c, ..., d);<br /> <br /> // Incorrect, line break after function name.<br /> f<br /> (a, ..., b, c, ..., d);<br /> </syntaxhighlight><br /> <br /> * For statements that begin new blocks of code (such as if/while/class...), in order to avoid confusing the line continuation with the code block, the line continuation is indented two extra levels. For example consider the following snippet of code:<br /> <br /> <syntaxhighlight lang=typescript line=line><br /> // Incorrect.<br /> if(condition_a && condition_b && ... &&<br /> condition_c) {<br /> console.log('meow');<br /> }<br /> </syntaxhighlight><br /> <br /> The line continuation on line 2 clashes with the code block on line 3. To avoid this clash the above code is indented as follows:<br /> <br /> <syntaxhighlight lang=typescript line=line><br /> // Correct.<br /> if(condition_a && condition_b && ... &&<br /> condition_c) {<br /> console.log('meow');<br /> }<br /> </syntaxhighlight><br /> <br /> The extra level of indentation in the line continuation makes it clear where the condition ends and the code block begins.<br /> <br /> ==Braces==<br /> <br /> Braces are placed using a variant of the [http://wiki.c2.com/?OneTrueBraceStyle OTBS style]. The opening brace is placed on the same line as the declaring statement with one single space preceding it, and the closing brace is placed on a line of its own at the same level of indentation as the declaring statement. For if statements, the else/else if is placed on the same line as the closing brace. For do/while loops, the while is placed on the same line as the closing brace.<br /> <br /> Examples:<br /> <syntaxhighlight lang=typescript line=line><br /> // Correct.<br /> if(<cond>) {<br /> <body><br /> } else {<br /> <default><br /> }<br /> <br /> // Correct.<br /> do {<br /> <body><br /> } while(<cond>);<br /> <br /> // Incorrect.<br /> if(<cond>)<br /> {<br /> <body><br /> }<br /> else<br /> {<br /> <default><br /> }<br /> <br /> // Incorrect.<br /> do<br /> {<br /> <body><br /> }<br /> while(<cond>);<br /> </syntaxhighlight><br /> <br /> ==Spacing==<br /> <br /> The following are correct use cases for white spaces:<br /> <br /> * Used for indentation.<br /> * Used to surround binary operations.<br /> <syntaxhighlight lang=typescript line=line><br /> // Correct.<br /> const x = a + b;<br /> const y = 5;<br /> <br /> //! Incorrect<br /> const x = a+b;<br /> const y=5;<br /> const z= 5;<br /> </syntaxhighlight><br /> <br /> * One space is placed after a comma.<br /> <syntaxhighlight lang=typescript line=line><br /> // Correct.<br /> f(1, 2);<br /> function g(a: number, b: number): number;<br /> <br /> //! Incorrect<br /> f(1,2);<br /> function g(a:number,b:number);<br /> </syntaxhighlight><br /> <br /> ==Naming==<br /> <br /> [https://en.wikipedia.org/wiki/Camel_case Camel case] is used for naming whereas variables and functions use mixedCase and namespaces, modules, and types use CapWords. Names should be descriptive but should avoid being verbose.<br /> <br /> Classes and variables should be given the name of a noun and functions the name of a verb. Functions that return a boolean or boolean variables should be named in the form of a question starting with isX or hasX.<br /> <br /> ==Imports==<br /> Imports are listed in order of most global to local. Where dependencies have the same locality, then they are ordered alphabetically. For example, the first group of dependencies to be imported are third party packages which are listed in alphabetical order based on the package name. In the above snippet the third party dependencies are jquery, react and react-router-dom which are imported in alphabetical order. Then local dependencies are imported where directories further up the hierarchy are imported first. That is, the directory '../../..' which is three levels up is imported before the directory '..' which is only one level up.<br /> <br /> When multiple names are imported from a package, they must be listed in alphabetical order.<br /> <br /> <syntaxhighlight lang=typescript line=line><br /> import * as $ from 'jquery';<br /> import * as React from 'react';<br /> import * as Router from 'react-router-dom';<br /> import {HBoxLayout, Padding, VBoxLayout} from '../../..';<br /> import {Model} from '..';<br /> </syntaxhighlight><br /> <br /> ==Declarations==<br /> <br /> Any declaration (such as a function or class) that is intended to be imported by another file must be documented using [http://usejsdoc.org/ JSDoc style]. If the definition is local then that documentation should be omitted entirely.<br /> <br /> Any documentation should be preceded by a blank line. In the code snippet, Properties is part of the public API so it is documented along with all of its fields, but the State is internal to the file so no aspect of it is documented.<br /> <br /> <syntaxhighlight lang=typescript line=line><br /> <br /> /** Stores the React properties used to render a Page. */<br /> export interface Properties {<br /> <br /> /** The model used to display the page. */<br /> model: Model;<br /> }<br /> <br /> export interface State {<br /> redirect: string;<br /> isLoading: boolean;<br /> }<br /> </syntaxhighlight><br /> <br /> ==Variable Declarations==<br /> <br /> Variables are declared so that only one variable is declared per line, prefer declaring variables using ''const'' when possible, and deferring to ''let'' otherwise, variables should always be initialized at the point of their declaration.<br /> <br /> For complex initialization of values, use an [https://en.wikipedia.org/wiki/Immediately-invoked_function_expression immediately invoked lambda expression] as follows:<br /> <br /> <syntaxhighlight lang=typescript line=line><br /> const value = (() => {<br /> if(condition) {<br /> return 123;<br /> }<br /> return 321;<br /> })();<br /> </syntaxhighlight><br /> <br /> =Example=<br /> <br /> Below is a full example combining numerous elements of the style guide to define a typical React component. It should be used as a general reference for how code is laid out, structured, and properly spaced.<br /> <br /> <syntaxhighlight lang=typescript line=line><br /> import * as $ from 'jquery';<br /> import * as React from 'react';<br /> import * as Router from 'react-router-dom';<br /> import {HBoxLayout, Padding, VBoxLayout} from '..';<br /> import {Model} from '.';<br /> <br /> /** Stores the React properties used to render a Page. */<br /> export interface Properties {<br /> <br /> /** The model used to display the page. */<br /> model: Model;<br /> }<br /> <br /> export interface State {<br /> redirect: string;<br /> isLoading: boolean;<br /> }<br /> <br /> /** Displays an HTML page. */<br /> export class Page extends React.Component<Properties, State> {<br /> constructor(props: Properties) {<br /> super(props);<br /> this.state = {<br /> redirect: '',<br /> isLoading: true<br /> };<br /> }<br /> <br /> public componentWillMount(): void {<br /> this.props.model.load().then(<br /> () => {<br /> this.setState({<br /> isLoading: false<br /> });<br /> });<br /> }<br /> <br /> public render(): JSX.Element {<br /> if(this.state.redirect) {<br /> return <Router.Redirect push to={this.state.redirect}/>;<br /> } else if(this.state.isLoading) {<br /> return <LoadingPage/>;<br /> }<br /> const style = {<br /> backgroundColor: '#FFFFFF',<br /> font: 'Roboto 14px'<br /> };<br /> return (<br /> <div style={style}><br /> <h1>Hello world!</h1><br /> <img src='cat.jpg'/><br /> </div>);<br /> }<br /> }<br /> </syntaxhighlight><br /> <br /> =Additional References=<br /> <br /> The bulk of this style guide focuses on syntax rather than good programming practices. The following list are reference materials for best practices on writing portable, efficient, and clean TypeScript:<br /> <br /> * [https://www.typescriptlang.org/docs/handbook/basic-types.html TypeScript Hand Book]</div>

Kamal https://wiki.spiretrading.com/index.php?title=Spire_Trading_Inc.:About&diff=100 Spire Trading Inc.:About 2020-03-19T19:41:53Z

<p>Kamal: </p> <hr /> <div>[[File: Spire-logo.png|237x91px|center]]<br /> <br /> <br /> We’re a boutique firm developing high-quality trading software in Canada’s financial hub. We pride ourselves on building extremely stable and lightning-quick trading software that can be highly customized for our customers. At Spire, we understand that small teams can do amazing things, and take pride in achieving the kind of work that results in better output and happier employees. If you want to know more about us, take a look at [https://spiretrading.com our website].</div>

Kamal https://wiki.spiretrading.com/index.php?title=Spire_Trading_Inc.:About&diff=99 Spire Trading Inc.:About 2020-03-19T19:41:04Z

<p>Kamal: </p> <hr /> <div>[[File: Spire-logo.png|upright=1.0|center]]<br /> <br /> <br /> We’re a boutique firm developing high-quality trading software in Canada’s financial hub. We pride ourselves on building extremely stable and lightning-quick trading software that can be highly customized for our customers. At Spire, we understand that small teams can do amazing things, and take pride in achieving the kind of work that results in better output and happier employees. If you want to know more about us, take a look at [https://spiretrading.com our website].</div>

Kamal https://wiki.spiretrading.com/index.php?title=Spire_Trading_Inc.:About&diff=98 Spire Trading Inc.:About 2020-03-19T19:40:09Z

<p>Kamal: </p> <hr /> <div>[[File: Spire-logo.png|50x50%|center]]<br /> <br /> <br /> We’re a boutique firm developing high-quality trading software in Canada’s financial hub. We pride ourselves on building extremely stable and lightning-quick trading software that can be highly customized for our customers. At Spire, we understand that small teams can do amazing things, and take pride in achieving the kind of work that results in better output and happier employees. If you want to know more about us, take a look at [https://spiretrading.com our website].</div>

Kamal https://wiki.spiretrading.com/index.php?title=Spire_Trading_Inc.:About&diff=97 Spire Trading Inc.:About 2020-03-19T19:35:51Z

<p>Kamal: </p> <hr /> <div>[[File: Spire-logo.png|395x151px|center]]<br /> <br /> <br /> We’re a boutique firm developing high-quality trading software in Canada’s financial hub. We pride ourselves on building extremely stable and lightning-quick trading software that can be highly customized for our customers. At Spire, we understand that small teams can do amazing things, and take pride in achieving the kind of work that results in better output and happier employees. If you want to know more about us, take a look at [https://spiretrading.com our website].</div>

Kamal https://wiki.spiretrading.com/index.php?title=Spire_Trading_Inc.:About&diff=96 Spire Trading Inc.:About 2020-03-19T19:34:18Z

<p>Kamal: </p> <hr /> <div>[[File: Spire-logo.png|395x151px|center]]<br /> <br /> We’re a boutique firm developing high-quality trading software in Canada’s financial hub. We pride ourselves on building extremely stable and lightning-quick trading software that can be highly customized for our customers. At Spire, we understand that small teams can do amazing things, and take pride in achieving the kind of work that results in better output and happier employees. If you want to know more about us, take a look at [https://spiretrading.com our website].</div>

Kamal https://wiki.spiretrading.com/index.php?title=Spire_Trading_Inc.:About&diff=95 Spire Trading Inc.:About 2020-03-19T19:33:22Z

<p>Kamal: </p> <hr /> <div>[[File: Spire-logo.png|upright=1.0|center]]<br /> <br /> We’re a boutique firm developing high-quality trading software in Canada’s financial hub. We pride ourselves on building extremely stable and lightning-quick trading software that can be highly customized for our customers. At Spire, we understand that small teams can do amazing things, and take pride in achieving the kind of work that results in better output and happier employees. If you want to know more about us, take a look at [https://spiretrading.com our website].</div>

Kamal https://wiki.spiretrading.com/index.php?title=Spire_Trading_Inc.:About&diff=94 Spire Trading Inc.:About 2020-03-19T19:32:06Z

<p>Kamal: </p> <hr /> <div>[[File: Spire-logo.png|upright=0.5]]<br /> <br /> We’re a boutique firm developing high-quality trading software in Canada’s financial hub. We pride ourselves on building extremely stable and lightning-quick trading software that can be highly customized for our customers. At Spire, we understand that small teams can do amazing things, and take pride in achieving the kind of work that results in better output and happier employees. If you want to know more about us, take a look at [https://spiretrading.com our website].</div>

Kamal https://wiki.spiretrading.com/index.php?title=Spire_Trading_Inc.:About&diff=93 Spire Trading Inc.:About 2020-03-19T19:30:40Z

<p>Kamal: </p> <hr /> <div>[[File: Spire-logo.png]]<br /> <br /> We’re a boutique firm developing high-quality trading software in Canada’s financial hub. We pride ourselves on building extremely stable and lightning-quick trading software that can be highly customized for our customers. At Spire, we understand that small teams can do amazing things, and take pride in achieving the kind of work that results in better output and happier employees. If you want to know more about us, take a look at [https://spiretrading.com our website].</div>

Kamal https://wiki.spiretrading.com/index.php?title=File:Spire-logo.png&diff=92 File:Spire-logo.png 2020-03-19T19:30:22Z

<p>Kamal: </p> <hr /> <div></div>

Kamal https://wiki.spiretrading.com/index.php?title=Spire_Trading_Inc.:About&diff=91 Spire Trading Inc.:About 2020-03-19T15:34:58Z

<p>Kamal: </p> <hr /> <div>[[File: Spire-logo.svg]]<br /> <br /> We’re a boutique firm developing high-quality trading software in Canada’s financial hub. We pride ourselves on building extremely stable and lightning-quick trading software that can be highly customized for our customers. At Spire, we understand that small teams can do amazing things, and take pride in achieving the kind of work that results in better output and happier employees. If you want to know more about us, take a look at [https://spiretrading.com our website].</div>

Kamal https://wiki.spiretrading.com/index.php?title=File:Spire-logo.svg&diff=90 File:Spire-logo.svg 2020-03-19T15:15:29Z

<p>Kamal: </p> <hr /> <div></div>

Kamal https://wiki.spiretrading.com/index.php?title=Spire_Trading_Inc.:About&diff=89 Spire Trading Inc.:About 2020-03-19T15:01:16Z

<p>Kamal: </p> <hr /> <div>[[File:Logo.png]]<br /> <br /> We’re a boutique firm developing high-quality trading software in Canada’s financial hub. We pride ourselves on building extremely stable and lightning-quick trading software that can be highly customized for our customers. At Spire, we understand that small teams can do amazing things, and take pride in achieving the kind of work that results in better output and happier employees. If you want to know more about us, take a look at [https://spiretrading.com our website].</div>

Kamal https://wiki.spiretrading.com/index.php?title=Spire_Trading_Inc.:About&diff=88 Spire Trading Inc.:About 2020-03-19T15:00:40Z

<p>Kamal: </p> <hr /> <div>We’re a boutique firm developing high-quality trading software in Canada’s financial hub. We pride ourselves on building extremely stable and lightning-quick trading software that can be highly customized for our customers. At Spire, we understand that small teams can do amazing things, and take pride in achieving the kind of work that results in better output and happier employees. If you want to know more about us, take a look at [https://spiretrading.com our website].</div>

Kamal https://wiki.spiretrading.com/index.php?title=Spire_Trading_Inc.:About&diff=87 Spire Trading Inc.:About 2020-03-19T15:00:24Z

<p>Kamal: Created page with "We’re a boutique firm developing high-quality trading software in Canada’s financial hub. We pride ourselves on building extremely stable and lightning-quick trading softw..."</p> <hr /> <div>We’re a boutique firm developing high-quality trading software in Canada’s financial hub. We pride ourselves on building extremely stable and lightning-quick trading software that can be highly customized for our customers. At Spire, we understand that small teams can do amazing things, and take pride in achieving the kind of work that results in better output and happier employees. If you want to know more about us, take a look at [https://spiretrading.com|our website].</div>

Kamal https://wiki.spiretrading.com/index.php?title=MediaWiki:Common.css&diff=86 MediaWiki:Common.css 2020-03-19T14:32:14Z

<p>Kamal: </p> <hr /> <div>/* CSS placed here will be applied to all skins */<br /> <br /> <br /> @import url('https://fonts.googleapis.com/css?family=Montserrat&display=swap');<br /> <br /> <br /> /*** SELECTORS ***/<br /> <br /> html, body {<br /> font-family: Roboto, sans-serif;<br /> line-height: 18pt;<br /> }<br /> <br /> <br /> body {<br /> background-color: #FFF;<br /> background-image: url('http://wiki.spiretrading.com/images/b/bd/Footer.pattern.png');<br /> background-repeat: repeat-x;<br /> background-position: bottom center;<br /> background-size: 20%;<br /> }<br /> <br /> a, #mw-panel .portal .body li a {<br /> color: #4B23A0;<br /> }<br /> <br /> h1, h2, h3, h4, h5, h6 {<br /> font-family: 'Montserrat', sans-serif;<br /> }<br /> <br /> #mw-page-base {<br /> background-image: none;<br /> background-color: #FFF;<br /> }<br /> <br /> <br /> /*** IDENTIFIERS ***/<br /> <br /> #pt-login-private a {<br /> color: #EC228F !important;<br /> }<br /> <br /> #p-logo {<br /> height: 70px !important;<br /> }<br /> <br /> <br /> /*** CLASSES ***/<br /> <br /> /* RESETTING GRADIENTS AND HEADINGD */<br /> .vectorTabs, .vectorTabs span, #mw-head .vectorMenu h3, .vectorTabs li {<br /> background-image: none !important;<br /> }<br /> <br /> /* LOGO */<br /> .mw-wiki-logo {<br /> background-position: left 20px top 20px !important;<br /> }<br /> <br /> .mw-body h1, .mw-body-content h1, .mw-body-content h2 {<br /> font-family: 'Montserrat', sans-serif;<br /> }<br /> <br /> <br /> .vectorTabs .selected {<br /> border-bottom: 2px solid #4B23A0;<br /> }<br /> <br /> .mw-body {<br /> border-color: #C8C8C8 !important;<br /> }<br /> <br /> .toc {<br /> background: #F8F9FA;<br /> border-color: #F2F2F2;<br /> margin: 15px 0;<br /> padding: 15px;<br /> }<br /> <br /> <br /> /*** SKIN: TWEEKI CUSTOMIZATIONS ***/<br /> <br /> .navbar-brand img {<br /> margin-top: -5px;<br /> width: 136.5px;<br /> height: 35px;<br /> }<br /> <br /> h1, .h1 {<br /> font-size: 30px;<br /> }<br /> h2, .h2 {<br /> font-size: 27px;<br /> }<br /> h3, .h3 {<br /> font-size: 24px;<br /> }<br /> h4, .h4 {<br /> font-size: 20px;<br /> }<br /> h5, .h5 {<br /> font-size: 18px;<br /> }<br /> h6, .h6 {<br /> font-size: 16px;<br /> }<br /> <br /> h1, .h1, h2, .h2, h3, .h3 {<br /> margin-top: 25px;<br /> margin-bottom: 15px;<br /> }<br /> <br /> .firstHeading, .tweekiFirstHeading {<br /> text-align: left;<br /> margin-bottom: 30px;<br /> }<br /> <br /> .navbar-default {<br /> background-image: none !important;<br /> background-color: #FFF !important;<br /> }<br /> <br /> .btn, #wpSave {<br /> border: 0px !important;<br /> }<br /> <br /> .btn-default, .btn-primary, .btn-success, .btn-info, .btn-warning, .btn-danger, #wpSave {<br /> text-shadow: none !important;<br /> -webkit-box-shadow: none !important;<br /> box-shadow: none !important;<br /> }<br /> <br /> .btn-primary, .mw-ui-button.mw-ui-progressive, #wpSave {<br /> background-image: none;<br /> background-color: #513392;<br /> }<br /> <br /> .btn-primary:hover, .btn-primary:focus, .mw-ui-button.mw-ui-progressive:hover, mw-ui-button.mw-ui-progressive:focus, #wpSave:hover, #wpSave:focus {<br /> background-color: #6556A4;<br /> }<br /> <br /> .btn-primary:active, .mw-ui-button.mw-ui-progressive:active, #wpSave:active {<br /> background-color: #453A70;<br /> }<br /> <br /> a:hover, a:focus {<br /> color: #6556A4;<br /> }<br /> <br /> .navbar-right {<br /> margin-top: 7px;<br /> }<br /> <br /> #searchInput {<br /> margin-top: 5px;<br /> }<br /> <br /> #searchInput:focus {<br /> border: 1px solid #4B23A0;<br /> background-image: none;<br /> outline: 0;<br /> -webkit-box-shadow: none;<br /> box-shadow: none;<br /> }<br /> <br /> #footer {<br /> background-color: #F8F8F8;<br /> padding: 15px;<br /> }<br /> <br /> #footer-icons li:last-child::before {<br /> content: " • ";<br /> }<br /> <br /> td.mw-label {<br /> padding-right: 10px;<br /> }<br /> <br /> @media only screen and (min-width: 1000px){<br /> #contentwrapper {<br /> margin-bottom: 190px !important;<br /> }<br /> }<br /> <br /> .oo-ui-panelLayout-framed {<br /> border: 0 none #FFF;<br /> }</div>

Kamal https://wiki.spiretrading.com/index.php?title=MediaWiki:Tweeki-footer-custom&diff=85 MediaWiki:Tweeki-footer-custom 2020-03-12T21:20:48Z

<p>Kamal: </p> <hr /> <div>LOGIN, Special:ALLPAGES |All Articles</div>

Kamal https://wiki.spiretrading.com/index.php?title=MediaWiki:Tweeki-footer-custom&diff=84 MediaWiki:Tweeki-footer-custom 2020-03-12T21:20:14Z

<p>Kamal: </p> <hr /> <div>LOGIN, [[Special:ALLPAGES |All Articles]]</div>

Kamal https://wiki.spiretrading.com/index.php?title=MediaWiki:Tweeki-footer-custom&diff=83 MediaWiki:Tweeki-footer-custom 2020-03-12T21:20:02Z

<p>Kamal: </p> <hr /> <div>LOGIN, [[Special:ALL PAGES |All Articles]]</div>

Kamal https://wiki.spiretrading.com/index.php?title=MediaWiki:Tweeki-footer-custom&diff=82 MediaWiki:Tweeki-footer-custom 2020-03-12T21:18:04Z

<p>Kamal: </p> <hr /> <div>LOGIN, [[Special:ALLPAGES |All Articles]]</div>

Kamal https://wiki.spiretrading.com/index.php?title=MediaWiki:Tweeki-footer-custom&diff=81 MediaWiki:Tweeki-footer-custom 2020-03-12T21:17:21Z

<p>Kamal: </p> <hr /> <div>LOGIN, [[Special:ALLPAGES "All Articles"]]</div>

Kamal https://wiki.spiretrading.com/index.php?title=MediaWiki:Tweeki-footer-custom&diff=80 MediaWiki:Tweeki-footer-custom 2020-03-12T21:17:01Z

<p>Kamal: </p> <hr /> <div>LOGIN, [[Special:ALLPAGES]]</div>

Kamal https://wiki.spiretrading.com/index.php?title=MediaWiki:Tweeki-footer-custom&diff=79 MediaWiki:Tweeki-footer-custom 2020-03-12T21:16:44Z

<p>Kamal: </p> <hr /> <div>LOGIN, [[ALLPAGES]]</div>

Kamal https://wiki.spiretrading.com/index.php?title=MediaWiki:Tweeki-footer-custom&diff=78 MediaWiki:Tweeki-footer-custom 2020-03-12T21:16:26Z

<p>Kamal: </p> <hr /> <div>LOGIN, [[ALL PAGES]]</div>

Kamal https://wiki.spiretrading.com/index.php?title=MediaWiki:Tweeki-footer-custom&diff=77 MediaWiki:Tweeki-footer-custom 2020-03-12T21:13:46Z

<p>Kamal: </p> <hr /> <div>LOGIN, ALL PAGES</div>

Kamal https://wiki.spiretrading.com/index.php?title=MediaWiki:Tweeki-footer-custom&diff=76 MediaWiki:Tweeki-footer-custom 2020-03-12T21:13:31Z

<p>Kamal: </p> <hr /> <div>LOGIN|ALL PAGES</div>

Kamal https://wiki.spiretrading.com/index.php?title=MediaWiki:Tweeki-footer-custom&diff=75 MediaWiki:Tweeki-footer-custom 2020-03-12T21:11:04Z

<p>Kamal: </p> <hr /> <div>LOGIN, ALL PAGES</div>

Kamal https://wiki.spiretrading.com/index.php?title=MediaWiki:Tweeki-footer-custom&diff=74 MediaWiki:Tweeki-footer-custom 2020-03-12T21:06:06Z

<p>Kamal: </p> <hr /> <div>LOGIN - All Pages</div>

Kamal https://wiki.spiretrading.com/index.php?title=MediaWiki:Tweeki-footer-custom&diff=73 MediaWiki:Tweeki-footer-custom 2020-03-12T21:05:05Z

<p>Kamal: </p> <hr /> <div>LOGIN - [http://wiki.spiretrading.com/index.php?title=Special:AllPages ALL PAGES]</div>

Kamal https://wiki.spiretrading.com/index.php?title=MediaWiki:Tweeki-footer-custom&diff=72 MediaWiki:Tweeki-footer-custom 2020-03-12T19:57:04Z

<p>Kamal: Created page with "LOGIN-[http://wiki.spiretrading.com/index.php?title=Special:AllPages ALL PAGES]"</p> <hr /> <div>LOGIN-[http://wiki.spiretrading.com/index.php?title=Special:AllPages ALL PAGES]</div>

Kamal https://wiki.spiretrading.com/index.php?title=MediaWiki:Common.css&diff=71 MediaWiki:Common.css 2020-03-10T20:07:21Z

<p>Kamal: </p> <hr /> <div>/* CSS placed here will be applied to all skins */<br /> <br /> <br /> @import url('https://fonts.googleapis.com/css?family=Montserrat&display=swap');<br /> <br /> <br /> /*** SELECTORS ***/<br /> <br /> html, body {<br /> font-family: Roboto, sans-serif;<br /> line-height: 18pt;<br /> }<br /> <br /> <br /> body {<br /> background-color: #FFF;<br /> background-image: url('http://wiki.spiretrading.com/images/b/bd/Footer.pattern.png');<br /> background-repeat: repeat-x;<br /> background-position: bottom center;<br /> background-size: 20%;<br /> }<br /> <br /> a, #mw-panel .portal .body li a {<br /> color: #4B23A0;<br /> }<br /> <br /> h1, h2, h3, h4, h5, h6 {<br /> font-family: 'Montserrat', sans-serif;<br /> }<br /> <br /> #mw-page-base {<br /> background-image: none;<br /> background-color: #FFF;<br /> }<br /> <br /> <br /> /*** IDENTIFIERS ***/<br /> <br /> #pt-login-private a {<br /> color: #EC228F !important;<br /> }<br /> <br /> #p-logo {<br /> height: 70px !important;<br /> }<br /> <br /> <br /> /*** CLASSES ***/<br /> <br /> /* RESETTING GRADIENTS AND HEADINGD */<br /> .vectorTabs, .vectorTabs span, #mw-head .vectorMenu h3, .vectorTabs li {<br /> background-image: none !important;<br /> }<br /> <br /> /* LOGO */<br /> .mw-wiki-logo {<br /> background-position: left 20px top 20px !important;<br /> }<br /> <br /> .mw-body h1, .mw-body-content h1, .mw-body-content h2 {<br /> font-family: 'Montserrat', sans-serif;<br /> }<br /> <br /> <br /> .vectorTabs .selected {<br /> border-bottom: 2px solid #4B23A0;<br /> }<br /> <br /> .mw-body {<br /> border-color: #C8C8C8 !important;<br /> }<br /> <br /> .toc {<br /> background: #F8F9FA;<br /> border-color: #F2F2F2;<br /> margin: 15px 0;<br /> padding: 15px;<br /> }<br /> <br /> <br /> /*** SKIN: TWEEKI CUSTOMIZATIONS ***/<br /> <br /> .navbar-brand img {<br /> margin-top: -5px;<br /> width: 136.5px;<br /> height: 35px;<br /> }<br /> <br /> h1, .h1 {<br /> font-size: 30px;<br /> }<br /> h2, .h2 {<br /> font-size: 27px;<br /> }<br /> h3, .h3 {<br /> font-size: 24px;<br /> }<br /> h4, .h4 {<br /> font-size: 20px;<br /> }<br /> h5, .h5 {<br /> font-size: 18px;<br /> }<br /> h6, .h6 {<br /> font-size: 16px;<br /> }<br /> <br /> h1, .h1, h2, .h2, h3, .h3 {<br /> margin-top: 25px;<br /> margin-bottom: 15px;<br /> }<br /> <br /> .firstHeading, .tweekiFirstHeading {<br /> text-align: left;<br /> margin-bottom: 30px;<br /> }<br /> <br /> .navbar-default {<br /> background-image: none !important;<br /> background-color: #FFF !important;<br /> }<br /> <br /> .btn, #wpSave {<br /> border: 0px !important;<br /> }<br /> <br /> .btn-default, .btn-primary, .btn-success, .btn-info, .btn-warning, .btn-danger, #wpSave {<br /> text-shadow: none !important;<br /> -webkit-box-shadow: none !important;<br /> box-shadow: none !important;<br /> }<br /> <br /> .btn-primary, .mw-ui-button.mw-ui-progressive, #wpSave {<br /> background-image: none;<br /> background-color: #513392;<br /> }<br /> <br /> .btn-primary:hover, .btn-primary:focus, .mw-ui-button.mw-ui-progressive:hover, mw-ui-button.mw-ui-progressive:focus, #wpSave:hover, #wpSave:focus {<br /> background-color: #6556A4;<br /> }<br /> <br /> .btn-primary:active, .mw-ui-button.mw-ui-progressive:active, #wpSave:active {<br /> background-color: #453A70;<br /> }<br /> <br /> a:hover, a:focus {<br /> color: #6556A4;<br /> }<br /> <br /> .navbar-right {<br /> margin-top: 7px;<br /> }<br /> <br /> #searchInput {<br /> margin-top: 5px;<br /> }<br /> <br /> #searchInput:focus {<br /> border: 1px solid #4B23A0;<br /> background-image: none;<br /> outline: 0;<br /> -webkit-box-shadow: none;<br /> box-shadow: none;<br /> }<br /> <br /> #footer {<br /> background-color: #F8F8F8;<br /> }<br /> <br /> #footer-icons li:last-child::before {<br /> content: " • ";<br /> }<br /> <br /> td.mw-label {<br /> padding-right: 10px;<br /> }<br /> <br /> @media only screen and (min-width: 1000px){<br /> #contentwrapper {<br /> margin-bottom: 190px !important;<br /> }<br /> }<br /> <br /> .oo-ui-panelLayout-framed {<br /> border: 0 none #FFF;<br /> }</div>

Kamal https://wiki.spiretrading.com/index.php?title=MediaWiki:Tweeki-navbar-brand&diff=70 MediaWiki:Tweeki-navbar-brand 2020-03-10T19:56:42Z

<p>Kamal: Created page with "File:Logo.wiki.png"</p> <hr /> <div>File:Logo.wiki.png</div>

Kamal