Application Link : https://shielded-caverns-97668.herokuapp.com/
The motivation behind the CSCE 625 Self Evaluation project is to help students in assessing their preparation for the graduate-level Artificial Intelligence course. This project can assist students in understanding the course prerequisites. By using this evaluation portal, the students can make an informed decision as to whether they are sufficiently prepared to register for the class.
The requirements for the project were provided by Dr. Duncan Walker, Professor, Texas A&M University. The key stakeholders of this project are prospective students, teaching assistants, and the course instructors.
As this was a legacy application, a majority of the work dealt with enhancing existing features or implementing architecture/design fixes. The key customer requirements were:
- Implementing Multiple-Choice Questions(MCQs)
- Supporting Mathematical equations in questions
- Automating grading/evaluation
- Setting up a password recovery system
Through this project, all the above requirements were met. The portal now supports Multiple-Choice Questions on top of the basic “Short Answer” questions. The feature to support Mathematical equations in Questions/Answers was done using the MathJax library. Automatic grading has been implemented for both MCQ and Short Answer questions in the Quiz module. In addition, the instructors now have the opportunity to reset “Lost Password”s.
Initial code is taken as it is from this repo - https://github.com/wagerpascal/team_froyo
Instructors:
- Can login and add/edit/update questions and topics
- Can choose between a multiple-choice question or short answer type question
- Can add math in the questions
- Can recover passwords
Students:
- Can take the quiz and evaluate their performance using the feedback and remarks generated at the end
- Can select the topics they want be tested on
- Can go through the questions like flashcards
We followed the development process which was introduced in the class itself where we wrote cucumber tests which were used as acceptance tests and RSpec tests which were used for function level testing. Since most of our features required making modifications to the existing product, many times we just had to add extra tests pertaining to our changes instead of writing the new feature/Rspec files from the start. However, many tests were missing, so during the course of development, we added a lot of new tests. We targeted about 1-2 user stories per iteration that allowed to make sure that we thoroughly test the features before deployment instead of adding tests towards the end to increase coverage.
To make sure that our production environment is clean, we used branch protection rules. We decided that no one should be allowed to directly push changes to “master” and hence we created rules that required developers to have their changes reviewed by at least two other developers. As a result, each developer would raise a pull request and upon being reviewed by two other developers, the changes will automatically get merged with the master branch. This process really helped us and most of the time our production environment was in a deployable state. None of the developers faced any major merge conflict issue too. We had a total of over 45 branches (some have been deleted) and 4 releases - one for each iteration.
Heroku does allow automatic deployment where we can specify our production branch and upon every merge/commit to that branch, Heroku will run some automatic scripts and deploy our latest changes. However, this feature never worked for us. We pointed the automatic deployment to our “master” branch, which we tried to keep clean, but the automation script always failed. We did spend some time to see the issue but it appeared to come because of the ruby version that we were using. Unfortunately, one of our team members had to always deploy changes manually because of this one time we thought that our latest changes have been deployed but during the demo to our customer, the latest changes were missing. We showed our development changes during that time which was working fine. Had this automatic deployment worked, we could have avoided this manual deployment.
We didn’t face any issues with the Development environments. However, the production instance in Heroku doesn’t provide a free SMTP service. Hence, we had to perform a workaround to support the Password Recovery feature.
The inline mathematical notation feature was implemented using the javascript library Mathjax. The choice of this library was made considering its LaTeX markup and its extensive documentation. The partial check for “Short Answer” questions was done using the fuzzy-string-match Ruby gem. We used SimpleCov to generate the coverage report of our Ruby code. SimpleCov provided a simple method for generating test coverage reports.
- Final Customer Interview : https://vimeo.com/304276474
- Application Demo : https://vimeo.com/305544529
- Pivotal tracker : https://www.pivotaltracker.com/n/projects/2200809
- Heroku App : https://shielded-caverns-97668.herokuapp.com/
- Even though addition of equations looked straightforward using the open-source library called MathJax, getting it to work correctly took us some time. We faced problems displaying equations during navigation between the questions.
- As Heroku doesn’t provide a free SMTP service, we came up with a workaround to support password recovery.
- The automatic deployment feature of Heroku never worked for us and we always had to perform manual deployment.