We’ve moved to ucosp.ca

This blog was retired some time ago.  Please see http://ucosp.ca for current information about the UCOSP program.

MarkUs 0.7.0 is ready to go!

The MarkUs Team is proud to present MarkUs 0.7.0!

Click here to see our release announcement.

Evaluation

Almost all of this term’s students have sent in their self-evaluations, and their evaluations of their mentors. Overall, people seem to have enjoyed working on things that are actually going to be used, and getting to know their peers and their industry mentors. There are a few things we need to do better next time—clearer goals for some projects, some grades midway through term so that people know where they stand, etc.—but I think we all deserve an ‘A’ for what we accomplished.

Best of luck with exams (for those of you who still have them); I hope to have the chance to work with you again some day.

Coming to a close…

Our FlightSim project has come to a close last week, after posting our final delieverable. It’s been a long ride, so I thought I should take my time to write down my experience and what I’ve learned here.

Different from most of you, our project started at IBM’s lab, not at the St. George campus. On our first morning, all of us were invited to their lab at Markham. The lab itself is a really cool place, and the IBMers have treated us well. But to be honest, it’s not exactly the greatest experience. We were basically given a crash course on DB2, then the TE (which is the foundation that our project is building upon), plus some unsuccessful troubleshooting session on how to get both working on a Mac and Linux. Because the amount of information is SO overwhelming, by the end of the day, all I was left with is frustration and question marks. Heck, I don’t really understand the porject that well to begin with, but then it feels like I understand that even less when we leave the labs. As everyone have already started doing some coding in the UT campus, I thought we would be doomed.

On the second day, things start to look a bit better. Matthew gave us a walkthrough of the TE codebase. Overwhelming, still, but we are starting at least starting to see what this is all about. (The lack of projector is really leaving something to be desired… six kids staring at a ultra-high pixel density laptop monitor… not even funny!) We also did, in my opinion, one of the most important things for our project. We set up or communication channel (Skype) and a meeting time (Tues, Thurs). Yes, it’s taking a lot longer than it should, and it could be done more efficiently, but I believe it’s well worth the cost, we’ll talk about this more in a bit.

By the end of the code sprint, most of us still haven’t got of systems set up probably. But then I started to understand more about our project and it seemed quite a bit more approachable.

As we splitted and returned to our home city, the first challenge is to get things working on our end. This marks the first collebration of our team. Within days, the wiki is populated with detailed instructions on how to get things working and what works and what doesn’t. We also helped each other out on Skype. Perhaps it’s the frustration we have in common that really bonded the whole team together, and this helped to smooth things out a lot for the rest of the term. It still takes a few more weeks and a lot of help from IBM (esp Paul, you’re awesome!!) before our systems are truely functioning, but can at least start doing some useful work now.

My first assignment is to investigate the recurssive queries issue. Basically, I need to write a recurrsive query that saturates the CPU. It took me quite a while to figure out what that even means. This is pretty much my first official encounter with the massive DB2 system, so I spent a good amount of time researching and learning how to fight this little monster. After a lot of trial and error, I have sucessfully created a recursive query that does some interesting things. However, the result is quite disappointing. Although it took me days to write that query, it only took the database 5ms to execute it. Matthew suggested that DB2 might be doing some crazy optimization behind the scene for me. Although this attempt turned out fruitless, it was a good experience and allowed me to get myself familiar with the DB2 system.

I was then reassigned to work with Mike on his locklist overflow scenario. His scenario worked beautifully on his machine, so I took up the task to reproduce and record that on my laptop. However, after a night of trial and error, I still cannot reproduce the problem on my own machine. I did some extra research and concluded that the behavior might under this situation is undefined, so it varies wildly across machines. I looked into the nature of the problem and proposed some changes to the scenario (changed from locklist overflow to lock escalation). Although we didn’t end up using this scenario, we did some serious work reseearching that problem, and left some pretty good foundation for other people to pick that up in the future.

To avoid slowing down our progress due to the extra work needed for the lock escalation scenario, I picked up on Sylvian’s lock wait scenario because it’s much simplier to reproduce and understand. We then continued our work based on this senario and ultimately produced a working version of our scenario and attached it in the final delieverable.

---

What I have learned…

1. Reading other people’s code

By far, I think this is the most valuable experience for me. In the real world, developer documentation is a luxary for lot of open source projects. Having the experience of reading and understanding other people’s code will allow me to contribute to a wide range of open source project in the future.

2. Working within a distributed team

This is probably one of the most important that Greg planned this course for us. I realized how important it is to maintain good communication with the team. What makes our team unique in UCOSP is that we have two weekly meetings, one via conference call, one via Skype chat. Although this could be overwhelming at first, I do find this highly valuable and would recommend other teams in UCOSP to do the same.

3. Asking help

Without the help from IBMers like Matthew and Paul, we wouldn’t have gone this far for this project. I learned to ask help when you need it, and more importantly HOW to ask help. Describing a complicated problem clearly (but overwhelming) could be challenging and this course turned out to be an excellent opportuinty for practicing that.

---

What I liked…

• The semi-weekly meetings!
• IBMers are very helpful… and often respond within ours of us asking a question.
• The project was challenging, in a good way.

---

What could be better…

• The initial project definition was too vague… Because most students joining this team will not have the experience needed for understanding the project, I think it’d be a better idea for provide more guidance and make things more concrete for them at the beginning. Then, allow them to have more flexibility as they learned more about the project. (i.e. provide some clear and rigid goals, instead of allowing us to make our own goals right from the start, because we wouldn’t be able to take advantage of that flexibility at that time anyways)
• The pieces we are building upon wasn’t quite ready for prime time yet when we first started, which caused a lot of frustration as we spent most of our time debugging and setting things up in the first few weeks. I believe this has mostly been addressed by now, thanks to the new releases and the sandbox server.
• More documentation would be nice 🙂
• The code sprint was quite overwhelming for most of us.. maybe we can aim to do/learn a little less at the sprint..?

---

Again, I would like to thank the IBMers (esp Matthew and Paul) for providing us such an incredible experience!

Thunderbird Status Updates: April 02

This week is another productive week for Thunderbird Team in that most of us have finished most of their work!

Wei Xian has resolved his bug (restore session) and his patch has been pushed to comm-central. Also, he is going to prepare a “quick start guide” for future students who are going to work on Thunderbird. For myself, I have posted my revised patch and get the review from Blake. Now I have submitted a secondary review request and hopefully everything is going all right.  Evan is working on his own RFC 2425 parser to provide (de-)serialization of RFC 2425 directory entries into a data structure designed to support simple lookups on types and parameters. Now he is waiting for his patches to be reviewed. Zach is working on applying his patch and running mozmill test on his machine. There are still some issues for me to handle with the testing. Lindauson is still working on the menu items and seeking suggestions.

pony-build Updates

Khushboo:

Khushboo has been wrestling with git and getting her branch(s) to push properly.  Some very informative posts can be found on her blog. She also continues creating build scripts for other python packages.

Fatima:

Fatima has been working on getting branch support in for Mecurial checkouts in pony-build, to go along with the new changes, she has also been working on tests. You can read up on all her research into the subject as well as her progress over at her blog.

Jack:

Jack has been continuing his work on his pony-client changes. During his work on this he stumbled onto another bug with forcing builds that he is looking in to also.

Max:

Max has implemented a fix for defaulting to an in-memory db for the server. He has also been working on some failure conditions within build steps under a certain context. He,however, has taken a break from the perils of subprocess timeouts until he can secure a windows machine for proper testing. You can mozy on over to his blog for more info.

Edit: When is pony-build going to get some love and have our own Category?

Mercurial: the end of the beginning

Today marks the last day of classes at the University of Waterloo, and so ends the official portion of the UCOSP project for Tessa, Wendy, and myself. During our last meeting on April 1st, we tied some loose ends on our patches and discussed our experiences in the project. I will save the details for the final reports, but we all agreed that we’d like to continue contributing to Mercurial as time permits.

Paul and Alex have a little more time before official end of classes at UBC, and we’ll probably be hearing from them after the meeting this week.

Status updates:

• Bfiles auto-* integration
  • auto-status and auto-update have been accepted into bfiles
  • auto-put and auto-refresh are almost there
• Wendy and Tessa continued to improve on their warm-up projects:
• Paul has a working version of bfilesify which converts existing mercurial repositories to use bfiles. We are playing around with it to provide feedback.
• Alex has been working on his ever-popular case guard extension.
• I have started work on implementing my extended status proposal which aims to create closer integration between bfiles, subrepos, and core Mercurial code.

As always, you can find detailed status reports on our Wiki at https://ucosp.fogbugz.com/default.asp?W44

The Real Challenge of UCOSP

“The real challenge of GSoC is not the coding, it’s learning to work with a community,” wrote Matt Mackall to the Mercurial mailing list a couple days ago with regard to the upcoming Google Summer of Code projects: http://selenic.com/pipermail/mercurial/2010-April/030996.html

I believe this applies equally well to us: the real challenge of UCOSP is not the coding, it’s learning to work with a community. This is especially true for the Mercurial team because we are working with such a large, established, global community of developers. Working within our UCOSP team was alright for our initial warm-up projects where we built new Mercurial extensions or added isolated features, but it became very important when we started working on the bfiles extension. We collaborated extensively with Greg Ward, the creator of bfiles. Towards the end, he helped us extensively with combining and polishing our patches, and as a result, they integrated smoothly into his tree. The more we engaged the developer community, the more productive we became.

The post that I link to has some other great pointers for anyone new to an opensource project – not necessarily those doing it for credit or money. It’s worth a read.

Thunderbird Status Updates: March 26

Apologies this is coming late, I didn’t notice I was set as the blog poster for this week!

It seems like several of us are having difficulties with unit tests, with myself and Zach having trouble getting working unit tests off the ground, and Wei Xian adding some polish to his previous unit tests.

Also, Tim and I are feeling the crunch of other courses so haven’t been productive over the last week.

Many of us, including Kefu, Tim, Evan, and Wei Xian have been working hard with Mozilla reviewers to make changes to their code. It’s nice to see that the project as a whole places such emphasis on code quality and correctness, and we’re all learning a lot from what they are telling us to do!

And of course, while working on tests and getting past code reviews, some of us are trucking along working on other tasks – Lindauson is hard at work trying to get menu items to behave the way he wants them to, Wei Xian is working on standalone message window behaviour, and I am working on listening to folder compacting events so that they properly display themselves in the activity manager.

Final deliverables of Data Center Flight Simulator

List of deliverables:

• Technology Explorer for IBM DB2: https://db2mc.svn.sourceforge.net/svnroot/db2mc/UCOSP/release/final
• WMD workload profiles: https://db2mc.svn.sourceforge.net/svnroot/db2mc/UCOSP/release/final/config_files%20in%20WMD/
• Document on how to add new scenarios: https://sourceforge.net/apps/mediawiki/db2mc/index.php?title=Adding_new_Scenarios
• Document on how to use TE to test a person: https://sourceforge.net/apps/mediawiki/db2mc/index.php?title=Testing_a_person_DB2_diagnostic_knowledge_using_the_Technology_Explorer
• Document of graphical indicator: https://sourceforge.net/apps/mediawiki/db2mc/index.php?title=Action_-_indicator
• Final video of locklist tutorial:
  • URL1: http://vimeo.com/10569706
  • URL2:  to be uploaded to sourceforge.net
• Final video of IO tutorial:
  • URL1: http://reseau.twisto.ca/io.m4v
  • URL2: http://www.youtube.com/watch?v=RLgOBTtMyvs
  • URL3: to be uploaded to sourceforge.net
• Individual reports:
  • Diane: http://dianetam.com/dev/blog/
  • Lenny : http://hanlenny.wordpress.com/
  • Jean: to be submitted individually
  • Sylvain: to be submitted individually
  • Godfrey: to be submitted individually
  • Michael: sent earlier via email