Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-12-15T16:54:04Z

Aanilku: /* 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==
 
[[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|.....}|event_description]
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.

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

==Implementation==
====Changes in existing files====
We have also inserted new code in the following controllers:
*application_controller.rb
*admin_controller.rb
*advice_controller.rb
*assignment_questionnaire_controller.rb
*assignment_signups_controller.rb
*assignments_controller.rb
*auth_controller.rb
*course_controller.rb
*impersonate_controller.rb
*import_file_controller.rb
*invitation_controller.rb
*questionnaires_controller.rb
*response_controller.rb
*review_mapping_controller.rb
*submitted_content_controller.rb
*teams_controller.rb

Defined a logger object in the application_controller that points to our new log file: events.log.
Since this is defined in the application controller, it will be accessible in all the controllers and there is no need to redefine it again in the other controllers where we use it to log events. We have added a total of 45 logging statements for different events.

The new code in the other controllers are simple logging statements to log events, does not affect the functionality of the existing code in any way.

====New Controllers====
*logger_controller.rb
We created a new controller for reading and filtering the log records.
This has two actions, for viewing the logs and for filtering the logs based on input from the user.

===New Models===
*log_entry.rb
This model was created to represent each log statement in the record. It contains fields that pertain to a log entry like the time, userid, event and log description

===New Views===
*view_logs.html.erb
This is the view we created for viewing the logs records. The used is also given an option to filter the logs based on time, userid, user type and event type.

[[File:view2.png]]

Each log entry has a serial number, timestamp, name of the event, description of the event, type of the user involved in the event and userID of the user.
We have provided the option to search the logs by user type, userID, event type and time.
You can notice that there is a second search field below just above the table. It does an in page search of the results that are currently loaded. Its faster if you dont want the latest logs. It will search only the records that were present in the log file when the page was loaded. If you want to search the latest logs, i.e logs that have been added after the page was loaded, you need to use the first search button. This search will be comparatively slower as it involves a controller hit and redirection back to the view page.

==Testing==

====RSpec Testing====
We have written a feature test in RSpec for the logger module. We have created a new class: logger_spec.rb for the test cases.

====Test 1====
If the user having less privileges than an admin tries to access the log viewer page, then he/she gets a authentication failure message.

==Future Extension==
This project can be easily extended by adding more log statements to additional or new events by simply making a log entry with our logger object in the specified format. If proper format is followed, it will get picked up by the parser and will be visible in the view.

==Conclusion==
We learned a lot doing this project. It was a good experience contributing to open source software. We got a chance to add an entire model, view and controller to the existing codebase. We also had to read through all the existing controller code to insert logging statements at proper locations to log user activity. This was a good learning experience.

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-12-15T16:53:18Z

Aanilku: /* Future Extension */

==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|.....}|event description]
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.

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

==Implementation==
====Changes in existing files====
We have also inserted new code in the following controllers:
*application_controller.rb
*admin_controller.rb
*advice_controller.rb
*assignment_questionnaire_controller.rb
*assignment_signups_controller.rb
*assignments_controller.rb
*auth_controller.rb
*course_controller.rb
*impersonate_controller.rb
*import_file_controller.rb
*invitation_controller.rb
*questionnaires_controller.rb
*response_controller.rb
*review_mapping_controller.rb
*submitted_content_controller.rb
*teams_controller.rb

Defined a logger object in the application_controller that points to our new log file: events.log.
Since this is defined in the application controller, it will be accessible in all the controllers and there is no need to redefine it again in the other controllers where we use it to log events. We have added a total of 45 logging statements for different events.

The new code in the other controllers are simple logging statements to log events, does not affect the functionality of the existing code in any way.

====New Controllers====
*logger_controller.rb
We created a new controller for reading and filtering the log records.
This has two actions, for viewing the logs and for filtering the logs based on input from the user.

===New Models===
*log_entry.rb
This model was created to represent each log statement in the record. It contains fields that pertain to a log entry like the time, userid, event and log description

===New Views===
*view_logs.html.erb
This is the view we created for viewing the logs records. The used is also given an option to filter the logs based on time, userid, user type and event type.

[[File:view2.png]]

Each log entry has a serial number, timestamp, name of the event, description of the event, type of the user involved in the event and userID of the user.
We have provided the option to search the logs by user type, userID, event type and time.
You can notice that there is a second search field below just above the table. It does an in page search of the results that are currently loaded. Its faster if you dont want the latest logs. It will search only the records that were present in the log file when the page was loaded. If you want to search the latest logs, i.e logs that have been added after the page was loaded, you need to use the first search button. This search will be comparatively slower as it involves a controller hit and redirection back to the view page.

==Testing==

====RSpec Testing====
We have written a feature test in RSpec for the logger module. We have created a new class: logger_spec.rb for the test cases.

====Test 1====
If the user having less privileges than an admin tries to access the log viewer page, then he/she gets a authentication failure message.

==Future Extension==
This project can be easily extended by adding more log statements to additional or new events by simply making a log entry with our logger object in the specified format. If proper format is followed, it will get picked up by the parser and will be visible in the view.

==Conclusion==
We learned a lot doing this project. It was a good experience contributing to open source software. We got a chance to add an entire model, view and controller to the existing codebase. We also had to read through all the existing controller code to insert logging statements at proper locations to log user activity. This was a good learning experience.

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-12-15T04:20:29Z

Aanilku: /* Testing */

==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|.....}|event description]
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.

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

==Implementation==
====Changes in existing files====
We have also inserted new code in the following controllers:
*application_controller.rb
*admin_controller.rb
*advice_controller.rb
*assignment_questionnaire_controller.rb
*assignment_signups_controller.rb
*assignments_controller.rb
*auth_controller.rb
*course_controller.rb
*impersonate_controller.rb
*import_file_controller.rb
*invitation_controller.rb
*questionnaires_controller.rb
*response_controller.rb
*review_mapping_controller.rb
*submitted_content_controller.rb
*teams_controller.rb

Defined a logger object in the application_controller that points to our new log file: events.log.
Since this is defined in the application controller, it will be accessible in all the controllers and there is no need to redefine it again in the other controllers where we use it to log events. We have added a total of 45 logging statements for different events.

The new code in the other controllers are simple logging statements to log events, does not affect the functionality of the existing code in any way.

====New Controllers====
*logger_controller.rb
We created a new controller for reading and filtering the log records.
This has two actions, for viewing the logs and for filtering the logs based on input from the user.

===New Models===
*log_entry.rb
This model was created to represent each log statement in the record. It contains fields that pertain to a log entry like the time, userid, event and log description

===New Views===
*view_logs.html.erb
This is the view we created for viewing the logs records. The used is also given an option to filter the logs based on time, userid, user type and event type.

[[File:view2.png]]

Each log entry has a serial number, timestamp, name of the event, description of the event, type of the user involved in the event and userID of the user.
We have provided the option to search the logs by user type, userID, event type and time.
You can notice that there is a second search field below just above the table. It does an in page search of the results that are currently loaded. Its faster if you dont want the latest logs. It will search only the records that were present in the log file when the page was loaded. If you want to search the latest logs, i.e logs that have been added after the page was loaded, you need to use the first search button. This search will be comparatively slower as it involves a controller hit and redirection back to the view page.

==Testing==

====RSpec Testing====
We have written a feature test in RSpec for the logger module. We have created a new class: logger_spec.rb for the test cases.

====Test 1====
If the user having less privileges than an admin tries to access the log viewer page, then he/she gets a authentication failure message.

==Future Extension==
This project can be easily extended by adding more log statements to additional or new events by simply making a log entry with our logger object in the specified format. If proper format is followed, it will get picked up by the parser and will be visible in the view.

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-12-15T03:41:26Z

Aanilku: /* New Views */

==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|.....}|event description]
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.

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

==Implementation==
====Changes in existing files====
We have also inserted new code in the following controllers:
*application_controller.rb
*admin_controller.rb
*advice_controller.rb
*assignment_questionnaire_controller.rb
*assignment_signups_controller.rb
*assignments_controller.rb
*auth_controller.rb
*course_controller.rb
*impersonate_controller.rb
*import_file_controller.rb
*invitation_controller.rb
*questionnaires_controller.rb
*response_controller.rb
*review_mapping_controller.rb
*submitted_content_controller.rb
*teams_controller.rb

Defined a logger object in the application_controller that points to our new log file: events.log.
Since this is defined in the application controller, it will be accessible in all the controllers and there is no need to redefine it again in the other controllers where we use it to log events. We have added a total of 45 logging statements for different events.

The new code in the other controllers are simple logging statements to log events, does not affect the functionality of the existing code in any way.

====New Controllers====
*logger_controller.rb
We created a new controller for reading and filtering the log records.
This has two actions, for viewing the logs and for filtering the logs based on input from the user.

===New Models===
*log_entry.rb
This model was created to represent each log statement in the record. It contains fields that pertain to a log entry like the time, userid, event and log description

===New Views===
*view_logs.html.erb
This is the view we created for viewing the logs records. The used is also given an option to filter the logs based on time, userid, user type and event type.

[[File:view2.png]]

Each log entry has a serial number, timestamp, name of the event, description of the event, type of the user involved in the event and userID of the user.
We have provided the option to search the logs by user type, userID, event type and time.
You can notice that there is a second search field below just above the table. It does an in page search of the results that are currently loaded. Its faster if you dont want the latest logs. It will search only the records that were present in the log file when the page was loaded. If you want to search the latest logs, i.e logs that have been added after the page was loaded, you need to use the first search button. This search will be comparatively slower as it involves a controller hit and redirection back to the view page.

==Testing==

====RSpec Testing====
We have written feature tests in RSpec for the logger module. We have created a new class: logger_spec.rb for the test cases.
====Test 1====
Check if the link redirects to the log view page when you click on it.

====Test 2====
If the user having less privileges than an admin tries to access the log viewer page, then he/she gets a authentication failure message.

====Test 3====
Tests if the search functionality is working properly or not. Tests by searching with a user ID and checks if the results contain only results for that particular user ID.

==Future Extension==
This project can be easily extended by adding more log statements to additional or new events by simply making a log entry with our logger object in the specified format. If proper format is followed, it will get picked up by the parser and will be visible in the view.

File:View2.png

2016-12-15T03:35:07Z

Aanilku:

File:View.png

2016-12-15T03:32:50Z

Aanilku:

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-12-15T03:28:33Z

Aanilku: /* Future Extension */

==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|.....}|event description]
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.

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

==Implementation==
====Changes in existing files====
We have also inserted new code in the following controllers:
*application_controller.rb
*admin_controller.rb
*advice_controller.rb
*assignment_questionnaire_controller.rb
*assignment_signups_controller.rb
*assignments_controller.rb
*auth_controller.rb
*course_controller.rb
*impersonate_controller.rb
*import_file_controller.rb
*invitation_controller.rb
*questionnaires_controller.rb
*response_controller.rb
*review_mapping_controller.rb
*submitted_content_controller.rb
*teams_controller.rb

Defined a logger object in the application_controller that points to our new log file: events.log.
Since this is defined in the application controller, it will be accessible in all the controllers and there is no need to redefine it again in the other controllers where we use it to log events. We have added a total of 45 logging statements for different events.

The new code in the other controllers are simple logging statements to log events, does not affect the functionality of the existing code in any way.

====New Controllers====
*logger_controller.rb
We created a new controller for reading and filtering the log records.
This has two actions, for viewing the logs and for filtering the logs based on input from the user.

===New Models===
*log_entry.rb
This model was created to represent each log statement in the record. It contains fields that pertain to a log entry like the time, userid, event and log description

===New Views===
*view_logs.html.erb
This is the view we created for viewing the logs records. The used is also given an option to filter the logs based on time, userid, user type and event type.

==Testing==

====RSpec Testing====
We have written feature tests in RSpec for the logger module. We have created a new class: logger_spec.rb for the test cases.
====Test 1====
Check if the link redirects to the log view page when you click on it.

====Test 2====
If the user having less privileges than an admin tries to access the log viewer page, then he/she gets a authentication failure message.

====Test 3====
Tests if the search functionality is working properly or not. Tests by searching with a user ID and checks if the results contain only results for that particular user ID.

==Future Extension==
This project can be easily extended by adding more log statements to additional or new events by simply making a log entry with our logger object in the specified format. If proper format is followed, it will get picked up by the parser and will be visible in the view.

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-12-15T03:26:56Z

Aanilku: /* Testing */

==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|.....}|event description]
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.

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

==Implementation==
====Changes in existing files====
We have also inserted new code in the following controllers:
*application_controller.rb
*admin_controller.rb
*advice_controller.rb
*assignment_questionnaire_controller.rb
*assignment_signups_controller.rb
*assignments_controller.rb
*auth_controller.rb
*course_controller.rb
*impersonate_controller.rb
*import_file_controller.rb
*invitation_controller.rb
*questionnaires_controller.rb
*response_controller.rb
*review_mapping_controller.rb
*submitted_content_controller.rb
*teams_controller.rb

Defined a logger object in the application_controller that points to our new log file: events.log.
Since this is defined in the application controller, it will be accessible in all the controllers and there is no need to redefine it again in the other controllers where we use it to log events. We have added a total of 45 logging statements for different events.

The new code in the other controllers are simple logging statements to log events, does not affect the functionality of the existing code in any way.

====New Controllers====
*logger_controller.rb
We created a new controller for reading and filtering the log records.
This has two actions, for viewing the logs and for filtering the logs based on input from the user.

===New Models===
*log_entry.rb
This model was created to represent each log statement in the record. It contains fields that pertain to a log entry like the time, userid, event and log description

===New Views===
*view_logs.html.erb
This is the view we created for viewing the logs records. The used is also given an option to filter the logs based on time, userid, user type and event type.

==Testing==

====RSpec Testing====
We have written feature tests in RSpec for the logger module. We have created a new class: logger_spec.rb for the test cases.
====Test 1====
Check if the link redirects to the log view page when you click on it.

====Test 2====
If the user having less privileges than an admin tries to access the log viewer page, then he/she gets a authentication failure message.

====Test 3====
Tests if the search functionality is working properly or not. Tests by searching with a user ID and checks if the results contain only results for that particular user ID.

==Future Extension==

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-12-13T21:33:54Z

Aanilku: /* Implementation */

==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|.....}|event description]
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.

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

==Implementation==
====Changes in existing files====
We have also inserted new code in the following controllers:
*application_controller.rb
*admin_controller.rb
*advice_controller.rb
*assignment_questionnaire_controller.rb
*assignment_signups_controller.rb
*assignments_controller.rb
*auth_controller.rb
*course_controller.rb
*impersonate_controller.rb
*import_file_controller.rb
*invitation_controller.rb
*questionnaires_controller.rb
*response_controller.rb
*review_mapping_controller.rb
*submitted_content_controller.rb
*teams_controller.rb

Defined a logger object in the application_controller that points to our new log file: events.log.
Since this is defined in the application controller, it will be accessible in all the controllers and there is no need to redefine it again in the other controllers where we use it to log events. We have added a total of 45 logging statements for different events.

The new code in the other controllers are simple logging statements to log events, does not affect the functionality of the existing code in any way.

====New Controllers====
*logger_controller.rb
We created a new controller for reading and filtering the log records.
This has two actions, for viewing the logs and for filtering the logs based on input from the user.

===New Models===
*log_entry.rb
This model was created to represent each log statement in the record. It contains fields that pertain to a log entry like the time, userid, event and log description

===New Views===
*view_logs.html.erb
This is the view we created for viewing the logs records. The used is also given an option to filter the logs based on time, userid, user type and event type.

==Testing==

====RSpec Testing====
We have written feature tests in RSpec for the logger module. We have created a new class: logger_spec.rb for the test cases.
====Test 1====
Check if the link redirects to the log view page when you click on it.

====Test 2====
If the user having less privileges than an admin tries to access the log viewer page, then he/she gets a authentication failure message.

====Test 3====
Tests if the search functionality is working properly or not. Tests by searching with a user ID and checks if the results contain only results for that particular user ID.

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-12-13T15:59:07Z

Aanilku: /* New Views */

==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|.....}|event description]
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.

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

==Implementation==
====Changes in existing files====
We have defined a logger object in the application_controller that points to our new log file: events.log.
Since this is defined in the application controller, it will be accessible in all the controllers and there is no need to redefine it again in the other controllers where we use it to log events.

We have also inserted new code in the following controllers:

The new code we added are simple logging statements to log events, does not affect the functionality of the existing code in any way.

====New Controllers====
logger_controller.rb
We created a new controller for reading and filtering the log records.
This has two actions, for viewing the logs and for filtering the logs based on input from the user.

===New Models===
log_entry.rb
This model was created to represent each log statement in the record. It contains fields that pertain to a log entry like the time, userid, event and log description

===New Views===
*view_logs.html.erb
This is the view we created for viewing the logs records. The used is also given an option to filter the logs based on time, userid, user type and event type.

==Testing==

====RSpec Testing====
We have written feature tests in RSpec for the logger module. We have created a new class: logger_spec.rb for the test cases.
====Test 1====
Check if the link redirects to the log view page when you click on it.

====Test 2====
If the user having less privileges than an admin tries to access the log viewer page, then he/she gets a authentication failure message.

====Test 3====
Tests if the search functionality is working properly or not. Tests by searching with a user ID and checks if the results contain only results for that particular user ID.

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-12-13T15:54:11Z

Aanilku: /* Implementation */

==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|.....}|event description]
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.

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

==Implementation==
====Changes in existing files====
We have defined a logger object in the application_controller that points to our new log file: events.log.
Since this is defined in the application controller, it will be accessible in all the controllers and there is no need to redefine it again in the other controllers where we use it to log events.

We have also inserted new code in the following controllers:

The new code we added are simple logging statements to log events, does not affect the functionality of the existing code in any way.

====New Controllers====
logger_controller.rb
We created a new controller for reading and filtering the log records.
This has two actions, for viewing the logs and for filtering the logs based on input from the user.

===New Models===
log_entry.rb
This model was created to represent each log statement in the record. It contains fields that pertain to a log entry like the time, userid, event and log description

===New Views===

==Testing==

====RSpec Testing====
We have written feature tests in RSpec for the logger module. We have created a new class: logger_spec.rb for the test cases.
====Test 1====
Check if the link redirects to the log view page when you click on it.

====Test 2====
If the user having less privileges than an admin tries to access the log viewer page, then he/she gets a authentication failure message.

====Test 3====
Tests if the search functionality is working properly or not. Tests by searching with a user ID and checks if the results contain only results for that particular user ID.

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-12-13T15:41:13Z

Aanilku: /* Interpreting the Logs */

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-12-11T04:03:07Z

Aanilku: /* Logging */

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-12-11T03:49:43Z

Aanilku:

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-11-11T00:29:24Z

Aanilku: /* Interpreting the Logs */

File:Sketch.png

2016-11-11T00:26:41Z

Aanilku:

File:MockScreen.png

2016-11-11T00:21:01Z

Aanilku:

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-11-10T01:57:09Z

Aanilku: /* What we plan to implement */

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-11-10T01:54:54Z

Aanilku: /* Instructor/TA/Admin Activity */

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-11-10T01:54:20Z

Aanilku: /* Introduction */

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-11-10T01:53:30Z

Aanilku: /* Logging */

CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

2016-11-10T01:52:29Z

Aanilku: Created page with "==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..."

CSC/ECE 517 Fall 2016

2016-11-09T21:41:42Z

Aanilku: /* Final Project Design Document */

[http://www.example.com link title]==Calibration Assignment Submissions==
*[[Calibration Assignment Submission (Firebrick JS)]]
*[[Calibration Assignment Submission (Active Job)]]
==Writing Assignments 2==
*[[CSC/ECE 517 Fall 2016/E1666. Test team functionality]]
*[[CSC/ECE 517 Fall 2016/E1643. Refactor Suggestion controller]]
*[[CSC/ECE 517 Fall 2016/E1631. Refactoring Bidding Interface]]
*[[CSC/ECE 517 Fall 2016/E1674.Refactor leaderboard.rb and write unit tests]]
*[[CSC/ECE 517 Fall 2016/E1671. Unit Tests for participants.rb Hierarchy]]
*[[CSC/ECE 517 Fall 2016/E1668.Test e-mailing functionality]]
*[[CSC/ECE 517 Fall 2016/E1658. Refractor lottery_controller.rb and write integration tests]]
*[[CSC/ECE 517 Fall 2016/E1660. Review requirements and thresholds]]
*[[CSC/ECE 517 Fall 2016/E1650. Sort instructor views alphabetically by default]]
*[[CSC/ECE 517 Fall 2016/E1644. Refactor and test Teams Controller]]
*[[CSC/ECE 517 Fall 2016/E1645. Refactoring Tree Display Controller]]
*[[CSC/ECE 517 Fall 2016/E1659. Refactor on_the_fly_calc.rb]]
*[[CSC/ECE 517 Fall 2016/E1657. Introduce a Student View for instructors]]
*[[CSC/ECE 517 Fall 2016/E1653. Fix and improve rubric criteria]]
*[[CSC/ECE 517 Fall 2016/E1642. Refactor review_response_map.rb]]
*[[CSC/ECE 517 Fall 2016/E1633. Refactor different question types from quiz feature]]
*[[CSC/ECE_517_Fall_2016/E1664:_Feature_Test_Assignment_Creation]]
*[[CSC/ECE 517 Fall 2016/E1666. Test team functionality]]
*[[CSC/ECE_517_Fall_2016/E1654. Improve_date-picker_and_deadlines]]
*[[CSC/ECE_517_Fall_2016/E1652 Fix teammate advertisements and requests to join a team ]]
*[[CSC/ECE_517_Fall_2016/E1662. UI issues/fixes]]
*[[CSC/ECE_517_Fall_2016/E1673. Refactor question_type.rb]]
*[[CSC/ECE_517_Fall_2016/E1675. Timestamp for student file & hyperlink submissions]]
*[[CSC/ECE_517_Fall_2016/E1640. Refactor response.rb and response_helper.rb]]
*[[CSC/ECE 517 Fall 2016/E1634. Refactor and write unit test of due_date.rb and deadline_helper.rb]]
*[[CSC/ECE_517_Fall_2016/M1654._Improve_network_security_features]]
*[[CSC/ECE_517_Fall_2016/E1670._Unit_tests_for_answers.rb]]
*[[CSC/ECE_517_Fall_2016/E1641. Refactor review_mapping_controller.rb]]
*[[CSC/ECE_517_Fall_2016/M1652_Implement_ImageMap_Support_Servo]]
*[[CSC/ECE_517_Fall_2016/E1648/Add_past_due_assignment]]
*[[CSC/ECE 517 Fall 2016/E1656. Improve imports]]
*[[CSC/ECE_517_Fall_2016/M1653_Implement_HTML_form_validation]]
==Final Project Design Document==
*[[CSC/ECE 517 Fall 2016 E1696 Improve Self-Review]]
*[[CSC/ECE 517 Fall 2016 E1676 Role-based reviewing]]
*[[CSC/ECE 517 Fall 2016/E1680. Improve survey functionality]]
*[[CSC/ECE 517 Fall 2016/E1693. Drag-and-drop interface for creating rubrics]]
*[[CSC/ECE 517 Fall 2016/E1701. Accelerate RSpec testing]]
*[[CSC/ECE 517 Fall 2016/E1705. Tracking the time students look at the others' submissions]]
*[[CSC/ECE 517 Fall 2016/E1688. Send feedback to support + tree display improvement]]
*[[CSC/ECE 517 Fall 2016 E1707: Top trading cycles to exclude previous teammates]]
*[[CSC/ECE 517 Fall 2016 E1678: Review configuration options]]
*[[CSC/ECE 517 Fall 2016 E1682: Improve score calculation]]
*[[CSC/ECE 517 Fall 2016 E1684: Feature Test for Assignment Submission]]
*[[CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza]]

CSC/ECE 517 Fall 2016/E1658. Refractor lottery controller.rb and write integration tests

2016-11-09T03:26:56Z

Aanilku: /* Test Cases */

===Expertiza Background===
Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. It allows students to review each other’s work and improve their work upon this feedback.

===Description of Current Project===
The following is an Expertiza based OSS project which deals primarily with the lottery_controller.rb file. It focusses on refactoring some of the more complex methods, modifying some of the language to make it more Ruby friendly, removing some redundant code. The goal of this project is to attempt to make this part of the application easier to read and maintain.
The lottery_controller contains all of the logic for running the lottery. Code climate is used in this project to detect various issues such as high cyclomatic complexity, bad naming, etc.

===Changes needed===
Fix following issues mentioned below:
* Cyclomatic complexity for run_intelligent_bid is too high.
* Perceived complexity for run_intelligent_bid is too high.
* Use snake_case for variable names.
* Avoid more than 3 levels of block nesting.

===Changes performed===
The code was refactored and its Code Climate rating improved from F to A.

Before Refractoring:
[[File:Ccbefore.png|frame|left]]

After Refractoring:
[[File:Ccscafter.png|frame|left]]

* Cyclomatic complexity for run_intelligent_bid and other methods is greatly reduced.
* Perceived complexity for run_intelligent_bid is also reduced.
* snake_case are used for variable names.
* More than 3 levels of block nesting is avoided.

Before:
<pre>
if bid_record.nil?
bids << 0
else
bids << bid_record.priority ||= 0
end
</pre>

After:
<pre>
bids << bid_record.nil? ? 0 : bid_record.priority ||= 0
</pre>
Assignment using if condition was changed to conditional operator

Before:

<pre>
assignment = Assignment.find_by_id(params[:id])
</pre>

After:

<pre>
assignment = Assignment.find_by(id: params[:id])
</pre>
Changed to find_by from find_by_id

Before:

<pre>
response = RestClient.post url, data.to_json, :content_type => :json, :accept => :json
</pre>

After:

<pre>
response = RestClient.post url, data.to_json, content_type: :json, accept: :json
</pre>
Changed to the latest ruby convention for HashMaps

Before:

<pre>
def create_new_teams_for_bidding_response(teams, assignment)
teams.each_with_index do |user_ids, index|
new_team = AssignmentTeam.create(name: assignment.name + '_Team' + rand(1000).to_s,
parent_id: assignment.id,
type: 'AssignmentTeam')
parent = TeamNode.create(parent_id: assignment.id, node_object_id: new_team.id)
user_ids.each do |user_id|
team_user = TeamsUser.where(user_id: user_id, team_id: new_team.id).first rescue nil
team_user = TeamsUser.create(user_id: user_id, team_id: new_team.id) if team_user.nil?
TeamUserNode.create(parent_id: parent.id, node_object_id: team_user.id)
end
end
end
</pre>

After:

<pre>
def create_new_teams_for_bidding_response(teams, assignment)
teams.each_with_index do |user_ids|
new_team = AssignmentTeam.create(name: assignment.name + '_Team' + rand(1000).to_s,
parent_id: assignment.id,
type: 'AssignmentTeam')
parent = TeamNode.create(parent_id: assignment.id, node_object_id: new_team.id)
user_ids.each do |user_id|
team_user = TeamsUser.where(user_id: user_id, team_id: new_team.id).first rescue nil
team_user = TeamsUser.create(user_id: user_id, team_id: new_team.id) if team_user.nil?
TeamUserNode.create(parent_id: parent.id, node_object_id: team_user.id)
end
end
</pre>
Removed unused variables

Before:

<pre>
unless Assignment.find_by_id(params[:id]).is_intelligent # if the assignment is intelligent then redirect to the tree display list
flash[:error] = "This action not allowed. The assignment " + Assignment.find_by_id(params[:id]).name + " does not enabled intelligent assignments."
</pre>

After:

<pre>
unless Assignment.find_by(id: params[:id]).is_intelligent # if the assignment is intelligent then redirect to the tree display list
flash[:error] = "This action not allowed. The assignment " + Assignment.find_by(id: params[:id]).name + " does not enabled intelligent assignments."
</pre>
Changed find_by_id to find_by

Before:

<pre>
unassignedTeams = AssignmentTeam.where(parent_id: params[:id]).reject {|t| !SignedUpTeam.where(team_id: t.id).empty?}
unassignedTeams.sort! {|t1, t2| TeamsUser.where(team_id: t2.id).size <=> TeamsUser.where(team_id: t1.id).size}
team_bids = []
unassignedTeams.each do |team|
topic_bids = []
sign_up_topics.each do |topic|
student_bids = []
TeamsUser.where(team_id: team.id).each do |s|
student_bid = Bid.where(user_id: s.user_id, topic_id: topic.id).first rescue nil
if !student_bid.nil? and !student_bid.priority.nil?
student_bids << student_bid.priority
end
end
#takes the most frequent priority as the team priority
freq = student_bids.inject(Hash.new(0)) { |h,v| h[v] += 1; h}
topic_bids << {topic_id: topic.id, priority: student_bids.max_by { |v| freq[v] }} unless freq.empty?
end
topic_bids.sort! {|b| b[:priority]}
team_bids << {team_id: team.id, bids: topic_bids}
end
</pre>

After:
<pre>
unassigned_teams = AssignmentTeam.where(parent_id: params[:id]).reject {|t| !SignedUpTeam.where(team_id: t.id).empty? }
unassigned_teams.sort! {|t1, t2| TeamsUser.where(team_id: t2.id).size <=> TeamsUser.where(team_id: t1.id).size }
team_bids = []
unassigned_teams.each do |team|
topic_bids = []
sign_up_topics.each do |topic|
student_bids = []
TeamsUser.where(team_id: team.id).each do |s|
student_bid = Bid.where(user_id: s.user_id, topic_id: topic.id).first rescue nil
if !student_bid.nil?
if !student_bid.priority.nil?
student_bids << student_bid.priority
end
end
# takes the most frequent priority as the team priority
freq = student_bids.each_with_object(Hash.new(0)) do |v, h|
h[v] += 1
end
topic_bids << {topic_id: topic.id, priority: student_bids.max_by {|v| freq[v] }} unless freq.empty?
end
topic_bids.sort! {|b| b[:priority] }
team_bids << {team_id: team.id, bids: topic_bids}
end
</pre>

Used snake case naming convention.
Removed and condition inside if and converted it to nested if condition check.
Replaced inject with each_with_obj.

Before:

<pre>
def auto_merge_teams(unassignedTeams, _finalTeamTopics)
assignment = Assignment.find(params[:id])
# Sort unassigned
unassignedTeams = Team.where(id: unassignedTeams).sort_by {|t| !t.users.size }
unassignedTeams.each do |team|
sortedBids = Bid.where(user_id: team.id).sort_by(&:priority) # Get priority for each unassignmed team
sortedBids.each do |b|
# SignedUpTeam.where(:topic=>b.topic_id).first.team_id
winningTeam = SignedUpTeam.where(topic: b.topic_id).first.team_id
next unless TeamsUser.where(team_id: winningTeam).size + team.users.size <= assignment.max_team_size # If the team can be merged to a bigger team
TeamsUser.where(team_id: team.id).update_all(team_id: winningTeam)
Bid.delete_all(user_id: team.id)
Team.delete(team.id)
break
end
end
end
</pre>

After:

<pre>
before_action :fetch_assignment, only: [:auto_merge_teams]
before_action :sort_unassigned_teams, only: [:auto_merge_teams]
def auto_merge_teams(unassigned_teams, _final_team_topics)
# Sort unassigned

unassigned_teams.each do |team|
sorted_bids = Bid.where(user_id: team.id).sort_by(&:priority) # Get priority for each unassigned team
sorted_bids.each do |b|
# SignedUpTeam.where(:topic=>b.topic_id).first.team_id
winning_team = SignedUpTeam.where(topic: b.topic_id).first.team_id
next unless TeamsUser.where(team_id: winning_team).size + team.users.size <= assignment.max_team_size # If the team can be merged to a bigger team
TeamsUser.where(team_id: team.id).update_all(team_id: winning_team)
Bid.delete_all(user_id: team.id)
Team.delete(team.id)
break
end
end
end
def fetch_assignment
assignment = Assignment.find(params[:id])
end

def sort_unassigned_teams
unassigned_teams = Team.where(id: unassigned_teams).sort_by {|t| !t.users.size }
end
end
</pre>

Split the function into smaller pieces to keep up with coding conventions.

===Test Cases===
Initially, the lottery controller had only one test case: for the action run_intelligent_bid.
We added one more test case for run_intelligent_bid and also added test cases for all the other actions in the controller.

1. For the action run_intelligent_assignmnent, we have two test cases:
* webservice call should be successful
This is to check if the web service is getting called. But the URL given in the code is currently is of a web service that is currently down. Hence for testing purposes we have used a dummy URL.
This can be replaced with the correct URL to the web service when it becomes available in the future.

* should return json response
This test case checks if the response from the web service is in JSON format or not.

2. For the action run_intelligent_bid, we have the following test cases: 
*should do intelligent assignment 
This was an already existing test case. It tests whether the assignment received is intelligent or not. 
* should exit gracefully when assignment not intelligent 
This checks if the control redirects to main page in case the assignment received is not intelligent. 

3. For the action create_new_teams_for_bidding_response, we have the following test cases: 
* should create team and return teamid 
This test checks if the method is creating the team for bidding by taking in the assignment as parameter. 

4. For the action auto_merge_teams, we have written the following test cases: 
* sorts the unassigned teams 
This test case checks whether the method is able to sort teams which have not been assigned to any assignments yet.

== Conclusions ==
As a result of our work, the code quality of the controller lottery_controller.rb has improved a lot. Code Climate has given it the highest possible rating. The original code had a code climate rating of F. We worked on all the issues pointed out by code climate and and improved the rating to A. 
Initially, there was only one test case and only one of the methods in the controller was covered. We have also added RSpec test cases for all the methods in the the controller and hence the test coverage has increased. 
This was a very good learning experience. We learnt how to write test cases in RSpec and got a chance to contribute to Open Source Software. Another major take away from the project was the chance that we got to read and understand code written by other people. This is very important skill to have when you work in the industry and can be sometimes more difficult than writing code from scratch.

CSC/ECE 517 Fall 2016/E1658. Refractor lottery controller.rb and write integration tests

2016-11-08T01:53:40Z

Aanilku: /* Test Cases */

CSC/ECE 517 Fall 2016/E1658. Refractor lottery controller.rb and write integration tests

2016-11-08T01:46:56Z

Aanilku: /* Test Cases */

===Expertiza Background===
Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. It allows students to review each other’s work and improve their work upon this feedback.

===Description of Current Project===
The following is an Expertiza based OSS project which deals primarily with the lottery_controller.rb file. It focusses on refactoring some of the more complex methods, modifying some of the language to make it more Ruby friendly, removing some redundant code. The goal of this project is to attempt to make this part of the application easier to read and maintain.
The lottery_controller contains all of the logic for running the lottery. Code climate is used in this project to detect various issues such as high cyclomatic complexity, bad naming, etc.

===Changes needed===
Fix following issues mentioned below:
* Cyclomatic complexity for run_intelligent_bid is too high.
* Perceived complexity for run_intelligent_bid is too high.
* Use snake_case for variable names.
* Avoid more than 3 levels of block nesting.

===Changes performed===
The code was refactored and its Code Climate rating improved from F to A.

Before Refractoring:
[[File:Ccbefore.png|frame|left]]

After Refractoring:
[[File:Ccscafter.png|frame|left]]

* Cyclomatic complexity for run_intelligent_bid and other methods is greatly reduced.
* Perceived complexity for run_intelligent_bid is also reduced.
* snake_case are used for variable names.
* More than 3 levels of block nesting is avoided.

Before:
<pre>
if bid_record.nil?
bids << 0
else
bids << bid_record.priority ||= 0
end
</pre>

After:
<pre>
bids << bid_record.nil? ? 0 : bid_record.priority ||= 0
</pre>
Assignment using if condition was changed to conditional operator

Before:

<pre>
assignment = Assignment.find_by_id(params[:id])
</pre>

After:

<pre>
assignment = Assignment.find_by(id: params[:id])
</pre>
Changed to find_by from find_by_id

Before:

<pre>
response = RestClient.post url, data.to_json, :content_type => :json, :accept => :json
</pre>

After:

<pre>
response = RestClient.post url, data.to_json, content_type: :json, accept: :json
</pre>
Changed to the latest ruby convention for HashMaps

Before:

<pre>
def create_new_teams_for_bidding_response(teams, assignment)
teams.each_with_index do |user_ids, index|
new_team = AssignmentTeam.create(name: assignment.name + '_Team' + rand(1000).to_s,
parent_id: assignment.id,
type: 'AssignmentTeam')
parent = TeamNode.create(parent_id: assignment.id, node_object_id: new_team.id)
user_ids.each do |user_id|
team_user = TeamsUser.where(user_id: user_id, team_id: new_team.id).first rescue nil
team_user = TeamsUser.create(user_id: user_id, team_id: new_team.id) if team_user.nil?
TeamUserNode.create(parent_id: parent.id, node_object_id: team_user.id)
end
end
end
</pre>

After:

<pre>
def create_new_teams_for_bidding_response(teams, assignment)
teams.each_with_index do |user_ids|
new_team = AssignmentTeam.create(name: assignment.name + '_Team' + rand(1000).to_s,
parent_id: assignment.id,
type: 'AssignmentTeam')
parent = TeamNode.create(parent_id: assignment.id, node_object_id: new_team.id)
user_ids.each do |user_id|
team_user = TeamsUser.where(user_id: user_id, team_id: new_team.id).first rescue nil
team_user = TeamsUser.create(user_id: user_id, team_id: new_team.id) if team_user.nil?
TeamUserNode.create(parent_id: parent.id, node_object_id: team_user.id)
end
end
</pre>
Removed unused variables

Before:

<pre>
unless Assignment.find_by_id(params[:id]).is_intelligent # if the assignment is intelligent then redirect to the tree display list
flash[:error] = "This action not allowed. The assignment " + Assignment.find_by_id(params[:id]).name + " does not enabled intelligent assignments."
</pre>

After:

<pre>
unless Assignment.find_by(id: params[:id]).is_intelligent # if the assignment is intelligent then redirect to the tree display list
flash[:error] = "This action not allowed. The assignment " + Assignment.find_by(id: params[:id]).name + " does not enabled intelligent assignments."
</pre>
Changed find_by_id to find_by

Before:

<pre>
unassignedTeams = AssignmentTeam.where(parent_id: params[:id]).reject {|t| !SignedUpTeam.where(team_id: t.id).empty?}
unassignedTeams.sort! {|t1, t2| TeamsUser.where(team_id: t2.id).size <=> TeamsUser.where(team_id: t1.id).size}
team_bids = []
unassignedTeams.each do |team|
topic_bids = []
sign_up_topics.each do |topic|
student_bids = []
TeamsUser.where(team_id: team.id).each do |s|
student_bid = Bid.where(user_id: s.user_id, topic_id: topic.id).first rescue nil
if !student_bid.nil? and !student_bid.priority.nil?
student_bids << student_bid.priority
end
end
#takes the most frequent priority as the team priority
freq = student_bids.inject(Hash.new(0)) { |h,v| h[v] += 1; h}
topic_bids << {topic_id: topic.id, priority: student_bids.max_by { |v| freq[v] }} unless freq.empty?
end
topic_bids.sort! {|b| b[:priority]}
team_bids << {team_id: team.id, bids: topic_bids}
end
</pre>

After:
<pre>
unassigned_teams = AssignmentTeam.where(parent_id: params[:id]).reject {|t| !SignedUpTeam.where(team_id: t.id).empty? }
unassigned_teams.sort! {|t1, t2| TeamsUser.where(team_id: t2.id).size <=> TeamsUser.where(team_id: t1.id).size }
team_bids = []
unassigned_teams.each do |team|
topic_bids = []
sign_up_topics.each do |topic|
student_bids = []
TeamsUser.where(team_id: team.id).each do |s|
student_bid = Bid.where(user_id: s.user_id, topic_id: topic.id).first rescue nil
if !student_bid.nil?
if !student_bid.priority.nil?
student_bids << student_bid.priority
end
end
# takes the most frequent priority as the team priority
freq = student_bids.each_with_object(Hash.new(0)) do |v, h|
h[v] += 1
end
topic_bids << {topic_id: topic.id, priority: student_bids.max_by {|v| freq[v] }} unless freq.empty?
end
topic_bids.sort! {|b| b[:priority] }
team_bids << {team_id: team.id, bids: topic_bids}
end
</pre>

Used snake case naming convention.
Removed and condition inside if and converted it to nested if condition check.
Replaced inject with each_with_obj.

Before:

<pre>
def auto_merge_teams(unassignedTeams, _finalTeamTopics)
assignment = Assignment.find(params[:id])
# Sort unassigned
unassignedTeams = Team.where(id: unassignedTeams).sort_by {|t| !t.users.size }
unassignedTeams.each do |team|
sortedBids = Bid.where(user_id: team.id).sort_by(&:priority) # Get priority for each unassignmed team
sortedBids.each do |b|
# SignedUpTeam.where(:topic=>b.topic_id).first.team_id
winningTeam = SignedUpTeam.where(topic: b.topic_id).first.team_id
next unless TeamsUser.where(team_id: winningTeam).size + team.users.size <= assignment.max_team_size # If the team can be merged to a bigger team
TeamsUser.where(team_id: team.id).update_all(team_id: winningTeam)
Bid.delete_all(user_id: team.id)
Team.delete(team.id)
break
end
end
end
</pre>

After:

<pre>
before_action :fetch_assignment, only: [:auto_merge_teams]
before_action :sort_unassigned_teams, only: [:auto_merge_teams]
def auto_merge_teams(unassigned_teams, _final_team_topics)
# Sort unassigned

unassigned_teams.each do |team|
sorted_bids = Bid.where(user_id: team.id).sort_by(&:priority) # Get priority for each unassigned team
sorted_bids.each do |b|
# SignedUpTeam.where(:topic=>b.topic_id).first.team_id
winning_team = SignedUpTeam.where(topic: b.topic_id).first.team_id
next unless TeamsUser.where(team_id: winning_team).size + team.users.size <= assignment.max_team_size # If the team can be merged to a bigger team
TeamsUser.where(team_id: team.id).update_all(team_id: winning_team)
Bid.delete_all(user_id: team.id)
Team.delete(team.id)
break
end
end
end
def fetch_assignment
assignment = Assignment.find(params[:id])
end

def sort_unassigned_teams
unassigned_teams = Team.where(id: unassigned_teams).sort_by {|t| !t.users.size }
end
end
</pre>

Split the function into smaller pieces to keep up with coding conventions.

===Test Cases===
Initially, the lottery controller had only one test case: for the action run_intelligent_bid.
We added one more test case for run_intelligent_bid and also added test cases for all the other actions in the controller.

* For the action run_intelligent_assignmnent, we have two test cases: 
1. webservice call should be successful 
This is to check if the web service is getting called. But the URL given in the code is currently is of a web service that is currently down. Hence for testing purposes we have used a dummy URL.
This can be replaced with the correct URL to the web service when it becomes available in the future. 

2. should return json response 
This test case checks if the response from the web service is in JSON format or not.

* For the action run_intelligent_bid, we have the following test cases: 
1.should do intelligent assignment 
This was an already existing test case. It tests whether the assignment received is intelligent or not. 
2. should exit gracefully when assignment not intelligent 
This checks if the control redirects to main page in case the assignment received is not intelligent. 

* For the action create_new_teams_for_bidding_response, we have the following test cases: 
1. should create team and return teamid 
This test checks if the method is creating the team for bidding by taking in the assignment as parameter. 

* For the action auto_merge_teams, we have written the following test cases: 
1. sorts the unassigned teams 
This test case checks whether the method is able to sort teams which have not been assigned to any assignments yet.

CSC/ECE 517 Fall 2016/E1658. Refractor lottery controller.rb and write integration tests

2016-11-08T01:46:12Z

Aanilku: /* Changes performed */

===Expertiza Background===
Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. It allows students to review each other’s work and improve their work upon this feedback.

===Description of Current Project===
The following is an Expertiza based OSS project which deals primarily with the lottery_controller.rb file. It focusses on refactoring some of the more complex methods, modifying some of the language to make it more Ruby friendly, removing some redundant code. The goal of this project is to attempt to make this part of the application easier to read and maintain.
The lottery_controller contains all of the logic for running the lottery. Code climate is used in this project to detect various issues such as high cyclomatic complexity, bad naming, etc.

===Changes needed===
Fix following issues mentioned below:
* Cyclomatic complexity for run_intelligent_bid is too high.
* Perceived complexity for run_intelligent_bid is too high.
* Use snake_case for variable names.
* Avoid more than 3 levels of block nesting.

===Changes performed===
The code was refactored and its Code Climate rating improved from F to A.

Before Refractoring:
[[File:Ccbefore.png|frame|left]]

After Refractoring:
[[File:Ccscafter.png|frame|left]]

* Cyclomatic complexity for run_intelligent_bid and other methods is greatly reduced.
* Perceived complexity for run_intelligent_bid is also reduced.
* snake_case are used for variable names.
* More than 3 levels of block nesting is avoided.

Before:
<pre>
if bid_record.nil?
bids << 0
else
bids << bid_record.priority ||= 0
end
</pre>

After:
<pre>
bids << bid_record.nil? ? 0 : bid_record.priority ||= 0
</pre>
Assignment using if condition was changed to conditional operator

Before:

<pre>
assignment = Assignment.find_by_id(params[:id])
</pre>

After:

<pre>
assignment = Assignment.find_by(id: params[:id])
</pre>
Changed to find_by from find_by_id

Before:

<pre>
response = RestClient.post url, data.to_json, :content_type => :json, :accept => :json
</pre>

After:

<pre>
response = RestClient.post url, data.to_json, content_type: :json, accept: :json
</pre>
Changed to the latest ruby convention for HashMaps

Before:

<pre>
def create_new_teams_for_bidding_response(teams, assignment)
teams.each_with_index do |user_ids, index|
new_team = AssignmentTeam.create(name: assignment.name + '_Team' + rand(1000).to_s,
parent_id: assignment.id,
type: 'AssignmentTeam')
parent = TeamNode.create(parent_id: assignment.id, node_object_id: new_team.id)
user_ids.each do |user_id|
team_user = TeamsUser.where(user_id: user_id, team_id: new_team.id).first rescue nil
team_user = TeamsUser.create(user_id: user_id, team_id: new_team.id) if team_user.nil?
TeamUserNode.create(parent_id: parent.id, node_object_id: team_user.id)
end
end
end
</pre>

After:

<pre>
def create_new_teams_for_bidding_response(teams, assignment)
teams.each_with_index do |user_ids|
new_team = AssignmentTeam.create(name: assignment.name + '_Team' + rand(1000).to_s,
parent_id: assignment.id,
type: 'AssignmentTeam')
parent = TeamNode.create(parent_id: assignment.id, node_object_id: new_team.id)
user_ids.each do |user_id|
team_user = TeamsUser.where(user_id: user_id, team_id: new_team.id).first rescue nil
team_user = TeamsUser.create(user_id: user_id, team_id: new_team.id) if team_user.nil?
TeamUserNode.create(parent_id: parent.id, node_object_id: team_user.id)
end
end
</pre>
Removed unused variables

Before:

<pre>
unless Assignment.find_by_id(params[:id]).is_intelligent # if the assignment is intelligent then redirect to the tree display list
flash[:error] = "This action not allowed. The assignment " + Assignment.find_by_id(params[:id]).name + " does not enabled intelligent assignments."
</pre>

After:

<pre>
unless Assignment.find_by(id: params[:id]).is_intelligent # if the assignment is intelligent then redirect to the tree display list
flash[:error] = "This action not allowed. The assignment " + Assignment.find_by(id: params[:id]).name + " does not enabled intelligent assignments."
</pre>
Changed find_by_id to find_by

Before:

<pre>
unassignedTeams = AssignmentTeam.where(parent_id: params[:id]).reject {|t| !SignedUpTeam.where(team_id: t.id).empty?}
unassignedTeams.sort! {|t1, t2| TeamsUser.where(team_id: t2.id).size <=> TeamsUser.where(team_id: t1.id).size}
team_bids = []
unassignedTeams.each do |team|
topic_bids = []
sign_up_topics.each do |topic|
student_bids = []
TeamsUser.where(team_id: team.id).each do |s|
student_bid = Bid.where(user_id: s.user_id, topic_id: topic.id).first rescue nil
if !student_bid.nil? and !student_bid.priority.nil?
student_bids << student_bid.priority
end
end
#takes the most frequent priority as the team priority
freq = student_bids.inject(Hash.new(0)) { |h,v| h[v] += 1; h}
topic_bids << {topic_id: topic.id, priority: student_bids.max_by { |v| freq[v] }} unless freq.empty?
end
topic_bids.sort! {|b| b[:priority]}
team_bids << {team_id: team.id, bids: topic_bids}
end
</pre>

After:
<pre>
unassigned_teams = AssignmentTeam.where(parent_id: params[:id]).reject {|t| !SignedUpTeam.where(team_id: t.id).empty? }
unassigned_teams.sort! {|t1, t2| TeamsUser.where(team_id: t2.id).size <=> TeamsUser.where(team_id: t1.id).size }
team_bids = []
unassigned_teams.each do |team|
topic_bids = []
sign_up_topics.each do |topic|
student_bids = []
TeamsUser.where(team_id: team.id).each do |s|
student_bid = Bid.where(user_id: s.user_id, topic_id: topic.id).first rescue nil
if !student_bid.nil?
if !student_bid.priority.nil?
student_bids << student_bid.priority
end
end
# takes the most frequent priority as the team priority
freq = student_bids.each_with_object(Hash.new(0)) do |v, h|
h[v] += 1
end
topic_bids << {topic_id: topic.id, priority: student_bids.max_by {|v| freq[v] }} unless freq.empty?
end
topic_bids.sort! {|b| b[:priority] }
team_bids << {team_id: team.id, bids: topic_bids}
end
</pre>

Used snake case naming convention.
Removed and condition inside if and converted it to nested if condition check.
Replaced inject with each_with_obj.

Before:

<pre>
def auto_merge_teams(unassignedTeams, _finalTeamTopics)
assignment = Assignment.find(params[:id])
# Sort unassigned
unassignedTeams = Team.where(id: unassignedTeams).sort_by {|t| !t.users.size }
unassignedTeams.each do |team|
sortedBids = Bid.where(user_id: team.id).sort_by(&:priority) # Get priority for each unassignmed team
sortedBids.each do |b|
# SignedUpTeam.where(:topic=>b.topic_id).first.team_id
winningTeam = SignedUpTeam.where(topic: b.topic_id).first.team_id
next unless TeamsUser.where(team_id: winningTeam).size + team.users.size <= assignment.max_team_size # If the team can be merged to a bigger team
TeamsUser.where(team_id: team.id).update_all(team_id: winningTeam)
Bid.delete_all(user_id: team.id)
Team.delete(team.id)
break
end
end
end
</pre>

After:

<pre>
before_action :fetch_assignment, only: [:auto_merge_teams]
before_action :sort_unassigned_teams, only: [:auto_merge_teams]
def auto_merge_teams(unassigned_teams, _final_team_topics)
# Sort unassigned

unassigned_teams.each do |team|
sorted_bids = Bid.where(user_id: team.id).sort_by(&:priority) # Get priority for each unassigned team
sorted_bids.each do |b|
# SignedUpTeam.where(:topic=>b.topic_id).first.team_id
winning_team = SignedUpTeam.where(topic: b.topic_id).first.team_id
next unless TeamsUser.where(team_id: winning_team).size + team.users.size <= assignment.max_team_size # If the team can be merged to a bigger team
TeamsUser.where(team_id: team.id).update_all(team_id: winning_team)
Bid.delete_all(user_id: team.id)
Team.delete(team.id)
break
end
end
end
def fetch_assignment
assignment = Assignment.find(params[:id])
end

def sort_unassigned_teams
unassigned_teams = Team.where(id: unassigned_teams).sort_by {|t| !t.users.size }
end
end
</pre>

Split the function into smaller pieces to keep up with coding conventions.

===Test Cases===
Initially, the lottery controller had only one test case: for the action run_intelligent_bid.
We added one more test case for run_intelligent_bid and also added test cases for all the other actions in the controller.

For the action run_intelligent_assignmnent, we have two test cases: 
1. webservice call should be successful 
This is to check if the web service is getting called. But the URL given in the code is currently is of a web service that is currently down. Hence for testing purposes we have used a dummy URL.
This can be replaced with the correct URL to the web service when it becomes available in the future. 

2. should return json response 
This test case checks if the response from the web service is in JSON format or not.

For the action run_intelligent_bid, we have the following test cases: 
1.should do intelligent assignment 
This was an already existing test case. It tests whether the assignment received is intelligent or not. 
2. should exit gracefully when assignment not intelligent 
This checks if the control redirects to main page in case the assignment received is not intelligent. 

For the action create_new_teams_for_bidding_response, we have the following test cases: 
1. should create team and return teamid 
This test checks if the method is creating the team for bidding by taking in the assignment as parameter. 

For the action auto_merge_teams, we have written the following test cases: 
1. sorts the unassigned teams 
This test case checks whether the method is able to sort teams which have not been assigned to any assignments yet.

CSC/ECE 517 Fall 2016/E1658. Refractor lottery controller.rb and write integration tests

2016-11-08T01:45:14Z

Aanilku: /* Changes performed */

===Expertiza Background===
Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. It allows students to review each other’s work and improve their work upon this feedback.

===Description of Current Project===
The following is an Expertiza based OSS project which deals primarily with the lottery_controller.rb file. It focusses on refactoring some of the more complex methods, modifying some of the language to make it more Ruby friendly, removing some redundant code. The goal of this project is to attempt to make this part of the application easier to read and maintain.
The lottery_controller contains all of the logic for running the lottery. Code climate is used in this project to detect various issues such as high cyclomatic complexity, bad naming, etc.

===Changes needed===
Fix following issues mentioned below:
* Cyclomatic complexity for run_intelligent_bid is too high.
* Perceived complexity for run_intelligent_bid is too high.
* Use snake_case for variable names.
* Avoid more than 3 levels of block nesting.

===Changes performed===
The code was refactored and its Code Climate rating improved from F to A.

Before Refractoring:
[[File:Ccbefore.png|frame|left]]

After Refractoring:
[[File:Ccscafter.png|frame|left]]

* Cyclomatic complexity for run_intelligent_bid and other methods is greatly reduced.
* Perceived complexity for run_intelligent_bid is also reduced.
* snake_case are used for variable names.
* More than 3 levels of block nesting is avoided.

Before:
<pre>
if bid_record.nil?
bids << 0
else
bids << bid_record.priority ||= 0
end
</pre>

After:
<pre>
bids << bid_record.nil? ? 0 : bid_record.priority ||= 0
</pre>
Assignment using if condition was changed to conditional operator

Before:

<pre>
assignment = Assignment.find_by_id(params[:id])
</pre>

After:

<pre>
assignment = Assignment.find_by(id: params[:id])
</pre>
Changed to find_by from find_by_id

Before:

<pre>
response = RestClient.post url, data.to_json, :content_type => :json, :accept => :json
</pre>

After:

<pre>
response = RestClient.post url, data.to_json, content_type: :json, accept: :json
</pre>
Changed to the latest ruby convention for HashMaps

Before:

<pre>
def create_new_teams_for_bidding_response(teams, assignment)
teams.each_with_index do |user_ids, index|
new_team = AssignmentTeam.create(name: assignment.name + '_Team' + rand(1000).to_s,
parent_id: assignment.id,
type: 'AssignmentTeam')
parent = TeamNode.create(parent_id: assignment.id, node_object_id: new_team.id)
user_ids.each do |user_id|
team_user = TeamsUser.where(user_id: user_id, team_id: new_team.id).first rescue nil
team_user = TeamsUser.create(user_id: user_id, team_id: new_team.id) if team_user.nil?
TeamUserNode.create(parent_id: parent.id, node_object_id: team_user.id)
end
end
end
</pre>

After:

<pre>
def create_new_teams_for_bidding_response(teams, assignment)
teams.each_with_index do |user_ids|
new_team = AssignmentTeam.create(name: assignment.name + '_Team' + rand(1000).to_s,
parent_id: assignment.id,
type: 'AssignmentTeam')
parent = TeamNode.create(parent_id: assignment.id, node_object_id: new_team.id)
user_ids.each do |user_id|
team_user = TeamsUser.where(user_id: user_id, team_id: new_team.id).first rescue nil
team_user = TeamsUser.create(user_id: user_id, team_id: new_team.id) if team_user.nil?
TeamUserNode.create(parent_id: parent.id, node_object_id: team_user.id)
end
end
</pre>
Removed unused variables

Before:

<pre>
unless Assignment.find_by_id(params[:id]).is_intelligent # if the assignment is intelligent then redirect to the tree display list
flash[:error] = "This action not allowed. The assignment " + Assignment.find_by_id(params[:id]).name + " does not enabled intelligent assignments."
</pre>

After:

<pre>
unless Assignment.find_by(id: params[:id]).is_intelligent # if the assignment is intelligent then redirect to the tree display list
flash[:error] = "This action not allowed. The assignment " + Assignment.find_by(id: params[:id]).name + " does not enabled intelligent assignments."
</pre>
Changed find_by_id to find_by

Before:

<pre>
unassignedTeams = AssignmentTeam.where(parent_id: params[:id]).reject {|t| !SignedUpTeam.where(team_id: t.id).empty?}
unassignedTeams.sort! {|t1, t2| TeamsUser.where(team_id: t2.id).size <=> TeamsUser.where(team_id: t1.id).size}
team_bids = []
unassignedTeams.each do |team|
topic_bids = []
sign_up_topics.each do |topic|
student_bids = []
TeamsUser.where(team_id: team.id).each do |s|
student_bid = Bid.where(user_id: s.user_id, topic_id: topic.id).first rescue nil
if !student_bid.nil? and !student_bid.priority.nil?
student_bids << student_bid.priority
end
end
#takes the most frequent priority as the team priority
freq = student_bids.inject(Hash.new(0)) { |h,v| h[v] += 1; h}
topic_bids << {topic_id: topic.id, priority: student_bids.max_by { |v| freq[v] }} unless freq.empty?
end
topic_bids.sort! {|b| b[:priority]}
team_bids << {team_id: team.id, bids: topic_bids}
end
</pre>

After:
<pre>
unassigned_teams = AssignmentTeam.where(parent_id: params[:id]).reject {|t| !SignedUpTeam.where(team_id: t.id).empty? }
unassigned_teams.sort! {|t1, t2| TeamsUser.where(team_id: t2.id).size <=> TeamsUser.where(team_id: t1.id).size }
team_bids = []
unassigned_teams.each do |team|
topic_bids = []
sign_up_topics.each do |topic|
student_bids = []
TeamsUser.where(team_id: team.id).each do |s|
student_bid = Bid.where(user_id: s.user_id, topic_id: topic.id).first rescue nil
if !student_bid.nil?
if !student_bid.priority.nil?
student_bids << student_bid.priority
end
end
# takes the most frequent priority as the team priority
freq = student_bids.each_with_object(Hash.new(0)) do |v, h|
h[v] += 1
end
topic_bids << {topic_id: topic.id, priority: student_bids.max_by {|v| freq[v] }} unless freq.empty?
end
topic_bids.sort! {|b| b[:priority] }
team_bids << {team_id: team.id, bids: topic_bids}
end
</pre>

Used snake case naming convention.
Removed and condition inside if and converted it to nested if condition check.
Replaced inject with each_with_obj.

Before:

<pre>
def auto_merge_teams(unassignedTeams, _finalTeamTopics)
assignment = Assignment.find(params[:id])
# Sort unassigned
unassignedTeams = Team.where(id: unassignedTeams).sort_by {|t| !t.users.size }
unassignedTeams.each do |team|
sortedBids = Bid.where(user_id: team.id).sort_by(&:priority) # Get priority for each unassignmed team
sortedBids.each do |b|
# SignedUpTeam.where(:topic=>b.topic_id).first.team_id
winningTeam = SignedUpTeam.where(topic: b.topic_id).first.team_id
next unless TeamsUser.where(team_id: winningTeam).size + team.users.size <= assignment.max_team_size # If the team can be merged to a bigger team
TeamsUser.where(team_id: team.id).update_all(team_id: winningTeam)
Bid.delete_all(user_id: team.id)
Team.delete(team.id)
break
end
end
end
</pre>

After:

<pre>
before_action :fetch_assignment, only: [:auto_merge_teams]
before_action :sort_unassigned_teams, only: [:auto_merge_teams]
def auto_merge_teams(unassigned_teams, _final_team_topics)
# Sort unassigned

unassigned_teams.each do |team|
sorted_bids = Bid.where(user_id: team.id).sort_by(&:priority) # Get priority for each unassignmed team
sorted_bids.each do |b|
# SignedUpTeam.where(:topic=>b.topic_id).first.team_id
winning_team = SignedUpTeam.where(topic: b.topic_id).first.team_id
next unless TeamsUser.where(team_id: winning_team).size + team.users.size <= assignment.max_team_size # If the team can be merged to a bigger team
TeamsUser.where(team_id: team.id).update_all(team_id: winning_team)
Bid.delete_all(user_id: team.id)
Team.delete(team.id)
break
end
end
end
def fetch_assignment
assignment = Assignment.find(params[:id])
end

def sort_unassigned_teams
unassigned_teams = Team.where(id: unassigned_teams).sort_by {|t| !t.users.size }
end
end
</pre>

Split the function into smaller pieces to keep up with coding conventions.

===Test Cases===
Initially, the lottery controller had only one test case: for the action run_intelligent_bid.
We added one more test case for run_intelligent_bid and also added test cases for all the other actions in the controller.

For the action run_intelligent_assignmnent, we have two test cases: 
1. webservice call should be successful 
This is to check if the web service is getting called. But the URL given in the code is currently is of a web service that is currently down. Hence for testing purposes we have used a dummy URL.
This can be replaced with the correct URL to the web service when it becomes available in the future. 

2. should return json response 
This test case checks if the response from the web service is in JSON format or not.

For the action run_intelligent_bid, we have the following test cases: 
1.should do intelligent assignment 
This was an already existing test case. It tests whether the assignment received is intelligent or not. 
2. should exit gracefully when assignment not intelligent 
This checks if the control redirects to main page in case the assignment received is not intelligent. 

For the action create_new_teams_for_bidding_response, we have the following test cases: 
1. should create team and return teamid 
This test checks if the method is creating the team for bidding by taking in the assignment as parameter. 

For the action auto_merge_teams, we have written the following test cases: 
1. sorts the unassigned teams 
This test case checks whether the method is able to sort teams which have not been assigned to any assignments yet.

CSC/ECE 517 Fall 2016/E1658. Refractor lottery controller.rb and write integration tests

2016-11-05T04:25:01Z

Aanilku: /* Test Cases */

===Expertiza Background===
Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. It allows students to review each other’s work and improve their work upon this feedback.

===Description of Current Project===
The following is an Expertiza based OSS project which deals primarily with the lottery_controller.rb file. It focusses on refactoring some of the more complex methods, modifying some of the language to make it more Ruby friendly, removing some redundant code. The goal of this project is to attempt to make this part of the application easier to read and maintain.
The lottery_controller contains all of the logic for running the lottery. Code climate is used in this project to detect various issues such as high cyclomatic complexity, bad naming, etc.

===Changes needed===
Fix following issues mentioned below:
* Cyclomatic complexity for run_intelligent_bid is too high.
* Perceived complexity for run_intelligent_bid is too high.
* Use snake_case for variable names.
* Avoid more than 3 levels of block nesting.

===Changes performed===
The code was refactored and its Code Climate rating improved from F to A.

Before Refractoring:
[[File:Ccbefore.png|frame|left]]

After Refractoring:
[[File:Ccscafter.png|frame|left]]

* Cyclomatic complexity for run_intelligent_bid and other methods is greatly reduced.
* Perceived complexity for run_intelligent_bid is also reduced.
* snake_case are used for variable names.
* More than 3 levels of block nesting is avoided.

Before:

if bid_record.nil?
bids << 0
else
bids << bid_record.priority ||= 0
end

After:

bids << bid_record.nil? ? 0 : bid_record.priority ||= 0

Assignment using if condition was changed to conditional operator

Before:
assignment = Assignment.find_by_id(params[:id])

After:
assignment = Assignment.find_by(id: params[:id])

Changed to find_by from find_by_id

Before:

response = RestClient.post url, data.to_json, :content_type => :json, :accept => :json

After:

response = RestClient.post url, data.to_json, content_type: :json, accept: :json

Changed to the latest ruby convention for HashMaps

Before:

def create_new_teams_for_bidding_response(teams, assignment)
teams.each_with_index do |user_ids, index|
new_team = AssignmentTeam.create(name: assignment.name + '_Team' + rand(1000).to_s,
parent_id: assignment.id,
type: 'AssignmentTeam')
parent = TeamNode.create(parent_id: assignment.id, node_object_id: new_team.id)
user_ids.each do |user_id|
team_user = TeamsUser.where(user_id: user_id, team_id: new_team.id).first rescue nil
team_user = TeamsUser.create(user_id: user_id, team_id: new_team.id) if team_user.nil?
TeamUserNode.create(parent_id: parent.id, node_object_id: team_user.id)
end
end
end

After:

def create_new_teams_for_bidding_response(teams, assignment)
teams.each_with_index do |user_ids|
new_team = AssignmentTeam.create(name: assignment.name + '_Team' + rand(1000).to_s,
parent_id: assignment.id,
type: 'AssignmentTeam')
parent = TeamNode.create(parent_id: assignment.id, node_object_id: new_team.id)
user_ids.each do |user_id|
team_user = TeamsUser.where(user_id: user_id, team_id: new_team.id).first rescue nil
team_user = TeamsUser.create(user_id: user_id, team_id: new_team.id) if team_user.nil?
TeamUserNode.create(parent_id: parent.id, node_object_id: team_user.id)
end
end

Removed unused variables

Before:

unless Assignment.find_by_id(params[:id]).is_intelligent # if the assignment is intelligent then redirect to the tree display list
flash[:error] = "This action not allowed. The assignment " + Assignment.find_by_id(params[:id]).name + " does not enabled intelligent assignments."

After:

unless Assignment.find_by(id: params[:id]).is_intelligent # if the assignment is intelligent then redirect to the tree display list
flash[:error] = "This action not allowed. The assignment " + Assignment.find_by(id: params[:id]).name + " does not enabled intelligent assignments."

Changed find_by_id to find_by

Before:

unassignedTeams = AssignmentTeam.where(parent_id: params[:id]).reject {|t| !SignedUpTeam.where(team_id: t.id).empty?}
unassignedTeams.sort! {|t1, t2| TeamsUser.where(team_id: t2.id).size <=> TeamsUser.where(team_id: t1.id).size}
team_bids = []
unassignedTeams.each do |team|
topic_bids = []
sign_up_topics.each do |topic|
student_bids = []
TeamsUser.where(team_id: team.id).each do |s|
student_bid = Bid.where(user_id: s.user_id, topic_id: topic.id).first rescue nil
if !student_bid.nil? and !student_bid.priority.nil?
student_bids << student_bid.priority
end
end
#takes the most frequent priority as the team priority
freq = student_bids.inject(Hash.new(0)) { |h,v| h[v] += 1; h}
topic_bids << {topic_id: topic.id, priority: student_bids.max_by { |v| freq[v] }} unless freq.empty?
end
topic_bids.sort! {|b| b[:priority]}
team_bids << {team_id: team.id, bids: topic_bids}
end

After:

unassigned_teams = AssignmentTeam.where(parent_id: params[:id]).reject {|t| !SignedUpTeam.where(team_id: t.id).empty? }
unassigned_teams.sort! {|t1, t2| TeamsUser.where(team_id: t2.id).size <=> TeamsUser.where(team_id: t1.id).size }
team_bids = []
unassigned_teams.each do |team|
topic_bids = []
sign_up_topics.each do |topic|
student_bids = []
TeamsUser.where(team_id: team.id).each do |s|
student_bid = Bid.where(user_id: s.user_id, topic_id: topic.id).first rescue nil
if !student_bid.nil?
if !student_bid.priority.nil?
student_bids << student_bid.priority
end
end
# takes the most frequent priority as the team priority
freq = student_bids.each_with_object(Hash.new(0)) do |v, h|
h[v] += 1
end
topic_bids << {topic_id: topic.id, priority: student_bids.max_by {|v| freq[v] }} unless freq.empty?
end
topic_bids.sort! {|b| b[:priority] }
team_bids << {team_id: team.id, bids: topic_bids}
end

Used snake case naming convention.
Removed and condition inside if and converted it to nested if condition check.
Replaced inject with each_with_obj.

Before:

def auto_merge_teams(unassignedTeams, _finalTeamTopics)
assignment = Assignment.find(params[:id])
# Sort unassigned
unassignedTeams = Team.where(id: unassignedTeams).sort_by {|t| !t.users.size }
unassignedTeams.each do |team|
sortedBids = Bid.where(user_id: team.id).sort_by(&:priority) # Get priority for each unassignmed team
sortedBids.each do |b|
# SignedUpTeam.where(:topic=>b.topic_id).first.team_id
winningTeam = SignedUpTeam.where(topic: b.topic_id).first.team_id
next unless TeamsUser.where(team_id: winningTeam).size + team.users.size <= assignment.max_team_size # If the team can be merged to a bigger team
TeamsUser.where(team_id: team.id).update_all(team_id: winningTeam)
Bid.delete_all(user_id: team.id)
Team.delete(team.id)
break
end
end
end

After:

before_action :fetch_assignment, only: [:auto_merge_teams]
before_action :sort_unassigned_teams, only: [:auto_merge_teams]
def auto_merge_teams(unassigned_teams, _final_team_topics)
# Sort unassigned

unassigned_teams.each do |team|
sorted_bids = Bid.where(user_id: team.id).sort_by(&:priority) # Get priority for each unassignmed team
sorted_bids.each do |b|
# SignedUpTeam.where(:topic=>b.topic_id).first.team_id
winning_team = SignedUpTeam.where(topic: b.topic_id).first.team_id
next unless TeamsUser.where(team_id: winning_team).size + team.users.size <= assignment.max_team_size # If the team can be merged to a bigger team
TeamsUser.where(team_id: team.id).update_all(team_id: winning_team)
Bid.delete_all(user_id: team.id)
Team.delete(team.id)
break
end
end
end
def fetch_assignment
assignment = Assignment.find(params[:id])
end

def sort_unassigned_teams
unassigned_teams = Team.where(id: unassigned_teams).sort_by {|t| !t.users.size }
end
end

Split the function into smaller pieces to keep up with coding conventions.

===Test Cases===
Initially, the lottery controller had only one test case: for the action run_intelligent_bid.
We added one more test case for run_intelligent_bid and also added test cases for all the other actions in the controller.

For the action run_intelligent_assignmnent, we have two test cases: 
1. webservice call should be successful 
This is to check if the web service is getting called. But the URL given in the code is currently is of a web service that is currently down. Hence for testing purposes we have used a dummy URL.
This can be replaced with the correct URL to the web service when it becomes available in the future. 

2. should return json response 
This test case checks if the response from the web service is in JSON format or not.

For the action run_intelligent_bid, we have the following test cases: 
1.should do intelligent assignment 
This was an already existing test case. It tests whether the assignment received is intelligent or not. 
2. should exit gracefully when assignment not intelligent 
This checks if the control redirects to main page in case the assignment received is not intelligent. 

For the action create_new_teams_for_bidding_response, we have the following test cases: 
1. should create team and return teamid 
This test checks if the method is creating the team for bidding by taking in the assignment as parameter. 

For the action auto_merge_teams, we have written the following test cases: 
1. sorts the unassigned teams 
This test case checks whether the method is able to sort teams which have not been assigned to any assignments yet.

CSC/ECE 517 Fall 2016/E1658. Refractor lottery controller.rb and write integration tests

2016-11-04T23:36:43Z

Aanilku: /* Changes performed */

===Expertiza Background===
Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. It allows students to review each other’s work and improve their work upon this feedback.

===Description of Current Project===
The following is an Expertiza based OSS project which deals primarily with the lottery_controller.rb file. It focusses on refactoring some of the more complex methods, modifying some of the language to make it more Ruby friendly, removing some redundant code. The goal of this project is to attempt to make this part of the application easier to read and maintain.
The lottery_controller contains all of the logic for running the lottery. Code climate is used in this project to detect various issues such as high cyclomatic complexity, bad naming, etc.

===Changes needed===
Fix following issues mentioned below:
* Cyclomatic complexity for run_intelligent_bid is too high.
* Perceived complexity for run_intelligent_bid is too high.
* Use snake_case for variable names.
* Avoid more than 3 levels of block nesting.

===Changes performed===
The code was refactored and its Code Climate rating improved from F to A.

Before Refractoring:
[[File:Ccbefore.png|frame|left]]

After Refractoring:
[[File:Ccscafter.png|frame|left]]

* Cyclomatic complexity for run_intelligent_bid and other methods is greatly reduced.
* Perceived complexity for run_intelligent_bid is also reduced.
* snake_case are used for variable names.
* More than 3 levels of block nesting is avoided.

Before:

if bid_record.nil?
bids << 0
else
bids << bid_record.priority ||= 0
end

After:

bids << bid_record.nil? ? 0 : bid_record.priority ||= 0

Assignment using if condition was changed to conditional operator

Before:
assignment = Assignment.find_by_id(params[:id])

After:
assignment = Assignment.find_by(id: params[:id])

Changed to find_by from find_by_id

Before:

response = RestClient.post url, data.to_json, :content_type => :json, :accept => :json

After:

response = RestClient.post url, data.to_json, content_type: :json, accept: :json

Changed to the latest ruby convention for HashMaps

Before:

def create_new_teams_for_bidding_response(teams, assignment)
teams.each_with_index do |user_ids, index|
new_team = AssignmentTeam.create(name: assignment.name + '_Team' + rand(1000).to_s,
parent_id: assignment.id,
type: 'AssignmentTeam')
parent = TeamNode.create(parent_id: assignment.id, node_object_id: new_team.id)
user_ids.each do |user_id|
team_user = TeamsUser.where(user_id: user_id, team_id: new_team.id).first rescue nil
team_user = TeamsUser.create(user_id: user_id, team_id: new_team.id) if team_user.nil?
TeamUserNode.create(parent_id: parent.id, node_object_id: team_user.id)
end
end
end

After:

def create_new_teams_for_bidding_response(teams, assignment)
teams.each_with_index do |user_ids|
new_team = AssignmentTeam.create(name: assignment.name + '_Team' + rand(1000).to_s,
parent_id: assignment.id,
type: 'AssignmentTeam')
parent = TeamNode.create(parent_id: assignment.id, node_object_id: new_team.id)
user_ids.each do |user_id|
team_user = TeamsUser.where(user_id: user_id, team_id: new_team.id).first rescue nil
team_user = TeamsUser.create(user_id: user_id, team_id: new_team.id) if team_user.nil?
TeamUserNode.create(parent_id: parent.id, node_object_id: team_user.id)
end
end

Removed unused variables

Before:

unless Assignment.find_by_id(params[:id]).is_intelligent # if the assignment is intelligent then redirect to the tree display list
flash[:error] = "This action not allowed. The assignment " + Assignment.find_by_id(params[:id]).name + " does not enabled intelligent assignments."

After:

unless Assignment.find_by(id: params[:id]).is_intelligent # if the assignment is intelligent then redirect to the tree display list
flash[:error] = "This action not allowed. The assignment " + Assignment.find_by(id: params[:id]).name + " does not enabled intelligent assignments."

Changed find_by_id to find_by

Before:

unassignedTeams = AssignmentTeam.where(parent_id: params[:id]).reject {|t| !SignedUpTeam.where(team_id: t.id).empty?}
unassignedTeams.sort! {|t1, t2| TeamsUser.where(team_id: t2.id).size <=> TeamsUser.where(team_id: t1.id).size}
team_bids = []
unassignedTeams.each do |team|
topic_bids = []
sign_up_topics.each do |topic|
student_bids = []
TeamsUser.where(team_id: team.id).each do |s|
student_bid = Bid.where(user_id: s.user_id, topic_id: topic.id).first rescue nil
if !student_bid.nil? and !student_bid.priority.nil?
student_bids << student_bid.priority
end
end
#takes the most frequent priority as the team priority
freq = student_bids.inject(Hash.new(0)) { |h,v| h[v] += 1; h}
topic_bids << {topic_id: topic.id, priority: student_bids.max_by { |v| freq[v] }} unless freq.empty?
end
topic_bids.sort! {|b| b[:priority]}
team_bids << {team_id: team.id, bids: topic_bids}
end

After:

unassigned_teams = AssignmentTeam.where(parent_id: params[:id]).reject {|t| !SignedUpTeam.where(team_id: t.id).empty? }
unassigned_teams.sort! {|t1, t2| TeamsUser.where(team_id: t2.id).size <=> TeamsUser.where(team_id: t1.id).size }
team_bids = []
unassigned_teams.each do |team|
topic_bids = []
sign_up_topics.each do |topic|
student_bids = []
TeamsUser.where(team_id: team.id).each do |s|
student_bid = Bid.where(user_id: s.user_id, topic_id: topic.id).first rescue nil
if !student_bid.nil?
if !student_bid.priority.nil?
student_bids << student_bid.priority
end
end
# takes the most frequent priority as the team priority
freq = student_bids.each_with_object(Hash.new(0)) do |v, h|
h[v] += 1
end
topic_bids << {topic_id: topic.id, priority: student_bids.max_by {|v| freq[v] }} unless freq.empty?
end
topic_bids.sort! {|b| b[:priority] }
team_bids << {team_id: team.id, bids: topic_bids}
end

Used snake case naming convention.
Removed and condition inside if and converted it to nested if condition check.
Replaced inject with each_with_obj.

Before:

def auto_merge_teams(unassignedTeams, _finalTeamTopics)
assignment = Assignment.find(params[:id])
# Sort unassigned
unassignedTeams = Team.where(id: unassignedTeams).sort_by {|t| !t.users.size }
unassignedTeams.each do |team|
sortedBids = Bid.where(user_id: team.id).sort_by(&:priority) # Get priority for each unassignmed team
sortedBids.each do |b|
# SignedUpTeam.where(:topic=>b.topic_id).first.team_id
winningTeam = SignedUpTeam.where(topic: b.topic_id).first.team_id
next unless TeamsUser.where(team_id: winningTeam).size + team.users.size <= assignment.max_team_size # If the team can be merged to a bigger team
TeamsUser.where(team_id: team.id).update_all(team_id: winningTeam)
Bid.delete_all(user_id: team.id)
Team.delete(team.id)
break
end
end
end

After:

before_action :fetch_assignment, only: [:auto_merge_teams]
before_action :sort_unassigned_teams, only: [:auto_merge_teams]
def auto_merge_teams(unassigned_teams, _final_team_topics)
# Sort unassigned

unassigned_teams.each do |team|
sorted_bids = Bid.where(user_id: team.id).sort_by(&:priority) # Get priority for each unassignmed team
sorted_bids.each do |b|
# SignedUpTeam.where(:topic=>b.topic_id).first.team_id
winning_team = SignedUpTeam.where(topic: b.topic_id).first.team_id
next unless TeamsUser.where(team_id: winning_team).size + team.users.size <= assignment.max_team_size # If the team can be merged to a bigger team
TeamsUser.where(team_id: team.id).update_all(team_id: winning_team)
Bid.delete_all(user_id: team.id)
Team.delete(team.id)
break
end
end
end
def fetch_assignment
assignment = Assignment.find(params[:id])
end

def sort_unassigned_teams
unassigned_teams = Team.where(id: unassigned_teams).sort_by {|t| !t.users.size }
end
end

Split the function into smaller pieces to keep up with coding conventions.

===Test Cases===

CSC/ECE 517 Fall 2016/E1658. Refractor lottery controller.rb and write integration tests

2016-11-01T21:04:33Z

Aanilku: /* Changes performed */

===Expertiza Background===
Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. It allows students to review each other’s work and improve their work upon this feedback.

===Description of Current Project===
The following is an Expertiza based OSS project which deals primarily with the lottery_controller.rb file. It focusses on refactoring some of the more complex methods, modifying some of the language to make it more Ruby friendly, removing some redundant code. The goal of this project is to attempt to make this part of the application easier to read and maintain.
The lottery_controller contains all of the logic for running the lottery. Code climate is used in this project to detect various issues such as high cyclomatic complexity, bad naming, etc.

===Changes needed===
Fix following issues mentioned below:
* Cyclomatic complexity for run_intelligent_bid is too high.
* Perceived complexity for run_intelligent_bid is too high.
* Use snake_case for variable names.
* Avoid more than 3 levels of block nesting.

===Changes performed===
The code was refactored and its Code Climate rating improved from F to A.

Before Refractoring:
[[File:Ccbefore.png|frame|left]]

After Refractoring:
[[File:Ccscafter.png|frame|left]]

* Cyclomatic complexity for run_intelligent_bid and other methods is greatly reduced.
* Perceived complexity for run_intelligent_bid is also reduced.
* snake_case are used for variable names.
* More than 3 levels of block nesting is avoided.

Before:

if bid_record.nil?
bids << 0
else
bids << bid_record.priority ||= 0
end

After:

bids << bid_record.nil? ? 0 : bid_record.priority ||= 0

Assignment using if condition was changed to conditional operator

Before:
assignment = Assignment.find_by_id(params[:id])

After:
assignment = Assignment.find_by(id: params[:id])

Changed to find_by from find_by_id

Before:

response = RestClient.post url, data.to_json, :content_type => :json, :accept => :json

After:

response = RestClient.post url, data.to_json, content_type: :json, accept: :json

Changed to the latest ruby convention for HashMaps

Before:

def create_new_teams_for_bidding_response(teams, assignment)
teams.each_with_index do |user_ids, index|
new_team = AssignmentTeam.create(name: assignment.name + '_Team' + rand(1000).to_s,
parent_id: assignment.id,
type: 'AssignmentTeam')
parent = TeamNode.create(parent_id: assignment.id, node_object_id: new_team.id)
user_ids.each do |user_id|
team_user = TeamsUser.where(user_id: user_id, team_id: new_team.id).first rescue nil
team_user = TeamsUser.create(user_id: user_id, team_id: new_team.id) if team_user.nil?
TeamUserNode.create(parent_id: parent.id, node_object_id: team_user.id)
end
end
end

After:

def create_new_teams_for_bidding_response(teams, assignment)
teams.each_with_index do |user_ids|
new_team = AssignmentTeam.create(name: assignment.name + '_Team' + rand(1000).to_s,
parent_id: assignment.id,
type: 'AssignmentTeam')
parent = TeamNode.create(parent_id: assignment.id, node_object_id: new_team.id)
user_ids.each do |user_id|
team_user = TeamsUser.where(user_id: user_id, team_id: new_team.id).first rescue nil
team_user = TeamsUser.create(user_id: user_id, team_id: new_team.id) if team_user.nil?
TeamUserNode.create(parent_id: parent.id, node_object_id: team_user.id)
end
end

Removed unused variables

Before:

unless Assignment.find_by_id(params[:id]).is_intelligent # if the assignment is intelligent then redirect to the tree display list
flash[:error] = "This action not allowed. The assignment " + Assignment.find_by_id(params[:id]).name + " does not enabled intelligent assignments."

After:

unless Assignment.find_by(id: params[:id]).is_intelligent # if the assignment is intelligent then redirect to the tree display list
flash[:error] = "This action not allowed. The assignment " + Assignment.find_by(id: params[:id]).name + " does not enabled intelligent assignments."

Changed find_by_id to find_by

Before:

unassignedTeams = AssignmentTeam.where(parent_id: params[:id]).reject {|t| !SignedUpTeam.where(team_id: t.id).empty?}
unassignedTeams.sort! {|t1, t2| TeamsUser.where(team_id: t2.id).size <=> TeamsUser.where(team_id: t1.id).size}
team_bids = []
unassignedTeams.each do |team|
topic_bids = []
sign_up_topics.each do |topic|
student_bids = []
TeamsUser.where(team_id: team.id).each do |s|
student_bid = Bid.where(user_id: s.user_id, topic_id: topic.id).first rescue nil
if !student_bid.nil? and !student_bid.priority.nil?
student_bids << student_bid.priority
end
end
#takes the most frequent priority as the team priority
freq = student_bids.inject(Hash.new(0)) { |h,v| h[v] += 1; h}
topic_bids << {topic_id: topic.id, priority: student_bids.max_by { |v| freq[v] }} unless freq.empty?
end
topic_bids.sort! {|b| b[:priority]}
team_bids << {team_id: team.id, bids: topic_bids}
end

After:

unassigned_teams = AssignmentTeam.where(parent_id: params[:id]).reject {|t| !SignedUpTeam.where(team_id: t.id).empty? }
unassigned_teams.sort! {|t1, t2| TeamsUser.where(team_id: t2.id).size <=> TeamsUser.where(team_id: t1.id).size }
team_bids = []
unassigned_teams.each do |team|
topic_bids = []
sign_up_topics.each do |topic|
student_bids = []
TeamsUser.where(team_id: team.id).each do |s|
student_bid = Bid.where(user_id: s.user_id, topic_id: topic.id).first rescue nil
if !student_bid.nil?
if !student_bid.priority.nil?
student_bids << student_bid.priority
end
end
# takes the most frequent priority as the team priority
freq = student_bids.each_with_object(Hash.new(0)) do |v, h|
h[v] += 1
end
topic_bids << {topic_id: topic.id, priority: student_bids.max_by {|v| freq[v] }} unless freq.empty?
end
topic_bids.sort! {|b| b[:priority] }
team_bids << {team_id: team.id, bids: topic_bids}
end

Used snake case naming convention.
Removed and condition inside if and converted it to nested if condition check.
Replaced inject with each_with_obj.

Before:

def auto_merge_teams(unassignedTeams, _finalTeamTopics)
assignment = Assignment.find(params[:id])
# Sort unassigned
unassignedTeams = Team.where(id: unassignedTeams).sort_by {|t| !t.users.size }
unassignedTeams.each do |team|
sortedBids = Bid.where(user_id: team.id).sort_by(&:priority) # Get priority for each unassignmed team
sortedBids.each do |b|
# SignedUpTeam.where(:topic=>b.topic_id).first.team_id
winningTeam = SignedUpTeam.where(topic: b.topic_id).first.team_id
next unless TeamsUser.where(team_id: winningTeam).size + team.users.size <= assignment.max_team_size # If the team can be merged to a bigger team
TeamsUser.where(team_id: team.id).update_all(team_id: winningTeam)
Bid.delete_all(user_id: team.id)
Team.delete(team.id)
break
end
end
end

After:

before_action :fetch_assignment, only: [:auto_merge_teams]
before_action :sort_unassigned_teams, only: [:auto_merge_teams]
def auto_merge_teams(unassigned_teams, _final_team_topics)
# Sort unassigned

unassigned_teams.each do |team|
sorted_bids = Bid.where(user_id: team.id).sort_by(&:priority) # Get priority for each unassignmed team
sorted_bids.each do |b|
# SignedUpTeam.where(:topic=>b.topic_id).first.team_id
winning_team = SignedUpTeam.where(topic: b.topic_id).first.team_id
next unless TeamsUser.where(team_id: winning_team).size + team.users.size <= assignment.max_team_size # If the team can be merged to a bigger team
TeamsUser.where(team_id: team.id).update_all(team_id: winning_team)
Bid.delete_all(user_id: team.id)
Team.delete(team.id)
break
end
end
end
def fetch_assignment
assignment = Assignment.find(params[:id])
end

def sort_unassigned_teams
unassigned_teams = Team.where(id: unassigned_teams).sort_by {|t| !t.users.size }
end
end

Splited the function into smaller pieces to keep up with coding conventions.

CSC/ECE 517 Fall 2016/E1658. Refractor lottery controller.rb and write integration tests

2016-11-01T21:03:35Z

Aanilku: /* Changes performed */

===Expertiza Background===
Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. It allows students to review each other’s work and improve their work upon this feedback.

===Description of Current Project===
The following is an Expertiza based OSS project which deals primarily with the lottery_controller.rb file. It focusses on refactoring some of the more complex methods, modifying some of the language to make it more Ruby friendly, removing some redundant code. The goal of this project is to attempt to make this part of the application easier to read and maintain.
The lottery_controller contains all of the logic for running the lottery. Code climate is used in this project to detect various issues such as high cyclomatic complexity, bad naming, etc.

===Changes needed===
Fix following issues mentioned below:
* Cyclomatic complexity for run_intelligent_bid is too high.
* Perceived complexity for run_intelligent_bid is too high.
* Use snake_case for variable names.
* Avoid more than 3 levels of block nesting.

===Changes performed===
The code was refactored and its Code Climate rating improved from F to A.

Before Refractoring:
[[File:Ccbefore.png|frame|left]]

After Refractoring:
[[File:Ccscafter.png|frame|left]]

* Cyclomatic complexity for run_intelligent_bid and other methods is greatly reduced.
* Perceived complexity for run_intelligent_bid is also reduced.
* snake_case are used for variable names.
* More than 3 levels of block nesting is avoided.

Before:

if bid_record.nil?
bids << 0
else
bids << bid_record.priority ||= 0
end

After:

bids << bid_record.nil? ? 0 : bid_record.priority ||= 0

Assignment using if condition was changed to conditional operator

Before:
assignment = Assignment.find_by_id(params[:id])

After:
assignment = Assignment.find_by(id: params[:id])

Changed to find_by from find_by_id

Before:

response = RestClient.post url, data.to_json, :content_type => :json, :accept => :json

After:

response = RestClient.post url, data.to_json, content_type: :json, accept: :json

Changed to the latest ruby convention for HashMaps

Before:

def create_new_teams_for_bidding_response(teams, assignment)
teams.each_with_index do |user_ids, index|
new_team = AssignmentTeam.create(name: assignment.name + '_Team' + rand(1000).to_s,
parent_id: assignment.id,
type: 'AssignmentTeam')
parent = TeamNode.create(parent_id: assignment.id, node_object_id: new_team.id)
user_ids.each do |user_id|
team_user = TeamsUser.where(user_id: user_id, team_id: new_team.id).first rescue nil
team_user = TeamsUser.create(user_id: user_id, team_id: new_team.id) if team_user.nil?
TeamUserNode.create(parent_id: parent.id, node_object_id: team_user.id)
end
end
end

After:

def create_new_teams_for_bidding_response(teams, assignment)
teams.each_with_index do |user_ids|
new_team = AssignmentTeam.create(name: assignment.name + '_Team' + rand(1000).to_s,
parent_id: assignment.id,
type: 'AssignmentTeam')
parent = TeamNode.create(parent_id: assignment.id, node_object_id: new_team.id)
user_ids.each do |user_id|
team_user = TeamsUser.where(user_id: user_id, team_id: new_team.id).first rescue nil
team_user = TeamsUser.create(user_id: user_id, team_id: new_team.id) if team_user.nil?
TeamUserNode.create(parent_id: parent.id, node_object_id: team_user.id)
end
end

Removed unused variables

Before:

unless Assignment.find_by_id(params[:id]).is_intelligent # if the assignment is intelligent then redirect to the tree display list
flash[:error] = "This action not allowed. The assignment " + Assignment.find_by_id(params[:id]).name + " does not enabled intelligent assignments."

After:

unless Assignment.find_by(id: params[:id]).is_intelligent # if the assignment is intelligent then redirect to the tree display list
flash[:error] = "This action not allowed. The assignment " + Assignment.find_by(id: params[:id]).name + " does not enabled intelligent assignments."

Changed find_by_id to find_by

Before:

unassignedTeams = AssignmentTeam.where(parent_id: params[:id]).reject {|t| !SignedUpTeam.where(team_id: t.id).empty?}
unassignedTeams.sort! {|t1, t2| TeamsUser.where(team_id: t2.id).size <=> TeamsUser.where(team_id: t1.id).size}
team_bids = []
unassignedTeams.each do |team|
topic_bids = []
sign_up_topics.each do |topic|
student_bids = []
TeamsUser.where(team_id: team.id).each do |s|
student_bid = Bid.where(user_id: s.user_id, topic_id: topic.id).first rescue nil
if !student_bid.nil? and !student_bid.priority.nil?
student_bids << student_bid.priority
end
end
#takes the most frequent priority as the team priority
freq = student_bids.inject(Hash.new(0)) { |h,v| h[v] += 1; h}
topic_bids << {topic_id: topic.id, priority: student_bids.max_by { |v| freq[v] }} unless freq.empty?
end
topic_bids.sort! {|b| b[:priority]}
team_bids << {team_id: team.id, bids: topic_bids}
end

After:

unassigned_teams = AssignmentTeam.where(parent_id: params[:id]).reject {|t| !SignedUpTeam.where(team_id: t.id).empty? }
unassigned_teams.sort! {|t1, t2| TeamsUser.where(team_id: t2.id).size <=> TeamsUser.where(team_id: t1.id).size }
team_bids = []
unassigned_teams.each do |team|
topic_bids = []
sign_up_topics.each do |topic|
student_bids = []
TeamsUser.where(team_id: team.id).each do |s|
student_bid = Bid.where(user_id: s.user_id, topic_id: topic.id).first rescue nil
if !student_bid.nil?
if !student_bid.priority.nil?
student_bids << student_bid.priority
end
end
# takes the most frequent priority as the team priority
freq = student_bids.each_with_object(Hash.new(0)) do |v, h|
h[v] += 1
end
topic_bids << {topic_id: topic.id, priority: student_bids.max_by {|v| freq[v] }} unless freq.empty?
end
topic_bids.sort! {|b| b[:priority] }
team_bids << {team_id: team.id, bids: topic_bids}
end

Used snake case naming convention.
Removed and condition inside if and converted it to nested if condition check.
Replaced inject with each_with_obj.

Before:

def auto_merge_teams(unassignedTeams, _finalTeamTopics)
assignment = Assignment.find(params[:id])
# Sort unassigned
unassignedTeams = Team.where(id: unassignedTeams).sort_by {|t| !t.users.size }
unassignedTeams.each do |team|
sortedBids = Bid.where(user_id: team.id).sort_by(&:priority) # Get priority for each unassignmed team
sortedBids.each do |b|
# SignedUpTeam.where(:topic=>b.topic_id).first.team_id
winningTeam = SignedUpTeam.where(topic: b.topic_id).first.team_id
next unless TeamsUser.where(team_id: winningTeam).size + team.users.size <= assignment.max_team_size # If the team can be merged to a bigger team
TeamsUser.where(team_id: team.id).update_all(team_id: winningTeam)
Bid.delete_all(user_id: team.id)
Team.delete(team.id)
break
end
end
end

After:

before_action :fetch_assignment, only: [:auto_merge_teams]
before_action :sort_unassigned_teams, only: [:auto_merge_teams]
def auto_merge_teams(unassigned_teams, _final_team_topics)
# Sort unassigned

unassigned_teams.each do |team|
sorted_bids = Bid.where(user_id: team.id).sort_by(&:priority) # Get priority for each unassignmed team
sorted_bids.each do |b|
# SignedUpTeam.where(:topic=>b.topic_id).first.team_id
winning_team = SignedUpTeam.where(topic: b.topic_id).first.team_id
next unless TeamsUser.where(team_id: winning_team).size + team.users.size <= assignment.max_team_size # If the team can be merged to a bigger team
TeamsUser.where(team_id: team.id).update_all(team_id: winning_team)
Bid.delete_all(user_id: team.id)
Team.delete(team.id)
break
end
end
end
def fetch_assignment
assignment = Assignment.find(params[:id])
end

def sort_unassigned_teams
unassigned_teams = Team.where(id: unassigned_teams).sort_by {|t| !t.users.size }
end
end

File:Cc old.png

2016-10-29T05:24:03Z

Aanilku: uploaded a new version of "File:Cc old.png": code climate before

code climate before

File:Cc old.png

2016-10-29T05:21:41Z

Aanilku: code climate before

code climate before

CSC/ECE 517 Fall 2016/E1658. Refractor lottery controller.rb and write integration tests

2016-10-28T22:21:51Z

Aanilku:

CSC/ECE 517 Fall 2016/E1658. Refractor lottery controller.rb and write integration tests

2016-10-28T22:15:51Z

Aanilku: /* Changes performed */

CSC/ECE 517 Fall 2016/E1658. Refractor lottery controller.rb and write integration tests

2016-10-28T22:11:42Z

Aanilku: /* Changes performed */

CSC/ECE 517 Fall 2016/E1658. Refractor lottery controller.rb and write integration tests

2016-10-28T22:08:53Z

Aanilku:

CSC/ECE 517 Fall 2016/E1658. Refractor lottery controller.rb and write integration tests

2016-10-28T22:01:49Z

Aanilku:

File:Ccbefore.png

2016-10-28T22:00:48Z

Aanilku:

CSC/ECE 517 Fall 2016/E1658. Refractor lottery controller.rb and write integration tests

2016-10-28T21:56:32Z

Aanilku: /* Changes performed */

File:Ccscafter.png

2016-10-28T21:55:59Z

Aanilku:

File:Cc after.png

2016-10-28T21:47:07Z

Aanilku: uploaded a new version of "File:Cc after.png"

File:Cc after.png

2016-10-28T21:46:25Z

Aanilku: