October 2011 Archives

Blog 3: Subversion

| No Comments

Subversion is a tool that is used to facilitate code version control when it comes to developing large programs. When a program is developed with more than one person it is often difficult to share what you have written with the other people that are also working on the project. Subversion is a tool that lets you work on the code individually, and then share the code with the other people via what is called a repository.
Personally, I have noticed many advantages to using Subversion. My lab partner and I have both spent a substantial amount of time working on our project thus far and there is no way that we would be able to coordinate our schedules so that we could work together on our project at the same time. Subversion allows us to work on our program whenever we get the opportunity, and then when we are done we can commit our work to our repository for the other one to see. Another nice feature about Subversion is that all of the versions of your code are kept, so if necessary, it is possible to revert back to an older version of your code. A third advantage to Subversion is that each time someone commits a new revision to his or her repository, that person is to include a brief message or description about what he or she is changing, that way the next time someone updates his or her repository, he or she can read the description and then have a descent idea of what was changed, or what still needs to be done.
Despite the many advantages to Subversion, there are also a few shortcomings. The biggest problem that my lab partner and I have run into with Subversion is resolving conflicts. If the two of us are working on our code at the same time and one person commits their work without updating first, conflicts may arise. This has happened on more than one occasion, the first of which ended with me reverting back to an older version of our code because there were so many conflicts. We have since become more responsible about using Subversion and we are much more careful about committing our work. I suppose that conflicts are not really a shortcoming to Subversion, rather the user just has to know what he or she is doing, which can be problematic with anything.
Overall I would say that I have had a positive experience with Subversion and would recommend it to anyone who is involved with large programming projects, especially if they are spread out amongst other programmers. It takes some getting use to, however, once you get the hang of it you can really capitalize on the benefits that it has to offer.

Blog Assignment 2

| 2 Comments

Blog assignment 2
Now that we are a few weeks into the project, my lab partner and I have experienced many befits and difficulties with coordinating out project. Learning to deal with these difficulties and capitalizing on these benefits is something that I look forward to accomplishing in this class.
The biggest difficulty that we have encountered is trying to find a good way to split up the work. It seems like there are many occasions where one segment of code cannot be written until another segment of code is already up and running. We attempted to solve this problem by finding which functions can be written independently without the use of each other and started from there. This seemed to work fairly well Once it comes time to piece things together, we get together to work on it, which is something that has seemed to work fairly well for iteration 1. Another difficulty that we have faced is creating conflicts in subversion. There was one occasion in iteration 1 where we were both working on the project at the same time and after I tried to commit my work, I received an error message that there was a conflict with my commit. We learned how to resolve subversion conflicts in lab, however, there were so many that I decided to just revert back to the older version and took what my partner had done. Most of the things that I had added, I was able to recode quickly and easily. This time we did not resolve the conflict very well, but later on when the due date came close to coming up we had another smaller conflict, which we were able to easily resolve without having to revert to older revisions. In the future we will both have to be more careful about creating conflicts, but hopefully we can resolve them a little more elegantly than the first one that we encountered.
One of the largest benefits that I have noticed while working with a partner is that it's really nice to talk to someone about your code who knows it as well as you do. In the past when I would try to get help with my programs from TA's, it would be a bit more of a challenge because they are not as familiar with my code and are usually looking at it for the first time. When I talk to my partner about a problem I am having with our code, the thought that gets put into finding a solution is usually a bit more efficient. Another large benefit of working with a partner is the extra set of eyes for debugging your program. There have been so many times in the past where I have been staring at the same code for hours and have missed trivial mistakes in my code. Having another person around to look at the code when something isn't working correctly is a huge benefit.
Working with a partner has been both challenging and beneficial. This is really the first time that I have worked with anyone on a programming assignment, and I think that it is good experience. Once we are programming at the professional level I am sure that we will be working with others, making these skills a very valuable trait.

Blog Assignment 1

| No Comments

Blog 1
One area of this class that I feel comfortable with is writing code that is easy to understand. I have taken programming classes in the past, and writing code that is easy to understand is something that I feel I have learned early on. In previous classes I have found out that it is important to write clear code when I need help from TA's or professors. If variable names are unclear and your code is difficult to read, getting help from others is much more difficult. Writing effective comments is another area of this class that I feel fairly comfortable with. In previous classes, when we submit assignments I want to make everything clear so that whoever is grading my work knows exactly what I was going for.
One area of this class that I do not feel comfortable with, is using debuggers. I have had some experience with GDB, however, it was really only for analyzing assembly dumps when we did the "bomb lab" assignment in CSci 2021. Debuggers seem like they could be an extremely helpful tool and I am interested in gaining some experience using them. Tools for automation and scripting languages are another area that I have very little experience. Automation tools seem as though they will add a great deal of simplification to programming, and I am curious to learn more about them.

About this Archive

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

November 2011 is the next archive.

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