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.
Saturday, September 27, 2014
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)