MarkUs Blog

MarkUs Developers Blog About Their Project

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

Leave a Reply