Archive for April, 2011
- Still working on delete feature.
- Working on logic for deleting assignments. (It’s a little tricky to completely remove an assignment)
- Finish delete feature
- Unsure about some elements of the assignment model. Worried about leaving dangling references to assignments.
- Incorporated all comments with regards to refactoring code and making modifications to role switching
- Userdocs + blog post up
- Vivien’s code is still pending ship-it, but very close
- Just finished my finals and come back for MarkUs
- Get my dashboard task totally work.
- 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.
- 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!)
- Still working on drag and drop annotation categories.
- responding to some outstanding reviews.
This term, Vivien and I finished the remark request feature.
- 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
- 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:
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.
- 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.
- Write a review for tests
- Start working on respond_to, try to make it a separate issue from the current one first.
As of Saturday, exams.
- waiting on ship-it
- blog post to userdoc after ship-it
- no review :/]
- No change
- Start work on issue 8 again
- None now that my other courses are finished! 😀
- Finished righting the download yml functionality.
- Work on editing the HTML part of it
- Exams coming…….
- Implemented modal dialog for role switching but have problems with loading the index page using AJAX requests
- Wrote some tests
- Fixing the bug that causes the index page not to load
- Understanding AJAX requests
- fixing new annotation category reload bug
- Tests for annotation category drag and drop
- None 🙂
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 api_helper.py -h
# Send a user HTTP request
$ python api_helper.py -r REQUEST_TYPE -k /path/to/api/key.txt -u http://url.to.markus.com/api/controller 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:
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 api_helper.py -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 api_helper.py -r GET -k api_key.txt -u http://localhost:3000/api/users user_name=c5doejoh
# Update user c5doejoh's details, changing everything.
$ python api_helper.py -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
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. 🙂