Posted by Joseph on 2010/03/01
Things I have learned:
- Ruby and Rails
- Shoulda 
- Mocha reminds me of mocking JUnit tests in Java  
- will_paginate: an elegant plugin for performing pagination 
- keeping state with in URL when doing AJAX calls 
- Word Press and Blogging: I have blogging fever. I cannot stop blogging about everything I have learned. I just hope someday a stranger will comment on how helpful it was.
Things I have completed:
- when the Markus webserver boots up, it verifies that the settings inside the configuration file located at: <markus_root>/config/environments/<env>.rb are valid. For instance, if the password validation script is not executable, a message will be printed to the console and the webserver will stop starting up.
- got the AJAX calls from ahrefs to to save state into the URL 
- implemented a mock submissions page that used serverside pagination to compare the performance with AJAX pagination
- since the performance was similar, Markus has decided to go with the serverside pagination because of all the loops we would have to jump through to get the AJAX pagination to work with the back button and bookmarks
Things I am working on:
- switching from AJAX pagination to serverside pagination so that bookmarks and the back button will work again
- encountered a large speed bump dealing with nested forms
- going to blog about the work around after I have verified that it works
Things to work on in the future:
- verifying that the serverside pagination has not changed the behaviour of the submissions page
- detailed view for the marker’s or admin’s submissions page
- cleaning up the serverside pagination code to take advantage of the conciseness of will_paginate . This will involve implementing a custom link render so that the submissions page’s UI does not change. The links generated by will_paginate looks like: “Previous Page 1 2 3 4 5 6 7 Next Page”. The links on the submissions page looks different.
 – Nested Contexts – http://josephmate.wordpress.com/2010/01/31/nested-contexts/
 – Mocking Modules with Mocha – http://josephmate.wordpress.com/2010/01/31/mocking-modules-with-mocha/
 – Weird Behaviour of Mocha- http://josephmate.wordpress.com/2010/01/31/weird-behaviour-of-mocha/
 – Will Paginate and Markus – http://josephmate.wordpress.com/2010/02/15/will_paginate-and-markus/
 – Rails, AJAX, Back Buttons, and Bookmarks – http://josephmate.wordpress.com/2010/02/20/rails-ajax-back-buttons-and-bookmarks/
 – will_paginate – http://railscasts.com/episodes/51-will-paginate
 – Hofstadter’s law – http://en.wikipedia.org/wiki/Hofstadter’s_law
Posted in MarkUs | Tagged: MarkUs, midterm, Status Update, Winter 2010 | 1 Comment »
Posted by victoria on 2010/02/28
Expectations, Status & Progress
Coming into this UCOSP project course, my ultimate goal was to be able to utilize the human-computer interaction (HCI) and user experience (UX) design knowledge that I’ve acquired from both school and work to enhance the usability of MarkUs. Through this experience, I’m hoping to solidify my understanding of various usability concepts and familiarize myself with more projects out there.
Up until now, I feel that I’m on track with the work that I’m doing with MarkUs. I’ve been spending most of my time redesigning and reorganizing a lot of features and functionality MarkUs currently offers. There’s no better way to do this than to keep prototyping and getting user feedback through usability sessions. Because of my full-time position, I have not been able to collect as much usability feedback that I’d like to in person. But I’ve found that running these designs by the team is often just as helpful. But most importantly, having a supportive supervisor to help collect the user feedback certainly helps me since I am working remotely most of the time.
In short, I think I’ve stayed on track because: I have already redesigned quite a few views; and have made various suggestions to the overall MarkUs interface.
Things I’ve learned thus far
In the past, I’ve done very little usability work for web-based applications, and I’m also very new to designing interfaces from scratch. Thanks to my team, I’ve learned quite a few things about designing web interfaces in particular. For example, small things like screen resolution will have a huge impact on the usability and presentation of the entire user interface. So it’s certainly something that needs to be considered early in the design cycle, and kept in mind at all times.
Another key thing that I’ve learned up until now is the prototyping tool, OmniGraffle. Instead of seeing the tool as being a burden, it has now saved a significant amount of my time. For example, I am now more comfortable using new canvases and layers in my prototypes wherever I see fit.
In the remainder of the course, I plan to continue working on the UI of MarkUs. I focused on the Grader Assignment and Group Formation views for the first half of the term, but those have now been addressed. Next, I am planning to tackle the Properties view – our goal is to make the Properties view intuitive to not just regular users, but also those that are using MarkUs for the first time. New designs for the MarkUs Dashboard are also to come.
I’d also like to maintain the good communication and coordination we’ve had as a team in the weeks to come.
I’ve had an awesome time working with the team, and I’m looking forward to the rest of the term!
Posted in MarkUs, Status | Tagged: MarkUs, midterm, midway update | 1 Comment »
Posted by bryanshen on 2010/02/27
Two months have passed since I joined Markus in Undergraduate Capstone Open Source Project (UCOSP). I thought it was just another course, but it’s a completely different than every other one I’ve ever taken.
The most noticeable difference is that no instructor is around! In a regular course, I am told how to do stuffs. I sit in a comfortable chair in the classroom, follow the instructions given by teachers and do best I to meet their expectation. This is all good, but most students end up acquiring a subset of the knowledge the teachers have in such courses.
It’s interesting that in UCOSP there is no such a instructor who knows “everything”. We use Ruby on Rails (RoR) to develop Markus, but I never had used any programming language similar to Ruby. I had to use it while still learning. It took me some time before I figure out this difference and notice how important it is.
When I started, I got a RoR book and stick to it as if it was an instructor. I read it page by page carefully, which I usually do in a regular course. But soon I found myself fall behind than other members. The book was too much to learn. With the speed I read it, I wouldn’t finish it before this semester ends. And even if I go through the whole book, I wouldn’t have enough knowledge to go with Markus, because RoR is developing so fast that Markus uses many third-party RoR plugins that the book doesn’t even cover. This forces me to take the other approach – set my learning objectives and learn only what is needed. I learned the syntaxes of Ruby languages and get the idea of Model View Controller (MVC) from the RoR book, where concepts are well organized. Then I studied the source code of Markus myself, and ask my google and my other team members whenever I have difficulties. As I look into more parts of the project, my knowledge of RoR has grown significantly. Since everyone is dealing with different aspects, we all have different sets of knowledge. When one has a problem, it is very likely another knows the solution. We are actually learning from each other. It is a good lesson for me – after all, self-learning and learning from peers will be a major way of acquiring knowledge in one’s life.
Honestly, I haven’t been doing as good as I expected. I was not wise enough to break a big task into small pieces. When I needed to fix a small bug, I could do it efficiently, even if there were lots of technical difficulties. But when a bigger task was assigned, I couldn’t do it as efficiently, because I tried to solve the task as a whole instead of dividing it and tackle it piece by piece.
Markus project once again tells me the importance of communication. Working on a project in a team is not like writing an algorithm alone.
By now, I’ve fixed several high priority detects of the Markus project, and I’m currently working on an enhanced feature.
I enjoy working on Markus. I feel honored when users make some positive comments and when I solve some defects they report. Within the remaining two months, I believe I can fit myself better in this position and generate more output to the project.
Posted in MarkUs, Status | 2 Comments »
Posted by Farah Juma on 2010/02/25
The first half of the semester has flown by quickly. Like last semester, I’m really enjoying being a part of the MarkUs team! It was nice to already have my development environment from last semester all set and ready to go for this semester. Since I didn’t have to spend any time on setup, I was able to jump back into the code right away. I’ve found that things make a lot more sense to me now than they did around the same time last semester. I think this is because I’m now much more familiar with the concept of model-view-controller, Ruby on Rails, the MarkUs code base, etc. I learned a lot last semester and I’m continuing to learn a lot this semester. I’d definitely recommend working on the same project for two semesters to other people because in a course like this, the learning curve can be pretty steep, depending on your background.
This semester, I’ve been continuing to work on the new grade entry feature for MarkUs. I’m really happy with my progress and with the way it’s turning out so far! While working on this feature, I’ve gotten to learn a lot about performance optimization. I recently learned some neat tricks to prevent users from feeling the pain of a large number of database creations. I’ve also been learning quite a bit about the importance of testing. Our team has been doing a great job of making sure everyone adds appropriate unit tests and functional tests for their own code. One of the great things about UCOSP is that we get to learn things that we might not have otherwise come across in our other courses.
I’m looking forward to the rest of the semester!
Posted in MarkUs, Status | 1 Comment »
Posted by Robert B on 2010/02/25
Simply put, I’m dissatisfied with my performance with MarkUs.
Up until now, I’ve been doing what could be considered the bare minimum of work to get a passing “grade” for UCOSP. This is my final school term which means I’m looking to the future a lot this term, searching for full time employment. While I’ve been very successful in this endeavour to tell the truth, it does mean that certain trade offs have been made which have not been to MarkUs’ benefit. When I had interviews to prepare for, MarkUs got put off. When I had assignments due in other classes, MarkUs got put off.
When I do work on MarkUs, it’s mostly a joy! It benefits from being a Ruby on Rails project in that 90% of everything is intuitive and easy to do. Most importantly, it’s fun! It’s fun to get results quickly and do meaningful work in so short a time. Occasionally there’s a sticking point that has me butting my head against a wall (converting fixture based tests to machinist for example), but that has taught me to take advantage of the ease of communicating with my fellow devs on the IRC channel, the mailing list, or through the review board. When I do work on MarkUs, I feel that I’m making up for deferred time, because I can get things done so quickly.
My feeling of being behind is a relative measure. I don’t post to review board nearly as much as Brian or Bryan. My submissions have not been as far reaching as Farah’s. I haven’t blogged as much as Joseph. I’ve made only 3-4 submissions since the codesprint, when in my mind, I feel I should have been making at least one a week. There’s lots for me to do, I just need to go ahead and do it.
The only thing I’m satisfied with as a performance metric is the blog posts I’ve written.
From a development standpoint, I don’t believe I’ve learned anything new from the UCOSP experience, but it’s certainly re-enforcing what I’ve learned from my co-op work terms.
- Communication is key. There are no stupid questions when you’re unfamiliar with the code base.
- Go ahead and try things. Mistakes are the engine of learning, and by learning from them, you’ll do better next time.
- Be transparent. If you can’t get work done on time, then you can’t get work done on time. Don’t pretend you’re being productive when you aren’t.
- Be helpful. If someone is having a problem, and you think you know the answer, pass on the knowledge! It’s one thing to encourage independent learning, but in a team based project, it’s better to be cooperative rather than competitive. The project benefits from it.
- Code reviews are invaluable. Code review others stuff, and they’ll make time to return the favour. It’s proof reading for the programming set!
My goals for the rest of the term is to simply get more done. I’ll have a job after the 1tth, which means that I’ll no longer be spending 1.5-2 courses worth of time on interviewing. I’m not in any heavy project courses this term beyond UCOSP, which means my time and energies can be focused on it. I want to review more code, write more code, and generally make MarkUs better off than when I left it. I also hope that the Powers That Be (AKA Greg, Karen, and Mike) see fit to grade me on my overall performance for the term, rather than be focus on the unstable start to the term.
Posted in MarkUs | 1 Comment »
Posted by Farah Juma on 2010/02/05
The MarkUs team’s status punchlines for this week can be found here.
Posted in MarkUs, Status | Leave a Comment »
Posted by Farah Juma on 2010/01/29
The MarkUs team had its weekly meeting this afternoon. We had a pretty big group today! Our meeting minutes can be found here.
Posted in MarkUs | Leave a Comment »
Posted by chancancode on 2010/01/29
Just blogged about this on my blog today, which might be of interest to the MarkUs folks.
Posted in MarkUs | Tagged: ruby | Leave a Comment »
Posted by Robert B on 2010/01/29
… can be found here .
If you make it to the bottom, you can see that I haven’t done very much. Interviews take up so much time! It’s a good problem to have, but I can’t help be feel a bit of guilt for pushing MarkUs off to the side for them.
Because of the flexible nature of UCOSP, it’s possible for me to do this. I’m just using my banked up hours from the code-sprint sooner rather than later. I plan on being back on track in a week or two when the scheduling madness that interviews induce finish up.
With any luck and some thorough grounding in data structures and algorithms, soon they will all be over.
Posted in MarkUs | Leave a Comment »
Posted by Robert B on 2010/01/23
MarkUs had it’s first IRC meeting of the term. It’s a slow beginning but I think we’ll start moving quickly soon enough. : )
See the minutes here.
Posted in MarkUs | Leave a Comment »