Challenge Overview
Welcome to Topcoder Submission - Marathon Match C++ Score System.
Contest Details
We are creating a new processor to handle Marathon Matches challenges based on NodeJs 8.x.
We have already created the scoring system for Java - http://www.topcoder.com/challenge-details/30072473/?type=develop&noncache=true. Now we need to the same for the C++ submission.
We have built a Node.Js C++ Module that will run the submitted code and produce output and statistics - https://www.topcoder.com/challenges/30072699/?type=develop&noncache=true
Project Background
Technology Stack
Individual Requirements
We are extending the existing Marathon Match Java Score System to check submissions provided in C++ language. Please check here the specifications of the previous challenge for more details.
1. The workflow for the Marathon Match Java Score System is shown below for reference only:
2. The workflow for the Marathon Match C++ Score System is shown below:
3. The DynamoDB will be used to store the Job and Verification Information. The verification information will be used to validate the source code and produce score. The C++ source code must conform with the class name and methods provided in the Verification Record. The data models are:
table name = Verification
4. The Job will need to hold the score information for each input along with the statistics. If an error occurs during method execution for a specific input, the error should be placed inside the object. In this case the score for that input will be 0.0 and all other values will be -1. The current implementation already provide most of the information needed. The data structure to be saved into db is shown below:
table name= Job
5. After fetching the member code, we should check the extension. If it's .cpp we continue the process. Otherwise, log and ignore.
6. All the code after the MM challenge check must be placed on a different folder called "cpp/". Common AWS code can be extracted to default configuration and common folder. The service inside this folder will expose only one method to the current MM codebase, which is calculateScore(submissionId, memberId, challengeId, submissionURL, jobId). The method will return a Promise that in case of success will resolve to the object below (will be extended in the future) and in case of failure will reject with the appropriated error message.
You will need to update the deployment guide (README.md) and validation document (Validation.md).
The Validation.md must show all the steps necessary to verify the application with the new changes:
Contest Details
We are creating a new processor to handle Marathon Matches challenges based on NodeJs 8.x.
We have already created the scoring system for Java - http://www.topcoder.com/challenge-details/30072473/?type=develop&noncache=true. Now we need to the same for the C++ submission.
We have built a Node.Js C++ Module that will run the submitted code and produce output and statistics - https://www.topcoder.com/challenges/30072699/?type=develop&noncache=true
Project Background
- Topcoder is updating its api and one of the apis being updated is the Submission api.
- One of the scenarios that we are taking care of here is that when a user uploads a submission to Topcoder for a Marathon Match challenge.
- An app (not relevant for this contest) creates a message that contains details about this submission and sends it to an Apache Kafka instance.
- This will be a challenge among a series of challenge that will build the Marathon Match processor.
Technology Stack
- Nodejs
- Kafka
- C++
Individual Requirements
We are extending the existing Marathon Match Java Score System to check submissions provided in C++ language. Please check here the specifications of the previous challenge for more details.
1. The workflow for the Marathon Match Java Score System is shown below for reference only:
2. The workflow for the Marathon Match C++ Score System is shown below:
3. The DynamoDB will be used to store the Job and Verification Information. The verification information will be used to validate the source code and produce score. The C++ source code must conform with the class name and methods provided in the Verification Record. The data models are:
table name = Verification
{
"challengeId": "<challenge id>", // primary key
"className": <the class name used C++ code>",
"methods": [
{
"name": "aMethod", // the method should be made public
"input": [ "int" ] // inputs of different types (like String, int, double, String[], int[], double[])
"output": "int" // output of different types (like String, int, double, String[], int[], double[])
}
],
"inputs": [ // data input - required
[ 0 ],
[ 1 ],
[ 2 ]
],
"outputs": [ // expected ouput - optional
0,
0,
0
],
"url": {
"cpp": "<an url with the C++ verification code>",
"java": "<an url with the Java verification code>",
"csharp": "<an url with the C# verification code>"
}
}
4. The Job will need to hold the score information for each input along with the statistics. If an error occurs during method execution for a specific input, the error should be placed inside the object. In this case the score for that input will be 0.0 and all other values will be -1. The current implementation already provide most of the information needed. The data structure to be saved into db is shown below:
table name= Job
{ "id": "<uuid - the job id>", "submissionId": "<submission id from kafka bus>", "challengeId": "<challenge id from kafka bus>", "memberId": "<member id from kafka bus>", "status": "<Start | Compile | Verification | Finished | Error", "error": "<global error>", "results": [ { "error": "<an error>", "score": 10.0, // score for input[0] "memory": 1024, // KBytes "executionTime": 1000 // milliseconds }, { "error": "<an error>", "score": 13.0, // score for input[1] "memory": 1024, // KBytes "executionTime": 1000 // milliseconds }, { "error": "<an error>", "score": 13.0, // score for input[2] "memory": 1024, // KBytes "executionTime": 1000 // milliseconds } ] }
5. After fetching the member code, we should check the extension. If it's .cpp we continue the process. Otherwise, log and ignore.
6. All the code after the MM challenge check must be placed on a different folder called "cpp/". Common AWS code can be extracted to default configuration and common folder. The service inside this folder will expose only one method to the current MM codebase, which is calculateScore(submissionId, memberId, challengeId, submissionURL, jobId). The method will return a Promise that in case of success will resolve to the object below (will be extended in the future) and in case of failure will reject with the appropriated error message.
7. The provide Node.Js C++ module should be used to calculate the output using the member submitted C++ code.
8. Add e2e testing using the solution provided in existing code - please follow the instructions in documentation to setup DynamoDB and S3. Use your AWS credentials to run the tests.
a) use the following message in Kafka. Change url to match your S3 bucket:
{ "topic": "submission.notification.create", "originator": "submission-api", "timestamp": "2018-10-03T16:36:57.524Z", "mime-type": "some mime-type", "payload": { "resource": "submission", "id": "some-id", "challengeId": "16344", "memberId": "123457", "url": "https://s3.amazonaws.com/tc-development-bucket/Random.java", "fileType": "cpp", "isFileSubmission": true } } ���
b) check the DB status of the job id is equal to Finished for success.
9. All tests (unit and e2e) must work without any errors.
Deployment guide and validation document
You will need to update the deployment guide (README.md) and validation document (Validation.md).
The README.md must show how to:
- Configure and Build application
The Validation.md must show all the steps necessary to verify the application with the new changes:
- Verify the code for different test cases
Final Submission Guidelines
- Updated code
- Required Documentation