OLM On Rails

Internal Test Server

leave a comment »

We have an internal test server set up, now. Everybody interested in the current state of development is very welcome to experiment with it. We are doing our best to keep this test server at a very recent state of development. Feedback, bug reports, etc. are greatly appreciated. Interested people who have access to lab 2270 in Bahen can go to desktop machine b2270-20 and try it out. There is a user ‘test’ with password ‘test’ set up and you should find a link to the test server (running cutting edge OLM) available on the desktop after login. Then, use username ‘s’ and some password (having more than one character) to log in to checkmark. If you have questions, we are sitting right next to you ūüôā Thanks!


Written by jerboaa

May 22, 2009 at 11:38 pm

Posted in Uncategorized

Tagged with

Goals for the summer

with 2 comments

We are already two weeks into the summer and I haven’t published the promised set of goals for the summer. ¬†This happened partly thanks to my procrastinating, and partly because Nelle, Mike, and Severin dove into the project with such vigour that I was afraid of holding them back.

Nevertheless, we need to keep our eyes on the goals:

0. Refactor the database schema and finish the refactoring from last term

This wasn’t on my original set of goals, but was identified on day 1 by Nelle, Mike, and Severin as the first step. ¬†We did a big refactoring last term, and not all of the dead code was removed. ¬†We are well on the way to completing this task.

1. Deployment.

This is the most important goal of the summer.  We plan to use OLM in the classroom in September so all decisions on features this summer will be based on whether or not they can be fully completed by September.   

The two things we are doing to work on this goal are that we will be meeting with Alan in the last week of  May to figure how to get an intermediate version running on our production server.  Hopefully if we spend time on this in late May and early June, we can iron out the system administration aspects of deployment.

Also, Severin is working on a test server that we can frequently update both to run tests and to use a demo server so that we can start to try out some of the new features on other instructors and students.

2. User permissions and visibility  

The roles (student, ta, instructor) exist in the code but we aren’t doing full checks to make sure that users can see only the views they are supposed to.

3. File submission backend

It would be really nice to use a version control system to store the student file submissions.  The current plan is to build an abstraction layer for file add, delete, replace, and view.  This will allow us to build 3 versions of the backend: an in-memory store for testing, a file-based store for simplicity and completeness, and the desired SVN store.  There are a bunch of design issues here that are unresolved.

4. TA mapping

The view that allows an instructor to attach TAs to the groups that they will mark is incomplete.

5. Administrative interface

This version of OLM includes a web interface for the instructors to do all the setup for an assignment. ¬†This includes assignment setup, group formation, rubric creation, downloading data (grades, annotations, files), and probably a few other things. ¬†We haven’t put any thought into the UI for this yet, so that’s on the list.

6. Grader view

This view is mostly complete, but it needs to be tightened up and made prettier.  Undoubtedly, it needs more testing.

7. UI design

We’ve spent most of the effort so far (with a few exceptions) on the back end, so we have lots of work to do on the UI. ¬†Fortunately, we will be able to work with a Season of ¬†Usability student on this part of the project.


No list of goals would be complete without a list of the new feature that would be nice to have. ¬†I’m not sure how many of these we will be able to get to, but I’m hoping we can get a few of them in.

  1. Logging: I’d like to be able to log all events and display them to the instructor.
  2. Metrics: ¬†I’d like to be able to display graphs and different views of the data we collect such as mark breakdowns, histograms of marks, number and length of annotations, number of submissions per group, etc.
  3. Mark entry:  If OLM becomes really useful, it would be nice to have a view to use to enter grades from another source such as lab marks or test marks.
  4. Another marking scheme:  The rubric approach has proven to be pretty flexible, but it would be nice to have another way to specify a marking scheme.
  5. Automated testing: ¬†This one is the highest priority long term goal. ¬†I don’t think we will get to it this summer, but I would like to be able to allow students to submit their code, and receive immediate feedback from an automated system.¬†

Written by Karen Reid

May 22, 2009 at 1:13 pm

Posted in Uncategorized

Assignment submission design issues

leave a comment »

One of my long term goals with OLM is to support automated testing where students could submit code and get immediate automated feedback. ¬†They might do this multiple times before submitting a final version. ¬†This means that we need to be able to keep multiple versions of a student’s submission. ¬†So, rather than inventing an ad hoc way to do this, our plan is to store student submissions in an SVN repository.

We don’t want to write a full subversion interface in OLM, partly because it just seems wrong, and partly because I’m not sure that there is good motivation to ask our first year students to use a version control system for their assignments.

Let’s first look at the issues from the point of view of a first year student who doesn’t know about how the files are stored in OLM. ¬† When a student uploads a file with the same name as one that was previously updated, the new file becomes the new version. ¬†From an SVN point of view no attempt is made to merge the files. ¬†I don’t think there is a problem with this scenario, but students who understand how SVN works may not expect this behaviour.

However, if students are already using repositories for their assignment work (as they do in our second year programming courses), it would be really nice if OLM could just use those repositories.  When we use repositories in our courses, students submit assignments by committing files to their repo before the due time.

Design question 1: ¬†Should students who are already using repositories have a web interface to “submit” their assignment?

If they do have a web interface, it complicates OLM’s job, because OLM then has to worry about conflicts. There may also be confusion for the students about which mechanism to use, and the differing behaviour between the two mechanisms. Students may need to worry about dealing with conflicts and merging changes when they are actively using a repository.

Design question 2: ¬†Do students need to be able to submit directories through the web interface? ¬†Should a student’s submission be able to include subdirectories?

The issue here is whether the web interface for assignment submission needs to support the ability to create and delete directories, or whether we can just support browsing them. ¬†Here again there is a distinction between the cases where the students are actively using the repositories and where they have only the web interface for assignment submission. ¬†If students have direct access to the repository, then it makes sense to do all directory adds and removes through SVN. ¬†If they don’t have access to the repository, then do they really need subdirectories? ¬†(We didn’t support subdirectories in the original OLM.)

Opinions are most welcome.

Written by Karen Reid

May 22, 2009 at 12:33 pm

Posted in Uncategorized


leave a comment »

The time has come to completely incorporate groups into checkmark. With various discussions with Karen and the crew here are the changes I am going to make to the schema and where I will be heading in the future. But first …

Where We Are

Currently, checkmark supports the simple case where an assignment has groups of a specified size. These groups can be made by the instructor manually or through a CSV upload (which is incompletely implemented – a little bit more on this later) and also by the students themselves. Basic group creation currently works with the current schema: (Which does not include the rubric or annotation stuff) which is explained by Geofrey here.

But, from a need for error checking groups on creation (mainly through the CSV upload) as well how classes like CSC301 run, I decided that we must incorporate a group name (auto-generated or provided) to distinguish between groups. From this we decided to do a small (and hopefully final) revamp on the schema to support the following 3 cases:

  1. Situations when students choose to work in groups but can choose to work alone on an assignment;
  2. Situations when groups do not persist across assignments;
  3. and situations when groups persist across assignments (But sometimes the members of a
    group might change)

To support these cases, there are a number of front end and back end changes that need to be made. The front end is fairly straight forward and so I am going to focus on the back end for this post.

Back end Changes

We decided to support these cases with very few changes to the schema. We are going to remove the assignments_groups table and maintain the groups-assignments associations solely in the memberships table with the addition of an assignment_id field.  So, the schema now looks like this (Sorry for the change of format from the above picture):

The above cases are now supported as follows:

  1. Students who choose to work alone will have one entry for the specific assignment in the memberships table, this is the same as the current situation with the addition of the assignment_id field.
  2. If groups do not persist across assignments, again, this is currently supported.
  3. If groups do persist, then each student will have a distinct entry in the memberships table for each assignment. This way, memberships can change across assignments by simply changing that students group_id for that assignment and all previous assignment memberships will be maintained. Every time an assignment with persisting groups is created, all the groups from the previous assignment will be copied over by duplicating the entries for the previous assignment and updating the assignment_id.
  4. But this situation is a bit more complicated. Most likely, instructors are going to set up all assignments at the beginning of the term and so the memberships entries for those assignments may already exist before the assignment is released. So, to ensure that each assignment has the most up-to-date group information, we will cascade any group modification actions that happen on any previous assignments to the future (and maybe currently open — by an extension) assignments. This is an expensive operation, but it is not likely to happen often.

It seems that few changes to the schema actually supported what we wanted, without sacrificing much performance (hopefully I am right in claiming this).

Where We Are Going

Now I am going to outline where I plan to go in the future.

Schema Changes

I am going to apply all the schema migrations within the next couple of days.

The relationships within the models do not actually change, since assignments_groups was simply a join table and does not hold any extra information on the relationship.

Changes to the Models and Controllers

  • I am sure there will be some refactoring that will need to be done, so I will revisit the old code and make sure everything that worked before still works.
  • I need to fully incorporate the group names, allowing the instructor to choose when the names will be auto-generated or provided by the user and when the group names should be viewed as well as who can view them.
  • Complete the CSV upload, with proper error checking and group creation.
  • Implement the functionality (front end and back end) described above for persisting groups.
  • … etc. I am sure there is more.

But before I make these changes, I am going to try something I have never tried before and which should be interesting…

Unit Testing, Unit Testing, Unit Testing and Test Driven Development

I am going to try my hand at test driven development and write all the unit tests required to (hopefully) adequately test all of the group functionality. Not only that, I am going to keep a journal of sorts and blog about it! So stay tuned for exciting unit testing goodness.

Written by Catherine

February 12, 2009 at 3:05 am

Posted in OLM on Rails

Prototype/Ajax.Request -> Rails SOLVED!

with one comment

Problem solved!¬† I’m super psyched – I can finally continue developing for our demo on Dec 3rd.¬† Whew!

The problem lay where I didn’t expect it – it was Firebug.¬† I was using an alpha version of Firebug, which hadn’t updated itself to the latest version.¬† It was capturing the AJAX POST request going out, but didn’t let the parameters carry through.¬† So, I updated to Firebug 1.2.1, and I’m set.¬† Everything’s jake.

Whew.¬† I was really starting to lose it, there.¬† Back to work…


Written by Mike Conley

November 23, 2008 at 5:09 pm

Posted in Uncategorized

Prototype/Ajax.Request -> Rails – The Plot Thickens Part 2

with one comment

Still no solution in sight.¬† I’ve tried creating a brand new Rails project, and the behaviour persists there as well.¬† I’m convinced it’s a problem with Rails though, and not a problem in my machine.

Let’s go over the facts again:

  • I have Rails 2.1.0 installed on an Ubuntu 8.04 Hardy Heron Tablet PC
  • I’m using a Postgres database on the OLM project
  • Using Prototype JS library V
  • We’re using Mongrel, not WeBRICK
  • Using Ajax.Request with the ‘POST’ method does not pass any parameters to the params hash in the target controller
  • It works with GET though!
  • When using POST, I can see the parameters if I inspect the request object – they’re in @parameters, which I cannot seem to access
  • POSTing seems to work on other computers, using the same OLM code checked out from the repository
  • I’ve tried a complete reinstall of Rails, with the same result

Maybe my uninstall assumption is wrong:¬† what’s the best way to completely purge Rails from my machine?¬† I essentially followed these steps before:

Thoughts from anybody?



Written by Mike Conley

November 21, 2008 at 3:04 am

Prototype/Ajax.Request -> Rails – The Plot Thickens

leave a comment »

So, no solution in sight yet – but I’ve localized the problem.

The parameters pass fine on Geofrey’s computer.¬† That’s good news.

The bad news, is that I did a full uninstall of Rails/Ruby on my machine, and then reloaded the whole thing from scratch…and the bug remains.

Super frustrating.


Written by Mike Conley

November 19, 2008 at 5:29 pm

Posted in Uncategorized