We now have 15 students signed up to do UCOSP projects next term. There’s plenty of room for more…
Archive for November, 2009
Posted by pgornicz on 2009/11/30
For the most part we are all trying to wrap things up. Here’s how we plan to divide the final work load.
Yulia + Ioana: Look into fixing coordinate system.
Chani: Will put together a skeleton of the document.
Patrik: Will write up an overview of the source code by Tuesday.
Alex: Plans to finish his passing improvements and contribute a write up of why we choose the python code.
Everybody: Contribute to the document and consider tweaks to improve overall performance.
Posted by pgornicz on 2009/11/30
We had our weekly meeting yesterday (Nov 29th ’09). The minutes and transcript are available here (http://chani.ca/robocup/minutes/nov29.txt).
Posted by jorygraham on 2009/11/30
It was nice to learn how people are using tools like FriendFeed to interact directly with their end-users. I know there are a lot of solutions to that specific problem, but my experience with large scale work in the past had only ever been internal projects.
Lack of direction. I understand that this wasn’t really a problem for a lot of the projects, but I feel that ours suffered it in spades. We didn’t have a shareholder who was really hands-on and invested in what we were doing.
Posted by bkonrad on 2009/11/30
The code sprint. Hands down the most fun part of the course for me (as it was last year), I enjoyed meeting the smart people who make up the Basie team and solving a few key design problems. The Basie team came from all over, and it was a blast.
Remote, remote, remote. I know that this business “can be done from anywhere”, but it’s just not the same IMO. I set up some phone chats this term that hopefully made everything a bit more human, but more of that would have been great. If I was in charge I would require that a student doing a code review for another student have AT LEAST one “real” discussion about the purpose of the code in question. The process of explaining one’s code very often reveals shortfalls or room for awesome improvement.
Just my two cents (we have a lot of cents here now!)
Posted by dashrantic on 2009/11/30
Whups, it appears I missed the original email on doing this writing assignment–apologies for it being a bit late!
I’ll start with my thoughts on the positives for this course first. I really feel I’ve learned a great deal about working with a distance group on a software project–something normal CS coursework doesn’t really prepare one for (and even precious little time is spent in the courses I’ve taken on working with more or less random groups as well). There are definite difficulties in the process, but it’s been a great experience learning these things firsthand.
And for the negative. Looking at some of the other posts, I think I would be redundant if I simply mentioned the lack of structure in the course, so I would like to point out at least one thing specifically–I’m going to pick on the grading schemes here (I was already thinking about writing this up before I saw Eric’s post just below mine–I guess this is ending up being a long extension on one of the subjects to touched on). It’s an interesting idea to have the students decide how their own projects will be graded, but I don’t think it worked out very well this time around.
I really feel there needs to be a more definite overall grading scheme. I went through all my emails from UCOSP going back to the beginning of the term, and didn’t see anything with any sort of set grading scheme. Through the semester we’ve been asked to do various things (several writing assignments, project presentation video, etc), but these pop up more or less at random, and other than being told basically that “it will affect my grade”, I have no idea how they will affect my grade.
If at the beginning of the term we could see something like:
“Initial writing assignment: X% of final grade
Project status updates: Y% of final grade
Final project video: Z% of final grade
*Along with item due dates*, I feel that would be immensely helpful. The specifics of the items don’t have to be filled out at that point, but would make sure students knew ahead of time when something was going to be due, and around when to check back for more information. For example, I somehow missed Greg’s first email about this writing assignment–but thought nothing of it, because I guess I didn’t remember seeing the initial email, and I didn’t know to expect one–so the current terrible signal-to-noise ratio of my inbox took over.
Then for some set percent of the overall final grade, students could do what we did this term and pick how their final deliverable would be graded at the end of the term. However, that would not be their *entire* grading scheme, but section of a more structured grading chart. This would allow not only for the projects to be graded more simply, but would allow students to get a better feel as to how they are progressing throughout the course, and have a better idea on how to schedule their time through the term.
So I do think that more structured grading would be a great thing for this course, what students could get out of it, and positively impact the final products as a result. I like the ideas here https://ucosp.wordpress.com/2009/11/16/some-ideas-for-next-term/ as a start, but to implement those ideas, we’re also going to need structured grading.
It’s been a great experience overall though! I know this post is a little long, so I hope it all made sense–feel free to comment if anyone wants me to make any part of my long rambling here more clear / want me to explain anything better 🙂
Thanks for reading, and it’s been great working with everyone!
Posted by Eric Henry on 2009/11/29
The good cent:
I would definitely say that the best part of my UCOSP experience has been my project “mentor”, Blake Winton. I’m not sure how he put up with my incessant IRC messages at all times of the day Sunday through Saturday. I learned a lot about Mercurial and distributed version control from him, and he was always so chill that I couldn’t help but want to work on the ISPDB. It’s too bad he’s not grading me for the course, otherwise this might be a nice little push towards a good grade 😉
The bad cent:
In short, the structure. I didn’t bother reading all of the other post mortems so I hope that I’m not repeating anyone here…
The long version:
The structure of the course made it hard to give it priority equal to my other courses. I know that I still put in a good amount of work, but I would have liked to put in more. I liked the idea that “Greg” had (I know your dirty secret on this one Greg, and it’s safe with me 🙂 ), but I think it still needs more structure. If the 3rd suggestion had a percentage of the total grade (like 30%) where you either got your weekly milestone done (or a good blog post about what you came up against that kept you from completion) or you lost a percentage of your total grade. As it stands now, it’s hard to see the real repercussions of missing milestones since they don’t have a direct, quantifiable effect on your grade. I could go on about this one, but unless someone comments with questions I’m going to lay this to rest…
Posted by Alex(Ning) on 2009/11/29
Thumbs up: first of all, know a lot of new friends:) this is most valuable. Second, learn how to cooperation with each other, even we are far away from each other. We use IRC to hold and log team meeting, wiki page to schedule and record our process, bugzilla to keep track of everything. Those tools contribute a lot to the final success of the project. For the technical aspect, I learn the new language flex and use it to create the UI and animation for the front end. It’s an amazing tools for data representations and I am so glad that I can apply it to the real work.
Thumbs down: The only problem that I can see is that the open source projects are lack of documentation. We start with thinking and end with coding. But if we do have documents, for one things, we can realize what we are gonna do much faster. For another, if we create documents while developing, it will be much easier for the fellows to improve our work or continue the unfinished parts. Otherwise, they may have to spend some time to understand our code.
Overall, I will rank very high for this projects. We can do something which is meaning for lots of people, instead of coding just for assignments. Lots of useful tools are involved and I can improve my working skills through the whole semester. BTW, I really miss the trip for the Toronto and saw the beautiful city.
Posted by ilienert on 2009/11/29
The Good: I learned a lot about web frameworks (specifically, Django) and jQuery applications from Basie. Without having any web development background, the course allowed me to move at my own pace while still absorbing lots of information that I will likely retain for future employment opportunities. Not only that, but the reference gained by doing such a project is certainly one of the best ways to get your foot in the door (here’s looking at you, Greg ;)). Basie was my first taste of the real world.
The Bad: Code reviews were daunting since team members were focused on very particular aspects of the project.
Judging by factors that extend beyond the mere comparative lengths of the two preceding paragraphs, the good most certainly outweighs the bad. Having a web development course under my belt, I’ve decided to continue experimenting with CSC49X and am now on board for a project with a much different flavour: image recognition. I’m very excited how far-reaching and open-ended these projects can be and hope that more students, as I did, will have the opportunity to apply their knowledge to something meaningful in the coming terms.
Posted by evanbowling on 2009/11/28
thumbs up: Getting the opportunity to work with so many interacting technologies was a challenge. It forced me to take care with the documentation I have been preparing, and given me some inspiration as to ways that documentation could be organized better.
thumbs down: Meetings were often canceled and it was hard to set attainable personal goals.
All in all, I feel the course has been helpful. It was extremely frustrating at times because I felt like I was spending so much time dealing with installation problems and not always knowing what work was necessary to get to the next step. That frustration, I think, was key to learning how to work with multiple open source communities where everyone is setting their own deadlines and is dealing with other time constraints as well.