MarkUs Blog

MarkUs Developers Blog About Their Project

Archive for November, 2013

USOSP Status Report – Week of Nov 18

without comments

Xiang

Status

  • Completed the functional tests for the Summaries tab and submitted a pull request
  • Fixed issue 1211 and submitted pull request

Roadblocks

  • Need to learn more about shoulda to ensure test quality

Next week

  • Continue to test and improve the functionalities related to the Summaries tab
  • Look for new issue to work on

Arianne

Status

  • Fix for issue-1194 got merged into the project
  • Fixed a bug related to displaying more than 15 students at a time for a grade entry form
  • Briefly looked into issue-894: Marks spreadsheet: sort by User Name, Last Name, First Name, Section

Next Week

  • Working on issue-100: Simple Grade Entry: Refactor the code for calculating a student’s average mark

William

Status

  • Worked on implementing and testing methods inside of the new git_repository.rb file
  • Completed self.open, self.access, and self.delete (self.delete has some quirks that need discussing)
  • Went through subversion_repository looking for code to salvage, I think we can reuse most of the Repository class.
  • Rugged doesn’t create a master branch when it initializes a repo, I found a work around.

Roadblocks

  • No one has merged Dylan’s pull request. It is making it difficult to work collectively.
  • When rugged initializes a repo it doesn’t create a master branch, that was frustrating.
  • Rugged cannot delete repos, however, it can delete branches and references to head in the repo. We need to discuss if this is an issue in the meeting.

Next Week

  • Continue implementing in git_repository.rb
  • Test and see for sure what can be recycled from the Repository class in git_repository.rb
  • Dylan and I have discussed building a test harness for git_repository, we might explore that more.

Dylan

Status

  • Continued implementing the git_repository create method. When creating a group, many of the repository methods get called. I have been implementing these roughly to try and get the new group to show appear in the list so that I can start adding students to it.

Roadblocks

  • The Rugged docs are pretty sparse. Was able to find some solutions with Bill

Next week

  • Get the groups added fully and implement necessary methods to get students added to them.

Daniyal

Status

  • Looked into how Shoulda works
  • Created Shoulda tests for Git repository.

Roadblocks

  • Haven’t been able to run my tests to make sure they work because the git repository file has not been merged so I’m not sure how to check out the work done so far on git repositories.

Next week

  • Figure out if my tests are fine and commit them
  • Work on implementing some methods in git_repository

Written by Daniyal Liaqat

November 18th, 2013 at 4:14 am

Posted in Uncategorized

Punchlines ECN – 17/11/2013

without comments

Augustin

Status

– Migration to JQuery ongoing

– 2 PRs with some files from app/views/assignments

Roadblocks

– Some unknown translations from Prototype to JQuery

– I have not tested yet my work because I had some trouble executing cmd “bundle exec rails s”

Next Week

  – Functionnal test about my work

– Finish migration

 

Anthony

Status

– Migration to JQuery ongoing

– Pull request with some files of the app/view folder

RoadBlocks

– Some unknown translations from Prototype to JQuery

Next Week

– Make a pull request with my full part of the app/view

– Start my part of the js folders

Hamid

Status

–  Finishing the migration to jQuery

Roadblocks

– Some unknown translations from Prototype to JQuery

Next Week

 –  Make my pull requests

Julien

Status

–  Working with Loic on our migration, our part is almost over and should be done this week end

Roadblocks

– The translation of ajax request

– The translation of this kind of function :

@student_ids.each do |student_id|
end

Next Week

 – finish our part, with the tests and the commits

 

Loïc

Status

–  Working with Julien on our migration, our part is almost over and should be done this week end

–  Doing the commits for our part

Roadblocks

– The translation of ajax request

– The translation of this kind of function :

@student_ids.each do |student_id|
end

Next Week

 – finish our part, with the tests and the commits

 

François

Status

– Migration to JQuery in process

RoadBlocks

– Some trouble with specific Prototype functions: page.call(), Ajax.Request & replace_html with some @-parametres

Next Week

– Continue the migration

 

Written by Loïc Labagnara

November 17th, 2013 at 5:43 am

Posted in Uncategorized

Starting Implementation with Gitolite/Rugged

without comments

Note: this post will be updated as the design changes. This is just for other developers who wish to work on the git-backend project.

 

What works:

– Adding a group will create a git repo in /repos (will change)

– New repo has permissions RW+ granted to admins/graders.

 

Setup:

1. Checkout my git-conversion branch (will change)  https://github.com/drunkel/Markus/tree/git-conversion

2. Install and use ruby 1.9.3

3. Ensure that gems: rugged and gitolite are installed.

4. Create a directory in /data/dev/repos called git_auth

5. in irb, do:

require ‘gitolite’

Gitolite::GitoliteAdmin.bootstrap("./git_auth")

 

6. Start the server normally.

 

**These instructions may contain errors, this project is just getting started.

 

 

 

Written by Dylan Runkel

November 10th, 2013 at 7:59 pm

Posted in Uncategorized

Installing libgit2 and Rugged

without comments

Requirements:

Please ensure you have git, ruby 1.9+, rails, rvm, and gem installed before proceeding.
Please ensure you are running a relatively up-to-date Linux operating system or Mac OSX 10.7+

Installing on Linux
For the installation of Libgti2 and Rugged, we are headed into the Linux terminal. Libgit2 requires that we have cmake installed, so we’ll start there.
     sudo apt-get install cmake

Next installing Libgit2. First navigate to where you would like to download the Libgit2 folder to. Then input the following commands in to the terminal:
     git clone https://github.com/libgit2/libgit2.git
     cd libgit2
     mkdir build
     cd build
     cmake ..
     cmake --build .

Next we will install Rugged.
     sudo gem install rugged

Everything by now should be installed, lets test to ensure that is the case.
     irb
     1.9.3 :001 > require “rugged”
       => true
     1.9.3 :002 >exit

Installing on Mac OSX
Before proceeding with installation, please ensure you are running XCode development tools 5.0+ and have the XCode console development enabled.
For the installation of Libgti2 and Rugged, we will be headed into the Mac terminal. But first we need to install cmake installed, so we’ll start there.

  • Go to http://www.cmake.org/cmake/resources/software.html
  • Go to download link Mac OSX 64/32-bit Universal (for Intel, Snow Leopard/10.6 or later) and choose .dmg
  • Open the .dmg file and follow the instructions on screen, ensure cmake console commands are installed if prompted.

Next installing Libgit2. First open up the terminal and navigate to where you would like to download the libgit2 folder to. Then input the following commands in to the terminal:
     git clone https://github.com/libgit2/libgit2.git
     cd libgit2
     mkdir build
     cd build
     cmake ..
     cmake --build .

Next we will install Rugged.
     sudo gem install rugged

Everything by now should be installed, lets test to ensure that is the case.
     irb
     1.9.3 :001 > require “rugged”
       => true 
     1.9.3 :002 >exit

Written by William Roy

November 8th, 2013 at 9:56 pm

Posted in Uncategorized

Status Report – Week of Oct. 28

without comments

Dylan

What I did:
– Looked into how user access is done for the current SVN system. Summarized my (rough) notes and passed onto Bill, Daniyal.
– Set up a Vagrant box to act as my dummy server to host my git repos on, and began playing around with gitolite.
– Now have an understanding of the basic architecture of gitolite, how users are added, and roles managed.
Roadblocks:
– Distance is a bit hard. This project will require us to have quite a few meetings, I think.
– Rugged (required to talk with the git repos) requires Ruby 1.9.3….but as we know this doesn’t work with existing code. Need to discuss how it’s best to go about testing our implementations.
Next week:
– Do up a quick document to get Bill and Daniyal up to speed with my findings.
– Meet with Bill and Daniyal to discuss putting some of these parts together.
– Write some code! See where/how to integrate gitolite and the permissions scheme into MarkUs. 

 

William

Status
 – Got libgit2 and rugged working on Ubuntu.
 – Working on writing a guide for installing libgit2 and rugged for the MarkUs blog.
 – Played around with some rugged methods to better understand how things work.
Roadblocks
 – libgit2 will NOT build on OSX 10.6, I tried for far to long to get it to work. However OSX 10.7 and higher are fine.
 – Rugged does not support ruby 1.8.7
Next Week
 – Post guide on installing libgit2 and rugged onto MarkUs Blog.
 – Ideally I’d like to meet with Daniyal and Dylan again to figure out how we’d like to proceed with implementation of git inside MarkUs
 – Begin implementation of git!

 

Arianne

Last week:

Created ticket for bug found: link not working for uploading grade entry form grades through csv. – Issue-1224

Fixed Issue-1224 and submitted pull request.
Worked on fixing old tests that broke from issue-1194 updates (still have 3 unit tests and 3 functional tests to fix).
This week:
Add a few tests for new functionality. Finish off this ticket!

 

Daniyal

Status:

– Researched libgit2, rugged and gitolite. Gitolite looks like something we will need for authentication as it allows for easier and more fine-grain control of repositories. It uses a file similar to svn_authz to determine which users have what kind of access to different repositories.
– Worked on issue-54, learnt a bit of JavaScript to format calendar_date_select in new assignment tab. Added a gap between buttons and increased button font size. Submitted a fix for this issue and made a pull request.

Issues:

– Haven’t been able to start add code for git repositories because I’m having trouble figuring out where to start.

Next Week:

– Meet with Dylan and Bill to figure out how/where to start implementing git.
– Get at least some code started for git implementation, even if it is very barebones.

 

Xiang

Status:
– Reviewed all the code written for the Summaries tab and did coding cleaning.
– Posted a blog post describing the functionalities of Summaries tab and implementation details as well as issues.
Roadblock:
– Had some issue with local Markus after update
Next week:
– Fix the issue with update
– Commit a working set of code
– Write tests for the Summaries tab

Written by Xiang Yu

November 6th, 2013 at 11:29 am

Posted in Uncategorized

New feature: Summaries tab

without comments

I have been tasked to implement this new “Summaries” tab which is under “Assignments” and on the same level as “Groups”, “Submissions”, etc. It has a similar basic layout as the “Submissions” tab which is a table with functionalities such as filtering, pagination and sorting by columns. Each row in this table corresponds to a group; the columns are Repository, Commit date, Marking state, Grace credit used, Final grace, and grades for each marking criterion of the group. It serves as a detailed mark breakdown for each assignment.

While implementing it, I following the same logic for the “Submissions” tab for populating data, handling pagination and sorting. For the most part it works fine. However, I did come across two major roadblocks:

1. This is more of a difference to consider than a problem. Since I am displaying marks for each marking criterion, the number of columns is different across different assignments and it might change when the assignment rubric is changed. Therefore I need to dynamically display the criteria according to which assignment we are viewing. For the “Submissions” tab, since it only displays information that is common to every assignment, the number of columns won’t change.

2. Since now I have new columns, I need to implement new “compare” functions for them for the “sorting by column” to work. The way sorting and paginating works in the “Submissions” is as follows: The “compare” function for each column is coded in a constant hash in the Submission controller; when a pagination/sorting event occurs, the hash, along with other paratmeters, is passed to the handle_pagination_event helper function which handles sorting, and then pagination. The problem is I can’t store all the “compare” functions for the criteria in the same static fashion since the marking rubric may change and the corresponding compare functions required also change. In addition, since data in the criterion columns are of the same type (“mark”) and the implementation of the compare function should be identical except there is a unique mark id for each column.

 

The way I implemented it is that, hopefully following the “DIY” principle of Ruby on Rails, I created a single new compare function for comparing marks for a certain marking criterion. Instead of having two parameters (the two objects being compared), I have a third paramter, mark id,  for the compare function to get the desired mark. Then the two marks are extracted and compared according to the established logic. The whold picture is, the view generates table columns dynamically according to the rubric of the current assignment; when a “sort by criterion” event occurs, the corresponding mark id is passed along with other parameters and the hash which contains the new 3-parameter comapre function to the pagination helper function; the helper function executes the compare function to sort the data by this particular marking criterion.

 

While exploring other possible solutions, I have noticed that there are sortable table in Markus that are handled in a totally different way, namely the “FilterTable” javascript class. After reading the git wiki page of FilterTable, I found out that when the FilterTable object is created, the columns should be specified. Therefore it cannot handle situations where name and number of columns are changed dynamically. Moreover, it doesn’t seem to have pagination feature (it’s just a long table). I am by no means a javascript expert, so please correct me I am wrong.

 

The following are some screenshots of the Summaries tab:

(1) sorting by final grade as in the Submissions tab

Screenshot_sort_by_final_grade

 

(2) sorting by the first marking criterion:

Screenshot_sort_by_criterion1

 

(2) sorting by the second marking criterion:

Screenshot_sort_by_criterion2

 

Also I am relatively new to the Ruby on Rails world, so if you have any suggestions or better solutions, please let me know 🙂

 

 

Xiang Yu

 

Written by Xiang Yu

November 3rd, 2013 at 3:35 pm

Posted in Uncategorized