post mortem

Thumbs up:

• A chance to make a name on a open source project (“eclipse”)
• The formation that Wayne gave us during the code sprint, We would  definitly not have acomplished as much without it.
• Regular project conference call with the team and  Dwight.
• We managed to work as a real team and set-up a svn and irc channel and have 2 irc meeting each week to give each other a status update.

Thumbs down:

• The start of the Eclipse4Edu project (no svn, different goal for every member : disparate team)
• More code rewiew by our responsible or someone more experimented would have been great.
• To blog on wordpress should not be mandatory but it’s really nice to have the opportunity to do it.

Thoughts on RoboCup

I worked on RoboCup and I have to say it didn’t turn out to be what I expected in the beginning. But I really enjoyed it despite the problems we had (just like any other team this term).

There isn’t a whole lot of bad things I can say about the csc494 experience. We pretty much lost that month before the Code Sprint because we couldn’t get an access to the repository. Also it took me personally few weeks after the Code Sprint to actually understand what is it that we were working on and how to approach it. It would have been nice to have a little more guidance, but on the other hand it was cool to be able to set our own priorities too.

Good thing, is that despite being geographically dispersed, my team did a pretty good job communicating with each other.

Overall, I think I got an invaluable experience working on RoboCup. It’s one of those things that look sort of easy on paper  but are overwhelmingly complex when you start implementing them. It also taught me not to be too optimistic when making plans and not to assume correctness of the code that wasn’t my own.

Status updates for Robocup

We had our meeting on Sunday, November 22. Here is what the team had been up to:

Alex

- worked on passing, now it takes into account players from the opposit team

- it is hard to make 100% accurate passing because of the noise added to the measurements

Next task:

- work on interception as it is related to passing

Chani

- fixed code so that now players are using data from the current tick

- fixed a bug in the debug ui

Next task:

- continue debugging

Ioana

- worked on dribbling

- found bug that causes a player to be stuck near the ball not making any actions

possible reason is that position of the player and the ball is not update properly

Next task:

- continue working on dribbling

Yulia

- rewrote chunk of code responsible for parsing the s-expressions from the server

- slightly improved the accuracy of statistics computed from the server data

but it seems that there is not much we can do to make it better because of the

server restrictions

Next task:

- continue debugging

Patrik

- did a merge of code from the dt branch into trunk

Next task:

- debugging kick/dribbling

Thunderbird weekly meeting: Nov. 25, 2009

The Thunderbird team had its weekly meeting today. Our meeting notes and status updates can be found here.

Thanks, Jamie

The second batch of tutorials in our grassroots Software Carpentry course are running today, and we’d like to send a “thank you” to Jamie Winter at The MathWorks, who has provided students with temporary licenses for MATLAB. It’s all been very last minute, and we’re grateful to Jamie for pulling this off on such short notice.

Post Mortem: From a little doubful to I enjoyed doing this, like Bungy Jumping

Thumbs up: Learning skills and applying them to complete daily project tasks. Like the old saying goes, its like killing two birds with one stone, learning all these new technical/non technical skills that will look pretty good in a resume and completing a great project and getting credits for it, hence making progress in terms of school credits. This was a very rewarding experience, with a great team, if it was not for other school commitments I would do it again

Thumbs down: A lot of ideas pending coding, at-least there is a bit of documentation which I believe can prove to be helpful for the next people who continue with the project.

Did somebody say post-mortem?

Can’t believe this is coming to an end already. I’ve read it before, but let it be the best experience of my undergraduate career too.

Con : Setting-up

Maybe it’s just about me (but I don’t think so), and I know that MarkUs was, by far, not the worst project for that concern, but I didn’t enjoy the set-up time. One could argue that I never do. One would be right. Indeed, if I could spend my whole time working on interesting development problems rather that boring configuration tune-ups, I would be in my perfect world. On the other hand, it’s part of the job, and we should appreciate the formation it gives us in problems hunting. Let’s just say that, efforts should be made to ensure the next students face less problems during that crucial (sometimes painful) part of their UCOSP experience in order for them to spend even more time coding great new features.

Thumbs up : Having to meet with great tools

The review board, for one, gave me the chance to read more code in a semester than I think I had in my whole life . This (or anything similar) is definitely a must have if you wish to: 1) keep the quality of your code base high, and 2) Keep developers up to date with where the code base is going, by having a chance to look at new code before it reaches the repository. Which is especially relevant to distributed development (like ours!)

Let’s not forget

I would like to add a special thank for Adam Goucher and Mike Gunderloy. These two professionals wandered around our meetings, review boards, mailing list and whatnot, providing helpful advices on many issues we were facing. This whole experience was my introduction to the open source community, and even though I had no particular expectations, I was gladly surprised to meet people like these.

In the hope that I manage to participate again[1] next year (and meet some of you again).

Gabriel

[1] Need to fit this into a local course. I’m working on it.

Post-mortem

Thumbs up:  Great experience working as part of a geographically dispersed team.  In all my co-op terms, I’ve always worked in an office where I could talk to people face-to-face.  Now that my experience has broadened, I expect to be a better team player on future software development projects.

Thumbs down:  Sporadic time commitments.  As a student with 4 other courses, contributing 8-10 hours a week means working sporadically throughout the week when time permits for 1-3 hour chunks at a time.  While not entirely a bad thing, it is sometimes hard to maintain focus, and can seem like the project is moving slowly.  However, the weekly meetings and status updates do help alleviate this.

Yet Another Post Mortem

Greg:

You are not allowed to repeat something that someone else has said (which is a good incentive to post early .

Apparently posting within the day isn’t early enough; there are almost two pages already.

I’d like to echo what Josh said, both the good and the bad. The best courses in my undergraduate have been the ones where I’ve done ‘real’ work, and the more opportunities I have to do such things the better. Also echoing the ‘deadlines’ section of Josh’s post: I’ve definitely needed to apply triage this semester, for all my courses, not just UCOSP. It really is unavoidable with a fourth year workload. I’d prefer taking hard but interesting courses at the cost of lower marks, rather than taking ’soft’ options and not getting my tuition’s worth. Still, it’s a balancing act when every professor thinks his or her course is the toughest one you’re taking this year. [1]

Anyway, here’s my own thumbs up / thumbs down:

Thumbs up: This may be Basie specific, but I enjoyed the amount of support we received from grad students and people who previously contributed to the project. Having U of T undergrads who already logged time on the project helped as well. Without that guidance, the work done this term would have been much more disorganized.

Thumbs down: Beggars can’t be choosers, but most of the UCOSP projects were web-based, and those that weren’t filled up quickly. Also, nearly every project has a focus on education, or has programmers as their targeted users. This is likely a result of the UCOSP profs selecting projects familiar to them, and due to the open-source mentality of ’scratching your own itch’.

[1] Hey Jay, we should totally make “I Survived Compilers” t-shirts at the end of this term. That is, assuming we do survive compilers.

Thoughts

Being a part of the Robocup UCOSP project has been an interesting experience.

First, I’ll discusses some of the issues with this project. It’s not actually an open source project, and it’s not really under development by anyone other then my group members. This is an issue because we didn’t really get to experience that side of an open source project (ie. being part of a larger picture and lending a hand). The code we decided to use as a base turned out to be worse then we expected which caused use to have to perform alot of maintenance work instead of adding features or extending the team capabilities. Also, the size of the source tree is actually fairly small which has caused us problems, basically it causes most of the things we do to affect everybody in the group hence greatly slowing down development.

I think it would have been interesting to see what would have happened if we decided to start from scratch and develop a client in C++ (which was an option to us because of the very large amount of freedom we were given). Arguably it would have been worse wrt to everybody depending on each other but at the same time it would have been an experience of the birth of a project.

Interestingly, all of the bad points I’ve made are also the good points. They’ve really taught me how to think about projects and that things are not always going to go as planned. It would have been nice to have more guidance but at the same time it’s nice to have been given the freedom to make decisions for ourselves and learn from the outcomes.