Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2013/Final E728

2013-04-05T01:36:57Z

Dshuffma: /* Team Members */

== Final Project E728 ==

'''Design Document'''
__TOC__

== Introduction ==
The E728 project focuses on improving the review section's layout and usefulness. <ref name='assignment'> https://docs.google.com/document/d/11YTjxFXFR13vJ769yFBbqn9qOueK2Ktz0Pd-gyS2W5U/edit</ref> Our plan is to breakdown the [http://www.reddit.com/r/FieldOfKarmicGlory/comments/1beq5p/the_rules_of_battle/ assignment] and address each goal.
#Tabular Reviews - Use a table with tabs to view the reviews. The tabs will select which review is active. The table will hold the questions on the left, and corresponding reviewer score and comment on the right.
#Submission Type Indicator - A visual clue (can be either text message, color coded, or image icon) will be added to distinguish if a review is an original or updated review.
#Bug Fix - Figure out if a particular bug still exists, if so fix it. The bug happens when a one clicks on a particular review and it does not display the feedback form the review.
#Meta-review Relations - Create a link or add text to indicate which review the meta-review was written about.
#Update View Scores - Improve the view scores page by adding filters.
#Restructure HTML Generation - Move as much code that generates HTML from the models to the views.

==Team Members==
*David Pratt - dcpratt
*David Huffman - dshuffma

== Goal Mock-Ups==

===Tabular Reviews===
The current review page is shown below. A [http://en.wikipedia.org/wiki/Mockup mock-up] of the planned changes is also shown below.
{| class="wikitable"
! style="width: 600px" | Before
|-
|[[File:orig.PNG|Before]]
|}

{| class="wikitable"
! style="width: 600px" | After (mock-up)
|-
|[[File:Planned.PNG|After (mock-up)]]
|}

Notice that the reviews have moved from sequential listing to displaying one at a time in a table. The other views can be seen by clicking their respective link which might be styled as a 'tab'.

===Submission Indicator===

One option is to color code the review links to indicate an updated review. In the mock-up below the updated review link is green. A key will be needed to inform users of the distinction.

{| class="wikitable"
! style="width: 200px" | Color-coding (mock-up)
|-
|[[File:New_rev.png|After (mock-up)]]
|}

===Meta-review Relations===
A summary of the review's information can be displayed below the review. The image below shows some information that may be useful including the source of the meta-review.

{| class="wikitable"
! style="width: 200px" | Color-coding (mock-up)
|-
|[[File:rev_info.png|After (mock-up)]]
|}

== Design Goals ==
Most of the design patterns are difficult to apply since we will be focusing on the views only and not gathering and structuring the data. From what we can tell the data is already there and sent to the view. We should not need to edit the models or controllers much, except for goal 6 (Restructure HTML Generation). In any case we expect to stay DRY, and comment our code for easy understanding and future integration. We will adhear to the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] architecture and as such will add the necessary code to its correct position.

== References ==
<references/>

CSC/ECE 517 Spring 2013/Final E728

2013-04-05T01:36:46Z

Dshuffma:

== Final Project E728 ==

'''Design Document'''
__TOC__

== Introduction ==
The E728 project focuses on improving the review section's layout and usefulness. <ref name='assignment'> https://docs.google.com/document/d/11YTjxFXFR13vJ769yFBbqn9qOueK2Ktz0Pd-gyS2W5U/edit</ref> Our plan is to breakdown the [http://www.reddit.com/r/FieldOfKarmicGlory/comments/1beq5p/the_rules_of_battle/ assignment] and address each goal.
#Tabular Reviews - Use a table with tabs to view the reviews. The tabs will select which review is active. The table will hold the questions on the left, and corresponding reviewer score and comment on the right.
#Submission Type Indicator - A visual clue (can be either text message, color coded, or image icon) will be added to distinguish if a review is an original or updated review.
#Bug Fix - Figure out if a particular bug still exists, if so fix it. The bug happens when a one clicks on a particular review and it does not display the feedback form the review.
#Meta-review Relations - Create a link or add text to indicate which review the meta-review was written about.
#Update View Scores - Improve the view scores page by adding filters.
#Restructure HTML Generation - Move as much code that generates HTML from the models to the views.

==Team Members==
David Pratt - dcpratt
David Huffman - dshuffma

== Goal Mock-Ups==

===Tabular Reviews===
The current review page is shown below. A [http://en.wikipedia.org/wiki/Mockup mock-up] of the planned changes is also shown below.
{| class="wikitable"
! style="width: 600px" | Before
|-
|[[File:orig.PNG|Before]]
|}

{| class="wikitable"
! style="width: 600px" | After (mock-up)
|-
|[[File:Planned.PNG|After (mock-up)]]
|}

Notice that the reviews have moved from sequential listing to displaying one at a time in a table. The other views can be seen by clicking their respective link which might be styled as a 'tab'.

===Submission Indicator===

One option is to color code the review links to indicate an updated review. In the mock-up below the updated review link is green. A key will be needed to inform users of the distinction.

{| class="wikitable"
! style="width: 200px" | Color-coding (mock-up)
|-
|[[File:New_rev.png|After (mock-up)]]
|}

===Meta-review Relations===
A summary of the review's information can be displayed below the review. The image below shows some information that may be useful including the source of the meta-review.

{| class="wikitable"
! style="width: 200px" | Color-coding (mock-up)
|-
|[[File:rev_info.png|After (mock-up)]]
|}

== Design Goals ==
Most of the design patterns are difficult to apply since we will be focusing on the views only and not gathering and structuring the data. From what we can tell the data is already there and sent to the view. We should not need to edit the models or controllers much, except for goal 6 (Restructure HTML Generation). In any case we expect to stay DRY, and comment our code for easy understanding and future integration. We will adhear to the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] architecture and as such will add the necessary code to its correct position.

== References ==
<references/>

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T01:43:03Z

Dshuffma: /* Submission Indicator */

== Final Project E728 ==

'''Design Document'''
__TOC__

== Introduction ==
The E728 project focuses on improving the review section's layout and usefulness. <ref name='assignment'> https://docs.google.com/document/d/11YTjxFXFR13vJ769yFBbqn9qOueK2Ktz0Pd-gyS2W5U/edit</ref> Our plan is to breakdown the [http://www.reddit.com/r/FieldOfKarmicGlory/comments/1beq5p/the_rules_of_battle/ assignment] and address each goal.
#Tabular Reviews - Use a table with tabs to view the reviews. The tabs will select which review is active. The table will hold the questions on the left, and corresponding reviewer score and comment on the right.
#Submission Type Indicator - A visual clue (can be either text message, color coded, or image icon) will be added to distinguish if a review is an original or updated review.
#Bug Fix - Figure out if a particular bug still exists, if so fix it. The bug happens when a one clicks on a particular review and it does not display the feedback form the review.
#Meta-review Relations - Create a link or add text to indicate which review the meta-review was written about.
#Update View Scores - Improve the view scores page by adding filters.
#Restructure HTML Generation - Move as much code that generates HTML from the models to the views.

== Goal Mock-Ups==

===Tabular Reviews===
The current review page is shown below. A [http://en.wikipedia.org/wiki/Mockup mock-up] of the planned changes is also shown below.
{| class="wikitable"
! style="width: 600px" | Before
|-
|[[File:orig.PNG|Before]]
|}

{| class="wikitable"
! style="width: 600px" | After (mock-up)
|-
|[[File:Planned.PNG|After (mock-up)]]
|}

Notice that the reviews have moved from sequential listing to displaying one at a time in a table. The other views can be seen by clicking their respective link which might be styled as a 'tab'.

===Submission Indicator===

One option is to color code the review links to indicate an updated review. In the mock-up below the updated review link is green. A key will be needed to inform users of the distinction.

{| class="wikitable"
! style="width: 200px" | Color-coding (mock-up)
|-
|[[File:New_rev.png|After (mock-up)]]
|}

===Meta-review Relations===
A summary of the review's information can be displayed below the review. The image below shows some information that may be useful including the source of the meta-review.

{| class="wikitable"
! style="width: 200px" | Color-coding (mock-up)
|-
|[[File:rev_info.png|After (mock-up)]]
|}

== Design Goals ==
Most of the design patterns are difficult to apply since we will be focusing on the views only and not gathering and structuring the data. From what we can tell the data is already there and sent to the view. We should not need to edit the models or controllers much, except for goal 6 (Restructure HTML Generation). In any case we expect to stay DRY, and comment our code for easy understanding and future integration. We will adhear to the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] architecture and as such will add the necessary code to its correct position.

== References ==
<references/>

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T01:41:36Z

Dshuffma: /* Submission Indicator */

== Final Project E728 ==

'''Design Document'''
__TOC__

== Introduction ==
The E728 project focuses on improving the review section's layout and usefulness. <ref name='assignment'> https://docs.google.com/document/d/11YTjxFXFR13vJ769yFBbqn9qOueK2Ktz0Pd-gyS2W5U/edit</ref> Our plan is to breakdown the [http://www.reddit.com/r/FieldOfKarmicGlory/comments/1beq5p/the_rules_of_battle/ assignment] and address each goal.
#Tabular Reviews - Use a table with tabs to view the reviews. The tabs will select which review is active. The table will hold the questions on the left, and corresponding reviewer score and comment on the right.
#Submission Type Indicator - A visual clue (can be either text message, color coded, or image icon) will be added to distinguish if a review is an original or updated review.
#Bug Fix - Figure out if a particular bug still exists, if so fix it. The bug happens when a one clicks on a particular review and it does not display the feedback form the review.
#Meta-review Relations - Create a link or add text to indicate which review the meta-review was written about.
#Update View Scores - Improve the view scores page by adding filters.
#Restructure HTML Generation - Move as much code that generates HTML from the models to the views.

== Goal Mock-Ups==

===Tabular Reviews===
The current review page is shown below. A [http://en.wikipedia.org/wiki/Mockup mock-up] of the planned changes is also shown below.
{| class="wikitable"
! style="width: 600px" | Before
|-
|[[File:orig.PNG|Before]]
|}

{| class="wikitable"
! style="width: 600px" | After (mock-up)
|-
|[[File:Planned.PNG|After (mock-up)]]
|}

Notice that the reviews have moved from sequential listing to displaying one at a time in a table. The other views can be seen by clicking their respective link which might be styled as a 'tab'.

===Submission Indicator===

One option is to color code the review links to indicate an updated review. In the mock-up below the updated link is green. A key will be needed to inform users of the distinction.

{| class="wikitable"
! style="width: 200px" | Color-coding (mock-up)
|-
|[[File:New_rev.png|After (mock-up)]]
|}

===Meta-review Relations===
A summary of the review's information can be displayed below the review. The image below shows some information that may be useful including the source of the meta-review.

{| class="wikitable"
! style="width: 200px" | Color-coding (mock-up)
|-
|[[File:rev_info.png|After (mock-up)]]
|}

== Design Goals ==
Most of the design patterns are difficult to apply since we will be focusing on the views only and not gathering and structuring the data. From what we can tell the data is already there and sent to the view. We should not need to edit the models or controllers much, except for goal 6 (Restructure HTML Generation). In any case we expect to stay DRY, and comment our code for easy understanding and future integration. We will adhear to the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] architecture and as such will add the necessary code to its correct position.

== References ==
<references/>

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T01:38:06Z

Dshuffma: /* Design Goals */

== Final Project E728 ==

'''Design Document'''
__TOC__

== Introduction ==
The E728 project focuses on improving the review section's layout and usefulness. <ref name='assignment'> https://docs.google.com/document/d/11YTjxFXFR13vJ769yFBbqn9qOueK2Ktz0Pd-gyS2W5U/edit</ref> Our plan is to breakdown the [http://www.reddit.com/r/FieldOfKarmicGlory/comments/1beq5p/the_rules_of_battle/ assignment] and address each goal.
#Tabular Reviews - Use a table with tabs to view the reviews. The tabs will select which review is active. The table will hold the questions on the left, and corresponding reviewer score and comment on the right.
#Submission Type Indicator - A visual clue (can be either text message, color coded, or image icon) will be added to distinguish if a review is an original or updated review.
#Bug Fix - Figure out if a particular bug still exists, if so fix it. The bug happens when a one clicks on a particular review and it does not display the feedback form the review.
#Meta-review Relations - Create a link or add text to indicate which review the meta-review was written about.
#Update View Scores - Improve the view scores page by adding filters.
#Restructure HTML Generation - Move as much code that generates HTML from the models to the views.

== Goal Mock-Ups==

===Tabular Reviews===
The current review page is shown below. A [http://en.wikipedia.org/wiki/Mockup mock-up] of the planned changes is also shown below.
{| class="wikitable"
! style="width: 600px" | Before
|-
|[[File:orig.PNG|Before]]
|}

{| class="wikitable"
! style="width: 600px" | After (mock-up)
|-
|[[File:Planned.PNG|After (mock-up)]]
|}

Notice that the reviews have moved from sequential listing to displaying one at a time in a table. The other views can be seen by clicking their respective link which might be styled as a 'tab'.

===Submission Indicator===

One option is to color code the review links to indicate a updated review. In the mock-up below the updated link is green. A key will be needed to inform users of the distinction.

{| class="wikitable"
! style="width: 200px" | Color-coding (mock-up)
|-
|[[File:New_rev.png|After (mock-up)]]
|}

===Meta-review Relations===
A summary of the review's information can be displayed below the review. The image below shows some information that may be useful including the source of the meta-review.

{| class="wikitable"
! style="width: 200px" | Color-coding (mock-up)
|-
|[[File:rev_info.png|After (mock-up)]]
|}

== Design Goals ==
Most of the design patterns are difficult to apply since we will be focusing on the views only and not gathering and structuring the data. From what we can tell the data is already there and sent to the view. We should not need to edit the models or controllers much, except for goal 6 (Restructure HTML Generation). In any case we expect to stay DRY, and comment our code for easy understanding and future integration. We will adhear to the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] architecture and as such will add the necessary code to its correct position.

== References ==
<references/>

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T01:35:16Z

Dshuffma: /* Design Goals */

== Final Project E728 ==

'''Design Document'''
__TOC__

== Introduction ==
The E728 project focuses on improving the review section's layout and usefulness. <ref name='assignment'> https://docs.google.com/document/d/11YTjxFXFR13vJ769yFBbqn9qOueK2Ktz0Pd-gyS2W5U/edit</ref> Our plan is to breakdown the [http://www.reddit.com/r/FieldOfKarmicGlory/comments/1beq5p/the_rules_of_battle/ assignment] and address each goal.
#Tabular Reviews - Use a table with tabs to view the reviews. The tabs will select which review is active. The table will hold the questions on the left, and corresponding reviewer score and comment on the right.
#Submission Type Indicator - A visual clue (can be either text message, color coded, or image icon) will be added to distinguish if a review is an original or updated review.
#Bug Fix - Figure out if a particular bug still exists, if so fix it. The bug happens when a one clicks on a particular review and it does not display the feedback form the review.
#Meta-review Relations - Create a link or add text to indicate which review the meta-review was written about.
#Update View Scores - Improve the view scores page by adding filters.
#Restructure HTML Generation - Move as much code that generates HTML from the models to the views.

== Goal Mock-Ups==

===Tabular Reviews===
The current review page is shown below. A [http://en.wikipedia.org/wiki/Mockup mock-up] of the planned changes is also shown below.
{| class="wikitable"
! style="width: 600px" | Before
|-
|[[File:orig.PNG|Before]]
|}

{| class="wikitable"
! style="width: 600px" | After (mock-up)
|-
|[[File:Planned.PNG|After (mock-up)]]
|}

Notice that the reviews have moved from sequential listing to displaying one at a time in a table. The other views can be seen by clicking their respective link which might be styled as a 'tab'.

===Submission Indicator===

One option is to color code the review links to indicate a updated review. In the mock-up below the updated link is green. A key will be needed to inform users of the distinction.

{| class="wikitable"
! style="width: 200px" | Color-coding (mock-up)
|-
|[[File:New_rev.png|After (mock-up)]]
|}

===Meta-review Relations===
A summary of the review's information can be displayed below the review. The image below shows some information that may be useful including the source of the meta-review.

{| class="wikitable"
! style="width: 200px" | Color-coding (mock-up)
|-
|[[File:rev_info.png|After (mock-up)]]
|}

== Design Goals ==
Most of the design patterns are difficult to apply since we will be focusing on the views only and not gathering and structuring the data. From what we can tell the data is already there and sent to the view. We should not need to edit the models or controllers much, except for goal 6 (Restructure HTML Generation). In any case we expect to stay DRY, and comment our code for easy understanding and future integration.

== References ==
<references/>

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T01:34:00Z

Dshuffma: /* Tabular Reviews */

== Final Project E728 ==

'''Design Document'''
__TOC__

== Introduction ==
The E728 project focuses on improving the review section's layout and usefulness. <ref name='assignment'> https://docs.google.com/document/d/11YTjxFXFR13vJ769yFBbqn9qOueK2Ktz0Pd-gyS2W5U/edit</ref> Our plan is to breakdown the [http://www.reddit.com/r/FieldOfKarmicGlory/comments/1beq5p/the_rules_of_battle/ assignment] and address each goal.
#Tabular Reviews - Use a table with tabs to view the reviews. The tabs will select which review is active. The table will hold the questions on the left, and corresponding reviewer score and comment on the right.
#Submission Type Indicator - A visual clue (can be either text message, color coded, or image icon) will be added to distinguish if a review is an original or updated review.
#Bug Fix - Figure out if a particular bug still exists, if so fix it. The bug happens when a one clicks on a particular review and it does not display the feedback form the review.
#Meta-review Relations - Create a link or add text to indicate which review the meta-review was written about.
#Update View Scores - Improve the view scores page by adding filters.
#Restructure HTML Generation - Move as much code that generates HTML from the models to the views.

== Goal Mock-Ups==

===Tabular Reviews===
The current review page is shown below. A [http://en.wikipedia.org/wiki/Mockup mock-up] of the planned changes is also shown below.
{| class="wikitable"
! style="width: 600px" | Before
|-
|[[File:orig.PNG|Before]]
|}

{| class="wikitable"
! style="width: 600px" | After (mock-up)
|-
|[[File:Planned.PNG|After (mock-up)]]
|}

Notice that the reviews have moved from sequential listing to displaying one at a time in a table. The other views can be seen by clicking their respective link which might be styled as a 'tab'.

===Submission Indicator===

One option is to color code the review links to indicate a updated review. In the mock-up below the updated link is green. A key will be needed to inform users of the distinction.

{| class="wikitable"
! style="width: 200px" | Color-coding (mock-up)
|-
|[[File:New_rev.png|After (mock-up)]]
|}

===Meta-review Relations===
A summary of the review's information can be displayed below the review. The image below shows some information that may be useful including the source of the meta-review.

{| class="wikitable"
! style="width: 200px" | Color-coding (mock-up)
|-
|[[File:rev_info.png|After (mock-up)]]
|}

== Design Goals ==
Most of the design patterns do not apply since we will be focusing on the views only. From what we can tell the data is already there and sent to the view. We should not need to edit the models or controllers much, except for goal 6 (Restructure HTML Generation). In any case we expect to stay DRY, and comment our code for easy understanding and future integration.

== References ==
<references/>

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T01:31:55Z

Dshuffma: /* Design Goals */

== Final Project E728 ==

'''Design Document'''
__TOC__

== Introduction ==
The E728 project focuses on improving the review section's layout and usefulness. <ref name='assignment'> https://docs.google.com/document/d/11YTjxFXFR13vJ769yFBbqn9qOueK2Ktz0Pd-gyS2W5U/edit</ref> Our plan is to breakdown the [http://www.reddit.com/r/FieldOfKarmicGlory/comments/1beq5p/the_rules_of_battle/ assignment] and address each goal.
#Tabular Reviews - Use a table with tabs to view the reviews. The tabs will select which review is active. The table will hold the questions on the left, and corresponding reviewer score and comment on the right.
#Submission Type Indicator - A visual clue (can be either text message, color coded, or image icon) will be added to distinguish if a review is an original or updated review.
#Bug Fix - Figure out if a particular bug still exists, if so fix it. The bug happens when a one clicks on a particular review and it does not display the feedback form the review.
#Meta-review Relations - Create a link or add text to indicate which review the meta-review was written about.
#Update View Scores - Improve the view scores page by adding filters.
#Restructure HTML Generation - Move as much code that generates HTML from the models to the views.

== Goal Mock-Ups==

===Tabular Reviews===
The current review page is shown below. A [http://en.wikipedia.org/wiki/Mockup mock-up] of the planned changes is also shown below.
{| class="wikitable"
! style="width: 600px" | Before
|-
|[[File:orig.PNG|Before]]
|}

{| class="wikitable"
! style="width: 600px" | After
|-
|[[File:Planned.PNG|After (mock-up)]]
|}

Notice that the reviews have moved from sequential listing to displaying one at a time in a table. The other views can be seen by clicking their respective link which might be styled as a 'tab'.

===Submission Indicator===

One option is to color code the review links to indicate a updated review. In the mock-up below the updated link is green. A key will be needed to inform users of the distinction.

{| class="wikitable"
! style="width: 200px" | Color-coding (mock-up)
|-
|[[File:New_rev.png|After (mock-up)]]
|}

===Meta-review Relations===
A summary of the review's information can be displayed below the review. The image below shows some information that may be useful including the source of the meta-review.

{| class="wikitable"
! style="width: 200px" | Color-coding (mock-up)
|-
|[[File:rev_info.png|After (mock-up)]]
|}

== Design Goals ==
Most of the design patterns do not apply since we will be focusing on the views only. From what we can tell the data is already there and sent to the view. We should not need to edit the models or controllers much, except for goal 6 (Restructure HTML Generation). In any case we expect to stay DRY, and comment our code for easy understanding and future integration.

== References ==
<references/>

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T01:30:40Z

Dshuffma: /* Introduction */

== Final Project E728 ==

'''Design Document'''
__TOC__

== Introduction ==
The E728 project focuses on improving the review section's layout and usefulness. <ref name='assignment'> https://docs.google.com/document/d/11YTjxFXFR13vJ769yFBbqn9qOueK2Ktz0Pd-gyS2W5U/edit</ref> Our plan is to breakdown the [http://www.reddit.com/r/FieldOfKarmicGlory/comments/1beq5p/the_rules_of_battle/ assignment] and address each goal.
#Tabular Reviews - Use a table with tabs to view the reviews. The tabs will select which review is active. The table will hold the questions on the left, and corresponding reviewer score and comment on the right.
#Submission Type Indicator - A visual clue (can be either text message, color coded, or image icon) will be added to distinguish if a review is an original or updated review.
#Bug Fix - Figure out if a particular bug still exists, if so fix it. The bug happens when a one clicks on a particular review and it does not display the feedback form the review.
#Meta-review Relations - Create a link or add text to indicate which review the meta-review was written about.
#Update View Scores - Improve the view scores page by adding filters.
#Restructure HTML Generation - Move as much code that generates HTML from the models to the views.

== Goal Mock-Ups==

===Tabular Reviews===
The current review page is shown below. A [http://en.wikipedia.org/wiki/Mockup mock-up] of the planned changes is also shown below.
{| class="wikitable"
! style="width: 600px" | Before
|-
|[[File:orig.PNG|Before]]
|}

{| class="wikitable"
! style="width: 600px" | After
|-
|[[File:Planned.PNG|After (mock-up)]]
|}

Notice that the reviews have moved from sequential listing to displaying one at a time in a table. The other views can be seen by clicking their respective link which might be styled as a 'tab'.

===Submission Indicator===

One option is to color code the review links to indicate a updated review. In the mock-up below the updated link is green. A key will be needed to inform users of the distinction.

{| class="wikitable"
! style="width: 200px" | Color-coding (mock-up)
|-
|[[File:New_rev.png|After (mock-up)]]
|}

===Meta-review Relations===
A summary of the review's information can be displayed below the review. The image below shows some information that may be useful including the source of the meta-review.

{| class="wikitable"
! style="width: 200px" | Color-coding (mock-up)
|-
|[[File:rev_info.png|After (mock-up)]]
|}

== Design Goals ==
Most of the design patterns do not apply since we will be focusing on the views only. From what we can tell the data is already there and sent to the view. We shouldn't need to edit the models or controllers unless except for goal 6 (Restructure HTML Generation). In any case we expect to stay DRY, and comment our code for easy understanding and future integration.

== References ==
<references/>

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T01:30:28Z

Dshuffma: /* Design Goals */

== Final Project E728 ==

'''Design Document'''
__TOC__

== Introduction ==
The E728 project focuses on improving the review section's layout and usefulness. <ref name='assignment'> https://docs.google.com/document/d/11YTjxFXFR13vJ769yFBbqn9qOueK2Ktz0Pd-gyS2W5U/edit</ref> Our plan is to breakdown the [http://www.reddit.com/r/FieldOfKarmicGlory/comments/1beq5p/the_rules_of_battle/ assignment] and address each goal.
#Tabular Reviews - Use a table with tabs to view the reviews. The tabs will select which review is active. The table will hold the questions on the left, and corresponding reviewer score and comment on the right.
#Submission Type Indicator - A visual clue (can be either text message, color coded, or image icon) will be added to distinguish if a review is an original or updated review.
#Bug Fix - Figure out if a particular bug still exists, if so fix it. The bug happens when a one clicks on a particular review and it does not display the feedback form the review.
#Meta-review Relations - Create a link or add text to indicate which review the meta-review was written about.
#Update View Scores - Improve the view scores page by adding filters.
#Restructure HTML - Move as much code that generates HTML from the models to the views.

== Goal Mock-Ups==

===Tabular Reviews===
The current review page is shown below. A [http://en.wikipedia.org/wiki/Mockup mock-up] of the planned changes is also shown below.
{| class="wikitable"
! style="width: 600px" | Before
|-
|[[File:orig.PNG|Before]]
|}

{| class="wikitable"
! style="width: 600px" | After
|-
|[[File:Planned.PNG|After (mock-up)]]
|}

Notice that the reviews have moved from sequential listing to displaying one at a time in a table. The other views can be seen by clicking their respective link which might be styled as a 'tab'.

===Submission Indicator===

One option is to color code the review links to indicate a updated review. In the mock-up below the updated link is green. A key will be needed to inform users of the distinction.

{| class="wikitable"
! style="width: 200px" | Color-coding (mock-up)
|-
|[[File:New_rev.png|After (mock-up)]]
|}

===Meta-review Relations===
A summary of the review's information can be displayed below the review. The image below shows some information that may be useful including the source of the meta-review.

{| class="wikitable"
! style="width: 200px" | Color-coding (mock-up)
|-
|[[File:rev_info.png|After (mock-up)]]
|}

== Design Goals ==
Most of the design patterns do not apply since we will be focusing on the views only. From what we can tell the data is already there and sent to the view. We shouldn't need to edit the models or controllers unless except for goal 6 (Restructure HTML Generation). In any case we expect to stay DRY, and comment our code for easy understanding and future integration.

== References ==
<references/>

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T01:29:52Z

Dshuffma: /* Design Goals */

== Final Project E728 ==

'''Design Document'''
__TOC__

== Introduction ==
The E728 project focuses on improving the review section's layout and usefulness. <ref name='assignment'> https://docs.google.com/document/d/11YTjxFXFR13vJ769yFBbqn9qOueK2Ktz0Pd-gyS2W5U/edit</ref> Our plan is to breakdown the [http://www.reddit.com/r/FieldOfKarmicGlory/comments/1beq5p/the_rules_of_battle/ assignment] and address each goal.
#Tabular Reviews - Use a table with tabs to view the reviews. The tabs will select which review is active. The table will hold the questions on the left, and corresponding reviewer score and comment on the right.
#Submission Type Indicator - A visual clue (can be either text message, color coded, or image icon) will be added to distinguish if a review is an original or updated review.
#Bug Fix - Figure out if a particular bug still exists, if so fix it. The bug happens when a one clicks on a particular review and it does not display the feedback form the review.
#Meta-review Relations - Create a link or add text to indicate which review the meta-review was written about.
#Update View Scores - Improve the view scores page by adding filters.
#Restructure HTML - Move as much code that generates HTML from the models to the views.

== Goal Mock-Ups==

===Tabular Reviews===
The current review page is shown below. A [http://en.wikipedia.org/wiki/Mockup mock-up] of the planned changes is also shown below.
{| class="wikitable"
! style="width: 600px" | Before
|-
|[[File:orig.PNG|Before]]
|}

{| class="wikitable"
! style="width: 600px" | After
|-
|[[File:Planned.PNG|After (mock-up)]]
|}

Notice that the reviews have moved from sequential listing to displaying one at a time in a table. The other views can be seen by clicking their respective link which might be styled as a 'tab'.

===Submission Indicator===

One option is to color code the review links to indicate a updated review. In the mock-up below the updated link is green. A key will be needed to inform users of the distinction.

{| class="wikitable"
! style="width: 200px" | Color-coding (mock-up)
|-
|[[File:New_rev.png|After (mock-up)]]
|}

===Meta-review Relations===
A summary of the review's information can be displayed below the review. The image below shows some information that may be useful including the source of the meta-review.

{| class="wikitable"
! style="width: 200px" | Color-coding (mock-up)
|-
|[[File:rev_info.png|After (mock-up)]]
|}

== Design Goals ==
Most of the design patterns do not apply since we will be focusing on the views only. From what we can tell the data is already there and sent to the view. We shouldn't need to edit the models or controllers unless except for goal 5. In any case we expect to stay DRY, and comment our code for easy understanding and future integration.

== References ==
<references/>

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T01:28:50Z

Dshuffma:

== Final Project E728 ==

'''Design Document'''
__TOC__

== Introduction ==
The E728 project focuses on improving the review section's layout and usefulness. <ref name='assignment'> https://docs.google.com/document/d/11YTjxFXFR13vJ769yFBbqn9qOueK2Ktz0Pd-gyS2W5U/edit</ref> Our plan is to breakdown the [http://www.reddit.com/r/FieldOfKarmicGlory/comments/1beq5p/the_rules_of_battle/ assignment] and address each goal.
#Tabular Reviews - Use a table with tabs to view the reviews. The tabs will select which review is active. The table will hold the questions on the left, and corresponding reviewer score and comment on the right.
#Submission Type Indicator - A visual clue (can be either text message, color coded, or image icon) will be added to distinguish if a review is an original or updated review.
#Bug Fix - Figure out if a particular bug still exists, if so fix it. The bug happens when a one clicks on a particular review and it does not display the feedback form the review.
#Meta-review Relations - Create a link or add text to indicate which review the meta-review was written about.
#Update View Scores - Improve the view scores page by adding filters.
#Restructure HTML - Move as much code that generates HTML from the models to the views.

== Goal Mock-Ups==

===Tabular Reviews===
The current review page is shown below. A [http://en.wikipedia.org/wiki/Mockup mock-up] of the planned changes is also shown below.
{| class="wikitable"
! style="width: 600px" | Before
|-
|[[File:orig.PNG|Before]]
|}

{| class="wikitable"
! style="width: 600px" | After
|-
|[[File:Planned.PNG|After (mock-up)]]
|}

Notice that the reviews have moved from sequential listing to displaying one at a time in a table. The other views can be seen by clicking their respective link which might be styled as a 'tab'.

===Submission Indicator===

One option is to color code the review links to indicate a updated review. In the mock-up below the updated link is green. A key will be needed to inform users of the distinction.

{| class="wikitable"
! style="width: 200px" | Color-coding (mock-up)
|-
|[[File:New_rev.png|After (mock-up)]]
|}

===Meta-review Relations===
A summary of the review's information can be displayed below the review. The image below shows some information that may be useful including the source of the meta-review.

{| class="wikitable"
! style="width: 200px" | Color-coding (mock-up)
|-
|[[File:rev_info.png|After (mock-up)]]
|}

== Design Goals ==
Most of the design patterns do not apply since we will be focusing on the views only. Though we may need to touch controllers or models at some point if the data needs to be restructured. In any case we expect to stay DRY, and comment our code for easy understanding and future integration.

== References ==
<references/>

File:Rev info.png

2013-04-02T01:24:25Z

Dshuffma:

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T01:16:16Z

Dshuffma: /* Goal Mock-Ups */

== Final Project E728 ==

'''Design Document'''
__TOC__

== Introduction ==
The E728 project focuses on improving the review section's layout and usefulness. <ref name='assignment'> https://docs.google.com/document/d/11YTjxFXFR13vJ769yFBbqn9qOueK2Ktz0Pd-gyS2W5U/edit</ref> Our plan is to breakdown the [http://www.reddit.com/r/FieldOfKarmicGlory/comments/1beq5p/the_rules_of_battle/ assignment] and address each goal.
#Tabular Reviews - Use a table with tabs to view the reviews. The tabs will select which review is active. The table will hold the questions on the left, and corresponding reviewer score and comment on the right.
#Submission Type Indicator - A visual clue (can be either text message, color coded, or image icon) will be added to distinguish if a review is an original or updated review.
#Bug Fix - Figure out if a particular bug still exists, if so fix it. The bug happens when a one clicks on a particular review and it does not display the feedback form the review.
#Meta-review Relations - Create a link or add text to indicate which review the meta-review was written about.
#Update View Scores - Improve the view scores page by adding filters.
#Restructure HTML - Move as much code that generates HTML from the models to the views.

== Goal Mock-Ups==

===Tabular Reviews===
The current review page is shown below. A [http://en.wikipedia.org/wiki/Mockup mock-up] of the planned changes is also shown below.
{| class="wikitable"
! style="width: 600px" | Before
|-
|[[File:orig.PNG|Before]]
|}

{| class="wikitable"
! style="width: 600px" | After
|-
|[[File:Planned.PNG|After (mock-up)]]
|}

Notice that the reviews have moved from sequential listing to displaying one at a time in a table. The other views can be seen by clicking their respective link which might be styled as a 'tab'.

===Submission Indicator===

One option is to color code the review links to indicate a updated review. In the mock-up below the updated link is green. A key will be needed to inform users of the distinction.

{| class="wikitable"
! style="width: 200px" | Color-coding (mock-up)
|-
|[[File:New_rev.png|After (mock-up)]]
|}

===Meta-review Relations===
A summary of the review's information can be displayed below the review. The image below shows some information that may be useful including the source of the meta-review.

{| class="wikitable"
! style="width: 200px" | Color-coding (mock-up)
|-
|[[File:rev_info.png|After (mock-up)]]
|}

== References ==
<references/>

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T01:13:33Z

Dshuffma: /* Goal Details */

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T01:13:10Z

Dshuffma: /* Tabular Reviews */

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T01:12:24Z

Dshuffma: /* Submission Indicator */

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T01:11:55Z

Dshuffma: /* Submission Indicator */

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T01:11:20Z

Dshuffma: /* Submission Indicator */

File:New rev.png

2013-04-02T01:11:07Z

Dshuffma:

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T01:10:36Z

Dshuffma: /* Thing 2 */

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T01:05:58Z

Dshuffma: /* Tabular Reviews */

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T01:05:06Z

Dshuffma: /* Tabular Reviews */

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T01:03:36Z

Dshuffma: /* Tabular Reviews */

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T01:02:44Z

Dshuffma: /* Tabular Reviews */

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T01:01:05Z

Dshuffma: /* Tabular Reviews */

File:Planned.PNG

2013-04-02T01:00:34Z

Dshuffma:

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T01:00:23Z

Dshuffma: /* Tabular Reviews */

File:Orig.PNG

2013-04-02T00:59:15Z

Dshuffma:

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T00:58:31Z

Dshuffma: /* Tabular Reviews */

File:Before E728.PNG

2013-04-02T00:58:14Z

Dshuffma:

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T00:57:32Z

Dshuffma: /* Tabular Reviews */

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T00:56:13Z

Dshuffma: /* Tabular Reviews */

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T00:34:29Z

Dshuffma: /* Thing 1 */

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T00:33:49Z

Dshuffma: /* Overview */

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T00:33:11Z

Dshuffma: /* Introduction */

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T00:12:33Z

Dshuffma: /* Introduction */

CSC/ECE 517 Spring 2013/Final E728

2013-04-02T00:11:23Z

Dshuffma: Created page with "== Final Project E728 == '''Design Document''' __TOC__ == Introduction == There were three goals in the OSS E600 project <ref name='assignment'> http://courses.ncsu.edu/csc517/..."

== Final Project E728 ==

'''Design Document'''
__TOC__

== Introduction ==
There were three goals in the OSS E600 project <ref name='assignment'> http://courses.ncsu.edu/csc517/common/homework/OSS/expertiza.html</ref>
#Restructure the feature files for better organization. Feature folders like 'student' had few scenarios strung out between many files. Consolidate the files to make them more useful.
#Determine a gem that will generate code coverage reports. It needs to work with Ruby 1.8.7 and Rails 2.
#Use the coverage tool to find areas that need the most improvement. Then create new tests targeting those areas to increase coverage.

== Overview ==

===Thing 1===

===Thing 2===

== References ==
<references/>

CSC/ECE 517 Spring 2013/OSS E600

2013-03-21T03:26:52Z

Dshuffma: /* Coverage Increase */

== OSS E600 ==

'''Writing Assignment 2'''
__TOC__

== Introduction ==
There were three goals in the OSS E600 project <ref name='assignment'> http://courses.ncsu.edu/csc517/common/homework/OSS/expertiza.html</ref>
#Restructure the feature files for better organization. Feature folders like 'student' had few scenarios strung out between many files. Consolidate the files to make them more useful.
#Determine a gem that will generate code coverage reports. It needs to work with Ruby 1.8.7 and Rails 2.
#Use the coverage tool to find areas that need the most improvement. Then create new tests targeting those areas to increase coverage.

== Setup ==
Setting up the coverage + [http://en.wikipedia.org/wiki/Cucumber_(software) cucumber] environment is very similar to setting up for only cucumber. The majority of the instructions in the old cucumber [http://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza wiki] still apply.<ref name='old_wiki'>http://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza</ref>

The gem we choose is called [https://github.com/relevance/rcov rcov], and we have the one by [https://github.com/relevance/rcov relevance]. <ref name='rcov_gem'>http://rubygems.org/gems/rcov</ref>

Follow the [http://wikis.lib.ncsu.edu/index.php/Creating_a_Linux_Development_Environment_for_the_Expertiza_Application linux wiki] to setup Expertiza. Assuming that [https://github.com/expertiza/expertiza Expertiza] is already running, enter these commands:
<pre>
gem install relevance-rcov
bundle install
rake db:create
rake db:test:prepare
</pre>
Modify the file ./lib/task/cucumber.rake. Add the line "t.rcov=true" below each of the three t.profile lines.
<pre>
Cucumber::Rake::Task.new({:ok => 'db:test:prepare'}, 'Run features that should pass') do |t|
t.binary = vendored_cucumber_bin # If nil, the gem's binary is used.
t.fork = true # You may get faster startup if you set this to false
t.profile = 'default'
t.rcov = true #add this line for coverage report
end

Cucumber::Rake::Task.new({:wip => 'db:test:prepare'}, 'Run features that are being worked on') do |t|
t.binary = vendored_cucumber_bin
t.fork = true # You may get faster startup if you set this to false
t.profile = 'wip'
t.rcov = true #add this line for coverage report
end

Cucumber::Rake::Task.new({:rerun => 'db:test:prepare'}, 'Record failing features and run only them if any exist') do |t|
t.binary = vendored_cucumber_bin
t.fork = true # You may get faster startup if you set this to false
t.profile = 'rerun'
t.rcov = true #add this line for coverage report
end
</pre>

== Running ==
===Run Coverage and All Features===
Enter the command below to run the entire cucumber feature suite '''and''' get code coverage reports.
<pre>
rake features
</pre>
When cucumber runs you should see green/yellow/red text as each scenario runs and either passes, skips or fails.
 
'''Cucumber Example'''
 
[[File:Cucumber_ex.png]]

===Run All Features <ref name='old_wiki'/>===
To run all cucumber features found within the ./features directory:
<pre>bundle exec cucumber</pre>

=== Run a Single Feature <ref name='old_wiki'/> ===
To run all scenarios for a single cucumber feature:
<pre>bundle exec cucumber features/admin/impersonate_user.feature</pre>

=== Run a Single Scenario <ref name='old_wiki'/>===
To run specific scenario within a feature, specify the line number:
<pre>bundle exec cucumber features/admin/impersonate_user.feature:5</pre>

== Coverage Reports ==
The coverage reports will be generated in the folder ./coverage. <ref name='rcov'> https://github.com/cucumber/cucumber/wiki/Using-RCov-with-Cucumber-and-Rails </ref>
The reports will be in an HTML format. View the report by opening ./coverage/index.html in a [http://en.wikipedia.org/wiki/Web_browser browser].

The main output of [https://github.com/relevance/rcov rcov]is a web page shown below which lists each source file on the left followed by the coverage percentage of that source file. Clicking on the source file link will show the line by line coverage of that source file.

[[File:coverage_screen.jpg]]

== Design Patterns ==
The work that we did in implementing this project did not introduce any new design patterns to the Expertiza system that were of our own creation.

The Cucumber system, however, does exhibit the [http://en.wikipedia.org/wiki/Facade_pattern? Facade Pattern]. The Facade Pattern provides a simplified interface to a software system. The Cucumber package provides this facade through the steps in Capybara. The simplified interface allows the software developer to write tests in something close to a natural language.

== Outcome ==

=== File Organization ===
Before there were 35 feature files. They have been consolidated to 20 files. The largest improvement is the feature folder 'student' as shown below:

{| class="wikitable"
! style="width: 50%" | Before
! style="width: 50%" | After
|-
|[[File:Before.PNG|left|Before]]
|[[File:After.PNG|227px|After]]
|}

=== Coverage Increase ===
The overall coverage increase was small, but measurable. 12 new scenarios were created to achieve the increase.
 
Before
*Total Coverage: 33.29%
*Code coverage: 26.70%
 
After
*Total Coverage: 34.17%
*Code coverage: 27.45%

== Demonstration Video ==
A demonstration video walks through the project. Click [https://www.youtube.com/watch?v=r29BdG-EV4A Here] to view.

== References ==
<references/>

CSC/ECE 517 Spring 2013/OSS E600

2013-03-21T03:25:44Z

Dshuffma: /* Demonstration Video */

== OSS E600 ==

'''Writing Assignment 2'''
__TOC__

== Introduction ==
There were three goals in the OSS E600 project <ref name='assignment'> http://courses.ncsu.edu/csc517/common/homework/OSS/expertiza.html</ref>
#Restructure the feature files for better organization. Feature folders like 'student' had few scenarios strung out between many files. Consolidate the files to make them more useful.
#Determine a gem that will generate code coverage reports. It needs to work with Ruby 1.8.7 and Rails 2.
#Use the coverage tool to find areas that need the most improvement. Then create new tests targeting those areas to increase coverage.

== Setup ==
Setting up the coverage + [http://en.wikipedia.org/wiki/Cucumber_(software) cucumber] environment is very similar to setting up for only cucumber. The majority of the instructions in the old cucumber [http://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza wiki] still apply.<ref name='old_wiki'>http://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza</ref>

The gem we choose is called [https://github.com/relevance/rcov rcov], and we have the one by [https://github.com/relevance/rcov relevance]. <ref name='rcov_gem'>http://rubygems.org/gems/rcov</ref>

Follow the [http://wikis.lib.ncsu.edu/index.php/Creating_a_Linux_Development_Environment_for_the_Expertiza_Application linux wiki] to setup Expertiza. Assuming that [https://github.com/expertiza/expertiza Expertiza] is already running, enter these commands:
<pre>
gem install relevance-rcov
bundle install
rake db:create
rake db:test:prepare
</pre>
Modify the file ./lib/task/cucumber.rake. Add the line "t.rcov=true" below each of the three t.profile lines.
<pre>
Cucumber::Rake::Task.new({:ok => 'db:test:prepare'}, 'Run features that should pass') do |t|
t.binary = vendored_cucumber_bin # If nil, the gem's binary is used.
t.fork = true # You may get faster startup if you set this to false
t.profile = 'default'
t.rcov = true #add this line for coverage report
end

Cucumber::Rake::Task.new({:wip => 'db:test:prepare'}, 'Run features that are being worked on') do |t|
t.binary = vendored_cucumber_bin
t.fork = true # You may get faster startup if you set this to false
t.profile = 'wip'
t.rcov = true #add this line for coverage report
end

Cucumber::Rake::Task.new({:rerun => 'db:test:prepare'}, 'Record failing features and run only them if any exist') do |t|
t.binary = vendored_cucumber_bin
t.fork = true # You may get faster startup if you set this to false
t.profile = 'rerun'
t.rcov = true #add this line for coverage report
end
</pre>

== Running ==
===Run Coverage and All Features===
Enter the command below to run the entire cucumber feature suite '''and''' get code coverage reports.
<pre>
rake features
</pre>
When cucumber runs you should see green/yellow/red text as each scenario runs and either passes, skips or fails.
 
'''Cucumber Example'''
 
[[File:Cucumber_ex.png]]

===Run All Features <ref name='old_wiki'/>===
To run all cucumber features found within the ./features directory:
<pre>bundle exec cucumber</pre>

=== Run a Single Feature <ref name='old_wiki'/> ===
To run all scenarios for a single cucumber feature:
<pre>bundle exec cucumber features/admin/impersonate_user.feature</pre>

=== Run a Single Scenario <ref name='old_wiki'/>===
To run specific scenario within a feature, specify the line number:
<pre>bundle exec cucumber features/admin/impersonate_user.feature:5</pre>

== Coverage Reports ==
The coverage reports will be generated in the folder ./coverage. <ref name='rcov'> https://github.com/cucumber/cucumber/wiki/Using-RCov-with-Cucumber-and-Rails </ref>
The reports will be in an HTML format. View the report by opening ./coverage/index.html in a [http://en.wikipedia.org/wiki/Web_browser browser].

The main output of [https://github.com/relevance/rcov rcov]is a web page shown below which lists each source file on the left followed by the coverage percentage of that source file. Clicking on the source file link will show the line by line coverage of that source file.

[[File:coverage_screen.jpg]]

== Design Patterns ==
The work that we did in implementing this project did not introduce any new design patterns to the Expertiza system that were of our own creation.

The Cucumber system, however, does exhibit the [http://en.wikipedia.org/wiki/Facade_pattern? Facade Pattern]. The Facade Pattern provides a simplified interface to a software system. The Cucumber package provides this facade through the steps in Capybara. The simplified interface allows the software developer to write tests in something close to a natural language.

== Outcome ==

=== File Organization ===
Before there were 35 feature files. They have been consolidated to 20 files. The largest improvement is the feature folder 'student' as shown below:

{| class="wikitable"
! style="width: 50%" | Before
! style="width: 50%" | After
|-
|[[File:Before.PNG|left|Before]]
|[[File:After.PNG|227px|After]]
|}

=== Coverage Increase ===
The overall coverage increase was small, but measurable.
 
Before
*Total Coverage: 33.29%
*Code coverage: 26.70%
 
After
*Total Coverage: 34.17%
*Code coverage: 27.45%

== Demonstration Video ==
A demonstration video walks through the project. Click [https://www.youtube.com/watch?v=r29BdG-EV4A Here] to view.

== References ==
<references/>

CSC/ECE 517 Spring 2013/OSS E600

2013-03-21T03:24:59Z

Dshuffma: /* Run Coverage and All Features */

== OSS E600 ==

'''Writing Assignment 2'''
__TOC__

== Introduction ==
There were three goals in the OSS E600 project <ref name='assignment'> http://courses.ncsu.edu/csc517/common/homework/OSS/expertiza.html</ref>
#Restructure the feature files for better organization. Feature folders like 'student' had few scenarios strung out between many files. Consolidate the files to make them more useful.
#Determine a gem that will generate code coverage reports. It needs to work with Ruby 1.8.7 and Rails 2.
#Use the coverage tool to find areas that need the most improvement. Then create new tests targeting those areas to increase coverage.

== Setup ==
Setting up the coverage + [http://en.wikipedia.org/wiki/Cucumber_(software) cucumber] environment is very similar to setting up for only cucumber. The majority of the instructions in the old cucumber [http://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza wiki] still apply.<ref name='old_wiki'>http://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza</ref>

The gem we choose is called [https://github.com/relevance/rcov rcov], and we have the one by [https://github.com/relevance/rcov relevance]. <ref name='rcov_gem'>http://rubygems.org/gems/rcov</ref>

Follow the [http://wikis.lib.ncsu.edu/index.php/Creating_a_Linux_Development_Environment_for_the_Expertiza_Application linux wiki] to setup Expertiza. Assuming that [https://github.com/expertiza/expertiza Expertiza] is already running, enter these commands:
<pre>
gem install relevance-rcov
bundle install
rake db:create
rake db:test:prepare
</pre>
Modify the file ./lib/task/cucumber.rake. Add the line "t.rcov=true" below each of the three t.profile lines.
<pre>
Cucumber::Rake::Task.new({:ok => 'db:test:prepare'}, 'Run features that should pass') do |t|
t.binary = vendored_cucumber_bin # If nil, the gem's binary is used.
t.fork = true # You may get faster startup if you set this to false
t.profile = 'default'
t.rcov = true #add this line for coverage report
end

Cucumber::Rake::Task.new({:wip => 'db:test:prepare'}, 'Run features that are being worked on') do |t|
t.binary = vendored_cucumber_bin
t.fork = true # You may get faster startup if you set this to false
t.profile = 'wip'
t.rcov = true #add this line for coverage report
end

Cucumber::Rake::Task.new({:rerun => 'db:test:prepare'}, 'Record failing features and run only them if any exist') do |t|
t.binary = vendored_cucumber_bin
t.fork = true # You may get faster startup if you set this to false
t.profile = 'rerun'
t.rcov = true #add this line for coverage report
end
</pre>

== Running ==
===Run Coverage and All Features===
Enter the command below to run the entire cucumber feature suite '''and''' get code coverage reports.
<pre>
rake features
</pre>
When cucumber runs you should see green/yellow/red text as each scenario runs and either passes, skips or fails.
 
'''Cucumber Example'''
 
[[File:Cucumber_ex.png]]

===Run All Features <ref name='old_wiki'/>===
To run all cucumber features found within the ./features directory:
<pre>bundle exec cucumber</pre>

=== Run a Single Feature <ref name='old_wiki'/> ===
To run all scenarios for a single cucumber feature:
<pre>bundle exec cucumber features/admin/impersonate_user.feature</pre>

=== Run a Single Scenario <ref name='old_wiki'/>===
To run specific scenario within a feature, specify the line number:
<pre>bundle exec cucumber features/admin/impersonate_user.feature:5</pre>

== Coverage Reports ==
The coverage reports will be generated in the folder ./coverage. <ref name='rcov'> https://github.com/cucumber/cucumber/wiki/Using-RCov-with-Cucumber-and-Rails </ref>
The reports will be in an HTML format. View the report by opening ./coverage/index.html in a [http://en.wikipedia.org/wiki/Web_browser browser].

The main output of [https://github.com/relevance/rcov rcov]is a web page shown below which lists each source file on the left followed by the coverage percentage of that source file. Clicking on the source file link will show the line by line coverage of that source file.

[[File:coverage_screen.jpg]]

== Design Patterns ==
The work that we did in implementing this project did not introduce any new design patterns to the Expertiza system that were of our own creation.

The Cucumber system, however, does exhibit the [http://en.wikipedia.org/wiki/Facade_pattern? Facade Pattern]. The Facade Pattern provides a simplified interface to a software system. The Cucumber package provides this facade through the steps in Capybara. The simplified interface allows the software developer to write tests in something close to a natural language.

== Outcome ==

=== File Organization ===
Before there were 35 feature files. They have been consolidated to 20 files. The largest improvement is the feature folder 'student' as shown below:

{| class="wikitable"
! style="width: 50%" | Before
! style="width: 50%" | After
|-
|[[File:Before.PNG|left|Before]]
|[[File:After.PNG|227px|After]]
|}

=== Coverage Increase ===
The overall coverage increase was small, but measurable.
 
Before
*Total Coverage: 33.29%
*Code coverage: 26.70%
 
After
*Total Coverage: 34.17%
*Code coverage: 27.45%

=== Demonstration Video ===
A demonstration video walks through the project. Click [https://www.youtube.com/watch?v=r29BdG-EV4A Here] to view.

== References ==
<references/>

CSC/ECE 517 Spring 2013/OSS E600

2013-03-21T03:24:42Z

Dshuffma: /* Run Coverage and All Features */

== OSS E600 ==

'''Writing Assignment 2'''
__TOC__

== Introduction ==
There were three goals in the OSS E600 project <ref name='assignment'> http://courses.ncsu.edu/csc517/common/homework/OSS/expertiza.html</ref>
#Restructure the feature files for better organization. Feature folders like 'student' had few scenarios strung out between many files. Consolidate the files to make them more useful.
#Determine a gem that will generate code coverage reports. It needs to work with Ruby 1.8.7 and Rails 2.
#Use the coverage tool to find areas that need the most improvement. Then create new tests targeting those areas to increase coverage.

== Setup ==
Setting up the coverage + [http://en.wikipedia.org/wiki/Cucumber_(software) cucumber] environment is very similar to setting up for only cucumber. The majority of the instructions in the old cucumber [http://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza wiki] still apply.<ref name='old_wiki'>http://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza</ref>

The gem we choose is called [https://github.com/relevance/rcov rcov], and we have the one by [https://github.com/relevance/rcov relevance]. <ref name='rcov_gem'>http://rubygems.org/gems/rcov</ref>

Follow the [http://wikis.lib.ncsu.edu/index.php/Creating_a_Linux_Development_Environment_for_the_Expertiza_Application linux wiki] to setup Expertiza. Assuming that [https://github.com/expertiza/expertiza Expertiza] is already running, enter these commands:
<pre>
gem install relevance-rcov
bundle install
rake db:create
rake db:test:prepare
</pre>
Modify the file ./lib/task/cucumber.rake. Add the line "t.rcov=true" below each of the three t.profile lines.
<pre>
Cucumber::Rake::Task.new({:ok => 'db:test:prepare'}, 'Run features that should pass') do |t|
t.binary = vendored_cucumber_bin # If nil, the gem's binary is used.
t.fork = true # You may get faster startup if you set this to false
t.profile = 'default'
t.rcov = true #add this line for coverage report
end

Cucumber::Rake::Task.new({:wip => 'db:test:prepare'}, 'Run features that are being worked on') do |t|
t.binary = vendored_cucumber_bin
t.fork = true # You may get faster startup if you set this to false
t.profile = 'wip'
t.rcov = true #add this line for coverage report
end

Cucumber::Rake::Task.new({:rerun => 'db:test:prepare'}, 'Record failing features and run only them if any exist') do |t|
t.binary = vendored_cucumber_bin
t.fork = true # You may get faster startup if you set this to false
t.profile = 'rerun'
t.rcov = true #add this line for coverage report
end
</pre>

== Running ==
===Run Coverage and All Features===
Enter the command below to run the entire cucumber feature suite '''and''' get code coverage reports.
<pre>
rake features
</pre>
When cucumber runs you should see green/yellow/red text as each scenario runs and either passes skips or fails.
 
'''Cucumber Example'''
 
[[File:Cucumber_ex.png]]

===Run All Features <ref name='old_wiki'/>===
To run all cucumber features found within the ./features directory:
<pre>bundle exec cucumber</pre>

=== Run a Single Feature <ref name='old_wiki'/> ===
To run all scenarios for a single cucumber feature:
<pre>bundle exec cucumber features/admin/impersonate_user.feature</pre>

=== Run a Single Scenario <ref name='old_wiki'/>===
To run specific scenario within a feature, specify the line number:
<pre>bundle exec cucumber features/admin/impersonate_user.feature:5</pre>

== Coverage Reports ==
The coverage reports will be generated in the folder ./coverage. <ref name='rcov'> https://github.com/cucumber/cucumber/wiki/Using-RCov-with-Cucumber-and-Rails </ref>
The reports will be in an HTML format. View the report by opening ./coverage/index.html in a [http://en.wikipedia.org/wiki/Web_browser browser].

The main output of [https://github.com/relevance/rcov rcov]is a web page shown below which lists each source file on the left followed by the coverage percentage of that source file. Clicking on the source file link will show the line by line coverage of that source file.

[[File:coverage_screen.jpg]]

== Design Patterns ==
The work that we did in implementing this project did not introduce any new design patterns to the Expertiza system that were of our own creation.

The Cucumber system, however, does exhibit the [http://en.wikipedia.org/wiki/Facade_pattern? Facade Pattern]. The Facade Pattern provides a simplified interface to a software system. The Cucumber package provides this facade through the steps in Capybara. The simplified interface allows the software developer to write tests in something close to a natural language.

== Outcome ==

=== File Organization ===
Before there were 35 feature files. They have been consolidated to 20 files. The largest improvement is the feature folder 'student' as shown below:

{| class="wikitable"
! style="width: 50%" | Before
! style="width: 50%" | After
|-
|[[File:Before.PNG|left|Before]]
|[[File:After.PNG|227px|After]]
|}

=== Coverage Increase ===
The overall coverage increase was small, but measurable.
 
Before
*Total Coverage: 33.29%
*Code coverage: 26.70%
 
After
*Total Coverage: 34.17%
*Code coverage: 27.45%

=== Demonstration Video ===
A demonstration video walks through the project. Click [https://www.youtube.com/watch?v=r29BdG-EV4A Here] to view.

== References ==
<references/>

CSC/ECE 517 Spring 2013/OSS E600

2013-03-21T03:24:16Z

Dshuffma: /* Run Coverage and All Features */

== OSS E600 ==

'''Writing Assignment 2'''
__TOC__

== Introduction ==
There were three goals in the OSS E600 project <ref name='assignment'> http://courses.ncsu.edu/csc517/common/homework/OSS/expertiza.html</ref>
#Restructure the feature files for better organization. Feature folders like 'student' had few scenarios strung out between many files. Consolidate the files to make them more useful.
#Determine a gem that will generate code coverage reports. It needs to work with Ruby 1.8.7 and Rails 2.
#Use the coverage tool to find areas that need the most improvement. Then create new tests targeting those areas to increase coverage.

== Setup ==
Setting up the coverage + [http://en.wikipedia.org/wiki/Cucumber_(software) cucumber] environment is very similar to setting up for only cucumber. The majority of the instructions in the old cucumber [http://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza wiki] still apply.<ref name='old_wiki'>http://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza</ref>

The gem we choose is called [https://github.com/relevance/rcov rcov], and we have the one by [https://github.com/relevance/rcov relevance]. <ref name='rcov_gem'>http://rubygems.org/gems/rcov</ref>

Follow the [http://wikis.lib.ncsu.edu/index.php/Creating_a_Linux_Development_Environment_for_the_Expertiza_Application linux wiki] to setup Expertiza. Assuming that [https://github.com/expertiza/expertiza Expertiza] is already running, enter these commands:
<pre>
gem install relevance-rcov
bundle install
rake db:create
rake db:test:prepare
</pre>
Modify the file ./lib/task/cucumber.rake. Add the line "t.rcov=true" below each of the three t.profile lines.
<pre>
Cucumber::Rake::Task.new({:ok => 'db:test:prepare'}, 'Run features that should pass') do |t|
t.binary = vendored_cucumber_bin # If nil, the gem's binary is used.
t.fork = true # You may get faster startup if you set this to false
t.profile = 'default'
t.rcov = true #add this line for coverage report
end

Cucumber::Rake::Task.new({:wip => 'db:test:prepare'}, 'Run features that are being worked on') do |t|
t.binary = vendored_cucumber_bin
t.fork = true # You may get faster startup if you set this to false
t.profile = 'wip'
t.rcov = true #add this line for coverage report
end

Cucumber::Rake::Task.new({:rerun => 'db:test:prepare'}, 'Record failing features and run only them if any exist') do |t|
t.binary = vendored_cucumber_bin
t.fork = true # You may get faster startup if you set this to false
t.profile = 'rerun'
t.rcov = true #add this line for coverage report
end
</pre>

== Running ==
===Run Coverage and All Features===
Enter the command below to run the entire cucumber feature suite '''and''' get code coverage reports.
<pre>
rake features
</pre>
When cucumber runs you should see green/yellow/red text as each scenario runs and either passes or fails.
'''Cucumber Example'''
 
[[File:Cucumber_ex.png]]

===Run All Features <ref name='old_wiki'/>===
To run all cucumber features found within the ./features directory:
<pre>bundle exec cucumber</pre>

=== Run a Single Feature <ref name='old_wiki'/> ===
To run all scenarios for a single cucumber feature:
<pre>bundle exec cucumber features/admin/impersonate_user.feature</pre>

=== Run a Single Scenario <ref name='old_wiki'/>===
To run specific scenario within a feature, specify the line number:
<pre>bundle exec cucumber features/admin/impersonate_user.feature:5</pre>

== Coverage Reports ==
The coverage reports will be generated in the folder ./coverage. <ref name='rcov'> https://github.com/cucumber/cucumber/wiki/Using-RCov-with-Cucumber-and-Rails </ref>
The reports will be in an HTML format. View the report by opening ./coverage/index.html in a [http://en.wikipedia.org/wiki/Web_browser browser].

The main output of [https://github.com/relevance/rcov rcov]is a web page shown below which lists each source file on the left followed by the coverage percentage of that source file. Clicking on the source file link will show the line by line coverage of that source file.

[[File:coverage_screen.jpg]]

== Design Patterns ==
The work that we did in implementing this project did not introduce any new design patterns to the Expertiza system that were of our own creation.

The Cucumber system, however, does exhibit the [http://en.wikipedia.org/wiki/Facade_pattern? Facade Pattern]. The Facade Pattern provides a simplified interface to a software system. The Cucumber package provides this facade through the steps in Capybara. The simplified interface allows the software developer to write tests in something close to a natural language.

== Outcome ==

=== File Organization ===
Before there were 35 feature files. They have been consolidated to 20 files. The largest improvement is the feature folder 'student' as shown below:

{| class="wikitable"
! style="width: 50%" | Before
! style="width: 50%" | After
|-
|[[File:Before.PNG|left|Before]]
|[[File:After.PNG|227px|After]]
|}

=== Coverage Increase ===
The overall coverage increase was small, but measurable.
 
Before
*Total Coverage: 33.29%
*Code coverage: 26.70%
 
After
*Total Coverage: 34.17%
*Code coverage: 27.45%

=== Demonstration Video ===
A demonstration video walks through the project. Click [https://www.youtube.com/watch?v=r29BdG-EV4A Here] to view.

== References ==
<references/>

CSC/ECE 517 Spring 2013/OSS E600

2013-03-21T03:23:20Z

Dshuffma: /* Run Coverage and All Features */

== OSS E600 ==

'''Writing Assignment 2'''
__TOC__

== Introduction ==
There were three goals in the OSS E600 project <ref name='assignment'> http://courses.ncsu.edu/csc517/common/homework/OSS/expertiza.html</ref>
#Restructure the feature files for better organization. Feature folders like 'student' had few scenarios strung out between many files. Consolidate the files to make them more useful.
#Determine a gem that will generate code coverage reports. It needs to work with Ruby 1.8.7 and Rails 2.
#Use the coverage tool to find areas that need the most improvement. Then create new tests targeting those areas to increase coverage.

== Setup ==
Setting up the coverage + [http://en.wikipedia.org/wiki/Cucumber_(software) cucumber] environment is very similar to setting up for only cucumber. The majority of the instructions in the old cucumber [http://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza wiki] still apply.<ref name='old_wiki'>http://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza</ref>

The gem we choose is called [https://github.com/relevance/rcov rcov], and we have the one by [https://github.com/relevance/rcov relevance]. <ref name='rcov_gem'>http://rubygems.org/gems/rcov</ref>

Follow the [http://wikis.lib.ncsu.edu/index.php/Creating_a_Linux_Development_Environment_for_the_Expertiza_Application linux wiki] to setup Expertiza. Assuming that [https://github.com/expertiza/expertiza Expertiza] is already running, enter these commands:
<pre>
gem install relevance-rcov
bundle install
rake db:create
rake db:test:prepare
</pre>
Modify the file ./lib/task/cucumber.rake. Add the line "t.rcov=true" below each of the three t.profile lines.
<pre>
Cucumber::Rake::Task.new({:ok => 'db:test:prepare'}, 'Run features that should pass') do |t|
t.binary = vendored_cucumber_bin # If nil, the gem's binary is used.
t.fork = true # You may get faster startup if you set this to false
t.profile = 'default'
t.rcov = true #add this line for coverage report
end

Cucumber::Rake::Task.new({:wip => 'db:test:prepare'}, 'Run features that are being worked on') do |t|
t.binary = vendored_cucumber_bin
t.fork = true # You may get faster startup if you set this to false
t.profile = 'wip'
t.rcov = true #add this line for coverage report
end

Cucumber::Rake::Task.new({:rerun => 'db:test:prepare'}, 'Record failing features and run only them if any exist') do |t|
t.binary = vendored_cucumber_bin
t.fork = true # You may get faster startup if you set this to false
t.profile = 'rerun'
t.rcov = true #add this line for coverage report
end
</pre>

== Running ==
===Run Coverage and All Features===
Enter the command below to run the entire cucumber feature suite '''and''' get code coverage reports.
<pre>
rake features
</pre>

'''Cucumber Example'''
 
[[File:Cucumber_ex.png]]

===Run All Features <ref name='old_wiki'/>===
To run all cucumber features found within the ./features directory:
<pre>bundle exec cucumber</pre>

=== Run a Single Feature <ref name='old_wiki'/> ===
To run all scenarios for a single cucumber feature:
<pre>bundle exec cucumber features/admin/impersonate_user.feature</pre>

=== Run a Single Scenario <ref name='old_wiki'/>===
To run specific scenario within a feature, specify the line number:
<pre>bundle exec cucumber features/admin/impersonate_user.feature:5</pre>

== Coverage Reports ==
The coverage reports will be generated in the folder ./coverage. <ref name='rcov'> https://github.com/cucumber/cucumber/wiki/Using-RCov-with-Cucumber-and-Rails </ref>
The reports will be in an HTML format. View the report by opening ./coverage/index.html in a [http://en.wikipedia.org/wiki/Web_browser browser].

The main output of [https://github.com/relevance/rcov rcov]is a web page shown below which lists each source file on the left followed by the coverage percentage of that source file. Clicking on the source file link will show the line by line coverage of that source file.

[[File:coverage_screen.jpg]]

== Design Patterns ==
The work that we did in implementing this project did not introduce any new design patterns to the Expertiza system that were of our own creation.

The Cucumber system, however, does exhibit the [http://en.wikipedia.org/wiki/Facade_pattern? Facade Pattern]. The Facade Pattern provides a simplified interface to a software system. The Cucumber package provides this facade through the steps in Capybara. The simplified interface allows the software developer to write tests in something close to a natural language.

== Outcome ==

=== File Organization ===
Before there were 35 feature files. They have been consolidated to 20 files. The largest improvement is the feature folder 'student' as shown below:

{| class="wikitable"
! style="width: 50%" | Before
! style="width: 50%" | After
|-
|[[File:Before.PNG|left|Before]]
|[[File:After.PNG|227px|After]]
|}

=== Coverage Increase ===
The overall coverage increase was small, but measurable.
 
Before
*Total Coverage: 33.29%
*Code coverage: 26.70%
 
After
*Total Coverage: 34.17%
*Code coverage: 27.45%

=== Demonstration Video ===
A demonstration video walks through the project. Click [https://www.youtube.com/watch?v=r29BdG-EV4A Here] to view.

== References ==
<references/>

File:Cucumber ex.png

2013-03-21T03:21:49Z

Dshuffma:

CSC/ECE 517 Spring 2013/OSS E600

2013-03-21T03:15:55Z

Dshuffma: /* Setup */

== OSS E600 ==

'''Writing Assignment 2'''
__TOC__

== Introduction ==
There were three goals in the OSS E600 project <ref name='assignment'> http://courses.ncsu.edu/csc517/common/homework/OSS/expertiza.html</ref>
#Restructure the feature files for better organization. Feature folders like 'student' had few scenarios strung out between many files. Consolidate the files to make them more useful.
#Determine a gem that will generate code coverage reports. It needs to work with Ruby 1.8.7 and Rails 2.
#Use the coverage tool to find areas that need the most improvement. Then create new tests targeting those areas to increase coverage.

== Setup ==
Setting up the coverage + [http://en.wikipedia.org/wiki/Cucumber_(software) cucumber] environment is very similar to setting up for only cucumber. The majority of the instructions in the old cucumber [http://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza wiki] still apply.<ref name='old_wiki'>http://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza</ref>

The gem we choose is called [https://github.com/relevance/rcov rcov], and we have the one by [https://github.com/relevance/rcov relevance]. <ref name='rcov_gem'>http://rubygems.org/gems/rcov</ref>

Follow the [http://wikis.lib.ncsu.edu/index.php/Creating_a_Linux_Development_Environment_for_the_Expertiza_Application linux wiki] to setup Expertiza. Assuming that [https://github.com/expertiza/expertiza Expertiza] is already running, enter these commands:
<pre>
gem install relevance-rcov
bundle install
rake db:create
rake db:test:prepare
</pre>
Modify the file ./lib/task/cucumber.rake. Add the line "t.rcov=true" below each of the three t.profile lines.
<pre>
Cucumber::Rake::Task.new({:ok => 'db:test:prepare'}, 'Run features that should pass') do |t|
t.binary = vendored_cucumber_bin # If nil, the gem's binary is used.
t.fork = true # You may get faster startup if you set this to false
t.profile = 'default'
t.rocv = true #add this line for coverage report
end

Cucumber::Rake::Task.new({:wip => 'db:test:prepare'}, 'Run features that are being worked on') do |t|
t.binary = vendored_cucumber_bin
t.fork = true # You may get faster startup if you set this to false
t.profile = 'wip'
t.rocv = true #add this line for coverage report
end

Cucumber::Rake::Task.new({:rerun => 'db:test:prepare'}, 'Record failing features and run only them if any exist') do |t|
t.binary = vendored_cucumber_bin
t.fork = true # You may get faster startup if you set this to false
t.profile = 'rerun'
t.rocv = true #add this line for coverage report
end
</pre>

== Running ==
===Run Coverage and All Features===
Enter the command below to run the entire cucumber feature suite '''and''' get code coverage reports.
<pre>
rake features
</pre>

===Run All Features <ref name='old_wiki'/>===
To run all cucumber features found within the ./features directory:
<pre>bundle exec cucumber</pre>

=== Run a Single Feature <ref name='old_wiki'/> ===
To run all scenarios for a single cucumber feature:
<pre>bundle exec cucumber features/admin/impersonate_user.feature</pre>

=== Run a Single Scenario <ref name='old_wiki'/>===
To run specific scenario within a feature, specify the line number:
<pre>bundle exec cucumber features/admin/impersonate_user.feature:5</pre>

== Coverage Reports ==
The coverage reports will be generated in the folder ./coverage. <ref name='rcov'> https://github.com/cucumber/cucumber/wiki/Using-RCov-with-Cucumber-and-Rails </ref>
The reports will be in an HTML format. View the report by opening ./coverage/index.html in a [http://en.wikipedia.org/wiki/Web_browser browser].

The main output of [https://github.com/relevance/rcov rcov]is a web page shown below which lists each source file on the left followed by the coverage percentage of that source file. Clicking on the source file link will show the line by line coverage of that source file.

[[File:coverage_screen.jpg]]

== Design Patterns ==
The work that we did in implementing this project did not introduce any new design patterns to the Expertiza system that were of our own creation.

The Cucumber system, however, does exhibit the [http://en.wikipedia.org/wiki/Facade_pattern? Facade Pattern]. The Facade Pattern provides a simplified interface to a software system. The Cucumber package provides this facade through the steps in Capybara. The simplified interface allows the software developer to write tests in something close to a natural language.

== Outcome ==

=== File Organization ===
Before there were 35 feature files. They have been consolidated to 20 files. The largest improvement is the feature folder 'student' as shown below:

{| class="wikitable"
! style="width: 50%" | Before
! style="width: 50%" | After
|-
|[[File:Before.PNG|left|Before]]
|[[File:After.PNG|227px|After]]
|}

=== Coverage Increase ===
The overall coverage increase was small, but measurable.
 
Before
*Total Coverage: 33.29%
*Code coverage: 26.70%
 
After
*Total Coverage: 34.17%
*Code coverage: 27.45%

=== Demonstration Video ===
A demonstration video walks through the project. Click [https://www.youtube.com/watch?v=r29BdG-EV4A Here] to view.

== References ==
<references/>

CSC/ECE 517 Spring 2013/OSS E600

2013-03-21T03:13:38Z

Dshuffma: /* Coverage Increase */

== OSS E600 ==

'''Writing Assignment 2'''
__TOC__

== Introduction ==
There were three goals in the OSS E600 project <ref name='assignment'> http://courses.ncsu.edu/csc517/common/homework/OSS/expertiza.html</ref>
#Restructure the feature files for better organization. Feature folders like 'student' had few scenarios strung out between many files. Consolidate the files to make them more useful.
#Determine a gem that will generate code coverage reports. It needs to work with Ruby 1.8.7 and Rails 2.
#Use the coverage tool to find areas that need the most improvement. Then create new tests targeting those areas to increase coverage.

== Setup ==
Setting up the coverage + cucumber environment is very similar to setting up for only cucumber. The majority of the instructions in the old cucumber [http://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza wiki] still apply.<ref name='old_wiki'>http://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza</ref>

The gem we choose is called [https://github.com/relevance/rcov rcov], and we have the one by [https://github.com/relevance/rcov relevance]. <ref name='rcov_gem'>http://rubygems.org/gems/rcov</ref>

Follow the [http://wikis.lib.ncsu.edu/index.php/Creating_a_Linux_Development_Environment_for_the_Expertiza_Application linux wiki] to setup Expertiza. Assuming that [https://github.com/expertiza/expertiza Expertiza] is already running, enter these commands:
<pre>
gem install relevance-rcov
bundle install
rake db:create
rake db:test:prepare
</pre>
Modify the file ./lib/task/cucumber.rake. Add the line "t.rcov=true" below each of the three t.profile lines.
<pre>
Cucumber::Rake::Task.new({:ok => 'db:test:prepare'}, 'Run features that should pass') do |t|
t.binary = vendored_cucumber_bin # If nil, the gem's binary is used.
t.fork = true # You may get faster startup if you set this to false
t.profile = 'default'
t.rocv = true #add this line for coverage report
end

Cucumber::Rake::Task.new({:wip => 'db:test:prepare'}, 'Run features that are being worked on') do |t|
t.binary = vendored_cucumber_bin
t.fork = true # You may get faster startup if you set this to false
t.profile = 'wip'
t.rocv = true #add this line for coverage report
end

Cucumber::Rake::Task.new({:rerun => 'db:test:prepare'}, 'Record failing features and run only them if any exist') do |t|
t.binary = vendored_cucumber_bin
t.fork = true # You may get faster startup if you set this to false
t.profile = 'rerun'
t.rocv = true #add this line for coverage report
end
</pre>

== Running ==
===Run Coverage and All Features===
Enter the command below to run the entire cucumber feature suite '''and''' get code coverage reports.
<pre>
rake features
</pre>

===Run All Features <ref name='old_wiki'/>===
To run all cucumber features found within the ./features directory:
<pre>bundle exec cucumber</pre>

=== Run a Single Feature <ref name='old_wiki'/> ===
To run all scenarios for a single cucumber feature:
<pre>bundle exec cucumber features/admin/impersonate_user.feature</pre>

=== Run a Single Scenario <ref name='old_wiki'/>===
To run specific scenario within a feature, specify the line number:
<pre>bundle exec cucumber features/admin/impersonate_user.feature:5</pre>

== Coverage Reports ==
The coverage reports will be generated in the folder ./coverage. <ref name='rcov'> https://github.com/cucumber/cucumber/wiki/Using-RCov-with-Cucumber-and-Rails </ref>
The reports will be in an HTML format. View the report by opening ./coverage/index.html in a [http://en.wikipedia.org/wiki/Web_browser browser].

The main output of [https://github.com/relevance/rcov rcov]is a web page shown below which lists each source file on the left followed by the coverage percentage of that source file. Clicking on the source file link will show the line by line coverage of that source file.

[[File:coverage_screen.jpg]]

== Design Patterns ==
The work that we did in implementing this project did not introduce any new design patterns to the Expertiza system that were of our own creation.

The Cucumber system, however, does exhibit the [http://en.wikipedia.org/wiki/Facade_pattern? Facade Pattern]. The Facade Pattern provides a simplified interface to a software system. The Cucumber package provides this facade through the steps in Capybara. The simplified interface allows the software developer to write tests in something close to a natural language.

== Outcome ==

=== File Organization ===
Before there were 35 feature files. They have been consolidated to 20 files. The largest improvement is the feature folder 'student' as shown below:

{| class="wikitable"
! style="width: 50%" | Before
! style="width: 50%" | After
|-
|[[File:Before.PNG|left|Before]]
|[[File:After.PNG|227px|After]]
|}

=== Coverage Increase ===
The overall coverage increase was small, but measurable.
 
Before
*Total Coverage: 33.29%
*Code coverage: 26.70%
 
After
*Total Coverage: 34.17%
*Code coverage: 27.45%

== References ==
<references/>

CSC/ECE 517 Spring 2013/OSS E600

2013-03-21T03:13:16Z

Dshuffma: /* Coverage Increase */

== OSS E600 ==

'''Writing Assignment 2'''
__TOC__

== Introduction ==
There were three goals in the OSS E600 project <ref name='assignment'> http://courses.ncsu.edu/csc517/common/homework/OSS/expertiza.html</ref>
#Restructure the feature files for better organization. Feature folders like 'student' had few scenarios strung out between many files. Consolidate the files to make them more useful.
#Determine a gem that will generate code coverage reports. It needs to work with Ruby 1.8.7 and Rails 2.
#Use the coverage tool to find areas that need the most improvement. Then create new tests targeting those areas to increase coverage.

== Setup ==
Setting up the coverage + cucumber environment is very similar to setting up for only cucumber. The majority of the instructions in the old cucumber [http://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza wiki] still apply.<ref name='old_wiki'>http://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza</ref>

The gem we choose is called [https://github.com/relevance/rcov rcov], and we have the one by [https://github.com/relevance/rcov relevance]. <ref name='rcov_gem'>http://rubygems.org/gems/rcov</ref>

Follow the [http://wikis.lib.ncsu.edu/index.php/Creating_a_Linux_Development_Environment_for_the_Expertiza_Application linux wiki] to setup Expertiza. Assuming that [https://github.com/expertiza/expertiza Expertiza] is already running, enter these commands:
<pre>
gem install relevance-rcov
bundle install
rake db:create
rake db:test:prepare
</pre>
Modify the file ./lib/task/cucumber.rake. Add the line "t.rcov=true" below each of the three t.profile lines.
<pre>
Cucumber::Rake::Task.new({:ok => 'db:test:prepare'}, 'Run features that should pass') do |t|
t.binary = vendored_cucumber_bin # If nil, the gem's binary is used.
t.fork = true # You may get faster startup if you set this to false
t.profile = 'default'
t.rocv = true #add this line for coverage report
end

Cucumber::Rake::Task.new({:wip => 'db:test:prepare'}, 'Run features that are being worked on') do |t|
t.binary = vendored_cucumber_bin
t.fork = true # You may get faster startup if you set this to false
t.profile = 'wip'
t.rocv = true #add this line for coverage report
end

Cucumber::Rake::Task.new({:rerun => 'db:test:prepare'}, 'Record failing features and run only them if any exist') do |t|
t.binary = vendored_cucumber_bin
t.fork = true # You may get faster startup if you set this to false
t.profile = 'rerun'
t.rocv = true #add this line for coverage report
end
</pre>

== Running ==
===Run Coverage and All Features===
Enter the command below to run the entire cucumber feature suite '''and''' get code coverage reports.
<pre>
rake features
</pre>

===Run All Features <ref name='old_wiki'/>===
To run all cucumber features found within the ./features directory:
<pre>bundle exec cucumber</pre>

=== Run a Single Feature <ref name='old_wiki'/> ===
To run all scenarios for a single cucumber feature:
<pre>bundle exec cucumber features/admin/impersonate_user.feature</pre>

=== Run a Single Scenario <ref name='old_wiki'/>===
To run specific scenario within a feature, specify the line number:
<pre>bundle exec cucumber features/admin/impersonate_user.feature:5</pre>

== Coverage Reports ==
The coverage reports will be generated in the folder ./coverage. <ref name='rcov'> https://github.com/cucumber/cucumber/wiki/Using-RCov-with-Cucumber-and-Rails </ref>
The reports will be in an HTML format. View the report by opening ./coverage/index.html in a [http://en.wikipedia.org/wiki/Web_browser browser].

The main output of [https://github.com/relevance/rcov rcov]is a web page shown below which lists each source file on the left followed by the coverage percentage of that source file. Clicking on the source file link will show the line by line coverage of that source file.

[[File:coverage_screen.jpg]]

== Design Patterns ==
The work that we did in implementing this project did not introduce any new design patterns to the Expertiza system that were of our own creation.

The Cucumber system, however, does exhibit the [http://en.wikipedia.org/wiki/Facade_pattern? Facade Pattern]. The Facade Pattern provides a simplified interface to a software system. The Cucumber package provides this facade through the steps in Capybara. The simplified interface allows the software developer to write tests in something close to a natural language.

== Outcome ==

=== File Organization ===
Before there were 35 feature files. They have been consolidated to 20 files. The largest improvement is the feature folder 'student' as shown below:

{| class="wikitable"
! style="width: 50%" | Before
! style="width: 50%" | After
|-
|[[File:Before.PNG|left|Before]]
|[[File:After.PNG|227px|After]]
|}

=== Coverage Increase ===
The overall coverage increase was small, but measurable.
Before
 
*Total Coverage: 33.29%
*Code coverage: 26.70%
 
After
 
*Total Coverage: 34.17%
*Code coverage: 27.45%

== References ==
<references/>

CSC/ECE 517 Spring 2013/OSS E600

2013-03-21T03:11:34Z

Dshuffma: /* Coverage Reports */

== OSS E600 ==

'''Writing Assignment 2'''
__TOC__

== Introduction ==
There were three goals in the OSS E600 project <ref name='assignment'> http://courses.ncsu.edu/csc517/common/homework/OSS/expertiza.html</ref>
#Restructure the feature files for better organization. Feature folders like 'student' had few scenarios strung out between many files. Consolidate the files to make them more useful.
#Determine a gem that will generate code coverage reports. It needs to work with Ruby 1.8.7 and Rails 2.
#Use the coverage tool to find areas that need the most improvement. Then create new tests targeting those areas to increase coverage.

== Setup ==
Setting up the coverage + cucumber environment is very similar to setting up for only cucumber. The majority of the instructions in the old cucumber [http://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza wiki] still apply.<ref name='old_wiki'>http://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza</ref>

The gem we choose is called [https://github.com/relevance/rcov rcov], and we have the one by [https://github.com/relevance/rcov relevance]. <ref name='rcov_gem'>http://rubygems.org/gems/rcov</ref>

Follow the [http://wikis.lib.ncsu.edu/index.php/Creating_a_Linux_Development_Environment_for_the_Expertiza_Application linux wiki] to setup Expertiza. Assuming that [https://github.com/expertiza/expertiza Expertiza] is already running, enter these commands:
<pre>
gem install relevance-rcov
bundle install
rake db:create
rake db:test:prepare
</pre>
Modify the file ./lib/task/cucumber.rake. Add the line "t.rcov=true" below each of the three t.profile lines.
<pre>
Cucumber::Rake::Task.new({:ok => 'db:test:prepare'}, 'Run features that should pass') do |t|
t.binary = vendored_cucumber_bin # If nil, the gem's binary is used.
t.fork = true # You may get faster startup if you set this to false
t.profile = 'default'
t.rocv = true #add this line for coverage report
end

Cucumber::Rake::Task.new({:wip => 'db:test:prepare'}, 'Run features that are being worked on') do |t|
t.binary = vendored_cucumber_bin
t.fork = true # You may get faster startup if you set this to false
t.profile = 'wip'
t.rocv = true #add this line for coverage report
end

Cucumber::Rake::Task.new({:rerun => 'db:test:prepare'}, 'Record failing features and run only them if any exist') do |t|
t.binary = vendored_cucumber_bin
t.fork = true # You may get faster startup if you set this to false
t.profile = 'rerun'
t.rocv = true #add this line for coverage report
end
</pre>

== Running ==
===Run Coverage and All Features===
Enter the command below to run the entire cucumber feature suite '''and''' get code coverage reports.
<pre>
rake features
</pre>

===Run All Features <ref name='old_wiki'/>===
To run all cucumber features found within the ./features directory:
<pre>bundle exec cucumber</pre>

=== Run a Single Feature <ref name='old_wiki'/> ===
To run all scenarios for a single cucumber feature:
<pre>bundle exec cucumber features/admin/impersonate_user.feature</pre>

=== Run a Single Scenario <ref name='old_wiki'/>===
To run specific scenario within a feature, specify the line number:
<pre>bundle exec cucumber features/admin/impersonate_user.feature:5</pre>

== Coverage Reports ==
The coverage reports will be generated in the folder ./coverage. <ref name='rcov'> https://github.com/cucumber/cucumber/wiki/Using-RCov-with-Cucumber-and-Rails </ref>
The reports will be in an HTML format. View the report by opening ./coverage/index.html in a [http://en.wikipedia.org/wiki/Web_browser browser].

The main output of [https://github.com/relevance/rcov rcov]is a web page shown below which lists each source file on the left followed by the coverage percentage of that source file. Clicking on the source file link will show the line by line coverage of that source file.

[[File:coverage_screen.jpg]]

== Design Patterns ==
The work that we did in implementing this project did not introduce any new design patterns to the Expertiza system that were of our own creation.

The Cucumber system, however, does exhibit the [http://en.wikipedia.org/wiki/Facade_pattern? Facade Pattern]. The Facade Pattern provides a simplified interface to a software system. The Cucumber package provides this facade through the steps in Capybara. The simplified interface allows the software developer to write tests in something close to a natural language.

== Outcome ==

=== File Organization ===
Before there were 35 feature files. They have been consolidated to 20 files. The largest improvement is the feature folder 'student' as shown below:

{| class="wikitable"
! style="width: 50%" | Before
! style="width: 50%" | After
|-
|[[File:Before.PNG|left|Before]]
|[[File:After.PNG|227px|After]]
|}

=== Coverage Increase ===
Before
 
Total Coverage: 33.29%
Code coverage: 26.70%
 
After
 
Total Coverage: 34.17%
Code coverage: 27.45%

== References ==
<references/>

CSC/ECE 517 Spring 2013/OSS E600

2013-03-21T03:09:55Z

Dshuffma: /* OSS E600 */

== OSS E600 ==

'''Writing Assignment 2'''
__TOC__

== Introduction ==
There were three goals in the OSS E600 project <ref name='assignment'> http://courses.ncsu.edu/csc517/common/homework/OSS/expertiza.html</ref>
#Restructure the feature files for better organization. Feature folders like 'student' had few scenarios strung out between many files. Consolidate the files to make them more useful.
#Determine a gem that will generate code coverage reports. It needs to work with Ruby 1.8.7 and Rails 2.
#Use the coverage tool to find areas that need the most improvement. Then create new tests targeting those areas to increase coverage.

== Setup ==
Setting up the coverage + cucumber environment is very similar to setting up for only cucumber. The majority of the instructions in the old cucumber [http://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza wiki] still apply.<ref name='old_wiki'>http://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza</ref>

The gem we choose is called [https://github.com/relevance/rcov rcov], and we have the one by [https://github.com/relevance/rcov relevance]. <ref name='rcov_gem'>http://rubygems.org/gems/rcov</ref>

Follow the [http://wikis.lib.ncsu.edu/index.php/Creating_a_Linux_Development_Environment_for_the_Expertiza_Application linux wiki] to setup Expertiza. Assuming that [https://github.com/expertiza/expertiza Expertiza] is already running, enter these commands:
<pre>
gem install relevance-rcov
bundle install
rake db:create
rake db:test:prepare
</pre>
Modify the file ./lib/task/cucumber.rake. Add the line "t.rcov=true" below each of the three t.profile lines.
<pre>
Cucumber::Rake::Task.new({:ok => 'db:test:prepare'}, 'Run features that should pass') do |t|
t.binary = vendored_cucumber_bin # If nil, the gem's binary is used.
t.fork = true # You may get faster startup if you set this to false
t.profile = 'default'
t.rocv = true #add this line for coverage report
end

Cucumber::Rake::Task.new({:wip => 'db:test:prepare'}, 'Run features that are being worked on') do |t|
t.binary = vendored_cucumber_bin
t.fork = true # You may get faster startup if you set this to false
t.profile = 'wip'
t.rocv = true #add this line for coverage report
end

Cucumber::Rake::Task.new({:rerun => 'db:test:prepare'}, 'Record failing features and run only them if any exist') do |t|
t.binary = vendored_cucumber_bin
t.fork = true # You may get faster startup if you set this to false
t.profile = 'rerun'
t.rocv = true #add this line for coverage report
end
</pre>

== Running ==
===Run Coverage and All Features===
Enter the command below to run the entire cucumber feature suite '''and''' get code coverage reports.
<pre>
rake features
</pre>

===Run All Features <ref name='old_wiki'/>===
To run all cucumber features found within the ./features directory:
<pre>bundle exec cucumber</pre>

=== Run a Single Feature <ref name='old_wiki'/> ===
To run all scenarios for a single cucumber feature:
<pre>bundle exec cucumber features/admin/impersonate_user.feature</pre>

=== Run a Single Scenario <ref name='old_wiki'/>===
To run specific scenario within a feature, specify the line number:
<pre>bundle exec cucumber features/admin/impersonate_user.feature:5</pre>

== Coverage Reports ==
The coverage reports will be generated in the folder ./coverage. <ref name='rcov'> https://github.com/cucumber/cucumber/wiki/Using-RCov-with-Cucumber-and-Rails </ref>
The reports will be in an HTML format. View the report by opening ./coverage/index.html in a [http://en.wikipedia.org/wiki/Web_browser browser].

The main output of rcov is a web page shown below which lists each source file on the left followed by the coverage percentage of that source file. Clicking on the source file link will show the line by line coverage of that source file.

[[File:coverage_screen.jpg]]

== Design Patterns ==
The work that we did in implementing this project did not introduce any new design patterns to the Expertiza system that were of our own creation.

The Cucumber system, however, does exhibit the [http://en.wikipedia.org/wiki/Facade_pattern? Facade Pattern]. The Facade Pattern provides a simplified interface to a software system. The Cucumber package provides this facade through the steps in Capybara. The simplified interface allows the software developer to write tests in something close to a natural language.

== Outcome ==

=== File Organization ===
Before there were 35 feature files. They have been consolidated to 20 files. The largest improvement is the feature folder 'student' as shown below:

{| class="wikitable"
! style="width: 50%" | Before
! style="width: 50%" | After
|-
|[[File:Before.PNG|left|Before]]
|[[File:After.PNG|227px|After]]
|}

=== Coverage Increase ===
Before
 
Total Coverage: 33.29%
Code coverage: 26.70%
 
After
 
Total Coverage: 34.17%
Code coverage: 27.45%

== References ==
<references/>