MarkUs Blog

MarkUs Developers Blog About Their Project

Archive for April, 2011

Punchlines for April 21, 2011

without comments

Karel Kahula


  • Still working on delete feature.
  • Working on logic for deleting assignments. (It’s a little tricky to completely remove an assignment)

Next Steps:

  • Finish delete feature


  • Unsure about some elements of the assignment model. Worried about leaving dangling references to assignments.

Oloruntobi Ogunbiyi

  • Incorporated all comments with regards to refactoring code and making modifications to role switching

Next Steps:

  • Testing


  • none

Misa Sakamoto


  • Userdocs + blog post up
  • Vivien’s code is still pending ship-it, but very close

Next Steps:

  • none


  • none

Yansong Zang


  • Just finished my finals and come back for MarkUs

Next Steps:

  • Get my dashboard task totally work.


  • none

Danesh Dadachanji


  • Exams are done!
  • Fixed an issue with my sham ruby gems that prevented me from running tests.
  • Changed to use blueprints instead of fixtures in my tests.

Next Steps

  • Make sure all the logic in my tests and asserts is correct.
  • Write a review


  • I was having some troubles with Sham and had to reinstall my rubygems to fix the problem (thank you Mike!)

Ibrahim Ishahin


  • Still working on drag and drop annotation categories.

Next Steps:

  • responding to some outstanding reviews.


  • work

Bertan Guven

Next Steps:

Written by misa

April 21st, 2011 at 1:48 pm

Userdocs updated for remark requests

without comments

This term, Vivien and I finished the remark request feature.

Instructors can:

  • allow/disallow remark requests per assignment
  • set due dates
  • specify remark request rules/instructions
  • comment on each student’s remark request
  • view old and new marks as they remark

Students can:

  • create and save remark requests, to edit later
  • submit remark requests to the instructor
  • cancel submitted remark requests
  • view old and new marks once the remark has been processed
  • view instructor’s comments on the remark request once the remark has been processed

The MarkUs Userdoc has been updated, and is available here:

Instructor and Student Guides have also been updated, and are available here:

Written by misa

April 14th, 2011 at 1:08 am

Posted in Documents,Remarks

April 7th – Wrap Up Meeting – Minutes

without comments

Danesh is currently testing the API but is a bit confused about the way that Severin tested some other API. He has been struggling with understanding shoulda functions. He also wrote a blog post containing information on the API for managing users. He would also get the information on his blog post up on the wiki.

Misa is currently waiting her review to pass.

Karen was wondering if the remark requests feature was ready to be demoed at Research In Action (RIA) showcase at the University of Toronto. However, the review request for the feature had not passed yet. Severin and Misa intend to coordinate to get the remark request feature up and running for the RIA demo.

Karel just finished classes and would be able to put in more time into Markus now. He is currently working on the functionality of deleting items and would get it done by the end of the week.

Bertan put up a review today and he is waiting for responses. Meanwhile he would be writing tests for the feature.

Tobi has been able to create a modal dialog for role switching. However, he has a problem with loading the index page of the user whom the admin is trying to assume the role of. The problem is with AJAX requests. He intends to fix the problem by tonight and would also finalize tests for the feature.

Ibrahim just finished fixing a bug in the annotation categories drag and drop. He would also be writing tests.

The UCOSP steering committee will be meeting next week to sort out most of the marks and other stuff, so Karen would like everyone to send her a note before the end of the week.

Written by Tobi

April 9th, 2011 at 8:07 pm

Punchlines for April 7

without comments

Danesh Dadachanji


  • Trying to wrap my head around the shoulda bundle and understand the context, setup and should formats that the current API tests follow.
  • I have all of the logic behind each test in my last blog post so moving it over should be quite simple.

Next Steps

  • Write a review for tests
  • Start working on respond_to, try to make it a separate issue from the current one first.

Road Blocks
As of Saturday, exams.

Misa Sakamato


  • waiting on ship-it
Next steps:
  • blog post to userdoc after ship-it
  • no review :/]

Karel Kahula

  • No change
Next Steps:
  • Start work on issue 8 again
  • None now that my other courses are finished! 😀
Bertan Guven

  • Finished righting the download yml functionality.
Next Steps
  • Work on editing the HTML part of it
  • Exams coming…….
Oloruntobi Ogunbiyi
  • Implemented modal dialog for role switching but have problems with loading the index page using AJAX requests
  • Wrote some tests
Next Steps:
  • Fixing the bug that causes the index page not to load
  • Understanding AJAX requests

Ibrahim Shahin


  • fixing new annotation category reload bug

Next Steps

  • Tests for annotation category drag and drop

Road Blocks

  • None 🙂

    Written by BertanGuven

    April 7th, 2011 at 1:22 pm

    User REST API

    without comments

    For those of you that need a little bit of background information on API, it’s what we use to send an HTTP request to the server to perform some standard HTTP tasks. The way you send an HTTP request to a MarkUs server is using the files located at


    I prefer using the python script so here’s an example of a request using it. Here’s an example of using the script in general. If you want specific examples, try looking at the help option.

    $ cd lib/tools
    # Display the help description
    $ python -h
    # Send a user HTTP request
    $ python -r REQUEST_TYPE -k /path/to/api/key.txt -u param1=value1 param2=value2...

    You need to have your API key stored somewhere in a text file. You can find it at the bottom of the index page once you’ve logged in (TAs and Admins only).
    RoR recognizes 4 requests:

    • GET
    • POST
    • PUT
    • DELETE

    The API that I implemented handles them with respect to the users in your current database.

    GET – Show user
    This displays a given user’s details using in-line text rendering. It takes in a key value of user_name=foo and will print out the user_name, first name, last name and the user’s type (admin/TA/student).

    POST – Create user
    This request creates a new user if it does not exist already. It checks this based solely on user_name You need to pass in the user_name, last_name, first_name and user_type.  The options for user_type are “admin”, “ta” or “student”. Passing in an existing user or invalid user_type causes an error.

    PUT – Update user
    Sends the server a request to update an existing user. You choose the user you want to update through the user_name key and update the attributes through first_name and last_name. The request also takes an optional new_user_name key that you can use to change the user’s user_name. If you don’t pass this, it will simply not change. If the user does not exist or any of the parameters

    DELETE – Delete user
    Seeing as you should never be deleting a user, the server just renders a 404.

    Everything seems to be running smoothly but I’m going to add some functional tests to make sure authentication is actually working and that each of the functions are doing what they are supposed to be doing. The ideas I’ve got so far are as follows.

    • Give an incorrect authentication key and check that the correct error is rendered.
    • Create a user using the API and then manually check for it in the database. Also assert that the attributes are correct.
    • Send a GET request for a newly created user and check that the response against a preformated string. Note that this will have to change if respond_to is implemented (see below).
    • Update the first and last name of a new user that I temporarily create. Check the database to see if they attributes changed but the user_name remained the same.
    • Update the user again, this time also changing the user_name. Assert that the database contains a user with the new user_name and correct attributes and also assert the old one no longer exists.

    Any other suggestions? I figured deleting doesn’t need an actual test because it renders the 404 when I try to send a DELETE request. I’d say that’s sufficient enough.

    For a future project, I’m going to try to implement the rails respond_to function that renders a specific format for GET, depending on the user’s wishes. The hope is that you can simply enter

    and it would automatically render XML. There are two approaches to this implementation, both of which use the respond_to function. The easier way is hopefully that RoR recognizes the extension and the call to an API and does it for you. This way it would just be checking the requested format. The slightly more complicated approach is to modify the HTTP request by adding an additional key value pair for an Accept key. This key:value would have to be added to the request header’s list so the easiest way to do that is directly through the script. I am open to any other suggestions though I won’t start working on this until I’m done testing.

    Here are examples for each of the requests, in case the general example wasn’t clear enough.

    $ cd markus_home/lib/tools
    # Create Doe, John - a student with user_name c5doejoh
    $ python -r POST -k api_key.txt -u http://localhost:3000/api/users user_name=c5doejoh last_name=Doe first_name=John user_type=student

    # Show user c5doejoh's details
    $ python -r GET -k api_key.txt -u http://localhost:3000/api/users user_name=c5doejoh

    # Update user c5doejoh's details, changing everything.
    $ python -r PUT -k api_key.txt -u http://localhost:3000/api/users user_name=c5doejoh last_name=Smith first_name=Steve user_type=ta new_user_name=c8smiths

    Written by Danesh

    April 7th, 2011 at 12:22 am

    March 31, 2011 IRC Meeting Minutes

    without comments

    Before the end of the term,  everyone should email Karen a little report consisting of what you accomplished this term, the current state of your work, what you plan to do to complete it, and a self-assessment. Remember to  include links to any blog posts you wrote.

    Misa will be writing a blog post about the userdocs as soon as she gets a ship it.

    Karel is very busy with school, and won’t be able to work on MarkUs until after the 6th.

    Yansong has stopped working on Markus for the time being. He will resume after his final exams.

    Ibrahim has a bit more work to do for his drag and drop annotation categories before the end of the term.

    Danesh has finished the marking state error bug and is implementing tests for the Users API.

    Tobi is wrapping up the role switching item and is writing tests and implementing a modal dialog for it.

    Bertan has been very busy and is working on converting ActiveRecords into YAML.

    There will be two more meetings, a regular one next week and the postmortem.

    There was a lot of talk about working on MarkUs after the term is over. I look forward to continuing to work with everyone staying on the project. 🙂

    Written by Ibrahim

    April 1st, 2011 at 1:56 am

    Posted in Meetings,Minutes