When I started to program Markus in RoR, I still think in the Java way, and find something very confusing. Here is some code I saw in Assignment class:

# Are we past the due date for this assignment?
class Assignment < ActiveRecord::Base
 # some code here

 def past_due_date?
    return !due_date.nil? &amp;amp;&amp;amp; Time.now > due_date
 end

 # some code here
end

I was curious of what “due_date” is, so I naturally did an “Open Declaration” in Eclipse IDE, which gave me no feedback at all. This happens because RoR types are dynamic, and type information is not available until run-time.

Then I searched for “due_date” across the whole project, and found some references of “due_date” but no definition of it at all.

What is it? Is it an instance variable? No, the name of an instance variable always begins with “@”. Is it a local variable? No, local variable should be initialised before being used. It should be a method. Yes, it’s a method, but where is it defined?

After turning to Mike and Severin, I eventually understood that “due_date” was not defined explicitly. It was created by ActiveRecord. ActiveRecord noticed that “due_date” was a column in the database table associated with Assignment, and therefore creates the “due_date” method (getter and setter) automatically. [The database schema]

This seems incredible to a Java programmer. In Java, a method should be explicitly defined before you use it. But in RoR, you don’t necessarily have to define a method to use it – methods can be created at run-time. Finally I realised this is why we call RoR “dynamic”. And for the first time I see the benefit of being dynamic: the chunky data-object mapping code is eliminated by the magic of dynamic!

Next time, when you cannot find the definition of something, don’t be panic, but think “dynamic”.

Brian Xu fixed three bugs:
512 -  UI: Show the graders name in the graders drop down —- http://review.markusproject.org/r/370/
531 – Graders need a way of “un-setting” Criteria —- http://review.markusproject.org/r/369/
571 – Edit Student: “Cancel” button links to something wrong —- http://review.markusproject.org/r/371/

Bryan Shen closed: #393. multi-level folder not allowed. Bryan also plans to blog about some things he has learned from working on Markus.

Brian Xu and Bryan Shen plan to get together and discuss how they are going to complete the flexible grading scheme.

Farah plans to return to working on the grade entry. She will update the review board so we can make comments on the code. The functional tests are still in the works.

Joseph has completed 564 – Validate files with a path with a space and check configuration on startup —- http://review.markusproject.org/r/358/. He hopes to get some time next week to look at will_paginate.

jerboaa figure out that urgent issue that arrived on February 4th.

Mike, feel free to assign this bug to someone else.  Everyone else, feel free to jump on it.

The Download Detailed Criteria produces a stack trace when grace days are allowed.  It works when there are no grace days.

undefined method `find_by_rubric_criterion_id’ for #<Class:0xb6e475f8>
RAILS_ROOT: /data/markus/instance/csc209-2010-01

Application Trace | Framework Trace | Full Trace
/u/drprj/.gem/ruby/1.8/gems/activerecord-2.3.4/lib/active_record/base.rb:1842:in `method_missing_without_paginate’
/u/drprj/.gem/ruby/1.8/gems/will_paginate-2.3.11/lib/will_paginate/finder.rb:170:in `method_missing’
/u/drprj/.gem/ruby/1.8/gems/activerecord-2.3.4/lib/active_record/associations/association_collection.rb:380:in `send’
/u/drprj/.gem/ruby/1.8/gems/activerecord-2.3.4/lib/active_record/associations/association_collection.rb:380:in `method_missing_without_paginate’
/u/drprj/.gem/ruby/1.8/gems/activerecord-2.3.4/lib/active_record/base.rb:2143:in `with_scope’
/u/drprj/.gem/ruby/1.8/gems/activerecord-2.3.4/lib/active_record/associations/association_proxy.rb:206:in `send’
/u/drprj/.gem/ruby/1.8/gems/activerecord-2.3.4/lib/active_record/associations/association_proxy.rb:206:in `with_scope’
/u/drprj/.gem/ruby/1.8/gems/activerecord-2.3.4/lib/active_record/associations/association_collection.rb:376:in `method_missing_without_paginate’
/u/drprj/.gem/ruby/1.8/gems/will_paginate-2.3.11/lib/will_paginate/finder.rb:170:in `method_missing’
/data/markus/instance/csc209-2010-01/app/models/assignment.rb:400:in `get_detailed_csv_report’
/data/markus/instance/csc209-2010-01/app/models/assignment.rb:399:in `get_detailed_csv_report’
/data/markus/instance/csc209-2010-01/app/models/assignment.rb:384:in `each’
/data/markus/instance/csc209-2010-01/app/models/assignment.rb:384:in `get_detailed_csv_report’
/data/markus/instance/csc209-2010-01/app/models/assignment.rb:383:in `get_detailed_csv_report’
/data/markus/instance/csc209-2010-01/app/controllers/submissions_controller.rb:431:in `download_detailed_csv_report’

Thanks,
Karen

Robert finished off the tests for the random Grader assignment. He plans to work on issue 569 – Investigate possible Grader Assignment problem by manually hammering on the grader assignments to see if they always update correctly onscreen.

He also plans to work on 559 – Allow Rubric Weightings to be 0 or negative. However, Karen would like to discuss how it should be done with Byron. Mike believes that Byron will be able to use the Flexible Criteria if we push hard enough.

Mike will be running next week’s meeting. Additionally, Karen would like to have a meeting on the reading week’s Friday Feb 19th.

Status

• Shipped fix for 510 for release 0.6
• Invited down to California for Facebook interviews. [Yay!]
• Kept up with discussion on reviews.

Next Steps

• Determine if my fix for 510 also resolves issue 569 for occasional non updates of grader assignments.
• Find more time to work on MarkUs. This should arrive next Thursday, and during reading week.

Roadblocks

• Lack of time due to interviews and other classes. 4 interviews with Amazon this week.
• Unable to conduct code reviews on many changes this week.

Mike

Status

• Reviewed a bunch of code
• Wrote a handy-dandy script that lets me test drive diffs-for-review quickly and easily. See http://mikeconley.ca/blog/2010/02/02/pre-commit-code-review-in-markus-development/ towards the bottom. I’m going to polish this tool up and upload it somewhere if people are interested in using it.
• Answered some emails, commented on the blog, tried to be helpful

Next Steps

• Look into Details CSV Report issue that Karen and Byron are having
• Upon (hopefully) fixing above, prepare patch (possibly including other fixes for 0.6 that have been committed)
• Review more code.
• Answer any more questions that people have. Fire away!

Roadblocks

• These past two weeks have been super busy. I have a feeling my two courses this semester are synchronized to bring the pain simultaneously. Coming up to a rest point though.

Bryan

Status

• Wrote my first unit tests!
• Closed #393 (”Repository folder does not allow paths such as “test/path1″, 393)
• Reviewed some code

Next Steps

• Work on #418: Changing an assignment’s due date doesn’t update the SubmissionRule’s cache
• Write a blog to share my newbie experiences
• Gain more RoR knowledge

Roadblocks

• There was an essay that took me almost two days!

Victoria

Status

• Completed MarkUs Usability and Interface Design Plan.

Next Steps

• Start prototyping for the group formation tab.

Roadblocks

• None

Joseph

Status

• I completed all the requests from the review. We are not longer
  escaping the validate script for the user. I have figured out a way to
  check for a validate script that does not have the spaces escaped by
  looking at the error code from p.open and then $?
• I found a second bug that I will write a blog post about so I can
  get into details and give code examples with pretty highlights

Next Steps

• Check-in the stuff I talked about above
• Still need to look at will_paginate

Roadblocks

• Next week is an extremely busy week

Farah

Status

• Didn’t get much time to work on MarkUs this week because I had three assignments due

Next Steps

• Will spend extra time on MarkUs this weekend and next week
• Finish functional tests for the grades table and submit a review request
• Work on the student UI

Roadblocks

• My other courses took up most of my time this week

Brian

Status

• Ticket 531,571,512 done
• Start to work on UI issue now

Next Steps

• finish test cases of above ticket
• write a blog to summary up a few discoveries

Roadblocks

• Intensive reading of papers

Topic A1:  Upload/Download CSV file – Replace Accordion Menu with Button + Modal Dialogue

Description: To replace the current accordion menu upload/download options with upload and download buttons running along the top of the view.  Let’s call these “Action Buttons”.

Next Steps:

• These action buttons will spawn a modal dialogue (similar to the interface we currently have for adding a new student to a group in the Groups & Graders view), where the user can specify the location of the CSV file to upload or download.
• To avoid confusion and maintain consistency, will have to apply this migration throughout the entire project.

Rationale: Having the accordion menu on the side will greatly affect the readability of the 2-pane Assign Graders view.  Also, the accordion menu has caused confusion amongst users in the past, so switching to modal dialogues may improve the usability of MarkUs as a whole.

Topic A2:  Reorganize Action Links & Action Buttons

Note:  “Action Links” refer to the action items to the right of the page header located at the top of every view.

Description: Current prototype inherits action links from the existing release of MarkUs.  However, if we were to replace the accordion menu with action buttons running along the top of the view (right-to-left), these may interfere with the existing action links we already have running from the left to the right.

Next Steps: Compile a list of action links and buttons that we will have for each view.  Analyze the list and see how we can categorize, trim down, or reorganize the layout of these options.

Rationale: As mentioned in the description, the left-to-right action links may potentially interfere with the right-to-left action buttons.

Section B: Assign Graders Tab

Topic B1:  Do Not Need a Review/Read-Only Mode

Description: In the prototype, users are automatically put into a read-only mode so they can view existing grader-to-group assignments.

Next Steps: Users will now be automatically put into the edit mode where they can create new grader-to-group assignments and make changes to the existing ones.

Rationale: Typically, users only use the Assign Graders feature during the initial setup/creation of a new assignment.  And if they were to revisit this view, it would probably be to make changes to the current grader-to-group assignments.

Topic B2: Allow for Multiple Grader Selection

Description:  In the current prototype, more than one grader can be selected in the Graders pane.  But do we have use cases where more than one grader would be assigned to the same group of students?  Should these checkboxes be radio buttons instead?

Next Steps:  Keep the checkboxes and allow for multiple users to be selected!

Rationale:  It’s very possible that more than one grader would be assigned to the same group of students.  Also, we will be implementing a feature that helps the user evenly distribute selected groups amongst selected graders.

Topic B3:  Introduce “Select All” and “Clear All” Buttons

Description:  These were not introduced in the current prototype.

Next Steps:  Need to add “Select All” and “Clear All” options for both the Graders pane and the Groups pane.

Rationale:  User(s) most likely wouldn’t want to manually select all the graders and/or groups.

Topic B4:  Evenly Distribute Selected Groups Amongst Selected Graders

Description:  As mentioned in Topic B2, the current prototype does not support this feature.  We will be adding this feature, but how should this be implemented?

Next Steps:  Possibilities:

• Have a button that allows users to select the next n groups that they would like to assign graders to.
• Select a set of graders and evenly distribute the (selected) groups sequentially or randomly amongst them.

Rationale:  A useful feature that is implemented in the current release of MarkUs, and is one that we will definitely want to keep.

Topic B5:  Include Graders’ Full Names (In Addition to User IDs)

Description: (Feature Request) The existing release of MarkUs only lists the user IDs of the graders in the Groups & Graders view.  With a large number of graders, it becomes hard to differentiate between graders solely by their user IDs.

Next Steps: Add full names of graders to the Graders pane.

Rationale: To make it easier for users (in particular, instructors) to differentiate between graders.

Section C: Group Formation Tab

Topic C1: Provide Student List for Group Creation

Note: This change will be made in the grader and instructor interfaces only.  Due to privacy issues, students will not have access to the class list when they are creating the groups themselves.  Students will be expected to know their group members’ user IDs.

Description: The user currently has to draw on their own records for the user IDs of the students that they would like to put into a group.  This is mainly because the list of (unassigned) students is not currently made available to the user at the time of group creation.

Next Steps:  Rework the existing Group formation tab interface so that users have access to the list of (unassigned) students when they are creating a new group.  One possible option is to use a layout similar to the prototyped Assign Graders view where the list of (unassigned) students will be placed in a pane where users can make multiple selections.

Rationale: To prevent the user from having to draw on their own records for the current list of (unassigned) students.

Topic C2:  Provide a List of Unassigned Students When Adding Members to an Existing Group

Note: This change will be made in the grader and instructor interfaces only.  Students will not be allowed to make changes to their groups.  Only graders and instructors have permission to do so.

Description: The user currently has to draw on their own records for the user IDs of the students that they would like to add to an existing group.  A read-only list of unassigned students is provided to the user in the current release of MarkUs.  However, the user loses access to this list when they actually have to enter the user IDs of these students.

Next Steps:  There are various ways of addressing this problem.  However, we need to come up with a way of visualizing large class lists (e.g., possibly 500+ students) such that graders/instructors can easily find the student(s) that they are looking for.  Some ideas:

• Drop down menu
  • However, finding a specific student in a large list of unassigned students may be extremely difficult (with a lot of scrolling involved).
• Drop down menu + search feature

Rationale: To prevent the user from having to draw on their own records for the current list of unassigned students.

Others

Research/Field Work:

• Ask users about their most wished for shortcuts/features (e.g., shortcut to evenly distribute groups amongst graders)
• Go through different views and tally the number of items for the accordion menu in that view.
  • Purpose: To see if replacing accordion menu with buttons is a feasible.  This would also give us a sense of how big the change will be if we apply this to the entire project.  We may also discover existing options in the accordion menu that works best in an accordion menu.

In the markus code, there are a lot of places where we use markus_config_&lt;something&gt; instead of MarkusConfigurator.markus_config_&lt;something&gt;. We should start using the latter. He’s why:

ensure_config_helper.rb

def self.check_config()
puts "Checking #{markus_config_logging_logfile}"
puts "Checking #{markus_config_logging_errorlogfile}"
puts "Checking #{markus_config_repository_storage}"
puts "Checking #{markus_config_validate_file}"
puts "Checking #{MarkusConfigurator.markus_config_logging_logfile}"
puts "Checking #{MarkusConfigurator.markus_config_logging_errorlogfile}"
puts "Checking #{MarkusConfigurator.markus_config_repository_storage}"
puts "Checking #{MarkusConfigurator.markus_config_validate_file}"
check_in_writable_dir(markus_config_logging_logfile, "MARKUS_LOGGING_LOGFILE")
check_in_writable_dir(markus_config_logging_errorlogfile, "MARKUS_LOGGING_ERRORLOGFILE")
check_writable(markus_config_repository_storage, "REPOSITORY_STORAGE")
check_readable(markus_config_repository_storage, "REPOSITORY_STORAGE")
if ! RUBY_PLATFORM =~ /(:?mswin|mingw)/ # should match for Windows only
check_executable(markus_config_validate_file, "VALIDATE_FILE")
end
end

Output from running rake test:units When loading everything up:

Checking log/info_development.log
Checking log/error_development.log
Checking /home/jmate/everything/workspaces/repos
Checking /home/jmate/everything/workspaces/markus/config/dummy_validate.sh
Checking log/info_development.log
Checking log/error_development.log
Checking /home/jmate/everything/workspaces/repos
Checking /home/jmate/everything/workspaces/markus/config/dummy_validate.sh

At this point, &lt;blah&gt; == MarkusConfigurator.&lt;blah&gt;

When running the test cases:

/tmp/ensure_config_helper_test_777699315/log/log_info_file.log
Checking log/info_test.log
Checking log/error_test.log
Checking /home/jmate/everything/workspaces/repos
Checking /home/jmate/everything/workspaces/markus/config/dummy_validate.sh
Checking /tmp/ensure_config_helper_test_777699315/log/log_info_file.log
Checking /tmp/ensure_config_helper_test_777699315/log/log_error_file.log
Checking /tmp/ensure_config_helper_test_777699315/source_repo_dir
Checking /tmp/ensure_config_helper_test_777699315/validate_script.sh
/tmp/ensure_config_helper_test_595310852/log/log_info_file.log
...
...
...
Checking log/info_test.log
Checking log/error_test.log
Checking /home/jmate/everything/workspaces/repos
Checking /home/jmate/everything/workspaces/markus/config/dummy_validate.sh
Checking /tmp/ensure_config_helper_test_473533902/log/log_info_file.log
Checking /tmp/ensure_config_helper_test_473533902/log/log_error_file.log
Checking /tmp/ensure_config_helper_test_473533902/source_repo_dir
Checking /tmp/ensure_config_helper_test_473533902/validate_script.sh

Now you can see that &lt;blah&gt; != MarkusConfigurator.&lt;blah&gt; . So the namespace for the method you are trying to call cannot be ambiguous. In the source code above you must use MarkusConfigurator.&lt;blah&gt;.

Mocking Modules with Mocha

I could not find any examples on mocking modules with mocha. It’s probably because it’s so easy! It’s just like mocking an instance of a class.

the_module.rb :

module TheModule
def the_module_function
return "the real value"
end
end

test.rb :

require "test/unit"
require "mocha"
require "the_module"
include TheModule

class TheModuleTest < Test::Unit::TestCase
# replace 'the real value' with 'the mocked value'"
def test_it
assert TheModule.the_module_function == "the real value"

TheModule.stubs(:the_module_function).returns("the mocked value")

assert TheModule.the_module_function == "the mocked value"
end
end

Running the tests:

jmate@CalculatorJozef:~/everything/workspaces$ ruby test.rb
Loaded suite test
Started
.
Finished in 0.00096 seconds.

1 tests, 2 assertions, 0 failures, 0 errors

Nested Contexts

I learned a new trick with shoulda. Credit goes to: http://www.viget.com/extend/reusing-contexts-in-shoulda-with-context-macros/

You can nest contexts inorder to resuse them.

Here is a quick example I prepared:

context "we have a temp dir" do
setup do
@temp_dir = "/tmp/temp_#{rand(1073741824)}"</pre>
@log_dir = "#{@temp_dir}/log"
@file = "#{@log_dir}/file"
FileUtils.mkdir( @temp_dir )
end
teardown do
FileUtils.rm_r( @temp_dir )
end
should "be able to test with the temp dir" do
end

context "we have a log dir" do
setup do
FileUtils.mkdir( @log_dir )
end
should "be able to test with the temp and log dir" do
end

context "we have a file inside the log dir inside the temp dir" do
setup do
FileUtils.touch( [@file] )
end
should "be able to test with temp, log and file" do
end
end
end
end

Permissions, Directories and Ruby

I recently learned that if you remove the execute bit on a directory and try to rm -r the parent directory then you will be unable to remove the executable directory. However, this works in a terminal.

Example in ruby:

#!/usr/bin/env ruby
require 'fileutils'
include FileUtils

@parent_dir = "/tmp/parent_#{rand(1073741824)}"
@test_dir = "#{@parent_dir}/test"
@file = "#{@test_dir}/file"

FileUtils.mkdir( @parent_dir )
FileUtils.mkdir( @test_dir )
FileUtils.touch([ @file ])
FileUtils.chmod( 0600, [ @test_dir ])
FileUtils.rm_r( @parent_dir )

Output from script:

jmate@CalculatorJozef:~/everything$ ./test.rb
/usr/lib/ruby/1.8/fileutils.rb:1297:in `unlink': Permission denied - /tmp/parent_674314876/test/file (Errno::EACCES)
from /usr/lib/ruby/1.8/fileutils.rb:1297:in `remove_file'
from /usr/lib/ruby/1.8/fileutils.rb:1302:in `platform_support'
from /usr/lib/ruby/1.8/fileutils.rb:1296:in `remove_file'
from /usr/lib/ruby/1.8/fileutils.rb:1285:in `remove'
from /usr/lib/ruby/1.8/fileutils.rb:756:in `remove_entry'
from /usr/lib/ruby/1.8/fileutils.rb:1335:in `postorder_traverse'
from /usr/lib/ruby/1.8/fileutils.rb:1335:in `postorder_traverse'
from /usr/lib/ruby/1.8/fileutils.rb:1339:in `postorder_traverse'
from /usr/lib/ruby/1.8/fileutils.rb:1334:in `postorder_traverse'
from /usr/lib/ruby/1.8/fileutils.rb:1333:in `each'
from /usr/lib/ruby/1.8/fileutils.rb:1333:in `postorder_traverse'
from /usr/lib/ruby/1.8/fileutils.rb:1334:in `postorder_traverse'
from /usr/lib/ruby/1.8/fileutils.rb:1333:in `each'
from /usr/lib/ruby/1.8/fileutils.rb:1333:in `postorder_traverse'
from /usr/lib/ruby/1.8/fileutils.rb:754:in `remove_entry'
from /usr/lib/ruby/1.8/fileutils.rb:612:in `rm_r'
from /usr/lib/ruby/1.8/fileutils.rb:608:in `each'
from /usr/lib/ruby/1.8/fileutils.rb:608:in `rm_r'
from ./test.rb:14

Example in terminal:

jmate@CalculatorJozef:/tmp$ mkdir parent
jmate@CalculatorJozef:/tmp$ mkdir parent/test
jmate@CalculatorJozef:/tmp$ touch parent/test/file
jmate@CalculatorJozef:/tmp$ rm -r parent

As you can see from the output above. I had no trouble doing this in the terminal.

It might have something to do with not being able to cd into a directory that does not have the execute bit set.

I hope the knowledge I pass on helps you guys:

Ruby Permissions and Directories

Nested Contexts

Mocking Modules with Mocha

Weird Behaviour With Mocha

Cheers,
Joseph

The IRC log can be found here

Agenda

• Feedback from users
• Round table
• Other issues

Feedback from users

• We’ve been getting great feedback so far!
• Karen has been keeping us posted through the mailing list

Round table

• We had a pretty big group today, including our friends from France!
• Nelle has been working on implementing sections and adding students to sections. She has a couple of UI issues right now. Nelle is going to try and stay in touch with Victoria to make sure they’re not working on conflicting things. Nelle has also been looking into moving over to Machinist.
• Benjamin is working on translating MarkUs into French.
• Farah has been working on unit tests for the grades tables (and fixing some bugs related to the table as well).
• Brian worked on unit tests for Ticket #570.
• Robert has been busy with interviews this week.
• Bryan worked on Ticket #393 and is now working on tests.
• Joseph has been working on Ticket #574. We decided to put a comment in the setup file that explains why quotes around the path are necessary and then check whether or not the validate program runs.

Other issues

• Karen would like to see descriptions of tickets in our punchlines (instead of just the ticket numbers)
• The French team will be posting reports here every couple of weeks
• We are looking for students for an NSERC USRA for the summer
• Victoria is going to be creating a blog post about the wireframes she has created so far for TA assignment

Read-Only Mode — which we will most likely no longer have:

Overview: UI that allows user to view existing grader-to-group assignments.

Edit Mode — will be the new default UI when user opens up the Assign Graders tab:

Assign Groups: UI users will use to create/modify grader-to-group assignments.

Assign Groups: Example of user interaction in edit mode.

That’s all for now!

Status

• Fixed the functional tests!  Yeah!
• Put the functional tests on markusproject.org homepage – though they act funny in an “off and on” sort of way…
• Reviewed some code
• Closed #530 (next/prev submission links in grader view no longer skip completed assignments in 0.6 – needs to be pushed to trunk)
• Wrote a blog post about closing #531:  http://blog.markusproject.org/?p=1103

Next Steps

• Review more code as it comes in
• Turn the rest of Byron’s email into tickets (can’t believe I haven’t finished that yet)
• Take a look at some other high-priority fixes maybe to patch 0.6
• Brace myself for possible MarkUs support…CSC148 and CSC209 assignments due tomorrow.

Roadblocks

• This is a heavy week and a half for me – that’s why I did most of my work over the weekend.  Might not respond to email this weekend, and will be pretty bogged down until next Wednesday sometime.

Brian

Status

• 1 post on Markus blog
• Finished #570 units test cases, change committed

Next Steps

• Fix some bugs on weekends .

Roadblocks

• Job hunting, 1 graduate course that requires intensive reading of papers, 1 research project

Victoria

Status

• Completed first set of wireframes for the Assign Graders View.
• Got useful feedback from Karen and Farah during last night’s UI meeting.

Next Steps

• Start prototyping for the Group tab.  That is, the view users use to create new groups and modify existing groups.
• Summarize new usability issues and ideas from last night’s UI meeting and write a blog post about it.

Roadblocks

• Learning how to use a new application for prototyping.  I’m slowly getting the hang of it!

Joseph

Status

• handling validate files with a space and checking configuration on startup is on reviewboard
• ticketed the paging bug where the page number and page size are not saved in a bookmark or when hitting back/forwards
• did rudimentary research on will_paginate – have not found anything so far

Next Steps

• finish up the codereview
• complete research on will_paginate
• conclude which method to approach the pagination problem after research is complete

Roadblocks

• see reviewboard for the discussion that just arose about the function in PathHelper: http://review.markusproject.org/r/358/#comment923

Bryan

Status

• Working on #393, Reviewing code, learning Ruby and Shoulda.

Next Steps

• Solve more tickets.

Roadblocks

• Not enough knowledge of Ruby, testing, and Markus’ structure.

Nelle

Status

• Work on implementing creating section and to adding students to them
• Started to look on how to migrate smoothly to Machinist

Next steps

• Implementing the group members from same section limitation
• Improving the UI on the different parts implemented this week

Roadblocks

• None

Robert

Status

• Working on tests for my fix for 510, otherwise Halted.
• Reviewed changes from team members as they come in.

Next Steps

• Find time to work on MarkUs.

Roadblocks

• Many consecutive interviews [Google, Microsoft, Amazon, Facebook], midterms, and assignments all at once.

Farah

Status

• Fixed a bug related to alphabetical pagination which was causing the alphabetical categories to get re-calculated each time the user switched between pages instead of only when the number of items per page is changed (and learned about session variables)
• Re-factored code to make the GradeEntryFormsController lighter by moving some things to the model instead
• Finished the unit tests for the grades table
• Dropped in on the UI meeting on Wednesday

Next Steps

• Finish functional tests for the grades table
• Student interface for grade entry forms

Roadblocks

• None this week

1. Class methods

This works great if your setup varies significantly between tests of a method, but you still want almost the same thing (or the exact same thing) to happen in each of the cases. You can create class methods in test class to re-factor tests like this. The key part is that you define the method prior to the highest-nested level context of any test that will use the method. I like naming them starting with should_ to clearly indicate what they’re for

def self.should_flip_active
  # Put your should statements here, including should "..." do ... end and should_*
end

2. Iterating over a set of test data

With unit tests, we shouldn’t really be using fixtures and loading everything from the database. Instead, you might just set up the few attributes that you need on a model instance to test a method on it. If you want to do this for slightly different data, then you can use either a hash or an array and make a context for each of them!

Structure with an array:

['c6conley', 'g9merika'].each do |user|
  context "with user "+user do
    # Put your setup and should statements in here - you could even make it nested further!
  end
end

Structure with a hash:

{ 'c6conley' => 5, 'g9merika' => 8 }.each do |user, section|
  context "with user "+user do
    # Do some tests on user with section
end

One last comment on Shoulda – I’ve found that you can only access assigns, e.g. assigns(:student).some_student_attribute from within should blocks. I’ve run into some problems when running my tests if I try to use assigns or a class variable like @student within an open area in a should statement. Here’s some examples:

should "work" do
  assert_equal 'hello', assigns(:student).user_name
end

# should not work
should_set_the_flash_to assigns(:student).user_name

should "work" do
  assert_contains flash.values, assigns(:student).user_name
end

Happy Shoulda testing!

Our original steps for the Notes system implementation went as follows:

1. Design the model.
2. Create mock-ups of the user interface.
3. In parallel, design the Notes tab and the modal dialog interfaces (for groupings).
4. Extend this functionality to assignments and to students once the notes system is solid for groupings.

We have completed the first three steps, including unit and functional tests. Thanks to the polymorphic, “noteable” idea that we used for the relationship between a note and a grouping, the only work necessary to have notes on a different object type is to:

• add a “display_for_note” method to the model, like we did for groupings – this allows us to display these notes
• modify the create a note form in the Notes tab to allow for other types of noteable objects than just groupings
• add a link to the modal dialog in an appropriate location for the object type

For now, I can’t see the best place to place a link to a modal dialog to create a note associated to an assignment or to a student, so I would recommend just adding that functionality to the Notes tab.