Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2017/finalproject E1744

2017-04-28T17:48:01Z

George2: /* Database Schema Changes */

'''CSC517 Final Project - E1744 Github Metrics'''

'''(asorgiu, george2, mdunlap, ygou14)'''

== Proposed Design Document ==

===Description===
We will add a new feature to provide Expertiza with Github metrics (for example, number of committers, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. It may also help instructors to predict which projects are likely to be accepted/rejected (even before the final due dates).

===Work to be done===
This project is divided into two parts. One is to extract Github metadata of the submitted repos and pull requests. The second part is to build a classifier (e.g., Bayesian) to do the early prediction on some projects that are likely to fail. This prediction is based on more than 200 past projects (Fall 2012- Fall 2016). Based on the meta-data from students repos/pull requests, we can warn both authors and teaching staff if our model predicts that some projects are likely to fail.

The methodology of this project is to add a means to monitor the individual contributions of various team members throughout the duration of project in order to quantitatively access their work. This will aid the teaching staff and team members during the review process as well as improve visibility to a student of the work he or she has committed.

=====Extract Github metadata=====
* First, get an access token from github. Here are the [https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/ steps]
* Save the access token in the environment variable 'EXPERTIZA_GITHUB_TOKEN'
* Now, github data is fetched from github's [https://developer.github.com/v3/repos/statistics/ Statistic API]

=====Architectural Design=====
This feature has similar functionality with a web crawler, which is crawling the data from a server and store locally. So that for the architectural style of our subsystem, we would like to choose client/server style, which segregates the system into two applications, where the client makes requests to the server whenever a user is looking for the metrics. In many cases, the server is a database with application logic represented as stored procedures, in our case, is Github.

=====UML=====
[[File:1744 design.png|frame|center|30px|30px]]

=====Database Schema Changes=====
[[File:1744_db_schema.png|frame|center|30px|30px]]

A new table called '''github_contributors''' is created to store the data for each committer. The table contain's the committer's email, github_id and all the metrics associated with a project. At the moment we handle the following metrics:
* Committer email - commiter_url
* Committer id - commiter_id
* Total number of commits - total_commits
* Number of files changed - files_changed
* Lines of code changed - lines_changed
* Lines of code added - lines_added
* Lines of code removed - lines_removed
* Lines of code added that survived until final submission - lines_persisted.
* submission_record_id - Foreign Key to '''submission_records''' table.

An index on committer_id is added to enable search.

====Test Plan====

The tests will use rspec to validate the response to the metrics from github and displaying the various metrics. These tests will be test the data in new tables '''github_contributors''' with foreign key to '''submission_records'''.

# Test 1:
## Login as instructor6
## Go to submission page
## Validate that metrics are pulled in from github
# Test 2:
## Login as student
## Go to submission page
## Confirm the student's metrics values

=====Unit Tests=====

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Method
! Parameter
! Expected result
|-
| show
| submission_id with valid github hyperlink
| Github Metrics and status code 200
|-
| show
| submission_id with file uploaded
| render 'github_contributors/not_found'
|-
| show
| submission_id with non github hyperlink
| render 'github_contributors/not_found'
|-
| show
| submission_id with private github hyperlink
| render 'github_contributors/not_found'
|-
|}

====Build a classifier====
THIS WILL NOT BE IMPLEMENTED AS PART OF THIS PROJECT. This is future work to be done.

CSC/ECE 517 Spring 2017/finalproject E1744

2017-04-28T17:47:19Z

George2: /* Test Plan */

'''CSC517 Final Project - E1744 Github Metrics'''

'''(asorgiu, george2, mdunlap, ygou14)'''

== Proposed Design Document ==

===Description===
We will add a new feature to provide Expertiza with Github metrics (for example, number of committers, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. It may also help instructors to predict which projects are likely to be accepted/rejected (even before the final due dates).

===Work to be done===
This project is divided into two parts. One is to extract Github metadata of the submitted repos and pull requests. The second part is to build a classifier (e.g., Bayesian) to do the early prediction on some projects that are likely to fail. This prediction is based on more than 200 past projects (Fall 2012- Fall 2016). Based on the meta-data from students repos/pull requests, we can warn both authors and teaching staff if our model predicts that some projects are likely to fail.

The methodology of this project is to add a means to monitor the individual contributions of various team members throughout the duration of project in order to quantitatively access their work. This will aid the teaching staff and team members during the review process as well as improve visibility to a student of the work he or she has committed.

=====Extract Github metadata=====
* First, get an access token from github. Here are the [https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/ steps]
* Save the access token in the environment variable 'EXPERTIZA_GITHUB_TOKEN'
* Now, github data is fetched from github's [https://developer.github.com/v3/repos/statistics/ Statistic API]

=====Architectural Design=====
This feature has similar functionality with a web crawler, which is crawling the data from a server and store locally. So that for the architectural style of our subsystem, we would like to choose client/server style, which segregates the system into two applications, where the client makes requests to the server whenever a user is looking for the metrics. In many cases, the server is a database with application logic represented as stored procedures, in our case, is Github.

=====UML=====
[[File:1744 design.png|frame|center|30px|30px]]

=====Database Schema Changes=====
[[File:1744_db_schema.png|frame|center|30px|30px]]

A new table called '''github_contributors''' is created to store the data for each committer. The table contain's the committer's email, github_id and all the metrics associated with a project. At the moment we handle the following metrics:
* Committer email - commiter_url
* Committer id - commiter_id
* Total number of commits - total_commits
* Number of files changed - files_changed
* Lines of code changed - lines_changed
* Lines of code added - lines_added
* Lines of code removed - lines_removed
* Lines of code added that survived until final submission - lines_persisted.

An index on committer_id is added to enable search.

A new table called '''submission_records_github_contributors''' which acts as a reference between the '''submission_records''' and '''github_contributors''' tables. It has two columns:
* github_contributor_id - Foreign Key to '''github_contributors''' table.
* submission_record_id - Foreign Key to '''submission_records''' table.

A composite unique key constraint is added on ''github_contributor_id'' and ''submission_record_id''.

====Test Plan====

The tests will use rspec to validate the response to the metrics from github and displaying the various metrics. These tests will be test the data in new tables '''github_contributors''' with foreign key to '''submission_records'''.

# Test 1:
## Login as instructor6
## Go to submission page
## Validate that metrics are pulled in from github
# Test 2:
## Login as student
## Go to submission page
## Confirm the student's metrics values

=====Unit Tests=====

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Method
! Parameter
! Expected result
|-
| show
| submission_id with valid github hyperlink
| Github Metrics and status code 200
|-
| show
| submission_id with file uploaded
| render 'github_contributors/not_found'
|-
| show
| submission_id with non github hyperlink
| render 'github_contributors/not_found'
|-
| show
| submission_id with private github hyperlink
| render 'github_contributors/not_found'
|-
|}

====Build a classifier====
THIS WILL NOT BE IMPLEMENTED AS PART OF THIS PROJECT. This is future work to be done.

CSC/ECE 517 Spring 2017/finalproject E1744

2017-04-28T17:46:05Z

George2: /* Unit Tests */

'''CSC517 Final Project - E1744 Github Metrics'''

'''(asorgiu, george2, mdunlap, ygou14)'''

== Proposed Design Document ==

===Description===
We will add a new feature to provide Expertiza with Github metrics (for example, number of committers, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. It may also help instructors to predict which projects are likely to be accepted/rejected (even before the final due dates).

===Work to be done===
This project is divided into two parts. One is to extract Github metadata of the submitted repos and pull requests. The second part is to build a classifier (e.g., Bayesian) to do the early prediction on some projects that are likely to fail. This prediction is based on more than 200 past projects (Fall 2012- Fall 2016). Based on the meta-data from students repos/pull requests, we can warn both authors and teaching staff if our model predicts that some projects are likely to fail.

The methodology of this project is to add a means to monitor the individual contributions of various team members throughout the duration of project in order to quantitatively access their work. This will aid the teaching staff and team members during the review process as well as improve visibility to a student of the work he or she has committed.

=====Extract Github metadata=====
* First, get an access token from github. Here are the [https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/ steps]
* Save the access token in the environment variable 'EXPERTIZA_GITHUB_TOKEN'
* Now, github data is fetched from github's [https://developer.github.com/v3/repos/statistics/ Statistic API]

=====Architectural Design=====
This feature has similar functionality with a web crawler, which is crawling the data from a server and store locally. So that for the architectural style of our subsystem, we would like to choose client/server style, which segregates the system into two applications, where the client makes requests to the server whenever a user is looking for the metrics. In many cases, the server is a database with application logic represented as stored procedures, in our case, is Github.

=====UML=====
[[File:1744 design.png|frame|center|30px|30px]]

=====Database Schema Changes=====
[[File:1744_db_schema.png|frame|center|30px|30px]]

A new table called '''github_contributors''' is created to store the data for each committer. The table contain's the committer's email, github_id and all the metrics associated with a project. At the moment we handle the following metrics:
* Committer email - commiter_url
* Committer id - commiter_id
* Total number of commits - total_commits
* Number of files changed - files_changed
* Lines of code changed - lines_changed
* Lines of code added - lines_added
* Lines of code removed - lines_removed
* Lines of code added that survived until final submission - lines_persisted.

An index on committer_id is added to enable search.

A new table called '''submission_records_github_contributors''' which acts as a reference between the '''submission_records''' and '''github_contributors''' tables. It has two columns:
* github_contributor_id - Foreign Key to '''github_contributors''' table.
* submission_record_id - Foreign Key to '''submission_records''' table.

A composite unique key constraint is added on ''github_contributor_id'' and ''submission_record_id''.

====Test Plan====

The tests will use rspec to validate the response to the metrics from github and displaying the various metrics. These tests will be test the data in new tables '''submission_records_github_contributors''' and '''github_contributors''' as well as expand the existing tests on '''submission_records'''.

# Test 1:
## Login as instructor6
## Go to submission page
## Validate that metrics are pulled in from github
# Test 2:
## Login as student
## Go to submission page
## Confirm the student's metrics values

=====Unit Tests=====

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Method
! Parameter
! Expected result
|-
| show
| submission_id with valid github hyperlink
| Github Metrics and status code 200
|-
| show
| submission_id with file uploaded
| render 'github_contributors/not_found'
|-
| show
| submission_id with non github hyperlink
| render 'github_contributors/not_found'
|-
| show
| submission_id with private github hyperlink
| render 'github_contributors/not_found'
|-
|}

====Build a classifier====
THIS WILL NOT BE IMPLEMENTED AS PART OF THIS PROJECT. This is future work to be done.

CSC/ECE 517 Spring 2017/finalproject E1744

2017-04-28T17:23:41Z

George2: /* Extract Github metadata */

'''CSC517 Final Project - E1744 Github Metrics'''

'''(asorgiu, george2, mdunlap, ygou14)'''

== Proposed Design Document ==

===Description===
We will add a new feature to provide Expertiza with Github metrics (for example, number of committers, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. It may also help instructors to predict which projects are likely to be accepted/rejected (even before the final due dates).

===Work to be done===
This project is divided into two parts. One is to extract Github metadata of the submitted repos and pull requests. The second part is to build a classifier (e.g., Bayesian) to do the early prediction on some projects that are likely to fail. This prediction is based on more than 200 past projects (Fall 2012- Fall 2016). Based on the meta-data from students repos/pull requests, we can warn both authors and teaching staff if our model predicts that some projects are likely to fail.

The methodology of this project is to add a means to monitor the individual contributions of various team members throughout the duration of project in order to quantitatively access their work. This will aid the teaching staff and team members during the review process as well as improve visibility to a student of the work he or she has committed.

=====Extract Github metadata=====
* First, get an access token from github. Here are the [https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/ steps]
* Save the access token in the environment variable 'EXPERTIZA_GITHUB_TOKEN'
* Now, github data is fetched from github's [https://developer.github.com/v3/repos/statistics/ Statistic API]

=====Architectural Design=====
This feature has similar functionality with a web crawler, which is crawling the data from a server and store locally. So that for the architectural style of our subsystem, we would like to choose client/server style, which segregates the system into two applications, where the client makes requests to the server whenever a user is looking for the metrics. In many cases, the server is a database with application logic represented as stored procedures, in our case, is Github.

=====UML=====
[[File:1744 design.png|frame|center|30px|30px]]

=====Database Schema Changes=====
[[File:1744_db_schema.png|frame|center|30px|30px]]

A new table called '''github_contributors''' is created to store the data for each committer. The table contain's the committer's email, github_id and all the metrics associated with a project. At the moment we handle the following metrics:
* Committer email - commiter_url
* Committer id - commiter_id
* Total number of commits - total_commits
* Number of files changed - files_changed
* Lines of code changed - lines_changed
* Lines of code added - lines_added
* Lines of code removed - lines_removed
* Lines of code added that survived until final submission - lines_persisted.

An index on committer_id is added to enable search.

A new table called '''submission_records_github_contributors''' which acts as a reference between the '''submission_records''' and '''github_contributors''' tables. It has two columns:
* github_contributor_id - Foreign Key to '''github_contributors''' table.
* submission_record_id - Foreign Key to '''submission_records''' table.

A composite unique key constraint is added on ''github_contributor_id'' and ''submission_record_id''.

====Test Plan====

The tests will use rspec to validate the response to the metrics from github and displaying the various metrics. These tests will be test the data in new tables '''submission_records_github_contributors''' and '''github_contributors''' as well as expand the existing tests on '''submission_records'''.

# Test 1:
## Login as instructor6
## Go to submission page
## Validate that metrics are pulled in from github
# Test 2:
## Login as student
## Go to submission page
## Confirm the student's metrics values

=====Unit Tests=====

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Method
! Parameter
! Expected result
|-
| get_metrics
| team_id = null
| Null / Exception
|-
| get_metrics
| team_id = Invalid team_id
| Null / Exception
|-
| get_metrics
| team_id = valid_team_id
| List of metrics for all the committers in the team.
|-
|}

====Build a classifier====
THIS WILL NOT BE IMPLEMENTED AS PART OF THIS PROJECT. This is future work to be done.

CSC/ECE 517 Spring 2017/finalproject E1744

2017-04-28T17:19:14Z

George2: /* Work to be done */

'''CSC517 Final Project - E1744 Github Metrics'''

'''(asorgiu, george2, mdunlap, ygou14)'''

== Proposed Design Document ==

===Description===
We will add a new feature to provide Expertiza with Github metrics (for example, number of committers, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. It may also help instructors to predict which projects are likely to be accepted/rejected (even before the final due dates).

===Work to be done===
This project is divided into two parts. One is to extract Github metadata of the submitted repos and pull requests. The second part is to build a classifier (e.g., Bayesian) to do the early prediction on some projects that are likely to fail. This prediction is based on more than 200 past projects (Fall 2012- Fall 2016). Based on the meta-data from students repos/pull requests, we can warn both authors and teaching staff if our model predicts that some projects are likely to fail.

The methodology of this project is to add a means to monitor the individual contributions of various team members throughout the duration of project in order to quantitatively access their work. This will aid the teaching staff and team members during the review process as well as improve visibility to a student of the work he or she has committed.

=====Extract Github metadata=====
* First, get an access token from github. Here are the [steps](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/)
* Save the access token in the environment variable 'EXPERTIZA_GITHUB_TOKEN'
* Now, github data is fetched from github's [statistic API](https://developer.github.com/v3/repos/statistics/)

=====Architectural Design=====
This feature has similar functionality with a web crawler, which is crawling the data from a server and store locally. So that for the architectural style of our subsystem, we would like to choose client/server style, which segregates the system into two applications, where the client makes requests to the server whenever a user is looking for the metrics. In many cases, the server is a database with application logic represented as stored procedures, in our case, is Github.

=====UML=====
[[File:1744 design.png|frame|center|30px|30px]]

=====Database Schema Changes=====
[[File:1744_db_schema.png|frame|center|30px|30px]]

A new table called '''github_contributors''' is created to store the data for each committer. The table contain's the committer's email, github_id and all the metrics associated with a project. At the moment we handle the following metrics:
* Committer email - commiter_url
* Committer id - commiter_id
* Total number of commits - total_commits
* Number of files changed - files_changed
* Lines of code changed - lines_changed
* Lines of code added - lines_added
* Lines of code removed - lines_removed
* Lines of code added that survived until final submission - lines_persisted.

An index on committer_id is added to enable search.

A new table called '''submission_records_github_contributors''' which acts as a reference between the '''submission_records''' and '''github_contributors''' tables. It has two columns:
* github_contributor_id - Foreign Key to '''github_contributors''' table.
* submission_record_id - Foreign Key to '''submission_records''' table.

A composite unique key constraint is added on ''github_contributor_id'' and ''submission_record_id''.

====Test Plan====

The tests will use rspec to validate the response to the metrics from github and displaying the various metrics. These tests will be test the data in new tables '''submission_records_github_contributors''' and '''github_contributors''' as well as expand the existing tests on '''submission_records'''.

# Test 1:
## Login as instructor6
## Go to submission page
## Validate that metrics are pulled in from github
# Test 2:
## Login as student
## Go to submission page
## Confirm the student's metrics values

=====Unit Tests=====

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Method
! Parameter
! Expected result
|-
| get_metrics
| team_id = null
| Null / Exception
|-
| get_metrics
| team_id = Invalid team_id
| Null / Exception
|-
| get_metrics
| team_id = valid_team_id
| List of metrics for all the committers in the team.
|-
|}

====Build a classifier====
THIS WILL NOT BE IMPLEMENTED AS PART OF THIS PROJECT. This is future work to be done.

CSC/ECE 517 Spring 2017/finalproject E1744

2017-04-28T17:01:38Z

George2: /* Data Flow */

'''CSC517 Final Project - E1744 Github Metrics'''

'''(asorgiu, george2, mdunlap, ygou14)'''

== Proposed Design Document ==

===Description===
We will add a new feature to provide Expertiza with Github metrics (for example, number of committers, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. It may also help instructors to predict which projects are likely to be accepted/rejected (even before the final due dates).

===Work to be done===
This project is divided into two parts. One is to extract Github metadata of the submitted repos and pull requests. The second part is to build a classifier (e.g., Bayesian) to do the early prediction on some projects that are likely to fail. This prediction is based on more than 200 past projects (Fall 2012- Fall 2016). Based on the meta-data from students repos/pull requests, we can warn both authors and teaching staff if our model predicts that some projects are likely to fail.

The methodology of this project is to add a means to monitor the individual contributions of various team members throughout the duration of project in order to quantitatively access their work. This will aid the teaching staff and team members during the review process as well as improve visibility to a student of the work he or she has committed.

====Extract Github metadata====

=====Architectural Design=====
This feature has similar functionality with a web crawler, which is crawling the data from a server and store locally. So that for the architectural style of our subsystem, we would like to choose client/server style, which segregates the system into two applications, where the client makes requests to the server whenever a user is looking for the metrics. In many cases, the server is a database with application logic represented as stored procedures, in our case, is Github.

=====UML=====
[[File:1744 design.png|frame|center|30px|30px]]

=====Database Schema Changes=====
[[File:1744_db_schema.png|frame|center|30px|30px]]

A new table called '''github_contributors''' is created to store the data for each committer. The table contain's the committer's email, github_id and all the metrics associated with a project. At the moment we handle the following metrics:
* Committer email - commiter_url
* Committer id - commiter_id
* Total number of commits - total_commits
* Number of files changed - files_changed
* Lines of code changed - lines_changed
* Lines of code added - lines_added
* Lines of code removed - lines_removed
* Lines of code added that survived until final submission - lines_persisted.

An index on committer_id is added to enable search.

A new table called '''submission_records_github_contributors''' which acts as a reference between the '''submission_records''' and '''github_contributors''' tables. It has two columns:
* github_contributor_id - Foreign Key to '''github_contributors''' table.
* submission_record_id - Foreign Key to '''submission_records''' table.

A composite unique key constraint is added on ''github_contributor_id'' and ''submission_record_id''.

====Test Plan====

The tests will use rspec to validate the response to the metrics from github and displaying the various metrics. These tests will be test the data in new tables '''submission_records_github_contributors''' and '''github_contributors''' as well as expand the existing tests on '''submission_records'''.

# Test 1:
## Login as instructor6
## Go to submission page
## Validate that metrics are pulled in from github
# Test 2:
## Login as student
## Go to submission page
## Confirm the student's metrics values

=====Unit Tests=====

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Method
! Parameter
! Expected result
|-
| get_metrics
| team_id = null
| Null / Exception
|-
| get_metrics
| team_id = Invalid team_id
| Null / Exception
|-
| get_metrics
| team_id = valid_team_id
| List of metrics for all the committers in the team.
|-
|}

====Build a classifier====
THIS WILL NOT BE IMPLEMENTED AS PART OF THIS PROJECT. This is future work to be done.

File:1744 db schema.png

2017-04-17T19:46:24Z

George2: uploaded a new version of "File:1744 db schema.png"

CSC/ECE 517 Spring 2017/finalproject E1744

2017-04-12T22:16:13Z

George2: /* Database Schema Changes */

'''CSC517 Final Project - E1744 Github Metrics'''

'''(asorgiu, george2, mdunlap, ygou14)'''

== Proposed Design Document ==

===Description===
We will add a new feature to provide Expertiza with Github metrics (for example, number of committers, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. It may also help instructors to predict which projects are likely to be merged.

===Work to be done===
This project is divided into two parts. One is to extract Github metadata of the submitted repos and pull requests. The second part is to build a classifier (e.g., Bayesian) to do the early prediction on some projects that are likely to fail. This prediction is based on more than 200 past projects. The features above should be used, together with some temporal features (e.g. the temporal pattern of this team’s commits so far). Eventually, we would like to e-mail students whose metrics are bad, giving them advice on how to improve.

The purpose of this project is to add a means to monitor the individual contributions of various team members throughout the duration of project in order to quantitatively access their work. This will aid the teaching staff and team members during the review process as well as improve visibility to a student of the work he or she has committed.

====Extract Github metadata====

=====Data Flow=====

The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.

=====Architectural Design=====
This feature has similar functionality with a web crawler, which is crawling the data from a server and store locally. So that for the architectural style of our subsystem, we would like to choose client/server style, which segregates the system into two applications, where the client makes requests to the server whenever a user is looking for the metrics. In many cases, the server is a database with application logic represented as stored procedures, in our case, is Github.

=====UML=====
[[File:1744 design.png|frame|center|30px|30px]]

=====Database Schema Changes=====
[[File:1744_db_schema.png|frame|center|30px|30px]]

A new table called '''github_contributors''' is created to store the data for each committer. The table contain's the committer's email, github_id and all the metrics associated with a project. At the moment we handle the following metrics:
* Committer email - commiter_url
* Committer id - commiter_id
* Total number of commits - total_commits
* Number of files changed - files_changed
* Lines of code changed - lines_changed
* Lines of code added - lines_added
* Lines of code removed - lines_removed
* Lines of code added that survived until final submission - lines_persisted.

An index on committer_id is added to enable search.

A new table called '''submission_records_github_contributors''' which acts as a reference between the '''submission_records''' and '''github_contributors''' tables. It has two columns:
* github_contributor_id - Foreign Key to '''github_contributors''' table.
* submission_record_id - Foreign Key to '''submission_records''' table.

A composite unique key constraint is added on ''github_contributor_id'' and ''submission_record_id''.

====Test Plan====

The tests will use stubs to simulate the number of commits from github and displaying the various metrics. These tests will be test the data in new tables '''submission_records_github_contributors''' and '''github_contributors''' as well as expand the existing tests on '''submission_records'''.

# Test 1:
## Login as instructor6
## Go to submission page
## Validate that metrics are pulled in from github
# Test 2:
## Login as student
## Go to submission page
## Confirm the student's metrics values

=====Unit Tests=====

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Method
! Parameter
! Expected result
|-
| get_metrics
| team_id = null
| Null / Exception
|-
| get_metrics
| team_id = Invalid team_id
| Null / Exception
|-
| get_metrics
| team_id = valid_team_id
| List of metrics for all the committers in the team.
|-
|}

====Build a classifier====
THIS WILL NOT BE IMPLEMENTED AS PART OF THIS PROJECT. This is future work to be done.

File:1744 db schema.png

2017-04-12T22:15:35Z

George2:

CSC/ECE 517 Spring 2017/finalproject E1744

2017-04-12T22:01:34Z

George2: /* Database Schema Changes */

'''CSC517 Final Project - E1744 Github Metrics'''

'''(asorgiu, george2, mdunlap, ygou14)'''

== Proposed Design Document ==

===Description===
We will add a new feature to provide Expertiza with Github metrics (for example, number of committers, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. It may also help instructors to predict which projects are likely to be merged.

===Work to be done===
This project is divided into two parts. One is to extract Github metadata of the submitted repos and pull requests. The second part is to build a classifier (e.g., Bayesian) to do the early prediction on some projects that are likely to fail. This prediction is based on more than 200 past projects. The features above should be used, together with some temporal features (e.g. the temporal pattern of this team’s commits so far). Eventually, we would like to e-mail students whose metrics are bad, giving them advice on how to improve.

The purpose of this project is to add a means to monitor the individual contributions of various team members throughout the duration of project in order to quantitatively access their work. This will aid the teaching staff and team members during the review process as well as improve visibility to a student of the work he or she has committed.

====Extract Github metadata====

=====Data Flow=====

The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.

=====Architectural Design=====
This feature has similar functionality with a web crawler, which is crawling the data from a server and store locally. So that for the architectural style of our subsystem, we would like to choose client/server style, which segregates the system into two applications, where the client makes requests to the server whenever a user is looking for the metrics. In many cases, the server is a database with application logic represented as stored procedures, in our case, is Github.

=====UML=====
[[File:1744 design.png|frame|center|30px|30px]]

=====Database Schema Changes=====
[[File:Database.png|frame|center|15px|15px]]

A new table called '''github_contributors''' is created to store the data for each committer. The table contain's the committer's email, github_id and all the metrics associated with a project. At the moment we handle the following metrics:
* Committer email - commiter_url
* Committer id - commiter_id
* Total number of commits - total_commits
* Number of files changed - files_changed
* Lines of code changed - lines_changed
* Lines of code added - lines_added
* Lines of code removed - lines_removed
* Lines of code added that survived until final submission - lines_persisted.

An index on committer_id is added to enable search.

A new table called '''submission_records_github_contributors''' which acts as a reference between the '''submission_records''' and '''github_contributors''' tables. It has two columns:
* github_contributor_id - Foreign Key to '''github_contributors''' table.
* submission_record_id - Foreign Key to '''submission_records''' table.

A composite unique key constraint is added on ''github_contributor_id'' and ''submission_record_id''.

====Test Plan====

The tests will use stubs to simulate the number of commits from github and displaying the various metrics. These tests will be test the data in new tables '''submission_records_github_contributors''' and '''github_contributors''' as well as expand the existing tests on '''submission_records'''.

# Test 1:
## Login as instructor6
## Go to submission page
## Validate that metrics are pulled in from github
# Test 2:
## Login as student
## Go to submission page
## Confirm the student's metrics values

=====Unit Tests=====

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Method
! Parameter
! Expected result
|-
| get_metrics
| team_id = null
| Null / Exception
|-
| get_metrics
| team_id = Invalid team_id
| Null / Exception
|-
| get_metrics
| team_id = valid_team_id
| List of metrics for all the committers in the team.
|-
|}

====Build a classifier====
THIS WILL NOT BE IMPLEMENTED AS PART OF THIS PROJECT. This is future work to be done.

CSC/ECE 517 Spring 2017/finalproject E1744

2017-04-12T22:01:22Z

George2: /* Database Schema Changes */

'''CSC517 Final Project - E1744 Github Metrics'''

'''(asorgiu, george2, mdunlap, ygou14)'''

== Proposed Design Document ==

===Description===
We will add a new feature to provide Expertiza with Github metrics (for example, number of committers, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. It may also help instructors to predict which projects are likely to be merged.

===Work to be done===
This project is divided into two parts. One is to extract Github metadata of the submitted repos and pull requests. The second part is to build a classifier (e.g., Bayesian) to do the early prediction on some projects that are likely to fail. This prediction is based on more than 200 past projects. The features above should be used, together with some temporal features (e.g. the temporal pattern of this team’s commits so far). Eventually, we would like to e-mail students whose metrics are bad, giving them advice on how to improve.

The purpose of this project is to add a means to monitor the individual contributions of various team members throughout the duration of project in order to quantitatively access their work. This will aid the teaching staff and team members during the review process as well as improve visibility to a student of the work he or she has committed.

====Extract Github metadata====

=====Data Flow=====

The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.

=====Architectural Design=====
This feature has similar functionality with a web crawler, which is crawling the data from a server and store locally. So that for the architectural style of our subsystem, we would like to choose client/server style, which segregates the system into two applications, where the client makes requests to the server whenever a user is looking for the metrics. In many cases, the server is a database with application logic represented as stored procedures, in our case, is Github.

=====UML=====
[[File:1744 design.png|frame|center|30px|30px]]

=====Database Schema Changes=====
[[File:Database.png|frame|center|30px|30px]]

A new table called '''github_contributors''' is created to store the data for each committer. The table contain's the committer's email, github_id and all the metrics associated with a project. At the moment we handle the following metrics:
* Committer email - commiter_url
* Committer id - commiter_id
* Total number of commits - total_commits
* Number of files changed - files_changed
* Lines of code changed - lines_changed
* Lines of code added - lines_added
* Lines of code removed - lines_removed
* Lines of code added that survived until final submission - lines_persisted.

An index on committer_id is added to enable search.

A new table called '''submission_records_github_contributors''' which acts as a reference between the '''submission_records''' and '''github_contributors''' tables. It has two columns:
* github_contributor_id - Foreign Key to '''github_contributors''' table.
* submission_record_id - Foreign Key to '''submission_records''' table.

A composite unique key constraint is added on ''github_contributor_id'' and ''submission_record_id''.

====Test Plan====

The tests will use stubs to simulate the number of commits from github and displaying the various metrics. These tests will be test the data in new tables '''submission_records_github_contributors''' and '''github_contributors''' as well as expand the existing tests on '''submission_records'''.

# Test 1:
## Login as instructor6
## Go to submission page
## Validate that metrics are pulled in from github
# Test 2:
## Login as student
## Go to submission page
## Confirm the student's metrics values

=====Unit Tests=====

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Method
! Parameter
! Expected result
|-
| get_metrics
| team_id = null
| Null / Exception
|-
| get_metrics
| team_id = Invalid team_id
| Null / Exception
|-
| get_metrics
| team_id = valid_team_id
| List of metrics for all the committers in the team.
|-
|}

====Build a classifier====
THIS WILL NOT BE IMPLEMENTED AS PART OF THIS PROJECT. This is future work to be done.

File:Database.png

2017-04-12T21:59:51Z

George2: uploaded a new version of "File:Database.png"

Database Schema

CSC/ECE 517 Spring 2017/finalproject E1744

2017-04-12T21:54:43Z

George2: /* Test Plan */

'''CSC517 Final Project - E1744 Github Metrics'''

'''(asorgiu, george2, mdunlap, ygou14)'''

== Proposed Design Document ==

===Description===
We will add a new feature to provide Expertiza with Github metrics (for example, number of committers, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. It may also help instructors to predict which projects are likely to be merged.

===Work to be done===
This project is divided into two parts. One is to extract Github metadata of the submitted repos and pull requests. The second part is to build a classifier (e.g., Bayesian) to do the early prediction on some projects that are likely to fail. This prediction is based on more than 200 past projects. The features above should be used, together with some temporal features (e.g. the temporal pattern of this team’s commits so far). Eventually, we would like to e-mail students whose metrics are bad, giving them advice on how to improve.

The purpose of this project is to add a means to monitor the individual contributions of various team members throughout the duration of project in order to quantitatively access their work. This will aid the teaching staff and team members during the review process as well as improve visibility to a student of the work he or she has committed.

====Extract Github metadata====

=====Data Flow=====

The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.

=====Architectural Design=====
This feature has similar functionality with a web crawler, which is crawling the data from a server and store locally. So that for the architectural style of our subsystem, we would like to choose client/server style, which segregates the system into two applications, where the client makes requests to the server whenever a user is looking for the metrics. In many cases, the server is a database with application logic represented as stored procedures, in our case, is Github.

=====UML=====
[[File:1744 design.png|frame|center|30px|30px]]

=====Database Schema Changes=====
[[File:db_github_schema.png|frame|center]]

A new table called '''github_contributors''' is created to store the data for each committer. The table contain's the committer's email, github_id and all the metrics associated with a project. At the moment we handle the following metrics:
* Committer email - commiter_url
* Committer id - commiter_id
* Total number of commits - total_commits
* Number of files changed - files_changed
* Lines of code changed - lines_changed
* Lines of code added - lines_added
* Lines of code removed - lines_removed
* Lines of code added that survived until final submission - lines_persisted.

An index on committer_id is added to enable search.

A new table called '''submission_records_github_contributors''' which acts as a reference between the '''submission_records''' and '''github_contributors''' tables. It has two columns:
* github_contributor_id - Foreign Key to '''github_contributors''' table.
* submission_record_id - Foreign Key to '''submission_records''' table.

A composite unique key constraint is added on ''github_contributor_id'' and ''submission_record_id''.

====Test Plan====

The tests will use stubs to simulate the number of commits from github and displaying the various metrics. These tests will be test the data in new tables '''submission_records_github_contributors''' and '''github_contributors''' as well as expand the existing tests on '''submission_records'''.

# Test 1:
## Login as instructor6
## Go to submission page
## Validate that metrics are pulled in from github
# Test 2:
## Login as student
## Go to submission page
## Confirm the student's metrics values

=====Unit Tests=====

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Method
! Parameter
! Expected result
|-
| get_metrics
| team_id = null
| Null / Exception
|-
| get_metrics
| team_id = Invalid team_id
| Null / Exception
|-
| get_metrics
| team_id = valid_team_id
| List of metrics for all the committers in the team.
|-
|}

====Build a classifier====
THIS WILL NOT BE IMPLEMENTED AS PART OF THIS PROJECT. This is future work to be done.

CSC/ECE 517 Spring 2017/finalproject E1744

2017-04-12T21:41:39Z

George2: /* Test Plan */

'''CSC517 Final Project - E1744 Github Metrics'''

'''(asorgiu, george2, mdunlap, ygou14)'''

== Proposed Design Document ==

===Description===
We will add a new feature to provide Expertiza with Github metrics (for example, number of committers, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. It may also help instructors to predict which projects are likely to be merged.

===Work to be done===
This project is divided into two parts. One is to extract Github metadata of the submitted repos and pull requests. The second part is to build a classifier (e.g., Bayesian) to do the early prediction on some projects that are likely to fail. This prediction is based on more than 200 past projects. The features above should be used, together with some temporal features (e.g. the temporal pattern of this team’s commits so far). Eventually, we would like to e-mail students whose metrics are bad, giving them advice on how to improve.

The purpose of this project is to add a means to monitor the individual contributions of various team members throughout the duration of project in order to quantitatively access their work. This will aid the teaching staff and team members during the review process as well as improve visibility to a student of the work he or she has committed.

====Extract Github metadata====

=====Data Flow=====

The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.

=====Architectural Design=====
This feature has similar functionality with a web crawler, which is crawling the data from a server and store locally. So that for the architectural style of our subsystem, we would like to choose client/server style, which segregates the system into two applications, where the client makes requests to the server whenever a user is looking for the metrics. In many cases, the server is a database with application logic represented as stored procedures, in our case, is Github.

=====UML=====
[[File:1744 design.png|frame|center|30px|30px]]

=====Database Schema Changes=====
[[File:db_github_schema.png|frame|center]]

A new table called '''github_contributors''' is created to store the data for each committer. The table contain's the committer's email, github_id and all the metrics associated with a project. At the moment we handle the following metrics:
* Committer email - commiter_url
* Committer id - commiter_id
* Total number of commits - total_commits
* Number of files changed - files_changed
* Lines of code changed - lines_changed
* Lines of code added - lines_added
* Lines of code removed - lines_removed
* Lines of code added that survived until final submission - lines_persisted.

An index on committer_id is added to enable search.

A new table called '''submission_records_github_contributors''' which acts as a reference between the '''submission_records''' and '''github_contributors''' tables. It has two columns:
* github_contributor_id - Foreign Key to '''github_contributors''' table.
* submission_record_id - Foreign Key to '''submission_records''' table.

A composite unique key constraint is added on ''github_contributor_id'' and ''submission_record_id''.

=====Test Plan=====

The tests will use stubs to simulate the number of commits from github and displaying the various metrics. These tests will be test the data in new tables '''submission_records_github_contributors''' and '''github_contributors''' as well as expand the existing tests on '''submission_records'''.

# Test 1:
## Login as instructor6
## Go to submission page
## Validate that metrics are pulled in from github
# Test 2:
## Login as student
## Go to submission page
## Confirm the student's metrics values

====Build a classifier====
THIS WILL NOT BE IMPLEMENTED AS PART OF THIS PROJECT. This is future work to be done.

CSC/ECE 517 Spring 2017/finalproject E1744

2017-04-12T21:34:56Z

George2: /* Extract Github metadata */

'''CSC517 Final Project - E1744 Github Metrics'''

'''(asorgiu, george2, mdunlap, ygou14)'''

== Proposed Design Document ==

===Description===
We will add a new feature to provide Expertiza with Github metrics (for example, number of committers, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. It may also help instructors to predict which projects are likely to be merged.

===Work to be done===
This project is divided into two parts. One is to extract Github metadata of the submitted repos and pull requests. The second part is to build a classifier (e.g., Bayesian) to do the early prediction on some projects that are likely to fail. This prediction is based on more than 200 past projects. The features above should be used, together with some temporal features (e.g. the temporal pattern of this team’s commits so far). Eventually, we would like to e-mail students whose metrics are bad, giving them advice on how to improve.

The purpose of this project is to add a means to monitor the individual contributions of various team members throughout the duration of project in order to quantitatively access their work. This will aid the teaching staff and team members during the review process as well as improve visibility to a student of the work he or she has committed.

====Extract Github metadata====

=====Data Flow=====

The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.

=====Architectural Design=====
This feature has similar functionality with a web crawler, which is crawling the data from a server and store locally. So that for the architectural style of our subsystem, we would like to choose client/server style, which segregates the system into two applications, where the client makes requests to the server whenever a user is looking for the metrics. In many cases, the server is a database with application logic represented as stored procedures, in our case, is Github.

=====UML=====
[[File:1744 design.png|frame|center|30px|30px]]

=====Database Schema Changes=====
[[File:db_github_schema.png|frame|center]]

A new table called '''github_contributors''' is created to store the data for each committer. The table contain's the committer's email, github_id and all the metrics associated with a project. At the moment we handle the following metrics:
* Committer email - commiter_url
* Committer id - commiter_id
* Total number of commits - total_commits
* Number of files changed - files_changed
* Lines of code changed - lines_changed
* Lines of code added - lines_added
* Lines of code removed - lines_removed
* Lines of code added that survived until final submission - lines_persisted.

An index on committer_id is added to enable search.

A new table called '''submission_records_github_contributors''' which acts as a reference between the '''submission_records''' and '''github_contributors''' tables. It has two columns:
* github_contributor_id - Foreign Key to '''github_contributors''' table.
* submission_record_id - Foreign Key to '''submission_records''' table.

A composite unique key constraint is added on ''github_contributor_id'' and ''submission_record_id''.

=====Test Plan=====

The tests will use stubs to simulate the number of commits from github and displaying the various metrics. These tests will be test the data in new tables '''submission_records_github_contributors''' and '''github_contributors''' as well as expand the existing tests on '''submission_records'''.

Test 1:
1. Login as instructor6
2. Go to submission page
3. Validate that metrics are pulled in from github

Test 2:
1. Login as student
2. Go to submission page
3. Confirm the student's metrics values

====Build a classifier====
THIS WILL NOT BE IMPLEMENTED AS PART OF THIS PROJECT. This is future work to be done.

CSC/ECE 517 Spring 2017/finalproject E1744

2017-04-07T03:15:26Z

George2: /* Database Schema Changes */

CSC/ECE 517 Spring 2017/finalproject E1744

2017-04-06T09:27:17Z

George2: /* Database Schema Changes */

CSC/ECE 517 Spring 2017/finalproject E1744

2017-04-06T09:25:04Z

George2: /* Database Schema Changes */

File:Db github schema.png

2017-04-06T09:23:54Z

George2: uploaded a new version of "File:Db github schema.png"

File:Db github schema.png

2017-04-06T09:23:01Z

George2:

File:Database.png

2017-04-06T09:18:32Z

George2: uploaded a new version of "File:Database.png": Reverted to version as of 09:16, 6 April 2017

Database Schema

File:Database.png

2017-04-06T09:17:30Z

George2: uploaded a new version of "File:Database.png"

Database Schema

File:Database.png

2017-04-06T09:16:12Z

George2: Database Schema

Database Schema

CSC/ECE 517 Spring 2017/finalproject E1744

2017-04-06T05:36:59Z

George2: /* Database Schema Changes */

CSC/ECE 517 Spring 2017/finalproject E1744

2017-04-06T05:35:50Z

George2: /* Database Schema Changes */

CSC/ECE 517 Spring 2017/finalproject E1744

2017-04-06T05:34:48Z

George2: /* Database Schema Changes */

CSC/ECE 517 Spring 2017/finalproject E1744

2017-04-06T05:31:25Z

George2: /* Proposed Design Document */

CSC/ECE 517 Spring 2017/oss E1727

2017-03-25T22:58:37Z

George2:

==Introduction==
This project was completed as part of a greater open source project called Expertiza.

Expertiza is a web application platform, similar to wikipedia, which offers teachers and students a way to organize for group assignments and porjects. By using Expertiza, students have the ability to submit and coordinate peer-review learning objects (articles, code, web sites, etc). The Expertiza project is supported by the National Science Foundation.

Expertiza offers several features which are useful to a classroom-style learning environment. Among those several features, this project represents a contribution to the organization of the code used for assignment signup sheets.

===Background===
The work for this project was completed by a group of three students from NC State. However, the project was completed according to guidelines provided by a coordinator who works with Expertiza.

Following the guidelines provided, the group worked to clean up a portion of the Expertiza project code through refactorization and reorganization. More specifically, logical code needed to be separated from portions of the project which were not responsible for containing code for the functionality of the application.

===Motivation===
The motivation for this project was to make the project code easier for programmers to read by compartmentalizing portions of the code to separate locations in the project according to the functionality of the code.

The scope of this project was limited to functionalities associated with the signup sheet. This meant that logical code that was embedded in "view" (a folder containing html formatting and design code) should be moved to a more appropriate location, the "helpers" folder (this folder contains compartmentalized auxiliary functions that "help" with other parts of the project).

===Tasks Identified===
'''Documents:''' _add_signup_topics.html.erb, _due_dates.html.erb
* Move javascript code to assets (folder): There was some javascript at the bottom of the file _add_signup_topics.html.erb. This was moved to a new file app/assets/javascripts/signup.js. The functions were modified to pass in the number of teams that needed to be toggled (since it is now in a separate file without access to that information). The javascript from the file _due_dates.html.erb was also moved to the new signup.js file.
This functionality can be tested by logging in as an instructor, make sure you are managing assignments, then click the "Edit" button of an assignment (the little pencil icon on the right), then choose the "Topic" tab. If you click "Hide all teams" link, all team names and team member unity ids will be hidden. Click the link again and the content will be shown. If you click individual top names, it should hide/show only one team's info.

'''Documents:''' _suggested_topic.html.erb, intelligent_topic_selection.html.erb
* Move logical code to helper file and assign self-explanatory method names.

'''Documents:''' _all_actions.html.erb, _topic_names.html.erb
* Move logical code to helper file and assign self-explanatory method names.

'''Testing:'''
* Create a test file named sign_up_sheet_helper_spec.rb in spec/helpers
* Write test cases for all methods in sign_up_sheet_helper.rb using factories

====Classes====
* sign_up_sheet_helper.rb
* sign_up_sheet_helper_spec.rb

===Project Modifications===

==== New Method: check_topic_due_date_value() ====
<nowiki> def check_topic_due_date_value(assignment_due_dates, topic_id,
deadline_type_id = 1, review_round = 1)
due_date = get_topic_deadline(assignment_due_dates, topic_id,
deadline_type_id, review_round)
DateTime.parse(due_date.to_s).strftime("%Y-%m-%d %H:%M").in_time_zone
end</nowiki>

==== New Method: get_topic_deadline() ====
<nowiki> def get_topic_deadline(assignment_due_dates, topic_id,
deadline_type_id = 1, review_round = 1)
topic_due_date = TopicDueDate.where(parent_id: topic_id,
deadline_type_id: deadline_type_id,
round: review_round).first rescue nil
if !topic_due_date.nil?
topic_due_date.due_at
else
assignment_due_dates[review_round - 1].due_at.to_s
end
end</nowiki>

==== New Method: get_suggested_topics() ====
<nowiki> def get_suggested_topics(assignment_id)
team_id = TeamsUser.team_id(assignment_id, session[:user].id)
teams_users = TeamsUser.where(team_id: team_id)
teams_users_array = []
teams_users.each do |teams_user|
teams_users_array << teams_user.user_id
end
@suggested_topics = SignUpTopic.where(assignment_id:
assignment_id, private_to: teams_users_array)
end</nowiki>

==== New Method: get_intelligent_topic_row() ====
<nowiki> def get_intelligent_topic_row(topic, selected_topics, max_team_size)
row_html = ''
if !selected_topics.nil? && !selected_topics.empty?
selected_topics.each do |selected_topic|
row_html = if selected_topic.topic_id == topic.id and
!selected_topic.is_waitlisted
'<tr bgcolor="yellow">'
elsif selected_topic.topic_id == topic.id and
selected_topic.is_waitlisted
'<tr bgcolor="lightgray">'
else
'<tr id="topic_' + topic.id.to_s + '">'
end
end
else
row_html = '<tr id="topic_' + topic.id.to_s + '" style="background-color:' +
get_topic_bg_color(topic, max_team_size) + '">'
end
row_html.html_safe
end</nowiki>

==== New Method: get_topic_bg_color() ====
<nowiki>def get_topic_bg_color(topic, max_team_size)
calculation = (400 * (1 - (Math.tanh(2 * [max_team_size.to_f / Bid.where(topic_id:
topic.id).count, 1].min - 1) + 1) / 2)).to_i.to_s
'rgb(' + calculation + ',' + calculation + ',0)'
end</nowiki>

==== New Method: render_participant_info() ====
<nowiki> def render_participant_info(topic, assignment, participants)
name_html = ''
if !participants.nil? && !participants.empty?
chooser_present = false
participants.each do |participant|
next unless topic.id == participant.topic_id
chooser_present = true
if assignment.max_team_size > 1
name_html += ' ' + participant.team_name_placeholder + ' '
end
name_html += 'participant.user_name_placeholder'
if participant.is_waitlisted
name_html += '(waitlisted)'
end
name_html += ' '
end
name_html += 'No choosers.' unless chooser_present
end
name_html.html_safe
end
end</nowiki>

==== New Test for Helper Classes: spec/helpers/sign_up_sheet_helper_spec.rb ====
Implemented positive and negative test cases for all the methods in sign_up_sheet_helper.rb

==Running the Project Remotely==
We have hosted our forked repo so you can review our changes here:

http://138.197.104.185:3000/

Suggested login for Instructor privileges is 'instructor6' with password 'password'. To login as a student, you can use 'student5000' with password 'password'

===Testing Instructions===
====First task====
This functionality can be tested by logging in as an instructor, make sure you are managing assignments, then click the "Edit" button of an assignment (the little pencil icon on the right), then choose the "Topic" tab. If you click "Hide all teams" link, all team names and team member unity ids will be hidden. Click the link again and the content will be shown. If you click individual top names, it should hide/show only one team's info.

====Helper File Changes====
There is no change in the expected behaviour.
* '''get_suggested_topics''': Retrieve list of topics suggested by signed in user for an assignment.
* '''get_intelligent_topic_row''': Render Intelligent Row in bidding based topic selection.
* '''get_topic_bg_color''': Render background color for row based on signed in user and status of the topic.
* '''render_participant_info''': Render Participant Info based on topic, assignment and participants.

==Test Plan==
===Unit Tests===
Unit tests were required per the project assignment for helper methods which previously had no associated unit tests. These tests verified that each discrete method returned the proper values. The tests were written using RSpec/FactoryGirl and are listed above. A summary of the test cases is shown below.

{| class="wikitable"
! colspan="4" | Unit Test Summary
|-
! Method
! Parameters
! Purpose
! Tested Scenarios
|-
| check_topic_due_date_value
| assignment_due_dates, topic_id, deadline_type, review _round
| Check the due date for topic submission given the topic id and assignment due dates.
| a) All nulls, b) Legitimate value for assignment and topic ids
|-
| get_suggested_topics
| assignment_id
| Retrieve topics suggested by the signed in user for an assignment
| a) Signed In user is null b) Legitimate value for assignment and signed in user.
|-
| get_intelligent_topic_row
| topic_id, selected_topic_ids, max_team_size
| Render the row for a topic in intelligent topic selection(bidding) given the topics selected by the students and the maximum permitted team size for the assignment.
| a) Topic Selected by signed in student. b) Topic Selected by signed in student is waitlisted. c) Topic not selected by signed in student. d) Student has not selected any topics.
|-
| render_participant_info
| topic, assignment, participants
| Render Info for participants of a topic for an assignment.
| a) No Participants have been selected. b) Wrong Participants were selected. c) All legitimate values.
|-
|}

====To Run the Unit Tests====
* Navigate to the expertiza home folder
* Run `rspec spec/helpers/sign_up_sheet_helper_spec.rb`

CSC/ECE 517 Spring 2017/oss E1727

2017-03-25T22:58:08Z

George2: Added Test plan in tabular form

==Introduction==
This project was completed as part of a greater open source project called Expertiza.

Expertiza is a web application platform, similar to wikipedia, which offers teachers and students a way to organize for group assignments and porjects. By using Expertiza, students have the ability to submit and coordinate peer-review learning objects (articles, code, web sites, etc). The Expertiza project is supported by the National Science Foundation.

Expertiza offers several features which are useful to a classroom-style learning environment. Among those several features, this project represents a contribution to the organization of the code used for assignment signup sheets.

===Background===
The work for this project was completed by a group of three students from NC State. However, the project was completed according to guidelines provided by a coordinator who works with Expertiza.

Following the guidelines provided, the group worked to clean up a portion of the Expertiza project code through refactorization and reorganization. More specifically, logical code needed to be separated from portions of the project which were not responsible for containing code for the functionality of the application.

===Motivation===
The motivation for this project was to make the project code easier for programmers to read by compartmentalizing portions of the code to separate locations in the project according to the functionality of the code.

The scope of this project was limited to functionalities associated with the signup sheet. This meant that logical code that was embedded in "view" (a folder containing html formatting and design code) should be moved to a more appropriate location, the "helpers" folder (this folder contains compartmentalized auxiliary functions that "help" with other parts of the project).

===Tasks Identified===
'''Documents:''' _add_signup_topics.html.erb, _due_dates.html.erb
* Move javascript code to assets (folder): There was some javascript at the bottom of the file _add_signup_topics.html.erb. This was moved to a new file app/assets/javascripts/signup.js. The functions were modified to pass in the number of teams that needed to be toggled (since it is now in a separate file without access to that information). The javascript from the file _due_dates.html.erb was also moved to the new signup.js file.
This functionality can be tested by logging in as an instructor, make sure you are managing assignments, then click the "Edit" button of an assignment (the little pencil icon on the right), then choose the "Topic" tab. If you click "Hide all teams" link, all team names and team member unity ids will be hidden. Click the link again and the content will be shown. If you click individual top names, it should hide/show only one team's info.

'''Documents:''' _suggested_topic.html.erb, intelligent_topic_selection.html.erb
* Move logical code to helper file and assign self-explanatory method names.

'''Documents:''' _all_actions.html.erb, _topic_names.html.erb
* Move logical code to helper file and assign self-explanatory method names.

'''Testing:'''
* Create a test file named sign_up_sheet_helper_spec.rb in spec/helpers
* Write test cases for all methods in sign_up_sheet_helper.rb using factories

====Classes====
* sign_up_sheet_helper.rb
* sign_up_sheet_helper_spec.rb

===Project Modifications===

==== New Method: check_topic_due_date_value() ====
<nowiki> def check_topic_due_date_value(assignment_due_dates, topic_id,
deadline_type_id = 1, review_round = 1)
due_date = get_topic_deadline(assignment_due_dates, topic_id,
deadline_type_id, review_round)
DateTime.parse(due_date.to_s).strftime("%Y-%m-%d %H:%M").in_time_zone
end</nowiki>

==== New Method: get_topic_deadline() ====
<nowiki> def get_topic_deadline(assignment_due_dates, topic_id,
deadline_type_id = 1, review_round = 1)
topic_due_date = TopicDueDate.where(parent_id: topic_id,
deadline_type_id: deadline_type_id,
round: review_round).first rescue nil
if !topic_due_date.nil?
topic_due_date.due_at
else
assignment_due_dates[review_round - 1].due_at.to_s
end
end</nowiki>

==== New Method: get_suggested_topics() ====
<nowiki> def get_suggested_topics(assignment_id)
team_id = TeamsUser.team_id(assignment_id, session[:user].id)
teams_users = TeamsUser.where(team_id: team_id)
teams_users_array = []
teams_users.each do |teams_user|
teams_users_array << teams_user.user_id
end
@suggested_topics = SignUpTopic.where(assignment_id:
assignment_id, private_to: teams_users_array)
end</nowiki>

==== New Method: get_intelligent_topic_row() ====
<nowiki> def get_intelligent_topic_row(topic, selected_topics, max_team_size)
row_html = ''
if !selected_topics.nil? && !selected_topics.empty?
selected_topics.each do |selected_topic|
row_html = if selected_topic.topic_id == topic.id and
!selected_topic.is_waitlisted
'<tr bgcolor="yellow">'
elsif selected_topic.topic_id == topic.id and
selected_topic.is_waitlisted
'<tr bgcolor="lightgray">'
else
'<tr id="topic_' + topic.id.to_s + '">'
end
end
else
row_html = '<tr id="topic_' + topic.id.to_s + '" style="background-color:' +
get_topic_bg_color(topic, max_team_size) + '">'
end
row_html.html_safe
end</nowiki>

==== New Method: get_topic_bg_color() ====
<nowiki>def get_topic_bg_color(topic, max_team_size)
calculation = (400 * (1 - (Math.tanh(2 * [max_team_size.to_f / Bid.where(topic_id:
topic.id).count, 1].min - 1) + 1) / 2)).to_i.to_s
'rgb(' + calculation + ',' + calculation + ',0)'
end</nowiki>

==== New Method: render_participant_info() ====
<nowiki> def render_participant_info(topic, assignment, participants)
name_html = ''
if !participants.nil? && !participants.empty?
chooser_present = false
participants.each do |participant|
next unless topic.id == participant.topic_id
chooser_present = true
if assignment.max_team_size > 1
name_html += ' ' + participant.team_name_placeholder + ' '
end
name_html += 'participant.user_name_placeholder'
if participant.is_waitlisted
name_html += '(waitlisted)'
end
name_html += ' '
end
name_html += 'No choosers.' unless chooser_present
end
name_html.html_safe
end
end</nowiki>

==== New Test for Helper Classes: spec/helpers/sign_up_sheet_helper_spec.rb ====
Implemented positive and negative test cases for all the methods in sign_up_sheet_helper.rb

==Running the Project Remotely==
We have hosted our forked repo so you can review our changes here:

http://138.197.104.185:3000/

Suggested login for Instructor privileges is 'instructor6' with password 'password'. To login as a student, you can use 'student5000' with password 'password'

===Testing Instructions===
====First task====
This functionality can be tested by logging in as an instructor, make sure you are managing assignments, then click the "Edit" button of an assignment (the little pencil icon on the right), then choose the "Topic" tab. If you click "Hide all teams" link, all team names and team member unity ids will be hidden. Click the link again and the content will be shown. If you click individual top names, it should hide/show only one team's info.

====Helper File Changes====
There is no change in the expected behaviour.
* '''get_suggested_topics''': Retrieve list of topics suggested by signed in user for an assignment.
* '''get_intelligent_topic_row''': Render Intelligent Row in bidding based topic selection.
* '''get_topic_bg_color''': Render background color for row based on signed in user and status of the topic.
* '''render_participant_info''': Render Participant Info based on topic, assignment and participants.

====To Run the Unit Tests====
* Navigate to the expertiza home folder
* Run `rspec spec/helpers/sign_up_sheet_helper_spec.rb`

==Test Plan==
===Unit Tests===
Unit tests were required per the project assignment for helper methods which previously had no associated unit tests. These tests verified that each discrete method returned the proper values. The tests were written using RSpec/FactoryGirl and are listed above. A summary of the test cases is shown below.

{| class="wikitable"
! colspan="4" | Unit Test Summary
|-
! Method
! Parameters
! Purpose
! Tested Scenarios
|-
| check_topic_due_date_value
| assignment_due_dates, topic_id, deadline_type, review _round
| Check the due date for topic submission given the topic id and assignment due dates.
| a) All nulls, b) Legitimate value for assignment and topic ids
|-
| get_suggested_topics
| assignment_id
| Retrieve topics suggested by the signed in user for an assignment
| a) Signed In user is null b) Legitimate value for assignment and signed in user.
|-
| get_intelligent_topic_row
| topic_id, selected_topic_ids, max_team_size
| Render the row for a topic in intelligent topic selection(bidding) given the topics selected by the students and the maximum permitted team size for the assignment.
| a) Topic Selected by signed in student. b) Topic Selected by signed in student is waitlisted. c) Topic not selected by signed in student. d) Student has not selected any topics.
|-
| render_participant_info
| topic, assignment, participants
| Render Info for participants of a topic for an assignment.
| a) No Participants have been selected. b) Wrong Participants were selected. c) All legitimate values.
|-
|}

CSC/ECE 517 Spring 2017/oss E1727

2017-03-25T22:14:38Z

George2: /* Testing Instructions */

==Introduction==
This project was completed as part of a greater open source project called Expertiza.

Expertiza is a web application platform, similar to wikipedia, which offers teachers and students a way to organize for group assignments and porjects. By using Expertiza, students have the ability to submit and coordinate peer-review learning objects (articles, code, web sites, etc). The Expertiza project is supported by the National Science Foundation.

Expertiza offers several features which are useful to a classroom-style learning environment. Among those several features, this project represents a contribution to the organization of the code used for assignment signup sheets.

===Background===
The work for this project was completed by a group of three students from NC State. However, the project was completed according to guidelines provided by a coordinator who works with Expertiza.

Following the guidelines provided, the group worked to clean up a portion of the Expertiza project code through refactorization and reorganization. More specifically, logical code needed to be separated from portions of the project which were not responsible for containing code for the functionality of the application.

===Motivation===
The motivation for this project was to make the project code easier for programmers to read by compartmentalizing portions of the code to separate locations in the project according to the functionality of the code.

The scope of this project was limited to functionalities associated with the signup sheet. This meant that logical code that was embedded in "view" (a folder containing html formatting and design code) should be moved to a more appropriate location, the "helpers" folder (this folder contains compartmentalized auxiliary functions that "help" with other parts of the project).

===Tasks Identified===
'''Documents:''' _add_signup_topics.html.erb, _due_dates.html.erb
* Move javascript code to assets (folder): There was some javascript at the bottom of the file _add_signup_topics.html.erb. This was moved to a new file app/assets/javascripts/signup.js. The functions were modified to pass in the number of teams that needed to be toggled (since it is now in a separate file without access to that information). The javascript from the file _due_dates.html.erb was also moved to the new signup.js file.
This functionality can be tested by logging in as an instructor, make sure you are managing assignments, then click the "Edit" button of an assignment (the little pencil icon on the right), then choose the "Topic" tab. If you click "Hide all teams" link, all team names and team member unity ids will be hidden. Click the link again and the content will be shown. If you click individual top names, it should hide/show only one team's info.

'''Documents:''' _suggested_topic.html.erb, intelligent_topic_selection.html.erb
* Move logical code to helper file and assign self-explanatory method names.

'''Documents:''' _all_actions.html.erb, _topic_names.html.erb
* Move logical code to helper file and assign self-explanatory method names.

'''Testing:'''
* Create a test file named sign_up_sheet_helper_spec.rb in spec/helpers
* Write test cases for all methods in sign_up_sheet_helper.rb using factories

====Classes====
* sign_up_sheet_helper.rb
* sign_up_sheet_helper_spec.rb

===Project Modifications===

==== New Method: check_topic_due_date_value() ====
<nowiki> def check_topic_due_date_value(assignment_due_dates, topic_id,
deadline_type_id = 1, review_round = 1)
due_date = get_topic_deadline(assignment_due_dates, topic_id,
deadline_type_id, review_round)
DateTime.parse(due_date.to_s).strftime("%Y-%m-%d %H:%M").in_time_zone
end</nowiki>

==== New Method: get_topic_deadline() ====
<nowiki> def get_topic_deadline(assignment_due_dates, topic_id,
deadline_type_id = 1, review_round = 1)
topic_due_date = TopicDueDate.where(parent_id: topic_id,
deadline_type_id: deadline_type_id,
round: review_round).first rescue nil
if !topic_due_date.nil?
topic_due_date.due_at
else
assignment_due_dates[review_round - 1].due_at.to_s
end
end</nowiki>

==== New Method: get_suggested_topics() ====
<nowiki> def get_suggested_topics(assignment_id)
team_id = TeamsUser.team_id(assignment_id, session[:user].id)
teams_users = TeamsUser.where(team_id: team_id)
teams_users_array = []
teams_users.each do |teams_user|
teams_users_array << teams_user.user_id
end
@suggested_topics = SignUpTopic.where(assignment_id:
assignment_id, private_to: teams_users_array)
end</nowiki>

==== New Method: get_intelligent_topic_row() ====
<nowiki> def get_intelligent_topic_row(topic, selected_topics, max_team_size)
row_html = ''
if !selected_topics.nil? && !selected_topics.empty?
selected_topics.each do |selected_topic|
row_html = if selected_topic.topic_id == topic.id and
!selected_topic.is_waitlisted
'<tr bgcolor="yellow">'
elsif selected_topic.topic_id == topic.id and
selected_topic.is_waitlisted
'<tr bgcolor="lightgray">'
else
'<tr id="topic_' + topic.id.to_s + '">'
end
end
else
row_html = '<tr id="topic_' + topic.id.to_s + '" style="background-color:' +
get_topic_bg_color(topic, max_team_size) + '">'
end
row_html.html_safe
end</nowiki>

==== New Method: get_topic_bg_color() ====
<nowiki>def get_topic_bg_color(topic, max_team_size)
calculation = (400 * (1 - (Math.tanh(2 * [max_team_size.to_f / Bid.where(topic_id:
topic.id).count, 1].min - 1) + 1) / 2)).to_i.to_s
'rgb(' + calculation + ',' + calculation + ',0)'
end</nowiki>

==== New Method: render_participant_info() ====
<nowiki> def render_participant_info(topic, assignment, participants)
name_html = ''
if !participants.nil? && !participants.empty?
chooser_present = false
participants.each do |participant|
next unless topic.id == participant.topic_id
chooser_present = true
if assignment.max_team_size > 1
name_html += ' ' + participant.team_name_placeholder + ' '
end
name_html += 'participant.user_name_placeholder'
if participant.is_waitlisted
name_html += '(waitlisted)'
end
name_html += ' '
end
name_html += 'No choosers.' unless chooser_present
end
name_html.html_safe
end
end</nowiki>

==== New Test for Helper Classes: spec/helpers/sign_up_sheet_helper_spec.rb ====
Implemented positive and negative test cases for all the methods in sign_up_sheet_helper.rb

==Running the Project Remotely==
We have hosted our forked repo so you can review our changes here:

http://138.197.104.185:3000/

Suggested login for Instructor privileges is 'instructor6' with password 'password'. To login as a student, you can use 'student5000' with password 'password'

===Testing Instructions===
====First task====
This functionality can be tested by logging in as an instructor, make sure you are managing assignments, then click the "Edit" button of an assignment (the little pencil icon on the right), then choose the "Topic" tab. If you click "Hide all teams" link, all team names and team member unity ids will be hidden. Click the link again and the content will be shown. If you click individual top names, it should hide/show only one team's info.

====Helper File Changes====
There is no change in the expected behaviour.
* '''get_suggested_topics''': Retrieve list of topics suggested by signed in user for an assignment.
* '''get_intelligent_topic_row''': Render Intelligent Row in bidding based topic selection.
* '''get_topic_bg_color''': Render background color for row based on signed in user and status of the topic.
* '''render_participant_info''': Render Participant Info based on topic, assignment and participants.

====To Run the Unit Tests====
* Navigate to the expertiza home folder
* Run `rspec spec/helpers/sign_up_sheet_helper_spec.rb`

CSC/ECE 517 Spring 2017/oss E1727

2017-03-23T00:15:29Z

George2: /* Project Modifications */

==Introduction==
This project was completed as part of a greater open source project called Expertiza.

Expertiza is a web application platform, similar to wikipedia, which offers teachers and students a way to organize for group assignments and porjects. By using Expertiza, students have the ability to submit and coordinate peer-review learning objects (articles, code, web sites, etc). The Expertiza project is supported by the National Science Foundation.

Expertiza offers several features which are useful to a classroom-style learning environment. Among those several features, this project represents a contribution to the organization of the code used for assignment signup sheets.

===Background===
The work for this project was completed by a group of three students from NC State. However, the project was completed according to guidelines provided by a coordinator who works with Expertiza.

Following the guidelines provided, the group worked to clean up a portion of the Expertiza project code through refactorization and reorganization. More specifically, logical code needed to be separated from portions of the project which were not responsible for containing code for the functionality of the application.

===Motivation===
The motivation for this project was to make the project code easier for programmers to read by compartmentalizing portions of the code to separate locations in the project according to the functionality of the code.

The scope of this project was limited to functionalities associated with the signup sheet. This meant that logical code that was embedded in "view" (a folder containing html formatting and design code) should be moved to a more appropriate location, the "helpers" folder (this folder contains compartmentalized auxiliary functions that "help" with other parts of the project).

===Tasks Identified===
'''Documents:''' _add_signup_topics.html.erb, _due_dates.html.erb
* Move javascript code to assets (folder): There was some javascript at the bottom of the file _add_signup_topics.html.erb. This was moved to a new file app/assets/javascripts/signup.js. The functions were modified to pass in the number of teams that needed to be toggled (since it is now in a separate file without access to that information). The javascript from the file _due_dates.html.erb was also moved to the new signup.js file.
This functionality can be tested by logging in as an instructor, make sure you are managing assignments, then click the "Edit" button of an assignment (the little pencil icon on the right), then choose the "Topic" tab. If you click "Hide all teams" link, all team names and team member unity ids will be hidden. Click the link again and the content will be shown. If you click individual top names, it should hide/show only one team's info.

'''Documents:''' _suggested_topic.html.erb, intelligent_topic_selection.html.erb
* Move logical code to helper file and assign self-explanatory method names.

'''Documents:''' _all_actions.html.erb, _topic_names.html.erb
* Move logical code to helper file and assign self-explanatory method names.

'''Testing:'''
* Create a test file named sign_up_sheet_helper_spec.rb in spec/helpers
* Write test cases for all methods in sign_up_sheet_helper.rb using factories

====Classes====
* sign_up_sheet_helper.rb
* sign_up_sheet_helper_spec.rb

===Project Modifications===

==== New Method: get_suggested_topics() ====
<nowiki> def get_suggested_topics(assignment_id)
team_id = TeamsUser.team_id(assignment_id, session[:user].id)
teams_users = TeamsUser.where(team_id: team_id)
teams_users_array = Array.new
teams_users.each do |teams_user|
teams_users_array << teams_user.user_id
end
@suggested_topics = SignUpTopic.where(assignment_id: assignment_id, private_to: teams_users_array)
end</nowiki>

==== New Method: get_intelligent_topic_row() ====
<nowiki> def get_intelligent_topic_row(topic, selected_topics)
row_html = ''
if !selected_topics.nil? && selected_topics.size != 0
for selected_topic in @selected_topics
if selected_topic.topic_id == topic.id and !selected_topic.is_waitlisted
row_html = '<tr bgcolor="yellow">'
elsif selected_topic.topic_id == topic.id and selected_topic.is_waitlisted
row_html = '<tr bgcolor="lightgray">'
else
row_html = '<tr id="topic_"' + topic.id.to_s + '>'
end
end
else
row_html = '<tr id="topic_"' + topic.id.to_s + ' style="background-color:' + get_topic_bg_color(topic) + '">'
end
row_html.html_safe
end</nowiki>

==== New Method: get_topic_bg_color() ====
<nowiki> def get_topic_bg_color(topic)
'rgb(' + (400*(1-(Math.tanh(2*[@max_team_size.to_f/Bid.where(topic_id:topic.id).count,1].min-1)+1)/2))
.to_i.to_s + ',' + (400*(Math.tanh(2*[@max_team_size.to_f/Bid.where(topic_id:topic.id).
count,1].min-1)+1)/2).to_i.to_s + ',0)'
end</nowiki>

==== New Method: render_participant_info() ====
<nowiki> def render_participant_info(topic, assignment, participants)
name_html = ''
if !participants.nil? && participants.size > 0
chooser_present = false
for participant in @participants
if topic.id == participant.topic_id
chooser_present = true
if assignment.max_team_size > 1
name_html += ' ' + participant.team_name_placeholder + ' '
end
name_html += 'participant.user_name_placeholder'
if participant.is_waitlisted
name_html += '(waitlisted)'
end
name_html += ' '
end
end
unless chooser_present
name_html += 'No choosers.'
end
end
name_html.html_safe
end</nowiki>

==== New Test for Helper Classes: spec/helpers/sign_up_sheet_helper_spec.rb ====
Implemented positive and negative test cases for all the methods in sign_up_sheet_helper.rb

==Running the Project Remotely==
We have hosted our forked repo so you can review our changes here:

http://138.197.104.185:3000/

Suggested login for Instructor privileges is 'instructor6' with password 'password'. To login as a student, you can use 'student5000' with password 'password'

===Testing Instructions===
====First task====
This functionality can be tested by logging in as an instructor, make sure you are managing assignments, then click the "Edit" button of an assignment (the little pencil icon on the right), then choose the "Topic" tab. If you click "Hide all teams" link, all team names and team member unity ids will be hidden. Click the link again and the content will be shown. If you click individual top names, it should hide/show only one team's info.

====Helper File Changes====
There is no change in the expected behaviour.
* '''get_suggested_topics''': Retrieve list of topics suggested by signed in user for an assignment.
* '''get_intelligent_topic_row''': Render Intelligent Row in bidding based topic selection.
* '''get_topic_bg_color''': Render background color for row based on signed in user and status of the topic.
* '''render_participant_info''': Render Participant Info based on topic, assignment and participants.

==Future Work==

CSC/ECE 517 Spring 2017/oss E1727

2017-03-23T00:15:01Z

George2: Helper File Changes

==Introduction==
This project was completed as part of a greater open source project called Expertiza.

Expertiza is a web application platform, similar to wikipedia, which offers teachers and students a way to organize for group assignments and porjects. By using Expertiza, students have the ability to submit and coordinate peer-review learning objects (articles, code, web sites, etc). The Expertiza project is supported by the National Science Foundation.

Expertiza offers several features which are useful to a classroom-style learning environment. Among those several features, this project represents a contribution to the organization of the code used for assignment signup sheets.

===Background===
The work for this project was completed by a group of three students from NC State. However, the project was completed according to guidelines provided by a coordinator who works with Expertiza.

Following the guidelines provided, the group worked to clean up a portion of the Expertiza project code through refactorization and reorganization. More specifically, logical code needed to be separated from portions of the project which were not responsible for containing code for the functionality of the application.

===Motivation===
The motivation for this project was to make the project code easier for programmers to read by compartmentalizing portions of the code to separate locations in the project according to the functionality of the code.

The scope of this project was limited to functionalities associated with the signup sheet. This meant that logical code that was embedded in "view" (a folder containing html formatting and design code) should be moved to a more appropriate location, the "helpers" folder (this folder contains compartmentalized auxiliary functions that "help" with other parts of the project).

===Tasks Identified===
'''Documents:''' _add_signup_topics.html.erb, _due_dates.html.erb
* Move javascript code to assets (folder): There was some javascript at the bottom of the file _add_signup_topics.html.erb. This was moved to a new file app/assets/javascripts/signup.js. The functions were modified to pass in the number of teams that needed to be toggled (since it is now in a separate file without access to that information). The javascript from the file _due_dates.html.erb was also moved to the new signup.js file.
This functionality can be tested by logging in as an instructor, make sure you are managing assignments, then click the "Edit" button of an assignment (the little pencil icon on the right), then choose the "Topic" tab. If you click "Hide all teams" link, all team names and team member unity ids will be hidden. Click the link again and the content will be shown. If you click individual top names, it should hide/show only one team's info.

'''Documents:''' _suggested_topic.html.erb, intelligent_topic_selection.html.erb
* Move logical code to helper file and assign self-explanatory method names.

'''Documents:''' _all_actions.html.erb, _topic_names.html.erb
* Move logical code to helper file and assign self-explanatory method names.

'''Testing:'''
* Create a test file named sign_up_sheet_helper_spec.rb in spec/helpers
* Write test cases for all methods in sign_up_sheet_helper.rb using factories

====Classes====
* sign_up_sheet_helper.rb
* sign_up_sheet_helper_spec.rb

===Project Modifications===

==== New Method: check_topic_due_date_value() ====
<nowiki> def check_topic_due_date_value(assignment_due_dates, topic_id, deadline_type_id = 1, review_round = 1)
due_date = get_topic_deadline(assignment_due_dates, topic_id, deadline_type_id, review_round)
DateTime.parse(due_date.to_s).strftime("%Y-%m-%d %H:%M").in_time_zone
end</nowiki>

==== New Method: get_topic_deadline() ====
<nowiki> def get_topic_deadline(assignment_due_dates, topic_id, deadline_type_id = 1, review_round = 1)
topic_due_date = TopicDueDate.where(parent_id: topic_id,
deadline_type_id: deadline_type_id,
round: review_round).first rescue nil
if !topic_due_date.nil?
topic_due_date.due_at
else
assignment_due_dates[review_round - 1].due_at.to_s
end
end</nowiki>

==== New Method: get_suggested_topics() ====
<nowiki> def get_suggested_topics(assignment_id)
team_id = TeamsUser.team_id(assignment_id, session[:user].id)
teams_users = TeamsUser.where(team_id: team_id)
teams_users_array = Array.new
teams_users.each do |teams_user|
teams_users_array << teams_user.user_id
end
@suggested_topics = SignUpTopic.where(assignment_id: assignment_id, private_to: teams_users_array)
end</nowiki>

==== New Method: get_intelligent_topic_row() ====
<nowiki> def get_intelligent_topic_row(topic, selected_topics)
row_html = ''
if !selected_topics.nil? && selected_topics.size != 0
for selected_topic in @selected_topics
if selected_topic.topic_id == topic.id and !selected_topic.is_waitlisted
row_html = '<tr bgcolor="yellow">'
elsif selected_topic.topic_id == topic.id and selected_topic.is_waitlisted
row_html = '<tr bgcolor="lightgray">'
else
row_html = '<tr id="topic_"' + topic.id.to_s + '>'
end
end
else
row_html = '<tr id="topic_"' + topic.id.to_s + ' style="background-color:' + get_topic_bg_color(topic) + '">'
end
row_html.html_safe
end</nowiki>

==== New Method: get_topic_bg_color() ====
<nowiki> def get_topic_bg_color(topic)
'rgb(' + (400*(1-(Math.tanh(2*[@max_team_size.to_f/Bid.where(topic_id:topic.id).count,1].min-1)+1)/2))
.to_i.to_s + ',' + (400*(Math.tanh(2*[@max_team_size.to_f/Bid.where(topic_id:topic.id).
count,1].min-1)+1)/2).to_i.to_s + ',0)'
end</nowiki>

==== New Method: render_participant_info() ====
<nowiki> def render_participant_info(topic, assignment, participants)
name_html = ''
if !participants.nil? && participants.size > 0
chooser_present = false
for participant in @participants
if topic.id == participant.topic_id
chooser_present = true
if assignment.max_team_size > 1
name_html += ' ' + participant.team_name_placeholder + ' '
end
name_html += 'participant.user_name_placeholder'
if participant.is_waitlisted
name_html += '(waitlisted)'
end
name_html += ' '
end
end
unless chooser_present
name_html += 'No choosers.'
end
end
name_html.html_safe
end</nowiki>

==== New Test for Helper Classes: spec/helpers/sign_up_sheet_helper_spec.rb ====
Implemented positive and negative test cases for all the methods in sign_up_sheet_helper.rb

==Running the Project Remotely==
We have hosted our forked repo so you can review our changes here:

http://138.197.104.185:3000/

Suggested login for Instructor privileges is 'instructor6' with password 'password'. To login as a student, you can use 'student5000' with password 'password'

===Testing Instructions===
====First task====
This functionality can be tested by logging in as an instructor, make sure you are managing assignments, then click the "Edit" button of an assignment (the little pencil icon on the right), then choose the "Topic" tab. If you click "Hide all teams" link, all team names and team member unity ids will be hidden. Click the link again and the content will be shown. If you click individual top names, it should hide/show only one team's info.

====Helper File Changes====
There is no change in the expected behaviour.
* '''get_suggested_topics''': Retrieve list of topics suggested by signed in user for an assignment.
* '''get_intelligent_topic_row''': Render Intelligent Row in bidding based topic selection.
* '''get_topic_bg_color''': Render background color for row based on signed in user and status of the topic.
* '''render_participant_info''': Render Participant Info based on topic, assignment and participants.

==Future Work==

CSC/ECE 517 Spring 2017/oss E1727

2017-03-22T23:53:30Z

George2: /* Project Modifications */

==Introduction==
This project was completed as part of a greater open source project called Expertiza.

Expertiza is a web application platform, similar to wikipedia, which offers teachers and students a way to organize for group assignments and porjects. By using Expertiza, students have the ability to submit and coordinate peer-review learning objects (articles, code, web sites, etc). The Expertiza project is supported by the National Science Foundation.

Expertiza offers several features which are useful to a classroom-style learning environment. Among those several features, this project represents a contribution to the organization of the code used for assignment signup sheets.

===Background===
The work for this project was completed by a group of three students from NC State. However, the project was completed according to guidelines provided by a coordinator who works with Expertiza.

Following the guidelines provided, the group worked to clean up a portion of the Expertiza project code through refactorization and reorganization. More specifically, logical code needed to be separated from portions of the project which were not responsible for containing code for the functionality of the application.

===Motivation===
The motivation for this project was to make the project code easier for programmers to read by compartmentalizing portions of the code to separate locations in the project according to the functionality of the code.

The scope of this project was limited to functionalities associated with the signup sheet. This meant that logical code that was embedded in "view" (a folder containing html formatting and design code) should be moved to a more appropriate location, the "helpers" folder (this folder contains compartmentalized auxiliary functions that "help" with other parts of the project).

===Tasks Identified===
'''Documents:''' _add_signup_topics.html.erb, _due_dates.html.erb
* Move javascript code to assets (folder): There was some javascript at the bottom of the file _add_signup_topics.html.erb. This was moved to a new file app/assets/javascripts/signup.js. The functions were modified to pass in the number of teams that needed to be toggled (since it is now in a separate file without access to that information). The javascript from the file _due_dates.html.erb was also moved to the new signup.js file.
This functionality can be tested by logging in as an instructor, make sure you are managing assignments, then click the "Edit" button of an assignment (the little pencil icon on the right), then choose the "Topic" tab. If you click "Hide all teams" link, all team names and team member unity ids will be hidden. Click the link again and the content will be shown. If you click individual top names, it should hide/show only one team's info.

'''Documents:''' _suggested_topic.html.erb, intelligent_topic_selection.html.erb
* Move logical code to helper file and assign self-explanatory method names.

'''Documents:''' _all_actions.html.erb, _topic_names.html.erb
* Move logical code to helper file and assign self-explanatory method names.

'''Testing:'''
* Create a test file named sign_up_sheet_helper_spec.rb in spec/helpers
* Write test cases for all methods in sign_up_sheet_helper.rb using factories

====Classes====
* sign_up_sheet_helper.rb
* sign_up_sheet_helper_spec.rb

===Project Modifications===

==== New Method: check_topic_due_date_value() ====
<nowiki> def check_topic_due_date_value(assignment_due_dates, topic_id, deadline_type_id = 1, review_round = 1)
due_date = get_topic_deadline(assignment_due_dates, topic_id, deadline_type_id, review_round)
DateTime.parse(due_date.to_s).strftime("%Y-%m-%d %H:%M").in_time_zone
end</nowiki>

==== New Method: get_topic_deadline() ====
<nowiki> def get_topic_deadline(assignment_due_dates, topic_id, deadline_type_id = 1, review_round = 1)
topic_due_date = TopicDueDate.where(parent_id: topic_id,
deadline_type_id: deadline_type_id,
round: review_round).first rescue nil
if !topic_due_date.nil?
topic_due_date.due_at
else
assignment_due_dates[review_round - 1].due_at.to_s
end
end</nowiki>

==== New Method: get_suggested_topics() ====
<nowiki> def get_suggested_topics(assignment_id)
team_id = TeamsUser.team_id(assignment_id, session[:user].id)
teams_users = TeamsUser.where(team_id: team_id)
teams_users_array = Array.new
teams_users.each do |teams_user|
teams_users_array << teams_user.user_id
end
@suggested_topics = SignUpTopic.where(assignment_id: assignment_id, private_to: teams_users_array)
end</nowiki>

==== New Method: get_intelligent_topic_row() ====
<nowiki> def get_intelligent_topic_row(topic, selected_topics)
row_html = ''
if !selected_topics.nil? && selected_topics.size != 0
for selected_topic in @selected_topics
if selected_topic.topic_id == topic.id and !selected_topic.is_waitlisted
row_html = '<tr bgcolor="yellow">'
elsif selected_topic.topic_id == topic.id and selected_topic.is_waitlisted
row_html = '<tr bgcolor="lightgray">'
else
row_html = '<tr id="topic_"' + topic.id.to_s + '>'
end
end
else
row_html = '<tr id="topic_"' + topic.id.to_s + ' style="background-color:' + get_topic_bg_color(topic) + '">'
end
row_html.html_safe
end</nowiki>

==== New Method: get_topic_bg_color() ====
<nowiki> def get_topic_bg_color(topic)
'rgb(' + (400*(1-(Math.tanh(2*[@max_team_size.to_f/Bid.where(topic_id:topic.id).count,1].min-1)+1)/2))
.to_i.to_s + ',' + (400*(Math.tanh(2*[@max_team_size.to_f/Bid.where(topic_id:topic.id).
count,1].min-1)+1)/2).to_i.to_s + ',0)'
end</nowiki>

==== New Method: render_participant_info() ====
<nowiki> def render_participant_info(topic, assignment, participants)
name_html = ''
if !participants.nil? && participants.size > 0
chooser_present = false
for participant in @participants
if topic.id == participant.topic_id
chooser_present = true
if assignment.max_team_size > 1
name_html += ' ' + participant.team_name_placeholder + ' '
end
name_html += 'participant.user_name_placeholder'
if participant.is_waitlisted
name_html += '(waitlisted)'
end
name_html += ' '
end
end
unless chooser_present
name_html += 'No choosers.'
end
end
name_html.html_safe
end</nowiki>

==== New Test for Helper Classes: spec/helpers/sign_up_sheet_helper_spec.rb ====
Implemented positive and negative test cases for all the methods in sign_up_sheet_helper.rb

==Running the Project Remotely==
We have hosted our forked repo so you can review our changes here:

http://138.197.104.185:3000/

Suggested login for Instructor privileges is 'instructor6' with password 'password'. To login as a student, you can use 'student5000' with password 'password'

===Testing Instructions===
====First task====
This functionality can be tested by logging in as an instructor, make sure you are managing assignments, then click the "Edit" button of an assignment (the little pencil icon on the right), then choose the "Topic" tab. If you click "Hide all teams" link, all team names and team member unity ids will be hidden. Click the link again and the content will be shown. If you click individual top names, it should hide/show only one team's info.

==Future Work==

CSC/ECE 517 Spring 2017/oss E1727

2017-03-22T23:42:58Z

George2: Added Test Data

==Introduction==
This project was completed as part of a greater open source project called Expertiza.

Expertiza is a web application platform, similar to wikipedia, which offers teachers and students a way to organize for group assignments and porjects. By using Expertiza, students have the ability to submit and coordinate peer-review learning objects (articles, code, web sites, etc). The Expertiza project is supported by the National Science Foundation.

Expertiza offers several features which are useful to a classroom-style learning environment. Among those several features, this project represents a contribution to the organization of the code used for assignment signup sheets.

===Background===
The work for this project was completed by a group of three students from NC State. However, the project was completed according to guidelines provided by a coordinator who works with Expertiza.

Following the guidelines provided, the group worked to clean up a portion of the Expertiza project code through refactorization and reorganization. More specifically, logical code needed to be separated from portions of the project which were not responsible for containing code for the functionality of the application.

===Motivation===
The motivation for this project was to make the project code easier for programmers to read by compartmentalizing portions of the code to separate locations in the project according to the functionality of the code.

The scope of this project was limited to functionalities associated with the signup sheet. This meant that logical code that was embedded in "view" (a folder containing html formatting and design code) should be moved to a more appropriate location, the "helpers" folder (this folder contains compartmentalized auxiliary functions that "help" with other parts of the project).

===Tasks Identified===
'''Documents:''' _add_signup_topics.html.erb, _due_dates.html.erb
* Move javascript code to assets (folder): There was some javascript at the bottom of the file _add_signup_topics.html.erb. This was moved to a new file app/assets/javascripts/signup.js. The functions were modified to pass in the number of teams that needed to be toggled (since it is now in a separate file without access to that information). The javascript from the file _due_dates.html.erb was also moved to the new signup.js file.
This functionality can be tested by logging in as an instructor, make sure you are managing assignments, then click the "Edit" button of an assignment (the little pencil icon on the right), then choose the "Topic" tab. If you click "Hide all teams" link, all team names and team member unity ids will be hidden. Click the link again and the content will be shown. If you click individual top names, it should hide/show only one team's info.

'''Documents:''' _suggested_topic.html.erb, intelligent_topic_selection.html.erb
* Move logical code to helper file and assign self-explanatory method names.

'''Documents:''' _all_actions.html.erb, _topic_names.html.erb
* Move logical code to helper file and assign self-explanatory method names.

'''Testing:'''
* Create a test file named sign_up_sheet_helper_spec.rb in spec/helpers
* Write test cases for all methods in sign_up_sheet_helper.rb using factories

====Classes====
* sign_up_sheet_helper.rb
* sign_up_sheet_helper_spec.rb

===Project Modifications===

==== New Method: check_topic_due_date_value() ====
<nowiki> def check_topic_due_date_value(assignment_due_dates, topic_id, deadline_type_id = 1, review_round = 1)
due_date = get_topic_deadline(assignment_due_dates, topic_id, deadline_type_id, review_round)
DateTime.parse(due_date.to_s).strftime("%Y-%m-%d %H:%M").in_time_zone
end</nowiki>

==== New Method: get_topic_deadline() ====
<nowiki> def get_topic_deadline(assignment_due_dates, topic_id, deadline_type_id = 1, review_round = 1)
topic_due_date = TopicDueDate.where(parent_id: topic_id,
deadline_type_id: deadline_type_id,
round: review_round).first rescue nil
if !topic_due_date.nil?
topic_due_date.due_at
else
assignment_due_dates[review_round - 1].due_at.to_s
end
end</nowiki>

==== New Method: get_suggested_topics() ====
<nowiki> def get_suggested_topics(assignment_id)
team_id = TeamsUser.team_id(assignment_id, session[:user].id)
teams_users = TeamsUser.where(team_id: team_id)
teams_users_array = Array.new
teams_users.each do |teams_user|
teams_users_array << teams_user.user_id
end
@suggested_topics = SignUpTopic.where(assignment_id: assignment_id, private_to: teams_users_array)
end</nowiki>

==== New Method: get_intelligent_topic_row() ====
<nowiki> def get_intelligent_topic_row(topic, selected_topics)
row_html = ''
if !selected_topics.nil? && selected_topics.size != 0
for selected_topic in @selected_topics
if selected_topic.topic_id == topic.id and !selected_topic.is_waitlisted
row_html = '<tr bgcolor="yellow">'
elsif selected_topic.topic_id == topic.id and selected_topic.is_waitlisted
row_html = '<tr bgcolor="lightgray">'
else
row_html = '<tr id="topic_"' + topic.id.to_s + '>'
end
end
else
row_html = '<tr id="topic_"' + topic.id.to_s + ' style="background-color:' + get_topic_bg_color(topic) + '">'
end
row_html.html_safe
end</nowiki>

==== New Method: get_topic_bg_color() ====
<nowiki> def get_topic_bg_color(topic)
'rgb(' + (400*(1-(Math.tanh(2*[@max_team_size.to_f/Bid.where(topic_id:topic.id).count,1].min-1)+1)/2))
.to_i.to_s + ',' + (400*(Math.tanh(2*[@max_team_size.to_f/Bid.where(topic_id:topic.id).
count,1].min-1)+1)/2).to_i.to_s + ',0)'
end</nowiki>

==== New Method: render_participant_info() ====
<nowiki> def render_participant_info(topic, assignment, participants)
name_html = ''
if !participants.nil? && participants.size > 0
chooser_present = false
for participant in @participants
if topic.id == participant.topic_id
chooser_present = true
if assignment.max_team_size > 1
name_html += ' ' + participant.team_name_placeholder + ' '
end
name_html += 'participant.user_name_placeholder'
if participant.is_waitlisted
name_html += '(waitlisted)'
end
name_html += ' '
end
end
unless chooser_present
name_html += 'No choosers.'
end
end
name_html.html_safe
end</nowiki>

==Running the Project Remotely==
We have hosted our forked repo so you can review our changes here:

http://138.197.104.185:3000/

Suggested login for Instructor privileges is 'instructor6' with password 'password'. To login as a student, you can use 'student5000' with password 'password'

===Testing Instructions===
====First task====
This functionality can be tested by logging in as an instructor, make sure you are managing assignments, then click the "Edit" button of an assignment (the little pencil icon on the right), then choose the "Topic" tab. If you click "Hide all teams" link, all team names and team member unity ids will be hidden. Click the link again and the content will be shown. If you click individual top names, it should hide/show only one team's info.

==Future Work==