Week 8: October 26th to November 1st

What I Did This Week:

Tried getting my hands dirty and writing tests for the Talk Editor. I started with the test_click_add_talk method, but got stuck with it. I found some solutions on Stackexchange and found one that worked when test_talkeditor.py was executed on its own, but caused a segfault when the entire test suite was run.

After playing around with pytest a little bit, I finally decided I was stuck and posted to the Google Group about it. This lead to an IRC discussion with Thanh Ha and Michael Tom-Wing, which culminated in Thanh Ha suggesting that either I skip testing this method and move on to other tests, or try refactoring talkeditor.py. Since the problem I experienced with test_click_add_talk would also apply to my other tests, I think it would be best to try to refactor the code.

What I Plan to Do Next Week:

-  Attempt to refactor talkeditor.py so that the widgets don't use the problematic exec_() method.

Problems:

- Last week, I struggled a bit in figuring out how to create viable tests -- using it just to open and close the New Talk window turned out to be a whole project on its own. I am hoping that this is an exceptional situation and that most of the testing will turn out to be slightly easier than that.
- My sleep schedule has been kind of unhealthy lately, and I would like to fix that. Hopefully the end of Daylight Savings Time will help with that a little bit.

Discussion:

This week was the week we received our midterm evaluations. I was evaluated by Dennis Ideler, who suggested a grade somewhere in the 70s. I think that's fair, and his comments were fair as well. The only comment I want to make regards preparation -- it was commented that I might work better if I spent less time preparing and more time diving right in. I have made a conscious effort to spend as much time working with actual code as possible. However, I still have to rely on a documentation and research to understand the current code, and to give me an overview of what my options are for fixing bugs. I want to make sure that I understand the code, rather than just copying or rote-memorizing examples of code and hoping it works without knowing why it works.

To the extent that I have succeeded at all in this course so far, I attribute what success I have had to my tendency to patiently and slowly understand the information in front of me, and viewing learning as an end in itself. When I asked to be part of this program, it was because I wanted to get a better understanding of working on a programming project with a team, as well as understand a bit of the practice of contributing to an open source project in particular. I have already learned a lot, and even if Dennis had suggested a grade somewhere in the 20s, I know that my experience in this course so far has been worthwhile.

One thing I have learned about myself over the past year of school is that, although I'm studying for a joint-major degree in Mathematics and Computing Science, I guess I'm really more into the math part than the computing part. I suppose I think more in terms of theorems and abstract algorithms than in the vocabulary I've learned from my mentors and teammates working on this project. I don't think this is a bad thing. It just means that in the long term (and by "long term", I mean years, not so much this project) I might enjoy contributing more mathematical elements to projects.