# MarkUs Blog

MarkUs Developers Blog About Their Project

## Remark System

I went in to this project with no knowledge of anything in it. Markus runs on Ruby, Rails, JQuery, HTML, MVC pattern, RESTful services, and raw Javascript. Basically, I had none of these things. I’d never touched web development before (barring a small ‘computers’ class in elementary, where a high school student taught me how to link to images on other people’s web sites by reading and writing pure html in the 90’s). I had to give myself a crash course in Ruby and Rails in order to understand enough to begin reversing behaviours through observation. On top of that, I had to learn enough HTML to understand what was going on in the views, and pick up the Javascript and JQuery, since so many of my changes were concentrated on the views – also new to me, since I usually stick to back-end development. Overall, I’ve become a huge fan of Rails, and particularly Ruby. I found this project gave a great understanding of how (and why) MVC systems work the way they do, and really came to appreciate how easy it was to find what needed to be changed when I went looking – you could tell just by looking at if the issue was with data, behaviour, or appearance. Ruby has become one of my favourite languages, barring a few quirks which can lead to consistency issues (you can use begin/end or {/], your boolean logics can be !/&&/|| or not/and/or, and some other similar problems). However, this project was able to mitigate these problems with Hound, a program that hounds you if you try to submit changes that don’t follow the consistency standards. This was a great term for broadening my horizons and getting to experience web development, which I don’t really see taught at SFU.

Written by Christian Millar

April 16th, 2015 at 1:01 pm

## RSpec testing in MarkUs II

MarkUs is the robust and reliable application where testing is used as the main component to make sure those qualities persist. I knew nothing about testing before starting UCOSP this term in January of 2015. Besides the fact that testing is very important for the known reasons (Duh). When I began learning RSpec I realized the philosophy behind writing robust code: consider all the possibilities of how your code can be wrecked before writing it. Are you writing a form with a field prompting for user’s date of birth? Think about dates like 99/99/9999 or javascript code that might end up in that field. Crazy stuff happens, so it’s faulty to write code only assuming the best-case scenario where user actions are always coherent with the functionality implemented.

The Behavior Driven Development (BDD) seems very logical and even optimal for applications like MarkUs. But adopting it means that all the developers should have in-depth knowledge of how testing works. It’s seems unlikely to happen due to the distributive nature of the application and the fact that many people who work on it are coming and going just like me. After spending my term on MarkUs working with RSpec I can say for sure that I’m not even close at becoming pro at testing. So forget about BDD and let’s see what I’ve done over this term.

The tickets I was working on mainly concentrated around different sorts of testing. I started with the easiest kind that involved unit testing where you test a single function to make sure it produces appropriate results using arbitrary scenarios. Sometimes it’s difficult to come up with a good scenario. You have to think about what function supposed to do and test that, but then you also have to consider wild (not too wild) possibilities that could break the function. Writing passing a test is easy, but most of the time I was only satisfied when I was able to break something that resulted in failing test and required fixing.

That happened when I began working on CSV upload functionality for Simple Grade Entry form. The upload relies on rails library parsing methods that are not ideally robust to begin with. So it’s very important that the file passes all the checks before entering the parsing stage. My wild (but not too wild) failing scenarios included checking for: presence of EOF character, appropriate EOL characters, non-CSV files that are pretending they are CSV (sneaky spies!), etc. I also discovered that any file passed through CSV upload would overwrite the original template. Even though this functionality is required for other parts of MarkUs, I thought that it could potentially cause some troubles along the way. Now this concern is handled and corresponding RSpec tests are in place.

RSpec is a powerful testing framework that possesses both great readability and writability aspects. Although it’s not good enough on its own for html parsing (requires Nokogiri), and javascript parsing (requires Capybara/Selenium pair which is not a stable solution for vagrant box developers).  I also found out that RSpec is not multi-thread-friendly and because of that I was unable to finish the last issue that required testing forked processes. Nevertheless, there are currently efforts made by the RSpec core team and, hopefully, we will soon get the capability of testing parallel processes.

I greatly enjoyed working with this test framework and its object-building sister – FactoryGirl. The biggest challenge I was facing is understanding of sometimes complex relationships between different MarkUs entities. And in-depth understanding is required, because there is no way to even start testing without a good idea of how different elements co-operate with each other. And then you start building factories, which have to follow the rules of multiple associations, validation and other model requirements. Testing helps a developer to get almost intimate with the code, so I believe that this term I became not just a better coder, but improved as a programmer.

Written by Maryna Moskalenko

April 10th, 2015 at 8:22 pm

## Integrating MathJax

A feature commonly requested by markers was the ability to annotate student submissions with LaTeX like math. This has now been implemented!

Anywhere annotations exist markers can enter LaTeX like math thanks to MathJax. When creating an annotation the marker just needs to surround the math in a pair of dollar-sign symbols. The entire annotation shown in the image above is:

should actually be $$\lt \frac 1 2$$

As would be expected, students also see LaTeX like math when viewing an annotation with math in it. This math rendering system expands (and reinforces) the utility of Markus for theory-based courses such as calculus, discrete math or linear algebra.

In addition to the MathJax integration, markers can now preview their annotation prior to submitting it.

The preview functionality will help speedup the marking process for users unfamiliar with MathJax syntax. Instead of submitting an annotation, hovering over it and then editing it, markers can now preview exactly how their annotation will look once submitted. This also allows markers to preview rich HTML annotations with bolded and italicized text.

Written by Paymahn Moghadasian

April 10th, 2015 at 12:54 pm

Posted in New Feature