From 6048f502931328e7ae366ca779564a797c10f264 Mon Sep 17 00:00:00 2001 From: Teyras Date: Sun, 22 Jan 2017 17:12:16 +0100 Subject: [PATCH] nitpicks of Basic concepts --- Rewritten-docs.md | 109 ++++++++++++++++++++++++---------------------- 1 file changed, 57 insertions(+), 52 deletions(-) diff --git a/Rewritten-docs.md b/Rewritten-docs.md index 526007b..9bdd59a 100644 --- a/Rewritten-docs.md +++ b/Rewritten-docs.md @@ -473,82 +473,87 @@ of the system. ## Basic concepts The system is designed as a web application. The requirements say that the user -interface must be accessible from students' computers without the need to -install additional software. This immediately implies that users have to be -connected to the internet, so it is used as communication medium. Today, there -are two main ways of designing graphical user interface -- as a native -application or a web page. Creating a nice and multi-platform application with -graphical interface is almost impossible because of the large number of -different environments. Also, these applications often requires installation or -at least downloading its files (sources or binaries). On the other hand, -distributing a web application is easier, because every personal computer has an -internet browser installed. Also, browsers support an (mostly) unified and -standardized environment of HTML5 and JavaScript. CodEx is also a web -application and everybody seems satisfied with it. There are other communicating -channels most programmers have available, such as e-mail or git, but they are -inappropriate for designing user interfaces on top of them. +interface must be accessible for students without the need to install additional +software. This immediately implies that users have to be connected to the +internet, so it is used as communication medium. Today, there are two main ways +of designing graphical user interfaces -- as a native application or a web page. +Creating a user-friendly and multi-platform application with graphical interface +is almost impossible because of the large number of different environments. +Also, these applications typically require installation or at least downloading +its files (sources or binaries). On the other hand, distributing a web +application is easier, because every personal computer has an internet browser +installed. Also, browsers support a (mostly) unified and standardized +environment of HTML5 and JavaScript. CodEx is also a web application and +everybody seems satisfied with this fact. There are other communicating channels +most programmers use, such as e-mail or git, but they are inappropriate for +designing user interfaces on top of them. The application interacts with users. From the project assignment it is clear, that the system has to keep personalized data about users and adapt presented -content according to this knowledge. User data cannot be publicly visible, so -that implies necessity of user authentication. The application also has to -support multiple ways of authentication (university authentication systems, a -company LDAP server, an OAuth server...) and permit adding more security -measures in the future, such as two-factor authentication. +content according to this knowledge. User data cannot be publicly visible, which +implies necessity of user authentication. The application also has to support +multiple ways of authentication (university authentication systems, a company +LDAP server, an OAuth server...) and permit adding more security measures in the +future, such as two-factor authentication. -User data also includes a privilege level. From the assignment it is required to +User data also include a privilege level. From the assignment it is required to have at least two roles, _student_ and _supervisor_. However, it is wise to add -_administrator_ level, which takes care of the system as a whole and is +_administrator_ level for users who take care of the system as a whole and is responsible for core setup, monitoring, updates and so on. Student role has the least power, basically can just view assignments and submit solutions. Supervisors have more authority, so they can create exercises and assignments, view results of students etc. From the university organization, one possible level could be introduced, _course guarantor_. However, from real experience all duties related with lecturing of labs are already associated with supervisors, -so this role seems not so useful. In addition, no one requested more than three +so this role does not seem useful. In addition, no one requested more than three level privilege scheme. -School labs are lessons for some students lead by supervisors. Students have the -same homework and supervisors are evaluating its solutions. This organization -has to be carried into the new system. Counterpart to real labs are virtual -groups. This concept was already discussed in previous chapter including need -for hierarchical structure of groups. Right for attending labs has only a -person, who is student of the university and is recorded in university -information system. To allow restriction of group members in ReCodEx, there two -type of groups -- _public_ and _private_. Public groups are open for every -registered users, but to become a member of private group one of its supervisors -have to add that user. This could be done automatically at beginning of the term -with data from information system, but unfortunately there is no such API yet. -However, creating this API is now considered by university leadership. Another +School labs are lessons for some students lead by supervisors. All students ina +lab have the same homework and supervisors evaluate their solutions. This +organization has to be carried over into the new system. Virtual groups are a +counterpart to real-life labs. This concept was already discussed in the +previous chapter including the need for a hierarchical structure of groups. Only +students of the university recorded in the university information system have a +right to attend labs. + +To allow restriction of group members in ReCodEx, there are two types of groups +-- _public_ and _private_. Public groups are open for all registered users, but +to become a member of private group, one of its supervisors have to add the +user. This could be done automatically at the beginning of the term with data +from information system, but unfortunately there is no API for this yet. +However, creating this API is now being considered by university staff. Another just as good solution for restricting membership of a group is to allow anyone join the group with supplementary confirmation of supervisors. It has no additional benefits, so approach with public and private groups is implemented. Supervisors using CodEx in their labs usually set minimum amount of points -required to get a credit. These points can be get by solving assigned exercises. -To visually show users if they already have enough points, ReCodEx groups -supports setting this limit. There are two equal ways how to set a limit -- -absolute value or relative value to maximum. The latter way seems nicer, so it -is implemented. The relative value is set in percents and is called threshold. - -Our university has a few partner grammar schools. There were an idea, that they +required to get a credit. These points can be acquired by solving assigned +exercises. To show users whether they already have enough points, ReCodEx also +supports setting this limit for individual groups. There are two equal ways how +to set a limit -- absolute value or relative value to maximum. The latter way +seems nicer, so it is implemented. The relative value is set in percents and is +called threshold. + +Our university has a few partner grammar schools. There was an idea, that they could use CodEx for teaching informatics classes. To make the setup simple for them, all the software and hardware would be provided by the university as a -completely ready-to-use remote service. However, CodEx were not prepared to -support this kind of usage and no one had time to manage a separate instance. -With ReCodEx it is possible to offer hosted environment as a service to other -subjects. The concept we figured out is based on user and group separation -inside the system. There are multiple _instances_ in the system, which means -unit of separation. Each instance has own set of users and groups, exercises can -be optionally shared. Evaluation backend is common for all instances. To keep -track of active instances and paying customers, each instance must have a valid +completely ready-to-use remote service. However, CodEx is not prepared for this +kind of usage and no one has the time to manage a separate instance. With +ReCodEx it is possible to offer hosted environment as a service to other +subjects. + +The concept we came up with is based on user and group separation inside the +system. There are multiple _instances_ in the system, which means unit of +separation. Each instance has own set of users and groups, exercises can be +optionally shared. Evaluation backend is common for all instances. To keep track +of active instances and paying customers, each instance must have a valid _licence_ to allow users submit their solutions. licence is granted for defined period of time and can be revoked in advance if the subject do not keep approved terms and conditions. -The main work for the system is to evaluate programming exercises. The exercise -is quite similar to homework assignment during school labs. When a homework is -assigned, two things are important to know for users: +The primary task of the system is to evaluate programming exercises. The +exercise is quite similar to homework assignment during school labs. When a +homework is assigned, two things are important to know for users: - description of the problem - metadata -- when and whom to submit solutions, grading scale, penalties, etc.