<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Eleill</id>
	<title>Expertiza_Wiki - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Eleill"/>
	<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Special:Contributions/Eleill"/>
	<updated>2026-06-02T20:07:04Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.41.0</generator>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108818</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108818"/>
		<updated>2017-04-30T03:55:06Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Automated Testing within Rails */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. The completed code from previous projects did not clearly demonstrate successful integration with SimiCheck from Expertiza, and was not deemed production worthy. Based on this feedback, we started our development from scratch and utilized the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
The majority of the updates are handled in new background tasks. Therefore, there weren't many modifications to existing Expertiza files. The current New Assignment interface has two new configuration parameters, which have also been added to the Assignment model. SimiCheck Delay (hours) and SimiCheck Similarity Threshold (percentage) were added. The Plagiarism Comparison Report was added to the &amp;quot;Review Report&amp;quot; interface's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== Assignment - SimiCheck delay and threshold added ====&lt;br /&gt;
We added &amp;quot;simicheck&amp;quot; and &amp;quot;simicheck_threshold&amp;quot; properties to the the existing Assignment model. &lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck&amp;quot; property accommodates the number of hours to delay the execution of the Plagiarism Checker after the assignment's due date. &amp;quot;simicheck&amp;quot; is -1 if there is no Plagiarism Checker scheduled, and between 0 and 100 (hours) if the assignment is to have a Plagiarism Checker Report.&lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck_threshold&amp;quot; property is a percentage that filters the Plagiarism Checker's Similarity results. The threshold refers to the percentage of text that is the same between two documents.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, the Team IDs, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagrams ===&lt;br /&gt;
Typical overall system operation:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_SimiCheck.png]]&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
Class heirarchy in the fetchers:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:SimiCheck_Fetchers.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
The current assignment configuration UI has been modified to contain 2 new select boxes. These select boxes determine how long to delay the Plagiarism Checker after an assignment's due date, and on what similarity percent to filter the Plagiarism Checker Comparison results.  &lt;br /&gt;
&lt;br /&gt;
After the results have been aggregated they can be viewed in a results report page. This report includes the submission names, the responsible teams, the similarity percentage, and a link to view the similarity results. The Plagiarism Checker Report UI looks similar to this:&lt;br /&gt;
&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To view the interface changes, login to Expertiza as an instructor; navigate to Manage... Assignments. Click &amp;quot;New public/private assignment&amp;quot;. The last two fields on the New Assignment page say &amp;quot;SimiCheck  Delay&amp;quot; and &amp;quot;SimiCheck Similarity Threshold&amp;quot;. In &amp;quot;SimiCheck Delay&amp;quot;, select a value between 0 and 100 to enable the Plagiarism Checker. In &amp;quot;SimiCheck Similarity Threshold&amp;quot;, select a percentage value to filter the Plagiarism Checker Comparison results. The percentage refers to the percent of same text between two documents. &lt;br /&gt;
&lt;br /&gt;
After the assignment ends and the delay period has passed, you can view the Plagiarism Report. Click the &amp;quot;View review report&amp;quot; icon containing a magnifying glass and two people (in the third row of per-assignment icons). Select &amp;quot;Plagiarism Checker Report&amp;quot; from the select box, and click &amp;quot;Submit&amp;quot;. If there is any plagiarism to report, it will load.&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
In Expertiza there already existed functionality to schedule or queue tasks for the task system. We have hooked into that system by adding a new task type declared as &amp;quot;compare_files_with_simicheck&amp;quot; and then providing the correct date/time configuration. When a task deadline occurs, there is a method that invokes logic based on the task type. Once this task type is detected on a scheduled task, the SimiCheck comparison is initiated.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample ===&lt;br /&gt;
====Scheduled task expires, hook is called====&lt;br /&gt;
The following code was added to app/mailers/delayed_mailer.rb/perform:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
  if (self.deadline_type == &amp;quot;compare_files_with_simicheck&amp;quot;)&lt;br /&gt;
    perform_simicheck_comparisons(self.assignment_id)&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We wrote unit tests for the new functionality that we implemented, this included models, helpers, SimiCheck logic etc.. In order to properly unit test we mocked all interfaces and black box tested the new functionality. Our test cases can be found in the following locations:&lt;br /&gt;
*spec/models/website_fetcher_spec.rb&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108817</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108817"/>
		<updated>2017-04-30T03:51:25Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Testing Strategy */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. The completed code from previous projects did not clearly demonstrate successful integration with SimiCheck from Expertiza, and was not deemed production worthy. Based on this feedback, we started our development from scratch and utilized the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
The majority of the updates are handled in new background tasks. Therefore, there weren't many modifications to existing Expertiza files. The current New Assignment interface has two new configuration parameters, which have also been added to the Assignment model. SimiCheck Delay (hours) and SimiCheck Similarity Threshold (percentage) were added. The Plagiarism Comparison Report was added to the &amp;quot;Review Report&amp;quot; interface's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== Assignment - SimiCheck delay and threshold added ====&lt;br /&gt;
We added &amp;quot;simicheck&amp;quot; and &amp;quot;simicheck_threshold&amp;quot; properties to the the existing Assignment model. &lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck&amp;quot; property accommodates the number of hours to delay the execution of the Plagiarism Checker after the assignment's due date. &amp;quot;simicheck&amp;quot; is -1 if there is no Plagiarism Checker scheduled, and between 0 and 100 (hours) if the assignment is to have a Plagiarism Checker Report.&lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck_threshold&amp;quot; property is a percentage that filters the Plagiarism Checker's Similarity results. The threshold refers to the percentage of text that is the same between two documents.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, the Team IDs, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagrams ===&lt;br /&gt;
Typical overall system operation:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_SimiCheck.png]]&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
Class heirarchy in the fetchers:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:SimiCheck_Fetchers.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
The current assignment configuration UI has been modified to contain 2 new select boxes. These select boxes determine how long to delay the Plagiarism Checker after an assignment's due date, and on what similarity percent to filter the Plagiarism Checker Comparison results.  &lt;br /&gt;
&lt;br /&gt;
After the results have been aggregated they can be viewed in a results report page. This report includes the submission names, the responsible teams, the similarity percentage, and a link to view the similarity results. The Plagiarism Checker Report UI looks similar to this:&lt;br /&gt;
&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To view the interface changes, login to Expertiza as an instructor; navigate to Manage... Assignments. Click &amp;quot;New public/private assignment&amp;quot;. The last two fields on the New Assignment page say &amp;quot;SimiCheck  Delay&amp;quot; and &amp;quot;SimiCheck Similarity Threshold&amp;quot;. In &amp;quot;SimiCheck Delay&amp;quot;, select a value between 0 and 100 to enable the Plagiarism Checker. In &amp;quot;SimiCheck Similarity Threshold&amp;quot;, select a percentage value to filter the Plagiarism Checker Comparison results. The percentage refers to the percent of same text between two documents. &lt;br /&gt;
&lt;br /&gt;
After the assignment ends and the delay period has passed, you can view the Plagiarism Report. Click the &amp;quot;View review report&amp;quot; icon containing a magnifying glass and two people (in the third row of per-assignment icons). Select &amp;quot;Plagiarism Checker Report&amp;quot; from the select box, and click &amp;quot;Submit&amp;quot;. If there is any plagiarism to report, it will load.&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
In Expertiza there already existed functionality to schedule or queue tasks for the task system. We have hooked into that system by adding a new task type declared as &amp;quot;compare_files_with_simicheck&amp;quot; and then providing the correct date/time configuration. When a task deadline occurs, there is a method that invokes logic based on the task type. Once this task type is detected on a scheduled task, the SimiCheck comparison is initiated.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample ===&lt;br /&gt;
====Scheduled task expires, hook is called====&lt;br /&gt;
The following code was added to app/mailers/delayed_mailer.rb/perform:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
  if (self.deadline_type == &amp;quot;compare_files_with_simicheck&amp;quot;)&lt;br /&gt;
    perform_simicheck_comparisons(self.assignment_id)&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We wrote unit tests for the new functionality that we implemented, this included models, helpers, SimiCheck logic etc.. In order to properly unit test we mocked all interfaces and black box tested the new functionality. Our test cases can be found in the following locations:&lt;br /&gt;
&amp;lt;br&amp;gt;spec/models/website_fetcher_spec.rb&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108816</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108816"/>
		<updated>2017-04-30T03:51:01Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* User Interface */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. The completed code from previous projects did not clearly demonstrate successful integration with SimiCheck from Expertiza, and was not deemed production worthy. Based on this feedback, we started our development from scratch and utilized the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
The majority of the updates are handled in new background tasks. Therefore, there weren't many modifications to existing Expertiza files. The current New Assignment interface has two new configuration parameters, which have also been added to the Assignment model. SimiCheck Delay (hours) and SimiCheck Similarity Threshold (percentage) were added. The Plagiarism Comparison Report was added to the &amp;quot;Review Report&amp;quot; interface's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== Assignment - SimiCheck delay and threshold added ====&lt;br /&gt;
We added &amp;quot;simicheck&amp;quot; and &amp;quot;simicheck_threshold&amp;quot; properties to the the existing Assignment model. &lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck&amp;quot; property accommodates the number of hours to delay the execution of the Plagiarism Checker after the assignment's due date. &amp;quot;simicheck&amp;quot; is -1 if there is no Plagiarism Checker scheduled, and between 0 and 100 (hours) if the assignment is to have a Plagiarism Checker Report.&lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck_threshold&amp;quot; property is a percentage that filters the Plagiarism Checker's Similarity results. The threshold refers to the percentage of text that is the same between two documents.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, the Team IDs, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagrams ===&lt;br /&gt;
Typical overall system operation:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_SimiCheck.png]]&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
Class heirarchy in the fetchers:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:SimiCheck_Fetchers.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
The current assignment configuration UI has been modified to contain 2 new select boxes. These select boxes determine how long to delay the Plagiarism Checker after an assignment's due date, and on what similarity percent to filter the Plagiarism Checker Comparison results.  &lt;br /&gt;
&lt;br /&gt;
After the results have been aggregated they can be viewed in a results report page. This report includes the submission names, the responsible teams, the similarity percentage, and a link to view the similarity results. The Plagiarism Checker Report UI looks similar to this:&lt;br /&gt;
&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To view the interface changes, login to Expertiza as an instructor; navigate to Manage... Assignments. Click &amp;quot;New public/private assignment&amp;quot;. The last two fields on the New Assignment page say &amp;quot;SimiCheck  Delay&amp;quot; and &amp;quot;SimiCheck Similarity Threshold&amp;quot;. In &amp;quot;SimiCheck Delay&amp;quot;, select a value between 0 and 100 to enable the Plagiarism Checker. In &amp;quot;SimiCheck Similarity Threshold&amp;quot;, select a percentage value to filter the Plagiarism Checker Comparison results. The percentage refers to the percent of same text between two documents. &lt;br /&gt;
&lt;br /&gt;
After the assignment ends and the delay period has passed, you can view the Plagiarism Report. Click the &amp;quot;View review report&amp;quot; icon containing a magnifying glass and two people (in the third row of per-assignment icons). Select &amp;quot;Plagiarism Checker Report&amp;quot; from the select box, and click &amp;quot;Submit&amp;quot;. If there is any plagiarism to report, it will load.&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
In Expertiza there already existed functionality to schedule or queue tasks for the task system. We have hooked into that system by adding a new task type declared as &amp;quot;compare_files_with_simicheck&amp;quot; and then providing the correct date/time configuration. When a task deadline occurs, there is a method that invokes logic based on the task type. Once this task type is detected on a scheduled task, the SimiCheck comparison is initiated.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample ===&lt;br /&gt;
====Scheduled task expires, hook is called====&lt;br /&gt;
The following code was added to app/mailers/delayed_mailer.rb/perform:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
  if (self.deadline_type == &amp;quot;compare_files_with_simicheck&amp;quot;)&lt;br /&gt;
    perform_simicheck_comparisons(self.assignment_id)&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We wrote unit tests for the new functionality that we implemented, this included models, helpers, simicheck logic etc.. In order to properly unit test we mocked all interfaces and black box tested the new functionality. Our test cases can be found in the following locations:&lt;br /&gt;
&amp;lt;br&amp;gt;spec/models/website_fetcher_spec.rb&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108815</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108815"/>
		<updated>2017-04-30T03:50:33Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* API Testing during Development */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. The completed code from previous projects did not clearly demonstrate successful integration with SimiCheck from Expertiza, and was not deemed production worthy. Based on this feedback, we started our development from scratch and utilized the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
The majority of the updates are handled in new background tasks. Therefore, there weren't many modifications to existing Expertiza files. The current New Assignment interface has two new configuration parameters, which have also been added to the Assignment model. SimiCheck Delay (hours) and SimiCheck Similarity Threshold (percentage) were added. The Plagiarism Comparison Report was added to the &amp;quot;Review Report&amp;quot; interface's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== Assignment - SimiCheck delay and threshold added ====&lt;br /&gt;
We added &amp;quot;simicheck&amp;quot; and &amp;quot;simicheck_threshold&amp;quot; properties to the the existing Assignment model. &lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck&amp;quot; property accommodates the number of hours to delay the execution of the Plagiarism Checker after the assignment's due date. &amp;quot;simicheck&amp;quot; is -1 if there is no Plagiarism Checker scheduled, and between 0 and 100 (hours) if the assignment is to have a Plagiarism Checker Report.&lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck_threshold&amp;quot; property is a percentage that filters the Plagiarism Checker's Similarity results. The threshold refers to the percentage of text that is the same between two documents.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, the Team IDs, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagrams ===&lt;br /&gt;
Typical overall system operation:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_SimiCheck.png]]&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
Class heirarchy in the fetchers:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:SimiCheck_Fetchers.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
The current assignment configuration UI has been modified to contain 2 new select boxes. These select boxes determine how long to delay the Plagiarism Checker after an assignment's due date, and on what similarity percent to filter the Plagiarism Checker Comparison results.  &lt;br /&gt;
&lt;br /&gt;
After the results have been aggregated they can be viewed in a results report page. This report includes the submission names, the responsible teams, the similarity percentage, and a link to view the similarity results. The Plagiarism Checker Report UI looks similar to this:&lt;br /&gt;
&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To view the interface changes, login to Expertiza as an instructor; navigate to Manage... Assignments. Click &amp;quot;New public/private assignment&amp;quot;. The last two fields on the New Assignment page say &amp;quot;SimiCheck  Delay&amp;quot; and &amp;quot;SimiCheck Similarity Threshold&amp;quot;. In &amp;quot;Simicheck Delay&amp;quot;, select a value between 0 and 100 to enable the Plagiarism Checker. In &amp;quot;SimiCheck Similarity Threshold&amp;quot;, select a percentage value to filter the Plagiarism Checker Comparison results. The percentage refers to the percent of same text between two documents. &lt;br /&gt;
&lt;br /&gt;
After the assignment ends and the delay period has passed, you can view the Plagiarism Report. Click the &amp;quot;View review report&amp;quot; icon containing a magnifying glass and two people (in the third row of per-assignment icons). Select &amp;quot;Plagiarism Checker Report&amp;quot; from the select box, and click &amp;quot;Submit&amp;quot;. If there is any plagiarism to report, it will load.&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
In Expertiza there already existed functionality to schedule or queue tasks for the task system. We have hooked into that system by adding a new task type declared as &amp;quot;compare_files_with_simicheck&amp;quot; and then providing the correct date/time configuration. When a task deadline occurs, there is a method that invokes logic based on the task type. Once this task type is detected on a scheduled task, the SimiCheck comparison is initiated.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample ===&lt;br /&gt;
====Scheduled task expires, hook is called====&lt;br /&gt;
The following code was added to app/mailers/delayed_mailer.rb/perform:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
  if (self.deadline_type == &amp;quot;compare_files_with_simicheck&amp;quot;)&lt;br /&gt;
    perform_simicheck_comparisons(self.assignment_id)&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We wrote unit tests for the new functionality that we implemented, this included models, helpers, simicheck logic etc.. In order to properly unit test we mocked all interfaces and black box tested the new functionality. Our test cases can be found in the following locations:&lt;br /&gt;
&amp;lt;br&amp;gt;spec/models/website_fetcher_spec.rb&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108813</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108813"/>
		<updated>2017-04-30T03:45:34Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Diagrams */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. The completed code from previous projects did not clearly demonstrate successful integration with SimiCheck from Expertiza, and was not deemed production worthy. Based on this feedback, we started our development from scratch and utilized the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
The majority of the updates are handled in new background tasks. Therefore, there weren't many modifications to existing Expertiza files. The current New Assignment interface has two new configuration parameters, which have also been added to the Assignment model. SimiCheck Delay (hours) and SimiCheck Similarity Threshold (percentage) were added. The Plagiarism Comparison Report was added to the &amp;quot;Review Report&amp;quot; interface's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== Assignment - SimiCheck delay and threshold added ====&lt;br /&gt;
We added &amp;quot;simicheck&amp;quot; and &amp;quot;simicheck_threshold&amp;quot; properties to the the existing Assignment model. &lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck&amp;quot; property accommodates the number of hours to delay the execution of the Plagiarism Checker after the assignment's due date. &amp;quot;simicheck&amp;quot; is -1 if there is no Plagiarism Checker scheduled, and between 0 and 100 (hours) if the assignment is to have a Plagiarism Checker Report.&lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck_threshold&amp;quot; property is a percentage that filters the Plagiarism Checker's Similarity results. The threshold refers to the percentage of text that is the same between two documents.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, the Team IDs, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagrams ===&lt;br /&gt;
Typical overall system operation:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_SimiCheck.png]]&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
Class heirarchy in the fetchers:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:SimiCheck_Fetchers.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
The current assignment configuration UI has been modified to contain 2 new select boxes. These select boxes determine how long to delay the Plagiarism Checker after an assignment's due date, and on what similarity percent to filter the Plagiarism Checker Comparison results.  &lt;br /&gt;
&lt;br /&gt;
After the results have been aggregated they can be viewed in a results report page. This report includes the submission names, the responsible teams, the similarity percentage, and a link to view the similarity results. The Plagiarism Checker Report UI looks similar to this:&lt;br /&gt;
&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To view the interface changes, login to Expertiza as an instructor; navigate to Manage... Assignments. Click &amp;quot;New public/private assignment&amp;quot;. The last two fields on the New Assignment page say &amp;quot;SimiCheck  Delay&amp;quot; and &amp;quot;SimiCheck Similarity Threshold&amp;quot;. In &amp;quot;Simicheck Delay&amp;quot;, select a value between 0 and 100 to enable the Plagiarism Checker. In &amp;quot;SimiCheck Similarity Threshold&amp;quot;, select a percentage value to filter the Plagiarism Checker Comparison results. The percentage refers to the percent of same text between two documents. &lt;br /&gt;
&lt;br /&gt;
After the assignment ends and the delay period has passed, you can view the Plagiarism Report. Click the &amp;quot;View review report&amp;quot; icon containing a magnifying glass and two people (in the third row of per-assignment icons). Select &amp;quot;Plagiarism Checker Report&amp;quot; from the select box, and click &amp;quot;Submit&amp;quot;. If there is any plagiarism to report, it will load.&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
In Expertiza there already existed functionality to schedule or queue tasks for the task system. We have hooked into that system by adding a new task type declared as &amp;quot;compare_files_with_simicheck&amp;quot; and then providing the correct date/time configuration. When a task deadline occurs, there is a method that invokes logic based on the task type. Once this task type is detected on a scheduled task, the SimiCheck comparison is initiated.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample ===&lt;br /&gt;
====Scheduled task expires, hook is called====&lt;br /&gt;
The following code was added to app/mailers/delayed_mailer.rb/perform:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
  if (self.deadline_type == &amp;quot;compare_files_with_simicheck&amp;quot;)&lt;br /&gt;
    perform_simicheck_comparisons(self.assignment_id)&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108812</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108812"/>
		<updated>2017-04-30T03:45:11Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Diagram */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. The completed code from previous projects did not clearly demonstrate successful integration with SimiCheck from Expertiza, and was not deemed production worthy. Based on this feedback, we started our development from scratch and utilized the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
The majority of the updates are handled in new background tasks. Therefore, there weren't many modifications to existing Expertiza files. The current New Assignment interface has two new configuration parameters, which have also been added to the Assignment model. SimiCheck Delay (hours) and SimiCheck Similarity Threshold (percentage) were added. The Plagiarism Comparison Report was added to the &amp;quot;Review Report&amp;quot; interface's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== Assignment - SimiCheck delay and threshold added ====&lt;br /&gt;
We added &amp;quot;simicheck&amp;quot; and &amp;quot;simicheck_threshold&amp;quot; properties to the the existing Assignment model. &lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck&amp;quot; property accommodates the number of hours to delay the execution of the Plagiarism Checker after the assignment's due date. &amp;quot;simicheck&amp;quot; is -1 if there is no Plagiarism Checker scheduled, and between 0 and 100 (hours) if the assignment is to have a Plagiarism Checker Report.&lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck_threshold&amp;quot; property is a percentage that filters the Plagiarism Checker's Similarity results. The threshold refers to the percentage of text that is the same between two documents.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, the Team IDs, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagrams ===&lt;br /&gt;
Typical overall system operation:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_SimiCheck.png]]&lt;br /&gt;
&lt;br /&gt;
Class heirarchy in the fetchers:&lt;br /&gt;
[[File:SimiCheck_Fetchers.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
The current assignment configuration UI has been modified to contain 2 new select boxes. These select boxes determine how long to delay the Plagiarism Checker after an assignment's due date, and on what similarity percent to filter the Plagiarism Checker Comparison results.  &lt;br /&gt;
&lt;br /&gt;
After the results have been aggregated they can be viewed in a results report page. This report includes the submission names, the responsible teams, the similarity percentage, and a link to view the similarity results. The Plagiarism Checker Report UI looks similar to this:&lt;br /&gt;
&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To view the interface changes, login to Expertiza as an instructor; navigate to Manage... Assignments. Click &amp;quot;New public/private assignment&amp;quot;. The last two fields on the New Assignment page say &amp;quot;SimiCheck  Delay&amp;quot; and &amp;quot;SimiCheck Similarity Threshold&amp;quot;. In &amp;quot;Simicheck Delay&amp;quot;, select a value between 0 and 100 to enable the Plagiarism Checker. In &amp;quot;SimiCheck Similarity Threshold&amp;quot;, select a percentage value to filter the Plagiarism Checker Comparison results. The percentage refers to the percent of same text between two documents. &lt;br /&gt;
&lt;br /&gt;
After the assignment ends and the delay period has passed, you can view the Plagiarism Report. Click the &amp;quot;View review report&amp;quot; icon containing a magnifying glass and two people (in the third row of per-assignment icons). Select &amp;quot;Plagiarism Checker Report&amp;quot; from the select box, and click &amp;quot;Submit&amp;quot;. If there is any plagiarism to report, it will load.&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
In Expertiza there already existed functionality to schedule or queue tasks for the task system. We have hooked into that system by adding a new task type declared as &amp;quot;compare_files_with_simicheck&amp;quot; and then providing the correct date/time configuration. When a task deadline occurs, there is a method that invokes logic based on the task type. Once this task type is detected on a scheduled task, the SimiCheck comparison is initiated.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample ===&lt;br /&gt;
====Scheduled task expires, hook is called====&lt;br /&gt;
The following code was added to app/mailers/delayed_mailer.rb/perform:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
  if (self.deadline_type == &amp;quot;compare_files_with_simicheck&amp;quot;)&lt;br /&gt;
    perform_simicheck_comparisons(self.assignment_id)&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=File:SimiCheck_Fetchers.png&amp;diff=108811</id>
		<title>File:SimiCheck Fetchers.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=File:SimiCheck_Fetchers.png&amp;diff=108811"/>
		<updated>2017-04-30T03:43:54Z</updated>

		<summary type="html">&lt;p&gt;Eleill: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108810</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108810"/>
		<updated>2017-04-30T03:34:15Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Code Sample(s) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. The completed code from previous projects did not clearly demonstrate successful integration with SimiCheck from Expertiza, and was not deemed production worthy. Based on this feedback, we started our development from scratch and utilized the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
The majority of the updates are handled in new background tasks. Therefore, there weren't many modifications to existing Expertiza files. The current New Assignment interface has two new configuration parameters, which have also been added to the Assignment model. SimiCheck Delay (hours) and SimiCheck Similarity Threshold (percentage) were added. The Plagiarism Comparison Report was added to the &amp;quot;Review Report&amp;quot; interface's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== Assignment - SimiCheck delay and threshold added ====&lt;br /&gt;
We added &amp;quot;simicheck&amp;quot; and &amp;quot;simicheck_threshold&amp;quot; properties to the the existing Assignment model. &lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck&amp;quot; property accommodates the number of hours to delay the execution of the Plagiarism Checker after the assignment's due date. &amp;quot;simicheck&amp;quot; is -1 if there is no Plagiarism Checker scheduled, and between 0 and 100 (hours) if the assignment is to have a Plagiarism Checker Report.&lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck_threshold&amp;quot; property is a percentage that filters the Plagiarism Checker's Similarity results. The threshold refers to the percentage of text that is the same between two documents.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, the Team IDs, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_SimiCheck.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
The current assignment configuration UI has been modified to contain 2 new select boxes. These select boxes determine how long to delay the Plagiarism Checker after an assignment's due date, and on what similarity percent to filter the Plagiarism Checker Comparison results.  &lt;br /&gt;
&lt;br /&gt;
After the results have been aggregated they can be viewed in a results report page. This report includes the submission names, the responsible teams, the similarity percentage, and a link to view the similarity results. The Plagiarism Checker Report UI looks similar to this:&lt;br /&gt;
&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To view the interface changes, login to Expertiza as an instructor; navigate to Manage... Assignments. Click &amp;quot;New public/private assignment&amp;quot;. The last two fields on the New Assignment page say &amp;quot;SimiCheck  Delay&amp;quot; and &amp;quot;SimiCheck Similarity Threshold&amp;quot;. In &amp;quot;Simicheck Delay&amp;quot;, select a value between 0 and 100 to enable the Plagiarism Checker. In &amp;quot;SimiCheck Similarity Threshold&amp;quot;, select a percentage value to filter the Plagiarism Checker Comparison results. The percentage refers to the percent of same text between two documents. &lt;br /&gt;
&lt;br /&gt;
After the assignment ends and the delay period has passed, you can view the Plagiarism Report. Click the &amp;quot;View review report&amp;quot; icon containing a magnifying glass and two people (in the third row of per-assignment icons). Select &amp;quot;Plagiarism Checker Report&amp;quot; from the select box, and click &amp;quot;Submit&amp;quot;. If there is any plagiarism to report, it will load.&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
In Expertiza there already existed functionality to schedule or queue tasks for the task system. We have hooked into that system by adding a new task type declared as &amp;quot;compare_files_with_simicheck&amp;quot; and then providing the correct date/time configuration. When a task deadline occurs, there is a method that invokes logic based on the task type. Once this task type is detected on a scheduled task, the SimiCheck comparison is initiated.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample ===&lt;br /&gt;
====Scheduled task expires, hook is called====&lt;br /&gt;
The following code was added to app/mailers/delayed_mailer.rb/perform:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
  if (self.deadline_type == &amp;quot;compare_files_with_simicheck&amp;quot;)&lt;br /&gt;
    perform_simicheck_comparisons(self.assignment_id)&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108809</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108809"/>
		<updated>2017-04-30T03:32:20Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Scheduled task expires, hook is called */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. The completed code from previous projects did not clearly demonstrate successful integration with SimiCheck from Expertiza, and was not deemed production worthy. Based on this feedback, we started our development from scratch and utilized the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
The majority of the updates are handled in new background tasks. Therefore, there weren't many modifications to existing Expertiza files. The current New Assignment interface has two new configuration parameters, which have also been added to the Assignment model. SimiCheck Delay (hours) and SimiCheck Similarity Threshold (percentage) were added. The Plagiarism Comparison Report was added to the &amp;quot;Review Report&amp;quot; interface's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== Assignment - SimiCheck delay and threshold added ====&lt;br /&gt;
We added &amp;quot;simicheck&amp;quot; and &amp;quot;simicheck_threshold&amp;quot; properties to the the existing Assignment model. &lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck&amp;quot; property accommodates the number of hours to delay the execution of the Plagiarism Checker after the assignment's due date. &amp;quot;simicheck&amp;quot; is -1 if there is no Plagiarism Checker scheduled, and between 0 and 100 (hours) if the assignment is to have a Plagiarism Checker Report.&lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck_threshold&amp;quot; property is a percentage that filters the Plagiarism Checker's Similarity results. The threshold refers to the percentage of text that is the same between two documents.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, the Team IDs, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_SimiCheck.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
The current assignment configuration UI has been modified to contain 2 new select boxes. These select boxes determine how long to delay the Plagiarism Checker after an assignment's due date, and on what similarity percent to filter the Plagiarism Checker Comparison results.  &lt;br /&gt;
&lt;br /&gt;
After the results have been aggregated they can be viewed in a results report page. This report includes the submission names, the responsible teams, the similarity percentage, and a link to view the similarity results. The Plagiarism Checker Report UI looks similar to this:&lt;br /&gt;
&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To view the interface changes, login to Expertiza as an instructor; navigate to Manage... Assignments. Click &amp;quot;New public/private assignment&amp;quot;. The last two fields on the New Assignment page say &amp;quot;SimiCheck  Delay&amp;quot; and &amp;quot;SimiCheck Similarity Threshold&amp;quot;. In &amp;quot;Simicheck Delay&amp;quot;, select a value between 0 and 100 to enable the Plagiarism Checker. In &amp;quot;SimiCheck Similarity Threshold&amp;quot;, select a percentage value to filter the Plagiarism Checker Comparison results. The percentage refers to the percent of same text between two documents. &lt;br /&gt;
&lt;br /&gt;
After the assignment ends and the delay period has passed, you can view the Plagiarism Report. Click the &amp;quot;View review report&amp;quot; icon containing a magnifying glass and two people (in the third row of per-assignment icons). Select &amp;quot;Plagiarism Checker Report&amp;quot; from the select box, and click &amp;quot;Submit&amp;quot;. If there is any plagiarism to report, it will load.&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
In Expertiza there already existed functionality to schedule or queue tasks for the task system. We have hooked into that system by adding a new task type declared as &amp;quot;compare_files_with_simicheck&amp;quot; and then providing the correct date/time configuration. When a task deadline occurs, there is a method that invokes logic based on the task type. Once this task type is detected on a scheduled task, the SimiCheck comparison is initiated.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample(s) ===&lt;br /&gt;
====Scheduled task expires, hook is called====&lt;br /&gt;
The following code was added to app/mailers/delayed_mailer.rb/perform:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
  if (self.deadline_type == &amp;quot;compare_files_with_simicheck&amp;quot;)&lt;br /&gt;
    perform_simicheck_comparisons(self.assignment_id)&lt;br /&gt;
  end&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108808</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108808"/>
		<updated>2017-04-30T03:29:22Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Scheduled task expires, hook is called */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. The completed code from previous projects did not clearly demonstrate successful integration with SimiCheck from Expertiza, and was not deemed production worthy. Based on this feedback, we started our development from scratch and utilized the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
The majority of the updates are handled in new background tasks. Therefore, there weren't many modifications to existing Expertiza files. The current New Assignment interface has two new configuration parameters, which have also been added to the Assignment model. SimiCheck Delay (hours) and SimiCheck Similarity Threshold (percentage) were added. The Plagiarism Comparison Report was added to the &amp;quot;Review Report&amp;quot; interface's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== Assignment - SimiCheck delay and threshold added ====&lt;br /&gt;
We added &amp;quot;simicheck&amp;quot; and &amp;quot;simicheck_threshold&amp;quot; properties to the the existing Assignment model. &lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck&amp;quot; property accommodates the number of hours to delay the execution of the Plagiarism Checker after the assignment's due date. &amp;quot;simicheck&amp;quot; is -1 if there is no Plagiarism Checker scheduled, and between 0 and 100 (hours) if the assignment is to have a Plagiarism Checker Report.&lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck_threshold&amp;quot; property is a percentage that filters the Plagiarism Checker's Similarity results. The threshold refers to the percentage of text that is the same between two documents.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, the Team IDs, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_SimiCheck.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
The current assignment configuration UI has been modified to contain 2 new select boxes. These select boxes determine how long to delay the Plagiarism Checker after an assignment's due date, and on what similarity percent to filter the Plagiarism Checker Comparison results.  &lt;br /&gt;
&lt;br /&gt;
After the results have been aggregated they can be viewed in a results report page. This report includes the submission names, the responsible teams, the similarity percentage, and a link to view the similarity results. The Plagiarism Checker Report UI looks similar to this:&lt;br /&gt;
&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To view the interface changes, login to Expertiza as an instructor; navigate to Manage... Assignments. Click &amp;quot;New public/private assignment&amp;quot;. The last two fields on the New Assignment page say &amp;quot;SimiCheck  Delay&amp;quot; and &amp;quot;SimiCheck Similarity Threshold&amp;quot;. In &amp;quot;Simicheck Delay&amp;quot;, select a value between 0 and 100 to enable the Plagiarism Checker. In &amp;quot;SimiCheck Similarity Threshold&amp;quot;, select a percentage value to filter the Plagiarism Checker Comparison results. The percentage refers to the percent of same text between two documents. &lt;br /&gt;
&lt;br /&gt;
After the assignment ends and the delay period has passed, you can view the Plagiarism Report. Click the &amp;quot;View review report&amp;quot; icon containing a magnifying glass and two people (in the third row of per-assignment icons). Select &amp;quot;Plagiarism Checker Report&amp;quot; from the select box, and click &amp;quot;Submit&amp;quot;. If there is any plagiarism to report, it will load.&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
In Expertiza there already existed functionality to schedule or queue tasks for the task system. We have hooked into that system by adding a new task type declared as &amp;quot;compare_files_with_simicheck&amp;quot; and then providing the correct date/time configuration. When a task deadline occurs, there is a method that invokes logic based on the task type. Once this task type is detected on a scheduled task, the SimiCheck comparison is initiated.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample(s) ===&lt;br /&gt;
====Scheduled task expires, hook is called====&lt;br /&gt;
The following code was added to app/mailers/delayed_mailer.rb/perform:&lt;br /&gt;
&amp;lt;code&amp;gt;if (self.deadline_type == &amp;quot;compare_files_with_simicheck&amp;quot;)&lt;br /&gt;
  perform_simicheck_comparisons(self.assignment_id)&lt;br /&gt;
end&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108807</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108807"/>
		<updated>2017-04-30T03:28:25Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Code Sample(s) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. The completed code from previous projects did not clearly demonstrate successful integration with SimiCheck from Expertiza, and was not deemed production worthy. Based on this feedback, we started our development from scratch and utilized the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
The majority of the updates are handled in new background tasks. Therefore, there weren't many modifications to existing Expertiza files. The current New Assignment interface has two new configuration parameters, which have also been added to the Assignment model. SimiCheck Delay (hours) and SimiCheck Similarity Threshold (percentage) were added. The Plagiarism Comparison Report was added to the &amp;quot;Review Report&amp;quot; interface's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== Assignment - SimiCheck delay and threshold added ====&lt;br /&gt;
We added &amp;quot;simicheck&amp;quot; and &amp;quot;simicheck_threshold&amp;quot; properties to the the existing Assignment model. &lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck&amp;quot; property accommodates the number of hours to delay the execution of the Plagiarism Checker after the assignment's due date. &amp;quot;simicheck&amp;quot; is -1 if there is no Plagiarism Checker scheduled, and between 0 and 100 (hours) if the assignment is to have a Plagiarism Checker Report.&lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck_threshold&amp;quot; property is a percentage that filters the Plagiarism Checker's Similarity results. The threshold refers to the percentage of text that is the same between two documents.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, the Team IDs, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_SimiCheck.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
The current assignment configuration UI has been modified to contain 2 new select boxes. These select boxes determine how long to delay the Plagiarism Checker after an assignment's due date, and on what similarity percent to filter the Plagiarism Checker Comparison results.  &lt;br /&gt;
&lt;br /&gt;
After the results have been aggregated they can be viewed in a results report page. This report includes the submission names, the responsible teams, the similarity percentage, and a link to view the similarity results. The Plagiarism Checker Report UI looks similar to this:&lt;br /&gt;
&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To view the interface changes, login to Expertiza as an instructor; navigate to Manage... Assignments. Click &amp;quot;New public/private assignment&amp;quot;. The last two fields on the New Assignment page say &amp;quot;SimiCheck  Delay&amp;quot; and &amp;quot;SimiCheck Similarity Threshold&amp;quot;. In &amp;quot;Simicheck Delay&amp;quot;, select a value between 0 and 100 to enable the Plagiarism Checker. In &amp;quot;SimiCheck Similarity Threshold&amp;quot;, select a percentage value to filter the Plagiarism Checker Comparison results. The percentage refers to the percent of same text between two documents. &lt;br /&gt;
&lt;br /&gt;
After the assignment ends and the delay period has passed, you can view the Plagiarism Report. Click the &amp;quot;View review report&amp;quot; icon containing a magnifying glass and two people (in the third row of per-assignment icons). Select &amp;quot;Plagiarism Checker Report&amp;quot; from the select box, and click &amp;quot;Submit&amp;quot;. If there is any plagiarism to report, it will load.&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
In Expertiza there already existed functionality to schedule or queue tasks for the task system. We have hooked into that system by adding a new task type declared as &amp;quot;compare_files_with_simicheck&amp;quot; and then providing the correct date/time configuration. When a task deadline occurs, there is a method that invokes logic based on the task type. Once this task type is detected on a scheduled task, the SimiCheck comparison is initiated.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample(s) ===&lt;br /&gt;
====Scheduled task expires, hook is called====&lt;br /&gt;
The following code was added to app/mailers/delayed_mailer.rb/perform:&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
if (self.deadline_type == &amp;quot;compare_files_with_simicheck&amp;quot;)&lt;br /&gt;
  perform_simicheck_comparisons(self.assignment_id)&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108806</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108806"/>
		<updated>2017-04-30T03:20:12Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Task Triggering */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. The completed code from previous projects did not clearly demonstrate successful integration with SimiCheck from Expertiza, and was not deemed production worthy. Based on this feedback, we started our development from scratch and utilized the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
The majority of the updates are handled in new background tasks. Therefore, there weren't many modifications to existing Expertiza files. The current New Assignment interface has two new configuration parameters, which have also been added to the Assignment model. SimiCheck Delay (hours) and SimiCheck Similarity Threshold (percentage) were added. The Plagiarism Comparison Report was added to the &amp;quot;Review Report&amp;quot; interface's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== Assignment - SimiCheck delay and threshold added ====&lt;br /&gt;
We added &amp;quot;simicheck&amp;quot; and &amp;quot;simicheck_threshold&amp;quot; properties to the the existing Assignment model. &lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck&amp;quot; property accommodates the number of hours to delay the execution of the Plagiarism Checker after the assignment's due date. &amp;quot;simicheck&amp;quot; is -1 if there is no Plagiarism Checker scheduled, and between 0 and 100 (hours) if the assignment is to have a Plagiarism Checker Report.&lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck_threshold&amp;quot; property is a percentage that filters the Plagiarism Checker's Similarity results. The threshold refers to the percentage of text that is the same between two documents.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, the Team IDs, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_SimiCheck.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
The current assignment configuration UI has been modified to contain 2 new select boxes. These select boxes determine how long to delay the Plagiarism Checker after an assignment's due date, and on what similarity percent to filter the Plagiarism Checker Comparison results.  &lt;br /&gt;
&lt;br /&gt;
After the results have been aggregated they can be viewed in a results report page. This report includes the submission names, the responsible teams, the similarity percentage, and a link to view the similarity results. The Plagiarism Checker Report UI looks similar to this:&lt;br /&gt;
&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To view the interface changes, login to Expertiza as an instructor; navigate to Manage... Assignments. Click &amp;quot;New public/private assignment&amp;quot;. The last two fields on the New Assignment page say &amp;quot;SimiCheck  Delay&amp;quot; and &amp;quot;SimiCheck Similarity Threshold&amp;quot;. In &amp;quot;Simicheck Delay&amp;quot;, select a value between 0 and 100 to enable the Plagiarism Checker. In &amp;quot;SimiCheck Similarity Threshold&amp;quot;, select a percentage value to filter the Plagiarism Checker Comparison results. The percentage refers to the percent of same text between two documents. &lt;br /&gt;
&lt;br /&gt;
After the assignment ends and the delay period has passed, you can view the Plagiarism Report. Click the &amp;quot;View review report&amp;quot; icon containing a magnifying glass and two people (in the third row of per-assignment icons). Select &amp;quot;Plagiarism Checker Report&amp;quot; from the select box, and click &amp;quot;Submit&amp;quot;. If there is any plagiarism to report, it will load.&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
In Expertiza there already existed functionality to schedule or queue tasks for the task system. We have hooked into that system by adding a new task type declared as &amp;quot;compare_files_with_simicheck&amp;quot; and then providing the correct date/time configuration. When a task deadline occurs, there is a method that invokes logic based on the task type. Once this task type is detected on a scheduled task, the SimiCheck comparison is initiated.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample(s) ===&lt;br /&gt;
''Coming soon...''&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108804</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108804"/>
		<updated>2017-04-30T03:10:52Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Potential Hurdles */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. The completed code from previous projects did not clearly demonstrate successful integration with SimiCheck from Expertiza, and was not deemed production worthy. Based on this feedback, we started our development from scratch and utilized the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
The majority of the updates are handled in new background tasks. Therefore, there weren't many modifications to existing Expertiza files. The current New Assignment interface has two new configuration parameters, which have also been added to the Assignment model. SimiCheck Delay (hours) and SimiCheck Similarity Threshold (percentage) were added. The Plagiarism Comparison Report was added to the &amp;quot;Review Report&amp;quot; interface's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== Assignment - SimiCheck delay and threshold added ====&lt;br /&gt;
We added &amp;quot;simicheck&amp;quot; and &amp;quot;simicheck_threshold&amp;quot; properties to the the existing Assignment model. &lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck&amp;quot; property accommodates the number of hours to delay the execution of the Plagiarism Checker after the assignment's due date. &amp;quot;simicheck&amp;quot; is -1 if there is no Plagiarism Checker scheduled, and between 0 and 100 (hours) if the assignment is to have a Plagiarism Checker Report.&lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck_threshold&amp;quot; property is a percentage that filters the Plagiarism Checker's Similarity results. The threshold refers to the percentage of text that is the same between two documents.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, the Team IDs, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_SimiCheck.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
The current assignment configuration UI has been modified to contain 2 new select boxes. These select boxes determine how long to delay the Plagiarism Checker after an assignment's due date, and on what similarity percent to filter the Plagiarism Checker Comparison results.  &lt;br /&gt;
&lt;br /&gt;
After the results have been aggregated they can be viewed in a results report page. This report includes the submission names, the responsible teams, the similarity percentage, and a link to view the similarity results. The Plagiarism Checker Report UI looks similar to this:&lt;br /&gt;
&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To view the interface changes, login to Expertiza as an instructor; navigate to Manage... Assignments. Click &amp;quot;New public/private assignment&amp;quot;. The last two fields on the New Assignment page say &amp;quot;SimiCheck  Delay&amp;quot; and &amp;quot;SimiCheck Similarity Threshold&amp;quot;. In &amp;quot;Simicheck Delay&amp;quot;, select a value between 0 and 100 to enable the Plagiarism Checker. In &amp;quot;SimiCheck Similarity Threshold&amp;quot;, select a percentage value to filter the Plagiarism Checker Comparison results. The percentage refers to the percent of same text between two documents. &lt;br /&gt;
&lt;br /&gt;
After the assignment ends and the delay period has passed, you can view the Plagiarism Report. Click the &amp;quot;View review report&amp;quot; icon containing a magnifying glass and two people (in the third row of per-assignment icons). Select &amp;quot;Plagiarism Checker Report&amp;quot; from the select box, and click &amp;quot;Submit&amp;quot;. If there is any plagiarism to report, it will load.&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
The majority of this project is implemented as a background task; we can think of it as a separate application or process apart from Expertiza. Ideally this process will be running in another thread to allow for concurrency. We will be exploring during development different options for handling the task with respect to languages and trigger methodologies. For languages we will be exploring Ruby, Python, Node, and potentially others. From a trigger methodology standpoint we will explore both polling and/or event based triggering.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample(s) ===&lt;br /&gt;
''Coming soon...''&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108803</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108803"/>
		<updated>2017-04-30T03:07:54Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Task Triggering */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. The completed code from previous projects did not clearly demonstrate successful integration with SimiCheck from Expertiza, and was not deemed production worthy. Based on this feedback, we started our development from scratch and utilized the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
The majority of the updates are handled in new background tasks. Therefore, there weren't many modifications to existing Expertiza files. The current New Assignment interface has two new configuration parameters, which have also been added to the Assignment model. SimiCheck Delay (hours) and SimiCheck Similarity Threshold (percentage) were added. The Plagiarism Comparison Report was added to the &amp;quot;Review Report&amp;quot; interface's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== Assignment - SimiCheck delay and threshold added ====&lt;br /&gt;
We added &amp;quot;simicheck&amp;quot; and &amp;quot;simicheck_threshold&amp;quot; properties to the the existing Assignment model. &lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck&amp;quot; property accommodates the number of hours to delay the execution of the Plagiarism Checker after the assignment's due date. &amp;quot;simicheck&amp;quot; is -1 if there is no Plagiarism Checker scheduled, and between 0 and 100 (hours) if the assignment is to have a Plagiarism Checker Report.&lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck_threshold&amp;quot; property is a percentage that filters the Plagiarism Checker's Similarity results. The threshold refers to the percentage of text that is the same between two documents.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, the Team IDs, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_SimiCheck.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
The current assignment configuration UI has been modified to contain 2 new select boxes. These select boxes determine how long to delay the Plagiarism Checker after an assignment's due date, and on what similarity percent to filter the Plagiarism Checker Comparison results.  &lt;br /&gt;
&lt;br /&gt;
After the results have been aggregated they can be viewed in a results report page. This report includes the submission names, the responsible teams, the similarity percentage, and a link to view the similarity results. The Plagiarism Checker Report UI looks similar to this:&lt;br /&gt;
&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To view the interface changes, login to Expertiza as an instructor; navigate to Manage... Assignments. Click &amp;quot;New public/private assignment&amp;quot;. The last two fields on the New Assignment page say &amp;quot;SimiCheck  Delay&amp;quot; and &amp;quot;SimiCheck Similarity Threshold&amp;quot;. In &amp;quot;Simicheck Delay&amp;quot;, select a value between 0 and 100 to enable the Plagiarism Checker. In &amp;quot;SimiCheck Similarity Threshold&amp;quot;, select a percentage value to filter the Plagiarism Checker Comparison results. The percentage refers to the percent of same text between two documents. &lt;br /&gt;
&lt;br /&gt;
After the assignment ends and the delay period has passed, you can view the Plagiarism Report. Click the &amp;quot;View review report&amp;quot; icon containing a magnifying glass and two people (in the third row of per-assignment icons). Select &amp;quot;Plagiarism Checker Report&amp;quot; from the select box, and click &amp;quot;Submit&amp;quot;. If there is any plagiarism to report, it will load.&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
The majority of this project is implemented as a background task; we can think of it as a separate application or process apart from Expertiza. Ideally this process will be running in another thread to allow for concurrency. We will be exploring during development different options for handling the task with respect to languages and trigger methodologies. For languages we will be exploring Ruby, Python, Node, and potentially others. From a trigger methodology standpoint we will explore both polling and/or event based triggering.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample(s) ===&lt;br /&gt;
''Coming soon...''&lt;br /&gt;
&lt;br /&gt;
=== Potential Hurdles ===&lt;br /&gt;
GiHub has rate limits with respect to how many requests we are allowed to make per auth token per hour. According to GitHub's documentation we are allowed 5000 authenticated requests per hour with an additional 60 requests per hour for unauthenticated requests. This documentation can be found [https://developer.github.com/v3/#rate-limiting here].  Due to the fact that this is a background task and immediate results are not required(will likely be an overnight task), we will ensure that if the need arises to exceed 5000 requests per hour that we will delay the subsequent quests until the next hour. This should satisfy the number of checks that need to occur within a reasonable time frame.&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108802</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108802"/>
		<updated>2017-04-30T03:07:03Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* User Interface */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. The completed code from previous projects did not clearly demonstrate successful integration with SimiCheck from Expertiza, and was not deemed production worthy. Based on this feedback, we started our development from scratch and utilized the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
The majority of the updates are handled in new background tasks. Therefore, there weren't many modifications to existing Expertiza files. The current New Assignment interface has two new configuration parameters, which have also been added to the Assignment model. SimiCheck Delay (hours) and SimiCheck Similarity Threshold (percentage) were added. The Plagiarism Comparison Report was added to the &amp;quot;Review Report&amp;quot; interface's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== Assignment - SimiCheck delay and threshold added ====&lt;br /&gt;
We added &amp;quot;simicheck&amp;quot; and &amp;quot;simicheck_threshold&amp;quot; properties to the the existing Assignment model. &lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck&amp;quot; property accommodates the number of hours to delay the execution of the Plagiarism Checker after the assignment's due date. &amp;quot;simicheck&amp;quot; is -1 if there is no Plagiarism Checker scheduled, and between 0 and 100 (hours) if the assignment is to have a Plagiarism Checker Report.&lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck_threshold&amp;quot; property is a percentage that filters the Plagiarism Checker's Similarity results. The threshold refers to the percentage of text that is the same between two documents.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, the Team IDs, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_SimiCheck.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
The current assignment configuration UI has been modified to contain 2 new select boxes. These select boxes determine how long to delay the Plagiarism Checker after an assignment's due date, and on what similarity percent to filter the Plagiarism Checker Comparison results.  &lt;br /&gt;
&lt;br /&gt;
After the results have been aggregated they can be viewed in a results report page. This report includes the submission names, the responsible teams, the similarity percentage, and a link to view the similarity results. The Plagiarism Checker Report UI looks similar to this:&lt;br /&gt;
&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To view the interface changes, login to Expertiza as an instructor; navigate to Manage... Assignments. Click &amp;quot;New public/private assignment&amp;quot;. The last two fields on the New Assignment page say &amp;quot;SimiCheck  Delay&amp;quot; and &amp;quot;SimiCheck Similarity Threshold&amp;quot;. In &amp;quot;Simicheck Delay&amp;quot;, select a value between 0 and 100 to enable the Plagiarism Checker. In &amp;quot;SimiCheck Similarity Threshold&amp;quot;, select a percentage value to filter the Plagiarism Checker Comparison results. The percentage refers to the percent of same text between two documents. &lt;br /&gt;
&lt;br /&gt;
After the assignment ends and the delay period has passed, you can view the Plagiarism Report. Click the &amp;quot;View review report&amp;quot; icon containing a magnifying glass and two people (in the third row of per-assignment icons). Select &amp;quot;Plagiarism Checker Report&amp;quot; from the select box, and click &amp;quot;Submit&amp;quot;. If there is any plagiarism to report, it will load.&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
The majority of this project is implemented as a background task and as such we can think of it as a separate application or process apart from Expertiza. Ideally this process will be running in another thread to allow for concurrency. We will be exploring during development different options for handling the task with respect to languages and trigger methodologies. For languages we will be exploring Ruby, Python, Node, and potentially others. From a trigger methodology standpoint we will explore both polling and/or event based triggering.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample(s) ===&lt;br /&gt;
''Coming soon...''&lt;br /&gt;
&lt;br /&gt;
=== Potential Hurdles ===&lt;br /&gt;
GiHub has rate limits with respect to how many requests we are allowed to make per auth token per hour. According to GitHub's documentation we are allowed 5000 authenticated requests per hour with an additional 60 requests per hour for unauthenticated requests. This documentation can be found [https://developer.github.com/v3/#rate-limiting here].  Due to the fact that this is a background task and immediate results are not required(will likely be an overnight task), we will ensure that if the need arises to exceed 5000 requests per hour that we will delay the subsequent quests until the next hour. This should satisfy the number of checks that need to occur within a reasonable time frame.&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108801</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108801"/>
		<updated>2017-04-30T02:59:14Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* PlagiarismCheckerComparison */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. The completed code from previous projects did not clearly demonstrate successful integration with SimiCheck from Expertiza, and was not deemed production worthy. Based on this feedback, we started our development from scratch and utilized the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
The majority of the updates are handled in new background tasks. Therefore, there weren't many modifications to existing Expertiza files. The current New Assignment interface has two new configuration parameters, which have also been added to the Assignment model. SimiCheck Delay (hours) and SimiCheck Similarity Threshold (percentage) were added. The Plagiarism Comparison Report was added to the &amp;quot;Review Report&amp;quot; interface's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== Assignment - SimiCheck delay and threshold added ====&lt;br /&gt;
We added &amp;quot;simicheck&amp;quot; and &amp;quot;simicheck_threshold&amp;quot; properties to the the existing Assignment model. &lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck&amp;quot; property accommodates the number of hours to delay the execution of the Plagiarism Checker after the assignment's due date. &amp;quot;simicheck&amp;quot; is -1 if there is no Plagiarism Checker scheduled, and between 0 and 100 (hours) if the assignment is to have a Plagiarism Checker Report.&lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck_threshold&amp;quot; property is a percentage that filters the Plagiarism Checker's Similarity results. The threshold refers to the percentage of text that is the same between two documents.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, the Team IDs, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_SimiCheck.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
The current assignment configuration UI will be modified to contain another field where an integer can be selected. This will configure how long to wait after an assignment's due date before running the comparison task. &lt;br /&gt;
&lt;br /&gt;
After the results have been aggregated they will be able to be viewed via a results report page. This report will include the submissions, their corresponding teams, and the similarity results. The Plagiarism Checker Report UI looks similar to this:&lt;br /&gt;
&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To view the interface changes, login to Expertiza as an instructor; navigate to Manage... Assignments. Click &amp;quot;New public/private assignment&amp;quot;. The last field on the New Assignment page says &amp;quot;SimiCheck Hour Delay&amp;quot;. Enter a value between 0 and 100 to enable the Plagiarism Checker. &lt;br /&gt;
&lt;br /&gt;
After the assignment ends and the delay period has passed, you can view the Plagiarism Report. Click the &amp;quot;View review report&amp;quot; icon containing a magnifying glass and two people (in the third row of per-assignment icons). Select &amp;quot;Plagiarism Checker Report&amp;quot; from the select box, and click &amp;quot;Submit&amp;quot;. If there is any plagiarism to report, it will load.&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
The majority of this project is implemented as a background task and as such we can think of it as a separate application or process apart from Expertiza. Ideally this process will be running in another thread to allow for concurrency. We will be exploring during development different options for handling the task with respect to languages and trigger methodologies. For languages we will be exploring Ruby, Python, Node, and potentially others. From a trigger methodology standpoint we will explore both polling and/or event based triggering.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample(s) ===&lt;br /&gt;
''Coming soon...''&lt;br /&gt;
&lt;br /&gt;
=== Potential Hurdles ===&lt;br /&gt;
GiHub has rate limits with respect to how many requests we are allowed to make per auth token per hour. According to GitHub's documentation we are allowed 5000 authenticated requests per hour with an additional 60 requests per hour for unauthenticated requests. This documentation can be found [https://developer.github.com/v3/#rate-limiting here].  Due to the fact that this is a background task and immediate results are not required(will likely be an overnight task), we will ensure that if the need arises to exceed 5000 requests per hour that we will delay the subsequent quests until the next hour. This should satisfy the number of checks that need to occur within a reasonable time frame.&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108800</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108800"/>
		<updated>2017-04-30T02:57:52Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Assignment - SimiCheck delay added */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. The completed code from previous projects did not clearly demonstrate successful integration with SimiCheck from Expertiza, and was not deemed production worthy. Based on this feedback, we started our development from scratch and utilized the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
The majority of the updates are handled in new background tasks. Therefore, there weren't many modifications to existing Expertiza files. The current New Assignment interface has two new configuration parameters, which have also been added to the Assignment model. SimiCheck Delay (hours) and SimiCheck Similarity Threshold (percentage) were added. The Plagiarism Comparison Report was added to the &amp;quot;Review Report&amp;quot; interface's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== Assignment - SimiCheck delay and threshold added ====&lt;br /&gt;
We added &amp;quot;simicheck&amp;quot; and &amp;quot;simicheck_threshold&amp;quot; properties to the the existing Assignment model. &lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck&amp;quot; property accommodates the number of hours to delay the execution of the Plagiarism Checker after the assignment's due date. &amp;quot;simicheck&amp;quot; is -1 if there is no Plagiarism Checker scheduled, and between 0 and 100 (hours) if the assignment is to have a Plagiarism Checker Report.&lt;br /&gt;
&lt;br /&gt;
The &amp;quot;simicheck_threshold&amp;quot; property is a percentage that filters the Plagiarism Checker's Similarity results. The threshold refers to the percentage of text that is the same between two documents.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_SimiCheck.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
The current assignment configuration UI will be modified to contain another field where an integer can be selected. This will configure how long to wait after an assignment's due date before running the comparison task. &lt;br /&gt;
&lt;br /&gt;
After the results have been aggregated they will be able to be viewed via a results report page. This report will include the submissions, their corresponding teams, and the similarity results. The Plagiarism Checker Report UI looks similar to this:&lt;br /&gt;
&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To view the interface changes, login to Expertiza as an instructor; navigate to Manage... Assignments. Click &amp;quot;New public/private assignment&amp;quot;. The last field on the New Assignment page says &amp;quot;SimiCheck Hour Delay&amp;quot;. Enter a value between 0 and 100 to enable the Plagiarism Checker. &lt;br /&gt;
&lt;br /&gt;
After the assignment ends and the delay period has passed, you can view the Plagiarism Report. Click the &amp;quot;View review report&amp;quot; icon containing a magnifying glass and two people (in the third row of per-assignment icons). Select &amp;quot;Plagiarism Checker Report&amp;quot; from the select box, and click &amp;quot;Submit&amp;quot;. If there is any plagiarism to report, it will load.&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
The majority of this project is implemented as a background task and as such we can think of it as a separate application or process apart from Expertiza. Ideally this process will be running in another thread to allow for concurrency. We will be exploring during development different options for handling the task with respect to languages and trigger methodologies. For languages we will be exploring Ruby, Python, Node, and potentially others. From a trigger methodology standpoint we will explore both polling and/or event based triggering.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample(s) ===&lt;br /&gt;
''Coming soon...''&lt;br /&gt;
&lt;br /&gt;
=== Potential Hurdles ===&lt;br /&gt;
GiHub has rate limits with respect to how many requests we are allowed to make per auth token per hour. According to GitHub's documentation we are allowed 5000 authenticated requests per hour with an additional 60 requests per hour for unauthenticated requests. This documentation can be found [https://developer.github.com/v3/#rate-limiting here].  Due to the fact that this is a background task and immediate results are not required(will likely be an overnight task), we will ensure that if the need arises to exceed 5000 requests per hour that we will delay the subsequent quests until the next hour. This should satisfy the number of checks that need to occur within a reasonable time frame.&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108799</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108799"/>
		<updated>2017-04-30T02:53:05Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Expertiza Modifications */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. The completed code from previous projects did not clearly demonstrate successful integration with SimiCheck from Expertiza, and was not deemed production worthy. Based on this feedback, we started our development from scratch and utilized the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
The majority of the updates are handled in new background tasks. Therefore, there weren't many modifications to existing Expertiza files. The current New Assignment interface has two new configuration parameters, which have also been added to the Assignment model. SimiCheck Delay (hours) and SimiCheck Similarity Threshold (percentage) were added. The Plagiarism Comparison Report was added to the &amp;quot;Review Report&amp;quot; interface's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== Assignment - SimiCheck delay added ====&lt;br /&gt;
We added a &amp;quot;simicheck&amp;quot; property to the the existing Assignment model. This willl accommodate the number of hours to delay the execution of the Plagiarism Checker after the assignment's due date. &amp;quot;Simicheck&amp;quot; will be -1 if there is no Plagiarism Checker scheduled, and between 0 and 100 (hours) if the assignment is to have a Plagiarism Checker Report.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_SimiCheck.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
The current assignment configuration UI will be modified to contain another field where an integer can be selected. This will configure how long to wait after an assignment's due date before running the comparison task. &lt;br /&gt;
&lt;br /&gt;
After the results have been aggregated they will be able to be viewed via a results report page. This report will include the submissions, their corresponding teams, and the similarity results. The Plagiarism Checker Report UI looks similar to this:&lt;br /&gt;
&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To view the interface changes, login to Expertiza as an instructor; navigate to Manage... Assignments. Click &amp;quot;New public/private assignment&amp;quot;. The last field on the New Assignment page says &amp;quot;SimiCheck Hour Delay&amp;quot;. Enter a value between 0 and 100 to enable the Plagiarism Checker. &lt;br /&gt;
&lt;br /&gt;
After the assignment ends and the delay period has passed, you can view the Plagiarism Report. Click the &amp;quot;View review report&amp;quot; icon containing a magnifying glass and two people (in the third row of per-assignment icons). Select &amp;quot;Plagiarism Checker Report&amp;quot; from the select box, and click &amp;quot;Submit&amp;quot;. If there is any plagiarism to report, it will load.&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
The majority of this project is implemented as a background task and as such we can think of it as a separate application or process apart from Expertiza. Ideally this process will be running in another thread to allow for concurrency. We will be exploring during development different options for handling the task with respect to languages and trigger methodologies. For languages we will be exploring Ruby, Python, Node, and potentially others. From a trigger methodology standpoint we will explore both polling and/or event based triggering.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample(s) ===&lt;br /&gt;
''Coming soon...''&lt;br /&gt;
&lt;br /&gt;
=== Potential Hurdles ===&lt;br /&gt;
GiHub has rate limits with respect to how many requests we are allowed to make per auth token per hour. According to GitHub's documentation we are allowed 5000 authenticated requests per hour with an additional 60 requests per hour for unauthenticated requests. This documentation can be found [https://developer.github.com/v3/#rate-limiting here].  Due to the fact that this is a background task and immediate results are not required(will likely be an overnight task), we will ensure that if the need arises to exceed 5000 requests per hour that we will delay the subsequent quests until the next hour. This should satisfy the number of checks that need to occur within a reasonable time frame.&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108798</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108798"/>
		<updated>2017-04-30T02:51:17Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Background */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. The completed code from previous projects did not clearly demonstrate successful integration with SimiCheck from Expertiza, and was not deemed production worthy. Based on this feedback, we started our development from scratch and utilized the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
The majority of the updates are handled in new background tasks. Therefore, there weren't many modifications to existing Expertiza files. The current new Assignment interface has two new configuration parameters, which have also been added to the Assignment model. SimiCheck Delay (hours) and SimiCheck Similarity Threshold (percentage) were added. The Plagiarism Comparison Report was added to the &amp;quot;Review Report&amp;quot; interface's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== Assignment - SimiCheck delay added ====&lt;br /&gt;
We added a &amp;quot;simicheck&amp;quot; property to the the existing Assignment model. This willl accommodate the number of hours to delay the execution of the Plagiarism Checker after the assignment's due date. &amp;quot;Simicheck&amp;quot; will be -1 if there is no Plagiarism Checker scheduled, and between 0 and 100 (hours) if the assignment is to have a Plagiarism Checker Report.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_SimiCheck.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
The current assignment configuration UI will be modified to contain another field where an integer can be selected. This will configure how long to wait after an assignment's due date before running the comparison task. &lt;br /&gt;
&lt;br /&gt;
After the results have been aggregated they will be able to be viewed via a results report page. This report will include the submissions, their corresponding teams, and the similarity results. The Plagiarism Checker Report UI looks similar to this:&lt;br /&gt;
&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To view the interface changes, login to Expertiza as an instructor; navigate to Manage... Assignments. Click &amp;quot;New public/private assignment&amp;quot;. The last field on the New Assignment page says &amp;quot;SimiCheck Hour Delay&amp;quot;. Enter a value between 0 and 100 to enable the Plagiarism Checker. &lt;br /&gt;
&lt;br /&gt;
After the assignment ends and the delay period has passed, you can view the Plagiarism Report. Click the &amp;quot;View review report&amp;quot; icon containing a magnifying glass and two people (in the third row of per-assignment icons). Select &amp;quot;Plagiarism Checker Report&amp;quot; from the select box, and click &amp;quot;Submit&amp;quot;. If there is any plagiarism to report, it will load.&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
The majority of this project is implemented as a background task and as such we can think of it as a separate application or process apart from Expertiza. Ideally this process will be running in another thread to allow for concurrency. We will be exploring during development different options for handling the task with respect to languages and trigger methodologies. For languages we will be exploring Ruby, Python, Node, and potentially others. From a trigger methodology standpoint we will explore both polling and/or event based triggering.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample(s) ===&lt;br /&gt;
''Coming soon...''&lt;br /&gt;
&lt;br /&gt;
=== Potential Hurdles ===&lt;br /&gt;
GiHub has rate limits with respect to how many requests we are allowed to make per auth token per hour. According to GitHub's documentation we are allowed 5000 authenticated requests per hour with an additional 60 requests per hour for unauthenticated requests. This documentation can be found [https://developer.github.com/v3/#rate-limiting here].  Due to the fact that this is a background task and immediate results are not required(will likely be an overnight task), we will ensure that if the need arises to exceed 5000 requests per hour that we will delay the subsequent quests until the next hour. This should satisfy the number of checks that need to occur within a reasonable time frame.&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108797</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108797"/>
		<updated>2017-04-30T02:50:21Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Background */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. The completed code from previous projects did not clearly demonstrate successful integration with SimiCheck from Expertiza, and were not deemed production worthy. Based on this feedback, we started our development from scratch and utilized the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
The majority of the updates are handled in new background tasks. Therefore, there weren't many modifications to existing Expertiza files. The current new Assignment interface has two new configuration parameters, which have also been added to the Assignment model. SimiCheck Delay (hours) and SimiCheck Similarity Threshold (percentage) were added. The Plagiarism Comparison Report was added to the &amp;quot;Review Report&amp;quot; interface's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== Assignment - SimiCheck delay added ====&lt;br /&gt;
We added a &amp;quot;simicheck&amp;quot; property to the the existing Assignment model. This willl accommodate the number of hours to delay the execution of the Plagiarism Checker after the assignment's due date. &amp;quot;Simicheck&amp;quot; will be -1 if there is no Plagiarism Checker scheduled, and between 0 and 100 (hours) if the assignment is to have a Plagiarism Checker Report.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_SimiCheck.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
The current assignment configuration UI will be modified to contain another field where an integer can be selected. This will configure how long to wait after an assignment's due date before running the comparison task. &lt;br /&gt;
&lt;br /&gt;
After the results have been aggregated they will be able to be viewed via a results report page. This report will include the submissions, their corresponding teams, and the similarity results. The Plagiarism Checker Report UI looks similar to this:&lt;br /&gt;
&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To view the interface changes, login to Expertiza as an instructor; navigate to Manage... Assignments. Click &amp;quot;New public/private assignment&amp;quot;. The last field on the New Assignment page says &amp;quot;SimiCheck Hour Delay&amp;quot;. Enter a value between 0 and 100 to enable the Plagiarism Checker. &lt;br /&gt;
&lt;br /&gt;
After the assignment ends and the delay period has passed, you can view the Plagiarism Report. Click the &amp;quot;View review report&amp;quot; icon containing a magnifying glass and two people (in the third row of per-assignment icons). Select &amp;quot;Plagiarism Checker Report&amp;quot; from the select box, and click &amp;quot;Submit&amp;quot;. If there is any plagiarism to report, it will load.&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
The majority of this project is implemented as a background task and as such we can think of it as a separate application or process apart from Expertiza. Ideally this process will be running in another thread to allow for concurrency. We will be exploring during development different options for handling the task with respect to languages and trigger methodologies. For languages we will be exploring Ruby, Python, Node, and potentially others. From a trigger methodology standpoint we will explore both polling and/or event based triggering.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample(s) ===&lt;br /&gt;
''Coming soon...''&lt;br /&gt;
&lt;br /&gt;
=== Potential Hurdles ===&lt;br /&gt;
GiHub has rate limits with respect to how many requests we are allowed to make per auth token per hour. According to GitHub's documentation we are allowed 5000 authenticated requests per hour with an additional 60 requests per hour for unauthenticated requests. This documentation can be found [https://developer.github.com/v3/#rate-limiting here].  Due to the fact that this is a background task and immediate results are not required(will likely be an overnight task), we will ensure that if the need arises to exceed 5000 requests per hour that we will delay the subsequent quests until the next hour. This should satisfy the number of checks that need to occur within a reasonable time frame.&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108796</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108796"/>
		<updated>2017-04-30T02:46:13Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Expertiza Modifications */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. However, the outcomes from these projects did not clearly demonstrate successful integration with SimiCheck from Expertiza and were not deemed production worthy. As a result, part of our project involves researching the previous submission and learning from it. In addition, based on this feedback so far we have decided to start our development from scratch and utilize the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
The majority of the updates are handled in new background tasks. Therefore, there weren't many modifications to existing Expertiza files. The current new Assignment interface has two new configuration parameters, which have also been added to the Assignment model. SimiCheck Delay (hours) and SimiCheck Similarity Threshold (percentage) were added. The Plagiarism Comparison Report was added to the &amp;quot;Review Report&amp;quot; interface's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== Assignment - SimiCheck delay added ====&lt;br /&gt;
We added a &amp;quot;simicheck&amp;quot; property to the the existing Assignment model. This willl accommodate the number of hours to delay the execution of the Plagiarism Checker after the assignment's due date. &amp;quot;Simicheck&amp;quot; will be -1 if there is no Plagiarism Checker scheduled, and between 0 and 100 (hours) if the assignment is to have a Plagiarism Checker Report.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_SimiCheck.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
The current assignment configuration UI will be modified to contain another field where an integer can be selected. This will configure how long to wait after an assignment's due date before running the comparison task. &lt;br /&gt;
&lt;br /&gt;
After the results have been aggregated they will be able to be viewed via a results report page. This report will include the submissions, their corresponding teams, and the similarity results. The Plagiarism Checker Report UI looks similar to this:&lt;br /&gt;
&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To view the interface changes, login to Expertiza as an instructor; navigate to Manage... Assignments. Click &amp;quot;New public/private assignment&amp;quot;. The last field on the New Assignment page says &amp;quot;SimiCheck Hour Delay&amp;quot;. Enter a value between 0 and 100 to enable the Plagiarism Checker. &lt;br /&gt;
&lt;br /&gt;
After the assignment ends and the delay period has passed, you can view the Plagiarism Report. Click the &amp;quot;View review report&amp;quot; icon containing a magnifying glass and two people (in the third row of per-assignment icons). Select &amp;quot;Plagiarism Checker Report&amp;quot; from the select box, and click &amp;quot;Submit&amp;quot;. If there is any plagiarism to report, it will load.&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
The majority of this project is implemented as a background task and as such we can think of it as a separate application or process apart from Expertiza. Ideally this process will be running in another thread to allow for concurrency. We will be exploring during development different options for handling the task with respect to languages and trigger methodologies. For languages we will be exploring Ruby, Python, Node, and potentially others. From a trigger methodology standpoint we will explore both polling and/or event based triggering.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample(s) ===&lt;br /&gt;
''Coming soon...''&lt;br /&gt;
&lt;br /&gt;
=== Potential Hurdles ===&lt;br /&gt;
GiHub has rate limits with respect to how many requests we are allowed to make per auth token per hour. According to GitHub's documentation we are allowed 5000 authenticated requests per hour with an additional 60 requests per hour for unauthenticated requests. This documentation can be found [https://developer.github.com/v3/#rate-limiting here].  Due to the fact that this is a background task and immediate results are not required(will likely be an overnight task), we will ensure that if the need arises to exceed 5000 requests per hour that we will delay the subsequent quests until the next hour. This should satisfy the number of checks that need to occur within a reasonable time frame.&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108795</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108795"/>
		<updated>2017-04-30T02:41:45Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Diagram */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. However, the outcomes from these projects did not clearly demonstrate successful integration with SimiCheck from Expertiza and were not deemed production worthy. As a result, part of our project involves researching the previous submission and learning from it. In addition, based on this feedback so far we have decided to start our development from scratch and utilize the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
Due to the fact that the majority of the updates will be a handled in a new background task, there won't be many modifications to files in Expertiza that currently exist. The current assignment configuration view will need to be expanded to add a configuration parameter and the Assignment model will need to be expanded to include a SimiCheck Delay parameter. The Plagiarism Comparison Report will be added to the &amp;quot;Review Report&amp;quot; ui's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== Assignment - SimiCheck delay added ====&lt;br /&gt;
We added a &amp;quot;simicheck&amp;quot; property to the the existing Assignment model. This willl accommodate the number of hours to delay the execution of the Plagiarism Checker after the assignment's due date. &amp;quot;Simicheck&amp;quot; will be -1 if there is no Plagiarism Checker scheduled, and between 0 and 100 (hours) if the assignment is to have a Plagiarism Checker Report.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_SimiCheck.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
The current assignment configuration UI will be modified to contain another field where an integer can be selected. This will configure how long to wait after an assignment's due date before running the comparison task. &lt;br /&gt;
&lt;br /&gt;
After the results have been aggregated they will be able to be viewed via a results report page. This report will include the submissions, their corresponding teams, and the similarity results. The Plagiarism Checker Report UI looks similar to this:&lt;br /&gt;
&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To view the interface changes, login to Expertiza as an instructor; navigate to Manage... Assignments. Click &amp;quot;New public/private assignment&amp;quot;. The last field on the New Assignment page says &amp;quot;SimiCheck Hour Delay&amp;quot;. Enter a value between 0 and 100 to enable the Plagiarism Checker. &lt;br /&gt;
&lt;br /&gt;
After the assignment ends and the delay period has passed, you can view the Plagiarism Report. Click the &amp;quot;View review report&amp;quot; icon containing a magnifying glass and two people (in the third row of per-assignment icons). Select &amp;quot;Plagiarism Checker Report&amp;quot; from the select box, and click &amp;quot;Submit&amp;quot;. If there is any plagiarism to report, it will load.&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
The majority of this project is implemented as a background task and as such we can think of it as a separate application or process apart from Expertiza. Ideally this process will be running in another thread to allow for concurrency. We will be exploring during development different options for handling the task with respect to languages and trigger methodologies. For languages we will be exploring Ruby, Python, Node, and potentially others. From a trigger methodology standpoint we will explore both polling and/or event based triggering.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample(s) ===&lt;br /&gt;
''Coming soon...''&lt;br /&gt;
&lt;br /&gt;
=== Potential Hurdles ===&lt;br /&gt;
GiHub has rate limits with respect to how many requests we are allowed to make per auth token per hour. According to GitHub's documentation we are allowed 5000 authenticated requests per hour with an additional 60 requests per hour for unauthenticated requests. This documentation can be found [https://developer.github.com/v3/#rate-limiting here].  Due to the fact that this is a background task and immediate results are not required(will likely be an overnight task), we will ensure that if the need arises to exceed 5000 requests per hour that we will delay the subsequent quests until the next hour. This should satisfy the number of checks that need to occur within a reasonable time frame.&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=File:Simicheck_API_-_SimiCheck.png&amp;diff=108794</id>
		<title>File:Simicheck API - SimiCheck.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=File:Simicheck_API_-_SimiCheck.png&amp;diff=108794"/>
		<updated>2017-04-30T02:40:48Z</updated>

		<summary type="html">&lt;p&gt;Eleill: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108774</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108774"/>
		<updated>2017-04-29T20:35:36Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* User Interface */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. However, the outcomes from these projects did not clearly demonstrate successful integration with SimiCheck from Expertiza and were not deemed production worthy. As a result, part of our project involves researching the previous submission and learning from it. In addition, based on this feedback so far we have decided to start our development from scratch and utilize the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
Due to the fact that the majority of the updates will be a handled in a new background task, there won't be many modifications to files in Expertiza that currently exist. The current assignment configuration view will need to be expanded to add a configuration parameter and the Assignment model will need to be expanded to include a SimiCheck Delay parameter. The Plagiarism Comparison Report will be added to the &amp;quot;Review Report&amp;quot; ui's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== Assignment - SimiCheck delay added ====&lt;br /&gt;
We added a &amp;quot;simicheck&amp;quot; property to the the existing Assignment model. This willl accommodate the number of hours to delay the execution of the Plagiarism Checker after the assignment's due date. &amp;quot;Simicheck&amp;quot; will be -1 if there is no Plagiarism Checker scheduled, and between 0 and 100 (hours) if the assignment is to have a Plagiarism Checker Report.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_Page_1.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
The current assignment configuration UI will be modified to contain another field where an integer can be selected. This will configure how long to wait after an assignment's due date before running the comparison task. &lt;br /&gt;
&lt;br /&gt;
After the results have been aggregated they will be able to be viewed via a results report page. This report will include the submissions, their corresponding teams, and the similarity results. The Plagiarism Checker Report UI looks similar to this:&lt;br /&gt;
&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To view the interface changes, login to Expertiza as an instructor; navigate to Manage... Assignments. Click &amp;quot;New public/private assignment&amp;quot;. The last field on the New Assignment page says &amp;quot;SimiCheck Hour Delay&amp;quot;. Enter a value between 0 and 100 to enable the Plagiarism Checker. &lt;br /&gt;
&lt;br /&gt;
After the assignment ends and the delay period has passed, you can view the Plagiarism Report. Click the &amp;quot;View review report&amp;quot; icon containing a magnifying glass and two people (in the third row of per-assignment icons). Select &amp;quot;Plagiarism Checker Report&amp;quot; from the select box, and click &amp;quot;Submit&amp;quot;. If there is any plagiarism to report, it will load.&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
The majority of this project is implemented as a background task and as such we can think of it as a separate application or process apart from Expertiza. Ideally this process will be running in another thread to allow for concurrency. We will be exploring during development different options for handling the task with respect to languages and trigger methodologies. For languages we will be exploring Ruby, Python, Node, and potentially others. From a trigger methodology standpoint we will explore both polling and/or event based triggering.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample(s) ===&lt;br /&gt;
''Coming soon...''&lt;br /&gt;
&lt;br /&gt;
=== Potential Hurdles ===&lt;br /&gt;
GiHub has rate limits with respect to how many requests we are allowed to make per auth token per hour. According to GitHub's documentation we are allowed 5000 authenticated requests per hour with an additional 60 requests per hour for unauthenticated requests. This documentation can be found [https://developer.github.com/v3/#rate-limiting here].  Due to the fact that this is a background task and immediate results are not required(will likely be an overnight task), we will ensure that if the need arises to exceed 5000 requests per hour that we will delay the subsequent quests until the next hour. This should satisfy the number of checks that need to occur within a reasonable time frame.&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108773</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108773"/>
		<updated>2017-04-29T20:35:15Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* User Interface */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. However, the outcomes from these projects did not clearly demonstrate successful integration with SimiCheck from Expertiza and were not deemed production worthy. As a result, part of our project involves researching the previous submission and learning from it. In addition, based on this feedback so far we have decided to start our development from scratch and utilize the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
Due to the fact that the majority of the updates will be a handled in a new background task, there won't be many modifications to files in Expertiza that currently exist. The current assignment configuration view will need to be expanded to add a configuration parameter and the Assignment model will need to be expanded to include a SimiCheck Delay parameter. The Plagiarism Comparison Report will be added to the &amp;quot;Review Report&amp;quot; ui's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== Assignment - SimiCheck delay added ====&lt;br /&gt;
We added a &amp;quot;simicheck&amp;quot; property to the the existing Assignment model. This willl accommodate the number of hours to delay the execution of the Plagiarism Checker after the assignment's due date. &amp;quot;Simicheck&amp;quot; will be -1 if there is no Plagiarism Checker scheduled, and between 0 and 100 (hours) if the assignment is to have a Plagiarism Checker Report.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_Page_1.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
The current assignment configuration UI will be modified to contain another field where an integer can be selected. This will configure how long to wait after an assignment's due date before running the comparison task. &lt;br /&gt;
&lt;br /&gt;
After the results have been aggregated they will be able to be viewed via a results report page. This report will include the submissions, their corresponding teams, and the similarity results. The Plagiarism Checker Report UI looks similar to this:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
To view the interface changes, login to Expertiza as an instructor; navigate to Manage... Assignments. Click &amp;quot;New public/private assignment&amp;quot;. The last field on the New Assignment page says &amp;quot;SimiCheck Hour Delay&amp;quot;. Enter a value between 0 and 100 to enable the Plagiarism Checker. &lt;br /&gt;
&lt;br /&gt;
After the assignment ends and the delay period has passed, you can view the Plagiarism Report. Click the &amp;quot;View review report&amp;quot; icon containing a magnifying glass and two people (in the third row of per-assignment icons). Select &amp;quot;Plagiarism Checker Report&amp;quot; from the select box, and click &amp;quot;Submit&amp;quot;. If there is any plagiarism to report, it will load.&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
The majority of this project is implemented as a background task and as such we can think of it as a separate application or process apart from Expertiza. Ideally this process will be running in another thread to allow for concurrency. We will be exploring during development different options for handling the task with respect to languages and trigger methodologies. For languages we will be exploring Ruby, Python, Node, and potentially others. From a trigger methodology standpoint we will explore both polling and/or event based triggering.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample(s) ===&lt;br /&gt;
''Coming soon...''&lt;br /&gt;
&lt;br /&gt;
=== Potential Hurdles ===&lt;br /&gt;
GiHub has rate limits with respect to how many requests we are allowed to make per auth token per hour. According to GitHub's documentation we are allowed 5000 authenticated requests per hour with an additional 60 requests per hour for unauthenticated requests. This documentation can be found [https://developer.github.com/v3/#rate-limiting here].  Due to the fact that this is a background task and immediate results are not required(will likely be an overnight task), we will ensure that if the need arises to exceed 5000 requests per hour that we will delay the subsequent quests until the next hour. This should satisfy the number of checks that need to occur within a reasonable time frame.&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108772</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108772"/>
		<updated>2017-04-29T20:34:46Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Expertiza Modifications */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. However, the outcomes from these projects did not clearly demonstrate successful integration with SimiCheck from Expertiza and were not deemed production worthy. As a result, part of our project involves researching the previous submission and learning from it. In addition, based on this feedback so far we have decided to start our development from scratch and utilize the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
Due to the fact that the majority of the updates will be a handled in a new background task, there won't be many modifications to files in Expertiza that currently exist. The current assignment configuration view will need to be expanded to add a configuration parameter and the Assignment model will need to be expanded to include a SimiCheck Delay parameter. The Plagiarism Comparison Report will be added to the &amp;quot;Review Report&amp;quot; ui's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== Assignment - SimiCheck delay added ====&lt;br /&gt;
We added a &amp;quot;simicheck&amp;quot; property to the the existing Assignment model. This willl accommodate the number of hours to delay the execution of the Plagiarism Checker after the assignment's due date. &amp;quot;Simicheck&amp;quot; will be -1 if there is no Plagiarism Checker scheduled, and between 0 and 100 (hours) if the assignment is to have a Plagiarism Checker Report.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_Page_1.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
The current assignment configuration UI will be modified to contain another field where an integer can be selected. This will configure how long to wait after an assignment's due date before running the comparison task. &lt;br /&gt;
&lt;br /&gt;
After the results have been aggregated they will be able to be viewed via a results report page. This report will include the submissions, their corresponding teams, and the similarity results. The Plagiarism Checker Report UI looks similar to this:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
The majority of this project is implemented as a background task and as such we can think of it as a separate application or process apart from Expertiza. Ideally this process will be running in another thread to allow for concurrency. We will be exploring during development different options for handling the task with respect to languages and trigger methodologies. For languages we will be exploring Ruby, Python, Node, and potentially others. From a trigger methodology standpoint we will explore both polling and/or event based triggering.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample(s) ===&lt;br /&gt;
''Coming soon...''&lt;br /&gt;
&lt;br /&gt;
=== Potential Hurdles ===&lt;br /&gt;
GiHub has rate limits with respect to how many requests we are allowed to make per auth token per hour. According to GitHub's documentation we are allowed 5000 authenticated requests per hour with an additional 60 requests per hour for unauthenticated requests. This documentation can be found [https://developer.github.com/v3/#rate-limiting here].  Due to the fact that this is a background task and immediate results are not required(will likely be an overnight task), we will ensure that if the need arises to exceed 5000 requests per hour that we will delay the subsequent quests until the next hour. This should satisfy the number of checks that need to occur within a reasonable time frame.&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108771</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108771"/>
		<updated>2017-04-29T20:34:07Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* User Interface */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. However, the outcomes from these projects did not clearly demonstrate successful integration with SimiCheck from Expertiza and were not deemed production worthy. As a result, part of our project involves researching the previous submission and learning from it. In addition, based on this feedback so far we have decided to start our development from scratch and utilize the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
Due to the fact that the majority of the updates will be a handled in a new background task, there won't be many modifications to files in Expertiza that currently exist. The current assignment configuration view will need to be expanded to add a configuration parameter and the Assignment model will need to be expanded to include a SimiCheck Delay parameter. The Plagiarism Comparison Report will be added to the &amp;quot;Review Report&amp;quot; ui's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
To view the interface changes, login to Expertiza as an instructor; navigate to Manage... Assignments. Click &amp;quot;New public/private assignment&amp;quot;. The last field on the New Assignment page says &amp;quot;SimiCheck Hour Delay&amp;quot;. Enter a value between 0 and 100 to enable the Plagiarism Checker. &lt;br /&gt;
&lt;br /&gt;
After the assignment ends and the delay period has passed, you can view the Plagiarism Report. Click the &amp;quot;View review report&amp;quot; icon containing a magnifying glass and two people (in the third row of per-assignment icons). Select &amp;quot;Plagiarism Checker Report&amp;quot; from the select box, and click &amp;quot;Submit&amp;quot;. If there is any plagiarism to report, it will load.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== Assignment - SimiCheck delay added ====&lt;br /&gt;
We added a &amp;quot;simicheck&amp;quot; property to the the existing Assignment model. This willl accommodate the number of hours to delay the execution of the Plagiarism Checker after the assignment's due date. &amp;quot;Simicheck&amp;quot; will be -1 if there is no Plagiarism Checker scheduled, and between 0 and 100 (hours) if the assignment is to have a Plagiarism Checker Report.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_Page_1.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
The current assignment configuration UI will be modified to contain another field where an integer can be selected. This will configure how long to wait after an assignment's due date before running the comparison task. &lt;br /&gt;
&lt;br /&gt;
After the results have been aggregated they will be able to be viewed via a results report page. This report will include the submissions, their corresponding teams, and the similarity results. The Plagiarism Checker Report UI looks similar to this:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
The majority of this project is implemented as a background task and as such we can think of it as a separate application or process apart from Expertiza. Ideally this process will be running in another thread to allow for concurrency. We will be exploring during development different options for handling the task with respect to languages and trigger methodologies. For languages we will be exploring Ruby, Python, Node, and potentially others. From a trigger methodology standpoint we will explore both polling and/or event based triggering.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample(s) ===&lt;br /&gt;
''Coming soon...''&lt;br /&gt;
&lt;br /&gt;
=== Potential Hurdles ===&lt;br /&gt;
GiHub has rate limits with respect to how many requests we are allowed to make per auth token per hour. According to GitHub's documentation we are allowed 5000 authenticated requests per hour with an additional 60 requests per hour for unauthenticated requests. This documentation can be found [https://developer.github.com/v3/#rate-limiting here].  Due to the fact that this is a background task and immediate results are not required(will likely be an overnight task), we will ensure that if the need arises to exceed 5000 requests per hour that we will delay the subsequent quests until the next hour. This should satisfy the number of checks that need to occur within a reasonable time frame.&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108769</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108769"/>
		<updated>2017-04-29T20:31:27Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Assignment */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. However, the outcomes from these projects did not clearly demonstrate successful integration with SimiCheck from Expertiza and were not deemed production worthy. As a result, part of our project involves researching the previous submission and learning from it. In addition, based on this feedback so far we have decided to start our development from scratch and utilize the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
Due to the fact that the majority of the updates will be a handled in a new background task, there won't be many modifications to files in Expertiza that currently exist. The current assignment configuration view will need to be expanded to add a configuration parameter and the Assignment model will need to be expanded to include a SimiCheck Delay parameter. The Plagiarism Comparison Report will be added to the &amp;quot;Review Report&amp;quot; ui's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
To view the interface changes, login to Expertiza as an instructor; navigate to Manage... Assignments. Click &amp;quot;New public/private assignment&amp;quot;. The last field on the New Assignment page says &amp;quot;SimiCheck Hour Delay&amp;quot;. Enter a value between 0 and 100 to enable the Plagiarism Checker. &lt;br /&gt;
&lt;br /&gt;
After the assignment ends and the delay period has passed, you can view the Plagiarism Report. Click the &amp;quot;View review report&amp;quot; icon containing a magnifying glass and two people (in the third row of per-assignment icons). Select &amp;quot;Plagiarism Checker Report&amp;quot; from the select box, and click &amp;quot;Submit&amp;quot;. If there is any plagiarism to report, it will load.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== Assignment - SimiCheck delay added ====&lt;br /&gt;
We added a &amp;quot;simicheck&amp;quot; property to the the existing Assignment model. This willl accommodate the number of hours to delay the execution of the Plagiarism Checker after the assignment's due date. &amp;quot;Simicheck&amp;quot; will be -1 if there is no Plagiarism Checker scheduled, and between 0 and 100 (hours) if the assignment is to have a Plagiarism Checker Report.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_Page_1.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
In order to be able to configure how long to wait to run the comparison task the current assignment configuration UI will be modified to contain another field where an integer can be input.&lt;br /&gt;
After the results have been aggregated they will be able to be viewed via a results report page. This report will include the submissions, their corresponding teams, and the similarity results. &amp;lt;br&amp;gt;&lt;br /&gt;
Here is a mock up of our proposed UI:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
The majority of this project is implemented as a background task and as such we can think of it as a separate application or process apart from Expertiza. Ideally this process will be running in another thread to allow for concurrency. We will be exploring during development different options for handling the task with respect to languages and trigger methodologies. For languages we will be exploring Ruby, Python, Node, and potentially others. From a trigger methodology standpoint we will explore both polling and/or event based triggering.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample(s) ===&lt;br /&gt;
''Coming soon...''&lt;br /&gt;
&lt;br /&gt;
=== Potential Hurdles ===&lt;br /&gt;
GiHub has rate limits with respect to how many requests we are allowed to make per auth token per hour. According to GitHub's documentation we are allowed 5000 authenticated requests per hour with an additional 60 requests per hour for unauthenticated requests. This documentation can be found [https://developer.github.com/v3/#rate-limiting here].  Due to the fact that this is a background task and immediate results are not required(will likely be an overnight task), we will ensure that if the need arises to exceed 5000 requests per hour that we will delay the subsequent quests until the next hour. This should satisfy the number of checks that need to occur within a reasonable time frame.&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108767</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108767"/>
		<updated>2017-04-29T20:05:17Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Expertiza Modifications */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. However, the outcomes from these projects did not clearly demonstrate successful integration with SimiCheck from Expertiza and were not deemed production worthy. As a result, part of our project involves researching the previous submission and learning from it. In addition, based on this feedback so far we have decided to start our development from scratch and utilize the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
Due to the fact that the majority of the updates will be a handled in a new background task, there won't be many modifications to files in Expertiza that currently exist. The current assignment configuration view will need to be expanded to add a configuration parameter and the Assignment model will need to be expanded to include a SimiCheck Delay parameter. The Plagiarism Comparison Report will be added to the &amp;quot;Review Report&amp;quot; ui's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
To view the interface changes, login to Expertiza as an instructor; navigate to Manage... Assignments. Click &amp;quot;New public/private assignment&amp;quot;. The last field on the New Assignment page says &amp;quot;SimiCheck Hour Delay&amp;quot;. Enter a value between 0 and 100 to enable the Plagiarism Checker. &lt;br /&gt;
&lt;br /&gt;
After the assignment ends and the delay period has passed, you can view the Plagiarism Report. Click the &amp;quot;View review report&amp;quot; icon containing a magnifying glass and two people (in the third row of per-assignment icons). Select &amp;quot;Plagiarism Checker Report&amp;quot; from the select box, and click &amp;quot;Submit&amp;quot;. If there is any plagiarism to report, it will load.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== Assignment ====&lt;br /&gt;
To accommodate the number of hours to wait after the assignment due date, before executing the Plagiarism Checking Comparison task, we added a &amp;quot;simicheck&amp;quot; property to the the existing Assignment model. &amp;quot;Simicheck&amp;quot; will be -1 if there is no Plagiarism Checking, and between 0 and 100 (hours) if the assignment is to have a Plagiarism Checker Report.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_Page_1.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
In order to be able to configure how long to wait to run the comparison task the current assignment configuration UI will be modified to contain another field where an integer can be input.&lt;br /&gt;
After the results have been aggregated they will be able to be viewed via a results report page. This report will include the submissions, their corresponding teams, and the similarity results. &amp;lt;br&amp;gt;&lt;br /&gt;
Here is a mock up of our proposed UI:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
The majority of this project is implemented as a background task and as such we can think of it as a separate application or process apart from Expertiza. Ideally this process will be running in another thread to allow for concurrency. We will be exploring during development different options for handling the task with respect to languages and trigger methodologies. For languages we will be exploring Ruby, Python, Node, and potentially others. From a trigger methodology standpoint we will explore both polling and/or event based triggering.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample(s) ===&lt;br /&gt;
''Coming soon...''&lt;br /&gt;
&lt;br /&gt;
=== Potential Hurdles ===&lt;br /&gt;
GiHub has rate limits with respect to how many requests we are allowed to make per auth token per hour. According to GitHub's documentation we are allowed 5000 authenticated requests per hour with an additional 60 requests per hour for unauthenticated requests. This documentation can be found [https://developer.github.com/v3/#rate-limiting here].  Due to the fact that this is a background task and immediate results are not required(will likely be an overnight task), we will ensure that if the need arises to exceed 5000 requests per hour that we will delay the subsequent quests until the next hour. This should satisfy the number of checks that need to occur within a reasonable time frame.&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=File:SimiCheck_View_Mockup.png&amp;diff=108766</id>
		<title>File:SimiCheck View Mockup.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=File:SimiCheck_View_Mockup.png&amp;diff=108766"/>
		<updated>2017-04-29T19:37:10Z</updated>

		<summary type="html">&lt;p&gt;Eleill: uploaded a new version of &amp;amp;quot;File:SimiCheck View Mockup.png&amp;amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;First version of the SimiCheck UI&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=File:SimiCheck_View_Mockup.png&amp;diff=108765</id>
		<title>File:SimiCheck View Mockup.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=File:SimiCheck_View_Mockup.png&amp;diff=108765"/>
		<updated>2017-04-29T19:33:57Z</updated>

		<summary type="html">&lt;p&gt;Eleill: uploaded a new version of &amp;amp;quot;File:SimiCheck View Mockup.png&amp;amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;First version of the SimiCheck UI&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108763</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108763"/>
		<updated>2017-04-29T06:18:25Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* AssignmentComparisonWait */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. However, the outcomes from these projects did not clearly demonstrate successful integration with SimiCheck from Expertiza and were not deemed production worthy. As a result, part of our project involves researching the previous submission and learning from it. In addition, based on this feedback so far we have decided to start our development from scratch and utilize the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
Due to the fact that the majority of the updates will be a handled in a new background task, there won't be many modifications to files in Expertiza that currently exist. The current assignment configuration view will need to be expanded to add a configuration parameter and the Assignment model will need to be expanded to include a SimiCheck Delay parameter. The Plagiarism Comparison Report will be added to the &amp;quot;Review Report&amp;quot; ui's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== Assignment ====&lt;br /&gt;
To accommodate the number of hours to wait after the assignment due date, before executing the Plagiarism Checking Comparison task, we added a &amp;quot;simicheck&amp;quot; property to the the existing Assignment model. &amp;quot;Simicheck&amp;quot; will be -1 if there is no Plagiarism Checking, and between 0 and 100 (hours) if the assignment is to have a Plagiarism Checker Report.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_Page_1.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
In order to be able to configure how long to wait to run the comparison task the current assignment configuration UI will be modified to contain another field where an integer can be input.&lt;br /&gt;
After the results have been aggregated they will be able to be viewed via a results report page. This report will include the submissions, their corresponding teams, and the similarity results. &amp;lt;br&amp;gt;&lt;br /&gt;
Here is a mock up of our proposed UI:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
The majority of this project is implemented as a background task and as such we can think of it as a separate application or process apart from Expertiza. Ideally this process will be running in another thread to allow for concurrency. We will be exploring during development different options for handling the task with respect to languages and trigger methodologies. For languages we will be exploring Ruby, Python, Node, and potentially others. From a trigger methodology standpoint we will explore both polling and/or event based triggering.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample(s) ===&lt;br /&gt;
''Coming soon...''&lt;br /&gt;
&lt;br /&gt;
=== Potential Hurdles ===&lt;br /&gt;
GiHub has rate limits with respect to how many requests we are allowed to make per auth token per hour. According to GitHub's documentation we are allowed 5000 authenticated requests per hour with an additional 60 requests per hour for unauthenticated requests. This documentation can be found [https://developer.github.com/v3/#rate-limiting here].  Due to the fact that this is a background task and immediate results are not required(will likely be an overnight task), we will ensure that if the need arises to exceed 5000 requests per hour that we will delay the subsequent quests until the next hour. This should satisfy the number of checks that need to occur within a reasonable time frame.&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108762</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108762"/>
		<updated>2017-04-29T06:12:53Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* AssignmentComparisonWait */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. However, the outcomes from these projects did not clearly demonstrate successful integration with SimiCheck from Expertiza and were not deemed production worthy. As a result, part of our project involves researching the previous submission and learning from it. In addition, based on this feedback so far we have decided to start our development from scratch and utilize the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
Due to the fact that the majority of the updates will be a handled in a new background task, there won't be many modifications to files in Expertiza that currently exist. The current assignment configuration view will need to be expanded to add a configuration parameter and the Assignment model will need to be expanded to include a SimiCheck Delay parameter. The Plagiarism Comparison Report will be added to the &amp;quot;Review Report&amp;quot; ui's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== AssignmentComparisonWait ====&lt;br /&gt;
This model &amp;quot;belongs_to&amp;quot; the current Assignment model that already exists. It will contain as its foreign key an assignment as well as a field for how many hours to wait after the assignment due date before executing the comparison task.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_Page_1.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
In order to be able to configure how long to wait to run the comparison task the current assignment configuration UI will be modified to contain another field where an integer can be input.&lt;br /&gt;
After the results have been aggregated they will be able to be viewed via a results report page. This report will include the submissions, their corresponding teams, and the similarity results. &amp;lt;br&amp;gt;&lt;br /&gt;
Here is a mock up of our proposed UI:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
The majority of this project is implemented as a background task and as such we can think of it as a separate application or process apart from Expertiza. Ideally this process will be running in another thread to allow for concurrency. We will be exploring during development different options for handling the task with respect to languages and trigger methodologies. For languages we will be exploring Ruby, Python, Node, and potentially others. From a trigger methodology standpoint we will explore both polling and/or event based triggering.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample(s) ===&lt;br /&gt;
''Coming soon...''&lt;br /&gt;
&lt;br /&gt;
=== Potential Hurdles ===&lt;br /&gt;
GiHub has rate limits with respect to how many requests we are allowed to make per auth token per hour. According to GitHub's documentation we are allowed 5000 authenticated requests per hour with an additional 60 requests per hour for unauthenticated requests. This documentation can be found [https://developer.github.com/v3/#rate-limiting here].  Due to the fact that this is a background task and immediate results are not required(will likely be an overnight task), we will ensure that if the need arises to exceed 5000 requests per hour that we will delay the subsequent quests until the next hour. This should satisfy the number of checks that need to occur within a reasonable time frame.&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108761</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108761"/>
		<updated>2017-04-29T05:42:04Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Expertiza Modifications */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. However, the outcomes from these projects did not clearly demonstrate successful integration with SimiCheck from Expertiza and were not deemed production worthy. As a result, part of our project involves researching the previous submission and learning from it. In addition, based on this feedback so far we have decided to start our development from scratch and utilize the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
Due to the fact that the majority of the updates will be a handled in a new background task, there won't be many modifications to files in Expertiza that currently exist. The current assignment configuration view will need to be expanded to add a configuration parameter and the Assignment model will need to be expanded to include a SimiCheck Delay parameter. The Plagiarism Comparison Report will be added to the &amp;quot;Review Report&amp;quot; ui's select box for a selected assignment.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== AssignmentComparisonWait ====&lt;br /&gt;
This model &amp;quot;belongs_to&amp;quot; the current Assignment model that already exists. It will contain as it's foreign key an assignment as well as a field for how many hours to wait after the assignment due date before executing the comparison task.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_Page_1.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
In order to be able to configure how long to wait to run the comparison task the current assignment configuration UI will be modified to contain another field where an integer can be input.&lt;br /&gt;
After the results have been aggregated they will be able to be viewed via a results report page. This report will include the submissions, their corresponding teams, and the similarity results. &amp;lt;br&amp;gt;&lt;br /&gt;
Here is a mock up of our proposed UI:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
The majority of this project is implemented as a background task and as such we can think of it as a separate application or process apart from Expertiza. Ideally this process will be running in another thread to allow for concurrency. We will be exploring during development different options for handling the task with respect to languages and trigger methodologies. For languages we will be exploring Ruby, Python, Node, and potentially others. From a trigger methodology standpoint we will explore both polling and/or event based triggering.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample(s) ===&lt;br /&gt;
''Coming soon...''&lt;br /&gt;
&lt;br /&gt;
=== Potential Hurdles ===&lt;br /&gt;
GiHub has rate limits with respect to how many requests we are allowed to make per auth token per hour. According to GitHub's documentation we are allowed 5000 authenticated requests per hour with an additional 60 requests per hour for unauthenticated requests. This documentation can be found [https://developer.github.com/v3/#rate-limiting here].  Due to the fact that this is a background task and immediate results are not required(will likely be an overnight task), we will ensure that if the need arises to exceed 5000 requests per hour that we will delay the subsequent quests until the next hour. This should satisfy the number of checks that need to occur within a reasonable time frame.&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108760</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108760"/>
		<updated>2017-04-29T05:35:42Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Requirements */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. However, the outcomes from these projects did not clearly demonstrate successful integration with SimiCheck from Expertiza and were not deemed production worthy. As a result, part of our project involves researching the previous submission and learning from it. In addition, based on this feedback so far we have decided to start our development from scratch and utilize the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** We will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** We will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
Due to the fact that the majority of the updates will be a handled in a new background task, there won't be many modifications to files in Expertiza that currently exist. The current assignment configuration view will need to be expanded to add a configuration parameter and the Assignment model will need to be expanded to include a comparison wait parameter. New links will need to be added to current assignment status view to enable navigation to the new comparison report page.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== AssignmentComparisonWait ====&lt;br /&gt;
This model &amp;quot;belongs_to&amp;quot; the current Assignment model that already exists. It will contain as it's foreign key an assignment as well as a field for how many hours to wait after the assignment due date before executing the comparison task.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_Page_1.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
In order to be able to configure how long to wait to run the comparison task the current assignment configuration UI will be modified to contain another field where an integer can be input.&lt;br /&gt;
After the results have been aggregated they will be able to be viewed via a results report page. This report will include the submissions, their corresponding teams, and the similarity results. &amp;lt;br&amp;gt;&lt;br /&gt;
Here is a mock up of our proposed UI:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
The majority of this project is implemented as a background task and as such we can think of it as a separate application or process apart from Expertiza. Ideally this process will be running in another thread to allow for concurrency. We will be exploring during development different options for handling the task with respect to languages and trigger methodologies. For languages we will be exploring Ruby, Python, Node, and potentially others. From a trigger methodology standpoint we will explore both polling and/or event based triggering.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample(s) ===&lt;br /&gt;
''Coming soon...''&lt;br /&gt;
&lt;br /&gt;
=== Potential Hurdles ===&lt;br /&gt;
GiHub has rate limits with respect to how many requests we are allowed to make per auth token per hour. According to GitHub's documentation we are allowed 5000 authenticated requests per hour with an additional 60 requests per hour for unauthenticated requests. This documentation can be found [https://developer.github.com/v3/#rate-limiting here].  Due to the fact that this is a background task and immediate results are not required(will likely be an overnight task), we will ensure that if the need arises to exceed 5000 requests per hour that we will delay the subsequent quests until the next hour. This should satisfy the number of checks that need to occur within a reasonable time frame.&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108759</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108759"/>
		<updated>2017-04-29T05:32:56Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Problem Statement */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html SimiCheck]. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. .&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. However, the outcomes from these projects did not clearly demonstrate successful integration with SimiCheck from Expertiza and were not deemed production worthy. As a result, part of our project involves researching the previous submission and learning from it. In addition, based on this feedback so far we have decided to start our development from scratch and utilize the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** Will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** Will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
Due to the fact that the majority of the updates will be a handled in a new background task, there won't be many modifications to files in Expertiza that currently exist. The current assignment configuration view will need to be expanded to add a configuration parameter and the Assignment model will need to be expanded to include a comparison wait parameter. New links will need to be added to current assignment status view to enable navigation to the new comparison report page.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== AssignmentComparisonWait ====&lt;br /&gt;
This model &amp;quot;belongs_to&amp;quot; the current Assignment model that already exists. It will contain as it's foreign key an assignment as well as a field for how many hours to wait after the assignment due date before executing the comparison task.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_Page_1.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
In order to be able to configure how long to wait to run the comparison task the current assignment configuration UI will be modified to contain another field where an integer can be input.&lt;br /&gt;
After the results have been aggregated they will be able to be viewed via a results report page. This report will include the submissions, their corresponding teams, and the similarity results. &amp;lt;br&amp;gt;&lt;br /&gt;
Here is a mock up of our proposed UI:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
The majority of this project is implemented as a background task and as such we can think of it as a separate application or process apart from Expertiza. Ideally this process will be running in another thread to allow for concurrency. We will be exploring during development different options for handling the task with respect to languages and trigger methodologies. For languages we will be exploring Ruby, Python, Node, and potentially others. From a trigger methodology standpoint we will explore both polling and/or event based triggering.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample(s) ===&lt;br /&gt;
''Coming soon...''&lt;br /&gt;
&lt;br /&gt;
=== Potential Hurdles ===&lt;br /&gt;
GiHub has rate limits with respect to how many requests we are allowed to make per auth token per hour. According to GitHub's documentation we are allowed 5000 authenticated requests per hour with an additional 60 requests per hour for unauthenticated requests. This documentation can be found [https://developer.github.com/v3/#rate-limiting here].  Due to the fact that this is a background task and immediate results are not required(will likely be an overnight task), we will ensure that if the need arises to exceed 5000 requests per hour that we will delay the subsequent quests until the next hour. This should satisfy the number of checks that need to occur within a reasonable time frame.&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108671</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108671"/>
		<updated>2017-04-28T20:56:19Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Requirements */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called SimiCheck. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. More information on the SimiCheck API can be found [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html here].&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. However, the outcomes from these projects did not clearly demonstrate successful integration with SimiCheck from Expertiza and were not deemed production worthy. As a result, part of our project involves researching the previous submission and learning from it. In addition, based on this feedback so far we have decided to start our development from scratch and utilize the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** Will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** Will edit view/review_mapping/response_report.html.haml to include a new PlagiarismCheckerReport type and point to the plagiarism_checker_report partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
Due to the fact that the majority of the updates will be a handled in a new background task, there won't be many modifications to files in Expertiza that currently exist. The current assignment configuration view will need to be expanded to add a configuration parameter and the Assignment model will need to be expanded to include a comparison wait parameter. New links will need to be added to current assignment status view to enable navigation to the new comparison report page.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== AssignmentComparisonWait ====&lt;br /&gt;
This model &amp;quot;belongs_to&amp;quot; the current Assignment model that already exists. It will contain as it's foreign key an assignment as well as a field for how many hours to wait after the assignment due date before executing the comparison task.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_Page_1.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
In order to be able to configure how long to wait to run the comparison task the current assignment configuration UI will be modified to contain another field where an integer can be input.&lt;br /&gt;
After the results have been aggregated they will be able to be viewed via a results report page. This report will include the submissions, their corresponding teams, and the similarity results. &amp;lt;br&amp;gt;&lt;br /&gt;
Here is a mock up of our proposed UI:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
The majority of this project is implemented as a background task and as such we can think of it as a separate application or process apart from Expertiza. Ideally this process will be running in another thread to allow for concurrency. We will be exploring during development different options for handling the task with respect to languages and trigger methodologies. For languages we will be exploring Ruby, Python, Node, and potentially others. From a trigger methodology standpoint we will explore both polling and/or event based triggering.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample(s) ===&lt;br /&gt;
''Coming soon...''&lt;br /&gt;
&lt;br /&gt;
=== Potential Hurdles ===&lt;br /&gt;
GiHub has rate limits with respect to how many requests we are allowed to make per auth token per hour. According to GitHub's documentation we are allowed 5000 authenticated requests per hour with an additional 60 requests per hour for unauthenticated requests. This documentation can be found [https://developer.github.com/v3/#rate-limiting here].  Due to the fact that this is a background task and immediate results are not required(will likely be an overnight task), we will ensure that if the need arises to exceed 5000 requests per hour that we will delay the subsequent quests until the next hour. This should satisfy the number of checks that need to occur within a reasonable time frame.&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108669</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108669"/>
		<updated>2017-04-28T20:55:38Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Requirements */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called SimiCheck. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. More information on the SimiCheck API can be found [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html here].&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. However, the outcomes from these projects did not clearly demonstrate successful integration with SimiCheck from Expertiza and were not deemed production worthy. As a result, part of our project involves researching the previous submission and learning from it. In addition, based on this feedback so far we have decided to start our development from scratch and utilize the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** Will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** Will edit view/review_mapping/response_report.html.haml to include an new PlagiarismCheckerReport type and pointer to the new partial.&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
Due to the fact that the majority of the updates will be a handled in a new background task, there won't be many modifications to files in Expertiza that currently exist. The current assignment configuration view will need to be expanded to add a configuration parameter and the Assignment model will need to be expanded to include a comparison wait parameter. New links will need to be added to current assignment status view to enable navigation to the new comparison report page.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== AssignmentComparisonWait ====&lt;br /&gt;
This model &amp;quot;belongs_to&amp;quot; the current Assignment model that already exists. It will contain as it's foreign key an assignment as well as a field for how many hours to wait after the assignment due date before executing the comparison task.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_Page_1.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
In order to be able to configure how long to wait to run the comparison task the current assignment configuration UI will be modified to contain another field where an integer can be input.&lt;br /&gt;
After the results have been aggregated they will be able to be viewed via a results report page. This report will include the submissions, their corresponding teams, and the similarity results. &amp;lt;br&amp;gt;&lt;br /&gt;
Here is a mock up of our proposed UI:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
The majority of this project is implemented as a background task and as such we can think of it as a separate application or process apart from Expertiza. Ideally this process will be running in another thread to allow for concurrency. We will be exploring during development different options for handling the task with respect to languages and trigger methodologies. For languages we will be exploring Ruby, Python, Node, and potentially others. From a trigger methodology standpoint we will explore both polling and/or event based triggering.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample(s) ===&lt;br /&gt;
''Coming soon...''&lt;br /&gt;
&lt;br /&gt;
=== Potential Hurdles ===&lt;br /&gt;
GiHub has rate limits with respect to how many requests we are allowed to make per auth token per hour. According to GitHub's documentation we are allowed 5000 authenticated requests per hour with an additional 60 requests per hour for unauthenticated requests. This documentation can be found [https://developer.github.com/v3/#rate-limiting here].  Due to the fact that this is a background task and immediate results are not required(will likely be an overnight task), we will ensure that if the need arises to exceed 5000 requests per hour that we will delay the subsequent quests until the next hour. This should satisfy the number of checks that need to occur within a reasonable time frame.&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108657</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=108657"/>
		<updated>2017-04-28T12:14:50Z</updated>

		<summary type="html">&lt;p&gt;Eleill: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called SimiCheck. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed. More information on the SimiCheck API can be found [https://simicheck.com/simicheck/static/swagger-ui/dist/index.html here].&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. However, the outcomes from these projects did not clearly demonstrate successful integration with SimiCheck from Expertiza and were not deemed production worthy. As a result, part of our project involves researching the previous submission and learning from it. In addition, based on this feedback so far we have decided to start our development from scratch and utilize the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** Will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** Will create this file:  view/review_mapping/response_report.html.erb&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Expertiza Modifications ==&lt;br /&gt;
Due to the fact that the majority of the updates will be a handled in a new background task, there won't be many modifications to files in Expertiza that currently exist. The current assignment configuration view will need to be expanded to add a configuration parameter and the Assignment model will need to be expanded to include a comparison wait parameter. New links will need to be added to current assignment status view to enable navigation to the new comparison report page.&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== AssignmentComparisonWait ====&lt;br /&gt;
This model &amp;quot;belongs_to&amp;quot; the current Assignment model that already exists. It will contain as it's foreign key an assignment as well as a field for how many hours to wait after the assignment due date before executing the comparison task.&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerComparison ====&lt;br /&gt;
This model '''belongs_to''' the PlagiarismCheckerAssignmentSubmission model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== PlagiarismCheckerAssignmentSubmission ====&lt;br /&gt;
This model '''has_many''' PlagiarismCheckerComparison models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_Page_1.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
In order to be able to configure how long to wait to run the comparison task the current assignment configuration UI will be modified to contain another field where an integer can be input.&lt;br /&gt;
After the results have been aggregated they will be able to be viewed via a results report page. This report will include the submissions, their corresponding teams, and the similarity results. &amp;lt;br&amp;gt;&lt;br /&gt;
Here is a mock up of our proposed UI:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
=== Task Triggering ===&lt;br /&gt;
The majority of this project is implemented as a background task and as such we can think of it as a separate application or process apart from Expertiza. Ideally this process will be running in another thread to allow for concurrency. We will be exploring during development different options for handling the task with respect to languages and trigger methodologies. For languages we will be exploring Ruby, Python, Node, and potentially others. From a trigger methodology standpoint we will explore both polling and/or event based triggering.&lt;br /&gt;
&lt;br /&gt;
=== Code Sample(s) ===&lt;br /&gt;
''Coming soon...''&lt;br /&gt;
&lt;br /&gt;
=== Potential Hurdles ===&lt;br /&gt;
GiHub has rate limits with respect to how many requests we are allowed to make per auth token per hour. According to GitHub's documentation we are allowed 5000 authenticated requests per hour with an additional 60 requests per hour for unauthenticated requests. This documentation can be found [https://developer.github.com/v3/#rate-limiting here].  Due to the fact that this is a background task and immediate results are not required(will likely be an overnight task), we will ensure that if the need arises to exceed 5000 requests per hour that we will delay the subsequent quests until the next hour. This should satisfy the number of checks that need to occur within a reasonable time frame.&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=107952</id>
		<title>CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016/E1738_Integrate_Simicheck_Web_Service&amp;diff=107952"/>
		<updated>2017-04-06T21:25:30Z</updated>

		<summary type="html">&lt;p&gt;Eleill: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Team BEND - Bradford Ingersoll, Erika Eill, Nephi Grant, David Gutierrez&lt;br /&gt;
&lt;br /&gt;
== Problem Statement ==&lt;br /&gt;
Given that submissions to Expertiza are digital in nature, the opportunity exists to utilize tools that automate plagiarism validation. One of these such tools is called SimiCheck. SimiCheck has a web service API that can be used to compare documents and check them for plagiarism. The goal of this project is to integrate the SimiCheck API into Expertiza in order to allow for an automated plagiarism check to take place once a submission is closed.&lt;br /&gt;
&lt;br /&gt;
== Background ==&lt;br /&gt;
This project has been worked on before in previous semesters. However, the outcomes from these projects did not clearly demonstrate successful integration with SimiCheck from Expertiza and were not deemed production worthy. As a result, part of our project involves researching the previous submission and learning from it. In addition, based on this feedback so far we have decided to start our development from scratch and utilize the previous project as a resource for lessons learned.&lt;br /&gt;
&lt;br /&gt;
== Requirements ==&lt;br /&gt;
* Create a scheduled background task that starts a configurable amount of time after the due date of an assignment has passed&lt;br /&gt;
* The scheduled task should do the following:&lt;br /&gt;
** Fetch the submission content using links provided by the student in Expertiza from only these sources:&lt;br /&gt;
*** External website or MediaWiki&lt;br /&gt;
**** GET request to the URL then strip HTML from the content&lt;br /&gt;
*** Google Doc (not sheet or slides)&lt;br /&gt;
**** Google Drive API&lt;br /&gt;
*** GitHub project (not pull requests)&lt;br /&gt;
**** GitHub API, will only use the student or group’s changes&lt;br /&gt;
** Categorize the submission content as either a text submission or source code&lt;br /&gt;
** Convert the submission content to raw text format to facilitate comparison&lt;br /&gt;
** Use the SimiCheck API to check similarity among the assignment’s submissions&lt;br /&gt;
*** Notify the instructor that a comparison has started&lt;br /&gt;
*** Send the content of the submissions for each submission category&lt;br /&gt;
**** We will experiment with how many documents to send at a time&lt;br /&gt;
**** Note that each file is limited in size to 1 MB by SimiCheck&lt;br /&gt;
*** Wait for the SimiCheck comparison process to complete&lt;br /&gt;
**** We will provide SimiCheck with a callback URL to notify when the comparison is complete, however if this doesn’t work well will revert to polling&lt;br /&gt;
**** Will also provide an “Update Status” link to manually poll comparison status &lt;br /&gt;
*** Notify the assignment’s instructor that a comparison has been completed&lt;br /&gt;
* Visualize the results in report&lt;br /&gt;
** Will create this file:  view/review_mapping/response_report.html.erb&lt;br /&gt;
** Since SimiCheck has already implemented file diffs, links will be provided in the Expertiza view that lead to the SimiCheck website for each file combination&lt;br /&gt;
** Comparison results for each category will be displayed within Expertiza in a table&lt;br /&gt;
*** Each row is a file combination with similiarity, file names, team names, and diff link&lt;br /&gt;
*** Sorted in descending similarity&lt;br /&gt;
*** Uses available data from the SimiCheck API’s summary report&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
=== Pattern(s) ===&lt;br /&gt;
Given that this project revolves around integration with several web services, our team is planning to follow the [https://en.wikipedia.org/wiki/Facade_pattern facade design pattern] to allow Expertiza to make REST requests to several APIs include SimiCheck, GitHub, Google Drive, etc. This pattern is commonly used to abstract complex functionalities into a simpler interface for use as well as encapsulate API changes to prevent having to update application code if the service changes or a different one is used. We feel this is appropriate based on the requirements because we can create an easy-to-use interface within Expertiza that hides the actual API integration behind the scenes. With this in place, current and future Expertiza developers can use our simplified functionality without needing to understand the miniscule details of the API’s operation.&lt;br /&gt;
&lt;br /&gt;
=== Model(s) ===&lt;br /&gt;
''There is no need to store the raw content sent to SimiCheck.&lt;br /&gt;
&lt;br /&gt;
==== AssignmentSubmissionsComparisonResult ====&lt;br /&gt;
This model '''belongs_to''' the AssignmentSubmissionsComparison model.  It stores the file IDs returned from SimiCheck, the percent similarity between them, and a URL to a detailed comparison (diff).&lt;br /&gt;
&lt;br /&gt;
==== AssignmentSubmissionsComparison ====&lt;br /&gt;
This model '''has_many''' AssignmentSubmissionsComparisonResult models.  It represents the results of the comparison among submissions for the assignment.  As such it will contain all of the relevant fields that are shown in the view as described in the requirements.&lt;br /&gt;
&lt;br /&gt;
=== Diagram ===&lt;br /&gt;
Typical overall system operation is shown here:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Simicheck_API_-_Page_1.png]]&lt;br /&gt;
&lt;br /&gt;
=== User Interface ===&lt;br /&gt;
Here is a mock up of our proposed UI:&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:SimiCheck_View_Mockup.png]]&lt;br /&gt;
&lt;br /&gt;
=== Code Sample(s) ===&lt;br /&gt;
''Coming soon...''&lt;br /&gt;
&lt;br /&gt;
== Testing Strategy ==&lt;br /&gt;
=== API Testing during Development ===&lt;br /&gt;
API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.&lt;br /&gt;
&lt;br /&gt;
=== Automated Testing within Rails ===&lt;br /&gt;
We plan on writing unit tests for any controllers and models that we create.  High level testing of the controllers, models, and view together will be done with Capybara. The tests we write will be alongside the existing test framework in Expertiza.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/OSS_M1706_Tracking_intermittent_test_failures_over_time&amp;diff=107608</id>
		<title>CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/OSS_M1706_Tracking_intermittent_test_failures_over_time&amp;diff=107608"/>
		<updated>2017-03-30T21:16:53Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* To Run The App Locally */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
This wiki provides details on new functionality programmed for the Servo OSS project.&lt;br /&gt;
&lt;br /&gt;
===Background===&lt;br /&gt;
&amp;quot;[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races.&amp;quot; Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely. &lt;br /&gt;
&lt;br /&gt;
===Motivation===&lt;br /&gt;
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. The [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project request] made is for a [http://flask.pocoo.org/docs/0.12/ Flask] service using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7]. The intermittent test failure tracker stores information regarding a test that fails intermittently and also provides means to quickly query for tests that have failed.&lt;br /&gt;
&lt;br /&gt;
===Tasks===&lt;br /&gt;
The intermittent test failure tracker initial steps (for the OSS project) include:&lt;br /&gt;
* Build a Flask service &lt;br /&gt;
* Use a JSON file to store information&lt;br /&gt;
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number&lt;br /&gt;
* Query the store results given a particular test file name&lt;br /&gt;
* Use the known intermittent issue tracker as an example of a Simple flask server &lt;br /&gt;
&lt;br /&gt;
Subsequent steps (for the final project) include:&lt;br /&gt;
* Add ability to query the service by a date range, to find out which were occurred the most often&lt;br /&gt;
* Build an HTML front-end to the service that queries using JS and reports the results&lt;br /&gt;
** Links to GitHub&lt;br /&gt;
** Sorting&lt;br /&gt;
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered&lt;br /&gt;
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
&lt;br /&gt;
===Design Pattern===&lt;br /&gt;
&lt;br /&gt;
The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller &amp;quot;services&amp;quot; and applies the services to the topmost &amp;quot;layer&amp;quot; of the project for which they are needed.&lt;br /&gt;
&lt;br /&gt;
===Application Flow===&lt;br /&gt;
&lt;br /&gt;
==== Saving a Test ====&lt;br /&gt;
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
                    +---------------------------------------------+&lt;br /&gt;
                    |       Intermittent Test Failure Tracker     |&lt;br /&gt;
                    |                                             |&lt;br /&gt;
+--------------+    | +-----------+      +---------+    +------+  |&lt;br /&gt;
|              |    | |           |      |         |    |      |  |      +--------+&lt;br /&gt;
|    Servo     |    | |           |      |         |    |      |  |      |        |&lt;br /&gt;
|    Build     +------&amp;gt;  webhook  +------&amp;gt; handler +----&amp;gt;  db  +---------&amp;gt;  json  |&lt;br /&gt;
|    Server    |    | |           |      |         |    |      |  |      |  file  |&lt;br /&gt;
|              |    | |           |      |         |    |      |  |      |        |&lt;br /&gt;
+--------------+    | +-----------+      +---------+    +------+  |      +--------+&lt;br /&gt;
                    |                                             |&lt;br /&gt;
                    +---------------------------------------------+&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Implementation ==&lt;br /&gt;
The implementation is entirely influenced by the request, the Servo team clearly defines what the service should do and how it would be made.&lt;br /&gt;
&lt;br /&gt;
=== Data model ===&lt;br /&gt;
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; &lt;br /&gt;
|-&lt;br /&gt;
! Name&lt;br /&gt;
! Type&lt;br /&gt;
! Description&lt;br /&gt;
|-&lt;br /&gt;
| test_file&lt;br /&gt;
| String&lt;br /&gt;
| Name of the intermittent test file &lt;br /&gt;
|-&lt;br /&gt;
| platform&lt;br /&gt;
| String&lt;br /&gt;
| Platform the test failed on&lt;br /&gt;
|-&lt;br /&gt;
| builder&lt;br /&gt;
| String&lt;br /&gt;
| The test machine (builder) the test failed on&lt;br /&gt;
|-&lt;br /&gt;
| number&lt;br /&gt;
| Integer&lt;br /&gt;
| The GitHub pull request number&lt;br /&gt;
|-&lt;br /&gt;
| fail_date&lt;br /&gt;
| ISO date (String)&lt;br /&gt;
| Date of the failure&lt;br /&gt;
|}&lt;br /&gt;
=== Datastore ===&lt;br /&gt;
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human-readable.&lt;br /&gt;
&lt;br /&gt;
=== Flask Service ===&lt;br /&gt;
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes:&lt;br /&gt;
  &lt;br /&gt;
  @app.route('/')&lt;br /&gt;
  def index():&lt;br /&gt;
    return 'Index page'&lt;br /&gt;
  &lt;br /&gt;
  @app.route('/user/&amp;lt;username&amp;gt;')&lt;br /&gt;
  def show_user(username):&lt;br /&gt;
    return db.lookup(username)&lt;br /&gt;
&lt;br /&gt;
The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
=== Functional Testing ===&lt;br /&gt;
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.&lt;br /&gt;
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.&lt;br /&gt;
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records. &lt;br /&gt;
All usable for thorough integration testing.&lt;br /&gt;
&lt;br /&gt;
===Unit Testing===&lt;br /&gt;
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. All unit tests are in tests.py.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
! colspan=&amp;quot;3&amp;quot; | Unit Test Summary&lt;br /&gt;
|-&lt;br /&gt;
! Test Purpose&lt;br /&gt;
! Function Tested&lt;br /&gt;
! Parameters&lt;br /&gt;
|-&lt;br /&gt;
| Add a record to a database &lt;br /&gt;
| db.add&lt;br /&gt;
| params[:self, :test_file, :platform, :builder, :number, :fail_date]&lt;br /&gt;
|-&lt;br /&gt;
| Delete a record from database&lt;br /&gt;
| db.remove&lt;br /&gt;
| params[:test_file]&lt;br /&gt;
|-&lt;br /&gt;
| Record a new Intermittent failure&lt;br /&gt;
| handlers.record&lt;br /&gt;
| params[:db, :test_file, :platform, :builder, :number]&lt;br /&gt;
|-&lt;br /&gt;
| Query the Intermittent failure records &lt;br /&gt;
| handlers.query&lt;br /&gt;
| params[:db, :test_file]&lt;br /&gt;
|-&lt;br /&gt;
| Record a new Intermittent failure, test invalid values - 4 tests for blanks for each input item&lt;br /&gt;
| handlers.record&lt;br /&gt;
| params[:db, :test_file, :platform, :builder, :number]&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
====Running Unit Tests and the App====&lt;br /&gt;
&lt;br /&gt;
Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo].&lt;br /&gt;
&lt;br /&gt;
=====To Run Unit Tests=====&lt;br /&gt;
* In the cloned repo folder, use the command &amp;lt;code&amp;gt;python test.py&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=====To Run The App Locally=====&lt;br /&gt;
* In the cloned repo folder, use the command &amp;lt;code&amp;gt;python -m flask_server&amp;lt;/code&amp;gt;&lt;br /&gt;
* To launch the app, go to http://localhost:5000&lt;br /&gt;
&lt;br /&gt;
== Submission/Pull Requests ==&lt;br /&gt;
&lt;br /&gt;
There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. In the interim, we shared our repo with Josh, whose reply was &amp;quot;this looks really great! Thanks for tackling it!&amp;quot;&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/OSS_M1706_Tracking_intermittent_test_failures_over_time&amp;diff=107607</id>
		<title>CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/OSS_M1706_Tracking_intermittent_test_failures_over_time&amp;diff=107607"/>
		<updated>2017-03-30T21:16:21Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Running Unit Tests and the App */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
This wiki provides details on new functionality programmed for the Servo OSS project.&lt;br /&gt;
&lt;br /&gt;
===Background===&lt;br /&gt;
&amp;quot;[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races.&amp;quot; Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely. &lt;br /&gt;
&lt;br /&gt;
===Motivation===&lt;br /&gt;
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. The [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project request] made is for a [http://flask.pocoo.org/docs/0.12/ Flask] service using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7]. The intermittent test failure tracker stores information regarding a test that fails intermittently and also provides means to quickly query for tests that have failed.&lt;br /&gt;
&lt;br /&gt;
===Tasks===&lt;br /&gt;
The intermittent test failure tracker initial steps (for the OSS project) include:&lt;br /&gt;
* Build a Flask service &lt;br /&gt;
* Use a JSON file to store information&lt;br /&gt;
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number&lt;br /&gt;
* Query the store results given a particular test file name&lt;br /&gt;
* Use the known intermittent issue tracker as an example of a Simple flask server &lt;br /&gt;
&lt;br /&gt;
Subsequent steps (for the final project) include:&lt;br /&gt;
* Add ability to query the service by a date range, to find out which were occurred the most often&lt;br /&gt;
* Build an HTML front-end to the service that queries using JS and reports the results&lt;br /&gt;
** Links to GitHub&lt;br /&gt;
** Sorting&lt;br /&gt;
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered&lt;br /&gt;
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
&lt;br /&gt;
===Design Pattern===&lt;br /&gt;
&lt;br /&gt;
The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller &amp;quot;services&amp;quot; and applies the services to the topmost &amp;quot;layer&amp;quot; of the project for which they are needed.&lt;br /&gt;
&lt;br /&gt;
===Application Flow===&lt;br /&gt;
&lt;br /&gt;
==== Saving a Test ====&lt;br /&gt;
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
                    +---------------------------------------------+&lt;br /&gt;
                    |       Intermittent Test Failure Tracker     |&lt;br /&gt;
                    |                                             |&lt;br /&gt;
+--------------+    | +-----------+      +---------+    +------+  |&lt;br /&gt;
|              |    | |           |      |         |    |      |  |      +--------+&lt;br /&gt;
|    Servo     |    | |           |      |         |    |      |  |      |        |&lt;br /&gt;
|    Build     +------&amp;gt;  webhook  +------&amp;gt; handler +----&amp;gt;  db  +---------&amp;gt;  json  |&lt;br /&gt;
|    Server    |    | |           |      |         |    |      |  |      |  file  |&lt;br /&gt;
|              |    | |           |      |         |    |      |  |      |        |&lt;br /&gt;
+--------------+    | +-----------+      +---------+    +------+  |      +--------+&lt;br /&gt;
                    |                                             |&lt;br /&gt;
                    +---------------------------------------------+&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Implementation ==&lt;br /&gt;
The implementation is entirely influenced by the request, the Servo team clearly defines what the service should do and how it would be made.&lt;br /&gt;
&lt;br /&gt;
=== Data model ===&lt;br /&gt;
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; &lt;br /&gt;
|-&lt;br /&gt;
! Name&lt;br /&gt;
! Type&lt;br /&gt;
! Description&lt;br /&gt;
|-&lt;br /&gt;
| test_file&lt;br /&gt;
| String&lt;br /&gt;
| Name of the intermittent test file &lt;br /&gt;
|-&lt;br /&gt;
| platform&lt;br /&gt;
| String&lt;br /&gt;
| Platform the test failed on&lt;br /&gt;
|-&lt;br /&gt;
| builder&lt;br /&gt;
| String&lt;br /&gt;
| The test machine (builder) the test failed on&lt;br /&gt;
|-&lt;br /&gt;
| number&lt;br /&gt;
| Integer&lt;br /&gt;
| The GitHub pull request number&lt;br /&gt;
|-&lt;br /&gt;
| fail_date&lt;br /&gt;
| ISO date (String)&lt;br /&gt;
| Date of the failure&lt;br /&gt;
|}&lt;br /&gt;
=== Datastore ===&lt;br /&gt;
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human-readable.&lt;br /&gt;
&lt;br /&gt;
=== Flask Service ===&lt;br /&gt;
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes:&lt;br /&gt;
  &lt;br /&gt;
  @app.route('/')&lt;br /&gt;
  def index():&lt;br /&gt;
    return 'Index page'&lt;br /&gt;
  &lt;br /&gt;
  @app.route('/user/&amp;lt;username&amp;gt;')&lt;br /&gt;
  def show_user(username):&lt;br /&gt;
    return db.lookup(username)&lt;br /&gt;
&lt;br /&gt;
The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
=== Functional Testing ===&lt;br /&gt;
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.&lt;br /&gt;
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.&lt;br /&gt;
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records. &lt;br /&gt;
All usable for thorough integration testing.&lt;br /&gt;
&lt;br /&gt;
===Unit Testing===&lt;br /&gt;
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. All unit tests are in tests.py.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
! colspan=&amp;quot;3&amp;quot; | Unit Test Summary&lt;br /&gt;
|-&lt;br /&gt;
! Test Purpose&lt;br /&gt;
! Function Tested&lt;br /&gt;
! Parameters&lt;br /&gt;
|-&lt;br /&gt;
| Add a record to a database &lt;br /&gt;
| db.add&lt;br /&gt;
| params[:self, :test_file, :platform, :builder, :number, :fail_date]&lt;br /&gt;
|-&lt;br /&gt;
| Delete a record from database&lt;br /&gt;
| db.remove&lt;br /&gt;
| params[:test_file]&lt;br /&gt;
|-&lt;br /&gt;
| Record a new Intermittent failure&lt;br /&gt;
| handlers.record&lt;br /&gt;
| params[:db, :test_file, :platform, :builder, :number]&lt;br /&gt;
|-&lt;br /&gt;
| Query the Intermittent failure records &lt;br /&gt;
| handlers.query&lt;br /&gt;
| params[:db, :test_file]&lt;br /&gt;
|-&lt;br /&gt;
| Record a new Intermittent failure, test invalid values - 4 tests for blanks for each input item&lt;br /&gt;
| handlers.record&lt;br /&gt;
| params[:db, :test_file, :platform, :builder, :number]&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
====Running Unit Tests and the App====&lt;br /&gt;
&lt;br /&gt;
Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo].&lt;br /&gt;
&lt;br /&gt;
=====To Run Unit Tests=====&lt;br /&gt;
* In the cloned repo folder, use the command &amp;lt;code&amp;gt;python test.py&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=====To Run The App Locally=====&lt;br /&gt;
* In the cloned repo folder, use the command &amp;lt;code&amp;gt;python -m flask_server&amp;lt;/code&amp;gt;&lt;br /&gt;
* Go to http://localhost:5000 to launch the app&lt;br /&gt;
&lt;br /&gt;
== Submission/Pull Requests ==&lt;br /&gt;
&lt;br /&gt;
There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. In the interim, we shared our repo with Josh, whose reply was &amp;quot;this looks really great! Thanks for tackling it!&amp;quot;&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/OSS_M1706_Tracking_intermittent_test_failures_over_time&amp;diff=107606</id>
		<title>CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/OSS_M1706_Tracking_intermittent_test_failures_over_time&amp;diff=107606"/>
		<updated>2017-03-30T21:16:07Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Datastore */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
This wiki provides details on new functionality programmed for the Servo OSS project.&lt;br /&gt;
&lt;br /&gt;
===Background===&lt;br /&gt;
&amp;quot;[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races.&amp;quot; Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely. &lt;br /&gt;
&lt;br /&gt;
===Motivation===&lt;br /&gt;
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. The [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project request] made is for a [http://flask.pocoo.org/docs/0.12/ Flask] service using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7]. The intermittent test failure tracker stores information regarding a test that fails intermittently and also provides means to quickly query for tests that have failed.&lt;br /&gt;
&lt;br /&gt;
===Tasks===&lt;br /&gt;
The intermittent test failure tracker initial steps (for the OSS project) include:&lt;br /&gt;
* Build a Flask service &lt;br /&gt;
* Use a JSON file to store information&lt;br /&gt;
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number&lt;br /&gt;
* Query the store results given a particular test file name&lt;br /&gt;
* Use the known intermittent issue tracker as an example of a Simple flask server &lt;br /&gt;
&lt;br /&gt;
Subsequent steps (for the final project) include:&lt;br /&gt;
* Add ability to query the service by a date range, to find out which were occurred the most often&lt;br /&gt;
* Build an HTML front-end to the service that queries using JS and reports the results&lt;br /&gt;
** Links to GitHub&lt;br /&gt;
** Sorting&lt;br /&gt;
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered&lt;br /&gt;
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
&lt;br /&gt;
===Design Pattern===&lt;br /&gt;
&lt;br /&gt;
The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller &amp;quot;services&amp;quot; and applies the services to the topmost &amp;quot;layer&amp;quot; of the project for which they are needed.&lt;br /&gt;
&lt;br /&gt;
===Application Flow===&lt;br /&gt;
&lt;br /&gt;
==== Saving a Test ====&lt;br /&gt;
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
                    +---------------------------------------------+&lt;br /&gt;
                    |       Intermittent Test Failure Tracker     |&lt;br /&gt;
                    |                                             |&lt;br /&gt;
+--------------+    | +-----------+      +---------+    +------+  |&lt;br /&gt;
|              |    | |           |      |         |    |      |  |      +--------+&lt;br /&gt;
|    Servo     |    | |           |      |         |    |      |  |      |        |&lt;br /&gt;
|    Build     +------&amp;gt;  webhook  +------&amp;gt; handler +----&amp;gt;  db  +---------&amp;gt;  json  |&lt;br /&gt;
|    Server    |    | |           |      |         |    |      |  |      |  file  |&lt;br /&gt;
|              |    | |           |      |         |    |      |  |      |        |&lt;br /&gt;
+--------------+    | +-----------+      +---------+    +------+  |      +--------+&lt;br /&gt;
                    |                                             |&lt;br /&gt;
                    +---------------------------------------------+&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Implementation ==&lt;br /&gt;
The implementation is entirely influenced by the request, the Servo team clearly defines what the service should do and how it would be made.&lt;br /&gt;
&lt;br /&gt;
=== Data model ===&lt;br /&gt;
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; &lt;br /&gt;
|-&lt;br /&gt;
! Name&lt;br /&gt;
! Type&lt;br /&gt;
! Description&lt;br /&gt;
|-&lt;br /&gt;
| test_file&lt;br /&gt;
| String&lt;br /&gt;
| Name of the intermittent test file &lt;br /&gt;
|-&lt;br /&gt;
| platform&lt;br /&gt;
| String&lt;br /&gt;
| Platform the test failed on&lt;br /&gt;
|-&lt;br /&gt;
| builder&lt;br /&gt;
| String&lt;br /&gt;
| The test machine (builder) the test failed on&lt;br /&gt;
|-&lt;br /&gt;
| number&lt;br /&gt;
| Integer&lt;br /&gt;
| The GitHub pull request number&lt;br /&gt;
|-&lt;br /&gt;
| fail_date&lt;br /&gt;
| ISO date (String)&lt;br /&gt;
| Date of the failure&lt;br /&gt;
|}&lt;br /&gt;
=== Datastore ===&lt;br /&gt;
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human-readable.&lt;br /&gt;
&lt;br /&gt;
=== Flask Service ===&lt;br /&gt;
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes:&lt;br /&gt;
  &lt;br /&gt;
  @app.route('/')&lt;br /&gt;
  def index():&lt;br /&gt;
    return 'Index page'&lt;br /&gt;
  &lt;br /&gt;
  @app.route('/user/&amp;lt;username&amp;gt;')&lt;br /&gt;
  def show_user(username):&lt;br /&gt;
    return db.lookup(username)&lt;br /&gt;
&lt;br /&gt;
The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
=== Functional Testing ===&lt;br /&gt;
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.&lt;br /&gt;
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.&lt;br /&gt;
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records. &lt;br /&gt;
All usable for thorough integration testing.&lt;br /&gt;
&lt;br /&gt;
===Unit Testing===&lt;br /&gt;
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. All unit tests are in tests.py.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
! colspan=&amp;quot;3&amp;quot; | Unit Test Summary&lt;br /&gt;
|-&lt;br /&gt;
! Test Purpose&lt;br /&gt;
! Function Tested&lt;br /&gt;
! Parameters&lt;br /&gt;
|-&lt;br /&gt;
| Add a record to a database &lt;br /&gt;
| db.add&lt;br /&gt;
| params[:self, :test_file, :platform, :builder, :number, :fail_date]&lt;br /&gt;
|-&lt;br /&gt;
| Delete a record from database&lt;br /&gt;
| db.remove&lt;br /&gt;
| params[:test_file]&lt;br /&gt;
|-&lt;br /&gt;
| Record a new Intermittent failure&lt;br /&gt;
| handlers.record&lt;br /&gt;
| params[:db, :test_file, :platform, :builder, :number]&lt;br /&gt;
|-&lt;br /&gt;
| Query the Intermittent failure records &lt;br /&gt;
| handlers.query&lt;br /&gt;
| params[:db, :test_file]&lt;br /&gt;
|-&lt;br /&gt;
| Record a new Intermittent failure, test invalid values - 4 tests for blanks for each input item&lt;br /&gt;
| handlers.record&lt;br /&gt;
| params[:db, :test_file, :platform, :builder, :number]&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
====Running Unit Tests and the App====&lt;br /&gt;
&lt;br /&gt;
Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo]&lt;br /&gt;
&lt;br /&gt;
=====To Run Unit Tests=====&lt;br /&gt;
* In the cloned repo folder, use the command &amp;lt;code&amp;gt;python test.py&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=====To Run The App Locally=====&lt;br /&gt;
* In the cloned repo folder, use the command &amp;lt;code&amp;gt;python -m flask_server&amp;lt;/code&amp;gt;&lt;br /&gt;
* Go to http://localhost:5000 to launch the app&lt;br /&gt;
&lt;br /&gt;
== Submission/Pull Requests ==&lt;br /&gt;
&lt;br /&gt;
There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. In the interim, we shared our repo with Josh, whose reply was &amp;quot;this looks really great! Thanks for tackling it!&amp;quot;&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/OSS_M1706_Tracking_intermittent_test_failures_over_time&amp;diff=107600</id>
		<title>CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/OSS_M1706_Tracking_intermittent_test_failures_over_time&amp;diff=107600"/>
		<updated>2017-03-30T15:49:43Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Unit Testing */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
This wiki provides details on new functionality programmed for the Servo OSS project.&lt;br /&gt;
&lt;br /&gt;
===Background===&lt;br /&gt;
&amp;quot;[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races.&amp;quot; Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely. &lt;br /&gt;
&lt;br /&gt;
===Motivation===&lt;br /&gt;
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. The [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project request] made is for a [http://flask.pocoo.org/docs/0.12/ Flask] service using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7]. The intermittent test failure tracker stores information regarding a test that fails intermittently and also provides means to quickly query for tests that have failed.&lt;br /&gt;
&lt;br /&gt;
===Tasks===&lt;br /&gt;
The intermittent test failure tracker initial steps (for the OSS project) include:&lt;br /&gt;
* Build a Flask service &lt;br /&gt;
* Use a JSON file to store information&lt;br /&gt;
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number&lt;br /&gt;
* Query the store results given a particular test file name&lt;br /&gt;
* Use the known intermittent issue tracker as an example of a Simple flask server &lt;br /&gt;
&lt;br /&gt;
Subsequent steps (for the final project) include:&lt;br /&gt;
* Add ability to query the service by a date range, to find out which were occurred the most often&lt;br /&gt;
* Build an HTML front-end to the service that queries using JS and reports the results&lt;br /&gt;
** Links to GitHub&lt;br /&gt;
** Sorting&lt;br /&gt;
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered&lt;br /&gt;
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
&lt;br /&gt;
===Design Pattern===&lt;br /&gt;
&lt;br /&gt;
The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller &amp;quot;services&amp;quot; and applies the services to the topmost &amp;quot;layer&amp;quot; of the project for which they are needed.&lt;br /&gt;
&lt;br /&gt;
===Application Flow===&lt;br /&gt;
&lt;br /&gt;
==== Saving a Test ====&lt;br /&gt;
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
                    +---------------------------------------------+&lt;br /&gt;
                    |       Intermittent Test Failure Tracker     |&lt;br /&gt;
                    |                                             |&lt;br /&gt;
+--------------+    | +-----------+      +---------+    +------+  |&lt;br /&gt;
|              |    | |           |      |         |    |      |  |      +--------+&lt;br /&gt;
|    Servo     |    | |           |      |         |    |      |  |      |        |&lt;br /&gt;
|    Build     +------&amp;gt;  webhook  +------&amp;gt; handler +----&amp;gt;  db  +---------&amp;gt;  json  |&lt;br /&gt;
|    Server    |    | |           |      |         |    |      |  |      |  file  |&lt;br /&gt;
|              |    | |           |      |         |    |      |  |      |        |&lt;br /&gt;
+--------------+    | +-----------+      +---------+    +------+  |      +--------+&lt;br /&gt;
                    |                                             |&lt;br /&gt;
                    +---------------------------------------------+&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Implementation ==&lt;br /&gt;
The implementation is entirely influenced by the request, the Servo team clearly defines what the service should do and how it would be made.&lt;br /&gt;
&lt;br /&gt;
=== Data model ===&lt;br /&gt;
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; &lt;br /&gt;
|-&lt;br /&gt;
! Name&lt;br /&gt;
! Type&lt;br /&gt;
! Description&lt;br /&gt;
|-&lt;br /&gt;
| test_file&lt;br /&gt;
| String&lt;br /&gt;
| Name of the intermittent test file &lt;br /&gt;
|-&lt;br /&gt;
| platform&lt;br /&gt;
| String&lt;br /&gt;
| Platform the test failed on&lt;br /&gt;
|-&lt;br /&gt;
| builder&lt;br /&gt;
| String&lt;br /&gt;
| The test machine (builder) the test failed on&lt;br /&gt;
|-&lt;br /&gt;
| number&lt;br /&gt;
| Integer&lt;br /&gt;
| The GitHub pull request number&lt;br /&gt;
|-&lt;br /&gt;
| fail_date&lt;br /&gt;
| ISO date (String)&lt;br /&gt;
| Date of the failure&lt;br /&gt;
|}&lt;br /&gt;
=== Datastore ===&lt;br /&gt;
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human readable.&lt;br /&gt;
&lt;br /&gt;
=== Flask Service ===&lt;br /&gt;
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes:&lt;br /&gt;
  &lt;br /&gt;
  @app.route('/')&lt;br /&gt;
  def index():&lt;br /&gt;
    return 'Index page'&lt;br /&gt;
  &lt;br /&gt;
  @app.route('/user/&amp;lt;username&amp;gt;')&lt;br /&gt;
  def show_user(username):&lt;br /&gt;
    return db.lookup(username)&lt;br /&gt;
&lt;br /&gt;
The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
=== Functional Testing ===&lt;br /&gt;
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.&lt;br /&gt;
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.&lt;br /&gt;
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records. &lt;br /&gt;
All usable for thorough integration testing.&lt;br /&gt;
&lt;br /&gt;
===Unit Testing===&lt;br /&gt;
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. All unit tests are in tests.py.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
! colspan=&amp;quot;3&amp;quot; | Unit Test Summary&lt;br /&gt;
|-&lt;br /&gt;
! Test Purpose&lt;br /&gt;
! Function Tested&lt;br /&gt;
! Parameters&lt;br /&gt;
|-&lt;br /&gt;
| Add a record to a database &lt;br /&gt;
| db.add&lt;br /&gt;
| params[:self, :test_file, :platform, :builder, :number, :fail_date]&lt;br /&gt;
|-&lt;br /&gt;
| Delete a record from database&lt;br /&gt;
| db.remove&lt;br /&gt;
| params[:test_file]&lt;br /&gt;
|-&lt;br /&gt;
| Record a new Intermittent failure&lt;br /&gt;
| handlers.record&lt;br /&gt;
| params[:db, :test_file, :platform, :builder, :number]&lt;br /&gt;
|-&lt;br /&gt;
| Query the Intermittent failure records &lt;br /&gt;
| handlers.query&lt;br /&gt;
| params[:db, :test_file]&lt;br /&gt;
|-&lt;br /&gt;
| Record a new Intermittent failure, test invalid values - 4 tests for blanks for each input item&lt;br /&gt;
| handlers.record&lt;br /&gt;
| params[:db, :test_file, :platform, :builder, :number]&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
====Running Unit Tests and the App====&lt;br /&gt;
&lt;br /&gt;
Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo]&lt;br /&gt;
&lt;br /&gt;
=====To Run Unit Tests=====&lt;br /&gt;
* In the cloned repo folder, use the command &amp;lt;code&amp;gt;python test.py&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=====To Run The App Locally=====&lt;br /&gt;
* In the cloned repo folder, use the command &amp;lt;code&amp;gt;python -m flask_server&amp;lt;/code&amp;gt;&lt;br /&gt;
* Go to http://localhost:5000 to launch the app&lt;br /&gt;
&lt;br /&gt;
== Submission/Pull Requests ==&lt;br /&gt;
&lt;br /&gt;
There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. In the interim, we shared our repo with Josh, whose reply was &amp;quot;this looks really great! Thanks for tackling it!&amp;quot;&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/OSS_M1706_Tracking_intermittent_test_failures_over_time&amp;diff=107599</id>
		<title>CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/OSS_M1706_Tracking_intermittent_test_failures_over_time&amp;diff=107599"/>
		<updated>2017-03-30T14:43:55Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Test Plan */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
This wiki provides details on new functionality programmed for the Servo OSS project.&lt;br /&gt;
&lt;br /&gt;
===Background===&lt;br /&gt;
&amp;quot;[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races.&amp;quot; Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely. &lt;br /&gt;
&lt;br /&gt;
===Motivation===&lt;br /&gt;
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. The [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project request] made is for a [http://flask.pocoo.org/docs/0.12/ Flask] service using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7]. The intermittent test failure tracker stores information regarding a test that fails intermittently and also provides means to quickly query for tests that have failed.&lt;br /&gt;
&lt;br /&gt;
===Tasks===&lt;br /&gt;
The intermittent test failure tracker initial steps (for the OSS project) include:&lt;br /&gt;
* Build a Flask service &lt;br /&gt;
* Use a JSON file to store information&lt;br /&gt;
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number&lt;br /&gt;
* Query the store results given a particular test file name&lt;br /&gt;
* Use the known intermittent issue tracker as an example of a Simple flask server &lt;br /&gt;
&lt;br /&gt;
Subsequent steps (for the final project) include:&lt;br /&gt;
* Add ability to query the service by a date range, to find out which were occurred the most often&lt;br /&gt;
* Build an HTML front-end to the service that queries using JS and reports the results&lt;br /&gt;
** Links to GitHub&lt;br /&gt;
** Sorting&lt;br /&gt;
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered&lt;br /&gt;
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
&lt;br /&gt;
===Design Pattern===&lt;br /&gt;
&lt;br /&gt;
The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller &amp;quot;services&amp;quot; and applies the services to the topmost &amp;quot;layer&amp;quot; of the project for which they are needed.&lt;br /&gt;
&lt;br /&gt;
===Application Flow===&lt;br /&gt;
&lt;br /&gt;
==== Saving a Test ====&lt;br /&gt;
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
                    +---------------------------------------------+&lt;br /&gt;
                    |       Intermittent Test Failure Tracker     |&lt;br /&gt;
                    |                                             |&lt;br /&gt;
+--------------+    | +-----------+      +---------+    +------+  |&lt;br /&gt;
|              |    | |           |      |         |    |      |  |      +--------+&lt;br /&gt;
|    Servo     |    | |           |      |         |    |      |  |      |        |&lt;br /&gt;
|    Build     +------&amp;gt;  webhook  +------&amp;gt; handler +----&amp;gt;  db  +---------&amp;gt;  json  |&lt;br /&gt;
|    Server    |    | |           |      |         |    |      |  |      |  file  |&lt;br /&gt;
|              |    | |           |      |         |    |      |  |      |        |&lt;br /&gt;
+--------------+    | +-----------+      +---------+    +------+  |      +--------+&lt;br /&gt;
                    |                                             |&lt;br /&gt;
                    +---------------------------------------------+&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Implementation ==&lt;br /&gt;
The implementation is entirely influenced by the request, the Servo team clearly defines what the service should do and how it would be made.&lt;br /&gt;
&lt;br /&gt;
=== Data model ===&lt;br /&gt;
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; &lt;br /&gt;
|-&lt;br /&gt;
! Name&lt;br /&gt;
! Type&lt;br /&gt;
! Description&lt;br /&gt;
|-&lt;br /&gt;
| test_file&lt;br /&gt;
| String&lt;br /&gt;
| Name of the intermittent test file &lt;br /&gt;
|-&lt;br /&gt;
| platform&lt;br /&gt;
| String&lt;br /&gt;
| Platform the test failed on&lt;br /&gt;
|-&lt;br /&gt;
| builder&lt;br /&gt;
| String&lt;br /&gt;
| The test machine (builder) the test failed on&lt;br /&gt;
|-&lt;br /&gt;
| number&lt;br /&gt;
| Integer&lt;br /&gt;
| The GitHub pull request number&lt;br /&gt;
|-&lt;br /&gt;
| fail_date&lt;br /&gt;
| ISO date (String)&lt;br /&gt;
| Date of the failure&lt;br /&gt;
|}&lt;br /&gt;
=== Datastore ===&lt;br /&gt;
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human readable.&lt;br /&gt;
&lt;br /&gt;
=== Flask Service ===&lt;br /&gt;
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes:&lt;br /&gt;
  &lt;br /&gt;
  @app.route('/')&lt;br /&gt;
  def index():&lt;br /&gt;
    return 'Index page'&lt;br /&gt;
  &lt;br /&gt;
  @app.route('/user/&amp;lt;username&amp;gt;')&lt;br /&gt;
  def show_user(username):&lt;br /&gt;
    return db.lookup(username)&lt;br /&gt;
&lt;br /&gt;
The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
=== Functional Testing ===&lt;br /&gt;
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.&lt;br /&gt;
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.&lt;br /&gt;
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records. &lt;br /&gt;
All usable for thorough integration testing.&lt;br /&gt;
&lt;br /&gt;
===Unit Testing===&lt;br /&gt;
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. All unit tests are in tests.py.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
! colspan=&amp;quot;3&amp;quot; | Unit Test Summary&lt;br /&gt;
|-&lt;br /&gt;
! Test Purpose&lt;br /&gt;
! Functional Tested&lt;br /&gt;
! Parameters&lt;br /&gt;
|-&lt;br /&gt;
| Add a record to a database &lt;br /&gt;
| db.add&lt;br /&gt;
| params[:self, :test_file, :platform, :builder, :number, :fail_date]&lt;br /&gt;
|-&lt;br /&gt;
| Delete a record from database&lt;br /&gt;
| db.remove&lt;br /&gt;
| params[:test_file]&lt;br /&gt;
|-&lt;br /&gt;
| Record a new Intermittent failure&lt;br /&gt;
| handlers.record&lt;br /&gt;
| params[:db, :test_file, :platform, :builder, :number]&lt;br /&gt;
|-&lt;br /&gt;
| Query the Intermittent failure records &lt;br /&gt;
| handlers.query&lt;br /&gt;
| params[:db, :test_file]&lt;br /&gt;
|-&lt;br /&gt;
| Record a new Intermittent failure, test invalid values - 4 tests for blanks for each input item&lt;br /&gt;
| handlers.record&lt;br /&gt;
| params[:db, :test_file, :platform, :builder, :number]&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
====Running Unit Tests and the App====&lt;br /&gt;
&lt;br /&gt;
Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo]&lt;br /&gt;
&lt;br /&gt;
=====To Run Unit Tests=====&lt;br /&gt;
* In the cloned repo folder, use the command &amp;lt;code&amp;gt;python test.py&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=====To Run The App Locally=====&lt;br /&gt;
* In the cloned repo folder, use the command &amp;lt;code&amp;gt;python -m flask_server&amp;lt;/code&amp;gt;&lt;br /&gt;
* Go to http://localhost:5000 to launch the app&lt;br /&gt;
&lt;br /&gt;
== Submission/Pull Requests ==&lt;br /&gt;
&lt;br /&gt;
There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. In the interim, we shared our repo with Josh, whose reply was &amp;quot;this looks really great! Thanks for tackling it!&amp;quot;&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/OSS_M1706_Tracking_intermittent_test_failures_over_time&amp;diff=107598</id>
		<title>CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/OSS_M1706_Tracking_intermittent_test_failures_over_time&amp;diff=107598"/>
		<updated>2017-03-30T13:52:47Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Submission/Pull Requests */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
This wiki provides details on new functionality programmed for the Servo OSS project.&lt;br /&gt;
&lt;br /&gt;
===Background===&lt;br /&gt;
&amp;quot;[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races.&amp;quot; Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely. &lt;br /&gt;
&lt;br /&gt;
===Motivation===&lt;br /&gt;
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. The [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project request] made is for a [http://flask.pocoo.org/docs/0.12/ Flask] service using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7]. The intermittent test failure tracker stores information regarding a test that fails intermittently and also provides means to quickly query for tests that have failed.&lt;br /&gt;
&lt;br /&gt;
===Tasks===&lt;br /&gt;
The intermittent test failure tracker initial steps (for the OSS project) include:&lt;br /&gt;
* Build a Flask service &lt;br /&gt;
* Use a JSON file to store information&lt;br /&gt;
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number&lt;br /&gt;
* Query the store results given a particular test file name&lt;br /&gt;
* Use the known intermittent issue tracker as an example of a Simple flask server &lt;br /&gt;
&lt;br /&gt;
Subsequent steps (for the final project) include:&lt;br /&gt;
* Add ability to query the service by a date range, to find out which were occurred the most often&lt;br /&gt;
* Build an HTML front-end to the service that queries using JS and reports the results&lt;br /&gt;
** Links to GitHub&lt;br /&gt;
** Sorting&lt;br /&gt;
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered&lt;br /&gt;
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
&lt;br /&gt;
===Design Pattern===&lt;br /&gt;
&lt;br /&gt;
The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller &amp;quot;services&amp;quot; and applies the services to the topmost &amp;quot;layer&amp;quot; of the project for which they are needed.&lt;br /&gt;
&lt;br /&gt;
===Application Flow===&lt;br /&gt;
&lt;br /&gt;
==== Saving a Test ====&lt;br /&gt;
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
                    +---------------------------------------------+&lt;br /&gt;
                    |       Intermittent Test Failure Tracker     |&lt;br /&gt;
                    |                                             |&lt;br /&gt;
+--------------+    | +-----------+      +---------+    +------+  |&lt;br /&gt;
|              |    | |           |      |         |    |      |  |      +--------+&lt;br /&gt;
|    Servo     |    | |           |      |         |    |      |  |      |        |&lt;br /&gt;
|    Build     +------&amp;gt;  webhook  +------&amp;gt; handler +----&amp;gt;  db  +---------&amp;gt;  json  |&lt;br /&gt;
|    Server    |    | |           |      |         |    |      |  |      |  file  |&lt;br /&gt;
|              |    | |           |      |         |    |      |  |      |        |&lt;br /&gt;
+--------------+    | +-----------+      +---------+    +------+  |      +--------+&lt;br /&gt;
                    |                                             |&lt;br /&gt;
                    +---------------------------------------------+&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Implementation ==&lt;br /&gt;
The implementation is entirely influenced by the request, the Servo team clearly defines what the service should do and how it would be made.&lt;br /&gt;
&lt;br /&gt;
=== Data model ===&lt;br /&gt;
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; &lt;br /&gt;
|-&lt;br /&gt;
! Name&lt;br /&gt;
! Type&lt;br /&gt;
! Description&lt;br /&gt;
|-&lt;br /&gt;
| test_file&lt;br /&gt;
| String&lt;br /&gt;
| Name of the intermittent test file &lt;br /&gt;
|-&lt;br /&gt;
| platform&lt;br /&gt;
| String&lt;br /&gt;
| Platform the test failed on&lt;br /&gt;
|-&lt;br /&gt;
| builder&lt;br /&gt;
| String&lt;br /&gt;
| The test machine (builder) the test failed on&lt;br /&gt;
|-&lt;br /&gt;
| number&lt;br /&gt;
| Integer&lt;br /&gt;
| The GitHub pull request number&lt;br /&gt;
|-&lt;br /&gt;
| fail_date&lt;br /&gt;
| ISO date (String)&lt;br /&gt;
| Date of the failure&lt;br /&gt;
|}&lt;br /&gt;
=== Datastore ===&lt;br /&gt;
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human readable.&lt;br /&gt;
&lt;br /&gt;
=== Flask Service ===&lt;br /&gt;
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes:&lt;br /&gt;
  &lt;br /&gt;
  @app.route('/')&lt;br /&gt;
  def index():&lt;br /&gt;
    return 'Index page'&lt;br /&gt;
  &lt;br /&gt;
  @app.route('/user/&amp;lt;username&amp;gt;')&lt;br /&gt;
  def show_user(username):&lt;br /&gt;
    return db.lookup(username)&lt;br /&gt;
&lt;br /&gt;
The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
=== Functional Testing ===&lt;br /&gt;
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.&lt;br /&gt;
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.&lt;br /&gt;
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records. &lt;br /&gt;
All usable for thorough integration testing.&lt;br /&gt;
&lt;br /&gt;
===Unit Testing===&lt;br /&gt;
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. &lt;br /&gt;
&lt;br /&gt;
Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo]&lt;br /&gt;
&lt;br /&gt;
=====To Run Unit Tests=====&lt;br /&gt;
* In the cloned repo folder, use the command &amp;lt;code&amp;gt;python test.py&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=====To Run The App Locally=====&lt;br /&gt;
* In the cloned repo folder, use the command &amp;lt;code&amp;gt;python -m flask_server&amp;lt;/code&amp;gt;&lt;br /&gt;
* Go to http://localhost:5000 to launch the app&lt;br /&gt;
&lt;br /&gt;
== Submission/Pull Requests ==&lt;br /&gt;
&lt;br /&gt;
There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. In the interim, we shared our repo with Josh, whose reply was &amp;quot;this looks really great! Thanks for tackling it!&amp;quot;&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/OSS_M1706_Tracking_intermittent_test_failures_over_time&amp;diff=107597</id>
		<title>CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/OSS_M1706_Tracking_intermittent_test_failures_over_time&amp;diff=107597"/>
		<updated>2017-03-30T13:51:37Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Submission/Pull Requests */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
This wiki provides details on new functionality programmed for the Servo OSS project.&lt;br /&gt;
&lt;br /&gt;
===Background===&lt;br /&gt;
&amp;quot;[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races.&amp;quot; Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely. &lt;br /&gt;
&lt;br /&gt;
===Motivation===&lt;br /&gt;
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. The [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project request] made is for a [http://flask.pocoo.org/docs/0.12/ Flask] service using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7]. The intermittent test failure tracker stores information regarding a test that fails intermittently and also provides means to quickly query for tests that have failed.&lt;br /&gt;
&lt;br /&gt;
===Tasks===&lt;br /&gt;
The intermittent test failure tracker initial steps (for the OSS project) include:&lt;br /&gt;
* Build a Flask service &lt;br /&gt;
* Use a JSON file to store information&lt;br /&gt;
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number&lt;br /&gt;
* Query the store results given a particular test file name&lt;br /&gt;
* Use the known intermittent issue tracker as an example of a Simple flask server &lt;br /&gt;
&lt;br /&gt;
Subsequent steps (for the final project) include:&lt;br /&gt;
* Add ability to query the service by a date range, to find out which were occurred the most often&lt;br /&gt;
* Build an HTML front-end to the service that queries using JS and reports the results&lt;br /&gt;
** Links to GitHub&lt;br /&gt;
** Sorting&lt;br /&gt;
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered&lt;br /&gt;
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
&lt;br /&gt;
===Design Pattern===&lt;br /&gt;
&lt;br /&gt;
The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller &amp;quot;services&amp;quot; and applies the services to the topmost &amp;quot;layer&amp;quot; of the project for which they are needed.&lt;br /&gt;
&lt;br /&gt;
===Application Flow===&lt;br /&gt;
&lt;br /&gt;
==== Saving a Test ====&lt;br /&gt;
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
                    +---------------------------------------------+&lt;br /&gt;
                    |       Intermittent Test Failure Tracker     |&lt;br /&gt;
                    |                                             |&lt;br /&gt;
+--------------+    | +-----------+      +---------+    +------+  |&lt;br /&gt;
|              |    | |           |      |         |    |      |  |      +--------+&lt;br /&gt;
|    Servo     |    | |           |      |         |    |      |  |      |        |&lt;br /&gt;
|    Build     +------&amp;gt;  webhook  +------&amp;gt; handler +----&amp;gt;  db  +---------&amp;gt;  json  |&lt;br /&gt;
|    Server    |    | |           |      |         |    |      |  |      |  file  |&lt;br /&gt;
|              |    | |           |      |         |    |      |  |      |        |&lt;br /&gt;
+--------------+    | +-----------+      +---------+    +------+  |      +--------+&lt;br /&gt;
                    |                                             |&lt;br /&gt;
                    +---------------------------------------------+&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Implementation ==&lt;br /&gt;
The implementation is entirely influenced by the request, the Servo team clearly defines what the service should do and how it would be made.&lt;br /&gt;
&lt;br /&gt;
=== Data model ===&lt;br /&gt;
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; &lt;br /&gt;
|-&lt;br /&gt;
! Name&lt;br /&gt;
! Type&lt;br /&gt;
! Description&lt;br /&gt;
|-&lt;br /&gt;
| test_file&lt;br /&gt;
| String&lt;br /&gt;
| Name of the intermittent test file &lt;br /&gt;
|-&lt;br /&gt;
| platform&lt;br /&gt;
| String&lt;br /&gt;
| Platform the test failed on&lt;br /&gt;
|-&lt;br /&gt;
| builder&lt;br /&gt;
| String&lt;br /&gt;
| The test machine (builder) the test failed on&lt;br /&gt;
|-&lt;br /&gt;
| number&lt;br /&gt;
| Integer&lt;br /&gt;
| The GitHub pull request number&lt;br /&gt;
|-&lt;br /&gt;
| fail_date&lt;br /&gt;
| ISO date (String)&lt;br /&gt;
| Date of the failure&lt;br /&gt;
|}&lt;br /&gt;
=== Datastore ===&lt;br /&gt;
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human readable.&lt;br /&gt;
&lt;br /&gt;
=== Flask Service ===&lt;br /&gt;
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes:&lt;br /&gt;
  &lt;br /&gt;
  @app.route('/')&lt;br /&gt;
  def index():&lt;br /&gt;
    return 'Index page'&lt;br /&gt;
  &lt;br /&gt;
  @app.route('/user/&amp;lt;username&amp;gt;')&lt;br /&gt;
  def show_user(username):&lt;br /&gt;
    return db.lookup(username)&lt;br /&gt;
&lt;br /&gt;
The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
=== Functional Testing ===&lt;br /&gt;
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.&lt;br /&gt;
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.&lt;br /&gt;
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records. &lt;br /&gt;
All usable for thorough integration testing.&lt;br /&gt;
&lt;br /&gt;
===Unit Testing===&lt;br /&gt;
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. &lt;br /&gt;
&lt;br /&gt;
Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo]&lt;br /&gt;
&lt;br /&gt;
=====To Run Unit Tests=====&lt;br /&gt;
* In the cloned repo folder, use the command &amp;lt;code&amp;gt;python test.py&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=====To Run The App Locally=====&lt;br /&gt;
* In the cloned repo folder, use the command &amp;lt;code&amp;gt;python -m flask_server&amp;lt;/code&amp;gt;&lt;br /&gt;
* Go to http://localhost:5000 to launch the app&lt;br /&gt;
&lt;br /&gt;
== Submission/Pull Requests ==&lt;br /&gt;
&lt;br /&gt;
There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. We shared our repo with Josh, whose reply was &amp;quot;this looks really great! Thanks for tackling it!&amp;quot;&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/OSS_M1706_Tracking_intermittent_test_failures_over_time&amp;diff=107585</id>
		<title>CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/OSS_M1706_Tracking_intermittent_test_failures_over_time&amp;diff=107585"/>
		<updated>2017-03-30T02:48:36Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Test Plan */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
This wiki provides details on new functionality programmed for the Servo OSS project.&lt;br /&gt;
&lt;br /&gt;
===Background===&lt;br /&gt;
&amp;quot;[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races.&amp;quot; Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely. &lt;br /&gt;
&lt;br /&gt;
===Motivation===&lt;br /&gt;
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. The [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project request] made is for a [http://flask.pocoo.org/docs/0.12/ Flask] service using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7]. The intermittent test failure tracker stores information regarding a test that fails intermittently and also provides means to quickly query for tests that have failed.&lt;br /&gt;
&lt;br /&gt;
===Tasks===&lt;br /&gt;
The intermittent test failure tracker initial steps (for the OSS project) include:&lt;br /&gt;
* Build a Flask service &lt;br /&gt;
* Use a JSON file to store information&lt;br /&gt;
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number&lt;br /&gt;
* Query the store results given a particular test file name&lt;br /&gt;
* Use the known intermittent issue tracker as an example of a Simple flask server &lt;br /&gt;
&lt;br /&gt;
Subsequent steps (for the final project) include:&lt;br /&gt;
* Add ability to query the service by a date range, to find out which were occurred the most often&lt;br /&gt;
* Build an HTML front-end to the service that queries using JS and reports the results&lt;br /&gt;
** Links to GitHub&lt;br /&gt;
** Sorting&lt;br /&gt;
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered&lt;br /&gt;
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
&lt;br /&gt;
===Design Pattern===&lt;br /&gt;
&lt;br /&gt;
The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller &amp;quot;services&amp;quot; and applies the services to the topmost &amp;quot;layer&amp;quot; of the project for which they are needed.&lt;br /&gt;
&lt;br /&gt;
===Application Flow===&lt;br /&gt;
&lt;br /&gt;
==== Saving a Test ====&lt;br /&gt;
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
                    +---------------------------------------------+&lt;br /&gt;
                    |       Intermittent Test Failure Tracker     |&lt;br /&gt;
                    |                                             |&lt;br /&gt;
+--------------+    | +-----------+      +---------+    +------+  |&lt;br /&gt;
|              |    | |           |      |         |    |      |  |      +--------+&lt;br /&gt;
|    Servo     |    | |           |      |         |    |      |  |      |        |&lt;br /&gt;
|    Build     +------&amp;gt;  webhook  +------&amp;gt; handler +----&amp;gt;  db  +---------&amp;gt;  json  |&lt;br /&gt;
|    Server    |    | |           |      |         |    |      |  |      |  file  |&lt;br /&gt;
|              |    | |           |      |         |    |      |  |      |        |&lt;br /&gt;
+--------------+    | +-----------+      +---------+    +------+  |      +--------+&lt;br /&gt;
                    |                                             |&lt;br /&gt;
                    +---------------------------------------------+&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Implementation ==&lt;br /&gt;
The implementation is entirely influenced by the request, the Servo team clearly defines what the service should do and how it would be made.&lt;br /&gt;
&lt;br /&gt;
=== Data model ===&lt;br /&gt;
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; &lt;br /&gt;
|-&lt;br /&gt;
! Name&lt;br /&gt;
! Type&lt;br /&gt;
! Description&lt;br /&gt;
|-&lt;br /&gt;
| test_file&lt;br /&gt;
| String&lt;br /&gt;
| Name of the intermittent test file &lt;br /&gt;
|-&lt;br /&gt;
| platform&lt;br /&gt;
| String&lt;br /&gt;
| Platform the test failed on&lt;br /&gt;
|-&lt;br /&gt;
| builder&lt;br /&gt;
| String&lt;br /&gt;
| The test machine (builder) the test failed on&lt;br /&gt;
|-&lt;br /&gt;
| number&lt;br /&gt;
| Integer&lt;br /&gt;
| The GitHub pull request number&lt;br /&gt;
|-&lt;br /&gt;
| fail_date&lt;br /&gt;
| ISO date (String)&lt;br /&gt;
| Date of the failure&lt;br /&gt;
|}&lt;br /&gt;
=== Datastore ===&lt;br /&gt;
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human readable.&lt;br /&gt;
&lt;br /&gt;
=== Flask Service ===&lt;br /&gt;
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes:&lt;br /&gt;
  &lt;br /&gt;
  @app.route('/')&lt;br /&gt;
  def index():&lt;br /&gt;
    return 'Index page'&lt;br /&gt;
  &lt;br /&gt;
  @app.route('/user/&amp;lt;username&amp;gt;')&lt;br /&gt;
  def show_user(username):&lt;br /&gt;
    return db.lookup(username)&lt;br /&gt;
&lt;br /&gt;
The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
=== Functional Testing ===&lt;br /&gt;
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.&lt;br /&gt;
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.&lt;br /&gt;
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records. &lt;br /&gt;
All usable for thorough integration testing.&lt;br /&gt;
&lt;br /&gt;
===Unit Testing===&lt;br /&gt;
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. &lt;br /&gt;
&lt;br /&gt;
Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo]&lt;br /&gt;
&lt;br /&gt;
=====To Run Unit Tests=====&lt;br /&gt;
* In the cloned repo folder, use the command &amp;lt;code&amp;gt;python test.py&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=====To Run The App Locally=====&lt;br /&gt;
* In the cloned repo folder, use the command &amp;lt;code&amp;gt;python -m flask_server&amp;lt;/code&amp;gt;&lt;br /&gt;
* Go to http://localhost:5000 to launch the app&lt;br /&gt;
&lt;br /&gt;
== Submission/Pull Requests ==&lt;br /&gt;
&lt;br /&gt;
There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/OSS_M1706_Tracking_intermittent_test_failures_over_time&amp;diff=107584</id>
		<title>CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/OSS_M1706_Tracking_intermittent_test_failures_over_time&amp;diff=107584"/>
		<updated>2017-03-30T02:32:36Z</updated>

		<summary type="html">&lt;p&gt;Eleill: /* Functional Testing */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
This wiki provides details on new functionality programmed for the Servo OSS project.&lt;br /&gt;
&lt;br /&gt;
===Background===&lt;br /&gt;
&amp;quot;[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races.&amp;quot; Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely. &lt;br /&gt;
&lt;br /&gt;
===Motivation===&lt;br /&gt;
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. The [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project request] made is for a [http://flask.pocoo.org/docs/0.12/ Flask] service using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7]. The intermittent test failure tracker stores information regarding a test that fails intermittently and also provides means to quickly query for tests that have failed.&lt;br /&gt;
&lt;br /&gt;
===Tasks===&lt;br /&gt;
The intermittent test failure tracker initial steps (for the OSS project) include:&lt;br /&gt;
* Build a Flask service &lt;br /&gt;
* Use a JSON file to store information&lt;br /&gt;
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number&lt;br /&gt;
* Query the store results given a particular test file name&lt;br /&gt;
* Use the known intermittent issue tracker as an example of a Simple flask server &lt;br /&gt;
&lt;br /&gt;
Subsequent steps (for the final project) include:&lt;br /&gt;
* Add ability to query the service by a date range, to find out which were occurred the most often&lt;br /&gt;
* Build an HTML front-end to the service that queries using JS and reports the results&lt;br /&gt;
** Links to GitHub&lt;br /&gt;
** Sorting&lt;br /&gt;
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered&lt;br /&gt;
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
&lt;br /&gt;
===Design Pattern===&lt;br /&gt;
&lt;br /&gt;
The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller &amp;quot;services&amp;quot; and applies the services to the topmost &amp;quot;layer&amp;quot; of the project for which they are needed.&lt;br /&gt;
&lt;br /&gt;
===Application Flow===&lt;br /&gt;
&lt;br /&gt;
==== Saving a Test ====&lt;br /&gt;
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
                    +---------------------------------------------+&lt;br /&gt;
                    |       Intermittent Test Failure Tracker     |&lt;br /&gt;
                    |                                             |&lt;br /&gt;
+--------------+    | +-----------+      +---------+    +------+  |&lt;br /&gt;
|              |    | |           |      |         |    |      |  |      +--------+&lt;br /&gt;
|    Servo     |    | |           |      |         |    |      |  |      |        |&lt;br /&gt;
|    Build     +------&amp;gt;  webhook  +------&amp;gt; handler +----&amp;gt;  db  +---------&amp;gt;  json  |&lt;br /&gt;
|    Server    |    | |           |      |         |    |      |  |      |  file  |&lt;br /&gt;
|              |    | |           |      |         |    |      |  |      |        |&lt;br /&gt;
+--------------+    | +-----------+      +---------+    +------+  |      +--------+&lt;br /&gt;
                    |                                             |&lt;br /&gt;
                    +---------------------------------------------+&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Implementation ==&lt;br /&gt;
The implementation is entirely influenced by the request, the Servo team clearly defines what the service should do and how it would be made.&lt;br /&gt;
&lt;br /&gt;
=== Data model ===&lt;br /&gt;
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; &lt;br /&gt;
|-&lt;br /&gt;
! Name&lt;br /&gt;
! Type&lt;br /&gt;
! Description&lt;br /&gt;
|-&lt;br /&gt;
| test_file&lt;br /&gt;
| String&lt;br /&gt;
| Name of the intermittent test file &lt;br /&gt;
|-&lt;br /&gt;
| platform&lt;br /&gt;
| String&lt;br /&gt;
| Platform the test failed on&lt;br /&gt;
|-&lt;br /&gt;
| builder&lt;br /&gt;
| String&lt;br /&gt;
| The test machine (builder) the test failed on&lt;br /&gt;
|-&lt;br /&gt;
| number&lt;br /&gt;
| Integer&lt;br /&gt;
| The GitHub pull request number&lt;br /&gt;
|-&lt;br /&gt;
| fail_date&lt;br /&gt;
| ISO date (String)&lt;br /&gt;
| Date of the failure&lt;br /&gt;
|}&lt;br /&gt;
=== Datastore ===&lt;br /&gt;
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human readable.&lt;br /&gt;
&lt;br /&gt;
=== Flask Service ===&lt;br /&gt;
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes:&lt;br /&gt;
  &lt;br /&gt;
  @app.route('/')&lt;br /&gt;
  def index():&lt;br /&gt;
    return 'Index page'&lt;br /&gt;
  &lt;br /&gt;
  @app.route('/user/&amp;lt;username&amp;gt;')&lt;br /&gt;
  def show_user(username):&lt;br /&gt;
    return db.lookup(username)&lt;br /&gt;
&lt;br /&gt;
The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
=== Functional Testing ===&lt;br /&gt;
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.&lt;br /&gt;
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.&lt;br /&gt;
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records.  &lt;br /&gt;
All usable for thorough integration testing.&lt;br /&gt;
&lt;br /&gt;
===Unit Testing===&lt;br /&gt;
The unit tests included in the code exercise the major functions of this system.  The tests exercise the addition of a record into the database, the removal of a record given a filename and finally the retrieval of a record.&lt;br /&gt;
&lt;br /&gt;
== Submission/Pull Requests ==&lt;br /&gt;
&lt;br /&gt;
There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/OSS_M1706_Tracking_intermittent_test_failures_over_time&amp;diff=107565</id>
		<title>CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/OSS_M1706_Tracking_intermittent_test_failures_over_time&amp;diff=107565"/>
		<updated>2017-03-29T18:52:21Z</updated>

		<summary type="html">&lt;p&gt;Eleill: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
This wiki provides details on new functionality programmed for the Servo OSS project.&lt;br /&gt;
&lt;br /&gt;
===Background===&lt;br /&gt;
&amp;quot;[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races.&amp;quot; Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely. &lt;br /&gt;
&lt;br /&gt;
===Motivation===&lt;br /&gt;
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. The [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project request] made is for a [http://flask.pocoo.org/docs/0.12/ Flask] service using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7]. The intermittent test failure tracker stores information regarding a test that fails intermittently and also provides means to quickly query for tests that have failed.&lt;br /&gt;
&lt;br /&gt;
===Tasks===&lt;br /&gt;
The intermittent test failure tracker initial steps (for the OSS project) include:&lt;br /&gt;
* Build a Flask service &lt;br /&gt;
* Use a JSON file to store information&lt;br /&gt;
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number&lt;br /&gt;
* Query the store results given a particular test file name&lt;br /&gt;
* Use the known intermittent issue tracker as an example of a Simple flask server &lt;br /&gt;
&lt;br /&gt;
Subsequent steps (for the final project) include:&lt;br /&gt;
* Add ability to query the service by a date range, to find out which were occurred the most often&lt;br /&gt;
* Build an HTML front-end to the service that queries using JS and reports the results&lt;br /&gt;
** Links to GitHub&lt;br /&gt;
** Sorting&lt;br /&gt;
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered&lt;br /&gt;
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
&lt;br /&gt;
===Design Pattern===&lt;br /&gt;
&lt;br /&gt;
The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller &amp;quot;services&amp;quot; and applies the services to the topmost &amp;quot;layer&amp;quot; of the project for which they are needed.&lt;br /&gt;
&lt;br /&gt;
===Application Flow===&lt;br /&gt;
&lt;br /&gt;
==== Saving a Test ====&lt;br /&gt;
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
                    +---------------------------------------------+&lt;br /&gt;
                    |       Intermittent Test Failure Tracker     |&lt;br /&gt;
                    |                                             |&lt;br /&gt;
+--------------+    | +-----------+      +---------+    +------+  |&lt;br /&gt;
|              |    | |           |      |         |    |      |  |      +--------+&lt;br /&gt;
|    Servo     |    | |           |      |         |    |      |  |      |        |&lt;br /&gt;
|    Build     +------&amp;gt;  webhook  +------&amp;gt; handler +----&amp;gt;  db  +---------&amp;gt;  json  |&lt;br /&gt;
|    Server    |    | |           |      |         |    |      |  |      |  file  |&lt;br /&gt;
|              |    | |           |      |         |    |      |  |      |        |&lt;br /&gt;
+--------------+    | +-----------+      +---------+    +------+  |      +--------+&lt;br /&gt;
                    |                                             |&lt;br /&gt;
                    +---------------------------------------------+&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Implementation ==&lt;br /&gt;
The implementation is entirely influenced by the request, the Servo team clearly defines what the service should do and how it would be made.&lt;br /&gt;
&lt;br /&gt;
=== Data model ===&lt;br /&gt;
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; &lt;br /&gt;
|-&lt;br /&gt;
! Name&lt;br /&gt;
! Type&lt;br /&gt;
! Description&lt;br /&gt;
|-&lt;br /&gt;
| test_file&lt;br /&gt;
| String&lt;br /&gt;
| Name of the intermittent test file &lt;br /&gt;
|-&lt;br /&gt;
| platform&lt;br /&gt;
| String&lt;br /&gt;
| Platform the test failed on&lt;br /&gt;
|-&lt;br /&gt;
| builder&lt;br /&gt;
| String&lt;br /&gt;
| The test machine (builder) the test failed on&lt;br /&gt;
|-&lt;br /&gt;
| number&lt;br /&gt;
| Integer&lt;br /&gt;
| The GitHub pull request number&lt;br /&gt;
|-&lt;br /&gt;
| fail_date&lt;br /&gt;
| ISO date (String)&lt;br /&gt;
| Date of the failure&lt;br /&gt;
|}&lt;br /&gt;
=== Datastore ===&lt;br /&gt;
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human readable.&lt;br /&gt;
&lt;br /&gt;
=== Flask Service ===&lt;br /&gt;
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes:&lt;br /&gt;
  &lt;br /&gt;
  @app.route('/')&lt;br /&gt;
  def index():&lt;br /&gt;
    return 'Index page'&lt;br /&gt;
  &lt;br /&gt;
  @app.route('/user/&amp;lt;username&amp;gt;')&lt;br /&gt;
  def show_user(username):&lt;br /&gt;
    return db.lookup(username)&lt;br /&gt;
&lt;br /&gt;
The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.&lt;br /&gt;
&lt;br /&gt;
== Test Plan ==&lt;br /&gt;
&lt;br /&gt;
The sample [http://csc517oss.zachncst.com/ index page] is for illustrating the project's functionality only. The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records. &lt;br /&gt;
&lt;br /&gt;
== Submission/Pull Requests ==&lt;br /&gt;
&lt;br /&gt;
There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub.&lt;/div&gt;</summary>
		<author><name>Eleill</name></author>
	</entry>
</feed>