Sensorial’Org

Last Thursday was the feature freeze; this Thursday was the code freeze. It’s frustrating that I haven’t accomplished everything that I’ve set out to do, nor have I finished everything that I’ve started. The next best thing is to document what I’ve done so that someone else could pick up where I’ve left off.

Following the last progress report:

February

Week 2: Folded the Student and TA Controller into a User controller, and abstracted the Views to handle both types of users.

Week 3: Code sprint! Started the initial mapping of TA to groups, and played around some more JavaScript. TAs are mapped to groups, and that information is sent to the database. A count is displayed next to each TA’s name to indicate how many groups have been mapped to them. This information is not assignment specific however, because towards the end of the second day, the backend was remodeled so I didn’t want to invest a lot of time implementing something that would break with the new architecture.

Still needs to be done is the toggling of groups (e.g. groups that’s been assigned to a TA, groups that haven’t, groups that have been assigned to a certain TA, etc), automatic mapping (e.g. divide the groups evenly between all TAs), and unmapping.

March

Week 3: Since the TA mapping was at a stand-still, I spent the week polishing up the Assignment Rubric’s and Grader’s view.

Week 4 (to be done):

1. Documentation: what’s been done, what’s still left to be done.
2. Documentation hand-off details; where things are; which files are doing what.
3. Documentation within the code; make sure everything makes sense.
4. Refactor some code.
5. File tickets when necessary.

Summary of Deliverables

Screens on the top illustrates how the system was before I implemented my changes. The after shot is on the bottom for the comparison.

Read more…

Reflection

This course has been both been challenging and fun. Challenging in that Ruby on Rails had a steep learning curve and trying to pick up a new technology along with three other different technologies in other courses was difficult. Furthermore, time management is extremely important. On one hand, you’re working on a project that you have an genuine interest in so you tend spend a lot of time trying to perfect it. On the other hand, there are no deadlines. We meet on a weekly basis to report our progress, but you aren’t given an assignment and a date that it has to be done by. So there’s a temptation to push this aside and try to make for it later because something’s due at 10 tomorrow morning.

At the same time, however, it was also really fun and rewarding:

• I had the pleasure to work with Karen Reid, Geofrey Flores, Amanda Manarin, Mike Conley, Andrew Louis, and Severin Gehwolf. My favourite part of each meeting is that it always begin with a little off-topic discussion about how everyone is doing outside of this course. It’s extremely refreshing because it doesn’t feel like I’m in school.
• It’s not computer science without the technological component. Aside from picking up on Ruby and Rails, and Javascript, I was also forced to use the command line a lot more. I’m much more comfortable with writing scripts, using vim, killing processes, using subversion, searching for and through files, debugging, connecting to servers and databases… all that stuff that I learned and forgot about in first and second year came into practice.
• It’s going to be used! Deployment is in September 2009. I still remember how excited I was when I got my first paycheck as a designer. It’s awesome that you love what you do, but having other people value what you do as well is something else entirely.

I just finished day 2 of the reading week code sprint (coding 9-5 for 3 days), having been operating on 3 hours of sleep because I was putting together a presentation.

For the past two days, I’ve been implementing the TA to Student mapping. There’s one instance of OLM per course, and for each instance, there is a set of users and a set of TAs. When users submit assignments (either individually or as a group), there needs to be a way for the instructor to assign some TA to mark them. We are considering two main strategies for this: (1) each TA marks some subset of students/groups; (2) every TA marks some section of all assignments.

At the moment, the interface is like this. I’ve accomplished:

• Users can select any number of groups by clicking on them; groups can be deselected from the same gesture. (In the future, users should also be able to select a series of groups)
• Users can select any TA by clicking on them; a TA can be deselected with the same gesture. However, only one TA can be selected at time. It behaves like a radio button.
• Users can assign a set of groups to a set of TAs.
• Learned how to use both the rails debugger (available with gem install ruby-debug, and Firebug’s console feedback =)

Struggles

When a user clicks on “Assign TA”, the event is handled by a JavaScript function. Every time a group/TA is selected/deselected, the data structure holding the set of groups/TA is updated. Once the “Assign TA” event has been received, an AJAX request is sent to the controller passing this information via parameters.

The set of groups is stored as an array using JavaScript. This in turn is converted to an JSON string using the Prototype library (i.e. myArray.toJSON()) before it is sent to the controller.

The controller receives this information as a string. So if you try iterating it using Ruby’s .each construct, the only element you’ll get is that string. This JSON must be decoded: ActiveSupport::JSON.decode(myJSONstr).

To be done

• Display the number of groups each TA has assigned to them
• Toggle groups by TA (including those who hasn’t been assigned a TA).

I’ve fallen behind in trying to keep up-to-date with where I was with my projects as assignment deadlines and interviews are brush past me. An update on the project course I’m doing:

Janruary

Week 0: Familiarized myself with Ruby and Rails. Downloaded InstantRails, and tried out a few simple applications. Of course, none of them ever works.

Week 1: Got my first application up and running! It was a proud moment.

Week 2: I downloaded the OLM codebase and struggled with getting it to communicate with Postgres. Once that was set up, I started the application and tried to get up to speed on what has already been done.

Because of the Model View Controller nature of Rails, it was difficult to follow the code in that I had to jump from one file to another in order to trace the sequence of events. The MVC model helped me understand each component of the system from a linear perspective, but when the components started to interact with each other, the relationship became harder to see; association between models is done through “Rails magic” via has_many, has_one, belongs_to, and has_many_and_belongs_to… I still have to figure out how foreign key comes into play.

To help me better understand how it was suppose to behave, I played around with application by interacting with it as an end-user. Beginning with a high level task (e.g. adding a user), I broke down each goal into a series of subtask (clicks that the user has to make in sequence to accomplish the high level task). At each step, I asked myself “What could go wrong?” and “What can I put here that might break this?” I made a note when something broke, when something behaved oddly, and anything that was ambiguous.

Week 3: At the weekly meeting, it was confirmed for me what were the bugs and what were design decisions. Since this was the week of CUSEC, I spent the days leading up to event trying to reproduce the bugs that I’ve encountered and filing tickets for them.

Week 4: The changes that I made this week were mostly for aesthetics. Synchronizing the text, realigning the page elements, establishing a visual hierarchy… I used this as an exercise to explore the Views and how they corresponded with the controllers. At the same time, I looked for ways to increase the usability, but given my lack of domain knowledge, what’s intuitive for me may not be intuitive for our stakeholders and end users.

February

Week 1: Taking a step back from the usability aspect of the project, I worked on implementing the TA and Grades model. The TA and the Student are derivations of the User; since Student was already implemented, most of the logic was there.

The Grades model includes the Assignment (the assignment that this grade is for), the Group (the group of students who submitted for this assignment; individuals will be considered as groups of one’s), the User (aka the TA who is assigned to mark this group for this assignment), and Grade (the grade that each group achieved), and Status (whether or not the TA has started marking this assignment).

This is an opportunity to work through a complete component–the controller, the model and the view. More on this later.

Week 2: Since the controllers and views of the TA and Student are almost identical, they will be refactored into a Users controller before the Code Sprint that’s taking place over later this week.