MarkUs Blog

MarkUs Developers Blog About Their Project

Archive for April, 2013

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.


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 
 first_name: admin
 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.


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:

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?

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.

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.

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.

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

Punchlines – UCOSP Winter 2013 – Week 11

without comments

Mike Wu


  • Submitted pull request #1063 to add indicator in “Annotation Summary” to distinguish remark annotations from original ones (issue 1029).


  • None.

Next week:

  • Coordinate with Karen on what to develop next.
  • Write a blog post, topic TBD.



  • Finally finished /api/users/id/groups, updated submission_downloads, and added test coverage for submission_downloads. That pull request can be found here: It was interesting handling the test cases for submission_downloads, as I had to setup and imitate a user who had committed files to a repo for an assignment submission. And as for groups, I decided to just work with the groups class rather than groupings.
  • I also pushed my current progress with RESTful API documentation to a branch on my fork, and the file can be previewed here:


  • None.

Next week:

  • Finish documentation, update the Test Results routes.



  • Added an option to the grades entry form so that the totals column may or may not be rendered based on the admins choice.
  • The implementation of the above feature required adding a new property to the grade entry form model, as a result, a new db migration has been created.
  • Similarly, within the student view, the results are displayed as part of the grade entry forms list only if the admin checks the “show total” option, otherwise, a message will be displayed informing the student to look at their detailed marks.


  • None.

Next week:

  • Need to do simple CSS cleanup and add internationalization support for a few new labels.
  • Finalize blog post.



  • Submitted pull request-1064 for fix to issue 1013 (late penalty description + mark not showing up once mark is submitted) as well as some other bugs I found


  • Came across other bugs while working on fix (eg: penalty decay wasn’t working properly, “remove” button had a UI bug). Included these fixes with pull request.

Next week:

  • Work on issue 1020 (fixing “show old mark summary” to show bonus/penalty mark section for old result)



  • Finished work on term goal of converting prototype to jquery. Started looking through Github issues to see what issues I can fix for the remainder of the project.


  • Cannot merge the prototype to jquery branch just yet into MarkUs master due to merge conflicts across a number of files. Daryn and I will have to meet up together to do this process together to make it go a lot smoother.

Next week:

  • Work on Github issues



  • Finished implementing back drop down menu.


  • Merging all changes into Markus master due to merge conflicts. Will consolidate with Marc to complete merges.

Next week:

  • Either work on issues, testing pull requests for others, or find small prototype tools to be changed to jQuery.

Ian Smith


  • Have the student interface for the automated testing set up. Students can run tests, and see results.
  • The test_results are now associated with the test_script results so they display properly.
  • A revision number of the repo that the test was used to run with is stored and displayed so the user knows which test ran with which version of their repository.


  • Need more information about how “run on request” is supposed to work.

Next week:

  • Finish and polish the student interface for automated testing.
  • Merge and complete the work on unlimited tokens that I implemented previously.

Mike Stewart


  • I’ve got graders being assigned to users through the grade entry graders tab, but still need to work out a few bugs.


  • Working out a few last bugs with the grader tab, particularly with the tables not loading properly.

Next week:

  • Fix bugs and submit a pull request for grader tab.



  • Implemented a limit on the number of tests that can run simultaneously on a test server


  • None

Next week:

  • Display test run progress to TAs and students

Written by Ian Smith

April 3rd, 2013 at 11:36 am