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.
Monday, October 13, 2014
Week 5: October 5th to October 13th
What I Did This Week:
- Opened issue #618, involving using quotation marks in various fields in the Talk Editor.
- Discussed changes in PR #605 with Dennis Ideler, e.g. UI changes.
- Studied the Config Tool ant the Qt functions involved with it.
- Looked at the Get Started guide; didn't find anything worth changing at this time.
What I Plan to Do Next Week:
- Continue perfecting PR #605.
- Do some research on how installation works in general, i.e. what's the difference between the Freeseer that gets installed, and the Freeseer we run from the source? I suspect this information will be valuable to me long after I leave this project.
- See if I can get some basic understanding of the code the other students are working on.
Problems, past and upcoming:
- There were some disagreements about what the UI should look like when the user switches from one talk to another without saving the current talk. However, I believe we have reached a consensus about what it should look like now.
- In the past week, I had a number of assignments to do and meetings to go to, as well as a whole Thanksgiving weekend to prepare for and attend. This week, I still have some assignments to do and some midterms to study for. I believe I have kept my head above water so far. This week might not be my most productive. Time in itself is not too much of a problem -- I can easily put in 10 hours, but if I'm working on other things, the hours might not be as focused and productive as I'd like them to be.
- Due to a previous commitment, I will not be able to attend the October 26th hangout.
Discussion:
Not much to talk about this week.
- Opened issue #618, involving using quotation marks in various fields in the Talk Editor.
- Discussed changes in PR #605 with Dennis Ideler, e.g. UI changes.
- Studied the Config Tool ant the Qt functions involved with it.
- Looked at the Get Started guide; didn't find anything worth changing at this time.
What I Plan to Do Next Week:
- Continue perfecting PR #605.
- Do some research on how installation works in general, i.e. what's the difference between the Freeseer that gets installed, and the Freeseer we run from the source? I suspect this information will be valuable to me long after I leave this project.
- See if I can get some basic understanding of the code the other students are working on.
Problems, past and upcoming:
- There were some disagreements about what the UI should look like when the user switches from one talk to another without saving the current talk. However, I believe we have reached a consensus about what it should look like now.
- In the past week, I had a number of assignments to do and meetings to go to, as well as a whole Thanksgiving weekend to prepare for and attend. This week, I still have some assignments to do and some midterms to study for. I believe I have kept my head above water so far. This week might not be my most productive. Time in itself is not too much of a problem -- I can easily put in 10 hours, but if I'm working on other things, the hours might not be as focused and productive as I'd like them to be.
- Due to a previous commitment, I will not be able to attend the October 26th hangout.
Discussion:
Not much to talk about this week.
Saturday, October 4, 2014
Week 4: September 28th to October 4th
What I Did This Week
- Clarified my knowledge about talkeditor.py in written form.
- Learned about QModelIndex and understanding the apply_changes and update_talk methods in talkeditor.py.
- Learned about QPersistentModelIndex, added click_talk method to talkeditor.py. Made PR #605.
- Learned about the Diff utility, so I would have a better idea of how Git worked. Added functional save/discard/cancel window to Talk Editor. Learned how long it takes for commits to be pushed and tested.
- Took screenshot of save/discard/cancel window for PR #605. Finished functionality for save/discard/cancel prompt, including having the prompt come up when the user decides to add a new talk. Learned how to set Gedit up so that pressing "tab" creates 4 spaces instead of a tab character, thus potentially saving me dozens of seconds of time in the near future.
What I Plan to Do Next Week
- Finish whatever changes I will inevitably need to make in PR #605.
- Take another look at the Getting Started page, with reference to the checklist in Issue #442. Consider possible changes to be made, with a focus on making the instructions clear and simple.
- As long as I'm on a roll with the Talk Editor, see if I can get anywhere in solving Issue #532 (Talks should not be unselected after being modified through the table view).
Expected Problems
- The coming weekend is Thanksgiving, and I'll be traveling to celebrate with my family. I am probably not the only one facing this conflict.
- I have a bunch of assignments due in the coming weeks -- I will work hard to balance the work in my different courses so that I don't fall too far behind in any of them, including this one, but it will be difficult.
Discussion
Whenever I write one of these blog posts, I make sure to look at my past blog posts as well as my Project Proposal to get some idea of what direction I'm headed.
Last week, I said that I would look at talkeditor.py and see how far I could get in solving #501. I think I did pretty well -- whether my solution is approved or not remains to be seen, but as far as I can tell, the solution does everything I intended for it to do. The solution came together much more quickly than I expected it to. Remarkably, in the schedule in my Project Proposal, this was the week I half-jokingly said I would have a "magical epiphany" which would solve whatever issue I was working on, and it seems like that's almost what happened. That said, I know I need to be prepared for the possibility that my changes aren't very good or that they conflict with other people's work -- this can be a harsh business sometimes.
I suppose it would have been nice if I had done a bit more communication with my team mates. I want to make sure I know what they're working on, so that I don't step on their toes -- and similarly, I'm starting to see why it's important to let them know what I'm working on, so they don't step on my toes. As far as I can tell, no major conflicts have come up so far, but I want to make sure it stays that way.
Apparently midterm evaluations are coming up. It's hard to enjoy being evaluated, as much as I know it has to be done. All I can say is, I have tried as hard as I can to be productive while keeping my blood pressure at a reasonable level. I am aware that my progress might seem slow, but the fact is that I have made progress. At the beginning of the semester, I was intimidated the prospect of editing preexisting code, and I had no idea how to use Git or any of the Python modules involved with Freeseer. Now I have some idea how to use Git, I have some familiarity with Qt, and I've made some of my own changes to the code with no sign of stopping.
- Clarified my knowledge about talkeditor.py in written form.
- Learned about QModelIndex and understanding the apply_changes and update_talk methods in talkeditor.py.
- Learned about QPersistentModelIndex, added click_talk method to talkeditor.py. Made PR #605.
- Learned about the Diff utility, so I would have a better idea of how Git worked. Added functional save/discard/cancel window to Talk Editor. Learned how long it takes for commits to be pushed and tested.
- Took screenshot of save/discard/cancel window for PR #605. Finished functionality for save/discard/cancel prompt, including having the prompt come up when the user decides to add a new talk. Learned how to set Gedit up so that pressing "tab" creates 4 spaces instead of a tab character, thus potentially saving me dozens of seconds of time in the near future.
What I Plan to Do Next Week
- Finish whatever changes I will inevitably need to make in PR #605.
- Take another look at the Getting Started page, with reference to the checklist in Issue #442. Consider possible changes to be made, with a focus on making the instructions clear and simple.
- As long as I'm on a roll with the Talk Editor, see if I can get anywhere in solving Issue #532 (Talks should not be unselected after being modified through the table view).
Expected Problems
- The coming weekend is Thanksgiving, and I'll be traveling to celebrate with my family. I am probably not the only one facing this conflict.
- I have a bunch of assignments due in the coming weeks -- I will work hard to balance the work in my different courses so that I don't fall too far behind in any of them, including this one, but it will be difficult.
Discussion
Whenever I write one of these blog posts, I make sure to look at my past blog posts as well as my Project Proposal to get some idea of what direction I'm headed.
Last week, I said that I would look at talkeditor.py and see how far I could get in solving #501. I think I did pretty well -- whether my solution is approved or not remains to be seen, but as far as I can tell, the solution does everything I intended for it to do. The solution came together much more quickly than I expected it to. Remarkably, in the schedule in my Project Proposal, this was the week I half-jokingly said I would have a "magical epiphany" which would solve whatever issue I was working on, and it seems like that's almost what happened. That said, I know I need to be prepared for the possibility that my changes aren't very good or that they conflict with other people's work -- this can be a harsh business sometimes.
I suppose it would have been nice if I had done a bit more communication with my team mates. I want to make sure I know what they're working on, so that I don't step on their toes -- and similarly, I'm starting to see why it's important to let them know what I'm working on, so they don't step on my toes. As far as I can tell, no major conflicts have come up so far, but I want to make sure it stays that way.
Apparently midterm evaluations are coming up. It's hard to enjoy being evaluated, as much as I know it has to be done. All I can say is, I have tried as hard as I can to be productive while keeping my blood pressure at a reasonable level. I am aware that my progress might seem slow, but the fact is that I have made progress. At the beginning of the semester, I was intimidated the prospect of editing preexisting code, and I had no idea how to use Git or any of the Python modules involved with Freeseer. Now I have some idea how to use Git, I have some familiarity with Qt, and I've made some of my own changes to the code with no sign of stopping.
Saturday, September 27, 2014
Week 3 - September 21st to September 27th, post-Sprint
What I Did This Week
- Learned a bit about how Freeseer exports .csv files, and for that matter, what .csv files are for. (1 hour).
- Read the w3schools guide to SQL in order to better understand how Freeseer stores talk information in a database. (2.5 hours).
- Learned about .rst files, enough to make some changes and create pull request #599, which included some additions to the Quick Start guide. (2 hours).
- Learned how to squash commits and write long commit messages in the styles recommended by the Best Practices. (0.5 hours).
- With Michael Tom-Wing's help, wrestled with Git for a while in order to successfully squash the commits made for pull request #599. Also spent some time reading about QCompleter in order to understand TalkEditor.py. (1.5 hours).
- Took a closer look at TalkEditor.py functions select_talk, talk_selected and apply_changes to understand them better, with the ultimate goal of figuring out how to fix issue #501. (1.5 hours).
- Wrote this blog post. (2 hours).
What I Intend to Do Next Week
- Understand more of the functions in TalkEditor.py, with the goal of fixing issue #501. Try to find an excuse to ask for help in IRC or the mailing list, in order to help overcome my fear of initiating interaction with others -- after all, you're not a very frightening group of people, I just get very irrationally anxious.
Problems
- I still haven't figured out how to fix #501. I believe that this is because I still don't know enough about how QTableView works and which methods in TalkEditor.py come into play when you click on a talk in the table, and exactly what those methods do. It could be that there's no shortcut, and I just have to power through and learn how all this stuff works.
- As mentioned in "What I Intend to Do Next Week", I get very anxious about initiating interaction with others, and as a result, I don't believe that I have communicated enough with the rest of the team. I am hoping to look for an excuse to ask a question when I look at TalkEditor.py.
Discussion
I'd like to start off with a joke from Annie Hall, a movie I borrowed from the SFU library this week. Alvy (Woody Allen) and Annie (Diane Keaton) are going to two different therapists and talking about their relationship with each other. We see their respective therapy sessions on the left and right half of the screen.
Annie: "We have sex constantly -- two, maybe three times a week."
Alvy: "We hardly ever have sex -- two, maybe three times a week."
What the heck does this have to do with UCOSP and Freeseer? I've mentioned before that I have trouble getting up the courage to mention when something is confusing me and ask for help. However, one of the ideas that the mentors have tried to drill into us, and rightly so, is to communicate early and often about whatever we're working on. I am aware that it is completely irrational of me to be worried about bothering my mentors, because they're there to help, and they have yet to show any annoyance at my asking to help them. This is a fear that I am gradually trying to overcome, but I do think it will take time. As a result, I had this nightmarish vision of myself being evaluated at the end of the semester:
Me: "I communicated with my mentors constantly -- along with my blog posts and the weekly Hangouts, I lurked on IRC, responded to feedback on my pull requests, and occasionally asked questions about things I was confused about."
Mentor: "Ben didn't communicate with us nearly enough -- apart from his blog posts and attendance at the weekly Hangouts, all he did was lurk on IRC and respond to feedback on his pull requests, and only occasionally ask questions about things he was confused about."
Joseph Yeung advised me at the Code Sprint not to worry too much, which I find is good advice, especially in social situations where I have to initiate conversations with other people -- if I'm not worried about how I come across, I come across just fine. Nonetheless, I do experience anxiety at the prospect of initiating conversations with people, even on the internet. I'm nervous thinking about the Hangout tomorrow, and that's something I've done, like, three times already, so it's not like I haven't had enough practice at it.
I have looked at what I've done over the past week. At the Code Sprint, Joseph suggested that one way to look at this course is as 2 to 3 weeks of work at a full-time job, except that each 8-hour day is spread across a week. With that in mind, if I had done everything I did this week in an 8-hour day, I would consider that to be a fairly productive day.
If I may extend this metaphor, I think it would be appropriate for me to being up the few jobs I have had. Unlike my colleagues in this course, I have never done an internship or had any experience programming in any real projects before this one. But I have taken summer jobs to pay for school: I worked at a museum one summer, in a lead refinery another summer, and most recently at Canadian Tire. In all cases, I don't think I got much productive work done in my first few weeks. I was too busy catching up with my coworkers and managers, who already seemed to know everything. At the lead refinery, I actually only saw the inside of the refinery once or twice in my first two weeks -- the rest of the time was spent learning basic safety procedures in an office. At Canadian Tire, I made a point of learning new things every day about the products on the shelves and about the tools I had to use (especially the computer that calculated the paint tints). Even on my last day of work before returning to school, I was still learning new things. And this was a retail store: imagine a programming project, with a large codebase, in which I am expected to make intelligent, surgical improvements.
Sometimes a confusion is best cleared up by asking the right question to the right person (even if the right question turns out to be "Help me?") Other times, there's just no way around acquiring the knowledge necessary to solve the problem. I think that, in the case of some of the problems I will be attempting to tackle in Freeseer, there is no way around gaining a deep understanding of the code. To ask other people for help too often would be a crutch to prevent me from learning. On the other hand, the right question might provide for an opportunity to quickly have the problem elucidated by another person, and help me to solve it. I often think about the differences between useful questions, and non-useful questions -- a bit too often, perhaps.
One way I hope to keep myself on track is to think in the long term: beyond this course, even beyond my university degree. The reason I signed up for this course was because I knew a little something about programming, but there seemed to be a huge gap between the knowledge I had, and the knowledge a person needed in order to contribute to an open-source project. I like open-source software, partly because I'm too cheap to buy software myself, but also partly because of the philosophy behind it -- the idea of putting programmers in control, making the code freely available, and the meritocratic idea that all you need to contribute to the world of software is a good idea and a bit of knowledge. I'm a creative person, but for the time being, knowledge is something I lack. This course seemed like the perfect excuse to dip my toes into the ocean of real-world software development.
As a result, I'm not in this course for the grade or the glory, and my main reason for going to university isn't for the promise of earning more money later on in my life (although that certainly doesn't hurt). I'm here because I want to know stuff. People always ask me what I plan to do with my degree. Hang it on my wall, I tell them. It's the knowledge and skills themselves that are important -- it never seems to occur to anybody that, when you have knowledge, you can, y'know, USE that knowledge. For example, part of the reason I spent so much time this week on SQL is because I know that SQL is used in a lot of programs besides Freeseer, and in the long run, even after this course is over, knowing about SQL will be a very useful skill for me to have, and will allow me to write programs that deal with databases -- I'm told that knowing about SQL is a very marketable skill as well, which is nice, but it's not my primary motivation.
I really want to be able to make programs that solve the kinds of problems I want to solve, and perhaps to solve problems that other people don't even consciously consider to be problems yet. Ultimately, it's kind of a selfish motive, but I don't think that's a bad thing at all. I have already learned a lot about contributing to an open-source project, and no matter what happens grade-wise, I know that I will have learned a lot by the end of the semester -- my time will not have been wasted.
Meta
I have a tendency to ramble a little in my blog posts. I have found that some people in my life enjoy my ramblings, and others don't. I would like to keep them in my posts, because I can provide a valuable first-person account of what it's like to be a student in this program.
In a traditional course, the professor grades the students based on a series of questions which is the same for everybody -- a lazy whiz-kid who knew everything before he signed up for the class might end up with the same grade as an average but hard-working student who paid attention and worked hard to understand the material.
But I get the sense that the UCOSP program is more complicated than that, with part of the grade being based on the goals the students set for themselves, on what the students learn, and on whether the students are able to make steady progress.
With that in mind, I would like to keep using my blog posts to make available as much data as possible on what was going through my mind each week. This is partly for my own benefit (I enjoy the act of writing to clarify my own thoughts) and partly for the benefit of whoever has to evaluate my performance in this course.
However, since not everybody needs to know what's going on inside my head, I think the best compromise would be to start my posts with a few short sections, followed by a Discussion. The short sections will be just the facts, ma'am: What I Did This Week, What I Plan to Do Next Week, and Problems. The Discussion will be the longer, stream of consciousness stuff. I might occasionally include a Meta section, like this one, for anything blog-related.
- Learned a bit about how Freeseer exports .csv files, and for that matter, what .csv files are for. (1 hour).
- Read the w3schools guide to SQL in order to better understand how Freeseer stores talk information in a database. (2.5 hours).
- Learned about .rst files, enough to make some changes and create pull request #599, which included some additions to the Quick Start guide. (2 hours).
- Learned how to squash commits and write long commit messages in the styles recommended by the Best Practices. (0.5 hours).
- With Michael Tom-Wing's help, wrestled with Git for a while in order to successfully squash the commits made for pull request #599. Also spent some time reading about QCompleter in order to understand TalkEditor.py. (1.5 hours).
- Took a closer look at TalkEditor.py functions select_talk, talk_selected and apply_changes to understand them better, with the ultimate goal of figuring out how to fix issue #501. (1.5 hours).
- Wrote this blog post. (2 hours).
What I Intend to Do Next Week
- Understand more of the functions in TalkEditor.py, with the goal of fixing issue #501. Try to find an excuse to ask for help in IRC or the mailing list, in order to help overcome my fear of initiating interaction with others -- after all, you're not a very frightening group of people, I just get very irrationally anxious.
Problems
- I still haven't figured out how to fix #501. I believe that this is because I still don't know enough about how QTableView works and which methods in TalkEditor.py come into play when you click on a talk in the table, and exactly what those methods do. It could be that there's no shortcut, and I just have to power through and learn how all this stuff works.
- As mentioned in "What I Intend to Do Next Week", I get very anxious about initiating interaction with others, and as a result, I don't believe that I have communicated enough with the rest of the team. I am hoping to look for an excuse to ask a question when I look at TalkEditor.py.
Discussion
I'd like to start off with a joke from Annie Hall, a movie I borrowed from the SFU library this week. Alvy (Woody Allen) and Annie (Diane Keaton) are going to two different therapists and talking about their relationship with each other. We see their respective therapy sessions on the left and right half of the screen.
Annie: "We have sex constantly -- two, maybe three times a week."
Alvy: "We hardly ever have sex -- two, maybe three times a week."
What the heck does this have to do with UCOSP and Freeseer? I've mentioned before that I have trouble getting up the courage to mention when something is confusing me and ask for help. However, one of the ideas that the mentors have tried to drill into us, and rightly so, is to communicate early and often about whatever we're working on. I am aware that it is completely irrational of me to be worried about bothering my mentors, because they're there to help, and they have yet to show any annoyance at my asking to help them. This is a fear that I am gradually trying to overcome, but I do think it will take time. As a result, I had this nightmarish vision of myself being evaluated at the end of the semester:
Me: "I communicated with my mentors constantly -- along with my blog posts and the weekly Hangouts, I lurked on IRC, responded to feedback on my pull requests, and occasionally asked questions about things I was confused about."
Mentor: "Ben didn't communicate with us nearly enough -- apart from his blog posts and attendance at the weekly Hangouts, all he did was lurk on IRC and respond to feedback on his pull requests, and only occasionally ask questions about things he was confused about."
Joseph Yeung advised me at the Code Sprint not to worry too much, which I find is good advice, especially in social situations where I have to initiate conversations with other people -- if I'm not worried about how I come across, I come across just fine. Nonetheless, I do experience anxiety at the prospect of initiating conversations with people, even on the internet. I'm nervous thinking about the Hangout tomorrow, and that's something I've done, like, three times already, so it's not like I haven't had enough practice at it.
I have looked at what I've done over the past week. At the Code Sprint, Joseph suggested that one way to look at this course is as 2 to 3 weeks of work at a full-time job, except that each 8-hour day is spread across a week. With that in mind, if I had done everything I did this week in an 8-hour day, I would consider that to be a fairly productive day.
If I may extend this metaphor, I think it would be appropriate for me to being up the few jobs I have had. Unlike my colleagues in this course, I have never done an internship or had any experience programming in any real projects before this one. But I have taken summer jobs to pay for school: I worked at a museum one summer, in a lead refinery another summer, and most recently at Canadian Tire. In all cases, I don't think I got much productive work done in my first few weeks. I was too busy catching up with my coworkers and managers, who already seemed to know everything. At the lead refinery, I actually only saw the inside of the refinery once or twice in my first two weeks -- the rest of the time was spent learning basic safety procedures in an office. At Canadian Tire, I made a point of learning new things every day about the products on the shelves and about the tools I had to use (especially the computer that calculated the paint tints). Even on my last day of work before returning to school, I was still learning new things. And this was a retail store: imagine a programming project, with a large codebase, in which I am expected to make intelligent, surgical improvements.
Sometimes a confusion is best cleared up by asking the right question to the right person (even if the right question turns out to be "Help me?") Other times, there's just no way around acquiring the knowledge necessary to solve the problem. I think that, in the case of some of the problems I will be attempting to tackle in Freeseer, there is no way around gaining a deep understanding of the code. To ask other people for help too often would be a crutch to prevent me from learning. On the other hand, the right question might provide for an opportunity to quickly have the problem elucidated by another person, and help me to solve it. I often think about the differences between useful questions, and non-useful questions -- a bit too often, perhaps.
One way I hope to keep myself on track is to think in the long term: beyond this course, even beyond my university degree. The reason I signed up for this course was because I knew a little something about programming, but there seemed to be a huge gap between the knowledge I had, and the knowledge a person needed in order to contribute to an open-source project. I like open-source software, partly because I'm too cheap to buy software myself, but also partly because of the philosophy behind it -- the idea of putting programmers in control, making the code freely available, and the meritocratic idea that all you need to contribute to the world of software is a good idea and a bit of knowledge. I'm a creative person, but for the time being, knowledge is something I lack. This course seemed like the perfect excuse to dip my toes into the ocean of real-world software development.
As a result, I'm not in this course for the grade or the glory, and my main reason for going to university isn't for the promise of earning more money later on in my life (although that certainly doesn't hurt). I'm here because I want to know stuff. People always ask me what I plan to do with my degree. Hang it on my wall, I tell them. It's the knowledge and skills themselves that are important -- it never seems to occur to anybody that, when you have knowledge, you can, y'know, USE that knowledge. For example, part of the reason I spent so much time this week on SQL is because I know that SQL is used in a lot of programs besides Freeseer, and in the long run, even after this course is over, knowing about SQL will be a very useful skill for me to have, and will allow me to write programs that deal with databases -- I'm told that knowing about SQL is a very marketable skill as well, which is nice, but it's not my primary motivation.
I really want to be able to make programs that solve the kinds of problems I want to solve, and perhaps to solve problems that other people don't even consciously consider to be problems yet. Ultimately, it's kind of a selfish motive, but I don't think that's a bad thing at all. I have already learned a lot about contributing to an open-source project, and no matter what happens grade-wise, I know that I will have learned a lot by the end of the semester -- my time will not have been wasted.
Meta
I have a tendency to ramble a little in my blog posts. I have found that some people in my life enjoy my ramblings, and others don't. I would like to keep them in my posts, because I can provide a valuable first-person account of what it's like to be a student in this program.
In a traditional course, the professor grades the students based on a series of questions which is the same for everybody -- a lazy whiz-kid who knew everything before he signed up for the class might end up with the same grade as an average but hard-working student who paid attention and worked hard to understand the material.
But I get the sense that the UCOSP program is more complicated than that, with part of the grade being based on the goals the students set for themselves, on what the students learn, and on whether the students are able to make steady progress.
With that in mind, I would like to keep using my blog posts to make available as much data as possible on what was going through my mind each week. This is partly for my own benefit (I enjoy the act of writing to clarify my own thoughts) and partly for the benefit of whoever has to evaluate my performance in this course.
However, since not everybody needs to know what's going on inside my head, I think the best compromise would be to start my posts with a few short sections, followed by a Discussion. The short sections will be just the facts, ma'am: What I Did This Week, What I Plan to Do Next Week, and Problems. The Discussion will be the longer, stream of consciousness stuff. I might occasionally include a Meta section, like this one, for anything blog-related.
Monday, September 22, 2014
Week 2: Code Sprint
This is the week of the Code Sprint. Naturally, there will be a lot to talk about. I have spent a little while learning about Qt by reading the code for talkeditor.py and TalkDetailsWidget.py, and Googling the names of methods I didn't understand. I didn't spend as much time on this before the sprint as I would have liked to: however, the code is slightly less intimidating to me than it was before, so that's good. Years ago when I took my first-year computer science course, we learned Java, and one of the things we learned how to use was the Javax/Swing package, so that's the totality of my experience with GUI packages before this.
Friday, 11:00 AM (Toronto): As I write this, it is Friday morning. Joseph Yeung has talked to us about what is expected of us in this course, and the importance of communicating and asking questions.
It is a little difficult to work when everybody is talking quietly. If everybody were yelling, it would all be white noise, and I could work fine, but when it's just one person talking every few moments, then my mind wants to pay attention to each person as they talk.
It is still a little intimidating to be around the other students in this project. It seems like everybody else has done internships and work experience somewhere, so everybody else has already had plenty of experience with programming with other people in the real world. Meanwhile, all I've done is take computer science courses (many of which involved more pencil-and-paper theory than actual programming) and write little programs for my own amusement. I hope that the mentors will keep this in mind when deciding on my grade at the end of this semester -- I strongly doubt that I will be as productive as my teammates on any absolute level, but I think that I will make a lot of personal progress, in the sense that I will be much more skilled than I was when I started.
Friday, 2:50 PM (Toronto): I'm taking some time to write some more because I am currently installing Sphinx, which is apparently required to run the test suite. "Test suite" is a phrase I hadn't heard until today, as is the phrase "code base."
Michelle Craig went to each table and told us about how, each semester, at least one student fails this course. Naturally, I don't want to fail, so I will make sure to put in 10 to 12 hours each week, as I promised in my project proposal. However, I still worry that that won't be enough to make sufficient progress.
I have tried to be honest about where I am now, what I expect to be able to do, and what I am learning each week. I know that I am encouraged to talk to a mentor if I get stuck on anything. At this point, I don't think I've gotten stuck on anything that I haven't mentioned to a mentor yet; I've just been making very, very slow progress. This is an important distinction to make. Even today, in the six hours since starting this morning, I have learned how to run the test suite, what it means in practice to switch from branch to branch in Git, and a bunch about the Qt library, including a bit about how translation works. I also literally just noticed that the files "requirements.txt" and "dev_requirements.txt" can be run with pip, e.g. "pip install -r requirements.txt" (full disclosure: I wouldn't have noticed it if Francisco hadn't pointed it out to me, so thank you, Francisco). I didn't know any of that before. To an untrained observer, it might look like I haven't accomplished anything today, but compared to where I was yesterday, I believe I've accomplished quite a bit.
One issue is that, in some cases, there are things that I literally just didn't know enough about to ask a coherent question. Like I said, I hadn't heard the term "test suite" until today, so how could I know that Freeseer had one, let alone how to run it?
Friday, 5:00 PM (Toronto): I have figured out how to use QMessageBox to ask questions (e.g. "Save changes to current talk? Save/Discard/Cancel") and I've learned a little bit about how information is exchanged between the table that lists all the talks, and the TalkDetailsWidget (apparently Qt has these things called "Signals" and "Slots", something I just found out today). This might not seem like a lot, but I consider that to be huge progress for me towards figuring out how to fix Issue #501. I spent a lot of today figuring out how the "talk_selected" method worked. Tomorrow, I will try to learn more about the other related methods in talkeditor.py. I suspect it won't take as long -- I have learned a lot today.
Saturday, 11:50 AM (Toronto): More learning about Qt by reading and playing around with talkeditor.py and looking at the Qt documentation. I now know a little something about QtDataWidgetMapper, and about Model/View pattern.
I am doing this with the goal of solving Issue #501. I have sort of figured out how saving works. The reason I am looking at QtDataWidgetMapper is to get a better understanding of how selecting a talk from the list works.
Ultimately, my vision is to have something like this: The user selects a talk from the list, by either pressing enter or clicking on it. If their current talk hasn't been saved, then a message box comes up that says "Save changes in current talk?" with the options Save, Discard, or Cancel (Save is the default selection). If the user selects Save, then the changes are saved before the new talk is selected. If the used selects Discard, then the changes are discarded before the new talk is selected. If the user selects cancel, then the talk with unsaved changes remains selected.
Saturday, 3:40 PM (Toronto): Time flies. I have volunteered to give a short presentation to the other students on what Freeseer is and what we intend to accomplish this semester. I am banking on the fact that, although I might not have the most technical knowledge, I like to think of myself as a decent public speaker. We'll have to see whether I'm correct.
I haven't yet finished solving #501. However, I am making progress -- if nothing else, I'm learning more and more about Qt every minute. At one point I thought I might have been stuck, but it occurred to me that, if I'm working on the Save feature on the Talk Editor, it might be a good idea for me to familiarize myself with database.py (when I say "it occurred to me", I mean "Joseph Yeung explicitly mentioned the importance of the database when I mentioned I was working on Issue #501").
Saturday, 5:00 PM (Toronto): The presentation went fine, as far as I can tell. The audience was laughing. Whether they were laughing at me or with me, I might never know, but laughter is laughter. I'll go ahead and call that a success.
Sunday, 9:30 AM (Toronto): Since this is the last day I have to see my teammates in person, I will spend a bit of time considering questions that I want to ask in person before leaving Toronto. When I was in high school and through some of my university studies, I had the unfortunate habit of failing to notice when I was confused by something -- after all, in a lot of classes, you can get by through rote memorization or BS-ing. This is something I am working hard to remedy, but it takes conscious effort.
Sunday, 11:00 AM (Toronto): I have made another pull request. If my first pull request (changing a space in the Copyright notice on a file, which was bad because the notice was copied directly from somewhere else and shouldn't be altered) was a 0 out of 10, I would like to think that this new one deserves at least a 2.4 out of 10, in the sense that at least there's a good idea behind it -- I added an instruction in the Basic guide for Contributors, explaining how to install the requirements and dev requirements.
For the remainder of the day (that is, until 12 noon) my plan is to familiarize myself with database.py, since it might be relevant to understanding the Save function in the talk window. I notice that PyQt4 has something called QtSql, and database.py imports QtSql from PyQt4. It seems like it might be a good idea for me to learn a little something about Sql. My current level of knowledge is that Sql has something to do with databases -- that's about it. I won't waste the entire semester learning about the theory of databases, but it seems to me that it might be to my advantage to at least get a bird's-eye view of the subject, for this course and beyond.
Monday, 11:40 AM (Burnaby): I'm back. I now have a bunch of laundry to do and a bunch of homework to catch up on. I still intend to put in my 10 to 12 hours of work this week, but it will probably be rather low-stress work. I don't believe this will be a problem -- I am still within my projected schedule as outlined in my Project Proposal, and in fact a little bit ahead (I've already done some hands-on experimentation with Qt and become quite familiar with talkeditor.py).
There have been some issues with the pull request I made yesterday. I would like to spend some time addressing that in the coming week. In addition, this week I intend to learn a little bit about SQL, and keep plugging away at #501 -- at this point, I am learning a little bit about how saving information to the talk database works, hence my desire to learn about SQL and QtSql. I suspect I will get stuck at some point, at which point I will do my best to articulate my confusions, either to the mailing list or IRC depending on how long I ramble on.
In yesterday's meeting, Joseph addressed some of my concerns about my own ignorance. He advised me not to worry, and said that, in a course like this, the amount of progress you make is more important than your absolute number of contributions. This was somewhat reassuring -- I have tried to approach this course with the motive of learning the skills it takes to contribute to a project like this, not with the intention of getting an easy grade.
TL;DR:
What I did: Went to Code Sprint, met mentor Joseph and the other students in the program. Experimented with Qt and familiarized myself with talkeditor.py and TalkDetailsWidget.py. Made a pull request related to Issue #432.
What I intend to do: Figure out how the talk database works, hopefully getting a bird's-eye view of how Sql works in the process. Attempt to address concerns about Issue #432 pull request.
Friday, 11:00 AM (Toronto): As I write this, it is Friday morning. Joseph Yeung has talked to us about what is expected of us in this course, and the importance of communicating and asking questions.
It is a little difficult to work when everybody is talking quietly. If everybody were yelling, it would all be white noise, and I could work fine, but when it's just one person talking every few moments, then my mind wants to pay attention to each person as they talk.
It is still a little intimidating to be around the other students in this project. It seems like everybody else has done internships and work experience somewhere, so everybody else has already had plenty of experience with programming with other people in the real world. Meanwhile, all I've done is take computer science courses (many of which involved more pencil-and-paper theory than actual programming) and write little programs for my own amusement. I hope that the mentors will keep this in mind when deciding on my grade at the end of this semester -- I strongly doubt that I will be as productive as my teammates on any absolute level, but I think that I will make a lot of personal progress, in the sense that I will be much more skilled than I was when I started.
Friday, 2:50 PM (Toronto): I'm taking some time to write some more because I am currently installing Sphinx, which is apparently required to run the test suite. "Test suite" is a phrase I hadn't heard until today, as is the phrase "code base."
Michelle Craig went to each table and told us about how, each semester, at least one student fails this course. Naturally, I don't want to fail, so I will make sure to put in 10 to 12 hours each week, as I promised in my project proposal. However, I still worry that that won't be enough to make sufficient progress.
I have tried to be honest about where I am now, what I expect to be able to do, and what I am learning each week. I know that I am encouraged to talk to a mentor if I get stuck on anything. At this point, I don't think I've gotten stuck on anything that I haven't mentioned to a mentor yet; I've just been making very, very slow progress. This is an important distinction to make. Even today, in the six hours since starting this morning, I have learned how to run the test suite, what it means in practice to switch from branch to branch in Git, and a bunch about the Qt library, including a bit about how translation works. I also literally just noticed that the files "requirements.txt" and "dev_requirements.txt" can be run with pip, e.g. "pip install -r requirements.txt" (full disclosure: I wouldn't have noticed it if Francisco hadn't pointed it out to me, so thank you, Francisco). I didn't know any of that before. To an untrained observer, it might look like I haven't accomplished anything today, but compared to where I was yesterday, I believe I've accomplished quite a bit.
One issue is that, in some cases, there are things that I literally just didn't know enough about to ask a coherent question. Like I said, I hadn't heard the term "test suite" until today, so how could I know that Freeseer had one, let alone how to run it?
Friday, 5:00 PM (Toronto): I have figured out how to use QMessageBox to ask questions (e.g. "Save changes to current talk? Save/Discard/Cancel") and I've learned a little bit about how information is exchanged between the table that lists all the talks, and the TalkDetailsWidget (apparently Qt has these things called "Signals" and "Slots", something I just found out today). This might not seem like a lot, but I consider that to be huge progress for me towards figuring out how to fix Issue #501. I spent a lot of today figuring out how the "talk_selected" method worked. Tomorrow, I will try to learn more about the other related methods in talkeditor.py. I suspect it won't take as long -- I have learned a lot today.
Saturday, 11:50 AM (Toronto): More learning about Qt by reading and playing around with talkeditor.py and looking at the Qt documentation. I now know a little something about QtDataWidgetMapper, and about Model/View pattern.
I am doing this with the goal of solving Issue #501. I have sort of figured out how saving works. The reason I am looking at QtDataWidgetMapper is to get a better understanding of how selecting a talk from the list works.
Ultimately, my vision is to have something like this: The user selects a talk from the list, by either pressing enter or clicking on it. If their current talk hasn't been saved, then a message box comes up that says "Save changes in current talk?" with the options Save, Discard, or Cancel (Save is the default selection). If the user selects Save, then the changes are saved before the new talk is selected. If the used selects Discard, then the changes are discarded before the new talk is selected. If the user selects cancel, then the talk with unsaved changes remains selected.
Saturday, 3:40 PM (Toronto): Time flies. I have volunteered to give a short presentation to the other students on what Freeseer is and what we intend to accomplish this semester. I am banking on the fact that, although I might not have the most technical knowledge, I like to think of myself as a decent public speaker. We'll have to see whether I'm correct.
I haven't yet finished solving #501. However, I am making progress -- if nothing else, I'm learning more and more about Qt every minute. At one point I thought I might have been stuck, but it occurred to me that, if I'm working on the Save feature on the Talk Editor, it might be a good idea for me to familiarize myself with database.py (when I say "it occurred to me", I mean "Joseph Yeung explicitly mentioned the importance of the database when I mentioned I was working on Issue #501").
Saturday, 5:00 PM (Toronto): The presentation went fine, as far as I can tell. The audience was laughing. Whether they were laughing at me or with me, I might never know, but laughter is laughter. I'll go ahead and call that a success.
Sunday, 9:30 AM (Toronto): Since this is the last day I have to see my teammates in person, I will spend a bit of time considering questions that I want to ask in person before leaving Toronto. When I was in high school and through some of my university studies, I had the unfortunate habit of failing to notice when I was confused by something -- after all, in a lot of classes, you can get by through rote memorization or BS-ing. This is something I am working hard to remedy, but it takes conscious effort.
Sunday, 11:00 AM (Toronto): I have made another pull request. If my first pull request (changing a space in the Copyright notice on a file, which was bad because the notice was copied directly from somewhere else and shouldn't be altered) was a 0 out of 10, I would like to think that this new one deserves at least a 2.4 out of 10, in the sense that at least there's a good idea behind it -- I added an instruction in the Basic guide for Contributors, explaining how to install the requirements and dev requirements.
For the remainder of the day (that is, until 12 noon) my plan is to familiarize myself with database.py, since it might be relevant to understanding the Save function in the talk window. I notice that PyQt4 has something called QtSql, and database.py imports QtSql from PyQt4. It seems like it might be a good idea for me to learn a little something about Sql. My current level of knowledge is that Sql has something to do with databases -- that's about it. I won't waste the entire semester learning about the theory of databases, but it seems to me that it might be to my advantage to at least get a bird's-eye view of the subject, for this course and beyond.
Monday, 11:40 AM (Burnaby): I'm back. I now have a bunch of laundry to do and a bunch of homework to catch up on. I still intend to put in my 10 to 12 hours of work this week, but it will probably be rather low-stress work. I don't believe this will be a problem -- I am still within my projected schedule as outlined in my Project Proposal, and in fact a little bit ahead (I've already done some hands-on experimentation with Qt and become quite familiar with talkeditor.py).
There have been some issues with the pull request I made yesterday. I would like to spend some time addressing that in the coming week. In addition, this week I intend to learn a little bit about SQL, and keep plugging away at #501 -- at this point, I am learning a little bit about how saving information to the talk database works, hence my desire to learn about SQL and QtSql. I suspect I will get stuck at some point, at which point I will do my best to articulate my confusions, either to the mailing list or IRC depending on how long I ramble on.
In yesterday's meeting, Joseph addressed some of my concerns about my own ignorance. He advised me not to worry, and said that, in a course like this, the amount of progress you make is more important than your absolute number of contributions. This was somewhat reassuring -- I have tried to approach this course with the motive of learning the skills it takes to contribute to a project like this, not with the intention of getting an easy grade.
TL;DR:
What I did: Went to Code Sprint, met mentor Joseph and the other students in the program. Experimented with Qt and familiarized myself with talkeditor.py and TalkDetailsWidget.py. Made a pull request related to Issue #432.
What I intend to do: Figure out how the talk database works, hopefully getting a bird's-eye view of how Sql works in the process. Attempt to address concerns about Issue #432 pull request.
Saturday, September 13, 2014
Week 1
I am Ben Buckley. I'm not a hundred percent sure what I'm expected to write in my weekly blog post, but I will take it as an opportunity to reflect on what I've done each week and reorient myself towards my goals -- whatever those goals turn out to be. Since I assume someone, somewhere will end up reading these blog posts, I will do my best to stay entertaining.
I applied for the UCOSP program because I wanted to know what it was like to contribute to an open-source project. No matter what happens this semester, I am confident that I will know a lot more leaving than I did coming in.
Going in, I honestly didn't know very much. The thing is, in typical computer science courses, you learn how to program by doing isolated problems with preset solutions. There's a huge gap between solving problems designed to teach a specific concept, and actually being able to contribute to a project that people use.
It seems like learning to program is like learning a natural language. Just because you know how to diagram a sentence, doesn't mean you'll be able to fully appreciate James Joyce. There's more to it than just the syntax of the language. You also need a vast store of real-world knowledge. There is no shortcut to gaining this knowledge; it takes a long time.
The unfortunate thing is that often, when an expert knows a lot about a subject, they overestimate how easy it is for other people to master the same subject. So far, my mentors have been courteous about answering my questions. However, in the past I've had professors who hated answering questions -- even if they paid lip service to the value of asking questions, you could tell they didn't enjoy answering them. I'm always a bit nervous about asking questions, because I don't like to bother people. But on an intellectual level, I know that in the long run it is less trouble for everybody if I ask as many questions as I can as soon as I can, so that I can overcome any confusion I have and get started with productive work right away. So, it is important that I work on overcoming my fear of asking questions.
One of the reasons that asking questions can be so scary is that, when you ask a question, you are revealing your own ignorance. In an educational environment, it would be nice if this were encouraged, but in practice, admitting one's ignorance often results in being criticized by the person whose job it is to teach you, e.g. "I shouldn't have to explain something so obvious. You should know this stuff already." However, there are also times when I've asked a question about something, only to find that other students were confused about it as well. For that reason, I will try not to bluff my way through my blog posts. I will do my best to list everything that I am ignorant about. If my posts end up being very, very long as a result of this policy, then so be it.
I took one step in overcoming this fear in the past week. I had downloaded Freeseer, and I was trying to run it from the source. I could open the program, but I couldn't record anything. So, I posted in the Google group about it, and within a day, we set up a Google hangout to figure out what was going wrong. Michael Tom-Wing and Thanh Ha were very helpful, and ultimately we were able to solve the problem. Apparently it had something to do with how I installed one of the libraries? At any rate, I am able to record video and audio on my laptop.
One upside of my fear of asking questions is that I have gotten fairly good at learning things on my own. I have spent most of the last few weeks reading about things I need to understand in order to make meaningful contributions to Freeseer. This included, of course, the documentation for Freeseer, but it also included learning about Git and about Bash scripts. It also required me to learn about aspects of Python that I didn't know about, or about which my knowledge is a bit shaky. For example, I didn't know anything about logging in Python, and I haven't had much practice writing programs where catching exceptions plays a big part. I have also never used the Qt or GStreamer libraries before.
Learning about Git is a project on its own. Intellectually, I have some idea of what it's for -- it gives you a way to experiment on a project by making a branch, and making changes to that branch in the form of commits. In the past few weeks, I've learned a lot about how Git works, but I still have a very long way to go, I think. Sometimes I can Google the answer to a question, but a lot of the time, I need to read more about Git just so I can articulate a meaningful question, let alone understand the answer. Git is the first version control system I have ever used -- maybe if I had used other systems beforehand and dealt with the problems that Git is designed to solve, I would understand it a bit better. But alas, I have to work with the knowledge that I have.
I have spent some time in the past week considering what I want to work on this semester. Given my passion for making things understandable and easy, two things come to mind: the Freeseer GUI, and the documentation. What the GUI and documentation have in common is that they are both intended, in some sense, to communicate the purpose and features of the project to its users and developers. A common issue I have noticed among people who work in technical professions is that they are not always good at communicating their knowledge to other people. This is where I believe I might be of some use. I don't have a much technical knowledge as everybody else on the project, but when I do have knowledge, I am obsessive about being able to communicate it in a way that makes sense. I don't claim that I always succeed, but I am passionate enough about communication that I would be willing to stick with it for the entire semester.
I would like to spend some time working on both the GUI and on the documentation -- if I get tired of working on one of those two things, I can take a break and work on the other for a while. Working on the GUI will allow me to get my hands dirty with the code in a way that interests me, and doing research for the documentation will give me enough experience reading the code and using the program that I can contribute to other aspects of the project as well, especially if I decide to stay on the project after the course is over.
What do I hope to accomplish by the end of the semester? Ordinarily, when it comes to improving communication between developers and users, I would settle for nothing less than a total revolution in human consciousness. But since this is only a 3-credit course, I will have to settle for smaller goals. When I look at the list of open issues, I can see plenty that are relevant to my interests. For example, there's issue #532: after a talk is modified in the table view, it becomes unselected. This seems like a tiny problem, but it doesn't seem to have been addressed (I am able to reproduce it). Fixing it would make a small but noticeable difference in the user's experience.
Another issue is #442, "Reorganize Get Started Guide". I made some mistakes when I was setting up Freeseer, so I have firsthand experience in the importance of having a good starting guide.
With that in mind, I believe that I am ready to start drafting up my project proposal for the semester. I think I'll start doing that now.
EDIT: I've done my project proposal, and it can be seen here: https://docs.google.com/document/d/1D98OpJsXvnOMHOWmZkRnb5Xp26Upv2jfMaMP3VYP3WQ/edit?usp=sharing
I applied for the UCOSP program because I wanted to know what it was like to contribute to an open-source project. No matter what happens this semester, I am confident that I will know a lot more leaving than I did coming in.
Going in, I honestly didn't know very much. The thing is, in typical computer science courses, you learn how to program by doing isolated problems with preset solutions. There's a huge gap between solving problems designed to teach a specific concept, and actually being able to contribute to a project that people use.
It seems like learning to program is like learning a natural language. Just because you know how to diagram a sentence, doesn't mean you'll be able to fully appreciate James Joyce. There's more to it than just the syntax of the language. You also need a vast store of real-world knowledge. There is no shortcut to gaining this knowledge; it takes a long time.
The unfortunate thing is that often, when an expert knows a lot about a subject, they overestimate how easy it is for other people to master the same subject. So far, my mentors have been courteous about answering my questions. However, in the past I've had professors who hated answering questions -- even if they paid lip service to the value of asking questions, you could tell they didn't enjoy answering them. I'm always a bit nervous about asking questions, because I don't like to bother people. But on an intellectual level, I know that in the long run it is less trouble for everybody if I ask as many questions as I can as soon as I can, so that I can overcome any confusion I have and get started with productive work right away. So, it is important that I work on overcoming my fear of asking questions.
One of the reasons that asking questions can be so scary is that, when you ask a question, you are revealing your own ignorance. In an educational environment, it would be nice if this were encouraged, but in practice, admitting one's ignorance often results in being criticized by the person whose job it is to teach you, e.g. "I shouldn't have to explain something so obvious. You should know this stuff already." However, there are also times when I've asked a question about something, only to find that other students were confused about it as well. For that reason, I will try not to bluff my way through my blog posts. I will do my best to list everything that I am ignorant about. If my posts end up being very, very long as a result of this policy, then so be it.
I took one step in overcoming this fear in the past week. I had downloaded Freeseer, and I was trying to run it from the source. I could open the program, but I couldn't record anything. So, I posted in the Google group about it, and within a day, we set up a Google hangout to figure out what was going wrong. Michael Tom-Wing and Thanh Ha were very helpful, and ultimately we were able to solve the problem. Apparently it had something to do with how I installed one of the libraries? At any rate, I am able to record video and audio on my laptop.
One upside of my fear of asking questions is that I have gotten fairly good at learning things on my own. I have spent most of the last few weeks reading about things I need to understand in order to make meaningful contributions to Freeseer. This included, of course, the documentation for Freeseer, but it also included learning about Git and about Bash scripts. It also required me to learn about aspects of Python that I didn't know about, or about which my knowledge is a bit shaky. For example, I didn't know anything about logging in Python, and I haven't had much practice writing programs where catching exceptions plays a big part. I have also never used the Qt or GStreamer libraries before.
Learning about Git is a project on its own. Intellectually, I have some idea of what it's for -- it gives you a way to experiment on a project by making a branch, and making changes to that branch in the form of commits. In the past few weeks, I've learned a lot about how Git works, but I still have a very long way to go, I think. Sometimes I can Google the answer to a question, but a lot of the time, I need to read more about Git just so I can articulate a meaningful question, let alone understand the answer. Git is the first version control system I have ever used -- maybe if I had used other systems beforehand and dealt with the problems that Git is designed to solve, I would understand it a bit better. But alas, I have to work with the knowledge that I have.
I have spent some time in the past week considering what I want to work on this semester. Given my passion for making things understandable and easy, two things come to mind: the Freeseer GUI, and the documentation. What the GUI and documentation have in common is that they are both intended, in some sense, to communicate the purpose and features of the project to its users and developers. A common issue I have noticed among people who work in technical professions is that they are not always good at communicating their knowledge to other people. This is where I believe I might be of some use. I don't have a much technical knowledge as everybody else on the project, but when I do have knowledge, I am obsessive about being able to communicate it in a way that makes sense. I don't claim that I always succeed, but I am passionate enough about communication that I would be willing to stick with it for the entire semester.
I would like to spend some time working on both the GUI and on the documentation -- if I get tired of working on one of those two things, I can take a break and work on the other for a while. Working on the GUI will allow me to get my hands dirty with the code in a way that interests me, and doing research for the documentation will give me enough experience reading the code and using the program that I can contribute to other aspects of the project as well, especially if I decide to stay on the project after the course is over.
What do I hope to accomplish by the end of the semester? Ordinarily, when it comes to improving communication between developers and users, I would settle for nothing less than a total revolution in human consciousness. But since this is only a 3-credit course, I will have to settle for smaller goals. When I look at the list of open issues, I can see plenty that are relevant to my interests. For example, there's issue #532: after a talk is modified in the table view, it becomes unselected. This seems like a tiny problem, but it doesn't seem to have been addressed (I am able to reproduce it). Fixing it would make a small but noticeable difference in the user's experience.
Another issue is #442, "Reorganize Get Started Guide". I made some mistakes when I was setting up Freeseer, so I have firsthand experience in the importance of having a good starting guide.
With that in mind, I believe that I am ready to start drafting up my project proposal for the semester. I think I'll start doing that now.
EDIT: I've done my project proposal, and it can be seen here: https://docs.google.com/document/d/1D98OpJsXvnOMHOWmZkRnb5Xp26Upv2jfMaMP3VYP3WQ/edit?usp=sharing
Subscribe to:
Posts (Atom)