October 2011 Archives

never use source control before? Try it now!


Software project is developed by a team mostly, which means a tool that can make the team work efficient and enable team members to communicate in time when they are far away from each other is of great importance. In general, source control is such tool that makes the teamwork more convenient and more efficient and has some great properties to ensure the success of our project. A source control system is a place to store all the various revisions of the stuff you write while developing an application.

Source control offers tons of advantages to both teams and individuals:

First of all, it gives the team a project-wide undo button--this is of great importance. With knowing this property, my partner and I can try any code that we think it will work but are not sure of its correctness. All programmers encounter such problems: changing the code causes tons of errors, but for some reason they cannot change the code back to the original one. No exceptions for my partner and I. When we working on iteration 1, we wanted to add a pointer "next" in the "struct" of tokenType and use this pointer in our scanner.cpp file. But it turned out to be wrong and what made things much worse is that we cannot go back to the version without errors! Subversion saved our project---simply using the command "svn revert Scanner.h".

In addition, the version control system keeps a record of the changes made over time. Sometimes, I want to see changes that after my last commit--what part did my partner change? Simply using the "log" command, we can get all the information about certain file.

What's more, multiple developers can work on the same code at same time.Although when more than two people change the same part, a conflict will happen and team members have to change the code manually to solve the conflict. Most time, it works very well.

Beside advantages of source control system above, subversion has some other powerful feathers and its worth mention why you'd want to pick subversion.

From the paper "Pragmatic Version Control", I know that subversion is cheap to branch, tag and merging---it uses an efficient database model to branch and merge files, making these operations quick and painless, but in CVS, branching or labeling code requires more efforts--the server has to access and modify every file in the repository. And subversion is available for a wide variety of platforms, and most important, the server will run well on Windows--which is true cross-platform support.

There are some important things you have to know if you want to use subversion.

First, you have to use the "update" command frequently. The project is a team work and some of our teammates may work on the code when you are not. You want to make sure that you are working on the most up-to-date code every time you sit by your computer. For example, in iteration2, I forgot to update when I started, and when I wanted to commit, I was in trouble--I had to update first. Sadly, I found that my partner had already done the part I just worked on! I don't want you to get into such troubles.

Second, use "merge" properly. You and your partner can work on the same file at the same time, but if you want to commit your change but the svn says your local file is out of date, it means your partner have made some changes on this file after your last update. At this time, you need first to use "svn update" to update your local file to the most up-to-date file and then commit your changes using "svn commit -m "change file *.cpp" ". It works now! But if you and your partner work on the same part of the same file, you would not be so lucky. After you type the command "commit", you will see the conflicts between yours and your partner's. This time, you have to talk to your partner to decide which version you should use. That's what we learned and tried in labs and projects of 3081.I never use subversion before and It's so amazing. You definitely should use it!

Third, do use tags and branches. Sometimes, you want to see a previous version but the revision number is very hard to remember. That's why we give some versions that we are satisfied with a tag---name which is easy to remember. In the course 3081w, we have to do many iterations during the semester and my partner and I also put a tag on our first iteration. Anyway, tags should be read only.

"Source control is our first lag in programming", if you never use it before, you definitely should try it!

Challenges of working in teams

| No Comments

We got Iteration 1 done; but, it was challenging. With little skills in C++ my partner and I struggle throughout this project. Something we thought would be easy turned out to be difficult.

In the real world it is said a team must learn to cooperate, communicate and set standards in order to get a project done efficiently and effectively. In addition, it would also allow the team to divide and conquer the project. With this in mind, my partner and I divided the project into halves; I would be responsible for one half of project and my partner for the other half of the project. When I thought about this divided and conquer method it sounded so great due to the decrease in work load for the both of us. However, this wasn't the case because my partner and I didn't utilize team communication. As a result, we didn't set standards in which we would agree to use - such as having the same variables or place braced differently, thus led to challenges.

I believe the most challenging aspect from this project was when my partner and I came together to combine our project. For example, my partner and I named our variables differently and putted functions in a single file or separate files. To make thing worse we had our own preferences on how to write codes, thus led to disagreement. This was the result of not communicating with each other in the beginning. With this in mind, we then concluded together that we had to communicate if we wanted to get the project done. And so, my partner and I set up dates to come together to re-write our project so that it can be in a single format that both of us would agree and recognize. As a result of finally utilizing communication and collaboration, my partner and I were able to agree upon what functions to have, the naming of variables, the write up of the codes, what comments are needed, and how to put space to make the program more readable. In the end, the project was in format in which we both understand and there were no more disputes - even if we had a dispute we would solve it appropriately before things get out of hand. We also learned that we didn't need to use svn; however, now we know it's a good tool to use for future projects.

Although working in a team can be troublesome and challenging, it can also make a project much easier. Having a team allow the birth of many ideas to share because everyone think and solve problems in different ways. For example, if I were to work alone I will never know that there are other ways to solve a problem; but, if I work in a team I can learn and utilize the different ideas my partner have and improve my problem solving skills. Never the less, working in a team gives us the benefits- swapping our thoughts and learning from each other.

In contrast, one thing I notice when it comes to working alone is it can be rather difficult, especially when it comes to finding an error. This has happened to me so many times and it can be really painful because I think my program is perfect but I have to find where an error might be! Working with a partner will solve this situation very well. As I said above, everyone is different and everyone will picture a program differently. Consequently, the error you can't find will be fixed by others quickly. Maybe that is why different students ask different questions during a lecture.

Although working with a partner can make our life easier, sometimes we can mess it up for some reason. To keep all these benefit, we must always keep in mind -communication, good programming practice, comments and the use of tools.

About this Archive

This page is an archive of entries from October 2011 listed from newest to oldest.

September 2011 is the previous archive.

November 2011 is the next archive.

Find recent content on the main index or look in the archives to find all content.



Powered by Movable Type 4.31-en