What I Did This Week:
- Fixed Issue #627
- Addressed some problems with PR #630
- Added a bit more to the Talk Editor tests
What I Plan to Do Next Week:
- See how much further I can get with the Talk Editor tests in a week
- Look for any small fix issues I can address in the last week
Problems:
- Some issues using QTest to simulate a user typing in changes to a talk
- I believe it is unlikely that I will complete the Talk Editor tests as promised.
Discussion:
I suppose we're approaching the end of the course now. I shouldn't get too complacent: I still have a few days left before lectures are officially over, and I might as well stick around the entire week to wrap up loose ends as necessary.
However, since this is, in theory, the last journal entry that will be considered as part of my course work, this seems like as good a time as any to do a bit of a retrospective on the whole experience.
I definitely know more than I did when I started the course. I can already think of ways I can use Git/Github, SQL, Qt, and unit testing in my personal projects in the future. I also have a slightly better understanding of Linux than I did before.
I want to emphasize that these aren't just specific technologies I've been learning. It would be one thing if, for example, I had used Subversion before and this was my first exposure to Git. But before this course, I hadn't had very much experience with any version control system, database programming language, or unit testing in general, let alone pytest or unittest specifically.
I think it's worth mentioning that I've had to get a lot of practice reading code for this course. This is not trivial. As Joel Spolsky said, it's harder to read code than to write it.
I am aware that I started out as the most experienced student in the Freeseer group. I've never been in any kind of work-experience program or internship or co-op. I've never taken a 200-level course in software engineering, or in most of the upper-division courses that do into any depth on actual software design.
If I wanted to be charitable to myself, I would say that I did the best I could under the circumstances.
If I wanted to be less charitable, I would suggest that I didn't take nearly enough advantage of all the expertise around me -- not just the mentors, but the other students.
But my problem is, what am I supposed to ask? I have a problem, and it goes beyond this course: i have trouble asking people for help. Over the past year or so, I have made a deliberate effort to ask for help more often, with some level of success. If I had to guess as to why I have this problem, maybe it's because I've had too many teachers who rolled their eyes or got angry whenever someone asked a question, with the reason that we should have been paying better attention, so I got this idea that ASKING QUESTIONS = ANNOYING (at least, when I do it. I don't think I've ever had that attitude about other people asking me questions.) My problem isn't exposing myself to the possibility of looking stupid -- I take it for granted that most of my actions are going to seem a bit silly by default. My problem is that I don't want to do things that I believe are annoying to other people, just like how I don't want other people to do things that they know annoy me.
Obviously, this is irrational. For one thing, I'm sure a lot of students have had teachers like that, but that doesn't stop them from asking questions. Plus, it is extremely rare for someone to actually be annoyed when I ask a question. The mentors and students in the Freeseer group have been nothing but helpful on the occasions when I've asked questions.
There is a reason I have obsessed over this in my blog posts. Learning a technical skill like programming with SQL is one thing, and will make me more informed about databases. But learning to effectively interact with other people and learn from them is more meta-level, and can allow me to more effectively learn technical skills. Oh, and also there's the small fact that forming meaningful relationships with other people is intrinsically worth doing. I like people, but I get anxious around them. I would hate to wake up in a couple decades and think about how much better my life could have been if I had just reached out a little more.
With this in mind, if I were to evaluate myself in this course with a percentage, what would I give myself? I believe it would be fair for me to pass the course, in the sense that I have fulfilled the basic requirements of the course, put in the hours, written the journal entries, and attended the Code Sprint and the hangouts. I've made contributions to the code, which can be verified on Github. So, I think a fair grade would be at least 60%.
However, I don't think I really went above and beyond. There were weeks when I slipped on the number of hours I worked, or when my hours were unproductive. I've already mentioned how I haven't interacted enough with the other members of the team, which means that I didn't give myself the opportunity to collaborate with other people on specific tasks. As a result, I was not nearly as productive as I could have been. I would not give myself more than 80%.
This has been a good experience. Everyone I have met in the process (mentors, students, professors, and so on) has been extremely helpful and nice. If I have been less than completely productive, it is my own responsibility, and has nothing to do with any of the people I have had the pleasure of working with.
Saturday, November 29, 2014
Saturday, November 22, 2014
Week 11: November 16th to November 22nd
What I Did This Week:
- Cleaned up refactor of talkeditor.py
- Started implementing some tests for talk editor
What I Plan to Do Next Week:
- Forge ahead with talk editor tests.
- Look at tests of other features to get a better idea of what good tests look like
Problems:
- Not much to report this week
- Cleaned up refactor of talkeditor.py
- Started implementing some tests for talk editor
What I Plan to Do Next Week:
- Forge ahead with talk editor tests.
- Look at tests of other features to get a better idea of what good tests look like
Problems:
- Not much to report this week
Saturday, November 15, 2014
Week 10: November 9th to November 15th
What I Did This Week:
- Kind of settled on one way to implement the refactoring of the Talk Editor. Refactored it quickly and filthily, mostly to just make sure it would actually work.
What I Plan to Do Next Week:
- Clean up refactoring, make it a little more elegant. Possibly get started on actually testing the methods, which is what this whole refactoring was for to begin with.
Problems:
- Spent perhaps a bit too much time ruminating on how to solve various problems. Ultimately, I got around this by breaking the problem into smaller parts and working for shorter amounts of time (e.g. working for 15 or 30 minutes several times throughout the day rather than working 1 straight hour) to keep myself from getting fatigued.
- Kind of settled on one way to implement the refactoring of the Talk Editor. Refactored it quickly and filthily, mostly to just make sure it would actually work.
What I Plan to Do Next Week:
- Clean up refactoring, make it a little more elegant. Possibly get started on actually testing the methods, which is what this whole refactoring was for to begin with.
Problems:
- Spent perhaps a bit too much time ruminating on how to solve various problems. Ultimately, I got around this by breaking the problem into smaller parts and working for shorter amounts of time (e.g. working for 15 or 30 minutes several times throughout the day rather than working 1 straight hour) to keep myself from getting fatigued.
Saturday, November 8, 2014
Week 9: November 2nd to November 8th
What I Did This Week:
- Made some progress in refactoring talkeditor.py. In particular, made the save prompt a separate file, and looked at alternatives on how to add functionality.
What I Plan to Do Next Week:
- Decide on one way to add functionality to the new save prompt. If it works, then get back to writing tests.
Problems:
- Every time I think I understand Qt, it throws another curveball at me.
- To quote my project proposal: "I have a slight predisposition toward depression and anxiety, which might lead me to procrastinate." It got pretty bad over the last few weeks, and assignments and midterms didn't help. However, I have gotten some work done, and I suspect that the worst is over (I am still taking medication, and I have recently taken steps to make sleep and nutrition a high priority for myself).
Discussion:
When I was in high school, and in the first couple years of university, all the students in the STEM fields had a common frame of reference. We had all taken mostly the same courses, so our skills were pretty interchangeable. But the deeper we get into our education, the more we diverge in what our vocabulary consists of, and the more I find that I have to eliminate certain interests.
For example, I figured out a while ago that I'm probably never going to be an expert physicist. I am okay with that -- in fact, somewhat paradoxically, I can enjoy reading about physics more now that I don't feel the pressure to become an expert in it.
I am starting to think that I'm approaching the same wall when it comes to programming. Maybe not all kinds of programming -- I like solving deep, mathematically interesting problems. I saw a discussion in IRC lamenting how people who don't learn to code in class will end up being mediocre programmers. I have learned to code, and I write a lot of code in my spare time. I've solved a bunch of the Project Euler problems, and I write programs to find the answers to questions I think are interesting, or to solve problems I need to solve. The problem is, most of these problems are mathematical in nature. In a way this is good, because I have gotten a fairly deep and intuitive understanding of algorithms.
But it's bad because it means that I haven't cultivated the breadth of skills that other computer science majors seem to have -- it wasn't until this semester that I figured out how to use Git and SQL -- heck, I didn't even know how to use IRC before this semester, and I'm learning things about Linux every day that it seems like my colleagues have known their whole lives. (I even had trouble figuring out how to format some of the text in this blog post -- I just can't seem to get anything right this week.)
I wish I had a lighter note to end on, but I don't think this is necessarily as bleak for me as it sounds. I know I can survive this course.
- Made some progress in refactoring talkeditor.py. In particular, made the save prompt a separate file, and looked at alternatives on how to add functionality.
What I Plan to Do Next Week:
- Decide on one way to add functionality to the new save prompt. If it works, then get back to writing tests.
Problems:
- Every time I think I understand Qt, it throws another curveball at me.
- To quote my project proposal: "I have a slight predisposition toward depression and anxiety, which might lead me to procrastinate." It got pretty bad over the last few weeks, and assignments and midterms didn't help. However, I have gotten some work done, and I suspect that the worst is over (I am still taking medication, and I have recently taken steps to make sleep and nutrition a high priority for myself).
Discussion:
When I was in high school, and in the first couple years of university, all the students in the STEM fields had a common frame of reference. We had all taken mostly the same courses, so our skills were pretty interchangeable. But the deeper we get into our education, the more we diverge in what our vocabulary consists of, and the more I find that I have to eliminate certain interests.
For example, I figured out a while ago that I'm probably never going to be an expert physicist. I am okay with that -- in fact, somewhat paradoxically, I can enjoy reading about physics more now that I don't feel the pressure to become an expert in it.
I am starting to think that I'm approaching the same wall when it comes to programming. Maybe not all kinds of programming -- I like solving deep, mathematically interesting problems. I saw a discussion in IRC lamenting how people who don't learn to code in class will end up being mediocre programmers. I have learned to code, and I write a lot of code in my spare time. I've solved a bunch of the Project Euler problems, and I write programs to find the answers to questions I think are interesting, or to solve problems I need to solve. The problem is, most of these problems are mathematical in nature. In a way this is good, because I have gotten a fairly deep and intuitive understanding of algorithms.
But it's bad because it means that I haven't cultivated the breadth of skills that other computer science majors seem to have -- it wasn't until this semester that I figured out how to use Git and SQL -- heck, I didn't even know how to use IRC before this semester, and I'm learning things about Linux every day that it seems like my colleagues have known their whole lives. (I even had trouble figuring out how to format some of the text in this blog post -- I just can't seem to get anything right this week.)
I wish I had a lighter note to end on, but I don't think this is necessarily as bleak for me as it sounds. I know I can survive this course.
Saturday, November 1, 2014
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.
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.
Friday, October 24, 2014
Week 7: October 19th to October 25th
What I Did This Week:
- Studied PyTest and UnitTest more. In particular, I learned about the importance of fixtures.
- Consulted Freeseer documentation for contributors on Testing. Also consulted PR #619 and other sources on how Testing is currently done in Freeseer.
- Learned how profiles are created -- in particular, studied Profiles.py, including Profile and ProfileManager classes -- to understand how fixtures use them.
What I Plan to Do Next Week:
- Determine what, in practical terms, has to be tested in order to check whether my new functions in TalkEditor.py work as promised. (For that matter, how do I know if the test itself is valid?)
- Figure out how to write tests that involve a Table View.
Problems:
- Last week I was very sick: this week, I wasn't sick, but I was very busy, and I'll continue to be busy over the weekend. The SFU Choir has a retreat this weekend (9:00 AM Saturday straight to 5:00 PM Sunday), and there has been a surprising amount of preparation to do in the week leading up to it. For that reason, I will not be present at the Sunday Hangout.
- Studied PyTest and UnitTest more. In particular, I learned about the importance of fixtures.
- Consulted Freeseer documentation for contributors on Testing. Also consulted PR #619 and other sources on how Testing is currently done in Freeseer.
- Learned how profiles are created -- in particular, studied Profiles.py, including Profile and ProfileManager classes -- to understand how fixtures use them.
What I Plan to Do Next Week:
- Determine what, in practical terms, has to be tested in order to check whether my new functions in TalkEditor.py work as promised. (For that matter, how do I know if the test itself is valid?)
- Figure out how to write tests that involve a Table View.
Problems:
- Last week I was very sick: this week, I wasn't sick, but I was very busy, and I'll continue to be busy over the weekend. The SFU Choir has a retreat this weekend (9:00 AM Saturday straight to 5:00 PM Sunday), and there has been a surprising amount of preparation to do in the week leading up to it. For that reason, I will not be present at the Sunday Hangout.
Sunday, October 19, 2014
Week 6: October 14th to October 18th
What I Did This Week:
- Finished PR #605
- Studied ConfigToolWidget and a bit about how layouts and resizing works in Qt.
- Opened Issue 630 and PR 631, to create tests for my changes to the TalkEditor
- Studied PyTest and UnitTest
- Updated my Project Proposal to reflect my slight change in plans (specifically, my sudden interest in unit tests)
What I Plan to Do Next Week:
- Work on PR 631.
- In the process, learn more about PyTest and unit testing in general
Problems, past and upcoming:
- I've been very sick this week. It didn't help that I had a midterm and a couple assignments due this week. But I survived, and managed to get some stuff done this week.
- Next week, on Saturday and Sunday, I will be attending the Simon Fraser University Choir Retreat -- I am the Bass section leader, so it is important that I show up for this overnight trip. This means I will definitely miss the Sunday hangout (that's partly why I wanted to volunteer to take minutes this week -- I knew I wouldn't get a chance on the 26th)
- I was planning to meet with Ted Kirkpatrick (the professor representing UCOSP at SFU) this week, but I (unfortunately?) found myself with a ticket to see a lecture by the Dalai Lama on Tuesday at the same time. Whether we reschedule, or I just send him an e-mail update, remains to be seen.
Discussion:
Some people are embarrassed by things they wrote when they were 14 years old. I'm embarrassed by things I wrote a month ago.
When I wrote my Project Proposal (see: https://docs.google.com/document/d/1D98OpJsXvnOMHOWmZkRnb5Xp26Upv2jfMaMP3VYP3WQ) I guess I was thinking "Documentation! I'm good at writing stuff, so yeah, let's do that!" As it turns out, I did some coding, and it turns out I kind of like it -- the experience reminded me of why I enjoy programming in the first place.
When I wrote my project proposal, I was working under the assumption that I would fail at everything I tried. I still think that that's a good way to plan things: people are terrible planners, and it's impossible to predict how a program will evolve, so if you assume you'll come across huge roadblocks every step of the way, you'll come pretty close to predicting your progress on average. In that respect, I think my project proposal comes pretty close to a realistic timeline of what I wanted to do at the time. What I didn't expect was how much my interests would change. I still believe in good documentation, but now that I've had a taste of coding, I want more. That surprised me.
In the interest of keeping my promises, I will keep doing the documentation-related things I mentioned in my Project Proposal (which, when you get right down to it, doesn't add up to a whole lot of time). I'll have time to pursue my other interests within the project as well.
- Finished PR #605
- Studied ConfigToolWidget and a bit about how layouts and resizing works in Qt.
- Opened Issue 630 and PR 631, to create tests for my changes to the TalkEditor
- Studied PyTest and UnitTest
- Updated my Project Proposal to reflect my slight change in plans (specifically, my sudden interest in unit tests)
What I Plan to Do Next Week:
- Work on PR 631.
- In the process, learn more about PyTest and unit testing in general
Problems, past and upcoming:
- I've been very sick this week. It didn't help that I had a midterm and a couple assignments due this week. But I survived, and managed to get some stuff done this week.
- Next week, on Saturday and Sunday, I will be attending the Simon Fraser University Choir Retreat -- I am the Bass section leader, so it is important that I show up for this overnight trip. This means I will definitely miss the Sunday hangout (that's partly why I wanted to volunteer to take minutes this week -- I knew I wouldn't get a chance on the 26th)
- I was planning to meet with Ted Kirkpatrick (the professor representing UCOSP at SFU) this week, but I (unfortunately?) found myself with a ticket to see a lecture by the Dalai Lama on Tuesday at the same time. Whether we reschedule, or I just send him an e-mail update, remains to be seen.
Discussion:
Some people are embarrassed by things they wrote when they were 14 years old. I'm embarrassed by things I wrote a month ago.
When I wrote my Project Proposal (see: https://docs.google.com/document/d/1D98OpJsXvnOMHOWmZkRnb5Xp26Upv2jfMaMP3VYP3WQ) I guess I was thinking "Documentation! I'm good at writing stuff, so yeah, let's do that!" As it turns out, I did some coding, and it turns out I kind of like it -- the experience reminded me of why I enjoy programming in the first place.
When I wrote my project proposal, I was working under the assumption that I would fail at everything I tried. I still think that that's a good way to plan things: people are terrible planners, and it's impossible to predict how a program will evolve, so if you assume you'll come across huge roadblocks every step of the way, you'll come pretty close to predicting your progress on average. In that respect, I think my project proposal comes pretty close to a realistic timeline of what I wanted to do at the time. What I didn't expect was how much my interests would change. I still believe in good documentation, but now that I've had a taste of coding, I want more. That surprised me.
In the interest of keeping my promises, I will keep doing the documentation-related things I mentioned in my Project Proposal (which, when you get right down to it, doesn't add up to a whole lot of time). I'll have time to pursue my other interests within the project as well.
Subscribe to:
Posts (Atom)