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.
Subscribe to:
Posts (Atom)