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 breakpointsClicking 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.

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.

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

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 %>

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:

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:

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

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.

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

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