MarkUs Blog

MarkUs Developers Blog About Their Project

Archive for November, 2011

MarkUs UCOSP, Fall 2011: Status Week 11

without comments

Severin

Status:

  • Ran a small scale experiment with MemoryRespository. Not sure if conclusive, but it ran fast and did not show similar behaviour to other experiments with SVN repositories.
  • Unsuccessfully tried to make Phusion Passenger use separate production.log’s per Ruby worker.
  • Sidenote: Mongrel/Passenger performance is pretty much on par

Next Steps:

  • Perhaps create a screencast showing the performance run in action
  • Write-up of findings
  • Time permitting, re-run mongrel experiments with separate production logs per mongrel in order to get more accurate analysis from request-log-analyzer

Roadblocks:

  • Other courses

 

Alex

Status:

  • Added functional tests for students, TAs, rubrics, and annotation_categories to test the multiple encoding file uploads.

Next Steps:

  • Try to figure out how to add remaining functional tests.
  • Figure out why there are errors on the grades file upload. Whether it’s caused by me or by a rails 3 migration.

Roadblocks:

  •  Could not figure out how to add functional tests to grades, groups, graders.
  • Graders and groups do not have a functioning upload/download capability, so I could not test it manually before making the functional tests.

 

Luke

Status:

  • Put up review fixing issue 527 (http://review.markusproject.org/r/1139/).Waiting for Ship It.
  • Fixed misspelling raised by a professor and some translation issues.
  • Got that reviewed. (https://github.com/lkysow/Markus/tree/spelling-fix)
  • Discussed issue 525 (https://github.com/MarkUsProject/Markus/issues/525) with Nelle and got it closed.
  • Started work on issue 501 (https://github.com/MarkUsProject/Markus/issues/501). Waiting on  translations from mailing list.

Next Steps:

  • Bump Ship It on 527.
  • Bump translations needed on 501.
  • Start work on… ahh rvlaicu stole it!

Roadblocks:

  • Need ship it on 527 and translations for 501

Erik

Status:

  • Resolved issue 439: Admins couldn’t create groups with the “Add new” button (Waiting for review. id: 1137)
  • Wrote a blog post about using firebug

Next Steps:

  • Probably continue work on the groups page, still a few broken links/buttons

Roadblocks:

  • None

 

Razvan

Status:

  • No real work done this week.

Next steps:

  • Continue with issues currently allocated to me.

Roadblocks:

  • Final projects for a couple of courses taking significantly more time than expected.

Written by Severin

November 30th, 2011 at 4:55 pm

Using Firebug

without comments

Firebug (Found here) is an add-on for Firefox that allows users to view, modify and debug the HTML, CSS, and JavaScript of pages as you see them. I imagine that most of the Markus developers know how it works already, but in this blog post I am going to talk about how I have been using it, and what neat features and tricks that I’ve learned.

Firebug takes the form of a layover that sits over your page. In the screenshot, the HTML tab is selected, so we see the source HTML and CSS for the page.

Working with HTML

The first thing that I learned with firebug is how to view and edit HTML effectively. This turns out to be handy, since it isn’t always obvious what kind of HTML the rails code will make. I certainly spent a lot of time playing with various rails commands and seeing what results they have in HTML.

Handy Features

  • The inspect button
    This is the button at the top left of the toolbar (next the the firebug, the one with a mouse arrow above a box). If you click on that button and start moving the mouse around the page, firebug will show the HTML source and CSS of whatever is under your mouse. This makes it super easy to find the HTML source of whatever feature you are working on.
  • Editing HTML
    There is an edit button near the top left of the toolbar (in the second row). Clicking it will allow you to edit the HTML of whatever line you have selected, and will show you the results immediately on the page. This lets you try all sorts of experimenting and testing. I found it useful for adding and taking away CSS classes and seeing the results. Note that you can also make changes to the CSS directly in the window on the right and see the results right away too (You can also do this from the CSS tab).

Working with JavaScript

JavaScript is used all over the place in Markus, and if you’ve never used it before, it can be quite a handful. It can be hard to tell if the code you write is even executing or causing errors, because the page won’t necessarily tell you. Fortunately, Firebug helps here too. Clicking on the scripts tab will show you all the JavaScript that is working on the current page. The console tab ends up being super useful here too.

Handy Features

  • Setting breakpoints
    Clicking on the line number of any line will set a breakpoint there. Whenever that line of code is being executed, the execution will pause and let you take a look. You can then step forward one line at a time, or jump to your next breakpoint. This is handy for seeing what code is being executed in what order.
  • Printing debug messages
    If you want to print debug messages in your JavaScript, try console.log("Log Message"). This is print your log messages to the firebug console (On the console tab). Again, this is really handy to make sure specific lines of code are being executed in a particular order.
  • Seeing error messages
    If your JavaScript is incorrect, it will often fail silently, leaving you confused as to if your code is working or not. But the firebug console will actually print useful error messages to the console and give you specific line numbers. This is awesome if you are not very familiar with JavaScript.
  • Testing JavaScript at runtime
    Again, this one uses the firebug console. At the bottom of the console, there is a command prompt that has starts with “>>>”. You can type any JavaScript here, and it will be executed on your page immediately. This is handy for checking out the results of function calls, or just to experiment a little.

Other Miscellaneous Features

  • Viewing HTTP requests
    Is there anything the console can’t do? The console will show you any HTTP requests that your page is making. It shows the type (GET, POST, etc), and to what URL. It also tells you if the request was successful, and gives you the error responses if they weren’t. This is pretty handy since it isn’t always obvious what rails routing will do.
  • Firebug in another window
    Firebug doesn’t have to cover the bottom quarter of the screen! Pressing Ctrl + F12 will open firebug in a new window. This is particularly awesome if you have 2 monitors.

Hopefully this post has been useful to some people. I’m sure there are still tonnes of features that I missed, but these are just the ones that I found most helpful and used most often. Feel free to add your own favorite firebug features to this post.

Written by Erik

November 30th, 2011 at 11:10 am

Punchlines – 25 november 2011

without comments

Here are the punchlines of our group (students from Centrale Nantes), working on the test framework of Markus.

Charline

Status :

Done the state of the art for the student view
Diagrams describing the project

Next Step :

Solving the problems to make the student view working

Claire

Status :

State of the art for the Student’s test framework completed
Wrote activity and state-transition diagrams for each type of user

Next Step :

Solving the problems listed in the state of art in order to make the student view working.

Benjamin

Status :

understanding what is inside a build.xml document
generating build.xml from java program
testing the build.xml in order to know wether a java class compile or not
I have written the solution of the algpr practical work.

Next Step :

generating build.xml for c or c++ program
persevering with ant documentation

Roadblocks :

i have not understood the particular interest of the JUnit library while generating a build.xml document

Guillaume

Status :

Wrote class diagram for the test framework. State of ort of the test framework (Admin’s view)

Next Step :

Correct display errors and try to solve the 404 error

Bertrand

Status :

Ended the state of the art for the Admin’s test framework.
Wrote 3 sequence diagrams for each type of user.

Next Step :

Try to correct the errors that disable us to see if Ant can compile our test files.

Roadblock :

Error 404

Karim

Status :

Working on the state of the art of test framework (grader view).
Did a general component diagram for Markus.
Detected some bugs while working on the state of art.

Next Step :

Working on bugs (404 and root) related to the grader view

Written by gbugnet

November 25th, 2011 at 12:40 pm

Posted in Status Reports

Tagged with ,

Markus UCOSP Fall 2011 – Meeting Minutes Nov 23

without comments

Meeting started at 3:15 p.m. and ended at 3:58 p.m.

  • Jordan is coordinating with the team from France to fix various issues
  • Alex was busy with course union administration
  • Erik is working on group routing issues and wrote a blog post on remote_form UJS
  • Luke worked on various issues: Opened and closed a bug, looked into a routing issue and worked on submission rule issues
  • Severin was busy, but played a bit with the production log analyzer tool
  • Razvan is working on issues 527/528, and is having some routing issues which were resolved during the meeting

Written by Erik

November 23rd, 2011 at 5:26 pm

Markus UCOSP Fall 2011 – Status Week 10

without comments

Severin

Status:

  • Run one experiment with repos already created. Not surprisingly, the request times for the student interface, where repos get created  (if not existent) decrease and submission URL take up most of the time.
  • Briefly played with the request-log-analyzer gem, which allows for production.log analysis. [1] is an example (note that it’s only capable of analyzing logs correctly if there is one production.log per mongrel).
  • All evidence seems to point into the same direction. The more SVN interaction is done, the longer the response times.

Next Steps:

  • Perhaps create a screencast showing the performance run in action
  • Write-up of findings
  • Time permitting, re-run mongrel experiments with separate production logs per mongrel in order to get more accurate analysis from request-log-analyzer

Roadblocks:

  • End-of-term crunch. I didn’t really get anything done this week 🙁

 

Alex

Status:

  • No work done this week.

Next Steps:

  • Create regression tests for the fix created to #426.
  • Work on new found issues #583 and #584. Missing view code in graders and groups for downloading/uploading files.

Roadblocks:

Unexpected course union administrative tasks and meetings due to a resignation of our president.

 

Luke

Status:

  • Discussed Erik’s work on ReviewBoard
  • Got issue #531 closed
  • Created new issue #586
  • Worked on #586

Next Steps:

  • Fix #586

Roadblocks:

  • None

Erik

Status:

  •  Wrote blog post about updating remote_forms with UJS
  •  Continued working fixing issues on the groups page, the “Add new” button in partucular

Next Steps:

  •  Try and get all of the groups issues resolved

Roadblocks:

  •  The remaining issues are all still remote function calls which I have been struggling with for a while. Hopefully can get them resolved in a timely fashion

Razvan

Status:

  • Worked on issues 527/528
  • Submitted changes for 580

Next steps:

  • Continue working and finish up 527/528
  • Fix the tests that fail for issue 560 before finally committing it to main

Roadblocks:

  • Could use a quick hint as to how to fix the testing issues with annotation texts

Written by Razvan

November 23rd, 2011 at 4:12 pm

Replacing form_remote_tag in rails 3

without comments

form_remote_tag has been deprecated in rails 3, and thus shouldn’t be used anymore. But what do we replace it with?

The main idea is that we can use form_tag with :remote => true passed in as an argument for the same effect. eg:


<%= form_remote_tag :url => global_actions_assignment_groups_path(@assignment) do %>

becomes:

<%= form_tag url_for(global_actions_assignment_groups_path(@assignment)),
:remote => true do %>

Simple enough. But what if we want some Ajax callbacks attached to this? For instance, what if we originally had this:

<%= form_remote_tag :url => global_actions_assignment_groups_path(@assignment),
:loading => "thinking();",
:complete => "done_thinking();" do %>

Now things get a little but trickier. Let look at the html that this generates:

<form onsubmit="new Ajax.Request('/en/assignments/2/groups/global_actions', {asynchronous:true, evalScripts:true, onComplete:function(request){done_thinking();}, onLoading:function(request){thinking();}, parameters:Form.serialize(this)}); return false;" method="post" action="/en/assignments/2/groups/global_actions" accept-charset="UTF-8">

Notice that the javascript is appearing inline, making things annoying to read. In rails 3, we use UJS (Unobtrusive Javascript) to separate this out. First we need to take out the Ajax callbacks and put in the :remote => true tag:


<%= form_tag url_for(global_actions_assignment_groups_path(@assignment)),
:remote => true do %>

and the html this generates:

<form method="post" data-remote="true" action="/en/assignments/2/groups/global_actions" accept-charset="UTF-8">

This is way simpler, but how do we achieve the same end result? The magic is happening with the data-remote="true" line. Rails UJS binds to any forms with that attribute and submits them via AJAX instead of POST. Now we just need to write event listeners to the appropriate Ajax callbacks. First we should give our form an id:


<%= form_tag url_for(global_actions_assignment_groups_path(@assignment)),
:id => "global_action_form",
:remote => true do %>

and then we can write the listeners:


<script type='text/javascript'>
$("global_action_form").observe('ajax:after', function(evt, status, data, xhr) {
thinking();
});


$("global_action_form").observe('ajax:complete', function(evt, status, data, xhr) {
done_thinking();
});
</script>

Note that this code should appear after the form that it is hooking to. Note that a UJS Ajax call has 6 events that can be hooked to:

ajax:before – Before the Ajax call
ajax:loading – before ajax call, but after XmlHttpRequest object is created
ajax:after – after ajax call is sent (note: not after it returns)
ajax:success – successful ajax call
ajax:failure – failed ajax call
ajax:complete – completion of ajax call (after ajax:success and ajax:failure)

Thats it. We now have the same end result using UJS.

Written by Erik

November 23rd, 2011 at 10:27 am

Test Framework – Bugs reports

without comments

After many hours spent exploring the different possibilities of the MarkUs tool, the team has found, by trials and errors, some bugs where some are still unresolved at that day. We are still performing some tests about the framework in order to assure the stability of the version against any action (here implied more specifically the misused of the tool itself by a grader or a student). It results from these many tests the (incomplete) list, here below. Here follows some of these errors :

Routing

  • Situation : The student tries to run his code before the expiration of the date

ActionController::RoutingError in Assignments#student_interface
No route matches {:action=>”render_test_result”, :controller=>”results”, :id=>1

Bug solved (view the related commit)

  • Situation : The student tries to run his code before the expiration of the date (behind the first error)

ActionController::RoutingError in Assignments#student_interface
No route matches {:result=>#<Result id: 5, submission_id: 5, marking_state: “unmarked”, overall_comment: nil, created_at: “2011-11-17 21:42:50”, updated_at: “2011-11-17 21:42:50″, released_to_students: false, total_mark: 0.0>, :controller=>”automated_tests”}

Bug solved (view the related commit)

  • Situation : The admin or the grader tries to see the students submissions

ActionController::RoutingError in Submissions#browse
No route matches {:action=>”edit”, :controller=>”results”, :id=>#<Result id: 4, submission_id: 4, marking_state: “unmarked”, overall_comment: nil, created_at: “2011-11-17 13:31:52”, updated_at: “2011-11-17 13:31:52”, released_to_students: false, total_mark: 0.0>}

Bug solved (view the related commit)

Record Not Found

  • Situation : The graders tries to collect all the submissions after the deadline is passed

ActiveRecord::RecordNotFound in SubmissionsController#collect_ta_submissions
Couldn’t find Assignment without an ID

404

  • Situation : Let’s assume that a group of students or maybe only one student (according to the condition of the practical work) has sent his work.
    Then the teacher wants to collect the work in order to go on the grading action. Then he presses the “collect and grade” button.

Let’s solve it !

Written by gbugnet

November 20th, 2011 at 4:14 pm

Posted in Developer Essentials

Tagged with ,

Punchlines – 18 november 2011

without comments

Here are the punchlines of our group (students from Centrale Nantes), working on the test framework of Markus.

Charline

Status :

I have solved one routing problem (when the admin or grader click on submissions (in the case where the student has hosted some files)

located some others routing problems

Next Step :

solving others routing problems

starting to write the state of the art (if we have no more routing

Claire

Status :

Continue to search other problems which block the writing of the test framework sate of art(Grader view)

Next Step :

Keep on trying to solve routing bugs using the list of existing bugs and write the state of art if the bugging views could be seen.

Benjamin

Status :

Listing some bugs of the markusproject

Next Step :

I will continue to have a look on the test framework

Roadblocks :

need to work in group, i don’t have the understanding of the code behind the framework.

Guillaume

Status :

Bugs listing, have a look at Ant files (build.xml and build.properties) for an ALGPR assignment.

Next Step :

Correct last bugs and finish the state of art.

Roadblocks :

Some problems with my rails server…

Bertrand

Status :

Made some commits solving 2 routing issue, and 1 test correction

Working on listing the bugs solved, and current bugs

Next Step :

Finish the list and work back on the state of the art

Karim

Status :

Trying to find and solve routing problems, I have found one and I am working on solving it.

Next Step :

Continue to search other problems which block the writing of the test framework sate of art(Grader view)

Written by gbugnet

November 19th, 2011 at 6:07 am

Posted in Status Reports

Tagged with ,

Markus UCOSP Fall 2011 – Meeting Minutes, Nov 16

with one comment

Meeting started at 3:15 p.m. and ended at 3:55 p.m.

  • Karen’s proposal to write a paper about the history of and our experiences with MarkUs has been accepted. It will be spearheaded by Morgan and will be presented at a conference in France in the spring
  • Severin has been blogging about the preliminary results of his performance analysis
  • Erik fixed his JavaScript issues and is planning to write a blog about it
  • Alex fixed the file uploading routing error for all file uploads as well as added all the necessary regression tests for them
  • Luke has decided to re-approach his submission rule problem and has written a blog post
  • Razvan finished setting up MarkUs on his computer after a hard drive failure and has all of the fixes for the annotation texts in a working state. He’s going to submit this review and then submit another one for the deprecated call to remote_function

Written by lkysow

November 16th, 2011 at 6:34 pm

Posted in Meetings,Minutes

render vs. redirect_to in Ruby on Rails 3

with 7 comments

Here’s what you need to know when you’re deciding between a render and a redirect_to in your controller action:

First, what do render and redirect do?

render will render a particular view using the instance variables available in the action. For example if a render was used for the new action, when a user goes to /new, the new action in the controller is called, instance variables are created and then passed to the new view. Rails creates the html for that view and returns it back to the user’s browser. This is what you would consider a normal page load.

redirect_to will send a redirect to the user’s browser telling it to re-request a new URL. Then the browser will send a new request to that URL and it will go through the action for that URL, oblivious to the fact that it was redirected to. None of the variables created in the action that caused the redirect will be available to the redirected view. This is what happens when you click on ‘Create’ in a form and the object is created and you’re redirected to the edit view for that object.

So which one should you use?

If you’re lucky, neither! If you don’t have a render or a redirect_to in your controller method for a particular action then Rails will automatically render the template for that action. For example if your action is new, rails will render the view for new: new.html.erb.

If you need to render another action’s view, you can use render :action_name. For example if the user has filled in a form at /new and they click ‘Create’, the form is posted to the create action. If there are errors with creating the object, in the create action you can use render :new to show the same form as before but with the error messages for why the object failed to be created. These errors can be displayed because the new template will have access to the variables in the create action. If you used redirect_to here, you wouldn’t be able to show the errors and anything typed into the form would be lost.

If you need the user to run a new action, use redirect_to :action => :action_name. For example if the user has clicked ‘Create’ and there are no errors in creating the object, you can use redirect_to :action => :show to show the successfully created object.

 Here’s an example of the correct uses for an imaginary Book controller:

#renders the 'new' view automatically

def new

  @book = Book.new

end

def create

  @book = Book.new params[:book]

  if @book.save

    redirect_to :action => :show #if the book is successfully created,

                                 #redirect to its show action

  else

    render :new #else render the new action again but with error messages available

                #from @book.errors and with the fields the user filled in available

  end

end

 

A small note on syntax:

Before Rails 3, to render a different action you would have to use render :action => "new" but now you can just use the symbol for the action: render :new

See http://guides.rubyonrails.org/layouts_and_rendering.html for more information.

Written by lkysow

November 16th, 2011 at 4:33 pm