MarkUs Blog

MarkUs Developers Blog About Their Project

Archive for the ‘Developer Essentials’ Category

Status Update: March 10th, 2014

without comments

Rafael Padilha

This week I was travelling, as I’ve told Karen, so I haven’t worked a lot. I’m going to finish the Portuguese translation and get one of the issues I’d worked at the Facebook weekend ready to be merged to the repository.

Zach Munro-Cape

This Week

- Resolved issue https://github.com/MarkUsProject/Markus/issues/1358
- successfully ran the git branch and created setup instructions https://github.com/munrocape/Markus/wiki/GitBackEnd
- Contributed to wiki instructions for rvm
Roadblocks
 - messed up my ruby installation. took an evening to resolve.
Next Week
- continue work on mapping subversion repo file into rugged git-repo file
Andrew Hernandez
This week:

  • Worked on issue with duplicate annotations
  • Worked on reproducing a bug I noticed
Roadblocks:
  • Really busy week since a lot of deadlines are incoming in all my courses
Next Week:
  • Decide which project I will work on with Shenglong and Jeremy
  • Continue work on issue
  • Send in bug report if I can reproduce the bug

Jeremy Winter

This week: Finished issue #1310, continued doing rails tutorials online as well as reading a rails book.
Roadblocks: When I used git pull upstream master to make sure my code could easily be merged, the version of markus wouldn’t run. Looking into a solution for this.
Next week: Continue working on issues I find, as well as consult with Andrew about writing code for being able to tag assignments.
Shenglong Gao
This week: Finalized project with Western team
Roadblocks: Been extremely busy with startup
Next Week: Finish issue, start working on project

Cornell Team

Next week:

 

We will try to finish issue #1032 but this issue is much trickier than it seems at the first glance. We will start working on the help system.

Current Week:

 

Ope:

 

- Created an issue (#1380) identified while on the User’s tab

- Fixed the issue and created a pull request (#1384) that was merged successfully

- With Tiago’s assistance, installed MarkUs on a Linux machine running Ruby 2.0 in order to validate changes he made. I will assist him at a later time in updating the Installation Steps

- Reviewed issue #1032 with the team (Chris and Alex), and identified the cause of the error not being displayed. We came up with a temporary workaround. We will work on a permanent fix.

 

-Roadblocks: None

Alex:

- Helped work on issue #1032 with Ope and Chris.

- Started looking into issue #1301 and was finding possible other errors related to it.

 

Roadblocks:

-Was having trouble replicating the exact situation of issue #1301

 

Christopher:

 

- Mostly work on issue #1032. We manage to find out the cause of the problem and found some other bugs while fixing this issue. Now we are able to show the error message but not in the right way. One of the problem is because they call a method that has been deprecated and we finally figure that out.

- Start looking into issue #1301

 

Roadblocks:

- There is a method call that doesn’t exist anywhere. After working on it, we finally figure out that the method has been deprecated but still being called.

Tiago

This Week:
- I worked on issue #1367,#1373 and on the portuguese translation of MarkUs.

Roadblocks: None

Next Week: Continue to make markus work with ruby 2.0

Written by Shenglong Gao

March 10th, 2014 at 8:15 pm

Help System Proposal

with 2 comments

Help System:

The MarkUs help system is a way for helping users understand the functionality of MarkUs. The help system will contain embedded documentation in the website. The help system will use both hovering function over text and also will have tool tips throughout  the website. The tooltips will be a little picture of a question mark next to certain text or tabs or input boxes. When the user either clicks or hovers over the tool tip a box will appear telling the user the functionality of the specific element. We are also considering giving the user the ability to turn on and off the help system. This could be useful if a user is comfortable with MarkUs and does not need to see the extra dialogue.

We would like to make it so the help system can easily be changed when a change to the system is made. For this we feel it would be best to separate the actual text that will go into the embedded documentation from the pages themselves. We will store the text in a file and reference the sections that way. This implementation would be done much like the multiple language feature that exists. This will make it much easier for future developers to edit the tool tips if functionality changes or even add new tool tips by following the same design.

Here are some websites that we would like to base our system off of.

http://downloads.sixrevisions.com/css-tooltips/index.html

http://www.pat-burt.com/wp-content/csstooltip.html

The following is a list of where we believe the help system could be useful.

Admin View:

When an admin first logs in they should be able to hover of the tabs for a short description of what is under each tab for example the assignments tab could display “Review and Create Assignments”.

Within the tabs there are many sections and elements that could have documentation to help the user. Here is a list of some places where extra documentation can help.

Under the Assignments tab:

- On choose assignment page:

    > Upload and download button on the top right: display message on hover.

    > Add Assignment and Add Marks Spreadsheet: display message on hover.

- On Add Assignment page:

    > We will put a small icon (for example: ‘i’ icon) on the right side of each textbox that will

       display the message when the user click on it.

    > Some of the sections (Marking scheme, required files, etc.) will have the small icon on

  the section’s title that will display the properties of each selection.

- On Assignments > Settings > Marking Scheme:

    > We will add more stuff into the “Help” text box

- On Assignments > Settings >  Annotation:

    > We will add more stuff into the “Help” text box

- On Assignments > Settings > Text Framework

    > We will put a small icon on the right side of each section that will display the message

       when the user click on it

- On Assignments > Groups and on Assignments > Graders

    > The message will be displayed when the user hover onto the title of each tabs (for

       example: All groups, Valid, Not Valid tab)

- On Assignments > Submissions

    > The message will be displayed when the user hover on the button or the “title” (for

       example: collect all submissions, csv report, etc.)

Under the Users tab:

- On Users > Students:

    > We will have a small icon next to the title (Manage Students). The message will be

  displayed when the user clicks on it. This message will explain the actions (Bulk

  action, Give grace credits, Add Section, Mark active and Mark inactive)

- On Users > Students > Edit Students:

    > We will have a small icon next to “Grace Period Deduction”. The message will be

       displayed when the user clicks on it.

Students view:

Under Assignments tab:

After Clicking on an assignment you will see submission, assignment rules, and group information. In each of these sections we will have a small help icon that will explain details about what the student is looking at.

Under the Submissions tab:

We will have a help icon with a detailed description on how to submit your work. One option is a short step by step process that could walk a student through the submission.

Under the Results tab:

A help icon with details about what results the user is looking at

Graders View:

Under the Home tab:

- On Home page:

    > We will have a small icon next to “Your API Key”. The message will be displayed when

       the user clicks on it.

Written by Christopher Jonathan

February 28th, 2014 at 1:31 pm

Status Update: February 13 2014

without comments

Zach

This week:
- Unified filenames for CSV files along with some UI changes to download.

Associated Pull Requests: #1354, #1345

- Began working with Kitiya on issue #1358. Implementing search functionality in the User view.

Roadblocks:
- Nothing major with MarkUs.

Next week:
- Continued work on #1358.
- Look into git backend and what issues previously had. This could potentially be my project for the term.

Jeremy

This week:
- I’m currently working on issue #1310, and gaining an a better understanding of how everything works in Markus and rails.

Roadblocks:
- Haven’t had any major roadblocks yet.

Next week:
- Finish up that issue I’m working on, and get together with Andrew and Sheng about what we want to work on.

Ope

This week:
- Worked on installing the MarkUs application on my computer. Successfully completed installation.
- Reviewed parts of application code (critical controllers and views) to better understand the application flow
- Reviewed some existing issues on GitHub to understand work that may be needed
- Tested out the application interface to become more familiar with navigating through the system

-Roadblocks:
- Minimal time to catch up on project due to late start.

Alex

This Week:
- I worked on issue #1342 for creating groups in assignments.Was able to fix the issue by changing code in the group controller.

Roadblocks:
- I am not sure if the change to the issue will mess other parts of the grouping functionality. We need to do some other testing to determine if this is actually a fix.

Christopher

This week:
- Helped Ope on installing MarkUs application.
- Try to understand how MarkUs works by logging in as Administrator, Student and Grader.
- Looking on how the code works while navigating through the MarkUs Application
- Find a bug and put it on GitHub (issue #1342)

Roadblocks:
- Learning Ruby and how Rails work.

(Collectively at Cornell, Alex, Ope, and Christopher)

Next week:
As a group here at Cornell we plan on implementing the help system. Our first task is to better understand the functionality of MarkUs and where useful help tools could be implemented. By the end of next week we plan on creating a proposal of places that could use the help system and also develop some UI designs that we could use for the help system. We also will be working on issues that still exist.

Kitiya

This week:
- Submitted pull request for issue #764 – using correct HTTP status code for expired sessions.
- Working on issue #1358 – adding search functionality on the user tab.
- Familiarizing myself with MarkUs and Rails.

Roadblocks:
- Having not fully understood Rails is the biggest roadblock for me right now.

Next week:
- Continue working on issue #1358.
- Finalize the project I will be working on toward the term.

Gillian Chesnais
David Das

This week:
- #1337 (where releasing grades for all students in a spreadsheet of more than one page of students would fail)
- #1338 (where a TA with no student trying to view a spreadsheet would raise an error).

#1337 was failing because there was a function call (call() on line 221 after the fix) without any arguments. It needed arguments describing how results from a database query should be sorted and a variable pointing to the current user, which we provided.

Issue 1337


The first two arguments above indicate how it should be sorted, and we set these to be empty strings because we figured that since all users were being selected in this case, the order would not matter.

As this was our first bug fix and we did not know Ruby at all, we spent a significant amount of time pinpointing this error and understanding why it was failing, and how it related to the output. We also needed to learn how G_TABLE_PARAMS used procs and lambdas to fix this bug.
For issue #1338, we figured out that the function alpha_paginate() was meant to return ‘[]‘ when there were no students assigned to a TA, and it attempted this by checking if total_pages was 0. However, in this case total_pages is actually 1. We added another condition that all_grade_entry_students was 0 instead, which seems to have fixed this bug. You can see this fixed below:

Issue 1338


In the future, we will start to focus on patching and fixing the Markus beta.

Andrew

This week:
- Working on ticket #1348 to disallow identical annotations on the same line of an assignment.
- Submit detailed bug report about an issue with annotation.
- Familiarizing myself with Markus functionality and code.

Roadblocks:
- Catching up on schoolwork hasn’t allowed me to put as much time as I’d like in fixing the ticket.

Next week:
- Finish ticket #1348
- Speak with Jeremy and Sheng about which project we will be taking on.

Shenglong

This week:
- Submitted pull request for installation instructions on linux
- Working on issue #1347
- Learning MarkUs and Rails

Roadblocks:
- Not understanding Rails and the codebase is my major stumbling stone
- I’ve also been abroad the this entire entire week

Next week:
- Continue working on issue #1347
- Finalize the project I will be working on toward the Western team

Rafael
Tiago

This week:
- Started the Portuguese translation.
- Issue #1333
- Issue #1312

Roadblocks:
- None

Next week:
- Continue on the Portuguese translation of MarkUs.

Written by Zach Munro-Cape

February 13th, 2014 at 8:26 pm

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

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

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

Moving from Prototype to jQuery

without comments

For a little over two weeks, I had the opportunity to learn JavaScript by working on an issue on the MarkUs’s GitHub.
This issue is about updating the MarkUs application from Prototype to jQuery. Indeed, in order for MarkUs to migrate to Rails 3.1 (it is currently implemented with Rails 3.0), it has to support the new default javascript library, jQuery, hence motivating this work.

As I had never programmed in Javascript before, the first step was to document myself on javascript, but also to learn how Prototype and jQuery worked.
Fortunately, these two libraries have a fairly extensive documentation (Prototype API & jQuery API).

Merge old Pull Request and Master

A student, @m-bodmer had already tackled this issue a while back when working on MarkUs. Thankfully, he had created a pull request, and I could easily retrieve his branch to update it with the recent changes in the codebase, and understand his patch.

He worked on the jQuery integration, while still keeping Prototype in parallel.
For this, we used the call jQuery.noConflict(); which allows us to switch between one and the other (see the
doc).

As Prototype is the default, we call it with $ (ie, the default). jQuery is simply managed with calling jQuery (e.g. jQuery('#elem') instead of $('elem')).

Problems

While working on this issue, I encountered a series of problems:

  1. The first one is MarkUs’ views. We should avoid creating so many .rjs files (more informations here).
  2. The second problem is the numbers of render of .js.erb (e.g. _boot.js.erb which is everywhere). We should, if possible, remove them all. Yet, to do so, we need to solve the following two problems. First, there are, within these files, FilterTables owned by Prototype (things that we must remove in future to benefit of jQuery DataTables). Second, these files have embedded Ruby.
    There are ways to solve these problems (for example, sending varables when calling JS or sending data with new html attributes data-something). I have solved the latter, but the former remains to be done.
  3. The third problem appears in some functional tests. The request format is not good, so I was forced to specify it (:format => :js).

Work on _boot.js.erb

First, I removed the <script> tags from JS files and placed them in the body of the .html.erb without changing the call to this file:

Then, I removed the //<![CDATA[ tags  which -for me- should not be here (cf. article on stackoverflow).
The change of Ajax request is documented here.

I removed the populate.rjs called by the request

in benefit of .done() method of Ajax.

This required an explicit call to JSON in Ajax (dataType: 'json') and an adequate response in the action:

I haven't change the populate() JS function now called by the .done() method. It requires to change the data object -transformed by the jQuery (I haven't tried to change its behavior)- in JSON using JSON.stringify(data).
Another problem, the call of the partial. Rails now expects a partial in JS. To change this behavior, I had to explicitly add .html.erb extension.

Work on AnnotationCategories/

This work was to change this piece of code:

First, I removed all the JS part to put it in a .js file.
Then, so that my request knows the required path, I created a variable path I send to the created function function using #{}. Which gives:

JS side, I created a file named index.js inside javascripts/AnnotationCategories/.
I think eventually, it would be wise to follow a template that would be to create for each model a .js corresponding and not to make -as I did- a folder with a view's name inside.
So the function add_annotation_category() looks like this:

First, I cut the call to element by creating an intermediate variable category_prompt. To find out if an element exists or not -knowing that jQuery, unlike Prototype, always returns an object not null-, I use the .size() method I compare with 0 implicitly.

Regarding the Ajax request, I use variable passed as parameter for the URL and I specify the type GET.

Modals

Before I tackled this work, each time we used models, we had to recode part of the javascript.

Then, I decided to take care of modals, so that we whenever have to recode to do the same thing. Example for the file annotation_categories/_boot.js.erb:

As this is not "DRY" (do not repeat yourself, one of Rails's moto), I decided to created a javascript class, that we can reuse. I first removed all modals not working properly. Then, I created a ModalMarkus class in the application.js file (we should place it in another file):

This "class" thus creates modals with automatic size and two methods open() & close() (I took inspiration from the implementation of bootstrap-modal.js file).
I also added a dialogClass to add a CSS rule to remove the header and the footer of modals I found unnecessary.

Thanks to this work, we can initialize modals by simply adding this piece of code in a javascript file:

And modals can be called with:

From RJS to JS.ERB

Finally, one of last things I did is the migration of files from .rjs to .js.erb -in the case that the .rjs is not easily deletable-. To do this, the jQuery & Prototype APIs are essential, but I also found help in various documents easily findable after a Google search (e.g. SlideShare).
Some examples:

From Prototype

To jQuery

Conclusion

There is still a lot of work to do, but it is, I think, interesting work to do.
Thanks to this issue, I learnt JS, but I also saw more in depth how MarkUs worked. I also gives the opportunity to appear unnecessary, poor made and replaceable code.

G.

Written by Ghislain Guiot

August 12th, 2013 at 12:39 pm

Debugging in Rails

without comments

Learning how to debug in Ruby on Rails is arguably one of the most important things to learn when getting started with rails development, yet isn’t always easy to pick up with the documentation available. What follows is an introductory guide to rails debugging, with the goal of getting new developers up and running with the command-line debugger as quickly as possible.

Logging

One of the simplest ways to debug in rails is to simply output information to the screen. This is especially convenient when it is necessary to continuously output the value of a variable over time.

The easiest way to do this depends on where you are debugging – whether it is within a view, controller or model.

Views: DebugHelper

The Rails ActionView comes with a debug helper that makes debugging in a view easy.

Within a view, simply enter debug followed by the name of the variable of interest to print out the variable in a human-readable format. For example:

<%= debug @current_user %>

The above code will display a detailed YAML output of the given variable, in this case @current_user, at that particular point in the execution:

--- !ruby/object:Admin 
attributes: 
 first_name: admin
 section_id: 
 notes_count: 0
 last_name: admin
 updated_at: 2013-01-19 01:05:27 Z
 created_at: 2013-01-19 00:56:14 Z
 grace_credits: 0
 hidden: 0
 api_key: MjBjZDk1Y2Q5MjdhZTU1MjE2NjBlYTNmYmQzODY4Zjc=
 id: 1
 user_name: a
 type: Admin
attributes_cache: {}
changed_attributes: {}
destroyed: false
marked_for_destruction: false
new_record: false
previously_changed: {}
readonly: false

Controllers and Models: Logger

Within a controller, it’s still possible to pass debugging information to the screen by passing it to a view object, although it is typically simpler to log it to the console. This can be done using the default rails logger, which takes a string as input. Duplicating the above example using the logger:

logger.debug "Current user: #{@current_user.inspect}"

In this example, the inspect method is used to convert the contents of the @current_user object into a human-readable format, which is then output to the console by the logger. Note that the console output is also logged to a text file for later viewing. In the Markus development environment, this is saved in logs/development.log.

Debugging

For more complex problems, it is often necessary to step through the code to get to the root of the problem. This can be done using the built-in ruby-debug gem.

The ruby-debug gem must be first installed in the Markus environment, which can be done with the following command:

sudo gem install ruby-debug

The debugger can then be invoked by entering debugger anywhere in the ruby code, which has the effect of creating a breakpoint. When the debugger statement is reached, the application is paused and creates a debugger shell in the terminal.

Some of the most important commands include:

  • backtrace – Display a stack trace of the application execution.
  • break – Set new breakpoints, at a particular line or method in a file/class.
  • catch – Tells the debugger to catch all exceptions of a particular type, or (with no arguments) catch all exceptions.
  • continue - Resume execution.
  • delete/disable – Delete/disable a breakpoint.
  • display – Used to set the debugger to display the value of a certain variable each time you move the debugger to a new point.
  • down/up  - Move up/down n levels in the execution stack.
  • finish – Continue execution until the current (or specified) stack frame returns.
  • frame – Used to move to any point in the execution stack. Call frame n, where n is the number listed in the backtrace.
  • irb – Start an interactive ruby interpreter. Interactively execute code within the current application context.
  • list (or l) – Display the lines of code surrounding the current line being executed. Can be used in succession to display following lines of code. Use list- to display previous lines of code.
  • method – Display methods available to an object or class.
  • next/step – Steps through the code, one line at a time. Next is more like “step over” and step more like “step in”. Use next/step- to move backwards.
  • p or pp – Print (or pretty print) the value of a ruby expression.
  • quit – Exit the debugger shell. Also will terminate the server.
  • reload – Reload the ruby source. Required to reload the code if you change it while the debugger session is running.
  • thread – Show running threads, switch between them, and stop/resume.
  • var – Display all variables of a certain type (gloabl, instance, local, constant) and their values.

For the specific parameters of these commands, enter help <command> in the debugger shell. Simply entering help will provide a list of all commands.

Written by Mike Stewart

April 14th, 2013 at 1:50 pm

Remarking Process Overview

without comments

This term, I worked on the re-marking feature in MarkUs together with Alysha. Besides the major change to database schema, a number of other changes and additions were made to improve the usability of the feature.

For a general overview of how the remarking process works in its current state, I have added a section in the Wiki on this topic: https://github.com/m-wu/Wiki/blob/issue-18/HowGradingWorks.rst#the-life-cycle-of-a-remark-request

Written by Mike Wu

April 12th, 2013 at 5:00 pm

Personal gains from contributing to UCOSP

without comments

My involvement in the UCOSP program was quite rewarding and satisfying. I gained valuable real-world experience as well as knowledge pertinent to my school studies and long-term career goals. Prior to working on Markus, I did not have any experience contributing to open source projects. For this reason, I found it difficult to understand why certain people spend a lot of their spare time producing stuff without being paid and then give it away for free. What are some of the personal benefits you can gain as a developer from participating in open source projects?

Self-education
This is your chance to work on projects and problems that you are most enthusiastic about, which is a strong motivator for doing your best and reaching creative heights.

Having your work reviewed and critiqued publicly may seem out of the norm. However, criticism can be viewed as a tool for improving your skills, attitudes and habits towards quality. You will develop a tendency to avoid sloppy coding knowing that your work is accessible by anyone.

The larger projects that have survived for years and continue to evolve often have great leadership, organization and development guidelines. Chances are you will become part of a team and learn from people that are many levels better than yourself.

Contribution
Some people actually develop feelings of wanting to give something back. Maybe not trying to make a difference but simply showing a token of gratitude to a community providing such a strong foundation for learning and education to anyone in society.

Control
Most people wish for freedom to control their lives. It can be incredibly frustrating to work on a project with budget constraints where software is rushed into a unmanageable mess. Reorganization and outsourcing can also seed feelings of disappointment and helplessness.

With open source you are no longer are a victim of such circumstances. You are free to implement and improve the features you think matter the most, while users help with finding relevance and setting priorities.

Reuse
Most programmers develop an urge to not repeat themselves throughout their careers. Producing open source software is the freedom to truly reuse efforts when changing jobs (or starting your own company) and share them with anyone.

These intentions stimulate thinking using broader perspectives and designs that are cooperative, flexible and adaptable to different environments in order to maximize opportunities for reuse. Keeping users loyal often means maintaining version compatibility and upgradability. Having to deal with all this complexity will make you a better programmer.

Open source is a lot about a community of freedom and sharing and it is not hard to see why open source developers often are highly respected. Participation will introduce you to a community of incredible talented, like-minded and caring people that may help improve your skills beyond imagination.

Written by oussamaBA

April 10th, 2013 at 11:05 am