Recently in Writing Assignments Category

I never used source control before this class. In Lab01, when I got started on it, I thought it was just a repository and my partner and I could put our work into the same place, and then the TA could check our work from there. During Lab01, we were learning the basic command of svn(Subversion), a popular source version control system like CVS. I found that svn was very complicated and that I did not see any advantage when using it. It takes us lots of time to build a workspace and checkout. However, while deeply studying, I found I am totally wrong, since svn is actually pretty helpful and easy to use.

First of all, a source version control system is not only a simple repository, but a place that can store all the various revisions of the ideas that we commit. Therefore, it provides a project-wide undo button that we can easily roll back. For example, in Lab05, we erroneously replaced our source code "readInput.cpp" file by an automatically generated one. We were so worried at first about it, but it was svn that we were using. Consequently, we typed "svn revert readInput.cpp" in the command line to revert the local changes to the file.

I think the most beneficial feature of Subversion for us is that it allows us to edit files, same or different, in different places at the same time. For example, after checking out the files from the repository to my laptop, I can work without the CSE lab machines. So can my partner. Therefore, we do not need to schedule and find a place to work together all the time. We usually just split our workload and then work on our own time. Using update can help us get the latest files from the repository while using commit can help us submit our changes. Also, any conflict of editing the same files is easy to handle since version control provides a good conflict resolution system. For instance, sometimes I add small changes to our programs, just testing the functionality in my workspace, but do not commit the changes. Before my next update, Keng may have already edited the same files. It doesn't matter, because when I updating, svn will change the name of every conflict file, and every conflict part in the programs will be marked observably.

Our project consists of lots of iteration. The same files may have different revisions. Tags help us keep track of these files which are from different iteration. For example, we first work in the mainstream directory. After we finish the iteration, we copy the files to a new directory in the tags, like the "Iteration1", "Iteration2" and "Lab_06" directories that we already have. If bugs arose in one tag, we will just work in the specific tag as if we were working in the mainstream.

In general, Subversion is a really helpful source control system that we cannot work without it.

I am really happy to work with my partner, Keng. We can learn from each other, and consequently, it made us more efficient to accomplish the iteration 1.

3081 is a writing course. I am not good at writing. Although English is also a second language for Keng, his English is pretty good. Therefore, he can help me correct my writing in the project. Furthermore, when we run into a question, the TA usually does not know what I am trying to ask. But he can describe it properly, so we can ask the TA easily or Google it ourselves. On the other hand, Keng is familiar with the command line. He knows many useful commands. For example, if I want to open Emacs using command line, I would type "Emacs". After that, I need to open another terminal since my original process switch to run Emacs. Then Keng taught me that I could type "Emacs &", then it would create a daemon process which runs Emacs, and I could still use the terminal. It is pretty convenient.

We think thoroughly about the puzzles in the project before we met. For example, I did not know how to make a string or a line comment in regular expression. So I bore this question in my mind, and discussed it with Keng when we met. Then we Googled it and each kept trying on our own. I used to write many codes before this class so that I could implement our ideas quickly. We finally finished it through our efforts. Because we knew the specific questions before we began to work, so it would be more efficient to figure them out in group together. Therefore, we can write down our specific questions of the future iteration before we work together. This ensures the same benefits occur next time.

Although there are a lot of benefits to work together, challenges sometimes arise. First of all, we need to find time that we are both available to meet. But this semester is crazy. Homework and projects are published one by one. I do not have any free time. I think Keng is also busy this semester, so we do not have very much time to meet. Thus, I tried to do some of the work by myself. I finished all of the required regular expressions before we met. Although this was a time-consuming task, it was pretty simple to do it since I just needed to copy them one by one, and then modify them a little bit. Therefore, it was easy for us to do the remaining parts when we worked together. If we do not have very much time available for the following meeting, we can keep in touch with each other through email, and come up with an outline of the project. Using this process, we will just need to consider the tiny details when we work together. As I mentioned before, my English is not very good. When we work together, sometimes I do not understand what Keng means, and sometimes he also does not know what I am trying to say. Still, he is patient enough to talk with or listen to me. Thus, English has not been a big challenge until now. But I should note that I need to practice my English frequently. It is not only important for this project in 3081, but is also one of my key priorities while studying in the U.S.

There is another challenge that would not have occurred in a single-programmer environment. Because I am a bit of a control freak, I always want to change my partner's code to my style. It is a bad habit of working with others. If I have already hurt Keng, I am really sorry about that. Maybe this problem has not yet occurred, but I used to do it last semester. Keng is a pretty nice guy, and I should keep in mind that this project is both of ours, so I should respect his work. I can organize our codes together, but cannot change his code. I hope this is not a challenge for us in the future.

This is a challenging semester. I take many challenging classes, such as CSCI 3081W, where the professor's goal seems to be to make the class as painful as possible. But I think the painful experience will bring me lots of useful skills, so this will have a happy ending.

I used to participate in the Olympiad in informatics and the ACM programming contest. So before the class, I was already familiar with C++, debugger, data structures and algorithms. That does not mean I am an expert programmer, but that I have skills necessary for the class already. The most important experience that I want to share is that anyone in my situation should keep practicing. For example, instead of asking others to help me debug, I always sit in front of the computer myself, and do the work as long as it takes. Although it takes a lot of time, it is very helpful in improving my debugging ability. I also like to modify codes again and again until the code is pretty simple. Sometimes it is readable, but sometimes it is hard to understand, largely because I use a lot of bit operators and implicit conversions between bool and int.

If you want to choose a book to self-study C++, I strongly recommend Accelerated C++ as the first C++ book you should read. With less than 300 pages, it covers the most important features of C++ and dives into STL, without focusing on the tiny details of the language. I am extremely grateful that I chose this book as a primer, and not C++ primer which has 2000 pages!

I have written tens of thousands of lines of code to practice the contest problems. But contest is just contest, not real world problems. When looking at the topics that our class will be covering, I noticed that I still have a long way to go. For instance, I did not spend enough time on commenting. A good programmer should always make effective comments. When I did the "railroad" project in 1901 last semester, it needed a large amount of comments, but that responsibility largely fell to my partner. I am not good at writing comments, so I avoided this job and let my partner to do it. In the future, I should face my weaknesses and dare to challenge them. I hope to overcome this through this class.

The design pattern is also an interesting topic. In the "railroad" project, I just added new functions to satisfy the new requests. I never thought what design pattern I should use and how important it was to programmers. I heard many people and many books talk about it, but I just never dabbled in it. Therefore, I hope to understand it more thoroughly though this class. I hope this semester will be fruitful. I really feel I am challenging myself this semester.