rsalesc / jude Goto Github PK

Add a new role called "Score". This will be a non-contestant user which will be able to see the scoreboard in fullscreen mode. It will not be able to see submissions and or any other thing, just the scoreboard section. It's a bit painful to support because:

• Need to support a new kind of authentication (with "score" role now).
• Need to dynamically load the possible roles in the admin panel.
• Need to modify the SPA to support this.

Jade has changed its name to pug. The jade package is not maintained anymore.

Implement strategies to address the following issues:

• A user submitting the EXACTLY same code twice. Most of the times it was not really it's intention, or it's a robot doing robot things. We can address this by storing the hashes of submissions for a specific problem by a specific user (a 2D index + a traversal because 3D indices are heavyweight) and checking for duplicates. A error message can suggest to the user an alternative if he/she really wants to resubmit this code: modifying it (notice that even a robot can bypass this, not much to do).

• A user (or robot) trying to flood the judging services with a bunch of slow submissions. This causes the judge queue to work REALLY slow and should be addressed AS SOON AS POSSIBLE before open-sourcing the project. Meanwhile, we can just disqualify the users who do that :). Possible solutions are:

  • User cannot submit more than 4 times in a minute.
  • User will get a 1-minute cooldown if he/she attempts to submit 5 times in a minute.
  • User will have to wait 15 seconds between submissions.
  • Turn all this rules off and add a new rule (user cannot submit more than 6 times in a minute) if it's the last minute of the contest.

Migrate project to Node 8 and finally get rid of all those asyncawait imports.

Add a webservice which will be responsible for polling the database looking for files to print.

This can be implemented with mongo-queue2, and first, if there are multiple services, they can fight for the printing. In future versions maybe this can be more deterministic.

Possibly enforce Storage usage in Loader, so we can heavily abstract contest FS and possibly ensure that the Storage/Cacher is loaded before any other action (before Task loading, inclusive)

Cards and other containers are too large. Though the texts can be made smaller efficiently, cards are still to big for a judge, page is getting too crowded with containers and is missing too much information. That's because I coded all the thing using 90% zoom in Chrome, which made think it was all fine 👯‍♂️

Migrate to Bulma seems to be the way to go. Material UI seems to be a good option too, but it's components are large as well. Bulma seems to be more compact, but it's still not stable and it has not a reasonable amount of features. Anyway, for things Bulma does not provide, other individual components may be used.

Bundle Codemirror, jQuery, Materialize and all that stuff into a single vendor file. Additionally, stop using CDNs. Those are the reasons:

• They should be bundled in a vendor file because they are not actually imported from the application code. They are just available globally. So let's keep it this way and let's include it first in our HTML.

• There are a bunch of CSS stuff which will have to be included together, so it's better to use Webpack.

• Files must be provided in a Internet-constrained environment, so downloading files provided by CDNs is not an option.

Create functions to allow/disallow writing to certain/all/none of the files.

This is not too important, but it will become really important in the moment we start to put other files in the execution box, which will not happen very soon.

It's not a problem if we judge one task at a time, but if we somehow decide to judge concurrently, then we will have a huge problem.

This one is really important but painful. A lot of breaking changes and I still have to check if the validation and embedding recursive problems were fixed since I forked it.

Add a kind of slider to allow the user to jump to specific moments of the contest and see the scoreboard as it was at that time. The slider should fully work during upsolving, be disabled before the contest and incrementally increase in size during the contest. Additionally, if frozen and blind are implemented, it should respect that.

This causes the user to get stuck in the root page when he just logged out.

The current (and hopefully temporary) fix is to entirely disable this feature (user has to hit refresh to get new data).

Add filters to GET requests like: sort (?), limit, select, etc.

Cache compiled checkers to avoid compiling them many times.This is a big deal since testlib.h and jngen.h (mainly) are usually slower than user's solution to compile.

Double-click event does not fire on mobile. Because of that, nothing that exclusively uses this as an event trigger will be fired. An example is the list of submissions of a user after double-clicking the standings cell for a problem.

Show language, execution time for each dataset, time in contest, real time, verdicts for each dataset, code and compilation text for a submission in the "show code" modal.

Replace the current contest-list "Admin Panel" entry with a more discrete logout button in the upper-right corner of the card panel.

Kinda tricky requirements.

Need a security policy and a javaagent to handle the OutOfMemory exception. DMOJ code is useful as a reference. Sandbox must support multiple processes, open files, gotta have extra memory and control groups must do their job.

Memory limit should be enforced in java's command line instead of in the sandbox.

Info text of a submission is being to the user during the competition. This text may contain sensitive data such as the real answer for a testcase. This should only be sent after the competition ends and when the verdict is Compilation Error.

This is good. Node.js native support for ES6+ features is poor.

Though, it's a challenge to support this, because currently this code uses dynamic path resolution to require local modules. It helps while local testing.

The challenges are:

• Get rid of all dynamic requires. Possibly substitute most of them with static resolved paths and import/export. In this way, this project won't be supposed to be Node-ready by nature anymore.
• Build 4 webpack configs, one for each of the main code modules
  • Judge will have it's code packed to build/judge.js in CommonJS.
  • Express will have it's code packed to build/app.js in CommonJS
  • The other files will remain in their current paths.
• Add 4 npm build scripts commands and one that call all of them
  • npm run build-admin, npm run build-express, npm run build-judge, npm run build-web`.
• Use some kind of babel live transpiler to make local testing easier (that is, to be able to run single files without having to pack them separately [that would be painful, this is important]).

Add support for clarifications. This should imply in a new resource named Clarification, which will contain a possibly null category field, a possibly null problem field, a possibly empty question field and a possibly empty answer field. Also, the clarification may be linked to a specific user or can be broadcasted.

Stop using gulp for building the sass files. Those should be bundled with Webpack. The alternatives are:

• Simply bundle the sass files into the front bundle. The issue here is that they will only be loaded with the whole Vue bundle, which may took long. Anyways, those sass files are strictly related to this SPA, so it's not a problem at all to do this. This may become an issue if we come up with sass files for other parts of our application which are independent of the SPA.

• Bundle them in a different file to load it faster and take advantage of multiple workers in modern browsers.

The first alternative is ok for now.