Topcoder Submission - Marathon Match C# Score System

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. We now want to build the C# version.

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 accept also C# code.

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. Please use the library https://github.com/tjanczuk/edge to allow running the C# code. We are targetting Linux and Mac OS X so we should use Mono for .NET libraries.

4. 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

{
   "id": "<uuid - the verification id>",
   "challengeId": "<challenge id>",
   "className": <the class name used C# code>",
   "methods": [
         {
               "name": "aMethod", // the method should be made static and 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": [ // optional
       [ 0 ],
       [ 1 ],
       [ 2 ]
   ],
   "outputs": [ // optional
       0,
       0,
       0
   ],
   "url": {
      "java": "<an url with the Java verification code>",
      "csharp": "<an url with the C# verification code>"
   }
}

5. The Job will need to hold the score information for each input along with the statistics. If a global error occurs (method has wrong signature), status should be marked as Error and results will be null. 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. See 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
     }
  ]
}

6. After fetching the member code, we should check the extension. If it's .cs we continue the process. Otherwise, log and ignore. 

7. All the code after the MM challenge check must be placed on a different folder called "csharp/", including any configuration needed. 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.

8. The idea is to create a Wrapper class that will be responsible to call the methods from the class provided in member code and will also do statistics calculations (max memory and execution time). The wrapper class will need to catch any exception and provide the appropriate error to javascript code.

9. The wrapper class must have two public methods that will return running time and max memory usage. The wrapper will also run the code provided by member. The library https://github.com/tjanczuk/edge should be able to run the code without compiling, but if compilation would make the job easier it is also allowed. Please follow java compilation process for example. If compilation is used, Mono framework compilers must be applied.

10. There is no hard requirements on how to calculate the statistics. Runtime must be calculated in milliseconds.

11. All existing tests (unit and e2e) must still 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