1. 💥 Genesis
2. ⚡️ Quick Start
3. 🌴 Features
   1. 📝 List of features
   2. 🤝 Missing a specific feature ?
   3. 🔎 Found a bug ?
4. 🙌 How can I contribute ?
5. 💻 Insights
   1. 🍯 Developement
   2. 🍏 Build
   3. 🍊 Tests
   4. 🍈 Continuous Integration
   5. 🍇 Continuous Delivery
6. 📜 Licence

🎮 𝐪𝐀𝐏𝐏 (Quantitative Analytics Application) is a simple ecosystem of devices that helps the users to 𝑏𝑢𝑖𝑙𝑑, 𝑝𝑟𝑖𝑐𝑒 and 𝑎𝑛𝑎𝑙𝑦𝑠𝑒 customized financial derivatives contracts.

✍🏻 This flowcharts shows the architecture of the project together with which components the user can consume.

⏩ 𝑞𝐶𝑂𝑅𝐸 (private) is the aggregation of embedded private libraries in charge of implementing 𝘤𝘰𝘯𝘵𝘳𝘢𝘤𝘵, 𝘥𝘢𝘵𝘢, 𝘮𝘰𝘥𝘦𝘭 and 𝘱𝘳𝘪𝘤𝘦𝘳 architectures. Its codebase is hosted on a private GitHub repository which access is restricted to our developpers only.

⏩ 𝑞𝐴𝑃𝐼 (public) is the shared object that the user can plug into his or her personal project. A library of functions that request the core to perform generic actions such as getting contract information, getting price and greeks ...

⏩ qDSL (public) is the internal contract description that uses the power of domain-specific language. A language easily understandable by human and machine to design your contract from a self-explanatory script. The whole ecosystem is built around this.

⏩ 𝑞𝐺𝑈𝐼 (public) is the up and running GUI desktop application from which the user requests the API and visualize the results through a modern graphical interface.

To download the latest version of our application, go to Releases and download the asset that corresponds to your operating system. After extracting all the files into a nice location of your machine, you are falling onto a folder that contains qAPP directory. Open the qGUI executable located at qAPP/bin and you arrive to the main page with an example.

1. 📺 How to plug qAPI with my project ?
2. 📺 How to use the ladders ?
3. 📺 How to use the Heston parameters smile impact viewer ?

The project is very far from being complete (and will probably never be ...) and a loads of features are still missing. This is why our developpers are working continuously to enrich the list of available functionalities. Feel free to share your ideas under the tag features ! We are happy to discuss with you about your personnal needs and the feasibility of your project.

Feel free to report your issue (see How can I report my issue) with a respective title and an understandable description.

We are building a payoff base to:

• Challenge our tool and push it to its limits.
• Enhance our unit and integration tests.

We propose to every structured products and programmer enthusiasts to contribute its favorite payoff within a shared folder. Here is the process to follow:

• Design your contract (see How can I design my contract)

• Fork and clone this repository.

git clone https://github.com/matt-charr/qAPP.git

• Drop your contract python file(s) into qAPP/factory folder.

mv my_contract.py qAPP/factory/my_contract.py

• Commit, push and pull request.

cd qAPP 
git commit -am "Added my contract"
git push origin master

Once a bug or a feature is submitted, an issue is created with the corresponding flag (bug, feature, project, activity, misc). Once picked from the stack, a dev branch is created, comes down locally to the developper machine and this is where the fun begins 😃

qAPP uses CMake as a build system and has its main code base located on a private repository which access is restricted to our developers only. Besides, it relies on a bunch of repository dependencies that are required at qAPP build time.
It is to the following projects that we owe our heartfelt thanks for their generous open source contribution.

• ImGui
• ImPlot
• ImFileBrowser
• MariaDB
• Curl
• OpenSSL
• Glfw
• JsonCpp
• Eigen

To load the below dependencies, qAPP uses the power of superbuild feature from CMake. For that purpose, an embedded CMake project is in charge of cloning, building and installing all the dependencies that qAPP requires into a specific folder. That's pretty cool, isn't it ? 😃

In order to ensure that the code change effect is not broken by any subsequent modifications, at the end of each dev session, a new unit test is required to be submitted to the test suite together with a contract file that replicates the expected behavior of the code change.

qAPP embbeds a custom GitHub action that runs at each pull requests. Once a pull request is submitted, build and tests are triggered on our Windows, Linux and MacOS self-hosted runners in Debug/Release mode with the below configurations. A dev branch is merged if and only if all builds and tests passed on all tested configurations.

Our team delivers a release on a weekly basis:

• ~One major release per year (coming out with the current project)
• ~One minor release per month (coming out with the current feature)
• ~One patch release per week (coming out with the current bug)

To publish a new release, each tag created on our developement repository triggers a github actions that for each OS supported will create and upload the package to qAPP.

Copyright © 2024 qAPP - Quantitative Analytics. All rights reserved.
This file is part of the project qAPP - Quantitative Analytics Application. 
Hence the latter remains the exclusive property of its author. 
Accordingly, no part of this document may be used or transmitted 
in any form for professional, educational or commercial purposes 
without the express permission of Matthieu Charrier.

🙌 Feedbacks more than welcome.
⭐ Star the project on GitHub helps it to progress.
🔔 Reach us at https://github.com/matt-charr/qAPP/issues if:
⚫ You need 𝘀𝗼𝗺𝗲 𝗵𝗲𝗹𝗽 𝘁𝗼 𝘀𝘁𝗮𝗿𝘁.
⚫ You want to 𝗽𝗿𝗼𝗽𝗼𝘀𝗲 𝗮 𝗻𝗲𝘄 𝗳𝗲𝗮𝘁𝘂𝗿𝗲.
⚫ You want to 𝘀𝘂𝗯𝗺𝗶𝘁 𝗮 𝗰𝗼𝗻𝘁𝗿𝗮𝗰𝘁.
⚫ You want to 𝗿𝗲𝗽𝗼𝗿𝘁 𝗮𝗻 𝗶𝘀𝘀𝘂𝗲.