MarkUs Blog

MarkUs Developers Blog About Their Project

Archive for April, 2015

Remark System

without comments

My semester has been primarily refinements. During an earlier semester, as system for requesting remarks was put into place. Under that system, students could request a remark on any released assignment, and the marker would receive it, and be able to mark and add comments. However, there were some issues in this system, including features that had to be disabled. For instance, under the planned version, students could save their remark requests, then work on them later, without markers being able to see them. Under the current implementation, markers could see the in-progress request, and saving the request to work on it later would sometimes erase the student’s score for that assignment – a bit of a problem. As a stopgap, the saving feature had been completely disabled. One of my major orders of business was to fix these issues and enable the saving feature. Another issue in vein was a quality-of-life improvement for markers. Under ther current implementation, when a remark was requested, the marker could see what all the old scores were, but if they felt the original score was fair, they still had to go through and reenter all of the scores anyway. My fix here was to autopopulate the scores for the remark with the old mark, but the issue was timing. My initial versions crudely set the marks when the screen was loaded by the marker. This was problematic because if the marker went away, then had to log in and go back to the screen, they’d lose the marks when they reloaded. The (in retrospect) obvious fix was to instead set the marks when the remark request is submitted, since that’s when the second marks set appears in the database. Another fix for quality of life was fixing session expiry. Under the current system, your session could silently expire while you were working, then when you tried to save or submit, you’d lose your work and be booted to a login screen. So, I added a modal to warn you if your session was due to expire soon. This was tricky because Rails servers are very strictly RESTful – that is, they respond to actions the user takes. They do not initiate their own actions such as checking if a session has expired. Instead, I used a JQuery function to set up a repeating call to an action on the server, asking the server repeatedly to check if the session was due to expire. Then, I had to filter these checks out, so that they wouldn’t reset the session expiry (which would keep a session from ever timing out). There was also an issue that couldn’t be resolved; namely, we issue a HTTP 302 error when you try to go to a page and your session times out. This is because it gives us a silent redirect. Technically, the correct error for a session timeout would be HTTP 401 Unauthorized. However, because this is a 4xx code, browsers like to throw up a little “You are being redirected” screen. To get around this, I had a ridiculous bit of Javascript hackery, which returned a bit of HTML text with the 401. That text was a script, and the script, when loaded, shoved you back to the login silently using a bit of ERB (Embedded RuBy, being used in a Ruby file). While it worked, it was very un-Rails, confusing, and wasn’t obvious.

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

without comments

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

without comments

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


Screen Shot 2015-04-10 at 11.38.45 AM

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.

Screen Shot 2015-04-10 at 11.51.07 AM

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