Tag Archives: ruby

Summer Work: Week 1

For this summer, the Computer Science Department at UofT has hired me to continue my work on the OLM project.  Click on that link, or check out my other post about OLM to see what it’s all about.

I just finished my first week of work, and it finished with a long weekend.  Not bad.

And I’ve got a great team – I’m working with Severin Gehwolf and Nelle Varoquaux, both excellent thinkers, programmers, and collaborators.  Severin is a UofT student like myself, and Nelle has flown in specially from France (!) to work with us.  They’re great, and we’re going to get a lot done.

So what have we to show for our first week of work?

Well for starters, we’ve gutted the entire database schema of OLM.  We started right from the bottom, and worked our way through every component of the database, trying to figure out what we could cut, trim, expand, and refactor.

And there was plenty to do.  This version of OLM has been in the works for a while now, and there have been plenty of awesome people working on it – but there’s been a variety of Ruby/Rails/JavaScript experience, and the cracks show.

I, myself, came into this project with no Rails experience whatsoever, and while I think I now more or less get the drift, I’m still by no means an expert.  Anyhow,  I’m looking at my old code too, and kind of grimacing.

But the ideas are all there.  It’s like a big hunk of marble that a whole lot of people gnawed and chiseled at for a little bit, trying to make a sculpture.  After the big DB schema refactor, I think the whole team can sort of see the rough form of what this thing is trying to become, and now we just need to carve it out.  Luckily, instead of a few hours per week like the last few semesters, we get a full summer to focus on it.

So, with the DB refactor done, the first thing has been to redesign the models/controllers to play nice with our new database tables.  It was scary, because after the refactor, everything broke – but we’re working on it, and it’s slowly starting to come back.

We’ve also decided to switch the file storage back-end.  Up until now, we were using Ruby to organize a file system back-end to do simple versioning of submitted files.  One of our goals this summer, is to build an abstraction layer that will allow us to choose different options for this versioned storage back-end.  In particular, we aim to support Subversion.  That’s right – a web-based Subversion front-end that supports commits, and catches (but doesn’t resolve) conflicts.  It’s a fun thought.

I have a feeling this is going to be a very interesting part of our project, and I’ll probably report on it more as it develops – but as it stands, it’s still being conceived on wipe-boards and scrap paper.

Anyhow, I’ll try to keep this blog up to date with what we’re doing.  Or maybe I’ll keep this blog up to date.  I’m conflicted.

Who knows, maybe this will be my last blog post of the summer.  I won’t lie – after working 8 hours on a computer, the last thing I want to do is come home and write a blog post.  If anything, my posts will probably wait until the weekends.

But we’ll see.

OLM: What is it?

I’ve mentioned the OLM project a few times, and more than once, I’ve been asked:  “What is this OLM thing you keep talking about?”

So that’s what this post is for:  to provide a plain-English explanation of what OLM actually is/does.

Note: I can’t guarantee that the history of OLM is entirely accurate – I’m assembling this from hearsay, and personal accounts.  If there are any corrections to be made to this post, please comment or email me.

Part 1:  How it Used to Be

Computer Science students, at one point or another, have to computer programs for their assignments.  These programs are written in a myriad of languages (Java, Python, C, the list goes on…), and have to be marked by teaching assistants.

Originally, after students submitted their completed programs, the TA’s would print off the source code and write on the printouts to give feedback on how the code was written.  They would also use a rubric to grade the overall assignment based on predetermined criteria – which isn’t at all unusual in grading student work.

That’s how it used to be.

Part 2: The Birth of OLM

One day, the Computer Science Department at UofT decided that they wanted to write a web application for instructors to manage assignments, and to receive student submitted code.  They also wanted TA’s to be able to log in, and mark the code, almost as if they were doing it on paper.

So OLM (On-Line Marking) was born.  It was written in a web framework called TurboGears by a group of undergraduate students.

And it wasn’t bad.  It’s still used in the department to this day.

Part 3:  OLM is Reborn as…Checkmark…or OLM…or something

The original OLM has a few deficiencies.  The instructors who actually use it could probably rattle off plenty of stories about how, sometimes the client-side of the interface doesn’t entirely agree with the server, or little glitches that require diving into the database to fix.

Plus, the code-base is kind of a hodge-podge.  Not easy to extend, not easy to maintain…the framework that OLM was written on was no longer the “hot framework”, and there was little in the way of support.  Something needed to be done.

So it was decided that OLM would be recreated from the ground up, and would be an evolution based on the lessons learned from the original implementation.  It was going to be rebuilt in Ruby on Rails, and it was going to be awesome.

It was also going to be renamed.  The name “Checkmark” has been bounced around, but should really be more considered as a code-name.  The project is still referred to as OLM, or Checkmark.

(Just came up with a name idea:  MarkUs.  Note to self:  send name idea to supervisor…)

Part 4:  As it Stands

The new implementation of OLM is actually in pretty decent shape.  There are plenty of bug-fixes and unimplemented features, but a lot of the hardest stuff seems to be over – at least, in terms of matching the feature list of the original OLM.

And that’s important, because our supervisor wants this thing polished, tested, and deployed for the Fall term – and it’s got to at least match the original feature set of OLM, if not exceed it.

Part 5:  Want to See It?

If you want to see this thing, you have three choices:

  1. Catch me in person, and ask to see it.  If I have my laptop, I’ll give you a demo.
  2. Get it from our Subversion repository, and get it running on your own machine.
  3. Enroll in a CS undergrad course in the Fall, and who knows…maybe you’ll end up using it.

Anyhow, if there are any OLM related questions, or even some name ideas, please don’t hesitate to post.

Rendering Multiple Partials with Ruby on Rails

So, as we speak, I’m going through a bit of the code that I’ve submitted for the OLM project, and I’ve begun refactoring.

While doing this, I ran into an interesting problem:  I want to use Rails’ remote_function to update two sections of the page with an AJAX call.  For a while, this stumped me, because you can really only have one render call within a controller method, like this:

render :partial => "footer"

But I was determined to render two.  So here’s what I ended up doing:

On the client side, I’ve got this in my view…

<%= remote_function (:url =>{ :action => "codeviewer", :id => @assignment.id, :uid => @uid },
                   :with => "'fid='+fid", :after => "$('working').hide();")%>

And in the Controller, in the “codeviewer” method, I do this: 

render :update do |page|
    page.replace_html 'codeviewer', :partial => 'codeviewer', :locals =>
        { :uid => params[:uid], :filetext => filetext, :annots => annots}
      #Also update the annotation_summary_list
    page.replace_html 'annotation_summary_list', :partial => 'annotation_summary', :locals => {:annots => annots, :fid => @fid}
end

This will render my two partials in the DOM elements with ID’s ‘codeviewer’ and ‘annotation_summary_list’, respectively.

Nice.

CodeSprint ’09: What Happened?

For those of you who don’t know, this past Thursday, Friday, and Saturday, I’ve had my face planted into a laptop, working 8 hour days on the OLM project.  

And I wasn’t alone.

I was in a room with plenty of other Computer Science students – some even coming from as far as the West coast to join us. Good people, good times, interesting problems, and free food – all care of Greg Wilson, Karen Reid, and the other support within the department.  It was really fun, and I learned a lot.

And we coded our asses off.  Literally.  It was awesome.

So what did I end up actually doing?  Well, when TA’s are marking code, there are little menus that let them attach pre-built annotations to highlighted sections of code.  I’ve also replaced the ugly Javascript Prompt dialog that asks for new annotations with a nice, modal dialog, using LivePipe UI.  The team also got the rubric listed next to the code, and we now have the ability to apply grades on the rubric!  Awesome!  We’re almost there!  There are plenty of tickets, plenty of ways this code and interface can get cleaned up, but we almost have the behaviour we want.  And that’s something.

If I get a chance, there are two things I’d like to do:

  1. Replace the SyntaxHighlighter Javascript code with something a little less client-heavy.  Maybe we can syntax highlight the code on the server side before we send it to the client for viewing?  That doesn’t sound too bad… does anybody know of a Ruby gem that’ll do that?
  2. Refactor the annotations code.  Right now, it’s a lot of Javascript.  A lot.  I’d like to shave it down, simplify it, streamline it.  But that’s what refactoring is all about, right?

Oh, and, in other news, I’m considering graduate school, and doing Google Summer of Code.  Just something I’m mulling over in my head…

Update:  Coding for three days straight brought sooooo much tension back into my shoulders…this is where Movement class exercises become very handy…