Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-11-14T23:31:38Z

Sjha4:

==Introduction==
Currently, Expertiza doesn’t log anything, beyond the events in the console log. But often we need to know when a student logged in, reserved a topic, dropped off a team, etc. This will help the admin/instructor verify claims made by the student saying that he had submitted something or did some other activity that but didnt get reflected in expertiza due to a bug, a network issue or something else that went wrong.
In a production environment, logs are the best way to debug the application when something goes wrong. In the absence of logs, it is very difficult for a developer/support technician to debug and analyze what went wrong.

In a production environment, logs are the best way to debug the application when something goes wrong. In the absence of logs, it is very difficult for a developer/support technician to debug and analyze what went wrong.

==Events to Log==
====Student Activity====
Logins, logouts, signups, submission of files/links (although there is already a log of when links are submitted), issuing invitations, joining teams, dropping off teams, requesting reviews, submitting reviews (or author feedback, or teammate reviews, or meta-reviews), undoing any of these operations.

====Instructor/TA/Admin Activity====
Creating/editing courses and assignments, giving grades, impersonating other users, adding TAs, adding participants to courses or assignments, assigning reviewers.

==What we plan to implement==
 
[[File:Overall Process.png]]
 
 
There are two parts to this project:
*Logging the events and other information that will help in debugging
*Creating a GUI to interpret the logs and show events for a particular user in a particular time frame.

We are planning to use the logging framework that comes inbuilt with rails. Rails makes use of the '''ActiveSupport::Logger''' class to write log information. Each log statement in the program has a level associated with it which indicates their importance.

The hierarchy of log messages is as below:
*'''UNKNOWN''' : An unknown message that should always be logged.
*'''FATAL''' : A unhandleable error that results in a program crash
*'''ERROR''' : A handleable error condition
*'''WARN''' : Warnings
*'''INFO''' : Useful info about system operation
*'''DEBUG''' : Low level info for developers to help with debugging.

In the config file, we can specify the level of logs to be printed. A log statement in the program will be printed only if its level is equal to or higher than the level set in the config file.

Usually in production, we set the level to INFO or WARN and in in a development environment, we set it to debug which will print out all the finer details of the state of the system which helps in debugging.

Currently, the expertiza code contains very little logging statement and it does not record student/instructor or TA activity. The current logs are also of little or no help to a developer/ support technician trying to debug the code when something goes wrong.

We plan on improving the current log statements by adding more information to it so that it becomes more useful to the person trying to debug the code and will also record all student, TA and instructor activities. We will also be adding more log statements which will make it easier to track all student, TA and instructor activities.

For the second part of the project, we will create a view that is accessible only to the admin from his console. This view will list out the events by interpreting the logs and give an option to filter it based on user and date.

==Design==
====Logging====
 
[[File:Log Events.png]]
 
We are planning to standardize the log statements by giving them a predefined format. This will also help us in the second part of the project which is to interpret the logs and display student activities in a GUI.
This is the format we propose:
*INFO:
[TimeStamp: | controller_name|method| roleid| userid|event: {login|submission|.....}]
We will use this to log entry into methods and to log events like login, submission, joining teams, leaving teams, creating assignments, inviting other user to team etc.
*DEBUG:
[TimeStamp: controller_name| method_name|roleid| userid|{variable_name, variable_value}]
We will use this to print out values of key variables which the developer/debugger can use for debugging.

In the production environment, we will limit the logs to INFO mode, i.e it will print out only the errors and events.

In development environment, we will set the logger mode to DEBUG. This will print out all the logs including errors, events and debug statements. This will help the developer in debugging the code when something goes wrong.

====Interpreting the Logs====
This is the second part of the project. We will be creating a GUI to interpret and make sense of all the log data. The GUI will display the events for each user. We will also give an option to filter the event listing based on date and events.

This is a rough sketch of what the page will look like:
 
 
[[File:LogToGUI.png]]
 
 
It will have a text field to specify the user ID, a drop down menu to select the event and two date picker fields to specify the begin and end dates for the logs

==Testing==
====UI Testing====
The new page which is accessible only to the admin should be used for the UI Testing.
Since this will be a new page, more details on UI testing will be added after implementation.

====RSpec Testing====
New RSpecs will be written wherever required. Logging statements however need not be tested because testing debug statements is not standard practice.

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-11-14T23:26:18Z

Sjha4: /* What we plan to implement */

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-11-14T23:23:56Z

Sjha4: /* What we plan to implement */

==Introduction==
Currently, Expertiza doesn’t log anything, beyond the events in the console log. But often we need to know when a student logged in, reserved a topic, dropped off a team, etc. This will help the admin/instructor verify claims made by the student saying that he had submitted something or did some other activity that but didnt get reflected in expertiza due to a bug, a network issue or something else that went wrong.
In a production environment, logs are the best way to debug the application when something goes wrong. In the absence of logs, it is very difficult for a developer/support technician to debug and analyze what went wrong.

In a production environment, logs are the best way to debug the application when something goes wrong. In the absence of logs, it is very difficult for a developer/support technician to debug and analyze what went wrong.

==Events to Log==
====Student Activity====
Logins, logouts, signups, submission of files/links (although there is already a log of when links are submitted), issuing invitations, joining teams, dropping off teams, requesting reviews, submitting reviews (or author feedback, or teammate reviews, or meta-reviews), undoing any of these operations.

====Instructor/TA/Admin Activity====
Creating/editing courses and assignments, giving grades, impersonating other users, adding TAs, adding participants to courses or assignments, assigning reviewers.

==What we plan to implement==
 
[[File:Overall Process.png]]
 
 
There are two parts to this project:
*Logging the events and other information that will help in debugging
*Creating a GUI to interpret the logs and show events for a particular user in a particular time frame.

We are planning to use the logging framework that comes inbuilt with rails. Rails makes use of the '''ActiveSupport::Logger''' class to write log information. Each log statement in the program has a level associated with it which indicates their importance.

The hierarchy of log messages is as below:
*'''UNKNOWN'''
An unknown message that should always be logged.
*'''FATAL'''
A unhandleable error that results in a program crash
*'''ERROR'''
A handleable error condition
*'''WARN'''
Warnings
*'''INFO'''
Useful info about system operation
*'''DEBUG'''
Low level info for developers to help with debugging.

In the config file, we can specify the level of logs to be printed. A log statement in the program will be printed only if its level is equal to or higher than the level set in the config file.

Usually in production, we set the level to INFO or WARN and in in a development environment, we set it to debug which will print out all the finer details of the state of the system which helps in debugging.

Currently, the expertiza code contains very little logging statement and it does not record student/instructor or TA activity. The current logs are also of little or no help to a developer/ support technician trying to debug the code when something goes wrong.

We plan on improving the current log statements by adding more information to it so that it becomes more useful to the person trying to debug the code and will also record all student, TA and instructor activities. We will also be adding more log statements which will make it easier to track all student, TA and instructor activities.

For the second part of the project, we will create a view that is accessible only to the admin from his console. This view will list out the events by interpreting the logs and give an option to filter it based on user and date.

==Design==
====Logging====
 
[[File:Log Events.png]]
 
We are planning to standardize the log statements by giving them a predefined format. This will also help us in the second part of the project which is to interpret the logs and display student activities in a GUI.
This is the format we propose:
*INFO:
[TimeStamp: | controller_name|method| roleid| userid|event: {login|submission|.....}]
We will use this to log entry into methods and to log events like login, submission, joining teams, leaving teams, creating assignments, inviting other user to team etc.
*DEBUG:
[TimeStamp: controller_name| method_name|roleid| userid|{variable_name, variable_value}]
We will use this to print out values of key variables which the developer/debugger can use for debugging.

In the production environment, we will limit the logs to INFO mode, i.e it will print out only the errors and events.

In development environment, we will set the logger mode to DEBUG. This will print out all the logs including errors, events and debug statements. This will help the developer in debugging the code when something goes wrong.

====Interpreting the Logs====
This is the second part of the project. We will be creating a GUI to interpret and make sense of all the log data. The GUI will display the events for each user. We will also give an option to filter the event listing based on date and events.

This is a rough sketch of what the page will look like:
 
 
[[File:LogToGUI.png]]
 
 
It will have a text field to specify the user ID, a drop down menu to select the event and two date picker fields to specify the begin and end dates for the logs

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-11-14T23:22:42Z

Sjha4: /* What we plan to implement */

==Introduction==
Currently, Expertiza doesn’t log anything, beyond the events in the console log. But often we need to know when a student logged in, reserved a topic, dropped off a team, etc. This will help the admin/instructor verify claims made by the student saying that he had submitted something or did some other activity that but didnt get reflected in expertiza due to a bug, a network issue or something else that went wrong.
In a production environment, logs are the best way to debug the application when something goes wrong. In the absence of logs, it is very difficult for a developer/support technician to debug and analyze what went wrong.

In a production environment, logs are the best way to debug the application when something goes wrong. In the absence of logs, it is very difficult for a developer/support technician to debug and analyze what went wrong.

==Events to Log==
====Student Activity====
Logins, logouts, signups, submission of files/links (although there is already a log of when links are submitted), issuing invitations, joining teams, dropping off teams, requesting reviews, submitting reviews (or author feedback, or teammate reviews, or meta-reviews), undoing any of these operations.

====Instructor/TA/Admin Activity====
Creating/editing courses and assignments, giving grades, impersonating other users, adding TAs, adding participants to courses or assignments, assigning reviewers.

==What we plan to implement==
 
[[File:Overall Process.png]]
 
 
There are two parts to this project:
*Logging the events and other information that will help in debugging
*Creating a GUI to interpret the logs and show events for a particular user in a particular time frame.

We are planning to use the logging framework that comes inbuilt with rails. Rails makes use of the ActiveSupport::Logger class to write log information. Each log statement in the program has a level associated with it which indicates their importance.

The hierarchy of log messages is as below:
*'''UNKNOWN'''
An unknown message that should always be logged.
*'''FATAL'''
A unhandleable error that results in a program crash
*'''ERROR'''
A handleable error condition
*'''WARN'''
Warnings
*'''INFO'''
Useful info about system operation
*'''DEBUG'''
Low level info for developers to help with debugging.

In the config file, we can specify the level of logs to be printed. A log statement in the program will be printed only if its level is equal to or higher than the level set in the config file.

Usually in production, we set the level to INFO or WARN and in in a development environment, we set it to debug which will print out all the finer details of the state of the system which helps in debugging.

Currently, the expertiza code contains very little logging statement and it does not record student/instructor or TA activity. The current logs are also of little or no help to a developer/ support technician trying to debug the code when something goes wrong.

We plan on improving the current log statements by adding more information to it so that it becomes more useful to the person trying to debug the code and will also record all student, TA and instructor activities. We will also be adding more log statements which will make it easier to track all student, TA and instructor activities.

For the second part of the project, we will create a view that is accessible only to the admin from his console. This view will list out the events by interpreting the logs and give an option to filter it based on user and date.

==Design==
====Logging====
 
[[File:Log Events.png]]
 
We are planning to standardize the log statements by giving them a predefined format. This will also help us in the second part of the project which is to interpret the logs and display student activities in a GUI.
This is the format we propose:
*INFO:
[TimeStamp: | controller_name|method| roleid| userid|event: {login|submission|.....}]
We will use this to log entry into methods and to log events like login, submission, joining teams, leaving teams, creating assignments, inviting other user to team etc.
*DEBUG:
[TimeStamp: controller_name| method_name|roleid| userid|{variable_name, variable_value}]
We will use this to print out values of key variables which the developer/debugger can use for debugging.

In the production environment, we will limit the logs to INFO mode, i.e it will print out only the errors and events.

In development environment, we will set the logger mode to DEBUG. This will print out all the logs including errors, events and debug statements. This will help the developer in debugging the code when something goes wrong.

====Interpreting the Logs====
This is the second part of the project. We will be creating a GUI to interpret and make sense of all the log data. The GUI will display the events for each user. We will also give an option to filter the event listing based on date and events.

This is a rough sketch of what the page will look like:
 
 
[[File:LogToGUI.png]]
 
 
It will have a text field to specify the user ID, a drop down menu to select the event and two date picker fields to specify the begin and end dates for the logs

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-11-14T23:22:04Z

Sjha4: /* What we plan to implement */

==Introduction==
Currently, Expertiza doesn’t log anything, beyond the events in the console log. But often we need to know when a student logged in, reserved a topic, dropped off a team, etc. This will help the admin/instructor verify claims made by the student saying that he had submitted something or did some other activity that but didnt get reflected in expertiza due to a bug, a network issue or something else that went wrong.
In a production environment, logs are the best way to debug the application when something goes wrong. In the absence of logs, it is very difficult for a developer/support technician to debug and analyze what went wrong.

In a production environment, logs are the best way to debug the application when something goes wrong. In the absence of logs, it is very difficult for a developer/support technician to debug and analyze what went wrong.

==Events to Log==
====Student Activity====
Logins, logouts, signups, submission of files/links (although there is already a log of when links are submitted), issuing invitations, joining teams, dropping off teams, requesting reviews, submitting reviews (or author feedback, or teammate reviews, or meta-reviews), undoing any of these operations.

====Instructor/TA/Admin Activity====
Creating/editing courses and assignments, giving grades, impersonating other users, adding TAs, adding participants to courses or assignments, assigning reviewers.

==What we plan to implement==
 
[[File:Overall Process.png]]
 
 
There are two parts to this project:
*Logging the events and other information that will help in debugging
*Creating a GUI to interpret the logs and show events for a particular user in a particular time frame.

We are planning to use the logging framework that comes inbuilt with rails. Rails makes use of the ActiveSupport::Logger class to write log information. Each log statement in the program has a level associated with it which indicates their importance.

The hierarchy of log messages is as below:
*'''UNKNOWN''' An unknown message that should always be logged.
*'''FATAL''' A unhandleable error that results in a program crash
*'''ERROR''' A handleable error condition
*'''WARN''' Warnings
*'''INFO''' Useful info about system operation
*'''DEBUG''' Low level info for developers to help with debugging.

In the config file, we can specify the level of logs to be printed. A log statement in the program will be printed only if its level is equal to or higher than the level set in the config file.

Usually in production, we set the level to INFO or WARN and in in a development environment, we set it to debug which will print out all the finer details of the state of the system which helps in debugging.

Currently, the expertiza code contains very little logging statement and it does not record student/instructor or TA activity. The current logs are also of little or no help to a developer/ support technician trying to debug the code when something goes wrong.

We plan on improving the current log statements by adding more information to it so that it becomes more useful to the person trying to debug the code and will also record all student, TA and instructor activities. We will also be adding more log statements which will make it easier to track all student, TA and instructor activities.

For the second part of the project, we will create a view that is accessible only to the admin from his console. This view will list out the events by interpreting the logs and give an option to filter it based on user and date.

==Design==
====Logging====
 
[[File:Log Events.png]]
 
We are planning to standardize the log statements by giving them a predefined format. This will also help us in the second part of the project which is to interpret the logs and display student activities in a GUI.
This is the format we propose:
*INFO:
[TimeStamp: | controller_name|method| roleid| userid|event: {login|submission|.....}]
We will use this to log entry into methods and to log events like login, submission, joining teams, leaving teams, creating assignments, inviting other user to team etc.
*DEBUG:
[TimeStamp: controller_name| method_name|roleid| userid|{variable_name, variable_value}]
We will use this to print out values of key variables which the developer/debugger can use for debugging.

In the production environment, we will limit the logs to INFO mode, i.e it will print out only the errors and events.

In development environment, we will set the logger mode to DEBUG. This will print out all the logs including errors, events and debug statements. This will help the developer in debugging the code when something goes wrong.

====Interpreting the Logs====
This is the second part of the project. We will be creating a GUI to interpret and make sense of all the log data. The GUI will display the events for each user. We will also give an option to filter the event listing based on date and events.

This is a rough sketch of what the page will look like:
 
 
[[File:LogToGUI.png]]
 
 
It will have a text field to specify the user ID, a drop down menu to select the event and two date picker fields to specify the begin and end dates for the logs

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-11-14T23:18:37Z

Sjha4: /* What we plan to implement */

==Introduction==
Currently, Expertiza doesn’t log anything, beyond the events in the console log. But often we need to know when a student logged in, reserved a topic, dropped off a team, etc. This will help the admin/instructor verify claims made by the student saying that he had submitted something or did some other activity that but didnt get reflected in expertiza due to a bug, a network issue or something else that went wrong.
In a production environment, logs are the best way to debug the application when something goes wrong. In the absence of logs, it is very difficult for a developer/support technician to debug and analyze what went wrong.

In a production environment, logs are the best way to debug the application when something goes wrong. In the absence of logs, it is very difficult for a developer/support technician to debug and analyze what went wrong.

==Events to Log==
====Student Activity====
Logins, logouts, signups, submission of files/links (although there is already a log of when links are submitted), issuing invitations, joining teams, dropping off teams, requesting reviews, submitting reviews (or author feedback, or teammate reviews, or meta-reviews), undoing any of these operations.

====Instructor/TA/Admin Activity====
Creating/editing courses and assignments, giving grades, impersonating other users, adding TAs, adding participants to courses or assignments, assigning reviewers.

==What we plan to implement==
 
[[File:Overall Process.png]]
 
 
There are two parts to this project:
*Logging the events and other information that will help in debugging
*Creating a GUI to interpret the logs and show events for a particular user in a particular time frame.

We are planning to use the logging framework that comes inbuilt with rails. Rails makes use of the ActiveSupport::Logger class to write log information. Each log statement in the program has a level associated with it which indicates their importance.

The hierarchy of log messages is as below:
*UNKNOWN: An unknown message that should always be logged.
*FATAL: A unhandleable error that results in a program crash
*ERROR: A handleable error condition
*WARN: Warnings
*INFO: Useful info about system operation
*DEBUG: Low level info for developers to help with debugging.

In the config file, we can specify the level of logs to be printed. A log statement in the program will be printed only if its level is equal to or higher than the level set in the config file.

Usually in production, we set the level to INFO or WARN and in in a development environment, we set it to debug which will print out all the finer details of the state of the system which helps in debugging.

Currently, the expertiza code contains very little logging statement and it does not record student/instructor or TA activity. The current logs are also of little or no help to a developer/ support technician trying to debug the code when something goes wrong.

We plan on improving the current log statements by adding more information to it so that it becomes more useful to the person trying to debug the code and will also record all student, TA and instructor activities. We will also be adding more log statements which will make it easier to track all student, TA and instructor activities.

For the second part of the project, we will create a view that is accessible only to the admin from his console. This view will list out the events by interpreting the logs and give an option to filter it based on user and date.

==Design==
====Logging====
 
[[File:Log Events.png]]
 
We are planning to standardize the log statements by giving them a predefined format. This will also help us in the second part of the project which is to interpret the logs and display student activities in a GUI.
This is the format we propose:
*INFO:
[TimeStamp: | controller_name|method| roleid| userid|event: {login|submission|.....}]
We will use this to log entry into methods and to log events like login, submission, joining teams, leaving teams, creating assignments, inviting other user to team etc.
*DEBUG:
[TimeStamp: controller_name| method_name|roleid| userid|{variable_name, variable_value}]
We will use this to print out values of key variables which the developer/debugger can use for debugging.

In the production environment, we will limit the logs to INFO mode, i.e it will print out only the errors and events.

In development environment, we will set the logger mode to DEBUG. This will print out all the logs including errors, events and debug statements. This will help the developer in debugging the code when something goes wrong.

====Interpreting the Logs====
This is the second part of the project. We will be creating a GUI to interpret and make sense of all the log data. The GUI will display the events for each user. We will also give an option to filter the event listing based on date and events.

This is a rough sketch of what the page will look like:
 
 
[[File:LogToGUI.png]]
 
 
It will have a text field to specify the user ID, a drop down menu to select the event and two date picker fields to specify the begin and end dates for the logs

File:Overall Process.png

2016-11-14T23:18:10Z

Sjha4:

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-11-14T23:17:58Z

Sjha4:

==Introduction==
Currently, Expertiza doesn’t log anything, beyond the events in the console log. But often we need to know when a student logged in, reserved a topic, dropped off a team, etc. This will help the admin/instructor verify claims made by the student saying that he had submitted something or did some other activity that but didnt get reflected in expertiza due to a bug, a network issue or something else that went wrong.
In a production environment, logs are the best way to debug the application when something goes wrong. In the absence of logs, it is very difficult for a developer/support technician to debug and analyze what went wrong.

In a production environment, logs are the best way to debug the application when something goes wrong. In the absence of logs, it is very difficult for a developer/support technician to debug and analyze what went wrong.

==Events to Log==
====Student Activity====
Logins, logouts, signups, submission of files/links (although there is already a log of when links are submitted), issuing invitations, joining teams, dropping off teams, requesting reviews, submitting reviews (or author feedback, or teammate reviews, or meta-reviews), undoing any of these operations.

====Instructor/TA/Admin Activity====
Creating/editing courses and assignments, giving grades, impersonating other users, adding TAs, adding participants to courses or assignments, assigning reviewers.

==What we plan to implement==
 
 
[[File:Overall Process.png]]
 
 
There are two parts to this project:
*Logging the events and other information that will help in debugging
*Creating a GUI to interpret the logs and show events for a particular user in a particular time frame.

We are planning to use the logging framework that comes inbuilt with rails. Rails makes use of the ActiveSupport::Logger class to write log information. Each log statement in the program has a level associated with it which indicates their importance.

The hierarchy of log messages is as below:
*UNKNOWN: An unknown message that should always be logged.
*FATAL: A unhandleable error that results in a program crash
*ERROR: A handleable error condition
*WARN: Warnings
*INFO: Useful info about system operation
*DEBUG: Low level info for developers to help with debugging.

In the config file, we can specify the level of logs to be printed. A log statement in the program will be printed only if its level is equal to or higher than the level set in the config file.

Usually in production, we set the level to INFO or WARN and in in a development environment, we set it to debug which will print out all the finer details of the state of the system which helps in debugging.

Currently, the expertiza code contains very little logging statement and it does not record student/instructor or TA activity. The current logs are also of little or no help to a developer/ support technician trying to debug the code when something goes wrong.

We plan on improving the current log statements by adding more information to it so that it becomes more useful to the person trying to debug the code and will also record all student, TA and instructor activities. We will also be adding more log statements which will make it easier to track all student, TA and instructor activities.

For the second part of the project, we will create a view that is accessible only to the admin from his console. This view will list out the events by interpreting the logs and give an option to filter it based on user and date.

==Design==
====Logging====
 
[[File:Log Events.png]]
 
We are planning to standardize the log statements by giving them a predefined format. This will also help us in the second part of the project which is to interpret the logs and display student activities in a GUI.
This is the format we propose:
*INFO:
[TimeStamp: | controller_name|method| roleid| userid|event: {login|submission|.....}]
We will use this to log entry into methods and to log events like login, submission, joining teams, leaving teams, creating assignments, inviting other user to team etc.
*DEBUG:
[TimeStamp: controller_name| method_name|roleid| userid|{variable_name, variable_value}]
We will use this to print out values of key variables which the developer/debugger can use for debugging.

In the production environment, we will limit the logs to INFO mode, i.e it will print out only the errors and events.

In development environment, we will set the logger mode to DEBUG. This will print out all the logs including errors, events and debug statements. This will help the developer in debugging the code when something goes wrong.

====Interpreting the Logs====
This is the second part of the project. We will be creating a GUI to interpret and make sense of all the log data. The GUI will display the events for each user. We will also give an option to filter the event listing based on date and events.

This is a rough sketch of what the page will look like:
 
 
[[File:LogToGUI.png]]
 
 
It will have a text field to specify the user ID, a drop down menu to select the event and two date picker fields to specify the begin and end dates for the logs

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-11-14T23:17:05Z

Sjha4: /* What we plan to implement */

==Introduction==
Currently, Expertiza doesn’t log anything, beyond the events in the console log. But often we need to know when a student logged in, reserved a topic, dropped off a team, etc. This will help the admin/instructor verify claims made by the student saying that he had submitted something or did some other activity that but didnt get reflected in expertiza due to a bug, a network issue or something else that went wrong.
In a production environment, logs are the best way to debug the application when something goes wrong. In the absence of logs, it is very difficult for a developer/support technician to debug and analyze what went wrong.

In a production environment, logs are the best way to debug the application when something goes wrong. In the absence of logs, it is very difficult for a developer/support technician to debug and analyze what went wrong.

==Events to Log==
====Student Activity====
Logins, logouts, signups, submission of files/links (although there is already a log of when links are submitted), issuing invitations, joining teams, dropping off teams, requesting reviews, submitting reviews (or author feedback, or teammate reviews, or meta-reviews), undoing any of these operations.

====Instructor/TA/Admin Activity====
Creating/editing courses and assignments, giving grades, impersonating other users, adding TAs, adding participants to courses or assignments, assigning reviewers.

==What we plan to implement==
 
 
 
 
There are two parts to this project:
*Logging the events and other information that will help in debugging
*Creating a GUI to interpret the logs and show events for a particular user in a particular time frame.

We are planning to use the logging framework that comes inbuilt with rails. Rails makes use of the ActiveSupport::Logger class to write log information. Each log statement in the program has a level associated with it which indicates their importance.

The hierarchy of log messages is as below:
*UNKNOWN: An unknown message that should always be logged.
*FATAL: A unhandleable error that results in a program crash
*ERROR: A handleable error condition
*WARN: Warnings
*INFO: Useful info about system operation
*DEBUG: Low level info for developers to help with debugging.

In the config file, we can specify the level of logs to be printed. A log statement in the program will be printed only if its level is equal to or higher than the level set in the config file.

Usually in production, we set the level to INFO or WARN and in in a development environment, we set it to debug which will print out all the finer details of the state of the system which helps in debugging.

Currently, the expertiza code contains very little logging statement and it does not record student/instructor or TA activity. The current logs are also of little or no help to a developer/ support technician trying to debug the code when something goes wrong.

We plan on improving the current log statements by adding more information to it so that it becomes more useful to the person trying to debug the code and will also record all student, TA and instructor activities. We will also be adding more log statements which will make it easier to track all student, TA and instructor activities.

For the second part of the project, we will create a view that is accessible only to the admin from his console. This view will list out the events by interpreting the logs and give an option to filter it based on user and date.

==Design==
====Logging====
 
[[File:Log Events.png]]
 
We are planning to standardize the log statements by giving them a predefined format. This will also help us in the second part of the project which is to interpret the logs and display student activities in a GUI.
This is the format we propose:
*INFO:
[TimeStamp: | controller_name|method| roleid| userid|event: {login|submission|.....}]
We will use this to log entry into methods and to log events like login, submission, joining teams, leaving teams, creating assignments, inviting other user to team etc.
*DEBUG:
[TimeStamp: controller_name| method_name|roleid| userid|{variable_name, variable_value}]
We will use this to print out values of key variables which the developer/debugger can use for debugging.

In the production environment, we will limit the logs to INFO mode, i.e it will print out only the errors and events.

In development environment, we will set the logger mode to DEBUG. This will print out all the logs including errors, events and debug statements. This will help the developer in debugging the code when something goes wrong.

====Interpreting the Logs====
This is the second part of the project. We will be creating a GUI to interpret and make sense of all the log data. The GUI will display the events for each user. We will also give an option to filter the event listing based on date and events.

This is a rough sketch of what the page will look like:
 
 
[[File:LogToGUI.png]]
 
 
It will have a text field to specify the user ID, a drop down menu to select the event and two date picker fields to specify the begin and end dates for the logs

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-11-14T23:06:08Z

Sjha4: /* Interpreting the Logs */

==Introduction==
Currently, Expertiza doesn’t log anything, beyond the events in the console log. But often we need to know when a student logged in, reserved a topic, dropped off a team, etc. This will help the admin/instructor verify claims made by the student saying that he had submitted something or did some other activity that but didnt get reflected in expertiza due to a bug, a network issue or something else that went wrong.
In a production environment, logs are the best way to debug the application when something goes wrong. In the absence of logs, it is very difficult for a developer/support technician to debug and analyze what went wrong.

In a production environment, logs are the best way to debug the application when something goes wrong. In the absence of logs, it is very difficult for a developer/support technician to debug and analyze what went wrong.

==Events to Log==
====Student Activity====
Logins, logouts, signups, submission of files/links (although there is already a log of when links are submitted), issuing invitations, joining teams, dropping off teams, requesting reviews, submitting reviews (or author feedback, or teammate reviews, or meta-reviews), undoing any of these operations.

====Instructor/TA/Admin Activity====
Creating/editing courses and assignments, giving grades, impersonating other users, adding TAs, adding participants to courses or assignments, assigning reviewers.

==What we plan to implement==
There are two parts to this project:
*Logging the events and other information that will help in debugging
*Creating a GUI to interpret the logs and show events for a particular user in a particular time frame.

We are planning to use the logging framework that comes inbuilt with rails. Rails makes use of the ActiveSupport::Logger class to write log information. Each log statement in the program has a level associated with it which indicates their importance.

The hierarchy of log messages is as below:
*UNKNOWN: An unknown message that should always be logged.
*FATAL: A unhandleable error that results in a program crash
*ERROR: A handleable error condition
*WARN: Warnings
*INFO: Useful info about system operation
*DEBUG: Low level info for developers to help with debugging.

In the config file, we can specify the level of logs to be printed. A log statement in the program will be printed only if its level is equal to or higher than the level set in the config file.

Usually in production, we set the level to INFO or WARN and in in a development environment, we set it to debug which will print out all the finer details of the state of the system which helps in debugging.

Currently, the expertiza code contains very little logging statement and it does not record student/instructor or TA activity. The current logs are also of little or no help to a developer/ support technician trying to debug the code when something goes wrong.

We plan on improving the current log statements by adding more information to it so that it becomes more useful to the person trying to debug the code and will also record all student, TA and instructor activities. We will also be adding more log statements which will make it easier to track all student, TA and instructor activities.

For the second part of the project, we will create a view that is accessible only to the admin from his console. This view will list out the events by interpreting the logs and give an option to filter it based on user and date.

==Design==
====Logging====
 
[[File:Log Events.png]]
 
We are planning to standardize the log statements by giving them a predefined format. This will also help us in the second part of the project which is to interpret the logs and display student activities in a GUI.
This is the format we propose:
*INFO:
[TimeStamp: | controller_name|method| roleid| userid|event: {login|submission|.....}]
We will use this to log entry into methods and to log events like login, submission, joining teams, leaving teams, creating assignments, inviting other user to team etc.
*DEBUG:
[TimeStamp: controller_name| method_name|roleid| userid|{variable_name, variable_value}]
We will use this to print out values of key variables which the developer/debugger can use for debugging.

In the production environment, we will limit the logs to INFO mode, i.e it will print out only the errors and events.

In development environment, we will set the logger mode to DEBUG. This will print out all the logs including errors, events and debug statements. This will help the developer in debugging the code when something goes wrong.

====Interpreting the Logs====
This is the second part of the project. We will be creating a GUI to interpret and make sense of all the log data. The GUI will display the events for each user. We will also give an option to filter the event listing based on date and events.

This is a rough sketch of what the page will look like:
 
 
[[File:LogToGUI.png]]
 
 
It will have a text field to specify the user ID, a drop down menu to select the event and two date picker fields to specify the begin and end dates for the logs

File:LogToGUI.png

2016-11-14T23:04:45Z

Sjha4:

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-11-14T23:04:29Z

Sjha4: /* Interpreting the Logs */

==Introduction==
Currently, Expertiza doesn’t log anything, beyond the events in the console log. But often we need to know when a student logged in, reserved a topic, dropped off a team, etc. This will help the admin/instructor verify claims made by the student saying that he had submitted something or did some other activity that but didnt get reflected in expertiza due to a bug, a network issue or something else that went wrong.
In a production environment, logs are the best way to debug the application when something goes wrong. In the absence of logs, it is very difficult for a developer/support technician to debug and analyze what went wrong.

In a production environment, logs are the best way to debug the application when something goes wrong. In the absence of logs, it is very difficult for a developer/support technician to debug and analyze what went wrong.

==Events to Log==
====Student Activity====
Logins, logouts, signups, submission of files/links (although there is already a log of when links are submitted), issuing invitations, joining teams, dropping off teams, requesting reviews, submitting reviews (or author feedback, or teammate reviews, or meta-reviews), undoing any of these operations.

====Instructor/TA/Admin Activity====
Creating/editing courses and assignments, giving grades, impersonating other users, adding TAs, adding participants to courses or assignments, assigning reviewers.

==What we plan to implement==
There are two parts to this project:
*Logging the events and other information that will help in debugging
*Creating a GUI to interpret the logs and show events for a particular user in a particular time frame.

We are planning to use the logging framework that comes inbuilt with rails. Rails makes use of the ActiveSupport::Logger class to write log information. Each log statement in the program has a level associated with it which indicates their importance.

The hierarchy of log messages is as below:
*UNKNOWN: An unknown message that should always be logged.
*FATAL: A unhandleable error that results in a program crash
*ERROR: A handleable error condition
*WARN: Warnings
*INFO: Useful info about system operation
*DEBUG: Low level info for developers to help with debugging.

In the config file, we can specify the level of logs to be printed. A log statement in the program will be printed only if its level is equal to or higher than the level set in the config file.

Usually in production, we set the level to INFO or WARN and in in a development environment, we set it to debug which will print out all the finer details of the state of the system which helps in debugging.

Currently, the expertiza code contains very little logging statement and it does not record student/instructor or TA activity. The current logs are also of little or no help to a developer/ support technician trying to debug the code when something goes wrong.

We plan on improving the current log statements by adding more information to it so that it becomes more useful to the person trying to debug the code and will also record all student, TA and instructor activities. We will also be adding more log statements which will make it easier to track all student, TA and instructor activities.

For the second part of the project, we will create a view that is accessible only to the admin from his console. This view will list out the events by interpreting the logs and give an option to filter it based on user and date.

==Design==
====Logging====
 
[[File:Log Events.png]]
 
We are planning to standardize the log statements by giving them a predefined format. This will also help us in the second part of the project which is to interpret the logs and display student activities in a GUI.
This is the format we propose:
*INFO:
[TimeStamp: | controller_name|method| roleid| userid|event: {login|submission|.....}]
We will use this to log entry into methods and to log events like login, submission, joining teams, leaving teams, creating assignments, inviting other user to team etc.
*DEBUG:
[TimeStamp: controller_name| method_name|roleid| userid|{variable_name, variable_value}]
We will use this to print out values of key variables which the developer/debugger can use for debugging.

In the production environment, we will limit the logs to INFO mode, i.e it will print out only the errors and events.

In development environment, we will set the logger mode to DEBUG. This will print out all the logs including errors, events and debug statements. This will help the developer in debugging the code when something goes wrong.

====Interpreting the Logs====
This is the second part of the project. We will be creating a GUI to interpret and make sense of all the log data. The GUI will display the events for each user. We will also give an option to filter the event listing based on date and events.

This is a rough sketch of what the page will look like:
[[File:LogToGUI.png|frame]]
 
 
It will have a text field to specify the user ID, a drop down menu to select the event and two date picker fields to specify the begin and end dates for the logs

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-11-14T22:58:16Z

Sjha4: /* Logging */

==Introduction==
Currently, Expertiza doesn’t log anything, beyond the events in the console log. But often we need to know when a student logged in, reserved a topic, dropped off a team, etc. This will help the admin/instructor verify claims made by the student saying that he had submitted something or did some other activity that but didnt get reflected in expertiza due to a bug, a network issue or something else that went wrong.
In a production environment, logs are the best way to debug the application when something goes wrong. In the absence of logs, it is very difficult for a developer/support technician to debug and analyze what went wrong.

In a production environment, logs are the best way to debug the application when something goes wrong. In the absence of logs, it is very difficult for a developer/support technician to debug and analyze what went wrong.

==Events to Log==
====Student Activity====
Logins, logouts, signups, submission of files/links (although there is already a log of when links are submitted), issuing invitations, joining teams, dropping off teams, requesting reviews, submitting reviews (or author feedback, or teammate reviews, or meta-reviews), undoing any of these operations.

====Instructor/TA/Admin Activity====
Creating/editing courses and assignments, giving grades, impersonating other users, adding TAs, adding participants to courses or assignments, assigning reviewers.

==What we plan to implement==
There are two parts to this project:
*Logging the events and other information that will help in debugging
*Creating a GUI to interpret the logs and show events for a particular user in a particular time frame.

We are planning to use the logging framework that comes inbuilt with rails. Rails makes use of the ActiveSupport::Logger class to write log information. Each log statement in the program has a level associated with it which indicates their importance.

The hierarchy of log messages is as below:
*UNKNOWN: An unknown message that should always be logged.
*FATAL: A unhandleable error that results in a program crash
*ERROR: A handleable error condition
*WARN: Warnings
*INFO: Useful info about system operation
*DEBUG: Low level info for developers to help with debugging.

In the config file, we can specify the level of logs to be printed. A log statement in the program will be printed only if its level is equal to or higher than the level set in the config file.

Usually in production, we set the level to INFO or WARN and in in a development environment, we set it to debug which will print out all the finer details of the state of the system which helps in debugging.

Currently, the expertiza code contains very little logging statement and it does not record student/instructor or TA activity. The current logs are also of little or no help to a developer/ support technician trying to debug the code when something goes wrong.

We plan on improving the current log statements by adding more information to it so that it becomes more useful to the person trying to debug the code and will also record all student, TA and instructor activities. We will also be adding more log statements which will make it easier to track all student, TA and instructor activities.

For the second part of the project, we will create a view that is accessible only to the admin from his console. This view will list out the events by interpreting the logs and give an option to filter it based on user and date.

==Design==
====Logging====
 
[[File:Log Events.png]]
 
We are planning to standardize the log statements by giving them a predefined format. This will also help us in the second part of the project which is to interpret the logs and display student activities in a GUI.
This is the format we propose:
*INFO:
[TimeStamp: | controller_name|method| roleid| userid|event: {login|submission|.....}]
We will use this to log entry into methods and to log events like login, submission, joining teams, leaving teams, creating assignments, inviting other user to team etc.
*DEBUG:
[TimeStamp: controller_name| method_name|roleid| userid|{variable_name, variable_value}]
We will use this to print out values of key variables which the developer/debugger can use for debugging.

In the production environment, we will limit the logs to INFO mode, i.e it will print out only the errors and events.

In development environment, we will set the logger mode to DEBUG. This will print out all the logs including errors, events and debug statements. This will help the developer in debugging the code when something goes wrong.

====Interpreting the Logs====
This is the second part of the project. We will be creating a GUI to interpret and make sense of all the log data. The GUI will display the events for each user. We will also give an option to filter the event listing based on date and events.

This is a rough sketch of what the page will look like:
[[File:sketch.png|frame]]
 
 
It will have a text field to specify the user ID, a drop down menu to select the event and two date picker fields to specify the begin and end dates for the logs

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-11-14T22:56:32Z

Sjha4: /* Logging */

==Introduction==
Currently, Expertiza doesn’t log anything, beyond the events in the console log. But often we need to know when a student logged in, reserved a topic, dropped off a team, etc. This will help the admin/instructor verify claims made by the student saying that he had submitted something or did some other activity that but didnt get reflected in expertiza due to a bug, a network issue or something else that went wrong.
In a production environment, logs are the best way to debug the application when something goes wrong. In the absence of logs, it is very difficult for a developer/support technician to debug and analyze what went wrong.

In a production environment, logs are the best way to debug the application when something goes wrong. In the absence of logs, it is very difficult for a developer/support technician to debug and analyze what went wrong.

==Events to Log==
====Student Activity====
Logins, logouts, signups, submission of files/links (although there is already a log of when links are submitted), issuing invitations, joining teams, dropping off teams, requesting reviews, submitting reviews (or author feedback, or teammate reviews, or meta-reviews), undoing any of these operations.

====Instructor/TA/Admin Activity====
Creating/editing courses and assignments, giving grades, impersonating other users, adding TAs, adding participants to courses or assignments, assigning reviewers.

==What we plan to implement==
There are two parts to this project:
*Logging the events and other information that will help in debugging
*Creating a GUI to interpret the logs and show events for a particular user in a particular time frame.

We are planning to use the logging framework that comes inbuilt with rails. Rails makes use of the ActiveSupport::Logger class to write log information. Each log statement in the program has a level associated with it which indicates their importance.

The hierarchy of log messages is as below:
*UNKNOWN: An unknown message that should always be logged.
*FATAL: A unhandleable error that results in a program crash
*ERROR: A handleable error condition
*WARN: Warnings
*INFO: Useful info about system operation
*DEBUG: Low level info for developers to help with debugging.

In the config file, we can specify the level of logs to be printed. A log statement in the program will be printed only if its level is equal to or higher than the level set in the config file.

Usually in production, we set the level to INFO or WARN and in in a development environment, we set it to debug which will print out all the finer details of the state of the system which helps in debugging.

Currently, the expertiza code contains very little logging statement and it does not record student/instructor or TA activity. The current logs are also of little or no help to a developer/ support technician trying to debug the code when something goes wrong.

We plan on improving the current log statements by adding more information to it so that it becomes more useful to the person trying to debug the code and will also record all student, TA and instructor activities. We will also be adding more log statements which will make it easier to track all student, TA and instructor activities.

For the second part of the project, we will create a view that is accessible only to the admin from his console. This view will list out the events by interpreting the logs and give an option to filter it based on user and date.

==Design==
====Logging====
[[File:Log Events.png|frame]]
 
We are planning to standardize the log statements by giving them a predefined format. This will also help us in the second part of the project which is to interpret the logs and display student activities in a GUI.
This is the format we propose:
*INFO:
[TimeStamp: | controller_name|method| roleid| userid|event: {login|submission|.....}]
We will use this to log entry into methods and to log events like login, submission, joining teams, leaving teams, creating assignments, inviting other user to team etc.
*DEBUG:
[TimeStamp: controller_name| method_name|roleid| userid|{variable_name, variable_value}]
We will use this to print out values of key variables which the developer/debugger can use for debugging.

In the production environment, we will limit the logs to INFO mode, i.e it will print out only the errors and events.

In development environment, we will set the logger mode to DEBUG. This will print out all the logs including errors, events and debug statements. This will help the developer in debugging the code when something goes wrong.

====Interpreting the Logs====
This is the second part of the project. We will be creating a GUI to interpret and make sense of all the log data. The GUI will display the events for each user. We will also give an option to filter the event listing based on date and events.

This is a rough sketch of what the page will look like:
[[File:sketch.png|frame]]
 
 
It will have a text field to specify the user ID, a drop down menu to select the event and two date picker fields to specify the begin and end dates for the logs

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-11-14T22:55:55Z

Sjha4: Adding Design diagram

==Introduction==
Currently, Expertiza doesn’t log anything, beyond the events in the console log. But often we need to know when a student logged in, reserved a topic, dropped off a team, etc. This will help the admin/instructor verify claims made by the student saying that he had submitted something or did some other activity that but didnt get reflected in expertiza due to a bug, a network issue or something else that went wrong.
In a production environment, logs are the best way to debug the application when something goes wrong. In the absence of logs, it is very difficult for a developer/support technician to debug and analyze what went wrong.

In a production environment, logs are the best way to debug the application when something goes wrong. In the absence of logs, it is very difficult for a developer/support technician to debug and analyze what went wrong.

==Events to Log==
====Student Activity====
Logins, logouts, signups, submission of files/links (although there is already a log of when links are submitted), issuing invitations, joining teams, dropping off teams, requesting reviews, submitting reviews (or author feedback, or teammate reviews, or meta-reviews), undoing any of these operations.

====Instructor/TA/Admin Activity====
Creating/editing courses and assignments, giving grades, impersonating other users, adding TAs, adding participants to courses or assignments, assigning reviewers.

==What we plan to implement==
There are two parts to this project:
*Logging the events and other information that will help in debugging
*Creating a GUI to interpret the logs and show events for a particular user in a particular time frame.

We are planning to use the logging framework that comes inbuilt with rails. Rails makes use of the ActiveSupport::Logger class to write log information. Each log statement in the program has a level associated with it which indicates their importance.

The hierarchy of log messages is as below:
*UNKNOWN: An unknown message that should always be logged.
*FATAL: A unhandleable error that results in a program crash
*ERROR: A handleable error condition
*WARN: Warnings
*INFO: Useful info about system operation
*DEBUG: Low level info for developers to help with debugging.

In the config file, we can specify the level of logs to be printed. A log statement in the program will be printed only if its level is equal to or higher than the level set in the config file.

Usually in production, we set the level to INFO or WARN and in in a development environment, we set it to debug which will print out all the finer details of the state of the system which helps in debugging.

Currently, the expertiza code contains very little logging statement and it does not record student/instructor or TA activity. The current logs are also of little or no help to a developer/ support technician trying to debug the code when something goes wrong.

We plan on improving the current log statements by adding more information to it so that it becomes more useful to the person trying to debug the code and will also record all student, TA and instructor activities. We will also be adding more log statements which will make it easier to track all student, TA and instructor activities.

For the second part of the project, we will create a view that is accessible only to the admin from his console. This view will list out the events by interpreting the logs and give an option to filter it based on user and date.

==Design==
====Logging====
[[File:Log Events.png|frame]]
We are planning to standardize the log statements by giving them a predefined format. This will also help us in the second part of the project which is to interpret the logs and display student activities in a GUI.
This is the format we propose:
*INFO:
[TimeStamp: | controller_name|method| roleid| userid|event: {login|submission|.....}]
We will use this to log entry into methods and to log events like login, submission, joining teams, leaving teams, creating assignments, inviting other user to team etc.
*DEBUG:
[TimeStamp: controller_name| method_name|roleid| userid|{variable_name, variable_value}]
We will use this to print out values of key variables which the developer/debugger can use for debugging.

In the production environment, we will limit the logs to INFO mode, i.e it will print out only the errors and events.

In development environment, we will set the logger mode to DEBUG. This will print out all the logs including errors, events and debug statements. This will help the developer in debugging the code when something goes wrong.

====Interpreting the Logs====
This is the second part of the project. We will be creating a GUI to interpret and make sense of all the log data. The GUI will display the events for each user. We will also give an option to filter the event listing based on date and events.

This is a rough sketch of what the page will look like:
[[File:sketch.png|frame]]
 
 
It will have a text field to specify the user ID, a drop down menu to select the event and two date picker fields to specify the begin and end dates for the logs

File:Log Events.png

2016-11-14T22:55:17Z

Sjha4:

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-11-14T22:21:41Z

Sjha4: Adding Design

==Introduction==
Currently, Expertiza doesn’t log anything, beyond the events in the console log. But often we need to know when a student logged in, reserved a topic, dropped off a team, etc. This will help the admin/instructor verify claims made by the student saying that he had submitted something or did some other activity that but didnt get reflected in expertiza due to a bug, a network issue or something else that went wrong.
In a production environment, logs are the best way to debug the application when something goes wrong. In the absence of logs, it is very difficult for a developer/support technician to debug and analyze what went wrong.

In a production environment, logs are the best way to debug the application when something goes wrong. In the absence of logs, it is very difficult for a developer/support technician to debug and analyze what went wrong.

==Events to Log==
====Student Activity====
Logins, logouts, signups, submission of files/links (although there is already a log of when links are submitted), issuing invitations, joining teams, dropping off teams, requesting reviews, submitting reviews (or author feedback, or teammate reviews, or meta-reviews), undoing any of these operations.

====Instructor/TA/Admin Activity====
Creating/editing courses and assignments, giving grades, impersonating other users, adding TAs, adding participants to courses or assignments, assigning reviewers.

==What we plan to implement==
There are two parts to this project:
*Logging the events and other information that will help in debugging
*Creating a GUI to interpret the logs and show events for a particular user in a particular time frame.

We are planning to use the logging framework that comes inbuilt with rails. Rails makes use of the ActiveSupport::Logger class to write log information. Each log statement in the program has a level associated with it which indicates their importance.

The hierarchy of log messages is as below:
*UNKNOWN: An unknown message that should always be logged.
*FATAL: A unhandleable error that results in a program crash
*ERROR: A handleable error condition
*WARN: Warnings
*INFO: Useful info about system operation
*DEBUG: Low level info for developers to help with debugging.

In the config file, we can specify the level of logs to be printed. A log statement in the program will be printed only if its level is equal to or higher than the level set in the config file.

Usually in production, we set the level to INFO or WARN and in in a development environment, we set it to debug which will print out all the finer details of the state of the system which helps in debugging.

Currently, the expertiza code contains very little logging statement and it does not record student/instructor or TA activity. The current logs are also of little or no help to a developer/ support technician trying to debug the code when something goes wrong.

We plan on improving the current log statements by adding more information to it so that it becomes more useful to the person trying to debug the code and will also record all student, TA and instructor activities. We will also be adding more log statements which will make it easier to track all student, TA and instructor activities.

For the second part of the project, we will create a view that is accessible only to the admin from his console. This view will list out the events by interpreting the logs and give an option to filter it based on user and date.

==Design==
====Logging====
We are planning to standardize the log statements by giving them a predefined format. This will also help us in the second part of the project which is to interpret the logs and display student activities in a GUI.
This is the format we propose:
*INFO:
[TimeStamp: | controller_name|method| roleid| userid|event: {login|submission|.....}]
We will use this to log entry into methods and to log events like login, submission, joining teams, leaving teams, creating assignments, inviting other user to team etc.
*DEBUG:
[TimeStamp: controller_name| method_name|roleid| userid|{variable_name, variable_value}]
We will use this to print out values of key variables which the developer/debugger can use for debugging.

In the production environment, we will limit the logs to INFO mode, i.e it will print out only the errors and events.

In development environment, we will set the logger mode to DEBUG. This will print out all the logs including errors, events and debug statements. This will help the developer in debugging the code when something goes wrong.

====Interpreting the Logs====
This is the second part of the project. We will be creating a GUI to interpret and make sense of all the log data. The GUI will display the events for each user. We will also give an option to filter the event listing based on date and events.

This is a rough sketch of what the page will look like:
[[File:sketch.png|frame]]
 
 
It will have a text field to specify the user ID, a drop down menu to select the event and two date picker fields to specify the begin and end dates for the logs

E1632: Refactor delayed job.rb and scheduled task.rb

2016-11-05T02:53:45Z

Sjha4: /* UI Testing */

== '''Expertiza''' ==

[https://expertiza.ncsu.edu/ Expertiza] is an open source type of project that has been undertaken by the National Science Foundation. Various articles, codes in multiple languages and links can be submitted using the platform. It is popularly used by students studying at NC State to submit assignments, review works and get feedback. It allows users to switch between multiple environments if an user is not satisfied with a particular environment.

== '''Installation and Contribution''' ==

The setup development can be done using OSX, Linux or Docker. While using the OSX method and Linux method (RHEL), shell access and root access is a prerequisite. Docker is another method to install Wikipedia. It is cross Operating System (OS) compatible. Docker pull is needed to pull the docker image. Docker run is then used on port number 3000.
Expertiza allows user to contribute to their project. The expertiza project needs to be forked and cloned to create a local directory. Changes can be pushed and committed to a new branch. Finally the code is reviewed and changes are possibly made after a pull request.

== '''Problem Statement''' ==

The project is related to the class scheduled_class. The associated MVC framework relate to sending out reminder emails around the deadline of a task. The project objective includes-
*Removing duplicate code that is common in scheduled_task.rb and delayed_job.rb.
*Subclass Deadline_Type in the perform method.
*Refactoring mail_signed_up_users to multiple named methods and modifying it in a more elegant manner.
*Checks to the new refactored code.

----

'''Current Implementation'''
A task queue is implemented in expertiza for all the emails that need to be sent to the users. Delayed_job is used to send this task when the task is out of the queue. Scheduled_task provides information to the admin about the queue present at any given time. Scheduled_task uses assignment_id, deadline_type and due at to provide information for the admin. Current implementations include-
*Using the perform method linked to other methods mailing can be done for metareviewers, emails can be fetched and reminders can be sent to team members and mails can be sent to all signed up users.
*Implementation can be used for various types of deadlines. Deadline for team formation, sign-up and dropping outstanding reviews are also implemented.

----

'''Drawbacks and Solutions'''

'''Problem 1:''' Perform is too big a method and is implemented in a complicated manner.

'''Solution:''' Deadline_type is made a superclass with metareview, review, submission, drop_topic, sign_up, team_formation,drop_one_member_topic, drop_outstanding_reviews as the subclasses. The subclasses have a method email_list which contains the functionality. Thus, inheritance replaces the case structure.

'''Problem 2:''' mail_signed_up_users is a long method and contains duplicate code in its branches.

'''Solution:''' The mail_signed_up users can be split to two different methods- mail_sign_up_topics_user and and mail_non_sign_up_topics_user.The functionality of the first one is also used by the drop_topic subclass and the submission subclass uses both- the mail_sign_up_topics_user and mail_non_sign_up_topics_user.

----

== '''Code Modification''' ==

== Several new models have been added. All the deadline_type subclasses have been added as new models. ==
One of them looks like:

class Review < DeadlineType
def email_list(assignment_id)
emails = []
reviewer_tuples = ResponseMap.where(['reviewed_object_id = ? AND type = "ReviewResponseMap"', assignment_id])
for reviewer in reviewer_tuples
participant = Participant.where(['parent_id = ? AND id = ?', assignment_id, reviewer.reviewer_id])
uid = participant.first.user_id
user = User.find(uid)
emails << user.email
end
emails
end
end

== Changes to the mail_signed_up_user ==

This includes the splitting of the method to multiple methods to make it more elegant

'''Earlier Code:'''

def mail_signed_up_users
emails = []
assignment = Assignment.find(self.assignment_id)
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
# If there are sign_up topics for an assignement then send a mail toonly signed_up_teams else send a mail to all participants
if (sign_up_topics.nil? || sign_up_topics.count == 0)
if assignment.team_assignment?
teamMails = getTeamMembersMail
for mail in teamMails
emails << mail
email_reminder(emails, self.deadline_type)
end
else
mail_assignment_participants
end
else
for topic in sign_up_topics
signedUpTeams = SignedUpTeam.where(['topic_id = ?', topic.id])
unless assignment.team_assignment?
for signedUser in signedUpTeams
uid = signedUser.team_id
user = User.find(uid)
emails << user.email
end
else
for signedUser in signedUpTeams
teamid = signedUser.team_id
team_members = TeamsUser.where(team_id: teamid)
for team_member in team_members
user = User.find(team_member.user_id)
emails << user.email
end
end
end
end
email_reminder(emails, self.deadline_type) if emails.size > 0
end
end

'''Modified Code:'''

def mail_signed_up_users
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
# If there are sign_up topics for an assignement then send a mail toonly signed_up_teams else send a mail to all participants
if (sign_up_topics.nil? || sign_up_topics.count == 0)
emails = mail_non_sign_up_topic_users
else
emails = mail_sign_up_topic_users
end
emails
end

== The perform method has been modified ==
The perform method has been modified to a large extent as it now uses Single Table Inheritance (STI)[http://api.rubyonrails.org/classes/ActiveRecord/Inheritance.html] instead of if-else cases statements.

'''Earlier Code:'''

def perform
assignment = Assignment.find(self.assignment_id)
if !assignment.nil? && !assignment.id.nil?
if (self.deadline_type == "metareview")
mail_metareviewers
if assignment.team_assignment?
teamMails = getTeamMembersMail
email_reminder(teamMails, "teammate review")
end
end
if (self.deadline_type == "review")
mail_reviewers # to all reviewers
end
if (self.deadline_type == "submission")
mail_signed_up_users # to all signed up users
end
if (self.deadline_type == "drop_topic")
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
if (!sign_up_topics.nil? && sign_up_topics.count != 0)
mail_signed_up_users # reminder to signed_up users of the assignment
end
end
if (self.deadline_type == "signup")
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
if (!sign_up_topics.nil? && sign_up_topics.count != 0)
mail_assignment_participants # reminder to all participants
end
end
if (self.deadline_type == "team_formation")
assignment = Assignment.find(self.assignment_id)
if (assignment.team_assignment?)
emails = get_one_member_team
email_reminder(emails, self.deadline_type)
end
end
if (self.deadline_type == "drop_one_member_topics")
assignment = Assignment.find(self.assignment_id)
drop_one_member_topics if (assignment.team_assignment?)
end
if (self.deadline_type == "drop_outstanding_reviews")
drop_outstanding_reviews
end
end
end

'''Modified Code:'''

def perform
assignment = Assignment.find(self.assignment_id)
emails = []
if !assignment.nil? && !assignment.id.nil?
deadlineTypeClass = self.deadline_type.split("_").map { |n| n.capitalize}.join("").to_s
deadlineObj = Object.const_get(deadlineTypeClass).new
emails = deadlineObj.email_list(self.assignment_id)
email_reminder(emails, self.deadline_type) if emails.size > 0
end
end

== '''Testing''' ==

The scheduled_task_spec.rb is the test class for the above changes.All the test cases pass for scheduled_task_spec.rb following our changes.[https://travis-ci.org/expertiza/expertiza/builds/172184541]

== ''' UI Testing''' ==

Installation for Reviewers

Because asynchronous events require a daemon running in the background and the new Delayed::Job class for Rails 4 has additional fields, the following steps are recommended.

1. Install Expertiza and execute 'bundle install'

2. Create database and perform data migration using 'rake db:migrate'

3. Execute 'rails generate delayed_job:active_record' at the prompt. This will create a delalyed_job file in /bin directory.

4. Execute 'rails generate delayed:upgrade' if delayed_job has been created before.

5. Enter your smtp server account settings in config/environments/production.rb file. You may find an example in config/environments/developments.rb file.

6. Start the rails server by entering

rails server

5. Start the delayed_job server by executing

RAILS_ENV=production bin/delayed_job start

Please watch the video : [https://www.youtube.com/watch?v=d96A_9j2rng Here] to see how to test the use cases of the functionality that we have refactored.

E1632: Refactor delayed job.rb and scheduled task.rb

2016-11-05T02:53:13Z

Sjha4: /* UI Testing */

== '''Expertiza''' ==

[https://expertiza.ncsu.edu/ Expertiza] is an open source type of project that has been undertaken by the National Science Foundation. Various articles, codes in multiple languages and links can be submitted using the platform. It is popularly used by students studying at NC State to submit assignments, review works and get feedback. It allows users to switch between multiple environments if an user is not satisfied with a particular environment.

== '''Installation and Contribution''' ==

The setup development can be done using OSX, Linux or Docker. While using the OSX method and Linux method (RHEL), shell access and root access is a prerequisite. Docker is another method to install Wikipedia. It is cross Operating System (OS) compatible. Docker pull is needed to pull the docker image. Docker run is then used on port number 3000.
Expertiza allows user to contribute to their project. The expertiza project needs to be forked and cloned to create a local directory. Changes can be pushed and committed to a new branch. Finally the code is reviewed and changes are possibly made after a pull request.

== '''Problem Statement''' ==

The project is related to the class scheduled_class. The associated MVC framework relate to sending out reminder emails around the deadline of a task. The project objective includes-
*Removing duplicate code that is common in scheduled_task.rb and delayed_job.rb.
*Subclass Deadline_Type in the perform method.
*Refactoring mail_signed_up_users to multiple named methods and modifying it in a more elegant manner.
*Checks to the new refactored code.

----

'''Current Implementation'''
A task queue is implemented in expertiza for all the emails that need to be sent to the users. Delayed_job is used to send this task when the task is out of the queue. Scheduled_task provides information to the admin about the queue present at any given time. Scheduled_task uses assignment_id, deadline_type and due at to provide information for the admin. Current implementations include-
*Using the perform method linked to other methods mailing can be done for metareviewers, emails can be fetched and reminders can be sent to team members and mails can be sent to all signed up users.
*Implementation can be used for various types of deadlines. Deadline for team formation, sign-up and dropping outstanding reviews are also implemented.

----

'''Drawbacks and Solutions'''

'''Problem 1:''' Perform is too big a method and is implemented in a complicated manner.

'''Solution:''' Deadline_type is made a superclass with metareview, review, submission, drop_topic, sign_up, team_formation,drop_one_member_topic, drop_outstanding_reviews as the subclasses. The subclasses have a method email_list which contains the functionality. Thus, inheritance replaces the case structure.

'''Problem 2:''' mail_signed_up_users is a long method and contains duplicate code in its branches.

'''Solution:''' The mail_signed_up users can be split to two different methods- mail_sign_up_topics_user and and mail_non_sign_up_topics_user.The functionality of the first one is also used by the drop_topic subclass and the submission subclass uses both- the mail_sign_up_topics_user and mail_non_sign_up_topics_user.

----

== '''Code Modification''' ==

== Several new models have been added. All the deadline_type subclasses have been added as new models. ==
One of them looks like:

class Review < DeadlineType
def email_list(assignment_id)
emails = []
reviewer_tuples = ResponseMap.where(['reviewed_object_id = ? AND type = "ReviewResponseMap"', assignment_id])
for reviewer in reviewer_tuples
participant = Participant.where(['parent_id = ? AND id = ?', assignment_id, reviewer.reviewer_id])
uid = participant.first.user_id
user = User.find(uid)
emails << user.email
end
emails
end
end

== Changes to the mail_signed_up_user ==

This includes the splitting of the method to multiple methods to make it more elegant

'''Earlier Code:'''

def mail_signed_up_users
emails = []
assignment = Assignment.find(self.assignment_id)
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
# If there are sign_up topics for an assignement then send a mail toonly signed_up_teams else send a mail to all participants
if (sign_up_topics.nil? || sign_up_topics.count == 0)
if assignment.team_assignment?
teamMails = getTeamMembersMail
for mail in teamMails
emails << mail
email_reminder(emails, self.deadline_type)
end
else
mail_assignment_participants
end
else
for topic in sign_up_topics
signedUpTeams = SignedUpTeam.where(['topic_id = ?', topic.id])
unless assignment.team_assignment?
for signedUser in signedUpTeams
uid = signedUser.team_id
user = User.find(uid)
emails << user.email
end
else
for signedUser in signedUpTeams
teamid = signedUser.team_id
team_members = TeamsUser.where(team_id: teamid)
for team_member in team_members
user = User.find(team_member.user_id)
emails << user.email
end
end
end
end
email_reminder(emails, self.deadline_type) if emails.size > 0
end
end

'''Modified Code:'''

def mail_signed_up_users
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
# If there are sign_up topics for an assignement then send a mail toonly signed_up_teams else send a mail to all participants
if (sign_up_topics.nil? || sign_up_topics.count == 0)
emails = mail_non_sign_up_topic_users
else
emails = mail_sign_up_topic_users
end
emails
end

== The perform method has been modified ==
The perform method has been modified to a large extent as it now uses Single Table Inheritance (STI)[http://api.rubyonrails.org/classes/ActiveRecord/Inheritance.html] instead of if-else cases statements.

'''Earlier Code:'''

def perform
assignment = Assignment.find(self.assignment_id)
if !assignment.nil? && !assignment.id.nil?
if (self.deadline_type == "metareview")
mail_metareviewers
if assignment.team_assignment?
teamMails = getTeamMembersMail
email_reminder(teamMails, "teammate review")
end
end
if (self.deadline_type == "review")
mail_reviewers # to all reviewers
end
if (self.deadline_type == "submission")
mail_signed_up_users # to all signed up users
end
if (self.deadline_type == "drop_topic")
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
if (!sign_up_topics.nil? && sign_up_topics.count != 0)
mail_signed_up_users # reminder to signed_up users of the assignment
end
end
if (self.deadline_type == "signup")
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
if (!sign_up_topics.nil? && sign_up_topics.count != 0)
mail_assignment_participants # reminder to all participants
end
end
if (self.deadline_type == "team_formation")
assignment = Assignment.find(self.assignment_id)
if (assignment.team_assignment?)
emails = get_one_member_team
email_reminder(emails, self.deadline_type)
end
end
if (self.deadline_type == "drop_one_member_topics")
assignment = Assignment.find(self.assignment_id)
drop_one_member_topics if (assignment.team_assignment?)
end
if (self.deadline_type == "drop_outstanding_reviews")
drop_outstanding_reviews
end
end
end

'''Modified Code:'''

def perform
assignment = Assignment.find(self.assignment_id)
emails = []
if !assignment.nil? && !assignment.id.nil?
deadlineTypeClass = self.deadline_type.split("_").map { |n| n.capitalize}.join("").to_s
deadlineObj = Object.const_get(deadlineTypeClass).new
emails = deadlineObj.email_list(self.assignment_id)
email_reminder(emails, self.deadline_type) if emails.size > 0
end
end

== '''Testing''' ==

The scheduled_task_spec.rb is the test class for the above changes.All the test cases pass for scheduled_task_spec.rb following our changes.[https://travis-ci.org/expertiza/expertiza/builds/172184541]

== ''' UI Testing''' ==

Installation for Reviewers

Because asynchronous events require a daemon running in the background and the new Delayed::Job class for Rails 4 has additional fields, the following steps are recommended.

1. Install Expertiza and execute 'bundle install'

2. Create database and perform data migration using 'rake db:migrate'

3. Execute 'rails generate delayed_job:active_record' at the prompt. This will create a delalyed_job file in /bin directory.

4. Execute 'rails generate delayed:upgrade' if delayed_job has been created before.

5. Enter your smtp server account settings in config/environments/production.rb file. You may find an example in config/environments/developments.rb file.

6. Start the rails server by entering

rails server

5. Start the delayed_job server by executing

RAILS_ENV=production bin/delayed_job start

Please watch the video : Here[https://www.youtube.com/watch?v=d96A_9j2rng] to see how to test the use cases of the functionality that we have refactored.

E1632: Refactor delayed job.rb and scheduled task.rb

2016-11-04T23:23:07Z

Sjha4: /* UI Testing */

== '''Expertiza''' ==

[https://expertiza.ncsu.edu/ Expertiza] is an open source type of project that has been undertaken by the National Science Foundation. Various articles, codes in multiple languages and links can be submitted using the platform. It is popularly used by students studying at NC State to submit assignments, review works and get feedback. It allows users to switch between multiple environments if an user is not satisfied with a particular environment.

== '''Installation and Contribution''' ==

The setup development can be done using OSX, Linux or Docker. While using the OSX method and Linux method (RHEL), shell access and root access is a prerequisite. Docker is another method to install Wikipedia. It is cross Operating System (OS) compatible. Docker pull is needed to pull the docker image. Docker run is then used on port number 3000.
Expertiza allows user to contribute to their project. The expertiza project needs to be forked and cloned to create a local directory. Changes can be pushed and committed to a new branch. Finally the code is reviewed and changes are possibly made after a pull request.

== '''Problem Statement''' ==

The project is related to the class scheduled_class. The associated MVC framework relate to sending out reminder emails around the deadline of a task. The project objective includes-
*Removing duplicate code that is common in scheduled_task.rb and delayed_job.rb.
*Subclass Deadline_Type in the perform method.
*Refactoring mail_signed_up_users to multiple named methods and modifying it in a more elegant manner.
*Checks to the new refactored code.

----

'''Current Implementation'''
A task queue is implemented in expertiza for all the emails that need to be sent to the users. Delayed_job is used to send this task when the task is out of the queue. Scheduled_task provides information to the admin about the queue present at any given time. Scheduled_task uses assignment_id, deadline_type and due at to provide information for the admin. Current implementations include-
*Using the perform method linked to other methods mailing can be done for metareviewers, emails can be fetched and reminders can be sent to team members and mails can be sent to all signed up users.
*Implementation can be used for various types of deadlines. Deadline for team formation, sign-up and dropping outstanding reviews are also implemented.

----

'''Drawbacks and Solutions'''

'''Problem 1:''' Perform is too big a method and is implemented in a complicated manner.

'''Solution:''' Deadline_type is made a superclass with metareview, review, submission, drop_topic, sign_up, team_formation,drop_one_member_topic, drop_outstanding_reviews as the subclasses. The subclasses have a method email_list which contains the functionality. Thus, inheritance replaces the case structure.

'''Problem 2:''' mail_signed_up_users is a long method and contains duplicate code in its branches.

'''Solution:''' The mail_signed_up users can be split to two different methods- mail_sign_up_topics_user and and mail_non_sign_up_topics_user.The functionality of the first one is also used by the drop_topic subclass and the submission subclass uses both- the mail_sign_up_topics_user and mail_non_sign_up_topics_user.

----

== '''Code Modification''' ==

== Several new models have been added. All the deadline_type subclasses have been added as new models. ==
One of them looks like:

class Review < DeadlineType
def email_list(assignment_id)
emails = []
reviewer_tuples = ResponseMap.where(['reviewed_object_id = ? AND type = "ReviewResponseMap"', assignment_id])
for reviewer in reviewer_tuples
participant = Participant.where(['parent_id = ? AND id = ?', assignment_id, reviewer.reviewer_id])
uid = participant.first.user_id
user = User.find(uid)
emails << user.email
end
emails
end
end

== Changes to the mail_signed_up_user ==

This includes the splitting of the method to multiple methods to make it more elegant

'''Earlier Code:'''

def mail_signed_up_users
emails = []
assignment = Assignment.find(self.assignment_id)
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
# If there are sign_up topics for an assignement then send a mail toonly signed_up_teams else send a mail to all participants
if (sign_up_topics.nil? || sign_up_topics.count == 0)
if assignment.team_assignment?
teamMails = getTeamMembersMail
for mail in teamMails
emails << mail
email_reminder(emails, self.deadline_type)
end
else
mail_assignment_participants
end
else
for topic in sign_up_topics
signedUpTeams = SignedUpTeam.where(['topic_id = ?', topic.id])
unless assignment.team_assignment?
for signedUser in signedUpTeams
uid = signedUser.team_id
user = User.find(uid)
emails << user.email
end
else
for signedUser in signedUpTeams
teamid = signedUser.team_id
team_members = TeamsUser.where(team_id: teamid)
for team_member in team_members
user = User.find(team_member.user_id)
emails << user.email
end
end
end
end
email_reminder(emails, self.deadline_type) if emails.size > 0
end
end

'''Modified Code:'''

def mail_signed_up_users
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
# If there are sign_up topics for an assignement then send a mail toonly signed_up_teams else send a mail to all participants
if (sign_up_topics.nil? || sign_up_topics.count == 0)
emails = mail_non_sign_up_topic_users
else
emails = mail_sign_up_topic_users
end
emails
end

== The perform method has been modified ==
The perform method has been modified to a large extent as it now uses Single Table Inheritance (STI)[http://api.rubyonrails.org/classes/ActiveRecord/Inheritance.html] instead of if-else cases statements.

'''Earlier Code:'''

def perform
assignment = Assignment.find(self.assignment_id)
if !assignment.nil? && !assignment.id.nil?
if (self.deadline_type == "metareview")
mail_metareviewers
if assignment.team_assignment?
teamMails = getTeamMembersMail
email_reminder(teamMails, "teammate review")
end
end
if (self.deadline_type == "review")
mail_reviewers # to all reviewers
end
if (self.deadline_type == "submission")
mail_signed_up_users # to all signed up users
end
if (self.deadline_type == "drop_topic")
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
if (!sign_up_topics.nil? && sign_up_topics.count != 0)
mail_signed_up_users # reminder to signed_up users of the assignment
end
end
if (self.deadline_type == "signup")
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
if (!sign_up_topics.nil? && sign_up_topics.count != 0)
mail_assignment_participants # reminder to all participants
end
end
if (self.deadline_type == "team_formation")
assignment = Assignment.find(self.assignment_id)
if (assignment.team_assignment?)
emails = get_one_member_team
email_reminder(emails, self.deadline_type)
end
end
if (self.deadline_type == "drop_one_member_topics")
assignment = Assignment.find(self.assignment_id)
drop_one_member_topics if (assignment.team_assignment?)
end
if (self.deadline_type == "drop_outstanding_reviews")
drop_outstanding_reviews
end
end
end

'''Modified Code:'''

def perform
assignment = Assignment.find(self.assignment_id)
emails = []
if !assignment.nil? && !assignment.id.nil?
deadlineTypeClass = self.deadline_type.split("_").map { |n| n.capitalize}.join("").to_s
deadlineObj = Object.const_get(deadlineTypeClass).new
emails = deadlineObj.email_list(self.assignment_id)
email_reminder(emails, self.deadline_type) if emails.size > 0
end
end

== '''Testing''' ==

The scheduled_task_spec.rb is the test class for the above changes.All the test cases pass for scheduled_task_spec.rb following our changes.[https://travis-ci.org/expertiza/expertiza/builds/172184541]

== ''' UI Testing''' ==

Installation for Reviewers

Because asynchronous events require a daemon running in the background and the new Delayed::Job class for Rails 4 has additional fields, the following steps are recommended.

1. Install Expertiza and execute 'bundle install'

2. Create database and perform data migration using 'rake db:migrate'

3. Execute 'rails generate delayed_job:active_record' at the prompt. This will create a delalyed_job file in /bin directory.

4. Execute 'rails generate delayed:upgrade' if delayed_job has been created before.

5. Enter your smtp server account settings in config/environments/production.rb file. You may find an example in config/environments/developments.rb file.

6. Start the rails server by entering

rails server

5. Start the delayed_job server by executing

RAILS_ENV=production bin/delayed_job start

Please watch the video : Here[https://www.youtube.com/watch?v=d96A_9j2rng] to see how to test our use cases.

E1632: Refactor delayed job.rb and scheduled task.rb

2016-11-04T23:22:51Z

Sjha4: /* UI Testing */

E1632: Refactor delayed job.rb and scheduled task.rb

2016-11-04T23:20:18Z

Sjha4: /* Testing */

E1632: Refactor delayed job.rb and scheduled task.rb

2016-11-01T03:06:33Z

Sjha4: /* Testing */

E1632: Refactor delayed job.rb and scheduled task.rb

2016-11-01T03:05:53Z

Sjha4: /* Testing */

== '''Expertiza''' ==

[https://expertiza.ncsu.edu/ Expertiza] is an open source type of project that has been undertaken by the National Science Foundation. Various articles, codes in multiple languages and links can be submitted using the platform. It is popularly used by students studying at NC State to submit assignments, review works and get feedback. It allows users to switch between multiple environments if an user is not satisfied with a particular environment.

== '''Installation and Contribution''' ==

The setup development can be done using OSX, Linux or Docker. While using the OSX method and Linux method (RHEL), shell access and root access is a prerequisite. Docker is another method to install Wikipedia. It is cross Operating System (OS) compatible. Docker pull is needed to pull the docker image. Docker run is then used on port number 3000.
Expertiza allows user to contribute to their project. The expertiza project needs to be forked and cloned to create a local directory. Changes can be pushed and committed to a new branch. Finally the code is reviewed and changes are possibly made after a pull request.

== '''Problem Statement''' ==

The project is related to the class scheduled_class. The associated MVC framework relate to sending out reminder emails around the deadline of a task. The project objective includes-
*Removing duplicate code that is common in scheduled_task.rb and delayed_job.rb.
*Subclass Deadline_Type in the perform method.
*Refactoring mail_signed_up_users to multiple named methods and modifying it in a more elegant manner.
*Checks to the new refactored code.

----

'''Current Implementation'''
A task queue is implemented in expertiza for all the emails that need to be sent to the users. Delayed_job is used to send this task when the task is out of the queue. Scheduled_task provides information to the admin about the queue present at any given time. Scheduled_task uses assignment_id, deadline_type and due at to provide information for the admin. Current implementations include-
*Using the perform method linked to other methods mailing can be done for metareviewers, emails can be fetched and reminders can be sent to team members and mails can be sent to all signed up users.
*Implementation can be used for various types of deadlines. Deadline for team formation, sign-up and dropping outstanding reviews are also implemented.

----

'''Drawbacks and Solutions'''

'''Problem 1:''' Perform is too big a method and is implemented in a complicated manner.

'''Solution:''' Deadline_type is made a superclass with metareview, review, submission, drop_topic, sign_up, team_formation,drop_one_member_topic, drop_outstanding_reviews as the subclasses. The subclasses have a method email_list which contains the functionality. Thus, inheritance replaces the case structure.

'''Problem 2:''' mail_signed_up_users is a long method and contains duplicate code in its branches.

'''Solution:''' The mail_signed_up users can be split to two different methods- mail_sign_up_topics_user and and mail_non_sign_up_topics_user.The functionality of the first one is also used by the drop_topic subclass and the submission subclass uses both- the mail_sign_up_topics_user and mail_non_sign_up_topics_user.

----

== '''Code Modification''' ==

== Several new models have been added. All the deadline_type subclasses have been added as new models. ==
One of them looks like:

class Review < DeadlineType
def email_list(assignment_id)
emails = []
reviewer_tuples = ResponseMap.where(['reviewed_object_id = ? AND type = "ReviewResponseMap"', assignment_id])
for reviewer in reviewer_tuples
participant = Participant.where(['parent_id = ? AND id = ?', assignment_id, reviewer.reviewer_id])
uid = participant.first.user_id
user = User.find(uid)
emails << user.email
end
emails
end
end

== Changes to the mail_signed_up_user ==

This includes the splitting of the method to multiple methods to make it more elegant

'''Earlier Code:'''

def mail_signed_up_users
emails = []
assignment = Assignment.find(self.assignment_id)
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
# If there are sign_up topics for an assignement then send a mail toonly signed_up_teams else send a mail to all participants
if (sign_up_topics.nil? || sign_up_topics.count == 0)
if assignment.team_assignment?
teamMails = getTeamMembersMail
for mail in teamMails
emails << mail
email_reminder(emails, self.deadline_type)
end
else
mail_assignment_participants
end
else
for topic in sign_up_topics
signedUpTeams = SignedUpTeam.where(['topic_id = ?', topic.id])
unless assignment.team_assignment?
for signedUser in signedUpTeams
uid = signedUser.team_id
user = User.find(uid)
emails << user.email
end
else
for signedUser in signedUpTeams
teamid = signedUser.team_id
team_members = TeamsUser.where(team_id: teamid)
for team_member in team_members
user = User.find(team_member.user_id)
emails << user.email
end
end
end
end
email_reminder(emails, self.deadline_type) if emails.size > 0
end
end

'''Modified Code:'''

def mail_signed_up_users
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
# If there are sign_up topics for an assignement then send a mail toonly signed_up_teams else send a mail to all participants
if (sign_up_topics.nil? || sign_up_topics.count == 0)
emails = mail_non_sign_up_topic_users
else
emails = mail_sign_up_topic_users
end
emails
end

== The perform method has been modified ==
The perform method has been modified to a large extent as it now uses Single Table Inheritance (STI)[http://api.rubyonrails.org/classes/ActiveRecord/Inheritance.html] instead of if-else cases statements.

'''Earlier Code:'''

def perform
assignment = Assignment.find(self.assignment_id)
if !assignment.nil? && !assignment.id.nil?
if (self.deadline_type == "metareview")
mail_metareviewers
if assignment.team_assignment?
teamMails = getTeamMembersMail
email_reminder(teamMails, "teammate review")
end
end
if (self.deadline_type == "review")
mail_reviewers # to all reviewers
end
if (self.deadline_type == "submission")
mail_signed_up_users # to all signed up users
end
if (self.deadline_type == "drop_topic")
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
if (!sign_up_topics.nil? && sign_up_topics.count != 0)
mail_signed_up_users # reminder to signed_up users of the assignment
end
end
if (self.deadline_type == "signup")
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
if (!sign_up_topics.nil? && sign_up_topics.count != 0)
mail_assignment_participants # reminder to all participants
end
end
if (self.deadline_type == "team_formation")
assignment = Assignment.find(self.assignment_id)
if (assignment.team_assignment?)
emails = get_one_member_team
email_reminder(emails, self.deadline_type)
end
end
if (self.deadline_type == "drop_one_member_topics")
assignment = Assignment.find(self.assignment_id)
drop_one_member_topics if (assignment.team_assignment?)
end
if (self.deadline_type == "drop_outstanding_reviews")
drop_outstanding_reviews
end
end
end

'''Modified Code:'''

def perform
assignment = Assignment.find(self.assignment_id)
emails = []
if !assignment.nil? && !assignment.id.nil?
deadlineTypeClass = self.deadline_type.split("_").map { |n| n.capitalize}.join("").to_s
deadlineObj = Object.const_get(deadlineTypeClass).new
emails = deadlineObj.email_list(self.assignment_id)
email_reminder(emails, self.deadline_type) if emails.size > 0
end
end

== '''Testing''' ==

The scheduled_task_spec.rb is the test class for the above changes.All the test cases pass for the test case.[https://travis-ci.org/expertiza/expertiza/builds/172184541]

E1632: Refactor delayed job.rb and scheduled task.rb

2016-11-01T03:04:53Z

Sjha4: /* The perform method has been modified */

E1632: Refactor delayed job.rb and scheduled task.rb

2016-11-01T03:03:58Z

Sjha4: /* Several new models have been added. All the deadline_type subclasses have been added as new models. */

== '''Expertiza''' ==

[https://expertiza.ncsu.edu/ Expertiza] is an open source type of project that has been undertaken by the National Science Foundation. Various articles, codes in multiple languages and links can be submitted using the platform. It is popularly used by students studying at NC State to submit assignments, review works and get feedback. It allows users to switch between multiple environments if an user is not satisfied with a particular environment.

== '''Installation and Contribution''' ==

The setup development can be done using OSX, Linux or Docker. While using the OSX method and Linux method (RHEL), shell access and root access is a prerequisite. Docker is another method to install Wikipedia. It is cross Operating System (OS) compatible. Docker pull is needed to pull the docker image. Docker run is then used on port number 3000.
Expertiza allows user to contribute to their project. The expertiza project needs to be forked and cloned to create a local directory. Changes can be pushed and committed to a new branch. Finally the code is reviewed and changes are possibly made after a pull request.

== '''Problem Statement''' ==

The project is related to the class scheduled_class. The associated MVC framework relate to sending out reminder emails around the deadline of a task. The project objective includes-
*Removing duplicate code that is common in scheduled_task.rb and delayed_job.rb.
*Subclass Deadline_Type in the perform method.
*Refactoring mail_signed_up_users to multiple named methods and modifying it in a more elegant manner.
*Checks to the new refactored code.

----

'''Current Implementation'''
A task queue is implemented in expertiza for all the emails that need to be sent to the users. Delayed_job is used to send this task when the task is out of the queue. Scheduled_task provides information to the admin about the queue present at any given time. Scheduled_task uses assignment_id, deadline_type and due at to provide information for the admin. Current implementations include-
*Using the perform method linked to other methods mailing can be done for metareviewers, emails can be fetched and reminders can be sent to team members and mails can be sent to all signed up users.
*Implementation can be used for various types of deadlines. Deadline for team formation, sign-up and dropping outstanding reviews are also implemented.

----

'''Drawbacks and Solutions'''

'''Problem 1:''' Perform is too big a method and is implemented in a complicated manner.

'''Solution:''' Deadline_type is made a superclass with metareview, review, submission, drop_topic, sign_up, team_formation,drop_one_member_topic, drop_outstanding_reviews as the subclasses. The subclasses have a method email_list which contains the functionality. Thus, inheritance replaces the case structure.

'''Problem 2:''' mail_signed_up_users is a long method and contains duplicate code in its branches.

'''Solution:''' The mail_signed_up users can be split to two different methods- mail_sign_up_topics_user and and mail_non_sign_up_topics_user.The functionality of the first one is also used by the drop_topic subclass and the submission subclass uses both- the mail_sign_up_topics_user and mail_non_sign_up_topics_user.

----

== '''Code Modification''' ==

== Several new models have been added. All the deadline_type subclasses have been added as new models. ==
One of them looks like:

class Review < DeadlineType
def email_list(assignment_id)
emails = []
reviewer_tuples = ResponseMap.where(['reviewed_object_id = ? AND type = "ReviewResponseMap"', assignment_id])
for reviewer in reviewer_tuples
participant = Participant.where(['parent_id = ? AND id = ?', assignment_id, reviewer.reviewer_id])
uid = participant.first.user_id
user = User.find(uid)
emails << user.email
end
emails
end
end

== Changes to the mail_signed_up_user ==

This includes the splitting of the method to multiple methods to make it more elegant

'''Earlier Code:'''

def mail_signed_up_users
emails = []
assignment = Assignment.find(self.assignment_id)
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
# If there are sign_up topics for an assignement then send a mail toonly signed_up_teams else send a mail to all participants
if (sign_up_topics.nil? || sign_up_topics.count == 0)
if assignment.team_assignment?
teamMails = getTeamMembersMail
for mail in teamMails
emails << mail
email_reminder(emails, self.deadline_type)
end
else
mail_assignment_participants
end
else
for topic in sign_up_topics
signedUpTeams = SignedUpTeam.where(['topic_id = ?', topic.id])
unless assignment.team_assignment?
for signedUser in signedUpTeams
uid = signedUser.team_id
user = User.find(uid)
emails << user.email
end
else
for signedUser in signedUpTeams
teamid = signedUser.team_id
team_members = TeamsUser.where(team_id: teamid)
for team_member in team_members
user = User.find(team_member.user_id)
emails << user.email
end
end
end
end
email_reminder(emails, self.deadline_type) if emails.size > 0
end
end

'''Modified Code:'''

def mail_signed_up_users
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
# If there are sign_up topics for an assignement then send a mail toonly signed_up_teams else send a mail to all participants
if (sign_up_topics.nil? || sign_up_topics.count == 0)
emails = mail_non_sign_up_topic_users
else
emails = mail_sign_up_topic_users
end
emails
end

== The perform method has been modified ==
The perform method has been modified to a large extent as it now uses Single Table Inheritance (STI)[http://api.rubyonrails.org/classes/ActiveRecord/Inheritance.html] instead of if-else cases statements.

'''Earlier Code:'''

def perform
assignment = Assignment.find(self.assignment_id)
if !assignment.nil? && !assignment.id.nil?
if (self.deadline_type == "metareview")
mail_metareviewers
if assignment.team_assignment?
teamMails = getTeamMembersMail
email_reminder(teamMails, "teammate review")
end
end
if (self.deadline_type == "review")
mail_reviewers # to all reviewers
end
if (self.deadline_type == "submission")
mail_signed_up_users # to all signed up users
end
if (self.deadline_type == "drop_topic")
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
if (!sign_up_topics.nil? && sign_up_topics.count != 0)
mail_signed_up_users # reminder to signed_up users of the assignment
end
end
if (self.deadline_type == "signup")
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
if (!sign_up_topics.nil? && sign_up_topics.count != 0)
mail_assignment_participants # reminder to all participants
end
end
if (self.deadline_type == "team_formation")
assignment = Assignment.find(self.assignment_id)
if (assignment.team_assignment?)
emails = get_one_member_team
email_reminder(emails, self.deadline_type)
end
end
if (self.deadline_type == "drop_one_member_topics")
assignment = Assignment.find(self.assignment_id)
drop_one_member_topics if (assignment.team_assignment?)
end
if (self.deadline_type == "drop_outstanding_reviews")
drop_outstanding_reviews
end
end
end

'''Modified Code:'''

def perform
assignment = Assignment.find(self.assignment_id)
emails = []
if !assignment.nil? && !assignment.id.nil?
deadlineObj = self.deadline_type.new
emails = deadlineObj.email_list
email_reminder(emails, self.deadline_type) if emails.size > 0
end
end

== '''Testing''' ==

The scheduled_task_spec.rb is the test class for the above changes.

E1632: Refactor delayed job.rb and scheduled task.rb

2016-11-01T03:03:09Z

Sjha4: /* Problem Statement */

== '''Expertiza''' ==

[https://expertiza.ncsu.edu/ Expertiza] is an open source type of project that has been undertaken by the National Science Foundation. Various articles, codes in multiple languages and links can be submitted using the platform. It is popularly used by students studying at NC State to submit assignments, review works and get feedback. It allows users to switch between multiple environments if an user is not satisfied with a particular environment.

== '''Installation and Contribution''' ==

The setup development can be done using OSX, Linux or Docker. While using the OSX method and Linux method (RHEL), shell access and root access is a prerequisite. Docker is another method to install Wikipedia. It is cross Operating System (OS) compatible. Docker pull is needed to pull the docker image. Docker run is then used on port number 3000.
Expertiza allows user to contribute to their project. The expertiza project needs to be forked and cloned to create a local directory. Changes can be pushed and committed to a new branch. Finally the code is reviewed and changes are possibly made after a pull request.

== '''Problem Statement''' ==

The project is related to the class scheduled_class. The associated MVC framework relate to sending out reminder emails around the deadline of a task. The project objective includes-
*Removing duplicate code that is common in scheduled_task.rb and delayed_job.rb.
*Subclass Deadline_Type in the perform method.
*Refactoring mail_signed_up_users to multiple named methods and modifying it in a more elegant manner.
*Checks to the new refactored code.

----

'''Current Implementation'''
A task queue is implemented in expertiza for all the emails that need to be sent to the users. Delayed_job is used to send this task when the task is out of the queue. Scheduled_task provides information to the admin about the queue present at any given time. Scheduled_task uses assignment_id, deadline_type and due at to provide information for the admin. Current implementations include-
*Using the perform method linked to other methods mailing can be done for metareviewers, emails can be fetched and reminders can be sent to team members and mails can be sent to all signed up users.
*Implementation can be used for various types of deadlines. Deadline for team formation, sign-up and dropping outstanding reviews are also implemented.

----

'''Drawbacks and Solutions'''

'''Problem 1:''' Perform is too big a method and is implemented in a complicated manner.

'''Solution:''' Deadline_type is made a superclass with metareview, review, submission, drop_topic, sign_up, team_formation,drop_one_member_topic, drop_outstanding_reviews as the subclasses. The subclasses have a method email_list which contains the functionality. Thus, inheritance replaces the case structure.

'''Problem 2:''' mail_signed_up_users is a long method and contains duplicate code in its branches.

'''Solution:''' The mail_signed_up users can be split to two different methods- mail_sign_up_topics_user and and mail_non_sign_up_topics_user.The functionality of the first one is also used by the drop_topic subclass and the submission subclass uses both- the mail_sign_up_topics_user and mail_non_sign_up_topics_user.

----

== '''Code Modification''' ==

== Several new models have been added. All the deadline_type subclasses have been added as new models. ==
One of them looks like:

class review < DeadlineType
def email_list(assignment_id)
emails = []
reviewer_tuples = ResponseMap.where(['reviewed_object_id = ? AND type = "ReviewResponseMap"', assignment_id])
for reviewer in reviewer_tuples
participant = Participant.where(['parent_id = ? AND id = ?', assignment_id, reviewer.reviewer_id])
uid = participant.first.user_id
user = User.find(uid)
emails << user.email
end
emails
end
end

== Changes to the mail_signed_up_user ==

This includes the splitting of the method to multiple methods to make it more elegant

'''Earlier Code:'''

def mail_signed_up_users
emails = []
assignment = Assignment.find(self.assignment_id)
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
# If there are sign_up topics for an assignement then send a mail toonly signed_up_teams else send a mail to all participants
if (sign_up_topics.nil? || sign_up_topics.count == 0)
if assignment.team_assignment?
teamMails = getTeamMembersMail
for mail in teamMails
emails << mail
email_reminder(emails, self.deadline_type)
end
else
mail_assignment_participants
end
else
for topic in sign_up_topics
signedUpTeams = SignedUpTeam.where(['topic_id = ?', topic.id])
unless assignment.team_assignment?
for signedUser in signedUpTeams
uid = signedUser.team_id
user = User.find(uid)
emails << user.email
end
else
for signedUser in signedUpTeams
teamid = signedUser.team_id
team_members = TeamsUser.where(team_id: teamid)
for team_member in team_members
user = User.find(team_member.user_id)
emails << user.email
end
end
end
end
email_reminder(emails, self.deadline_type) if emails.size > 0
end
end

'''Modified Code:'''

def mail_signed_up_users
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
# If there are sign_up topics for an assignement then send a mail toonly signed_up_teams else send a mail to all participants
if (sign_up_topics.nil? || sign_up_topics.count == 0)
emails = mail_non_sign_up_topic_users
else
emails = mail_sign_up_topic_users
end
emails
end

== The perform method has been modified ==
The perform method has been modified to a large extent as it now uses Single Table Inheritance (STI)[http://api.rubyonrails.org/classes/ActiveRecord/Inheritance.html] instead of if-else cases statements.

'''Earlier Code:'''

def perform
assignment = Assignment.find(self.assignment_id)
if !assignment.nil? && !assignment.id.nil?
if (self.deadline_type == "metareview")
mail_metareviewers
if assignment.team_assignment?
teamMails = getTeamMembersMail
email_reminder(teamMails, "teammate review")
end
end
if (self.deadline_type == "review")
mail_reviewers # to all reviewers
end
if (self.deadline_type == "submission")
mail_signed_up_users # to all signed up users
end
if (self.deadline_type == "drop_topic")
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
if (!sign_up_topics.nil? && sign_up_topics.count != 0)
mail_signed_up_users # reminder to signed_up users of the assignment
end
end
if (self.deadline_type == "signup")
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
if (!sign_up_topics.nil? && sign_up_topics.count != 0)
mail_assignment_participants # reminder to all participants
end
end
if (self.deadline_type == "team_formation")
assignment = Assignment.find(self.assignment_id)
if (assignment.team_assignment?)
emails = get_one_member_team
email_reminder(emails, self.deadline_type)
end
end
if (self.deadline_type == "drop_one_member_topics")
assignment = Assignment.find(self.assignment_id)
drop_one_member_topics if (assignment.team_assignment?)
end
if (self.deadline_type == "drop_outstanding_reviews")
drop_outstanding_reviews
end
end
end

'''Modified Code:'''

def perform
assignment = Assignment.find(self.assignment_id)
emails = []
if !assignment.nil? && !assignment.id.nil?
deadlineObj = self.deadline_type.new
emails = deadlineObj.email_list
email_reminder(emails, self.deadline_type) if emails.size > 0
end
end

== '''Testing''' ==

The scheduled_task_spec.rb is the test class for the above changes.

E1632: Refactor delayed mailer.rb and scheduled task.rb

2016-11-01T03:01:52Z

Sjha4: moved E1632: Refactor delayed mailer.rb and scheduled task.rb to E1632: Refactor delayed job.rb and scheduled task.rb

#REDIRECT [[E1632: Refactor delayed job.rb and scheduled task.rb]]

E1632: Refactor delayed job.rb and scheduled task.rb

2016-11-01T03:01:52Z

Sjha4: moved E1632: Refactor delayed mailer.rb and scheduled task.rb to E1632: Refactor delayed job.rb and scheduled task.rb

== '''Expertiza''' ==

[https://expertiza.ncsu.edu/ Expertiza] is an open source type of project that has been undertaken by the National Science Foundation. Various articles, codes in multiple languages and links can be submitted using the platform. It is popularly used by students studying at NC State to submit assignments, review works and get feedback. It allows users to switch between multiple environments if an user is not satisfied with a particular environment.

== '''Installation and Contribution''' ==

The setup development can be done using OSX, Linux or Docker. While using the OSX method and Linux method (RHEL), shell access and root access is a prerequisite. Docker is another method to install Wikipedia. It is cross Operating System (OS) compatible. Docker pull is needed to pull the docker image. Docker run is then used on port number 3000.
Expertiza allows user to contribute to their project. The expertiza project needs to be forked and cloned to create a local directory. Changes can be pushed and committed to a new branch. Finally the code is reviewed and changes are possibly made after a pull request.

== '''Problem Statement''' ==

The project is related to the class scheduled_class. The associated MVC framework relate to sending out reminder emails around the deadline of a task. The project objective includes-
*Removing duplicate code that is common in scheduled_task.rb and delayed_mailer.rb.
*Subclass Deadline_Type in the perform method.
*Refactoring mail_signed_up_users to multiple named methods and modifying it in a more elegant manner.
*Checks to the new refactored code.

----

'''Current Implementation'''
A task queue is implemented in expertiza for all the emails that need to be sent to the users. Delayed_mailer is used to send this task when the task is out of the queue. Scheduled_task provides information to the admin about the queue present at any given time. Scheduled_task uses assignment_id, deadline_type and due at to provide information for the admin. Current implementations include-
*Using the perform method linked to other methods mailing can be done for metareviewers, emails can be fetched and reminders can be sent to team members and mails can be sent to all signed up users.
*Implementation can be used for various types of deadlines. Deadline for team formation, sign-up and dropping outstanding reviews are also implemented.

----

'''Drawbacks and Solutions'''

'''Problem 1:''' Perform is too big a method and is implemented in a complicated manner.

'''Solution:''' Deadline_type is made a superclass with metareview, review, submission, drop_topic, sign_up, team_formation,drop_one_member_topic, drop_outstanding_reviews as the subclasses. The subclasses have a method email_list which contains the functionality. Thus, inheritance replaces the case structure.

'''Problem 2:''' mail_signed_up_users is a long method and contains duplicate code in its branches.

'''Solution:''' The mail_signed_up users can be split to two different methods- mail_sign_up_topics_user and and mail_non_sign_up_topics_user.The functionality of the first one is also used by the drop_topic subclass and the submission subclass uses both- the mail_sign_up_topics_user and mail_non_sign_up_topics_user.

----

== '''Code Modification''' ==

== Several new models have been added. All the deadline_type subclasses have been added as new models. ==
One of them looks like:

class review < DeadlineType
def email_list(assignment_id)
emails = []
reviewer_tuples = ResponseMap.where(['reviewed_object_id = ? AND type = "ReviewResponseMap"', assignment_id])
for reviewer in reviewer_tuples
participant = Participant.where(['parent_id = ? AND id = ?', assignment_id, reviewer.reviewer_id])
uid = participant.first.user_id
user = User.find(uid)
emails << user.email
end
emails
end
end

== Changes to the mail_signed_up_user ==

This includes the splitting of the method to multiple methods to make it more elegant

'''Earlier Code:'''

def mail_signed_up_users
emails = []
assignment = Assignment.find(self.assignment_id)
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
# If there are sign_up topics for an assignement then send a mail toonly signed_up_teams else send a mail to all participants
if (sign_up_topics.nil? || sign_up_topics.count == 0)
if assignment.team_assignment?
teamMails = getTeamMembersMail
for mail in teamMails
emails << mail
email_reminder(emails, self.deadline_type)
end
else
mail_assignment_participants
end
else
for topic in sign_up_topics
signedUpTeams = SignedUpTeam.where(['topic_id = ?', topic.id])
unless assignment.team_assignment?
for signedUser in signedUpTeams
uid = signedUser.team_id
user = User.find(uid)
emails << user.email
end
else
for signedUser in signedUpTeams
teamid = signedUser.team_id
team_members = TeamsUser.where(team_id: teamid)
for team_member in team_members
user = User.find(team_member.user_id)
emails << user.email
end
end
end
end
email_reminder(emails, self.deadline_type) if emails.size > 0
end
end

'''Modified Code:'''

def mail_signed_up_users
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
# If there are sign_up topics for an assignement then send a mail toonly signed_up_teams else send a mail to all participants
if (sign_up_topics.nil? || sign_up_topics.count == 0)
emails = mail_non_sign_up_topic_users
else
emails = mail_sign_up_topic_users
end
emails
end

== The perform method has been modified ==
The perform method has been modified to a large extent as it now uses Single Table Inheritance (STI)[http://api.rubyonrails.org/classes/ActiveRecord/Inheritance.html] instead of if-else cases statements.

'''Earlier Code:'''

def perform
assignment = Assignment.find(self.assignment_id)
if !assignment.nil? && !assignment.id.nil?
if (self.deadline_type == "metareview")
mail_metareviewers
if assignment.team_assignment?
teamMails = getTeamMembersMail
email_reminder(teamMails, "teammate review")
end
end
if (self.deadline_type == "review")
mail_reviewers # to all reviewers
end
if (self.deadline_type == "submission")
mail_signed_up_users # to all signed up users
end
if (self.deadline_type == "drop_topic")
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
if (!sign_up_topics.nil? && sign_up_topics.count != 0)
mail_signed_up_users # reminder to signed_up users of the assignment
end
end
if (self.deadline_type == "signup")
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
if (!sign_up_topics.nil? && sign_up_topics.count != 0)
mail_assignment_participants # reminder to all participants
end
end
if (self.deadline_type == "team_formation")
assignment = Assignment.find(self.assignment_id)
if (assignment.team_assignment?)
emails = get_one_member_team
email_reminder(emails, self.deadline_type)
end
end
if (self.deadline_type == "drop_one_member_topics")
assignment = Assignment.find(self.assignment_id)
drop_one_member_topics if (assignment.team_assignment?)
end
if (self.deadline_type == "drop_outstanding_reviews")
drop_outstanding_reviews
end
end
end

'''Modified Code:'''

def perform
assignment = Assignment.find(self.assignment_id)
emails = []
if !assignment.nil? && !assignment.id.nil?
deadlineObj = self.deadline_type.new
emails = deadlineObj.email_list
email_reminder(emails, self.deadline_type) if emails.size > 0
end
end

== '''Testing''' ==

The scheduled_task_spec.rb is the test class for the above changes.

E1632: Refactor delayed job.rb and scheduled task.rb

2016-10-29T03:41:02Z

Sjha4: /* Problem Statement */

== '''Expertiza''' ==

[https://expertiza.ncsu.edu/ Expertiza] is an open source type of project that has been undertaken by the National Science Foundation. Various articles, codes in multiple languages and links can be submitted using the platform. It is popularly used by students studying at NC State to submit assignments, review works and get feedback. It allows users to switch between multiple environments if an user is not satisfied with a particular environment.

== '''Installation and Contribution''' ==

The setup development can be done using OSX, Linux or Docker. While using the OSX method and Linux method (RHEL), shell access and root access is a prerequisite. Docker is another method to install Wikipedia. It is cross Operating System (OS) compatible. Docker pull is needed to pull the docker image. Docker run is then used on port number 3000.
Expertiza allows user to contribute to their project. The expertiza project needs to be forked and cloned to create a local directory. Changes can be pushed and committed to a new branch. Finally the code is reviewed and changes are possibly made after a pull request.

== '''Problem Statement''' ==

The project is related to the class scheduled_class. The associated MVC framework relate to sending out reminder emails around the deadline of a task. The project objective includes-
*Removing duplicate code that is common in scheduled_task.rb and delayed_mailer.rb.
*Subclass Deadline_Type in the perform method.
*Refactoring mail_signed_up_users to multiple named methods and modifying it in a more elegant manner.
*Checks to the new refactored code.

----

'''Current Implementation'''
A task queue is implemented in expertiza for all the emails that need to be sent to the users. Delayed_mailer is used to send this task when the task is out of the queue. Scheduled_task provides information to the admin about the queue present at any given time. Scheduled_task uses assignment_id, deadline_type and due at to provide information for the admin. Current implementations include-
*Using the perform method linked to other methods mailing can be done for metareviewers, emails can be fetched and reminders can be sent to team members and mails can be sent to all signed up users.
*Implementation can be used for various types of deadlines. Deadline for team formation, sign-up and dropping outstanding reviews are also implemented.

----

'''Drawbacks and Solutions'''

'''Problem 1:''' Perform is too big a method and is implemented in a complicated manner.

'''Solution:''' Deadline_type is made a superclass with metareview, review, submission, drop_topic, sign_up, team_formation,drop_one_member_topic, drop_outstanding_reviews as the subclasses. The subclasses have a method email_list which contains the functionality. Thus, inheritance replaces the case structure.

'''Problem 2:''' mail_signed_up_users is a long method and contains duplicate code in its branches.

'''Solution:''' The mail_signed_up users can be split to two different methods- mail_sign_up_topics_user and and mail_non_sign_up_topics_user.The functionality of the first one is also used by the drop_topic subclass and the submission subclass uses both- the mail_sign_up_topics_user and mail_non_sign_up_topics_user.

----

== '''Code Modification''' ==

== Several new models have been added. All the deadline_type subclasses have been added as new models. ==
One of them looks like:

class review < DeadlineType
def email_list(assignment_id)
emails = []
reviewer_tuples = ResponseMap.where(['reviewed_object_id = ? AND type = "ReviewResponseMap"', assignment_id])
for reviewer in reviewer_tuples
participant = Participant.where(['parent_id = ? AND id = ?', assignment_id, reviewer.reviewer_id])
uid = participant.first.user_id
user = User.find(uid)
emails << user.email
end
emails
end
end

== Changes to the mail_signed_up_user ==

This includes the splitting of the method to multiple methods to make it more elegant

'''Earlier Code:'''

def mail_signed_up_users
emails = []
assignment = Assignment.find(self.assignment_id)
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
# If there are sign_up topics for an assignement then send a mail toonly signed_up_teams else send a mail to all participants
if (sign_up_topics.nil? || sign_up_topics.count == 0)
if assignment.team_assignment?
teamMails = getTeamMembersMail
for mail in teamMails
emails << mail
email_reminder(emails, self.deadline_type)
end
else
mail_assignment_participants
end
else
for topic in sign_up_topics
signedUpTeams = SignedUpTeam.where(['topic_id = ?', topic.id])
unless assignment.team_assignment?
for signedUser in signedUpTeams
uid = signedUser.team_id
user = User.find(uid)
emails << user.email
end
else
for signedUser in signedUpTeams
teamid = signedUser.team_id
team_members = TeamsUser.where(team_id: teamid)
for team_member in team_members
user = User.find(team_member.user_id)
emails << user.email
end
end
end
end
email_reminder(emails, self.deadline_type) if emails.size > 0
end
end

'''Modified Code:'''

def mail_signed_up_users
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
# If there are sign_up topics for an assignement then send a mail toonly signed_up_teams else send a mail to all participants
if (sign_up_topics.nil? || sign_up_topics.count == 0)
emails = mail_non_sign_up_topic_users
else
emails = mail_sign_up_topic_users
end
emails
end

== The perform method has been modified ==
The perform method has been modified to a large extent as it now uses Single Table Inheritance (STI)[http://api.rubyonrails.org/classes/ActiveRecord/Inheritance.html] instead of if-else cases statements.

'''Earlier Code:'''

def perform
assignment = Assignment.find(self.assignment_id)
if !assignment.nil? && !assignment.id.nil?
if (self.deadline_type == "metareview")
mail_metareviewers
if assignment.team_assignment?
teamMails = getTeamMembersMail
email_reminder(teamMails, "teammate review")
end
end
if (self.deadline_type == "review")
mail_reviewers # to all reviewers
end
if (self.deadline_type == "submission")
mail_signed_up_users # to all signed up users
end
if (self.deadline_type == "drop_topic")
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
if (!sign_up_topics.nil? && sign_up_topics.count != 0)
mail_signed_up_users # reminder to signed_up users of the assignment
end
end
if (self.deadline_type == "signup")
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
if (!sign_up_topics.nil? && sign_up_topics.count != 0)
mail_assignment_participants # reminder to all participants
end
end
if (self.deadline_type == "team_formation")
assignment = Assignment.find(self.assignment_id)
if (assignment.team_assignment?)
emails = get_one_member_team
email_reminder(emails, self.deadline_type)
end
end
if (self.deadline_type == "drop_one_member_topics")
assignment = Assignment.find(self.assignment_id)
drop_one_member_topics if (assignment.team_assignment?)
end
if (self.deadline_type == "drop_outstanding_reviews")
drop_outstanding_reviews
end
end
end

'''Modified Code:'''

def perform
assignment = Assignment.find(self.assignment_id)
emails = []
if !assignment.nil? && !assignment.id.nil?
deadlineObj = self.deadline_type.new
emails = deadlineObj.email_list
email_reminder(emails, self.deadline_type) if emails.size > 0
end
end

== '''Testing''' ==

The scheduled_task_spec.rb is the test class for the above changes.

E1632: Refactor delayed job.rb and scheduled task.rb

2016-10-29T03:37:13Z

Sjha4: /* The perform method has been modified */

== '''Expertiza''' ==

[https://expertiza.ncsu.edu/ Expertiza] is an open source type of project that has been undertaken by the National Science Foundation. Various articles, codes in multiple languages and links can be submitted using the platform. It is popularly used by students studying at NC State to submit assignments, review works and get feedback. It allows users to switch between multiple environments if an user is not satisfied with a particular environment.

== '''Installation and Contribution''' ==

The setup development can be done using OSX, Linux or Docker. While using the OSX method and Linux method (RHEL), shell access and root access is a prerequisite. Docker is another method to install Wikipedia. It is cross Operating System (OS) compatible. Docker pull is needed to pull the docker image. Docker run is then used on port number 3000.
Expertiza allows user to contribute to their project. The expertiza project needs to be forked and cloned to create a local directory. Changes can be pushed and committed to a new branch. Finally the code is reviewed and changes are possibly made after a pull request.

== '''Problem Statement''' ==

The project is related to the class scheduled_class. The associated MVC framework relate to sending out reminder emails around the deadline of a task. The project objective includes-
*Removing duplicate code that is common in scheduled_task.rb and delayed_job.rb.
*Subclass Deadline_Type in the perform method.
*Refactoring mail_signed_up_users to multiple named methods and modifying it in a more elegant manner.
*Checks to the new refactored code.

----

'''Current Implementation'''
A task queue is implemented in expertiza for all the emails that need to be sent to the users. Delayed_mailer is used to send this task when the task is out of the queue. Scheduled_task provides information to the admin about the queue present at any given time. Scheduled_task uses assignment_id, deadline_type and due at to provide information for the admin. Current implementations include-
*Using the perform method linked to other methods mailing can be done for metareviewers, emails can be fetched and reminders can be sent to team members and mails can be sent to all signed up users.
*Implementation can be used for various types of deadlines. Deadline for team formation, sign-up and dropping outstanding reviews are also implemented.

----

'''Drawbacks and Solutions'''

'''Problem 1:''' Perform is too big a method and is implemented in a complicated manner.

'''Solution:''' Deadline_type is made a superclass with metareview, review, submission, drop_topic, sign_up, team_formation,drop_one_member_topic, drop_outstanding_reviews as the subclasses. The subclasses have a method email_list which contains the functionality. Thus, inheritance replaces the case structure.

'''Problem 2:''' mail_signed_up_users is a long method and contains duplicate code in its branches.

'''Solution:''' The mail_signed_up users can be split to two different methods- mail_sign_up_topics_user and and mail_non_sign_up_topics_user.The functionality of the first one is also used by the drop_topic subclass and the submission subclass uses both- the mail_sign_up_topics_user and mail_non_sign_up_topics_user.

----

== '''Code Modification''' ==

== Several new models have been added. All the deadline_type subclasses have been added as new models. ==
One of them looks like:

class review < DeadlineType
def email_list(assignment_id)
emails = []
reviewer_tuples = ResponseMap.where(['reviewed_object_id = ? AND type = "ReviewResponseMap"', assignment_id])
for reviewer in reviewer_tuples
participant = Participant.where(['parent_id = ? AND id = ?', assignment_id, reviewer.reviewer_id])
uid = participant.first.user_id
user = User.find(uid)
emails << user.email
end
emails
end
end

== Changes to the mail_signed_up_user ==

This includes the splitting of the method to multiple methods to make it more elegant

'''Earlier Code:'''

def mail_signed_up_users
emails = []
assignment = Assignment.find(self.assignment_id)
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
# If there are sign_up topics for an assignement then send a mail toonly signed_up_teams else send a mail to all participants
if (sign_up_topics.nil? || sign_up_topics.count == 0)
if assignment.team_assignment?
teamMails = getTeamMembersMail
for mail in teamMails
emails << mail
email_reminder(emails, self.deadline_type)
end
else
mail_assignment_participants
end
else
for topic in sign_up_topics
signedUpTeams = SignedUpTeam.where(['topic_id = ?', topic.id])
unless assignment.team_assignment?
for signedUser in signedUpTeams
uid = signedUser.team_id
user = User.find(uid)
emails << user.email
end
else
for signedUser in signedUpTeams
teamid = signedUser.team_id
team_members = TeamsUser.where(team_id: teamid)
for team_member in team_members
user = User.find(team_member.user_id)
emails << user.email
end
end
end
end
email_reminder(emails, self.deadline_type) if emails.size > 0
end
end

'''Modified Code:'''

def mail_signed_up_users
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
# If there are sign_up topics for an assignement then send a mail toonly signed_up_teams else send a mail to all participants
if (sign_up_topics.nil? || sign_up_topics.count == 0)
emails = mail_non_sign_up_topic_users
else
emails = mail_sign_up_topic_users
end
emails
end

== The perform method has been modified ==
The perform method has been modified to a large extent as it now uses Single Table Inheritance (STI)[http://api.rubyonrails.org/classes/ActiveRecord/Inheritance.html] instead of if-else cases statements.

'''Earlier Code:'''

def perform
assignment = Assignment.find(self.assignment_id)
if !assignment.nil? && !assignment.id.nil?
if (self.deadline_type == "metareview")
mail_metareviewers
if assignment.team_assignment?
teamMails = getTeamMembersMail
email_reminder(teamMails, "teammate review")
end
end
if (self.deadline_type == "review")
mail_reviewers # to all reviewers
end
if (self.deadline_type == "submission")
mail_signed_up_users # to all signed up users
end
if (self.deadline_type == "drop_topic")
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
if (!sign_up_topics.nil? && sign_up_topics.count != 0)
mail_signed_up_users # reminder to signed_up users of the assignment
end
end
if (self.deadline_type == "signup")
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
if (!sign_up_topics.nil? && sign_up_topics.count != 0)
mail_assignment_participants # reminder to all participants
end
end
if (self.deadline_type == "team_formation")
assignment = Assignment.find(self.assignment_id)
if (assignment.team_assignment?)
emails = get_one_member_team
email_reminder(emails, self.deadline_type)
end
end
if (self.deadline_type == "drop_one_member_topics")
assignment = Assignment.find(self.assignment_id)
drop_one_member_topics if (assignment.team_assignment?)
end
if (self.deadline_type == "drop_outstanding_reviews")
drop_outstanding_reviews
end
end
end

'''Modified Code:'''

def perform
assignment = Assignment.find(self.assignment_id)
emails = []
if !assignment.nil? && !assignment.id.nil?
deadlineObj = self.deadline_type.new
emails = deadlineObj.email_list
email_reminder(emails, self.deadline_type) if emails.size > 0
end
end

== '''Testing''' ==

The scheduled_task_spec.rb is the test class for the above changes.

E1632: Refactor delayed job.rb and scheduled task.rb

2016-10-29T03:34:35Z

Sjha4:

== '''Expertiza''' ==

[https://expertiza.ncsu.edu/ Expertiza] is an open source type of project that has been undertaken by the National Science Foundation. Various articles, codes in multiple languages and links can be submitted using the platform. It is popularly used by students studying at NC State to submit assignments, review works and get feedback. It allows users to switch between multiple environments if an user is not satisfied with a particular environment.

== '''Installation and Contribution''' ==

The setup development can be done using OSX, Linux or Docker. While using the OSX method and Linux method (RHEL), shell access and root access is a prerequisite. Docker is another method to install Wikipedia. It is cross Operating System (OS) compatible. Docker pull is needed to pull the docker image. Docker run is then used on port number 3000.
Expertiza allows user to contribute to their project. The expertiza project needs to be forked and cloned to create a local directory. Changes can be pushed and committed to a new branch. Finally the code is reviewed and changes are possibly made after a pull request.

== '''Problem Statement''' ==

The project is related to the class scheduled_class. The associated MVC framework relate to sending out reminder emails around the deadline of a task. The project objective includes-
*Removing duplicate code that is common in scheduled_task.rb and delayed_job.rb.
*Subclass Deadline_Type in the perform method.
*Refactoring mail_signed_up_users to multiple named methods and modifying it in a more elegant manner.
*Checks to the new refactored code.

----

'''Current Implementation'''
A task queue is implemented in expertiza for all the emails that need to be sent to the users. Delayed_mailer is used to send this task when the task is out of the queue. Scheduled_task provides information to the admin about the queue present at any given time. Scheduled_task uses assignment_id, deadline_type and due at to provide information for the admin. Current implementations include-
*Using the perform method linked to other methods mailing can be done for metareviewers, emails can be fetched and reminders can be sent to team members and mails can be sent to all signed up users.
*Implementation can be used for various types of deadlines. Deadline for team formation, sign-up and dropping outstanding reviews are also implemented.

----

'''Drawbacks and Solutions'''

'''Problem 1:''' Perform is too big a method and is implemented in a complicated manner.

'''Solution:''' Deadline_type is made a superclass with metareview, review, submission, drop_topic, sign_up, team_formation,drop_one_member_topic, drop_outstanding_reviews as the subclasses. The subclasses have a method email_list which contains the functionality. Thus, inheritance replaces the case structure.

'''Problem 2:''' mail_signed_up_users is a long method and contains duplicate code in its branches.

'''Solution:''' The mail_signed_up users can be split to two different methods- mail_sign_up_topics_user and and mail_non_sign_up_topics_user.The functionality of the first one is also used by the drop_topic subclass and the submission subclass uses both- the mail_sign_up_topics_user and mail_non_sign_up_topics_user.

----

== '''Code Modification''' ==

== Several new models have been added. All the deadline_type subclasses have been added as new models. ==
One of them looks like:

class review < DeadlineType
def email_list(assignment_id)
emails = []
reviewer_tuples = ResponseMap.where(['reviewed_object_id = ? AND type = "ReviewResponseMap"', assignment_id])
for reviewer in reviewer_tuples
participant = Participant.where(['parent_id = ? AND id = ?', assignment_id, reviewer.reviewer_id])
uid = participant.first.user_id
user = User.find(uid)
emails << user.email
end
emails
end
end

== Changes to the mail_signed_up_user ==

This includes the splitting of the method to multiple methods to make it more elegant

'''Earlier Code:'''

def mail_signed_up_users
emails = []
assignment = Assignment.find(self.assignment_id)
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
# If there are sign_up topics for an assignement then send a mail toonly signed_up_teams else send a mail to all participants
if (sign_up_topics.nil? || sign_up_topics.count == 0)
if assignment.team_assignment?
teamMails = getTeamMembersMail
for mail in teamMails
emails << mail
email_reminder(emails, self.deadline_type)
end
else
mail_assignment_participants
end
else
for topic in sign_up_topics
signedUpTeams = SignedUpTeam.where(['topic_id = ?', topic.id])
unless assignment.team_assignment?
for signedUser in signedUpTeams
uid = signedUser.team_id
user = User.find(uid)
emails << user.email
end
else
for signedUser in signedUpTeams
teamid = signedUser.team_id
team_members = TeamsUser.where(team_id: teamid)
for team_member in team_members
user = User.find(team_member.user_id)
emails << user.email
end
end
end
end
email_reminder(emails, self.deadline_type) if emails.size > 0
end
end

'''Modified Code:'''

def mail_signed_up_users
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
# If there are sign_up topics for an assignement then send a mail toonly signed_up_teams else send a mail to all participants
if (sign_up_topics.nil? || sign_up_topics.count == 0)
emails = mail_non_sign_up_topic_users
else
emails = mail_sign_up_topic_users
end
emails
end

== The perform method has been modified ==
The perform method has been modified to a large extent as it now uses Single Table Inheritance (STI) instead of if-else cases statements.

'''Earlier Code:'''

def perform
assignment = Assignment.find(self.assignment_id)
if !assignment.nil? && !assignment.id.nil?
if (self.deadline_type == "metareview")
mail_metareviewers
if assignment.team_assignment?
teamMails = getTeamMembersMail
email_reminder(teamMails, "teammate review")
end
end
if (self.deadline_type == "review")
mail_reviewers # to all reviewers
end
if (self.deadline_type == "submission")
mail_signed_up_users # to all signed up users
end
if (self.deadline_type == "drop_topic")
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
if (!sign_up_topics.nil? && sign_up_topics.count != 0)
mail_signed_up_users # reminder to signed_up users of the assignment
end
end
if (self.deadline_type == "signup")
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
if (!sign_up_topics.nil? && sign_up_topics.count != 0)
mail_assignment_participants # reminder to all participants
end
end
if (self.deadline_type == "team_formation")
assignment = Assignment.find(self.assignment_id)
if (assignment.team_assignment?)
emails = get_one_member_team
email_reminder(emails, self.deadline_type)
end
end
if (self.deadline_type == "drop_one_member_topics")
assignment = Assignment.find(self.assignment_id)
drop_one_member_topics if (assignment.team_assignment?)
end
if (self.deadline_type == "drop_outstanding_reviews")
drop_outstanding_reviews
end
end
end

'''Modified Code:'''

def perform
assignment = Assignment.find(self.assignment_id)
emails = []
if !assignment.nil? && !assignment.id.nil?
deadlineObj = self.deadline_type.new
emails = deadlineObj.email_list
email_reminder(emails, self.deadline_type) if emails.size > 0
end
end

== '''Testing''' ==

The scheduled_task_spec.rb is the test class for the above changes.

E1632: Refactor delayed job.rb and scheduled task.rb

2016-10-29T03:28:12Z

Sjha4:

== '''Expertiza''' ==

Expertiza is an open source type of project that has been undertaken by the National Science Foundation. Various articles, codes in multiple languages and links can be submitted using the platform. It is popularly used by students studying at NC State to submit assignments, review works and get feedback. It allows users to switch between multiple environments if an user is not satisfied with a particular environment.

== '''Installation and Contribution''' ==

The setup development can be done using OSX, Linux or Docker. While using the OSX method and Linux method (RHEL), shell access and root access is a prerequisite. Docker is another method to install Wikipedia. It is cross Operating System (OS) compatible. Docker pull is needed to pull the docker image. Docker run is then used on port number 3000.
Expertiza allows user to contribute to their project. The expertiza project needs to be forked and cloned to create a local directory. Changes can be pushed and committed to a new branch. Finally the code is reviewed and changes are possibly made after a pull request.

== '''Problem Statement''' ==

The project is related to the class scheduled_class. The associated MVC framework relate to sending out reminder emails around the deadline of a task. The project objective includes-
*Removing duplicate code that is common in scheduled_task.rb and delayed_job.rb.
*Subclass Deadline_Type in the perform method.
*Refactoring mail_signed_up_users to multiple named methods and modifying it in a more elegant manner.
*Checks to the new refactored code.

----

'''Current Implementation'''
A task queue is implemented in expertiza for all the emails that need to be sent to the users. Delayed_mailer is used to send this task when the task is out of the queue. Scheduled_task provides information to the admin about the queue present at any given time. Scheduled_task uses assignment_id, deadline_type and due at to provide information for the admin. Current implementations include-
*Using the perform method linked to other methods mailing can be done for metareviewers, emails can be fetched and reminders can be sent to team members and mails can be sent to all signed up users.
*Implementation can be used for various types of deadlines. Deadline for team formation, sign-up and dropping outstanding reviews are also implemented.

----

'''Drawbacks and Solutions'''

'''Problem 1:''' Perform is too big a method and is implemented in a complicated manner.

'''Solution:''' Deadline_type is made a superclass with metareview, review, submission, drop_topic, sign_up, team_formation,drop_one_member_topic, drop_outstanding_reviews as the subclasses. The subclasses have a method email_list which contains the functionality. Thus, inheritance replaces the case structure.

'''Problem 2:''' mail_signed_up_users is a long method and contains duplicate code in its branches.

'''Solution:''' The mail_signed_up users can be split to two different methods- mail_sign_up_topics_user and and mail_non_sign_up_topics_user.The functionality of the first one is also used by the drop_topic subclass and the submission subclass uses both- the mail_sign_up_topics_user and mail_non_sign_up_topics_user.

----

== '''Code Modification''' ==

== Several new models have been added. All the deadline_type subclasses have been added as new models. ==
One of them looks like:

class review < DeadlineType
def email_list(assignment_id)
emails = []
reviewer_tuples = ResponseMap.where(['reviewed_object_id = ? AND type = "ReviewResponseMap"', assignment_id])
for reviewer in reviewer_tuples
participant = Participant.where(['parent_id = ? AND id = ?', assignment_id, reviewer.reviewer_id])
uid = participant.first.user_id
user = User.find(uid)
emails << user.email
end
emails
end
end

== Changes to the mail_signed_up_user ==

This includes the splitting of the method to multiple methods to make it more elegant

'''Earlier Code:'''

def mail_signed_up_users
emails = []
assignment = Assignment.find(self.assignment_id)
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
# If there are sign_up topics for an assignement then send a mail toonly signed_up_teams else send a mail to all participants
if (sign_up_topics.nil? || sign_up_topics.count == 0)
if assignment.team_assignment?
teamMails = getTeamMembersMail
for mail in teamMails
emails << mail
email_reminder(emails, self.deadline_type)
end
else
mail_assignment_participants
end
else
for topic in sign_up_topics
signedUpTeams = SignedUpTeam.where(['topic_id = ?', topic.id])
unless assignment.team_assignment?
for signedUser in signedUpTeams
uid = signedUser.team_id
user = User.find(uid)
emails << user.email
end
else
for signedUser in signedUpTeams
teamid = signedUser.team_id
team_members = TeamsUser.where(team_id: teamid)
for team_member in team_members
user = User.find(team_member.user_id)
emails << user.email
end
end
end
end
email_reminder(emails, self.deadline_type) if emails.size > 0
end
end

'''Modified Code:'''

def mail_signed_up_users
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
# If there are sign_up topics for an assignement then send a mail toonly signed_up_teams else send a mail to all participants
if (sign_up_topics.nil? || sign_up_topics.count == 0)
emails = mail_non_sign_up_topic_users
else
emails = mail_sign_up_topic_users
end
emails
end

== The perform method has been modified ==
The perform method has been modified to a large extent as it now uses Single Table Inheritance (STI) instead of if-else cases statements.

'''Earlier Code:'''

def perform
assignment = Assignment.find(self.assignment_id)
if !assignment.nil? && !assignment.id.nil?
if (self.deadline_type == "metareview")
mail_metareviewers
if assignment.team_assignment?
teamMails = getTeamMembersMail
email_reminder(teamMails, "teammate review")
end
end
if (self.deadline_type == "review")
mail_reviewers # to all reviewers
end
if (self.deadline_type == "submission")
mail_signed_up_users # to all signed up users
end
if (self.deadline_type == "drop_topic")
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
if (!sign_up_topics.nil? && sign_up_topics.count != 0)
mail_signed_up_users # reminder to signed_up users of the assignment
end
end
if (self.deadline_type == "signup")
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
if (!sign_up_topics.nil? && sign_up_topics.count != 0)
mail_assignment_participants # reminder to all participants
end
end
if (self.deadline_type == "team_formation")
assignment = Assignment.find(self.assignment_id)
if (assignment.team_assignment?)
emails = get_one_member_team
email_reminder(emails, self.deadline_type)
end
end
if (self.deadline_type == "drop_one_member_topics")
assignment = Assignment.find(self.assignment_id)
drop_one_member_topics if (assignment.team_assignment?)
end
if (self.deadline_type == "drop_outstanding_reviews")
drop_outstanding_reviews
end
end
end

'''Modified Code:'''

def perform
assignment = Assignment.find(self.assignment_id)
emails = []
if !assignment.nil? && !assignment.id.nil?
deadlineObj = self.deadline_type.new
emails = deadlineObj.email_list
email_reminder(emails, self.deadline_type) if emails.size > 0
end
end

== '''Testing''' ==

The scheduled_task_spec.rb is the test class for the above changes.

E1632: Refactor delayed job.rb and scheduled task.rb

2016-10-29T03:23:42Z

Sjha4:

User:Sjha4

2016-10-29T03:20:12Z

Sjha4: moved User:Sjha4 to E1632: Refactor delayed mailer.rb and scheduled task.rb: OSS Project

#REDIRECT [[E1632: Refactor delayed mailer.rb and scheduled task.rb]]

E1632: Refactor delayed job.rb and scheduled task.rb

2016-10-29T03:20:12Z

Sjha4: moved User:Sjha4 to E1632: Refactor delayed mailer.rb and scheduled task.rb: OSS Project

== '''Expertiza''' ==

Expertiza is an open source type of project that has been undertaken by the National Science Foundation. Various articles, codes in multiple languages and links can be submitted using the platform. It is popularly used by students studying at NC State to submit assignments, review works and get feedback. It allows users to switch between multiple environments if an user is not satisfied with a particular environment.

----

== '''Installation and Contribution''' ==

The setup development can be done using OSX, Linux or Docker. While using the OSX method and Linux method (RHEL), shell access and root access is a prerequisite. Docker is another method to install Wikipedia. It is cross Operating System (OS) compatible. Docker pull is needed to pull the docker image. Docker run is then used on port number 3000.
Expertiza allows user to contribute to their project. The expertiza project needs to be forked and cloned to create a local directory. Changes can be pushed and committed to a new branch. Finally the code is reviewed and changes are possibly made after a pull request.

----

'''Problem Statement'''
The project is related to the class scheduled_class. The associated MVC framework relate to sending out reminder emails around the deadline of a task. The project objective includes-
*Removing duplicate code that is common in scheduled_task.rb and delayed_job.rb.
*Subclass Deadline_Type in the perform method.
*Refactoring mail_signed_up_users to multiple named methods and modifying it in a more elegant manner.
*Checks to the new refactored code.

----

'''Current Implementation'''
A task queue is implemented in expertiza for all the emails that need to be sent to the users. Delayed_mailer is used to send this task when the task is out of the queue. Scheduled_task provides information to the admin about the queue present at any given time. Scheduled_task uses assignment_id, deadline_type and due at to provide information for the admin. Current implementations include-
*Using the perform method linked to other methods mailing can be done for metareviewers, emails can be fetched and reminders can be sent to team members and mails can be sent to all signed up users.
*Implementation can be used for various types of deadlines. Deadline for team formation, sign-up and dropping outstanding reviews are also implemented.

----

'''Drawbacks and Solutions'''
'''Problem 1:''' Perform is too big a method and is implemented in a complicated manner.

'''Solution:''' Deadline_type is made a superclass with metareview, review, submission, drop_topic, sign_up, team_formation,drop_one_member_topic, drop_outstanding_reviews as the subclasses. The subclasses have a method email_list which contains the functionality. Thus, inheritance replaces the case structure.

'''Problem 2:''' mail_signed_up_users is a long method and contains duplicate code in its branches.

'''Solution:''' The mail_signed_up users can be split to two different methods- mail_sign_up_topics_user and and mail_non_sign_up_topics_user.The functionality of the first one is also used by the drop_topic subclass and the submission subclass uses both- the mail_sign_up_topics_user and mail_non_sign_up_topics_user.

----

== '''Code Modification''' ==

== Several new models have been added. All the deadline_type subclasses have been added as new models. ==
One of them looks like:

class review < DeadlineType
def email_list(assignment_id)
emails = []
reviewer_tuples = ResponseMap.where(['reviewed_object_id = ? AND type = "ReviewResponseMap"', assignment_id])
for reviewer in reviewer_tuples
participant = Participant.where(['parent_id = ? AND id = ?', assignment_id, reviewer.reviewer_id])
uid = participant.first.user_id
user = User.find(uid)
emails << user.email
end
emails
end
end

== Changes to the mail_signed_up_user ==

This includes the splitting of the method to multiple methods to make it more elegant

'''Earlier Code:'''

def mail_signed_up_users
emails = []
assignment = Assignment.find(self.assignment_id)
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
# If there are sign_up topics for an assignement then send a mail toonly signed_up_teams else send a mail to all participants
if (sign_up_topics.nil? || sign_up_topics.count == 0)
if assignment.team_assignment?
teamMails = getTeamMembersMail
for mail in teamMails
emails << mail
email_reminder(emails, self.deadline_type)
end
else
mail_assignment_participants
end
else
for topic in sign_up_topics
signedUpTeams = SignedUpTeam.where(['topic_id = ?', topic.id])
unless assignment.team_assignment?
for signedUser in signedUpTeams
uid = signedUser.team_id
user = User.find(uid)
emails << user.email
end
else
for signedUser in signedUpTeams
teamid = signedUser.team_id
team_members = TeamsUser.where(team_id: teamid)
for team_member in team_members
user = User.find(team_member.user_id)
emails << user.email
end
end
end
end
email_reminder(emails, self.deadline_type) if emails.size > 0
end
end

'''Modified Code:'''

def mail_signed_up_users
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
# If there are sign_up topics for an assignement then send a mail toonly signed_up_teams else send a mail to all participants
if (sign_up_topics.nil? || sign_up_topics.count == 0)
emails = mail_non_sign_up_topic_users
else
emails = mail_sign_up_topic_users
end
emails
end

== The perform method has been modified ==
The perform method has been modified to a large extent as it now uses Single Table Inheritance (STI) instead of if-else cases statements.

'''Earlier Code:'''

def perform
assignment = Assignment.find(self.assignment_id)
if !assignment.nil? && !assignment.id.nil?
if (self.deadline_type == "metareview")
mail_metareviewers
if assignment.team_assignment?
teamMails = getTeamMembersMail
email_reminder(teamMails, "teammate review")
end
end
if (self.deadline_type == "review")
mail_reviewers # to all reviewers
end
if (self.deadline_type == "submission")
mail_signed_up_users # to all signed up users
end
if (self.deadline_type == "drop_topic")
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
if (!sign_up_topics.nil? && sign_up_topics.count != 0)
mail_signed_up_users # reminder to signed_up users of the assignment
end
end
if (self.deadline_type == "signup")
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
if (!sign_up_topics.nil? && sign_up_topics.count != 0)
mail_assignment_participants # reminder to all participants
end
end
if (self.deadline_type == "team_formation")
assignment = Assignment.find(self.assignment_id)
if (assignment.team_assignment?)
emails = get_one_member_team
email_reminder(emails, self.deadline_type)
end
end
if (self.deadline_type == "drop_one_member_topics")
assignment = Assignment.find(self.assignment_id)
drop_one_member_topics if (assignment.team_assignment?)
end
if (self.deadline_type == "drop_outstanding_reviews")
drop_outstanding_reviews
end
end
end

'''Modified Code:'''

def perform
assignment = Assignment.find(self.assignment_id)
emails = []
if !assignment.nil? && !assignment.id.nil?
deadlineObj = self.deadline_type.new
emails = deadlineObj.email_list
email_reminder(emails, self.deadline_type) if emails.size > 0
end
end

E1632: Refactor delayed job.rb and scheduled task.rb

2016-10-29T03:18:07Z

Sjha4: Adding wiki for OSS project 1

== '''Expertiza''' ==

Expertiza is an open source type of project that has been undertaken by the National Science Foundation. Various articles, codes in multiple languages and links can be submitted using the platform. It is popularly used by students studying at NC State to submit assignments, review works and get feedback. It allows users to switch between multiple environments if an user is not satisfied with a particular environment.

----

== '''Installation and Contribution''' ==

The setup development can be done using OSX, Linux or Docker. While using the OSX method and Linux method (RHEL), shell access and root access is a prerequisite. Docker is another method to install Wikipedia. It is cross Operating System (OS) compatible. Docker pull is needed to pull the docker image. Docker run is then used on port number 3000.
Expertiza allows user to contribute to their project. The expertiza project needs to be forked and cloned to create a local directory. Changes can be pushed and committed to a new branch. Finally the code is reviewed and changes are possibly made after a pull request.

----

'''Problem Statement'''
The project is related to the class scheduled_class. The associated MVC framework relate to sending out reminder emails around the deadline of a task. The project objective includes-
*Removing duplicate code that is common in scheduled_task.rb and delayed_job.rb.
*Subclass Deadline_Type in the perform method.
*Refactoring mail_signed_up_users to multiple named methods and modifying it in a more elegant manner.
*Checks to the new refactored code.

----

'''Current Implementation'''
A task queue is implemented in expertiza for all the emails that need to be sent to the users. Delayed_mailer is used to send this task when the task is out of the queue. Scheduled_task provides information to the admin about the queue present at any given time. Scheduled_task uses assignment_id, deadline_type and due at to provide information for the admin. Current implementations include-
*Using the perform method linked to other methods mailing can be done for metareviewers, emails can be fetched and reminders can be sent to team members and mails can be sent to all signed up users.
*Implementation can be used for various types of deadlines. Deadline for team formation, sign-up and dropping outstanding reviews are also implemented.

----

'''Drawbacks and Solutions'''
'''Problem 1:''' Perform is too big a method and is implemented in a complicated manner.

'''Solution:''' Deadline_type is made a superclass with metareview, review, submission, drop_topic, sign_up, team_formation,drop_one_member_topic, drop_outstanding_reviews as the subclasses. The subclasses have a method email_list which contains the functionality. Thus, inheritance replaces the case structure.

'''Problem 2:''' mail_signed_up_users is a long method and contains duplicate code in its branches.

'''Solution:''' The mail_signed_up users can be split to two different methods- mail_sign_up_topics_user and and mail_non_sign_up_topics_user.The functionality of the first one is also used by the drop_topic subclass and the submission subclass uses both- the mail_sign_up_topics_user and mail_non_sign_up_topics_user.

----

== '''Code Modification''' ==

== Several new models have been added. All the deadline_type subclasses have been added as new models. ==
One of them looks like:

class review < DeadlineType
def email_list(assignment_id)
emails = []
reviewer_tuples = ResponseMap.where(['reviewed_object_id = ? AND type = "ReviewResponseMap"', assignment_id])
for reviewer in reviewer_tuples
participant = Participant.where(['parent_id = ? AND id = ?', assignment_id, reviewer.reviewer_id])
uid = participant.first.user_id
user = User.find(uid)
emails << user.email
end
emails
end
end

== Changes to the mail_signed_up_user ==

This includes the splitting of the method to multiple methods to make it more elegant

'''Earlier Code:'''

def mail_signed_up_users
emails = []
assignment = Assignment.find(self.assignment_id)
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
# If there are sign_up topics for an assignement then send a mail toonly signed_up_teams else send a mail to all participants
if (sign_up_topics.nil? || sign_up_topics.count == 0)
if assignment.team_assignment?
teamMails = getTeamMembersMail
for mail in teamMails
emails << mail
email_reminder(emails, self.deadline_type)
end
else
mail_assignment_participants
end
else
for topic in sign_up_topics
signedUpTeams = SignedUpTeam.where(['topic_id = ?', topic.id])
unless assignment.team_assignment?
for signedUser in signedUpTeams
uid = signedUser.team_id
user = User.find(uid)
emails << user.email
end
else
for signedUser in signedUpTeams
teamid = signedUser.team_id
team_members = TeamsUser.where(team_id: teamid)
for team_member in team_members
user = User.find(team_member.user_id)
emails << user.email
end
end
end
end
email_reminder(emails, self.deadline_type) if emails.size > 0
end
end

'''Modified Code:'''

def mail_signed_up_users
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
# If there are sign_up topics for an assignement then send a mail toonly signed_up_teams else send a mail to all participants
if (sign_up_topics.nil? || sign_up_topics.count == 0)
emails = mail_non_sign_up_topic_users
else
emails = mail_sign_up_topic_users
end
emails
end

== The perform method has been modified ==
The perform method has been modified to a large extent as it now uses Single Table Inheritance (STI) instead of if-else cases statements.

'''Earlier Code:'''

def perform
assignment = Assignment.find(self.assignment_id)
if !assignment.nil? && !assignment.id.nil?
if (self.deadline_type == "metareview")
mail_metareviewers
if assignment.team_assignment?
teamMails = getTeamMembersMail
email_reminder(teamMails, "teammate review")
end
end
if (self.deadline_type == "review")
mail_reviewers # to all reviewers
end
if (self.deadline_type == "submission")
mail_signed_up_users # to all signed up users
end
if (self.deadline_type == "drop_topic")
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
if (!sign_up_topics.nil? && sign_up_topics.count != 0)
mail_signed_up_users # reminder to signed_up users of the assignment
end
end
if (self.deadline_type == "signup")
sign_up_topics = SignUpTopic.where(['assignment_id = ?', self.assignment_id])
if (!sign_up_topics.nil? && sign_up_topics.count != 0)
mail_assignment_participants # reminder to all participants
end
end
if (self.deadline_type == "team_formation")
assignment = Assignment.find(self.assignment_id)
if (assignment.team_assignment?)
emails = get_one_member_team
email_reminder(emails, self.deadline_type)
end
end
if (self.deadline_type == "drop_one_member_topics")
assignment = Assignment.find(self.assignment_id)
drop_one_member_topics if (assignment.team_assignment?)
end
if (self.deadline_type == "drop_outstanding_reviews")
drop_outstanding_reviews
end
end
end

'''Modified Code:'''

def perform
assignment = Assignment.find(self.assignment_id)
emails = []
if !assignment.nil? && !assignment.id.nil?
deadlineObj = self.deadline_type.new
emails = deadlineObj.email_list
email_reminder(emails, self.deadline_type) if emails.size > 0
end
end