Quartz Energy - XRD API Implementation Challenge Part 1 - Normalization

Challenge Objectives

• Python Rest API development using Flask framework

• Implement CRUD endpoints for minerals catalogue and data import

• Implement calculation endpoints

Project Background

• Our client has developed a specific method of analyzing geological data from soil samples which involves converting Weight percent mineralogy data to volume percent and integrating the calculation with porosity and organic carbon data.

• All the calculations are currently in an Excel workbook - our goal is to create an api to store and process the data, i.e. move the calculations from Excel into the codebase.

• In a previous challenge we have designed an API specification and database models.

• In this challenge we’ll implement all the crud and calculation endpoints

• Follow-up challenges will focus on implementing calculation optimization (Python) and testing (manual and automated)

 

Technology Stack

• Python 3

• Flask

• Flask-Restplus

• MongoDB

• ORM of your choice

 

Code access

 

Project repository is available at https://gitlab.com/quartz-energy/xrd-services/xrd-services  - see challenge forums to get access. Repository contains only the API specification, database models and calculation details document. It is up to you to create a proper project structure.

 

In the challenge forums you’ll find these documents:
 

• Sample Excel file with input and output data

• Data overview presentation

• Calculations specification document

 

We recommend reading these files before moving on to the next section of the challenge spec.

 

Individual requirements

 

1. Minerals catalogue CRUD endpoints
   This is a set of simple CRUD endpoints for managing known minerals and their properties

2. Data Store CRUD endpoints
   This is a set of CRUD endpoints for managing input data sets. Note that DataStore table should contain some info from the input file (number of rows, file name, location, etc). Actual uploaded files should be stored to a configurable directory. Validations for minerals list are required.

3. Calculation endpoints

These 6 endpoints correspond to the 6 output tabs in the sample output file. See the calculations spec document for details on each step. You can use the sample input data file in the forums for testing.

General requirements

 

• Unit tests are required for all endpoints.

• All endpoints should be annotated with Swagger annotations and swagger UI should be served by the API.

• All configuration parameters should be extracted to a common settings module. Sensitive configuration parameters should be set from environment variables (DB url, credentials, etc).

• Please make sure your code is well-documented. Use the following style guides Google Python Style Guide, Python Style Guide, and Docstring Conventions. Code linter is required. Please make sure it is well-engineered but not over-engineered (YAGNI and KISS) solution. We're looking for well-structured and tested code. Well-structured code follows good design principles like the SOLID principles and well-tested code has comprehensive unit tests.

• The code should be implemented using Python3 only.

 

What To Submit

 

• All source code

• Deployment guide

• Postman collection containing sample calls for all endpoints (success/failure)

• Verification guide - how to set up the environment, start the api, and verification screenshots

• Unit tests coverage report

 

Scoring Methodology

 

Contest Specification Requirements(60% weightage)

 

• Have all major specification requirements been met?

Score: 0-9

Major requirements are:

• all endpoints are implemented correctly and return the correct data and codes, etc,

• all db models are defined and contain correct attributes and data types

• Unit tests - minimum coverage 80%

        Have all major specification requirements been met?

Score: 0-3

Minor requirements are:

 

• Postman collection

• Swagger annotations

 

Best Practices & Comments(30% weightage)

 

• Does the submission follow standard best practices?

Score: 0-3

This section includes the PEP-8 code style, linter, patterns usage, code comments

Please make sure your code is well-documented. Use the following style guides Google Python Style Guide, Python Style Guide, and Docstring Conventions. Code linter is required. Please make sure it is well-engineered but not over-engineered (YAGNI and KISS) solution. We're looking for well-structured and tested code. Well-structured code follows good design principles like the SOLID principles and well-tested code has comprehensive unit tests.

Deployment and verification guide (10% weightage)

 

• Does the deployment guide contain everything needed to successfully configure and deploy the api?

Score: 0-3

Final Submission Guidelines

See above